Setting up your own blog(james-huang.github.io)
james-huang.github.io
Setting up your own blog
http://james-huang.github.io/programming/2015/07/19/setting-up-your-own-blog/
22 comments
> Git is ugly and best hidden underneath GUIs
I guess I'm one of those 'very few', because every GUI and frontend I've used that tries to hide what's going on underneath has been far more cumbersome to use than the command line.
The only thing I'll use a Git GUI for is to check the history/revision graph.
I guess I'm one of those 'very few', because every GUI and frontend I've used that tries to hide what's going on underneath has been far more cumbersome to use than the command line.
The only thing I'll use a Git GUI for is to check the history/revision graph.
The HN "random" sample of git users is also very skewed towards the git power users. Here is some usability research from Google et al about VCS usage:
https://static.googleusercontent.com/media/research.google.c...
https://static.googleusercontent.com/media/research.google.c...
Git GUIs terrify me. On the command line, I know exactly what was run and how to get back to a known good state if I muck it up (or at least where to start googling for the undo!). I have no clue what some GUI is running behind the scenes when I click some theoretically innocuous button.
Or at least that is how I felt when I was a beginner to git. Now I'm confident that I could fix anything a GUI screwed up but the command line is just easier and faster for me.
Or at least that is how I felt when I was a beginner to git. Now I'm confident that I could fix anything a GUI screwed up but the command line is just easier and faster for me.
Very few of the thousands or millions of git users know more than basic usage and most do not rely on the CLI.
I'd be interested to know where you get these numbers, as this doesn't match my observations at all. I generally see people move quite quickly from a GUI to the command line.
I'd be interested to know where you get these numbers, as this doesn't match my observations at all. I generally see people move quite quickly from a GUI to the command line.
I don't think a study on this specific point exists, but here are some Drake-equation-like ways to estimate this.
Microsoft estimates tha there are 8 million .NET users in 2012:
http://www.quora.com/How-many-NET-developers-are-there
Let's say the number is in the same range today (I don't see a reason why the number of Windows developers would have drastically grown or dropped since then), and let's add a couple more million Windows developers who do not use .NET. Total, 10 million Windows developers. Let us say, half of all Windows use git for source control (non-git usage is still huge in private corporations). I am probably underestimating here. So, very roughly, that's about 5 million git users on windows.
Let us also estimate that 90% of all Windows users never use a CLI. I have personally met very few Windows developers who do. Windows is very much anti-CLI. So that's 4.5 million git users who do not use a CLI and 0.5 million Windows users who do.
For Mac OS X, we know that there were 1.2 million apps last year, let's say that there are, I don't know, three developers per app on average:
http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-...
Since Apple steers developers to use Xcode and Xcode has git integration, let's say half of all Apple-based developers do not use the git CLI regularly. We shall assume that Apple-based developers are a bit more familiar with a CLI than Windows users. So this is 1.5 million Apple users who use git without a CLI and 1.5 million who do. That's a total so far of 2 million CLI git users and 6.5 non-CLI git users.
Finally, let us say that nearly every git user has a github account. Let's say, 25% of them don't. Github has reported 3 million users in 2013:
http://thenextweb.com/insider/2013/04/11/code-sharing-site-g...
http://redmonk.com/dberkholz/2013/01/21/github-will-hit-5-mi...
Exponential growth suggests it should be around 5 or 6 million now, and if 25% of all git users do not use github, that roughly matches my estimates for how many of them are spread out across Windows and Apple.
So yeah. I am very confident that most git users do not use the CLI, at least not regularly. I am almost certain that of those git users who primarily use a git frontend, they only ever drop down into the command line when they need to do something very specific and they google that specific thing and copy around the magic git incantation that they find.
I know you can wiggle these numbers around a lot. But I also think we forget how big the non-HN developer crowd is, and how large the number is of people who are averse to a CLI.
Microsoft estimates tha there are 8 million .NET users in 2012:
http://www.quora.com/How-many-NET-developers-are-there
Let's say the number is in the same range today (I don't see a reason why the number of Windows developers would have drastically grown or dropped since then), and let's add a couple more million Windows developers who do not use .NET. Total, 10 million Windows developers. Let us say, half of all Windows use git for source control (non-git usage is still huge in private corporations). I am probably underestimating here. So, very roughly, that's about 5 million git users on windows.
Let us also estimate that 90% of all Windows users never use a CLI. I have personally met very few Windows developers who do. Windows is very much anti-CLI. So that's 4.5 million git users who do not use a CLI and 0.5 million Windows users who do.
For Mac OS X, we know that there were 1.2 million apps last year, let's say that there are, I don't know, three developers per app on average:
http://techcrunch.com/2014/06/02/itunes-app-store-now-has-1-...
Since Apple steers developers to use Xcode and Xcode has git integration, let's say half of all Apple-based developers do not use the git CLI regularly. We shall assume that Apple-based developers are a bit more familiar with a CLI than Windows users. So this is 1.5 million Apple users who use git without a CLI and 1.5 million who do. That's a total so far of 2 million CLI git users and 6.5 non-CLI git users.
Finally, let us say that nearly every git user has a github account. Let's say, 25% of them don't. Github has reported 3 million users in 2013:
http://thenextweb.com/insider/2013/04/11/code-sharing-site-g...
http://redmonk.com/dberkholz/2013/01/21/github-will-hit-5-mi...
Exponential growth suggests it should be around 5 or 6 million now, and if 25% of all git users do not use github, that roughly matches my estimates for how many of them are spread out across Windows and Apple.
So yeah. I am very confident that most git users do not use the CLI, at least not regularly. I am almost certain that of those git users who primarily use a git frontend, they only ever drop down into the command line when they need to do something very specific and they google that specific thing and copy around the magic git incantation that they find.
I know you can wiggle these numbers around a lot. But I also think we forget how big the non-HN developer crowd is, and how large the number is of people who are averse to a CLI.
On the topic of git...
For the first 6 months I used git, which was because I started a new job where it was used, I stuck almost exclusively to a coworker's wiki page, "<name>'s git cheatsheet". I remember re-cloning the repo so many times when chances are there was a way I could have fixed the mess I'd created.
I didn't know what I was doing and it was very complicated. It had a steep learning curve.
Now, some six years later, I still only use a handful of commands regularly, but really, aside from the painful-to-read man pages (they are very clear, but contain so many flags and other tidbits), I find it very simple to understand and to use. I rarely ever get confused. I'm not a big fan of `rebase` but I can see where it would have its purpose in merging feature branches back to the trunk/master (and if I can find a coworker using it in a nice, clear way, I might adopt it myself). I never use `--force` and recommend that everyone everywhere avoid it once they've pushed.
But really, and there may be some "survivor bias" involved here, I think it's a very well done system for what it does, and I am generally able to reason pretty clearly about what's going on and help others figure out what their issues are. It's quite possible that bzr/hg/darcs is a better and cleaner way of doing the same tasks, and I still have no idea about many commands and I am sure there are things that I have glossed over thinking that I understand them... but it makes sense to me; I don't like any of the GUIs (though I tend to like to "live" in the terminal as much as possible, I've seen things I don't like in both Tower and Sourcetree), and it just seems right to me.
Sorry to go off on a tangent there...
For the first 6 months I used git, which was because I started a new job where it was used, I stuck almost exclusively to a coworker's wiki page, "<name>'s git cheatsheet". I remember re-cloning the repo so many times when chances are there was a way I could have fixed the mess I'd created.
I didn't know what I was doing and it was very complicated. It had a steep learning curve.
Now, some six years later, I still only use a handful of commands regularly, but really, aside from the painful-to-read man pages (they are very clear, but contain so many flags and other tidbits), I find it very simple to understand and to use. I rarely ever get confused. I'm not a big fan of `rebase` but I can see where it would have its purpose in merging feature branches back to the trunk/master (and if I can find a coworker using it in a nice, clear way, I might adopt it myself). I never use `--force` and recommend that everyone everywhere avoid it once they've pushed.
But really, and there may be some "survivor bias" involved here, I think it's a very well done system for what it does, and I am generally able to reason pretty clearly about what's going on and help others figure out what their issues are. It's quite possible that bzr/hg/darcs is a better and cleaner way of doing the same tasks, and I still have no idea about many commands and I am sure there are things that I have glossed over thinking that I understand them... but it makes sense to me; I don't like any of the GUIs (though I tend to like to "live" in the terminal as much as possible, I've seen things I don't like in both Tower and Sourcetree), and it just seems right to me.
Sorry to go off on a tangent there...
Some people say you have to understand how git organizes its data internally to be able to use it. It was even more than that to me: the way git organizes its data internally is awesomely simple and powerful, and anything you want to do with git is just finding the right incantation. And when you find it, you don't really care how ugly it is, because you know how all things really are underneath and you find peace in knowing all is right.
when one knows a command line tool it often feels much better, much faster, much more powerful than any GUI command.
Do you use linux? (If not, that would explain it) Do you claim the same thing for all the other gnu tools (grep et al)?
Git might have some esoteric flags and commands at some points but is not ugly at all and, when understood, it really feels beautiful (and safe, oh so safe to use knowing I know how to recover from practically anything, git has my back).
edit: looking at your other response... using Windows devs who are unfamiliar with GUIs as a metric is not really a good point. If you're going to use Argumentum ad populum then bad programming practices are better than good practices.
Do you use linux? (If not, that would explain it) Do you claim the same thing for all the other gnu tools (grep et al)?
Git might have some esoteric flags and commands at some points but is not ugly at all and, when understood, it really feels beautiful (and safe, oh so safe to use knowing I know how to recover from practically anything, git has my back).
edit: looking at your other response... using Windows devs who are unfamiliar with GUIs as a metric is not really a good point. If you're going to use Argumentum ad populum then bad programming practices are better than good practices.
I'm hardly alone in thinking the git CLI is difficult to use. It is in fact one of the most frequently criticisms against git.
I think the best evidence for that is that there is no shortage of blog posts about how easy it is to learn git, and here, these are all the easy things you should do in order to learn git. If it's so easy, why is Git Explained its own genre of blog post? I can only think of Monads/Haskell Explained as another blog post in a similar genre.
It's not about how often we use it: for example, we probably use ls and cd a lot more than git, yet we don't write endless blog posts about how easy ls and cd are. If git really were that easy, it wouldn't need so much explaining.
I think the best evidence for that is that there is no shortage of blog posts about how easy it is to learn git, and here, these are all the easy things you should do in order to learn git. If it's so easy, why is Git Explained its own genre of blog post? I can only think of Monads/Haskell Explained as another blog post in a similar genre.
It's not about how often we use it: for example, we probably use ls and cd a lot more than git, yet we don't write endless blog posts about how easy ls and cd are. If git really were that easy, it wouldn't need so much explaining.
"If git really were that easy, it wouldn't need so much explaining."
Well, on one hand, I like the git cli better than guis, but on the other, I don't really disagree.
However, to your question: it might just be the case that it's an easy thing to explain, or an easy thing to learn, or made easier by writing... there are a lot of other possibilities than there is a big demand for these articles.
Well, on one hand, I like the git cli better than guis, but on the other, I don't really disagree.
However, to your question: it might just be the case that it's an easy thing to explain, or an easy thing to learn, or made easier by writing... there are a lot of other possibilities than there is a big demand for these articles.
It's funny because I fail to see the value of having a blog version controlled (maybe because I don't have a blog myself, but still).
We use version control because sometime we mess up, so we want to go back in the past and compare values of the same file at different points in time. I don't understand how this kind of problem ever arises when you have a blog: You never need to compare multiple versions of the same post, and if you use files, you always use a different file for each post.
We also use version control when we want to have parallel development (ie keep a stable, working master branch, and toy around in a dev branch). When you have a blog, you just use a _drafts folder that is configured so that what is inside is never published; when your post is ready you move it to the _public folder or whatever. Another worthless feature in that use case.
What _is_ useful from a version control, and more specifically from git, is its ability to replicate everywhere: push to your personal backup, push to github, ush to your webserver. It is used both as a backup and as a way to have your content be where you distribute files. But git is not the only option availale to sync content, and far from the only one. A HTTP POST is more common, and a Dropbox sync is even easier (you don't have anything to do, and the content is automatically synced and distributed for free by Dropbox)
We use version control because sometime we mess up, so we want to go back in the past and compare values of the same file at different points in time. I don't understand how this kind of problem ever arises when you have a blog: You never need to compare multiple versions of the same post, and if you use files, you always use a different file for each post.
We also use version control when we want to have parallel development (ie keep a stable, working master branch, and toy around in a dev branch). When you have a blog, you just use a _drafts folder that is configured so that what is inside is never published; when your post is ready you move it to the _public folder or whatever. Another worthless feature in that use case.
What _is_ useful from a version control, and more specifically from git, is its ability to replicate everywhere: push to your personal backup, push to github, ush to your webserver. It is used both as a backup and as a way to have your content be where you distribute files. But git is not the only option availale to sync content, and far from the only one. A HTTP POST is more common, and a Dropbox sync is even easier (you don't have anything to do, and the content is automatically synced and distributed for free by Dropbox)
Beautiful is way overused. I hate it. Whenever some new website/app uses it to describe their UI, I feel rage!
Spoken like a true mercurial enthusiast? :)
I have used git on the command line since day 1. It really isn't that hard.
I have used git on the command line since day 1. It really isn't that hard.
If you don't want to go with Jekyll/Ruby, there's Hugo (written in Go): http://gohugo.io
The nice thing about Hugo is that there's no install step. Just download and run with zero dependencies. Plus it's literally 100 times faster than jekyll. Friend of mine with a large blog (1000-ish posts) has to wait over 5 minutes for jekyll to render his whole site. He tried Hugo with the same site: 1 second. This enables live reloading in a local browser whenever you change anything in your site, which is super handy.
My first post about Hugo on my (obviously) Hugo-powered site: https://npf.io/2014/08/hugo-is-awesome/
My first post about Hugo on my (obviously) Hugo-powered site: https://npf.io/2014/08/hugo-is-awesome/
I'm using Pelican[0], which is written in Python.
0. http://blog.getpelican.com/
0. http://blog.getpelican.com/
And I used Sculpin[0], written in PHP and uses Twig for templating.
[0] https://sculpin.io/
[0] https://sculpin.io/
I assume you'd have to host this yourself? One advantage of Jekyll/Pages is that the hosting is free and relatively easy to set up.
edit: disregard me. I was busy being a bad user who doesn't read
edit: disregard me. I was busy being a bad user who doesn't read
Hugo is just like Jekyll. It converts markdown (or other markup) into static HTML.
Does it work with GitHub Pages?
Edit http://gohugo.io/tutorials/github-pages-blog/ THERE ARE SO MANY STEPS. I guess I'll eat the build time until it gets to 5 minutes.
Edit http://gohugo.io/tutorials/github-pages-blog/ THERE ARE SO MANY STEPS. I guess I'll eat the build time until it gets to 5 minutes.
Ah, I see. I didn't thoroughly read the splash page. Thank you for informing me!
Maybe I'm missing something obvious, but can't you already do this with Tumblr, Wordpress or Blogger? They're Free, Open (from his description, I assume it means customizable), and Easy.
Wordpress is extraordinarily clunky. There's a lot of configuration you have to concern yourself with (i.e. plugins, SEO, etc). If you want a custom domain with wordpress there's even more of a hassle.
With Jekyll + GH Pages you have full control of your site with as little complexity as necessary.
Here's some more info: http://joshualande.com/jekyll-github-pages-poole/
With Jekyll + GH Pages you have full control of your site with as little complexity as necessary.
Here's some more info: http://joshualande.com/jekyll-github-pages-poole/
> I wanted complete control, so Medium and Svbtle were out.
You could easily argue those other services don't give "complete" control either.
You could easily argue those other services don't give "complete" control either.
haha exactly what I was thinking!
Another Jekyll theme that I've been using is Poole:
http://getpoole.com/
It comes with the barebones theme, and two other sister themes.
http://getpoole.com/
It comes with the barebones theme, and two other sister themes.
This is a nice client-side markdown editor for gh-pages :
http://prose.io/
http://prose.io/
While checking the Traffic stats for one of my projects on GitHub today, I discovered inbounds from the following site:
http://www.staticgen.com/
It's interesting to see just how many static blog generators there are. :) Also, if you prefer you can probably find one written in $FAVORITE_PROGRAMMING_LANGUAGE.
http://www.staticgen.com/
It's interesting to see just how many static blog generators there are. :) Also, if you prefer you can probably find one written in $FAVORITE_PROGRAMMING_LANGUAGE.
I've had a blog[0] on GH pages for a few years now. I wrote a few posts about how to go about setting up feeds/og tags, GA, and I really should write another one about setting up everything else.
Basically, hosting a static blog is a rabbit hole. Keep track of where you came from, and share it out there. It's kinda amazing what you can do with a little bit of effort.
Personal plug: I cofounded Feedio[1], which gives you a widget for doing email subscriptions (among other things).
[0]: https://stevenkaras.github.io
[1]: http://feedio.co
Basically, hosting a static blog is a rabbit hole. Keep track of where you came from, and share it out there. It's kinda amazing what you can do with a little bit of effort.
Personal plug: I cofounded Feedio[1], which gives you a widget for doing email subscriptions (among other things).
[0]: https://stevenkaras.github.io
[1]: http://feedio.co
What about the fact that your content is duplicated in multiple places? Does that concern you at all?
To be honest, I'm not really sure what's duplicated here. Are you talking about the markdown sources being visible through the project?
yeah. google indexes that.
Hadn't considered that.
On the one hand, GH pages is a fairly popular resource for quick static site hosting, so Google should have had an engineer sit around and come up with a special filter just for that. On the other, I doubt very much that they've actually done that.
All in all, as long as you set canonical tags for your posts, the duplicate content on another domain shouldn't penalize you too very much. In any case, SEO for a personal technical blog isn't a high priority for me. If I were writing books or doing something to earn money with the blog, I would probably shell out for static site hosting using S3 and Cloudfront or something.
On the one hand, GH pages is a fairly popular resource for quick static site hosting, so Google should have had an engineer sit around and come up with a special filter just for that. On the other, I doubt very much that they've actually done that.
All in all, as long as you set canonical tags for your posts, the duplicate content on another domain shouldn't penalize you too very much. In any case, SEO for a personal technical blog isn't a high priority for me. If I were writing books or doing something to earn money with the blog, I would probably shell out for static site hosting using S3 and Cloudfront or something.
Eh. I don't get the Jekyll thing. I'd much rather run my own server.
After using Blogger, WordPress, and Ghost for years in various forms, I decided (for various reasons) to just write a simple blog engine of my own to power my site. The result is here: https://github.com/BenOvermyer/obelisk-blog-engine
It's not elegant, it's not extensible, and it's not really intended for anyone but me. But it works, and it's fully under my control. Any failings with it are mine, not that of anyone else.
After using Blogger, WordPress, and Ghost for years in various forms, I decided (for various reasons) to just write a simple blog engine of my own to power my site. The result is here: https://github.com/BenOvermyer/obelisk-blog-engine
It's not elegant, it's not extensible, and it's not really intended for anyone but me. But it works, and it's fully under my control. Any failings with it are mine, not that of anyone else.
I also recommend using http://prose.io/ to edit the markdown files and commit directly to github. It even writes metadata for jekyll.
So far, after a disappointing experience with WordPress, I've been pretty happy with Jekyll, and would recommend it.
I've written a tutorial on how to set up your own from scratch, which might be interesting of you're considering that: http://ricardolopes.net/blog/setting-up-a-hackers-blog-with-...
I've written a tutorial on how to set up your own from scratch, which might be interesting of you're considering that: http://ricardolopes.net/blog/setting-up-a-hackers-blog-with-...
I used github pages to set up a test blog with hexo [1] (and posted 1 entry about xsel [2], wooh) but wasn't able to find a very clean solution to providing multi-language versions of a post (the fork someone recommended kinda broke the theme [3] which is all on me, since I didn't really know what I was doing)
I'm wondering If people here have done the whole multilanguage blog (translations for each post) and what problems they've faced and solutions they've employed.
[1] - https://hexo.io/ [2] - http://isaacremuant.github.io/2014/10/27/xsel-Copy-Paste-fro... [3] - https://github.com/hexojs/hexo/issues/474#issuecomment-90086...
I'm wondering If people here have done the whole multilanguage blog (translations for each post) and what problems they've faced and solutions they've employed.
[1] - https://hexo.io/ [2] - http://isaacremuant.github.io/2014/10/27/xsel-Copy-Paste-fro... [3] - https://github.com/hexojs/hexo/issues/474#issuecomment-90086...
If you'd be open to a new framework/language, Pelican's creators seem to have considered translations of articles in designing their framework[1].
[1] http://docs.getpelican.com/en/3.6.0/content.html#translation...
[1] http://docs.getpelican.com/en/3.6.0/content.html#translation...
Python's always good, thanks, I'll check it out.
I've been fascinated with Jekyll as a blog, but I wonder whether it offers the same SEO resources as Wordpress.
Any experiences?
Any experiences?
Jekyll can set the basics such as meta descriptions via YAML front matter and the page template system, custom page titles, custom URL structure, etc. You can also use proper formatting quite easily (h1, etc.) with your choice of formatting.
As long as you have that covered that is all you really need for good SEO - the rest is keyword research, quality content, links, etc.
As long as you have that covered that is all you really need for good SEO - the rest is keyword research, quality content, links, etc.
In my experience it works great for SEO: you're in control of basically everything, so you have the freedom to play with meta tags, sitemaps, structured data, readable urls and so on.
But, of course, afaik, there's no plugin with nice explanations and checkboxes to configure that stuff.
But, of course, afaik, there's no plugin with nice explanations and checkboxes to configure that stuff.
You can also do this pretty easily with Hexo, which makes it easy to push Markdown blog posts to prettily-formatted static webpages. There's easy Github integration so that creating and deploying a new blog post is as a two-command process: http://razishaban.com/2015/07/from-zero-to-hexo-a-quick-tuto...
Lost me at Jekyll, I never really liked it.
If you want something where you can write where inspiration hits, use something like Ghost and throw it on a cheap DigitalOcean droplet.
If you want something where you can write where inspiration hits, use something like Ghost and throw it on a cheap DigitalOcean droplet.
If you are interested in the Jekyll / Github approach, you ought to check out Octopress (https://github.com/imathis/octopress) by Brandon Mathis.
It includes all the benefits of this approach, but with a nice out-of-the-box theme as well as useful helpers to make the blogging experience much better.
It includes all the benefits of this approach, but with a nice out-of-the-box theme as well as useful helpers to make the blogging experience much better.
For those who want to use React to generate a static site check out the source to my blog: https://github.com/kentor/kentor.github.io. I've ditched Jekyll because I don't want to use its template system and have ruby set up.
I just did Swacker[1], which does a deployment from a Github to a continous integrations build with Wercker to a hosted container on Giant Swarm. No downloaded software required.
1. https://github.com/giantswarm/swarm-wercker
1. https://github.com/giantswarm/swarm-wercker
We are working on a new blogging platform SunSed.com (still a work in progress) with focus on writing and reading experience.
Just try our editor! With Emacs like keyboard shortcuts (next sentence, etc) and features like moving content up/down in the page (no copy and paste needed). Anyway!
Just try our editor! With Emacs like keyboard shortcuts (next sentence, etc) and features like moving content up/down in the page (no copy and paste needed). Anyway!
Here's Github's official tutorial: https://help.github.com/articles/using-jekyll-with-pages/
Another setup guide - this one's for WP - http://impossiblehq.com/how-to-start-a-blog-guide/
Is Jekyll superior to Wintersmith in any way? Am currently fiddling around with Wintersmith.
I picked Jekyll cause it works out of the box with github pages.
I just spent a good long while converting a Jekyll theme to a WordPress theme.
I value WP's comments too much. Static sites require you to give control of your comments to third parties, and that, for me, is unacceptable.
I value WP's comments too much. Static sites require you to give control of your comments to third parties, and that, for me, is unacceptable.
I'll grant that git can be useful and it's certainly unavoidable, but "beautiful" is not a word I would use to describe it. Git is ugly and best hidden underneath GUIs, WUIs, and frontends. Indeed, this is how most people use it. Very few of the thousands or millions of git users know more than basic usage and most do not rely on the CLI.
So, in a similar vein to static blogs under version control, we have blohg for hg:
http://blohg.org/