On Seven Inches

Tim Bray has a year-end blog post up that's worth a read. In case you don't know, Tim Bray is Google's Android Evangelist. As you might expect from someone who would take that job, he's as enthusiastic about the Android platform as I am about iOS. Although his perspective colors his view (as does mine), his analysis is usually pretty good.

He's got one assertion in this most recent post, however, that doesn't seem to ring true to my ear.

Apple will totally do a 7" device. Anyone who’s spent quality time reading books or playing games on the Galaxy Tab knows; there’s a great big hole in the ecosystem that needs something bigger than a handset but that still fits in one hand and you can use for four hours in a row sitting up. This argument is over.

John Gruber seems similarly skeptical, opining yesterday that:

The problem is that it’s nice, for certain tasks, to be able to hold a tablet in one hand, but you can’t do that with the current iPad. I think Bray’s mistake is assuming that using a 7-inch display is the only way to solve that problem.

The argument is far from over, and it's silly to even make the assertion. I have, within arm's reach, the very 7" tablet Tim refers to - a Samsung Galaxy Tab. I have spent quality time with the Tab, and think I definitely count as part of the set known as "anyone", yet I don't see this glaring hole that Tim thinks is so obvious. Personally, I found the Tab awkward for text reading, though part of that is due to Android's abysmal text rendering engine. The only way the Tab is better than the iPad for reading is that it's lighter and more portable. As for games, I'll admit that the Tab's form factor is pretty much ideal for driving games. All other types of games I've tried, it's either no better or worse than the iPad and, of course, there's no comparison in the selection of available games yet.

The Tab is a 16:9 tablet running Android 2.2. For watching 16:9 video content like movies and HD television shows, the end result is that you get roughly the same size image video as you do on the iPad in a package that's lighter and easier to hold, which sounds like a winner, right? There are downsides, however. The smaller form factor means less room for batteries and thus shorter battery life. The energy requirements for a 7" tablet are not considerably less than those of a 10" device, but there's a lot less room for batteries. As a result, while battery life is almost never an issue on my iPad, it's often one on the Tab. If you've seen the inside of an iPad, you know that most of the heft of the iPad comes from batteries. Apple made the design decision that they'd rather have a slightly heavier device that could run all day long on a single charge with normal usage. Based on sales and reviews, I think it's safe to say that was a good decision.

Batteries are getting more efficient every year, as are processors, so at some point, a 7" device with iPad-like battery life is completely feasible, however when that happens, a 10" device will have even better battery life. But battery life is far from the only downside to this form factor.

With the exception of video, some types of games (e.g. car driving games), and likely a handful of other tasks, the smaller form factor is simply not as good as the iPad for most things you'd want to do. It sits in an uncomfortable middle ground between phone-size devices and 10" tablets like the iPad and the… well, like the iPad. The Tab does nothing considerably better than either an iPhone or an iPad. It's "as good" at a handful of tasks.

What it boils down to is that the main advantage of the 7" form factor is that it's easier to carry around with you and is lighter to hold. I'm just unconvinced that's enough of a reason to make a 7" iPad inevitable.

Personally, If I were going to buy something to fit between my iPhone 4 and my iPad, I'd buy a Kindle, and recent sales numbers seem to indicate that many people are making that choice. The Kindle does less than the Tab, but it's even lighter and it does do something better than the iPad, iPhone, and Tab: it's a better ebook reader. It gets great battery life, it's easy on your eyes, has nice text, it's easy to carry, can be held comfortably in one hand, and it's much, much cheaper.

When Apple introduced the iPad, it looked like it was going to compete, and probably kill, the burgeoning ebook reader market. Instead, it pushed those special-purpose devices into a lower price bracket where they no longer compete directly with the iPad. Looking at how the sales numbers have jumped recently, the iPad may just be the best thing that ever happened to the Kindle. The Kindle and Nook are almost down into the "impulse buy" category, and as a result, they're selling like hotcakes, often to people who already own iPads.

But where does a seven inch tablet fit into the market? What would compel someone who owns an iPad to buy one, or would compel someone to buy one instead of an iPad? There isn't really a huge unmet demand for this product to fill. There's no pressing, burning need that would cause people to buy yet another device. A seven inch tablet has to compete with products that are already on the market and that are well-established. It can't compete with the Kindle on price, size, weight, or as an ebook reader. It's not noticeably cheaper than the iPad, yet has shorter batter life. It doesn't do anything that the iPad or iPhone can't. It's only compelling advantages are that it's lighter and smaller. Well, for a small segment of the market, it has another advantage: it's not from Apple.

The Galaxy Tab has been selling pretty well, but it's got novelty working for it, and it's really the only viable non-Apple tablet on the market right now. That will not be the case for long, however. The way the iPad has sold, you can expect every computer hardware manufacturer to try to claim a piece of the tablet market. Microsoft has already announced that, for them, CES would be about "slates" yet again this year (oh, boy!).

For seven inch tablets to gain traction in the long run, they will have to provide a compelling advantage over the iPad, the iPhone, and the Kindle. If they're not going to compete on price, maybe there's some feature or ability where seven inch tablets can distinguish themselves and establish a long-term foothold, but I haven't thought of it yet, and apparently neither have the current tablet manufacturers like Samsung.

The only way Apple will release a 7" tablet is if they think of some compelling reason for such a product to exist. It's possible that the reason would be price - making a more affordable and smaller iPad available to people who can't afford a $500+ device but want something bigger than an iPod touch. That's not impossible given Apple's drive for competitive pricing in their consumer products the last few years, but it's far from a foregone conclusion.

Read more »

Posted in: Android,Apple,Rant

More Animation Curves than You Can Shake a Stick at

Core Animation is awesome. It makes doing a lot of complex, fancy animations downright easy. One of the really nice built-in features of Core Animation is the ability to use animation curves. These curves let you specify whether the animation happens linearly (at the same pace throughout the animation), or whether the animation eases in, eases out, or does both.

When you have to go closer to the metal and use OpenGL ES, you're not so lucky. We don't have animation curves provided for us in OpenGL ES. We have to interpolate ourselves. Fortunately, the math behind animation curves is straightforward. Plus, there are far more curves than just the four Apple offers.

I haven't run across a good library for generating animation curves, so I've decided to release my animation curve functions as public domain (no attribute required, no rights reserved). Here is a graph of all the different animation curves I'm releasing:


Here is the original Numbers.app document that generated the graph, and here is the Xcode project that generated the data. The project also contains all the functions needed to plot these curves.

Apple doesn't document which calculations they use for easing, but my guess is that they're quadratic. I'm not sure, though, since many of the curves yield similar results.

All of the interpolation functions included in the Xcode project above take three inputs and return a GLfloat containing the interpolated value. The first parameter, t, is the percent of the way through the animation you want a value calculated for. This is a clamped float that should be in the range 0.0 to 1.0. Values above 1.0 will be treated as 1.0 and values below 0.0 are treated as 0.0. The second parameter, start, is the value when the animation starts. The third parameter, end, is the final value to be animated toward.

If you want to apply a curve to a CGPoint or Vector3D, you have to call the function multiple times for each component (x/y or x/y/z).

Have fun!

Here are the functions included in the project above:

#include <OpenGLES/ES2/gl.h>
#include <OpenGLES/ES2/glext.h>
#include <math.h>

#define BoundsCheck(t, start, end) \
if (t <= 0.f) return start;        \
else if (t >= 1.f) return end;

GLfloat LinearInterpolation(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return t * end + (1.f - t) * start;
}
#pragma mark -
#pragma mark Quadratic
GLfloat QuadraticEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return   -end * t * (t - 2.f) -1.f;
}
GLfloat QuadraticEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t + start - 1.f;
}
GLfloat QuadraticEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) return end/2.f * t * t + start - 1.f;
    t--;
    return -end/2.f * (t*(t-2) - 1) + start - 1.f;
}
#pragma mark -
#pragma mark Cubic
GLfloat CubicEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return end*(t * t * t + 1.f) + start - 1.f;
}
GLfloat CubicEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t * t+ start - 1.f;
}
GLfloat CubicEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.;
    if (t < 1.) return end/2 * t * t * t + start - 1.f;
    t -= 2;
    return end/2*(t * t * t + 2) + start - 1.f;
}
#pragma mark -
#pragma mark Quintic
GLfloat QuarticEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return -end * (t * t * t * t - 1) + start - 1.f;
}
GLfloat QuarticEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t * t * t + start;
}
GLfloat QuarticEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return end/2.f * t * t * t * t + start - 1.f;
    t -= 2.f;
    return -end/2.f * (t * t * t * t - 2.f) + start - 1.f;
}
#pragma mark -
#pragma mark Quintic
GLfloat QuinticEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return end * (t * t * t * t * t + 1) + start - 1.f;
}
GLfloat QuinticEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * t * t * t * t * t + start - 1.f;
}
GLfloat QuinticEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return end/2 * t * t * t * t * t + start - 1.f;
    t -= 2;
    return end/2 * ( t * t * t * t * t + 2) + start - 1.f;
}
#pragma mark -
#pragma mark Sinusoidal
GLfloat SinusoidalEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * sinf(t * (M_PI/2)) + start - 1.f;
}
GLfloat SinusoidalEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return -end * cosf(t * (M_PI/2)) + end + start - 1.f;
}
GLfloat SinusoidalEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return -end/2.f * (cosf(M_PI*t) - 1.f) + start - 1.f;
}
#pragma mark -
#pragma mark Exponential
GLfloat ExponentialEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * (-powf(2.f, -10.f * t) + 1.f ) + start - 1.f;
}
GLfloat ExponentialEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return end * powf(2.f, 10.f * (t - 1.f) ) + start - 1.f;
}
GLfloat ExponentialEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return end/2.f * powf(2.f, 10.f * (t - 1.f) ) + start - 1.f;
    t--;
    return end/2.f * ( -powf(2.f, -10.f * t) + 2.f ) + start - 1.f;
}
#pragma mark -
#pragma mark Circular
GLfloat CircularEaseOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t--;
    return end * sqrtf(1.f - t * t) + start - 1.f;
}
GLfloat CircularEaseIn(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    return -end * (sqrtf(1.f - t * t) - 1.f) + start - 1.f;
}
GLfloat CircularEaseInOut(GLclampf t, GLfloat start, GLfloat end)
{
    BoundsCheck(t, start, end);
    t *= 2.f;
    if (t < 1.f) 
        return -end/2.f * (sqrtf(1.f - t * t) - 1.f) + start - 1.f;
    t -= 2.f;
    return end/2.f * (sqrtf(1.f - t * t) + 1.f) + start - 1.f;
}

Read more »

Posted in: Animation,Core Animation,OpenGL ES,Sample Code

The Little Grashopper Blog

Well, I'm not sure how I never ran across it before, but Philip Rideout, author of O'Reilly's iPhone 3D (a book I recommended last week), has a hell of a blog for people interested in OpenGL. A lot of the posts are specific to desktop OpenGL (and recent versions of OpenGL at that!), but there's tons of great information that applies to OpenGL ES as well. It's a veritable treasure trove of advanced graphics goodness from a guy who's been doing it for years.

Read more »

Posted in: OpenGL ES,Other blogs

More Math Resources

After posting about the free Linear Algebra book, I was told about another resource for learning math via Twitter. The Khan Academy is a not-for-profit website providing online video courses on a number of topics. They don't just cover math, but they do cover math extensively. They have well over 100 video lessons on linear algebra alone. Definitely a great resource I'm happy to pass along!

Read more »

Non-Deterministic Problems aka Finding Talent

As programmers, we usually deal with deterministic systems. To state it simplistically, deterministic systems are systems where the same inputs always results in the same output. Unless we intentionally introduce randomness¹ or have a relatively rare kind of bug in our code, the same inputs to our programs will always yield the same output. It could very well be the wrong result if our algorithm is bad, but it should be the same wrong result every time, which is a trait we rely on heavily.

In the real world, most things we encounter are non-deterministic. There are always factors we can't control or measure, and most systems have a human element. We are at the mercy of whim and emotion, and that's hard for a lot of programmers to deal with. Our fellow humans's decisions are decidedly non-deterministic and hard to predict, as are ours (though we usually don't notice this trait quite as much in ourselves).

You may have noticed that I haven't had much time to write lately. I've been exceedingly busy of late, even by my own standards. Although a lot of my time is being spent writing and debugging software, I've also been involved with some very non-deterministic problems as a result of my involvement with some large, complex development projects.

Probably the biggest non-programming problem that I've had to deal with lately, which most of my industry peers and nearly all of our clients are dealing with also, is finding good, experienced, reliable developers to staff projects. In short, there aren't enough experienced mobile software developers to go around. There simply aren't as many developers with multiple successful projects under their belt as there are companies who need the services of such people. I know of one large company that currently has ten open requisitions for mobile developers - five iOS and five Android - and no viable prospects at the moment. I helped one client recently bring aboard a good iOS developer, which took several months, and then I very quickly regretted it, because MartianCraft could really use that developer's services now.

Yet, on the other hand, whenever I blog about just how much work there is right now, I inevitably get several e-mails or comments from developers wanting to know how to find all this work. I make it sound like it's raining work, and they're not getting wet.

Given that, I thought it worth a few minutes to write about both sides of the equation: how to find developers, and how to find work as a developer. This isn't an exhaustive treatment, just a summary of recent observations.

For Developers: Finding Work

Unfortunately, I've got no silver bullet for aspiring developers. Overnight success is often indistinguishable from years of hard work. There are countless issues around getting that are not mobile development-specific that I'm not going to touch, such as a willingness to relocate ("go where the work is").

As with any industry, a large part of finding work is establishing a reputation and getting to know as many people in the industry as you can. Though it's expensive, you really need to go to WWDC, and probably a couple other conferences as well. About half, maybe even more, of MartianCraft work has come directly or indirectly as a result of one of us attending a conference. Conferences are where we meet our peers and where we develop and maintain our relationships with them. You should also attend CocoaHeads and/or NSCoder Night if you have one near you. This is where you can meet and get to know local iOS and Mac developers. On the Android side, there are similar meet-ups that you can attend.

When going to hire or subcontract a developer, most people I know will automatically prefer someone they've met, talked with, and maybe shared a drink with over a stranger, no matter how good the stranger's resume looks. Confidence in someone's ability to get a job done comes more rapidly from personal interaction. Resumes are sterile, but sitting down and working through a tough bug with somebody gives you a real feel for the other person's character and technical chops in a way you can never get from a resume.

At conferences, don't worry about going to every session. Everybody tries to at their first DubDub, but don't. Really. Pace yourself so you can socialize in the evenings. That may sound like bad, or even frivolous advice - as if I'm telling you to play hooky, but the information in the sessions can be found again. Most conferences videotape their sessions, and usually some of the attendees do joint note-taking using SubEthaEdit and make those notes available. But socializing with industry peers is vital if you want to do this full time, especially as an Indie. These are the people who can give you work (and accept work when you're too busy to take on new work yourself), and they are the people who can help you when you're stuck on a gnarly technical problem. These are the people who can give you a different perspective on something you've been staring at for far too long and are the people who can help you become a smarter, better developer.

Though not perfect, the iOS and Mac developer community is incredibly giving and helpful. It's not uncommon for direct competitors to help each other out and consider each other friends. Most of us realize that it's not a zero-sum game, and helping out others in our community usually comes back with interest. Scratch that. Not usually. Always.

Getting ongoing work requires more than being liked by other developers, however. You have to give people a reason to have confidence in your abilities. Creating or contributing to open source projects can show huge (if not immediate) returns. In the early days of iOS, before Core Data was available, my SQLitePersistentObjects project brought me nearly as much recognition as having my name on the cover of iPhone programming books.

Regular blogging is also a huge opportunity. Not only does it give people an idea of the depth of your knowledge, it gives you a chance to learn and improve. I don't think I've posted more than a couple technical blog posts where there wasn't either a correction or improvement sent to me by a reader, and often there were many. Just remember not to get defensive or depressed when it happens. You don't stop making mistakes until you stop living, but if you keep learning, you can avoid making the same mistake too many times. Readers who care enough to point out your mistakes are valuable beyond belief. Tame your ego and cherish them. Nobody's going to think less of you as a developer for occasional mistakes or less-than-perfect code.

But, no matter how much of the above you do, there is one absolute prerequisite to getting work on an ongoing basis: you have to have the technical chops. This is probably the hardest thing to figure out. I've met many great developers who lacked confidence in their abilities and I've met some who've had far too much confidence in them. It's really hard to gauge your own ability and it's almost always sobering to revisit older code you've written. No matter how good you get, there's always room to get better and if you're doing it right, you will. As developers, we're paid as much for our ability to quickly assimilate new knowledge as we are for the things we already know.

Don't worry too much about your whether you have a specific degree, or a college degree at all. You don't have to have a computer science or computer engineering degree to be a good programmer. There are many, many great programmers (including inside Apple) without those degrees and, in fact, without degrees at all. College is one way to get the information and some of the experience you need to be a good programmer, but it's not the only way, and it's possible (though probably not common) to get through school with a CS or CE degree and completely suck. Some of the worst iOS programmers I've encountered have both degrees and programming experience. Objective-C is a bit of a weird beast, and overconfidence is a big problem for experienced developers coming from C++, Java, and C# background. They look at Objective-C, see familiar aspects, and think they know what they're doing, sometimes completely oblivious to the differences between a static, strongly-typed language and a dynamic, weakly-typed one or the differences between a garbage-collected language and a reference-counted one.

In a perfect world, nobody would ever be able to offer their services as an iOS developer without perfectly understanding the rules around memory management. I'm not suggesting you should, but everything else, you could learn on the job, but you have to really grok the way retain counting and memory management work to be a professional iOS developer. You can really fuck up a code base trying to fix EXC_BAD_ACCESS bugs if you don't know what you're doing and can create an awful lot of work for somebody else in the process. You can also get away with an awful lot of leaks if you're developing on the simulator that will cause significant problems later. The stakes get much higher when you're working on the same code at the same time other developers are.

One thing to seriously consider, even if you have a few apps under your belt, is to take a class or workshop. There are some excellent ones out there, including (but certainly not limited to) the Big Nerd Ranch and the Pragmatic Studio. A few thousand dollars may seem like a lot of money, but it's a hell of an investment given the work opportunities available right now. A good workshop will beat into your head the important stuff. They'll strap a firehose of information onto your face and open the spout. They will make your brain hurt, but you will come out knowing memory management and the fundamentals, and that will put you in the running.

Another key skill is debugging. Being able to fix your bugs and those you find in other people's code is vital. Plus, the more bugs you encounter, the more things you know not to do in the future. Want to test yourself? Try downloading this. It's an Xcode project — a modified version of one of the Beginning iPhone 3 Development projects — that has a number of common bugs introduced into it. You should be able to get this to compile clean (no errors or warnings), then be able to navigate into every view in the application without it crashing and with something being displayed on every view. Once you've done that, you should then be able to fix any leaks in the app using Instruments. How long it takes is going to depend on a lot of factors, but I'd say that a typical, experienced, professional iOS developer should be able to fix this in between a half hour and an hour and a half. Regardless of how long it takes, if you can fix them all without help, you've gone a long way down the path to becoming a great developer.

Don't worry if you can't find them all that quickly. The first time you encounter a particular class of bug, it takes more time. Persistence is as important as speed, and debugging this project is a good exercise. Once you see a type of bug once, it's much easier to find and fix it when you encounter it again.

If I find time over the holiday, I might do a screencast showing how to find and fix all the bugs in the project. I can't promise I'll find the time to do that given my current workload, but if I can, I will.

Lastly, if you're looking for full-time iOS or Android employment, or for contract development work, send me your resume. MartianCraft isn't hiring full-time employees at the moment, but we do often need subs, and I know of many, many open requisitions for full-time jobs and I'm always happy to pass resumes along to hiring managers.

For Companies: Finding Mobile Developers

The other side of the equation is, how do you staff a mobile development project right now? Many experienced mobile developers were attracted to the space because it offered them the ability to make a living creating what they want to create. Mobile, and especially iOS development offer opportunities for small teams without a lot of funding to make a decent living. Many of those indie developers are doing exactly what they want to be doing and it's going to be hard, if not impossible, to attract them away from that life, if they're good at what they do.

Hell, many contract developers have app ideas they'd love to be working on themselves. A friend of mine who owns a development shop stated the problem fairly succinctly recently by saying: "We've got several app ideas we'd like to build, but clients keep throwing money at us."

I don't know exactly how many contract iOS developers there are with Objective-C experience that pre-dates the release of the iPhone SDK and/or who have several successful projects under their belt, but it's less than are needed. Big businesses are finally catching on to the importance of mobile and that's making a shallow talent pool even shallower. The situation for Android is similar. Though there are more people who already know the underlying language (Java), the platform has only relatively recently hit critical mass, so there aren't a lot of people who have been involved with successful Android software projects yet compared to the work available, and even less who have successfully shipped multiple Android projects.

In all reality, you're either going to need to offer crazy rates to lure the cream of the crop to your project (and that is no guarantee you're going to get the cream) or you're going to need to invest time and money into developing internal talent. I would advise at least having one really good, experienced tech lead on any decent size project, though. As many App Store success stories can attest, it is absolutely possible to ship good software using only inexperienced developers. But, doing so increases your risk substantially. Having at least one mentor who can guide and help and solve the really icky problems is gold.

In most places, you can train developers more cheaply and more quickly than you can find existing ones, at least if you're looking for full-time employees. It's not a perfect plan - your newly trained people will be learning on the job and making mistakes and may, at times, hit problems that are beyond their ken. But, with the proper training and support, they can handle the bulk of the work, and over time, will gain the experience to handle anything. Of course, you'll have to take steps to keep them from leaving. Arming an employee with a highly marketable skill always incurs a risk of losing that employee.

You can deal with that using contract terms requiring payback of training expenses or other similar ideas, but it's far more effective (albeit harder) to create an environment where people want to work. Job satisfaction is a bigger motivator for many developers than the size of their paycheck, assuming they're making enough to be comfortable and to feel valued. We're one of the few growth industries in this economy, and there's always another paycheck somewhere if you have these skills, so if you're create a hostile environment, no amount of money is going to keep the good people around long term.

There's another option you might be considering: offshoring. Go ahead. I mean, anything I say against the practice is going to seem biased given what I do for a living, and it's true that you can get considerably lower rates by doing it. I've seen shops in other countries offering iOS development services for about what you can make working at Burger King here in the states. And there are actually success stories from offshoring to cheap development body shops. Unfortunately, there are even more horror stories. In the few cases where I've been brought in to fix² projects of this nature, it's always been a waste of time and we ended up just throwing out the old code and starting over. Let me tell you, "start over" is a suggestion that strikes fear into the hearts of project managers.

To put it as fairly as possible: Offshoring increases risk. If you're comfortable with more risk, then it might be a good choice for you. There's a chance you'll come in way under budget and be a hero. Just recognize that there's a larger chance you'll end up six months down the line starting over completely. Any way you cut it, you're likely to have language barriers, cultural differences, and a hard time enforcing accountability. The simple fact of the matter is, even in countries with considerably lower cost of living, opportunities for good mobile developers are legion, so the only way those shops can maintain those excessively low rates is with a constant stream of new, inexperienced bodies. Call me crazy, but it seems to me, that if you're going to have inexperienced bodies working on your project, you'd be better off with ones closer to home that you can train and guide and have some idea of what they're doing.

I'll be blunt. If you're looking to build a team of iOS or Android developers in-house, you've got a tough road ahead of you at the moment. At some point, we'll hit equilibrium and it will get easier, but right now, it's hard. Just as I suggested to aspiring developers, I'd encourage you to get involved with the community. Send somebody, preferably somebody with some authority to hire developers and whose day-to-day job is working with the technology, to conferences, CocoaHeads meetings, and NSCoder Nights, or the Android equivalents (Meetup.com is a good place to find both iOS and Android groups in your area).

I'm always happy to hear from companies that need iOS or Android development resources. I'm thrilled to refer potential employees your way if you're looking for in-house talent, and MartianCraft is always open to talking with with you about your development needs, whether it's for a little strategic consulting and guidance, or to fully staff a development project. And if MartianCraft isn't a good fit for your situation or doesn't have the resources available to do a great job, there's a pretty good chance we know somebody who is and does. If we do, we'll connect you with them.

---

1 Technically speaking, without external input of some sort, computers are not capable of true randomness, and using a pseudorandom function doesn't make a computer non-deterministic. Pseudorandomness does make the computer pretend to be non-deterministic, though, and you will appear to get different output from the same input on successive runs of the program.
2 The term that we professionals in the industry use to refer to this process is "unfucking". Surprisingly, most dictionaries have not picked up this term yet.

Read more »

Posted in: Contracting,Developers,Rant

Free Course in Linear Algebra

Computer graphics programming uses linear algebra so heavily, you could basically say it's based on it. Yet, many people — perhaps most — who develop an interest in graphics programming don't have a background in Linear Algebra. At most universities, it is taught as an upper-level (300 or 400) mathematics course, which means that the majority of students who aren't majoring or minoring in math or certain hard sciences, typically don't take them. Even if you have studied it, if you've gone a period of time without using it, you very likely have forgotten it.

Yet, if you want to go beyond a certain level in graphics programming, you need to understand it.

Today, I stumbled across a free course in Linear Algebra, and it looks to be quite good. It's dense but, hey, this is higher math we're talking about here, so there's not much that can be done to simplify it without making it incorrect. But the price is right, the content is good, and what's even better is that the course doesn't assume much in the way of specific prior knowledge.

Make no bones about it, this is hard stuff to learn, but if you've got a reason to learn it (like a drive to create computer graphics), it helps a lot. Linear algebra in the classroom taught in an abstract manner bored me to tears. Having a real reason and being able to do things with it makes it much more rewarding and fun.

Read more »

OpenGL ES Book Recommendation

Since canceling my OpenGL ES 2.0 for iOS 4 book, I've had several people request book recommendations to use instead of my book. Honestly, I didn't really have one to give before today, partially because I intentionally avoided reading competing books while working on mine.

Today, while stuck on a train, I checked out Philip Rideout's iPhone 3D Programming by O'Reilly. Now, it's never easy to give an objective opinion on a book that competes with one you're writing, and even though my book is currently not on a production schedule and I have no time to work on it, I tend to still think of myself as working on an OpenGL ES book. Although there are several things that I would have done differently, I also know it's unfair to judge a book that way. Deciding what to include and what not to include in a book is a horribly difficult thing with an expansive topic like OpenGL ES and no two authors are going to make the same exact decision in that regard, so I'm not going to criticize Philip Rideout for, well, for not being me. Hell, normally not being me is taken as a bit of a compliment anyway.

Yet, though it's not the book I would have written, I can wholeheartedly recommend it. The information is solid and useful and it's presented in a way that doesn't assume or require a Ph.D in math. One thing that Rideout does do that I opted not to even attempt, is to give both the OpenGL ES 1.1 and OpenGL ES 2.0 approach to tasks that can be done in both environments, which is actually interesting on multiple grounds. One, it's a great transition for people who know 1.1 but not 2.0, but also, it shows the interesting ways people have figured out to work around the limitations of the fixed pipeline. These kinds of solutions fascinate me because they're the result of people refusing to accept technical limitations.

Much (all?) of the material from this book is available free online, but I'd recommend buying the book, which gives you access to the book's source code and also will also help an angel get his wings. Well, I'm not 100% sure on the latter, but it seems likely this time of year.

If you're floundering a bit with OpenGL ES, this book is well worth your time.

Read more »

Posted in: Book project,Books,OpenGL ES