Mentoring

Podcast Episode 14 – Mentoring

MentorEpisode 14 of the Pete on Software Podcast is out and this week, I’m sharing my thoughts on mentoring. The word mentor has been watered down to just mean people that you want to look up to and emulate. To me, a mentor relationship is a two way street and unless you are having personal interactions with your “mentor” on a regular basis, you’re doing it wrong.

To top it off, when looking to find potential mentors, we may be barking up the wrong tree in terms of finding what we really need. I don’t spend any time talking about why you need a mentor, because I felt that everyone knows why they need to have their own Yoda or Mr. Miyagi.

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

Dumb Mistakes

iOS – TableView Row Height Wrong on 64-bit Only

I had a fun little problem pop up at my client site today. We had a tableview that was displaying data that looked perfect when running on everything except for an iPhone 5s. After a little bit of DuckDuckGo-ing, we came across these Stack Overflow questions here and here that suggested that the heightForRowAtIndexPath method might be the culprit.

When I went and dug in, I found this warning (I did do some cut and paste to get the warning just over near the code):

float to CGFloat Warning

If you can’t read it, that warning says, “Conflicting return type in implementation of ‘tableView:heightForRowAtIndexPath:’: ‘CGFloat’ (aka ‘double’) vs ‘float'”

The code was the following:

- (float) tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (indexPath.row % 2 == 0) {
        return 247.0;
    }
    else {
        return 315.0;
    }
}

The signature for that method means that the code should have looked like this:

- (CGFloat) tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (indexPath.row % 2 == 0) {
        return 247.0;
    }
    else {
        return 315.0;
    }
}

So what is the explanation? Basically CGFloat was typedef’ed as float. However, Apple wanted you to use CGFloat in case they ever changed what a CGFloat was going to stand for. Apparently, with the move to 64-bit, Apple has done just that. In 32 bit versions, the signatures were identical. However, now in 64-bit land, because the method was returning the wrong type, iOS considered the return value to be 0, breaking our layout. By only changing the return type in the signature to the proper value, the app functioned again properly.

Keep this in mind the next time you might think about being smarter than the language designers and consider not using their typedefs.

Podcasts

Podcast Episode 13 – Itzik Ben-Gan on T-SQL

Itzik Ben-GanIn this week’s episode, I interviewed Itzik Ben-Gan. This was a huge treat for me because Itzik is someone that I’ve learned a lot from and looked up to for almost a decade. This wasn’t even an interview that I would have chased down on my own, but I will say that doing the interview has given me confidence to chase down some others.

If I didn’t land this interview for myself, then who did? Jeff Meyer (another Itzik fan) reached out to Mr. Ben-Gan on my behalf and got him to agree to come on the show and then looped me in to make the necessary appointments. All along the way, I was a little nervous about talking with Itzik. You know what they say about meeting your heroes…

In this case, that fear was totally unfounded. Itzik was amazingly nice and right off the bat, I could tell that he was exactly how I had hoped that he’d be. The guy just KNOWS T-SQL. We had a great conversation about T-SQL features: those that are underused, those that are powerful, and those that aren’t there yet – but should be. We also talked about his teaching and writing style and along the way collected some great resources.

Even if you aren’t a developer, you should listen to this week’s podcast. It is a pleasure to listen to a passionate expert talk about their craft.

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

Conferences

Stir Trek 2014 Talk Recap

Stir Trek LogoI did it! Mission Accomplished (and I don’t mean in that ironic “banner on an aircraft carrier” way).

A few months ago, I submitted a talk to Stir Trek and it got accepted. I had wanted to speak at a conference again, but I was super stumped as to what to talk about that would be interesting enough to stand out. There were only 40 speaking slots and hundreds of applicants, so it had to be good. Part of the selection this year was done blind (based on nameless abstracts), so content really needed to be key.

Thankfully, my co-worker Jey came up with a great idea. He suggested talking about how to do push notifications in iOS. I wanted to really think big, so I expanded it to include Android. Another co-worker, Jeff, thought that if I included Win Phone 8 I would really increase my appeal. So, I submitted this:

Don’t Call Us, We’ll Call You: Push Notifications in iOS, Android, and Win Phone 8

Mobile is the future and one-way-only conversations are boring. Find out how to keep your app’s users in the know with push notifications. In this session, we will evaluate the push notification landscape, see why push notifications are useful, and how you would send and receive them to iOS, Android, and Windows Phone 8 devices. Then, we’ll take a look at writing a push server, and evaluate the pros and cons of rolling our own versus leveraging a Notification as a Service platform such as Urban Airship or Parse.

As I mentioned in my talk, my original idea was that writing the native push servers would be a really bad experience and then the cloud providers would wipe all of my tears away. Nothing could have been further from the truth. I mean, the native push servers (especially iOS) definitely had their challenges, but once you write them, they are done. The cloud providers don’t protect you from the worst parts of setting up the push servers, anyway. Their benefits aren’t ease of development, but rather their reliability and extra features that they offer that don’t show up in a simple push demonstration.

Preparing for the talk was a lot more difficult that I originally thought and took at least twice as long. I wrote an iOS application, an Android application, a Windows Phone 8 application, and a .Net REST service to push to them. I deployed the .Net service to an EC2 instance so that it would be available everywhere.

The code to make the application do what it needed to do at its core wasn’t difficult (on purpose). However, the amount of yak shaving that I had to do to get things rolling in iOS, configure the EC2 instance, and get the Windows Phone 8 environment running inside VMWare were really painful.

I did learn a lot, though. Thankfully, all of my demos went off without a hitch. That was my biggest fear, but I was very fortunate to have had no problems at all. My next biggest fear was that I’d get questions that I had no idea about. Fortunately, I got great questions from the audience and I was able to speak to them with some degree of intelligence.

I had a lot of friends turn out to see me talk, which helped a lot. It was also an amazing experience to present on such a huge screen and in such a large room. Add to that the way that the speakers were treated by the amazing organizers (see our speaker room spread here), and it served to make the entire day very special for me.

As promised, all of my code and slides are up on the Stir Trek Github Repo under the Mobile track, so check them out.

If you were at my talk and would be so kind as to rate the talk (and give any optional feedback), I’d really appreciate it. You can do that here.

Podcasts

Podcast Episode 12 – When to Leave Your Job

QuitIt has been 3 weeks since I last published a podcast. I had some interviews fall through and then I let myself get caught up spending every waking minute working on my Stir Trek presentation. And before I knew it, I was just out of the habit of publishing my podcast. I knew I had to put something out so that I didn’t get caught in a serious podfade. I had a few episode ideas set aside in case things fell through, but they weren’t working out.

That leads me to today. I was able to find something that I wanted to talk about, albeit a bit on the short side for the content portion (I make up for it a bit with 3 picks this week). Sometimes the hardest step is just getting back on the horse. This isn’t at all to say that I think that this episode is terrible, I just really wanted to share a bit of what I’ve been going through. The fact that there is a term for it means that it is probably pretty common. Hopefully, maybe at some point in the future this post will stand as a good encouragement to someone to stop procrastinating and just PUBLISH!

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.