UPDATE: This was probably really stupid of me to do right now, but I've been wanting to change my GitHub name for awhile... and just did... so if anyone would like to checkout the repo you can find it now at https://github.com/kulte/ratchet-signup
Thanks for mentioning Kendo, hadn't heard of it, just checked it out though... kinda pricey :) I think it's pretty awesome that someone developed a free, open-source mobile UI prototyping framework.
The awesomeness in my opinion is that a) this took me literally five minutes which means that I had to write absolutely none of my own CSS classes for mobile prototyping, the wonderful guys who developed Ratchet did that for me already! Also, Ratchet is not an MVC framework, it's a front-end iPhone targeted mobile prototyping framework. It allows you to prototype a mobile UI with HTML/CSS/JS faster than prototyping in native Objective-C. At first glance, I honestly think these guys are being humble by calling it a prototyping framework. I could see myself using this for mobile web versions of my apps, although that does presuppose that everything "works" pretty closely to the level one would expect it to reading the docs on their homepage. Check out the link I posted in another comment, you might be confusing Ratchet with something else.
I think it really comes down to a matter of preference. This looks interesting to me, and it caught my eye when I saw it on Hacker News much in the same way Meteor did when it came out. For me personally, it just passed the initial smell test really well.
In terms of some concrete attributes which I like, I think it probably is the best framework I've seen in terms of the general aesthetic. I have high hopes that it will allow me to create most of the view elements I'd need to prototype in an incredibly short period of time. I haven't used jQuery mobile for some time now (> 1 year) yet it seems like there are more CSS classes in Ratchet that mimic the iOS look and feel well enough that one could develop a full iOS app prototype in a day or less. If I remember correctly from using jQuery mobile, there was a bit more code to write, and the general look just didn't feel as good to me.
If what you mean is there a CDN for the Ratchet javascript, I don't think so. If you go to the website http://maker.github.com/ratchet/ there is a download link, but my repo just augments what you get in the download folder... like I said, 5 minutes :)
EDIT: I see what you mean now, no I didn't put up a hosted link since I just developed the one screen during a 5 min break. That's a decent idea though, maybe I'll make a full demo application (maybe I'll make it a Todo list, no one has ever used that for a demo app before) and put it up on Heroku.
I also recommend for node Guillermo Rauch's Smashing Node.js. Also Javascript the Good Parts by Crockford is the cononical language resource for Javascript, once you've reached your inevitable local maximum in just having knowledge of node.js and not much Javascript per se.
I agree that having a job and doing a startup is not giving either of those things a fair chance at succeeding. But also if I had to add one thing, I'd say that most entrepreneurs simply give up too fast. This might have represented a true test against how badly you actually want to have your own business (non lifestyle business that is) and maybe your decision is the truest manifestation of your real desires, but I think that if you know that what you really want is to change the world with a "let's blow this out of the water" type of business, then less than 3 years is simply too soon to give up in my opinion.
A few observations. One, you haven't written that many pages, in fact you've written very, very few pages save for the preface and the like. This isn't an issue on its own, except theres no Table of Contents so it's hard for me to see where you are going to take it from here, or in other words what your vision is. The obvious result of this is that it's pretty hard to provide feedback. The flip side is of course, that you've demonstrated enough desire and initiative within yourself to endeavor to start the book, so unless you have a serious reason to stop, maybe forge ahead and try to finish what you started.
One other thing that I just want to put in your head, I'm not sure if I'm even going so far as to suggest it, is the possibility of flexing scope to write perhaps a 50 page e-book, not dissimilar to the Sacha Greif ebook (http://sachagreif.com/ebook/) but for getting from zero to the next book on Rails for absolute beginners. The benefit of this would be that you could probably spend about 20 hours writing it (I'm pulling this number out of my ass, so I could be waaay off about this time estimate) and therefore you've risked a much shorter amount of time, which I'm assuming is your main concern.
I started writing the book on the weekend, and have tried to include details about the main concept and format (it's going to be split into three books). As it's early days I've only really touched on what will actually be included, but my thoughts so far are along these lines:
An introduction to Object Oriented Programming |
Ruby basics |
-why ruby |
-datatypes |
-variables |
-classes |
-etc |
An introduction to Rails and the MVC architecture |
-why rails etc |
A Ruby on Rails tutorial - building your first app! |
-1 |
-2 |
-3 |
-4 |
-etc |
Using Gems |
Using Git |
Deploying |
An introduction to Test Driven Development |
-------? |
-------? |
-------? |
Originally I sought feedback from my friends, and as that's been very positive I thought it wise to get opinions from a wider audience, such as on HN.
Thanks for the link to the Sacha Greif book - I will definitely check it out!
First off, let me state that I in no way wish to diminish the accomplishments of the authors of RailwayJS in making these comments. I think they've built an inevitable framework given that Rails was (and likely still is) the most popular open source web framework (at least as far as the HN/startup crowd goes) and of course why not give developers the same abstractions they have with their old favorite when a new thing comes along. But here's a constructive observation:
Node.js isn't a framework. AND it's not a programming language. Node is ostensibly a set of libraries and a runtime environment. I've been to a few Node meetups over the past few years, and inevitably people (not just newbies btw) will ask "what will be the Rails for Node?" But I think making this analogy is wrong. It's wrong for two main reasons, the first of which is that it implicitly compares Node.js to Ruby, which is a category mistake. More importantly though I'd argue, it's wrong because making the Rails for Node analogy deprives the developer (you!) of the opportunity to allow an emergent programming paradigm to change the way you think about programming! So how should Node do that? My fantasy for how Node.js will evolve in the next few years is that it will be a series of node packages which can be easily dropped in and out of my programs. I believe that the goal of the third-party node package development community should be to encourage this modularity, because I think it is the right abstraction for what Node.js actually is, and not necessarily what some people might wish it was. It's easy enough to set up EventMachine in Rails and then you can use your familiar stack, but I'd encourage anyone looking to use Node.js to fully embrace it and use it as an opportunity to explore new workflows, and not just try to fit your old stack into an event loop.
In the past few weeks, I don't know why, but I took a prominent note of how easy application development has become. The fact is that someone probably could learn how to write a web application in Ruby on Rails in three months without much hinderance. Production quality, probably not, but a REST API persisting to a database and implementing some business logic, absolutely.
It scares me a little (a really little) in that this trend is ostensibly a precursor, or leading indicator if you will, to the increasing commoditization of our profession. But here is the thing. There are steps that we can actively take to mitigate the complacency that recent technology has afforded to us. This is likely where I agree with the author the most. If your skill set is narrower than you wish it to be, engage problems in a different domain, and acquire the knowledge to do so beforehand. Meanwhile, if you're one of the people, like me, who feel beyond fortunate to wake up everyday doing something that you love, then continue to do that, stay hungry to learn new things all the time, and hope that that will be enough. That's pretty much all you can do.
Am I the only one that sees commoditization of programming as a good thing? I long for a world where everybody could define simple-to-moderately-complex automated behaviors, without needing to pursue a career in programming.
Tools like Apple's Automator or Android's Locale provide low barriers to scripting for the masses, but they fall short of providing a good, easy to use abstraction mechanism; in the end they amount to classic imperative languages, which are difficult to master.
On the other hand we have the Spreadsheet, the only widely successful End-User-Development tool, ever. This one provides a really good for building abstract data models and workflows - I've seen it used by people without any programming understanding to develop complete form-like applications, collaboration tools and storage repositories. Unfortunately, using those required a lot of repetitive actions. The spreadsheet model does provide a good abstraction mechanism but does not support automation capabilities; you still need a classic scripting language to automate behaviors.
I hope the recent live programming fad initiated by Bret Victor's "Inventing on Principle" will finally produce widely used reactive environments; those are a good basis for non-programmers to begin programming without a steep learning curve and only up to the point that they really need.
An even quicker introduction to the final specification of WebSockets: http://socket.io.
P.S. I'm aware that a) this doesn't help anyone not using Node.js on their server (it's not even part of my production stack at work (yet!), even though I'm bringing it to light here) and b) it's more than just WebSockets, for instance it will gracefully degrade on legacy browsers.
I just can't miss an opportunity to sing its praises because it has so many benefits over the simple implementation.
