https://gandalf.lakera.ai/

Классная шутка, чтобы почувствовать себя кул-хакером. Иногда вылетает из-за лимитов ChatGPT, но полезная зарядка для ума. Советую записывать свои успешные промпты, чтобы использовать их повторно.

Очень доступная статья, которая объясняет работу простейшего аллокатора памяти “для чайников”.

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

Вначале идет немного теории про разные виды “монолитов”, а потом разбираются собственно ошибки:

1. Предполагать, что микросервисы всегда лучше монолита.
2. Общие модели и/или общая база.
3. Слишком большие микросервисы.
4. Слишком маленькие микросервисы.
5. Начинать построение нового продукта с микросервисной архитектуры.
6. Связывание через инфраструктурный код (логгирование/авторизацию и т.п.).
7. Использование синхронных вызовов между микросервисами.
8. Обратно-несовместимые изменения в событиях.
9. Отсутствие автоматизации релизов.
10. Отсутствие инкапсуляции (когда микросервис слишком много знает о деталях реализации другого микросервиса).
11. Несоответствие организационной структуры архитектуре продукта.

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

Наверняка многие случайно попадали на Rosetta Code, когда пробовали что-то делать простое на не очень знакомом языке. Недавно наткнулся на аналог для JS-фреймворков, хотя там везде выглядит все почти одинаково…

В IntelliJ при поиске можно указать в качестве варианта, где искать, определенный тип кода — например, искать только в тестах. Эти области поиска можно редактировать, добавляя свои. Кроме того, можно настроить цвет отображения в списке всех файлов. В самом окне проекта можно отобразить только тесты/только основные файлы/свою область поиска. Все это можно шарить — это хранится в .idea вместе с остальными настройками проекта.

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

В GitHub вы можете запушить изменения в чужой репозиторий, если он является форком вашего и автор разрешил правки в PR.

Live Reload — это возможность обновления локально запущенного приложения “на лету” при изменении исходного кода вместо того, чтобы его останавливать, перекомпилировать и запускать заново. Эта функция есть много где — например, у фронтендеров в npm, у бэкендеров в Spring, в Jekyll, внезапно в gradle (там это называется continuous build) и т.д. Для реализации этого механизма нужно отслеживать изменения в коде и потом их собственно применять.

Первый этап можно реализовать одним из трех способов:

1. Запомнить состояние исходников (сделать снапшот) и периодически повторять эту процедуру, сравнивая новую версию со старой.
2. Получать и обрабатывать уведомления от файловой системы.
3. Перехватывать системные вызовы.

С первым вариантом все понятно — он проще реализуется, но и более затратен по ресурсам. Второй вариант поинтереснее — у каждой ОС есть свой механизм для этого, со своими приколами. Третий вариант — для упоротых, для решения проблемы это перебор.

В Linux для уведомлений от ФС (второй способ) есть подсистема inotify. Использовать ее довольно просто: создается файловый дескриптор, к нему привязываются подписки на конкретные файлы и/или папки, потом в бесконечном цикле читаем структуры-сообщения об изменениях из дескриптора (ожидание будет за счет блокирующего read).

Кстати, в большинстве случаев за счет уведомлений от ФС работают команды вроде tail -f. Совсем всегда — не получится, т.к. удаленные системы обычно не посылают такой информации.

Механизм применения изменений сильно зависит от инструмента, но обычно сводится наличию демона/лоадера/супервизора, которые ждут сигнала о наличии изменений и при его получении обрабатывают изменения и заменяют текущую версию (перезаписыванием статики, перезагрузкой страницы, перезагрузкой классов из класслоадера и т.п.).

Прикольный доклад с попыткой угадать будущее программирования. Докладчик сначала проехался про то, что мы все еще живем в парадигме программ как преобразователей входа в выход (а не чего-то долгоживущего), потом прошелся по синтаксису, легаси, превосходству визуального представления над текстовым в некоторых ситуациях, типам, отладке, борьбе со сложностью и т.п. В целом довольно лайтовый доклад с юморком. А будущее по мнению автора — за интерактивным программированием, которое решает многие проблемы. Один из примеров интерактивного программирование — питоновские ноутбуки. Не уверен, что согласен с оратором, но боли подсвечены неплохо и есть о чем подумать.

Сабж.

В игре есть сюжет, но не могу сказать, что он блещет художественностью, перестал читать его после третьего задания. По комментариям в поле ответа можно узнать все необходимое. Иногда есть небольшие неточности в задании (взбесил момент, когда в комментах были попутаны “Returned” и “Recovered”, благо в большом тексте все было нормально), но больше расстраивают манипуляции со строками в районе 15 главы. Для некоторых ошибок выдается объяснение, но у меня в основном были просто сырые исключения SQL и TypeError: can't convert undefined to object. Местами торчит диалект MySQL (или SQLite?).

Но в целом неплохой тренажер получается для начального уровня. Всего там 20 заданий на select, join, group by и т.п. и аж одно на delete.