Tag Archives: github

GitHub growth problems

When first writing about mirroring this blog, there were only 2 places — WordPress.com and GitHub — that came to mind as good choices:

I believe both will last for decades, maybe even 100 years, and both embrace the open web in a way that most other centralized web sites do not.

I still believe that, but Bloomberg has an article about growth and spending problems at GitHub:

In September 2014, subscription revenue on an annualized basis was about $25 million each from enterprise sales and organizations signing up through the site, according to another financial document. After GitHub staffed up, annual recurring revenue from large clients increased this year to $70 million while the self-service business saw healthy, if less dramatic, growth to $52 million.

These numbers seem fantastic except that GitHub is losing money overall. GitHub has transformed from a small profitable company to a large unprofitable VC-backed company. Here are some of the goals from GitHub’s 2012 announcement about taking funding:

We want GitHub to be even easier for beginners and more powerful for experts. We want GitHub everywhere — whether you use Windows or Mac or Linux or some futuristic computer phone that hasn’t been invented yet — we want GitHub to be an awesome experience. We want to make it easier to work together than alone.

They’ve made progress in the last 4 years. I’m not sure the GitHub user experience has improved more quickly because of funding than it would have otherwise, though.

I love GitHub and use it exclusively for my source and my client projects, because there’s a productivity benefit to having everything in one place. I hope GitHub can turn the corner on profitability. And most importantly, I hope they have a sustainable long-term plan beyond this initial quick growth.

Dropbox, iCloud, and GitHub on the iPad

Federico Viticci has another fantastic long-form essay, this time about using the iPad Pro for a year. It’s the story of his iPad workflow plus mini reviews of each app that make using the iPad as a primary computer possible.

I haven’t finished reading the whole thing yet, but I’ve been paying particular attention to the theme of file management. I use Dropbox for my most important files — documents, notes, and photos — because I want them synced everywhere and accessible in an obvious, transparent way. iCloud is too opaque and app-specific.

Federico covers this conflict early in the essay with a list of iCloud downsides:

iOS apps like Documents and Workflow can’t access or display the contents of other apps’ folders. This prevents the existence of a full-featured iCloud Drive file manager that offers functionalities Apple doesn’t want to build in their iCloud Drive app. There should be an API to allow third-party apps to gain access to the entire contents of your iCloud Drive filesystem, just like there are APIs for photo and music access.

I’ll be happily surprised if Apple ever adds such an API. It seems unlikely. And if that’s true, it means iCloud will be permanently crippled compared to Dropbox.

The trend to new iCloud-first apps like Ulysses and Bear is fine. It doesn’t appeal to me, though. I use Ulysses on the Mac because I can sync with Dropbox. There are so many Dropbox-capable iOS text editors that I feel confident using my current favorite and switching whenever I want.

Federico also describes using GitHub and the iPad app Working Copy for collaborative editing:

Working Copy’s diff support has been a boon for how we edit Markdown and collaborate on articles. We can keep track of every edit and comment in a centralized location without creating duplicates. Working Copy makes it easy to follow the evolution of a document through multiple commits; every writer can chime in with their own suggestions and Working Copy will handle file merging and conflict resolution thanks to GitHub.

GitHub is useful for much more than code. I personally love the simplicity of Gists and GitHub Pages. It’s great to see how MacStories can use GitHub for editing articles, too.

Workflow update for web APIs

Federico Viticci has an overview and examples for the latest Workflow for iOS release, which adds more advanced features for calling into web APIs. It looks great:

For those who are only partially familiar with the terminology, this means that Workflow can communicate with the majority of modern services that come with a web API. If you’ve never worked with web APIs before, it’ll take you a few hours of reading and experiments with dictionaries, token authentications, form requests, and file uploads to get the gist of how it works. But, the Workflow team has managed to make what tends to be a visually unintuitive programming task – assembling dictionaries and structuring JSON – as simple and attractive as possible, abstracting many of the complexities that web developers have to deal with in desktop IDEs and command-line tools.

Here’s another nice example of automatically creating GitHub Gists, from Jordan Merrick:

This is a workflow I’ve always wanted to create, and the new API support makes it possible. Gists are great to share small pieces of text information, such as code snippets or scripts. This action extension workflow accepts files of any type (though they must be text-based) and creates a gist using the GitHub API.

Workflow can now take over many web tasks that previously required either writing scripts or depending on hosted solutions like IFTTT and Zapier. Like my workflow for posting photos to my blog, it’s a natural tool for web publishing and microblogging.

I’d also love to see a Mac version of Workflow one day. I do some limited automation on my Mac, but AppleScript and Automator aren’t as easy to use or as well-maintained as Workflow.

Building on Jekyll

If you were to build a weblog publishing system, would you start from scratch or build on an existing tool? There’s a healthy market for WordPress-powered hosting, for example, from WordPress.com itself to WP Engine. People know and trust these tools.

I was faced with this question for my microblogging platform. My requirements were pretty simple:

  • The published site needed to be 100% static, so that I could host it anywhere.
  • The template system needed to be widely used, so that I could draw on existing themes and provide customization for users later.

Jekyll looked like a great choice. I’m so happy with how well this has worked that I mention Jekyll in the marketing and footer of published sites. It’s a brand that can help give users confidence that this is built on something solid, and that if they need to migrate to self-hosted, there’s a path.

On top of Jekyll, I built a web interface for publishing and deleting posts, changing themes, and I added XML-RPC support so that you can use external blog editors like MarsEdit. Plus there’s a native iPhone app for posting.

All of this enables another feature that I’m very excited about: full mirroring to GitHub Pages. When you publish a microblog site, you can have it upload all the Markdown and HTML to a GitHub repository. This is a great way to export or mirror your content.

I think it’s a good foundation. Publishing is actually a small part of the overall microblog platform I’ve built, but it’s an important one. I can’t wait to share more and keep building features up around Jekyll.

I’m writing a short e-book about everything I’ve learned, and I’ll have news soon about early access to the platform. You should sign up on the announce mailing list before next week.

Complete mirror of this blog

I’ve been blogging here for 13 years. If you take any random post from that first year, the majority of the links to other web sites are broken. The default outcome for any site that isn’t maintained — including the one you’re reading right now — is for it to vanish. Permanence doesn’t exist on the web.

We can solve this, but it will take time. For now I think mirroring our writing is a great solution, to guard against domain names expiring and other inevitable failures. But where to mirror to?

Only 2 companies keep coming to mind: WordPress.com and GitHub. I believe both will last for decades, maybe even 100 years, and both embrace the open web in a way that most other centralized web sites do not.

Even though I self-host this weblog on WordPress, I’ve chosen to mirror to GitHub because of their focus on simple, static publishing via GitHub Pages. It has the best chance of running for a long time without intervention.

I exported all of manton.org with the httrack command-line tool and checked it into GitHub, with a CNAME for mirror.manton.org. It works perfectly. I still need to automate this process so that it updates regularly, but I’m very happy to finally have a complete mirror for the first time.

Future-safe weblogs

It’s a common theme for Dave Winer to write about preserving our writing on the web. Today he outlines some criteria for judging whether a web host will last:

“The concern is that the record we’re creating is fragile and ephemeral, so that to historians of the future, the period of innovation where we moved our intellectual presence from physical to electronic media will be a blank spot, with almost none of it persisting.”

I think about this in 2 parts. The first is publishing your weblog to your own domain name. This ensures that your writing doesn’t go away and links don’t break when your web host goes out of business, because you can copy your content somewhere else and map your domain to that new location.

The second is some kind of host that will last forever. This is an unsolved problem. Hosting fees need to be paid, domain name registrations need to be renewed. It may be too big a leap to ever get there, but we could settle instead for better mirroring of content. I’d like to have my content mirrored automatically to GitHub Pages, for example, and maybe even Medium.

Imagine the life of a printed book from the early 20th century that has now survived generations. How was this possible? Many copies must have been printed, because some will inevitably be lost or destroyed. And when a library or bookstore is closed, copies of the book must be transferred to a new location.

This all follows naturally with a printed book, but to adopt the same pattern for digital works, we must go out of our way to create a system of mirroring and long-term storage that tries to match what happens in the real world automatically. It’s a great challenge.

Unfortunately very little has changed on this topic since I wrote about permanence 3 years ago. But we can change that. Open formats and auto-mirroring will be a key part of my new microblogging platform.

Two weeks notice: final pull request

With just 5 days left at my regular job, it’s time to get serious about wrapping up my work. I have a small change mostly ready and tested locally, but need to push it up to GitHub and finish testing on the dev server. I have a couple open Jira tickets to look at after that.

Over the weekend I spent a lot of time with the Stripe API, trying to improve how I manage user subscriptions. Stripe has some new features since I first started using it. For example, options for sales tax and a quantity field. The latter is convenient if you have something like the ability to pay for multiple hosted web sites in a subscription, rather than deal with adding custom line items on an invoice.

Deadlines are an excellent way to push yourself to actually finish something. So this deadline of Friday is good, in a way, but unlike most of my other deadlines, I can’t miss it and keep working for another week. That finality is a little daunting right now, as I look at the week ahead and everything I want to get done.

Two weeks notice: writing documentation

Boy Scouts have a saying: leave no trace. One of its basic principles is that when you pack up your camp site, make sure you clean up all the trash. The place should look even better than when you found it.

It’s not a bad principle to keep in mind when leaving a job, either. Projects should be in a good state. I’ve fallen short in one key aspect of this — a conspicuous lack of unit tests in my web apps — but I’ve been more successful in other areas, like up to date versions of Rails and pretty comprehensive documentation.

Documentation is also an easy thing to improve at the last minute. Today I’m reviewing some API docs from top to bottom again, making sure that the confusing edge cases for how an app works are well covered. For my job at VitalSource, this means editing in Confluence.

The apps in Atlassian’s main suite that I’m familiar with — Confluence, Jira, and HipChat — have improved in small increments over the years. I makes sense that they would move fairly slowly; the apps are heavily used in larger companies, so a major redesign or feature change would not be well-received by many of their customers. Of those 3 apps, HipChat seems easily the best designed, and I expect having Slack as a competitor will keep them focused and driven to improve the app.

This post isn’t meant as a rant against Confluence, but as I use it’s default markup language or WYSIWYG editor I’m reminded of just how much I enjoy writing in Markdown instead. For my own apps, I’ve experimented with writing documentation in Markdown hosted on GitHub, which gives me easy publishing and version history. Tweet Marker, for example, pulls a Markdown file from GitHub directly and formats it inside its own web interface for Twitter app developers.

As usual, open formats like simple text files are a great choice for any writing that you want to last. For my new microblogging project, I need to repurpose a lot of writing I’ve done on this blog and move it into more formal documentation. I’ll probably use Markdown and GitHub for that as well.

Core Intuition 152

We posted episode 152 of Core Intuition today, with discussion of iCloud Drive, iOS 8, and Yosemite, plus mini-rants about distributed version control, why Daniel uses Mercurial, and how I just switched everything to GitHub. I like how this episode turned out. As usual, it’s under 40 minutes, and not a bad place to start if you’re just subscribing for the first time.

The Core Intuition jobs site is still half off for a few more days. $100 to get your job in front of a bunch of great iOS and Mac developers.

(After a decade on Movable Type, I’m migrating this blog to a new system, so I fell into the trap of not posting much until that process is complete. I’ll have much more to write about this soon.)

Searchpath open source and themes

I have big news for Searchpath today. The client-side portion of Searchpath is now officially open source and available on GitHub. While I do think one of the innovations of Searchpath is the JavaScript, CSS, and HTML, it’s really the simplicity of setting up Searchpath that makes it work. A single line of JavaScript adds a search box and indexes your site, and the crawling and storage will of course remain private on my servers.

Now that part of the service is on GitHub, customers who wanted to extend the JavaScript can have a clear path for doing that. Not only is it easier to host the JavaScript yourself, but I’m accepting pull requests to integrate your improvements back into the core product for everyone to use. Special thanks to Brett Terpstra for already submitting some tweaks.

I’m also very excited to announce a simple themes structure for Searchpath. Because in addition to the JavaScript, the second part of customizing Searchpath is the design. While I document CSS class names you can use to override styles, I wanted to make it even easier to design completely new user interfaces and share them with others.

On GitHub you’ll find a “themes” folder. Any sub-folder here will be routinely synced to the main Seachpath server, where you can access it by adding “theme=folder_name” to the JavaScript include URL. To create your own theme, just add a sub-folder with your own custom theme name and submit a pull request. When the theme is added to Searchpath, all your CSS and images will be hosted by my servers. (The first person to use a specific name will effectively become the owner of it, and I’ll only accept pull requests from that person.)

Want to learn more about Searchpath? You can try it out here for free, or sign up for $8/month.