Archive for Programming

Programming Pitfalls: Windows 8 & VS 13

PitfallIt will come as no surprise to anyone who has been following this site for a while that I’ve been doing a bit of Windows 8 development. Like many developers moving over from another platform, I have some concerns about XAML and the development philosophy that it seems to promote, but that’s not the pitfall I hit this time. No, the trap I fell into is far more sinister….

You see I had opened Visual Studio 12 and got a notification that there was a new version of Visual Studio coming out and if I wanted to take advantage of all of the new goodness in Windows 8.1, I’d need to download it via MSDN. Like a good little code monkey, I did just that and made a fussy coffee while I waited for download and install to finish.

Once the install had finished I opened Visual Studio 13 and created a C# / XAML metro app. So far so good. No errors or warnings of any kind where displayed. On the whole, I am pretty happy with the workflow in 13 and got the app done in just about a week — it was just a proof of concept.

Now comes the tricky part: deployment. After going through the ridiculous proces of explaining to a non-tech person that they have to run a PowerShell script to run the archive Visual Studio produces, all seemed to go well — the first stakeholder was happy and passed it on to someone else. Then came the issues. For some reason the app would run on some devices and not others.

After a few frantic hours of search-fu, Stack Overflow browsing, and digging through the chaos that is the MSDN developer forums, I had a theory. Was it possible that all the devices that the app ran on had been updated to 8.1 and the ones it didn’t work on were still on 8? If so, there surely would be a menu or XML attribute in the App Manifest that I could change the minimum version to 8.

I was right on the first point and kind of right on the second. It turns out that the app could not be run on 8.0 devices as built and there is an option in the manifest to change the version. Unfortunately, in VS 13, you can’t change the version number. My suspicion was confirmed — Visual Studio 13 did not support building for Windows 8.0. Well, that’s not exactly right either. It turns out that Visual Studio 13 will build a Windows 8.0 app but will not create one — that means that you’d need to create the project in VS 12 but could move over to VS 13 later. I ended up having to create a new project in VS 12 and copying the code over into that new project. The bottom line is that this feels like a ham-fisted attempt on Microsoft’s part to force adoption of the 8.1 APIs and left me with a bad taste in my mouth. At this point, I am sticking with VS 12 until all of my projects no longer require 8.0 support but, frankly, this problem just shouldn’t exist.

Questions? Comments? Find me on Twitter.

Pallet Town: OO with Pokemon and Java pt2

Welcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

Ok, so we are picking up where we left off in our last post. We have a basic Pokemon class:

public Class Pokemon { 	
	public int id;	
	public String name;
	public int hp;
	public int ap;
}

We also have learned how to construct a Pokemon based on our existing class:

Pokemon pikachu = new Pokemon();

And of course how to set some properties for our new pikachu:

Pokemon pikachu = new Pokemon();
pikachu.name = "Pikachu";
pikachu.ap = 10;
pikachu.hp = 100;

That of course works, but is a little bit of a pain. Let’s take things a step further and make a more convenient constructor for our Pokemon class:

public Class Pokemon { 	
	public int id;	
	public String name;
	public int hp;
	public int ap;

	public Pokemon(int _id, String _name, int _hp, int _ap) {
		this.id = _id;
		this.name = _name;
		this.hp = _hp;
		this.ap = _ap;

		return this;
	}
}

I know that might look a little crazy but it is actually pretty simple. Basically, we are setting values for the properties of our Pokemon in the constructor itself rather than having to do so in the implementation — this is a very primitive form of encapsulation, one of the most important concepts of all of software development. So, using our new constructor, we’d create the same pikachu from before:

Pokemon pikachu = new Pokemon(14, "pikachu", 100, 10);

Doesn’t that look much cleaner?

Hope this post helps you on your journey to become a Pokemon… err coding master! Please feel free to send any feedback to me on Twitter or Google+. Also, be sure to check out my company Fingertip Tech, INC on Twitter.

 

Begginer’s Mind

There is a value in being a beginner. It’s not something that you can enter into a spreadsheet, plan for, or even try to replicate, but it is there and is something that should not be beaten out of beginners. Having beginners mind is about more than just being new to something — most people are in reality new (or shall we say ignorant) of most things. No, beginner’s mind is more than just ignorance though the former does require the latter. Beginner’s mind is that quality someone who is new to a craft has when he or she is very eager and is keen to tackle tasks that are perhaps a rung or two beyond his or her level. I had it when I did martial arts when I was younger. I had it when I first saw that through some mysterious writing that I now know as code I could control the computer and get it to stuff even if that stuff was just a silly guessing game or getting a Unicode rocket to launch from a Basic terminal. I remember the feeling of “knowing” Java after taking just a few months worth of classes and I also remember the feeling of about a year later realizing that I knew basically nothing about Java or really anything else I was doing. I can honestly say that, for me, the best time (or most fun time at least) in my career saws when everything was new.

Sadly, that was years ago and I’ve learned a lot since then and now have a fairly developed understanding of what I know (some stuff) and what I don’t know( just about everything). With that comes a loss of enthusiasm. Strangely, at least for me, the blasé comes not from knowledge of my own ignorance but rather actually from knowing what I do know. Though, like most developers I “know” a modest amount of “stuff”, I’ve com to see anything new through the lenses of my existing experience. Frankly, nothing looks shiny anymore. I find myself a bit like a child who realizes that his new Christmas bike is just his old one from four years ago with a splash of paint.

Part of me feels like this has been accelerated by the increased tribalism in the development space. In truth, it doesn’t really matter. Software still needs to be written and I still need to write it, but part of me does wonder if there is anything coming on the horizon that will restore that sense of eagerness that I see in the greener developers around me. Would love to hear your feedback, please find me on Twitter or Google+.

Pallet Town: OO with Pokemon and Java

Welcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

Object oriented programming is one of the most common and widely used programming paradigms on the market today. In fact, if (like me), you code for a living, then it is likely that you have to deal with OO concepts on a daily basis; in fact, they have probably become something of a second nature to you. Still, maybe you are just dipping your feet into the wide world of Pokemon… err I meant Java… err I mean programming. Well, this post and its follow up posts are for you.

Before we begin, take a look at this fast code snippet:

public Class Pokemon { 	
	public int id;	
	public String name;
	public int hp;
	public int ap;
}

If that seems foreign to you, don’t worry, we will be going over it right now!

OK so what we have there is a simple but boring class that represents Pokemon. Bascailly, we are defining the basic attributes (or properties) of a Pokemon. Taking it from the top, all Pokemon need to have an id so we can store them in our Pokedex (which is basically a fancy database), they all have names, they all all have hp or hit points, and they all have attack points. Of coure, we are likely over simplifying what Pokemon are but we will look at that issue in future posts.

At this point we have a Pokemon class, but no actually Pokemon objects. We need to create an instance of our Pokemon class. To do this we are going to use Java’s ‘new’ operator like so:

Pokemon pikachu = new Pokemon();

Our resulting “pikachu” is a little lame… he has 0 hp, 0 ap, and his name and id are null. Let’s try that again but take it a step futher:

Pokemon pikachu = new Pokemon();
pikachu.name = "Pikachu";
pikachu.ap = 10;
pikachu.hp = 100;

That’s it you have a very basic Pikachu! Sure it can’t do much right now and is a little boring and has some data encapsulation problems, but we will address some of those issues in the next post.

Hope this post helps you on your journey to become a Pokemon… err coding master! Please feel free to send any feedback to me on Twitter or Google+. Also, be sure to check out my company Fingertip Tech, INC on Twitter.

 

CoffeeScript Revisited pt1

coffeescript_logoCoder Radio listeners will know that I am far from CoffeeScript’s biggest supporter and still to this day have some serious concerns surrounding the languages long terms prospects outside of the Rails community. However, I am also giving it a second chance — meaning that I am actually going to use it for a small internal project at Fingertip Tech, INC. It would be far easier for me to do this project in plain old vanilla JavaScript and part of me really thinks that would just be more efficient. Yet, still I am giving it a shot in CoffeeScript.

The reason for this is that a lot of very smart people seem to really like it and it has matured a bit since the last time I gave it a shot.

I’m not sure how this test run is going to go, but I still do have some serious concerns about CoffeeScript. To start, it offers little advantages over JavaScript other than looking “prettier” and the syntax is closer to Ruby than I’d like it to be, since I’ve found that most CompSci students are only familiar with Java.

I’ll be sure to share my findings on CoffeeScript in a few weeks, so come back soon. Also, feel free to send me comments or suggestions on Twitter and Google+.

 

Fizzbuzzed

buzzedOver the last few weeks I’ve been interviewing potential candidates for development and QA internships. I can confidently say without exaggerating that this has been one of the most difficult and frankly disappointing experiences of my professional life. Frankly, most of the students I spoke to are barely qualified to shadow a programmer let alone actually touch a text editor or IDE of their own. We’ve covered this pretty thoroughly but there does seem to be a little more fertile ground here for discussion; this is especially true when you consider that most of the candidates I interviewed had finished a good deal of their coursework in Computer Science or some other related field.

The interview process is not some rigged-for-failure trivia contest alla Google or Microsoft. No, the verbal questions were simple and for the most part not the that technical. Here is a pretty standard line of questioning: “what is your favorite programming language / platform and why”. As long as the student could provide a reasonable (or at least reasonable sounding) explanation for his answer, he was in the clear. Beyond that there are of course the standard “checking for axe murders” questions.

There is however one last hurdle — a written test in the form of Fizzbuzz.  Pretty much everyone I asked to do Fizzbuzz failed and it didn’t seem to matter if I put them in front or an IDE, text editor, or just pen and paper. Worse still, some students sent me solutions that they had done without supervision that actually contained errors. No limits were placed on the students in terms of platform of language and (not surprisingly) most students chose to use Java as their test language and stated that they’d taken a number of Java-centric courses.

One area of this process has surprised me — many of the candidates who did the poorest on Fizzbuzz were also the most likely to drone on about sorting algorithms or some other impressive sounding nonsense of which I am relatively sure they have no understanding.

Remember kids, Knuth is key but you still need some sort practical understand of what exactly you are doing. Please do leave any comments on Google+ or Twitter. Also, please keep in mind that I am always available for consulting projects.

 

Pallet Town: Intro to AFHTTPClient Part 1

Pallet TownWelcome to Pallet Town! Pallet town is going to be an ongoing bi-weekly look at various development technologies and techniques from the perspective of someone new to that technology. For those who might know or (God forbid) are too young to get the reference, Pallet Town is the first town in the original Pokemon games for the Nintendo Gameboy.

This week we are going to take a look at getting some simple networking done with the new hotness in iOS networking frameworks: AFNetworking. To be specific we are going to focus on one of its more important classes: AFHTTPClient Now there are is a little bit of a prerequisite here, we are going to go ahead and assume that you have already added AFNetworking to your iOS project and we are also going to assume that we are going to use ARC.

For starters, let’s take a look at how we instantiate the AFHTTPClient:

Now that we have our client, let’s say we want to make a simple RESTFul GET call; this sample builds a bit on our Pokemon themed ASP.Net MVC web app from the last installment of Pallet Town. Ideally, this call would just get all the Pokemon available on the API; this of course assumes you followed the normal MVC patterns in your routing on the API. Here’s the code:

- (void)getAllPokemon
{ 
	AFHTTPClient* client = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:@"SOME_URL_STRING"]];
	[client getPath:@"api/pokemon/" parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
			NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
			NSLog(@"Request Successful, response '%@'", responseStr);
		} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
				NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);
	}];
}

That was fun but let’s make things a little more complicated. Let’s say you want to pull a particular Pokemon via its Id. That’s still a GET request but takes a parameter like so:

- (void)getPokemonById:(NSNumber *)pokemonId
{ 
	NSDictionary* parameters = @{@"Id" : pokemonId}
	AFHTTPClient* client = [[AFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:@"SOME_URL_STRING"]];
	[client getPath:@"api/pokemon/" parameters:parameters success:^(AFHTTPRequestOperation *operation, id responseObject) {
			NSString *responseStr = [[NSString alloc] initWithData:responseObject encoding:NSUTF8StringEncoding];
			NSLog(@"Request Successful, response '%@'", responseStr);
		} failure:^(AFHTTPRequestOperation *operation, NSError *error) {
				NSLog(@"[HTTPClient Error]: %@", error.localizedDescription);
	}];
}

Getting Pokemon from the server is a lot of fun, but you know in the age of Minecraft, I like to  be a little more creative than just working with the set number of Pokemon that Nintendo provides. Tune in for our next installment to see how to POST my very own legendary Pokemon to the server!

Programming Pitfalls: iOS Simulator and Audio Codecs

PitfallThere are some bugs that you fix and brag about to your friends afterward, then there are the ones that are just plain embarrassing. Unfortunately, I’m writing about one of the latter today rather than the former.  You see this pitfall, though no more or less annoying than the others I cover in this series, is made all the more worse by the fact that I should have known better. If you’ve ever listened to an episode of Coder Radio in which I mention the iOS Simulator, then you know that I always warn developers to never trust it; the reason for this is that your code isn’t really running on iOS but rather a pseudo-OS X platform. Never ever trust the simulator. Ever.

Taking a step back, let’s look at the issue. I have a number of audio files and they all play just fine on the iOS Simulator, but my beta testers are reporting that they can’t hear any audio files at all on their devices. This is odd to say the least. I scoured my AVAudio implementation looking for the most obscure of bugs but still found nothing. The good news, using “good” very loosely, is that I was able to delete the app and reproduce the bug myself.

After a few hours of pouring over LLDB and various Test Flight logs, I found that everything looked fine: the audio URLs (the audio is coming from a server) all looked fine, there didn’t appear to be any NSZombie related issues, and the audio files themselves seemed fine.  I was totally lost.

Then I remembered something based on an offhand comment I found on a StackOverflow post — the simulator uses OS X’s audio subsystems which differ from iOS’s. In particular, OS X has access to a few more audio codecs than iOS. As it turns out, the API I  was interacting with has different calls that request the audio in different formats. I changed the call to request the MP3 formatted files and was good to go. Facepalm.

I hope you’ve enjoyed taking a look at another programming pitfall and please do leave any comments on Google+ or Twitter. Also, please keep in mind that I am always available for consulting projects.

Coding is More than Just Code

ScreenHunter_1760-Feb.-15-09.35Every week I do a little online radio show called Coder Radio with incomparable Chris Fisher. Most of the show’s feedback is overwhelmingly positive, however, there is, on occasion, a comment made about the show lacking in “code”. In the past, I’ve brushed these comments off by reading a little Objective-C or Ruby on air in order to make a point — the point being that reading code on air or getting extremely technical is more than a little boring. Still, I’m doing more than trying to entertain by not reading out code on air or going into the nitty gritty of the latest hot API.

To start, APIs change and like all creative works (yes, coding is a creative exercise) are products of the time and place they were written in. As a thought exercise let’s take a look at Dropbox’s new mobile APIs aimed at handling what (boiled down to its most basic oversimplified definition) could be called super-caching. That’s a really good idea in 2013, when a lot of people have smart devices but terrible mobile service. However, it’ll seem pretty quant in ten or so years when the world is blanketed with the equivalent of Fios over the airwaves at an affordable price. Of course there is  an aspect of the show that focuses on what’s new or ‘in”, but on the whole I try to keep the show as “evergreen” as possible.

I like C# but maybe you don’t. Would you really want to listen to someone go on and on about the particulars of C#? Conversely, maybe you like PHP, but I only go in depth on C family languages — is that giving you a lot of value? When it comes down to it the particulars of a given language are just that particular to that specific language. Larger concepts, however, can provide value to all sorts of developers working on any platform.

I’ve noticed that it is mostly the younger set of the audience that seems to have the issue and to a point that makes sense. After all, when you are just starting out it seems like learning the API for whatever platform you are working on is your highest priority, because you are under a lot of pressure to actually prove yourself. However, once you get beyond  that initial green period, you’ll likely find that being successful in the industry has very little to do with ho well you know a particular API but rather how well you can navigate processes, understand other disciplines including business and business development, and (I know this will sting a few of you) interact with people in meaningful and pleasant ways.

The bottom line is Coder Radio, like software development itself, is and will continue to be about far more than code. Feel free to comment on Twitter or Google+

Book Review: Programming C# 5.0

catI recently read Programming C# 5.0 by Ian Griffiths as part of O’Reilly’s Blogger Review program. For those who care about formats, I read the epub format and not the print one. Overall the book isn’t bad, but there are some issues that left me less than impressed. My primary issue with the book is that it isn’t clear who it is intended for. Certainly, targeting a generic C# book is going to be hard given the wide variety of areas C# is used in (Azure, XNA / MonoGame, WinRT, etc) and it seemed like there was a need for the book to be a little more specific in terms of domain.

There also are some issues in terms of the skill (or rather experience) level of the book’s target audience. It starts by explaining the history of C# and .Net and in particular how it related to Microsoft’s Java strategy — in that C# was their answer to Java. All of that is very interesting and probably something that a C# developer should know. However, things quickly fall of the rails when the author explains what ints and other basic types are. This trend continues for about four chapters but then the book quickly moves on to more advanced and more interesting topics.

Despite this odd and somewhat jarring inability to figure out who this book is for and what the scope of the text should be there is a good deal of value to get out of the text. For instance, the text teaches not just programming in C# but how to program in idiomatic C# and to a lesser degree how to follow the accepted, though admittedly somewhat informal and subject to personal tastes, conventions established by Microsoft and the .Net community.

Overall, I would recommend this book to someone in school or who is new to programming and suggest that person read it straight through. For more advanced users or users who have a few years of development experience in another language, I’d still suggest picking this book up but skipping to about chapter four or five.