D
David Masover
There's dozens of HTML, CSS, and JavaScript guides out there, but a
good starting point to learn HTML, CSS and JavaScript is
w3schools.com.
Probably a good starting point.
Later on, though... For CSS, I seem to always end up on A List Apart when I
have a particularly hard problem. For JavaScript, you'd eventually want to
read Douglas Crockford's stuff:
http://javascript.crockford.com/
I agree that w3schools is a good place to start, though.
- CSS makes a site pretty.
More specifically, it makes a site look the way you want it to.
You don't really need to learn HTTP (fortunately): If you decide on a
web-based solution, your webserver will take care of that. At most,
deal with error codes, of which you need to know 3:
404: Site not found.
500: Internal Server Error (a catch all, meaning that something in
your webserver went wrong).
200: The client request could be processed.
Those 3 are important to troubleshoot an application.
I think the main concepts here are what HTTP is, what a status code is, what
HTTP headers are, and what an HTTP method is:
http://tomayko.com/writings/rest-to-my-wife
Once you have that, the details of how these things are actually implemented
may not matter much -- I have only rarely felt the need to speak HTTP directly
-- but it's good to at least have some idea of what it is:
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Also: Web servers, database servers, HTTP stuff etc. is more the
domain of a system administrator.
Probably. Hopefully. It may even be completely eliminated, depending on what
you deploy to:
http://appengine.google.com/
http://code.google.com/p/appengine-jruby/
Or of course, when you're just starting out developing Rails, the default
setup will give you a little SQLite database, and you can get by while knowing
very little.
But, for example, I never felt I really needed to know how to set up a
database server, but ORMs are the leakiest of abstractions. If I was building
something on top of a SQL database, I needed to know at least enough about SQL
to have an intuition of which operations will be fast and which will be slow,
how I should store my data based on what I need to do with it, and
occasionally there's no getting around writing a manual SQL query to optimize
something.
Well, you need two tools to develop Ruby applications: A texteditor,
and Ruby itself. Everything else is gravy.
I'd also cite Rubygems as a necessity, but yes, that's about it.
For web stuff, it helps to have a number of browsers installed, to see
if your markup code and JavaScript work as you think they should.
In particular, probably Google Chrome or Firefox with Firebug, at least. The
ability to right-click and "inspect element" is _very_ helpful for figuring
out what's actually going on with a page.
However, if you can find a web designer, they'll happily do that for
you, or grab a template for HTML and CSS off of a website, like
oswd.org or opensourcetemplates.org .
In my experience, web _designers_ have been terrible with JavaScript and only
tolerable with HTML and CSS.
Searching the web for "<my problem> Ruby library" usually helps, as
does taking a look at http://ruby-toolbox.com/
I also find a search on rubygems.org helps a lot.
While all of this seems like a lot, you can divide this with ease into
several steps:
- Learn Ruby and Rails (or another web framework, like Sinatra)
Learn Ruby first.
I would also argue that some amount of HTML and CSS should come before Rails,
for more or less the same reason that Ruby should come through Rails. I don't
agree with everything Joel says, but this part is important:
"The law of leaky abstractions means that whenever somebody comes up with a
wizzy new code-generation tool that is supposed to make us all ever-so-
efficient, you hear a lot of people saying "learn how to do it manually first,
then use the wizzy tool to save time." Code generation tools which pretend to
abstract out something, like all abstractions, leak, and the only way to deal
with the leaks competently is to learn about how the abstractions work and
what they are abstracting. So the abstractions save us time working, but they
don't save us time learning."
Especially that last part. Rails saves you time working, but I don't think it
should be used to save you time learning. Otherwise, when stuff breaks (and it
will), you'll have a _much_ harder time figuring out what's actually going on.