Variables and Observations

The Linux From Scratch project is very much alive and well in 2016. What began in the late 1990s as an educational process for building a completely customized GNU/Linux system from source code is still very much relevant today. What you will learn from going through the LFS book will augment your linux knowledge like nothing else. Give it a try, you won’t be disappointed!

Deployment of web applications can be a frustrating endeavor when trying to make the various pieces of a stack work together. Development environments are typically setup with light weight test web servers and file-based databases to simplify debugging of application code during development. This means that once your code is in good shape locally, you still face various challenges moving it from your workstation to a production server. One of the pesky issues I always face when moving to production is getting the app to talk to the database. To help verify that my production database configuration is working properly, I wrote a basic flask app, flask-db-test. It’s a simple app presenting a form which exposes a single database model, allowing you to see if reads and writes are working.

Pedantic SQL is a style guide and code beautifier for ANSI SQL intended to make SELECT statements more readable. I use the term ‘beautifier’ loosely because one may well argue that no amount of formatting will be sufficient to make SQL look pretty. I call it ‘pedantic’ because it is insistently rigid in how it is applied. But this rigidity is what makes the resulting queries readable. The lack of consistency in SQL writing styles makes it entirely too difficult to read others’ queries. A lot of bad practices have evolved which detract from query readability and extensibility. A query should be understandable at a quick glance. Following this style guide will make your queries a lot easier to grasp. It will also make them a lot easier to extend or build upon later.

Don’t call me a ‘5:01er’, For one thing, I leave at 4. If that bothers you, feel free to stop by my office any day at 7am and we’ll talk about it.

Everything I have to say about the differences between a good manager and a bad one can be summed up with this simple distinction: “A bad manager makes you work, a good manager lets you work.”

Last August, Max Schireson, the CEO of MongoDB, announced his resignation in a refreshingly honest blog post explaining that he wanted to spend more time with his family. Despite the fact that Schireson’s decision appears at face value to be the obviously correct choice, his announcement was quickly propagated from tech circles to the mainstream media, and served to rekindle various ongoing debates over work-life balance, gender equity, competitiveness in the global economy, and the role of class privilege in the top echelon of corporate power structures. While it’s a little unfair to Mr. Schireson to overload what is essentially a private decision with a heap of weighty social issues, as a public figure he is surely used to such attention and since these are very important issues, it is still valid to use his example to discuss them in these contexts.

In this post I will describe the workflow I used to generate this blog.

Today I am extremely happy to announce the release of version 1.0 of mlelr (pronounced ‘mealer’, of course), a C program for Maximum Likelihood Estimation of Logistic Regression Models that has been in sporadic development for over 12 years. For everything you need to know, read this guided tour of mlelr which accompanies the source code.

The term ‘big data’ sounds infantile, like ‘My Computer’. It should hurt the ears of anyone with any appreciation of Style. This is a buzzword that deserves to be cast into the dustbin of discarded buzzwords as quickly as we can possibly do so. On the way, I’d like us all to consider that maybe ‘medium data’ isn’t getting all the attention that it deserves.

Meetings are the uncomfortable fact of corporate life that we all love to hate. They are so often maligned because they are perceived to be a waste of time—nothing seems to get accomplished, they run too long, the right people are not present, there is no clear agenda, and most importantly, meetings interrupt the normal flow of work for everyone involved. It does not have to be like this. If executed with efficiency and respect for everyone’s time, meetings can actually be the productive problem-solving gatherings they are supposed to be. This can only work, however, if you help foster a strong organizational culture to ensure that meetings do what they intend with as little collateral damage as possible.