Suddenly, Flutter

I had no plans to learn Flutter in 2019

When I first heard of Flutter last year, I couldn’t help but draw parallels to Java Swing, the UI technology I started with in grad school (and thankfully dropped a year or so later). If you don’t know much about Java’s UI technologies, suffice to say that for all of Java’s strengths, no version of their UI framework was ever one of them.

It started okay-ish enough with Java’s AWT toolkit that let Java call native code to create system windows, buttons etc, but devs soon realized that building cross-platform applications (which was always Java’s pitch) was really hard when you could only target the least common denominator widgets that were available across all platforms. “No more” said the Java community, and proceeded to build Swing, a cross-platform UI framework that emulated the system controls by drawing them itself on a canvas.

Image result for write once debug everywhere java

Sound familiar? That was what Flutter promises with the core graphics engine that would emulate the native Android and iOS widgets

The problem is that Swing turned out to be crap. The widgets never felt native and performed poorly. You could always tell if you were using a Swing app. And it was always interesting when some app wasn’t coded right and you’d end up with apps emulating the Windows look-and-feel on a Mac (who checked on a Mac back in those days)

So Flutter was on my “no-thanks” list. Besides my lack of faith in faking native system widgets, the language they chose was Dart! Who knew Dart? More importantly, where were the interesting libraries in Dart? Having done a few React Native apps before, I liked my options with JavaScript and the dream of making cross-platform (mobile AND web) apps.

But then a couple of things happened. One: I saw some pretty compelling Flutter based apps. The interesting thing was, the best apps try to create their own design language anyway, so deviating from the system look-and-feel felt okay; and then second: I tried Flutter for a labweek project and was won over by the one click deploy to multiple platforms and the hot reload (it might also have been just fortuitous timing as I was losing my mind with React Native’s minimal support for custom views and animations, something that Flutter promises a lot more control over)

So for the last 4 months or so I have been working with Flutter and I have to say I really enjoy it. Some parts are definitely rough (I still don’t love the indentation hell when describing layouts) but Dart is enjoyable and is very inspired by the best parts of JavaScript and Swift (among others). Recent additions to Dart have been very interesting, because they address issues in real-world UI development. This feels different from the more generic “Lets create a general purpose language and allow it for UI dev” approach of other languages.

But the core reason I am excited about Flutter is the culture. The reason Swing was a dud (IMHO) was that it was built by people who didn’t care to push UI experiences. The native mobile toolkits are better but still make it hard to build complex user interfaces (SwiftUI and Jetpack Compose are trying to change that). Example “Hello World” apps you see using native toolkits are pretty generic form-based apps.

But look at the kinds of apps Flutter shows off:

Image result for flutter timeline app

🀩

While this may not be everyone’s cup of tea, this “think-outside-boxy-layouts” approach has my vote.

4 months in, I am still new-ish to Flutter but I guess I am on board. Stay tuned for more random Flutter stuff on this blog πŸ™‚

Learning Curves

For the last few years I have been thinking quite a bit about how we enable more people to learn programming. As an industry, we need more programmers universally and there seems to be a huge number of people who would want to come in. Unfortunately though we can’t seem to connect the 2 sides of this equation effectively.

Specifically I have been thinking about learning curves. Until recently I believed learning curves to follow a close-to-linear relationship with time. You learn a little bit at the beginning and are work on simple ideas and learn more and more as time goes by.

This seems to be codified in most programming books too, which introduce simple ideas at the beginning and then move towards more complex ideas

However, lately I feel a more honest representation of this learning curve we expect a newcomer to master would look something like this.

The initial hump in that graph represents a mountain of complexity that junior programmers are immediately handed before they can do anything with code. A lot of times this hump represents meta-work: things that are not core to the technology but elements like build systems or frameworks for testability, coding standards, etc

Take JavaScript for example. A “Hello world” JavaScript experience requires you to either start coding the way the industry strongly dislikes, the old fashioned way with script tags and vanilla JS, or learn the complexity of modules, package managers, build systems etc.

Same goes for mobile app development. For example if you are looking to make your first Android app, a brand new Android project using the Android Studio wizard drops you into a mess of Gradle, Java, Kotlin and XML files.

Tools like XCode and Android Studio also are extremely complicated for any beginner to use, with a ton of panels and tools to tap on without knowing what they do. Ironically, most of the teams building these tools have User Experience professionals on them and yet the ideas of progressive disclosure and first run experience, that as an industry we keep touting for our end user apps, are never considered.

Technology Complexity Cycle

Reflecting on my own learning-programming experience and talking about this with a few other people, I realize that another thing that got me into programming was also working on a technology (Flash) that wasn’t as mature.

When I started playing with Flash, it was back in the Flash-4 days with a very simple programming model where most of the code was written in small scripts attached to the timeline that just controlled the position of the animation playhead. My learning-to-code experience happened almost in-sync with the addition of complexity to Flash. Towards the last part of my experience with Flash, it had gotten complex enough with ActionScript3 and the need to become a “real” programming platform that it started to lose people.

I feel this happens a lot. Early versions of a programming platform are simple and functional and then, if it gathers attention of the “serious” programmers, way too much complexity gets added. This complexity makes the technology a daunting beast to new entrants.

The point is …

I had a couple of thoughts for new programmers that became the primary motivation for this post:

  1. Survive the initial hump: Getting started with learning programming is a lot harder in the beginning so stick with it. It does get easier as you cross the initial hump of tools and meta-work that goes into starting a project and very rarely revisited once the project is in active development
  2. Play with emerging technologies: Emerging technologies don’t often have a lot of initial hump as tooling and other meta-work hasn’t been invented yet. Technologies like WebVR, Blockchains, Flutter etc are great candidates to play with now and grow your skills as the technology matures.

And for those of us who have been in this industry for a while and may have the power to influence tooling and/or methodologies of how code is written, lets endeavor to make these more welcoming to folks with different levels of experience with tech.

PhlAI talk: Building AI with Emotional Intelligence

Last week I gave a talk at the PhlAI conference on building systems with emotional intelligence, a subfield of Artificial Intelligence called Affective Computing. The presentation is embedded below and can be found on my SpeakerDeck page

I have been looking into this space for the last 4 months or so and it is a really fascinating space. I am a big believer in the need for assistive systems to mediate an increasingly complex world for us and that these assistants would need to be not only competent but also empathetic. However as with most new technologies, Affective Computing has a lot of potential for abuse as well if these technologies are used to emotionally manipulate or deceive people. It is definitely a path we must tread very carefully.

In general I really did enjoy the PHLAI conference and met some really interesting people and saw some very impressive technical talks and demos by IBM, Tableau , H2O, SaS and Ascend. Thank you to the organizers for putting on a great event. Definitely looking forward to the next one!

I made one of FullStack Academy’s “Developers to Follow” list

It’s always nice to be recognized. And since part of the purpose of this blog is to serve as a historical record of my professional life, figured I should post about it here before I lost the link to the sands of time πŸ˜‰

https://www.fullstackacademy.com/blog/developers-that-work-in-media

GDG Philly’s 100th meetup: a retrospective

Drumroll!!! The next GDG Philly meetup will the πŸŽ‰100th official meetup!!!

And we have a good one lined up with some of the biggest tech leaders in Philly on a panel on managing your career as a technologist. If you are a developer or are looking to become one, you should definitely sign up.

For me it’s certainly a time for some celebration and reflection. Corey and I started Philly GDG, or rather its previous incarnation, AndroidPhilly, in 2011 when both of us had just about started working on Android and realized there wasn’t a local community where we could learn from each other. And considering how minimal technical documentation and user experience guidelines were back then, a local community was sorely needed. The group transitioned to an official GDG at some point which meant we got a lot more support from Google in terms of speakers and schwag.

Thinking back, there are a lot of things that worked well. The consistency of the day (last Wed of every month) and location (Comcast Center) every month definitely was a good idea and built up a monthly habit for the regular members. Comcast was great about sponsoring this event every month since it’s inception, and my managers, former and current, were very supportive of letting me run this. Other companies in Philly have been fantastic supporters as well including Promptworks, Chariot, Candidate and others who have hosted or supported us with food and beverages over time.

We are also a better balanced community as far as gender goes with more women participation than a lot of other communities. A lot of credit there goes to Corey for leading the outreach in early days, and always making sure we had women as part of the leads. It’s something the current leads, Yash, John and Ruthie, continue to champion.

There have also always been a lot of challenges, some similar to those faced by other groups while others unique to our own. Sourcing speakers every month is hard, specially when your community is much smaller than those in cities like SF and NY. Creating a channel for the community to keep the conversation going has also been challenging with Slack becoming a defacto communities platform that doesn’t really work if you aren’t paying for it (I am starting to look at other platforms like Discord, but a lot of people may not be willing to install another app). Trying to balance the level of talks has also been a concern: we want to have intro level talks to bring new people in but also more advanced sessions for folks who have been coming here for a while. If you have ideas on any of these, I am all ears.

I made a lot of friends thanks to our group. From other past (Corey, Chuck, Dallas) and present (Yash, John, Ruthie and Kenny) fellow organizers who helped run this group to regular members who have been attending our monthly meetup for years.

Hanging out with past and present Philly GDG leads at Google IO 2018

I am looking forward to how the group evolves going forward. In the meanwhile, if you are in the neighborhood, join us for our πŸŽ‰100th event. It promises to be a great one

Adventures in working with JavaScript, Dart and Emojis

I spent the whole day today working with Strings being sent between a JavaScript serverside app and a Dart clientside app. As an industry we have been doing this forever, so you’d think it’d be easy but then along came emojis to muck up my day 🀬

Instead of writing my own primer on Strings here (and doing a bad job), let me just link to Joel Spolsky’s excellent post on the subject

This really old post still does a great job of bringing us up to speed to the Unicode world we live in today. And then came Emojis

There are numerous posts of the pain of dealing with Emojis whenever you have to because it does screwy things like combining neighboring characters to form a single emoji. This means that the length of a string, if it is just a measure of the unicode CodePoints used is different from what you would count on the screen.

This gives you whacky results like “πŸ’©”.length == 2 and generally makes working with strings just a pain even to the extent of crashing your iPhone. On the flip side some things like being able to delete family members from the 4 member family emoji with every backspace are kinda amusing, since it is it’s actually 7 characters: 4 ‘normal’ people characters and 3 invisible ‘joining’ characters in between.

Which brings me to today. I am playing around with moving a client/server app from JavaScript everywhere to JavaScript server and a Dart client app. In the previous iteration, strings that needed to be sent had special characters that needed to be escaped and sent across: no problem. JavaScript’s escape/unescape worked pretty well.

Moving to Dart though was a challenge, because there is no escape/unescape method. Turns out escape/unescape is best avoided anyway, and encodeURI/decodeURI is a better option. Dart has a decodeFull method on the Uri class that does the job pretty well.

Except that the characters in the list also included emojis and Dart’s Uri class doesn’t work with anything more than UTF-8 characters and crashes when encountering strings with emojis that are just ‘escaped’. This, as it turns out, is as per spec and all those fancy emoji domains that I thought used Unicode in the URI, use a different idea around Internationalized Resource Identifiers and Punycode. Thankfully passing in a URI encoded string with emojis seems to work fine and emojis come out πŸ‘on the other side of the decode process.

While this seemed to work at that point, passing the decoded string to my Yaml loader crashes the app again (is Yaml supposed to be restricted to Ascii/Utf-8 ? ). But that is a problem for a different day.

For now, I have decided to just convert emojis to shortcodes for the transit and remap them to emojis on the other side. Its not pretty but it works.

Oh and in the meanwhile, if you want to know how to loop through a String with emojis in Dart, you can do that by looking through the Runes in a String:

A Quick 2018 Retrospective

I am a little behind on my 2018 review, seeing that its almost mid Jan already. But better late than never, so here goes

VR

2018 continued to be a year of tremendous education professionally. For a big part of the year I continued to work in the VR space, specifically using A-Frame and WebVR. I am definitely a fan of WebVR and I really do believe that the app model that is prevalent in the mobile ecosystems is a bad idea for VR. I completely agree with the vision of VR being a web of experiences, and the web technology stack has matured to a point where deploying a VR experience is trivial. Hopefully more people will take up building VR experiences in JavaScript and WebVR. What the community really needs is a diversity of ideas and to grow VR beyond its early base of gamers.

While it was a lot of fun, I am looking at other things beyond VR this year and am excited for certain new ideas I am playing with. Will share more on that later.

Blockchains

I did a fair bit of work on Blockchains in 2018, mostly at the Dapp level. Its early days for this space but I do believe they present a once in a generation opportunity for a step function change in how we use technology. There is a lot of pessimism about the space right now, after the unrealistic craziness that was the 2018 bubble when Bitcoin hit $19,000 but I am excited about where the tech is going.

I spoke at a panel at the Coinvention Conference on the Philly Blockchain scene (Thanks Mike) as well as at the inaugural session of the Drexel Blockchain club (Thanks Adit)

That’s me, that pink blob there!

Besides these, I did work on a LOT of JavaScript and Rails which has been pretty rewarding and learned a lot about Google’s cloud infrastructure, specially Firebase. I need to distill a lot of that into a future blogpost

Reading

I did a fair bit of reading this year but I did abandon a lot of books halfway. I am trying to be okay with that rather than pushing through a bad book, just to complete it. I wish there was a better app than Goodreads for books though

Misc

Some other things that happened this year:

  • Philly Google Developer Group (GDG) continues to go strong in its 8th (!) year since its start as AndroidPhilly in 2011. Its a great community that I look forward to meeting at least once a month and have made some great friends there.
  • I didn’t travel as much for work this year, which was good. My favorite event though was the MIT Media Lab’s Fall Member Event. I do like all the demos that the Media Labs groups present but the best part is the talks with other sponsors from different organizations.
  • I worked with a lot of interns and co-ops this year, mostly from Drexel, and I loved it. These guys and girls are smart, enthusiastic and I find conversations with them refreshing since they question a lot of assumptions I often have. Maybe I should consider some work in academia πŸ˜‰

2019 is guaranteed to be a year of many changes and I am excited for most of them. Stay tuned.