dhh

11 ms·

61.
by dhh 15y ago
If you use something like jbuilder to build your JSON, then this exact same technique will work just as well.
62.
by dhh 15y ago
You hit the DB for the top-level. So in step 6, we'll always hit the db for the latest project, but we will not hit the db for the todolists or the todos of those todolists if the project cache is fresh. So you save the render plus any db c
63.
by dhh 15y ago
See step 6. The view is pulling the cache key straight from the domain model. It relies on being the informed as well about changes in its children to do that, which is what the setup in step 5 is about.
64.
by dhh 15y ago
Because neither of those elements have any bearing on maintainability beyond what is customary for a Rails application. The wonders of pjax is that it doesn't require you to change your application style and structure at all, so it has zero
65.
by dhh 15y ago
On 50/50, yes, we write lots of JavaScript for Ajax. We've done that since 2005 with Tada list. The debate here is over whether going client-side MVC for everything is a pleasant experience. I contend that it is not. The maintainability sto
66.
by dhh 15y ago
Matt, I don't think there's all that much difference in money spent (you still need to buy servers either way and you still need to cache even if you return JSON). We crank out functionality faster when it can be done server-side because th
67.
by dhh 15y ago
In terms of client-side MVC vs server-side renderings, the ration is more like 90/10 or 95/5. We have one major section that's all client-side MVC, which is our calendar. We have one tiny section as well, which is a little invite widget. Ev
68.
by dhh 15y ago
Is that supposed to be a slam? I've been working on "custom" platforms for the better part of a decade.
69.
by dhh 15y ago
I'm not sure what qualifies as sustainable or not in your book. We've achieved our speed goals (sub 100ms pages for the most part), our development goals (Ruby, Rails, server side pleasure), and our UI goals (app that feels like a web page,
70.
by dhh 15y ago
I'm not sure I understand the pain point you're describing. What's "styled HTML"? We're sending HTML across the wire that looks exactly like the HTML we used to render the initial page. It has classes, ids, and custom data descriptors. We h
71.
by dhh 15y ago
50-100ms is the time it takes to generate the response on the server. On top of that you have to add the ping time between you and server and whatever other network overhead there is. That's why it's great to be closer to 50ms so you'll sta
72.
by dhh 15y ago
We've found that the additional overhead of sending HTML vs JSON is negligible in most cases. The additional speed gained by just sending JSON across is not worth the programming enjoyment hit of doing everything client-side. When you get b
73.
by dhh 15y ago
Not for the time being. Stacker is specifically developed for this unique UI style that we're using for Next. We don't open source our UI elements.
74.
by dhh 15y ago
We don't do that. We only discriminate against browsers we know will have problems. Like IE6-8. So what we're running is actually a blacklist. If you show up with a browser that's not one of the big four, we're just letting you in on your o
75.
by dhh 15y ago
We certainly have! I would be embarrassed if we hadn't. Also, that's why we're comparing uptime against big, established web applications. I would not hold these standards up to a 1 year-old, newly started business. You have far more import
76.
by dhh 15y ago
Sounds good! Remember to setup transaction tracking, though. Just doing pings or http get and expecting 200 OK on a page is not enough for this to be interesting. For Basecamp, we login, go to a project, and post a message, or something lik
77.
by dhh 15y ago
We do more than just login to the apps. We login and go to an expected spot. So it catches all of that. This includes total downtime yes.
78.
by dhh 15y ago
We configured all the benchmark apps to expect a response. So on Github we go and checkout a repo. On Freshbooks a known invoice. On Assistly the agents index. Etc. This is "the app is functional" checking. Not just 200 OK.
79.
by 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+.
80.
by 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 rut
81.
by 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.
82.
by 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.
83.
by 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.
84.
by dhh 15y ago
Key-dependency is achieved using touch-parent-on-update.
85.
by dhh 15y ago
This is all for HTML fragment caching using key-based expiration. I'll write up all the details soon.
86.
by dhh 15y ago
I'll give away that secret right now: Key-based expiration.
87.
by dhh 15y ago
Last I checked, I believe something like 20% of our customers were from the tech/startup scene. The vast majority of our customers are regular businesses. But yes, we're still tiny compared to behemoths like Sharepoint. All the more reason
88.
by dhh 15y ago
I thought of this after we hired @qrush. He instantly started arguing with everyone about everything from technology choices to feature selection and I thought to myself, "that's so awesome". And then I thought that we've had a long history
89.
by dhh 15y ago
All expenses are indeed tracked by virtue of using a credit card. Electronic receipts are forwarded to a shared email address. For everything else, we're willing to run the risk of an audit that might argue over the purpose of a lunch to sa
90.
by dhh 15y ago
Can you ask? I'm curious to learn what these background checks entail. Also, if they actually do prevent bad apple's from joining, why not do them to programmers as well (given that they have the power to program backdoors etc into systems)

More ›