Angular and Python Are Marketing Wrong

by Stephen Fluin 2015.05.16

Over the last several years, developers around the world have been gently nudged to updated the version of Python they are using, and Angular is poised to do the same.

A new version, a new direction

Python 2.7.9 is the default used in Ubuntu's latest version. This is somewhat discordant with the fact that the latest version is actually 3.4.3. With Python 3, the creators of Python were trying to improve the language dramatically by refocusing on what was important for them in a language. The problem with this approach is that they broke backward compatibility, and left Python 2.x in a state where it was easier for developers to keep using the older version than to update to 3.x Python 3 was introduced in 2008! That was 7 years ago and developers still are reluctant to switch.

Angular is headed in the same direction, with their current work on Angular 2. Angular 2 (just like Python) breaks compatibility with the old version, introduces new language constructs, and tries to achieve a set of admirable goals including performance and simplicity. The problem is that they are trying to introduce too many things at the same time. To migrate from AngularJS (Angular 1) to Angular 2, the user has to learn and implement a number of changes to both the language they use to write applications, as well as to the toolset they use to build and deploy their applications.

The problem with Python 3

I may just be a terrible developer, but from my perspective the problem with Python 3 is that they got rid of all of the convenience tools included in the the language. Everything from the print statement to the way that you interact with files was dramatically changed to handle Unicode and edge cases better, but from my perspective this made the new language better at edge cases, and worse at nominal cases.

The problem with Angular 2

Angular 2 is headed down a similar path, with developers already groaning about having to do things a different way. While I believe each of the changes in Angular 2 were made for good reason, it's too much at the same time for the average developer to understand.

Take a look at all of the new things a developer has to do or think about

  1. Switching from Javascript to ES6 OR Typescript with compilation - Even if you don't want to switch, Angular 2 was written in Typescript, and most of the examples that exist today are Typescript examples. If you ask the average developer what the diffrences between Javascript, ES6, and Typescript are, they would have a lot of trouble explaining it.
  2. Shift to Components - Now instead of grouping controllers and views into their respective structures, everything is broken into components, where the view and corresponding controller live together. This a structurally benficial change, but it once again assumes you are building a complex application, and increases the work to simply get started.
  3. Loss of Directives - Directives have disappeared and been replaced by Components and Directives (which is a type of component). This confusing terminology
  4. Loss of Existing Libraries - Because of the change in formats for Components and the loss of Directives, the huge number of AngularJS modules available on the internet are made useless for these types of projects.
  5. Double Binding Magic is gone - There's a magic moment when a developer connects an ng-model to a variable in the view. With the new Component model, this magic is gone because it feels like you have to create the wiring yourself, and your application will require more code just to get started (although in fewer places).

The Solution

From my perspective, the solution is simple. Eliminate the frustration and fears related to the migration path by designing, building, and marketing these "major revisions" as new languages.

Developers are used to and often excited by the adoption of a new language of framework. When a major revision with breaking changes is created, developers have to conflate their positive feelings about the past framework with the additional time, energy, and cost related with updating their knowledge and skillsets, without the corresponding buzz coming from the adoption of something new and exciting.

Perhaps if we had Cobra and Nentr (names I have made up for Python 3 and Angular 2 respectively), developers would be able to evaluate these languages on their own merits, rather than being forced into a "upgrade or be left behind" mentality. 


permalink

#ios2weekchallenge Initial Thoughts

by Stephen Fluin 2014.10.25

Two weeks ago today I embarked on a journey to switch to an iPhone 6 as my daily driver.  It started off a little rocky with a trip to three different T-Mobile stores in order to get a SIM card. The first store was out, the second store wanted to charge me for them. Luckily the third store was able to give me one and suddenly my phone number and universe was driven by an iOS device.

Rather than go into a long narrative, here's a list of the pros and cons I have experiences.

Cons

  1. Swiftkey for iOS isn't ready yet. It has no number row on the keyboards, it has no voice recognition, it has no rapid/accuracy selector.
  2. iOS custom keyboards aren't ready. It's a hugely jarring experience to be using a custom keyboard and to be dumped back to the iOS standard keyboard for password prompts.
  3. Notifications suck. On Android, Notifications drove my entire mobile workflow. With iOS this feels impossible. There's no way to interact with  many notifications quickly. You have to launch an app, interact, then jump back to the notifications. They need quick actions really badly. I have no idea how their wearables are going to work without these.
  4. Google Apps aren't as good on iOS. Most notably, you can't click on phone numbers in emails. What?!
  5. Where are the wearables? I've gotten used to a buzz in my pocket causing a corresponding wrist or head nod to take a peek at what's going on. With iOS I know the Apple watch is coming, but today I still have to pull the entire device out of my pocket (by which point the notification is gone) and take a peek.
  6. The iPhone 6 is slippery! I'll post a video later, but hold an LG G3 or a Nexus 5 in one hand and an iPhone 6 in another. As you start tilting your hands, the iPhone is going to drop to the floor first. This matters because some acrobatics are required to interact with a 4.7 or 5.5 inch phone. My 5.5 inch LG G3 makes it easier to touch the top of the phone than the 4.7 inch iPhone.


Pros

  1. Epic Camera. The iPhone 6 camera is the best smartphone camera I have ever used. Night time, day time, it's fast and reliable. I would LOVE to see this camera on every phone I ever use again.
  2. Touch ID is great. Finger prints are a surprisingly good security mechanism. I always took pleasure in using it, it's basically just fun. The only glitch is that it goes a little bit slower sometimes.
  3. Apple Pay is awesome. I've used Google Wallet for years, but Apple has done something amazing. Not only do they have broader support (banks!) from partners, but the experience of using your fingerprint for authentication in combination with a simple tap (even from the phone being off) is much better than having your Android phone on and unlocked prior to making a transaction.
  4. Weight and slimness of the device is highly desirable. There's no Android phone this fast, slim, and light. Which is nice, as long as it doesn't bend, :).

permalink

Trekking Across Bulgaria #throughglass

by Stephen Fluin 2014.08.30

I'm currently travelling in Bulgaria, wearing Google Glass the entire time. There are a lot of interesting reactions, one of the most unexpected was another traveler inside the monument known as Buzludzha that I visited. I was standing in the middle of the inside of the monument trying to take a photosphere, and I hear from behind me, "is that Google Glass?".


permalink

Create Your Own Mobile App Privacy Policy

by Stephen Fluin 2014.06.08

One of the necessary evils of the world is the use of a Privacy Policy when you develop a mobile application. You probably aren't going to hit everything if you write your own. There are a huge number of paid services out there, but the complexity and lack of transparency from those services can be very frustrating.

After some searching, I found a service that provides free access to a template that can act as the basis for your own privacy policy. It even guides and leads you through the process of modifying and customizing the policy to your needs.

Check it out here: http://www.docracy.com/6513/mobile-privacy-policy-geolocated-apps-


permalink

Chrome Cordova Apps - cca create bug

by Stephen Fluin 2014.05.30

Failed to fetch package information for org.apache.cordova.keyboard

If you have experienced this error, you aren't alone. Any projects being created with version v0.0.11 of Chrome Cordova Apps (cca) are now failing to be setup properly.

The change comes from a desynchronization between Cordova's plugin library and the cca tool. This has been fixed by the developers in the latest source code on Github, but not released as part of npm.

The easiest way to get around this bug is to edit

/usr/bin/cca

, and change line 53 from:

'org.apache.cordova.keyboard',

to

'org.apache.cordova.labs.keyboard',

After that, cca should work just fine again, allowing you to create new projects.


permalink
View All Articles