(NOTE: "Simple" is not my project)
It allows you to create entries in ReStruturedText using a text editor. I designed it with Heroku in mind, but can be easily adapted for any Web environment that uses Git.
When you push to Heroku, the entry metadata will be automatically saved to Neo4j, and the HTML fragment generated from the ReStructuredText source file will be served off disk.
You can use the free Heroku dyno and Neo4j Add-on (https://addons.heroku.com/neo4j) to serve your blog for free.
I wanted the benefits of a dynamic app, but I wasn't willing to exchange Emacs for a Web-based editor so I created a hybrid engine.
I chose Neo4j because graphs are an elegant way of storing relational data. There are no tables to mess with and no joins (everything is explicitly joined). And if your blog's auth/commenting system uses data from the social graph, such as Facebook or Twitter, a graph database provides a clean way of storing the data.
Also, I am the author of Bulbs (https://github.com/espeed/bulbs), a graph-database framework written in Python, so using it was a natural choice.
As opposed to, say, a Relational DBMS?
What you've done might be very interesting and rewarding to you, but it feels like you wasted three paragraphs in your response with something that falls right into the "just because I could" camp.
Neo4j is neat and underutilized. I think rglullis is just saying, if that's why espeed used it, he could have saved three paragraphs of explanation by just saying that.
I find elegance in simplicity. If you don't need the tabular features of a relational database, why not use a graph DB for relational data? It's like a key value store with directly connected relationships.
This is so much simpler than having to deal with creating tables, DDLs, and migrations:
>>> g = Graph()
>>> james = g.vertices.create(name="James")
>>> julie = g.vertices.create(name="Julie")
>>> g.edges.create(james, "knows", julie)
But regardless, this is Hacker News where people explore, build, and share new things. I hope we're not moving to a place where that gets admonished.
* Nodes/Vertices: Person, Topic, Entry
* Relationships/Edges: Tagged, Authored
person -- authored --> entry
entry -- tagged --> topic
The comment system is a separate, generic component.
Marko, the guy who created Gremlin (https://github.com/tinkerpop/gremlin/wiki), just released a Gremlin Tree step (https://github.com/tinkerpop/gremlin/wiki/Tree-Pattern), which makes it really easy to build a threaded comment tree in one quick shot.
If you have a large blog or content system, you can use likes and views to make content recommendations using a basic Gremlin collaborative filtering query:
// calculate basic collaborative filtering for vertex with user_id
def rank_items(user_id) {
m = [:]
g.v(user_id).out('likes').in('likes').out('likes').groupCount(m)
m.sort{a,b -> a.value <=> b.value}
return m.values()
}
Simple/Obtvse should be an interface for adding posts and editing existing posts. Similarly, a command-line-interface can also be used for adding posts. (`newidea "I want a castle made of marshmellows"`)
The site is stored in a database when live, but the database can be transformed one-to-one into a directory of human-readable Markdown or ReStructuredText files.
Rendering is handled by a separate component, e.g. nanoc or jekyll. The important thing is that the site database can easily be mapped to a human readable format. The advantage of this approach is that it is easy to write a modular rendering engine without mucking with the specifics of the CMS.
For example, I want to automagically categorize posts in a taxonomy, find related posts, group posts that are lists, etc. using some NLP wizardry. I would much rather write this application for a directory of human-readable files, adding metadata fields to text files, than paint myself into a corner with a particular CMS.
Please email me if you are interested.
The thing I like about static generators is that I don't have to worry about a programming language being present on my hosting site (http://funcptr.net is blogofile, http://bertjwregeer.com/ is Poole.py[2]) and the overhead is a lot smaller, since all I have is static files there is a lot less worry about accidentally causing CPU spikes, or a database being overloaded, and using sendfile() one can very quickly and efficiently serve up HTML files to clients.
[1]: http://www.blogofile.com/ [2]: https://bitbucket.org/obensonne/poole/overview
wget -m -k -nH <your URL here>
But, with the feature you request, then, it doesn't really work for a static site generator. It is better to use normal caching with a dynamic site like how Simple is doing now.
So basically just a UI for writing and managing the posts that sits on top of Jekyll.
I'd be curious to see how a "Blogger of today" would fare if it also had Dropbox integration, so you could use specialized local apps like IA Writer if you wanted to but also still write or edit on the go without your main machine.
To do the same thing with the cache in a Rails app, I'd probably have to make a script to visit every page to get it to render to the cache, then copy the cache out. At that point, it'd probably be easier to ignore Rails' built-in caching and just to make a rake task that renders everything.