Решение на Десета задача от Георги Стефанов

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

Към профила на Георги Стефанов

Резултати

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

Код

REPOSITORY = 'https://github.com/georgisvetlozarovstefanov/ruby-retrospective-2015-2'
# 1. За да използваме друг файл можем да добавим require 'filename' в нашия код. Негова вариация -
# require_relative е доста удобна, тъй като тя търси спрямо директорията на файла съдържащ
# require_relaive.
# 2. Всичко, което може да е самостоятелно е добре да се направи в отделни константи или класове.
# Ако при повикването си може да приема някаква променлива стойност може да се направи в клас,
# а иначе просто константи. Пример : в 5-та задача използвам клас Messages, за съобщения. Тъй като
# те зависят от input, не можах да ги направя просто константи.
# 3. При интерполация на низове, по-четимо е когато къдравите скоби са прилепени до променливата, която
# се интерполира - намалява се възможността да се прочете грешно низът.
# 4. Ако метод връща различни стойности при corner cases, добре е първо те да се проверят и да се върнат съответните
# стойности. В противен случай се изпълнява код, който:
# а) може да предизвика логически или RunTime грешки;
# b) прави ненужни изчисления и усложнява логиката на програмата.
# 5. За да построя низ с голяма дължина, простиращ се на няколко реда, мога да построя масив от редовете
# и да използвам метода join. Същото важи и за извличане на списък от данни, които отговарят на някакъв
# регулярен израз.
# 6. Ruby позволява да се създават обекти тип Time. Ако искам да създам време, отговарящо на текущото ( по време на изпълнение на програмата),
# вместо Time.new , пиша Time.now.
# 7. require 'digest/sha1' за да можеш лесно да хешираш информация.
# 8. Да предположим, че имаме два метода, които в своето начало извършват някакви операции, които са подобни. Тогава по-елегантно ще е да се
# да се напише метод, който генерализира тази част, в която те съвпадат. Пример: Задача 6 - костенурката трябва да може да се завърти надясно, наляво
# (може да искаме да се завърта и на 180 градуса, etc. ). Тогава вместо да създаваме отделни методи всеки имплементиран по "свой си начин", можем просто да
# създадем един - за завъртане наляво например, тъй като той образува базис на всички въртения на ъгли кратни на 90 градуса.
# 9. Когато имаме задача или проект, които са много обемни : Първо трябва да отделим самостоятелните части - компоненти, които сами по себе си трябва да могат да извършват
# това, което се изисква от тях. Много е удобно при мисленето на архитектурата на програмата да се използват графики, чертежи и подобни - те създават обща представа за
# главното API - това, което всъщност е най-важното. Самата имплементация се оставя за накрая, но въпреки това е добре да имаш едно наум за това какво е най-удобно в
# имплементацията.
# 10. За Ruby е много удобно да се изтегли и ползва някакъв наръчник, както и offline копие на RubyDoc-а. Нерядко може да срещнеш проблем с интернет връзката си и тези подходи,
# предоставят лесно решение.
# 11. Мултиредовите низове могат да се създават с '\'. Така не се пълнят с излишни символи '\n'.
# 12. Обектите в Ruby имат булеви стойности, от което човек трябва да се възползва ако иска да има по-четлив код. Удобно е при търсене
# на елемент в масив, ако се нуждаеш и от самия елемент ако бъде намерен.
# 13. Методът split комбиниран с регулярни изрази има приложеие за извличане на информация и складиране в низове. С втория аргумент показваш
# колко елемента да се вземат от split-натия низ.
# 14. Писането на тестове е изключително важно, а въпреки това сравнително леко. Пример: За първи път си написах собствени тестове за задача 7. Много е готино и успях
# да получа пълен брой точки на задачата. За тестовете е важно да са написани оптимално - да не са много дълги, но да покриват най-много случаи, включително и някои гранични.
# 15. Могат да се правят multi-line регулярни изрази с модификатора "x". Пример :
# "(expression.match(%r{\A\ *[A-Z]+\ *\(\ *(([-]?\d+(\.\d+)?)|
# ([A-Z]+[0-9]+))?\ *\)\z}x) != nil) || \
# (expression.match(%r{\A\ *[A-Z]+\ *\(\ *((([-]?\d+(\.\d+)?)|
# ([A-Z]+[0-9]+))\ *,\ *)+\ *(([-]?\d+(\.\d+)?)
# |([A-Z]+[0-9]+))\ *\)\ *\z}x) != nil)".
# В такъв случай обаче преди whitespace символите трябва да се слага индикатор '\'.
# 16. Доброто познаване на принципа на call стека е от значение за поправянето на грешки в програмите. Това включва и бързата ориентация в backtrace-а.
# Предвидимите грешки не трябва да се хващат - те показват грешки в имплементацията на програмата, които трябва да се поправят.
# 17. Понякога се налага да се извършат много методи върху един начален получател. Тогава могат да се chain-нат. Ако кодът става твърде дълъг, може
# да се пренесе на няколко реда. Пример :
# "occurs_on = [0,1,2,3,4,5,6].map { |day| date.to_days + day }.
# map{ |days| Date.to_date(days) }.
# delete_if { |date| !(self === date) }
# occurs_on".
# Къде се оставя точката - на края на горния ред или в началото на долния - е въпрос на избор, но без нещо да показва, че chain-нът е свършил, човек
# може да се обърка при четенето на кода.
# 18. По-"човешко" (т.е. по-лесно и поносимо) и по-интуитивно е кодът да е immutable. По-малко странични ефекти, по-лесно се следи и изтъква принципите на
# ООП.
# 19. Освен кода, самите проекти, които правя трябва да са добре подредени и структурирани. Това включва файловете и документацията. В тази насока, друго нещо, което осъзнах е, че
# Ruby и Windows не са най-добрата комбинация.
# 20. Чуждият код е идеален начин да са научиш на по-добра собствена практика. Освен всичко, ти дава и перспектива за това как "колегите" разсъждават върху даден проблем.
# А когато видиш много прост и елегантен начин за осъществяване на нещо, което намираш за сложно се и вдъхновяваш, което е голям плюс.

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

From https://github.com/fmi/ruby-retrospective-2015-2
 * branch            master     -> FETCH_HEAD
HEAD is now at 512294b Modify a test in task 8 to not include empty cells
Cloning into 'submission'...
HEAD is now at 9e150a9 Method chaining - better perceptability
From /tmp/ruby-retrospective-2015-2/checker
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> upstream/master

Changes URL:
https://github.com/georgisvetlozarovstefanov/ruby-retrospective-2015-2/compare/512294b6dde...9e150a9476f

‘solutions/08.rb’ -> ‘/tmp/ruby-retrospective-2015-2/checker/solutions/08.rb’
‘solutions/05.rb’ -> ‘/tmp/ruby-retrospective-2015-2/checker/solutions/05.rb’
‘solutions/07.rb’ -> ‘/tmp/ruby-retrospective-2015-2/checker/solutions/07.rb’
‘solutions/06.rb’ -> ‘/tmp/ruby-retrospective-2015-2/checker/solutions/06.rb’
OK
..............................

Finished in 0.02539 seconds
30 examples, 0 failures
OK
..............

Finished in 0.00968 seconds
14 examples, 0 failures
OK
...............................

Finished in 0.0765 seconds
31 examples, 0 failures
English words for names
* inexistant on line 254 is not in english

Errors found
F

Failures:

  1) ruby-retrospective-2015-2 covers the minimum requirements
     Failure/Error: system(command) or raise "Command failed for #{@solutions_repo}: #{command}"
     RuntimeError:
       Command failed for https://github.com/georgisvetlozarovstefanov/ruby-retrospective-2015-2: bundle exec rake check
     # /tmp/d20160131-21007-1gpm02w/spec.rb:107:in `execute'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:82:in `block (3 levels) in solutions_pass_all_checks'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:81:in `chdir'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:81:in `block (2 levels) in solutions_pass_all_checks'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:47:in `chdir'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:47:in `block in solutions_pass_all_checks'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:46:in `solutions_pass_all_checks'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:20:in `ok?'
     # /tmp/d20160131-21007-1gpm02w/spec.rb:126:in `<top (required)>'

Finished in 0.00094 seconds
1 example, 1 failure

Failed examples:

rspec /tmp/d20160131-21007-1gpm02w/spec.rb:132 # ruby-retrospective-2015-2 covers the minimum requirements

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

Георги обнови решението на 27.01.2016 00:19 (преди почти 9 години)

+REPOSITORY = 'https://github.com/georgisvetlozarovstefanov/ruby-retrospective-2015-2'
+
+# 1. За да използваме друг файл можем да добавим require 'filename' в нашия код. Негова вариация -
+# require_relative е доста удобна, тъй като тя търси спрямо директорията на файла съдържащ
+# require_relaive.
+
+# 2. Всичко, което може да е самостоятелно е добре да се направи в отделни константи или класове.
+# Ако при повикването си може да приема някаква променлива стойност може да се направи в клас,
+# а иначе просто константи. Пример : в 5-та задача използвам клас Messages, за съобщения. Тъй като
+# те зависят от input, не можах да ги направя просто константи.
+
+# 3. При интерполация на низове, по-четимо е когато къдравите скоби са прилепени до променливата, която
+# се интерполира - намалява се възможността да се прочете грешно низът.
+
+# 4. Ако метод връща различни стойности при corner cases, добре е първо те да се проверят и да се върнат съответните
+# стойности. В противен случай се изпълнява код, който:
+
+# а) може да предизвика логически или RunTime грешки;
+# b) прави ненужни изчисления и усложнява логиката на програмата.
+
+# 5. За да построя низ с голяма дължина, простиращ се на няколко реда, мога да построя масив от редовете
+# и да използвам метода join. Същото важи и за извличане на списък от данни, които отговарят на някакъв
+# регулярен израз.
+
+# 6. Ruby позволява да се създават обекти тип Time. Ако искам да създам време, отговарящо на текущото ( по време на изпълнение на програмата),
+# вместо Time.new , пиша Time.now.
+
+# 7. require 'digest/sha1' за да можеш лесно да хешираш информация.
+
+# 8. Да предположим, че имаме два метода, които в своето начало извършват някакви операции, които са подобни. Тогава по-елегантно ще е да се
+# да се напише метод, който генерализира тази част, в която те съвпадат. Пример: Задача 6 - костенурката трябва да може да се завърти надясно, наляво
+# (може да искаме да се завърта и на 180 градуса, etc. ). Тогава вместо да създаваме отделни методи всеки имплементиран по "свой си начин", можем просто да
+# създадем един - за завъртане наляво например, тъй като той образува базис на всички въртения на ъгли кратни на 90 градуса.
+
+# 9. Когато имаме задача или проект, които са много обемни : Първо трябва да отделим самостоятелните части - компоненти, които сами по себе си трябва да могат да извършват
+# това, което се изисква от тях. Много е удобно при мисленето на архитектурата на програмата да се използват графики, чертежи и подобни - те създават обща представа за
+# главното API - това, което всъщност е най-важното. Самата имплементация се оставя за накрая, но въпреки това е добре да имаш едно наум за това какво е най-удобно в
+# имплементацията.
+
+# 10. За Ruby е много удобно да се изтегли и ползва някакъв наръчник, както и offline копие на RubyDoc-а. Нерядко може да срещнеш проблем с интернет връзката си и тези подходи,
+# предоставят лесно решение.
+
+# 11. Мултиредовите низове могат да се създават с '\'. Така не се пълнят с излишни символи '\n'.
+
+# 12. Обектите в Ruby имат булеви стойности, от което човек трябва да се възползва ако иска да има по-четлив код. Удобно е при търсене
+# на елемент в масив, ако се нуждаеш и от самия елемент ако бъде намерен.
+
+# 13. Методът split комбиниран с регулярни изрази има приложеие за извличане на информация и складиране в низове. С втория аргумент показваш
+# колко елемента да се вземат от split-натия низ.
+
+# 14. Писането на тестове е изключително важно, а въпреки това сравнително леко. Пример: За първи път си написах собствени тестове за задача 7. Много е готино и успях
+# да получа пълен брой точки на задачата. За тестовете е важно да са написани оптимално - да не са много дълги, но да покриват най-много случаи, включително и някои гранични.
+
+# 15. Могат да се правят multi-line регулярни изрази с модификатора "x". Пример :
+
+# "(expression.match(%r{\A\ *[A-Z]+\ *\(\ *(([-]?\d+(\.\d+)?)|
+# ([A-Z]+[0-9]+))?\ *\)\z}x) != nil) || \
+# (expression.match(%r{\A\ *[A-Z]+\ *\(\ *((([-]?\d+(\.\d+)?)|
+# ([A-Z]+[0-9]+))\ *,\ *)+\ *(([-]?\d+(\.\d+)?)
+# |([A-Z]+[0-9]+))\ *\)\ *\z}x) != nil)".
+
+# В такъв случай обаче преди whitespace символите трябва да се слага индикатор '\'.
+
+# 16. Доброто познаване на принципа на call стека е от значение за поправянето на грешки в програмите. Това включва и бързата ориентация в backtrace-а.
+# Предвидимите грешки не трябва да се хващат - те показват грешки в имплементацията на програмата, които трябва да се поправят.
+
+# 17. Понякога се налага да се извършат много методи върху един начален получател. Тогава могат да се chain-нат. Ако кодът става твърде дълъг, може
+# да се пренесе на няколко реда. Пример :
+
+# "occurs_on = [0,1,2,3,4,5,6].map { |day| date.to_days + day }.
+# map{ |days| Date.to_date(days) }.
+# delete_if { |date| !(self === date) }
+# occurs_on".
+
+# Къде се оставя точката - на края на горния ред или в началото на долния - е въпрос на избор, но без нещо да показва, че chain-нът е свършил, човек
+# може да се обърка при четенето на кода.
+
+# 18. По-"човешко" (т.е. по-лесно и поносимо) и по-интуитивно е кодът да е immutable. По-малко странични ефекти, по-лесно се следи и изтъква принципите на
+# ООП.
+
+# 19. Освен кода, самите проекти, които правя трябва да са добре подредени и структурирани. Това включва файловете и документацията. В тази насока, друго нещо, което осъзнах е, че
+# Ruby и Windows не са най-добрата комбинация.
+
+# 20. Чуждият код е идеален начин да са научиш на по-добра собствена практика. Освен всичко, ти дава и перспектива за това как "колегите" разсъждават върху даден проблем.
+# А когато видиш много прост и елегантен начин за осъществяване на нещо, което намираш за сложно се и вдъхновяваш, което е голям плюс.

Георги обнови решението на 27.01.2016 21:51 (преди почти 9 години)

REPOSITORY = 'https://github.com/georgisvetlozarovstefanov/ruby-retrospective-2015-2'
# 1. За да използваме друг файл можем да добавим require 'filename' в нашия код. Негова вариация -
# require_relative е доста удобна, тъй като тя търси спрямо директорията на файла съдържащ
# require_relaive.
# 2. Всичко, което може да е самостоятелно е добре да се направи в отделни константи или класове.
# Ако при повикването си може да приема някаква променлива стойност може да се направи в клас,
# а иначе просто константи. Пример : в 5-та задача използвам клас Messages, за съобщения. Тъй като
# те зависят от input, не можах да ги направя просто константи.
# 3. При интерполация на низове, по-четимо е когато къдравите скоби са прилепени до променливата, която
# се интерполира - намалява се възможността да се прочете грешно низът.
# 4. Ако метод връща различни стойности при corner cases, добре е първо те да се проверят и да се върнат съответните
# стойности. В противен случай се изпълнява код, който:
# а) може да предизвика логически или RunTime грешки;
# b) прави ненужни изчисления и усложнява логиката на програмата.
-# 5. За да построя низ с голяма дължина, простиращ се на няколко реда, мога да построя масив от редовете
+# 5. За да построя низ с голяма дължина, простиращ се на няколко реда, мога да построя масив от редовете
# и да използвам метода join. Същото важи и за извличане на списък от данни, които отговарят на някакъв
# регулярен израз.
-# 6. Ruby позволява да се създават обекти тип Time. Ако искам да създам време, отговарящо на текущото ( по време на изпълнение на програмата),
+# 6. Ruby позволява да се създават обекти тип Time. Ако искам да създам време, отговарящо на текущото ( по време на изпълнение на програмата),
# вместо Time.new , пиша Time.now.
-# 7. require 'digest/sha1' за да можеш лесно да хешираш информация.
+# 7. require 'digest/sha1' за да можеш лесно да хешираш информация.
-# 8. Да предположим, че имаме два метода, които в своето начало извършват някакви операции, които са подобни. Тогава по-елегантно ще е да се
-# да се напише метод, който генерализира тази част, в която те съвпадат. Пример: Задача 6 - костенурката трябва да може да се завърти надясно, наляво
-# (може да искаме да се завърта и на 180 градуса, etc. ). Тогава вместо да създаваме отделни методи всеки имплементиран по "свой си начин", можем просто да
-# създадем един - за завъртане наляво например, тъй като той образува базис на всички въртения на ъгли кратни на 90 градуса.
+# 8. Да предположим, че имаме два метода, които в своето начало извършват някакви операции, които са подобни. Тогава по-елегантно ще е да се
+# да се напише метод, който генерализира тази част, в която те съвпадат. Пример: Задача 6 - костенурката трябва да може да се завърти надясно, наляво
+# (може да искаме да се завърта и на 180 градуса, etc. ). Тогава вместо да създаваме отделни методи всеки имплементиран по "свой си начин", можем просто да
+# създадем един - за завъртане наляво например, тъй като той образува базис на всички въртения на ъгли кратни на 90 градуса.
-# 9. Когато имаме задача или проект, които са много обемни : Първо трябва да отделим самостоятелните части - компоненти, които сами по себе си трябва да могат да извършват
-# това, което се изисква от тях. Много е удобно при мисленето на архитектурата на програмата да се използват графики, чертежи и подобни - те създават обща представа за
-# главното API - това, което всъщност е най-важното. Самата имплементация се оставя за накрая, но въпреки това е добре да имаш едно наум за това какво е най-удобно в
-# имплементацията.
+# 9. Когато имаме задача или проект, които са много обемни : Първо трябва да отделим самостоятелните части - компоненти, които сами по себе си трябва да могат да извършват
+# това, което се изисква от тях. Много е удобно при мисленето на архитектурата на програмата да се използват графики, чертежи и подобни - те създават обща представа за
+# главното API - това, което всъщност е най-важното. Самата имплементация се оставя за накрая, но въпреки това е добре да имаш едно наум за това какво е най-удобно в
+# имплементацията.
-# 10. За Ruby е много удобно да се изтегли и ползва някакъв наръчник, както и offline копие на RubyDoc-а. Нерядко може да срещнеш проблем с интернет връзката си и тези подходи,
-# предоставят лесно решение.
+# 10. За Ruby е много удобно да се изтегли и ползва някакъв наръчник, както и offline копие на RubyDoc-а. Нерядко може да срещнеш проблем с интернет връзката си и тези подходи,
+# предоставят лесно решение.
-# 11. Мултиредовите низове могат да се създават с '\'. Така не се пълнят с излишни символи '\n'.
+# 11. Мултиредовите низове могат да се създават с '\'. Така не се пълнят с излишни символи '\n'.
-# 12. Обектите в Ruby имат булеви стойности, от което човек трябва да се възползва ако иска да има по-четлив код. Удобно е при търсене
-# на елемент в масив, ако се нуждаеш и от самия елемент ако бъде намерен.
+# 12. Обектите в Ruby имат булеви стойности, от което човек трябва да се възползва ако иска да има по-четлив код. Удобно е при търсене
+# на елемент в масив, ако се нуждаеш и от самия елемент ако бъде намерен.
-# 13. Методът split комбиниран с регулярни изрази има приложеие за извличане на информация и складиране в низове. С втория аргумент показваш
-# колко елемента да се вземат от split-натия низ.
+# 13. Методът split комбиниран с регулярни изрази има приложеие за извличане на информация и складиране в низове. С втория аргумент показваш
+# колко елемента да се вземат от split-натия низ.
-# 14. Писането на тестове е изключително важно, а въпреки това сравнително леко. Пример: За първи път си написах собствени тестове за задача 7. Много е готино и успях
-# да получа пълен брой точки на задачата. За тестовете е важно да са написани оптимално - да не са много дълги, но да покриват най-много случаи, включително и някои гранични.
+# 14. Писането на тестове е изключително важно, а въпреки това сравнително леко. Пример: За първи път си написах собствени тестове за задача 7. Много е готино и успях
+# да получа пълен брой точки на задачата. За тестовете е важно да са написани оптимално - да не са много дълги, но да покриват най-много случаи, включително и някои гранични.
-# 15. Могат да се правят multi-line регулярни изрази с модификатора "x". Пример :
+# 15. Могат да се правят multi-line регулярни изрази с модификатора "x". Пример :
# "(expression.match(%r{\A\ *[A-Z]+\ *\(\ *(([-]?\d+(\.\d+)?)|
# ([A-Z]+[0-9]+))?\ *\)\z}x) != nil) || \
# (expression.match(%r{\A\ *[A-Z]+\ *\(\ *((([-]?\d+(\.\d+)?)|
# ([A-Z]+[0-9]+))\ *,\ *)+\ *(([-]?\d+(\.\d+)?)
# |([A-Z]+[0-9]+))\ *\)\ *\z}x) != nil)".
# В такъв случай обаче преди whitespace символите трябва да се слага индикатор '\'.
# 16. Доброто познаване на принципа на call стека е от значение за поправянето на грешки в програмите. Това включва и бързата ориентация в backtrace-а.
-# Предвидимите грешки не трябва да се хващат - те показват грешки в имплементацията на програмата, които трябва да се поправят.
+# Предвидимите грешки не трябва да се хващат - те показват грешки в имплементацията на програмата, които трябва да се поправят.
# 17. Понякога се налага да се извършат много методи върху един начален получател. Тогава могат да се chain-нат. Ако кодът става твърде дълъг, може
-# да се пренесе на няколко реда. Пример :
+# да се пренесе на няколко реда. Пример :
# "occurs_on = [0,1,2,3,4,5,6].map { |day| date.to_days + day }.
# map{ |days| Date.to_date(days) }.
# delete_if { |date| !(self === date) }
# occurs_on".
-# Къде се оставя точката - на края на горния ред или в началото на долния - е въпрос на избор, но без нещо да показва, че chain-нът е свършил, човек
-# може да се обърка при четенето на кода.
+# Къде се оставя точката - на края на горния ред или в началото на долния - е въпрос на избор, но без нещо да показва, че chain-нът е свършил, човек
+# може да се обърка при четенето на кода.
# 18. По-"човешко" (т.е. по-лесно и поносимо) и по-интуитивно е кодът да е immutable. По-малко странични ефекти, по-лесно се следи и изтъква принципите на
-# ООП.
+# ООП.
# 19. Освен кода, самите проекти, които правя трябва да са добре подредени и структурирани. Това включва файловете и документацията. В тази насока, друго нещо, което осъзнах е, че
# Ruby и Windows не са най-добрата комбинация.
# 20. Чуждият код е идеален начин да са научиш на по-добра собствена практика. Освен всичко, ти дава и перспектива за това как "колегите" разсъждават върху даден проблем.
# А когато видиш много прост и елегантен начин за осъществяване на нещо, което намираш за сложно се и вдъхновяваш, което е голям плюс.