ddfreyne changed the topic of #nanoc to: 3.6.4 (may 29th) | web http://nanoc.ws/ | repo http://bit.ly/XE6e3G | issues http://bit.ly/VfXaSV | forum http://ho.io/n-discuss | irclog http://irclog.whitequark.org/nanoc
alerante has quit [Remote host closed the connection]
<smkelly> this nanoc thing sure is great.
<bobthecow> smkelly: i'm a fan.
<smkelly> is there some advantage to using the relativize_paths filter?
<smkelly> I don't get why you'd do it
<bobthecow> if you're running your nanoc site in a subdirectory or something, it makes things easier.
<bobthecow> i.e. if example.com/blog/ is your nanoc site.
<bobthecow> you could either hard-code /blog/ at the front of all your links, or you could use explicit paths relative to the nanoc root, then relativize 'em.
<smkelly> ahh
skroon has quit [Ping timeout: 264 seconds]
skroon has joined #nanoc
<ddfreyne> smkelly: It also makes it easy to move your site elsewhere later on
<ddfreyne> bobthecow: Hmm, that tag stuff looks nice
<skroon> hi ddfreyne
<bobthecow> ddfreyne: yeah. i'd like to extend it to work with all item attributes.
<bobthecow> and do things like LSI and baysean classification.
<bobthecow> since that just does dumb word matching.
<bobthecow> but if you've got a system-wide thing to modify metadata, it might as well do some classification and tagging with smarts.
<bobthecow> (for what it's worth, i built an LSI implementation for nanoc, but it's *really slow* so i never ended up using it)
yogsototh has joined #nanoc
pavelkunc has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
<ddfreyne> bobthecow: yeah :)
<bobthecow> might be worth making mutable data sources for 4.0
<bobthecow> offload the "i want to write an attribute to this item" to the filesystem datasource.
<ddfreyne> I played with that idea before, but discarded it for reasons of complexity
<bobthecow> obviously, not mutable during compilation...
<ddfreyne> But... maybe this should be investigated again
<bobthecow> but from a separation of concerns point of view, it seems like making the data source writeable makes more sense than having arbitrary commands rewriting your files.
<bobthecow> that and it could be aware of what has a metadata file, and what has frontmatter.
<bobthecow> items that come from legacy data sources, or are added during preprocessing, would of course be non-mutable.
<ddfreyne> bobthecow: Absolutely
<ddfreyne> The data sources need to be very generic then, though. Meaning full CRUD on everything
<bobthecow> i'd just do something like @item.write foo and @item.write_attribute :foo, bar
<ddfreyne> bobthecow: need delete_attribute too
<bobthecow> ahh. yeah.
<ddfreyne> bobthecow: what about renaming items? moving them, I mean?
<ddfreyne> That could potentially even need VCS integration
<bobthecow> nooo.
<bobthecow> leave the vcs separate.
<bobthecow> it'll detect moving, renaming, etc.
<bobthecow> i'd just start with a simple "i want to write attributes", honestly.
<bobthecow> because for most things, that's enough.
<ddfreyne> bobthecow: git does, but others possibly don't ;)
<bobthecow> for example, i'm currently tracking hashes and "updated at" timestamps in a yaml file and merging them into the item attributes during preprocessing.
<bobthecow> i'd much rather write 'em to the items themselves, but i don't want to deal with parsing and rewriting content files, and possibly screwing everything up :_
<bobthecow> :)
<bobthecow> so if it were built into the data source, i'd be a lot happier setting @item.write_attribute :updated_at, Date.now
<ddfreyne> bobthecow: Yeah. Preprocessing should ideally be limited to a minimum
<bobthecow> and doesn't need to be redone on every compile.
<bobthecow> it's not like my items are changing every time i compile.
<ddfreyne> Even generating tag pages, or pagination pages, should happen when necessary, and not always when compiling
<bobthecow> that could be one of the things the nanoc-tag or nanoc-metadata or whatever does.
<ddfreyne> bobthecow: I'd like to have a nicer way of generating new pages in nanoc
<ddfreyne> Something intuitive
<bobthecow> you configure a tag attribute, then run a command to generate "tag pages"
<bobthecow> which could be a custom data source and a yaml file or whatever.
<ddfreyne> Yeah
<ddfreyne> bobthecow: So you'd have content/ and generated-content/ for generated pages (like tag pages)?
<ddfreyne> Would you also have "generated attributes" then? Those could be harder...
<bobthecow> i'd prolly have the tag pages generate into yaml files in tmp/ or something.
<bobthecow> i'd have generated attributes write to the content pages.
<bobthecow> @item.write_attribute :foo, bar should write bar into my frontmatter.
cDlm has quit [Ping timeout: 245 seconds]
pavelkunc has joined #nanoc
cDlm has joined #nanoc
alerante has joined #nanoc
alerante has quit [Read error: Connection reset by peer]
alerante_ has joined #nanoc
cDlm has quit [Ping timeout: 248 seconds]
alerante_ has quit [Remote host closed the connection]
pavelkunc has quit [Quit: Leaving.]
jugglinmike has joined #nanoc
cDlm has joined #nanoc
pavelkunc has joined #nanoc
bghost has joined #nanoc
cDlm has quit [Ping timeout: 240 seconds]
cDlm has joined #nanoc
skroon has quit [Ping timeout: 264 seconds]
<smkelly> Is rules.rb preferred over Rules now?
alerante has joined #nanoc
<bobthecow> smkelly: i use it now.
<bobthecow> i don't know what's preferred.
<bobthecow> but i have big enough sites that i split up my rules files now, so i have a folder named rules/ and that doesn't play nice with a file named Rules :)
<smkelly> I didn't even know it was a thing until I Saw it in somebody's github
<smkelly> s/S/s/, not sure how that happened
<bobthecow> prolly just a super shifty "I"
bghost has quit [Ping timeout: 246 seconds]
bghost has joined #nanoc
<ddfreyne> Irrelevant, but... eewwww.
<ddfreyne> smkelly: I use Rules
<ddfreyne> Although I guess it is hip to call it Rulefile these days... aong with Makefile and Procfile and Rakefile and Gemfile and whatever
<smkelly> Guardfile
<smkelly> in case you couldn't tell it was a file
<ddfreyne> mkdir Guardfile
<darix> ddfreyne: php and nice code are often 2 things you cant achieve at the same time. ;)
<bobthecow> darix: disagree.
<bobthecow> bad programmers can make bad code in any language.
<bobthecow> there just happen to be more bad php programmers.
<darix> bobthecow: which results in tons of crappy php code out there.
<bobthecow> ddfreyne: as ugly as that is, at least it uses modern password hashing and prepared statements.
<bobthecow> so i'd rather people use this than roll their own.
<darix> and even zend admitted that the language has so many pitfalls that it is hard to write secure php code.
<darix> anyway
<darix> as long as they dont want to run php on my servers i am fine.
<darix> my last 2-3 people who came to me "we want wordpress" got a "you will use nanoc and here is why"
<darix> ;)
<bobthecow> wordpress has one of the most accessible admin interfaces of any open source project.
<bobthecow> the code leaves something to be desired, but they do a solid job on making something that normal humans can use.
<bobthecow> unfortunately, nanoc isn't there yet :)
<darix> bobthecow: they came with "we want wordpress and we want to keep that site running as archive forever"
<darix> nothing i want to hear really
<darix> bobthecow: and they got along nicely with nanoc in the end
<bobthecow> IIRC there's a static caching plugin for wordpress that would do the trick.
<darix> bobthecow: the last 2 years were nanoc already
<bobthecow> i've gotten less dogmatic about things in my old age :P
<bobthecow> my nanoc site generates two php files :)
<ddfreyne> mystonline.com is also a nanoc site but contains some PHP files
<ddfreyne> I am not sure whether they are still using nanoc though. I have the feeling they're simply editing the static generated pages...
<bobthecow> eesh. really?
alerante has quit [Ping timeout: 240 seconds]
<darix> bobthecow: i am pragmatic too.
<darix> e.g. i had one project where we installed a VM to run wp for them
<darix> i always told them "for that bit use nanoc"
<darix> and they rejected
<darix> a few months later they migrated to github pages.
<ddfreyne> bobthecow: read-write data source (as opposted to read-only) would make web interfaces a lot easier to write too, I guess
<bobthecow> ddfreyne: yep yep.
<darix> ddfreyne: git push trigger or cronjob do a fine job too.
<ddfreyne> bobthecow: Also, nanoc should be able to write generated files directly to a database, a filesystem, the network... etc. So that should be decoupled too
<darix> ddfreyne: or memcached
<darix> ^^
<bobthecow> ddfreyne: leave that up to the data source.
<bobthecow> oh, generated == compiled.
<ddfreyne> bobthecow: yes, compiled
<bobthecow> i thought you were referring to the "write" half of read-write data sources.
<darix> then you can use the lighty module to serve directly from memcached
<darix> nginx has something like that too if i recall correctly
<bobthecow> darix: or set up a read-through memcache instance.
<bobthecow> since memcached prunes LRU stuff sometimes :)
<bobthecow> would suck to compile your site and have bits of it disappear.
<ddfreyne> darix: Yeah, that would be cool. Parallel output mechanism would be necessary then though, which makes things a bit more complicated
<darix> bobthecow: just have enough memory ;D
<darix> ddfreyne: s/output/storage/
<bobthecow> darix: it turns out that nginx backed by a hard drive is absurdly performant anyway, once it's tuned.
<darix> bobthecow: so is lighty! :p
<darix> bobthecow: and if you have enough memory just stuff your page on tmpfs and zooooooooooooooooooooooom
<ddfreyne> You have other things to worry about than lighttpd vs nginx if you are hitting the limits when serving static pages ;)
<darix> ddfreyne: well depends
<darix> but yeah
<darix> it was mostly stupid design decisions in the setup
<darix> like serving from nfs
<bobthecow> oh.
<bobthecow> yeah.
<bobthecow> throw a varnish in front of it and nobody will ever notice :)
<darix> ugh
bghost has quit [Ping timeout: 245 seconds]
alerante has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
pavelkunc has quit [Quit: Leaving.]
<smkelly> ugh serving web from nfs :/
<smkelly> that is a disaster waiting to happen