Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Make Trello

blog.fogcreek.com

Post reply on HN
Print view View original

91–100 of 120 posts

Re: How We Make Trello

#91

Post by basicallydan »

thedufer wrote: post #62
copergi wrote: post #58

Earlier quoted context omitted.

>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever Those are two orthogonal things. All my sites have a complete separation of presentation from code and access a nice API to get data. Including the ones that are purely HTML and have no javascript at all. Single page apps are good for things that are…

Not completely orthogonal. The way Trello is set up, client and server releases are completely unrelated and don't have to know about each other. The web app is almost as separate from the server as the iOS/Android apps, which isn't really possible if you're rendering html in the server. That said, I agree that making something into a single page app just to get this separation isn't going to be useful.

> That said, I agree that making something into a single page app just to get this separation isn't going to be useful.

I agree, but there are other benefits too :)

Re: How We Make Trello

#92

Post by bib971 »

bobbygrace wrote: post #20
edwinnathaniel wrote: post #11

I'm more interested to know the actual technical details of the build and testing process than the "Task-List" software development based approach because that can be done by any software project management tools (even JIRA). What's missing in this article is the whole Continuous Delivery technical aspect of it. What do you guys use to build the NodeJS app? What do you guys use to test the NodeJS app? What do you guy…

I hope Doug writes a more technical post about the multi-client build/release process. We have unit tests for the whole API and very few automated tests for the front-end. Client builds are stored in S3. We use mongoDB and will do backfills if necessary (pretty rare). Rolling back the client is just pointing the stable branch to another build.

Bobby, you said every app is a client of the API. I notice Trello.com consumes API from https://trello.com/1/xx while an OAuth client (from one of your Jsfiddle examples) consumes from https://api.trello.com/1/xx?key=xx&token=xx. I suppose the former just passes through to the later? If so, does the former needs to pass over the key and token (I suppose you can generate on the fly based on auth cookie)? I'm trying to get my head around the fact that your app provides OAuth for other clients and at the same time (from what you're saying) your app is also one of such clients. Not sure how it really works.

Re: How We Make Trello

#93

Post by hibbelig »

sidcool wrote: post #14

So they create a new branch for each fix? And all developers are supposed to merge in their branch every few hours or so? Isn't it a bit of a drag?

With Subversion, you have a working copy with changes and then you do "svn update", and Subversion merges the upstream changes into your working copy. (But you don't normally call this merge.)

With Git, you have a working _repository_ with changes and then you do "git pull", and Git merges the upstream changes into your repository.

From the user's perspective, it looks about the same. But the Git merges are safer than the Subversion updates, because if the Subversion update messes up your working copy, you're stuck. But with Git, you always have (1) the commits you made locally, (2) the commits you just pulled from upstream, (3) the merge that was done by "git pull". And (1) and (2) can't get messed up, only (3) can get messed up. But you still have both your version (1) and their version (2) to go back to, so you have lots of chances to fix it.

Think of Git branches and the corresponding merges to be like Subversion updates with backups of the previous local working copy.

Re: How We Make Trello

#94

Post by kibibu »

hibbelig wrote: post #93
sidcool wrote: post #14

So they create a new branch for each fix? And all developers are supposed to merge in their branch every few hours or so? Isn't it a bit of a drag?

With Subversion, you have a working copy with changes and then you do "svn update", and Subversion merges the upstream changes into your working copy. (But you don't normally call this merge.) With Git, you have a working _repository_ with changes and then you do "git pull", and Git merges the upstream changes into your repository. From the user's perspective, it looks about the same. But the Git merges are safer tha…

> Subversion updates with backups of the previous local working copy.

Which is a practice I got into the habit of doing manually when I used to work with Subversion.

Re: How We Make Trello

#95

Post by exceptione »

mbesto wrote: post #13
smacktoward wrote: post #12

Earlier quoted context omitted.

Everything I've ever heard about Fog Creek indicates that they take their people seriously. Which probably makes them more likely to take their work at Fog Creek seriously. Funny how that works, huh? A lesson many, many other companies could profit from.

I agree with your point, but it requires that you hire correct right from the beginning. Spolsky (like pg, Atwood, Fried/DHH , etc.) has his pick of the litter because of well thought out essays and large base of followers. You can't simply take this attitude without having a large pipeline of people who (1) agree with you and (2) who are good. Lesson learned - creating a community or following of people (i.e. talent…

Well if you read what Joel says about working conditions and look at the office pics where you can see that in practice it just makes sense that fogcreek can attract the best people. Look how everybody has is own office.

I still dont get it why people keep thinking that to cram puzzlers on a noisy heap with all possible (social, visual, audio) distractions saves money in the end. If Joel can offer programmers sane working conditions in NY, so can every office around the world.

Re: How We Make Trello

#96

Post by exceptione »

jordo37 wrote: post #84
mbesto wrote: post #13

Earlier quoted context omitted.

I agree with your point, but it requires that you hire correct right from the beginning. Spolsky (like pg, Atwood, Fried/DHH , etc.) has his pick of the litter because of well thought out essays and large base of followers. You can't simply take this attitude without having a large pipeline of people who (1) agree with you and (2) who are good. Lesson learned - creating a community or following of people (i.e. talent…

Having essays is not the only way to do it. The other way is to just be willing to wait for the right hire. At my company, we have a small engineering team so far, but we have taken a long time for each hire with the basic idea that they need to fit some key characteristics of our team. At the beginning this was actually harder to identify what was important, but now that we have a larger team there is more diversity…

I am curious about what characteristics you have uncovered. And do you think they are accidental?

Re: How We Make Trello

#97

Post by noblethrasher »

thedufer wrote: post #62
copergi wrote: post #58

Earlier quoted context omitted.

>In my opinion if there's one thing a reader should take away from this it should be that Single Page Apps and separation of server and client are The. Best. Thing. Ever Those are two orthogonal things. All my sites have a complete separation of presentation from code and access a nice API to get data. Including the ones that are purely HTML and have no javascript at all. Single page apps are good for things that are…

Not completely orthogonal. The way Trello is set up, client and server releases are completely unrelated and don't have to know about each other. The web app is almost as separate from the server as the iOS/Android apps, which isn't really possible if you're rendering html in the server. That said, I agree that making something into a single page app just to get this separation isn't going to be useful.

>which isn't really possible if you're rendering html in the server.

It's not only possible, it's pretty trivial in most cases. Just endow each user facing object with a .ToHTML() and .ToJSON().

This is actually one of the core benefits of REST, you send me a request for a resource along with some desired media type(s), and I send you back a representation in the media type of your choice (or as close as possible).

Re: How We Make Trello

#98

Post by trustfundbaby »

What I'm interested in is the mechanics behind how they know were to send a user based on their channel (beta/stable/alpha). We wanted to do something like this, but we couldn't figure out how to route users to the right app server either using AWS ELBs or nginx proxying ... admittedly we didn't really spend a lot of time thinking about it though.

Re: How We Make Trello

#100

Post by jw2013 »

These tech intros are pretty cool, yet can I ask how does the team acquire users? That seems to be harder than the tech challenges for Trello IMHO.
Post reply on HN