Продолжение предыдущего поста

Децентрализация — это отсутствие единого центра контроля и единой точки отказа.
Несомненно, в нынешнее время, много проектов стараются перевести те или иные сервисы от принципа Клиент-Сервер к принципу Клиент-Клиент.

Давайте посмотрим что мы уже имеем, и чего нам не хватает.

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

Лирическое №1

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

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

Сложилось так, что в качестве рабочей OS у меня установлена последняя версия Ubuntu (13.10). Долгое время я довольствовался последней стабильной версией PHP из репозиториев (видимо везло), но тут по работе пришел проект на 5.3 (а то и 5.2, но под 5.3 завелся), который никак не хотел стартовать на последней 5.5.3, что из официальных репозиториев и я было опечалился (уже имеется опыт установки неактуального PHP на Ubuntu, хоть и успешный, но весьма грустный), но потом вспомнил ruby и rvm.io и решил провести небольшое исследование. В итоге коллега подсказал озвученную в заголовке вещь.

Конец лирического. К фактам.

Если вкратце – единственное назначение phpbrew – возможность использовать разные версии PHP на одной машине. Быстро, просто, практически без танцев с народными музыкальными инструментами. (не продакшен, не параллельная работа, но мгновенное переключение между версиями при разработке).

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

Эти требования разумны. Часть из них трудно реализуема. Часть — очевидна. Часть — зависит от контекста. Но в целом они довольно универсальны. Если будут какие-то вопросы по конкретным пунктам — велкам в комментарии.

Начну с того, что наш проект находится на начальной стадии развития, а его запуск планируется на 1е ноября. И, чтобы сразу отсечь всю возможную критику касаемо преждевременной оптимизации, скажу, что перед командой была поставлена задача разработать приложение, справляющееся с резкими скачками нагрузки (от 1000 до 50000 и т. п.). В связи с этим было решено закладывать хорошо масштабируемую архитектуру, позволяющую легко и быстро увеличивать производительность системы за счет аппаратной части (по принципу scale-out).

Какой бы профессией вы ни владели, каким бы родом деятельности ни занимались — всегда найдётся друг или хороший знакомый, который захочет воспользоваться вашими услугами. Или ему нужно срочно что-то помочь, пофиксить, запилить, прочистить… А вы как раз это умеете, да к тому же ещё и неплохо вроде бы.
Одно дело — это бесплатная дружеская помощь на пять минут, а совсем другое — сделать целый проект за деньги со сроками в месяц или полгода.
И вот для этой ситуации у меня есть несколько (для кого-то очевидных!) советов-правил, которыми я бы хотел поделиться, работая в сфере разработки сайтов.

Ежедневно в социальных сетях, на форумах и на различных сайтах появляется информация, как очередной пользователь современных технологий стал жертвой мошенников. А сколько постов написано об этом на Хабре, дополненных комментариями – можно неделю читать, как большую книгу по безопасности использования благ цивилизации. Но давайте зададимся простым вопросом: как ведет себя большинство потребителей этой информации? Ответ очевиден: читает, закрывает страницу и…забывает. Лишь небольшая часть пользователей пытается вынести урок из чужих ошибок, чтобы не повторять их. Но сознательных пользователей современных технологий так мало, что у меня почти нет сомнений – этот материал для многих откроет заново смысл ежедневных и привычных действий, опасности которых почти всегда игнорируются, хотя для сознательных пользователей в этом посте найдутся прописные истины.

Часто, а на самом деле практически всегда, при создании сайта необходимо, чтобы страницы сайта открывались не по id сущности в базе, а по текстовому идентификатору, назовем его slug.

post/view/1 => post/view/testovaya-novost

(из url'а стоило бы убрать и view, но урок не о том)

Самым примитивным путем можно создать в таблице post поле slug, в модели Post соответственно появляется новый атрибут, в представление (view) добавляем новый input, в который ручками вбиваем slug.

<?php

use yii\helpers\Html;
use yii\widgets\ActiveForm;

/**
 * @var yii\web\View           $this
 * @var common\models\Post     $model
 * @var yii\widgets\ActiveForm $form
 */
?>

<div class="post-form">

	<?php $form = ActiveForm::begin(); ?>

	<?= $form->field( $model, 'name' )->textInput( [ 'maxlength' => 255 ] ) ?>
	<?= $form->field( $model, 'slug' )->textInput( [ 'maxlength' => 255 ] ) ?>
	<?= $form->field( $model, 'content' )->textarea( [ 'rows' => 6 ] ) ?>

	<div class="form-group">
		<?= Html::submitButton( $model->isNewRecord ? Yii::t( 'app', 'Create' ) : Yii::t( 'app', 'Update' ), [ 'class' => $model->isNewRecord ? 'btn btn-success' : 'btn btn-primary' ] ) ?>
	</div>

	<?php ActiveForm::end(); ?>

</div>

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

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

Недавно в нашей фирме устроили лекцию «Engineering Practices» и это оказалось введением в TDD.
О нет, только не это! «Иногда они возвращаются» (с) Стивен Кинг

На прошлой работе мы потратили 3 года на попытку внедрить эту методику. Это было мучительно. Менеджмент искренне верил в то, что TDD решит проблемы фирмы. Реальность разительно несоответствовала этому. Все это будило затертые воспоминания о Советской эпохе. Вспоминались висящие на стенах плакаты «Вперед к победе коммунизма» и фразы вроде «Учение Маркса всесильно потому, что оно верно».


Так что же не так в консерватории c TDD?

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

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



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

• Basic — создан для проектов небольших масштабов;
• Intermediate — подойдёт для большинства проектов средней сложности;
• Advanced — будет хорошим выбором для более сложных проектов с необходимостью предоставления собственного API.

Почему стоит ознакомиться с этой статьёй? Отсутствие доходчивой документации вводит ещё неискушённых разработчиков в ступор (проверено на себе), а куча различных сюрпризов (например, в виде багов) замечательно дополняют это ощущение. Я попытался разобрать процесс работы с Yiinitializr до винтиков, чтобы уберечь вас от большинства неприятностей на пути его освоения.

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

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



Пример и код в jsFiddle.

Окружение, которое выращивает творческих программистов, убивает менеджмент и маркетинг. И обратное тоже верно.

Программирование — это великая Игра. Она поглощает тебя целиком, тело и душу. Когда ты весь погружён в него — для тебя более ничего не существует. Когда ты выныриваешь на свет, ты можешь с удивлением обнаружить, что прибавил 50 кг, возраст твоего исподнего приближается к возрасту первоклашки, и судя по количеству коробок из-под пиццы, уже пришла весна.
Но тебе всё равно, потому что программа работает, код красив, изящен и быстр.

картинка для тех, кто в танке

Пару лет назад меня попросили написать ликбез по сетевому рендеру в блендере.
Я слегка увлёкся и получилось то, что представляю вашему вниманию.
Обзор так и не опубликовали до конца на сайте blender3d.org.ua, хотя pdf там можно найти. Прошу сохранить, может быть кому-то будет интересно.

Привет, Хабрачитатель!
Полнотекстовый поиск данных в InnoDB – это известная головная боль многих разработчиков под MySQL / InnoDB. Для тех, кто не в курсе дела я объясню. В типе таблиц MyISAM есть полноценный полнотекстовый поиск данных, однако сама таблица исторически имеет ограничения, которые являются принципиальными в отдельных проектах. В более «продвинутом» типе таблиц InnoDB полнотекстового поиска нет. Вот и приходится мириться бедным разработчикам либо с ограничениями MyISAM, либо с отсутствием поиска в InnoDB. Я хочу рассказать о том, какие есть способы организовать полноценный поиск в InnoDB без магии и исключительно штатными средствами. Также будет интересно сравнить скоростные характеристики каждого способа.

Генератор будет полезен для тех, кто верстает статические страницы.
Инструмент написан на JavaScript, и, следуя методологии БЭМ, каркас формируется только на основе классов.
Работает просто: на вход получает HTML, на выходе отдаёт CSS.

Попробовать в действии можно на демонстрационной страничке, оформление настраивается по вкусу.

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

В жопу спецификации!

Которые помогут вам оценить и повлиять на состояние ИТ-инфраструктуры вашей организации

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

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

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



Перед вами 8 ситуаций, в которых будут участвовать web-дизайнер — Дмитрий, работающий в программе Photoshop, и верстальщик — Владимир. Эти два парня знают свое дело, но у них постоянно возникают конфликты, а иногда у одного из них возникает странное желание ударить другого монитором по голове. Впрочем, все мы цивилизованные люди и допустить такой развязки не можем. А потому сейчас мы разберемся в некоторых причинах конфликта этих двух бесценных специалистов.

От переводчика: Это седьмая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

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

Постановка задачи

Есть две основные проблемы, которые создают необходимость в конфигурации приложений:

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

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

var conf = {
  // окружение приложения - 
  // "production", "development", или "test
  env: process.env.NODE_ENV || "development",
 
  // IP адрес
  ip: process.env.IP_ADDRESS || "127.0.0.1",
 
  // Порт
  port: process.env.PORT || 0,
 
  // Настройки БД
  database: {
    host: process.env.DB_HOST || "localhost:8091"
  }
};
 
module.exports = conf;

Это работает неплохо, но есть ещё пара проблем:

• Что если в конфигурации указаны некорректные данные? Мы можем сберечь время и нервы, обнаруживая ошибки как можно раньше.
• Насколько легко разобраться в конфигурации администраторам, тестировщикам и другим членам большой команды, когда им надо менять настройки или искать дефекты? Более декларативный и лучше документированный формат сделал бы их жизнь легче.