LegitimateSounding.com

PostgreSQL is an amazing and extensible database, providing a ton of functionality. One of the best parts, in my opinion, is the ability to add additional programming languages to create stored procedures. This allows developers to move business logic deeper into the database itself. Unfortunately, this is often very hard to test in isolation.

The current state of testing in PostgreSQL is to run make installcheck, which runs a myriad of SQL commands living in files in the sql directory, with the results checked against a bunch more files living in the expected directory. This works, but is often-times difficult to add into existing test suites, which ultimately leaves holes in testing.

All databases consist of a handful of operations: Create, Read, Update, Delete, and sometimes Scan. If this sounds a lot like reading and writing files on a disk, it is. At their core, databases need access to both data and metadata. An operating system provides this in a very basic form of a filesystem. As a simple approach to building a database, the reliance on a filesystem is key, as it provides a lot of metadata, and allows us to move forward with one less layer to deal with.

There comes a time in every community where members of that community must step back and take a look at how they appear to behave to those outside of them. The operative word is appear, and that's the part I want to focus on.

In the first installment we dealt with creating collections and deep inspection of the JSON object once it was inserted. In this installment, we will be covering saving the data and building WHERE clauses from MongoDB queries in order to retrieve the data that we've written.

I had a crazy thought. Don't all good ideas start with that phrase? Well, this one was suitably crazy: why not build my own version of MongoDB right on top of Postgres? It sounds a little far-fetched, but in all honesty it's pretty simple.

I love the Arduino; it's one of the most awesome technologies I've seen in quite a while: its heart is a gorgeous microcontroller with a plethora of inputs and outputs. I also love Node.js: its event driven model is very elegant and the fact that it's Javascript makes it pretty easy to develop in, even for the novice.

Multiple requests suck. Let me rephrase that: multiple requests really suck. The more requests you make, the more connections that are made, the more data that is transfered, the longer it takes to for your application to become responsive. Servitude helps you reduce the number of requests made for CSS and JavaScript down to one and injects it into the DOM for you in the order you request -- faster requests mean more responsiveness; more responsiveness means a better application.

It's been a few months since I released Bricks.js, and I figured it was finally time to talk about it. Bricks is a fast, and extremely modular web application framework built on top of Node.js that works a little differently.

I had been meaning to spend some time with Judy Arrays but I hadn't quite found a good reason to explore them to their full extent. While attending NodeConf I caught Marco Rogers' talk on C++ bindings for Node.js which gave me a fantastic reason to spend some time in the Judy world. A few days later I came up with this project: Judy Arrays in Node.js. Unfortunately, it's been about half of a decade since my last foray into C++, and at least a decade and a half before that via academia, so while all attempts have been made to adhere to best standards of Node.js add-on development, I cannot guarantee that everything is 100% correct and that there are no memory leaks.

It was summer and I was craving pork. Not just any pork, but Tails and Trotters pork -- fed with hazelnuts and absolutely delicious. I somehow convinced my lovely partner-in-crime to split the cost of half of a pig; there was only one problem, we had a freezer but its pedigree was entirely unknown. Rather than take a chance on losing a whole lot of yummy a plan was hatched: we'd bring the freezer into the 21st century (or at least the monitoring of it).

Introducing my first Github repository: node-date-utils. During redevelopment of my freezer daemon (more to come later), I found a couple of missing Date methods. This is an attempt to fill some of them in.