Howdy folks! I’ve been thinking about and studying Machine Learning off and on for a year or more now, and have recently started writing another blog covering my thoughts on that subject. If you’re interested in that sort of thing and would like to follow along, come join me at ML Nexus! I’d be glad to have your perspective on the things I’m covering there.
February 6, 2018 Update: I figured out a workflow with the experimental .NET 4.6 support in Unity to actually make this work with Daydream, and have updated the workflow here. This solves the annoying caveat that I’d previously posted.
Swagger (aka OpenAPI) lets you define API structure in a machine-readable way. This allows all kinds of cool functionality: automatic docs, code generation across languages, etc. Here’s the workflow we’ve devised for consuming Swagger APIs in Unity. (Note: I’ve tested this on a Mac, but haven’t tried it on a PC yet.)
- Load your Swagger specification into the editor at https://app.swaggerhub.com/. (The easiest way is just to copy and paste it into the editor window.)
- Verify that the auto-generated documentation on the right looks correct.
- Choose “Csharp” from the “Download → Client” dropdown.
- Unzip the downloaded
- Open a terminal window.
- Go to the directory of the new unzipped download. (e.g. “
- Build your DLL:
build.batif you’re on windows.
- Your DLL is now in the “bin” subdirectory of the downloaded folder and is called “IO.Swagger.dll”. Copy this to your “Scripts” folder in Unity.
- Find “Newtonsoft.Json.dll” (
packages/Newtonsoft.Json.10.0.3/lib/net45/Newtonsoft.Json.dll) and copy it to your “Scripts” folder in Unity.
- Find “RestSharp.Net2.dll” (
packages/RestSharp.105.1.0/lib/net452/RestSharp.dll) and copy it to your “Scripts” folder in Unity.
- You’ll also need to round up the DataAnnotations DLL from somewhere in your Unity package (
Unity.app/Contents/MonoBleedingEdge/lib/mono/4.5/System.ComponentModel.DataAnnotations.dll) and copy it into your “Scripts” folder in Unity.
- Unity loads the DLL and makes the IO.Swagger namespace available to you.
Take a look in the
docs folder of the project you downloaded from the Swagger editor. It includes nice Markup files with C# sample code documenting the APIs in your new DLL. The sample code makes a great starting point for accessing the DLL’s functionality.
Great Big Obnoxious Caveat:
This doesn’t currently work when running on Android due to this bug in Unity’s .NET implementation. We ended up doing a last-minute rewrite to use Best HTTP instead, which was a crying shame. Hoping this bug will indeed be fixed in the future and make this workflow viable on that platform.
About a year ago, I decided it was time for a career shift. I managed a fabulous team of mobile developers who were a joy to work with, but I missed creating things. I talked to my boss at Mutual Mobile about the problem; he encouraged me to chart out a way back to an engineer role within the company.
I thought carefully about my options. I could go back to iOS engineering, which my previous boss had done. He was delighted with the change and had no regrets whatever about stepping down from management to an engineering job. But I enjoy learning and figuring out new things and, while iOS is a fantastically enjoyable platform to develop for, iOS 10 seemed pretty mature. I moved from web development to mobile because the web stopped feeling like the wild west. Now I had the same sense about mobile.
So I looked at alternatives. Mutual Mobile had a months-old Virtual Reality practice at that point that was gaining steam. While I hadn’t yet spent any serious time with Unity, which the team uses for its work, my son and some of my fellow engineers both had and were clearly enjoying the experience.
I floated my plan to retool myself into a VR engineer to my boss and the VR team, all of whom were gracious enough to give it an enthusiastic thumbs-up. So in early 2017, I began a self-administered crash course in Unity and VR. I found Unity’s online training materials to be excellent, and by the time we executed my official transition to the VR team, I was able to jump in and contribute to the team without a problem.
(I was still green compared to the other two excellent engineers working on our projects, but made up for it by continuing to do management of our engineering and project management teams.)
I’ve now gotten to contribute to a Cardboard project and do all the engineering for an Oculus Rift project. (The former should be available in the mobile app stores soon, and the latter will be installed in the Bass Pro HQ in Springfield in a few weeks.) The team’s also doing work with several other really interesting clients; I’m excited about the work ahead.
Now that I’m past the initial hurdles in Unity, I’m learning things I think might benefit other developers and/or VR enthusiasts. Accordingly, I’m going to post things here to document my learning. My areas of particular interest include: Good Software Architecture in Unity, Cool Stuff our Team is Doing, Using Physical Props in VR, and Accessibility in VR.
If you’re interested in any of these areas or just in creating VR, please get in touch or just follow along. I’m excited about this next phase of my career, and will be happy to have company!
Over the past year, I’ve written a few articles for Mutual Mobile that I’ve never gotten around to posting here. They’re all more or less technical, so may not be interesting if you visit for personal and family stories. If you’d like to see any of these, they’re linked here.
I’ve just had the first article in a series published over at the Mutual Mobile Engineering Blog. It’s all about making Unit Testing more efficient and less repetitious. The article is written with a focus on iOS, but the principles can be applied more broadly as well.
I did a presentation at CocoaConf Dallas today on how, as a developer, to make your iOS apps usable by people with visual impairments. It was a lot of fun, and seemed to be well-received by the conference attendees. If you’d like to see the slides, you can download them here:
In addition, I announced an open source component I wrote to make accessibility testing easier for developers. It’s called SMAccessibilityOverlay. By adding it to an app under development, you can temporarily display an overlay that quickly shows what areas of the screen have been marked as accessible, and what labels are associated with those regions:
If you’d like to try it out in your app, you can download it from GitHub here. I’d also be delighted to have input on it, either in the form of suggestions (good) or code contributions (better) or encouraging beer purchases (best).
I was a fairly early backer of the much-publicized Pebble smart watch. After being wristwatch-free for years, I’ve been wearing mine for nearly a week now, and have some early first impressions I thought I’d share for the curious.
First off: it’s a good-looking timepiece. While the 144×168 screen resolution sounds almost absurdly low for those of us who have been spoiled by full-color retina displays, it look just fine in context. The high-contrast display technology is great, and is visible in a wide range of conditions. Being able to turn on the backlight with a quick wrist-flick is terrific, though it does make playing hide-and-seek in the dark more challenging (as my kids will attest).
The on-device software is solid and well thought-out, with a clear, usable interface a bit reminiscent of the original iPod. Scroll views show a shadow at the top or bottom if there’s more content to display. Controlling music works like a charm with the built-in music app or any others that use Apple’s media control APIs. (Combined with Pandora and Apple TV, I can control music streaming from the Internet through my home sound system from my wrist. It’s the future!)
The included watch faces are fairly varied and interesting, with the binary display being a favorite of mine, though it takes me 10 seconds to figure out the time when someone asks me. And thanks to the support for notifications, I’ve known what those incessant chirrups coming from my phone are about without having to fish it out of my pocket.
Funnily enough, my biggest beefs with the out-of-the-box experience have to do with iOS. Pebble is taking advantage of some newer features in iOS 6 that haven’t been widely used yet, and there are still some rough edges on Apple’s side of things. Notifications have to be reset whenever the Pebble and phone lose contact with each other (which includes restarting either device, using Airplane mode, rebooting your phone for a system update, etc). Additionally, when the watch talks to the phone and the Pebble app isn’t already running in the background, iOS throws up an obtrusive alert telling you that the watch is trying to talk to the phone. It then launches the Pebble app into the foreground if you give it the permission to communicate it’s asking for.
There are, however, a few knocks I can level at the Pebble itself. If one gets multiple notifications in rapid succession — for example, when the mail app finds a few new messages in your inbox — the first notification immediately gives way to the latter, with no way to rewind and see the initial information.
The battery life doesn’t seem near as long as the advertised week. I admittedly haven’t run it into the ground yet, and I’m not 100% sure I gave it a full charge, since there’s no indication of charge status when it’s plugged in*, but so far it seems to last closer to 4 days than the week the company cites. (Oops — it just expired. Looks like the 4 day figure’s about right, and the low battery warning seems to appear 12-18 hours before it gives up the ghost.)
The most egregious problem, however, is the SDK. Or more precisely, the gaping hole where it should be. As detailed on http://www.ispebblesdkshipping.com/ (a spoof of Pebble’s own http://www.ispebbleshipping.com/), the kit that would allow developers to create new apps and watch faces for the Pebble was promised first for August 2012, then by January 23, then when the watch shipped. As of today, it still hasn’t turned up, and the company has been tight-lipped about what is causing the delay.
Given that the hardware specs have actually been improved since the Kickstarter finished, my hope is that the programmers are simply hoping to deliver something higher-quality and more capable than they’d initially planned on. The lack of communication, however, is a bit worrisome since many folks who have bought one of the devices did so out of a desire to be able to develop for it.
But overall, I’m happy with this first version of the Pebble. The existing functionality seems solid, and the possibilities for future improvements will be exciting once the SDK is finally out. If the company has to choose between putting something out soon that’s half-baked, or taking longer to create something they’re really proud of, it’s clear they choose the latter — a decision I applaud.
But now I have to go charge my watch.
* UPDATE: There actually is an indicator that lets you know when the watch is fully charged, but until the Pebble folks graciously pointed out the help page, I hadn’t been able to sort out the iconography they are using.
One of the best explanations I’ve ever seen of the appeal of what I currently get to do as a profession.
Why is programming fun? What delights may its practitioner expect as his reward?
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God’s delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child’s first clay pencil holder “for Daddy’s office.”
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.)
Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.
Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men.
From The Mythical Man-Month, by Frederick P. Brooks, via Federico Grilli
…we didn’t have fancy 3D graphics! We had half-acre pixels and 8 colors and we liked it!
Today while visiting garage sales with my lovely bride, I stumbled across an October 1982 National Geographic with these ads for game consoles of the day. I was 12 when these ads were run, and remember fondly many hours whiled away with friends playing both Atari and Intellivision. (I never did much with the Odyssey², probably because I saw these ads and the “wizard” gave me nightmares.)