GitHub is one commit away from being the ultimate blog engine
reefpoints.dockyard.com
I just realized the title might sound like I'm putting down GitHub, that's not the point. I love GitHub.
reefpoints.dockyard.com
Some people argue that adding a dynamic commenting system contradicts the static html goal of Jekyll. Going along those lines, critics say that a conversation is best carried out on 3rd party sites like HN. However, for technical blog posts specifically, a two-way conversation helps illuminate finer points in the original blog post.
Googling around for 'jekyll comments' or 'disqus open source alternative' reveals many people who would use such an idea. However, aside from some quick-and-dirty projects, I see no compelling open source alternative to disqus that will include features such as OpenId, spam prevention, comment threads, etc. Does anyone know of such a project?
That sounds interesting.
My next question is: Does Disqus's API let me do this via... Disqus? Surfing through the API docs suggests that the answer may be "yes".
Or you could just have a comment link that uses the github website comments - if you are really interested in technical discussion it's probably fair to assume the poster has a github account
Do you know to what degree they are slowed down? I am observing that they load particularly fast (< 1 second) on this blog post.
Disqus doesn't slow down page load times because we use a non-blocking technique to load required files. We work hard to make sure that we don't add any performance regressions to sites using Disqus.
We are also working on making comments made via our product indexable by search engines.
As for the open source version of Disqus, I am not sure what you mean by that since Disqus is a service and not a program that you can download and install. People prefer Disqus because they don't want to spend time implementing and hosting discussion platforms for their websites just like people using GitHub don't want to spend time implementing and hosting developer collaboration software.
Anton
P.S. If you are having problems with Disqus slowing down your page, email me at anton@disqus.com and I will check it out.
We give site owners a hassle-free discussion platform that can be integrated into their websites with additional perks such as moderation tools, analytics, spam filters (trained on the whole network of websites and not just one) and others.
And people leaving comments on different websites are now able to manage and control their comments across the web, and use their Twitter/Facebook/Google accounts knowing that Disqus will never abuse their trust. Boxed software installed on different sites managed by different people would likely never be able to provide neither the integration nor the trust.
But don't get me wrong, we absolutely love open source. Check out our Code page[1] or our public account on GitHub[2]. We released many different projects, some of which are adored by the Python/Django community (e.g. Django Sentry). I think Disqus as a product is better when it is a service and not a boxed software.
Anton
[1] — http://code.disqus.com/code/ [2] — https://github.com/disqus/
Also.. uh.. This is kind of unrelated but you kind of abused my trust. I wanted to post an anonymous comment and thought I needed to provide an account for spam reasons, so I logged in, left my username blank, and it automatically put my first name in as the author of the post. I have tried to avoid your stuff since. I think other people were posting things anonymously so it might have just been my fault. Still though, I'm done with it.
Now that I go back to it, I see that it links to my twitter account and provides my first name. I was thinking that just showing my first name would only be kind of bad, turns out I was remembering it incorrectly. It is as bad as I thought it was.
1.) Control of data, I am not sure what rights I am legally signing away to Disqus when using it as my comment service.
2.) Continuity, I am certain that if Disqus passes away the service won't be there and only fools would offer a free service and ensure that the data isn't lost for what ever reason. How are your data liberation policies, a simple click for a zip or a tar-ball? Or would I need to construct my own back-up using your API? If the latter, is that allowed?
Nothing changes when you comment on a website using Disqus—your comment is published on someone's website and becomes their data. That said, if a comment was not originally anonymous, you have an option to anonymize it so that it is not associated with your profile and name anymore. We are and will always be on commenters' side.
This is what I can authoritatively say as a Disqus engineer. If you want more information, email to hello@disqus.com and folks here will be happy to answer all your questions.
Anton
For a developer, making your own Disqus is actually easy. And I have done so myself, with free hosting on top of Google's App Engine ...
http://alexn.org/TheBuzzEngine/ + https://github.com/alexandru/TheBuzzEngine
Don't expect the same polish as Disqus. This is meant for my usage mostly and I have simple needs.
My idea was a little bit different: I would drop in a single file to my Jekyll repo that adds a "Create a new post" page on my blog. There is a text field with a live markdown preview and a "Commit" button that would make the calls (via javascript) to the Github API to create a new commit in the repository. This commit triggers the hooks that rebuild the blog.
The main hurdle was authentication, since Github OAuth doesn't support any client-side flows (which is understandable since it's not a completed spec, to my knowledge). So I would have to pass my user/pass in everytime.
But I got the API calls all working (after Github support helped me get CORS working), but I lost interest in the project and it's just sitting around collecting dust
The code: https://github.com/swanson/lanyon/tree/gh-pages
Demo that doesn't quite work: http://swanson.github.com/lanyon/
There's another good use-case, which I've suggested to them: Their "We recommend adding a README..." message could just link to a markdown editor, making it really easy to put up some documentation.
Already there are things like TiddlyWiki and DropPages that do this and it's much more approachable for the average user.
I also think as DropBox teams improves and iterates it will be interesting to see more people using Dropbox for basic version control, probably not a good idea but I think it'll happen.
It was discussed on his podcast (Build and Analyze), don't think he's published it though.
The first thing I did was edit my profile, but I found that it doesn't give me enough feedback about errors. I tried changing everything all at once(of course) and then got greeted with the previous defaults. It took some trial and error to figure out that it wasn't accepting the RGBA PNG I had picked out for a profile picture. I'd also like a direct link to the markdown formatting docs, or even just a quick summary, on the profile editing screen.
My profile finished, I proceeded to look in my Dropbox folder. The README is not formatted for Windows Notepad and appears as one long line of text. I switched to NP++ and continued to write a "hello.txt" containing a link and an image. It shows up, so I go back and edit the README, too. Everything is in order, but what is this "cloud+arrow" button? Inspecting it reveals it's publishing, but I don't feel confident about whether I've published hello.txt until I log out and check.
I might continue using this. Some last thoughts:
I will probably want options to organize posts. There isn't enough documentation to know if I already have them.
I found myself wondering if there was a shortcut for marking up the image that would let me point to a folder inside Dropbox without tabbing out to find the public link.
I may not want the displayed title of README to be README.
- You're absolutely right, we definitely need more error feedback.
- We're planning on writing a Markdown tutorial on site and building a browser-based editor (based on Ace, most likely). Will take this under advisement.
- I need to test with more variety of profile images. I held back on doing this until I could abstract away the entire image handling code.
- We wrote all the text files on a Mac so we're probably seeing some problems with Windows vs. *nix line-endings. I'll address this tomorrow.
- You're not the first person to be confused about how we're handling publishing, so we'll address this in a UI update.
- In terms of publishing images, we want to be able to process more than just text files in your Dropbox, so eventually you'll be able to relatively link to images instead of having to host them somewhere else. Our browser-based editor will let you browse your Dropbox and select images.
- We do support custom titles (and summaries) using the MultiMarkdown formatting syntax. Just make the first line of your text file look like this:
Title: The title I want
Summary: A summary of my text file
---
Again, thanks for the feedback and I hope you can give it another go once we make a few tweaks. I really appreciate you input.
I think he's just asking for the ability to create a new file from scratch in github's web interface.
What might actually happen is that Git or Dropbox become the interface through which we “put files on the web”. One’s blog is just a subset of files that one is maintaining anyway.
That’s nice, and a consolidation of tools. But not, um, advanced.
So while it is just serving static files, it's static files pre-processed by Jekyll.
What might actually happen is that Git or Dropbox become the interface
through which we “put files on the web”.
Again, it's still very early and this is more to prove that the idea is doable, but we'd love to hear any input. We're working on some commonly requested features like customized designs, cname redirection, rss feeds. The idea is to have a very hacker friendly publishing tool that doesn't require very much work to set up.
[1] http://tom.preston-werner.com/2008/11/17/blogging-like-a-hac...
I would die to find a gaggle of people who want to work with me on a simple CMS on top of Git.
As paleolithic as it sounds, I think a CMS build on flat files would be a lot easier to manage than a CMS built on a relational data store.
If you don't need accounts and personalization, or can just do that all client side, you could simply load balance across micro AWS instances pulling from the git repo and stick everything behind Cloudfront -- all for a few quarters an hour.
Nevertheless I think the concept has potential if done right (and with Github or Dropbox).
This should be done.