Нужна ли логика для того, чтобы кодить?
Да. Но не всё так плохо. Давайте разберёмся.
В программе юрфаков курс логики обычно есть. И в нём, помимо прочего, должны излагаться такие вещи: конъюнкция (логическое "И"), дизъюнкция (логическое "ИЛИ"), отрицание (логическое "НЕ"), импликация ("ЕСЛИ ... ТО"), а также понятие об истинности/ложности высказывания ("True" / "False"). Эти несколько вещей и составляют "логическую основу" кодинга, во всяком случае, для начинающих. Давайте разберём на конкретном бытовом примере.
Пример из жизни, чтоб показать, что мы уже мыслим логически:
1. Бытовушное описание.
Когда я проснусь, то не ранее 8 утра захочу открыть окно, чтобы проветрить свою конуру. Но я это сделаю, если температура на улице больше 9°C и если нет дождя, снега, града и прочей дичи, падающей с небес.
2. Логическое описание.
Если я проснулся, тогда проверю время. Если уже есть 8:00, тогда я выгляну в окно, чтобы проверить температуру за окном и наличие осадков. Если температура выше 9°C и если нет осадков, тогда я открою окно.
3. Описание псевдокодом (абстрактный код, который пародирует языки программирования и который можно быстро приспособить под любой из них).
if( awakeningDone == True ){
if( time >= "8:00" ){
if( temperatureC > 9 AND precipitation == False ){
openTheWindow();
}
}
}
Как видите, наши "когда" и "не ранее" в бытовушном описании мы превратили в "если" в логическом описании.
А все имеющиеся "если" в логическом описании мы превратили в конструкции if( условие... ){ код... } в описании псевдокодом. Кроме этого, состояние пробуждения проверяем на истинность ( awakeningDone == True ), сравниваем время ( time >= "8:00" ), температуру ( temperatureC > 9 ) и проверяем наличие осадков на ложность ( precipitation == False ), ведь они нам не нужны.
Вот вам и пример формализации бытовой логики, ничего сложного. :)
К ней ещё не раз вернёмся, ведь в мире кодинга страшна не логика, а страшно и разрушительно её отсутствие.
Да. Но не всё так плохо. Давайте разберёмся.
В программе юрфаков курс логики обычно есть. И в нём, помимо прочего, должны излагаться такие вещи: конъюнкция (логическое "И"), дизъюнкция (логическое "ИЛИ"), отрицание (логическое "НЕ"), импликация ("ЕСЛИ ... ТО"), а также понятие об истинности/ложности высказывания ("True" / "False"). Эти несколько вещей и составляют "логическую основу" кодинга, во всяком случае, для начинающих. Давайте разберём на конкретном бытовом примере.
Пример из жизни, чтоб показать, что мы уже мыслим логически:
1. Бытовушное описание.
Когда я проснусь, то не ранее 8 утра захочу открыть окно, чтобы проветрить свою конуру. Но я это сделаю, если температура на улице больше 9°C и если нет дождя, снега, града и прочей дичи, падающей с небес.
2. Логическое описание.
Если я проснулся, тогда проверю время. Если уже есть 8:00, тогда я выгляну в окно, чтобы проверить температуру за окном и наличие осадков. Если температура выше 9°C и если нет осадков, тогда я открою окно.
3. Описание псевдокодом (абстрактный код, который пародирует языки программирования и который можно быстро приспособить под любой из них).
if( awakeningDone == True ){
if( time >= "8:00" ){
if( temperatureC > 9 AND precipitation == False ){
openTheWindow();
}
}
}
Как видите, наши "когда" и "не ранее" в бытовушном описании мы превратили в "если" в логическом описании.
А все имеющиеся "если" в логическом описании мы превратили в конструкции if( условие... ){ код... } в описании псевдокодом. Кроме этого, состояние пробуждения проверяем на истинность ( awakeningDone == True ), сравниваем время ( time >= "8:00" ), температуру ( temperatureC > 9 ) и проверяем наличие осадков на ложность ( precipitation == False ), ведь они нам не нужны.
Вот вам и пример формализации бытовой логики, ничего сложного. :)
К ней ещё не раз вернёмся, ведь в мире кодинга страшна не логика, а страшно и разрушительно её отсутствие.
Нужен ли English, чтобы кодить?
Да. Но не такой сложный, как у юристов.
Часто говорят, что без английского о карьере программиста можно забыть. Но стоп, мы же хотим для начала немного покодить...
1. Чтобы кодить, как и в случае с математикой, для начала хватит и школьной программы. Популярнейшие языки программирования создавались и создаются в англоязычной среде, в их основе английские слова. Из-за этого большую часть времени вам придётся использовать такие сложные слова, как:
if, else, for, while, switch, function, return, class, private, public, match, replace, round, floor, ceil...
Иногда могут всплывать ещё более сложные: array, import, include, explode, implode, decode, encode... Да, иногда будут попадаться стрёмные триады типа ignore_user_abort, а иногда даже верблюды: getElementById.
Но эти слова/словосочетания самодостаточны и однозначны. Я пока ещё не видел, чтоб одно и то же слово в языке программирования имело разные значения. А теперь посмотрите, что творится в юридическом English, какого уровня обороты используются там, сколько идиом и традиций... Языкам программирования далеко до этого. :)
2. Да, существует ещё такая штука, как документация языков программирования и разных технологий. Но её, снова-таки, пишут простым языком, без сложноподчинённого террариума. Первая книга на английском, которую я осилил полностью и без боли, был мануал по одной программе. На англоязычных форумах тоже не Шекспиры сидят.
3. Но почему от кодеров в вакансиях иногда требуют уровень владения английским Intermediate, а то и выше? Да потому, что:
- нужна уверенность, что он/она не будет каждые 10 минут тратить 1 минуту в гугл-переводчике;
- передовые технологии и обновы в первую очередь документируются и обсуждаются на английском, нужно держать руку на пульсе;
- команды интернациональны, все должны понимать друг друга;
- ну и вишенка: нередко хотят перенести на самого кодера общение с клиентом, ибо внедрён Agile и всё такое.
Поэтому можно начать кодить и со "школьным" английским. А там глядишь, романтика создания технологий собственными руками вдруг заставит раскачать свой English.
Да. Но не такой сложный, как у юристов.
Часто говорят, что без английского о карьере программиста можно забыть. Но стоп, мы же хотим для начала немного покодить...
1. Чтобы кодить, как и в случае с математикой, для начала хватит и школьной программы. Популярнейшие языки программирования создавались и создаются в англоязычной среде, в их основе английские слова. Из-за этого большую часть времени вам придётся использовать такие сложные слова, как:
if, else, for, while, switch, function, return, class, private, public, match, replace, round, floor, ceil...
Иногда могут всплывать ещё более сложные: array, import, include, explode, implode, decode, encode... Да, иногда будут попадаться стрёмные триады типа ignore_user_abort, а иногда даже верблюды: getElementById.
Но эти слова/словосочетания самодостаточны и однозначны. Я пока ещё не видел, чтоб одно и то же слово в языке программирования имело разные значения. А теперь посмотрите, что творится в юридическом English, какого уровня обороты используются там, сколько идиом и традиций... Языкам программирования далеко до этого. :)
2. Да, существует ещё такая штука, как документация языков программирования и разных технологий. Но её, снова-таки, пишут простым языком, без сложноподчинённого террариума. Первая книга на английском, которую я осилил полностью и без боли, был мануал по одной программе. На англоязычных форумах тоже не Шекспиры сидят.
3. Но почему от кодеров в вакансиях иногда требуют уровень владения английским Intermediate, а то и выше? Да потому, что:
- нужна уверенность, что он/она не будет каждые 10 минут тратить 1 минуту в гугл-переводчике;
- передовые технологии и обновы в первую очередь документируются и обсуждаются на английском, нужно держать руку на пульсе;
- команды интернациональны, все должны понимать друг друга;
- ну и вишенка: нередко хотят перенести на самого кодера общение с клиентом, ибо внедрён Agile и всё такое.
Поэтому можно начать кодить и со "школьным" английским. А там глядишь, романтика создания технологий собственными руками вдруг заставит раскачать свой English.
Нужен ли педантизм/буквоедство, чтобы кодить?
Да. Но похлеще, чем у юристов. Последние три дня я утверждал, что можно кодить со школьной математикой, школьным English и развитой бытовой логикой. Но в случае с педантизмом/внимательностью такое не прокатит.
1. Если вы пропустите запятую или кавычку в договоре, иске или законопроекте, то быть может, вам это простится. Договор подпишут, суд примет иск, а законопроект пройдёт все стадии. Но компьютер тут схалтурить не даст: программа зачастую просто не запустится, если допустить подобную ошибку. А если запустится, тем хуже для вас: может быть заложена потенциальная ошибка или уязвимость, которая проявится со временем.
⛔️ Примеры, когда не запустится вовсе (язык PHP):
$law = "good; — тут нужна закрывающая кавычка
$law = "good'; — тут нужна закрывающая кавычка того же типа, что и открывающая
$law = "good" — тут в конце инструкции должна стоять точка с запятой (;)
law = "good"; — тут пропущен знак $ для обозначения переменной
🐛 Пример, когда запустится, к сожалению:
if( $userPassword = $realPassword ){ //code } — тут блок //code будет выполняться всегда, ибо в блоке if происходит не сравнение (знак == ), а тупо присваивание (знак = ). Так можно заложить страшную уязвимость, если не тестировать свой код.
2. Как же быть? На самом деле, специальный софт для кодинга заботливо помогает отслеживать такие вещи ещё на стадии написания кода. Также при тестировании отдельная подпрограмма укажет номер строчки, в которой обнаружилась ошибка, и даже её тип. Более того, если вы сидите в браузере на чужом сайте, можете нажать F12, чтобы увидеть возможные ошибки в панели разработчика (вкладка "Console"). Но на софт полагайся, а сам(-а) не расслабляйся, ведь страшны ошибки не синтаксические, а логические (о них будет отдельный пост).
3. Поэтому если вы заслуженно считаете себя педантом/буквоедом, вам хорошо даётся вычитка драфтов и дьюдилы, у вас взгляд натаскан на двойные пробелы, а нерасставленные знаки препинания вызывают боль, то вход в мир кодинга станет для вас прогулкой. Если же нет, тогда это будет хорошее испытание. В любом случае программирование — это мир, где вы почувствуете, что ваша любовь к точности и порядку востребована.
Да. Но похлеще, чем у юристов. Последние три дня я утверждал, что можно кодить со школьной математикой, школьным English и развитой бытовой логикой. Но в случае с педантизмом/внимательностью такое не прокатит.
1. Если вы пропустите запятую или кавычку в договоре, иске или законопроекте, то быть может, вам это простится. Договор подпишут, суд примет иск, а законопроект пройдёт все стадии. Но компьютер тут схалтурить не даст: программа зачастую просто не запустится, если допустить подобную ошибку. А если запустится, тем хуже для вас: может быть заложена потенциальная ошибка или уязвимость, которая проявится со временем.
⛔️ Примеры, когда не запустится вовсе (язык PHP):
$law = "good; — тут нужна закрывающая кавычка
$law = "good'; — тут нужна закрывающая кавычка того же типа, что и открывающая
$law = "good" — тут в конце инструкции должна стоять точка с запятой (;)
law = "good"; — тут пропущен знак $ для обозначения переменной
🐛 Пример, когда запустится, к сожалению:
if( $userPassword = $realPassword ){ //code } — тут блок //code будет выполняться всегда, ибо в блоке if происходит не сравнение (знак == ), а тупо присваивание (знак = ). Так можно заложить страшную уязвимость, если не тестировать свой код.
2. Как же быть? На самом деле, специальный софт для кодинга заботливо помогает отслеживать такие вещи ещё на стадии написания кода. Также при тестировании отдельная подпрограмма укажет номер строчки, в которой обнаружилась ошибка, и даже её тип. Более того, если вы сидите в браузере на чужом сайте, можете нажать F12, чтобы увидеть возможные ошибки в панели разработчика (вкладка "Console"). Но на софт полагайся, а сам(-а) не расслабляйся, ведь страшны ошибки не синтаксические, а логические (о них будет отдельный пост).
3. Поэтому если вы заслуженно считаете себя педантом/буквоедом, вам хорошо даётся вычитка драфтов и дьюдилы, у вас взгляд натаскан на двойные пробелы, а нерасставленные знаки препинания вызывают боль, то вход в мир кодинга станет для вас прогулкой. Если же нет, тогда это будет хорошее испытание. В любом случае программирование — это мир, где вы почувствуете, что ваша любовь к точности и порядку востребована.
Каким может быть первый раз
В программирование юрист может войти по-разному. Подумал и объединил известные мне способы в три пути. И выставил их по порядку от простого к непростому. А ещё их можно проходить последовательно.
📜 Через алгоритмизацию разных процессов, например, юридической рутины. Тут юрист сначала выполняет роль архитектора, а каменщиком является нанятый в штат или временно подряженный кодер. Юрист здесь является автором общей логики продукта, определяет цели и условия их достижения (то есть ставит технические задачи). Кодер же задаёт юристу рамки, обусловленные бюджетом, платформой, интерфейсом и другими техническими вещами. Но роль юриста вовсе не должна ограничиваться командами типа "сделай здесь красиво, а здесь чтобы фоточка выскакивала". Юрист тщательно выписывает алгоритм/контент либо в доке на Google Drive, либо в каком-нибудь софте для прототипирования, то есть он реальный соразработчик. Таким образом, вы плавненько переходите от стратегического мышления к техническому пониманию, и вам уже будет легче взяться за кодинг. Но всё ещё не так легко.
🎨 Компромиссный вариант — программы/сервисы по типу What You See Is What You Get — WYSIWYG. Благодаря одной из них я стал лигалинженером в Axon Partners, но это будет отдельная история (спойлер: потом её стало мало, чтобы удержаться). В таких программах вы в 80-90% случаев не пишете никакой код, а либо строите что-то вроде конструктора, либо прокладываете логические лабиринты, а оно потом работает так, будто вы кодили. Можно быстро влиться, и дальше может произойти чудо. Если вы стали настолько усердно работать в них, что перестало хватать встроенного функционала и вы всё больше смещались в те 10-20% случаев написания кода — поздравляю: вы почти совершили мягкий переход. Теперь нужно выбрать: оставаться дальше в тени WYSIWYG и вести ограниченную жизнь или овладеть джедайской силой кодинга.
🛠 Сразу через кодинг, пытаясь делать то, что нафантазировал ваш учитель, автор учебного пособия, организатор курсов и т.д. В моём случае это была информатика в лицее, где нам предлагался язык Паскаль, а в качестве инструмента чудная прога АЛГО. Самое лучшее началось, когда дали задание на дом — сделать собственный проект. Первая моя работа — виртуальный собеседник на тему футбола (но из-за ограничения на количество строк кода разговор получился коротким). Этот путь сложен тем, что приходится одновременно и прототипировать продукт, и физически создавать его строчка за строчкой, то есть развивать и глобальное, и локальное мышление. Но в процессе уже можно получать удовольствие.
В программирование юрист может войти по-разному. Подумал и объединил известные мне способы в три пути. И выставил их по порядку от простого к непростому. А ещё их можно проходить последовательно.
📜 Через алгоритмизацию разных процессов, например, юридической рутины. Тут юрист сначала выполняет роль архитектора, а каменщиком является нанятый в штат или временно подряженный кодер. Юрист здесь является автором общей логики продукта, определяет цели и условия их достижения (то есть ставит технические задачи). Кодер же задаёт юристу рамки, обусловленные бюджетом, платформой, интерфейсом и другими техническими вещами. Но роль юриста вовсе не должна ограничиваться командами типа "сделай здесь красиво, а здесь чтобы фоточка выскакивала". Юрист тщательно выписывает алгоритм/контент либо в доке на Google Drive, либо в каком-нибудь софте для прототипирования, то есть он реальный соразработчик. Таким образом, вы плавненько переходите от стратегического мышления к техническому пониманию, и вам уже будет легче взяться за кодинг. Но всё ещё не так легко.
🎨 Компромиссный вариант — программы/сервисы по типу What You See Is What You Get — WYSIWYG. Благодаря одной из них я стал лигалинженером в Axon Partners, но это будет отдельная история (спойлер: потом её стало мало, чтобы удержаться). В таких программах вы в 80-90% случаев не пишете никакой код, а либо строите что-то вроде конструктора, либо прокладываете логические лабиринты, а оно потом работает так, будто вы кодили. Можно быстро влиться, и дальше может произойти чудо. Если вы стали настолько усердно работать в них, что перестало хватать встроенного функционала и вы всё больше смещались в те 10-20% случаев написания кода — поздравляю: вы почти совершили мягкий переход. Теперь нужно выбрать: оставаться дальше в тени WYSIWYG и вести ограниченную жизнь или овладеть джедайской силой кодинга.
🛠 Сразу через кодинг, пытаясь делать то, что нафантазировал ваш учитель, автор учебного пособия, организатор курсов и т.д. В моём случае это была информатика в лицее, где нам предлагался язык Паскаль, а в качестве инструмента чудная прога АЛГО. Самое лучшее началось, когда дали задание на дом — сделать собственный проект. Первая моя работа — виртуальный собеседник на тему футбола (но из-за ограничения на количество строк кода разговор получился коротким). Этот путь сложен тем, что приходится одновременно и прототипировать продукт, и физически создавать его строчка за строчкой, то есть развивать и глобальное, и локальное мышление. Но в процессе уже можно получать удовольствие.
Какой язык программирования выбрать?
Это частый злободневный вопрос. Часто связан с вопросом, какой язык программирования (далее — ЯП) лучше/перспективнее. Как по мне, это очень похоже на вопрос "в какой отрасли права лучше запустить свой юрбиз?".
В программировании есть ЯП, популярные сейчас, и есть "угасающие". Есть и практически заброшенные, с узким кругом почитателей (прям как латынь). Есть ЯП, которые целесообразны для программирования "железа" (роботы-пылесосы, датчики для смарт-курятников и т.д.), а есть те, за счёт которых работают веб-сайты. Так что выбор ЯП — вопрос того, чем вы хотите заниматься. Ведутся специальные рейтинги ЯП, по которым вы сегодня можете примерно оценить "популярность" и "перспективность" основных ЯП.
Основываясь на данных dou.ua и proglib.io, выстраиваю здесь свой топ 5 ЯП с точки зрения полезности для юриста:
1. JavaScript
суть: наиболее широко применяется на веб-сайтах, гибкий, можно делать весьма разнообразные штуки, есть хорошие библиотеки.
популярность: ⌨️⌨️⌨️
перспективы: 🚀🚀🚀🚀
сложность: 🤯🤯
мой опыт: использую постоянно.
2. Python
суть: минималистичный синтаксис, хорошее коммьюнити, много библиотек, подточен под машинное обучение и анализ данных, имеет официальную философию.
популярность: ⌨️⌨️⌨️
перспективы: 🚀🚀🚀🚀
сложность: 🤯
мой опыт: прошёл вводный курс, потихоньку начинаю использовать.
3. PHP
суть: применяется в основном в веб-проектах, удобно строить большие и динамические сайты, поддерживается многими провайдерами.
популярность: ⌨️⌨️
перспективы: 🚀🚀🚀
сложность: 🤯🤯
мой опыт: использую постоянно.
4. Java
суть: потенциально охватывает множество устройств, активно используется для кодинга под Android.
популярность: ⌨️⌨️⌨️
перспективы: 🚀🚀🚀
сложность: 🤯🤯🤯
мой опыт: -
5. C#
суть: ведущий язык для платформы .net, поближе к Windows.
популярность: ⌨️⌨️
перспективы: 🚀🚀
сложность: 🤯🤯🤯
мой опыт: -
Здесь не упомянуты такие, возможно, интересные для юристов языки, как R, Go и Swift. В ненужности юристам C/C++ на фоне других ЯП уверен.
А вы уже кодили, кроме уроков информатики в школе?
✔️ — ДА; ❌ — НЕТ
Это частый злободневный вопрос. Часто связан с вопросом, какой язык программирования (далее — ЯП) лучше/перспективнее. Как по мне, это очень похоже на вопрос "в какой отрасли права лучше запустить свой юрбиз?".
В программировании есть ЯП, популярные сейчас, и есть "угасающие". Есть и практически заброшенные, с узким кругом почитателей (прям как латынь). Есть ЯП, которые целесообразны для программирования "железа" (роботы-пылесосы, датчики для смарт-курятников и т.д.), а есть те, за счёт которых работают веб-сайты. Так что выбор ЯП — вопрос того, чем вы хотите заниматься. Ведутся специальные рейтинги ЯП, по которым вы сегодня можете примерно оценить "популярность" и "перспективность" основных ЯП.
Основываясь на данных dou.ua и proglib.io, выстраиваю здесь свой топ 5 ЯП с точки зрения полезности для юриста:
1. JavaScript
суть: наиболее широко применяется на веб-сайтах, гибкий, можно делать весьма разнообразные штуки, есть хорошие библиотеки.
популярность: ⌨️⌨️⌨️
перспективы: 🚀🚀🚀🚀
сложность: 🤯🤯
мой опыт: использую постоянно.
2. Python
суть: минималистичный синтаксис, хорошее коммьюнити, много библиотек, подточен под машинное обучение и анализ данных, имеет официальную философию.
популярность: ⌨️⌨️⌨️
перспективы: 🚀🚀🚀🚀
сложность: 🤯
мой опыт: прошёл вводный курс, потихоньку начинаю использовать.
3. PHP
суть: применяется в основном в веб-проектах, удобно строить большие и динамические сайты, поддерживается многими провайдерами.
популярность: ⌨️⌨️
перспективы: 🚀🚀🚀
сложность: 🤯🤯
мой опыт: использую постоянно.
4. Java
суть: потенциально охватывает множество устройств, активно используется для кодинга под Android.
популярность: ⌨️⌨️⌨️
перспективы: 🚀🚀🚀
сложность: 🤯🤯🤯
мой опыт: -
5. C#
суть: ведущий язык для платформы .net, поближе к Windows.
популярность: ⌨️⌨️
перспективы: 🚀🚀
сложность: 🤯🤯🤯
мой опыт: -
Здесь не упомянуты такие, возможно, интересные для юристов языки, как R, Go и Swift. В ненужности юристам C/C++ на фоне других ЯП уверен.
А вы уже кодили, кроме уроков информатики в школе?
✔️ — ДА; ❌ — НЕТ
Чем вообще отличаются языки программирования?
Все различия между языками программирования (далее — ЯП) я бы условно поделил на три группы: устройство/возможности, синтаксис/внешность и тренды в применении.
⚙️ Устройство / Возможности
Самая важная группа, ведь ЯП прежде всего — это "рабочая лошадка". У разных ЯП есть разные возможности и ограничения, также нередко одни и те же функции реализованы по-разному. Также различается механика запуска и выполнения исходного кода. Кому интересно, есть неплохая сравнительная таблица. Но давайте в это пока не углубляться. Скажу только, что для новичка в мире кодинга эти различия вытекают в следующее: перейти с JavaScript или PHP на C++ или Java сложнее, нежели наоборот.
🎇 Синтаксис / Внешность
Все популярные ЯП, на первый взгляд, выглядят одинаково: тупо текст, напичканный сторонними символами: {}()""'';$=>. Но если присмотреться, разные правила синтаксиса определяют разное общее впечатление от вида большого куска кода. Нередко можно услышать, что Python элегантен, ведь в нём не нужно ставить вездесущие фигурные скобки {}. Но за этой простотой кроется другая угроза: нужно следить за отступами. Также вы могли видеть, что у кодеров на мониторе код бывает разноцветный. Эта "раскраска" зависит не от ЯП, а от настроек программы, в которой пишется этот код. Вовсе не стоит выбирать ЯП исходя из этого критерия, это как выбирать адвоката по цвету рубашки и волос.
🚲 Тренды в применении
Так сложилось, что ЯП ещё нужно оценивать и с точки зрения целесообразности его применения для решения той или иной задачи. Много кому покажется смешным, что свои первые две нейросети я написал на PHP, ведь для такого дела в тренде Python. Но в этих "традициях" действительно нередко есть смысл: наличие тех или иных библиотек на конкретном ЯП означает, что именно с этим ЯП задачу можно решить быстрее, легче, удобнее и дешевле, не "изобретая велосипед заново". А если вы хорошо овладели, скажем, двумя ЯП, вам несложно будет выучить третий под конкретную задачу, если сильно понадобится.
А что для вас важнее: возможности (⚙️) или тренды (🚲) ?
Если у вас есть вопросы/пожелания, пишите их в комментарии к этому посту, мне в личку или на почту (см. в описании канала).
Все различия между языками программирования (далее — ЯП) я бы условно поделил на три группы: устройство/возможности, синтаксис/внешность и тренды в применении.
⚙️ Устройство / Возможности
Самая важная группа, ведь ЯП прежде всего — это "рабочая лошадка". У разных ЯП есть разные возможности и ограничения, также нередко одни и те же функции реализованы по-разному. Также различается механика запуска и выполнения исходного кода. Кому интересно, есть неплохая сравнительная таблица. Но давайте в это пока не углубляться. Скажу только, что для новичка в мире кодинга эти различия вытекают в следующее: перейти с JavaScript или PHP на C++ или Java сложнее, нежели наоборот.
🎇 Синтаксис / Внешность
Все популярные ЯП, на первый взгляд, выглядят одинаково: тупо текст, напичканный сторонними символами: {}()""'';$=>. Но если присмотреться, разные правила синтаксиса определяют разное общее впечатление от вида большого куска кода. Нередко можно услышать, что Python элегантен, ведь в нём не нужно ставить вездесущие фигурные скобки {}. Но за этой простотой кроется другая угроза: нужно следить за отступами. Также вы могли видеть, что у кодеров на мониторе код бывает разноцветный. Эта "раскраска" зависит не от ЯП, а от настроек программы, в которой пишется этот код. Вовсе не стоит выбирать ЯП исходя из этого критерия, это как выбирать адвоката по цвету рубашки и волос.
🚲 Тренды в применении
Так сложилось, что ЯП ещё нужно оценивать и с точки зрения целесообразности его применения для решения той или иной задачи. Много кому покажется смешным, что свои первые две нейросети я написал на PHP, ведь для такого дела в тренде Python. Но в этих "традициях" действительно нередко есть смысл: наличие тех или иных библиотек на конкретном ЯП означает, что именно с этим ЯП задачу можно решить быстрее, легче, удобнее и дешевле, не "изобретая велосипед заново". А если вы хорошо овладели, скажем, двумя ЯП, вам несложно будет выучить третий под конкретную задачу, если сильно понадобится.
А что для вас важнее: возможности (⚙️) или тренды (🚲) ?
Если у вас есть вопросы/пожелания, пишите их в комментарии к этому посту, мне в личку или на почту (см. в описании канала).
Работают ли юристы с алгоритмами?
Да. Постоянно. Только чаще это скрывается под личиной таких слов: порядок/последовательность действий при подготовке консультации, рецепт успеха/выигрыша в суде, чеклист для похода к госрегистратору, политика вычитки договоров и т.д.
Полное определение и историю этого термина вы можете почитать на Википедии. Важно то, что любой алгоритм можно разложить на 3 составляющие. Рассмотрим сразу на двух параллельных примерах: охота за бананом на высокой пальме (🌴) и выигрыш вами суда как представителем истца (⚖️).
🎯 Конечный результат/цель — самая важная, ведь к ней вы стремитесь, её нужно заполучить, иначе в противном случае алгоритм был бы бессмыслицей. Её важно правильно сформулировать. С этого нужно начинать строить алгоритм:
1. достать/сорвать банан с пальмы;
2. получить решение суда, в котором удовлетворены ваши исковые требования.
🧸 Изначальные ресурсы/данные — думаем, что у нас есть из того, что могло бы оказаться полезным для достижения цели:
1. камни, палки, верёвки, ствол самой пальмы, хорошая физическая форма и т.д.;
2. доказательства, свидетели, собственная харизма и т.д.
🔗 Порядок действий над изначальными ресурсами/данными, завершающийся достижением цели. Самая сложная часть алгоритма. Но человечество доказало, что при хорошем знании своего дела и логическом мышлении можно строить очень сложные алгоритмы.
1.1. находим палку достаточной длины;
1.2. сбиваем этой палкой банан.
или
1.1. тупо лезем по стволу вверх
1.2. как долезли, срываем банан (и тут наш алгоритм обрывается, ибо мы же поставили себе цель достать/сорвать банан; так что можем оборваться и мы с пальмы, если не продумали эту ситуацию наперёд).
2.1. собираем у истца (и, возможно, у третьих лиц) нужную информацию, доказательства;
2.2. формируем иск (а это отдельный алгоритм);
2.3. подаём иск в суд;
2.4. являемся в первое заседание (и отдельный алгоритм, что делаем в нём);
2.5. подаём по ситуации нужные ходатайства;
(2.6.) если нужно, являемся в другие заседания;
2.7. ожидаем вынесение решения.
Как видите, алгоритм может быть довольно сложным, включать в себя подалгоритмы, а также шаги, о необходимости которых заранее неизвестно. Уверен, вам есть чем дополнить этот алгоритм.
#алгоритм
Да. Постоянно. Только чаще это скрывается под личиной таких слов: порядок/последовательность действий при подготовке консультации, рецепт успеха/выигрыша в суде, чеклист для похода к госрегистратору, политика вычитки договоров и т.д.
Полное определение и историю этого термина вы можете почитать на Википедии. Важно то, что любой алгоритм можно разложить на 3 составляющие. Рассмотрим сразу на двух параллельных примерах: охота за бананом на высокой пальме (🌴) и выигрыш вами суда как представителем истца (⚖️).
🎯 Конечный результат/цель — самая важная, ведь к ней вы стремитесь, её нужно заполучить, иначе в противном случае алгоритм был бы бессмыслицей. Её важно правильно сформулировать. С этого нужно начинать строить алгоритм:
1. достать/сорвать банан с пальмы;
2. получить решение суда, в котором удовлетворены ваши исковые требования.
🧸 Изначальные ресурсы/данные — думаем, что у нас есть из того, что могло бы оказаться полезным для достижения цели:
1. камни, палки, верёвки, ствол самой пальмы, хорошая физическая форма и т.д.;
2. доказательства, свидетели, собственная харизма и т.д.
🔗 Порядок действий над изначальными ресурсами/данными, завершающийся достижением цели. Самая сложная часть алгоритма. Но человечество доказало, что при хорошем знании своего дела и логическом мышлении можно строить очень сложные алгоритмы.
1.1. находим палку достаточной длины;
1.2. сбиваем этой палкой банан.
или
1.1. тупо лезем по стволу вверх
1.2. как долезли, срываем банан (и тут наш алгоритм обрывается, ибо мы же поставили себе цель достать/сорвать банан; так что можем оборваться и мы с пальмы, если не продумали эту ситуацию наперёд).
2.1. собираем у истца (и, возможно, у третьих лиц) нужную информацию, доказательства;
2.2. формируем иск (а это отдельный алгоритм);
2.3. подаём иск в суд;
2.4. являемся в первое заседание (и отдельный алгоритм, что делаем в нём);
2.5. подаём по ситуации нужные ходатайства;
(2.6.) если нужно, являемся в другие заседания;
2.7. ожидаем вынесение решения.
Как видите, алгоритм может быть довольно сложным, включать в себя подалгоритмы, а также шаги, о необходимости которых заранее неизвестно. Уверен, вам есть чем дополнить этот алгоритм.
#алгоритм
Из чего нам строить алгоритмы
Как видно по предыдущему посту, алгоритмы состоят из активных действий. И вот же совпадение: множество команд в разных языках программирования (далее — ЯП) — это тоже действия. Поэтому для обозначения этих команд используются глаголы.
Вот подборка примеров таких команд из разных ЯП:
append, apply, bind, call, decode, encode, explode, implode, join, replace, return, switch, test, trim, unset...
Это облегчает переход от алгоритмического описания порядка действий к самому коду. Давайте проверим это на реальном примере.
🎯 Постановка задачи:
Допустим, нужно найти и выписать из данного текста все предложения, где есть слово "суперфиций".
🧸 Ресурсы:
1) данный текст: "Суперфиций важен! Никто не может это отрицать. Понятие суперфиция дают на юрфаке. Юрист не может об этом не знать.";
2) возможности ЯП JavaScript и библиотеки jQuery.
🔗 Порядок действий (собственно алгоритм):
1) разделяем текст на предложения (тут я исхожу из гипотезы-упрощения, что все предложения оканчиваются знаками ".", "!", "?");
2) каждое предложение тестируем на наличие "суперфици";
3) если "суперфици" есть в текущем предложении, добавляем его к находкам.
⌨️ Код (жирным выделяю эти самые действия):
let myText = "Суперфиций важен! Никто не может это отрицать. Понятие суперфиция дают на юрфаке. Юрист не может об этом не знать.";
let sentences = myText.split(/[\.\?\!]/);
for( i=0; i<sentences.length; i++ ){
let isHere = /суперфици/i.test(sentences[i]);
if( isHere == true ){
$("body").append("<br>"+sentences[i]);
}
}
Результат — у нас на странице появится:
Суперфиций важен
Понятие суперфиция дают на юрфаке
🤔 Вопрос: что будет, если мы в коде поменяем true на false? Пишите в комменты)
Обратная связь:
Вам ок такой формат (🆗) или нужно меньше кода (⛔️)?
#алгоритм #код
Как видно по предыдущему посту, алгоритмы состоят из активных действий. И вот же совпадение: множество команд в разных языках программирования (далее — ЯП) — это тоже действия. Поэтому для обозначения этих команд используются глаголы.
Вот подборка примеров таких команд из разных ЯП:
append, apply, bind, call, decode, encode, explode, implode, join, replace, return, switch, test, trim, unset...
Это облегчает переход от алгоритмического описания порядка действий к самому коду. Давайте проверим это на реальном примере.
🎯 Постановка задачи:
Допустим, нужно найти и выписать из данного текста все предложения, где есть слово "суперфиций".
🧸 Ресурсы:
1) данный текст: "Суперфиций важен! Никто не может это отрицать. Понятие суперфиция дают на юрфаке. Юрист не может об этом не знать.";
2) возможности ЯП JavaScript и библиотеки jQuery.
🔗 Порядок действий (собственно алгоритм):
1) разделяем текст на предложения (тут я исхожу из гипотезы-упрощения, что все предложения оканчиваются знаками ".", "!", "?");
2) каждое предложение тестируем на наличие "суперфици";
3) если "суперфици" есть в текущем предложении, добавляем его к находкам.
⌨️ Код (жирным выделяю эти самые действия):
let myText = "Суперфиций важен! Никто не может это отрицать. Понятие суперфиция дают на юрфаке. Юрист не может об этом не знать.";
let sentences = myText.split(/[\.\?\!]/);
for( i=0; i<sentences.length; i++ ){
let isHere = /суперфици/i.test(sentences[i]);
if( isHere == true ){
$("body").append("<br>"+sentences[i]);
}
}
Результат — у нас на странице появится:
Суперфиций важен
Понятие суперфиция дают на юрфаке
🤔 Вопрос: что будет, если мы в коде поменяем true на false? Пишите в комменты)
Обратная связь:
Вам ок такой формат (🆗) или нужно меньше кода (⛔️)?
#алгоритм #код
Будни юриста и функции()
☝️ В прошлом посте в коде промелькнули такие команды, как "split", "test" и "append". То есть в языках программирования (далее — ЯП) есть какие-то слова, способные делать многое, экономя вам гораздо больше времени, нежели его вам потребуется на их написание. Откуда это вообще взялось? Дело в том, что разработчики ЯП не были садистами. И они создали функции.
🏹 Что такое функция? Представьте, что к вам в команду пришёл новичок. И вот вам нужно научить его/её готовить договор на подписание. Вы говорите ему следующее:
"Подготовить некий договор на подписание означает:
1) распечатать договор на принтере;
2) проверить, все ли страницы на месте и нету ли изъянов печати;
3) скрепить степлером страницы."
🧠 Отныне он/она будет понимать, что когда просят "подготовить договор на подписание", то это означает порядок названных трёх действий. То есть вы создали функцию в голове новичка. И вам не надо больше никогда озвучивать ни одно из трёх действий, достаточно назвать эту функцию (или, как говорят программисты, "вызвать" её). Удобно, не так ли? И этот механизм очень распространён в нашей жизни: "пожарить картофан", "съездить на дачу" и т.д.
📎 Зачем нужны скобки после имён функций? Туда вписываются параметры, необходимые для их работы. Одним из параметров функции нередко является указание на предмет, над которым нужно совершить действия. В нашем случае обсуждаемая функция может иметь вид:
подготовьДоговорНаПодписание(название_договора);
⛏ Так вот, в разные ЯП встроено достаточно много базовых функций. Поэтому вы одной строчкой можете написать команду, чтобы разбить текст на части, посчитать количество каких-то слов в нём и сделать многое другое. Кроме этого, вы можете создавать даже свои собственные функции. Благодаря им кодинг не настолько жесток, каким кажется на первый взгляд. Это первопроходцам приходилось морочиться с битами и кодить практически на железе.
🤔 Как часто вы используете подобный механизм в жизни?
P.S. В пятницу будет первое задание на канале)
#функция
☝️ В прошлом посте в коде промелькнули такие команды, как "split", "test" и "append". То есть в языках программирования (далее — ЯП) есть какие-то слова, способные делать многое, экономя вам гораздо больше времени, нежели его вам потребуется на их написание. Откуда это вообще взялось? Дело в том, что разработчики ЯП не были садистами. И они создали функции.
🏹 Что такое функция? Представьте, что к вам в команду пришёл новичок. И вот вам нужно научить его/её готовить договор на подписание. Вы говорите ему следующее:
"Подготовить некий договор на подписание означает:
1) распечатать договор на принтере;
2) проверить, все ли страницы на месте и нету ли изъянов печати;
3) скрепить степлером страницы."
🧠 Отныне он/она будет понимать, что когда просят "подготовить договор на подписание", то это означает порядок названных трёх действий. То есть вы создали функцию в голове новичка. И вам не надо больше никогда озвучивать ни одно из трёх действий, достаточно назвать эту функцию (или, как говорят программисты, "вызвать" её). Удобно, не так ли? И этот механизм очень распространён в нашей жизни: "пожарить картофан", "съездить на дачу" и т.д.
📎 Зачем нужны скобки после имён функций? Туда вписываются параметры, необходимые для их работы. Одним из параметров функции нередко является указание на предмет, над которым нужно совершить действия. В нашем случае обсуждаемая функция может иметь вид:
подготовьДоговорНаПодписание(название_договора);
⛏ Так вот, в разные ЯП встроено достаточно много базовых функций. Поэтому вы одной строчкой можете написать команду, чтобы разбить текст на части, посчитать количество каких-то слов в нём и сделать многое другое. Кроме этого, вы можете создавать даже свои собственные функции. Благодаря им кодинг не настолько жесток, каким кажется на первый взгляд. Это первопроходцам приходилось морочиться с битами и кодить практически на железе.
🤔 Как часто вы используете подобный механизм в жизни?
P.S. В пятницу будет первое задание на канале)
#функция
Как выбрать материал для обучения
По стилю изложения можно обозначить такие две полярные группы, на отрезке между которыми расположены любые материалы по изучению программирования:
📄 Классика, где излагается сухая теория и при крайней необходимости приводятся скудные примеры. Встречаются практически такие же многоэтажные обороты, как и у юристов. О пороге входа автор часто не заботится: "либо вникай, либо проваливай". Это чаще книги и статьи на Википедии, чем видео.
🍿 Нечто необычное, где примеры зачастую опережают определения; примеры вполне понятны и связаны с бытом; даже есть некая доля юмора. Низкий порог входа. Это чаще видео (или живой перфоманс, который потом шерится как видео) и какие-то интерактивные штуки. Ну и этот телеграм-канал я стараюсь вести в таком ключе.
С чего начинать, тут на самом деле каждый для себя может решить. Если у вас научный бэкграунд или вы просто любите сложные тексты, то первая группа поможет хорошо углубиться и далеко пройти. Что же насчёт второй группы, то я не смотрел много видосов, но меня в своё время впечатлил видеокурс от CS50 на YouTube (вот, например, первая лекция). Они с потрясающим цинизмом помогают понять разные непростые явления в кодинге и вообще логику работы ЭВМ.
📨 Один подписчик написал мне, что хочет пойти на этот курс от Прометеуса (CS50: Основы программирования), ищет единомышленников (❗️). Курс бесплатный, свежий, українською мовою (есть и оригинал на английском). Я глянул описание, меня зацепила эта фраза "Практические задания курса базируются на реальных кейсах со сфер биологии, криптографии, финансов, судебно-медицинской экспертизы и разработки игр". Впервые вижу в этом уютном мирке кодинга судебно-медицинскую экспертизу (🍖)... И вот я подумал: а вдруг юристам понравится?
💬 В общем, можете найтись и скооперироваться в комментариях)
#курс #CS50
По стилю изложения можно обозначить такие две полярные группы, на отрезке между которыми расположены любые материалы по изучению программирования:
📄 Классика, где излагается сухая теория и при крайней необходимости приводятся скудные примеры. Встречаются практически такие же многоэтажные обороты, как и у юристов. О пороге входа автор часто не заботится: "либо вникай, либо проваливай". Это чаще книги и статьи на Википедии, чем видео.
🍿 Нечто необычное, где примеры зачастую опережают определения; примеры вполне понятны и связаны с бытом; даже есть некая доля юмора. Низкий порог входа. Это чаще видео (или живой перфоманс, который потом шерится как видео) и какие-то интерактивные штуки. Ну и этот телеграм-канал я стараюсь вести в таком ключе.
С чего начинать, тут на самом деле каждый для себя может решить. Если у вас научный бэкграунд или вы просто любите сложные тексты, то первая группа поможет хорошо углубиться и далеко пройти. Что же насчёт второй группы, то я не смотрел много видосов, но меня в своё время впечатлил видеокурс от CS50 на YouTube (вот, например, первая лекция). Они с потрясающим цинизмом помогают понять разные непростые явления в кодинге и вообще логику работы ЭВМ.
📨 Один подписчик написал мне, что хочет пойти на этот курс от Прометеуса (CS50: Основы программирования), ищет единомышленников (❗️). Курс бесплатный, свежий, українською мовою (есть и оригинал на английском). Я глянул описание, меня зацепила эта фраза "Практические задания курса базируются на реальных кейсах со сфер биологии, криптографии, финансов, судебно-медицинской экспертизы и разработки игр". Впервые вижу в этом уютном мирке кодинга судебно-медицинскую экспертизу (🍖)... И вот я подумал: а вдруг юристам понравится?
💬 В общем, можете найтись и скооперироваться в комментариях)
#курс #CS50
Первое ЗАДАНИЕ на канале!
... а что же ещё делает кодера сильным?
💭 В программировании очень важно понимать, как ваши слова, которыми вы описываете ещё не созданную технологию/продукт, превращать в итоговый код. Умение это делать быстро и с первого раза приходит со временем. Ранее, в этом посте я показал, как бытовушное описание через логическое описание эволюционирует в псевдокод (а из псевдокода уже легко выйти в конкретный код). Это очень важная последовательность для новичка.
💡 До меня это дошло, когда на курсах задали на дом написать код, который определяет, является ли любое введённое число палиндромом. Когда я пытался мыслить сразу программным кодом, никак не получалось. И так, и сяк — не получалось. Когда же взял и расписал необходимые действия (логику) пошагово, внезапно стало ясно, как из этого выстроить победный код.
🖊 Поэтому сейчас предлагаю вам задачу: какие инструкции нужно дать компьютеру, чтобы он мог сказать про любое число, является ли оно палиндромом? Кстати, вот палиндромы: 212, 55, 88488, а вот непалиндромы: 122, 56, 84888. Пока не нужно писать код. Сначала нужно просто объяснить себе словами необходимую последовательность действий. Здесь зарыто 80% успеха.
У вас для этого есть такие инструменты:
▪️ в любой момент можете запоминать любые значения, полученные вами, включая полученное на старте число;
▪️ в любой момент можете проверить что-либо на истинность или ложность перед тем, как выполнить какое-нибудь действие;
▪️ в любой момент можете сравнивать числа, проводить математические операции, округлять, брать остаток от деления;
▪️ можете повторять одни и те же действия (включая вышеперечисленные) некоторое количество раз или пока не изменится некоторое обстоятельство (то есть создавать циклы).
🌱 Согласен, палиндромы далеки от юриспруденции, но это будет очень показательно для тех, кто проникнется. Для меня это задание стало точкой роста. И, разумеется, не стоит гуглить решение. :) Сила приходит с ̶с̶т̶р̶а̶д̶а̶н̶и̶е̶м̶ усилиями.
Методику решения такой задачи опубликую в понедельник.
#мясо #задание #палиндром
... а что же ещё делает кодера сильным?
💭 В программировании очень важно понимать, как ваши слова, которыми вы описываете ещё не созданную технологию/продукт, превращать в итоговый код. Умение это делать быстро и с первого раза приходит со временем. Ранее, в этом посте я показал, как бытовушное описание через логическое описание эволюционирует в псевдокод (а из псевдокода уже легко выйти в конкретный код). Это очень важная последовательность для новичка.
💡 До меня это дошло, когда на курсах задали на дом написать код, который определяет, является ли любое введённое число палиндромом. Когда я пытался мыслить сразу программным кодом, никак не получалось. И так, и сяк — не получалось. Когда же взял и расписал необходимые действия (логику) пошагово, внезапно стало ясно, как из этого выстроить победный код.
🖊 Поэтому сейчас предлагаю вам задачу: какие инструкции нужно дать компьютеру, чтобы он мог сказать про любое число, является ли оно палиндромом? Кстати, вот палиндромы: 212, 55, 88488, а вот непалиндромы: 122, 56, 84888. Пока не нужно писать код. Сначала нужно просто объяснить себе словами необходимую последовательность действий. Здесь зарыто 80% успеха.
У вас для этого есть такие инструменты:
▪️ в любой момент можете запоминать любые значения, полученные вами, включая полученное на старте число;
▪️ в любой момент можете проверить что-либо на истинность или ложность перед тем, как выполнить какое-нибудь действие;
▪️ в любой момент можете сравнивать числа, проводить математические операции, округлять, брать остаток от деления;
▪️ можете повторять одни и те же действия (включая вышеперечисленные) некоторое количество раз или пока не изменится некоторое обстоятельство (то есть создавать циклы).
🌱 Согласен, палиндромы далеки от юриспруденции, но это будет очень показательно для тех, кто проникнется. Для меня это задание стало точкой роста. И, разумеется, не стоит гуглить решение. :) Сила приходит с ̶с̶т̶р̶а̶д̶а̶н̶и̶е̶м̶ усилиями.
Методику решения такой задачи опубликую в понедельник.
#мясо #задание #палиндром
🗝 Подсказка к задаче палиндрома
Есть в языках программирования такая штука, как деление с остатком, а то, что мы с его помощью делаем, называется взятие остатка или деление по модулю. Оно выводит либо остаток, который возникает при делении чисел, либо ноль.
🐗 Я условно стал называть это пятым арифметическим действием (вот же неграмотный!), потому что в трёх моих любимых языках программирования (JavaScript, PHP и Python) оно записывается при помощи знака "%":
4 % 2 = 0, потому что 4 / 2 = 2, то есть в остатке ноль,
5 % 2 = 1, потому что 5 / 2 = 2 и в остаток идёт единица.
Зачем выделили под это отдельный знак? Ну, в коде проще записать result = 5 % 2; , чем:
1) result = 5 - 5 / 2 * 2, если деление целых чисел не приводит к получению дробного результата;
2) result = 5 - floor( 5 / 2 ) * 2, если появляется дробный результат, который нужно округлить.
🔎 Зачем это нужно и как это поможет решить задачу палиндрома?
У взятия остатка есть прекрасное свойство, благодаря которому можно легко получить последнюю цифру числа, поделив его с остатком на 10. Например, 245 % 10 = 5, 248 % 10 = 8. То есть это значит, что проблема вычленения нужной цифры — это не проблема.
А ещё деление с остатком на 2 позволяет определить, является число чётным или нечётным:
5 % 2 = 1, 7 % 2 = 1, 131 % 2 = 1, то есть нечётные числа всегда продуцируют единицу;
4 % 2 = 0; 6 % 2 = 0; 132 % 2 = 0, то есть чётные числа всегда продуцируют ноль.
Ещё подсказка: исходите из определения палиндрома и тех его свойств, которые из этого вытекают.
Как успехи с палиндромом?)
🆗 — что-то есть; ⛔️ — не хочу
Есть в языках программирования такая штука, как деление с остатком, а то, что мы с его помощью делаем, называется взятие остатка или деление по модулю. Оно выводит либо остаток, который возникает при делении чисел, либо ноль.
🐗 Я условно стал называть это пятым арифметическим действием (вот же неграмотный!), потому что в трёх моих любимых языках программирования (JavaScript, PHP и Python) оно записывается при помощи знака "%":
4 % 2 = 0, потому что 4 / 2 = 2, то есть в остатке ноль,
5 % 2 = 1, потому что 5 / 2 = 2 и в остаток идёт единица.
Зачем выделили под это отдельный знак? Ну, в коде проще записать result = 5 % 2; , чем:
1) result = 5 - 5 / 2 * 2, если деление целых чисел не приводит к получению дробного результата;
2) result = 5 - floor( 5 / 2 ) * 2, если появляется дробный результат, который нужно округлить.
🔎 Зачем это нужно и как это поможет решить задачу палиндрома?
У взятия остатка есть прекрасное свойство, благодаря которому можно легко получить последнюю цифру числа, поделив его с остатком на 10. Например, 245 % 10 = 5, 248 % 10 = 8. То есть это значит, что проблема вычленения нужной цифры — это не проблема.
А ещё деление с остатком на 2 позволяет определить, является число чётным или нечётным:
5 % 2 = 1, 7 % 2 = 1, 131 % 2 = 1, то есть нечётные числа всегда продуцируют единицу;
4 % 2 = 0; 6 % 2 = 0; 132 % 2 = 0, то есть чётные числа всегда продуцируют ноль.
Ещё подсказка: исходите из определения палиндрома и тех его свойств, которые из этого вытекают.
Как успехи с палиндромом?)
🆗 — что-то есть; ⛔️ — не хочу
💠 Решение задачи с палиндромом
1. Смотрим внимательно дефиниции/свойства, чтобы найти зацепки: палиндром (число) — это число, которое читается одинаково в обоих направлениях, то есть которое будет равно числу, составленному из его цифр задом наперёд. Значит, его последняя цифра равна первой, предпоследняя — второй и т.д. И это правило соблюдается вплоть до центра этого числа, которым может быть одинокая цифра (212, 151, 11011) или же пара цифр (1221, 338833). Итак, мы можем сравнивать поочерёдно первую и последнюю цифры, а затем откидывать их... Но стоп... Кажется, я зашёл слишком далеко. Вернусь в начало.
2. ... читается одинаково в обоих направлениях. Значит, нужно записать его (далее — Старое число) задом наперёд, получив таким образом его зеркальное отражение (далее — Новое число) и сравнить их. Как это сделать? Проговариваю буквально:
0️⃣ буду оперировать Старым и Новым числами;
1️⃣ беру последнюю цифру Старого числа;
2️⃣ прибавляю её к телу Нового числа;
3️⃣ выкидываю её из Старого числа;
🔁 повторяю действия 1️⃣, 2️⃣, 3️⃣, пока в Старом числе не иссякнут цифры;
4️⃣ сравниваю Старое и Новое числа: если они равны, то это палиндром.
3. Вот воплощение этого алгоритма в виде кода на JavaScript:
0️⃣ let numberOldTest = numberOld;
let numberNew = 0; (подготовительная стадия, необходимая для работы)
🔁 while( numberOldTest > 0 ){
1️⃣ digitLast = numberOldTest % 10; (вот к чему относится вчерашняя подсказка)
2️⃣ numberNew = numberNew * 10 + digitLast; (чтобы цифры не суммировались арифметически, нужно повышать разряд числа, умножая основу на 10)
3️⃣ numberOldTest = Math.floor( numberOldTest / 10 ); (тут нужно округлять вниз, чтоб избавиться от дроби)
}
4️⃣ if( numberOld == numberNew ){ alert("это палиндром"); }
Вот и всё. А ведь я на старте чуть не переусложнил решение задачи. Ведь также можно путём математических ухищрений брать первую и последнюю цифры Старого числа и сравнивать их. Затем, если они равны, отбрасывать их (опять-таки, первую сложнее отбросить). И так двигаться до середины числа. И ещё нужно учитывать, что число может состоять как с парного, так и непарного количества цифр. А ещё есть и другие математические способы, просто логика работы и код будут сложнее.
А что получилось у вас? Было ли полезно?
1. Смотрим внимательно дефиниции/свойства, чтобы найти зацепки: палиндром (число) — это число, которое читается одинаково в обоих направлениях, то есть которое будет равно числу, составленному из его цифр задом наперёд. Значит, его последняя цифра равна первой, предпоследняя — второй и т.д. И это правило соблюдается вплоть до центра этого числа, которым может быть одинокая цифра (212, 151, 11011) или же пара цифр (1221, 338833). Итак, мы можем сравнивать поочерёдно первую и последнюю цифры, а затем откидывать их... Но стоп... Кажется, я зашёл слишком далеко. Вернусь в начало.
2. ... читается одинаково в обоих направлениях. Значит, нужно записать его (далее — Старое число) задом наперёд, получив таким образом его зеркальное отражение (далее — Новое число) и сравнить их. Как это сделать? Проговариваю буквально:
0️⃣ буду оперировать Старым и Новым числами;
1️⃣ беру последнюю цифру Старого числа;
2️⃣ прибавляю её к телу Нового числа;
3️⃣ выкидываю её из Старого числа;
🔁 повторяю действия 1️⃣, 2️⃣, 3️⃣, пока в Старом числе не иссякнут цифры;
4️⃣ сравниваю Старое и Новое числа: если они равны, то это палиндром.
3. Вот воплощение этого алгоритма в виде кода на JavaScript:
0️⃣ let numberOldTest = numberOld;
let numberNew = 0; (подготовительная стадия, необходимая для работы)
🔁 while( numberOldTest > 0 ){
1️⃣ digitLast = numberOldTest % 10; (вот к чему относится вчерашняя подсказка)
2️⃣ numberNew = numberNew * 10 + digitLast; (чтобы цифры не суммировались арифметически, нужно повышать разряд числа, умножая основу на 10)
3️⃣ numberOldTest = Math.floor( numberOldTest / 10 ); (тут нужно округлять вниз, чтоб избавиться от дроби)
}
4️⃣ if( numberOld == numberNew ){ alert("это палиндром"); }
Вот и всё. А ведь я на старте чуть не переусложнил решение задачи. Ведь также можно путём математических ухищрений брать первую и последнюю цифры Старого числа и сравнивать их. Затем, если они равны, отбрасывать их (опять-таки, первую сложнее отбросить). И так двигаться до середины числа. И ещё нужно учитывать, что число может состоять как с парного, так и непарного количества цифр. А ещё есть и другие математические способы, просто логика работы и код будут сложнее.
А что получилось у вас? Было ли полезно?
Первый короткий пост на канале: ОПРОС
🏔 Народ, контента много и его ещё можно создавать и создавать, ибо право и программирование — это две очень благодатные нивы, полные загадок и свершений. Перед тем, как самозабвенно упарываться дальше, мне ценно услышать, что вас сейчас интересует больше всего:
1) элементы сугубо кодинга: переменные, классы, циклы, обработка ошибок, виды ошибок, отладчики и прочее;
2) алгоритмизация правовых процессов — примеры, подходы, идеи и прочее;
3) какие-то истории, факапы, личный опыт.
P.S. Очень круто, что всё больше людей начинает комментировать происходящее, причём приводя свои решения в виде кода. Давайте продолжать. 🎉
Пишите в комменты )
#опрос
🏔 Народ, контента много и его ещё можно создавать и создавать, ибо право и программирование — это две очень благодатные нивы, полные загадок и свершений. Перед тем, как самозабвенно упарываться дальше, мне ценно услышать, что вас сейчас интересует больше всего:
1) элементы сугубо кодинга: переменные, классы, циклы, обработка ошибок, виды ошибок, отладчики и прочее;
2) алгоритмизация правовых процессов — примеры, подходы, идеи и прочее;
3) какие-то истории, факапы, личный опыт.
P.S. Очень круто, что всё больше людей начинает комментировать происходящее, причём приводя свои решения в виде кода. Давайте продолжать. 🎉
Пишите в комменты )
#опрос
КАК Я ВОШЁЛ В АЙТИ.
ЧАСТЬ 1. Игрульки и отказ от юридических тасков. 🤓
Спасибо за комментарии! Окей, расскажу сначала немного о своём бэкграунде.
🐣 Если не считать Pascal в лицее и немножко C++ на курсах (где вершиной моего познания стал палиндром и вложенные циклы для решения двумерных задач), то вменяемо программировать я начал в программе для ... создания игр. Это Construct 2, в ней практически не нужно писать код, вместо этого из блоков выстраиваются схемы по типу "событие — действие", "событие — проверка условий — действие" и т.д. То есть изначально я (наверное, как и многие), хотел создавать свои игры, это была реальная мотивация забивать свою голову всякой дичью в виде оптимизации, совместимости, компиляции и прочего. Но до конца я (наверное, как и многие) ни один проект не довёл, у меня там накопилось где-то 15 заготовок. Причём под конец я начал экспериментировать и смешивать жанры, например "тетрис-теннис с элементами RPG в духе World of Warcraft". Кстати, заниматься этим было особенно интересно во время унылых лекций на юрфаке.
🗽 После стажировки в юрфирме Axon Partners в конце 2016-го я обнаглел настолько, что предложил заняться лигалтеком прямо под Новый год, хотя ещё плохо понимал, что это такое (и вообще ещё не было решено, будут ли со мной сотрудничать дальше). И когда решили-таки сотрудничать, самое прикольное то, что первые три лигалтек-проекта я делал в этой программе аж до сентября 2017-го, нагло симулируя с её помощью веб-сайты. Она поддерживала компиляцию в html-файлы, но там были проблемы с вёрсткой, которые я не мог преодолеть, потому что а) не знал HTML и б) кое-что нельзя было преодолеть. Поэтому первые три лигалтек-проекта были уродливы, как не знаю что.
🥀 Итак, благодаря Construct 2 я почти сразу смог отказаться от юридических тасков в Аксоне. Почти сразу, потому что какой-то стрёмный рисёрч успел оставить легалистский шрам в моей душе. И спустя две-три недели Дима Гадомский вручил мне лигалинженерскую рясу, которую я ношу и по сей день. Дальше расскажу о том, какой язык программирования стал моим первым рабочим.
ЧАСТЬ 1. Игрульки и отказ от юридических тасков. 🤓
Спасибо за комментарии! Окей, расскажу сначала немного о своём бэкграунде.
🐣 Если не считать Pascal в лицее и немножко C++ на курсах (где вершиной моего познания стал палиндром и вложенные циклы для решения двумерных задач), то вменяемо программировать я начал в программе для ... создания игр. Это Construct 2, в ней практически не нужно писать код, вместо этого из блоков выстраиваются схемы по типу "событие — действие", "событие — проверка условий — действие" и т.д. То есть изначально я (наверное, как и многие), хотел создавать свои игры, это была реальная мотивация забивать свою голову всякой дичью в виде оптимизации, совместимости, компиляции и прочего. Но до конца я (наверное, как и многие) ни один проект не довёл, у меня там накопилось где-то 15 заготовок. Причём под конец я начал экспериментировать и смешивать жанры, например "тетрис-теннис с элементами RPG в духе World of Warcraft". Кстати, заниматься этим было особенно интересно во время унылых лекций на юрфаке.
🗽 После стажировки в юрфирме Axon Partners в конце 2016-го я обнаглел настолько, что предложил заняться лигалтеком прямо под Новый год, хотя ещё плохо понимал, что это такое (и вообще ещё не было решено, будут ли со мной сотрудничать дальше). И когда решили-таки сотрудничать, самое прикольное то, что первые три лигалтек-проекта я делал в этой программе аж до сентября 2017-го, нагло симулируя с её помощью веб-сайты. Она поддерживала компиляцию в html-файлы, но там были проблемы с вёрсткой, которые я не мог преодолеть, потому что а) не знал HTML и б) кое-что нельзя было преодолеть. Поэтому первые три лигалтек-проекта были уродливы, как не знаю что.
🥀 Итак, благодаря Construct 2 я почти сразу смог отказаться от юридических тасков в Аксоне. Почти сразу, потому что какой-то стрёмный рисёрч успел оставить легалистский шрам в моей душе. И спустя две-три недели Дима Гадомский вручил мне лигалинженерскую рясу, которую я ношу и по сей день. Дальше расскажу о том, какой язык программирования стал моим первым рабочим.
КАК Я ВОШЁЛ В АЙТИ.
ЧАСТЬ 2. Первые три проекта и первый язык программирования. 😎
🗺 1-й проект: им стала интерактивная юридическая карта мира для разных видов бизнеса с фильтрацией по налогам, условиям открытия и поддержания компаний и т.д. Через две недели я принёс прототип в Construct 2, мы начали его наполнять содержимым и экспериментировать. Тут не требовалось никакого сложного программирования, просто распределение данных по группам и их визуальное представление. Но внезапно мы этот проект отложили в сторону, потому что переключились на второй.
🧟♂️ 2-й проект: когда Google объявили, что будут баниться приложения, не имеющие политики приватности, мы сразу же взялись решить эту проблему. За три дня сделали конструктор политик приватности, один из первых вебботов украинского лигалтека — Privacy Policy Bot, он же Франк. Запустили 13 февраля 2017. Он выглядел страшно, в первый день на нём подвисали кнопки, но он работал. Через несколько дней мы выпустили апдейт, в котором вы могли этот же документ получить в фановом виде: он был напикан шутками на английском языке, которые не исключали его юридическое значение. В эти дни я узнал, что такое хостинг и как его настраивать, а также понял, что на первом месте должна быть безотказность софта, а уже затем красивенькие анимации.
🛠 3-й проект: когда подошло время вернуться к 1-му проекту, Дима Гадомский поинтересовался, смогу ли я сделать конструктор таких ботов, как Франк, чтобы и другие юристы могли клепать такие вещи. Я написал в чате, что подумаю. Через 40 минут я сказал, что это возможно. В этот же день началась разработка, растянувшаяся на полгода. Через несколько дней наткнулся на проблему сохранения пользовательских данных на сервере. И вот на форуме Construct 2 нахожу инструкцию о том, как должен выглядеть делающий это скрипт на PHP. Вот так вопрос выбора языка программирования для дальнейшей работы решился сам собой. А к первому проекту мы так и не вернулись.
ЧАСТЬ 2. Первые три проекта и первый язык программирования. 😎
🗺 1-й проект: им стала интерактивная юридическая карта мира для разных видов бизнеса с фильтрацией по налогам, условиям открытия и поддержания компаний и т.д. Через две недели я принёс прототип в Construct 2, мы начали его наполнять содержимым и экспериментировать. Тут не требовалось никакого сложного программирования, просто распределение данных по группам и их визуальное представление. Но внезапно мы этот проект отложили в сторону, потому что переключились на второй.
🧟♂️ 2-й проект: когда Google объявили, что будут баниться приложения, не имеющие политики приватности, мы сразу же взялись решить эту проблему. За три дня сделали конструктор политик приватности, один из первых вебботов украинского лигалтека — Privacy Policy Bot, он же Франк. Запустили 13 февраля 2017. Он выглядел страшно, в первый день на нём подвисали кнопки, но он работал. Через несколько дней мы выпустили апдейт, в котором вы могли этот же документ получить в фановом виде: он был напикан шутками на английском языке, которые не исключали его юридическое значение. В эти дни я узнал, что такое хостинг и как его настраивать, а также понял, что на первом месте должна быть безотказность софта, а уже затем красивенькие анимации.
🛠 3-й проект: когда подошло время вернуться к 1-му проекту, Дима Гадомский поинтересовался, смогу ли я сделать конструктор таких ботов, как Франк, чтобы и другие юристы могли клепать такие вещи. Я написал в чате, что подумаю. Через 40 минут я сказал, что это возможно. В этот же день началась разработка, растянувшаяся на полгода. Через несколько дней наткнулся на проблему сохранения пользовательских данных на сервере. И вот на форуме Construct 2 нахожу инструкцию о том, как должен выглядеть делающий это скрипт на PHP. Вот так вопрос выбора языка программирования для дальнейшей работы решился сам собой. А к первому проекту мы так и не вернулись.
Надёжные способы автоматизировать создание документов
Способ 1. Заполнение шаблонов. 📇
Второй и третий проекты с прошлого поста дали мне знать, что есть два эффективных подхода к подготовке документов при помощи алгоритмов.
Заполнение шаблонов — до боли знакомая ситуация. Допустим, у вас есть готовый шаблон какого-то документа. Чтобы пустить его в дело, достаточно заполнить какие-то индивидуальные данные. Например: шаблоны заявлений в универе; договоры, которые вам подсовывают в банках; акты приёма-передачи результатов услуг и т.д. Чаще всего вписываем туда наименования, контакты, даты, суммы и т.д.
🎮 Автоматизировать такое до неприличия просто:
1. В нужных местах шаблона ставим некие уникальные метки, которые не используются нигде в тексте (например: $name$, $date$, %sumOfMoney%, goodsQuantity).
2. Создаём опросник (можно и в виде чат-бота), где ответами на вопросы являются те данные, которые нам нужно вставить в документ ("Укажите фамилию и инициалы покупателя");
3. Подменяем каждую метку на каждый полученный ответ (таким образом, какой-нибудь "Шпак И.С." заменит собой какую-нибудь метку $nameOfBuyer$);
Чё ещё можно с этим сделать?
🔹 Одна и та же метка может встречаться несколько раз в разных местах документа (например, если наименование контрагента вы хотите разместить в начале и в конце договора).
🔹 Разумеется, между опросником и подменой меток можно втулить ещё алгоритм, который будет производить дополнительные операции над данными: преобразование, дополнение, обрезка и т.д. (например, дробные числа округлять вверх, когда речь идёт о ценах и вы хотите исключить копейки).
🔹 Метку можно заполнить ничем, чтобы она исчезла, если по выбранному юзером сценарию какое-то поле нужно оставить пустым (пустота в этом случае выглядит так: "", '').
🔹 Можно сделать так, что какие-то данные в документе будут формироваться на основе ответов, а не напрямую из них (например, в опроснике юзер выбрал опцию "плачу долларами", и вы добавляете к указанной денежной сумме словесное обозначение долларов).
🌆 Используя такой алгоритм, можно заполнять несколько сотен шаблонов за несколько секунд, если у вас уже есть таблица с нужными данными. Или всё-таки лучше делать это вручную полтора рабочих дня, наслаждаясь спокойствием профессии и слушая город за окном?
А вы когда-нибудь пользовались подобными опросниками?
Или создавали свои?
#шаблон #алгоритмизация #документ
Способ 1. Заполнение шаблонов. 📇
Второй и третий проекты с прошлого поста дали мне знать, что есть два эффективных подхода к подготовке документов при помощи алгоритмов.
Заполнение шаблонов — до боли знакомая ситуация. Допустим, у вас есть готовый шаблон какого-то документа. Чтобы пустить его в дело, достаточно заполнить какие-то индивидуальные данные. Например: шаблоны заявлений в универе; договоры, которые вам подсовывают в банках; акты приёма-передачи результатов услуг и т.д. Чаще всего вписываем туда наименования, контакты, даты, суммы и т.д.
🎮 Автоматизировать такое до неприличия просто:
1. В нужных местах шаблона ставим некие уникальные метки, которые не используются нигде в тексте (например: $name$, $date$, %sumOfMoney%, goodsQuantity).
2. Создаём опросник (можно и в виде чат-бота), где ответами на вопросы являются те данные, которые нам нужно вставить в документ ("Укажите фамилию и инициалы покупателя");
3. Подменяем каждую метку на каждый полученный ответ (таким образом, какой-нибудь "Шпак И.С." заменит собой какую-нибудь метку $nameOfBuyer$);
Чё ещё можно с этим сделать?
🔹 Одна и та же метка может встречаться несколько раз в разных местах документа (например, если наименование контрагента вы хотите разместить в начале и в конце договора).
🔹 Разумеется, между опросником и подменой меток можно втулить ещё алгоритм, который будет производить дополнительные операции над данными: преобразование, дополнение, обрезка и т.д. (например, дробные числа округлять вверх, когда речь идёт о ценах и вы хотите исключить копейки).
🔹 Метку можно заполнить ничем, чтобы она исчезла, если по выбранному юзером сценарию какое-то поле нужно оставить пустым (пустота в этом случае выглядит так: "", '').
🔹 Можно сделать так, что какие-то данные в документе будут формироваться на основе ответов, а не напрямую из них (например, в опроснике юзер выбрал опцию "плачу долларами", и вы добавляете к указанной денежной сумме словесное обозначение долларов).
🌆 Используя такой алгоритм, можно заполнять несколько сотен шаблонов за несколько секунд, если у вас уже есть таблица с нужными данными. Или всё-таки лучше делать это вручную полтора рабочих дня, наслаждаясь спокойствием профессии и слушая город за окном?
А вы когда-нибудь пользовались подобными опросниками?
Или создавали свои?
#шаблон #алгоритмизация #документ
👁 Вычислительное право — выдумка бородачей в свитерах или ...
Вчера прошёл Computational Law & Blockchain Festival наконец и в Киеве, вот видеозапись. Мне очень понравилась презентация Егора Чурилова о вычислительном праве (см. ниже фото одного из слайдов). Кажется, мы сейчас пытаемся перевести наши правовые системы с третьего этапа (дигитализация) на четвёртый (онтологизация/семантизация), хотя в некоторых вопросах ещё застряли и на втором (механизация). В причинах такого пробуксовывания пытались разобраться на последующей панельной дискуссии.
Вот какие микровыводы для себя сделал:
▪️ Digital by default — не шутка, мы всерьёз собираемся двигать общество и право к цифровизации.
▪️ Кибернетики создали разные способы/модели представления человеческого знания (и юридических законов) в цифровом виде, так что у нас даже есть из чего выбирать.
▪️ Но переход не будет резким, привычки менять сложно, поэтому будем расходовать много бумаги ещё некоторое количество лет.
▪️ Технологии можно делать как прозрачными, так и не прозрачными. Но компьютеру всё равно проще логировать свои действия и отчитываться за них, чем судье-человеку, который даже не догадывается, что в послеобеденное время он склонен выносить более мягкие (и даже оправдательные) приговоры (спасибо Егору за классный пример).
▪️ Юристов digital by default и его последствия не вытеснят в один конкретный день, но это не повод его игнорировать. Эта профессия в плане инструментов и образа действий в следующие годы будет меняться значительно быстрее, чем за последние 100 лет. Но лигалхакеры всего мира помогут не потеряться в ворохе технологий и найти себя.
Вчера прошёл Computational Law & Blockchain Festival наконец и в Киеве, вот видеозапись. Мне очень понравилась презентация Егора Чурилова о вычислительном праве (см. ниже фото одного из слайдов). Кажется, мы сейчас пытаемся перевести наши правовые системы с третьего этапа (дигитализация) на четвёртый (онтологизация/семантизация), хотя в некоторых вопросах ещё застряли и на втором (механизация). В причинах такого пробуксовывания пытались разобраться на последующей панельной дискуссии.
Вот какие микровыводы для себя сделал:
▪️ Digital by default — не шутка, мы всерьёз собираемся двигать общество и право к цифровизации.
▪️ Кибернетики создали разные способы/модели представления человеческого знания (и юридических законов) в цифровом виде, так что у нас даже есть из чего выбирать.
▪️ Но переход не будет резким, привычки менять сложно, поэтому будем расходовать много бумаги ещё некоторое количество лет.
▪️ Технологии можно делать как прозрачными, так и не прозрачными. Но компьютеру всё равно проще логировать свои действия и отчитываться за них, чем судье-человеку, который даже не догадывается, что в послеобеденное время он склонен выносить более мягкие (и даже оправдательные) приговоры (спасибо Егору за классный пример).
▪️ Юристов digital by default и его последствия не вытеснят в один конкретный день, но это не повод его игнорировать. Эта профессия в плане инструментов и образа действий в следующие годы будет меняться значительно быстрее, чем за последние 100 лет. Но лигалхакеры всего мира помогут не потеряться в ворохе технологий и найти себя.
Надёжные способы автоматизировать создание документов
Способ 2. Соединение блоков. 🍢
Выше я рассказал о том, как заполнять шаблоны. Но это весьма тривиальная задача. Нередко структура и содержание документа должны различаться зависимо от ситуации клиента. И тут мы приходим к тому, что документ нужно строить из отдельных блоков, которые должны подставляться зависимо от полученных ответов.
Простая ситуация: задаём 3 вопроса подряд, на каждый из них даётся по 2 ответа, и каждый ответ связан с неким блоком текста, который должен подставиться в документ. У нас в Axon Partners такое было с тем самым Privacy Policy Bot, только там таких вопросов было около двенадцати. И на этой же идее я строил тот самый конструктор ботов, где можно было создать до 15-и вопросов с 4-мя возможными ответами.
🎲 Выходит, потенциально количество вариаций такого документа будет равно произведению сумм ответов по каждому вопросу: 2 х 2 х 2 = 8. И вам как юристу на этапе создания и тестирования такого конструктора необходимо убедиться, что все эти вариации жизнеспособны и не противоречивы: например, что блок из ответа №1 на вопрос №1 совместим с блоком из ответа №2 на вопрос №3 и т.д. Поэтому такое конструирование документа лучше подходит для консультаций, справок и некоторых "блочных" документов по типу несложных политик приватности. Ведь договоры обычно имеют более сложную логику, хотя при некоторой ловкости можно что-то эдакое сотворить и с ними.
И конечно же, при необходимости блок можно сделать пустым.
Способ 2. Соединение блоков. 🍢
Выше я рассказал о том, как заполнять шаблоны. Но это весьма тривиальная задача. Нередко структура и содержание документа должны различаться зависимо от ситуации клиента. И тут мы приходим к тому, что документ нужно строить из отдельных блоков, которые должны подставляться зависимо от полученных ответов.
Простая ситуация: задаём 3 вопроса подряд, на каждый из них даётся по 2 ответа, и каждый ответ связан с неким блоком текста, который должен подставиться в документ. У нас в Axon Partners такое было с тем самым Privacy Policy Bot, только там таких вопросов было около двенадцати. И на этой же идее я строил тот самый конструктор ботов, где можно было создать до 15-и вопросов с 4-мя возможными ответами.
🎲 Выходит, потенциально количество вариаций такого документа будет равно произведению сумм ответов по каждому вопросу: 2 х 2 х 2 = 8. И вам как юристу на этапе создания и тестирования такого конструктора необходимо убедиться, что все эти вариации жизнеспособны и не противоречивы: например, что блок из ответа №1 на вопрос №1 совместим с блоком из ответа №2 на вопрос №3 и т.д. Поэтому такое конструирование документа лучше подходит для консультаций, справок и некоторых "блочных" документов по типу несложных политик приватности. Ведь договоры обычно имеют более сложную логику, хотя при некоторой ловкости можно что-то эдакое сотворить и с ними.
И конечно же, при необходимости блок можно сделать пустым.
26-й день: запуск чатов! 👁🗨
Друзья, вот нас и стало уже 500! Очень благодарен всем, кто шерит канал. :) Заменяя неудобный интерфейс комментариев, запускаю целых два чата для желающих:
🗯 Common Chat, чтобы обсуждать контент и вообще тематику канала, а именно – более "гуманитарные" и "стратегические" вопросы.
💬 Coder Chat, чтобы обсуждать сугубо кодерские вопросы и, взаимопомогая, забрасывать друг друга кусками кода, осколками конструктивной критики и полезными материалами.
Завтра продолжаю своё повествование. А пока что зацените скриншот альфа версии нашего первого опубликованного лигалтек-продукта в феврале 2017-го. К чему я? Не нужно бояться, что без профессионального дизайнера у вас на старте получится антикрасивый интерфейс. В лигалтеке главное — нутро продукта: его движок, логика и функционал. Считаю, что юрист не обязан ещё и дизайнить. Это можно оставить людям с профессиональным чувством прекрасного. 🎨 Поэтому главное требование к лигалинженерам — хотя бы тексты сделать читабельными.
Друзья, вот нас и стало уже 500! Очень благодарен всем, кто шерит канал. :) Заменяя неудобный интерфейс комментариев, запускаю целых два чата для желающих:
🗯 Common Chat, чтобы обсуждать контент и вообще тематику канала, а именно – более "гуманитарные" и "стратегические" вопросы.
💬 Coder Chat, чтобы обсуждать сугубо кодерские вопросы и, взаимопомогая, забрасывать друг друга кусками кода, осколками конструктивной критики и полезными материалами.
Завтра продолжаю своё повествование. А пока что зацените скриншот альфа версии нашего первого опубликованного лигалтек-продукта в феврале 2017-го. К чему я? Не нужно бояться, что без профессионального дизайнера у вас на старте получится антикрасивый интерфейс. В лигалтеке главное — нутро продукта: его движок, логика и функционал. Считаю, что юрист не обязан ещё и дизайнить. Это можно оставить людям с профессиональным чувством прекрасного. 🎨 Поэтому главное требование к лигалинженерам — хотя бы тексты сделать читабельными.
Надёжные способы автоматизировать создание документов
Способ 3. Шабменты или фраглоны. 🏈
Разумеется, на практике при создании документов (особенно договоров, актов, заявлений и т.д.) приходится комбинировать способ 1 и способ 2. То есть и данные от юзера напрямую вносить (имена, даты, адреса, номера, суммы и т.д), и какие-то блоки подставлять. Логику процесса я изобразил на картинке ниже.
Обратите внимание, что данные юзера можно вносить как в статичную ("чёрную") часть документа ("желтый" ответ), так и в сами фрагменты ("красный" ответ). Причём порядок действий по такой схеме не имеет значения, хотя с точки зрения оптимизации стоит вносить данные клиента в уже выбранный (используемый) фрагмент.
🧩 То есть на нижнем уровне эти фрагменты ("зелёные") сами становятся шаблонами. В кодинге нередко можно столкнуться с такой многоуровневостью, пошаговостью. Поэтому-то умение мыслить пошагово довольно важно.
Способ 3. Шабменты или фраглоны. 🏈
Разумеется, на практике при создании документов (особенно договоров, актов, заявлений и т.д.) приходится комбинировать способ 1 и способ 2. То есть и данные от юзера напрямую вносить (имена, даты, адреса, номера, суммы и т.д), и какие-то блоки подставлять. Логику процесса я изобразил на картинке ниже.
Обратите внимание, что данные юзера можно вносить как в статичную ("чёрную") часть документа ("желтый" ответ), так и в сами фрагменты ("красный" ответ). Причём порядок действий по такой схеме не имеет значения, хотя с точки зрения оптимизации стоит вносить данные клиента в уже выбранный (используемый) фрагмент.
🧩 То есть на нижнем уровне эти фрагменты ("зелёные") сами становятся шаблонами. В кодинге нередко можно столкнуться с такой многоуровневостью, пошаговостью. Поэтому-то умение мыслить пошагово довольно важно.
