BitBalloon Blog

Netlify, a pro-version of BitBalloon.

2015-11-03T00:00:00Z

A while back we introduced our new product for pro developers, netlify.

It’s a complete suite of hosting services for modern static websites, and even includes an opensource CMS.

Based on the same lightning fast CDN structure as BitBalloon, netlify comes with more than 40 distinct features, such as continous deployment, integration into GitHub, BitBucket, GitLabs and private Git repos, and so much more.

Netlify is more than twice as fast as any other hosting service on the market that specialises in hosting static sites and apps. That means better performance and higher conversion for your online business.

However BitBalloon isn’t going anywhere. It’s a stripped down version of netlify, where we focus on simple drag’n’drop deploying of static sites. BitBalloons goal is to be the easiest way to get a site online, while still getting blazingly fast hosting speeds.

But if you want to keep up with static news, or have more features, the platform that we are developing on, and where we publish content from is netlify. So do come and join us :)

Take care out there , and remember there are plenty of ways to get in touch) if you have any questions or comments.

~Matt & Chris, founders of BitBalloon & Netlify

Five Reasons you want HTTPS for your Static site

2014-10-03T00:00:00Z

“Does HTTPS really make any sense for a static web site?”

We’ve heard this a couple of times when talking about BitBalloon’s HTTPS support.

It might seem like a static site is already plenty secure: there’s no moving parts, no risk of SQL injection, no openings for XSS attacks, no cookies to hijack, no personalized data sent over the wire, etc, etc, etc…

So why spend extra and take even the smallest performance hit just to add HTTPS to a static site?

Here’s 5 good reasons you should switch to HTTPS for your static site today:

1. Improve your SEO

If you care about how well your site positions in Google searches, then adding HTTPS can give you a small boost. Google recently announced that they would start ranking sites with HTTPS support higher than sites that only works under HTTP.

2. Better Analytics

If you’re not using HTTPS for your site, you’re missing out on really important Analytics data.

We all wan’t to know where our visitors comes from. Being able to dive into our traffic sources is one of the major selling points of Google Analytics or any of their alternatives.

Browsers, however, won’t send the important “Referer” header when a user follows a link from a HTTPS site to a plain HTTP site. As more and more sites starts forcing HTTPS this becomes a larger and larger problem for site owners without HTTPS enabled.

If a you got an inbound link from HackerNews and your site is not HTTPS, you won’t see see Hacker News as a traffic source at all in your Analytics, since Hacker News forced HTTPS. Wan’t to know the bounce rate from the Hacker News audience? Tough luck unless you run HTTPS.

Same goes for any other traffic source enforcing HTTPS and there are more of those every day.

3. Protect your content

Last month Comcast received a lot of flak when people found out they were injecting adware into people’s browsers when using their Xfinity public Wi-Fi hotspots.

They’re not the first, and they won’t be the last, to tamper with traffic over public networks. As a website owner, having other companies inject ads into your site is a disaster. Ads on a company site makes you seem cheap and can seriously hurt the first impression you make on your users.

HTTPS means all the traffic between your site and your users is sent over an encrypted connection, and no-one can tamper with the source code of your site. So by enabling HTTPS you’re getting a guarantee that what your users see is really what you intended.

4. Protect your users

HTTPS doesn’t just protect users from lousy ISPs injecting ads, it also protects from more malicious man-in-the middle attacks. That inconspicuous little Facebook Like button could suddenly be opening up a phishing form to steal your users Facebook credentials. When your site is served unencrypted there’s nothing stopping a malicious attacker from using it as a convenient way to hijack your users.

5. Take advantage of bleeding edge technologies

During the last years browsers have gone from being simple document viewers, and grown into a full operating system of their own that can run complex web apps, access users location, file system, web cams, microphones and store data locally.

With great power comes great responsibility, and one of the key security systems that all the web infrastructure relies on is the same-origin policy.

When a user gives a site access to his location or his webcam, she does it based on the domain of the site asking for permission. As browsers gets more powerful, this means the trust bestowed on individual domains becomes much more valuable.

Because of this browser vendors are starting to consider only granting these permissions to domains served with HTTPS. It’s really part of the same reason as #4. How can you trust a domain, if there’s no way to guarantee that what you’re getting from that domain is really what the owner of the domain intended?

The new, incredibly interesting, Service Workers spec explicitly limits support to HTTPS origins and there’s talks about moving in that direction for some existing browser features like geolocation.

So if you want to take full advantage of the power of modern browsers, you might have to enable HTTPS for your sites.

Fine Grained HTTP Header Control & Basic Auth

2014-09-29T00:00:00Z

Today we’re launching a new feature that lets you add fine grained access control through basic auth, and gives you control over all the HTTP headers for URLs within your site.

Our new _headers file lets you control HTTP headers for specific paths within your site, as well as letting you configure HTTP basic auth.

The format is very simple:

## A path:
/templates/*
  # Headers for that path:
  Cache-Control: max-age: 3000
  Expires: 3000

Paths can contain * or :placeholders. A :placeholder matches anything except / while a * matches anything.

Here’s an example of settings the X-Frame-Options and X-XSS-Protection headers for all pages on your site:

/*
  X-Frame-Options: DENY
  X-XSS-Protection: 1; mode=block

Basic auth

The headers file can also be used to set basic auth headers. It’s a simple way to limit access to particular parts of your site.

/something/*
  Basic-Auth: someuser:somepassword anotheruser:anotherpassword

This will trigger the built-in basic browser authentication for any URL under /something. There’s two users defined here, one with the username “someuser” and password “somepassword”, the other with “anotheruser” and “anotherpassword”.

Unlike other headers in the _headers file, the Basic-Auth header will obviously not be sent as a standard HTTP header but used to control the appropriate HTTP headers for basic authentication.

Behind the Scenes of StaticGen.com

2014-07-31T00:00:00Z

Mathias Biilmann, founder of BitBalloon, dives into details about the redesign of staticgen.com. Our listing of the top, open-source, static site generators.

He shares how he used Github’s API, Gist, Middleman and Factor.io to build an always up to date, dynamic listing as a static website hosted on BitBalloon.

Transcript:

Mike: Hey everybody. I’m Michael Ruescher.

Mathias: And I’m Mathias Biilmann.

Mike: And this is the BitBalloon podcast number two. And today, we want to talk about the redesign of StaticGen.com.

StaticGen.com was a simple leaderboard that I created about a year ago, when Mathias and I, first were kind of thinking about building a service that was focused on just static sites. And at that time, we were also running the Webpop platform, and I said, “Okay, this is a great opportunity to kind of use what’s there at Webpop, and build a simple little site that just gives me a little bit of oversight about what’s going on with the static generator, open-source community.”

At that time, I sort of looked at static sites as more of this quick, like HTML one-pagers, but quickly discovered that there’s this whole world out there, people using static site generators to build much bigger, more interesting, complex sites. And there’s hundreds of these generators out there, and a large open-source community building them. So I figured I wanted to figure out how to surface the best ones, and which ones I should be looking at, if I ever need to build those kinds of sites.

So we used the server-side extension framework that Webpop offers to write a little bit of JavaScript that basically looks at each Github repository of a generator that you add to the collection there. And basically, it pulls down the stats of how many stars, how many forks, and how many issues it has. And then puts those together into one big leaderboard, and also keeps a record for each individual generator, so you can see its progression through time.

Mathias: Yeah.

Mike: When I first put this thing together, it was pretty neat. I mean, you could very quickly see which ones were getting the most action, the most stars. And it definitely gave you a good idea of which languages were popular, and which frameworks had the most contributions going on, and the most plug-ins, etcetera.

But one thing we found out pretty quickly is that all these people who are building these generators, wanted to get on the list. So people started leaving comments in the Disqus on the site. And the problem was kind of that I was pretty busy doing other stuff, and that every time this happened, I said, “Hey, can you add this?” It would just be all this additional work. And at the same time, I also didn’t really know how to represent them, necessarily. So if someone asks me to add their generator for them to our listing, it was kind of like, “Well, okay. I guess I’m just going to look at your GitHub page if I have time, and basically copy and paste what you have there, and hope that that works,” right?

Mathias: Yeah. And you then try to, like dig up stuff that can sometimes not be completely obvious, such as what kind of templates is this generator primarily using, and so on.

Mike: Right. And there’s all kinds of people going “Hey, can you fix this? This actually uses this kind of template, etcetera.” And so it kind of became unscalable in that sense, and we really weren’t set up to make this a collaborative process. And another issue that was sort of coming up with it was that we were making a ton of API requests to Github, and that was causing the site to load rather slowly at times.

Mathias: We had a bunch of caching underneath it, but still it’s just like, just to generate the index page, there’s no other way through the Github API, than to make at least one API request for each generator on that index page, and there’s just no way that all of those requests were always getting cached, so load times became a real problem.

Mike: So this thing kind of sat around for a while, and then you decided you’d give it a refresh.

Mathias: Yeah. I really like the site, and I like having a place with just all the static site generators. There was an another list that came up, staticsitegenerators.net I think, and I was actually using that a bit to do research and so on, but that’s great resource for, like everything in the static world, but it’s just also a very large list with a lot of things on it that’s not necessarily static site generators actually. Like a bunch of the stuff there is also flat file CMSs, or even hosting services. And I sort of wanted a list that was really just static site generators, and that also had some more details on each of them. And in the mean time, we launched BitBalloon and had gotten quite a bit of experience ourselves with building sites with static site generators. BitBallon.com is built with Middleman.

So I didn’t actually like this whole process of having this, sort of directory with all the ratings and so on as a dynamic site. It makes a lot more sense as a static site because… it doesn’t make sense that every time someone goes and see the index, we need to ask Github about all the details of all the repositories. It makes a lot more sense that just once a day or twice a day, we just run a build and find all those statistics and build the leaderboard of the day. I was thinking about that for a while, but also didn’t really have the time to set up all of that. And then I ran into the guys from Factor.io, that actually started integrating both BitBalloon and Middleman into their service. And what their service does is that it’s simply a deployment service, where you can, sort of use a little DSL that they’ve written, to plot together different types of services and data sources. And so in this case, once they had added BitBalloon and Middleman, it was easy for us to say “take a time resource and make sure that every six hours you fetch this source code from Github, and then you run the Middleman build, and then you push the result to BitBalloon”. All just in five little lines of their DSL. And that’s a really nice way of skipping the whole process of also having to keep tabs on some server somewhere that needs to run a crontab and so on, and just automate it all. So once I saw that that was possible, I just started to hack on a new version of static based on Middleman.

So for those who don’t know, Middleman is a static site generator in Ruby that has a feel, kind of like, Rails for static sites. If you come from Rails development, you’ll immediately feel very familiar with how Middleman, sort of organizes stuff, and with the Asset Pipeline of Middleman, and with the way you can use the typical template languages that you were used to from Rails, by default ERB, but you could also use HAML or the like and it’s easy to create CoffeeScript and get Sass and those kind of things working. And the way a typical Middleman site works is that you have, sort of different collections of content. What each collection is just a folder with markdown files in them, and each markdown file is a piece of content with a body text and some metadata of data called frontmatter, that you write in the very start of the file in YAML.

So what I did with Middleman was making a folder with a collection of Github projects. Each project is a static site generator. There’s some metadata in the beginning that just tells us what the Github repository is, what the title is, and a little short description, and the data for what language it’s in, what kind of template it uses. And then there’s just a body text with the description of that static site generator.

And then just from that, I could sort of start just building up the whole design of the new StaticGen. Sort of taking elements from the old one and rewriting them a bit, and making some JavaScript based filters and authoring, and just get the whole site to work as a completely normal Middleman project that would just list all the site generators I had added there.

To transition, I made like a quick little Ruby script that just fetched all the data we already had in Webpop, from the old version of StaticGen, and just put each of those into a Markdown file, and then actually just grabbed the Readme from the repository from each of them, and put it as the body text. And then I could just go in and sort of edit out the stuff that I didn’t really want to have in StaticGen.com. I didn’t want to have like the whole, all the set up instructions, and how to build and install and that stuff. I just edited out anything that wasn’t just the pure description of what is the static site generator, what’s the philosophy of it, and what’s the idea of it. And then once I sort of actually kind of done most of the design and got the whole site just functioning, and got the list working, I then started to work on this little extension to Middleman that would… Like Middleman allows you to sort of hook into its representation of the pages you have in a site. So during build time, you can add all the information to those pages. So in this case, I…

Mike: Are you just operating on the HTML there, for the output?

Mathias: No. It’s operating on sort of the… like each page is an object that has, different fields: A title…

Mike: Got you. Right.

Mathias: And in the case of StaticGen, in the projects folder, each project is a markdown file, and it then has, front end matter, where each of them has a title, a repo, a homepage, a language, a license, a list of templates, and a description. So the object I would operate on would have all of those fields.

Mike: Right.

Mathias: And that means that what the Github extension would do is that it would look at the repo field.

Mike: Right.

Mathias: And then will speak to the Github API, and fetch the data on that repo from Github, then add to that object, methods for accessing, like the number of stars, the number of forks, the number of issues. And then obviously, I could easily, include those into the page, and even with Middleman, it’s easy enough to just write stuff to sort all the output, show all the repositories, but sort it by number of stars in Github. And of course, below the scenes, this has sort of the same issue as Webpop, like to build the index page, you do need to make an API request to Github for every single static site generator, to get the data. But the big difference with this flow is just that, since this happens at the build time, it really doesn’t matter. I mean, it doesn’t matter if it takes 15 seconds or something like that, to fetch all the data.

Mike: And you get what? Like 5,000 requests a day, or something, so…

Mathias: Yeah. And the beauty of this here is that it’s just at build time, so when I run the Middleman build, it will do all these queries to Github, but then it will push the site to BitBalloon as a completely static site. And then once it’s live, there are no dynamic actions going on there. So it really doesn’t matter at all how many API requests we need to do, and how much work we need to do. We don’t have to worry about being especially efficient or any thing, because it’s really just being run once a day.

Mike: Absolutely.

Mathias: And then one thing I needed to solve was: what would I do with… like one thing we already did in the first version was to sort of keep track of… keep a little archive for each static site generator, where we could have, the historical data on how many… making it easy to go in and see, like how is this static site generator trending at the moment? Is it getting more stars? Is it getting less stars?

Mike: Yeah. And that’s something I added at that time because I didn’t see any way in Github to kind of get this historical record, and I was thinking, you know, what’s something we can add beyond what you can just see in the Github repo. So this isn’t just basically reproducing what’s already on Github. And so I kind of figured, well I might as well start logging this, and who knows what kind of interesting thing we can pull out of it later. As long as we have the data, it creates opportunities down the road.

Mathias: Absolutely. So I definitely wanted to have that as well for our static version. But of course, I have to think about, so what am I going to do? I don’t want to have to run a database somewhere. I mean, I really wanted this simple system, where build could just run on Factor. Where there’s actually no server somewhere running the build, it’s just this service called Factor that just builds it and push it to BitBalloon. So I definitively didn’t want to have to host a database somewhere, and I also just wanted to keep it really simple, for people to… I mean, one of the big ideas with doing this as a static site, apart just from the fact that it fits the model really well because you get away from the problem of having to do all those API requests in real time, it’s also just ideal that the whole site can just be open-source on Github, and when people want to add a new static site generator, instead of leaving us comments and discuss and asking to do it, they can just send in a pull request and say, “Hey, here’s a new static site generator.” So I also wanted to make it really easy for people to be able to just download the repositories and run a Middleman build. So I also don’t… I didn’t want to have some weird database running, and stuff like that.

Mike: Right.

Mathias: It needed to just be really simple. So one of the things that are really nice is that, again, since this is just a process that’s supposed to run once a day, you really don’t have to worry about typical things, such as latency to a database, or speed, or stuff like that. You can be much more lenient with those kinds of things. So the solution that I’m using now is that, what you need to do to run Middleman in a way that stores the stats and everything, is just to set up an empty Gist. And then when you run the build, you need to have this environment variables, your access token to, an access token for the Github API, and the ID of that Gist. And then during the build, the Middleman extension will actually use the Github API to use that Gist as kind of JSON database.

Mike: Oh wow.

Mathias: So it just, like generates a big fat JSON with all the stats of the the stats of the static site generators, and then just stores that in the Gist. So I actually have like a Gist that has like the archive for StaticGen.

Mike: Right.

Mathias: And just with the whole history of how many stats of each of these had and so on.

Mike: Yeah.

Mathias: And I mean it’s not terribly efficient or anything. It’s not like the recommended database solution for dynamic site for sure.

Mike: Right.

Mathias: But it’s just really simple for this, and the beauty of it is that it really doesn’t need to be very efficient. I mean, I can just store it and grab it, and then that Gist also kind of works as a cache. So if the data for the day is already in that Gist, we don’t need to make new API requests. So in the end, it kind of speeds up also the build process a bit. But it’s just also an example of how we can just do things in a different way, when you move the site generation from run time to compile time, actually.

Mike: Is that something you came up with yourself?

Mathias: Yeah.

Mike: Or is that something you saw somewhere else? Because I’ve never heard of such a thing.

Mathias: No. This is definitely my own… my own invention.

Mike: Wow.

Mathias: And it’s working great.

Mike: Sure, yeah. Gist don’t go away, I guess you can rely on them, right?

Mathias: Yeah, it’s there. And the beauty is that you can even roll it back and roll it forward or whatever.

Mike: Perfect.

Mathias: Each Gist is like a little Github repository in its own way.

Mike: I think after this podcast, you’re going to get a phone call from Github saying, “What have you done?” It’s going to be the new, like hipster database.

Mathias: Absolutely. But I mean, I was thinking of various options, but it was just easy because the API I was working with was already Github. So I was already reading all this data from Github, so it was sort of natural that I would also just use Github as my database for writing data. But you could imagine many ways. Another option I was considering was just having a Google Doc spreadsheet with the historical data. And they also have a JSON, OAuth2-based API for that.

Mike: Right.

Mathias: So that’s another thing that you can totally use for a database in these kind of static sites.

Mike: Yeah.

Mathias: But you would never really want to use as a database in a dynamic site. But again, in this case, the whole requirement… the requirements for a database change fundamentally when you just care about it, being up and being there, but you don’t really care about latency.

Mike: Right. So let’s go back to, you know, one of the things you mentioned, I think we kind of crossed over earlier, is the fact that this is now an open-source project.

Mathias: Yeah.

Mike: What are some of the implications of that now? Like what have we seen that’s different from when it was just a private project on Webpop?

Mathias: Yeah. Obviously, the big difference is, that since we launched it we’ve gotten a bunch of pull requests. Where people have been… especially adding new static site generators, some corrected, some data in existing ones, and some pull requests just to help us with things, like we have some rules that used to say that it had to be open source, and under that point that it had to be accessible on Github. Someone made a really good point of, open source and “accessible on Github” being two completely different things. And made a pull request just correcting that in the rules. And it’s a really awesome flow, actually. You just get a pull request with a new static site generator. You can just go in and look it over. And then if everything is fine with that pull request, I just merge it in. Then Factor will pick up that there’s a new commit to staticgen, and it will just run the build. And once it’s done, it will deploy to BitBalloon. So it makes the whole process of having people contribute and getting new static site generators added and then making sure that the information we have on the static site generators are up to date, really smooth and really easy, and very collaborative.

A great example also of how nice this kind of process can be, is also that, again, since the end result is always just a static site, and due to the way BitBalloon works, where we really have atomic deploys and so on. I didn’t have to worry at all when we were on the front page in Hacker News, and a bunch of pull requests were coming in, about just merging those in and let Factor deploy it. I’m sure that if this had been more of a dynamic site, I would have been a little more nervous of sort of tampering with it while it was getting tons of traffic. But it’s a nice bonus now that you can just do this, then the new version will just roll out once the build has been working fine and everything is good.

Mike: So as you were considering what to rebuild the site in, you obviously ended up with picking Middleman, are there any other generators that caught your eye?

Mathias: Yeah. I mean, I’ve lately been diving into various of them, and it’s such an interesting field just because there are more and more of them coming out all the time. And one of the nice things is that you can sort of pick very much, based on what kind of project you’re making. And a lot of them will have different strong points.

I could have considered Jekyll as well. That’s obviously one of the default choices, and it’s really nice as well and it’s quite easy to make plug-ins for as well. It just doesn’t have as much of a… like a nice thing with Middleman is this way that it has an idea of this sitemap that your extensions can interact with, that made it a really good fit for this because I just wanted to sort of add stuff to that sitemap. And with this project, I was also just pragmatic, and since we already built BitBalloon that common Middleman I was familiar and it was easy to jump into.

Mike: Right.

Mathias: Some of the other like… there are also static site generators that are more suited to specific things like, Assemble is a nice grunt-based static site generator. I know that, for example, the guys from ZURB use it to build foundation’s documentation with. But it’s not like, as simple as… in my opinion, it’s not very good for anything with more of a content model or something like that. But it’s really nice that it’s just like it integrates into Grunt. So Assemble is great for building documentation and stuff like that, for project where you already have your Grunt file and everything, you can just likehook in a little static site generator to build part of the project as a static site.

Mike: That makes sense.

Mathias: I’ve been looking quite a bit on Hugo lately.

Mike: Oh yeah.

Mathias: And it looks really interesting. It’s one of the new Go-based static site generators. And that’s kind of like, it has some… just being Go, it’s just a download. It doesn’t have any dependencies and so on. And of course Go is really fast, and it looks like it has a really interesting model as well. So that’s one of the ones I’m sort of following with interest. And then apart from that, it’s also really like, the nice thing with static site generators, that there are several in just about any language you want. So for many projects, picking a static site generator is also just a question of, what languages are we already using. If people are using Python and Django, it will probably be obvious to pick something like Cactus that, just like Middleman, sort of feels like a Rails for static sites, then Cactus sort of feels like a Django for static sites.

Mike: And I see that Pelican is consistently in the top three of static site generators. Python.

Mathias: Yeah. Pelican is also sort of one of those that’s been around for a long time. Like just about as long as…

Mike: Imports from WordPress.

Mathias: Yeah. It’s also cool.

Mike: Nice. What do you think motivates people to make all these generators? I mean, there’s hundreds of them out here.

Mathias: Yeah. I think there’s a lot of different motivations. I think, in general, every developer at some point has made their own blogging engine. And with static site generators, it’s a little the same. A lot of people will just start saying, “I’m a developer, I want my own site. I want it to generate some way, so let me just build my own static site generator and generate it”. So a bunch of them are like very personal projects, with just like, “Okay, I’ll do this to scratch an itch” And then some of those gets popular with a lot of people. Then you can see that some of them are more architected. Some of them comes out of… like Cactus came out of an agency… Assemble really came out of this idea, of let’s just use Grunt and create some grunt helpers help us that can basically build static sites from a directory. And then there’s also just the fact that some of them are focused on different things. Jekyll was from the start, like really focused on blogging, and just made it really simple to make a static blog. Whereas others are much more based on building landing pages, or documentation. And of course, once Jekyll came out, there was also a bunch of them that people built to have something like Jekyll, but in their language of choice.

Mike: Absolutely. Yeah, there’s quite a few of those.

Mathias: Yeah. Which makes sense. I mean, it’s one of the reasons for building BitBalloon in a way that this process just makes a lot of sense, where you don’t, move all the building to the compile time side of things. And then you use something like BitBalloon to just deploy them.

Mike: Yeah.

Mathias: And all the choice around, like what kind of tools and workflow, and so on, do we want to use? Well, it really doesn’t matter. I mean, it’s just what suits you best during the compile time phase. And if you use, if you’re a start up and you’re building a tech product, I imagine that it would always makes the most sense to have the static site generator that was as similar as possible to the stack you’re already using to build your technology with.

Mike: So I’ve got one last question for you while I got you on the horn here. So one thing I’ve been kind of… I’ve got a few friends that are photographers, and I’ve seen their solution. They’re not web developers, and they ended up with some sort of plug-in on their WordPress site, to serve their photography. But it’s basically like killing them. Like their site just kind of grinds to a halt as soon as they get traffic. And I’ve really been thinking that a static site on BitBalloon would be the ideal solution for them. The only kind of disconnect is, that they’re not hackers, they’ve never run a command line. But I feel like they would cross that chasm if they could get a result, where they could just kind of like load a folder of files in, and that would sort of create a new, tab or thing of photos that people can check out. Basically a new post, right? And so I don’t know if you’ve looked into this, or just through your perusing of these generators. If you have one that sort of stands out. I mean, you could probably do something like this with Middleman, I would assume.

Mathias: Yeah. But actually, it’s a fun question because one of the pull requests we got for StaticGen after we launched was a very unknown, like it just has two stars on Github, a small static site generator called ThumbsUp that basically does that. It’s actually… I haven’t really tried it, but it looks like it’s really cool idea. The input is just a directory, where for each photo album you just have photos, and then you just run one command line, and it will build you a photogallery website with different albums, and so on.

Mike: Yeah, right on. This might be it.

Mathias: So that’s definitively a good starting point, I think. And it’s something I only know about because we got that pull request for Static Gen.

Mike: So that’ll be one to explore. I’ll give it a star right now.

Mathias: Yeah. I’ll give it one as well.

Mike: Well, right on man. This has been really fun. I hope that people learned a little something, and definitely check out StaticGen on Github, if you’re curious. All that how it works, pull it down.

Mathias: Yeah. Send pull requests!

Mike: Absolutely. And I will catch you guys next time.

Download Your Old Deploys

2014-07-07T00:00:00Z

Ever lost your local version of a website? Ever wish you had stored an earlier version after making a change?

From today you can download the source files for any version of your website you’ve ever hosted on BitBalloon.

Just go to the History tab when viewing one of your sites in the admin backend. Next to each deploy you’ll find a new Download button that will let you download a zip with all the original source files you uploaded for that deploy.

Draft Deploys

2014-06-13T00:00:00Z

Today we’re launching a new API feature that’ll give you a bit more control over the deployment process, by allowing you to mark a deploy as a draft.

A draft deploy won’t automatically get published once all the uploaded assets have been prepared on the CDN and processed for max performance.

Instead you’ll be able to view the deploy on it’s deploy url and then publish it once you’ve verified that everything looks right.

Here’s some small code examples based on the Ruby API client:

site = client.get("my-site-id")
deploy = site.deploys.create(:dir => "/path/to/my/folder", :draft => true)
deploy.wait_for_ready

# Verify that everything looks right on deploy.deploy_url before publushing

deploy.publish

If you’re deploying a single page app, a great usecase for this would be to run an integration test suite against the BitBalloon deployed page as part of a continous deployment process, and only publish the deploy if all tests pass.

If you’re doing work for a client, this can be a great way to let your client validate a new version before publishing.

The Middleman BitBalloon Extension

2014-05-16T00:00:00Z

Middleman is one of our favorite static site generators here at BitBalloon.

This site is built with Middleman and we recently launched StaticGen, a directory of open-source static site generators, powered by Middleman.

Our new middleman-bitballoon extension now makes it even easier to deploy Middleman built sites to BitBalloon.

Using the Plugin

The middleman-bitballoon extension adds a middleman deploy command to Middleman.

First add middleman-bitballoon to the Gemfile of you Middleman project:

gem 'middleman-bitballoon'

And then run bundle install.

Before you can deploy, you’ll need to configure the extension in your config.rb:

activate :bitballoon do |bitballoon|
  bitballoon.token = ENV["BB_TOKEN"]
  bitballoon.site  = "my-bitballoon-site.bitballoon.com"

  # Optional: always run a build before deploying
  bitballoon.build_before = true
end

We recommend setting the Access Token from an environment variable, but obviously you can also load it from a file or hardcode it in your config.rb.

To generate a token, just go to the BitBalloon Applications screen and create a personal token.

Once the project has been configured right, you can deploy at any time with:

bundle exec middleman deploy

Grunt BitBalloon Deploy Task

2014-04-28T00:00:00Z

Grunt has quickly become the standard build-tool for the front-end world, with a huge ecosystem with hundreds of plugins you can use to automate just about anything.

Today we’re adding one more to the list: grunt-bitballoon.

The BitBalloon Grunt plugin makes it straight forward to deploy to BitBalloon straight from your Gruntfile. It’s a multi-task plugin, so you can easily setup development, staging and production targets.

Here’s a simple example of a Gruntfile using the plugin to setup a separate dev and prod target:

grunt.initConfig({
  bb: grunt.file.readJSON('./grunt-bitballoon.json'),
  bitballoon: {
    options: {
      token: '<%= bb.token %>',
      src: 'dist'
    },
    dev: {
      site: "http://my-staging-site.bitballoon.com"
    },
    prod: {
      site: "http://my-production-site.bitballoon.com"
    }
  }
});

grunt.registerTask('deploy', [
  'bitballoon:prod'
]);

Get all the details in our grunt-bitballoon docs

Ara T Howard on Static Sites, Dynamic Content & Creativity

2014-03-27T00:00:00Z

Ara T Howard, long time Rubyist and partner at the Boulder Colorado based web agency, Dojo4, explains why using a static site architecture unleashes the creative forces of the agency’s front end talent.

He shares how to use Draftin and Middleman to create a collaborative authoring environment that seamlessly publishes Markdown documents to rendered HTML on BitBalloon.

Transcript:

Mike: Hey everybody I’m Mike Ruescher and I am here with Ara Howard from Dojo4 and this is the BitBalloon podcast where we discuss new ways of developing websites and applications using the static site architecture. So Ara How’s it going?

Ara: It’s going great. Launching some sites today.

Mike: Okay. I’ll try to stick to the point then so you can get back to launching stuff! You guys are out in Boulder, Colorado, right?

Ara: Yeah, Dojo4, we’re a creative technology agency that’s located in downtown Boulder. We’ve been working here as the agency for about five years, although the founders worked together in some fashion for a number of years before that. And so we’re really fortunate to be right in the middle of what we like to call start-up alley here in Boulder and we get to do a lot of fun stuff. Everything from website to native apps, to Rails applications, to massive like cloud infrastructure, so yeah.

Mike: Quite the range there. Sounds like you’re no strangers to building fully dynamic web properties.

Ara: No. Absolutely not. I’ve been a Ruby developer since Ruby 1.4 maybe even a little bit before then, long before rails was on the scene and you know at that point, I was building a lot of dynamic web applications for NOAA through the Co-operative Institute for Research and Sciences and we were doing — so at that point it was mainly CGI applications but also some really, really sophisticated java applications using old school MPM-CGI which is new school kids call that Server push. But yeah, I’ve been building dynamic data-driven web applications for, I’m embarrassed to say, probably more than 15 years at this point.

Mike: So, you started this Dojo4 about 5 years ago?

Ara: Yeah. At the time I became a partner in Dojo4, I had an LLC codeforpeople and a lot of people know that name from the Ruby world, it’s 200 gems, definitely way more than 150 gems in the Ruby community at this point, so that was my former consultancy and then that company and myself along with a few other individuals came together to do something a little bit bigger than just doing rails work including design and production work, copywriting and interface design.

Mike: Integrating vertically.

Ara: Yeah there you go.

Mike: Excellent. So when you guys started out, you obviously had to put up some sort of website to tell the world about who you are, and was that a static site from the beginning?

Ara: Yeah. It was actually and I’ve always been a big fan of static. To the extent that ten years ago I was using some dynamic tools like the Ruby CGI library, most people don’t know that you can run CGI programs off standard in and standard out. And I was basically developing my own static site generators. So that I could work with some of the really early Ruby templating libraries. Don’t know if anyone remembers that. We were doing a lot of template driven static site generators, at the time. Like 10 years ago before it was really in fashion. And I’ve always been a fan of that just for the obvious reason that static scales like mad. But also as a developer, I like having everything in source control, My IDE is VIM and I like just being able to work.

I believe in the power of plain text.

Static makes it possible to create architectures that scale really easily, so I’ve always had a preference for that. And when we started Dojo4 our very first website was something static. Our creative director and I had a couple versions of the site that was static, of course it was checked into Github and we went through a variety of deployment solutions. It was even running out of a box in a closet here at one point. And it was on a EC2 node we hosted on S3 at one point when that first was possible. So I’ve been deploying dynamically generated static sites for the duration of the time I’ve been working on the internet.

Mike: Then at some point though, you guys moved on to a more CMS-based solution, which actually had a database which was generating your site, not pre-rendering it, right.

Ara: Yeah, and at the time it was of the former partners of Dojo4, and we had this discussion and we really wanted to encourage people to write. I mean that was the motivation, to increase participation in the development of the website that was the impetus for moving on to a more CMS-based tooling, and so we looked at a variety of things and some of the people in the shop were experts with expression engine, of course had experience with WordPress but as developers we wanted input into having a modern framework that was simpler to deploy, easier to manage, and Github had a variety of deployment options and was more extensible, solid MVC framework. So that ruled out pretty much most of the popular CMS’s with the exception say of expression engine which was ruled out on the basis of it being semi-closed. Its not open source software. And so we ruled it out.

We ended up going with Refinery at the time which it was a nice toolkit. We rolled out a new site and it certainly worked. Certainly people who were non technical could use it, so we had that setup for a while and we noticed that people weren’t doing a significant amount of new writing. Design was limited because the people who were sort of passionate about design so on a spectrum of designers and front end developers, there was a barrier to entry. They were like, can I change a little bit of HTML, a template here and there and it’s like well yes but it depends, it just depends. Like you had to actually understand the technical stack depending on what you were trying to achieve. Say we wanted to lay the blog out in a grid and not have traditional pagination, like a design concern, you’re going to have to think about that a little bit, infinite scrolling or Oh we’ve got to write some Ajax or something like that. So we didn’t see a lot of additional writing. We didn’t see a lot of creative revisions to this site and we saw despite the fact that it was a good framework and was usually extensible, we saw almost no custom code written.

Mike: Perhaps there is even a bit of a psychological barrier to actually writing and getting stuff out there, and that’s what might have happened in your situation. I think in a lot of situations, if you have the added overhead of maybe a rails app or any sort of additional complexity around authoring then that becomes the excuse to not do it.

Ara: Absolutely and so we saw a lack of both technical and creative input into the site or innovation. Lack of technical and creative innovation and so. then we launched into our second most recent version of the website which we ditched the custom stack and we did something custom. And the reason that we did something totally custom was again, you know the thinking was. Well there was two lines of thinking. One I don’t know if you’ve read the Done manifesto but I’m a big believer in the concept that doing something makes you right, its one of the ideas there and we were basically seeing that the Rails dev, the developers were doing a majority of work.

And so the overhead of having a predetermined model structure and to be limited by even what the CMS could offer just to create a dynamically generated blog-post didn’t seem to work out. And so we developed a custom rails app and we have a CMS plugin that we’ve written that is very simple, it’s not a fully fledged CMS, it fulfills the need where you have a rails app and like hey we just need to also edit some content type, so that’s very common in rails projects.

Mike: I’ll have to check that out.

Ara: Well, its one of the few projects that’s not in the public domain. I could extract it into an engine, it’s on the to-do list. I have some hesitation around it for a variety of reasons. But in any case we use that and then we were able to achieve somethings quite easily because we were on a fully custom stack. so for example our old rails app, our deployment actually it basically when something like deploy the rails app, and then because we had a quite good configuration I had it so that content editing we used page caching, heavy heavy use of rails page caching. So that for all practical purposes the site was almost exclusively served by Apache and nginx, depending on whatever was deployed to you.

So we basically wired into the content editor invalidate the entirety of the page cache, it was a sledge hammer, but it had a beautiful property that for almost no work, the site was extremely fast, extremely durable and easy to manage. Page caching has gone out of fashion in the rails world but for content non authenticated apps, it’s absolutely unbeatable. So we were quite happy with that. That was the best incarnation of the site that we had for a long time. We were able to have a lot of authoring again, not a significant uptick but it was very easy for developers to make changes for sure. When we had a new idea, like oh we should do this customer survey thing at Christmas time or whatever. It should have add this little webhook to do whatever. We should build a tweet feed, it would be super simple and super robust to implement.

But then again something started to smell a little funny to me and during the period that we are using this on our own website we were building a lot of static sites using primarily middleman as a site generator for customers and the niche that we were filling there really was, I’ll just take a little tangent here, you know we worked for a lot of customers that were dissatisfied in particular with rails apps deployed to Heroku, or with Wordpress, because of the common litany of excuses: it’s insecure, it gets hacked all the time, it’s down every now and again, it cost too much to maintain, and so for a variety of companies it was a little challenging to get them to make the switch. But we basically were able to say to them look, if you just give up on real time editing of content, just give up on that. A funny story on that is of the bigger companies, they’re very large, a successful startup here in Boulder and they were definitely reticent to off Wordpress for their main sites, they has some reticence to going to a fully static site and like well, what if we want to make updates? Fortunately we had been working with them for a year, and we were sort of able to point out that look your organization is larger now, you have 50, 60 people, nobody just publishes directly to the blog.

You have a publishing flow which ultimately ends up in internal review outside of the system, and at the end of the day a word doc would get shipped to us. And we would report it. And this is very common, very common. Basically, for the one person shops static html works fine. And then there’s the sweet spot of like maybe two to eight people were something like WordPress for small business does allow every body to contribute. Everybody can put their plugins in, everybody can edit content, but once an organization gets bigger the invariably end up with a content publishing wordflow. You know this stuff has to go through Marketing, it needs to be approved, it needs to be scheduled for November, instead of September. And so all of that kind of goes out the window and so publishing is much more controlled and centralized, so we were able to say that look what does it matter to you when you’re giving us this content and we’re putting it in to whatever system and simultaneously they have concerns around up time. Absolutely we need our site to be fast, people forget how important speed is for SEO.

We want it to be robust, people forget what poor marketing having your website be down is, if you’re a technical company, it really makes you look like an ass if you can’t keep a website up. And so we made the switch. And their site is managed completely in Middleman, every single change by every author is in Github. We can rollback this site to any moment in time, all data, all content, seven months three hours and 2 minutes ago we know exactly what the site looks like. We would deploy it to S3, we were doing quite a bit if that about a year ago and I liked that quite a bit and I was looking over some of the clients we had done that with.

I was looking at what we had done, and then I realized and felt kind of foolish in a way that I’m like you know, our site, our rails app it really is a static site generator. We’ve moved fully paged caching at the end of the day,in fact at the end of my deploy, I could actually run wget mirror and warm the cache and at that point, other than when we’re editing, it didn’t really matter if the site was up and I thought well okay that’s neat. But it certainly is driving a plastic tack in with a 30 lb sledgehammer.

But that wasn’t the motivation to reinvent the site, so we talked for sometime about moving this site back from Rails to Middleman and making it static.

But one of the things I got hung up, and this is still an issue is that there are some issues with deploying to S3. For example we have had some issues with content negotiations, so gzipped versus not gzipped, that’s a small issue.

But I think the biggest one we have is deployments and S3 especially for our larger sites say like 1000 pages, 2000 pages - It doesn’t offer atomic deploys. So that especially when you’re doing client work, can be a little nerve wracking to push out a new version of the site and worry that your network is going to go down in the middle or that people are going to basically be experiencing a broken site during the deployment.

Now practically speaking it wasn’t a huge issue but I wasn’t comfortable, I wanted to make our site even better, I wanted fast and I wanted atomic and I wanted robust performance out of what was serving our website.

So I played with the normal permutations of, we can make it HA, we can load balance between servers and then have Capistrano based deployment, so it’s atomic, it’s HA, but are you kidding me? It take two minutes to like three minutes to like pushup a one character change, it just didn’t feel good. And that’s also very challenging to reason about.

I was telling you for the our second to last permutation we were mostly concerned with allowing developers, the people who are doing the work to be able to do the work easily in the tools that they like using. And so that was a step in the right direction. But really the people who need to be editing websites are front end engineers they’re not designers, they’re not back end developers, they’re not Rails developers.

They are people who are passionate about HTML and CSS and retina optimized images and why we want to a SVG logo and we have to use this IE hack. And that’s because the front end, just the HTML you deliver has gotten exponentially more complex in the last 2 years. Because of he proliferation of the byte sizes combined with resolutions combined with network speeds right 3G, 4G, online, offline, broadband, android phone, turn sideways, suddenly the development the ability to be creative on the front end has gotten quite technical.

And that’s where the real innovation can occur in a web and so I realized it’s those people that you really want to give those people a playground on your website, if you want to experience like the maximum creativity, those people need to be able to work quickly. and so those people they don’t really care about say SSH Key round robin, I need to deploy the three servers to make these up, oh I need to run a database migration to like get some change deployed, they don’t give a shit about this.

And nor should they.

So I went back to the drawing board and I had been looking at BitBalloon for a while, it seemed very promising: the atomic deployments, the CDN distribution which of course is something you can do on AWS if you push an S3 site out unto cloud front, but all of the sudden your deployment has really gotten complicated, and caching validations is really hard to reason about.

Mike: You wanna abstract that stuff away if you want to make simple for people.

Ara: Yeah and we can do it, back end engineers can do it, but the question is as a web agency is do I really want to spend time screwing with caching validation across a CDN for our website, it like the last thing I want to spend time on.

Mike: I think half of our job is avoiding bunny trails.

Ara: Yes exactly. And so where we’re at now our new site, I’ve been talking to Steve one of our really talented engineers and it just happened like one day, I said you know what let’s rebuild the whole site in static and about 48 hrs later we were done. We took the rails site and we designed, implemented and deployed an entirely new infrastructure that is based on BitBalloon, a webhook and the Draftin editing service, and Middleman. And so from the beginning the site is a Middleman site and it doesn’t matter what site generator you would use. You might use Docpad or there’s a variety of really great site generators but we have a site generator and all our content is checked into Github so we started there.

Here is a website, a very easy, a very well factored website but data-driven and all static entirely contained in Github. And so then we needed to move on to like how do we deploy it. And so we made the deployment we went to BitBalloon. That was not a lot of work.

We compared our Rails site being served from Apache to one being served from BitBalloon, same content. Our Google page rank jumped from a 35 to like a 88, just with no work!

Mike: That’s awesome.

Ara: Yeah, it was really beautiful. We were able to take sprockets out of the entire thing. That’s something the BitBalloon does for you. It’s sprockets as a service, we are like screw compressing images and CSS and we don’t even want to think about it also, like not our problem like why do we care about this.

Mike: Absolutely, why does everyone have to re-invent the wheel there, right.

Ara: Yeah, and I mean, sprocket’s is a good tool chain, but again I’ve spent many, many days of my life debugging asset compilation issues on developers boxes and to the extent that sometimes I’ll avoid using the tool chain for small things.

Its just not important enough, so in any case although I’ll will say its gotten much better. so we have this static website, its written in middleman, its all in github and it can deploy to bitballoon.

And so now we’re in a position where the front end guys can iterate very, very quickly. They’re just able to churn out new features. Like we had a St. Patrick Day version of the site took a few minutes to make the tweaks, deploy, great. The hosting is super robust, it’s super fast, it takes out a whole bunch of complexity. CDN invalidation, asset magnification.

So as a technologist, a CTO, I can look at it and say yes I will put my name on that, I can show that to a client and say you think you need key words or a certain CMS for SEO which of course Google ignores now. But your site is like a dog and Google cares about this, you need to make it fast so that search engines can consume it, prefer to consume it. And so I can look at the site and it’s like yeah something I’m proud of as technologist. Look how fast it is on your phone, on 3G, its blazing fast, oh and by the way its up, like I don’t have any infrastructure to host it, I don’t have boxes, I don’t pay for anything to host it, or pay for very little to host it, so I’m very happy about that.

But we lost the ability to publish and for non-technical people to publish. And that’s kind of a deal killer for some people right. So what we did, we have been using the very excellent Draftin service and I don’t know how many people are listening here have used it. Its basically a markdown editor. It’s an in browser markdown editor at first glance that’s what it is but if you dig a little deeper and the UI’s deceptively simple, it offers a lot of features, but two of them we really like for our publishing workflow, well three of them, i should say.

One: it allows you to share your draft and get feedback on people in a sort of git pull request based way. So people are able to make suggestions and alterations and the author is able to merge them in very quickly. This is all happening outside of any CMS or online site repository or anything, it’s just online service were you’re writing things and very, very good collaboration tolls and merging tools. That one feature we were using a lot before we started using it for the website.

The other feature that we use a lot, is I’m writing a lot of proposals in it, so often times I would write something, solicit feedback from my team and then I have a really nice feature called ask your pro where you just pay and you just pay a small fee 6 bucks for a professional editor, who’s automatically under and NDA will edit your draft.

I really like that because I make a lot of spelling errors, I’m a very fast writer, but I’m sloppy and it’s great for me to be able to put together a you know 200 word blog post and go you edit it. That’s 6 dollars it’s so worth my time it’s not even funny.

So I’d often times put the editor into Hemingway mode which means you cant even hit the back space key you can only write you can’t delete. So I write then press I press the button, hey editor for 6 bucks clean this up then I’ll solicit feedback from the team, and now I have something that I might post. And I was doing this when we had the rails app. And so a rails app we could post in Markdown too and I would just export it and paste it in there.

So Draftin has another killer feature, you can configure arbitrary web hooks and it can deploy content to WordPress, It can deploy content to Tumblr, FaceBook or arbitrary webhooks. And this is where our coup de grace came in we said we built a little robot, its' a teeny little webhook that sits on one of our EC2 nodes she listens to these post backs from Draftin. It’s a secure webhook so every author has a secure URL and we basically just give it to them, I’m like look all you need to do in a Draftin interface is put this URL and call it Dojo4. you can give it a name, its your Dojo4 endpoint.

So now you can use this Draftin tool which is like so much more sophisticated than any CMS editor out there in terms of managing arbitrary workflows, of review, revisions, internet planning, so on and so forth to get to develop really good content. Which is the basis of a good site, and then my two seconds with a URL and a name you can say and there’s s Webhook. So that Webhook when they hit publish, when anyone set up in Draftin hits publish, it posts to our little robot and so she catches the draft it comes in as a big ball of JSON and without getting too technical, what I do is drop it in the file system once in temp just to like make sure that I’ve captured it and then I basically spawn an import process and so that import process is actually written in our website repo and in plain English our website repo has a command line tool that knows how to import files which is the JSON, the blob JSON, the Draftin post to us, it knows how to import that and the fact that it happens to do it though obviously you can run it from the command line if you have the file. And this is basically what this little command line script does it just examines, it has a mapping of the webhook to what kind of content, so right now all of our webhooks make blog posts.

But it could be a blog posting or anything else, it’s the URL that determines this, what end point you publish to. So right now they’re all blog posts and the UID that’s in the URL also as well, lets me know what author it is, so obviously I can drop stuff on the floor if its not an author I know about, and so then I can just basically explore that into the file system into our static site repo, so we have data, and Middleman uses a data layer that’s mostly -based and we have something that’s much more sophisticated than that, its on Github, it under ahoward my github name ro standing for ‘read only objects’ and it’s a system that just meant to like manage your site content in a really super understandable directory hierarchy, its not that complicated.

But if you think how would I lay out the data with relative assets for those blog posts in a file system that what it does. It just gives you a very good interface to it. So the import of the file from, I just basically write some files and the directory to disk and it gets committed. And so then it’s in the repo, there’s notifications coming to our Campfire room and all the other notification channels like another git commit, and then the robot deploys the site and we have some email hooks so as the robot is pushing the site up it just lets the author know that we get three messages which is like hey I got your post, i am building the website and I deployed it and it’s live. That process takes a few minutes, and I have some new work that I believe will make it many times faster compiling the site, building the site, its not actually the deployment

Mike: Pulling in dependencies?

Ara: Yeah, I mean basically the Middleman site generator it’s linear, its primarily a single threaded, it could be much faster, I guess is all I’m saying. But some site generators are faster. There’s a lot of competitors in that space right now. But in any case we generate the site and then users just get a couple of emails, some robots check in their content, their bit of content and push it to BitBalloon. So that gives us all the properties that i was looking for which is the thing is super easy to tweak for the people who tweak websites. Which is front end engineers. They can hack with impunity because they can preview locally or they can review the site in any way, shape or form, right anything can serve static HTML, they have no barrier to playing because there’s no fear that lets just say what they did is oh my gosh you’re crying over the MO data and it an N+1 query, so you just make the build take a minute longer. Well that’s not ideal but who cares. This isn’t happening in real time or you know one of those pages goes boom, but it doesn’t take the app down. if when we build it doesn’t work, but it’s not an error that the enduser is going to see a 500 of a website for example. So they don’t have to worry about database layers, asset pipe lines any of that. They basically have a site generator, they have data, its all HTML, CSS and Javascript and that’s it.

Mike: If only that’s what it meant when it’s a What You See Is What You Get.

Ara: Yes, right. And I think that something and I have explained this to clients too, it’s a real hard. the concept of content editors lowering the barrier to entry for the layman to be able to edit content, I don’t want to say it’s impossible now but that question “what do you see?” is actually pretty hard to answer right now and it’s like well, do you mean on an iPad when it’s rotated sideways or do you mean on a large screen Mac monitor and it’s like and of course it’s like a rabbit hole, and it’s like actually Jeez should that banner image even be there on the iPad, it’s real big, what if they aren’t 3G, we may not even send it down, And so your points were all taken, i think, the concept of, I think, it has got to change, its not What You See Is What You Get when you’re editing, it really needs to change, that these are the important aspects of my content. And then the system has to do something clever based on the device and the network that the user is using to consume it and that problem is getting worse faster, its not getting better faster.

Mike: Well I think there a few things I want to note here is that one is this is a perfect example of where we really believe the web is headed to: a more composable ecosystems of services. Where you use the services you need and compose them together to produce a result and this is what you’re doing here. You’re using BitBalloon for deployment and hosting you’re using EC2 to automate the process from getting to Draftin to your site generator and these parts just work together and I think that it’s really neat to see this happening for you and working so well for you.

The other thing is that going back to what you see is what you get, definitely Markdown is emerging as the standard in the industry. It finds that middle ground between making it possible for people to author and also understand that what matters is the important aspects of what you what to have on your site and that really distills it down into that and kind of removes a lot of the pain.

If you can get someone to understand and use Markdown I think you’ve really kind of have solved the problem in terms of getting a client to manage content on their site and not having to deal with issues why does this look different in my WYSIWYG editor that it looks on the site and so forth.

Ara: Yeah, I agree with you, I mean yeah on all those points and definitely we feel like we are using composable tools and Draftin for collaborative editing. For collaborative editing is a superior tool to anything available to any CMS on the market. Markdown as an intermediate format is absolutely the best format currently to store your content in. You know you really don’t want to be coupled to any complex, data formats or databases when your talking about content that part of company’s IP, that content is very important, it’s very hard to generate, you want to be able to reuse it in a variety of ways and so you want a format, you don’t want it in a propriety CMS format, you want it in something very simple that you’re going to be able to migrate through systems for 10 years, because that content, you know that represents your company knowledge base, your company marketing. I don’t know how to put an exact dollar figure on it, but it’s much higher than people realize.

That’s the hard part of websites, its generating good content. And that includes the images, It’s the images and the writing but you want those to be in a very simple importable format that’s going to be durable over time. And just case in point, like when I’m working with a new site generator actually based on Rails that I’m actually working on that’s building our site is actually take about 3 seconds with this new site generator but when I was getting the new tool working over our content, because our content is using this gem and it would be the same with the files, but because our content is using this gem ro, our content is laid out in a directory hierarchy which basically one blog post per directory as you can imagine. And then inside there, there’s one file that’s just the data attributes, attributes.yml, but the content is body.md, it’s a markdown file. very easy to edit in vim, and read and understand and then the assets are in a relative directory under that.

If I tarred up that content and there’s other content-type in there too, people and jobs and stuff like that, but if I tarred that up and gave it to any web developer, anywhere in the world, who have ever worked in any language ever and I said you need to expose this in your Go static generator or your php dynamic site, whatever, you would not even require a readme. It would be like this is all the content of all of Dojo4 right here.

Mike: Right. That’s impressive.

Ara: Yeah, and then it’s not. Ff you asked a hundred developers to lay out a directory hierarchy of content for a website, 99 of them would do it this way. So keeping it plain text and portable, that’s another, that’s also sort of the composable idea that you’re talking about right?

I should be able to take this content and do something else. Write it, script it, takes our blog and publish it as a book. Which is something done for clients for example. So that’s true and then finally just using BitBalloon to solve the asset compilation, CDN, hosting, HA, speed problem for us, I don’t even remember what you guys charged, it’s like so cheap, I’ve forgotten because It doesn’t matter to me.

Mike: We appreciate your enthusiasm on that!

Ara: Yeah you should raise your prices by the way.

Mike: That’s always good to hear. Let’s see is there anything else we want to go over here? If I want to set this up for a myself, is there a code you’ve made available? The murkiest part for me is the bot you have on EC2 is this something you guys are keeping to yourselves or is this going to be something that’s available for others to take a look at?

Ara: I haven’t released it as a very, very generic application yet. It’s a very small rack application, its only 200 lines of code and it has a good read me. They were some passwords and things well they were encrypted, but there was some data in the repo that prevented me from just saying the repo is open although it’s on my to do list at some point, I have no, my intention is to have the entire Dojo4 site and this robot have public repos, but in the short term I did publish about this workflow. It’s on the dojo4.com blog and the title of the blog is Static is the New Black. At the bottom of the article, I allowed people to download the entire rack application, I did strip out some sensitive stuff just to make it smaller and safer but I gave people the middleman app and the rack app, so that’s 98 percent of the entire system.

Mike: Okay.

Ara: So yeah we’re giving it away eventually it will be public on Github but you can look at this rack app and see oh geez. I mean the webhook to catch the content from Draftin is trivial. There is a little bit of thinking. You know programming robots, having a repo with a robot that modifies the repo, is you need to think about that a little bit, its not a lot of code, it’s only a few lines. The penalty for screwing up is that things can go horribly wrong as it goes Boom!. But the beauty of it is: so what. All of our content is in Github, it’s revision controlled, it doesn’t really matter if we screw up because we can go back. Every single change.

So, I may or may not have programmed an infinite loop that did somethings to our website that I regret last week, but you know it really didn’t do anything harmful in the end. So again that’s the real beauty of aggressive caching right or having a static website is that having your website be up and what’s available to the public is entirely decoupled from any of these details. It just doesn’t matter if our whole publishing workflow is exploded or we’re doing it by hand today, it makes no difference. So for me as a developer it’s also liberating. I have no fear to try new things, I can’t take the site down by screwing with our publishing work flow. They’re independent concepts.

Mike: You mentioned already some ideas for ways that you could repurpose content for example generating a book. Is there any other things you see on the horizon in terms of how you plan to use this with future clients or existing clients that you have?

Ara: I think the thing that I realized is that ultimate system that we would build, Draftin’s really close and think that very, very appropriate say for blogging and other things. But there are some limitations as in if you share something you’re going to publish with me as you’re writing it, we can both see it, if you publish it then it’s checked into the repo and everyone can make edits to it. And then of course when its published everyone can see it. But other than the repository I don’t say have a view automatically into every draft, every person is working on if they haven’t solicited me for input.

Now our organization is only 15 people but if you use an approach like this for an organization of a hundred people, that may not cut it and so I see Draftin and I’m realizing that in the old domain system you still may have I guess what’s called a centralized CMS. In other words there’s a Rails app and you log in to it and you can use the tools there and that can publish content. That same rails app may have content that Draftin can consume. Right, you like have this simple web interface or any other reasons, yes Draftin is an inlet too, Oh by the way so is email, right, we have lots of scripts that listen to email channels so for me to write well I won’t go into what we do with those, but for me to modify one of those, scripts that we have that listens on an inbox one of out company inboxes and say yeah actually if you email to blog at dojo4.com too, it does the same thing.

So I think the fundamental architecture is firmly decoupled, authoring is decoupled from publishing is decoupled from revision control is decoupled from hosting.

So that’s perfect but I do see maybe developing more of a centralized application to have more total knowledge of the system. For example an administrative person could go in and click a button and generate a Webhook URL for a new employee for example, so here’s one now you can use this to publish on Draft, which right now is, well we do it from the command line but its not exposed to non technical people.

So i really see augmenting it more than any thing else is what I see in the new future, augmenting and optimizing because right now our workflow is good. The price we pay for having you know a site that is screaming fast, simple to manage and close to a 100 percent up-time is several minutes from hitting the publish button to seeing it. I think you know if we can get that down thats fine for us technologists, I think it might make some end users, it might make then uncomfortable.

I mean it just depends on how sophisticated they are because you have a similar lag if you’re using any CMS pretty much you can see, a kind of a lag. But I think getting the whole build and deploy site go down you know even 15 seconds that something you could easily explain to a client, yeah it take 15 to 20 secs before, after you hit publish a bunch of bots churn away and now your site in unbelievably fast. And we guarantee that it will be up, that’s a totally reasonable trade-off. So yes optimizing and augmenting, I think are the next things but I haven’t had more creative thoughts than that at this moment

Mike: Yeah that makes a lot of sense. So wrapping this up, what you just mentioned to me, it just reminds me of conversation I had a few months ago with Kin Lane, the API Evangelist, he’s also really big on a sort of git based markdown authoring workflow. And he’s got a huge empire of content that he does entirely through this kind of process. I can put you in touch with him, you guys might have a really interesting conversation about what you’re talking about, the orchestration of multiple authors and this kind of publishing flow.

Ara: Yeah. I’m really interested in that because, I think it’s important for people that really care about their content or in large organizations where the curation is so important and it’s not served at all in the web publishing marketing place right now by any major CMS.

Mike: Yes, I think there is a real opportunity there and you guys are making some real badass inroads into it. So thanks a lot Ara, I really appreciate you time and for those of you listening, definitely check out the blogpost at the dojo4.com blog Static is the New Black.

Working with clients and collaborators

2014-03-26T00:00:00Z

Most websites have a group of people involved in building, updating and maintaining them.

This is no different with static sites or one-page apps, and so far BitBalloon hasn’t been giving the ideal experience for a team working together or for a designer with a client.

Today we’re happy to announce our new user management feature.

Now inviting clients or collaborators to your site is as easy as typing their emails in a textbox. We’ll send them an invitation and when they follow the confirmation link they get access to the site.

Never share an FTP password again!

Building a Mobile Todo App with Appery.io and BitBalloon

2014-02-19T00:00:00Z

Max Katz from Appery.io made an awesome little tutorial showing how to build a todo app with Appery and BitBalloon.

Appery.io is a cloud-based rapid development environment that helps you create cross-platform apps in HTML5 with a drag and drop app builder.