In 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.
I 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.
It 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!
Without further ado, here is Episode 12.
This is definitely going to be one of those posts where I’m posting this not only for others to find while they are Binging and Googling, but for future Pete to come back and re-figure out how to do something that took him some time to figure out in the first place. I’ve had several posts like that (this gem chief among them), and this sort of situation is a very good reason to have a blog. Blogs are good places for a brain dump.
My issue this time was with a tool called Sql Power Architect. Sql Power Architect is a data modeling tool that I was using kind of as an Erwin-lite due to Erwin’s super high price tag and Architect’s free community edition.
I was trying to make a diagram of a database that I was being asked to examine for issues. I was able to reverse engineer the database and lay it out like so:
However, when I tried to generate the PDF of this diagram, I got this error:
So, I did some searching and I wanted to increase the Java heap size, but only for that application if possible. I don’t run that many Java programs on my machine and I definitely didn’t want to upset the delicate balance of the Android environment that I have set up on the Windows side (which, incidentally is way more “picky” that the Android environment on the Mac side).
What I found is the Xmx switch for the java command line. I navigated to the Sql Power Architect install folder and figured out that architect.exe probably just called architect.java under the covers, so I executed this command below:
java -Xmx1024m -jar architect.jar
That fired up the program with a 1 gig heap size. After that, I loaded my diagram and was able to export it to PDF without any issues.
The finished PDF:
As I said, hopefully this post can be helpful to some poor soul in the future (even if that soul is me).
This week’s podcast was pretty fun. I interviewed someone that I know very well, someone who has taught me more about business and the business of software than any other person, Mr. Ron Carter. Ron is a CIO of a healthcare services company and held many roles in the past: consultant with major firms, developer, DBA, and architect, among others.
Ron has a track record of successfully delivering product after product, across many verticals in both the public and private sectors, for a tech industry where the failure of large product projects has become a punchline. Needless to say, Ron has a wealth of experience to share and I’m excited to have him on the show.
We talk about what it takes to be a CIO of an organization. Looking forward as a career path, we cover the role of CIO and the skills and knowledge that developers would need to reach the role. Other topics include team building, building trust, advice for new CIOs, and remote work.
It was a great interview, definitely give it a listen!