jefffoster

They are both algorithm books and the initials are the last names of the authors.

AHU is "The Design and Analysis of Computer Algorithms" by Aho, Hopcroft and Ullman.

CLR is "Introduction to Algorithms" by Cormen, Leiserson and Rivest

When you're a development manager and someone offers you some extra developers what'd you say? If you say no to more developers, then it's very easy for your decision to be blamed for the project failings. At some point, the decision is probably more about politics than increasing the likelihood of the project succeeding.

There's an chapter in "Surely you're joking Mr. Feynmann" about something similar. Students in Brazil achieved fantastic marks in exams, but were unable to translate memorized formulas to practical use.

The chapter is online here http://randomgraphs.blogspot.com/2009/06/feynman-on-educatio...

http://common-lisp.net/project/cells/ (Cells) is a data flow language where values are determined by formulas similar to spreadsheets.

So instead of a spreadsheet with a programming language, go the other way around!

The author is a headhunter and wrote a great guide to getting a quant job (www.ieor.columbia.edu/pdf-files/Paul_Dominic.pdf [PDF]). I guess that skews his perspective a bit in what he's looking for (numerical algorithms and C++). I'm guessing the situation isn't that bad for companies looking for plain old Java programmers. Finding graduates experienced with C++ and numerical algorithms is substantially harder!

When I'm working in a static language such as Haskell I very rarely write traditional unit tests, instead preferring to use QuickCheck (http://en.wikipedia.org/wiki/QuickCheck). I like the adversarial nature - I specify invariants and I challenge the computer to prove me wrong! This seems more likely to find bugs than me writing my own tests.

Wanting to find bugs seems to be an important factor in writing quality tests. It's easy to write soft tests when the same person writes the code and does the test. Maybe that's why pair programming and TDD seem to go well together, as the other person is more motivated to try and break your code?

"Be professional" would be a better aim.

In my opinion, the most important thing for code is for the developers to actually care about it. Whether you test first, test later, or just simplify the code until it's obviously correct [1] it really doesn't matter, just care enough to want bug free software.

[1] "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." (Tony Hoare)

Compressed Sensing is exciting - using a sequence of low res images to obtain a higher resolution sample. It was discussed in Wired (http://www.wired.com/magazine/2010/02/ff_algorithm/all/1) together with a compelling example (minimizing the time of a young patient in an MRI machine)

The big thing is that F# has graduated from MS Research and is now available as Visual F#. This is important as it could make functional programming more mainstream (or at least into the hands of more people).

The creator of the room can set various feeds which show up as comments in the room. You can do exactly the thing you describe by clicking the Ruby tag, grabbing the RSS feed and selecting it as a feed for the room.

http://antirez.com/post/redis-virtual-memory-story.html is an interesting contrast to this story.

A few years ago I used rentacoder.com (now known as vworker.com) and made about $10K in 3 months. I made the majority of the money from doing a good job on something (generally at a very low price) and then getting repeat business from outside the bidding system.

Most fun project was writing some software that showed prospective patients what their teeth would look like after having their teeth bleached!

Minor correction, you mean Feathers. It's a great book!

There's a good video available "How To Design A Good API and Why it Matters" by Josh Bloch. There's a selection of slides to accompany a version of the talk here http://lcsd05.cs.tamu.edu/slides/keynote.pdf [PDF].

Link to previous discussion

http://news.ycombinator.com/item?id=318827

My favourite is "you can't polish a turd" though I don't think it really qualifies as an engineering term!

using isn't quite the same as try/finally. using is a construct explicitly for freeing resources. With a try/finally construct it's up to the user to fill in the finally block correctly.

Couldn't agree more! Most of the time I've heard people say "this code sucks" it seems to mean that it's formatted "wrongly" or that the person is too lazy to understand it, or it's not written by them!

From myself (telling the story seems to give a lot of feedback) and from readers. And sometimes the flames of Reddit even contain useful information!

Blogging is definitely not top of the queue, but if I'm going to go to the effort of learning something new, I might as well write some notes on it and the extra effort of putting it into a blog seems worth it for me.

I started blogging purely as a way of improving my coding skills, and I was pretty cynical about it. From blogging I've had good feedback about how I can improve, and the mere act of keeping a blog has kept me motivated enough to keep learning and keep posting. In my opinion, definitely worth the cost.

Have you seen http://www.spoon.net/? It seems very similar to the StackVM idea.

There's a couple of things the Haskell community are doing that should help address this problem. The Haskell platform (http://hackage.haskell.org/platform/) provides a tested collection of compiler and standard libraries. There's also a Google Summer of Code proposal to improve Hackage (the library repository) to make it more social. See http://cogracenotes.wordpress.com/hackage-proposal/.

I'd really like to understand more about markets and how they fit together. It sounds like you've got a better understanding than me, can you recommend any good books?

(I'm the author of that thing)

The search chapter in PAIP has an excellent description of A* search, beam search and best first search that shows the relationship between the algorithms. The code is available on-line (http://norvig.com/paip/search.lisp).

Can you give some examples of the "harder problems that are intractable with traditional OO mechanisms"?

In a previous job there was a system similar to JIRA that sent out e-mail notifications on new bugs and so on. Each employee was also represented by a ticket with contact information and so on.

Less than a week into starting this job, I received an automated message saying that "Ticket 1234 Fred Bloggs has been deleted". At the same time, the guy got up, left and never returned...

See http://en.wikipedia.org/wiki/Rule_of_72

From their white-paper apparently DBMS systems spend 35% of their time doing buffer management, 17% doing logging, another 19% doing latching and finally 21% doing locking. This leaves only 7% for "useful work". In comparison, VoltDB has 95% capacity for useful work.

Reads even more like marketing blogspam!

I found that running

  lein deps
  lein uberjar

Resulted in a clean build for me. I guess you could also stick the JAR in the local maven repository too - flyingsaucer lives at https://xhtmlrenderer.dev.java.net/

As a side note, you could run Emacs in daemon mode and connect to it with the client. See http://emacs-fu.blogspot.com/2009/02/emacs-daemon.html for more details. This way you only have to pay the startup cost once.