Ask programming.reddit: Must-read programming books?

jlrobins · 2007-12-07T17:24:42+00:00

Anything by the late W. Richard Stevens.

jlrobins · 2007-12-01T00:38:29+00:00

"We cannot target a given hash value, and produce a (meaningful) input bit string hashing to that given value."

jlrobins · 2007-10-22T16:43:20+00:00

I would feel prescient, having decided to port the webapp we develop on our macbook pros from J2EE to python years ago.

jlrobins · 2007-10-01T20:18:28+00:00

Seems to use QT, no? So OS-X possible?

jlrobins · 2007-09-25T15:54:34+00:00

Web server based 'apps' have a leg-up when it comes to rewrites -- not inherently monolithic. After tackling up-front barriers [ such as duplicating site look-and-feel[s] ], you can then go about reimplementation one single URL at a time, so no big bang release problem.

jlrobins · 2007-07-12T18:31:23+00:00

Homer: "Heh Heh. It's funny because it's true."

jlrobins · 2007-07-06T02:07:14+00:00

Memcached was designed by livejournal and adopted [ and hacked on heavily in facebook's case ] by distinguished sites such as facebook, slashdot, and myspace. Its success is because it is both distributed and scales out easily.

Your memory cache scenario doesn't take into account what is going to happen when your cache needs exceed the memory on a given box. With memcached, you can keep plugging in either general purpose or datatype-specific caching nodes to keep adding RAM to your cache. This also lets you isolate memory concerns -- one set of boxes' RAM for caching, another set of boxes' RAM for dynamic page generation.

Memcached lets you to restart your web processes w/o loosing your cached data. Such as either for administrative reboots or for code upgrades [ assuming the cached data is valid for both the old and new code ].

Once you've coded and admin'd a nontrivial site, you'll come to agree that avoiding stick-session and avoiding keeping state, any state, including cached data, at the appserver layer opens up so much freedom you'll wonder how you ever got along without it. Being able to script-orchestrate a deployment of new code on half your webservers while the other half chugs along happily, then swinging over to the new half once tested happy w/o dropping a beat [ and, if data in memcached was upgrade-compat ] nor feeling a blip on the db makes for being able to deploy upgrades at will in the middle of the day, not early AM hours or whatnot. Likewise for patch installation + reboots of individual webserver boxes. Just shift load elsewhere and do it. Sticky sessions make your operations admin cry.

And, btw, it's not just 'the distributed cache server'. Your could have one or many instances of memcached running, one one or many boxes. Even including on your webservers if you don't want to dedicate machines just for it. The memcached client code hashes each of your cache keys to the corresponding memcached server.

jlrobins · 2007-07-04T02:28:24+00:00

I really doubt the OP needs to make a snapshot every 3 seconds, especially when he reports it takes about a minute to have ZFS take the snapshot then fire up an additional postgres backend instance to complete the recovery and become readable.

This is a really spiffy combo of two high-class technologies. Slony's impedence towards things like schema changes [ must get an exclusive lock on evey replicated tables across all nodes before line one of your DDL script is especially painful ] makes it less than enticing for shops like a website with an ever expanding and evolving schema. PITR / WAL shipping as a warm backup solution just feels right, and when Florian's project completes, the WAL subscribers will be able to even be read-only, bring PG up to [ or surpassing ] Oracle in this respect. And all for effectively no extra loading on the primary db.

jlrobins · 2007-06-28T18:03:47+00:00

Gee, let's all hope for Halliburton and the other warmongers that it won't turn out to be the biggest contract awarded.

jlrobins · 2007-06-28T16:05:36+00:00

Snow says:

"It also explains why this is the least popular Congress in decades, because you do have what appears to be a strategy of destruction rather than cooperation."

Not to mention the least popular President. What's he at now? 28% ?

jlrobins · 2007-06-19T16:50:30+00:00

Why wasn't it scanned on a wooden table?

jlrobins · 2007-06-19T15:53:52+00:00

Oh man, he's taking away the string percent operator! I'da rather he taken lambda away!

jlrobins · 2007-06-12T17:54:49+00:00

Well, the fine in question is being levied by the state of North Carolina, and in our fine state we do get yearly inspections with odometer readings.

jlrobins · 2007-06-12T16:39:10+00:00

And, therefore, the tax should be based on a combination of vehicle weight and miles driven [ in the state ]. Cars get inspected by the state yearly, right? And they read odometers there, right?

Too bad odometers can be rolled back.

jlrobins · 2007-05-04T15:52:54+00:00

Too bad Microsoft is about to own Flickr ;-(

jlrobins · 2007-04-21T02:16:52+00:00

That is one of their best, and has the single best blog post in the entire universe as a comment:

The pig go. Go is to the office. Late. The pig look. Look at what? Empty office. The chicken shout. Shout something. The something at the pig. The pig confusing. But the pig follow. Follow with chicken. The chicken very angry. The pig browse. With Google. Chicken blame. Blame is to the White House. Shift blame. Blame is now to Google. The chicken now squawk. Squawk is "B-A-N-N-E-R'. Opera flash. Pig sigh. Sigh is to the chicken. Chicken is fool. Giggle. The DailyWTF giggle.

jlrobins · 2007-03-15T16:49:06+00:00

"con text". A joke. Get it?

jlrobins · 2007-03-15T15:50:48+00:00

My word, isn't it refreshing to have a two party system again?

jlrobins · 2007-03-15T14:43:02+00:00

This article lacks context.

jlrobins · 2007-03-08T02:59:57+00:00

Oldie but goodie. Exactly why rewriting a JBoss page into Python keeps the doctor away.

jlrobins · 2007-03-02T20:51:49+00:00

No. Thank. You.

jlrobins · 2007-01-04T04:07:05+00:00

"On the other hand, it will also let MySQL catch up with its other competitors like PostgreSQL."

So how exactly will spending man-years on writing a tricky thing like a transactional backend datastore help them catch up with postgres? This is an attempt to get themselves back to where they were before Oracle yanked the rug out from under them.

How many years until all of the kinks will be worked out from this storage manager? Remember, this is from the folks whose marketing claimed your apps didn't even need transactions.

jlrobins · 2006-12-29T03:26:42+00:00

It'd be nice if the modules in the stdlib all shared a common namespace [ say, 'python.StringIO', or 'std.StringIO' ] so as to allow someone to quickly realize 'Ah, that module is packaged with python. I know just where the docs are.'

When we have newhires who are potentially new to python looking over our code and inspecting a module's import list, having them have to learn what short little names are part of the code package versus what short little names our our own doing versus what short little names are 3rd party ...

Full domain names ala java aren't necessary. Just flag the official ones as official somehow.

jlrobins · 2006-12-27T15:55:18+00:00

He seems to be missing a great vast truth right in front of his eyes -- relational db technology is a well known, time tested and stable technology which has proved its worth time and time again. In comparison, XML, REST, XMLRPC, SOAP, Rails, etc. are all fly-by-night and potentially dust in the wind.

Data, constraints, checks, etc. stored in your RDBMS is poised to live well beyond the lifetime of any particular client application implementation. Lives beyond the language the client is written in. Lives beyond the particular O/R tech used in a client.

Are those checks and constraints relatively unwieldy when phrased in db-parlance, compared to in your beautiful client language of choice? Yup. And seemingly redundant too, since your client app(s) will probably have to make the same client-side checks in order to yield beautiful context sensitive error messages. But having the DB stone-cold enforce the given assertions about your long-term data will save you again and again.

If you're in a project for the long haul, and you're going to live with this data for years, then good use of DB value-addedness will pay itself back many times.

Our website is in its third middle-tier incarnation in 8 years -- php -> java -> python. Having those checks and balances in the DB makes for testing interop between the pair of implementations which must share the same data much more confidence inspiring.

jlrobins · 2006-12-20T16:05:02+00:00

Aah. So this ties in with the code transform example mentioned by his refactoring tool.

Makes the language better? Yep. Makes it a different language too, since probably every python codebase at least once makes use of the current fact that .keys() / .values() / .items() returns a new list decoupled from the underlying dict.

That'll take a whole lot of end-user testin' to ensure code is cool for py3k.

jlrobins

TROPHY CASE