davidthewatson · December 13, 2011 14:39
diff --git a/the_new_blog_software_flask_plus_gist_equals_flasgist.html b/the_new_blog_software_flask_plus_gist_equals_flasgist.html
 <p>I'm not sure if anyone's been crazy enough to try this yet, but I've had this vision for a while. I had three main goals: get the data out of a relational database, put it in the cloud, and make it look pretty.</p>
 <p><b>I satisfied the first goal using github's gist API as a data store for all of my blog posts.</b> I use the description as the title, the filename to anchor the URL semantically, the created_at date for the date/time of the posting, and the body for the post itself. I'm only supporting single filename gists right now, and I use the starred/unstarred functionality to mean published and draft, respectively. The beauty of this design is that it allows me to avoid having to implement all of the CMS functions directly, i.e authentication, creating, updating, deleting posts, etc. In exchange, I use github's gist interface for creation, updating, deleting, promoting from draft to published, and in turn, I get versioning and forking of posts for free, which is inline with both my share and share-alike fondness for Creative Commons licensing and my desire to work iteratively on the pieces that I publish.</p>
 <p><b>I satisfied the second goal by running the entire thing on heroku cedar</b>. Heroku rocks. It enables me to keep all of my work in git and iterate quickly with deployments using git at the command line.</p>
 <p><b>I satisfied the third goal by using twitter bootstrap</b>. Twitter bootstrap was mentioned to me by a coworker a couple months ago and I hadn't even heard about it, but after working with it for a few months, I'm totally sold on its value proposition, which, put simply, is that I can use a few simple CSS classes quickly and easily with very little reference required, and having things look designer-clean in the prototype stage without having to be a designer, or at least not a good one. Even better, the designer-friendly CSS is kept in templates where it belongs.</p>
 <p>In addition to this, right now I'm using the embedding features of flickr and youtube to host my media content and I'm using the github API to list my github repositories. My plan is to move the flickr and youtube content to API-based designs as well. Next, I will remove the personal branding stuff and refactor that into a separate skin so that others can use it trivially without having to wade through my personal branding.</p>
 <p>The major issue with this design is the latency implied by the remote API calls. However, heroku's nginx, varnish, and routing stack make this mostly a non-issue as the cache means that pages load much more quickly in production than they do on my macbook pro. The other thing that I thought about trying is to move the python web services requests to jquery such that the page loads content asynchronously.</p>
 <p>But with less than five hundred lines of code, I'm satisfied with it for now. And I shall call him <a href="https://github.com/davidthewatson/flasgist">flasgist</a>.</p>
	<p>I'm not sure if anyone's been crazy enough to try this yet, but I've had this vision for a while. I had three main goals: get the data out of a relational database, put it in the cloud, and make it look pretty.</p>
	<p><b>I satisfied the first goal using github's gist API as a data store for all of my blog posts.</b> I use the description as the title, the filename to anchor the URL semantically, the created_at date for the date/time of the posting, and the body for the post itself. I'm only supporting single filename gists right now, and I use the starred/unstarred functionality to mean published and draft, respectively. The beauty of this design is that it allows me to avoid having to implement all of the CMS functions directly, i.e authentication, creating, updating, deleting posts, etc. In exchange, I use github's gist interface for creation, updating, deleting, promoting from draft to published, and in turn, I get versioning and forking of posts for free, which is inline with both my share and share-alike fondness for Creative Commons licensing and my desire to work iteratively on the pieces that I publish.</p>
	<p><b>I satisfied the second goal by running the entire thing on heroku cedar</b>. Heroku rocks. It enables me to keep all of my work in git and iterate quickly with deployments using git at the command line.</p>
	<p><b>I satisfied the third goal by using twitter bootstrap</b>. Twitter bootstrap was mentioned to me by a coworker a couple months ago and I hadn't even heard about it, but after working with it for a few months, I'm totally sold on its value proposition, which, put simply, is that I can use a few simple CSS classes quickly and easily with very little reference required, and having things look designer-clean in the prototype stage without having to be a designer, or at least not a good one. Even better, the designer-friendly CSS is kept in templates where it belongs.</p>
	<p>In addition to this, right now I'm using the embedding features of flickr and youtube to host my media content and I'm using the github API to list my github repositories. My plan is to move the flickr and youtube content to API-based designs as well. Next, I will remove the personal branding stuff and refactor that into a separate skin so that others can use it trivially without having to wade through my personal branding.</p>
	<p>The major issue with this design is the latency implied by the remote API calls. However, heroku's nginx, varnish, and routing stack make this mostly a non-issue as the cache means that pages load much more quickly in production than they do on my macbook pro. The other thing that I thought about trying is to move the python web services requests to jquery such that the page loads content asynchronously.</p>
	<p>But with less than five hundred lines of code, I'm satisfied with it for now. And I shall call him <a href="https://github.com/davidthewatson/flasgist">flasgist</a>.</p>