An addendum to UITextField delegate guides

Hi.

I'll be posting more programming notes in the future. So that I don't forget them.

Maybe you’re working on an iOS app. And maybe you’ve got a text field, and you want the keyboard to go away, because you’re finished with it.

Presentation styles?

But for some reason it won’t go away. So you double check guides and tutorials and documentation. You even find a few things that seem forehead-slappingly obvious.

“Oh. That’s it,” you exclaim, and make that fix.

Only it still doesn’t work.

You read the UITextField class reference, again, exhaustively, to no avail.

Is your view controller a modal view controller?

Is its presentation style UIModalPresentationFormSheet?

Welcome to a fun and exciting exception! What you’re looking for is:

UIViewController -(BOOL)disablesAutomaticKeyboardDismissal

Override it to return NO. And then have a nice day.

This tip brought to you by the letter D.

Posted with Blogsy

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.

Whew.

Splash screen for the
English version

Just submitted app #1 (travel phrases) and #2 (旅行会話) to Apple's App Store. Way more painful than I expected, but it's done. Hopefully it will make it through the review process unscathed.

Then, apps that I have made will be available for download and purchase. I'm still grappling with this idea.

In fact, it's the first product that I really feel that I have created, being made available to the public at large, which they can then pay money for if they like it. (Not to me, but that's all right. I've already been paid for it.) I certainly do feel a sense of ownership in the books that I had a major influence on through editing and criticism. But that feeling is not the same as being the generative force behind that work.

Heady stuff.

Dialogue from the Japanese version

In fact, being a contract worker was extremely hard on me because I felt hemmed in in terms of the ways I could contribute. On the other hand, I didn't want to contribute to every aspect of the business - I wanted to focus on making a great app. And even though I did contribute beyond the app, sometimes it was frustrating that I was spending my time on peripheral things rather than getting the app itself done. It was an unexpected tension that I basically avoided trying to discuss or resolve.

I'm listening to an audiobook called Critical Conversations, which has some good insights as to why people do really poorly in expressing themselves. I want listen to it again and make an effort to have these kinds of conversations, rather than avoiding them.

At any rate, my next step is to put together a personal site that I may direct all of my adoring fans to. Picking a theme from Google Blogger is, I feel, insufficient. Then I hang out my shingle as an iOS developer for hire. Or something to that effect.

Exciting times.