SunshinePHP 2016 Recap

The Good

SunshinePHP 2016 was an awesome event! Not only were we sold out of tickets for the 4th year in a row, but the attendee list was truly amazing! Each year more and more companies in South Florida send most if not all of their PHP developers to the conference. This year we saw at least 20 companies in South Florida send 5 or more of their developers, and around 8 of those sent around 10. We love seeing our work take hold, and with this many companies embracing the conference it is obvious we are doing a good job. Thanks to all for participating.

SunshinePHP CrowdsThis year we had 14 of our amazing 19 sponsors represented in the exhibitor area, handing out Lego pieces and speaking with developers about how they could help them enhance their careers in one way or another. We are happy that every sponsor raved about the event, attendees, the amount of contacts they made, and the overall organization of the conference.

SunshinePHP exhibitor areaAttendees told us they loved the Lego puzzle idea, and really enjoyed collecting the Legos from the sponsors.

We had some amazing talks and keynotes this year, and really pulled some topics that were outside the box we typically see at PHP conferences. Two talks were about the brain and mental functionality, and how rest and downtime can affect our thought processes and how we learn. There were talks about dealing with customers, and how to help them help us. The keynote speakers shared tips on collaboration and teamwork while sharing stories about Pacific Ocean crossing, and growing up with physical and/or mental disabilities.

Or course these off-the-wall, but very valuable, subjects joined our already mind blowing lineup of topics and speakers.

We also had a very gender diverse attendee and speaker lineup with 16 female speakers (or 36%) and around 20% female attendees! This is a step in a very positive direction, and SunshinePHP continues to lead the way through non-biased speaker selection and responsible marketing.

The menu each day was slightly altered from previous years, with some healthier choices. The quality of the food was another nice touch as the venue really stepped up to provide some tasty items.

Evening events went well with games and panel discussions about API building indoors, and an open bar with some food items outdoors on the pool patio. (Yes, it was nice and warm.)

SunshinePHP tasty food

Overall the event went amazingly well.

The Bad

We didn’t receive too many complaints in our feedback from the event. Some mentioned that the temperature in one room was a bit cold for awhile. Others mentioned that we could have added the technical levels of the talks on the printed schedule. (We had them on the site, but overlooked adding it to the printed materials.)

One complaint, which we loved, was that we made it very difficult to improve the event for next year. 😉

The Ugly

Yes, unfortunately there was some ugly. With the recent awareness of codes of conduct and with the increase in gender diversity there is bound to be more visibility as victims come forward rather than remaining hidden. (Because even though we didn’t hear about these incidences in the past, they were already happening.) We are relieved to report that each incident below was handled professionally, and to the satisfaction of the victims.

One report was about a male attendee offering 2 separate female attendees a private sampling of relaxation techniques in his room. And when the women refused the man did not continue or push. When the incidences was brought to the man as being inappropriate he apologized and said he meant well, and he would not do it again.

A second report was made about a man in the pool area, long after the conference had ended for the day, who approached the girlfriend of an attendee and flirtatiously claimed that she could do better than her current boyfriend. We recommended that the man retire to his room (to prevent an assault) and get some rest for the next day, which he did. Nothing further was said, and no additional actions were taken.

There was a third incident reported which took place before the conference actually started, but was reported after the conference ended. A male offered to take a female shopping some distance away from the venue. Allegedly, while they were shopping the man touched the woman in an inappropriate manner. Because of the lateness of the report there were no further actions.

In a fourth report, allegedly a woman was swimming with a group, long after the conference had ended for the day, and one of the men in the group touched her in an inappropriate manner. The following morning this was brought to our attention as a 3rd party story by someone who was not present. We spoke with the man, who remained in his room except for meals over the remainder of the conference.

And finally in a fifth incident, also reported by a woman but late into the following day, it was stated that a man in the pool area the night before was over-aggressively tugging on the straps of her swimsuit. The apologetic man was questioned and promised to refrain from such activities in the future. The woman said this was an acceptable outcome.

My desire, and the reason I am being open about these incidences is to help others. Other conferences need to be aware this happened, so they can also keep their attendees safe. And attendees need to know about these things so they can watch for it, report it early, and help keep each other safe. Because whether we admit it or not, these types of activities happen everywhere. If you organize an event or group, please do not fool yourself into thinking your event is immune.


While SunshinePHP was very organized, and was an awesome event, sometimes things can happen that are out of an organizer’s control. I feel the SunshinePHP staff did everything in their power to ensure the safety of our attendees. We are looking forward to next year.

The 2015 Slack vs IRC debate rages on

irc-v-slackIt seems that 2015 will likely be partially remembered as the year IRC zealots raged against those using Slack instead of the old reliable, and still growing daily, IRC chat. And it is turning out to be as lively as the “tabs versus spaces” debate that never seems to end.

Of course this means I am only left with one solution…it’s time for me to create a blog post to commemorate this seemingly HUGE issue, and make my thoughts known.

The answer is, I use both depending on circumstances.

For those who aren’t aware (shame on you), IRC (internet relay chat) allows the creation of “chatrooms” where folks can get together to share common interests. And thanks to many individuals and companies providing servers for the cause, it is free. Freenode has been around for more than 15 years.

IRC for all of it’s greatness is also fairly bland, and is pretty much just chat, and while many people use it there is still not much to make it “sticky”. For some this may be perfect because there is less “noise”, but for others there is not enough to warrant their attention.

Lately there is a new kid on the block called Slack.

Slack had a bumpy beginning as a failed startup. The app was likely doomed to be discontinued and never see the light of day as a private resource for companies, because nobody was using it. So as a last ditch effort the company decided to open it to the public, where it boomed to become a regular part of many projects by companies and open source projects and/or communities.

Not only does Slack perform the same activities as IRC, but it also includes the ability to integrate information from outside sources. For instance, via connectors you can pull in RSS feeds from pretty much anything that provides RSS, Tweets and Retweets by certain accounts, Facebook content, IRC content, Github comments and notices, news and announcements from virtually anywhere, and much more. In short, you can create a one stop portal with tons of information relevant to your “Team” which makes Slack a place where everyone can get together and share at a much higher degree than with traditional IRC.

So, what is the problem you may ask? The answer would be that Slack is not entirely free (though there is a free level), and if Slack were to change their pricing model or if they closed entirely all is lost. Communities, projects, and all these things created around this great platform disappears. There are no options to kick up your own server retaining the content, or any other alternative to carry on without the Slack company.

Those who are speaking up against using Slack for things like User Groups and OSS projects are voicing a valid concern because history and entire communities could be lost forever if Slack were used and evil things happen. This is a valid concern, and I was one of those people, until recently, which I will share in a moment.

However, on the other side of the issue is this: Though IRC is still growing and is not really being hurt by Slack, a vast majority of people simply don’t want to use it. Not because of anything malicious, but because a well set up Slack Team can become such a wonderful thing.

I organize the South Florida PHP User Group (SoFloPHP), and a long time ago I created the #soflophp chatroom on IRC Freenode. Then I promoted it heavily to the group of 800 members over and over and over again, and even posted it on the group website. Yet, at best we only had 2 or 3 people in the chat at any one time…BORING!

Recently a member, and now co-organizer, of the group asked if we could create a Slack team for the SoFloPHP user group. I was initially against it and voiced my concern as well as pointing out that there was already an IRC chatroom for the group. But the member was persistent, so I reluctantly agreed. And WOW!

Now to be fair, the Slack Team likely would have been a failure also because in Slack you need to invite every person into the team. There is not a way for folks to just join in, as with IRC. However, there is a handy app (Slackin) you can post on a server that allows people to enter their email address for an auto invite to the Team. We simply posted the app on a free Heroku instance and were off and running.

The problem of getting people into the Slack Team was handled, but how to make it better than IRC and ensure it was used? I then created a couple of Channels within the Team. One was for “Social” which I then created a couple of connectors to some relevant Twitter accounts. This kept fresh content, announcements, and relevant updates automatically flowing in to keep everyone informed and encourage discussion. Then I created a “Jobs” Channel to do the same, but with posts from our user group jobs board at And I also created a feed to the “Random” Channel from the Reddit /r/php hot board to infuse news and updates relevant to PHP. (Note: While Reddit can create an overload of posts, it does seem to promote chat around some of the posts in the General Channel.)

Now that we are using Slack as the user group communication portal (in addition to for the group management) we’ve noticed a much higher level of activity in the group. There are 50’ish members after only a couple of months, and the usage is growing instead of staying stagnant as the IRC did for a few years.

So the bottom line for me: Without paid services like our user group would not be what it is, and it seems that Slack has enabled us to become more active. I will continue using both, until they no longer work. Because the bottom line is that the group was created to serve the community, and Slack seems to do that for now.

Are Conference Talks Getting Too Soft?

For a few years I’ve participated in various conference CFP processes, and have been asked to speak via CFP submissions (I speak at about 10 conferences each year). Then after the conferences are over I’ve read attendee feedback about the content shared by speakers, including myself. This has caused me to take a second look at talks in general, and to take a closer look at my own talks.

To go into more details, I’ve read and heard feedback from attendees who voiced concern due to the high number of talks that border on being too “soft” for the topic area they cover. Ultimately they are asking, “Where’s what I paid for?” which may be a valid question.

Don’t get me wrong! I’m not saying that all talks should be highly technical, or that soft talks do not carry value. Instead what I’m concerned about is whether talks in certain topics are covered too soft or abstract, or perhaps are a bit shallow to allow more broad coverage, and do not carrying their weight on a conference schedule.

Case of Novices

We all boast that conferences are great places for beginners to learn quickly. I know when I was learning PHP I often felt like I was drinking from a fire-hose at a conference. But the content I heard at conferences taught some items I could use immediately, and the rest became fodder for learned over the rest of the following year. Which worked out well because as a non-speaker I could really only afford a single conference each year.

Fast forward to today. There are community level conferences in almost every region of the U.S. and around the globe. It has never been easier for a beginner to find and attend a conference containing the same speakers and talks that previously were ONLY at the large conferences. Yet, it appears that talks themselves are carrying less and less “meat”. Beginners may leave the conference with some content and ideas, but then need to search for more details to actually learn. But should they? Or should there be a fair mix of practical content to use immediately mixed with ideas to research for the future? I personally lean toward the latter.

It is hard to teach a great amount in a 1 hour talk, but if there is not some immediately usable content an attendee will have a tough time proving to their short sighted boss that it was worth their time.

Case of Veterans

In the community I often hear the mantra “Everybody should go to at least one conference a year”. With the recent explosion of regional conferences there are now many veterans venturing out of the office in search of…more. These well paid high level devs need to justify their time at a conference more than a novice level developers because it’s more expensive for their company to give up a few days of productivity and salary from them.

These developers are able to drink from two fire-hoses, and have a thirst for everything that can be thrown at them. They are ready to see code samples, and even live coding by the experts in the field. However, too often a talk does not live up to the expectations built by the talk abstract which eluded to more. The abstract said they would learn how to do something, but the talk may actually bounce around concepts and possibilities. The veteran walks away vindicated in their current knowledge, but gains nothing new.

The Hallway Track

If I hear another person say the hallway track is the best value of a conference I’m going to PUKE!

Again, let me clarify. I’m a firm believer in a strong hallway track. To have exploration time between talks, during meals, at hack events, and at the end of the day, is priceless. But the best part of a conference should be the talks. Those talks should promote discussions in the hallway track where attendees, speakers, and others continue the conversations and perhaps learn more fine points.

How Does This Happen?

I think there are various reasons why the talks have become softer than traditionally. However, I will only name a few that jump out, and leave the rest to the readers own realization.

First, there is laziness. It’s easier to verbally talk about something rather than create code samples and examples. It takes a great deal of time and effort to generate code that only serves the purpose of demonstration. However, it is much easier to present a bunch of bullet points and remain abstract.

Second, there may be a lack of preparation. I think that many speakers do not spend nearly enough time preparing new talks, or rehearsing them. Therefore it is somewhat thrown together and lacks the refinement of in-depth content and examples. If the talk is not prepared ahead of the CFP, which is fine in some cases, I have seen speakers wait far to long after they are selected to actually create the talk.

Third, the speaker may lack true passion on the topic but was able to get it accepted by a conference. Unfortunately knowledge does not always equal passion. Therefore the attendees suffer, because the talk lacks conviction and quality of someone who truly cares.

Fourth, a talk doesn’t live up to it’s potential the first time it’s given. It gets better with repetition. The talk is not bad the first time it’s given, but it is not 100% either. As a user group organizer I am saddened that so many do not consider speaking at a user group to make sure a talk is vetted before giving them at a conference where attendees are paying for “higher quality”.

The Challenge

Based on the above lines of thinking I’m going to be doing the following moving forward, and encourage others to take on this challenge:

  • Tweak my own existing talks to ensure they carry value. Add code examples where they should have been to begin with, include more resources to enforce my words, and even include more live coding and demos to provide deeper understanding.
  • Be tougher when rating talks I attend at conferences. I should walk out of a talk feeling like I truly learned something.
  • Be more critical when selecting talks to be presented at conferences. I owe it to the attendees, and to the conference organizers to ensure the best talks are chosen.
  • Ask to see slides and code for talks in advance if available, and at a minimum set a deadline of when these should be ready if the talk is selected. To ensure the talk lives up to the abstract.
  • I will not submit talks to conferences I have not prepared in advance and given at least once to a user group. See the blog post by Cal Evans titled “Airfare and Two Nights in the Hotel” where he writes about this very thing.

Final Thoughts

I am friends with many developers (or used to be :P) who speak at conferences pretty often. I know many of them take great pride in their talks and the preparation of them, and not all of the points discussed in this post applies to everyone. However, I would encourage you, the reader, to consider your own talks and see if you can apply some of these things. I believe that we can all improve in some way, and I personally strive to improve each day.

Simple reminder to keep it simple

This morning a tweet caught my attention prompting me to read this post by Gary Hockin also known as @GeeH. (There’s just something about that voice.[inside joke])  In the post he talks of his experiences while attempting to simplify code in a project, and in the process uncovers hidden dependencies that increased the codebase significantly in order to gain the benefit of a mere 100 lines of code.  He also highlights that in today’s mainstream PHP development, where many are using Composer to blindly include packages into applications, we may not fully understand code being pulled in with the consequence of accepting responsibility to maintain those additional packages as well.

I’ll wait a second while that sinks in…

Yes, that’s right.  If you include additional packages and libraries into your application you’re accepting the responsibility to maintain them.  No, I’m not saying you are responsible for contributing to the software package…unless you care to.  What I’m saying is you are now in charge of updating the software within your application, which now includes additional packages created by others.  As security holes get fixed, or new versions come out fixing bugs, it is up to you to ensure you update these packages in your applications which include them.

You’ve been living in a dream world Neo

Ha, didn’t think about that, did you?  If you did, Bravo, you’re behaving like a professional.  For the rest, welcome to reality.  Now go update the applications you’ve neglected.  But first a side note.

I’m not saying Composer is bad.  Actually I think the opposite.  Composer is awesome, and you should be using it if you’re not already.  As in the post by Gary above I’m simply saying it’s our professional duty to know what we’re asking Composer to do on our behalf.  Use it responsibly and do a bit of research so you’re not blindly including potential issues, bugs, security holes, and nightmares to maintain in the future.  Then if you’re satisfied with what you see, go ahead and “require” away.

But wait!  Don’t just look at the packages you’re including into your codebase.  Also take a look at their dependencies as well, because you are also accepting them in the process.  Know what you’re saying “yes” to.

Past knowledge

None of what I’m saying is new stuff.  A while back, in the beginning of 2012 (I thought it was earlier for some reason), Ed Finkler @funkatron wrote the original MicroPHP Manifesto to voice his concern over many frameworks starting to grow in size. (NOTE: Later there was a separate domain dedicated to housing the MicroPHP Manifesto, but I like the original better because the blog post associated with it helps highlight why it’s a concern.)  I encourage you to check it out and consider the meaning, and how it relates to your projects.

Again, nobody is saying large full frameworks are evil or other libraries should not be used.  The idea behind all of this is to caution, so you go in with your eyes open and “know” what you’re including in the codebase.  Know the responsibilities accepted by including other libraries.

Happy coding!