Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.

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

Документальный фильм про Стива Джобса и его стартап, компанию NEXT, которую он основал после ухода из Apple. Фильм снят в 1986 году. Перевод на русский язык — канал GTV.



Приятного всем просмотра!

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

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

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

Я сам долгое время считал, что создание компиляторов — это удел элиты, а простому смертному программисту не постичь этой науки. Попробую доказать, что это не так.

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

Введение

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

Вступление

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

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

Эта статья во многом повторяет (в том числе заимствует иллюстрации) раздел из английской Haskell Wikibook, но тем не менее не является непосредственным переводом.

Что такое категория?

Примеры

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

Красные кружочки изображают «объекты», а стрелки – «морфизмы».

Я хочу привести один наглядный пример из реальной жизни, который даст какое-то интуитивное представление о природе объектов и морфизмов:

Можно считать города «объектами», а перемещения между городами – «морфизмами». Например, можно представить себе карту авиарейсов (как-то не нашёл я удачную картинку) или карту железных дорог – они будут похожи на картинки выше, только сложнее. Следует обратить внимание на два момента, которые кажутся в реальности само собой разумеющимися, но для дальнейшего имеют важное значение:

• Бывает, что из одного города в другой никак не попасть поездом или самолётом – между этими городами нет морфизмов.
• Если мы перемещаемся в пределах одного и того же города, то это тоже морфизм – мы как бы путешествуем из города в него же.
• Если из Санкт-Петербурга есть поезд до Москвы, а из Москвы есть авиарейс в Амстердам, то мы можем купить билет на поезд и билет на самолёт, “скомбинировать” их и таким образом попасть из Санкт-Петербурга в Амстердам – то есть можно на нашей карте нарисовать стрелку от Санкт-Петербурга до Амстердама изображающую этот скомбинированный морфизм.

Надеюсь, с этим примером всё понятно. А теперь немного формализма для чёткости.

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

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

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

Одним из безусловно удобных способов получать новости, статьи и т.п. с различных сайтов — является RSS. Однако с каждым годом число лент неуклонно возрастает, кол-во фидов увеличивается, а времени на разгребание всего этого хозяйства становится все меньше и меньше. Очевидно — нужно как-то автоматически фильтровать статьи. Этим мы сегодня и займемся.

Некоторое время назад у меня дошли руки до темы, которая давно уже меня нервирует интересует. Эта тема — наследование в JavaScript.

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

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

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

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

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

Данную статью хочу приурочить к одновременно выходу второй версии моего приложения Word Wizard и взятию новой отметки в $200 000 в Apple AppStore. Далее я постараюсь поделиться своим опытом и мыслями об образовательном рынке, а также рассказать свою историю успеха. Надеюсь что эта информация будет полезна многим независимым разработчикам. Для тех же кто создает образовательные продукты на платформе iOS моя статья даст возможность оценить рынок приложений в этой сфере.



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

Математик Скотт Рикард (Scott Rickard) попробовал сделать то, что ни один музыкант никогда не пытался, а именно — сочинить самую противную мелодию. Таким способом учёный хотел проиллюстрировать тезис, что гармония музыки заключается в математических паттернах, то есть в повторах.

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

По мотивам За что я люблю Drupal.
Опубликовано по просьбе JiLiZART (перевод, как я понял, тоже его).
Оригинал: erickennedy.org.

Недавно на Хабре уже проскакивал сайт по подбору кино, когда хочется что-то посмотреть, но не знаешь что именно. Предлагаю вам оценить ещё один — CiEx.ru.

В вашей системе время играет важную роль? Ваши пользователи/компоненты распределены по территории всего земного шара, или хотя бы нашей необъятной родины? Значит, вам нужны часовые пояса. Что ж, это просто. Самое сложное, что вам придется сделать — не запутаться. Об этом мы с вами и поговорим. Для начала вам нужно научиться правильно думать. Думая правильно, все остальное будет для вас либо самоочевидным, либо достаточно простым.

Начнем с часов. Все мы привыкли определять время, глядя на часы на стене. При работе с часовыми поясами такое время называется Wall clock time. В принципе, ничего плохого в нем нет, только в разных местах земного шара в один и тот же момент времени часы показывают разное время. Если задаться целью, можно придумать алгоритм перевода wall clock time одного часового пояса в wall clock time другого. Обычно надо прибавить/отнять разницу в часах между часовыми поясами, кроме (внимание) моментов перехода на летнее/зимнее время. Вот когда начинается переход, вычисления становятся по-настоящему сложными.

Нам же нужно что-то простое и пуленепробиваемое, как… целое число.

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

О чем эта статья?

Эта статья о том:

1. Что такое релиз?
2. Как нумеруются релизы?
3. Зачем при релизе нужен бранч?
4. Почему релиз это больше, чем просто jar (war, ear, zip, etc)?
5. Что такое maven-release-plugin?
6. Делаем бранч c помощью release:branch.
7. Подготовка к релизу с помощью release:prepare.
8. Выпускаем релиз с помощью release:perform.

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

Этот текст является вольным переводом замечательного поста Kaushik Sathupadi на тему распределённых систем и существующих ограничений при их создании.

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

Часть №1: Идея нового сервиса — «Позвони, напомню!»

Вчера, когда ваша супруга в очередной раз оценила тот факт, что вы вспомнили о её дне рождения и подарили шикарный подарок, в голове всплыла забавная идея. «Хм, а ведь люди вечно всё забывают». А у вас просто блестящая память! Почему бы не сделать новый сервис, который позволит полностью раскрыться вашему таланту? С каждой мыслью об этой идее вам всё больше и больше она нравится. Вы уже даже придумали рекламу, которую можно было бы напечатать в газете:

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

Типичное обращение в ваш сервис выглядело бы вот так:

    Как известно недавнее обновление продуктов Adobe Flash Player до 10.1 и Adobe AIR до 1.5 версий осуществило целый фурор, презентовав новый протокол связи Real-Time Media Flow Protocol (RTMFP). Заранее попрошу не путать вышеупомянутый с Real-Time Messaging Protocol (RTMP) для использования которого был необходим Adobe Flash Media Server (FMS) на стороне обслуживающего сервера.
    Разработчики обещают, что протокол будет обладать низкой задержкой во времени при пересылке пакетов, но самое главное, протокол ориентирован на организацию пиринговой сети.