Summary: Retrospective Thoughts on BitC

May 21, 2013 § Leave a Comment

In my opinion, BitC is the most innovative take on systems programming we’ve seen since the invention of C.  While sad that it failed, I am deeply impressed by the thoughtful post-mortem by Jonathan S. Shapiro.   Here are links to the various threads of his analysis (and the equally thoughtful responses):

RIBS: Marrying the REST and MVC Design Patterns

September 26, 2011 § 1 Comment

[Diagram updated on 10/27. Thanks to @frozencanuck for his feedback.]

The RIBS diagram is my third attempt to extend the wildly-succesful Model–View–Controller design pattern to encompass first the The DCI Architecture and now the REST architectural style.  This time, I started by reverse-engineered the design principles behind the Ki Statechart Framework, particularly their use of statecharts as coordinating controllers.

I also have a clearer picture of what I am doing:  trying to identify a general design pattern for computational systems.

Here’s what it looks like so far:

Resource • Interface • Behavior • State

  1. The purpose of a System is to manage a Resource
  2. A System contains a Resource, one or more States and their Behaviors, an Interface for each State, plus relationships with zero or more Peers.
  3. An Interface (which could also be a System of its own) consists of active Actions and passive Presentations available to an external Client.
  4. When a Client invokes an Action, the System routes it to the appropriate Behavior for the current State (the routing is necessary if there are multiple concurrent states, otherwise it can be elided).
  5. A Behavior can in general a) adapt a Resource, b) interact with a Peer, and  c) initiate additional Behavior
  6. Resources present to an Interface and adapt to a Behavior
Importantly, this is a conceptual document, not a software architecture.  To be sure, it is intended to map easily onto traditional MVC objects:
  • Views are Interfaces
  • Models are Resources that can adapt and present themselves
  • Controllers manage State, routing, and connections with Peers
This implies that traditional MVC concepts are actually aggregates of other, more primitive concepts.  Indeed, advanced programmers often add presenters, adapters, routers, state machines, and behavioral strategies in order to overcome the brittleness of pure MVC.
However, the RIBS pattern is actually more general than that, because it applies even below the object level:
  • Views can be systems, whose Resource is a drawing context and Behavior is hit detection
  • A Model object could itself be a system, with a database row as its Resource and business logic as its Behavior
You might say that one system’s Interface is another system’s Resource.  In fact, RIBS can also be used at a much higher level to describe RESTful web services:
  • Hypertext is an Interface  (HTML) which uses Routes (URLs) to embed State
  • Behavior is driven by a small set of Actions (HTTP verbs) against a specific Resource
In short, a RESTful system pulls the State into the Interface enabling you to work directly with Resources.
At least, thats the theory, as best I currently understand it and can articulate it. What do you think? Can you do better?

SIDA: Moving Object-Oriented Design beyond Model-View-Controller

September 16, 2011 § 2 Comments

[Update: this post has been obsoleted by RIBS: Marrying the REST and MVC Design Patterns « iHack, therefore iBlog]

SIDA stands for “State • Interface • Data • Algorithm“, and is a refinement of my earlier “DIDA” model (where the “D” stood for Design).  DIDA in turn was an expansion of the well-known Model–View–Controller design pattern based on insights from the Data-Context-Interactions architecture.

State • Interface • Data • AlgorithmThe key premise of SIDA is that there are four primary artifacts that need to be designed, from the most important on down:

  1. Concrete States
  2. Clear Interfaces
  3. Consistent Data
  4. Concise Algorithms
These in turn are related in a particular system via the:
  1. Presentation of Views
  2. Controlling of Actions
  3. Binding of Roles

as shown in the accompanying diagram.

In a simple system, the state is implicit and the relations are absorbed into one of the artifacts, reducing SIDA to the traditional View, Model, and Controller, respectively.  For more complex systems, however, it may make sense to design explicit objects for each relation, e.g., traits for roles, presenters for views, and strategies for actions.

In addition, SIDA is intended as a general architecture, describing the internal structure of everything from databases to web services to GUI applications.  An interface as defined from inside the system may appear as data or an algorithm from outside the system.

The most interesting (and perhaps unusual) aspect of this diagram is how it makes state a central features, something developers never use. If state really is so central to the design process, perhaps it deserves explicit language support, as provided by UnrealScript or typestates (as in Rust).

This is all still merely a hypothesis on my part, as I haven’t actually put any of this into practice yet.  Anyone with more experience care to comment?

DIDA: Reinterpreting MVC object modelling in light of DCI

September 15, 2011 § 2 Comments

[UPDATE: This post has been obsoleted by SIDA: Moving Object-Oriented Design beyond Model-View-Controller]

I recently read about The DCI Architecture: A New Vision of Object-Oriented Programming, a successor/complement to the original Model–View–Controller design pattern, by one of the original authors.  The DCI stand for:

  • Data
  • Context
  • Interaction
I was both impressed and confused.  Impressed because I’ve been thinking for a while that MVC wasn’t quite sufficient, and this seems like a big leap forward.  Confused, because most of their discussion revolved around roles (typically implemented as traits) and algorithms, so I couldn’t quite figure out where exactly Context and Interactions fit in — much less how they related to MVC objects.
Design Interface Data AlgorithmTo help me sort it all out in my head, I developed a comprehensive picture I call DIDA, which attempts to incorporate both MVC and DCI in a single unified design pattern. DIDA stands for:
  • Design
  • Interface
  • Data
  • Algorithms
In a sense, it uses the critique from DCI to tease apart to the components of MVC.   In particular, traditional MVC tends to combine the roles and data into model classes, the presentation and interface into a view hierarchy, and all the actions and algorithms into a single controller.  The key insight of DCI (as best I understand it) is that  roles should be kept distinct from the “mostly dumb” data, and only bound in the context of a particular algorithm, which should be clearly spelled out in its own software construct. I used the same logic to similarly extract the Presenter Pattern from views and to separate controllers from algorithms.
The basic idea is that the Interface, Data and Algorithms are three primary nouns you need to Design as part of an application (roughly in that order).  Those in turn determine the roles, presentation, and actions necessary to wire everything together.  Depending on the use cases, it may make sense to implement everything as traditional MVC objects, but it might be wiser to use, e.g., traits, presenters, and strategies to enable weaker coupling.
As far as I can tell, this approach captures the key benefits of DCI, but is much easier to understand and apply. Of course, I could easily be overlooking something. Please let me know what you think.

What Makes Programming Languages Successful?

July 1, 2010 § Leave a Comment

Following up on my (subjective) list of what I like about Ruby, here’s a (relatively objective) list based on articles about what makes programming languages successful. « Read the rest of this entry »

What I love most about Ruby

June 29, 2010 § 1 Comment

I have some friends (Hi Dustin) that are serious language geeks, whom I often get into debates with. One of my common refrains is “to do it the Ruby way”, because (while Ruby has its warts) it does so many little things beautifully well. So, as future ammunition, I figured I should try to collect links to my favorite Ruby features (much as many others have already done before me).

« Read the rest of this entry »

Migrating from Steel.app to 1Password

August 4, 2009 § 2 Comments

For years I’ve used Steel.app from Gravity to manage all my passwords. Alas, as sometimes happens, they’ve decided to discontinue that product. :-(

To their credit, they’re offering a 20% discount on the User-Friendy-but-Ugly-Safari-Hack 1Password from Agile Web Solutions. Unfortunately, since Steel.app is freeform and 1Password is structured, they say you have to cut and paste everything manually.

Not true! If you (like me, and I suspect many others) used a consistent column scheme for storying your passwords, it is actually quite easy to migrate your data automatically. Find out how below…

Update: you can use a similar process to import from Steel.app into PasswordWallet, a simpler but less intrusive alternative to 1Password.

« Read the rest of this entry »

Bonjour-enabled iPhone Remote.app wins rave reviews

July 14, 2008 § 1 Comment

The iPhone Remote control for iTunes and Apple TV is taking the world by storm — thanks largely to the power of Bonjour. Hat tip to S.C. for the links.
I see you, iPhone Remote

A lot of people are busily activating iPhone 3Gs and upgrading old iPhones to the new 2.0 software. And they’re downloading apps on the app store, most particularly Apple’s free iTunes Remote utility.

One GeekDad’s Review of iPhone 2.0

Perhaps the coolest little bauble in the free apps, Remote turns your iPhone into an Apple remote, so you can use it to control iTunes on your computer, or your AppleTV, when you’re on your local wi-fi network.

iPhone 2.0 and the iTunes Remote

One of the most surprising and enjoyable elements is the iTunes Remote. Full and comprehensive access to my fairly large iTunes library on the iMac: all playlists, etc, with the ability to control volume, jump around in songs, see artwork – just like the ‘iPod’ iPhone application!

Impulsive Highlighters

The Remote is one of Apple’s own applications rolled out for free over the App Store for the new iPhone software and it is absolutely brilliant, with an amazing user interface and flawless integration. It’s the best iPhone application I’ve used yet and I just love it! It sets the perfect example of an iPhone app.

iPhone 2.0: Remote App << Cheaper than therapy

The NYTimes reader is nice as is the Google app that gives me decent access but it’s the Apple Remote app that is just, well, cool.

Apple TV updated, support for MobileMe, Remote

The iPhone remote application is worth the upgrade alone. Gone is the need to use Apple’s minimalist remote control, and replacing it is a full color touch sensitive remote that would put a Logitec all-in-one unit to shame (although of course it won’t work my TV). For Apple TV fans, bliss.

Apple TV 2.1 Update Adds Remote App and Mobile Me Support

Support for the Remote app for the iPhone and iPod touch (awesome)

First iTunes Remote App for iPhone Hands-On

One of the first apps I downloaded while doing the App Store video walkthrough today was the new iPhone Remote for iTunes. There’s only one word to describe it: perfectomfgthisissocool.
Verdict: download it now.

A First Look at the iPhone Apps Store

It’s that simple: the iPhone is now a house-wide wireless remote control for your music library. I would hate to be one of the companies that sells house-wide wireless remote controls for your music library right about now.

Apple’s Upcoming iPhone Remote App for iTunes Is Really Smart

iPhone 2.0 ‘Remote’ : a Small App For A Giant Leap Forward

Shall you have an iPhone or iPod Touch, you can now remote control your iTunes libraries (Mac and PC, Folks) with the little yet jaw-dropping awesomely fantastic Remote application.
Now, once again Apple is showing the way to the Future : how we’ll be able to control any *connected* device from our smartphone – er, iPhone.

iPhone 2.0 firmware features snazzy little remote app

One of the delicious new freebies in the iPhone 2.0 software update: a lovely little app that will turn your iPhone or iPod touch into a remote control for your Apple TV or within iTunes. It works over WiFi and even hoovers up the cover art or preview image of what you want to play. The Shuffle-like Apple remote magnetically attached to the side of my monitor seems so quaint now.

Hands On with iTunes iPhone remote

You’ll probably remember last month when I wrote about a rumor stating that Apple planned to make their own iPhone remote for release in the App Store. Well, it turned out to be true, and it’s awesome. Apple, with a stroke of genius, has decided to call this iPhone application Remote. It’s free, it’s 1MB, and it’s available through the App Store that was launched yesterday.

ShoesFest 2008: Getting Started

July 10, 2008 § 1 Comment


A big thank you and welcome to everyone who’s joining the Shoes community for ShoesFest 2008. On Friday, July 11th and 25th (local times vary), we are encouraging people with or without programming experience to join us in creating and running Shoes programs on Mac, Windows, and Linux so they can email us with feedback about:

  • crashers
  • platform compatibility issues
  • performance bottlenecks
  • confusing, missing, or under-documented APIs

Here’s Ten Steps for making the most of your involvement in ShoeFest, whether for one hour or twenty-four:

  1. Download Shoes for Mac OS X, Windows, or Linux
  2. Read _why’s answers to common questions
  3. Use an IRC client to join the discussion on irc://irc.freenode.net#shoes
  4. Try one of the Shoes Tutorials people have written
  5. Read and run a few of the included samples, or programs from The Shoebox
  6. Scan Nobody Knows Shoes, and review the poster of the most common APIs
  7. Use `shoes -m` to bring up the manual (On OS X, you can do ⌘-?)
  8. Modify/extend an existing app to try out particular APIs or techniques
  9. Write your own Shoes app. It could illustrate use of a particular API, replicate a similar app on another platform, or just be something you’ve always wanted to write 
  10. File bugs by emailing shoes AT code.whytheluckystiff.net; copy why AT whytheluckystiff.net if you’d like to be permanently added to that mailing list
That’s it! Have fun, and be sure to invite your friends. The Shoes you save may be your own…

7/11 & 7/25 ShoesFests with Why The Lucky Stiff

June 27, 2008 § 3 Comments

why the lucky stiff and friends invite all interested Ruby hackers — and wannabe hackers — to join them for two 24-hour ShoesFests: 

  • Friday, July 11th noon GMT to Saturday, July 12th noon GMT
  • Friday, July 25th noon GMT to Saturday, July 26th noon GMT

< 8 AM New York / 5 AM San Francisco / 9 PM Tokyo / 3 PM Amsterdam >

The goal of these events is to write and share fun little applications using Shoes,  a clever little cross-platform GUI toolkit written in Ruby. This will allow us to test, document, and file bugs on how the various Shoes features work on the different supported platforms (Linux, Windows, Mac), in preparation for our next major release on July 31st, 2008.

No Ruby — or programming — experience is required; we’d love to find out how easy it is for novices to learn Shoes!  Of course, if you happen to know the Ruby C API, expert help is always appreciated.

The primary interaction will take place on the Shoes IRC channel: #shoes on irc://irc.freenode.net
You can participate using any of the many web- and native- apps for IRC.

Shoes comes with its own built-in manual.  Use `shoes -m` to bring it up.  (On OS X, you can do ⌘-?.)

Additional Resources:

Spread the word!  Everybody could use a nice set of Shoes. :-)

« Older Entries

Where Am I?

You are currently browsing the Software category at iHack, therefore iBlog.

Follow

Get every new post delivered to your Inbox.

Join 1,432 other followers