Archive for Uncategorized

Bashing Bash

Ubuntu on Windows
Coder Radio listeners who already caught Monday’s show will know that I have been playing around with Bash on Windows. To be specific I was using the Ubuntu “app” available on the Windows Store and made not modifications to it or my system.

The experience of just getting it installed is pretty terrible. You have to join the Windows Insider program and after you’ve done that restart your computer a number of times until Windows Update notices that you’re in the program and picks up the required update. There’s no direct command line script you can for this you just restart, restart, and restart… until… eventually… it works. Having spent a lot of time in UNIX-like environments, I’ve gotten used to things be a little more precise than “restart and pray.”

Once it got the Windows Insider issue sorted out and installed the Ubuntu “app” from the Windows Store, I started messing around with the BASH interface. On the whole, it functions like a real BASH interface and the commands you’ve been using on Linux / macOS will work just fine. However, that was pretty much the end of my enjoying the experience. Like many things in technology my primary issue is one of expectations. I expected to simply be able to open a BASH window that would start in my home directory and be able to interoperate easily with the local Windows file system. This is not how BASH on Windows works. The Linux file system is separated into an obscure section of the hard disk, making even the simplest tasks of working between the Linux systems and Windows needlessly challenging. From a practical perspective what I wanted to be able to do was edit some code using Visual Studio Code somewhere in my ‘Documents’ directory and run BASH commands against that code easily.

Because I am doing a lot of work that crosses into the legacy Windows world, I really wanted this to work and find it particularly disappointing because other Microsoft tools (Azure, VS Code, and Typescript) have proven to be surprisingly useful for my latest efforts. It would have saved me a ton of headaches. However, it’s just not ready for prime time yet. Ultimately, if you’re working in a Windows environment you’re still better off with just learning Powershell or using something like Cygwin. Let me know what you think on Twitter or in the comments. Also, heard of Docker Compose but not sure what it’s all about? Checkout my quick explainer here.

Ahoy Mateys!

I am happy to announce the official public launch of my new company Buccaneer Tech, INC. Buccaneer is something new from what I’ve done before, as it has more of a focus on bringing the best of open-source technologies to the enterprise market via innovative mobile and software as a service products.

Enough of the buzzword bingo! What does this all mean? Well, it means we are going to be launching some products based on open-source and of course we will also be limitedly available for consulting projects.

I’m not ready to make any product announcements just yet but if you follow @BuccaneerTech on Twitter to be one of the first to know!

Testing TDD: First Look

TDD (Test Driven Development) seems to be gearing up to the new “best practice” for 2014 and you know there is nothing I like more than being told that there is a new (though TDD’s newness is debatable) shininess that will solve all of my problems and make me poop rainbows. To be clear, I don’t think that TDD is a bad idea. In fact, we are actively discussing how we might implement TDD where it makes sense at Fingertip Tech, INC – they key phrase there is “where it makes sense.” To be brutally honest, one of the reasons I’m writing these posts is to try to counter the “up and coming” TDD consultant trend. Oh yes, the process consultants are moving on from Agile and are trying to make TDD a fertile ground for their inflated consulting fees. It is my hope that sharing some knowledge at this point with you my dear reader will help you to not get suckered in by a smooth talking process consultant; as far as I’ve seen these people are nothing but charlatans, preying on organizations that have failed to keep their staff engaged.

Proponents of TDD claim that it will reduce time spent on QA / bug fixing and generally increase the quality of our code across the board. Unfortunately, they’ve so far failed to provide any conclusive evidence that supports those claims across the board – to be fair, there are plenty of folks offering guestimated anecdotes but those are as dubious as they sound. What I want is something like the average project has X hours of bug fixing under normal circumstances, we spent Y hours doing TDD, spent Z hours bug fixing anyway, Z + Y is either greater than or less than X. From a practical point of view, I see no reason to bother with TDD unless Y + Z constantly come out to be less than X. It is for this reason, that I am currently tracking this simple formula in our TDD projects.

I’m also tracking a few other factors: platform, client-side, server-side, testing library, and the nature of the bugs that we still end up having to manually test. Though I’ve been doing this personally for a few months, I am still not prepared to release my full results.

I will, however, say that TDD (at least in my experience) is looking to be like Agile in that a little bit of a good thing is good but a lot can be terrible. I’ll also share a few more points. The first being that TDD for me has so far been a sunk cost in terms of time on the client-side – it is near impossible to really “test” visual elements without manually testing them. The server-side, however, has been a different story and far more positive. This makes sense, since the TDD folks tend to focus on its effectiveness for server-side platforms such as ASP.Net or Rails.

If you want to follow this series, please follow me on Twitter and add this site your RSS reader of choice.

Code Journal 1.3.0 Released!

Code Journal LogoI’m happy to announce that version 1.3.0 of Code Journal is now available for both direct customers and Mac App Store users.

This version brings a lot of UI refinements and I have taken your feedback very seriously and streamlined the user flows and functionality based on that feedback.

I hope you enjoy the app and please do not hesitate to use the feedback link in the app with any comments or concerns! If you haven’t picked it up yet, please find it at http://codejournalapp.com.

NSPredicate 100

Objective-C  and Cocoa (or more accurately Cocoa Touch) are seeing  surge in developer interest due in most part to the revenue potential of the iOS App Store. A lot has been made of Objective-C’s quarks and it’s true; like all other programming languages Objective-C has its oddities that might have made sense at one point but feel either strange or in some cases dated. Unfortunately, a lot of developers new to Objective-C seem to be having a lot of issues adapting to their newly adopted development stack, partly because they often try to wrongly apply concepts from other stacks to Cocoa inappropriately and partly because they just don’t know enough about Cocoa and the language to really work as efficiently as possible in the platform.  NSPredicate, in particular, is one of the classes that these developers simply do not use; presumably, because they are ignorant of it.

NSPredicate is designed to make searching sets of data based on constraints more efficient. Let’s look at a really simple example of how it might used:

NSArray* pokemon = @[@”pikachu”, @”charmander”, @”bulbasaur”, @”squirtle”];
NSPredicate* pokePredicate = [NSPredicate predicateWithFormat:@”SELF MATCHES @”charmander”];
NSArray* result = [pokemon filterUsingPredicate:pokePredicate];

Ok so what is happening there? We are defining a simple array of four strings. We are then creating a predicate based on the parameter of searching ‘SELF’ (a stand in for the objects that will be scanned themselves) with the parameter of ‘MATCHES’ (self explanatory) the object, in this case an NSString, ‘@”charmander”’. Some of you may be saying: ‘Big deal. I can do that with a for loop”. That’s correct. In fact, for this simple example the ‘for loop’ option isn’t too terrible:

 
for (NSString* aString in pokemon) {
if ([aString isEqualToString:@”charmander”]) {
NSArray* result = @[aString];
}
}

That works but is not very pretty. Additionally, Apple has put a lot into optimizing NSPredicate and in most cases for all but the simplest searches, NSPredicate will be significantly more efficient than any ‘for loop’ any of us could code.

That’s all well and good, but another great thing about NSPredicate is that it takes advantage of one of my favorite Objective-C features: blocks. That’s right, you can get the same search and filter power of NSPredicate but also be able to define your own filtering method via a block:

NSPredicate* pokePredicate = [NSPredicate predicateWithBlock:^BOOL(id evaluatedObject,
NSDictionary* bindings) {
BOOL passedYourTest;
// do some testing / comparisons
return passedYourTest;
}];

Ok so that does not return an array like the first example, but it does show one of the other most commonly used features NSPredicate: testing a group of objects against some arbitrary parameters. Why would you bother doing this sort of thing with NSPredicate rather than a more traditional loop? You guessed it! Apple has optimized NSPredicate, however, your custom block can definitely slow things down if you are not careful.

This is just a simple example of what can be done with NSPredicate and I hope that at least some of you will take a look at the class’s documentation and give some thought as to how you can optimize and make your code more elegant with the help NSPredicate.  Comments? Questions? Find me on Google+ or Twitter.

Can You Parse My Backend

As developers most of us have had an idea for an app (mobile, web, desktop, or whatever) but just haven’t had enough time to configure and fiddle with a backend stack or system. I mean come on who wants to dedicate 200hrs+ to a proof of concept. Well, I have been working with a nifty little tool called Parse. Parse is a backend in a box so to speak. Basically, you create an account log into a dashboard and start entering data into a spreadsheet; you can even upload a CSV if you like. Best part? Parse has SDK’s for iOS and Android and also has  a REST API that can be used with anything that understands JSON.

Let’s take a fast look at a common use case: you need to authenticate an iOS user via Facebook:

- (void) ourMagicalMethod {
	[Parse setApplicationId:@"SOME_ID" clientKey:@"Your Super Secret KEY"];
	[PFFacebookUtils initializeWithApplicationId:@"SOME_FB_ID"];
	NSArray* permissions @["desired permissions"];
	[PFFacebookUtils loginWithPermissions:permissions block:^(PFUser*     user, NSError* error) {
	// your epic logic goes heres
        }];
}

You can also find this code snippet here.

What’s that you say? You like your code more robotic? No worries. I have you covered with an Android sample:

public void yourMagicalMethod() {
	Parse.initialize(this,"pID" "pKEY");
	ParseFacebookUtils.initialize("fbId");
	ParseFacebookUtils.login(this, new LoginInCallback() {
		@Override
		public void done(Parse user, ParseException err) {
			// your awesome logic
		}
	});
}

Again you can find the snippet here.

With those two snippets you have either created a user in your Parse database if one did not exist for that Facebook account or logged the existing one in. Now that’s not to say that Parse can replace a real custom backend, but for prototyping when time is of the upmost importance or if your resources are severely constrained, it just may do the job.

Got feedback? I’d love to hear on Google+ or Twitter. Also, if you enjoy my work, please consider purchasing Code Journal wither form the Mac App Store or direct. All the snippets you see here were written using Code Journal.

Thanks JB Community

If you listened to Coder Radio this week you would have heard toward the end that I have been working on a project targeted for the Ubuntu App Store. You will have also heard that I ended up choosing Mono as the development stack for the project; I plan on writing a post in a few weeks on my overall experience with Mono on Ubuntu and plan to mention it on a future episode of the show.

Needless to say I had some problems, but that’s not really the point of this particular post. The point of this post is to thank all the Jupiter Broadcasting community members for all their help. I have received countless e-mails and messages on Google+ regarding the issue. All of them offered suggestions of how I might solve my issue. Some even offered to either help me write a solution or offered to share how they had solved similar issues.

I’m floored. I wish I could write you all back individually but there are simply too many of you. So, please take this post as a thank you letter. Furthermore, in the spirit of community, I am going to open-source whatever solution I end using and will be posting it on Github as a more substantial way to say “thank you.”

The Problem With Religion (In Software)

As engineers we generally strive for the simplest most elegant solutions to the problems we encounter in our work. Though we may not agree on what systems or frameworks are elegant, we tend to look at things from a fairly objective perspective. I believe that it is that focus on objective quality that has allowed our industry to make the startling advances it has in  the last twenty to thirty years. Think about it. You probably have a computer on your desk or in your pocket that is more powerful and more useful than the machines of the seventies and eighties that would have taken an entire room to house. I was disappointed to hear one of my former heroes decry the state of modern computing in rather exterme terms. Basically, Richard Stallman has come to believe that all non-free software is evil (his word not mine) and should not be developed or used even if it is far superior to a free alternative or even if a free option does not exist.

Computing has advanced to where it is in a relatively short amount of time because of pragmatism, not zealotry. Because smart engineers built what they felt was the best software for their problem domains. More often than not the tools and products they developed were proprietary. One of most obvious modern examples of this is the iPhone. Whether you like it or not mobile computing would not have advanced to where it is today had Apple developed the iPhone or iOS. It is true that iOS is one of the most closed proprietary systems to date, but that does not mean that it is not important. In fact, it is arguably the most important system in the mobile / tablet computing space.

Imagine what mobile computing would be like if everyone had to write their drivers for each specific piece of hardware, then attempt to hack a Linux or BSD distro onto their device, and write custom software for handling telephony and other regular smart phone actions (e-mail etc).  This generally what you would have to do today to install a “free” phone. Keep in mind that every-time you got a new phone or tablet, you’d have to go through all or at least a good part of this process again. What about non-engineers? You users. People who can’t figure out the basics of setting up their e-mail on iOS, let alone compile a kernel. Should they be frozen out of the mobile computing revolution.

Isn’t better to have something that works for a large number of people with little to no technical expertise on the part of the user, rather than have something that only an elite few “hardcore” people can use?

Would we even have the features and capabilities that we have grown used to if it weren’t for commercial interest pushing the envelope of technical innovation? Pragmatism is not a dirty word as Stallman and other freedom zealots would have you believe. We should do as those who came before us have done: use the best tools for the job and take advantage of every resource we can, even if they are not free. Innovation requires that level pragmatism and proprietary software does not need to justify its existence; history does that.

Hello world!

Welcome to blog.mdominick.com this is a continuation of my personal software development blog. Older posts can be found at http://codingonthetrain.tumblr.com/. Stay tuned.