Внезапно, про PHP. Комьюнити выбирает как развивать язык, вводить ломающие совместимость изменения и не повторять ошибок Python 2/3, Perl 5/6 и других героев.

Будущее развитие PHP

https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md

Никита опубликовал черновик RFC с предложением установить механизм введения в язык новых глобальных или ломающих обратную совместимость фич. И рассмотрел возможные пути решения:

1. Новый язык (P++)
При всех своих недостатках, одно из преимуществ тут в том, что можно делать совершенно радикальные изменения. Например, убрать $ из переменных. Но мы помним судьбу Perl/Raku.

2. Editions (редакции/издания)
Идея позаимствована из Rust, в разработку которого Никита тоже вовлечён.
По сути, это набор обратно-несовместимых изменений, объединенных под одним именем. Такой вариант интересен как с технической так и с маркетинговой точки зрения.

3. Директивы declare на каждую фичу
То есть на каждое крупное изменение вводить отдельную директиву по типу strict_types.
___

Поскольку против нового языка уже неофициально проголосовали и единогласно отмели идею, то дальше Никита рассматривает технические аспекты реализации единшов/директив.
Варианты тут такие:

• Текущая реализация с объявлениями в каждом файле
declare(strict_types=1) или в случае едишнов declare(edition=2020)

• Новый открывающий тег
Например, для едишнов: <?php2020

• Указание директив для пространств имён (RFC)

namespace_declare('Vendor\Lib', [
    'strict_types' => 1,
    'no_dynamic_properties' => 1,
    // ...
]);

• Ввести понятие пакета в PHP
Прототип этого варианта оформлен в виде пул-реквеста.
Пакет надо будет явно объявлять в каждом файле.

<?php

package "nikic/php-parser";

namespace PhpParser\Node;

• Что-то на основе файловой системы
Например добавлять файл .package.php в корне пакета, который будет содержать нужную метаинформацию.

В конце Никита подводит выводу, что оптимальный вариант — это едишны + declare директивы в каждом файле.

☕️ В JavaMagazine опубликовали статью о Records, которые завезут в следующую версию Java.

Records уменьшают бойлерплейт для data-only структур данных, автоматические геттеры и конструкторы. Почему бы и нет?

https://blogs.oracle.com/javamagazine/records-come-to-java

#java

📼 И сразу добью шикарным докладом 1998 (!!!) года Гая Стила про развитие языков программирования.

Крайне рекомендую посмотреть. Во-первых, любопытно как Стил топит за добавление в Java дженериков (привет, golang) и перегрузки операторов. Во-вторых, сама подача материала - не хочу спойлерить, но форма подчеркивает содержание - программистам всегда нужно строить мелкие абстракции чтобы перебраться на более высокий уровень. И важно сделать это просто.

Ну и отдельный фан увидеть конференцию разработчиков 22 года назад: докладчик в пиджаке, в нагрудном кармане батарея из ручек, слайды на проекторе - обалденно.

https://www.youtube.com/watch?v=_ahvzDzKdB0

P.S. Можете еще почитать о самом Гае Стиле на википедии. Это один из гигантов computer science, и мы стоим на его плечах в том числе

#video

Вспомнил крутую статью с пачкой Serverless паттернов, все про AWS, но и 1в1 на других провайдерах применяется)

Текст можно особо не читать, достаточно картинки глянуть, все просто и понятно.

https://www.jeremydaly.com/serverless-microservice-patterns-for-aws/

Короткий анализ языков, которые команда Fuchsia будет поддерживать и развивать для разработки самой ОС и приложений для нее.

Спойлер: Dart - да, GoLang - нет. Потому что GC, большой рантайм и негативный опыт использования.

https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md#Go

#fuchsia #c #cpp #dart #rust #golang

Там FB свой мессенджер переписывает, и эт конечно интересно-полезно, хотя много чего не досказано. Понравились коменты с ХН:

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment:

- NumPy is 360K lines mostly C
- Postgres is around 2.1M of C
- Go 1.13 is around 1.5M of Go code
- Rust 1.37 is around 1.2M of Rust code iirc
- core llvm is around 3M of C++ iirc
...
A chat app is 1.7M. A chat app...

Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've worked together on something truly awesome, big and useful. But we all know that doesn't pay the bills and so here we are.

> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat
To be fair, this is part of the problem ^

https://engineering.fb.com/data-infrastructure/messenger/
https://news.ycombinator.com/item?id=22466462

Да, конечно мерять все в SLOC это так себе метрика, но и пренебрегать ею неправильно.

📝 webpack двигается в сторону micro frontends.
Micro frontends - это идея микросервисов переложенная на фронтенд, то есть части страницы делятся на самостоятельные изолированные приложения. Эти части могут быть реализованы разными командами и на разном технологическом стеке.
https://micro-frontends.org

Представим себе крупный сервис с множеством функциональных частей: поиск, фильтры, каталог, реклама, навигация и т.д.
Очень часто эти части могут встречаться на одной странице, но при этом разрабатываться разными командами и с использованием разных подходов к разработке (ведь каждая команда лучше знает "как правильно" ;)). В этом случае встает некоторое количество вопросов, например:

Как разделить большую кодовую базу на микро-приложения?

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

Как части приложения могут "общаться" между собой?

Например, в условиях SPA (single page application) фильтры могут влиять на каталог.

Как обеспечить реиспользование зависимостей?

Например, на странице загружен блок, который использует react и redux. Чуть позже, на страницу, динамически, подъезжает второй блок, который тоже использует react. Проблема в том, что этот блок разрабатывается другой командой, собирается и релизится отдельно от первого. Здесь необходимо обеспечить совместимость двух блоков и реиспользование уже загруженных на страницу зависимостей - второй блок не должен заново загружать на страницу react, а должен реиспользовать уже загруженный.

Около месяца назад было предложено архитектурное решение для webpack https://github.com/webpack/webpack/issues/10352 и буквально несколько дней назад были сделаны первые демо.
Описание решения можно найти тут https://medium.com/@ScriptedAlchemy/bcdd30e02669, а потыкать можно вот эту демку https://github.com/mizx/mfe-webpack-demo

Если коротко, то идея заключается в том, что совершенно разные собранные бандлы могут реиспользовать различные части друг-друга - одни бандлы предоставляют (expose) свои части (например UI-компоненты или целое приложение), а другие бандлы эти части импортируют и используют.
Фича все еще в разработке

#webpack #webpack5 #microfrontends

🎙 Ура, 9 выпуск WatEvoCast! В этот раз про PyConBy'20
Apple Podcast
#watevocast

👩‍💻 Внезапно на hackernews в топ вышла статья на вики про Катерину Ющенко, украинскую программистку, которая написала один из первых адресных языков программирования.

Сейчас развитие этих идей мы видим в указателях (pointers), адресной арифметике и прочих важных штуках.

Катерина Ющенко на Википедиях: укр, рус, англ
Тред на хакерньюз

#person #girlpower #cs

🐍 Вышла очередная альфа следующего релиза Python 3.9. Главное, что нас ожидает:

1. Новые операторы у диктов для слияния (dict1| dict2) и дополнения (dict1 |= dict2). Все существующие варианты решения такой пустяковой проблемы либо достаточно громоздкие, либо неочевидны синтаксически
2. Расширение аннотаций. В данный момент большая часть аннотаций - это аннотации типами. Хотя в целом эта фича имеет гораздо больше потенциал. От валидции, до навешивания новой логики переменной. Новый класс Annotated позволит это исправить
3. Переход на релизный цикл раз в год. До этого конкретной даты не было и релиз происходил тогда, когда разработчики считали что продукт готов

Код фриза для версии еще не произошло, возможно появиться еще что-то интересное.

#python

📺 Регулярные встречи разработчиков Evo по понятным причинам переезжают в онлайн. Прямо сейчас начинаем трансляцию первой такой встречи на ютубе.

Наш лучший специалист Александр Мостовенко будет рассказывать о типизации в TypeScript

https://youtu.be/Yd_otKlrf1I

🍴 Почти лонгрид о том, как git стал главной системой контроля версий. От первых версий Линуса до покупки Microsoft`ом GitHub.

#git

https://www.welcometothejungle.com/en/articles/btc-history-git

Недавно в Firefox была обнаружена проблема с кешированием данных в Twitter. Любой пользователь с физическим доступом к компьютеру теоретически мог прочитать чужие личные сообщения. Мартин Томсон из команды разработки Firefox рассказал, почему это произошло, в статье "Twitter Direct Message Caching and Firefox".

Чтобы предотвратить кеширование контента в браузерах, сайт должен отправить в ответе http-заголовок Cache-Control: no-store. В любом другом случае в Firefox начинает работать механизм эвристического кеширования. Этот механизм используется для предсказания, какой контент может быть закеширован и на какое время. Контент без Cache-Control: no-store сохраняется в кэше на семь дней. Как вы наверное уже догадались Twitter не отправлял этот заголовок в ответе из-за чего в Firefox включался механизм кеширования. Вместо него Twitter отправлял заголовок Content-Disposition, который используется для добавления метаинформации (например, имени файла) к загружаемым файлам. В статье говорится, что в "other browser" (как я понимаю Chrome) наличие этого заголовка отключает кеширование, но это поведение не является частью стандарта.

Какие можно сделать выводы из этой истории? Нужно проверять работу сайта в разных браузерах (Chrome, Firefox, Safari) и не стоит полагаться на поведение браузера, которое не соответствует стандартам.

#firefox #cache #http

https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/

🐘 Отличная статья о 10 нюансах PostgreSQL, о которых стоит знать, если вы его активно используете.

Там и переполнение Transaction ID и сборка мусора устаревших строк, и дорогие соединения к базе. Тем не менее вывод:

You should probably still use PostgreSQL and not something else for storing data that you’d ideally like to, you know, keep around for some time.

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

https://medium.com/@rbranson/10-things-i-hate-about-postgresql-20dbab8c2791

#databases

📕 The Svelte Compiler Handbook - емкое описание основных частей Svelte со ссылками для более детального погружения. Для тех, кто хочет начать разбираться во внутренностях фреймворка или читать (и понимать) его исходники.

https://lihautan.com/the-svelte-compiler-handbook/

#javascript

🐍 Про хеширование и равенство в Питоне и других языках

В двух словах: Don’t override hash and eq to force objects to hashable. Use immutable objects instead.

https://eng.lyft.com/hashing-and-equality-in-python-2ea8c738fb9d

#python

📺 Трансляция с DevOps 2020 by Eficode

https://www.eficode.com/devops2020online/track1

#video

#db
Дождались! Долгожданный пост от Яны Доган Things I Wished More Developers Knew About Databases
Мне кажется, что пост получился очень удачным и пробелы по многим пунктам я замечал у коллег(да что уж там, я тоже узнал много нового, например из пункта про часы). Так что, дохрена рекомендую

UPD сорян, ссылка потерялась. Вернул

🔥 Наш лучший специалист, архитектор фронтенда Александр Мостовенко, вошел в топ-3 докладчиков на JavaScript fwdays'20 с рассказом про перевод большого python-монолита на SSR

Вже готовий топ-3 доповідей онлайн-конференції JavaScript fwdays'20 від 21 березня за голосуванням учасників 🤩

1️⃣ @koorchik "Effective NodeJS Application Development"

2️⃣ Олександр Мостовенко " 'Devide et impera' with GraphQL and SSR"

3️⃣ @tshemsedinov "Web Locks API in Node.js and browser"

Посилання на доповіді:
👉 https://www.youtube.com/playlist?list=PLPcgQFk9n9y9jbWCnublMA1D2qbJPLukf