Привет! Меня зовут Игорь Веденеев. До 2022 года я возглавлял отдел мобильной разработки в AGIMA. Это было, пожалуй, самое интересное и полезное время, которое многое мне дало в профессиональном и личностном плане. Но при этом все 2 года на этой должности я периодически спрашивал себя, насколько я полезен и нужно ли было идти на этот шаг в карьере.

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

Привет, Habr! На связи Андрей Непряхин, СТО компании AGIMA. В этой статье я расскажу о том, какие стили лидерства существуют, как их нужно применять на различных стадиях развития команды.

Привет, Хабр! Я Саша Шутай, руководитель направления PHP в AGIMA. Хочу обсудить важные для тимлидов вопросы: как управлять бэклогом и правильно распределять время, нормально ли отвлекаться во время работы, как овертаймить, не выгорать и успевать жить. Статья в первую очередь будет полезна начинающим тимлидам. Ну а матерые руководители команд найдут в ней советы по оптимизации работы.

Менеджеров проектов можно классифицировать тысячей разных способов: по опыту, по навыкам, по вовлеченности или по сфере работы. Но мы выбрали самый сложный — классифицировать по их манере управления. Один PM на всё готов и вписывает команду в любой движ, другой — напротив, отказывается от активностей и всячески оберегает «своих» от перегруза. В общей сложности мы насчитали 16 ярких типажей. Попробуем разобрать плюсы и минусы каждого.

Нас зовут Аня Ионова и Миша Дырма, мы оба уже много лет работаем в AGIMA, оба прошли путь от линейного проджекта до руководителя проектного офиса. За эти годы мы вырастили десятки РМ-ов, а общались, наверное, с сотнями, если не с тысячами. Мы поняли, что это хороший материал для — немного субъективного — обобщения. В этой статье мы описываем те типы управления, которые видели собственными глазами. А заодно — даем рекомендации, как выявить и грамотно применить скиллы каждого PM.

Всем привет! Я Саша Ворожищев, руководитель мобильной разработки в AGIMA. В интернете сотни статей о том, как важно не выматывать себя на работе, но всё без толку. Согласно недавнему исследованию Хабр Карьеры, более 90% российских IT-специалистов сталкивались с выгоранием. При этом более 40% доводят себя до поздних стадий, когда эмоциональное истощение уже перерастает в депрессию.

В этой ситуации будет полезным напомнить, что любой руководитель может влиять на состояние команды. И это важно не только с точки зрения человеколюбия, но и с точки зрения бизнеса. В конце концов энергичный сотрудник, который любит свою работу, принесет компании больше счастья, чем выгоревший и усталый. Поэтому давайте разберем, как мотивировать команду соблюдать Work-life balance.

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

И начинают доходить руки у отделов валютного контроля ФНС, позадавать вопросы физлицам-резидентам, кто по мнению ФНС должен был представить отчеты по зарубежным счетам до 01 июня 2024 года, но почему-то это не сделал.

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

Тема статьи: коммуникации РП и команды: как это делать правильно, а как неправильно, и к чему это вас приведет.

Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».

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

Все нижесказанное основано на моем личном опыте, как РП с опытом 25 лет и РПО с опытом 10 лет.

> С 10 апреля 2024, 3 месяца спустя,
> данная статья заблокирована РКН на территории РФ,
> но доступна с IP других стран, а также через веб-архив.

На фоне прошлогоднего обострения цензуры в РФ, статьи автора MiraclePTR стали глотком свободы для многих русскоязычных айтишников. Я же хочу приоткрыть дверь к свободной информации чуть шире и пригласить «не‑технарей» («чайников»), желающих поднять личный прокси‑сервер для обхода цензуры, но дезориентированных обилием информации или остановленных непонятной технической ошибкой.

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

Статья рассчитана на «чайников», не знакомых с предметной областью. Однако и люди «в теме» могут найти нечто полезное (например, чуть более простую настройку проксирования через CloudFlare без необходимости поднимать nginx на VPS).

Если у вас ещё нет личного прокси для обхода цензуры — это знак.

Язык программирования Scratch — это относительно молодой язык, который появился в 2007 году как способ обучения детей кодингу. Он прост, интерактивен и доступен для ребят, так как в нем не нужно писать строчки кода, составлять скрипты с тегами и классами, подключать внешние библиотеки. Scratch сравним с детской компьютерной игрой: у вас есть сцена, на которой происходит действие с персонажами. Они могут прыгать, бегать, кидать мяч, гонять на машинках и выполнять любые другие действия. Чтобы создать в Скретч программу, нужно построить её из специальных «кирпичиков» — цветных блоков-операторов. Так, при помощи синих блоков мы перемещаем объект на поле, зеленым блоком проводим все математические действия и настраиваем логику, красным задаем значения переменных и так далее.

Привет!

Меня зовут Андрей и я руковожу IT-подразделением. Около 5 последних лет я работаю в Яндексе с командами от единиц до сотен инженеров. Так сложилось, что команд я потрогал много и разных: некоторых руководителей от времени перемещают по частям компании и зонам ответственности и я – не исключение.

За свой не самый продолжительный, но очень интенсивный карьерный трек я увидел большое количество разных управленцев. Часть – я вырастил из своих ребят до уровней M1 и M2 (руководителей групп и служб). Часть – нанял. Часть – достались мне в наследство.

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

Я хочу поделиться с читателем (предположительно – начинающим или уже опытным руководителем) школой мысли, которая снижает вероятность большинства известных мне видов ошибок. Фреймворк – очень простой концептуально и широко применимый. Я был бы рад, получив его в начале своего карьерного пути и буду счастлив, если эта статья поможет хотя бы одному руководителю стать лучше.

Ну что, поехали?

Вероятно, вы уже слышали о соревновании под названием "The One Billion Row Challenge" (1brc), если же нет, то предлагаю ознакомиться с репозиторием 1brc Гуннара Морлинга.

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

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

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

Хочется рассказать о нашем опыте внедрения CI/CD в компанию. О том, как в целом работать с ним и как это работает у нас.

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

Приятного прочтения, всем peace!

Если вы не курите, не занимаетесь экстремальными видами спорта и не переписываетесь за рулём, то с 80% вероятностью вы умрёте от развития и последствий следующих четырёх (в порядке смертоносности) проблем. Или, как Питер Аттия в своей книге Outlive, красочно и устрашающе назвал их «Четырьмя всадниками смерти» (The Four Horsemen).

Сегодня всё больше и больше сервисов объявляют о своей поддержке ActivityPub, в том числе даже такие, как Tumblr или Threads. И это ожидаемо, так как ActivityPub позволяет сохранять контроль над собственными данными, в отличие от закрытых сервисов Meta. Кроме того, это позволяет обмениваться данными более независимо (Fediverse). Применение ActivityPub не ограничивается социальными сетями и блогами. Есть сервисы для хостинга изображений, видео, музыки и многое другое.

Если рассматривать все эти активности как события, то это позволит сервису Awakari открыть целое новое измерение в Fediverse. Используя Awakari можно отслеживать интересные события из неограниченного множества источников.

У моего знакомого в гараже стоял Ford Crown Victoria начала 80-х — красавец тёмно-вишнёвого цвета. История его попадания в гараж длинная и невероятная, но был нюанс: Форд был не на ходу. Точнее, он ездил только задним ходом. Хозяин, само собой, справедливо полагал, что такой метод передвижения несколько унизителен для королевы, поэтому всеми силами пытался машину починить. Поскольку дело было в самом начале 2000-х, деньги на это уходили немалые: по сути, в кузове потихоньку пересобирали новый автомобиль. Стоило это примерно как два Ford Focus того времени. Итог печальный: хозяин умер, дальнейшая судьба так и не поехавшего вперёд автомобиля неизвестна и, думается, незавидна. Все годы ремонта семья ездила по делам и на дачу на общественном транспорте. И, если честно, таких историй много: будучи привязанным к вещам, люди не успевают нормально жить. 

Как я уже не раз писал, бизнес ничем не отличается от людей, потому что его создают, ведут и уничтожают тоже люди. Так вот, нередко компании начинают заниматься тем же самым: строить вигвамы из подручных средств, тратить время, простаивать и в конечном итоге проигрывать. У этих процессов много имён, одно из них — самописная CRM-система.

Привет! Я Алексей, iOS-разработчик в Тинькофф. Участвую в развитии архитектуры приложения, провожу собеседования и занимаюсь менторингом разработчиков.

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

Нет времени объяснять! Bytedance тестирует платформу создания АИ ботов, coze.com, в том числе на базе gpt-4/gpt-3.5/Dalle-3 с возможностью интеграции в телеграм/дискорд. На данный момент ограничений практически нет, бесплатный доступ к огромному количеству сервисов, включая платные. Сервис доступен в России и еще в ряде стран.

Есть возможность создавать сложные workflow, добавлять кастомные плагины/апи, да практически что угодно можно сделать. Я покажу на примере нескольких ботов. Простой gpt бот - переводчик, чуть более сложный - для написания кода на питон, с возможностью "гуглить" и очень сложный, для генерации изображений в Dalle, с сложным воркфлоу, кастомными плагинами/вставками кода/условиями и так далее. Поехали!

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

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