The best read-it-later implementation that will never be
Google already has the tech to build the best read-it-later service bar none. It understands web content like no other and can even crawl JavaScript applications. Google can unshackle content that I actually want to read from all the surrounding noise.
Google can, but unfortunately it won’t. Doing so would anger content owners, the people that Google relies on to display its ads. And that’s a pity.
Elixir Notes
I’ve been learning myself some Elixir lately. Unfortunately, I’ve only been able to sip while I really want to be gulping the stuff down. There aren’t enough hours in a day. Sometimes a week passes between study sessions and it’s hard for me to find my bearings when I come back to the language after a break. So I’ve started writing some study notes. I find that it helps me internalise the syntax and makes what I’m learning more sticky. The result is more than just a cheat sheet, but remains easy to glance through.
It’s a work in progress, but might be useful to somebody: Elixir notes.
Elixir is a functional, meta-programming aware language built on top of the Erlang VM. It is a dynamic language that focuses on tooling to leverage Erlang’s abilities to build concurrent, distributed and fault-tolerant applications with hot code upgrades.
Using Retrofit and RxJava to interact with web services on Android
Retrofit from Square, and RxJava from Netflix, are a great combo for interacting with web services on Android.
Retrofit
Retrofit is a REST client for Android and Java. It allows you to turn a REST API into a Java interface by using annotations to describe the HTTP requests. It can then generate an implementation of the interface for you. This means that you can go from:
GET /users/{userId}/posts
to:
webService.fetchUserPosts(userId)
in a few lines of code. Retrofit is very easy to use and it comes with RxJava integration.
RxJava
RxJava is a Java implementation of Rx, the Reactive Extensions library from the .NET world. It allows you to compose asynchronous and event-based programs in a declarative manner. Let’s say that you want to implement something like this:
- Start observing our current location. When a location change happens, in parallel
- Send a web service request A
- Send a web service request B
- Using the result from B, send a web service request C
- When the results for both A and C are back, update the UI
RxJava allows you to write out your program pretty much as above. It abstracts out concerns about things like threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O. You can tell RxJava to observe the location changes and perform the web service requests in a background thread, and pass you the final results in the UI thread. If any exceptions are thrown at any point in the chain of events, you get told about it in one convenient place. You’re not drowning in a spaghetti of onSuccess and onError callbacks. You’re building pipelines.
I’m sold. Show me the code!
Sounds good? I’ve got some code to get you started. RexWeather is a simple app that demonstrates the use of Retrofit and RxJava on Android. The app queries the current location, then fetches the current weather and seven day forecast from OpenWeatherMap.
You can grab the Android Studio project from GitHub. The code is BSD-licensed, so feel free to use and share.
Being a Programmer
Being a programmer means that my default state is to be at the edge of my current capabiliy. I’m rarely in any sort of comfort zone, and looking around the Internet, I’m constantly reminded of just how much I still have to learn.
There is a level of sharing in our profession that allows us to literally look at master craftsmen as they are building their best work. There is a huge body of open source work where we can see every line of code added and removed. Commit messages tell us the justification for every single change made to the codebase, all the way back to the very first line written. And on top of that, we can read about the design decisions as they are hashed out in online discussions. No matter how good we become, the open nature of the Internet rams home the harsh truth: someone, somewhere, has the expertise to expose us as mere imposters.
Ours is a commitment to lifelong learning and sometimes it can feel like an endless slog. However, if we embrace our never ending education, we can thrive and grow not just as craftsmen, but as humans. I’ve noticed that good programmers have a deep intellectual self-confidence. One that comes through doing something over and over again, constantly. Good programmers know that they can learn just about anything if they apply their mind to it. No, it won’t be easy. No deep insight comes easily. But it can be done. They know because they do it all the time.
RubyMotion 3.0 to bring Android support
RubyMotion allows developers to use Ruby to write iOS and OS X applications. It uses an LLVM-based static compiler to compile apps down to machine code.
With the next major version, RubyMotion looks to take on Xamarin in the cross platform game. Due later this year, RubyMotion 3.0 will add support for the Android platform.
Ruby is, in my opinion, a more pleasant language than either Java or Objective-C. However, that in itself was not a good enough reason for me to pick it over Objective-C for my iOS work. Would I use it for Android apps? They promise that performance should not be an issue. RubyMotion compiles down to machine code on Android too. The ability to share code between platforms makes it somewhat more attractive, but it also brings up comparison with the more mature Xamarin stack. While Ruby is nice, Xamarin has C#, which is also a nice(er) language (than Java). And how about the ability to use F# in Xamarin? Functional programming is the new black isn’t it?
It looks like one thing will carry over from iOS and OS X to Android though: The eye-twitch inducing fact that ruby code favours liberal use of underscores while the Android framework, like Cocoa Touch, is firmly in the camel case camp.
Darculash, a new theme for IntelliJ IDEA, Android Studio and friends
I’ve made a new theme for the JetBrains family of IDEs. It’s based on the Darcula theme from JetBrains. Here’s a preview of some Java code in Android Studio:
You can grab it from GitHub.
Fix the broken windows
Sometimes, after finishing the implementation of a new part of a program, I like to take a break and sort of aimlessly browse the code that I’ve written so far. I will pick a module and start reading a couple of classes, and see where that takes me. It’s a form of procrastination. That’s me coming back up to the surface to breathe, to gather up my willpower before I again dive deep into another intense round of coding.
While code reading, I will often find things about the program that can be improved on. Some things will be small – add some documentation; fix typos, whitespace or indentation. Maybe pick a better name for a variable. But sometimes, I will find bigger opportunities for improvement, and I will do some ad hoc refactoring.
I believe that this is a healthy form of procrastination. It keeps my knowledge of the program domain current, and keeps the code lean, the best I can make it. This creates a virtuous cycle of implementation, polishing, implementation, polishing again and so on. I do not consider it wasted time. A codebase that is sound is easier to add to. It’s an investment towards less work in the future.
However, sometimes I have to work on a codebase that is in a bad shape. When that happens, I just want to go in, make the changes that I need to make, and get out of there without leaving too many brain cells behind. I will leave things in a better state than I found them, but I want to be out of there as soon as I’m done. I will not go out of my way to seek out things that I can improve on. Because I can already see the issues staring at me in the face, and there are so many of them. Motivation has taken a quick look and said “Look, I just remembered that there’s this thing I gotta do. Call me later, you know, after you’re done here.”
Maybe you’ve heard about the Broken Windows Theory. It goes like this:
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.
Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.
So fix up your broken windows. Be vigilant and always worry about what you’re presenting to a visiting programmer. If it’s obvious that you don’t care about your code, then the next person to add to it will care even less. Soon badly indented code becomes poorly structured code. People start spawning state needlessly simply because they can’t be bothered trying to untangle the mess. They’re holding their breath while running through corridors that stink of urine. They just want to get in, add this thing they need to add, and run out again. One day someone trips over some wiring and the building is on fire.
Fix them broken windows.
Mainpeak wins at the Web Awards
Two ecommerce projects in the past two years, and two national awards. As usual, it’s been a pleasure working with the team at Humaan. Congratulations guys!
Recent project: Event Weather Redesign
I recently worked with Event Weather and Daniel Brouse to launch the latest redesign of the Event Weather website. Daniel and I wrote the original site back in 2008, when we were both working at Bam Creative. This is the third iteration of the service.