3 ms·

I'd start with a website. Important is that you give yourself small tasks, just learning from books and doing exercises is boring and you learn often too much w

by tferris 14y ago

I'd start with a website. Important is that you give yourself small tasks, just learning from books and doing exercises is boring and you learn often too much which isn't relevant. I wouldn't do mobile development either: the learning curve is too steep and you face a fragmented landscape. An example path: 1. Build a plain web page without anything (and learn HTML, CSS) 2. Build more: a web site with multiple pages and little dynamics (and learn a backend language/system like Python or Node.js with Javascript) 3. Build a blog with more dynamic content (and learn a web framework like Django for Python or Express for Node.js and how to use them with a database like MongoDB or MySQL) I would start with plain HTML, CSS and later learn Javscript, then a little Node.js and then Express and MongoDB as database => that's the quickest way how to get things quickly done and to learn why and how things work. And you have basically to just learn three languages: HTML, CSS, JS and if you like some simple dialects (like Stylus instead of CSS and Jade instead of HTML). Or if you have some basic dev skills already just jump into Node and Express, you will have very soon first results. I wouldn't start with something too much 'magic' involved. Magic = abstraction that you do not understand anymore. Ruby on Rails is an example: you learn tons of conventions, see magic everywhere but won't have a clue for a very long time why and how things work and thus, you just learn conventions and won't learn really to code. Ruby on Rails can be very frustrating: you do Rails for three months and are still not quick or productive and then you think it's your fault or you can't code (but it's Rails with its magic, conventions and increased complexity where actual coding is a very small part). Don't get me wrong: setting up a site with Rails can be done in few minutes but customizing it without knowing how Rails works (and even if you know how Rails work) can be a real pain. With Rails you learn how to effectively glue things together, Rails ecosystems provides thousands of great and mature gems waiting to be glued together.

rcube 14y ago
yeah.. stfu
briandear 14y ago
Your bias against ruby is astounding. You recommend node and Django but recommend against rails? Rails isn't magic. The Michael Hartl book is a great place to start after Chris Pine's 'Learn to Program.' Of course the Pine and Hartl books might be a little too magical for an avowed Pythonista. As far as MySQL, you've lost your damned mind. For relational databases, why not build a heroku site and use PG? Who the hell still uses MySQL? My suggested 'Learn to Program' path would start with Kids Ruby, then followed by the Chris Pine 'Learn to Program' book followed by the Michael Hartl tutorial followed by the Big Nerd Ranch Objective C book. The Nerd Ranch book starts with an intro to C before getting into OOP concepts.
- tferris 14y ago
  > bias against ruby is astounding. There was no bias. Ruby on Rails is a mature production-level framework which gets things done. I've just said that it may not be the right tool for getting into programming. With Ruby on Rails too much is automated providing a DSL with a high abstraction layer and finally as one big monolithic piece. This setup might be good for an experienced programmer but I doubt it's perfect for an beginner. That's all I said and it's not bias, rather your post feels biased and very emotional-calm down. > Rails isn't magic You are the first who's saying this. I repeat myself but here again: magic is when the user doesn't understand the abstraction level anymore, when it's too far away from the implementation pattern, when the original desgin pattern isn't clear anymore and Rails definitely is. > You recommend node and Django but recommend against rails? Did you ever try Node, Sinatra or Django? Maybe you should before giving such strong opinions. All of them, espeically first two are more expressive and force you to think yourself. With Rails you have to learn the convetions, use them and still are clueluss what to do in exceptional situations because the RoR setup won't strengthen your real coding skills (I am just talking about newcomers!). With Node.js and Express, you have to think because there are much less conventions, it;s more modular and thus, you'll be forced to code more and decide which path to go, with Rails everything is given and often the choices are opinionated (SCSS, Coffeescript). Or you wonder which directory to use for which file in Rails all the time according to the convetions, that no coding! For the classic CRUD app Rails might be good. With Python/Django you have more abstraction but those are more related to the actual design pattern and thus more expressive than Rails—but do not startt a flamewar here, Django and Rails are very similar at the end of the day. > s far as MySQL, you've lost your damned mind. This is a really bad style and intolerant—this is not HN style. Instead of coming with arguments you get abusive without knowing the big picture. RDBMS are very mature systems, I wouldn't go with MySQL, rather with Postgres and for lots of systems they are the way to go. NoSQLs are young and there's some reasons they should be used by newcomers, especially Mongo: - No need for an ORM/ODM (for Mongo because of the good native JS interface, you can still use one and it makes sense but you do not need reallly) - No migrations, no scheme You still can do both with NoSQL/Mongo but to get started to get out of the door, just to understand what a datastore does the complexity level is just right. An SQL with all its migrations, schemes, ORMs, join tables is too much for a beginner. We know this stuff for years but a beginner?? A beginner has to get quickly some positive experiences which he understands and then Node with Mongo is perfect. Of course Rails + ActiveRecord is great to get started quickly but it's abstract and the beginner would not dare to leave the given path because he doesn't know how to directly access the DB. Later he can always switch to a SQL and a ORM (also in Node and with NoSQL) if he likes. BTW, this is not just for beginners, for many projects this setup makes sense, it's just a new way. Rails is now 7 years old and lot of people like to stick to old paradigms. And ORMs in particular ActiveRecord are debatable, ActiveRecord is slow and clumsy and often not the right choice for scalable high traffic use cases. Finally, your recommended way is a muddled and confusing way with too much theory. First he should start with some high level Ruby, then some theory, finally some Objective C and then C?? Which logic does this follow? Most important when learning something is to have steadily successes in order to stay motivated. Small tasks are important to stay interactive to get self-confidence, just learning theory for days doesn't work without having any good use case at all and following some dull examples from Hartls tutorial won't help either. I know that a proper way would include C, OOP and so on but the way would be too long for startes.

by tferris 14y ago

rcube 14y ago

yeah.. stfu

briandear 14y ago

Your bias against ruby is astounding. You recommend node and Django but recommend against rails? Rails isn't magic. The Michael Hartl book is a great place to start after Chris Pine's 'Learn to Program.' Of course the Pine and Hartl books might be a little too magical for an avowed Pythonista. As far as MySQL, you've lost your damned mind. For relational databases, why not build a heroku site and use PG? Who the hell still uses MySQL? My suggested 'Learn to Program' path would start with Kids Ruby, then followed by the Chris Pine 'Learn to Program' book followed by the Michael Hartl tutorial followed by the Big Nerd Ranch Objective C book. The Nerd Ranch book starts with an intro to C before getting into OOP concepts.

tferris 14y ago
> bias against ruby is astounding. There was no bias. Ruby on Rails is a mature production-level framework which gets things done. I've just said that it may not be the right tool for getting into programming. With Ruby on Rails too much is automated providing a DSL with a high abstraction layer and finally as one big monolithic piece. This setup might be good for an experienced programmer but I doubt it's perfect for an beginner. That's all I said and it's not bias, rather your post feels biased and very emotional-calm down. > Rails isn't magic You are the first who's saying this. I repeat myself but here again: magic is when the user doesn't understand the abstraction level anymore, when it's too far away from the implementation pattern, when the original desgin pattern isn't clear anymore and Rails definitely is. > You recommend node and Django but recommend against rails? Did you ever try Node, Sinatra or Django? Maybe you should before giving such strong opinions. All of them, espeically first two are more expressive and force you to think yourself. With Rails you have to learn the convetions, use them and still are clueluss what to do in exceptional situations because the RoR setup won't strengthen your real coding skills (I am just talking about newcomers!). With Node.js and Express, you have to think because there are much less conventions, it;s more modular and thus, you'll be forced to code more and decide which path to go, with Rails everything is given and often the choices are opinionated (SCSS, Coffeescript). Or you wonder which directory to use for which file in Rails all the time according to the convetions, that no coding! For the classic CRUD app Rails might be good. With Python/Django you have more abstraction but those are more related to the actual design pattern and thus more expressive than Rails—but do not startt a flamewar here, Django and Rails are very similar at the end of the day. > s far as MySQL, you've lost your damned mind. This is a really bad style and intolerant—this is not HN style. Instead of coming with arguments you get abusive without knowing the big picture. RDBMS are very mature systems, I wouldn't go with MySQL, rather with Postgres and for lots of systems they are the way to go. NoSQLs are young and there's some reasons they should be used by newcomers, especially Mongo: - No need for an ORM/ODM (for Mongo because of the good native JS interface, you can still use one and it makes sense but you do not need reallly) - No migrations, no scheme You still can do both with NoSQL/Mongo but to get started to get out of the door, just to understand what a datastore does the complexity level is just right. An SQL with all its migrations, schemes, ORMs, join tables is too much for a beginner. We know this stuff for years but a beginner?? A beginner has to get quickly some positive experiences which he understands and then Node with Mongo is perfect. Of course Rails + ActiveRecord is great to get started quickly but it's abstract and the beginner would not dare to leave the given path because he doesn't know how to directly access the DB. Later he can always switch to a SQL and a ORM (also in Node and with NoSQL) if he likes. BTW, this is not just for beginners, for many projects this setup makes sense, it's just a new way. Rails is now 7 years old and lot of people like to stick to old paradigms. And ORMs in particular ActiveRecord are debatable, ActiveRecord is slow and clumsy and often not the right choice for scalable high traffic use cases. Finally, your recommended way is a muddled and confusing way with too much theory. First he should start with some high level Ruby, then some theory, finally some Objective C and then C?? Which logic does this follow? Most important when learning something is to have steadily successes in order to stay motivated. Small tasks are important to stay interactive to get self-confidence, just learning theory for days doesn't work without having any good use case at all and following some dull examples from Hartls tutorial won't help either. I know that a proper way would include C, OOP and so on but the way would be too long for startes.