Hotspotr partners with LightPole for Mobile

no comments Comments

Andre
Andre
18
Mar

Hotspotr -- my community-driven WiFi hotspot site -- announced a content-providing partnership with LightPole today. You can read the press release over at http://lightpole.net/press/index.html.

Hotspotr lists over 8,000 user-contributed WiFi hotspots. LightPole provides a mobile client you can use to browse Hotspotr from your mobile phone using an interactive, maps-based interface:


You can download the LightPole mobile client for free from the Hotspotr homepage.


Separately, Hotspotr is also taking advantage of the Google Maps streetview functionality. For locations where streetview is available, you will have the option to browse the 3-d streetview imagery:



See an example at the Dolores Park Cafe in San Francisco.

Wow!

no comments Comments

Derek
Derek
18
Mar

We thought you’d like Scout – but we didn’t expect to reach our 100 account limit in about an hour and a half.

We’re already collecting feedback and gearing up for the next launch.

Don’t worry if you didn’t get in this time – we’re collecting lots of feedback for our full launch.

If you’re need some more help getting Scout configured, have some feedback, want help writing a plugin, or just want to chat about Scout, drop by our public chat room or forums.

Thanks, and stay tuned for the launch!

VPS options + nginx w/ deprec

1 comment Comments

Andre
Andre
26
Feb

Staging environments are the perfect excuse to dig into new server configurations, and to play around with tools like Deprec. I have covered the gruesome technical details of the process over at Andre on Tech:

Overall, I'm impressed with how much deprec does for you. I had my staging environment setup in a few hours. Enjoy!

Hands on with Scout at Atlanta Ruby User Group

Posted in Scout, Presentations, Atlanta | 3 comments Comments

Cbq
CBQ
14
Feb

Last night, I demoed Scout to a room-full of Rubyists at the Atlanta Ruby User Group Meeting.

I would love to share all the wonderful feedback, but instead, I’ll share some of the excellent questions (and more elaborate answers) that were asked of Scout:

What are the security pitfalls, i.e. can someone simply write a ‘rm -rf’ plugin?

To answer that, let’s look at the architecture of Scout first:

  • You install the tiny Scout client (which is a Ruby gem) on your server.
  • The client connects over https (always) through a 256-bit secure, encrypted connection (the same encryption your bank uses).
  • Scout never logs in to any of your servers.
  • All communication is initiated by the client.
  • The client downloads a pre-loaded plugin plan, consisting only of plugins of your choosing, so it cannot run plugins you didn’t explicitly authorize.
  • The server also uses that same secure encryption for all communication. Individual accounts are protected.
  • Client keys (uniquely generated) can be revoked at any time, disabling the client.

The security measures needed for Scout are the same as for any other software. In fact, in some ways, it’s easier to be more secure – the plugins are relatively few lines of code and easy to review. For a more closed environent, you can create a copy of the plugin code and host it on one of your own servers (a plugin is plain text).

Is Scout open source?

The Scout client is completely open source. The gem is a normal Ruby gem, open for development, and distributed under the MIT and/or Ruby License (whichever you prefer). The Scout Plugins people write are also completely open, in fact, they are surrounded and fostered by a community that encourages branching, fixes, and general open-ness.

The Server, where you aggregate your data, do reporting, and in general, collect information about your account is not open-source. We maintain the server, and keep all your data safe and sound.

When does it launch?

We’re doing the plumbing now – account subscriptions, a new home page, privacy policies, backup procedures, etc. We’ve recognized that lots of people are anxious to get going and we’re working to get it ready for public use as fast as possible.

Lessons from the Trenches at Acts As Conference

Posted in Ruby on Rails, Speaking | 3 comments Comments

Cbq
CBQ
11
Feb

For those who missed my talk at the most excellent Acts As Conference put on by the good folks at Rails For All in Orlando, Florida—here’s the cheat sheet.

My talk was on the lessons learned from teaching the Ruby on Rails Bootcamp and various on-site Trainings over the past year and a half. Here are the 4 key things you need to do to be a successful trainer:

Define Your Purpose – Come up with a clear, specific, desired outcome. Are you attempting to teach the basics, or promote mastery? A quick how-to, or a detailed guide to a particular way of development? A clear purpose helps your audience hit the ground running. An unorganized braindump can leave your students frustrated when they go at it alone.

Know Your Audience – You’ve got to understand everything you can about your audience. This means not only their current level of knowledge, but their past experiences, and even their goals. Ask questions before and during your training to understand everything you can about them. This will help immensely with the next tip.

Give Relevant Examples – Cater your examples to the domain that your audience knows. If you are teaching a bunch of journalists, use concepts from the publishing world. Never use foo, bar, or any other made up word in any example. If you don’t know, guess, and if your audience corrects you on the concept, you now have attentive listeners, contributing to your solution!

Teach How to Learn – Show, don’t tell. Stress how to find out why something works the way it does. Give plenty of examples, and help your audience figure out concepts. Give them the resources to continue learning and to find out more. Show them how you figured it out, or where you went to learn.

I’m sure there are plenty more tips, but I’ve found these 4 to be extremely valuable to me in coming up with valuable lessons and ways of teaching. Thanks to everyone who came up to me afterward to ask questions and share feedback about teaching!

Auto-Login for Any URL in Rails

Posted in HowTo, Ruby on Rails | 1 comment Comments

James
James
06
Feb

One of our current projects at Highgroove sends a lot of email to its users. It essentially walks them through a process and emails them at each step. All of those messages include URL's to visit the relevant page in the application for that step. Since we've emailed them the URL's we don't want them to have to login every time they click one.

To get around that I modified the application to accept URL's like the following:

http://domain.com/login/TOKEN/ANY/SITE/URL

These URL's log the user in using their security TOKEN and then redirect them to /ANY/SITE/URL. This setup allows me to easily forward a user to any URL on the site which is great when writing all of these emails.

The code is easy enough too. I imagine many of us have a sessions controller that looks something like:

class SessionController < ApplicationController
  def create
    if user = User.authenticate(params[:email], params[:pass])
      # log user in...
    else
      # login error message...
    end
  end

  # ...
end

First, I just added some support for the token based login with redirect to that:

class SessionController < ApplicationController
  def create
    if params[:token] and (user = User.find_by_token(params[:token]))
      # log user in...
      if params[:path].is_a? Array
        redirect_to "/#{params[:path].join('/')}"
      else
        redirect_to home_path  # or whatever default page you want
      end
    elsif user = User.authenticate(params[:email], params[:pass])
      # log user in...
    else
      # login error message...
    end
  end

  # ...
end

The magic redirect_to() call in that new code uses a not-often-seen feature of Rails's routing. You can specify that Rails collect any number of trailing URL bits into an Array much like Ruby can do for method parameters. Here's the route definition I am using to get users to the code above:

# a custom login route with forwarding
map.connect "login/:token/*path", :controller => "session",
                                  :action     => "create"

The *path is the magic slurping parameter syntax, again just like arguments to a Ruby method. Rails will collect each piece of the remaining URL into an Array called path, so just remember that you need to rejoin the elements to make them a real URL again.

Graphing Rails Performance With Scout

Posted in Scout | no comments Comments

Derek
Derek
29
Jan

We’re using Scout, our monitoring and reporting application, to graph the performance of our Rails applications and servers.

I’ve uploaded a video that looks at how one of our applications, PlaceShout, impacts the server load and Mongrel memory usage. I also compare PlaceShout’s footprint to another server.

Watch the video: Graphing in Scout (1 min 47 sec)

Past Videos on Scout:

Installing the Scout Client (1 min 39 sec)

Installing the Rails Requests Plugin (1 min 55 sec)

Signup for our launch email list

We’ve started emailing invites to Scout. Signup on our homepage, and we’ll give you access to Scout before the public launch.

See PlaceShout, Other New Apps at SF Beta Tonight

Posted in PlaceShout | no comments Comments

Derek
Derek
29
Jan

Andre and I will be at SF Beta tonight demoing PlaceShout, our short-form local reviews service.

We’re among 10 companies showing off their latest innovations (view the full list).

More information on tonight’s event is here.

Hope to see you there!

Making it easier to eat healthier

no comments Comments

Derek
Derek
28
Jan

Better = more work. Tools that “make better easier” are rare.

I heard a radio advertisment for Safeway’s FoodFlex Program this morning. When you purchase groceries at Safeway and use your Safeway Card, Foodflex analyzes your purchases and suggests healthier alternatives. The program is accessed through the Safeway website.

Dieting often means counting calories. It makes dieting more work than not dieting. Foodflex can do the counting for you. Sure, Foodflex can’t track meal-by-meal, but you get a reasonable overview of your eating habits based on your grocery purchases. A couple of healthier suggestions a month is an easier, more sustanable path to eating better than religiously counting calories.

Web App Service Plan Subscriptions

Derek
Derek
22
Jan

We’re working on our subscription plans for Scout. While working on the plans, we took a look at what other subscription-based services are charging for access.

There are some definite similarities, but a couple of peculiar differences.

Below is a quick sampling of what we found:

Service Plan Options* Credit Card Required?^ Free Plan Generosity
Basecamp
Project Management
Free
$12
$24
$49
$99
$149
Yes Gives you a solid overview. You’re walled into 1 project, can’t upload any files, but you can invite unlimited people, create todos, send messages, etc.
Highrise
Contact Management
Free
$12
$24
$49
$99
$149
Yes Very limited. 2 users, no file storage, and a single case (a way to group items together). It’s difficult for us to judge it unless we’re all using it to share information, and we can’t do that with the free plan.
BlinkSale
Invoicing
Free
$12
$24
$49
Yes Very nice. Only major limitation is 3 invoices per-month.
FamSpam
Family email, photo gallery, and archive
Free
$12
$24
$49
No Free Plan is pretty open – 4 family members, 10MB of storage, 100 photos.
Wufoo
HTML Form Builder
Free
$9
$24
$69
$199
Yes It’s enough. You’re limited to 3 forms, 3 reports, and 10 fields per/form. No file storage.
FogBuzz on Demand
Bug Tracking
$25 per/user No N/A
CrazyEgg
Web Analytics Visualization
Free
$9
$19
$49
$99
Yes Very generous. Track 4 pages, limited number of visits. Stats are updated in real-time, limited tracking and sharing.
* - All prices per/month
^ - Only applies to paid plans

All of the services but BlinkSale and Wufoo are dramatically more useful with more people. Why then does Highrise’s free plan only allows 2 users (initially it was a single user)? 37Signal’s older product on the list, Basecamp, has unlimited users on the free plan.

37Signal’s pricing model is widely copied (free/$12/$24/$49).

FamSpam and FogBuzz on Demand allow you to signup for a paying plan without supplying a credit card. I assume after 30 days you need to enter credit card information. It’s an interesting idea because sometimes you don’t know if you need an advanced feature until you try it. The tricky part about this strategy is handling accounts that don’t decide to pay. Do you suspend all functionality or just parts of the application that paid plans can’t access? How to you handle access to data they may no longer have access to on a free plan?

On the surface, CrazyEgg appears to be the most generous with their free plan. Many people may only want heat maps on a couple of pages anyway and how often the data is gathered may not be a major factor. There are a lot of people that could use their free plan perpetually.

Being too generous isn’t necessarily a good thing. It takes time and resources to support free accounts, and that can take away from enhancements and service offerings to paying customers. Blinksale may have the best balance. You get most of the features, and if you’re willing to pay for an invoicing solution, you’re probably sending more than 3 invoices a month.

Older posts: 1 2 3 4 ... 11