Николай обнови решението на 22.01.2014 12:50 (преди около 10 години)
+REPOSITORY = 'https://github.com/NikolayGenov/ruby-retrospective-3'
+
+# Двадесет неща, които научих.
+
+# 1. Може да се използва symbol на някои места, където се ползва block и това да съкрати
+# кода драстично и да го направи значително по-четим.
+# 2. По-добре е да се използа each_with_object отколкото да се използва по-сложен reduce
+# за работа с обекти и стойности.
+# 3. По-добре да се взимат неща на парчета с each_slice и да се обработват на парчета
+# отколкото едно по едно и да се правят отделни манипулации с тях.
+# 4. Може да се използва zip като вземаме само по-кратката част от 2 общи масива,
+# за да се обединят и да се направи обратно в един масив, но трябва да се използва flatten,
+# който да бъде с аргумент 1, за да не се махат всички скоби.
+# 5. Хубаво е да се изнесе парсването на нещата в отделен клас или на отделно място,
+# за да се изчисти логиката и да остане само на едно единствено място и другите класове
+# да не се интересуват данните, които получават в какъв формат са.
+# 6. Да се използват модули вместо класове където се дефинират методи за обработка на данни
+# и не е нужно съхранението на данни за след това.
+# 7. По-добре е да се създава обект от типа на класа като се използва new с името на класа,
+# а не само с new.
+# 8. Когато трябва да извикаме даден attr_reader, който не искаме да е публичен и в същотото време
+# искаме да може да се извика от обектите в класа ни, е хубаво да използваме protected.
+# 9. Може да се ползва placeholder за въвеждане на стринг в друг freeze-нат стринг и след това
+# да се извика с '%' и желания от нас стринг след него.
+#10. Може да ползваме pred когато искаме да вземем размери например от 0-ла до pred вместо n-1.
+#11. Хубаво е да имаме базов клас, където да изнесем общите части за всичко и да дефинираме
+# общите публични методи като такива, които ще хвърлят изключение, ако не са дефинирани.
+#12. Хубаво е да замразяваме стринговите обекти, за да не се създават всеки път нови,
+# което да може да доведе до нежелани ефекти и възможност за exploit.
+#13. Хубаво е отделните алгоритми да се капсулират в свой собствен клас и да се разбиват
+# на отделни части, като тези класове са вътрешни за мястото където този алгоритъм
+# ще бъде използван. Това позволява той да бъде тестван отделно като клас.
+#14. Хубаво е не един клас да се грижи за това как всичко се изобразява(чертае) върху нещо,
+# а се подава като аргумент мястото, където ще се изобразява и всеки отделен клас да знае сам
+# как да се начертае върху него. Така мястото където ще бъде чертано няма нужда да има
+# излишното знанието всяко нещо как се прави и да се трупат допълнителни методи в него.
+#15. По-добре е да се правят методи в класа за създаването на нещо ново, когато то не се използват
+# в класа и е необходимо само за външния интерфейс
+#16. По-добре е да се използват хешове за запазване на елементи, защото така не се изтересуваме
+# дали те са извън зададените от нас граници, но и да са - това няма да се отрази в грешка,
+# а просто метода, който се грижи за поставянето на елементите ще трябва да се погрижи този
+# елемент да се игнорира. Когато имаме малък на брой елементи за запазване,
+# тогава чрез хешове намаляваме използваната памет.
+#17. Удобно е да се използва класов attr_accessor за даден флаг, който трябва да се променя и
+# не принадлежи на никоя инстанция, а също така е нужно да се извлече неговата
+# стойност на няколко места в различни класове.
+#18. Удобно е да се използва метапрограмиране, за да се намали значително количеството
+# на повтарящ се код, също така и дължината на методите и до някъде тяхната сложност.
+# Създаването на методи, които получават ламбда, която от своя страна се оценява по-късно,
+# прави нещата доста по DRY, до някъде за сметка на разбираемост и сложност като метапрограмиране.
+#19. Може да създаваме нови хешове като им подаваме блок, който трябва да се грижи за
+# тяхната инициализация и да връща дадена стойност, която е определена от блока (или обект)
+# по-подразбиране ако искаме да достъпим ключ, който все още не съществува.
+#20. Хубаво е да връщаме self като краен резултат от методи, също така да използваме tap, и всичко това,
+# за да може да chain-ваме различни методи без проблем.
Доста от нещата, които си написал, си ги обобщил като принципно валидни истини, а те са по-скоро едно от възможните сносни решения на конкретен проблем в конкретна задача.
Освен това, не съм съгласен с т. 7. Аз бих използвал само new, ако съм в класов контекст. Точка 15 не съм съвсем сигурен, че я разбирам добре.
Като цяло - добре си се справил :) Надявам се да си доволен от наученото.