аналогично, MessagingService и NotificationsSerivce (в примере из статьи), можно тестировать отдельно, а для метода SendMessage зафигачить интеграционный тест. однако лирический герой ратует за то, чтобы непременно тестить освещение не зависимо от реализации конкретных компонентов, для чего наваял DI с конструктором и пачкой новых интерфейсов "… не обусловленных ни какой семантикой".
это так же гибко и правильно, как если в квартире каждый светильник включать через вилку-розетку. и теперь весь сыр-бор вокруг подключения потолочной люстры — когда тестировщикам ужас как хочется заместо неё втыкать свои имитаторы, а хозяевам нафиг не нужно что-то вместо неё подключать и вообще портит интерьер. :)
VIM c ctags (пусть wrangler если это erlang) решают задачу в 95% случаев. остальные 95% кода все равно лапками проверять. не понимаю с чем вы не согласны.
я хотел сказать, что в реальных проектах, возможности языка используются на полную катушку — со всяким мета-программированием, и прочей ерундой, которая делает язык именно таким, за что мы его и выбираем, а статический анализ — лишь приятной примочкой (типа на PEP8 чекать). автоматический рефакторинг в каких-то частных случаях тоже возможен, но поменять мегабайт индуистического кода неглядя, как для Java — это фантастика (или безумие).
угу. только при чем тут Java, если статья конкретно про Erlang?
в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
по-моему зря этот Джо сюда Java прилепил, она совсем из другой оперы, и отсюда холивар весь.
кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?
мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
Спасибо за интересную драму про менеджера Егора. Я искренне ему сопереживал на протяжении всей статьи, в надежде, что все закончится хорошо. Единственная досада, что почти детективная интрига с отчетами, обозначенная в завязке, осталась так и не раскрытой, а заявленный алгоритм описывается на примере каких-то совершенно иных, не связанных между собой ситуаций.
Поэтому сюжет, в целом, показался каким-то не логичным, и быть может надуманным, даже. С первого взгляда, такая непоследовательность выглядит либо как недоработка сценария (если это литература), либо как притягивание фактов за уши к теории (если речь про науку). Если только оставлять сюжетную интригу не раскрытой это какая-то специальная особенность маркетинговой публицистики. В общем, не понятно, стоит-ли того же ожидать на ваших курсах, или в отличие от статьи, там все четко разложено по полочкам?
нестандартная реализация создает лишние сложности и сильно ограничивает кейсы их применимости (https://github.com/domenic/chai-as-promised/issues/1, например). поэтому — да, кривой. программисты с исторического факультета могут искать применение, но с практической точки зрения, чем раньше отправят в кунсткамеру это недоразумение, тем лучше — на сегодняшний день стандарт это реальность.
по примерам не понятно, как считать площадь фигур, в итоге, и каким образом преобразованный код иллюстрирует LSP, если ни наследования, ни полиморфизма в нем не осталось?
может вы смотрели, какие именно операции приводят к увеличению потребления памяти (выбор файлов в диалоговом окне, чтение в FileObject через readAsDataURI(), добавление картинки в DOM и т.п.)?
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
едва успели выпилить из браузера одно чудо-юдо, как другим уже не терпится запилить туда css с variables и calc.
кажется. что в купе с правилами применения каскадов, наследования (в понимании css), анимаций и традиционными вендор-специфичными глюками это должно стать умопомрачительным в отладке механизмом — или они таким способом хотят готовить персонал для программирования квантовых компьютеров?)
по-разному бывает. бывает, что разработчики в состоянии аффекта действительно забыли про какую-то важную штуку, например, про третье колесо для детского велосипеда — тогда да, надо половину рамы перекраивать. а иногда пытаются фонарик к рулю приделать методом всепроникающей диффузии, вместо того, чтобы заимплементить сей девайс с интерфейсом стандартного хомута. еще говорят, что сервисы это не ооп, поэтому понятие интерфейса к ним применимо лишь чисто условно.
в этом цирке «Станый Метод» может быть запросто результатом чего-то в роде string:concat(X, Y), или того хуже. это совсем другой мир, где от AST толку чуть. распоследние тулзы пытаются даже код выполнять, но у и этого подхода есть принципиальные ограничения.
кто-то может привести пример инструментария для языков с _динамической_ типизацией где всякие go to definition и find all references, дают сколь-нибудь существенное отличие в надежности результата, по сравнению с «тупым грепом»?
мне вот не попадались еще. поэтому да, на первый план, так или иначе, выходит удобство редактирования и «vim» — наше всё. остальные трюки приходится делать лапками и внимательно проверять глазками.
Поэтому сюжет, в целом, показался каким-то не логичным, и быть может надуманным, даже. С первого взгляда, такая непоследовательность выглядит либо как недоработка сценария (если это литература), либо как притягивание фактов за уши к теории (если речь про науку). Если только оставлять сюжетную интригу не раскрытой это какая-то специальная особенность маркетинговой публицистики. В общем, не понятно, стоит-ли того же ожидать на ваших курсах, или в отличие от статьи, там все четко разложено по полочкам?
хочу понять, имеет-ли все это смысл, если оригиналы терять нельзя — например для последующей отправки их на сервер — и какую стратегию лучше выбрать.
кажется. что в купе с правилами применения каскадов, наследования (в понимании css), анимаций и традиционными вендор-специфичными глюками это должно стать умопомрачительным в отладке механизмом — или они таким способом хотят готовить персонал для программирования квантовых компьютеров?)
:)