638 karma · joined October 21, 2013
The magic of the tutorial (to me) is that it tries to package together the entire development cycle for you. It gives you the foundation for building a real usable, launchable application. Concepts like authentication and authorization are extremely important and usually not covered very well. You learn to set up heroku and push updates. You learn testing, version control etc.
For someone who has finished codeacademy, javascriptissexy, etc., I think a common problem is, "ok great ,I understand for loops, and while loops, wtf do I do now? I have this CRUD problem I want to solve that no one else is solving. How do I put it together? I want a login page. I need to input information. How do I connect all this?"
Once you finish this tutorial, you know what the process looks like for Rails. Then you can genericize your knowledge and explore Sails, Meteor, Django, Flask, Ember, MEAN, Play, etc with a foundation and an ability to start asking questions.
For all the "non-technical" people out there who want to see their ideas come to life, who are considering hiring contractors or paying for a class, or posting on HN or founder dating for a technical co-founder, stop. Take a step back. Forget about your idea for a week or two and immerse yourself in this tutorial and learn about what it takes to put something together. You and your software related projects will be better for it.
For Rails that would probably be https://www.railstutorial.org/.
For Meteor, that would be https://www.discovermeteor.com/.
I can't speak to Django or Flask. Or node based platforms like Sails.
I would recommend the Rails tutorial even if you don't ultimately settle on Rails. There's something magical about that tutorial. I recommend it now even though it is not my platform of choice.
There are plenty of reasons why waiting X amount of time will ultimately have little impact on the success of your product. And even if someone launches first, there are plenty of ways that you can still win.
Moreover, based the scope you described in the linked post, it's likely you could learn to chop together what you're looking for within two months of hard work. There are more than enough tutorials on related subject matter that you could use to piece together a functioning version of what you're hoping to achieve.
Go with #1; hope for #3; meh on #2. (I hope someone disagrees and gives you a good alternative viewpoint.)
As a Meteor developer, I would pay for a solution that allowed me to use Meteor's collection of magic on a platform that was built specifically to take advantage of said magic.
I think I'm going to wait a while before buying.
All of this is to say, it is not the case that the legal system is gung-ho about giving juries complex IP issues while simultaneously avoiding juries for "easier to understand" criminal matters.
The judge and lawyers are concerned about making sure each juror is unbiased. How you answer question A regarding topic B could be very revealing of your bias towards the case even if neither question A nor topic B have anything to do with the case. People often lie on question X on topic Y (questions and topics more directly related to the case), or their answers often don't reflect how they actually act in the jury room.
I do have to point out that many of the people I know at these firms who seriously enjoy their lawyering jobs are people who go to law school after having a real job in Field A and then practicing law in Field A. For example, someone with a PhD in Biochem and worked at Amgen as a research scientist then becoming a licensing attorney in biotech. Or someone with an EECS degree who becomes a patent litigator focusing on hardware or software disputes.
I don't think escaping to government is out of reach. I also don't think its "underpaid" (although that's relative). Granted, you'll likely have to be at the top of your class in order to find that sort of escape route, and if you're at the top of your class, the world is your oyster anyways.
A lot of the cruft will go away with the rise of machine intelligence. But the $xxxx/hr attorneys won't be replaced. Knowing the law and the facts is only 1/3 the battle. The rest of it is crafting your story if you're a litigator or negotiation position if you're a transactional attorney, understanding your clients business and needs, and putting all the pieces together. Good artists and story tellers haven't been replaced even though everyone already knows www.tvtropes.org. Rails engineers won't disappear because of https://news.ycombinator.com/item?id=7985162. If your value proposition is dependent on doing menial, time-intensive tasks, you will eventually replaced by a computer.
Feel free to contact me.
The book is also very good: https://leanpub.com/javascript-allonge
What I want to know is what kind of magic YC saw in the application that got the team the interview. Because even from the team's perspective "There was no business model to speak of, the market size was unclear, we didn’t have much of any secret sauce, we hadn’t been working on it that long and the list goes on."
Is this an instance where the team was so compelling it warranted an interview?
In fact, the talk seems appropriate for every discussion regarding, but not limited to, how terrible JS is or how it should die.
The other argument in favor of class action contingency structure is the alignment of interest between plaintiffs and attorneys. Although as already pointed out in other parts of this thread, perhaps the incentives begin to mis-align when settlements reach a certain size?
What is a better alternative? (Other than preventing stuff like this in the first place.)