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

The Trello Tech Stack

blog.fogcreek.com

Post reply on HN
Print view View original

71–80 of 96 posts

Re: The Trello Tech Stack

#71

Post by trotsky »

JoachimSchipper wrote: post #63
trotsky wrote: post #48

How vulnerable are all javascript approaches in terms of injection type attacks? Do apps like node and mongo effectively prevent them, or is it still possible to shoot yourself in the foot? I've read some off hand comments along the lines of "as long as you're not a total moron you have nothing to worry about", but that sounds a lot like what was said about sql injections and xss before exploiting them went mainstrea…

See http://news.ycombinator.com/item?id=3369876 . Summary: people seem to be ignoring security. Also note stuff like https://news.ycombinator.com/item?id=3419693 : node.js is not free of issues itself. (To be fair, lots of people got that wrong and it was patched quickly.)

Thanks very much!

Re: The Trello Tech Stack

#73

Post by robocat »

jeswin wrote: post #37
apg wrote: post #8

This post raises a few questions for me... and perhaps some one more versed in these stacks can provide answers. - Does the use of CoffeeScript alleviate the MC Escher-esque quality of callbacks within closures involved in working with Javascript on both the server and client (and the data store)? I can totally see the appeal of CoffeeScript's syntax. Giving the programmers something different to look (and learn) at…

1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec... I am writing a sizable Node app myself. In the end, you just get used to the callback style.

I think the following links are relevant for those of us that know much less than you:

I liked this article that discusses three different solutions to callbacks with different compromises: http://blog.willconant.com/post/7523275566/continuations-in-...

Jeremy discusses #350 and tamejs here: http://news.ycombinator.com/item?id=2777196

Tamejs have a great writeup about the callback spaghetti problem here: http://tamejs.org/

Re: The Trello Tech Stack

#74

Post by shasta »

edw519 wrote: post #32

Use things that are going to work great in two years. This is one of those remarks that is obvious to someone who knows what it means but mysterious to someone who doesn't. So what does it really mean? - Don't use a technology that, no matter how good, is just too niche for widespread adoption? - Don't use a technology that we'll have trouble finding programmers to support? - Look for stuff that will take better adva…

"Use software that will work great in two years" is the reason we're looking at using Trello.

Re: The Trello Tech Stack

#75

Post by robocat »

dodger wrote: post #57
jashkenas wrote: post #52

Earlier quoted context omitted.

dodger: I'd be curious to know where y'all bled over CoffeeScript or Backbone, if you don't mind sharing.

Actually, those have been great (and thank you for making them)! We had an outage during beta because somebody forgot to wrap an array comprehension assignment (CoffeeScript) and we didn't test right. Backbone has been really good, and while we had some complaints, I think many have been resolved in more recent versions - we're on something ancient.

> "we're on something ancient"

Isn't that one of the major drawbacks of using a bleeding edge Tech Stack? Albeit mitigated by choosing to use code that is easy to comprehend/maintain (like backbone!)

What do you think you will do? E.g. With backbone: Merge up, status quo -- maintain your branch, change libraries, or something else?

Re: The Trello Tech Stack

#76

Post by dodger »

robocat wrote: post #75
dodger wrote: post #57

Earlier quoted context omitted.

Actually, those have been great (and thank you for making them)! We had an outage during beta because somebody forgot to wrap an array comprehension assignment (CoffeeScript) and we didn't test right. Backbone has been really good, and while we had some complaints, I think many have been resolved in more recent versions - we're on something ancient.

> "we're on something ancient" Isn't that one of the major drawbacks of using a bleeding edge Tech Stack? Albeit mitigated by choosing to use code that is easy to comprehend/maintain (like backbone!) What do you think you will do? E.g. With backbone: Merge up, status quo -- maintain your branch, change libraries, or something else?

Agreed, it made some necessary, non-backward-compatible changes as a result of being such a young project. I think it is likely that we will upgrade to a newer version soon.

Re: The Trello Tech Stack

#77

Post by dodger »

Rauchg wrote: post #31
dodger wrote: post #28

Earlier quoted context omitted.

Today I'd consider going with a service, but first I'd see how https://github.com/LearnBoost/websocket.io looks. Most of our problems have been with abstractions in the socket.io client and scaling issues with server process chatter. The chatter shouldn't be necessary with websockets-only.

With https://github.com/LearnBoost/engine.io the abstractions are greatly simplified, which is what I'm announcing today. The socket.io codebase has been shrunk dramatically, and it's as a result easier to scale/maintain.

That's great!

Re: The Trello Tech Stack

#78

Post by ufo »

apg wrote: post #43
jeswin wrote: post #37

Earlier quoted context omitted.

1. CoffeeScript doesn't alleviate this yet. I doubt will be much progress on this until we find a good way to implement defer/async. https://github.com/jashkenas/coffee-script/issues/350#issuec... I am writing a sizable Node app myself. In the end, you just get used to the callback style.

I am assuming that CoffeeScript should be able to add new syntax where the need arises, as the number of CoffeeScript users is probably still pretty low and able to adapt to change. From what I can tell, CoffeeScript - and the Javascript/Node world - would really benefit from something like F#'s workflow/computation-expression syntax, which will take a fairly straight-forward readable statement and behind the scenes…

Where is the love for [Deferreds?](http://www.sitepen.com/blog/2010/05/03/robust-promises-with-...)?

Deferreds are * Mostly monadic (creating a deferred is "return", the "then" method is "fmap" and "bind"). * Can be implemented as a library, without a separate compilation step or having to patch the runtime. * Avoids most of the CPS inversion of control madness. You can return and store promises and you can also add callbacks after the fact so code is much more flwxible. (writing sequential async loops is still annoying though)

Re: The Trello Tech Stack

#79

Post by wavetossed »

mnutt wrote: post #41
frabcus wrote: post #36

Earlier quoted context omitted.

My (minimal) criteria is it has to be packaged in Debian. A couple years ago I considered both MongoDB and CouchDB immature for that reason. The recent confusion of CouchDB/Couchbase etc. shows that was a reasonable view.

I'm not sure when they started, but 10gen now packages and distributes their own MongoDB Debian and Redhat packages. It seems like the right move, so that they're not beholden to the update schedule of the distros.

Yes!!! The development cycle of software like MongoDB, RabbitMQ and so on, is much faster than that of Debian or any other Linux distro. The Debian package is fine for dabbling or low volume use, but for any serious app, you MUST go direct to the developers and use their latest stable release. That is what they support best on their mailing lists, and that is where most bugs are already fixed.

A lot of software development teams are releasing their own RPM and .DEB Linux binary packages for just that reason, to encourage people to use up to date packages instead of the stale OS distro packages.

In a way, it's rather like security updates. Who would refuse to install security updates because it's not part of the Ubuntu 10.4 LTS release? Almost nobody even thinks of doing that. So why would you use old obsolete releases of mission critical software?

Re: The Trello Tech Stack

#80

Post by meatmanek »

wavetossed wrote: post #79
mnutt wrote: post #41

Earlier quoted context omitted.

I'm not sure when they started, but 10gen now packages and distributes their own MongoDB Debian and Redhat packages. It seems like the right move, so that they're not beholden to the update schedule of the distros.

Yes!!! The development cycle of software like MongoDB, RabbitMQ and so on, is much faster than that of Debian or any other Linux distro. The Debian package is fine for dabbling or low volume use, but for any serious app, you MUST go direct to the developers and use their latest stable release. That is what they support best on their mailing lists, and that is where most bugs are already fixed. A lot of software devel…

> why would you use old obsolete releases of mission critical software?

"If it ain't broke, don't fix it"

Because it's mission critical, and you can't afford for it to break. Once you hit a certain complexity, upgrades almost always break something:

APIs change. Undefined behavior changes. New bugs are introduced. A feature critical to your app starts performing worse. The above changes break something else you depend on (libraries, proxies, etc.)

Upgrading to a significantly changed version of a mission-critical app/library/language is a lot of work, and is sometimes impossible: many projects couldn't be reasonably ported to Python 3 if they wanted to; a lot of important libraries don't work on Python 3.

This is exactly why bug and security fixes are often backported into old versions. Python 2.5 is still receiving security patches. Apache 1.3 was maintained for years after 2.0 was considered stable.

Post reply on HN