Tag Archive: Programming

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

FacebookTwitterGoogle+Share

Los Angeles, Again

Apologies for my absence from the blog for the past few weeks; I spent the time immersed in Udemy, getting my new course ready for publication. It’s submitted for review now, waiting only for an image before it gets set live. I’m super-excited and will let you know more when it’s released.

I’m spending the winter in Los Angeles.

I promised myself last winter, as I was freezing in my NYC apartment with the heat cranked up to max and my poor tree actually leaning away from the window to escape the polar vortex (who knew trees even DID that?), that if I actually went ahead and pursued this plan to travel and learn and find a new path, I’d spend the winter someplace warm.

I chose L.A. I’ve lived here before, for four-plus years in the early 2000s, and I know where to go, where to avoid, where to relax, where to hike. Most of all, I have friends here who I’m looking forward to spending time with, making the city feel more like a village hamlet or a reunion than a sprawling sprawl.

I’m already feeling the pull of L.A.’s unique rhythm, the blend of seasons into endlessness, the no-hurry mornings and the bright blue perfection, though now I am uniquely qualified to fight it with productivity. I spent the last seven years in New York, where busy-ness is a way of life, even when it’s fabricated.

I remember traveling around L.A. when I was working in journalism, wondering as I passed by cafes in the middle of the day, “Who are all these idle people?”

Now I am one of those people. But I’m not idle. In the past month I’ve doubled down on my (now-working!) Xcode plugin, signed up to present it at a SXSW breakfast, added new capabilities and started planning a standalone software product; created a Udemy course to teach basic programming concepts to would-be programmers, non-technical co-founders, and parents and teachers; and fixed major bugs in my flashcard app that were preventing progress. I’ve spoken with a lawyer about creating a company and am prepared to move forward.

I expect to launch all of these projects by the time I leave in March, along with an organic food finder I prototyped last summer. It’ll be an interesting couple of months.

Then I’ll see what sticks.

In the meantime, I’ll enjoy being productive in the midst of laid-back L.A. I’m also trying to get back on track with my organic, hack-your-health lifestyle, which I decided a few years ago was non-optional if I wanted to live an optimal life. It’s super-successful for me when I’m on-board with it, so I’m back on board and ready to enjoy my (non)-winter.

73 degrees. I love it. Lots of work to do.

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.

Hacker School: Week 7

I’m in the second half of Hacker School, feeling short of time and not sure what to do about it. My only option is to keep showing up every day and getting things done. I sit at a long table in a huge room or abscond to my personal favorite work space, a living-room-like corner with a high ceiling, a metric ton of computer books, and a metal staircase leading up to a door that doesn’t open.

On a beanbag or couch in this corner, surrounded by books and people hacking on projects and a robot mural painted on the wall, I feel equally at home and unsettled.

After focusing on C for two weeks and then an Xcode plugin for a month, I’m switching my “learning” focus to JavaScript and node.js. I’m using the excellent Learn JavaScript Properly outline suggested by Richard of Stanley, and so far it’s going well.

Turns out I like JavaScript. A lot.

This is sort of a surprise to me, because I’ve heard JavaScript is weird. Inconsistent. Unreliable, even.

But I resonate with the C-based parts of the syntax, and it’s helping me understand the function-based parts that aren’t quite the same as Objective-C’s classes and methods. I’m learning from a solid base. And that’s reassuring.

I also feel like I can eventually build almost anything with JavaScript, and that’s motivating. I don’t feel like I’ll need to learn it for six months before I can do anything useful.

My “building/maintenance” focus remains on expanding and extending the plugin, so I have two tracks to switch between. This is my best mode of working, because even procrastination can become productive — if I get tired or burned-out on one thing, I can switch to the other. It also ensures I write code consistently and don’t get bogged down in only book-learning.

I’ll write a full-on technical post about the plugin soon.

Day 89: Victory

I cannot begin to describe how happy this makes me:

Terminal output from Xcode voice recognition plugin

And this:

Xcode voice recognition plugin

I went back to the voice recognition plugin. I thought about it differently. And it works.

It’s not perfect. Far from it. But the key bottleneck is broken. This basically means everything I want to build, from a functionality perspective, I’ll be able to build.

I’ve never actually experienced this in coding before. I always just had someone help me through the hard parts, which was good for productivity but meant I never really learned to work through a tough problem in code. It’s awesome.

Referencing the “Day 89” in the title of this post, it’s Day 89 since leaving my job. Day 31 of Hacker School.

Things Accomplished versus Distance Covered

I’m in week four of Hacker School.

It’s awesome. But I’m struggling with a dilemma: balancing the tough problem and the maximum ground.

I view Hacker School in terms of two metrics: Things Accomplished and Distance Covered.

Of course I want to accomplish some things. I have a whole list of things I want to accomplish, some while at Hacker School and some afterward.

But the whole point of doing Hacker School, for me, is to learn the maximum possible amount in the time given, so that I become a much better programmer for whatever comes next.

This means I also need to keep an eye on the Distance Covered.

It doesn’t mean I will abandon tough problems forever; but it does mean I don’t want to spend the entire 11 weeks on one problem without any guarantee that I’ll solve it in that timeframe.

Asking the Right Question

So I’m forced to balance things. The right question is not, “How long will I spend on a particular project?”

The right question for me is, “Given the rate of progress I am making, the amount of code I am writing, and the amount of learning going on, how long will I spend on a particular project at Hacker School?”

That’s why I’ve decided to set the voice recognition project aside for now and continue forward with my Hacker School plan by turning my attention to Swift for the next two weeks.

But I Love Tough Problems

I wasn’t too happy about this decision, because my experience has been that the projects and problems I delve into tenaciously and refuse to let go until I’ve figured them out always produce my greatest successes and joy. It was true with high-speed trading risk controls at my prior job. It was true with health issues that I defeated.

But those projects take years, not weeks.

I don’t have years at Hacker School. I have time to learn a lot about a lot, meet and enjoy working with great people, and build a base for tackling the really tough problems afterward.

The Nights-and-Weekends Compromise

I discovered that the voice recognition project is 100% doable — it just requires a lot of work. More work than I have time to dedicate to it at Hacker School.

So, my compromise is to make it a nights-and-weekends project, while spending my time in the Hacker School space completing my Hacker School plan.

That means Swift for the next two weeks and then a shift to JavaScript and node.js.

Meanwhile, I’ll be mulling the voice recognition project in my spare time, which is probably the best way to tackle tough problems that are at an impasse. I will figure it out. But I will also accomplish other things and cover the distance.

Say What? My Voice Recognition Dilemma

I tried Mac Dictation this week. My goal was to get a few simple sentences to appear in a text editor. Initial experiments were not successful. The full sentences I attempted were garbled beyond recognition when they appeared on-screen, so I fell back to word-by-word communication.”Make.” Made. “Maaaaaake….” Mate. No. Try again. “Maaaaaake….” Made. No. “Create….” Create. Aha. Victory is mine! “An.” In.

I progressed word by word, slowly and carefully, and my text editor dutifully showed the words on the screen with numerous errors. This was not production-ready. No one wants to talk as if they’re scolding a recalcitrant pet.

To be clear, I’m not a marble-mouthed mumbler. I’ve recorded books on tape for Recording for the Blind and Dyslexic (now Learning Ally), and I know I can enunciate well. But Dictation couldn’t understand my voice.

I knew that if I couldn’t get text to appear on-screen, I couldn’t complete my project. I’ve started coding the next part and it’s feasible, so I really want this to work!

So, I Googled for my options:

1.) Try to improve Dictation’s performance by improving my computer setup;

2.) Buy Dragon Dictate and hope it runs on my underpowered 2011 MacBook Air and has better accuracy than Dictation.

3.) Abandon OS X entirely and do the project in a Windows virtual machine with Dragon Naturally Speaking for Windows.

4.) Try using OpenEars to build an iOS app that does the same thing.

Only the first two options really get me to my initial goal; the last two are pivots that require adapting to different platforms and approaches.

So, tomorrow I’m buying a USB headset to eliminate ambient noise and provide a clearer dictation experience. I really hope this improves Mac Dictation’s performance by leaps and bounds. If it does, I’ll be off to the races. If it doesn’t, I’ll be installing Dragon Dictate on a machine not made to handle it.

I’m heartened by the discovery that once I get the text on the screen, my goals can be accomplished. I’m discouraged by how difficult it is to actually get the text on the screen. But discouraged does not mean “gave up.” It means I’m thinking hard about the options.

What I Wish I Knew About Computer Science in High School

I wish someone had explained Computer Science to me when I was in middle or high school.

Not the syntax of whichever language the school’s computer lab chose to use, not the same-old contextless exercise of adding two numbers together and producing a result, but what it would mean to choose a life in computer science.

A life as a maker, not a consumer. A life of flexible work options based on my own skill, drive and preferences. A life of curiosity and endless learning, with earning potential directly dependent on risk taken. A life of developing the ability to benefit society firsthand, either alone or in a team.

That’s what I wish I knew.

I majored in journalism — not a terrible choice in the 1990s, but better as half of a double-major with a more practical complement.

Fortunately for me, I taught myself HTML and Linux, then chose to work in online journalism and enjoyed several years of walking on fresh snow. I never forgot that feeling.

I went back for a technical master’s degree but shied away from pure Computer Science because I was afraid. Afraid I couldn’t compete with people who’d been coding since they were 12, who majored in CS at college the first time around, who were wizards.

I tried a few CS classes or books periodically — C, Python, JavaScript — but always found them incredibly difficult compared to other subjects, so I assumed I wouldn’t be good at programming.

I didn’t realize that intense difficulty is normal in CS. No one told me that everyone goes through it, that the learning curve is so steep you can’t even seen the first base camp when you start climbing Code Mountain. All you see is clouds.

I finally picked up Aaron Hillegass’ awesome Objective-C book in 2012. And an amazing thing happened: From cover to cover, I understood it.

Which is how Objective-C became my first (real) programming language.

I spend a lot of time now thinking about how to change this story for future nerds. Why didn’t anyone mention computer science to me when I was in high school? Why did it take so long for me to find the right explanation? What was it about Aaron’s book that made it the right explanation? And why don’t more people talk about the broader context instead of M_PI when teaching CS?

Simplicity in CS is just plain scarce. Addressing questions like:

  • What are the basic building blocks of code?
  • How can true beginners understand these concepts?
  • How can they transfer those concepts to different languages and build on them in more complex projects? (I found there was a true roadblock as I got deeper into iOS, which I overcame by attending the Big Nerd Ranch bootcamp in person, but not everyone has that option.)
  • How can they climb the intense learning curve successfully? (Just acknowledging up-front that it’s intense for almost everyone would help.)
  • How can they understand what studying computer science means, from a productivity and career-potential and lifestyle perspective, if no one ever tells them?

In short, how is computer science not required by default in public schools yet? And how is it so poorly explained by the vast majority of teachers?

It is not rocket science. And it doesn’t have to be explained that way.