Сейчас стало модно везде использовать биометрические данные для авторизации и иногда мы не замечаем как и куда такие данные передаются. Так как у биометрических данных есть такая проблема, что их вообще никак нельзя сменить в случае компрометации, то направо и налево раздавать их не вполне разумно.

В октябре 2023 банк Тинькофф начал предлагать своим клиентам перевести имеющиеся у него фотографии в биометрический формат (и потом загрузить их в Единой биометрической системе — ЕБС). Причём от этого предложения было не так легко отказаться (для удобства клиентов кнопки "Не хочу" просто не было предусмотрено). Обо всём этом уже писали ранее.

Зачем это всё было надо для Тинькова? Вопрос сложный. Может быть из любви к своим клиентам, может быть чтобы заполнить пустующую ЕБС, может быть для ещё каких-то важных целей, неведомых простым смертным. Только топ-менеджмент Тинькова может дать ответ на этот вопрос, но это нам и не важно. Интереснее что из всего этого получилось.

В обсуждении к упомянутой выше статье некоторые комментаторы решили попробовать или удалить из Тинькова биометрическую информацию или явно написать им, что согласия они не дают. Идея показалась разумной и мне. Ещё тогда, в октябре 2023, я написал в чат, что хочу удалить биометрчиескую информацию. Вероятно, я был не один такой, так как бот Олег сам всё понял и сам прислал на мою почту справку о том, что никакой моей биометрии у них нет. Разумеется, согласие на создание биометрии из имеющихся данных (фото и аудио) я Тинькову не давал.

В 2023-ем году мы узнали, что нейросети могут галлюцинировать. На первый взгляд, это довольно забавное и пока что безобидное явление. Но в этой короткой статье я расскажу, как я столкнулся с галлюцинациями самого Google, и как это чуть не угробило стартап, в котором я работаю.

С Новым Годом уважаемые читатели! Год назад я публиковал подборку из 150-ти книг для тех, кто делает игры и в ней я обещал, что буду постоянно обновлять ее и добавлять в нее новые книги. Время не заставило себя ждать и количество книг в подборке увеличилось в двое и если вы ищите что почитать, то заходите или добавляйте в закладки!

Привет, Хабр! 👋

Меня зовут Игорь, и я Unity Developer. Последние несколько месяцев я реализовывал зомби шутер на атомарном подходе. Несмотря на то, что подход оказался очень удобным и гибким, я столкнулся я рядом архитектурных проблем в процессе разработки. Поэтому в этой статье я хотел бы раскрыть текущую концепцию атомарного подхода: объяснить что это такое, какие есть преимущества и недостатки, и самое главное, показать как правильно использовать атомарный подход у себя в проекте.

Как мы к этому пришли? Как мы стали вместо решения наших задач, тратить кучи денег на решение проблем, которых у нас нет?

В этой статье я хочу описать (часть) моего опыта взаимодействия со структурой, именуемой в дальнейшем «яндекс», с точки зрения работника. Опишу собеседования и этап «входа».

Да, уже были статьи про собеседование и даже в эту же структуру, некоторые из них я видел, но не во всём с ними согласен, к тому же конкретно С++ разработчиков я там не видел.

В жизни каждого инженера-фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.

Эти фичи явственно смахивают на внутренние механизмы баз данных. Действительно, в любом достаточно сложном клиентском приложении программисту непременно придётся реализовывать такое множество фич для управления данными, что эта работа будет напоминать построение предметно-ориентированной базы данных. Такая дополнительная сложность удваивается в каждом проекте, над которым мы работаем, поэтому приходится тратить время на решение бизнес-проблем, а радовать пользователя – уже как успеем.

Поэтому сегодня предлагаю вам составить мне компанию – и мы вместе рассмотрим распространённые паттерны работы с данными приложений, а также разберёмся, как они соотносятся с фичами баз данных. Далее мы рассмотрим решения, которые могли бы стать альтернативами этим паттернам – например, как сделать в клиентской части оптимизированный стек базы данных, который позволил бы нам сосредоточиться на разработке приложения, а не на мелкой возне с данными.

Недавно Аби Нода*, программист и генеральный директор платформы DeveloperExperience, ознакомился с исследованием The Human Side of Software Engineering Teams: An Investigation of Contemporary Challenges. В нём авторы обозначили наиболее важные «человеческие» проблемы, сопутствующие разработке ПО.

По мнению Ноды, материал закладывает основу для будущих исследований о взаимосвязи человеческого фактора и продуктивности разработчиков. В то же время менеджеры могут использовать его как чек-лист, позволяющий выявить зоны для потенциальных улучшений в командах.

Подробнее о том, как человеческий фактор мешает работать программистам, читайте под катом.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

IT-сообщество давно уже изобилует людьми, которые работают, откровенного говоря, спустя рукава. Отлынивают, филонят, тихо саботируют. Такие сотрудники часто прогуливают работу, пользуясь удаленкой. Они коммитят в 2 раза реже и хуже, чем могли бы. Они не готовы править и даже замечать ошибку в коде, если на это нет прямого распоряжения начальника. Они принципиально не готовы разбираться в текущих задачах шире и глубже, чем этого требует минимально возможная планка. Одним словом, такие сотрудники работают по самой нижней границе своего потенциала, при этом делают это осознанно.

Степень активной осознанности может быть разной. Например, в самом ясном проявлении это может принимать такую форму: «не буду делать ни одного лишнего движения, если не посчитаю это нужным, ведь в первую очередь это нужно не мне». В самом слабом своем проявлении это звучит примерно так: «я просто боюсь выгорания и выживаю, как могу».

Я далек от того, чтобы делать какие-либо моральные оценки этому явлению (если
прочтете до конца, поймете, почему).  Я – тимлид с 15-летним опытом работы в IT. Я лично нанимал многих людей и со многими прощался. У меня есть своя приличная статистика откровенных мыслей и настроений людей, которые со мной работали, работают, или работают, но не со мной. На основании этого своего опыта (и не только своего) я попытаюсь дать ответ на вопрос, как и почему вырастает фига в кармане программиста. Я потяну за ниточку клубка причин и постепенно попытаюсь его распутать целиком. Результатом будет сводный граф причин феномена саботажа в IT. Поехали!

Хочу вас огорчить, программисты не делают игры - их делают дизайнеры и арт. Можно уволить программиста и на его место придет другой и через условные месяц-два-полгода начнет закрывать таски не хуже. Если увольняется дизайнер, его монстр, пушка или контент повисает без хозяина и без "видения". Если её не перехватил сосед (а у соседа свой монстр), то в большинстве случаев его работа просто уходит в стол и монстра пишут заново на тех же ассетах и принципах, но заново.

Если увольняется арт-директор, который несет "видение" проекта, то проекту становится очень плохо, в большинстве случаев визуально он изменится до неузнаваемости, хотя ассеты могут быть те же самые. Программисты делают всё, кроме самой игры: рендер, звук, физику, сеть, AI, инверсную кинематику, поиск пути и т.д. Можем подискутировать в комментариях.

В технической документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта форма для строгих и однозначных описаний! Почему же страдательный залог заставляет читателей страдать? Будем разбираться...

В прошлые выходные мне представилась возможность пообщаться с только что выпустившимися студентами. Сейчас они ищут свою первую работу в разработке ПО. В разговоре с ними я понял, что они довольно ошибочно воспринимают эту работу.

Причина этого в том, что реальность для этих новичков очень искажена. Они видят лишь высокие зарплаты, удалённую работу, тимбилдинг и вечеринки с пиццей.

Всё это приятные бонусы, но никто не говорит им, что на самом деле им придётся делать на этой работе.

Имея большой опыт работы в этой отрасли, я смог показать им, какова жестокая реальность. Я рассказал им о хорошем, но также поделился и неприятными истинами.

Прочитав эту статью, кто-то может сказать, что я слишком негативен, но я считаю, что все эти аспекты неотделимы от профессии и их необходимо принять.

Игры бывают разные, большие и маленькие, триA и супер инди, в компаниях с сотнями разработчиков и что создаются самородками-одиночками. Редко их делают с нуля и пишут код только игры, чаще пишут игровые тулы, редактор и параллельно пишут саму игру. За всей этой многомиллиардной индустрией стоит код, много кода, очень много кода. Игровые движки и фреймворки – мощные инструменты, которые помогают разработчику творить его идеи и создавать увлекательные игровые миры. Это каркас, на котором строятся все игровые вселенные, они включают в себя сотни инструментов, библиотек и ресурсов, позволяя разработчикам превратить строчки кода в театр для одного зрителя.

Существует более сотни игровых движков, каждый из них содержит как минимум одну фичу которой нет ни в каком другом. Всех возможностей вместе нет ни в одном, и это прекрасно - иначе бы такой движок монополизировал рынок. Хм, Unreal5 ты ли это? Иногда полезно пробежать по release notes движка, чтобы оставаться в курсе последних новостей. Возможно вы разрабатываете свое решение и эта статья натолкнет вас на новые идеи. Готовы узнать что ваша любимая игры была сделана не на Unity, а на православном SDL?

Обычно компаниям выгодно взращивать линейных руководителей, а не нанимать. Это помогает создать команду менеджеров и тимлидов, которые глубоко погружены в специфику проектов, разделяют культуру компании, и одновременно с этим даёт возможность для естественного карьерного развития заинтересованным сотрудникам.

Но также нередки случаи, когда резерв управляющих кадров не позволяет решить возникшую организационную задачу. Это может привести к необходимости нанимать линейных руководителей извне.

Прийти новым руководителем в уже сформированный коллектив, не разрушить команду, сохранить и увеличить её производительность — очень непросто. Особенно в случае с самоорганизующимися Agile-командами: когда от руководителя ожидается не директивное управление, а качественное сопровождение. Такие команды настроены не на подчинение, а на сотрудничество, которое ожидают и от руководителя. Повести за собой, действуя на равных и не имея сформированного авторитета, — задача, требующая терпения, настойчивости и хороших навыков коммуникации. И решить эту задачу нужно в достаточно короткий период адаптации.

Что такое Scrum?

Scrum — это Agile-система управления проектами, «помогающая людям и командам инкрементно и совместно приносить пользу» — цитата со Scrum.org.

Agile не является: Библией разработки ПО, догматическим набором строгих правил, тикетами Jira или коучами Agile, суетящимися в вашей компании.