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.

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.

Using Symlinked Node libraries with React Native 0.55

I recently updated the React Native app I have been working on for a while from RN 0.47 to 0.55. I’ll admit I was a bit callous about the update and hadn’t really looked at the change log, but hey, version control does give one a foolish sense of bravado.

Anyway, needless to say there were issues. As of RN 0.55.4, the `setJSMainModuleName` has been renamed to `setJSMainModulePath` and it took me a bit of sleuthing to figure that out (Find the Github commit here)

However a bigger issue came up when I tried to package the app after resolving the compile errors.

Screen Shot 2018-05-16 at 1.19.27 AM

Turns out the new Metro packager cannot follow symlinks, like those created by npm-link

This was a total fail for me, since my app uses local npm modules to hold pieces of common code for the web and mobile clients.

Thankfully someone did come up with a bit of a hack that generates absolute paths for all symlinked libraries and launches the cli.js file of the packager with a config file with the list of absolute paths.

It works for now, but hopefully this bug will get fixed soon.

Building CodeCoin: A Blockchain DApp prototype

If you know me, there is a good chance that you know how πŸ‘Β I am about Blockchain and Decentralized apps. I have given a few talks on it but till recently these were mostly either focused on Bitcoin or on the academics of Blockchain technology. At a recent Comcast Labweek, I was finally able to get my hands dirty with building a Blockchain based decentralized app (DApp) on Ethereum.

Labweek is a week long hackathon at the T&P org in Comcast that lets people work on pretty much anything. I was pretty fortunate to end up working with a bunch of really smart engineers here. The problem we decided to look into was the challenge of funding open source projects. I am pretty passionate about open source technologies but I have seen great ideas die on Github because supporting a project when you aren’t getting paid for it is really hard.Β Our solution to this problem was a bounty system for Github issues that we called CodeCoin.

The way CodeCoin worked was as follows:

  • A project using CodeCoin would sign up on our site and download some Git hooks.
  • When anyone creates an issue on Github, we create an Ethereum wallet for the issue and post the wallet address back to Github so its the first comment on the issue.
  • We use a Chrome extension that adds a “Fund this issue” button on the Github page that starts the Ethereum payment flow.
  • To actually handle the payment, we require MetaMask that we can trigger using its JavaScript api
  • Ether is held in the wallet till the issue is marked resolved and merged into master. At this time another Git hook fires that tells our server to release the Ether into the wallets of all the developers who worked on the issue.

app-screen.png
Issue page design. Most of the UI changes came from a custom Chrome extension

flow.png
Application Flow

Note that while we held the Ether on our side in wallets, the right way to do this would have been to use a Smart Contract. We started down that route but since most of the code was done in like 2 days (while juggling other real projects), wallets seemed like the easier route.

Releasing money into developer accounts was also a hack. Since developers don’t sign up to Github with any digital wallet address, we need the wallet addresses as part of the final commit message. This could be done with a lookup on a service like Keybase.IO maybe and with more time we would have tried integrating it to our prototype. In fact it was the next week that I heard about their own Git offering. I haven’t read enough about that yet though.

Development notes:

  • For local development, we used the TestRPC library to run a Ethereum chain simulation on our machine.
  • We used web3js, the Ethereum JavaScript api for doing most of the actual transactions
  • Web3js was injected into the browser by the MetaMask extension. There were some challenges getting Metamask to talk to the TestRPC. Basically, you had to make sure that you initialized MetaMask with the same seed words as you used for your account on TestRPC (which makes sense) but there isn’t a way afaik to change that information in MetaMask. Early on, we were restarting TestRPC without configuring the initial accounts so we’d have to reinstall MetaMask to configure it with the new account. Chalk that to our own unfamiliarity with the whole setup.

metamask
MetaMask transaction

  • We did try to use Solidity to run a smart contract on TestRPC which worked for the demo apps, but canned that effort in the last moment as we were running out of time

All in all, it was a fun couple of days of intense coding and I feel I learnt a lot. Most of all I enjoyed working with a group of really smart peers, most of whom I didn’t know before the project at all. Hopefully we get to do more of that in the future πŸ™‚

IMG_0310.jpg

 

Notes from Oculus Connect 4

I had a great time last week attending Oculus Connect 4. Just like last year, the keynotes were really interesting and the sessions pretty informative. Here are some quick thoughts on the whole event:

Oculus Go and Santa Cruz

Oculus announced two new self contained headsets: the Go, a 3DoF inexpensive ($199) headset that will be coming early next year and much later, Project Santa Cruz, the 6DoF headset with inside-out tracking. Whats interesting is that both these devices will run mobile CPU/GPUs which means that 3 of the 4 VR headsets released by Oculus will have mobile processing power. If you are a VR developer, you better be optimizing your code to run on low horsepower devices, not beefy gaming machines.

Image result for oculus go and santa cruz
Oculus Go

Both Go and Santa Cruz are running a fork of Android

The move to inexpensive hardware makes sense, since Oculus has declared it their goal to bring 1 billion people into VR (no time frame was given πŸ˜‰ )

Oculus Dash and new Home Experience

The older Oculus Home experience is also going away in favor of the new Dash dashboard that you’ll be able to bring up within any application. Additionally you’ll be able to pin certain screens from Dash enabled applications (which based on John Carmack‘s talk seem to be just Android apks). There could be an interesting rise of apps dedicated to this experience, kinda like Dashboard widgets for Mac when that was a thing.

Image result for Oculus Dash
Oculus Dash

The removal of the app-launcher from Oculus Home means Home now becomes a personal space that you can modify with props and environments to your liking. It looks beautiful, though not very useful. Hopefully it lasts longer than PlayStation’s Home

 

Image result for new Oculus Home Connect 4
New Oculus Home (pic from TechCrunch,com)

 

New Avatars

The Oculus Avatars have also undergone a change. They no longer have the weird mono-color/ wax-dolls look but actually look more human with full color. This was also done to allow for custom props and costumes that you’ll be able to dress your avatar in in the future (go Capitalism πŸ˜‰ )

Image result for new Oculus avatars
New Avatars (Pic from VentureBeat.com)

Another change is that the new Avatars have eyes with pupils! The previous ones with pupil-less eyes creeped me out. The eyes have also been coded to follow things happening in the scene to make them feel more real.

Oh and finally, the Avatar SDK is going to go cross platform, which means if you use the Avatars inΒ  your app, you’ll be able to use them in other VR platforms as well like Vive and DayDream.

More Video

Oculus has been talking quite a bit lately about how Video is a huge use case for VR. A majority of use of VR seems to be in video applications, though detail on that wasn’t given. For example, apps like BigScreen that let you stream your PC cannot be classified as video or game since who knows whats being streamed. Also since the actual usage number of VR sessions wasn’t said, its hard to figure out if the video sessions count is a lot or not.

Either way, one of the big things that Carmack is working on is a better video experience. Apparently last year their main focus was better text rendering and now the focus is moving to video. The new video framework no longer uses Google’s ExoPlayer and improves the playback experience by syncing audio to locked video framerate rather than the other way as its done today.

Venues

One of the interesting things announced at Connect was Venues: a social experience for events like concerts, sports etc. It will be interesting to see how that goes.

Image result for oculus venues
Oculus Venues

There were numerous other talks that were interesting, from Lessons from One Year of Facebook Social to analyzing what is working in the app store. All the videos are on their YouTube Channel

Conclusion:

While I was wowed by a lot of the technology presented, it definitely feels like VR has a Crossing the Chasm problem: They have a pretty passionate alpha-user base but are trying really hard to actually get the larger non-gaming-centric audience in.

Image result for Crossing the Chasm

Oculus Go seems like a good idea to get the hardware and experience more widely distributed but what is really needed is that killer app that you really have to try in VR. The technology pieces are right there for the entrepreneur with the right idea.