<guardian>
matjas: that's my implementation of to_slug(string)
<guardian>
matjas: I felt I didn't need to depend on another gem just for that since I'm writing everything in English so doing string.downcase.strip.gsub(' ', '-').gsub(/[^\w-]/, '') is enough to slugify something
<matjas>
guardian: cool, but where do i put this? (i'm new to nanoc, obviously)
<guardian>
but in fact I think I'll have 3 separate settings in config: for css, js and html minification
<bobthecow>
i use debug? for that.
<guardian>
and have preprocess override those defaults if ENV contains NANOC_ENV set to production
<bobthecow>
and the env settings for prod/dev switches.
<guardian>
not sure I need both debug? and production?
<bobthecow>
i have different levels of crazy depending on those two settings.
<guardian>
well I think, even when developing the site further, I want everything to be minified anyways: best way to early see if minification messes things up
<Rym>
darix: do you have a gist for what you're attempting perhaps? or more detail?
<bobthecow>
right. that's what i'm doing.
<bobthecow>
debug? is for when minification is hiding something or i want to view compiled but not minified source.
<bobthecow>
but most dev is done with debug==false and env==development
<guardian>
what difference do you make?
<guardian>
compiled but not minified?
<darix>
Rym: gallery module. i have foo.jpeg and foo.yaml
<darix>
foo.yaml has all exif data
<darix>
so i want to have /foo/index.html
<bobthecow>
things are deleted in preprocess if production?
<bobthecow>
everything's always compiled.
<bobthecow>
things are minifed unless debug?
<darix>
generated by (:rep => :html)
<guardian>
oh
<darix>
which renders foo.jpg + the exif metadata from foo.yaml
<guardian>
yeah I have @items.delete_if { |item| item[:publish] == false } in preprocess but I don't even use it
<guardian>
it's there because I saw others do it when I began
<guardian>
bobthecow: I think I don't even need to hide, remove things if I feel the need to fix something and ship — isn't that the job of fix branch + rebase dev?
bghost has joined #nanoc
<Rym>
darix: pm me the related rules :)
<darix>
Rym: later. busy atm
<Rym>
sure
<bobthecow>
guardian: depends.
<bobthecow>
we have dev resources (style guides, etc) that aren't shipped, but are always there.
<guardian>
I see
<guardian>
ok need to recap. @config[:minification][:css] set in config.yaml as default value. then in preprocess if production? ensure minification is set to true unless debug? in which case force minification to false?
<guardian>
maybe that's over engineered already. have config switches for each minification (css, js, html) always set to true (and committed as is) and revert back one of them in case something breaks
<guardian>
debug? doesn't offer enough granularity — and about production? for now I don't need to filter out parts
<bobthecow>
YAGNI
<guardian>
YAGNI which part? separate control over css, js, html minification?
<bobthecow>
overengineering all of this :)
<guardian>
or the convoluted combination of production? and debug? :)
<bobthecow>
yeah.
<bobthecow>
the only thing we use production? for is removing items that aren't present while in production.
<guardian>
yeah not sure config switches are even needed
<bobthecow>
and the only thing we use debug? for is toggling minification for when things start breaking.
<guardian>
it's: config switches VS comment Rules temporarily
<bobthecow>
and we use those directly in the rules.
<bobthecow>
so the rule says `filter :uglify_js unless debug?`
<bobthecow>
etc.
<guardian>
but could be comment filter :uglify_js is really something breaks with js minification
<guardian>
s/is/if
<bobthecow>
true.
<bobthecow>
that works too.
<bobthecow>
we've got lots of rules though.
<bobthecow>
so it's easier to change `debug: true` in nanoc.yaml :)
<bobthecow>
6 rules files and counting.
<guardian>
indeed
tracphil has joined #nanoc
<Keltia>
meow
<Keltia>
ddfreyne: ping
<Keltia>
bobthecow: I have another problem for you :)