В настоящий момент выходит не так много книг по PHP, поэтому я решил прочитать свежее переиздание книги PHP Cookbook от 2023 года, которую в России переводят, как "PHP. Рецепты программирования". Хотелось бы «УЗНАТЬ», что можно написать не про какую-то сферу, где применяется PHP, а именно про сам язык.

Об авторе

Эрик Манн - инженер-программист с опытом почти в два десятилетия. Он создавал масштабируемые проекты для стартапов на ранней стадии и для компаний из списка Fortune 500. Эрик часто рассказывает о архитектуре программного обеспечения, технике безопасности и передовом опыте разработки. Он регулярно уже более пяти лет пишет статьи в журнале php[architect], и больше всего ему нравится помогать новым разработчикам избегать многих ошибок, которые он совершил в своей карьере программиста.

Сложности моддинга, обзор движка игры и приемы геймдизайна. Какие проблемы были решены для RTS игры и её сообщества.

Современная ситуация с разработкой веб-приложений

Laravel – один из наиболее популярных фреймворков для разработки на языке PHP. Если вы только начинаете свой путь в Laravel и хотите освоить этот мощный инструмент, то курс LaraКурс на YouTube может стать отличным помощником для вас. Курс разработан специально для разработчиков, которые не знакомы с Laravel и включает в себя все необходимые знания и навыки, чтобы начать создавать современные продукты на этом фреймворке. Его записал бэкенд-разработчик нашей Студии Флаг – Алексей Смирнов, который имеет богатый опыт в разработке на Laravel. В данной статье мы рассмотрим основные характеристики курса и то, что вы можете ожидать от него.

Популярность JavaScript фреймворков среди разработчиков растет, и появляется все больше сайтов, использующих эти фреймворке в работе. Поэтому все больше приходится работать по SEO с такими современными сайтами, и накапливается опыт их оптимизации. Такой опыт накапливается через большое количество ошибок, и в этой статье мы рассмотрим, как избежать таких ошибок.

Иначе картина может быть такой (сайт после переноса на React JS):

Привет! Меня зовут Айнур, и я frontend-разработчик SimbirSoft. Более 6 лет я работаю над коммерческими проектами, создаю и улучшаю интерфейсы, поэтому в работе достаточно часто использую паттерны проектирования. Неоднократно я обращался за идеями и лайфхаками к книге Patterns.dev, которая содержит очень современный взгляд на шаблоны проектирования, рендеринга и производительности JavaScript.

Авторы Patterns.dev:

Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.

Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

Материал книги будет полезен не только React-разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend-разработкой.

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

Источник: https://www.patterns.dev/
Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

И снова всем привет! Судя по реакциям и количеству закладок к переводу первой части книги Patterns.dev, этот материал оказался для вас полезен. Поэтому я решил поделиться переводом второй части.

В ней речь идет про паттерны рендеринга. В случае правильного подбора можно получить более быструю сборку и отличную производительность загрузки при низких затратах на обработку.

Напомню, что авторы Patterns.dev:
Лидия Холли — штатный консультант и преподаватель по разработке программного обеспечения, которая в основном работает с JavaScript, React, Node, GraphQL. Она также занимается наставничеством и проводит личные тренинги.
Эдди Османи — технический менеджер, работающий над Google Chrome. Его команды работают над такими проектами, как Lighthouse, PageSpeed ​​Insights, Chrome User Experience Report и другими.

Материал книги будет полезен не только React‑разработчикам, но и всем, кто так или иначе интересуется или сталкивается с frontend‑разработкой. Это ознакомительная часть перевода учебника https://www.patterns.dev/. Перевод всей второй части учебника можно найти здесь.

P. S.: На данный момент выложено в виде pdf, в дальнейшем планируется полноценная публикация на github для удобства изучения.

P. P. S.: Вторая часть взята из книги: https://www.patterns.dev/, переведена на русский язык. Книга находится под лицензией CC BY-NC 4.0

Данный адаптированный материал распространяется на условиях лицензии Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)

Я люблю древовидные комментарии. Для них сложно найти лучшую альтернативу. Интерфейсы форумов из двухтысячных выглядят слишком огромными для сообщений в два-три предложения. В линейном потоке сообщений мессенджера бывает сложно понять, кому кто отвечает. А имиджборды мне приходилось на полном серьезе учиться читать.

Одна из самых старых и самых популярных площадок с деревьями комментариев — это Reddit. Правда, большая часть его пользователей едина в одном: его интерфейс ужасен. Но его API открыто, поэтому на выбор есть множество клиентских приложений, особенно для мобильных телефонов — Joey, Relay, Slide и Boost и другие. Их авторы — как правило, и сами недовольные стандартным интерфейсом Реддита — потратили много времени и сил на поиск удобного интерфейса для комментариев. И большая их часть пришла к очень похожим вариантам дизайна.

В этой статье я хочу разобрать, чем мне так нравится такой дизайн деревьев комментариев, сравнить его с деревьями комментариев Хабра, и попробовать пофантазировать, как бы могли выглядеть комменты Хабра в интерфейсе клиентов для Reddit.

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

Раньше я сам был таким человеком.

И не мудрено - никто не рождается с навыком идеально точного планирования.

Сейчас я довольно точно, в некоторых случаях даже до минуты, могу оценить сколько времени займёт у меня выполнение той или иной задачи, что при прежних попытках планирования казалось чем то невозможным. Как мне это удалось? Делюсь в статье.

Большие языковые модели, такие как GPT-4, с угрожающей скоростью становятся все более эффективными. Через пару лет нам больше не понадобятся разработчики!
...Или, по крайней мере, такая позиция становится вирусной в Твиттере. Я гораздо более оптимистично смотрю на то, что эти достижения ИИ означают для будущего разработки программного обеспечения.

Всем привет, меня зовут Хаджимурад, занимаюсь фронтенд разработкой уже 3,5 года и за это время успел поработать на многих проектах: интернет магазин, панели администрирования, проекты для университета. Сейчас работаю на проекте в банке и сегодня хочу поделится с вами своим опытом.

В статье на примере простого сайта, постараюсь описать три способа рендеринга приложений, раскрыть их плюсы и минусы, и на практических примерах провести сравнение производительности и размеров приложения. Материал больше подойдёт начинающим фронтенд-разработчикам, или тем, кто хочет познакомиться c CSR, SSG и SSR. Для лучшего понимания от вас потребуются начальные знания React, менеджеров пакетов npm или yarn.

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

Теперь же веб-страница может быть полноценным приложением, которое получает данные из различных источников, выполняет манипуляции «на лету» и предоставляет полную интерактивность. Это значительно повысило полезность интернета, но ценой размера, пропускной способности и скорости. За последние 10 лет средний размер веб-страниц для десктопа увеличился с 468 КБ до 2284 КБ, что составляет рост на 388,3%. У мобильных устройств скачок еще более впечатляющий — от 145 КБ до 2010 КБ, то есть больше на 1288,1%.

Всем привет! На связи Spectr.

В феврале мы провели митап #DevTalks, посвященный фронтенду, и сейчас хотим подробно о нем рассказать: поделимся докладами спикеров, материалами выступлений, отзывами участников и немного расскажем о внутренней кухне организации таких ивентов. 

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

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

Дальнейшая судьба проекта, конечно, зависит от многих факторов и скорее всего вы его забросите (как и остальные ваши 150 пет-проектов, которые никто не увидит), но даже в самом рождении этого проекта необходимо решить множество архитектурных и религиозных вопросов, а своим опытом их решения я решил поделиться с вами, чтобы вы не допускали подобных ошибок или указали мне на те ошибки, которые возможно я еще не заметил.

Технология css-in-js существует уже довольно давно. Ещё в начале своего профессионального опыта я встречал подходы, в которых стайлинг локальных частей интерфейса пробрасывался в html через javascript в виде css директив. Иногда это необходимая мера, хотя необходимой она случается изредка, но раз в год, как говорится, и палка стреляет. У меня на опыте был пример построения раздела интерфейса, в котором устанавливаемое на сайт пользователя модальное окно можно рестайлить через кодовый редактор с live preview. css-in-js бывает оправдан, поэтому хочу сразу оговориться - хоронить никакой подход не стоит. Но и идеализировать его как универсальную пилюлю тоже не надо. Рендер стилей, привязанный к логике рендера компонентов в контексте всего проекта - это просто свой путь со своими приключениями, появившийся на мой взгляд в общей психопатии привязывать к state всё что только можно. Что если посмотреть - откуда взялась эта техногогия? На сегодняшний день на рынке проектирования интерфейсов сложился монополист react, диктующий программистам свои правила игры, и который даже без использования styled модуля имеет в себе простейщую инверсию управления cssInJs.
React - важный персонаж в этой теме. Он, словно useEffect всего современного front-end - стал центром силы, средоточием зла в виде голого state management, не предусматривающего из коробки ничего иного.

Всем привет! Меня зовут Аня Ланда, я фронтенд-разработчик в Самокате. В компании я больше двух лет, общий стаж во фронтенде – 6 лет и всё это время я делаю таблицы. В этом посте расскажу про эволюцию подходов к работе с ними, что меняется на пути от нескольких сотен до сотен тысяч элементов в таблице.

Распространенная проблема, которую я вижу в объектно-ориентированном проектировании:

* Волшебник — это разновидность игрока.
* Воин — это разновидность игрока.
* У игрока есть оружие.
* Посох — это разновидность оружия.
* Меч — это разновидность оружия.

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

PHP - едва ли первое, что придет в голову, когда стоит задача поднять сервер веб-сокетов. Практически каждая статья в интернете будет пестрить предложениями использовать для этого NodeJS, Python или Go. Но поскольку PHP - это однозначно первое, что приходит в голову, когда речь идет о веб-приложениях, почему бы не попробовать?

На самом деле, запуск сервера веб-сокетов на PHP довольно прост. Существует превосходная библиотека Ratchet, позволяющая работать на любом фреймворке (или вовсе без него) полноценно и легко.

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