The Syntax of Tech Communities

Project
This post is over 2 years old and is probably out of date.

Just like the programming languages that are the centers of our communities, each community has its own set of rules and idioms — they have a real life syntax.

In my (almost) three years of being in a developer relations type role I have attended events in several communities and have observed how they differ from my primary community (PHP). As I’ve tried to understand those differences and the reasons behind them, I have had many discussions with members of many more communities also.

After attending my first PyCon (US) I was struck by just how welcoming and diverse the community is and had many conversations trying to understand why this is. This is not what this post is about. This post is about conferences specifically, and how communities place different priorities on different things when it comes to how they run, organize, speak at, and attend events.

PHP

The first thing I found that was unique about the PHP community is that every event which has an open CFP (e.g. not a local community day, hackathon, etc.) will reimburse at least some travel and lodging costs.

Larger community and for profit events will typically cover all flight costs and at least (number of talks)+1 nights hotel. Some will limit the number of international speakers to keep costs manageable, while others will have a fixed amount of costs they can cover, and the rest is up to the speaker.

In fact, the reason I started speaking at conferences was because of this, I would never have been able to afford to attend otherwise.

These may be paid up front with the conference booking the flights on your behalf, or they may be a refund after the fact.

In the last few years the smaller community events have (probably because it’s a default in OpenCFP) added checkboxes to their CFP which allow you request help for travel and/or accommodation. I think this change has come about as the number of speakers whose jobs are willing to pay their way has increased.

Additionally, you would get a full ticket to the event. Speakers do not get paid anything additional such as an honorarium.

Due to these costs incurred by events, ticket prices are usually somewhere from $150-350 with tutorial days at additional cost. A few events are much more expensive (~$1000+), but are typically not aimed at the community crowd.

Another thing I’ve noted is that it’s common for speakers to submit multiple talks to conferences and this is highly encouraged to people who wish to get a talk accepted: never submit just one!

As for the talks themselves, they are usually minimum 40 minutes (which is rare) and maximum 60 minutes. 50 minutes is the most common format.

Ruby

The community which I spend the most time comparing (mostly with PJ) is Ruby. The first major difference I noticed was that there were no speaker packages. I was outraged by this, it felt like the equivalent of “it’ll be good for your portfolio”.

Then I found out why this was: the ruby community values accessible ticket prices, and wants to have a low price point to make the event feasible for as many people as possible, including students, single parents, etc.

This would be impossible if speakers travel/hotel were paid for by the event.

Speakers are given a ticket to the event, and I’m sure for some its reason enough to speak, while others do it for the exposure and networking opportunities. But additionally they seem to do it to contribute back to the community as well.

Also, when it comes to CFPs, numerous people I spoke to early on were aghast to learn that in the PHP community we submit multiple talks. However it seems that this is changing, and it is becoming more common to do so.

Talks are usually 25 minutes, with the max being 35 minutes. Some are as little as 20 minutes.

Python

The Python community seems to be somewhere in the middle. While Python events do not cover a speakers flight and hotel, the PSF has a formal grant program which allows for those unable to afford to attend to request financial support to do so.

And while ticket prices are not as cheap as ruby events, they do have multiple levels of ticket prices, for example students, regular, and business tickets. For PyCon US, those were $125, $300, and $600 respectively. And everyone buys a ticket, including the event chairs, volunteers, and speakers. Again the PSF grant program can help here.

Submitting multiple talks seems to be the norm. And talks are 35-40 minutes long.

Perl

I have only recently started discussing this topic with members of the Perl community, but they seem to also value low cost tickets, speaker costs not covered, and 35-40 minute talk slots. I may be wrong on this but that’s what I understand to be the case. I am unsure if tickets to the event are given to speakers, or how CFPs are typically done.

There’s No Right Answer

It is obvious to me that community is hugely important to everyone I’ve spoken to about this, and I find it interesting how different communities have different priorities resulting in different conference experiences.

I will say that the Python way seems like a much more democratic and inclusive way to handle things, but that it depends on the PSF which is a core part of its community and requires monumental effort, oversight, and tons of volunteers. As an aside, the PSF also seems instrumental in the inclusiveness and diversity exhibited by the Python community.

At the end of the day, I think we all have valid motivations. The PHP way ensures that regardless of your financial situation, if you have something valuable to share then you can do so, while the Ruby way ensures that the most possible people can attend to hear what is being shared, and the Python way tries to strike a middle ground.

I do find it interesting how consistent things seem to be within communities, perhaps simply through early leaders setting the expectations, but it does show some of the differences of opinion on how to build a thriving community — and yet even with these differences, they are all large, thriving communities.


Image courtesy of Benjamin Horn, used under a CC-BY 2.0 License.

Thanks to PJ and Rae for reviewing this post.

Polyglot Background Jobs with Gearman, PHP, Ruby & Node.js

Standard
This post is over 4 years old and is probably out of date.

Over on the Engine Yard Blog I wrote about a topic near-and-dear to my heart: Gearman.

For those that don’t know, Gearman is a simple C-based job queue server, that allows you to schedule jobs for other processes (called workers) to pick up and complete, either synchronously, or [usually] asynchronously. It can also be connected to via a number of clients in a bunch of different languages, not just PHP.

I’ve used Gearman for about 4 years, but have never had the opportunity to use it in a multi-language environment. So, I took the time to explore both Ruby and Node.js Gearman clients, and put together a multi-language example for this document. Using PHP for the client, Ruby for the workers, and Node.js for a status check poll.

What’s awesome is that any part of that could have been written in either of the other languages, or indeed in Python, C, Java, Perl — heck, I could’ve used MySQL or PostgreSQL!

I’ve always loved that this was a possibility, and it was great fun to actually put it into practice: even if only for a demo.

If you want to read about it, go checkout Polyglot Background Jobs on the Engine Yard Blog.

Learning Rails (and Ruby)

Standard
This post is over 5 years old and is probably out of date.

A few days ago I had a new blog post published on the Engine Yard Blog. The post was actually written, before my last blog post here, and is really more on the same subject; get out there and cross-pollinate. Learn, and share with other tech communities.

You can read the post here: Learning Rails (and Ruby) on the Engine Yard Blog.

I’ve had a lot of positive feedback (on reddit), and surprisingly the only negative feedback I got was via the PHP sub-reddit. I think some people choose to defend their choices simply because they don’t want to have made the wrong ones. But really, there’s no right and wrong answer, and it mostly comes down to preference and little else.

That’s enough meta-commentary from me, read it already!

Distill: An opportunity to get out of your comfort zone

Speaking
This post is over 5 years old and is probably out of date.

As part of my work at Engine Yard I have been involved in helping shape and organize a new conference, Distill, which will be held on Treasure Island in San Francisco, CA on August 8-9th 2013.

The conference will bring together a bunch of folks from different technological backgrounds to share information, and cross-pollinate ideas. Just like Ruby on Rails kickstarted the PHP frameworks explosion, we (the PHP community) have an opportunity to give back not only to the Ruby/Rails community but to Javascript, Python, Java, and database communities, and who knows what else will make a showing.

Hopefully, we can all “get off the island” and allow us to create something awesome.

The Call For Proposals is currently open, and closes on April 9th, and I highly encourage everyone to submit.

Making the case for PHP

Project
This post is over 9 years old and is probably out of date.

One of the biggest decisions you can make for any project is the environment it which the project will be written.

Most developers mistake the word environment for the word “technology” or “software”. For example, you develop in a “JSP environment”, or a “LAMP environment”. This is a crucial mistake that is made time and time again, and unfortunately, it hurts companies because the decision makers either make the same mistake, or they listen to those making the mistake.

I’ve said numerous times, that you can use any language to do anything. Yes, there are practical limits, using C to write a dynamic website isn’t a great idea, nor is using PHP for password cracking. Each language has it’s own strengths and weaknesses; good developers however, know what these are and work with their strengths and work around their weaknesses. This post isn’t going to focus much on languages; I figure everybody reading has already chosen PHP and knows why.

What I will say is this: Ruby, Python, PHP, Perl, Java and .NET all bring the same capabilities to the table (some things are easier in some, and some more difficult in others). You can create any solution you want in each of these languages, in an efficient, well thought out, well developed way. Yahoo! could be written in Python. How do we know this? because Google uses it. Microsoft uses .NET for it’s web presence, and while you might not like to use it, it still stands up to more stress than most of the websites on the internet.

With this in mind, I then would say that the language capabilities themselves, are the least important factor in choosing your environment.

This then brings me neatly to what else that environment encompasses. These, to me, fall into three categories. People, knowledge and penetration.

Access to People

To put it bluntly, if you can’t find the people to write your code, you’re screwed. While you may know what you’re doing, and you have enough people now: your team will need to grow. If you can’t find people around you to hire, then what?

There are estimates that for every 100 PHP developers, there are 42 Perl developers, there are 12 Python developers and 4 Ruby developers. (see: here)

Some will say that this is because there is a lot of bad PHP developers. I will agree to a point, but that point is that there are just so damn many, that there are still more great developers to pick from than with other languages.

Access to Knowledge

While this one is more subjective, I believe that the sheer number of PHP developers generate far more useful knowledge from which to learn, cherry pick ideas and utilize them. Add to that the extensive number of books, and our excellent php|architect magazine; as well as the training and teachings provided by MTA, Zend and ibuildings, we have more going for us than most every other language with, I think, the exception of Java in terms of professionally backed learning.

Market Penetration

Simply put, the availability of PHP as a platform is there from the cheapest virtualhost, to the most expensive dedicated systems. It has gained wide acceptance from smaller companies, because it is cheap and reliable, and from enterprise companies such as IBM, Oracle and even Microsoft because they see that the ability is there for PHP to operate in that space and a huge number of developers willing to make that happen.

Conclusion

No other language can claim this trifecta, sure, there are a lot of .NET and Java developers, but a lot that goes on happens behind closed doors in big enterprises, and the knowledge is not shared. And while this isn’t true of Python, or Ruby, they lack in numbers and knowledge comparatively. This is why I choose PHP.

– Davey