Right after Github got nailed with that mass assignment vulnerability in Rails, one of my colleagues asked me when I thought everyone would start to abandon Github. He asked with a sort of cocky, corporate assumption that I too was as appalled as he was at the blantant disregard for security. His unspoken subtext was “Those DVCS kids, they got just what they deserved, won’t it be great when we can get back to a real VCS like Perforce”.
Little did this guy know that it was I who created the first corporate Github repository for this particular organization in an act of rogue VCS activism. And, it was clear from the way he was talking about version control that he longed for the days of centralized control where one guy had to manually merge in everyone’s changesets. I remember that sort of work, it was awful. Tack on a couple of days to the development cycle to deal with awful SVN conflict markers.
I didn’t respond. Honestly, if you depend on Github at work, you are in an odd spot, you are hoping that a co-worker doesn’t have an axe to grind against the service because it wouldn’t be tough to convince some manager-type that this Github thing does deserve a second-look. I did prepare a list of reasons why this particular GitHub vulnerability doesn’t matter… Here it is, you might need it yourself:
Github was hacked, by a friendly. A bored Russian named Homakov was just trying to make a point about Rails security. Github initially suspended his account, but has since reinstated it. It isn’t like Github has hijacked by ransom-demanding Sudanese pirates here.
When they found out about the problem, they fixed it… immediately. They didn’t try to hide it, they responded just the way any hosted provider should.
They made the right decision and had everyone reconfirm the identity of every key ever uploaded to Github. You couldn’t ask for a better response. They very much could have taken some lazy road and just ignored the possibility the every key could have been compromised.
Go ahead take all the code you want, the house is locked. Even if our code was transfered to a hostile (which it likely wasn’t), you don’t get into production without a secret, and those secrets are not in code.
This sort of stuff happens to every hosted service you use, 95% of the time you don’t hear about it because it is a real hostile and the company just pays some ransom demand in exchange for not being screwed.
Ask any of the developers what they prefer, using Github or using the old proprietary system. Ask them how much time they used to waste merging branches.
Github is a DVCS, every single developer had a full copy of the repository checked out, if someone had compromised code it would be apparent.
Listen, Github is how software is done right now, you move back to some proprietary POS, and I guarantee you half of the developers will just take all the vacation they are due and tender resignations.
Github is Impervious to Super Missiles, please just go back to management.
Here’s a graph of the traffic breakdown by OS from Google Analytics of the Common Java Cookbook:
Can you guess which colors represent which operating systems?
1st Place: Blue: Windows
2nd Place: Green: Linux
3rd Place: Orange: Mac
It is no contest. Working developers use Windows. If they don’t use Windows then they just as likely to use Linux or Mac. This is a year-long snapshot from Jan 1st ’09-’10, and this trend is consistent with other larger, developer-focused web sites that I see analytics numbers for.
Edition 0.7 is out. You can read it on Scribd or online at the Sonatype site. This edition saw a marked improvement in the rendering of the PDF version of the book with the move to the newer docbkx plugin and the integration of the fop-images-pdf library to allow direct embedding of PDF vector art as figures.
As a co-author of Harnessing Hibernate, I get to hear about some of the feedback the book has received from time to time. James recently shared a letter he received about the book, a real “letter”: signed, sealed, and delivered by the United States Postal Service. How archaic? Someone decided to read a computer book, type up a letter, and mail a physical artifact. My initial reaction was, “what kind of crazy jackass would bother with the USPS when our email addresses are listed in the…” But, after some reflection, it certainly worked; it gained someone’s attention more so than a simple email. A real letter is much more difficult to ignore than something that shows up in my busy Gmail INBOX, and you have to consider that the person who sent this letter is more invested in his feedback than someone who fires off a random email.
Emails are easy to ignore, and the promises made in an electronic format fade quickly. Committing ink to paper is something else entirely, and you tend to take printed material more seriously than you would an electronic message. Printed letters are much more interesting, and they retain powerful lasting value that emails do not… see this blog post about letters from the recently deceased John Hughes. As effective as it was at gaining my attention, I can’t help but return to my initial reaction. Is this someone with an interesting archaic quirk? Or, is this some email-avoiding conspiracy theorist?
One of the pieces of feedback in the letter was that the book was out of date. Of course the book is out of date, bulk-printing 10,000 copies of a 400 page book about a rapidly evolving open source project is certainly the definition of crazy. Unlike other books I’ve helped to write, Harnessing Hibernate is not free. It doesn’t have a life outside of the printed product, and it is getting more and more irrelevant every single day. Harnessing Hibernate is a lost opportunity, if it were an open title, it would quickly gain an audience and a community willing to help develop the content.
When I hear that someone has blogged about some general Maven hatred, I cringe and expect to read a post that consists of 30% incorrect assumptions about how Maven should be used, 50% ignorance of the most basic concepts, and 20% truth.
What can be done:
The Maven Users lists needs to become a bit more opinionated for first time users. If someone enters into the discussion asking the following question:
“I’m attempting to publish a directory full of JARs to my local repository using the Install plugin.”
The first reaction should be, “No, use a repository manager.” Not, “Let me find seventeen ways to help you do a series of backflips to get Maven to do something it was never intended to do.”. Maven isn’t the general Swiss-army knife tool that many approach it as. While it *can* be made to do anything you want it to do, there are core assumptions that shouldn’t be challenged. Half of the criticism we deal with is from people that were never told: “Don’t try this, don’t try to use Maven for this.”
The Maven community needs a better FAQ. I’m of the opinion that the lack of a good FAQ is directly related to the difficulty of the APT format. If Maven had a better FAQ, we’d have less people approaching it with the wrong assumptions.
Multimodule Build – Also, I took some time last week to split up the Commons Java Cookbook into a Multimodule Maven project that uses a number of plugins to fully automate the publishing pipeline. If you want to checkout the source code for everything, take a look at the GitHub repository.
I’m focusing on the book build because I’m trying to make it easier for me to move quickly before I start developing more content. I’m working on some automation tools that will make it easier to build, test, and inject all of the code samples in the book, and I’m also looking for even more ways to distribute the content. In the next few weeks, expect more news about an Eclipse version of the book and a version of the book for ebook readers.
As promised, I’m opening up the license for the cj-cookbook. I’m starting out with Creative Commons Attribution-No Derivatives-Non-commercial 3.0 US. So, I think that this license is a bit Draconian. It essentially means: “Can’t sell it, don’t use it for training, don’t change it, and tell everyone I wrote it.” Doesn’t that seem a bit vain for an open source project? I might relax the license a bit by dropping the NoDerivs clause, but I’m still mulling it over. Does anyone reading this post have any particular feelings about what license this book should be under? Does anyone want to challenge me to release it under ASL 2.0? I have been critical of viral licenses in the past, so it would be ironic of me to release it under the GPL Documentation licenses.
This is a quick follow-up to release 0.13. Most of the references to Jakarta are now removed from the book. Some projects, like the now defunct Slide or the very inactive ORO, are still in Jakarta. Projects like Lucene and HttpClient which were both parts of Jakarta when the original book was published have been updated, and I’m pointing to the project sites for Apache Lucene and Apache HttpClient (or is it HttpComponents? See a later update.)
Changing all internal link elements to xrefs and getting rid of hard-coded section references. For some reason, the XML I got back from O’Reilly has hard-coded text in link elements that reference section numbers. So if you see a reference to Section 1.4, click on it, and end up looking at Section 1.2, this is because I must have deleted a section. DocBook has the facility to generate XRef text at render time so I have to modify all the internal link elements to xrefs and set the label style.
Write a Unit Test that compares the text of a ulink element with the target URL. If the text of a ulink begins with “http://”, I need to make sure that the anchor tag is going to link to the exact same URL. There are already a few examples in the book where there are inconsistencies between the URL that is printed and the URL that is being linked to.
Write a Unit Test that tests all ulinks for 404s. This is important for consistency, I need to figure out a way to do this automatically for other books as well, so I’m thinking about a way to do this in a Maven plugin.
I can’t tell if the hc.apache.org project has actually released 4.0 or if we’re stuck in a perpetual beta. I don’t want to update the book to talk about httpcore until I’m sure it isn’t going to change. I do know that I have to circle back at some point and:
Update the Http/DAV chapter: Change it to reference the new Http Components Project
Update the Http/DAV chapter: Change the sections that discuss Jakarta Slide to reference Apache Jackrabbit
Update the Lucene Samples to use the Latest Release: Right now this part of the book references version 1.9.1 because there was an API change wrt configuring the Document.
I need an issue tracker for this project, and I can’t decide between Trac and JIRA. On the one hand, I like Trac’s simplicity, but, on the other hand, I’m pretty sure I could benefit from some of the subtask stuff that is available in Jira. Decisions, decisions, decisions….
If you haven’t noticed, Jakarta was dismantled. It now contains a shell of projects which are largely inactive. The community which was Jakarta once contained hundreds of committers and was the center of open source Java. It was Jakarta that produced Ant, Maven, Struts, Log4J, Lucene… among others. While Jakarta was an interesting crucible for innovation, it didn’t scale very well and there were an endless series of flamewars and management problems due to the fact that it was just too large for its own good. Sometime in 2003 or 2004, a decision was made to split Jakarta into separate TLPs and Commons eventually moved to Apache Commons (http://commons.apache.org).
Release 0.13 of Common Java Cookbook updates everything up to Chapter 5, removing references to “Jakarta Commons” components in favor of “Apache Commons”. Where a project was called “Jakarta Commons Collections” it is now called “Commons Collections”.
Next step: I’ll follow this release up with a 0.14 that removes all of the references to Jakarta XYZ.