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

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

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

Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.

Задержки продолжили копиться.

Вопрос ограничения доступа к данным встает при разработке многопользовательских систем почти всегда. Основные сценарии следующие:

1. ограничение доступа к данным для пользователей не прошедших аутентификацию
2. ограничение доступа к данным для аутентифицированных, но не обладающих необходимыми привелегиями пользователей
3. предотвращение несанкционированного доступа с помощью прямых обращений к API
4. фильтрация данных в поисковых запросах и списковых элементах UI (таблицы, списки)
5. предотвращение изменения данных, принадлежащих одному пользователю другими пользователями

Сценарии 1-3 хорошо описаны и обычно решаются с помощью встроенных средств фреймворков, например role-based или claim-based авторизации. А вот ситуации, когда авторизованный пользователь может по прямому url получить доступ к данным «соседа» или совершить действие в его аккаунте случаются сплошь и рядом. Происходит это чаще всего из-за того что программист забывает добавить необходимую проверку. Можно понадеяться на код-ревью, а можно предотвратить такие ситуации применив глобальные правила фильтрации данных. О них и пойдет речь в статье.

Привет! Меня зовут Константин Евтеев, я работаю в Авито руководителем юнита DBA. Наша команда развивает системы хранения данных Авито, помогает в выборе или выдаче баз данных и сопутствующей инфраструктуры, поддерживает Service Level Objective для серверов баз данных, а еще мы отвечаем за эффективность использования ресурсов и мониторинг, консультируем по проектированию, а возможно и разрабатываем микросервисы, сильно завязанные на системы хранения, или сервисы для развития платформы в контексте хранилищ.

Я хочу рассказать, как мы решили один из вызовов микросервисной архитектуры — проведение бизнес-транзакций в инфраструктуре сервисов, построенных с помощью паттерна Database per service. С докладом на эту тему я выступал на конференции Highload++ Siberia 2018.

Как можно несколькими строками кода распечатать непрерывный поток сообщений из Твиттера, добавив в него данные о погоде в местах проживания их авторов? И как при этом ограничить скорость запросов к провайдеру метеоусловий, чтобы они не внесли нас в черный список?

Расскажем вам сегодня, как это сделать, но сначала познакомимся с технологией Akka Streams, позволяющей работать с потоками данных в реальном времени так же просто, как программисты работают с LINQ-выражениями, не требуя при этом ручной реализации ни отдельных акторов, ни интерфейсов Reactive Streams.


В основе статьи — расшифровка доклада Вагифа Абилова с нашей декабрьской конференции DotNext 2017 Moscow.

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

В небольшой команде тимлид может попытаться судить обо всем происходящем на основе субъективных ощущений, но, чем больше компания, тем важнее использовать объективные данные и метрики. Александр Киселев (AleksandrKiselev) и Сергей Семенов в своем докладе на TeamLead Conf показали, как использовать данные, которые вы уже накопили, где взять дополнительные, и что они все вместе могут помочь определить неочевидные проблемы. И даже, аккумулировав опыт многих коллег, предложили варианты решения.


О спикерах: Александр Киселев и Сергей Семенов в IT мы уже больше 8 лет. Оба прошли путь от разработчика до тимлида и далее до product-менеджера. Сейчас работают над аналитическим сервисом GitLean, который автоматически собирает аналитику у команд разработки для тимлидов и CTO. Задача этого сервиса в том, чтобы технические менеджеры могли принимать свои решения на основе объективных данных.

Всем доброго! Как всегда немножечко о нас: курс "Руководитель разработки", несмотря на его новизну для как не совсем чистого "программерского" курса, оказался очень успешным в плане количества окончивших его: из более чем тридцати человек отсеялось всего четыре человека, да и то по не связанным с тематикой обучения причинам. Так что закончив один поток, запускаем теперь и второй, чуть обновив и добавив теперь ещё и открытые уроки, на которых можно познакомиться и с преподавателем — Станиславом Михальским, и в целом с тем, что даётся на нём.

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

Поехали.

«Всегда честно признавай свои ошибки, это притупит бдительность начальства и позволит тебе натворить новые.» Марк Твен

«Успешными преподавателями становятся те, кто выбирает это занятие для удовольствия»

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

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

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

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

Существует два основных пути становления топ-менеджмента в IT-компаниях:

1. Менеджерский — когда менеджер проекта начинает управлять другими менеджерами.
2. Технарский — когда разработчик начинает управлять другими разработчиками и количество управляемого им персонала увеличивается.

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

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

Цель статьи — рассказать немного о MSBuild, показать что такое таргеты и таски в MSBuild, научить работать с файлом .csproj, дать полезные ссылки. Если у вас будет более подходящее название для статьи, то буду рад обсудить в комментариях.

Меню

• Основные понятия — что такое target и task в MSBuild
• Жизненный цикл сборки MSBuild — какая последовательность вызова таргетов
• Подготовка окружения для примеров
• Таргеты в MSBuild — пример использования некоторых таргетов MSBuild
• Создание собственного таргета MSBuild
• Таски в MSBuild — пример использования некоторых тасков MSBuild
• Переменные и макросы в .csproj
• Ссылки

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

Этим постом как раз постараемся на все и ответить. Пару месяцев назад для студентов нашей Школы мы запустили линейку мастер-классов про выгорание. Приглашали не просто тех, кто умеет бодро и зажигательно говорить (это мы и сами умеем), а, прежде всего, профессионалов психотерапии, кто уже много лет занимается тем, что успешно работает со счастливыми обладателями синдрома выгорания:

1. Дмитрий Ковпак, кандидат мед.наук, президент российской Ассоциации когнитивно-поведенческой психотерапии (КПТ), доцент кафедры психологии и педагогики СЗГМУ им. И.И. Мечникова.

2. Алексей Демьяненко, психотерапевт, заведующий Городским Психотерапевтическим Центром Санкт-Петербурга, руководитель регионального отделения Российской Психотерапевтической Ассоциации.

3. Наталия Дзеружинская, доктор мед.наук, врач-психиатр высшей квалификационной категории, профессор кафедры психиатрии и наркологии Национального медицинского университета имени А.А. Богомольца Украины. Более 30 лет работы в сфере психического здоровья.

4. Мария Берлин, организационный психолог, тренер, корпоративный психолог ЗАО РТК МТС(2015-2016), преподаватель института «Иматон», автор программы подготовки специалистов «Работа с эмоциональным выгоранием – комплексный подход».

В итоге у нас накопилось пять мастер-классов (видео под катом). Видео изначально были доступны только нашим студентам. Но раз тема оказалась актуальной для Хабра, решили все это выложить — пользуйтесь на здоровье.

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



В последние годы микросервисы стали очень популярной темой. «Микросервисное безумие» выглядит примерно так:

«Netflix хороши в DevOps. Netflix делают микросервисы. Таким образом, если я делаю микросервисы, я хорош в DevOps».

Однажды перед нами встала задача автоматизировать различные workflow в крупной компании. Для нас это значило соединить воедино на момент старта порядка 10 систем. Причем связать всё надо было асинхронно, масштабируемо, надежно.

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

Для решения этой задачи мы решили использовать архитектуру обмена сообщениями через шину данных, и нам отлично подошел MassTransit с его Saga в связке с RabbitMQ.

Приветствую, товарищи!

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

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

Я решил не делить его на отдельные куски — так информацию искать будет проще. Надеюсь что не сильно нарушу тематику ресурса, пусть НЛО нас рассудит.


Flumserberg. Здесь и далее — обычно мои фотографии, которые мне показались более или менее приличными :)

Данная публикация является разбором особенностей контейнерной виртуализации Docker под системой Windows.

Она не претендует на роль исчерпывающей и по мере необходимости будет обновляться и дополняться.

За практическим руководством с нуля советую обратиться к этой публикации.

Содержание

• Предварительные настройки
• Выбор между Docker Toolbox on Windows или Docker for Windows
• Windows контейнеры и Linux контейнеры
• Особенности монтирования папок
• Монтирование с хост-машины или volume
• Особенности разметки диска GPT и MBR
• Docker Toobox to Windows
• Docker Swarm
• Проблемы с кодировкой
• Полезные ссылки
• Заключение

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

Под катом рассказ Филиппа Дельгядо (dph) на Highload++ про опыт, накопившийся за несколько лет работы над платежной системой для российского легального букмекерского бизнеса, про ошибки, но и про некоторые достижения, и про то, как грамотно смешать, но не взбалтывать, web с enterprise.

Расскажу о профессиональной эмиграции разработчика в Финляндию. У меня никогда не получалось писать кратко, а тема очень большая, но попробую :)



Я переехал в Финляндию полгода назад, причем не в Хельсинки, как большинство, а в небольшой город Вааса на западном побережье — население 65 тыс. Финляндию я до этого давно и прочно любил, жил в Питере и последние несколько лет постоянно туда катался и изучал страну — примерно 35 въездов в нее туристом было.

Зачем НЕ нужно переезжать в Финляндию

Финляндия — несмотря на благополучие, страна не для каждого.

Во-первых, здесь НЕ стоит ждать очень высоких зарплат, не в IT по крайней мере. ЗП разработчиков хорошие, значительно выше среднего по стране, но далеко не огромные. После налогов они сравнимы с обычными московскими или хорошими питерскими, при более высокой (хотя и не в разы) стоимости жизни. В некоторых странах Европы были бы больше, в Штатах — сильно больше. Зарплат вполне хватает для более чем достойной жизни (ипотека-машина-путешествия-хобби), но богатым тут стать трудно.

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

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.

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

До моей работы в Uber у меня не было опыта работы с распределёнными системами. Я получил традиционное образование в Computer Science, после чего с десяток лет занимался full-stack разработкой. Поэтому, пусть я и мог рисовать различные диаграммы и рассуждать о компромиссах (tradeoffs) в системах, к тому моменту я недостаточно хорошо понимал и воспринимал концепции распределённости — такие, например, как согласованность (consistency), доступность (availability) или идемпотентность (idempotency).

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

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

Итак, давайте приступим к нашему погружению в SLA, согласованность, долговечность данных, сохранность сообщений, идемпотентность и некоторые другие вещи, которые мне потребовалось выучить на своей новой работе.

Привет!

Сегодня мы немного поговорим про EntityFramework. Совсем чуть-чуть. Да, я знаю что к нему можно относиться по-разному, многие от него плюются, но за неимением лучшей альтернативы — продолжают использовать.

Так вот. Часто ли вы используете в своём C#-проекте с настроенным ORM-ом прямые SQL-запросы в базу? Ой, да бросьте, не отнекивайтесь. Используете. Иначе как бы вы реализовывали удаление/обновление сущностей пачками и оставались живы…

Что мы больше всего любим в прямом SQL? Скорость и простоту. Там, где "в лучших традициях ORM" надо выгрузить в память вагончик объектов и всем сделать context.Remove (ну или поманипулировать Attach-ем), можнo обойтись одним мааааленьким SQL-запросом.
Что мы больше всего не любим в прямом SQL? Правильно. Отсутствие типизации и взрывоопасность. Прямой SQL обычно делается через DbContext.Database.ExecuteSqlCommand, а оно на вход принимает только строку. Следовательно, Find Usages в студии никогда не покажет вам какие поля каких сущностей ваш прямой SQL затронул, ну и помимо прочего вам приходится полагаться на свою память в вопросе точных имён всех таблиц/колонок которые вы щупаете. А ещё молиться, что никакой лоботряс не покопается в вашей модели и не переименует всё в ходе рефакторинга или средствами EntityFramework, пока вы будете спать.

Так ликуйте же, адепты маленьких raw SQL-запросов! В этой статье я покажу вам как совместить их с EF, не потерять в майнтайнабильности и не наплодить детонаторов. Ныряйте же под кат скорее!