scriby

"Performance cost of Ruby ORM model instantiation" may not have been the best title :)

Developers hire other developers that think like themselves.

Technically oriented developers hire other technically oriented developers.

A mediocre developer won't be able to distinguish who knows their stuff or not. But at least getting team fit / communication / personality right is half the battle.

I worry that this sort of article could be misinterpreted easily, even with the disclaimer.

It's talking about optimizing something that takes less than 1% of the vast majority of an application's cycles. Which doesn't really mean anything... Be careful using this sort of benchmark to disproportionately affect decision making.

User experience > cute technical solution

That makes sense. I've been doing node js too long where you have to do this stuff by hand :0

This looks wide open to csrf attacks.

Another site can post a form on behalf of a user automatically, and the cookies for job poacher will be sent. Meaning that a malicious site can take actions on behalf of a logged in user.

Perhaps their solution is more complicated than they let on, but I doubt it given it's "20 lines of code".

I think in the real world there are a variety of cases that benefit from parallel operatio...

-Anything dealing with disk I/O like copying or reading files -Sending / receiving from S3 or other file repository -Making a request to external web services as part of a request -Working with document DBs like Mongo where instead of a join you can do one query per table in parallel

I would love it if you could check out asyncblock and see if you like how it helps manage control flow with fibers. It would be easy to integrate with what you have already. We use asyncblock in a very large node based application, and it's really helpful for keeping business logic straightforward and simple.

Another possibility would be using node-sync (https://github.com/0ctave/node-sync) if you prefer their approach.

I'm saying the framework doesn't have support for parallel tasks within a single request. For example, the case of kicking off two database queries in parallel, then doing something when both are finished. I understand that each request executes in parallel.

It's possible I missed how the framework supports parallel tasks, can you explain? The only thing I saw was wait(), which gives you "series" instead of "parallel". It's true people could still use callbacks/libraries to implement parallel tasks, but then we haven't gained much.

This appears only to support one-at-a-time synchronous control flow. Giving up parallel tasks is a funny proposition in node, as it's one of its greatest strengths. So this framework still seems limited in the potential uses, but maybe it will grow over time.

I wrote a library based on fibers that can provide similar benefits to any node application. It also gives simple patterns for error handling, makes debugging easier by maintaining stack traces across async boundaries, and provides really easy ways to do series and parallel flow control.

Take a look at https://github.com/scriby/asyncblock.

It would actually be pretty cool to integrate asyncblock into this project as it could provide the flow control portion for free.

I have to disagree with this.

There's plenty of ways to be creative and still be disciplined.

I find myself spending a lot of cycles reducing solutions to their most simple form -- removing everything unnecessary until just what's required remains.

Or, designing large systems. Giving my input on UI layout / design / experience. Imaging use cases and how users will use the software -- what assumptions will they make?

Data structure selection, sync vs async, and a whole myriad of trade offs and judgment calls are all creative processes.

We're professionals after all. We're employed for the finished product -- let's make it as good as we can.

You can always code outside of work to flex your creative muscles if you find your work environment too restricting.

My team at work uses Webstorm. It's a bit of a memory hog, but it works pretty well. The integrated debugger is great, and you get immediate feedback if your JS doesn't parse. The main weakness is the autocomplete could be a little smarter, but it's not useless. The editor regularly goes on sale for $40.

If you're looking for something free, you might check out the cloud9 editor. You can try the hosted version and install it locally.

Also, a tool like JSHint (less opinionated than lint) is a practical necessity.

I wrote a module based on fibers to help with these sort of problems. Take a look at https://github.com/scriby/asyncblock