Talking at PHPNE

On Tuesday, the 16th of April, I gave a talk at PHP North East, titled "Silex: From nothing, to an API". This was my first real talk, so it was really nerve wracking for me. Initially, I planned not to be the guy who wrote his presentation the night before, but due to certain things, that turned out to be what happened.

This lack of planning and rehearsal time really came to be a real problem for me, as during my actual talk I rushed through my slides, and missed out some key points. The Friday following my talk, I was also involved in a workshop on how to give better presentations, which, I wish had of been the Friday before my talk, but never mind.

After the course, and listening to myself during the talk, I've realised a number of issues with it. The following are things that I either learned, or did incorrectly during my talk.

You can see the slides for the talk on slideshare and the source code on GitHub. Also, if you have any feedback on the talk, please let me know via Twitter (@chrisdkemper) or in the comments.

1. Don't make assumptions

This was my first real problem, as it lead to a few issues during the talk. My first assumption, was that I thought everybody in the room would know about Composer, which after the talk, I learned wasn't the case. I don't believe in explaining every part of a presentation, because this can be very boring to the majority of spectators, and makes for a dull presentation. I could have however, put a slide in explaining what Composer was and its benefits. Within this slide I could have also mentioned Composers ability to autoload a users own libraries, which I used within the presentation, but never explained.

To make life easier for myself during the testing part of the part, I'd written some tests using the Symfony Console Component but I then didn't fully explain this. I should have made a better point of mentioning that it wasn't part of Silex, and was a separate library. I also could have actually explained the benefits of this a lot more, as the library itself is awesome, and you should check it out.

2. Slow the fuck down

After the course, and listening to myself during the presentation, I know now that I was talking through my slides WAY too fast. This is a vicious cycle, because as you talk faster, you go through more slides, and then realise you don't have many slides left, which makes you more nervous, so you talk faster, etc, etc. With being nervous I missed out explaining some of the key parts of the talk. First of all, I should actually explained how Silex works with its routes. The first example I used, is the one mentioned in the documentation on the Silex website is quite simple to someone who knows Silex, but not for someone who is unfamiliar with it. Below is that code sample:

$app->get('/hello/{name}', function($name) use($app) { 
    return 'Hello '.$app->escape($name); 
});

Ideally, I should have mentioned that each route is added to the main application object, and that variables used in the url are passed through as arguments. You can also use the Request and Response objects as arguments too, if you require them within the route. Also, to make use of application helper functions and services, the application variable needs to passed into the route via use, otherwise it'll be unavailable within the route.

I also rushed through the usage of components within the application. I didn't elaborate very much on the use of DBAL within the talk. Although it was only a base usage, I could have still went into a little more detail about how it worked, but I blame my nerves.

3. Plan Plan Plan

My lack of preparation time kicked me in the face here. For one, I mentioned some things that weren't technically correct. These were mainly down to the use of Silex in larger applications. Silex as a framework is perfectly capable of handling larger applications, but the issue with it comes with managing the routes, as this can get quite messy unless it's managed properly. You can get around this a little by using Controller providers, which can make routes a lot more manageable for larger applications.

I also totally neglected to mention how easy it is to run tests within Silex, you can check that our here.

Summary

There were a few other improvements I could have made, but on the whole I'm still glad I gave the presentation. Although there were a lot of problems, I learned a lot from the experience, and, I know at least one person got something out of, which makes it all worth it! Hopefully I'll be able to do another talk in the future, and make a better job of this one.

A new site, eventually.

Since my previous site, a placeholder page I built on the Megabus home from the .net awards in 2010 I've been saying I'll build a new one, and now, I finally have! Due to this being nearly 2 years coming, I've decided to just finally get something out there actually allows me to blog, and show any potential side projects I have going on (wait and see for that one). I was initially going to build the site in Drupal, then in Wordpress, then in PyroCMS. Although all of these systems would have been perfectly adiquete, I then suddenly realised, I know how to code, I don't need a CMS.

With that in mind, I then decided to go down the framework route, in the form of Silex. If you're looking to whack a quick prototype together, or a nice little site like this one, I'd definently give it a try. To go with this, I also made use of the TWIG capabilities of Silex, and decided to serve my content in the form TWIG templates for the main layout, and Markdown files for the actual content. Although this seems like a backwards way to work, the lack of a database means the site is shockinly fast, which is always a good thing. The disadvantage of this however, is when it comes to routing, as it all has to be done manually, but that comes down to an array with a filename and a slug, so once you have a couple in there it's easy enough to work with.

On the design side of things, you may have already worked out I've went with the Twitter bootstrap as a base. This allowed me to get the site up and running really quickly, and just skin it for my needs. I decided to get it from Github, so I could have access to the LESS files, allowing me to compress all the styles into one file, which helps with the super speedyness.

To cover the comments, I've decided to go with Disqus. I've always liked using this, mainly because of the ease, and that it takes care of the moderation and annoying aspects of dealing with comments, ala spam. That pretty much sums up the site, the rest of the aspects I just added in little bits at a time, and I'll no doubt change the design when I kick off a side project or two, but theres time for that yet.

If you have any thoughts on the setup or would like to offer some suggestions, I'd love to read about them in the comments.

Foundation Version Control for Web Developers.

Since my new site is finally up, it means I should finally write a post regarding the book written by myself, and Ian Oxley. Although it's been out for a number of months now, I still sometimes miss the whole writing experience, although it's one of the toughest things I've done to date. The start of the book went rather smoothly, but then I started falling behind, and the timescales started getting tighter, and tighter. I can safely say that some of these timescale issues were down to my poor management, because I always just thought "It can't be THAT hard.", well I can safely say, it is.

That's not to say the project wasn't rewarding, seeing your name in an ACTUAL BOOK is one of the best feelings ever, plus I was able to be the first member of family to have that honor, which is a great feeling. The main issues I had generally came down to planning, because in most cases I well and truly underestimated the amount of time, and effort that goes into writing, and the research, my god the research! Working in the web, I'm used to the whole, you-get-a-bug-then-fix-it thing, but of course with a printed book, that luxury isn't there. Although the publisher does help with some of these issues (by putting your chapters through various copy and technical reviews), you really have to make sure everything (humanly possible) is correct in there, by checking, and double checking everything.

With the book, especially in the CVS chapter, I kept having to get information from sites that were created back with dial up was king, and having to confirm the facts from these sites, using others that looked the same wasn't so easy. For the newer systems (Git, SVN and Mercurial), this process was a still a pain in the arse, because with Version Control, there are a lot of ways to perform certain actions, but some are a lot better than others. This meant doing A LOT of testing. I had a spare Macbook (Courtesy of Phil Sherry) and various Virtual Machine's to ensure I could test everything multiple times (and under multiple environments), to ensure it worked as intended.

This process, combined with the researched needed = lots of work. All of this effort went into all the practical chapters of the book that I wrote, so you can imagine how much I shat my pants when I realised the scale this went to, especially working with Mac, Windows and Ubuntu. Although there was a lot of work involved, I still like to think I'd have been a lot more comfortable if I'd planned more extensively at the start, and managed my time better.

With that in mind, being able to take breaks is a really hard thing to do while writing, at least it was for me anyway. Towards the end of the process, if I didn't work every possible moment, I wouldn't have finished, simple. When you're working 5 days a week and writing 7, it can really take it out of you, and I'm sure many of you freelancers out there will always have this issue. I had to allocate myself at least a half day off to recharge, otherwise the 7am to 2-3am days would end up devouring me and I'd be a zombie.

I've already mentioned the research that went into the book, which took up a lot of the time, and I'm sad to say that some of the research can have a somewhat negative effect on you while you're doing it. While writing the book, I learned and understood every command needed by someone getting started with Version Control, but as soon as I'd learned a command, it's place was filled by another, and the previous one was forgotten. Now I'm having to use my own book as a reference for some commands, which isn't really a bad thing, it proves it works.

All in all, I'd love to work on another book, the glory you get out of it hugely outweighs the work that goes into it. This time though, I'd be sure as hell to plan the fuck out of everything, and if anything, have more than enough material to write about, and know the time will allow for the schedule. Plus, I'd rather write about something I'd need to research less, so I can spend more time being creative with the content I knew, not making sure said content was actually correct.

If you haven't checked out the book yet (you should, it's awesome AND has a snake on the cover) then you can head over to Amazon and check it out there.

I love Kickstarter

Since finding out about Kickstater back in March, I've been in love with the idea of micro funding and what it's able to achieve. The first project I backed was Eqo Optics and after that I got the fever. Thus far, I've backed 9 projects although In some cases my lack of funds made me miss some great opportunities such as Elevation Dock or OUYA.

One of my favourite projects is Carmageddon which is the next instalment in the series. Due to some crazy licensing issues, Stainless games were unable to make a new version of the game, but now, they can! After being successfully funded, the project is now well underway, and the game is making great progress. I'm really looking forward to seeing one of my favourite games given an awesome facelift.

While using the site, I've never been in the position where one of the projects I've backed hasn't delivered. Don't get me wrong, I'm still waiting for a number of things, but those particular projects are either games (Castle Story, Planetary Annihilation or even Timber and Stone), or products such as Nifty Drive which are being well updated. They all have active development blogs, so you know what's happening on regular basis!

With Kickstarter now being available in the UK, it gives a huge amount of opportunity for cooler projects to back, and most likely, spend all of my money on.