/ фото Ozzy Delaney CC

Мы в 1cloud много рассказываем о собственном опыте работы над провайдером виртуальной инфраструктуры и тонкостях организации внутренних процессов. Сегодня мы решили немного поговорить об оптимизации БД.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Привет. Это пост о новой версии Тарантула «от автора». Интернет занятно устроен: если поискать про Тарантул, то найдётся статья от 2011 года, о версии 1.3. И ещё какой-то перфоратор, кажется. На форумах-бордах вообще стоит густой туман. Тарантул «ну это как Редис, только»…

Или ещё, недавно сделал для себя открытие, на Тостере кто-то написал «София — это такое append-only хранилище по типу Тарантула». С такими постами я скоро стану фанатом сайта «сделано у нас», автомата Калашникова и Саяно-Шушенской ГЭС. Правда, мне сложно понять, почему мы восхищаемся западными инструментами, при этом представления не имеем о своих. Итак, Tarantool 1.6. В чём фишка?

Эта заметка навеяна мелькавшими последнее время на хабре постами двух тематик — «интересные команды unix» и «как я подбирал программиста». И описываемые там команды, конечно, местами интересные, но редко практически полезные, а выясняется, что реально полезным инструментарием мы пользоваться и не умеем.
Небольшое лирическое отступление:
Года три назад меня попросили провести собеседование с претендентами на должность unix-сисадмина. На двух крупнейших на тот момент фриланс-биржах на вакансию откликнулись восемь претендентов, двое из которых входили в ТОП-5 рейтинга этих бирж. Я никогда не требую от админов знания наизусть конфигов и считаю, что нужный софт всегда освоится, если есть желание читать, логика в действиях и умение правильно пользоваться инструментарием системы. Посему для начала претендентам были даны две задачки, примерно такого плана:
— поместить задание в крон, которое будет выполняться в каждый чётный час и в 3 часа;
— распечатать из файла /var/run/dmesg.boot информацию о процессоре.

К моему удивлению никто из претендентов с обоими вопросами не справился. Двое, в принципе, не знали о существовании grep.



Поэтому… Лето… Пятница… Перед шашлыками немного поговорим о grep.

Ежегодная конференция профессиональных веб-разработчиков DevConf проходит с 2010 года. Она состоит из нескольких секций, посвященных самым популярным языкам и технологиям веб-разработки. В 2015 году году компания Badoo взяла на себя важную миссию — записать видео выступлений, чтобы те, кто не смог посетить конференцию, могли посмотреть их в любое время.

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

Секция PHP конференции DevConf 2015

В первую очередь хотелось бы отметить доклад Дмитрия Стогова (Zend Technologies) «Релиз PHP 7: что нас ждет в октябре 2015». Не будем мучить вас переводом «чейнджлога» седьмой версии, а скажем просто: смотреть всем, кто имеет хоть какое-то отношение к PHP. Если вы за свою жизнь написали хотя бы строчку кода на PHP, то, скорее всего, уже слышали про сумасшедшую производительность, JIT и spaceship operator. JIT в PHP так и не появился, но оптимизации проведены масштабные. В докладе Дмитрий рассказывает много о внутренней кухне PHP, есть графики производительности разных версий PHP и HHVM на реальных приложениях. Badoo сейчас как раз в процессе перехода на PHP 7, нам пришлось сильно «перекопать» инфраструктуру тестирования и переписать кучу расширений, но мы на финишной прямой и можем подтвердить, что PHP 7 действительно показывает очень серьезный рост производительности. Какой именно получается прирост? Пока секрет. Ждите от нас отдельной статьи на эту тему, когда мы поборем последние косяки, отлавливаемые на продакшн-трафике.

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

В прошлой статье мы рассказали, что такое Docker и как с его помощью можно обойти Vendor–lock. В этой статье мы поговорим о Dockerfile как о правильном способе подготовки образов для Docker. Также мы рассмотрим ситуацию, когда контейнерам нужно взаимодействовать друг с другом.


В InfoboxCloud мы сделали готовый образ Ubuntu 14.04 с Docker. Не забудьте поставить галочку «Разрешить управление ядром ОС» при создании сервера, это требуется для работы Docker.

Задача данной статьи — показать самый производительный путь написания тестов в контексте разработки веб-приложений.

Здесь и дальше под термином тесты будут подразумеваться юнит-тесты.

Разработка веб-приложений сопровождается постоянным использованием в коде базы данных. Если код работы с базой данных и код работы с результатом взаимодействия с базой данных не разделен, нам потребуется база данных в подавляющем большинстве тестов проекта. Также, если код использует методы фреймворка, нам для тестов потребуется подключить фреймворк. Пока тестов мало, всё отлично. Когда тестов становится больше, замечается проблема: скорость выполнения тестов немного напрягает. Когда время выполнения всех юнит-тестов становится больше чем минута, становится невозможным постоянно запускать все тесты. Разработчик начинает запускать только часть тестов, пытаясь уменьшить негативное влияние длительного времени работы тестов, но проблема снижения эффективности тестирования со временем будет только возрастать.

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

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

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

1. Видео с доклада
2. Слайды

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

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

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

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

Библиотека докладов

Это не просто статья — это целая библиотека докладов про внутреннее устройство тех или иных крупных и высоконагруженных проектов. Все эти доклады звучали на конференциях HighLoad++ и РИТ++ за последние несколько лет.

1. Введение

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

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

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

В Технопарке я преподаю студентам курс «Базы Данных». Уже из названия ясно, что речь идет о неотъемлемой части современной IT-грамотности — без этой дисциплины сегодня трудно представить себе компьютерную специальность. Базы данных в том или ином виде сегодня окружают нас повсюду — в самом обычном смартфоне их сотни, что, разумеется, далеко не предел.

Написание статьи навеяно habrahabr.ru/qa/34735 и habrahabr.ru/qa/32135 вопросами, в качестве ответов на которые не смог найти полной и подробной информации, чего очень не хватало. Я надеюсь, что она будет полезна и другим.

Проект, на чью долю пал выбор в виде ZF в качестве основного фреймворка, представлял из себя мобильную версию сервиса (адаптивный дизайн с некоторыми ньюансами) + АПИ для мобильных приложений.
Коллегиально было принято политико-техническое решение делать единое АПИ, посредством которого будет общаться и сайт, и приложения.

На этом, думаю, прелюдию можно закончить и перейти к самому интересному.

В своих двух предыдущих статьях я рассказал о Dependency Injection и IoC контейнере, и о том, как они работают конкретно в Laravel. Данный пост будет посвящен практическому применению DI и IoC на реальном примере. А так же, какие все таки преимущества нам дают эти два прекрасных инструмента и паттерна в приложении.

О боже, ещё один пост о Inversion of Control

Каждый более-менее опытный программист встречал в своей практике словосочетание Инверсия управления (Inversion of Control). Но зачастую не все до конца понимают, что оно значит, не говоря уже о том, как правильно это реализовать. Надеюсь, пост будет полезен тем, кто начинает знакомится с инверсией управления и несколько запутался.

Привет, Хаброжители!
У нас вышла новая книга С. Чакона и Б. Страуба



Эта книга представляет собой обновленное руководство по использованию Git в современных условиях. С тех пор как проект Git — распределенная система управления версиями — был создан Линусом Торвальдсом, прошло много лет, и система Git превратилась в доминирующую систему контроля версий, как для коммерческих целей, так и для проектов с открытым исходным кодом. Эффективный и хорошо реализованный контроль версий необходим для любого успешного веб-проекта. Постепенно эту систему приняли на вооружение практически все сообщества разработчиков ПО с открытым исходным кодом. Появление огромного числа графических интерфейсов для всех платформ и поддержка IDE позволили внедрить Git в операционные системы семейства Windows. Второе издание книги было обновлено для Git-версии 2.0 и уделяет большое внимание GitHub.

В одном из комментариев здесь была просьба рассказать подробнее об индексах, и так как, в рунете практически нет сводных данных о поддерживаемых индексах различных СУБД, в данном обзоре я рассмотрю, какие типы индексов поддерживаются в наиболее популярных СУБД

^{Капитан Немо у штурвала «Наутилуса»}

Индексы — один из самых мощных инструментов в реляционных базах данных. Мы используем их, когда нужно быстро найти какие-то значения, когда объединяем базы данных, когда нужно ускорить работу SQL-операторов и т.д. Но что представляют собой индексы? И как они помогают ускорять поиск по БД? Для ответа на эти вопросы я изучил исходный код PostgreSQL, отследив, как происходит поиск индекса для простого строкового значения. Я ожидал найти сложные алгоритмы и эффективные структуры данных. И нашёл.

Здесь я расскажу о том, как устроены индексы и как они работают. Однако я не ожидал, что в их основе лежит информатика. В понимании подноготной индексов также помогли комментарии в коде, объясняющие не только как работает Postgres, но и почему он так работает.

Впервые я столкнулся с Upwork (тогда еще oDesk) в 2011м году, когда брат прислал на них ссылку в скайпе. Я только начинал работать на русских биржах, и подумал — почему бы не попробовать еще и на зарубежной. Но тогда все закончилось ничем. Результаты были слабыми, и, разочаровавшись во фрилансе как таковом, я бросил это дело.

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