🎛 Работаем параллельно
Представьте, что юридическая фирма "Альбус и партнёры" через 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%.
Ну и, как всегда, держите визуализацию:
Представьте, что юридическая фирма "Альбус и партнёры" через 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%.
Ну и, как всегда, держите визуализацию:
🐗 Перешёл в IT
недоспойлер: в продуктовую компанию (о термине), больше пока сказать не могу
Каюсь, давно не писал посты сюда. Всё это время искал работу в IT, параллельно лихорадочно повышая квалификацию. Спустя 6 недель поисков удалось найти. Позади осталось около 10 отказов, из них 1 проваленный скрининг по телефону и 2 проваленных тестовых задания. Также 7 заявок остались без ответа. Но благодаря всему этому я узнал, насколько был некомпетентен всё это время. Например:
💀 Все созданные мной продукты не соответствуют ни одному паттерну проектирования. А зря. Это ппц важная штука.
💀 ООП на практике применял очень редко, а зря (да-да, овладел искусством процедурного и функционального стилей).
💀 Не работал с Линуксом и консолью, не знал даже базовых команд, а зря. Но на новой работе с первых же минут пришлось освоить, а спустя три дня осознал, насколько это нужно и полезно.
💀 Не работал с фреймворками для своего основного языка программирования (PHP). Очень зря. Этот пункт не позволил даже просто податься на массу аппетитных вакансий (именно джуновских). Часто требуется хотя бы полгода-год опыта с тем или иным фреймворком. Видел даже вакансию от крутого проекта из нашей лигалтек-экосистемы "Legal Nodes", там нужен был опыт с фреймворком.
Поэтому, уважаемые свитчеры, кто хочет перейти на сторону IT как программист, советую сначала поизучать вакансии, выписать из них кучу незнакомых слов, которые пишут работодатели, и разбираться, разбираться, разбираться. Готовиться к любому контакту с работодателем как к смеси экзамена и турнира на вылет. Да вообще советов ещё уйму можно дать, и их в Интернете пруд пруди. Кстати, тут скоро будет занятный ивент на тему свитчерства по маршруту "право - IT", меня с моим диагнозом туда тоже взяли. 🤕
P.S. Канал будет жить, вас не брошу. Он не для рекламы, а ради торжества нашей юной лигалинженерской отрасли. Скоро возобновлю поставку постов.
недоспойлер: в продуктовую компанию (о термине), больше пока сказать не могу
Каюсь, давно не писал посты сюда. Всё это время искал работу в IT, параллельно лихорадочно повышая квалификацию. Спустя 6 недель поисков удалось найти. Позади осталось около 10 отказов, из них 1 проваленный скрининг по телефону и 2 проваленных тестовых задания. Также 7 заявок остались без ответа. Но благодаря всему этому я узнал, насколько был некомпетентен всё это время. Например:
💀 Все созданные мной продукты не соответствуют ни одному паттерну проектирования. А зря. Это ппц важная штука.
💀 ООП на практике применял очень редко, а зря (да-да, овладел искусством процедурного и функционального стилей).
💀 Не работал с Линуксом и консолью, не знал даже базовых команд, а зря. Но на новой работе с первых же минут пришлось освоить, а спустя три дня осознал, насколько это нужно и полезно.
💀 Не работал с фреймворками для своего основного языка программирования (PHP). Очень зря. Этот пункт не позволил даже просто податься на массу аппетитных вакансий (именно джуновских). Часто требуется хотя бы полгода-год опыта с тем или иным фреймворком. Видел даже вакансию от крутого проекта из нашей лигалтек-экосистемы "Legal Nodes", там нужен был опыт с фреймворком.
Поэтому, уважаемые свитчеры, кто хочет перейти на сторону IT как программист, советую сначала поизучать вакансии, выписать из них кучу незнакомых слов, которые пишут работодатели, и разбираться, разбираться, разбираться. Готовиться к любому контакту с работодателем как к смеси экзамена и турнира на вылет. Да вообще советов ещё уйму можно дать, и их в Интернете пруд пруди. Кстати, тут скоро будет занятный ивент на тему свитчерства по маршруту "право - IT", меня с моим диагнозом туда тоже взяли. 🤕
P.S. Канал будет жить, вас не брошу. Он не для рекламы, а ради торжества нашей юной лигалинженерской отрасли. Скоро возобновлю поставку постов.
🎡 Паттерны в кодинге и праве
В разработке часто встречаются повторяющиеся из десятилетия в десятилетие ситуации:
▫️ обработка заказов с разными дополнениями (чай с сахаром, кофе с двойными сливками);
▫️ управление игровыми персонажами и их динамично меняющимся поведением (разные баффы и дебаффы на разных персах в Дотке);
▫️ мониторинг изменений состояния некоего элемента со стороны разных субъектов;
и т.д.
Для грамотного программирования этих механизмов применяются разные паттерны. Паттерн — это устоявшаяся схема связывания между собой программных сущностей, при которой система получит определённые преимущества и недостатки. Задача паттерна — сделать хорошо и не сделать плохо. Ключевое проявление хорошести — "гибкость системы", то есть насколько удобно, легко и быстро можно будет вносить в неё изменения с минимальным риском что-нибудь сломать. Короче, правильно выбранный паттерн — сэкономленный бабос и нервы заказчика.
⚙️ В кодинге есть куча паттернов. Вот недавно решил освоить несколько из них и наткнулся на крутой сайт, где есть и объяснения, и хорошие примеры. Также о паттернах написана легко читающаяся книга с картинками (да почти с комиксами!). По этим источникам внимательно изучаю и отрабатываю на практике паттерны, перед тем как лепить их в резюме.
⚖️ В праве тоже есть паттерны. Например, паттерны структурирования закона, судебного решения и договора различны. Если закон и договор ещё как-то можно сделать похожими по структуре, то судебные решения ярко от них отличаются. Но в то же время, для них одновременно характерен такой функциональный паттерн, как использование ссылки на положения, которые уже прозвучали:
1️⃣ (далі по тексту - Виконавець) — см. во многих договорах
2️⃣ (далі - Реєстр) — см в ч. 1 ст. 16 этого закона
3️⃣ (0.3, 0.5 і 1 грам, - далі «доза») — см. в этом решении
Следование паттернам, их правильное применение и в программировании, и в праве позволяет:
🔹 добиться быстрого обмена информацией между программистами / между юристами;
🔹 добиться быстрого восприятия происходящего в коде, договоре, судебном решении и т.д. человеком, который видит этот код/документ впервые;
🔹 создать эффективный код/документ, с которыми легко и приятно работать, вносить изменения без большого риска заложить баги.
⚠️ Важно: следует отличать паттерны проектирования (Strategy, Decorator, Adapter и т.д.) от принципов разработки (DRY, KISS, YAGNI, SOLID). Кстати, я уже писал ранее о принципах DRY и KISS.
В разработке часто встречаются повторяющиеся из десятилетия в десятилетие ситуации:
▫️ обработка заказов с разными дополнениями (чай с сахаром, кофе с двойными сливками);
▫️ управление игровыми персонажами и их динамично меняющимся поведением (разные баффы и дебаффы на разных персах в Дотке);
▫️ мониторинг изменений состояния некоего элемента со стороны разных субъектов;
и т.д.
Для грамотного программирования этих механизмов применяются разные паттерны. Паттерн — это устоявшаяся схема связывания между собой программных сущностей, при которой система получит определённые преимущества и недостатки. Задача паттерна — сделать хорошо и не сделать плохо. Ключевое проявление хорошести — "гибкость системы", то есть насколько удобно, легко и быстро можно будет вносить в неё изменения с минимальным риском что-нибудь сломать. Короче, правильно выбранный паттерн — сэкономленный бабос и нервы заказчика.
⚙️ В кодинге есть куча паттернов. Вот недавно решил освоить несколько из них и наткнулся на крутой сайт, где есть и объяснения, и хорошие примеры. Также о паттернах написана легко читающаяся книга с картинками (да почти с комиксами!). По этим источникам внимательно изучаю и отрабатываю на практике паттерны, перед тем как лепить их в резюме.
⚖️ В праве тоже есть паттерны. Например, паттерны структурирования закона, судебного решения и договора различны. Если закон и договор ещё как-то можно сделать похожими по структуре, то судебные решения ярко от них отличаются. Но в то же время, для них одновременно характерен такой функциональный паттерн, как использование ссылки на положения, которые уже прозвучали:
1️⃣ (далі по тексту - Виконавець) — см. во многих договорах
2️⃣ (далі - Реєстр) — см в ч. 1 ст. 16 этого закона
3️⃣ (0.3, 0.5 і 1 грам, - далі «доза») — см. в этом решении
Следование паттернам, их правильное применение и в программировании, и в праве позволяет:
🔹 добиться быстрого обмена информацией между программистами / между юристами;
🔹 добиться быстрого восприятия происходящего в коде, договоре, судебном решении и т.д. человеком, который видит этот код/документ впервые;
🔹 создать эффективный код/документ, с которыми легко и приятно работать, вносить изменения без большого риска заложить баги.
⚠️ Важно: следует отличать паттерны проектирования (Strategy, Decorator, Adapter и т.д.) от принципов разработки (DRY, KISS, YAGNI, SOLID). Кстати, я уже писал ранее о принципах DRY и KISS.
🎼 BPMN — разложи свой бизнес-процесс по нотам
Обнаружил ещё одну замечательную точку приложения усилий лигалинженера (и не только) — создание и обслуживание схем на языке моделирования бизнес-процессов BPMN при автоматизации чего-либо. Это такие схемы, где в большей мере человекочитаемым языком можно показать логику взаимодействий нескольких слоёв многоуровневой системы. Система может состоять из человеков, софта и чего угодно. Расписать можно как абстрактно, так и конкретно, отмечая каждое действие, особенно в точках взаимодействий слоёв.
На подобной схеме ниже изобразил, что происходит, когда я, используя телеграм-бота, отправляю информацию на бэкенд своего веб-сервера, чтобы сохранить её в базе данных. Использовал этот онлайн-сервис. Есть и куча других.
Такие схемы помогают удобно передавать знания об устройстве и работе системы, а также видеть, сколько раз в общий поток вклинивается тот или иной слой. Например, чётко видно, что человек (я) на своём слое лишь пишет и отправляет сообщение, а затем (не успев даже моргнуть) увидит уже отчёт о результате. Пока человек ждёт, "под капотом" произойдёт куча того, что иногда называют "магией", хотя на самом деле это предельно конкретные вещи.
Беру инструмент на вооружение и вам рекомендую. У меня ппц сколько систем создано, которые неплохо бы таким образом задокументировать. 🤓
Правда, напоминает нотный стан?
Обнаружил ещё одну замечательную точку приложения усилий лигалинженера (и не только) — создание и обслуживание схем на языке моделирования бизнес-процессов BPMN при автоматизации чего-либо. Это такие схемы, где в большей мере человекочитаемым языком можно показать логику взаимодействий нескольких слоёв многоуровневой системы. Система может состоять из человеков, софта и чего угодно. Расписать можно как абстрактно, так и конкретно, отмечая каждое действие, особенно в точках взаимодействий слоёв.
На подобной схеме ниже изобразил, что происходит, когда я, используя телеграм-бота, отправляю информацию на бэкенд своего веб-сервера, чтобы сохранить её в базе данных. Использовал этот онлайн-сервис. Есть и куча других.
Такие схемы помогают удобно передавать знания об устройстве и работе системы, а также видеть, сколько раз в общий поток вклинивается тот или иной слой. Например, чётко видно, что человек (я) на своём слое лишь пишет и отправляет сообщение, а затем (не успев даже моргнуть) увидит уже отчёт о результате. Пока человек ждёт, "под капотом" произойдёт куча того, что иногда называют "магией", хотя на самом деле это предельно конкретные вещи.
Беру инструмент на вооружение и вам рекомендую. У меня ппц сколько систем создано, которые неплохо бы таким образом задокументировать. 🤓
Правда, напоминает нотный стан?
🚔 Лигалтек и Государство
Завтра начинается третий месяц, как я работаю в Минцифре. За это время успел сделать для себя массу выводов. Один из них: работа над инновациями, их внедрением и распространением — это кропотливый ежедневный труд, от которого нельзя ожидать сиюминутного выхлопа. Этим диджитальным культурам, которые сеем сегодня, нужно время, чтобы укорениться и взойти.
В первые годы своих лигалинженерских исканий я думал, что все наши проблемы должен решить код. Но вот некоторый код уже появился и продолжает появляться в рамках развития государственных сервисов. И теперь пришло время работы с людьми. Поведение людей сложнее, чем поведение кода. С ними приходится спорить, убеждать, уметь смотреть на мир с их стороны. Цифровые технологии, государственные API, открытые данные сами себя не внедрят. Внедрение идёт через принятие и желание, взаимодействие и соглашения.
И понял я, что нам в государственном лигалтеке сейчас нужен в первую очередь не ИИ, а нужно:
▪️ чтобы государственный реестр не ложился от нескольких десятков прилетевших одновременно запросов, а был безотказен, как сапёрная лопатка;
▪️ чтобы человек не унижался 5-10-15 рабочих дней в попытках получить справку о том, что он не лось, а получил её в 2 клика;
▪️ и так далее.
Проще говоря, нам нужна сначала безотказность if-else, над которым мы, бывает, посмеиваемся. А ИИ в праве... ИИ подождёт. Надо сначала показать и доказать людям правильное лицо технологий: скорость, глобальность, удобство, простоту. А не объяснять, что нейросеть переобучилась или застряла в локальном минимуме и поэтому отказала в пенсии 100-летнему человеку.
Завтра начинается третий месяц, как я работаю в Минцифре. За это время успел сделать для себя массу выводов. Один из них: работа над инновациями, их внедрением и распространением — это кропотливый ежедневный труд, от которого нельзя ожидать сиюминутного выхлопа. Этим диджитальным культурам, которые сеем сегодня, нужно время, чтобы укорениться и взойти.
В первые годы своих лигалинженерских исканий я думал, что все наши проблемы должен решить код. Но вот некоторый код уже появился и продолжает появляться в рамках развития государственных сервисов. И теперь пришло время работы с людьми. Поведение людей сложнее, чем поведение кода. С ними приходится спорить, убеждать, уметь смотреть на мир с их стороны. Цифровые технологии, государственные API, открытые данные сами себя не внедрят. Внедрение идёт через принятие и желание, взаимодействие и соглашения.
И понял я, что нам в государственном лигалтеке сейчас нужен в первую очередь не ИИ, а нужно:
▪️ чтобы государственный реестр не ложился от нескольких десятков прилетевших одновременно запросов, а был безотказен, как сапёрная лопатка;
▪️ чтобы человек не унижался 5-10-15 рабочих дней в попытках получить справку о том, что он не лось, а получил её в 2 клика;
▪️ и так далее.
Проще говоря, нам нужна сначала безотказность if-else, над которым мы, бывает, посмеиваемся. А ИИ в праве... ИИ подождёт. Надо сначала показать и доказать людям правильное лицо технологий: скорость, глобальность, удобство, простоту. А не объяснять, что нейросеть переобучилась или застряла в локальном минимуме и поэтому отказала в пенсии 100-летнему человеку.
♨️ Зачем ходить на хакатоны
(даже если это юридические хакатоны)
(даже если они проходят онлайн)
Я четыре раза участвовал в legaltech-хакатонах.
Киев, Берлин, Харьков, Львов.
Ни разу не пожалел.
Ты оказываешься в команде обычно с незнакомыми людьми. За ограниченное время вам нужно сделать нечто, что должно решить проблему многих людей. Ты берёшь на себя определённую роль и выжимаешь из себя максимум. Получаешь возможность почувствовать себя Сооснователем. Иногда за это какой-то крутой дядя или тётя (инвестор, инкубатор или организатор хакатона) может дать вам денег.
🐟 Скоро будет хакатон с акцентом на работу юрклиник, которые у нас становятся нередко домом последней надежды для слабых мира сего, где проактивный студент может присоединить селёдочный вкус профессии к получаемому ежедневно лекционному мармеладу. Короче, проблемы очень насущные, животрепещущие, настоящие. Прикладному интеллектуалу есть где разогнаться.
Для студентов, которые хотят улучшить профессию, а не присесть на иглу традиционных схем, хакатон обязателен к посещению. Да и в резюме это, на мой взгляд, будет аппетитная строчка. Да и полезные знакомства можно завести. Да и узнать, что такое "Notion".
Ворваться можно через чатбота.
(даже если это юридические хакатоны)
(даже если они проходят онлайн)
Я четыре раза участвовал в legaltech-хакатонах.
Киев, Берлин, Харьков, Львов.
Ни разу не пожалел.
Ты оказываешься в команде обычно с незнакомыми людьми. За ограниченное время вам нужно сделать нечто, что должно решить проблему многих людей. Ты берёшь на себя определённую роль и выжимаешь из себя максимум. Получаешь возможность почувствовать себя Сооснователем. Иногда за это какой-то крутой дядя или тётя (инвестор, инкубатор или организатор хакатона) может дать вам денег.
🐟 Скоро будет хакатон с акцентом на работу юрклиник, которые у нас становятся нередко домом последней надежды для слабых мира сего, где проактивный студент может присоединить селёдочный вкус профессии к получаемому ежедневно лекционному мармеладу. Короче, проблемы очень насущные, животрепещущие, настоящие. Прикладному интеллектуалу есть где разогнаться.
Для студентов, которые хотят улучшить профессию, а не присесть на иглу традиционных схем, хакатон обязателен к посещению. Да и в резюме это, на мой взгляд, будет аппетитная строчка. Да и полезные знакомства можно завести. Да и узнать, что такое "Notion".
Ворваться можно через чатбота.
📓 Логи — кодерская бюрократия или цифровая нефть?
В жизни каждого разработчика и собственника IT-продукта должна быть такая штука, как логи (logs). Логи — это записи, которые накапливаются в процессе работы алгоритмов. Их можно писать в текстовые файлы и даже в базу данных. В логах можно фиксировать:
- что произошло
- когда произошло
- что было причиной, откуда сервис был вызван, с какого IP-адреса и т.д.
- что стало следствием, какой документ был сформирован, куда отправлен и т.д.
- работа алгоритма закончилась нормально или ошибкой.
Короче, суть ваших логов ограничивается вашей фантазией, задачами, потребностью контролировать работу продукта.
🌋 Но самое главное, что логи при их большом количестве становятся не просто дневником вашего продукта и обузой для жёсткого диска. Они — ваша Big Data. Если использовать их правильно, можно получить хороший толчок к пониманию сильных и слабых мест сервиса. Их можно визуализировать. Их можно скормить ML-продуктам, чтобы получить прогнозы на будущее или увидеть аномалии в прошлом.
⚔️ Их можно использовать и в юридических целях. Если, конечно, вы грамотно их ведёте и защищаете от подмены. При их помощи можно проводить расследования, находить виновных, оправдывать невинных.
Например, в CRM-системе, которую разрабатываю для коллег, логи транслируются на отдельную веб-страницу в человекочитаемой форме и раскрашиваются разными цветами. Можно быстро увидеть, кто, когда и какую сущность изменил, насколько важным является такое изменение.
🕸 А если, например, логи запросов чиновников к вашим записям в госреестрах сделать частью экосистемы открытых данных, то вы как раз и сможете в риалтайме узнавать, какой чиновник и когда просматривал ваши данные в госреестре. А о том, как логи могут сделать более прозрачным цифровизированное правосудие, я писал ранее.
В жизни каждого разработчика и собственника IT-продукта должна быть такая штука, как логи (logs). Логи — это записи, которые накапливаются в процессе работы алгоритмов. Их можно писать в текстовые файлы и даже в базу данных. В логах можно фиксировать:
- что произошло
- когда произошло
- что было причиной, откуда сервис был вызван, с какого IP-адреса и т.д.
- что стало следствием, какой документ был сформирован, куда отправлен и т.д.
- работа алгоритма закончилась нормально или ошибкой.
Короче, суть ваших логов ограничивается вашей фантазией, задачами, потребностью контролировать работу продукта.
🌋 Но самое главное, что логи при их большом количестве становятся не просто дневником вашего продукта и обузой для жёсткого диска. Они — ваша Big Data. Если использовать их правильно, можно получить хороший толчок к пониманию сильных и слабых мест сервиса. Их можно визуализировать. Их можно скормить ML-продуктам, чтобы получить прогнозы на будущее или увидеть аномалии в прошлом.
⚔️ Их можно использовать и в юридических целях. Если, конечно, вы грамотно их ведёте и защищаете от подмены. При их помощи можно проводить расследования, находить виновных, оправдывать невинных.
Например, в CRM-системе, которую разрабатываю для коллег, логи транслируются на отдельную веб-страницу в человекочитаемой форме и раскрашиваются разными цветами. Можно быстро увидеть, кто, когда и какую сущность изменил, насколько важным является такое изменение.
🕸 А если, например, логи запросов чиновников к вашим записям в госреестрах сделать частью экосистемы открытых данных, то вы как раз и сможете в риалтайме узнавать, какой чиновник и когда просматривал ваши данные в госреестре. А о том, как логи могут сделать более прозрачным цифровизированное правосудие, я писал ранее.
🪑 Инновации на костылях — быстро или вредно?
И кодинг, и право подвержены применению костылей.
Костыль — жаргонное обозначение такого решения задачи, которое сочетает в себе все или часть таких свойств:
▪️ неполный охват — расчёт на встречу с очевидными, наиболее частыми её проявлениями, игнорирование остальных;
▪️ как следствие, неустойчивость — возможен сбой при встрече с проигнорированными значениями или при использовании в другой временной период;
▪️ условность — например, вместо случайности предлагает "псевдослучайность";
▪️ "из-гвна-и-палок" — не является профессиональным, реализовано при помощи средств или приёмов, которые для этого не предназначены;
▪️ неуклюжесть — задействует неоправданно больше ресурсов, чем требуется (как в плане количества кода, так и в плане вычислительной мощности);
▪️ труднопостижимость — другому человеку (а то и целым поколениям) бывает сложно осмыслить, так было "специально задумано" или же сделано из-за нехватки времени, средств, фантазии.
Например, вам нужно сгенерировать случайную дату в текущем году. Реализовать это, например, в Python можно так:
🚷 Являются ли костыли абсолютным злом? Да нет. Они часто нужны, чтобы сократить время на разработку какой-то фичи и за счёт этого быстрее проверить гипотезу. Но когда окажется, что гипотеза удачна и фичу надо оставлять, код следует переписать так, чтобы избавиться от костылей и прочих "мин замедленного действия". Нужно уметь убеждать свой менеджмент, что хоть и "оно же работает", код нуждается в существенной доработке, чтобы в будущем эти костыли не вылезли боком (как бы это ни звучало).
А что является костылём в праве? Думаю, вы уже встречали их. Костыли встречаются в договорах, правоприменении и даже в законах. Наверняка кто-то считает и сам Хозяйственный кодекс сплошным огромным костылём в частном праве. 😊
И кодинг, и право подвержены применению костылей.
Костыль — жаргонное обозначение такого решения задачи, которое сочетает в себе все или часть таких свойств:
▪️ неполный охват — расчёт на встречу с очевидными, наиболее частыми её проявлениями, игнорирование остальных;
▪️ как следствие, неустойчивость — возможен сбой при встрече с проигнорированными значениями или при использовании в другой временной период;
▪️ условность — например, вместо случайности предлагает "псевдослучайность";
▪️ "из-гвна-и-палок" — не является профессиональным, реализовано при помощи средств или приёмов, которые для этого не предназначены;
▪️ неуклюжесть — задействует неоправданно больше ресурсов, чем требуется (как в плане количества кода, так и в плане вычислительной мощности);
▪️ труднопостижимость — другому человеку (а то и целым поколениям) бывает сложно осмыслить, так было "специально задумано" или же сделано из-за нехватки времени, средств, фантазии.
Например, вам нужно сгенерировать случайную дату в текущем году. Реализовать это, например, в Python можно так:
from datetime import dateА вот как выглядит явно костыльное решение:
from random import randint
date_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 randintТо есть во втором варианте мы не заморачиваемся с учётом количества дней для каждого месяца (не будут появляться даты с 29, 30 и 31 днём) и жёстко привязываемся к 2021-му году. Минусы этого решения очевидны.
random_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_day
print(date_random)
🚷 Являются ли костыли абсолютным злом? Да нет. Они часто нужны, чтобы сократить время на разработку какой-то фичи и за счёт этого быстрее проверить гипотезу. Но когда окажется, что гипотеза удачна и фичу надо оставлять, код следует переписать так, чтобы избавиться от костылей и прочих "мин замедленного действия". Нужно уметь убеждать свой менеджмент, что хоть и "оно же работает", код нуждается в существенной доработке, чтобы в будущем эти костыли не вылезли боком (как бы это ни звучало).
А что является костылём в праве? Думаю, вы уже встречали их. Костыли встречаются в договорах, правоприменении и даже в законах. Наверняка кто-то считает и сам Хозяйственный кодекс сплошным огромным костылём в частном праве. 😊
🔔 Дзінь, є хто живий?
Пробачте, давно сюди не писав. Було багатенько роботи. Вирішив далі вести цей канал українською, бо все ж цей канал народжений і викормлений українською екосистемою. 🇺🇦
Про що поговоримо далі? Та як завжди, про різне: (само)навчання кодингу, роботу з даними, SQL та Excel, аналіз правових текстів та про інші технарсько-правничі суміші. 🙂
Але як і раніше:
1⃣ жодної реклами (типу коли автору каналу платять, а він постить бозна-що);
2⃣ ніякого контенту в дусі "на, відчепись".
Я ціную ваш час. ⏳
Пробачте, давно сюди не писав. Було багатенько роботи. Вирішив далі вести цей канал українською, бо все ж цей канал народжений і викормлений українською екосистемою. 🇺🇦
Про що поговоримо далі? Та як завжди, про різне: (само)навчання кодингу, роботу з даними, SQL та Excel, аналіз правових текстів та про інші технарсько-правничі суміші. 🙂
Але як і раніше:
1⃣ жодної реклами (типу коли автору каналу платять, а він постить бозна-що);
2⃣ ніякого контенту в дусі "на, відчепись".
Я ціную ваш час. ⏳
📁 Як відкрити величезний файл
При роботі з Big Data можете зіткнутися з тим, що потрібні вам дані будуть розміщені у величезному файлі. Наприклад, ось цей набір даних по юридичних особах і ФОПах лежить у двох файлах об'ємом 5 Gb і 9 Gb (після розархівування), які налічують 1 800 000+ і 5 500 000+ рядків відповідно. Файли мають розширення XML. Якщо ви спробуєте відкрити будь-який з них в текстовому редакторі, то... краще цього не робіть 🙂.
Як же ж бути? Тут і можуть стати в нагоді базові навички з кодингу та використання регулярних виразів (про них писав тут раніше). Скориставшись ними, ви можете не завантажувати файл цілком в оперативну пам'ять комп'ютера, а зчитувати його по одному рядку. І над кожним таким рядком можна виконувати потрібні операції: шукати якісь значення, виписувати їх в окремий файл / базу даних тощо. Завдяки цьому прийому я на прохання одного знайомого видобув потрібні дані по всіх юридичних особах, які були зареєстровані за останні кілька місяців.
⚙️ Наприклад, на зображенні показано невеличкий код на PHP, який з величезного файла з юрособами "випише" вам в окремий текстовий файлик всі рядки з даними про юросіб, які були зареєстровані у червні 2021 року.
При роботі з Big Data можете зіткнутися з тим, що потрібні вам дані будуть розміщені у величезному файлі. Наприклад, ось цей набір даних по юридичних особах і ФОПах лежить у двох файлах об'ємом 5 Gb і 9 Gb (після розархівування), які налічують 1 800 000+ і 5 500 000+ рядків відповідно. Файли мають розширення XML. Якщо ви спробуєте відкрити будь-який з них в текстовому редакторі, то... краще цього не робіть 🙂.
Як же ж бути? Тут і можуть стати в нагоді базові навички з кодингу та використання регулярних виразів (про них писав тут раніше). Скориставшись ними, ви можете не завантажувати файл цілком в оперативну пам'ять комп'ютера, а зчитувати його по одному рядку. І над кожним таким рядком можна виконувати потрібні операції: шукати якісь значення, виписувати їх в окремий файл / базу даних тощо. Завдяки цьому прийому я на прохання одного знайомого видобув потрібні дані по всіх юридичних особах, які були зареєстровані за останні кілька місяців.
⚙️ Наприклад, на зображенні показано невеличкий код на PHP, який з величезного файла з юрособами "випише" вам в окремий текстовий файлик всі рядки з даними про юросіб, які були зареєстровані у червні 2021 року.
📁 Як відкрити величезний файл: поради знавців
Колеги по екосистемі дали кілька фідбеків по темі попереднього поста. Поділюся ними.
1️⃣ Не варто парсити XML регулярними виразами. XML — це спеціальна мова розмітки, з якою слід працювати відповідним чином.
2️⃣ Не варто прив'язуватися до переносів рядків. Кажуть, Мін'юст може несподівано "поламати" логіку, виклавши черговий файл "в один рядок". Тому типу краще зчитувати файл "порціями" байтів, видираючи потрібний контент з поточної порції. Дійсно, можна і так.
3️⃣ PHP — непідходяща мова програмування для такого роду задач. Типу краще R чи Python. Що ж, якщо ви знаєте кілька мов, то беріть ту, яка більше пасує вашій поточній задачі. А на PHP парсинг я запускав локально, щоб підготувати дані до подальшого використання в інших умовах, тому мені це було цілком норм. 😊
4️⃣ Краще використовувати підхід MapReduce, коли весь масив даних ділиться на кілька фрагментів (чи навіть кілька десятків) і аналіз кожного фрагмента запускається на окремому ядрі процесора чи окремому комп'ютері (сервері). Це дозволить пришвидшити отримання кінцевого результату. Але для цього доведеться писати значно більше коду, щоб весь масив даних розділити, делегувати задачі окремим підпрограмам, а потім зібрати докупи результати їх роботи. Тому це варто робити, коли вам доводиться виконувати цю процедуру часто і коли важливо швидко отримувати результати. А я ж запускав свій алгоритм раз на два тижні і нікуди не поспішав.
Загалом, цей кейс — гарний приклад того, що в інформатиці одну й ту ж задачу можна виконати по-різному:
🐗 "дешево і сердито" — будь-якою мовою програмування написати примітивний код, який тупо "в лоб" видасть потрібний результат (але буде ризик, що наступного разу щось піде не так)
🐙 фундаментально — підібрати оптимальну мову програмування, врахувати формат даних наявного джерела (XML, JSON, CSV тощо), написати алгоритм для розподілених обчислень, запустити його на потрібній інфраструктурі тощо
Колеги по екосистемі дали кілька фідбеків по темі попереднього поста. Поділюся ними.
1️⃣ Не варто парсити XML регулярними виразами. XML — це спеціальна мова розмітки, з якою слід працювати відповідним чином.
2️⃣ Не варто прив'язуватися до переносів рядків. Кажуть, Мін'юст може несподівано "поламати" логіку, виклавши черговий файл "в один рядок". Тому типу краще зчитувати файл "порціями" байтів, видираючи потрібний контент з поточної порції. Дійсно, можна і так.
3️⃣ PHP — непідходяща мова програмування для такого роду задач. Типу краще R чи Python. Що ж, якщо ви знаєте кілька мов, то беріть ту, яка більше пасує вашій поточній задачі. А на PHP парсинг я запускав локально, щоб підготувати дані до подальшого використання в інших умовах, тому мені це було цілком норм. 😊
4️⃣ Краще використовувати підхід MapReduce, коли весь масив даних ділиться на кілька фрагментів (чи навіть кілька десятків) і аналіз кожного фрагмента запускається на окремому ядрі процесора чи окремому комп'ютері (сервері). Це дозволить пришвидшити отримання кінцевого результату. Але для цього доведеться писати значно більше коду, щоб весь масив даних розділити, делегувати задачі окремим підпрограмам, а потім зібрати докупи результати їх роботи. Тому це варто робити, коли вам доводиться виконувати цю процедуру часто і коли важливо швидко отримувати результати. А я ж запускав свій алгоритм раз на два тижні і нікуди не поспішав.
Загалом, цей кейс — гарний приклад того, що в інформатиці одну й ту ж задачу можна виконати по-різному:
🐗 "дешево і сердито" — будь-якою мовою програмування написати примітивний код, який тупо "в лоб" видасть потрібний результат (але буде ризик, що наступного разу щось піде не так)
🐙 фундаментально — підібрати оптимальну мову програмування, врахувати формат даних наявного джерела (XML, JSON, CSV тощо), написати алгоритм для розподілених обчислень, запустити його на потрібній інфраструктурі тощо
🗿 Технології — НЕ ГОЛОВНЕ
Так, технології — не головне. Технології — не найважливіше. Мабуть, вам дивно це чути від мене 🙂
Навіщо вони потрібні? Щоб зробити життя зручнішим. Безпечнішим. Щоб автоматизувати нецікаве. Щоб пришвидшити повільне. Щоб менше кортизолу і більше серотоніну.
🏛 Наприклад, у державній сфері — для того, щоб:
- зменшити можливості корупції;
- позбавитись інших негативних проявів "людського фактору", помилок внаслідок неуважності, байдужості чи надмірної завантаженості службовця тощо;
- колосально пришвидшити надання державних послуг;
- спростити взаємодію людини і держави, звести її до натискання зручних кнопочок на сайтах і в застосунках.
Але технологія — це завжди палиця з двома кінцями.
ЯКЩО перевести будь-яку державну послугу на цифрові рейки:
🔌 не подбавши про її якісну технічну реалізацію, відмовостійкість і достатність відповідної інфраструктури;
та/або
🎲 не врахувавши можливість появи специфічних вхідних параметрів (які за законом не виключають права на отримання послуги, але не потрапили в технічне завдання);
та/або
🐗 невдало підібравши виконавців, які виставляють рахунки вправніше, ніж пишуть потрібний код;
та/або
🔩забивши відмовившись від якісного тестування з будь-яких причин (для IT-сервісів це дуже критичний етап становлення, на якому, однак, часом економлять кошти чи час);
та/або
🎧 не забезпечивши якісну техпідтримку користувачів;
ТО ця технопалиця дивитиметься гострим кінцем в бік людини, яка намагається отримати цю послугу. А якщо ще прибрати нецифровий формат надання послуги, залишивши лише сиренький цифровий, то привіт, левіафане нашого часу.
Що ж важливе?
💫 Важливі процеси, які вибудовуються навколо цифровізованого явища (державної послуги, тощо). Важливі люди, які відповідають за ці процеси. Сам факт цифровізації (створення софту) чогось не робить світ сповненим райдуг і рожевих поні. Цифрове рішення, мов дитина, потребує догляду, підтримки, вдосконалення. І користувач цифрового рішення потребує догляду, підтримки, зокрема не лише засобами цього цифрового рішення.
Іншими словами, навіщо вам плавати на підводному човні, якщо десь нагорі не буде людей, які вас витягнуть, коли він дасть дуба? Або якщо такі люди будуть, але він не протестований, як слід?
💎 Цифровізація здатна створити колосальну цінність, якщо вона є проявом (інструментом, наслідком), а не замінником розумного процесу, яким розумно керують як до, так і після оцифрування чогось.
👼 Отже, важливо готувати не лише технічних спеців, а й спеців, які вміють піклуватися про людяність цифрових рішень, мислять стратегічно з позицій їхнього комфорту, безпеки, доступності для людини. Головне, щоб у таких людей було:
▫️ достатньо влади для ефективного застосування своїх знань;
▫️ достатньо сил для спротиву "грі на кількість і швидкість", яка зашкоджує якості, глибині, доступності та/або безпеці.
Так, технології — не головне. Технології — не найважливіше. Мабуть, вам дивно це чути від мене 🙂
Навіщо вони потрібні? Щоб зробити життя зручнішим. Безпечнішим. Щоб автоматизувати нецікаве. Щоб пришвидшити повільне. Щоб менше кортизолу і більше серотоніну.
🏛 Наприклад, у державній сфері — для того, щоб:
- зменшити можливості корупції;
- позбавитись інших негативних проявів "людського фактору", помилок внаслідок неуважності, байдужості чи надмірної завантаженості службовця тощо;
- колосально пришвидшити надання державних послуг;
- спростити взаємодію людини і держави, звести її до натискання зручних кнопочок на сайтах і в застосунках.
Але технологія — це завжди палиця з двома кінцями.
ЯКЩО перевести будь-яку державну послугу на цифрові рейки:
🔌 не подбавши про її якісну технічну реалізацію, відмовостійкість і достатність відповідної інфраструктури;
та/або
🎲 не врахувавши можливість появи специфічних вхідних параметрів (які за законом не виключають права на отримання послуги, але не потрапили в технічне завдання);
та/або
🐗 невдало підібравши виконавців, які виставляють рахунки вправніше, ніж пишуть потрібний код;
та/або
🔩
та/або
🎧 не забезпечивши якісну техпідтримку користувачів;
ТО ця технопалиця дивитиметься гострим кінцем в бік людини, яка намагається отримати цю послугу. А якщо ще прибрати нецифровий формат надання послуги, залишивши лише сиренький цифровий, то привіт, левіафане нашого часу.
Що ж важливе?
💫 Важливі процеси, які вибудовуються навколо цифровізованого явища (державної послуги, тощо). Важливі люди, які відповідають за ці процеси. Сам факт цифровізації (створення софту) чогось не робить світ сповненим райдуг і рожевих поні. Цифрове рішення, мов дитина, потребує догляду, підтримки, вдосконалення. І користувач цифрового рішення потребує догляду, підтримки, зокрема не лише засобами цього цифрового рішення.
Іншими словами, навіщо вам плавати на підводному човні, якщо десь нагорі не буде людей, які вас витягнуть, коли він дасть дуба? Або якщо такі люди будуть, але він не протестований, як слід?
💎 Цифровізація здатна створити колосальну цінність, якщо вона є проявом (інструментом, наслідком), а не замінником розумного процесу, яким розумно керують як до, так і після оцифрування чогось.
👼 Отже, важливо готувати не лише технічних спеців, а й спеців, які вміють піклуватися про людяність цифрових рішень, мислять стратегічно з позицій їхнього комфорту, безпеки, доступності для людини. Головне, щоб у таких людей було:
▫️ достатньо влади для ефективного застосування своїх знань;
▫️ достатньо сил для спротиву "грі на кількість і швидкість", яка зашкоджує якості, глибині, доступності та/або безпеці.
🏔 КОДИНГ — нелегкий шлях для гуманітарія
💪 З одного боку, програмування захоплює, викликає азарт, підкорює збудженням відчуття могутності (типу ти змушуєш комп'ютери виконувати твої накази, можеш створювати власні цілі світи, особливо в геймдеві, тощо). Ну а для когось основним мотивом є гроші.
🤯 А з іншого боку, воно потребує великої віддачі, уваги, пунктуальності, логічності, перебудови мислення, розуміння абстракцій, вміння слідувати стандартам, слідкувати за оновленнями обраних технологій, постійно переосмислювати свій досвід, вміння оцінювати час на виконання задач, тощо.
Якщо ви вирішуєте опановувати програмування шляхом написання безпосередньо програмного коду, то ви маєте розуміти:
- для чого це робите (хочете робити кар'єру в IT, це просто допоміжний фактор в іншій основній роботі або це просто ваше хобі);
- на що ви готові заради цього (платні курси, (само)навчання по ночах, комплекс самозванця, рестарт кар'єри, тощо).
ЯКЩО створювати програми (автоматизацію у власному бізнесі) хочеться, але не можеться,
І ЯКЩО є сумніви, що
варто витрачати час на опанування кодингу
АБО кошти на оплату послуг програміста,
ТО ви можете скористатися так званими No-Code чи Low-Code рішеннями, якими насичується ринок. 😺
Це сервіси (інтерфейси), які дозволяють створювати софт (в тому чи іншому розумінні) для задоволення нагальних бізнес-потреб без навичок (або майже без навичок) програмування, без написання (або майже без написання) програмного коду з усіма цими круглими чи фігурними дужками, комами, крапками. 🙃
І якраз про такі сервіси завтра (02.09.2021) о 19:00 буде офлайн-івент від Микити Підгайного. Я вирішив на нього сходити, щоб розширити професійний кругозір. Квитки мають бути в цього чатбота. Може, хтось чекав на знак долі, і ти тепер знаєш, що це він :)
💪 З одного боку, програмування захоплює, викликає азарт, підкорює збудженням відчуття могутності (типу ти змушуєш комп'ютери виконувати твої накази, можеш створювати власні цілі світи, особливо в геймдеві, тощо). Ну а для когось основним мотивом є гроші.
🤯 А з іншого боку, воно потребує великої віддачі, уваги, пунктуальності, логічності, перебудови мислення, розуміння абстракцій, вміння слідувати стандартам, слідкувати за оновленнями обраних технологій, постійно переосмислювати свій досвід, вміння оцінювати час на виконання задач, тощо.
Якщо ви вирішуєте опановувати програмування шляхом написання безпосередньо програмного коду, то ви маєте розуміти:
- для чого це робите (хочете робити кар'єру в IT, це просто допоміжний фактор в іншій основній роботі або це просто ваше хобі);
- на що ви готові заради цього (платні курси, (само)навчання по ночах, комплекс самозванця, рестарт кар'єри, тощо).
ЯКЩО створювати програми (автоматизацію у власному бізнесі) хочеться, але не можеться,
І ЯКЩО є сумніви, що
варто витрачати час на опанування кодингу
АБО кошти на оплату послуг програміста,
ТО ви можете скористатися так званими No-Code чи Low-Code рішеннями, якими насичується ринок. 😺
Це сервіси (інтерфейси), які дозволяють створювати софт (в тому чи іншому розумінні) для задоволення нагальних бізнес-потреб без навичок (або майже без навичок) програмування, без написання (або майже без написання) програмного коду з усіма цими круглими чи фігурними дужками, комами, крапками. 🙃
І якраз про такі сервіси завтра (02.09.2021) о 19:00 буде офлайн-івент від Микити Підгайного. Я вирішив на нього сходити, щоб розширити професійний кругозір. Квитки мають бути в цього чатбота. Може, хтось чекав на знак долі, і ти тепер знаєш, що це він :)
🎠 ТЕСТУЙ, інакше буде ...
Неймовірно важлива стадія створення програмних продуктів — їхнє тестування.
Тестування насамперед має на меті:
- перевірити, чи програма працює так, як це було задумано, чи виконує всі поставлені задачі;
- перевірити, як програма поводить себе при її нетиповому (неадекватному, екстремальному) використанні;
- виявити помилки, вразливі місця, ділянки неоптимального використання ресурсів, тощо.
Якщо тестувати погано, то і продукт вийде не дуже. І справа не в тому, що програмісти погані. Навіть досвідчені програмісти можуть часто писати код, який матиме вразливості, не покриватиме всі можливі варіації вхідних даних, комбінації параметрів тощо. Людському мозку нечасто вдається ідеально виконати задачу на всіх рівнях. Тому й існує система різних "тестерських" професій в IT, і взагалі тестування ПЗ має цілу теорію і понятійний апарат.
Тому якщо ваша команда розробників складається з вас одного/-єї, то і тестувати доведеться переважно самостійно. Звісно, можна (і бажано) дати протестувати ваш прототип друзям/колегам, але до цього вам слід самостійно дещо зробити. Наприклад, якщо ваша програма (чатбот, вебсайт) приймає від користувача деякі параметри (текст, цифри), які далі має обробити, то зробіть ось що:
▪️ перевірте, як програма реагує, коли їй пробують надіслати пустий рядок або рядок лише з пробілів
▪️ якщо програма очікує цифри, то що буде, коли надійдуть літери, спецсимволи? а якщо надійде не позитивне, а від'ємне число?
▪️ якщо програма очікує якийсь варіант відповіді з конкретного набору ("так", "ні"), то що буде, коли надійде щось інше (наприклад, "не знаю")?
▪️ якщо програма очікує дату у форматі ДД.ММ.ГГГГ, то що буде, коли дата надійде в будь-якому іншому форматі? і чи програма перевірятиме, щоб дата загалом була коректна (наприклад, щоб на позиції ММ не було числа більше 12, а в лютому була коректна кількість днів)?
▪️ коли програма має отримувати дату в майбутньому часі (наприклад, день, коли вас клієнт просить пропушити), то програма перевірятиме, чи не введено минулу дату?
Чим більше ви сформулюєте таких питань і пропрацюєте їх, тим кращою буде ваша програма, краще йтимуть пов'язані з нею бізнес-процеси, буде більш убезпечена ваша репутація і нерви, тощо.
"По хорошому", тестування слід здійснювати після кожної зміни вашого коду. Практика показує, що "ефект метелика" в коді дуже часто спрацьовує, тому між програмістом і продакшеном має стояти тестер. 🙂 Ну й краще дізнаватися про баги самостійно, а не від клієнтів... 😌
Неймовірно важлива стадія створення програмних продуктів — їхнє тестування.
Тестування насамперед має на меті:
- перевірити, чи програма працює так, як це було задумано, чи виконує всі поставлені задачі;
- перевірити, як програма поводить себе при її нетиповому (неадекватному, екстремальному) використанні;
- виявити помилки, вразливі місця, ділянки неоптимального використання ресурсів, тощо.
Якщо тестувати погано, то і продукт вийде не дуже. І справа не в тому, що програмісти погані. Навіть досвідчені програмісти можуть часто писати код, який матиме вразливості, не покриватиме всі можливі варіації вхідних даних, комбінації параметрів тощо. Людському мозку нечасто вдається ідеально виконати задачу на всіх рівнях. Тому й існує система різних "тестерських" професій в IT, і взагалі тестування ПЗ має цілу теорію і понятійний апарат.
Тому якщо ваша команда розробників складається з вас одного/-єї, то і тестувати доведеться переважно самостійно. Звісно, можна (і бажано) дати протестувати ваш прототип друзям/колегам, але до цього вам слід самостійно дещо зробити. Наприклад, якщо ваша програма (чатбот, вебсайт) приймає від користувача деякі параметри (текст, цифри), які далі має обробити, то зробіть ось що:
▪️ перевірте, як програма реагує, коли їй пробують надіслати пустий рядок або рядок лише з пробілів
▪️ якщо програма очікує цифри, то що буде, коли надійдуть літери, спецсимволи? а якщо надійде не позитивне, а від'ємне число?
▪️ якщо програма очікує якийсь варіант відповіді з конкретного набору ("так", "ні"), то що буде, коли надійде щось інше (наприклад, "не знаю")?
▪️ якщо програма очікує дату у форматі ДД.ММ.ГГГГ, то що буде, коли дата надійде в будь-якому іншому форматі? і чи програма перевірятиме, щоб дата загалом була коректна (наприклад, щоб на позиції ММ не було числа більше 12, а в лютому була коректна кількість днів)?
▪️ коли програма має отримувати дату в майбутньому часі (наприклад, день, коли вас клієнт просить пропушити), то програма перевірятиме, чи не введено минулу дату?
Чим більше ви сформулюєте таких питань і пропрацюєте їх, тим кращою буде ваша програма, краще йтимуть пов'язані з нею бізнес-процеси, буде більш убезпечена ваша репутація і нерви, тощо.
"По хорошому", тестування слід здійснювати після кожної зміни вашого коду. Практика показує, що "ефект метелика" в коді дуже часто спрацьовує, тому між програмістом і продакшеном має стояти тестер. 🙂 Ну й краще дізнаватися про баги самостійно, а не від клієнтів... 😌
🏃♂️ ПРОГРАМУВАННЯ І ПОСПІХ
Розробнику нині часто доводиться писати код нашвидкуруч і пошвидше запускати його в роботу (продакшн). У цієї поспішності можуть бути різні причини.
Наприклад, швидкість від розробника може вимагати бізнес, щоб IT-продукт (чи окремі фічі) виводився на ринок швидше, щоб обігнати конкурентів, закріпитися у ніші (важливо для стартапів), збільшити прибутки, тощо. В окремих галузях це дозволяє в лічені дні отримувати мільйонні доходи, наприклад у геймдеві, коли з’являється черговий хайповий жанр мобільної гри, який геймдев-студії починають масово копіювати, намагаючись урвати кусень побільше. Тобто працює ця банальщина:
час = гроші,
швидко програмуєш = швидко заробляєш.
Інколи причиною поспіху може бути бажання розробника швидше здати проєкт, щоб взятися за новий (більш цікавий або перспективний) чи щоб отримати премію за швидкість, гарну оцінку на perfomance review з подальшим підвищенням, гарну оцінку від замовника на фріланс-біржі, тощо.
А ще розробка може вестися під егідою діючої політичної влади, і якщо це продукт, що здатен впливати на її рейтинг, то поспіх може стати логічним наслідком бажання випустити якомога більше вражаючого і корисного функціоналу до наступних виборів.
Але незалежно від зовнішніх і внутрішніх причин, поспіх у програмуванні має одні й ті ж своєрідні наслідки. Розділю їх на умовні блоки:
💎 ЯКІСТЬ ПРОДУКТУ ДЛЯ КОРИСТУВАЧА
🏯 АРХІТЕКТУРА (якість продукту з точки зору розробника)
🔐 [КІБЕР] БЕЗПЕКА
І почну з того, значимість чого перестають недооцінювати зазвичай вже тоді, коли грянув грім. Вже завтра 😊
Розробнику нині часто доводиться писати код нашвидкуруч і пошвидше запускати його в роботу (продакшн). У цієї поспішності можуть бути різні причини.
Наприклад, швидкість від розробника може вимагати бізнес, щоб IT-продукт (чи окремі фічі) виводився на ринок швидше, щоб обігнати конкурентів, закріпитися у ніші (важливо для стартапів), збільшити прибутки, тощо. В окремих галузях це дозволяє в лічені дні отримувати мільйонні доходи, наприклад у геймдеві, коли з’являється черговий хайповий жанр мобільної гри, який геймдев-студії починають масово копіювати, намагаючись урвати кусень побільше. Тобто працює ця банальщина:
час = гроші,
швидко програмуєш = швидко заробляєш.
Інколи причиною поспіху може бути бажання розробника швидше здати проєкт, щоб взятися за новий (більш цікавий або перспективний) чи щоб отримати премію за швидкість, гарну оцінку на perfomance review з подальшим підвищенням, гарну оцінку від замовника на фріланс-біржі, тощо.
А ще розробка може вестися під егідою діючої політичної влади, і якщо це продукт, що здатен впливати на її рейтинг, то поспіх може стати логічним наслідком бажання випустити якомога більше вражаючого і корисного функціоналу до наступних виборів.
Але незалежно від зовнішніх і внутрішніх причин, поспіх у програмуванні має одні й ті ж своєрідні наслідки. Розділю їх на умовні блоки:
💎 ЯКІСТЬ ПРОДУКТУ ДЛЯ КОРИСТУВАЧА
🏯 АРХІТЕКТУРА (якість продукту з точки зору розробника)
🔐 [КІБЕР] БЕЗПЕКА
І почну з того, значимість чого перестають недооцінювати зазвичай вже тоді, коли грянув грім. Вже завтра 😊
🏃♂️ ПОСПІХ І ПРОГРАМУВАННЯ: [КІБЕР]БЕЗПЕКА 🔐
Виділю два аспекти поспіху: гівняний і залежнісний.
1️⃣ Говнокод і говнопрактики
Якщо ви швидко пишете код, поверхово його перевіряєте і на це накладається низька культура тестування у вашій команді, ви можете сформувати якусь вразливість вашої системи. Ось деякі приклади:
▪️ сторінка сайту, яка призначена лише для адміністраторів, але буде відкриватися і у звичайних користувачів чи взагалі у неавторизованих відвідувачів;
▪️ ділянка API, що видає конфіденційні дані, не вимагаючи валідного токену (ключа, паролю, сесії);
▪️ код, який пропускає SQL-ін’єкції у вашу базу даних чи допускає несанкціоновані сценарії взаємодії (що дозволяє або вщент знищити вашу базу даних, або викачати її, або інколи навіть авторизуватися на сайті як адміністратор чи інший користувач);
▪️ ділянка коду чи криво налаштований сервер, що за деякої комбінації вхідних даних поводить себе неадекватно, видає зайву інформацію про вашу систему, даючи важливі підказки для продовження атаки;
▪️ код, що пропускає XSS-атаки на якусь зі сторінок вашого сайту;
▪️ ви не заморочилися з валідацією даних, які надходять ззовні, і хтось зміг розташувати і виконати свій код у вашій системі;
▪️ ви не заморочилися з шифруванням і почали зберігати паролі чи чутливі персональні дані користувачів у незашифрованому вигляді (а потім стажер, якому ви дали доступ до бази даних, її скачує і продає в даркнеті);
▪️ ви "для зручності" помістили якісь логіни/паролі/ключі чи цілі інструкції по використанню в коментарях до коду, потім забули видалити, немов ті анекдотичні лікарі з ножицями (далі цей код може різними шляхами потрапити у відкритий репозиторій в мережу, той проіндексується гуглом, і понєслась).
2️⃣ Залежності
Для пришвидшення розробки є різні інструменти. Зокрема, це різні бібліотеки, фреймворки, CMS-системи, CRM-системи, які дозволяють використовувати чужий стандартизований код, щоб не створювати "свої велосипеди". В IT-галузі культивується мода на використання готових рішень. І це можна зрозуміти, бо, мовляв, навіщо вчергове кодити свій механізм авторизації користувача на сайті і купу інших банальних речей, коли можна скористатися готовим надійним механізмом у популярному фреймворці. Чи навіщо писати з нуля свою нейромережу, коли можна скористатися популярною математичною бібліотекою, яка зніме з вас купу нецікавого рутинного головняку.
Використовуючи готові рішення, можна за лічені години підняти сайт, наповнити його контентом, видати під ключ замовнику і отримати завітний гонорар. І вдаючись до рекомендованих офіційною документацією прийомів по написанню коду в рамках цих рішень, ви з вищими шансами напишете хороший і надійний код.
Однак у чужих готових IT-рішеннях (далі — софт) іноді виявляються різні вразливості, і автори софту такі вразливості протягом якогось часу прибирають, викладаючи його оновлену версію. Але щоб ця вразливість зникла у вашому сайті, побудованому на цьому софті, вам необхідно оновитися до цієї останньої версії (або ж випилювати її вручну, але це шлях "на любителя"). І от тут у вас може виникнути проблема, якщо ви давно не оновлювалися.
Ви можете з’ясувати, що нова версія софту вимагатиме від вас переписування деяких ділянок вашої системи, інакше вони поламаються. Ви як програміст розумієте, що від вашої команди така адаптація вимагатиме, скажімо, 2 тижні. Однак у вашого керівника (чи замовника), якщо він не фанат кібербезпеки, ці 2 тижні будуть асоціюватися з 2 тижнями простою, бо ви фактично не створите нічого нового, не викотите нову фічу (функцію), не створите інфоприводів для аудиторії тощо.
І ось тут починається драма: керівник вам скаже "давай пізніше до цього повернемося, зараз у нас є важливіші задачі". І ви кодите далі нові фічі, а ваша система продовжує жити з вразливою "діркою". Кодова база збільшується, вже розроблені фічі вимагають якоїсь підтримки і розвитку, а на підході нові й нові фічі, і у цьому пекельному вихорі роботи ви вже й забуваєте про ту свою дірку, в яку одного дня може проникнути "миша"…
Висновки нижче.
Виділю два аспекти поспіху: гівняний і залежнісний.
1️⃣ Говнокод і говнопрактики
Якщо ви швидко пишете код, поверхово його перевіряєте і на це накладається низька культура тестування у вашій команді, ви можете сформувати якусь вразливість вашої системи. Ось деякі приклади:
▪️ сторінка сайту, яка призначена лише для адміністраторів, але буде відкриватися і у звичайних користувачів чи взагалі у неавторизованих відвідувачів;
▪️ ділянка API, що видає конфіденційні дані, не вимагаючи валідного токену (ключа, паролю, сесії);
▪️ код, який пропускає SQL-ін’єкції у вашу базу даних чи допускає несанкціоновані сценарії взаємодії (що дозволяє або вщент знищити вашу базу даних, або викачати її, або інколи навіть авторизуватися на сайті як адміністратор чи інший користувач);
▪️ ділянка коду чи криво налаштований сервер, що за деякої комбінації вхідних даних поводить себе неадекватно, видає зайву інформацію про вашу систему, даючи важливі підказки для продовження атаки;
▪️ код, що пропускає XSS-атаки на якусь зі сторінок вашого сайту;
▪️ ви не заморочилися з валідацією даних, які надходять ззовні, і хтось зміг розташувати і виконати свій код у вашій системі;
▪️ ви не заморочилися з шифруванням і почали зберігати паролі чи чутливі персональні дані користувачів у незашифрованому вигляді (а потім стажер, якому ви дали доступ до бази даних, її скачує і продає в даркнеті);
▪️ ви "для зручності" помістили якісь логіни/паролі/ключі чи цілі інструкції по використанню в коментарях до коду, потім забули видалити, немов ті анекдотичні лікарі з ножицями (далі цей код може різними шляхами потрапити у відкритий репозиторій в мережу, той проіндексується гуглом, і понєслась).
2️⃣ Залежності
Для пришвидшення розробки є різні інструменти. Зокрема, це різні бібліотеки, фреймворки, CMS-системи, CRM-системи, які дозволяють використовувати чужий стандартизований код, щоб не створювати "свої велосипеди". В IT-галузі культивується мода на використання готових рішень. І це можна зрозуміти, бо, мовляв, навіщо вчергове кодити свій механізм авторизації користувача на сайті і купу інших банальних речей, коли можна скористатися готовим надійним механізмом у популярному фреймворці. Чи навіщо писати з нуля свою нейромережу, коли можна скористатися популярною математичною бібліотекою, яка зніме з вас купу нецікавого рутинного головняку.
Використовуючи готові рішення, можна за лічені години підняти сайт, наповнити його контентом, видати під ключ замовнику і отримати завітний гонорар. І вдаючись до рекомендованих офіційною документацією прийомів по написанню коду в рамках цих рішень, ви з вищими шансами напишете хороший і надійний код.
Однак у чужих готових IT-рішеннях (далі — софт) іноді виявляються різні вразливості, і автори софту такі вразливості протягом якогось часу прибирають, викладаючи його оновлену версію. Але щоб ця вразливість зникла у вашому сайті, побудованому на цьому софті, вам необхідно оновитися до цієї останньої версії (або ж випилювати її вручну, але це шлях "на любителя"). І от тут у вас може виникнути проблема, якщо ви давно не оновлювалися.
Ви можете з’ясувати, що нова версія софту вимагатиме від вас переписування деяких ділянок вашої системи, інакше вони поламаються. Ви як програміст розумієте, що від вашої команди така адаптація вимагатиме, скажімо, 2 тижні. Однак у вашого керівника (чи замовника), якщо він не фанат кібербезпеки, ці 2 тижні будуть асоціюватися з 2 тижнями простою, бо ви фактично не створите нічого нового, не викотите нову фічу (функцію), не створите інфоприводів для аудиторії тощо.
І ось тут починається драма: керівник вам скаже "давай пізніше до цього повернемося, зараз у нас є важливіші задачі". І ви кодите далі нові фічі, а ваша система продовжує жити з вразливою "діркою". Кодова база збільшується, вже розроблені фічі вимагають якоїсь підтримки і розвитку, а на підході нові й нові фічі, і у цьому пекельному вихорі роботи ви вже й забуваєте про ту свою дірку, в яку одного дня може проникнути "миша"…
Висновки нижче.
Legal Code
🏃♂️ ПОСПІХ І ПРОГРАМУВАННЯ: [КІБЕР]БЕЗПЕКА 🔐 Виділю два аспекти поспіху: гівняний і залежнісний. 1️⃣ Говнокод і говнопрактики Якщо ви швидко пишете код, поверхово його перевіряєте і на це накладається низька культура тестування у вашій команді, ви можете…
⬆️ Висновки
🔸 Ви можете писати код швидко, є така практика і філософія. Але виділяйте час на його перевірку, ретельно тестуйте. А краще давайте тестувати ваш код/продукт тим, хто це вміє робити. Бажано, щоб професійні тестери були у штаті вашої команди (зрозуміло, що не завжди є ресурс на таку розкіш).
🔸 Ваш керівник/клієнт може не розбиратися в кібербезпеці, але хтось у команді повинен розбиратися, мати доступ до ревізії коду (peer review) і мати вплив на процес розробки. Автор коду дуже часто може не помітити вразливе місце. Добре би мати в команді повноцінного кіберспеціаліста чи хоча б періодично показувати йому свій код.
🔸 Якщо ви використовуєте деякий фреймворк, CMS-систему, CRM-систему тощо, намагайтесь слідкувати за новинами про ці продукти, щоб якомога раніше дізнатися про вразливості, коли про них почнуть писати публічно.
🔸 Якщо ви знайшли вразливості у вашому коді чи у використаних залежностях, то займайтеся вразливостями, а не відкладайте на потім. Внаслідок зламу вашої системи втрати можуть бути значно страшнішими, ніж неотримані премії за зірвані дедлайни. Доводьте до відома керівників/клієнтів суть загроз, намагайтесь "вибити час" на їх усунення.
🔸 Якщо ви не візьметесь за власну кібербезпеку, бо поспішаєте, то за неї візьмуться ті, хто нікуди не поспішає. І вам ще повезе, якщо внаслідок зламу вам одразу поставлять якийсь шлак (дефейс) на головну сторінку. Буде гірше, якщо зламник тихенько сидітиме у вашій системі, викачуючи ваші дані в режимі реального часу (і як цікавий варіант, зливаючи їх конкурентам), чи готуючи ваші потужності до участі в якійсь іншій кібератаці, тощо.
Маєте ще ідеї? Пишіть в коментарях)
🔸 Ви можете писати код швидко, є така практика і філософія. Але виділяйте час на його перевірку, ретельно тестуйте. А краще давайте тестувати ваш код/продукт тим, хто це вміє робити. Бажано, щоб професійні тестери були у штаті вашої команди (зрозуміло, що не завжди є ресурс на таку розкіш).
🔸 Ваш керівник/клієнт може не розбиратися в кібербезпеці, але хтось у команді повинен розбиратися, мати доступ до ревізії коду (peer review) і мати вплив на процес розробки. Автор коду дуже часто може не помітити вразливе місце. Добре би мати в команді повноцінного кіберспеціаліста чи хоча б періодично показувати йому свій код.
🔸 Якщо ви використовуєте деякий фреймворк, CMS-систему, CRM-систему тощо, намагайтесь слідкувати за новинами про ці продукти, щоб якомога раніше дізнатися про вразливості, коли про них почнуть писати публічно.
🔸 Якщо ви знайшли вразливості у вашому коді чи у використаних залежностях, то займайтеся вразливостями, а не відкладайте на потім. Внаслідок зламу вашої системи втрати можуть бути значно страшнішими, ніж неотримані премії за зірвані дедлайни. Доводьте до відома керівників/клієнтів суть загроз, намагайтесь "вибити час" на їх усунення.
🔸 Якщо ви не візьметесь за власну кібербезпеку, бо поспішаєте, то за неї візьмуться ті, хто нікуди не поспішає. І вам ще повезе, якщо внаслідок зламу вам одразу поставлять якийсь шлак (дефейс) на головну сторінку. Буде гірше, якщо зламник тихенько сидітиме у вашій системі, викачуючи ваші дані в режимі реального часу (і як цікавий варіант, зливаючи їх конкурентам), чи готуючи ваші потужності до участі в якійсь іншій кібератаці, тощо.
Маєте ще ідеї? Пишіть в коментарях)
РФ напала на Україну, майже як Гітлер в 1941-му.
Але зовсім не так успішно.
"Загарбники" несуть очікувані втрати. Вже збито чимало їхнього літаючого металобрухту. "Прожарка" танків пішла повним ходом.
Не панікуйте. В мережі шириться ДУЖЕ багато фейків. Фільтруйте, як боженьки. Бо завдяки Інтернету війна, паніка і дезінформація поширюється в головах швидше, ніж їхні срані ракети.
Вони воювати не вміють. Лише п*здіти і п*здити своїх громадян на мітингах. Бліцкригу немає і ВЖЕ НЕ БУДЕ.
НЕ фотографуйте, НЕ знімайте, НЕ описуйте, НЕ викладайте в мережу переміщення, маневри, дії і розташування наших військ, техніки, літаків, окремих військових і т.п.
Будьте розумно обачні та холоднокровні. Ваша емоційна стабільність і розсудливість — міцний вклад в їхню ганебну поразку.
Ми — нація з міцним осердям. І з нами цивілізований світ, а не купка анально зондованих диктаторів.
Україна ❤️
P.S. Про поспіх і архітектуру коду у поговоримо трохи згодом :)
* * *
РФ напала на Украину, почти как Гитлер в 1941-м.
Но совсем не так успешно.
"Завоеватели" несут ожидаемые потери. Уже сбито немало их летавшего металлолома. "Прожарка" танков пошла полным ходом.
Не паникуйте. В сети распространяется ОЧЕНЬ много фейков. Фильтруйте, как боженьки. Ведь благодаря Интернету война, паника и дезинформация распространяется в головах быстрее, чем их сраные ракеты.
Они воевать не умеют. Лишь п*здеть и п*здить своих граждан на митингах. Блицкрига не было и УЖЕ НЕ БУДЕТ.
НЕ фотографируйте, НЕ снимайте, НЕ описывайте, НЕ выкладывайте в сеть перемещения, манёвры, действия и расположение наших войск, техники, самолётов, отдельных военных и т.п.
Будьте разумно бдительны и хладнокровны. Ваша эмоциональная стабильность и рассудительность — крепкий вклад в их позорное поражение.
Мы — нация с крепким стержнем. И с нами цивилизованный мир, а не кучка анально зондированных диктаторов.
Украина ❤️
Але зовсім не так успішно.
"Загарбники" несуть очікувані втрати. Вже збито чимало їхнього літаючого металобрухту. "Прожарка" танків пішла повним ходом.
Не панікуйте. В мережі шириться ДУЖЕ багато фейків. Фільтруйте, як боженьки. Бо завдяки Інтернету війна, паніка і дезінформація поширюється в головах швидше, ніж їхні срані ракети.
Вони воювати не вміють. Лише п*здіти і п*здити своїх громадян на мітингах. Бліцкригу немає і ВЖЕ НЕ БУДЕ.
НЕ фотографуйте, НЕ знімайте, НЕ описуйте, НЕ викладайте в мережу переміщення, маневри, дії і розташування наших військ, техніки, літаків, окремих військових і т.п.
Будьте розумно обачні та холоднокровні. Ваша емоційна стабільність і розсудливість — міцний вклад в їхню ганебну поразку.
Ми — нація з міцним осердям. І з нами цивілізований світ, а не купка анально зондованих диктаторів.
Україна ❤️
P.S. Про поспіх і архітектуру коду у поговоримо трохи згодом :)
* * *
РФ напала на Украину, почти как Гитлер в 1941-м.
Но совсем не так успешно.
"Завоеватели" несут ожидаемые потери. Уже сбито немало их летавшего металлолома. "Прожарка" танков пошла полным ходом.
Не паникуйте. В сети распространяется ОЧЕНЬ много фейков. Фильтруйте, как боженьки. Ведь благодаря Интернету война, паника и дезинформация распространяется в головах быстрее, чем их сраные ракеты.
Они воевать не умеют. Лишь п*здеть и п*здить своих граждан на митингах. Блицкрига не было и УЖЕ НЕ БУДЕТ.
НЕ фотографируйте, НЕ снимайте, НЕ описывайте, НЕ выкладывайте в сеть перемещения, манёвры, действия и расположение наших войск, техники, самолётов, отдельных военных и т.п.
Будьте разумно бдительны и хладнокровны. Ваша эмоциональная стабильность и рассудительность — крепкий вклад в их позорное поражение.
Мы — нация с крепким стержнем. И с нами цивилизованный мир, а не кучка анально зондированных диктаторов.
Украина ❤️
⚠️ В інфопростір можуть залітати фейки, ніби Україна здалася і підписала якісь документи.
Але це не так і цього не буде.
Україна міцна, мотивована і цивілізований світ з нами. Нашого Президента вже порівнюють з Брюсом Віллісом.
Росія не зможе виграти цю війну, поки наші громадяни палять їхні танки і БТРи ганчірками. Ганчірками, Карл!
Важливо брати до уваги інформацію, яка надходить передусім з офіційних джерел. І слід розуміти, що навіть офіційне джерело може бути на деякий час зламаним, через нього може бути здійснена фейк-диверсія. Тому бережіть свою свідомість від різкої реакції на будь-яку інформацію. Перевіряйте в кількох різних джерелах. Війна — це не лише постріли на вулиці, це й біль, відчай, страх, зневіра і будь-що інше, що ви переживаєте на вашому емоційному фронті.
Ось приклади деяких офіційних джерел:
Президент України: https://www.tg-me.com/V_Zelenskiy_official
Служба безпеки України: https://www.tg-me.com/SBUkr
Нацполіція: https://www.tg-me.com/UA_National_Police
Ось корисний сайт по темі війни, його підняла людина, яку я особисто знаю:
🔸 https://resist.in.ua
Якщо ви не знаєте, як допомогти зараз Україні, можете почати з цієї сторінки:
https://resist.in.ua/#/tasks
Але це не так і цього не буде.
Україна міцна, мотивована і цивілізований світ з нами. Нашого Президента вже порівнюють з Брюсом Віллісом.
Росія не зможе виграти цю війну, поки наші громадяни палять їхні танки і БТРи ганчірками. Ганчірками, Карл!
Важливо брати до уваги інформацію, яка надходить передусім з офіційних джерел. І слід розуміти, що навіть офіційне джерело може бути на деякий час зламаним, через нього може бути здійснена фейк-диверсія. Тому бережіть свою свідомість від різкої реакції на будь-яку інформацію. Перевіряйте в кількох різних джерелах. Війна — це не лише постріли на вулиці, це й біль, відчай, страх, зневіра і будь-що інше, що ви переживаєте на вашому емоційному фронті.
Ось приклади деяких офіційних джерел:
Президент України: https://www.tg-me.com/V_Zelenskiy_official
Служба безпеки України: https://www.tg-me.com/SBUkr
Нацполіція: https://www.tg-me.com/UA_National_Police
Ось корисний сайт по темі війни, його підняла людина, яку я особисто знаю:
🔸 https://resist.in.ua
Якщо ви не знаєте, як допомогти зараз Україні, можете почати з цієї сторінки:
https://resist.in.ua/#/tasks