> А еще в начале февраля я купил и установил себе 350 ВТ переднее моторколесо.
Есть распространенное мнение что переднее моторколесо на велосипеде — не самая хорошая идея. Давление на переднее колесо небольшое, поэтому потерять сцепление с поверхностью очень легко, а следовательно управляемость велосипеда — это может иметь фатальные последствия.
> Если ехать недалеко — то бутылка с водой будет лишь лишним весом. Но если путь длиннее 5 км, то энергично едущий велосипедист теряет жидкость очень быстро, поэтому нужно часто пить.
Серьезно? Каждый день езжу 12 км на «дач-байке» до работы, никакой воды не требуется.
На весь путь уходит минут 40. Это быстрее чем на общественном транспорте.
Хотя не исключаю что это физиологические особенности моего организма, посему экстраполировать на других наверное не совсем корректно.
У меня она ассоциируется с башней Саурона. Наверное потому-что мигание «маяка» видно из почти из любой точки города ночью. А на севере города вообще создается ощущение что она нависает над тобой.
По мне так логично: фотополимер — это продукт химической промышленности, и исходный материал — условно нефть/газ/прочие промышленно-добываемые ископаемые.
Производство идет 24 часа в неделю, 365 дней в году, в любую погоду и при любой температуре окружающей среды.
Из чего производят воск — не ясно. Пчелы имхо не промышленный вариант.
Производство натурального пчелиного воска заведомо зависит от кучи условий, причем в ограниченное время — время весеннего цветения.
> Сейчас планируется, что в системе будет храниться информация о 58 млрд сделок, совершаемых ежедневно, а также данные о трейдерах, включая их номера социального страхования и даты рождения.
Я абсолютно согласен с автором — учебники и курсы дают неплохую теоретическую подготовку, но этого недостаточно.
Именно погружение в языковую среду — компьютерные игры, фильмы, книги и прочее дают именно тот минимальный уровень чтобы начать эффективно общаться на иностранном языке.
Многие повседневные современные фразеологизмы и идиомы в книгах вообще не освещаются, а без них смысл часто теряется в догадках.
А есть еще и акценты — например американский говор в первое время после переезда я понимал без проблем, почти как будто говорят на Русском. Спасибо Голливудским фильмам.
Но например разговор с британцем для меня был пыткой — после 5 минут мозг просто перегружался и переставал интерпретировать звуковые сигналы. Было очень стыдно и неприятно. И только после нескольких недель в одной команде с британцем, после того как мозг адаптировался, я смог нормально с ним коммуницировать :)
Вам нужны энциклопедические/академические статьи, написанные сухим точным языком, и с обязательным списком используемой литературы и источниками в конце? Мне кажется вы ресурсом ошиблись.
Мне наоборот нравится, и стиль неплохо согласуется с содержанием и посылом статьи.
Может стоит решать эту проблему, а не писать рядом "своими словами"?
Эта проблема как раз и решается.
Было бы оно точное, его можно было бы скомпилировать, выкинув весь остальной код.
А оно и компилируется. Это обычный DSL.
Он работает так же, как в остальном програмном коде. Что ещё от него можно ожидать? Ну а что в некоторых языках нет перегрузки операторов и сравнение всегда по ссылке, так о том и речь, что некоторые языки имеют кривой дизайн, из-за чего приходится добавлять костыли типа to eq.
Это совершенно не этот случай, to eq тут написан именно для того чтобы выражение было читабельным, а не убогим дискретным ассертом без контекста и правильной ошибки.
Все эти красоты не имеют смысла при использовании отладчика, а не отладке через repl.
А ну теперь все понятно. Это еще один аспект TDD/BDD который сударь не вкурил. Тесты используются не только для валидации, а так-же как часть процесса разработки и отладки.
Нет. Одна строчка кода и 5 записанных в одну строку — не одно и то же.
Если 5 строчек дают контекст и читабельность — это лучше чем одна ниндзя-строка которая делает все на свете.
Читаемость и поддерживаемость одной строчки выше, чем пяти.
> Куча бессмысленных bdd-расшаркиваний — это и есть уродливость.
На вкус и цвет все фломастеры разные.
> Никто кроме программистов читать ваши модульные тесты не будет. А программисту лучше читать формально точный програмный код, а не описание «своим языком», которое не полное и зачастую врёт.
В том и дело. «Формально» точный код порой тяжело читать, особенно если нет контекста. Пожалейте коллег.
Описание «своим языком» формально точно так-же «точное», просто написано читаемо.
> Часто, и в данном случае тоже, текстовое описание просто в точности повторяет программный код. В лучшем случае это тавтология, в худшем — описание с кодом разъезжается.
Суть в том чтобы описать поведение кода язком наиболее близким к человеческому. Ваши «точные», но неструктурированные тесты после нескольких итераций превращаются в нечитаемое гуано, в котором без пол-литра не разобраться.
> В конце концов это даже не BDD: ru.wikipedia.org/wiki/BDD_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
без комментариев
> В лучшем случае код тестов может выполнять роль примеров в документации, но заменить её не способен, так как документация должна давать общие правила использования, а тесты — это всегда конкретные примеры с конкретными параметрами. Приведённый мной код вполне себе попадает в документацию. Например: dlang.org/phobos/std_ascii.html#isAlphagithub.com/dlang/phobos/blob/master/std/ascii.d#L145
документация без примеров — плохая документация
> Сравнивать значения через метод to eq, когда в языке есть оператор сравнения == — это ничерта не красиво. Это карго-культ «человеческого» языка.
Вот только оператор сравнения `==` в некоторых языках может работать не так как ты ожидаешь.
Смысл использования to eq() не просто в самом сравнении, но и составлении правильного текста ошибки:
1) foo() returns bar
Failure/Error: expect(foo()).to eq('bar')
expected: "bar"
got: "zar"
(compared using ==)
Ну и сударь явно не понимает значения слова «карго-культ».
> Ну да, писать 5 строчек кода в место одной — вот где красота. Впрочем, с критериями «красиво/уродливо» вам стоило в художники пойти, а не в программисты. У программистов должны быть иные приоритеты.
Вы, сударь, видать любитель однострочников. Читаемость и поддерживаемость кода — не последний фактор в software engineering. Мне жалко ваших коллег.
Ну и эстетическая красота — имхо тоже не последняя вещь. С вашим подходом надо всем жить в панельных хрущевках.
Не очень понял смысл вашего примера. Речь топикстартера шла об «уродливости», а не о том чтобы написать самый минималистичный тест.
Суть и смысл BDD в том чтобы описывать поведение языком понимаемым человеком без лишних усилий. Таким образом код тестов может служить одновременно документацией к тестируемому коду.
Ну и это просто красиво. После BDD обычные тесты, с ассертами итп, выглядят уродливо.
Ну единственный вариант — домашний NAS. У меня например терабайтник к роутеру подключен по USB3 через адаптер, и служит дисковым пространством для устанавливаемых пакетов у роутера и прочей ерунды (например раздавать фильмы для телевизора).
Понимаю что пост рекламный, но все равно хочу сказать: Пусть WD и Seagate горят в аду. Это крик души.
Последние пять лет только Тошиба — ни единого разрыва.
А WD и Seagate у меня ассоциируются с долгими часами восстановления RAID массива, «стуками смерти» и прочими радостями. Причем это на дорогущих «ынтерпрайзных» дисках.
Простите, что?
Газ в единицах объема измерять — дело крайне неблагодарное.
Есть распространенное мнение что переднее моторколесо на велосипеде — не самая хорошая идея. Давление на переднее колесо небольшое, поэтому потерять сцепление с поверхностью очень легко, а следовательно управляемость велосипеда — это может иметь фатальные последствия.
Серьезно? Каждый день езжу 12 км на «дач-байке» до работы, никакой воды не требуется.
На весь путь уходит минут 40. Это быстрее чем на общественном транспорте.
Хотя не исключаю что это физиологические особенности моего организма, посему экстраполировать на других наверное не совсем корректно.
Те мои сомнения подтвердились — ювелирный воск гораздо сложнее/дороже в производстве чем пластики для 3D-печати.
Производство идет 24 часа в неделю, 365 дней в году, в любую погоду и при любой температуре окружающей среды.
Из чего производят воск — не ясно. Пчелы имхо не промышленный вариант.
Производство натурального пчелиного воска заведомо зависит от кучи условий, причем в ограниченное время — время весеннего цветения.
Первый релиз 2004 год, хотя это по сути плюс-минус опенсорсный форк RHEL-a.
Не понимаю что в нем «новомодного»?
А потом взломают и ее, и будет неприятно.
Именно погружение в языковую среду — компьютерные игры, фильмы, книги и прочее дают именно тот минимальный уровень чтобы начать эффективно общаться на иностранном языке.
Многие повседневные современные фразеологизмы и идиомы в книгах вообще не освещаются, а без них смысл часто теряется в догадках.
А есть еще и акценты — например американский говор в первое время после переезда я понимал без проблем, почти как будто говорят на Русском. Спасибо Голливудским фильмам.
Но например разговор с британцем для меня был пыткой — после 5 минут мозг просто перегружался и переставал интерпретировать звуковые сигналы. Было очень стыдно и неприятно. И только после нескольких недель в одной команде с британцем, после того как мозг адаптировался, я смог нормально с ним коммуницировать :)
Мне наоборот нравится, и стиль неплохо согласуется с содержанием и посылом статьи.
Эта проблема как раз и решается.
А оно и компилируется. Это обычный DSL.
Это совершенно не этот случай, to eq тут написан именно для того чтобы выражение было читабельным, а не убогим дискретным ассертом без контекста и правильной ошибки.
А ну теперь все понятно. Это еще один аспект TDD/BDD который сударь не вкурил. Тесты используются не только для валидации, а так-же как часть процесса разработки и отладки.
Если 5 строчек дают контекст и читабельность — это лучше чем одна ниндзя-строка которая делает все на свете.
Крайне спорное утверждение.
Что легче читать и поддерживать?
или
Да, а еще я код форматирую. Каюсь, виновен — жутко не утилитарно.
1) foo() returns bar
Failure/Error: expect(foo()).to eq('bar')
expected: "bar"
got: "zar"
(compared using ==)
На вкус и цвет все фломастеры разные.
> Никто кроме программистов читать ваши модульные тесты не будет. А программисту лучше читать формально точный програмный код, а не описание «своим языком», которое не полное и зачастую врёт.
В том и дело. «Формально» точный код порой тяжело читать, особенно если нет контекста. Пожалейте коллег.
Описание «своим языком» формально точно так-же «точное», просто написано читаемо.
> Часто, и в данном случае тоже, текстовое описание просто в точности повторяет программный код. В лучшем случае это тавтология, в худшем — описание с кодом разъезжается.
Суть в том чтобы описать поведение кода язком наиболее близким к человеческому. Ваши «точные», но неструктурированные тесты после нескольких итераций превращаются в нечитаемое гуано, в котором без пол-литра не разобраться.
> В конце концов это даже не BDD: ru.wikipedia.org/wiki/BDD_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
без комментариев
> В лучшем случае код тестов может выполнять роль примеров в документации, но заменить её не способен, так как документация должна давать общие правила использования, а тесты — это всегда конкретные примеры с конкретными параметрами. Приведённый мной код вполне себе попадает в документацию. Например: dlang.org/phobos/std_ascii.html#isAlpha github.com/dlang/phobos/blob/master/std/ascii.d#L145
документация без примеров — плохая документация
> Сравнивать значения через метод to eq, когда в языке есть оператор сравнения == — это ничерта не красиво. Это карго-культ «человеческого» языка.
Вот только оператор сравнения `==` в некоторых языках может работать не так как ты ожидаешь.
Смысл использования to eq() не просто в самом сравнении, но и составлении правильного текста ошибки:
1) foo() returns bar
Failure/Error: expect(foo()).to eq('bar')
expected: "bar"
got: "zar"
(compared using ==)
Ну и сударь явно не понимает значения слова «карго-культ».
> Ну да, писать 5 строчек кода в место одной — вот где красота. Впрочем, с критериями «красиво/уродливо» вам стоило в художники пойти, а не в программисты. У программистов должны быть иные приоритеты.
Вы, сударь, видать любитель однострочников. Читаемость и поддерживаемость кода — не последний фактор в software engineering. Мне жалко ваших коллег.
Ну и эстетическая красота — имхо тоже не последняя вещь. С вашим подходом надо всем жить в панельных хрущевках.
Не очень понял смысл вашего примера. Речь топикстартера шла об «уродливости», а не о том чтобы написать самый минималистичный тест.
Суть и смысл BDD в том чтобы описывать поведение языком понимаемым человеком без лишних усилий. Таким образом код тестов может служить одновременно документацией к тестируемому коду.
Ну и это просто красиво. После BDD обычные тесты, с ассертами итп, выглядят уродливо.
Последние пять лет только Тошиба — ни единого разрыва.
А WD и Seagate у меня ассоциируются с долгими часами восстановления RAID массива, «стуками смерти» и прочими радостями. Причем это на дорогущих «ынтерпрайзных» дисках.