Решение на Пета задача от Герасим Станчев

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

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

Резултати

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

Код

#repo = https://github.com/Gerasim-Stan/ruby-retrospective-4
#01. Никога не опитвай да рефакторираш клас <=> модул.
#02. Автоматичните тестове са блаженство. Комбинирани с добре настроена среда, пестят часове. Ежедневно.
#03. Работата с обекти по чистия (Ruby) начин е много по:
# - лесна
# - приятна
# - консистентна
# в сравнение с останалите езици.
#04. Ruby е разработен за работа в UNIX-like системи.
#05. Правилното кръщаване на променливи е трудно, важно и трябва да му се отделя време и спокойствие.
#06. Всеки клас трябва да има една отговорност/задача (SRP).
#07. Всеки метод трябва да изпълнява точно зададено множество от операции, като при всички други случаи трябва да се „чупи“.
#08. Използването на each и всички изградени върху му допълнения, е изключително мощен и удобен инструмент.
#09. Метакласа на базовия клас е базовия клас на метакласа на наследника.
#10. Кода трябва да е DRY. Повторенията при писане на код или при тестване изразходват огромно количество енергия.
#11. При тернарния оператор не трябва да има страничен ефект, независимо от изхода.
#12. Изграждането на „скелет“ на модул от кода е добра идея при комбинация с test first. При останалите случаи обикновено е ненужно.
#13. Когато започвах да уча Ruby, обикновено използвах първия метод (особено от Enumerable), който покриваше поне част от желаната от мен функционалност,
# така че да мога сам да допиша останалото. Сега редовно проверявам с какви сладкишчета може да ме изненада стандартната библиотека.
#14. Трябва да се сещам за гениални идеи, като [larodi, foo, bar].max, където за масив (хетерогенна структура от данни) веднъж се дефинира метода max,
# и след това се използва за различни цели, а не се дефинира глобален метод (в Object, например). Все още не разбирам защо съм го срещал само в Ruby..
#15. Блоковете са още едно блаженство на езика. Комбинирани с идеята за комуникация между обектите със съобщения, се получава чудесен резултат.
# Решават много проблеми, възникващи в други езици, в които липсват.
#16. Ако написан на Ruby, кода не се чете, значи трябва да се пренапише/рефакторира.
# Много често е възможно писането на код, който се приближава до описанието „четим“ за хора, знаещи английски и незанимаващи се с програмиране.
#17. Писането на DSL-и е особено практично и сравнително лесно в Ruby.
#18. Съществува възможността за модулизация на кода, така че класове да са в модули, които по-късно да се добавят в други класове, а да не са дефинирани в Object.
# Проблема с пространствата от имена (namespaces) е решен елегантно. И е добра идея помощни класове да се влагат в самия клас.
#19. Научих, че в Ruby често съществуват два начина за решаване на проблем - с метод или синтаксис. Например, alias, или пък дефинирането на класови методи.
#20. Chain-ването на методи върху обект улеснява четенето. За разлика от редовното присвояване на стойности.
#21. Има удобни трикове, които обаче трябва да се избягват, тъй като не са особено популярни - например, heredoc.
# Не съм изчистил докрай формулировката на проблема и не съм сигурен доколко това избягване е добра/лоша идея, но ме боде в очите от няколко седмици.

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

Герасим обнови решението на 19.01.2015 11:50 (преди почти 10 години)

+#repo = https://github.com/Gerasim-Stan/ruby-retrospective-4
+
+#01. Никога не опитвай да рефакторираш клас <=> модул.
+
+#02. Автоматичните тестове са блаженство. Комбинирани с добре #настроена среда, пестят часове. Ежедневно.
+
+#03. Работата с обекти по чистия (Ruby) начин е много по:
+# - лесна
+# - приятна
+# - консистентна
+# в сравнение с останалите езици.
+
+#04. Ruby е разработен за работа в UNIX-like системи.
+
+#05. Правилното кръщаване на променливи е трудно, важно и трябва #да му се отделя време и спокойствие.
+
+#06. Всеки клас трябва да има една отговорност/задача (SRP).
+
+#07. Всеки метод трябва да изпълнява точно зададено множество от #операции, като при всички други случаи да се „чупи“.
+
+#08. Използването на each и всички изградени върху му #допълнения, е изключително мощен и удобен инструмент.
+
+#09. Метакласа на базовия клас е базовия клас на метакласа на #наследника.
+
+#10. Кода трябва да е DRY. Повторенията при писане на код или #при тестване изразходва огромно количество енергия.
+
+#11. При тернарния оператор не трябва да има страничен ефект, #независимо от изхода.
+
+#12. Изграждането на „скелет“ на модул от кода е добра идея при #комбинация с test first. При останалите случаи обикновено е #ненужно.
+
+#13. Когато започвах да уча Ruby, обикновено използвах първия #метод (особено от Enumerable), който покриваше поне част от #желаната от мен функционалност, така че да мога сам да допиша #останалото. Сега редовно проверявам с какви сладкишчета може да #ме изненада стандартната библиотека.
+
+#14. Трябва да се сещам за гениални идеи, като [larodi, foo, #bar].max, където за масив (хетерогенна структура от данни) #веднъж се дефинира метода max, и след това се използва за #различни цели, а не се дефинира глобален метод (в Object, #например). Все още не разбирам защо съм го срещал само в Ruby..
+
+#15. Блоковете са още едно блаженство на езика. Комбинирани с #идеята за комуникация между обектите със съобщения, се получава #чудесен резултат. Решават много проблеми, възникващи в други #езици, в които липсват.
+
+#16. Ако написан на Ruby, кода не се чете, значи трябва да се #пренапише/рефакторира. Много често е възможно писането на код, #който се приближава до описанието „четим“ за хора, знаещи #английски и незанимаващи се с програмиране.
+
+#17. Писането на DSL-и е особено практично и сравнително лесно в #Ruby.
+
+#18. Съществува възможността за модулизация на кода, така че #класове да са в модули, които по-късно да се добавят в други #класове, а да не са дефинирани в Object. Проблема с #пространствата от имена (namespaces) е решен елегантно. И е 3добра идея помощни класове да се влагат в самия клас.
+
+#19. Научих, че в Ruby често съществуват два начина за решаване #на проблем - с метод или синтаксис. Например, alias, или пък #дефинирането на класови методи.
+
+#20. Chain-ването на методи върху обект улеснява четенето. За #разлика от редовното присвояване на стойности.
+
+#21. Има удобни трикове, които обаче трябва да се избягват, тъй #като не са особено популярни - например, heredoc.

Герасим обнови решението на 19.01.2015 11:50 (преди почти 10 години)

#repo = https://github.com/Gerasim-Stan/ruby-retrospective-4
#01. Никога не опитвай да рефакторираш клас <=> модул.
-#02. Автоматичните тестове са блаженство. Комбинирани с добре #настроена среда, пестят часове. Ежедневно.
+#02. Автоматичните тестове са блаженство. Комбинирани с добре настроена среда, пестят часове. Ежедневно.
#03. Работата с обекти по чистия (Ruby) начин е много по:
# - лесна
# - приятна
# - консистентна
# в сравнение с останалите езици.
#04. Ruby е разработен за работа в UNIX-like системи.
-#05. Правилното кръщаване на променливи е трудно, важно и трябва #да му се отделя време и спокойствие.
+#05. Правилното кръщаване на променливи е трудно, важно и трябва да му се отделя време и спокойствие.
#06. Всеки клас трябва да има една отговорност/задача (SRP).
-#07. Всеки метод трябва да изпълнява точно зададено множество от #операции, като при всички други случаи да се „чупи“.
+#07. Всеки метод трябва да изпълнява точно зададено множество от операции, като при всички други случаи да се „чупи“.
-#08. Използването на each и всички изградени върху му #допълнения, е изключително мощен и удобен инструмент.
+#08. Използването на each и всички изградени върху му допълнения, е изключително мощен и удобен инструмент.
-#09. Метакласа на базовия клас е базовия клас на метакласа на #наследника.
+#09. Метакласа на базовия клас е базовия клас на метакласа на наследника.
-#10. Кода трябва да е DRY. Повторенията при писане на код или #при тестване изразходва огромно количество енергия.
+#10. Кода трябва да е DRY. Повторенията при писане на код или при тестване изразходва огромно количество енергия.
-#11. При тернарния оператор не трябва да има страничен ефект, #независимо от изхода.
+#11. При тернарния оператор не трябва да има страничен ефект, независимо от изхода.
-#12. Изграждането на „скелет“ на модул от кода е добра идея при #комбинация с test first. При останалите случаи обикновено е #ненужно.
+#12. Изграждането на „скелет“ на модул от кода е добра идея при комбинация с test first. При останалите случаи обикновено е ненужно.
-#13. Когато започвах да уча Ruby, обикновено използвах първия #метод (особено от Enumerable), който покриваше поне част от #желаната от мен функционалност, така че да мога сам да допиша #останалото. Сега редовно проверявам с какви сладкишчета може да #ме изненада стандартната библиотека.
+#13. Когато започвах да уча Ruby, обикновено използвах първия метод (особено от Enumerable), който покриваше поне част от желаната от мен функционалност, така че да мога сам да допиша останалото. Сега редовно проверявам с какви сладкишчета може да ме изненада стандартната библиотека.
-#14. Трябва да се сещам за гениални идеи, като [larodi, foo, #bar].max, където за масив (хетерогенна структура от данни) #веднъж се дефинира метода max, и след това се използва за #различни цели, а не се дефинира глобален метод (в Object, #например). Все още не разбирам защо съм го срещал само в Ruby..
+#14. Трябва да се сещам за гениални идеи, като [larodi, foo, bar].max, където за масив (хетерогенна структура от данни) веднъж се дефинира метода max, и след това се използва за различни цели, а не се дефинира глобален метод (в Object, например). Все още не разбирам защо съм го срещал само в Ruby..
-#15. Блоковете са още едно блаженство на езика. Комбинирани с #идеята за комуникация между обектите със съобщения, се получава #чудесен резултат. Решават много проблеми, възникващи в други #езици, в които липсват.
+#15. Блоковете са още едно блаженство на езика. Комбинирани с идеята за комуникация между обектите със съобщения, се получава чудесен резултат. Решават много проблеми, възникващи в други езици, в които липсват.
-#16. Ако написан на Ruby, кода не се чете, значи трябва да се #пренапише/рефакторира. Много често е възможно писането на код, #който се приближава до описанието „четим“ за хора, знаещи #английски и незанимаващи се с програмиране.
+#16. Ако написан на Ruby, кода не се чете, значи трябва да се пренапише/рефакторира. Много често е възможно писането на код, който се приближава до описанието „четим“ за хора, знаещи английски и незанимаващи се с програмиране.
-#17. Писането на DSL-и е особено практично и сравнително лесно в #Ruby.
+#17. Писането на DSL-и е особено практично и сравнително лесно в Ruby.
-#18. Съществува възможността за модулизация на кода, така че #класове да са в модули, които по-късно да се добавят в други #класове, а да не са дефинирани в Object. Проблема с #пространствата от имена (namespaces) е решен елегантно. И е 3добра идея помощни класове да се влагат в самия клас.
+#18. Съществува възможността за модулизация на кода, така че класове да са в модули, които по-късно да се добавят в други класове, а да не са дефинирани в Object. Проблема с пространствата от имена (namespaces) е решен елегантно. И е добра идея помощни класове да се влагат в самия клас.
-#19. Научих, че в Ruby често съществуват два начина за решаване #на проблем - с метод или синтаксис. Например, alias, или пък #дефинирането на класови методи.
+#19. Научих, че в Ruby често съществуват два начина за решаване на проблем - с метод или синтаксис. Например, alias, или пък дефинирането на класови методи.
-#20. Chain-ването на методи върху обект улеснява четенето. За #разлика от редовното присвояване на стойности.
+#20. Chain-ването на методи върху обект улеснява четенето. За разлика от редовното присвояване на стойности.
-#21. Има удобни трикове, които обаче трябва да се избягват, тъй #като не са особено популярни - например, heredoc.
+#21. Има удобни трикове, които обаче трябва да се избягват, тъй като не са особено популярни - например, heredoc.

Герасим обнови решението на 21.01.2015 12:23 (преди почти 10 години)

#repo = https://github.com/Gerasim-Stan/ruby-retrospective-4
#01. Никога не опитвай да рефакторираш клас <=> модул.
#02. Автоматичните тестове са блаженство. Комбинирани с добре настроена среда, пестят часове. Ежедневно.
#03. Работата с обекти по чистия (Ruby) начин е много по:
# - лесна
# - приятна
# - консистентна
# в сравнение с останалите езици.
#04. Ruby е разработен за работа в UNIX-like системи.
#05. Правилното кръщаване на променливи е трудно, важно и трябва да му се отделя време и спокойствие.
#06. Всеки клас трябва да има една отговорност/задача (SRP).
-#07. Всеки метод трябва да изпълнява точно зададено множество от операции, като при всички други случаи да се „чупи“.
+#07. Всеки метод трябва да изпълнява точно зададено множество от операции, като при всички други случаи трябва да се „чупи“.
#08. Използването на each и всички изградени върху му допълнения, е изключително мощен и удобен инструмент.
#09. Метакласа на базовия клас е базовия клас на метакласа на наследника.
-#10. Кода трябва да е DRY. Повторенията при писане на код или при тестване изразходва огромно количество енергия.
+#10. Кода трябва да е DRY. Повторенията при писане на код или при тестване изразходват огромно количество енергия.
#11. При тернарния оператор не трябва да има страничен ефект, независимо от изхода.
#12. Изграждането на „скелет“ на модул от кода е добра идея при комбинация с test first. При останалите случаи обикновено е ненужно.
-#13. Когато започвах да уча Ruby, обикновено използвах първия метод (особено от Enumerable), който покриваше поне част от желаната от мен функционалност, така че да мога сам да допиша останалото. Сега редовно проверявам с какви сладкишчета може да ме изненада стандартната библиотека.
+#13. Когато започвах да уча Ruby, обикновено използвах първия метод (особено от Enumerable), който покриваше поне част от желаната от мен функционалност,
+# така че да мога сам да допиша останалото. Сега редовно проверявам с какви сладкишчета може да ме изненада стандартната библиотека.
-#14. Трябва да се сещам за гениални идеи, като [larodi, foo, bar].max, където за масив (хетерогенна структура от данни) веднъж се дефинира метода max, и след това се използва за различни цели, а не се дефинира глобален метод (в Object, например). Все още не разбирам защо съм го срещал само в Ruby..
+#14. Трябва да се сещам за гениални идеи, като [larodi, foo, bar].max,
+# където за масив (хетерогенна структура от данни) веднъж се дефинира метода max, и след това се използва за различни цели, а не се дефинира глобален метод (в Object, например). Все още не разбирам защо съм го срещал само в Ruby..
-#15. Блоковете са още едно блаженство на езика. Комбинирани с идеята за комуникация между обектите със съобщения, се получава чудесен резултат. Решават много проблеми, възникващи в други езици, в които липсват.
+#15. Блоковете са още едно блаженство на езика. Комбинирани с идеята за комуникация между обектите със съобщения, се получава чудесен резултат.
+# Решават много проблеми, възникващи в други езици, в които липсват.
-#16. Ако написан на Ruby, кода не се чете, значи трябва да се пренапише/рефакторира. Много често е възможно писането на код, който се приближава до описанието „четим“ за хора, знаещи английски и незанимаващи се с програмиране.
+#16. Ако написан на Ruby, кода не се чете, значи трябва да се пренапише/рефакторира.
+# Много често е възможно писането на код, който се приближава до описанието „четим“ за хора, знаещи английски и незанимаващи се с програмиране.
#17. Писането на DSL-и е особено практично и сравнително лесно в Ruby.
-#18. Съществува възможността за модулизация на кода, така че класове да са в модули, които по-късно да се добавят в други класове, а да не са дефинирани в Object. Проблема с пространствата от имена (namespaces) е решен елегантно. И е добра идея помощни класове да се влагат в самия клас.
+#18. Съществува възможността за модулизация на кода, така че класове да са в модули, които по-късно да се добавят в други класове, а да не са дефинирани в Object.
+# Проблема с пространствата от имена (namespaces) е решен елегантно. И е добра идея помощни класове да се влагат в самия клас.
#19. Научих, че в Ruby често съществуват два начина за решаване на проблем - с метод или синтаксис. Например, alias, или пък дефинирането на класови методи.
#20. Chain-ването на методи върху обект улеснява четенето. За разлика от редовното присвояване на стойности.
#21. Има удобни трикове, които обаче трябва да се избягват, тъй като не са особено популярни - например, heredoc.
+# Не съм изчистил докрай формулировката на проблема и не съм сигурен доколко това избягване е добра/лоша идея, но ме боде в очите от няколко седмици.

Герасим обнови решението на 21.01.2015 12:24 (преди почти 10 години)

#repo = https://github.com/Gerasim-Stan/ruby-retrospective-4
#01. Никога не опитвай да рефакторираш клас <=> модул.
#02. Автоматичните тестове са блаженство. Комбинирани с добре настроена среда, пестят часове. Ежедневно.
#03. Работата с обекти по чистия (Ruby) начин е много по:
# - лесна
# - приятна
# - консистентна
# в сравнение с останалите езици.
#04. Ruby е разработен за работа в UNIX-like системи.
#05. Правилното кръщаване на променливи е трудно, важно и трябва да му се отделя време и спокойствие.
#06. Всеки клас трябва да има една отговорност/задача (SRP).
#07. Всеки метод трябва да изпълнява точно зададено множество от операции, като при всички други случаи трябва да се „чупи“.
#08. Използването на each и всички изградени върху му допълнения, е изключително мощен и удобен инструмент.
#09. Метакласа на базовия клас е базовия клас на метакласа на наследника.
#10. Кода трябва да е DRY. Повторенията при писане на код или при тестване изразходват огромно количество енергия.
#11. При тернарния оператор не трябва да има страничен ефект, независимо от изхода.
#12. Изграждането на „скелет“ на модул от кода е добра идея при комбинация с test first. При останалите случаи обикновено е ненужно.
#13. Когато започвах да уча Ruby, обикновено използвах първия метод (особено от Enumerable), който покриваше поне част от желаната от мен функционалност,
# така че да мога сам да допиша останалото. Сега редовно проверявам с какви сладкишчета може да ме изненада стандартната библиотека.
-#14. Трябва да се сещам за гениални идеи, като [larodi, foo, bar].max,
-# където за масив (хетерогенна структура от данни) веднъж се дефинира метода max, и след това се използва за различни цели, а не се дефинира глобален метод (в Object, например). Все още не разбирам защо съм го срещал само в Ruby..
+#14. Трябва да се сещам за гениални идеи, като [larodi, foo, bar].max, където за масив (хетерогенна структура от данни) веднъж се дефинира метода max,
+# и след това се използва за различни цели, а не се дефинира глобален метод (в Object, например). Все още не разбирам защо съм го срещал само в Ruby..
#15. Блоковете са още едно блаженство на езика. Комбинирани с идеята за комуникация между обектите със съобщения, се получава чудесен резултат.
# Решават много проблеми, възникващи в други езици, в които липсват.
#16. Ако написан на Ruby, кода не се чете, значи трябва да се пренапише/рефакторира.
# Много често е възможно писането на код, който се приближава до описанието „четим“ за хора, знаещи английски и незанимаващи се с програмиране.
#17. Писането на DSL-и е особено практично и сравнително лесно в Ruby.
#18. Съществува възможността за модулизация на кода, така че класове да са в модули, които по-късно да се добавят в други класове, а да не са дефинирани в Object.
# Проблема с пространствата от имена (namespaces) е решен елегантно. И е добра идея помощни класове да се влагат в самия клас.
#19. Научих, че в Ruby често съществуват два начина за решаване на проблем - с метод или синтаксис. Например, alias, или пък дефинирането на класови методи.
#20. Chain-ването на методи върху обект улеснява четенето. За разлика от редовното присвояване на стойности.
#21. Има удобни трикове, които обаче трябва да се избягват, тъй като не са особено популярни - например, heredoc.
# Не съм изчистил докрай формулировката на проблема и не съм сигурен доколко това избягване е добра/лоша идея, но ме боде в очите от няколко седмици.