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

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

• 1С: Документооборот (Россия)
• Система Электронного Документооборота «InDocs» (Казахстан)
• Е1 Евфрат (Россия)
• Система электронного документооборота «Documentolog» (Казахстан)
• Единая система электронного документооборота государственных органов Республики Казахстан (ЕСЭДО) (Казахстан)
• Портальная система электронного документооборота «ТЕНГРИДОК» (Казахстан)
• Система электронного документооборота ARTA SYNERGY (Казахстан)
• CЭД Docsvision (Россия)
• Система электронного документооборота Эвридок (Казахстан)
• DIRECTUM (Россия)

Киберздоровье через призму Мармока

• архитектурные преимущества иммутабельности;
• создание эффективного персистентного векторного типа на основе RRB-деревьев;
• разбор архитектуры на примере простого текстового редактора.

Продолжаем рассказ про API, которые появились в новых версиях Java.

1. Files.mismatch()

Появился в: Java 12

На практике довольно часто возникает необходимость проверить, являются ли два файла в точности одинаковыми или нет. С помощью метода Files.mismatch(), появившегося в Java 12, это наконец-то можно сделать. Этот метод возвращает позицию первого несовпадающего байта в двух файлах или -1, если файлы идентичны.

Это может быть полезно, например, когда синхронизируешь содержимое двух директорий. Чтобы не перезаписывать файл при копировании тем же самым содержимым и лишний раз не нагружать диск, можно сначала проверить, идентичны файлы или нет:

public static void syncDirs(Path srcDir, Path dstDir)
        throws IOException {
    // Для простоты демонстрации считаем, что поддиректорий нет
    try (Stream<Path> stream = Files.list(srcDir)) {
        for (Path src : stream.collect(toList())) {
            Path dst = dstDir.resolve(src.getFileName());
            if (!Files.exists(dst)) {
                System.out.println("Copying file " + dst);
                Files.copy(src, dst);
            } else if (Files.mismatch(src, dst) >= 0) {
                System.out.println("Overwriting file " + dst);
                Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING);
            }
        }
    }
}

В наше время HTTPS обязателен для каждого веб-сайта: пользователи ищут замочек в адресной строке, когда передают личные данные; Chrome и Firefox недвусмысленно помечают как небезопасные веб-сайты с формами на страницах без HTTPS; это влияет на позиции в поисковой выдаче и оказывает серьёзное влияние на приватность в целом. Кроме того, сейчас имеется несколько вариантов получить бесплатный сертификат, так что переход на HTTPS — всего лишь вопрос желания.

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

Интро

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

Но один момент не меняется — если ты стал тимлидом, в твоей жизни изменится многое, если этого не произошло, это первый знак, говорящий о том, что ты явно не справляешься со своими обязанностями (либо это звание носит сугубо формальный характер).

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

Из хорошей идеи не всегда выходит бизнес

Мир сходит с ума, заталкивая калькулятор для 2+2 в облака. Чем мы хуже? Давайте Hello World затолкаем в три микросервиса, напишем пару-тройку тестов, обеспечим пользователей документацией, нарисуем красивый пайплайн сборки и обеспечим деплой в условный облачный прод при успешном прохождении тестов. Итак, в данной статье будет показан пример того, как может быть построен процесс разработки продукта от спецификации до деплоя в прод. Инетересно? тогда прошу под кат