2016: A Hung Truong Year in Review

It’s been a while since I wrote a year-in-review on this blog, let alone any blog post. 2016 was a big year though, so here’s some stuff I did.

In January Emily and I moved from Ann Arbor, Michigan where we had been living for a few years (Emily since grad school and me since the last time I moved back from Chicago in like 2012) to Seattle, Washington. I’ve loved Seattle ever since I moved here in 2009 to go work for Microsoft, and it’s great to be back! I’m working for a coffee company in Seattle called Starbucks (yes, I get free coffee). I get to work on their iOS app and make latte art in my spare time. Here are some highlights:


Latte art: Betta Fish (using almond milk)

A photo posted by Hung Truong (@hungtruong) on

Made a pumpkin latte art #latteart #meta #pumpkinlatte

A photo posted by Hung Truong (@hungtruong) on

For the first year that we’ve been here, Emily and I have been exploring the sights in Seattle, including a bunch of parks like Discovery Park, Volunteer Park (which has lots of cute baby ducks) and Seward Park, among others. With all the free coffee I’m getting, I’m also experimenting with different brew methods including Aeropress, cold brew, and most recently with a Kalita Wave.

In June I went to WWDC for the first time as an attendee and got to meet lots of other cool developers. I got a photo with Craig with the good hair who does the funny parts of the Apple keynotes. Next year I’m going to be attending a conference in the UK as a speaker, which I’m really excited about.

Last year I got a new digital camera which I started using quite a bit to capture our hikes and other interesting moments. This year I upgraded from the Sony RX-100 to the Fujifilm X-T1. It’s been really fun learning more about photography as a hobby and reading about lenses and techniques to get cool photo captures. Here’s a few shots that I like, taken from this year:

In September I bought a bunch of supplies and built a tiny solar powered charging system on my roof. It was a fun proof of concept and I’m using it to charge some of my lower power devices, including an electric bike that I bought for my commute (when it’s not rainy). I’m guessing that it wouldn’t have enough juice yet to power an electric car, but that’s on my to do list.

In October, Apple announced a new piece of hardware, so naturally I wrote a fart app for it.

That’s basically the noteworthy stuff that happened to me this year. Moving and getting used to Seattle is basically a full-time job. I’m also keeping myself busy with updating the house and automating it as much as possible using a Samsung SmartThings hub and various light switches, etc. Other random things I’ve been working on are experimenting with Instagram by using a copious number of tags in all of my posts, buying a pair of Snapchat Spectacles and experimenting with those, and cooking new recipes with the pressure cooker I just purchased from Amazon.

I’m looking forward to doing more stuff in 2017 and hopefully blogging about it more often as well.

On Writing Successful Fart Apps


Last Thursday, Apple held an event where they announced a few things, including a refresh of the Macbook Pro line that killed all of the good ports and added a touch bar to replace the function key row. I was actually in a meeting during the announcement but I had heard of the touch bar through a story about a leak. Someone on Twitter put a bounty of $5 on the first fart app for the touch bar and a friend retweeted it to me.

If you know me, you know that I like writing stupid apps and basically making a mockery of the Silicon Valley trope of “making the world a better place.” Specifically, the fart app genre appeals to me as a way to subvert the app ecosystem and make it a little more dumb and weird. The tech industry in particular takes itself way too seriously. In a way, I’m emulating my Computer Science hero Monzy, who created projects like “Pantscam” and  a program that morphed people’s faces into butts (which I can’t find the archive of at the moment), all while being a successful nerdcore rapper. While the things he made were somewhat stupid, you can’t deny that the technology was actually pretty cool.

Writing fart apps is also a great way to learn about a particular platform. If “hello world” is the simplest app that you can write in a language, a fart app is the simplest non-trivial app you can write, since it touches the UI, the file system and whatever mechanism there is for playing an audio file. In the past I wrote some fart apps for Google Glass and the Apple Watch, which were small enough projects that I didn’t get bored and abandon them, plus I learned something in the process.

So anyway, on Thursday I got home from work and installed Xcode 8.1 on my computer. I ended up needing to get another update for macOS Sierra to get the simulated Touch Bar to show up as well. I looked at some sample code, figured out what I needed to do to write the app and finished in maybe an hour or two. It was a good exercise to get reacquainted with macOS development after I stalled on a project I started a few years ago. I pushed the repo to Github, made a demo video and took a screenshot and sent some tweets to the Twitter user who requested the app. I also sent it to some other Twitter users who made similar requests, not expecting anyone to write a fart app less than 12 hours after the hardware for it was announced.

On Friday, I posted the Github repo to an iOS developer community on Slack. That’s pretty much all the “promotion” I did. At some point that day, someone posted the project on Product Hunt (good call!) and it kinda just sat there. I went out of town during the weekend but I noticed someone had written a story about the project on Cult of Mac. I figured that would be the apex of my touch bar fart app’s story. At some point during the weekend though, I got a tweet that the Product Hunt entry hit 100 upvotes. Then a few more stories were written today and my project was even mentioned in NatashaTheRobot’s Swift newsletter. I’m guessing that today will be the real apex of this fart app and it’ll slowly be forgotten like my other fart apps before it.

So what have I learned from this and previous fart apps? One is that some people take themselves way too seriously to enjoy a good fart app. For example, this person:

First, I’m not a kid. My job title has senior in it which must mean something! Also, I have a day job and writing fart apps (a.k.a. learning stuff) is my hobby. Finally, thanks to this hard-hitting piece of journalism, we see that even fart app writers can eventually move on to greater ambitions.

There’s also this killjoy from Product Hunt:

While I can understand the sentiment that there could be better tech things happening, I also don’t think it’s realistic to see a new Snapchat or Twitter released every single day. Friday was a slow day, so a fart app won! And is it just the subject matter that makes the project immature and pathetic? Like, would a British PM Soundboard be any more appropriate?

Bottom line is that this project only took a couple hours out of my free time, which I would’ve probably spent playing a JSRPG anyway. I suppose you could argue that the nonexistence of my app would’ve caused fewer people to waste time discussing it, but I can’t really control how other people spend their time.

One cool thing that’s come out of this project is that someone has already forked it and made a soundboard project out of it. This is sort of the whole point of writing an open source fart app: establish a codebase that people can check out, learn from, and maybe even extend into their own thing. I knew from the start that my app wasn’t going to make it into an App Store. I do believe that the Github repo was the first (public at least) to reference the NSTouchBar class.

Finally, if you are reading this blog post thinking: “hey, I’d like to be known for making a fart app instead of one of many other useful contributions I’ve made to this planet!” then here are some tips! First off, you need to actually be the first to market on the fart app scene as interest will surely wane as the second, third, fourth, etc fart apps written for the technology are released. Unless you add something really cool, like actual fart smells in addition to sounds, then you probably wanna rush your fart app to market. Second, you’ll need to market your app with some kind of video. When building for cutting edge hardware like the touch bar (which no one has yet) or Google Glass (which literally no one bought),  you can assume that no one will have the hardware or be interested in installing your app, so just make a video! In my experience it helps if you mumble a lot. Finally, share your code by making it available on Github and attach a generous license to it. I used the MIT license but put the wrong year because I copy-pasted it from another app. But I guess my mistake was relatable because more than one person commented on that commit! Your app won’t be worth anything anyway, so you might as well share it.

I hope this post has helped explain my motivations for making a touch bar fart app. Partly it’s to prove that I could, and partly make a cool $0.03 on the video ads.

P.S. Apple, if you are reading this, please do not ban me from WWDC over this. I promise to write some software using one of your new frameworks for non-fart applications!

Building a DIY Off-Grid Solar Bank on my Roof

I’ve been fascinated with solar energy ever since I was a kid and my brother had a toy with a motor attached to a mini solar panel that you could run under a strong light. In recent years, solar panels have come down in price and now seemed like a good a time as any for me to experiment with it a bit. I took a week long staycation from work a few weeks ago, and in preparation, I did a bunch of research and bought a ton of components to set up an off grid solar thing.

I chose to go off-grid because I didn’t want to deal with actually putting the power back into the grid and all the bureaucracy involved (I’m not sure if my power company even buys power back), and the scale I’m working at is super small anyway. Here are the components I used, and why I decided to go with them. They might not be the best choice, because I have no idea what I’m doing, but even so, I learned a lot in the process.

The Battery

As I was building an off-grid solar charging system,  I needed something to store the energy gathered by the panel. My initial goal with the project was to charge the battery on my electric bike. The bike is something like 12Ah at 48v, so overall the capacity is about 580 watt hours. I only let the bike battery drain to about 80% at most, so I wanted to charge about 100 watt hours at a time.

The type of battery I got was a lead acid sealed AGM battery, which is apparently pretty safe and commonly used in this sort of application. After doing some research about these batteries, it sounds like they also last longer if you only let them discharge to about 60-80% of their capacity, so I got a battery that holds 660 watt hours (12v * 55 Ah). I could probably have gone with a bigger battery but this one only cost about $100.

I had no idea what sort of connector this battery used when I bought it, but it turns out that it’s a pretty common connector that uses a bolt. The inverter I ended up buying worked out of the box with it and I ended up buying a box of additional eyelet adaptors to make my own wires.

The Solar Panel

I wanted a panel that would be able to charge up my battery to a decent level each day. I ended up getting probably more capacity than needed, but I can always expand my project later. I bought a 100W polycrystalline (because it was cheaper than mono) panel by Renology because it had good ratings and a good price to watt ratio. The connectors on the panel are MC4 so I ended up buying some additional cable so I could connect the panel to a charge controller.

The Charge Controller

I ended up getting a cheap charge controller that came at a discount in exchange for me writing a review. I was going to buy one that looked similar anyway, though I’m not sure if it’s the same manufacturer or just a knock off of the one I was going to buy. Either way it is the perfect size for my project at 10A and shows info like the current voltage level of the battery and the amperage going into the battery as well as the load coming out of the usb ports and the load out connectors.

I assumed you were supposed to connect the load out directly to an inverter but I read a few posts about how that would be a bad idea. I’m guessing too much load would fry your charge controller.

The Inverter

I was looking for a pure sine wave inverter, which is supposed to be more efficient and nice to your electronic devices, but I couldn’t find one under $100 so I ended up getting an 800W inverter that seemed pretty solid. As I mentioned earlier, the connectors just worked for the battery, which was nice. I only use one outlet at a time, so I haven’t tested if this thing can actually throw out 800W, but it’s probably a good rule of thumb to get an inverter with more capacity than you’ll need on average anyway. My bike battery charger uses about 140W and a Macbook charger will use 80W. I’m not sure how many watts that is after efficiency lost with the inverter but it’s probably not too terrible.

Putting it all together

After getting all of the parts I realized that I was missing the connection from the charge controller to the battery. I ended up buying some ringlet adapters that would fit the battery and cut off part of the long wire I bought to make a new wire. This worked better than I thought it would. After that, I was able to connect the panel and battery to the charge controller. I was able to read that the panel was giving something like 3 amps to the battery, which was amazing to me at the time.

I also connected the inverter to the battery and was able to run my bike charger. I attached my Smart Things outlet in between the outlet and the charger so I could monitor how much voltage the battery used. It’s interesting because once the battery reaches a certain charge, the charger tapers down its power usage slowly. Finally, I placed the panel on the roof, which was kind of difficult considering how tall the roof is and how short my ladder apparently is, plus how heavy the panel was and how much I’m able to lift above my head while also balancing on top of a ladder…

Here’s some photos of the system running just inside the door to the roof. I’ll probably set up a plank or something to drill the charge controller and inverter onto, since right now it’s a little janky.

This is the charge controller, battery and inverter charging my bike battery and an iPhone.
This is the charge controller, battery and inverter charging my bike battery and an iPhone.
The highest amperage I've seen is about 6, where I suppose the most the panel can give is 8.3 if it was on the surface of the sun.
The highest amperage I’ve seen is about 6, where I suppose the most the panel can give is 8.3 if it was on the surface of the sun.
Solar Panel
This is the solar panel before I got it on top of the roof

Hopefully you found this interesting and are already planning an off grid solar system of your own. I’m happy to say that my ebike is now powered 100% by my project, as well as a bunch of electronics in my house. Also, my house has become a lot more valuable in the case of a zombie apocalypse.

Strange Copy Pasta in Developer Resumes

A sample of some UIViews
A sample of some UIViews that are basic “functionalities” in a “Multi-view Application”

So for the past few weeks we’ve been trying to hire for a contractor position to work on our iOS app. Along with the rest of the team, I’ve been reviewing resumes on a really corporate looking website that have been submitted by recruiters on behalf of candidates. It’s an interesting exercise because the resumes are almost all in the same exact format and after a while, they really start to look the same. In some cases, this is because a candidate has been rejected and resubmitted accidentally.

While scanning through a bunch of resumes, my coworker Will noticed a bullet point that actually appeared in more than one person’s resume:

Experienced in creating and custom UIViews, Table Views, Tab Bars and Navigation Bar, which are some basic functionalities in a Multi-view Application.

There are a few things that stand out about this. The sentence itself runs on and on, and the grammar used is pretty dubious. Also, the inclusion of this into an iOS developer’s resume tells you nothing because every iOS developer should have experience with these elementary UI elements, and the sentence even sort of explains that at the end. The fact that it appears in more than one resume is surprising, since it’s such a stupid thing to include in your resume to begin with.

I was curious about this bullet point, so I suggested that Will paste the phrase into Google. Here’s an interesting slice of the results:

While there’s not a direct match, there are links to resumes which have slightly altered versions of the same phrase. The part that is mostly shared is the “…which are some basic functionality in a Multi view Application.” If you google for that, you will find pages and pages of resumes with a bullet point similar to the original. Will even started a tally of “mutations” of the phrase with added embellishments at the end, or with slightly better grammar.

I was curious which other phrases in these resumes were common, so I tried googling some of them. Some that I found that had become memes were:

  • Strong Knowledge of Software Development Life Cycle (SDLC) with strategically designing and implementing the software, debugging, fixing and maintaining the software.
  • Developed apps using various iOS design patterns (MVC, Delegation, Target-action and Slide-out Navigation).
  • Proficient in Memory Management: Automatic Reference Counting (ARC) and Manual Reference Counting (MRC).
  • Mobile Application Development (iPhone/iPad) using objective-C, UIKit, Core Location, MapKit, Cocoa Touch and Cocoa Service Frameworks.

I have a few guesses as to why these are in so many resumes verbatim. It could be that the candidate simply copied and pasted the bullet points from a friend’s resume and hopefully actually has those skills. Another could be that the recruiting firm offered to touch up their resume for them and did so lazily. While it’s easy to attribute this to malice, it’s probably just good old fashioned laziness. After all, if it works for so many developers, it should work for you! Either way it looks terrible for the candidate and it’s frustrating for people doing the hiring to see such a lack of originality. I already have to go through more than 30 resumes; I don’t want to think I’m going crazy with all the feelings of Deja Vu.

My recommendation to developers would be to write, in your own words, what you’ve actually accomplished. Resume writing is annoying, and no one likes doing it, but the downside to plagiarism is that I toss your resume out and assume you’re a terrible person. Also, I’m secretly hoping that this blog post becomes the top Google result for all of these copied bullet points so any curious resume-reviewers realize they’re not going insane. Also, feel free to nitpick my own outdated resume which you can find here on my (way outdated) portfolio site.

I haven’t gone in depth at all to discover more of these copied phrases, but I’m willing to bet that a big percentage of bullet points in resumes are simply ripped off from other resumes.

WWDC 2016 Recap

wwdc badge

As a beginning iOS developer, I remember learning a lot of the craft by trial and error, paired with many of the WWDC videos of years’ past. I was very lucky this year to 1) get chosen for the WWDC lottery and 2) work for a company that would support my trip to San Francisco. The week flew by and I went to some really interesting sessions. Here’s the things I found most interesting.


I’ve been developing some accessibility features since starting at Starbucks, and so I went to the What’s New in Accessibility session. The most interesting developer facing features are the improved Accessibility Inspector (which lets you quickly run accessibility audits, even in the simulator) and custom rotors for secondary actions. I’m still pretty new to accessibility but I imagine enabling custom rotors will be nice since I just used a hack with the headers rotor to enable skipping between content.

Swift APIs

Although I haven’t been writing much Swift at work (we’re just starting to adopt it), I went to the Swift API Design Guidelines session. It was interesting to note the conscious decisions to make Swift read grammatically, and how developers are reconciling that with the ways that Swift needs to be compatible with Objective-c APIs. The talk itself was really interesting and worth watching in full, because I’m not going to try to summarize it here!

WatchOS 3


As a person who actually bought an Apple Watch and still wears it every day, I would really like developers to take advantage of the performance gains in WatchOS 3, least of which is leaving apps in memory so they can load much faster! I was also really mesmerized by the power of rich notifications on the watch using SpriteKit and/or SceneKit. I’m worried that the watch is in a catch-22 right now where it’s not really worth the work to develop for it because there aren’t enough users, which aren’t using the watch because of the lack of good apps. Or it could be that the watch really just needs a good weather app and that’s it. Oh well.

Search APIs

I also went to a session about using search APIs like NSUserActivity and CoreSpotlight. I largely ignored these features in the past, but it would be pretty interesting to hook into the system in order to provide phone numbers or addresses to hand off to maps or some other apps that the user is switching to.

Other Stuff

I went to quite a few other sessions on things like iOS Photography (which I sort of just went to accidentally and stayed for) and iMessage integration and On-Demand Resources. Overall, the sessions were really great and I found it really nice to be able to attend a talk in person and absorb the knowledge without distractions. It’s true that the sessions are all available either streaming or online shortly after happening, but too often I’m watching a video while also working against some work deadline or only paying half attention. It’s also pretty neat to be among other iOS developers, and it’s kind of hard to believe that companies have a hard time hiring when you can see so many developers in one room!

Hair Force One

hair force one

Craig Federighi has become one of the best parts of Apple Keynotes as he’s equal parts funny and informative. Whenever he showed up in the conference center, huge lines of people would gather to take a photo with him. He’s a really tall dude and it’s really nice of him to put up with random iOS developer who want to take a photo with him.

The Jacket

wwdc jacket

I received what is apparently a tradition at WWDC; a jacket with the year on it. I immediately felt weird about getting a nice jacket that basically screams “I am the most elite of the elite, because either I or my company can pay $1600 for me to go to a developer conference!” I spotted a few jackets from earlier years in the conference center, as though it’s a way to show that you’ve been in this game for longer and you’re much cooler than people who just got their first jacket this year. I am in the process of de-labeling my jacket with nail polish remover (ask me about it if you’re interested!) and I’ll hopefully get to wear the jacket embarrassment free once the weather gets cooler (it’s a really nice jacket!). I am hoping that Apple stops giving these jackets out at some point and does something like, I dunno, plants a tree for each attendee? Then again, we are talking about a company that makes objects that people literally worship.

The Company Store

the company store

Speaking of products, there’s a company store set up in the conference center where you can buy shirts and baby stuff and hats with Apple logos on them. I was going to buy something but I realized that you’re literally paying $40 for the logo as the shirt itself is a fairly standard bella canvas tee. Plus I already have a WWDC jacket that asserts my dominance as an iOS developer!

In Closing

Again, I feel incredibly lucky to have been able to go to WWDC this year, for the first time ever. The keynote and sessions were really great and I got at least 3 ideas for future apps, which is a lot more than I’ve had in the past year or two. Hopefully I can go next year do it all over again.