Bookshelf for Dash

In addition to the recent Moment and Async docSet for Dash, I have created a third docSet distribution, this time for the cool library Bookshelf which is pretty cool Node.js ORM for PostgreSQL, MySQL and SQLite3 in the style of Backbone.js.


Created by Tim Griesser, its just one project in the line of many which is solving every day issues with elegance and efficiency… Currently its the same approach as with Moment and Async, where its merely an embedded version of the online documentation…


Add the documentation from here… Direct Link


Moment.js for Dash

I have decided to add all the documentation I’m using to my setup for offline access, for this I’m using Dash (Dash is an API Documentation Browser and Code Snippet Manager).


Dash is the same docSet standard used by Zeal (“…a simple offline API documentation browser inspired by Dash (OS X app), available for Linux and Windows”,


For my first docSet I chose to make the documentation for Moment.js available (a javascript date library for parsing, validating, manipulating, and formatting dates).


Since the most laborious part of generating a docSet is adding all entries to the searchIndex database (an embedded SQLLite database), I opted for simply embedding the online documentation in an archive and expose it as the docSet in a single resource.

To install the docSet, simply client the link below and it will automatically add the reference to Dash (or Zeal):
Custom DashFeed URL for adding the docSet

If you prefer you can also add it manually by adding the following link to the list of docSets:
Direct URL to the docSet definition

Next step would be to create a script that would allow me to extract the different documentation points from the online documentation and add it to the searchIndex, however for now it fullfills my need to have an easy and structured way to access the documentation when offline.

Methodology, Tools

The Brackets Team… using Trello

In my optics (and obviously when wearing my coders goggles) Brackets is the most exciting news to come out of San Jose this year… not only is the team targeting to build an entirely new code IDE for web projects, but they have decided to do it in a new way… a way that may prove both to be more challenging as a traditional product development approach as well as more rewarding as members of the community starts joining the development effort by adding both core features as well as extensions (an extension API is on its way) even from the very beginning of its lifetime…

Anyways, what I wanted to share was that the Brackets team is using Trello as their SCRUM board.. being a happy Trello user myself, this is off course both interesting and exciting…


The Brackets Team obviously practices Scrum. They have decided to work iteratively and produce stable builds every 2.5 weeks (12 coding days to be exact). A rather unusual number, however it works for the Adobe Brackets team… Development started in January 2012 so it’s still in the very early stages of the project.

The project goes under the parole: Code Free ! So I suggest you do exactly that, join the project, contribute a feature or two, learn a lot and then take this approach and apply to your development efforts in your own circles, being commercial or not, the approach is clever and when executed correctly, can empower to teams and the extended teams like no other approach…


The Five Generic and Easy Milestones…

I have found that on most smaller projects, I end up with 5 generic milestones, depending on the execution of the project, the composition and distribution of effort will be adjusted, however it seems to never fail… its not exactly RUP, MSF or one of the many cool Agile process methodologies and process frameworks… however there are direct tracing to all of them…

  1. Tracer Bullet (5%)
    …decent writeup on the definition of the executable produced during this phase:
  2. Walking Skeleton (10%)
    …and a pretty decent writeup by none other than Crystal inventor: Alistair Cockburn:
  3. Lions Share (70%)
    …the definition of this milestone is vaguely inspired to a certain degree of that of the UP Construction phase…
  4. Release Candidate (10%)
    …I suppose this is common to most process frameworks and methodologies in one form or the other:
  5. Golden Master (5%)
    …along with the previous of stabilizing phases, it has many traits in common with the MSF Stabilization phase, I found a neat writeup on that here:

Giving them not arbitrary names such as “Batman”, “Pavarotti” and other gimmicky naming schemes, seems to require less explanation of the use of named milestones for non-programmers… yet still using some easily identifiable names seems to make the understanding of an iterative and incremental development approach come more easy among business people… and choosing names that actually reflects the contents of the milestone seems to have a positive effect on the adoption of the named milestone approach… what are your thoughts and experiences ?