Системный архитектор
Украинский ресурс DOU.UA (Developers.Org.Ua) провел зарплатный опрос среди IT-разработчиков, в котором приняло участие 10280 украинских специалистов. Более половины из них 5359 это разработчики: Software Engineers, Tech/TeamLeads и System Architects. Все зарплаты указаны в долларах США по курсу межбанка, чистыми, т.е. после уплаты всех налогов.
Данные в CSV доступны на GitHub. Для оценки зарплат в выборках используется медиана.
Если у подростка, а потом и у взрослого тоже нет планов на собственное будущее — вы уже знаете ответ. До этого важного тезиса мне пришлось идти овердофига лет.
Иными словами.
Сколько стоит час работы сотрудника? Это обязаны знать в любой компании, которая продаёт свои часы. А тем, кто не продаёт, а покупает, не лишним будет понять, почему именно столько просят подрядчики, и сколько на самом деле стоят внутренние проекты. Давайте разберёмся, как мы считаем стоимость часа и что туда входит.
PostgreSQL хранит данные на каких-то носителях. И между PostgreSQL и, например, магнитной поверхностью диска находится несколько кешей: кеш самого винчестера, кеш RAID-контроллера или винчестерной полки, кеш файловой системы на уровне операционной системы и кеш самого PostgreSQL. Если первыми перечисленными кешами мы практический не можем управлять, то последними, находящимися в ОЗУ сервера, управлять можем: например, выделяя больше ОЗУ под кеш PostgreSQL в ущерб кешу ОС, или наоборот. В официальной документации можно прочитать ничем не подтвержденные рекомендации, типа выделять под PostgreSQL четверть ОЗУ. Это вызывает сомнения. PostgreSQL в виде Postgres95 впервые появился в 1995 году и, кто знает, быть может и эти рекомендации относятся к тому же году. Поэтому появилась идея эксперимента с целью разобраться, как лучше распределять ОЗУ.
Прим. перев.: автор этой статьи — Ben Nadel, сооснователь и главный инженер InVision App Inc. Миссию своей команды, поддерживающей серверную инфраструктуру компании, он сам характеризует как «advocate for the users», т.к. её главная цель — гарантировать пользователям InVision «получение опыта, который они заслуживают». Его опыт — яркая иллюстрация того, что микросервисы не серебряная пуля.
Если вы следите за мной в Твиттере, то наверняка заметили, что периодически я публикую победные твиты о возвращении одного из наших микросервисов в InVision обратно в монолит. Обычно эти твиты сопровождаются гифкой, в которой Танос вставляет последний Камень бесконечности в Перчатку бесконечности. Нахожу ее вполне уместной, поскольку воссоединение камней придает Таносу невероятную силу — так же, как воссоединение микросервисов придает силу мне и моей команде. Меня много раз спрашивали, почему я избавляюсь от микросервисов. Настало время поделиться своими мыслями по поводу этого путешествия в мире разработки веб-приложений…
В предыдущей статье я рассказывала, в чём сходство задач и инструментов тимлида и психолога, и обещала ответить на вопрос, зачем тимлиду это надо.
Ну правда, зачем? Задача тимлида – сделать всё, чтобы команда работала эффективно. Зачем быть искренним и эмпатичным, если люди – это ресурс, и вы умеете ими управлять?
Но мы все люди, а не какой-то безличный ресурс. А значит, для качественного взаимодействия друг с другом нам необходима эффективная коммуникация. Овладев ею, вы сможете разбираться с конфликтами в команде, а в некоторых случаях не допускать их, понимать мотивацию и интересы сотрудников. Есть и ещё кое-что важное: вы наладите коммуникацию с собой, разовьёте самосознание и здоровую рефлексию.
С этого и начну.
Предположим, вам надо обработать на PostgreSQL большое (не, не так... БОЛЬШОЕ) количество записей, чтобы посчитать какие-нибудь агрегаты. В предыдущей статье были разобраны различные варианты, как это можно организовать, а в этой посмотрим, как при этом особо никого не заблокировать, включая "набегающий поток" данных.
Например, это может быть пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок, или что-то еще... В любой управленческой системе подобных задач наберется горка, и СБИС тоже не является исключением.
Но у всех этих ситуаций есть общий момент - количество изменений сильно больше количества целевых агрегатов. Например: тысячи товаров, по каждому десятки тысяч отгрузок в день.
Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?
При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.
В данной статье мы коротко пройдемся по теории и на практике разберемся как перевести любое Legacy приложение на гексагональную архитектуру. Повествование будет в контексте фреймворка Symfony и PHP 7.4, но синтаксис приведенных примеров настолько прост что вы без труда поймете как сделать так же на вашем языке программирования (если он поддерживает ООП).
За свою карьеру я работал над многими проектами Symfony, и одна из самых частых проблем, с которыми клиенты звонят в нашу компанию, заключается в том, что их программное обеспечение «заблокировано» старой версией фреймворка или оно стало необслуживаемым, потому что поиск и исправление ошибок обходится слишком дорого.
С течением жизни приложения в его БД накапливается все больше данных. Десктопное оно, SaaS или даже мобильное - неважно, в современном мире почти каждый что-то хранит "у себя".
Если это какая-то локальная утилита - не страшно, само ее существование у пользователя достаточно ограничено. Но если это что-то вроде нашего СБИС, который накапливает и помогает анализировать операции за все время существования бизнеса, то, по мере его роста, не только операций становится больше, но и понимания, какие именно сводные отчеты помогают в оперативном управлении.
Вот про то, как сделать такие отчеты быстрыми, какие бывают способы их реализации и встречаются "грабли" на этом пути, сегодня и поговорим.
Эта статья для тех первооткрывателей, которые запускают свою первую компанию, которая конечно же должна сделать мир лучше.
Речь пойдет о том, что нельзя пощупать, но можно и нужно знать и понимать. Без чего не стоит не только мечтать о единороге, но даже и начинать не стоит. Поговорим о мотивации основателей и о том, какие испытания духа ждут каждого фаундера.
Как часто мы задаемся вопросом о том, почему порой так сложно настроить себя на некоторые виды деятельности?
Многие из нас имеют план намеченных дел. Однако, немногим удается хотя бы что-то из этого списка просто начать делать. Причем, в некоторых случаях бывает, что настолько мы не хотим чем-либо заниматься, что в принципе перестаем делать что-либо из того, что определили для себя как нечто обязательное. Как будто кто-то внутри нас сидит, и каждый раз берет верх над нашим желанием заняться чем-то полезным, провоцирует нас на мало значимые и повторяющиеся изо дня в день действия, которые отвлекают от чего-то более важного.
Мы можем часами тратить время на различные и не всегда полезные занятия. И делаем это практически на автомате. А потом ругаем себя за то, что в очередной раз потратили продуктивное время на непродуктивные дела. Сталкиваясь с подобным поведением, мы даем себе обещание, что в следующий раз займемся тем, что запланировали. Вместо этого делаем то, что делали раньше.
В рамках бесплатного спринта по созданию презентаций для стартапов я перевела полезные советы от Y Combinator.
Y Combinator — лучший в мире акселератор для стартапов по количеству единорогов (25), по объему привлеченных инвестиций ($27 млрд) и по капитализации выпускников ($300+ млрд). 125 компаний с оценкой $150M+
Ниже приведена адаптация презентации, которую я даю стартапам YC, прежде чем мы попросим их создать свои презентации для Demo Day.
Вот как сделать надежную презентацию для Demo Day. Следует помнить, что у вас уже есть все необходимое для создания отличной презентации.
Вероятно есть 100 причин, почему ваша компания великолепна, но люди смогут вспомнить парочку из них после короткой презентации или питча. С каждым из вас мы сели и выяснили 5-7 самых важных идей, которые люди должны знать о вашем стартапе. Вы хотите, чтобы инвесторы запомнили именно эти 5-7 пунктов.
Как вы уже поняли после Prototype Day, вам повезет, если они смогут вспомнить хотя бы 1 или 2 из этих пунктов в контексте 100 других компаний, презентующихся вместе с вами.
Потому что государство – это продукт. Со своими метриками, экономикой, жизненным циклом. У граждан-пользователей есть и лайфтайм, и отток, и средний чек. Да и цели те же: найти свою нишу на мировом рынке, решить боли пользователей, повысить выручку и капитализацию. Только вот чиновники, которые управляют нашими странами, угробили бы любой стартап примерно сразу.
С момента своего создания JavaScript всегда был ориентирован на создание инновационного пользовательского опыта (UX - User Experience). Он позволяет разработчикам создавать максимально интуитивно понятный и удобный UX под конкретную задачу.
Однако на практике создание отличного пользовательского опыта с помощью JavaScript не такая простая задача. Потребуется немало времени, чтобы выбрать надежные пакеты, настроить их, интегрировать на свои страницы и заставить интерфейсный код взаимодействовать с остальной частью вашей инфраструктуры.
Эта проблема не нова: она очень похожа на состояние Symfony в PHP до появления Symfony Flex. Нам нужен эквивалент Symfony Flex для JavaScript - инструмент способный создавать прекрасный пользовательский опыт так же быстро, как теперь мы можем настроить HTTP-клиент, почтовую программу или панель администрирования.
Процесс документирования архитектуры программного обеспечения может показаться пугающим. Но на самом деле достаточно всего 5 диаграмм, чтобы объяснить структуру вашей системы практически любому.
