Агентство национальной безопасности США рассекретило изумительные письма, которые знаменитый математик Джон Нэш отправил им в 1955 году.

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

Отсканированные копии рукописных писем Джона Нэша

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

Доброго времени суток!

Недавно, начав изучать Haskell, несколько раз пытался подступиться к монадам, но всё никик не мог, что назывется, нить ухватить (м.б. дело в нехватке базовых знаний). Помогла замечательная книга Learn you a Haskell for great Good.
Начитался, проникся, решил донести до коллег/друзей. Разрабатываем на Python, казалось бы, незачем сильно вникать во «всю эту функциональщину», по крайней мере дальше filter/map/reduce. Но расширение кругозора, штука, бесспорно, полезная, поэтому я решил реализовать пару монад на Python, да так чтобы это не вылилось в полный unpythonic. Конечно же, не я первый и не я последний, было и есть несколько реализаций монад на основе Python, но все те реализации, что встречались мне, либо полностью unpythonic, либо сложны для понимания далёкому от самой концепции человеку. Пришлось изобретать свой велосипед, который, впрочем, позволяет ухватить суть…

Протокол RDP является протоколом прикладного уровня и поэтому для его защиты идеально подходит TLS, который работает над транспортным уровнем.

В данном топике с помощью open source приложений OpenSSL и sTunnel мы защитим RDP-соединения по протоколу TLS c поддержкой российских шифрсьютов (GOST2001-GOST89-GOST89), клиентская аутентификация по ГОСТ-вым сертификатам будет проводиться аппаратно на борту USB-токена Рутокен ЭЦП с выработкой ключа согласования по схеме VKO GOST 34-10.2001. При этом ключ аутентификации является неизвлекаемым и его невозможно украсть. Так же Рутокен ЭЦП будет использоваться в качестве аппаратного ДСЧ.

Для случая аутентификации на терминальном сервере об Active Directory по сертификатам RSA мы обернем TLS по RSA в TLS по ГОСТ. Таким образом, мы получим двухуровневый TLS — RSA с клиентской аутентификацией будет идти внутри канала, защищенного ГОСТами.

Предистория

Я прочитал эту статью о паттерне проектирования «Мост». Увы, его очень часто используют неверно. Более того, я затем открыл книгу Приемы объектно-ориентированного проектирования. Паттерны проектирования. Оказалось — и там авторы очень смутно декларируют причины его наличия и когда его использовать. Поэтому ниже я вам сообщу, как и зачем подобное использовать.

Обновление

Это поверхностная статья, которую можно не совсем точно трактовать. Но её достоинство, что она короткая и вводит в проблематику. У специалистов она может вызвать вопросы более глубокого содержания, а у молодых разработчиков некоторые недоразумения, т.к. я спорю по сути с «Бандой четырех», но полностью согласен с Фаулером и его подходом к рефакторингу (да и у них между собой есть противоречия) — но типа а кто я такой, чтобы спорить.

Я готовлю расширенную статью для специалистов, но она может быть полезна и молодым разработчикам механистически выучившим паттерны проектирования. Они не очень хорошо понимают когда их использовать, а специалистам думаю будет важно аргументация в смысле, что из паттернов предпочесть. Эта расширенная статья надеюсь пояснит почему надо избавляться от паттерна «Мост», а также использовать паттерн Посредник в ограниченном смысле.

Уже есть ответвление этой статьи Правильное использование паттерна «Мост» (Мост с двухсторонним движением) или MVC->«Бизнес-сущность — Визуализация — Контроллер». Где показано, что Мост/Посредник можно использовать в некой комбинации при разделении визуализации и бизнес-логики, но это практически единственная сфера для этих шаблонов. В чистой бизнес-логике и низкоуровневых/системных задачах этих паттернов следует избегать.

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

Что такое паттерн проектирования «Мост» на самом деле

Если Вы знаете объектно-ориентированное программирование, то со всей ответственностью заявляю, что знать о паттернах совершенно не обязательно. Паттерны — это лишь частное и не всегда самое удачное решение на базе ООП принципов.

Посмотрим, что такое паттерн «Мост», что кроется за этим заумным термином. Это не что иное как комбинация применения наследования и агрегации. Увы, часто не знают, что такое агрегация. По- простому, это когда один объект включается в другой.

Эта статья нацелена на читателей, которые начинают или только хотят начать заниматься программированием модулей ядра Linux и сетевых приложений. А также может помочь разобраться с прозрачным проксированием HTTPS трафика.

Небольшое оглавление, чтобы Вы могли оценить, стоит ли читать дальше:

1. Как работает прокси сервер. Постановка задачи.
2. Клиент – серверное приложение с использованием неблокирующих сокетов.
3. Написание модуля ядра с использованием библиотеки Netfilter.
4. Взаимодействие с модулем ядра из пользовательского пространства (Netlink)

P.S. Для тех, кому только хочется посмотреть на прозрачный прокси-сервер для HTTP и HTTPS, достаточно настроить прозрачный прокси-сервер для HTTP, например, Squid с transparent портом 3128, и скачать архив с исходниками Shifter. Скомпилировать (make) и, после удачной компиляции, выполнить ./Start с правами root. При необходимости можно поправить настройки в shifter.h до компиляции.

Всем привет! Хабраюзеры, которые увлекаются фотографией, наверняка слышали о таком интересном приеме, как Tilt Shift (Тилт-шифт). Это уникальный стиль фотосъемки, при котором предмет или место снято в натуральную величину, но выглядит как миниатюрная модель. Изначально такой эффект можно было достичь при помощи специальных объективов или переходников. Так вот, буквально в начале этой недели в Рунете появился новый проект от компании Artensoft – компьютерная программа для создания tilt-shift фотографии из любого фотоснимка без применения оптики – Tilt Shift Generator. У этой программы есть свои уникальные фишки, о которых я расскажу в этом небольшом обзоре.

Прошла неделя с момента пиара на хабре моего проекта «Что делать?». Я напомню, что этот проект начинался, как эксперимент по разработке среднестатистического WEB-проекта целиком на JavaScript (Node.JS). Сейчас я хочу поделиться с сообществом результатами этого эксперимента, полученным полезным опытом, а также подробной картой с отмеченными на ней граблями.

Эпизод 1: начало пути

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

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

Почему же для устранения смаза и расфокусировки практически ничего нету (unsharp mask не в счет) – может быть это в принципе невозможно? На самом деле возможно – соответствующий математический аппарат начал разрабатываться примерно 70 лет назад, но, как и для многих других алгоритмов обработки изображений, все это нашло широкое применение только в недавнее время. Вот, в качестве демонстрации вау-эффекта, пара картинок:



Я не стал использовать замученную Лену, а нашел свою фотку Венеции. Правое изображение честно получено из левого, причем без использования ухищрений типа 48-битного формата (в этом случае будет 100% восстановление исходного изображения) – слева самый обычный PNG, размытый искусственно. Результат впечатляет… но на практике не все так просто. Под катом подробный обзор теории и практические результаты.
Осторожно, много картинок в формате PNG!

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

• Скачать с Яндекса
• Скачать с Dropbox

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

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

Имеем следующий код:

1    class A {
2        
3     private B line;
4   
5     public void foo() {
6       for (Integer line : line.getElements()) {
7    
8       }
9     }
10    }
11    
12    class B {
13    
14      List<Integer> getElements() {
15         return null; // doesn't matter
16      }
17    }

Вопрос: скомпилируется ли код?
Ответ: должен, но не будет

Managed код и .NET Framework – совершенно замечательная вещь с точки зрения программиста, которому надо кровь из носу выдавать максимально стабильно работающие программы. Использование .NET позволяет очень сильно сократить затраты на разработку, тестирование и сопровождение программных продуктов, особенно по сравнению с C++ или Delphi.

Однако, managed код имеет одну очень серьезную родовую травму, которая прямо проистекает из его достоинств – он изначально несовместим с unmanaged средой, в которой вынужден работать. Boxing, поля памяти, отсутствие прямой адресации и прочие ухищрения, призванные облегчить жизнь программисту, приводят к тому, что взаимодействие managed и unmanaged кода становится проблемой.

Однако нет такой проблемы, которую нельзя решить (пусть даже с помощью топора и лома). Сегодня у нас краткий обзор возможностей организации взаимодействия между managed и unmanaged кодом. Многие C# и особенно VB.NET программисты боятся этого, но на самом деле в этом нет ничего страшного. Начнем мы с самых примитивных методов, которые будут интересны разве что новичкам (поэтому матерые волки .NET могут с чистой совестью первую часть статьи пропустить), и закончим описанием того, что делать, если хочется написать программу на .NET, но сделать это невозможно (а такое тоже бывает). Естественно, к каждому случаю будут приведены конкретные примеры, быть может, хабрачеловеки расскажут мне о моей собственной велосипедности. Параллельно я скажу пару слов о подводных камнях при работе с VSTO и Windows Shell.

Как вы, наверное, помните из моей предыдущей статьи, взаимодействие unmanaged и managed кода представляет определенную проблему, даже для опытных разработчиков. Причина этого — необходимость понимать, какие процессы происходят при пересечении данными границы CLR.

К сожалению, нередко проблема наладить взаимодействие встает у тех разработчиков, которые слабо знакомы с подноготной технологии COM и возможностями .NET для обеспечения взаимодействия. Это нормально — нельзя знать все на свете. Потому я не буду здесь объяснять всю суть проблемы маршаллинга данных из unmanaged в managed и обратно, а просто дам несколько рабочих рецептов, которые помогут вам тогда, когда нужно срочно и завтра, и вы с тоской смотрите на английское издание книги Inside OLE и понимаете, что разобраться в этом за день нет никакой возможности.

Однако, для тех, кто неплохо в этом разбирается, в конце статьи есть небольшой бонус — способ организации out-process COM на .NET. Честно говоря, я добросовестно считал, что сделать out-process COM с помощью .NET невозможно, однако буквально вчера выяснилось, что все-таки нет, можно. В связи с этим, рассказывать про архитектуру .NET Pipe RPC я скорее всего не буду — она достаточно сложна, однако все предоставляемые ей возможности с легкостью заменяет out-process COM.

Методика все та же — минимум объяснений, максимум рецептов. Для глубинного понимания происходящих процессов рекомендую обратиться к документации в MSDN — этот раздел уже даже перевели на русский язык.

Здравствуйте, Хабросообщество!

На хабре есть описание множества интересных структур данных, таких как деревья отрезков, дуча и т.п. Если Вам интересны сложные структуры данных, то добро пожаловать под кат!

Привет, Хабрахабр!

Введение

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

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

Введение

Здравствуй, уважаемый хабраюзер.Я хотел бы тебе представить материал о практическом создании компилятора, который будет транслировать код, написанный на языке Cool, в код виртуальной машины CIL (Common Intermediate Language) под платформу .NET.Данный материал я решил разбить на две части из-за лени все сразу это описывать

В первой части будет описан процесс написания грамматики с учетом приоритетов операторов в среде ANTLR, а также генерации лексера и парсера под язык C#. Также в ней будут рассмотрены подводные камни, которые встретились у меня на пути. Таким образом я постараюсь хоть кому-нибудь сэкономить время (может быть для себя в будущем).

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

Многие из нас имеют аккаунт в сервисе Dropbox, о данном сервисе написано много статей и лайф-хаков, но сегодня я хочу вам показать, как можно заполучить заветный e-mail в зоне .edu за 15 минут.

Со вчерашнего дня, господа, можно написать вот такой скрипт:

// функция преобразования строки JavaScript (UTF-8) в UTF-16
function TEXT(text){
   return new Buffer(text, 'ucs2').toString('binary');
}

var FFI = require('node-ffi');

// подключаемся к user32.dll
var user32 = new FFI.Library('user32', {
   'MessageBoxW': [
      'int32', [ 'int32', 'string', 'string', 'int32' ]
   ]
});

// диалоговое окно
var OK_or_Cancel = user32.MessageBoxW(
   0, TEXT('Привет, Хабрахабр!'), TEXT('Заголовок окна'), 1
);

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

Это стало возможным потому, что модуль node-ffi (обёртку вокруг той необыкновенно полезной библиотеки libffi, которая используется для вызова библиотек на языке Си не менее чем в восьми других языках) вчера портировали на Windows.