For the last 6 months, I've had the good fortune to work on a number of awesome projects. Things that I would love to show to other people and brag about, but I always hesitate because they aren't unconditionally awesome--and they aren't all mine.
As part of my contracting gig, I've jumped into a number of projects that were about 75% finished. My job was to polish them up and get them ready for the app store. While I'm really proud of the work I've done, there are several lingering problems that I really wish I could go back and "do right." Most of these are existing features that worked (more or less), and we just didn't have the time or money to fix.
There were also a number of management-level decisions that I didn't entirely agree with. Things like the way we handled in-app ads. I mean, I understand. My client needs to make money. Hell, I want them to make money. After all, I want them to keep paying me. But, it would have been nice if we could have toned things down a bit. Still, they asked for it; I implemented it. No shame in that.
Mostly, though, I don't want to look like I'm taking credit for someone else's work. After all, they lead the horse to water--I just got it to drink. Or, in other words, I didn't make it, I just made it awesome.
The really weird thing is that this uneasy feeling goes cuts other way as well. I often find myself having trouble talking to my clients, especially when things start to go wrong.
I mean, I don't want to be THAT guy. You know the one. The guy who is always whining about the last person who had his job. Always finding some way to blame them or excuse his poor performance on them. In an ideal world, I want to be the one who finds the problems, owns the problems and fixes the problems. But when my clients are pestering me for results, and I'm fighting to meet a tight deadline, and I just spent the last 15 hours cleaning up someone else's mess...well, it's hard to find a constructive way to express my concerns. I mean, let's be honest, (and I'm sure Obama would have my back here) sometimes it really is the Bush Administration's fault. Or in my case, it's the fault of whatever knuckle-typing orangutan they hired to cobble this thing together.
Don't get me wrong, I love a good orangutan. But, let's face it, they are the hippies of the simian world. If you need a sidekick to ride on your hog and watch your back at the roadhouse, then a orangutan is definitely the way to go. But, despite the convincing neck beard, they should not be allowed anywhere near code.
And I guess that's the real lesson here. Don't hire orangutans. They may work for bananas, but eventually you'll have to hire someone like me to come in and shovel out their poop. In the long run, those will become the most expensive bananas you've ever purchased.
-Rich-
Wednesday, January 12, 2011
Friday, November 5, 2010
From the Crazy Idea Lab
Hey,
Over the last couple of days, an idea has begun to bubble up from the bottom recesses of my brain. Preparing and putting on my presentation just reminded me how much I enjoy teaching. As a result, I'm seriously considering putting together a few tech training courses. I think I'd like to start by focusing on "Intro to iOS Programming" classes, then possibly branch out into other topic areas (Ruby on Rails comes to mind).
If anyone would be interested, please drop me a line. Also, let me know what sort of topics you would be interested in covering, as well as preferences for class length, etc.
Thanks,
-Rich-
Over the last couple of days, an idea has begun to bubble up from the bottom recesses of my brain. Preparing and putting on my presentation just reminded me how much I enjoy teaching. As a result, I'm seriously considering putting together a few tech training courses. I think I'd like to start by focusing on "Intro to iOS Programming" classes, then possibly branch out into other topic areas (Ruby on Rails comes to mind).
If anyone would be interested, please drop me a line. Also, let me know what sort of topics you would be interested in covering, as well as preferences for class length, etc.
Thanks,
-Rich-
MacTech Conference
I'm sitting in the great hall on the last day of the MacTech conference. It's been a great 3 days. I've learned a lot, and had a chance to talk to so many interesting people. My presentation went over well (though, being between sandwiched between two of the best sessions all conference, I am afraid it may have been somewhat overshadowed). It was just about the right length. I'm starting to feel presentation fatigue just as things are wrapping up.
I hope they will do this again next year.
-Rich-
I hope they will do this again next year.
-Rich-
Friday, October 22, 2010
Could Apple's App Store Lead to a More Open App Ecosystem?
The upcoming App store for Mac seems to have the internet in a mini-uproar. There seems to be a general fear that this is the narrow point of the wedge. That Apple's long term plan is to lock-down the Mac, the same way they have locked down the iPhone and iPad. And yes, that could be their end goal, but I can't help but wonder if maybe a desktop app store couldn't lead to more-open app stores across the board.
Limiting the app ecosystem makes sense for a phone. By it's very nature, its a limited device. It's OK if it can't do everything--as long as it lets me accomplish useful tasks while I'm on the run. On the other hand, users expect to get more work done on their iPads. Not surprisingly, the iOS SDK loosened up considerably with the iPad's release. Before, each application was kept entirely in its own sandbox. Now we can move files from one app to the next. It may not be complete access to the file system, but it has vastly improved the iPad's usefulness.
Soon we will have a full-blown desktop app store. Most of the excused given for limiting apps simply don't apply. We're no longer dealing with devices that have severely limited resources. We no longer need to worry about upsetting AT&T. Users don't need to jail break their computers to load applications from outside the app store. Most importantly, users will have even higher expectations on what applications can and should be able to do. This will create a considerable amount of pressure on Apple to open up the process, and despite what many people think, Apple is not immune to pressure.
In many ways, Apple is already on a slow path towards loosening restrictions on the iOS app store. They've lifted the ban on third-party languages. They've published a more specific list of their requirements. They continually add new features to the SDK that allow access to previously restricted features on iOS devices. I fully expect this trend will continue as Apple feels their way through what is obviously a tricky and difficult issue. I also expect this trend will accelerate once we have a desktop App store. It won't happen overnight, and it won't be perfect. But, I have a feeling that the Mac App Store will be a good thing for the larger App ecosystem.
Limiting the app ecosystem makes sense for a phone. By it's very nature, its a limited device. It's OK if it can't do everything--as long as it lets me accomplish useful tasks while I'm on the run. On the other hand, users expect to get more work done on their iPads. Not surprisingly, the iOS SDK loosened up considerably with the iPad's release. Before, each application was kept entirely in its own sandbox. Now we can move files from one app to the next. It may not be complete access to the file system, but it has vastly improved the iPad's usefulness.
Soon we will have a full-blown desktop app store. Most of the excused given for limiting apps simply don't apply. We're no longer dealing with devices that have severely limited resources. We no longer need to worry about upsetting AT&T. Users don't need to jail break their computers to load applications from outside the app store. Most importantly, users will have even higher expectations on what applications can and should be able to do. This will create a considerable amount of pressure on Apple to open up the process, and despite what many people think, Apple is not immune to pressure.
In many ways, Apple is already on a slow path towards loosening restrictions on the iOS app store. They've lifted the ban on third-party languages. They've published a more specific list of their requirements. They continually add new features to the SDK that allow access to previously restricted features on iOS devices. I fully expect this trend will continue as Apple feels their way through what is obviously a tricky and difficult issue. I also expect this trend will accelerate once we have a desktop App store. It won't happen overnight, and it won't be perfect. But, I have a feeling that the Mac App Store will be a good thing for the larger App ecosystem.
Wednesday, October 13, 2010
Changing the transition animation for an UINavigationController
I love the UINavigationController class for iOS. It's a great framework for managing a wide range of view-swapping applications, and we get the transition between views for free.
But, what if we want to use a different type of transition animation? UINavigationController only has one option--the new view slides in from the right while the old view slides off the left. There's no direct mechanism, but it turns out that it's not too hard to manage, at least for a select set of transitions.
First, lets look at the UIView methods. The navigation controller has its own view, which will contain the subviews we wish to manage. in iOS 4.0 and later, we can use that view's block-based animation.
Note: when we actually call pushViewController: we are setting the animated value to NO. This disables the Navigation Controller's default animation. Instead, the block of code uses the defined transition (in this case UIViewAnimationOptionTransitionCurlDown).
The same thing can be done using iOS 2.0 or later (although, you cannot submit anything older than 2.0 at this time).
Also notice, the two methods use two slightly different constants to define the view type. However, they both support the same four options: curl up, curl down, flip left and flip right.
We can get a different set of transitions by setting a transition animation for the Navigation Controller's view's Core Animation Layer.
There's one big difference here. The other animations were local. They only affected the code within the block (or between the beginAnimations and commitAnimations calls). This is a global change, and will continue to affect the Navigation Controller's behavior until it is changed again (or cleared by setting the animation to nil).
This also has four options: fade in, move in, push or reveal. For all but the fade, you can also set the direction of motion (from the top, bottom, left or right--though the iPhone seems to reverse the top and bottom options). We've already seen the push animation--the default behavior is a push from the right. Move in simply slides the new view over the existing one. Reveal pulls the old view away, revealing the existing one. While fade simply cross-fades from one view to the next.
I really wish there was an easy way to do other animated transitions (for example, having a view appear to grow from the center of the screen, or shrink into the center of the screen). But, I suspect those would take a lot of work at the CALayer level. I made a few attempts using regular animation blocks and altering the size of the incoming view. I could get the size to animate, but the old view simply vanished, leaving my new view to appear over a white background. Not what I wanted at all.
Still, there's a lot of cool effects you could produce with just these options. Happy hacking!
-Rich-
But, what if we want to use a different type of transition animation? UINavigationController only has one option--the new view slides in from the right while the old view slides off the left. There's no direct mechanism, but it turns out that it's not too hard to manage, at least for a select set of transitions.
First, lets look at the UIView methods. The navigation controller has its own view, which will contain the subviews we wish to manage. in iOS 4.0 and later, we can use that view's block-based animation.
[UIView
transitionWithView:self.navigationController.view
duration:1.0
options:UIViewAnimationOptionTransitionCurlDown
animations:^{
[self.navigationController
pushViewController:self.alternateView
animated:NO];
}
completion:NULL];
Note: when we actually call pushViewController: we are setting the animated value to NO. This disables the Navigation Controller's default animation. Instead, the block of code uses the defined transition (in this case UIViewAnimationOptionTransitionCurlDown).
The same thing can be done using iOS 2.0 or later (although, you cannot submit anything older than 2.0 at this time).
[UIView beginAnimations:@"transition" context:nil];
[UIView setAnimationDuration:1.0];
[UIView
setAnimationTransition:UIViewAnimationTransitionCurlDown
forView:self.navigationController.view
cache:NO];
[self.navigationController
pushViewController:self.alternateView animated:NO];
[UIView commitAnimations];
Also notice, the two methods use two slightly different constants to define the view type. However, they both support the same four options: curl up, curl down, flip left and flip right.
We can get a different set of transitions by setting a transition animation for the Navigation Controller's view's Core Animation Layer.
CATransition* transition = [CATransition animation];
transition.duration = 1.0;
transition.type = kCATransitionFade;
transition.subtype = kCATransitionFromTop;
[self.navigationController.view.layer
addAnimation:transition forKey:kCATransition];
[self.navigationController
pushViewController:self.alternateView animated:NO];
There's one big difference here. The other animations were local. They only affected the code within the block (or between the beginAnimations and commitAnimations calls). This is a global change, and will continue to affect the Navigation Controller's behavior until it is changed again (or cleared by setting the animation to nil).
This also has four options: fade in, move in, push or reveal. For all but the fade, you can also set the direction of motion (from the top, bottom, left or right--though the iPhone seems to reverse the top and bottom options). We've already seen the push animation--the default behavior is a push from the right. Move in simply slides the new view over the existing one. Reveal pulls the old view away, revealing the existing one. While fade simply cross-fades from one view to the next.
I really wish there was an easy way to do other animated transitions (for example, having a view appear to grow from the center of the screen, or shrink into the center of the screen). But, I suspect those would take a lot of work at the CALayer level. I made a few attempts using regular animation blocks and altering the size of the incoming view. I could get the size to animate, but the old view simply vanished, leaving my new view to appear over a white background. Not what I wanted at all.
Still, there's a lot of cool effects you could produce with just these options. Happy hacking!
-Rich-
Wednesday, September 29, 2010
Testing out Scrivner
So, I finally broke down and started testing out Scrivner. For those who don't know, it's basically a word processor specifically designed for writers. It allows you to organize and work on large writing projects, and it has been highly recommended by just about everyone.
So far I like it. With one exception.
Let me take a quick step back here, and say that I've listened to a lot of people talk about how the iPad is a great media consumption device, but that it sucks for media creation. I disagree. I use my iPad all the time. However, I use it differently than my desktop.
For example, brainstorming. I love MindNotes. It's the first computerized mind-mapping software that I felt was realistically useable. In fact, I now prefer it to paper. It's almost as easy to use, and I can so easily move things around, or export the results to use in other programs. In fact, my only complaint is that I cannot connect items into loops. I'd really like to be able to draw additional connections between existing nodes.
I am also a big fan of Pages on the iPhone. Don't get me wrong, I would never sit down and write anything of significant length. However, for editing documents, it is absolutely brilliant. Again, I probably prefer editing on my iPad to editing on my computer. In the old days (back when dinosaurs walked the earth--you know, the 90's), I would typically print out hard copies when editing, mark them up, then go back to the keyboard to make the changes. I find that editing on the iPad gives me almost all the advantages I found in working on hardcopies (very portable, a uni-tasking environment, easy to mark up with notes and comments), with the added bonus of removing the tedious final step. I can make the changes directly on the iPad, and just export them back.
In fact, I wish someone would develop a word processor on the iPad that really focused on making it a good editing tool. I'm not entirely sure what that would entail, but I can feel the general shape of it.
Enter Scrivner.
Scrivener, in many ways, has the ability to become an excellent editing platform. I love the way I work with scene-sized blocks of text. And it feels like there should be some sort of synergy between the outlining in Scrivner and the outlining I already perform in MindNotes. Mostly, it just feels like there should be some way of getting the peanut butter of Scrivener into the chocolate that is editing on the iPad.
But there isn't. And it doesn't sound like the folks at Scrivner have any interest in making one. And that's a sad, sad thing.
Sure, I could export the Scrivner document as a word doc, then import it into Pages on my iPad. But, I cannot round trip the document back into Scrivner (or at least, I don't know how to). And that may turn out to be a deal-breaker for Scrivner.
-Rich-
So far I like it. With one exception.
Let me take a quick step back here, and say that I've listened to a lot of people talk about how the iPad is a great media consumption device, but that it sucks for media creation. I disagree. I use my iPad all the time. However, I use it differently than my desktop.
For example, brainstorming. I love MindNotes. It's the first computerized mind-mapping software that I felt was realistically useable. In fact, I now prefer it to paper. It's almost as easy to use, and I can so easily move things around, or export the results to use in other programs. In fact, my only complaint is that I cannot connect items into loops. I'd really like to be able to draw additional connections between existing nodes.
I am also a big fan of Pages on the iPhone. Don't get me wrong, I would never sit down and write anything of significant length. However, for editing documents, it is absolutely brilliant. Again, I probably prefer editing on my iPad to editing on my computer. In the old days (back when dinosaurs walked the earth--you know, the 90's), I would typically print out hard copies when editing, mark them up, then go back to the keyboard to make the changes. I find that editing on the iPad gives me almost all the advantages I found in working on hardcopies (very portable, a uni-tasking environment, easy to mark up with notes and comments), with the added bonus of removing the tedious final step. I can make the changes directly on the iPad, and just export them back.
In fact, I wish someone would develop a word processor on the iPad that really focused on making it a good editing tool. I'm not entirely sure what that would entail, but I can feel the general shape of it.
Enter Scrivner.
Scrivener, in many ways, has the ability to become an excellent editing platform. I love the way I work with scene-sized blocks of text. And it feels like there should be some sort of synergy between the outlining in Scrivner and the outlining I already perform in MindNotes. Mostly, it just feels like there should be some way of getting the peanut butter of Scrivener into the chocolate that is editing on the iPad.
But there isn't. And it doesn't sound like the folks at Scrivner have any interest in making one. And that's a sad, sad thing.
Sure, I could export the Scrivner document as a word doc, then import it into Pages on my iPad. But, I cannot round trip the document back into Scrivner (or at least, I don't know how to). And that may turn out to be a deal-breaker for Scrivner.
-Rich-
Tuesday, September 28, 2010
"Developers prefer Android" is Bogus
Ok, I know I'm a huge iOS fanboy, and given the amount of time and energy I've invested in learning the platform, I have a vested interest in its success. But, I'd hope that I'd be a bit miffed at these headlines, even if the situation where reversed.
Today CNet posted the following article Survey: Developers favor Android over Apple long-term.
OK, first off, let's be accurate here. There is a 59% to 35% split in the surveyed population that says Android has the best long-term outlook. Which is very different from developer's preferring Android. I prefer Lisp to Java, but its pretty obvious that Java has had the better long-term outlook.
But what really upsets me is the science behind the survey. This was a survey of 2,363 Appcelerator Titanium developers. For those of you who don't know (and I didn't until I looked into it) Appcelerator Titanium lets you write cross-platform iOS/Android applications using HTML, JavaScript and CSS. In other words, these aren't your typical iOS developers, and will be heavily biased towards people who are interested in making cross-platformed apps.
It is not surprising, given the selection bias, that Android polled favorably. Also, overall iOS didn't do too badly. You might even say it kicked ass. Here's the iOS vs. Android rundown from the poll.
-Rich-
Today CNet posted the following article Survey: Developers favor Android over Apple long-term.
OK, first off, let's be accurate here. There is a 59% to 35% split in the surveyed population that says Android has the best long-term outlook. Which is very different from developer's preferring Android. I prefer Lisp to Java, but its pretty obvious that Java has had the better long-term outlook.
But what really upsets me is the science behind the survey. This was a survey of 2,363 Appcelerator Titanium developers. For those of you who don't know (and I didn't until I looked into it) Appcelerator Titanium lets you write cross-platform iOS/Android applications using HTML, JavaScript and CSS. In other words, these aren't your typical iOS developers, and will be heavily biased towards people who are interested in making cross-platformed apps.
It is not surprising, given the selection bias, that Android polled favorably. Also, overall iOS didn't do too badly. You might even say it kicked ass. Here's the iOS vs. Android rundown from the poll.
-Rich-
Subscribe to:
Posts (Atom)
