I’m quite glad to see labels (similar to GMail’s) are finally landing in Fastmail.
Continue reading post "#2897"organization posts
TMLib meets Require JS
I’ve recently been working on reorganizing, cleaning up, and improving my javascript library, TMLib. This has included folder reorganization, source cleanup and normalization, a (so far crappy) build system, adding unit testing, a (mostly still unused) class system, etc.
My most recent effort has been to bring in the use of Require JS. Require is an AMD implementation, which is an interesting extension of the module pattern. It takes the dependency injection part of the module pattern (ie passing variables the module will use as arguments into the function expression) a step further by handling auto loading of those modules with a script loader that will asynchronously load and run all dependencies for a module before running the dependent module, injecting the dependencies as either parameters or assigned variables. Require does this with names based on file path, sort of like a JS equivalent of PSR-0. Require also provides a build process that will combine all required module files into one and minify. I have not played with this yet, but am hoping it will take over my currently crappy build process.
So far, I’ve only converted over a small core part of my library, but I really like the direction it is going. The scoping/dependency wrappers around each module may add some bulk, but will also allow minification of all module dependencies and what not, so it may end up being insignificant in the build, especially since my current build process doesn’t involve much minification. Even if it ends up a bit larger than it could be, the development benefits outweigh that concern for me. It has also required a change in the way I construct my library pieces. The early pieces require being constructed in a certain order, and things don’t work as well when modules to depend on each other. But I think it will be really nice when I get the full library converted over and the build process figured out.
Workshop Paradigm
apps + files organized by job/workshop
example: music making workshop has music creation apps + users personal (and other’s shared?) music files
different users have same apps (tools) but their own files (works)
different jobs/workshops may use same tools ie music making and music listening workshop may both need some listening tools