Nikos Gereoudakis stream7

Get Out Of Photoshop

The Post PSD Era: http://bradfrostweb.com/blog/post/the-post-psd-era/
Mocking Up is Hard To Do: http://blog.bearded.com/post/21447195970/mocking-up-is-hard-to-do

Atomic Design

An extract from Designing Atoms and Elements: http://stuffandnonsense.co.uk/blog/about/an-extract-from-designing-atoms-and-elements
- Smashing Book #3 from where it came: https://shop.smashingmagazine.com/smashing-book-3.html
Atomic Web Design: http://bradfrostweb.com/blog/post/atomic-web-design/

Frontend Development

Attention: the list was moved to

https://github.com/dypsilon/frontend-dev-bookmarks

This page is not maintained anymore, please update your bookmarks.

The idea:

allow precompilation which outputs a set of compiled cache-busted files and produces a mapping object { source_path => compiled name }
make this mapping available to the production code through the environment variable (good for Heroku)
still support on-the-fly compilation for the development machine

asset-compilers.coffee is a adapter module around connect-assets and the "mapping" JSON. Also adds 2 custom compilers - a thin Sass wrapper around the official gem and a Jade compiler for client-side templates

build_assets.coffee is a CLI script using the previous module to perform the compilation and outputs the mapping JSON to a file. It also directly copies all the assets that do not need compilation

config.coffee is an example how STATIC_HOST is made available for the application

I'm having trouble understanding the benefit of require.js. Can you help me out? I imagine other developers have a similar interest.

From Require.js - Why AMD:

The AMD format comes from wanting a module format that was better than today's "write a bunch of script tags with implicit dependencies that you have to manually order"

I don't quite understand why this methodology is so bad. The difficult part is that you have to manually order dependencies. But the benefit is that you don't have an additional layer of abstraction.

Zero downtime deploys with unicorn + nginx + runit + rvm + chef

Below are the actual files we use in one of our latest production applications at Agora Games to achieve zero downtime deploys with unicorn. You've probably already read the GitHub blog post on Unicorn and would like to try zero downtime deploys for your application. I hope these files and notes help. I am happy to update these files or these notes if there are comments/questions. YMMV (of course).

Other application notes:

Our application uses MongoDB, so we don't have database migrations to worry about as with MySQL or postgresql. That does not mean that we won't have to worry about issues with the database with indexes being built in MongoDB or what have you.
We use capistrano for deployment.

Salient points for each file:

Your class can be no longer than 100 lines of code.
Your methods can be no longer than five lines of code.
You can pass no more than four parameters and you can’t just make it one big hash.
When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. And your view can only know about one instance variable.

You can break these rules if you can talk your pair into agreeing with you.

The spec has moved to a repo: https://github.com/defunctzombie/package-browser-field-spec to facilitate collaboration.

	$ = jQuery

	queues = {}
	running = false

	queue = (name) ->
	name = 'default' if name is true
	queues[name] or= []

	next = (name) ->

	gifify() {
	if [[ -n "$1" ]]; then
	if [[ $2 == '--good' ]]; then
	ffmpeg -i $1 -r 10 -vcodec png out-static-%05d.png
	time convert -verbose +dither -layers Optimize -resize 600x600\> out-static*.png GIF:- \| gifsicle --colors 128 --delay=5 --loop --optimize=3 --multifile - > $1.gif
	rm out-static*.png
	else
	ffmpeg -i $1 -s 600x400 -pix_fmt rgb24 -r 10 -f gif - \| gifsicle --optimize=3 --delay=3 > $1.gif
	fi
	else

	# to generate your dhparam.pem file, run in the terminal
	openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048