My New Tumblelog
Tuesday, February 27th, 2007Godammit, before I could get off my ass and write a tumblelog using Rails someone created exactly what I wanted in tumblelogs.
Archive for the ‘design’ Category
del.icio.us Not Being Tasty
Wednesday, February 14th, 2007I wanted to switch from my old del.icio.us account to my new del.icio.us account and was very, very thankful for the (new-to-me) import feature. One problem though.
All my imported bookmarks are marked not shared. Dammit.
I haven’t been using del.icio.us that long, so it’s not like I have thousands upon thousands of links… but I have enough in there that I want public that editing each one individually to share it is a tremendous pain in my ass. Glancing through the comments on this post it seems that many people want the “share all” feature… but the del.icio.us developers have stated that they will not implement this feature.
I find that developers (myself included) get these little wild hairs up their butts about the funniest things: The creators of Yojimbo are vehemently against organizing information in the application using hierarchical folders. Not as big a pain point there as the tagging support more than makes up for it… but, dammit, sometimes I want to organize things as “Letters/Work” and “Letters/Personal”.
Anyway, I’ll probably release a little script soon that re-shares all one’s del.icio.us bookmarks.
The Machine is Us/ing Us
Thursday, February 8th, 2007Check out the pretty YouTube video by Assistant Professor Michael Wesch of KSU.=
So that’s what Web 2.0 means. ( = JK/NR!!!11
Here’s the KSU Digital Ethnography homepage.
HOLY CRAP IT’S THE iPHONE
Tuesday, January 9th, 2007Engadget’s got good live coverage:
I’m still betting the “And one more thing…” is Leopard, thus scooping Vista.
Simplicity
Wednesday, November 29th, 2006I’m agreeing with Joel again about simplicity.
Less is more. (In fact, sometimes you want only half)
Do you hate preferences? I do. (Yeah, yeah, yeah… I love that book)
Seems there’s a design trend lately towards minimalism, a trend towards items that do one thing and do it well,... and we’re seeing it again, and again, and again.
I want in. ( =
Question on Generics
Tuesday, October 3rd, 2006Suppose I have an event reactor pattern set up like this:
public interface IEventDispatcher
{
void Subscribe(IEvent newEvent, EventDispatcherHandler handler);
void FireEvent(IEvent newEvent);
}
public delegate void EventDispatcherHandler(IEvent newEvent);
public interface IEvent
{
// ... meaningful eventing stuff goes here ...
}
This is all well and good as it decouples senders and receivers, blah blah blah… And in the real code these are all in separate files and all that jazz.
Anyway, something I’ve noticed many times in doing event dispatcher patterns is a tendency for these “events” to become “commands” as well… so you might have the “SaveThing” class… but then you’ll add the “ThingSavingEvent” class (which is cancellable) and the “ThingSavedEvent” class. For every “command event” you’ll have the pre- and post-events as well.
And what do they teach us about code duplication? ( =
So here’s what I wanted to do:
public interface ICommand
{
// ... do command stuff here ...
}
public interface ICommandExecuter<t> where T : class, ICommand
{
void DoCommand(T command);
void UndoCommand(T command);
}
public class CommandRegistry
{
private IEventDispatcher dispatcher;
void RegisterExecuter</t><t>(ICommandExecuter</t><t> executer) where T : class, ICommand
{
// register executer here
}
void Execute(ICommand command)
{
// fire precommandevent for this command
// iterate over each command executer instance for that command
// fire postcommandevent for this command
}
}
// here's the part I'm pretty sure won't work...
public class PreCommandEvent</t><t> : IEvent where T : class, ICommand
{
}
public class PostCommandEvent</t><t> : IEvent where T : class, ICommand
{
}
</t>
Here’s how it works: the CommandRegistry gets a bunch of ICommandExecuter<> instances for different commands… the SaveCommand, the ExitCommand, and so on (eventually I want to put something in the CommandRegistry to maintain order, to make the command executers transactional… but I digress). Before the CommandRegistry iterates through the executers it constructs and fires a PreCommandEvent<> of the appropriate type. Here’s a concrete example.
1. Program needs to throw the SaveCommand which implements ICommand.
2. Program calls registry.Execute(new SaveCommand());
3. Registry constructs an instance of the type PreCommandEvent
4. Registry finds list of ICommandExecuter
5. Registry constructs an instance of the type PostCommandEvent
Steps 3 – 5 are the problem here. The language does not support doing things like this:
That just doesn’t make sense. Passing a Type object in isn’t syntactically correct there… the type name is what’s expected. And not a string, either.
So, yes, I know I can do some reflection to generate the an instance of the appropriate type… and it’s not that I think reflection is hard, or anything like that… but a lot of the reflection examples depend on the run-time type of an instance of a generic type looking like this: PostCommandEvent`1[[SaveCommand,
This Game Will Be Awesome
Friday, May 12th, 2006GameSpy has a neat article called Will Wright Presents Spore that documents a super-fantastic approach to game creation and gameplay.
Using deterministic, procedural algorithms in response to user-supplied data the game grows the creature and determines behavior based on its form. Awesome! I especially love the “massively single-player” aspect of downloading specifications for other players’ structures and creatures and populating the world with these buildings and beings. I cannot believe that I have to wait a year for this game to come out.
I’m also already thinking about ways I want to do this in my own as-yet-unnamed project… stay tuned. ( =
EDIT: Google video has a fantastic Spore gameplay video. 35 minutes long but so worth it.