Привет!
Это снова я:)
Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.
#posts@ergonomic_code #fp@ergonomic_code
Это снова я:)
Анкл Боб недавно написал новый пост с восхвалением ФП.
Да-да, это тот самый Анкл Боб, который придумал SOLID - "5 основных принципов объектно-ориентированного программирования", согласно русской Википедии.
#posts@ergonomic_code #fp@ergonomic_code
Привет!
Сегодня я надел свою шляпу параноика.
Ещё одна реальная история бана большим братом аккаунта простого юзера со всеми данным.
Сегодня я надел свою шляпу параноика.
Ещё одна реальная история бана большим братом аккаунта простого юзера со всеми данным.
Mere Civilian
Apple broke up with me 😢
Do not get too attached to your Apple account; it belongs to Apple, NOT YOU!
Привет!
Случайно наткнулся на прямой ответ на мой сакральный вопрос - как декомпозировать систему на модули?
Ответ - Parnas Partitioning.
Правда оригинальную статью даже за деньги нагуглить не могу.
Ну и сам ответ любопытный, но, кажется, не практичный.
Что предлагают:
1) собрать всех стейкхолдеров. В моих реалиях - уже анриал
2) стрясти с них все идеи того что может поменяться. С учётом того, того, что сейчас требований на старте особо нет, то фик знает как трясти
3) отсортировать это всё по относительной вероятности. Вот тут уже хорошо и понятно, осталось придумать как пройти первые два шага:)
4) Оценить стоимость инкапсуляции каждого пункта
5) То что инкапсулировать дешево - инкапсулировать в отдельный модуль
6) Из оставшегося инкапсулировать наиболее вероятные штуки, пока бюджет не кончится.
Кажется, декомпозиция системы на модули (в современных условиях, по крайней мере) - это всё-таки вотчина гадалок и экстрасенсов.
#papers@ergonomic_code #design@ergonomic_code
Случайно наткнулся на прямой ответ на мой сакральный вопрос - как декомпозировать систему на модули?
Ответ - Parnas Partitioning.
Правда оригинальную статью даже за деньги нагуглить не могу.
Ну и сам ответ любопытный, но, кажется, не практичный.
Что предлагают:
1) собрать всех стейкхолдеров. В моих реалиях - уже анриал
2) стрясти с них все идеи того что может поменяться. С учётом того, того, что сейчас требований на старте особо нет, то фик знает как трясти
3) отсортировать это всё по относительной вероятности. Вот тут уже хорошо и понятно, осталось придумать как пройти первые два шага:)
4) Оценить стоимость инкапсуляции каждого пункта
5) То что инкапсулировать дешево - инкапсулировать в отдельный модуль
6) Из оставшегося инкапсулировать наиболее вероятные штуки, пока бюджет не кончится.
Кажется, декомпозиция системы на модули (в современных условиях, по крайней мере) - это всё-таки вотчина гадалок и экстрасенсов.
#papers@ergonomic_code #design@ergonomic_code
Привет!
Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.
Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.
Очень рекомендую к вдумчивому просмотру
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code
Пересмотрел старый доклад моего любимого Рича Хикки.
Он там прямым текстом говорит, что доклад не про то, чтобы попинать ООП, но получается у него очень хорошо. При том на фундаментальном уровне.
Но самая крутая на мой взгляд штука - это Эпохальная Модель Времени, кратко описная здесь.
Очень рекомендую к вдумчивому просмотру
#talks@ergonomic_code #fp@ergonomic_code #clojure@ergonomic_code #immutable_domain_model@ergonomic_code
InfoQ
Are We There Yet?
In his keynote at JVM Languages Summit 2009, Rich Hickey advocated for the reexamination of basic principles like state, identity, value, time, types, genericity, complexity, as they are used by OOP today, to be able to create the new constructs and languages…
У меня накопилось ещё ссылок, но мне показалось, что на той недели я вас заспамил, такчто пока их придержал.
Как часто я могу что-то постить, чтобы вам было комфортно?
Как часто я могу что-то постить, чтобы вам было комфортно?
Anonymous Poll
3%
Раз в месяц
19%
Раз в неделю
50%
Два-три раза в неделю
16%
Каждый день
3%
Каждые восемь часов
9%
Раз в два-три часа
Привет!
Параноидальный линко-пост.
Гугл, по чистой случайности главный большой брат и владелец самого популярного браузера, собирается выкинуть АПИ критичные для АдБлокеров.
Го Firefox - тут вполне ок последние 4 года
Параноидальный линко-пост.
Гугл, по чистой случайности главный большой брат и владелец самого популярного браузера, собирается выкинуть АПИ критичные для АдБлокеров.
Го Firefox - тут вполне ок последние 4 года
Electronic Frontier Foundation
Chrome Users Beware: Manifest V3 is Deceitful and Threatening
Like FLoC and Privacy Sandbox before it, Google Chrome’s Manifest V3 is another example of the inherent conflict of interest that comes from Google controlling both the dominant web browser and one
Привет!
Прочитал оригинальюную статью по Parnas Partitioning (ещё раз спасибо @celebithil за неё).
Не сказать чтобы статья показалась мне особо полезной, но напоминание одной хорошей мысли утянул:
In fact, imposing a design goal of modularity or flexibility WITHOUT providing the associated Hiding Assumption List would appear to be inherently ineffective. General purpose flexibility is likely to prove to be an ill-defined goal.
Абстрактная задача создания гибкой системы - плохая задача. Невозможно (с практической точки зрения, по крайней мере) создать систему гибкую в любом месте по любому направлению. И если делать систему гибкой просто на всякий случай, то с большой долей вероятности вы не угадаете и заложенные "точки перегиба" не пригодятся, но они увеличат стоимость разработки и усложнят "сгибание" системы в непредусмотренных местах, когда это действительно потребуется.
Прочитал оригинальюную статью по Parnas Partitioning (ещё раз спасибо @celebithil за неё).
Не сказать чтобы статья показалась мне особо полезной, но напоминание одной хорошей мысли утянул:
In fact, imposing a design goal of modularity or flexibility WITHOUT providing the associated Hiding Assumption List would appear to be inherently ineffective. General purpose flexibility is likely to prove to be an ill-defined goal.
Абстрактная задача создания гибкой системы - плохая задача. Невозможно (с практической точки зрения, по крайней мере) создать систему гибкую в любом месте по любому направлению. И если делать систему гибкой просто на всякий случай, то с большой долей вероятности вы не угадаете и заложенные "точки перегиба" не пригодятся, но они увеличат стоимость разработки и усложнят "сгибание" системы в непредусмотренных местах, когда это действительно потребуется.
Привет!
Вышли корутины 1.6.0 с парой долгожданных (мной) фич:
1) наконец-то можно писать мультиплатформенные тесты на suspend код без костылей
2) наконец-то можно создавать диспетчеры с ограниченным параллелизмом
#tools@ergonomic_code #kotlin@ergonomic_code
Вышли корутины 1.6.0 с парой долгожданных (мной) фич:
1) наконец-то можно писать мультиплатформенные тесты на suspend код без костылей
2) наконец-то можно создавать диспетчеры с ограниченным параллелизмом
#tools@ergonomic_code #kotlin@ergonomic_code
The JetBrains Blog
Introducing kotlinx.coroutines 1.6.0 | The Kotlin Blog
Following the release of Kotlin 1.6.0, the 1.6.0 version of the kotlinx.coroutines library is out. Here are the main features it brings: A new API and multiplatform support for kotlinx-coroutines-t
Привет!
Новый год - время перемен.
Весь 21-ый год я пытался сделать рациональную методику разработки ПО с детерминированным результатом. И что-то у меня не выходил каменный цветок - наверное не просто так, никто ещё этого не смог:)
И вот, под конец года я сначала прочитал "Думай медленно, решай быстро", где Канниман среди прочего ставит под сомнение предсказательную способность некоторых экспертов (я это прочитал как сомнение в способности программистов предсказать изменения).
Затем я прочитал "A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT", где Парнас пишет, что рациональный дизайн невозможен.
Потом прочитал "Чёрного Лебедя", где Талеб среди прочего через слово пинает платонические модели
И сейчас читаю "Data and Reality", где Кент показывает, что информация сама по себе - аморфное месиво, и нет рационального способа выбора её представления в компьютере.
В общем, я решил сделать пивот и в следующем году перейти от попытки создать теорию всего к описанию своей практики.
Генеральный план - составить каталог "соображений", исходя из которых я принимаю решения и разбирать конкретные кейсы применения этих соображений и принятия решений. Потом может удастся всё это как-то объединить.
С наступающим Новым годом!:)
Пусть вам программирование приносит больше положительных эмоций, чем отрицательных:)
#ergo_approach@ergonomic_code #books@ergonomic_code
Новый год - время перемен.
Весь 21-ый год я пытался сделать рациональную методику разработки ПО с детерминированным результатом. И что-то у меня не выходил каменный цветок - наверное не просто так, никто ещё этого не смог:)
И вот, под конец года я сначала прочитал "Думай медленно, решай быстро", где Канниман среди прочего ставит под сомнение предсказательную способность некоторых экспертов (я это прочитал как сомнение в способности программистов предсказать изменения).
Затем я прочитал "A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT", где Парнас пишет, что рациональный дизайн невозможен.
Потом прочитал "Чёрного Лебедя", где Талеб среди прочего через слово пинает платонические модели
И сейчас читаю "Data and Reality", где Кент показывает, что информация сама по себе - аморфное месиво, и нет рационального способа выбора её представления в компьютере.
В общем, я решил сделать пивот и в следующем году перейти от попытки создать теорию всего к описанию своей практики.
Генеральный план - составить каталог "соображений", исходя из которых я принимаю решения и разбирать конкретные кейсы применения этих соображений и принятия решений. Потом может удастся всё это как-то объединить.
С наступающим Новым годом!:)
Пусть вам программирование приносит больше положительных эмоций, чем отрицательных:)
#ergo_approach@ergonomic_code #books@ergonomic_code
Привет!
У меня тут на "рубеже годов" случился идейный кризис - поначалу казалось, что тотальный и весь эргономичный подход надо переделывать, но сейчас уже кажется что можно обойтись малой кровью.
И одним из аспектов кризиса является разочарование в агрегатах и Spring Data JDBC. Я пока не понимаю где проблема - в самих идее и технологии или ДНК (моём) и у меня нет другой идеи как делать эргономичный персистанс, поэтому пока придерживаюсь старой схемы.
Так вот, накопал интересный доклад о Spring Data JDBC от его разработчика. Он там из первых рук объясняет мотивацию создания модуля (мало кто в мире понимает и может эффективно использовать JPA, за пределами туториалов и хелло воролдов) и даёт пачку рецептов решения не совсем тривиальных проблем.
И этот доклад натолкнул меня на интересную мысль: Агрегаты и неизменяемая модель данных - идеальная комбинация.
По задумке, все изменения в агрегате должны проходить через его корень.
И если у вас модель изменяемая, то для соблюдения этого правила есть только два пути:
1) Полностью инкапсулировать все сущности внутри агрегата. Но в этом случае в агрегате придётся нагенерять гору методов для чтения данных некорневых сущностей.
2) Отрубать руки за прямую мутацию некорневой сущности. В прямом смысле, потому что более мягкое наказание будет приводить к нарушению этого правила, из-за невнимательности или спешки.
Потенциально есть ещё вариант с package private методами для мутации некорневых сущностей, но:
1) В Котлин package private всё ещё не завезли:(
2) Это требует пакетирования по агрегатам
Однако главный аргумент против того, чтобы не искать способ соблюдать это правило в изменяемой модели - императивный код сложен в понимании и подвержен ошибкам
А вот если у модель неизменяемя - то по определению, любая мутация любой части агрегата должна будет пройти через его корень, чтобы собрать новое состояние корня, со ссылками на новые состояния некорней. При том сами некрони можно спокойно выставлять для "публичного чтения".
#ergo_approach@ergonomic_code #spring_data_jdbc@ergonomic_code #talks@ergonomic_code #whynojpa@ergonomic_code
У меня тут на "рубеже годов" случился идейный кризис - поначалу казалось, что тотальный и весь эргономичный подход надо переделывать, но сейчас уже кажется что можно обойтись малой кровью.
И одним из аспектов кризиса является разочарование в агрегатах и Spring Data JDBC. Я пока не понимаю где проблема - в самих идее и технологии или ДНК (моём) и у меня нет другой идеи как делать эргономичный персистанс, поэтому пока придерживаюсь старой схемы.
Так вот, накопал интересный доклад о Spring Data JDBC от его разработчика. Он там из первых рук объясняет мотивацию создания модуля (мало кто в мире понимает и может эффективно использовать JPA, за пределами туториалов и хелло воролдов) и даёт пачку рецептов решения не совсем тривиальных проблем.
И этот доклад натолкнул меня на интересную мысль: Агрегаты и неизменяемая модель данных - идеальная комбинация.
По задумке, все изменения в агрегате должны проходить через его корень.
И если у вас модель изменяемая, то для соблюдения этого правила есть только два пути:
1) Полностью инкапсулировать все сущности внутри агрегата. Но в этом случае в агрегате придётся нагенерять гору методов для чтения данных некорневых сущностей.
2) Отрубать руки за прямую мутацию некорневой сущности. В прямом смысле, потому что более мягкое наказание будет приводить к нарушению этого правила, из-за невнимательности или спешки.
Потенциально есть ещё вариант с package private методами для мутации некорневых сущностей, но:
1) В Котлин package private всё ещё не завезли:(
2) Это требует пакетирования по агрегатам
Однако главный аргумент против того, чтобы не искать способ соблюдать это правило в изменяемой модели - императивный код сложен в понимании и подвержен ошибкам
А вот если у модель неизменяемя - то по определению, любая мутация любой части агрегата должна будет пройти через его корень, чтобы собрать новое состояние корня, со ссылками на новые состояния некорней. При том сами некрони можно спокойно выставлять для "публичного чтения".
#ergo_approach@ergonomic_code #spring_data_jdbc@ergonomic_code #talks@ergonomic_code #whynojpa@ergonomic_code
springone.io
Join other developers, app architects, and innovators and learn how they’re using the latest tech to build the apps that keep the world humming.
Привет!
Postgres Professionals - российская контора по разработке и коммерческой поддержке постгреса, выпустила книгу (на русском!) об устройстве постгреса. Сам, естественно, ещё не читал, но добавил себе в список прочтения.
#books@ergonomic_code #databases@ergonomic_code
Postgres Professionals - российская контора по разработке и коммерческой поддержке постгреса, выпустила книгу (на русском!) об устройстве постгреса. Сам, естественно, ещё не читал, но добавил себе в список прочтения.
#books@ergonomic_code #databases@ergonomic_code
postgrespro.ru
PostgreSQL 17 изнутри
Postgres Professional - российская компания, разработчик систем управления базами данных
Привет!
Продолжаю проверять гипотезу, что это у меня проблема в ДНК, а с агрегатами и Spring Data JDBC всё ок, смотрю очередной видос
Всё тот же автор Spring Data JDBC одновременно:
1) пинает JPA
2) восторгается агрегатами
3) предлагает декомпозировать систему на основе агрегатов
4) запрещает циклы в зависимостях
Смотрю как в своё зеркало 21ого года:)
Плюс он там среди прочего рекомендует вообще не создавать внешние ключи между агрегатами, но это имхо перебор. А вот отключать констрейнты на нерелевантные тесту агрегаты в интеграционных тестах - имхо идею любопытная
Ну и наконец:
"it will feel painfull ... but people have to think where stuff belongs and this alone is I think a great benefit"
Со второй частью согласен полностью. Но хочется найти способ обойтись без боли
#talks@ergonomic_code #spring_data_jdbc@ergonomic_code #whynojpa@ergonomic_code #ergo_approach@ergonomic_code
Продолжаю проверять гипотезу, что это у меня проблема в ДНК, а с агрегатами и Spring Data JDBC всё ок, смотрю очередной видос
Всё тот же автор Spring Data JDBC одновременно:
1) пинает JPA
2) восторгается агрегатами
3) предлагает декомпозировать систему на основе агрегатов
4) запрещает циклы в зависимостях
Смотрю как в своё зеркало 21ого года:)
Плюс он там среди прочего рекомендует вообще не создавать внешние ключи между агрегатами, но это имхо перебор. А вот отключать констрейнты на нерелевантные тесту агрегаты в интеграционных тестах - имхо идею любопытная
Ну и наконец:
"it will feel painfull ... but people have to think where stuff belongs and this alone is I think a great benefit"
Со второй частью согласен полностью. Но хочется найти способ обойтись без боли
#talks@ergonomic_code #spring_data_jdbc@ergonomic_code #whynojpa@ergonomic_code #ergo_approach@ergonomic_code
YouTube
Domain-Driven Design with Relational Databases Using Spring Data JDBC
Abstract: Domain-driven design introduces the concepts of Aggregate, AggregateRoot, and Repository. If one takes these concepts seriously, certain habits we picked up while fighting working with JPA become unacceptable. Even more, a substantial part of the…
Привет!
Сегодня линкопост: Functional Programming for Pragmatists
Мужик говорит быстро, поэтому слушать довольно тяжело, но мне нравится его определение и объяснение ФП.
Отдельно крут критерий определения чистоты функции: функция чистая, только если её можно заменить на (потенциально огромную) хэшмапу из параметров функции в результаты вызова.
Наконец, мужик в части дебага классно поясняет то, что я называю "локальностью рассуждей".
В общем прям рекомендую видос, особенно тем, кто (пока что:)) не пришёл к выводу, что чистые функции - самый эргономичный способ разработки програм на сегодняшний момент
#talks@ergonomic_code #fp@ergonomic_code
Сегодня линкопост: Functional Programming for Pragmatists
Мужик говорит быстро, поэтому слушать довольно тяжело, но мне нравится его определение и объяснение ФП.
Отдельно крут критерий определения чистоты функции: функция чистая, только если её можно заменить на (потенциально огромную) хэшмапу из параметров функции в результаты вызова.
Наконец, мужик в части дебага классно поясняет то, что я называю "локальностью рассуждей".
В общем прям рекомендую видос, особенно тем, кто (пока что:)) не пришёл к выводу, что чистые функции - самый эргономичный способ разработки програм на сегодняшний момент
#talks@ergonomic_code #fp@ergonomic_code
YouTube
Functional Programming for Pragmatists • Richard Feldman • GOTO 2021
This presentation was recorded at GOTO Copenhagen 2021. #GOTOcon #GOTOcph
http://gotocph.com
Richard Feldman - Functional Programming Language Expert & Author of "Elm in Action"
ABSTRACT
Do you care more about how well code works than how conceptually elegant…
http://gotocph.com
Richard Feldman - Functional Programming Language Expert & Author of "Elm in Action"
ABSTRACT
Do you care more about how well code works than how conceptually elegant…
Между тем в фоновом режиме думаю как делать эргономичный персистанс и накопал статью с критикой SQL-я за неэргономичность:) И альтернативным предложением:)
Может быть у нас всё-таки есть свет в конце туннеля:)
#posts@ergonomic_code #sql@ergonomic_code
Может быть у нас всё-таки есть свет в конце туннеля:)
#posts@ergonomic_code #sql@ergonomic_code
Geldata
We Can Do Better Than SQL | Gel Blog
The questions we often hear are "Why create a new query language?" and "What's wrong with SQL?". This blog post contains answers to both.
Привет!
Вы наверняка слышали, что Хоар назвал null-ы своей ошибкой на миллиард долларов.
Вчера случайно наткнулся на относительно свежую (2009 год) презентацию самого Хоара на эту тему.
И она натолкнула меня на мысль, что мы живём на закате (первой?) золотой эры ИТ - всё самое крутое придумали в 60-70-ые годы и многие из тех, кто это ещё живы и при на них можно посмотреть в живую:)
Сама же презентация не то чтобы прям полезная была, но довольно интересная и за ней можно скоротать длинный зимний вечерок:)
#talks@ergonomic_code
Вы наверняка слышали, что Хоар назвал null-ы своей ошибкой на миллиард долларов.
Вчера случайно наткнулся на относительно свежую (2009 год) презентацию самого Хоара на эту тему.
И она натолкнула меня на мысль, что мы живём на закате (первой?) золотой эры ИТ - всё самое крутое придумали в 60-70-ые годы и многие из тех, кто это ещё живы и при на них можно посмотреть в живую:)
Сама же презентация не то чтобы прям полезная была, но довольно интересная и за ней можно скоротать длинный зимний вечерок:)
#talks@ergonomic_code
YouTube
Null References The Billion Dollar Mistake
lecturer：Tony Hoare
conference：QCon London 2009
topic：null reference in programming language design
conference：QCon London 2009
topic：null reference in programming language design
Привет!
Снова линко-пост.
Тут дядька хорошо показывает в чём проблема с наллами и предлагает заменить их на Maybe-монаду (ака Java Optional, ака sum типы).
Но не спешите всё переписывать на Optional, пока не посмотрите как Рич Хикки пинает Maybe в первых 14 минутах этой презентации и предлагает заменить их на union типы (ака Kotlin nullable, ака Java Multiple catch block).
А этой статье автор подробно рассматривает sum & union типы и приходит к выводу, что "Therefore union types are strictly more flexible than sum types, but the ergonomics of each approach depends on the use-case."
#talks@ergonomic_code
Снова линко-пост.
Тут дядька хорошо показывает в чём проблема с наллами и предлагает заменить их на Maybe-монаду (ака Java Optional, ака sum типы).
Но не спешите всё переписывать на Optional, пока не посмотрите как Рич Хикки пинает Maybe в первых 14 минутах этой презентации и предлагает заменить их на union типы (ака Kotlin nullable, ака Java Multiple catch block).
А этой статье автор подробно рассматривает sum & union типы и приходит к выводу, что "Therefore union types are strictly more flexible than sum types, but the ergonomics of each approach depends on the use-case."
#talks@ergonomic_code
YouTube
Billion Dollar Foresight by Richard Feldman (NoRedInk) - Inspirational
In 1960, Sir Tony Hoare introduced the concept of "null" to programming. Today he calls this his "billion dollar mistake," as he estimates null has caused a billion dollars in economic damage. If this was a billion-dollar mistake, what about the reverse?…
Небольшой тизер нового поста - проблемы с производительностью, присущие системам на базе мейнстримовых ОРМов (JPA) являются следствием проблем дизайна (высокая связанность и циклы в связях между модулями), порождённых использованием этих ОРМов.
Привет!
Пока новый пост варится - радую вас линками:)
Я нашёл базу данных мечты - EdgeDb.
Что в ней крутого:
1) Она на базе Постгреса. Т.е. ядро надёжное и если с верхним слоем будут проблемы - можно будет цепануться к Постгресу напрямую
2) У неё графово-реляионна модель данных
2.1) Она поддерживает вложенные инсёрты
2.2) Она поддерживает наследование и полиморфные связи
2.3) Она поддерживает выборку иерархичных данных
2.4) Запросы на EdgeQL композируемые (Composable)
3) Судя по гиту, пилят её уже 13 лет и сейчас пилят активно как никогда - на момент написания предыдущий мёрж в мастер был 43 минуты назад, а за последние 2 дня вмёржили 20 ПРов
4) Free как и свобода и как пиво
5) Поддерживает GraphQL из коробки
6) У неё релиз версии 1.0 в феврале
Одна проблема - нет клиентов под JVM 😂
#posts@ergonomic_code #ergo_persistance@ergonomic_code #tools@ergonomic_code #databases@ergonomic_code
Пока новый пост варится - радую вас линками:)
Я нашёл базу данных мечты - EdgeDb.
Что в ней крутого:
1) Она на базе Постгреса. Т.е. ядро надёжное и если с верхним слоем будут проблемы - можно будет цепануться к Постгресу напрямую
2) У неё графово-реляионна модель данных
2.1) Она поддерживает вложенные инсёрты
2.2) Она поддерживает наследование и полиморфные связи
2.3) Она поддерживает выборку иерархичных данных
2.4) Запросы на EdgeQL композируемые (Composable)
3) Судя по гиту, пилят её уже 13 лет и сейчас пилят активно как никогда - на момент написания предыдущий мёрж в мастер был 43 минуты назад, а за последние 2 дня вмёржили 20 ПРов
4) Free как и свобода и как пиво
5) Поддерживает GraphQL из коробки
6) У неё релиз версии 1.0 в феврале
Одна проблема - нет клиентов под JVM 😂
#posts@ergonomic_code #ergo_persistance@ergonomic_code #tools@ergonomic_code #databases@ergonomic_code
Geldata
Gel | Postgres Unchained
Gel is an open-source database designed to address ergonomic limitations of SQL and relational modeling, without sacrificing type safety or performance.
И бонусом, в первую очередь для моих студентов, но может и опытным специалистам покажется интересным: ещё раз про джоины
#posts@ergonomic_code #sql@ergonomic_code
#posts@ergonomic_code #sql@ergonomic_code
Java, SQL and jOOQ.
Say NO to Venn Diagrams When Explaining JOINs
In recent times, there have been a couple of tremendously popular blog posts explaining JOINs using Venn Diagrams. After all, relational algebra and SQL are set oriented theories and languages, so …
Привет!
Внезапный "а знаете ли вы пост?".
Наверняка вы слышали, что при проектировании REST API необходимо отдавать предпочтение стандартизированный штукам, например для авторизации использовать заголовок Authentication.
Чего вы, возможно, не слышали (по крайней мере я не слышал до вчерашнего дня) - ответы на запросы с заголовком Authentication запрещено кэшировать по умолчанию. А если использовать доморошенные заголовки, то надо не забыть явно запретить кэширование ответов.
#http_api@ergonomic_code #rest_api@ergonomic_code #posts@ergonomic_code
Внезапный "а знаете ли вы пост?".
Наверняка вы слышали, что при проектировании REST API необходимо отдавать предпочтение стандартизированный штукам, например для авторизации использовать заголовок Authentication.
Чего вы, возможно, не слышали (по крайней мере я не слышал до вчерашнего дня) - ответы на запросы с заголовком Authentication запрещено кэшировать по умолчанию. А если использовать доморошенные заголовки, то надо не забыть явно запретить кэширование ответов.
#http_api@ergonomic_code #rest_api@ergonomic_code #posts@ergonomic_code
IETF HTTP Working Group Specifications
RFC7234
Hypertext Transfer Protocol (HTTP/1.1): Caching