GIT SHOULDN'T BE SO HARD TO LEARN.

When you're just getting started, something as straightforward as a merge can be terrifying. It can take a long time to really become comfortable using some of Git's more advanced features. (It took me a year or two.)

Once people achieve some level of Git enlightenment, they tend to make statements of the form 'Git gets a lot easier once you realize X' -- but that doesn't do much for people staring up Git's steep learning curve.

My goal with this site is to help you, Dear Reader, understand what those smug bastards are talking about.

The mobile landscape today is all but monopolized by WebKit, as a result, most of the tooling and infrastructure to support mobile web development on the frontend is taking place in the WebKit Inspector, so I’ll focus on it, and take a deep dive into its entire feature-set and how and when to use it.

Google and the Chrome team have been pumping a ton of resources into the WebKit Inspector. The changes have enabled a whole new class of complex and ambitious applications that would have otherwise collapsed on their own weight. This is great news, of course, but as I talk to more and more web developers about their process and tooling, it became clear to me that many of them haven’t caught up with the changes or aren’t making effective use of the tooling available. This blog post attempts to remedy that, not only by walking you through the inspector’s feature set, but also highlighting certain techniques for bug hunting and feature development that I’ve found to be indispensable.

I read a rather interesting post yesterday called PHP: a fractal of bad design. It's been getting a lot of traffic among the PHP community lately because it's rather inflammatory. But to be honest, it does make a lot of really good points. It also makes a lot of mistakes and misses a bigger picture.

I’m cranky. I complain about a lot of things. There’s a lot in the world of technology I don’t like, and that’s really to be expected—programming is a hilariously young discipline, and none of us have the slightest clue what we’re doing. Combine with Sturgeon’s Law, and I have a lifetime’s worth of stuff to gripe about.

This is not the same. PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. Go on, ask! It makes for interesting conversation.

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can’t even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. (Hence, fractal.)

PHP is an embarrassment, a blight upon my craft. It’s so broken, but so lauded by every empowered amateur who’s yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

But I’ve got to get this out of my system. So here goes, one last try.

As an active member of "The Internet" and vocal Objective-C coder, I get a lot of questions surrounding the language. They're often framed around thinking about learning the language or trying to write an app, but they also usually involve a phrase like "Objective-C looks really hard" or "what are all those minus signs about?" Both of these are pretty good questions, and I'd like to address why someone might be more hesitant to jump into iOS or OS X development compared to, say, Ruby or Java.

How to Hire a Programmer
There's no magic bullet for hiring programmers. But I can share advice on a few techniques that I've seen work, that I've written about here and personally tried out over the years.

1. First, pass a few simple "Hello World" online tests.
I know it sounds crazy, but some people who call themselves programmers can barely program. To this day, I still get regular pings from people who tell me they had candidates fail the most basic programming test imaginable.

That's why extremely simple programming tests are step one of any sane interview process. These tests should happen online, and the goal is not to prove that the candidate is some kind of coding genius, but that they know what the heck programming is. Yes, it's sad and kind of depressing that this is even necessary, but if you don't perform this sanity check, trust me – you'll be sorry.

Some services that do online code screening (I am sure there are more, but these are the ones I know about) are Interview Zen and codility.

Thanks for the reply, s removes spaces but it doesn't seem to strip non-breaking spaces (I actually use another function to trim excess space using this command).

I'm not sure if there is a way to do this or a reason it's failing with   but I have a workaround now if anyone else needs this. Using the unicode equivalent of   works, ie str.replace(/u00a0/g,'');

I’m 32 (and a half) years old, at time of writing in early February 2012, so Morin and I work in the same field and are of approximately the same age. The difference is, I not only immediately thought of hashing as an appropriate measure, but was shocked that Path hadn’t implemented their app and servers that way. Nonetheless, this isn’t an isolated example.

From talking to many developers about this privacy intrusion during the past week, it quickly became disturbingly clear to me that many aren’t familiar with hashing at all. This is also predictably (and entirely forgivably) true for the many journalists who have covered the story, unintentionally distorting the issue due to lack of education in the field.

This article, therefore, aims to introduce the concept of hashing in a clear, straightforward, and no-degree-required way, suitable for journalists and casual readers as well as programmers and software engineers. I’ll also explain why it’s suitable for preserving the privacy of contact information whilst still allowing for social functionality, and I’ll touch on whether or not you really need to store that contact information (hashed or not) in the first place.

WAT
A lightning talk by Gary Bernhardt from CodeMash 2012

Sometimes people say to me, "Hey, Wil, you've been programming since dinosaurs roamed the earth... do you have any advice for young whippersnappers like us?"

And I always respond, "Hey, you kids, GET THE HECK OUT OF MY YARD!"

No, no, I usually demur with, "Oh, gosh, I don't know," as I look down shyly and shuffle my feet.

But, I've thought about it a lot recently, after writing so much solo code for Delicious Library (for the first time in many years), and then taking on a new programmer and trying to impart my style on him. And what I've come up with is a style I call:

* The Way of the Code Samurai *

Now, I don't actually know much about real samurai, but the basic thing I've heard is they stand and stare at each other for hours, and then suddenly BAM strike once and the other guy is down.

That's how you should code.

It’s been over a decade since Joel Spolsky wrote the Joel Test: 12 Steps to Better Code. The man was ahead of his time. Sure, things like version control are a no-brainer for any competent shop out there. With the ease of tools out there, most teams have a bug database and have reasonably up-to-date schedules. Heck, most software companies out there do pretty well on Joel’s 12 steps. But those 12 steps are no longer enough.

I’ve become somewhat of a process nut, which is weird. Usually I’ve got my finger over the big red deploy button before anyone else. But that’s not process, that’s deploying. I like to hear how other companies work. I see the most trivial roadblocks frustrate some developers. Many companies, both big and small, pay too little attention to process. It hurts morale, it contributes to unnecessary work and it will eventually lead to a product falling apart.

This is my attempt to codify what I think are 12 great supplemental steps to Joel’s first 12. Like Joel’s, you should give a binary answer to each question: “yes” or “no.”

Good is the enemy of Great
Latin-1 is the enemy of UTF-8
You write web apps. You understand the web is global, and want to support internationalization. You want UTF-8.
UTF-8 is extremely sane. Well, as sane as an encoding can be that features backwards-compatibility with ASCII.
Everything you care about supports UTF-8. Trust me: you want it everywhere.
Problem is, every last part of the web-application stack will fight you on your quest towards UTF-8 purity. What follows is a playbook to win your pervasive-UTF-8 battle.

Programming for Mere Mortals is a series of books designed to introduce the concepts of programming from the ground up to a reader who has never written a line of code.

Unlike most programming books which aim to teach you a particular language or operating system, this series focuses on the core fundamentals that are common to programming any computer.

The first volume, How to Count (approx. 70 pages), introduces you in a laid-back, conversational tone to math concepts that are essential to becoming a successful programmer.

Rubular is a Ruby-based regular expression editor. It's a handy way to test regular expressions as you write them.

To start, enter a regular expression and a test string.

Version Control
Everything you need to get started with Subversion or Git.

In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

This is a tutorial on the Git version control system.

Git is quickly becoming one of the most popular version control systems in use. There are plenty of tutorials on Git already. How is this one different?

A Story

When I first started using Git, I read plenty of tutorials, as well as the user manual. Though I picked up the basic usage patterns and commands, I never felt like I grasped what was going on “under the hood,” so to speak. Frequently this resulted in cryptic error messages, caused by my random guessing at the right command to use at a given time. These difficulties worsened as I began to need more advanced (and less well documented) features.

After a few months, I started to understand those under-the-hood concepts. Once I did, suddenly everything made sense. I could understand the manual pages and perform all sorts of source control tasks. Everything that seemed so cryptic and obscure now was perfectly clear.

Understanding Git

The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.

A huge part of my job these days seems to be impedence-matching between big opaque chunks of library software that sort of do most of what my program is meant to achieve, but don’t quite work right together so I have to, I don’t know, translate USMARC records into Dublin Core or something.  Is that programming?  Really?  Yes, it takes taste and discernment and experience to do well; but it doesn’t require brilliance and it doesn’t excite.  It’s not what we dreamed of as fourteen-year-olds and trained for as eighteen-year-olds.  It doesn’t get the juices flowing.  It’s not making.

It’s common practice for any software project with multiple coders to use some version control mechanism. CVS or Subversion used to be popular. These days distributed systems like git and Mercurial are the quickly replacing the old standards. But what about the cases when you’re the only coder?

Let me tell you. Whatever the initial setup cost, coding is much easier with version control than without it.

Intressant intervju med Jonathan 'The Wolf' Rentzsch, en vass macprogrammerare.