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

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

Практически все Javascript-программисты пользуются консолью в браузерах. Консоль встроена в Хром, Оперу, IE и устанавливается с Firebug в Фоксе.
Но у неё есть пару неудобств, которые можно очень легко исправить. Это:

• Ошибки, когда консоль не определена
• Невозможность использовать вне контекста
• Невозможность отключить во время production
• некроссбраузерность

Исправим эти проблемы легко и быстро!

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

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

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

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

В конце — суммация книг, которые хабровчане рекомендуют в комментариях помимо основного списка.

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

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

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

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Когда количество машин, на которые я постоянно заходил по ssh достигло 3х, я понял, что просто быстрой авторизации мне мало, и пора перетащить bash-алиасы, конфиги к редактору и прочие элементы окружения на удаленные системы. С другой стороны, нужен был способ не путаться в многочисленных вкладочках с терминалами. В итоге я пришел к связке из scp, screen и цветовой дифференциации хостов :)
Скриншоты результатов:
Домашняя система:

Одна из удаленных машин:

Команда для синхронизации профиля:
$ profsync
Подробности под катом.

Disclaimer
Этот пост появился здесь по нескольким причинам:
1) Меня попросил сам Boomburum
2) Есть предположение, что на хабре всё-таки есть люди, имеющие прямое отношение к IT, но при этом имеющие весьма отдалённое представление о пользе SSH и её извлечении из обычного домашнего роутера, и которым, надеюсь, будет весьма интересно и полезно об этом узнать.

Хабралюдям, познавшим Дао IOS, tun, VPN, *wrt, WOL… etc, предлагается на выбор:
А) Закрыть топик, заняться делом и не выводить себя из нирваны чтением этой любительской фигни.
Б) Потратить время на конструктивную критику и полезные дополнения в комментариях.
Специально для GrammarNazi:
Пишите пожалуйста об ошибках в личку — обещаю исправиться.

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

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

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

Устанавливал я Ubuntu 10.10 на ноутбук Acer Aspire Timeline 5810TG. Эта машина обладает экраном в почти 16 дюймов и относительно производительным железом, зато батарея достаточно емкая, чтобы ставить с ней личные рекорды.

Доступность контента и отображение информации на сайте чрезвычайно важна. Говоря простым языком, что хорошего может сделать то, что находится у вас на сайте, если определенные люди не смогут увидеть это? Конечно, этот новый модный дизайн с мелким шрифтом и малоконтрастными цветами для вас и ваших друзей выглядит классно, но вот что насчет тех, у кого слабое зрение, или тех, кто не различает некоторые цвета, или тех, у кого какие-либо другие проблемы со зрением — они ведь просто не смогут ничего найти, не говоря уже о том, чтобы прочитать хоть что-нибудь на вашем сайте. Вам надо, даже не «надо», а вы ДОЛЖНЫ сделать свой сайт доступным для как можно большего числа посетителей.

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

Договоры, отчеты, акты — кому охота заниматься этой скукотой, когда вокруг бьет ключом и фонтанирует идеями креативная жизнь? Особенно, если заказчик снисходительно хлопает творческого подрядчика по плечу: «Да ладно, зачем какие-то договоры. Мое слово — закон!» Остается только радостно согласиться и приступить к работе.

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

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

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

Точек зрения на то, каким должен быть сайт, много: у программиста одна, у дизайнера – другая, у интернет-маркетолога – третья, у владельца…

На самом деле, точка зрения – всего одна – у конечного пользователя ресурса. И именно это в первую очередь нужно учитывать. Естественно, принимая во внимание удобство обслуживания сайта администратором.

В чем преимущества грамотно написанного технического задания:

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

^{Illustration by Kevin Cornell}

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

На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.

Что такое OAuth 2.0

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

Жизнь была прекрасна и все было в этом мире хорошо, пока почта с моего сайта не стала активно посылаться в спам практически всеми крупными почтовыми серверами. Особенно усердствовал в этом Gmail. Частенько меня принимали за спамера в Yandex, реже в mail.ru и rambler.

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

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

Как часто программист сталкивается с вопросом выбора целевой аудитории? Я, если честно, не могу особенно назвать себя программистом, но с этим связан очень тесно. Я заказчик, и по сути менеджер проектов. Как правило, этот вопрос возникает в момент, когда проектируешь новое приложение. Будь это модуль для 1С, веб сайт или приложение для iPhone – задача очевидна. Необходимо чтобы пользователю было удобно.
Как правило мы примеряем всё под себя – если мне понятно, мне удобно, значит и пользователю будет удобно. И на практике сталкиваемся с «нормальной» ситуацией, когда пользователь не может найти кнопку или функцию, которая для Вас, находится в очевидном месте. Итак давайте разберемся, откуда возникают такие недоразумения?

Вы 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 на сайте.

Натолкнулся в разделе QA на интересный вопрос. Ответ на него заставил написать эту статью как бОлее полный ответ на вопрос «как организовать поиск по множеству параметров, как в Яндекс-маркете, например».

Я знаю, что на Хабре, да и вообще есть много сторонников noSQL решений (сам не без греха), но все же я сторонник сначала подумать, а уже потом выбирать решение.

Итак, что имеем в «ДАНО»

• Имеем 120 чекбоксов — вариант 1/0
• Имеем 30 «радио» с выбором «да/нет/не важно»
• Имеем 2-3 слайдера для указания диапазона цен/размера чего нить
• Имеем самое главное: 12 млн записей в БД.
• Имеем Select * From tovar Where (wifi=true) and (led=false) and (type=3) and ….остальные параметры …; со временем выполнения близкому к истерике клиента.