Github отметил праздничной открыткой преодоление рубежа в 1 миллион зарегистрированных пользователей.

Что может подвигнуть разработчика на написание программного обеспечения просто так, не за деньги, не получая изначально ни копейки а только тратя все свое и без того отсутствующее свободное время? Существует на самом деле множество причин и люди не раз пытались их анализировать. На многих сайтах существует огромное количество опросов, с множеством вариантов ответов, на которые люди отвечают примерно равномерно. Оно и понятно, мотивация у всех разная. Однако, моя задача сегодня не попытаться вывести “теорию опенсорса”. Моя задача сегодня – рассказать о небольшом проекте, который я делал совсем недавно. И который помог мне добиться хороших позиций в жизни, хоть о нем так никто и не узнал.

Задача

Часто приходится сталкиваться с долгосрочными проектами, которые требуют разработки на тестовом сервере под Linux, и после проверки клиентом — обновления кода на его сервере. Разумеется, имеет смысл использовать систему контроля версий (мы используем SVN), и когда есть доступ к клиентскому серверу через SSH — достаточно сделать например команду svn update или svn checkout.

Проблема

Однако, когда к клиентскому серверу есть доступ только по FTP — приходится заливать обновления вручную, используя одну из альтернатив:
— копировать по FTP все файлы проекта, чтобы ничего не упустить
— составлять список файлов которые были изменены с момента предыдущего релиза, и заливать только их.

Решение

Хочу поделиться решением, которое позволяет автоматизировать этот процесс, и производить обновление проекта на клиентском сервере простым запуском скрипта на вашем dev-сервере. Для этого предлагается написать простенький Shell скрипт, который будет выполнять следующее:
1) Экспортировать код проекта из системы контроля версий
2) Обновлять код проекта на клиентском сервере

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

Хочу поделиться рецептом, как совместить php-скрипт и почтовый сервер Postfix для автоматической обработки входящей почты.

С помощью такой связки мы собираем статистику по количеству возвратов bounce-писем:Undelivered Mail Returned to Sender.

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

Читатели помнят, что ещё в декабре прошлого года, после публикации пользователя brunql мы с ним и timsat решили всерьёз взяться за open-hardware проект, который назвали Лайтпак. В феврале мы даже презентовали вам ревизию 4.3 после которой к проекту присоединилось много светлых голов.

А сегодня я готов показать вам чего мы добились к версии 5.5, ставшей первым коммерческим вариантам Лайтпака, который можно купить за деньги:

Намба 0: Вступление

Однажды, задумчиво листая башорг, я вдруг понял, что большинство цитат довольно длинные и очень часто их просто лень читать. В наш век всеобщей спешки — на это уходит много времени. Таким образом родился новый формат: Шортики (от английского слова Short — короткий). Шортик — это короткая (из одного-двух предложений) шутка, жестко ограниченная 255 символами (чтобы не повадно было).

Как раз в этот момент я хотел подучить программирование и искал несложную задачу. Сайт я накидал довольно быстро — за пару вечеров, рассказал о нем коллегам по работе и паре знакомых в IRC, и собирался уже о нем забыть, как вдруг обнаружил, что за два дня сайт посетило 500 человек, из которых чуть ли не треть подписалась на RSS. Стало понятно, что концепция людям понравилась. Немного прилизав сайт внешне, я решился показать его Хабрасообществу — Шортики — короткие и смешные, прошу любить и жаловать.

P.S. Учитывая то, что это не совсем стартап (проект пока некоммерческий, да и «стартап» — слишком громкое слово для моей поделки), приобретенная за годы пребывания на сайте хабрасовесть не позволила мне написать нетехническую статью. Поэтому, под катом вас ждет занимательная история о том, как мы готовили Шортики к Хабраэффекту.

Хорошим тоном считается всегда указывать для изображений, которые мы используем на странице, их длину и ширину. Часто такие картинки, если мы не укажем их размеры, могут во время загрузки раскачивать нашу верстку.
Чтобы во время разработки было более наглядно, где мы пропустили картинки без указания размеров, ребята из 37Signals предложили небольшой, но чрезвычайно полезный сниппет:

img:not([width]):not([height]) {
  border: 2px solid red !important;
}

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

Оригинал статьи

Эта статья — продолжение цикла статей по информационной безопасности в веб-приложениях (и не только).

Вообще думал написать о «белом ящике», но я решил что нужно сначала ликвидировать возможные пробелы у целевой аудитории (в основном веб-разработчики) в этой области.

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

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

Как обычно — ответственность за все полученные знания только на читателе :)

Здравствуйте, уважаемые коллеги.

Одним из косвенных показателей качества кода считается code coverage — степень покрытия его тестами (как правило, имеются в виду модульные тесты). В большинстве случаев за coverage принимается соотношение количеству строк кода, в котрое попадает управление во время прогона тестов, к общему числу значимых (не являющихся комментарием, пустой строкой, или, например одной фигурной скобкой, обозначающей начало или конец блока) строк кода модуля.

Другим же условием хороших тестов является отсутствие сторонних эффектов (side effects), как например создание/удаление файлов, установка сетевых соединений, запись в порты и т.д.

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

Под катом вы найдете мое решение и, в качестве бонуса, еще одну ОПП-обертку к курлу, полностью покрытую тестами.

«Для многих цивилизаций Восточного Завитка Галактики, не столь церемонных, elFinder уже с успехом заменил прочие web файловые менеджеры и стал общепринятым, поскольку, хотя в нем и встречаются редкие баги, но зато у него есть два больших преимущества.
Во-первых, он дешевле;
а во-вторых, у него есть большая красная кнопка, на которой большими веселыми
буквами написан дружеский совет: Don't panic!»

Сегодня у меня по настоящему счастливый день!
Несколько месяцев крайне напряженной, но невероятно приятной работы позади.
И я с удовольствием представляю — файловый менеджер для web elFinder 2.0 beta!

Хочу выразить огромную благодарность всему сообществу за помощь, патчи и переводы.
Коллегам по студии — спасибо, что взяли на себя всю текучку, чтобы освободить меня для этого проекта.
И хочу представить нового разработчика elFinder — 667bdrm. Он же автор модуля для drupal.
И еще, нам всем очень приятно, что сейчас нет практически ни одного фреймворка, в который бы не был интегрирован elFinder. Кстати, одними из первых это сделали РБК Софт.

Тема почтовых рассылок на хабре поднималась буквально недавно, но там не освещался один важдый момент: как обеспечить редактируемость контента этой рассылки после красивой и аккуратной верстки.

Ведь если сверстано на таблицах, с пустыми gif'ами для отступов — результат «монолитный», но не дай бог такое редактировать контент-менеджеру. Моментально всё поедет, да и не умеют нормально визивиги работать с таким ужасом.

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

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

• Объяснить зачем это нужно разработчикам и руководству
• Ввести в обиход новую схему работы с кодом
• Научить ничего не подозревающих девелоперов новым техникам

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

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

В этой части статьи я напишу о вертикальном маргине. О горизонтальном поговорим в следующей части.

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

Скрипт создает 2 архива: в одном файлы, в другом директория с дампами всей БД по базам.
Нужно поменять настройки в начале.

В качестве ответа на отчёт НАТО об угрозе «хактивизма» группировка Anonymous опубликовала открытое письмо (сайт сейчас под DDoS-атакой, так что см. кэш Google). Публикуем перевод этого документа.

Приветствуем вас, члены НАТО. Мы — Anonymous.

В своей недавней публикации вы представили Anonymous как угрозу «государству и народу». Вы также заявили, что секретность якобы является «неизбежным злом» и что прозрачность — не всегда правильный способ развития.

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

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

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

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

В эту пятницу, 27 мая, популярнейшей CMS Wordpress исполнилось ровно восемь лет — именно 27 мая 2003 года была анонсирована open-source CMS с таким названием. То, что появилось, как форк блоггинг-платформы b2, стало невероятно популярной самодостаточной платформой, которую используют миллионы людей. Сайты на Wordpress делают все — от школьников до крупнейших интернет-СМИ. Сейчас на этой CMS работает около 45 миллионов сайтов, включая Mashable. Предлагаю заново просмотреть историю Wordpress в скриншотах, и вспомнить, как все начиналось. Лично я начал работать с Wordpress, начиная с версии 2.3.3. Все промежуточные версии не будем указывать, в обзорчике показаны только ключевые версии и обновления.

Что делать, если нужно создавать много Word файлов одинакового вида, но разного содержания? Например заполнять бланки, квитанции.

Есть 3 варианта:
1) использовать одну из библиотек для работы с Word документами
2) сохранить документ в формате docx, открыть архиватором и внутри мы увидим "\word\document.xml" — чистый xml, с которым можно работать через str_replace (спасибо Enuriru за подсказку)
3) использовать сторонний сервис, который сделает за меня большую часть работы

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

Второй варинт хорош и прост, когда мы работаем с word документами в формате .docx, но к сожалению он не поддерживает формат .doc

В процессе проработки третьего варианта, наткнулся на интересное решение LiveDocx

Преимущества:
— файл шаблона можно создать привычным способом через Word
— представление документа в форматах doc, docx, rtf, pdf
— не нужно заморачиваться с представлением Word документа через html или XML
— простота подключения
— надежность — сервис существует давно и под него даже есть готовая библиотека от Zend
Недостатки:
— в бесплатной версии ограничение на 250 генерируемых документов в сутки
— шаблон нельзя менять (например нельзя сгенерировать таблицу с кол-вом строк, равным количеству элементов в базе)

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

Обычно ставят на новую железку новую ОС, поднимают софт, настраивают, переносят контент, базы и прочее, меняют DNS и через двое суток выключают старый сервер. Казалось бы простая процедура, сотни раз её делал любой сисадмин. НО, в процессе как показывает практика что-то забывается и уже на боевом сервере нужно делать правки и настройки, тащить старые костыли и адаптировать их на новом месте.

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