Dienstag, 18. September 2012

symfony 2.1, Commands and Swiftmailer memory spooling

Working with symfony 2.1 for a while now I can say I really enjoy it. Composer is awesome and the new profiler bar is also very nice. I don't use forms that much so I cannot say anything about the new form component.

One problem which took me some time till I figured it out regards the sending of emails within a command when memory spooling is configured for swiftmailer. It just doesn't sent any mails! The reason is very simple once you look in the right direction: Memory spooling means the emails get sent on the kernel terminate event, which never happens when a command is executed. The issue is discussed on github.

Donnerstag, 13. September 2012

symfony2: Testing email sending

On my endless struggle to achieving 100% code coverage and catching every possible (and impossible) test case (I'm just kiddinh, please don't do this!) I was in need for some way to test the sending of emails. This blog post will show you how to test this within a symfony2 (I'm using symfony 2.1 RC2) application, using the default swiftmailer.

Let's be clear hear: I'm not talking about unit tests. These have to be done in swiftmailer or the symfony swiftmailer bundler. I'm talking about functional tests of your application where you want to check if a particular action by your user (or your admin, or your cronjob, or whatever triggers the sending of an email) does lead to an email being sent.

Mittwoch, 5. September 2012

Ship it on day 1!

I don't know what's the matter with us web developers. We have the luxury of being able to release a product and improve it many times without any concernc. We are luckier than software developers who must ship their product through an update mechanism and we are much luckier than any other engineer, who simply cannot improve the product much when it's built.

Yet we stick to the old concept of developing and developing, not shipping till it's "really" ready. This "ready" means a shitload of features nobody will use, a ui most of the users cannot grasp and a long time till any user can experience your application.

I would bet serious money on the fact that most developers agree to this and yet won't do it. One thing which always comes up is the set of critical features. To me, there is not one feature which is critical. Just get up the first page and get it out there. Set up a signup page for beta users. Start implementing the first feature, create an account for yourself and start using it. If you think it's worth trying for somebody else, let them have access to it.

If you start implementing a new feature, get it out there and just let a selected group of users access it. See what happens. You can polish it later. You can add the missing subfeature later. Nobody will stop using your service just because there is some object which cannot be deleted right now. Or updated. Nobody will stop using it because there are some design flaws.

People will stop using your product when they wait 1 month for a set of features and then get crappy functionality they don't need.

On the other hand, people will love you when they feel they are in control: They mention some improvement and the next they it's there. It may not be perfect, but they can achieve their goal. They can use it and see what can be improved.

Or, as the guys at opbeat say: Fuck it, ship it!