«Если говорить о бизнесе, мой опыт показывает, что большинство контор являются крайне неэффективными.»

Сегодня в моем G+ появился этот пост испанского блогера, который пишет о личной эффективности и производительности — словом, очередной productivity-freak, поехавший, как и я, по GTD, time management и прочим похожим красивым словам. Текст оказался написан достаточно харизматично и, на мой взгляд — толково, в связи с чем нет сил больше прятать. Пост посвящен попыткам справиться с неимоверным батхертом, который рано или поздно встречается на пути каждого, кто научился худо-бедно организовывать своё время и теперь стоит лицом к лицу с вопросом «что же делать с раззвездяями кругом»? Поскольку писал ИТ консультант, в то время как у нас же тут все программисты, поэтому текст слегка адаптирован под наши особенности – без ущерба общему смыслу.

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

Настройка резервного копирования в Ubuntu за 20 минут.

Для работы над проектами использую svn, который находится на удаленном виртуальном выделенном хосте, под управлением ubuntu 8.04. Со временем объемы данных выросли, как и критичность этих данных. Потеря чего-то снилась в кошмарах. Время от времени копировал репозитории на локальный компьютер. Недавно мне это надоело. И я стал искать возможности автоматизировать это дело. Не буду говорить о поисках и вариантах, расскажу о результатах.

Итак, мы имеем удаленный хост под управлением ubuntu, с некоторым массивом довольно критичных данных. Довольно логичным было бы настроить бэкап прямо на удаленном хосте, с помощью tar по крону, rsyns и т.д. Но, т.к. место на виртуальном выделенном хостинге довольно дорого и использовать его лучше по делу, идеально было бы, чтобы данные автоматически копировались на какую нибудь локальную машину, место на которой хоть отбавляй. В моем случае это файловый сервис в офисе, под управлением все той же Ubuntu.

Я уже довольно долгое время хочу формализовать все свои мысли, опыт, ежедневно применяемый на практике, и многое другое в одном месте и предоставить их общественности. Уверен, многим этот материал будет полезен. Он посвящен различным моментам в конфигурации серверного ПО Linux и безопасным подходам к созданию сайтов/приложений на php (все же это до сих пор одна из самых популярных связок, хоть её успешно и подвигают другие технологии. Но советы так же легко применимы и к веб-ресурсам на других технологиях).

Т.е. речь идет о типичной ситуации. Проект (стартап), купили под него сервер и разворачиваем на нем сайт. Бизнесу не нужно тратить лишних денег на сервера (поэтому будут выбраны наиболее производительные связки ПО), а так же нужно, чтобы все было безопасно, при чем бесплатно :)

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

В итоге получилась система, сочетающая включение/выключение света как с помощью выключателей, так и через интернет — с помощью кнопок на веб-страничке.
Как это получилось — читайте под катом.

Вступление

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

Когда я впервые увидел статью на хабре «Народный мониторинг температуры (vs прогноз) в различных городах. Нужен ли?», посвященную мониторингу параметров среды narodmon.ru, я как-то скептически отнесся к такой затее и забыл про нее. Перед новым годом у меня появилась Raspberry Pi и какое-то время ушло на ее освоение и обзор возможностей, в итоге что-бы малинка не простаивала, да и так для общего развития по статье «История взаимодействия «чайника» и DS18B20 посредством Raspberry Pi» сделал тоже самое, но с учетом исходников первоисточника, в который уже внесены изменения по мотивам вышеприведенной статьи с ссылкой на хабр. Температура измерялась, графики строились, но как-то скучно стало за этим наблюдать, да и применение малинки в этих целях это как из пушки по воробьям, и в один прекрасный день я вспомнил про «Народный мониторинг», на котором вся отображаемая на сайте информация выводится только на основании сведений о текущих параметрах среды(температура, влажность, атм.давление и др.) передаваемых с клиентских устройств пользователей данного сервиса. Начал искать и нашел статью «Лучшая реализация реализация UART => 1-wire и I2C/SPI на базе роутеров». Тут я и загорелся идеей сделать такое устройство, правда в надежде на то, что кто-то уже это сделал, а я только повторю, благо роутер TL-MR3020 уже имелся в хозяйстве, и над ним уже ставились бесчеловечные опыты по привинчиванию его к «самокатной телеге» с камерой по мотивам статьи «Простой wifi бот для мониторинга помещений или «кухонное» роботостроение».

Скажу сразу, всю DOM-модель мы строить не будем, а лишь рассмотрим ее элементы и как с ними работать при помощи jQuery. Статья рассчитана на начинающих или тех кто хочет вспомнить как можно строить элементы «на лету», надеюсь кому-то это будет полезно.
Большинство веб-разработчиков сталкивается с необходимостью вставить какое-либо содержимое из js, возможно это ajax или событие. Но никто не задумывается о том что с вашим кодом возможно кому-то придется работать. И часто даже в очень известных плагинах можно встретить код такого типа:

var content = "<table>"
for(i=0; i<3; i++){
    content += '<tr><td>' + 'result ' +  i + '</td></tr>';
}
content += "</table>"

$('#table').append(content);

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

Введение

Как известно, nginx умеет кешировать ответ сервера, и выдавать его по запросу вместо обращения к бэкенду, экономя тем самым ресурсы сервера. Скорость отдачи таких закешированных страниц иногда поражает, ради таких скоростей иногда не жалко переносить на javascript многие функции сайта только для того, чтобы иметь возможность закешировать ещё 1 страницу целиком (Например, вынести отрисовку плашки с авторизацией юзера на js, чтобы иметь возможность кешировать страницу, которая идентична для всех пользователей, за исключением этой самой плашки).

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

• Можно легко закешировать вообще все страницы, но для динамических сайтов или для сайтов с авторизацией нужно ли это?
• Можно закешировать отдельно несколько url, вида /album/*, но не переписывать же конфиг nginx каждый раз при появлении новых разделов сайта?

Pudb — полноэкранный консольный дебагер с графическим интерфейсом. Большим плюсом является то, что в нем есть подсветка синтаксиса, дополнительные панели вывода информации, горячии клавиши и интерграция с IPython.

pdb, в сравнении с Pubd, показался жутно не удобным и ограниченым. Поиск ошибок стал занимать на много меньше времени и приносить больше удовольствия. При первом взгляде на него вспоминался Assembler и Turbo Pascal в студенческие годы в техникуме.

Если кто заинтересовался примеры установки и использования под катом.

Доброго времени суток!

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

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

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

Оглавление:

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

Прим. переводчика — В оригинале использовался всем знакомый термин «software engineer». Так как русский его аналог «инженер-программист» используется в повседневной речи редко, пришлось использовать слово «разработчик» как наиболее близкое. Также профессия «short-order cook», с которой автор сравнивает положение многих разработчиков в индустрии, была переведена как «мальчик на побегушках» — мне кажется, что она отлично отражает суть проблемы отношения к разработчикам. Наконец, я старался везде вместо слов «to code» и «programming» использовать «разрабатывать» и «разработка» из-за сложившемся в русском языке негативном смысле слов «кодировать» и «программирование» как примитивных процессов перевода требований в машинные инструкции низкого или высокого уровня.

Автор оригинальной статьи — Nickolas C. Zakas, известный фронтенд разработчик и JavaScript-евангелист в свое время проработавший более пяти лет в Yahoo. Это запись из его блога, в которой он говорит о том, почему с разработчиками так сложно договориться и что с этим делать.

Не так давно Дженна Байлотта написала замечательную статью «Как дизайнерам ужиться с разработчиками», в которой она описывает методы работы в команде, позволяющие дизайнерам и разработчикам добиться лучшей производительности. Я в свое время работал с дизайнерами (а, работая в UI, и с разработчиками) и столкнулся с похожими проблемами, так что мне понятен ее практичный подход. Во время командной работы никогда не помешает уважать труд своих коллег и понимать их способ мышления.

Одна из главных мыслей той статьи заключалась в том, что разработчики говорят «нет» слишком быстро. Эта мысль тут же въелась мне в мозг и долго отказывалась вылезать оттуда. Мне хотелось воскликнуть: «Но подожди, ты же не понимаешь, почему мы говорим „нет“!». Тут же появился миллион других защитных аргументов. На самом деле она, конечно, права — мы правда слишком быстро говорим «нет», причем не только дизайнерам, а вообще всем. Это побудило меня поразмыслить над психологией разработчиков и тем, что составляет нашу истинную суть.

Привет!

Расскажу об одной небольшой (~30kb) JS библиотеке для удобной работы с Google Maps API под названием gmaps.js.
Раз уж библиотека создана для ускорения процесса веб-разработки, то и я вас задерживать не буду. Как можно понять из названия, она делает не что иное, как упрощает взаимодействие с API Google Maps. Многие из вас работали с API и, вероятно, каждый раз вам приходилось попотеть, чтобы порыться в документации и реализовать, например, свое собственное описание метки на карте. Или подписаться на событие взаимодействия с картой…

Всем привет!

Сегодня расскажу, как на боевых серверах во время нагрузки, в пыли и грязи, эффективно отлавливать узкие места в производительности больших веб-приложений на PHP, а также искать и устранять «нестандартные» ошибки. Многие из описанных техник мы с успехом применяем на нашем облачном сервисе «Битрикс24».
Информация, надеюсь, пригодится системным администраторам и разработчикам, обслуживающим сложные веб-проекты, а также менеджерам, которые хотят выстроить эффективный и быстрый процесс поиска и устранения узких мест и ошибок проектов на PHP.

Неуловимый Go.

Помните анекдот про неуловимого Джо? Именно восклицанием «Да кому он нужен!», прозвучавшим в форме вопроса "ЗАЧЕМ?", был встречен на Хабре релиз первой стабильной версии GO 1.

Именно на этот вопрос я хочу ответить циклом статей, оформленных в необычном для Хабра формате — в виде пошаговой совместной разработки действующего веб-проекта — с живым обсуждением и добавлением функционала. А чтобы вдвойне оправдать внесение цикла ещё и в хаб «Высокая производительность», мы поставим перед собой задачу создать не просто «хомяка», а проект, который наглядно продемонстрирует habri et orbi способность выдерживать значительные естественные нагрузки.

Вместо аперитива: реализация простейшего динамического веб-приложения на языке Go работает в 5-20 раз быстрее аналогичной Python-реализации. И всего в два раза уступает скорости отдачи статики Nginx-ом.

В рамках этого проекта, помимо самого языка Go, мы косвенно затронем и другие (относительно новые) технологии веб-разработки — HTML5, CSS3, Redis, MongoDB. Также я постараюсь вытащить из закутков долговременной памяти некоторые из трюков в области безопасности и экономии на спичках, коих накопилось много за полтора десятка лет работы в этой области. Устраивайтесь поудобнее, запасайтесь терпением и кофе — под катом «много букв», а ведь это только вводная часть :)

Теория создания самодельной автомобильной спутниковой сигнализации с web-интерфейсом и поддержкой eCall / ЭРА-ГЛОНАСС на базе микроконтроллеров STM32 как основа концепции «Умный автомобиль», и её использование в системах «Умный дом». Реализация аналога технологии Volvo On Call и автомобильной социальной сети Toyota Friends.

Распространенное мнение о появлении панка, состоит в том, что панк был реакцией на крайности современного рока, в частности прогрессивного рока того времени. Реальность, безусловно, намного сложнее, но я подозреваю, что доля правды в этом есть. Рок-н-ролл в поздние 60-е и 70-е, похоже, был областью “Золотых Богов”, недоступной простому смертному. Контраст между группами типа Rush и Black Flag был огромен.

Говорят, что современные аппаратные технологии поддержки виртуализации (VT-d у Intel, IOMMU у AMD) позволяют отдавать физическое устройство на шине PCI в непосредственное управление виртуальной машине. В том числе видеокарту.
Воображение рисует такую конфигурацию: настольный сервер с гипервизором, на нем запускается гостевая пользовательская операционная система, имеющая доступ к необходимым устройствам ввода-вывода, один-два неприхотливых сервера по мере надобности, ну и сколько надо виртуалок для бесчеловечных экспериментов. Управляем гипервизором через консоль в гостевой ОС либо удаленно, с ноутбука, скажем.
Вдохновленный этой картиной, я решил попробовать, но оказалось, что проброс (passthrough) видеоадаптера — задача не совсем тривиальная. Только месяца через три боданий с железом и чтения форумов удалось получить положительный результат. В качестве гипервизора пробовал VMware и Xen. Получилось только с Xen.

После моего поста в прошлый четверг не осталось сомнений в том, что простой и бесплатный шаблон (кто-то даже называет фреймворк) с адаптивной версткой на HTML5 вызывает интерес у потенциальных пользователей. Пост даже собрал достаточно голосов, чтобы НЛО разрешило мне пригласить кого-нибудь на Хабрахабр.

Нужно напомнить, что Simpliste — именно такой шаблон. И теперь работа по его развитию пойдет полным ходом.

Одним из преимуществ Simpliste я считаю наличие готовых тем оформления. Сразу, в момент запуска существовало 3 темы. Постепенно я создал еще несколько.

Введение. В современном мире существует большое количество задач, в рамках которых приходится обрабатывать большие массивы однотипных данных. Яркими примерами являются системы для анализа биржевых котировок, погодных условий, статистики сетевого трафика. Многие из этих систем используют различные реляционные базы данных, в таблицах которых содержатся такие объемы данных, что правильное составление и оптимизация запросов к этим таблицам становится просто необходимым для нормального функционирования системы. В этой статье описаны методы решения ( и сравнительные временные характеристики используемых методов ) нескольких задач по получению данных из таблиц СУБД MySQL, содержащих статистику о проходящем через маршрутизаторы одного из крупных российских сетевых провайдеров сетевом трафике. Интенсивность потока данных, поступающего с главного маршрутизатора такова, что ежесуточно в таблицы базы данных используемой системы мониторинга сетевого трафика поступает в среднем от 400 миллионов до миллиарда записей, содержащих информацию о транзакциях TCP/IP (рассматриваемый маршрутизатор экспортирует данные по протоколу netflow). В качестве СУБД для системы мониторинга используется MySQL.