djanowski

Recently I started to work on a very simple tool to do this with a single command: it'll start all your projects in a given directory and expose them via HTTPS on https://[project].localhost

No daemons, and the only piece of configuration is adding a file to /etc/resolvers: https://github.com/djanowski/hostel

I've been using it for myself so it's lacking documentation and features. For example, it expects to run each project using `npm run dev`, but I want to add Procfile support.

Hopefully other people find it useful. Contributions very much welcome!

I'm surprised such an in-depth article doesn't even mention promises. Upcoming async/await (already available via transpilation) will make error handling in Node sane again.

That's a good first step.

However, flow is more than knowing what you're working on.

Maybe there are techniques to not lose that state of mind so easily?

I happened to be reading The Design of Everyday Things at the same time as Understanding Air France 447. It was surprising to see how the concepts explained in the book by Don Norman applied perfectly to explain the errors made by the pilots -- even though airplanes are not everyday things.

Can you fix the typo in the title?

Thank you!

\o/ Thank you!

Yes, you're right that most frontend developers already rely on Node for various tasks.

This would be most helpful for those who still haven't introduced Node as a dependency and trying hard to get away without it :)

In any case, as I mentioned in another comment, the fact that one can write a minimal preprocessor in ~30 LOC could be useful to start a conversation about the current state of the art regarding frontend development.

Most importantly: it's very easy to end up with a huge CSS file that can't be compressed, and it makes everything more complicated.

Representing hierarchy in the class name makes the output shorter, in most cases, and makes the HTML and CSS code easier to understand. For instance, when you see <div class=title>, you need to go up to find context to understand what that "title" class is. If you have <div class=widget-title>, that's much better. Let alone that generic ("title") classes can lead to problems with conflicting rules depending on their specificity.

By the way, classes at the top level are faster to parse and apply.

This articles expands on some of these issues: http://www.sitepoint.com/beware-selector-nesting-sass

That's awesome. Let's keep in touch :)

Both Less and Sass implement features that I consider anti-patterns: nesting, @extend, etc. Sure, you can ignore them, but there's a lot of code in the tool to support that. The code needs maintenance and puts the barrier of entry higher for those wanting to contribute to it. Also, these are first-class features of the tool, they can't be disabled explicitly. So you'd need code reviews and other artifacts to make sure no programmer/designer ever tries to use them. Finally, why would you choose a tool that does 20x what you need, if there's an alternative that does just what you need? (As stated in other comments, I don't mean my solution is what will replace all preprocessors. PostCSS looks like a more modular approach and it allows you to effectively cherry-pick the features you need by means of plugins.)

Also, easy != simple. The fact that a tool is easy to install (after having installed another mega-dependency) shouldn't count as an advantage, in my opinion.

I don't think you read the top section of the README. It clearly says that I was first looking to write a simpler CSS preprocessor, and then came across M4.

I'm not saying the tool I wrote will replace all preprocessors. My point is: I wrote one with just enough features in around 30 LOC. Can we use that to start a discussion around the current state of the art regarding frontend tooling? Or software in general?

Thank you!

It's true. sassc(1) is a great step forward in terms of speed.

That said, Sass encourages practices that I consider bad. Nesting, @extend, etc.

Sass's design also makes it difficult to implement a basic feature like grouping all media queries for a single output. Check this issue from 2011: https://github.com/sass/sass/issues/116

If you don't mind a bigger tool and the dependency on Node.js, then PostCSS looks very good: https://github.com/postcss/postcss

That's... a really good question. I added instructions in the README: https://github.com/djanowski/hasp#installation

Thank you!

Cool hack!

Thanks!

Why did this horrible language become so popular? Why has it not been replaced?

I don't know. Maybe just like other tools in POSIX systems -- it works :)

You're right. I didn't mean to say sourcemaps are useless. For now, they were a trade-off. It'd be interesting to see if they can be added using M4.

By the way, antirez is already working on a lazy deletion of large objects: http://twitter.com/antirez/status/626406286083670016

Already using Quip for Mac, loving it. Great job.

I would say that Disque follows the minimalistic philosophy of Redis. However, Disque is a specialization of one of the most common use cases of Redis: queues. So I wouldn't expect so many primitives--Disque knows about jobs and queues, so you don't have to build those yourself like people have been doing on top of Redis.

And there's a Ruby client for it already: https://rubygems.org/gems/disque

And there's a Ruby client to start playing with it: https://rubygems.org/gems/disque

There's some extra background here: http://antirez.com/news/88

Looks good. Add yourself to http://redis.io/clients.

Cool, I'll try to make it.

Also – there's an Open House at Cowork Central this Wednesday, so feel free to join us: http://eventioz.com/events/open-house-jelly

:-)

Fortunately they changed their minds and gems are auto-approved now, so the barrier is still there, just a little bit easier to lift ;-)

Again, GitHub rocks. We tried to create a simple script to make it easier for us to also deploy to RubyForge (mainly because of the username prepending and the --source).

We'll be looking forward to your feedback, James!

Exactly! We've been doing the same thing – releasing only to GitHub because it's so easy and fun (and easier now that they e-mail you when the gem fails to build...)

The idea behind Joe is that if you're already releasing to GitHub, it's really easy to release to RubyForge as well with a single command. No need to wrap your whole project inside something like Hoe. You're already generating a gemspec for GitHub, why not using it for RubyForge?

Plus there's the addition of the ERb template to produce the gemspec (which is completely optional), but that's the best way I've found to maintain my gem specification, especially the files I want to ship.