j-kidd

Double indentation looks rather ugly though. I like the "K&R" style much better (as shown in comment from bpicolo):

    def some_descriptive_function_name(
        one_parameter,
        another_parameter,
    ):
        some_functionality()

Anyway, either one is superior to 'indent to sibling', where the lines are now tightly coupled to each other.

So, with T2 instances and General Purpose volumes, Amazon is now officially in the overselling business. Kudos to them for finding a way to do it fairly. Looks like extra tough time ahead for lowendbox sellers.

The jmespath library from boto is quite similar to this, and possibly has way more traction. Some differences:

- jmespath uses `body.translations[0].language` instead of `body.translations.0.language`, and it can also do `body.translations[].language`.

- jmespath doesn't support the "missing" use case

This is not strictly about Ruby vs Python. Having used Pyramid (+SQLAlchemy) and Rails, I think the former is plenty fast enough such that no user cares about silly optimization, while the latter is the opposite.

Loading the Rails environment is just too slow, thus you need a preloader such as Zeus or Spring. And then you need something like Guard to make unit testing semi-bearable. But running the whole test suite would still be too slow, so you need parallel_tests to spread the tests across multiple cores (and multiple databases). And finally you drink the PORO kool-aid and start decoupling your codebase from Rails stuffs, and end up debating with DHH in HN.

In my opinion, the full explanation is too long to be put as code comment, but is just right as the commit message. The best way is to keep the commit message, but add a short comment like:

    // Hack to trigger layout change in latest Mozilla

Then, whoever interested in the hack can read the full explanation from the commit message.

Basically, for simple code with unclear purpose, I'd go with short comment in the code plus full explanation in the commit message. For hard-to-read code with complicated logic, I'd go with long comment in the code. Or refactoring.

Ticket description, commit message, code comment, and the code itself are all necessary to keep the codebase "documented".

Good article, but I think it touches too little about persistence. The trade-off of EBS vs ephemeral storage, for example, is not mentioned at all.

Getting your application server up and running is the easiest part in operation, whether you do it by hand via SSH, or automate and autoscale everything with ansible/chef/puppet/salt/whatever. Persistence is the hard part.

Here's my old school setup:

Deployment: `easy_install -U` from a local pypi

Packaging: `setup.py bdist_egg` and `setup.py bdist_wininst`

Dependencies: declare in setup.py, fetch via yolk

To test if everything works, just create a blank virtualenv and easy_install.

This has been working fine for me for years on Linux and Windows.