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 corey
Fri, 24 Feb 2006 20:25:00 GMT
I’ve only been here a few days, so I’m still trying to come up to speed on how everything is working. They’re using CIA to do their continuous integrations after each svn commit. They then have a bot on our local irc server that announces whether the build is broken after the recent commit. While it’s nice to know whether the build is broken or not, I wanted to know the commit message and what files were touched. Enter Kevin Ballard’s svnbot. They used to use this in typo but they’ve apparently stopped in the last few months. The major bonus here is not having to go to our local trac server to see what files were modified and what the other developer had to say about the code they just committed.
Posted in subversion | Tags integration, rbot, svn, svnbot
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
Sat, 18 Feb 2006 18:46:00 GMT
There’s been some interest from people who want to set up “IE on Linux” as we mentioned we were doing to help with automating IE testing. As you’ll see, the process is merely a testament to the hard work done by others to make this not only possible but easy.
First off, make sure you’ve got licenses for the software you’re installing. I’m not pretending to be a lawyer, not pretending to interpret the Microsoft EULAs that might apply. I think it’s safe to say you’d better have licenses on hand.
I’ll be assuming you don’t already have Wine installed and that you don’t already have a ~/.wine directory already. If you do you’ll need to take that into account. I’m installing on Debian (unstable), but I’ll be installing from tarballs, so as long as you’ve got the dependencies needed to compile wine you should be ok.
Ok, it’s just this simple:
- download the 0.9.7 Wine
tarball here
- tar xvj wine-0.9.7.tar.bz2
- cd wine-0.9.7
- ./tools/wineinstall
- cd ..
- tar xvfz winetools-0.9jo-III.tar.gz
- cd winetools-0.9jo-III
- su
- ./install
- exit
- cd ..
- wt
- do Base Config
- create a Fake Windows Drive
- Install TrueTypeFont Arial
- Install DCOM 98
- Install Microsoft Foundation Classes 4.x
- Install Internet Explorer SP1 English
Now, if like us you are behind a proxying firewall, you’ll have a headache when trying to install IE since the installer doesn’t typically see your proxy. To install from behind the proxy you’ll need to do the following:
- Wait for the download to eventually time out and fail.
- Click “Advanced”
- Click the proxy checkbox, then fill in our proxy IP and port.
- (For some reason I had problems typing in the proxy info boxes and had to use cut-and-paste to get the info in there(?!).
When you’re done, exit out of Winetools. Now you’ve got a .wine/ directory with a “C drive” with IE6 installed. I’d advise backing up .wine/ so you can recreate this configuration with a one-liner (now, don’t you wish that working with Windows was always this easy? Heh.)
To run IE now, simply run IE:
% wine ”$HOME/.wine/c/Program Files/Internet Explorer/IEXPLORE.EXE”
You can append arguments for IE to the end of the command-line.
I’ve verified that Javascript does indeed work, but PNG support is still missing. I haven’t had a chance to try the things mentioned in this forum yet to see if I can get PNGs working. Any feedback on that issue is welcome.
Posted in testing | Tags ie, linux
Posted by rick
Thu, 16 Feb 2006 21:22:00 GMT
We ran into a problem once we installed the RJS templates plugin. Turns out the problem isn’t just in the plugin, but also in edge rails. We wrote up a quick patch that fixed the problem and then wanted to pass the info upstream.
After talking briefly with the maintainer of the RJS templates plugin (Cody Fauser) we were pointed to the proper Rails file to put our test in. So we wrote up a quick actionpack unit test for the problem and tried it out. Yep, there it was.
So we filed a ticket with a patch & unit test: #3861.
Posted in ruby on rails | Tags 3861, patch, rick, rjs, templates
Posted by rick
Tue, 14 Feb 2006 22:22:00 GMT
Taking the advice of Peter Merel from the last post, we're beginning to pursue the automation of browser-based testing for the project. Automation to me means Linux (no way in hell I'm going to try this on Windows, that's just a rabbit hole), so I set up Microsoft Internet Explorer 6 on Linux this afternoon. I'm not sure if this is sacrilege or making the best of a bad lot.
Either way, here's proof:
Posted in testing | Tags ie, linux
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
Fri, 03 Feb 2006 21:25:00 GMT
We landed milestone09 (actually, the 10th milestone of the project) on the first of February. Here’s a peek at the ‘rake stats’ output. Compare and contrast with the stats from milestone05. There’s (as would be expected) more stuff in all respects than 2 months ago, and we have much more functionality. (Some informed readers may note that we’re still not even halfway to the linecounts of “stuff” we had in our early Java version of the project—which had zero documentation, zero tests, and comparatively minimal functionality).
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers | 342 | 223 | 1 | 22 | 22 | 8 |
| Controllers | 1663 | 942 | 11 | 87 | 7 | 8 |
| APIs | 24 | 5 | 1 | 0 | 0 | 0 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Functional tests | 2538 | 1931 | 30 | 199 | 6 | 7 |
| Models | 2144 | 812 | 38 | 54 | 1 | 13 |
| Unit tests | 3305 | 2321 | 29 | 275 | 9 | 6 |
| Libraries | 1203 | 672 | 14 | 74 | 5 | 7 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 11219 | 6906 | 124 | 711 | 5 | 7 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 2654 Test LOC: 4252 Code to Test Ratio: 1:1.6
Though we didn’t publish it at the time, we’ve seen test-to-code ratios as high as 2.0:1 but are back down to 1.6:1 now. The primary reason for the drop is that we’ve added a lot of new models in one quick push, but haven’t yet put them to use, and haven’t added tests or controllers for them.
Why is that? (Clearly we’re not a TDD shop, but we should at least have tests for our models, right?) Well, we’ve been domain modeling our next major component—the clinical component of the system (client charting, collection of observations, evidence-based clinical guidance, support for clinical protocols, etc.) and we conducted a quick spike to see if we could fit some complex datasets into our data model (e.g., the DSM-IV-TR diagnosis tree). To do that you’ve got to build the tables in the database and load the data. Well, if you’re going to do that, you might as well put ActiveRecord models on top so that the structure and navigability of the data can be explored with Rails rather than with cumbersome SQL. So, we built the models, but we’ve not yet moved on to put the unit tests on top of the models. We’ll get there shortly.
Something else—the overall amount of “stuff” we generate has gone up a bit because we’ve created a lot of RDoc documentation. Rails makes this so easy I’m almost ashamed I put it off for a while, thinking the developers could get overwhelmed with all the New Ways of doing things. Suffice it to say, RDoc is easy, and running rake appdoc is pretty simple too. We have our public subversion tree pull doing a ‘rake appdoc’ as well so anyone can browse the API documentation from anywhere in the company. Hey, it’s nice for us when we’re away from our desks. :-)
Having been distracted slightly by the personnel process (things are going well on that front: let’s just say that the “conventional wisdom” that you just won’t find Ruby/Rails programmers (much less good ones) out there is complete and utter nonsense), we’re now pretty deep in domain modelling and ramping up the process of working with users and experts on the clinical front. This will probably slow our coding down somewhat, but will result in really solid progress for the project overall.
Current headaches include miserable support for common AJAX idioms in Internet Explorer—which, I shouldn’t need to remind you was the place where AJAX was actually conceived. You’d think IE would provide good support for that which they invented. (You’d be wrong.)
Since we don’t yet have browser-based testing in place (though we’re planning to investigate Selenium, if not Watir), knowing that AJAX functionality is working—much less, continuing to work—is a headache and a time sink for us. We’ll be actively working to address that in the near future.
We’ve moved into the realm of web services—one of our guys is working on bringing a Java applet designed to control a signature pad device into the project. Being early adopters (heh) we decided to use SOAP and/or XML-RPC (and I think I caught a faint odor of WSDL in the air this week). Everything worked smashingly, easily, quickly well until the code landed in the tree and the functional tests blew up for no apparent good reason. Suffice it to say that if you’re doing SOAP development with Rails you probably want to be aware of this ticket, and, yes, the patch works flawlessly.
That’s the first time we’ve had a situation where the developer pushed working and tested code to the integration server and it broke and there was nothing that the developer could have done to prevent the build from breaking. Those things are going to happen, so just expect them. We were lucky in that the Rails community is so active that it took us 10 minutes to go from broken build to fixed build: run the build, put the error message into google, find the patch, apply the patch, run a test build, commit, done. Very nice.
Posted in project | Tags milestone, rick, stats
