cURL is awesome

Multipart forms bring out a whole new dimension for cURL, showing how it is once again the premiere tool for doing command-line HTTP tasks. It’s worth your while to check out the manual pages, especially these concepts:

  • < vs. @
  • -F
  • Why do some solutions suggest \r\n ?
  • cURL will do the boundary header for you!
  • –trace-ascii “debug-output.txt”
  • Why does one solution suggest –data-binary @multipart-format.txt ?

cURL multipart form for ASP.NET

A file upload widget accompanying a form changes the whole exchange: instead of the usual long params to send, each is separated into its own sections, boundary pieces governed by dashes and a cryptic string. cURL will handle these for you, and your usual tools – with some modification – can pull out the additional parts.

curl -F "key1=value1" -F "key2=<long-string.txt" -F "key3=value3" ^
  -F "key4=value4" %url% > response.txt

Suppose you don’t really use the form to upload a file, because the upload is optional; suppose you still submit some info. Then you can simulate sending an empty file – if the HTTP traffic shows it – like so:

if exist nosuch.txt ( del nosuch.txt )
C:\cygwin\bin\touch nosuch.txt

curl -v -b cookies.yum -F ... -o "" -A "%spoofagent%" ^
  -F "filetemplate=@nosuch.txt;filename=;type=application/octet-stream" ^

Sikuli workarounds

Sikuli is pretty awesome, but it runs into the same issue as any Java deployment: how to make it as painless as possible to get it up and running. And for speed, starting up Sikuli is slower than an experienced power user. I managed to create a 100% AutoIt solution for some of these issues:

  • Printing from the browser. Traverse all Internet Explorer instances and compare by title. Traverse frames if necessary. Use _IEAttach(). Then grab the print button, _IEAction() click, and _IEWait(). When the Print Preview loads, Send(“^p”) or Send(“{ENTER}”).

Actually, that was the only issue. Everything else could be done in AutoIt. I guess I have not run into a serious enough image-recognition problem yet.

Crawford’s carts

Reading about Moonbase, the best game that never was, made me wonder about skill culmination. I usually try to think about how to apply a concept once I have encountered it, but imagine stuffing bits of code references into your mental bin, pointers to longer examples already written: that steady accretion is a growing allocation in your untested toolbox, but there for composing bigger ideas. Even exposure to the execution might be enough for your mind to refer to it later, even when you have no idea how to make a useful app after learning one thing (like TextArea).

That’s my approach with “Game Programming All in One” for now: finish the book. Finish it, and then look back when a project presents. I may have a better idea of what’s possible after the grind, after the tedium of laying out tiles and plowing through examples. The algorithms are common in many games; adhering to each new concept as needing a new executable would involve a lot of repeat typing.

The other side is the “Art and Fear” side: quantity over quality. This aligns with establishing fluency. I make an exception, because games are gestalt productions: you’re likely to need sound, animation and double-buffering in any of them. Those techniques are universal and just need to be learned.

On human computation

I am almost to the end of “Exploring Java.” The promised hope is near: the custom component, a rotating dial, in Java. It’s the sort of tempting brew I found in Welsh’s Tcl book, when he covered an asynchronous clock in C and a custom slider widget.

I’ve been writing more source than typing it, straight into the notebook and comparing approaches: whether to use a Frame, when to use a lightweight component, and that one line that makes the whole example worth a second glance.

GUIs in this perspective are made with reusable components, fitted purposefully together and arranged in a deliberate hierarchy. This discipline forces design up front, and in my case may do some good: I must iterate on paper the better thing, so that the code shows the best one.

Accountants and computing

A book from the 80s expounds the duties of an accountant:

  • measuring data (money)
  • providing reports for higher-ups (decision-makers)
  • bookkeeping (data entry, et al)
  • processing

How close is development to accounting? It seems fairly side-by-side. At least in my case: automating Excel, collecting data and distributing files. Finances are critical though, and maybe learning some will help me be a more conscientious programmer. (I also have to learn it for general business stuff anyway.)

Entrepreneurial force

There are two alternatives to not having ideas: be a cover band or create worlds. The first concept is to write implementations of familiar tools, like a file browser.

The second is to take innocuous exercises and expand them to fill the mental space of ability: calculating totals in a sentinel-controlled loop becomes a full-blown CRUD app with emailed reports and fancy graphics. My CS prof’s words come back: “How far can you go with it?”

How many exercises to a common library of tested code? That would be an interesting way to grow a framework.

Late-bound reports

Associating data too early: if the format changes and you don’t have enough separate files, breaking them out is more work. So, sometimes I have files organized like this:


Each directory represents a transform step that gives a valuable artifact.

Enterprise, enterprise

One of the largest software companies in the world offers solutions, and there is one we are about to implement that essentially destroys the scrappy bits: the shelved scripts, encoded knowledge lingering enough to be its own museum and mistake graveyard, could become obsolete with this launch.

As developers, it’s cool to empower users, especially “self-service” features, which before required a special call and a technical talk. But it’s wrapped in its own glitter; there’s a training package; and it feels I could be relegated to “application support.”

It’s frankly terrifying. The intuitive dichotomy protests a difference between mastering a handful of tools with manual pages and learning formal abstractions. I would have to reconcile a grasp of command-line options with knowing which menus and buttons to click. If they are the same in their separate contexts, why do I resist?

Paper drive

Finished out a notebook today. Moleskine used to have their page-spines bound with another layer of thicker, but lately it’s either peeling or absent. I ought to get those returned for proper ones, if only as evidence of looser quality control than a permanent process. I don’t want to switch!

Writing with a particular gel pen, I can only write two pages at a time. The ink is too wet and I feel I’m composing an ancient scroll. At least it’s mostly source code, so I guess it’s certainly worth keeping. I also have to write neater, because the wider bleed magnifies mistakes.

My next try is Baron Fig; I ordered one but forgot they don’t have the elastic strap. Maybe I can rig one with a rubber band and a couple heavy-duty staples.