Здесь могло бы быть долгое вступление про то, как современные веб-приложения прошли путь от простых макетов, ограниченных технологиями своего времени, до способных подстраиваться даже не под ограничения технологий, а под ограничения самих пользователей. Но сейчас важно совсем другое. Как ни крути, все пользователи разные, и иногда ограничения касаются их физических возможностей. Этими вопросами занимается адаптивный дизайн и, в частности, инклюзивный. Но обо всем по порядку.
Всем привет! Мы уже много писали про разработку корпоративного портала НЛМК, которым пользуются больше половины сотрудников нашей большой компании. Сейчас хочу рассказать какие существуют дополнительные инструменты оповещения пользователей, которые мы кастомно настроили на портале, чтобы повысить вовлечение: новостная лента, корпоративное телевидение, онлайн-трансляции, Push уведомления и e-mail рассылка.
В этой статье мы опишем наш опыт работы с очень большой системой управления проектами, реализованной на SP, с какими ограничениями мы столкнулись и как добились похудения данной ИС.
Стоит только коснуться производственной специфики, как стандартные подходы разваливаются на куски — даже если у вас уже есть огромная дизайн-система на основе популярной методологии Material Design. Я — Аня Труфанова, делаю дизайн для MES (manufacturing execution system). Нам пришлось взять дизайн-систему и наполнить ее уникальными фичами и кастомными компонентами, адаптированными под нестандартные условия. Сейчас я поделюсь, что именно мы переосмыслили и какие фичи добавили.
Всем привет! Не говорите, что вам нечего приготовить, если у вас дома одна картошка. При смекалке и достаточном количестве специй — пюре, драники, запеканка, чипсы фри... Конечно, мы обсуждаем не кулинарию. Мне хотелось бы поговорить о GraphQL и некоторых фичах, которые мы внедрили у себя в компании, и тиражируем на различные проекты, где используется этот язык запросов.
Эта статья о базовой структуре, производительности, безопасности и гибкости GraphQL и будет интересна архитекторам, интеграторам, аналитикам и разработчикам, которые не ограничиваются рассмотрением информационных систем только с точки зрения «кода», а учитывают полный жизненный цикл системы, включая поддержку, развитие, систему управления знаниями и многое другое.
Всем привет!
Сегодня я расскажу про роли поставщика и потребителя в контексте информационных систем. Под поставщиками я подразумеваю информационные системы, которые передают информацию, а под потребителями – которые ее получают. Также расскажу об основных правилах игры, которые мы выработали у себя в команде.
Зачем нужны правила? Представьте, если бы светофоры в разных городах имели бы разную цветовую гамму. К сожалению, похожий бардак иногда встречается в различных областях нашей жизни, и сфера информационных технологий — не исключение!
Статья поможет структурировать информацию тем, кто проектирует информационные системы и взаимосвязи между ними.
Привет, Хабр!
В этой статье мы описываем полную методику быстрого пополнения словарного запаса при чтении неадаптированной литературы на иностранном языке. Статья будет интересна тем, кто владеет иностранным языком на уровне B2-С1 и столкнулся с необходимостью увеличить словарный запас на 5000-10000 новых слов за относительно короткий срок, напр. за полгода-год.
Методика опробована на английском языке и мобильном приложении Яндекс.Переводчик, однако может быть использована для любого другого языка и/или мобильного приложения.
С уважением,
Владимир
Привет Всем.
Меня зовут Михаил. В НЛМК нахожусь на должности Frontend-разработчика. Занимаюсь разработкой внутренних информационных систем на React + Typescript.
В этой статье поговорим про тип enum (перечисление) в Typescript, о случаях когда его можно и нужно использовать, а когда нет.
Перечисления бывают числовыми и строковыми. Например, представим в виде перечисления должности работников кафе.
Рассмотрим перечисления с числовыми значениями:
Наша команда специализируется на разработке и развитии функционала корпоративного портала группы компаний НЛМК.
На практике мы сталкиваемся с самыми разными задачами: от вывода ленты новостей компании и простейших форм обратной связи до функционала оценки качества работы сотрудников и планировщиков рабочего времени некоторых отделов.
Однако, несмотря на все разнообразие решаемых нами вопросов, зачастую разрабатываемые нами сервисы можно собрать из одних и тех же функциональных блоков, своеобразных "кирпичиков".
Конечно, реализуемая бизнес-логика всегда разная, но в основе часто используются одни и те же элементы. Умение правильно их применить, настроить и "подружить" друг с другом существенно снижает затраты времени и труда, как на разработку, так и на поддержку функционала портала.
В рамках этой статьи мы хотим поделиться опытом использования бизнес-процессов Битрикс: рассказать про их преимущества, недостатки и особенности внедрения.
Сегодня я хотел поговорить о том, как мы выстраиваем процесс работы с общими библиотеками разработки. Я расскажу о нашем подходе, который позволяет соединить процессы, команды и инструменты в единое целое. Статья будет интересна тем, кто сопровождает, создает или интересуется, как библиотеки появляются на свет.
После того как я впервые съездила на завод, стало понятно, почему в дизайнеров кидаются тапками.
Мы работали на ярких прикольных аймаках, проектируя интерфейсы MES-систем в соответствии с трендами. А потом своими глазами увидели, в какой ад для сотрудников производства это превратилось.
В разработке интерфейсов для металлургии оказалось намного больше нюансов и специфики, чем мы предполагали.
У нас полно лендингов и бизнес просит еще! Но каждый новый лендинг нужно проводить по процессу. Хочется автоматизации - нужен конструктор! Я неоднократно читал статьи на Хабре про самописные решения – 5 лет, и все в лучшем виде, но для нас это "too much". Мы уложились менее чем за год с "Bitrix". До этого серьезно прошерстили рынок на предмет типовых решений, а также отбросили вариант решения с нуля. Расскажу о процессе выбора и что мы в итоге получили.
Привет, Хабр! На связи команда Проектного офиса НЛМК-ИТ.
В жизни каждого Проектного офиса наступает момент, когда населяющие его менеджеры и другие сотрудники задумываются о внедрении системы управления проектами. Манящая простотой и выгодами идея редко обходится без подводных камней на этапе реализации. На старте полезно узнать об опыте тех, кто уже набил шишки и морально-волевыми усилиями решил данную задачу, чтобы минимизировать собственные страдания.
Поэтому, вооружившись идеей «храбрый учится на своих ошибках, мудрый учится на чужих, а дурак не учится никогда», мы хотели бы рассказать одну историю.
Задача: в БД необходимо фиксировать кто создал сущность, кто её обновил, и кто её удалил.
Все знают, как взять пользователя из контекста и сунуть его в сущность. Допустим, на уровне сервиса в методе извлечь информацию о нём и «засетать» его в нужные поля (придётся везде таскать этот кусок кода по сервису), а с аспектами как‑то выглядит не явно и накладывает ряд обязательств (например, развешивание аннотаций над методами всякий раз, когда мы что‑то пытаемся сделать с сущностью (новые участники команды могут не знать о такой неявной практике, а старые забыть о ней)).
Мне хотелось полностью делегировать это приложению, но погуглив, я не нашёл какого‑то явного решения. Сейчас расскажу, как мне удалось это сделать: