Radiator is a system for syndicating and displaying continuous integration server job statuses. It currently can act as a front-end to Jenkins
- View settings are associated with a IP address; no user table maintenance required.
- Each source is a discrete Jenkins view, so existing Jenkins view configurations can be leveraged.
- Multiple sources can be aggregated onto a single radiator display.
- Views can be filtered to only display selected job statuses.
Radiator is generally being developed using TDD. Since Sinatra has no real test support (other than Rack::Test), that can be a challenge. But challenges help us grow, and growth is good. Radiator's tests use Test::Unit, rather than a fancier test framework like rspec. I'm sure there are a lot of advantages to using rspec. I'm also sure that most of the people using rspec have never (or only rarely) encountered situations where rspec is better than Test::Unit. But ultimately, I used Test::Unit because I knew it, and I decided not to add "learn a new test framework" to my requirements for Radiator.
- Radiator uses HAML. You either love or hate HAML. I love it. I also like Python, the little I've been able to use it.
- Radiator uses SASS. You don't get a choice here. SCSS is far superior to CSS. Drink the kool-aid. It's good for you.
- Radiator uses Compass. I chose Compass for two reasons: I'm comfortable with Blueprint, and I didn't want to have to write my own toolchain for compiling SCSS into CSS.
- Radiator uses -prefix-free. You really need this. It means you don't have to put a bunch of browser-specific directives in your CSS3 files. Seriously. It's great.
- Parts of Radiator's look-and-feel were prototyped using dabblet. Dabblet is great. Really great.
- Radiator uses jquery and jquery-ui
- Radiator uses FakeWeb and flexmock for testing.
-
implement config
-
implement switch
-
need a more complementary jquery-ui theme