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.

Chomsky and Superbowl Party: http://www.thebrushback.com/Archives/noamchomsky_full.htm

Perfect article for those on HN who follow pro sports ;)

This shall be a great fit for the NAT/Bastion instance, since the high-availability setup has a few drawbacks: https://aws.amazon.com/articles/2781451301784570

You shall read this first: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331150

There was a rather significant change to the kernel ARP caching behavior introduced in early 2013: https://github.com/torvalds/linux/commit/2724680bceee94eac39...

It seems to work fine everywhere, except in EC2 VPC, where the arp cache can sometime becomes stale. We too reported this issue to AWS support, but have no idea if they are doing anything about it.

The workaround is to apply a sysctl change to revert to the old behavior prior to the commit. Or to use a subnet larger than /24 to reduce the chance of getting the same IP.

Looking at the examples from the official documentation, I agree with your sentiment. Indeed, the conciseness can cause some confusion to people familiar with the existing scoping rules.

IMHO, it's a good thing if LATERAL is only added as some kind of syntactic sugar. I once had to use LATERAL in DB2 as a band-aid solution for its broken scoping rules: https://www.ibm.com/developerworks/mydeveloperworks/blogs/SQ...

Also from http://stackoverflow.com/a/16553503 by the author of SQLAlchemy:

> Do you have any estimates on how much time is wasted, compared to the rest of the application? Profiling here is extremely important before making your program more complex. As I will often note, Reddit serves well over one billion page views a day, they use the SQLAlchemy Core to query their database, and the last time I looked at their code they make no attempt to optimize this process - they build expression trees on the fly and compile each time.

I feel rather underwhelmed by the performance improvement touted by adequate records. Perhaps someone from the rails community can do something like this: http://techspot.zzzeek.org/2010/12/12/a-tale-of-three-profil...

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.

Here: http://trac.imagemagick.org/log/

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.

With SQLAlchemy, I have done similar optimizations against mssql by changing a few lines of ORM code. Without SQLAlchemy, I imagine I'd have to change dozens of hand written SQL queries.

A good ORM helps you to generate the exact SQL you need.

I am pretty sure SQLAlchemy will translate that into:

    UPDATE purchase SET downloads_left=%(downloads_left)s WHERE purchase.id = %(purchases_id)s;

By the way, the posted code has an off-by-one error, as it should do the checking first before the minus operation. Also, the line `db.session.add(purchase)` is redundant.

EDIT: remove bad sample

> I don't know if you've looked at the graph of a Git repo where people merge instead of rebase

We use merge instead of rebase. Here's a snapshot of the graph:

  | | | | | | | | | | | | | | |                  
  * | | | | | | | | | | | | | |
  |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \
  | |_|/ / / / / / / / / / / / /
  |/| | | | | | | | | | | | | |
  | | | | | | | | | | | | | | |

There are only 4 people working on the repo.

Outside of US and EU, it is quite difficult to find a reputable and affordable dedicated hosting provider. We use AWS extensively in ap-southeast-1, and their new C3 Compute Optimized instances are actually very competitive in price-performance ratio. Previously, we mostly used C1 instances, which were just okay. I never like the M1 / M3 instances.

Besides, in this region with messy peering agreement, AWS network also has the lowest ping time and the fewest hops.

Try replacing /etc/nginx/fastcgi_params with the one from http://wiki.nginx.org/PHPFcgiExample

Also, the packaging is done differently by ubuntu and nginx upstream, so I don't think you can just replace it. They are also bundled with different modules. For example, I have to use the package from ubuntu because the one from nginx upstream lacks the geoip module.

It looks like the Multi-AZ setup is using block level replication such as DRBD instead of the built-in replication:

> Database updates are made concurrently on the primary and standby resources to prevent replication lag.

Makes me feels better for setting up my own pg cluster on EC2 a week ago, which does allow reads from the replication slave. Plus, I can provision <1000 IOPS (provisioned IOPS is damn expensive with AWS), and get to use ZFS.

Sriracha made its debut in Malaysia approximately a month ago, being sold for MYR 21.90 (28 oz) and MYR 13.90 (17 oz) by Ben's Independent Grocer in Solaris Dutamas.

Pretty nice profit margin there, now that the wholesale price is no longer a secret...

> I don't think you can through the postgres/mysql parser in 5ms, much less optimizer, planner, and execution stack.

Yeah... except no. I just set `log_min_duration_statement` to 0, and can see that PostgreSQL typically takes less than 0.1 ms to parse a query.

Quickly parsing a query to come up with an optimized plan is actually a great strength of PostgreSQL, when compared to other RDBMS. MSSQL, for example, has this complex query plan caching mechanism to compensate for its slow parsing. PostgreSQL doesn't need that.

Also, with EXPLAIN ANALYZE, I can see that PostgreSQL typically takes less than 0.1 ms to do an index lookup as well.

You seem to believe that MongoDB has some kind of magic that makes it the only database that can perform sub millisecond query. 10gen is doing a great job there.

I like your comparison of SQL to JavaScript. However, personally I love SQL and always use an ORM. My vow is to never have a line of SQL in my application source code. This is perfectly doable with SQLAlchemy, though not with crappy ORM such as ActiveRecord.

Indeed, I blame ActiveRecord for making NoSQL popular. When your ORM doesn't create foreign key for you, it is a slippery slope to blatant denormalization and eventually NoSQL.

EDIT: The other party to blame would be MySQL with its painfully slow "must-make-a-copy-of-everything" ALTER TABLE.

Perhaps a more advanced camera technology that detects asshole driving behavior instead of speeding? Rich dudes pay to get ahead. Increased revenue for the police department. Improved traffic. Win-win for everyone.

If HelloMcFly originates from the "open lane", I am indifferent to where he decides to merge into the "right lane", as long as he doesn't force anyone to unnecessary slam their brake.

What really piss me off are drivers who move from the "right lane" into the "open lane", and then merge back after cutting perhaps 5, 6 cars.

The gist I get from the link is that the act of "smoothing the wave" will not benefit the one who performs the act, but it benefits the drivers behind the lane. You can't fix the traffic jam in front of you, but you can do your part to prevent one from forming behind you.

And that's why people pass around the link.

In httpd-2.4.x (first released in Jan 2012), the event MPM is already the default on Linux:

https://httpd.apache.org/docs/2.4/mpm.html#defaults

In httpd-2.2.x, however, the default MPM on Linux is prefork, i.e. the "bad" one:

https://httpd.apache.org/docs/2.2/mpm.html#defaults

And those would be the "factory" defaults. Distributions can still put in their own defaults, e.g. Ubuntu 12.04 LTS supplies httpd-2.2.x with the worker MPM.

Anyway, Apache 1.3.x (built-in with something similar to the prefork MPM) + mod_php was the de facto (or only?) way to deploy PHP scripts, as you can just throw the scripts into the htdocs directory and they will just work.

Apache, while not hipster-compatible, is still very much alive.

> I think it may be time Apache itself branches out to a leaner version (with the kitchen sink build available separately) that's as bare-bones as possible with basic functionality that can still be easily extended by modules later.

Right. Here's a binary size comparison between Apache 2.4.6 and Nginx 1.4.1:

    ~ $ ls -l /usr/sbin/apache2
    -rwxr-xr-x 1 root root 580528 Jul 26 13:23 /usr/sbin/apache2

    ~ $ ls -l /usr/sbin/nginx 
    -rwxr-xr-x 1 root root 661264 May 24 07:42 /usr/sbin/nginx

Apache is totally modular. Going from Apache to Nginx would be a downgrade for me.

I think the last one is actually the most important one. The READ COMMITTED isolation level is a bad default. I have encountered many SQL Server databases that are unknowingly stuck with this default, with "WITH (NOLOCK)" added all over the place.

It is kinda funny that you used the phrase "pick your poison". That's exactly my feeling when working with SQL Server. I have never had a "pick your poison" moment with PostgreSQL :)

For general computing purpose (e.g. HTPC + bittorrent + samba), there are always something missing with these small ARM computers. I am holding on to my AMD E-350, especially with the rapid improvement in the radeon driver lately.

Gigabyte Brix with AMD Kabini is going to be interesting, and possibly very competitive in pricing without sacrificing performance:

http://liliputing.com/2013/06/gigabyte-brix-mini-computer-to...