В топиках про немецкий хостинг от Hetzner и Server4You (кстати, у последней компании есть ещё несколько сайтов – будьте аккуратнее) люди интересовались, а почему именно хостинг в Германии? То, что не в России мы теперь уже знаем точно, и если у проекта в целевой аудитории центральная и западная Россия и/или Европа, то выбор немецкого хостинга часто оказывается оптимальным по соотношению цены/качества/пинга. Однако, если ваш проект нацелен на США или на весь мир? Думаю, что хостинг от Hetzner тут подходит довольно слабо — эта компания, как и почти все немецкие хостинги ориентируется в основном на внутренний рынок, не заботясь ни о доступности серверов вне страны (очень часто в случае с Hetzner пинг в Россию или вообще доступность сервера из России оказывается под вопросом), ни о хорошей международной поддержке хотя бы на английском языке (у Hetzner сейчас эту проблему, решили и саппорт доступен на английском, что далеко не всегда так в случае с другими немецкими хостерами – очень часто и сайт и саппорт на немецком языке). Для сервиса ориентированного на самый прибыльный – американский сегмент желателен и хостинг американский и возможность «роста».

Т.к. наша компания уже практически год является клиентом одного из американских VPS-хостингов (открываем там небольшой бесплатный хостинг картинок — можно попинговать и всячески проверить работу), хочу рассказать про него, сделав некоторые сравнения с хостингом немецким (да простят хабражители, за сравнение VPS от BurstNET с опытом использования Dedicated-сервера от Hetzner – весовые категории разные, но, опыт общения с Hetzner у нас основан именно на аренде выделенного сервера).

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

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

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

На GoogleSites есть соответствующий шаблон для портала проекта. Приведу его краткий обзор.

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Проведя последние несколько дней за изучением документации по Zend Framework, я был приятно удивлен новым функционалом, который был добавлен в последнюю версию этого каркаса Web-приложений.
Моей первой мыслью было осознание скорости, с которой взрослеет технология PHP.
Легкость совместного использования Zend Framework и PHPUnit — это, на мой взгляд, одно из наиболее значительных достижений.

0 Преамбула

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

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

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

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Почему после распараллеливания выполнение вашей программы может замедлиться вдвое?
Почему после создания потока перестает работать Ctrl-C?
Представляю вашему вниманию перевод статьи David Beazley «Inside the Python GIL». В ней рассматриваются некоторые тонкости работы потоков и обработки сигналов в Python.

^{*) На самом деле все равно сложно, но зато проще, чем было раньше.}

История началась с постановки задачи: нужно сделать анимированный баннер с примерно тридцатью объектами средствами HTML+javascript за один день. За день, конечно, баннер сделан не был, а был сделан за два усилиями трех человекодней. После выполнения задания осталась библиотека пакетной анимации, которую я назвал Scenario. О её доработанной версии я и хочу рассказать.

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

Запуск сценария из любого места предельно прост:

var newScenario = [...];
$.scenario(newScenario, {
    complete: function(time) {
        alert('Готово!');
    }
});

Осталось только разобраться, что писать вместо трех точек в примере :)

JavaScript 1.8 предоставляет огромное количество вкусного синтаксического сахара, в основном любителями функциональщины. Но очень мало разработчиков знает об этой красоте. Конечно, к сожалению, все эти вкусности не поддерживает даже Chrome (что уж говорить об IE?), а только Firefox 3+, но JavaScript-разработчик просто обязан знать обо всех этих новинках.

Наиболее полную информацию можно найти в статьях на MDN:

• New in JavaScript 1.7
• New in JavaScript 1.8

А я перевела небольшую, но интересную статью Джона Ресига (автора jQuery), который раскрывает в ней некоторые из новых фич: Expression Closures, Generator Expressions, __iterator__, Array Reduce и кое-что ещё:

// Останавливаем выполнение события по-умолчанию
document.addEventListener("click", function() false, true);
// Выводим три сообщения
for ( let i in 3 ) alert( i );
// Создаем массив из 100 элементов, заполненный нулями
[ 0 for ( i in 100 ) ];
// Создаем единичную матрицу 10*10
[[ i == j ? 1 : 0 for ( i in 10 ) ] for ( j in 10 )];

Знаете ли вы что такое рейтрейсер? Это программа которая рисует трёхмерную сцену на экране так, как её бы увидели вы. Конечно, не совсем так, но некоторые рейтрейсеры умеют рисовать очень правдоподобные картинки, например как в "Аватаре".

Идея рейтрейсера очень простая и в этой статье я раcскажу как устроен этот алгоритм и даже напишу его на JavaScript. Картинки и пример прилагаются.

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

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

На сегодняшний день наиболее часто используемым паттерном проектирования сайтов является Модель-Вид-Контроллер (MVC). Повсеместное его использование отчасти вызвано успехом и популярностью фреймворка Ruby on Rails. Сейчас MVC является практически синонимом веб-разработки среди всех платформ.

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

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

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

Часто требуется реализовать возможность рейтингового оценивания того или иного объекта (заметки, комментария, цитаты, фотограммы, видеоролика и т. д.) посетителями сайта. Как это запрографировать?

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

Для того, чтобы обеспечить слабую связанность конкретных сущностей предметной области, к которым мы привязываем возможность рейтингового голосования, с модулем, реализующим нашу задачу, мы выделяем отдельные классы для объекта (Rating_Object) и субъекта (Rating_Subject). Оба эти класса — конкретные и реализованы как active record. Чтобы иметь возможность привязывать всяческие статьи и фотограммы к экземплярам Rating_Object, мы предусматриваем интерфейс Rating_Ratable:

interface Rating_Ratable {
    /**
     * @return Rating_Object
     */
    public function asRatingObject();
}

Прочитав статью решил проверить, насколько пригоден для этого Haskell. Сразу скажу, сам Haskell пригоден весьма неплохо, но вот, пробежавшись по hackage.haskell.org, я сразу обнаружил проблемы с библиотеками для работы с PDF, что и поставило крест на полноценной реализации.
Но я решил всё же проделать часть работы, дабы показать, как та же задача могла бы быть сделана на Haskell, если бы да кабы…

Deferred объекты появились в jQuery 1.5. Они позволяют отделить логику, которая зависит от результатов выполнения действия от самого действия. Для JavaScript Deferred объекты не новы, они уже были в MochiKit и Dojo, но с изменениями логики jQuery ajax от Julian Aubourg, внедрение Deferred объектов было неминуемо. С Deferred объектами несколько callback могут быть связаны с результатом задачи и любые из них могут быть привязаны к действию даже после начала его выполнения. Выполняемая задача может быть асинхронна, но не обязательно.

Deferred объекты теперь встроены в $.ajax() таким образом вы будете получать их автоматически. Обработчики теперь могут быть связаны с результатом следующим образом:

// $.get, ajax запрос, он асинхронный по умолчанию
var req = $.get('foo.htm')
   .success(function( response ){
      // что-нибудь делаем с ответом
   })
   .error(function(){
      // делаем что-нибудь если запрос провалился
   });
 
// это выполнится перед тем как $.get() будет выполнено
doSomethingAwesome();
 
// Делаем что-то ещё перед завершением запроса
req.success(function( response ){
   // делаем  что-то ещё с ответом
   // он будет выполнен когда запрос завершится, а если запрос завершен, то будет вызван немедленно
   // если запрос уже был выполнен
});

Всех с наступившими!



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

UPD:
— Исправлена ошибка «too large on page» (подробнее на github) Спасибо Bifidokk и StreetAngel
— Авторы топиков сделаны ссылкой
— Добавлена возможность сохранять избранное только из указанных блогов

Однажды возникла задача настроить раздачу интернета на пару десятков компьютеров (офисные и домашние). Коробочные решения оказались либо платными, либо достаточно сложно настраиваемыми, поэтому было принято решение использовать собственное на базе Debian Linux. Опытом его поднятия я хочу поделиться с вами в этом посте, но приведенные здесь версии могли немного устареть с момента написания мануала «для себя», так что нужно проявить некоторую внимательность. Также, нужно учитывать, что приведенное решение далеко от идеального и профессионального. Оно поможет скорее тем, кому нужно быстро поднять у себя сервер, раздающий интернет. В конце у нас будет раздача интернета через PPPoE с назначением внутренних IP клиентам, шейпинг трафика, DNS сервер и простой мониторинг текущих сессий из консоли.

Вступление

В статье будет рассказано о том, как в кратчайшие сроки познакомиться с основами скриптинга в GIMP на языке Scheme и приступить непосредственно к решению простых практических задач. Данный материал предназначен лишь для тех, кто собирается автоматизировать рутинную обработку здесь и сейчас, не сильно вдаваясь в тонкости и не жертвуя драгоценным временем. Также, статью не рекомендуется использовать в качестве пособия по Scheme отдельно от Script-fu. Связано это с упрощённым стилем программирования в данном материале и отсутствием освещения других немаловажных фактов, которые нас сейчас волнуют гораздо меньше, чем скорость освоения.

Содержание:

1. Что нам понадобится?
2. Коротко о синтаксисе
3. Переменные
4. Функции
5. Списки
6. Регистрация скрипта в GIMP
7. Написание кода
8. Заключение

Здравствуй, Хабр! Думаю, люди, которые следят за моим творчеством, заметили, что я очень увлекся рисованием на Canvas в JavaScript. Возможно это немного излишне, но ничего не могу с собой поделать, уж очень нравится эта технология. Так нравится, что я аж буду выступать на конференции с докладом о ней (Пономаренко Павел).

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