you doody head you forgot to clean up your EventStruct!

Last night I went out to get some dinner and as I sat in the drive-through waiting for the unbridled joy that is Cain’s chicken I listened to the radio. WOSU’s All Sides had a piece about child poverty and mentoring. It was interesting and thought provoking, one of the guests said something that rang true and made me think. (Paraphrasing because the audio is currently unavailable) He started to realize that the kids were excited to have him come talk to the class every week, not because they were interested in his stories about the Post Office, but because they wanted to know that someone cared about them. It was a powerful thing to remember, that children need to know that someone cares for them, and that not all children are that lucky.

In writing this blog one of my favorite memories is doing the research to write the teaching post. It reminded me of the heady days of my youth spending hours inside of the amazingly good QBasic help file trying to get something to work, stumbling and bumbling, put beaming with pride and a giddy happiness when I finally got the program to work. These days the amount of programming languages geared towards teaching have only expanded, and systems like Alice put LOGO’s turtle graphics to shame (although I still love that LISP-laden turtle).

This started the old gears turning in my head, and although this thought is pre-pre-alpha, I thought I would get some feedback and just jot down what I’m thinking. What if there were an after school program for elementary school aged children where IT professionals donated their time and talent to helping kids learn how to program. Children need mentoring, the IT community has a wealth of talented and caring people, let’s put these two things together and see if we can do some good. The logistics of this are a little daunting, but I want to lay out the reasons why now is the right time for just such a program.

Programming is the new literacy. Don’t believe me, here is an article entitled Programming is the new literacy. As we move forward into an increasingly wired future, programming, scripting, mark-up, are going to become skills that are normal to have. Children are already more “plugged-in” then ever before, the benefits of understanding the machine they’ve been using since they were in diapers is apparent. As the information economy continues its march into the 21^st century, people will need these skills. From a simple formula in an Excel Spreadsheet to whipping up a ruby script to do batch processing, these will become the differentiators of tomorrow, helping people achieve.

Hardware has never been more accessible. Moore’s Law is a thing of beauty, I just bought a more than capable HP refurb for $150 to act as a media server. OLPC has shown that putting affordable computers into children’s hands is possible, and it looks more and more likely that school districts in the Industrialized Nations will be following suit in the next decade or so. Companies routinely donate their old computers which means that if $150 is too much (which it is for a lot of low income families) then you can get a donated computer free. Children can also access computers at libraries and schools for free.

Software has never been more accessible. The number of languages specifically targeting teaching has only been growing. If you haven’t already, go read the teaching post, it is a round-up of just a handful of the neat and nifty software meant to help kids learn to program. The learning curve has never been gentler, you can go from a learning language like Hackity Hack (which is based off of Ruby) to the full Ruby language fairly easily, and from there you can explore the whole world of Ruby development from Rails to Unicorn and back again.

Programming is about more than computers. Although the immediate goal of learning to program is to instruct a computer in how to perform a given task, the side benefits are immense. Programming teaches children a structured way to solve problems, learning about control structures teaches the ideas of Boolean Logic, writing formulae increases and reinforces the understanding of mathematics. Programming is also empowering, being able to sit down at a keyboard with nothing more than your wits and a good idea and turn it into something real is an amazing feeling for a child. Programs let children learn and explore, make mistakes and figure out how to solve them, with gentle encouragement and careful guidance a child can turn their ideas into reality, and that’s a powerful lesson.

Where to go from here? I’m not exactly sure, the logistics of setting something like this up are a little out of my league. For right now this is just a good idea, I’m at step 3 of the idea ladder. Leave a comment, let me know what you think, if you are a parent, would this kind of program interest you? If you are an IT professional, would you volunteer at such an organization? If you are a business owner, would you support such an organization? If you are a child, would you like to learn to program?

I’m not sure where this idea will go from here, but I’m excited to find out.

In the future, we will rule this world!

Ideas are interesting things, we have them all the time, we dismiss them frequently, and we value them heartily. Some people don’t like to talk about their ideas, don’t want people to steal their million dollar brain baby, and I can respect that, but a million dollar idea with zero execution is worth nothing.

Ideas, like misery, love company, if I tell you an idea your brain will immediately start thinking about it, having its own ideas and interpretations. Then you tell me your ideas that my ideas caused and I get more ideas and so on and so forth, this is the basis of a conversation. That our ideas can grow and change organically, that we can piggy back off of each other, this is the basis of our society. But let’s get out of the woods of the abstract and into the city of concrete.

What I want to talk about today are those entrepreneurial ideas that we all have from time to time. Those things that you are certain will make you rich and famous, or the ideas that leap back into our minds when we see some new thing, a worldwide pornography distribution network, Tim Berners-Lee stole my idea! What should you do with these ideas, how should you handle them, and why and what and huh.

Every person will have their own way of handling the little lightning bolts that leap into their head but I want to take you through the path that I’ve found helpful for me.

1. Write it down – I write down almost every business thought I have, no matter how far fetched, and no matter how overloaded with tasks I am. This seems a little silly, if you are actively working at one thing it can even feel disloyal to start thinking about something else, what am I a squirrel easily distracted by a shiny piece of tinfoil? No, in my opinion you can never have enough ideas in reserve. It doesn’t take too much time to jot down enough information to be able to recall it later, and it doesn’t mean you aren’t serious about your current set of priorities. We would all like to think that everything we are working on will always work out, but you will never be sad that you have more ideas to fall back on.
2. Percolate – Go do something else, even if you aren’t actively thinking about something, after writing it down it will be floating around in your brain someplace. Great ideas refuse to fall to the wayside, if you find yourself coming back to something in your head more than a few times, move onto step 3.
3. Talk it out – Share your idea with other people, sanity check it, see if they laugh at you. Don’t get discouraged too easily though, great ideas can sound crazy and still be great ideas. After discussing it with a few people you can get a handle on how realistic it is and how excited you should be about your new idea.
4. Prototype or Shelf – If you’ve made it to step 4 you have to look around and prioritize, it’s easy to be swept up in the novelty of a new idea, but strive to objectively adjudicate whether or not you have the free time to move forward. If you do, grab some technology you are comfortable with and make a prototype, don’t invest too much time or money. If not shelf the idea, keep a short list of things ready made to work on and add this idea to it.
5. Focus Group Lite – If you made a prototype put it in front of some people, or float a pilot program. See how people react, sometimes an idea can sound great until you see it, then you realize some fundamental flaw. If this stage is good then move onto step 6.
6. Jump in with both feet – Get cracking. If you have the time, passion, and indication that people could use your idea, go for it. It will be difficult and you will probably fail, but you will be better for it.

Ideas are nothing without execution, but they are still valuable. Make sure you save your ideas, bounce them off of other people, and if your gut and other people tell you to go for it, take the chance. You may not always succeed, but you will rarely be disappointed that you tried.

Oh shit they've miniaturized HAL

The other day I wrote about the concept of the blackbox. I focused specifically on the idea of a blackbox as us programmers think about it. I’ve been thinking about it more and more though and realized that there are blackboxes all around us. There are processes that our often complicated, confusing, manual messes that our non-programming friends and family have to suffer through. If they knew a little bit of ruby or maybe some batch programming they would be able to save mountains of time and effort, but they don’t, so that’s where programmers can shine. The problem is that to help our friends and family we have to shine some light into their blackbox tasks and figure out what they do, that’s not the easiest task for a programmer to take on.

Recently at work they announced a change to the timecard system that we use, all timecards MUST be submitted by 10:00am Monday morning. The old system was, they should be in sometime on Monday and if not then our very nice receptionist will send out a sternly worded email shaming you into submitting you timecard. Being curious (and being that the explanation was just a few more lines down in the email) I wondered what change had occurred to the system to require this 10:00am deadline. Ends up that our receptionist used to enter this data by hand from the system we enter it in into the accounting software. This was a tedious and error-prone task, once someone bothered to look at it they realized that with a little bit of code they could automate this all and get these programs chatting back and forth like old bridge partners. A couple hours of programmer effort later and now our receptionist is able to answer calls and do all the other receptionisty things that she is great at instead of spending time copying numbers from one program to another.

The blackbox, timecards turning into accounting information, was illuminated and the process was horrible, a little bit of code applied and BAM new productivity abounds. It gets me to wondering, how many other blackboxes are all around me, waiting for someone to shine some light in, see the inefficiencies, and offer up some soothing code. I’ve given myself a new little game to play when talking to my friends and loved ones, when they start complaining about something that they have to do in their day to day, instead of just offering a sympathetic, “Sucks to be you loser” I start digging deeper. “These reticulated splines are giving you a lot of trouble, how exactly do you make them?” Normally they will reply with a bit of hesitation, maybe even a polite, “Oh, its boring, you don’t need to know about that.” But if you keep on gently nudging, you can find out enough of the process to help.

It doesn’t always have to be by providing code, sometimes just the general nerdy computer knowledge that we have can be incredibly beneficial. It’s easy to forget that not everyone knows the little tricks to make the computer easier and more fun to use. I was able to save my mother hours a day by explaining to her that despite what her boss told her, she does not have to shut down Photoshop between opening every file. Until then she had been instructed and believed that she had to wait a good minute for Photoshop to boot up in between every file, opening hundreds of files a day, you do the math. By asking my girlfriend some questions about something she does at work I was able to throw together an Excel spreadsheet to save her a ton of time. The magic of VLOOKUP and some well placed formulas was all that was needed to take a boring repetitive task and make it much simpler and less error-prone.

For those in the computer-know it’s easy to look at the computer as a simple tool, something to be mastered and leveraged to make our lives easier. For many people though, computers are blackboxes, confusing little machines that spit out weird error messages and are constantly fighting them to get things done. And there is the other edge of this sword, by shining light into a process blackbox and making life easier you do the double duty of helping illuminate the blackbox for a computer novice. You help show by example that the computer is not mean or frustrating (well sometimes they are frustrating) but just a tool that with careful skill, some essential knowledge, and most importantly a lack of fear, you can make bend to your will.

Go find the blackboxes around you, help someone save 15-20 minutes a day, show someone that computers are not just useful in general but can be made personally useful. You will be a technology hero to them, you will find an interesting puzzle to play with for yourself, and at the end of the day everyone will be better off. Find the blackboxes and start pouring in light, you will be pleasantly surprised at what you find.

simplicity is sometimes surprisingly complex

I love abstractions, most people do, they allow us to take complex things and wrap them in simple things and everyone is happy. The thing to realize is that there are degrees of complexity and different goals of abstractions.

Programming is one of those things where more often than not our abstractions are really helpful. The problem becomes one of perceived complexity vs. actual complexity. A good example is network protocols.

Network protocols are these complex beasts that let us talk across networks with some degree of certainty. Its really quite the marvel of engineering prowess, man has taken the various blinkenlights and cables and a big ole’ pile of Cisco and now you can watch a video of a cat playing keyboard whenever you like. Network protocols were designed to simplify the process of two programs on physically distant machines sharing information.

When you first try to learn a complex abstraction it can seem daunting, UDP, TCP/IP, sockets and fifos and netcats oh my! Sometimes it can seem overwhelming, but take a step back and realize that no matter how complicated a piece of software is, its just moving around bytes.

Perl has a philosophy that at the end of the day, everything is strings. That’s why its the glue that holds together the interwebs, because it’s just a really good string manipulation language. At the end of the day that’s all the internet is, strings floating around, normally between angled brackets.

Like most of the things I write I’m almost certain I had a point… oh there it is. When I started writing prosper it seemed like an impossible mountain to climb. I wanted to write a library that would bridge the gaps between all supported database backends, to have it be a sort of universal data access object.

This was much easier to think about than the actual problem

I had a few false starts on my project until I took a step back, I simplified my problem domain, and created an architecture that worked. Instead of focusing on the end result of prosper I thought about it in a more abstract way, prosper was a mapper from function calls to string snippets. This isn’t actually what prosper does today, prosper is in fact much more complex now than I would have ever imagined when I first started out.

The obstacle that stood in my way the most when starting out on prosper was being overwhelmed and unsure. The problem domain I was trying to tackle was too big, even when I tried solving it i ended up painting myself into a corner by focusing too much on how one specific backend acted. I needed a simpler problem that was more easily solvable, but one that would in the end help me reach my actual goal.

As much as I wish I could take credit for this idea, it’s not mine, it’s something called Minimum Viable Product. I wanted something that at its core would produce cross-platform SQL, so the first iteration was to make something that did exactly that. If you go on GitHub and pull one of the earlier commits you will see that that’s exactly what I built. Over time I have added the ability to execute those strings, connection and transaction management, standardized results, prepared statement support, and much more.

I couldn’t have accomplished any of this though if I hadn’t taken a step back from the problem domain and looked at the simpler problem at the core of what I was trying to do. I stumbled in the beginning, I’ve refactored again and again, over the break my good friend Ian took a look at the library and found a whole slew of problems, and I thank him for it. Prosper isn’t perfect yet, but it is moving toward being something really worthwhile, and to begin moving it required that I have something, anything, to start with.

So here is my suggestion for you for the new year. If you have some project that you’ve wanted to do but couldn’t figure out how to start, step back from the problem domain and try to find the core of the problem and solve it with the simplest thing that could possibly work. Don’t worry about the first iteration, or the first 20 iterations, you have to just get started. Once it is started you can iterate and refactor and maybe throw everything away and start again. No matter what the outcome of the first iteration it will be worth it, the best case scenario is that you can use the first iteration as a core moving forward, the worst case is that you learn a bunch about the problem domain and have to try again.

It’s the start of a new year, resolve to start your dream project, because that’s the hardest part. Once you get rolling momentum has a fantastic way of carrying you through.

Just like this, only less beautiful women and more boring data

When solving a problem the most difficult part should almost never be the implementation. Implementing a solution should be fairly straightforward from the solution itself, if it is not, then your solution is incomplete. That doesn’t mean that you need to sit down with pen and paper and completely solve a problem before coding, this is an approach taken by some books attempting to teach software development. Some go as far to advocate for an even stricter approach, something along these lines.

1. Model the problem domain with UML or some other modeling technique
2. Translate your modeling into pseudo-code
3. Translate pseudo-code into actual code
4. Realize 2 month project took 2 years to complete
5. Go to step 1 (the problem has radically changed since you took so long)

Of course, I’m poking fun at the books that take such a structured route. Here is a news flash for everyone Programmers are lazy. Here is another news flash (and this might actually be news to some people) Being lazy is good. Not all laziness is good, if it causes you to cut corners and fail to deliver a high quality product, than you fail at life. If however your laziness drives you to find an easier way to do things then “Lazy FTW!”

I have the “joy” of programming Java in my 9 to 5, when you write Java for a living you get used to the absurd amount of verbosity in your code, you also have the joy of Eclipse (notice no quotes around joy) that will write most of your Java code for you. Then there are things like Project Lombok that strive to make Java easier and more fun to write. C# got the memo, and let their programmers be lazy, let’s take a look at attributes in a few languages

Here is some C# code to make a class called Foo with a string member called Bar that can be read and written

public class Foo {
  public string Bar { get; set; }
}

They realized people are lazy, let’s look at the same thing in ruby

class Foo
  attr_accessor :bar
end

Again, concise and simple, let’s look at some Java

public class Foo {
  private string bar;

  public string getBar() {
    return this.bar;
  }

  public void setBar(string bar) {
    this.bar = bar;
  }
}

Can you hear it? I can, it’s the language architect saying “Just don’t be so lazy, write those simple functions, it isn’t hard.” The truth of the matter is that it isn’t hard, in fact Eclipse will happily write these functions for you, just hit CTRL-SHIFT-G. I’m sure there is a point here that I’m getting to, and here it is. I don’t want to disparage Java or start a language war, what I want to point out is that Java has a different conceptual model than C# or ruby. C# has the concept of properties and ruby has the concept of attributes, Java doesn’t have anything like this, classes have members and functions, nothing more.

The point is that the conceptual models your solution adopts will have huge ramifications on the implementation of the solution. There are many examples of unifying philosophies that make things simpler. Unix’s concept that everything is a file, C++ concept of streams, Erlang’s pervasive share-nothing message passing, ruby’s duck typing. These are core concepts that have profound and far reaching consequences.

Working on a new side project I recently was struck by a way to simplify a complex data structure by adopting a new conceptual model. Creating an internally consistent, elegant conceptual model is the most important thing you can do for a project’s success.

Conceptual modeling is a hard thing to get right, go into too much detail and your model becomes rigid and brittle, go into too little and the model can be impossible to implement correctly. Making a good conceptual model is like making a good analogy, there are a few hallmarks to a good conceptual model.

• The conceptual model should simplify the problem domain. Files and folders greatly simplifies the concept of a hierarchical file system by relating it to something commonplace.
• The conceptual model should not be overly complex to translate into an implementation
• The conceptual model should be uniform and consistent, if you find parts of the problem domain falling outside the conceptual model or feeling “tacked on” you should rework the model

The next time a project seems stuck or overly complex, instead of refactoring code or attempting to throw another library at it, take a step back, look at the big picture and refactor your conceptual mode.

Get ready for the feats of strength

The holidays are upon us and no matter what holiday your particular sky god has you celebrate (Festivus for the Rest of Us!) there is one thread of humanity that binds us together at this time, days off from work. When you have some time off of work you can spend it doing any number of worthwhile things

• Drinking egg nog until you black out
• Eating your weight in sugar cookies
• Having that same argument with your family that you’ve been having for the last 10 years
• Watching 24 hours of A Christmas Story
• Spending quality time with friends and loved ones
• Living through the same day over and over and over, á la Groundhog’s Day (Best saved for the actual Groundhog’s Day)

If you are reading this blog there is a good chance that you are some sort of programming nerd, its ok, I don’t care what the New York Times says. As a proud nerd you have probably heard of some sort of technology that interests you, maybe clojure has piqued your curiosity, or you finally want to learn that “rails” thing all those young whippersnappers keep talking about. I would argue that this can be a great way to decompress, if you do it right.

First off, find something different than what you are used to, if your 9-5 is .Net don’t spend your precious free time learning more .Net, that’s stupid. Go find something radically different, maybe look at a functional programming language, go find that weird kid in the corner and talk to him, he probably has interesting stories about fire. This might seem like a waste of time at first, but it’s not. It’s all too easy to get locked into an ecosystem, doing the same thing day in and day out, to get comfortable there and to start thinking that your way is the only way or the best way. Reading about other technology outside of your realm might not have a direct benefit to your 9-5, but you may gain a perspective or understanding that would be incredibly difficult to get from your standard frame of mind.

Second off, this isn’t work, this is fun. You are allowed to make mistakes and change your mind. If you work through a tutorial or get done with the first chapter of something and find that you really don’t care, then go find something else, the software world is full of interesting things. The thing is, only stop if you grok the subject and dislike it, don’t necessarily stop just because you don’t get it at first.

What? Caroling? No fuck that, I got some erlanging to do!

Third off, this is just to whet your whistle. Don’t ignore your loved ones, squirreled away with your Beginner’s Guide to Erlang because you’ve fallen in love with the idea of massively parallel systems. Take this time to investigate several things, learning the basics and setting up your love affair for the next few months. Then make sure you tell the people you care about that you love them and eat too much food and do people things.

For me this break will be about Rails. I’ve followed rails for a while, I’ve always been impressed with it, and I’ve had a few false starts. I’ve gone through the Getting Started tutorial more than once. I’m a php guy at my core, but learning how other people do the web is worthwhile. I’ve started the adventure already and think that this time it might stick. I have a 2 hour car ride up to Cleveland and back that I plan to fill with listening to Rails podcasts.

That’s all for now, go relax and decompress, that’s what I plan on doing for the next 4 days. As a side note I will probably not update during the holiday break so if you obsessively check or your rss feed gets lonely don’t worry I will be back on the 28th.

cupcake dispensing button

I have been working on prosper for the last few months, I started thinking about it in early October and according to GitHub my first commit was October 22nd. This project has been great fun so far and I’m not even close to a 1.0 release yet (right now prosper is at 0.6 well on its way to 0.7). I have learned a ton on this project that I would have never guessed before I started.

• The joy of GitHub
• The terror of phpDoc
• The prodding of friends
• The camaraderie of other developers (Will Bond and Jeremiah Peschka)
• The vulnerability of releasing the project
• The drive to keep improving

I completely underestimated the amount of work prosper would be, and I don’t mean coding (although coding has eaten up a large chunk of the time I normally fill with playing Borderlands). I didn’t realize the amount of work it takes to manage even a small project like this. GitHub has been an amazing resource, but at the end of the day it is a tool, and you need to spend time learning how to use it and populating it with data. Writing up documentation, reading documentation, creating examples, running tests, working with collaborators, discussing technical problems, it has been a mountain of unexpected stuff. Now I’m not complaining, this was the challenge I wanted, I’m learning a ton of new stuff, making great new connections, and pushing myself in ways I never have before. One of the most important new hats I’m learning to wear is promoter

Let’s say you have a great idea (like a standardized php database abstraction layer), and you decide to invest your time and energy into it. Great, you start coding like a madman and you have something working, you are working out the kinks, enjoying it, really making something worthwhile. After a while you have this project to the point where you think others might be able to use it, what do you do?

1. It’s too much work to do anything, just let the bits sit on your harddrive
2. I need to share this with people, I’ll toss it on GitHub / BitBucket / SourceForge / etc
3. I want to promote it
4. I’m going to get others involved

Those are the steps that I went through, and I would imagine a lot of people do, really I’m at step 2.5-ish, I created some pages within WordPress for prosper, but I plan on spinning out a standalone website for prosper at some point. The list looks easy but the problem is that you have to push yourself, because each step is costly.

To go from step 1 to step 2 you need to push past that voice in your head telling you to apply more polish. You need to push past any indecision or fear of criticism and get your code out there. The next step is to promote the crap out of your project. This step is difficult because how do you even go about it. Here are some ideas.

• Create a sample application using your project
• Give your project a home and shamelessly link to it
• Promote on reddit, Hacker News, etc.
• Get friends more famous than you to push it, if you don’t have famous friends, start sending out emails, the people that I’ve talked to have been really great
• Submit your project for review in any pertinent technical website (like PHP5 Magazine, which may actually be defunct)

For step 3 you have to push others, push friends, and push yourself to get your project on people’s radar. Now for the next step, getting others involved. You should have created some connections and hopefully some users, enlist them to make your project the best it can be. User’s can submit bugs, feature requests, and patches. Other developers can polish up bits they are interested in, as my good friend Jeremiah did. Getting more eyes and ears and noses in your project let’s you refine and build, spreading complexity around.

The point of everything is that you have to push. Even great ideas, great code, great projects can fall to the wayside if no one pushes. Promoting the work you do is nearly as important as the work itself, if no one ever uses your code, no one will care about the months of effort you put into making it beautiful. Get out there and be passionate, genuine, and don’t stop pushing.

Tomorrow I will be picking up the gauntlet that Jeremiah Peschka threw down today in What is Your Biggest Weakness? Tune in tomorrow to see what my biggest weakness is, and see who I challenge next.

don't worry, no babies were harmed

Yesterday my friend Ian sent me a tweet about prosper

@ihumanable I’d be more interested in using Prosper if it provided support for true prepared statements instead of concatenating strings.
6:29 AM Dec 7th – pian0

With that my baby was born, the baby was a version of prosper that utilized prepared statements where appropriate. Prosper’s main functionality has been coded for a while and the bulk of the work I’ve been doing as of late has been testing, improving backend support, and adding new functionality. The nice thing about this kind of work is that you don’t have to go mucking around in working code, you are just fixing broken stuff and adding new functionality. The idea of adding prepared statements made me a little queasy, I had briefly looked at it when I was starting prosper but decided that they were so varied that for the first attempt I would just avoid the headache. What’s the problem you ask, let’s take a look at this feature table real quick.

As you can see the support for prepared statements varies in the Vendor Specific Database Extensions of php. There is also the fact that prepared statement support is poorly implemented in several extensions, they can be coded around but it adds a good deal of complexity. Despite all the reasons not to implement prepared statements, safety, speed, and correctness dictate that I should at least give it a go.

Yesterday and today were my go, and I met with some success. Prepared statements are not all that difficult to implement for a given backend, throw in some question marks, call the correct bind function, and you’re off and running. The real difficulty is the cross-platform nature of prosper. I wanted prepared statements to be a first class citizen, I didn’t want to decrease any existing functionality, I wanted to not overly complicate the way prosper works, and because there are 11 adapters that need to be upgraded, I wanted it to be simple to add this functionality to a given adapter.

I worked and toiled and toiled and worked, I tried hacking something up to make the MySQL adapter work, ran into the bind_results function and screamed at it for a while. Then I got out some paper and drew out some diagrams, thought about sample code. Then I went to sleep. Then I woke up and in the shower pondered the proper syntax for passing around typing information and the division of labor for transformation. Then I hacked on it some more and wrote a quick test. Then and this is the most important part I realized I had done it absolutely backwards.

I had some clues that stuff wasn’t working out right, I hit a point where I would either need to embed an if statement in every function of an adapter or have a duplicate function. I thought that with some clever coding I could shove this down into the base class, it wasn’t great but it was working. Then I saw another red flag when I realized that the processing in the where clause was identical to the processing in the values clause, and I applied some refactoring. This is when I realized that there was a single function that I could have modified and had the whole thing work much more elegantly.

That is when I had to come to the decision to murder my baby. I had painstakingly worked out the kinks for two days, traveling far down this road, touching a bunch of code, and now I realize the best way forward is back. The best thing I can do right now is to revert my changes to Monday morning and lose 2 days of work, and that is great!

It’s not the best outcome, in an ideal world I would have seen this solution before and applied it and not wasted 2 days. The thing is that I’ve learned a great deal, I’ve come up with a much better implementation, and I’ve been reminded of an important lesson, never be afraid to throw away code. The code I wrote is adequate, it works well enough, but it is far from optimal. I could keep going, head down, plowing away making as many problems as I solve trying to build a house on an unsound foundation. The point here is to pay attention to those red flags.

The other important point is that sometimes you have to actually try something to find the thing that will work. You may lose some time, but even after sitting down with pencil and paper, thinking long and hard, the optimal path didn’t come to me until I walked down the wrong road. That’s just life sometimes as a software developer, you have to learn to live with it.

I will continue working on prepared statements for prosper, and I hope that by 0.7 or 0.8 they will be implemented and in there. I still question the syntax and think that I can clean it up, right now the plan is for prosper to support unnamed parameters (?), named parameters (:name), unnamed typed parameters (%i), and named typed parameters (:name%s), but all this seems like a little much. Good thing prosper hasn’t had a 1.0 release yet

keep pushing that boulder

Back from Thanksgiving, nice break, hope everyone had a good holiday. With the long weekend came some time to eat turkey, spend time with my family, and reflect on life. I’ve been thinking about what I want to ultimately accomplish in life and how to get there. The end goal is to work on complex technical problems and produce something useful for humanity.

I spend a good amount of time on Hacker News which is a great place to find out about new technology. It’s a fantastic community where entrepreneurs and programming geeks get together and talk about technology and startups. It’s the kind of place that incubates ideas that become the next twitter or youtube. Spending time there has made me think that I can do more, do better, it was part of the drive to make prosper.

The problem is that life doesn’t happen in a bubble. You have to buy groceries, pay the rent, and keep the lights on. So I’ve found myself at an odd cross road, I’d rather not continue doing business programming, but I can’t stop. What is a person to do? How does one pursue their dreams while maintaining financial security, is it even possible?

For a long while I’ve believed that you can work a 9-5 to keep the lights on and then work on a side project in the evening. The problem that I’m now finding is that any project that you can hang your hat on and make a living with is going to require more work than what you can give it in the 4 or 5 hours after you get home from work and before you go to sleep to get up for work the next day. Once you throw in trying to have some semblance of a life, it becomes nearly impossible to give a side project enough love and attention to make it work.

I’ve still been working full bore on prosper and its sister project that has yet to be released. The problem that I face now is this ever creeping feeling that I am merely spinning my wheels, and the encroaching danger of professional burnout. Prosper has yet to see any real adoption, which is not surprising its not ready for anything concrete yet, it is unproven, and it is still in a huge state of flux. The 0.5 release and the current bleeding edge on GitHub are fairly different, with the bleeding edge being a fair bit better.

There is no use moping about all this, so I need a plan to move forward with. Can I quit my day job to focus on the side projects, no. Should I give up on my dreams, no. What is the way forward then? Normally I would double down, work harder and push through. The problem is that I think I slipped from the first stage of professional burnout (Physical, Mental and Emotional Exhaustion) to the second stage (Shame and Doubt), and pushing harder, doubling down, may only accelerate this process.

I still believe that I can change the face of PHP database access, that my library can provide a hugely needed service to hundreds or thousands of PHP developers. I still believe in my ability to create useful technologies and solve difficult problems. So I’m creating a list of things to accomplish in the hopes of defeating my professional burnout.

• Re-institute a workout and diet regimen – Long hours at work and on projects have caused me to spend too many hours sitting around and running to McDonald’s or Wendy’s for a quick bite to eat.
• Create concrete project goals for prosper – So far development on prosper has been haphazard, I’ll get some idea and then work implementing it. The problem being that this leads to an almost manic-depressive like development schedule. When there is a new feature to implement I could spend 6 hours working on it, then have days and days of nothing until a new idea springs up.
• Make time to relax – I find that I spend most of my off-time working on prosper or its sister project. The other “down-time” that I have is spent reading technical articles and ebooks about programming. This stems from my deep love of programming, I do enjoy reading about lisp for hours, but I need to rekindle some of my love for other subject matters, too much of anything is a bad thing.
• Reflect on the good – Too often I spend time thinking about the negative. There are many great things that I take for granted.

Like GI Joe said, knowing is half the battle. This post is more about coming to terms with the difficulty that I’m currently facing, but I hope that it can help others in a similar position. No one is going to hand you your dreams, you have to fight and scrape and kick and scream to make it. It is difficult grueling often thankless work. It’s not easy, but if you want more out of life than a paycheck and a cold grave you must fight for it. The struggle takes it toll on everyone, but by being cognizant of the dangers, and recognizing that you are not impervious to the grind, you can make it through, and hopefully make something unique and beautiful.

google thinks this means refactor

I’ve been working a lot on prosper lately (this means that if you want to play around with it, get the bleeding edge on GitHub). I recently added a lazy loading feature, mostly to facilitate unit testing, and pretty soon I will be adding some unit testing. I was able to take care of some things recently that have bugged me for a while, and its because of ruthless refactoring.

Refactoring is not black magic, it just means taking some code and reworking it, rename a function here, encapsulate some functionality there, done. The sticky part is that refactoring is a compounding problem. Things that should be refactored build up on each other, so if you put off refactoring for too long you will have a real mess on your hands. Refactoring can be painful but should never be put off, you see a function named poorly but know that it is used in 20 places, get it now, don’t put it off, because by the time you get around to renaming it, it will be in more places.

A good IDE will help you in your refactoring process, the one that I love is (surprise, surprise) Eclipse. Eclipse is brilliant at refactoring, probably because it keeps semantic knowledge with symbol names. Rename the function foo to bar and you don’t have to worry about Eclipse destorying all those variables named foo (ps. if you have variables named foo you have refactoring to do!). Eclipse (and other IDEs) are great at all kinds of refactoring, renaming, extracting and encapsulating, pull up, push down, etc. Get to know these tools, get comfortable with using them, and refactor without fear.

Wait, change big chunks of code without fear, how!? Well you should have tests, be they unit or functional. I’m introducing unit tests into prosper, but for the time being I have a local version of todo list case study. The todo list application is pretty good because it exercises all the important bits, if I change something and everything in there keeps working, I haven’t broken anything too badly.

The reason I want to introduce unit tests though is that I’ve introduced regressions even with the todo list humming along, some dark corner of prosper has started shooting out unicorns, but I haven’t noticed, until I see some bit of code that I know can’t be doing the right thing. Test coverage allows you to refactor without fear, and if you want to have a living project that people might someday use, you need to refactor without fear to keep things current.

That’s it for the technical part of this blog post, I would like to announce a few things though.

• The move to GitHub has been completed and I’m starting to get into the workflow of using it now.
• The new skunkworks project is nearing a beta release, so keep an eye out.
• Development on the new project has spurred improvements in prosper, there will be a point release (0.6) soon
• There probably won’t be a post tomorrow as I’m traveling with Heather, my beautiful girlfriend, up to see my family in Cleveland.

That’s all for now, I will have something up Black Friday more than likely, until then, Happy Turkey Day everyone, safe travels, see you after I put another couple of pounds on.