j-kidd

And here's a great post that provides some insight on how much effort has been put in by RDBMS vendors to handle locking:

http://stackoverflow.com/a/872808

After reading the article and your comment, I went to watch "Why we think it's OK to cheat and steal (sometimes)" on youtube, while downloading both his books with bittorrent.

I think it is fairly reasonable to expect such downtime for major version upgrade. Is there a DBMS vendor that can promise you otherwise?

Not in my case, the client doesn't have the resource, and we don't have the expertise. At the end, I became somewhat of an expert in SQL Server (i.e. I know how to start SQL Profiler and read query plan), at the cost of important functionality not delivered to the client on time.

If possible, try not to go down the "support Postgres as well" route.

I was in your situation, where client wanted SQL Server since they already have the license. During development, I use PostgreSQL instead, to "support Postgres as well".

At the end, roughly one-third [1] of the total development effort was spent on overcoming SQL Server's limitations, things that you would never have to think about in PostgreSQL.

So, try telling the client that they already have PostgreSQL license as well, with unlimited future upgrade.

[1] This figure was pulled from ass. The actual productivity loss could be more due to similar reasons outlined in http://news.ycombinator.com/item?id=3784750

Modern stack is just not compatible with Ubuntu LTS. You can either pull stuffs from ppa, build them from source, roll your own packages, or, heaven forbid, choose a better distro.

> The main thing one needs to think about when coding an app in a load balanced environment is that there’s no guarantee that request ‘n+1′ is going to land on the same server as request ‘n’, so you need to handle sessions in a centralized/db manner so that the cookies in the browser link you up to the proper session regardless of what server you hit.

Instead of doing it in a centralized/db manner, Beaker allows sessions to be distributed client side:

http://techspot.zzzeek.org/2011/10/01/thoughts-on-beaker/

It was one of the best things I learned last year.

> Surprisingly, almost no one wears their headphones all the time while coding.

The author should try reading Peopleware. Here's an excerpt from Chapter "Bring Back the Door":

"In response to worker's gripes about noise, you can either treat the symptom or treat the cause. Treating the cause mean choosing isolation in the form of noise barriers -- walls and doors -- and these cost money. Treating the symptom is much cheaper. When you install Muzak or some other form of pink noise, the disruptive noise is drowned out at small expense. You can save even more money by ignoring the problem altogether so that people have to resort to tape recorders and earphones to protect themselves from the noise. If you take either of these approaches, you should expect to incur an invisible penalty in one aspect of worker's performance: They will be less creative."

Gitology is definitely a sunk cost, because of all the concepts you have to learn which are not applicable anywhere else. Here's a good example of what happens when a programmer learns git as the first DVCS:

http://groups.google.com/group/wtforms/msg/8ffaf89083f775a4

Best tool for the job, can't agree more with that. We have a team that insists on using git when:

- it is just a small team (less than 5 devs)

- there is no github, just a locally hosted gitorious instance (proprietary project)

- the lead dev who picks git is using Windows half the time

- there are less technical people who need commit rights (e.g. changing reports layout, changing CSS, etc)

I believe the "git already won" mentality (which is very apparent in the comments of both OP article and HN) get these people to pick git over mercurial. And once they become familiar with git, they won't let go, due to the sunk cost of learning gitology[1].

[1] http://jordi.inversethought.com/blog/on-gitology/

This is exactly what the OP warned against. When the marketing people find out about all these "near products" you guys churned out in a day, say goodbye to sane development schedule.

Game-winning 3-pointer. That's it. I am now supporting any team he plays on.

I have been running unbound for a month, and there is no noticeable difference in resolving time. This article provides a good read: http://linuxmafia.com/~rick/googledns.html

The moral of story here is that if you have an expiring contract, you better hope your next opponent would be the Nets ;)

I am a Nets fan for 12 years and hate the Knicks. Today I followed NYK vs MIN just because of Jeremy Lin. Game tied, 24 seconds left, and he got the ball in his hand. I could have became a Knicks fan if he made that layup. This is insane.

Nets spent billions to build a new arena. Knicks got Jeremy Lin.

Virtualenv is a pragmatic approach to solve actual problems during both development and deployment. As long as you have a python executable (don't have to be installed system-wide) and the virtualenv.py module, you can create a virtualenv. How is that "a whole ecosystem"?

Can you elaborate on that? The more I use Python, the more I find it to be a well thought out language with a very consistent feel, allowing me to write code without thinking. Well, except when it comes to decorators. How would you propose to improve the syntax?

> If something is available legally and at a reasonable price (by which I mean not only available second hand for £100 as a collectable, rather than "99p for an MP3, that's outrageous" etc...) I either buy it or accept I won't have it.

You are assuming the world is full of honorable people like yourself. Unfortunately, that's not the world we live in. In the words of Scott Adams:

"The least effective system ever invented is something called the honor system. The theory guiding this system is that people are not huge weasels."

Sorry, I missed the point about "caring more as a local". I concur with that.

Get off your high horse. Being American doesn't automatically make your code better. As a "foreigner", I recently had to deal indirectly with American developers (to integrate our product with theirs at the request of the client). They charge 100K USD for something that only needs 2 man days, didn't code to the specifications (set by themselves), and took forever to fix any problem on their end.

Bad developers exist everywhere.

Your comment, in particular the part about SQLAlchemy, reads a lot like the blub programmer.

Semicolon makes it possible to do jQuery-style chaining with the least noise. I think frequent-backslash is uglier than always-semicolon.

I don't get it. Why would one mock the database connection when the thing to be tested here is a stored procedure?

> Dynamically typed languages basically have the problem that they can't get decent IDE support, ever.

PyCharm.

I was debating myself whether to spend $50 for PyCharm, or $60 for Sublime Text. Then I came to my senses.

> SQL is much more versatile and flexible than objects/structs

SQL isn't even turing complete. How can it be more versatile and flexible than your programming language of choice?

> How would you expect an ORM to generate a "dense" query like this with it's simplistic view of things ?

In SQLAlchemy,

    cls.query.filter(<some_condition_on_another_field>).update(dict(one_field=value))

> The developer who can't use and understand SQL really has no business going near the ORM.

Absolutely. First we have developers trying to use ORM (a.k.a. HideSQL) to avoid learning SQL. That fails. Now we have developers trying to use NoSQL to avoid learning SQL. This "avoid learning SQL" thing is shaping up to be a fantastic anti-pattern. I wonder what's next.

> Ultimately, people dislike ORMs for the same reason they dislike things like CoffeeScript

This is not a good comparison. With ORM, you started with Python/Java/C#/etc + SQL, and ended with Python/Java/C#/etc + SQL (a lot less). There is nothing new added.

With CoffeeScript, you started with JavaScript, and ended with JavaScript + a perlish language.

Also, in Debian, you have one guy maintaining a bunch of core packages: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745#310

If you deploy Debian/Ubuntu on servers, your fate is pretty much dependent on this guy, unless you roll your own packages, which wastes precious time.

> Lars has promised to “sweet talk” the other browser vendors

Sweet talking is no evil!

> Roughly half of that is entirely closing braces/parens...

This is good, as it improves the code's readability.

> ...but the other half is actual code reduction/simplification, mostly from loop comprehensions.

This may not be good, as it can reduce the code's readability. List comprehension should only be used moderately, else you will end up with this:

http://blog.garlicsim.org/post/3504711416/nastiest-python-li...

Also, with python, at least you gain performance advantage by using list comprehension.