via css-tricks.com
Here at Google, we have thousands of engineers working on our code base every day. In fact, as previously noted, 50% of the Google code base changes every month. That’s a lot of code and a lot of people. In order to ensure that our code base stays healthy, Google primarily employs unit testing and code review for all new check-ins. When a piece of code is ready for submission, not only should all the current tests pass, but new tests should also be written for any new functionality. Once the tests are green, the code reviewer swoops in to make sure that the code is doing what it is supposed to, and stamps the legendary “LGTM” (Looks Good To Me) on the submission, and the code can be checked in.
However, Googlers work every day on increasingly more complex problems, providing the features and availability that our users depend on. Some of these problems are necessarily difficult to grapple with, leading to code that is unavoidably difficult. Sometimes, that code works very well, and is deployed without incident. Other times, the code creates issues again and again, as developers try to wrestle with the problem. For the sake of this article, we'll call this second class of code “hot spots”. Perhaps a hot spot is resistant to unit testing, or maybe a very specific set of conditions can lead the code to fail. Usually, our diligent, experienced, and fearless code reviewers are able to spot any issues and resolve them. That said, we're all human, and sneaky bugs are still able to creep in. We found that it can be difficult to realize when someone is changing a hot spot versus generally harmless code. Additionally, as Google's code base and teams increase in size, it becomes more unlikely that the submitter and reviewer will even be aware that they're changing a hot spot.
In order to help identify these hot spots and warn developers, we looked at bug prediction. Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range. Source-based metrics that could be used for prediction are how many lines of code, how many dependencies are required and whether those dependencies are cyclic. These can work well, but these metrics are going to flag our necessarily difficult, but otherwise innocuous code, as well as our hot spots. We're only worried about our hot spots, so how do we only find them? Well, we actually have a great, authoritative record of where code has been requiring fixes: our bug tracker and our source control commit log! The research (for example, FixCache) indicates that predicting bugs from the source history works very well, so we decided to deploy it at Google.
mv {E,e}ecummings.txt # Change the case (to lowercase) of the first letter E of a filename using brace expansion.
— Command Line Magic (@climagic) December9, 2011
While you’re building your application, chances are you’ll run into more than a few times where you write some kind of library-esque code that you then, of course, drop into a
libfolder somewhere. Sure, it’s pretty reusable and you may want it in another project someday, but it’s just one file, surely it’s not worth the headache of releasing it as open source, right?Wrong. Every piece of library code living inside your application is a piece of code that you are solely responsible for maintaining. Even if it’s just one file it can often be worth it to publish it as open source just to keep it out of your application.
This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please mail me, Heiko Webers, at 42 {_et_} rorsecurity.info. After reading it, you should be familiar with:
The Top 25 Software Errors are listed below in three categories:
Were you a big Gowalla fan? Did you like Dodgeball? Did you think Trunk.ly (gasp!) was better than Pinboard? Did you make a lot of contributions to Nextstop? Do you miss Aardvark and EtherPad? Did "I Want Sandy" change your life?
These projects are all very different, but the dynamic is the same. Someone builds a cool, free product, it gets popular, and that popularity attracts a buyer. The new owner shuts the product down and the founders issue a glowing press release about how excited they are about synergies going forward. They are never heard from again.
Whether or not this is done in good faith, in practice this kind of 'exit event' is a pump-and-dump scheme. The very popularity that attracts a buyer also makes the project financially unsustainable. The owners cash out, the acquirer gets some good engineers, and the users get screwed.
To avoid this problem, avoid mom-and-pop projects that don't take your money! You might call this the anti-free-software movement.
