В большинстве инженерных областей изготовление изделия (или стоимость отказа изделия) значительно дороже его проектирования. В таких условиях имеет смысл максимально оптимизировать производство автомобилей, т.к. каждая сэкономленная гайка умножается на кол-во произведенных авто. Аналогично с архитектурой — построить дом куда дороже, чем спроектировать.
В IT все наоборот — разработка "по аджайлу" относительно дешевая, а вот проектирование и верификация — очень дороги. Как в пословице про дурака, реку и камень — один закодил, десятеро протестировать не могут.
Об оптимизации беспокоятся только те, кто сам платит за железо: прежде всего производители устройств на микроконтроллерах и владельцы облаков из сотен и тысяч машин.
Решение для написания асинхронного кода в промышленных масштабах уже придумано — Future/Promise. Конечно, это сложнее, чем синхронный код, но значичельно проще коллбэков а-ля node.js или изменяемого состояния + события а-ля Netty.
Проблем с интеграцией с синхронным кодом тоже нет — просто нужно помнить, что параллелизация синхронного кода ограничена количеством потоков в тредпуле.
Разве разработчики не делают rebase целевой ветки (master/development) в свой PR перед сабмитом на ревью? Тогда свежий PR гарантированно мерджится без конфликтов.
Ну реально странная статья — при репосте как раз юридическая сторона очевидна — публичные призывы к экстремисткой деятельности (тексты) или публичное распространение экстремистких материалов (картинки).
в 2012 году Витольда Филиппова, активиста татарского отделения националистической партии «Российский общенародный союз», оштрафовали на 1000 рублей (уголовное дело)
Обилие моков в тестах — признак плохого дизайна. Юнит-тесты должны тестировать логику, а логика по-возможности должна быть вынесена в отдельные функции, у которых нет внешних зависимостей. На эти функции и нужно писать юнит-тесты.
В большинстве инженерных областей изготовление изделия (или стоимость отказа изделия) значительно дороже его проектирования. В таких условиях имеет смысл максимально оптимизировать производство автомобилей, т.к. каждая сэкономленная гайка умножается на кол-во произведенных авто. Аналогично с архитектурой — построить дом куда дороже, чем спроектировать.
В IT все наоборот — разработка "по аджайлу" относительно дешевая, а вот проектирование и верификация — очень дороги. Как в пословице про дурака, реку и камень — один закодил, десятеро протестировать не могут.
Об оптимизации беспокоятся только те, кто сам платит за железо: прежде всего производители устройств на микроконтроллерах и владельцы облаков из сотен и тысяч машин.
Решение для написания асинхронного кода в промышленных масштабах уже придумано — Future/Promise. Конечно, это сложнее, чем синхронный код, но значичельно проще коллбэков а-ля node.js или изменяемого состояния + события а-ля Netty.
Проблем с интеграцией с синхронным кодом тоже нет — просто нужно помнить, что параллелизация синхронного кода ограничена количеством потоков в тредпуле.
Всё придумано до нас — это называется "кооперативная многозадачность" — https://en.wikipedia.org/wiki/Cooperative_multitasking
Разработчикам ОС проще, у них есть прямой доступ к стеку и аппаратная поддержка переключения контекстов.
Есть такое — https://aws.amazon.com/glacier/
Запись недорогая, хранение очень дешевое, а вот за чтение снимут последние штаны.
Отсутствие дискриминации по-европейски:
Фото токаря в принципе неправильное, а не только по пятницам.
Волосатое, до первой горячей стружки в голову.
И без очков, что вообще жесть.
gcc так и компилируется — в два этапа. Сначала системным компилятором, потом он пересобирает сам себя.
https://ru.wikipedia.org/wiki/Раскрутка_компилятора
В настоящее время, когда девопс борятся за лишние минуты и секунды turnaround-а, ждать ревью сутки — какая-то средневековая дикость.
Разве разработчики не делают rebase целевой ветки (master/development) в свой PR перед сабмитом на ревью? Тогда свежий PR гарантированно мерджится без конфликтов.
Не думали о том, что в случае конфликта мерджить должен ревьювер?
Очень хорошо мотивирует рассматривать PR вовремя.
А кто у вас мерджит PR в случае конфликтов — разработчик или ревьювер?
В малых компаниях сплошь и рядом
Старожилы должны помнить огромный сборник ляпов на bugtraq — "Бред сивой кобылы".
https://bugtraq.ru/bred/
Очевидно же — раньше сомнительные методы работали.
Ну реально странная статья — при репосте как раз юридическая сторона очевидна — публичные призывы к экстремисткой деятельности (тексты) или публичное распространение экстремистких материалов (картинки).
Порывшись в интернете, нашел приговор в тему: https://rospravosudie.com/court-sudebnyj-uchastok-6-mirovogo-sudi-g-staryj-oskol-belgorodskoj-oblasti-s/act-221616632/
Имеет смысл прочитать для понимания, как и за что.
https://news2.ru/story/359823/
Политика, пропаганда и вранье — это лучше на какой-нибудь другой ресурс.
По этому шаблону делаются ВСЕ сайты программных продуктов на западе. Список "выгод" с картинками, а что именно предлагается — непонятно.
Обилие моков в тестах — признак плохого дизайна. Юнит-тесты должны тестировать логику, а логика по-возможности должна быть вынесена в отдельные функции, у которых нет внешних зависимостей. На эти функции и нужно писать юнит-тесты.
ACDSee 3.11 же!
Для этой цели лучше использовать Service Worker:
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API