Объявили результаты. Из четырёх команд мы оказались на четвёртом месте. Сказать, что это стало мягко говоря удивлением — ничего не сказать. Секрет оказался прост: мы пришли четверо разработчиков делать проект на хакатон, который был назван таковым организаторами по ошибке. А оказался конкурсом бизнес-идей. В общей шкале оценки реализация значила всего 20%. Двадцать процентов. Двухдневная работа заняла одну пятую от общей оценки (презентация делалась за пределами основного времени). Зато более половины уделялось умозрительным критериям, не имеющим никакого отношения к собственно работе, проделанной командами на самом хакатоне: например «Прогнозируемый объём аудитории», «Вирусный эффект» (ага, для B2G продукта вирусный эффект). Как в той картинке, где разных животных, включая рыбу, просят залезть на дерево, кто быстрее.
При цене реализации в 20% можно было вообще ничего не кодить два дня, прийти без проекта, но зато удачно придумать и продать комиссии маркетинговую лапшу. Хакатоны нередко ругают за возможность «выиграть одной презентацией», но в такой критике обычно речь идёт об обмане относительно степени готовности прототипа. Здесь же такие условия были с самого начала заложены в систему.
Даже не знаю, как к этому относиться. Ну типа чуваки просто не донесли, что реализация почти ничего не значит, и стараться не нужно. На мой взгляд это противоречит концепции хакатона, тогда уж стоило просто объявить конкурс идей, у него совсем другие правила игры. С другой стороны, участвовать нас никто не заставлял, проект получился прикольный, делать его было интересно. С третьей стороны, одно из самых сокрушительных поражений в моей жизни.
В ноябре будет уже более масштабный внутренний so-called-хакатон в компании. Не понимаю, хочу ли теперь участвовать или нет. #dev
При цене реализации в 20% можно было вообще ничего не кодить два дня, прийти без проекта, но зато удачно придумать и продать комиссии маркетинговую лапшу. Хакатоны нередко ругают за возможность «выиграть одной презентацией», но в такой критике обычно речь идёт об обмане относительно степени готовности прототипа. Здесь же такие условия были с самого начала заложены в систему.
Даже не знаю, как к этому относиться. Ну типа чуваки просто не донесли, что реализация почти ничего не значит, и стараться не нужно. На мой взгляд это противоречит концепции хакатона, тогда уж стоило просто объявить конкурс идей, у него совсем другие правила игры. С другой стороны, участвовать нас никто не заставлял, проект получился прикольный, делать его было интересно. С третьей стороны, одно из самых сокрушительных поражений в моей жизни.
В ноябре будет уже более масштабный внутренний so-called-хакатон в компании. Не понимаю, хочу ли теперь участвовать или нет. #dev
1🤯33👍7❤6👨💻2🔥1
Самое удивительное в энтерпрайз-разработке — необходимость специально доказывать и аргументировать объективно правильные решения. Представь, приходишь на автомобильный завод, а там выпускают бензобаки с дыркой в центре одной из стенок. Причём, это не особенность конкретного рынка или потребителя, просто исторически так процессы сложились. Ты такой: «Эээ, зачем с дыркой, давайте делать без дырки». Но тебе отвечают, что нужно аргументировать, защитить эту позицию перед бизнесом, ещё и с цифрами. Показать, что затраты ниже, чем профит. А начальник производства тебе ещё и раскладывает: на бензобаки без дырки будет уходить больше металла, так что твоё предложение приведёт к росту расходов. Ещё и у клиентов баки начнут заполняться дольше, негативный опыт.
Ты находишь инженерные книжки с описанием физики сплошных сред: «Вот гляньте что пишут, вот аргументы, вот схемы и формулы». А в ответ слышишь, что книги это идеализация, и в жизни оно всё иначе, нужно реалистично смотреть. Но самое главное: перестраивать линию на отсутствие дырки это прям очень дорого: станки переконфигурировать, персонал обучать, да и наверняка первое время будут косяки, поставки снизятся. Короче если прям не докажешь, что профит от твоего предложения принесёт миллиард за день, то иди нафиг.
Почему в разработке такого много, а на реальных автомобильных заводах всё-таки делают без дырок? Я вижу две причины:
1. Во-первых, когда бензобак еб**ёт, или там самолёт упадёт, это очень заметно. Аварии происходят с шумом, нередко с травмами. А падение какого-нибудь входящего интеграционного потока из-за отсутствия контроля состояния модели — это тихо, без фейерверков. Ну насыпется в лог ошибок, пошёл, руками поправил пару записей в БД, запустил снова.
2. Во-вторых, всё-таки у разработки низкая степень разнообразной конкуренции из-за склонности этой сферы к монополизации (которая обусловлена простотой доставки потребителю). В мире порядка тысячи автопроизводителей, а вот софт одного типа обычно выпускает едва ли десяток компаний. Сколько фирм делают, например, САПР для твердотельного моделирования? Нейросетка мне привела девять. Сколько настоящих конкурентов у какого-нибудь Майкрософт Офиса? Один: гугл документы.
И вроде всё понятно, как оно работает, но не перестаю удивляться. Нужно прям реально убеждать людей, не на инженерном языке, а на языке бизнеса и маркетинга, что дырка в бензобаке это плохо. #dev #life
Ты находишь инженерные книжки с описанием физики сплошных сред: «Вот гляньте что пишут, вот аргументы, вот схемы и формулы». А в ответ слышишь, что книги это идеализация, и в жизни оно всё иначе, нужно реалистично смотреть. Но самое главное: перестраивать линию на отсутствие дырки это прям очень дорого: станки переконфигурировать, персонал обучать, да и наверняка первое время будут косяки, поставки снизятся. Короче если прям не докажешь, что профит от твоего предложения принесёт миллиард за день, то иди нафиг.
Почему в разработке такого много, а на реальных автомобильных заводах всё-таки делают без дырок? Я вижу две причины:
1. Во-первых, когда бензобак еб**ёт, или там самолёт упадёт, это очень заметно. Аварии происходят с шумом, нередко с травмами. А падение какого-нибудь входящего интеграционного потока из-за отсутствия контроля состояния модели — это тихо, без фейерверков. Ну насыпется в лог ошибок, пошёл, руками поправил пару записей в БД, запустил снова.
2. Во-вторых, всё-таки у разработки низкая степень разнообразной конкуренции из-за склонности этой сферы к монополизации (которая обусловлена простотой доставки потребителю). В мире порядка тысячи автопроизводителей, а вот софт одного типа обычно выпускает едва ли десяток компаний. Сколько фирм делают, например, САПР для твердотельного моделирования? Нейросетка мне привела девять. Сколько настоящих конкурентов у какого-нибудь Майкрософт Офиса? Один: гугл документы.
И вроде всё понятно, как оно работает, но не перестаю удивляться. Нужно прям реально убеждать людей, не на инженерном языке, а на языке бизнеса и маркетинга, что дырка в бензобаке это плохо. #dev #life
👍22💯11😢7❤2😁1
У протокола Яндекса по умному дому есть регламент, согласно которому Яндекс периодически запрашивает состояние всех устройств одного пользователя в рамках конкретного провайдера, одним запросом. Провайдеры забивают на поддержку этого метода, и возвращают не всегда корректный ответ, из-за чего про некоторые устройства Яндекс начинает думать, что они отвалились.
В такой ситуации Яндекс делает несколько попыток, а затем присылает пользователю уведомление типа «Датчик такой-то долго не отвечает». Фокус в том, что, если нажать на уведомление, открывается карточка этого устройства, которая запрашивает его состояние уже более целенаправленно: не методом получения всех устройств, а методом запроса по конкретному устройству. На эти методы производители не забивают, и карточка успешно обновляется.
Так вот. Какого хрена в Яндексе не догадались пропускать шаг с уведомлением и просто при неполучении состояния пытаться запрашивать его напрямую? Это же прям очень просто в реализации, экономит запросы на уведомления, не отвлекает юзера, делает систему более надёжной.
Не, ладно, я сам работаю в энтерпрайзе, поэтому знаю, что можно годами ждать исправления даже мелкого косяка, потому что так процессы устроены. Но всё-таки, блин. Прям подбешивает меня, и как пользователя, и как программиста. #dev
В такой ситуации Яндекс делает несколько попыток, а затем присылает пользователю уведомление типа «Датчик такой-то долго не отвечает». Фокус в том, что, если нажать на уведомление, открывается карточка этого устройства, которая запрашивает его состояние уже более целенаправленно: не методом получения всех устройств, а методом запроса по конкретному устройству. На эти методы производители не забивают, и карточка успешно обновляется.
Так вот. Какого хрена в Яндексе не догадались пропускать шаг с уведомлением и просто при неполучении состояния пытаться запрашивать его напрямую? Это же прям очень просто в реализации, экономит запросы на уведомления, не отвлекает юзера, делает систему более надёжной.
Не, ладно, я сам работаю в энтерпрайзе, поэтому знаю, что можно годами ждать исправления даже мелкого косяка, потому что так процессы устроены. Но всё-таки, блин. Прям подбешивает меня, и как пользователя, и как программиста. #dev
💯19😱4🤯1
Media is too big
VIEW IN TELEGRAM
Каждый Новый Год, как вы помните, я пытаюсь придумать какую-то новую технологическую фишечку к празднику. Идея вот этого у меня возникла еще год назад, но ни времени, ни знаний для реализации толком не было. В этот же раз поставил себе цель обязательно разобраться и добить. Демка на видео, без звука будет непонятно.
Из недостатков, конечно, нужно калибровать под каждые светодиоды то, как визуально будет выглядеть тот или иной цвет. Я этого не делал, поэтому попадание не чтоб прям идеальное, особенно для сложных сцен типа «осенний лес».
Из крутого внезапно узнал, что ESP32 двухъядерная! Не знаю, как я это пропустил в своё время. Но тут прям можно одним потоком читать сеть, а другим драйвить ленту и не делать паузы.
В целом мне всё равно нравится. Работает под управлением DeepSeek. В первой версии был GigaChat, он отвечает где-то вдвое быстрее, но слишком часто предлагает цвета совершенно мимо того, что я назвал.
Репозиторий с не слишком аккуратным кодом, если кому не лень будет возиться :) С наступающим!
#dev@clockstackwheels #gadgets@clockstackwheels #diy@clockstackwheels
Из недостатков, конечно, нужно калибровать под каждые светодиоды то, как визуально будет выглядеть тот или иной цвет. Я этого не делал, поэтому попадание не чтоб прям идеальное, особенно для сложных сцен типа «осенний лес».
Из крутого внезапно узнал, что ESP32 двухъядерная! Не знаю, как я это пропустил в своё время. Но тут прям можно одним потоком читать сеть, а другим драйвить ленту и не делать паузы.
В целом мне всё равно нравится. Работает под управлением DeepSeek. В первой версии был GigaChat, он отвечает где-то вдвое быстрее, но слишком часто предлагает цвета совершенно мимо того, что я назвал.
Репозиторий с не слишком аккуратным кодом, если кому не лень будет возиться :) С наступающим!
#dev@clockstackwheels #gadgets@clockstackwheels #diy@clockstackwheels
6🔥35❤7👍5👏1😱1
Внезапно сменил работу
Кажется, буквально только что прогремела моя статья о собеседованиях, феерично завершившаяся попаданием в 2ГИС. Восемь месяцев — чертовски маленький срок. Никогда не занимался «джобхоппингом», так что и сейчас не открывал резюме, не искал работу, готовился к аттестации. Встроился в процессы, накупил корпоративного мерча, подружился с коллегами и стал регулярно ездить в офис (который при мне перенесли в другое здание и расширили). Уже прям ассоциировал себя с 2ГИС.
Но внезапно мне сделали очень заманчивое предложение. Такое, от которого невозможно отказаться. Позвали в расширяющуюся финтех-компанию архитектором на новые продукты. Очень грустно уходить из 2ГИС, но я бы себя не простил, если бы не воспользовался открывшейся возможностью.
Сегодня на теперь уже старом месте работы было exit-интервью. Кстати, хорошая практика — компания обращает внимание на особенности в статистике увольнений. Задавали вопросы о том, что было хорошо, а что можно улучшить.
Вообще впечатления от 2ГИС самые тёплые. Из плюсов я бы выделил развитую корпоративную культуру и приятную атмосферу работы (не в последнюю очередь благодаря коллегам). Я с удовольствием читал внутренний новостной портал, ходил на презентации фич и самопрезентации новичков, участвовал в местных квизах. Прям сильный косяк вышел только с хакатоном, я вам об этом писал, но там скорее всего просто конкретные организаторы лажанули.
Одна из самых крутых киллер-фич 2ГИС, как работодателя — упрощённое взятие выходных и отпусков. По большей части не нужно никаких специальных согласований, если ты внезапно повёз ребёнка к врачу, или сам устал и хочешь денёк отоспаться.
Однако, в других местах отсутствие формализма порождает сложности. В Росатоме, например, процессы движения задач по жизненному циклу были зарегламентированы сильнее: нельзя передать что-то в разработку без аналитики, постановщик задачи сам следит за её статусами, задача целиком переназначается всегда на текущего одного ответственного человека (на стадии разработки на программиста, на стадии тестирования на тестировщика и т.д.). В 2ГИС иногда задачи приходили от бизнеса с необходимостью самостоятельно ходить по людям и уточнять, что на самом деле хотели. Делалось это как бы для экономии на аналитиках, что лично мне кажется большим заблуждением: бизнес таким образом платил за время более дорогого программиста, который ещё и выполнял работу аналитика дольше, потому что специализируется на другом. В итоге то, что казалось экономией, в моём понимании было скорее увеличением расходов и сроков. То же самое касалось, например, архитектуры и техдолга (но это типичная проблема подавляющего большинства бизнесов — техдолг вообще никто не умеет считать и оценивать).
Я бы сказал так: 2ГИС как бы вырос из стартапа и стал практически бигтехом, особенно после покупки Сбером. Если не бигтехом, то энтерпрайзом точно. Но в итоге оставил часть недостатков стартапа (экономия на «второстепенных» вещах, отсутствие регламентов) и получил часть недостатков энтерпрайза (слабое влияние сотрудников на конечный продукт, очень затянутое планирование и согласование новых задач, заметное количество легаси).
С другой стороны в той же мере присутствуют одновременно плюсы стартапа (простые организационные процессы, неформальная атмосфера) и плюсы энтерпрайза (стабильная компания с офисами, конкурентными зарплатами, рыночным белым оформлением, айти брендом и корпоративной культурой).
Если вы дисциплинированы, компетентны и не боитесь некоторых трудностей, то я однозначно готов советовать работу в 2ГИС. Сейчас идёт набор разработчиков на C#, Go, дата-саентистов, присоединяйтесь :) Уровни мидл и сеньор.
#dev@clockstackwheels #life@clockstackwheels
Кажется, буквально только что прогремела моя статья о собеседованиях, феерично завершившаяся попаданием в 2ГИС. Восемь месяцев — чертовски маленький срок. Никогда не занимался «джобхоппингом», так что и сейчас не открывал резюме, не искал работу, готовился к аттестации. Встроился в процессы, накупил корпоративного мерча, подружился с коллегами и стал регулярно ездить в офис (который при мне перенесли в другое здание и расширили). Уже прям ассоциировал себя с 2ГИС.
Но внезапно мне сделали очень заманчивое предложение. Такое, от которого невозможно отказаться. Позвали в расширяющуюся финтех-компанию архитектором на новые продукты. Очень грустно уходить из 2ГИС, но я бы себя не простил, если бы не воспользовался открывшейся возможностью.
Сегодня на теперь уже старом месте работы было exit-интервью. Кстати, хорошая практика — компания обращает внимание на особенности в статистике увольнений. Задавали вопросы о том, что было хорошо, а что можно улучшить.
Вообще впечатления от 2ГИС самые тёплые. Из плюсов я бы выделил развитую корпоративную культуру и приятную атмосферу работы (не в последнюю очередь благодаря коллегам). Я с удовольствием читал внутренний новостной портал, ходил на презентации фич и самопрезентации новичков, участвовал в местных квизах. Прям сильный косяк вышел только с хакатоном, я вам об этом писал, но там скорее всего просто конкретные организаторы лажанули.
Одна из самых крутых киллер-фич 2ГИС, как работодателя — упрощённое взятие выходных и отпусков. По большей части не нужно никаких специальных согласований, если ты внезапно повёз ребёнка к врачу, или сам устал и хочешь денёк отоспаться.
Однако, в других местах отсутствие формализма порождает сложности. В Росатоме, например, процессы движения задач по жизненному циклу были зарегламентированы сильнее: нельзя передать что-то в разработку без аналитики, постановщик задачи сам следит за её статусами, задача целиком переназначается всегда на текущего одного ответственного человека (на стадии разработки на программиста, на стадии тестирования на тестировщика и т.д.). В 2ГИС иногда задачи приходили от бизнеса с необходимостью самостоятельно ходить по людям и уточнять, что на самом деле хотели. Делалось это как бы для экономии на аналитиках, что лично мне кажется большим заблуждением: бизнес таким образом платил за время более дорогого программиста, который ещё и выполнял работу аналитика дольше, потому что специализируется на другом. В итоге то, что казалось экономией, в моём понимании было скорее увеличением расходов и сроков. То же самое касалось, например, архитектуры и техдолга (но это типичная проблема подавляющего большинства бизнесов — техдолг вообще никто не умеет считать и оценивать).
Я бы сказал так: 2ГИС как бы вырос из стартапа и стал практически бигтехом, особенно после покупки Сбером. Если не бигтехом, то энтерпрайзом точно. Но в итоге оставил часть недостатков стартапа (экономия на «второстепенных» вещах, отсутствие регламентов) и получил часть недостатков энтерпрайза (слабое влияние сотрудников на конечный продукт, очень затянутое планирование и согласование новых задач, заметное количество легаси).
С другой стороны в той же мере присутствуют одновременно плюсы стартапа (простые организационные процессы, неформальная атмосфера) и плюсы энтерпрайза (стабильная компания с офисами, конкурентными зарплатами, рыночным белым оформлением, айти брендом и корпоративной культурой).
Если вы дисциплинированы, компетентны и не боитесь некоторых трудностей, то я однозначно готов советовать работу в 2ГИС. Сейчас идёт набор разработчиков на C#, Go, дата-саентистов, присоединяйтесь :) Уровни мидл и сеньор.
#dev@clockstackwheels #life@clockstackwheels
1👍37🔥18❤6⚡2😱2😭2
В 2023 году мы с коллегой сделали доклад на DotNext по DDD и архитектуре систем. И там, в числе прочего, показали, что устройство сложного проекта, спроектированного по определённым правилам, может иметь фрактальную структуру. Но мысль эту особо не развивали.
В 2024 году Влад Хононов — автор одной из самых известных книг по DDD — сделал доклад на DotNext по теме «Фрактальная геометрия в проектировании систем». Разумеется, он никаким образом на нашу идею не опирался, а работал над своей системой уже несколько лет к моменту доклада. У него там прям интересные научные обоснования, более серьёзный теоретический фундамент с введением новых понятий и принципов. Но факт близости хода мысли приятен. Типа, мы с коллегой делали систему, которая показала те же свойства, что и системы крутого эксперта в архитектуре.
Прям рекомендую доклад по второй ссылке всем, кто работает в компаниях, где по какому-то странному недосмотру есть архитектура, борьба с техдолгом и попытки не допустить превращения кода в лапшу с высоким зацеплением.
#dev@clockstackwheels
В 2024 году Влад Хононов — автор одной из самых известных книг по DDD — сделал доклад на DotNext по теме «Фрактальная геометрия в проектировании систем». Разумеется, он никаким образом на нашу идею не опирался, а работал над своей системой уже несколько лет к моменту доклада. У него там прям интересные научные обоснования, более серьёзный теоретический фундамент с введением новых понятий и принципов. Но факт близости хода мысли приятен. Типа, мы с коллегой делали систему, которая показала те же свойства, что и системы крутого эксперта в архитектуре.
Прям рекомендую доклад по второй ссылке всем, кто работает в компаниях, где по какому-то странному недосмотру есть архитектура, борьба с техдолгом и попытки не допустить превращения кода в лапшу с высоким зацеплением.
#dev@clockstackwheels
🔥12👍4
Сделал в компании доклад о применении ИИ в архитектуре, давайте и вам расскажу.
Фокус в использовании подхода architecture as code: абсолютно все архитектурные артефакты у нас это тексты. С обычной документацией понятно, это и так некоторый набор текстовых файлов, чаще всего в макрдауне. Для них мы применяем структурный шаблон Arc42 — список из 12 пунктов, по которым нужно распределить информацию о проектируемой системе.
Структурный шаблон, во-первых, хорошо известен нейронкам, и они сразу понимают, о чём речь. Во-вторых, можно кинуться в модель бизнес-требованиям и очень быстро создать некий первоначальный набросок, от которого вы дальше уже пляшете, уточняя по пунктам и исправляя ошибки ИИ. Ну и, в-третьих, готовая структура с ящиками, по которым нужно всё раскладывать, это гораздо лучше, чем свалка ADR'ок, как это нередко бывает в компаниях.
Со схемами и диаграммами ещё интереснее. Берём инструменты со своими DSL-языками, такие, как Structurizr и PlantUML. Вся схема или диаграмма целиком определяется текстовым файлом. Можно применять Git со всеми его преимуществами. А для нейронок это родная среда: вы, как человек, смотрите на схему глазами, но нейронка работает с её DSL-файлом. Навскидку тут прирост эффективности даже больше, чем в программировании, потому что DSL это просто синтаксис, без смыслового наполнения, человеку его можно вообще не знать. Ты пишешь промпты, а смотришь уже на картинку, сгенерированную схему, и следующим промптом указываешь, где какие правки сделать. Нейронке при этом не приходится думать про потоки, асинхронность, типы данных, она просто правит текст как текст, поскольку у DSL нет поведения.
Тут как раз наиболее видна разница между рутинной и интеллектуальной частью работы. Как именно будет выглядеть схема, продумывает архитектор. Если доверить это нейронке, даже мощной, будет полно ошибок, неоптимальностей, неучтённых нюансов среды и так далее. Но вот само по себе написание синтаксиса — имба.
#dev@clockstackwheels
Фокус в использовании подхода architecture as code: абсолютно все архитектурные артефакты у нас это тексты. С обычной документацией понятно, это и так некоторый набор текстовых файлов, чаще всего в макрдауне. Для них мы применяем структурный шаблон Arc42 — список из 12 пунктов, по которым нужно распределить информацию о проектируемой системе.
Структурный шаблон, во-первых, хорошо известен нейронкам, и они сразу понимают, о чём речь. Во-вторых, можно кинуться в модель бизнес-требованиям и очень быстро создать некий первоначальный набросок, от которого вы дальше уже пляшете, уточняя по пунктам и исправляя ошибки ИИ. Ну и, в-третьих, готовая структура с ящиками, по которым нужно всё раскладывать, это гораздо лучше, чем свалка ADR'ок, как это нередко бывает в компаниях.
Со схемами и диаграммами ещё интереснее. Берём инструменты со своими DSL-языками, такие, как Structurizr и PlantUML. Вся схема или диаграмма целиком определяется текстовым файлом. Можно применять Git со всеми его преимуществами. А для нейронок это родная среда: вы, как человек, смотрите на схему глазами, но нейронка работает с её DSL-файлом. Навскидку тут прирост эффективности даже больше, чем в программировании, потому что DSL это просто синтаксис, без смыслового наполнения, человеку его можно вообще не знать. Ты пишешь промпты, а смотришь уже на картинку, сгенерированную схему, и следующим промптом указываешь, где какие правки сделать. Нейронке при этом не приходится думать про потоки, асинхронность, типы данных, она просто правит текст как текст, поскольку у DSL нет поведения.
Тут как раз наиболее видна разница между рутинной и интеллектуальной частью работы. Как именно будет выглядеть схема, продумывает архитектор. Если доверить это нейронке, даже мощной, будет полно ошибок, неоптимальностей, неучтённых нюансов среды и так далее. Но вот само по себе написание синтаксиса — имба.
#dev@clockstackwheels
1🔥20👍7
С 9 по 11 июня 2019 года я с друзьями участвовал в хакатоне, который круто поменял всю жизнь — именно после него мы попали на финал, выиграв который, получили предложение о работе в Росатоме. Для меня это была первая наёмная работа и де-факто начало моего становления, как профессионала (в рыночном смысле).
Вот мне системы флэшбэков в веб-сервисах вчера напомнили, что годовщина была ) Семь лет назад, подумать только! #dev
https://vk.com/@463377-100-vinreit-na-hakatonah-kak-my-vyigrali-cifrovoi-proryv-i-u
Вот мне системы флэшбэков в веб-сервисах вчера напомнили, что годовщина была ) Семь лет назад, подумать только! #dev
https://vk.com/@463377-100-vinreit-na-hakatonah-kak-my-vyigrali-cifrovoi-proryv-i-u
VK
100% винрейт: как мы выиграли Цифровой Прорыв и ушли без приза
В этом году в рамках проекта «Россия — страна возможностей» был запущен масштабный IT-конкурс по всей стране под названием Цифровой Проры..
❤16👍4
Был уверен, что переключение на ру-домен уберёт навязчивые плашки. Даже не представляю, чтобы я, например, реализуя подобный элемент интерфейса, сделал бы как-то иначе, кроме выборочного отображения. Это просто совершенно естественно для любого опытного разработчика, даже не нужны никакие дополнительные требования в задаче. Но вот что мы видим в одном из самых дорогих продуктов страны. #dev
😁46👍5