I like all of my model classes to have a created_at and an updated_at timestamp that automatically do the correct thing to provide a very basic audit trail. This does not let you off the hook for doing actual auditing, but it is a nice way to do sanity checks and get some instant information about records. fActiveRecord makes this pretty easy to do, let’s dive into some code.

class someModel extends fActiveRecord {
  /**
   * The fActiveRecord class provides the configure function to let you set-up Active Record hooks.  Let's do that now
   */
  protected function configure() {
    fORMDate::configureDateCreatedColumn($this, 'created_at');
    fORMDate::configureDateUpdatedColumn($this, 'updated_at');
  }
}

Easy as that you now have your created_ats and updated_ats working great for the someModel class. Here’s the cool part though, because boilerplate code is stupid ugly code, if you want to use this across your project simply do the following.

class ActiveRecord extends fActiveRecord {
  /**
   * For this project every model should record created_at and updated_at
   */
  protected function configure() {
    fORMDate::configureDateCreatedColumn($this, 'created_at');
    fORMDate::configureDateUpdatedColumn($this, 'updated_at');
  }
}

Now when you need to create a new model simply extend ActiveRecord instead of fActiveRecord and auto timestamps are done.

that's a pretty sweet logo

On June 3rd I typed the following into my Terminal.

mkdir faveroo
cd faveroo
git init

On August 15th I typed the following into my Terminal.

cd ~/src/faveroo
php deploy.php production

Then I watched and held my breath as my carefully crafted deployment script worked its way through 2 months of code and pushed them across the line. Then I fired up my browser and went to http://faveroo.com and waited for the now familiar homepage to show up… I’m sure it took less than a second to load, but it seemed like an eternity, finally it was up. I worked for the next few hours exercising the application through all its various operations, squishing little bugs here and there that popped up from being in a different environment. Two months of development, and finally it was live, and it actually worked. A few hours later we started hooking up people with sweet deals and putting money in the bank, mission accomplished.

Faveroo.com is my first project at my new job at 614 Media Group. It was a skunkworks project up through the end of July, so I couldn’t come to this blog and talk about it. I did all of the coding for Faveroo and my colleague Jeff Guciardo did all the design work to make it look so pretty (it’s probably the prettiest thing I’ve ever had the opportunity to create). The basic premise of the website is that our team of dedicated sales people go and find great local deals, then we throw them up on Faveroo.com, and then we help people save some cash. When you buy a Faveroo you save some money, the business makes money, we make money, and 3% of the sale automatically goes to charity, it’s win-win-win-win. But I’m neither marketing nor sales, so I will stick with what I know and what I knows is tech, so let’s talk about that for a minute.

Faveroo is a PHP website that includes the public frontend, a private backend, and a series of maintenance scripts that make sure everything works like clockwork. When I was starting up the Faveroo project I was given carte blanche as to how to build it. All of our other web properties use the classic LAMP stack, so to keep operations fairly sane and because I deeply love PHP, I decided to build out Faveroo on a classic LAMP stack as well. The code is Object Oriented, nearly MVC, PHP 5.2 code. I looked around, had been for a long time, at various PHP Web Frameworks. I had just come off of working with rails on a side project and so I knew the joy and frustration of work with a framework.

As you may be aware, I’m crazy in love with Flourish and decided that I would use it as a major component. I have been a fan of Flourish for a while now, probably over a year, but this was the first big application I was going to use it on, and really the first large scale from scratch application I have ever written. Now don’t get me wrong, I’m no rookie to this slinging code stuff, I’ve maintained huge legacy applications, built middle-ware up from nothing, and even rewritten large applications to the point that almost all of the original code has been replaced. But this would be the first time that if I didn’t like something in my code, it was because I was the stupid jack-ass that made such a boneheaded decision. Well, not the first time, but the first time I couldn’t easily blame someone else

I want to say that the decision to go with Flourish is probably what made the rapid turn around time possible. It’s a wonderful library that helps you do things right but doesn’t force you to do anything you don’t need. The thing that amazed me as I used it is I started off only wanting to pull bits and pieces, maybe some fCryptography here and a little fMessaging there, but as I got familiar (and boy howdy did I get familiar) with the docs, I just found more and more amazing functionality and a beautifully coherent system. Flourish was clearly written to be used, and by the end of the project I found I was using almost every class. It’s clearly a tool written for real world use from real world experience.

Flourish and jQuery are really the 2 big external dependencies for Faveroo, the rest of the code was written by me. I found this minimal system worked very well for me. I wrote a router in about 100 lines of PHP code, it’s nothing earth shattering but I think it has a few novel ideas. I’ve since built a new version of this router that is shorter and has less complex code paths. At some point in the future I may try to make a more generic version of this router and release it open source. All of the model classes are fairly straightforward using the excellent fActiveRecord as a base.

I spent about a week spinning up my minimalist framework, but it paid off big. I knew how the system worked every step of the way, and more importantly, I could alter it in minor ways to achieve dramatic results. All of this is possible with established frameworks, but here I got away without having to climb up a learning curve. This gave me more time to understand the problem domain and to learn how to best use Flourish.

With this experience under my belt I’m looking forward to continuing to learn, and hopefully to contribute back to, Flourish and PHP development in general. This project has shown me that in 2 months I can go from nothing to cash hitting the bank account. I feel reinvigorated to make cool things that add value to people’s lives and reassured of my abilities as a programmer. After a long period feeling burned out and wasted, I remember why I love programming, and why I love creating, and why this is the only thing I can ever see myself doing.

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')
  ->set(array('since' => $since))
  ->where('id = :id', $_POST)
  ->execute();

I wrote

Prosper\Query::update('user')
  ->set(array('since' , $since))  //WHOA!
  ->where('id = :id', $_POST)
  ->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!

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.