Programowanie w Ruby od podstaw - kurs wideo PL

A to akurat jest całkiem niegłupie ponieważ prostsze i wymagające mniej teorii niż .each, patrz też:

http://learncodethehardway.org/blog/AUG_19_2012.html

To tak jak z niepisaniem testów i dokumentacji: możesz sobie robić cokolwiek jeśli jesteś pewien że do końca życia projektu pozostaniesz jedyną osobą z tym kodem pracującą.

z batsavo akurat chodziło mi o konwencje, bo autor tematu napisał, że takowej w Rubym nie ma.

No nie no… Wymaganie znajomości multiple-inheritance, Message passing and dispatch, Blocks passed to function calls itd do użycia #each to tak, jakbyś od osoby uczącej się Railsów oczekiwał znajomości tego, co siedzi pod ActiveRecord::Relation, albo ActiveRecord::QueryMethods::WhereChain.

Możesz redukować do absurdu ile tylko chcesz (i używając fałszywej analogii). Ale musisz przyznać że trzeba te kwestie omówić chociaż z grubsza żeby wyjaśnić, skąd się bierze .each i dlaczego działa tak jak działa.

Ale przecież w tym kursie zaraz po tym jest #each bez (prawdopodobnie, bo nie kupiłem) wyjaśnienia 90% punktów, które podane są we wpisie z Twojego linku.

irb(main):014:0>[quote=“radarek, post:18, topic:7452”]
Tworzenie plików

(o wstawianie spacji po między nazwę metody a “()” )
Dlaczego nie może? Nie jest oczywiście to dobrą praktyką, ale nie potrafię odtworzyć sytuacji, że “nie zadziała”.

[/quote]

irb(main):012:0> plik=File.new(“test.txt”, “r”)
=> #<File:test.txt>

irb(main):013:0> plik=File.new (“test.txt”,“r”)
SyntaxError: (irb):13: syntax error, unexpected ‘,’, expecting ‘)’
plik=File.new (“test.txt”,“r”)
^
(irb):13: syntax error, unexpected ‘)’, expecting end-of-input
from C:/Ruby200-x64/bin/irb:12:in `’

Ja testowałem z

plik=File.new ("test.txt")

i to działa. Ale faktycznie dla 2 parametrów już nie.

Bo parser to potraktowal jakbys mu przekazal argumenty bez nawiasow gdzie argumentem jest jakies expression w nawiasie :smiley:

Faktycznie. Z tym, że zdziwiony jestem trochę bo wydawało mi się, że ruby w przypadku foo ("bar") zarzuci jakimś warningiem ale tak nie robi (miałem wrażenie, że dawniej tak właśnie było).

Podsumowując:

  • przykłady sprawdzaliśmy wielokrotnie,
  • nawet Kolega się czegoś nauczył przy okazji publikacji naszego kursu :smile:

Z tym że reszta zarzutów @radarek jest zasadna.

Zupełnie mnie ten argument nie przekonuje. Codziennie uczę się nowych rzeczy, zarówno od bardziej jak i mniej doświadczonych programistów. Zresztą chyba najwięcej uczę się na swoich i cudzych błędach ;-).

Tak z ciekawości. Czy przed nakręceniem tego kursu była przygotowana transkrypcja, którą ktoś sprawdził pod kątem merytorycznym, czy też osoba nagrywająca szła na żywioł? Mam wrażenie, że nikt nie sprawdzał części merytorycznej materiału i teraz macie problem bo raczej nie wierzę, że nagracie ponownie materiał uwzględniając nasze uwagi (a jak widać wyżej ja miałem ich kilka po oglądnięciu 3 krótkich części).

Ja proponuję, by Kolega napierw przetestował, a później pisał, jedna uwaga była już nie trafiona a teraz kolejna:

irb(main):001:0> puts “tomek”.Upcase
NoMethodError: undefined method Upcase' for "tomek":String from (irb):1 from C:/Ruby200-x64/bin/irb:12:in
irb(main):002:0> puts “tomek”.upcase
TOMEK
=> nil

Na który zarzut to ma być odpowiedź? Na ten, że nazwy metod mogą się również zaczynać od wielkich liter? Bo jeśli tak, to to jest epic fail - to, że metoda String.Upcase nie istnieje nie znaczy, że nie można definiować metod zaczynających się od wielkiej litery.

1 Like

Rozmawiamy o metodzie .upcase, czy definiowanej metodzie .Metoda?
Jeszcze chwila i dowiem się, że Zmienna to zmienna? :smile:

Dlatego właśnie pytałem, na który zarzut to miała być odpowiedź. Więc na który?

Panie Tomaszu, proszę nie zmuszać mnie do oglądnięcia filmu jeszcze raz ;-).
W filmie pt. “Definiowanie i wywoływanie metod” w 1m25s pada stwierdzenie “(…) naszej metodzie musimy nadać jakąś nazwę. Ważna rzecz - nazwa musi być napisana z małej litery”.

I tak jak napisałem - otóż nie musi.

[4] pry(main)> def Foo; puts "foo"; end
=> :Foo
[5] pry(main)> Foo()
foo
=> nil
3 Likes

@radarek Akurat w tym przykładzie nie zgodzę się z Tobą. To, że można zdefiniować metodę z dużej litery nie znaczy, że należy o tym głośno mówić. Wiem, że poprawniej byłoby stwierdzić ‘nazwa powinna być napisana z małej litery’, ale początkujący i tak mają mnóstwo rzeczy do zrozumienia i zapamiętania, tak więc nie sądzę, żeby to robiło dużą różnicę.

To tak, jak na matematyce jest tłuczone przez kilka lat, że nie istnieje pierwiastek z -1, a potem na pierwszych zajęciach na studiach człowiek się dowiaduje, że był okłamywany całe życie. Na początku nie musisz znać liczb zespolonych, żeby radzić sobie dobrze z matematyką.

1 Like

Widzisz, zahaczasz o bardzo fajny temat. Co powinno a czego nie powinno się mówić osobie, którą wprowadzamy w jakiś temat. Otóż w tym wypadku, moim zdaniem, lepiej byłoby nie poruszać tego tematu i tyle (zakładam, że autor gdzieś wcześniej wyjaśnia słuchaczowi, że ruby ‘zwraca’ uwagę na małe i duże litery wiec przepisując kod z tutoriala powinno się zachować dokładnie taką samą formę).

[quote]
To, że można zdefiniować metodę z dużej litery nie znaczy, że należy o tym głośno mówić.
[/quote

Otóż to. Wystarczy głośno o tym nie mówić.
Natomiast tutaj pada po prostu nieprawdziwe stwierdzenie i uczona osoba jest wprowadzona w błąd.

1 Like