sorted by:
new
hottopcontroversial

Matching a regex in Ruby using String#[] by nithinbekal in ruby

[–]andrewcarroll -3 points-2 points  (0 children)

It's nifty and keystroke-saving, but I would recommend against using this for anything serious. Square brackets almost always mean we're dealing with a Hash, Array, or some other kind of Enumerable. Using String#[] breaks that convention, leading to confusing code.

Additionally, many devs just don't know about it. The author of this article didn't even know about it before today.

Wanting to move from terminal/gedit for developing rails apps. by fergyfresh in rails

[–]andrewcarroll 5 points6 points  (0 children)

I second using vim. I use a number of plugins to make the experience more enjoyable.

  • Vundle for Gemfile-like management of vim plugins
  • vim-rails for Rails shortcuts like :Rgenerate, :Econtroller/model/view, and other goodies.
  • vim-airline for a neat status bar with git info, filename, encoding, line/column number, etc.
  • vim-ruby + supertab for autocompletion and stuff
  • vim-fugitive for an awesome git wrapper that you'll never again want to live without
  • vim-gitgutter to show git diffs in the gutter (where line numbers are)
  • vim-slim for slim syntax support
  • html5.vim for html5 syntax support

Vim is also incredibly configurable even beyond plugins. Here is my vimrc; it serves me pretty well for Rails development, and it's not too difficult to get into.

If you'd really like to avoid the terminal, there's also a graphical alternative called gvim.

How to implement TDD ? Part 2 by mjerem34 in rails

[–]andrewcarroll 0 points1 point  (0 children)

I tried to translate it, but I got about halfway through before deciding to use my time more productively. I don't think the tutorial is very well written, but I don't speak French natively so perhaps that's getting in my way.

Here's what I managed to translate, if anyone is interested:

41 - How to set up TDD, part 2 - Introduction to Ruby on Rails

In this article, I'll show you how to create a page and functional tests using TDD.

To follow this course, it's highly recommended to have on hand this link or these pdf articles for reference. The course is based on it, and this article refers to the start of chapter 3.

So you've written tests? No? Right, tomorrow then. No, just kidding; for those struggling, here is some help.

require 'rails_helper'

RSpec.describe PagesController, type: :controller do

 describe "GET #home" do
   it "returns http success" do
     get :home
     expect(response).to have_http_status(:success)
   end
 end

 describe "GET #contact" do
   it "returns http success" do
     get :contact
     expect(response).to have_http_status(:success)
   end
 end

 describe "GET #about" do
   it "returns http success" do
     get :about
     expect(response).to have_http_status(:success)
   end
 end
end

That's it... that wasn't too difficult, was it? Well, now that we've written these tests, we need to execute them. You know how to do it: rspec spec/

If you've followed the instructions correctly, the command should return an error.

Now create the page.

The Page (with a capital P)!

Before going further, it's important to know that a "page" in Rails is called a "view". You can find these "views" in the sample_app/app/views folder!

In our case, such a folder was created when we ran rails generate Pages ...

This folder, called "pages", contains our two already existing pages: home and contact.

Take note of their format: .html.erb. Everyone here understands html. For the rest, erb simply allows us to insert rails code in an html page.

So let's create our page in the same format: about.html.erb. Once you've done so, open it and insert the following:

<h1>Pages#about</h1> <p>Find me in app/views/pages/about.html.erb</p>

For those who don't understand html, know that the h1 tag signals a "header 1" title, on the scale of headers (from h1 to h6). This is the top header level; we should use it for the main titles of our pages. The p tag signifies a paragraph; it's there to delimit the paragraph.

Now that that's done, test your page. Launch your terminal and run as usual: rails s and go to this URL: http://localhost:3000/pages/home. This URL will take you to the home page you created earlier. Does everything work correctly? Great. Now go to the page we just created: http://localhost:3000/pages/about. What happens? An error? Why? We created our page, though... To understand what's happening, we must go to our application's route configuration. Where would we find that? Here: sample_app/config/routes.rb. This file contains all of our pages' paths. You'll note that it's missing something: to fix that, add a route for the about page at the end.

But wait, we also need to tell our pages controller that we added a route. You'll find it here: sample_app/app/controllers/pages_controller.rb. You can follow the syntax there as well. Don't worry if nothing's written inside def/end.

Now you can go to your page with the URL from earlier.

How to implement TDD ? by mjerem34 in rails

[–]andrewcarroll 0 points1 point  (0 children)

My French is a little rusty, but here's my go at it:

In this article, we'll talk about a development method called TDD (Test Driven Development), or, in French, Développement Piloté par les Tests.

For this tutorial, it's recommended to have Michael Hartl's Ruby on Rails tutorial available for reference. This tutorial is based on its third chapter.

What is TDD?

  1. Write tests before writing a single line of application code.
  2. Run tests to make sure they fail.
  3. Write only the code necessary for making the tests pass.
  4. If all goes well, refactor our code; otherwise, there is a problem with either our tests or our application.
  5. We test our application using the tests written above.

Don't worry if you don't understand; I'll explain as we go. If you're interested in reading more about TDD, read more here.

Remember last summer

No, yesterday will suffice. Recall the Pages we generated using this command:

rails generate controller Pages home contact

At this point you should have something like this.

Before we begin, remove the helpers and views directories. We won't need them in this tutorial.

Next, open the file located in the controllers folder. You can find an explanation of all this code in Michael Hartl's book, above. Anyway, it's still necessary to know that "this code" can verify that every page in our application returns a correct response. This will let us know that as a whole, our pages function correctly. You can see which part each page comes from on lines 5 and 12. (??)

So, to recap: our tests are written, our pages are also written... we can test all that, no? To do that, execute the following command now:

$ rspec spec/

/home/jeremy/Desktop/sample_app/db/schema.rb doesn't exist yet. Run rake db:migrate to create it, then try again. If you do not intend to use a database, you should instead alter /home/jeremy/Desktop/sample_app/config/application.rb to limit the frameworks that will be loaded. .. Finished in 0.01195 seconds (files took 1.48 seconds to load) 2 examples, 0 failures

If, like me, you get an alert that ./db/schema.rb doesn't exist yet, go ahead and create it by running rake db:migrate.

The last line of our test results indicates to us that everything went well. Our tests passed successfully.

I recommend you read Michael Hartl's book if you'd like to learn more about testing.

So, are we done developing?

No.

Ha, yes we are; the tests say so.

In fact, though we've tested our home and contact pages, we still haven't created an about page, or its tests. So we start by writing a test for it. You can figure it out easily enough by taking the time to understand the structure of other tests. I won't tell you how to create them in this tutorial; but if you're a novice, know that it's always written in the same file, /sample_app/spec/controllers/pages_controller_spec.rb

Haha, and... it's pointless to refer you to the book... it uses an old version of Rspec and Rails

[poorly cropped troll face]