Javascript Fatigue? Or something more?

There has been a lot of talk recently about a phenomenon called “Javascript Fatigue”, whereby developers are getting confused and worn out trying to keep up with the slew of new tools and methodologies when it comes to developing Javascript.

The problem is they are right, especially when it comes to the tooling. We’ve suddenly gone from a couple a javascript files included into our html to needing to do the following:

1. Decide what type of new, cutting edge version of JS/ES you are going to write in
2. Figure out what combination of Babel + plugins will work properly with this version
3. Build your package.json and figure out what dependencies you needed
4. figure out the correct Babel config that will compile your code
5. once you’ve compiled your code, you need to compile it again so that the module system you are using works properly
6. but wait, you might also have an intermediary compile step depending on if you are using JSX and the tooling around that

For someone like me who wrote jQuery and was overly concerned with the issues that sprang from cross-browser compatibility before ES2015 or Node was even a thing, this current process is completely baffling. Suddenly, one day we are compiling our Javascript multiple times just to get it work.

I’m not saying these are bad things. Things like React and Node have done wonderful things for web development and allowed us to move forward in the web space in new and exciting ways. The problem is that we’ve created such a barrier around these great things that it is becoming increasingly harder to take advantage of them in a way that is reasonable.

Let me tell you about the times I have tried to use Babel. Yes, plural, because up until recently I could never get it to work. I wrote my ES2015 code, went to find Babel, only to be told that I needed babel-cli, once I got babel-cli I then figure out that it does nothing by itself and you need to download plugins. At this point I was confused, isn’t the point of Babel to compile modern JS code down to code we can use now? Why do we need to install plugins for something to do what it was built to do?

So I go and find the plugin, install that (thus my node_modules folder gets ever larger), and try again. Only this time it doesn’t work because I need to learn the arcane combination of compiler flags to even get it to just work. When did it become easier to compile using GCC/Clang than it is to compile Javascript?

Ok, so now I have a collection of Javascript files that have been transformed into something the browser can use, except it can’t because now I have this whole module system littered throughout my code. Apparently, figuring out how to deal with modules is a challenge left to the coder. So now, I have to figure out how to concatenate my compiled Javascript code so that it will work with these modules. So I go and grab Browserify because at the time, it seems like the most commonly used software to achieve this.

After again figuring out the ancient incantations of the compiler flags that would make even kernel developers blush, and again writing more config files, I finally have compiled my ES2015 code down to something I can include in my browser.

After all this, I load up my test.html file, and bask in the ‘hello world’ application I have just written in the new hotness that is ES2015. Except, now I have 2 actual source files (I was experimenting with ES2015 modules), 2 compiled files, 1 concatenated build.min.js file, and a ridiculous amount of configuration and build files.

This is what Javascript fatigue is, a complicated maze of dependencies that don’t quite fit together, tools which require mountains of configuration and cli flags, and multiple steps that should be folded down into one tool but for some reason are not.

If Javascript is to continue to thrive as it has been, then we need to as a community have a serious discussion about how we do things. We need to build tools that are easy to use and require one, if not a small number of steps. Imagine being able to download just one build tool that by default allows you to write something like ‘jsc /some/js/dir -o /some/build/dir –enable-jsx’ which not only does all the compilation but handles things such as modules etc for you, so that we can spend more time on building great applications and spend less time on downloading and configuring tools.

 

We Need to Talk About The “Mobile Revolution”

It’s been nearly six months since I left my last job working in the Mobile Consultancy game. These days mobile to me means a responsive web front-end or using Facebook/Twitter/That-thing-that-all-the-cool-kids-are-using, which to be honest, is fine by me.

Looking back at my time working in the mobile space, one thing seems pretty clear to me: There isn’t really any money to be made in mobile.

These days you are either are either the hot new Silicon-Valley startup enabling their users to use their software in a more native way on mobile (Facebook, Twitter etc) or you build your business model around being mobile first and find a way to make that model profitable (Uber etc). The problem is that in the eyes of the consumer, an app that you may have slaved hundreds of hours on to them is worth at most 99 cents, god forbid you do something crazy like ask for a measly $3.99.

A lot of people place the blame squarely on the shoulders of Apple and Google, and while yes, they do have some blame to shoulder, the real blame should go onto the consumer who has created this race to the bottom style of software. It’s a hard pill to swallow for most of us, myself included, the idea that while the average joe see’s their mechanic or plumber as someone who deserves a fair compensation for their work, we are under-appreciated to the point where people see our work as worth less than their morning coffee. It even reaches the point of insulting when you get co-workers, family, friends or even complete strangers who come up to you and ask you to build their “next revolutionary idea” and think they’ve somehow outwitted you by getting you to work to their idea of how long it takes to build an app for what is essentially no money (as a 50% stake in a crappy idea is still worth no money.)

Moving past the bitterness of past experiences for a while, another reality starts to set in. For those working in the mobile applications games, the only way to make money is as a consultant working on other peoples ideas. For those of us who have run the gamut of trying to do anything that might make us money will tell you, its between damn hard and nigh impossible to release an app that will provide you, the developer with any kind of sustainable income you can life off of (granted, exceptions do exist i.e. Flappy Birds). However, working as a consultant, your income is not tied directly to app sales (at least, I hope not), rather it is tied to the delivery of the app itself.

These days, every business wants a mobile app, most don’t even know why or even if they need one, but they are convinced they do, and in fact these are usually the cases where an app becomes less of a cost center, and more of a boost to their base revenue model. These are the companies that keep mobile application developers fed and with a roof over their head. However, these are also the customers who create the self-fulfilling prophecy of apps not being worth diddly-squat as the vast majority of these businesses release their app for free.

Really, I feel this was more of a vent than talking about industry problems, which is fine, it’s my blog, I can write what I want. And I also realize that one session of venting online is not going to inspire a radical shift in the industry, but at the very least, I feel some kind of duty to those who come after me to give fair warning as to the state of things in the mobile world.

Good luck brave soldier.

(Feature photo copyright Charis Tsevis)

Thoughts on “The Good Parts”

Recently I’ve decided to take another look at what is currently the trendy thing to be working on in software these days, which to me seems to be anything written in Javascript.

I’ve always had a love-hate relationship with Javascript, I can see the power it offers in creating dynamic web pages, and the idea of AJAX has changed how we work on the web. However, Javascript is a funny beast that occasionally does strange things (the most famous example of which is demonstrated here).

Javascript has also had, long before it became in any way popular or “trendy”, a lone knight claiming that Javascript not only doesn’t suck, but has “good parts”. Now, I’m not going to sit here and rip on Douglas Crockford, because the man does have some good points. However, after watching his live talks “The Good Parts” and “The Better Parts”, I’m convinced that a lot of his points are either subjective, riding the trends of today or are just claims with no evidence to back them up.

My particular sticking point comes from his proclamation “I am done with loops”, claiming that without loops Javascript becomes a purely functional language. You can’t just not use a feature of the language and suddenly turn it into something different, not to mention the whole idea that not using features of the language is stupid. It’s naive to think that you can solve every repetition problem solely through recursion.

Also, using foreach, map etc instead of loops is “not using loops”, rather, it is just abstracting away the loop from the programmer. Given up until ES6 there was no tail-call recursion, how do you believe foreach() and map() were implemented?

However, after saying all this, I will say that I’m not overly against saying that he is right, and Javascript does have its good parts. In fact, with all the things coming in ES6, Javascript is the closest thing to my ideal programming language that I have in my head (minus static typing). I’d like to see Javascript evolve and shake off it’s terrible past and evolve into something that will carry the web forward for the next decade.

Mobile Design For The Rest Of Us

It’s common to have someone come to you with an app idea when your job title is something akin to “Mobile Applications Engineer”, they might even have a good idea and some designs to go along with it (god forbid)!

Invariably, when I see these wonderfully put together designs, the first question that comes out of my mouth is:

You only have one set of designs here, where are the others?

And this is usually met with a look of confusion or derision as I’m scornfully told “what do you mean others? they need to all look and act the same!”

This position is understandable, from a business perspective it makes sense for your app to look and function the same across different platforms. However, this stance shows a lack of understanding of the mobile market, and understanding you should probably learn before investing in the mobile market.

Android users expect their apps to work like Android apps, conversely, iOS users expect iDevice apps to work like iDevice apps

And it isn’t just the expectation of the end users you have to deal with, but it is the fundamental way in which apps work on these two platforms which can cause all sorts of issues.

One of my first commercial projects was porting an iOS app to Android, and inevitably it ended up being a circle of implementing the features the Android way, then ripping them out to be replaced by more iOS-similar features. Now, this isn’t to say that I don’t deserve some blame for that situation (always make sure you understand the project spec fully before delivering stories!) But the end result has been confused Android users who cannot understand why standard Android actions behave in a non-android way.

My favourite example of this is the Action/Navigation bar. In iOS, the top banner bar is called the navigation bar, and is designed to be the central manager for navigating back and forward in a manner similar to a stack of plates in that it will always display the top plate, and every time the back button is pressed, the top plate is removed, revealing the plate below it.

However, in Android land, the top banner bar is called the Action bar, and while it has some built-in features for navigation, it’s primary function is to be container for action buttons/dropdowns which spawn their own actions. And while there is some built-in functionality for navigation, it is primarily for going back to the previous “activity”.

Understanding that each platform is each unique in some way, shape or form can actually be of benefit to the implementing business as building your app with the same features in a platform-specific way shows the consumer you care about their end-user experience and can only benefit your app growth in the long term.

Expanding Your World Beyond The Code You Write

A few days ago, I was on my way home when I get a phone call.

“Hey, can you deploy the server to production?”

Grumbling a moaning, I turned the car around and headed back to the office. An hour later, Apache was serving our backend server. Satisfied, I grabbed my stuff and got out of the office before I was asked to do anything else.

Later that night, while I am out for dinner, I get a text message:

“Updating profile pictures is causing the app to crash.”

Fuck! I quickly grab my phone and do the best debugging that I can on my phone through the admin console, turning up not much of anything. Sighing, I respond that I’ll look into it as soon as I am near a computer. (Keep in mind, production wasn’t actually live in use production, so it wasn’t consumer critical to have it fixed right then and there).

Later that night when I get home, I start going through the debugging process. My local server instance is working fine, even our test server is working fine. So it must be something to do with our production box. Thinking about why Django would be throwing a 500 on uploading profile pictures led me to the answer.

“Apache runs as a service under linux which spawns the WSGI interpreter, it doesn’t have permissions to write to /var/www!”

Satisfied that the fix was working, I went to bed that night having learnt just a little bit more about deploying production servers.

Being responsible for deploying our code to production has introduced me to a whole new skillset that I never thought I would have to learn, and which I never learnt at university. I call this skillset, consumer-facing skills for developers.

The problem coming fresh out of university isn’t so much your skill level. A lot of companies can deal with someone who might not know the latest Javascript framework or the have 3 years experience in a language that has only existed for 2 years. The problem comes down to the fact that you’ve spent 3+ years working on meaningless problem-sets, with very little teamwork.

Now, there is nothing wrong with doing problem-sets by yourself. However, these problem-sets are not designed to prepare young software engineers for the consumer-facing world ahead of them. And that is fine, it is not necessarily the job of the university to prepare you for the commercial software development world, but, to simply impart a set of skills to you, and prepare you for a life of developing your own skillset as needed.

The thing I see, and the thing I have experienced most of all, is being able to wrap your head around the concept of building something useful for the consumer. Even if that consumer is another software developer using your tools in their own projects, as a developer, you need to realize that your software is going to be used by other people.

And it’s not just the end result you have to worry about either. Your software is going to be tested by QA specialists, your software is going to be deployed and kept running by sysadmins and your software is going to be maintained probably by some other software developer in the not-to-distant future.

The point I am trying to make is that we as software developers need to see and experience the world beyond our compilers. Go down to the QA office and talk to those guys about how they go about testing things, who knows, you might learn something that will mean less work for them and a more solid product for you. Go talk to the sysadmins and ask them how they actually deploy things and ensure that the whole system doesn’t fall over.

In particular, I’ve taken to deploying Django to production. Not only has this led me to DigitalOcean, which has a wonderful tool that deploys production ready Django instances for you, but I’ve also learnt how a production Apache system can work. On top of that, I now know how how to deploy Django setups to production.

Don’t be afraid to get your hands dirty and see the moving machine for what it is. You might accidentally learn something.

What you write does not define you

I’m pretty new to the software industry. I’ve followed it for years throughout my stint at university, but only recently have I really gotten into the trenches.

The first thing that has really hit hard for me is dealing with the fact that software will never be perfect. Admittedly, as someone who spent some time around music, I should probably know better, but it seems not so much…

It can be a little daunting at first, when you do your first release to someone for testing and they turn around and tell you “this doesn’t work, I can’t log in.” But you smile and nod and scurry off to fix the log-in screen, only to come back the next day and hear “well, the log-in screen works, but your homepage breaks when you do a handstand and recite the pledge of allegiance.” You begin to wonder why anyone would even think of doing this, but you shrug and go off to figure out how to off-key-singing-proof your homepage. You awaken the next day to find a bug-tracker full of bugs in your software. Defeated you roll over and decide that the testers just hate you and don’t know how to use your software the right way.

It can be difficult, especially for people like me who are new into the industry to see a bug-tracker full of bug reports and not feel like each report is a comment on your skills as a developer. After all, you wrote all of it, who else is to blame but you when it all goes wrong?

We all work in an inherently negative field in that we build something, and wait for someone to come back and tell us we fucked up. It’s a nasty cycle when your skills are determined by the amount of times someone tells us we did something wrong.

A thought I’ve had recently, and one I am trying to internalize is that we as developers need to stop defining ourselves by the software we write, and start defining ourselves by the lessons we learn from each project. Each project is a chance for us to grow and learn something new, and a chance for us to make improvements upon our processes and ourselves. And that is something I believe is worth basing yourself upon.

I could be wrong though. After all, I am only new to this, and maybe I am living in a naïve fairy-tale. But what I do know for sure is that defining yourself by the software you write is not a healthy or safe way to live.

Think Of Those Across The Pond

First off, excuse the vague-ness of some things, NDA’s are still in effect.

I’ve just come off a project working with an international client on an app that involves both english and non-english translations. This involved both the app and an application server, both of which needed to handle internationalization. Over the course of this project, I’ve come to realise, few developers actually keep international users in mind. As such, for my own benefit as much as anyone elses, here is a list of things to keep in mind when working on software with international users.

Not everyone speaks or reads english

This seems like an obvious one, but, you’d be surprised how many apps are out there which have a large international user base and which only focus on english. Simple things like using the built-in strings file feature can make translating your app easy.

Google translate is not a reliable translation source

So you have your strings file, and decide you want to add spanish to your app? You go over to Google Translate and run your strings through the translator. You happily upload the new version thinking you’ve done a great service by providing support to international users. That is, until you find out that google translate accidentally translated your welcome page header into an insult to the users mother, or that the important instructions don’t actually make any sense.

The problem with google translate is that it isn’t smart enough to take into consideration the phrasing contexts of certain sentences, and will just translate verbatim.

Do yourself a favour, if you find yourself with a number of users asking for international support, don’t be afraid to ask them for help translating.

Validation can catch you off guard

This one speaks somewhat to my stupidity. And if I’m going to make myself look like an idiot, then hopefully someone can learn a lesson from it.

In Australia, our post codes are always 4 digits long, now of course, me not having the wisdom to think beyond my own country, implemented a check to ensure the given post code was a 4 digit long number (allowing the number to have its first digit as 0). I only realised my folly when reading about Germany and discovering they have 5 digit long post codes.

The issue is, we spend so long in our own little bubble of expecting certain things to be the way they are, we forget that some people do actually do things a little different.

My suggestion – learn about a few different countries, how they print phone numbers, zip codes etc

Time and decimal numbers secretly hate you

Ask me to write out the date for you and it will probably be in the form of dd/mm/yyyy. Ask an American and it will probably be in the format mm/dd/yyyy.

Unfortunately, this is by far the most annoying thing I’ve come across, especially in the way of time. First you start off handling time the way you are used to. Then you discover that some countries don’t consider AM/PM at all and work on 24-hour time. Then you discover that some of the countries that do, do AM/PM have special translations for it.

What about decimal numbers? Here in Australia we say 1,645.43. But in some parts of the world they would write 1.645,43 which is the same number.

Luckily, in iOS we have things like NSDateFormatter and NSNumberFormatter. I’ve made a solemn vow to always use these from now on when handling dates or numbers, and you should too.

Not everyone writes english

How well does your app handle unicode? What about your server? One thing I quickly ran into was using Django-Rest-Framework with unicode characters. Even when your app is being used in an english locale, the user might have added Chinese to their keyboards and could be happily typing a slab of text containing a mix of standard ascii and unicode characters.

If you’re web framework of application framework supports unicode, I suggest using it from the start.

Now, I may have forgotten something, and some of this may seem rather obvious. But internationalization is one of those things that can easily be forgotten about until it is too late.