Я достаточное время пользовался I2P и читал все статьи об этой сети доступные в русскоязычной части интернета, но не одна из них не даёт всеобъемлющего знания о ней. Учитывая пожеланию людей в предыдущих публикациях об I2P, я занялся переводом официального источника.
Из-за большого объёма информации, я буду выкладывать переводы частями.

Если кого то действительно это интересует, прошу под «спойлер».

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

Введение

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

1. Веб-сёрфинг, используя любой браузер поддерживающих работу через прокси.
2. Чат: IRC, Jabber, I2P-Messenger.
3. Файлообмен:
   Torrents: I2PShark, Robert, Imule, PyBit, I2P-bt
   Передача напрямую между ПК: I2Phex
4. E-mail: susimail and I2P-Bote.
5. Blog: используя Syndie.
6. Распределённое хранение данных, сохраняйте свои данные используя облачную Tahoe-LAFS поверх I2P.
7. Группы новостей, используя любые программу reader, поддерживающую прокси.

В отличие от веб-сайтов, размещенных в распределительных сетях Freenet и GNUnet, сайты размещенных на I2P полностью интерактивные — есть традиционные веб-сервисы: поисковые системы, доска объявлений, в блогах имеется возможность комментировать.

С учетом всех этих анонимных приложений, I2P берет на себя роль «Харона» (Тот кто души через реки перевозил в греческой мифологии) — приложения сообщают, что они хотят послать некоторые данные на адрес, представленный криптографическим идентификатором (Это пункт назначения) и I2P заботиться о том, чтобы данные были доставлены секретно и анонимно. I2P умеет распределять пакеты, для того чтобы информация максимально анонимно и надежно передавать через несколько потоков, поверх TCP. При этом на основе алгоритма обеспечивать максимальную пропускную способность и минимальные задержки.
Доступны несколько простых прокси-серверов SOCKS, чтобы связать существующий интернет с I2P, их возможности были ограничены, так как многие сайты обычно создают угрозу анонимности и подвергают пользователя опасности.
Единственный безопасный путь это полная обработка приложений для обеспечения надлежащей работы, мы предоставляем ряд API-интерфейсов, которые можно использовать, чтобы улучшить взаимодействие с сетью (тут видимо имеется в виду работа с сетью интернет в обе стороны).

I2P не является исследовательским проектом — академическим, коммерческим или государственным. Это совместные усилия инженеров, направленные на то, чтобы делать все необходимое для обеспечения достаточного уровня анонимности для тех, кто в ней нуждается. Активная разработка велась с начала 2003 года и занимала всё время разработчиков, также есть специальная группа состоящая из участников со всего мира, которая тоже участвовала в разработке. Весь исходный код I2P открыт и свободно доступен на веб-сайте, большинство кода отдано в общественное достояние, хотя и используются нескольких криптографических процедур под BSD лицензией.
Люди, работающие над I2P не контролируют то, что люди делают в клиентских приложениях, и есть несколько приложений, доступных под лицензией GPL (I2PTunnel, susimail, I2PSnark, I2P-Bote, I2Phex и другие.).
Финансирование I2P поставляется исключительно из пожертвований, и не облагается налогами (ой как загнул), так как многие разработчики сами являются анонимными.

Принцип работы

Обзор

Чтобы понимать как работает сеть I2P, важно понять несколько ключевых понятий:
Во-первых, I2P делает строгое разделение между программным обеспечением, участвующих в сеть ( «маршрутизатор») и анонимные концами («цели»), связанные с отдельными приложениями.
Тот факт, что кто-то работает через I2P как правило, не секрет. Что скрывается? Это информация о том, что пользователь делает (если вообще что-либо), а также то, что маршрутизатор конкретного назначения подключен. Конечные пользователи, как правило, имеют несколько локальных адресов на маршрутизаторе — например, один прокси, для IRC серверов, другой для поддержки пользовательского анонимного веб-сервер («eepsite»), другой для I2Phex например, другой для торрентов и т. д.

Вторым важным аспектом для понимания работы, является концепция «туннеля». Туннель ориентированный путь через явно выбран список маршрутизаторов. Используется многоуровневое шифрование, поэтому каждый из маршрутизаторов может расшифровать только один слой. Расшифрованный информация содержит IP следующего маршрутизатора, наряду с зашифрованной информацией, которая будет перенаправлена. Каждый тоннель имеет начальную точку (первый маршрутизатор, также известный как «шлюз») и конечную точку. Сообщения могут быть отправлены только в одну сторону. Чтобы получить обратное сообщение, требуется еще один туннель.

Существует два типа туннеля: «исходящий» туннели отправляет сообщения от создателя туннеля, в то время как «входящие» туннели передают сообщение обратно создателю туннеля. Сочетание этих двух туннелей позволяет пользователям друг другу сообщения. Отправитель («Alice» на изображении выше) устанавливает исходящий туннель, в то время как приемник («Bob» в картинке) создает входящий туннель. Шлюз в входящем туннеле может получать сообщения от других пользователей, и переслать их до конечной точки (в данном случае это «Bob»).
Конечная точка исходящего туннеля должна будет отправить сообщение на шлюз во входящий туннель. Для этого отправитель («Алиса») добавляет инструкции в зашифрованное сообщение. Как только конечная точка исходящего туннеля расшифровывает сообщение, оно получит инструкцию, чтобы переслать сообщение на правильный входящий шлюз (шлюз «Bob»).

Третьим важным для понимания пунктом является сетевая база данных NetDB. Несколько алгоритмов, предназначенные для обмена сетевыми метаданными. Существует два типа метаданных это «routerInfo» и «leaseSets»:
routerInfo дает данные о маршрутизаторах, необходимых для обмена данными частных маршрутизаторов (их открытыми ключами, адресами и т.д.), в то время как leaseSet дает маршрутизаторам информацию, необходимую для связи конкретных точек.
LeaseSet содержит блок информации «Lease». Каждое поле определяет туннель из шлюзов, который позволяет достичь получателя. Полная информация, содержащаяся в Lease:
Входящий шлюз для туннеля, который позволяет достичь получателя.
Время, когда туннель устарел.
Пара открытых ключей, чтобы иметь возможность шифрования сообщений (для отправки через туннель и для получателя в пункте назначения).

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

Для создания собственных входящих и исходящих туннелей, Алиса производит поиск в netDb для сбора routerInfo. Таким образом, она собирает списки пиров, которые она может использовать в качестве Hop (Промежуточных точек) в ее туннелях. Она может отправить создать сообщение для первого прыжка с просьбой о создании тоннеля и просить, чтобы маршрутизатор отправил запрос на создание туннеля, до того как туннель будет построен.

Когда Алиса хочет послать сообщение Бобу, она сначала выполняет поиск в netDb, чтобы найти leaseSet Боба и получить информацию о текущих входящих туннелях Боба. Затем она выбирает один из своих исходящих туннелей и отправляет сообщение по нему с инструкциями для конечной точки исходящего туннеля, чтобы переслать сообщение на один из шлюзов входящего туннеля Боба.
Когда в исходящем туннеле конечная точка получает эти инструкции, она передает сообщение с запросом и когда входящий шлюз туннеля Боба получает запрос, он направляется вниз по туннелю к маршрутизатору Боба.
Если Алиса хочет чтобы Боб ответил на сообщение, она должна передать инструкцию явно, как часть самого сообщения. Это может быть сделано путем создания более высокого слоя, создание которого осуществляется в потоковой библиотеке. Алиса может также сократить время отклика, вкладывая ее последний leaseSet в сообщение, так что Бобу не нужно делать поиск по netDb для обращения, когда он решит ответить, но это не обязательно.

В то время как сами туннели имеют имеют многослойное шифрования для предотвращения несанкционированного доступа к пирам внутри сети («транспортный слой» зашифрован сам по себе, для предотвращения несанкционированного доступа к участникам сети).
Так же необходимо добавить дополнительный слой шифрования, чтобы скрыть сообщение от исходящей до конечной точки туннеля и шлюза входящего туннеля. Это «чеснок шифрование» позволяет маршрутизатору Алисы обернуть несколько сообщений в одно „чеснок сообщение“ (это четвёртый аспект), зашифрованные вместе с открытым ключом, так что посредник не может определить количество сообщений и что они содержат.
Для типичного соединения между Алисой и Бобом, сообщение будет зашифровано с открытым ключом, опубликованным в leaseSet Боба, позволяющий читать шифрованное сообщение на маршрутизаторе Боба, не выдавая открытый ключ

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

Какой хороший программист наш Вася! Всегда опрятно одет, вежлив и предупредителен, хороший семьянин и душа компании. Что? Как он, собственно говоря, программирует? Хм… Постойте… А мы и не знаем. Никто никогда толком результатов его работы и не видел-то. Получается, Вася — не очень хороший программист? Ну ладно.

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

А кто у нас есть еще?

Ну вот Коля — Коля всегда предельно точно выполняет указания руководства, работает именно над тем, что ему поручили, никакого своеволия. Ну идеальный же разработчик, да? Правда, последнюю задачу на 50 строк элементарного кода делал он почему-то почти пол-года… Нет, это не образцово-показательный программист.

Сергей — он справляется с задачами быстро. Молодец. Его, пожалуй, и назначим победителем. Правда, получается у него это только при работе в одиночку. А в команде Серёжа наш мямлит, не может ни на вопрос ответить, ни свой задать. Не получается у него работать в больших проектах — а где же нынче маленький-то взять? Вычеркиваем из нашего списка и Сергея.

Но вот Маша — просто рождена для общения. Поговорит с кем угодно, когда угодно, всё обсудит , всех достанет. Молодец Маша! Правда, if от for не отличает. Хороша Маша, но не программистка она наша.

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

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

Евгений наоборот порывается выбросить 90% существующего решения и за каких-то смешных пару лет переписать всё на Haskell/Lisp/Prolog.

Или вот, например… Что? Больше людей в нашей команде нет? Закончились?

А кто же у нас в итоге хороший программист?

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

Ближайшее, к чему я пришел, что мне кажется самым хорошим приближением к термину «хороший программист» — это ответ самого человека на вопросы: «Мне это нужно или нет? Для меня это важно или нет?».

Да или нет? Третьего не дано. Если человеку действительно важно и нужно, то, что он делает — всё остальное по-большому счету можно игнорировать. И не важно даже для чего и почему ему это нужно. Ради денег, славы, знаний, карьеры, покорения мира — всё-равно.

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

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

Посмотрите на себя, на своих коллег, спросите их или себя что-нибудь по работе (или представьте, что спросили). Как часто вы получите ответ «да мне вообще-то всё-равно», «подождём, как-то оно будет», «это не важно», «это не моя задача», «и так как-то работает», «я не знаю почему это сделано так». Следует ли за этими ответами продолжение в духе «но я разберусь и отвечу детальнее», «но я думаю что правильно будет сделать так», «я уточню», «но надо подумать как сделать лучше», «но мне бы хотелось изменить это вот-так», «я думал об этом и считаю, что …»?

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

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

Сегодня я хочу сообщить хабракоммьюнити что комманда разработчиков Qt вынесли Qt 4.8.4 в состояние релиза.

Это очередной patch-релиз (были исправлены баги, бинарная совместимость с Qt 4.8.x). Cписок достижений этого релиза под катом.

• 41 багов пофиксено Qt Gui
• 13 специфических файлов для Mac OS X
• 8 специфических файлов для Windows
• 5 специфических файлов для Linux/X11
• 36 специфических файлов для QNX/Blackberry
• 22 фикса для tools

Как всегда, подробнее можно посмотреть тут.

Есть хорошие новости для тех, кто ждал поддержку Windows 8 и VS2012. Сейчас Qt достаточно хорошо работает на компьютерах c Windows 8 (в режиме desktop) с железом от Intel. Qt 4.8.4 собирается с новым компилятором VS2012, за исключением WebKit.

Загрузить библиотеку можно с Qt Project или, коммерческую версию через Digia Customer Protal. Коммерческая SDK уже может быть обновлена. Комманда уже работает над опенсорсной SDK. Но ждать ее выхода следует после релиза Qt 5.

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

А именно — представьте себе пачку цифирей, которые аналитики составляют раз в месяц, в любимом ими пакете MS Office. И вот раз в месяц появилась необходимость эти цифры пережевывать и загружать в БД под управлением MS SQL.

И конечно же — этот мега-тул надо было сделать быстро. Чтобы потом передать на суппорт дешевым то ли малайцам, то ли индусам. Так что еще и рекомендовалось делать максимально понятно.

Как начали решать задачу

Злые дотнетчики решили упростить себе жизнь — не составлять же insert into руками, если в соответствующем отчете колонок столько, что имена им эксель дает трехбуквенные. А в древней БД огромная стопка таблиц, в некоторых из которых количество колонок просто потрясает воображение.

Поэтому, было сделано так — БД подсунули вижуалстудии, и получили огромную портянку кода для entity framework. Вместо пиления лобзиком и составления prepared statement с сотней вопросиков в values(…) — обычное заполнение entity objects с последующим context.SaveChanges().

Замечу — правильное решение. А premature optimizations как известно — зло.

На что наступили с таким подходом

Чую запах горелого. Срочно бегу на кухню, вынимаю мясо из латки. Обрезаю горелое двуручным мечом и тут же проглатываю, так как Уголек врывается в комнату. Горячо! Но изображаю.
— Что это, Мастер?
— Парная китятина. Последний писк моды!
— Не заливай — про моду ты знаешь только из словаря, — пробует. — Хотя действительно вкусно!

Гладко было на бумаге… Unique constraints далеко не все циферки соглашались кушать.

Потрясающий факт — если entity framework получает database level exception, то становится в позу бегущий кабан по рекомендации микрософта у нас есть только один путь — этот контекст пристрелить и создать следующий. В данном случае это означает, что надо master из старого контекста вытащить, или пересоздать, и желательно не копированием всех полей в catch().

И конечно же чтобы было интереснее — объекты из разных контекстов смешивать нельзя.

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

И вот в этот момент эти злыдни принесли утюг и паяльник! дошли до меня.

Что пришлось сделать

Карапет возмущен.
— Вредины! Просили энергии сто килограмм, а ухнули сколько! Ты мне так и скажи — надо много, зачем обманывать Карапета? Мне же не жалко, надо пять тонн — так и скажи, Карапет, дай нам пять тонн… Вредины они вредины и есть!

Как выяснилось, сущности CancelChanges в entity framework не предусмотрено. А ее наличие дало бы шанс не усложнять.

Как легко догадаться, пришлось изобрести.

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

Куды ложить?

— Афа, возьми себя в руки!
Обхватываю себя руками, отрываюсь от пола на биогравах.
— Взял. Куды ложить?

В примерах я сосредоточился для insertions как наиболее неочевидных. Аналогичным образом разбирается и update. Я не привожу портянку, так как она мало чем отличается от вышеприведенной, да и отслеживать updates проще. Delete у нас как раз нету — это ж паранойя товарищей банкиров, как это из БД что-то удалить? Ни-ни!

Покурив мануалы и как следует погуглив, определим такую структурку данных:

        class MyEntry         {             public EntityObject entity;             public string name;             public Dictionary<string, EntityKey> refmap;             public Dictionary<string, EntityObject> objmap;             public Dictionary<EntityObject, string> keymap;              public MyEntry(string s, EntityObject o)             {                 entity = o;                 name = s;                 refmap = new Dictionary<string, EntityKey>();                 objmap = new Dictionary<string, EntityObject>();                 keymap = new Dictionary<EntityObject, string>();             }         } 

Теперь мы можем заняться магией. Вот так определяется — что было добавлено в контекст после последнего SaveChanges():

            // added relationships             // t means derived class from EntityContext             var added = t.ObjectStateManager.GetObjectStateEntries(EntityState.Added); 

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

            List<MyEntry> allDataToProceed = new List<MyEntry>();             List<ObjectStateEntry> refs = new List<ObjectStateEntry>();             foreach (var a in added)             {                 if (a.IsRelationship)                 {                     var aaa = a.EntitySet.Name;                     var from = ((AssociationSet)a.EntitySet).AssociationSetEnds[0];                     var to = ((AssociationSet)a.EntitySet).AssociationSetEnds[1];                 }                 else                 {                     MyEntry e = new MyEntry(a.EntitySet.Name, a.Entity);                     allDataToProceed.Add(e);                     IEnumerable<IRelatedEnd> relEnds =                          ((IEntityWithRelationships)a.Entity).RelationshipManager.GetAllRelatedEnds();                     foreach (var rel in relEnds)                     {                         List<EntityObject> fks = new List<EntityObject>();                         foreach (var obj in rel)                             fks.Add((EntityObject)obj);                          var relname = rel.RelationshipName;                         if (fks.Count == 1)                         {                             if (fks[0].EntityKey.EntityKeyValues != null)                                 e.refmap[relname] = fks[0].EntityKey;                             else                             {                                 e.keymap[fks[0]] = fks[0].EntityKey.EntitySetName;                                 e.objmap[relname] = fks[0];                             }                         }                     }                 }             } 

Осталось собственно дело за малым — вернуть контекст к жизни

            foreach (var a1 in added)                 a1.Delete();             t.SaveChanges(); 

и приступить к сеансу экзорцизма — а что это у нас тут такое странное приползло, и главное — куда его девать.

Не дома тоже не ори

От давления лопается экран. Беру веник и собираю осколки — я же руководитель экспедиции. Угол что-то хочет сказать — какой у него писклявый голос на глубине в три километра. Говорю ему
— Дома не ори.
Подумав, добавляю
— И не дома тоже не ори.

Первое что нам надо сделать — это учесть foreign keys. Если какой-либо объект создан как часть цепочки master-slave — то не надо master и slave складывать по отдельности, а то так и referral integrity сломать можно.

            // now we need to remove objects already referenced by FK to not add the same              // objects twice in collection             List<EntityObject> usedInRefs = new List<EntityObject>();             foreach (var a1 in allDataToProceed)             {                 foreach (var dup in a1.objmap.Values)                     usedInRefs.Add(dup);             }               for (int j = 0; j < allDataToProceed.Count; ++j)             {                 if (usedInRefs.Contains(allDataToProceed[j].entity))                 {                     allDataToProceed.RemoveAt(j);                     --j;                 }             } 

И наконец дело за малым — осталось запихать в БД то что можно запихнуть. Для этого восстанавливаем нашей копии foreign keys и добавляем в контекст. Удалось? отлично, нет — значит это и есть наш больной зуб.

            foreach (var a1 in allDataToProceed)             {                 try                 {                     IEnumerable<IRelatedEnd> relEnds =                          ((IEntityWithRelationships)a1.entity).RelationshipManager.GetAllRelatedEnds();                     foreach (var rel in relEnds)                     {                         var relname = rel.RelationshipName;                         EntityKey key = null;                         if (a1.refmap.ContainsKey(relname)) key = a1.refmap[relname];                         EntityObject o = key != null ? o = (EntityObject)t.GetObjectByKey(key) : null;                          if (o == null && a1.objmap.ContainsKey(relname))                         {                             o = a1.objmap[relname];                             if (a1.keymap.ContainsKey(o)) t.AddObject(a1.keymap[o], o);                             else o = null;                         }                         if (o != null) rel.Add(o);                     }                      t.AddObject(a1.name, a1.entity);                     t.SaveChanges();                 }                 catch (Exception e2)                 {                     added = t.ObjectStateManager.GetObjectStateEntries(EntityState.Added);                     foreach (var a2 in added) a2.Delete();                     // now we can move back to excel cheet and unform which data is wrong                  }             } 

Вуаля. We did it!

Возможно, этот подход окажется кому-нибудь полезным.

Доброго времени суток. Никак не могу сообразить как в ListView выделить щелчком мыши элемент, находящийся под курсором. Как это сделать?

И еще хотелось бы прокрутка по элементам роликом мыши.