Why do people create these xyz-bower github repos of other projects? - yeoman

Below is one example of several I've found recently.
$bower search angular-ui-bootstrap
Search results:
angular-ui-bootstrap git://github.com/angular-ui/bootstrap.git
angular-ui-bootstrap-bower git://github.com/angular-ui/bootstrap-bower
angular-ui-bootstrap3 git://github.com/kkruit/angular-ui-bootstrap3-bower.git
angular-ui-bootstrap-complete git://github.com/datapad/bower-angular-ui-bootstrap-complete.git
The first entry seems to be the "official" bower repo with documentation and a license file, while the others appear to be someone's personal repo that contains some parts of the "official" repo minus the license, readme, documentation, etc...
The last one appears to be some shell script that operates on an "official" repo clone.
If people want to do this for themselves, I don't really care, but how does crap like this end up in the bower list? When I do a bower search, I'd like to find a pretty clear winner, but as it is I have to go digging thru which of these entries is the right one, and in the current case of Bootstrap 2/3 changeover it requires even more scrutiny.
The whole point of yeoman and bower is to make it easier to get things up and running quicker, but the pool of bower repos is polluted such that the signal to noise ratio is far to the right and into the noise category. Is there no requirement imposed on those that create bower repos?
Is there some reason this is being done?

Is there some reason this is being done?
Repos like Bower are self managed by the community, that's the only way you can provide a free service like that at scale, but each of those repos serves a role, if only for one person because if someone wants to register their package they can do so.
Perhaps most importantly I don't think Bower is positioned as a discovery tool, but a deployment tool first, which grants a level of discovery as a bonus but the main focus is on providing a consistent way to roll out packages, so in time I'm sure the additional features will mature too, but right now it's still early days and the project acknowledges that looking over the info at http://bower.io
With this specific case, the two official repos serve two purposes:
angular-ui-bootstrap Gives you everything, which you need if you want to modify template files or need just subsets of the code.
angular-ui-bootstrap-bower Gives you just the specific files you need to run everything as is, without any manual steps.
So there's a bit of a choice, and it might not be as clear as it could be, but that's the solution several repos I've seen have started to adopt. If you browse the search online, you also get the addition of download counts and github repo stars which gives a clear indication of which of the choices is most popular.
I totally agree it can be a pain, but I don't see any alternative that can scale as a community based project, but I'm sure in time people will get better at preparing their packages for distribution and take more consideration in the early design phases to facilitate that more cleanly.

Related

How does homebrew maintainers ensure the authenticity of binaries from each formula?

Since homebrew is community-driven, what will happen if someone submits a malicious formula. Will this get merged into the main repository and end up being installed by everyone else? How can homebrew prevent this?
These things could conceivably happen. The general consensus out there seems to be that the likelihood is small enough to ignore. IT companies like Google, Amazon, and so on are perfectly OK with employees using it, so it is probably fine if you do too.
Google: 90% of our engineers use the software you wrote (Homebrew) [...]
--- Max Howell, initiator of Homebrew (https://twitter.com/mxcl/status/608682016205344768)
Review works
Getting a malicious formula merged is actually not that easy. The fact that you need a GitHub account and that building up a GitHub profile (to give yourself credibility) is a hard work (you have to program) can be a first line of defense.
There are actual humans looking at the formula during the Pull Request process. Nothing obvious should pass through, moreover, it is possible that just the fact of people being there and doing the checking dissuades many from even trying to propose something malicious.
Possible attacks
Has any repository hacking actually happened? Hard to say, because the following example could easily be just a honest mistake.
CVE-2008-0166
In 2008, an overactive Debian maintainer introduced a bug to OpenSSL, apparently in an effort to "clean up the code." (https://www.schneier.com/blog/archives/2008/05/random_number_b.html)
Lets now turn to other possible attack mechanisms
Typo-squatting
Attacker uploads a package that is similarly named to a popular one. People make typos and download the spoofed one.
This was successfully demonstrated for Pypi in N. P. Tschacher's bachelor thesis, see incolumitas.com/2016/06/08/typosquatting-package-managers/.
Any kind of manual review should catch it, so Homebrew is likely safe from it.
Reflections on Trusting Trust
(https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf)
Famous essay by Ken Thompson which walks you through a procedure to insert a Trojan horse into a software stack (both the compiler and the application), so that it is present in both, but not easily detectable in either.
Dependency confusion
(https://www.schneier.com/blog/archives/2021/02/dependency-confusion-another-supply-chain-vulnerability.html)
Pick a company that is running an internal package repository. Publish a public package which has the same name as an internal company package. Then, the package installer may mistakenly prioritize the public name, and therefore employees of the company suddenly start installing your package.

Handling multiple projects in TFS - some tools available?

I am facing this ridiculous problem. I have more than 150 projects in tfs, and when i need to give admin rights to a particular person, or give portal rights, enable documents folder, change templates, get a combined report, etc, it gets tedious job to do it on all the projects...
Is anyone aware of such a tool that can work on multiple projects at a time ?
If you are looking to ease the pain of managing permissions across TFS, SharePoint, and SQL Reporting Services, then this tool on codeplex can help:
http://tfsadmin.codeplex.com/
I've not come across anything that allows you to do this, the only thing you can do really is to make use of those AD groups. If everything is organised into a decent structure (if not, move it :)) then the permissions should filter down, then it's just a matter of tweaking when needed.
Brian Harry's comments in response to Neil on Builds though: http://blogs.msdn.com/b/bharry/archive/2011/09/19/the-new-team-explorer-in-tfs-11.aspx imply that it's not going to be "fixed" (or significantly more awesome) next release though :(

Bug reports solution

Clarification/summary for the question -- we're looking for:
a hosted bug tracking system,
that is as convenient to use as lighthouse/github/launchpad,
can deal with attachments,
integrates email notifications and operations (implies operations in commit messages),
has a script-friendly API,
allows anonymous bug reports, or ones with an email but that do not require setting up an account for submission.
Lighthouse is close but fails on the last point, launchpad is similar, github also doesn't handle attachments. Tender is great for the last point, but fails as a general bug tracking system (and it looks like its open-source version will be limited to basically being a forum).
We looked into a number of applications to install and setup -- but with this range of requirements, they are always coming with a huge cost in terms of investing time in setting up and maintaining a working system.
In our (open-source) project we have been using Gnats for a really long time. It doing what it was designed to do fine, but that's getting to be pretty inconvenient: it's no longer maintained, has features that we never use, and lack features that we'd want to use... It doesn't deal with attachments, has no easy way to perform actions via emails, no integration with commit messages, and a web interface that was designed for 90s browsers. So I've been looking around in an attempt to find something that could replace it, hopefully some hosted solution to avoid the setup/maintenance hassle.
Probably the most impressive tool that I've seen is lighthouse: it has a very nice and practical interface, properly deals with attachments, controllable via emails, and can respond to commands in commit messages. But... It doesn't have any sane way to submit a bug anonymously -- and that's a major requirement, since we need any random user to be able to submit bugs through our IDE. (It seems that there is a possible hack to forward an email faking the From field, but that doesn't work very well -- specifically, the reporter should be included in the followup email exchange.) On the other side, there is the related tender tool, which is very good in that area, but is very basic otherwise -- too basic to serve as a bug tracking system.
There's a whole bunch of other sites that I've tried -- it seems that all of them require submitters to have an account, so they don't work well for our needs; as well as being limited in various other ways (don't deal with attachments, no good email integration, etc etc). It doesn't help that the meta-descriptions of these sites is usually pretty obscure: it took me hours to just figure out what tender/lighthouse are and how they're related, and no site mentions its inability to receive bug reports without registration. (I'm looking only at open-source-friendly sites, since we don't have any kind of budget for such things.)
There's also the option of installing some system locally, but bug tracking systems tend to be monsters that I'd like to avoid configuring and maintaining, if possible.
So the question is: is there anything obvious that I'm missing? Or to make it more concrete: is there a good comparison page somewhere that lays out popular options and their respective features explicitly?
JIRA is free for open source projects. It's far more user friendly than trac and bugzilla, and allows anonymous submissions and plugins. Unfortunately you'll need to host it on your own server, but from personal experience I can tell you that all you need to do is install a database (it can run without; but that's not a good idea) and it basically maintains itself.
Also is there a particular reason why Google Code or Sourceforge issue tracking tools wouldn't work? You don't need to use all their services if you don't want, you could use them purely for issue tracking.
Did you try trac? It is used by many open source projects.
FogBugz is one option. They'll host or you can run it yourself. My company looked at it but ... political considerations ... meant it is not viable here.
Have you looked at this Comparison of issue tracking systems on Wikipedia?
I have also found fixx, by hedgehoglab. Apparently it has the features that you care more:
Get things done
fixx has an intuitive interface to enable quick bug
reporting. Filling in a bug report is
as easy as sending e-mail.
Ability to add multiple attachments to issues allowing you
to attach screenshots and manage
documents related to issues.
Clever notification options to keep relevant people informed while
preventing issue tracker spam.
Also:
It has an open REST API.
I see that you are using Subversion as SCM. There is a Subversion integration with fixx.
Its unique installation requirement is Sun JDK 1.5.0.
It seems free for Open Source Projects and an hosted version is "Coming soon".
Note that I have never used it, so I cannot give any recommendation.
The open source BugTracker.NET has support for the following areas that are giving you problems:
Attachments
Guest login
Email notifications
SVN commit integration
I found it easy to set up, maintain, and tweak. Of course, you might think otherwise if you are not familiar with .NET and have a Windows server available.
You might look at Unfuddle. They do allow an API for the submission of tickets and have your other points covered including attachments.
Take a look at repositoryhosting.com They have ready made solution with trac / svn / git, for you. Comes with all kinds of bells and whitsles, such as Agilo plug-in and auotomatic backup to the amazon S3 bucket of your choice.
The prices are very reasonable.
Also, jumboxes offers a Trac / SVN virtual appliance that you can host in your own environment.
Redmine is a good open source option. You can check an online demo and a list of features.
It's not hosted though. But it's an interesting option.
And you can always check a list of different open source bug tracking alternatives
I've used ZenDesk in the past and it was rather hassle free.
In addition it has an api: http://www.zendesk.com/api.
Moreover I KNOW it can CC whosoever you want it to whenever anything happens.
We too are looking for a new solution.
At present we're using FogBugz, which is painfully slow.
We need our customers to be able to log bugs via email. Tender looks perfect, with the exception that it doesn't have any obviously usable ID fields that we can pass around. Is there a plugin or similar? I could knock up a browser extension to "goto bug id [whatever]" but that seems kludgy for what should surely be a core feature?

Is it possible/advisable to write reusable Ruby-on-Rails applications?

I have an idea for a large web application, which in my mind would really be a number of reasonably independent application "components" (?), e.g. forum, blog etc.
It seems to me that it would be nice to open source some of the individual components for others, or myself in the future to use.
Now clearly, I could write a basic forum, make the code available, then copy it across into my large app and extend/integrate it. However, this doesn't feel very DRY. In an ideal world I could maintain the code in one place and drop it into my larger application.
Rails seems to include engines, which sound like solve my problem but it would appear that what I want to do is a bad idea!
So should I..
a) Just build one large, coupled app.
b) Create a rails forum app (for example), release it, then merge/copy it into my main app
c) Use engines
d) Other...
Cheers,
Adam
That warning is just the standard Uncle Ben Corollary. Paraphrased from "With great power, also comes great responsibility." to "Just because you can, doesn't mean you should."
However, just because there are a number of uses for engines that are bad ideas, that doesn't mean it is in your case. Blogs and forums are two reasonably independent components that have already been produced as plugins using Engines. You might not even need to make them.
The way I see it, if you're planning on reusing a functional component that you can feasibly segregate from the rest of the app, then that's a good enough reason to make it a plugin, whether or not it relies on engines.
My experience is that these plugins grow from existing application code I've written. It's much easier to conceive, write, and test them as part of an application than on their own. Engines being miniature apps, aren't that much harder to build and test.
In short. Only you can decide which path is best, because you are most familiar with the goals of your app. Before you start have a look at what others have done with engines and plugins. The components you want to build may already exist.
To answer the question, I would probably start by building a single app, and extract out the bits that could be useful in other apps and abstract them into [engine] plugins as they reach maturity.
What you might be looking for Git Submodules. I don't know a ton about them, but you can simply have a git repo within a git repo. And you can update all your inner git repos pretty easily. Here's an article talking about it.

Running multiple sites from the same rails codebase?

I have a client that wants to take their Rails app that has been successful in one niche and apply it to another similar niche. This new instance of the app is going to start out very similar: all the same functionality, different logo and colors. However, if the new site is successful it will inevitably need significant customizations that shouldn't be applied to the original site. At the same time, if bugs are fixed and improvements are made to one app, then both apps should be able to share those improvements.
Can anyone suggest strategies or resources that address this issue? How do I keep changes that apply to both apps from taking significantly longer to test and implement?
Yes, I know the answer involves SCM, plugins, gems, and Rails engines. These tools will and are being used. but I want to know when and how to use these tools towards solving this problem.
Links are also welcome.
This question is not the same as:
Multiple websites running on same codebase?
In my question, I'm not running the exact same app with different settings.
How do you sync changes between multiple codebases? I'm asking a similar question, but I'm specifically asking about Rails apps.
We currently work with a setup quite similar with what you are describing.
We started developing a somewhat big Rails app (sales, stock management, product catalogue, etc) for a client. After finishing it, there came several new requests for almost identical functionality.
The original app, however, had to keep being maintained, adding new features, correcting bugs and whatnot.
The extended ones needed to maintain most functionality, but change appearance and looks.
What we did was follow a series of steps:
First we started cleaning up the code, pulling hardcode references to tables, reducing and optimizing queries, looking up missing indexes and ways to improve our ActiveRecord use
After being somewhat satisfied, we started developing missing tests. I can't stress hard enough why it's useful, since we'll be maintaining a same codebase for several apps, and need the core functionality to be as protected as it can be from new changes.
That was also the magic word: core functionality. We started selecting base functionality that could be reused, and extrating all generic code. That gave us a mix of controllers, models and views, which we started to change into modules, plugins and gems.
What goes where? Depends greatly on your code. As a rule of thumb, functionality that doesn't deal with the domain language goes to plugins (or gems if it doesn't depends too much on Rails)
This approach led us to a several of plugins, gems which we then pulled together reassembling the original project, and then it got to it's own GIT repository. That way, we had a main "template" repository which glued all the components and several other GIT repositories for each of them.
Finally, we develop an easy theme system (basically loading /stylesheets/themes/:theme_name/ and getting theme_name from the DB). Since it's an intranet project, we could almost do anything with proper CSS styling. I'd guess for working with IE you'd need a more complex approach.
Then, we just used that main repository developing the new functionality on top of it.
Now, how do we deal with changes to the core base. We start with our template repository. We fix or define where the fix or change should be and either change it there or on it's corresponding gem/plugin. After properly testing it, we deploy it to our GitHub account.
Finally, we merge/rebase the other projects from that template repository, getting the new updates.
Sounds a bit complicated, but it was only for the setup. The current workflow is quite simple and easy, with the given advantage of working with several developers without bigger issues.
With minimal touching of the main site, it might be possible to use the Ruby code from it while extending the templates and changing the styles. I have worked on that extensively in Django and the layout can look like:
project/
sites/
site_one/
templates/
models.py
settings.py
urls.py
views.py
site_two/
templates/
models.py
settings.py
urls.py
views.py
base_app/
settings.py
You could try do something similar in Rails:
main_webapp/
app/
config/
...
sites/
site_one/
controllers/
models/
views/
site_two/
controllers/
models/
views/
Assuming the functionalities are identical across sites but they just have different layout and styles, there will be none or very little model and controller code. Should you wish to add more functionality to specific sites, just stick the code under the desired site folder.
Django also have the concept of Sites and the ability to look for templates in one specific project folder and an app folder. You could try to copy those features and bring them over to Rails to achieve running multiple site from one codebase.
I recognize that you are looking for a Rails solution but you can still checkout how it's done in Django and copy some of the useful features to the other side. If I like a Rails specific feature, I'll port it other to Django/Python.
We're doing something similar at my company. Except its currently involving multiple environments (production, test, development). We're using SVN as our SCM to keep our code straight and lets us duplicate the current stable environment and create separate versions of an application (and potentially changing things like the logos or certain functionality). I highly highly recommend running the environment with Apache/Nginx and Phusion's Passenger. This is letting us run all of these applications separately, on the same/similar codebase(s). And that's it. We have to DBs, one Production and one Development to keep our live data separate, but you can easily connect two app instances to the same db this way. Its worked out really well for us so far in being able to develop, test and deploy multiple web applcations without taking down the primary production server.
I know this could be possible using Git Submodules

Resources