alexey_rom tweeted Edward Z. Yang's Databases are categories (based on a talk by David Spivak) the other day. I only just got round to reading it, and having done so, I recommend you do too. The notion of arrows and their properties (identity and associative composition) can be a bit abstract for the amateur/novice category theorist (like me -- hell, I wouldn't call myself more than a category theory fangirl), and mapping this onto identity and joins in databases is a really clever concretization.

There is some nerking in the comments about the relational model really being about Cartesian relations rather than object relations. This is true, but AFAICT irrelevant if viewed from the perspective of object-relational mapping (which you get for free in Postgres and Oracle anyway).

Where I think this is really useful is the world of higher-order query languages. Category-friendly languages such as Haskell have already made a good deal of headway into database APIs; I do not yet know of any projects that (for example) can create a schema from a set of objects and morphisms, but (continuing the example) I could see using that approach to generate all necessary foreign key constraints from an ORM.

When you inspect call graphs, what tools do you like to use? Shark? callgrind/kcachegrind? Something else? What makes a call graph inspector useful?

Waking up with a solution in mind for a leftover bug from last night's hacking session, getting it implemented within ten minutes of being sufficiently caffeinated to work, and discovering that one of the subsequent items on my TODO is actually as simple as I thought it would be.

Suppose you're designing a protocol, and you're deliberating over whether to use XML, YAML, JSON, s-expressions (!) or some other data representation format for it.

The question you need to ask yourself is, "have I written an EBNF definition for my protocol yet?"

If the answer is "no," drop everything you are doing. Yes, everything. Step away from the keyboard. Get a pencil and paper, or go to the whiteboard, and work out your EBNF first.

Then, and only then, you may decide what to use as a data representation. Deciding what data format to use before you have determined the grammar of your protocol is like deciding what language to use before you have figured out what algorithms you're using.

Protocol structure is a design decision. Data representation format is an implementation decision. Do not intermingle the two; it will only end in tears, yours or someone else's. Probably yours.

libevent is the second best thing that has ever happened to me. If you are doing asynchronous programming of any kind whatsoever¹, you should be using libevent or an appropriate interface to it.

(The first best thing that's ever happened to me? Diverting a long walk through Iowa City with ylla into the gym so that she could use the bathroom there. While waiting for her to finish up, I randomly found a newspaper and flipped through the classifieds, which led to me finding an ad for an internship at Integrated DNA Technologies, which I applied for and got; that led to me presenting at CodeCon, which led to my meeting enochsmiles and a bunch of other awesome people who have improved my life considerably, including, appropriately enough, one of the authors of libevent.)

¹Ok, fine, maybe not AJAX.

Google Analytics does some pretty cool stuff, but has one major drawback for mobile web application developers: it's Javascript-based, meaning that hits from mobile devices that don't speak Javascript silently go untracked. Recently, the Analytics team released some code that does server-side tracking; the linked ZIP file contains source and examples in ASP, JSP, PHP and Perl. Why not Python, you might wonder? I wondered too, particularly since an AppEngine project I'm working on is at least somewhat intended for phones (hey, you never know when you might be away from your desk but really want to know if a certain BioBrick exists), so I did a little poking around to see if it was possible to instrument an AppEngine application using server-side Mobile Analytics.

( The short answer is no.Collapse )

Oh, don't get me wrong, I laughed, but it's horrible:

I once saw a C++ filesystem driver that overrode the / operator to mean "append". So you could do something like:

directory = "/tmp/subdir1";
filename  = "myfile.txt";
full_path = directory/filename;

and end up with full_path being "/tmp/subdir1/myfile.txt"

And no, Stroustrup's not going to hell for designing a language that lets people do this. The sheer fact that people can do this means he's already there. And so are we.

By way of sfllaw, a development paradigm I had not previously known about, and tool for developing in this fashion. Holy shmoley. I agree with Bill Tozier, I want this for Python yesterday.

Behaviour-driven development is basically test-driven development on steroids: it takes the principle we like to cite, "write your man pages first!", and hooks it right into the test-driven development cycle, except now you're developing one behaviour at a time, so you can write your tests piece by piece and have individual chunks of the system piece by piece. I like TDD, but sometimes I have to write code fast (and yes, TDD always ends up saving me time in the end, but we've all had those projects where OMG EVERYTHING IS ON FIRE AND THERE'S NOT TIME TO DO IT RIGHT. Behaviour-driven development eliminates your excuses to not do it right: you're producing code as discrete functional units, complete with tests to prove that they are correctly functioning functional units, and you're producing it fast enough to keep management/the client happy. (Clients are sometimes not happy when the first week of work goes into building the unit test suite. Yes, yes, I know, that week of work saves a month or more later on down the line. Some of my clients are no longer my clients for a reason.)

Behaviour-driven development is also a great tool for the "design the UI first" school of programming, and any project that doesn't follow that school of programming is doing it wrong. (Think of it this way: if you're writing a library, design the API first -- that is to say, write the man page first. If you're writing a web application, mock up the user interface, figure out what the damn thing's going to look like and do all your changing-your-mind about how the UI is going to behave before you start laying down AJAX requests.)

Also courtesy sfllaw, a talk by Ben Mabey explaining not only these ideas but the business decisions which motivate behaviour-driven development. This is a really great overview and I strongly encourage any programmer with a pragmatic spirit -- or, even better, an entrepreneurial one -- to block out half an hour of your time to watch it.

Alas and alack, Cucumber is not available for Python yet, and from what I've seen, I really like the way it works. It apparently can be used with PHP, but I really would prefer to avoid PHP if at all possible; my preferred style is just way too functional these days to blend well with PHP. (I've developed a thing for continuation-passing style in the last month or so.) This may end up being the thing that finally motivates me to learn Ruby. I have a little side project going on right now that has a web-application-framework-shaped hole in it, and I had been planning on using Django, but given that it's going to be a Javascript-heavy front end with likely a healthy dose of script.aculo.us, Rails could be a better tool for the job. I'll need to decide if I like how Rails talks to databases; I'm madly in love with the way Django does it and anything less will be a major disappointment, so this is definitely a factor to consider. (Current Rails devs, your input is welcome -- I know very little about your framework. I used to be cranky about the lack of integration with Apache, but there's mod_rails these days and I assume that removes a lot of the reasons I had for bitching.)

And I'd have real continuations. That's always a plus.

Decisions, decisions. But I do like the fact that tools like this exist at all; it's me who needs to get over my uncanny-valley problem with Ruby.

(karnythia, thewayoftheid, tanyad, I'm not talking about the project I'm doing for y'all, this is a different project. So many irons in the fire!)

I'm building a C++ project for an unusual platform, and am having some confusing problems with my libstdc++. For some reason which I cannot fathom, I am getting an absurd number of "undefined reference to..." linker errors for symbols which are indeed undefined in libstdc++.a, but which are definitely defined in libc.a and libgcc.a. Yes, I am linking to both of those. (I know I am, because earlier I was getting some undefined-reference errors to symbols in libgcc.a from the code I'm actually compiling, and when I added -lgcc they went away.)

Any idea what's going on here? Do I need to compile libstdc++ from scratch rather than using the provided binary? (Please, God, let the answer to that be "no".)

ETA: enigmatic ld ordering issues for the lose. Thanks, tangaroa!