Вы просто поймали уникальный момент, когда произошла смена тренда. Я так i7-8700k в первый день продаж заказал до дефицита, и он потом ещё год дороже был, и в 22 году со многой техникой в рф можно было такое поймать - но это скорее исключение из правил, и такое бывает относительно редко. Ну и даже если так - можно смотреть бу рынок, где цена будет ниже а в случае с большинством комплектухи - на качестве не скажется
Мысли здравые, но при этом очевидные. Да - намного выгоднее при обновлении отстовать от актуала примерно на год. При выходе нового флагмана - предидущий теряет 30-40% цены, но остаётся отличным, годовалый контент продаётся со скидкой в те-же 30-40%.
Мы использовали matrix - там не 5 минут, а несколько дней. Но это не единсвенная библиотека, когда мы выбирали матрикс было еще 5 или 6 кандидатов котороые отфильтровали.
Магия в том - что нам не потребовалось изначально разрабатывать чат с нуля, чтобы потом героически его переносить)
Просто на 9 из 10 проектов у менеджмента обычно нет лишних человекочасов разработчиков, чтобы делать очередную тудушку для мобилок, или заниматься перетрубациями с2с в б2б - хотя для этого, как будто разделяемой кодовой базы не нужно и причем тут это вообще непонятно. Им бы продуктовые фичи вместить, которые приносят прибыль. Так что дело тут не втом, что кто-то не умеет)) Да и реально разделяемые задачи - ужасная редкость. Не нужно в каждом приложении писать свой механизм рисования графиков, свой чат и downloader а потом героически шарить их между проектами - достаточно взять либу) А продуктовые экраны связанные с конкретными продуктами - комерческие предложения, карточки контента, корзины и прочие флоу подключения услуг или предоставления фичей - обычно специфичны и шарить их невозможно. Реальные исключения которые я видел - супераппы, и миниапы для каждой из фичей суперапа, но там тоже не нужно по сути шарящейся кодовой базы
В целом с критикой клина согласен. Но вот конкретно с тезисом что по клину необходимо в каждом слое писать свою копию дата классов и связывать их мапперами - не согласен. Если ваша логика так проста, что данные во всех слоях одинаковы - вам достаточно дата сущности в domain о котором знают все, а значит все могут использовать (вспоминаем что domain в клине считается самым стабильным и неизменяемым слоем), а если у вас ui сущности отличаются, и на бекенде отличаются - тут уж хочешь не хочешь - мапперы где-то будут, и изолировать ui от источника данных маппером всё равно придётся.
Мне кажется про это автор упомянул в исключених. Я согласен с вами что пример возможен, но и с автором что если он возможен - вы будете знать об этом заранее и оправдать этим использование clean.
В 9 из 10 команд где я работал - был либо 1 продукт, либо 2 настолько разных продукта, что перерисовать кода все равно в них не имело смысла, там просто не может изниоткуда возникнуть внезапно второй продукт с кривыми придётся шерить кодовую базу.
Разделить бизнес логику на слои, создать правильную структуру каталогов, файлов, правильные направления связей, закрыть реализации за интерфейсы там где это подразумевается разделением на слои, правильно сделать иньекцию зависимостей (а по хорошему завести и настроить di библиотеку), разделить данные на куски таким образом, чтобы предоставлять везде необходимый минимум. Архитектура подразумевет декомпозицию и изоляцию - а это вещи не бесплатные.
С одной стороны мы говорим пиши просто, а с другой - пиши с качественной архитектурой, и мол это одно и тоже на длиной дистанции, но это вообще далеко не всегда так.
У меня есть pet проект где код пишется за 2 часа вечером, очень быстро, и архитектуры там вообще 0, а подход называется проще выбросить и написать по новой - но для этого проекта это лучше решение, а есть рабочий проект - и там все чинно и архитектурно.
Если бы я на pet взял подход как на рабочем - то одно развертывание архитектуры заняло бы у меня больше времени, чем весь проект сейчас, и окупилось бы в лучшем случае в следующей жизни.
"Веб-сервисы и приложения по умолчанию считают, что ты работает из доверенной для себя сети и доверенного устройства. "
Это в каком мире? мне казалось что у нас повальный https как раз потому, что любая сеть недоверенная))
Вообще я не понял тезис про то, что пользователю подсовывают фейковую страницу, он пытается зайти, вводит логин и пароль, и получает необходимость подтвердить вторым фактором вход - что ему помешает подтвердить вход вторым фактором?)
Если я правильно помню - в произведении Жюль Верна - таинственный остров, упрощенно но вполне доходчиво рассказывается как из подручный материалов доступных на необитаемом острове получить взрывчатку)) и как минимум часть ингридиентов можно купить уже готовыми в магазине.
Даже жалко - такая красиво оформленная и детальная статья, и такие тривиальные примеры которые в каждой доке к orm/sql в первом примере "как делать не надо" описаны. Особенно если учесть замах в заголовке.
Да, когда работаешь с sql бд и орм - каждый запрос стоит дорого, чем больше запросов соединишь в 1 - тем дешевле будет запрос. По этому запросы в цикле - красный флаг.
И понятно что разбирать json запросе дороже, чем не разбирать, и использовать для выборки его будет уже намного сложнее))
Эти тезисы должны быть очевидны студенту второго курса универа и как будто не заслуживают статьи
Во всех подобных решениях до этого (что xamarin, что flatter, что react native) всегда было две беды - по этому про них интересно.
1 - это протекание абстракций - когда у тебя на серьезном проекте обнаруживается бага, протекшая в нативный код, так еще и на одной платформе, и ты неделями её дебажишь - тут такого не встречали? Лог ошибок всегда понятен и место их возникновения?
2 - когда на разных платформах есть разные возможности - то в суммарной версии нет никаких. Если нам надо работать с фоновыми задачами (при свернутом приложении), планировать отложенную активность, показывать нотифткации - надо будет все равно съезжать к нативному для платформы коду? И насколько болезненно взаимодействие на ios между котлин и swift?
Тут надо определиться мы про доказательное программирование говорим или про рациональность его применения.
Для меня статья выглядит как осуждение автомобиля, за то что в городе нет дорог.
Если в твоём городе нет дорог - очевидно что автомобиль тебе не подходит, но это не "миф об автомобиле" - как в заголовке статьи)
Если для конкретной задачи ошибка из за попадания космических лучей или сбоя физики процессора критична, это не значит что доказательное программирование плохо или не работает)
Мне всегда казалось что доказательное программирование - это не про этап выполнения а про результат компиляции. Что мы можем доказать, что на процессоре, как машине тьюринга, скомпилированный код приведёт к корректному ответу на корректных входных данных.
А это все уже доказывается на уровне математики - программа превращается в конечный автомат и доказывается соотвествие входных состояний выходным. (Ну это как я себе это вижу, скорее всего эксперты опишут это намного адекватнее)
А ошибки на уровне физики процессора или уж крайне маловероятное попадание космических лучей - это не про программирование вообще, а про риск менеджмент - в конце концов на ваш компьютер кирпич может упасть, но причём тут программирование?
Не понимаю почему все напали на автора - из за телеги чтоли. Он даёт местами очевидные, но адекватные рекомендации жеж. Декомпозиция задачи на микроподзадачи, регулярные тренировки и поиск причин ошибок - как будто абсолютная база которая подойдёт для здорового человека.
Не сомневаюсь, что есть люди которые могут съесть слона целиком, схватывают с первого раза, но и им данные советы не повредят.
С серфигом веба нормально справляется железо 12 летней давности (i5 3500k + 8gb озу ddr3 + ssd), даже без дискретного видео
Вы просто поймали уникальный момент, когда произошла смена тренда. Я так i7-8700k в первый день продаж заказал до дефицита, и он потом ещё год дороже был, и в 22 году со многой техникой в рф можно было такое поймать - но это скорее исключение из правил, и такое бывает относительно редко. Ну и даже если так - можно смотреть бу рынок, где цена будет ниже а в случае с большинством комплектухи - на качестве не скажется
Правильными заголовком было бы - cherry представила мышь с микрофоном, но так аудиторию не заинтересуешь) а так - мусор
Мысли здравые, но при этом очевидные. Да - намного выгоднее при обновлении отстовать от актуала примерно на год. При выходе нового флагмана - предидущий теряет 30-40% цены, но остаётся отличным, годовалый контент продаётся со скидкой в те-же 30-40%.
Мы использовали matrix - там не 5 минут, а несколько дней. Но это не единсвенная библиотека, когда мы выбирали матрикс было еще 5 или 6 кандидатов котороые отфильтровали.
Магия в том - что нам не потребовалось изначально разрабатывать чат с нуля, чтобы потом героически его переносить)
Просто на 9 из 10 проектов у менеджмента обычно нет лишних человекочасов разработчиков, чтобы делать очередную тудушку для мобилок, или заниматься перетрубациями с2с в б2б - хотя для этого, как будто разделяемой кодовой базы не нужно и причем тут это вообще непонятно. Им бы продуктовые фичи вместить, которые приносят прибыль. Так что дело тут не втом, что кто-то не умеет))
Да и реально разделяемые задачи - ужасная редкость.
Не нужно в каждом приложении писать свой механизм рисования графиков, свой чат и downloader а потом героически шарить их между проектами - достаточно взять либу)
А продуктовые экраны связанные с конкретными продуктами - комерческие предложения, карточки контента, корзины и прочие флоу подключения услуг или предоставления фичей - обычно специфичны и шарить их невозможно. Реальные исключения которые я видел - супераппы, и миниапы для каждой из фичей суперапа, но там тоже не нужно по сути шарящейся кодовой базы
В целом с критикой клина согласен. Но вот конкретно с тезисом что по клину необходимо в каждом слое писать свою копию дата классов и связывать их мапперами - не согласен. Если ваша логика так проста, что данные во всех слоях одинаковы - вам достаточно дата сущности в domain о котором знают все, а значит все могут использовать (вспоминаем что domain в клине считается самым стабильным и неизменяемым слоем), а если у вас ui сущности отличаются, и на бекенде отличаются - тут уж хочешь не хочешь - мапперы где-то будут, и изолировать ui от источника данных маппером всё равно придётся.
Мне кажется про это автор упомянул в исключених. Я согласен с вами что пример возможен, но и с автором что если он возможен - вы будете знать об этом заранее и оправдать этим использование clean.
В 9 из 10 команд где я работал - был либо 1 продукт, либо 2 настолько разных продукта, что перерисовать кода все равно в них не имело смысла, там просто не может изниоткуда возникнуть внезапно второй продукт с кривыми придётся шерить кодовую базу.
Разделить бизнес логику на слои, создать правильную структуру каталогов, файлов, правильные направления связей, закрыть реализации за интерфейсы там где это подразумевается разделением на слои, правильно сделать иньекцию зависимостей (а по хорошему завести и настроить di библиотеку), разделить данные на куски таким образом, чтобы предоставлять везде необходимый минимум. Архитектура подразумевет декомпозицию и изоляцию - а это вещи не бесплатные.
Сижу я такой, читаю статью на dtf а оказывается это хабр о.О
7 пункт как-то не согласуется с 1/2.
С одной стороны мы говорим пиши просто, а с другой - пиши с качественной архитектурой, и мол это одно и тоже на длиной дистанции, но это вообще далеко не всегда так.
У меня есть pet проект где код пишется за 2 часа вечером, очень быстро, и архитектуры там вообще 0, а подход называется проще выбросить и написать по новой - но для этого проекта это лучше решение, а есть рабочий проект - и там все чинно и архитектурно.
Если бы я на pet взял подход как на рабочем - то одно развертывание архитектуры заняло бы у меня больше времени, чем весь проект сейчас, и окупилось бы в лучшем случае в следующей жизни.
"Веб-сервисы и приложения по умолчанию считают, что ты работает из доверенной для себя сети и доверенного устройства. "
Это в каком мире? мне казалось что у нас повальный https как раз потому, что любая сеть недоверенная))
Вообще я не понял тезис про то, что пользователю подсовывают фейковую страницу, он пытается зайти, вводит логин и пароль, и получает необходимость подтвердить вторым фактором вход - что ему помешает подтвердить вход вторым фактором?)
Если я правильно помню - в произведении Жюль Верна - таинственный остров, упрощенно но вполне доходчиво рассказывается как из подручный материалов доступных на необитаемом острове получить взрывчатку)) и как минимум часть ингридиентов можно купить уже готовыми в магазине.
Но получается у вас для виджетов две версии кода - для ios и андроид отдельно?
Интересные данные, ещё бы выводы какие нибудь)
Даже жалко - такая красиво оформленная и детальная статья, и такие тривиальные примеры которые в каждой доке к orm/sql в первом примере "как делать не надо" описаны. Особенно если учесть замах в заголовке.
Да, когда работаешь с sql бд и орм - каждый запрос стоит дорого, чем больше запросов соединишь в 1 - тем дешевле будет запрос. По этому запросы в цикле - красный флаг.
И понятно что разбирать json запросе дороже, чем не разбирать, и использовать для выборки его будет уже намного сложнее))
Эти тезисы должны быть очевидны студенту второго курса универа и как будто не заслуживают статьи
Во всех подобных решениях до этого (что xamarin, что flatter, что react native) всегда было две беды - по этому про них интересно.
1 - это протекание абстракций - когда у тебя на серьезном проекте обнаруживается бага, протекшая в нативный код, так еще и на одной платформе, и ты неделями её дебажишь - тут такого не встречали? Лог ошибок всегда понятен и место их возникновения?
2 - когда на разных платформах есть разные возможности - то в суммарной версии нет никаких. Если нам надо работать с фоновыми задачами (при свернутом приложении), планировать отложенную активность, показывать нотифткации - надо будет все равно съезжать к нативному для платформы коду? И насколько болезненно взаимодействие на ios между котлин и swift?
Тут надо определиться мы про доказательное программирование говорим или про рациональность его применения.
Для меня статья выглядит как осуждение автомобиля, за то что в городе нет дорог.
Если в твоём городе нет дорог - очевидно что автомобиль тебе не подходит, но это не "миф об автомобиле" - как в заголовке статьи)
Если для конкретной задачи ошибка из за попадания космических лучей или сбоя физики процессора критична, это не значит что доказательное программирование плохо или не работает)
Мне всегда казалось что доказательное программирование - это не про этап выполнения а про результат компиляции. Что мы можем доказать, что на процессоре, как машине тьюринга, скомпилированный код приведёт к корректному ответу на корректных входных данных.
А это все уже доказывается на уровне математики - программа превращается в конечный автомат и доказывается соотвествие входных состояний выходным. (Ну это как я себе это вижу, скорее всего эксперты опишут это намного адекватнее)
А ошибки на уровне физики процессора или уж крайне маловероятное попадание космических лучей - это не про программирование вообще, а про риск менеджмент - в конце концов на ваш компьютер кирпич может упасть, но причём тут программирование?
Не понимаю почему все напали на автора - из за телеги чтоли. Он даёт местами очевидные, но адекватные рекомендации жеж. Декомпозиция задачи на микроподзадачи, регулярные тренировки и поиск причин ошибок - как будто абсолютная база которая подойдёт для здорового человека.
Не сомневаюсь, что есть люди которые могут съесть слона целиком, схватывают с первого раза, но и им данные советы не повредят.