Composer, the dependency manager for php is awesome. Incredibly awesome, and gaining more awesomeness by the day. There used to be many glitches, edge cases that made me grinch from time to time to time about it, but almost anything I’ve had to complain about is now working wonderful.

However not everything regarding dependency management is in control of composer, and much is left to the creators of those dependencies.

What causes me pain recently is versions. Library versions are completely in the hands of the library creators. And for this I found people have a variety of behavior regarding tagging versions that makes my use of composer quite inconsistent. Here’s the main 3 of them and why I think they are good / bad.

Update: Seems I’m not the only one thinking about this. Check @igorwesome’s opinion here: https://gist.github.com/4475804 too.

Dev-master is thy master

This maintainer has no tagged versions at all. Examples include (sadly all symfony bundles):

• https://github.com/KnpLabs/KnpTimeBundle
• https://github.com/liip/LiipImagineBundle
• https://github.com/FriendsOfSymfony/FOSFacebookBundle

This is a horrible idea. You should tag versions. Even if you feel like your library is still under heavy development, clearly not finished yet etc… As soon as some other people are using your code, they need to be able to afford a bit of stability.

Countless times I’ve had the issue that when running a composer update, half of my code got broken because one or two libraries made changes on their development branch and didn’t worry that it would break things down for people who were using it previously.

One more advantage of having tagged versions is that composer caches them locally when you install them. Now I know all of you have internet connections of 8TrilloBytes/PictoSecond, but there’s still some of us for whom it’s not the case.

Time / feature based versions

Versions are tagged when maintainer “feels like it”. Seems to be the most common case. The maintainer has a deadline in mind, or a certain set of features he’d like to put in before creating a new version. So sometimes, many weeks / months go by before a feature actually makes it to a tagged version. I don’t have a definitive opinion on this strategy, I think it fits some libraries, but not all of them. It fits a framework, or a library with a massive user base I think.

My rant against this strategy is that often, bug fixes are also only tagged in a new version “at a later time”.

An example of this I recently had is with DoctrineExtensions (this is just one example because it’s the most recent one in my case). After an update to the latest version, the Sluggable behavior wasn’t working for me anymore. I went on to fix what for me was a bug, wrote tests for it, submitted a pull request which got merged.

Awesome you would think. Well yes but … no. Not completely. Now that I’ve fixed my bug, how do I start using the version that has the fix?

I can start using dev-master instead of the 2.3.* or 2.* version tag I previously had. But then, I’m back on the dev-master trainwreck. It’s called “dev” for a good reason, and it means that things are gonna break. Possibly a lot.

Or I could … well I don’t know!

The version tag freak

That would be me! If you look at https://github.com/khepin/KhepinYamlFixturesBundle/tags, it has 12 tags for about 96 commits in the repository. That’s one tag every 8 commits on average.

Whenever I update the code, or receive a pull request on it, I ensure the minimum to be confident that the code still works the way it should. Ask people to add tests when they submit new code. Run the tests before each PR. Try it on a spare project, whatever is needed.

But then as soon as I am confident that code doesn’t break things, I tag a new version immediately. X.Y+1.0 if I added some new feature or X.Y.Z+1 if it’s more of a bug fix.

I don’t think it’s a good thing to do for libraries that don’t have good testing in place as this would be like being on dev-master but with more work to be done. But for the other ones, doing something different feels like a relic of the past to me. A relic of times when it did cost money to release a new version. You had to print CD-ROMs, send them to your customers, go through an expensive upgrade process. So it made sense to only release when there was a truckload of new features / improvements.

But nowadays, what’s preventing us from having 5 versions a day if we’re confident they’re not breaking anything for existing users?

So maybe we could…

If you’re not confident, then the alpha and beta channels are here for that. I think these names are “misleading”. People have in mind that you work 5 months, then have alpha versions for one month and then beta versions for 2 weeks, and then a final version.

I’d like to propose that alpha and beta are used in a different way. Much like the “channels” on firefox and chrome.

In alpha, you can tag things as they come. Tag often. Not all the time (that would be dev-master), but often. As soon as a small feature is developed and tested => tag.

In beta, you give yourself room for a bit more feedback time.

And real versions are for when you feel comfortable that you’ve reached a new point in your library’s development.

What do you think? How do you do it?

I’m gonna say it again but you should at the very least start tagging versions of your code. This makes life easier for all the users of your code. This gives you the ability to develop new features freely without breaking everybody’s stuff.

I gave some ideas on how we could all achieve this better. I’m open to different opinions. Let me know what you think.

We’re doing some pretty advanced stuff at my company using underscore.js and to simplify some of it I wanted to use partial templates in my templates.

For example, we have different kind of tooltips all over our application. The structure is similar but the text and a few classes might change.

Underscore allows you to add your own functions using _.mixin(). And within an underscore template, all the underscore functions are still available.

So here’s the simple code:

Now you can declare a partial like this:

You declare your partials once, with a unique name. They are then globally available from within any other template.

And use it from within a template as follows:

That’s it, very easy and can save you some time by avoiding re-creating the same templates everywhere. Especially when you will need to change them!

Now …. time for the weekend!

A while ago, I had cleaned up all the database of symfony related blog feeds from the old symfony website, as well as added a few of my own. The whole thing is published as a single RSS feed.

Now the same is available as a Twitter account to keep you informed of all goodness in the symfony world. Just follow @sf_bloggers on Twitter.

And just like before, if you want to add your own blog feed in the mix, send a PR on khepin/symfonybloggers adding your Atom or RSS feed to the feed_list.

In a lot of cases it can happen that you want to make your forms different based on the user currently browsing your app.

The cookbook currently shows how to change a form with event subscribers depending on the data in that form. Say creating a record rather than updating something could require a different form for example.

Here we’re gonna take a look at what happens when your form should be customized based on something that is not readily available in the form’s data. Such as the user data.

In many cases though I’d tell you it’s better to not have to do that. There’s a lot of UI ways to make things so you never need the form to hold user specific data. Like letting a user browse to the thing she’s trying to update rather than have a huge select box inside of the form. But if you need something like that, here’s a clean way to do it!

Continue reading →

In the app we’re developing, I want the registration process to be as painless as possible, so the registration form only asks you for a few very basic things:

• username
• email
• password

However we want to have a user’s full information before he can participate in more “advanced” parts of the app. For example if you were an online air ticketing company, before allowing to proceed with a ticket checkout, you need the user’s full name, passport number and other things.

Continue reading →

Very quick post today, but I’m recently migrating a MySQL database to a Postgres one because the guys using it want to now take advantage of the geographical possibilities of Postgres. Some tables were very easy to migrate with very basic scripts however for some of them with lots of relations to each other, I wanted to take advantage of using an ORM to make things more simple for myself.
Continue reading →

There’s a problem many people seem to encounter in Symfony2 and that appears when you start using the ACL component for security along with Doctrine. The ACL defines an object’s identity based on its class name and an id retrieved from a ‘getId’ method if one exists or from a getIdentifier method if the object implements the DomainObject interface. Continue reading →

I ran into a few issues running tests for a symfony2 project that seems to be common to many people once your test suite starts to be more important. One of the common issues that people encounter is that the number of PDO connections allowed was maxed out. Doctrine keeps the connections alive in case a re-use is needed, but for now doesn’t close the connections once the Kernel shuts down (see: https://github.com/symfony/symfony/issues/2672). This issue has been closed as not related to Symfony, but I can’t figure out whether it’s been updated in the Doctrine bundle. So far it doesn’t seem so.

The workaround proposed in the 2 issues referencing that problem has allowed me to do a few more tests until the same problem appeared again. The solution that works best for me was to actually close the Doctrine connection on the tearDown of the PHPUnit test like this:

Now I run all my tests without ever having this issue come up again.

Bonus!

Even better, my tests run WAY faster than they did before! The normal test run is between 10 to 30% faster like this. But running the tests with code coverage now takes me less than half of the time it did before this change.

I recently found on Coil’s blog, here: http://www.strangebuzz.com/post/2012/01/28/Load-fixtures-with-Symfony2 how he went about creating fixtures from Yaml files in Symfony2. This is something that I’ve been willing to have for a while.

But I needed more than just loading the data from Yaml. My need for easy to use fixtures comes from testing and setting up the database for test purposes. Fixtures can have many different needs. You might need some of them in production because they bootstrap your database (for example set the client_contract possible status to prospect, proposal, signed_contract in a contract_status table), some of them are required for development. And some of them for testing of course and for testing you might even want different possible cases.

New Bundle!

Based on this idea I created a new bundle for this purpose: https://github.com/khepin/KhepinYamlFixturesBundle

The bundle allows you to define fixture files in the YAML format of course. You have a command line tool to load all your fixtures in database. As well as a service living in the DIC so that you can load fixtures in your test setup function.

Contexts

The bundle provides a notion of “contexts” which might be the ‘production’, ‘test’, ‘dev’ cases we just talked about for example. This allows you to either load only the standards fixtures or load the standard ones plus the ones specific of a given context.

Well that’s it for now, but I hope it helps many of you I’ve seen looking for this on the interwebs. Any feedback is welcome to help make it more usable for not just me.