Личный опыт: от frontend-разработчика до руководителя


Делаем веб лучше







Micronaut ворвался в нашу жизнь внезапно, без стука и без объявления войны. О нем пишут новости и читают доклады, и вряд ли найдется джавист, который ни разу не слышал это слово. Micronaut — это современный фреймворк для JVM для написания модульных микросервисов и serverless-приложений, использующий для этого фичи GraalVM.
В свою очередь, Grails — это фреймворк, который появился ещё в 2005 году и с тех пор непрерывно улучшается. В 2015 году Grails 3 переехал на SpringBoot, а версия 4.0.0 появилась в июле прошлого года. У Grails сохраняется своя аудитория, для которой он очень хорошо подходит и решает вполне конкретные проблемы.
Грэм Роше создал оба этих фреймворка. Мы пригласили Грэма в нашу виртуальную студию, чтобы обсудить, зачем было изобретать велосипеды и городить костыли, не закопать ли Grails и Spring Boot, как поддерживать Jakarta EE и не сломаться, что будет в Micronaut 2, стоит ли писать Micronaut поверх Micronaut и когда уже Java наконец помрёт.

class Number {
private int|float $number;
public function setNumber(int|float $number): void {
$this->number = $number;
}
public function getNumber(): int|float {
return $this->number;
}
}В одном из выпусков подкаста "Цинковый прод" мы мельком обсуждали, что нового будет в языке PHP8. После записи я решил написать статью, чтобы сформулировать свои мысли по положению PHP в современной разработке.
Давайте определимся в целом, какую нишу занимал/занимает язык, и куда он движется
Изначально язык позиционировался как простой инструмент, в котором из коробки есть всё необходимое для web.
С одной стороны, это действительно так: без дополнительных библиотек можно, например, вытащить из суперглобальной переменной $_POST параметры POST-запроса и вставить их в mysql с помощью встроенных функций, и это вроде как здорово.
Также очень важно, что модель "рожден, чтобы умереть" (например, в php-fpm) упрощала и упрощает разработку до безумия: не нужно знать, что такое локи, дедлоки, утечки памяти и т.д. Не надо писать await перед каждой строкой кода и т.д.
Скрипт начал работать над входящим HTTP-запросом, поработал в отдельном процессе, ни с кем не общаясь, и сдох, очистив все после себя. Очень просто программировать. Порог входа — около нуля.
Опять же, можно обойтись без роутинга: имя файла — это уже описание роутов.
С другой стороны, увы, есть нюансы. Веб не стал ждать и ушел далеко вперед.



Свежая подборка со ссылками на новости и материалы. В выпуске: 3 новых и 4 принятых RFC предложения для PHP 8, включая объявление свойств в конструкторе, о блокировке PHP-ML из-за плагиата, почему разработчики ненавидят PHP, порция полезных инструментов, видео и многое другое.
Приятного чтения!


В этой статье я хотел бы поделиться способом профилирования и трассировки программ на Go. Я расскажу, как можно это делать, сохраняя код гибким и чистым.
Логирование, сбор метрик и все, что не связано с основной функциональностью какого-либо кода, не должно находиться внутри этого кода. Вместо этого нужно определить точки трассировки, которые могут быть использованы для измерения кода пользователем.
Другими словами, логирование и сбор метрик – это подмножества трассировки.
Шаблонный код трассировки может быть сгенерирован с помощью gtrace.



Возможно, вы уже слышали про Alpine.js. Если нет, то это "Vue.js на минималках". "Angular 1 для миллениалов". Называйте, как хотите, главное, чтобы вам было понятно.
Зачем нам еще один фреймворк? Ну, Alpine хорошо вписывается в свою нишу. По факту, он – альтернатива большим фреймворкам для сайтов, где эти большие фреймворки не нужны. Например, меня, модного web-developer'а, запрягли писать многостраничный сайт. Мне нужно элементарно сделать форму и всякий другой интерактив. Что я буду делать? Возьму jQuery – друзья не поймут, на чистом JS всё писать тоже не комильфо. К тому же я уже знаю реакты, ангуляры и вью, знаю, что такое data-driven подход. Как мне теперь данные до отправки в HTML хранить?
Тут и приходит на помощь Alpine.js. Можно, конечно, Vue или React прикрутить. Но React без JSX никто в здравном уме писать не будет, а Vue минифицированный через CDN весит 34 kB (против 8.1 kB у Alpine). Так и получается, что выбор падает на Alpine.
Сейчас популярно мнение, что текущие Javascript-фреймворки непомерно большие, а новый фреймворк Svelte очень компактный. Поэтому всем нужно переходить на него, и проблема размера JavaScript решится сама собой.
Недавно вышла статья "Хороший ли выбор Svelte для реализации виджета?" с опытом реализации проекта с критичным размером бандла. Это отличный повод проверить обещания пиарщиков Svelte на реальном проекте.
Давайте его проанализируем!