21–30 of 32 posts
I'm confused, what does this post have to do with Ruby, other than a brief mention about how Ruby's syntax is different from other languages?
project euler stuff is just javascript, might as well run it in the browser.
I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that. What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?
The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.
I keep hearing about this, but has anyone actually done this?
It's probably not a HUGE boost in productivity, but it does feel really, really nice. And just knowing you can take your server-side data structures, trivially insert them into client-side scripts with JSON.stringify() or Ajax calls, and have the same helper libraries you use server-side be able to operate on them client-side, makes it so easy and flexible.
(I'm working on a project that uses IcedCoffeeScript both server-side and client-side, which lets us use the same async event-handling model on both sides as well -- another plus.)
I'm confused, what does this post have to do with Ruby, other than a brief mention about how Ruby's syntax is different from other languages?
I'm confused about what it has to do with node. project euler stuff is just javascript, might as well run it in the browser.
The post is mostly about convenience. I use javascript all the time. Now I can use it more. I love ruby, I just end up having to relearn it every time I use it because I don't use it often. Node is just the vehicle of that convenience.
A friend who is wrapping up the last year of his computer science education asked me last night "so what's this node.js stuff all about?". I thought about it for a few seconds and then told him the value of writing a web-app in node was the ability to use 1 language from top to bottom. In my experience, most of the detractors of node seem to miss the value that a homogenous programming environment can bring. I'm inte…
I've used node, and I just don't see it. You can share fragments of code, but for reasons of both security and logic not much more. In my view, the evented nature of node negates most of the pluses of one language. Additionally, javascript is a shitty language if what you want is a large amount of business logic. Python and ruby are much more concise and expressive. This is a huge win that a lot of people overlook. N…
These two things together completely transform Node, so much that I can't even imagine coding without them.
On a recent project I had to parse data from a set of csv files, while pre-processing the data and pushing it into a Couch database. At the same time I needed to generate a sqlite database with spatially aware geographic indexes using parts of the data, so we could build maps from the data. I ended up having a situation where the data was streaming into the couch database waaaay faster than the sqlite db could write the records, which resulted in the process growing in memory bogging the entire application down (the csv files could be uploaded via a form as well).
The solution ended up being that because my csv parser was building on the stream classes in node, i could literally pause/resume the stream based on the state of the buffer(s). This is exactly the same technique you would use when building an http proxy or limiting the transfer rate of file uploads. This is some pretty low level stuff to have to get into for a simple import script, and if I were to do it in something other than JS I would probably have used temporary files or separate processes or whatever. Debugging and testing this kind of problem is not really straightforward either.
As always YMMV, but I have become more appreciative of plain bash scripting as of late.
edit: formatting
The ability to share models/code between the client side and server side is magic at first. Javascript on every level with the data encoded in JSON? Yes, please.
I keep hearing about this, but has anyone actually done this?
The first is a hybrid desktop/web application to design maps using a CSS like descriptor language. The desktop app downloads actually bundle a local node server in an os specific wrapper, with a web view. The application works just as well hosted and accessed by multiple user.
The latter is a cloud service that allows you to host rendered map layers and remix/share them. Foursquare recently switched to using mapbox for all their browser based maps.
I'd estimate at least 90% of the code is shared between the server and the client, with the server side generally only differing when you need to access resources not available to the client (databases, files on the server etc). The user interfaces can be rendered on either the client or the server (w/ jsdom) as needed.
[1] mapbox.com/tilemill [2] mapbox.com/hosting
Earlier quoted context omitted.
This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them. Data sanitization and validation on the backend should be as thourough as that of the client, if not more.
Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.
The models can (and should) still be validated on the server before you actually save it, but this is child's play. There is a certain category of validation that can only happen on the server too, like 'has this username been taken already?'.
Earlier quoted context omitted.
Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.
My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically . The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data. As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is w…
I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that. What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?
> I don't want to have one process per request, so the obvious thing was to use something asynchronous There's these amazing things called threads you can use too