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

Привет, друзья!

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

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

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

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

О том, как из нескольких орхидей возникла целая лаборатория микроклонального размножения, под катом…

Всё чаще можно заметить этот тезис в статьях, докладах, мнениях о ракетостроении. И действительно, в глобальном плане это так, новые возможности, характеристики вжимать из реактивных двигателей становится всё сложнее, а те же тяги по большому счёту не увеличиваются уже давно, самые тяговитые монстры двигателестроения были созданы во 2 половине 20 века, и современные движки от них недалеко ушли, хоть и прокачали другие характеристики и возможности. Например, F1, настоящий монстр, поднимавший в небо лунную ракету Сатурн V имел тягу 6,77 меганьютон, а самый современный Raptor от корабля Starship и ускорителя Super Heavy имеет тягу всего...2000 килоньютон. И он считается мощным двигателем. Ситуация складывается печальная. Можно ли как то улучшить ситуацию, сделать двигатели мощнее, экономичнее? Можно, и об этом статья.

Всем привет! Продолжаем придумывать, как можно использовать устаревший смартфон в новом качестве. Эта статья подготовлена по материалам второго сезона видеокурса “Galaxy Upcycling - новая жизнь старого смартфона”. В  уроках первого сезона мы уже сделали 3D-голограмму, проектор (и написали об этом статью на Хабр), микроскоп, часы, гирлянду, а сегодня делаем еще один исследовательский прибор.

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

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

С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей. 

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

Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.

На протяжении всей жизни мне приходится экономить вычислительные и сетевые ресурсы: сначала были компьютеры с 300 кГц (кило — не гига!) и 32 Кбайт RAM, интернет по dial-up. Потом я решал олимпиадные задачки. Теперь имею дело с терабайтами трафика и 50 млрд событий в сутки. И хотя современные телефоны в 1 000 раз мощнее любого оборудования двадцатилетней давности, я до сих пор оптимизирую. Думал даже, что это со мной что-то не так. Но потом понял, что все постоянно что-нибудь оптимизируют. 

Эта статья в меньшей степени о том, почему нужно бороться за производительность, и в большей о том, на что сейчас стоит заменить устаревший стек из JPEG, JSON, gzip и TCP — и как это сделать. 

Спойлер: у нас есть решение и мы его не только показываем — ссылки на open source в конце статьи.

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

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

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

Как вы думаете, что делают рекрутеры, когда видят "Alexandr, NOT OPEN FOR WORK"? Правильно, пишут "Алексей, рассматриваете вариант работать в X?" Я обычно игнорирую это, но тут мне предложили попытать счастья с Яндекс.Лавкой, и я не смог пройти мимо - интересно было, смогу ли я устроиться куда-нибудь, когда введут великий российский файерволл. К тому же за последние 3 года я проходил только два интервью, и мне показалось, что я не в теме, что нынче требуется индустрии. Блин, я оказался и вправду не в теме. И вы, скорей всего, тоже - об этом и статья.

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

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

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

Что такое EVM?

EVM — это среда выполнения для блокчейна Ethereum. Позволяет запускать код смарт-контракта путем компиляции в байт-код EVM.

Основы: Solidity → Байт-код → Opcode

Как вы знаете, код Solidity должен быть скомпилирован в байт-код перед развертыванием в сети Ethereum. Этот байт-код соответствует серии инструкций кода операции, которые интерпретирует EVM.

Исходный код: файл, написанный на языке программирования, таком как Java, Solidity.

Байт-код: скомпилирован из исходного кода и запущен на виртуальной машине, такой как JVM, EVM.

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

В этом посте будет проанализировано, как каналы Unix реализуются в Linux. Для этого мы напишем и в несколько итераций оптимизируем тестовую программу, которая записывает и считывает данные через канал.  

Потешу своё геймдизайнерское самолюбие и скажу, что у разработки игр и искусства много общего: ни та, ни другая область в достаточной мере не формализована и не изучена с научной точки зрения. Хотя попытки были: взять, к примеру, труд Иосифа Шиллингера «Математические основы искусств» из первой половины XX века.

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

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

У каждого клиента – свои предпочтения. Не только в выборе автомобиля, блюда на обед или корпоративной информационной системы. Клиенты любят выбирать программистов.

Ну, что программисты разные – ежу понятно. Считается, что клиенты предпочитают профессионалов. Мы тоже так думали, и искренне стремились сделать каждого своего программиста этим самым профессионалом.

Однако, несколько клиентов, ставя нам задачи, упорно твердили: пусть программирует Серёжа. Хотя Серёжа – лютейший говнокодер, объект всеобщей жалости и главный поставщик материалов для конференций на тему «Как не надо программировать».