Archive for Programming

LOB in 2015

Line of business software development is one of the least discussed and least sexy areas of software development. Ironically, it is by almost any metric the largest. There are more HR applications that are succussfully running inside their organizations than there are indie apps that are successful business.  Why don’t we care about LOB software? Why isn’t there an LOB blog or podcasts about being LOB developers (or even “dark matter developers”), the tools they use, and the struggles they face? Well, LOB development has been boring at least up until now. 

2015 is going to be the year that all of those older LOB applications get brought into the modern world. This will be brought upong by a mixture of pressure to go mobile and the natural purchasing cycles of medium to large enterprises.  On this week’s Coder RadioChris Fisher and I, had a lively discussion about Xamarin.Forms and my less than stellar expereince with it. 

Purists will of course say that for the best expereince on a platform you have have to develop natively on the officially supported tools for that platform. I agree with that, but here’s the thing — not everyone wants or needs “the best”. We make compromises of this sort al the time. For instance, I can’t afford the best car, so I drive a car that’s good enough for me; if you must know, I drive an 08 Toyotal Corolla. You see, I made a cost / benefit analysis when purchasing my car all those years back and that’s the exact sort of calculus that business types make routinely when it comes to commissioning line of bussines applications; that might explain all the IE 6 and VB code that’s running around for sure….

Here’s where I get controversial — I think they are right and correct in their decision, at least in principle. The issue becomes one of balance. How do you balance quality and cost-savings? That’s the question (at least in the mobile space) that Xamarin and the various vendors of mobile web-based app development solutions will have to answer. I still hope that Xamarin gets their act together with Forms, since C# is a much more pleasant language to work in thatn Javascript, but only time will tell. 

Xamarin Review

http://xamarin.comRecently, we at Fingertip Tech, INC have been doing a lot of work in Xamarin and Xamarin.Forms. All in all, things have been going fairly well and the tooling seems to get better everyday! Still, nothing is perfect and at the end of the day working with the Xamarin toolchain is a decsion that has to made on a per project basis and will greatly depend on the overall budget for the project and its maintenance. We are still evaluating Xamarin.Forms but the following are my findings and observations of working with Xamarin classic.

The Good: C# is an absolutely amazing language and every .Net developer ought to apologize to every Java for not spreading the word on just how phenominal the langauge really is. I know that will be a controlversial statment and the Java VS C# debate is a post for another day, but if you haven’t ever done any work in a modern version of C#, then I urge you to give it a shot and try to have an open mind.

Xamarin Studio is a pretty good IDE on Mac OS X and XCode developers will be familar with the IDE’s layout and overall setup – additionally, if you have ever used a modern version of MonoDevelop, you’ll be in pretty good shape. Additionally, the setup process on Mac OS X was pretty straightforward and I was impressed the Xamarin was able to tie into my iOS development tool-chain, pulling up my simulators and my code-signing credentials. On the iOS side, Xamarin does a great job of supporting storyboard and nib files for user-interface design and is no too shabby on the Android side also; however, Android UIs are still best done in the XML layout files directly.

Despite being in C# rather than Objective-C or Java, Xamarin is a faithful port of just about all of the native iOS and Android APIs. In fact, if you know how to do something with say UITableView in Objective-C, then you pretty much are good to go in Xamarin.

The Bad: Working in Xamarin Studio is great! Well, that’s as long as you are working on Mac OS X. The Windows version of Xamarin Studio is nowhere near as polished or as reliable as its Mac sister. For example, on my Windows 8.1 machine, there is an issue in Xamarin Studio that incorrectly highlights correct code as erroneous. Additionally, the intellisense and related features just aren’t as reliable on Windows. AlthoughIt is likely that a good number of developers using Xamarin on Windows would prefer to work in Visual Studio, there is little excuse for the way Xamarin Studio runs on that platform and frankly it makes it seem like Windows users who have not paid for access to the Visual Studio integration are not as much of a priority as those using Visual Studio or Mac.

The Ugly: Once upon a time, developers the world over were used to paying for by the seat licences for software development tools and even progreamming languages. Xamarin is trying pretty hard to bring that back but I’m not sure it works. Something about the per seat pricing model rubs me the wrong way. Additionally, up until just the other week, no form of mothly subscription billing was available and even to date there is no monthly pricing for anything beyond the ‘Indie’ plan. As the owner of a small but still bigger than five person software development company, I find their drawing the line between ‘Indie’ and ‘Business’ at the seemingly arbitrary number of five just a bit too well… arbitrary for my tastes. Additionally, there are plenty of companies like mine that would probably prefer to not be billed seperately for iOS and Android. All of this creates a sort of complexity that just doesn’t jive with what is otherwise a clean and very customer friendly offering.

Overall, I am pretty happy with how well Xamarin is working out for us and plant to continue working in it. Follow me on Twitter or Google+. Interested in getting your app project off the ground? Then, contact Fingertip Tech, INC and forget to follow us on Twitter!

A Swift Softening

enter image description here Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.

This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?

So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.

Questions? Comments? Find me on Twitter.

Programming Pitfalls: Circular Imports in Objective-C

PitfallI spend a lot of time in XCode working in Objective-C for iOS and Mac OS X projects. In many ways, Objective-C has become my “native language” in terms of programming languages. Still, that doesn’t mean that I can’t make really silly mistakes when working in that language. In fact, through the magic of GitHub you can see the mistake in real-time in my open-source Cocoa / Cocoa Touch networking library, MDNetworking.

The mistake is, like the best dumb mistakes, small and simple but can take more time than I’d like to admit to notice and resolve. Take a look at this pseudo-code sample for what went wrong:

#import "Foo.h"
#import "Bar.h"

@implementation Foo
 // CODE
@end

 

#import "Bar.h"
#import "Foo.h"

@implementation Bar
// CODE
@end

That’s it. That’s all you need to do to reproduce this programming pitfall. As always, I hope this has been illuminating and entertaining for you and please do follow me on Twitter.

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.