Привет!
Сегодняшний вторничный пост я посвящу тому, нафига я вообще пишу эти посты и раскрытию тайны Эргономичного Подхода:)
Я хочу чтобы работать программистом было весело и приятно, а не мучительно больно, как во всех проектах, с которыми я поработал за последние 15 лет.
Понятно, я не могу снять все проблемы, влекущие боль в работе программистом, но кажется я в последнее время начал ухватывать принципы разработки, которые могут снять технические проблемы, связанные с качеством кода.
Для того чтобы материализовать эти принципы я начал писать Книгу.
Эта книга называется "Разработка эргономичного кода" и она о том, как сегодня писать код так, чтобы завтра с ним было работать весело и приятно.
В книге я описываю Эргономичный Подход - набор моделей, принципов и практик дизайна и кодирования, следование которым и должно сделать работу весёлой и приятной:)
Однако с книгами есть одна проблема - для меня тексты в книге должны быть идеальными, с безупречной логикой и фактлогически выверенными. И писать такие тексты внезапно оказалось очень трудно:)
А я же люблю чтобы работать было весело и приятно:)
Поэтому я создал этот канал, чтобы весело и приятно писать о том, что мне актуально: сути Эргономичного Подхода.
Затем посты прошедшие проверку вами, моя дорогая аудитория, я буду вылизывать, делать их логику безупречной, фактологически выверять и включать в Книгу.
Итого:
1) Зачем я это всё затеял? - хочу чтобы моя работа приносила мне радость.
2) Что такое Эргономичный Подход? - это методика работы, следование которой сегодня, сделает работу завтра весёлой и приятной.
Вот теперь я рассказал самое начало истории и наконец можно переходит к самой истории - следующий пост уже точно будет по сути эргономичного подхода.
#ergo_approach@ergonomic_code
Сегодняшний вторничный пост я посвящу тому, нафига я вообще пишу эти посты и раскрытию тайны Эргономичного Подхода:)
Я хочу чтобы работать программистом было весело и приятно, а не мучительно больно, как во всех проектах, с которыми я поработал за последние 15 лет.
Понятно, я не могу снять все проблемы, влекущие боль в работе программистом, но кажется я в последнее время начал ухватывать принципы разработки, которые могут снять технические проблемы, связанные с качеством кода.
Для того чтобы материализовать эти принципы я начал писать Книгу.
Эта книга называется "Разработка эргономичного кода" и она о том, как сегодня писать код так, чтобы завтра с ним было работать весело и приятно.
В книге я описываю Эргономичный Подход - набор моделей, принципов и практик дизайна и кодирования, следование которым и должно сделать работу весёлой и приятной:)
Однако с книгами есть одна проблема - для меня тексты в книге должны быть идеальными, с безупречной логикой и фактлогически выверенными. И писать такие тексты внезапно оказалось очень трудно:)
А я же люблю чтобы работать было весело и приятно:)
Поэтому я создал этот канал, чтобы весело и приятно писать о том, что мне актуально: сути Эргономичного Подхода.
Затем посты прошедшие проверку вами, моя дорогая аудитория, я буду вылизывать, делать их логику безупречной, фактологически выверять и включать в Книгу.
Итого:
1) Зачем я это всё затеял? - хочу чтобы моя работа приносила мне радость.
2) Что такое Эргономичный Подход? - это методика работы, следование которой сегодня, сделает работу завтра весёлой и приятной.
Вот теперь я рассказал самое начало истории и наконец можно переходит к самой истории - следующий пост уже точно будет по сути эргономичного подхода.
#ergo_approach@ergonomic_code
GitHub
developing-ergonomic-code/book-rus/developing-ergonomic-code.adoc at master · d-r-q/developing-ergonomic-code
Book about practices and techniques to develop code that is simple to comprehend and maintain - d-r-q/developing-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
Во всех бэках на спринге (со 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
Stack Overflow
Are you supposed to have one repository per table in JPA?
Are you supposed to have one repository per table in JPA? If not, how do you resolve the generics in the repository database?
For example, below is a StoreRepository. It handles CRUD operations on...
For example, below is a StoreRepository. It handles CRUD operations on...
Привет!
Сегодня я открываю рубрику "ИТ в лицах". Или "Хорошие люди" - не определился ещё:)
Представляю вам Эрика Мейера (Erik Meijer)
Этот мужик запилил LINQ и Rx* (ReactiveX, reactive extensions) - я думаю во многом именно ему мы должны быть благодарны за существование стрим апи во всех приличных языках в 20ом году:)
Сейчас он занимается диференциальным программированием - хз что такое, но кажись это что-то про подбор параметров функций на этапе компиляции. Ну и звучит круто
Наконец, он написал пару хороших статей, которые я так же планирую здесь опубликовать.
#posts@ergonomic_code
Сегодня я открываю рубрику "ИТ в лицах". Или "Хорошие люди" - не определился ещё:)
Представляю вам Эрика Мейера (Erik Meijer)
Этот мужик запилил LINQ и Rx* (ReactiveX, reactive extensions) - я думаю во многом именно ему мы должны быть благодарны за существование стрим апи во всех приличных языках в 20ом году:)
Сейчас он занимается диференциальным программированием - хз что такое, но кажись это что-то про подбор параметров функций на этапе компиляции. Ну и звучит круто
Наконец, он написал пару хороших статей, которые я так же планирую здесь опубликовать.
#posts@ergonomic_code
Wikipedia
Erik Meijer (computer scientist)
Dutch computer scientist
Хм, решил на всякий случай уточнить, знаете ли вы, что такое LINK и rx*
Anonymous Poll
22%
Знаю что такое LINK
13%
Знаю что такое rx
39%
Не знаю ни того, ни другого
26%
Знаю и то и то
Случайно (отсюда) наткнулся на статью, с той же идеей, что и у моего кубита (мой второй большой и смежный с ЭП проект) - в интересах пользователей переносить свои данные из облаков на локальные устройства, а наша (технарей) задача сделать так чтобы юзеры при этом в качестве сервиса не потеряли:)
ну и если кто хочет приложить руку к технологии хранения завтрашнего дня - можно поконтрибьютать в кубит, я активно помогу стартануть:)
#posts@ergonomic_code
ну и если кто хочет приложить руку к технологии хранения завтрашнего дня - можно поконтрибьютать в кубит, я активно помогу стартануть:)
#posts@ergonomic_code
Хабр
CRDT, RON и Сети Данных
Эта статья о следующем эволюционном шаге в развитии систем обработки данных. Тема амбициозная, поэтому расскажу сначала немного о себе. Вот уже больше 10 лет я работаю над проектами в области...
Линкопост
Очередной лонг лонг рид (оценка сайта - 2 часа, но я кажись за час-полтора осилил).
https://fasterthanli.me/articles/aiming-for-correctness-with-types
Какой-то чувак чморит Go и node.js за АПИ (преимущественно хттп сервера), которые допускают кривое использование "во имя простоты в 90% случаев".
А потом показывает, как это надо делать на Rust.
Основной посыл - юзайте языки и их фичи, которые на уровне компиляции исключают логические ошибки.
#posts@ergonomic_code
Очередной лонг лонг рид (оценка сайта - 2 часа, но я кажись за час-полтора осилил).
https://fasterthanli.me/articles/aiming-for-correctness-with-types
Какой-то чувак чморит Go и node.js за АПИ (преимущественно хттп сервера), которые допускают кривое использование "во имя простоты в 90% случаев".
А потом показывает, как это надо делать на Rust.
Основной посыл - юзайте языки и их фичи, которые на уровне компиляции исключают логические ошибки.
#posts@ergonomic_code
fasterthanli.me
Aiming for correctness with types
The Nature weekly journal of science was first published in 1869. And after one and a half century, it has finally completed one cycle of carcinization, by publishing an article about the Rust prog...
Привет!
Чёт предновогодняя суета на меня напала и я не осилил чего-нить за эту неделю скреативить, так что будет линкопост:)
Вообще, я всю идею воркфловов (включая термин) умыкнул у этого чувака. Но справедливости ради, я его когда-то почитал, забыл всё, "придумал" часть ЭП про воркфловы (которые тада называл юз кейсами), и потом снова наткнулся на этого чувака:)
В этом же докладе он рассказывает, что воркфловы - это скрипты тразнакци из P of EAA
Но кроме того, он там же и ещё пару важных вопросов упоминает:
1) адовость графов зависимостей в "объектно-ориентированных" проектах
2) не надо покрывать юнит тестами каждый отдельный класс в изоляции. и тесты должны проверять контракты системы на её границах, а не то, как она реализована
3) код в первую очередь надо нарезать на вертикальные полносвязные кусочки, а не слои
4) способ деплоя (монолит, микросервисы, серверлес) не должен влиять на дизайн системы. т.е. куски хорошо спроектированной системы можно без больших усилий двигать между процессами и машинами
#talks@ergonomic_code
Чёт предновогодняя суета на меня напала и я не осилил чего-нить за эту неделю скреативить, так что будет линкопост:)
Вообще, я всю идею воркфловов (включая термин) умыкнул у этого чувака. Но справедливости ради, я его когда-то почитал, забыл всё, "придумал" часть ЭП про воркфловы (которые тада называл юз кейсами), и потом снова наткнулся на этого чувака:)
В этом же докладе он рассказывает, что воркфловы - это скрипты тразнакци из P of EAA
Но кроме того, он там же и ещё пару важных вопросов упоминает:
1) адовость графов зависимостей в "объектно-ориентированных" проектах
2) не надо покрывать юнит тестами каждый отдельный класс в изоляции. и тесты должны проверять контракты системы на её границах, а не то, как она реализована
3) код в первую очередь надо нарезать на вертикальные полносвязные кусочки, а не слои
4) способ деплоя (монолит, микросервисы, серверлес) не должен влиять на дизайн системы. т.е. куски хорошо спроектированной системы можно без больших усилий двигать между процессами и машинами
#talks@ergonomic_code
YouTube
Reinventing the Transaction Script - Scott Wlaschin
The Transaction Script pattern organizes business logic as a single procedure. It has always been considered less sophisticated and flexible than a layered architecture with a rich domain model. But is that really true?
In this talk, we'll reinvent the Transaction…
In this talk, we'll reinvent the Transaction…
Я где-то по лету писал о парадигмах программирования и тогда не нашёл авторитетного источинка этого термина и что-то сам выдумал. А тут случайно натыкаюсь на The Paradigms of Programming - статью в авторитетном рецензируемом журнале.
Статью ещё не читал, так что пока не рекомендую
а вот за одну цитату я глазом зацепился, пока листал по диагонали:)
» The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work.
> In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development
Мораль вырваной из контекста цитаты - учись, а то станешь менеджером:)
#papers@ergonomic_code #terminology@ergonomic_code
Статью ещё не читал, так что пока не рекомендую
а вот за одну цитату я глазом зацепился, пока листал по диагонали:)
» The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work.
> In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development
Мораль вырваной из контекста цитаты - учись, а то станешь менеджером:)
#papers@ergonomic_code #terminology@ergonomic_code
GitHub
developing-ergonomic-code/book-rus/developing-ergonomic-code.adoc at master · d-r-q/developing-ergonomic-code
Book about practices and techniques to develop code that is simple to comprehend and maintain - d-r-q/developing-ergonomic-code
Привет!
Буду краток:)
С наступающим новым годом!:)
Спасибо, что вы всё ещё со мной, желаю, чтобы у вас в следующем году каждый день была хоть маленькая радость:) Ну и побольше эргономичного кода, конечно же:)
Вернусь 5-ого таки с постом про чистые функции:)
Буду краток:)
С наступающим новым годом!:)
Спасибо, что вы всё ещё со мной, желаю, чтобы у вас в следующем году каждый день была хоть маленькая радость:) Ну и побольше эргономичного кода, конечно же:)
Вернусь 5-ого таки с постом про чистые функции:)
https://telegra.ph/CHistye-funkcii-ehffekty-i-sajdehffekty-01-05
#posts@ergonomic_code #fp@ergonomic_code
#posts@ergonomic_code #fp@ergonomic_code
Telegraph
Чистые функции, эффекты и сайдэффекты
Блог переехал на мой сайт Привет! На первый взгляд халявная тема при ближайшем рассмотрении оказалась довольно мутной. С чистыми функциями всё более-менее просто, у них на вики есть внятное определение:
Single Responsibility Principle considered harmful
Привет!
Наткнулся тут на эту статью и чёт меня малёха бомбануло.
Теоретически, принцип (Single Responsibility Principle ) возможно хороший и правильный, ток с ним есть одна проблема - анкл Боб 20 (двадцать) лет его объясняет и ни как объяснить не может.
Мне удалось отследить следующую историю формулировок этого принципа самим Мартином:
- 19xx: чёт мне припоминается, что где-то он писал о то, что изначально публиковал эти принципы в каком-то журнале, но ссылок побырому я не нашёл
- 2003: "A class should have only one reason to change" - Agile Software Development, Principles, Patterns, and Practices
- 2008: "The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change" - Clean Code
- 2014: "Gather together the things that change for the same reasons. Separate those things that change for different reasons." - The Single Responsibility Principle
- 2018: "A module should be responsible to one, and only one, actor" - Clean Architecture
И тем не менее, в статье с которой меня бомбануло написано: "That class itself should do one thing".
По моим ощущениям "one thing" - это самая распространённая интерпретация SRP.
Всё бы ничего, но "thing" - понятие растяжимое.
Сортировка, например - одна вещь?
А если один метод в зависимости от размера входных данных использует разные алгоритмы?
Это всё ещё одна вещь или несколько?
А если код поддерживает сортировку массивов превышающих размер памяти и работает с диском соотвественно?
О размере вещей можно спорить бесконечно.
На небесах программисты только и говорят о том, сколько вещей делает тот или иной кусок кода.
Но даже чёрт с ней с вещью.
Сам анкл Боб путается в показаниях.
В одной из статей он пишет:
> "We do not mix business rules with GUI code".
Так-то всё правильно пишет - действительно не мешаем и это хорошо.
Ток изменения в требованиях от одного источника зачастую требует изменений и в гуе, и в правилах и в БД.
Т.е. эти штуки (для одной фичи) должны быть в одном месте.
В общем имхо, SRP - это хороший лозунг, который полезно знать и о котором стоит вспоминать, в третью очередь при анализе дизайна, но никак не основополагающий принцип дизайна.
И ещё не много хейта SOLID-а в целом:
1) https://www.youtube.com/watch?v=tMW08JkFrBA - доклад от крутого во всех смыслах мужика. Можно его прям по имени по ютубить и смотреть всё подряд. Настоятельно рекомендую.
2) https://www.tedinski.com/2019/04/02/solid-critique.html - пост от другого крутого мужика, который начал (и не осилил, похоже :( ) писать книгу примерно о том же, о чём пишу я:)
Но он осилил сильно больше чем я пока что, так что настоятельно рекомендую:)
3) https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong - просто слайды от неизвестного мужика, случайно попавшиеся под руку
На слайды из п. 3 Мартин даже ответил
#posts@ergonomic_code #solid@ergonomic_code
Привет!
Наткнулся тут на эту статью и чёт меня малёха бомбануло.
Теоретически, принцип (Single Responsibility Principle ) возможно хороший и правильный, ток с ним есть одна проблема - анкл Боб 20 (двадцать) лет его объясняет и ни как объяснить не может.
Мне удалось отследить следующую историю формулировок этого принципа самим Мартином:
- 19xx: чёт мне припоминается, что где-то он писал о то, что изначально публиковал эти принципы в каком-то журнале, но ссылок побырому я не нашёл
- 2003: "A class should have only one reason to change" - Agile Software Development, Principles, Patterns, and Practices
- 2008: "The Single Responsibility Principle (SRP) states that a class or module should have one, and only one, reason to change" - Clean Code
- 2014: "Gather together the things that change for the same reasons. Separate those things that change for different reasons." - The Single Responsibility Principle
- 2018: "A module should be responsible to one, and only one, actor" - Clean Architecture
И тем не менее, в статье с которой меня бомбануло написано: "That class itself should do one thing".
По моим ощущениям "one thing" - это самая распространённая интерпретация SRP.
Всё бы ничего, но "thing" - понятие растяжимое.
Сортировка, например - одна вещь?
А если один метод в зависимости от размера входных данных использует разные алгоритмы?
Это всё ещё одна вещь или несколько?
А если код поддерживает сортировку массивов превышающих размер памяти и работает с диском соотвественно?
О размере вещей можно спорить бесконечно.
На небесах программисты только и говорят о том, сколько вещей делает тот или иной кусок кода.
Но даже чёрт с ней с вещью.
Сам анкл Боб путается в показаниях.
В одной из статей он пишет:
> "We do not mix business rules with GUI code".
Так-то всё правильно пишет - действительно не мешаем и это хорошо.
Ток изменения в требованиях от одного источника зачастую требует изменений и в гуе, и в правилах и в БД.
Т.е. эти штуки (для одной фичи) должны быть в одном месте.
В общем имхо, SRP - это хороший лозунг, который полезно знать и о котором стоит вспоминать, в третью очередь при анализе дизайна, но никак не основополагающий принцип дизайна.
И ещё не много хейта SOLID-а в целом:
1) https://www.youtube.com/watch?v=tMW08JkFrBA - доклад от крутого во всех смыслах мужика. Можно его прям по имени по ютубить и смотреть всё подряд. Настоятельно рекомендую.
2) https://www.tedinski.com/2019/04/02/solid-critique.html - пост от другого крутого мужика, который начал (и не осилил, похоже :( ) писать книгу примерно о том же, о чём пишу я:)
Но он осилил сильно больше чем я пока что, так что настоятельно рекомендую:)
3) https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong - просто слайды от неизвестного мужика, случайно попавшиеся под руку
На слайды из п. 3 Мартин даже ответил
#posts@ergonomic_code #solid@ergonomic_code
Tom McFarlin
What Are Programming Side Effects, Anyway? | Tom McFarlin
I previously discussed programming side effects in the context of PSR-1. But their importance extends beyond a single language and into general programming.
Продолжаем знакомиться:)
Как у вас дела с английским?
Как у вас дела с английским?
Anonymous Poll
4%
Не знаю
30%
Могу читать
65%
Могу смотреть видосы
Та-да-да-дааааааа!
Меня тут внезапно осенило, что в текущую тему вторничных постов (чистые функции, эффекты и сайдэффекты) надо добавить пункт "грязные функции". Интригует?:)
Меня тут внезапно осенило, что в текущую тему вторничных постов (чистые функции, эффекты и сайдэффекты) надо добавить пункт "грязные функции". Интригует?:)
Привет!
Продолжаем разбирать тему чистых функций и эффектов. Сегодня пост о чистых функциях.
И заодно хочу поделиться радостью - моя задумка с каналом как песочницей для книги похоже работает:) Я несколько месяцев не мог ничего толком написать поэтой теме в книгу, а в канал нормально пишется и по ходу дела я сам всё глужбе понимаю тему. Думаю венцом этой серии постов станет черновик ещё одного раздела книги:) Ещё раз спасибо, что вы со мной - даже просмотры без комментов дают мне мотивацию продолжать эту работу:)
https://telegra.ph/CHistye-i-gryaznye-funkcii-ehffekty-i-obrabotka-signalov-sajdehffekty-chistye-funkcii-01-12
#posts@ergonomic_code #fp@ergonomic_code
Продолжаем разбирать тему чистых функций и эффектов. Сегодня пост о чистых функциях.
И заодно хочу поделиться радостью - моя задумка с каналом как песочницей для книги похоже работает:) Я несколько месяцев не мог ничего толком написать поэтой теме в книгу, а в канал нормально пишется и по ходу дела я сам всё глужбе понимаю тему. Думаю венцом этой серии постов станет черновик ещё одного раздела книги:) Ещё раз спасибо, что вы со мной - даже просмотры без комментов дают мне мотивацию продолжать эту работу:)
https://telegra.ph/CHistye-i-gryaznye-funkcii-ehffekty-i-obrabotka-signalov-sajdehffekty-chistye-funkcii-01-12
#posts@ergonomic_code #fp@ergonomic_code
Telegraph
Чистые и грязные функции, эффекты и обработка сигналов, сайдэффекты: чистые функции
Привет! Обращаю ваше внимание, что топик расширился - помимо анонсированных вчера грязных функций, вчера же я ещё "открыл" сигналы.Заголовок конечно длинноват, но пока так:)Но обо всём по порядку и сегодня у нас чистые функции. Чистая функция - это функция…
О, и сегодня нашему канальчику ровно месяц🥳:)
Мне кажется это был не плохой месяц и в будущее этого канала я смотрю с оптимизмом:)
Мне кажется это был не плохой месяц и в будущее этого канала я смотрю с оптимизмом:)
А знаете ли вы, что джетбрейнс ещё и научным ресёчем занимается?:)
https://research.jetbrains.org/annual-report/2020
мне вот любопытно - когда-то были бесплатные эклипсы, нетбинсы и прочий легион всяких жэбилдеров
и они все канули в лету по факту
а платная идея смогла отжать рынок у бесплатных продуктов, заработать на этом и начать инвестировать в ресёч девелопмента нового поколения, тем самым ещё дальше улетая от конкурентов по качеству продукта.
как им это удалось?:)
ну и заодно призываю всех, кто юзает в коммерческих целях кряканые идеи - таки купить её. это, возможно, лучшая инвестиция в 10-20 баксов в месяц, которую вы можете сделать:)
https://research.jetbrains.org/annual-report/2020
мне вот любопытно - когда-то были бесплатные эклипсы, нетбинсы и прочий легион всяких жэбилдеров
и они все канули в лету по факту
а платная идея смогла отжать рынок у бесплатных продуктов, заработать на этом и начать инвестировать в ресёч девелопмента нового поколения, тем самым ещё дальше улетая от конкурентов по качеству продукта.
как им это удалось?:)
ну и заодно призываю всех, кто юзает в коммерческих целях кряканые идеи - таки купить её. это, возможно, лучшая инвестиция в 10-20 баксов в месяц, которую вы можете сделать:)
JetBrains Research: uniting scientists at the cutting edge
JetBrains Research - Annual Report 2020
JetBrains Research unites scientists working in challenging new disciplines
Рич Хикки
Привет!
Сегодняшний линкопост будет о хорошем человеке - Ричи Хикки.
На мой взгляд это один из самых крутых чуваков современного ИТ.
Я поленился искать пруфы, поэтому вот спекулятивная версия его биографии, на основе моих обрывочных воспоминаний:)
Когда-то закончил стендфорд. Потом писал какой-то софт на С++ для радиостанций. Потом плюсы его окончательно доканали и он в счёт своих пенсионных сбережений в 2005 взял отпуск, чтобы написать Кложуру - на мой взгляд очень интересный язык о котором я ещё напишу - которую зарелизал 2007.
Потом в 2012 на своей Кложуре запилил Datomic - на мой взгляд очень интересную СУБД, о которой я ещё напишу:) - которую невозможно было написать ни на каком другом языке,
Потом где-то в районе 2018 на своих Кложуре и Датомики запилил Datomic Ions - с этой штукой я не разбирался подробно, на кажись она тотально решает проблему персистанса в информационных системах. А персистанс, по моим ощущениям - это самя большая жопа в информационных системах, если не всём ИТ.
Так вот если он держал в голове Ions, когда уходил в отпуск в 2005 году - я просто снимаю шляпу, это дичайший респект и уважуха.
Ну и судя по ценам на Датомик (от $5K в год) пенсионные накопления ему не сильно пригодятся:)
Наконец, самый известный и популярный его доклад, который рекомендуют, все кто его видел - Simple Made Easy. Доклад о том, что лёгкое и прывычное != простое и что современная индустриях тяготеет к лёгкому, хотя простое даёт лучшие результаты.
Ну и ваще он прикольный докладчик и ему есть что сказать в целом об ИТ - его видосы можно смотреть все подряд
#posts@ergonomic_code #clojure@ergonomic_code
Привет!
Сегодняшний линкопост будет о хорошем человеке - Ричи Хикки.
На мой взгляд это один из самых крутых чуваков современного ИТ.
Я поленился искать пруфы, поэтому вот спекулятивная версия его биографии, на основе моих обрывочных воспоминаний:)
Когда-то закончил стендфорд. Потом писал какой-то софт на С++ для радиостанций. Потом плюсы его окончательно доканали и он в счёт своих пенсионных сбережений в 2005 взял отпуск, чтобы написать Кложуру - на мой взгляд очень интересный язык о котором я ещё напишу - которую зарелизал 2007.
Потом в 2012 на своей Кложуре запилил Datomic - на мой взгляд очень интересную СУБД, о которой я ещё напишу:) - которую невозможно было написать ни на каком другом языке,
Потом где-то в районе 2018 на своих Кложуре и Датомики запилил Datomic Ions - с этой штукой я не разбирался подробно, на кажись она тотально решает проблему персистанса в информационных системах. А персистанс, по моим ощущениям - это самя большая жопа в информационных системах, если не всём ИТ.
Так вот если он держал в голове Ions, когда уходил в отпуск в 2005 году - я просто снимаю шляпу, это дичайший респект и уважуха.
Ну и судя по ценам на Датомик (от $5K в год) пенсионные накопления ему не сильно пригодятся:)
Наконец, самый известный и популярный его доклад, который рекомендуют, все кто его видел - Simple Made Easy. Доклад о том, что лёгкое и прывычное != простое и что современная индустриях тяготеет к лёгкому, хотя простое даёт лучшие результаты.
Ну и ваще он прикольный докладчик и ему есть что сказать в целом об ИТ - его видосы можно смотреть все подряд
#posts@ergonomic_code #clojure@ergonomic_code
Эргономичный код
Хорошие книги: Designing Data-Intensive Applications Привет! Четверговые посты начну с рубрики "хорошие книги". А рубрику "хорошие книги" начну с актуального - Designing Data-Intensive Applications. Эту книгу я читаю сейчас и прочитал пока только треть…
Привет!
Осилил наконец эту книгу. Крута книга:)
Особенно раздел "Doing the Right Thing". Очень советую прочитать хотя бы эти 10 страниц.
Там первый раздел о последствия хпередачи власти машинам (смотрю на тебя, Руслан:) ), а второй о последствиях установки шпинского ПО от гугла на какое-либо устройство в каждом доме плаенты:)
А как прочитаете - приходите делать кубит - вместе мы сделаем лучший мир для наших детей:)
Осилил наконец эту книгу. Крута книга:)
Особенно раздел "Doing the Right Thing". Очень советую прочитать хотя бы эти 10 страниц.
Там первый раздел о последствия хпередачи власти машинам (смотрю на тебя, Руслан:) ), а второй о последствиях установки шпинского ПО от гугла на какое-либо устройство в каждом доме плаенты:)
А как прочитаете - приходите делать кубит - вместе мы сделаем лучший мир для наших детей:)
GitHub
GitHub - d-r-q/qbit: qbit is a kotlin-multiplatform embeddable decentralized DBMS with object-relational information model
qbit is a kotlin-multiplatform embeddable decentralized DBMS with object-relational information model - d-r-q/qbit