Я постараюсь максимально коротко рассказать о том, как можно использовать этот паттерн с нашей любимой Doctrine на примерах и почему так делать — true.

Давайте представим себе базовый кейс:

1. У нас есть: сущность «Дом», сущность «Квартира в доме», сущность «Застройщик», сущность «Регион».
2. У нас есть задача: иметь возможность получить всех застройщиков, иметь возможность получить все занятые регионы застройщиком, уметь возможность получить все дома, которые принадлежат застройщику и все доступные регионы вообще в принципе, где ведутся продажи домов.
3. У нас есть правила от бизнеса:

Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.2.0 Beta 1, свежие RFC из PHP Internals, материалы по асинхронному PHP, видео с конференций и митапов, и многое другое.
Приятного чтения!

Всем привет! Я Алексей Грезов, разработчик Server Team Badoo. Мы в Badoo всегда стараемся сделать так, чтобы наш код было легко поддерживать, развивать и переиспользовать, ведь от этих параметров зависит, насколько быстро и качественно мы сможем реализовать какую-либо фичу. Одним из способов достижения этой цели является написание такого кода, который просто не позволит совершить ошибку. Максимально строгий интерфейс не даст ошибиться с порядком его вызова. Минимальное количество внутренних состояний гарантирует ожидаемость результатов. На днях я увидел статью, в которой как раз описывается, как применение этих методов упрощает жизнь разработчикам. Итак, предлагаю вашему вниманию перевод статьи про принцип "poka-yoke".

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

Предметно-ориентированное проектирование (Domain-Driven Design, DDD) — это процесс тесной увязки программного кода с реалиями предметной области.Благодаря ему добавление в программный продукт новых возможностей по мере его развития становится таким же простым, как и при создании программы с нуля. Эта книга в полной мере соответствует философии DDD и позволяет разработчикам перейти от философских рассуждений к решению практических задач.

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

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

Я думаю, вы уже знаете что такое push-уведомления, но я всё же напишу коротко о главном.

Пользователь, заходя на сайт, вытягивает (pull) с него данные. Это удобно и безопасно, но с развитием интернет ресурсов, появилась необходимость оперативно доставлять информацию пользователям не дожидаясь пока те сами сделают запрос. Так и появилась технология принудительной доставки (push) данных с сервера клиенту.

Обычным весенним днем, занимаясь «подготовкой» к ЕГЭ по информатике, наткнулся на статью об уязвимости Facebook, позволявшей взломать все аккаунты в социальной сети, за которую выплатили 15000$. Суть уязвимости заключалась в переборе кодов восстановления на тестовом домене компании. Я подумал, а чем собственно ВКонтакте хуже? И решил попробовать провернуть подобный трюк у них. Зная, что веб-версия уже достаточно хорошо исследована, жертвой должен был стать Android клиент, а что из этого вышло можно прочитать под катом.

Эра фулстэк фрэймворков в прошлом. Современные разработчики фрэймворков разделяют свои монолитные репозитории на компоненты с помощью ответвлений в Git, позволяя разработчику выбрать то, что действительно необходимо его проекту. Это означает, что вы можете построить свое приложение на топовых Zend Service Manager, Aura Router, Doctrine ORM, Laravel (Illuminate) Eloquent, Plates, Monolog, Symfony Cache или любых других компонентах, которые можно установить через Composer.

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

Откуда взялась идея? За последние несколько лет я сменил 3-4 компании, в которых мне доставалась мягко говоря лапша, толстенные контроллеры и минимум аннотаций. С чем именно связать отсутствие аннотаций — сказать сложно, возможно, это банальная лень или не знание того, что аннотации позволяют описывать больше, чем просто входящие параметры для классов/методов. А когда это начинает касаться API-контроллеров, то тут вообще весело, прикрутить FosRestBundle не проблема (я сейчас про более ленивый вариант, чем написание всего и вся самому ручками, хотя, как показывает практика — бандл проще).

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

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

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

Все началось с Kotlin. Случайно попалась статья про новый язык, что на нем можно писать под Android. Соприкоснувшись с темой, узнал что изначально приложения под Android пишутся на JAVA. Решил узнать на сколько трудоемко писать приложения под Android, в чем преимущества платформы на практике. Ведь по сути приложения JS и приложения Android выполняют одну и туже функцию. Заодно решил провести эксперимент. Что можно сделать за 12 часов, не зная что такое JAVA и тонкости разработки под Android, используя как помощник только Google. Пришла идея, которую развил в постановку задачи.

На работе попросили провести исследование какими средствами лучше разбирать объёмный XML файл (более 100Mb). Предлагаю сообществу ознакомиться с результатами.

Рассмотрим основные методы работы с XML:

1. Simple XML (documentation)
2. DOM (documentation)
3. xml_parser (SAX) (documentation)
4. XMLReader (documentation)

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

Для этого нужно учесть достаточно большое количество характеристик, от «как быстро всё будет работать» до «а необходима ли нам эта фича?». И так каждый раз. Именно в моменты мозгового штурма команда сравнивает удобство фреймворка, скорость, набор фич, которые реализованы в нем или в совместимых с ним модулях.

Но какой же всё-таки лучше, быстрее и производительнее?

Разработчики постоянно проводят сравнение фреймворков, чтобы прояснить для себя этот вопрос. Например, в статье Lukasz Kujawa приведено сравнение PHP фреймворков. Одно «но» — статья за 2013 год. А ведь время идёт… Поэтому мы решили провести своё, актуальное сравнение фреймворков.

Для оценки производительности был использован PHP Framework Benchmark. Он предлагает для сравнения множество фреймворков (не только указанных выше), но автор не спешит добавлять в репозиторий новые версии проектов, что, конечно же, печально, хотя и не смертельно. При желании добавить новую версию не сложно. 


Одной из основных целей данной статьи также является попытка практическим путем определить улучшения в производительности и эффективности новых версий PHP. Поэтому тестирование было проведено на РНР 5.6/7.0/7.1

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.
Приятного чтения!

Хочу рассказать вам о новом языке программирования, который называется Kotlin, и объяснить, почему вам стоит использовать его в своём следующем проекте. Раньше я предпочитал Java, но в последний год пишу на Kotlin везде, где только можно. И в данный момент я не представляю себе ситуации, в которой лучше было бы выбрать Java.

Kotlin разработан в JetBrains, и участие тех же людей в создании наборов IDE, таких как IntelliJ и ReSharper, хорошо заметно по самому языку. Он прагматичен и краток, благодаря чему написание кода превращается в приятный и эффективный процесс.

Хотя Kotlin компилируется в JavaScript и скоро будет компилироваться в машинный код, я сконцентрируюсь на его первичной среде — JVM.

Итак, несколько причин, почему вам следует полностью переходить на Kotlin (порядок случаен):

В первой части я уделил внимание только общей концепции: редюсеры, компоненты и экшны чаще меняются одновременно, а не по отдельности, поэтому и группировать и их целесообразнее по модулям, а не по отдельным папкам actions, components, reducers. Также к модулям были предъявлены требования:

1. быть независимыми друг от друга
2. взаимодействовать с приложением через API ядра

В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем.

Большинство разработчиков начинает знакомство с Redux с Todo List Project. Это приложение имеет следующую структуру:

actions/
  todos.js
components/
  todos/
    TodoItem.js
    ...
constants/
  actionTypes.js
reducers/
  todos.js
index.js
rootReducer.js

На первый взгляд такая организация кода кажется логичной, ведь она напоминает стандартные соглашения многих backend MVC-фреймворков:

app/
  controllers/
  models/
  views/

На самом деле, это неудачный выбор как для MVC, так и для React+Redux приложений по следующим причинам:

1. С ростом приложения следить за взаимосвязью между компонентами, экшнами и редюсерами становится крайне сложно
2. При изменении экшна или компонента с большой вероятностью потребуется внести изменения и в редюсер. Если количество файлов велико, скролить IDE вверх/вниз не удобно
3. Такая структура потворствует копипасте в редюсерах

Не удивительно, что многие авторы(раз, два, три) советуют структурировать приложение по «функциональности» (by feature).

Работа из дома несколько дней в неделю — давняя привилегия избранных программистов. Но если 20 лет назад такая опция была скорее исключением из правил, то сейчас разработчики требуют её от работодателя. Её ценят настолько же высоко, как наличие отпусков и отгулов, расширенной медицинской страховки и соблюдения нормального рабочего графика без овертаймов. На это указывают результаты многочисленных исследований, в том числе результаты опроса разработчиков на Stack Overflow Developer Survey Results 2017.

В конце концов, сейчас так много инструментов для организации удалённой работы: Slack, Skype, Google Hangouts, Basecamp, BlueJeans. Групповые часты, видеоконференции, совместная работа и управление проектами. Зачем вообще программисту ходить в офис каждый день?

Шаблоны проектирования — это способ решения периодически возникающих проблем. Точнее, это руководства по решению конкретных проблем. Это не классы, пакеты или библиотеки, которые вы можете вставить в своё приложение и ожидать волшебства.

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

В статье приведены примеры на PHP 7, но пусть вас это не смущает, ведь заложенные в шаблонах принципы неизменны. Кроме того, внедряется поддержка других языков.

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

И, разумеется, какими бы вам странными и некорректными ни казались вопросы на собеседовании, приходить нужно всё-таки подготовленным, зная тот язык, за программирование на котором вам собираются платить.



Третья часть серии статей посвящена одному из самых объемных понятий в современном PHP — итерации, итераторам и итерируемым сущностям. Я постарался свести в один текст некий минимум знаний об этом вопросе, пригодный для самоподготовки к собеседованию на позицию разработчика на PHP.

Две предыдущие части:

• Готовимся к собеседованию по PHP: ключевое слово «static»
• Готовимся к собеседованию по PHP: псевдотип «callable»

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