Archive for Programming

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!

Hybrid Today, Progressive Web App Tomorrow

App (and I am using that term very loosely here) development has undergone a change. Most companies are eschewing high cost native development and for iOS and Android and going with hybrid solutions using tools like Xamarin or Ionic. This is a great way for organizations to lower their initial development and ongoing maintenance costs as well as get a useful app for their business needs. One area that many organizations are finding is that they still need desktop web applications and you don’t get the code sharing advantages between mobile and desktop platforms that you do between the two dominant mobile platforms – iOS and Android. Luckily, the march of development tools and frameworks has carried on and there’s a new solution – progressive web apps. These are web applications that live on the server but thanks to powerful JavaScript (or in some cases Typescript) can access native-like device capabilities. This, coupled with responsive development techniques and some adaptive CSS allows the app to scale in not only screen-size but also capabilities depending on the device. There are a number of frameworks that provide this, but my two favorites are Angular 4 and Polymer 2.

The Angular team now uses the tagline “one framework, mobile and desktop” and they mean it. Angular has come a long way from the original release of AngularJS and is now a full application development framework.  Currently, Angular is on version four and if you’ve used an older version of the framework you’re going to find major differences (especially in the area of routing) but the time invested into catching up is well worth it. Using Angular 4 you can now create a high-functioning application that runs on everything from your twenty-seven inch desktop screen all the way down to a mobile phone. I do find that there’s a bit more ceremony in the latest versions of Angular than in the first, but you could argue that’s an advantage, since it also makes the framework more flexible than its predecessor.

Polymer 2 is more focused on JavaScript components than Angular but is no less powerful. While the details of it works under the hood are different the end result is exactly the same — you end up with a powerful application that can scale for different screen sizes and devices.  If I had to make a comparison between Angular and Polymer 2, it would be that the Polymer team has made more of an effort to be “pure JavaScript.” I don’t love that criticism of Polymer for two reasons: 1) Angular is now written in Typescript and I (in my opinion) best consumed using Typescript and 2) some of the custom directives in Angular actually lead to less boilerplate than the more “pure JavaScript” alternatives in Polymer (especially around defining custom components), so I’d actually consider that a feature for Angular rather than a bug. Still, that doesn’t mean that Polymer is not a great choice for your progressive web app development needs.

There are of course other choices for developing progressive web apps but these two projects have the backing of Google and large communities around them, so they’re likely going to stand the test of time unlike the many <insert_noun.js>  JavaScript frameworks of the previous ten years.  The future looks bright for the progressive web app and by extension Angular and Polymer, given that the trend of businesses demanding more for less out of their developers and development partners is likely to continue.

If you liked this post, follow me on Twitter for more!

How I Missed Web Assembly

As pointed out by an intrepid Coder Radio listener, I totally missed the importance of Web Assembly when it was in its initial nascent phases a year or so go. Now that Web Assembly is going to become a standard endorsed by the W3C and has backing from at least two major browser vendors to date (Google and Mozilla), I’ve done a full 180 and am convinced it is the future of not only web development but probably a good deal of mobile and desktop development as well; my assumption is that tools like Ionic and Electron will be able to leverage the performance gains brought by web assembly as well.

Looking back my mistake was that I failed to parse out the signal from the noise in the wider JavaScript conversation circa 2014 and on. There was (and in many communities still is) a lot of angst about the short-comings in the JavaScript language and a lot of people making noise about using alternatives to it that would simply compile to it –  CoffeeScript and TypeScript for example. There was of course a thread in the background about Web Assembly becoming potentially a language agnostic solution to this problem, but because I was looking at it through the lens of alternative languages to JavaScript and at the time didn’t think and I still don’t think  that changing from JavaScript just because you want a different language but then compiling into JavaScript makes any sense at all. In other words, I took a breathe and shouted a hearty “get off my lawn!”

My curmudgeon-like tendencies aside, I still firmly standby the idea that just writing in something like CoffeeScript to compile into JavaScript just because you don’t some features or shortcomings of JavaScript is silly. What I missed was that this whole language brouhaha was just a minor prologue to the real story — Web Assembly. Moving to Web Assembly not only increases web application performance significantly but also (as more languages create compilers for it) gives those developers who prefer some language over JavaScript a much more reasonable choice; they can simply use the language of their choice and compile it directly to Web Assembly! I’m totally on-board with that. In fact, I’ve been working in Microsoft’s TypeScript and find it great, so if we actually make it (we probably will) to this Web Assembly world, then I’ll probably go Typ eScript for most greenfield projects going forward.

As in Eden, there’s a potential snake in our garden — Apple. Web Assembly being fully supported on mobile Safari for iOS is absolutely necessary to unleash the full potential and development efficiencies that I believe Web Assembly can over the next five year period bring.

Questions? Comments? Blood curdling nerd rage? Tweet me! Also, take advantage of my free strategy session for your next project!

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.

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!

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.

 

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!