За полтора года в поддержке DIRECTUM я решил больше тысячи обращений, в том числе по настройке cистемы и работе с прикладным кодом. «Ну и что?» – возникает логичный вопрос. А то, что я – студент с экономической кафедры, который ещё два года назад не понимал, для чего нужна серверная часть в архитектуре мобильных приложений, и что интерфейс сайта в браузере на самом деле является html-разметкой. И я расскажу вам, как попал в IT-компанию, не имея опыта и навыков в этой сфере.

Вступление

В школе для закрепления знания нам задавали решить множество однотипных примеров. Мы все время досадовали: что тут ценного? Подставить в формулу два-три значения и получить ответ. Где тут полет мысли? Реальность оказалась суровей, чем школа.

Сейчас я работаю аналитиком в ИТ. До прихода в ИТ-сферу я поработал инженером-теплотехником, программистом ЧПУ, поучаствовал в исследовательских проектах.

На своем опыте я убедился, что 95% рабочего времени инженеры и ученые тратят на такие «однотипные» действия. Расчеты уравнений, проверки, регистрация результатов, копирование спецификаций. Проект за проектом, эксперимент за экспериментом, день за днем.

Ожидаемый релиз netcore 3.0 позволяет запускать wpf на netcore. Процедура перевода для одного несложного проекта занимает один-два дня. Каждый последующий — много быстрее.

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

Многим понимание того, куда двигаться, что делать, приходит по наитию. А на это уходит много времени. Время – самый важный ресурс человека, который нужно беречь и не разбрасываться им. И чтобы это время не терять, хочется поделиться некоторыми мыслями, советами.
Перечисленные советы многим покажутся «капитанскими» и очевидными, особенно опытным программистам, но это не должно отменять их правильности.

Конструктивная критика приветствуется.

Мы в компании DIRECTUM занимаемся разработкой ECM-системы DirectumRX. Основным элементом модуля Workflow для ECM-системы является движок. Он отвечает за изменение состояния экземпляра процесса (инстанса) по ходу жизненного цикла. Перед тем, как начать разрабатывать модуль Workflow, стоит решить: взять готовый движок или написать свой. Изначально мы пошли по первому варианту. Мы взяли движок Windows Workflow Foundation (WF), и в целом он нас устраивал. Но со временем мы поняли, что нам нужен свой движок. Как это случилось, и что из этого вышло, расскажу ниже.

Это продолжение предыдущей статьи: Зачем писать свой React Data Grid в 2019

Для чего нужен Redux? Ответов много. Например, чтобы работать с общими данными в разных React-компонентах. Но можно воспринимать Redux еще как способ манипулирования компонентой. Сам взгляд интересный: любой React-компонент может управлять другим React-компонентом через Redux.

Возьмём React-компоненту, которая отображает данные в виде строк и колонок (Data Grid, грид). Каким функционалом у нее можно управлять? Составом колонок и строк. Выделением. Хорошо бы и прокруткой данных.

Каждый день пользователи по всему миру получают большое количество различных рассылок — только через сервис MailChimp ежедневно рассылают миллиард писем. Из них открывают 20.81%.

Ежемесячно пользователи наших сайтов получают рассылки с отобранными редактором материалами. Эти письма открывают около 21% читателей.

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

В этой статье расскажу о том, как реализовать рекомендательную систему с нуля на основе коллаборативной фильтрации.

Первая часть статьи содержит теоретическую основу для реализации рекомендательной системы. Для понимания материала достаточно школьной математики.

Во второй части описана реализация на Python для данных нашего сайта.

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

Можно начать разрабатывать код на TypeScript или включить в проект Flow. TypeScript – это компилируемая версия JavaScript, разработанная компанией Microsoft. Flow, в отличие от TypeScript, это не язык, а инструмент, который позволяет анализировать код и проверять типы. В сети можно найти множество статей и видео об этих подходах, а также руководство по тому, как начать использовать типизацию. В этой статье мы бы хотели рассказать, почему нам не подошел Flow, и как мы начали переходить на Typescript.

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

Статей о том, как к существующей базе прикрутили полнотекстовый поиск на основе Elasticsearch, в интернете уже предостаточно. А вот статей, как сделать действительно умный поиск, явно не хватает.

При этом сама фраза «Умный поиск» уже превратилась в баззворд и используется к месту и нет. Что же такого должна делать поисковая система, чтобы её можно было считать умной? Ультимативно это можно описать как выдачу результата, который на самом деле нужен пользователю, даже если этот результат не совсем соответствует тексту запроса. Популярные поисковые системы вроде Google и Яндекс идут дальше и не просто находят нужную информацию, а напрямую отвечают на вопросы пользователя.

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