violasong.com

Beautiful Code and Beautiful Software

Mon, 29 Oct 2007 00:35:39 -0600

Programming was fun because I could make cool stuff, but what actually got me obsessed about it was suddenly seeing something interesting in the semantics and syntactics of the very lines of code. Being sensitive to the difference between good and bad code was intensely motivating, and discovering ways to write efficient, self-documenting, and thoughtfully-organized code was something I knew could captivate me forever. This is what I loved (and still love) about my field—the art of programming, the wonderfully complex craft that could take a lifetime to master.

As I added to my Ruby knowledge Java and then Objective-C, I began appreciating software development at a lower level. I grew up in an environment (the Rails community) where there was a lot of hate for those big verbose languages, but upon actually experiencing them for the first time myself, I discovered that I enjoyed them. They were different, but still interesting in differing ways. And hey, there was something satisfying and clarifying about writing dumb code after being born in high-level land—my first for-loop in Java, for example, helped me better appreciate the cleaner, object-oriented practices I knew, but I also saw something appealing in the for-loop itself. It wasn't just elegant language that intrigued me, it was also the basic logic behind the syntax, and the fact of differing syntax. Computer language, and differences in computer languages, were fascinating in and of themselves.

I had the same satisfying feeling when I first learned Assembly in college this term. Assembly was tedious and sometimes quite painful, but the way it made me think about basic programatic functions in such new ways was completely worth the pain. Of course, I also got a geeky pleasure just from being aware of the low-levelness of the code I was writing.

It gets worse! I had a great moment of self-discovery when I read Wolf's Programmers Don't Like to Code early this year. I indeed love the problem solving, elegance-creating, coding-to-learn part of coding, but I realized that I actually like coding for coding's sake, too. At least, that's how I describe my enjoyment of CSS and XHTML. I have an extensive enough grasp of front-end programming that I don't often solve a new problem these days (in fact, problems that take me a while or bugs I haven't seen before can be downright thrilling). Yet, I still enjoy working with the stuff. There's something relaxing about dumping out good-looking code that I understand very well, sort of like how I enjoy doodling the same cartoon cat over and over in my class notes, or how I enjoy playing the same three tunes when I sit at a piano. Even just looking at good CSS—well ok, my CSS, with everything ordered, indented, and cascading correctly—feels good in the same way that I felt bad, almost physically ill, as I waded around in the stylesheets of a certain forum software and found inconsistent indentation, extra line breaks, commented-out junk styles, and styles disabled by deliberately misspelling the property name.

This is what happens when you're so easily inspired, interesting shadows on the walls motivate you to continue living. You have to come back in once in a while and reorganize your levels of sensitivity so that your appreciation for light and sound is appropriately proportional to your appreciation for Off-Off-Broadway.

That is to say, these days I've been thinking a lot about the software part of software development. Specifically, the design of user interfaces in software. At BARcamp this year, I liked how Aza Raskin asked all developers to raise their hands, then all designers, later saying that the hands that went up the first time should have stayed up. All developers should be designers. At least, that's true for all developers lucky enough to work jobs where they have a say in the design of their software.

I'm getting increasingly excited about the importance of design within development, especially as I come to terms with my different passions and reflect over some of my past gigs. In the web app contracting world, design and development are usually separate jobs. In some cases, the design job is minimized in comparison to the rest of the project because clients generally pay for features, not for beautifully thoughtful design. On a project where I played both design and development roles, I recall feeling uncomfortable because I was assigned only two days to complete the visual design. It needed a lot more than two days. It was a complicated application that deserved weeks of rigorous iteration and conversations with the client. Unfortunately, that's not what the client was paying us for. The client was perfectly fine with the version-one mockup that took me a couple hours, and well, we had an app to launch.

I had another wake up call while I was at C4 this year. It appears that many Mac developers, perhaps most of them, are solo indies producing their own products. As such, they really do have to be both designers and developers. Actually, design is often the most significant part, and there seems to be a lot more enthusiasm over user experience and just producing a great product than there is over the code itself. One night during C4, someone inadvertently helped me see this when he described to me the nature of his work: "Coding the basic functionality is the easy part. That just take a couple weeks. What's really hard and time consuming is figuring out the specifics of the UI."

Wow, I thought. Why does that seem so right? Why is that so cool to me?! Oh, right, I'm a designer to begin with. There are dramatic rifts between my enjoyment of development, design, and art because I appreciate each of them in very different ways. I constantly try to integrate development and art, but I really ought to figure out how to mix all three.

After all, my goodness! Do we want beautiful code, or beautiful software? Here's another peek into my life: A side effect of being extremely open minded and absorbent is that I find myself believing all kinds of contradictory ideas, sometimes even opposite ones. It doesn't bother me right now because I'm in exploratory mode, not know-what-I-believe mode, but to retain sanity it is, of course, a must to occasionally sort things through until they make some kind of sense.

Thus, for further consideration I've listed just a fraction of the many things people like about software development, loosely ordered from the most intrinsic rewards to the most extrinsic rewards. I've left out a lot of really wonderful stuff like community, open source values, and challenges because those are harder to fit into this order, but I think you'll get the point. This is an extremely interesting sort order to me because of how psychologists say that intrinsic motivations are stronger and more likely to keep you going. For example, the person who takes karate classes because she feels energized and excited by the sensation of punching and kicking will more likely end up with a black belt than the person who takes the same classes for the health benefits.

Is it the same for programming?

The sensation of writing code
The knowledge that one is writing code
Enjoying computer logic
Enjoying computer language
Elegant syntax
Elegant semantics
Learning about code
Problem solving
Learning about problems
Achieving usability
Finishing a product
Elegant software
Solving human problems
Solving business problems
Satisfying market needs
Making money
Having a stable career

Which is the most persistently motivating kind of reward? Most importantly, which kind of motivation produces the best software? I'd love to do some formal research on this topic sometime, but I'm already pretty sure that the answer is "a healthy balance of most of the items on this list," as we certainly want our software to be both usable and maintainable, and sellable, and everything else. I'm also pretty sure that the balance is different for every situation and person. At the moment, however, I envision a wide bell-shaped curve sitting upon a rectangle, and everything turned on its side—the motivations that result in the best software are the ones nearer to the middle of the curve; but really, I think all of the motivations are beneficial in some way, and insofar as the programmer has her priorities straight, the more the better.

The tragedy of our field is that most programmers don't ever get to appreciate the majority of these rewards, particularly the more profound ones. Then again, it works out great because the majority of programming jobs couldn't possibly satisfy someone who cared about all these things. Still, I wonder what the industry would be like if we were all intrinsically, thoroughly passionate about our craft, and nobody was signing up for Computer Science classes just for the "stable career." I wonder what it would do to the world.

I think I should revisit this train of thought every year or so as I become a better software developer. I get the feeling, though, that my fate is already somewhat set in the fact that the more I grow, the more I desire a working situation where I have enough freedom to create beautiful things. It's probably worth noting that both freedom and beauty are vague, subjective ideas, so that could mean anything. All I know is that the compromises to both beauty in code and beauty in software design as necessitated in most programming jobs give me an unwavering feeling of discontent. I wouldn't be surprised if I ended up settling down as a freewheeling solo developer using, you know, web design contracting to support my freewheeling solo lifestyle.

Eventually I'll retire my computers and spend the rest of my days plein air painting on some beautiful farm out in the country. That, or a sensuous city life of alternating between street art missions and serving time. It's fun to imagine where I'll go once I feel done with technology. Hopefully that never happens, because I want to be the cool guru grandma who's still around when her children are giving mandatory programming lessons to their children.

PSIG 107 | Xmo'd + mogenerator: Seamless Core Data code generation

Sat, 13 Oct 2007 23:55:51 -0600

(What is PSIG? | PSIG 107 announcement)

Show and Tell

Practical Ruby Gems. Tom: "Eh it's a library book."
Gorman tells us of people coming to the Genius Bar because they've renamed their home folders and thus lost sight of their accounts.
We plug Silicon Prairie Social and I lament RubyCocoa syntax, mentioning named arguments in Ruby's future.
Kevin tells me that Python has named arguments already, but pyObjC still uses the underscore syntax because of C conversion complications.
Paul: Good articles in More Java Gems.
20 Greatest Unsolved Problems. Says Bradley: "I don't think the author is that talented as a writer. The chapter on protein folding wasn't nearly as interesting as I thought it would be." We ask if he wrote the author to complain. "I didn't write him. I could kick his butt though."
The Chinese Language: Fact and Fantasy, Elementarz Polish primer. Bradley pointed out something really cool about the Polish number system that I forget.
Programming Erlang, The Definitive Antler Reference.
Wolf's going to the OpenGL Bootcamp. "I'm not going to let you keep feeding me OpenGL lies that I've been too ignorant to counteract."
Chasing the Rising Sun. "Is it about Japan beating us in technology?" No, it's actually about the song about the house.
Dan demos the iAlertU MacBook alarm to everyone's delight. "Impressed a guy at Panera with it."
How to shoot yourself in the foot in any programming language

Xmo'd + mogenerator: Seamless Core Data code generation

Mogenerator refresher (from PSIG 98):

Object relational mappers integrate object-oriented software with relational databases. They allow you to work with objects instead of raw SQL statements. Classes map to tables, and rows map to instances. There are a few different ways to implement this:

Class first (e.g. Java Beans + XDoclet): Embed relational table and column names into the source to write SQL for you. Wolf believes this is the worst philosophy -- you can reference the data source, but there's not enough information to derive the schema from embedded metadata.
Schema first (e.g. Active Record, code gen): Link classes from the schema. Unfortunately, DDL (Data Definition Language) is a harsh and primitive landscape incapable of supporting sane metadata and you end up needing hacks. With Active Record, "you must name things the way god intended them to be named -- who is of course DHH." With code gen it means manually hacking mapping files.
Model first (e.g. EOF, Core Data): Wolf likes this philosophy best -- you start with a declarative base, but you have infinite room for sane metadata and you're not tied to any specific data source. Because it's just data, there's no need to write a parser or interpreter. You can generate both DDL and code from a single source. In dynamic languages, custom classes are optional.

Core Data can generate wrappers for all of your attributes as NSManagedObject classes or as custom subclasses of NSManagedObject. Custom subclasses are great for holding your business logic and helping with type safety. The problem is that it's kind of a tedious task to get Xcode to generate your subclasses and it usually involves a lot of painful merging due to the fact that each file contains both generated and custom code.

You can use the lovely Generation Gap pattern to help with the merging problem: put machine-generated and custom code in separate files and make your custom code subclass the generated code.

This is where mogenerator comes in -- it's a command-line tool that automates everything and makes use of this pattern. mogenerator owns the machine's files which are subclassed off of NSManagedObject, and subclassed files off of that are owned by you and untouched by the machine. When you modify your data model and invoke mogenerator, all your generated code will be updated but your custom code won't change.

Xmo'd

Xmo'd makes your life even easier by integrating mogenerator into Xcode. Wolf achieved this with the use of undocumented, reverse-engineered plugin API. Xmo'd overrides the data model document method to automatically run mogenerator for you. When you save a data model document in Xcode, the Xmo'd override fires off an AppleScript which calls mogenerator. This keeps your generated code continuously synced up with your data model. Xmo'd also adds the menu item "Autocustomize Entity Classes." Currently it works on Xcode 2; Xcode 3 support is coming soon.

PSIG 106 | NSToolbar

Mon, 06 Aug 2007 01:39:58 -0600

(What is PSIG? | PSIG 106 announcement)

Items of Interest

My Startup Life: What a (Very) Young CEO Learned on His Journey Through Silicon Valley -- We're informed the teen author manages to make himself sound like a 40-year-old what with the dry writing and needless mention of shoehorns :)
Getting Things Done: The Art of Stress-Free Productivity -- I claim I am henceforth living David Allen's principles. We'll see how it goes!
Sickert: the painter and his circle -- The story of Walter Sickert, an English Impressionist painter with some newly revealed connections to Jack the Ripper
Nothing Sacred -- Autobiography of comedian Lewis Black
Collapse: How Societies Choose to Fail or Succeed -- By the same guy who wrote Guns, Germs, and Steel
iFuntastic -- Make yer own iPhone ringtones
Paul on the Xserve, Mini, iMac: "But aren't we so pregnant for a bunch of upgrades?"
Steve entertains us with crazy stories from his awesome IT job at O'Hare. He also gets me curious about wxPython and the way you can use XML to define GUI with XRC. Most intriguing -- he predicts that the problem of computer viruses will grow hugely in the future, saying that crackers are most certainly in info-collection mode at the moment.
The meeting ends with the sharing of nasty-food/bug/pyromanic stories!

NSToolbar

Great presentation by Dave and El Wolfo involving a cowboy hat, a gaucho hat, methods named "spanishize" that define anything starting with "El " as Spanish, and oh -- we got to see some live debugging ;). Summary:

Currently, Interface Builder doesn't help you create toolbars, so you either have to do it in code or use Belkadan's GenericToolbar palette.

Doing it in code: After allocating your toolbar, initialize it with a unique identifier (initWithIdentifier) so that Cocoa can automatically remember user customizations to the toolbar. You'll also have to set setAutosavesConfiguration: and setAllowsUserCustomization: to YES. Once you've created and set the delegate, tell your window to setToolbar:toolbar.

There are four basic methods you need to manage your toolbar:

-toolbarDefaultItemIdentifiers: Specify default toolbar items. Remember to avoid name collision with Apple's standard items
-toolbarAllowedItemIdentifiers: Choose which of Apple's standard items to allow. By default none of them are allowed
-toolbar:itemForItemIdentifier:willBeInsertedIntoToolbar: Returns toolbar items as specified by the identifier
-validateToolbarItem: Called on every toolbar item. The target and action must be set and responsive for this to work

GenericToolbar is the non-code alternative: It has a nice drag/drop interface for adding and removing items as well as hooking up items to your controllers. It doesn't work very well with bindings, so it's better to do those in code.

Thanks to Gruber for the great wwdc photo upon which this is based

C4[1] this weekend!

Ok, I think this is the most excited I've ever been about a tech event. I can't wait for the sessions and I'm hugely looking forward to meeting everybody. I'm actually going to be manning the registration booth so I'll at least get to greet everyone :)

Hay -- anybody out there have an idea for Iron Coder that could use my help? I'm pretty psyched about the announced "API" because it would seem I could easily make use of my art/design/webcode-fu, but I'm not coming up with any ideas...

PSIG 105 | Dissasembling on OS X

Thu, 02 Aug 2007 01:21:28 -0600

(What is PSIG? | PSIG 105 announcement)

Items of Interest

AJAX Design Patterns
Mind Performance Hacks
The Four-Minute Mile
Million and one nights
Endless universe
Pangea Software's Ultimate Game Programming Guide for Mac OS X
Mac OS X Internals
Four members showed up with iPhones. There was a large amount of quality iPhone discussion during which I seem to have zoned out. hehe
We took a brief critical look at Leopard, particularly at how wrong the dock looks when it's on the side, and how the icons unfortunately bounce with their shadows attached.
WWDC 2007: It seems that this year's was essentially a repeat of last year's.
HOPL III: "We're still so primitive."

Dissasembling on OS X

Why disassemble?

To work around bugs
To learn more about areas where the docs are out-of-date, incomplete, or intentionally missing
To find ways to interoperate with other software, such as when implementing file format compatibility/interchange or breaking into proprietary tool-chains

Static tools: Hex editors

OS X ships with three utilities for hex dumping: hexdump, od, and xxd
HexEdit is one of the oldest mac open source apps, originally created for system 7
HexFiend is a newer open source Cocoa hex editor with more features

Static tools: General level

file tells you what kind of file something is, including all the architecture versions
strings looks in binaries to see if anything's human-readable. Use with standard input, or it'll only look into the version of the file with the same architecture as your system

Static tools: Code

Otool understands the Mach-O binary format and can tell you an app's dependencies. Apps linking to private frameworks involve Apple's undocumented stuff. Wolf: "It used to be that all the cool stuff was in the private frameworks. The last of the cool stuff pretty much went public by 10.4. So the hunt isn't there anymore."
otx does enhancements on Otool's output. It intermixes the raw outcodes into the disassembly in case you want to inject your own instructions. You can follow along and see what strings are being referenced. The tool also detects and works around some obfuscation techniques.
classdump is another tool for dumping Mach-O code. Trivia: AppKit appears to contain a class called NSEvilHacks.
MagicHat, a recently open-sourced tool, is like classdump except with a hyper-linked interface. You can specify which frameworks you care about. Wolf uses key-value coding to pull out undocumented methods.
Interface Builder can open up nibs and let you see names in the targets and actions. Make a copy of the app first because IB may leave some stuff in even if you don't save

Runtime Tools
"What's cool about software is you can put your hand up them like a puppet."

gdb debugger for obj-c.
BSInspectors, an Xcode plugin that lets you inspect objects
F-Script scripting for cocoa. F-Script Anywhere allows you to dynamically inject it into any Cocoa app. You can also dynamically look stuff up in the pop-up completer menu. The Object Browser shows you what methods are supported for the selected object. "Select view" button will inspect anything you click on and allow you to directly call the methods.

The rest of the evening was spent doing evil things to the iPhone. Also! I watched in awe as Dave/Wolf worked some fabulous Quartz Composer action into a little Cocoa toy app that I'd been working on ;D

BARcamp Chicago 2007

Thu, 26 Jul 2007 22:31:36 -0600

I had a lovely time at BARCamp. Like last year, it was a mind-expanding experience and encouraging on several fronts. This year we had more people, more energy, much cooler weather, a nicer venue (with clean bathroom!), and insanely large amounts of free food in addition to the obligatory free beer. For me, the best part was actually seeing familiar faces and getting to catch up with great geeks like Peter Chan, David Dalka, Peter Harkins, Justin Kruger, and of course the amazing Jason Rexillius. It especially rocked to finally meet my fellow DevChix, Jen Stander and Sarah Gray. I talked to a lot of interesting new people as well, like Rich the sound guy, Ben Collins-Sussman-SVN, Joi Podgorny, Conrad Albrecht-Buehler, and Atul, Aza, & Jono from Humanized.

Here are highlights from some of the presentations I attended:

Mass Customization: Next Generation of Software is Hardware -- Ziad Hussain

The dream is that ordinary people should be able to manufacture their own gizmos. We ought to have a Kinko's of fabrication -- a service that would allow users to design an item to be produced in full plastics and circuitry right away. Currently, some very interesting work is being done in producing cheap rapid-prototyping machines like RepRap and Fab@home. Geared to home users who can't afford commercial systems, these machines aim to democratize innovation.

Why most businesses fail, most businesspeople are miserable, and why you'll be different -- Sean Johnson

People seem to think that success requires either (1) working systematically for 50 years to get to the point where they can live the good life on a pile of money, or (2) hitting the jackpot on a business idea that rakes in the good-life piles of money right away. But what is the good life? Your dreams probably cost a lot less than you think. And in some cases, they are dreams you could be living right now.

Sean described ways to break free from standard business models in order to start happier, smarter companies. He discussed our tendency to put too much care on the validation of our peers as well as "VC money, a few hundred diggs, a write up on TechCrunch, etc." He encouraged us to, instead, design useful products that will help everyday people -- products that make money at every single sale.

Dynamic Mashups with RSS -- Aaron Williams

Kirix Strata is a data browser based on the Gecko engine, currently for Windows and soon to run on Ubuntu as well. Strata's aim is to make it easy to uncouple data from its context and render it usable. With a few clicks, Aaron demonstrated Strata's ability to import static HTML tables and RSS feeds into database form. He then showed us some database management features that remind me of Access and Excel. I was most intrigued by the Relationship Manager -- a GUI database editor which allows you to do wonderful things like visually join tables together.

Building Geo-Distributed Web Applications -- Jason Rexilius

Geo-distribution is a single app running simultaneously in multiple locations around the world. It could involve server clusters, network routing, multiple data centers/providers, or multiple carriers. Says Jason: Premature optimization is bad; ignoring your objectives is also bad. He gave us some interesting technical ideas on building web apps, encouraging us to think outside the database and leverage the right tools for the job.

Lisp -- John Quigley

John truly loves Lisp. I'm pretty sure his trembly, tender speech was the most passionate I've ever seen anyone get about any language. Lisp, he says, forgoes the syntax so you can get to the heart of the matter. It's a highly dynamic language that grows to meet your needs -- a programmable programming language for doing the impossible. Throughout John's presentation, he tried to help us see that Lisp was not some crazy language with a hideous syntax, but rather a gorgeous language with a very logical syntax.

The most interesting part was his explanation of the XML format and how it relates to Lisp. XML's tree design allows it to be both code and data, resulting in a very simple, flexible, and extensible tool -- the same is true of Lisp. An in-depth exploration of this idea can be found here.

For learning Lisp, John recommends Structure and Interpretation of Computer Programs, and two other books depending on your approach: Those wishing to take the practical path should read Practical Common Lisp (also available for free online). Those taking the academic path should read Paul Graham's ANSI Common Lisp.

DIY Beer - Tristan Sloughter

With beer in hand, Tristan gave us a beautiful talk on homebrewing.

Ingredients:

Malts -- Barley that's been malted, sugar. Provides body, color, and some flavors (chocolate, coffee, smokey, etc)
Hops -- A flower which provides bitterness (oils, measured in IBUs), hoppy flavor, and aromas like citrus and fruit
Yeast -- A fungus which creates ethanol by eating glucose from the malt; provides subtle flavor/texture
Other -- Irish Moss, insingglass, gypsum for clear color, Belgian candi, lactose, fruit, honey, coffee, spices, wormwood, pizza

Types:

Ale -- Top fermenting. Temp 65-75, belgian ales up to 86. Most common & easiest.
Lager -- Bottom fermenting. Temp 45-55. Harder to make and refrigeration. Mellow, crisp flavor.
Lambic -- Uses wild yeast. You leave your fermenter open and let any yeast (such as from a barn) fly in. Dry, vinous, cidery, sour aftertaste (the taste of bad beer). You can actually buy "wild yeast" to make your Lambic.

Equipment -- You need a 4 gallon pot and a kit from, say, Northern Brewer. It's an initial $100 investment for the kit and another $25-40 for ingredients, but in the end you're only paying 50 cents a glass instead of $1.25 for beer of same quality.

The process of brewing beer is essentially boiling the malt, adding hops at some point (depending on how bitter the beer should be), plugging it with an airlock and waiting for 3-7 days. I was amused by the formula for measuring IBU:

(gallons of brew * 1.34) / (oz. of hops * Alpha Acid * (time of boil) / 2)

"Happy brew hacking," Tristan concluded. "It's just like programming -- have fun with it, try different things, get drunk."

Enterprise Searching -- Dieselpoint

A guy from Dieselpoint gave a nose-bleedingly intense and detailed talk on different methods of searching for data and why enterprise searching is such a complex problem. There were some major gems in his speech, though they were a bit hard to understand -- I wished the talk had been more simplified and BARcampy rather than Fortune-500-board-meetingy so that we could have all internalized it better. I was impressed by the huge role linguistics play in searching and the many creative ideas for improving search engine performance.

Groovy -- James Williams

Groovy is an agile, dynamic language for the JVM that can fully integrate with Java. It looks similar to scripting languages like Ruby and Python in the way they've pruned away a lot of the Java syntax. For example, printing Hello World is as simple as: println "Hello, World!" Groovy includes some extra features such as closures, dynamic collections, and builders, which allow you to build data types with a tree-based syntax. The point of Groovy is not really to replace Java but to give you an alternative to more quickly code prototypes, UI, one-off apps, and extensions.

Getting involved in FOSS -- Freddy Martinez

I was completely impressed by fellow underage kid Freddy and his impassioned talk on getting into open source. He made several points I can totally confirm, such as the importance of users groups and mentors. His mentor actually got him started in the community by saying: "I'm doing documentation work. Wanna help edit?"

How to protect your open source project from poisonous people -- Ben Collins-Sussman

In any community, attention and focus are your scarcest resources. You must protect them from people who distract, emotionally drain, or cause needless infighting. It's not just trolls who are problematic -- perfectionists can also derail forward progress. It's important to do something about those who complain without helping, insult the status quo, are unable to pick up on the mood or common goals of the project. Ask questions like: Is the person draining attention and focus? Is this dispute worth it? Is the person paralyzing the project? Is the dispute likely to finish soon?

Don't: feed the energy beast or get emotional. Do: initially give people the benefit of the doubt and look for the facts under the emotions. Know when to ignore or forcibly boot someone. Most importantly, address the behavior, and not the person.

Build your community on politeness, respect, trust, and humility. The community founders establish the culture, and in turn, the culture should become self-selecting. Pick a direction and limit your scope. When you're limited, it's easier to measure your progress, easier to get people to join, and easier to screen away people who shouldn't join. Example: SVN's scope was solely to create a compelling replacement for CVS.

Have well-defined processes as far as backporting bugs, accepting and reviewing patches, and admitting new committers. Document important design decisions, bug fixes, mistakes, and code changes. Have healthy code collaboration policies -- send commit emails and encourage email review. Do big changes on branches for easier review. Increase your project's bus-factor on components by spreading the knowledge and not allowing names in files.

Humanized: Tales from developing Enso -- Atul Varma, Aza Raskin, & Jono DiCarlo

The guys from Humanized really have an good grasp on interface design, and their talk was one of the most inspiring I've ever heard. There's actually a lot more to their Enso products than the unfortunate labeling of "Quicksilver for Windows."

One of their major concerns is the problem of modal interfaces. Modes are in their essence confusing because every time a mode changes, a user's habituated actions are no longer relevant and she has to break her train of thought to add yet another set of actions to her memory. Says Humanized, almost everything that frustrates users about interfaces is due to a mode. That's why good interfaces have as few modes as possible.

In Enso, users hold down a key to get into the universal quasi-mode. It involves visual feedback, but also kinetic feedback, which is more effective -- your brain remembers you're in that mode because your finger's down on that key.

Another thing Humanized believes in is building from scratch. They say the toolkit straightjacket, while providing consistency, kills innovation. You can't be better without being different. You can't different without taking the time to make your own stuff.

On design: People think the GUI is just picking a good shade of blue, so it's pushed back to the end. In reality, all programmers should act as interface designers right from the start. As soon as you design a program, you're designing an interface. To the user, the interface is the product.

On the curse of being a geek: No matter how good you get with computers, you still have to design your programs for normal people.

PSIG 104 | JS <3 ObjC

Tue, 26 Jun 2007 00:04:20 -0600

(What is PSIG? | PSIG 104 announcement)

Items of Interest

The meeting began with a session of forced pre-WWDC iPhone speculation ^^;
Dave announced he'll be writing a column on beginning Mac programming for MacTech!
Definitive guide to SQLite: SQLite is great for read-heavy apps, like blogs, but it's limited when comes to writing, as you can only write when no other accesses are occurring.
Learn F-script in 20 Minutes, The Wizard of Menlo Park
Tom: iden.tify.us was featured on Mashable!
Paul: Building windows machines "a royal pain in the tush" -- alas no combo updates.
Wolf on backups: Rsync works well except for resource forks; however, if you really care about maintaining absolute data integrity, use SuperDuper. (This reminds me, I totally had a dream the other night that my only-partially-backed-up MacBook fell apart into tiny irreparable pieces. Oh, and that random thunderstorm last week completely toasted one of our WinXP boxes. Heh...)
Hacking MacOSX Tiger
Paul got into true old-fashioned Show and Tell mode and presented to us some random, interestingly-designed objects: Voss water bottles, weird tape dispenser, an impact stapler.
Gorman's been busy with wedding preparations. "Does it involve writing software?!?" "Yeah..." He's doing an WebObjects app for his wedding registry.
Dan quotes his Roosevelt professor on the Unix lab which is actually comprised solely of Emacs: "Why Macs? I start the semester with 16 working machines, and I end the semester with 16 working machines."
Wolf: The Accidental Mind
Wolf on the relative lack of interest in HOPL III: "This is why software's doomed."
WebKit open source web browser engine -- looks like a neat project. The new Web Inspector sounds especially interesting.

JS <3 ObjC

Introduced in OS X 10.4, the JavaScript-ObjC bridge is currently the only officially-supported bridge. The bridge makes it easier to work with AJAX libraries, JavaScript plugins, JSON and DOM (jquery). It also gives you access to regexes (which aren't built into Cocoa) and helps you build WebKit UIs. It's somewhat limited compared to other bridges as it was created specifically for the development of dashboard widgets (which, essentially, are just webpages made with HTML, CSS, and JS). The bridge automatically morphs over numbers, strings, and arrays, but not dictionaries.

Running JS from Objc is simple:
- [WebView stringByEvaluatingJavaScriptFromString:]

With a WebView (which can be hidden), you can call any JS from ObjC.

For security reasons, there is more resistance when calling ObjC from JS. By default, all ObjC selectors and keys are excluded from JavaScript access. You override the boolean methods isSelectorExcludedFromWebScript and isKeyExcludedFromWebScript to allow access.

Security note -- anyone can open up your package and view the JS and HTML, so it's a good idea to put the more sensitive stuff in the compiled ObjC. (However, says Wolf, f-script would get you through that, too :).)

Last weekend I was at BARCamp Chicago! Perhaps a post on that at some point...

PSIG 103 | PackageMaker

Mon, 25 Jun 2007 23:05:32 -0600

(What is PSIG? | PSIG 103 announcement)

Items of Interest

We note a new version of the disassembly tool otx and check out some of its new features. I must say... I get some warm fuzzies from the way it's released in public domain and anonymously :)
Programming in Lua
Dark Carnival
Einstein: His Life and Universe
Dave mentions that he filed a bug report on the aforementioned issue revealed by DDHidLib's device browser. Apple closed the report citing no problems, and lo, the latest version of OS X indeed does not have the bug. We verified that it still is around on 10.4.8, however. Apparently somebody fixed it some time between 10.4.8 and 10.4.9!
Infinite Cat Project: =^_____^=
The Psychology of Computer Programming
Micro-ISV
Frontiers of Justice
It is agreed that the best way to update OS X is via the combo updater which one downloads from the Apple site, as it tends to be much more reliable than Software Update.

Installer packages

.pkg -- The package format includes two key components: archive.pax.gz, where files are gzipped up with the pax archiving tool, and archive.bom, which contains the permissions metadata pax can't handle.

.mpkg -- Meta-packages are packages of packages, often used by Apple for system software. This is what enables the screen of checkboxes that allows the user to specify which components to install.

PackageMaker.app is Apple's GUI tool for making .pkg files. It's nice in that it gives you a sort of realtime preview of your installer, but it's hard to understand and crashy (it actually crashed during the demo). One thing to note is that when PackageMaker refers to "root," it's actually talking about your source folder, where you recreate your directory structure. Another thing interesting is that if you set your identifier (i.e. com.violasong.pkg.killerapp) in the package version, the install button will display "Upgrade" instead of "Install" if it detects an older version.

Other notable tools are Iceberg, an open source GUI packaging tool with a more direct UI, and the Pacifist extraction tool, useful for extracting your files without Installer.app for sanity-checking purposes.

It is recommended that you use GUI packaging tools only to generate the required description.plist and info.plist files, which can then be modified and reused to work with an automated command line solution. Wolf gives us a handy script that provides just that! You will unfortunately have to decipher a code in order to acquire said script.

Or if you are lame, you can click here instead. Enjoy!

Art notes: I have explored a few different possibilities in anthropomorphizing packagemaker.app.

In my polisci notebook, a doodle of cheery young fairy girl packaging a sweet potato into a box. There is also a bad sketch of an elf wrapping a pumpkin in a square of cloth.
In Photoshop, a blood-soaked, battle-scarred humanoid with glowing eyes and long green hair, packaging a small magic fruit into a golden capsule. After several evenings of high-res labor, I pretty much deemed it unfit for public viewing or further development.
In Photoshop, a weeping grayscale Cherokee man holding a large cracked egg.
In my proper sketchbook, a hasty pen drawing of an ugly version of the fairy girl holding a small version of the humanoid's magic fruit capsule.
Also in my sketchbook, a terrible pencil sketch of a foodservice operator eating the .PKG icon; the only image I decide to show the world, naturally.

PSIG 102 | QTKit: 1990s Multimedia Wrapped in 1980s Objects

Mon, 09 Apr 2007 11:56:20 -0600

(What is PSIG? | PSIG 102 announcement)

PSIG last week! I stayed for the whole thing this time, which means I was there till hotel security kicked us all out around 2 AM :). I've decided life is way too short to worry about leaving PSIG at a sane hour. It's just that good of a group.

Books, demos, notable tidbits

Blake C. informs me that the "interesting feature" I mentioned in my last PSIG post regarding Dave's device browser is actually a significant exploit, and that by blogging about it, I am thereby responsible for releasing it into the wild. Eheh, oops? ^^;;
I talk about why I ~~hate~~ am mildly critical of Twitter. Half the group's never heard of this hot new Web sensation, so Wolf helps out by demonstrating the app and executing a few tweets up on the big screen. After much drama and debate we eventually come to the agreement that Twitter can be both good and evil, depending on how you use it :)
Ben Gottlieb demoed his winning Ironcoder app -- a screensaver that tiles Wikipedia pages!
OpenGL SuperBible
Jason demoes the FizzBuzz program he wrote in Erlang, as well as a version of the program he created in Quartz Composer for all our rainbow-colored FizzBuzz needs.
Paul tells us he succeeded in booting OS 10.4.6 on his G4 off of a Lacie USB/Firewire thumb drive.
Essential PHP security, Professional PHP 5
It is stated that "it's too hard to find Rails jobs." I suggest the checking out of jobs.rubynow.com, rubyrockstars.com, and jobs.37signals.com. Tom says he does not recommend Craigstlist ;)
Game Physics: Engine Development, In Search of the Ultimate Building Blocks, Facts and Mysteries in Elementary Particle Physics. Love the comment on that last one: "It was written for the intelligent layman, which is what I am."
Mastering Cmake
Dave mentions that his King's Quest game for Windows actually runs using DOSBox, so apparently it was really easy to thingagummy the whatsit and... something. Way over my head ^^;;.
Later Dave demos an amusing new feature to his MAME OS X emulator -- Quartz Composer integration! For all our rainbow-colored copyright-violating video game needs!
The transferring of a wheresgeorge.com dollar occurs at some point.
"Now why did that die?" "Cuz you're plugged into the projector, doing a demo."
(On Parallels) "I like to see this as the right place for Windows -- in total subservience to OS X."

Iden.tify.us

Tom gave a great presentation on his Crazy New Web 2.0 Startup Site, iden.tify.us. It's a community site where users can upload music files or add video links and get their songs identified by other users. By Web 2.0, we're talking features like an embedded player for your site, tag clouds, RSS feeds with podcast enclosures, and "no business model. (YET!)" Looks promising :).

QTKit: 1990s Multimedia Wrapped in 1980s Objects

Wolf gave an very informative talk on QTKit, the Cocoa framework for QuickTime. He walked us through QuickTime's history and explained the .MOV file format. Basically, QuickTime files are organized in hierarchically nesting data units called atoms. There are classic atoms as well as the more powerful QuickTime atoms, which can tell you whether or not they contain other atoms. This container format has been made a digital media standard, and is the basis for formats like MPEG-4. You can use Apple's Dumpster tool to examine and edit atoms.

You can also examine the different tracks on unmuxed video files using QuickTime Pro. Besides the audio and image tracks, we find that Cocoacast episodes include a disabled text track which contains all the chapter titles, and another text track which holds the hyperlinks.

Apple's first attempt to provide a QuickTime interface was in the easy to use but very basic NSMovie and NSMovieView, members of the AppKit framework. These were deprecated in OS X 10.3 with the arrival of QTKit, which replaced them with QTMovie and QTMovieView. QTKit also comes with support for user media editing -- the same stuff that makes up QuickTime Pro 7. QTKit provides read-access to slight majority of the data model, but much has not been Cocoa-fied yet.

In addition to QTMovie (subclass of NSObject) and QTMovieView (subclass of NSView), QTKit provides 3 other NSObject subclasses: QTTrack, QTMedia, and QTDataReference. There are also two data structures: QTTime and QTTimeRange.

A warning: Apple's website contains a lot of old QuickTime information that doesn't apply anymore, and unfortunately, a lot of the new stuff isn't documented anywhere. The nice thing about the "language barrier" between old C and Obj-C is that you can tell it's the new stuff if it's in Obj-C. (I've also noticed that the old pages are styled differently, with Apple's old serif font for the title and smaller body text which shows up non-anti-aliased on my box. Of course, when you have screenshots like what you find on this page, that's a good clue as well ^^.)

See Apple's QTKitPlayer sample code for a demonstration of QTKit's capabilities. It comes with basic control graphics, but you can totally poach the big shiny QuickTime buttons from your Mac using Spotlight. An important point is that QTKit does not show up by default in Interface Builder. It's an optional palette which you have to enable in IB preferences. All of the optional palettes are located at /Developer/Extra/Palettes/.

Hopefully, says Wolf, the QTKit API will be fleshed out soon. The FAQ for QTKit seems to suggest that some of this will happen in OS X 10.5.

Chirb, April 2007

Wed, 04 Apr 2007 12:20:03 -0600

I went to the Chicago Area Ruby Group on Monday for Andy Lester's talk on project management. No crazy story this time because I took the train, although I did have to jog most of my way to the Thoughtworks building, which always seems to be my lot with the Metra schedule no matter where I'm going or when I need to get there. Note to self: If the appearance of composure is any priority, take cab ^^;;.

Half of Andy's presentation was about his alternative to the agile methods of project management. The other half was on technical debt, which I found rather interesting and fairly applicable to IBLP's IT operations. Here's a loose summary of his presentation (slides available at Andy's site).

Project Estimation and Tracking

1. Write it down. The project should be started with some sort of written document. Programmers like to begin coding right away because they think they know what the customer wants, but that's often not the case. A written agreement will help you avoid misunderstandings and will get any immediately obvious questions answered right in the beginning. Wikis are a good medium for these documents because of their collaborative and malleable nature. "It's not like in the 90's where one guy was Master of the Document."

2. Estimate. Give a rough idea of the time/money cost up front. This helps the customer to prioritize and prune, as well as feel in control of the project. Make sure they know that it's not a rigid commitment, because the next step will adjust your estimate.

3. Refine. Break up your estimate, perhaps into outline form for each task. You're doing design as you go, so keep notes. No subtask should be longer than 4 hours, because you can't estimate accurately above half a day. Doing it this way helps to distribute risk: Estimates are usually off by 100%, not 10%. You may need to take a day to sit and think about what you're getting into. You're paying up front in time to be able to know where the end point is. Remember that typing is not programming -- thinking and breaking down tasks is programming.

4. Plan and track your tasks. Write out your task plans Friday afternoon so everyone knows exactly what to do when they come in Monday morning. Try to finish each task before going on to the next one. Track your tasks so you always know what your status is, even in the middle of the week.

5. Adjust as necessary. Sometimes you'll need to shuffle the order, re-estimate, or break up tasks further. When handling new requests, say, "I can do it, but I'll need a day to tell you how long it will take." Customers need to know that nothing is free and that even the estimation of new features will take time. "Do you want the 30 second, half-hour, half-day, or half-week answer? That's what it'll be worth."

Always be aware of the status of your project. If you know you're not going to make a deadline, you should tell your boss or customer as soon as possible. Be honest with everyone, including with yourself.

Getting Out of Technical Debt

"Try to think of Peter Francis Geraci's face looming over you as we talk about this."

Identify your debts:

Clutter -- disorganization and confusion
Failing tests, unfixed bugs, unpatched security holes
Fragile or ugly code -- this often means the code is not read, maintained, or understood
Code without comments or outdated comments (an amiable audience member adds: Strive to write the kind of code that doesn't need comments, but do maintain your documentation.)
Truck-sensitive knowledge (the truck-factor: How many people can get run over before your company collapses?)
Code ownership -- this makes the code truck-sensitive, and a bottleneck
No coding standards -- standards help minimize the arguments and the time wasted worrying about or fixing differing code styles
Missing infrastructure -- do you have version control, bug tracking, backups, cron jobs to do your dirty work?
Jerks on the team -- they may be a negative productivity factor
Jerks in management -- well, that's beyond your control
Not realizing you have tech debt, or ignoring it

Determine the cost of paying the debt. Think in terms of time, money, and risk. Create the justification to sell your boss/customer on your changes in corporate language. Quantify everything: What exactly is the improved turnaround, extra quality, and decreased risk worth? All cost assessments must include opportunity costs: What could be done if this change wasn't made?

"Land one plane at a time." Watch the corners and the center will take care of itself. Automate your corner-watching.

Avoid future debt by not incurring more debt. Take notes when you incur debt anyway.

"However," Andy concludes, "Sometimes you just have to do what the customer wants."

ChiPy, March 2007

Mon, 12 Mar 2007 01:07:10 -0600

I attended the Chicago Python User Group last week, lured there by the mention that ChiPy member Ian Bicking works for the One Laptop Per Child project and would be bringing his own beta test 2 Children's Machine to the meeting. The little alien laptop destined to save the world is a topic I've become very curious about, especially now that one of my side projects is directly related to kids in computing. I've also been curious about Python for a while and have been looking for an excuse to go see what Pythonistas are like (turns out there's Ruby-hate, just like how Rubyists have Python-hate!). On top of all that, the meeting was being held at the Chicago Google office, so of course the Google fangirl within demanded that I check it out.

The night turned out to be quite an exciting series of misfortunes and mistakes, starting from the moment I decided that the Metra schedule seemed "inconvenient" so I'd try driving downtown for once. I mean, going with Metra would entail the complication of catching the train, the waste of an entire hour each way (while the drive only takes 40 minutes each way, according to my Google map), AAAND it would cost like 8 bucks, so driving makes sense, right? Oi, where do I begin...

(1) Traffic was shockingly bad. I mean, everyone warned me about this, but I didn't understand how bad. Also scary was the realization that I had no cash or I-Pass and thus no way to pay for tolls and the parking meter. After some digging around I discovered $4.50 in quarters in my backpack, but before I could feel any amount of relief about that,

(2) the ramp I needed to get onto was closed and there were no signs to tell me what to do instead of the ramp. This got me panicky so it was a while before I realized I should stop and ask for help. After getting the reroute info from a gas station attendant, I casually asked, "Oh by the way, how long will it take to get downtown?" He stared at me, eyes wide. "In this traffic? It's RUSH HOUR. It'll take AN HOUR." I only had 30 minutes till the meeting started, so I found this rather uncool, but what made it very much uncooler was that

(3) I made some kind of wrong turn right as I pulled into the city. Somehow when I read "Merge onto N Union Ave via the Lake St/200 N exit 51 A," it got all jumbled in my brain and I ended up on Lake St somewhere. Soon I found myself on what looked like the edge of town were it was weird and dark and completely empty. Did I mention the roads are really weird? For some reason, I've never noticed the big flashing yellow lights and 5-way intersections and the fact that everything seems broken-down and twisted, like some haunted nightmare video game. After a several minutes of trying to get back on track by pure determination alone, I stopped to dig around for a map and finally figured out what I had to do to get to the right street. It was a great feeling to have finally made it to my destination until I

(4) realized there was no place to park anywhere near the building. So I kept driving farther and farther away, still not seeing any place to park. Finally when I called out to some guy walking along the street for help, he directed me to a parking garage. Yay -- and look, they actually accept credit cards! I was so excited that I paid it "the credit card way," instead of the normal and much smarter "ticket" way, but I didn't see a problem with this till later. Off I went, parking at the first empty spot I saw before hurrying into the elevator and ending up in some lobby. I approached two workers in the office next to the lobby to ask them a question about how the credit card thing is supposed to work, when they simultaneously yelled at me, "AVIS IS THAT WAY" and pointed to the Avis office behind me. I'm all "Huh?" so they yelled it again, "Avis IS THAT WAY." I found this very, very creepy, and it wasn't till several hours later that I realized the map I was holding had the Avis logo on it. Ah.

(5) Even with maps in hand, I was completely disoriented when I got back on the streets and had to ask for help again. Thankfully some friendly woman pointed me in the right direction: "Just go over the bridge!" It was like arriving at the Promised Land when I finally got into the building, 1 hour late for the meeting. The first thing I noticed when the elevator opened onto the Google floor was that there were dozens of security cameras pointing straight at me. Er, it was probably just 4 cameras, and pointing in different directions, but it's times like this that everything seems worse that it really is. There were also some very snazzy spotlights shining the Google colors along the walls, but at the moment they only served to heighten the creepy effect. After a minute or two, a security guard appears and ushers me in after I claim to be there for the Python meeting. (I later learn he is actually the "front desk.")

I'm brought to this lone computer sitting in the hallway. "Go ahead and print out a nametag for yourself," he says cheerily. In my stressed out state, I must have appeared to be a completely idiotic computer-illiterate person, because he actually walked me through the entire process of the very simple and brilliant Google custom nametag printer.

"Type in your name where it says Name."

Ok.

"Now just type in shy pie where it says Host."

Shy pie? What's shy p—

Oh, ChiPy!!

After that, everything was smooth for a while. Despite being so late, I only missed the first presentation, on Unicode -- something I did want to see, but hey; in the happy yellow GoogleCafeteria, surrounded by a huge crowd of interesting-looking geeky people with beers, I was finally starting to calm down and feel pretty good about myself.

Soon Ian went up and discussed the OLPC effort and how he hoped to organize some Python sprints for Sugar UI development. He then passed the laptop around, much to my glee. It's a very nice, sturdy object that opens in an interesting way once you get past the cute lock system provided by the folded-over antennae parts. I remember thinking two things as I got my hands on it. Firstly: the feeling of balance seemed off, because the flipped-up screen half is thicker and heavier than the keyboard half. Secondly: the plastic shell was EXTREMELY GREASY by the time it was passed to me, even though it had only been touched by maybe 7 people at that point. Ew!

It had quite a novel screen which reminded me of a TI calculator's, only with the ability to light up and display colors. Another observation is that the keyboard is very small, making it basically unusable for adult hands. It was, nevertheless, very fun to poke those soft, gushy green keys and the funny little touchpad made of some hard fibrous-looking material. The UI was intriguing, but kind of too slow and underdeveloped to really experience much of. (Looks like it's possible to get an image of the latest version of the software here).

For the next presentation, Pete Fein demoed Grassy Knoll, his full text search web service. It's a REST interface to PyLucene, which is Java Lucene embedded in cPython -- twice as fast as Lucene and fun to write for, but finicky, hard to build, and bad with threads. Right now Grassy Knoll outputs JSON, but eventually Pete plans to make it language agnostic and give it multi-threaded server capability.

After the meeting I had a good time chatting with Bradley from PSIG about life and love and his personal library of thousands of math books. I also learned that he's an accomplished horn player and he got me all inspired about taking up the trumpet again. Hopefully I will this summer!

(6) Back to my adventure on the streets... it wasn't long before I realized that I had no idea what parking garage I had parked at. Yeah, this is where the ticket would have helped. All I remembered was that it had an Avis office and it was somewhere either near or on Lake St. It was probably a half hour of wandering before I remembered that the first floor of the garage was painted blue and named Paris. I decided to ask some random attendant in some random travel-related building if he knew of a parking garage with a Paris first floor. Amazingly, he actually did know what I was talking about and was able to point me there. It was quite relieving to get back to my car around 11PM -- time for a nice quiet drive home, I thought to myself. It seemed this would be the case, until

(7) a huge truck got in my way right when I needed to change lanes to get onto I-290. I hoped that there'd be another ramp if I kept driving, but when several minutes went by with no sign of such a thing, I attempted to go back downtown and drive back out again. I had to do this twice, wasting at least another hour and bothering yet another gas station attendant in the process.

Well I made it home eventually :D. My little travel experience ended up costing about 4.5 hours and $14 plus gas, which is more than twice the time and money it would have cost to take the train.

It's not every day I can create a 7-part horror story out of my own ineptitude, so I intend to make the most of what I learned. While at the ChiPy meeting, I had assured a couple different people that "from now on I'm taking the train." But as I drove home, I decided that the worst thing I could do now was to give up like that. I've always tended to dislike and avoid doing the things I'm naturally bad at, but I'm beginning to see this as a big flaw. Maybe I do lack a sense of direction, maybe I am terrible at reading maps, and maybe I always get massively lost when I rely on my instincts while traversing new streets, but that's not what I want for myself and I think I can change it. So, I'll definitely be driving there again, and I'm going to keep at it until I become good at all these things (or until I get lost forever, or get myself killed trying). I'll use the train if we're talking rush hour though :)

Sidenote: I talked to so many strangers that day (some of whom I actually didn't mention because this entry was getting so long), and nearly every one of them seemed to overflow with altruism in the ways they helped me. Chicagoans have changed my view of humanity as a whole. I wish I could have stopped with some of those people to exchange life stories.

Someday I hope to find that I've become the sharply-dressed, smart-looking businesswoman striding down the city streets knowing exactly where she's going; the one to whom hopelessly lost, out-of-breath youngsters come with wrinkled Google and Avis maps in hand. Till then, Chicago pwnz me. <3

PSIG 101 | DDHidLib

Sat, 03 Feb 2007 13:09:35 -0600

(What is PSIG? | PSIG 101 announcement)

I'm going to start taking notes at these programmer meetings I attend; mostly for my own benefit, but also because it would be a terrible shame for all of this to go unrecorded :).

Books, advice, ideas

Programming Special Interest Group

Hacking Video Game Consoles
Oh cool, there's a PSP SDK
"If you want to know how it feels to start your own record label, pile up a big bunch of money in your backyard and burn it."
Step into XCode
How to Make Yourself Happy and Remarkably Less Disturbable
Extreme Programming Explained 2nd Ed.
"Do not work in the same department as your spouse." -- lol
I demo my dinky little Cocoa app I've been writing :D. When I lament about the documentation being too sparse, they point me to cocoadev.com and suggest that I check out Apple's sample code.
I also share about my journey through the wonderful world of refactoring.
"Tell your manager you're refactoring, not rewriting."
Rails E-Commerce
I chat with some people about how I was originally going into graphic design (music education before that, and fine arts before that). "Oh, you'll definitely make more money with comp sci," they say. "You make a ton if you're a good programmer, but still a lot if you're a really bad one." Someone pipes up: "Wait, are you sure you make more as a good programmer? You'd probably make less money in most cases." We share a melancholy sigh and discuss manager ignorance.
Tom tells me the secret to cheating in Wack-a-Mole, "handy for when you're playing for money." Basically, hit the things sideways to make them stick.
Bradley tells me the secret to calculus; something about there being really only two basic concepts you need to understand.
He also tells me his approach to learning human languages: get a bunch of books, then get a native speaker. Where to find native speakers? "I just ask around. It helps that I work for a big company." At some point in the evening, it occurs to me that being a both a mathematician and a polyglot has got to have some kind of uber-positive effect on one's programming skills. I'm sure his being a DDR master helps as well xD
At some other point in the evening, it occurs to me that this was the first time I'd ever seen Wolf without a tie on. Lol! He encourages me to look into Aaron Hillegass' Cocoa book. Looks like it's actually available at my library :)

Presentation: DDHidLib

Dave began with a quick pictorial history of human interface devices. The hilarious thing about this group is that people actually remember the punch card reader and the teletype machine; someone even knew which model of teletype it was o___O.

I was especially interested in the video on Multi-Touch Interaction.

On to the main topic at hand: USB HID specifications include the HID device class (specifies how data should be extracted) and the HID usage tables (defines constants to be interpreted by the app). The specs can be downloaded here.

Apple's I/O kit has support for HID: IOHIDLib.

One of Apple's developer tools, IORegistryExplorer, provides a database of all devices on your system.

Accessing devices:

Find the object that represents the device in the I/O registry
Create device interface
Open connection to device
Communicate with device using functions provided by HID manager

Components of a device (every button, etc.) are called elements. Each element has unique number called a cookie, used to get status for the element. Cookies are static across sessions.

Queues for asynchronous notification:

Create queue
Add element cookies to queue
Add queue to run loop
Start queue

At this point, Dave gives us a detailed demo on IOHIDLib, scaring us with loads and loads of hard-to-understand code (scared me, anyway).

Then he whips out DDHidLib, his brilliant Obj-C wrapper around IOHIDLib. Why an Obj-C wrapper? Because of easier resource management, modern error handling, KVC/KVO (cocoa binding), and it makes common tasks easier. DDHidLib includes these classes: DDHidQueue and DDHidDevice<|---DDHidMouse

He also provides two very interesting utilities: HID Device Browser and HID Device Test. The device browser has this Event Watcher feature which we discovered can log keystrokes even while you're off typing in your OS X account password.

Dave hooked up various HIDs during his demo, like a Logitech Precision Gamepad and an N64 controller. He also passed around a variety of ancient game controllers -- you can get these things from Happ Controls. He concluded by playing the Atari 2600 game, Adventure, up on the big screen. All I can say is... wow :). We then discussed how somebody needs to make a repository for all these useful Cocoa tools, because Sourceforge doesn't accept everything.

Alive

Mon, 22 Jan 2007 12:25:50 -0600

Hello all! My crushed soul and I have nothing profound to announce at the moment. I am sorry, especially to those of you who have been waiting so long for my annual life-changes post. Rest assured that there is actually a lot going on in my life. The only reason why I haven't said anything is that it would take more emotional energy than I have left trying to disentangle and abridge it all into one coherent piece of text ^__^;;. For now I will give you this: that most of my questions remain unanswered.

Thoughts from the last couple months:

Finally Core2Duo MacBooks! Mine (2Ghz white) arrived the first of December. Bliss!
Java, Obj-C, Ruby, my insanely wonderful developer friends... I am so in debt to you.
At some point I turned 20. The day began nightmarishly, but was later made exponentially better by some crazy people who shocked me by remembering/figuring out my birthday... <3
I made it out of biology class alive and even got some nice character designs out of the taxonomy study ;D
Went up to Chicago several times for museums and happiness. Unfortunately the Sears Tower security guards did not let us use the stairs, even though I begged nicely.
As Candid HQ is no more, Candid Manga is also no more :-(. Ohwell.
I have a new string quartet! We play Final Fantasy songs and themes from Pride & Prejudice! Yayayay
Gasp, I joined one of my church's young adult groups; what could this mean?
Working out is like the only thing I've done on a consistent basis. All of December's weather was perfect for jogging, even Christmas Eve. I'd take this over a white Christmas any year!
Oh hey, I still love my job and I've been there almost three years now, craziness.
A whole bullet point to say -- Tony rocks because he knows about all my problems, yet he still talks to me :-). I don't know why. It's a very relieving thing to have friends like that.
Another bullet point to say -- Wolf rocks because he totally exudes magic and happiness and good taste and for some reason doesn't mind hanging out with plain old unmagical me. Cocoa rocks, PSIG rocks, red/green/gray walls? IT ROCKS!
Weien has demonstrated that he is completely insane -- so now I'm pressuring him to put out a whole CD and start a Random Weien Podcast Show ;D. He's already produced the first clip of Random Weien Quotes: AUDIO EDITION! MP3 here.

A few doodles from last semester; click for larger versions.

Sigh...

Originally I was going to have her playing the harpsichord, but that just seemed stale to the point of being sickening!

For some reason, Weien is really weirded out by this character XD

I hate this pic; why did I draw it?? lol

I start feeling guilty when everything I draw is young, relatively good-looking female cartoon characters. So to atone for my sins I attempted to paint a mildly realistic lady. I even did it in a mildly high resolution :D. THANK YOU 1GB OF RAM IN MY MACBOOK. Photoshop running over Rosetta is surprisingly usable.

Here's a creepy close-up! Original res of this thing was 1500 x 1290 px.

That's it for now. First day of school today!! This is going to be the best semester ever, I can just feel it.

EXH. 1

Tue, 05 Dec 2006 14:47:07 -0600

Wandering...

Tue, 05 Sep 2006 14:10:12 -0600

Quotes from my lit professor:

"Everyone is given something she can share with the world. Sometimes it takes half a life to figure out what that is."
(On why cut flowers are expensive) "Anything that dies in a day but is this beautiful is very precious. You only have a day to realize how beautiful it is."

That made me think about how we should act around people we'll only see once.

Quotes from my CIS professor:

"But you know the teacher's credo—if none of you get this, I have to kill myself at the end of the semester. It's the way of the teacher."
"Some teachers go crazy when you use parentheses on an expression that's going to be evaluated first anyway. I don't care. It's like wearing a belt, and suspenders too!"

(On somebody turning in homework assignments on 5 x 8" sheets of paper) "Hey, could you make these smaller? Make em toilet paper sized and then I'd have some use for em."

He had some serious things to say as well, such as the "key to succeeding in IT":

Be inch deep, mile wide (know a little bit of everything)
Also, be inch wide, mile deep (have a lot of expertise in a few areas)

After the last class of the semester, I went up and asked him for some "general college advice." The way he answered me, you'd think I had asked, "Please tell me who I am and what I should do to end up with the ideal job." Good stuff ^___^. Here's some of it:

Take the Meyers-Briggs test. Learn about the different types of personalities, not just to find out about yourself, but to figure out how to adapt your personality to make others feel more comfortable around you. (Something about doing this so consciously seems freakishly shrewd, almost negatively so. Good to consider nonetheless.)
Get your bachelors in business and your masters in computer science. (I found this advice rather disturbing as I've never thought of going into business, but I'm already kinda checking it out by enrolling in an economics class this fall. Looking for more opinions on this ^^;;.)
Before you actually need a job, do 10 tech job interviews in the area and assess your strengths and weaknesses based on the feedback you get. (Wow, almost like applying TDD to life.)
Don't keep wandering around. "But lucky for you," he said, "You've been wandering in the right direction." (Lol?)
All resumes are the same, listing all kinds of skills and technologies, etc. What really matters is if they like you. They will like you if you remind them of themselves. (Again, freakish. But probably true.)

Doodles:

More Ruby-chan

A short fiction we read in class

Short fiction by James Joyce

Hullo, good sir. How may I be of assistance?

This fall I'm taking classes full-time while working part-time. So far it seems like I'll be ok, though that'll probably change as the semester progresses, heh. Biology will be the toughest; I'm also taking Macroeconomics, Java 2, and Kickboxing 2 (:D). I'm pretty excited about Java because we'll be focusing on web apps. And thankfully, my professor is really nice and it doesn't seem like she'll have a problem with the fact that I kinda skipped Java 1. As for whether or not I'll make it despite that fact, I've yet to find out x.x.

Postponage of certain projects thus ensues! If you want me to do anything for you this fall, ask me NOW XD!!

Getting Real, Barcamp, etc.

Sat, 19 Aug 2006 12:09:43 -0600

But first some stuff I've been working on -

Matt & Mary Kay's wedding site: A fun project involving the lovely Radiant CMS powered by Rails, some PHP, a good bit of JavaScript and just enough Flash wrapped up in an rather Web 2.0-inspired design—it's monstrous :). I'll have to say it was a great honor to be asked to do this and I had a good time with it. I learned a lot in those last few minutes of Opera-debugging and figuring out how to get rid of the extra scroll from the reflection image. Radiant was very smooth to work with and I look forward to using it for other things in the future.

MovableType theme: A simple blog layout. Somehow it won in one of the categories at the style contest put on last month by Six Apart, Adobe, & West Civ @___@;;. Which is cool because finally, I feel deserving of a Mac and now I have the funds to get one :D

Northwoods Conference Center: This I did a while ago for work. It was probably the most exciting IBLP project I've done so far, as I was the main designer/coder on it and I got to try some new things like drawing the icons for the Directions/Weather buttons and creating a floor plan image with Xara. Lots of great photos to work with too! Made me wish I was there again.

Onward -

Basically, the Getting Real Workshop is a 1-day seminar about web development put on by a small and successful Chicago-based company closely tied in with the Rails framework. As a student, it was a pretty awesome opportunity to be sent there by IBLP considering the credentials, experience, position, etc. of the average type of person who's able to attend these kinda things ^^;;.

Actually, learning the Getting Real principles really made me appreciate my own little web team more. We're so accustomed to few laborers each doing a variety of different tasks to fill in the holes and we're always having to deal with limited time and meager funds. This kind of small and flexible team is preferable to 37signals; in fact, they recommended putting no more than three people on version one of any software project. Here are a few more of their ideas:

Focus on now: Don't make long-term plans, staff up for an uncertain future, or worry about scaling software ahead of time. Lower the cost of change by making many small decisions as you go, as those don't end in huge mistakes. Figure out what you're going to do along the way instead of using spec docs, because "the future should drive the future."
Less mass: Embrace constraints like not enough people, time, and money. Make less code, because less is easier to write and maintain. Include less features, as most of what people ask for doesn't actually matter—say no to a new feature request by default and let it marinate for a while before it turns into a maybe or a yes. Make opinionated software—provide less user preferences because the developer should be making all the tough decisions, not the users.

Design first: Let the interface drive the product. Design exactly what the customer should see, be in front of it as much as possible, and use it while you're building it.

Have a flexible and happy team: Hire generalists, not specialists who can't understand/appreciate everyone else's work. Hire happy people rather than disgruntled gurus, and maintain a happy environment—you want happiness-driven development.

The female/male ratio wasn't as bad here (15% female), probably because it was for designers and business types as much as it was for programmers.

At Barcamp Chicago I saw only about 5 women in the ~100 people attending, and I think with the exception of one or two, they were all wives/gf's tagging along. Honestly, geeky impromptu "unconferences" are bad places to take your girlfriend XD;.

But, I was fascinated by the experience. The tech events IBLP sends me to are all held at big, clean university meeting rooms, classy convention centers, or fancy hotels. As for this... this was definitely the first time in my life I'd been somewhere with KEGS of free beer—lol—in a room that was kind of the attic of a quirky little downtown art gallery, fans blasting for the lack of AC (this was during that 95+ degree weekend), walls taped up with paper for the free-for-all presentation schedule and for people to write out their ideas. Something about the whole thing seemed so artsy to me that I couldn't help but love it.

Oh, and JIMBO WALES was there! Very pleasant person in real life; pretty much like how I imagined he'd be :D. He talked a bit about Wikipedia and went in detail about his new project, Campaigns Wikia. Basically "participatory politics," encouraging people to get involved in intelligently and non-biasedly discussing political sides and issues. It was inspiring to realize that he was achieving a certain level of world peace in his work, yet without compromise—he'd rather be banned in China than allow censorship of the Chinese Wikipedia!

Another presentation I found encouraging was Sean Johnson on "How to Not Burn Your Business to the Ground." Here are my notes:

1. Stop stalling.
Nine out of ten businesses fail, but that just means you gotta start ten businesses.
Don't fear failure—it's part of the steps to success.
With Web 2.0, having only a small team is no longer a problem.
Everything is not going to be there when you start.
"How hard is it to learn to ride a bike if you don't have a bicycle? How hard is it to learn how to start a business… without starting a business?"

2. Have a mission.

You're idea should be something important to you as a person; something that goes beyond you and the business.
Business is the best opportunity to practice what you believe. It's a way to express yourself.

3. The idea's not as important as you think.

It's ok to have a mediocre idea as long as you execute it well. Focus on building your skills.

4. Sell, sell, sell

Sales are as much an art as marketing.
Don't be too proud to pound on doors. Call people, get instant feedback, work on your pitch.

5. Focus on your cash flow.

Establish credit with vendors and suppliers. Treat them well.
Have a good relationship with your banker and get advice from him/her.
Invoice immediately to keep the money coming in.
Put together a cash budget. Make sure you know where you stand by keeping your books.
Get help with taxes.
Make connections.

6. Find a great team.

Be picky about who you work with.
Go do things you're insanely passionate about, and you'll attract the kind of people who will be able to help you.
Be a giver and don't worry about what you'll get back.
Search for passionate people to work with you, not just talented ones.
Spend time with people who support you and build you up—you need the energy.

My mind was so full of all the ideas and inspiration and wants and dreams from these events that for a couple days I couldn't concentrate on anything in my normal life, and even now I'm a bit restless. I have no idea how this is all going to manifest itself, but I hope I'll be able to keep everything in perspective ^^;;. This adventure is meaningless unless it's what God has for me and I have yet to figure out if that is so.

Doodle: