Uninteresting: "Use my blog platform! It has the power of node!"
Interesting: "I wrote something new in a way or with tools that I had not used before. Here's what worked, here's what didn't, and here's what I learned."
Unfortunately, this is the former. I'd be interested in reading the latter if you wrote something up about your experience with this.
Pelican, Specter, Silvrback...I'm starting to get really confused. Is building your own blogging engine the new rite of passage for the web age, supplanting the practice of building your own text editor?
Is it okay if I keep writing post in HTML, rather than REST? Or am I missing out on some awesome set of features? I'd love to know if anyone actually converted to one of these platforms and found themselves writing more. I definitely have some trouble finishing the posts that I start, but I get the distinct impression that using one of these would be akin to getting a gym membership: if I'm not finishing blog posts now I won't magically start finishing blog posts just because of this new tool.
Oh look another great free tool and another senseless comment that tries to knock it for no reason. You're just writing over-generalized nonsense for the sake of it, most of which doesn't even make sense...
> Is it okay if I keep writing post in HTML, rather than REST?
I switched to a static site generator from Posterous when it was acquired (and ultimately shut down), and I definitely do find myself writing more posts on the blog. Writing a post is as easy as creating a new markdown file, writing in it, then `middleman build`, `git commit -a` and `git push` (which I could definitely automate further).
Of course, I probably consider this workflow easier because as a developer I'm already perfectly comfortable with git, and with working with source files. I can just open a terminal and type `vim /path/to/blog/new-post.markdown` and start writing. I find Wordpress slow, fiddly and limiting by contrast.
I'm not uncomfortable making the extended inference that most who prefer markdown for posting are at least very computer-literate and quite possibly software developers. I tried to sell my wife (a writer) on markdown and she didn't get it at all.
Well, it's up to you to use your own gym membership. If you sign up and don't use your membership, that is ultimately your problem. These new blogging platforms are like different gyms you can sign up for. Whether you exercise or not, at least do it at a gym you like.
I think it's nice to see a variety of self-made blogging platforms come around. Not only do we bloggers get our pick of the litter but it shows how some languages/frameworks work in creating something conventional like a blog. I agree that is seems to have become some sort of rite of passage.
I realise you're being snarky, but of course it is. Do what makes you happy. For an increasing (but numerically very small) amount of people, building their own service is what makes them happy.
In terms of awesome features - well yes. There are tons and tons and tons that are available from pages dynamically generated by a server-side program that would be a real pain to produce on manually updating HTML pages.
Actually, the todo list is the new blogging engine. Writing a blogging engine as a way to learn a new language has been around since at least the early days of Rails. I remember doing that tutorial back in ~2004.
I set it up just now, and it was very easy to get moving. I'm no ops master, but it only took a few minutes, and it's a bit nicer than the homerolled solution I had been using. My writeup is on my new blog at http://nevinera.net/trying-out-specter
>Specter takes the elegant/lazy approach of not using sessions at all - access to edit and create pages is entirely via url, and permission to actually perform those changes is granted by including a 'secret' (a password) in the form. It's not the most secure form of defense (I'm not using ssl, so a wireless sniffer could easily determine my password, for example), but its sufficient for a nonprofessional.
Is there something that I can do to make it more secure but still follow the lazy approach. I am asking cause I use heroku which is not secure as well.
I believe the standard approach is to hash the password in the browser and submit the hash for comparison - then if somebody observes the transaction they will only have gained access to the blog, and not everything with which it shares a password.
On the other side, it is typically better not to store the password on the server either. You could accomplish that by giving a utility to store a hash in a file, but that's a bit heavy I guess.
I meant for a nonprofessional /blogger/, incidentally, not a nonprofessional coder :-)
It looks like the actual best answer is to use ssl - apparently most apps transmit their password in the clear, and just rely on ssl to keep it from being observed. I'll amend my post.
You mean the the themes? Well I just added them to demonstrate that all you need to is change the css from boostrap to bootswatch in order to change the theme.
The most important one to me is not using PHP (THEshittiest programming language ever) and being built upon NodeJS. Also, look at my answer below about the security aspect of it.
Smallish subset here perhaps but then HN is not representative of the wider programming community.
I for one think JavaScript is an utterly hideous language full of all kinds of gotchas and abortions and that the only reason it has any relevance is it got their first.
With WordPress, there's always the possibility of your blog being hacked, because it executes queries and there's always the chance for bugs to exist some where in the huge ocean of code.
On the other hand, with static blog generators (like specter, octopress, pelican, etc) your generated blog will be static html and as far as I know, there's no way you can really question html's security, simply because security doesn't apply to it. You cannot attack html because it doesn't run queries or anything, it's just static data being pulled from the server and displayed by the browser. So, in the end, the security goes back to your host and how good the machines are configured (when you're using shared hosts).
Compared to WordPress, you definitely do; but think about it, there's lots of stuff in WordPress that a blogger doesn't need. WordPress is not just a blogging platform [anymore]. However, on the other hand, by using static sites you're entering a whole new level of security. But don't fear, for commenting, there's Disqus which is pretty good, and I think it's built into specter as well! Even if not so, adding it is just copying and pasting a couple of lines of code :)
Nah, just use Disqus for your comments. Octopress includes this by default, probably others as well.
I've been using static blogging for about a year now, it's great. Fast, simple, miss nothing from Blogger or Posterous, don't know about Wordpress never used it, and all your content is stored in your own Github repository.
Commenting is a pretty big part of the blogging community. I'd hope it would be included in any blogging platform. But then again there are outside sources like disqus for comments so you can bolt that onto your posts if you feel inclined.
Static engines:
* Do one thing _good_ (i.e. blog)
* Fewer lines of code, which means:
* Easier to maintain
* Easier to read
* Easier to customize using small chunks of raw code
Dynamic engines:
* Do many things (i.e. having multiple authors, multiple formats, visual editors, plugins, etc.)
* Many more (as in x^5) lines of code, which means:
* * Harder to maintain
* * Easier to use for _non programmers_
* * Easy to customize SOME things (apply a theme), HARD to customize the whole thing properly (you need to read huge chunks of code that might break if you change them)
--
The above reasons make Wordpress pretty much insecure compared to a Static website (i.e. Jekyll engine like octopress). Of course you could have a bloated wordpress websites where all it's plugins are revised and secure while you could have a static website where it's running buggy JavaScript which reveals your IP to the NSA (random example pick) but the % of having a bug in a bigger (in terms of lines of code) app is way higher.
It's not built-in out of the box, so you gotta ask the developer about it. But you should be able to easily use it by adding the js files to your header.
Just deployed it for an internal work blog (just happened to see this particular post at the right time), and I love new projects so I'll use it for awhile and see what I see.
Obviously it'd be "nice" to have some better contributor management, and instead of forcing me to manipulate the URL to do stuff it'd be "nice" to just click buttons, but frankly I don't care much about any of that.
Real feature request: Language specific syntax highlighting for the code bits. I'd like my snippets to come with highlighting as I explain stuff. JavaScript, Python, C, HTML to start, if you have to pick some languages. :)
Also I notice at the bottom of your blog an rrs and atom feed set of links. any plans on implementing that globally?
Ah, noticed the feed paths after I posted, thanks.
As for syntax highlighting yeah, I'm sure it's just a matter of a library, but you know, it's your project! Sometimes people are looking for stuff to add, just wanted to point out a place I'd find useful. :)
I'm sorry. My initial reaction to that was harsh and childish. I wish you the best of luck with your project, and if I can do anything to help please let me know.
If people keep making them, clearly existing solutions aren't quite getting it right, otherwise no one would bother.
> and a .io domain
And that's just Github's domain... Furthermore, Google is currently treating .io as a generic TLD. Considering the exhaustion of .com and .net addresses, is it any surprise that people have adopted another one en masse?
Interesting: "I wrote something new in a way or with tools that I had not used before. Here's what worked, here's what didn't, and here's what I learned."
Unfortunately, this is the former. I'd be interested in reading the latter if you wrote something up about your experience with this.