One piece of feedback: that gif of the process needs to be recreated. It's far too quick and the erroneous key strokes and typing/deleting is really confusing. Recreate the gif, but make it slower and error free to clearly demonstrate the process.
Most browsers support embedded videos now, which have the advantage that you can rewind and pause. You could also provide a transcript or static screenshots.
Dont want to be a bubble-burster here.This can also be achieved by picking any of the blog engines[1] and hooking it up with a CI. Gives you much more legroom then right?
There's this guide on a "one cent blog"[0] that I've used to create my own website / weblog with a custom domain. It uses Jekyll, CloudFlare and Travis-CI. Probably a bit more work to set up then the tool created by the OP, but also more flexible, I would think. The end result is much the same though. A simple 'git push' is used to publish the blog.
I'm the author of "One Cent Blog" thanks for the mention glad it helped you. One interesting difference between the approach described in my blog post(or any other static method) is that you are not relying on a server or a database that can fall over if you get a lot of traffic from say HN. Having static files is a blessing because it scales wonderfully.
The approach in this post relies on maintaining infrastructure, keeping it up to date and patched which for me is a lot of extra work I'd rather not do. Using a standard VPS it's a lot more expensive too.
I do this with jekyll and github but without s3 or travis-ci. I skimmed over the blog but couldn't understand what value s3 adds vs letting github host it. Cloudflare can do the https bits with github directly.
The main value is escaping the constraints on plugins and gems you are able to use with Jekyll on GitHub pages. Don't remember of the top of my head but I believe it's pretty limited.
I considered doing this with my hugo blog, but decided I wanted to do the work on my client and keep my server stupid. In order to build my site, I have a lot of minification, pdf generation, syntax highlighting etc, that requires a few packages to be installed on the client.
If my server had to rebuild after a git push of a new post, I'd have to install all of the tooling on the server. I just commit my post, then run npm deploy which rsyncs all the static assets to the server after building on the client. This also makes it so I can see everything on my client easily before deploying. If I was building a blog for someone else though, this would make sense, stupid client, smart server, commit from anywhere.
My motivation for this project was simple, I need a good interface to write my articles from different devices and able to publish them without touching the server.
I built this in such a way I don't need to think about database backups, server side authentication, using dropbox to sync my unfinished articles.
This architecture offers me freedom to write on my phone (Termux) during commute or sitting in the office and keep track of changes using git and finally publishing the post by simply adding a record into metadata.json.
You could throw Jekyll, Middleman, Pelican or Hugo on the server and run their build command with a git hook. Then you'd get the same result, but a completely static website without the server needing flask to piece together pages when a user hits the site.
The build times wouldn't be instantaneous as it would need to regenerate all the pages, but Hugo is still really snappy for even a large site. You probably post less than users access anyway.
The site would be built on the server so it wouldn't be completely dumb like rsync-ing static pages to nginx or something, but that's the rub if you want to be able to use clients with only git as a dependency.
Yours is a good solution, I'm just throwing an idea out there for a pre-baked alternative. My original use case didn't call for mobile blogging (not a fan), I run my own gitolite server so auth is already in my camp and I have a multi-tooled build that I didn't want on the server. If something breaks, it happens on my machine instead of on my server.
Also just a tip, maybe you want to put a <noscript> tag around an expanded copy of your hamburger menu. Without javascript, your website navigation is broken because you can't expand the menu.
Edit: by client, I mean blog-editing-computer not blog-reader's-computer.
What you said is true but where's the fun in it. I started this project as a simple django blog, included react little later and then scratched the whole thing and finally built this. It was fun working on this.
About the menu, I was planning to update it to hamburger icon with animations. For now the icon doesn't change and the menu is injected into adjacent/bottom element based on screen size.
Interesting to hear your experiences. I'm doing something similar, with a large number of files in the static directory which never change. Hugo seems to lack any knowledge about which files it changed, so it's a huge re-upload every time (I'm using AWS S3 sync).
It would be nice if Hugo could remember if it touched a file or not. AFAICT it just copies everything over each time and changes the datestamp. Even with rsync this is a lot of useless work.
I've got a script which does a git pull every 5 minutes, with automatic hugo build. It works (Hugo doesn't crash that often) and is simple enough for me.
Jekyll on Github does not allow plugins. Though I'd say that this seems to be a bit an overkill, one shouldn't need cntainers for this kinda task. Best approach would be local build+rsync/ssh for a normal hosting. For github, I'd build the site targeting another git repo that I'd push to github.
Seems to me that publishing blog post through git push is much more work than use some admin interface (for example Wordpress).
You can use it from any device (without aby app for CLI interface). You can use for example VersionPress[1] for backups to git. And I don't get what's the point of publishing without touching server, since you need to touch the server to view published post.
I think maintaining the LAMP Wordpress stack, extensions, admin panel auth security, whatever versionpress is etc. is more hassle than editing a text file and pushing code. To devs, this editing is second nature.
Also, I'd take my desktop editor to a contentEditable any day.
Github has a nice web interface for directly editing files and creating Git commits from them (and Pull Requests), which is why I like to stick to the GH Pages flavor of Jekyll. It's nice having the option for a web interface for quick edits and the editor of my choice for long form posts. The Github website is the only reason I use Jekyll over many of the more recent alternatives like Middleman/Hugo/et al.
I used wordpress for a couple of years, It's good for a general purpose blog, but as codesim365 said I like CLI than web interface and it's too much hassle maintaining WordPress( Regular updates and security patches, database backups and sync to dropbox or s3 )
With a CMS for static websites like DatoCMS [1] you can have the best from both words: edit your post from a good old web interface and publish a rock solid, stupid, static website.
I haven't used jekyll much but I would say this stores posts in separate git repo (github.com/snehesht/blogposts) and user doesn't need to update the server every time he publishes a new post.
It uses github webhooks to alert server of any events related to the blogposts repo. The server verifies the events using HMAC authnication ( see github docs for more info) and then updates the local blogposts repo ( git pull)
With github pages and Jekyll, updating the blog is also just a simple push of the Jekyll sources. The HTML page generation will than happen on github's side. Of course with this, you're locked down to 2 techs, github and Jekyll.
Being locked into Jekyll is not such a huge deal, as the posts are all Markdown with some YAML frontmatter, and other systems use the same post conventions, such as Middleman. Github only provides the convenience of not having to install Jekyll on your own system in order to publish. If you want to throw it up to S3 or any other static file server, you just have to run `jekyll build` yourself.
Both my current[1] and previous[2] blog engines work like this - as long as the post tree is updated by git or Dropbox, they're perfectly happy. Plus I can use whatever markup I want (even Jupyter notebooks).
Why would I want to use Zammu over just using Travis CI or any other existing CI service? The only new feature I see is scheduled deploys. (It's not clear to me from the description on the site how this work.) Unfortunately it doesn't seem the SSG I currently use (Wintersmith) is supported anyway. Although I don't see why adding specific support for each system should be necessary.
One piece of feedback: that gif of the process needs to be recreated. It's far too quick and the erroneous key strokes and typing/deleting is really confusing. Recreate the gif, but make it slower and error free to clearly demonstrate the process.