jimrhoskins

s/toSring/toString/

To others, the demo question on the home page is a divisible by 5 or 7 problem. This is one of the guest challenges and is that the number contains the digit '7'.

Also, the JS seems to be quirky:

    function jsChallenge() { 
      return 1;
      return 2;
      return 3;
    }

Returns 3

I feel like such a tool for saying this, because I thought people who said this were tools before I 'got it'. Taking your fingers off the keyboard and to the mouse and trackpad is slow. I now even get how moving your fingers to the arrow keys is slow. I never thought I would believe it, but somehow here I am, spouting the same nonsense.

It's true. I think there is just some mind-body-editor connection that develops with vi(m) usage (and emacs, I don't know). When you really start thinking in vim, your mind starts describing what you need to do in vim commands, that magically flow out of your fingers, and vim responds.

In other editors, for any task I need to do, instead of telling my editor to do something, I have to show my editor how to do it by selecting text and menu items with the mouse, it just feels clumsy.

Once the keystrokes are muscle memory, it's impossible to beat with point and click in terms of speed.

That's just an opinion from a vim novice that can never go back.

I used to think like that, then I realized, I am going to be editing text for at least the next 20-30 years (if not longer). I get the feeling vi(m) (and emacs) will be around then, so it's an investment worth making.

It only took a few weeks to reach the efficiency I had with TextMate, and every week since I've become more and more efficient. I haven't hit the point of diminishing returns in learning about my editor, and judging by other vim users I've seen, I probably won't for a long, long time.

Cool, thanks for the tip, I watched the video. It looks like you're doing some cool stuff, but it doesn't look appealing to me as a developer who is already comfortable with node.

The biggest mental leap for me is that you are using JSON objects to define sequential code. JSON defines an object as unordered. Obviously your compiler maintains order properly, however it just "feels wrong".

Like I said there is no way you can convince me to write code in a browser (unless there is an absolutely magical benefit), so writing fjson manually looks difficult both in the amount of extra syntax, as well as trying to connect the data to what it's doing.

The last thing that would hold me back is the debugging experience. Will i get back which lines im my documents are causing runtime errors, is there any static checking in place to make sure the strings of code are syntactically correct?

It's a big leap for me, but that being said, I definitely applaud you for developing something new and experimenting. I'm interested in seeing where this evolves.

I only watched the first few minutes of the video, then skipped around. What is the benefit of fire, as a framework? Can you work without the Fire IDE, and would that be worth it?

I just can't see giving up my text editor to click around a web interface to write code. It just seems orders of magnitude slower to me.

It looks cool and I appreciate the effort, I just have a hard time figuring out the benefit of fire to me as a developer.

12factor.net is not connecting for me right now. Google cache says it is this: http://twelve-factor.herokuapp.com/

I could be wrong but I think ICEfaces [1] for Java does something like this. I remember seeing a presentation on it at a Rails vs Django vs Java "debate" a few years ago.

It may not be quite the same thing, and I can't really parse the website very well for how it really works. I do remember it holds a copy of the DOM server side then manipulates it over HTTP.

So if you want it in Java, there's that.

[1]http://www.icefaces.org/main/home/

If you're in Orlando, stop by the office. Just tweet at someone here so we can expect you.

http://bit.ly/treehouseoffice

Several of the videos include Code Challenges, which test your knowledge by writing real code in the browser. We are going to be expanding this tool throughout Treehouse to offer more opportunities to code-along as well as take challenges.

I too learned Dev and Design through free resources and googling (It's still how I learn), but a lot of people find value in having a path laid out to them, and having consistency in the resources they learn from.

Of course a lot of people on HN are going to be people who taught/teach themselves everything, but a lot of people want some hand holding, and that's what we aim to provide with Treehouse.

Subtitles should be available on all videos when viewed on the website. Any videos without subtitles are currently being subtitled currently and should show up soon.

We have added Code Challenges, that allow you to demonstrate your knowledge using real code in the browser to learn badges.

Treehouse has been around under the name Think Vitamin Membership for about a year and a half. We charge a subscription (from day one), and reached profitability before we took on our investors.

Treehouse used to be called Think Vitamin Membership. It's been around for about a year and a half, and the testimonials are from current customers.

That is correct.

Ethan, the author of the RWD article, was actually on the team who worked on The Boston Globe site. He's been giving talks on the project and the process. I don't know if it is anywhere online, but it's very interesting.

Got me too. Damn

The advantage is that Node uses async/non-blocking IO.

For example, say your portal needs to collect info from 3 sources A, B, and C. In a synchronous system, you would have to request service A, wait for a response, then request B, wait, and so on. This means your request is utilizing the system for all that time, unable to serve other requests, without extra threads or processes.

Node, and other async systems, when they call for IO, like a service, a callback is registered for the result. So instead of having to wait for the result, the system becomes available for other actions, like other requests. So in this case you could request service A, B, and C all at once, and while you are waiting for the responses, the system can be handling other requests. When any of those services completes, it calls back to your code so you can handle the results, and give a response to the client.

So the advantage is that instead of a request taking A + B + C + extra time, it can take max(A, B, C) + extra time to serve the request, while serving other requests concurrently.

Node is not the only way to achieve this, many async systems exist like Tornado for python, EventMachine for ruby, and many others. But the JavaScript in node can be particularly fun to work with especially if you are also doing the front-end JavaScript, as it pretty much brings the context-switching in your brain to almost nothing.

Amazon is too big to fail/be kicked out of the market.

Yeah, in the isometric view it all looks like 1x1 sticks, but the schematic will fill with longer bricks. You can stagger them yourself when you build, but we are working on the algorithm to make it more structurally sound.