Borkware Miniblog

April 13, 2012

Stuff Going On At The Ranch

Filed under: Big Nerd Ranch, meta, programming, Visix, work, writing — Mark Dalrymple @ 8:48 pm

In case folks are dying to read more of my technical writing, I’ve been writing a lot of material over at the Big Nerd Ranch Weblog, including some gems like:

Well, OK, that’s everything, even the not-so-gemmy. For the forseeable future my geek writing will be over there, and I’ll reserve this weblog for cute Vikki pictures:

IMG 0005 IMG 0057 IMG 0090 IMG 0175 IMG 0191 IMG 0219 IMG 0427

November 3, 2011

Outlet Collections

Filed under: Cycling Fusion, iPhone, programming, work — Mark Dalrymple @ 12:29 pm

A quick post to explain my tweet.

Screen shot 2011 11 03 at 11 41 55 AM

TL;DR: I can batch show and hide UIViews really easily now. Easier than setting up a bunch of outlets, fiddling with tags, making dummy views, or groveling through the view hierarchy.

I bet it’s Cocoa 101 nowadays, but they were new to me, pretty much seeing the reference when dragging a connection to header files (which I never do) and promptly forgetting about them. I might have seen reference to them in a WWDC sessions or something. But finally now I had a real use. Yay! For a lot of this stuff I need to actually use it for Something Real before it sticks in my brain. I can learn stuff by doing, but I’m lousy at memorization. Just look at my history grades during high school. On second thought, please don’t.

RideBuddy™ is one of the new apps coming from Cycling Fusion. Amongst a ton of other stuff, RideBuddy lets you track workout time in various heart zones – ranges of heart rates that have different benefits and consequences to the body. We like the Sally Edwards Heart Zones® system, which is a five-zone system based on certain physiological markers. I won’t get into specifics here, you can join the Cycling Fusion Winter Training in January and get the full details.

Five zones are kind of a lot for a beginner or just a casual rider to wrap their mind around, so Sally created Zoning™, a friendlier three-zone system and a color-coded heart rate monitor. It’s only three zones, but it’s based on the same physiological markers as the five-zone system. You can get a lot of health and training benefit by using the three zone system, and can graduate to the five-zone system when you feel up to it.

My stuff needs to support both. So, I have a number of screens like this one:

Two zone models

Something that’ll support three zones or five zones. Internally I can support from one to five zones. The code that adjusts the layouts based on the zone system in-use hides everything zone-related, then populates and enables stuff zone-by-zone until it runs out of zones. In the above screenie I have four objects per zone: two static labels and two text fields. zone zone zone.

To simplify that work, I have five IBOutletCollection(UIView)s — one for each zone. I walk through all of them to Hide All The Things, then walk the zones enabling a particular collection and populating items until I run out of zones. If I don’t hit a collection, it stays hidden.

Understandably, this is so much nicer than setting up an IBOutlet for each label and text field and making the connections. Or setting a tag on the items. Or groveling through the view hierarchy showing and hiding things. Or having a dummy UIView just to be a container. Just add the outlet collection and make connections in IB.

Markus Möller on Twitter “uses them for animating / moving groups of views. Better than putting them all in a container view. Less hierarchy.” which is another excellent use.

 

August 16, 2011

My First App: Class Builder

Filed under: cycling, iPhone, programming, work — Mark Dalrymple @ 2:02 pm

Class builder beauty

My first App got accepted into the AppStore yesterday – Cycling Fusion’s Class Builder™. Woot! Amazingly enough, it went through the approval process without a peep. There’s screen shots and tutorial videos (some still in the making – didn’t expect AppStore approval so quickly) at the link. And it’s at the AppStore.

Class Builder is a tool for Indoor Cycling (a.k.a. “Spinning®”) instructors to lead better classes. Rather than juggling an ipod, sheets of paper or 3×5 cards, and a stopwatch; instructors can plug their Device into the club sound system, run the class, and have cues pop up at the proper time during the class. They can also configure pre-class and post-class music for ambience before and afterwards. If the club has a projector, the instructor can plug their Device into the projector and show everyone the ride profile, along with additional information like current cadence / power / HeartZone®. A slideshow of photos can be shown during the pre-class time to help set the mood.

Despite “Class” in the name, this has nothing to do with programming.

Folks have asked me what I’ve been up to in the year-and-change since I left Google to work with Cycling Fusion. This is it, and the usual billion other things that go on when you work at a startup (along with the major update to AMOSXP)

The code is pretty much all mine, end-to-end. 13,000 non-comment / non-whitespace / non-brace LoC, 84 classes, 32 html files, and 677 .pngs. Not huge, but respectable. It was my first time really to work on something small enough that could be coded by a single programmer – usually I work on behind-the-scenes stuff that nobody else wants to touch. App design was by me and Gene Nacey, the fearless leader of Cycling Fusion. Graphic design by Emanuel Rufino and me. Luckily I now have the Photoshop skills to convert between an inspired artist and the user interface, to tone things down or amp them up as needed to fit the demands of the UI.

Class Builder is a part of the overall Cycling Fusion strategy for bringing the worlds of Indoor and Outdoor cycling together. We’re revolutionizing Indoor Cycling as we now know it through curriculum and certification, targeted training programs, web-based tools, mobile device apps, licensable music and an online video training library. Our big coming-out party is in the fall. If you’re into that kind of stuff, come on down to the ICI Pro Conference in October and check us out.

September 5, 2009

AppEngine Launcher

Filed under: GOOG, programming, work — Mark Dalrymple @ 12:55 pm

One of the cool things about working at the GOOG is you can spend 20% of your time on projects unrelated your usual work. It’s the responsibility of each engineer to actually find or make a project, and to take the time to do it. But it’s really nice having the opportunity.

Over the last 9 months or so, I’ve thrown in my 20% time on the App Engine Launcher for Windows. Even though it says Windows, I did most of my work on the Mac, since the project is in Python and uses wxWidgets. Because of this, the Launcher works on Linux too.

And now it’s shipping. Woo! And it’s open sourced.

What is the Launcher? It’s a little dashboard where you can create new App Engine projects, run them locally, look at the logs, and deploy to appspot.com.

So, why this particular project? Good question, since I haven’t done much with AppEngine, outside of a small Photo Software Quickies database, similar to the Borkware Quickies. There were two reasons.

The first was to keep working on a project with the Launcher tech lead, John Grabowski. I worked with him on a previous project and had a lot of fun. If you ever get a chance to hear him talking about brewing beer or raising his six kids, you should.

The second was to have an excuse to expand my horizons. I’ve never really used Python before, and I need an actual project to work on before I really learn something. Here was a project that folks have been wanting and I could learn a new language and toolkit. Perfect fit. I absorbed a huge amount about Python, particularly during the code reviews from our Python expert Dave Symonds in Australia. Every code review I had to fix stuff, but I learned a bunch.

So now the technical take-aways.

Python is a nice language. self.There() are a self.few() annoying self.things() about self.python() self.that() self.KindOf() self.drove_me_nuts(). Whitespace indentation wasn’t one of them. I still program it with a C accent (and my C still has a Pascal accent), but through code review I fixed the most egregious anachronisms.

As a cross-platform toolkit, Wx is adequate. If I *had* to use a cross-platform toolkit, I’d use Qt, and also look at CocoaTron. And then weep for the demise of Galaxy. Wx actually looks and behaves well on Windows and Linux, but it doesn’t even reach the Uncanny Valley on the Mac.

We decided to use wxglade for creating the user interface components. That was probably the only big mistake of the project. It was nearly unusable on the Mac, frequently neglecting to save changes. Sometimes it took 5 edit/ok/save/generate-code cycles for menu bar edits to actually stick. Oh, and it’s a code generator. We hateses code generators, my precious. For some reason, wxglade kept on trying to make the main window huge. And finally, the code generator occasionally decides it wants to generate the same code twice. It doesn’t break anything, but still messy.

So, go check out the Launcher, now included with the App Engine SDK for Windows and Linux. There is a Mac version (which I didn’t work on) which has been shipping with the App Engine SDK for Mac for awhile.

July 1, 2008

How I Got Started In Programming

Filed under: meta, off-topic, Random, work — Mark Dalrymple @ 10:47 pm

The redoubtable AnneKate™ tagged me with a narcissitic brain-dump meme, How I Got Started Programming, so I figured I’d chime in. Usually I don’t do that stuff here, but hey, it’s my blog, I can me me me me if I want to.

How old were you when you started programming?

Sixth grade. Which would put me around 12 years old maybe? My dad brought home an Apple ][ (amazing how many stories like this start off with that machine), intending to do Typical Computer Things like track finances and write simulations of radiation-resistent DNA (my Dad’s awesome), but I noticed that it could play GAMES, and I glommed on to it. Dad got occasional visitation rights, but for the most part, the machine was all mine.

It was a super spiffy version, too. It had 48K, plus Applesoft BASIC on a card (Integer BASIC on the motherboard). To switch between languages, you powered-down, flipped the switch, and powered back up. (this was before DOS 3.3). Eventually the machine got a Language Card (16K expansion).

How did you get started in programming?

Typing in programs from magazines and books. This was the time when print publications (remember those?) would have complete program listings. I learn best by by eye -> hands -> screen -> eye -> brain, and this is how I learned programming. Actually, where I learned debugging, since you learn more by making (and finding, and fixing) misteaks than you do by doing things perfectly the first time. At least that’s what I keep telling myself.

What was your first language?

Apple ][ Integer BASIC. Later Applesoft, and then the UCSD Pascal system.

What was the first real program you wrote?

Where “real” is something non-trivial, and not something I typed in from a magazine. It was one my Dad designed, and I implemented. It was essentially a quality assurance database system for a Radiology department. Diagnoses could be entered, and then later correlated with reports from Pathology. Or something like that. As far as I was concerned, it was “type stuff in, save it to disk”, and then periodically run the worlds most inefficient multi-device sort. But it was cool seeing three Disk ][ units hooked up to a machine, all running.

It was at this time I learned what flowcharts were (remember those?), sigma notation, and basic algorithms and data structures.

What languages have you used since you started programming?

Roughly chronoillogical order, favorites starred

Integer BASIC (*), AppleSoft BASIC (*), UCSD Pascal (*), FORTRAN IV (under UCSD Pascal), VAX FORTRAN, VAX assembly, VAX BASIC, VMS DCL, Dbase ///, Turbo BASIC, Mac/TML Pascal (*), Hypertalk, Object Pascal, C (*), C++, Newtonscript, /bin/sh, /bin/csh, emacs lisp, Tcl (*), Perl, Oracle SQL, PL/SQL, PHP, Objective-C (*), /bin/bash, Javascript, Pythong, Java, Sawzall. HTML (XML and generic SGML) if you count those as languages.

Badgers, or Wombats?

Badgers, definitely.

What was your first professional programming gig?

Visix Software (R.I.P.) We did a cross-platform toolkit called “Galaxy”. It ruled™, and was definitely ahead of its time. Its geometry management system has not been approached by anything I’ve seen since.

I started off in tech support answering questions about network configuration for our license server and X11 Font Paths for our Looking Glass product. Eventually worked my way up to Señor Software Engineer working on some important parts of the product. Also, because of Visix, I spent four months on Wall Street.

My first “will program for food” was a couple of summers and Christmas vacations during college at the Little Rock VA Hospital, assembling PC-clones from spare parts, and building some software tools for the department. One was an elaboration of the previous medical system (this time in a “real” database, Dbase ///), and an isotope tracking system. I couldn’t really be paid, so I was officially a volunteer. If I was there for four or more hours, I got a cafeteria meal voucher, which was *just enough* for a cheeseburger, onion rings, and a coke. It was the only non-lethal thing there.

If you knew then what you know now, would you have started programming?

Hell yes! I’m having the time of my life, and I get paid for it.

If there is one thing you learned along the way that you would tell new developers, what would it be?

This is more generic life advice, but something I feel strongly about: Surround yourself with people that are smarter and more talented than you, and learn from them. See what they do, figure out why they do it. Ask questions. Bask in their greatness and absorb everything.

At Visix, I spent a big chunk of time hours and three whiteboards going through the Galaxy “Class Manager”, figuring out how it worked (which was a combination of C++-style vtables and Objective-C runtime lookup, but all in vanilla C, with a lot of macro magic).

What’s the most fun you’ve ever had programming?

At Visix, in the bootstrap days of Galaxy. I wrote a lot of demo programs and sample code, in addition to doing the “List Manager” (think Excel, but without the calculation engine). There were a lot of times I’d be working all night on some fun thing (like a graphics demo that needed scrolling, but we didn’t have scroll bars implemented yet, so I wrote a little joystick thingie). My favorite times were hacking on something fun, looking out the window, and watching the sun rise. It was magical.

Thanks AnneKate, that was a fun stroll down memory lane. Now get off my lawn.

October 31, 2007

Exploring Leopard with DTrace

Filed under: programming, work — Mark Dalrymple @ 4:39 pm

My friend and cow-orker Greg Miller has a piece published at MacTech: Exploring Leopard With DTrace.

DTrace is cool. DTrace is awesome. Go read this.

September 29, 2007

Don’t Forget VoodooPad

Filed under: amosxp, programming, Random, work — Mark Dalrymple @ 3:57 pm

With all of the love and attention that Flying Meat’s Acorn is receiving, I figured I would remind folks about VoodooPad.

VoodooPad is a personal Wiki that lets you write stuff and link things around. When it sees words in CamelCapsStyle, it automatically turns it into a link to a new page where you can write more stuff. All pretty standard wiki stuff. It uses the OS X text engine so it has all of the standard word processing features you’ve come to expect, including stuff like tables and lists. This is especially nice because I get a lot of my emacs key bindings along for free. Muscle memory is a wonderful, wonderful thing.

Screen Capture of VoodooPad pro

There are a couple of things I love about VoodooPad : it gets out of my way. I type, I link, I paste in graphics. Gus has obviously paid a lot of attention to the fine details and the app just gets out of my way. It is also very stable. I don’t remember when my last crash was. It just works. Just about every Leopard update makes SnapZ pro freak out and I have to get get new license keys (and then usually something fails on the server side, and takes 20 minutes of dinking around to get a license). Omnigrackle‘s layers get confused and the PDF export dialog has a bug that makes it easy to corrupt your document. Mail.app regularly crashes. But VoodooPad just keeps on chugging along. Oh, and it’s fast, too.

Some folks I know put everything into a single VoodooPad document and use it to store their life (or at least their brains). I typically have one VoodooPad document per project, which usually fall int into one of three broad categories:

Design Document : I have one where I keep my design notes for the Extreme Cross Stitch Design software I’m working on for the Spousal Overunit. I dump figures from OmniGrackle in there, and use class names as the currency of links. This makes it very easy to capture my thinking about the specifics of individual classes, as well as highlighting the interactions between classes. Sometimes I can go for a month or two between working on the App, so having all this stuff handy and interlinked makes it easy to reload my mental state. My winning IronCoder entry included a VoodooPad design document with all sorts of notes. (The entry was Race Against Time, if you’re really bored)

Data Dump and Organizer : I have another one where I keep all my notes, to-dos, transcriptions, and copies of interesting emails for the next edition of AMOSXP. You can see a screenie for this is over to the right. I blort in anything and everything I think might be interesting for the next edition. As I start chewing up a chapter, I have ready access to stuff to consider for exclusion (and stuff to nuke). Sometimes one topic (say an extension to a favorite object-oriented language) is too big for one chapter, so something like its automated memory management technique would make better sense living in the Memory chapter. So I can easily make a note in MemoryChap to say “go look over InThisSetOfNotes for these aspects of rubbish aggregation that would be interesting to talk about here”

Debugging Aid : For projects where I tend to do more debugging than design, I have a VoodooPad document that keeps my debugging notes. Usually for each non-trivial problem there’s a page with a dialog with myself. “So What’s the Problem Fool? Oh, Google Kipple is crashing when you frobulate the giznat. Does it happen all the time? No, just on the second launch. Maybe it’s the SpicyPonyHead user preference Hrm, could be” The dialog format lets me focus my thoughts by making explicit what the next useful piece of information might be, and it makes for easier reading when I need to revisit a bug or if I have to put it down for awhile and return to it later. The linky nature of a wiki makes it easy to put in different branches of investigation and let me revisit what I originally thought was a dead end, but might actually be the path to figuring out the real problem. Because Cocoa class names are CamelCapStyle, class names in stack trace become links. Ppaste in a stack trace and then link out to a class to jot down some relevant notes.

I’m a fan. Check it out.

September 27, 2007

Ten Tips for a (Slightly) Less Awful Resume

Filed under: Random, work — Mark Dalrymple @ 9:42 am

Steve Yegge knows hiring. His latest epistle is Ten Tips for a (Slightly) Less Awful Resume.

Rands also has a new article about The Button, the personality types you’ll run into during technical interviews.

Create a free website or blog at WordPress.com.