Моему бюджетному Redmi Note 10 Pro 2,5 года, но на нем 13-ая версия ОС, кто знает, может и новую докатят. Проблема не в Андроиде, проблема в конкретных вендорах.
1,5 сотки -- это участок под фундамент хорошего дома. Под парковку, цветник и беседку нужно еще 4,5 хотя бы. В таком можно жить, остальное это уже курятник какой-то
Чтобы time-to-market был минимальным, нужно параллелизовывать работы как можно круче. Чтобы программистов привлекали к проработке задачи как можно раньше, чтобы программисты всех частей (бэк, фронты, хер знает кто еще) в первую очередь согласовывали между собой контракт, а потом уже начинали что-то делать, естественно параллельно, чтобы опсы заранее знали о крупных фичах и планировали инфраструктурные апгрейды под релизы как можно раньше, чтобы тестировщики начинали накидывать тест-кейсы когда задача спроектирована, а не когда разработка закончила, чтобы техподдержка так же была в курсе того, что ее вскоре ожидает, могла как-то к этому подготовиться, например внести какие-нибудь предложения по разработке дополнительного тулинга для них.
А микросервисы к time-to-market докидывают не так уж много, по сравнению с монолитом: простые миграции хранилищ, да возможность без лишних согласований завезти нужные версии инструментов и библиотек, это важно, но с этим сталкиваешься далеко не на каждой фиче. Возможность говнокодить в микросервисе и вовсе может сыграть злую шутку при его разрастании. MSA -- это не про размеры сервисов, это про микроинтерфейсы к сущностям и необходимый минимум ручек для каждой из них. Их может быть три-пять, но с таким адом внутри, что лучше было не говнокодить с самого начала.
А какие вообще плюсы использования фласка с 2023 году по сравнению с тем же FastApi? Особенно доставила книга Flask Framework Cookbook, рассказывающая о Фласке и Питоне пятилетней давности, ну камон.
Большое спасибо за статью! Я правильно понял, что у вас там прокрался копипаст и в делении на типы СТО по этапам развития компании, на этапе департаментов должен быть cTO, то есть главный инженер, то есть такой человек, который уже не лезет в текучку конкретных департаментов? Было бы интересно еще почитать какие карьерные треки возможны для каждого из перечисленных типов (хотя для CTo и сTo понятно).
В долгосрочной перспективе техническая экспертиза миддла и сеньора как раз таки выравняется как за счет того, что техническую экспертизу не будет времени качать и все устаканится ровно на том уровне, чтобы задавать рядовым инженерам, техлидам и архитекторам вопросы, которые помогут осмотреть проблему со всех сторон. Первое, что должен сделать нормальный миддл инженер став тимлидом, это выбрать/назначить техлида/ов, если не хочется сгорать, постоянно пытаясь в личных овертаймах подтягивать экспертизу.
То есть мой поинт такой: если команда слабая и нужно срочно закрыть дырки, то с тимлидом-бывшим-сеньором команда конечно будет эффективнее, но в более-менее зрелых компаниях или отдельных командах, глубина экспертности тимлида не будет столь уж значимой, важны будут другие качества, это другой трек развития.
В тимлиды прекрасно переходится из миддл инженера. Технических знаний этой позиции должно хватать, чтобы занять эту позицию, а для решения людских взаимодействий и улучшения рабочих процессов нужны уже другие навыки. А сеньоры дальше растут по другому треку
Суть в том, что мы даем обещание выдать бизнес-результат к определенному сроку и за фиксированный бюджет, но договариваемся, что объем работы будет "плавающий".
FFF классный. Бюджет фиксирован, время фиксировано и мы просто сдаем в аренду свою команду, которая умеет делать качественно, но когда сделаем MVP не говорим. Кажется это вообще не про создание MVP в его базовом понимании, потому что он нужен ровно для того, чтобы протестировать какую-нибудь гипотезу, и если она не сработает -- то выбросить код без сожаления.
А откуда инфа, что на дорогах становится хуже и хуже? Статистика с сайта ГИБДД как-то не подтверждает. Конечно не так уж радостны абсолютные цифры, но тенденция на лицо.
Захватить за два года, довольно амбициозно, с учетом того, что еще не зарелизились. Наша компания несколько месяцев как переехала в Пачку, сыровато конечно, но чуваки растут по функционалу очень хорошо.
Вот тут можно порисовать графики самому. Это коэффициент фертильности по миру. Для того, чтобы мы не вымирали, каждая женщина должна рожать по 2.1 ребенка, на графике зеленый пунктир.
Да нет никаких проблем, когда рельеф ровный. А когда будет затяжной спуск, я очень хочу поглядеть на эту бричку из четверых людей, как будете одной рукой руль держать, второй зонт, а еще каким-нибудь местом постоянно оттормаживаться. То есть конечно у вас в Нидерландах велосипед - это здорово, минусовых температур нет, холмов нет. В местах подальше от океанов и климат континентальный, и местность с регулярными спусками-подъемами, по которым велоспортом заниматься норм, а решать ежедневные задачи не норм.
Не только комфортно, но и безопасно. Всем же известно, что передвижение с одной рукой на руле в поворотах не вызывает трудностей. А зонт еще можно использовать как парус.
Ну это не попытка уличить в чем-то противозаконном, просто личное наблюдение, которое срабатывает из раза в раз :) Для ML-инженеров питон - второстепенный инструмент и это норма.
Забавный факт, но почти всегда можно угадать, что код написан не обычным разрабом, а млщиком по таким вот строкам: return True if count_of_white_pixels > self.cfg['hero_step_define']['min_white_pixels'] else False
Пытаться предугадывать надо не конкретные вещи, а те места, где изменения наиболее возможны и стелить абстракции заранее. Этим наверное и отличается новичок от неновичка: опытный знает, где можно быстро навернуть говнокода, взяв техдолг, а где техдолг будет не очень к месту.
Моему бюджетному Redmi Note 10 Pro 2,5 года, но на нем 13-ая версия ОС, кто знает, может и новую докатят. Проблема не в Андроиде, проблема в конкретных вендорах.
1,5 сотки -- это участок под фундамент хорошего дома. Под парковку, цветник и беседку нужно еще 4,5 хотя бы. В таком можно жить, остальное это уже курятник какой-то
Чтобы time-to-market был минимальным, нужно параллелизовывать работы как можно круче. Чтобы программистов привлекали к проработке задачи как можно раньше, чтобы программисты всех частей (бэк, фронты, хер знает кто еще) в первую очередь согласовывали между собой контракт, а потом уже начинали что-то делать, естественно параллельно, чтобы опсы заранее знали о крупных фичах и планировали инфраструктурные апгрейды под релизы как можно раньше, чтобы тестировщики начинали накидывать тест-кейсы когда задача спроектирована, а не когда разработка закончила, чтобы техподдержка так же была в курсе того, что ее вскоре ожидает, могла как-то к этому подготовиться, например внести какие-нибудь предложения по разработке дополнительного тулинга для них.
А микросервисы к time-to-market докидывают не так уж много, по сравнению с монолитом: простые миграции хранилищ, да возможность без лишних согласований завезти нужные версии инструментов и библиотек, это важно, но с этим сталкиваешься далеко не на каждой фиче. Возможность говнокодить в микросервисе и вовсе может сыграть злую шутку при его разрастании. MSA -- это не про размеры сервисов, это про микроинтерфейсы к сущностям и необходимый минимум ручек для каждой из них. Их может быть три-пять, но с таким адом внутри, что лучше было не говнокодить с самого начала.
А какие вообще плюсы использования фласка с 2023 году по сравнению с тем же FastApi? Особенно доставила книга Flask Framework Cookbook, рассказывающая о Фласке и Питоне пятилетней давности, ну камон.
Большое спасибо за статью! Я правильно понял, что у вас там прокрался копипаст и в делении на типы СТО по этапам развития компании, на этапе департаментов должен быть cTO, то есть главный инженер, то есть такой человек, который уже не лезет в текучку конкретных департаментов? Было бы интересно еще почитать какие карьерные треки возможны для каждого из перечисленных типов (хотя для CTo и сTo понятно).
В долгосрочной перспективе техническая экспертиза миддла и сеньора как раз таки выравняется как за счет того, что техническую экспертизу не будет времени качать и все устаканится ровно на том уровне, чтобы задавать рядовым инженерам, техлидам и архитекторам вопросы, которые помогут осмотреть проблему со всех сторон. Первое, что должен сделать нормальный миддл инженер став тимлидом, это выбрать/назначить техлида/ов, если не хочется сгорать, постоянно пытаясь в личных овертаймах подтягивать экспертизу.
То есть мой поинт такой: если команда слабая и нужно срочно закрыть дырки, то с тимлидом-бывшим-сеньором команда конечно будет эффективнее, но в более-менее зрелых компаниях или отдельных командах, глубина экспертности тимлида не будет столь уж значимой, важны будут другие качества, это другой трек развития.
В тимлиды прекрасно переходится из миддл инженера. Технических знаний этой позиции должно хватать, чтобы занять эту позицию, а для решения людских взаимодействий и улучшения рабочих процессов нужны уже другие навыки. А сеньоры дальше растут по другому треку
FFF классный. Бюджет фиксирован, время фиксировано и мы просто сдаем в аренду свою команду, которая умеет делать качественно, но когда сделаем MVP не говорим. Кажется это вообще не про создание MVP в его базовом понимании, потому что он нужен ровно для того, чтобы протестировать какую-нибудь гипотезу, и если она не сработает -- то выбросить код без сожаления.
А откуда инфа, что на дорогах становится хуже и хуже? Статистика с сайта ГИБДД как-то не подтверждает. Конечно не так уж радостны абсолютные цифры, но тенденция на лицо.
Захватить за два года, довольно амбициозно, с учетом того, что еще не зарелизились. Наша компания несколько месяцев как переехала в Пачку, сыровато конечно, но чуваки растут по функционалу очень хорошо.
А что, женщины перестают рожать, потому что вынашивать тяжело?
Вот тут можно порисовать графики самому. Это коэффициент фертильности по миру. Для того, чтобы мы не вымирали, каждая женщина должна рожать по 2.1 ребенка, на графике зеленый пунктир.
Да нет никаких проблем, когда рельеф ровный. А когда будет затяжной спуск, я очень хочу поглядеть на эту бричку из четверых людей, как будете одной рукой руль держать, второй зонт, а еще каким-нибудь местом постоянно оттормаживаться. То есть конечно у вас в Нидерландах велосипед - это здорово, минусовых температур нет, холмов нет. В местах подальше от океанов и климат континентальный, и местность с регулярными спусками-подъемами, по которым велоспортом заниматься норм, а решать ежедневные задачи не норм.
Не только комфортно, но и безопасно. Всем же известно, что передвижение с одной рукой на руле в поворотах не вызывает трудностей. А зонт еще можно использовать как парус.
Ну это не попытка уличить в чем-то противозаконном, просто личное наблюдение, которое срабатывает из раза в раз :) Для ML-инженеров питон - второстепенный инструмент и это норма.
Потому что достаточно
return count_of_white_pixels > self.cfg['hero_step_define']['min_white_pixels'].Забавный факт, но почти всегда можно угадать, что код написан не обычным разрабом, а млщиком по таким вот строкам:
return True if count_of_white_pixels > self.cfg['hero_step_define']['min_white_pixels'] else FalseПытаться предугадывать надо не конкретные вещи, а те места, где изменения наиболее возможны и стелить абстракции заранее. Этим наверное и отличается новичок от неновичка: опытный знает, где можно быстро навернуть говнокода, взяв техдолг, а где техдолг будет не очень к месту.
Ну так-то у Анабара тоже есть бесплатный плагин