Since then, Apple has managed to add at least one marquee feature every year, sometimes many more, while still developing a desktop OS and building new Macs, iPhones and then iPads each year. The schedule is exhausting to even think about.

Unlike the iPhone, iOS hasn’t settled into a ‘tick-tock’ cycle either. We’ve seen back-to-back changes in iOS that have required major re-thinking of the OS. The phrase ‘pedal to the metal’ comes to mind. Apple is clearly determined to move iOS forward feature-wise on a very aggressive schedule. Even while showing considerable restraint in changing much about the basic structure of the home screen.

iPhone OS 2.0 got apps, iPhone OS 3.0 was probably the weakest of the bunch, but added many fan favorite features like copy and paste and MMS. iOS 4.0 brought multitasking support, Apple-style. Last year, iOS 5 flipped the table with the replacement of Apple’s long-running Mac-as-digital-hub with its iCloud service.

iOS 5 was a turning point for Apple in a few ways, coming as it did during the year of company founder Steve Jobs’ death and the matriculation of Tim Cook to Apple’s new guiding force. It also moved them further away from traditional computers at a time when they were pushing the iPad as the harbinger of a ‘Post-PC’ world. The future of Apple is now entangled completely in their efforts in the cloud, an area which hasn’t been kind to them in the past.

That was a big gamble. Betting the future of the company on a traditionally weak area was ballsy, but inevitable. Apple could read the cards just as well as the rest of us. Connected devices that existed apart from the traditional PC would become our primary computers, period.

In a few years, smartphones will be our primary computers, if they aren’t already.

Apple’s strategies are centered around that fact, that our personal computing will be pocketable first, tablet second and desktop third. To borrow Jobs’ analogy, there will always be room for truck-like PCs, but far more people drive compact cars, period.

That’s why it’s so interesting that Apple chose to go for broke in iOS 6 by removing Google Maps and choosing to build its own solution from the ‘ground up’. Their motivations are discussed later on in this article, but the simple ones are clear: maps is one of the most used items on any smartphone outside of the browser, and Apple wants that data to be its own, not a competitors.

The critical nature of mapping on any smartphone also means that Apple is taking its second big gamble in two years by betting that it can do at least a passable job of replacing Google, a company that has at least 5,000 dedicated employees working on Maps.

Apple has about 60,400 employees worldwide, but most of those are in Retail Stores. In the US, Apple has roughly 43,000 employees and 30,000 of those are in retail. If we use those same calculations for the worldwide market (I actually think 70% is conservative outside the US) then we end up with around 18,000 employees in the business of engineering, designing, marketing and managing Apple’s software and hardware products efforts.

In contrast, Google has some 54,000 employees, and no retail stores. The calculations based on basic man-hours do not stack up in Apple’s favor. Google has put forth an immense amount of effort to get Google Maps where it is now, and it would be surprising to see Apple come in and do as good a job without those resources. But stranger things have happened.

Outside of the new maps, there is plenty to like in iOS 6, it’s clearly a company firing on all cylinders.

Unless we’re talking about the App Store. The current incarnation of the store is probably the worst one in a while. It poses serious discoverability challenges for developers and a frustrating web-based UI that is worse than years past. Work is needed badly here, and Apple just purchased a company that does exactly that, so we hoped more of that work would be showing in iOS 6. Alas, not yet.

Siri continues its transformation here from an ‘assistant’ to a search analog. It delivers more information directly without the need to consult Google and Apple will likely expand its capabilities with more partnerships over the coming years. It clearly believes that this is how it will inject itself in between its users and Google.

iOS 6 is the first major iOS update that will be downloadable over-the-air. iOS 5 supports delta updates, patching only the changed parts of the OS for smaller downloads, but upgrading from iOS 4.x to 5.0 had to be done with a cable and a computer. Users of iOS 5 will be able to make the jump without ever having to touch a computer. Plug it in to charge, hit the update button and give it 30 minutes and you’re up and running.

It’s going to push the adoption rates of iOS 6 into the stratosphere. Apple has already had very good luck with upgrades due to a small overall device footprint, with iOS 5.0 hitting 75% in a few weeks and iOS 5.1 nearing 61% adoption in just 15 days. With iOS 6 being the first completely native OTA experience, these rates are going to be blown away.

Overall, iOS 6 is very good, with some nice touches throughout that ease pain points and refine the experience. And Passbook has the potential to be wonderfully useful. But the question marks of Maps and the App Store are big ones, integral to the ability to recommend iOS as the best platform for a smartphone purchase down the line. These are challenges that Apple will hopefully meet, but we’ll see.

Which brings us to installing iOS 6.

by MATTHEW PANZARINO @ TNW

The code is pretty much self explanatory:

/*
 * queryParameters -> handles the query string parameters
 * queryString -> the query string without the fist '?' character
 * re -> the regular expression
 * m -> holds the string matching the regular expression
 */
var queryParameters = {}, queryString = location.search.substring(1),
    re = /([^&=]+)=([^&]*)/g, m;

// Creates a map with the query string parameters
while (m = re.exec(queryString)) {
    queryParameters[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
}

// Add new parameters or update existing ones
queryParameters['newParameter'] = 'new parameter';
queryParameters['existingParameter'] = 'new value';

/*
 * Replace the query portion of the URL.
 * Query.param() -> create a serialized representation of an array or
 *     object, suitable for use in a URL query string or Ajax request.
 */
location.search = $.param(queryParameters);

You can clearly improve the regular expression, but the one above meet my needs.

Source: Changing URL parameters with jQuery from Samuel Santos blog.

A Starting Explanation

If you’re reading this, it’s likely that you’re at least somewhat acquainted with Terminal (or on Windows, something like Cygwin). If so, then you will understand this quick functional explanation of SSH.

SSH is essentially using a network connection to get into Terminal on another computer.

If you aren’t familiar with Terminal, there are a lot of explanations and beginner’s guides to Terminal, both here on Nettuts+ and elsewhere. The power of SSH is reliant on its simplicity; by offering you access to the Terminal of another machine, SSH cuts to the chase and gives you full control over a remote machine. If you understand the power of Terminal and its direct connection to the inner workings of your local machine, then you understand the power of SSH!

A Brief History

SSH was developed in its infant state in 1995. The primary developer, Tatu Ylonen, developed it as the first secure way to administrate a remote UNIX system. Previous to SSH, the only tools that existed sent information like passwords in clear text.

So, How Do I Use It?

There are a million guides out there on how to get set up with SSH. We will specifically cover one method today. First things first, you’ll want to make sure you have SSH on your system.

• Mac – A version of OpenSSH comes preinstalled.
• Windows – Follow a guide like this one or this one to get Cygwin and the “openssh” package installed.
• Linux – OpenSSH is highly likely to be installed already, but if it isn’t, you can follow the same guide to get it installed.

To determine if SSH is installed, run `which ssh`. If Terminal returns something along the lines of /usr/bin/ssh, then you’re good to go! Otherwise, follow one of these guides to get it installed.

In this article, I will assume the version you are using is OpenSSH; there are some configuration differences that depend on your version of SSH. We will be explaining how to set up a Mac to connect to a MediaTemple server through a single SSH command. Once you have SSH installed on your machine, you will need to make sure your target host has SSH enabled. SSH runs over port 22 by default; you can use a command line tool like nmap to ping your server to determine if port 22 is accepting incoming connections, like this:

sudo nmap -sS hostname.com

Of course, you probably have access to the administrative interface for the server. Make sure you look through the options and enable SSH. On a Mediatemple server, this configuration is located under the Server Control panel. Mediatemple SSH is accessible by using root@primarydomain.com. You can add users to the account, but for the sake of keeping things simple, we will use root@primarydomain.com.

Once SSH is enabled (and you have set a root password in your server admin), you can run the following line to SSH into your server.

ssh root@primarydomain.com

…where primarydomain.com is your MediaTemple primary domain. You will then be prompted for your password (which is the root password you set in the control panel). If you are not using MediaTemple, you can SSH directly to the IP address of your server as well.

If using shared hosting, it is likely that you will not be logging in as root. Instead, you will log in with a user account name. For example, if you are using a service like Site5, you may log in with a username at a subdomain, like this:

ssh username@malta.site5.com

Ultimately, these configurations will depend on your specific web server company. Refer to your host’s documentation for more information.

Once you are “shelled in”, you can execute commands and traverse the file system within Terminal. Depending upon on your level of access, you may be able to install things on your server using apt-get or wget commands. You can manage your Apache server, edit configuration files with a Terminal-based text editor, view error logs, clear caches, view files directly on a server to make sure they are the correct version, and plenty of other lower-level system administration tasks. Now, what if you wanted to do more, faster with SSH?

How Do I Use It… Better?

There are a ton powerful things that SSH opens you up to. We will skip a few of them (as quite a few are more sysadmin-related, like tunneling). But we will go over a few useful tricks.

Super-quick Log-in

You’re thinking to yourself, “seems like there should be a faster way to do this.” You’re right. And there is. Instead of having to remember your domain, password, and username for every server, you can set up a few configurations that will allow you to speed up the process to something along these lines.

ssh myserver

With the right configuration, you could run this, and without having to enter any passwords, IP addresses, or long domain names, you’re in! Again, we will assume you are logging into a MediaTemple server. First, we will generate ssh keys. This is basically a set of encrypted keys that live in ~/.ssh on your local machine. You have a “public” key and a “private” key. So, first things first, open a new Terminal window and create the .ssh folder in your home directory.

mkdir ~/.ssh

Next you will generate your keys with the following line. (This comes directly from MediaTemple’s documentation.)

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa -C "Comment about your key goes here."

This line will generate an ssh key of type rsa, with 2048 bits (for security), at the file location specified, with the comment specified. You will be promprted for a password, but it isn’t mandatory or necessary; not providing a password will enable you to automatically log in. The RSA type is for SSH protocol version 1. Type DSA is for protocol version 2. Check with your web server to find out which version they are using. Once your keys are generated, you will then run this to make sure your SSH configurations are set to the right permissions.

chmod 700 ~/.ssh && chmod 600 ~/.ssh/*

Next, you will upload your public key to your server. There are quite a few ways to do this; this way comes from MediaTemple’s docs as well.

cat ~/.ssh/id_rsa.pub | ssh root@example.com 'cat - >> ~/.ssh/authorized_keys'

This code is echoing your id_rsa.pub through a `|` (pipe) into the next command, which is an SSH into root@example.com, where you will run an echo and concatenation of what you piped in the first command. It sounds a bit complicated, so there are a few alternative ways to handle this. Essentially, you are going to want no line breaks and your public key on its own line in a file, called authorized_keys on your server in the ~/.ssh/ directory. So, if this is the first or only key you want on your server, you could run this command to copy it directly to that location.

scp ~/.ssh/id_rsa.pub root@example.com:.ssh/authorized_keys

This line is essentially saying, “copy this first file through SSH to the server at this location relative to my current home directory.”

Once your authorized_keys contains your public key, you can attempt to login to the server with ssh username@example.com. If you put your public key in the root user directory’s SSH configuration files, you will be able to login directly to root. You will be asked about a rsa fingerprint; go ahead and allow this action. It adds the server you are connecting to to a known_hosts file. This file can be used for a lot of different things, but particularly to secure yourself against what is called a “man-in-the-middle” attack. If you’d like to read a little more about this, check out this explanation.

If you can successfully log into your server, as if you had entered a password, your keys are working properly. The next step is to add a couple of lines for a shortcut to a configuration file on your machine . Open ~/.ssh/config in your favorite text editor (create it if it doesn’t exist) and add the following:

Host shortname
HostName somehost.com
User username

Where “shortname” is a nickname for the server you want to log into. For instance, “Host myserver” would allow me to do ssh myserver. The HostName is your server location, and of course the User is your username. You may have User root at this spot. Once this file is saved, you should be able to run a simple command to log into your server, like this:

ssh shortname

Git Without a Hub

Please Note: this section requires a bit of familiarity with Git.

You can use SSH to set up your own Git repos on your server! This is useful for companies who don’t want to expose their code on GitHub for whatever reason, and it’s great to be able to push directly from a local machine to a Git repo on your own server.

To set this up, make sure Git is installed on both the host and your local machine. You may have to go through your web server company to have Git installed. Next, run git init on your server in the location that you want your Git repo to be. Of course, you can do this a hundred different ways, but if you prefer to not have a bare repository, you can use branches to push to from your local machine. Here is a common workflow.

ssh user@example.com
cd /path/to/repo
git init
git checkout -b staging
git checkout master
# disconnect from shell session using ctrl-d
cd /local/repo
git init
git add .
git commit -am "some message"
git remote add origin user@example.com:/path/to/repo
git checkout -b staging
git push origin staging
ssh user@example.com
cd /path/to/repo
git merge staging

Essentially what is happening here is you are logging into the server, changing to the desired repo path, creating a repository and adding a “staging” branch which you can push to from your local machine. Then, you are creating your local repo and a corresponding “staging” branch on your local machine, and adding files to track to the repo. Next comes an initial commit. You are then adding the remote repository as an alias of “origin”. Next, you are pushing the local staging branch to the “origin” alias’s staging branch. Finally, you are ssh’ing back into the server and merging the “staging” branch with the default “master” branch.

SFTP > FTP

You can also use SSH-powered FTP (file transfer protocol), which is essentially a more secure (encrypted) version of FTP that runs over port 22 (rather than the default FTP port 21). Most FTP clients support SFTP as well. FileZilla (for Windows) and Fetch (for Mac) are two popular (and free) SFTP/FTP clients.

Easy Access to Your Server Almost Anywhere

As long as you are around a computer that is connected to the internet, has a Terminal, and has SSH installed (any Mac connected to WiFi, for instance), you can get access to your server, via SSH. That’s the best part. You don’t require any configuration (assuming you haven’t set up any restrictions that require a matching pubkey), you can log in with your username and password from practically anywhere. There are even SSH clients for iOS and other mobile devices. This is a very powerful feature of SSH that is only paralleled in portability by browser-based applications.

A Local Code Repo

Hopefully you can see the power of SSH in a daily development cycle.

Let’s imagine that you and a few buddies are working on some code together. Let’s also say you have a local computer that you have full control over that you use as a development LAMP server with a few VM’s installed on it. You can use SSH locally to move files to and from your computer and the development machine. You can even set up a local Git (or svn, or Mercurial) repo, powered by SSH to keep everything in check. Perhaps you could even make the development machine the only machine that is connected to the remote server via SSH, so that the code has to go through a specific staging process before it can be put into production. The backbone of all of these actions is SSH!

Hopefully you can see the power of SSH in a daily development cycle, especially for teams using version control. As I noted previously, there is plenty of documentation and a myriad of other network-level tools based on or reliant upon SSH that will give you more control and power over your development process and your server. Who knows? Maybe, one day, you could double as a sysadmin after all!

Who the Hell Do You Think You Are?

Every time I open a project that isn’t mine, it’s accompanied by a tinge of fear that I’m walking into some kind of Temple of Doom scenario, filled with trap doors, secret codes, and that one line of code that, upon alteration, brings down the entire app (and possibly sends a giant boulder hurtling toward me down a narrow hallway).

When we’re wrong, and everything is fine apart from some minor differences in “how I would have done it,” we breathe a sigh of relief, roll up our sleeves, and dive into the project.

But when we’re right… Well, that’s a whole different story.

Our first thought upon seeing this unholy mess is usually along the lines of, “Who the hell does this guy think he is?” And rightfully so; what kind of programmer would willingly create such an unholy mess out of a project?

The Answer Might Surprise You

Your first instinct might be to assume that the guy who built the project is a novice, or maybe he’s just an idiot. But that’s not always the case.

My theory is that awful code is the accumulation of multiple small shortcuts or concessions — just as often as it’s the product of inexperience or stupidity. This makes the Temple of Doom app much scarier, because whoever built it might be just as smart, savvy, and well-read as you are. They just got lazy or put things together in a rush, and each of those little shortcuts added up into the winding nightmare that just fell in your lap.

Even scarier, this could mean that at some point, someone inherited your code and immediately burst into tears.

Awful code is the accumulation of multiple small shortcuts or concessions.

You’re Better Than That, Baby!

It never hurts to reexamine your current practices and make sure you’re not taking any shortcuts that could be contributing to someone else’s lost sleep.

Let’s take a few minutes and go over some common shortcuts, concessions, and other bad practices to ensure that our projects aren’t striking fear into the hearts of the villagers.

You Don’t Plan Before You Start Coding

Before you write a single line of code, you should have a solid plan of attack. This helps keep you on track and avoids wandering code that will confuse you later, not to mention some other poor soul.

One approach that has saved me time — both in development and in commenting — is to write an outline in comments first:

Before you write a single line of code, you should have a solid plan of attack.

<?php

// Include necessary data

// Initialize the database connection

// Include the common header markup

// Determine the page variables from the POST data

// Load the proper database info using the page vairiables

// Loop through the loaded rows

// Format the images for display

// Create a permalink

// Format the entry for display

// Add the formatted entry to the entry array

// Collapse the entry array into page-ready markup

// Output the entries

// Include the common footer markup

As you can see, without writing a single line of code, I already know almost exactly what the file will look like. Best of all, you can plan out an entire application this way, and if you get to a point where one feature requires a functionality tweak to another, all you have to do is change the comment.

It requires a shift in the way you approach development, but it will make your project organization skills go through the roof.

NOTE: Some of these comments aren’t necessary; some of them will change; others will need to be added — that’s expected. This is kind of like writing an outline for a paper or writing a grocery list: it just keeps you on the right track when you go to finish the job.

You Don’t Comment Anything

Yet the single worst problem with most code that I encounter is that it’s poorly commented, or not commented at all.

It makes me sad that I have to write this down. When something is as easy as commenting, it shouldn’t be something we have to remind each other to do.

Yet the single worst problem with most code that I encounter is that it’s poorly commented, or not commented at all. This not only adds a good chunk of time to my initial familiarization with the project, but it pretty much guarantees that a fix made using an unconventional method out of necessity will confuse me. Then, if I end up doing any refactoring, I’ll inadvertently break the app because I haven’t encountered the extenuating circumstances that required the fix.

This process can take anywhere from 10 minutes to 6 hours. (And you’ve done this to me, I know where you live. I’m coming for you.)

So say this out loud:

I, [state your name], hereby swear to make comments in any situation where the purpose of the code I’ve written isn’t immediately apparent.

“Immediately apparent” refers to code that can’t be self-documenting (because it wouldn’t be reasonable to do so) and/or doesn’t complete a dead-simple task. Think about it this way: if you had to stop and think about your solution for more than a few seconds, it probably merits a quick line of explanation.

Consider the following:

$pieces = explode('.', $image_name);
$extension = array_pop($pieces);

What does that do? Did you have to stop and think about it? Do you still not know for sure what’s stored in$extension?

Look at that snippet again, but with one quick comment:

// Get the extension off the image filename
 $pieces = explode('.', $image_name);
 $extension = array_pop($pieces);

Now glancing at this code doesn’t require any additional brain power: you see the comment, see the code, and never have to question its intent.

It might only save you five seconds of contemplation, but if you’ve got a complex app, five seconds at a time will add up in a big way.

So stop making excuses. Write the damn comment.

Five seconds at a time will add up in a big way.

You Sacrifice Clarity for Brevity

Good examples of sacrificing clarity for brevity include unclear variable names and dropping the curly braces.

It’s a universal temptation to get something done in as few characters as possible, but that temptation is kind of like the temptation to only have one pair of underwear: sure, the laundry gets done quickly, but the problems that arise from your choicehugely outweigh the benefits.

Good examples of sacrificing clarity for brevity include short, unclear variable names (such as $a — what does $a store?) and dropping the curly braces.

Dropping curly braces from control structures is a particular pet peeve of mine. If you don’t like curly braces, switch to Python. In PHP, it’s just too easy to lose the meaning without them.

For example, look at this set of nested if-else statements without curly braces:

<?php

$foo = 8;

if( $foo<10 )
 if( $foo>5 )
 echo "Greater than 5!";
 else
 echo "Less than 5!";
else
 echo "Greater than 10!";
 echo "<br />Another note.";

At a glance, it looks like the last line should only fire if the value of $foo is greater than 10. But what’s actually happening is a case of improper indenting; the last echo statement will fire no matter what $foo stores.

Can you figure it out if you look at it for a few seconds and know that if-else statements without curly braces only affect the immediate next line? Of course.

Should you have to waste the energy figuring that out? Absolutely not.

Adding curly braces adds a few lines, but it clarifies the statement immensely, even with the odd indentation:

<?php

$foo = 8;

if( $foo<10 )
{
 if( $foo>5 )
 {
 echo "Greater than 5!";
 }
 else
 {
 echo "Less than 5!";
 }
}
else
{
 echo "Greater than 10!";
}
echo "<br />Another note.";

Yes, it’s a good thing to keep your code concise, but not at the expense of clarity. It’s worth the extra lines to ensure no one has to bang their head against a keyboard trying to sift through your code.

You Don’t Follow a Coding Standard

Choose a standard and stick to it.

Getting cute with your formatting might satisfy your artistic urges, but it does no good for anyone. Choose a standard (I recommend the PEAR coding standard) and stick to it. Everyone will thank you. (Including yourself, someday.)

Trust me. I was that guy once — I wanted to have a “signature style” — and I wasted a lot of hours fixing my atrocious formatting later on. There’s a time to be different and a time to do it like everyone else.

When it comes to programming, think of it like a spoken language. Grammar and punctuation exist for a reason: so we can clearly understand each other when we write things down. Think of coding standards like a geeky version of Strunk & White’s Elements of Style — following the guidelines means people understand what you’re trying to say, not that you’re a boring person.

You Duplicate Code

You’re doing it wrong.

Try to look at every single piece of your app as something that will need to change at some point. If it does, will you have to update more than one file? If you answered yes, it’s time to reevaluate how you write code.

If you’ve got code doing the same thing in more than one place in your app, you’re doing it wrong.

You Don’t Follow a Development Pattern

You should always have a structure when you code.

You should always have a structure when you code. I don’t mean to imply that you need to be following the MVC pattern or something equally rigid, but I do mean that you should know how to classify components and where they should go.

By following a logical development pattern, many decisions become automatic, and someone coming into your code doesn’t have to guess much when looking for a certain functionality in your codebase.

It doesn’t take long, and it really will clarify your apps in a big way.

You’re Too Clever for Your Own Good

The simplest solution is usually the most appropriate

There’s a fine line between a crafty solution and an overcomplicated one.

It’s always tempting to try out some sweet new trick you’ve learned, but we have to resist the urge to force a complex solution into a space where a simple one is sufficient.

On a basic level, the simplest solution is usually the most appropriate. You’re trying to get from point A to point B — taking a detour through point Awesome is fun, but really doesn’t add any benefits.

Your super-sweet solution does, however, pose a problem in which someone else may not have seen that particular solution and will just get lost. It’s not because they’re not as smart as you, either; it’s likely because they didn’t see that particular article or weren’t trying to force a square concept into a round problem.

Don’t dumb yourself down, but remember to avoid overcomplicating things “just ’cause.”

You’re a Wang

Avoid actively making your code hard to understand at all costs.

When I was first getting into development, I worked with a guy that was a self-proclaimed “expert” programmer. Whenever I had a question about a concept, he never gave me a straight answer; in order to get the answer to my original question, I had to answer a couple preliminary questions to “prove you can handle the answer.”

This guy was also really good at writing code that was cryptic,obfuscated, and just generally confusing.

Files like his are the result of programmers who think that they need to make their code hard to read in order to “keep the idiots out.”

The general philosophy behind this tends to be, “If you’re not smart enough to understand this code, you shouldn’t be in it in the first place.”

This is a deeply misguided and anti-social approach to programming. It’s a very elitist way of looking at things, and it shows that the programmer has lost touch with his beginner roots, when he himself needed help.

Avoid actively making your code hard to understand at all costs. It doesn’t make you any cooler or smarter, and it doesn’t bolster respect. It just makes you a wang.

Dude, What Are You Talking About?

If you stop learning, then the projects you work on are stuck in whatever time period you decided to settle.

In addition to the shortcuts and general laziness above, another thing that might be holding you back is a lack of continued learning and forward progress.

Technology isn’t changing because the community at large is bored and we decided to redecorate; most new technologies emerge to more efficiently and easily solve existing problems. Choosing to ignore progress is choosing to start the slow process of marginalizing your skillset.

Here are a few things we can all stop doing to make sure that our skillsets are up-to-date, all without having to give up our weekends.

You’re Trying to Do it All Yourself

Find out which of these programmers have a similar approach and let them fill you in on the big news.

You can’t keep up with the whole community. As anyone who’s ever tried to keep up with a subscription to 200+ tech blogs will tell you, it simply can’t be done within a reasonable timeframe.

Fortunately, there are those within the community who dedicate their time to watching the progression of technology and reporting their findings. If you take the time to find out which of these programmers has a similar approach and style, you can let them fill you in on the big news.

Watching 2-5 of these “early adopter” type bloggers can be more beneficial than subscribing to every tech blog you come across for several reasons:

• If you trust their opinion, they’ll be screening technologies for you.
• If a technology pops up on more than one of these blogs, you know you should at least take a few minutes to learn more about it because it’s obviously popular.
• Often, these blogs will feature a quick intro tutorial, which can save you the headache of starting from zero with a new technology.

You’re Not Out of Your Comfort Zone

I simply mean to suggest that you’ll feel more fulfilled as a programmer and see your talents progress more and more if you choose to always be looking to the next level of programming.

If you’re not doing something that challenges you, something is wrong. Finding new challenges within projects is most of what makes programming rewarding (or at least it should be).

Try asking yourself the following questions when you start looking at new projects:

• Is there a new technology that interests me that applies here?
• Have I learned of a better way to do this since the last time I took on a project like this?
• Is there a best practice I need to enforce that I could make sure to follow throughout this project?

Keep in mind: I’m not talking about doing anything grossly complex, here.

It can be as simple as remembering to add Docblocks to your objects, or as complex as making your app compatible withXMLRPC so it’s easier for users to post updates.

Just try not to settle in and convince yourself you’ve learned everything you’re going to learn. That’s when it’ll start getting ugly for you.

You’re Not Sharing

Always discuss your code with your fellow programmers.

The best way to improve is to discuss your code with your fellow programmers. This can be done through multiple avenues: if you’re feeling particularly outgoing, write a tutorial or release an open-source project; if you don’t feel up to something of that scale, maybe you could hang out on a community forum and offer help to the newcomers.

“How does helping the noobs help me progress?” you ask. Usually, if you post a solution that could be optimized, other experienced programmers are going to hop in and offer tweaks. So this approach is a double-whammy of awesomeness: you’re not only helping progress the community by offering your knowledge to beginners, but you’re sharpening your own skillset by hanging your chops out for everyone to see and help you develop.

You Don’t Have Any Side Projects

If you want to get into something new and cool that’s a bit too involved to put into a real project, the best way to learn is to start a side project that uses said technique.

That way, you can progress at your own pace, in your free time, and never risk missing a deadline or “doing it wrong.”

We’re All Guilty

If we’re doing it right, we should always be improving. And logic tells us that if we’re better now, then we were worse before. And if we follow that line of reasoning back far enough, there was a point where we were terrible.

I know that when I look back at some of the code I wrote in the past, I’m horrified.

So… Stop it.

We’ll never be perfect. But we can do everything in our power to make sure that we’re getting as close as possible.

What are your pet peeves when dealing with other developers’ code? Let me know in the comments!

Keeping on top of search engine developments is a must for marketing and brand management. Last week, Google tossed as large a monkey wrench into search as you might imagine: Google Search Plus Your World.

It means search results will now include posts and links shared by people you follow on Google+ when you click the appropriate link. The potential problem for businesses is that this isn’t a simple addition. Search results can become significantly different than you might have thought, which means different from your current SEO strategy.

Erin Everhart, director of Web and social media marketing at digital marketing agency 352 Media Group, found that social search can make results far less relevant. She searched for the phrase “web design company”:

Two out of three top results, traditionally coveted for clicks, are filled with social mentions. And social mentions that have nothing to do with a web design company.

Google’s long been under fire for an algorithm that struggles to produce the most relevant results, and with Search+, it seems that they aren’t doing much to head in that direction. Yes, it does add more trust and authority to your results, but not relevance.

Search expert Danny Sullivan found his own examples of how the new search approach can promote Google+ over relevancy. Furthermore, the “suggestions show up even if you’re logged out and anonymous to Google.” Personalized search is also opt-out, not opt-in, so inertia will keep most people using the system.

In short, if someone’s Google+ contacts aren’t talking about a company, linking to it, or providing a +1 (Google’s equivalent to a Facebook like) to the company, chances are that a company or brand that would otherwise be relevant to the person’s search may get pushed further down in results. Push them down far enough—it doesn’t take that much—and the company is now invisible for all practical organic search purposes.

Sullivan spoke with Amit Singhal, who is in charge of Google’s search algorithms. Singhal said that Google would be open to incorporating results from Facebook, Twitter, and other sources, but claimed that those companies don’t allow Google to crawl through data and store it in indexes.

But don’t expect those companies to change their minds and allow Google to bring that data up in search results. They don’t want to give up the advantages having their own data offers, nor will they want to hand over insights into the personal connections that presenting personal results would require.

Because Google is promoting Google+ links in search results, companies and brands must be on Google+ in effective ways. That means getting the attention and approval of influential people.

Everhart also says that companies will have to incorporate their keywords into their Google+ pages, because Google search results push Google+ pages so thoroughly now. If not, they lose important chances to be noticed by prospects and customers.

Been avoiding Google+ previously? Now’s the time to reconsider.

In jQuery the easiest way to do that is to use the built-in ajax functions to call the XML and use the each function to loop through all the nodes. The each function is nice, but is much much slower than a for loop. Just imagine what happens when we have an XML document with multiple levels of nested nodes you need to get at. You end up with multiple nested $.each functions and without much trying, you end up with a script that crawls. With JSON it’s easy to get at the data since its already native javascript. No parsers or proxies necessary–all you need to do is loop through the data, fast and simple. That’s one point for JSON.

There are aspects of XML that people point to as reasons to use it. First, XML is both human and machine readable. It is nice to see what data is being returned just by viewing the source, but that problem is solved by having good documentation, including an example of the JSON that will be returned. Also, being a front-end developer, I spend a lot of my time reading javascript anyway. I find it just as easy to read as XML, it’s just different.

Another good reason to use XML is that it’s widely available. Lots of websites offer APIs to get at their public (and sometimes private) data, and I usually find the returned format of these APIs are often either XML or JSON. However since XML has been around longer than JSON, there is simply more XML out there.

Sometimes you might find yourself in a situation where you don’t have JSON as an option. So do you submit to the API gods and slow down your site and just use the XML? Why do that when you can write the API yourself! This is where some server side skills come in handy. It’s super easy to load an XML document via PHP and print out the data in whatever format you need it to be in.

So in conclusion, you should be using JSON every chance you get.

You may be thinking about joining the website blackout movement, but yikes … what about the SEO implications? How do you take your site offline in protest without messing up your visibility in Google’s search results?

Well, Google’s Pierre Far shared several tips earlier today on Google+ in a post called “Website outages and blackouts the right way.”

In short, the advice is to use a 503 HTTP status code to tell spiders that the website is temporary unavilable. With a 503 status, Google won’t index the content (or lack thereof if you’re blacking out your site) and it won’t consider the site as having duplicate content issues (when all of the pages are blacked out).

But Far adds a couple important caveats to this advice regarding the robots.txt file and what will happen in Webmaster Tools if Google finds your site blacked out. Another Googler, John Mueller, adds additional information in the comments, so you’ll want to read the original Google+ post if you’re thinking about blacking out your website this week for SOPA, or in the future for any other reason.

Of course, also keep in mind that Bing may not handle things the same way if you do blackout your site.

At the end of our first year in business I got on my knees and prayed to God for a sign: whether we should continue our business.  Even though sales were coming in, we had zero profit to show for it.  A week later, we closed a deal with a large airline to have our wines served on their international flights.  Although we got the sign, there are certain other things I wish I would have known back then. I wish I would have known the real skills required to be an entrepreneur.

I’ve learned a lot in the past few years—and a lot of the necessary skills to start and run a fast-growing business just aren’t taught in the classroom. Here’s my list of five things school didn’t teach us about starting a business.

Starting your own business requires vast sacrifice.  OK, I’m aware it’s cliché to say this. Everyone who writes about entrepreneurship says this. But I can’t emphasize this enough.  No one can prepare you for the mental, physical, social, emotional, and spiritual stress starting a business will put on you.  It’s an all-encompassing endeavor that will test you in ways that working a 9 to 5 will not.  For us, it tested our relationship in ways that almost tore our young marriage apart.  For example, in the past seven years of marriage we’ve had both the time and money to take one single vacation. During the first three years of marriage we rarely had time to date—you know, continue that courtship that led to marriage in the first place. We were performing the equivalent of the jobs of six people with two people, and that meant physically not having time to eat or sleep. It meant missing out on some of the little things that make a marriage successful. We had little time to develop our young marriage and we lost contact with both family and friends.  As you consider pursuing an entrepreneurial venture, ask yourself if you can handle the personal sacrifice that comes with this venture.

Success rarely comes fast.  People read stories about Facebook, Google, Youtube, LinkedIn, Amazon, and all the other expeditious rises from start-up to powerhouse, and think that success comes quickly.  This is rarely the case.  In fact, Amazon and LinkedIn took several years before they made a profit.  In today’s world, particularly us Gen Y-ers have been trained to love—and expect—immediate gratification.  We have DVR, iPads, Netflix and the like technologies all catered to give us what we want when we want it.  Starting a business isn’t so fast or seamless. If you want to start a business and want it to be meaningful, be prepared for it to be something of a slow process. With the economy in the midst of a recession, getting the resources, both human and capital, may take a longer than you’re expecting.  This doesn’t mean that the business will not be a success; this just means that you have to have some patience to realize that success.

You need to be prepared to shift gears. In starting our company we had a vision for what we wanted to accomplish with the company. We created an initial strategy that was e-commerce based. But this strategy also coincided with the downturn in the market, which saw our e-commerce sales drop by 50 percent. Not to mention within the wine industry as a whole, 70 percent of wine is consumed within six hours of purchase. My wife and I did not let this kill our business. Instead, we shifted strategies quickly and began to think outside of the box to assess which consumers would have the most pressing desire for our products. This led us to the airline and hospitality industry. Now 30 to 40 percent of our business is done in that area.

The real “sales secrets” can’t be taught. Whether you are selling a product or a service it is crucial that when you get in front of customers, clients, or consumers, you can close the sale. Only you cant teach someone all of the elements of closing a sale in a classroom. Being able to read people, or have the right charisma in front of a customer is something that can’t be taught. Thankfully for our company, this hasn’t been a struggle for us: Selena has an uncanny ability to sell in our company’s products. This clearly comes from her experience in sales and her passion for our business that shines through. I believe great salespeople share certain characteristics that go beyond teachable skills: they must like engaging and interacting with people. They must like being a problem solver. They must have an eye for creating mutual value between you and the client. If you don’t have those skills, it does not mean that you can’t sell well—it might just not come naturally to you. If that’s the case, hire or partner with someone who does. The value of a good salesperson is immeasurable early on.

Think big, even when you’re small. When starting the business we thought early on about how to quickly scale.  We tried to gain national distribution rather than establish a solid footprint in one market. What we didn’t know is that it’s OK to start small and grow once you’re steady. The name of the game early in a business’s life is to generate sufficient cash flow to support the growth of the business. For businesses that are self-financed, or those in which the founders have significant skin in the game from a cash perspective, this is crucial to the longevity of the business. By pushing to scale your business fast, you place the business in a situation where it needs added investment and resources to grow that you may not have. This may result in you losing control, taking on partners that you would otherwise have not, have others empowered to impact your strategy in ways that are not aligned with your vision for the business. So, take your own pace.

I wish I would have known all these things back when we were starting out. Sure, these tips aren’t necessarily the most glamorous, but they are essential in determining whether you have the appetite to do what it takes to ensure a successful outcome in founding a business. There are no guarantees, but if you’re reading this article, you at least owe it to yourself to reflect and ask your self how you’d respond to being placed under the worst of all “what if” possible scenarios.

Flash is cool, right? And that lovely welcome screen and information-rich homepage your client wanted are just perfect. Or are they? We talked to six top designers and creative directors about their Web design pet peeves. What makes these pros cringe might surprise you.

1. Putting your brilliant design first

“Whether or not the site is designed elegantly, what really matters to me is whether the navigation is intuitive, and whether the information is organized well. Design, for as much time as we spend on it, if it’s all about the visual elements, that can quickly get someone out of that site. I always try to focus on making sure the information makes sense before putting mouse on screen. Plan ahead. Get the answers before laying anything down. Get together with your project manager and design team, and get all the info from the client before start designing. It’s also important to get the navigation in front of people to make sure everyone can get that information quickly. Be constantly testing. Only then should you build the beautiful elements, the design of the site, around that. If that’s not there the site can be considered a failure. “

— Andres Orrego, associate creative director of Chowder Inc. in New York

2. Going overboard with Flash

“Flash is certainly a pet peeve. It has its place, for sure, but since the dot.com bust we’ve come a long way. Today our customers want to be found – they expect to be found – but what does that mean for us? We need to set the stage for search engine optimization, so we need to stay away from Flash. When I see a site overly done, you ask yourself, does it really make sense for you to do that in Flash? No.”

— Antonio Navarrete, president and creative director of SilentBlast in Toronto

3. The unwelcoming welcome screen

“I hate everything about welcome screens. By clicking a link, I’ve already said that I want to go to visit your site, so there is no need to show me a ‘welcome’ screen with a quote. In fact, it is almost insulting to call it a ‘welcome screen’ – I’d almost respect it more if it was called a here-is-an-ad-so-we-can-make-money screen.  As it is, this intermediate screen just delays users from accessing your content and gives them an opportunity to leave before they ever arrive.”

- Andrew Cafourek, co-founder and digital lead of A022 Digital in New York

4. The boggling homepage

“People who are using your site, buying from your site, are not going to stay there or buy from you due to your awesome design. Most homepages are completely overwhelming. There is so much there – people try to communicate everything to everyone, and the real content gets lost. That’s a design disaster. It should tell people in three to five seconds who you are and what you do. That’s it. We have a design philosophy that we take from architecture: form follows function. When you are building a building, you want right angles and perfectly usable space. If you go to our homepage, you will see cleanliness and simplicity. I say this left and right, and my designers say it left and right: Websites have to breathe.”

- Marvin Russell, creative director of The Ocean Agency in Chicago

5. Worshipping the fold

“There’s been this maintained notion that everything has to be above a certain pixel dimension, and that everything below that gets lost. I don’t think that’s where we’re at anymore. People do scroll. They like portals. So especially with makingBarackObama.com, that was something we stayed away from: We knew people would scroll, and we really wanted to keep more information on the homepage, make it a portal, and allow for more content to be available on the portal page.  I think the key to making it work is making sure you present something and design with the pixel dimension in mind. On another site I did, there’s type interacting with an image makes you aware that there’s more going on below. Especially when you’re on blogs, they become very blah-y, and there’s no contrast in post styles. They don’t keep a variation that keeps readers interested. Variation in consistency lets you forget the fold.”

- Scott Thomas, a.k.a. @SimpleScott

6.  Not addressing the user’s real need

“Many companies organize the site around their own internal categories, which is different from what the audience is actually looking for. In other words, they’ll build a site around products, because they’re thinking they have to sell the product and the product needs to be front and center.  But when you think about it, you have to reverse it and first ask what need are you solving, and then present the product. I think there’s internal anxiety to make sure things get covered as a checklist, versus really stepping back and understanding what the users need. You have to have the perspective of an audience that may not know your brand, and there’s very often a complete absence of making people aware of your brand is, and why it’s relevant.”

- Sean Ketchem, strategy director of communication of MetaDesign in San Francisco

7. Hiding who you are

“Transparency on the Web is the hottest and the biggest thing as far as getting people to purchase or relate to your services. Our portfolio page was always No. 1 for the seven years we’ve been in business. But then we created videos of each one of our employees talking about what they do and why they love it. That page is now No. 1. By far, the people behind the process, behind the product, are extremely important. We’ve had clients say ‘we went with you because we got to kind of meet everybody before we even walked in the door.’ The buying process starts with a relationship. That process can start with a video and tell you personally what I do rather than just a photo and a title. Really show them rather than tell them.”

- Marvin Russell, creative director of The Ocean Agency in Chicago

The shift will dramatically impact how people search—and how potential customers find you:

Mobile search behaviors are different

No matter how nimble their thumbs, most people type faster on a traditional keyboard. Most people also automatically adopt a form of shorthand when using mobile devices and are more likely to rely on autocomplete suggestions. As a result your current keyword strategy could steadily become less effective. Say my kitchen sink is clogged; on a desktop I may search “how to unclog a kitchen sink,” but mobile search is more likely to be “clogged sink” or “unclog drain.” Shorter keywords and different phrasings will become more prevalent, long-tail keyword strings less effective.

Voice search will be different, too

Granted, currently Siri is a less than effective search assistant. But Siri and similar applications to follow will get better. Voice-generated searches are likely to be performed conversationally rather than with “search” language; instead of channeling my inner Yoda and typing “’drive shaft ‘57 Chevy refurbished,” I’m much likely to say, “Where can I find a refurbished drive shaft for a ’57 Chevy?” Voice search, like mobile search in general, will change how businesses identify and target keywords.

Mobile users mostly want it now… 

Mobile search skews heavily towards immediate needs: Finding a store, booking travel, finding products, and placing orders… the average mobile user is unlikely to engage in heavy research. If your current strategy is to provide rich, in-depth content that gradually leads a visitor towards a purchase, that approach won’t work for an increasing number of searchers. Mobile visitors tend to have more immediate needs than desktop users, so you’ll need to address those needs.

…and they want it short and sweet

Many businesses provide comprehensive how-to information designed to help customers but also to drive SEO results. (A friend converts a significant percentage of visitors who initially arrive to his website seeking information but soon decide they prefer to pay for a solution.) Mobile users won’t scan a page with multiple resources, tons of links, several videos… what feels “rich” on a desktop feels overwhelming on a mobile device. Providing how-to information will still be important, but the way you deliver that information will need to change.

So what should you do in the short-term?

Start experimenting now. Create a few new pages that feature different keywords than you currently target. Create a few “bite size” pages designed for mobile users. Try different combinations of photos and videos on select pages. Analyze your results and determine what works well for a small but growing slice of your Web audience.

Most of all, assume what works today will not work tomorrow—so start testing and adapting today.