November, 2009


30
Nov 09

spinning wheels

keep pushing that boulder

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.


25
Nov 09

refactor

google thinks this means refactor

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.


24
Nov 09

discomfort

was the colander really that hard?

was the collander really that hard?

I am an American, which means that my life is constant bombardment of people offering to make it simpler, faster, easier, and more comfortable. Watch an hour of tv and count the number of times people are trying to make your life easier and more comfortable, its quite a few. The problems they solve aren’t even real problems, they are imagined problems that we’ve been convinced are real. I used to think these problems were real too, I didn’t have enough time, I didn’t have enough skill, I needed the pre-packaged solution that was quick and ready in 5 minutes.

Then I woke up one day and realized that I had been swindled by a bunch of bullshit.

Who has 15 minutes to make pasta for dinner?! [Show woman dumping pot of scolding hot water and noodles all over herself]
There’s just not enough hours in the day!! Buy our microwave-licious pasta bowls!!!

You know who has 15 minutes to make pasta, everybody does. Want to write a comment saying there is no way you could free up such time, well fuck you Mr. I-have-time-to-read-a-blog-and-post-a-snarky-comment-but-somehow-can’t-find-15-minutes-with-both-hands-and-a-flashlight. At this point though, we are all thinking, am I trying to make some sort of point about pasta or is this going to get around to programming at some point?

Well thanks for going on that side-rant with me, let’s look at what in the world I’m trying to get to. Being a programmer I like to be comfortable, I like to work with the languages I like, and the tools I know, and the frameworks I understand. It makes sense, people are more productive when they are working with the tools we know, that’s why we have holy wars about what language is better and which framework to use, we invest some time getting our nice comfy language set-up just the way we like it and we look at people sitting on uncomfortable languages and wonder what the hell is wrong with them.

The problem with being comfortable is that its hard to learn and grow when you are comfy. You know the language, you might learn some edge cases here or there or uncover a new feature or bug every once in a while (and this is important too, its important to be a master of something), but new learning is rarely done this way. Its very hard to learn new things by doing the thing you already know how to do day in and day out. Yesterday I decided to do something new, and it was uncomfortable, but I’ve started learning and hope to learn a bunch more.

What was this horrible discomfort that I suffered, moving my code for prosper from Google Code to GitHub. You see, I’ve been using Subversion since college, when one of the smartest software developers I know, Ian Potter, introduced me to it. I had heard some stuff about svn before and compared to the source control system we were using (a folder called test and a folder called production) had determined svn would be a step up. He set up svn and patiently answered my questions of which code was on my machine and which code was on the server over and over again until my brain finally wired it up.

Moving to svn was much more complicated than the tried and true 2 folder methods, but the safety, history, and concurrency that svn offered was more than worth the week or two of learning the new system. In my career so far I’ve gotten to use cvs, svn, and vss, they are all similar concepts, there is a central repo and you can commit, update, branch, merge, blame, etc. This is how source control works in my brain, and I am completely comfortable with how this all works.

Well svn is no longer the new hotness, git is in big time, and a good portion of its popularity can be attributed to GitHub. GitHub is the facebook of source hosting, its a really great site to host your project on, most interesting new projects are hosted there, and the social aspect allows people to easily interact with you and your project. I’ve had a GitHub account for a while, and I tried it out before, only to go back to the comfortable embrace of Google Code and svn.

who could resist octocat?

who could resist octocat?

So why move to git, just because its shiny? Well, GitHub is almost enough of a reason, but the distributed nature of git, the increased popularity of git, and the ability to quickly make new branches and merge them back into trunk, make it worth learning. If I want to continue being active in a community that more and more relies on git, its probably best to learn it.

I’ve taken the first step, I’ve moved my stuff over to GitHub and I’ve got git up and running on my laptop, I’ve been able to push some changes upstream and over the next few days I will be reading the excellent help that GitHub provides you. It will not be comfortable, I will probably be scratching my head for a while, wishing to go back to the centralized repo that I know and love. I will more than likely treat git like svn for a while until I “get it.” But I’ve decided to stick it out, to live with and own my discomfort and to learn this new thing.

Here is my challenge to you: maybe you’ve read a few things about a new technology and its interested you, maybe you’ve even taken a few trembling steps into the new technology, and you’ve walked away or put it aside. Go back to it, jump in head first, don’t look back and don’t give up. The great thing about technology is there is usually a manual to read, a community to turn to, and our old friend Google. Make yourself uncomfortable, you might just learn something.


23
Nov 09

division of labor

cartoon labor

cartoon labor

When building or analyzing any system of significant complexity the most important thing to determine is a proper division of labor. The entire idea of n-tier architecture is built on dividing labor up into the appropriate tiers and keeping them cleanly separated. For anyone that’s ever worked on a real world system half of the difficulty is caused by one layer leaking into another and the other half is getting around the separation caused by separation.

Despite my last sentence, division of labor is a necessary and good part of design. When done right it allows you to know where functions, variables, and constants should live, how things should interact, and who is the system of record. This is why it is imperative to decide beforehand or shortly into a project what the lines of demarcation are and who is responsible for what.

Prosper is one of a group of libraries, with well defined divisions of labor. This allows the libraries to be decoupled, and also has the added benefit of letting me know when I’m done. When I found myself adding functionality to Prosper the other day that I knew belongs in the next library, I realized that it was time to officially start the next library. So a new skunkworks project is moving ahead full steam, it contains 2 parts that work together, and so again requires a well defined division of labor.

Just because work has begun on a new library doesn’t mean that Prosper is left out in the cold, yesterday I added support for the deprecated mysql library, standardized construction, and added better support for native functionality. If you are checking out Prosper, you can follow the latest development by pulling from the svn repo.

Back on topic though, figuring out the division of labor is the most important part of any analysis or design work. We recently at work had a 2 hour long discussion about order numbers. It went something along the lines of this:

BA: This order number comes from the Mainframe
Expert: No the Application creates that number
Dev: So, what does the SOA layer need to do?
BA: Generate the number
Expert: No, do nothing, the Application will automatically do it
Dev: Wait so who is responsible for creating the order number, and if its not the Mainframe why is it making one?
Expert: The Mainframe always made that number and the Application has always ignored it.
BA: So we will make it in the SOA Layer?
Dev: Who is in charge of making the unique identifier order number?!
Expert: [shrug]?
BA: [shrug]?
Dev: Let’s decide that first

Explicit division of labor requires you to pull the unspoken assumptions everyone has about the system out of the silence of our own minds and puts it into the blinding daylight. Suddenly communication is smoother, arguments come to an end, because there is some record to consult to help guide decisions.

Draw out your explicit divisions of labor, don’t carve it in stone though, if your original design ends up being too inflexible, allow it to change, but again, bring all the unspoken assumptions back out into the open. This allows you to cleanly define what piece is in charge of what function, keep layers from leaking into each other, and make for smoother development and analysis.


20
Nov 09

solve it forever

having a bully day

having a bully day

This is a very simple rule that I have for solving problems at work, solve them forever. Its not always practical and sometimes you need to bend the rule, but its a great guideline. When I’m presented with a problem at work, I take it as a personal insult, someone could have solved this before and made my life easier but they chose not to and burdened me with it, and I refuse to do that to anyone else.

This has some downsides, you have to put in a lot of effort, and sometimes little things take a lot longer than the “man” thinks they should. There are some upsides though, you avoid technical debt. A lot of coverage has been given recently to the idea of technical debt, how you define it, how you avoid it, should you avoid it and so on. It is one of those nebulous concepts that everyone has a different definition for, we all know what it feels like to run up against some technical debt, its that situation where something that should be simple is needlessly difficult.

Technical debt is not complexity, sometimes doing seemingly simple things within a complex system can be cumbersome, but that’s the price you pay for some other benefit (dynamic forms, automatic mapping, etc.) You know that you’ve hit some technical debt when something is complicated and difficult, but there is no upside.

Boss: Change the text on that button
Dev: Ok, I’ll just update the html
…several hours later…
Boss: Why’d that take so long?
Dev: You see that text is pulled from an i18l file, which is populated dynamically by a database table, that table is autorouted by the orm layer, so I had to change a bunch of configuration entries, then I had to run an update across several tables, some tables were using the name as a foreign key relationship, even though they didn’t declare that formally to the rdbms, so I had to go track down what tables were doing that, and once all that was through I had accidently made a typo and had to go through the whole damn process again.

Debt like this is incurred when you solve a problem for now, not thinking about the future. Solving a problem forever means that as long as the problem domain remains the same that you don’t have to do anything. The issue is that many people misinterpret solving a problem forever as solving all problems forever, and that is not what I wish to promote.

There is an important difference, you should solve the problem domain thoroughly, but your solution should be specific to that domain, don’t try to do too much. There are innumerable problems that someone will take the time to solve for themselves, but give no thought to what happens to the next guy. Coming onto a new project I’ve come face to face with an age old developer problem, rolling on.

Rolling onto a new project is often an exercise in navigating technology to set up a development environment, navigating the corporation to integrate yourself into it, and navigating the team to find a place. All this navigation seems to be on the shoulders of the new person, there are people you need to talk to to get mainframe access. Which people? Where are they? When do I talk to them? How? There are often answers locked up inside someone’s brain, and if you ask the right people you can, like a detective slowly unraveling a mystery, find the answers and get your email and passwords and id badges.

This is a problem that should be solved forever, once the first guy joined the team he should have documented what he did, when, how, why, and that document should be part of team cannon, available as a helpful guide to the next new guy. This rarely happens though, it is a shame, but understandable, new people are struggling to get up to speed on a project they don’t have time for the meta-project of documenting their up-to-speed-getting project.

That is just an example, the next time you are guts deep in a problem that you’ve encountered before think about your fellow developer, and think about how you can solve it forever. The more problems you permanently put to bed, the smoother development can go and the faster you can get your project done.


19
Nov 09

clean slate

Today is my first day at my new assignment. My company gave me a new(er) corporate laptop with a plain vanilla install of Windows XP Pro to use at my client site. Last night I had the joy of looking upon that fresh computer and thinking of the wonders that could be. I got ready to install the base programs that take a windows machine from factory to awesome. Here is my essential install list.

Then I spent plenty of time monkeying with the filesystem, the wallpaper, things that don’t particularly matter, but make the laptop feel like home to me. I made my icons and text smaller, since I’m used to a giant monitor and the 1280×800 resolution felt a little cluttered to me. Now though I feel right at home with this machine, and feel like this is the best possible time of laptop ownership, right after you’ve got it set up just the way you like it, right before you add stupid things that pollute the registry and mess up your beautiful filesystem.

The other clean slate, the less fun one, is my brain. I have all kinds of knowledge in my brain about my last projects, but today I find myself swimming in a see of paths and acronyms and weird buildings, and a chair that isn’t quite high enough to be comfortable. I’m starting to wrap my mind around the acronyms and getting a grip on what exactly we are doing here, but I fear it will take more time to feel as comfortable with this new position as I do with my new laptop.

Suffice it to say it could be much worse, I can clearly still push to my blog, so that’s sweet. The people I am working with seem cool and fun, the project seems like a lot of work but nothing that we can’t handle. I will probably have a whole different viewpoint in a week when I truly realize the scope of the project and settle into a nice little routine.

So far, so good, I’m off to read another IBM pdf that is half marketing / half documentation. Wish me luck.


18
Nov 09

baggage

i know how you feel

i know how you feel

Finally! I am finally about to start working at my new project after all those squishy human beings got done drawing pretty charts and signing dead pieces of trees. I now can put myself into the beautiful cold clutches of the machine again and get back to what I do best, code stuff. I’ll be moving from .Net web development to Java middle ware development, and I’m excited to get back to programming.

That seemed like quite the dig at .Net, I don’t intend it to, it’s just been my personal experience. The problem with the .Net projects I’ve worked on is that they’ve been amalgams of third party libraries, and I’ve been in charge of gluing them together. This isn’t a weakness, some would say its a great strength, drop some cash and boom, big problem solved by a nice clean little dll (or 4). I will say that it greatly reduces time to market which is a Good Thing© and that it lets you get down to the customizations that clients spend the big bucks on.

The problem is that I’m a programmer, not a customizer. I like to write code, not tweak little settings here or there (although as a nerd I’m a fan of that as well). The .Net environment always seemed like a bunch of black boxes that I was just trying to lash together in a pretty enough package to call it done. Any actual code I wrote was always just taking business rules and turning them into something a computer can understand. That’s ok, in fact companies make a lot of money doing this type of work, I just don’t as a programmer feel fulfilled by it.

Now though I’m heading into a project where there is a problem without a solution, something that actually needs to be designed, implemented, tested, deployed, iterated, and other fun nerd words. I’m excited to be back to programming, but I’m worried about technological baggage. What is technological baggage you ask, let me find you an example (anonymized, of course).

function Recalculate(...)
{
  if (isNaN(CleanNumber(ctrl.value)) || 
      CleanNumber(ctrl.value) == "")
  {
    ctrl.value = "0";
  }

  var newValue = parseFloat(CleanNumber(ctrl.value));
  var oldValue = parseFloat(CleanNumber(prevCtrl.value));
  var diff = newValue - oldValue;
            
  ctrl.value = newValue;
  prevCtrl.value = parseFloat(CleanNumber(changedPrevControl.value)) 
                    + diff;
  
  //Snip some similar code          
  FormatMoneyWithCommas(ctrl, 0, 0, 0);
}

There is nothing wrong with the above javascript it works just fine. But look at it, that’s .Net wrapped in script tags if I’ve ever seen it. There are many non-javascript things going on in this code, anyone familiar with javascript will see them straight away. My intent is not to shame the author of the code or to call it out as bad javascript, it is merely to show that when steeped in a technology it can be very hard to pull yourself out. I picked on .Net but I’ve see plenty of javascript written like java, in fact I’ve gotten actual java code thrown between script tags back from offshore “resources” before.

There is a lot to keep jumbled up in our heads when we are programming, to lessen this burden we adopt naming conventions, and calling conventions, and all kinds of conventions and that is a good thing. The bad thing is carrying your languages conventions into other languages, its a kind of linguistic egocentricity that makes the natives upset.

Now I am trying to purge the .Net from my fingers and get them ready for Java again. I’m sure I won’t remember all the little gotchas, but the important part is to be aware. There are some basic strategies for carrying over as little baggage as possible.

  • Google – Go and google Language X for Language Y developers, Language X and Langauge Y can be almost any combination of languages and there is a good chance someone wrote an article, feature matrix, common pitfalls type document for it.
  • When in Rome – If you are going into an established project, adopt its idioms.
  • Tutorials – Even if you know the language you are heading into, go read a few tutorials, brush up on the basics

I remember the painful period between Java and .Net, being frustrated trying to figure out what the hell a HashMap was called (Dictionary) or wanting to declare what my functions throw. I’m sure I will have the reverse, but the one thing I’m looking forward to is getting back to Eclipse, I love Eclipse, and I will not miss Visual Studio at all.


17
Nov 09

dogfood, terror, and tweets

too literal

too literal

Yesterday I released my new library Prosper (in case you hadn’t noticed the new menu entry at the top of this blog). It was a ton of work, way more work than I ever expected, but it was worth it. Prosper is now out the door and ready for human consumption, I’ve been using it all day on a fun little project, mostly playing around with the twitter API (which I’ve done before but never from php).

I was talking the other day with the esteemed Rick Kierner about the upcoming CodeMash convention. Since I work for an amazing company that is sponsoring the event, I get to go for just about free. I plan on going to the precompiler sessions and that day comes out of my pocket, but its a small price to pay. Rick is taking care of the nitty gritty details but in the end I will have to give him some cash money to pay for the precompiler and the first night’s hotel room, he decided to use BillMonk to record the debt and keep everything straight.

After perusing BillMonk for a while I decided that I really liked the site, its a cool idea, and I thought to myself, “hey self, now that tipjoy is defunct could there be a space for me to make my mark.” (Side note, I often think hyperlinks at myself). Rick and I bounced some ideas off each other and at the end of the day decided that there really wasn’t a good business in what we wanted to do, so we abandoned the thought and moved on, c’est la vie.

Today though the idea kept bouncing around in my head, really its been bouncing since we first started talking. Today I finished my proof of concept for my new minimalist bill tracking system, currently dubbed cha-tweet (a portmanteau of cha-ching and tweet). I’ll outline quickly the concept behind it, a rough approximation of its implementation, its status, and what the title has to do with anything so far in the post.

The idea is basically this, you can tweet a specially formed tweet and cha-tweet will aggregate those into a nice little summary of who owes you cash and who you owe cash. The tweets look like this

The debt cha-tweet

@I_owe_this_guy_money > $5 lunch: delicious sandwich!

The give cha-tweet

@I_gave_this_guy_money < $5 lunch: mcdelicious

The basic idea is that money comes out of or goes into the username to or from you, respectively. It’s a simple syntax that lets you sort by debtor/debtee and by type of debt. Since it starts off with the @username syntax it only gets displayed (by default) to people that know both of you and would maybe care, and its easy to find by the service because it is treated by twitter as a reply. The system works fairly well, and I’m happy enough with the concept.

The problem was that to create an accurate summary it had to go get and process the entire tweet stream, which can take a long while, and assuming that most of the tweets in a users tweet stream will not be cha-tweets, there is no need to do all this processing everytime (and in steps sexy miss rdbms). So, throw a database at the problem, store the seen cha-tweets and operate on them, this has now been implemented, it took one hour, and I used prosper to do it.

So how was it? Really easy, I stole the configuration from the todo list project, switched around the credentials and the schema name, and was off and running. Everything was working well until I tried to update something and Prosper spit up a bunch of non-sense at me, and my heart sank. Did I just release some library full of horrible bugs and will be mocked endlessly, the cries of n00b and pwned reverberating so loudly as to drive me mad?! No, I just don’t know how to type so instead of writing this

Prosper\Query::update('user')
  -&gt;set(array('since' =&gt; $since))
  -&gt;where('id = :id', $_POST)
  -&gt;execute();

I wrote

Prosper\Query::update('user')
  -&gt;set(array('since' , $since))  //WHOA!
  -&gt;where('id = :id', $_POST)
  -&gt;execute();

Changing that double arrow to a comma makes a big difference, and causes prosper to correctly try to set `0` to 'since' and `1` to 'some_huge_twitter_id_number' which is what I told it to do.

Crisis averted, my library still functions properly, hip hooray!

  • Is it easy to use? Yes, I found that it cut down on my development time considerably.
  • Is that because I wrote it and have no learning curve? Quite possibly, I’m not going to rule that out.
  • Is the code easy to read? Yes, its fairly straightforward crud stuff, made much simpler by prosper.
  • Did I learn anything eating my own dogfood? The verbose function is awesome! I wrote the verbose function in the beginning as a simple debug / sanity check of sorts to make sure that things were being translated and serialized correctly (pro tip: the magic __toString function will print the sql statement that will be executed). During development though it was incredibly useful to be able to switch the call to execute for a call to verbose and immediately see at a fairly granular level what was going on. This got me to thinking how much prosper needs some official documentation, and that will be my project for the next week or two.

In the end I have a nifty little twitter gadget, I will probably be hosting it somewhere soon so keep an eye out for that, but more over I have some more experience as an end-user with prosper and a renewed energy to write the official documentation.


I’m also adding some stuff to the blog, there are now social media icons, the rss feed link got a new friend mr. twitter link, and there are some backend changes for speed and stability. This is another round of blog tweaks and that is the best time to have your opinion incorporated into the blog’s overall look and feel, so comment away!


16
Nov 09

announcing prosper

prosper

prosper

I’ve been talking and teasing and hinting about my side project. Well today is the day I can finally announce my project, prosper.

Prosper has been in the works for a few months in my spare time, it is a database abstraction layer written in php. For anyone who has ever written a web application in php you know that they are written for one database and one database only. It is a MySQL application or an Oracle application or an X application. If the application gets popular enough, the developer might get around to adding some support for other backends, and when they do it is always some homegrown solution. With prosper you can write your database code once and have it work across 18 different backend databases.

Prosper came about when I was looking for a quality ORM layer, the one thing that struck me as odd is that everyone was rolling their own database abstraction layer. Doctrine has DQL, Flourish has F-SQL, php.activerecord has an adapter architecture, and so each library has its own quirks and compatibility.

Following the Unix philosophy, prosper does one thing and tries to do it well. Here are some things that prosper is not. Prosper is not an ORM. Prosper is not an Active Record implementation. Prosper is not an MVC framework. Prosper will not pluralize names, will not handle sequences for Oracle, will not slice and dice your onions. Prosper is one thing and one thing only, a library that turns function calls into sql.

Official documentation is coming soon, but for now you can view the case study, learn why you should use proper, and get the code

I read the documentation, I wrote the code, now its your turn. Give it a try, submit issues to the Google Code Page, and let me know what a great / terrible job I did.

Note that prosper is not ready for primetime yet, this is version 0.5, lots of the backends should work but only the MySQL one has gotten any kind of real testing. The code is open source currently under an MIT License, although the license may change for the 1.0 release, it will always be free to use and open source though. Here is the list of things that still need to happen.

  • Thoroughly test the backends
  • Add any backends that I missed
  • Write up official documentation
  • Move code to github to facilitate collaboration
  • Forge partnerships with other open source projects
  • Shamelessly promote

Go get the code and let me know what else I need to get to work on.


13
Nov 09

leaps and bounds

I keep talking about (more like won’t stfu about), the sideproject I’ve been working on. Today I added several draft pages to this blog containing documentation and release information, I’m expecting to have the actual rollout sometime next week. I’ve made a flowchart to show you how my mental process worked so far on this project, and where I’m at now.

how my brain works

how my brain works

Most of the time I get stopped in the “will it ever be any good?” decision, it returns no, and I scrap my code, and wait to have a worthwhile idea. This time though, somehow, I’ve managed to move past that one, and for the last 2 weeks or so have been spinning around the “is it any good?” -> “no” -> “refactor” -> “is it any good?” -> … loop. I’ve been tweaking this or that and in my head there was still so much to do before releasing.

Today though I’ve found myself writing up release information and documentation, and I came to realize that the ever present list of things to add or get working or refactor had been brought down to nil. I’m out of code work to do for the time being on this project, the best thing I can do is release. There seems to be this huge leap though from hacking to releasing, for me at least. I can sit all day adding features and refining APIs, but I realize now how frightening it is to put your work into the wild and try to promote it.

I feel this anxiety doubly compounded because I didn’t write an application where the code, even if open sourced, is neatly tucked away behind the scenes. I wrote a library, with an interface and code that if it gets any kind of adoption, people will probably look at, curse at, laugh at. Really though, there is nothing to do but put it out there, track the bugs, iterate, and make it something I can be proud of.

Next week I will be officially releasing this side project, my hope is Monday morning. I want to write up some great documentation, explanation, set up bug and feature tracking, set up a forum, and move the project over to github, because github is the official hotness. So this is a head’s up, watch out next week because big things are coming.