Прям лонг рид описывающий существующие модели ошибок в ЯП, и подход выбранный в экспериментальном ЯП для экспреминтальной ОС от МС.

ну и главный посыл: нужно 2 механизма - незаметный фейл фаст для багов и заметный для ошибок в окружении

http://joeduffyblog.com/2016/02/07/the-error-model/

#ergo_approach@ergonomic_code #error_handling@ergonomic_code

Kotlin Result DSL

Эдит: вариант для чтения на мобилках

И кстати в догонку про обработку ошибок.

Я в своё время прям сильно впечатлился Rust-овским try! (Который уже оказывается стал ?-оператором)

И недавно запилил драфт похожей штуки для Котлина:

fun testReturn(): WorkflowResult<Int, Throwable> {
    val int = doIo()
        .onError { return it }
    return Result(int + 1)
}

Это аналог вот такому коду:

fun testLong(): WorkflowResult<Int, Throwable> {
    val res = doIo()
    if (res is Error) {
        return res
    }
    val int = (res as Success).result

    return Result(int + 1)
}

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

Но спрашивается зачем всё это?

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

Вообще Result-ы как правило являются монадами и с ними можно работать так:

    val res = doIo()
    return res.map { it + 1}

И так получается даже короче. Но в Котлине нет спец синтаксиса для монад и поэтому они не масштабируются.
Например, если надо выполнить ИО-операцию на базе результата первых двух (и только в случае их успеха), то будет вот такой адок:

fun testCompositeM(): Optional<Int> {
    val first = mIo()
    val second = first.flatMap { mIo2(it) }
    return first.flatMap { firstVal ->
        second.flatMap { secondVal ->
            mIo2(firstVal + secondVal)
        }
    }
}

С моим же DSL-ем, всё будет прилично:

fun testComposite(): WorkflowResult<Int, Throwable> {
    val first = doIo().onError { return it }
    val second = doIo2(first).onError { return it }
    return doIo2(first + second)
}

Полный код DSLя

#error_handlin@ergonomic_code #kotlin@ergonomic_code #posts@ergonomic_code #ergo_approach@ergonomic_code

Друзья!

В первую очередь хочу ещё раз поблагодарить вас за то что подписались - я очень рад, что набралось больше 3-ёх человек:)

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

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

В ближайшие месяц-два посты будут трёх типов:
1) каждый вторник я буду стараться выкладывать авторские посты об Эргономичном Подходе и актуальном личном опыте;
2) каждый четверг я буду постить хёртбитную-ссылку на людей, книги, научные и популярные статьи и презентации, которые меня впечатлили в прошлом;
3) 0-2 раза в неделю я буду постить ссылки на какие-то актуальные статьи, показавшиеся мне интересными.

т.к. начало было сумбурным, и Kotlin Result DSL - это вообще приложение к одной из концепций ЭП (Workflows), то в ближайшие недели я буду писать предисторию к этому приложению:)
Пока план постов такой:
1) Эффекты, сайд эффекты и чистые функции. Что это за звери, чем отличаются, чем хороши и чем плохи;
2) Локальность рассуждений о коде (Local reasoning). Что это такое, почему важно;
3) Широкий и глубокий код. Нас учили, что функции должны быть короткими - это не всегда так. Локальность рассуждений важнее;
4) Workflows. Засунуть всё в одну функцию - тоже не вариант. Решение - воркфловы - шаблон разбиения кода, реализующего верхнеуровневую операцию с сохранением локальности рассуждений;
5) Kotlin Result DSL - применение Kotlin Result DSL для повышения эргономичности воркфловов.

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

P.S.

Ставьте лайкипишите комменты:)

#ergo_approach@ergonomic_code

Хорошие книги: Designing Data-Intensive Applications

Привет!

Четверговые посты начну с рубрики "хорошие книги".

А рубрику "хорошие книги" начну с актуального - Designing Data-Intensive Applications.

Эту книгу я читаю сейчас и прочитал пока только треть, но уже в восторге, поэтому рекомендую.

Designing Data-Intensive Applications - это приложения которые упираются не в CPU, а в количество, скорость поступления или сложность данных.
Т.е. считай все бэки.

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

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

Для фронтэндеров тоже есть практически полезная 4-ая глава о форматах взаимодействия бэка и фронта и его версионирования.

#books@ergonomic_code #databases@ergonomic_code

Привет!

Сегодняшний вторничный пост я посвящу тому, нафига я вообще пишу эти посты и раскрытию тайны Эргономичного Подхода:)

Я хочу чтобы работать программистом было весело и приятно, а не мучительно больно, как во всех проектах, с которыми я поработал за последние 15 лет.
Понятно, я не могу снять все проблемы, влекущие боль в работе программистом, но кажется я в последнее время начал ухватывать принципы разработки, которые могут снять технические проблемы, связанные с качеством кода.

Для того чтобы материализовать эти принципы я начал писать Книгу.
Эта книга называется "Разработка эргономичного кода" и она о том, как сегодня писать код так, чтобы завтра с ним было работать весело и приятно.
В книге я описываю Эргономичный Подход - набор моделей, принципов и практик дизайна и кодирования, следование которым и должно сделать работу весёлой и приятной:)

Однако с книгами есть одна проблема - для меня тексты в книге должны быть идеальными, с безупречной логикой и фактлогически выверенными. И писать такие тексты внезапно оказалось очень трудно:)
А я же люблю чтобы работать было весело и приятно:)
Поэтому я создал этот канал, чтобы весело и приятно писать о том, что мне актуально: сути Эргономичного Подхода.
Затем посты прошедшие проверку вами, моя дорогая аудитория, я буду вылизывать, делать их логику безупречной, фактологически выверять и включать в Книгу.

Итого:
1) Зачем я это всё затеял? - хочу чтобы моя работа приносила мне радость.
2) Что такое Эргономичный Подход? - это методика работы, следование которой сегодня, сделает работу завтра весёлой и приятной.

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

#ergo_approach@ergonomic_code

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

И не то, а чём думали авторы Spring Data: https://stackoverflow.com/questions/21265262/are-you-supposed-to-have-one-repository-per-table-in-jpa/21277087#21277087

А наткунлся я на это вот этой любопытной ссылке - https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates
походу, можно юзать спринг дату для бойлерплейтного кода, но не тащить при этом адовый проект.

а вот в эту ссылку я полез после того, как в своём петпроджекте на кторе и ебине проапгрейдил ктор 1.4.1 -> 1.4.2 (минор казалось бы), и у меня всё поотавливалось т.к. ебин юзает блокирующий jdbc, а ктор весь из себя на корутинах и не блокирующий и походу впилили туда проверку. И чёт я задумался, что мош спринг не так уж и плох:)

#posts@ergonomic_code #whynojpa@ergonomic_code #dd@ergonomic_code #spring_data_jdbc@ergonomic_code

Привет!

Сегодня я открываю рубрику "ИТ в лицах". Или "Хорошие люди" - не определился ещё:)

Представляю вам Эрика Мейера (Erik Meijer)

Этот мужик запилил LINQ и Rx* (ReactiveX, reactive extensions) - я думаю во многом именно ему мы должны быть благодарны за существование стрим апи во всех приличных языках в 20ом году:)

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

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

#posts@ergonomic_code

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

ну и если кто хочет приложить руку к технологии хранения завтрашнего дня - можно поконтрибьютать в кубит, я активно помогу стартануть:)

#posts@ergonomic_code

Линкопост

Очередной лонг лонг рид (оценка сайта - 2 часа, но я кажись за час-полтора осилил).
https://fasterthanli.me/articles/aiming-for-correctness-with-types

Какой-то чувак чморит Go и node.js за АПИ (преимущественно хттп сервера), которые допускают кривое использование "во имя простоты в 90% случаев".

А потом показывает, как это надо делать на Rust.

Основной посыл - юзайте языки и их фичи, которые на уровне компиляции исключают логические ошибки.

#posts@ergonomic_code