оптимизация/рефакторинг и правосудие будущего
🌫 часть 2 — зашифрованное правосудие
В предыдущем посте мы пришли к тому, что сжали код практически в четыре раза без потери функциональности и результата. Но изменилось представление некого знания о сути алгоритма, заложенного нами в этот код. До оптимизации формула этого знания выглядела так:
💦 y = округлить( ( x - 50 ) * 2 * 255 / 100 )
После оптимизации стала выглядеть так:
💧 y = округлить( ( x - 50 ) * 5.1 )
Если мы затем опубликуем этот код как библиотеку (например, выложим на гитхабе) и не поясним эту строку комментариями, то не все поймут, что означает число 5.1, откуда оно взялось. Это число 5.1 станет, по сути, зашифрованным цифровым знанием. Постороннему человеку придётся реконструировать наше изначальное мышление, пройти наш путь заново, чтобы понять и воссоздать логику этого алгоритма (здравствуй, рефакторинг).
Итак, причём здесь правосудие? А при том, что оптимизация больших вычислительных систем, в основе которых лежит математика и логика и которые разрабатываются с целью автоматизировать принятие правовых решений, может привести к тому, что правосудие будет выглядеть примерно так:
y = ( x * 2.45 ) + ( z * 0.2 ) - 1200
... и даже так:
y = 1.0 / ( 1.0 + exp( -( 0.525 * 1.0 / ( 1.0 + exp( -x ) ) ) ) ) + 0.2
То есть суть и логика диджитализированного правосудия вдруг окажется скрыта за оптимизированными логическими и математическими преобразованиями. Хорошо ли это? Отвечу так: это вовсе неплохо, если разработчики будут:
1️⃣ тщательно документировать свой код, поясняя происхождение всех вводных данных и факт применения математических констант и традиционных формул;
2️⃣ в случае оптимизации кода, которая ведёт к "сжатию правового знания", тщательно документировать те параметры, которые явно использовались до оптимизации и во что они "сжались" в ходе таковой;
3️⃣ в идеале — делать две версии кода: оптимизированную и "полную", по которой можно будет исследовать логику работы системы в случае необходимости (например, при успешном обжаловании такого диджитализированного решения).
📙 Недавно на канале "Future Law School" упоминалась книга Педро Домингоса "Верховный алгоритм ... ". Прочёл её в прошлом году, в ней действительно в доступной форме изложена тема алгоритмизации в машинном обучении, показаны некоторые математические формулы, которые используются далеко не в математических целях.
🌫 часть 2 — зашифрованное правосудие
В предыдущем посте мы пришли к тому, что сжали код практически в четыре раза без потери функциональности и результата. Но изменилось представление некого знания о сути алгоритма, заложенного нами в этот код. До оптимизации формула этого знания выглядела так:
💦 y = округлить( ( x - 50 ) * 2 * 255 / 100 )
После оптимизации стала выглядеть так:
💧 y = округлить( ( x - 50 ) * 5.1 )
Если мы затем опубликуем этот код как библиотеку (например, выложим на гитхабе) и не поясним эту строку комментариями, то не все поймут, что означает число 5.1, откуда оно взялось. Это число 5.1 станет, по сути, зашифрованным цифровым знанием. Постороннему человеку придётся реконструировать наше изначальное мышление, пройти наш путь заново, чтобы понять и воссоздать логику этого алгоритма (здравствуй, рефакторинг).
Итак, причём здесь правосудие? А при том, что оптимизация больших вычислительных систем, в основе которых лежит математика и логика и которые разрабатываются с целью автоматизировать принятие правовых решений, может привести к тому, что правосудие будет выглядеть примерно так:
y = ( x * 2.45 ) + ( z * 0.2 ) - 1200
... и даже так:
y = 1.0 / ( 1.0 + exp( -( 0.525 * 1.0 / ( 1.0 + exp( -x ) ) ) ) ) + 0.2
То есть суть и логика диджитализированного правосудия вдруг окажется скрыта за оптимизированными логическими и математическими преобразованиями. Хорошо ли это? Отвечу так: это вовсе неплохо, если разработчики будут:
1️⃣ тщательно документировать свой код, поясняя происхождение всех вводных данных и факт применения математических констант и традиционных формул;
2️⃣ в случае оптимизации кода, которая ведёт к "сжатию правового знания", тщательно документировать те параметры, которые явно использовались до оптимизации и во что они "сжались" в ходе таковой;
3️⃣ в идеале — делать две версии кода: оптимизированную и "полную", по которой можно будет исследовать логику работы системы в случае необходимости (например, при успешном обжаловании такого диджитализированного решения).
📙 Недавно на канале "Future Law School" упоминалась книга Педро Домингоса "Верховный алгоритм ... ". Прочёл её в прошлом году, в ней действительно в доступной форме изложена тема алгоритмизации в машинном обучении, показаны некоторые математические формулы, которые используются далеко не в математических целях.
оптимизация/рефакторинг и правосудие будущего
🌧 часть 3 — безупречная отчётность компьютера
Предыдущий пост мог нагнать пессимизма в размышления о диджитализации правосудия. Дескать, алгоритмы всё равно будут непонятными и непрозрачными, невзирая на тщательно задокументированный код, ведь конечный пользователь не обязан разбираться в коде, чтобы понять правомерность цифрового решения. На самом деле, для обеспечения понятности работы программ существует логирование (запись, фиксация) "производимых действий", "принимаемых решений", а для обеспечения их прозрачности — вывод всех логов конечным пользователям.
Что такое логирование и логи?
Привожу пример из юридической практики.
🖨 Стажеру Сергею в гипотетической юридической фирме "Аспера" поручили отсканировать 50 договоров, попутно проверяя наличие подписей. В ходе сканирования Сергей установил, что в договорах № 12, 17, 32 и 45 отсутствуют нужные подписи. Рядом со сканером лежал листок, куда Сергей записывал номера этих договоров. Эти записи = логи, листок = лог-файл, а процесс записи = логирование. Благодаря "лог-файлу" Сергея старшему юристу не придётся вручную перелопачивать все 50 договоров.
🦅 Логи можно применять везде, где есть возможность записи в файл или в базу данных. Насколько мне известно по моей практике, между любыми двумя строчками/инструкциями кода можно впихнуть команду на логирование текущего состояния системы (разумеется, просто так это делать не нужно). Логировать можно даже стадии отработки узлов нейросетей, чтобы искать изъяны в их логике, а ведь они считаются довольно закрытыми системами.
🔬 Так что при грамотной архитектуре и логировании диджитализированное правосудие не будет котом в мешке или котом Шредингера. Да и вообще котом. В отличие от человека, который в послеобеденное время может (не отдавая ни себе, ни обществу отчёт) выносить более мягкие решения. Который может путать слова, цифры, эмоционально поддаваться на присутствие толпы за окном и ретранслировать в судебное решение многие другие иррациональные факторы.
🌧 часть 3 — безупречная отчётность компьютера
Предыдущий пост мог нагнать пессимизма в размышления о диджитализации правосудия. Дескать, алгоритмы всё равно будут непонятными и непрозрачными, невзирая на тщательно задокументированный код, ведь конечный пользователь не обязан разбираться в коде, чтобы понять правомерность цифрового решения. На самом деле, для обеспечения понятности работы программ существует логирование (запись, фиксация) "производимых действий", "принимаемых решений", а для обеспечения их прозрачности — вывод всех логов конечным пользователям.
Что такое логирование и логи?
Привожу пример из юридической практики.
🖨 Стажеру Сергею в гипотетической юридической фирме "Аспера" поручили отсканировать 50 договоров, попутно проверяя наличие подписей. В ходе сканирования Сергей установил, что в договорах № 12, 17, 32 и 45 отсутствуют нужные подписи. Рядом со сканером лежал листок, куда Сергей записывал номера этих договоров. Эти записи = логи, листок = лог-файл, а процесс записи = логирование. Благодаря "лог-файлу" Сергея старшему юристу не придётся вручную перелопачивать все 50 договоров.
🦅 Логи можно применять везде, где есть возможность записи в файл или в базу данных. Насколько мне известно по моей практике, между любыми двумя строчками/инструкциями кода можно впихнуть команду на логирование текущего состояния системы (разумеется, просто так это делать не нужно). Логировать можно даже стадии отработки узлов нейросетей, чтобы искать изъяны в их логике, а ведь они считаются довольно закрытыми системами.
🔬 Так что при грамотной архитектуре и логировании диджитализированное правосудие не будет котом в мешке или котом Шредингера. Да и вообще котом. В отличие от человека, который в послеобеденное время может (не отдавая ни себе, ни обществу отчёт) выносить более мягкие решения. Который может путать слова, цифры, эмоционально поддаваться на присутствие толпы за окном и ретранслировать в судебное решение многие другие иррациональные факторы.
Ⓜ️ Математику в каждый мозг по самое ЗНО
На прошлой неделе прогремела новость о том, что ЗНО по математике станет обязательным с 2021 года в Украине. К тому же, оно будет иметь два уровня сложности (на выбор).
Зачем? Перевожу цитату министра с источника: "Базовые навыки по математике необходимы каждому человеку — она развивает логическое и абстрактное мышление. А это навыки, которые нужны всем людям, и всё больше стран делают внешний экзамен по математике обязательным для всех детей после завершения школы". Также математика, наряду с английским языком, названа "чрезвычайно важной для человека, который хочет быть конкурентным в современном мире".
С одной стороны, это круто, одобряю. Но почему-то не даёт покоя одна мысль. Ведь кроме этого, знания биологии собственного тела важны для человека, который хочет оставаться жизнеспособным. И физика — тоже как бы наука о законах, которые действуют повсюду. И как раз задача школы — расчехлить новоиспечённого человека в минимальном наборе самых важных знаний, наработанных цивилизацией.
💻 Поэтому давайте к 2026-му году топить за ЗНО по кодингу. А к 2031-му — по экологии, как раз будет горячо.
#новости #news #математика
На прошлой неделе прогремела новость о том, что ЗНО по математике станет обязательным с 2021 года в Украине. К тому же, оно будет иметь два уровня сложности (на выбор).
Зачем? Перевожу цитату министра с источника: "Базовые навыки по математике необходимы каждому человеку — она развивает логическое и абстрактное мышление. А это навыки, которые нужны всем людям, и всё больше стран делают внешний экзамен по математике обязательным для всех детей после завершения школы". Также математика, наряду с английским языком, названа "чрезвычайно важной для человека, который хочет быть конкурентным в современном мире".
С одной стороны, это круто, одобряю. Но почему-то не даёт покоя одна мысль. Ведь кроме этого, знания биологии собственного тела важны для человека, который хочет оставаться жизнеспособным. И физика — тоже как бы наука о законах, которые действуют повсюду. И как раз задача школы — расчехлить новоиспечённого человека в минимальном наборе самых важных знаний, наработанных цивилизацией.
💻 Поэтому давайте к 2026-му году топить за ЗНО по кодингу. А к 2031-му — по экологии, как раз будет горячо.
#новости #news #математика
🐟 О канале: веб-навигатор и посольство в Facebook
1. Каналу уже два месяца, а правила тегирования постов до сих пор не продуманы да и вообще тегирование я запорол изначально. Но взамен сделал веб-навигатор по постам канала, который буду обновлять раз в неделю. Здесь можно сразу увидеть, какие темы раскрыты и перейти в любой нужный пост. Да и если с каналом что-то случится, на этой странице будут дальнейшие координаты.
2. Также я открыл посольство в Facebook. Контент туда дублироваться не будет, максимум анонсы. Экспансия киберпространства продолжается. 😊
1. Каналу уже два месяца, а правила тегирования постов до сих пор не продуманы да и вообще тегирование я запорол изначально. Но взамен сделал веб-навигатор по постам канала, который буду обновлять раз в неделю. Здесь можно сразу увидеть, какие темы раскрыты и перейти в любой нужный пост. Да и если с каналом что-то случится, на этой странице будут дальнейшие координаты.
2. Также я открыл посольство в Facebook. Контент туда дублироваться не будет, максимум анонсы. Экспансия киберпространства продолжается. 😊
👁 Держава прозревает: машиночитабельные уставы
На этой неделе мы стали свидетелями знакового события: правительство Украины утвердило машиночитабельный модельный устав. Я узнал об этом из статьи Никиты Подгайного. Денис Иванов объяснил глобальное значение этого события. А я по привычке хочу пройтись по некоторым техвопросам.
1️⃣ Как это будет/может выглядеть?
На картинках в тексте Никиты изображен JSON. Я о нём здесь ещё не писал, поэтому простыми словами: JSON — это один из популярных способов объединять и структурировать данные, чтобы они были "понятны" компьютеру и в то же время удобно воспринимались человеком. Но пока неизвестно, будет ли этот сервис генерировать именно JSON-ы. Может, цифровой код действительно окажется "цифровым" кодом. Тогда получится, что однажды в 2020-м году будет заключена сделка между ТОВ с модельным уставом редакции 112131213 и ТОВ с модельным уставом редакции 121112212.
2️⃣ Может ли быть несколько модельных уставов в одном государстве?
Конечно. "Модельный" не значит "единственный". В этом случае "модель" скорее означает "версия". А для того, чтобы идентифицировать модель, не обязательно изучать экземпляр устава побуквенно, для этого как раз и будет цифровой код (аки номер версии). Ведь проще сказать "у меня Audi A7 2.8 FSI", чем описывать мощность двигателя, тип трансмисии и ряд других параметров.
3️⃣ Что дальше?
Это можно применить не только к уставам юрлиц. Через это можно пропустить огромное количество документов. И дело не только в шаблонизации как упрощении процедуры создания документа. Можно прийти к тому, чтобы не плодить сотни одинаковых документов (где отличается зачастую только дата и имена), а вместо этого формировать указатели на них, например: приказ_об_увольнении(142, "Гусачок Григорий Семёнович", "06.05.2019" ... ). Видите, выглядит как функция, в которую первым параметром передаём цифровой код, а дальше перечисляем нужные фактические данные, которые должны попасть в этот документ (имя увольняемого, дата увольнения и т.д.). Таким образом, сотню "приказов об увольнении" можно будет записать в столбик на нескольких А4.
Видите, чтобы сделать общество счастливее, не обязательно упарываться в блокчейн и нейросети. Less is more. Будем внимательно следить за диджитализацией этого вопроса.
На этой неделе мы стали свидетелями знакового события: правительство Украины утвердило машиночитабельный модельный устав. Я узнал об этом из статьи Никиты Подгайного. Денис Иванов объяснил глобальное значение этого события. А я по привычке хочу пройтись по некоторым техвопросам.
1️⃣ Как это будет/может выглядеть?
На картинках в тексте Никиты изображен JSON. Я о нём здесь ещё не писал, поэтому простыми словами: JSON — это один из популярных способов объединять и структурировать данные, чтобы они были "понятны" компьютеру и в то же время удобно воспринимались человеком. Но пока неизвестно, будет ли этот сервис генерировать именно JSON-ы. Может, цифровой код действительно окажется "цифровым" кодом. Тогда получится, что однажды в 2020-м году будет заключена сделка между ТОВ с модельным уставом редакции 112131213 и ТОВ с модельным уставом редакции 121112212.
2️⃣ Может ли быть несколько модельных уставов в одном государстве?
Конечно. "Модельный" не значит "единственный". В этом случае "модель" скорее означает "версия". А для того, чтобы идентифицировать модель, не обязательно изучать экземпляр устава побуквенно, для этого как раз и будет цифровой код (аки номер версии). Ведь проще сказать "у меня Audi A7 2.8 FSI", чем описывать мощность двигателя, тип трансмисии и ряд других параметров.
3️⃣ Что дальше?
Это можно применить не только к уставам юрлиц. Через это можно пропустить огромное количество документов. И дело не только в шаблонизации как упрощении процедуры создания документа. Можно прийти к тому, чтобы не плодить сотни одинаковых документов (где отличается зачастую только дата и имена), а вместо этого формировать указатели на них, например: приказ_об_увольнении(142, "Гусачок Григорий Семёнович", "06.05.2019" ... ). Видите, выглядит как функция, в которую первым параметром передаём цифровой код, а дальше перечисляем нужные фактические данные, которые должны попасть в этот документ (имя увольняемого, дата увольнения и т.д.). Таким образом, сотню "приказов об увольнении" можно будет записать в столбик на нескольких А4.
Видите, чтобы сделать общество счастливее, не обязательно упарываться в блокчейн и нейросети. Less is more. Будем внимательно следить за диджитализацией этого вопроса.
ТОП-50 юрбиза + ненапряжный кодинг = 🍑
Только что в рамках Общества Мёртвых Юристов мы запустили первый веб-проект. Типа тайное делаем явным, а запутанное — подсчитанным. Как оказалось, есть у "высшей лиги" нашего юрбиза свои причуды. Уверен: рейтинг, основанный на данных, будет более объективным, нежели закулисные поделки.
⚙️ Технически он не был сложным, понадобилось всего лишь:
1) данные из Excel перенести в базу данных MySQL;
2) выводить данные на веб-интерфейс, умножать, сравнивать, высчитывать проценты;
3) упорядочивать данные и скармливать их библиотеке Chart.js согласно документации;
4) немного покреативить с визуализацией "корпоративного ландшафта" юрбиза;
5) прислушиваться к толковому дизайнеру и вносить правки.
У меня это заняло три-четыре недели размеренного кодинга. Но как написал Дима, работа шла "несколько сраных месяцев" (по ходу, данные собирали, а меня подключили в конце). На выходе имеем амбициозный журналистский проект с почти BigData-основой. Дальше — больше.
Как оно вам?
Только что в рамках Общества Мёртвых Юристов мы запустили первый веб-проект. Типа тайное делаем явным, а запутанное — подсчитанным. Как оказалось, есть у "высшей лиги" нашего юрбиза свои причуды. Уверен: рейтинг, основанный на данных, будет более объективным, нежели закулисные поделки.
⚙️ Технически он не был сложным, понадобилось всего лишь:
1) данные из Excel перенести в базу данных MySQL;
2) выводить данные на веб-интерфейс, умножать, сравнивать, высчитывать проценты;
3) упорядочивать данные и скармливать их библиотеке Chart.js согласно документации;
4) немного покреативить с визуализацией "корпоративного ландшафта" юрбиза;
5) прислушиваться к толковому дизайнеру и вносить правки.
У меня это заняло три-четыре недели размеренного кодинга. Но как написал Дима, работа шла "несколько сраных месяцев" (по ходу, данные собирали, а меня подключили в конце). На выходе имеем амбициозный журналистский проект с почти BigData-основой. Дальше — больше.
Как оно вам?
КАК Я ВОШЁЛ В АЙТИ.
ЧАСТЬ 5. Закрытие первого крупного проекта. И второго. 📉
В прошлом рассказе я подошёл к сентябрю 2017 года. Примерно 5 числа состоялся релиз того самого конструктора ботов-генераторов документов. Появились юзеры-первопроходцы. И вместе с ними — вполне заслуженные жалобы на интерфейс, юзабилити и т.д. Но тем не менее, у кого-то получилось этим пользоваться. Поэтому мы в рамках серии аксоновских фриколоерингов даже проводили конкурс на создание наилучшего бота на этой платформе. Во Львове вручили приз победителю.
Но через некоторое время мы этот сервис закрыли. Почему? Параллельно к небу воспарила платформа ботоделов-майндмепистов, на которой можно создавать нелинейных чат-ботов без кодинга. И в таких условиях держаться за проект, который технически и морально позади нормального WYSIWYG решения я не видел смысла.
🧟♂️=>🦸♂️ Этой же осенью, пользуясь новообретёнными знаниями JavaScript, HTML и CSS, я переделал нашего веб-бота Франка (который делал политики приватности). Получилось красиво, но показать уже не могу, так как этот проект мы тоже закрыли. Почему? Началась эра GDPR, с вопросами приватности всё стало чуточку сложнее, и мы как эту услугу стали предоставлять довольно щепетильно и с индивидуальным подходом, который непросто алгоритмизировать.
Параллельно у нас в компании обострялся вопрос с организацией собственной юридической базы знаний, это был прямой вызов мне, поэтому я всё больше думал уже об этом.
🗺 Путь в айти: ч.1, ч.2, ч.3, ч.4
ЧАСТЬ 5. Закрытие первого крупного проекта. И второго. 📉
В прошлом рассказе я подошёл к сентябрю 2017 года. Примерно 5 числа состоялся релиз того самого конструктора ботов-генераторов документов. Появились юзеры-первопроходцы. И вместе с ними — вполне заслуженные жалобы на интерфейс, юзабилити и т.д. Но тем не менее, у кого-то получилось этим пользоваться. Поэтому мы в рамках серии аксоновских фриколоерингов даже проводили конкурс на создание наилучшего бота на этой платформе. Во Львове вручили приз победителю.
Но через некоторое время мы этот сервис закрыли. Почему? Параллельно к небу воспарила платформа ботоделов-майндмепистов, на которой можно создавать нелинейных чат-ботов без кодинга. И в таких условиях держаться за проект, который технически и морально позади нормального WYSIWYG решения я не видел смысла.
🧟♂️=>🦸♂️ Этой же осенью, пользуясь новообретёнными знаниями JavaScript, HTML и CSS, я переделал нашего веб-бота Франка (который делал политики приватности). Получилось красиво, но показать уже не могу, так как этот проект мы тоже закрыли. Почему? Началась эра GDPR, с вопросами приватности всё стало чуточку сложнее, и мы как эту услугу стали предоставлять довольно щепетильно и с индивидуальным подходом, который непросто алгоритмизировать.
Параллельно у нас в компании обострялся вопрос с организацией собственной юридической базы знаний, это был прямой вызов мне, поэтому я всё больше думал уже об этом.
🗺 Путь в айти: ч.1, ч.2, ч.3, ч.4
⛓ Почему не нужно бояться КЭП, то есть ЭЦП
Сталкиваюсь с тем, что многие люди, включая студентов юрфака, незнакомы с ЭЦП — электронной цифровой подписью (с недавних пор юридически правильно говорить КЭП — квалифицированная электронная подпись). А ведь она обретает всё большую роль в диджитализации права и государства. Например, только с КЭП можно попасть в электронный кабинет налогоплательщика, электронный суд и некоторые другие лигалтек-решения государства.
🚟 В канале о юрне вышел хороший пост об этом инструменте, а я хотел бы прояснить его техническую философию.
На первый взгляд, КЭП — файлик непонятного формата (например, .dat или .jks) на флешке, который был "сделан" в налоговой, скачан в "Приват24" или получен другим способом. Но это не так. Подпись — не сам файлик. Почему это круче, чем подпись ручкой на бумаге?
🖊 Когда вы подписываете документ (а точнее, лист бумаги) ручкой, то подписью становится горстка чернил, попавших на лист. И вы этой подписью в лучшем случае подтверждаете лишь факт того, что вы её поставили в этом конкретном участке листа. Ни за что другое ни вы, ни эта подпись не можете ручаться. Ведь эта подпись не взаимодействует с информацией на документе; факт постановки вами этой подписи не препятствует дальнейшему изменению/появлению данных на этом листе. Такая подпись — это лишь безвольное молчаливое свидетельство того, что когда-то кем-то она была здесь поставлена.
🧮 Процесс подписания документа КЭП намного более глубок и интеллектуален, нежели дублирование наскальной живописи с первых страниц наших паспортов. При таком подписании происходит некоторая магия, благодаря которой:
1. Подтверждается, что это именно ваша подпись.
2. Фиксируется момент времени подписания.
3. Фиксируется содержимое документа, который вы подписали. Если после подписания кто-то изменит документ, то это сразу же выяснится при проверке подписи. Интересно, почему? Можете читать дальше.
КЭП придумали не на пустом месте, она связана с хешированием. Не вдаваясь в пространные многословные определения, объясняю на упрощённом примере:
содержимое документа: "Я должен вернуть Грише 200 долларов."
хеш этого содержимого: n3ioG2n5b0PflsBt38
подписываю КЭП этот хеш: oN38gDTr3743Qn3Nfwj492nd
Гриша меняет содержание документа: "Я должен вернуть Грише 2000 долларов."
хеш этого содержимого уже другой: u11Rjkn05njkdnklPy
соответственно, моя подпись должна была бы выглядеть иначе: aA84kBrd09h3ifdSdG30ud772jsF
При проверке это сразу выяснится, и я заподозрю неладное.
На практике эти процессы более сложные и надёжные. Главное не хранить КЭП-файл и пароль от него где попало. 🙂
Сталкиваюсь с тем, что многие люди, включая студентов юрфака, незнакомы с ЭЦП — электронной цифровой подписью (с недавних пор юридически правильно говорить КЭП — квалифицированная электронная подпись). А ведь она обретает всё большую роль в диджитализации права и государства. Например, только с КЭП можно попасть в электронный кабинет налогоплательщика, электронный суд и некоторые другие лигалтек-решения государства.
🚟 В канале о юрне вышел хороший пост об этом инструменте, а я хотел бы прояснить его техническую философию.
На первый взгляд, КЭП — файлик непонятного формата (например, .dat или .jks) на флешке, который был "сделан" в налоговой, скачан в "Приват24" или получен другим способом. Но это не так. Подпись — не сам файлик. Почему это круче, чем подпись ручкой на бумаге?
🖊 Когда вы подписываете документ (а точнее, лист бумаги) ручкой, то подписью становится горстка чернил, попавших на лист. И вы этой подписью в лучшем случае подтверждаете лишь факт того, что вы её поставили в этом конкретном участке листа. Ни за что другое ни вы, ни эта подпись не можете ручаться. Ведь эта подпись не взаимодействует с информацией на документе; факт постановки вами этой подписи не препятствует дальнейшему изменению/появлению данных на этом листе. Такая подпись — это лишь безвольное молчаливое свидетельство того, что когда-то кем-то она была здесь поставлена.
🧮 Процесс подписания документа КЭП намного более глубок и интеллектуален, нежели дублирование наскальной живописи с первых страниц наших паспортов. При таком подписании происходит некоторая магия, благодаря которой:
1. Подтверждается, что это именно ваша подпись.
2. Фиксируется момент времени подписания.
3. Фиксируется содержимое документа, который вы подписали. Если после подписания кто-то изменит документ, то это сразу же выяснится при проверке подписи. Интересно, почему? Можете читать дальше.
КЭП придумали не на пустом месте, она связана с хешированием. Не вдаваясь в пространные многословные определения, объясняю на упрощённом примере:
содержимое документа: "Я должен вернуть Грише 200 долларов."
хеш этого содержимого: n3ioG2n5b0PflsBt38
подписываю КЭП этот хеш: oN38gDTr3743Qn3Nfwj492nd
Гриша меняет содержание документа: "Я должен вернуть Грише 2000 долларов."
хеш этого содержимого уже другой: u11Rjkn05njkdnklPy
соответственно, моя подпись должна была бы выглядеть иначе: aA84kBrd09h3ifdSdG30ud772jsF
При проверке это сразу выяснится, и я заподозрю неладное.
На практике эти процессы более сложные и надёжные. Главное не хранить КЭП-файл и пароль от него где попало. 🙂
Telegram
Юрня, дно і нелогічність
Якщо ви підписали договір ЕЦП (КЕП), то друкувати чи зберігати його у паперовому вигляді непотрібно 👌
Для тих, хто не знає, що таке електронний цифровий підпис чи кваліфікований електронний підпис, ось тут є інтро. Як прочитаєте, повертайтесь.
Отже:
1.…
Для тих, хто не знає, що таке електронний цифровий підпис чи кваліфікований електронний підпис, ось тут є інтро. Як прочитаєте, повертайтесь.
Отже:
1.…
🍯 Как юристу заработать на автоматизации
часть 1 — формируем картину настоящего и будущего
Disclaimer: Нижеследующие размышления не связаны с моей практикой, все совпадения случайны. Поехали.
Гипотетически представим ваш расклад до автоматизации:
▪️ вы многопрофильный юрист и у вас есть один вид задач, механизм выполнения которых вы отточили — создание несложных документов;
▪️ клиент даёт данные, а вы: в зависимости от сочетания двух обстоятельств, указанных в этих же данных, выбираете 1 из 5 возможных шаблонов, вносите в него эти данные и отправляете клиенту;
▪️ за 1 такой документ вы получаете 8 долларов (~ 208 гривен);
▪️ таких документов в день в среднем 2, каждый занимает по 25 минут времени (21 на создание, 4 на вычитку);
▪️ итак, в день вы тратите 50 минут, зарабатывая 16 долларов; иначе говоря, трата времени и сил на эту задачу приносит вам 1 доллар примерно каждые 3 минуты.
Представим ваш расклад после автоматизации:
▫️ имея представление о технологиях, вы прикинули, что, щёлкая по кнопочкам интерфейса, вы будете создавать такой документ не за 25 минут, а в среднем за 6 минут (2 на создание, 4 на вычитку);
▫️ вы понимаете, что на эту же задачу будет уходить почти в 4 раза меньше времени;
▫️ итак, в день вы будете тратить в среднем 12 минут, зарабатывая те же 16 долларов; иначе говоря, теперь каждые 45 секунд приносят вам 1 доллар;
▫️ но при этом больше таких документов в "сэкономленные" 38 минут ( 50 - 12 = 38 ) вы всунуть не сможете, ибо эти заказы не стоят у вас в очереди, а появляются в среднем дважды в день.
🤔 Выглядит приятно. Но теперь нужно прикинуть, сколько времени и средств вы потратите на перекидывание этого моста из настоящего в будущее — разработку продукта (интерфейса с кнопочками). Нутро подсказывает вам (и весьма правильно), что тут одним интерфейсом не обойтись, ведь вам нужно, чтобы генерировались готовые файлы в формате .docx, которые вы затем будете 4 минуты вычитывать. Вы дорожите своей репутацией и не будете отсылать клиенту невычитанный документ, а вычитывать быстрее у вас не получается.
😳 И, когда продукт будет готов, вы допускаете, что иногда могут вылезать какие-то неприятности и неучтённые на этапе разработки нюансы, которые поначалу будут усложнять подготовку отдельных документов. Если это будет часто, вы можете нервничать и даже иногда делать работу "с нуля по старинке". В итоге можете даже пожалеть о таком "инноваторстве", вернуться в прошлое и сжечь мост.
Поэтому, чтобы не сжигались мосты, в следующем посте продолжу размышления и подсчёты.
#автоматизация #заработок #деньги
часть 1 — формируем картину настоящего и будущего
Disclaimer: Нижеследующие размышления не связаны с моей практикой, все совпадения случайны. Поехали.
Гипотетически представим ваш расклад до автоматизации:
▪️ вы многопрофильный юрист и у вас есть один вид задач, механизм выполнения которых вы отточили — создание несложных документов;
▪️ клиент даёт данные, а вы: в зависимости от сочетания двух обстоятельств, указанных в этих же данных, выбираете 1 из 5 возможных шаблонов, вносите в него эти данные и отправляете клиенту;
▪️ за 1 такой документ вы получаете 8 долларов (~ 208 гривен);
▪️ таких документов в день в среднем 2, каждый занимает по 25 минут времени (21 на создание, 4 на вычитку);
▪️ итак, в день вы тратите 50 минут, зарабатывая 16 долларов; иначе говоря, трата времени и сил на эту задачу приносит вам 1 доллар примерно каждые 3 минуты.
Представим ваш расклад после автоматизации:
▫️ имея представление о технологиях, вы прикинули, что, щёлкая по кнопочкам интерфейса, вы будете создавать такой документ не за 25 минут, а в среднем за 6 минут (2 на создание, 4 на вычитку);
▫️ вы понимаете, что на эту же задачу будет уходить почти в 4 раза меньше времени;
▫️ итак, в день вы будете тратить в среднем 12 минут, зарабатывая те же 16 долларов; иначе говоря, теперь каждые 45 секунд приносят вам 1 доллар;
▫️ но при этом больше таких документов в "сэкономленные" 38 минут ( 50 - 12 = 38 ) вы всунуть не сможете, ибо эти заказы не стоят у вас в очереди, а появляются в среднем дважды в день.
🤔 Выглядит приятно. Но теперь нужно прикинуть, сколько времени и средств вы потратите на перекидывание этого моста из настоящего в будущее — разработку продукта (интерфейса с кнопочками). Нутро подсказывает вам (и весьма правильно), что тут одним интерфейсом не обойтись, ведь вам нужно, чтобы генерировались готовые файлы в формате .docx, которые вы затем будете 4 минуты вычитывать. Вы дорожите своей репутацией и не будете отсылать клиенту невычитанный документ, а вычитывать быстрее у вас не получается.
😳 И, когда продукт будет готов, вы допускаете, что иногда могут вылезать какие-то неприятности и неучтённые на этапе разработки нюансы, которые поначалу будут усложнять подготовку отдельных документов. Если это будет часто, вы можете нервничать и даже иногда делать работу "с нуля по старинке". В итоге можете даже пожалеть о таком "инноваторстве", вернуться в прошлое и сжечь мост.
Поэтому, чтобы не сжигались мосты, в следующем посте продолжу размышления и подсчёты.
#автоматизация #заработок #деньги
🍯 Как юристу заработать на автоматизации
часть 2 — продолжаем считать и рационализировать
Прежде, чем окунаться в разработку, нужно ещё посчитать. Да, разработка IT-продукта — это не только час фигачить код, два часа исправлять ошибки и фигачить дальше, а ещё и предварительные расчёты. Ведь зачем тратить время, если выгода от продукта будет сомнительной?
Вы понимаете, что как минимум 1 год будете предоставлять такую услугу. Если предположить, что вы работаете без отпусков 5 дней в неделю, но не работаете ещё в 12 разных праздников, тогда вы задействуете (365/7*5)-12 = 248 дней и заработаете около 248*16 = 3968 долларов:
▪️ до автоматизации — потратив на это 248*50мин = 206 часов.
▫️ с автоматизацией — потратив на это 248*12мин = 49 часов.
То есть интерфейс поможет вам "выиграть" 206-49 = 157 часов. Если "слепить" эти часы, то это 6 с половиной суток. И тут начинается самое интересное. Если вы привыкли крайне рационализировать своё бытие и поэтому вам крайне важно "не проиграть", тогда:
⏱ вы не должны потратить на разработку и исправление всяких ошибок больше 157 часов, то есть 6 с половиной суток;
💵 вы не должны потратить на разработку больше некой разумной суммы. Как высчитать эту сумму? А тут нужно понять, насколько вы оцениваете своё время. Сколько стоит час вашей работы? 50, 100, 200 долларов? А если честно? Может, 400, 200 или 100 гривен?
Ладно, посмотрим иначе на этот болезненный вопрос. Предварительные расчёты показали, что вы зарабатываете 1 доллар в 3 минуты, значит час такой вашей работы вы конклюдентно оцениваете в 20 долларов.
🧮 Итак, "выигранные" 157 часов, сулимые автоматизацией, можно оценить через призму 157*20 = 3140 долларов. Значит, разработка такого интерфейса уж точно не должна превысить эту сумму. А она и не превысит. За 600-700 долларов вам его точно сделают на заказ. А то и за меньшую сумму, смотря где найдёте фрилансера. Также, ваше участие в разработке не должно превысить 157 часов. Но и это вряд ли произойдёт, если вы специалист в своём деле, у вас не семь пятниц в неделю и вы адекватно общаетесь с людьми.
Но ещё рано радоваться, чуть позже продолжу размышления. И ведь не затронут вопрос, что будет, если вы возьмётесь кодить сами, ведь канал прежде всего об этом.
часть 2 — продолжаем считать и рационализировать
Прежде, чем окунаться в разработку, нужно ещё посчитать. Да, разработка IT-продукта — это не только час фигачить код, два часа исправлять ошибки и фигачить дальше, а ещё и предварительные расчёты. Ведь зачем тратить время, если выгода от продукта будет сомнительной?
Вы понимаете, что как минимум 1 год будете предоставлять такую услугу. Если предположить, что вы работаете без отпусков 5 дней в неделю, но не работаете ещё в 12 разных праздников, тогда вы задействуете (365/7*5)-12 = 248 дней и заработаете около 248*16 = 3968 долларов:
▪️ до автоматизации — потратив на это 248*50мин = 206 часов.
▫️ с автоматизацией — потратив на это 248*12мин = 49 часов.
То есть интерфейс поможет вам "выиграть" 206-49 = 157 часов. Если "слепить" эти часы, то это 6 с половиной суток. И тут начинается самое интересное. Если вы привыкли крайне рационализировать своё бытие и поэтому вам крайне важно "не проиграть", тогда:
⏱ вы не должны потратить на разработку и исправление всяких ошибок больше 157 часов, то есть 6 с половиной суток;
💵 вы не должны потратить на разработку больше некой разумной суммы. Как высчитать эту сумму? А тут нужно понять, насколько вы оцениваете своё время. Сколько стоит час вашей работы? 50, 100, 200 долларов? А если честно? Может, 400, 200 или 100 гривен?
Ладно, посмотрим иначе на этот болезненный вопрос. Предварительные расчёты показали, что вы зарабатываете 1 доллар в 3 минуты, значит час такой вашей работы вы конклюдентно оцениваете в 20 долларов.
🧮 Итак, "выигранные" 157 часов, сулимые автоматизацией, можно оценить через призму 157*20 = 3140 долларов. Значит, разработка такого интерфейса уж точно не должна превысить эту сумму. А она и не превысит. За 600-700 долларов вам его точно сделают на заказ. А то и за меньшую сумму, смотря где найдёте фрилансера. Также, ваше участие в разработке не должно превысить 157 часов. Но и это вряд ли произойдёт, если вы специалист в своём деле, у вас не семь пятниц в неделю и вы адекватно общаетесь с людьми.
Но ещё рано радоваться, чуть позже продолжу размышления. И ведь не затронут вопрос, что будет, если вы возьмётесь кодить сами, ведь канал прежде всего об этом.
🍯 Как юристу заработать на автоматизации
часть 3 — мучаем фрилансеров или делаем из себя лигалинженера
Итак, мы пришли к тому, что на разработку IT-продукта для автоматизации своей задачи при указанных условиях нужно потратить не более 157 часов личного времени и/или не более 3140 долларов.
Также нужно учесть такие факторы:
1) изменится ли за следующий год правовое регулирование этого вопроса настолько, что либо данная услуга исчезнет, либо её автоматизация станет невозможна, либо продукт придётся основательно переделывать/дорабатывать?
2) насколько остро может возникать потребность в доработке продукта?
Допустим, с этими вопросами у вас всё в порядке. Тогда можете заказать продукт за 600-700 долларов (или меньше), получить и радоваться. Неделю-месяц поработать, собрать список доработок и правок, обратиться к тому же фрилансеру и доработать ещё долларов за 50-200 (зависимо от масштабов/глубины доработки). А потом вы снова захотите что-то улучшить – и снова заплатите. И вот здесь вам может прийти мысль: "а если б я кодила(-а), тогда на ходу лично вносил(-а) бы эти правки, в любой удобный момент…". Что ж, тогда добро пожаловать на тернистый путь лигалинженерии.
Что же будет, если вы решитесь сделать этот продукт собственными руками/головой? Если всё, что вы знаете о кодинге — Паскаль со школы — это уже неплохо, но всё же очень мало. Нужно учиться.
👍 Хорошая новость: научиться всему необходимому для кодинга интерфейса с генерацией и заполнением .docx-файлов из заданных шаблонов по заданным правилам можно самостоятельно и бесплатно (при условии, что у вас есть Интернет и компьютер). Как я уже писал, для этого не нужно быть гуру в математике и English. Нужна базовая логика и важен педантизм.
🌪 Не очень хорошая новость: скорость обучения и успех вообще будут зависеть от вашего склада ума и умения учиться новому. Тут я уже не в силах рассчитать, сколько вам понадобится времени. Если всё пойдёт отлично — справитесь за две недели. Если не очень — то за месяц-два. И есть вероятность бросить всё на полпути, а значит — потерять время. Также важен способ обучения, который вы выберете.
🧞♂️ Важная новость: но если вы освоите кодинг, сделаете этот первый интерфейс и в дальнейшем поставите алгоритмизацию и автоматизацию себе на службу — однажды вы сможете создать джинна. И тогда уже не пожалеете о том времени и средствах, которые вам пришлось затратить на своё обучение, на преодоление боли непонимания каких-то технических вещей.
Подробнее об этом — в следующем посте.
часть 3 — мучаем фрилансеров или делаем из себя лигалинженера
Итак, мы пришли к тому, что на разработку IT-продукта для автоматизации своей задачи при указанных условиях нужно потратить не более 157 часов личного времени и/или не более 3140 долларов.
Также нужно учесть такие факторы:
1) изменится ли за следующий год правовое регулирование этого вопроса настолько, что либо данная услуга исчезнет, либо её автоматизация станет невозможна, либо продукт придётся основательно переделывать/дорабатывать?
2) насколько остро может возникать потребность в доработке продукта?
Допустим, с этими вопросами у вас всё в порядке. Тогда можете заказать продукт за 600-700 долларов (или меньше), получить и радоваться. Неделю-месяц поработать, собрать список доработок и правок, обратиться к тому же фрилансеру и доработать ещё долларов за 50-200 (зависимо от масштабов/глубины доработки). А потом вы снова захотите что-то улучшить – и снова заплатите. И вот здесь вам может прийти мысль: "а если б я кодила(-а), тогда на ходу лично вносил(-а) бы эти правки, в любой удобный момент…". Что ж, тогда добро пожаловать на тернистый путь лигалинженерии.
Что же будет, если вы решитесь сделать этот продукт собственными руками/головой? Если всё, что вы знаете о кодинге — Паскаль со школы — это уже неплохо, но всё же очень мало. Нужно учиться.
👍 Хорошая новость: научиться всему необходимому для кодинга интерфейса с генерацией и заполнением .docx-файлов из заданных шаблонов по заданным правилам можно самостоятельно и бесплатно (при условии, что у вас есть Интернет и компьютер). Как я уже писал, для этого не нужно быть гуру в математике и English. Нужна базовая логика и важен педантизм.
🌪 Не очень хорошая новость: скорость обучения и успех вообще будут зависеть от вашего склада ума и умения учиться новому. Тут я уже не в силах рассчитать, сколько вам понадобится времени. Если всё пойдёт отлично — справитесь за две недели. Если не очень — то за месяц-два. И есть вероятность бросить всё на полпути, а значит — потерять время. Также важен способ обучения, который вы выберете.
🧞♂️ Важная новость: но если вы освоите кодинг, сделаете этот первый интерфейс и в дальнейшем поставите алгоритмизацию и автоматизацию себе на службу — однажды вы сможете создать джинна. И тогда уже не пожалеете о том времени и средствах, которые вам пришлось затратить на своё обучение, на преодоление боли непонимания каких-то технических вещей.
Подробнее об этом — в следующем посте.
⚠️ И судя по этому скриншоту, осталось 5 билетов на ивент Coding4Lawyers, который состоится в следующую субботу в Киеве. Думал, их там больше, решил сообщить вам. Если кто-то ждал антипрокрастинационный знак от Вселенной, это может быть оно. 🧞♀
У меня там будет лекция-презентация о том, как закодить часть своей рутины не за месяц, а за несколько часов.
У меня там будет лекция-презентация о том, как закодить часть своей рутины не за месяц, а за несколько часов.
🍯 Как юристу заработать на автоматизации
часть 4 — финансовая формула автоматизации юриста
Обещал рассказать о джинне 🧞♀️, но сначала ещё немного математики. По итогам предыдущих трёх постов я предлагаю вам такую формулу финансовой оценки автоматизации работы отдельно взятого юриста:
y = hoursBefore * hourCost : (hoursAfter * hourCost + hoursWasted * hourCost + spendings)
Составляющие этой формулы описаны на веб-сайте канала. Вы там можете даже вписать свои расчётные данные и увидеть вердикт, насколько хороша будет такая автоматизация в финансовом плане. Прокомментировать это всё вы можете в "гуманитарном" чате, в "кодерском", и даже на Facebook, Axon Partners тоже запостили это.
Кто будет тестить, там вы увидите кнопку "показать удачный кейс". Она проиллюстрирует довольно неплохую, на мой взгляд, ситуацию:
💰 стоимость часа: 70 у.е. (в данном случае я подразумевал доллары, оценив час работы юриста в 70$)
⏳ кол-во часов до автоматизации: 400
⌛️ кол-во часов после автоматизации: 80
⏲ кол-во часов, затраченных на автоматизацию: 52
💸 стоимость автоматизации: 900 у.е. (важно не забыть включить сюда расходы на софт, хостинг, доменное имя и разные подписки на весь расчётный период, если таковые будут иметь место)
🌡 Получаем коэффициент: 2.761. Так как это больше единицы, это значит, что проект выходит в плюс. Кроме этого, интерфейс выведет вам другие полезные данные. И ещё есть кнопка с "плохим кейсом".
В общем, прошу потестить. Как вам оно?
часть 4 — финансовая формула автоматизации юриста
Обещал рассказать о джинне 🧞♀️, но сначала ещё немного математики. По итогам предыдущих трёх постов я предлагаю вам такую формулу финансовой оценки автоматизации работы отдельно взятого юриста:
y = hoursBefore * hourCost : (hoursAfter * hourCost + hoursWasted * hourCost + spendings)
Составляющие этой формулы описаны на веб-сайте канала. Вы там можете даже вписать свои расчётные данные и увидеть вердикт, насколько хороша будет такая автоматизация в финансовом плане. Прокомментировать это всё вы можете в "гуманитарном" чате, в "кодерском", и даже на Facebook, Axon Partners тоже запостили это.
Кто будет тестить, там вы увидите кнопку "показать удачный кейс". Она проиллюстрирует довольно неплохую, на мой взгляд, ситуацию:
💰 стоимость часа: 70 у.е. (в данном случае я подразумевал доллары, оценив час работы юриста в 70$)
⏳ кол-во часов до автоматизации: 400
⌛️ кол-во часов после автоматизации: 80
⏲ кол-во часов, затраченных на автоматизацию: 52
💸 стоимость автоматизации: 900 у.е. (важно не забыть включить сюда расходы на софт, хостинг, доменное имя и разные подписки на весь расчётный период, если таковые будут иметь место)
🌡 Получаем коэффициент: 2.761. Так как это больше единицы, это значит, что проект выходит в плюс. Кроме этого, интерфейс выведет вам другие полезные данные. И ещё есть кнопка с "плохим кейсом".
В общем, прошу потестить. Как вам оно?
🍯 Как юристу заработать на автоматизации
часть 5 — глядим не на деньги, а в свою бездну
💻 На том интерфейсе кнопка "показать плохой кейс" покажет, как вы теряете за год 3 570 долларов. Причина: автоматизация не делает вашу работу значительно быстрее, стоит ощутимо много и "съедает" ваше время.
🎽 Но нужно ли считать себя неудачником/неудачницей после этого? Зависит от того, насколько лично вы были вовлечены в эту автоматизацию, стали ли вы понимать логику алгоритмов и вычислительной техники, научились ли вы находить автоматизируемые закономерности в вашей работе, поняли ли, где и насколько компьютер может вас заменить в вашей работе, стать вашим "стажёром" или даже "джуном".
Если да — то вы приобрели современное, пока не очень распространённое знание, которое может сыграть хорошую роль в вашем юридическом будущем. Потому что ваши конкуренты уже используют разные технические решения, позволяющие им экономить своё время и снижать цены на ваши услуги. Возможно, это пока не касается некоторых специфических отраслей, таких как уголовное право. Хотя представители Сьерра-Леоне (солнечная Африка ☀️) в этом году показали обнадёживающую инновацию в сфере уголовного права/процесса, за что получили первое место на международном конкурсе HiiL, обойдя крутой проект AxDraft, который сейчас оценён больше, чем некоторые топовые украинские юрфирмы. Видите, жюри поставили выше не деньги.
🌱 Не всегда ваши первые попытки что-то автоматизировать будут удачны. Из моих трёх первых лигалинженерских проектов один был заморожен, а два других — закрыты. Но на всех трёх я научился кодить, и это теперь моя профессия. Истории известно, что люди не сразу раскрывают потенциал того знания, с которым сталкиваются. Поэтому нельзя точно назначить цену для знаний на момент их получения. 4-6 лет обучения на юрфаке на многотысячном контракте могут принести человеку меньше, чем два ивента по 10-15 баксов, на которых ему что-то западёт в душу и затем прорастёт.
💥 В эту субботу в Киеве прошёл сочный ивент — Coding 4 Lawyers. На протяжении 6 часов десятки юристов смотрели презентации о:
▫️ расширениях браузеров и как кодить прямо на чужих веб-сайтах;
▫️ написании JavaScript-кода на codepen.io, убивающего вашу рутину;
▫️ предназначении и структуре JSON;
▫️ проверке контрагентов ботом и других способах уменьшить концентрацию дичи в работе;
▫️ кодерских приёмах в праве и в чём договор должен быть похож на программу;
▫️ блокчейнизации и хэшировании;
▫️ автоматизации судебки Приватбанка;
▫️ сути лигалинженерии;
▫️ входе в айтишную профессию/экосистему.
Думаю, подробнее можно будет усмотреть здесь.
часть 5 — глядим не на деньги, а в свою бездну
💻 На том интерфейсе кнопка "показать плохой кейс" покажет, как вы теряете за год 3 570 долларов. Причина: автоматизация не делает вашу работу значительно быстрее, стоит ощутимо много и "съедает" ваше время.
🎽 Но нужно ли считать себя неудачником/неудачницей после этого? Зависит от того, насколько лично вы были вовлечены в эту автоматизацию, стали ли вы понимать логику алгоритмов и вычислительной техники, научились ли вы находить автоматизируемые закономерности в вашей работе, поняли ли, где и насколько компьютер может вас заменить в вашей работе, стать вашим "стажёром" или даже "джуном".
Если да — то вы приобрели современное, пока не очень распространённое знание, которое может сыграть хорошую роль в вашем юридическом будущем. Потому что ваши конкуренты уже используют разные технические решения, позволяющие им экономить своё время и снижать цены на ваши услуги. Возможно, это пока не касается некоторых специфических отраслей, таких как уголовное право. Хотя представители Сьерра-Леоне (солнечная Африка ☀️) в этом году показали обнадёживающую инновацию в сфере уголовного права/процесса, за что получили первое место на международном конкурсе HiiL, обойдя крутой проект AxDraft, который сейчас оценён больше, чем некоторые топовые украинские юрфирмы. Видите, жюри поставили выше не деньги.
🌱 Не всегда ваши первые попытки что-то автоматизировать будут удачны. Из моих трёх первых лигалинженерских проектов один был заморожен, а два других — закрыты. Но на всех трёх я научился кодить, и это теперь моя профессия. Истории известно, что люди не сразу раскрывают потенциал того знания, с которым сталкиваются. Поэтому нельзя точно назначить цену для знаний на момент их получения. 4-6 лет обучения на юрфаке на многотысячном контракте могут принести человеку меньше, чем два ивента по 10-15 баксов, на которых ему что-то западёт в душу и затем прорастёт.
💥 В эту субботу в Киеве прошёл сочный ивент — Coding 4 Lawyers. На протяжении 6 часов десятки юристов смотрели презентации о:
▫️ расширениях браузеров и как кодить прямо на чужих веб-сайтах;
▫️ написании JavaScript-кода на codepen.io, убивающего вашу рутину;
▫️ предназначении и структуре JSON;
▫️ проверке контрагентов ботом и других способах уменьшить концентрацию дичи в работе;
▫️ кодерских приёмах в праве и в чём договор должен быть похож на программу;
▫️ блокчейнизации и хэшировании;
▫️ автоматизации судебки Приватбанка;
▫️ сути лигалинженерии;
▫️ входе в айтишную профессию/экосистему.
Думаю, подробнее можно будет усмотреть здесь.
🍯 Автоматизация рутины и заработок юриста: выводы
Итак, какие выводы можно сделать из цикла постов на тему заработка от автоматизации своей рутины? У меня получились такие:
🔸 Чем более длительный период, который вы берёте за основу, тем более выгодна автоматизация. Тут простая логика: строишь дом один раз, живёшь в нём всю жизнь. Время от времени что-то отваливается, и ты чинишь, но всё равно большее время ощущается профит. Это пример так называемой инфраструктурной задачи, которая не является самоцелью, а создаёт благоприятные условия для достижения ваших истинных целей в жизни. Поэтому нет смысла требовать прибыль за первый месяц, если процесс автоматизации занял три недели.
🔸 Но у юристов отваливается чаще, чем у остальных профессий. Ведь в любой момент может измениться законодательство, повлияв на смену алгоритма автоматизации — придётся тратить ресурсы на доработку. А в худшем для вас случае банально может исчезнуть та работа, которую вы автоматизировали. И тогда архив с продуктом придётся закинуть куда-нибудь подальше. Или подумать, где ещё он может быть применён.
🔸 Ещё у автоматизации есть предел: всегда останется часть времени, которую вы не можете выкинуть из своего графика. В примерах ранее это те самые 6 минут на одну задачу. Поэтому стоит помнить, что продукт не заменит вас полностью, не выйдет вместо вас во время отпуска/больничного. Если только вы не найдёте способ даровать ему такую силу, в чём, по сути, и заключается суть истинно tech-нологичного legaltech.
🧞♀️ Но в любом случае у ваших опытов с автоматизацией ещё может быть нераскрытый потенциал: точка перехода к автономности. Сейчас сложно кого-то удивить тем, что компьютер быстрее человека находит искомое, быстрее считает, быстрее заполняет шаблоны. Но вы почувствуете бо́льшую силу, когда начнёте автономизировать ваши разработки, то есть когда вашему продукту не нужно будет ваше присутствие, чтобы выполнять какие-то задачи. Поэтому далее я расскажу о своём примере автономизирования при помощи чатбота.
Итак, какие выводы можно сделать из цикла постов на тему заработка от автоматизации своей рутины? У меня получились такие:
🔸 Чем более длительный период, который вы берёте за основу, тем более выгодна автоматизация. Тут простая логика: строишь дом один раз, живёшь в нём всю жизнь. Время от времени что-то отваливается, и ты чинишь, но всё равно большее время ощущается профит. Это пример так называемой инфраструктурной задачи, которая не является самоцелью, а создаёт благоприятные условия для достижения ваших истинных целей в жизни. Поэтому нет смысла требовать прибыль за первый месяц, если процесс автоматизации занял три недели.
🔸 Но у юристов отваливается чаще, чем у остальных профессий. Ведь в любой момент может измениться законодательство, повлияв на смену алгоритма автоматизации — придётся тратить ресурсы на доработку. А в худшем для вас случае банально может исчезнуть та работа, которую вы автоматизировали. И тогда архив с продуктом придётся закинуть куда-нибудь подальше. Или подумать, где ещё он может быть применён.
🔸 Ещё у автоматизации есть предел: всегда останется часть времени, которую вы не можете выкинуть из своего графика. В примерах ранее это те самые 6 минут на одну задачу. Поэтому стоит помнить, что продукт не заменит вас полностью, не выйдет вместо вас во время отпуска/больничного. Если только вы не найдёте способ даровать ему такую силу, в чём, по сути, и заключается суть истинно tech-нологичного legaltech.
🧞♀️ Но в любом случае у ваших опытов с автоматизацией ещё может быть нераскрытый потенциал: точка перехода к автономности. Сейчас сложно кого-то удивить тем, что компьютер быстрее человека находит искомое, быстрее считает, быстрее заполняет шаблоны. Но вы почувствуете бо́льшую силу, когда начнёте автономизировать ваши разработки, то есть когда вашему продукту не нужно будет ваше присутствие, чтобы выполнять какие-то задачи. Поэтому далее я расскажу о своём примере автономизирования при помощи чатбота.
🤖 Чатботы — пустышки: крюки да корзины
Наверняка, вы наслышаны о чатботах. Они всё чаще используются в бизнесе, в образовании, для поиска билетов и т.д. И я не раз слышал от людей что-то типа "Чатбот — это искусственный интеллект? Как он устроен?". Отвечаю.
Моё определение
Чатбот — доверенная создателю (вам) мессенджером сущность, которая в рамках интерфейса мессенджера по отношению к создателю (вам) и третим лицам занимает место собеседника, при этом способна связывать этих лиц со внешней интернет-средой по установленным мессенджером правилам.
При создании чатбота вам выдаётся токен (например, 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11), при помощи которого вы можете связать чатбота с нужным вам сервисом, как чужим, так и самописным. Например, в Telegram чатботы создаются при помощи @Botfather. Но в момент создания чатбот является пустышкой: в нём нет никакого содержания. Возможности чатботов целесообразно делить на две группы (хотя аналогичные возможности принадлежат и телеграм-аккаунтам самих людей). Условно называю их Корзина и Крюк.
🧺 Корзина
Когда появляется чатбот, он прежде всего становится одиноким слушателем в пустыне тишины. Для него большую часть времени ничего не происходит. А когда вдруг что-то происходит, он передаёт это своим подписавшимся слушателям (всем доступным или конкретному). Это и есть то, что именуется "пуш". Например, так выглядит простенький GET-запрос (его достаточно ввести в адресной строке браузера), который скидывает в корзину телеграм-чатботу текст "привет" с требованием передать его конкретному юзеру:
https://api.telegram.org/bot{TOKEN}/sendMessage?text=привет&chat_id={CHAT}, где:
🔹 вместо {TOKEN} подставляем токен чатбота, выданный @Botfather-ом;
🔹 вместо {CHAT} подставляем id чата, который был создан с этим чатботом интересующим нас юзером.
🏹 Крюк
Также чатботу можно подключить вебхук (от англ. webhook, где "hook" пришло от hooking в информатике, а буквально в конечном итоге переводится как "крюк"). Это означает, что все попадающее в чатбота со стороны юзеров-собеседников будет отправляться на указанный вами адрес в Интернете. Там эти запросы уже должен поджидать ваш скрипт, который с ними сделает то, что вам нужно. Этот же скрипт может вернуть некие данные в корзину чатбота, то есть "пропушить" в ответ.
Собственно, процесс программирования чатбота и заключается в том, чтобы на вашем сервере принимать от него (а точнее, от пишущих ему людей) входящие запросы (текст, файлы, картинки), обрабатывать их по нужной вам логике (NLP-алгоритмами, нейросетями, простым деревом решений, в общем, как хотите) и возвращать ответы. Причём можно возвращать как конкретному собеседнику чатбота, так и всем собеседникам. А сам чатбот является пустышкой, бессодержательным посредником между армией юзеров и вашими скриптами/алгоритмами, которые и должны, если вам этого хочется, изо всех сил имитировать "разум", "интеллект" и "эмоции". 🎅
Но почему тогда я разделяю эти возможности на две группы, если это составляющие единого процесса "запрос — ответ"? Да потому, что на практике можно использовать только одну возможность — "корзину", что я и делаю. Об этом расскажу дальше.
📑 Документация API чатботов Telegram
Наверняка, вы наслышаны о чатботах. Они всё чаще используются в бизнесе, в образовании, для поиска билетов и т.д. И я не раз слышал от людей что-то типа "Чатбот — это искусственный интеллект? Как он устроен?". Отвечаю.
Моё определение
Чатбот — доверенная создателю (вам) мессенджером сущность, которая в рамках интерфейса мессенджера по отношению к создателю (вам) и третим лицам занимает место собеседника, при этом способна связывать этих лиц со внешней интернет-средой по установленным мессенджером правилам.
При создании чатбота вам выдаётся токен (например, 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11), при помощи которого вы можете связать чатбота с нужным вам сервисом, как чужим, так и самописным. Например, в Telegram чатботы создаются при помощи @Botfather. Но в момент создания чатбот является пустышкой: в нём нет никакого содержания. Возможности чатботов целесообразно делить на две группы (хотя аналогичные возможности принадлежат и телеграм-аккаунтам самих людей). Условно называю их Корзина и Крюк.
🧺 Корзина
Когда появляется чатбот, он прежде всего становится одиноким слушателем в пустыне тишины. Для него большую часть времени ничего не происходит. А когда вдруг что-то происходит, он передаёт это своим подписавшимся слушателям (всем доступным или конкретному). Это и есть то, что именуется "пуш". Например, так выглядит простенький GET-запрос (его достаточно ввести в адресной строке браузера), который скидывает в корзину телеграм-чатботу текст "привет" с требованием передать его конкретному юзеру:
https://api.telegram.org/bot{TOKEN}/sendMessage?text=привет&chat_id={CHAT}, где:
🔹 вместо {TOKEN} подставляем токен чатбота, выданный @Botfather-ом;
🔹 вместо {CHAT} подставляем id чата, который был создан с этим чатботом интересующим нас юзером.
🏹 Крюк
Также чатботу можно подключить вебхук (от англ. webhook, где "hook" пришло от hooking в информатике, а буквально в конечном итоге переводится как "крюк"). Это означает, что все попадающее в чатбота со стороны юзеров-собеседников будет отправляться на указанный вами адрес в Интернете. Там эти запросы уже должен поджидать ваш скрипт, который с ними сделает то, что вам нужно. Этот же скрипт может вернуть некие данные в корзину чатбота, то есть "пропушить" в ответ.
Собственно, процесс программирования чатбота и заключается в том, чтобы на вашем сервере принимать от него (а точнее, от пишущих ему людей) входящие запросы (текст, файлы, картинки), обрабатывать их по нужной вам логике (NLP-алгоритмами, нейросетями, простым деревом решений, в общем, как хотите) и возвращать ответы. Причём можно возвращать как конкретному собеседнику чатбота, так и всем собеседникам. А сам чатбот является пустышкой, бессодержательным посредником между армией юзеров и вашими скриптами/алгоритмами, которые и должны, если вам этого хочется, изо всех сил имитировать "разум", "интеллект" и "эмоции". 🎅
Но почему тогда я разделяю эти возможности на две группы, если это составляющие единого процесса "запрос — ответ"? Да потому, что на практике можно использовать только одну возможность — "корзину", что я и делаю. Об этом расскажу дальше.
📑 Документация API чатботов Telegram
🙋♀️ Элина — чатбот-доносчик или чат-лог
Подзаголовок: как сделать чатбота, который будет полезен тем, что он тебе пишет, а ты ему нет.
За три года я сделал несколько разных сервисов, которыми приходится пользоваться другим людям. На этих сервисах есть формы по типу "оставить отзыв", "сообщение админу" или просто мониторинг активности юзеров. Один из них — наша база знаний в Axon Partners (далее — БЗ). В ней есть поле поиска результатов. Когда любой юзер вводит в поиск нечто, на что БЗ выдает ноль результатов или мало результатов, данные об этом событии сохраняются в отдельную таблицу базы данных.
И чтобы не лазить туда вручную с некоторой периодичностью (а значит — нечасто), я решил создать чатбота в Телеграме, назвать его Элиной и соорудить следующую штуку:
▫️ добавляем в эту таблицу колонку "wasChecked", значение по умолчанию — "no";
▫️ создаём на сервере cron-задачу с периодом срабатывания 10 минут, эта задача запускает скрипт, например, "checkBadRequestsLog.php";
▫️ этот скрипт выгружает из таблицы все строки, где наша колонка "wasChecked" равна "no", обрабатывает их, формируя текстовый пакет такого вида:
Неудавшихся запросов в БЗ – 2:
"proposal Каліфорнія" от Сергей Шевч., результатов 1;
"Estonia NDA" от Катя Нест., результатов 0.
▫️ далее отправляет этот текст чатботу (т.е. пушит) примерно тем образом, что я показывал выше;
▫️ и в конце ставим этим строкам отметку "yes" в колонке "wasChecked", чтобы через 10 минут эта информация не прилетела нам снова.
Вот и всё. Вышеописанное я повторил для 4-5 разных сервисов и один чатбот держит меня в курсе важных событий в разных точках. Если мои юзеры будут бедствовать или начнётся хакерская активность, которую смогут детектировать мои скрипты, я об этом узнаю быстро, ведь для этого достаточно быть онлайн в Телеграме. Такой механизм можно прикрутить почти ко всему, у чего есть API или что можно вменяемо парсить.
Вот поэтому я и полюбил метафору с корзиной 🧺, в которую сыплются плоды 🍎 (и личинки 🐛) с выращенных мной деревьев. Берите на вооружение. :)
Лигалинженеры, юзаете ли вы что-то подобное? Можем обсудить в чате.
Подзаголовок: как сделать чатбота, который будет полезен тем, что он тебе пишет, а ты ему нет.
За три года я сделал несколько разных сервисов, которыми приходится пользоваться другим людям. На этих сервисах есть формы по типу "оставить отзыв", "сообщение админу" или просто мониторинг активности юзеров. Один из них — наша база знаний в Axon Partners (далее — БЗ). В ней есть поле поиска результатов. Когда любой юзер вводит в поиск нечто, на что БЗ выдает ноль результатов или мало результатов, данные об этом событии сохраняются в отдельную таблицу базы данных.
И чтобы не лазить туда вручную с некоторой периодичностью (а значит — нечасто), я решил создать чатбота в Телеграме, назвать его Элиной и соорудить следующую штуку:
▫️ добавляем в эту таблицу колонку "wasChecked", значение по умолчанию — "no";
▫️ создаём на сервере cron-задачу с периодом срабатывания 10 минут, эта задача запускает скрипт, например, "checkBadRequestsLog.php";
▫️ этот скрипт выгружает из таблицы все строки, где наша колонка "wasChecked" равна "no", обрабатывает их, формируя текстовый пакет такого вида:
Неудавшихся запросов в БЗ – 2:
"proposal Каліфорнія" от Сергей Шевч., результатов 1;
"Estonia NDA" от Катя Нест., результатов 0.
▫️ далее отправляет этот текст чатботу (т.е. пушит) примерно тем образом, что я показывал выше;
▫️ и в конце ставим этим строкам отметку "yes" в колонке "wasChecked", чтобы через 10 минут эта информация не прилетела нам снова.
Вот и всё. Вышеописанное я повторил для 4-5 разных сервисов и один чатбот держит меня в курсе важных событий в разных точках. Если мои юзеры будут бедствовать или начнётся хакерская активность, которую смогут детектировать мои скрипты, я об этом узнаю быстро, ведь для этого достаточно быть онлайн в Телеграме. Такой механизм можно прикрутить почти ко всему, у чего есть API или что можно вменяемо парсить.
Вот поэтому я и полюбил метафору с корзиной 🧺, в которую сыплются плоды 🍎 (и личинки 🐛) с выращенных мной деревьев. Берите на вооружение. :)
Лигалинженеры, юзаете ли вы что-то подобное? Можем обсудить в чате.
🍎🍏 Как задать два вопроса в одном
Во многих лигалтек-решениях нам нужно строить алгоритм, задающий вопросы клиенту или другому собеседнику (далее — юзер). Нередко это происходит в чатботе.
🐢 Правилом хорошего тона (а также условием хорошей конверсии) является составление алгоритма таким образом, чтобы юзер совершал как можно меньше лишних действий. Например, не нужно спрашивать его номер телефона дважды, когда можно с первого раза сохранить эту информацию в привязке к аккаунту.
И разумеется, нужно оптимизировать порядок вопросов таким образом, чтобы не вытягивать из юзера те ответы, которые при некоторых дальнейших условиях могут не понадобиться. Но кроме этого, есть ещё один неочевидный приём, позволяющий сократить количество утомляющих ситуаций "вопрос-ответ".
1️⃣ Например, у нас может возникнуть ситуация такого типа:
вопрос А. Есть ли у вас ФЛП?
ответ А1. да
ответ А2. нет
вопрос Б (если был дан ответ А1). Он находится на 3-й группе налогообложения?
ответ Б1. да, на 3-й
ответ Б2. нет, не на 3-й
По результатам этого диалога мы заполняем свои переменные userHasFLP ( true / false ) и isTaxGroup3 ( true / false ), каждая заполняется в "своём", отведённом для этого вопросе.
2️⃣ Но того же результата можно достичь всего одним вопросом:
вопрос. Есть ли у вас ФЛП, и на какой группе налогообложения?
ответ 1. есть, 3-я группа
ответ 2. есть, не 3-я группа
ответ 3. нету
Как заполняются переменные в обоих сценариях, смотрите на схеме ниже. Думаю, в чатботе такой подход сделал бы этот участок более приятным для юзера, особенно в условиях, когда диалог приходится запускать заново.
Во многих лигалтек-решениях нам нужно строить алгоритм, задающий вопросы клиенту или другому собеседнику (далее — юзер). Нередко это происходит в чатботе.
🐢 Правилом хорошего тона (а также условием хорошей конверсии) является составление алгоритма таким образом, чтобы юзер совершал как можно меньше лишних действий. Например, не нужно спрашивать его номер телефона дважды, когда можно с первого раза сохранить эту информацию в привязке к аккаунту.
И разумеется, нужно оптимизировать порядок вопросов таким образом, чтобы не вытягивать из юзера те ответы, которые при некоторых дальнейших условиях могут не понадобиться. Но кроме этого, есть ещё один неочевидный приём, позволяющий сократить количество утомляющих ситуаций "вопрос-ответ".
1️⃣ Например, у нас может возникнуть ситуация такого типа:
вопрос А. Есть ли у вас ФЛП?
ответ А1. да
ответ А2. нет
вопрос Б (если был дан ответ А1). Он находится на 3-й группе налогообложения?
ответ Б1. да, на 3-й
ответ Б2. нет, не на 3-й
По результатам этого диалога мы заполняем свои переменные userHasFLP ( true / false ) и isTaxGroup3 ( true / false ), каждая заполняется в "своём", отведённом для этого вопросе.
2️⃣ Но того же результата можно достичь всего одним вопросом:
вопрос. Есть ли у вас ФЛП, и на какой группе налогообложения?
ответ 1. есть, 3-я группа
ответ 2. есть, не 3-я группа
ответ 3. нету
Как заполняются переменные в обоих сценариях, смотрите на схеме ниже. Думаю, в чатботе такой подход сделал бы этот участок более приятным для юзера, особенно в условиях, когда диалог приходится запускать заново.
🥅 Добавим немного интерактива в монолог?
// код (JavaScript):
let a = 5;
let b = 2;
let c = a + a;
let x = c / b;
let y = b-1;
// выводим в консоль:
console.log(x);
Вопрос:
каково значение переменной x?
// код (JavaScript):
let a = 5;
let b = 2;
let c = a + a;
let x = c / b;
let y = b-1;
// выводим в консоль:
console.log(x);
Вопрос:
каково значение переменной x?