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.

Drupal will NOT load any javascript (including jQuery and drupal.js) if it “thinks” that they are not required. It will only load the scripts if any other module or script requires them. For example, if you add scripts in your .info file or using the drupal_add_js() function in the hook_init(), Drupal will detect it and load its scripts.

Now, let's assume that you developed a module that adds its own scripts in hook_footer() using the drupal_add_js() function. At the time when hook_footer is executed, it is too late for Drupal to add scripts to the header and hence jQuery and drupal.js will not be added. If your javascript depends on them you will see error messages in your console such as:

Drupal is not defined
jQuery is not defined
The solution is to include at least one script earlier – for example in hook_init() so that Drupal loads its scripts.

Meteor is a set of new technologies for building top-quality web apps in a fraction of the time, whether you're an expert developer or just getting started.

Pure JavaScript.
Write your entire app in pure JavaScript. All the same APIs are available on the client and the server — including database APIs! — so the same code can easily run in either environment.

JSHint is a tool to detect errors and potential problems in JavaScript code.

Over the last few months, I’ve seen a password strength meter on almost every signup form I’ve encountered. Password strength meters are on fire.



Here’s a question: does a meter actually help people secure their accounts? It’s less important than other areas of web security, a short sample of which include:

Preventing online cracking with throttling or CAPTCHAs.
Preventing offline cracking by selecting a suitably slow hash function with user-unique salts.
Securing said password hashes.
With that disclaimer — yes. I’m convinced these meters have the potential to help. According to Mark Burnett’s 2006 book, Perfect Passwords: Selection, Protection, Authentication, which counted frequencies from a few million passwords over a variety of leaks, one in nine people had a password in this top 500 list. These passwords include some real stumpers: password1, compaq, 7777777, merlin, rosebud. Burnett ran a more recent study last year, looking at 6 million passwords, and found an insane 99.8% occur in the top 10,000 list, with 91% in the top 1,000. The methodology and bias is an important qualifier — for example, since these passwords mostly come from cracked hashes, the list is biased towards crackable passwords to begin with.

These are only the really easy-to-guess passwords. For the rest, I’d wager a large percentage are still predictable enough to be susceptible to a modest online attack. So I do think these meters could help, by encouraging stronger password decisions through direct feedback. But right now, with a few closed-source exceptions, I believe they mostly hurt. Here’s why.

Drush Rebuild
I wrote a simple utility, Drush Rebuild, to help me manage the process of rebuilding a local development environment. Drush Rebuild doesn’t make assumptions about your repository structure (Drush Make, entire codebase in repo, etc), nor does it care about extra steps you need to take when configuring a development environment, like disabling caching, adjusting connections with 3rd party services, and so on.
Instead, the utility provides a framework for executing rebuild scripts for a given site, using the power of Drush aliases and the drush php-script command.

Let's take a hike on the coast from San Francisco to Los Angeles to visit our friends in Newport Beach. I'll whip out my map and draw our route down the coast:


The line is about 400 miles long, we can walk 4 miles per hour for 10 hours per day, so we'll be there in 10 days. We call our friends and book dinner for next Sunday night, when we roll in triumphantly at 6pm. They can't wait!

We get up early the next day giddy with the excitement of fresh adventure. We strap on our backpacks, whip out our map, and plan day one. We take a look at the map. Uh oh:

Speaking of Radar, we encountered a fairly nasty problem after launching xScope. Many of our customers are designers and developers who love SSDs. It’s common to use a symlink in your Home folder to put big datasets like Pictures, Music and Movies on a separate hard drive. When you do this, folder access in the application sandbox container breaks. A small number of users who use symlinks are also getting crashes after launching the app that was downloaded from the Mac App Store:

xpchelper reply message validation: sandbox creation failed: 1002
Container object initialization failed: The file couldn’t be opened.

I started my startup journey about 4 years back, right around the time Amazon introduced AWS. We started with a VPS and eventually moved to dedicated servers for Muziboo, completely skipping the cloud wave. We are doing the same for SupportBee. We do use S3 but we never used EC2 for hosting. However, I have worked as a consultant a couple of times in the last few years and I have worked with EC2 on client projects. I understand the benefits of cloud hosting but I don’t think that cloud is the right solution for every company. Traditional dedicated server hosting still makes a lot sense for majority of companies out there. However, before I get to that, let’s first quickly go over the benefits of cloud hosting

This is a list of best practices for creating websites that do not break when browsers are updated. It's not always possible to follow all of these, but following as many of them as possible will help future-proof your website. This is especially important for intranet applications and other non-public websites where problems are likely to not be noticed during testing by browser vendors.

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.”

Critical, drop-everything bugs become daily affairs, and the sense of confidence in the engineering strength of the structure begins to erode. This leads to low morale, burnout, and less internal cooperation for fear of taking on too many bugs.

Of course I enjoyed my time on Wave like no other time in my career. It was equal parts frustration, joy, defeat and passion. I don't regret a single moment of being associated with it. It remains a wonderful attempt at creating something unique, exciting and incomparably bold. Nor do I want to ascribe blame to anyone on the team or Google at large. I just want to point that even the smartest, most motivated and talented people in the world--with a track record of delivering success--are alone not sufficient to overcome complexity that creeps up on you. Maybe we should have known better, but we didn't.

In the end, the man-month as a scalable unit of work is hubris worthy of a Greek tragedy.

"In science, if you know what you are doing, you should not be doing it. In engineering, if you do not know what you are doing, you should not be doing it. Of course, you seldom, if ever, see either pure state."

—Richard Hamming, The Art of Doing Science and Engineering
How can we design systems when we don't know what we're doing?

The most exciting engineering challenges lie on the boundary of theory and the unknown. Not so unknown that they're hopeless, but not enough theory to predict the results of our decisions. Systems at this boundary often rely on emergent behavior — high-level effects that arise indirectly from low-level interactions.

When designing at this boundary, the challenge lies not in constructing the system, but in understanding it. In the absence of theory, we must develop an intuition to guide our decisions. The design process is thus one of exploration and discovery.

How do we explore? If you move to a new city, you might learn the territory by walking around. Or you might peruse a map. But far more effective than either is both together — a street-level experience with higher-level guidance.

Likewise, the most powerful way to gain insight into a system is by moving between levels of abstraction. Many designers do this instinctively. But it's easy to get stuck on the ground, experiencing concrete systems with no higher-level view. It's also easy to get stuck in the clouds, working entirely with abstract equations or aggregate statistics.

This interactive essay presents the ladder of abstraction, a technique for thinking explicitly about these levels, so a designer can move among them consciously and confidently.

I believe that an essential skill of the modern system designer will be using the interactive medium to move fluidly around the ladder of abstraction.

This is interesting, because the mechanism of growing a comb-over applies to software development. A comb-over is the accumulation of years of deciding that today is not the day to change things. A comb-over is the result of years of procrastination, years of decisions that seem right when you're in a hurry to get ready for work but in retrospect one of those days should have included a trip to the barber and a bold decision to accept your baldness or take some other action as you saw fit.
Software is like this. Bad software doesn't really start with bad developers. It starts with good, decent people who make decisions that seem right on the day but in aggregate, considered over longer timeframes, are indefensible. This is a great paradox.

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

ou work hard at your job, and you don't always get to go home right when the clock strikes five, either. So why should you take time out of your day to sympathize with game developers? After all, they're adults. If they don't like their situation they can move on, right?

Well, the problem is that it's just not a very effective way to manage a project, and often it's the quality of the games that suffer. This is not a new revelation; as far back as 1909 studies have shown that the 40-hour work week actually provides more output over a long period of time than when employees work longer hours.

PHP Cloud Hosting Platform As A Service

Drupal 7 and Drupal 8 recently added a default (and sensible) .gitignore file to the standard repository, and while this solves some problems, it has also caused some confusion. (issue)

Here's a link to the actual new .gitignore. Essentially, it excludes the sites/default/files and sites/default/settings.php files from git source control.

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.

As a result of all the noise about UTF-8, got an email from Marek Gayer with some very smart tips on handling UTF-8. What follows is a discussion illustrating what happens when you get obsessed with performance and optimizations (be warned – may be boring, depending on your perspective).

Outrunning mbstring case functions with native PHP implementations
The native PHP strtolower / strtoupper functions don’t understand UTF-8 – they can only handle characters in the ASCII range plus (may) examine your servers locale setting for further character information. The latter behaviour actually makes them “dangerous” to use on a UTF-8 string, because there’s a chance that strtolower could mistake bytes in a UTF-8 multi-byte sequences as being something it should convert to lowercase, breaking the encoding. That shouldn’t be a problem if you’re writing code for a server you control but it is if you’re writing software for other people to use.

HTML5 is the new kid on the block, sure, and with reports that an official specification wont be fully completed and officially supported until 2022, you may be wondering why you should use it in your new site.

Well, there's one main reason (for me at least), and that is: The Future. The simple fact is that HTML4/XHTML1.0/CSS2 are outdated, and the new XHTML 2 standard has been scrapped in favor of HTML5. CSS3 is gaining more and more momentum every single day, the future of the web is HTML5.

In this article, I’ll describe some techniques to assist you in the debugging process when you are using jQuery in client-side Web development. Thankfully, we have much better tools and technologies than developers had even five years ago.

Reply-all gaffes, top-posting etiquette, plaintext versus HTML, attachment limits, inbox limits… everybody hits them. By comparison the simplicity and clarity of Facebook mail is impressive. A Facebook message requires (privacy controls pending) a symmetrically-acknowledged relationship between parties, and on top of that spam-murdering convenience it’s self-threading, low friction, and lightweight.

In a nutshell, Facebook is better than email unless you’re some kind of email expert. And for email’s successor to support all the expert features of email, none of its myriad problems would be solved.

It’s been a recurring theme this week, but the Pro users of yesteryear’s products, the people with the biggest investment in old technologies, are not the people who should be calling the shots in the design of their successors. These are the people who complain that an iPad can’t have third party software installed from anywhere but the App Store, ignoring the massive convenience and security gains the policy affords average users. These are the people who are still using slotted screwdrivers and Edison light fixtures and manual transmission cars.

Ensuring that your iPhone or iPad app is accessible (in this case, to visually impaired users) is the right thing to do, and thankfully it’s very easy – in many cases, there’s no work to do at all. This article for iOS developers describes how to implement accessibility support.

Microsoft spenderar enorma summor på forskning och utveckling men vad ger det egentligen?