“Seems like insane advice at first glance. I’m not sure many companies even understand why this would be a good idea, much less have the guts to attempt it. Raise your hand if where you work, someone deployed a daemon or service that randomly kills servers and processes in your server farm.”

via Jeff Atwood at Coding Horror

Cool!

The idea is that teams of developers want/need a simple way to ensure that their code gets reviewed by other people in their team (without having someone looking over your shoulder).  I think enough other people have talked about why we need code review (see below), but there hasn’t been a suitable, easy platform for doing it.

• https://www.owasp.org/index.php/Code_Review_Introduction
• http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html
• http://blog.nelhage.com/2010/06/i-hate-code-review/

There are a few hosted code review apps, but hopefully for commercial apps you have a policy to keep source-code in-house.  So we need an installable code review app, that automatically fetches commits from a repository, and provides a simple interface to do simple code review.

Inspectify is my answer to this problem.  It’s still a wee way off, but when it’s ready, you’ll be able to install it on a basic *nix box and start reviewing your Subversion-based code (support for other SCM’s may come later).

“Last week I wrote a piece called “Programmers: how to make the sysadmin love you“. The feedback has convinced me it needs a counterpart; something written from the perspective of the systems guy trying to get along with the dev team. Having offended all the programmers of the world (not to mention several Americans who don’t know what a fag packet is) it’s time to do the same for you systems folk.”

via mockyblog

“As a coder working for an organisation you are focused on building something to meet a defined spec. This spec will say things like “background should be blue”, “tabulated interface for user management” and “should not crash”. It may come with a set of images stitched together by a UI designer of how the site/app/thing is expected to look – either crayoned on the back of a fag packet or more likely mocked up in Photoshop so the UI programmers can pull it apart again for the logos and buttons. In a really good spec you’ll find a storyboard defining how it should behave, ready-made content and all the copy up front. We wish.”

via mockyblog

“Most of high scale web applications use MySQL + memcached. Many of them use also NoSQL like TokyoCabinet/Tyrant. In some cases people have dropped MySQL and have shifted to NoSQL. One of the biggest reasons for such a movement is that it is said that NoSQL performs better than MySQL for simple access patterns such as primary key lookups. Most of queries from web applications are simple so this seems like a reasonable decision.
Like many other high scale web sites, we at DeNA had similar issues for years. But we reached a different conclusion. We are using “only MySQL”. We still use memcached for front-end caching (i.e. preprocessed HTML, count/summary info), but we do not use memcached for caching rows. We do not use NoSQL, either. Why? Because we could get much better performance from MySQL than from other NoSQL products. In our benchmarks, we could get 750,000+ qps (queries per second) on a commodity MySQL/InnoDB 5.1 server from remote web clients. We also have got excellent performance on production environments.
Maybe you can’t believe the numbers, but this is a real story. In this long blog post, I’d like to share our experiences.”

via YOSHINORI MATSUNOBU

“It’s extremely common for websites to protect your password by encrypting the initial login, but surprisingly uncommon for websites to encrypt everything else. This leaves the cookie (and the user) vulnerable. HTTP session hijacking (sometimes called “sidejacking”) is when an attacker gets a hold of a user’s cookie, allowing them to do anything the user can do on a particular website. On an open wireless network, cookies are basically shouted through the air, making these attacks extremely easy.”

Eric Butler, Firesheep.

“It occurs to me that the tools we have available each do a large variety of things, and that there’s no good reason for these functions to be bound together into one application. For example, Maciej’s recent article on why not to have a public of WordPress (and more details) shows that serving the website and editing it can be very separate pieces. The original ancient Blogger software also used to push a copy up to your site via FTP.”

via joshua.schachter.org

Great ideas.

After removing all the extra HTTP requests you possibly can from your waterfall, it’s time to make sure that those that are left are as small as they can be. Not only this makes your pages load faster, but it also helps you save on the bandwidth bill. Your weapons for fighting overweight component include: compression and minification of text-based files such as scripts and styles, recompression of some downloadable files, and zero-body components. (A follow-up post will talk about optimizing images.)

via phpied.com