Ziray Studio Labs

I’ve seen a lot of poorly written and ugly looking code in my time. That’s not even considering the undocumented and uncommented code. We all know we should comment our code but how many of us do it consistently? I admit, when I’m in a coding frenzy, stopping to write comments just gets in the way of my thought process and can be distracting. I will however write a bunch of comments before I write the code, of the operations I think I need, in order to give me an outline of where I need to get to. For example:

I may not know all the APIs to load and play the video just yet, but at least I’ve given myself an outline and as I fill in the code below each comment, I can see exactly what I’m doing and where I need to go.

Why Your Code Sucks

The point of this article is not to talk about comments, but how to avoid writing them in the first place within your functions and still be clear for everyone else, for the most part. This is your code:

Not even a comment could concisely convey the meaning of that hideous statement. Instead, why not:

Well written code is self documenting. Let me restate that: if you can write code so that someone can jump to any point of that code and understand what’s going on at that point, read it like a sentence, and not have to decipher minute details like what each variable means, then you don’t have to comment most of your code.

There’s no reason you need to shorten the names in your code. Most programmers have never had file size limitations to deal with, so there’s no reason for it. Stop pretending you live in the 1960s and embrace nearly infinite file storage. To save keystrokes perhaps? Please, use a real IDE with code completion and stop doing stupid things like:

Function Names

Also, because your functions are essentially actions, they need to reflect that in the name, so put a verb in the beginning of your function such as: getData(), setStatus(), enableWiFi(), hideControls(), handleGraphicException(), launchBall(), etc.

Class Variables

Get rid of the underscores in front of your class variables. For example: _dg; _myNumber;. All class variables should be private anyway, so why do you need that ridiculous convention? It’s a hold over from C where there was no “private” keyword, so you’re using it and you have no idea why.

Also, what’s with the “my” naming convention? You sound stupid when you have those: myInstanceName, myMovieClip, myGraphicsContext. Of course it’s yours, whose would it be, if not yours? If you’re programming with a colleague, do you refer to his variable references as yourInstanceName? Or hisVideoFileURL? Of course not. Don’t be that stupid; you’re reading too many stupid online tutorials by uncreative people who only code because they have nothing else better to do while living in their parent’s basement.

In the very least, be consistent with your naming conventions.

Hungarian vs. Polish notation

Depending on which language you’re coding in,  you may need to use a notation to help you with type casting. Let me rephrase that: if you’re using a loosely typed language, use Hungarian notation. You should probably use this with strongly typed languages anyway because with abstract types, you never know what you could get into and it’s just generally less confusing.

Hungarian Notation: vendorNameTextField or vendorName_txt

Polish Notation: txtVendorName or textFieldVendorName

Why not Polish notation? Not only is it ugly, but why would I sort on variable type instead of the variable name like I can do in Hungarian notation? The notation names come from how the speakers of those languages modify their verbs and nouns. To say: “My ball” in Hungarian is:  ”labám” where “labda” is the root word and the ‘m’ singifies a first person possessive. Hence the ending of the word shows the crucial information. It’s the opposite in Polish notation where the beginning of the word is modified. In the interest of full disclosure, I love the Polish, but I am Hungarian, but I promise that’s not why I prefer one over the other.

Final Thoughts

In the end, be consistent, be clear and spell out your variable and function names.

As with any product or service, the question of pricing is always one of the many challenges of selling a product or service. Many price their products or services low in an attempt to under cut their competition or initially sell a lot and get their name out there. Others charge way more than a person is willing to pay for such a product.

With iPhone development, more often than not, you’re selling a product as opposed to a service, which may be a compliment to your physical or web based service. If your iPhone app is a complimentary product to a service that you already offer and charge for, your iPhone app should probably be free (depending on complexity). Look at it as a value-added feature to put you above your competition and make using your service more convenient and enjoyable. By creating more ways to access your service, you provide more opportunity for your customers to use it more often and really benefit from what you’re trying to offer them.

So what’s the sweet spot for a price for your iPhone app? It obviously depends, but there are some guidelines we came up with.

Be Unique with Your iPhone App

The more unique your application is, the more you can sell it for. By being unique, you have less competition and thus a higher demand.

Complexity of Your iPhone App

If your application can be easily reproduced by a 16 year old kid on a weekend, you either shouldn’t charge for your application, or if you do, don’t charge more than a dollar because that 16 year old kid won’t.

Proprietary

If your application uses proprietary information, software, APIs or other technologies that aren’t easily implemented or obtained, you can charge more for your application. This relates to complexity, but be aware that people will often create equivalent systems if it’s popular enough so proprietary systems and information require a lot of maintenance to keep them relevant.

Usefulness of Your Application

How often will someone use your app? Is it just a novelty or something someone will only use for a certain chore that they rarely do? If so, the demand for the app diminishes and so should your price.

No application should be more than $10 with few exceptions. Remember that you’re developing for a mobile platform and the software is limited and your price should be limited too.

If it’s a game, how is the quality and length of game play? The quality, the game play and the fun factor all play a part in your price. Obviously, people much prefer spending money on entertainment than on a new fancy laundry list application. Games are usually unique (to the App Store at least), are complex and provide a greater satisfaction to buyers, which allows them to enjoy a higher price tag.

Perspective

Having a higher price on the App Store shows more confidence in your application. Giving your app away usually means you don’t think people would be even willing to spend the price of a soda on your application. These applications are fine, but for some of us, we need to make a living.

Making your app a dollar usually means, I want to make some money, but I don’t think people will pay any more for it. But charging a dollar can also be good if your app has a wide appeal. What you lack in big numbers, you make up with bulk sales. So, if it’s a game, you could potentially have a larger market as opposed to a utility application that the user spends 30 seconds on. So you really need to look hard at your application and keep several factors in mind before you price your app. You can always change it later, so one approach is to start low and see how sales go.

This is not so much how to make applications for the iPhone, since there are so many on of those on the web already. This is more a syllabus on how to get started with the vast amount of information already out there and where to start from to quickly become proficient at iPhone development without getting frustrated or discouraged.

Development Requirements

An Intel-based Apple Mac
$99 (optional – if you want to actually publish your app)
That’s all!

Apple Developer Account

Development for the iPhone is initially free. So feel free to head over to http://developer.apple.com and sign up for a developer account if you don’t already have one. This will give you access to the Integrated Development Environment (IDE) called XCode, which is required to develop applications for the iPhone and iPod Touch. It also serves as a treasure chest of free information, sample code, tutorials, how-to videos and news, all of which I’ll talk about how to use later.

Once you’ve signed up for a developer account, you’ll need to download XCode and install it on your Mac. PC users are, as they always are, out of luck since a Mac is required for development. Once that’s done, put it aside as you won’t need it for a bit.

Learn to Program

An Important Design Pattern: Model View Controller

If you already know how to program a little bit, but haven’t gone through the rigors of a four year university Computer Science degree or something similar, start with learning an important design patterns, namely one called Model View Controller (MVC). Of course, a 4-year degree is not necessary, but you need to understand basic software engineering principles, design patterns and basic usability practices, which practically none of the programming tutorials, books and online articles teach. Also, a lot of practice helps as you’ll learn how to fix non-obvious compiler and runtime errors, how to structure your code, and pitfalls of each language you use.

Objective-C: The Language of Choice

After you understand the basic principle of MVC, you can then move on to learning the language of choice, Objective-C. Why Objective-C? Why didn’t Apple just choose a common language like C++ or Java? The reasons will become obvious as you learn about the language, it’s power, and how it fits into the MVC methodology better than any other language you’ve likely seen before. So here’s a nice tutorial on how to program in Objective-C.

If you already have a great understanding of programming and know a C-based langauge, skip the lengthy tutorial and take a look at this primer to get a sense of the additions to C that Objective-C brings to the table. For most people who are familiar with a C-based language, this will be all you need to get started.

Continue reading

The saying, “If it ain’t broke, don’t fix it,” is not a very good motto, especially when there’s progress to be made. When you’re working with old and tired technology it really drags down your capabilities and your ability to move forward. The need to keep around legacy solutions only holds back your clients from realizing your full potential as a company.

Their Failure is My Failure

Being the Technical Director at my company means that I get to pull out all the stops when it comes to investing in our technical capability as a company. But it also means that I am responsible for those technological failures as well.

Coming from the world of Human Computer Interaction (HCI), the user is never wrong or stupid, but instead it is your design that is wrong or inadequate and the sooner you realize that, the sooner you can move on to building better, more functional and friendly software.

The same goes for my developers. They are forced to use the solutions I provide for them and if they have problems with it, break it, or can’t get it to work, that’s my failure to design a well-working platform for them to develop on. Sure, I can always fix the problem for them in a few minutes and show them where they were misled because I understand how all the pieces fit, but I’m the one that made it, so of course I understand it. I could dismiss their problems as them not knowing how the code works or that certain things need to be placed in particular spots for things to work properly, but that’s not their job. Their job is to develop really great pieces of work and it’s only a difference of mentality on how they should do their jobs better and easier.

On the one hand, I could produce documents and try to explain how everything works and occasionally field questions on how certain things work. The alternative is to pay attention to the problems they’re running into and resolve it in a way that’s best for them. This may require a higher initial investment, but it’s an investment that’ll yield higher returns in the long run, not to mention happier developers.

It’s Not Them, Stupid, It’s You

We’re quick to fault others for something that we ourselves may understand quite well, but with the wealth of diversity in this world, no one can know exactly the same things you do. I work with really talented people and I can’t blame them for not knowing things I think are common sense because I know they know things that I couldn’t even begin to grasp. So instead of trying to be superior to people or trying to absolve yourself from blame, take the stance that the end-user is always right, be it your co-workers, your clients or your customers. Remember, you’re not trying to compete with them, you’re trying to work with them.

Don’t Fix It, Improve It

Take something in your line of work that is tired and old and revamp it. If your software is coded in ActionScript 2, upgrade it to 3. If your website is made with just straight up HTML, refactor it to include CSS and some JavaScript. If your invoices are still written in the Courier font, hire a designer to make them less intimidating (unless that’s the point, in which case your business model is flawed if you’re constantly trying to convince your customers to pay up). I know it might not seem broken and may seem to work fine, but by improving on what you already have, it allows you to evolve and be a leader rather than having tired old things hanging around and weighing you down.