Left On The Web

WeCamp: Everybody Is Welcome!

| Comments

Last month we announced WeCamp, an event where developers can improve their skills not just by listening to people, but also by actually doing things. Response has been amazing: Many people love the idea, we’ve already sold quite a few tickets, and we’ve even got Magma giving a ticket as a price (At the time of publishing of this blogpost there’s only a couple of hours left, so if you want to win, be fast!). Since announcing the event, I’ve talked to several different people who had the same doubt/question about the event, so I thought I’d clarify things a bit more.

Who should come to WeCamp?

Everyone! We don’t want to exclude anyone and we actually think everyone would be a huge asset to the event. I’ve had people say “I’m not experienced enough in development to attend”, to which I could only respond “untrue!”. The idea of WeCamp is that you don’t just train your technical skills but also your social skills. For a less experienced developer, the practical experience of working in a team with more experienced developers is priceless. In that same team, however, the most experienced developer gets the additional experience of helping a less experienced developer with the work, gaining a lot of experience and knowledge on how you can help others. This social aspect is easily just as important as gaining technical skills. So both developers come out of this gaining experience.

But I’m a frontend developer…

So? If you’re a frontend developer, have a look at the many websites created by pure backend developers… do they look good? Are they accessible? Built according to W3C standards? Most probably not. You’re needed! While we have a focus on PHP, you’ll learn to work with PHP developers: How to communicate with them, how they look at frontend work, what tools are available in the PHP ecosystem for frontend. And I know this may sound scary, but you’d perhaps even get some PHP skills as well.

Additionally: WeCamp is not just about technology. We’ll go through all stages of a project, starting at thinking of a good idea through planning to development, deployment and perhaps even marketing! There’s more than enough to learn throughout this whole process.

But I wonder about…

If you have any more doubts or questions, please let us know! This is the first time we’re organizing WeCamp so we’re still very much looking for what works best with a lot of things. If there’s any unclarity, or you have comments for improvements, let us know! You can always tweet at us @wecamp14 but you can also shoot us an email: we-can@weca.mp. We’re also here to learn, so please help us do just that!

Why Your Current Developer Is Terrible

| Comments

Earlier today I got pointed on Facebook to this article by Shamoon Siddiqui on Medium.com. I would very much recommend this article to both developers and managers. This is an excellent read. It also made me think about my role.

First of all: I’ve been on both sides of the above story. I’ve been the new developer hating on the previous developer, and I’ve been the guy who left hearing stories about the new developer. And to be honest: When you’re a new developer looking at an existing codebase, you’ll spot a lot of bad things. You’ll probably also spot a lot of things that you think are bad things, but are simply different than how you would’ve solved it. There is a difference!

My current role is different. As a consultant, I come into companies with existing teams (or sometimes just a single developer). I’m still in the same role though: I am the “new guy” coming in and spotting weaknesses, errors, problems etc. The difference, however, is that I’m there for this specific reason: I’m usually called in to help improve a codebase, fix a project, etc.

Over the past years of doing this work, I’ve also found out that there are many reasons why the codebase is, let’s say, suboptimal. This has to do with many things, but interestingly, very often it has very little to do with actual technical causes. Just to list a few:

  • The developer presented himself or herself as a senior, while they were actually not that senior
  • The management was not able to make decisions, causing developers to have to switch between tasks and solutions constantly
  • The developer(s) and management don’t communicate well
  • Sales and delivery are two seperate isolated parts of the company

There are more reasons, but the above are the most common reasons I’ve encountered so far. Let me dive into all of those a bit more.


I’ve seen it happen many times: A new developer is hired by a company. Their CV looks impressive: 8 years of experience with PHP. Definitely a senior developer! And since we need to focus on good quality, we need a senior! Then once the developer starts, it turns out the developer isn’t all that senior. Tasks take longer than expected, the software contains more bugs than expected, what happened?

Now, the first problem is: What is the definition of a senior developer? To me, a senior developer is not necessarily someone with lots of years experience. You could have 8 years of experience building websites and CMS’es for customers, but when you join a company building enterprise-level e-commerce solutions, you’re not a senior. Sure, you know PHP and you’ve solved the CMS-problem over and over, but what’s your experience with payment systems? Invoicing? E-commerce has a completely different set of problems to solve. Some solutions that work for a CMS might not work for E-commerce. Seniors know this. They don’t know the solution to all the problems, but they know the solution is not always the same. They communicate well, can explain a problem, and know where to look for a solution. A senior knows (s)he doesn’t know everything.

When hiring a developer, don’t blindly look at how many years of experience the candidate has with PHP (or whatever language you work with). Also have a look at the variation of the projects the developer has worked on. Unless, of course, your company operates in the same business as this developer with 8 years of experience in a specific field. Then you do want to hire the developer. Well, if everything else checks out.

Decisions, focus and quality

Talk to any developer and ask them what is one of the biggest causes of bad code, and they’ll tell you it is a lack of focus. Not being able to focus on a single task from start to finish ensures the code that is being delivered is of less quality than it could be.

One important reason for a lack of focus is not the fact that your developer checks their Facebook or Twitter regularly, or that they go out for some football or play on the gaming console three times a day. No, it’s usually that your developer(s) are not protected from distraction caused by the business.

When I worked at a product-focussed company years ago, we had this issue. On a regular basis, while working on a feature, someone would stand at the desk of a random developer and ask them to “quickly do this” or “fix this bug, it’s highly critical!”. Because of this, we never made our planning and the amount of bugs in our code was sometimes unacceptable.

Our team lead then made the best decision ever: He told us to redirect everyone to him. He would then decide on the priority of the request and put it into the planning. This was paradise! Within weeks, people didn’t even come to us anymore, but instead went directly to the team lead. We could focus on our tasks, reached our goals, and the quality of our code was higher than ever.

Our team lead, however, got no programming work done anymore. Instead, he would gather requests, determine priority and requirements and ensure all the tasks were ready for us to pick up. Another very important task: He made sure that the request was an actual decision, instead of just an idea that would have to be rolled back again in a month. A lot of bugs are caused by implemented features that have to be rolled back, partially rolled back or changed after being implemented.

Looking at current methodologies, the scrum master role comes to mind. But you shouldn’t just name someone scrum master and expect things to work well. Being a scrum master is usually a dedicated task. You can’t really expect the scrum master to get much work done aside from being a scrum master. At least not if you want the scrum master to do a good job.


Good communication is an art. It is a specialty. As I said above, a true senior developer is able to communicate. Communication isn’t easy.

The most important thing in communication when it comes to (technical) projects is to ensure that both sides mean the same thing. This can be really hard, because of very specific terminology being used by developers, customers, managers, etc. They all use different words for the same thing, or sometimes the same word and mean different things. It is important to realize this. Once you know this happens, you can ensure that you all mean the same thing. If a feature request comes in, make sure that the specifications are extensive. Go through the specifications together to ensure you’re on the same page. Do anything you can to ensure you mean the same thing, then both sign off on it.

Whatever you do, always try to keep an open mind in communicating with everyone. Make no assumptions and try to clear up any unclarities there are. This makes a lot of sense, and seems common knowledge, but I’ve seen so many problems arise from not actually doing this to want to write this down. Again. And again. And yes, I’ve fallen into this trap.


One of the worst situations I’ve ever been in (at several different companies, a lot of people seem to make this mistake) was that sales was an isolated team. They’d go out to customers, talk to them, try and find out what they wanted, then “communicate” (yeah, see what I did there?) the requirements to the developers to get an estimation. Then they’d go back to the customer with the estimation and a price. The customer (it is a customer after all) would try to get a lower price, which usually would succeed, and then the project would be given to the developers. Development would take up the specs, build what was in there, deliver it, and the project would (partially) fail. Time and time again.

The cause of this would usually be the isolation of both sales and delivery. Sales did their thing, then delivery did their thing. But they’d hardly ever communicate. This would cause incorrect specifications, incorrect estimations, incorrect end products and unhappy customers, developers and sales.

It might sound scary, but development is teamwork. And the team consists not just of developers, but also of sales. You work together. Talk to your customer together. Write specifications together. You share the praise together and you share the blame together. Sales needs to understand how development works and developers need to understand how sales works.

So why is my current developer terrible?

Actually, your developer isn’t all that terrible. Chances are, the developer is exactly what you could expect of him or her. Your expectations might be wrong though. Or you might need to work on communication, on processes, on your company. Have a good look not just at development, but at your company as a whole. Then you might understand the cause of the problem. Or, of course, hire a consultant to do that. Here’s a good place to find one.

WeCamp Excitement

| Comments

Last night I made one of the most exciting announcements of my professional life. At the AmsterdamPHP meetup I announced the first conference-like event that we’re organizing with the Ingewikkeld-crew. One of those things that I’ve done quite a while now for different usergroups (organizing events) is now also part of my work, and that feels pretty good.

Ever since I organized my first event (PHPCamp) for the company I worked for at that moment (Dutch Open Projects) I’ve liked doing that. Arranging speakers, the venue, sponsors, thinking of cool stuff to do. All that stuff is awesome, and I love that. From the moment I started Ingewikkeld I wanted to do an event. And we’re finally doing it!

To give you some background: I love conferences. They inspire me to dive into new technologies, research topics, hack around a bit, play with stuff. My main frustration around conferences is, though, that once I get back from the conference, I need to get some work done again. And usually that means my “technology to check out”-list only grows longer. I hardly have time to really dig into things after the conference is over.

Combine that with the fact that I learn much more when actually doing stuff and I hear the same thing from many people I talk to. I thought it would be good to do an event where people don’t just listen, but actually work on a project.

On a great day somewhere in the summer last year, Mike, Jelrik, Marjolein and myself sat down for a brainstorm. We started just throwing out ideas to see what we could do. We let it sink in for a while, and then started working on filling in the blanks, finalizing some ideas, and arranging things we had decided on.

The location turned out to be the first major challenge. Our initial idea was to find some kind of boyscout-venue. This would ensure electricity, some basic facilities and hopefully an Internetconnection. It turned out this was actually pretty hard, and we didn’t find such a location. We had a quick brainstorm to think of alternatives. Campsites were an option, but then we started considering more special locations: islands. Some searches led to island De Kluut, and after a meeting with someone from De Kluut, we knew we wanted to get this place.

There was only one big challenge: The island is very natural in that it does not have cables of any kind leading to the island. Electricity is not really an issue: They have solar energy collectors and backup generators. But the other pretty big challenge when you don’t have cables is an Internet connection. We had two main options that both turned out not to work for our situation. Eventually, someone came up with a company that provides sattelite Internet for events, and that turned out to be exactly what we needed.

For ticket sales, EventBrite was our best option and since I’d had enough positive experience from the buyer-side, and after researching it could do all we wanted, I signed up for an organizer-account and set up the event. This was very easy. The only frustrating thing was that I had to make my event public before being able to get an embed-code from their control panel. Since we were trying to create a hype by anonymously dropping some goodies at local usergroups, we didn’t want any trackable lines leading back to us. With some last-minute working, we got all of this sorted. Apparently, there were people thinking WeCamp was initiated by Ibuildings or AmsterdamPHP. Only a few people actually thought it was us.

And now it’s there. We’ve announced. A good feeling. Especially with all the positive response we get from people. Everyone basically says the idea is awesome. And ticket sales are already going better than expected. All early bird-tickets are already gone. And since we’re keeping this event small, that means there’s only 30 regular tickets left. Exciting times. There’s still much to do (organize fun activities, arrange some more sponsors to at least break even, arrange a couple more coaches, etc) but it’s a lot of fun. I’m looking forward to the last week of August. It will be EPIC. It will be WeCamp!

Some Thoughts on Recruiting

| Comments

Recruiters. Many developers hate their guts, and (in most cases) rightfully so. They usually have no clue about technology or about how to communicate with developers. It is also pretty clear most of the times that they’re only out for quick wins. I’ve seen recruiters call a developer they’d placed in a company exactly 6 months after he started to see if he wanted to move on, because 6 months was the period in the contract between the employer and the recruiter. I’ve seen recruiters tell candidates that the employer wasn’t interested, just because the employer didn’t want to pay the extremely high recruiter-fee. Hell, my first professional PHP job was like that. I ended up having direct contact with the employer because I didn’t believe the story the recruiter was telling me, and landed a pretty cool project. Some of the people I worked with there are still friends.

There is a flipside though: There are recruiters out there that do understand how things work. They know how developers work, communicate, what they feel is important. They are rare, but they do exist. So it would be stupid to just say “don’t work with recruiters” to companies or to developers. The thing with working with recruiters is: It takes time. You can’t just give a recruiter a profile and wait until they get you developers, or tell them you’re looking for a job and wait for the interviews. You have to invest in the relationship with the recruiter, do some research, get to know them, and ensure you’ve found one of the good ones.

The role of a recruiter

Many companies I’ve worked at, with or been in touch with expect a recruiter to look at their huge list of available developers (here’s your first mistake, because how many developers are actually available?) and give you the best developers based on a (usually incomplete) profile. But what exactly is it that a recruiter does?

Most recruiters have very little technical knowledge. They’re networkers, they create a network amongst developers and companies and try to link one with the other when they get a request. So from the majority of the recruiters, you should not expect that they make a judgement on the seniority of the developer or his skillset.

In an ideal world, the recruiter you work with actually has a development background and keeps his/her development knowledge up to acceptable levels. Ideally, the recruiter should be able to judge the skills and level of any developer they send your way.

Think about your reasons for hiring a recruiter

Before even contacting a recruiter, you need to ensure you’re doing this for the right reasons. Many companies simply expect the wrong things from a recruiter. As I mentioned before, you can’t just give them a profile and wait for the developers to come in.

Simply outsourcing getting potential candidates should not be your only reason hiring a recruiter, at least not if you want to save yourselves some time. The time you save by getting in the candidates, you will most probably spend doing interviews with candidates that do not actually fit your profile. The amount of times I (specialized in PHP with very little experience with other languages) got approached by a recruiter for a Java or Python-project is beyond belief. Getting 10 CV’s from a recruiter is not a good thing. It’s a bad thing. Instead, you’d want to get one or two CV’s of developers that actually are what you look for.

Even if you have a good recruiter, don’t expect to save much time on the recruitment process. Even if they immediately pass you the right CV’s, you’ll still need to make the final judgement on whether the developers are good or not, and of course convince them to work for you. You’ll still need your own HR-people to handle everything.

Take back your own recruitment

It may be worth your while to consider taking the recruitment back into your own organization. The most important task for a recruiter is to find the right developers for your organization. This may seems like a task that takes a lot of time, but it is easily combined with other stuff you already do (or should do).

The best representatives of your company when it comes to finding developers are your developers. They can speak to potential developers on the same level, can explain what the challenges are and what the fun aspects are of working for your company. They are also the best people to try and find out if a potential developer would fit your company, both in skills and in personality.

So if you have a position for a new developer, send your existing developers to usergroup meetings and conferences. Let them get in touch with other developers, potential employees. Don’t tell them to go out and find people, but tell them to keep their ears and eyes open. They should not try and force the “want to work for us?”-conversation on people, but once the topic comes up, they can of course start talking about it. And they should. The best advertisement for your company is your developers who passionately speak about their work at your company.

Invest in finding the right recruiter

There are many reasons for not putting the recruitment task on your developers. One of them would be the fact that the job opening is there because the developers already have way too much work.

Whatever your reason is for wanting to hire a recruiter, you need to invest in finding the right one. When you hire the wrong one, there’s many things that can go wrong:

  • The recruiter might start spamming his whole database. This reflects badly on your company
  • The recruiter might come up with completely unfitting developers, spending much of your time on nothing
  • The recruiter may not represent your company well, leading to expectations with your potential developer that you can’t fulfill.

If you think it through, there may be even more reasons that can go wrong when you’ve got the wrong recruiter. So invest time in finding the right one: Meet with several recruiters, don’t just hire them based on a single phonecall. Meet with them in person and try to find out how they work: How do they find the right developers? Do they just mass-mail, or do they select the right people from their database and approach those people? How do they find out what the level is of a developer?

Another good idea is to have one of your developers talk to the recruiters. Developers are pretty sensitive about recruiters so they usually have a pretty good idea about what type of recruiter they have in front of them after only a short meeting with the recruiter. Learn to trust this gut feeling. It is more powerful than you might think.

Do some research. Bad recruiters are easy to spot. They are the ones that have a lot of job openings on LinkedIn, preferably in the discussions-area of LinkedIn Groups instead of the Jobs area. They may try to start their own PHP usergroup in a city where a popular PHP usergroup already exists, just to lure developers to them. Their names get mentioned on Twitter and Facebook by developers who get easily annoyed by them. There are enough ways to spot the really bad ones. Also, since good recruiters are rare, they are often recommended by developers. You’ll find good recruiters actively participating in the PHP community, their company names may be listed as sponsors for usergroups and conferences and they’ll actually be at conferences and talk to people.


There is nothing wrong with the concept of recruiters. There are a lot of really bad recruiters though, and you’ll want to avoid them. First of all, decide whether you need recruiters in the first place. And once you decide to use recruiters, invest some time in finding the right recruiters.

Update: After some feedback from Phil Sturgeon and Ivo Jansch, I’ve slightly updated the wording of this article.

Prototyping Your Experience

| Comments

Whether in a professional environment or in private, prototyping (or making a proof of concept) is a useful tool. It is something people underestimate though. Frequently I hear people thinking the time spent on a prototype or proof of concept is a waste of time. NO, IT ISN’T

Just this morning, I was reading this article by Ed Finkler on Tribalism and I was thinking about it. Ed describes tribalism in the tech-world, and I could totally understand what he was talking about. The fact that terms like “browser-war” and “framework-war” come by in our world. The fact that we always put Drupal against Joomla! against Wordpress is proof that we live in a tribal techworld. And as Ed writes, this is not necessarily a bad thing, but it usually comes with some negative side-effects.

I’ve done projects at a lot of web agencies where the company had standardized on a single framework or a single CMS. And with “standardized”, I mean, that was the only technology being used, and aside of perhaps some individual libraries, if some solution did not exist for that chosen technology, they’d build it themselves without looking outside of their tribe. I usually question such behaviour, and the response I regularly get is “we can’t all know everything about every (framework|CMS)”. Of course I agree with this: In the fast-moving world of technology we live in, you can’t be an expert in every available technology. The thing is: You don’t need to be an expert in every technology. You need to know just enough to know when it can be useful.

And so I get to prototyping. Prototyping (or making a proof of concept) is nothing new. It’s definitely not limited to software either. Better yet, given the dynamic nature of software and the pretty static nature of other industries, it is even better suited for those other industries; imagine building an airplane without building a prototype first. You’ll never know what’s wrong with the design of your plane until it crashes with 250 people inside.

Aside from building a prototype to testdrive your design and see if it is any good, you can use the prototyping approach also for your own good. An important thing to realize is that a prototype is not a production-ready product. It is something you build to prove to yourself that a concept works, or to try out one (or several different) approach(es). And once you’re done, you can always decide to throw away the prototype and start all over.

The thing is, you can use prototyping for the projects you do (and you should definitely consider this approach when you’re not sure about a proposed solution), but you can also use prototyping for learning things. Actually, while prototyping, you usually learn anyway. But consider using it for learning a new technology for a change.


Let’s take a practical example. When Symfony2 came out, I was deep into symfony 1. However, Symfony2 was completely new and different from symfony 1, so I needed something to try it our and learn the concepts. I decided to build a very simple website that would aggregate all the links posted to twitter with the #linktuesday-hashtag. I started my first Symfony2-project and started playing around. Once done, I decided to open source it and publish the website. But the most important thing of this project was: I learned the basics of Symfony2.


A similar example is gowat.ch. I wanted to dive into the Silex microframework. It was a hip thing to do at that time to have your own custom URL shortener, and since a microframework is a good fit for that, I decided to write my own shortener with Silex. As with LinkTuesday, the end result was good enough for me to actually put into production. For me at least. But again, the most important thing was that I now know Silex and knew when to use and when not to use Silex.

And it goes on…

You might be aware that I’m a big advocate for interoperability and using multiple frameworks in projects wherever it makes sense. I’ve done several talks on the subject. One of those talks I did with Enrico Zimuel of Zend Framework fame. We’d done a talk where we used some simple examples. Last year, we were going to do the talk again at the Forum PHP conference in Paris but we decided we weren’t happy with the examples. They were clear, but did not contain practical use cases. So we sat down together to write a prototype of an application that would actually use both frameworks, or in this case it would use Symfony2 and Zend Frameworks Apigility project for RESTful APIs. It took us a day of playing around, but we ended up with a prototype that worked and showed exactly what we wanted: That it is possible (and easy) to use the Doctrine entities from a Symfony2 project to create a RESTful API with Apigility. In the process of doing so, Enrico learned some stuff about the Symfony2 bootstrap (hell, I learned some things about the Symfony2 bootstrap), and I learned the basics of Apigility. Enrico even shared this knowledge in a blogpost.

Failure is success

The examples I’ve given so far are all examples of projects that actually made it to the outside world in one way or another. But there are many projects that I’ve started that either failed or that I just decided were not good enough. The thing with the prototyping approach is that failure is success. It’s not about the end result of the project, it’s about the process of building the prototype. It’s about using a new technology, about finding out how that technology works, how to solve the problems you encounter with that technology. It’s about gaining knowledge on which problems this technology solves, and which problems it doesn’t solve. As I mentioned before: The goal is not to become an expert, but to know when you should and when you shouldn’t use the technology, so that in a future project you can decide which technology you should use to solve the problem at hand.

The business side of things

Coming back to the agencies that said “we can’t all know everything about every (framework|CMS)”: Absolutely! However, you should be aware more of the world around you! Invest a couple of hours a week or even a couple of hours a month in working with a different technology so that you become more aware of other technologies. You don’t have to completely switch to a different technology, you don’t even have to master that technology, but just being aware that it exists is already a great asset for your company and your development team(s). You could even have different people look at different technologies and then present their findings to eachother. Or make it a competition: Have different team members build the same proof of concept with different technologies, and see which is the better solution. Enough possibilities to get more knowledge with a limited investment.

Learning is key

We work in an ecosystem that is ever changing, always evolving. New technologies come in to replace old technologies or to work side by side with the technologies we all love. It may sound cliché, but the snoozers lose in this world. Standing still is not an option. We need to keep learning. Forever.

Get Rid of Session Files in an API

| Comments

A quick blogpost about building APIs with Symfony2 and FOSRestBundle, just so I won’t forget this and can always refer to this blogpost if I start wondering about this again…

Some time ago I inherited an API project that was built on top of Symfony2 and the FOSRestBundle after the previous developer was unable to continue his work due to personal circumstances. I finished the project and everything was up and running fine. A couple of weeks ago, I got an e-mail from the customer because their systems had lots of issues. It turned out that the session-directory contained a couple of hundred thousand session files. This seemed odd, since there is a very limited web interface to this API.

The first thing I did was pragmatic: I wrote a simple command to clean out the session directory from files older than 1 hour (since sessions typically last only a couple of minutes). This was the quick fix, but it didn’t sort the cause of the problem.

This morning, I actually dove into the code to try and solve the problem. And the fix was literally a one-liner. In the firewall configuration, I just needed to add a single line:

        pattern:   ^/api
        wsse:      { nonce_dir: null, lifetime: 3600, realm: "Secured API", profile: "UsernameToken" }
        anonymous:    true
        stateless:    true

The last line was all that was needed: It configures Symfony2 to work in a stateless way for this firewall. And stateless applications don’t need sessions. Such a simple fix, but it takes a short while to figure it out.

What Makes a Good Conference Great

| Comments

TL;DR: The people and the atmosphere


First some context: In the past months, I’ve been lucky enough to have been at both the PHPNW conference in Manchester, the TrueNorthPHP conference in TorontoMississuaga, and PHPBenelux in Antwerp. I’ve been to those conferences before and hope to be at them again in the future.

Right after TrueNorthPHP ended, I tweeted:

I’ve always said #phpnw is the best PHP conference in the world. #tnphp is a close second. #tnphp is the #phpnw of North America

Quickly thereafter I made a promise, so here it is. It took a while, but if I promise something, I need to keep that promise.

What makes a good conference?

For a lot of people, the content makes the conference. And of course, the content is one of the most important things at a conference. You’re there to learn, so you need to have some good content, otherwise it’s all a bit useless. Well, not completely, but if the main purpose of a conference visit can’t be fulfilled, what are you doing there? Additionally, it’ll be very hard to get your boss to pay for a conference if there’s no useful content.

I’ve been to a lot of conferences, and the content is usually excellent, but there is a lot of difference in how I experience a conference. This difference has hardly anything to do with the content. Looking at, for instance, Dutch PHP Conference, PHPBenelux, PHPNW, PHP[tek] etc, the content is similar. There’s minor differences, but you’ll see a lot of overlap in topics (and sometimes also in speakers). It is ultimately the people and with that the atmosphere of a conference that makes the difference for me between a good and a great conference.

How to get the right people?

Getting the right people, or actually the right mix of people, is not easy. It is a mixture of a number of things:

  • Select the right speakers
  • Keep entry prices low
  • Promote in the right places
  • Create more than a conference

Funny enough, I’ve found that conferences with a big community-aspect to it have a much better feeling for this than commercial conferences with a marketing or profit aim. I think (but this is a guess) that this might be because the more community-involved conferences are run by more technical people, who know what technical people want.

Select the right speakers

The speakers should aim to reflect the full audience that you’re trying to reach. And no, I am not talking about gender, race, sexual preference or any of those things. They don’t matter. The schedule should reflect the topics you want to cover and the levels of developers you’re aiming for. If you’re aiming for architect-level visitors, it is no use to put up an intro to Symfony2. If you’re aiming for a conference where beginning developers and seniors/architects meet, make sure your schedule reflects this by putting up a mixture of all levels and topics.

Keep entry prices low

Keeping entry prices low is important for getting people in. Some employers don’t pay for the tickets of their employees, and self-financing some couple of hundred euro’s is hard. Sponsors go a long way in financing conferences, ensuring you can keep the ticket prices low. This is also where community-conferences have an advantage: They don’t need to make a profit. Their only agenda is to offer great content to as many people as possible. Commercial conferences of course can’t really change that, it’s just the nature of the conference. This does mean that community conferences are at a slight advantage here…

Promote in the right places

If you’re aiming for an enterprise conference, obviously you advertise in magazines aimed at CTO’s and big companies. If you’re focussing starters, there’s different places to promote. Get those usergroups on board in the promotions, find the right websites and magazines, etc. Usually, finding some key community members will do a lot towards getting in the right people.

Create more than a conference

Organizing a conference is good, but you should create much more than just a conference. It should be a full experience, including social events, a good treatment of speakers, delegates, sponsors and anyone involved. Or perhaps even better, as my friend Michelangelo put it last weekend at PHPBenelux: “We don’t want to create an experience, we want to create the Magic Kingdom.” He compared PHPBenelux to a Disneyland Park, and he’s spot on: From the moment you come to a conference to the moment you leave, you should be part of the conference, whether you’re a speaker, delegate or sponsor.

Creating the magic

There’s more than enough to write about this, but I’ll just give a few small pointers that I’ve seen happen at the earlier mentioned conferences, and that I’ve also tried to apply in the years that I’ve been part of the PHPBenelux and PFCongres crew:

Pick up and drop off speakers at the airport/trainstation

This is not hard, but it makes speakers feel really welcome and appreciated. It’s that little effort you put in that means speakers don’t have to worry about where they are going and how to get there. And while you’re driving anyway, if you are aware of delegates also arriving and you have some room in your car, just take the delegate along. This makes the delegates also feel as an important part of the conference.

Don’t seperate speakers from delegates

I’ve been at several conferences where there was a completely seperated speaker room. While it is awesome to have a place to sit down, plug in your laptop and work for a bit, usually speakers also want to mingle with the crowd. Instead of creating a seperate speaker room, why not just create a place to hang out for everyone at the conference, with powersockets and some tables and chairs. Offering a seperate room for speakers to get some peace and quiet is not a bad idea, but don’t make that room the only place where people can sit down and do some work.

Create epic socials

A social event at a conference is a place where people want to have fun, chat, laugh etc. Make sure that people get just that out of a social. Make sure there’s room for people to sit and chat, avoid loud music, and if possible, arrange some entertainment. Last weekend at PHPBenelux, there was a carnival in the sponsor area (every sponsor had something, for instance arcade games, coin pushers, air hockey, X-box). They even had bumper cars! Last year at php[tek], there was lots of Legos to play with. PFCongres had a gamenight. These are the things people enjoy at a conference. They are the difference between a good conference and an EPIC conference.


In short: Every conference is in essence the same: Good content with good speakers. I’ve not yet been to a single bad conference when it comes to content and speakers. The difference is made in all those little extra’s. Spending a little effort on those extra things will make the difference.

That Little Detail in Converting services.xml to services.yml

| Comments

Here’s a little detail that got me frustrated for a while. In the project I’m currently working on, we’ve decided to standardize on Yaml for the service configuration over the default XML. Since we already had a couple of bundles developed with XML, I needed to convert those configuration files to adhere to our chosen standard. This took me longer that it needed to, and I couldn’t figure out what the problem was.

The problem turned out to be a tiny little detail that you easily miss. I converted all the keys and values of the XML literally when I converted to Yaml. However, there is one key that needs a small change. When you use the repository-class in services.xml, this needs to be updated to repository_class in the Yaml version. Apparently, Yaml doesn’t really like the ‘–’ and so wants an underscore.

It took me quite a long time to figure it out. Now you know. Don’t make the same mistake! :)

I’m Sorry: An Open Letter to Elizabeth Naramore

| Comments

Hi Liz,

I was going to send this letter as an e-mail, but as I was writing the e-mail I felt it necessary to turn this into an open letter. Everybody should see this, and be aware of this. Everyone should stand up to support you. Openly, not just in private.

It is amazing how much crap you’re getting for TRUCE conference. I am truly sorry for this. This is not the community I thought I was a part of. It has honestly been a huge surprise how much negativity there is in the world of PHP and tech.

Last weekend at TrueNorth I attended the Open Sourcing Mental Illness-talk by Ed Finkler, and one of the most important lessons I took away was to be empathetic and to focus on positivity. The people that go about hatin’ clearly have never heard of this. On the other hand, you clearly do know, as TRUCE is a perfect example of this.

For what it’s worth, I highly respect you for standing up against inequality and all the problems the tech community has. If only I had the finances, I would immediately book my flight to the US and ensure I’d be there. Unfortunately that won’t work, so instead I tried to help you fund the conference with a small donation. Aside from that donation, I would like to really make it clear that I love what you’re doing and I highly respect the things you have done, do and hopefully will keep on doing for the PHP and wider tech community. And though I can’t really speak for everyone in the PHP community, I know for sure that many agree with this.

Please Liz, don’t give in to the hate. That would mean the haters win. And haters should never win. It is the love and passion for solving a problem together what makes the Open Source community so great. Usually we focus on technical problems and coming up with technical solutions, and now we’ve got a social problem at hand. As many have said in response to the hate-storm after the TRUCE announcement:

It's better to try and do something than to just sit by and do nothing to solve the problem

And so, dear Liz, I want to thank you for trying to do something. TRUCE conference can, at worst, result in a good get together where attendees will start understanding each other just a bit better. In the best situation I can think of, it can spark a movement that will change the tech community to be one that is more inclusive, more empathetic and more understanding. Liz, you ROCK.

Indexing BLOB Fields in Solr

| Comments

Just a quick blogpost today about Solr. If I help someone with this post, good. If I help myself to remember this, good.

In a project I’m currently working on I’m stuck with a legacy database where I can’t change the fields for fear of breaking a legacy application that is using the same data. One of the fields in the database that I need to index with Solr is a MySQL BLOB field. I initially just indexed it as is, but that resulted in odd codes instead of the actual text:


Since I use the DataImportHandler instead of writing my own indexing scripts, I can’t do the conversion myself, so I needed a simple way to convert the BLOB to a usable text somewhere in the indexing process. Of course, Google and Stack Overflow come to the rescue. Thanks to this answer to a question about this topic, I know that it is actually quite easy.

select CONVERT(Text USING utf8) as description FROM Book where EAN='${bookproduct.id}'

That’s it! Now, instead of the odd object codes as above, I actually index the text-version of the BLOB field.