Тут кто-то сделал альтернативный клиент для Твиттера, причем на языке Nim. Все бы ничего, но по запросу Nitter в гугле 1я ссылка на Urban Dictionary. Не сильно привлекательно :D

Но хоть значание слова не сильно упоротое (внезапно в топе значений - cat). В общем перед наименованием проекта/продукта лучше проверить выдачу гугла и || проверить значения на UB, лишний раз не будет)

https://habr.com/ru/post/469249/
https://www.urbandictionary.com/define.php?term=Nitter

Статья с обзором алгоритмов отрисовки дерева гита, блин, а ведь это интересная вещь, никогда не задумывался как оно работает.

https://pvigier.github.io/2019/05/06/commit-graph-drawing-algorithms.html

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can't run at the same time as any of your other unit tests
• You have to do special things to your environment to run it.

—by mfeathers
https://twitter.com/davecheney/status/1178289934542655489?s=21

10 введений в архитектуру из 10

Эхххх, сидишь досматриваешь Футураму, а в слаке алерт за алертом, а я не дежурный. Отличное воскресенье. Кстати, а посоветуйте какие-то мультики, чего время терять зря ¯\_(ツ)_/¯

Ну правда же...(тред: https://twitter.com/dhh/status/1177974040432037888)

Вчера столкнулся с неприятной фичей(?) godoc.

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

Да, тот момент, когда явный конструктор в го был бы кстати.

Док https://godoc.org/github.com/cristalhq/zookeeper
Код https://github.com/cristalhq/zookeeper/blob/master/commands.go#L92 #hq

ps. лол, не замечал раньше код ~ док 🤔

Ща будет пост без пруфов о том, что лучше доводить вещи до конца, ну или хотя бы постить результаты-мысли-идеи.

Где-то 4 года назад, сидя в офисе после работы я сидел и оптимизировал алгоритм сортировки. Зачем? да кто знает, мне было нечем заняться, а после собесов в Амазон желание писать алгоритмы возобновилось.

И вот, после реализации нескольких странных структур данных (дерево сегментов, Фенвика, еще что-то), пачки алгоритмов для деревьев (при чём все писалось в читаемом/неолимпиадном стиле, для потомков, на Си), я пришел к алгоритму сортировки.

К сожалению N*LogN побороть я не смог[citation needed], поэтому занялся оптимизацией на практике. Не, не переписыванием всё на векторизированный ассемблер, а просто прикидывал, как так перекрутить данные, чтобы меньше прыгать по рам-у.

Штош, я пришёл к тому же, к чему пришел и уважаемый Александреску(или это он после меня 🤔), о чём рассказано в его докладе и этой записи https://t.me/peterblog/1078 Пересказывать нет смысла, лучше прочитать пост Петра или глянуть доклад.

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

(еще чуток про конфу С++ тут https://t.me/experimentalchill/21)

Пришло время ругаться на spring framework. Ну ладно, не совсем. В великой Intellij IDEA есть такая штука как Inspect Code, которая прогоняет разные проверки по коду и ругается, ничего особенного.

Проблема вот в чем, если вы определили какой-то ендпоинт(класс + аннотация RestController), то из-за того, что все это будет подтянуто в рантайме (разве нет?), класс явно не будет использован. Уже догадываетесь к чему это ведёт?

Правильно, целый класс с ендпоинтами никто _явно_ не инстанцирует, соотв все публичные методы никто не использует, и да, соотв любые поля в классе тоже. А так как мы пишем вебсервисы и гребём в море микросервисов, то вся архитектура состоит из нескольких слоёв, в каждом из которого по одной вещице (restcontroller -> service -> storage).

Некоторые методы в условном Storage не используются, потому что по стеку выше ничего не вызывается, хоть в коде это явно и написано. Такие дела (конфиг в иде не нашел, поэтому жалуюсь).

вруби все настройки, сказал я себе
заработало, скажу я вам

и плагином можно https://www.jetbrains.com/help/idea/context-and-dependency-injection-cdi.html

но это не отменяет того, что махинации с МОИМИ КЛАССАМИ В РАНТАЙМЕ это круто. Это вообще не круто.

А если хочется еще покатать модельки по гошному коду, то можно обратиться к Брэду, он идеи ищет для дампа прокси https://twitter.com/bradfitz/status/1178677638669336576

Аналитика 10 лямов репозиториев

Безумный дядька сделал аналитику огромного количества открытых реп в гитхабе/битбакете/гитлабе, посчитал файлики, запуская это всё лямбдой на AWS, а данные вытягивая с S3. В итоге всё стоило под 80 баксов.

В чём прикол? (помимо того, что это оказалось не слишком дорого и вообще посчиталось нормально)

Написана тулзовина была на Go.
Мораль: ресёч, когда нужно было просто погонять данные (или поскрапить их) да формировать json-результаты? Go, я выбираю тебя *бросает_покебол*

Такс, я наконец-то прочитал эту статью: Сложность простоты https://habr.com/ru/post/469441/

0. Она отлично написана, очень приятно читать.

1. Стало обидно за плохой отзыв о чате го в телеге, но про кол-во флуда и пустых советов все же правда, к сожалению так устроены чаты.

2. Победа в простоте работы с хаскеллом была видна из заголовка и конечно же из-за переиспользования чужого кода: вот тебе дженерики, вот тебе код, подставляй свое.

3. Однопоточный код на го оказался проще и не требовал ничего, кроме как компилятора.

4. Понравилась фраза: Идеология го, в свою очередь, скорее "код должен быть достаточно простым, чтобы в случае изменения требований его легко было выкинуть и написать новый".
Что-то в ней есть, интерфейсы(+конракты?) тому подтверждение, если не писать в жава-стиле.

5. commentsTree <- mapConcurrently getCommentById tree смотрися круто, но отличается от реализации в го на одну вещь: оно все делает за тебя. Хорошо это или плохо - сильно зависит от контекста, поэтому 2 решения не совсем правильно сравнивать. Либо мы берём и ручками стартуем треды/гринтреды в Хаскелле, либо ищем необходимую библиотеку на го и реализуем интерфейс, чтобы оно само посчитало и собрало результаты.

6. "параллелизация заключалась в изменении одной строчки, а не переосмыслении всей программы" - хочется, но нет.

И даже после всего этого что-то заставляет людей тащить го в прод и строить продукты...А статья хорошая, да.

Вечное

Continuous Profiling in #Go

https://docs.google.com/document/d/1GKcH3bo3bbZ2wNSqQnmdK-z98c71Qmmfo8ZEVRGgDKE/edit#

И сразу репка https://github.com/profefe/profefe

Достаточно важное: формат профилей pprof совсем не привязан к Go. Для Java, JavaScript, Python и пр. есть библиотеки позволяющие получить данные профилирования в формате pprof. Возможно, profefe может стать полезным сервисов для приложений написанных на других языках.

возможно сегодня я сделал чью-то жизнь чуть приятнее. круто.