bjori doesn't blog

I don't like ORMs . I really don't. It's not just because all of the ORM frameworks I've seen make mockery out of performance needs, but they also tend to be extremely over-engineered, which makes me want to cry. I'd wager that most people using ORMs are actually solving the wrong problem with the wrong solution, simply because there wasn't a better alternative for their data-modeling needs and the benefits of adopting an ORM outweighed its inherent problems. It's like driving a gasoline-hungry car. You say that you care about its MPG rating, but you are still wasting a lot of gas without ever looking back. It is just a cost of living. Or insurance: You know you can save 15% or more... but you don't. You've accepted that bi-annual rip-off as cost of living. Just like using an ORM, you have accepted the pain as cost of living. Well, I don't :) ODS - Object<->Document Serializer The new MongoDB PHP driver includes an experimental O

For the past few months I've been working on a "next-gen" MongoDB driver for PHP -- codename " phongo ". The aim was to build a new PHP extension ontop of the mongoc and libbson libraries to reduce maintenance of the extension itself and focus more on providing the ecosystem with improved support and libraries. The new driver is available on PECL (called "mongodb", surprisingly enough) . It doesn't include any of the bells and whistles found in the previous "mongo" driver. It doesn't include any `group` or `count` command helpers, and you won't find any Collection or Database objects; however, it really doesn't need any of these things. All it has is simplicity. You can execute a command of your choosing. You can execute a query . You can execute a write . That's really it (as with everything, there are certain exceptions). Oh, it is also very, very fast. What's the Point? Most developers interact with datab

Tableless html was all the rage a decade ago -- for a good reason. One of the advantages was maintainability of the markup -- especially in a deeply nested table layout. It also turned out, the table layout didn't actually fit the way we wanted to present the data. The rigid structure it enforced wasn't what we were after - and it also limited the freedom designers had to push forward and create next generation website and application layouts. In the beginning though, it really was the only way to get stuff done -- and the best tool for the job. It was fun while it lasted -- but we are over it now. Today -- we are entering a similar situation -- in databases, of all places. Tableless databases are becoming all the rage today -- for a good reason. One of the advantages of going tableless db is maintainability of the data -- especially with deeply nested data. It turns out, the table schema doesn't fit the way we want to work with or present data. The rigid struc