Tag Archive for programming

Pallet Town: Giving Into Javascript Classes

Coder Radio listeners will know that I have some strong feelings on classes in Javascript and most of them are pretty negative. After some extensive time (measured in years) of exploring alternatives to pure Javascript such as CoffeeScript and Typescript, I ended up going back to pure Javascript but remained Typescript curious. That takes us to the present day. I find myself working on a very large, feature rich, and complex Javascript codebase that other people will eventually be working on with me. I’ve long railed that classical inheritance has no place in Javascript, but the reality of the situation is that it makes sense for some use cases and (a much more severe issue) most developers you’d hire out of school and sadly many more experience ones have no frame of reference outside of the classical OO as seen in languages like Java and C#.

Presented with this combination of issues, I naturally looked to include some Typescript classes in my code for some underlying data structures that the software is going to rely on. Unfortunately, I hit a pretty fast issue — require statements. My code base is based on Node.js and uses require heavily. In simple cases, that’s no problem in simple cases:

var Pokemon = require('pokemon') // Javascript

import Pokemon from 'pokemon' // Typescript

That’s not so bad, but things can get a little less elegant very fast. For instance, let’s say you’re using MongoDB and importing it via require:

var MongoClient = require('mongodb').MongoClient

There are of course ways to do this but none of them were elegant and simple enough for my tastes. As an aside, if your application uses MongoDB via the Mongoose driver, then you’re good to go with this Typescript statement:

import * as mongoose from 'mongoose'

My application, however, is using the Mongo driver directly and for some business specific reasons this was not an option, so I said ’so long to Typescript’ for this project and looked for another solution to my classical OO problem.

The solution I landed on was using the class functionality introduced in Javascript in ES6. Let’s take a look at a sample of what this might look like assuming that were are working on a Node.js based application that needs to pull in Mongo in the same way that my real world one does:

// importing Mongo
var MongoClient = require('mongodb').MongoClient;
var mongo_url = 'some_url_for_database_access';
// class declaration
class Pokemon {
	constructor(name, type, level) {
		this.name = name;
		this.type = type;
		this.level = level;
	}
	
	save(callback) {
		let pokemon = this;
		MongoClient.connect(mongo_url, function (err, db) {
			if (err) throw err;
			db.collection('pokemon').insertOne(JSON.stringify(pokemon), function (err, result) {
				if (err == null) callback();
			}); 
		}
	}
}
module.exports = Pokemon; // exporting for use elsewhere

That’s a pretty simple implementation but is enough to get a good idea of the basic structure of Javascript classes. One aspect that I am finding interesting about working with them is that it’s possible (and as far as I can see a good practice) to use them as sparingly as possible, hopefully avoiding the deep coupling between classes that tends to occur in large scale applications written in a classical OO style. So far, my thinking is that these types of classes are appropriate for base data structures that your application relies on, but the majority of your code should be written in a more functional style.

I hope this helps and if you want to reach out please find me on Twitter and if you’re interested in seeing something cool pretty soon check out The Mad Botter.

Google Kotlin!

Google announced that the Kotlin programming language will now be a first class citizen alongside of Java for Android development. Since Apple had announced Swift as the replacement for Objective-C as the iOS app development programming language, there’s been a lot of speculation on what Google might do in response; some commentators even speculated that Google might also go with Swift. Google has now made their move and it’s a really smart one. Coder Radio listeners will know that I’ve been a long-time fan of Java, but I have to say if there’s going to be a successor to it, then Kotlin seems like a great choice.

For starters, it targets the JVM. That means that Kotlin code can be run on a wide variety of architectures and devices. For the purposes of Android development this was essential, since Android uses a “version” of the JVM; there’s been some legal cloud about what exactly Google’s Davlik VM was a bit too much like the JVM for Oracle. If you’ve never had a “standard” disappear on you, then you might not understand how much of risk there is in technologies simply evaporating into the air, leaving you and your users high and dry.

Speaking of the longevity of technologies (especially in the enterprise), Kotlin targets Java 6. What that means is the there’s a huge pool of enterprise Java applications that it can work on today using its interoperability with Java. In practical terms, this means that there’s no need to rewrite your legacy Java application to start writing modules in Kotlin.

Java can be a little strict in terms of checked exceptions. Basically, in Java, if there’s a possibility to throw an exception it must be checked with a try / catch block. In larger projects this makes you’re code pretty verbose and I’ve long found this to be one most annoying aspects of Java day to day. Kotlin does not have checked exceptions, giving you more flexibility in how you write your code and reducing all around cruft.

If you’re an Android developer or just a Java developer in general, I urge you to take a look at Kotlin and form your own opinion. Also, if you’re interested in learning more about Docker or DevOps in general, take a look at my Docker Compose Quickstart Guide and follow me on Twitter!

4 Must Listen Podcasts For Developers

Software development is a fast moving profession and it’s near impossible to stay up to date with all of the changes, new libraries, and great open-source projects that are coming out on what feels like an hourly basis. That’s where great podcasts come in to keep you not only up to date on your development specialty but also give you an understanding of what is going on in other areas of the industry, so you remain a well rounded technologist. In the interest of fairness, I am going to exclude my own show Coder Radio from this list but I would of course encourage you to give it a shot as well as all of the other great Jupiter Broadcasting productions. So here are my five must listens in no particular order!

Linux Action Show: Though this is more of a general Linux development show, it’s the best source for Linux coverage on the web today. Even developers who aren’t focused on the FOSS / Linux space, should at least listen to LAS to maintain a level of knowledge on the platform to hold up a casual conversation with a Linux-focused developer.

The Bike Shed: Focusing on web development with a specific focus on Ruby, Rails, and all things JavaScript, this show gives a good overall look at the web development landscape from the perspective of developers working at a high-end development consultancy — the show is produced and hosted by members of the Thoughtbot team.

.Net Rocks: This is one of the classic developer shows and it’s still great. Even though I imagine that many of you reading this aren’t work on .Net / Microsoft technologies, this show will still manages to be accessible. This is an absolute must listen for those of you who may have some prejudices or just simply be out of touch with what is going on with Microsoft developers.

Accidental Tech Podcast: ATP is a show hosted by some very deep and thoughtful Apple fans who also happen to be developers. I’m positioning it that way, because like LAS, ATP isn’t designed as a developer show, but they do often showcase development topics. I find this show especially valuable, because I rarely agree with the hosts when it comes to development topics or their general outlook on technology as well as what makes software valuable. It’s this challenge to some of my held beliefs that I find valuable and while my outlook has continued to diverge from theirs, there is still tremendous value in being challenged and I recommend that all of you subscribe to at least one show where your options will be challenged.

One More Thing: OK, so I told you there’d be four but I have a fifth. I just launched a YouTube Channel that focuses on open-source and mobile development tips for the enterprise sector. I hope you’ll check it out!

There you have it – my four must listens and a bonus! Let me know what you think on Twitter and take a look at my company Buccaneer Tech INC!

 

 

 

Three Tech Wishes for 2017

Happy 2017! As we put 2016 in the rearview mirror, we’re all taking a look at the outlook for 2017 as I did here but I wanted to take a more personal angle here and explore what I desperately want to see from the tech community. This list is by no means exhaustive and for the sake of time (and online attention spans) I’m limiting it to my top three.

Google Account Management: Dealing with multiple Google accounts is an unfortunate and annoying fact of life for me both as a regular user and as a developer. In this year alone I’ve probably written thousands of lines of code for myself and for clients to deal with this problem by basically scraping calendar events between two or Google accounts. The business case for this problem is pretty simple. Company A gets a contract to do some work but they don’t have the resources in house, so they subcontract part (or all) of the job to Company B, but Company A doesn’t want the client to figure out that Company B exists and is actually doing the work, so they give all the Company B people Company A Google accounts. My event scraping solution is sloppy and fraught with all sorts of little issues. Google should find a way to implement some sort “vanity account” system that let’s the actual email addresses be masked between multiple domains, so that the customer sees what Company A wants them to, but Company B doesn’t have the overhead of dealing with yet another GMAIL account.

Reactive Programming Hype: A lot has been made of Reactive Programming in 2016. While there is definitely some fire to the smoke, things are getting way too hyped and frankly I’m seeing Jr developers pitching reactive programming on freelance gigs as some sort of silver bullet that will solve all the problems you have have and even ones you don’t know you have yet. This is scary! Sure there has always been hype around “new” (sneer quotes because Reactive Programming is only new from a ‘certain point of view’) technologies and methodologies but this hype train around all things with the word or root ‘react’ in them has the kinetic energy of ten hydrogen bombs. I’ve gotten too many projects in this year from prospective clients that were over-engineered in one of these reactive libraries by some Jr dev who just got a little too excited on the Kool-Aide sales pitch and the story is sadly all the same – the client was happy with what he was told but what he got was a steaming pile of hard to reason about spaghetti code and ultimately a rewrite. For 2017 let’s just pull the cord a little on the hype train, OK?

Docker Direction: Despite some fairly significant pain in upgrading between Docker versions and other more minor issues, I am still a serious believer in Docker as the premier containerization solution. Coder Radio listeners will remember that even as a callow youth I was on the Docker train right from the beginning but my faith has been somewhat shaken and I’d like some clearer communications regarding where the technology is going, who they feel their ideal target users are, and where Docker the company sees its role beginning and ending — in other words where will they and where won’t they compete with vendors who are selling / implementing Docker.

Those are my three (I hope fairly doable) wishes for 2017, but before I go…. I also want to note what I didn’t mention here that I have in my end of year / new year posts for the last years – App Store monetization and more specifically a sign from Apple on where they see that going. We got our answer in 2016 – subscriptions. While that will work for a number of apps and is working fine for my Backpoints (iOS & Android), it does not satisfy all the needs of independent developers and likely will not create the high-value ecosystem of professional paid (paid defined as taking money in any non-donation way) software that the iOS App Store originally enjoyed. When I think about Apple and their answer to the monetization issues on the App Store, I am remained of that great quote from Dan Brown’s Angels and Demons: “God answers all prayers, but sometimes his answer is ‘no’.”

Pallet Town: First Steps to Functional

I’ve been taking a deeper look at Functional Reactive Programming in the form of RxJavaand ReactJS. While I am still at the early stages of really looking at this and forcing myself to actually work in these technologies that I’m still no really sure make a lot of sense for my use cases (more on that at a later date), I was taken aback by the simple usefulness of the “Functional” part of the equation. At the risk of grossly oversimplifying the benefits of functional programming (or at least adopting a more functional style in your object oriented code), there is a ton to be gained with just a little bit of re-thinking of how you think about the relationships between your objects and how you structure your methods. This is because one of the main benefits of functional programming is that it minimizes state and therefore unintended side-effects. Here are the two quickest and easiest ways to improve your code today using a more functional mindset.

One Function == One Action:” Every function you write should do one thing and only one thing. Let’s take a very simple sample of what this should look like:

public Pokemon getPokemon(int id) {
	Pokemon  myPokemon = PokemonStore.getById(id);
	myPokemon.setType("fire");
	PokemonStore.save(myPokemon);
	return myPokemon
}

The Assumptions in that are that we have some PokemonStore class that is effectively an ORM for your Pokemon. That’s fine. The issue here is that our ‘getPokemon’ function doesn’t just fetch us the correct record by id as you would expect it to. Instead it updates it ‘type’ property and reserves the mutated record to the datastore before returning the record. This is obviously terrible on a number of levels but looking at it from a functional point of view, the primary sin is that it does three things (getting a record, mutating a record, and saving a record) rather than just one and what it does doesn’t match the method signature. A better version of this method would have mutating the type in another method and simply return the record:

public Pokemon getPokemon(int id) {
	Pokemon myPokemon = PokemonStore.getById(id);
	return myPokemon;
}

As you can see that’s easy to read, does one thing, and there’s little to know risk that a future developer won’t understand what the method is supposed to do.

Deterministic Outputs: A method given the same inputs should always return the same outputs. If that’s not true, then you likely have too much coupled state in your code that is causing unforeseen issues. This is a great example of what not to do:

public Pokemon getFirstPokemonInRoster() {
	List<Pokemon> roster = User.CurrentUser().getRoster();
	Pokemon starter = roster.get(0);
	return starter;
}

There’s a lot not to like in this method. For starters it relies on the start of a Users.CurrentUser() singleton, which instantly creates couple state. Another issue is that it’s not very flexible — is it really true that we will only ever care about the current user’s roster? Finally it’s not written in a way to be optimized for easy BDD / testing and violates the functional principle (or perhaps guideline) of passing in the objects / values a method needs to run into the method directly rather than pulling them from another place. Here’s a minor change that addresses all of those issues:

public Pokemon getFirstPokemonInRoster(int userId) {
	User user = UserStore.getById(userId);
	List<Pokemon> roster = user.getRoster();
	Pokemon starter = roster.get(0);
	return starter;
}

As you can see, the revised method can now the pull the roster for any arbitrary user and does not rely on a user singleton. You can easily imagine a test being written that passes in a valid user id to test the golden path for this and also another test with an invalid value for the userId paramater; incidentally, my method still doesn’t handle that case, but there are multiple ways you might do that and catching that sort of thing is really what automated testing is for ;).

I hope you’ve found this helpful! If you have any questions or comments, please sound off below or on Twitter.

Bye MacBook, Hello Lemur!

Apple is widely believed to be releasing new Macs next week and I am celebrating this long overdue update to the MacBook Pro by replacing my existing MacBook Pro with a Linux laptop from System 76. This isn’t one of those “Apple sucks posts” but I did want to go over briefly why I find myself moving away from Apple platforms and in to the open-source arms of Ubuntu Linux for my production needs but am still firmly entrenched in the i-ecosystem for my content consumption and light office productivity needs. Generally speaking, I am making a bet that the puck is going toward Linux powered AI.

Let’s start with content consumption. I ‘own’ over one hundred and eighty movies in iTunes, over fifty albums on iTunes, and a family subscription to Apple Music. I also have a number of newspaper and magazine subscriptions that just frankly have far better user experiences on iOS than Android. Basically, I’m pretty highly invested in the Apple content ecosystem, so moving away from Apple totally would be costly and more than a little wasteful. Also, I am pretty happy with the Apple TV / iOS devices / iTunes setup.

There’s also the issue of time’s insistent march on. iOS and mobile platforms in general are extremely mature. That’s great for users but less than exciting to me as a developer. Don’t get me wrong I still love iOS and Android development, but it’s just not that exciting or bleeding edge anymore. The sad fact being that both those platforms are very mature and most apps are just re-implementations of commonly accepted design patterns; that goes doubly for those that are clients to relatively simple REST APIs.

Going forward for the next five to ten years, I think there’s going to be some serious action in the field of AI or ‘bots’ if you prefer. In my opinion most of the most significant innovations are going to be on cloud-based Linux servers that power these pieces of software. Of course mobile platforms will likely be the most common front-ends for this type of software, but my guess is that will be in a more limited thin-client capacity. That’s the bet my Twitter followers may have figured out that I have been working on some side AI bots for months now and that’s where I think this is all ultimately going.

Let me know what you think especially if you think that I’m crazy! If you’re curious, the laptop I went with for my MacBook replacement is the Lemur by System 76. The Lemur joins my home office’s Ratel as the second machine in my growing Linux / System 76 fleet.

Slack-pocalypse Now

Slack is reducing my productivity and is almost certainly having a material negative effect on my day to day performance as well as my job enjoyment. Things started so well with Slack and I and I still love the vision of reducing email but something’s change, something’s been twisted….

In the beginning the initial goal of Slack was to make team communications easier and cut down on useless (or at the lest nonproductive) emails. I am happy to say that for the most part that’s happened for us internally at Buccaneer; in fact, we have almost zero internal email threads in a given week that aren’t forwarding something from a customer-facing person to someone else and even then most of that is handled in Slack as well. That’s great!

Then Slack added guest accounts, single channel accounts, and the ability to have multiple accounts on one Slack client and what was a great internal communication tool became the customer service portal from Hell. I can see how the folks over at Slack thought they might reduce the strain of customer communications just as they had internal communications. Possibly they thought Slack chats might replace daily stand ups, weekly status meetings, or “checkin emails”. Sadly, they were mistaken. Due to the expectation of virtually immediate response on Slack, it actually makes these problems worse.

In terms of daily standup (which I will go to my grave claiming is pointless in a group greater than six) Slack is treated as “in addition to” rather than a “replacement for”. Same problem for weekly status meetings.

Though it’s the daily (or worse “build”) checkin email that Slack has truly perverted , twisting it into a nightmare that leaves me muttering “the horror the horror” at the end of every sprint. The beauty of the checkup email and email in general is that it’s socially acceptable to not reply immediately. Indeed, one of the best ways to respond to those sort of things for me was to wait until I had something positive to say or respond by EOB whichever came first. Just a few hours can make what might be a bad or awkward conversation into a good one and email allowed me to manage my time in a way that I could find those hours with no more (and sometimes not even) a “I’ll follow up with you by EOB”. Thanks to Slack, the conversation goes a little more like:

Get enough of these and you’ll be dreaming of the halcyon days of once weekly conference calls and formal EOB update emails.

Don’t get me wrong. I am not against open lines of communication but sometimes things take time and you want to craft a more sophisticated response than you can get when being barraged by messages. Of course from the sender’s perspective Slack is a form of instant messaging with an emphasis on the instant as in NOW part. Unfortunately, responding to even the most cursory of messages requires a context switch and any experienced developer will tell you that’s a productively killer.

What Slack needs is a more aggressive version of their current Do Not Disturb feature. One that not only warns the sender that you are not available but that actively says you are busy. This is something that HipChat, an Atlasssian competitor to Slack, has had since before Slack was even around. On HipChat if you mark yourself as busy, it puts up a red logo that looks like a traffic sign and actively warns any senders that they are probably interrupting you by messaging you. The difference may seem subtle if you aren’t like me and used HipChat for a long time before Slack, but in terms of communicating your status to your team and any customers in the system, HipChat is clear — away really means away, available really means available, and busy means leave me alone I am working.

What do you think? Is it just me? Find me on Twitter and let me know. Also, do fill out the contact form on this page, I am a 50% promotion for getting new hybrid app development projects started. If you’ve been thinking of getting an app for your business or even just have an idea you want to validate, there’s never been a better time to reach out!

Swift on Android

SwiftRumor has it that Google may be considering making Apple’s Swift a first class language for Android development. Predictably, the internet has been pretty excited about this possibility. My lack of enthusiasm for Swift has been fairly well document, so I’m going to keep my comments to a minimum.  Swift on Android shares the same API problem as Swift on iOS and this likely has more to do with legal wrangling than technology.

Java and Objective-C are very object oriented languages and the Android SDK and Cocoa Touch APIs reflect that. Swift is a far more functional language than either of them. “Good Swift”, which I have been told is functional and not just “Objective-C in Swift” doesn’t really go so well with a OO designed API on Apple’s platform. Why should that problem not exist on Android as well? Maybe Google and Apple will rewrite their SDKs to be more functional, but that’s not where they are right now.

Oracle is suing Google and has been suing Google for Android’s use of the Java programming language, which Oracle acquired in its acquisition of Sun. The lawsuit is ridiculous and a destructive waste of resources, but that’s a pretty fair description of the US legal system, so it is likely to continue to be an ongoing concern for Google. If Google were to stop using Java on Android, that might put them in a better position regarding the suit and it’s pretty clear that the licensing on Swift would prevent any similar issue from cropping up between Apple and Google.

Yes, I’m admittedly bias, but it’s important to think about the practical and ulterior motives that Google might have for adopting Swift and not just blindly jump aboard the hype train. Swift is a decent programming language, but it’s not the right solution to every problem and we should only make changes when it makes sense to do so. Let me know what you think on Twitter or Google+.

The Year of Xamarin Development?

1423190333_thumb.pngXamarin may now be a viable tool for cost-efficient hybrid app development since it’s recent acquisition by Microsoft.

The current app marketplace is highly competitive and as the general startup market cools in

terms of funding, launch runway for apps is going to be even more important to early stage startups. Xamarin may allow cash-strapped startups to leverage code-reuse and the large pool of global C# developers while targeting both iOS and Android.

In general, developing an app natively for both platforms will nearly double the cost of client-side development and require a team to staffed with developers well-versed in Java as well as

Swift / Objective-C. Even with today’s outsourcing resources, the cost of this duplicated effort can stretch the budget of many startups.

Microsoft’s challenge will be finding a way to keep Xamarin attractive to mobile developers ontoday’s leading platforms by keeping up with the innovations and platform updates brought by future iOS and Android versions. They have to not only keep up with Apple and Google but also attract developers to develop apps for Windows 10, something that has to date proven near impossible.

 

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!