— Реклама — Пост проплачен —-

Илья Зеленчук @Zelenchuk, основатель BigXP (онлайн-консультации с ИТ-специалистами) ищет специалиста по разработке Desktop приложений для Windows.

Нужно пообщаться с человеком на тему построение решений и оптимального использования технологий: может следует использовать Windows Presentation Form, WebForms, ASPnet или что-то ещё?

Будет супер круто, если сможете сравнить несколько существующих подходов, приложить ссылки для наглядного их представления, рекомендации к использованию того или иного подход.

Общение не бесплатное, конечно! Стучитесь в личку: @Zelenchuk

Отчётики
(фишечка из старенького)

Не такая уж и редкая ситуация, когда бизнесу надо построить сложные отчёты на основе, например, списка пользователей сервиса (100k+). Отчёты обычно просят не самые простые как раз потому, что самостоятельно бизнес и не может сам сделать.

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

Для ускорения процесса было бы идеально или запихать всё в Excel (лучше конечно заюзать Excel Power Pivot, подсказывает Иван Повстен) и отдать задачку на какой-нибудь фриланс-бирже, чтобы из данных сформировали всё, что надо. В принципе там за 1-3 тысячу рублей и за несколько часов вполне реально получить практически любого коня с перламутровыми пуговицами. Экономия громадная, - и на времени и на бабле.

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

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

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

Вот пример исходной таблички:

 Номер клиента   Номер заказа    Клиент  Номер ДС        Состояние
83753   31295   Дина Варава     89996748        Передано на Почту России
83744   39212   Алекс Гузик     89995484        В доставке
707610359       707610359       Аникина Дарья   89993430        Передано на Почту России
657597666       657597666       Коломийчук Денис        89993422        Передано на Почту России
83736   31286   Николай Бочкарев        89993075        Передано на Почту России
66533   31184   Фёдор Замятин   89992572        Передано на Почту России
66533   31284   Фёдор Замятин   89213242        Передано на Почту России

А вот результат обфусцирования:

 Kwsjq tacoocb   Fwnod cysvmf    Itutvs  Humly IY        Ltqreflvd
22776   64670   Uhov Dkoirq     34355175        Svionxkd jw Hitlo Icsjou
21261   74885   Npopm Ktdpk     63688838        W xxwmmehl
444805037       533302151       Almsbsw Hbbtn   50672520        Svionxkd jw Hitlo Icsjou
038783307       867483713       Welvjfxjwa Pqcrp        53311325        Svionxkd jw Hitlo Icsjou
17233   73463   Numgvco Mgxoekph        34871684        Svionxkd jw Hitlo Icsjou
18743   55506   Beyta Bkecibq   02342714        Svionxkd jw Hitlo Icsjou
18743   62415   Beyta Bkecibq   68851814        Svionxkd jw Hitlo Icsjou

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

Вот скриптик для обфусцирования csv на Python: https://ctorecords.shortcm.li/obfuscate (есть на других языка: php, perl. На днях выложу вариант для node.js и go).

UPDATE от Андрея Копейко для тех, кто не хочет мелочиться: тулза сразу для обфускации сразу всей бд на постгре https://gitlab.com/dalibo/postgresql_anonymizer

Юнит-дампики
(фишечка из старенького)

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

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

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

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

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

Как построить такую систему? Самый дешёвый способ, взять sql дамп вообще всей БД (обычно они очень тяжёлые) и тупо погрепать по колонке с user_id. Функционально такой греп можно запустить мгновенно (лучше всё же zgrep, чтобы не распаковывать дамп), хотя и работать он будет много минут, дав в результате sql юнит-дамп

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

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

- —— Реклама — Пост проплачен —-

Ищут технического директор/CTO в продуктовую разработку

АО «Инфотех Груп» (Infotech Group) — российская компания-разработчик программного обеспечения для крупных корпораций, государственных структур, среднего и малого бизнеса. Основными направлениями автоматизации являются промышленность, электроэнергетика, безопасность и охрана, городское хозяйство. Все продукты строятся на базе собственной программной платформы INFOTECH. В своих разработках компания использует технологии машинного зрения, Big Data, нейронные сети, экспертные модели классической диагностики.

Задачи:
- Создание стратегии технологического развития компании;
- Выбор технологических решений для продуктов Компании;
- Формирование архитектурного облика продуктов Компании;
- Оценка технологических решений для продуктов с точки зрения финансовых, временных и других аспектов;
- Планирование и построение процессов продуктовой разработки;
- Формирование команд продуктовой разработки;
- Распределение задач между командами;
- Формирование продуктовых стратегий и отслеживание их реализации;
- Обеспечение темпа и качества продуктовой разработки на максимальном уровне;
- Управление технологическими рисками;
- Управление, оценка, обучения, аттестация команд и сотрудников Департамента разработки;
- Взаимодействие с менеджерами продуктов и руководителями смежных подразделений;
- Ответственность за результат подразделения.

Знание технологического стека важного для заказчика вакансии:
- React/Redux, Angular/Backbone;
- Scala/Java8, Akka 2.5, Play! 2.x, Ebean/Hibernate/Slick, OpenAPI/Swagger 2;
- PostgreSQL, Cassandra, MongoDB;
- Apache Spark, Kafka, Esper (CEP);
- Kamon/Prometheus/Grafana;
- Consul/Docker/Kubernetes;
- Git, Maven, SBT.

Необходимые компетенции:
- Высшее техническое образование;
- Опыт работы в качестве CTO/ Директора по разработке в продуктовой ИТ компании не менее 5 лет;
- Опыт управления территориально распределенными командами продуктовой разработки (от 50 человек);
- Отличные знания в области современных технологий, понимание тенденций их развития;
- Продуктовое мышление, умение разбираться в специфике бизнеса;
- Умение вести проектную и техническую документацию;
- Опыт формирования Архитектуры продуктовых решений.

Мы предлагаем:

Интересные, уникальные, сложные проекты;
- Стабильный доход (уровень дохода обсуждается с кандидатом по результату собеседования);
- Современный уютный офис в 5 минутах ходьбы от станции метро и станции МЦК Кутузовская;
- Английский;
- ДМС;
- Гибкие внутренние процессы.

Если есть опыт управления коллективом от 50 человек со всеми софт-скиллами, то скорее шлите резюме в A.shilova@infotechcorp.com

Про кадровый голод и пенсионную реформу

Вчера целый день сзобеседовал кандидатов за 60 лет и требовавших себе зп в 200-250 тыр. Причем график работы должен быть свободным!

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

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

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

Знаете почему? Потому что это мы сами подрастём. Готовы?

—- Реклама —— Пост проплачен ——

Всем привет!
Меня зовут Иван и я Founder/CEO в readless LLC;
Мы в нашу дружную команду ищем iOS-разработчика middle (с опытом от 2+ лет);
У нас почасовая оплата – ставка определяется по итогам собеседования;

Проект на Swift, используем уже firebase и стопку библиотек :) Круто, если у тебя есть опыт работы с аудио/видео контентом (стриминг, прекешинг и т.п.), а опыт в реактивных фраемворках, будет как плюсик в карму;

Мы сейчас ищем толкового iOS разработчика, ожидаем проактивности и вовлеченности. Задача – помочь текущей команде заделиверить продукт в прод, попути пройдя все проверки от QA и первое ревью от Apple, и в дальнейшем развивать продукт и радовать пользователей новыми фичами;
Формат работы: фуллтайм/партайм на удаленке;
Месторасположение: не важно.

Работа должна быть в удовольствие, поэтому ты получаешь:
- Возможность сделать приятным опыт прослушивания аудиоконтента для сотен тысяч людей;
- Интересные задачи;
- Возможность проявить себя и сделать классное приложение, которое будет не стыдно показать друзьям/родным и близким;
- Приятные бонусы при решении сложных задач или соблюдении дедлайнов.

Если остались вопросы, всегда готов ответить в личке @imiasnikov

​​Москва, 3-5 февраля 2020 обучающий практикум Slurm по SRE на русском языке: https://slurm.io/sre

На рынке есть три крупнейших компании по devops на аутсорсинг (от каждой компании в этом чатике есть представители). Компании эти принципиально отличаются друг от друга. Одна их компаний имеет административный ресурс. Другая имеет собственное издательство. Третья компания Southbridge проводит обучающие практикумы devops под общим названием Slurm.

Три разных подхода к привнесению ценности на рынок. Их всех объединяет общая черта, - они стали центрами компетенций по devops.

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

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

Результаты опроса про хранение деревьев в реляционных бд:
55 голосов - за 😎 parent id
28 голосов - за 🤩 nested sets

А если голосовать количеством необходимых sql-запросов для выборки из дерева на 10к элементов одной из подветок, то какой вариант выиграет? В штуках запросов и микросекундах если измерять, у кого будет меньше?

​​​Southbridge и Flant, наконец, встретились!

П.С. Кто угадает, футболка с чьим принтом на мне?

-—- Реклама —- Пост оплачен ——

Привет из Шопстер!

Мы – стартап, успешно живущий на зарабатываемые деньги. Уже 6 лет занимаемся Wi-Fi аналитикой и HotSpot-ом; трекингом персонала и индор-навигацией. Наши партнёры - крупнейшие компании в сфере рекламы и ритейла, а также интеграции IT решений.

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

Из стека предстоит активно использовать
Python, Django, DRF, Docker
а также взаимодействовать с
Kafka, NSQ, S3, Postgres

Ожидаемые компетенции
- хорошее знание Python
- опыт разработки на Python + Django от 2-х лет, работа с Django Admin, знакомство с DRF
- работа с Docker
- понимание принципов ООП, понимание/применение архитектурных паттернов
- знание базовых алгоритмов и структур данных
- понимание REST
- английский, минимум на уровне чтения документации

Будет плюсом:
- опыт работа с Scipy, Numpy, Pandas
- опыт разработки высоконагруженных приложений
- опыт управления командой, менторинг
- опыт работы с PL/pgSQL

Условия работы
- стартап, то есть нас нет бюрократии, а есть ответственность за свои действия
- белая ЗП, 2 раза в месяц на карту
- офис в 5 минутах от м. Беговая
- фрукты по пятницам и опциональные посиделки по праздникам
- гибкий график
- возможна частично-удаленная работа

Вилка 90 - 130 net

Контакт telegram: @avabr

Лилипут на плече великана

Так нередко бывает, - шикарный проект (Великан), харизматичный технический лидер (Лилипут) и их совместный ореол «прошел огонь, воду и медные трубы! Все знает, все умеет! Проект занимает лидерские позиции благодаря именно этой Личности!»

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

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

Лилипуты на плече великана меняются. Каждый оставляет что-то свое ему и великан приобретает знакомые нам черты.

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

Но на плече другого великана мы таких лилипутов почему-то в следующий раз видим очень редко.

В чем главная мысль? Мы путаем лилипута и великана. Мы смешиваем их успехи. Мы пытаемся сами стать такими, но не знаем, что привнес лилипут, а что - великан.

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

Коллеги, кто работает с Kubernetes, приходите на Слёрм Мега. Москва, 22-24 ноября, отель Симферополь.

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

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

Цена: 50 000 руб. По промокоду CTORECORDS скидка 10%.

Регистрация: https://slurm.io/mega?utm_source=ctorecords

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

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

А система продолжает развиваться. Есть чёткое ощущение, что усиливая сложность путём тупо кодирования и не выводя на bpmn формализацию, мы полностью перестанем контролировать происходящее.

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

Про жиру и разницу масштабов компаний

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

Оппоненты же из кровавого энтерпрайза живут в мире, в котором ни кто не может охватить мозгом все потоки работ. Ни кто не сможет рулить эффективно компанией 100+ человек из-за размера в ручном режиме. Если процесс отлажен и даёт 20% маржи после выплаты всех фотов, налогов и косвенных платежей, то можно его масштабировать тупо, наняв 100+ человек, ограничиваясь только размером рынка.

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

Жира - это история про управляемое автоматизированное масштабирование заработков.

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

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

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

Обучение SRE & Kubernetes = Slurm

Прыгнул за руль и помчался на Мегу https://slurm.io/mega?utm_source=ctorecords. Буду вести репортаж все три дня из консоли.

Что это такое? Продвинутый интенсив по куберу и куберосодержащим решениям.

Зачем? Полное погружение в контекст по стеку.

Пишите вопросики в чатике с тегом #slurm, буду по ходу дня отвечать и я сам и организаторы. Самый интересный вопрос получит награду по окончании интенсива!