kellyfelkins.org

Citizen’s Briefing Book

Citizen’s Briefing Book was announced on Obama’s change.gov site today.

Share this article on

* * *

Tbone walking in the Park

My dog “Tbone” was hit by a car at the end of March. The doctors repaired his broken back but did not give us much hope.

Here it is 5 months later and he is mobile and playful in the park. I took some video today of him walking.

I’m really proud of him. I’m grateful that he’s alive. I’m grateful that he can walk. And I’m grateful that he is such a happy spirit in my life.

You can read the story of his recovery. It’s a blog, so if you want to read it in order, start at the bottom…

Share this article on

Comment

* * *

permalink

rav this!

Do you know about the Rails Application Visualizer.

RAV Visualization

This thing is about the easiest thing in the world to use. You got to love it when the instructions include:

3. Chuckle and execute rake visualize!

I keep the model view of my application on my desk. The text is getting so small I’ll soon have to either use a magnifying glass or at least print it on larger paper.

Share this article on

Comment

* * *

permalink

I'll rest later...

One of my early rails projects is a to-do list. But this is no ordinary to-do list. Think of it as a team to-do list. It’s called RestLater and you can find it at http://restlater.com.

Team? Yes, that’s right. It’s for teams. It helps you work together effectively.

The problem is simply this: Often there is a small group of people that need to work together to get some set of tasks done. Restlater is a service that allows you to specify the team members and the tasks. Then team members can go about their work. As they complete tasks they mark them completed on Restlater. Since all team members are viewing the task list on-line they all know what tasks are not complete, which have been completed and by who.

Simplicity

Restlater strives to provide this simple functionality simply. I hope that anyone can get started immediately. However it’s not simple enough — yet. Just be aware that simple will continue to be a goal for this service.

Security

I think one of the hardest things to do in ASP services is to guard against unauthorized access by authorized users. Think about that a minute. Guard against unauthorized access by authorized users. How do we as developers traditionally do this? Well, most of the time we put a bunch of “if” statements in our code. And we add “where” clauses to our SQL. Most of us code very carefully in these situations, and we hold our breath during releases. You always wonder if you covered every situation.

One approach is to push the access control down into something beyond the normal coding realm. Get it right there and you don’t have to worry. But this is normally pretty hard to do.

Restlater is implemented using Ruby on Rails. Rails has an object/relational mapping API called ActiveRecord. For this project I modified ActiveRecord, overriding many of the methods with versions that check access. The methods work the same, but they only operate on data that is available to the logged in user. I still add many of the normal ‘if’ statements so that the UI is friendly. But if I miss one, and an attempt is made to access, modify or delete a record that the current user doesn’t have specific access to, an exception is thrown — or in some cases the record is simply not found, as if it didn’t exist.

There is still a lot to be done to improve security. Rest assured, this is important to me.

There

A service like restlater needs to be there. If you can’t depend on it you will not use it. And it needs to be responsive. This is something I’m watching and will continue to improve upon.

Stats

One of the reasons for this blog entry is to record the project stats. Here they are:

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers              |    69 |    58 |       0 |       8 |   0 |     5 |
| Controllers          |   268 |   223 |       4 |      24 |   6 |     7 |
| APIs                 |     0 |     0 |       0 |       0 |   0 |     0 |
| Components           |     0 |     0 |       0 |       0 |   0 |     0 |
|   Functional tests   |   496 |   301 |       6 |      57 |   9 |     3 |
| Models               |   404 |   302 |      10 |      32 |   3 |     7 |
|   Unit tests         |   590 |   476 |       6 |      54 |   9 |     6 |
| Libraries            |    87 |    35 |       0 |       9 |   0 |     1 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  1914 |  1395 |      26 |     184 |   7 |     5 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 618     Test LOC: 777     Code to Test Ratio: 1:1.3

Share this article on

Comment

* * *

permalink

please don't feed the rails programmers

topicvote application screen grab

My friend Jane Macfarlane and I did a presentation at the East Bay Ruby Meetup on Thursday, December 14, 2006. After a brief introduction we created a Ruby on Rails application…live.

Writing code is challenging, but becomes truly sporting when you have 20 or 30 people watching you. When I told some developer friends that I was doing this, I got replies like “Oh, this should be exciting” — and I don’t think they meant that in a good way. Of course we rehearsed and scripted the event so it went smoothly, for the most part.

One exciting moment for me occurred when I was trying to install the acts_as_authenticated plugin. The command failed and I was briefly baffled, when an audience member asked if it required network access. Of course this was the issue, but the bigger question to me was whether I was going to bump into similar issues through out the presentation — thankfully, I didn’t.

The concept was to build an application from start to finish in the allotted time of 1.5 hours. I’ve done this before and knew the application had to be simple, but I also wanted something that was not a standard rails demo applications: blog, todo list, or recipes. I really wanted to show some key features of rails and I wanted the process to have at least 2 major phases in order to show incremental development. Jane and I settled on an application to allow people to submit and vote on future topics for East Bay Ruby Meetup meetings. We called the application TopicVote.

My thanks go to William Sobel for doing the normally thankless job of organizing this meetup and this particular event.

For those that asked for the presentation/demo material, here it is.

If you want to run the application, of course you will need to have:

mysql
ruby
rails

Then to install and run, you will need to:

untar and unzip the application archive (tgz) file
create the databases (topicvote_development and topicvote_test)
update the config/database.yml file with your specific database information
cd into the application directory, and …
run it (script/server)
Oh yeah, then visit the server with your favorite browser at http://localhost:3000

Here are the files:

Finally, during the Q&A we briefly discussed a program called DENIM. For information on DENIM, please check out my DENIM article.

If you’ve read this far, please consider rating me at Working With Rails.

Thank you.

Share this article on

Comment [319]

* * *

Older