Killing Your Babies

I've been wanting to write an Erlang serial port library for a very very long time now.  I've probably talked about it, at this point, more than it will take me to *actually* write the thing.  But I've been stymied (forever it feels like) by mental blocks and knowledge-gap blocks and the general dis-ease of not knowing where to begin.

I was fortunate enough to be able to attend !!con this past Sunday.  (!!con is a weekend conference that features short, 10 minute talks on things you find fascinating in programming.)  Watching people talk about the things in programming that they had been geeking out about lately made me start thinking about what it was that I wanted to present about next year.  And I realized it was the serial port project I've been avoiding for years now.

So today, I booted up an AWS instance and downloaded the source tree and started compiling the Debian sources. One of the current Recurse Center batchees stopped by to say hello, and I outright asked them if they knew anything about kernel modules -- turns out the answer was very much yes!

In less than 20 minutes we had a "hello world" working kernel module! Pris (the Recurser who was helping out) asked me what it was that I was trying to do with a kernel module -- and when I explained the bigger project (getting Erlang interop-ing with C code), Pris explained that since I was using serial, there was no need to write a kernel module -- I could just write "plain" C code as my driver for an Erlang API.  And actually, a project that does exactly this already exist, and if I wanted to I could probably just use them.

Boy do I feel silly for telling so many people about how I was going to write a kernel module.  And even more silly for avoiding setting up a VM that could do kernel things on it. (I thought it would be hard!)

I'm not as motivated to write all this code as I was, but I might do it anyway because I am still curious about how the serial API works.

I've been carrying this project idea around with me for such a long time; it's nice to have killed so many hangups and misconceptions about the amount of work that would be required all in one go.  This project seems so much more tractable now.  More importantly, it's amazing how much mental energy has been freed up from worrying about how hard this would be to finish, or if it would even ever be finished.  Guilt and unfulfilled desire finally deflated into an actual, tangible body of work that I know how to start.  Or not, since it kind of already exists.

I just wish I hadn't deleted all that Erlang code a few weeks back.  Oh well. :)

Cocoas First Responder, an irl investigation of terms

List of terms/sentences from an article on the Responder Chain that I don't understand yet.

- In fact even Apple often employs delegate protocols to have a view controller communicate to its superior.
-

@protocol FlipsideViewControllerDelegate

- Now we can get rid of the delegate protocol

Oh interesting.  There are 2 ways to assign the receiver for an action (like a button click).  One is to assign it to the "File's Owner".  No idea who this is yet, but sort of get the idea that it may be something called a "Controller" class.  Or something.  The other option for an action target is that you can put the action (the click) in a 'queue' of sorts, to be processed by the "Responder Chain" (whatever that is).  The chain goes up a list, sort of like the View Hierarchy in Android, until it finds a receiving method (I don't think that's what these are called but whatevs) that is registered for that action (the click!).  That method is then called.  

- Any selector can be used for the action parameter of the sendAction method 

What's a selector?  If I had to guess, I'd say that it's a view?

Since the app delegate has been promoted to a UIResponder as of iOS 5

Who's the app delegate?  This seems like the first Activity from an Android app.  Or like an Application subclass, but more easily accessible than the Application subclass is. 

Further Interface Builder questions:

There are three items listed under Placeholders: File's Owner, First Responder, and Application.  What is Application good for?

What's the difference between the Placeholders objects, and the Objects?

Mapping Learning

I'm currently writing an app for OSX.  I started it over a year ago, but when XCode ate my project, I gave up.  Before the XCode Apocalypse happened, I had a working prototype built.

In early April, while at DroidCon Montreal, someone asked me what my 'startup idea' was.  I told them about my XCode project that got eaten.  They said it was a good idea, so when I got home I tried to open XCode again.  No luck.

In early October, I was inspired by a tweet about octobuild.com to finish a project in October.  Or at least work on one.  So I opened XCode again.  It worked this time. (Huzzah).

I've been working on it, off and on, since then, just a little over a month.  The prototype no longer works, but instead I'm currently focusing my efforts on making the GUI look and work how I want it to.

I don't know Objective-C.  I've never done any OSX app programming before.  I have done .NET and a fair amount of Android programming, however.  Both of which are GUI-esque systems.  I've been having a hard time grokking how the new system (Interface builder, wtf?) works, so here's a short documentation of things I've learned so far that have been helpful for getting a footing on writing my first OSX app.

- Reading the Apple documentation.  Fairly helpful, but not the right granularity for the most part.  Either too much of a 10,000 foot view or way too granular 1ft view.
- Googling shit / searching for help on Stack Overflow.  Hard to do at the beginning because I don't know what I'm supposed to be Googling for.  What's the proper name for the text input field things?
- Doing an Apple tutorial. I found a really basic, pictoral tutorial in the Apple docs.  This was really helpful for learning the layout of XCode.  But I had mostly forgotten it a few weeks later when I went to do my own GUI.  I can't find the link to it now, either.  However, I did find this repository of sample code.
- Reading articles that are too hard for me.  This is actual a pretty decent strategy for getting a grounding in what the lay of the land is, provided you can hold the fuzzy/frustrated feeling at bay and work on building a relational map of unknown words.  Example: this article.
- Finding the right words.  I finally figured out that Cocoa is the name of the GUI system for Mac OSX applications.  I don't recall exactly what the name for the UI system is for iOS apps.  But it's not Cocoa.
- Asking friends for help. I found this to be slightly helpful, but mostly frustrating.  I asked for help via chat, and I really needed someone in person to show me what buttons to click on the Interface Builder.  Both people I asked were helpful, but neither of them were able to point me to the silver bullet for understanding Mac App programming that I was hoping for.  (One probably doesn't exist).
- Reading the Table of Contents of books.  I find this really helpful for giving the lay of the land - what topics are there to explore?  How are things called?  Sadly, I didn't think to do this until today.  Table of Contents are often available free of charge for any book listed on Amazon (or otherwise).

Something I'm considering trying:
- Buying/borrowing a book. Books are so good at starting at step A and explaining the lay of the land (which is usually what I need the most when working in a totally new paradigm/system.)


I still feel like I'm struggling because the thing that I wanted to have done is not done yet.  The reality is that I may not be moving very fast, but things are making more sense.  That's progress!  I'll take it :)

unsure where to start

sitting in this project space that I'm renting space in for a month. (or two?).  it's my first day here, so there's a lot of pressure to be good and productive with my time.  I'm not really sure what that means, on a Saturday.  I mean, if I wasn't here I'd be at home reading the novel I'm currently working my way through: Capote's In Cold Blood.  Or boring my dog to death with more interval practice.

Conquering intervals is my current frustration.  I've been focusing on perfect 4ths & 5ths.  The generally accepted way to memorize an interval is to map it to a favorite song.  A perfect 4th, for example, is the first two notes of "We wish you a Merry Christmas".  The idea being that if you hear two notes that sound like the beginning of the song, you know, instantaneously, that that is a perfect 4th.  The key notes that I'm using for a perfect 5th are the first two notes of the Star Wars theme song.  Duhh, dahh, dahdahdah dahhhh dahh.  You get the idea.

These notes go north and they also go south.  As in being able to identify a perfect 4th both ascending and descending.  It's a bit of a night mare, especially because my short term memory is so horrid.  Or maybe it's just that my listening skills leave a bit to be desired.  Either way just being able to accurately recognize (and, more importantly, differentiate) perfect 4ths & 5ths is a current struggle.

I went to ear training class on Thursday.  In class we focused on rhythm training and singing scales.  The scales that we covered were normal (all the same pitches), a normal (?) minor scale (raised 3rd, 6th & 7th) a harmonic minor scale (raised 3rd & 6th) and a melodic minor (raised 3rd).  I still don't really understand coming back down on the diatonic and melodic minor scales.  It seems to be that they go back to being the same as the "normal" minor scale.  I should look this up, but it's kind of more fun to just grouse / write it out.

There's also 4 sets of triads:  A normal triad (tonic, M3rd, M5th). A minor triad (tonic, m3, M5th). A diminished triad (tonic, m3, d5). An augmented triad (tonic, M3rd, a5th).

Another current frustration: figuring out what language to write side projects in.  Getting outside of the mobile app infrastructure land is so hard *whines*.  I'd really like to switch my blogging over to a static site, but I'm currently trapped in indecision station with regards to what engine to pick.  There's a Java one, but I'd have to figure out how to jar things.  There's a zillion in Ruby or Python but just ew, ok?  There's one in Erlang that looks dope but I'm not sure that my Erlang skills are good enough to figure out how to get it up and running.  I'd also like to write my own (the existing projects up on Github seems small enough to make this a doable project), but that doesn't solve the problem.

Can I write an Android static site generator?  That seems real dorky but also super useful.  I'd definitely use it all the time. o.O lol.  Turn your mobile phone into a web server with this one weird trick!

Ruby and Python are out because we HATTES them we HAATEES them.
Java, eh.
JavaScript? meh.
... what else is there?
Scala? fffuuuckno.
Kotlin? Groovy? meeehbe.
Dart, Go? no thank you.
Smalltalk? Prolog? Erlang? when do you need this by?
bash? what are you a masochist?
C?


Yeah. Maybe I'll do it in C.

scritch scritch scritch

I can't help but feel that I've spent most of my day here on my sofa, plunking away at odd thoughts.  They are all odd.  Thoughts, that is.

I'm going back and re-interpreting a scattershot collection of old memories, in the process making them into new ones.  I have lots of ideas of things that I would like to see done, but most times just having the thought is enough of a reward that I don't get much past that.  You know, past just having the idea.

The ideation phase, it turns out, is so rewarding that the physical labor of actually producing or turning that thought into reality is unnecessary.  Less rewarding, almost.

I wonder then if that's what makes writing so seductive -- in the age of Internet, where publishing and garnering an audience[1] is a semi-trivial thing, writing things down is such an easy process. It doesn't take much other than remembering to write down the day dream like thoughts in order to have *done* something with a thought.  To have made an idea feel more concrete than it was.

We had a visitor at EO (was that where the conversation occurred? I can never remember conversation provenance) on Friday.  A few of us went out to coffee, and talk turned to the robotics class at Columbia that our visitor was doing mid-terms for. The prompt was a robot navigating about a room full of obstacles, and they kept running into a problem that their robot would not hit the finish targets exactly.  The biggest challenge had shifted from writing code to how to account for drift?

This problem provides a nice foil for the difference between "programming" and "engineering" - whereas programming is writing out the steps that you want the robot to take, and engineering is the task of discovering what steps that the robot needs to take.  Figuring out what the causes of the problem is and figuring out a solution (a solution that is later embedded into code) -- this is engineering.  Without drift, would it not be so much of an engineering problem?  I would say yes -- it's merely a matter of getting the robot to execute a series of steps.  But since some amount of error occurs in the system, a method of correcting for the error - discovering it, reporting, and reducing it - must be found.  There's no clearcut way to make it better, either.

Is there much difference between daydreaming & writing and programming & engineering?  Other than engineering probably takes much more work than sitting on a sofa staring dreamily into the distance as you wait for the sun to finally set.  But both are the process of finding ideas (wherever they may be) and putting them down, concretely.


[1] personally, I'd be happy if only robots read my pages

General ideas about teaching programming : 'apps' vs. 'programs'

Apps are hard.  I wrote my first Appery.io app today*.  (It was a version of the homework we ask job candidates at work to complete.)

From a certain perspective, writing an app is rather easy.  You throw up some buttons, wire the data to the views, and ship it.  That wasn't so bad, right?  But the amount of knowledge you need to write an app is a bit daunting.

First, you need an idea.  You need to be able to clearly articulate the audience, the scope of what the app will and won't do.  Second, there's the layout and navigation flow of the app.  A poorly designed navigation experience can kill an application.  You need coding know-how.  What the classes are, how the different underlying APIs work together to make the views happen.  To say nothing of the necessary pre-reqs of understanding programming primitives, like variables, control flow, language syntax.  Finally, unless you're writing a local app, you need to know how the internet works.  What a RESTful API service is, how HTTP works with headers and params.  How to get an API key, how to authenticate.

Appery's a low entry point for building a very simple app, and maybe for copying tutorials you could get something a bit more dynamic, but the seams between knowing a very little to knowing pretty much everything there is to know about writing an app are close together and a bit rougher than you'd hope for a tool this simple.  There's a lot of places where you fail over into JavaScript, or where you need to know what a web proxy is (so that you're can get around making Cross Domain Requests**.)  Writing a mobile app in HTML, CSS, and JavaScript requires a surprising amount of web domain, app, and just plain networking knowledge.

That's asking a lot for new developers.  Admittedly, maybe the target market isn't new developers, it's companies that don't have the developers/time/money/inclination to create a native Android/iOS/Windows phone from scratch for each of the platforms.  It's significantly easier to throw an experienced dev at Appery and get a workable mobile app than to create a native app from scratch.  (Disclaimer: In no way is this an endorsement of Appery's product -- if anything, this experience has only deepened my belief that there's no substitute for a natively written app experience.)

But for a new dev audience (one without an experienced dev who can blunt corners and abstract away the rest of the considerable amount of knowledge that you need to write a native app), Appery seems like a terrifying and frustrating experience.  (Though if you know web development, well, then you know web development).

What would be better for young devs to spend a weekend doing?  Other than learning wire framing and writing very leakily abstracted apps?  They should learn programming.  They should write programs, not apps.  It could use quite a bit of set up to get going, but I really liked the challenge at the Hackette's Spotify Hackathon they held last year (https://github.com/pbos/spotify-hockey).  It basically involves writing a hockey team algorithm.  It's a good problem for a weekend project because a) the end product isn't about presenting your ideas (you just load up the different hockey teams and let them have a tournament style show down), b) it'd involve a non-trivial amount of programming, and c) it's kind of fun.

Or maybe that's a bit too advanced for completely new programmers.  Something like Scratch (http://scratch.mit.edu/) or even some format for writing text adventure games could be fun.  Basically, make it less about building a product, and more about writing a small program, with a code editor and a runtime environment.

/rant


* I work professionally as an Android app developer.

** If you clicked on this link, you just proved my point about needing massive amounts of previous knowledge.  Bonus points to you if you now get why CORS is a problem.  You're probably in the minority.

Bugs under the Covers

Debugging is an artform.  The right debug message, once you've figured out what it means, can save you hours of digging.  If you can figure out what they're talking about, that is.  On the other hand, a badly worded or just plain misdirecting debug statement can waste hours of your time.

Not enough can be said about the right console log or print statement.  Any bug is trivial once you know where to look.