Category: Uncategorized

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.

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.

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

 

 

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 😉 )

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.

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.

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.

I have been involved in a few VR projects this last year. While the earlier prototypes used Unity as the development environment, some of the new ones use WebVR, an emerging web standard for VR development.

WebVR, as opposed to native-app VR, does have a few advantages:

• JavaScript tooling is pretty good and getting better
• Automatically falls back to an in-browser 3D experience on non-VR devices
• Not having to compile the app to quickly check the changes in a browser is pretty awesome

The biggest thing though is that the kind of experiences we have always thought about: moving from one VR experience, is not possible in a series of native apps. I have heard the future of VR referred to as a “web of connected VR experiences” and that is the vision that is truly exciting.

That said, current tooling is much better for VR native apps with most tools focusing on Unity, which is really the de-facto tool for game developers. However I really hope the tooling on WebVR side starts getting better.

Developing for WebVR

The way we currently build for WebVR is by using AFrame, a VR framework built on top of WebGL primarily maintained by Mozilla and the WebVR community. AFrame is built on top of ThreeJS, the most popular 3D library for WebGL. For desktop VR development, the only desktop browser that you don’t have to finagle with too much is Firefox. Most of the development is done on Oculus Rifts connected to some beefy PCs.

Another tool worth noting is Glitch which provides instant development setups for JavaScript based apps. Glitch has been very useful to quickly try out an idea and share it internally. The develop -> preview flow is pretty straight forward.

The developer workflow for mobile VR development though is a different story. While our current prototype had no requirements to be mobile, I recently tried it on a Google’s Daydream and found a few bugs. Fixing those seemed trivial, but actually doing that was a lot more painful than I would have thought. Here are some problems I ran into:

Cannot start a WebVR experience from inside VR

Currently there is no available web browser that can launch from the DayDream VR home menu. While Chrome on Android supports WebVR and will trigger a “Insert into Headset” DayDream action when a user taps on a VR button on a WebVR experience, there is no way to get to that experience from within DayDream itself. You cannot pin a WebVR experience to your DayDream Home and WebVR experiences don’t appear in your recent VR apps section.

This is actually really frustrating. The workflow to debug a DayDream error is:

• Fix(?) bug
• On phone, go to Chrome, launch app
• Tap “VR” mode
• Insert phone into headset
• Verify Chrome Remote Debugger is still connected
• See if the bug still appears
• Pop phone out of headset

The constant popping of the phone in and out of the headset get old really fast. One option may be to add a “reload” button in your WebVR experience but I am not sure if that will work, since you aren’t supposed to be able to enter VR mode without an explicit user action (like a button tap)

One thought I did have was to create an Android app with the Manifest declaring it as a DayDream app, and then have its main view just be a WebView. Unfortunately that didn’t work, though I did get the app in the DayDream Home view. A different idea was to let this app launch Chrome with my WebVR app’s URL. Again, there were challenges: For one Chrome launched in conventional view and did not automatically trigger the VR split view for the left and right lenses. To add to this hack, I added a trigger to call AFrame’s enterVR() method when the page loaded which kinda worked but every launch caused this weird blink when the app went from 2D to VR mode that it was actually painful to use.

One HUGE tip in this workflow: Make sure you have enabled the DayDream debug menu selected the “Skip VR Entry Screens” without which the workflow mentioned adds like 2 more steps per debug.

Using Chrome Remote Debug

For a lot of my testing, all I needed was the console.log function from developer tools. You can see your logs using Chrome Developer Tools’ Remote Debug feature. Not sure I was doing it wrong but I kept losing connection to the active tab every time I reloaded the page to check. Really annoying. At the end of the day, I did discover the A-Frame Log Component, which I haven’t used yet, but intend to very soon.

Lack of a DayDream Controller Emulator

If you are developing for VR, your productivity is directly proportional to how much of the development you can do without putting on the headset. With WebVR, since your app automatically works in a browser, you can do a lot of development without the headset. Unfortunately this breaks down when you are trying to code around user interactions. You can use the Mouse as a raycast source which gets you partly there but you really want an emulator for the hand controllers to try different things out.

DayDream officially has an emulator for its controller, but that controller only seems to target Unity and Unreal based projects. There are other projects like DayFrame for AFrame but since my problem was specific to the DayDream controller, using a proxy emulator didn’t make much sense.

What I really wanted to do was to pair the official Google DayDream controller to my PC but I haven’t been able to find any way to do that yet.

Conclusion

I have been generally enjoying working with AFrame and it has a surprisingly (to me) strong community of active developers. However the developer workflows, esp for on-device testing, still need work. Ideally what I am looking for is a one click that deploys my WebVR app to a server and then launches DayDream pointed to the WebVR page running in fullscreen VR. Or even better, a WebVR/AFrame equivalent of Create React App or similar boilerplate projects, that automatically sets up all the best tools for developing and testing WebVR projects on both the browser and on-device.

 

 

Its interesting that for an industry pushing humanity into the future, Software engineering practices have not changed significantly in the last 50 years.  We are still using basic text editors with syntax highlighting, often on machines with hundreds of times the power of the devices they were originally designed for, an irony highlighted by Bret Victor in his talk linked below

I have been thinking about this for a while and collecting links on different ideas around this for the last few years. The deck below collects some of these ideas. If you have others that could be added, please leave a comment.

Other Links

An interesting article on exploring visual programming in Go. Some interesting points there on why visual programming failed

I was recently invited to give a talk at a Modev DC event held at the Capital One building. The slides are embedded below.

They are mostly based on my previous blog post on using React Native in an existing Android application which you can read here.

Thanks Modev, Luis and the Capital One team for having me over

I spent this entire week in the west coast attending North America GDG Managers’ Summit and the I/O events. I am still processing some of the conversations from the Managers’ summit and how to use them to improve GDG Philadelphia that I help run so I’ll leave that to a future blog post so this post is restricted to the I/O event only.

The list of announcements both big and small are a mile long and have been well covered by other publications. My own gist of the announcements is here (feel free to send me a pull request if you wanna add anything there). Here are some thoughts on just I/O this year:

AI All the Things

Google’s internal things to pepper their products with features only possible using AI is clearly bearing fruit. From just pure utility features like enhanced copy and paste on Android to flagship features like Google Lens that allows object recognition in photos and videos on Google Photo and Assistant. I am particularly excited by the TensorflowLite project and programming for AI is something I am going to learn this year.

Immersive Computing (VR / AR / MR / xR)

People seem to love coming up with new terminology in this space. Google buckets the VR/AR technologies into “Immersive Computing”. They are doing some really interesting things in this space and I am glad to see them continue to push the state of art here. I was particularly impressed by Project Seurat that uses algorithms to allow developers to use simpler geometry to mimic complex, even movie quality, 3D models.

On the Tango / Augmented Reality side, Google Visual Positioning System truly impresses as well. In fact in one conversation, a Googler mentioned that the Google Maps team was heavily involved in the VPS development.

There were also some great demos of AR capture and reconstruction using the upcoming Asus Zenphone AR. Big question is when does a Google Pixel get a depth sensor and Tango support?

Actions on Google

Google’s new Actions platform that lets you build skills for Google Assistant on the Home, Android and iPhone was very interesting. The tooling basically consists of 3 components:

• Actions on Google console that lets you manage your …um..actions
• The API.ai tier that your actions probably need to manage natural language input
• Chatbase, Google’s analytics platform for Chatbots that lets you observe your bots’ growth and engagement over time

I liked the system and it seems pretty trivial to make a simple Chatbot…I mean Action. They also announced a competition for the platform so get ready to see a lot of new ways you can order pizzas 😉

Android Dev

Android SDK + Firebase

Google continues to push Firebase as an essential part of Android development. Google cloud services have been catching up to AWS’ for a while and Firebase seems to be a great option to AWS Mobile. AWS’ tools are not friendly to a mobile developer and the Firebase tools do seem much more approachable. The addition of services like Performance Monitoring makes Firebase even more essential a part of the Android developers’ toolkit.

Google Play Developer Console Updates

I haven’t pushed anything to the Google Play Store since Picscribe in 2013. The publisher tools back then were functional and did a decent job I thought, but the latest updates to the publisher experience are fantastic. More tools to run A/B tests, greater visibility on top reasons for crashes, pre-release testing etc will allow developers to really optimize their apps just from the store.

Kotlin is an official second language for Android development

I am mostly ambivalent about Kotlin (😱). I had no particular issues with using Java for Android development, except maybe an occasional gripe about not being able to pass functions around. I am happy for Kotlin’s less verbose syntax but dread what happened with Swift’s introduction to the iOS ecosystem where the focus seemed to change from cool apps to various academic discussions (if I hear about monads one more time…).

Also the rapid evolution of the language meant that code examples and Stack Overflow answers stopped working in a few months. Lets hope this is less of an issue on the Android side.

And of course a new developer moving to Android now needs to know not only Java but Kotlin as well since the codebase will be a mix of the two.

On the flip side, the copy Java and paste as Kotlin feature in Android Studio is pretty dope

Cloud Functions: The rise of Lambdas

With so much functionality exposed as services from either Google or Amazon, developers can really power their apps with very little backend code development. That said, this leads to the rise in the need for some kind of glue layer that connects all these components together. Firebase’ Cloud Functions and Amazon’s Lambdas serve this need.  The workflow for Amazon Lambdas is still slightly awkward, but Firebase’s workflow feels a lot better.

Final thoughts

There were a lot for cool technologies for show at I/O and it was awesome. The other amazing part was just meeting old friends from across the world and even making some new ones.

I will also say this: This was one of the BEST organized events I have ever attended and kudos to Google for pulling it off. The session reservation system worked well, there was ample shade, food and drink and even they even got the weather to be nice for 3 days 😉

Till next year!

 

They say don’t bury the lede but I just gave it away in the title ;). Phildelphia Business Journal comes up with a list of 10 Tech Disruptors every year who are “blazing new trails and inspiring others in the technology community”. I am one of the 10 for this year, and in extremely smart company of local CEOs, CTOs and Founders.

Thanks for the honor @PHLBizJournal. Its great to see your name in the paper (well for the right reasons 😉 )

Over the last few years I have found myself defending QR codes in different conversations. While huge in the rest of the world, QR codes were never embraced in the west. Aesthetics was one that I had heard multiple times (“They are so ugly”) but they solved a real problem: bridging the offline world with the online one.

For whatever reason, neither Apple nor Google devices ship with a default QR code reader. Apple’s default camera app has some image recognition built in which lets you scan iTunes gift cards, but neither Apple nor (more surprisingly) Google showed any interest in QR codes. (Update: Apple added QR support for the default camera app in iOS 11)

But QR codes have snuck up in our society in the last few years. Some of these aren’t normal QR codes and maybe deserve their own label (scan codes?) but the idea remains the same: a graphic that codifies text that a scanner (camera) can read from a distance.

• Snapchat popularized the idea with their Snapcodes that let users add other Snapchat users as friends.
• Twitter, Kik, Facebook Messenger and Google Allo followed and now scanning a code to initiate a connection is starting to become normal.

• Apps like the desktop experience for WhatsApp and the rumored upcoming desktop experience for Google Allo use QR codes to authorize their desktop accounts with the mobile ones
• Airline and train tickets are using QR codes for their mobile boarding passes.
• Windows’ error reporting

Today, at F8, Facebook’s big developer event, they announced that Messenger will now support their scan-code, what they call Parametric Codes, which you’ll be able to use to do all sorts of things from friending to payments (offline payments via scan-codes is a big deal in China, where Messenger is taking a lot of its feature development cues from).

As happy as I am to see the return of these codes, the proprietary nature of each of them is a little bit of a bummer, but hopefully they will make the idea of scanning a code to connect with the real world more mainstream.

Update:

YCombinator Blog has a very interesting article on the rise of WeChat, but this section on QR codes is especially interesting

WeChat’s elevation of the QR code as a link from the offline became the lynchpin for China’s online-to-offline boom in 2015. Previously, to engage with a service or brand, a user would have to search or enter a website address. WeChat’s Pony Ma says of QR codes, “it is a label of abundant online information attached to the offline world”. This logic explains why WeChat chose to promote QR codes in the first place. QR codes never took off in the U.S. for three key reasons: (1) the #1 phone and the #1 social app didn’t allow you to scan QR codes. (2) Because of this, people had to download dedicated scanner apps, and then the QR code would take them to a mobile website, which is arguably more cumbersome than simply typing in the URL or searching for the brand on social media. (3) Early use cases focused on low-value, marketing related content and at times was merely spam. So, even though QR codes would’ve been U.S. marketers’ dream, it was a few steps too far to be useful.

With the established adoption of QR codes, WeChat launched “Mini Programs” as an extension of WeChat Official Accounts designed to enable users to access services in a more frictionless way just like the web browser did

I am currently working on a web portal for showcasing our teams’ different projects, white-papers and reports. Given the limited scope of the project, we thought it might be a good idea to try it with a full JavaScript stack of  MongoDB, Express and ReactJS.

Since the site needed both a user facing portal and an admin portal, we started building both of those in parallel but as separate projects. The goal was to keep the admin portal independent of the actual site itself. The pages on the site are also more or less completely defined in JSON schemas so it could be reused in the future if we ever wanted to use it for a different project or release it as an open source project.

The Create-React-App library from Facebook was really useful for a pretty painless start to the projects.

Proxying calls to the API

The first issue I ran into was accessing Express that was running on a different port (3000) than Create-React-App’s development server (3001). Since the browser considered these two different sites, browser security wouldn’t let be make API calls to the server from the client. Figuring it was a problem for later, I just allowed the dev server to handle CORS requests using something like:

app.use(function(req, res, next) { 
    res.header("Access-Control-Allow-Origin", "*"); next(); 
});

This worked for all GET requests but completely failed when I tried to POST JSON from the client. Turns out when sending JSON, the browser pre-flights the POST request with an OPTIONS request that I was not handling at all. As found in the MDN docs:

The [CORS] specification mandates that browsers "preflight" 
the request, soliciting supported methods from the server with an 
HTTP OPTIONS request method, and then, upon "approval" from the server, 
sending the actual request with the actual HTTP request method.

Turns out, all the headache was for nothing. Create-React-Apps allows you to proxy calls to a dev server by adding a proxy line in your package.json

"proxy": "http://localhost:3000/",

Packaging React Apps for different server paths

Another issue was that Create-React-Apps by default assumes the final built app will be served from the root of the server. It took a bit of finding out that the it does allow you to set the folder path for your app on the server using the homepage field in the package.json:

"homepage": "http://localhost:3000/admin",

Allowing Express to serve multiple React Apps

Finally as we tried to deploy the front end and the admin app, we ran into another issue. Since Express needed to serve front-end from the server root, admin from the /admin/ path and also a bunch of different api responses from /api urls, we had to do a bit of trial and error to get the pathing for the resources right. Our final response paths for the Express app look like this:

// API end points defined first
app.get("/api/projects",  (req, res)=>{})
app.post("/api/project",  (req, res)=>{})

// Admin paths
app.use('/admin/', express.static(path.join(__dirname, 'admin')))
app.get('/admin/*', function (req, res) {
 res.sendFile(path.join(__dirname, './admin', 'index.html'));
});

// Site path
app.use('/', express.static(path.join(__dirname, 'front-end')))
app.get('/*', function (req, res) {
 res.sendFile(path.join(__dirname, 'front-end', 'index.html'));
});

This is still work in progress and I am sure a lot more learnings will come going forward, but at right now, with the first version of the site deployed to our dev server, I am gonna get a well earned beer 🙂

 

Today’s news of the post-acquisition Yahoo being called Altaba made me think of the Yahoo I have known (and for a while loved) for the last 20+ years.

While AOL may have been America’s portal, Yahoo was ours in India. I was a happy enough Yahoo Mail, Yahoo Groups and Yahoo News user but what I was really addicted to was Yahoo Chat and Yahoo Messenger. Yahoo Chat was fantastic. The basic functionality was yahgood enough but I got really addicted to their IMvironments: mini flash-based experiences that you could play in while chatting.

I spent hours on it in different chat rooms and even made 2 of my closest friends on a Yahoo India chat room. The first of those friends was a girl from Romania named Anca. We talked a lot about our individual countries and that made me fairly knowledgable about Romania, a country I never really thought of otherwise. When I went to grad school at Rutgers, I ended up sitting next to a very quiet guy during one of the international student orientation sessions. He opened up when he mentioned he was from Romania and we could connect on that. That guy, Nicu, ended up being my best friend in grad school and is single-handedly responsible for me not dropping out of grad school when I struggled with writing code (I had never written code before having majored in Electronics in undergrad) and suddenly doing graduate level and research level C++ programming put me way out of my depth. Nicu, who had by then worked for a couple of years as a Software Engineer in Germany sat with me for HOURS teaching me programming concepts and helping me with my assignments.

So in a way I might owe Yahoo for my entire career 😉

As I became a web developer, Yahoo was one of the technology companies I envied. They were always building amazing pieces of technology. Some pieces of technology I was fascinated by and worked with included:

• YUI which was THE user interface library for web experiences,
• YSlow which I used a LOT when I was developing web apps
• Yahoo Widgets, which was the Konfabulator app that Yahoo bought, that I wrote a couple of widgets for
• BrowserPlus, which apparently I was a fan of at some point (Who remembers?!)
• Yahoo Cocktails, a JavaScript based platform that powered their LiveStand iPad app.
• YQL, a query language that mapped web apis like SQL queries.

In fact, I even went to a Yahoo Hack Day in NY a while back and my friend Gabo and I ended up building an AIR app for YQL queries (we didn’t win though 😦 )

This list doesn’t include other amazing tech that came out of Yahoo like Hadoop etc that I never interacted with.

I also interacted with Yahoo a fair bit professionally, when Comcast and Yahoo struck an ad deal in 2007 and I was responsible for integrating their video ad system (that didn’t exist) into The Fan video player that I was leading the development for. It was also one of my favorite engineering stories to tell but that is a story for another time 😉

Thanks for the memories Yahoo.

 

As some of you may know I have been very interested in Bitcoin and blockchains for the past couple of years and have been digging into it even more lately as part of my day job. However, blockchains have been in the news a lot lately to the point where it often feels like its a solution looking for a problem. Sure, blockchains are the sexy new tech but here are some questions you need to ask when debating looking into blockchains as a solution to your problem:

• Can you deal with transparency? Writing to a public blockchain is may be a difficult new way of working (as banks are starting to find out). There is also a huge mindset today that considers data an asset that could be profitable and not worth sharing (though with the increasing risk of hackers and data breaches, its worth considering if your big data is an asset or a liability?)
• Do you need immutable history? A huge value of the blockchain is in the fact that the blockchain is a record of history that can never be modified. Certain initiatives around blockchains with super users that can rewrite history completely negate the core trust mechanism of the blockchain. However there may be data that is incorrectly reported at times. Does your data consist of absolute truths or may need to be corrected once in a while?
• Will you have untrusted peers or the network? One of the big reasons to adopt a blockchain is in environments of limited trust. If the only people that can write to a blockchain need to be authorized in a different way, you are just trading your current problem for a new one.
• Can you keep your blockchain from being hijacked? If you do have untrusted peers on a network, and your network is fairly small, can a peer take over your blockchain with a 51% attack?
• Can you just leverage the Bitcoin blockchain? Keeping an operational blockchain is work and needs nodes and miners that are incentivized to maintain it. What kind of rewards do you offer that make your chain worth working on? If you don’t have the right incentives in place, your blockchain may not outlive the individual or corporate curiosity that spawned the idea. A better idea may be to write it or, more likely, a hash of it to the Bitcoin blockchain making it a part of the official history and something that will exist even if your project dies.

There is a huge tendency to fixate on the distributed nature of the blockchain, but if that is your sole goal, there are other distributed database technologies that you should be looking into.