There are two recent trends I really hate: DevOps and the notion of the "full-stack" developer. The DevOps movement is so popular that I may as well say I hate the x86 architecture or monolithic kernels. But it's true: I can't stand it. The underlying cause of my pain? This fact: not every company is a start-up, though it appears that every company must act as though they were.

Read on →

Note, this page originally appeared on the sandman.io blog.

sandman automatically generates a REST API service and web admin from your existing database without requiring any code!

When you look at the most disruptive technology products of the last few years (or months, decades, etc), you may notice that the products themselves seem "obvious". It's almost impossible to believe that there was a time when a service like didn't exist. Or when to find out what friends and family were doing we had to call them and ask. Or when a centralized place to share videos didn't exist on the Internet.

Dropbox, Facebook, and YouTube all share the same quality: in retrospect, they seem obvious. In fact, some would say that they didn't actually do all that much. Personal profile sites already existed. Wasn't it just a matter of time before someone made them pretty and easy to use? And posting videos on the Internet was never difficult, so it's inevitable that someone would eventually create a centralized place for it.

In a way, it's true. These services took an existing (or "near-existing") technology and productized it. The key, though, is that Dropbox, Facebook, and YouTube fulfilled desires we didn't even know we had. Each of these web giants evoke a "that's it"-style shoulder shrug today, but they noticed opportunities where no-one else did. They grew big by seeing need where it didn't yet exist.

Enter Sandman

Sandman (on GitHub here) often evokes similar reactions when I describe it to people. "That's it?" they wonder aloud. "Doesn't something already exist to do something like that? Surely someone must have already done this. It seems so obvious!". Sandman, which builds a web admin and REST API service on top of your legacy database without requiring any code, seems like such an obvious product that most people assume it already exists. In fact, many people say that they had the same idea, but never followed through.

To be sure, Sandman is no technological marvel. It takes two technologies which are well established, ORMs (Object-Relation Mappers) and code generation, and marries them in a simple, straightforward manner. The result, however, is nothing short of magic.

Your Database, In Your Browser

I love the look on people's face when they first run Sandman. They enter the details of their existing database, hit enter, and bam!, Sandman has opened a browser tab pointed at their new admin site. There in front of them is all of their data, waiting to be manipulated.

For technical managers, other groups within the organization, and even external clients, the ability to add, edit, and delete information buried deep within an enterprise database is unparalleled. Forget about clunky GUI tools that connect to a single database and make you use SQL to add data. Just use your browser to fill a simple form, where most data is already auto-filled for you, to make the change to your data.

"It's stored in a database," is a phrase that probably evokes a shudder from most technology managers and programmers. With Sandman, hearing that something is "stored in a database" is the same as hearing "you access that through a beautiful, easy to use web tool that has been tested by hundreds of people". Sandman really does "free" your data.

Sandman Makes Things REST

When I'm showing Sandman to a developer, I ask them to curl a simple URL after they've connected Sandman. Without fail, their eyes light up when they realize the clunky, over-complicated legacy database (the kind that exists in every enterprise) now has a super-clean REST API.

"Imagine how easily we can run custom reports," they say. "Better yet, we can have Sandman generate them on-the-fly and simply give our users the URL of the results!" Interacting with legacy databases in the enterprise will never be the same.

Rather than having to find and install drivers and write different code for each type of database they connect to, developers can simply program against a single, RESTful service using battle-tested open source libraries. The amount of code that Sandman makes redundant is shocking. Sandman changes the way that developers create services, for the better.

Surely This Already Exists!

By now, some readers are thinking, "Surely this technology already exists! It's so obvious!" It does now. Sandman represents the effort required to marry ORMs with code generation to automatically, with no coding required create a REST API and web-based admin interface. Before Sandman, this "obvious" service really didn't exist. After Sandman, nothing will quite be the same.

Read on →

I'm sitting in the airport with my lovely wife (who's watching me type this) waiting to board my flight to Montreal. I'm quite excited to attend my first PyCon, indeed my first large conference ever. If you're going to be there, let me know! Hit me up on Twitter (@jeffknupp), email me at jeff@jeffknupp.com or text me at (419) 455-6877. I'll be in town until Sunday afternoon, so please get in touch! Looking forward to meeting a few readers...

Read on →

When someone asks why the if __name__ == '__main__' idiom should be used, I say it's because it makes turning your "script" into a "library" a seamless act. Novices often write a series of one-off Python scripts that exist only as long as it takes to finish and run them. More seasoned developers have accumulated a set of libraries they've written over the years.

Last night I needed to properly parse a fully-qualified domain into its constituent parts (top-level domain, second-level domain, sub-domains). I found one library that looked promising, but it used a hard-coded list to represent all of the possible TLDs. The problem is this list changes with some frequency, and I needed to get it right.

So, fine, there's no third-party package that exactly fits my needs. Rather than just bolt on the domain parsing functionality to the application that required it, however, I turned it into a first-class citizen: a library (more accurately, a Python package). Heck, I even released it with unit tests and hooked it up to TravisCI.

Why would I take the extra time required to make this a reusable library? Two main reasons: first, this is a straightforward problem that should be solved once and never thought of again. Any time you encounter situations like that, do the right thing and write a small library. Second, because it's a general enough task, I wanted to make it available to others so that they didn't need to keep solving a problem that's already been solved.

Solved Problems

As developers, we waste a ton of time on solved problems. Whether it's due to "Not Invented Here"-itis or general ignorance, I've seen entire systems duplicated by different teams in the same organization. I would argue that being able to sense when a problem likely has an open source solution is an integral part of being a "good" developer.

So in the interest of saving everyone a bunch of time, I wrote the package, released it, and am happy to accept bug reports (and will fix them). What's more, the library becomes another tool in my tool belt rather than a few random functions in a script I'll never use again.

As developers, we should be working together on the mundane stuff so that we can all go off and work on the cool stuff. Please, don't make other people solve your problem over and over again. Do it once, make a library, and release it to the world. You'll save all of us a lot of time.

Read on →

Recently, I've seen a number of nice-looking blogging platforms pop up. Each basically let's you write your content in Markdown, shows you a live preview, and can keep posts unpublished until you're ready to bestow them upon the world. They all look nifty, but I'll never use them.

Why? I've been using blug, my Python-based static blog generator, to generate this site for years. blug was designed with a certain workflow in mind (mine) and has grown since then. I have a private fork of the public blug repo where I have all my settings and special templates. That repo is the one that sees the most love (and I'm long overdue for a sync between the private code and the public). But more importantly than blug being tuned for how I work, blug gives me something other blogging platforms don't: control.

Read on →