The Odin Project – Learn Web Development for Free
theodinproject.com
theodinproject.com
Anyone starting web development now would do well to stick with Javascript. No, it's not the nicest language, but there's no avoided it. And you can always use that on the backend if you have to - and if you need to spend time learning something for the backend part you'd be better served learning about relational databases than Ruby.
Anyway, between JS, HTML, and CSS, you're going to have a lot to learn. At least with CSS these days you can pretty much start with flexbox for layout, and maybe if you're lucky you'll never have to learn all the old horrible methods of getting things to look reasonable - or you'll have a solid foundation when you do encounter them.
Not that I think Java is a pleasant language. It is quite a monstrosity in terms of syntax and verbosity, but that doesn't mean it isn't useful to know.
And an actual question: when hiring for [junior] web development roles, would you for example take into account knowledge of non-web languages like, say, 6502 assembly & C++?
I'm curious as in the coming year I'll be graduating and on the hunt. Although I consider myself proficient in JavaScript (and Python to a much greater extent) my hobby interests lie more in microcontrollers, "retro" programming, and just general electronics. Would that sort of background be a boon in your opinion, or would you prefer a candidate with more strength in web technologies? (though by golly I swear I will one day get my homebrew computer connected to the World Wide Web!)
Also, my experience with the nodejs ecosystem has in general been better than with Ruby Gems. I have always hated Ruby magic and the problems it causes in gem incompatibilities.
The problem with the magic for the 80%, is that the remaining 20% takes up the remaining 80% of the time. With the first 80% of the delivery in 20% of the time, the final 20% taking 4x longer because of the lack of understanding of the magic gives no advantage in the end.
Thats if everything goes well. If the 80/20 rule fails, you get the ninety-ninety rule ( https://en.wikipedia.org/wiki/Ninety-ninety_rule ).
RoR lets one build crud without understanding what goes on beneath the ActiveRecord. RoR is great when there is low complexity of the code and it is easy to follow the data through the pipes. Once it goes beyond that, adding complexity to that with the spooky action, highly declarative style that RoR encourages it can be painfully difficult to do - and something that far beyond what the 'write crud in 30 mintes/hours/days' classes offer.
Beyond that, with the failure to understand the before and beneath, one gets the impossible to debug bugs and security holes that lie within libraries that have been imported ( https://williamedwardscoder.tumblr.com/post/43394068341/ruby... ).
I disagree. RoR is great when there's moderate complexity. Microframeworks (Sinatra) are better for low complexity, and everything with high complexity is a unique and special snowflake.
> Magic is wonderful when it works right, and painful when it goes wrong
...and really educational when you start digging into it, and then you generally realize it only went wrong because you were trying to do something stupid.
> the remaining 20% takes up the remaining 80% of the time
Sure, but that's because the first 80% took a fraction of the time, not because that last 20% takes a multiple.
Do you have a particular example?
> spooky action, highly declarative style that RoR encourages
This is a bit of a "cognitive style" difference. In most of RoR - particularly your models - you want to be describing the idea of the thing. Since most people start programming by writing procedures, this is a bit of a leap. RoR Models are not about how a thing gets done, but about what that thing is. When you think from this perspective, RoR models are easy and nice.
> Beyond that, with the failure to understand the before and beneath...
Straight up, I want you to explain the complete before and beneath of your favorite tech stack or this is problematically hypocritical. I would then also want you to explain why it's reasonable to expect this of all programmers, rather than just senior programmers.
I can answer this one. I could explain to you every aspect of go's net/http package and database/sql package. The interface is compact, and even the source is very legible and easy to digest. You don't need all the extra bullshit to build API and run CRUD operations. I am a former RoR developer. I have lost no speed in just using simple tools and simple packages.
Also, I can have a junior or associate developer from any background get up to speed in a matter of days. Where as when I was at the Rails shop, you specifically had to hire a "rails guy/gal" and even then still took them days to get started.
(Don't mean for this to be a "go is great" rant, I am sure there are equally simple tools out there - Dropwizard is another one that comes to mind -- just a bunch of jars glued together)
It is possible to learn good practices without seeing well-structured applications that you can use as "role models", but it's really hard (I know, I had to read how to structure n-tier applications from books, and then apply it to a deficient platform that my employer had standardized on).
The "just use standard library" argument often seems a bit deceptive to me, though. For example, how are you managing schema updates?
Absolutely, not saying my experience doesn't translate. However directory structure doesn't exist like you think in go. Files are the primary organization, and the only thing that goes in subfolders are different packages. It's actually quite nice, now I don't need to dig into 4-6 folders to get to the important stuff like I did in my Java/RoR days.
> The "just use standard library" argument often seems a bit deceptive to me, though.
It is absolutely a mantra in the go community. No deception here.
> For example, how are you managing schema updates?
Use your favorite tool! So funny you mention, I have a RoR background and I loved active-record migration, so I use standalone active record migration https://github.com/thuss/standalone-migrations, but you can just as easily use any other schema migration tool like Liquibase.
But what I am learning more and more these days is to just write sql. Write your migrations in plain sql. It's always easier for everyone involved. SQL is a ubiquitous language.
Nice! That sounds really appealing; I want to learn Go, I just haven't felt like I've identified a problem I want to solve that's best solved in Go.
That said, the obvious direction this questioning is going is...
Well, but either you're relying on the database and networking magic, or you need to understand the before/beneath of the database and networking; and it keeps recursing down until you get to the point of electrons in silicon, and then the switch is "magic of the scientific method".
How do you draw the line of "this magic is fine" and "this magic is not fine"?
It sounds like maybe the line isn't "do you know" but rather "what does it take to learn", and that Go makes it easy to learn the before / beneath?
I'm not saying that Rails has no place, and it might well be the best next step, but I wouldn't put it (or Django, maybe Express) in a course for absolute beginners. Perhaps in the follow-up course :)
Nearly every single PHP framework is faster and more intuitive to deploy than Ruby on Rails.
I am definitely a fan of Ruby and Rails. So I am biased. But I have deployed my fair share of PHP and find it hard to imagine how it is easier.
Places like digitalocean have prebuilt machines for both. On a new centos or ubuntu server installing php/composer/laravel can be done in 10 steps.
In the laravel world we have forge which allows you to script and provision your stack
We're talking about novice web development and you're invoking AWS?
PHP is unzip, plug and play. Or single click any VPS "LAMP" package and go.
EDIT: Also, let's assume the target person runs a Windows machine. XAMPP is at least... 10 times easier to set up than Ruby/Rails on a local instance. And that's being exceptionally charitable.
Once you are more advanced as a developer or have a larger project then you might not like some of the choices that Rails makes, but it not only saves work but does more than most teams could or would realistically do if they have to assemble an application with just Sinatra or Express as a base.
For learners, having the framework lay out known-good stuff in a standard structure for all of the dozen or so elements that a Web application needs is incredibly helpful. You can let Rails create the application skeleton, and then work through the different parts, knowing that it all hangs together.
Maybe a better tact at why JavaScript first: people are far more likely to hire junior front end people than junior backend.
This.
What's a synergistic language? Javascript (i.e. it's required learning for the browser, and you get the backend with Node - and you point this out.) Javascript has advantage from browser monopolization.
What's a great and increasingly popular language for the backend? Python. And Python is so nice that we don't need a slogan about how "Guido is nice so we are nice" (with apologies to Matz and the dwindling Ruby community).
Write your software so simple that there are obviously no deficiencies, not so complex that there are no obvious ones (Hoare, 1980). Ruby is way more complex than Python because there's a bajillion different ways to do it.
To me the only point of learning Ruby is if you're already in a job that maintains a Rails app.
The battle for the supreme interpreted language isn't over, but, like Perl, it's my humble opinion that you can count Ruby out.
I would definitely say that these are serious strengths of Ruby, not weaknesses. Here's why:
Ruby is foremost concerned with the experience of the person using the tool. To use an analogy, many of us spend a lot of time finding keyboards and layouts that harm us less, or do not actively harm us. You would avoid using a hammer if the grip was painful to hold.
Ruby may appear to have a bajillion ways to do something, but actually, it's just many different ways to communicate the same few things to other people. Since you are free (and able) to use any of many ways, you can choose the one that is actually the most communicative, not the one that should be the most communicative. But, as you begin to peel back that facade and understand what's underneath (that everything is a thing that is a combination object, reference, and function), you see that it's actually pretty simple.
The result of this is that in Ruby, you can - and can benefit from - deeply considering the structure of the thoughts that code describes. Particularly in Rails, you can consider the idea of the thing you are dealing with, and then you write down the description of that thing; Ruby magic then makes that description code.
That is, ultimately, why I think Ruby is a "synergistic" language, and an excellent one with which to start: it [can] teach you to think in a way that's independent of any given language - about what is occurring for the computer, and more importantly, what is occurring for the programmer. You can then take that learning and apply it everywhere else.
Mostly, I just know how bloody frustrating it is to work with (most) libraries and APIs that aren't from (or inspired by) Ruby-land, and how (generally) easy and convenient it is to work with things from (or inspired by) Ruby (and Rails).
This is primarily because most of the "learn X" that I've seen for Javascript is pretty web-centric, while the "learn Ruby" things that I've seen are much more general CS. So the idea is to first get a basic grounding in general programming, and then jump into the thing you'll use a lot for your particular application.
Example: Learning about scope in JS versus basically anything else.
Also, Rails really does encode basically all the best-practices - so when you literally don't know any better, you can still succeed. And then when you move away from Rails, you have a known-good way to start anything.
basically nodejs is not just getting into express anymore. although optional, most likely you will soon have to get into things like react, flux, transpiling, and understanding immutable and fuctional programming, which are all IMO a bit too much for developers to jump in to. also, js is currently changing at a rapid pace, what they learned a year ago is most likely obsolete in todays standards, ie: es5/6/7/next. i have not seen a language change so many times in such a short period of time, i cant imagine how beginning developers can deal with it.
i actually had a chat with recently grad bootcampers who went through a 3months courses of rails and then nodejs/react from General Assembly in LA. their responses to rails was easy to learn and they picked it up right away. but once they got to react/nodejs their experiences were something closer to horror.
id say js indeed was a good choice for beginners 3 - 4 years ago but now there are so many baggages involved such as dealing with setting it up through webpack and its many ways to transpile such as esnext/jade/stylus/etc.
so unless you have a few years of programming experience, i would not recommend devs to go through js at this time.
basically i can teach someone rails on how to build real world applications in a few weeks. but with js, id still be explaining the internals like what is a promise, async vs synchronous function, etc. and this even before diving into the world of redux, map reducers, webpack, immutablejs, higher order functions, and ... the list goes on.
anyway you take it, its a long road ahead with js, much longer than most people will tell you.
Someone learning web development now has a long road ahead of them. They'll need to learn everything. Not just some backend language, but all the front-end frameworks, functional programming, Sass, build tools, typescript, etc. The list is endless.
news.ycombinator.com and its various tentacles runs on Ruby and Arc
Ruby has very expressive syntax, allowing beginners to focus more on the core programming concepts. Its object model also makes it a nice language to learn the basics and best practices of OOP.
The resources out there for beginner programmers and Ruby are also top notch and the community is very friendly to beginners.
This is completely anecdotal, but we've had a fairly decent number of students come into the chat rooms telling us they started with javascript as a beginner but weren't getting it, ruby was much easier for them to get up to grips with.
I admit that I've seen a few students put off with the magic in Ruby, but those really have been a very small minority of students compared to those who really embraced learning it.
In saying all this, we have plans to focus more of our efforts on Javascript and give students the option to choose a javascript track in the curriculum.
I question starting people on Ruby for web development.
Anyone starting web development now would do well to stick with Javascript.
And you can always use that on the backend if you have to
and if you need to spend time learning something for the backend part you'd be better
served learning about relational databases than Ruby.
When learning/teaching something you very much want to pick something that:
1. Has been around for at least 5 years
2. Is actively used, maintained, and overall has proven itself
3. Has good documentation and tooling
4. Perhaps has programs to help people getting started (Rails Girls, PyLadies, etc)
5. Is still around 5 years from now
Ruby and Rails are a perfect choice for this, though Rails (just like most frameworks out there) _is_ a bit complex for total beginners.
And if you look at the recently published (and fairly well received) IEEE language rankings, you'll see that Ruby is ranked 9th for the number of jobs, and has Java, C#, Python, and PHP ahead of it - all languages with one or more major web frameworks. Any of them would be a better choice for someone looking for work, according to these charts.
Also, let's be honest - in the scheme of things, no-one uses Ruby on the front-end.
[0] http://spectrum.ieee.org/static/interactive-the-top-programm...
Anecdote: I hired an Odin Project "graduate" in early 2015, somebody who had gotten a CS degree 10 years earlier but never done anything with it. The Odin Project had prepared him to hit the ground running on modern web software development, and also prepared him for evaluation for our job, with an impressive capstone project. He was a successful hire without a doubt.
- When doing my first lessons on ruby you are asked to read several tutorials. I thought, well I already learned that, but in every article I managed to find something new.
- It uses a multitude of other learning sources, does not even try to cover too much themselves. So you get to learn in very different ways. Reading good articles, watching some talks, downloading a repo where you need to write the code to make the test run successfully. Overall I feel, I get the best content, not because they write the best content (who could do that for all the subjects?), but it points you to great content.
- Contrary to many online tools, it forces you to work on your own system, which is a good thing.
- It often forces you to define the problem you are solving yourself. Many online courses make it too easy, you just learn coding. You don't learn to structure the problem.
- It also tries to give you a solid programming knowledge before going into web development. I really appreciate that. It's so easy to learn some angular or vue.js, then you... just need to fetch some data, ah how do I store data, oh and authentication and authorization, oh and... and quickly you get lost. I think it's is very beneficial to first get some solid programming knowledge before diving into the whole server / db / frontend stack.
So I can highly recommend this approach. BTW: even the creators are thinking of driving the course more towards JS (https://github.com/TheOdinProject/curriculum/issues/5633)
edit: formatting
"they've been totally in control of the process until now and they've probably dragged their feet because they can (who knows, an even better developer might show up, right?)."
I don't care about the which-language-is-best-to-start-with debate that is being argued in full force here. If you want to rails, knock yourself out. If you want to JS, woo! JS!. I care a lot about seeing your potential employer as an antagonist. They have just indicated to you that they like you enough to invite you to join them. Negotiate, sure, but assume good faith. And the very idea that they were waiting for a better candidate who didn't show up undervalues you. YOU were the one that impressed them most. How well you code was only a part of their choice. They liked your personality best, too, and your honesty, and your dedication, and that indefinable other thing that's hard to quantify.
They are likely the good guys, and they see you the same way. Now go ask for a better salary, or more vacation, but don't assume the worst.
Apparently Viking Code School has both Ruby and JS separate tracks (I may be misremembering, though)
Erik the original creator of The Odin Project, has moved on to focus on Viking. But theres a bunch of us working on improving the project.
Teach beginners backend JavaScript with Node.js. It's not a matter of personal preference, JavaScript is objectively easier for beginners to learn and utilise for backend programming because arbitrarily introducing another language when they already know front-end JS increases cognitive load for no benefit.
There's also this Java/Typescript curriculum https://www.edx.org/micromasters/software-development