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

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

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

Шутка о том, что отличие консалтеров состоит в том, что они просто берут больше денег за ту же работу для многих является аксиомой. Здесь постараемся объяснить, почему услуги консалтеров, как правило, дороже, в чем особенности консалтинг-бизнеса в ИТ и чем качественно отличаются услуги консалтинга от услуг аутсорсеров и фрилансеров на примере создания приложений для спорта. Опишем этапы, которые проходит проект в нашей компании, и расскажем, зачем эти этапы нужны.

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

Статья будет полезна тем, кто не проводил тестирования или имеет мало опыта.

Мой опыт юзабилити-тестирования(ЮТ) состоит из проектов разной сложности: от небольших стартапов, до энтерпрайз b2b приложений.

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

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