Конечно же, в большинстве случаев этот "треугольник" - популярное, но мнимое ограничение. Все проекты и продукты, в которых мне довелось поучаствовать за 20 с лишним лет, могли быть сделаны и быстрее, и качестве, и дешевле. Более того, чаще всего проекты получаются некачественными, потому что делаются долго. Устаревают собранные требования, случаются пандемии и кризисы, да и банально многие важные мелочи забываются, если разработка длится слишком долго. Коротко говоря, в подавляющем большинстве проектов любой параметр можно значительно улучшить, не ухудшая два других
Я вспоминаю. Правда не каждый год и даже не два. Скачиваю, смотрю, пытаюсь пользоваться, привыкнуть, но через пару месяцев сдаюсь и сношу. И так на протяжении уже лет 15
Если надо пройти из точки А в точку Б оптимальным маршрутом, то задача и должна так ставиться. Выбор способа из тысяч - тоже часть решения задачи. Зависит наверно от задачи, но я думаю что вовлечение менеджмента в процесс выбора - это микроменеджмент
"Scrum" (конец 20 века) - по признанию автора метода - это "революционный метод управления проектами"
Это название книжки на русском. Как говорил А. Пименов, здесь ложь в каждом слове. Скрам - это не революционный, не метод, не управления, и не проектами.
Не надо пихать код-ревью в процессы, если без него можно обойтись. Код ревью (даже двойное и тройное) ничего не гарантирует, но зато дорого стоит, дает почву для конфликтов и многодругого нежелательного
устал искать хорошие LED-лампы. перешел на галогенные с двойным цоколем и стандартным патроном e27. Они лишь чуточку экономичнее обычных ламп накаливания — 75вт дают света как 100вт, но свет от них такой же шикарный, CRI=100
У меня некоторые внутренние ресурсы по HTTPS перестали открываться в браузерах Chrome и Safari. Нагугленные свистопляски с добавлением сертификатов в Keychain и выставлением Always Trust не помогли — сейчас браузеры показывают валидную цепочку до ресурса, но браузер открыть их не дает.
Пока пользуюсь Firefox — к счастью там в Advanced пока есть кнопка «сам знаю что безопасно, а что нет»
Я считаю, что лучше обойтись без ORM.
Потому что ORM в каждом языке свой, и часто не один. И часто опыт с одного на другой переносить нельзя.
А SQL везде один и тот же, различия в диалектах незначительны.
Конечно же, в большинстве случаев этот "треугольник" - популярное, но мнимое ограничение. Все проекты и продукты, в которых мне довелось поучаствовать за 20 с лишним лет, могли быть сделаны и быстрее, и качестве, и дешевле. Более того, чаще всего проекты получаются некачественными, потому что делаются долго. Устаревают собранные требования, случаются пандемии и кризисы, да и банально многие важные мелочи забываются, если разработка длится слишком долго. Коротко говоря, в подавляющем большинстве проектов любой параметр можно значительно улучшить, не ухудшая два других
Я вспоминаю. Правда не каждый год и даже не два. Скачиваю, смотрю, пытаюсь пользоваться, привыкнуть, но через пару месяцев сдаюсь и сношу. И так на протяжении уже лет 15
Если надо пройти из точки А в точку Б оптимальным маршрутом, то задача и должна так ставиться. Выбор способа из тысяч - тоже часть решения задачи. Зависит наверно от задачи, но я думаю что вовлечение менеджмента в процесс выбора - это микроменеджмент
Это название книжки на русском. Как говорил А. Пименов, здесь ложь в каждом слове.
Скрам - это не революционный, не метод, не управления, и не проектами.
Не надо пихать код-ревью в процессы, если без него можно обойтись. Код ревью (даже двойное и тройное) ничего не гарантирует, но зато дорого стоит, дает почву для конфликтов и много другого нежелательного
Бывают и рефлекторные ксеноновые, бывают линзованные галогенные.
Алексей, скоро начало учебного года, тест настольных светодиодных ламп для школьников был бы очень кстати ;)
Спасибо, давно присматриваюсь к такого рода устройствам.
Да, "метрики переоценены".
Пока пользуюсь Firefox — к счастью там в Advanced пока есть кнопка «сам знаю что безопасно, а что нет»
Я считаю, что лучше обойтись без ORM.
Потому что ORM в каждом языке свой, и часто не один. И часто опыт с одного на другой переносить нельзя.
А SQL везде один и тот же, различия в диалектах незначительны.