github:TCAsyncHashProtocol. I like constructing simple network protocols from plist/json-safe dicts, and
transmit them over the wire as json. Easy to prototype with, easy to debug.
Give TCAHP an AsyncSocket, and this is what it’ll do for you, plus
support for request-response, and arbitrary NSData attachments.
It is an embarrassment and almost an insult that my example project is a massive
200 lines. I hope to be able to reduce the verbosity and boilerplate clutter of
using TCAHP without making it heavy-weight. At the very least, I recommend that you
use SPLowVerbosity.
An example of using TCAHP to send a request to update the server’s MOTD:
[_proto requestHash:$dict(
@"command", @"setMessage", // the command is 'setMessage'
@"contents", msg // Send 'msg' as the new message to set.
) response:^(NSDictionary *response) {
// The server has replied.
if([[response objectForKey:@"success"] boolValue])
NSLog(@"Successfully updated message!");
else
NSLog(@"Couldn't set message, because %@", [response objectForKey:@"reason"]);
}];
(Note the latest piece of magic that I added, where the selector of the delegate
method is created based on the value of the key ‘command’ in the message. I quite
like it.)
As you can see, the resulting protocol is very weakly typed. In theory,
this means you will be making typos and not understanding why the hell
your network seems broken; in reality, I’ve never had that problem.
If you are going to end up with a crappy to mediocre blender anyway, then why bother spending more or availing yourself of the advice and service of a specialty retailer? Reducing the overall quality of products thus destroys a key competitive advantage of Walmart’s smaller rivals.
By categorizing our cognitive flaws, documenting not just our errors but also their embarrassing predictability, he has revealed the hollowness of a very ancient aspiration. Knowing thyself is not enough. Not even close.
—Is Self-Knowledge Overrated? at the new yorker. not very surprising, but sort of confirms that everyone’s an idiot, not just me :P
I’ve been trying to build a wearable computer since forever, but I sort of got stuck because there aren’t (or I can’t find) any good HMDs (head-mounted displays) that don’t cover your entire field of vision (covering just one eye is fine, but being see-through would be the best, of course). I’ve had a Google Alert on the AirScouter for a year or so, and it seems they’re finally releasing them in some sort of product. I want one *so badly*, but they’re targeted at industrial application and priced thereafter, at $5200 :( I may be a huge frickin’ nerd, but I can’t really justify spending that kind of money on yet another hobby project…
Your brain begins to know that you are “enjoying” yourself, even if you hate this insipid thing. In spite of a love-shaped hole in the center of your spirit re: this electronic monster, you will not turn away. […] What gruesome psychomathematiconomist devised this heart-labyrinth?
—insertcredit (4 chapters) reminds me why I hate “social games” more than TV. Memetic T-Viruses, turning human beings into zombies.
People are sort of tired of me complaining; I’ve been saying I hate Xcode 4 since the first time I used it. “You’ll get used to it!”, “Learn Behaviors and everything will be well”, “Embrace the new UI model”, they said. I’ve been using it exclusively for several months now, trying to explore and use every feature of it; make sure to try to find a way in which I can confidently work in it. I failed. Launching Xcode 3 is a fresh breeze every time.
Just a note up front: I’m not saying Xcode 4 sucks. It is light-years ahead of Xcode 3 in many ways, particularly autocompletion and the IDEs idea of what the code contains (inline warnings and errors as you type is wonderful). This is just about the way it manages windows and tabs. And even then, maybe there is some mode or usage pattern that I don’t know about and would fit me better — if so, please shout in the comment or to my twitter!
Spatial Thinking
Xcode 4 works fantastically for a lot of people. How am I special? Why do I have to try to be so different all the time? Apart from just generally being an annoying sod, I imagine myself being a spatial thinker; I like to think in terms of spatially organizing whatever concepts I’m working with. I loved Classic Mac OS’ spatial Finder, where windows always appeared at the same location were it did last time, and there was a one-to-one mapping between folder and window.
The same goes for me and source code files. I used to work in Condensed Mode in XC 3; a single thin window with a project file listing, all source windows separate, and then dedicated slots for Build and Run windows on a separate screen (together with a terminal or two). I would work with a dozen source files at the same time, placing them around the screen. When I needed one I used recently, I would know where it would be spatially, and could just click a tiny corner or edge peeking out beneath whatever I was working on(1). This way I could also layer other applications in between windows, and have a rather deep pile of things I’m working on. It’s the classic desktop metaphor, and the main argument against Multiple Document Interfaces (MDIs) that we Mac nerds would ridicule Windows users for having to use every day(2).
You might be able to imagine why XC4 would then be a problem for me, with everything in a single window, everything appearing in the exact same location on screen as you instead switch between modes of operation in one screen area, rather than switching between locations and zones on the screen. It was — and is — a complete disaster for my productivity. I spend so much time switching between contexts nowadays, trying to reorient myself.
Staying In the Past?
Trying to work in an Xcode 3 manner in Xcode 4 is worse than just trying to adapt.
One of the best features of Xcode 3 is that it would remember all the open windows of a project when you closed it. In Xcode 4, closing a window is terminating it and its layout forever, and the last window you happen to close will become the main project window. Oh, you accidentally closed the window *you* consider the main window first, and then you had a reference header in a window configured for reading reference headers still open on another screen? Well, I guess that’s your main window now, and you’ll just need to reconfigure it as your main. (Update: There is in fact “Close project” in File which will remember all the windows. This doesn’t help in the situation where you close one window forgetting that you had two open though, which is quite common.)
Want a separate window for your build progress so you can keep track of what’s actually happening in your builds? That’s in a sidebar now, and if you actually want build details, you have to manually choose the latest build results in *another* sidebar, and then switch back to the first sidebar.
Want a separate window for your console output? Hey, there’s this hack where you can name a tab “console”, bring up the debug lower-pane, set that pane to console output, make the pane fill the window, turn off the left-and-right sidebars, drag the tab out to its on window. Remember to put it back in its tab before closing the window though, or it’ll become your project!
OK, this is not working.
Trying To Adapt
The way I work now is to have everything I used to have in separate windows, in separate tabs; and have Behaviors set to switch to them at appropriate times. I have one Build tab and one Debug tab, set up in a pretty nice way. I mean, this is okay, I can work this way. However, I do lose my focus a lot of the time, and I get lost trying to context switch between tabs. And I need to set this up for every project I start working on. And I can’t really use my secondary monitor for the things I like and used to do. And it’s just a pain.
Fixing Shit
Why alienate all spatial thinking developers from the Mac and iOS developer communies? I can absolutely imagine Condensed Mode working in Xcode 4. The concept of optional sidebars everywhere could still work. I’d just want to pull out the Project navigator sidebar into its own window which becomes the ‘project main’ (closing it closes all related windows); allow some of the more awkward sidebars like the Object Library to be a panel like in IB; have dedicated Build and Console windows; and have the IDE try to suggest the “one file per window” concept (but possibly allow browsing different files within one window is the user really wants to). I mocked up a horrible concept in Acorn, for your viewing pleasure:
This would make me very, very happy. Sure, it’d be half as “fast” as Xcode 3, it’d still forget how to autocomplete once a day, and crash pretty much every minute, but at least I could work with it.
(2): It’s worth to note that the prevalence of MDI on Windows is a symptom of not having a real application metaphor, and thus having to group all windows in a meta-window in order to regain an actual application context. Mac OS never had this problem, as an application is the primary unit of operation and the main metaphor there, and not the window.
Software today is not engineering. Building the Empire State Building with three thousand people in a year is engineering. Programming today is more like the Egyptians piling blocks on each other and hoping it doesn’t fall over.
Every day, I spend so much time building almost trivial functionality in thousands of lines of code, with brittle APIs that hook into other people’s brittle APIs, because that’s the code base we have, and every other code base seems to be roughly looks like that, too. I spend my weekends learning about C and C-like systems because that’s what I know; I don’t go around learning about compiler-compilers, I’m stuck in what my brain already “knows” that programming is like. I didn’t know twenty minutes ago that you could write a complete compositing 2d graphics environment with 26 compositing method in under 400 lines of code.
My very good friend Martin once told me how different it is to even think in Japanese and Chinese, how those thoughts can’t even be translated into English. Kay’s realization that the same holds true for programming is profound in a way I didn’t realize before.
Back in uni I unwittingly participated in an experiment. One of the teachers arranged two lab sessions with the exact same content, and put Java programmers in one and C++ programmers in the other. We were given some UML and were asked to implement it. The real task had actually been to see how fast we could build it (but were of course not told in beforehand that we were being timed); and while I was fastest in my group and it felt like the C++ came out pretty naturally, the result showed that it took me twice as long to write the code than it took on average for the Java coders.
Ever since then, I’ve been worried that even though I feel like I’m really fast with my tools, those very tools are holding me back, and I’m *really* just a tenth as fast as I could have been with another set of tools. I love ObjC, but it’s still C, it still got non-object types, there’s still manual memory management, everything is viciously verbose, and meta programming is still more limited than in some non-C languages.
Design patterns in general are a recipe for failure, as they are indicators of flaws in your language. A design pattern inherently violates DRY as it means that many people have written something very similar, but it has not been abstracted out.
—Matthew Maurer in a thread by Andy Matuschak. Whole comment thread is interesting.
