So, from a 10,000 point of view it will help me to explain that, while most people know what a processor is, many consumers don’t realize how many different varieties of processors exist. Most desktop machines use a family of processor commonly known as “x86″. PCs and Macs alike use this variety of processor, and over the course of Microsoft’s history they have made the largest profit selling software to run on x86 machines.

However x86′s dominance as the de facto champion of all computing platforms has recently been challenged. Mobile devices, such as smartphones and tablets, often favor alternatives that consume much less power than x86 units. One family of mobile-friendly processors that has emerged over the past decade is the ARM family of processors. With an increasing number of casual Internet users transitioning to using these mobile devices more frequently than their full size computers, it seems as though x86 could soon be relegated to only being used by computing professionals and hardcore gamers. Granted, that is still a long way off, but that’s my personal opinion on the way the market is headed. Take it for what you will.

Now, typically, software manufacturers that sell directly to consumers won’t care too much about on what platform their software is going to be executed. In fact, before Mac switched to Intel chips, it was not uncommon for manufacturers to produce a version of their software to run on the old Mac processors (PowerPC, if you care to know the name). Given the emergence of ARM, and the general diversification of the consumer device offerings, it isn’t surprising to hear that Microsoft is planning on producing ARM versions of their popular Windows Operating System. (In fact, they might do so already to be honest – I just don’t know.)

What is surprising is that it seems, according to ArsTechica, Microsoft is going to make it harder to install an Operating System other than Windows on ARM machines that ship with Windows pre-installed. They plan to do this by making their feature called SecureBoot mandatory for these machines. This strikes me as very, very peculiar. What raises my eyebrow even further is that they mandate that non-ARM machines must allow users to turn SecureBoot off.

I struggle to imagine the reasoning for this. Windows, as it exists now, wouldn’t make much sense as a mobile Operating System. There have for a long time been a mobile variants of the OS that they have used for mobile phones, but to the best of my knowledge they have never used full-on Windows in a mobile device.  

There has been talk of ARM based economy PCs hitting the market, which is all well and good, but I’m beginning to suspect that – in spite of these new low power PCs coming out – Microsoft actually is planning to do something big with Windows on mobile because the people who buy economy PCs aren’t likely to hurt Microsoft’s market presence or revenue in the desktop arena. It’s not like they have an equivalent of Apple’s App Store that gives them continuous revenue. 

However, if they were going to give a model like that a shot for their “big boy” operating system, they would be smart to do it in the Mobile arena first. And if they did do that, it would be on ARM chips, and a large number of people not using their Operating System would significantly hurt the viability of such a continuous revenue business model.

Additionally, this is a marked change from how Microsoft has operated in the past. It’s a very Apple-esque move in many ways.

Microsoft has talked before about trying to give a constant feel throughout their products. Indeed, the XBox dashboard now looks like an HD version of a Windows phone in some respects. It is reasonable to suspect that the next step in that endeavour is unifying their mobile and desktop Operating Systems, and attempting to build a continuous revenue model to capitalize on their users after they purchase the original product.

Whether or not that will actually happen is something only time will tell. For now, we just have to sit and wait. As always leave me some comment love below. I’d love to hear what you think.

However, these sites really only work for people who get some sort of gratification from achieving those points or rewards. I am not typically one of those people. Don’t get me wrong, I do find it rewarding, but it’s not likely to make me feel rewarded enough to return to the site. (I’m also not much of a gamer in general. Skyrim has been sitting on my shelf, unopened, for over a week.) Yet, there is one thing that is always particularly effective at motivating people like me: money.

It would seem that there are new companies starting to pick up on this trend. 21habit, a site started by Microsoft and Amazon engineers, is designed to help you kick start life changes by guiding you through a 21 day challenge where you must report regularly about your success or failure. The service offers the traditional, no penalty, method that many Gamification structures offer. Yet for those who need some extra motivation, they’ve also provided a “committed” mode. Essentially, if you use the committed mode you wager $21 that you will complete your goal each of the next 21 days. For each day you succeed, you earn back $1. For each day you fail, $1 is donated to charity.

Another new-to-the-arena company named GymPact is doing something similar. Members of the service participate in a pact to go to the gym a certain number of days each week. On weeks you do not succeed, you loose some money. On weeks you do succeed, you get paid. GymPact uses the money from the pool of people who failed to meet their goal to pay those who succeeded. Overall, it is an interesting concept – but as a business model it sucks because it only works as long as there are people using the service who consistently fail. If everyone succeeds, then everyone… well, looses. I don’t see money motivated people like myself being willing to “take one for the team”, but I can’t deny that the concept is still interesting. 

I suspect we’re going to see a lot more of the money-powered gamification sites pop up. Overall, sites like Fitocracy and others have had a hard time attracting users who just aren’t motivated by some fictional currency. Naturally, the next logical step is to create sites that use a tangible currency to motivate its users. 

So what are your thoughts? Do these sites sound like something that would appeal to you? Leave me some comment love and let me know!

Further Reading:

• TechCrunch article on 21habit
• TechCrunch article on GymPact

Quite simply the service enables you set up triggers between multiple services in a dead simple fashion. Currently it supports a handful of services, including Twitter, Facebook, WordPress (Hosted and Self-deployed), Flickr, Craigslist, and more. As you can see in the screenshot above I’ve set mine up to auto-syndicate my blog posts to my Twitter and Facebook accounts. (This blog post will actually be the first to test these new triggers.)

Setting up new triggers in IFTTT is done in a Wizard format that guides you through the process of setting up your triggers and actions.

Overall, I’m pretty excited about this. I wish they had a few more services (such as Gravatar), but overall it is a pretty promising selection. They are still in “beta” status, so I expect that everything I’m missing will come in a future release. If you’ve got some time to check it out, then please give it a spin and let me know what you think. I expect a majority of my readers will have already heard about IFTTT, but I’m sure there are a few who come here from links on my Facebook feed who haven’t yet.

You can get to IFTTT by pointing your web browser to ifttt.com (or clicking that handy link). I’m just now scratching the surface of what I can do with this little gem of internet automation, so I’ll be sure to keep you guys apprised of anything cool that I come up with in later blog posts. As always, I’d love some comment love with your thoughts on it. Does IFTTT sound like something you would use? Or, are you already using it?

Essentially, whenever we’re working on a change that is going to be more than one or two lines we create a new branch on our git repository. We do any number of commits to our new branch, and then push our changes. Since we use Github for our repository hosting, we can then open a Pull Request to let everyone else know the code is ready to be reviewed. Then someone else will review the code, and check the code out to test it for any bugs.

Admittedly, I was apprehensive about this process at first. Mostly because I had never participated in a team where code review was done well before I came to OpenStudy. With most of my recent employers I had a lot of autonomy from other team members or supervisors. As long as my clients were happy, everyone else was happy. Usually code review only happened if someone wasn’t happy. Of course, I didn’t expect that autonomy to remain the same in the transition to a product-oriented company. It’s just not realistic, and it shouldn’t be. So I braced myself for some transitional pains when we started this workflow.

I found that the transition to the code review process at OpenStudy wasn’t nearly as painful as I expected. In fact, our code review process has been invaluable over the past month in my learning process, finding bugs in the code before the changes got merged into master, and otherwise making sure that the code we eventually published to our server was relatively polished. Nothing is worse than preparing a release, getting excited to push it to the server, and then realizing something is horribly wrong as soon as you get it live. Of course, I’ve never actually had that happen (cough cough).

So, the process of code review has been throughly beneficial to me. Although I can’t speak for Antonio and Matt, I suspect they have similar sentiments. I encourage you to strongly consider implementing a similar process in your development team as well. If you do decide to do so, I have a few ideas that you may find helpful. These are some things that I believe we’ve really done right at OpenStudy, and that have made the process more valuable for everyone involved.

First, everyone participates. Anyone who is actively coding needs to participate in the code review process, regardless of their position within the team. The truth is that being around longer, or having a more senior title, doesn’t make you immune to human error or mean your ideas will always be the best, yet I’ve heard many a horror story from friends who work under a managing programmer that doesn’t understand that. Unfortunately, my friends end up cleaning up the mess left behind by their boss more often than not.

Additionally, code review is one of those things that works best when everyone buys into it. The more buy-in that your team members have in the process, the more beneficial it will be for them, the product, and the whole company. The best way to get a team to buy into code review is for everyone to participate. So, even if you are that guy who is capable of taming two lions while writing perfectly formed assembly, you should still allow your code to be reviewed by your colleagues.

Second, we use GitHub. I was one of those people who honestly didn’t see a whole lot of value in GitHub over hosting my own private Git server. I’ve never been in a position to use their pull requests before, but it didn’t really sell me on them based on my initial assessment. However, at OpenStudy we make extensive use of what I’ve come to believe is GitHub’s golden egg: the line commenting feature. It’s possible for any one of us to single out an individual line in a file and ask a specific question about it, or make a specific suggestion. The benefit is twofold: the topic of conversation is immediately visible for anyone reading the pull request (no fumbling through a file looking for the contents of the specific line), and conversations about distinct issues or lines stay separated.

Overall, this reduces the amount of time we spend trying to communicate a specific problem or question and increases the amount of time we actually spend addressing the issue.

Finally, we encourage open communication. The idea behind open communication during the code review process is that all participants in the review converse back and forth on the suggestions that are made. This is what sets “code review” apart from “code approval” and enables the developers to learn from each other, instead of blindly issuing a list of corrections. Developing a good product is a team effort, and no line of code stands alone. Of course if your team ends up at an impasse in the conversation someone needs to be able to pull rank to keep the forward momentum going, but that should always be a last resort.

Code review may not work for every team, but it works pretty well for us. So, leave me some comment love below. I’m sorry it’s been so long since I’ve posted on here – but it’s been a really crazy month. I hope you and your family have a safe and excellent New Years, and here’s to hoping that I get back into the rhythm of regular posting in 2012.

This bill is especially bad because Section 102 of the bill requires that, after being notified of infringing content, service providers are required to take steps to prevent access to the content (link) and search engines are supposed to make the links magically disappear from their results (link). Similar provisions exist in the bill for payment processors (link).

Do I support online piracy? No. I believe people deserve to get paid for what they do. However, I also believe that under no circumstances should the government be allowed to interfere with the business of non-co-conspirator third parties with just a court order. The precedent this sets is dangerous, and scary.

Look into this yourself. Check out the OpenCongress profile for the bill. Read the text. Write your congressional representatives. Call them tomorrow, Wednesday November 16th.

We must prevent this bill from being passed or, I fear, give up our protected rights under the First Amendment in the digital world.

Contrary to popular misconception, the idea of an iPad isn’t anything new. Touch screens have been around for decades in various shapes and forms. Of course, the technology got a heck of a lot better, but it’s all the same really. It’s this idea of direct manipulation - or being able to directly impact the elements that you see on your screen with natural movements as opposed to learned movements. For example, “touch and drag” as opposed to “click and drag”. To the people selling tablets, this is the holy grail. Just look at any iPad Commercial. (More after the break.)

The salespeople would have us believe that this is the holy grail of technology. But today I had one of those moments where I felt as though I had been whacked on the head by a bat (I do know what that feels like), because touchscreen technology isn’t the holy grail. It’s a stepping stone.

I had this revelation today while reading Bret Victor’s article titled “A Brief Rant on the Future of Interaction Design”. Go read it. It’s very non-technical. It’s incredibly… obvious. He first shows this video that displays some “visionary” concept of technology in the future, and then proceeds to point out some flaws in it.

Usually I don’t like to create a blog post unless I feel I have something significant to add to the conversation. I’m making an exception this evening. I’m really convinced that this is something that everyone in the tech industry… scratch that… everyone in every industry should read.

What jobs do you do on an iPad, for example, that would be easier if you had more actions you could do? Have you been disappointed by the “pictures under glass” effect? Leave me some love in the comments and let me know.

On an unrelated note, I have some exciting news coming in a few weeks. Stay tuned.

Ooops. It seems the quote from their help page regarding birthday changes is accurate, but it still makes me ask “Why?” I honestly can’t think of a good technical reason for this limitation. Their help pages refer you to their community standards on this matter, which leads me to believe there is no technical reason. Since the community standards makes no explicit mention of a birthday change policy, I’m inclined to believe they just don’t want you to do it.

These types of policies make me believe that they are a bit out of touch with their user base. Or, perhaps all the engineers at Facebook are just playing this prank on each other and want it to stick for before it can be undone.

Yeah, I’m going with option 2.

“Steve Jobs Killed My Joke By Being Funny”

Steve Jobs Replies To Email: “Are You Nuts?”

Steve Jobs emails: “We will keep making the best computers”

But, instead of rambling on with some mopey monologue about how we’ve lost a pretty awesome guy – I think I should instead share something that he said back at the Stanford University Commencement in 2005: “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking.”

Apple’s homepage, for the first time that I can remember, has foregone their normal promotional spot. In its place is a picture of Steve himself, and text that reads “Steve Jobs 1955-2011″. Wikipedia has documented a list of statements about Steve Jobs’s death. CNN has also compiled a pretty good list of reactions to his death. Go look over them when you get a chance.

Stay hungry, stay foolish.

When I was working for the University of Georgia, I was introduced to Subversion. Subversion was, and still is, a powerful version control tool. However, recently I’ve come to prefer Git due to the increased flexibility that it provides. There are some things that are possible with Git that aren’t doable with Subversion, and in my humble opinion these features can make managing multiple copies of an application much, much easier.

In today’s article I’m going to go over a few introductory Git terms, and then I’m going to give some tips on cool features in Git that made my life easier. Both of these features are things that Subversion just couldn’t do. This article is not an attempt at a fair compare and contrast between Subversion and Git, so if that’s what you’re looking for, then look elsewhere.

Now, let’s get started.

Git Terminology: Bare Repositories, Remotes, Push and Pull, etc.

In oder for what I’m going to explain to make any kind of sense, I’ve got to explain a few Git concepts. If you’re already fluent in Git, feel free to skip ahead. I’m going to explain these terms from the point of view of someone who already understands Subversion. If you don’t already understand Subversion, then you’ll probably be a little lost – but don’t be afraid to use the Google machine and get caught up with the rest of the class.

The first thing that I need to explain is the concept of push and pull. If you’ve worked in Subversion for awhile, you understand that when you run a commit Subversion takes your changes and uploads them to the Subversion repository on your organization’s version control server. Git works a little bit differently. Unlike in Subversion, your working copy is a bona-fide Git repository. So, when you commit your changes – you’re not doing anything on the network. You’re just updating your local Git repository.

Of course, version control doesn’t do much good if you can’t share your changes with your team members. So, Git introduces a few new commands. The push command takes your repository and publishes your changes to a Git repository elsewhere. This can be accessed using straight SSH or you may have some sort of Git server (i.e. gitolite or gitosis) running that your client talks to. Much like Subversion, you can’t publish any changes unless you already have the latest copy of the code in your local working directory. (If you try, it will fail.) So, that’s where pull comes in. It allows you to retrieve changes published to the shared repository and merge them with your current repository.

In Git, these shared repositories are called remotes. However, not all remotes have to be shared among several people. A remote is simply some Git repository that lives on another machine that has a shared history with your Git repository. By default, the “official” repository that your code comes from is named “origin”, but you can name remotes whatever you like. Additionally, you can interact with remotes using any protocol that lets you interact with the file system (SSH, FTP, SFTP, WebDAV, etc) making this feature really flexible.

As I mentioned, remotes are Git repositories. However, most remotes are a special kind of Git repository known as a bare repository. Your working directory on your computer would be a non-bare repository. The distinction is simple: non-bare repositories are places where code needs to be edited or run, while bare repositories are strictly for storage – and thus don’t have decompressed, complete copies of your source files readily available. Bare repositories only consist of the Git repository database. The files that make up your application are not extracted in editable form.

Finally, Subversion has the concept of a trunk and branches. In Git, there are only branches and the master branch is the equivalent of the trunk in SVN.

Now that we’ve got the basics down, let’s get rolling with the fun stuff!

Code Management: Use the Stash

One of the unfortunate things about PHP development is that you have to store database and application startup settings somewhere. And if you have half-decent system admin, the login credentials to the database on your development machine will not be the same as the login credentials on the production server. Usually, the database login credentials and database names will vary from development machine to development machine as well. If any of these machine-specific changes make it into the central repository, then someone’s code is going to be broken or conflict when they update or pull.

At Boxkite, we solved this problem by making database.dist.php a versioned file for database settings. Then we required developers to create their own database.php in the same directory to get the app working. We then used the svn:ignore setting to make sure that the user-specific database file never made it up to the central repository.

This strategy works fine. You can even take it a step further in Git by not requiring the separate file. You could store the production settings in database.php, then when users clone the repository they could change it to support their local settings and run:

git update-index --assume-unchanged path/to/config/database.php

- and voila! The database settings won’t be committed.

Recently, I’ve been staying away from this convention for a few reasons.

1. If someone updates database.php with real, useful changes (additional config parameters, etc, etc) you’ve got a bit of a mess on your hands.
2. Something doesn’t feel right about telling Git to lie about the status of the file. Doesn’t seem like a clean solution. Maybe I’m just neurotic.
3. It also seems like doing this something that could cause a new intern or someone else headaches down the road because it’s not immediately obvious what has happened when you are looking at the output of Git’s status command.

If we were in Subversion, we wouldn’t have much of a choice. However, Git introduces a new concept called the stash. To do a merge on a file, say foo.php, that file can’t have uncommitted changes sitting out in your working directory. Git will complain and ask you to either stash or commit the file.

Now, if you’re currently working on foo.php and you’re not entirely sure you want to share those changes yet, a commit is a bad idea. After a commit, your changes are a part of the history of the repository. Instead, I recommend you utilize the stash, which is a part of your local repository that’s not shared with any remotes.

The stash a stack, so you can push things on and off in a first-in-first-out order. Optionally, you can also explicitly recall a particular entry and apply it. It’s dead simple to use. Running git stash will stash all uncommitted files in your working directory – reverting them to how they appeared at the last commit. This allows you to pull, merge, and do whatever you like. Then, when you’re ready to have that work-in-progress back, you simply run git stash apply and Git will redo those changes in the files in your working directory.

Deployments: Push to Non-Bare Repositories

If everything in Git is a repository, then it makes sense that if you have a web application running on a server somewhere then there’s a good chance that the actual web directory of the project will, itself, be a Git repository. (Much like it would be a Subversion working directory if you were using svn.) This makes a lot of sense, because it means you can push changes to the central Git repository, and then pull those changes down to the production server like you would with Subversion.

However, Git allows you to do something much more powerful than this. Git allows you to push directly to the copy of the application on the live server. This may seem like a subtle distinction, but there are some benefits.

1. If you work for a company like mine that has an edge firewall around our network (where the central Git server is) and some of your clients are hosted offsite, then you don’t have many other options.
1. Configure your client’s server to connect to your company’s VPN (which probably wouldn’t make the security guys too happy)
2. Manually FTP files. (bleh)
2. You don’t have to log into the server and CD to the directory to do the update.
• May need to enter your password unless you have SSH keys set up, but still faster than manually navigating to the directory in the terminal.
• Mentally, this means you don’t have to deal with a change of context. You’re still located in your working directory when you’re finished.
3. You can script actions that happen automatically when you push to the directory using the post-receive hook.
• Most of the time, you’ll probably just want to script the git reset command so your changes get unpacked to the working directory. But Ruby on Rails developers can use Git to run touch tmp/restart.txt and reload the application server and make the new code live.

Setting this process up is fairly simple. You’ve got to create the Git repository on the remote machine, then add the remote to your local repository. In brief, it looks something like this.

On the remote machine:

1. Create the directory you want the project to live in on this machine. CD into the directory.
2. Run git init
3. Run git config receive.denyCurrentBranch ignore, then this repository will be set up to receive content.
4. CD to .git/hooks and create a new file named post-receive. Then, in that file add the following lines to tell git to update the working copies of the files every time an update is pushed:

GIT_WORKDIR=..
git reset --hard

Then, on your machine:

1. CD to your local Git repository for the project.
2. If you’re using SSH then you’ll need to add a remote using a command like this (I’ll assume the remote is named “production”):
   git remote add production ssh://user@host/path/to/remote/repo
3. Then, all you need to do is push your master branch to the production repository:
   git push production master

Your code should now be on your server ready to run! It’s worth mentioning that you’re not restricted to using Git commands in the post-receive hook. You can execute whatever you need to get the job done and automate getting your code live!

Further Reading

• Git Book – Distributed Workflows
• Git Book – Stashing
• Git – SVN Crash Course — For those interested in migrating to Git from SVN.

Conclusion

This has admittedly been a very brief overview of two particular aspects of Git that I’ve really enjoyed. At under 2000 words, I don’t think I really did the power of these features justice, but hopefully I did whet your appetite to learn more about Git if you’re not already a user. If you’re new to Git, hopefully this has reaffirmed your decision to make the jump from where ever you’re coming from.

As always, leave me some comment love with your thoughts.

I’ve had regular exposure to Mac OS for years before I switched to Mac myself. I’ve used Mac OS 8 a little, and Mac OS 9 much more. In my humble opinion, the progress that has been made between Mac OS 9 and Mac OS X Lion is a leap that would have taken many corporations much longer than 14 years to accomplish. OS 9, in comparison with Windows 95 and Windows 2000, was a joke. Yet, here we are some years later and the tables are completely flipped. Apple has gone from being the butt of the joke of internet message boards, to a company revered for their forward thinking. I think most, if not all, of the credit for that goes to Steve Jobs.

Now, we find ourselves in the situation we all knew had to come eventually: Steve Jobs has resigned from his post as CEO of Apple due to health reasons. You can even find some pretty ghastly looking pictures on him online if you’re into looking at that sort of thing. Many people are speculating that this will mean the end of Apple as an industry leader, and concerns over the stock price for APPL, which currently sits at $383.58, have surfaced as well.

Naturally, I feel compelled to throw in my two cents. To put it simply, I don’t think Apple is going anywhere – at least not anytime soon.

It is safe to say that Apple has plans in place for the next few years. And even if those don’t pan out entirely due to some lack of consumer confidence – they’re not exactly hurting for cash. Additionally, running the company isn’t exactly something new for Tim Cook, Jobs’s successor, since he assumed that role in Steve’s previous absences – in 2004 and 2009 – and in fact has been the de facto CEO since January when Steve started his latest medical leave. I think it is safe to say that for now, the status quo will be maintained and Apple will continue to push the industry forward.

Of course, the other question on everyone’s mind is whether or not Tim Cook will have the same “vision” that Steve used to make Apple what it is today. Once we pass these next few years, and Steve Jobs’s influence on the company trends towards zero – will they be in trouble? Unfortunately, only time will tell. I personally think that we’ll see Apple’s innovation continue to set the curve – even after Steve is no longer involved in the company. Look at the degree of confidence that Steve seems to have in Cook’s ability to run the company (Jobs wouldn’t have let him do so three times if he didn’t believe Tim Cook was up to the task).

There are certainly a lot of changes I would love to see happen in the next few years, especially to the way Apple treats the iPhone Developers Program and the App Store, and maybe Tim Cook is the man to make those things happen.

Now that I’ve gotten that out, I’d love to hear your thoughts. Are you selling your Apple stock or already drooling over whatever you think the mad scientists are going to produce next? Leave me some comment love and let me know!

The photo of Steve Jobs was originally taken by Flickr user acaben, and is used under the terms of the Creative Commons license.