no comments 
Derek
It hurts – it feels like giving up. You’re stuck on a problem and do the last thing that makes sense – stop thinking about it. And the minute you forgot about the problem the solution comes into focus. Sometimes it’s a shower, for others it’s a long walk or playing a video game.
The Eureka Hunt – Why do good ideas come to us when they do?, an article by Jonah Lehrer published in the the July 28th issue of the New Yorker, covered scientific research on moments of insight. There were a couple nuggets on provoking insights:
Simmer down the focus.
Avoid things that help you focus (like caffeine).
If you’re in an environment that forces you to produce and produce, and you feel very stressed, then you’re not going to have any insights…Concentration, it seems, comes with the hidden cost of diminished creativity.
John Kounious, Cognitive Neuroscientist, Drexel University
Set the alarm clock a few minutes early
The drowsy brain is unwound and disorganized, open to all sorts of unconvential ideas. The right hemisphere is unusally active.
Get in a good mood
Jung-Beeman’s latest paper investigates why people who are in a good mood are so much better at solving insight puzzels (On average, they solve nearly twenty per cent more C.R.A. problems.)
Posted in Speaking | no comments
CBQ
We’ve had the pleasure of working with Matt Todd recently on several Highgroove projects.
Matt’s going to be speaking at RubyFringe, “an avant-garde conference for developers that are excited about emerging Ruby projects and technologies” on July 18-20, 2008 in Toronto, Canada.
And while there is a very clever joke I could insinuate about Matt’s talk entitled Being Dumb And Using It To Your Advantage, on Matt being “the expert on dumb,” I can’t quite come up with it—and then there’s the fact that he is actually really frickin’ smart.
If you’ve ever thought of an idea, only to convince yourself “eh, that’ll never work, that’s a dumb idea”—his talk will make you think otherwise.
2 comments
Derek
Andre, Charles, and myself leave for RailsConf Thursday.
If you want to discuss Rails monitoring, Javascript, the business of Rails, biking, camping, or dogs, talk to us!
I’m the tall, skinny scarecrow-like figure with the big head. Charles looks like he might belong to a hipster boy band. Andre…well he looks completely normal. Just look for the scarecrow and the hipster – Andre will be the other one in our group.
11 comments
Andre
Passenger, AKA mod_rails
There are a number of posts (one, two) out there on getting Phusion's Passenger up and running on OSX (Leopard). I decided to give it a go, and was pleased to discover several things:
- Despite reports to the contrary, Passenger installed just fine with Leopard's built-in Apache (I'm running Apache 2.2.8).
- Setup is very easy, as advertised.
- My default doc root(~/Sites) is works exactly as it did before. I do some HTML and PHP work there, so it was key that it continue to work properly.
Since the install process itself is quite easy, I wanted to offer a few tips for utilizing Passenger in a typical dev environment -- i.e., what you need after you get your first Passenger-powered Rails app up and running.
Your Brain on Passenger
As you know, script/server starts your Rails app on a specific port. If you bounce around between a number of applications at any one time, you're probably used to either starting them on different ports, or control-c'ing your current mongrel, cd'ing to another app's directory, and script/server'ing again. This familiar pattern changes when you're running passenger. All your apps are available at any one time, as long as you have your vhosts configured.
If you're like me, you usually hit your currently running Rails app on http://localhost:3000. That also changes when you're running Passenger. Instead, you'll hit a unique URL for each app, which you've configured in /etc/hosts to just go to 127.0.0.1
Setting up a new app
I set up a lot of Rails apps in my dev environment. With Passenger, in exchange for the on-demand convenience of accessing any of your apps any time, there are a few additional setup steps to take whenever you introduce a new app into your dev environment.
- create your rails project as usual
- add a new vhost. I configure mine in
/private/etc/apache2/extra/http-vhosts.conf
- add the host in /etc/hosts
- restart apache: sudo apachectl restart
Here's a vhosts example with two apps I'm running locally. You can set up as many apps as you want this way:
<VirtualHost *:80>
DocumentRoot "/Users/andre/projects/rails/hotspotr/public"
ServerName dev.hotspotr.com
ErrorLog "/Users/andre/projects/rails/hotspotr/log/error.log"
</VirtualHost>
<VirtualHost *:80>
DocumentRoot "/Users/andre/projects/rails/shapewiki/public"
ServerName dev.shapewiki.com
ErrorLog "/Users/andre/projects/rails/shapewiki/log/error.log"
</VirtualHost>
Two things to note here:
- The ErrorLog line is optional. If you don't include it, the error output for this app will go to
/private/var/log/apache2/error.log. Not that that's bad, but you're probably not used to looking for Rails logs there.
- I decided to go with the convention of dev.[PRODUCTION_URL].com. You can use anything here, as long as it matches up with an entry in /etc/hosts (see below)
And here's an example /etc/hosts addition to match the two virtual hosts above:
127.0.0.1 dev.hotspotr.com
127.0.0.1 dev.shapewiki.com
That's it! Go to (for example) http://dev.hotspotr.com, and you're hitting you local development app. There is nothing to start and stop. The first request for any app you hit will take a moment. Subsequent requests will feel quite snappy.
Let's Set up some Aliases to Make it all Flow
Here are the aliases I added to my .bashrc file to give me quick access to everything I needed for a new, Passenger-centric workflow in my development environment:
# Use this in any RAILS_ROOT dir. That restart.txt file tells mod_rails to restart this app.
# You'll want to do this when (for example) you install a new plugin.
alias restart_rails='touch tmp/restart.txt'
# By default, your app's error log now goes here. Unless you configure your apps otherwise,
# it's helpful to have an alias to take you to your error log quickly.
alias apache_logs='cd /private/var/log/apache2/'
# You'll be adding to your vhosts configuration everytime you introduce a new Rails app.
# Might as well make it a shortcut
alias vhosts='sudo vi /private/etc/apache2/extra/httpd-vhosts.conf'
# Dito with hosts
alias hosts='sudo vi /etc/hosts'
# You'll need to restart apache whenever you make a change to vhosts.
# You can also click System Preference->Sharing->Web Sharing, but this is quicker.
alias apache_restart='sudo apachectl restart'
3 comments
CBQ
A while back, we wrote an article on Running Background Jobs in Ruby on Rails.
The Ruby on Rails framework has a number of tools for running your code outside of the web-request, including the venerable script/runner for one-off tasks, but using them can be a little heavy on your server. If you want to run a task on the minute, or on demand, script/runner will load your entire Rails environment, which can be from 20-50 MB, depending on how many libraries and how much code you’re pulling in.
There are also a few other good guides, recipes, and libraries that we’ve mentioned before, including:
We’ve found that it’s not terribly hard to build your own job server that runs continuously in the background and can handle all kinds of jobs, including those that should run on a specified interval. Here’s how we did it.
Read more... 
no comments
CBQ
Come see us talk about Scout Server Monitoring and Reporting at StartupRiot on May 19, 2008, and watch all the other startups present their wares. This looks to be a really great event.
See ya there!
no comments
Derek
You need to be in the Bay Area. You shouldn’t be in the Bay Area.
You need to work crazy hours. You shouldn’t work more than 4 days a week.
You need to raise as much money as you can. You shouldn’t raise money.
The topics above never seem to get old and I think it’s unfortunate.
Just run your business the way that feels right. The majority of your time during the week is spent working. Whether you’re working for yourself or for someone else, if you’re not working the way you want to, it won’t last.
Posted in Scout | no comments
Derek
Scout, our server monitoring and application, is now available for public consumption.
Scout is for the 95% of us that either gave up on installing & maintaining monitoring applications or used the old fashion monitoring method – an email from a customer when your web application is down. I’m not calling you out, it’s simply that monitoring used to be more painful than
not monitoring. We think Scout changes that in a beautiful way.
Scout makes it easy to bring all of your data together – from the monitoring standbys (url monitoring, server load, memory usage, etc) to modern day analytics (the number of user accounts on your web application, unique visitors, inbound links, etc). It’s all done through an easy plugin system that you configure through our web interface – you never have to login to each of your servers and install or edit monitoring scripts. You’re not limited to the plugins we built – you can roll your own with a couple of elegant lines of Ruby code.
no comments
Derek
We’ve used Scout for several months internally. Along with Colloquy, Google Docs, Basecamp, and Skitch, it’s one of the few apps I use every day.
We think this makes Scout a better service – we’re not watching Scout from a third-person perspective. However, sometimes things sneak through – the type of things that don’t bother you after using an application for months but can be hurdle to others when getting started.
There were 2 nagging issues that stood out in the Scout user experience. I’ll cover how I addressed the first one here.
Read more...
no comments
CBQ
The success of our Scout monitoring tool’s Beta has been amazing. We appreciate all the feedback we’ve received so far.
We’ve decided to spin-off a separate product based on Scout. It’s called Skraut. Just as Scout can monitor a server to know when it’s in trouble, Skraut can monitor your significant other, to know when you’re in trouble.
We hope you like it. Remember to signup for the Beta program, launching soon!
Skraut – Sneaky People Monitoring Software
