4 ms·

Code statistics for Basecamp Next

55 points by andycroll 15y ago

andycroll 15y ago
I still find myself worrying about the 'app-ness' of lots of JS in a web application. Think it's derived from my web standards background. Twitter is my least favorite site in this respect. No idea what this means for of Basecamp Next, as there's no actual code yet, but in my own work I like to make sure that no-JS doesn't necessarily mean no-functionality.
- dhh 15y ago
  Andy, Basecamp Next does not have a one-screen app feel at all. We're still all about separate pages. But we do rely heavily on JS for functionality, so it won't work without it.
  - andycroll 15y ago
    In an ideal world I'd like non-JS fallbacks but I'm torn as to whether I'm being too 'old school' or stuck in a 'progressive enhancement' approach more suited to a web site rather than a web app. I suspect it comes down to the project and the trade offs therein. I'm no code zealot. I'm presuming you're serving just desktop interface to start as well? No responsive or mobile at launch?
    - dhh 15y ago
      The UI has been designed to work great on tablets and it also works pretty well on a phone (albeit a tad crammed). We'll probably do something more dedicated for mobile after launch.
    - alexhaefner 15y ago
      I'm building an app in a very similar manner to what I've read about Basecamp Next. When you move to the new model with a payload of code, and then json reqests from there, it's blazingly fast, and so much more gratifying to zoom around the site as no full page re-renders have to happen. You wouldn't like native apps refreshing on ever transition of state.
wtn 15y ago
Still awaiting the release of Cinco…
- dhh 15y ago
  Don't hold your breath. We haven't revisited the mobile version of Basecamp since we released it and haven't started any other new projects based on Cinco. I'm not sure when/if we'll have a chance to get back to it.
  - jashkenas 15y ago
    I think I may have asked this before, but would you mind describing a bit about how you foresaw Cinco coming together? What would it have provided on top of Backbone.js + Stitch/Sprockets?
  - jkahn 15y ago
    Surprising. Mobile Basecamp became a lot faster a few months ago. I thought that it was because of code improvements, now I'm guessing it is due to iOS 5.
DavidChouinard 15y ago
The most interesting tidbit is this: Code to Test Ratio: 1:0.8 That seems like an awful lot, no?
- rmah 15y ago
  No. I've worked on projects where our tests outweighed our "code" by 2x or more.
- travisjeffery 15y ago
  No, not at all; especially not for enterprise applications. The current project I work on has 292908 LOC, and Code to Test Ratio: 1:1.1.
  - hopeless 15y ago
    On the other hand, I work on enterprise apps with 200-500k LOC and maybe 1-2K LOC for test. So "Enterprise" probably isn't a good indicator on test ratios.
- jonknee 15y ago
  If you think that's a lot, check out SQLite's ratio: http://www.sqlite.org/testing.html http://www.sqlite.org/testing.html
csallen 15y ago
Wow, only 6334 lines of code? I find that to be shockingly small. It's less than projects I've worked on by myself for 4 or 5 months, which is nuts considering they've (presumably) had 5+ engineers working on Next for a year now.
- dhh 15y ago
  I worked pretty much alone on the code base for the first three months. Then we were two people for another three-ish months. Then the last four months or so we've ramped up the team to have 4-6 programmers on, depending. But we're also ruthless about keeping the code base small. In the beginning I would go through the entire code base every week and prune it. I still read through the entire thing every now and then and make sure there's no excess fat.
  - csallen 15y ago
    Ah, makes sense. I didn't realize you guys keep things so small. Is Next going to have an API when it launches? And if so, do the stats posted include lines of API-related code? EDIT: And since I'm already asking so many questions, how do you guys feel about supporting older versions of IE?
    - dhh 15y ago
      Yes, we're launching with an API. The code stats include those for the API. We will not support old versions of IE. We support IE9+.
      - csallen 15y ago
        Cool. It's pretty impressive to fit an API in there, too. Do you guys subscribe to the method of building your app on top of your own API? Or do you place more of a priority on speed?
        jkahn 15y ago
        It's Rails, so presumably the API will be one with the (regular) code for the most part.
DanielRibeiro 15y ago
DHH's take[1]: we have almost as much CoffeeScript as Ruby code! [1] https://twitter.com/#!/dhh/status/164038209267974145 https://twitter.com/#!/dhh/status/164038209267974145
mhartl 15y ago
It's interesting to see how few integration tests there are in Basecamp Next. I used to use functional (controller) tests heavily, but in the last year I've switched over to integration tests (plus Capybara) for controllers and views. (I still use unit tests for models.) I really like their power and flexibility, and I've found it convenient and intuitive to test, e.g., a web form by visiting the page and (virtually) clicking "Submit". These are the stats for the current Rails Tutorial sample application (taken from the in-progress book at http://railstutorial.org/book?version=3.2 http://railstutorial.org/book?version=3.2): $ rake stats +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 164 | 139 | 6 | 23 | 3 | 4 | | Helpers | 81 | 62 | 0 | 13 | 0 | 2 | | Models | 102 | 58 | 3 | 6 | 2 | 7 | | Libraries | 0 | 0 | 0 | 0 | 0 | 0 | | Model specs | 256 | 198 | 0 | 0 | 0 | 0 | | Controller specs | 29 | 22 | 0 | 0 | 0 | 0 | | Request specs | 555 | 424 | 0 | 3 | 0 | 139 | | Cucumber features | 87 | 34 | 0 | 0 | 0 | 0 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 1274 | 937 | 9 | 45 | 5 | 18 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 259 Test LOC: 678 Code to Test Ratio: 1:2.6 (Note that "Request specs" is RSpec-speak for "Integration tests".) This is probably a little heavier on the test code side than I would have in an app designed for production rather than pedagogy, but it gives you the basic idea. Even though there's some minor controversy about testing frameworks in the Ruby community (you can see that I use—gasp!—RSpec), I think it's great that the only way to cause major testing controversy is not to do it. P.S. I have some reservations about Cucumber, and the Cucumber features are there mainly for Rails Tutorial readers who want a quick introduction to the subject. I don't use Cucumber much myself, although I do have a better appreciation of its virtues than I used to.

55 points by andycroll 15y ago

I still find myself worrying about the 'app-ness' of lots of JS in a web application. Think it's derived from my web standards background. Twitter is my least favorite site in this respect. No idea what this means for of Basecamp Next, as there's no actual code yet, but in my own work I like to make sure that no-JS doesn't necessarily mean no-functionality.

dhh 15y ago
Andy, Basecamp Next does not have a one-screen app feel at all. We're still all about separate pages. But we do rely heavily on JS for functionality, so it won't work without it.
- andycroll 15y ago
  In an ideal world I'd like non-JS fallbacks but I'm torn as to whether I'm being too 'old school' or stuck in a 'progressive enhancement' approach more suited to a web site rather than a web app. I suspect it comes down to the project and the trade offs therein. I'm no code zealot. I'm presuming you're serving just desktop interface to start as well? No responsive or mobile at launch?
  - dhh 15y ago
    The UI has been designed to work great on tablets and it also works pretty well on a phone (albeit a tad crammed). We'll probably do something more dedicated for mobile after launch.
  - alexhaefner 15y ago
    I'm building an app in a very similar manner to what I've read about Basecamp Next. When you move to the new model with a payload of code, and then json reqests from there, it's blazingly fast, and so much more gratifying to zoom around the site as no full page re-renders have to happen. You wouldn't like native apps refreshing on ever transition of state.

wtn 15y ago

Still awaiting the release of Cinco…

dhh 15y ago
Don't hold your breath. We haven't revisited the mobile version of Basecamp since we released it and haven't started any other new projects based on Cinco. I'm not sure when/if we'll have a chance to get back to it.
- jashkenas 15y ago
  I think I may have asked this before, but would you mind describing a bit about how you foresaw Cinco coming together? What would it have provided on top of Backbone.js + Stitch/Sprockets?
- jkahn 15y ago
  Surprising. Mobile Basecamp became a lot faster a few months ago. I thought that it was because of code improvements, now I'm guessing it is due to iOS 5.

DavidChouinard 15y ago

The most interesting tidbit is this: Code to Test Ratio: 1:0.8 That seems like an awful lot, no?

rmah 15y ago
No. I've worked on projects where our tests outweighed our "code" by 2x or more.
travisjeffery 15y ago
No, not at all; especially not for enterprise applications. The current project I work on has 292908 LOC, and Code to Test Ratio: 1:1.1.
- hopeless 15y ago
  On the other hand, I work on enterprise apps with 200-500k LOC and maybe 1-2K LOC for test. So "Enterprise" probably isn't a good indicator on test ratios.
jonknee 15y ago
If you think that's a lot, check out SQLite's ratio: http://www.sqlite.org/testing.html http://www.sqlite.org/testing.html

csallen 15y ago

Wow, only 6334 lines of code? I find that to be shockingly small. It's less than projects I've worked on by myself for 4 or 5 months, which is nuts considering they've (presumably) had 5+ engineers working on Next for a year now.

dhh 15y ago
I worked pretty much alone on the code base for the first three months. Then we were two people for another three-ish months. Then the last four months or so we've ramped up the team to have 4-6 programmers on, depending. But we're also ruthless about keeping the code base small. In the beginning I would go through the entire code base every week and prune it. I still read through the entire thing every now and then and make sure there's no excess fat.
- csallen 15y ago
  Ah, makes sense. I didn't realize you guys keep things so small. Is Next going to have an API when it launches? And if so, do the stats posted include lines of API-related code? EDIT: And since I'm already asking so many questions, how do you guys feel about supporting older versions of IE?
  - dhh 15y ago
    Yes, we're launching with an API. The code stats include those for the API. We will not support old versions of IE. We support IE9+.
    - csallen 15y ago
      Cool. It's pretty impressive to fit an API in there, too. Do you guys subscribe to the method of building your app on top of your own API? Or do you place more of a priority on speed?
      - jkahn 15y ago
        It's Rails, so presumably the API will be one with the (regular) code for the most part.

DanielRibeiro 15y ago

DHH's take[1]: we have almost as much CoffeeScript as Ruby code! [1] https://twitter.com/#!/dhh/status/164038209267974145 https://twitter.com/#!/dhh/status/164038209267974145

mhartl 15y ago

It's interesting to see how few integration tests there are in Basecamp Next. I used to use functional (controller) tests heavily, but in the last year I've switched over to integration tests (plus Capybara) for controllers and views. (I still use unit tests for models.) I really like their power and flexibility, and I've found it convenient and intuitive to test, e.g., a web form by visiting the page and (virtually) clicking "Submit". These are the stats for the current Rails Tutorial sample application (taken from the in-progress book at http://railstutorial.org/book?version=3.2 http://railstutorial.org/book?version=3.2): $ rake stats +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 164 | 139 | 6 | 23 | 3 | 4 | | Helpers | 81 | 62 | 0 | 13 | 0 | 2 | | Models | 102 | 58 | 3 | 6 | 2 | 7 | | Libraries | 0 | 0 | 0 | 0 | 0 | 0 | | Model specs | 256 | 198 | 0 | 0 | 0 | 0 | | Controller specs | 29 | 22 | 0 | 0 | 0 | 0 | | Request specs | 555 | 424 | 0 | 3 | 0 | 139 | | Cucumber features | 87 | 34 | 0 | 0 | 0 | 0 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 1274 | 937 | 9 | 45 | 5 | 18 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 259 Test LOC: 678 Code to Test Ratio: 1:2.6 (Note that "Request specs" is RSpec-speak for "Integration tests".) This is probably a little heavier on the test code side than I would have in an app designed for production rather than pedagogy, but it gives you the basic idea. Even though there's some minor controversy about testing frameworks in the Ruby community (you can see that I use—gasp!—RSpec), I think it's great that the only way to cause major testing controversy is not to do it. P.S. I have some reservations about Cucumber, and the Cucumber features are there mainly for Rails Tutorial readers who want a quick introduction to the subject. I don't use Cucumber much myself, although I do have a better appreciation of its virtues than I used to.