Legal Code

📓 Логи — кодерская бюрократия или цифровая нефть?

В жизни каждого разработчика и собственника IT-продукта должна быть такая штука, как логи ( https://en.wikipedia.org/wiki/Log_file). Логи — это записи, которые накапливаются в процессе работы алгоритмов. Их можно писать в текстовые файлы и даже в базу данных. В логах можно фиксировать:
- что произошло
- когда произошло
- что было причиной, откуда сервис был вызван, с какого IP-адреса и т.д.
- что стало следствием, какой документ был сформирован, куда отправлен и т.д.
- работа алгоритма закончилась нормально или ошибкой.

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

🌋 Но самое главное, что логи при их большом количестве становятся не просто дневником вашего продукта и обузой для жёсткого диска. Они — ваша Big Data. Если использовать их правильно, можно получить хороший толчок к пониманию сильных и слабых мест сервиса. Их можно визуализировать. Их можно скормить ML-продуктам, чтобы получить прогнозы на будущее или увидеть аномалии в прошлом.

⚔️ Их можно использовать и в юридических целях. Если, конечно, вы грамотно их ведёте и защищаете от подмены. При их помощи можно проводить расследования, находить виновных, оправдывать невинных.

Например, в CRM-системе, которую разрабатываю для коллег, логи транслируются на отдельную веб-страницу в человекочитаемой форме и раскрашиваются разными цветами. Можно быстро увидеть, кто, когда и какую сущность изменил, насколько важным является такое изменение.

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

♨️ Зачем ходить на хакатоны
(даже если это юридические хакатоны)
(даже если они проходят онлайн)

Я четыре раза участвовал в legaltech-хакатонах.
Киев, Берлин, Харьков, Львов.
Ни разу не пожалел.

Ты оказываешься в команде обычно с незнакомыми людьми. За ограниченное время вам нужно сделать нечто, что должно решить проблему многих людей. Ты берёшь на себя определённую роль и выжимаешь из себя максимум. Получаешь возможность почувствовать себя Сооснователем. Иногда за это какой-то крутой дядя или тётя (инвестор, инкубатор или организатор хакатона) может дать вам денег.

🐟 Скоро будет https://www.facebook.com/events/677310929649514 на работу юрклиник, которые у нас становятся нередко домом последней надежды для слабых мира сего, где проактивный студент может присоединить селёдочный вкус профессии к получаемому ежедневно лекционному мармеладу. Короче, проблемы очень насущные, животрепещущие, настоящие. Прикладному интеллектуалу есть где разогнаться.

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

Ворваться можно через https://t.me/LegalLabBot.

https://telegra.ph/file/1eb6139bf2633f1a5671d.jpg🚔 Лигалтек и Государство

Завтра начинается третий месяц, как я работаю в https://www.facebook.com/mintsyfra. За это время успел сделать для себя массу выводов. Один из них: работа над инновациями, их внедрением и распространением — это кропотливый ежедневный труд, от которого нельзя ожидать сиюминутного выхлопа. Этим диджитальным культурам, которые сеем сегодня, нужно время, чтобы укорениться и взойти.

В первые годы своих лигалинженерских исканий я думал, что все наши проблемы должен решить код. Но вот некоторый код уже появился и продолжает появляться в рамках развития государственных сервисов. И теперь пришло время работы с людьми. Поведение людей сложнее, чем поведение кода. С ними приходится спорить, убеждать, уметь смотреть на мир с их стороны. Цифровые технологии, государственные API, открытые данные сами себя не внедрят. Внедрение идёт через принятие и желание, взаимодействие и соглашения.

И понял я, что нам в государственном лигалтеке сейчас нужен в первую очередь не ИИ, а нужно:
▪️ чтобы государственный реестр не ложился от нескольких десятков прилетевших одновременно запросов, а был безотказен, как сапёрная лопатка;
▪️ чтобы человек не унижался 5-10-15 рабочих дней в попытках получить справку о том, что он не лось, а получил её в 2 клика;
▪️ и так далее.

Проще говоря, нам нужна сначала безотказность if-else, над которым мы, бывает, посмеиваемся. А ИИ в праве... ИИ подождёт. Надо сначала показать и доказать людям правильное лицо технологий: скорость, глобальность, удобство, простоту. А не объяснять, что нейросеть переобучилась или застряла в локальном минимуме и поэтому отказала в пенсии 100-летнему человеку.

https://telegra.ph/file/003f77b1fa6fa1f259fcf.png🎼 BPMN — разложи свой бизнес-процесс по нотам

Обнаружил ещё одну замечательную точку приложения усилий лигалинженера (и не только) — создание и обслуживание схем на языке моделирования бизнес-процессов https://ru.wikipedia.org/wiki/BPMN при автоматизации чего-либо. Это такие схемы, где в большей мере человекочитаемым языком можно показать логику взаимодействий нескольких слоёв многоуровневой системы. Система может состоять из человеков, софта и чего угодно. Расписать можно как абстрактно, так и конкретно, отмечая каждое действие, особенно в точках взаимодействий слоёв.

На подобной схеме ниже изобразил, что происходит, когда я, используя телеграм-бота, отправляю информацию на бэкенд своего веб-сервера, чтобы сохранить её в базе данных. Использовал этот https://app.diagrams.net/. Есть и куча других.

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

Беру инструмент на вооружение и вам рекомендую. У меня ппц сколько систем создано, которые неплохо бы таким образом задокументировать. 🤓

Правда, напоминает нотный стан?

🎡 Паттерны в кодинге и праве

В разработке часто встречаются повторяющиеся из десятилетия в десятилетие ситуации:
▫️ обработка заказов с разными дополнениями (чай с сахаром, кофе с двойными сливками);
▫️ управление игровыми персонажами и их динамично меняющимся поведением (разные баффы и дебаффы на разных персах в Дотке);
▫️ мониторинг изменений состояния некоего элемента со стороны разных субъектов;
и т.д.

Для грамотного программирования этих механизмов применяются разные паттерны. Паттерн — это устоявшаяся схема связывания между собой программных сущностей, при которой система получит определённые преимущества и недостатки. Задача паттерна — сделать хорошо и не сделать плохо. Ключевое проявление хорошести — "гибкость системы", то есть насколько удобно, легко и быстро можно будет вносить в неё изменения с минимальным риском что-нибудь сломать. Короче, правильно выбранный паттерн — сэкономленный бабос и нервы заказчика.

⚙️ В кодинге есть куча паттернов. Вот недавно решил освоить несколько из них и наткнулся на https://refactoring.guru/ru/design-patterns/catalog, где есть и объяснения, и хорошие примеры. Также о паттернах написана легко читающаяся https://habr.com/ru/company/piter/blog/352202 (да почти с комиксами!). По этим источникам внимательно изучаю и отрабатываю на практике паттерны, перед тем как лепить их в резюме.

⚖️ В праве тоже есть паттерны. Например, паттерны структурирования закона, судебного решения и договора различны. Если закон и договор ещё как-то можно сделать похожими по структуре, то судебные решения ярко от них отличаются. Но в то же время, для них одновременно характерен такой функциональный паттерн, как использование ссылки на положения, которые уже прозвучали:

1️⃣ (далі по тексту - Виконавець) — см. во многих договорах

2️⃣ (далі - Реєстр) — см в ч. 1 ст. 16 https://zakon.rada.gov.ua/laws/show/5203-17#Text

3️⃣ (0.3, 0.5 і 1 грам, - далі «доза») — см. в http://reyestr.court.gov.ua/Review/87273651

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

⚠️ Важно: следует отличать паттерны проектирования (Strategy, Decorator, Adapter и т.д.) от принципов разработки (DRY, KISS, YAGNI, SOLID). Кстати, я уже писал ранее о принципах и .

🐗 Перешёл в IT

недоспойлер: в продуктовую компанию ( https://dou.ua/forums/topic/11274), больше пока сказать не могу

Каюсь, давно не писал посты сюда. Всё это время искал работу в IT, параллельно лихорадочно повышая квалификацию. Спустя 6 недель поисков удалось найти. Позади осталось около 10 отказов, из них 1 проваленный скрининг по телефону и 2 проваленных тестовых задания. Также 7 заявок остались без ответа. Но благодаря всему этому я узнал, насколько был некомпетентен всё это время. Например:

💀 Все созданные мной продукты не соответствуют ни одному паттерну проектирования. А зря. Это ппц важная штука.

💀 ООП на практике применял очень редко, а зря (да-да, овладел искусством процедурного и функционального стилей).

💀 Не работал с Линуксом и консолью, не знал даже базовых команд, а зря. Но на новой работе с первых же минут пришлось освоить, а спустя три дня осознал, насколько это нужно и полезно.

💀 Не работал с фреймворками для своего основного языка программирования (PHP). Очень зря. Этот пункт не позволил даже просто податься на массу аппетитных вакансий (именно джуновских). Часто требуется хотя бы полгода-год опыта с тем или иным фреймворком. Видел даже вакансию от крутого проекта из нашей лигалтек-экосистемы "Legal Nodes", там нужен был опыт с фреймворком.

Поэтому, уважаемые свитчеры, кто хочет перейти на сторону IT как программист, советую сначала поизучать вакансии, выписать из них кучу незнакомых слов, которые пишут работодатели, и разбираться, разбираться, разбираться. Готовиться к любому контакту с работодателем как к смеси экзамена и турнира на вылет. Да вообще советов ещё уйму можно дать, и их в Интернете пруд пруди. Кстати, тут скоро будет https://t.me/klhofficial на тему свитчерства по маршруту "право - IT", меня с моим диагнозом туда тоже взяли. 🤕

P.S. Канал будет жить, вас не брошу. Он не для рекламы, а ради торжества нашей юной лигалинженерской отрасли. Скоро возобновлю поставку постов.

https://telegra.ph/file/198fba958a574d84e3c06.jpg🎛 Работаем параллельно

Представьте, что юридическая фирма "Альбус и партнёры" через 25 минут должна отдать 1000 листов материалов иска курьеру, но ещё не проставлены обязательные печати на каждом листе.

Чтобы проставить печать на одном листе и перейти к следующему, нужно потратить в среднем 2 секунды. Итак, у одного человека эта благородная задача займёт: 1000 * 2 / 60 = 33 минуты. То есть он не успеет это сделать в срок, если, конечно, не будет пропечатывать каждый лист за полторы секунды.

🐾 Но если у фирмы есть хотя бы 2 таких печати и 2 человека, то можно успеть. Ведь нет разницы, в каком порядке пропечатываются листы: 1000-му листу всё равно, пропечатан он после 999-го или нет. А значит, все листы можно поделить на 2 пачки, дать 2-м людям и вооружить 2-мя печатями. Они сделают эту работу параллельно за 1000 * 2 / 60 / 2 = 16 минут 40 секунд, в два "потока" ("подпрограммы"), и в конце лишь останется соединить назад эти две пачки, что займёт, скажем, до 10 секунд.

Что мы видим? Результат тот же, а времени потрачено меньше. В этом идея параллельных вычислений и в программировании.

⚡️ Важное условие: порядок (последовательность) выполнения работы не должен влиять на конечный результат.

🔦 Например, подобное разделение программы на подпрограммы я реализовал в нашей юридической поисковой системе при полнотекстовом поиске. Когда она видит, что запросу соответствует более 8 источников, она начинает плодить подпрограммы в некоем кол-ве x, которое зависит от кол-ва источников, но не более 16. Сервер выполняет их одновременно, по готовности результаты их работы возвращаются в "материнскую" программу. Прирост скорости такого поиска составляет в среднем 215%.

Ну и, как всегда, держите визуализацию:

https://telegra.ph/file/a874eb347e0fd05ca67e3.jpg🎨 Программируйте и рисуйте

Недавно сделал для юристов веб-конструктор доверенностей. Это тривиальный проект с точки зрения размахов современной лигалтек-индустрии. Но если смотреть на него с технической стороны, то он уже требует построения полноценной архитектуры из файлов, скриптов и таблиц базы данных. Стек технологий в этом случае описывается уже минимум пятью словами: HTML, CSS, JavaScript, PHP и MySQL.

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

Поэтому стоит визуально планировать и документировать такую работу, ведь сразу будет видно:
▫️ "точки входа" с фронтенда на бэкенд,
▫️ по каким "тропкам" бегут данные,
▫️ какие зависимости есть в проекте и т.д.

А ещё это просто красиво. 🧑‍🎨

Сначала это удобно делать на бумаге (я всегда с неё начинаю новые проекты), затем на компе. По привычке продолжаю в Illustrator. В этот раз получилось как-то так:

https://telegra.ph/file/f6d374b02649ae223d556.jpg👨‍👩‍👧‍👦 Как контроль версий сделает вас лучше

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

🐛 Проблема №1. Нужно отслеживать свой прогресс. Хороший способ делать это — смотреть на свой прошлый код, видеть его недостатки, улучшать его. Отдавать себе отчёт, где и почему код был неэффективным, плохо читающимся. Понимать, где и в чём я вырос(-ла) за месяц, год, два. Но как его хранить? Плодить файлы, наподобие как с договорами в формате .docx, называя их "scriptanalysis2020-05-18 v1.docx", "scriptanalysis2020-05-18 v2.docx" ?

🐛 Проблема №2. Когда кодишь уже несколько месяцев, начинаешь замечать, что есть повторяющиеся куски кода, которые кочуют из проекта в проект. Бывает, делая 9-й проект, вспоминаешь, что сюда надо бы вставить функцию из 4-го проекта, а сюда — те прекрасные три строчки из 6-го проекта. И если не помнишь наизусть, приходится лезть в 4-й и 6-й проект за этими штуками.

Обе проблемы можно решить при помощи репозиториев и систем контроля версий. Например, я использую тот самый https://github.com/. На Гитхабе можно завести приватный репозиторий, насоздавать в нём файлов и наполнить их вашим кодом. Теперь проблема №2 решена: у вас есть некое общее место, откуда вы с лёгкостью достанете нужный универсальный код. А если вы будете регулярно обновлять ваши файлы, делая в них коммиты с обновлённым кодом, то затем, используя кнопку "History", вы будете видеть, как менялся файл от коммита к коммиту, т.е. как двигался ваш прогресс (проблема №1).

P.S. Конечно, это не является страховкой от того, что из проекта в проект будет кочевать плохой код, если такая плохизна вовремя не осознана. 🙂

На скрине Гитхаб показывает, как коммит изменил содержание файла:

🔔 Дзінь, є хто живий?

Пробачте, давно сюди не писав. Було багатенько роботи. Вирішив далі вести цей канал українською, бо все ж цей канал народжений і викормлений українською екосистемою. 🇺🇦

Про що поговоримо далі? Та як завжди, про різне: (само)навчання кодингу, роботу з даними, SQL та Excel, аналіз правових текстів та про інші технарсько-правничі суміші. 🙂

Але як і раніше:
1⃣ жодної реклами (типу коли автору каналу платять, а він постить бозна-що);
2⃣ ніякого контенту в дусі "на, відчепись".

Я ціную ваш час. ⏳

🪑 Инновации на костылях — быстро или вредно?И кодинг, и право подвержены применению костылей.

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

Например, вам нужно сгенерировать случайную дату в текущем году. Реализовать это, например, в Python можно так:

from datetime import datefrom random import randintdate_start = date.today().replace(day=1, month=1).toordinal()date_final = date.today().replace(day=31, month=12).toordinal()date_random = date.fromordinal(randint(date_start, date_final))print(date_random)А вот как выглядит явно костыльное решение:

from random import randintrandom_day = randint(1, 28)random_day = '0' + str(random_day) if random_day < 10 else str(random_day)random_month = randint(1, 12)random_month = '0' + str(random_month) if random_month < 10 else str(random_month)date_random = '2021-' + random_month + '-' + random_dayprint(date_random)То есть во втором варианте мы не заморачиваемся с учётом количества дней для каждого месяца (не будут появляться даты с 29, 30 и 31 днём) и жёстко привязываемся к 2021-му году. Минусы этого решения очевидны.

🚷 Являются ли костыли абсолютным злом? Да нет. Они часто нужны, чтобы сократить время на разработку какой-то фичи и за счёт этого быстрее проверить гипотезу. Но когда окажется, что гипотеза удачна и фичу надо оставлять, код следует переписать так, чтобы избавиться от костылей и прочих "мин замедленного действия". Нужно уметь убеждать свой менеджмент, что хоть и "оно же работает", код нуждается в существенной доработке, чтобы в будущем эти костыли не вылезли боком (как бы это ни звучало).

А что является костылём в праве? Думаю, вы уже встречали их. Костыли встречаются в договорах, правоприменении и даже в законах. Наверняка кто-то считает и сам Хозяйственный кодекс сплошным огромным костылём в частном праве. 😊