Първа задача

  1. Тук може да задавате въпроси по първа задача. В хранилището може да намерите примерния тест и инструкции как да го изпълнявате.

    Все още не сме ви предали целия материал, който ще ви е нужен да я решите, но сме ви казали къде и как да търсите документация. Задачата не е с голяма трудност, така че би трябвало да може да се оправите и сами със знанията, които имате до момента.

    В понеделник ще говорим за неща, които ще ви трябват за тази задача. Моят горещ съвет е да пробвате да я решите сами, преди понеделника. По този начин ще разберете до каква степен сте се справили с усвояване на материал сами, което си е много ценно и необходимо умение. Понеделник ще видите и някои трикчета и ще имате още два дни да правите евентуални подобрения по решението си.

  2. Revert-нали сме ъпдейта по условието.

    Ако се чудите, няколкото случая, в които сме казали, че метода е недефиниран, няма да проверяваме с автоматизирани тестовете. Реагирайте както прецените. Не сме говорили за изключения, но това е най-подходящото нещо в такива ситуации.

    Това, което би било неподхдощято, е да върнете nil. Тук се спазва принципа fail fast - нещата трябва да се чупят възможно най-бързо, когато в програмата има грешка. В противен случай, грешката се намира много по-трудно. Допълнително, програмата се упражнява с некоректни данни (например, получава nil, там където трябва да получи число). Аналогията на това -3.harmonic да върне nil е 3 / 0 да върне nil или 3 + 'apple' да върне nil – просто е семантично неправилно.

  3. @Николай (и всички останали), използвайте синтаксиса на Markdown, за да маркирате пасажи с код. Редактирал съм ти поста, за да изглежда човешки.

    Иначе, да – грозна е :)

    Макар че може, не трябва да се ползва така, най-малкото защото while C е нещо важно и не трябва да е навряно там, в дъното.

    Ето подредбата:

    while C
      if A and B
        line1
        line2
      else
        line3
      end
    end
    
  4. Грозна или не (субективно), трудно четима е (пак субективно, но по-значимо). Например, аз първия път въобще не видях, че там има while. Чак когато прегледах поста на Митьо го видях и се върнах обратно да видя дали не съм пропуснал нещо. Думичката за това е double-take и ако се случи, може би кода не е ОК.

    Като цяло, модификаторните форми на if, while и компания са ОК само за едноредови неща.

  5. Имам няколко въпроса:
    - Какво влияние имат времето за изпъление и изхабените ресурси от програмата върху оценката за задачата?
    - Докато преравях документациите намерих няколко много готини конструкции, които обаче не сме ги обсъждали на лекция. Ще санкционирате ли в случай, че използваме нещо, което не е споменато на лекция?
    - Има ли някакво ограничение върху тестовите данни? По-конкретно, може ли да считаме, че масивът не съдържа други масиви сред елементите си?

    ДОБАВКА: Можем ли да считаме, че в метода drop_every(n) n >= 1?

    • Понеже това не е ПРАНКА, ако не сме казали изрично, не мислете за времето за изпълнение и/или заеманата памет. С обемите данни, с които работим и на съвременния хардуер, това не е проблем. Борим се за четимост, експресивност, яснота и прочее.
    • Разбира се, няма да санкционираме за това. Да се рови човек е дори поощрително. Като програмисти, правим това непрекъснато.
    • Да е отговорът на последните два въпроса. Няма да има масиви в масивите :) ако има, нещо ще гръмне, но вие не се грижете за това.
  6. @Иван, принципно трябва да се хвърля ArgumentError или да се остави нещо в метода да гръмне. В случая, ние няма да ви подаваме такива списъци и не изискваме от вас да следите и реагирате на такива случаи.

  7. Не е работата на тестовете да го правят, работа на вашите решения е да го правят :) Този отговор, който пиша в момента, също не спазва skeptic ограниченията, но това като цяло не е много интересен факт, нали?

Трябва да сте влезли в системата, за да може да отговаряте на теми.