Sword | Hacker News Reader

Sword

sword.mu

93 pointsbradly36 comments

With a proper Makefile,

    $ cd project
    $ inotifywait -m -e modify,close_write,move,move_self,create,delete,delete_self -r . | while read; do make; done

Every time any source is modified, renamed, created, etc, that will run 'make', rebuilding whatever output artifacts you need.

As long as you're careful about always re-fetching artifacts (like css files built from whatever css-sugar-y thing is hot this week) somehow, that should set you up nicely, and it generalizes to all kinds of workflows.

Thanks for making me aware of this. This is linux specific but something like this seems to be available on Mac OS X (https://github.com/alandipert/fswatch).

I don't quite understand where in your command you specify that make is executed? Could you expand on that.

while read; do make; done

that's spot on.

the command "inotifywait -m -r . -e {some events}" recursively watches all inodes in the current directory (the "-r" and "." parts) for events in the {some events} list, and every time something happens (you save a file, create a new one, open a file, etc etc), inotifywait prints a line.

The "-m" flag makes it print a line and keep watching. Without that, it's a one-shot (which can work like [0] but all the setting up and tearing down of inotify watches is expensive on a large project).

[0]

    $ while inotifywait -e some,events -r . ; do make; done

I got sick of not having a unified way of managing auto-rebuiding across the variety of tools I use (compass, coffescript, closure compiler, rake, etc) so I built something similar. I just wanted to say if * changes, run X, oh and by the way please debounce change events before running X. And the app needed to be easy for other devs to use it reliably and reproducibly.

https://github.com/apinstein/watchngo

As I typed it I was thinking that debouncing change events would be nice; as I wrote the above, you'll get several events depending on what operations you're performing.

It happens that subsequent invocations of 'make' will be blindingly fast because it will check inode timestamps (by default, you can force make to look deeper if you have Reasons) and because those inodes will still be cached "somewhere" in the kernel. So, debouncing isn't critical for this particular use case, but it would give me a warm fuzzy feeling.

I wrote a little tool to do that, http://github.com/adamsanderson/when-files-change .

For instance

    when-files-change -- make

In general, it has the same underlying mechanism, but simpler to remember ;)

Another option is using Grunt with the watch plugin.

I like it.

Not being familiar with .styl, though, this line confused me: "So, it has found /assets/style.styl."

Especially because it found style.sass

.styl is the file extension for stylus. Its just another css preprocessor like less or scss

http://learnboost.github.io/stylus/

I think this part is just a typo

> So, it has found /assets/style.styl. Now it analyzes extension:

> .sass extension? Use Sass then.

Thank you, will fix it.

Me too. Must be a typo.

Yep, just a typo.

Yep, fixed now. Thanks.

Seems very similar to the Harp project: http://harpjs.com/

I may actually prefer this better because of the scss/sass support, though.

Serve is also very similar: http://get-serve.com/

Could not recommend this more – strikes just the right balance between a Rails app and plain HTML/CSS for prototyping.

Hey, I am the Sword author. Harp development and Sword development have begun almost simultaneously. You should stick with Harp if you use typical NodeJS tools for templating (like Handlebars and Stylus), and use Sword if you prefer Ruby ones.

(author of harp here)

Sword indeed looks very cool, and yes, it is almost identical to Harp.

People should really pay attention to this approach because I'm fairly confident this is where static web servers/generator are headed. By lazily compiling only the assets that are needed when requested we save a stupendous amount of cpu cycles and we can keep the development workflow much more natural and rapid. Regenerating the world as Jekyll does, is ridiculously slow, awkward (spews out static files everywhere), and still requires a static web server to serve the files.

Today many people are manually setting up pre-compiling with tools like Grunt and Make to do their pre-compiling but I don't expect this to last much longer due to the cognitive overhead of maintaining these scripts and the lack of features such as layouts and partials. Not sure if sword supports this but I couldn't imagine harp without it.

@svoroval - Best of luck with Sword. Looks like we are on the same page :)

@taylorlapeyre - FWIW SASS support in Harp is right around the corner. We held off until node-sass didn't require a compile step to be installed. It now meets that requirement.

I have no use for this, but it should really be caching compiled versions and recompile resources only when they become newer than what's cached.

I think some information is missing here.

Suppose I want to look at a CSS file (zzz.css, say). But that file does not exist, since I'm using LESS to make my CSS. The LESS source exists; the CSS output does not -- yet. I'm using sword.

I have a Unix command prompt in front of me. What do I type?

How I understood it:

    $ sword &
    $ wget localhost:1111/path/to/style.css

I don't really see the benefit over using something that does background compilation e.g. CodeKit.

Also it seems a little silly/wasteful to use this in a production environment, which I may be mistaken about but the last paragraph seems to be instructions for deploying a site on top of this.

It is silly and wasteful. It is just possible.

There seems to be no mention in the docs of where the compiled files end up, if anywhere; taking the docs literally it appears that this is the preferred way to use sword, which is indeed silly and wasteful.

Just use --compile flag. Here is the issue: https://github.com/somu/sword/issues/7

It might mean production but that paragraph is useful for dev server configuration. I'd want --daemonize almost all the time in a dev environment. --compress sounds useful for exporting assets for production.

If you prefer GUI and reload the browser for you, I think livereload does very well.

http://livereload.com

What's the advantage of using Sword over, say, compass watch?

Zero configuration (no config.rb), a lot of preprocessors besides Sass/Compass supported (like LESS, HAML, Slim, CoffeeScript and so on).

Sounds neat! An easy-to-use (API) proxy would be a killer feature.

Got it! Open an issue and describe your thoughts? Will think to add it in the next release.

is this similar to yeoman?

Not really.

$ watch

Like!

Reply on news.ycombinator.com