Не так давно промелькнула ссылка на достаточно свежее (осень 2011) англоязычное голосование со скромным названием "самая впечатляющая книга, которую должен прочесть каждый разработчик программного обеспечения" и описанием:

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

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

Однако в данном небольшом посте я возьму на себя смелость перечислить ТОП-5 тех самых книг, победивших в голосовании, переведенных на русский язык. И дать небольшие комментарии, ведь книги действительно этого достойны. Да, лично я бы поменял некоторые места, однако положимся на «мнение зала» ресурса Stack Overflow.

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Три недели назад на хабре уже писали о том, что Мильнер и Дуров будут раздавать гранты в размере 25 тысяч долларов, при этом не требуя ничего взамен.
И вот сейчас в группе проекта StartFellows были объявлены 6 стартапов, которые получат этот грант:

vnimanietv.ru — премия в области образовательных видеолекций;

budist.ru — социальный будильник;

sandsign.ru — подписи на песке;

wheely.com — сервис для заказа и отслеживания такси;

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

drugdrugu.ru — социальная сеть, сведение людей по принципу «Я хочу/Я могу».

Сообщается, что было прислано около 2000 писем и не все заявки ещё обработаны.
Судя по первым победителям, предпочтение отдаётся живым проектам.

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

Новый набор метрик доступен в разделе «Технические характеристики» в каждой из вкладок отчета «Скорость загрузки сайта» (Исследование, Эффективность, Наложение данных на карту).

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



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

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

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

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

Мы захотели узнать, почему уходят игроки и можно ли предсказать их уход. Предмет исследования – ММОРПГ Аион, однако наши результаты оказались применимы к широкому кругу игр и онлайн сервисов.

Сегодня попробую осветить денежные вопросы.
Банковский счет, карты, платежи, PayPal и все такое.
Это продолжение топика HOWTO: свой бизнес в США из России, если кто пропустил.

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

    В этой статье я попробую осветить процесс создания и администрирования американской корпорации для резидента РФ. Наверняка многие из фактов для самих американцев покажутся тривиальными, однако для жителя России все куда сложнее — увы, это данность. Чтоб не сказать — это Родина, сынок. Оговорюсь сразу — я все это проделал более 2 лет назад, так что, некоторые детали могут быть не совсем актуальны. Но вряд ли что-то поменялось принципиально.

Представляю вашему вниманию перевод статьи под названием "Site Search: Strategies for No Results Found" от Linda Bustos. Перевели в компании UXDepot специально для пользователей Хабрахабра с одобрением компании Elastic Path.

Эта статья написана по мотивам книги Грега Ньюдельмана "Designing Search: UX Strategies for Ecommerce Success". Необычно видеть книгу на 300 страниц, посвященную одному единственному аспекту создания интернет-магазинов, но оптимизация поиска по сайту действительно заслуживает такого внимания!



Есть одна составляющая оптимизации поиска по сайту, на которой мы часто зацикливаемся: как удержать пользователя на сайте, даже если в результате поиска ему не удалось найти то, что требовалось. Статья основана на разделе "No Search Results Strategy: Not a Zero-Sum Game" вышеупомянутой книги. Ньюдельман говорит о том, что «нет простого набора правил, которые гарантировали бы успешное внедрение страницы результатов поиска в случае, когда не было найдено ни одного совпадения. Но есть четыре принципа, от которых стоит отталкиваться»:

Google первой среди крупных интернет-компаний внедрила на HTTPS-серверах функцию защиты от будущей потери секретного ключа (функция называется perfect forward secrecy или PFS). Для этого разработано open-source дополнение к OpenSSL, в частности, написан быстрый генератор ключей на эллиптических кривых P-224, P-256 и P-521. По ходу работы специалисты Google также исправили несколько багов в OpenSSL.

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

В случае с Google такой вариант не пройдёт. Теперь здесь используются недолговечные («эфемерные») сеансовые ключи, которые обмениваются по схеме ECDHE (аббревиатура ECDHE расшифровывается как «эфемерный алгоритм Диффи-Хеллмана с использованием эллиптических кривых»). После сеанса связи ключи уничтожаются, и даже владелец сервера не сможет расшифровать сессию, которую его сервер зашифровал прошлым ключом.

Вчера, 17 ноября, прошло ежегодное вручение наград лучшим стартапам, The Europas. Выбор по 22 номинациям осуществлялся как на основе голосования экспертов, так и по результатам 40,000 голосов посетителей сайта theeuropas.com.

Эта статья — перевод статьи из блога www.swarmonline.com с небольшими моими дополнениями

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

В этой статье мы собрали список некоторых из вещей, которые рекомендуем вам делать, когда вы начинаете работать с Ext JS (даже, если вы ветеран разработки, всё равно можете узнать что то новое!). Эти вещи прошли через наш опыт, через просмотр и ответы на одни и те же вопросы на форумах. Это наиболее общие из лучших техник программирования.

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

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

1. Почему стоит начать работать «в белую»
2. Почему на начальном этапе ИП лучше ООО
3. Что делать, если партнёров несколько

Если вы – начинающий или уже опытный фрилансер и подумываете о работе «в белую», но ещё точно не определились с вопросами «Стоит ли оно того?» и «ИП или ООО?», вэлком

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

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

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

UPD: Как показала практика, необходимо ощутимое измение и дополние в тексте. Я решил внести лишь незначительные правки в основную часть, а новыми выводами поделиться в конце статьи.

Прочитайте пару объявлений об открытых вакансиях в геймдеве, и Вы увидите, что в большинстве из них наниматель ищет людей со страстью к компьютерным играм. Это звучит очень заманчиво, романтично и оптимистично. Объявления рассказывают, как много всего интересного делается в компании, как увлечены играми её работники — и вот они ищут себе таких же коллег. «Вау!» — говорит себе молодой наивный читатель — «У меня огромная страсть к играм! Эта работа для меня!»

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

Кто не в курсе, это выглядит так:
Линейная алгебра для разработчиков игр / 71 комментарий / 6 новых
История взлома одной браузерной игры. Возврат контроля / 32 комментария / 2 новых
Список ресурсов для изучения Ассемблера / 55 комментариев / 14 новых

Т. е. это такой список топиков, где вы писали комментарий [или подписались вручную].

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

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

Представляем вашему вниманию PHP-библиотеку для использования нашего API.

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

Плюсы и возможности:

• OAuth-авторизация пользователя;
• безопасность работы (поддерживается проверка цепочки сертификатов);
• удобство работы (response'ы сервера представлены в виде объектов) и быстрый старт;
• относительно безопасное и простое решение хранения токенов пользователей с использованием шифрования и без использования БД. Реализацию этого решения вы сможете легко переписать под свои хранилища.

Скачать библиотеку можно отсюда.

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

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

Мне давно хотелось попробовать что-нибудь новенькое, и вот, когда на работе предложили написать примеры использования API Яндекс.Денег на разных языках, я с удовольствием принял это предложение-challenge. Так как чаще всего подобный функционал используют в приложениях на различных хостингах, то было принято волевое решение первым делом попробовать написать сие на PHP. Причем API до этого я даже не видел; более того, никакого опыта работы с PHP, кроме как лабораторной в ВУЗе, у меня не было. Дело обещало быть интересным.