The Accidental ScrumMaster

November 15th, 2011 — 9:07am

Since my role has changed over the past few months away from being a pure developer to a lead of an agile (scrum) group here, I’ve started blogging some about my experiences over at The Accidental ScrumMaster:

Let me start off by saying this – I have been a developer for just about all of my professional career (with some syadmin and networking tossed in to spice things up). I’ve helped to lead other developers in projects where we were focused on just the software and didn’t have to worry too much about outside forces. At my current job, this has changed. Over the last few months, due to some changes in staffing (read that as “people moved on”) holes were left in the team for certain roles. Before those people transitioned out of their jobs, they started to approach me with some of the responsibilities they had and showed me the ropes.

Suddenly I wasn’t just another developer anymore – I was the person managing our Jira project, I was the one doing the code merges and releases and I was the one tracking the progress of the project on a day to day basis.

I hope what I post there can be beneficial to other developers out there who find themselves with extra the responsibilities of making agile happen in their jobs.

Comment » | Agile, Development

Uniqueness in Fuel Models

September 5th, 2011 — 3:47pm

As a part of broadening my horizons, I’m back to working with Fuel, a framework that has a familiar feel to some of the ones I’ve used in the past but has some extra “oomf” from new features and PHP 5.3-ness.

I was working in my models the other day and had a need for uniqueness – I wanted to be sure that the object I was pushing into the database didn’t match any other one. I went through the docs and didn’t see anything about it and a glance through the source didn’t turn up anything either. So, as an alternative, I came up with a method I put in my base model:

class Model_Base extends OrmModel
{
    public function isUnique($modelObject)
    {
        $modelType = get_class($modelObject);
        $found = $modelType::find('all',array(
            'where' => $modelObject->to_array()
        ));
        return (count($found)>0) ? false : true;
    }
}

The code above finds the class name (the model the object is made from) and tries to find anything with exactly the same properties. The “to_array()” method is something Fuel has to translate objects into handy arrays.

Fuel ORM docs

2 comments » | FuelPHP, PHP

The Joind.in & I

September 3rd, 2011 — 8:48pm

By now I’m sure a lot of the folks reading the posts from this blog know of the site I’ve helped shape over the past few years, Joind.in. It’s become most successful in PHP circles, but has branched out into other communities, both tech and non-tech. Not too long after the project started up, it was decided to open source the code and pull in contributions from whoever offered their time. I personally feel that, for a first out of the box open source project for me, it’s turned out well and has a great, active community around it. I’ve learned a lot working on not only the code but in management of the project as well.

I’m taking a break from all of this for now though. I know, Joind.in has been my baby for the last few years, but I’ve been feeling a little burnt out on it the last few months and I’m starting to feel like it’s having a negative impact on the project. My plan is to take a few months to regroup myself and pull my head out of the code and maybe even get a better, broader picture of what the project could become. My priorities are shifting towards another project I’ve been putting in some time on (no hints yet) that I hope can be a good tool for a similar community.

The management of the project is being put in capable hands, though – no worries there. Lorna will be the gatekeeper for all things Joind.in. She’ll be handling both the site and the open source project in their day to day needs. I’ll still be lurking around in the same places, but I won’t be as active in the project as I have been.

Thank you to the community that has made the site everything it is and I know it will grow even more in the months to come. Thanks for your contributions, both in code and even just in kind words. Please keep them coming and if you’re a fan or contributor of the project, ask Lorna if there’s a helpful hand you can lend. I know she’d appreciate it.

UPDATE: You can also see Lorna’s post here.

2 comments » | Community, joind.in, PHP

Joind.in + Combell FTW

August 2nd, 2011 — 7:47am

A while back we (the team leads of the Joind.in project) made the decision to move off of the hosting we were on and up to bigger and better things. Slicehost was a good place to start, but our needs were moving beyond what the little VPS was providing. Through a fortunate series of events, Thijs Feryn set up some space for the project to live on in the Combell servers. This allowed us to more easily set up things like a Hudson instance for deployment and a full test site. Here’s the info from the blog post over on Joind.in:

In recent weeks the Joind.In project has moved onto a new hosting platform. After launching the project in a quiet corner of the server used to host phpdeveloper.org (both are the brain-child of @enygma), it had somewhat outgrown the resources available to it as more and more people used it for more and bigger events.

The new platform is generously provided by Combell, who are a large Belgian ISP. They are familiar faces (and often sponsors) at technical events in Europe, and we’re very happy to have them supporting Joind.In! We now have a dedicated platform for the site, a staging area and a build server, all thanks to the support we have received.

In particular we’d like to thank Thijs Feryn who made it all happen, and of course Combell themselves. You can see their logo in our sidebar and footer, so do check them out.

We’re looking forward to some of the great things this move and new technology will allow us to do in the future of the project. If you’d like to get involved, go over to the github repo for the project or troll through the bug list and pick up something to work on.

Thanks again to Combell and to Thijs for their contribution!

Comment » | joind.in, PHP

You’re Open Source…Now What? (Communication – Part 3)

June 24th, 2011 — 9:01am

So, what started out to be a post or two on some of the important things to consider about communication in open source projects, has now turned into it’s own little mini-series. In part one I talked about some of the important things to consider when it’s you, the organizer, talking to the people that come in and want to get involved with your project. In the second part I covered some of the organizer-to-organizer communication techniques to keep the project running smoothly.

In this part I’m going to focus on something that’s a bit harder to control, but can still make a huge amount of difference in your project’s life. Contributors talking back and forth with the organizers is fun and all, but sometimes they just want to skip a step and go directly to another developer. Dev-to-dev communication is absolutely necessary to make a project thrive. If a developer comes in and the only chatter they see on a mailing list is the project’s admin taking to various people, chances are they won’t stick around too long. People want to see life, they want to see lively discussions and ideas being explained and played off one another.

There only one real issue – you can’t control this.

You can, however, make use of some tools that make it a lot easier. As I mentioned, mailing lists are great tools to have for your contributors to ask questions and get their own ideas across. You have to encourage this, though – it’s not just going to magically happen. Sometimes you have to get the ball rolling by asking a few questions yourself first, but once that ice is broken conversations will more easily pop up. Even just a response or two to a question you posed to the list can spark ideas from other developers not even interested in the original thread. Challenge yourself to, at the start of every week, try to come up with a topic that you think needs to be discussed on the project and start a thread on the list. It’s okay if the majority of the activity at the project’s start is from the organizer(s). Lots of people have their opinions, some are just more forthcoming than others with them. Having a good “feel” for the list helps bring these out.

A second tool that can be invaluable for any project, just starting out or already mature with its contributor base in hand, is something that several of the code repository sites (like github or Bitbucket) offer as a part of their service – the ability to look at the changes someone’s committed to their branch (or to trunk), see the differences and comment on them right in the same page. Previously, version control systems have sent out commit emails that might have included the diffs from one version to another. This is good and all, but developers would need to respond to these emails with their suggestions and, well, as I’ve already mentioned, email is really more about the point-to-point rather than for lengthly discussions.

There’s a huge benefit to having a record of all comments related to change in the code right there in front of you. Github will even let you make a comment about a specific line in the change and all parties involved in the discussion are notified. No more batting around emails and trying to keep track of how many “Re:” there are in the latest response.

The final recommendation I’ll make is probably the most tricky depending on the size of the project. If at all possible having developers on your project physically in the same room makes amazing things happen. Take, for example, the Hackathon that happened at the last php|tek conference. Several developers were all there with the intent of working out some of the bugs in the Joind.in project as well as several others (including writing tests for PHP itself). Remote communications can be efficient, but there’s nothing quite like sitting across the table from another developer poking around the same code you are and hashing things through. Obviously, the Hackathon was a rare event, but if you’re even able to just get two or three contributors together, do it. Conferences are a great place to organize things like this – there’s people from all over that already know the project and look forward to the community that comes with other developers on the same project. There’s even the possibility of drafting new recruits!

Developer -to-developer communications is one of the hardest to get right mostly because it’s not really something you can control. It’s more of a “throw it and hope it sticks” kind of thing that can really pay off in the future of your project.

2 comments » | Development, opensource, PHP

You’re Open Source…Now What? (Communication – Part 2)

June 23rd, 2011 — 9:03am

In case you missed it, this post is a continuation of another post looking a some of the things I’ve learned in the time I’ve spent as an open source project organizer for Joind.in. In this second post I’m going to keep looking at communication and the role it plays in the project. The focus will be a little bit different, though – this time it’s more about internal communication.

Keeping all of the contributors to your project informed and involved is a task to itself, but this should be only half of your focus. It’s easy to get caught up in the code merges, mailing list threads and even heated IRC conversations about the next fixes that need to be made. It can be fun, trust me – there’s times when it’s easier to just think about the code and where the popular opinion says it should go. Unfortunately, this almost always leads to bad decisions.

See, one of the core things you can’t forget about when you’re organizing an open source project is to keep the “staff” all on the same page too. When you start off small and it’s maybe you and a few casual committers, it’s easy. You can pull out the decisions without having to worry about anyone else. This all changes when you have one or more others come in and start to be a part of the project. It’s a tough transition for a lone gunman developer used to calling the shots to flip that switch in their head labeled “ask the team”. It’s crucial that everyone involved in running the project be on the same page about things. If they’re not, that’s when bad things can happen like major code forks or worse – a poisoning of the project’s community.

I know in the previous article I advocated keeping things out in the open when dealing with the project and its intentions, but there’s a “but” that comes with it. Contributors and casual observers don’t need to be in on some of the organizational decisions related to the project. There’s things related to the code of the project and then there’s things related to the project itself. It’s up to you and your fellow organizers to make the call on what discussions belong where. Usually the line is pretty clear, but somethings a “let’s ask the community what they think” is the right way to go.

So, how does a (possibly) completely remote team keep up with one another? Well, here’s a few ways, some being better than others:

  • Email – one of the more cumbersome techniques due to it’s nature as more of a point to point method. This can work if there’s only 2-3 of you, but when it starts growing past that, this just gets confusing
  • Mailing List – this is a step above the emailing method and at least will give you a way to review the threads in case questions pop back up. Still not great, but better
  • Online project management apps – these can be great if you need something with a bit more superpower to help manage the project. Even something as easy as Basecamp can help.

The real key is to finding something that works well for your project, though. Sometimes it’s enough to just keep a running list of decisions/future plans made about the project, but I’ll warn you that you’ll outgrow this pretty quickly. It just doesn’t scale very well for anything other than a 2-3 person project.

Thankfully, keeping your project’s “staff” informed isn’t as difficult as keeping up with the general contributor base. It’s easier to just tell them where they need to go rather than trying to get the message out to as many people as possible and hoping it sticks.

Do you and your project have a tool or method that you use to keep all of the admins on the same page? Share it in the comments!

Comment » | Development, opensource, PHP

You’re Open Source…Now What? (Communication – Part 1)

June 22nd, 2011 — 8:55am

I’ve had an idea rolling around in the back of my mind for a little while now and the Call for Papers for ZendCon brought it up and into focus in the last few weeks. I am a part of the Joind.in project, a community event feedback site that’s also an open source project. My co-conspirator Lorna Mitchell and I have worked hard over the past year or so really trying to make the project the best it can be. There’s been a lot of learning that’s gone on during that time, so I wanted to share some of that in a series of blog posts.

This first post, as the title mentions is about communication. I’m going to break it up into two parts because there’s really two different sides to this one word when it comes to a project with so many moving pieces.

Communication with the Group

The first and more obvious form of communication people of think of when working with an open source project is talking to the community at large. Once you take that step an decide to open the source for your application, you’re no longer alone in its development. Sure, you might be the only one committing code to the project, but that doesn’t mean there’s not interested parties out there keeping an eye on your work. This is the first thing to consider as communication from your project to the outside world – the code you write. Even the best, most elegant code without some kind of commenting or internal documentation will fall flat. If there’s nothing helping an outside developer to understand your code and the design of it, chances are they’ll abandon it before they even get started.

Following this same line of thought, there’s the next most important (maybe more important?) form of communication for you to share with potential developers – project documentation. I know it’s been hounded to death by this point, but please don’t wait until the very end of your coding to write documentation. Yes, it’s a pain, but with so many tools out there (like the excellent DocBlox) to help you generate documentation, you have no excuse. Auto-generated docs are great, but real human-made files that include examples and descriptions are even better. Don’t forget to put a human side on your project – it draws in more contributors than just code comments alone.

The “human touch” brings me to the next topic under communication – personal interaction. Comments and documentation on the project are one thing, but if you really want to get people involved and get them as excited about the project as you are, you need to reach out to them on a personal level. There’s lots of ways to make this happen including:

  • mailing lists (we have ours split into “developers”, “features” and “site news”)
  • an IRC channel (#joind.in on Freenode, stop on by and say “hi”)
  • a blog
  • a Facebook page
  • a Twitter account

It’s an easy thing for a developer of a project to just want to stick with the code and get tunnel vision when it comes to the overall project. I’m going to go so far, though, as to say that if you don’t choose at least one of the things from the list above, your project will not succeed past the point of you and maybe a few other developers hacking on the code. At the recent php|tek conference in Chicago, there was a hackathon one night where several (I think it was around 8 or 9) folks all sat down and worked on Joind.in bugs. This was excellent except for the fact that I, one of the project leads, wasn’t able to be at the conference. This is where the IRC channel became invaluable – Lorna was there helping but there was only so much of her to go around. Me being able to have an official place for those people to come and ask questions was a huge boost in productivity over something like email.

Two things to remember, though – having these things is great, but don’t spread yourself too thin. You don’t have to have all of the things from the above list to make a successful project. Pick what fits your needs and the needs of your group. Remember, not everyone that’s interested may be a developer. Also, and this goes hand in hand with #1, don’t forget to nurture the communities you build. I’ve seen first-hand how things can drop off if the driving forces behind the project aren’t there to help drive these interactions. The past few months my time was increasingly eaten up by the conference I was planning and I just wasn’t able to spend the time with Joind.in that I wanted to. As a result, the mailing lists ran a bit dry and even the IRC channel was sparse. I’m on a mission to turn this around, though and am doing what I can to keep our current developers and bring in those shiny new faces eager to hack away.

Disclaimer: Okay, so I lied a little bit – turns out there’s more to say on this topic than I thought, so the second part of the “communication” idea will be in a “Part 2″ post coming soon. Until then, here’s a few suggestions for the project organizers out there about communication with your developers:

Suggestions

  • Be transparent – don’t hide decisions from your community. No one likes surprises, so do them a favor and let them give their input
  • Be consistent – you and the other project leaders need to present a united front on decisions. No “ask him, he’ll say yes” sort of thing
  • Be polite – yes, there’s going to be “those people” that seem to live to cause trouble, but deal with them politely. You never know who’s listening
  • Be a dev leader – this is an easy one for the project leads that are still developing, but for the others this could mean moderating pull requests or being familiar enough with the code structure to answer some high-level questions

In the next post I’ll talk more about the flip side of this – communication within the project between organizers and some of the difficulties that are hiding in there.

2 comments » | Development, opensource, PHP

“It’s Not Just About the News”

April 21st, 2011 — 9:34am

Originally, I was going to present these thoughts at the PHP Community Conference (in a session titled “It’s not Just About the News”) but it didn’t work out for me to be there. I still wanted to share some of my thoughts and experience in running PHPDeveloper.org for the last 11 years.

In its very first form, PHPDeveloper.org was just a page of links. It was hosted on a local server I had at the college I attended and was aliased to the outside world under the hostname “bender.ods.org”. I started gathering links on that page to some of my favorite PHP resources of the time – things like PHPBuilder.com and, of course, the PHP.net manual. I was new to the language – this was back in 1999-2000 range – and was constantly devouring everything I could about it. Not many of the free hosting services supported PHP back then so running it on my own server was clearly the answer. I compiled my own installations from scratch complete with some of the earlier versions of Apache, PHP3 (fresh off of PHP/FI) and MySQL. All of my code was procedural and I had no clue about application design. All I knew was that I loved the language. I left my Perl books to gather dust and marched on to a bright PHP-based future.

To be honest, I’m not entirely sure when I made the leap from a set of links to the sort of blog style PHPDev is in today. I was a huge fan of Slashdot back then (weren’t we all?) and I think I thought to myself one day, “I could totally do that”. So I hacked together a custom sort of content management system and started to work. Things weren’t as consistent then as they were now. Back then I might have posted once a week, two or three times if I was feeling ambitious. If you want a good laugh, go back and take a look at some of my earliest posts on the Internet Archive.

I was a big IRC user back then – still am on Freenode – and I spread the word about the site mostly through there. There was no such thing as Twitter and getting sites like Yahoo to notice you wasn’t as easy as it is now. I had one thing going for me though…back then there just wasn’t another PHP news site out there, at least not one that was consistently updated. I was determined that PHPDev would become one of the best resources out there for PHP-related news and community happenings that it could be.

Some folks have called me a human aggregator in the past, and I think that’s what really sets the site apart from some of the other PHP news/community sites out there. I’ve never, ever pulled in posts automatically from other sources. Yep, that’s right – I hand-write every post you read on the site. I spend about an hour or so each day trolling through my Google Reader feeds (I’m up to 434 of them currently) to find some of the most interesting content out there. I actually spend some time reading the posts and writing up a good summary of what it has to offer. Plus, I can do some fun things the other automatic readers can’t like:

  • Pulling announcements from Twitter
  • Listening to podcasts and summarizing their content
  • Filtering out posts that are related to a product or general commentary
  • Making community announcements about conferences
  • Taking specific article submissions

One of the best things, though, is subscribing to things like DZone or PHPCamp and discovering new articles that aren’t even on other aggregator’s radar. I gather things from the four corners of the web and try to make the best sense I can out them to share with the world. In recent years, I’ve realized that the “stuff I find interesting” approach is good, but I had to widen the scope to make it really work. I now read through my feeds and think more “is there a group that would find this interesting” instead. As a result there’s been posts on things outside of PHP touching on software like Drupal/WordPress/Joomla as well as Open Source projects that might be related to PHP, but not always directly.

I’m sure you’re curious about the technology behind the site. Well, let me say off the bat, you’re probably going to be disappointed. Remember when I said I had a hacked together CMSish kind of thing to manage the content – it’s not much different these days. I started with it back in PHP3 and it was all procedural. It wasn’t pretty but I was proud of it and it worked. Then PHP4 came along and these magical things called objects and OOP came along with it. Of course, I just had to do a rewrite. PHPDev v2 was born. Things changed again when Zend announced that they were making a framework (framework? what’s a framework?) and released some of their earliest versions. So, being the curious developer I was, I did what any good developer would do – another rewrite (PHPDev v3). If you’re wondering, I think it was ZF 0.7 or 0.8 – not sure which. Keep in mind that most of these rewrites came with a design update, but they all took the same basic news site/blog format. Finally, and this is the current form, I wanted to learn something different so I branched out to the Solar framework in yet another rewrite (yep, PHPDev v4).

So, what does all of that mean? It shows that the tools don’t matter. I could probably rewrite the site a million different ways, but that’s not what it’s about. Most of my current posting is just done on a simple form with subject, content and date/time. I write them in the morning and queue them to go out during the day. Sure, there’s been a few hiccups now and then when the technology changed, but what matters to most of my visitors is the content.

I checked in my logs a little while back just to see how many people were hitting the feeds on my site and found an interesting statistic – there’s now more people following the @phpdeveloper account on Twitter than there are pulling the feeds. Now, that’s not taking into consideration any re-blogging folks do of my content (that’s a whole other topic), but it’s still interesting to me.

So, how far have things come since the site’s birth back in 2000? Well, without trying to sound too boastful about it, I think PHPDev has become one of the most respected PHP news sites out there and provides a valuable service to the community that can only come from a human behind the helm. As of my latest post, the database now hosts 16232 articles that chronicle the history of the years the PHP community has been through, both the good and the bad.

Of course, I couldn’t end this post without thanking each and every one of you out there – my readers have made the site what it is. I couldn’t have done it without you. Your contributions – either through blog posts or actual submissions – are the lifeblood of the site. I’ve stood on the shoulders of everyone in the community to reach this high, and I thank you for letting me come along.

4 comments » | Community, PHP

Process Oriented vs Product Driven

April 10th, 2011 — 9:45am

Advice I like from 101 Things I Learned in Architecture School (Matthew Frederick):

Being Process Oriented, not Product Driven, is the most important and difficult skill for a designer to develop.

Being process oriented means:

  • seeking to understand a design problem before chasing after decisions
  • not force fitting solutions to old problems onto new problems
  • removing yourself from prideful investment in your projects and being slow to fall in love with your ideas
  • making design investigations and decisions holistically (that address several aspects of a design problem at once) rather than sequentially (that finalize one aspect of a solution before investigating the next);
  • making design decisions conditionally – that is, with the awareness that they may or may not work out as you continue toward a final solution;
  • knowing when to change and when to stick with previous decisions
  • accepting as normal the anxiety that comes from not knowing what to do;
  • working fluidly between concept-scale and detail-scale to see how each informs the other;
  • Always asking “What if…?” regardless of how satisfied you are with your solution.

Not a far stretch to make to software engineering. I especially love the “be slow to fall in love with your ideas” line. It’s easy to be seduced by how sexy something is and be blind to the fact that it sticks out like a sore thumb. Admit it, you’ve done it too. Above all, be flexible, consider more than just what you see right now and remember that software is constantly evolving – you should too.

Even if you have no intentions of learning anything more about architecture, 101 Things I Learned in Architecture School is a nice read with lots of good parallels, I highly suggest it.

2 comments » | Development, PHP

A Few Joind.in Thanks

April 7th, 2011 — 11:13am

If you’re a listener of the Voices of the ElePHPant podcast, you’ve probably already spotted the latest episode where Cal interviewed me about Joind.in and the experiences I’ve had with making to open source and the challenges associated with it. Unfortunately, the podcast was only a few minutes long and wasn’t a good forum for me to thank the folks that have helped to make the project into what it is today. As I mentioned in the recording, I knew to make the site all it could be, I needed to open it and share it with other minds greater than mine.

So, here’s a few thanks to some of the folks that have made an impact on the project:

  • Lorna Mitchell

    Honestly, without Lorna, a co-lead on the project, things wouldn’t be where they are today. She is one of the very first contributors to the project and was around back when the code was hosted on my own SVN server. She’s been the one that has waded through my early code and has helped point out the broken parts and encourage work on the features we agreed would be best to have. Her involvement with the project has grown considerably ever since php|tek last year and she’s become an invaluable part of the project.

    Because of her busy schedule, we’ve moved into different roles in the project that play more to our strengths. She, the always outgoing, willing to talk to anyone person she is, has taken up championing the project to anyone who will sit still long enough to listen. Some of the sessions she’s given have even included Joind.in as an integral part. In fact, she has a talk coming up at Dutch PHP Conference that’s about the new version of the Joind.in API she’s been hard at work on. Oh, and not to be forgotten, she also pushed the bug tracking for the project off of Github and onto Jira – a major upgrade to the bug tracking abilities of the project. The project is lucky to have her as a lead.

  • Kathryn Reeve

    Kathryn has been one of the few that’s voluntarily tackled the Javascript for the project. The changes she’s made won’t jump out at you when you visit the site, but they’ve
    helped to make the site more stable and more usable. She’s recently been working on date picker update for all of the date fields on the site and has made the tabs on the
    event page more accessible via the URL.

  • Joshua Thijssen

    Joshua’s a relatively new developer to the project, but he’s the kind open source projects love. He’s the kind of guy that dives head-first into code and doesn’t look back. I’m
    not completely sure, but I think that in the first week he was involved in the project, he closed about 10 bugs single-handedly. He’s active in both the IRC channel
    (#joind.in on irc.freenode.net) and in the bug tracker, both in providing suggestions and in closing out issues. Joshua is also the creator of the Android Joind.in application (which he gave a presentation on at the 4Developers conference).

  • Kevin Bowman

    Kevin’s been involved in the project for quite a while with contributions that range from server-side work, code updates, conversations on the mailing list and his most visible
    contribution, the iPhone application. This app, along with the Android one, are widely used at conferences for those times when it’s just easier to get out a phone than
    a laptop. He’s a great asset to have around for some of the more technical bits and I’m thankful for his continued efforts to help the project grow.

  • Mike van Riel

    Mike has been another one of those developers that’s extremely eager to help. Some of his latest work has helped bring the project more up to a unified coding standard.
    He and Michelangelo van Dam also laid the foundation for the unit testing functionality that the site currently uses (as well as some additional debugging handling). Before that
    he contributed loads of bug fixes.

I could go on and on with a list of folks that have helped out the project in one way or another, but here’s a few more of the thanks I want to send out…thank you to Jeremy Kindall, Derick Rethans, Stefan Koopmanschap, Ryan Mauger, Michelangelo van Dam and Rob Allen. I know there’s people I’ve missed on this list – there’s a whole host of you out there that have helped promote the site and make it what it is. I am so thankful that the PHP community is as open and sharing as it is. Without it, there’s no way a project like this would have gotten much beyond its infancy.

Thanks you to all of the PHP conferences that consistently use the site for their feedback – PHPUK, php|tek, ZendCon, PHPBelenux, ConFoo, Symfony events, PHP Community Conference, Day Camp 4 Developers, phpDay, PHP Unconference Europe, Dutch PHP Conference, PHP Northwest and the PHP Brazil Conference – and to all of the user groups and other events that contribute events and show their support daily.

I personally want to thank you all for being a part of our project, and I’m looking forward to where the future will take us. :)

1 comment » | Community, joind.in, PHP

Back to top