Здравствуйте! Я Александр Шульман, руководитель компании Active, в которой мы уже несколько лет занимаемся амбициозным проектом — пишем продукт для обеспечения кибербезопасности и достигли первых результатов: полгода назад мы получили аккредитацию от Минцифры, попали в реестр отечественного софта и у нас открылись продажи. Я хочу поделиться своим опытом и представлениями о рынке кибербезопасности с вами с позиции управленца, а не от лица специалиста ИБ, хочу рассказать о своих разочарованиях, открытиях и о том, как в итоге у нас в команде родилась идея сделать свой вклад в рынок ИБ. Мне кажется, что это многим будет интересно, т.к. рынок ИТ активно движется в сторону информационной безопасности по причинам регуляции и по причине роста реальных угроз, а значит, все больше менеджеров и управленцев столкнется с вызовами по кибербезопасности.
Управление разработкой *
Планирование, отслеживание и контроль
Как мы строили систему грейдов разработчиков
Как понять, насколько правильно ты оценен, насколько верно оценены люди в твоей команде, соответствует ли оценка приносимой пользе и багажу их знаний и навыков? Стоит ли платить больше за знания, которые в данный момент не применяются и могут никогда не задействоваться? Как правильно оценить опыт? Как не обидеть коллег оценками и сподвигнуть их к саморазвитию, а не переходу в другую компанию? И как не раздуть ФОТ до бесконечности, когда люди открывают охоту за грейдами?
Все это сложные вопросы и очень многогранные. Пять лет мы аккуратно пытались подобрать ключик к этой проблеме. Пробовали подойти с разных сторон, анализировали результаты и тюнили программу. Кому интересно взглянуть на наш путь, позаимствовать немного хороших идей и узнать, чем закончились те или иные шаги, — добро пожаловать под кат.
Как зарегистрировать аккаунт разработчика в Google Play в 2024 году: пошаговая инструкция
Мы часто помогаем клиентам не только с модерацией приложений, но и с регистрацией аккаунта разработчика в Google Play. Казалось бы — что такого? Вводишь данные и готово. Но лицензия платная, а на пользователях РФ санкции. Как в таких реалиях создать аккаунт, чтобы опубликовать мобильное приложение — рассказываем в статье.
Джун, сеньор и мидл: меняются ли с годами представления о грейдах разработчиков
В чём принципиальное отличие джуна от мидла, а мидла от сеньора? На какие навыки поднажать, чтобы не задерживаться на одной ступеньке? Эти темы актуальны в ИТ-сообществе всегда.
Мы решили проследить, меняются ли с годами представления айтишников о принципиальных различиях между грейдами разработчиков.
Истории
Просветлённый выживший: кто такой фичекрайний и зачем это всё разработчику?
Меня зовут Игорь Буняков, я был фичекрайним за реалистичные дороги в 2ГИС. Недавно они вышли в навигаторе, а позже будут доступны в режиме карт на мобильных устройствах и на 2gis.ru. Реалистичные дороги оказались невероятно большими, невероятно сложными, невероятно красивыми. При этом реалистичность — это не столько про красивость, сколько про функциональность. Мы даём пользователям нашего навигатора новый опыт.
Про техническую реализацию у нас отдельный пост, а этот — менеджерская история для разработчиков. Тут я рассуждаю, кто же на самом деле такой фичекрайний и что он делает, какие стадии проходит во время проекта и почему же всё-таки так классно инженеру прочувствовать роль менеджера.
Программисты больше не нужны, их «уволит» ИИ?
«Через пять лет мы увидим решения, которые смогут заменить как минимум 50% программистов уровня junior и middle», ― шокирует один из экспертов недавней дискуссии, прошедшей на Youtube-канале Ai4Dev. Но так ли страшен черт, как его малюют? Более ста тысяч строк кода в секунду, автоматизация рутинных задач, повышение эффективности ― все это уже часть нашей реальности благодаря применению ИИ в разработке. Однако не все согласны с тем, что искусственный интеллект ― это лекарство от всех болезней. «Именно люди двигают компанию. И генеральный директор, и дворник ― каждый вносит свой вклад», ― напоминает другой участник разговора. Так что же нас ждет ― революция или эволюция? Ответы на этот и другие вопросы вас ждут в сегодняшнем новом материале блога ЛАНИТ на Хабре.
OpenGrok
Эффективный поиск это один за важнейших аспектов работы с «большими проектами». Познакомимся с OpenGrok - одним из лучших инструментов для полнотекстового поиска из тех есть в открытом доступе.
Переезд с Jira
Всем привет! Меня зовут Саша, я — старший специалист по автоматизации тестирования в компании ITFB Group. По роду своей профессиональной деятельности я общаюсь с большим количеством своих коллег, даю советы, рекомендации, а также занимаюсь упрощением и улучшением процессов тестирования. На одном проекте у нас возникла необходимость уйти от Jira как системы управления тестами, и я взялся за эту исследовательскую задачу, чтобы воплотить ее в жизнь. Всем, кому интересна эта история, — добро пожаловать под кат.
Шутки про программистов. Классификация
Шутки про программистов — особый вид юмора и городского фольклора. Некоторые из них рассчитаны на самих программистов, то есть понятны только им, хотя другие доступны и более широкой аудитории. В принципе, их можно классифицировать по темам. Есть несколько типичных тематик, некоторые из них мы упомянем здесь. Естественно, с примерами.
Никто не даст вам повышения — вы должны взять его сами
Получить возможность - это хорошо, но очень важно, чтобы вы развили в себе навыки, позволяющие делать это самостоятельно.
Иногда мне кажется, что одни и те же темы поднимаются периодически. Я слышу от нескольких людей одну и ту же тему. Эта статья появилась потому, что в последнее время я неоднократно слышал от клиентов коучинга и тренингов, что их перспективы продвижения ограничены. Лично я пришел к выводу, что во многом это ограничение является самовнушением, а не фактическим ограничением. После того как я объяснил и написал нижеизложенное в электронном письме нескольким людям, я решил, что, возможно, имеет смысл написать это в виде статьи. Так что если я недавно писал вам что-то подобное, спасибо за вдохновение! :)
Пробуем закрепить принципы работы компании. Пишем свой Манифест
Часто слышу и читаю о том, что крупные компании создают свои миссии. Или подобные документы, которые заявляют что-то абстрактное “за все хорошее, против всего плохого” или про то, как они меняют мир, ничего для этого мира и не делая. Все тезисы взяты из головы и совпадения случайны.
Но есть примеры, когда компании декларируют более “приземленные” и рабочие принципы своей работы или модели действий (никого не рекламирую). Следуют им компании или нет – другой вопрос. Мне было интересно не это, а скорее то, как компании приходят к подобным декларациям. Если и вам интересно это узнать, то делюсь.
Мы в конце прошлого года тоже подошли к созданию такого документа. Сначала, как бы в шутку, но шутка выросла в документ, который мы назвали “Манифест”. Сегодня хотел бы спросить, как вы относитесь к таким документам, считаете ли их создание полезным делом или нет. И будет здорово, если поделитесь почему так считаете.
Вселенная кода, доступная каждому: презентация GitVerse
Привет, Хабр! На связи Андрей Аврамчук (@Mimizavr). Недавно я побывал на онлайн-презентации GitVerse — платформы для совместной разработки и хостинга кода. Планируется, что она станет инструментом нового поколения, избавляющим разработчика от многих болей. Под катом вы узнаете:
— Чем GitVerse может помочь открытому ПО.
— Почему перенос своих проектов на платформу — это легко и приятно.
— Куда спрятаться от ИИ (спойлер: никуда).
— Умеет ли GitVerse в CI/CD.
— И наконец, какие есть причины смотреть в будущее с оптимизмом.
Как веб-технологии помогают искать золото
Я хочу рассказать о своем опыте добавления графического интерфейса
пользователя, созданного с помощью HTML-разметки и CSS-стилей, к ранее
разработанному мной консольному приложению для золотодобывающей
компании. Возможно, описанный мною пример воодушевит на использование
веб-технологий в вашем проекте.
Ближайшие события
Кто такие ИТ-архитекторы и какие задачи они решают
Динамичные изменения в обществе и бизнесе вынуждают компании адаптироваться к новым правилам и требованиям при создании продукта. Успех часто сопутствует тем, кто тщательно продумывает стратегию и развивает свои проекты. Одним из таких преимуществ может стать эффективное ИТ-решение.
В современных информационных технологиях особое значение уделяется проектированию архитектуры приложения. В этой статье я постарался ответить на вопросы о том, кто такие ИТ-архитекторы и как появилась эта профессия, какими бывают архитекторы и какие задачи они решают.
Как джуну отрастить софты: советы и реальные истории. Часть 3. Развиваться
Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее.
О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах.
Некоторые советы могут звучать очевидно: например, у нас есть пункт «выполнять обещания» — понятно, что никто обычно не собирается набрать задач и смотреть, как они горят. Но часто именно таких простых советов тяжело придерживаться. Поэтому в статье мы «приземлили» их реальными историями, чтобы читатель мог узнать ситуацию, если столкнется с ней сам, и применить наш гайд.
Кому читать. Этот гайд — для джунов, которые хотят сделать софты своим конкурентным преимуществом. Если джун ответственно выполняет работу, умеет самостоятельно обучаться и не проходит мимо говна, его готовы оторвать с руками, даже если ему не хватает знаний. К тому же советы из этого гайда помогут быстрее закрепиться в команде и вырасти. Пользуйтесь!
Измерение продуктивности разработчиков. Ответ McKinsey
«На прошлой неделе McKinsey опубликовала статью под названием «Да, вы можете измерить продуктивность разработчиков программного обеспечения». Эта статья вызвала настоящий переполох в сообществе разработчиков ПО. Кент Бек — инженер-программист и создатель экстремального программирования —написал что «Отчет настолько абсурден и наивен, что нет смысла подробно его критиковать».
Хотя мне не понравилось куда клонит этот отчет, я решил взглянуть на положительную сторону: то, как участие McKinsey сигнализирует о растущей потребности даже в «традиционных» компаниях лучше понимать, как работают команды разработчиков программного обеспечения.
Но что-то было не так. Через несколько часов после публикации этой статьи я уже созванивался с Кентом, поскольку мы пытались определитьточно почему мы оба были разочарованы этим отчетом. Мы почти сразу оказались на одной волне и решили, что можем помочь сообществу разработчиков программного обеспечения, изложив словами то, что мы обсуждали. Ниже приведен наш ответ, написанный мной и Кентом Беком, одним "общим голосом".
Костыли, которые горят, пока всё лопается: как выглядит разработка под децентрализованные финансы
Большая часть кода — это опенсорс от разных проектов и сетей. Криптовалюты образовали несколько веток развития, и внутри каждой сети плюс-минус свой набор инфраструктурных решений. Между собой они соединены примерно никак или костылями. Интерфейсы так же дружелюбны, как у Vim в сравнении с Word. API есть, иногда задокументированы, иногда нет (тогда приходится реверсить смарт-контакты или шаблоны кода), иногда работают не так, как в документации.
Стартап работает на стартапе: например, кто-то может долго контрибьютить в библиотеку и инфраструктуру, а потом за неделю свернуться и всё прикрыть. И когда я говорю «инфраструктуру» — это значит, что какая-то часть маршрутов обмена тех же криптовалют будет закрыта одномоментно. Если вы это имплементировали — это ваши проблемы. Мы в процессе разработки омничейн-продукта столкнулись с таким не раз.
Одна из самых больших ценностей — смарт-контракты. Это (упрощая) своего рода боты, которые умеют выполнять какую-то часть работы. Они открыты, их могут читать все, и через это строится доверие. Чтобы выпустить смарт-контракт, обычно нужно позвать аудиторов, они подтвердят, что он работает так, как описано, и затем только его загрузят на прод. Ну или автор смарт-контракта может внезапно обновить его на отъём всех денег у населения, и тогда пострадает только его репутация.
В общем, добро пожаловать в мир разработки на ончейн-данных. Ща познакомлю вас с некоторым дерьмом. Начнём с того, как одномоментно полтора миллиона человек потеряли свои деньги после краха FTX.
Почему я отказался от разработки игр на Rust, часть 1
Предисловие: этот пост представляет собой очень длинный перечень мыслей и проблем, возникавших у меня за годы работы; также в нём рассматриваются некоторые из аргументов, которые мне часто говорили. В посте выражено моё мнение, сформировавшееся у меня в процессе разработки игр на Rust в течение многих тысяч часов на протяжении многих лет и после множества завершённых игр. Это не хвастовство и не показатель успеха, я просто хочу сказать, что вложил достаточно много усилий в Rust; здесь не получится сказать «когда наберёшься опыта, тебе всё станет понятно».
Пост не будет ни научной оценкой, ни A/B-исследованием. Это моё личное мнение после разработки игр на Rust маленькой инди-командой (два человека) в попытках заработать достаточно денег, чтобы финансировать процесс. Мы не одни из тех разработчиков с бесконечными финансами от инвестора и многолетним запасом времени. Если вы находитесь в этой категории и получаете удовольствие от многолетней разработки систем, то всё написанное ниже к вам не относится. Я рассматриваю всё с такой точки зрения: «Мне хочется создать игру максимум за 3-12 месяцев, чтобы люди могли сыграть в неё, а я — немного заработать». Статья не написана с точки зрения «Я хочу изучить Rust, а разработка игр — это весело», хотя это и вполне нормальная цель; просто она никак не согласуется с тем, чего хотим мы — заниматься разработкой игр коммерчески успешным и самодостаточным образом.
Мы выпустили несколько игр на Rust, Godot, Unity и Unreal Engine, и многие люди сыграли в них в Steam. Мы создали с нуля собственный игровой 2D-движок с простым рендерером, а также в течение нескольких лет использовали Bevy и Macroquad во многих проектах, некоторые из которых были очень нетривиальными. Кроме того, я бэкенд-разработчик на полную ставку и пишу код на Rust. Этот пост — не какое-то поверхностное мнение после изучения нескольких туториалов или разработки небольшой игры для геймджема. За три с лишним года мы написали сильно больше ста тысяч строк кода на Rust.
Задача этого поста — развеять популярные и часто повторяемые аргументы. Но это всё-таки субъективное мнение; по большей части я написал пост, чтобы не объяснять снова и снова одно и то же. Пусть это будет справочный материал о том, почему мы, скорее всего, откажемся от Rust как от инструмента для разработки игр. Мы ни в коем случае не планируем прекращать создавать игры, просто не будем делать это на Rust.
Как мечтать быть переводчиком, а стать Project Manager-ом и быть счастливым
Когда я закончила технический лицей с золотой медалью в конце нулевых, в Казахстане еще не было мейнстримом «войти в IT». Я мечтала стать криминалистом или переводчиком. Но сначала оказалось, что криминалист не должен падать в обморок при виде крови. Потом стало ясно, что правила сданных экзаменов в Казахстане позволяли стать мне только инженером‑электриком. Внезапно пришлось придумывать третий менее экстремальный вариант.
В одном из ведущих технических вузов Сибири мне очень вкусно описали специальность «Прикладная математика и информатика». Тут все выглядело надежно, потому что, если я не влюблюсь без памяти в науку, оставался еще план Б — стать программистом. Это значило, что на кусок хлеба с маслом заработать будет всегда можно, да и математику я любила. На том и порешили. Здесь нужно заранее сказать, что «будете работать менеджерами» от преподавателей звучало как оскорбление, а не похвала, но об этом дальше. С карьерой ученого все успешно получилось до Pre-Phd.
«Когда будет готово?». Декомпозируем задачи и оцениваем сроки без фатальных ошибок
Всем привет! Я Виктор Брыксин, руковожу разработкой Яндекс Телемоста. В статье поговорим про декомпозицию задач в проекте и как можно получить реальные сроки его выполнения.
Спойлер: вы все равно ошибетесь, прогнозируя сроки. Но что можно сделать? Минимизировать шанс на ошибки и сделать их менее фатальными. Я расскажу про рабочие инструменты, которые помогли мне в свое время, — брать их на вооружение или нет, решайте сами. Если вы не знаете, как подступиться к декомпозиции сложного проекта и с чего начать, — эта статья вам в помощь.
Вклад авторов
nmivan 2664.0romas1982 1226.0semen_grinshtein 917.2kesn 624.0fillpackart 604.0m1rko 595.2alizar 581.2ru_vds 573.2olegbunin 482.0uyga 471.0