Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

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

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

Обычно люди сходу начинают предлагать готовые реализации кеша, вроде memcached или HTTP-кеша, но это лишь ответ на вопрос где кешировать.

Кеширование – одна из многих тем, наряду с безопасностью и логированием, о которых знают и говорят все, но мало кто может это сделать правильно.

В этом топике уже поднимался вопрос о кодировках сервисов Google. Однако там речь шла о некорректности текстов соглашений. Я же в одном из своих проектов столкнулся с проблемами кодировок при работе с одним из API Google. Пикантность ситуации в том, что проблема возникла при работе с недокументированным API, и «палиться» в службе поддержки очень не хотелось. Поиск в сети решений не дал (варианты с «повторять пока не заработает» не принимались как серьезные). Как же мне удалось найти выход и решить всё самому?

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

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

Я довольно быстро доказал, что вероятность этого события равна нулю. Гордый собой, я запостил решение и ответ, ожидая плюсика в карму. Оказалось, однако, что авторский ответ совсем другой: 1 — 1/e. Забегая вперёд, скажу, что этот ответ неверен.

Неправильные авторские решения — довольно частое явление в интернет-головоломках. И я ни за что не стал бы писать этот пост, если бы автором задачи, а также её неверного решения, не был британский логик и алгебраист Чарльз Л. Доджсон, более известный под псевдонимом Льюис Кэрролл.

Добрый день, жители хабра! Я занимаюсь фрилансом (хотя это слово не очень люблю) на протяжении последних четырёх лет. В этом небольшом топике мне хотелось бы рассказать о различных способах вывода заработанных непосильным трудом денежных средств. Для начала стоит сказать о том, как именно организована моя работа. Я использую всего два варианта – oDesk и работа напрямую. С клиентами из России работать ещё не доводилось, так что о таких знакомых вариантах вывода денег, как WebMoney и Яндекс.Деньги речь идти не будет.

Приветствую!

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

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

Три года назад, когда я работал веб-разработчиком на YouTube, один из старших инженеров начал разглагольствовать о слишком большом весе видеостраницы. Страница была раздута до 1,2MB и содержала десятки запросов. Этот инженер так и заявил: если целые клоны Quake пишутся с объемом до 100KB, у нас просто нет оправданий! Я согласился с ним и был в восторге от нового проекта, решив сделать страницу просмотра YouTube с весом ниже 100 КВ. В этот вечер, в автобусе, едущем из Сан-Бруно, я написал код прототипа. Я решил ограничить функциональность базовым минимумом: видеоплеер, пять похожих видео, кнопка «Поделиться», инструмент разметки и десять комментариев, загружаемых с помощью AJAX. Я назвал проект “Feather” (англ. — перышко).

Даже при таком ограниченном наборе функций страница весила около 250 КБ. Я углубился в изучение кода и понял, что наше средство оптимизации (т.е. Closure compilation) не способно исключить код, который никогда реально не используется на самой странице (чего и следовало ожидать от любого инструмента в сложившихся обстоятельствах). Единственным способом дополнительно сократить код было вручную оптимизировать спрайты CSS, Javascript и изображения. Три дня стараний — и я получил гораздо более удачное решение. И все равно это было не 100 КБ. Я совсем недавно закончил написание кода видеоплеера HTML5, и поэтому решил включить его вместо гораздо более увесистого Flash player. Бамс! 98KB, и всего 14 запросов. Я снабдил код некоторыми базовыми возможностями мониторинга и запустил его исполнение в части нашего трафика.

Предыстория

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

(слева — у обычных пользователей, справа — у гневного)

ХО-ХО-ХО! Праздник к нам приходит! Всегда coca-co… HTML5!
Выпал снежок и как-то незаметно пришло праздничное, предновогоднее настроение. Чтобы как-то поддержать праздничный дух, мы решили сделать небольшой сюрприз от издательства и порадовать наших читателей бесплатной электронной книгой Марка Пилгрима «HTML5. Руководство разработчика» (DIVE INTO HTML5). Оригинал книги также есть в бесплатном варианте в Интернете.

Прежде чем скачать книгу целиком, предлагаем вам познакомиться с первой главой:

Глава 1. Как мы сюда попали?

Приступим

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

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

Пока я буду рассказывать, как появился HTML5, помните эти слова.

Что может быть лучшим подарком на день знаний для программиста? Конечно, полезная книга ;) Поэтому команда переводчиков «Pro Git» поднапряглась и доделала перевод книги на русский язык.

«Pro Git» — это довольно обширная обучающая книга о Git от Скотта Шакона — активного участника разработки проектов Git и GitHub. Автор рассматривает в тексте всевозможные аспекты работы с Git'ом, начиная с установки программы и базовых принципов работы децентрализованных систем контроля версий, и заканчивая рассмотрением внутреннего устройства Git'а и созданием валидных объектов в базе Git'а собственными руками. Несмотря на довольно обширный материал и затрагивание довольно специфических тем, книга написана довольно простым языком, содержит массу примеров и иллюстраций, и поэтому должна быть понятна и новичкам, только начинающим знакомиться с системами контроля версий.

Последняя версия перевода книги доступна в форматах pdf, epub, mobi.
Также доступна онлайн-версия перевода, но она, к сожалению, не обновлялась с мая.

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

Потребовалось мне вывести деньги с PayPal в России, только вот через посредников работать не хотелось.
Пришлось получить карту Payoneer для вывода PayPal на эту карту. Сколько не искал, так и не нашел полноценной, пошаговой инструкции.
Поэтому пишу сам.



ВНИМАНИЕ! Все ниженаписанное является де-юре нарушением законодательства РФ и Украины, и вообще выдумкой автора и плодом работы в фотошопе. Применяя описанное на практике, вы действуете на свой страх и риск, и ни автор, на администрация сайта не несет ответственности за ваши действия.

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

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

Оглавление:

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

«Воровство доменов», а точнее, несанкционировнные смены NS-серверов, неправильные регистрации реселлерами, просто ошибки при регистрации — продолжаются. Тема не новая, но, как показывает практика — год из года не теряет своей актуальности.
Постарался собрать в одном месте все советы по правильной регистрации доменов. Заодно — вспомнил несколько мифов о доменах.
Даже если Вы знаете о доменах больше меня, пожалуйста, посмотрите статью — сделаем вместе «Наиболее полное руководство», статья ориентирована на новичков.
Где и как регистрировать домены? Что делать, если домен уже зарегистрирован, но есть сомнения в правильсти его регистрации?

TryGit — интерактивный обучающий курс по Github в стиле Codecademy. Курс состоит из 25 мини-уроков, которые знакомят пользователя с базовыми понятиями и основными командами git, при этом ученик своими руками вводит команды в консоль, смотрит результат и читает сопровождающие надписи с объяснением происходящего.



Вот таким в будущем должно стать обучение в школах!

Конечно, 15-минутное введение не заменит полноценного учебника. Для обучения можно рекомендовать бесплатную книгу Pro Git и видеокурс Getting Git.

Не знаю, как вы, уважаемый читатель, а я всегда поражался контрасту между изяществом базовой идеи, заложенной в концепцию двоичных деревьев поиска, и сложностью реализации сбалансированных двоичных деревьев поиска (красно-черные деревья, АВЛ-деревья, декартовы деревья). Недавно, перелистывая в очередной раз Седжвика [1], нашел описание рандомизированных деревьев поиска (нашлась и оригинальная работа [2]) — настолько простое, что занимает оно всего треть страницы (вставка узлов, еще страница — удаление узлов). Кроме того, при ближайшем рассмотрении обнаружился дополнительный бонус в виде очень красивой реализации операции удаления узлов из дерева поиска. Далее вы найдете описание (с цветными картинками) рандомизированных деревьев поиска, реализация на С++, а также результаты небольшого авторского исследования сбалансированности описываемых деревьев.

Краткое введение

В наши дни все понимают насколько простой задачей является угон незащищенной http сессии.
И останавливать от повсеместного внедрения может только цена на покупку сертификата, www.startssl.com решает эту проблему, раздавая бесплатные сертификаты (Class 1). Verified (Class 2) стоят копейки.

Правило №1. Делайте все авторизационные куки HttpOnly

Куки с флагом HttpOnly не видны браузерному коду, а отправляются только на сервер. На практике у вас почти никогда нет необходимости получать их содержимое со стороны клиента (если такая необходимость почему-то у вас возникла — пересмотрите архитектуру авторизации, скорее всего, там что-то не так). А вот злоумышленнику, нашедшему XSS — а XSS так или иначе когда-нибудь где-нибудь найдется — отсутствие HttpOnly на авторизационных куках доставит много радости.

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

К сожалению, большинство инструментов, которые применяются для вычислений, будут прятать результат, но если вы найдете такой, который этого (1/998001=1.002003004005006e-06) не делает, то, может, не сразу заметно, но деление 1 на 998001 дает в результате все числа от 001 до 999.

Если вам интересна такого рода математика, то 1/9801 выдаст похожий результат, последовательность чисел от 01 до 99

Можно посмотреть в WolframAlpha. Нажимайте «More digits» в блоке «Decimal approximation»:
www.wolframalpha.com/input/?i=1%2F998001
www.wolframalpha.com/input/?i=1%2F9801

Заведя для себя «почту для домена» на Яндексе, я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции catch-all, которая направляет всю входящую почту несуществующих ящиков моего домена на мой основной ящик, предо мной встала необходимость зарезервировать за собой все «стандартные» названия ящиков, чтобы не было недоразумений, когда какое-то имя уже забил посторонний, и вся «служебная» почта уходит совсем не вам. В П.Д.Д. можно, конечно, в любой момент экспроприировать любой ящик подконтрольного домена, но ведь осадочек-то остается. Я озадачился: какие же имена почтовых ящиков являются стандартными и системными? Техподдержка Яндекса ответила, что они резервируют для себя только имя postmaster@ на каждом домене, чтобы отслеживать жалобы и проблемы с почтой, и что на данный момент вопрос о наборе резервированных имен у них остается открытым. Далее, результат поиска в интернете оказался немного предсказуем.