I'm working on an update to my PHP Web Services book and with PHP 7 likely to release before the book even makes it into print, I'm testing all my example code across PHP 5.6 and PHP 7 ... which today gave me a weird problem with a very, very simple SOAP example. Continue reading
I create my slide decks from ReStructuredText, which is a text markup format. Working this way makes it easy to add into source control, fast to work with, and also accessible since I don't use a mouse or other pointing device so traditional slide deck creation programs are kind of difficult. Text-based wins every time for me. While working on a new slide template, I ran into some difficulties and had to figure out how to inspect what was going on. I seem to struggle with this every time so I am writing my troubleshooting guide here for when I need it next. Continue reading
This post is an adaptation from an email I sent to a friend who is doing their first few conference talks. I was asked to share more widely so here it is
The microphone is your friend, honestly :) Even if you think you can be heard, there are some definite benefits to using a mic if it's available:
- you actually can be heard
- even people with less-than-excellent hearing can hear you
- the video recording can hear you as well
- you now have the option to employ some vocal variety: exclaiming, pausing, stage whisper ... it all adds interest and colour to what you are saying
There are a few different types of mic and each one has its own quirks! Continue reading
PHP 7 is coming, which is nice, but what does it mean for the majority of PHP developers? PHP as a community is notoriously slow in adoption, some of us are still waiting for 2012's new shiny to be available as standard on our hosting platforms. However with the performance benefits and a few really nice new features, PHP 7 is well worth everyone's attention, and it's actually quite easy to get started so here's my quick howto. Continue reading
If you're a web developer looking to improve your git skills, then I have just the thing for you. I love it when a project is finished and "out there" and I'm pleased to announce that my new screencast course Git Fundamentals For Web Developers is now available. It's mostly PHP but you'll find Python and Node examples in there as well just to show off some of the tricks that work best for different disciplines. The course is structured around specific tasks or problems that we face in creating and deploying web applications, and my best advice on how to solve them. Mostly, I just want you to be able to be awesome at what you do already without your source control tool getting in the way :)
Edit: If you're reading this before July 25th 2015, use code CFSCON5 to get a massive 50% off!
I've been a conference speaker for a lot of years now, which doesn't make me an expert but it does mean that people ask me for advice pretty regularly! With the Call for Papers open for PHP North West at the moment (awesome conference, first weekend in October, CfP at http://conference.phpnw.org.uk/phpnw15/call-papers/), I've taken this question a few times. Here's my advice in a nutshell:
- Think about what's interesting that you could share with other developers. The key here is that the people listening should go away with something useful, rather than just the impression that you're awesome
- Write it down. You don't need to write the talk before you submit - just a title and an abstract will do. The abstract should be one paragraph, maximum 200-250 words
- A great abstract says why this topic is vital, what cool things will be covered, who should come and what they will learn. I'm paraphrasing but those are the basics!
- Submit your abstract to http://helpmeabstract.com/ to get feedback from some lovely volunteers who will help you (bookmark the gist and keep revisiting it, the system doesn't notify you or anything ... yet. Pretty sure you can submit patches while procrastinating on a slide deck though)
- Did you get this far without submitting? That's normal :) Remember that your community needs new voices. Each of us is ahead of *someone* on the path, you absolutely don't need to be the expert to have something to offer to the rest of us. So please, submit :)
If you know anything at all about PHP7, you probably know it's fast. But did you know how fast? The alpha is out and looks very robust, so I decided I would create a new set of benchmarks to include it. Graphs first, disclaimers later :)
This graph shows the time it takes for each version of PHP to perform the same task, on average, with oldest PHP on the left and moving forward in time.
PHP 5.4 isn't exactly new; in fact the opposite is true! PHP 5.4 is end of life, but as our adoption rates show, as a community, PHP people aren't especially good at upgrading! I'm getting lots of questions now because some of the hosting providers, notably including Acquia's hosting, are finally upgrading away from those 5.2 and 5.3 offerings.
One thing in particular is tripping people up: the short open tag. I've had a few questions on this so here's the advice I am giving to clients and friends.
What Actually Changed
short_open_tag configuration directive was removed, but the short echo syntax
<?= is always available.
How To Upgrade Your Codebase
- If you have
<?=in your templates, leave it alone, those will still work
- If you have short tags
<?in your code, including in any of your libraries, then you need to do a global find-and-replace and turn them all into
If you have short tags somewhere in your codebase, you probably won't get errors, you'll just suddenly start seeing PHP code in your output as PHP doesn't recognise the tag and therefore doesn't evaluate the code! To find them, try searching for
<? followed by a whitespace character.
Hopefully that helps; there are a few gotchas to getting upgraded from older versions (especially from PHP 5.2) but this particular gotcha really isn't a problem and the instructions here should see you through.
I'm a fan of Jenkins as a build server, and on one particular project we've also started using New Relic (I haven't figured out how to blog fun things about New Relic without sharing graphs of client applications which doesn't seem like a cool thing to do). New Relic has a feature where you can notify it when you do a deployment, and it shows on the graphs a line marking when that happened, which is super useful for correlating performance changes with code changes.
I do a lot of code reviewing, both in my day job as principal developer and also as an open source maintainer. Sometimes it seems like I read more code than I write! Is that a problem? I'm tempted to say that it isn't. To be a good writer, you must be well-read; I believe that to be a good developer, you need to be code-omnivorous and read as much of other people's code as possible. Code reviews are like little chapters of someone else's code to dip into.
Over time I've developed some particular processes that I find helpful when reviewing code. In particular, I often surprise people at how much review I do before I run the code. Sometimes I grab the branch so that I can use my local diff tools, but I don't actually execute code until I've established some basic facts. This post is a little insight into what's happening in this not-running-the-code-yet zone. Continue reading