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

Резултати

6 точки от тестове
0 бонус точки
6 точки общо

1 успешни тест(а)
0 неуспешни тест(а)

Код

REPOSITORY = 'https://github.com/DobrinTs/ruby-retrospective-2016'

# Двадесет неща, които научих.

# 1. Може задача да ти се струва много проста, много добре написана, да работи

# според очакваното, но дори и най-простата задача има как да бъде подобрена.

# 2. Сливането на хешове с еднакви ключове, като новите стойности са хешове

# от старите стойности, не трябва да ни плаши. Така няма да усложним логиката

# на програмата, а напротив - ще я направим по-разбираема и по-компактна.

# 3. Стараейки се да улесня програмата чрез избягване на някои пресмятания,

# винаги трябва да се замислям "Дали пък по този начин не правя излишни

# проверки?".

# 4. Поредицата if-elseif-...-else прави кода труден за четене. Вместо това,

# когато в условието пише нещо от сорта на "Няма да подаваме мерни единици,

# различни от тези три.", може просто да оставя програмата да гръмне при

# недефинирано поведение и да не усложнявам кода.

# 5. Колко полезни могат да са map, reduce и filter. Вместо да правя нов

# масив(или друг вид контейнер), да обхождам оригиналния и в резултата да

# слагам само някои елементи, може просто да напиша map/filter/reduce върху

# оригиналния и да спестя памет и няколко реда (освен ако се избират самo

# части от елементите на оригиналния контейнер на база на

# сложна логика, коятo би било трудно да опиша в един кратък filter).

# 6. Колко полезно е да седнеш и да разгледаш как няколко човека

# решават един и същ проблем. В резултат собственото ти решение може да се

# подобри многократно.

# 7. По даден ключ и контейнер(хеш или масив) в променливи как може да не правя

# излишни проверки кое какво е, а просто да използвам Duck typing за

# достъпване на желаната стойност.

# 8. Колко е важно да си си настроил добре средата, в която пишеш. Например аз

# пиша кода в Sublime 3 и подкарвам програмата като натисна Ctrl+B, но явно

# Sublime ми е настроен на по-стара версия на Ruby. В резултат bundle exec

# rake check[2] в терминала минаваше всички тестове, но програмата, пусната

# през Sublime, даваше грешка при метода Array#to_h.

# 9. Колко е трудно след като си се сблъскал с по-трудна задача и с

# много усилия си успял да я решиш, да загърбиш старото решение, да спреш да

# мислиш неща от сорта "Ама това си работи добре" и да пренапишеш половината

# код.

# 10. Как изкарването на логика по класове може да направи програмата

# по-разбираема. Например вместо да запазваме аргументи и опции чрез масиви

# и само аз да си знам кой масив какво всъщност представлява, може да напиша

# по един клас и да улесня живота на тези, които ще четат кода след това.

# 11. Пренаписването на код не винаги е страшно нещо. Старият код не е бил

# просто загуба на време, а напротив - много идеи от стария код може да бъдат

# взети и модифицирани така, че да работят в новия код.

# 12. Когато вече си си казал "Добре! Хората правят отделни класове за

# аргумент, опция и опция с аргумент. И аз ще направя така.", вече ти се струва

# напълно логично да има 3 отделни класа. Но трябва ли те да са напълно

# отделни? Сядаш, гледаш кода на хората и аха - опция с аргумент наследява от

# опция. Винаги трябва да се замислям дали мога да направя един клас наследник

# на друг клас, за да преизползвам функционалност.

# 13. Колко е важно да тестваш абсолютно всички случаи, дори и да ти се струва,

# че се повтаряш. Например тествайки Range, проверявам, че по-голяма стойност

# не е в Range-a, но не правя същото за по-малка стойност. Още 1 ред, дори и

# аналогичен на предишния, щеше да спести 1 гръмнал тест.

# 14. След като вече имаш написани някакви тестове, колко е лесно и удобно да

# дописваш нови, без те по никакъв начин да указват влияние върху старите. Щом

# е толкова удобно, защо да не пиша тестове успоредно с програмата?

# 15. Важно е не само какъв Exception е хвърлила програмата, а и какво точно

# е съобщението му.

# 16. Чрез дефинирането на един простичък private метод може да си спестиш

# многократно писане на неща от сорта на "self.class.method_name". Извод -

# замисли се как да си направиш променливи и методи по-лесно достъпни.

# 17. Когато съм изправен пред проблем и имам някаква идея не трябва да мисля

# само дали мога да я реализирам, а дали трябва. Няма ли някакъв по-лесен начин

# да постигна същия резултат?

# 18. Instance_variable_get/set е лоша практика и защо да го използвам, когато

# имам вече дефинирани методи, извикването на които ми дава достъп до същите

# променливи?

# 19. Когато си дефинираме собствен клас Exception-и е хубаво да си направим и

# метод initialize, за да сме сигурни, че exception-ите от този клас ще имат

# коректно съобщение.

# 20. Когато решиш да приложиш map/select/reject и имаш

# готов код, който ще ти свърши работата, е изключително важно да си дадеш

# сметка дали за този ход е необходимо да филтрираш структурата или само keys,

# или само values на структурата. Например в слайдовете имаше код за find

# метода на хранилищата за данни - "@storage.select do |record| ..." и за

# ArrayStore работи перфектно, но за HashStore е необходимо да се промени на

# "@storage.values.select do |record| ...".

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

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 2cceab0 Update the solution for task 5.
From /tmp/ruby-retrospective-2016/checker
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> upstream/master

Changes URL:
https://github.com/DobrinTs/ruby-retrospective-2016/compare/1f710b00c26...2cceab0bff0

'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.04006 seconds
17 examples, 0 failures
Inspecting 1 file
.

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

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

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

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

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

Finished in 19.21 seconds
20 examples, 0 failures
Inspecting 1 file
.

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

Finished in 0.06042 seconds
25 examples, 0 failures
.

Finished in 0.00165 seconds
1 example, 0 failures

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

Добрин обнови решението на 13.01.2017 16:38 (преди почти 8 години)

+REPOSITORY = 'https://github.com/DobrinTs/ruby-retrospective-2016'

+# Двадесет неща, които научих.

+# 1. Може задача да ти се струва много проста, много добре написана, да работи

+# според очакваното, но дори и най-простата задача има как да бъде подобрена.

+# 2. Сливането на хешове с еднакви ключове, като новите стойности са хешове

+# от старите стойности, не трябва да ни плаши. Така няма да усложним логиката

+# на програмата, а напротив - ще я направим по-разбираема и по-компактна.

+# 3. Стараейки се да улесня програмата чрез избягване на някои пресмятания,

+# винаги трябва да се замислям "Дали пък по този начин не правя излишни

+# проверки?".

+# 4. Поредицата if-elseif-...-else прави кода труден за четене. Вместо това,

+# когато в условието пише нещо то сорта на "Няма да подаваме мерни единици,

+# различни от тези три.", може просто да оставя програмата да гръмне при

+# недефинирано поведение и да не усложнявам кода.

+# 5. Колко полезни могат да са map, reduce и filter. Вместо да правя нов

+# масив(или друг вид контейнер), да обхождам оригиналния и в резултата да

+# слагам само някои елементи, може просто да напиша map/filter/reduce върху

+# оригиналния и да спестя памет и няколко реда.

+# 6. Колко полезно е да седнеш и да разгледаш как няколко човека

+# решават един и същ проблем. В резултат собственото ти решение може да се

+# подобри многократно.

+# 7. По даден ключ и контейнер(хеш или масив) в променливи как може да не правя

+# излишни проверки кое какво е, а просто да използвам Duck typing за

+# достъпване на желаната стойност.

+# 8. Колко е важно да си си настроил добре средата, в която пишеш. Например аз

+# пиша кода в Sublime 3 и подкарвам програмата като натисна Ctrl+B, но явно

+# Sublime ми е настроен на по-стара версия на Ruby. В резултат bundle exec

+# rake check[2] в терминала минаваше всички тестове, но програмата, пусната

+# през Sublime, даваше грешка при метода Array#to_h.

+# 9. Колко е трудно след като си се сблъскал с по-трудна задача и с

+# много усилия си успял да я решиш, да загърбиш старото решение, да спреш да

+# мислиш неща от сорта "Ама това си работи добре" и да пренапишеш половината

+# код.

+# 10. Как изкарването на логика по класове може да направи програмата

+# по-разбираема. Например вместо да запазваме аргументи и опции чрез масиви

+# и само аз да си знам кой масив какво всъщност представлява, може да напиша

+# по един клас и да улесня живота на тези, които ще четат кода след това.

+# 11. Пренаписването на код не винаги е страшно нещо. Старият код не е бил

+# просто загуба на време, а напротив - много идеи от стария код може да бъдат

+# взети и модифицирани така, че да работят в новия код.

+# 12. Когато вече си си казал "Добре! Хората правят отделни класове за

+# аргумент, опция и опция с аргумент. И аз ще направя така.", вече ти се струва

+# напълно логично да има 3 отделни класа. Но трябва ли те да са напълно

+# отделни? Сядаш, гледаш кода на хората и аха - опция с аргумент наследява от

+# опция. Винаги трябва да се замислям дали мога да направя един клас наследник

+# на друг клас, за да преизползвам функционалност.

+# 13. Колко е важно да тестваш абсолютно всички случаи, дори и да ти се струва,

+# че се повтаряш. Например тествайки Range, проверявам, че по-голяма стойност

+# не е в Range-a, но не правя същото за по-малка стойност. Още 1 ред, дори и

+# аналогичен на предишния, щеше да спести 1 гръмнал тест.

+# 14. След като вече имаш написани някакви тестове, колко е лесно и удобно да

+# дописваш нови, без те по никакъв начин да указват влияние върху старите. Щом

+# е толкова удобно, защо да не пиша тестове успоредно с програмата?

+# 15. Важно е не само какъв Exception е хвърлила програмата, а и какво точно

+# е съобщението му.

+# 16. Чрез дефинирането на един простичък private метод може да си спестиш

+# многократно писане на неща от сорта на "self.class.method_name". Извод -

+# замисли се как да си направиш променливи и методи по-лесно достъпни.

+# 17. Когато съм изправен пред проблем и имам някаква идея не трябва да мисля

+# само дали мога да я реализирам, а дали трябва. Няма ли някакъв по-лесен начин

+# да постигна същия резултат?

+# 18. Instance_variable_get/set е лоша практика и защо да го използвам, когато

+# имам вече дефинирани методи, извикването на които ми дава достъп до същите

+# променливи?

+# 19. Когато си дефинираме собствен клас Exception-и е хубаво да си направим и

+# метод initialize, за да сме сигурни, че exception-ите от този клас ще имат

+# коректно съобщение.

+# 20. Когато решиш да приложиш map/select/reject и имаш

+# готов код, който ще ти свърши работата, е изключително важно да си дадеш

+# сметка дали за този ход е необходимо да филтрираш структурата или само keys,

+# или само values на структурата. Например в слайдовете имаше код за find

+# метода на хранилищата за данни - "@storage.select do |record| ..." и за

+# ArrayStore работи перфектно, но за HashStore е необходимо да се промени на

+# "@storage.values.select do |record| ...".

Добрин обнови решението на 15.01.2017 18:52 (преди почти 8 години)

 REPOSITORY = 'https://github.com/DobrinTs/ruby-retrospective-2016'

 # Двадесет неща, които научих.

 # 1. Може задача да ти се струва много проста, много добре написана, да работи

 # според очакваното, но дори и най-простата задача има как да бъде подобрена.

 # 2. Сливането на хешове с еднакви ключове, като новите стойности са хешове

 # от старите стойности, не трябва да ни плаши. Така няма да усложним логиката

 # на програмата, а напротив - ще я направим по-разбираема и по-компактна.

 # 3. Стараейки се да улесня програмата чрез избягване на някои пресмятания,

 # винаги трябва да се замислям "Дали пък по този начин не правя излишни

 # проверки?".

 # 4. Поредицата if-elseif-...-else прави кода труден за четене. Вместо това,

-# когато в условието пише нещо то сорта на "Няма да подаваме мерни единици,

+# когато в условието пише нещо от сорта на "Няма да подаваме мерни единици,

 # различни от тези три.", може просто да оставя програмата да гръмне при

 # недефинирано поведение и да не усложнявам кода.

 # 5. Колко полезни могат да са map, reduce и filter. Вместо да правя нов

 # масив(или друг вид контейнер), да обхождам оригиналния и в резултата да

 # слагам само някои елементи, може просто да напиша map/filter/reduce върху

-# оригиналния и да спестя памет и няколко реда.

+# оригиналния и да спестя памет и няколко реда (освен ако се избират самo

+# части от елементите на оригиналния контейнер или се използва друг вид

+# сложна логика, коятo би било трудно да опиша в един кратък filter).

 # 6. Колко полезно е да седнеш и да разгледаш как няколко човека

 # решават един и същ проблем. В резултат собственото ти решение може да се

 # подобри многократно.

 # 7. По даден ключ и контейнер(хеш или масив) в променливи как може да не правя

 # излишни проверки кое какво е, а просто да използвам Duck typing за

 # достъпване на желаната стойност.

 # 8. Колко е важно да си си настроил добре средата, в която пишеш. Например аз

 # пиша кода в Sublime 3 и подкарвам програмата като натисна Ctrl+B, но явно

 # Sublime ми е настроен на по-стара версия на Ruby. В резултат bundle exec

 # rake check[2] в терминала минаваше всички тестове, но програмата, пусната

 # през Sublime, даваше грешка при метода Array#to_h.

 # 9. Колко е трудно след като си се сблъскал с по-трудна задача и с

 # много усилия си успял да я решиш, да загърбиш старото решение, да спреш да

 # мислиш неща от сорта "Ама това си работи добре" и да пренапишеш половината

 # код.

 # 10. Как изкарването на логика по класове може да направи програмата

 # по-разбираема. Например вместо да запазваме аргументи и опции чрез масиви

 # и само аз да си знам кой масив какво всъщност представлява, може да напиша

 # по един клас и да улесня живота на тези, които ще четат кода след това.

 # 11. Пренаписването на код не винаги е страшно нещо. Старият код не е бил

 # просто загуба на време, а напротив - много идеи от стария код може да бъдат

 # взети и модифицирани така, че да работят в новия код.

 # 12. Когато вече си си казал "Добре! Хората правят отделни класове за

 # аргумент, опция и опция с аргумент. И аз ще направя така.", вече ти се струва

 # напълно логично да има 3 отделни класа. Но трябва ли те да са напълно

 # отделни? Сядаш, гледаш кода на хората и аха - опция с аргумент наследява от

 # опция. Винаги трябва да се замислям дали мога да направя един клас наследник

 # на друг клас, за да преизползвам функционалност.

 # 13. Колко е важно да тестваш абсолютно всички случаи, дори и да ти се струва,

 # че се повтаряш. Например тествайки Range, проверявам, че по-голяма стойност

 # не е в Range-a, но не правя същото за по-малка стойност. Още 1 ред, дори и

 # аналогичен на предишния, щеше да спести 1 гръмнал тест.

 # 14. След като вече имаш написани някакви тестове, колко е лесно и удобно да

 # дописваш нови, без те по никакъв начин да указват влияние върху старите. Щом

 # е толкова удобно, защо да не пиша тестове успоредно с програмата?

 # 15. Важно е не само какъв Exception е хвърлила програмата, а и какво точно

 # е съобщението му.

 # 16. Чрез дефинирането на един простичък private метод може да си спестиш

 # многократно писане на неща от сорта на "self.class.method_name". Извод -

 # замисли се как да си направиш променливи и методи по-лесно достъпни.

 # 17. Когато съм изправен пред проблем и имам някаква идея не трябва да мисля

 # само дали мога да я реализирам, а дали трябва. Няма ли някакъв по-лесен начин

 # да постигна същия резултат?

 # 18. Instance_variable_get/set е лоша практика и защо да го използвам, когато

 # имам вече дефинирани методи, извикването на които ми дава достъп до същите

 # променливи?

 # 19. Когато си дефинираме собствен клас Exception-и е хубаво да си направим и

 # метод initialize, за да сме сигурни, че exception-ите от този клас ще имат

 # коректно съобщение.

 # 20. Когато решиш да приложиш map/select/reject и имаш

 # готов код, който ще ти свърши работата, е изключително важно да си дадеш

 # сметка дали за този ход е необходимо да филтрираш структурата или само keys,

 # или само values на структурата. Например в слайдовете имаше код за find

 # метода на хранилищата за данни - "@storage.select do |record| ..." и за

 # ArrayStore работи перфектно, но за HashStore е необходимо да се промени на

 # "@storage.values.select do |record| ...".

Добрин обнови решението на 15.01.2017 18:53 (преди почти 8 години)

 REPOSITORY = 'https://github.com/DobrinTs/ruby-retrospective-2016'

 # Двадесет неща, които научих.

 # 1. Може задача да ти се струва много проста, много добре написана, да работи

 # според очакваното, но дори и най-простата задача има как да бъде подобрена.

 # 2. Сливането на хешове с еднакви ключове, като новите стойности са хешове

 # от старите стойности, не трябва да ни плаши. Така няма да усложним логиката

 # на програмата, а напротив - ще я направим по-разбираема и по-компактна.

 # 3. Стараейки се да улесня програмата чрез избягване на някои пресмятания,

 # винаги трябва да се замислям "Дали пък по този начин не правя излишни

 # проверки?".

 # 4. Поредицата if-elseif-...-else прави кода труден за четене. Вместо това,

 # когато в условието пише нещо от сорта на "Няма да подаваме мерни единици,

 # различни от тези три.", може просто да оставя програмата да гръмне при

 # недефинирано поведение и да не усложнявам кода.

 # 5. Колко полезни могат да са map, reduce и filter. Вместо да правя нов

 # масив(или друг вид контейнер), да обхождам оригиналния и в резултата да

 # слагам само някои елементи, може просто да напиша map/filter/reduce върху

 # оригиналния и да спестя памет и няколко реда (освен ако се избират самo

-# части от елементите на оригиналния контейнер или се използва друг вид

+# части от елементите на оригиналния контейнер на база на

 # сложна логика, коятo би било трудно да опиша в един кратък filter).

 # 6. Колко полезно е да седнеш и да разгледаш как няколко човека

 # решават един и същ проблем. В резултат собственото ти решение може да се

 # подобри многократно.

 # 7. По даден ключ и контейнер(хеш или масив) в променливи как може да не правя

 # излишни проверки кое какво е, а просто да използвам Duck typing за

 # достъпване на желаната стойност.

 # 8. Колко е важно да си си настроил добре средата, в която пишеш. Например аз

 # пиша кода в Sublime 3 и подкарвам програмата като натисна Ctrl+B, но явно

 # Sublime ми е настроен на по-стара версия на Ruby. В резултат bundle exec

 # rake check[2] в терминала минаваше всички тестове, но програмата, пусната

 # през Sublime, даваше грешка при метода Array#to_h.

 # 9. Колко е трудно след като си се сблъскал с по-трудна задача и с

 # много усилия си успял да я решиш, да загърбиш старото решение, да спреш да

 # мислиш неща от сорта "Ама това си работи добре" и да пренапишеш половината

 # код.

 # 10. Как изкарването на логика по класове може да направи програмата

 # по-разбираема. Например вместо да запазваме аргументи и опции чрез масиви

 # и само аз да си знам кой масив какво всъщност представлява, може да напиша

 # по един клас и да улесня живота на тези, които ще четат кода след това.

 # 11. Пренаписването на код не винаги е страшно нещо. Старият код не е бил

 # просто загуба на време, а напротив - много идеи от стария код може да бъдат

 # взети и модифицирани така, че да работят в новия код.

 # 12. Когато вече си си казал "Добре! Хората правят отделни класове за

 # аргумент, опция и опция с аргумент. И аз ще направя така.", вече ти се струва

 # напълно логично да има 3 отделни класа. Но трябва ли те да са напълно

 # отделни? Сядаш, гледаш кода на хората и аха - опция с аргумент наследява от

 # опция. Винаги трябва да се замислям дали мога да направя един клас наследник

 # на друг клас, за да преизползвам функционалност.

 # 13. Колко е важно да тестваш абсолютно всички случаи, дори и да ти се струва,

 # че се повтаряш. Например тествайки Range, проверявам, че по-голяма стойност

 # не е в Range-a, но не правя същото за по-малка стойност. Още 1 ред, дори и

 # аналогичен на предишния, щеше да спести 1 гръмнал тест.

 # 14. След като вече имаш написани някакви тестове, колко е лесно и удобно да

 # дописваш нови, без те по никакъв начин да указват влияние върху старите. Щом

 # е толкова удобно, защо да не пиша тестове успоредно с програмата?

 # 15. Важно е не само какъв Exception е хвърлила програмата, а и какво точно

 # е съобщението му.

 # 16. Чрез дефинирането на един простичък private метод може да си спестиш

 # многократно писане на неща от сорта на "self.class.method_name". Извод -

 # замисли се как да си направиш променливи и методи по-лесно достъпни.

 # 17. Когато съм изправен пред проблем и имам някаква идея не трябва да мисля

 # само дали мога да я реализирам, а дали трябва. Няма ли някакъв по-лесен начин

 # да постигна същия резултат?

 # 18. Instance_variable_get/set е лоша практика и защо да го използвам, когато

 # имам вече дефинирани методи, извикването на които ми дава достъп до същите

 # променливи?

 # 19. Когато си дефинираме собствен клас Exception-и е хубаво да си направим и

 # метод initialize, за да сме сигурни, че exception-ите от този клас ще имат

 # коректно съобщение.

 # 20. Когато решиш да приложиш map/select/reject и имаш

 # готов код, който ще ти свърши работата, е изключително важно да си дадеш

 # сметка дали за този ход е необходимо да филтрираш структурата или само keys,

 # или само values на структурата. Например в слайдовете имаше код за find

 # метода на хранилищата за данни - "@storage.select do |record| ..." и за

 # ArrayStore работи перфектно, но за HashStore е необходимо да се промени на

 # "@storage.values.select do |record| ...".

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

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

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

Резултати

Код

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

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

Добрин обнови решението на 13.01.2017 16:38 (преди почти 8 години)

Добрин обнови решението на 15.01.2017 18:52 (преди почти 8 години)

Добрин обнови решението на 15.01.2017 18:53 (преди почти 8 години)