Code, code on the range

I have achieved a major workflow milestone.

All of my web development can now be accomplished on the iPad, meaning that I may venture forth light of heart and burden, yet still program (in addition to writing, drawing, and hatching nefarious plots).

How? you cry plaintively. I too wish to walk the earth, free like the majestic Buffalo buffalo.

Not an actual Buffalo buffalo.

For me, the answer has been a triforce of apps, webhost, and extra hardware.

All of these puzzle pieces are replaceable. It’s just a matter of finding something that works for you.

But first, the webhosts.

It didn’t have to be Linode. Any server where I had actual control would do.

I was able to persuade my previous provider to give me remote access to my account so that I could install things. However, the operating system they used did not have a package manager.

For those unfamiliar with package managers, not having one meant that I had to install every single miserable dependency manually. To rephrase, programs need to run other programs, which need to run other programs. If you have to hunt down, build, and install every single one of these obscure bastards, that’s a lot of programs.

Energetic facial hair in the
background, masochism
in the foreground.

Though the general public may have the impression that anyone mad enough to stare down the barrel of a command line will have energetic facial hair and more than a tinge of masochism, the latter is patently untrue. That’s why there are package managers.

Package managers know program A needs program B needs program C. And they have a library of all of these programs. Handles it all for you.

Long story short: moving from little-known webhost to webhost used by people who know what they’re doing changed game from “cannot get shit done” to “can get shit done.”

Upon the necessity of keyboards

The software keyboard serves for train rides and fiddling around, or desperate times. If you propose to spend any time whatsoever at a table, a keyboard is necessary. That will be all.

New Cherry Diet Coda Zero: no calories, all flavor.

There’s two apps that I use for any programming work: Diet Coda and Textastic.

Diet Coda combines FTP access to the files on the webhost plus an editor for programming, with SSH access to the webhost itself for publishing and other server tasks.

Theoretically, it does everything.

Practically, it’s a new release and crashes quite a lot. Also, I’m not a huge fan of the software keyboard. We’ll see how it goes as I get more used to it. Since I have an external keyboard, it’s usually not a big concern.

Still, for emergency coding, or writing a draft on the train, Textastic works quite well. The software keyboard pretty much covers everything. It’s not ludicrous speed, but I can get things done without feeling an unquenchable desire to frisbee the iPad through a window every time I realize I must type an underscore.

Textastic is more general-purpose rather than specifically linked with my web server, so file sync is not quite as smooth. On the other hand, I can also use it to pull stuff from Dropbox and send it to my web server, which is useful.

But no workflow is so perfect it cannot be improved.

Photos and photo layout are not quite there yet. I think I vaguely promised a post on Photostream at some point. I’ve avoided it so far. I feel like I must have been doing something wrong, since it was so terrible, so I’ll have to try and bite the bullet again.

More experimentation

Last time I tried the iPad setup at a Ruby on Rails meetup, it failed due to lame webhost making it impossible to install anything. This time, I am reasonably confident that I can get it to work. And then it'll be just me and my two and a half pounds* against the world.

*iPad 2 + Smart cover + ZAGGKeys Flex + stylus

weissazool dot com

You probably didn’t notice, but I set up a website.

Yes, this, right here is a website. But it’s a template from Blogger. It would be more accurate to say that I built my own site. There’s a navigation bar on this page now, and all of the links (aside from ‘Blog’) will take you there.

What’s the difference? Why not set it up in Blogger?

All technical responsibility for my website devolves unto me.

• Is it not showing because of some problem with the hosting? My problem.
• Is it slow to load, or are there broken links? My problem.
• Are the colors poorly chosen? My problem.
• Is the design broken or buggy in another modern browser? My problem.

Well, except for…

Is there a monkey in your Gorditos?
Your problem.

• Is the design broken or buggy in Internet Explorer 6? Your problem.

Yes, there’s lots of fine and wonderful services that do the technical work for you. But I wanted to learn a little bit more about this world wide web thing people are talking about. And learning about and making it was a lot of fun.

It was also probably a much better use of my week than playing Diablo 3. I don’t know that I would have made that same decision in the past. Perhaps this is a sign of encroaching maturity.

For those interested in the technical keywords, I use a blogging framework called Jekyll. I style it with CSS, lay it out in HTML and Liquid, and write content in Markdown. Jekyll then takes care of the rest.

My ideal workflow is to be able to write and lay out a post, from start to finish, and then publish it, from the iPad.

Being able to make changes to the website layout and push those changes out to the host from the iPad is another goal.

A road map:

Migrate this blog off of Blogger.

Blogger is nice, but I would prefer to have all of my stuff in one place and with one design.

There’ll be some consequences.

• If I want comments (though so far they have been unnecessary) I will need to install something like Disqus as well.
• Followers (all two of them) and analytics will be lost.

The toughest consequence: Handling fish.

Since readership is low, those are negligible.

The tougher consequences:

• Handling images.
  
  Positioning and resizing and such are not part of Markdown’s spec. I wonder if there is a plugin or an extension for Markdown or Jekyll that handles it reasonably well. I can sacrifice a little precision if it means I don’t have to bang that out in HTML.
  
  (The answer: Yes. MultiMarkdown. Another thing to learn in the future.)


• Handling pagination with multiple posts on a page.
  
  This is really a design question that I need to think through first. The economy of space of just having a list of post titles and dates (my current plan) is nice. On the other hand, if for some reason someone is in the mood for a longer reading session, it may be nice to have multiple posts on a page.
  
  At the very least, I need a prev post and next post link.
  
  Also, related posts, particularly for project pages, are important.

Picture galleries.

This one’s a long way down the road. But I’d like to move my photos off of picasaweb at some point. I haven’t really given this much thought at all, though.

So there it is. weissazool dot com. This blog is still my primary bit of the internet, but one day they will merge to form the terrifying DEVASTATOR!

Some notes from the app development scratchpad.

On the app itself:

Probably the single hardest component was in-app purchases. 

I might try to do a presentation about it in the future, if I am masochistic enough to do that dance again. I probably should, so that I learn how to do it properly this time.

I will say this for now: I sacrificed a chicken over a pile of broken iPhones and iPod Touches, doused everything with gasoline, and set it all on fire. While praying to the spirit of the Apple All-Father. Then it worked.

Usually this is indicative that the person performing the eldritch rituals has no clue what they're doing. That may well be the case. It felt, by far, like the thing I had the least control over. I'm deathly afraid that some horrible bug involving in-app purchases and extremely angry customers will pop up.

Data wrangling on the back end took a lot longer than it needed to. 

I had no idea where to start. In fact, in the initial agreement, I was not supposed to be responsible for getting the data into an acceptable format. It was supposed to be provided to me. But so much time would have been wasted with manually entering the data, and hunting down the inevitable typos, that it was necessary for me to automate it in order to move the project forward.

Valuable experience, but it did derail work on the app itself for a substantial amount of time.

Switching from trying to do things via Unix scripting with bash to doing it in a more full-featured language, like Ruby, made life so much easier.

There's a lot of room for improvement, both in the app itself and on the back end, and I hope I get the opportunity to work on a version 2. 

In particular, I think we can streamline the structure of the lessons. Right now they're very closely based on the podcast, and user control is very limited and linear. My goal would be to give the user control over where and when they want to put more effort and time into practicing.

I also think it's really important for people trying to learn a language to generate phrases and conversations rather than just listen and repeat. I have some interesting ideas on how that could be done.

I learned a few things about how I work best, too.

Getting paid by the milestone beats getting paid by the project. 

Having a series of discrete goals and rewards is good. However, it's inflexible.

New tasks and goals that were not accurately predicted at the beginning of the project inevitably appear, creating a distinction between work you actually get paid for and unremunerated tasks. Spending a lot of energy on time-consuming extra tasks that don't quite fit your milestones is demoralizing.

Next time I consider taking a contract based on milestones, I would need clauses in there that allowed for the re-evaluation of tasks and compensation.

Alternatively, getting paid hourly is probably better in terms of being motivated to work on the project right this moment. But hourly pay for a remote worker causes its own set of problems related to time tracking and trust.

On occasion I can be effective and productive at home. 

Those occasions are infrequent and unreliable.

Getting out of the house, to a café or co-working space or park or really pretty much anywhere (sitting on the train!), is much better. But saying I should go out and actually doing so are two different things.
 
The best solution so far has been to make sure to have something scheduled. Whether it be frisbee practice in the mornings, or lunch with someone, or an errand to run, I can pad that event before, after, or both, with working time.

iPad Touch Typing

Ars Technica and other sites have written articles about the iPad as a full-fledged PC replacement. While Xcode ties me to a laptop for now, I have fancied a keyboard for writing and planning days so I can pack light.

Speaking of iPad workflows, I think it's awesome how cafés and restaurants are using them as point of sale devices, or for table and order management. But when I was in LA, I went to a diner descriptively named "Pie & Burger," where they had an antique, mechanical cash register, and watching the dials spin madly felt like the (analog!) clock was turning back and the chime announced that we had arrived in the 50's... It was magical.

The fresh strawberry pie (Strawberries. On top of a delicate, crunchy crust. And something jello-like, desperately attempting to hold it all together, even though things fall apart.) was great, but if you asked me why I have to go back the next time I'm in town, it's really for the cha-ching! of that register.

I digress. At any rate, iPad keyboards.

I tried out a couple of Brookstone products, both their case + keyboard and a floppy rubber keyboard. The case felt nice and was very grippy, but it was heavy. It felt like it doubled the weight. It also lacked the clever magnetic wake/sleep on open/close, which I love. Worst of all, it was very much in the way during casual usage, whenever I didn't need the keyboard. So I tried the floppy keyboard instead, going for portable and lightweight.

That was a disaster. Key presses didn't register, and using a keyboard apparently turns off autocomplete, so typing with it was actually slower and less accurate than with the software keyboard. I gave up after one paragraph with it.

Fortunately, Brookstone has a generous return policy. They also have a case like the first one I tried with a removable keyboard, but after looking at that and the Zagg case + keyboard, I just find that neither of them really beat the Apple smart cover for versatility and ease of use.

Move "Zagg" for great justice!

My current experiment involves a Zagg standalone rigid keyboard. It comes with a nice cover that can be used as a stand for the iPad in a pinch. It's a little bit smaller than an Apple keyboard and has some iPad-specific functions. It can be used for Android as well, though I haven't tried it.

So far I've typed up a couple of blog posts with it, and I'm well pleased. It has a number of special keys on the function row which I'm more used to keyboard shortcuts for. And the keyboard shortcus work! O frabjuous day! It's a smooth and natural transition, with very little need to touch the screen except when I'm switching between apps. And perhaps there's a shortcut for that too. I need to just start experimenting with key combinations.

Even though I don't use the copy/cut/paste keys, for people who used to use their mouse to do that, the added accessibility is probably a good thing.

I have at least one more iPad workflow post in me (iPhoto, I'm looking at you.) But hopefully the keyboard setup will get me back into posting more frequently.

The Critorist Tests Out iWeb: October 3, 2006

The first (and worst) in a series of unpublished blog entries dredged up from 2006.

This is all very nice and pretty. But how the hell do I, you know, stick code in here? I suppose I’d have to open it up in a program actually designed for code, but from what I saw of Dreamweaver, you could switch back and forth between design and code easily enough.

I should probably revisit iWeb sometime after iCloud comes out. If there's an iPad version.

Bananas have a great UI. It's like it was...
designed.

I suppose it’s worth commenting on working on the Mac in general. Obviously, it’s going to take some getting used to. The five (count ‘em, five) different, what the hell do you call ‘em, modifying keys - like Ctrl - are, well, confusing. All a matter of practice, I suppose. And if I can do much more with the keyboard, I can work faster. My main concern is whether the scheme makes sense - do I need to learn a whole new set of command keys for every damned application? That’d be a huge problem.

In retrospect, Windows had 4 - ctrl, alt, shift, windows. I can hardly remember what it was like to be an iVirgin.

Haven’t messed with iTunes yet. Briefly looked at iPhoto, if only to import my photos - now I need to figure out how to use it to organize things well. On my PC, it was pretty well organized into folders, but on a mac, the emphasis is on metadata - tags attached directly to the file. I was using the folders as a way to achieve the same result.

I still feel like my workflow with iPhoto could be much better.

Photo Booth is amusing. Frankly, it’s a toy, but it’s still pretty cool.

All I’ve really used this computer for so far, when you get right down to it, is browsing the web and IM. My excuse is that I’ve only had it a week and consequently not spent much time really digging in.

But I got the Japanese input set up. Works pretty similarly to Windows. でも、マックに全部がユニコード使える。 Doesn’t seem to be a key combo to switch back and forth quickly, tho, which pisses me off.

"Look upon my works, ye mighty, and despair."

I haven't bothered pointing out the glaring inaccuracies. Revisiting my first impressions of Mac OS is pretty embarrassing.

Hopefully five years from now I'll have progressed as much as I have from 2006.

Blog archaeology.

Before the dawn of time

Around October of 2006 I obtained my very first Mac.

Well, my only Mac. I'm still using it. It's rapidly approaching the point where I will need a new one, but that's another story.

Precambrian and Cambrian posts

With that new computer, I resolved to explore the myriad new apps that I was confronted with. I thought it would be pretty nifty to experiment with iWeb and write a blog. I didn't want any part of MobileMe, though, which complicated things. So I just wrote things up and didn't bother to publish them.

Shortly thereafter, I went on a cruise with my parents. There wasn't much to do on the ship except read and write. I wrote a travel blog, and put it online, writing posts in iWeb and Pages and then copying and pasting into a crummy web interface. The workflow was terrible, but still, nothing better to do. Which helps explain why I stopped writing shortly after the cruise ended. (Read: I once again had inexpensive internet access.)

Meteorite impact

Does anybody remember blogging sites from 2006? I know for sure I didn't post on livejournal, xanga, blogger, or myspace. But I can't recall the name of the site that hosted the blog. I can't find any emails or bookmarks relating to it. I've tried searching Google for unique phrases from the posts, to no avail.

I never told anyone about the blog, either, so it is irrevocably lost in the space between the Interwebs.

Digging up fossils

"How do you remember unique phrases from the posts?" you ask.

I have copies of what I believe are all the posts, in iWeb, Pages, or both. Also, I do remember that I hosted the pictures on photobucket, and there they have sat.

Now, that blog is quite distinct from this blog, because I've actually told a non-zero number of people about this one. Also, I'm still writing. Partly due to improved workflow - I still like using Blogsy to write on the go, though today I'm at the computer. But also partly because I'm getting better about these things.

To the museum

At last, we arrive at the point, or at the very least, a point.

I plan to restore the old blog posts, and add them to this blog. But it'll be a director's cut, with additional photos, video, and commentary as suits my whims.

On the Relentless Death Engines of Isaac Newton

Assumptions were made.

Specifically, that if I planned to create a game simulating, to some extent, the vagaries of Newtonian space, that I would need to employ what is, in the parlance of les programmeurs, a "physics engine."

Physics: it's everywhere!

Upon consideration and note-taking and scribbling (in the fine iPad app known as Penultimate, though I prefer Notes Plus for things I might need to present to others) I realized that it may be possible to emulate a number of physics-like properties by extending cocos2d sprites without subjecting myself to the agony of physics frameworks.

Not that physics frameworks aren't wonderful things. It's just that Box2d and Chipmunk are in C++ and C, respectively, and I'd like to get a better handle on cocos2d itself before moving on to new jungles with new tigers.

I lost track of which was which.

The plan was to do a cage match, in which the framework which caused me less cognitive stress in the tutorial would emerge victorious. But since both made me want to stab my cranium with chopsticks* this plan was abandoned in favor of extending CCSprite and just faking the physics till I have no alternative, at which point the algorithms should be transferable and my grasp of cocos2d should be firmer.

Which is to say, my verdict on the Box2d vs Chipmunk non-debate is: they both suck if this is your first try at making a game. Chipmunk has an Obj-C port which is super exciting up to the moment you find out it costs $200 to license. And the separation between the physical representation of your world and the visual representation of your world is frustrating. Perhaps as I continue I'll find a good reason for this. Objective-C's delegates would seem to lend themselves to conveniently adding physical properties and interaction to visual objects, or vice versa, but alas.

A brief note on tutorials available: there is indeed a lovely series right here, but it includes some unsavory coding practices, including magic numbers, poor factoring, and unnecessarily costly algorithms.

* A maneuver indicating distress of the brain, immortalized by the renowned pop culture commentator R. Cota after being subjected to the film 'Gone in 60 Seconds.'

Blogging on the go

Half Dome, Yosemite National Park

Usually I don't spend much time blogging - or writing in general - at home. Whether it's due to an abundance of distractions at home, or something psychological, I'm not sure, but regardless the reality of the situation is that I do nearly all of my writing and planning when I am out.

So here's the question: will having the capability to blog on the go result in me actually doing so?

My needs for blogging on the go

A summer festival at Yasukuni Shrine. No wi-fi here!

I have a US 3G iPad in Tokyo. I know of only two cafés in this benighted city that actually provide free wi-fi. So I need to be able to produce an entry without the Internet. Ideally, when I arrive at home and am enfolded in the warm embrace of teh intarwebz, I can practically just hit the publish button and be done with it.

Obviously, this will not always be feasible if I want to use media from the Internet or don't have my research duckies all lined up in a row, and that's ok. I can probably somehow manage to bring myself to do that last 5% at home. Sometimes.

Typing on the iPad

It's quite good. But there are a couple of features that would be really nice.

• A quick undo, similar to on a computer, that scratches the last batch of letters I typed. Backspacing is too slow relative to the amount of mistakes I make on this keyboard. While it can backspace a word at a time, it takes too long for that to kick in.
• A way to delete (as opposed to backspace). I need to replace the first letter of a word often enough that this would save a lot of pain trying to move the cursor to the precise position, or just selecting the word and typing it over again.

Fundamentally, I don't mind making lots of mistakes. But I have to be able to fix them quickly and easily, else it becomes a huge drag on typing speed. There might even be ways to do these things that I haven't figured out yet. I would have mentioned paragraph selection, for example, except I just figured out how to do it right now.

Blogsy

Blogsy is the app I've typed this up in. I haven't seen any other blogging apps for the iPad, excluding the various site-specific apps or doing it directly from their web interfaces. Currently I use blogger, and I don't think there's an app for that. Being able to pull media from your accounts or the Internet at large is brilliant. Switching between display and markup is smooth like butter. There are a few ragged edges, but I have high hopes that they'll be polished. I'm quite satisfied with it so far.

My one wish for the app is related to my lack of an Internet connection:

I want to be able to drag and drop photos and movies from Photos and Videos local to my iPad into the post. I don't know if the public APIs for the photo and video services would permit 3rd party apps to integrate uploading, but if it's technically possible, this app would go from being useful to being essential, in my eyes.

My verdict so far:

I've typed and formatted this post. I'd like to add a picture or two, so we'll see what happens when I get home. It took longer than I had expected, but I attribute some of that to the process of familiarizing myself with the app. Overall, I've got a good feeling about this.

The result after posting it to Blogger is not quite WYSIWYG, but... close. About 10 minutes of tweaking and adding captions (something Blogsy doesn't seem to be able to do yet).

Update: I had a look at the blog on the developer's website, and it seems like they're updating it to add local uploads shortly. I'm excited.