requests где конкретно лежит? не в сабмодуле?

Отдельно библиотеку и сорцы

Потом линковать

Но, как я понимаю, если в сборке финального файла флагом dmd будет cov, то все входящие в эту сборку файлы будут покрыты

requests где конкретно лежит? не в сабмодуле?

http://vibed.org/api/vibe.http.server/

vibe:http подключен отдельно?

хоть отдельно хоть нет он в любом случае тянется весь vibe

нет не тянет

и вопрос: а покрытие чего надо измерить?

нет не тянет

Для скачивания тянет

ну это пофиг

вот в чем вся беда

-cov ломает все

время переезжать на vibe 0.8.3

у меня есть пакеты которые покрытие используют и vibe - ничего не ломается

так что давайте компилятор и вайб обновим сначала

и dub clean разный там сделаем

И вообще .dub и dub.selections.json удалить ещё надо)

ок, попробую обновиться

все равно умирает, ну да ладно, хер с ним, все равно спасибо

подожди, надо добивать вопрос

это явно какой-то баг

удали из .dub vibe

может там что-то собрано не так как надо

.dub я весь удалил

Надо полностью ошибку смотреть, дело в неправильном видимо вызове performLocked

в текстовом виде полностью скопипасти

в тексте ща

да ладно

так не должно быть. расскажи как собираешь? dub файл какой? ключи комстроки?

в dub'e только dependencies и "dflags-dmd": ["-version=test1"],. дальше просто dub build —build=cov

надо задать вопрос, это может быть багом где-то в vibe

хорошо, как освобожусь займусь

фак, я даун, обновил dmd с 077 до 079,но забыл активировать.С 079 все норм собирается

АКТИВИРОВАТЬ?

source ~/dlang/dmd activate типа того

Прошлый остался

TDD на сколько в жизни применим? Тест драйвен девелопинг который

TDD на сколько в жизни применим? Тест драйвен девелопинг который

разумная середина ок как по мне

недавно обсуждали тут с Олегом

кратко: ты не знаешь что пишешь потому не можешь результаты до написания проверять

обычно

Ты имеешь в виду ортодоксальный TDD когда обязательно тесты пишут _перед_ кодом или просто когда весь код покрывают тестами?

в книжках Боба Мартина всё красиво выглядит, а на практике, почему-то, превращается в ад)

может, готовить не умею

в книжках Боба Мартина всё красиво выглядит, а на практике, почему-то, превращается в ад)

Если честно сперва подумал что эта фраза про ООП ;)

Конкретно написание теста перед кодом - у меня не особо прижилось, но я читал довольно вдохновляющую статью в которой намекается что если практиковаться то можно прийти к успеху

Когда сперва пишут тесты. Но я хз как можно вообще так Разрабатывать

У меня коллега уверяет что только так и надо

Ну вот так, сверху вниз )

Сначала ты начинаешь писать код пустышку на самом верхнем уровне, как бы ты хотел пользоваться искомой системой классов. Отсюда становится виден контракт - набор публичных методов.

TDD на сколько в жизни применим? Тест драйвен девелопинг который

Хз, для TDD вообще весь процесс разработки должен быть отлажен. Дескать пишите вы такие на java, предметная область совершенно ясна, в проекте есть архитектор, который уже придумал архитектуру, ты такой налисточке прописал свои интерфейсы, написал к ним тесты - начал постепенно реализовывать. Ляпота. И реальность, где ты понимаешь что пишешь, только когда уже написал... Я ратую за параллельное написание: дескать пишем код и тесты одновременно, если тесты выходят вперед - отлично, у нас TDD, если нет, то значит мы мало понимаем какую архитектуру хотим, а лучший способ понять это - написать еще немножко кода.

Блин, но разве так можно? Я крайне редко даже представляю какие мне методы потребуются

Хз, для TDD вообще весь процесс разработки должен быть отлажен. Дескать пишите вы такие на java, предметная область совершенно ясна, в проекте есть архитектор, который уже придумал архитектуру, ты такой налисточке прописал свои интерфейсы, написал к ним тесты - начал постепенно реализовывать. Ляпота. И реальность, где ты понимаешь что пишешь, только когда уже написал... Я ратую за параллельное написание: дескать пишем код и тесты одновременно, если тесты выходят вперед - отлично, у нас TDD, если нет, то значит мы мало понимаем какую архитектуру хотим, а лучший способ понять это - написать еще немножко кода.

+++

Блин, но разве так можно? Я крайне редко даже представляю какие мне методы потребуются

Откуда ты тогда эти методы берешь впринципе?

Ну я по ходу решения проблемы придумываю

У тебя возникает какая-то потребность в процессе разработки, и ты понимаешь что нужен метод. Вот если эти потребности сесть и продумать перед тем как работать, то получится готовый интерфейс.

И тесты пиши по ходу решения проблемы, а если получится и ещё немного забегай вперёд)

Kent Beck, который это все придумал, говорил, что ему просто сложно начинать писать имплементацию сразу. А начиная с тестов ему проще преодолевать инерцию/прокрастинацию. Все остальные плюсы, уже походу придумали

Fun Fact №3: Про D написано в ArchWiki https://wiki.archlinux.org/index.php/D

о даа, оч сложно преодолеть прокрастинацию) у меня 4 пет проекта, и чет сложно именно начать писать (когда начал уже едешь норм)

особенно когда работаешь на работе не особо связанной с программированием :)

Хз, для меня куда сложнее начать что-то и закончить

ну я и говорю сложно начать

ERROR: S client not available

Я имел ввиду, довести проект до конца)

Кто-нибудь знает, что за штука dustmite?

Я имел ввиду, довести проект до конца)

+, столько незаконченных проектов ?

+, столько незаконченных проектов ?

У меня они аж гб отхавали)

а я вот люблю полировать проекты. даж профилированием занимаюсь, через валграйнд прогоняю (которые на си пишу)

Перфекционизм?)

А что потом с ними происходит?

Впринципе между законченным проектом и незаконченным отложенным поначалу нет разницы. Оба лежат на полочке и никому не нужны

Ну...

Первый лежит в моей папке

на работе работает норм. там стыдно показывать что-то наспех сделанное

А второй - на гитхабе

Так что разница есть

за законченный звездочки летят?)

за законченный звездочки летят?)

Только если от друзей)

за законченный звездочки летят?)

Хз. У меня их нет

И того, и того

Оп, dustmite походу крутая штука

Созданная, что бы уменьшать код

(C сохранением ошибки)

У меня коллега уверяет что только так и надо

Привыкай вертеть на хую даже авторитетов. Во всякого рода математиках и ИТ это сплошь и рядом же.

Фигурально выражаясь

/me опять накатил, как можно догадаться

Сначала ты начинаешь писать код пустышку на самом верхнем уровне, как бы ты хотел пользоваться искомой системой классов. Отсюда становится виден контракт - набор публичных методов.

Это плохой подход с точки зрения конечной производительности

Привыкай вертеть на хую даже авторитетов. Во всякого рода математиках и ИТ это сплошь и рядом же.

Красиво сказано

Почему?

Это плохой подход с точки зрения конечной производительности

Продуктовой или инженерной?

Продуктовой или инженерной?

Конечной

Почему?

Ну потомучто закон Мерфи

щас найду точно формулировку

Конечной

Такой не бывает. Можно быстро сделать медленный продукт или медленно сделать быстрый продукт. Или еще 2 кобминации.

Законы Мэрфи: Искусство быть специалистом Следствие Вейнберга Квалифицированный специалист - это человек, который удачно избегает маленьких ошибок, неуклонно двигаясь к какому-нибудь глобальному заблуждению.