Learning new tech the simple talk way

Wed, Jan 17, 2018

I learned a few languages at school. English (thankfully, though the Glaswegian dialect of course!), Latin, Ancient Greek, Russian and Gaelic and since then I’ve always been prone to asking people to say things when I want to get a feel for how their language works.

I like to ask them to say things like “I am, I was, I will be”, then more challenging stuff such as “I am singing, I was singing, I will be singing”, or “I am reading a book, I read a book, I will read a book”.

Hearing the replies to these questions doesn’t infer immediate understanding but it allows my ear to tune in to their way of speaking and more importantly, to perhaps recognise how the language might work. Is it inflected? Do adjectives agree with their nouns in case, gender and number? What are the nuts and bolts of the language likely to be, based on my experience with the languages listed above? In short, what are its idioms?

The same technique can be used when learning a new programming language or technology. Java, Ruby, C#, go, C, C++, Javascript, I’ve used them all to produce production grade systems at some point over the last (ahem!) years of professional software development and each time I’ve applied the “simple talk” technique.

How do you open a file in Java? Really? Get away, what are you like!?

I’ve been working on an Android app recently that connects to a backend REST API and queries video conference bookings for a room. There’s an Estimote BLE beacon in the room broadcasting an Eddystone-UID which the app detects. It then sends the UID to the backend to get the day’s schedule of video conferences and displays them. When a video conference is about to start, the app displays the details for the duration of the conference. Ten minutes before the conference is due to finish, the app switches into feedback mode and displays a sad/smiley face for the participants to tap on the way out, sending the taps to the server. Ten minutes after the conference completes, the app reverts to displaying the day’s schedule for the room. It’ll eventually be stuck on the wall next to the door to facilitate gathering feedback. I decided to call it Gustav as it allows the Gathering of User Satisfaction Trends Across Videoconferences. Catchy!

I developed the user interface for the feedback analysis and backend API using spring-boot and the integration with the video conference scheduling system, so the Android app only has to talk to the spring-boot application and not have to deal with the idiosyncracies of understanding how a calendaring system works. I’ve done that already and wrapped it in a REST API. It’s pretty much standard practice for me. Get to know the scheduling system, its API and data formats and what the various terms mean. Classic Domain Driven Design (DDD) territory as I needed to talk to the people who run it and who have a language of their own when talking about video conferences. The DDD part also illustrates the first rule of integration:

know thy systems!

Anyway, this is all very interesting, challenging, satisfying and chin scratchingly curious in places but the point of droning on about it is the “simple talk” technique I used to refactor the Android code I’d written for the app. Specifically, the parts that consume the REST API to get the video conference schedule and send the feedback to the server. I had something that worked but I wanted something idiomatic as I knew it would take my understanding of the platform to a new and robust level.

Server-side API consumption is fairly easy to do, either from scratch or using spring-boot techniques like RestTemplate. No mystery there. Java competence is up around Level 4 on the Dreyfus Model of Skills Acquisition but true to the model, Android was a little lower in places. Most notably, how to consume an API. You can’t just write a client and query it as you have threading concerns to deal with on the resource constrained device. So, what’s the best idiom for doing this in Android? Time to turn to the “simple talk” technique.

I asked a question on stackoverflow, hoping someone would do me the honour of saying “I am, I was, I will be” but in Androidish. And they did. I asked what would be a good way to consume an API and the conversation I had with the very kind developer opened lots of doors of perception, not only giving me an aha! moment but allowing me to slot Android into its place in my ahem! years of software development idioms.

Understanding the idiomatic use of a language or technology lets you project previous experience onto the landscape, working out likely ways it might handle certain tasks, giving you a candle with which to light the dark journey ahead. Not to mention the cross fertilisation of using idioms from one language in another. Perhaps I’ll write a post about how I used the concept of promises from Javascript to integrate the output of a C program I was working on with a Java system a colleague was developing. The C program was turning documents into speech and I needed to let the Java system know when its job was ready without making it too cumbersome with message queues but that’s for another time. Integration is just so interesting!

Perhaps the “simple talk” technique might be useful when learning a new language or technology, allowing you to climb the rickety Dreyfus ladder of enlightenment?

comments powered by Disqus