Sheffield PHP, 8th October
A repeat performance of the talk given at PHPNW in July, possibly with even more wittier jokes!
Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently.
They’re not fond of rules. And they have no respect for the status quo.
You can quote them, Disagree with them, Glorify or vilify them.
About the only thing you can’t do Is ignore them.
Because they change things. They push the human race forward.
And while some may see them as the crazy ones, We see genius.
Because the people who are crazy enough to think they can change the world, Are the ones who do.
A fair number of passwords from the Ashley Maddison hack have now been cracked. Click through if you want to see the (NSFW) top 100 list, but you wont see many surprises.
As bad as it is that 11.7 million accounts were protected by weak passwords, there’s yet another number the underscores just how careless the Ashley Madison masses were: Only 4.6 million of the 11.7 million recovered passwords were unique.
If I did my maths correct, around 5% of all accounts (or 1 in 20) had passwords in that top 100 list.
It wasn’t so long ago that when you had a problem with any of your Apple products, you could drop by your local Apple Store and a friendly fellow geek would sort you how: in the case of hardware, usually by confirming the issue and giving you a replacement there and then.
But Apple products are getting more popular, and the Stores are getting busier. Gone are the days where you could just pop in: you’ve needed to book an appointment for some time now. And gone are the days where you knew you were talking to a fellow Apple geek who could get you on your feet there and then. Now, it’s a pleasant surprise if you get this.
Those who listen to ATP will know, possibly to their own frustration, about the issue where part of the front-facing camera is shifting to give an appearance of a grey crescent moon. (And for those who hadn’t: I’m sorry, you can no longer un-see it). And earlier today, Casey sent a tweet reminder:
iPhone 6 users with the crescent moon: if you got yours launch day like me, your warranty runs out ~18 September. http://t.co/txx5zRqug6
So far, so good. There’s a clear defect with your phone and you have just over a week to get a fix or replacement under regular warranty.
But then I delved into the replies to this tweet. And the results were mixed, to say the least:
@caseyliss Casey thanks to you pointing it out on ATP I booked genius appointment. Genius replaced mine with a brand new iPhone 6.
@caseyliss took mine in a couple of weeks ago with this issue. fix took about 10 minutes.
@caseyliss I was told as long as it wasn’t interfering with the function of the camera to live with it.
@caseyliss I was told that this was a “normal variance” and couldn’t get it fixed until it affected the photos taken by the FaceTime camera.
It would appear Apple Genius support is being inconsistant with this issue, with some owners being told it isn’t a problem.
Is it time Apple re-thought their after-sales support strategy?
As you’ll see in the video below, if you insert the [Samsung Galaxy Note 5] stylus wrong way in (and that appears to be pretty easy to do, as Leo demonstrates), the stylus gets stuck, held in place by a mechanism inside the phone.
The embedded video demonstrating the issue is amazing, and worth watching for Laporte’s reaction when he realises what he’d done.
A quick run-through of things you can check during your code review, but which you probably aren’t.
One of a number of lightning talks, part of a lightning talks evening, at PHPNW on 4th August.
Money Saving Expert:
As playing videos on a phone or tablet via a mobile network requires the internet, it eats into your data allowance at a rate of knots, and once the allowance is breached, it becomes mega-expensive. Networks charge up to 20p/MB in the UK if outside your inclusive allowance, and up to £8/MB abroad to use internet data.
An interesting reminder about how the little things that we don’t think twice about can be a huge deal for real world users.
I’ve been thinking a little bit about the usual, and understandable, reaction from the average developer when they learn that there’s a problem with their code.
That it’s a bad thing.
Here’s the thing: developing is hard. There’s so many moving parts that I would be concerned if there wasn’t a problem in the software, somewhere.
Two mantras that I’m fond of, of which I’m unsure of the genesis, spring to mind:
Nothing in the world is perfect. If something is completely without fault, it could be said that its fault is that too much time and energy was spent in creating it
If the code base to a piece of software is without fault, that’s because it does nothing interesting
The magic isn’t in getting it right the first time, or even the second or the third time: it’s in working as a team to make the best you can, given the constraints.
Proxy settings in OS X are weird. If you use SVN, Intellij wants to be different.
You need to set the proxy settings for each project if you’re behind a project. Do this by going to
Settings -> Version Control -> Subversion and make your changes. If you have the proxy settings set up in IntelliJ
you may want to just use those – or you can set up your own individual settings in there.
So there we have it.
You see, I don’t like the term “code review”. I prefer “peer review”: because you’re not just looking at the code.
One thing I like to look at, and which I increasingly find an important part of a commit is the commit message itself.
You may be writing to your future self, to a colleague in another office (or even country), or trying to explain to a project lead why you did what you did. And the commit message is the best way to achieve this.
I can’t pretend to be the best writer on the planet: I’ve done my fair share of “bug fixes” messages, but here’s a few things I’ve picked up:
- Ticket number goes first: it doesn’t matter how you do it (although a standard is always good), but if there’s a bug tracker ticket number associated with the commit, it should be the first thing you write. It helps automated systems, and makes it easy to pair an issue with a commit.
- One issue per commit: I’ve been burnt enough times doing this. Nobody enjoys picking out code that isn’t ready yet!
- Use the text editor: it may be possible to use a flag such as -m to include an in-line message, but it’s worth avoiding using it. Your message will be better for it.
- Include a one-line summary as the first line. Go into more detail after a carriage return. This makes it easy to scan logs, and improves automated systems. Make sure this summary makes sense without the rest of the message!
- Why did you do this? Yes, I can see you’ve modified the CSS stylesheet. Would you like to tell mewhy?
- Include discussions: future readers may not be privy to a conversation you had with a colleague. Write down what was discussed, with who, if you’re doing something out of the ordinary.
- Write a novel if you have to, but keep it succinct. Provide too much information rather than not enough. I’d rather have to skip a paragraph than have to interrupt you in order to ask why you did what you did.