HN user

nickmerwin

49 karma

http://mer.io

Posts5
Comments18
View on HN

For anyone interested in more contemporaenous context around Engelbart's Augmentation Research Center, the book "What the Dormouse Said" closely follows Engelbart's trials and tribulations amongst the other early personal computing visionaries of 1960's Stanford and the Mid-Peninsula, leading up to the Homebrew Computer Club:

https://en.wikipedia.org/wiki/What_the_Dormouse_Said

https://en.wikipedia.org/wiki/Homebrew_Computer_Club

Here at Coveralls.io we can't recommend Replicated enough. We were able to migrate our internally-developed, Github Enterprise style packaged VM delivery approach over to their system in a couple weeks.

But I'd say the real value is in not needing to support an additional deployment platform -- their Docker based approach is like Heroku for on-prem, it abstracts the infrastructure details and just works.

This is one of the things about being a web developer and part-time DBA that keeps me up at night (sometimes literally all night).

Around a month ago the source file table on Coveralls.io[0] hit a transaction wraparound, and put us in read-only mode for over 24 hours while RDS engineers performed a full vacuum (that's not something that can be done manually as a customer). On a managed database I'm paying thousands a month for, I was hoping there would be some sort of early warning system. Well, apparently there is, but it's buried in the logs, and won't trigger any app exceptions so went un-noticed.

What's worse is there's 0 indication of how long a vacuum is going to take, nor progress updates while it's going. So for a production web app with customers, this means damage control language like:

"Our engineers have identified a database performance issue and working to mitigate. Unfortunately we do not have an ETA at this time."

About a week later, more calamity hit: the INT "id" field on the same table exceeded the max length. My first thought was change it to a BIGINT, but after ~4 hrs into the migration without any indication of how much longer it would take, I pulled the plug and sharded the table instead.

Moral of the story is that web devs should be aware of these pitfalls, and that no matter how much trust you put into a managed database service, it still could happen to you (queue ominous background music).

Anyway I'm glad to see this lurking monster in our beloved database tamed, thank you Mr Haas!

[0] https://coveralls.io

I gave a talk on delivering Rails apps behind corporate firewalls at Railsconf'2015[0], but have since migrated Coveralls Enterprise[1] from our home-baked, pre-packaged VM to Replicated.com[2]

I'd recommend checking them out too since they're Docker based and have a significant roster: Travis, NPM, Code Climate, etc.

[0] https://www.youtube.com/watch?v=V6e_A9VzPy8

[1] https://enterprise.coveralls.io

[2] https://www.replicated.com

NPR.org itself has a great JSONP API that makes apps like the one in this article possible. Here's a site I put together that uses it and HTML5 audio for a very quick and minimal NPR listening experience (best viewed on iOS safari):

http://npr.io

It's a Jekyll app mostly written in CoffeeScript, deployed to S3 with CloudFront CDN'ing.

Here's a lengthier introduction for anyone interested: http://nickmerwin.com/2012/02/25/npr-io/

As we grew as a company, we found that we frequently had people working remotely on a project, sometimes from home, sometimes from another country. trying to keep track of what everyone was doing at any given moment seemed to get exponentially more difficult as time zone differences were involved. just asking people for status updates became a pain. we decided that we'd have to find a better way, and what we came up with to solve our internal issue is UTSUP?.

We developed the application to work transparently with git to update the entire company as to what individuals are working on without the communication overhead of having to actually send someone a status update; now we all just "sup" each other.