In the Colorado Front Range area? I’ll be talking about the realtime web at the Fort Collins Ruby Meetup this Wednesday.
I’ll show how adding realtime functionality is the easy: in less than 30 minutes, we’ll build a Sinatra app that uses Pusher for realtime functionality.
See the demo Sinatra app, a Ruby Meetup Realtime Heckle Board on Github.
Our navigation header was packed-full of links (and let’s be honest, looked a little stale). We’ve elected a new, fresher, nav header:
What you need to know
- We’ve emphasized the primary pieces of Scout (servers, applications, charts, and dashboards). The less-accessed config-related bits are inside a pulldown in the upper right (people, notifications, billing, etc).
- Hotkeys plus keyboard navigation is the best way to play. Each of the primary areas has an associated pulldown. Reveal each pulldown with a hotkey (the underlined letter in the nav). For example, hit the “s” key to reveal the servers pulldown. Once the pulldown is open, use your up/down keys + enter to navigate.
- We’ve dropped the recently accessed server tabs. These frequently created confusion: how the initial set of tabs was chosen, how they reacted when a new server was picked that shuffled a previously accessed tab off the list, etc. Using the “s” hotkey is the fastest way to travel to your servers within Scout.
The hotkeys for each pulldown (the first letter of each word):
- s – Servers
- a – Applications
- c – Charts
- d – Dashboards
Once a pulldown is open:
- up/down arrow keys – navigate through the list of items
- enter – show the current item
- esc – close the pulldown
If you see any issues, let us know!
The Scout gang (including founders and co-dictators-for-life Derek and Andre) will be at Rocky Mountain Ruby Conference in beautiful Boulder, Colorado next week.
If you’re going to be there, let us know. We’d love to take our relationship beyond our support email address (if you’re ready for that).
Gavin Stark and the Real Digital Media team are Campfire power users. Back in April, Gavin created a Hubot script to send Scout alerts to their chatroom. Now, they needed visuals:
We wanted to grab some of the graphics that Scout’s in-app page offers to users to provide us with visual feedback on historical norms for each metric without leaving the chat room. A call to Scout support got graphics ported into the API in less than a day, and we were off and running.
His sparkline update hasn’t been merged into the Hubot repo yet, but you can view his fork
Every man has their breaking point when it comes to deadweight code. Andre and I hit ours recently and decided to spend all of last week focusing soley on cleaning up Scout (a Rails app). Our goals:
- Faster tests – our tests took 8 minutes to complete. While it’s the perfect amount of time to catchup on Daily Show clips, it really tested our patience making application-wide changes.
- Removing deadweight – unused CSS rules, database tables + columns, views, and assets. It’s good having certainty that modifying code will change something in the application.
Here’s how we went about it:
We’ve added prolific plugin contributor Eric Lindvall’s latest plugins to Scout: Kestrel Overall and Kestrel Queue Monitoring. Kestrel is a simple message queue built from production needs at Twitter. Being the gentleman he is, Eric shared his experiences with Kestrel at Papertrail, a hosted log aggregation service.
As all good message queues should, it provides:
- transactional reads to prevent losing messages if a worker crashes before finishing processing a message
- durability to prevent losing messages if a queue server crashes or is stopped after messages have been sent to it
- “normal” queues (only one client sees a given message) and “fanout queues” (all clients see a given message, which many messaging systems call “topics”)
We picked Kestrel because it has bounded memory usage (it has a configuration setting to specify how many queued messages should reside in RAM, generally defaulting to 128MB), it’s small (I was able to read the entire Scala codebase in a weekend), and running on the JVM (which we have experiencing with) was a plus.
Last week, Sparrow became the latest poster boy for talent acquisitions (Google gets the team, kills the product). Paying customers complain (I supported it!). Indie devs get depressed as one of their rank sells out.
I disagree with Matt Gemmell that these are a good thing – this is not a feel-good rags-to-riches story. It’s about brilliant developers giving into reasonableness because they didn’t have the runway to be foolish.
There was a clear turning point for Andre and I with Scout – it happened in October 2009. It led to one of our most popular blog articles, “We Just Undid Three Months of Dev work. Here’s What We Learned.”
I’ll be telling that story at the Fort Collins New Tech Meetup tomorrow evening. If you’re a developer starting a business (or struggling turning a side project into one) drop by. If you’re interested in heckling me, stop by too!
We heard your feedback: adding charts to dashboards is a pain. No longer! Look for the Add Chart button on dashboards to add charts in one step. You don’t have to create a chart separately before adding it to a dashboard.
Big picture – we’re always looking for ways to make Scout easier to use. If there’s something clumsy or difficult you’d like to see improved, hit up the Scout suggestion page.
Recently in charts:
Josh Nichols of Rails Machine on their monitoring philosophy:
Measure all the metrics and alert on metrics that are actionable.
If you’ve got a bunch of servers, you’re going to want to read Josh Nichols’ How we roll with Scout article on the Rails Machine blog.
Rails Machine is a Ruby on Rails-focused managed hosting provider, which means they’re on the front lines when performance goes bad. From plugins to alerting, Josh details how they stay proactive on performance.