Tag: railsgirls

Been a while, hasn’t it? Anyway, I’ve finally had a bit of time now to sit down and revisit the tutorial.

The next steps in the tutorial (the link is here if you’re interested) are regarding adding picture/file uploads to the server (so, section 4). This bit started off pretty simple. I did hit that one error they warn you about, where the uploader cannot be found and you need to add another gem, but that only added a step that was basically identical to the one before it, so it was fine.

The only major snag I hit was in the step which has you add the code showing the picture (rather than just its filepath).

They ask you to change

<%= idea.picture %>

to

<%= image_tag idea.picture_url, width: '100%' if idea.picture.present? %>

Which for some reason generated astronomical amounts of errors. The reason is probably that I did a lot of things wrong. The first error was caused by referring to a local variable as an instance variable (Ruby differentiates these by starting instance variables with an @), but I tried to fix that by using some of the formatting from a different edit RailsGirls had me make, assuming that they had just messed up their second instruction.

<%= image_tag(@idea.picture_url, width: 600) if @idea.picture.present? %>

Doing this did not actually fix the problem. It made it worse.

I decided to debug by adding this as an extra list item, rather than replacing a list item already present, so that I could narrow down where the issue might be coming from. Naturally, I messed up the HTML tags immediately and caused a new issue.

But! I found that problem almost right away, got that cleared up, double checked why/how the parentheses might be working or not working, realized that the @ symbol shouldn’t be there, removed that and the parentheses, and everything started working again.

Verdict: I need to review Ruby syntax.

The static pages and routes finetuning were very easy, and I didn’t run into any issues there, which means that I finished that section of the tutorial today! The next section is about pushing your work to GitHub, but I don’t think I’ll do that right away; I want to do a bit of monkeying around with HTML, CSS and Javascript before I push anything.

Onward!

It took me a little while to come back to this, as I was never really able to properly figure out what was going wrong with Yarn. Eventually I decided that, since I also have an Ubuntu terminal and Linux running on my machine, I’d get set up over there instead, which let me bypass a lot of the issues I was running into with SQLite3 and Yarn.

So, onto the next section: Building Your First App.

Setting Up

The first steps were to make a directory to store a Rails app in (pretty easy), per their instructions, and then use Rails’ scaffolding setup to generate some ideas.

This was where I ran into my first hurdle (well, with the design of the tutorial itself — I’m not counting all the technical hoops of the first day): this tutorial is designed to augment a public workshop. What this means is that there are sections that essentially say “Here we’re going to learn about scaffolding. Run this command, and then the coach will tell you what scaffolding is.”

And then there’s no explanation of scaffolding.

Which — not the end of the world. Google is free. But it does mean at least a few minutes get expended on sorting through the first couple of results, figuring out which ones are documentation, which are explanations and which are ads, and trying to parse these as quickly as possible without having to do a whole ‘nother tutorial to try and figure them out.

(For the record, scaffolding is essentially running a command that will quickly write up the basic Model-View-Controller framework of your app for you, which you can then build on. It does exactly what a scaffold should.)

Working with the Scaffold

So the first thing, setting up the scaffold, looks a little like this:

rails generate scaffold idea name:string description:text picture:string

Guess what was not explained in this tutorial. If you guessed “any of those arguments”, you guessed correctly. I ended up finding the answer in one of the Ruby on Rails Getting Started guides, section 6.1. The quick answer is that this forms a table for storing “ideas” where each idea has three attributes (ideas are rows, attributes are columns). The arguments are the name of each attribute, and its datatype. Simple enough concept, and again something that would probably have come across better in a live workshop.

[a brief intermission while I check if Rails Girls has recorded any workshops]

[none that I can find]

[intermission over, we proceed]

After setting up the scaffold, updating the database, and running the server, I opened the site and found an empty table with a “New Ideas” button. The button opened a field looking like this:

Hey, presto! A couple of ideas later, and the table is beginning to look a little fuller.

And yes, I tested “Show”, “Edit” and “Destroy”. They do about what you’d expect.

Design

The next section (again headed off by “The coach will explain this part”) talks about the ‘View’ part of a MVC model, and which part of a view is HTML versus which part is Embedded Ruby (ERB). It doesn’t really explain how the two connect up, nor which part of a view is made of which. I have some familiarity with MVC from my computer science classes, if I didn’t, this would probably be another place where Pilot Stops to Google.

Went through the design bit; it was semi-easy, semi-interesting. When I’m working in HTML I’m always aware that there’s lots I don’t know, but it all follows so easily from what I do know that it feels like it goes almost too smoothly. I did learn about how ERB works in this context:

<% %>
<=% %> 

and presumably some other similar related ones are the tags one uses to embed Ruby into the page. I found that one out on StackExchange, where I was also assured that Haml is a far superior alternative for embedding Ruby into web pages.

Saved the code; ran the code.

I got surprised when saving the code and visiting the main page (localhost:3000) didn’t do anything, though – the styling only appeared on the page for the Ideas app (localhost:3000/ideas). I don’t know why that is yet. Right now my guess is something to do with the idea that there’s only dummy content on the main page, and the scaffold generated is just for the /ideas page. To be investigated.

Well, day 1.5? Day 2? The point is, I did a (very little) bit of the setup yesterday, but ran into a roadblock that I couldn’t resolve until now.

I’ve been working for a while on how to learn/run Ruby, and for now I’m settled on following some of the Rails Girls guides for creating web apps. Rails Girls is an organization that runs events teaching girls how to code in Ruby on Rails, but they also have tutorials online here.

So far, this has been an exercise in Googling a lot of stuff to see whether my computer will run things compatibly. The biggest two hurdles have been SQLite3 and Yarn (out of Ruby, Git, Node.js, SQLite3 and Yarn).

For the former, the issue has been determining whether they have a toolkit for 64-bit computers (they don’t), whether they have SQLite3 itself for 64-bit computers (they do), whether I can run the 32-bit toolkit on my computer (I can), and whether I can mix the 32-bit toolkit with the 64-bit version (I decided not to bother, since I can run the 32-bit version as well).

For the latter, it’s been trying to figure out why I could successfully install/update Yarn over and over again using Node.js, which was determined to be running, but not actually use any of Yarn’s commands (apparently you have to restart your computer. No one told me).

Update from several hours later: restarting did not fix it. I think I’ll need to add the folder to my PATH in order to be able to use the commands. Will investigate tomorrow & hopefully be able to write up a little more about what is happening.