Вдохновляющая история перехода к непрерывной поставке и частым релизам: 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

Зачем модернизировать legacy приложения? Не ради современных фреймворков и технологий. Смотреть нужно со стороны клиента и создания ценности для него. Обновление технологий лишь инструмент, но не самоцель. Возможно, обновление технологий и не потребуется при модернизации.

В прошлом году я записал два выпуска подкаста про современную разработку на Битрикс.

А недавно в эту же тему подняли на YouTube канале Хекслета, смотрите свежий батл между CTO с большой экспертизой по Битрикс (Иван Поддубный) и core разработчиком Yii (Александр Макаров): http://amp.gs/jnVXm

Послушайте также выпуски Пятиминутки PHP: http://amp.gs/jnVXZ
http://amp.gs/jnVXp

Новый язык программирования от Google: Carbon

http://amp.gs/jn9iq

Совместим с C++, но выглядит современнее и безопасно работает с памятью.

JavaScript → TypeScript
Java → Kotlin
C++ → Carbon

У тимлидов бывает свой «пакет с пакетами» — это Excel с Excel’ями
#подслушановмаршрутке

Образец желтых заголовков: "Масштабирование Laravel до 30 000 запросов в минуту".

Wait... В МИНУТУ?

Обычно запросами меряются в секунду и если перевести в привычную систему измерения, выходит 500 req/sec. Мощно отмасшабировали!

https://subscribe.mateusguimaraes.com/posts/scaling-laravel-to-30-000-requests-sec-and-over-100m-jobs

Можно оформить рассрочку Тинькофф на рассрочку от Яндекса (Яндекс.Сплит) - финтех, который мы заслужили!

Про маржинальность Amazon AWS в инфографике.

Кратко: выручка eCommerce бизнеса составляет 85%, однако профит от eCommerce всего 26%! AWS выходит гораздо более прибыльный бизнес!

http://amp.gs/jnDu7

Вышла версия PhpStorm 2022.2: http://amp.gs/jnufc

Лично меня заинтересовал переход на JetBrains Runtime 17, в котором рендеринг на macOS переведён на Metal. В прошлом году я ставил бета-версии этого рантайма и тогда разницы не заметил. Пошел обновляться, всё пока!

Вот такой интересный стартап со слоганом «Pull Request as a Service». Оплата за результат, напоминает Zerocracy (который Егор Бугаенко). Однако, как пишут в заметке - на платформе нет возможности обсуждения задачи с заказчиком и это как-то пугает!

Оплата за коммиты

Пример идеальной организации работы - такси. Всё оплачиваемое время водителя продуктивно, потери на коммуникацию и менеджмент минимальны, Uber даже сейчас стоит 40 миллиардов долларов. Всем бы так!

Ключевой фактор успеха - точность задачи. “Из пункта А в пункт Б,” - неправильно понять такое почти невозможно, да и споры о том, выполнен ли заказ, крайне маловероятны. Американский #стартапдня GitStart предлагает перенести магию на совсем другую профессию - на программистов.

Задача ставится на уровне исходников. “Обновить SDK, но чтобы все Unit-тесты продолжали работать,” - что-то в таком духе. Ответ разработчика приходит в формате Git Pull Request - т. е. готового кода. Если заказчик принимает Request - деньги списываются, нет - нет. Никаких переговоров, обсуждений или уточнений Gitstart не предусматривает.

А поговорить? Естественно, в такую схему вписывается далеко не любая задача. Где-то проще самому сделать, чем формализовать требования, где-то для успеха нужно хорошо знать проект. Но, увы. Нельзя - значит нельзя, никаких поблажек Gitstart не дает, обычных аутсорсеров можно искать на другой площадке, специализация и дифференциация - наше всё.

Стартап пока привлек 5 миллионов долларов инвестиций, по американским меркам - почти ничего, зато успел пройти Y Combinator.

https://www.gitstart.com/

#seed #сша #uber #itдляit