Code Haven

Moving Ahead

I dealt with my fears from last week by taking action. I did what I needed to do and got back to work. I hope never to repeat the dream I had last Friday night, though I accept my subconscious may feel differently.

I also allowed myself to be vulnerable on the blog. In the past, I’ve shied away from that. But if this is really going to be a record of my time, it shouldn’t be “all good, all the time.” It should reflect what I’m feeling and thinking, as much as possible, within the scope of things I write about here. It was scary to write those posts, but the story wouldn’t be complete without them.

On the lighter side, I started booking spring travel (several conferences lined up, both presenting and attending) and also booked a place in Iceland during winter, so I can see the Northern Lights. I’ve wanted to do this for decades, so I’m thrilled to have it on the calendar.


The Flow and the Ebb

I loved SXSW. I sat up-front center for as many sessions as possible. I introduced myself instead of vanishing after each session. And my presentation at the TechBreakfast there went great: I talked with dozens of potential users, validated my product idea, and met amazing people who I want to know for many years. I also allowed myself to enjoy serendipity. I kept returning to a Peruvian food truck because every time I went there, I met someone interesting.

Back in the NYC area, I’m completing a new course on GitHub basics and writing an intermediate course on GitHub gymnastics. I continue to sell my first course on programming concepts for true beginners. I’m speaking at a security conference in May on a topic related to my master’s thesis, and then plan to transform the thesis and the talk into courses as well. I’m continuing to build out my software, focusing on the open-source plugin and adding features requested by potential users.

And I keep doing things that scare me. My mission statement is to say YES when I’m scared and see what happens. So far I feel right about everything, even though I also feel uncertain about where the edge lies or what awaits me there. I remind myself that no one ever really knows what they’re doing, and as long as I’m adding value I’m doing okay.

Drop-Ship. Pack. Pray. SXSW.

I’m waiting to board my flight for SXSW. I’m excited and plan to have fun — I’m also presenting my Plain English Programming project at a breakfast event and hope to have fun doing that too!

I feel like a mobile shipping and delivery hub. I have no printer and three small bags with me while traveling, so I sent my (thankfully simple) print order to a FedEx Kinko’s. I’ve ordered more business cards, plus project cards for my demo and coupon cards for my basic-programming-concepts course, which should be hand-delivered Friday while I’m roaming the conference. I ordered a kiosk’s worth of DIY setup items from Amazon, heading to where I’m staying and hopefully arriving while I’m home, and identified a nearby Staples that I’m using as a pickup hub for anything I forget/forgot. I’ll be surprised if everything works as intended, but if enough pieces come together — or I know soon enough which pieces won’t come together — I’ll be good to go.

This is actually kind of fun, in a shipping- and conference-logistics-hub kind of way. Not what I planned when I initially registered for SXSW, but infinitely better in its own way. If this all works out, I’ll post a DIY kiosk how-to on this blog.

Boarding soon, more later.

What I’ve Been Doing

I spent February doing several things that are fun and also a first step toward fulfilling my Phase Two mission: Make useful things. (My Phase One mission was: Travel and learn.)

Programming in Plain English

I’m creating stand-alone software to let you program in plain English. I have a basic plugin version of the software working, which I’ll present at a SXSW TechBreakfast. If the fancier, fuzzier stand-alone software is also working well enough by then, I’ll demo that as well. It’s an iOS app and will also be a Mac app initially. Here’s a beta website for the project: Plain English Programming.

Short and Sweet Courses

I created a Udemy course called “Short and Sweet: Basic Programming Concepts in 2 Hours.” It was fun, frustrating and rewarding to create a two-hour course that presents the essential ideas of programming in real-world language, using pseudocode. The goal is to make it easier for students to learn any programming language after taking the course, and to understand good practices around program structure and refactoring. I’m happy with the end result (for now), I’m loving the ability to communicate instantly with my students and help them get past roadblocks and succeed, and I’ve made my first online revenue, which is exciting. The course is here, if you’re curious, and I’m including a coupon for blog readers: Short and Sweet: Basic Programming Concepts in 2 Hours

I’ve drafted an eBook to pair with the course and am planning my next courses in the Short and Sweet series. Initial feedback is that the concept is good: A Short and Sweet course will be the best, fastest, easiest intro to a topic — no oxymorons! I’ll be testing this premise some more and then launching my own course platform. Now that I have a course recording process down, it shouldn’t take me long to produce content.

Flashcard App Final Phase

I’ve hammered out many of the bugs in my flashcard app, which I plan to tailor as a study aid for each course I release. I’ll also release some stand-alone flashcard apps to help people study for various exams, starting with the NASM personal trainer exam, simply because it was the first test database I created for the app.

I have several other ideas swimming around in my head, mainly around how to help people learn and do more, better, faster. I’m really enjoying this phase of my sabbatical and will send updates. Apologies for the bat-cave moment on this blog, I know it was quiet here for a few weeks. I wasn’t sleeping :-)

Endangered Species: Concentration and Solitude

Other than ridicule, great thinkers and discoverers of the past had something else in common: lots of time to themselves to think and experiment.

Our amplification-loop world is making solitude a rare commodity and concentration a rare ability. We’ve gained exponential connectivity with others but should be aware of what we’re losing.

We can get a lot more information a lot faster. But what are we doing with it? The next great breakthroughs are waiting while we browse Facebook.

Do you remember how it felt to sit and read for hours, uninterrupted?

Concentration Rehab

I’m not sure how to rediscover concentration amid the noise, but I’m trying. Here are some ideas I’m testing:

1.    Schedule at least one day a month for solitude.
2.    Just breathe and think for a little while each day — even 15 minutes helps.
3.    Take a walk outside, alone.
4.    Read for five hours straight in a paper book, where a “Go to Facebook” option doesn’t exist.

A Blue-Sky Dilemma

Solitude as a team also should be more highly valued when an idea is off-the-map and likely to be rejected by status-quo decision makers. In all sorts of environments, ranging from large companies to Startup Weekend, I’ve seen truly interesting ideas eliminated early in collaborative processes because they fell outside of normal bounds.

Those are often the most promising ideas.

Crowds rarely make breakthroughs. They’re good at enforcing the status quo, and (if organized well) at generating incremental improvements. They also eventually popularize breakthroughs, but only after a sufficient number of early adopters look sufficiently cool enough to make them jealous.

I’m not saying that early validation of high-level ideas with customers is bad. If you’re considering an idea that’s not truly novel, it’s a great thing to do. But vetting blue-sky ideas by committee or with customers is, I suspect, counterproductive in early days. The really great ideas are too impractical, too unlikely, too risky or anti-status quo to make it out of committee, unless you work at Google X.

Solitude Before Sharing?

For blue-sky ideas, a possible approach might be: Build solitude (or a small, trusted team that respects it), work hard, try new things, succeed  at a small scale, and then share.

It’s not as fun in the moment. Focusing intensely on a tough problem with no guarantee of a breakthrough often is not fun. It requires saying no to many things, giving up some trappings of respectability, and generally being perceived as odd. But it brings the possibility of doing something truly great, instead of just pretty good.

If people are telling you you’re crazy, you may have a truly terrible idea, or you may be on the right track. It’s difficult to parse that feedback, but it’s not always a stop-sign. The biggest stop-sign is feedback along the lines of, “Yeah, it’s okay. Go ahead.”

The Tyranny of Experts

We’re trapped in an expert-bound world.

If you’re not recognized as an expert by another team of experts, it’s difficult to reach an audience. This is true even if you really are an expert. If you spent thousands of hours pursuing mastery of economics but didn’t tell anyone about it, unless you get lucky a la Thomas Piketty, you’re shouting into a sea of noise.

This means trouble because throughout human history, many great discoveries came from lone thinkers and doers.

Leonardo da Vinci. Galileo. Mendel. Edward Jenner. Banting and Best. Einstein. Ignaz Semmelweis. Beethoven. Prometheus (mythologically speaking). Linus Torvalds (initially).

The TCP/IP Exception

There are exceptions, of course. TCP/IP. The Manhattan Project. Teamwork can work in a well-crafted atmosphere. But there’s a high failure rate in creating such an atmosphere.

And academia? It’s hard to say the modern academic environment, with profit-motivated grants and overwhelming politics, succeeds in creating a place where real breakthroughs are possible. More often, academics seem to be rewarded for incremental breakthroughs, not out-of-paradigm thinking.

High Volume, High Stakes

Granted, many of the great thinkers and discoverers listed above were ridiculed or persecuted.

But ridicule has a higher volume today, thanks to social media, the Internet, TV and worldwide communication. It’s hard to be just the village eccentric now.

Moreover, official experts often don’t dare look ridiculous by departing from the accepted quo. Even if they believe something different in private. Especially if believing something different could endanger their job.

That’s why innovation often comes from unexpected corners.

It’s a tough choice: Even if you’re right, you may be ridiculed and discredited; conversely, you could find acceptance and reward. If your discovery can make people money, chances are higher that your experience will be relatively good. If your discovery could cause people to lose a lot of money, you face a greater risk.

But even if what you have to say seems ridiculous, someone has to say it first.

GitHub Fails and Lessons Learned

I messed up my Xcode plugin yesterday. GitHub failed me, or rather, I failed GitHub. Then I fixed it and implemented better practices.

This blog post is an open, transparent attempt to share my mistakes and solutions.

For non-GitHub users, GitHub is sort of like Google Docs for software. It allows multiple software developers around the world to work together on software (relatively) seamlessly. So, if a software developer in Dubai makes a change, and another software developer in France makes a different change, those two changes can be merged into a single version of the software without significant hassle.

One Branch to Rule Them All

My first mistake was that I had only one GitHub branch: master. Initially, this worked well for me, because I used one laptop for development and pushed changes frequently from my local machine’s master branch to GitHub’s remote master branch.

Yesterday, I decided to push changes from a second machine, a test iMac with OS X Yosemite and Xcode 6 GM installed (for stability of the plugin, my laptop is still running Mavericks and Xcode 5/Xcode 6 beta. This turned out to be a good idea, at least until quirks are worked out).

Using the test iMac, I added the UUID (unique identification code) for Xcode 6 GM to my plugin. I did some limited testing (MAJOR MISTAKE) to verify functionality, pushed the code to GitHub’s master branch from the iMac, published a few more minor commits, and then pulled the new master version onto my laptop to make sure it also worked there.

Spoiler Alert!

The plugin did not work on my laptop. Previously functional commands produced no output. One command to create a for loop actually executed the Undo function instead! (If you’re not a software developer, just know that this is a bad kind of bug.) Most of these commands had worked fine on the test iMac.

Baffled, I decided to test every single command on the iMac (maybe I should have done this the first time, hmm?). I quickly discovered that with only one exception (of course, the one I’d tested before) my conditional-statement methods crashed Xcode. Some of the other methods that had produced no output on the laptop worked perfectly on the iMac. And entering slightly non-matching commands, which should produce no action, also crashed Xcode.

Clearly, my program now had crossed wires — and this crossed-wires version was the master branch on GitHub and the working version on my iMac and my laptop.

It was time to revert.

Don’t Cross the Streams

I researched how to revert GitHub commits. I wanted to roll back to a canonical, stable version that had worked with Xcode 5, and then go forward from there in a more measured way.

It turned out there were many ways to do this, many of which seemed complicated. The simplest way, doing a hard reset, was utterly bad practice (see: rewriting history) and I didn’t want to go there.

I found a Stack OverFlow answer that solved my dilemma. A poster there recommended doing this:

git revert –no-commit #######..HEAD (where ####### is the ID of the commit)
git commit -m “Commit message explaining what I just did”

This approach would revert all of the commits at once and re-create the state that had existed after the target commit. But it would not rewrite history by entirely removing old commits. Perfect.

Executing the Plan

First, in case something went wrong, I created a new branch with the old commit that I considered to be stable:

git checkout -b xcodestable #######
git push origin xcodestable

Then, reassured that I had a stable version stored on a separate branch, I switched back to the master branch and rolled it back to the old commit using the “git revert –no-commit” solution from Stack OverFlow:

git checkout master
git revert –no-commit #######..HEAD
git commit -m “Commit message explaining what I just did”
git push -u origin master

This seemed to work beautifully. But when I tried to run the plugin on my laptop, I encountered the same problems as before.

Into the Logs

Stymied in all other ways, I dealt with the situation I had in front of me and started logging messages to the console. I stepped through each process to see where things were going wrong.

To my surprise, the main problem appeared to be that many commands, after detecting the correct start point, were jumping into a method that adds items to an array. That method started with the word “Put “.

I had added case insensitivity to the plugin recently. That meant any text containing “put ” also would trigger the add-items-to-array method. For example, if the word “input” appeared anywhere in the code or comments, that would be a trigger. Whoops. I wasn’t sure why the case-insensitivity feature had worked perfectly when I first implemented and tested it, but it was breaking now.

I cleaned that up by making the command start point more specific (“Put item “) and built the program again. This time everything functioned. I tested every piece of functionality and then pushed it to the master branch:

git add –all
git commit -m “Functioning version”
git push -u origin master

Since everything was working, and the prior “stable” snapshot actually had not functioned correctly, I created a new stable branch from the functioning master branch:

git checkout -b xcode5stable2
git push origin xcode5stable2

Then I deleted the old, non-stable-after-all snapshot branch:

git push origin –delete xcode5stable
git branch -d xcode5stable

On to New Frontiers

At this point, the master branch functioned on my laptop and I had taken a snapshot (branch) of this stable state.

I still wanted to update the plugin for Yosemite and Xcode 6 GM functionality.

Unlike the last time, I decided not to do that on master. I created a new branch for testing new functionality, with the goal of merging it into the master branch once it verifiably worked on Mavericks and Yosemite:

git checkout -b newyosemite

Using the laptop, I opened the plist file as source code and added the Xcode 6 GM UUID. Then I built, re-tested every piece of functionality on the Mavericks laptop, and then pushed to the newyosemite branch.

git add –all
git commit -m “Now compatible with…”
git push -u origin newyosemite

Next Steps

The next step is to test this seemingly functional version on the test iMac with Yosemite. I’ll do that this weekend. I’m not sure if it will work, but I believe I found and fixed the major bug behind the wacky, unpredictable functionality. I also think I figured out what is causing another bug and have several ideas on how to make the code more robust.

My major takeaway is that no matter how small a project, better Git/GitHub practices are worthwhile. Specifically:

  • Preserve stable versions before major changes in a separate branch;
  • Make new changes in a separate branch before merging those changes into master; and, possibly most importantly:
  • Test ALL pieces of functionality before pushing or merging anything to branch master. Don’t just do spot tests.


Hacker School Gratitude Journal

I’m grateful for everything about Hacker School and this summer.

I’m grateful for the people who made this experience possible. I’m grateful for the programmers who shared their knowledge and welcomed me to share mine. I’m grateful for the friends I made, and the hours I spent in deep concentration, and for the fact that these two things were not mutually exclusive.

I’m grateful for the chance to attend this magical place.

I’m grateful for the community that extends beyond Hacker School and makes the motto, “Never graduate,” a real thing, so I can keep growing and learning and sharing and participating in different ways over time.

I’m grateful for idealism winning out over realism, and making reality more ideal. I’m grateful that my Xcode plugin worked. I’m grateful that I didn’t overthink the idea before starting to try to figure it out. I’m grateful for the help I got from people in and around Hacker School. I’m grateful for brainstorming sessions, the comfy couch to sit on, the amount I’ve learned, and the feeling of being surrounded by lots of motivated, curious people.

I’m grateful for the lovely apartments I had to stay in, the noise of trains over the Manhattan Bridge reminding me that things are always moving and shifting, reminding me to keep pace and keep pushing and change things.

I’m grateful for my roommates and the wonderful experiences I’ve had with them, and I’m grateful that I took the chance to push out of my comfort zone and into the world of adjusting to others. I’m grateful for the occasional privacy that balances out my experiment in living more cooperatively and nomadically.

I’m grateful for the awesome people in my life, and for serendipity.

I’m grateful for my health. I’m grateful for the great food I eat every day and the opportunity to try anything. I’m grateful for New York City and its never-ending options, and I’m grateful for my ability to focus.

I’m grateful for persistence and creativity, which are only good together and have allowed me to do all of this — everything I’ve done for the past few years, leading me to this point of creating and exploring and learning and enjoying the world.

I’m grateful for the tough weeks and the easy weeks and the mistakes and the things done right, and the amazing summer that all these things combined to create. I can feel that I will look back on this summer with utter thankfulness, probably when I’m tired and stressed-out and working hard and struggling to sleep enough. So I thought I’d start now and say

Thank You.

Hacker School, Week 9 Postscript

I can’t believe week 9 of Hacker School just ended. Because of varying start dates for different Hacker School batches, batch lengths can vary. My batch is 11 weeks long, not 12, so week 9 is pretty far toward the end.

I’m learning a lot. I feel like I’m on a march to get as much done as possible in the time allotted, though I know this is an artificial deadline. I’ll keep learning the next day after Hacker School ends, and the next, and the next.

Granted, I’ll be learning in a hammock on a farm in Italy, which will be a nice change of scenery and pace. Instead of going out for dinner when I’m hungry, I’ll pick tomatoes and bake some organic bread.

But I still feel pressure about the upcoming end of the batch.

One of the great things about Hacker School is its open-ended nature. “Never graduate” is their motto, and they mean it. I’ll still be able to visit the Hacker School space on Thursdays, nights and weekends after my batch ends, and I’ll be able to attend Monday night talks, which means I’ll continue meeting great people whenever I’m in New York.

But I won’t be in Hacker School. I’ve loved this experience for the pure learning-friendliness of it, and I’ll miss the feeling of shared focus. I don’t feel quite ready to leave, but at the same time it will be nice to find out what “post-Hacker School” means for me.

I’m putting together some lessons learned that I’ll post when I’m done and on my way.

How to Use NYC’s First Bitcoin ATM

NYC has a Bitcoin ATM. I found out a couple of weeks ago. I was thrilled, because I’d been hesitant to link my main real-world bank account with an online Bitcoin exchange. I’m sure the online exchanges and wallets take many security precautions, but the technology is still new and I don’t trust fully yet.

I was also too lazy to set up an alternate bank account solely to use it with a Bitcoin exchange.

So I decided to visit the Bitcoin ATM. As a tech geek with interests in security and new innovations, I’m curious about how Bitcoin works and wanted to try the process end-to-end.

Bitcoin ATM Step-by-Step

The Lamassu ATM is run by PYC Bitcoin and is installed at Flat 128, a boutique in the West Village. I was worried that the process of depositing might be cumbersome or might not work, but it was smooth and easy.

Here are the steps I followed:

1. I downloaded the free Bread Wallet app on iPhone. It was recommended to me by the ATM operator as a good, easy-to-use app, and after some App Store research, I agreed. Configuring the app took only a couple of minutes.

2. I went to the ATM at Flat 128 with cash.

3. I opened the Bread Wallet app on my iPhone, entered my PIN, and selected the “Receive Money” screen. I tried to scan my app’s QR code into the ATM but held it in front of the wrong place on the machine. Luckily, the sales clerk knew how the machine worked and showed me where to scan the code. (Scan it on the glass panel on the lower right of the ATM).

4. I deposited cash, and a tally on the screen showed how many Bitcoins I had purchased. I stopped at 1 Bitcoin, confirmed the transaction, and watched as my phone’s Bread Wallet app balance went to about $500. (Note: There is also about a 5% fee.)

In sum, the ATM transaction was easy and pleasant. (I’m not sure how easy withdrawing cash would be, since I didn’t try that.)

But I now had a lot of money on my smartphone — more than I was willing to leave there for the long haul.

Where to Put the Bitcoin?

I researched online and offline Bitcoin storage and decided to split my Bitcoins between Coinbase (a relatively established online Bitcoin wallet with an offline vault option) and a paper (printed, offline) wallet.

Establishing the Coinbase account was easy, and it took about an hour to verify and transfer my Bitcoin from the Bread Wallet app. Beyond this simple transfer, setting up two-factor authentication (better security) in Coinbase was a little more complex. I had to provide my phone number, download the “Authy” app, and type in a couple of codes and a backup email address.

To me, the process itself is interesting. I’m interested in learning more about how Bitcoin works and trying a few more different mechanisms, including using offline or paper storage, using a Coinbase Vault, making an online purchase from, and withdrawing cash from the ATM.

I’ll blog about it here.