$ rvm use 1.8.7 $ ruby -e'puts [1, "a"].to_s' 1a $ rvm use 1.9 $ ruby -e'puts [1, "a"].to_s' [1, "a"]
I've been working on converting my client's Rails App to Ruby 1.9.
It's been fairly painless, but there have been a few stumbling blocks. One has been the use of arrays within string interpolations, and the difference in the result
Prior to Ruby 1.9 Array#to_s was a synonym for Array.join which resulted in the concatenation of the results of sending to_s to each element. In Ruby 1.9 Array#to_s is the same as Array#inspect.
This has had a tendency to produce subtle problems which are at time hard to track down. Once they are found, the solution is to do something like changing:
"Whatever #{some_array}"
to:
"Whatever #{some_array.join}"
I'm speaking about the "RiCal experience" tomorrow evening 20 October 2009, at the October meeting of the Raleigh Ruby Brigade. As usual the meeting is at Red Hat HQ in Raleigh and starts at 7:00 pm.
I plan to talk about calendars, time, time zones, camels, icalendar, Ruby implementation of complex "stuff", among other things.
I hope to see you there!
There's a bit of a buzz on the interwebs, that Microsoft's project to compete with the iPhone is having some problems.
What I find ironic is that they decided to call this project "Pink". Apple once had a project with the same name, which was to be the 'new' operating system for the Macintosh, as a replacement for System 7. Pink was to be an operating system built around an application framework which was to provide the API. This was a popular 'strategic' idea in those days, Apple, IBM and, yes even Microsoft were pursuing it.
Apple's Pink attempted to take the ideas from MacApp which had just made the transition from Object Pascal to C++, and grow them into an operating system. Larry Tesler had advocated this and John Sculley, then Apple's presidency during the "inter-regnum" period, had sunk lots of money into the project which was headquartered in the original building where the Macintosh had been developed, when it was the lair of the "Dread Pirate" Job's merry band. The project had gotten bogged down, and Sculley was on the verge of killing it, unless other 'investors' could be found. Since IBM was enamored with such things back then, a task-force was dispatched to Cupertino to look at Pink. I was tapped for the task-force because of my expertise in Object Oriented programming and visibility due to my connections with VisualAge and Smalltalk, Despite whatever technical misgivings which might have resulted, in other words they didn't listen to me, IBM bought in. The result was an alliance which formed two jointly companies which were jointly owned by IBM and Apple, Kaleida which focused on multi-media, and Taligent led by IBM Executive Joe Gugliemi, where Pink died a slow death. The longest term impact of the alliance was that it got Apple to agree to switching from the Motorola 68K family of microprocessors, which had been used in Macs until then, to the IBM PowerPC. But, since Motorola was a large IBM customer, IBM licensed the PowerPC to them, so that most Macs used IBM architected chips actually produced by Motorola until the "Dread" Pirate came back and eventually switched to using Intel chips.
Of course Microsoft's "Pink" has no relation to Apple's other than the name, but I can't help but finding this all ironic.
I admit it, I'm a much better programmer than graphics designer.
But getting the overall UI structure and flow of an application "right" requires a certain amount of "right brain" activity. And one of the best approaches is to create a "wire-frame" story board.
I've worked in situations where the "chief designer" would hand out web pages carefully crafted in PhotoShop, and ask for "pixel-perfect" renditions. UI discussions would be held using these images.
The problem is that this can lead to quite a bit of yak shaving, particularly of the bikeshedding variety.
I'm a big movie fan, in my dreams I've wanted to be a movie director if I couldn't be a programmer, or a Rock and Roll star, and among my heroes I count Hitchcock, Scorsese, Peter Jackson, and many others. I think that designing user interfaces is quite similar to designing movies. As someone who has watched a lot of that supplemental material on DVDs of recent an not so recent movies, I know how often directors use story boards to work out the flow and pace of a movie.
Storyboards are a rapid prototyping technique. It's a lot cheaper to work with easily replaceable "low-fidelity" artists drawings than to shoot the actual movie. Ideas can be discussed with little regard to the cost of the story-boarding.
User Interface design can, and should make use of a similar technique often called wire-framing, in which the sequence of presentations, the "scenes" if you will, which will take the form of things like web pages and dialog boxes, are sketched out and annotated as to what actions cause which transitions.
A few weeks ago I became aware of a product called Balsamiq Mockups which does a nice job of wire-framing.
Mockups exists both as an online web application and as an Adobe Air desktop version.
One way to think of Mockups is as a specialized version of PowerPoint or Keynote, although that's missing the point a bit. The similarity is that you can create storyboard pages, which are similar to pages in a presentation. There are some differences that make it a specialized wire-framing tool. First Mockups comes with lots of built-in user-interface components for web applications, desktop applications, and even iPhone apps. Second, rather than presenting the pages sequentially, you set up transitions between the pages based on user interactions, like clicking on buttons.
I find the cartoonish feeling of the pages quite nice. They get the idea across without inviting unnecessary quibbling about pixel-perfection. This is a tool for getting the big ideas down, after that a competent web-designer can polish things.
I've been looking for something like this for a while. I know quite a few Rails developers and designers who are pretty pumped up about this tool. It's well worth having a look.




