First of all, kudos to the OP for his work on Octopress...without it, I would've never gotten into Jekyll, and I would've never understood the joy and simplicity of static site development...trying out Octopress was one of the best things to happen to me as a (Rails) web developer.
The most surprising thing to me in the OP was seeing that Octopress users had been updating their sites all this time...I frequently checked back on the Octopress blog, and then the Git repo, to see how to go about doing that. I tinkered around playing with the dev branches but didn't know enough to get around their hiccups. Finally I gave up on it and just went to Jekyll, which was definitely a blessing in disguise, as it let me figure out more of the process of static site building, with fewer abstractions and conveniences in the way.
I don't know if I'll ever go back to Octopress -- I'm a devout Middleman user now -- but the direction it's taking seems to be the right one, and I'm amazed that the author, these past few years, is still cranking away at what could easily just be a legacy, soul-sucking project -- given the size of the userbase and the number of dependencies/upgrades involved in changing the code base.
Thanks for your story. I've heard that from so many people. That Octopress opened doors for them and exposed them to new interests. It's pretty much the best thing I could ask to hear. I love that I was able to be a part of that spark for people. So, thanks for sharing!
For what it's worth, I'm also a huge fan of Middleman. It's a great project and I use it for some things too. For a while, when Jekyll was in a dry spell, I considered building Octopress tools for Middleman as well, but in the end I prefer the simplicity of Jekyll.
Middleman is great, but it's too much like the view layer of Rails. To me, Jekyll feels more like the native web.
Looks awesome. Now if there was a clean way to do incremental rebuilds and pushes, I would be very happy. Octopress is awesome until you start to accumulate hundreds or thousands of posts that must be regenerated and pushed to the target. The regeneration process is intrinsically serial at this point and does not take advantage of multiple threads or processes.
I have my own little blogging engine based on https://github.com/debrouwere/render and what I've found is that the bottleneck is almost always IO. Rendering templates is so fast it simply does not matter whether you run it on a gazillion cores or not. Getting data from disk and then writing it to disk means you're dealing with contention, where parallelizing stuff can actually make it slower. So it can actually make sense to do all of this serially.
But of course, that doesn't mean you can't do incremental rebuilds. If the data is older than both the HTML and the template, then there's no need to rerender. More generators should support this, either internally or by making it easier to run them as part of a Make build.
I love the whole idea of static site generators. Jekyll, Middleman, etc. They're hard things to "hand-off" to a client. I'd love to see more work going into an interface for content managers (make it easy for them to update basic settings, add content, etc.). Prose, and Siteleaf get at this a bit.
NetObjects Fusion had some interesting features and ideas. My first non-intern job was with a company that did e-Learning materials. Our products were basically self-contained websites, with video content and scripted subtitled text, distributed on CDs. This was 2002 or so, so it was super bleeding edge then.
Our entire infrastructure relied on the extensive scriptability and plugability of NetObjects Fusion. We had an entire authoring system and video production pipeline that would allow NetObjects to generate pages for the videos with templates, all things needed included. All you had to do was drag the video player into the page and set the right property, and our build system would handle everything else.
The process was so automated on the technical side that it allowed the task of actually assembling the sites themselves to be farmed out to University students with little technical training. Although, speaking as someone who was initially hired as one of those "production workers," we were paid very well relative to other traditional college jobs and the work, while sometimes tedious, was often interesting and fun. I got to learn so many random things - how tires are made, how the propellant for the Space Shuttle's SRBs was mixed, etc.
Even now, I can still, a bit fondly, remember the hierarchical layout of NetObjects, with it's little yellow and black shields representing pages.
It was also a great company to work for. The owner was a business professor full time and this was his side project. We were always small, and him and his wife always took an interest in all the students that worked for them. Getting a home-cooked meal and a night of poker once a week was a nice perk for a poor college student.
The cool thing, though, was there was no pressure to stay. They knew we were students, they knew we were going to graduate eventually and take jobs elsewhere. It was a mutually beneficial scenario where they got relatively cheap labor (at the time), and we got good experience before heading out into the world.
I ended up staying on there for another 3 months or so after I graduated before taking my first full-time programming job. A big part of me landing that first post-college job was due to experienced I gained working in that environment. First as a lowly production worker, then advancing to graphic design, administering the network and programming plugins and scripting for NetObjects.
So I suppose my career would probably look very different without NetObjects Fusion.
Cool story, didn't know about the automation and scriptability. I wonder how many customers are still using NetObjects Fusion today, e.g. how well it has kept up with changes in the browser landscape.
Edit: was a browser included on the CDs? Today, one could bundle a portable-apps version of Firefox, increasing the likelihood of the content remaining readable, without needing external plugins for video.
It's been awhile so I don't remember the full specifics, but it was bundled with a specially configured version of Internet Explorer in a mode much like kiosk mode, but even more locked down. No right click menu, navigation, etc. Just basically a full-screen browser with no chrome. Administrators had to hit a special key sequence to exit.
Webhook (http://www.webhook.com/) is something you might be interested in. It's a static site generator that includes an admin interface. When the client changes something in the CMS, the generator is re-run and the site deployed automatically.
There have been people over the years who've been eager to build a GUI for Octopress. Without a good CLI it would be a huge pain. Many of the things I've been working on, should make it easier for that to happen.
Looks amazing! Huge fan of Octopress, but I'm looking to turn my blog multi-language and the way Octopress is currently set-up makes it a bit of a pain, but it looks like it will be quite a bit easier for anyone to make an Internationalization plugin for Octopress 3.0. Is anyone working on one currently?
There are people who use Jekyll for multilingual blogging without any special plugin. Since I don't, I'm not sure I can give you advice on the best technique. A bit of Googling and you'll be set.
If you find a workflow that works for you, post an issue on GitHub and maybe I can help automate parts of it. If it's just about adding YAML data, the new post templates feature of Octopress should take care of you there.
I looked at Hexo, Assemble, Wintersmith, Docpad, Metalsmith, and many others. I wanted flexibility to restructure as I saw fit and easily add structures other than just blogs. I tried docpad but it struck me as too "tell you how it's gonna be", even setting your front end template. Metalsmith (http://www.metalsmith.io/) was a great solution to that. It's a lot like using Gulp and Express' middleware plugins. I liked that I could completely customize the build pipeline to get exactly what I wanted. There's also a way to do your build pipeline with config files, if that's your cup of tea.
Been using octopress for a little over a year now, and this post sums up everything thats been a pain in the ass for me when it comes to upgrades/customization/etc.
I hope, however, that the author gives some thought to being able to freeze content, perhaps at the plugin level. I would hate to use a plugin, generate output, and find that at some point in the future, when the gem hasn't been maintained, the rest of my site suffers because I'm no longer able to mix current code with a plugin used at some point in the past. It would be great if I could have some sort of 'freeze' functionality that would take all the plugin level output as it exists today, lock it down, and update the rest of the site without having that plugin installed any more.
I look at GitHub issues and I'm just afraid to mess with things. Even if I fix stuff, there's a high likelihood that it will break something else or be hard to update to. I too cannot wait to release this.
Talk about bad timing, I just moved from Octopress to vanilla Jekyll yesterday. The only thing I really miss from Octopress is the CLI for generating new posts and it seems I'll be able to use it again, yay. http://prose.io/ is also an interesting project for editing posts.
Not sure why you'd say "bad timing". Moving to Vanilla Jekyll is the right decision. You'll be able to use any and all of the new plugins. There's no distinction anymore.
Hmm thank you for the story and the awesome work. Though I use DocPad right now Octopress / Jekyll is a great as well. And maybe we have room for another static site generator....The one I am working on :)
The most surprising thing to me in the OP was seeing that Octopress users had been updating their sites all this time...I frequently checked back on the Octopress blog, and then the Git repo, to see how to go about doing that. I tinkered around playing with the dev branches but didn't know enough to get around their hiccups. Finally I gave up on it and just went to Jekyll, which was definitely a blessing in disguise, as it let me figure out more of the process of static site building, with fewer abstractions and conveniences in the way.
I don't know if I'll ever go back to Octopress -- I'm a devout Middleman user now -- but the direction it's taking seems to be the right one, and I'm amazed that the author, these past few years, is still cranking away at what could easily just be a legacy, soul-sucking project -- given the size of the userbase and the number of dependencies/upgrades involved in changing the code base.