Статья написана после прочтения статьи Копи деньги смолоду или пара утверждений, легко проверяемых в Excel.

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

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

Зачем?

Вообще, идея этого поста пришла мне в голову в тот самый момент, когда я, не имея до этого за плечами полноценного опыта фриланса, решил всерьез освоить oDesk. Да, если кто не знает, oDesk — это одна из крупнейших в мире фриланс-бирж. Итак, дело было в июле этого года. Официальной работы к тому времени у меня уже полгода как не было, все подработки закончились, новых серьезных заказов не предвиделось, и oDesk представлялся мне весьма перспективным вариантом. Аккаунт, как водится, был зарегистрирован «про запас» еще за год до того, но висел все это время без дела, поэтому начинать нужно было с нуля. При этом я был почти уверен, что руководство, хотя бы самое краткое, на тему, как и с чего начинать, я где-нибудь (уж на Хабре-то точно!) да найду.
Возможно, я плохо искал. Однако все, что мне попалось по теме, сводилось только к тому, что не нужно сразу загибать цены, лучше начинать с небольших. Примерная цитата: «начинайте с $10 в час, со временем, дорастете и до $15». Дорастать до $15, да еще и со временем, мне категорически не хотелось, я был уверен, что можно зарабатывать значительно больше. Да и кроме того, меня волновало огромное количество вопросов. Как заполнять профиль? На какие проекты откликаться? Как составлять cover letter? Как, черт побери, получить этот первый заказ, когда все тебе отказывают?
В тот момент я решил, что если все у меня получится, обязательно напишу то самое руководство для новичков, которого я не нашел.

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

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

Предлагаю ознакомиться с принципом работы алгоритма Диффи – Хеллмана в замечательном видео от Art of the Problem в моем переводе.

Google представили выпуск open-source проекта J2Objc, собственный конвертер из исходного кода на Java в Objective-C для приложений на iPhone/iPad.

На Хабре присутствует довольно много бизнесменов, еще больше фрилансеров и работающих по найму.

Большинство из нас (уж я-то точно!) попалось в ловушку жизненной колеи, утверждённой социумом, как стандарт: школа => институт => работа по найму. Кто-то сразу подался во фриланс или бизнес.

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

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

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

Оригинальная статья Джона Грэхем-Камминга.
Переведено и опубликовано с разрешения автора.

Я занимаюсь программированием уже более 30 лет, начиная с машин, уже устаревших (на процессорах Z80 и 6502) до современных, используя языки BASIC, ассемблера, C, C++, Tcl, Perl, Lisp, ML, occam, arc, Ruby, Go и многие другие.

Далее следует список того, чему я научился.

Если в одном из моих прошлых постов речь шла о довольно современном подходе к построению сбалансированных деревьев поиска, то этот пост посвящен реализации АВЛ-деревьев — наверное, самого первого вида сбалансированных двоичных деревьев поиска, придуманных еще в 1962 году нашими (тогда советскими) учеными Адельсон-Вельским и Ландисом. В сети можно найти много реализаций АВЛ-деревьев (например, тут), но все, что лично я видел, не внушает особенного оптимизма, особенно, если пытаешься разобраться во всем с нуля. Везде утверждается, что АВЛ-деревья проще красно-черных деревьев, но глядя на прилагаемый к этому код, начинаешь сомневаться в данном утверждении. Собственно, желание объяснить на пальцах, как устроены АВЛ-деревья, и послужило мотивацией к написанию данного поста. Изложение иллюстрируется кодом на С++.

В этом посте рассказывается о созданной в форме кикстартеровского проекта системе мониторинга качества московского воздуха vozduh.msk.ru. Сначала будет несколько слов о том, почему воздух интересно мониторить и почему для этого недостаточно существующих систем. Потом будет рассказ о сборе средств на проект (с цифрами). Потом будет рассказ об архитектуре системы, её характеристиках, сильных сторонах и ограничениях.

От берёзы до arduino

26 апреля 2012 года Москву накрыло плотное желто-зелёное облако. Вместе с облаком поползли слухи о каком-то якобы взорвавшемся заводе по производству удобрений. Но скоро стало ясно, что для конспирологии места нет: этой весной случилось уникально бурное цветение берёзы. Зелёное облако состояло из пыльцы. Друзья-аллергики сидели дома, плотно закрыв створки стеклопакетов.

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

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

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

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


Возникла гипотеза: важный вклад в качество воздуха вносит «невидимая» мосэкомониторингом пыль.

UPD. Оригинальная статья достаточно старая — 2010 года. Сейчас ситуация выглядит по-другому.

В декабре 2010 у Reddit-а было 829М просмотров и 119 серверов.
В конце 2011 года — 2,07B просмотров и 240 серверов.

Спасибо potomushto за актуализацию.

UPD 2. Поправил схему для людей с проблемами цветовосприятия. Спасибо second_pilot и spiritedflow

---

Стив Хаффман, один из создателей Reddit, рассказал на презентации, чему они научились, пока строили и развивали Reddit до 7,5 млн пользователей в месяц, 270 миллионов просмотров страниц в месяц и более 20 серверов баз данных.


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


Каждый из 7 уроков будет рассмотрен в соответствующей секции.

• Падайте часто
• Разделение сервисов
• Открытая схема данных
• Избегайте хранения состояний
• Memcache
• Сохраняйте избыточные данные
• Выполняйте максимум работы в фоновом режиме

Написать этот пост меня привлекла эта статья. Многие ее помнят по вот этой картинке.

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

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

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

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

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

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

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

Но поскольку вы спросили, вот внутренние реализации каждой структуры данных Redis:

• Строки реализованы с использованием библиотеки динамических строк C, так что мы не платим (говоря асимптотически) за выделение памяти в операциях добавления. Таким образом мы получаем сложность добавления O(N), вместо, например, квадратичной.
• Списки реализованы как связные списки.
• Множества и Хэши реализованы как хэш-таблицы.
• Упорядоченные множества реализованы как списки с пропусками (особый тип сбалансированных деревьев)

David Drysdale, Beginner's guide to linkers (http://www.lurklurk.org/linkers/linkers.html).

Цель данной статьи — помочь C и C++ программистам понять сущность того, чем занимается компоновщик. За последние несколько лет я объяснил это большому количеству коллег и наконец решил, что настало время перенести этот материал на бумагу, чтоб он стал более доступным (и чтоб мне не пришлось объяснять его снова). [Обновление в марте 2009: добавлена дополнительная информация об особенностях компоновки в Windows, а также более подробно расписано правило одного определения (one-definition rule).

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

g++ -o test1 test1a.o test1b.o
test1a.o(.text+0x18): In function `main':
: undefined reference to `findmax(int, int)'
collect2: ld returned 1 exit status

Если Ваша реакция — 'наверняка забыл extern «C»', то Вы скорее всего знаете всё, что приведено в этой статье.

Как следует из официального блога Metasploit, последний апдейт данного продукта имеет в своём арсенале эксплоит под уязвимость нулевого дня (0day) для Java run-time environments (JRE).

Эксплоит кросплатформенный и был успешно протестирован на следующих платформах:

• Windows 7 SP1 с установленной Java 7 Update 6
• Mozilla Firefox под Ubuntu Linux 10.04
• Internet Explorer / Mozilla Firefox / Chrome on Windows XP
• Internet Explorer / Mozilla Firefox on Windows Vista
• Internet Explorer / Mozilla Firefox on Windows 7
• Safar под OS X 10.7.4

UPD_2
Как сообщается, уязвимости подвержены следующие продукты:

JDK и JRE 7 Update 6 и более ранние
JDK и JRE 6 Update 34 и более ранние
end of UPD_2

Как можно догадаться, раз это 0day, то на настоящий момент патча не существуетОбновление Java 7 update 7 устраняет уязвимость (спасибо Gregy за наводку). Уязвимости также пока что не присвоен номер CVE. Уязвимости присвоен CVE-2012-4681

Привет, Хабр!
Не так давно здесь прогремела статья об Arduino, породившая холивар в комментариях. Многие сторонники Ардуины, по их словам, хотят просто чего-то собрать типа мигающих светодиодов с целью разнообразить свой досуг и поиграться. При этом они не хотят возиться с травлением плат и пайкой. Как одну из альтернатив товарищ dedsky упомянул конструктор «Знаток», но его возможности ограничены набором деталей, входящих в комплект, да и конструктор все же детский. Я же хочу предложить другую альтернативу — так называемый Breadboard, макетная плата для монтажа без использования пайки.
Осторожно, много фоток.

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

Добрый вечер всем!

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

Я не претендую на истину. Я просто хочу показать простой и быстрый способ создать веб сервис.

Начало

Необходимое ПО

Самое главное это IDE. Я предпочитаю Eclipse. Данный проект я написал в Eclipse for Java EE Developers Juno. Четно говоря, предыдущий релиз был стабильнее, но этот внешне приятнее. В качестве фреймворка для REST я выбрал Jersey. Его легко найти и скачать. Точно так же как и саму IDE. В качестве сервера я установил GlassFish плагин для эклипса. Инструкцию по его установке точно так же легко найти. Ну на этом и всё.

Создание проекта

Итак. У нас есть Eclipse, папка с JAR-файлами Jersey и установленный GlassFish плагин. Теперь запускаем Eclipse и создаем пустой Dynamic Web Project, на последней вкладке не забываем отметить чек-бокс, который отвечает за генерацию web.xml файла.

Канадский разработчик Стив Ханов (Steve Hanov) рассказывает о простом способе повысить эффективность A/B-тестирования.

Суть заключается в использовании жадного алгоритма (epsilon-greedy method) для решения задачи о многоруком бандите. Другими словами, при выборе между вариантами A/B-тестирования Стив предлагает отказаться от полного рандома, а в 90% случаев выбирать лучший вариант по результатам накопленной к настоящему моменту статистики.

Метод прост до гениальности.