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.
iPhone 6 sales dropped from 56% down to 53% and iPhone 6 Plus sales jumped from 22% to 29%. The survey is based on 500 Apple customers. Large enough to be a trend indicator, small enough to have a significant margin of error.
I am surprised there’s a jump in iPhone sales in the March–June quarter, but I’m not surprised that the 6 Plus is the one that increased.
I was one of those who laughed at the larger size and wondered who would buy such a thing. But turns out, I got it wrong. From what I understand, the Plus is better.
I still prefer the iPhone 5 generation size, but when it comes between the iPhone 6 and 6 Plus, the larger one is easier to use. The middle ground of the iPhone 6 compromises too much, and it still doesn’t feel comfortable to hold (also, it’s too easy to drop).
If given the choice again, hands down I’d pick the Plus.
Zeynep Tufekci, on why we should worry about the state of software:
From our infrastructure to our privacy, our software suffers from “software sucks” syndrome which doesn’t sound as important as a Big Mean Attack of Cyberterrorists. But it is probably worse in the danger it poses.
I agree. Duct tape fixing duct tape, and taking short cuts because it has to make money (and never fixed because of ill thought out cost-benefit analysises) is a big problem that will only get worse before it gets better if we aren’t careful.
As a profession, we’re lucky that we have relativity lax regulation. And we are a massively growing profession which is moving at an incredible pace.
Yes, we did things badly in hindsight, I bet most engineers look at work they did only six months ago and cringe.
But we can’t let quality be a second class citizen, and we have to keep things maintained: just as we do with buildings, roads, and cars.
It shouldn’t be “more glamorous” to be working on a brand new greenfield project. Me, I love working my skills on keeping things ticking, pushing systems to its limits then putting the bits back together again.
Let’s hope I’m not a dying breed.
On 7th July at PHPNW.
Testing can be boring, but there’s also some interesting ways you can check your application. I’ll be going through some interesting tools and techniques, showing them in action, and who knows — maybe we’ll break something while we do so.
Michael E. Gerber, on Steve Jobs:
What did he know that the rest of us did not? My answer was simply that Jobs didn’t actually know more than the rest of us; he simply cared more.