И снова здравствуйте!

Что ж очередной «новый» курс, который стартовал в конце декабря, подходит к концу — «Backend разработчик на PHP». Учли разные мелкие шероховатости и запускаем новый. Осталось только посмотреть на выпуск и всё, поставим очередную галочку.



А счас пока давайте посмотрим на одну интересную статью.

Поехали.

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

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

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



Автор статьи, перевод которой мы сегодня публикуем, хочет поделиться с аудиторией React-разработчиков девятью полезными советами, направленными на повышение качества кода. Эти советы затрагивают довольно широкий диапазон тем — от инструментальных средств до стиля программирования.

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

Проблемы, симптомы

Мой начальный опыт программиста был весьма безоблачным – я без лишних проблем клепал вебсайты-визитки. Писал код, как я это сейчас называю “в строчку” или “полотном”. На маленьких объемах и простых задачах все было хорошо.

Но я сменил работу, и пришлось разрабатывать один единственный вебсайт в течение 4-х лет. Естественно, сложность этого кода была несопоставима с визитками из моей прошлой работы. В какой-то момент проблемы просто посыпались на меня – количество регрессии зашкаливало. Было ощущение, что я просто хожу по кругу – пока чинил “здесь”, сломал что-то “там”. И поэтом это “здесь” и “там” банально менялось местами и круг повторялся.

У меня исчезла уверенность в том, что я контролирую ситуацию – при всем моем желании недопустить баги, они проскакивали. Все эти 4 года проект активно разрабатывался – мы улучшали уже существующий функционал, расширяли, достраивали его. Я видел и чувствовал, как удельная стоимость каждого нового рефакторинга/доработки растет – увеличивался общий объем кода, и соответственно увеличивались затраты на любую его правку. Банально, я вышел на порог, через который уже не мог переступить, продолжая писать код “в строчку”, без использования архитектуры. Но в тот момент, я этого еще не понимал.

В больших компаниях редко возникает вопрос «Что собой представляют эти новомодные методики и технологии?», скорее «Как мы можем их у себя применить?».

DevOps существует почти 10 лет, и в последние два-три года большие нормальные организации уже освоились с премудростями DevOps. («Но что такое этот ваш DevOps?!» — вероятно, подумали вы. Договоримся, что это «улучшение качества вашего ПО за счёт ускорения цикла релизов с помощью облачных методик и автоматизации, а также с помощью дополнительных преимуществ ПО, которое остаётся в production».)

Когда Мэтта Карри, менеджера по Agile-трансформации в компании Allstate, спросили о применении DevOps, он ответил: «Думаю, когда айтишники его опробуют, то уже никогда не будут работать по-другому». Вероятно, вы слышите подобное вновь и вновь, когда речь заходит про внедрение DevOps.

Хотя внесение улучшений и изменений часто кажется чем-то, что не может произойти в вашей организации, результаты слишком заманчивы, чтобы их игнорировать, да и бизнес ожидает от ИТ последовательного наращивания возможностей и эффективности. Как сказал Джон Митчелл, директор по цифровой стратегии и поставке компании Duke Energy: «Согласно нашим бизнес-результатам, стало в 10 раз лучше».

Я люблю Реакт. Люблю за то, как он работает. За то, что он делает вещи «правильно». HOC, Composition, RenderProps, Stateless, Stateful – миллион патернов и антипатернов которые помогают меньше косячить.

И вот совсем недавно React принес нам очередной подарок. Очередную возможность косячить меньше — getDeviredStateFromProps.

Технически — имея статический мапинг из пропсов в стейт логика приложения должна стать более проста, более понятна, тестируема и так далее. По факту многие люди начали топать ногами, и требовать prevProps обратно, не в силах (или без особого желания) переделать логику своего приложения.

В общем разверлись пучины ада. Ранее простая задача стала сложней.

Блокчейн-протоколы должны обеспечивать консенсус среди нод децентрализованной системы. Пожалуй, самым известным алгоритмом консенсуса можно считать «тормозунутый, но надежный, потому что тормознутый» алгоритм Proof-of-Work: каждая нода, имея набор новых транзакций перебирает некоторое число nonce, являющееся полем блока. Блок считается валидным, если валидны все транзакции внутри него и хэш-функция от заголовка блока имеет некоторую общепринятую особенность (например, количество нулей в начале, как в Bitcoin):

Hash(  Block{transaction,nonce,…} ) = 000001001...

Как известно, блокчейн — это цепочка блоков. Цепочкой он является потому, что внутри каждого блока записан id (как правило хэш от заголовка) предыдущего блока. Для последующих рассуждений блокчейн в упрощенном виде можно представить так:

Сложно уследить за новшествами различных версий ECMAScript, а ещё сложнее — найти полезные примеры их применения, не перекапывая горы информации. Поэтому сегодня мы публикуем перевод материала, автор которого проанализировал 18 новых возможностей ECMAScript, в число которых входят те, что имеются в уже вышедших стандартах ES2016 и ES2017, а также — те, которые должны появиться в стандарте ES2018. Автор этой статьи обещает, что каждый, кто её прочтёт, узнает много интересного и полезного о новых возможностях JavaScript.

Проект Accelerated Mobile Pages (AMP) от Google вызвал определённый переполох по идеологическим причинам, но саму технологию так и не разобрали подробно. Несколько недель назад Ферди Кристант писал про несправедливое преимущество, которое получает контент AMP за счёт предзагрузки. Это заставило меня задуматься: насколько хорошо AMP работает на самом деле? Я видел тесты как у Ферди, когда сравнивались одна или две страницы, но ещё не встречал всесторонних объективных тестов.

Оценить производительность AMP на самом деле не так просто, чем кажется. Нужно рассмотреть по крайней мере четыре контекста:

1. Насколько хорошо работает AMP в контексте поиска Google?
2. Насколько хорошо работает библиотека AMP как автономный фреймворк?
3. Насколько хорошо работает AMP при загрузке из кэша?
4. Насколько хорошо работает AMP по сравнению с каноническим документом?

Мы уже видели насколько WebAssembly быстро компилируется, ускоряет js библиотеки и генерирует более компактные бинарники. У нас даже есть общее представление как наладить взаимодействие не только между сообществами Rust и JavaScript, но и с сообществами других языков. В прошлой статье мы упоминали специальный инструмент wasm-bindgen и сейчас я бы хотел остановиться на нем более подробно.

Для передачи данных сервером на php клиенту можно использовать следующий алгоритм:

1. Сервер php публикует данные в канал redis.
2. Сервер node подписывается на события в соответствующем канале redis и при
   наступлении события поступления данных публикует эти данные уже в
   socket.io
3. Клиент подписывается на сообщения socket.io и обрабатывает их при поступлении

Исходный код проекта можно найти на github

Книга «Безопасность в PHP» (часть 1)
Книга «Безопасность в PHP» (часть 2)

Межсайтовый скриптинг (XSS) — пожалуй, самый типичный вид уязвимостей, широко распространённых в веб-приложениях. По статистике, около 65 % сайтов в той или иной форме уязвимы для XSS-атак. Эти данные должны пугать вас так же, как пугают меня.

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Эта статья предназначена для тех, кто уже знает про Docker, знает для чего он. А вот что делать с этим дальше не знает. Статья носит рекомендательный характер и не посягает на звание «лучшая практика».

Итак, возможно вы прошли docker tutorial, докер кажется простым и полезным, но вы пока не знаете, как он может вам помочь с вашими проектами.

Обычно с деплоем возникает три проблемы:

1. Как мне доставить код на сервера?
2. Как мне запустить код на серверах?
3. Как мне обеспечить одинаковость окружения, в котором запускается и работает мой код?

Как с этим поможет Docker под катом.

Docker в продакшене на Iron.io


Ранее в этом году (прим. 2014 г.), мы приняли решение запускать каждую задачу на IronWorker внутри своего собственного Docker контейнера. С тех пор мы запустили более 300 000 000 программ внутри собственных Docker контейнеров в облаке.

После нескольких месяцев использования, мы хотели бы поделиться с сообществом некоторыми из проблем, с которыми мы столкнулись в построении инфраструктуры, основанной на Docker'e, как мы преодолели их, и почему это стоило того.

Что такое CI

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

Если вы не знаете как настроить CI в своем проекте, я приглашаю вас "под кат"

Вот несколько советов по работе с Vue.js которые я выработал за последний год.

Используйте стрелочные функции в компонентах

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

Например:

Одна из самых важных областей бизнес-софта – это отчетность. От того, насколько легко настроить под меняющиеся потребности бизнеса (и законодательства) существующий отчет или сделать новый, может зависеть (причем не в переносном смысле!) судьба бизнеса, будь то отчет для налоговой инспекции или диаграмма зависимости спроса на товары от сезона и других факторов. Мощная и гибкая система отчетности, позволяющая легко извлечь из системы нужные данные, представить их в доступном для понимания виде, позволяющая конечному пользователю перенастроить стандартный отчет так, чтобы увидеть данные в новом свете – это идеал, к которому должна стремиться каждая бизнес-система.

В платформе «1С:Предприятие» за построение отчётов отвечает механизм под названием «Система компоновки данных» (сокращенно СКД). В этой статье мы постараемся дать краткое описание идеи и архитектуры механизма СКД и его возможностей.

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

Краткое руководство по началу работы, которое вы ищете.

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

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

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

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