usable in any place a human can be used

Showing posts with label php. Show all posts
Showing posts with label php. Show all posts

20101029

Auto-timestamps in Flourish

This will be a short post, I just wanted to share a protip for anyone using Flourish and in particular using the fActiveRecord ORM. fActiveRecord is pretty awesome, with it and fRecordSet I find myself very rarely having to drop down to raw SQL, although for some reports it can't be avoided and then fORMDatabase::retrieve()->query() is your friend. Anyways one of the really cool features about fActiveRecord is that it has a plug in module based off of hooks and I wanted to pass along something that I've started doing as a convention that's worked out really well for me.


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.


[php]
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');
}
}
[/php]

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.
[php]
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');
}
}
[/php]

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

20100831

2 months

[caption id="attachment_864" align="aligncenter" width="590" caption="that\'s a pretty sweet logo"]Faveroo Logo[/caption]

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.

20100805

Flourishing

[caption id="attachment_859" align="alignleft" width="204" caption="Flourish\'s sweet logo"]flourish logo[/caption]

Looks like my claim of writing fast and furious didn't come to pass, oh well. For the last few weeks I've been working on a hush hush project for work. It's not done yet but we are nearing the end of the road for the MVP to be released soon. I wanted to write a quick update to discuss what it's been like getting back on my developer feet after burning out.


First off I'm engaged in my work again. For months I had felt disconnected, on autopilot, just trying to get through the day and hit some milestones. Secondly, I enjoyed playing cowboy for a while but have cone to realize that not all the habits I picked up in Corporate America were bad. Thirdly, I'm back to getting serious amounts of work done and am solving interesting problems.


Enough touchy feely hippie bullshit, let's get down to some business. I've been building a largish scale php application for the last couple of weeks and I wanted to reflect on the process.


I started off looking at various php frameworks a few weeks before starting this new project. I had kept an ear to the ground in the php framework area since forever so I knew the big players. I had also dabbled in some ruby on rails so I knew the bliss of when a framework gets it right, and the frustration of running up against something you would have done differently.


I looked into several frameworks CakePHP, Symfony, Zend Framework, Fat Free PHP, Yii, Noloh, and Recess! to name a few. They were all quite interesting but they all felt oddly foreign. Imagine if ruby on rails came out and it was a port of .Net web forms for ruby, blech. All the frameworks I looked at felt like they were trying to pave over PHP and make it into ruby lite or .Net lite. Each one was well put together on the whole and with some effort I'm sure I could have become proficient in any of them. Then I remembered an old friend I had played with before, Will Bond's unframework Flourish.


If you haven't taken a look before I urge you to do so now. Flourish is exactly what PHP needs, a strong core of classes geared toward common web tasks, with an eye towards simplicity, security, and consistency. After having used Flourish for a few weeks I can do nothing but sing its praises. Let me say that working with the combination of Flourish + PHP is a completely different experience than just writing PHP. Flourish gives you a sane construct around which you can build high quality applications. Here's a list of things Flourish provides:



  • Cross Database support for DB2, MSSQL, MySQL, Oracle, PostgreSQL, and SQLite

  • An extremely good ActiveRecord implementation

  • Filesystem with psuedo-transactions

  • Safe consistent handling of Requests

  • Session handling with special resources for Authentication

  • Classes for creating HTML including a quality Templating mechanism

  • Great Utility classes (think ActiveRecord rails people)

  • Amazing Email support

  • Classes for handling Dates, Numbers, and Money

  • High quality Exceptions and Handling Facilities


The thing that you will notice with Flourish is that it's a library that's seen real world use. It provides a high quality core but understands that it shouldn't try to be everything to everyone. The components interoperate nicely but you also function in isolation quite capably. It truly hits all the high points you would want from a library, but there is even more.


DOCUMENTATION: The Flourish documentation is some of the best I've ever seen. There is full PHPDoc for every class, which is nice, but more importantly there is "Class Documentation" that explains how the class is intended to be used, with code examples to get you started. The documentation is written very well and is incredibly in-depth. You could sit down and read it like a book, it's that good.


COMMUNITY: The Flourish discussion boards are active and I have never seen a posting go unanswered. Will Bond himself usually answers within a few hours of your posting, I know he has more than once helped me fix some tricky bug or better explained how something worked to me. The ability to reach out and communicate with the author is amazing, it also makes you want to provide support for the project.


CONSISTENCY: The Flourish API is amazingly consistent. I keep finding myself saying, "That's how I would have written it" while using it. If you learn how fCookie works, you know how fSession works, and you even know how fRequest works. Flourish simplifies things to the point that it's worth it to go the extra mile to add a bit of security to your code, because it makes it dead simple. Then you look back and realize that it also has helped you write self-documenting code, and jesus, did it just fucking cut my lawn too, what the hell?


SECURITY: As I alluded to earlier, Flourish encourages writing secure code. Flourish takes security seriously enough to have an entire compendium on just that topic and how it relates to PHP. My code is definitely more secure now that I use Flourish, from better security in parsing Request variables, to easily preventing Cross Site Request Forgeries, Flourish has you covered.




Ok, so I didn't really expect this to turn into a huge love fest about how much I love Flourish but that's where we are at. I want to over the course of a few blog posts really explore Flourish. I haven't fully figured out what format these are going to take, but if you are a PHP developer who wants to take their code to the next level, stay tuned.

20100121

unlicense'd

[caption id="attachment_606" align="alignright" width="300" caption="Freedom has never kicked so much ass"]colbert portrait by lockwood[/caption]

I wrote yesterday about the importance of open source software. I got one comment saying that prosper would be awesome if it were in the public domain. Here is the comment from Arto Bendiken


Prosper looks *sweet*. It’d be awesome if Prosper indeed were in the public domain. I think such a move would make for a decisive selling point over the numerous competing PHP libraries, setting Prosper clearly apart from the herd and allowing it to be easily embedded into any new emerging PHP web frameworks.

It’s worth mentioning that a key reason that SQLite, which is in the public domain, has prospered (no pun intended) has been the fact that it can be so easily (both technically and legally speaking) embedded into any other software. The end results of technical excellence combined with singularly liberal licensing speak for themselves: http://www.sqlite.org/famous.html

I think a lot of these same benefits could come into play also in such a potentially key higher-level web app infrastructure piece as Prosper. It certainly seems that you have the technical side of things well in hand, already, so here’s hoping for a bright and prosperous future.

Well I completely agree with Arto and want to clear up any confusion about prosper and its license. Prosper was original hosted on Google Code, which requires you to choose a license, at the time I selected the MIT/X11 license based off of my belief that it was the most free. A little further down the road I saw the WTFPL - Do What The Fuck You Want To Public License and thought about switching to that. There is a bluntness to the ideal of that license that appealed to me.


The problem with the WTFPL is of course its name, I want prosper to power lots of things and that means taking into account a wider audience. While hackers and rock star programmers can easily adopt something with WTFPL, I didn't want to be responsible for some corporation turning their back on an otherwise useful library because they were squeamish about a word in the license.


[caption id="attachment_607" align="alignright" width="220" caption="I always thought people just hated the letter C... then I found out this means no copyright"]no copyright[/caption]

Then I found this post on Hacker News (ironically by the same Arto Bendiken) and it lead me to the Unlicense. The Unlicense is exactly what I was looking for and simple to adopt. If you go to the GitHub repo you will see that the project is now officially Unlicense'd. The 0.8 release will be the first official Unlicense'd release, and so will every release going forward. I believe in free and open source software and so I'm publicly declaring now that prosper will always be free, open source, and unencumbered. The mechanism that I will use to ensure this going forward will be Unlicense.


What's the big deal, plenty of things are open source, why is this any different? The difference is that I'm giving this away fully, without any restrictions. Want to build a cool new library that uses prosper as the low-level database abstraction layer, go for it. Want to build a proprietary ORM that utilizes prosper, go for it. Want to repackage prosper and try to sell it (as underhanded as that is), go for it. Want to smother prosper with jam and eat it, if you can find a way to, go for it. Want to.... enough already, you can do whatever you like.


It is easy to talk about things like freedom and support them in the abstract, it becomes more difficult when you have something concrete. People could very well take prosper and take it in directions I don't care to see it go, but that is life, that is creation, that is the essence of open source. It is my goal to see prosper provide a solid foundation for building new and better tools and frameworks in php. I want as many people as possible to use it, and so this was a logical choice.


The next time you have some useful chunk of code lying around and you want to give it to the public domain for the good of the public, think about using Unlicense. I can't say it any better than they can so I will just quote their section about why you should use Unlicense. "Because you have more important things to do than enriching lawyers or imposing petty restrictions on users of your code."

20100107

codemash

[caption id="attachment_553" align="alignright" width="300" caption="I want you to come to Matt\'s CodeMash Session"]winking puppy[/caption]

Disclaimer: This post is shameless, and I mean really, really shameless, self-promotion.


If you have ever been on this site before you may recognize the name prosper. Prosper is my attempt at creating something of value for the PHP community. For anyone is following along at GitHub, you may have noticed that there hasn't been much work done in the last few weeks, what's the deal?! Well, don't fret, prosper is still under active development but it has been frozen for a few reasons.



  1. It was the holidays, and I was doing this weird thing where you interact with humans

  2. I've been seeking, and receiving, feedback from some key users

  3. I will be giving a live demo of Prosper and have been working on that demo more than the library as of late


"A Live Demo?" you say bedeviled by the notion. Don't worry you don't all need to cram into my apartment to see some technological wizardry, all you need to do is head on over to CodeMash, then at 3:00 on Thursday head to room E. The awesome company that I work for, HMB is sponsoring CodeMash and have selected me to give a presentation on this crazy open source project they've heard I wrote.


I've been working on a very minimal PowerPoint, because I know people can read so there is no point in me reading to them. At the end of the presentation though will be a live demo building up a simple database backed PHP application for managing all the fond memories of CodeMash, a quote board. In case you are unaware, building an application in front of people is incredibly nerve-wracking, which is why for the next 5 days I will be building this application over and over while talking to absolutely no one, to the confusion of my poor neighbors.


Live demos have a fantastic way of just going all wrong, as Bill will demonstrate





I'm not trying to poke fun at Mr. Gates (for once), giving a presentation in front of people, with new software is never a fun experience, and bad things© do happen. I will be practicing and practicing and practicing, and after that I will probably be practicing, for this presentation to make it the best it can be.


In other prosper news, I have set up http://prosper-lib.com to be the new home of prosper (currently just a forward to here, although the update is still working its way through GoDaddy's intertubes so you may get a parking page for a while). I am working with my good friend Ashley Kruso to get a new logo for prosper. Once I have the new logo I will begin building a new web home for prosper that will be all kinds of pretty. This is all in the run-up to Prosper 1.0, which is a goal for this year, but I haven't quite nailed down when.


It's all steam ahead on Prosper, thanks to the contributions and support of many people. When I started this project a few months ago I would not have been able to guess what it would turn into, so thanks to everyone that has helped or is going to help. By month's end there should be a 0.8 release that will have all kinds of new fun stuff including deferred result sets and lots of bug fixes from my friend who was kind enough to evaluate Prosper, Ian.

20091222

early present

[caption id="attachment_468" align="alignright" width="300" caption="open source software, the gift for everyone!"]pink present[/caption]

There is an early Christmas present for anyone using prosper, a new release, Version 0.7! You can get it hot off the GitHub or download here.


Version 0.7 has a lot of exciting new features, the biggest 2 were spurred on by Ian Potter and Jeremiah Peschka. The phpDoc has been updated (if you are still using version 0.6 you can find the old documentation here). The big news is that prosper uses Prepared Statements by default now, gracefully and transparently falling back to string interpolation where Prepared Statements are not available. The second new feature is the introduction of Explicit Transaction Management.


[php]
try {
Prosper\Query::begin();

//Do a bunch of stuff

Prosper\Query::commit();
} catch (Exception $e) {
Prosper\Query::rollback();
}
[/php]

Only some of the adapters support this, the ones that do not simply ignore the call to begin(), commit(), and rollback(). You can use the has_transactions() functions to check if the current adapter supports transactions.

































































































































Database Supported by Prosper Prepared Statements Transaction Support
dBase YES NO NO
DB++ NO NO NO
FrontBase YES NO YES
filePro NO NO NO
Firebird / Interbase YES YES YES
Informix YES NO NO
IBM DB2 YES YES YES
Ingres YES YES YES
MaxDB YES YES YES
Mongo NO NO NO
mSQL YES NO NO
MS-SQL YES NO NO
MySQL YES YES YES
OCI8 (Oracle) YES YES YES
Ovrimos YES YES YES
Paradox YES NO NO
PostgreSQL YES YES NO
SQLite YES NO NO
Sybase YES NO NO
Tokyo Tyrant NO NO NO

Happy Holidays, and Happy Coding!

20091221

impedance

[caption id="attachment_456" align="alignleft" width="300" caption="you can find really cool images searching for impedance mismatch, this one has lazers (with a z)"]you can find really cool images searching for impedance mismatch, this one has lazers (with a z)[/caption]

There is a threat to good software, one that threatens the most promising of software projects. This threat is impedance mismatch. I use impedence mismatch in the sense that Object-relational impedance mismatch uses the term, but make no mistake, I'm not talking about the difficulties of writing an ORM. What I wish to discuss is far more insidious, it is death by a thousand paper cuts, it can spell ruin for any project. Impedance mismatch is born out of the confusing first steps of a project, it can also arise from multiple developers working over time on a large project or from internal disagreements over the optimal solution.


The major problem is that when we go about designing some new piece of software, some whiz-bang solution, we do not fully understand the problem domain. Any good development team will spend days filling up whiteboards with the solution that models the problem domain, but anyone with experience will tell you that once you get into the guts of a problem you realize that things need to be changed. This is fine, in fact this is a sign that you are solving the actual problem and not the ideal one you began with, don't worry about changing your solution to meet the realities of the domain. The problem though is making these changes first class citizens and not some weird third class monster thrown into the mix.


Have you ever been on a project and heard a conversation like this?



New Developer: What is X?
Grizzled Veteran: X is what we refer to internally as Y
New Developer: Why do we call it Y internally but X on the UI
Grizzled Veteran: Time constraints... budgets.... other misc. bullshit
New Developer: *mental note: X is called Y sometimes*

BAMMO! There's some nasty impedance mismatch there. The problem is not so much in what we display to the user, or what our object properties are called, or what the database columns are named, the issue is that we have made our mental model convoluted. At the heart of all these systems we build as software developers is some sort of mental model, at runtime this is expressed in system as an object graph, for persistence it is expressed as a collection of tables and relationships, but all of these things are just a representation of some mental model.


[caption id="attachment_455" align="alignright" width="300" caption="artist depiction: working with an elegant mental model"]artist depiction: working with an elegant mental model[/caption]

When our mental model is internally consistent and simple and elegant, it makes life easy and happy and unicorns shoot out of our monitors and everything is sunshine and puppies. When your mental model gets convoluted it can be an awful and bewildering experience. The problem comes from an increased overhead, instead of the mapping from one representation to the next being clear-cut, the developer has to carry around a hashmap in their skull mapping various representations of their mental model. The difficulty of carrying out even trivial tasks is increased as the mapping from X -> Y -> Z -> Q -> P takes place.


[caption id="attachment_459" align="alignleft" width="200" caption="impedance mismatch vs. coupling: battle to the death"]impedance mismatch vs. coupling: battle to the death[/caption]

So let's just name everything the same and go home, problem solved. Oh, if it could only be so easy, the problem is that on the other end from impedance mismatch is a devilish little troll named coupling. Coupling is the amount that two pieces of software are intertwined, they could be tightly-coupled wherein changing one requires changing the other, or they can be loosely-coupled all the way to the point of being considered decoupled or orthogonal. Orthogonal pieces are nice to work with because you can change one and know that you won't have side-effects on other pieces. Orthogonality goes by some other names: encapsulation, modularity, and decoupled, it is generally considered a Good Thing© and I make no argument against it.


We now have these two seemingly opposing forces, we want to decrease impedance mismatch without introducing coupling, what should we do? There are many ways to deal with this issue, let's look at a few.


Adapters are nice little pieces of code (also called wrappers), that allow two different things to look the same. Let's assume we want to write some code to manage users, users have a name, an address, and an age. The developer of the class decides that this object can be pretty simple.


[php]
class User {
public $name;
public $address;
public $age;
}
[/php]

The database developer decides that he loves structured data and that this should be broken out into all kinds of columns and tables.


[sql]
table user (
user_id int autoincrement primary key,
first_name varchar,
last_name varchar,
addr_street varchar,
addr_number int,
addr_city int foreign key,
addr_zipcode int,
age int
)

table city (
city_id int autoincrement primary key,
city_name varchar,
state_id int foreign key,
)

table state (
state_id int autoincrement primary key,
state_name varchar,
state_abbrev varchar
)
[/sql]

We could create an adapter class that bridges the difference, for brevity's sake I won't include the code for it, but it would basically translate strings into database fields, as the application developer I get to imagine the database as mirroring my object, even though it doesn't.


ORM - ORM's are like automatic adapters. They are not without their faults and some implementations are better than others, but they mask the complexity of marshaling data and reduce the impedance mismatch.


Convention over Configuration - This was made famous by Ruby on Rails. There is some strong convention that you follow that allows for a consistent mapping between domains, an example would be that tables are always named the pluralized version of the class name.


There is no silver bullet to solving the problem of impedance mismatch, but a combination of the above can help limit it. The best thing you can do is be aware of the problem, don't introduce impedance where it is unnecessary, and never be afraid to ruthlessly refactor out impedance mismatch when you find it. Keeping impedance mismatch low increases developer productivity, lowers the bar for bringing on new people, and makes unicorns leap out of your monitor farting rainbows.

20091208

murdering your baby


[caption id="attachment_356" align="alignnone" width="370" caption="don\'t worry, no babies were harmed"]don't worry, no babies were harmed[/caption]

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.












































































































Database Supported by Prosper Can Support Prepared Statements
dBase YES NO
DB++ NO NO
FrontBase YES NO
filePro NO NO
Firebird / Interbase YES YES
Informix YES YES
IBM DB2 YES YES
Ingres YES YES
MaxDB YES YES
Mongo NO NO
mSQL YES NO
MS-SQL YES YES
MySQL YES YES
OCI8 (Oracle) YES YES
Ovrimos YES YES
Paradox YES NO
PostgreSQL YES YES
SQLite YES NO
Sybase YES NO
Tokyo Tyrant NO NO

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 ;-)

20091207

php pain

[caption id="attachment_353" align="alignright" width="210" caption="he never forgets, even the stupid decisions"]he never forgets, even the stupid decisions[/caption]

I am a fan of php, ever since my first software development job where I was thrown in the deep end and had to sink or swim. I swam in the sea of php and actually think it is a very nice language (begin receiving hate mail.... now!). You see, I never knew the non-OOP php, I was brought into a well managed project with Classes and Interfaces, it was basically Java with dollar-sigils thrown in. I never suffered through the spaghetti nightmare that so much php is, so I'm admittedly wearing some rose-colored glasses.


There is one feature that I love about php, it is the height of elegance, the associative array. The associative array can do anything, need a stack just use array_push and array_pop, need to do some functional programming array_map, array_filter, and array_walk are your friends. The beauty of the associative array in php is that it is ubiquitous, its a hash map, array, stack, object, all rolled into one.


The problem with the associative array though is that its create syntax is ugly. Here is how you create an array in php


[php]
$example = array(1, 2, 3);
[/php]

That doesn't seem so bad, what am I complaining about, well the problem comes when you have nested arrays (which is somewhat common).


[php]
$configuration =
array(
'name' => 'My Configuration',
'server' => array (
'name' => 'localhost',
'port' => '8080',
'users' => array (
array (
'username' => 'example',
'password' => 'example'
),
array (
'username' => 'user01',
'password' => 'pass01'
)
),
'overrides' => array (
'https' => false )
)
);
[/php]

The biggest problem is not that I have to keep writing the word array its that arrays don't look like arrays. They look like function calls, with other nested function calls, of course the newlines and tabs help out, but they don't solve the problem. Let's look at how this would appear in JavaScript using super-awesome JSON.


[javascript]
var configuration = {
name: 'My Configuration',
server: {
name: 'localhost',
port: '8080',
users: [ {username: 'example', password: 'example'},
{username: 'user01', password: 'pass01'} ],
overrides: {https: false}
}
};
[/javascript]

That's much nicer and the more important part is that hashes look like hashes and arrays look like arrays. There was a proposed php syntax change that was discussed to death and an analysis here which would have made the following legal php


[php]
$configuration = [
'name' => 'My Configuration',
'server' => [
'name' => 'localhost',
'port' => '8080',
'users' => [ ['username' => 'example', 'password' => 'example'],
['username' => 'user01', 'password' => 'pass01'] ],
'overrides' => ['https' => false]
]
];
[/php]

But this is not the case, and more importantly, may never be the case. The issue has been brought up and rejected several times, with the following reasoning



I see no advantages here, only another way to do already possible thing and yet another way to confuse people.

- Anthony Dovgal


For the record: I'm -1. array() is enough. Ridiculous idea to begin with.

- Jani Taskinen


There is no reason to add another syntax for *exactly* the same thing, especially because it's ungoogable

- Derick Rethans

Then there is this



I'm ok with it as well. Like I said over a year ago (*), it is a syntax very familiar to web developers and it feels natural to most people.

(*) http://marc.info/?l=php-internals&m=117060700805108&w=2
- Rasmus Lerdorf (the guy who created PHP)

The problem I see here is that the vote finally breaks down to 1 / 3 contributors in favor and 17 / 20 users in favor, it was then rejected. There is no recourse and as long as the people maintaining php see this as a useless feature, as a "backward incompatible syntax that duplicates already existing one, but 5 characters shorter" change request, it will never move forward.


This is a shame and it is myopic and dishonest. To trivialize this change supported by the vast majority of the php users voting as some sort of luxury people want so that they can avoid typing 5 characters is intellectually dishonest. The major point is that square brackets mean arrays in php, unless you are creating one, then it looks like a function.


[php]
$array = array(0, 1, 2, 3, 4, 5, 6); //Create the array
$element = $array[5]; //Get the element at index 5
$array[3] = "hello"; //Set the element at index 3
$array[] = "example"; //Push an element onto the array
[/php]

The dishonest part about the argument against the change is that it would be some sort of crazy zany backwards incompatible change and we would never break backwards compatibility. First off, if you are going to classify any addition to the language as backwards incompatible, then stop having a core development team, you are done, close up shop you can't add anything to the language anymore. Secondly, php has a history of removing and adding things that break older code, anyone remember the first stab at classes, or ever written $stringvar{4} to access a character, that is going away and you should write $stringvar[4] from now on. It's deprecated as of php 5.3.0 and will most likely be removed as of php 6.


But we are left as a community without recourse, the array function to create an array exists and by that fact alone it will remain forever. The most disheartening thing about the whole misadventure is that because this has been brought up and rejected so many times any time it is brought up now it is automatically rejected as being rejected before. Discussion has attached to this idea a Scarlett Letter, most undeservedly.


At the end of the day I won't jump ship, but it's one of those things that makes you stop and scratch your head. Why be so against it? I don't buy the arguments against it, I don't understand the fervor that the devs fight against it with, and I don't see the harm.


As people push the boundaries of what the language can do and the concept of the DSL (pushed by those ruby people) becomes more and more prominent, language cruft will have to fall by the wayside. Not improving array literal syntax is not the end of the world, but the attitudes and egos on display fighting a harmless change that the user base wants could be.




Edit: My arrays were using non-literal keys, which is incorrect as pointed out by Mewp in the comments, they have been corrected. Sorry about that, thanks for the correction Mewp.

20091203

prosper 0.6

[caption id="attachment_248" align="alignright" width="128" caption="prosper"]prosper[/caption]

I plan to have another real post later today, just wanted to announce a point release for the prosper library. Prosper development has been moving along and I am happy to announce that I just slapped the finishing touches on version 0.6.


Here is the 10 cent tour of the new stuff



  • Changed the configuration system to take constants instead of string literals

  • Added support for the older mysql library in addition to the mysqli library

  • Refactored adapters internally for more concise and logical class layout

  • Moved project to GitHub

  • Adapters are lazy loading now, this allows the configuration to be done with minimal overhead. This functionality also allows for unit testing

  • Added phpDoc Documentation to the project

  • Added GitHub frontpage documentation and project roadmap


There is a new download available on GitHub that contains all the documentation and source code. Since prosper is still in the 0.* stage it may be best to just clone or fork the source, a look at the 0.7 roadmap shows that there is still a bunch of work to be done.


If you want to help there are several ways that you can provide support



  • Use prosper and submit issues

  • Join the project*

  • Give me some feedback*


If you want to join up or give me feedback just send an email to ihumanable@gmail.com with prosper in the subject line

20091124

discomfort

[caption id="attachment_284" align="alignright" width="300" caption="was the collander really that hard?"]was the colander really that hard?[/caption]

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.


[caption id="attachment_285" align="alignleft" width="300" caption="who could resist octocat?"]who could resist octocat?[/caption]

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.

20091117

dogfood, terror, and tweets

[caption id="attachment_251" align="alignright" width="300" caption="too literal"]too literal[/caption]

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

20091116

announcing prosper

[caption id="attachment_248" align="alignright" width="128" caption="prosper"]prosper[/caption]

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.

20091110

convention vs convenience

[caption id="attachment_84" align="alignright" width="300" caption="convenience, american style"]convenience, american style[/caption]

I'm a huge believer in Convention over Configuration because it makes life easier and makes me more productive. I use to program in Java, and unless there is some seismic shake-up, I will soon be going back to Java. I like Java well enough, it's no lisp or ruby, but it has its place in the business world. I have many gripes with Java, verbosity, complexity, etc, but when you are in the enterprise trying to work with a bunch of third party pieces cobbled together into a hulking software nightmare the worst, by far, is configuration.


It makes some business sense, if a customer won't use your product because they want to change the tooltip on the help page and they can't without hiring a Java programmer, or at all because you distribute closed source .jar files, the simplest solution is to toss a config file at them. Just change this or that setting in the config file and, look at that, the whole application is christmas colored and in sanskrit. There are a some huge problems with Java configuration though.



  1. The unfortunate pairing with XML - XML hit its high water mark around the same time as Java, maybe there was some reciprocal love there, and it can be maddening.
    [xml]
    <env-entry>
    <env-entry-name>maxExemptions</param-name>
    <env-entry-value>10</env-entry-value>
    <env-entry-type>java.lang.Integer</env-entry-type>
    </env-entry>
    [/xml]
    Oh fuck me, are you serious?! I took that from the official Tomcat Documentation. It just sets maxExemptions = 10, but it takes 5 lines, 2 layers of nesting, 4 open tags, 4 close tags, and as you can see, this is a straight copy and paste from the official documentation and it has a pretty clear error. Clear to me because my eyes have been trained to read xml like a champion, the env-entry-name tag is closed by a param-name tag, that isn't right.

  2. Undocumented DSL - Every configuration is basically an undocumented Domain Specific Language wrapped up in XML's ugly ass clothing. There is little transfer of knowledge between Java and a Java Configuration file, or even between XML and a Java Configuration file.

  3. Undiscoverable - Maybe it would be more accurate to put hard to discover. Where do you go to figure out what belongs in your config, or what nodes configure what, your best bet is to hope the developer wrote up (and subsequently kept up to date) some documentation. Little to no help from your favorite IDE's code completion and the constrained nature of the problem domain makes web searches less likely to yield helpful information.

  4. Twiddling - Like in field of dreams, if you make a configuration, they will come. Sure there is no good reason for X to be configurable, but I don't like having hardcoded values in my code, so every hardcoded value is now configurable, and I'm on the slippery slope of softcoding now. This allows the end user too much power to twiddle around and configure things that don't ever need to be played with, just because we can doesn't mean we should.


This isn't just Java's problem, they are just the easiest to pick on because it seems like its everywhere. Then Ruby on Rails came onto the scene and made popular this idea, convention over configuration. I want to put my models in the fliggity directory, that's too bad, they go in the model directory. I would like to name my table that stores user data 'tc_people_datastore', yea well I would like a billion dollars, you are going to call it users. This means that if tomorrow I'm told to go work on a RoR project, having never seen it, I would have a good idea how the project is laid out, where the data lives, and how everything is hooked together. This convention eases the mental load I have to carry around, replacing it with simple, sane rules.


Convention over configuration, especially the rails way, has been called opinionated software. The software, in this case rails, has an opinion about how things should be laid out, what your tables should be called, etc. I'm in the midst of writing my own software and API and I've decided that my software should have an opinion about stuff, but more importantly that things should follow certain conventions.


[caption id="attachment_86" align="alignleft" width="205" caption="conventional breakfast"]conventional breakfast[/caption]

As a corollary to the conventions is a strive for consistency. Maybe a better title for this post would have been consistency vs convenience, but I'm already 700 words in, no going back now. I'd like a consistent API for a few reasons. Consistency makes it easy to remember, does this function go ($needle, $haystack) or ($haystack, $needle)? They all go ($needle, $haystack) calm down. Consistency makes wrong code look wrong, after seeing the same type of thing over and over again, the pattern gets burned in your brain, any deviation is obvious. I'm a little OCD, and making things consistent feels better.


The problem is that convention taken too far leads to an ugly little town called boilerplate, and no one wants to live there. This is where convenience comes in, it allows you to more-or-less follow convention but allow yourself an out to skip over the obvious parts. The problem is trying to strike an appropriate balance. I have a story of failure and redemption that I will quickly share with you.


My new side project is written in phpand makes use of the ubiquitous associative array when it makes sense to. I love me some php, but I hate the associative array literal syntax, and it's not going to change anytime soon For those of you unfamiliar here is how you would make the same associative arrays, in json and php.


[javascript]
var example = {'a': '1', 'b': '2', 'c': '3'};
[/javascript]
[php]
$example = array('a' => 1, 'b' => 2, 'c' => 3);
[/php]

Doesn't look too bad or different, but if you have to have nested arrays or use an array in a function signature (my case) it gets a ugly pretty quickly. I have also been reading up on lisp a lot recently and they have an idea that successive arguments can act as a pair. I thought this was a pretty nifty idea, so I set about creating an alternative calling convention.


[php]
$foo->bar(array('name' => 'Matt', 'age' => 23));
[/php]

Would be identical to


[php]
$foo->bar('name', 'Matt', 'age', 23);
[/php]

I thought that this looked much nicer, and it is fairly trivial to implement


[php]
class Foo {
function bar($values) {
if(func_num_args() > 1) {
$values = self::associate(func_get_args());
}
...
}

static function associate($args) {
$count = count($args);
if($count % 2 == 1) {
$args[] = null;
++$count;
}
for($i = 0; $i < $count; %i += 2) {
$result[$args[$i]] = $args[$i + 1];
}
return $result;
}
}
[/php]

I had done it, bam, lisp style associative arguments in php. The problem though is that, well, wtf? That is going to be the reaction to any php programmer unfamiliar with the lisp convention. I failed to follow the conventions of the language, so this morning I tore this code out. It added a secondary way to call a function, and it also introduces several edge cases, the benefit is also dubious. I was scratching my language implementer itch, but not in an appropriate fashion. This time convenience had to be sacrificed for convention's sake.

20091029

orm and sql

I've been working on a side project in earnest lately. It's all kinds of PHP fun and I'm enjoying learning the ins and outs of PHP 5.3 as well as relearning some of the stuff I already knew about from my PHP glory days. I've been looking at various different ORM solutions to use with my project and I'd like to take some time to review them, explain why I chose none of them, and what I'm doing instead. For the non-technical in the audience, ORM stands for Object-Relational Mapper, its a piece of software that allows you to save parts of your program to and load them back from a database, supposedly quickly and easily.

  • Doctrine
    Doctrine is the 800-pound gorilla of PHP ORM solutions, it has it all, and then some. It is an ORM sitting on top of a DBAL (Database Abstraction Layer) which leverages its own query language DQL (Doctrine Query Language). It can be configured in any number of ways, supports all kinds of backends, is mature, stable, and feature rich. That's all the good of Doctrine, the bad is the learning curve. The manual for Doctrine is 30 sections long, each section is quite a bit to take in. This is great if you are doing an enterprise level program, but for my project Doctrine was overkill.
  • Flourish Lib
    This is not an ORM solution, although it does contain one. Flourish is an unframework, and a really, really good one at that. If you want to shut someone up who says you can't write good code in PHP, send them to Flourish, the creator Will Bond did a tremendous job with this unframework, and I still plan on using large parts of it. The ORM layer is actually really nice, there is a bit of a learning curve, and at the end of the day I decided that it did too much and polluted my models too much. Flourish though is definitely worth learning, the website also has great best practices to follow if you are building a PHP Web Application.
  • php.activerecord
    Based off of the widely successful Ruby on Rails ActiveRecord class, this project aims to bring the ease of Rails database interactions to PHP. It does not attempt to be a PHP on Rails framework, there are plenty of those, its just a great implementation of the ActiveRecord pattern. The documentation is also fantastic, covering the essentials and letting you jump right in, it feels like there is no learning curve at all.
  • RedBean
    This is a complete departure from normal ORM solutions. In a normal solution you are cognizant of both the object model and the relational model, the ORM acts as a pleasant interface for interactions. In RedBean you are freed from having to know about the relational model, in fact you are allowed to let the relational model change on the fly. Need a new attribute for that object, don't worry about migrating schemas, just slap it in there and let RedBean figure out the rest. It is definitely an interesting idea, and it is maturing quickly, but I was wary of using it because of the overly fluid nature and the business constraints of my project

Those are the most interesting ones I investigated, I investigated quite a few other ones, but these were definitely the cream of the crop. None of them fit my project, but my project is a little bit weird (if you keep reading this blog you will no doubt see it one day, unless something shiny grabs my attention and I wonder off). If you are looking for a really powerful ORM with all the bells and whistles, check out Doctrine. If you are familiar with ActiveRecord, php.activerecord is a fantastic implementation. If you are programming PHP at all, take the time to read through Will Bond's amazing Flourish Lib. If you need some lightweight persistence or want to dabble in some object-oriented databases, give RedBean a try. Really on that last one, if you are even at all interested by technology, check out RedBean, it is a little young but shows amazing potential and is a great example of thinking outside the box.

So what did I decide, well I decided I don't want to use an ORM layer. ORM didn't fit my use case, I was only experiencing developer pain trying to shoehorn it in there. I decided that what I needed was something a little different, and I'm currently developing exactly that. So what is this mystery project that I'm working on, its a couple different parts that work together, but I decided that all I really wanted was the following list of things.

  • Cross platform SQL
  • Automatic CRUD
  • Lightweight library

So I'm writing them, and I will be releasing at least part of it soon, once I get it to a point where it does something, then expect a blog post with trumpets and whatnot. I conceived the project structure last night and began coding, I was able to put in 3 hours of work and got a very nice proof of concept running, but it is still all sharp edges and scuffed surfaces.

Stay tuned though, I hope to have something people can put their fingers on soon. I think there is a need for the lightweight components that I'm building, as a platform for future innovation and because after 3 months of looking around I couldn't find anything out there that did what I needed.