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
Posted by rick
Fri, 03 Feb 2006 20:33:00 GMT
I’ve invited a number of the other guys on the project to the site to post articles, comments, etc. Not everyone may decide to post, but there are now 5 more potential authors on the site. Surely that’ll mean more Rails discussion, more enterprise software discussion, more … discussion.
Tags rick, site
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, 21 Dec 2005 23:20:00 GMT
A commenter to the previous post was kind enough to ask some good questions, so it seems only fair that I make a fair attempt at answering them. I’m taking the liberty of re-ordering things, however. (I had really hoped to update more frequently, but time is scarce at work and at home, during the holiday season, even more scarce!)
What do you guys use for all this? Server platform? Dev platform? Any nix platforms in the mix? Any experience on deving on windows and server on nix?
We’re currently in development, meaning that we don’t have a real honest-to-goodness production system running yet. The closest thing we have to a production system is a machine that does our continuous integration for us, as well as hosting our nightly and milestone build sites. It happens to also run our subversion repository and our trac installation, but that’s coincidental (we assigned DNS names for trac, svn, milestone, and nightly so that we could move them whenever we see fit). It also sports an RT installation for feedback, but that’s coincidental too. That system is running Debian Linux (apt-pinned from stable to unstable, and a 2.6.12 kernel) on an Intel P4 2.8GHz CPU w/ 1GB RAM. It’s running Debian exactly because I set it up and do the admin on it. We do our Subversion work over ssh (svn+ssh://...). The RT instance is running on Apache2 w/ mod_perl. The nightly and milestone app builds are hosted on lighttpd using FCGI to run Rails. Taken together, we have Apache2 fronting the lightppd instances via proxying. That is, if you hit nightly:80 then you hit Apache, which sends you to nightly:8001 behind the scenes.
We have developers currently using the following platforms: Windows XP (2 full-time, 1 DBA doing occasional checkouts and builds), Debian Linux, FreeBSD, and I think some other random Linuxen. While we have AIX systems available in-house noone is chomping at the bit to develop on them, and we haven’t tried to deploy to them. So, yes, we do have some experience doing development on Windows with servers on Unix-ish systems.
When we go to production, we will almost certainly be using Linux for the front-end (i.e., non-database) servers, but there’s a vocal FreeBSD contingent in house, and they make a strong case. If I have any work to do on those servers I would demand that Debian be on them, but I would prefer that we have an actual Manager Of Production and he take the keys away from people like me who’d be more likely to ‘rm -rf’ something than not.
Also highly important to us is protecting client data. The legacy system the company currently runs on is locked up pretty tightly, and any test or development systems are populated with anonymized data. For HIPAA and Sarbanes-Oxley we need to ensure that we continue that tradition with the new system we are writing. Of course, so far we haven’t even purchased the servers that will be used to run the system, so setting up the production environment is cart-before-the-horse. That, and re-tasking developers and data conversion folks away from their jobs to prepare for something we really won’t need to think about for months doesn’t make sense to me. So, for now we don’t have a production system or environment yet. I also can’t argue with waiting as long as possible to buy hardware, and putting Moore’s Law to work on our budget.
What apps do you use? CIA? Switchtower? Trac? SVN Of course. Desktop editors?
We are (obviously) using Subversion (SVN) for version control.
For continuous integration we’re using the simple continuous_builder Rails plugin. We had been using CruiseControl when we were working with Java. While CruiseControl really could be considered platform/language agnostic (ok, at a stretch), it’s really geared for Java projects. I took DamageControl for a spin (I know one of the contributors and saw Aslak at RubyConf—he’s a sharp guy and right on top of the mailing list), but ultimately didn’t stay with it. While CruiseControl is simply monstrous, requiring a beefy machine to get it going, DamageControl is relatively lightweight. I like the idea of being able to use a Rails web interface to manage the various aspects of the project build, to catalog logs, etc.
From reading the mailing list I understood that DamageControl needs to be pulled from SVN to get the newest Rails-based version in a working form. First I hit our corporate proxy (I have no love for this abomination known as “BorderManager”, which would be better replaced, if a proxy is truly necessary, with a fresh install of squid) which made doing an SVN pull a no-go. So I had to do a pull from outside the firewall, tar it up, and suck it down over the web (don’t ask), which is what would be necessary whenever I wanted to svn update in the future. I then set about getting things going and got the web interface up and things purportedly properly initialized. Then I spent about 20 minutes trying to get a project entered in such a way that it would (a) try to do an SVN pull and (b) remember that the project actually existed. Seems I couldn’t on that particular day get both to happen at once for some reason. Then the interface started behaving funny (but which I think was mostly the stylesheet going missing(?)). Then I read more mails on the mailing list with more problems getting things going. I looked at my watch and said to myself, “It’s worth my time to take a look at continuous_builder rather than digging deeper into DamageControl right now.”
So I did, and got continuous_builder set up in half an hour. I spent a little more time looking for a good IRC library for Ruby that would let me post build status into our development group’s IRC channel, but to no avail (as in nothing that would let me write a client really quickly to do that one simple thing). I broke down and wrote a quick Perl script using Net::IRC to enter the room, post a message, and be gone. Seems to work. I’ve considered porting Perl’s Net::IRC straight to Ruby, but that may be a rainy day indeed when I get around to it.
So, back to the questions. On the desktop we are mostly vim/gvim (including one guy on Windows using vim (or is it gvim on Windows?)). The only full IDE we have going is one user using ArachnoIDE on Windows and who seems to like it very well. I’ll have to admit that I’ve been tempted to try development with it or with FreeRIDE (having been impressed with the underlying architecture of FreeRIDE). When we were working with Java we had pretty much standardized on using Eclipse, with the occasional vim hold-outs. We discovered pretty quickly that you have to be either a masochist or about a 3-4 sigma productivity developer to make a strong showing with JBoss/J2EE using a text editor like vim. Once we moved away from Java we realized that we could go back to using text editors again as we didn’t have to manage tens of thousands of lines of XML and thousands of lines of code shortly after coming out of the gate.
We’re not (yet) actually using SwitchTower, but intend to in the future. We’ve currently got a database server running both Oracle and Postgres (SuSE enterprise Linux) for development and testing. We aren’t yet using Migrations either, mostly due to the fact that Migrations was coming along as we were figuring out how to minimize the database dependence in our SQL creation, drop, and load scripts. We took the same general algorithm we were using with our Java environment with Ant and brought it over to our Ruby environment with Rake. We have plenty of constraints, a few triggers, a couple of database-level functions, etc. I now believe I know how we would get the normal table stuff (probably 90% of what we have) to work with Migrations while integrating the oddball stuff into Migrations too. We’ll see how that works. Due to the weird constraints, though, we’ve got a fairly customized fixture-loading/-unloading regime going.
Why not reduce biweekly milestones to weekly?
Mostly because we want to reduce iteration workload variability, and we want to give the user community a chance to inspect a stable milestone application and get some feedback on changes before the milestone is gone too quickly.
By variability I mean that, given a single week for an iteration, it’s likely that someone will be gone for a day or two during that iteration, where over a couple of weeks people are liklely to be here for a good fraction of the iteration, moreso on average as the iteration count increases. We would like to be able to “theme” an iteration from time to time, and we’d like for developers to feel that they’ve been involved in every iteration—that they’ve not missed out on something important. Early, we’re still sharpening tools and learning a bit how we naturally fit together as a team, and how to use the framework and language to a high level of effectiveness. A longer milestone gives a sense that there will be some slack time during the milestone so it’s o.k. to order tasks, make some space, and stop to think about how things work, maybe to play a bit more with the tools and try things out. Experimenting with how one works with the team, how one can accomplish tasks, how one needs to order things to get them done by the milestone all seem to be advantageous for the developers now. We’re also feeling our way into how to estimate developer productivity and task size on the project, so we want to leave a little room for error early in the project as well. On the developer side we may well wish to tighten our milestones down the road.
On the user feedback side, one thing we wish to avoid is the all-too-common moving target syndrome: user pulls up the most recent version of the application and notices there is a problem with it (some bug, some misinterpreted feature/story, something that was ill-conceived, etc.), takes the time to put together succinct feedback, sends it in, gets a message back the next day from the development team saying, “Oh, yeah, we fixed that already.”—with one problem typically replaced the next day by a new problem in the application. We hope that our build and development process helps mitigate whack-a-mole bug hunting, but the perception in the user community that things move too fast to be able to give considered feedback is one that drives users away. We’re trying to fight that perception early by doing two things: (1) making nightly releases so that users can look at today’s version of the application, checking to see how things are evolving in near-real-time. We’re also making milestone releases and keeping them stable for the length of the milestone (two weeks here). Users can spend a while with the milestone system and give well-considered feedback. They can give fast feedback on the nightly system, and check themselves to see if a particular problem has already been fixed.
Some might ask, “well, why not make the milestones shorter but have the history of recent milestones available for users to peruse?” And the answer would be that, actually, that’s how we started out, and we discontinued the trend. First, we found that not only were users not really visiting the historical milestone apps, but that the presence of too many apps was a bit confusing to some. More importantly, we have to have a database running behind every milestone application (as well as the nightly). For a small application with no legacy data this tends to be a low burden—just write a script to populate new databases and run it with every release. We began our conversion process of our legacy data right behind the building of the new application. We have hundreds of thousands of staff & client demographics records alone, many with multiple phone numbers and addresses, plus all the stock data (zip code databases, e.g.)—and the data set will only get larger as we go forward —the client chart is next on the batting list and the client chart data is, um, large. Long story short—with users not digging back into the past that we can tell and data growing as we go forward, it seems wiser to us to save some resources and just keep the most recent milestone and nightly builds available. But, that motivates us to make the milestone builds last for long enough for the users to get a chance to look and play.
How do the clients requests come in to development? Are tickets raised by the client? Is the spec updated? Is the milestone data maintained along with the tickets? Are tickets claimed by devs or assigned? Are time estimates for tickets maintained and analysed?
As for the mechanics, we’re using Trac to manage milestones and tickets. Milestone data is kept along with tickets. We are not currently keeping time estimates for tickets, and we aren’t necessarily going to attempt to analyze time per ticket or task, though we may begin using an abstract “point”-type system for estimating. That remains to be seen. Currently we’re working from a backlog of gathered requirements on the core of the service, built up from experience with the past system, interviews with users in the field, and feedback through other channels (including the RT feedback system). We break the requirements into tickets that are as small as possible without them being laughable. We are currently mostly assigning tickets to developers in an attempt to minimize the tendency toward code ownership (though I think we’re not yet doing well in minimizing that tendency) and educating developers on the various skills they will definitely need through the project, such as writing models, views, controllers, unit tests, functional tests, invoking partials, debugging AJAX, etc. I would like to move over time to a model where developers are picking out tickets more on their own, and I’m watching to see how we might ease into that.
The organization has, prior to this project, had a fairly top-down and mandated structure, which we’ve had quite a bit of success loosening up, though there have been some growing pains. I don’t yet see a wall for us to hit going in this direction, but I’m trying not to change things faster than they appear to be changeable. We’ve gotten pervasive testing, continuous builds, more “agile” processes starting really from zero—but then again that may be the easiest way to start in some cases. We tend to introduce one new thing at a time (for instance we’ve really just started doing RDoc in thie most recent iteration) to keep the learning curve relatively shallow. We then expect the new techniques and processes that work to become part of normal development going forward. That seems to have worked out really well for us.
As for tickets, we have our trac system, which the development team uses. We also have an RT ticket tracking system that’s available for public use throughout the organization, and we’ve publicized it’s value and availability. We publish the completed actions list from trac without developers’ names with every milestone. What we’re shooting for is a no-holds-barred Trac environment where developers can do what they want and need to do to collaborate on the project, as well as a public feedback and ticketing system with progress feedback for the user community. We want to allow the individual developers to not feel “watched” by members of the user community who might be pushing for certain features, or who might want to insist that some developer isn’t working hard enough or fast enough on their pet features. We may relax things a bit down the road, but for now we’re being careful to insulate developers until we can establish a solid relationship with our (LARGE) user community.
That’s a round-about way of saying that we both manage tickets internally, and have users creating tickets. As users put tickets in RT we triage them and bring them into either Trac as real tickets, or into Subversion as part of the design information we use when working out our domain model. As we get further and further along, getting into highly specialized domain areas, we will have a much closer relationship between users and developers. For now, though, we’re getting the battleship up to travelling speed—getting good representatives of the user community, finding time in their schedules, etc.
Well, this has taken (literally) forever to write, so I’m going to finally publish this, whether or not it’s complete… I’ve got a mental backlog of about 5 short articles I want to hit—but I may be writing them from New York (a.k.a. The Holidays).
Posted in project | Tags CIA, process, project, rick, svn
Posted by rick
Tue, 29 Nov 2005 22:42:00 GMT
We’re under steam with development on the rewrite project, and are nearing our next milestone, “milestone05”, which is due on Thursday. (Now, you might think that this would be the 5th milestone, but in actuality it’s the 6th, since we had a “milestone02a” wedged unceremoniously between “milestone02” and “milestone03”. New team, new tools, new processes—sometimes you just have to adapt.)
Regardless, we’re on a 2 week (really twice a month) milestone pace, meaning that there’s a fairly tight cycle between “stable” releases. We schedule a batch of features for a milestone, divvy the tasks out, and then work through the features for the milestone. As with any development project, reality will step in. From time to time we split a feature into a piece we can manage in a milestone, and a problem that may be relegated to the next milestone (or, if we’re lucky, resolved in this milestone). By the target date we hit the milestone, launch a stable demo site, and then move on to the next milestone.
We’re running a continuous integration server for the project, with a mandate that noone should “break the build”. If you “break the build” you work hard to get it fixed ASAP. Build breakage is becoming less and less frequent—partly because developers are getting in the habit of doing small check-ins and running our test suite before committing. Also, our test suite is growing quickly more and more comprehensive, and our environments are stabilizing—what happens on the build server is likely to be what happens on a development system. If it breaks on the build server it probably would’ve broken on your machine had you run the tests.
Now, from time to time we’ll hit a situation where the build breaks but the tests run on a developer’s system—or vice versa: I run the tests on my machine and they work, I push a commit, the build server is happy, another developer gets the pull and is hosed. :-/
The oddball cases have almost always been due to some local changes not yet committed on a developer’s system, or some weirdness with moving around things in a local (subversion) checkout in manners not advised. Confusion about branches (which we use rarely anyway) has accounted for some headaches. These thing are more and more rare though as we all settle into a normal work pattern that uses our tool chain in efficient and normal ways.
We had one case where there was an actual problem in the framework which caused tests to fail on Windows systems against one database flavor (Oracle), but nowhere else. This happens to be (as we understand it) related to Windows botched libc time implementation—basically, if the folklore is right, Microsoft took an early BSD libc implementation, then neglected to patch it when the BSD folks did. C’est la vie. You can read more gory details if you’d like (fwiw, I think this commit actually will fix the problem once we get around to testing it again, even though the changelog doesn’t report the fix).
With all this automated testing it sort of seems unnecessary to break things into bi-monthly milestones—I mean, after all, the application works now, and it will work (with a few minor incidents that we try to minimize) after every commit. Why not just have a live system that users can look at, poke at, give feedback on, etc.? As Dave Astels noted in an email recently, Rails really gives the sort of tight zero-turnaround feedback loop that we could conceivably have daily milestones.
Well, in a sense we almost have that—we have a nightly build that gets refreshed around midnight every night. This includes a fresh pull of our converted data (or really whatever the high water mark is on our conversion project that night), a fresh svn update, a dump of all old session data, and a restart of our lighttpd server. On any given day you can look at the nightly application and know that you’re no more than 24 hours off the current build (actually it’s closer to “no more than 8 hours” since nobody is really working on the system outside normal business hours). Users can hit the nightly site and see what the (working) application looks like today. —And, if you’re a developer, you can pull the tree any time, run “script/server” and use the application right this second.
However, we still stick to a milestone plan for a few reasons (at least that I can think of off the top of my head):
- It makes it easier to plan, estimate, and negotiate with users on when certain features can or might land in the system.
- A milestone gives us a stable point to look at, even if nightlies get a bit flaky or unstable.
- A milestone target lets us group related features together for deployment as a group.
- A somewhat stable target lets users identify bugs, or comment about feature implementations (etc.) without the target moving from under them. It’s frustrating to spend time thinking about one’s opinion of an application only for it to change by the time one gets a chance to tell someone. The nightlies will show progress, but the milestones give us something to talk about.
There are others—dinner forces them out of my head at the moment.
That said, let me close with a current “rake stats” snapshot of where we’re at. I’ll try to post these from time to time so that readers can get a low-granularity sense of what’s going on behind the scenes.
+----------------------+-------+-------+---------+---------+-----+-------+
| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers | 317 | 157 | 0 | 14 | 0 | 9 |
| Controllers | 884 | 632 | 8 | 60 | 7 | 8 |
| APIs | 0 | 0 | 0 | 0 | 0 | 0 |
| Components | 0 | 0 | 0 | 0 | 0 | 0 |
| Functional tests | 1470 | 1057 | 24 | 102 | 4 | 8 |
| Models | 1261 | 668 | 25 | 54 | 2 | 10 |
| Unit tests | 2413 | 1823 | 17 | 209 | 12 | 6 |
| Libraries | 545 | 255 | 4 | 25 | 6 | 8 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total | 6890 | 4592 | 78 | 464 | 5 | 7 |
+----------------------+-------+-------+---------+---------+-----+-------+
Code LOC: 1712 Test LOC: 2880 Code to Test Ratio: 1:1.7
update:
I forgot to include a screenshot from our current nightly build! Here’s a shot of the (AJAXified) in-place address editor for a staff member (me). Our model for people and organizations closely mirrors Martin Fowler’s Party and Accountability patterns from his Analysis Patterns text (worth the money at just about any price).
Here’s a shot (hopefully, we’ll all laugh at this one day). Yes, I know there’s not much there to see, but there’s a lot under the hood, and still not a lot of code. We’re happy with where we are so far. Enjoy.
Tags milestone, rick, stats
Posted by rick
Sun, 20 Nov 2005 17:10:00 GMT
This site is now running on lighttpd & fcgi, fronted by Apache running mod_proxy. I had been running a number of sites on this server using simple Apache/FCGI, but I’ve found stability with that combination to be far from ideal. The Apache FCGI linkage seems fairly fragile. Sometimes the Rails controller doesn’t get a chance to fire properly, resulting in HTTP 500 errors; sometimes an FCGI process gets seemingly disconnected and goes into a tailspin, sucking CPU like crazy; and overall Apache/FastCGI really isn’t (“fast”, that is).
Since we’re using Apache 1.3.33 on this FreeBSD server, however, I can’t (without digging around for a patch I’ve yet to actually find, and then risking the rebuild of Apache) have Apache pass the hostname properly back to lighttpd (this is an Apache2 feature). So I’m running a separate lighttpd intance for each Rails site (there are 5 on this server), each on a different port. Less than ideal, but it seems to be working, and fast.
Our CenterNet milestone sites and nightly build sites are using a similar configuration—a subdomain per site. But there we’re fronting with Apache2, and hence only need 1 lighttpd process for the whole enchilada.
If anyone knows how to easily work around this Apache1 + multiple lighttpd on different ports setup issue I’d be pleased to hear it for my personal sites.
Posted in this site | Tags apache, fcgi, lighttpd, rick
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
