Вот это отличный приём в SQL: JOIN LATERAL - например, выбрать последние 3 продажи по каждому менеджеру.
http://amp.gs/jBYrH

Интересное решение на форуме CKEditor: форум отправлен в архив и вместо этого рекомендуют использовать StackOverflow, дают ссылку на соответсвующий тег

Список обновлений в PHP 8.2 Alpha состоит аж из 14 глав, зачитаешься: http://amp.gs/jBgck


1. Backward Incompatible Changes
2. New Features
3. Changes in SAPI modules
4. Deprecated Functionality
5. Changed Functions
6. New Functions
7. New Classes and Interfaces
8. Removed Extensions and SAPIs
9. Other Changes to Extensions
10. New Global Constants
11. Changes to INI File Handling
12. Windows Support
13. Other Changes
14. Performance Improvements

Читая изменения в PHP 8.2 Alpha порой удивляешься: «а что, разве раньше не так работало? Это же логично, так должно было быть изначально!» http://amp.gs/jBgc4

Читаю статью, автор даёт совет: «не используйте float для денег». Совет стар как мир, вроде все уже давно выучили.

Однако автор приводит пример, однажды он сложил в PHP 149.99 + 159.99 и получил 309.99 вместо 309.98. И тут я насторожился, статейка попахивает упрощениями.

На сложении двух float с двумя знаками после запятой в PHP такую погрешность не словить! Проверьте сами, я проверил на версиях PHP от 4.3 до 8.1: http://amp.gs/jBEym - результат везде верный (309.98).

Так что не храните деньги во float, но если очень надо по быстрому сложить две float суммы - ничего страшного не произойдёт. Знаете контрпример? Присылайте!

Недавно втянулся в использование SQL синтаксиса LEFT JOIN LATERAL. Буквально по-другому стал смотреть на решение некоторых задач!

Проверил по документации, погугил, в популярных PHP ORM – нигде нет поддержки LATERAL, ни в Doctrine, ни в Laravel Query Builder, ни в Yii Query Builder, ни в Cycle ORM.

тут хочу дать пояснение, моё отношение к различным Query Builder и обёрткам над SQL синтаксисом. Вот какой подход я применяю при выборе между написанием простого SQL и использованием Query Builder или ORM...

Serverless postgres https://neon.tech/

Отличная вводная статья о подходе к обновлениям с использованием Feature Flags: http://amp.gs/jBDVA

VK запускает турнир по программированию искусственного интеллекта Russian AI Cup 🏆

Турнир пройдет в формате игры в жанре королевской битвы (Battle Royale). Участникам предстоит запрограммировать искусственный интеллект, который будет управлять ботами-волшебниками. Цель соревнований – остаться единственным выжившим.

Состязание пройдет с 7 по 31 июля на платформе All Cups. Принять участие смогут все желающие — от начинающих программистов до профессионалов. Регистрация уже открыта, первый этап соревнования пройдет 16-17 июля.

- В чём отличие преподавания английского языка для различных профессий (программисты, юристы, ученые...)?
- «Можно говорить грамотно, но неуместно»
- Английский для разработчика — отличается ли подход к обучению чисто программистов (кодеров) и тимлидов?
- Какие бывают уровни знания английского? A1, A2, B1, B2, C1, C2 — что всё это значит?
- Какого уровня достаточно для разработчика?
- А для тимлида или IT-менеджера?
- Сколько времени и усилий нужно для достижения этого уровня?
- Что такое Intermediate-плато и как его пройти?
- Культурный код и его значение уже на этапе собеседования
- Что не важно при обучении английскому языку?
- Как тренировать произношение?
- Насколько русский акцент понятен на слух?
- Грамматические ошибки: критичные и нет
- Самостоятельное обучение до уровня B2 — это реально?
- Рецептивные и продуктивные навыки
- Полезные инструменты и программы для изучения английского языка (в том числе внутри PhpStorm!)
- Пополнение словарного запаса по карточкам — насколько это эффективно?

​​Интересная задумка для пет-проекта: игра «Камень, ножницы, бумага» в виде симуляции естественного отбора.

Очень напряжённое зрелище гарантированно.

#gamedev #кек

Через 15 минут (10:00 мск, 2 июля) начало трансляции PHP митапа из Ульяновска: https://youtu.be/_mRJto4ziBM

Вдохновляющая история перехода к непрерывной поставке и частым релизам: http://amp.gs/jn8fL

В целом содержание статьи коррелирует с моим опытом, ставлю автору плюс и за проделанную работу и за отличную статью!

Laravel Pint 🍺 — консольная утилита для форматирования кода, работает поверх PHP-CS-Fixer. Я пока не успел попробовать, сам пользуюсь ECS (который тоже поверх fixer’а), надо будет сделать сравнение. http://amp.gs/jnmLz

Помните фреймворк Phalcon, который как расширение к PHP (на языке Zephyr) и по тестам очень быстрый?

Я внезапно вспомнил и пошёл читать блог: в планах переписать на чистом PHP, но опционально можно будет установить расширение для ускорения http://amp.gs/jnp3u

💬 "Кто-то спросит: так ли уж часто читается наш код? Разве большая часть времени не уходит на его написание?

Вам когда-нибудь доводилось воспроизводить запись сеанса редактирования? В 80-х и 90-х годах существовали редакторы, записывавшие все нажатия клавиш (например, Emacs). Вы могли проработать целый час, а потом воспроизвести весь сеанс, словно ускоренное кино. Когда я это делал, результаты оказывались просто потрясающими.

Большинство операций относилось к прокрутке и переходу к другим модулям!

- Боб открывает модуль.
- Он находит функцию, которую необходимо изменить.
- Задумывается о последствиях.
- Ой, теперь он переходит в начало модуля, чтобы проверить инициализацию переменной.
- Снова возвращается вниз и начинает вводить код.
- Стирает то, что только что ввел.
- Вводит заново.
- Еще раз стирает!
- Вводит половину чего-то другого, но стирает и это!
- Прокручивает модуль к другой функции, которая вызывает изменяемую функцию, чтобы посмотреть, как она вызывается.
- Возвращается обратно и восстанавливает только что стертый код.
- Задумывается.
- Снова стирает!
- Открывает другое окно и просматривает код субкласса. Переопределяется ли в нем эта функция?
<...>
В общем, вы поняли. На самом деле соотношение времени чтения и написания кода превышает 10:1. Мы постоянно читаем свой старый код, поскольку это необходимо для написания нового кода.

Из-за столь высокого соотношения наш код должен легко читаться, даже если это затрудняет его написание. Конечно, написать код, не прочитав его, невозможно, так что упрощение чтения в действительности упрощает и написание кода. Уйти от этой логики невозможно. Невозможно написать код без предварительного чтения окружающего кода. Код, который вы собираетесь написать сегодня, будет легко или тяжело читаться в зависимости от того, насколько легко или тяжело читается окружающий код. Если вы хотите быстро справиться со своей задачей, если вы хотите, чтобы ваш код было легко писать — позаботьтесь о том, чтобы он легко читался.

You might ask: How much is code really read? Doesn't most of the effort go into writing it?

Have you ever played back an edit session? In the 80s and 90s we had editors like Emacs that kept track of every keystroke. You could work for an hour and then play back your whole edit session like a high-speed movie. When I did this, the results were fascinating.

The vast majority of the playback was scrolling and navigating to other modules!

- Bob enters the module.
- He scrolls down to the function needing change.
- He pauses, considering his options.
- Oh, he's scrolling up to the top of the module to check the initialization of a variable.
- Now he scrolls back down and begins to type.
- Ooops, he's erasing what he typed!
- He types it again.
- He erases it again!
- He types half of something else but then erases that!
- He scrolls down to another function that calls the function he's changing to see how it is called.
- He scrolls back up and types the same code he just erased.
- He pauses.
- He erases that code again!
- He pops up another window and looks at a subclass. Is that function overridden?
<...>
You get the drift. Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code.

Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there's no way to write code without reading it, so making it easy to read actually makes it easier to write.

There is no escape from this logic. You cannot write code if you cannot read the surrounding code. The code you are trying to write today will be hard or easy to write depending on how hard or easy the surrounding code is to read. So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, перевод: Е.Матвеев, ООО Издательство "Питер"

#SoftwareDesign

Дельный комментарий про интеграционные тесты и юнит тесты с конференции DevOops (ссылка с таймкодом на нужный фрагмент): https://youtu.be/0-BAmdZ9MWU?t=2225

Совет: при модернизации legacy приложений, если ценность этой модернизации сомнительна или низка, то такое приложение лучше отдать на поддержку на аутсорс, а самим сосредоточиться на более маржинальных для бизнеса задачах. https://youtu.be/ary7OqYGpI0?t=1789

Мнение: Legacy приложением можно назвать такое, для которого выполняется хотя бы одно из двух условий:

1) Характеристики не достаточны с точки зрения пользователей (ёмкость, время отклика);

2) Скорость внесения изменений в систему не удовлетворяет нашим потребностям.

https://youtu.be/ary7OqYGpI0?t=2413