Наш предыдущий пост вызвал много вопросов. Мы были готовы к тому, что будут комменты по инструктажам по ТБ, вопрос об электронном подписании которых мы рассматривали и который может быть неоднозначным и дискуссионным. Однако не ожидали, что люди будут ставить под вопрос законность и саму возможность цифровой трансформации нарядной системы в России в рамках существующих законов. В этом посте попробуем обстоятельно ответить на вопросы, возникшие под предыдущим постом. По вопросам @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).

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

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

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

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

Искусственный интеллект и машинное обучение взорвали информационную повестку в 2023-м году и продолжают удивлять. Бизнес стремится активно интегрировать максимально передовые нейросети в любые процессы, где ими можно эффективно заменить человека. При помощи Chat GPT и похожих продуктов создают контент, общаются с клиентами, рисуют дизайн и разрабатывают программное обеспечение. С 2021 первого года происходят попытки интеграции нейросетей в процесс создания промышленного кода и ускорения промышленного программирования.

Всё началось с того, что команде, с которой я работаю, предложили заказ на миграцию приложений из Docker Compose «во что‑нибудь более масштабируемое, отказоустойчивое и гибкое». Например, Ansible или Kubernetes. И всё это прекрасно, но у меня возникли проблемы. Как системному аналитику и по совместительству PM проекта, с минимальным опытом в DevOps, пришлось изрядно попотеть с пониманием многих вещей, касающихся Kubernetes. Под катом подробно о статьях и книгах, которые помогли мне разобраться с оркестратором, понять, чего хочет заказчик, сформировать требования к работе системы в целом, отказоустойчивости, масштабированию и безопасности.

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

Пилотная статья понравилась комьюнити, а значит продолжаем рассказывать о ранних советских разработках, предвосхитивших современные достижения отрасли, а порой, опередивших своё время. Наш рассказ будет не полным без упоминания проектов АН УССР, наиболее важная часть которых была реализована в процессе разработки и использования ЭВМ “Киев”. Под катом речь пойдет о проектах управления технологическими процессами на расстоянии 500 км, разработке и применении прообраза современных реляционных систем управления базами данных, а также первых советских опытах по машинному обучению и созданию искусственного интеллекта в 1950-х - 1960-х.

Последние 3 месяца мировые СМИ пестрят сообщениями о возможностях Chat GPT. Нейросеть успешно сдаёт испытания, экзамены и технические собеседования для целого ряда профессий, справляется с типовыми задачами для SEO‑копирайтеров, технических писателей, аналитиков. В частности, недавно нейросеть успешно справилась с техническим собеседованием для соискателей Google, а также сдала врачебный экзамен. У представителей многих профессий, в том числе в ИТ, появились нехорошие мысли о необходимости в будущем менять профессию и о том, что Open AI сделали то же, что молодой адвокат из баянного анекдота. Попробую изложить свои мысли по этому поводу, как человек, который часто использует Chat GPT и как руководитель практики технологических решений системного интегратора ЕАЕ‑Консалт.

Импортозамещение в ИТ, локальный российский тренд последних лет. На протяжении последнего года — это слово многократно звучало из каждого “утюга”. Причины — крупные западные вендоры, в силу геополитических причин, ушли из России. Это болезненно отразилось на промышленности и крупных компаниях, они потеряли доступ к покупке лицензий, поддержке, обновлениям ect. Больно терять ERP, DSS, цифровая трансформация промышленности и бизнеса в России, очевидно, замедлится. Распространено мнение, что опыт цифровой трансформации и автоматизации, а также разработка систем управления процессами предприятий начались в России в девяностые, а 1С, Галактика и Монолит выросли на ровном месте, но это не совсем так...

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

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

Проблемы классических ERP и перспективы альтернативной модульной архитектуры

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

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