Hi Railsbridge! After teaching at the workshop on 1/19 and talking with @blakeeb, @clarkcutler, and @vhmartini I have a couple of changes I'd like to make to the curriculum.

We some work in progress at https://github.com/carbonfive/docs/tree/frontend_curriculum_cleanup which will certainly turn into a pull request shortly. However I'd love to run these ideas past the community while I work to polish up changes to the content.

Goals:

Javascript

Split out all of the javascript steps into an optional group. We certainly have students who want to focus on this area and some advanced classes may get there but I think it should be supplemental to the core curriculum.

Purpose and direction

Construct a consistent narrative about the page/site we are building throughout the HTML and CSS steps. Students seemed to be excited about building something "real" and the possibility of publishing it at the end of the course. However some of the examples do not obviously serve a goal of building a useful site and are hard to apply in context.

I suggest a overall goal of building a "personal site". The existing "resume" example works well but I worry about 1. students being hesitant to publish the results and 2. it not naturally leading to a multi-page site which is something I want to cover.
As an example I've been using building a page of notes about Railsbridge rather than "hello world" or a resume.

Git

Remove any dependency on git and the command line for now. I'd like to make deploying with git an optional side track for follow up which teachers can included as appropriate based on the class. It would be great to have this as a core part of the class but I think adding the command line is a lot of overhead and hard to relate to the rest of the lesson.

Tutorials vs challenges

For examples which do not fit well into the above narrative let's break them out into small self contained pages which are clearly spikes into specific problem or practices. I really like the idea of "challenges" we currently see in http://curriculum.railsbridge.org/frontend/make_columns

In my class students were confused about adding such experiments to their work in progress earlier in the course and without good versioning practices established yet worried about losing work along the way as we played with different ideas in the same page. I'd like to alternate between isolated tutorials and more flexible challenges throughout the course. With challenges as optional elements of each step which can all relate to a common narrative and more open ended challenges toward the end of the curriculum for classes which make good progress.

Proposed flow

Core curriculum (more tutorials than challenges)

1. Frontend (intro)
   • Get A Sticker
   • Tool Installation
     • Mac Os Git Installation
2. Introduction To Html (displaying plain text)

• Deploying To Github Pages (optional but if we support deploying let's encourage it after each step)

3. Html Tags (adding em)
4. Html Structure
5. Basic Css (tag selectors and simple styles)
6. Html Attributes (classes and ids)
7. Working with Multiple Pages (links between pages, shared CSS)
8. Css Selectors (spike on specificity)
9. Dev Tools

Challenges (less structure, more freeform application to a student's site)

1. Add More Elements (images, types of anchors)
2. Make Columns

Javascript

• Basic Javascript
• Jquery
• Jquery Vs Javascript

RailsBridge Boston wants to start merging our curriculum fork back to this source! But we still want to be able to embed the RailsBridge curriculum materials in our own website, using our own navigation, theming, and progress tracking feature, like we do here: http://www.railsbridgeboston.org/curriculum/curriculum_toc

We are thinking about how best to do this. railsbridge-boston/railsbridge-boston#66

The best idea I can come up with is to gemify railsbridge/docs so that it can be dropped into a Rails app Gemfile and embedded into the app.

At the least this would mean adding a gemspec file to railsbridge/docs and pulling enough of the code into the new gem to expose the curriculum content and markup generation functionality in the current codebase.

As for the Sinatra app server InstallFest < Sinatra::Application, it could stay where it is. But using it to present the material would become optional. This would free up the railsbridge/docs content from being locked into one application architecture and user interface. It would also make moot the seeming incongruity of having RAILSbridge curriculum content served up by a Sinatra app (#196). We would be improving the separation of content from presentation, consistent with the tenets of 100 schools of software thought.

Please let me know if this sounds OK. I think taking this path will improve the versatility and reusability of the curriculum content and increase innovation in the tooling around it over the long run.

The installfest is mostly static, Heroku's built in Varnish would probably do wonders for it if set up.

I will do this.

What it says on the tin, step files have a #next_step method but analogous method for previous steps. I propose to add one.

In the intermediate curriculum the pages have a header, such as "Install Devise" then they go to "Requirements to advance", "Discussion Items", "Tools and References", and "Hints". I would like to change this so that the page first lists a Goal, such as "Allow a user to create an account and log into your message board. Use the Devise gem to do this.", from there list the "Requirements to advance" as though they were acceptance criteria for the task. Next list "Tools and References" and "Hints". Lastly list "Discussion Items".

I think this makes a bit more sense. I can do this on my own if no one disagrees.

making this a formal issue so that someone remembers to do it someday

Step 3 is titled "Install Homebrew", but talks about verifying you have git installed. Should we have everyone install homebrew so they can install git in step 4?

Also, Step 3 says if you already have git, skip to step 5 (Install RVM). Doing so causes students to miss a sub step of Step 4 (Install Git), that is "Configure Git".

I'm willing to make these changes, just wanted to get input on whether they make sense.

This past weekend, one of the classes started with the Ruby for Beginners slide deck, and probably would never have gotten to Rails if they hadn't been tipped off to the fact that the deck was going to keep going for a while.

(Obviously having a 2-hour Ruby deck would be a good thing, too.)

The big curricula are assumed, I think, to last a whole day, but the lengths of the slide decks in the workshops section are mysteries:
http://docs.railsbridge.org/workshop/

It'd be great to add approximate times to those decks (2-3 hours, 6 hours, etc.)

I would like to create a cheat sheet that pulls the commands from the beginner curriculum so that people trying to create their own projects, or do the advanced curriculum, don't have to search around in the beginner curriculum to find the commands that they need. I would love it if someone wanted to pair with me on this! I have a flexible schedule and live in San Francisco.

Sidebar links are broken all over the place:

http://docs.railsbridge.org/docs/

http://docs.railsbridge.org/workshop/

I go here http://installfest.railsbridge.org/frontend/
i click the [src] link in the upper right which takes me http://installfest.railsbridge.org/frontend/frontend/src
which is an invalid link.

Continuing from my "buried lede" in #247 the past three installfests that I participated in, which I regret to say were all last Spring, I noticed at least a handful of students on Mac OS X who were following the Installfest instructions independently and successfully installed Rails via RailsInstaller proceeded by then following the Mac OS X Lion steps.

When talking to each of them the reason they continued was that they saw Mac OS X Lion in the table of contents and thought:

When @alexch and I originally talked about the table of contents, the hope was that it would provide an anchor that made orienting both students and mentors as they went through the curriculum. I'm not entirely certain that it accomplishes that goal, but I've seen it actively do the opposite on multiple occasions in the installfest and I think we should turn it off.

Using Ruby 1.8.7 per the Snow Leopard/Homebrew page, gem list differs:

[~/railsbridge] diff expected.txt actual.txt
1,25c1,51
< actionmailer (2.3.5)
< actionpack (2.3.5)
< activerecord (2.3.5)
< activeresource (2.3.5)
< activesupport (2.3.5)
< builder (2.1.2)
< configuration (1.1.0)
< cucumber (0.6.2)
< cucumber-rails (0.2.4)
< diff-lcs (1.1.2)
< heroku (1.8.0)
< json (1.2.0)
< launchy (0.3.5)
< nokogiri (1.4.1)
< polyglot (0.3.0)
< rack (1.1.0)
< rails (2.3.5)
< rake (0.8.7)
< rest-client (1.3.1)
< rspec (1.3.0)
< rspec-rails (1.3.2)
< sqlite3-ruby (1.2.5)
< term-ansicolor (1.0.4)
< treetop (1.4.3)
< webrat (0.7.0)
---
> actionpack (3.1.1)
> activemodel (3.1.1)
> activesupport (3.1.1)
> addressable (2.2.6)
> builder (3.0.0)
> bundler (1.0.18)
> capybara (1.1.1)
> childprocess (0.2.2)
> coderay (0.9.8)
> cucumber (1.1.0)
> cucumber-rails (1.1.1)
> database_cleaner (0.6.7)
> diff-lcs (1.1.3)
> erubis (2.7.0)
> ffi (1.0.9)
> gherkin (2.5.3)
> heroku (2.9.0)
> hike (1.2.1)
> i18n (0.6.0)
> json (1.6.1)
> json_pure (1.6.1)
> launchy (2.0.5)
> method_source (0.6.5)
> mime-types (1.16)
> multi_json (1.0.3)
> nokogiri (1.5.0)
> rack (1.3.5)
> rack-cache (1.1)
> rack-mount (0.8.3)
> rack-ssl (1.3.2)
> rack-test (0.6.1)
> railties (3.1.1)
> rake (0.9.2)
> rdoc (3.11)
> rest-client (1.6.7)
> rspec (2.7.0)
> rspec-core (2.7.0)
> rspec-expectations (2.7.0)
> rspec-mocks (2.7.0)
> rspec-rails (2.7.0)
> ruby_parser (2.3.0)
> rubyzip (0.9.4)
> selenium-webdriver (2.8.0)
> sexp_processor (3.0.6)
> slop (2.1.0)
> sprockets (2.0.3)
> term-ansicolor (1.0.7)
> thor (0.14.6)
> tilt (1.3.3)
> webrat (0.7.3)
> xpath (0.1.4)

While following the osx_lion install directions, it tells you to install the heroku gem (Step 8).

This results in a deprecation warning:

 !    The `heroku` gem has been deprecated and replaced with the Heroku Toolbelt.
 !    Download and install from: https://toolbelt.heroku.com
 !    For API access, see: https://github.com/heroku/heroku.rb

Proposed new page for getting heroku up and running:

1. Visit https://toolbelt.heroku.com/
2. Download the toolbelt for your OS
3. Install it (double click .pkg file, click continue, continue, etc)
4. Verify install worked (run 'heroku version' and see 2.33.1)
5. Login with your heroku credentials (heroku login)
   5a) Enter your heroku email address
   5b) Enter your heroku password
   5c) Verify you see "Authentication successful."
   Return to "Verify successful installation" page

Additional updates for installfest/osx_lion would be to update the path for the output of the command which heroku.

Right now the docs page gives precious little context to what they are about. If you're a savvy link-clicker, you can figure it out a few steps away. But maybe the docs themselves would be a good place to explain:

• what this is
• how it gets maintained
• links to other relevant things, like, railsbridge.org

While installing a windows machine, the antivirus of one student showed that the ansi153.zip file has malware.

Please verify, I don't use windows. I did download the file and scanned it on a online scanner tool. Here is the result:
https://www.virustotal.com/en/file/62e9f6fa2d808dc400c8a1b77a96e7d20b5640e8ca3c4b8ea8dc0566485e17bc/analysis/1362801198/

And I also filed the bug on the adoxa, but in the meanwhile we might recommend something different than adoxa's.

adoxa/ansicon#48

When a user is on a page and they view instructions with a browser that is taking up half the screen the left margin pushes content right so that commands are cut off. I observed this while pairing with a learner on her Windows machine, I'm not sure what the resolution was where it became difficult, but ideally we should have readable tutorials even if the browser is only 400-800px wide.

test

make a Railsbridge Gem Server so we're more immune from network outages

@alexch looks like an unlisted dependency of Erector is causing build failure on Travis. Any chance of that being fixed?

note that beginners are not at the needed place by the end of their first workshop, and definitely not when they enter the installfest, to effectively engage in the current edit cycle, so a separate channel is needed for critical noob feedback, since they are a key part of the point of the workshops; we currently have an unknown rate of silent fails, because a student has to succeed at a non-trivial level just to be able to point out a problem or suggest an improvement

one option would be a simple pop-up form, that knew where it was clicked from (so we have the context for the feedback), or an e-mail form (but that will eliminate some users by itself)

a simpler option might be a voting or tagging system that would let a noob click a [+/?/-] next to any section or para to let us know that it worked, it was confusing, or they got stopped there; at least it would tell us where to look, or what may need work

The spec test in spec/step_spec.rb has two problems.

1. It is currently failing on master.
2. It only tests the step method.

In order to work on #10, I'd also like to fully flesh out the step spec. This will should also allow anyone who wishes to further extend stepfiles to do so with more confidence.

on installfest/osx_lion, under "Verify successful installation", if they installed git with homebrew, the path should be /usr/local/bin/git. Is there a way to multiple result lines for a given console line?

i.e.:

verify "successful installation" do
  console "which git"
  result "/usr/bin/git"
  result "/usr/local/bin/git"

[...]

Then the result markup could say something like "/usr/bin/git or /usr/local/bin/git

A good friend of mine whipped together http://replpad.com/ over the weekend, and introduced me to the jsrepl project.

I'm going to spike on implementing jsrepl in a few of the exercises to see what happens - could be a great way to get people into IRB pre-installfest! (more at the "Get Excited About Programming!" phase of learning)

https://github.com/replit/jsrepl

Thoughts?

Here's a rough outline that we came up with:

Intro

• Demo of a game to play
• This is not java, but the syntax sucks like it is
• What is the relationship between HTML and javascript?
• Clone a repo with HTML and CSS with some boxes with back of the cards
• Manipulate the HTML and CSS as a review of those topics
  • Change cards colors

Primitive types

• Developer tools: Learn to use the console
• Introduce strings, numbers, booleans, variables, comments
• Use strings, numbers, booleans, variables and comments in our game in someway
  • maxNumberOfCards = 16
  • playerName = "my name"
  • gameOver = false
  • etc
• reload our page

Data Structures

• Introduction to Arrays
• Play with arrays in the console, learn to push, pop, iterate, and randomize?
• Create an array of 8 colors
• Assign each color to two cards
• Introduce Hash: key: value pair concept, actually called an object in javascript
• Terminology sidenote: Hash, Objects and OOP Objects
• Create an object of self's position: pair's position
• Looking things up by key to get the value

Control Flow

• In console, look at various return values and see what's truthy and falsey
• Basic function intro:
  • Introduce conditionals by creating a function: onclick checks what the target is and look it up in our hash, and just return the match number
• Conditionals and Loops (and Switch statements?)
• == or ===
• Optional: Try/Catches - Add as bonus step or at the end

Functions and Scope

• Functions
• Closures
• Callbacks - goto for the modern era
• Functions create scope
• Optional: what is 'this'?

Optional Advanced Topics

• Object Orientation - Inheritance, Prototypal Inheritance is different, yo!
• new operator
• error handling

Has anybody installed Mavericks and tried the Installfest instructions? Doesn't look like RailsInstaller supports it yet, so maybe that's gonna be a party.

Right now the "[toc]" link opens a list of the files in the current directory. This has long been a pain point for students as they are trying to follow the thread of the installfest and curriculum.

I've been discussing how we can do this a number of people and think it will prove to be a pretty straightforward graph traversal problem.

The curriculum is about learning rails, but the docs site is built using sinatra. This makes it more difficult for students to be able to contribute to the documentation. Rails is not be the best technical fit for this type of site, but it may be the right choice for encouraging participation.

I am happy to do the work if others agree that this is a good idea.

So, this happened and there is now a 171MB download that includes everything (including proprietary headers) for Mac users to build Ruby and Homebrew.

This is awesome and wonderful news! I have time budgeted to hack on the app tonight around 8:30PM PST. I'd love to work via IRC or Skype with someone on replacing the Mac OS instructions with this perfect middle ground between XCode and OSX-gcc.

If I don't get any takers I'll be submitting a pull request all the same.

So Erik P. made this cool development glossary:
https://github.com/railsbridge/docs/wiki/Development-Glossary

Maybe we should put it in the curriculum somewhere? Perhaps under the "Other Pages" section?

I think the "Other Pages" section could also include a command line cheat sheet and other side-trip materials (how your computer works?).

Do y'all think that is a good idea? Do you think this stuff should live somewhere else? I think the wiki is too far removed from the curriculum to actually be used doing the workshop.

Source: http://community.activestate.com/faq/komodo-command-line

Should we add a step to the installfest/install_komodo_edit_for_mac to add an alias for komodo?

1. echo alias komodo=\'open -a \"Komodo Edit\" \$ARGV*\' >> ~/.bash_profile

It looks like RailsInstaller (for Windows) didn't generate rdocs, but the step at /tools simply suggested rvm docs generate, which is of course not that helpful for Windows user.

We have fun subdomains for some of the docs pages, but not for all of them, and I think it causes more confusion at this point for folks to go straight to installfest.railsbridge.org or curriculum.railsbridge.org. Yesterday at Tapjoy there were posters all over the place pointing people to: curriculum.railsbridge.org/installfest, which does work, but isn't really helpful or shorter or good, really.

I can see an argument for installfest.railsbridge.org remaining, but not so much for the curricula, since there are so many of them.

In the Intermediate Curriculum it immediately jumps into having students manually create controllers, views, and routes. It doesn't explain how to do this, and the beginner curriculum does all of this with generate scaffold. If someone has the results of the beginner curriculum laying around then they can use that as a reference, but it doesn't actually explain the minimum of what needs to be done, and why you do each of those things. I think that explaining this is more detail will be educational, rather than making things too easy.

I have already written up a page for this, I just want to make sure it is okay with everyone before adding it.

make installfest.railsbridge.org work, instead of installfest.heroku.com

[ Boston guy here... As I've been reviewing the curriculum, I've come up with some questions. I figure they can't hurt. Feel free to brush 'em off if they've already been covered before. ]

I don't understand why the Macintosh Installfest page goes to the trouble of mapping numeric version (e.g. 10.7) to big cat names (e.g. Lion). This sets up an abstraction (names instead of numbers) that's used only once – and by people that probably don't know the cat names anyway.

The cat names read nicer than numbers, but it seems simpler to just label things with the version number found in "About This Mac".

Possible names:
Beginner
More Rails
Continuing Rails
Rails: Act II

There is a big jump between the "Intro to Rails" curriculum and the Intermediate Curriculum. The simplest thing might be to just name them Rails 1, Rails 2, Rails 3, etc. I'd like to work on a curriculum between the two that we already have. If you have objections please reply to this thread.

There's been continuing discussion on the railsbridge-workshops mailing list about branching the workshops. One topic that I've always wanted to have more literature on is the Ruby language itself. We should have a curriculum that is roughly as long as the Rails app curriculum and ends with "deploying" to GitHub.

Other things that fall under the purvey of this module.

• A Ruby for Rails survival card. (i.e. [1, "mittens", :deleted] is an Array. Arrays are lists. Their size is not fixed, they can grow and shrink. You would use an array to store any many kinds of sequential data.) which covers basic data types and objects, use cases, and how to do things like iteration and conditionals.
• Running Ruby applications from the Terminal
• Writing Rake tasks. Wanna demystify rake? Teach people what it's for and about topographically sorted dependencies (okay maybe not about that BUT IT IS SO COOL)
• How to help yourself using tools like rdoc, gem server, Stack Overflow, and ri. (as discussed in #75)
• Testing with Minitest. Because there's less magic in command line Ruby scripts, it will be far more feasible to introduce basic unit testing. Coupled with a lot more irb it should really help with learning via hypothesis.

Lastly, we should work as hard as we can not to reinvent the wheel. Ideally this curriculum would be much more a curation of existing community resources such as @alexch's Ruby stuff, Try Ruby, _w(P)GtR, the Ruby Koans, and the like. There's good stuff out there, we just need to filter it and present it.

I would like to start with a Ruby Survival Card for Railsbridge attendees.

'rake' (aka 'rake spec') was failing under Windows. I think it works now as of ( 52bf4b1 )

Am running OSX 10.7.3 and Xcode 4.3, but got lots of red on the "rvm install 1.9.3" step.

Traced the problem to a borked install of gcc. I tried symlinking to /usr/bin/gcc but no dice.

Installed gcc again from this (900mb DL) https://github.com/kennethreitz/osx-gcc-installer#readme

and hooray! she works

In the reference section we will include links to the Quick Reference of commands, Any other informational pages we want to pull out, and to external references where people can learn more. I can do this if no one protests.

Hello RailsBridge-a-deers,

Any 👍 / 👎 on making the nav uniform across the Docs site and the main RailsBridge site?

Pros:

• Easier for students to get to "more learning resources page" -- it's right there!
• Probably prettier

Cons:

• No dynamic curriculum title in the Nav bar
• Duplicate code == sadness
• Probably would want to update some of the other style, too, for a less jarring transition, which is work

in order to participate effectively in the edit cycle for the installfest or curriculum docs, you need (at a minimum):

• a github account, logged in, and the git client on your machine
• basic editor skills
• basic markdown, step, and (possibly) slide syntax
• (missing) guidelines for how to name, comment, and submit pull reqs

the "preview" links only show the git-diff on the source code changes; if you want to actually see what your changes would look like, you have to bundle install the forked repo, which is more advanced than the installfest, and doesn't work on windows at all

given that we are now developing multiple variants and deep-dives, I propose that we now provide a clear entry point and how-to for providing feedback and offering edits, that at a minimum covers the bullets in the first para, and includes the option of doing the stuff implied by the second para

note that Godfrey has provided nearly all of the component instructions and guidelines, but what is missing is the cover page that organizes and points to them, and then making sure that we link to that in all the right places

Hi all,

Tiffany from LA Railsbridge mentioned that there were some confusion among the students about the inconsistent use of hash rocket (i.e. {:a => 123, :b => "hello"}) vs 1.9 syntax (i.e. {a: 123, b: "hello"}). I can probably send a PR to unify them, but I want to get some feedback on which of these two options do people prefer:

1. Use hash rocket everywhere, maybe add a note about the 1.9 syntax ( Pros: consistent, easy to understand )
2. Use 1.9 syntax whenever possible ( Pros: this seems to be where the Ruby community is heading, and tutorials and code they read elsewhere will probably be using this style )

Godfrey

In the installfest directory, all or most console blocks include a leading $. In the curriculum directory, they do not. We should pick one and standardize. The natural choice in my opinion is to remove the $ since the console declaration creates a "Type this in terminal" message before any output.

While most of us know to strip the $ when actually typing, it's not something that can be reasonable expected of someone totally new to the terminal and doesn't make any sense for Windows users, who are using Command Prompt with Ruby on Rails and not git bash.

The only argument in the $'s favor to my mind is that it is a distinguishing mark between things meant to be entered into the command shell versus those meant for irb. So perhaps a corollary issue to this one is that we need to add an optional key to the console command similar to the source_code directive's method of distinguishing between languages.

it was supposed to be a pull request

...and now it will live here forever?

Thinking about ripping all mentions of MVC out of Suggestotron and replacing with an explanation of the request cycle that starts with the router. I think that MVC is nice shorthand for people talking about that particular architecture pattern, and super duper confusing for new folks — even just the order, "Model, View, Controller", is confusing.

Opinions?

There were 3 people at the last meetup who had a developer's aging laptop. My fiance inherited mine from 3 years ago. She had macports and an old version of Xcode. Having a step that's like "Run this command. If it doesn't error, call someone over" where the command detects if these things are installed.