# 2019-12-05
JetBrains представила Space ‒ продукт для облегчения коллективной разработки проектов.
https://www.jetbrains.com/space
Фактически это Jira на стероидах или "швейцарский нож" для разработки:
- рабочие чаты
- календарь
- вики
- трекер задач
- блоги
- контроль версий
- CI/CD
- artifactory и docker registry (и package management в целом, включая distibution)
Может быть cloud или hosted. Для маленьких cloud бесплатно.
То, что сейчас показано на сайте и в превьюшках/скринах, выглядит очень круто.
На перезентации сказали, что есть мобильные приложения, которые написаны на Kotlin/Multiplatform. То есть вся логика у них шарится (JS/iOS/Android).
JetBrains представила Space ‒ продукт для облегчения коллективной разработки проектов.
https://www.jetbrains.com/space
Фактически это Jira на стероидах или "швейцарский нож" для разработки:
- рабочие чаты
- календарь
- вики
- трекер задач
- блоги
- контроль версий
- CI/CD
- artifactory и docker registry (и package management в целом, включая distibution)
Может быть cloud или hosted. Для маленьких cloud бесплатно.
То, что сейчас показано на сайте и в превьюшках/скринах, выглядит очень круто.
На перезентации сказали, что есть мобильные приложения, которые написаны на Kotlin/Multiplatform. То есть вся логика у них шарится (JS/iOS/Android).
# 2020-01-16
JetBrains сделали шрифт специально для разработки. Осовременели и эту область. В нем все прекрасно: и продуман для долгой работы с текстом, и выглядит хорошо, и лигатуры есть.
Я до этого использовал везде Fira Code, но этот приятней.
https://www.jetbrains.com/lp/mono/
https://blog.jetbrains.com/blog/2020/01/15/jetbrains-mono-a-new-font-made-for-developers/
JetBrains сделали шрифт специально для разработки. Осовременели и эту область. В нем все прекрасно: и продуман для долгой работы с текстом, и выглядит хорошо, и лигатуры есть.
Я до этого использовал везде Fira Code, но этот приятней.
https://www.jetbrains.com/lp/mono/
https://blog.jetbrains.com/blog/2020/01/15/jetbrains-mono-a-new-font-made-for-developers/
# 2020-02-05
Мне очень нравится "Дзэн" языка программирования Python. В какой-то момент он стал настолько популярен, что даже вошел в сам интерпритатор в виде вызова 'import this'.
"Дзэн" состоит из принципов, которыми руководствовались при разработке языка. Но они настолько универсальны, что, кажется, подходят вообще для всего. Слегка изменив пару формулировок, можно приписать их к любому жизненному процессу.
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
А написал его один из основных контрибуторов языка ‒ Tim Peters.
Мне очень нравится "Дзэн" языка программирования Python. В какой-то момент он стал настолько популярен, что даже вошел в сам интерпритатор в виде вызова 'import this'.
"Дзэн" состоит из принципов, которыми руководствовались при разработке языка. Но они настолько универсальны, что, кажется, подходят вообще для всего. Слегка изменив пару формулировок, можно приписать их к любому жизненному процессу.
The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
А написал его один из основных контрибуторов языка ‒ Tim Peters.
Фундаментальное введение в stuctured concurrency
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Статья показывает мысль программиста с 50-х годов прошлого века по наши дни: о важности flow control и как менялись парадигмы; как Дейкстра объявил войну goto, а Кнут наоборот заступался.
Подобные "black box rule" требования к flow control можно спроецировать на concurrency. В итоге приходим к подобию CoroutineContext в Kotlin и получаем простой и понятный механизм cancellation и error handling.
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Статья показывает мысль программиста с 50-х годов прошлого века по наши дни: о важности flow control и как менялись парадигмы; как Дейкстра объявил войну goto, а Кнут наоборот заступался.
Подобные "black box rule" требования к flow control можно спроецировать на concurrency. В итоге приходим к подобию CoroutineContext в Kotlin и получаем простой и понятный механизм cancellation и error handling.
Ребята сделали bug-tracker прямо в git. CLI, веб-клиент и прочие плюшки. Все синкается с issues github, gitlab и прочими, если надо.
Странно, что раньше никто до подобного не додумался. Простые решения типа этого прекрасны.
https://github.com/MichaelMure/git-bug
В качестве примера подобного решения я в личных целях для доков/вики/тасок не использую никаких сервисов, а просто веду каталоги с markdown-документами с линками друг на друга и синкаю через git или Dropbox.
Странно, что раньше никто до подобного не додумался. Простые решения типа этого прекрасны.
https://github.com/MichaelMure/git-bug
В качестве примера подобного решения я в личных целях для доков/вики/тасок не использую никаких сервисов, а просто веду каталоги с markdown-документами с линками друг на друга и синкаю через git или Dropbox.
GitHub
GitHub - git-bug/git-bug: Distributed, offline-first bug tracker embedded in git
Distributed, offline-first bug tracker embedded in git - git-bug/git-bug
Важность GitHub'а осознаешь больше всего, когда он ложится.
Это как радар в Counter-Strike: когда он есть ты его не замечаешь, но, если его отключить, то резко ощущаешь нехватку.
Это как радар в Counter-Strike: когда он есть ты его не замечаешь, но, если его отключить, то резко ощущаешь нехватку.
Если ностальгический интерфейс Windows-98 вызывает у вас скупую гендерно-нейтральную слезу, то вот набор CSS для домашнего творчества, с которым можно повеселить друзей.
https://jdan.github.io/98.css
https://jdan.github.io/98.css
jdan.github.io
98.css
A design system for building faithful recreations of old UIs.
Во время карантина меня E-Legion позвали на митап на тему "Советы новичкам в мобильной разработке".
Сформулировав свои мысли, вот что на мой взгляд важно:
Надо учиться. Если уметь что-то делать хорошо, то можно устроиться в большую компанию, где вас будут облизывать, или, если есть творческая жилка, то сделать что-нибудь свое.
Способов учиться сейчас очень много:
- масса литературы и блогов
- мировые ВУЗы предлагают свои программы, зачастую бесплатно
- Udemy
Держитесь значимых людей (на работе, в индустрии, среди друзей). Это поможет поймать правильный "вижн" и узнать как думают разумные и более опытные люди.
Необходимо знать английский. Дело даже не только в том, что индустрия говорит на этом языке, а в том, что все изменения происходят на английском, и в переводе вы всегда будете опаздывать на полгода-год.
Сформулировав свои мысли, вот что на мой взгляд важно:
Надо учиться. Если уметь что-то делать хорошо, то можно устроиться в большую компанию, где вас будут облизывать, или, если есть творческая жилка, то сделать что-нибудь свое.
Способов учиться сейчас очень много:
- масса литературы и блогов
- мировые ВУЗы предлагают свои программы, зачастую бесплатно
- Udemy
Держитесь значимых людей (на работе, в индустрии, среди друзей). Это поможет поймать правильный "вижн" и узнать как думают разумные и более опытные люди.
Необходимо знать английский. Дело даже не только в том, что индустрия говорит на этом языке, а в том, что все изменения происходят на английском, и в переводе вы всегда будете опаздывать на полгода-год.
Ноутбук довольно долго шумит кулером, а я ничего особенного не делаю. Запускаю менеджер процессов, чтобы найти виновного. Но как только он запускается, шум прекращается и все приходит в норму.
Система: "Он начал что-то подозревать, сворачиваемся!"
Уже не в первый раз такое 😳
Система: "Он начал что-то подозревать, сворачиваемся!"
Уже не в первый раз такое 😳
Гороскоп программиста
♈️ Овен
Отличный день, чтобы экспериментировать с дизайном
♉️ Телец
Постарайтесь не смотреть на QA сверху вниз, сегодня им, как никогда, нужна ваша поддержка
♊️ Близнецы
Проявите осторожность при выборе дня релиза
♋️ Рак
Не начинайте больших задач, обратите больше внимания на миты
♌️ Лев
Звезды рекомендуют заняться рефакторингом, который вы долго откладывали
♍️ Дева
У вас получится взять на себя чужие баги, но это может привести к проблемам на CI
♎️ Весы
Сегодня ваши эстимейты будут точнее, чем обычно
♏️ Скорпион
Удачное время, чтобы оформить отпуск или конференцию
♐️ Стрелец
Не скупитесь на теплые слова тем, кто вас ревьюит
♑️ Козерог
Сегодня вам не стоит заниматься апдейтом серверов
♒️ Водолей
Хороший день, чтобы поспорить о роадмапе проекта
♓️ Рыбы
Разбрасываться словами в Wiki не принесет вам ничего хорошего
♈️ Овен
Отличный день, чтобы экспериментировать с дизайном
♉️ Телец
Постарайтесь не смотреть на QA сверху вниз, сегодня им, как никогда, нужна ваша поддержка
♊️ Близнецы
Проявите осторожность при выборе дня релиза
♋️ Рак
Не начинайте больших задач, обратите больше внимания на миты
♌️ Лев
Звезды рекомендуют заняться рефакторингом, который вы долго откладывали
♍️ Дева
У вас получится взять на себя чужие баги, но это может привести к проблемам на CI
♎️ Весы
Сегодня ваши эстимейты будут точнее, чем обычно
♏️ Скорпион
Удачное время, чтобы оформить отпуск или конференцию
♐️ Стрелец
Не скупитесь на теплые слова тем, кто вас ревьюит
♑️ Козерог
Сегодня вам не стоит заниматься апдейтом серверов
♒️ Водолей
Хороший день, чтобы поспорить о роадмапе проекта
♓️ Рыбы
Разбрасываться словами в Wiki не принесет вам ничего хорошего
Инсайты из мира веба и Typescript
Несмотря на полную поддержку типов и классов, в вебе принято использовать классические JS objects + functions, в частности для моделей.
Для людей из Java/Kotlin/C#/Go это выглядит немного странно. Они видят классы в Typescript и пихают их везде, где можно по умолчанию, когда в JS/TS – это не всегда лучшее решение.
Это обусловлено тем, что многие вещи так сложились исторически, что сделать что-либо проще с объектами. Например, нет способа автоматически вызвать конструктор класса с правильными аргументами. То есть, для клонирования (deep copy) инстанса класса нужно:
- либо использовать библиотеку типа Lodash.deepClone();
- либо писать особую JS-магию, которая не факт, что будет покрывать все случаи;
- либо вручную писать код для клонирования каждого экземпляра класса вручную.
А для JS-объектов есть простое решение в виде использования Spread syntax и, вуаля, данные скопированы.
Еще в вебе нечасто разделяют DTO и модели. Как правило, это одни и те же сущности из-за того что они совпадают с сущностями API, а формат данных в вебе редко меняется (какие-нибудь Protobuff/CBOR здесь редкость), поэтому DTO абстракцию никто обычно не делает.
Несмотря на полную поддержку типов и классов, в вебе принято использовать классические JS objects + functions, в частности для моделей.
Для людей из Java/Kotlin/C#/Go это выглядит немного странно. Они видят классы в Typescript и пихают их везде, где можно по умолчанию, когда в JS/TS – это не всегда лучшее решение.
Это обусловлено тем, что многие вещи так сложились исторически, что сделать что-либо проще с объектами. Например, нет способа автоматически вызвать конструктор класса с правильными аргументами. То есть, для клонирования (deep copy) инстанса класса нужно:
- либо использовать библиотеку типа Lodash.deepClone();
- либо писать особую JS-магию, которая не факт, что будет покрывать все случаи;
- либо вручную писать код для клонирования каждого экземпляра класса вручную.
А для JS-объектов есть простое решение в виде использования Spread syntax и, вуаля, данные скопированы.
Еще в вебе нечасто разделяют DTO и модели. Как правило, это одни и те же сущности из-за того что они совпадают с сущностями API, а формат данных в вебе редко меняется (какие-нибудь Protobuff/CBOR здесь редкость), поэтому DTO абстракцию никто обычно не делает.
Zaplib все. Там есть довольно важные инсайты относительно производительности JS и рендеринга.
https://zaplib.com/docs/blog_post_mortem.html
https://zaplib.com/docs/blog_post_mortem.html
Вот вы смеетесь над моей любовью к SQLite, а она все более и более популярна. На прошлой неделе так и вовсе жара была.
Cloudflare выпустил свою распределенную версию SQLite для своего облака. В их лямбдах можно теперь обращаться к базе, и с учетом их опыта с Durable Objects (key-value cloud storage), думаю, они умеют делать это хорошо.
А до этого был пост от создателя BoltDB про Litestream, который он делает.
Я уж не говорю про другие подобные решения наподобие Canonical Dqlite или rqlite.
Не так давно предлагал подобный подход к хранению данных для Firebase-подобного сервиса другу: много пользователей, у каждого есть своя база со своими данными и со своей структурой.
При условии существования реплик – чтение становится фактически неограниченным. Запись для скорости делается через WAL-журнал и сразу реплицируется. Скейлится все это безгранично по вашему желанию: хотите отдельный storage per client, хотите по country и т.д.
Долой ваши сложные/неудобные/нереляционные СУБД! Давно использую SQLite на бэке и супер-доволен.
Cloudflare выпустил свою распределенную версию SQLite для своего облака. В их лямбдах можно теперь обращаться к базе, и с учетом их опыта с Durable Objects (key-value cloud storage), думаю, они умеют делать это хорошо.
А до этого был пост от создателя BoltDB про Litestream, который он делает.
Я уж не говорю про другие подобные решения наподобие Canonical Dqlite или rqlite.
Не так давно предлагал подобный подход к хранению данных для Firebase-подобного сервиса другу: много пользователей, у каждого есть своя база со своими данными и со своей структурой.
При условии существования реплик – чтение становится фактически неограниченным. Запись для скорости делается через WAL-журнал и сразу реплицируется. Скейлится все это безгранично по вашему желанию: хотите отдельный storage per client, хотите по country и т.д.
Долой ваши сложные/неудобные/нереляционные СУБД! Давно использую SQLite на бэке и супер-доволен.