reiz

First of all, thx for documenting the mogration. That is very interesting.

Your monthly bill is smaller now. But how many hours did you invest into the migration? And how many hours more per month do you put in maintenance? I mean you have to take care of security patches now and many more things.

You used AWS in the most expensive way. Of course its expensive if you use on demand offering. You can cut costs by using Spot instances for ECS. Another way is by using reserved instances for ECS. If you pay 3 years upfront, you can get discounts up to 75%. That works for ECS and RDS.

I'm running ZEIT.IO on AWS and I had similar problems. But I don't want to manage VMs. As soon I have to SSH into something, I have a ton of problems I don't want to deal with.

That's a great map! If I would still live in the US, my wife would use that map every day :-)

This is a setup I'm using in all my Rails projects. Maybe you find it useful.

Docker container pre-configured with Nginx as forwarding proxy. You can use it to either block all outgoing traffic and whitelist certain domains or allow all outgoing traffic and blacklist certain domains. Let me know if you find it useful!

That's nice to see the NSA is contributing to the OSS community. I just randomly picked one of the NSA GitHub repositories, analysed it with VersionEye (https://www.versioneye.com) and found already 25 security vulnerabilities. Who is the best person to contact in this case? Here is the security report: https://www.versioneye.com/user/projects/59479cd06725bd00123....

You could use the VersionEye Maven Plugin for that: https://github.com/versioneye/versioneye_maven_plugin. It checks your dependencies against a license whitelist on the VersionEye server and if there is a violation it breaks your build on your CI server. That way you can enforce a license policy continuously. It's much better than just checking licenses once a year ;-)

I'm working on VersionEye since a couple years, it's a similar project and I open sourced it last week: https://blog.versioneye.com/2016/06/28/versioneye-goes-open-.... I'm following Andrews activities since a while and like what he did with libraries.io. Great job! As both projects have a big overlap and are open source now I'm open for collaboration :)

I'm crawling some famous C repos at GitHub for VersionEye. There are listed here: https://www.versioneye.com/C. And I integrated the biicode, a dependency manager for C/C++. The biicode packages are listed here: https://www.versioneye.com/biicode. Currently there are no tags like at libraries.io but maybe I will add tags and tag filters for browsing tags/categories.

Everybody is an highly competitive field. Everybody wants to release as fast as possible. That's why everybody is using open source components. I know that everybody in the commercial field avoids GPL. Just curious which other licenses are on the blacklist of the some companies.

Thanks for your input and the link. Any other licenses beside GPL you try to avoid?

Nice! That's what the world waited for :-)

I guess he is from the BayArea and he don't like remote sessions :-)

I wrote once a license crawler for VersionEye which recognises the most common licenses in README files on GitHub. But I didn't crawl whole GitHub! Only projects which are submitted in package managers and did not provide a license info on the package manager. I'm using it for example to complete license infos about RubyGem projects without a license on RubyGems.

Very interesting blog post. I wouldn't have thought that so less projects on GitHub provide a proper license! I'm working on https://www.versioneye.com and we track currently more than 500K open source projects in package managers. I just did a quick lookup in our database about Ruby licenses. Currently we have licenses for 56803 Ruby projects (RubyGems) and 49842 of them are MIT! That means 87% of all Ruby projects who provide a license at all, provide an MIT license! I will do a couple more queries and write a blog post to this!

Cool page. Makes totally sense. I'm doing it the same way. And in addition I use VersionEye to get notified about new versions of open source libraries I'm using in my projects. That saves me a lot of time. By the way I'm the dude who started VersionEye.

Check out jeweler (https://www.versioneye.com/ruby/jeweler/2.0.1). It makes creating and managing a Gem much easier ;-) Since I know it, it is a must have in all of my Gem projects.

Thanks for the article. I agree with you. Totally believe that the web will win in the long run.

Cool! Good Job. I really like it. Many times the documentation for programming projects look like grab. This project is a big help. Many Thanks1

Great news. Many Thanks for all the hard work.

OK. That makes sense.

Your last sentence is specially interesting. Being able to do a "bower install backbone" and going back to work is actually the purpose of a package manager. If it doesn't understand your project structure and is not able to wire the downloaded libraries into your project, whats the point of using it? Then bower is as good as npm or any other tool to download libraries. Right?

Yeah, that is good point. I guess should have point out that in the article.

But I still think that the initial publishing on Maven Central is more difficult then it should be. Pretty much every other package is doing a better Job on publishing. It took me less then a minute to publish my very first Ruby Gem. But it took me 1 week to publish my very first Jar file on the Maven Central.

Clojars is doing better.

You will laugh. That was my first title. I showed the article around, 2 days ago, and a good friend of my told me: "You need a more provocant title!".

Nils Adermann just confirmed that. I updated the blog post and the info graphic.

Well. You are right. Next time I will pick my words more carefully.

That's true. That's the disadvantage of that system. If there would be a language agnostic package manager, would you use it?

Good point. My next package manager after Maven was Bundler/RubyGems. And it was enlightening. I don't use so much PyPI, but I heard that the core commuters are working on a big refactoring.

I didn't felt attacked. I appreciate feedback ;-) And you are right. The choice of a language is just a choice. Dependency definition in native code is always a security vulnerability, because by resolving the dependencies you execute unknown code, specially if the packages are not signed. I could for example publish a python package on PyPI with a setup.py which contains code to delete files on your hard disk. At the moment my setup.py gets executed on your machine you will lose some files. Something like that can not happen with JSON, XML or YML.

Good point! I will blog more about that. I think there is a reason for that, why there are so many build tools out there in the Java ecosystem. Obviously there is no clear winner and the people are not satisfied with the current status.

Very good point. I didn't took that into the article because these package managers are all build for 1 single language. But I totally get your point. A language agnostic package manager, or at least a language agnostic repository with a clear defined API, would be awesome! The clients could still be different for each language, to handle language specific problems, but the repository server could be the same.

I didn't know that with the git hash. That's a good point! What I like on NPM is that they use JSON for defining the dependencies and that the packages are by default not installed globally. NPM and Bundler are different in some ways, but in general they do both a good job.