Създаване на хеш чрез map

Програмиране с Ruby

Курс във Факултета по Математика и Информатика към СУ

Решение на Седма задача - ретроспекция от Христина Тодорова

Обратно към всички решения

Към профила на Христина Тодорова

Резултати

  • 0 точки от тестове
  • 2 бонус точки
  • 2 точки общо
  • 0 успешни тест(а)
  • 1 неуспешни тест(а)

Код

REPOSITORY = 'https://github.com/hrist-todorova/ruby-retrospective-2016'
# Двадесет неща, които научих.
#
# 1. Можем да използваме оператора =|| за присвояване на стойност на променлива не само във вида x =|| а, но и във вида x = a || b като ако а е nil, то х приема стойността на b.
# 2. Ако имаме хешове с еднакви ключове, то може да ги обединим по подходящ за случая ни начин.
# 3. Ключовете се интернират, а стригновете - не.
# 4. Вместо метод с много проверки е по-добре да се измислят по-къси методи, които да вършат същата работа.
# 5. Избирането на подходящи имена на променливи помага много за разбирането на логиката на програмата.
# 6. Можем да зададем втори аргумент на split, който указва на колко части да се разделят елементите.
# 7. Спейсовете в Руби нямат значение в повечето случаи така че можем да подравняваме аргументи на методи, елементи в масиви, хешове и др.възможно най-красиво и четимо.
# 8. Трябва да пишем тестове не само за валидни данни, за да може да хванем възможни грешки от страна на потребителя и да осигурим адекватно поведение на програмата.
# 9. При тестване е добре да кажем за коя функция се отнасят следващите тестове, за да може когато открием бъг да се ориентираме в кода къде да го търсим.
# 10. RSpec позволява влагане на изразите така че можем максимално добре и в дълбочина да опишем и тестваме всички случаи.
# 11. Добре е да тестваме по-малките методи за грешки и тогава да тестваме методите, които разчитат на тях.
# 12. Не е нужно в if да правим проверки от типа if условие != nil. Достатъчно е да напишем if условие.
# 13. Можем да проверим какъв текст извежда дадена грешка чрез expect { обектът ни }.to raise_error(вид грешка,"текст на грешката").
# 14. Когато създаваме custom еrror клас, той трябва да наследява някой от стандартните класове за грешки в Ruby.
# 15. Ако трябва да проверим някакво свойство за елементите от списък или хеш и спрямо това да вземем или изхвърлим, или променим някои от тях, то може да проверим в Enumerable за готова функция, която да улесни работата ни.
# 16. Revert в Git e прекрасна идея.
# 17. Можем да използваме self в методите и по този начин да викаме методи върху него, например self.class и други. Също така може да се използва като контрол в наследници на даден клас, т.е. чрез self да разберем в кой клас се намираме и спрямо това да извикаме даден метод.
# 18. Можем динамично да задаваме методи с define_method като подаваме като блок тялото на метода.
# 19. Ако трябва да дефинираме много класови методи е удобно да ги изнесем в модул, който да extend-нем в нашия клас.
# 20. Редовното тестване при промени в кода спестява главоболия.

Лог от изпълнението

From https://github.com/fmi/ruby-retrospective-2016
 * branch            master     -> FETCH_HEAD
HEAD is now at a22cf37 Set rubocop version to 0.46.0 to fix obsolete cop errors
Cloning into 'submission'...
HEAD is now at 1ace80a Copy of the original solution from the ruby team.
From /tmp/ruby-retrospective-2016/checker
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> upstream/master

Changes URL:
https://github.com/hrist-todorova/ruby-retrospective-2016/compare/1f710b00c26...1ace80ab159

'tasks/1/solution.rb' -> '/tmp/ruby-retrospective-2016/checker/tasks/1/solution.rb'
'tasks/2/solution.rb' -> '/tmp/ruby-retrospective-2016/checker/tasks/2/solution.rb'
'tasks/3/solution.rb' -> '/tmp/ruby-retrospective-2016/checker/tasks/3/solution.rb'
'tasks/4/solution.rb' -> '/tmp/ruby-retrospective-2016/checker/tasks/4/solution.rb'
'tasks/5/solution.rb' -> '/tmp/ruby-retrospective-2016/checker/tasks/5/solution.rb'
Inspecting 1 file
.

1 file inspected, no offenses detected
.................

Finished in 0.00464 seconds
17 examples, 0 failures
Inspecting 1 file
.

1 file inspected, no offenses detected
...............

Finished in 0.0072 seconds
15 examples, 0 failures
Inspecting 1 file
.

1 file inspected, no offenses detected
...............

Finished in 0.00563 seconds
15 examples, 0 failures
Inspecting 1 file
C

Offenses:

solution.rb:36:81: C: Line is too long. [85/80]
      it 'raises error when the argument has other symbols than points and digits' do
                                                                                ^^^^^

1 file inspected, 1 offense detected
F

Failures:

  1) ruby-retrospective-2016 covers the minimum requirements
     Failure/Error: system(command) or raise "Command failed for #{@solutions_repo}: #{command}"
     RuntimeError:
       Command failed for https://github.com/hrist-todorova/ruby-retrospective-2016: bundle exec rake check_all
     # /tmp/d20170211-11010-1gsz847/spec.rb:82:in `execute'
     # /tmp/d20170211-11010-1gsz847/spec.rb:75:in `block (3 levels) in solutions_pass_all_checks'
     # /tmp/d20170211-11010-1gsz847/spec.rb:74:in `chdir'
     # /tmp/d20170211-11010-1gsz847/spec.rb:74:in `block (2 levels) in solutions_pass_all_checks'
     # /tmp/d20170211-11010-1gsz847/spec.rb:40:in `chdir'
     # /tmp/d20170211-11010-1gsz847/spec.rb:40:in `block in solutions_pass_all_checks'
     # /tmp/d20170211-11010-1gsz847/spec.rb:39:in `solutions_pass_all_checks'
     # /tmp/d20170211-11010-1gsz847/spec.rb:19:in `ok?'
     # /tmp/d20170211-11010-1gsz847/spec.rb:101:in `<top (required)>'

Finished in 0.00085 seconds
1 example, 1 failure

Failed examples:

rspec /tmp/d20170211-11010-1gsz847/spec.rb:107 # ruby-retrospective-2016 covers the minimum requirements

История (3 версии и 0 коментара)

Христина обнови решението на 12.01.2017 22:23 (преди над 7 години)

+REPOSITORY = 'https://github.com/hrist-todorova/ruby-retrospective-2016'
+
+# Двадесет неща, които научих.
+#
+#

Христина обнови решението на 15.01.2017 14:53 (преди над 7 години)

REPOSITORY = 'https://github.com/hrist-todorova/ruby-retrospective-2016'
# Двадесет неща, които научих.
#
-#
+# 1. Можем да използваме оператора =|| за присвояване на стойност на променлива не само във вида x =|| а, но и във вида x = a || b като ако а е # nil, то х приема стойността на b.
+# 2. Ако имаме хешове с еднакви ключове, то може да ги обединим по подходящ за случая ни начин.
+# 3. Ключовете се интернират, а стригновете - не.
+# 4. Вместо метод с много проверки е по-добре да се измислят по-къси методи, които да вършат същата работа.
+# 5. Избирането на подходящи имена на променливи помага много за разбирането на логиката на програмата.
+# 6. Можем да зададем втори аргумент на split, който указва на колко части да се разделят елементите.
+# 7. Спейсовете в Руби нямат значение в повечето случаи така че можем да подравняваме аргументи на методи, елементи в масиви, хешове и др.възможно най-красиво и четимо.
+# 8. Трябва да пишем тестове не само за валидни данни, за да може да хванем възможни грешки от страна на потребителя и да осигурим адекватно # поведение на програмата.
+# 9. При тестване е добре да кажем за коя функция се отнасят следващите тестове, за да може когато открием бъг да се ориентираме в кода къде да го търсим.
+# 10. RSpec позволява влагане на изразите така че можем максимално добре и в дълбочина да опишем и тестваме всички случаи.
+# 11. Добре е да тестваме по-малките методи за грешки и тогава да тестваме методите, които разчитат на тях.
+# 12. Не е нужно в if да правим проверки от типа if условие != nil. Достатъчно е да напишем if условие.
+# 13. Можем да проверим какъв текст извежда дадена грешка чрез expect { обектът ни }.to raise_error(вид грешка,"текст на грешката").
+# 14. Когато създаваме custom еrror клас, той трябва да наследява някой от стандартните класове за грешки в Ruby.
+# 15. Ако трябва да проверим някакво свойство за елементите от списък или хеш и спрямо това да вземем или изхвърлим, или променим някои от тях, то може да проверим в Enumerable за готова функция, която да улесни работата ни.
+# 16. Revert в Git e прекрасна идея.
+# 17. Можем да използваме self в методите и по този начин да викаме методи върху него, например self.class и други. Също така може да се използва като контрол в наследници на даден клас, т.е. чрез self да разберем в кой клас се намираме и спрямо това да извикаме даден метод.
+# 18. Можем динамично да задаваме методи с define_method като подаваме като блок тялото на метода.
+# 19. Ако трябва да дефинираме много класови методи е удобно да ги изнесем в модул, който да extend-нем в нашия клас.
+# 20. Редовното тестване при промени в кода спестява главоболия.

Христина обнови решението на 15.01.2017 14:55 (преди над 7 години)

REPOSITORY = 'https://github.com/hrist-todorova/ruby-retrospective-2016'
-
# Двадесет неща, които научих.
#
-# 1. Можем да използваме оператора =|| за присвояване на стойност на променлива не само във вида x =|| а, но и във вида x = a || b като ако а е # nil, то х приема стойността на b.
+# 1. Можем да използваме оператора =|| за присвояване на стойност на променлива не само във вида x =|| а, но и във вида x = a || b като ако а е nil, то х приема стойността на b.
+
# 2. Ако имаме хешове с еднакви ключове, то може да ги обединим по подходящ за случая ни начин.
+
# 3. Ключовете се интернират, а стригновете - не.
+
# 4. Вместо метод с много проверки е по-добре да се измислят по-къси методи, които да вършат същата работа.
+
# 5. Избирането на подходящи имена на променливи помага много за разбирането на логиката на програмата.
+
# 6. Можем да зададем втори аргумент на split, който указва на колко части да се разделят елементите.
+
# 7. Спейсовете в Руби нямат значение в повечето случаи така че можем да подравняваме аргументи на методи, елементи в масиви, хешове и др.възможно най-красиво и четимо.
-# 8. Трябва да пишем тестове не само за валидни данни, за да може да хванем възможни грешки от страна на потребителя и да осигурим адекватно # поведение на програмата.
+
+# 8. Трябва да пишем тестове не само за валидни данни, за да може да хванем възможни грешки от страна на потребителя и да осигурим адекватно поведение на програмата.
+
# 9. При тестване е добре да кажем за коя функция се отнасят следващите тестове, за да може когато открием бъг да се ориентираме в кода къде да го търсим.
+
# 10. RSpec позволява влагане на изразите така че можем максимално добре и в дълбочина да опишем и тестваме всички случаи.
+
# 11. Добре е да тестваме по-малките методи за грешки и тогава да тестваме методите, които разчитат на тях.
+
# 12. Не е нужно в if да правим проверки от типа if условие != nil. Достатъчно е да напишем if условие.
+
# 13. Можем да проверим какъв текст извежда дадена грешка чрез expect { обектът ни }.to raise_error(вид грешка,"текст на грешката").
+
# 14. Когато създаваме custom еrror клас, той трябва да наследява някой от стандартните класове за грешки в Ruby.
+
# 15. Ако трябва да проверим някакво свойство за елементите от списък или хеш и спрямо това да вземем или изхвърлим, или променим някои от тях, то може да проверим в Enumerable за готова функция, която да улесни работата ни.
+
# 16. Revert в Git e прекрасна идея.
+
# 17. Можем да използваме self в методите и по този начин да викаме методи върху него, например self.class и други. Също така може да се използва като контрол в наследници на даден клас, т.е. чрез self да разберем в кой клас се намираме и спрямо това да извикаме даден метод.
+
# 18. Можем динамично да задаваме методи с define_method като подаваме като блок тялото на метода.
+
# 19. Ако трябва да дефинираме много класови методи е удобно да ги изнесем в модул, който да extend-нем в нашия клас.
+
# 20. Редовното тестване при промени в кода спестява главоболия.