Нельзя сказать, что в этой статье вас ждут отборные потроха баз данных, но скорее рассказ про базы данных от самого начала, плюс небольшое углубление в некоторые подробности, которые Илье Космодемьянскому (@hydrobiont) кажутся важными. И есть все основания полагать, что так оно и есть.

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

Тем не менее, теоретические знания иногда полезно освежить. Этим мы, в том числе, и займемся.



О спикере: Илья Космодемьянский CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2. А кроме того, отвечает за продвижение Postgres-технологий, выступает на конференциях и рассказывает людям, как с ними работать.

Ниже материал по докладу Ильи на РИТ++ 2017, который не был связан с какой-то конкретной базой данных, но охватывал многие основные аспекты.

Недавно я познакомился с замечательной серией статей "Thinking in Ramda", которые проясняют на простых и ясных примерах способы написания кода в функциональном стиле с использованием библиотеки Ramda. Эти статьи показались мне настолько прекрасными, что я не смог удержаться от того, чтобы не перевести их на русский язык. Надеюсь, что в этом будет польза для многих людей :) Давайте начнём перевод с первой вступительной статьи.

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение

Данный пост — это начало серии статей «Мышление в стиле Ramda» о функциональном программировании.

Я буду использовать библиотеку Ramda в этих статьях, хотя многие из обсуждаемых идей применимы также к множеству других библиотек, таких как Underscore и Lodash, а также к другим языкам программирования.

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

Уважаемые читатели! Представляю вашему вниманию перевод методологии создания веб-приложений The Twelve-Factor App от разработчиков платформы Heroku. Мои комментарии скрыты спойлерами по ходу статьи.

Введение

В наши дни программное обеспечение обычно распространяется в виде сервисов, называемых веб-приложения (web apps) или software-as-a-service (SaaS). Приложение двенадцати факторов — это методология для создания SaaS-приложений, которые:

• Используют декларативный формат для описания процесса установки и настройки, что сводит к минимуму затраты времени и ресурсов для новых разработчиков, подключенных к проекту;
• Имеют соглашение с операционной системой, предполагающее максимальную переносимость между средами выполнения;
• Подходят для развертывания на современных облачных платформах, устраняя необходимость в серверах и системном администрировании;
• Сводят к минимуму расхождения между средой разработки и средой выполнения, что позволяет использовать непрерывное развертывание (continuous deployment) для максимальной гибкости;
• И могут масштабироваться без существенных изменений в инструментах, архитектуре и практике разработки.

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

Здравствуй, мой дорогой любитель поработать с Composer'ом, создавая свой очередной крутой проект на одном из модных фреймворков. Или, быть может, ты — фронтэнд-мастер, пишущий сложные штуки на JS и CSS, компилируя их из jsx- и less-файлов, устанавливая библиотеки через Bower, а проект собирая в каком-нибудь Grunt, попутно прогоняя код юнит-тестами и, конечно же, заливая потом всё это на github… Если всё это — часть твоей повседневной жизни, то хвала Всевышнему, поздравляю: ты прошел все эти испытания и даже не сломал себе мозг. Отныне, ты — из числа тех счастливых, потративших не одну неделю, разбираясь в том, как корректно настроить всю эту кучу инструментов, а также, ты — один из тех, кто может доминировать, властвовать и унижать блистать своими знаниями в комментариях Хабра к статьям других, менее проворных и смышлёных коллег по цеху…

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

Composer (getcomposer.org) — это относительно новый и уже достаточно популярный менеджер зависимостей для PHP. Вы можете описать от каких библиотек зависит ваш проект и Composer установит нужные библиотеки за вас! Причём Composer — это не менеджер пакетов в классическом понимании. Да, он оперирует с сущностями, которые мы будем называть «пакетами» или библиотеками, но устанавливаются они внутрь каждого проекта отдельно, а не глобально (это одно из основных отличий от старого-доброго PEAR).

Кратко, как это работает:

1. У вас есть проект, который зависит от нескольких библиотек.
2. Некоторые из этих библиотек зависят от других библиотек.
3. Вы описываете в своём проекте те библиотеки, от которых непосредственно зависит ваш код.
4. Composer находит нужные версии требуемых библиотек для всего проекта, скачивает их и устанавливает в папку вашего проекта.

При создании Composer авторы черпали идеи и вдохновение из аналогичных проектов: npm для Node.js и Bundler для Ruby.

Изначально он был спроектирован и разработан двумя людьми Nils Adermann и Jordi Boggiano, сейчас в проекте участвует более двадцати контрибьюторов, Проект написан на PHP 5.3, распространяется под лицензией MIT и доступен на github.

Первые коммиты были сделаны апреле 2011 года и на сегодняшний день Composer находится в стадии «alpha3». Однако, он уже достаточно стабилен и используется многими популярными PHP проектами (например, Symfony 2). Список проектов использующих Composer можно посмотреть на сайте packagist.org — это официальный репозиторий Composer пакетов. Кстати, на недавней конференции Devconf 2012 разработчик фреймворка Yii в своём докладе упомянул, что Yii2 скорее всего тоже будет использовать Composer.

В этой статье я кратко опишу основные возможности Composer и мы попробуем создать демонстрационный проект использующий Composer для загрузки необходимых библиотек. Все примеры будут доступны на github.com и bitbucket.org.

Привет, Хабр! Сегодня я хотел бы поговорить с вами о знакомых опытным PHP-девелоперам, но загадочных для новичков, штуках — Composer и Packagist. Не сомневаюсь, что для многих здесь текст не станет откровением. Материал для тех, кому с описанным ниже только предстоит столкнуться.

Вы — PHP-разработчик, и вам нужен хороший менеджер зависимостей — как npm или Bundler? Вам надоело мучаться с pear? И вы не хотите вручную качать библиотеки с сайтов и обновлять все зависимости? Тогда самое время познакомиться с Composer и Packagist.

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

Все мы хорошо знаем существующие популярные движки на PHP. Также можно упомянуть практически никому неизвестные, которые разрабатываются любителями. Но всех их объединяет одно большое «НО» в плане идеи, что собственно меня всегда и беспокоило. Почему никто не пользуется CMS при разработке высоконагруженных проектов? Все дело в том, что каждая из них спроектирована таким образом, чтобы всячески мешать разрабатывать какой-либо неспецифический функционал, не говоря о некоторых отдельных ситуациях.

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

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

В качестве эксперимента выкладываю перевод первой из 20 лекций. Если это получит должный отклик, буду переводить дальше.

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

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

Некоторое время назад у меня состоялся интересный разговор, коллега активно защищал Angular, говорил, что тот ускоряет веб-разработку. Я более десяти лет разрабатываю сложные web-сервисы, работал в Microsoft, в Spotware Systems на Кипре, сейчас создаю приложение для стартапа из Кремниевой долины, и в общем то слежу за трендами. Однако почувствовал себя динозавром, потому что не видел смысла использовать фронтэнд-фреймворки до того момента, а оказалось, что это уже мейнстрим. Шёл 2014-й год, я погрузился в мир Angular, Knockout и Backbone, что из этого вышло, почему я от них в итоге отказался и рекомендую коллегам сделать то же самое – под катом.

О том, что компания SpaceX разрабатывает пилотируемый космический корабль Crew Dragon, известно давно. Этот корабль планируется, в частности, использовать для доставки космонавтов на МКС или с МКС на Землю. Но до настоящего момента не было известно, что же там внутри. Теперь компания выложила снимки и видео внутренностей своего корабля.

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

Суть вот в чем, есть редактор (для примера: imperavi.com/redactor) и есть необходимость загружать сразу много картинок за один раз. В идеале простым перетаскиванием, а в нашем случае редактор кушает только одну картинку за раз. Это нужно поправить.

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

Добрый день, уважаемые хабровчане.

Сегодня я хотел бы поговорить о таких нетривиальных вещах, как асинхронные (параллельные) расчеты в языке PHP.
Сам по себе PHP — это скриптовый язык, который никогда и не претендовал на многопоточность. Но чем дальше в лес, тем более серьезные задачи стоят перед разработчиками, и тем больше приходится «извращаться» с пыхом, потому что мигрировать на более приспособленный под эти задачи язык программирования многие компании попросту боятся и не хотят. Следовательно, приходится работать с тем, что дают.
Подробности под катом…

Дабы сразу определить целевую аудиторию этого цикла заметок-статей-поучений пару слов о себе. Бывший школьник, будущий студент, в программинге толком ничего не смыслю, хотя есть пара сайтиков на готовых движках. В php-скриптах могу чего-нить лишнее удалить, изменить, но написать что-то с чистого листа — это не ко мне. Неоднократно пытался научится мастерству создания программ, но обычно тормозил как только дело доходило до ООП (видел в коде эти многочисленные классы, в пособиях всякие «объекты», «инкапсуляции» и т.п. и зависал...)

Собственно точно такое же желание появилось и сейчас. Порыскав по сети в поисках «чего-бы такого интересного выучить» наткнулся именно на Ruby с его рельсами. По словам спецов разного качества Руби сейчас актуален, программировать на нем быстро, это полный ООП (что перспективно в дальнейшем покорении олимпа программирования), синтаксис несложен… В то же время язык — тормоз, нагружает систему, twitter в нем барахтается, пытаясь удержаться на плаву, постоянные проблемы с хостингом. Но я вроде как стартапить в многомиллионную аудиторию не собираюсь, а для общего образования всегда подойдет.

Так что стоит признаться, что и Ruby я знаю совсем каплю, но уверен, что и мои «капли» будут интересны некоторым индивидам, подобным мне. Я могу (и буду) часто ошибаться в каких-то понятиях, методах, но мы ведь готовы помогать друг другу? Вроде бы как Хабр — это элита ИТ, но я думаю, что местные спецы не будут против, если мы тут с начинающими ребятами немного «потусим» :)

Собственно в этой серии статей мы будем капля за каплей наполнять стаканчик знаниями о Руби, наполнять будем вместе — для меня это также станет дополнительным стимулом не бросать занятия. Надеюсь, что и вам будет интересно! Начнем?

---

В продолжение статьи:

Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP

---

В отличии от предыдущего материала, в этой статье сделан упор на сравнение скорости отклика и интерпретации кода для различных версий PHP, включая PHP 7 beta3.

Для ранних версий PHP, проведено тестирование между оптимизаторами кода apc, xcache и opcaсhe.
Эта статья не содержит тестов на производительность, таких как нагрузочные тесты ab и siege. Возможно, об этом я напишу в одной из следующих статей.
В данном случае, меня не интересует сколько страниц за секунду способна сгенерировать та или иная версия php-интерпретатора, скорее то, с какой скоростью она сгенерирует мне страницу и с какой задержкой.
В данном случае разница в том, что тесты производительности замеряют отношение скорости интерпретатора к общим ресурсам сервера, а так же подготовленности других связанных компонентов web-системы к работе на повышенных нагрузках.
Остановимся на скорости и отклике. Очевидно что производительность зависит от скорости, но высокая скорость не может гарантировать высокую производительность. Это, возможно, связанно с тем, что недостаточно хорошо настроен web-сервер или база данных, а также с какими-то не было ограничениями, например сетевого стека.
Что бы не заниматься попыткой объять необъятное, мы просто замерим скорость и отклик работы интерпретаторов php, на мощном сервере без нагрузки, с одинаковыми конфигурациями web-сервера, базы данных и операционной системы для всех испытуемых. Используем конфигурацию php-fpm + nginx. База данных MariaDB. Все технические детали скрыты под спойлером ниже.

Однажды столкнулся с задачей: mongoDb использовался как кэш/буфер между backend на Java и frontend на node.js. Все было хорошо, пока не появилось бизнес требование перебрасывать большие объемы за короткое время через mongoDb (до 200 тыс. записей не более чем за пару минут). Для чего не так важно, важна что задача такая появилась. И вот тут уж пришлось разбираться во внутренностях монги…

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

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

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

К счастью PHPixie сама отказалась от глобального и статического скоупов, что позволяет легко запустить ее из-под ReactPHP.

Давно хотел поделиться с общественностью способом тестировать код, использующий функции для работы с внешней средой: с сокетами, БД, файлами и чем угодно ещё. Сегодня, увидев статью Runkit + PHPUnit = 100% покрытие тестами, решил, что сейчас самое время.
Решение с Runkit красивое, но есть одна проблема — Runkit не распространяется вместе PHP, его надо ставить отдельно. Я же хочу предложить подход, работающий в обычной поставке PHP 5.3+, при одном условии — проект должен использовать пространства имён.