Posted by charles
Sun, 26 Feb 2006 23:08:00 GMT
The rewrite project has us needing to support three different databases: Oracle, postgresql and SQLServer. Rather than take the approach of using MySQL as seen in “Agile Web Development with Rails” I decided to setup rails to use postgreSQL on my freebsd desktop and laptop. Installing this FLPR environment (freebsd, lighttpd, postgreSQL and rails) turned out to be straightforward despite some sketchy documentation. Those of you using freebsd may want to give this a try. As always it is important to become root to update the ports collection, then checking to see if any currently installed ports need to be upgraded before beginning.
Having done that, then as root cd to
/usr/ports/databases/postgresql81-server/
and do
make all && make install && make clean
This will install both the postgres server and client ports, and it will also have created a pgsql user along with a /usr/local/pgsql directory. This user will own all the data files and must also own the server process. Now the databse files and inital tablespaces need to be created. So, su to the pgsql user and then do
/usr/local/bin/initdb
If you want postgreSQL to start at boot, then make sure that postgresql_enable=”YES” appears in /etc/rc.conf. Don’t start an instance of the databse just yet, but rather exit back to being root and install the rails port. Just cd to /usr/ports/www/rubygem-rails and do the usual
make all && make install && make clean
Then cd to /usr/ports/www/rubygem-redcloth and do the same make sequence.
Next the C source code adapter needs to be installed. Unfortunately, neither the rails install nor the postgreSQL install will correctly set the lib path for building the adapter, so you need to set an environment variable otherwise the build will fail. So, as root do
setenv POSTGRES_INCLUDE /usr/local/include/
follwed by
gem install postgres
Now, a database instance can be started, so, su to the pgsql user and do
/usr/local/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
You will need to create yourself as a database user (actually, as a superuser). Here is how I did myself
/usr/local/bin/createuser charles
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) y
CREATE USER
If you feel more comfortable with a gui-interface for database administration, consider installing the pgadmin3 port.
Lastly, when you create your rails app, you will need to modify the config/database.yml file by commenting out all the lines except the postgreSQL entries and then modify those using the names of the three databases you need (ehr_* in my case):
development:
adapter: postgresql
database: ehr_development
username: charles
password:
host: 127.0.0.1
port: 5432
test:
adapter: postgresql
database: ehr_test
username: charles
password:
host: 127.0.0.1
port: 5432
production:
adapter: postgresql
database: ehr_production
username: charles
password:
host: 127.0.0.1
port: 5432
Using postgreSQL in a tiered environment is only slightly more complicated, and I’ll do a post about that sometime in the future.
Posted in ruby on rails | Tags charles, freebsd, lighttpd, postgresql, rails
Posted by rick
Mon, 20 Feb 2006 20:46:00 GMT
Check this out. Jonas Bengtsson has released a new screencast showing how to integrate Ruby and Selenium for browser-based acceptance testing. Bonuses include use of the Selenium IDE, Ruby test authoring, and automation of both IE and Firefox (on Windows, granted, but it’ll be cross-platform shortly, I have a feeling).
Very cool.
Posted in ruby on rails, testing | Tags automation, ie, rails, rick, ruby, selenium, testing
Posted by rick
Wed, 08 Feb 2006 21:31:00 GMT
Ruby on Rails is big on testing. There’s support for unit testing cooked right in—every time you create a model you get the unit testing framework built for free—just fill in the blanks. Similarly, whenever you create a new controller, you get the functional testing framework built for free—just fill in the blanks. Seems like view testing (with Selenium and OpenQA) is moving forward, and I wonder if some sort of automated support for those won’t come from the Rails framework itself soon…
That said, there’s very little talk about testing helpers—those bits of Ruby code that are made available for use by the view, but which aren’t in the templates themselves. Helpers aid reuse, and are a valuable use of Ruby behind the template.
Certain helpers can be tested with test/unit, just like unit tests for models. Some helpers, though, call functionality in the view libraries: a really common idiom is to provide various foo_link() methods that will generate links to certain types of objects. Rather than repeating the same detailed ActionView link_to() call everywhere, the code is factored out to a helper method which assembles the appropriate information and calls link_to() for you. Then you’ve got a single point of change whenever you want to change how comment links, story links, user links, whatever, behave.
Testing this sort of code should require a functional test, since you’ll actually want to have the view instantiated. There’s seemingly zero documentation on how to do this, and, checking around on some existing Ruby projects, I see people writing these sorts of helpers, but I see noone actually testing them.
We’ve jumped back for a moment and are relying on “stub” code to allow us to get a primitive, but less than ideal, test of our link helper (and other similar helpers that call ActionView functionality). We’re now looking for guidance from the Rails community.
To that end, we’ve posted Rails ticket #3775.
Posted in ruby on rails, testing | Tags bug, helpers, rails, rick, ruby, testing, ticket
Posted by greg
Mon, 06 Feb 2006 19:46:00 GMT
We had a brief introduction session about RJS templates (a way to automate AJAX actions for Rails) recently. The HOWTO document appears below.
We've also provided an mp3 download of the
audio from the presentation we had for the team.
Read more...
Posted in ruby on rails | Tags greg, rails, rjs, ruby, template
Posted by rick
Mon, 06 Feb 2006 15:11:00 GMT
Jon Tirsen pointed out that there’s what appears to be a full-featured Selenium on Rails plugin now available. We’ve been eyeing Selenium to help us with automating browser tests and acceptance tests, but have been sort of waiting for the dust to settle to see which approach at Rails integration is going to be the best. This plugin wasn’t even on our radar, but it looks really promising.
UPDATE: Speaking of not on our radar—there’s also a new Selenium IDE that’s a Firefox extension for (among other things) writing Selenium tests. Crazy.
Posted in ruby on rails, testing | Tags rails, rick, selenium, testing
Posted by rick
Wed, 18 Jan 2006 21:08:00 GMT
Sorry it’s been a while since I’ve given an update (we just cleared milestone08, fwiw, and I hope to have more for you shortly)—we’ve been making good progress, are having visitors from outside over the next couple of days, have had our heads down working hard, and are preparing for some internal presentations on our progress.
We recently had a big hiccup though. Just as we were working on hiring a new person to help out on the development team, our technical lead got a big offer out of the blue from a company in the, shall we say, financial realm. A bigger offer than we, as a non-profit (granted, a big non-profit but a non-profit nonetheless) can hope to match. So, long story short, we’re losing a real quality employee and member of our team. We wish him and his family the best and are excited for him in his new opportunity. Still, we’ve got a job to do, and we wish we could keep him.
But, we lower our heads and keep on keeping on.
So, now, in addition to needing to fill one highly qualified slot that we were going to expand with, we need to backfill another highly qualified slot to keep our momentum.
So, we’re looking. We’re looking for Good People… like the ones we already have (I wish we could clone them, but alas, we don’t have the requisite growth chambers installed yet…). Ruby experience is required, pretty much as is familiarity with Rails. We need people who can think in terms of architecture and domain models, can sit down and talk to users about how the system we’re building will work for them. We need people who like to work in a team, who aren’t afraid of unit tests and functional tests, who have a good sense of humor, who are excited about building awesome software, and who don’t break the build too often.
We’re working with cool tech, with slick processes, on a big project for a good cause. When we roll out the software we will just be beginning the process of improving the way we help people. Along the way everyone will learn a lot.
We’re in Nashville, TN. We can get some help from developers who aren’t in Nashville, but the real leverage comes from people who can be here to draw on the whiteboard with our developers, to point to code on the screen, to read the body language of the customer as he explains his job.
If you’re intrigued by the possibility of doing Ruby on Rails work in a cool town on a great project for a good cause (oh, yeah, for good money), then drop me a line.
Email me at rewritework at rickbradley.com.
Tags hiring, jobs, rails, rick, ruby
Posted by rick
Wed, 16 Nov 2005 16:32:00 GMT
In September (or so) we went through the process of trying to decide whether we wanted to keep plowing through the JBoss Java stack we were building with or to pursue an alternate technology. We did some test prototyping of part of our first component (of 6) in Ruby on Rails and then a test re-implementation of the full component in Ruby on Rails.
The productivity increase (and code footprint decrease) was basically staggering. We undertook a full analysis of the consequences of shifting our development from our Java stack to a Ruby on Rails platform. Ultimately we decided to shift from Java to Ruby on Rails.
The summary document of the issues (edited to protect the guilty :-) can be found on this site at Evaluation: moving from Java to Ruby on Rails for the CenterNet rewrite.
Posted in java, ruby on rails | Tags java, rails, rick, ruby, switch
