Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day'16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

Уже больше года использую паттерн Command Bus в своих Symfony-проектах и наконец решил поделиться опытом. В концев концов обидно, что в Laravel это есть «из коробки», а в Symfony, из которого Laravel во многом вырос — нет, хотя самому понятию Command/Query Separation уже не менее 10 лет. И если с буквой «Q» из аббревиатуры «CQRS» еще понятно что делать (лично меня вполне устраивают custom repositories), то куда приткнуть букву «C» — неясно.

На самом деле, даже в банальных CRUD-приложениях Command Bus дает очевидные преимущества:

• контроллеры становятся «худыми» (редкий «экшен» занимает более 15 строк),
• бизнес-логика покидает контроллеры и становится максимально независимой от фреймворка (в результате ее несложно повторно использовать в других проектах, даже если они написаны не на Symfony),
• упрощается unit-тестирование бизнес-логики,
• сокращается дублирование кода (когда, например, необходимо реализовать «фичу» как через Web UI, так и через API).

Введение

Слишком много раз я встречал приложения, о которых говорили, что у них есть модель предметной области и приложение было спроектировано на основе это предметной области. Однако в действительности всё, что я видел, было коллекцией сущностей (я бы даже сказал DTO), имеющих кучу свойств без какой бы то ни было реальной логики, связанной с сущностью. Кроме того, я могу найти много сервисов всех видов, которые содержат красочную смесь бизнес-логики и/или инфраструктуры. Если приложение вдобавок использует шину сообщений (как NServiceBus, Mass Transit Bus или Azure Bus), то конечно же заметно, что некие сообщения передаются от одного модуля к другому или нескольким модулям. К сожалению, сообщения часто имеют очень обобщённые названия, содержащие слова “обновить”, “изменить”, “добавить” или “удалить”, и несут большое количество полезной нагрузки — десятки разнообразных свойств. Часто из названия сообщения совершенно не очевидно, является ли оно командой или событием, и чтобы определить это, приходится глубоко зарыться в реализацию.

Я искренне хотел бы, чтобы все написанное выше было бы преувеличением или же имело смысл только для «старых» приложений, которые разрослись и вышли из-под контроля. Но печальная истина в том, что это относится ко многим новым проектам, даже тем, которым всего несколько месяцев от роду. Почему так происходит? Конечно, есть много разных причин: отсутствие знаний является одной из наиболее важных.

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

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

Здравствуйте, хабрапользователи! В этой статье речь пойдет о предметно-ориентированном проектировании программного обеспечения с использованием, в первую очередь, стратегических шаблонов. Вторую часть – про тактическое проектирование – читайте здесь.

Данный подход использовал Вон Вернон в своей книге «Реализация методов предметно-ориентированного проектирования». Цель написания этой книги: дать возможность разработчикам совершить полет на самолете DDD (в детстве автор зачастую путешествовал со своей семьей на небольших самолетах). Вид с высоты дает более широкое представление о проблемах моделирования, не давая застрять в различных технических деталях. Наблюдая ландшафт DDD таким способом, можно осознать преимущества как стратегического, так и технического проектирования. Подробнее – под катом!

Введение

В PHP приложениях отладка при помощи var_dump, debug_backtrace и прочих полезных функций не всегда удобна, и возникает потребность в полноценном отладчике. Эта статья — для тех, кто по каким-либо причинам не хочет использовать IDE, поддерживающие отладку PHP приложений из коробки, вроде NetBeans или PhpStorm, а хочет использовать для этих целей vim, и при этом отладка происходит на удаленном хосте.

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

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

Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

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

И если ошибка второго рода выражается просто:

$$

где Π — это полнота;

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

Но это лирика. Самый важный вопрос:

Почему в DataScience используют полноту и точность и почти никогда не говорят об ошибках первого и второго рода?

Кто не знает или забыл — прошу под кат.

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

Smart Contract & Gas

Если на пальцах, "умный контракт" — это некоторый код, живущий внутри блокчейна. Любой участник сети может его вызвать за небольшую плату. Эта плата и называется Gas, дословно "топливо". Зачем это нужно? Для защиты майнера от злоупотребления мошенником его ресурсов.

Немногие знают, но даже в биткоине есть возможность писать эти самые контракты, но в силу некоторых причин этим мало кто занимается. Одна из главных проблем — язык Script не Тьюринг-полный и написать что-то более менее серьезное непросто (чтобы вы понимали масштаб проблемы — нет даже возможности добавить цикл). В случае с Ethereum все чуть по другому, языки Тьюринг-полные, и есть риск, что кто-то напишет контракт вида

// Это псевдокод
foo = 0;
while (True) {
    foo++;
}

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

Недавно узнал о великолепном микро-фреймворке Silex, и примерно столь же недавно о модели ORM. Туториал будет полезен тем, кто хочет связать одно с другим.

На свободу интернета в России очередной раз наступают, и на этот раз ситуация довольно серьезная. Принят закон против всех анонимайзеров, VPN-сервисов, браузеров Tor и Opera. Теперь, если они не будут перекрывать доступ ко всем сайтам по требованию Роскомнадзора, в России их заблокируют. Также запрещенные ресурсы отныне нельзя показывать в выдаче поисковых систем. Закон приняли в Госдуме почти единогласно, и уже на следующий день его подписал президент. Говорят, на такой срочности настоял лично директор ФСБ.

Новый запрет касается нас напрямую. Мы занимаемся доставкой в Россию покупок из американских интернет-магазинов. И многие из них пользователей с российскими IP к себе просто не пускают. Это особенно характерно для сайтов брендов –

Выход Symfony 2 показался мне достаточно веской причиной чтобы наконец-то найти время и посмотреть что же из себя представляет один из самых популярных PHP-фреймворков в мире. Своё знакомство с ним я и описал в данной заметке. Так как это мой первый опыт работы с Symfony буду рад если заметите какие-то ляпы или недочёты и сообщите мне о них.

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

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

Хороший виртуальный ассистент должен не только решать задачи пользователя, но и разумно отвечать на вопрос «Как дела?». Реплик без явной цели очень много, и заготовить ответ на каждую проблематично. Neural Conversational Models — сравнительно новый способ создания диалоговых систем для свободного общения. Его основа — сети, обученные на больших корпусах диалогов из интернета. Борис hr0nix Янгель рассказывает, чем хороши такие модели и как их нужно строить.


Под катом — расшифровка и основная часть слайдов.

Мы живём очень мало. И мы ничего не успеваем. Ещё в раннем детстве меня пугала мысль о смерти. Разве мы пришли за жалкими семьюдесятью годами, из которых лишь первая половина не омрачена видимым старением и заболеваниями? К моему удивлению, проблема старения и смерти беспокоит очень мало людей. По моим опросам ни школьники, ни молодёжь не хочет жить вечно! «Это скучно», – говорят они! Жизнь вообще скучна у людей, ограничивших свой мир экраном айфона.

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

• Анализ предметной области и создание ТЗ (взаимодействия с заказчиком)
• Проектирование структуры программы
• Кодирование (набор программного кода согласно проектной документации)
• Тестирование и отладка
• Внедрение программы
• Сопровождение программы
• Утилизация

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

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

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



А затем мы провели атаку через сеть SS7 на один из тестовых номеров (подробнее о самих атаках мы писали ранее). И вот что у нас получилось:

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