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
<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 :)