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

Привет, я Дмитрий Логвиненко — Data Engineer отдела аналитики группы компаний «Везёт».

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

И да, я буду не только рассказывать, но и показывать: в программе много кода, скриншотов и рекомендаций.

Что обычно видишь, когда гуглишь слово Airflow / Wikimedia Commons

Привет, меня зовут Алексей Лобзов, я руководитель направления развития компетенции системного анализа в Альфа-Банке. В прошлом году мы в банке проводили Analyze IT Meetup. Кроме интересных докладов у нас был круглый стол, куда мы пригласили Лидера компетенции из Сбера, Solution архитектора из СИБУР Digital и Product Owner’а из Альфа-Банка.

Что их всех объединяет? Они все в прошлом были системными аналитиками. Наши герои поделились тем, как из системных аналитиков (СА) перешли на новую позицию. Тема оказалась животрепещущей — было много вопросов как на митапе, так и после, поэтому позже мы той же компанией и на ту же тему записали подкаст в СИБУР Digital.

И если для вас вопрос «А куда расти дальше, если я уже сеньор?» стоит «на повестке дня», то приглашаю почитать статью, подготовленную по материалам круглого стола. 

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

Наш предыдущий пост вызвал много вопросов. Мы были готовы к тому, что будут комменты по инструктажам по ТБ, вопрос об электронном подписании которых мы рассматривали и который может быть неоднозначным и дискуссионным. Однако не ожидали, что люди будут ставить под вопрос законность и саму возможность цифровой трансформации нарядной системы в России в рамках существующих законов. В этом посте попробуем обстоятельно ответить на вопросы, возникшие под предыдущим постом. По вопросам @Regennon@qyix7z@red_dragon и др.

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

Многие знают, что СССР был родиной т. н. «троичных машин», т. е. компьютеров, использующих не двоичную, а троичную систему счисления. Они стали уникальной страницей в истории вычислительной техники. Единственный серийный и самый известный пример троичной ЭВМ — советский компьютер «Сетунь», разработанный в 1958 году под руководством Николая Брусенцова, при активном участии Льва Гутенмахера, Сергея Соболева и Евгения Жоголева.

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

Очередной пост о том, что мы делаем. В этот раз расскажу вам о том, как мы обеспечили безопасность информационных баз 1С с использованием сервиса аутентификации Keycloak через протокол OpenID Connect и настройку двухфакторной аутентификации с помощью OTP‑кода.

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

Речь пойдёт о сервисе, который изначально мы задумали как внутрикорпоративную систему проверки контрагентов, а затем разработали как коммерческий продукт. Коротко расскажем о том, что делает система, с какими проблемами столкнулись при разработке и как их решали, как запускали, разворачивали, и немного коснемся того,  что “под капотом” у DevOps. Полагаю, что пост позволит оценить усилия команды при создании сервиса, подсветит использование некоторых технических решений, которые нам показались оптимальными, покажет типичные проблемы систем с парсингом из множества разнотипных источников, и будет полезен коллегам при разработке других продуктов. Я честно постараюсь минимизировать рекламную составляющую до короткого дисклеймера и избавить пост от маркетинг булшит. 

В комментах к предыдущей части некоторые читатели предложили рассказать о ещё нескольких ЯП, которые сыграли значительную роль для развития программирования в СССР. Автор не смеет игнорировать просьбы трудящихся. В этой части цикла поговорим об АЛМО, Эль-76 и Рапира и ЛЯПАС.

Сегодня тяжело найти человека, который бы не слышал прогнозов о том, что нейросети уже готовы заменить системных аналитиков, в особенности на этапе формирования требований к новым системам. Например, тренер в школы системного анализа, ИТ-архитектор в “Systems.Education“ Юрий Куприянов ещё год назад писал на Хабре о том, что системные аналитики с junior level рискуют потерять работу, т.к их способен заменить ИИ. Аналогичные выводы сделал наш руководитель практики технологических решений Виталий Волнянский в своих комментариях и публикациях о нейросетях в СМИ. 

Между тем, из ЕАЕ-Консалт после релиза Chat GPT до настоящего времени не был уволен ни один сотрудник, занимающийся системным анализом. Более того, среди знакомых мне системных интеграторов, компаний, разрабатывающих сложный софт для промышленности, крупного ритейла и систем безопасности (например, на основе компьютерного зрения), также не было массовых увольнений специалистов моего профиля. Более того, только на Хабр карьера в настоящий момент 479 вакансий системных аналитиков, профессия остаётся крайне востребованной и за пределами России, например считается  дефицитной в США. В посте предлагаю данные небольшого сравнительного исследования, не претендую на научную репрезентативность, но полагаю, что результаты, отчасти, раскрывают причины того, о чем я написал выше. 

Для многих российских ИТ-специалистов  возможность поработать или учиться в США если не заветная мечта, то, как минимум, серьезная цель. Несмотря на геополитическую напряженность, зарплаты, качество образования и другие приятные бонусы пребывания в Штатах продолжают привлекать российских разработчиков, ИТ-менеджеров, тестировщиков, аналитиков и студентов. Между тем, с распростертыми объятиями там не ждут не всех и не всегда.

В сети достаточно материалов про визы H-1B, L-1, О-1, F-1, B-1, специальных программах для “технических специалистов”, однако большинство из них дают поверхностную общую информацию и мало применимы на практике. В этом посте я предлагаю обзор самой “страшной” и широко используемой статьи Акта об иммиграции и национальности — 214(b).  Такое основание признаётся юристами наиболее гибким инструментом для отказов в неиммиграционных визах (рабочих, студенческих), а за её стандартной формулировкой может скрываться широкий спектр неочевидных и “коварных” причин.  К сожалению, я не юрист, а системный аналитик, поэтому в подготовке поста мне помог Мэтью Морлей - человек и пароход, американский адвокат, работающий в Москве, доктор юридических наук (JD) в Массачусетской Школе Права, специалист, на которого ссылается Reuters, член Американской коллегии адвокатов (АВА) и Американской ассоциации иммиграционных адвокатов (AILA).

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

В этой статье мы опустимся на один уровень ниже и посмотрим, что же происходит внутри среды исполнения Python для выполнения простого действия a + b. Иными словами, мы узнаем о подробностях реализации типов, операторов и динамической диспетчеризации в CPython.

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

"Советские микросхемы — самые большие микросхемы в мире"

В марте прошлого года в блоге Дениса Шамиряна @CorneliusAgrippa на Хабре вышел пропитанный пессимизмом, но, пожалуй, наиболее аргументированный и детальный пост о состоянии и перспективах российской микроэлектроники, в первую очередь, о КМОП производстве. Пост завершался критикой локализации производства микросхем и коротким, максимально неопределенным ответом на вопрос “что делать?”. С этого момента произошел ряд событий, которые могут снизить неопределенность и оценить усилия, предпринимавшиеся в этой области. Заранее скажу, что победных реляций и турбооптимизма в посте не будет. Этот пост — обзор событий, оценок, прогнозов, а также попыток, которые предпринимаются для создания с нуля полного цикла производства современных полупроводников в России. 

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

Сложные заказчики и клиенты — это всегда “геморрой”, много нервов и проблем на всех стадиях проекта. Коммуникационный аспект в нашей работе всегда занимает существенное место. Отчасти, это из-за специфики, мы чаще создаем приложения для спорта и нередко сталкиваемся с непростой коммуникацией, как на этапе обсуждения проектов, так и в процессе реализации. Когда приходишь на этот рынок — начинаешь бороться за заказы, т.к. они часто “жирные” в финансовом плане, клиентами разбрасываться не приходится, особенно в начале пути. Это пост — попытка классифицировать тяжелых заказчиков и обобщить наш опыт работы с ними. Рассказать, что стоит делать в ситуациях, когда отказываться от сотрудничества не хочется, но коммуникация оставляет желать лучшего, и как не попасть в сложную ситуацию с конкретными типами сложных клиентов.