Developing Perspective

Show 1.0


00:00:00   Hello and welcome to Developing Perspective.

00:00:02   Developing Perspective is a near daily podcast discussing what is new and interesting in

00:00:06   iOS, Apple, and the like.

00:00:09   I'm your host, David Smith.

00:00:10   I'm an independent iOS developer based in Herndon, Virginia.

00:00:13   This is show 1.0.

00:00:15   That's right, this is the first of what I would call the official shows.

00:00:18   Beyond this, things seem to have settled down.

00:00:21   I think I've gotten the kinks worked out and so the podcast is out of beta, which is kind

00:00:26   of exciting for me.

00:00:28   Today is July 28th.

00:00:29   Let's get started.

00:00:30   From a developing perspective, it's basically that I will cover a handful of links and articles

00:00:35   that I found interesting in roughly the last 24 hours or so, and then move on to a more

00:00:39   general discussion towards the end.

00:00:41   The show will never be longer than 15 minutes.

00:00:43   Let's get going.

00:00:44   All right.

00:00:45   To start off, I have a couple of things, sort of analyses that I did yesterday.

00:00:52   And the first one I'm going to mention here, which is a follow-on to my MAC value discussion

00:00:56   that I discussed yesterday, is what I was trying to discover whether CPU is the primary

00:01:03   driver in compilation time or if hard drive speed or related things are.

00:01:07   And, you know, there's a lot of things that I'm sure would always come into play here.

00:01:11   It's always hard to pinpoint exactly one thing that is the core driving factor.

00:01:16   You're always going to be creating some kind of synthetic benchmark to do that.

00:01:19   But at least I was hoping to create something that would be an interesting and relatively

00:01:24   valid way to evaluate that.

00:01:26   And so what I did is I took my three hard drives that I had sitting around the office.

00:01:32   I have a Mercury Extreme Pro SSD, just a regular 5400 conventional spinning disk, and then

00:01:38   I had a Lacey big disk which is set up to RAID 0.

00:01:43   And so that creates three very distinct hard drive speeds that I'm testing out, racing

00:01:48   from SSD on the fastest end to the graduate 5400 RPM conventional disk on the other extreme.

00:01:56   I also have two machines in my office. I have an Intel i7 quad-core iMac, and then I also

00:02:02   have a MacBook Pro which is a 2.53 GHz Intel Core 2 Duo, which is a dual processor. Those

00:02:09   machines comparatively from a Geekbench perspective, the iMac is 9890 and the MacBook Pro is 3581,

00:02:17   So almost roughly about 3 times, I think it's 2.7 times faster, is the iMac versus the MacBook

00:02:23   Pro.

00:02:24   So then what it allows me to do by having this setup is I can attach the FireWire hard

00:02:29   drives to each of the machines and then compile my three main projects, audiobooks, simplecasts,

00:02:34   and my recipe book across all three of them.

00:02:38   And then switching between the different hard drives and switching across the different

00:02:41   machines, which essentially gives me six data points for all the different options and configurations

00:02:47   there. And basically to do this if you're interested basically you can just run

00:02:51   Xcode build clean and then you run time Xcode build at the command line in the

00:02:56   root directory of an Xcode project and it will build it in a way that is sort

00:03:00   of much more reliable and works well as a benchmark. And the results were fairly

00:03:05   interesting, not exactly what I would have expected. So first there's

00:03:09   definitely an improvement that you get in compilation time and speed based on

00:03:13   the different hard drives. I saw about a 10 to 15 percent improvement between moving from

00:03:19   the 5400 RPM drive to the SSD. However, what I saw, which was much more dramatic, is that

00:03:26   the actual compilation time was far more dependent on CPU. The difference between moving from

00:03:31   my iMac to my MacBook Pro was very dramatic, almost exactly matching the Geekbench change.

00:03:38   So compilation was about 2.75 times faster

00:03:42   when working on my iMac than it was on my MacBook Pro.

00:03:46   I imagine at a point this would level off

00:03:48   and you'd stop seeing diminishing returns.

00:03:50   However, it certainly is at this point,

00:03:53   I would say that compilation time is far more tied

00:03:55   to the speed of your CPU and probably even more there

00:03:58   the number of cores that you have.

00:04:00   In this case, going from two virtual cores

00:04:03   to eight virtual cores was a far more dramatic improvement

00:04:07   than I was able to see with a hard drive. Of course, you combine the two, you get a

00:04:10   fast hard drive with a fast CPU and you'll have the best results. Definitely something

00:04:14   that's worth thinking about when you're considering what your next developer machine is.

00:04:18   All right. Next link I have is over to the--it's an oldie but a goodie from the Red Sweater

00:04:25   Blog. So this is Daniel Jelkud's blog. And it's just an interesting article that he wrote

00:04:30   some years ago when the old stock market crashed in 2008. And essentially, what it's just is

00:04:35   reminding us that the safest investment you can always have is in yourself, given that

00:04:40   that is the one place that if you put your money, your time, and your energy, you know

00:04:44   you're going to see that return because you're investing in something that you're going to

00:04:47   have to maintain and do for the rest of your life, which is your life.

00:04:53   Next is over on the iFixit blog, people who do those amazing teardowns of machines and

00:04:59   hardware.

00:05:00   It's always one of my favorite things whenever a new piece of hardware comes out, is always

00:05:04   seeing them tearing it apart. They have a job posting out. They're looking for a technical

00:05:09   writer and tinkerer, as they describe it. And it's just, I came across this in my RSS

00:05:14   feed, and I was just really struck by how well they did in putting this together. It's

00:05:18   just a really polished, nice job posting. They have a great video at the bottom talking

00:05:23   about what the office environment is. It sounds like a really interesting company to work

00:05:27   for. If I was looking for a job, I'd definitely consider it. But I think it just serves as

00:05:33   a good example of the kind of thing that if you're looking to hire developers especially,

00:05:38   something that you want to look at for this is a good way to communicate, I think, what

00:05:43   it's like to work there and to make people want to work there.

00:05:46   All right, next, there's a great article over on the Brooks Review talking about how he

00:05:53   evaluates and decides on purchasing new iOS apps. And this kind of walks through how he

00:05:58   finds out apps, the values and weights in which he places on the various attributes,

00:06:03   for example, icons, names, ratings, prices, those types of things, and just generally

00:06:08   walks through his sort of mindset when he's trying to buy a new app. I think this is a

00:06:14   very useful article as a just sort of an iOS developer for just getting sort of into the

00:06:19   mind of the customer maybe and making sure that I'm valuing and emphasizing the right

00:06:24   things in my development process rather than not.

00:06:28   And so definitely just worth checking out.

00:06:29   Obviously, he's a bit of a power user, so it's not

00:06:31   necessarily the way that all users think about your

00:06:34   applications, but certainly interesting to look at,

00:06:36   nevertheless.

00:06:38   And lastly, I have here a little discussion that I did

00:06:43   over on my own blog talking about App Store sales

00:06:47   volatility.

00:06:48   And specifically, so this was after reading a tweet, David

00:06:51   Bernhard from AppCubby talked about how while variability in his sales this week, where

00:06:58   one day I think he dropped about 70% from normal, and I was curious to see what's normal,

00:07:04   what's typical for being an iOS developer in the App Store. And so I plotted the percent

00:07:11   change in day-to-day sales as well as week-to-week sales year-to-date for my apps. And it's kind

00:07:18   of remarkable when you look at it that it's not uncommon to have daily swings in the 40%

00:07:23   range. So 40% up, 40% down, and then on a weekly basis to have ranges swings almost

00:07:30   as large as sort of in the 20% range, which also is pretty impressive I'd say. So definitely

00:07:37   if you make your living in the App Store, it takes a bit of a strong constitution and

00:07:41   a bit of patience because it's quite a ride.

00:07:43   Alright, and for today's discussion I'm going to talk just briefly about something that

00:07:50   I found kind of fascinating.

00:07:51   And so yesterday I had a blog post that I mentioned a couple days ago about MAC value,

00:07:58   where I sort of did a cost for performance analysis of the various MACs in the current

00:08:02   lineup and it got linked up on chamblanc.net and then over on marker.org, which on a personal

00:08:08   note is sort of the highlight of my week to be shown up on places, especially marker.org,

00:08:13   which is a site that has just been one of my favorites for years.

00:08:16   And really, it's very cool to see your name mentioned there.

00:08:20   The thing that was kind of fascinating about it,

00:08:23   and this is something that as a developer,

00:08:25   I think is a big mind shift change going from doing just development

00:08:29   to also now doing some blogging, is the sort of the urgency,

00:08:34   sort of the temptation maybe is the better word for it,

00:08:36   to constantly be tinkering and changing the post after you publish it.

00:08:40   So you publish it, and then, for example,

00:08:42   I got a lot of feedback. People ask questions, things are going on and on. And there's this

00:08:46   fascinating thing that I found that with an application, I'm constantly iterating on it.

00:08:50   I'm constantly improving it. I'm taking one base of code and I'm trying to make it as

00:08:55   good as possible. Adding features, improving it, adding depth. Whereas moving into the

00:09:00   sort of the written realm, that motivation changes quite dramatically because while I

00:09:05   could, I suppose, constantly be sitting there editing my blog posts, changing them and adding

00:09:09   information, removing information, tweaking and changing them, it doesn't really fit with

00:09:14   the form. I think the most readers' expectations is once they read it, other than sort of typographic

00:09:19   corrections or if you made me sort of factual updates, it is what it is. And so it's just

00:09:25   kind of an interesting thing that I've had to deal with. I'm kind of going from that.

00:09:29   I think at this point, it's just kind of interesting for me to be thinking, "Okay, when I'm going

00:09:34   to write something, I should probably make sure that it's pretty close to exactly what

00:09:39   it is that I want to say, make sure that it's sort of well thought out and thoughtful in

00:09:44   a way that with code I'll often, you know, you write something, you kind of get it working,

00:09:48   you get that first prototype out.

00:09:50   And then you put it in front of some beta testers and those types of processes are in

00:09:55   place whereas with a blog post I suppose I could do some of that internally, but mostly

00:09:59   it's just I need to make sure I can change my mindset that writing is very different,

00:10:03   It's a different modality than writing code.

00:10:07   That when I hit publish, there is only version 1.

00:10:11   There isn't really version 1.1, there isn't version 1.2, there isn't version 2.0 of a

00:10:16   blog post.

00:10:17   And I just needed to sort of, thought it was interesting to kind of be thinking about it

00:10:20   in those terms, because it's a change that I wasn't expecting coming from software development

00:10:24   and then moving into blog writing.

00:10:26   All right, well that's today's article.

00:10:29   I hope you enjoyed episode 1.0.

00:10:32   As I said, basically at this point, I think I've kind of got the kinks worked out.

00:10:36   I think things have settled down.

00:10:38   If you have any feedback, questions, thoughts, corrections, please hit me up on Twitter.

00:10:43   I am @_davidsmith, so underscore d-a-v-i-d-s-m-i-t-h.

00:10:49   Otherwise have a good day, happy coding, and I'll talk to you tomorrow.