[DrunkAndRetired.com Podcast] Episode 63 – Multicast Car n’ Cdr and Drunk and Retired in Review. Plus! Charlsie gets a Weblog

In this episode, Charles and Coté finally find themselves in the same room to talk about over a year of DrunkAndRetired, multicasting, some listener comments, and all about Charles new blog.

It’s a shortie at 18 minutes.

(This episode edited by Charles.)

Tags: , , .

Join the Conversation


  1. Uber episode, dudes, but now, I’ve got a question. Perhaps for a future show…

    At work, I am working (hah!) on a large systems integration project. Basically, we have a ~10k record billing system that has the capability to make calls via SSH, HTTP, ODBC, etc on save, edit, delete, etc. We have decided to go the HTTP route and write something of an API to our script library, which will in turn perform various actions relating to radius servers, Web hosting on both Linux and Windows, router table editing, and so on.

    My question to the gurus at D&R is: how would you recommend keeping your eye on the ball, and not letting the whole project get out of control.

    Duplication of knowledge is a big scare for me, because I am having to work with tons of bad code as it is, and I don’t want to have to leave that for the next guy to work on this stuff.

    Any and all input would be much appreciated!

  2. Aaron: this is just general advice for the project. Without knowing more details, I can’t add more specific things. That said, I would do three things:

    * Do your work in 2 week iterations where you have a meeting at the begining of the iterationt to plan a list of all the things you’ll do, and then a meeting at the end to “demo” all the work you’ve done. Additionally, you’d have a retrospective to go over what went well and didn’t. This, of course, is Scrum. I’m not sure if you guys are heavy weight enough to need the whole process, but added those 3 practices can help add in enough disipline to make sure things don’t go hay-wire.

    * Setup a wiki for you and other developers to use to document the system, including designs. Of course, you should strive to put documentation in the code as well as much as that makes sense

    * Write as many unit tests as possible. This is difficult, and near impossible, with legacy code, but as you write new code or understand how existing code works, try to write unit tests for it.

    I could pile on more general development practices — like continous builds — but you can layer those on later instead of fitting everything in your mouth at once.

  3. From Wikipedia:

    “Lisp was originally designed for the IBM 704 computer, in the late 1950s. On the 704, a cons cell was represented by a single 36-bit machine word containing two parts: an address part and a decrement part, each 15 bits long. The assembly functions used to extract either part of a machine word were called car (Contents of Address of Register) and cdr (Contents of Decrement of Register).”

Leave a comment

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.