Immediately after the conversation, I came to the realization that I, and many others like me (programmers, computer geeks, tech bloggers, etc.), have always thought about Apple in the wrong way: Apple as a computer company. I realized that Apple can control their operating system the way that it does because Apple doesn’t sell an operating system nor do they sell computers, they sell a product.

When you buy a GPS device for your car, do you get upset that you can’t install the operating system from that particular device onto a competitor’s device? Of course not. The operating system is specifically designed for that particular hardware and it would be ridiculous to think that it could (or should) be able to be easily ported to any other device. The hardware and the software are designed simultaneously in order to work together in as integrated a manner as possible. You are not buying the GPS operating system, you are buying a GPS device.

Apple wants (has wanted) to change the way we think about computers. This is the whole premise behind the “Think Different” campaign. Once this realization set in, a comment Steve Jobs made during an interview at D8 immediately made more sense:

We never saw ourselves in a platform war with Microsoft, and maybe that’s why we lost. We just wanted to make the best thing — we just thought about how can we build a better product.(Steve Jobs at D8)

We never think of Apple this way because our experience with computers comes from the likes of Microsoft and the various Linux variants. We’ve become accustomed to installing an operating system on any combination of assorted motherboards, processors, drives, etc. and then just installing the necessary drivers to make everything run as it should (in some cases this is a serious pain in the ass²). But this isn’t how Apple operates. They don’t sell you computer parts. That’s why they make it so hard to do hardware upgrades or to access the battery, because you’re not supposed to.

For consumers to think of Apple products as appliances, not as computers, is what I believe Apple wants. It explains many of the decisions that they have made regarding the iPhone, iPad and iOS. When you look at things from this perspective, it all makes perfect sense.

Those of us who don’t understand why people “drink the Apple ‘Kool-Aid’” don’t get it. And the reason we don’t get it is because we look at it the wrong way. Apple isn’t about tech specs, customization, or feature lists because the only people that care about that are geeks like me. All people want is a way to check their email, browse the web (i.e., FaceBook, Twitter, etc.) and not worry about what’s under the hood.

This, I think, is why so many iPhone vs. Android flame wars erupt on tech blogs. It’s like comparing a luxury car to a Formula-1 race car. One is all about speed and performance, the other one just wants you to get to where you want in as comfortable a way as possible. It’s ridiculous to compare the two and people who try don’t “get it”. They’re not even in the same category. Apple doesn’t want to be in the same category. That was never their intention.

As for me, I think I finally “get it”².

2. One might expect an iOS developer to understand why people would choose Apple products, and I thought I did. But I found that despite the fact that I enjoyed my various Apple purchases, I could never explain or justify them to others. I think that now I can.

You can read about the rationale for creating the app, etc., if you’d like, via my guest post at JapanGaku. It’s not too long, but for the sake of the topic at hand, here’s a summary:

Learning the Kana (Hiragana & Katakana) is one of the first steps in learning the language. And, since Romaji isn’t used in Tae Kim’s guide, it seemed like a great place to start. … I looked at some of what appeared to be the more popular Kana/Kanji apps and tried to include in my own app what users felt was lacking in others (based on the reviews they were leaving). Ultimately, I decided not to include everything I initially wanted to before releasing the app. … [Doing so would have been] a significant effort, and as already mentioned, it makes little sense to invest in something that won’t be used (I’m reminded of the YAGNI programming mantra: You Ain’t Gonna Need It). (Source)

So, I had a pretty good idea of what I wanted to do before I started doing anything. In addition to researching related applications, I did some reading regarding the user interface design of an iOS app, and I looked at examples of some well-designed apps before deciding where to start. With some ideas in mind, I started throwing together some mockups together in Adobe Photoshop.

Initial design concepts for the Japanese Alphabet Study Guide iOS app in Photoshop

If you already know what the app looks like, it is evident that, graphically, a lot has changed (to me, anyway) since the initial design concept, but structurally, the app did not change significantly.

After deciding what I, basically, wanted the app to look like. I started putting together some prototypes, both in code and on paper, and began writing down ideas regarding application flow and functionality.

Japanese Alphabet Study Guide Prototyping

Typically, I might start with prototyping before I even think about how the design should look and feel, but since I already had in mind how the app was going to work, I did things a bit backwards this time around.

I learned a lot while creating my first application (I spent a lot of time on Stack Overflow), so I made sure to repeat those things that were beneficial/helpful the first time around. User testing, for example. I never realized how great a resource my Japanese meetup group was for testing until I started writing software. I would install beta versions of my apps on my phone to bring for testing and observe how various people interacted with the apps. It became immediately obvious that the way I thought the apps should work was different from the way other people expected them to work. What’s more, these people were/are actually my target demographic – perfect!

Additionally, organizing things/”to-do”s that needed to be completed and adding tasks and ideas as they popped up was simplified thanks to the Things application. Things is probably one of my favorite apps, especially for getting things done. I can’t describe how valuable it has been to be able to add items/tasks to my to-do lists as they would come into my head (while trying to sleep, watching TV, reading articles, etc.). If you already have a to-do list manager, great! Use what works for you, but if you’re looking for one that’s simple, powerful, and elegant. Give Things a try.

Finally, keep in mind that you’re not really done with your application once it’s available for sale. If you’re fortunate enough, you’ll get some users that will leave meaningful reviews and provide insight into how you can improve your app (i.e. “If this app had feature X, it would perfect”, etc.). If users start complaining about crashes, be sure to check the crash logs provided in iTunes Connect.

Well, I guess that about wraps it up. I feel like I’ve kind of rambled my way through this, but hopefully what I’ve shared here can be useful to someone starting out in iOS (or software in general) development. In bullet points:

• Plan & Research
• Prototype & Design
• User Testing
• Review

I’ve also moved away from Flash development and into the “mobile sphere”. I’m still willing to do Flash where necessary, but I just don’t think that it makes sense for most websites. We’ve come a long way since the “All Flash” website “glory days”… I think that it’s fairly evident that mobile devices are the future. I’ve completed two iPhone apps (Learning Japanese and Japanese Alphabet Study Guide) and will probably start doing some Android development next year. I may even start posting more often… See you around.

Before I begin I should probably mention that this will take quite a bit of time, potentially up to an hour or more; so make sure you set aside enough time to do this. Also, I’d like to point out that Media Temple has an excellent tutorial and the official documentation may be found on the Symfony website.

A lot of this information can be found elsewhere on the internet, but I haven’t really seen a complete/concise walkthrough on setting up and configuring Symfony to work with MediaTemple‘s Grid Server, so I’m writing my own. The following instructions are written from the perspective of a Windows PC user, but – for the most part – everything should be pretty much the same on OSX or Linux. Keep in mind that you should only do this if you know what you’re doing. You could potentially mess up your web server if you’re not careful; also keep in mind that these instructions may not apply to all server configurations. Don’t blame me if you end up screwing up your server.

First and Foremost

PHP 5

Before you can even get started you have to make sure that your server is configured properly. Make sure that the Primary PHP Version is set to PHP 5. You can do this by selecting your target domain from the domains tab, then click on PHP Settings and select PHP 5 and press save at the bottom.

SSH Access

The next thing you need to make sure to do is enabled SSH access to your MediaTemple account. Still on the control panel page press the Server Administrator button/cell and make sure that under the SSH Option section that you select enabled. Save your settings.

Server Number: You’ll need to know your MediaTemple server number. In order to find out what your server number is, go the the Account Center control panel and click on the Server Guide button/cell. On the next page click the “System Paths” link in the third column. You should see a page that lists all of your server paths, environment variables, etc. You should see a line titled System path with a value of something like: “home/####/domains/yoursite.com” write down the number that comes after “home/” and before “/domains”; that’s your server number, it could be four or five digits (maybe more).

SSH Client

Now that you SSH access you’ll need a client to utilize its power. Mac users should have already have a client pre-installed on their OS (Applications>Utilities>Terminal). Unix/linux users should already know how to do this. For Windows users, I recommend using Putty; but if you have a preferred client feel free to use it. You can download the Putty client at http://www.putty.nl/download.html. Select the version that applies to your version of Windows (select the putty.exe file, not one of the other options). Whenever the Putty client finishes downloading, put the .exe file into your Windows folder (most likely C:\Windows); create a shortcut (right-click > “create shortcut”) and drag the shortcut to your desktop, start menu, wherever you want it.

Connecting to the Server

Connecting

Launch Putty (or your SSH client) from your shortcut, put your website hostname (www.example.com) or IP address into the hostname field – make sure the SSH option is selected and that the port number is correct – then click “open” on the bottom. If you haven’t connected to your server with the SSH client before you’ll get a “The server’s host key is not cached in the registry” alert. Click “Yes” to continue.

Logging In

Put in your username (it should be serveradmin@yoursite.com), press enter, then type in your password and press enter. If after logging in the client immediately closes or you get a “Connection closed by remote host” alert, it’s because you didn’t set your “SSH option” to enabled in the MediaTemple Account Center or you forgot to save your settings after you did so. If this happens to you, change your settings and try logging in again. After logging in successfully you should see a prompt with something like (except the *asterisks* will be an alphanumeric combination):

yoursite.com@****:~$

Installing Custom Pear Packages

Fortunately Pear comes as a global pre-install with MediaTemple’s Grid Servers, so that saves us a step (kind of); but because we’re adding a custom package/module we need to manually create an install copy in the server’s home directory.

Pear Install

Before we install/copy Pear we need to create a configuration file. Make sure that you’re still logged in with your SSH client (log in again if you’re not) and generate a configuration file for your home directory by typing in the following:

/usr/local/pear/bin/pear config-create $PWD .pearrc

Double check your spelling. If you did everything correctly you should see a list of files scroll past and the last line of text should read “Successfully created default configuration file”, etc. Now you’ll need to run the install:

/usr/local/pear/bin/pear install -o PEAR

Be sure to double check everything and make sure you don’t misspell anything. If you typed in everything correctly you’ll see a series of lines scroll past with things like “Downloading Console_Getopt”, “Downloading Structures_Graph”, etc. and then a few lines that say “install ok: channel://pear.php.net” and so on.

Bash Profile

So that you don’t have to type the full path to Pear in every time we’ll create a .bash_profile in order to make things more efficient. Check to see if a .bash_profile file already exists (chances are it doesn’t) by typing in the following:

ls -a

If you have a .bash_profile file in there already, fine, if you don’t also fine. You can do this next part one of two ways; you can use the Vi editor, or you can “concatenate” or “echo” the text directly into the file. If .bash_profile already exists you should use the Vi editor to make sure you’re not adding something that’s already there.

Vi Editor Method

Launch the Vi editor within your SSH client by typing in:

vi .bash_profile

This should “clear” the screen except for a line at the bottom that says something like:

".bash_profile" [New File]

The Vi editor defaults to “Command Mode”, be sure to press “i” on your keyboard to switch to “INSERT” mode. You’ll be able to tell because the bottom line changes to “– INSERT –”. Now type:

export PATH=$PATH:/home/####/users/.home/pear/

Be sure to replace the #### symbols with the server number you wrote down earlier. Double check your spelling and press the Escape (ESC) key on your keyboard, this will put you back in “Command Mode”. Hold down the Shift key (SHIFT) on your keyboard and press “ZZ” (make sure you press “Z” twice); again: “SHIFT+ZZ”. If you did everything correctly it should take you back to the shell prompt.

Go ahead and make sure that the file is there by displaying a directory listing:

ls -a

It should look just like it did earlier except now there’s a “.bash_profile” file in there.

Concatenation Method

If the .bash_profile file doesn’t exist in the current directory, at the SSH prompt type in:

touch .bash_profile

Press Enter. This will create a .bash_profile file for you. Next type in the following:

echo export 'PATH=$PATH:/home/####/users/.home/pear/' >> ~/.bash_profile

You can make sure that everything worked by typing in:

cat ~/.bash_profile

If you did everything properly it should basically just echo back the contents of the file.

Verifying the Profile

Now you can install Pear packages without having to type in the full path. Let’s run a test by installing/updating the mail package:

pear install -o Mail

It should scroll a few lines saying “Downloading”, etc. and end with “install ok: channel://pear.php.net” and so on, just like when we copied/installed Pear to the home directory.

Editing the PHP.INI File

If you’re not logged into the MediaTemple Account Center anymore, be sure to log back in for this next segment. From the Account Center control panel click on the “File Manager” button/cell. On that page, click into the “etc” folder. Once inside the “etc” folder you should see a file titled “php.ini.sample”, click it to open it and edit it. By the way, I would recommend that you copy everything that’s in that text box and make a backup somewhere on your computer, just in case you accidentally mess something up and have to go back to the default settings.

Scroll down to the very bottom and add the following line:

include_path = ".:/home/####/users/.home/pear/php"

Be sure to change the #### to your server number. If you want, feel free to add a comment (start the line with a semi-colon “;”) that says something like “pear include path”. Finally, change “php.ini.sample” to php.ini”. If you don’t do this, your settings won’t take effect. Click “save changes” to save the file.
Some users may prefer to change the include path on a directory-by-directory basis via an .htaccess file or on a script-by-script (.php file) basis but I wouldn’t recommend it unless you know what you’re doing. If you made the changes to your php.ini file as instructed above go ahead and skip to the next section, otherwise – if you’re wanting to go about it a different way – read the next few of paragraphs.
If you want to do it via .htaccess files (keep in mind this only affects .php files within that directory) add the following line to the .htaccess file in your target directory (remember to change the #### values to your server number):

php_value include_path /home/####/users/.home/pear/php'

If you’re wanting to change your include directive on a script-by-script basis, add the following somewhere near the top (probably before any ‘include’ commands):

set_include_path('/home/####/users/.home/pear/php');

Be sure – this is getting redundant, I know – to change the #### values to your server number.

Preparing to Install Symfony

Okay, we’re about half way done (I told you this would take a while). By the time you’ve gone through all of this your SSH client has probably timed out and aborted the connection, if this is case go ahead and log back in. If your client has not timed out type in “clear” and press enter to clear the screen (if you had to log back in, go ahead and do this as well).

You’ll have to make sure that the command-prompt is running as PHP5, to do this you’ll have to update your .bash_profile file again. There are two methods to doing this, as mentioned before. In this instance, I’m going to use the concatenation method:

echo export 'PATH=/usr/local/php5/bin:$PATH:/home/####/users/.home/pear'  >> ~/.bash_profile

WARNING: Make sure not to insert a carriage return or line break when entering the above two lines. The code above is merely wrapping.

Type that into your SSH client and make sure to replace the #### with your server number. Double check that everything is typed correctly, it’s a pretty lengthy line.

If you’re wanting to use Vi to input that, it’s the same except you don’t need to type “echo” or the “>> ~/.bash_profile”, nor do you need to put single quotes around the path.
To make sure that everything worked correctly type:

cat ~/.bash_profile

If you typed everything in correctly, it should echo the contents of .bash_profile out to you. The last line is the part that you just added.

Before we move on, you’ll need to refresh the shell environment variables, type:

source ~/.bash_profile

Installing Symfony

Discovery

Before installing Symfony you have to “discover” it through pear, type in:

pear channel-discover pear.symfony-project.com

After a slight pause, you should see a couple of lines that say: “Adding Channel pear.symfony-project.com succeeded” and “Discovery of channel pear.symfony-project.com succeeded”. Now with the next part you can either choose to install the latest stable release of Symfony or the “nightly builds” (beta releases); I recommend using the stable release.

For the stable release (recommended), type:

pear install symfony/symfony

For the “nightly build”:

pear install symfony/symfony-beta

You should see some text that says “starting to download symfony” then a progressing load, and finally, “install ok: channel://pear.symfony-project.com”.

This next part can be a little tricky so follow along closely.

Initializing a Symfony Project

After completing the previous section, Symfony is officially installed on your server; but, before you can use it you have to initialize a project and an application. The following steps will walk you through setting up a “symfony” subdomain which you can use to play with your Symfony installation. If you don’t want to create a subdomain you don’t have to.

To create a subdomain type:

mkdir ~/domains/symfony.yoursite.com

Obviously change “yoursite.com” to whatever your site may be (“example.com”, “mysite.net”, etc.). Next create a “symfony” directory:

mkdir ~/domains/symfony.yoursite.com/symfony

If you didn’t create a subdomain replace “symfony.yoursite.com” with simply “yoursite.com”. Now within the “symfony” directory create a directory called “web”:

mkdir ~/domains/symfony.yoursite.com/symfony/web

The reason we created these two directories is so that we can establish a symbolic link “SymLink” from the newly created “web” folder to the root “html” folder. Type in the following (be absolutely sure to type this in correctly):

cd ~/domains/symfony.yoursite.com/
ln -s symfony/web html

Again, if you didn’t create a subdomain instead of “symfony.yoursite.com” it will be just “yoursite.com”. The reason this is necessary is because Symfony’s default folder structure is different from MediaTemple’s structure, so we have to create a “SymLink” that will basically redirect the framework to the required files.

You may have noticed that after typing “cd ~/domains/symfony.domain.com/” that the prompt changed; that’s because you’ve moved into another directory, which is what is supposed to happen. Now that that’s done we need to actually “initialize” our Symfony project. Make sure that the prompt displays (note the word “symfony” at the end):

yoursite.com@****:~/domains/symfony.yoursite.com/symfony$

If it doesn’t type (if you didn’t create a subdomain – “yoursite.com” instead of “symfony.yoursite.com”):

cd ~/domains/symfony.yoursite.com/symfony

Now, at the SSH shell type:

symfony init-project myproject

Feel free to change “myproject” to whatever you want (e.g., “test”, “demo”, “default”, etc.). You should see a series of lines scroll by, if you typed everything correctly. Now type in the following:

symfony init-app myapp

Again, feel free to change “myapp” to whatever you wish, just make sure to be consistent.

If you’ve created a subdomain you have to make sure to add an .htaccess file in your “symfony/web” directory that adds a php5 script handler. To do this just type:

echo 'Options +FollowSymLinks +ExecCGI' >> ~/domains/symfony.yoursite.com/symfony/web/.htaccess
echo 'AddHandler php5-script .php' >> ~/domains/symfony.yoursite.com/symfony/web/.htaccess

WARNING: Make sure not to insert a carriage return or line break when entering the above two lines. The code above is merely wrapping.

Be sure to type this accurately (note the spaces and periods carefully) otherwise you’ll get a “500 Internal Server Error”. Again, if you prefer to use Vi to add those two lines to the end, it’s up to you.
Now go and test your work: symfony.yoursite.com (or just yoursite.com if you didn’t create the subdomain).

Where Are the Media Files?

If for some reason you’re not seeing the stylesheet, images, etc. It’s because the “sf” files didn’t get copied over, I’m not sure why this happens, but there’s an easy fix. In your SSH shell type:

cp -r ~/pear/data/symfony/web/sf ~/domains/symfony.yoursite.com/symfony/web/sf

WARNING: Make sure not to insert a carriage return or line break when entering the above two lines. The code above is merely wrapping.

Be sure to type all of that in carefully. Also if you didn’t create a subdomain change “symfony.yoursite.com” to simply “yoursite.com”.

Now go and test your work: symfony.yoursite.com (or just yoursite.com if you didn’t create the subdomain). Everything should be up and running smoothly. Congratulations, you’re finished.

c = c + 1;

or

c++;