Управление разработкой *

За последнее десятилетие мы убедились, что выполнение вручную процессов расследования и реагирования ограничивает нас по скорости, что сильно сказывается на возможности обрабатывать прирастающий с каждым днем поток инцидентов и угроз. Для того, чтобы помочь в решении складывающейся ситуации специалисты ИБ начинают применять в своей практике новые подходы, такие как Everything as Code (EaC), который зародился на базе практик разработки ПО.

Одна из основных проблематик обнаружения инцидентов, процедур Threat hunting и обнаружения угроз (TI) — высокая гранулярность скриптов и функций, необходимость контроля версий и учета изменений. Поэтому инженеры по информационной безопасности, стремясь повысить эффективность детекта и улучшить качество работы переняли лучшие практики из IT-разработки и назвали этот метод Configuration-as-Code. Давайте разберемся, что он из себя представляет.

Привет. Меня зовут Александр Калинин, я работаю фронтенд разработчиком в SM Lab на проекте Client Service Management. Занимаюсь разработкой веб-приложения на vue для работы с заказами клиентов Спортмастера.

На нашем проекте всего два фронтенд-разработчика, и мы вдвоём на протяжении почти года спорили о том, как лучше раскладывать файлы по папкам. Чуть меньше мы спорили о том, как называть файлы и папки. Затем перешли к расположению.

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

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

У нас примерно такое содержание папки scr:

Познавательные книжки Перельмана (который Яков) очень мне нравились с детства. Один из поразивших меня тогда примеров касался сложения усилий лошадей, тянущих одну повозку.

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

Искренне извиняюсь за такую нетехническую заметку, но прям "наболело" :)

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

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

В этой статье расскажем, как все это работает.

Привет. На связи Саша Липин, продакт-лид Garage Eight. Расскажу, какие методы приоритизации продуктовых штук я пробовал, для чего хорош каждый из них и на что опираться при выборе.

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

Приступим.

Метрики поддержки

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

Поддержка покрывает важные бизнес-риски, такие как сбои, аварии, недостатки продукта и негативный пользовательский опыт. Всё это нагромождение рисков вполне можно разделить на две категории:

Всем привет! Я Светлана Кирдяйкина, старший инженер по тестированию в Авито. Если вы задумываетесь про оптимизацию своего времени и улучшении тестирования — эта статья точно будет вам интересна. Здесь я постаралась простым языком описать факторы, на которые стоит обратить внимание перед тем, как начинать автоматизацию.

Недавно мы приступили к первому этапу эксплуатации автономных грузовиков Яндекса. Их уже можно встретить на трассе М-4 «Дон» между Москвой и Тулой, а 10–13 декабря посмотреть на грузовик могут посетители выставки COMTRANS International 2024 в «Экспоцентре».

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

Меня зовут Кирилл Зуев, вот уже шесть лет я управляю проектами по разработке платформ в направлении автономного транспорта Яндекса. Сегодня расскажу, как мы разрабатывали и запускали свой автономный грузовик, сколько вложили в этот проект сил, знаний и опыта, а также с какими трудностями столкнулись и как их преодолели.

Однажды команда открыла для себя 'Plus for Trello' — уникальное браузерное расширение для Trello, которое стало одним из лучших инструментов для учёта рабочего времени и ведения скрама небольшой командой. В этой статье расскажем о том, как этот плагин использовался в рабочем процессе, как Obsidian смог подхватить эстафету после его «смерти», и будет представлен проверенный временем шаблон проекта Obsidian для командной работы по scrum.

«Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к лучшему». Clean Code

Есть, куча вопросов, которые каждый задавал себе в той или иной интерпретации, но не каждый мог на них ответить.
Почему IT — пираты XXI века?

В чём конфликт бизнеса и разработки?

Что общего у керамической чашки и IT‑бизнеса?

Откуда берутся непроницаемые для опыта люди?

Чем схожи кот и плохой инженер?

Рассказал об этом Александр Бындю на встрече комьюнити Skillbox Code Experts. Я облекла наше двухчасовое общение в формат интервью, чтоб поделиться самыми интересными мыслями и тезисами нашей беседы.

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

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

Почему крупные компании выбирают аутсорсинг и аутстаффинг?

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

Для кого может быть полезна эта статья:

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

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

Процессы в командах — больная тема. Где-то в команде, состоящей из сеньоров, лидов, star-level-devs и одного РП, изменение процесса приводит к проседанию разработки в полтора раза. А на каком-нибудь стартапе джуны при командной оценке страдают от однообразия и ожидания своей очереди.

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

Думаю, все любят разрабатывать новый функционал приложений, сервисов, микросервисов и пр. И наверное, мало кто любит заниматься инфраструктурными работами. Например, портировать код на другую операционную систему или портировать код на другую микропроцессорную архитектуру, или же «отвязывать» вычислительную логику от графических интерфейсов (если вдруг приложение долгое время развивалось так, что отделение вычислений от графики никого не заботило)…

Тем не менее, инфраструктурные проекты тоже важны, и время от времени их приходится делать.

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

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

В этой статье мы, во-первых, разберём клинический пример, а во-вторых, поговорим про эффективные практики реализации масштабных инфраструктурных проектов.

Ранее я написал несколько статей про подключение беспроводных Zigbee-устройств к контроллеру Wiren Board. Сначала я использовал для программирования сценариев оболочку Sprut.hub, затем перешел на Node-RED. Наконец, я разобрался в языке программирования wb-rules и написал сценарии на нем. Недавно я начал знакомиться с ChatGPT и удивился тому, что он умеет в wb-rules.

Что ж настало время проверить возможности ChatGPT. Сможет ли он запрограммировать на wb-rules сценарии, которые я использовал в своих статьях ранее? Проверим!

Для начала представлюсь — я разработчик с более чем 15-летним стажем. За это время я работал в самых разных компаниях — от маленьких стартапов до крупных корпораций, в одиночку и в больших командах. Хочу рассказать о несправедливости в IT, с которой мне пришлось столкнуться.

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

Оу, таблица merchants2? Ну, у нас кончились столбцы в merchants, так что мы сделали merchants2.

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