Still here, and loving TextMate for AS3

Just a quick note to say that I haven't abandoned Identity and / or fallen under a bus.

The book I'm writing at the moment is in the final intense stages, so spare time is non-existent.

I'll try to reply today to anyone who has emailed me and not heard back. 

As an aside - last week I finally completed configuring TextMate to edit all my AS3 projects, and use ant to produce asdocs. I'm mostly working in Flash rather than Flex so it took a bit of wiggling to get the fl. package stuff to stop complaining.

Clearly if you're on Windows then you've got the option of FlashDevelop, but on Mac I've tried Flex, Eclipse with Powerflasher FDT, jEdit, coda (which I'm still using for everything except AS3) and of course the good ol' Flash IDE, but I've finally settled on TextMate and I'm really happy with it.

I'd been using TextMate as a 'power editor' to do extensive find / replace type tasks when refactoring for a while, but had come across multiple problems that stopped me from switching to it for all my AS3 and asdocs.

I'll post a complete run down of how I've finally got it set up next week. Google code group and this blog should be active again from the end of next week onwards. 

 

Aviary invites

I've got 5 aviary invites to give away.

Let me know if you're interested.

What if Sam releases Saffron?

I've been asked the question "What happens to Identity if Sam releases Saffron?" a couple of times recently, so I thought it might be a good idea to address it here, as I'm sure more people are wondering it.

The answer is that I don't know (mostly because it won't be up to me). At the moment Sam's website continues to be offline, and all anybody 'knows' about Saffron UML is based on a handful of screenshots and whole bunch of rumours.

If Sam does release Saffron and it turns out to be as good a tool as people are anticipating then either Identity will cease to be something that is worth developing, and we'll just get on with using Saffron (and be glad about it!) or Identity will still look like it delivers something sufficiently different from Saffron to continue working on it. We may even use Saffron for later stages of development, and/or perhaps refactor some of the Identity features to work as Saffron plugins. In any case, the best feature of open source development is the fact that it won't be my decision. If anybody sees value in continuing development then they can go right ahead and do that!

In using the PureMVC framework we're aiming to create some of the functionality we're going to need as add-ons to the framework which should also have use in other projects. We're going to need a set of lightweight components too, and we'll either be using existing open-source code or developing our own for those - which will also continue to have value regardless of what happens with Identity.

I'm personally building Identity because I really want to use it! As someone who used to be a manufacturing engineer I'm also really interested in production processes, and I'm excited about the solutions that we might develop in delivering truly integrated planning / modeling / documentation / stub-code. I've got no urge to be a big name in the flash community, though if Identity does come to fruition I quite fancy the idea of writing a book about joined up processes in AS3. Or something. Probably AS4 by then ;)

Oddly I'm using CRC and UML to structure the book I'm writing at the moment about Global Climate Change. My chapters are like objects, having responsibilities, collaborations, methods and properties. One of the things that I dream about for Identity is the ability to plug-in alternative tools for organising our thinking. Stuff that hasn't been dreamt up yet ...

Snapshots

Last week I was doing UML diagrams for a colleague to use in building his part of a large application. It occurred to me that the information he actually needed was quite a lot less than what was on the diagram, but as we were doing some test led development, and the model was continuously evolving to reflect the results of our tests, it was too annoying (and unreliable) to have two separate versions of the model to update.

I think the answer to this problem would be for each Identity Project to be able to have multiple 'Snapshots' - as roughly visualised in the pic above. In different Snapshots the state (CRC / Full class element / Collapsed class element) of each element could be different, but making a change to the model would update it overall, and the changes would be reflected in each snapshot. 

I've also been thinking about 'visibility filters' for the snapshots. Being able to toggle on and off all public / private / protected / package attributes and operations in the whole diagram would be useful too - I often find myself running 2 copies of a model, one with the entire structure and one to give to a collaborator which only includes the public stuff.

Apologies if this stuff is already present in existing UML tools - at the moment I've decided to not do any research into what's already out there until the first draft of the Identity spec is written up. At that point I think it'd be useful to compare what we've come up with to what's already available, but I'm trying to keep my thinking coming from 'what do we want this to do?' at the moment rather than 'what do other tools do?', knowing that we can pick the status quo up later.

Google code sign-up info

Join the Identity Modeller project at Google Code here.

I've also resolved the single-core / multi-core puzzle I think.  A multi-core version of PureMVC is going to be appropriate for a modules based application whether the app has one or many project windows.

Each module can run its own mini-version of the PureMVC framework.

The recommended strategy for modular PureMVC - presenting an interface to the module - is the only option available within the AIR security model anyway, so the multiCore AS3 port of PureMVC looks like a perfect fit.

I'm hoping that we can develop some of our functionality as PureMVC plug-ins.  For example - stuff around history / undo / redo across different modules is going to be a fairly generic solution. The saving of application state (something I love love love about Coda) so that when you start up next time it's just as you left it is also a framework solution that might be of use to other PureMVC users.

I've been thinking about the roadmap and time frame. A couple of people who have expressed interest in being involved are just hitting an intense period of exams and thesis submissions for the next month or so. I think that's potentially a good thing - I believe it takes a while for an idea as complex as this to settle and emerge. My objective then is to remain in planning until the end of June, and work towards a more and more precise definition of the project in that time.

Work begins in earnest at the beginning of July. I'd very much like to get to Alpha in October / November and release the first Beta in time for christmas. Wouldn't that be nice?

PureMVC, and the MDI / TDI quandry.

CarnageBlood recommended I check out PureMVC as a framework, and I'm really grateful for the suggestion because it looks excellent.

I have no doubt that using PureMVC is a good move - it's opensource and we can develop any generically useful extensions as plug ins that will be useful to other PureMVC users.  

The big question I have is single-core or multi-core?  How do these relate to interface possibilities?

My favourite applications appear to be a hybrid of TDI and MDI.  Coda is an amazing one-window-web-development tool that has tabbed browsing of files open in each window - one window referring to a 'site'.  Having multiple windows open means I can entirely separate my work by project / client / server.  I love it.  Each window has its own interface - file browser, search tool, activity etc.  A couple of windows - such as 'clips' - a code snippets tool - are shared across the app as floating panels.

Omnigraffle 5 works in a very similar way. Lots of the interface is wrapped directly around the document, but formatting panels etc are floating shared windows.

I've done plenty of standard MVC development but never a multi-core app.  I'm not even sure that what I'm describing is truely multicore?  Whilst there would be many models, views and controllers, the actual basis of the application is perhaps still a single core?

More reading to be done - and possibly the best way forward is to plan version 1 as single window (apart from interface floaters) tabbed documents style, with the multiple project windows version as a major update.

Identity modeller roadmap

If you build it, they will come ... 

That's my mantra at the moment anyway. At times I wonder whether I'll get enough active contribution to this project to make it worth doing open source ... and then I tell myself to shut up, because open source is something I believe in.  Wikinomics, etc.

I have a genuine passion about this project. I guess it's my old production engineer background coming out - I want to fix the process, regardless of the product. In the last year or so I've begun to feel incredibly frustrated by a lot of the work I do, by the sheer pointlessness of it to be honest.  But I still have friends who do OO coding who don't feel able to use UML, or CRC, and I still find I'm having to talk myself into doing it sometimes, and I know that if I had the tool that Identity aims to become I would be a much better coder and technical manager. I know that sharing good code would be easier for starters.

I'm fortunate to be involved in a couple of really, genuinely worthwhile projects - the biggest of which is a training application that runs in AIR. Apart from a really good usable GUI, the AIR-ness means that this app can manage its own updates in a wonderfully smooth way, something which has allowed us to get it out to users much earlier in the process than with a conventional app, where releasing updates might be problematic.  We can get a bug report from the client, engineer a fix and release the new update to all users within hours.

Based on that experience, the Identity modeller roadmap aims to release as early as possible. I'm also a fan of getting the risky bits out of the way as early as you can, so we start up with the data side, and work towards graphics at the end. To begin with it won't be pretty, but it will be working.

You can download the roadmap here. (pdf, 1.4 MB)

I've no idea what the timeframe is, which will depend partly on how many people get involved and how their schedules are playing out. If you want to have input into the big picture, in particular the scope of the model and the way data is saved, speak up now.  Thanks to all those already chipping in on email and chat!

If you're not able to contribute in terms of coding or design but would like to do unit testing or alpha / beta testing I'm already taking names for those ... don't be shy.