«Если человек, рождённый слепым, может на ощупь различать формы предметов, такие как сфера и куб, сможет ли он, получив способность видеть (но уже без помощи осязания), определить эти объекты только при помощи зрения, соотнеся их с имеющимся у него тактильным представлением?» Так звучит задача Молинью, мысленный эксперимент, сформулированный в 1688 году. И сам Уильям Молинью, и Джон Локк, в письме к которому он описал эту задачу, склонялись к отрицательному ответу.

Значительную часть информации зрячий человек получает благодаря глазам. Часто мы сознательно "лишаем" себя одного из органов, полезных для ориентации в пространстве — затыкаем уши наушниками и слушаем музыку, получая удовольствие. Человек, потерявший зрение в сознательном возрасте, продолжает мыслить обычными для зрячего категориями — он представляет картинки происходящего, мозг создаёт их из получаемой от других органов информации. Те же, кто родился слепым, видят мир иначе. Если потерявший зрение человек представит отдых на море, "увидев" воду и песчаный пляж, то слепой от рождения почувствует песок между пальцами и бриз на коже, услышит звуки волн. Даже после восстановления зрения мозг этих людей не сразу способен воспринять определённые предметы и явления.

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

Последняя разработка ЗАО «НИИФИ и ВТ» превзошла все возможности моего воображения...

Особенно хочется отметить, что это не какой нибудь сферический конь в вакууме — всем известно что наши выдающиеся военные учёные не всегда доводят свои прорывные научные идеи до реального воплощения, не так давно они даже получили за это очередной нагоняй от правительства.
Нет, сегодня речь идёт о законченном продукте, воплощённым в железе, который можно приобрести за весьма скромную сумму — 4 миллиона рублей точнее даже 3 700 000, воспользовавшись сайтом госзакупок.
Не буду больше испытывать терпение читателя, речь пойдёт о новейшем внешнем жёстком диске весом в… 25 килограммов. С остальными параметрами этого эпохального гаджета заинтересовавшийся читатель может ознакомиться под катом. Затем я уже совершенно серьёзно предлагаю обсудить что значит производство подобного рода устройств и как это может отразиться на нашей обороноспособности.

Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

Учёные уже полностью дизассемблировали H1N1 и занесли его в вирусную базу NCBI Influenza Virus Resource. Там всё задокументировано в подробностях. Например, образец A/Italy/49/2009(H1N1) был обнаружен в носу 26-летней женщины, вернувшейся из Италии в США. Вот первые 120 бит его генетического кода.

atgaaggcaa tactagtagt tctgctatat acatttgcaa ccgcaaatgc agacacatta

Сколько бит убьёт человека?
По приблизительным подсчётам, общий размер исходников H1N1 составляет 26 022 бит, а если исключить служебные стоп-сигналы (указывают на окончание каждой белковой последовательности), то исполняемый код состоит примерно из 25 054 бит. Это число является приблизительным ещё и потому, что в вирусе присутствует механизм генерации избыточного мусора для маскировки от антивирусов.

Итак, получается около 25 килобит или 3,2 килобайта. Таков объём кода для программы, имеющей ненулевые шансы убить человека. H1N1 написан гораздо эффективнее, чем компьютерный вирус MyDoom размером около 22 КБ.

Очень унизительно, что меня могут убить всего 3,2 КБ генетических данных. Впрочем, в 850 МБ человеческого генома по любому должны быть дыры для парочки эксплойтов.

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

Краткое содержание предыдущей серии:

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

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

Не все так просто, и вот, почему.

Сегодня я знаю: в какой бы стране я ни оказался, перед какой бы аудиторией ни выступал, если я покажу кредитную карту Visa и спрошу: «Кто из вас знает, что это такое?» — в ответ поднимется лес рук. Но стоит мне спросить: «А скажите, кому принадлежит Visa, как она управляется и где можно купить ее акции?» и в зале наступит гробовая тишина. Мы имеем дело с чем-то совершенно непонятным. С чем же именно? И с чего все начиналось?

Ди Хок – основатель и бывший генеральный директор Visa

Уважаемый читатель, данная статья написана по книге основателя крупнейшей в мире бизнес-структуры Visa Ди Хока “One from Many: VISA and the Rise of Chaordic Organization”. Курсивом выделены цитаты из книги. Решил разбить статью на две части, так как объём информации очень большой. Статья расскажет, как создавалась Visa и как она управляется, и о чём сожалеет её создатель.

Оглавление (на данный момент)

Часть 1. Описание, операции, применения.
Часть 2. Ценная информация в дереве и множественные операции с ней.
Часть 3. Декартово дерево по неявному ключу.
To be continued...

Декартово дерево (cartesian tree, treap) — красивая и легко реализующаяся структура данных, которая с минимальными усилиями позволит вам производить многие скоростные операции над массивами ваших данных. Что характерно, на Хабрахабре единственное его упоминание я нашел в обзорном посте многоуважаемого winger, но тогда продолжение тому циклу так и не последовало. Обидно, кстати.

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

Введение

В качестве введения рекомендую прочесть пост про двоичные деревья поиска того же winger, поскольку без понимания того, что такое дерево, дерево поиска, а так же без знания оценок сложности алгоритма многое из материала данной статьи останется для вас китайской грамотой. Обидно, правда?

Следующий пункт нашей обязательной программы — куча (heap). Думаю, также многим известная структура данных, однако краткий обзор я все же приведу.
Представьте себе двоичное дерево с какими-то данными (ключами) в вершинах. И для каждой вершины мы в обязательном порядке требуем следующее: ее ключ строго больше, чем ключи ее непосредственных сыновей. Вот небольшой пример корректной кучи:

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

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

Я часто собеседую разработчиков и часто задаю им простой, как кувалда, вопрос — как внутри работает JOIN в SQL? В ответ я обычно слышу бессвязное мычание про волшебные деревья и индексы, которые быстрее. Когда-то мне казалось, что каждый программист специалист должен знать то, с чем работает. Впоследствии жизнь объяснила мне, что это не так. Но мне все еще не понятно, как можно годами теребить базёнку, даже не догадываясь, а что там у нее «под капотом»?

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

13 июня 1944 года, через неделю после вторжения союзников в Нормандию, громкий жужжащий звук прогремел в небе избитого боями Лондона. Источником звука было недавно разработанное немецкое орудие войны: воздушная бомба V-1. Будучи предшественником крылатых ракет, V-1 была самоходной бомбой, управляемой с помощью гироскопов, питалась она от простого пульсирующего воздушно-реактивного двигателя, который поглощал воздух и воспламенял топливо 50 раз в секунду. Такая высокая частота пульсации давала бомбе характерный звук, зарабатывая ей прозвище «жужжащая бомба» (в оригинале – «buzz bomb» – прим. перев.).

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

В данной статье рассмотрим принцип аутентификации в веб-приложениях на платформе Spring с использованием относительно нового механизма аутентификации — JSON Web Token (JWT). Этот механизм уже обкатан и реализован для многих языков программирования.

«Когда я только начинала работать в этой сфере, все это было для нас как Дикий Запад — мы были первооткрывателями неизведанных земель. Никто нас ничему не учил» Маргарет Гамильтон.



Это Маргарет. Она пишет код хорошо. Делайте как Маргарет.

А еще:

• программист-самоучка;
• написала код для навигационного компьютера программы «Аполлон»;
• когда американцы ступили на поверхность Луны ей был 31 год;
• Маргарет НЕ автор термина «software engineering»;
• часто брала на работу 4х-летнюю дочку;
• дочка помогла найти баг в программе.

Под руководством Маргарет Гамильтон писались программы для бортового компьютера КА Аполлон. В один из самых ответственных моментов миссии Аполлон 11 именно работа Маргарет и ее команды предотвратила возможный срыв высадки на Луну. За три минуты до прилунения сработало несколько аварийных сигнальных устройств. Компьютер был перегруженн входящими данными – в стыковочной радарной системе произошло непроизвольное обновление счетчика, что привело к запросу на выполнение компьютером большего числа операций, чем он был способен обработать. Благодаря устойчивой архитектуре компьютер продолжил свою работу: в разработке бортового ПО использовался подход асинхронного исполнения (asynchronous executive). Процессы с высоким приоритетом (критичные для прилунения) могли прервать низкоприоритетные процессы.

Недавние отечественные проекты, один из которых представили мы, другой — появился на GeekTimes в «авторском» посте, натолкнули на мысль о короткой подборке на тему портативных аппаратов ЭКГ, и все, что мы нашли — под катом.

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

• Что есть информация?
• Как мозг представляет знания?
• Что такое язык?
• Какова роль языка в мышлении?
• Как совершаются поступки?
• Как осуществляется планирование?
• Какова природа фантазий и воспоминаний?
• Что такое мотивация?
• Какова природа эмоций?
• Откуда берется многообразие эмоциональных оценок?
• Что есть смысл?
• Как рождается мысль и какова ее природа?
• Что такое внимание?
• Что есть любовь?
• Что есть гармония и красота?

В какой-то из весенних дней этого года я ехал в троллейбусе и листал комикс о Коше. В одном из выпусков была такая фраза «НО! Её можно понять, она же фракталами в горизонт перетекает, я бы тоже замешкался...». После этого я посмотрел в окно и понял, что если мы возьмём два подходящих дробно-линейных преобразования комплексной плоскости a(z) и b(z), и рассмотрим систему итерированных функций для a(z), b(z), a⁻¹(z), b⁻¹(z), взяв в качестве начального множества картинку с Кошем, то Кош будет перетекать фракталами в горизонт!

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

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

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

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

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

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

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

Попробуем в нескольких статьях пройти путь от описания базовых идей, лежащих в основе всех сборщиков мусора, до разбора алгоритмов работы и возможностей тонкой настройки различных сборщиков Java HotSpot VM (вы ведь знаете, что таких сборщиков четыре?). И самое главное, рассмотрим, каким образом эти знания можно использовать на практике.

Java недавно стукнуло 20 лет. Казалось бы, на сегодняшний день на java написано все. Любая идея, любой проект, любой инструмент на java? — это уже есть. Тем более когда речь идет о таких банальных вещах как пул соединений к базе данных, который используют миллионы разработчиков по всему миру. Но не тут то было! Встречайте — проект HikariCP — самый быстрый на сегодняшний день пул соединений на java.

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

Этот пост — вольный и частичный перевод статьи Down the Rabbit Hole от автора HikariCP перемешанный с потоком моего сознания.

Середина 2000-х годов ознаменовалась бурным ростом числа колоночных СУБД. Vertica, ParAccel, Kognito, Infobright, SAND и другие пополнили клуб колоночных СУБД и разбавили гордое одиночество Sybase IQ, основавшей его в 90х годах. В этой статье я расскажу о причинах популярности идеи по-колоночного хранения данных, принцип действия и область использования колоночных СУБД.

Начнем с того, что популярные в наше время реляционные СУБД — Oracle, SQL Server, MySQL, DB2, Postgre и др. базируются на архитектуре, отсчитывающей свою историю еще c 1970-х годов, когда радиоприемники были транзисторными, бакенбарды длинными, брюки расклешенными, а в мире СУБД преобладали иерархические и сетевые системы управления данными. Главная задача баз данных тогда заключалась в том, чтобы поддержать начавшийся в 1960-х годах массовый переход от бумажного учета хозяйственной деятельности к компьютерному. Огромное количество информации из бумажных документов переносилось в БД учетных систем, которые должны были надежно хранить все входящие сведения и, при необходимости, быстро находить их. Такие требования обусловили архитектурные особенности реляционных СУБД, оставшиеся до настоящего времени практически неизменными: построчное хранение данных, индексирование записей и журналирование операций.

Дисклеймер от автора (автор — девушка): Я не разрабатываю движки баз данных. Я создаю веб-приложения. Я участвую в 4-6 разных проектах каждый год, то есть создаю много веб-приложений. Я вижу много приложений с различными требованиями и различными потребностями хранения данных. Я разворачивала большинство хранилищ, о которых вы слышали, и несколько, о которых даже не подозреваете.

Несколько раз я делала неправильный выбор СУБД. Эта история об одном таком выборе — почему мы сделали такой выбор, как бы узнали что выбор был неверен и как мы с этим боролись.Это все произошло на проекте с открытым исходным кодом, называемым Diaspora.

MongoDB — замечательная база данных, которая становится все популярнее в последнее время. Все больше людей с SQL опытом начинают её использовать, и один и первых вопросов, который у них возникает: MongoDB transactions?.

Если поверить ответам со stackoverflow, то все плохо.

MongoDB doesn't support complex multi-document transactions. If that is something you absolutely need it probably isn't a great fit for you.

If transactions are required, perhaps NoSQL is not for you. Time to go back to ACID relational databases.

MongoDB does a lot of things well, but transactions is not one of those things.

Но мы не поверим и реализуем транзакции (ACID*) основанные на MVCC. Ниже будет рассказ о том, как эти транзакции работают, а тем, кому не терпится посмотреть код — добро пожаловать на GitHub (осторожно, java).

Пост не о MongoDB, а о том, как использовать compare-and-set для создания транзакций, а durability обеспчивается ровно в той степени, в которой её обеспечивает хранилище.