Tag Archive: xcode plugin

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.

FacebookTwitterGoogle+Share

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

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