...

суббота, 5 октября 2013 г.

Топология для самых маленьких. Часть 2

В данной статье я продалжаю свое нежное введение в топологию. Первая часть находится здесь.

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

Замечания про ошибки (математические) приветствуются.

Еще одно предупреждение — очень много картинок.

Картинка для привлечения внимания (никак не относящаяся к нашему тексту).



Как вы думете, не разрывая эти фигуры, но деформируя любым образом, можно ли их рассоединить?

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

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

Поехали.



Итак, подмножество U топологического пространства (X, T) называется окрестностью точки х ттт, когда в U лежит открытое множество содержащее х



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


U, U' и Х и X' являются окрестностями x. При этом U, U' и Х открыты, а X' нет.

Из всего этого следует очень важная теорема (а может и не очень) — множество открыто ттт, когда оно содержит окрестности всех своих точек.

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



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


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

Предельная точка—это точка, подмножества А топологического пространства (X,T), в любой окрестности которой находится точка подмножества А.

Уф. Если говорить опираясь на визуальную интуици, то предельные точки это те точки, которые лежат «внутри» множества или на «краю». Не любая точка, которая принадлежат множеству, является предельной. Посмотрите на картинку ниже.


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

На картинке ниже показаны разные ситуации.


Точка а содержит в любой своей окрестности точку подмножества X. Точка b также. Следовательно, они являютя точками накопления. А вот точка c хотя и имеет окрестности в которых содержатся точки X, но имеет и другие окрестности, которые не содержат точек из X.

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

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

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

Посмотрите на рисунок.


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

Как это доказывается? Ну, здесь все просто. Допустим А подмножество топологического пространства X. Есть точка x, которая не принадлежит А и имеет открытую окрестность U, которая не пересекает А. так как эта окрестность открыта, то она является окрестностью любой своей точки. Раз она не пересекает А, значит ни одна точка этой окрестности не является предельной точкой множества А. Это значит, что (А∪множество его предельных точек)∪ открытое U= X. Или X\(А∪множество его предельных точек)= открытое множество

Т.е. А вместе с множеством своих предельных точек, является дополнением к открытому множеству, а значит замкнуто. Удивительно, как понятие окрестности оказалось глубоко связано с понятием открытости и замкнутости.

Теперь определим тесно связанное с замкнотостью понятие замыкание

Замыкание подмножества X — пересечение всех замкнутых множеств, которые содержат X. Замыкание X обозначается, например, так [X]. Замыкание подмножества — замкнутое множество, потому что пересечение замкнутых множеств замкнуто. И очевидно, что замыкание—самое маленькое замкнутое множество, которое содержиит X

Вот посмотрите на картинку.


У нас есть замкнутое желтое множество и оранжевое открытое. Если мы последовательно пересечем все замкнутые множества, которрые содержат оранжевое (я показал только некоторые шаги), то получим замыкание оранжевого множества.

Думаю, вы догадались, множество является замкнутым ттт, когда оно совпадает со своим замыканием ([X]=X).

Замкнутое множество — это множество, которое содержит все свои предельные точки, верно и то, что замыкание—это объединение множества и его предельных точек. Это кажется тривиальным, но этот факт нужно доказать. Доказывается просто — предельные точки множества X являются, что очевидно, и предельными точками каждого множества содержащего X. Значит они принадлежит и каждому замкнутому множеству содержащему X. Следовательно, предельные точки X содержатся и в любом пересечении этих множеств, т.е. в [X]. С другой стороны множество вместе со своими предельными точками замкнуто, а значит замыкание множества Х это множество Х вместе его предельными точками.

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


У него есть несколько свойств:

1)⊛∅=∅

Это значит, что замыкание пустого множества пусто.

2)X⊆⊛X

Множество содержится в своем замыкании.

3)⊛X=⊛⊛X

Замыкание замыкания множества равно замыканию множества

4)⊛X∪⊛X'=⊛(X∪X')

Объединение замыканий равно замыканию объединения.


Эти правила называются аксиомами замыкания Куратовского.

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


Допустим, у нас есть множество {a,b,c,d,e} снабженное топологией описанной на рисунке. Рассмотрим подмножество этого множества {a,b,c}. Какие точки являются предельными для него в данной топологии? По определению, это будут те точки, которые имеют в каждой своей окрестности точки из {a,b,c} помимо самих себя. Я показал открытые окрестности схематически с помощью окружностей. Точки внутри одного круга—находятся в одной окрестности (или в одном открытом подмножестве множества). Поэтому проверим для каждой точки нет ли у нее окрестности, в которой нет точек из {a,b,c}. У точки a, такая окрестность есть. Это окрестность, где содержится лишь точка а. Значит она не предельная точка. Во всех окрестностях b есть точки из {a,b,c} (помимо самой b). Аналогично для d и e. И т.д. таким образом из данной схемы мы видим, что b,d,e являются предельными точками для {a,b,c}, но а и с нет.

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


В антидискретной топологии каждая точка будет предельной для множества {a,b,c} (и для любого другого, кроме самого множества и пустого множества). Эту топологию не зря называют топологией слипшихся точек, в ней все точки пространства как бы слиплись друг с другом, прямо и не разберешь где что. Не хотел бы жить во вселенной с антидискретной топологией.

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

Глядя на все эти картинки, хочется определить понятие внутренности множества и границы. Например, когда я рисовал множества очерченые черным контуром, то сразу хотелось назвать эту линию границей множества. Однако до сих пор у нас не было понятие границы и внутренности. А сейчас будет.

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

Внутренность любого подмножества антидискретного пространства пуста. В дискретном простанстве любое подмножество совпадает со своей внутренностью и со своим замыканием одновременно.

Граница множества X (X подмножество A) — это множество тех точек множества A, окрестность которых содержит как точки X, так и A/X.

Я нарисовал такую картинку, немного в стиле абстракционистов вышло.


Ну вот. на этой ноте я заканчиваю статью. Для упражнения вы можете подумать над тем, какие точки являются границей множества {a,b,c} с картинки, какие ее внутренностью (если есть), какое у него замыкание. Ну и, конечно, можно ли расцепить фигуры из начальной картинки. И как это сделать (очень развивает пространственное мышление). Ответ на последний вопрос обещаю приложить к следующим статьям.

Пока все.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю № 77 (29 сентября — 5 октября 2013)


сегодня в 22:39





Веб-разработка




CSS




JavaScripts




Браузеры




Новости







Демо




Сайты с интересным дизайном и функциональностью





  • enПервый в мире сайт, где ничего не происходит

  • entravel.ilovevitaly.com — поиск для путешественников, позволяющий увидеть полезную информацию с разных сайтов, а также maps.ilovevitaly.com — карта с большими возможностями

  • Wrist — сайт с интерактивными векторными часами

  • rbv.me — стильный одностраничный сайт с css3-анимацией элементов

  • QuadriTown — сайт-игра в пиксель-арт стиле

  • Greyp Bikes — симпатичный одностраничный сайт с презентацией байков

  • Deep Sea Dive — креативный подход к оформлению сайта

  • studionone.com.au — запоминающееся эффектами и нестандартной навигацией портфолио

  • une-cuisine-astucieuse.fr — забавная анимация и звуковая дорожка

  • d.slowlyshooting.com — впечатляющий пример органичного объединения стильного дизайна и CSS 3D трансформаций




Дизайн




Подборка бесплатных дизайнерских печенек




Занимательное


Дайджест за прошлую неделю.

Материал подготовили dersmoll и alekskorovin




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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Numenta NuPIC: первые шаги

Введение




Numenta NuPIC — открытая реализация алгоритмов, моделирующих процессы запоминания информации человеком, происходящие в неокортексе. Исходные коды NuPIC на github

В двух словах, назначение NuPIC можно описать как «фиговина, выявляющая, запоминающая и прогнозирующая пространственные и временные закономерности в данных». Именно этим большую часть времени занимается человеческий мозг — запоминает, обобщает и прогнозирует. Очень хорошее описание этих процессов можно найти в книге Джеффа Хокинса «On Intelligence» (есть русский перевод книги под названием «Об интеллекте»).


На сайте Numenta есть подробный документ, детально описывающий алгоритмы и принципы работы, а также несколько видео.


Сборка и установка




Описана в readme файле в репозитории, поэтому детализировать не буду. Для работы, nupic потребуется python2.7 (или 2.6) с заголовочными файлами.

Параметры и структура модели




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

Модель состоит из нескольких процессов, поведение каждого из которых задается набором параметров.


Encoder



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

Например, на вход модели мы хотим подавать числа из интервала от 1 до 100 (скажем, текущую относительную влажность). Если просто взять бинарное представление чисел, что значения 7 и 8, расположены рядом, но бинарное их представление отличается очень сильно (0b0111 и 0b1000). Чтобы этого избежать, encoder преобразует числовые значения в набор единичных бит, сдвинутых пропорционально пропорционально значению. Например, для диапазона значений от 1 до 10 и трех единичных бит, получаем следующее представление:



  • 1 -> 111000000000

  • 2 -> 011100000000

  • 3 -> 001110000000

  • 7 -> 000000111000

  • 10 -> 000000000111




Если на входе несколько значений, то их бинарные представления просто объединяются вместе.

Аналогично представляются значения с плавающей точкой и дискретный набор значений (true/false, и другие перечислимые типы).
Spatial Pooler



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



Помимо определения похожих образов входных данных, NuPIC умеет различать контекст этих данных, анализируя их поток во времени. Достигается это за счет многослойности набора клеток (так называемые клеточные колонки), и подробное описание также выходит за намеченные рамки. Тут достаточно сказать, что без этого, система не отличала бы символ B в последовательности ABCABC от того же символа в CBACBA.

Практика: синус




Довольно теории, перейдем к практической стороне вопроса. Для начала возьмем простую функцию синуса, подадим на вход модели и посмотрим насколько хорошо она сможет ее понять и предсказать.

Полный код примера, разберем ключевые моменты.


Для создания модели по набору параметров, используется класс ModelFactory:



from nupic.frameworks.opf.modelfactory import ModelFactory

model = ModelFactory.create(model_params.MODEL_PARAMS)
model.enableInference({'predictedField': 'y'})


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



'sensorParams': {
'encoders': {
'y': {
'fieldname': u'y',
'n': 100,
'name': u'y',
'type': 'ScalarEncoder',
'minval': -1.0,
'maxval': 1.0,
'w': 21
},
},


Здесь задаются параметры encodera, преобразующего значение синуса (в диапазоне от -1 до 1) в битовое представление. Значения minval и maxval определяют диапазон, значение n задает общее количество бит в результате, а w — количество единичных бит (оно почему-то должно быть нечетным). Таким образом, весь диапазон разделяется на 79 интервалов с шагом 0.025. Для проверки вполне достаточно.


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


Вызов метода enableInference у модели, указывает какой из входных параметров мы хотим прогнозировать (он может быть только один).


Подготовка закончена, можно накачивать модель данными. Делается это так:



res = model.run({'y': y})


В аргументы подается dict, в котором перечислены все входные значения. На выходе модель возвращает объект, содержащий в себекопию входных данных (как в оригинальном представлении, так и в закодированном), а также прогноз на следующий шаг. Больше всего нас интересует именно прогноз в поле inferences:



{'encodings': [array([ 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 1., 1., 1., 1., 1., 1.,
1., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0.,
0., 0., 0., 0., 0., 0., 0., 0., 0.], dtype=float32)],
'multiStepBestPredictions': {1: 0.2638645383168643},
'multiStepPredictions': {1: {0.17879642297981466: 0.0083312500347378464,
0.20791169081775931: 0.0083320832430621525,
0.224951054343865: 0.020831041503470333,
0.24192189559966773: 0.054163124704840825,
0.2638645383168643: 0.90834250051388887}},


Прогнозировать мы можем на несколько шагов сразу, поэтому в словаре multiStepPredictions ключом является количество шагов прогноза, а значением — другой словарь с прогнозом в ключе и вероятностью в значении. Для примера выше, модель предсказывает значение 0.26386 с вероятностью 90.83%, значение 0.2419 с вероятностью 5.4% и т.д.


Наиболее вероятный прогноз находится в поле multiStepBestPredictions.


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


Вначале ошибка довольно велика, и прогнозируемое значение заметно отличается от оригинального значения (sin-predictor.py -s 100):


Через 1000 шагов:


Прогресс налицо. Через 10000 шагов:


Через 10000 шагов, последние 360 значений:


Видно, что модель определенно получила некоторые представления о том что от нее хотят.


Заключение




В этой статье я попытался дать самое общее представление о том как пользоваться NuPIC, не уходя в дебри деталей реализации. За кадром осталось много всего — структура сети, система визуализации cerebro, swarming, и т.п. Если будет время и интерес к теме, статьи можно продолжить.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



[Из песочницы] Первоначальная настройка Tomcat и его регистрация в NetBeans


сегодня в 21:35


Мне необходимо было настроить и запустить Tomcat на Mac OS X (Mountain Lion) и зарегистрировать данный сервер приложений (контейнер сервлетов) в NetBeans.

Для того чтобы это сделать, я выполнил следующие пункты.



Установка Tomcat




  1. Скачать архив Tomcat отсюда.

  2. Распаковать архив, например, в папку пользователя.

    ~/apache-tomcat-7.0.42

  3. Открыть программу «Терминал».

  4. Перейти в папку «bin»

    cd ~/apache-tomcat-7.0.42/bin

    и установить разрешение на запуск файлов с расширением .sh.

    sudo chmod +x ./*.sh

  5. Установить переменную окружения CATALINA_HOME. Для того чтобы она сохранилась не на время сессии в терминале, а постоянно, нужно ее прописать в файле «launchd.conf».

    Создать/открыть файл (пример приведен с помощью редактора vi, но можно использовать любой другой, например emacs):

    sudo vi /etc/launchd.conf



    Перейти в режим вставки: «клавиша s».

    Записать туда текст:

    setenv CATALINA_HOME /Users/ХХХ/apache-tomcat-7.0.42



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

    Закрыть режим вставки «клавиша Esc».

    Перейти в режим команды «клавиша :».

    Сохранить файл, команда «wq».

  6. По умолчанию сервер настроен на порт 8080. Чтобы его изменить нужно перейти в папку «conf»:

    cd ~/apache-tomcat-7.0.42/conf



    Открыть там файл «server.xml».

    Найти тэг «Connector» где атрибут port равен «8080» и установить атрибут port в нужное Вам значение:

    <Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />


  7. По умолчанию пользователь, имеющий права публикации (deploy) на сервер через веб GUI или через скрипт, отключен. Его нужно прописать в файле «tomcat-users.xml». Для этого нужно перейти в папку «conf»:

    cd ~/apache-tomcat-7.0.42/conf



    Открыть там файл «tomcat-users.xml» и добавить следующее (имя пользователя и пароль можно использовать отличающиеся от приведенных):

    <role rolename="tomcat"/>
    <role rolename="manager-gui"/>
    <role rolename="manager-script"/>
    <user username="tomcat" password="tomcat" roles="tomcat, manager-gui, manager-script"/>




  8. Перезагрузить компьютер, чтобы установленная переменная окружения CATALINA_HOME установилась.

  9. Открыть программу «Терминал».

  10. Перейти в папку «bin»

    cd ~/apache-tomcat-7.0.42/bin

    и запустить скрипт «startup.sh»

    sh startup.sh



    Должно отобразиться в терминале примерно следующее (в зависимости от ваших настроек системы):


    Using CATALINA_BASE: /Users/ХХХ/apache-tomcat-7.0.42
    Using CATALINA_HOME: /Users/ХХХ/apache-tomcat-7.0.42
    Using CATALINA_TMPDIR: /Users/ХХХ/apache-tomcat-7.0.42/temp
    Using JRE_HOME: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
    Using CLASSPATH: /Users/ХХХ/apache-tomcat-7.0.42/bin/bootstrap.jar:/Users/XXX/apache-tomcat-7.0.42/bin/tomcat-juli.jar




  11. Запустить браузер и набрать в адресной сроке http://localhost:8080. Если вы поменяли порт, как было указано в п. 6, то укажите свой порт.

  12. Должна открыться домашняя страница tomcat.

  13. По кнопке «Server status» можно посмотреть статус поднятого сервера. Нужно будет ввести имя пользователя и пароль созданные ранее.

  14. По кнопке «Manager App» можно публиковать (удалять) приложения. Нужно будет ввести имя пользователя и пароль созданные ранее.

  15. Остановка сервера выполняется следующим образом. Перейти в папку «bin»

    cd ~/apache-tomcat-7.0.42/bin

    и запустить скрипт «shutdown.sh»

    sh shutdown.sh




Регистрация сервера Tomcat в NetBeans




  1. Если была установлена 8 версия Tomcat, то необходимо сделать символьную ссылку на каталог библиотек.


    ln -s /Users/XXX/apache-tomcat-8.0.0-RC3/lib /Users/XXX/apache-tomcat-8.0.0-RC3/common/lib


  2. Открыть NetBeans

  3. Меню Сервис->Серверы

  4. В открывшемся окне нажать кнопку «Добавить сервер»

  5. В открывшемся окне выбрать «Apache Tomcat» и нажать кнопку «Далее»

  6. В следующей отображенной панели указать домашнюю папку Tomcat, например "/Users/ХХХ/apache-tomcat-7.0.42"

  7. Указать имя пользователя и пароль, созданные ранее. Нажать кнопку «Далее».

  8. Указать порт, если он был изменен ранее. Нажать кнопку «Готово».

  9. Для проверки можно создать Веб приложение и выбрать в качестве сервера приложений Apache Tomcat. После чего запустить его из NetBeans. Данное приложение развернется автоматически в Tomcat-е и запуститься в браузере, например под таким адресом: http://localhost:8090/WebApplication1 (обычно по умолчанию шаблон веб приложения содержит страничку jsp с текстом «Hello World!»).


Примечание



Это не относится к настройке Tomcat или регистрации сервера Tomcat в NetBeans, но некоторые приложения ищут java в папке /bin, а в Mac OS X java устанавливается в другие папки, но при этом есть символьная ссылка на java в папке /usr/bin.

Таким образом нужно сделать еще одну символьную ссылку на java.


sudo ln -s /usr/bin/java /bin/java




Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?


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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Half-Life 3 эксклюзивно для Linux


сегодня в 20:46


Собственно Гейб подтвердил что HL3 будет и будет экслючивно для SteamOS aka GNU/Linux.

На LinuxCon Europe, Гейб Ньюэлл официально заявил об этом в следующем отрывке:




Кто-то из аудитории: Ну ладно, а то на счет Half-Life 3?

[все посмеялись]

Гейб: Задавно, что упомянли об этом. Я бы хотел заявить прямо сейчас, что следующая игра по вселенной Half-Life будет официальным экслюзивом для Linux платформ.

[зал взорвался авациями]





Затем Гейб заявил что его не сильно волнуют деньги и он заботится об игроках и релиз зажжет игровую революцию линуксовых игр. Ну и не забыл упомянять, что Window 8 гавне лучшая операционная система для игр. Однако о дате резлиза, по традиции, глава компании решил умолчать.

По материалам p4rgaming.com





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?


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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



60 игр на распродаже Not On Steam


сегодня в 20:34


image

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


Около 60 игр, скидки от 25% и больше, там где иконка ключика значит что дадут ключик, когда игра будет в стиме.


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





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?


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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



VIM, Windows, quickfix — борьба с кодировкой компилятора

Имеется инструментальный компьютер с Windows и ассемблер для одного замечательного, но специфического процессора. Для удобства была настроена рабочая среда на базе VIM — подсветка синтаксиса, вызов препроцессора, ассемблера и линкера через make с разбором сообщений об ошибках, ctags с прыганьем по коду. Но есть нюанс — выдача сообщений :make идет на русском. Разумеется, на консольном русском, cp866. А исходники на ассемблере и локаль VIM — cp1251. И как же быть?



Приводить всю кодировку — текстовых файлов и локали VIM — к cp866 из-за одного компилятора? Даже не смешно. Догадываться из контекста о смысле ошибки? До сих пор так и делал. Надоело. Надо разобраться, потратить пару вечеров и забыть об этом досадном недоразумении.

Система quickfix работает: вывод make попадает в файл ошибок, из него выковыриваются номера неправильных строк кода и вид ошибки, курсор после компиляции сразу ставится в нужное место. Вот только понять суть ошибки непросто:


рис. 1


И команда :cope не помогает в чтении, хотя по ошибочным строкам кода прыгать позволяет:


рис. 2


Примечание: Для примера использована опция makeef=error.err (чтобы сократить отображаемую строку команды make), хотя обычно она у меня пустая по умолчанию, и файл ошибок make создается в TEMP.


Казалось бы — ерунда какая! Ща поправим опцию encoding… Ан нет — она, зараза, глобальная. Поэтому кодировка поменяется везде, во всех открытых буферах, включая окно исходника. Комментариям на русском хана. Сообщениям самого VIM — тоже.


рис. 3рис. 4


Можно попробовать :set encoding=cp866 вручную, можно воткнуть это в $VIM/vimfile/ftplugin/qf.vim, чтобы срабатывало по команде :cope. Можно даже попробовать :setlocal — не поможет.


Раз изменить кодировку в одном отдельно взятом буфере не получается, попробуем перекодировать сам файл ошибок. Для этого заглянем в справку, и обнаружим, что при вызове :make выполняется такая последовательность:




  1. При включённой опции 'autowrite' выполняется запись всех изменённых буферов.

  2. Имя файла ошибок вычисляется в соответствии со значением опции 'makeef'. Если значение опции 'makeef' не содержит "##", то уже существующий файл с таким именем будет удалён.

  3. Запускается программа с именем, заданным в значении опции 'makeprg' (по умолчанию: «make») с необязательным набором [аргументов], вывод которой перенаправляется в файл ошибок (в Unix вывод также отображается на экране).

  4. Выполняется чтение файла ошибок с использованием значения опции 'errorformat'.

  5. Если модификатор [!] не задан, то происходит перемещение к первой ошибке из списка.

  6. Файл ошибок удаляется.

  7. Теперь вы можете перемещаться по списку ошибок с помощью команд вроде :cnext и :cprevious.





Получается, при открытии буфера qf по команде :cope файл ошибок уже не существует. Можно попробовать вернуть его неизящным способом — в $VIM/vimfile/ftplugin/qf.vim записать

setlocal encoding=cp866
setlocal fileencoding=cp1251
w! ./error.err
setlocal encoding=cp1251




То есть, при открытии буфера qf командой :cope сменить кодировку, вставить кодировку для файла, записать новый файл ошибок и вернуть кодировку назад. Кстати, local здесть можно опустить — все равно бесполезно. Теперь можно руками установить новый файл ошибок :cf ./error.err.

рис. 5


Некрасиво, неудобно и куча лишних движений руками. Получается, после каждой компиляции надо сначала :cope, потом :ccl, потом :cf ./error.err и снова :cope. Если попытаться вставить это все в qf.vim, то возникнет бешеная рекурсия, которую VIM удавит самостоятельно. И :cope ведет себя как-то странно: лишние палки в начале строк добавляются, даже неохота разбираться в причинах.


рис. 6


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



Команда ":make" выполняет программу, заданную в значении опции 'makeprg'. Это происходит путём вызова команды из оболочки, заданной в значении опции 'shell'. Иными словами, происходит практически то же самое, что и при вводе команды


":!{значение_makeprg} [аргументы] {значение_shellpipe} {файл_ошибок}".


Здесь {значение_makeprg} это строковое значение опции 'makeprg'. Вы можете использовать любую необходимую программу, не только «make».





Восклицательный знак ":!{команда}" требует выполнить указанную {команду} в оболочке. Значит, отловить событие, возникающее с файлом при выполнении :make, не получится. Надежда использовать автокоманду рухнула. Но сдаваться рано. Посмотрим внимательнее на



'shellpipe' 'sp' строка (по умолчанию: ">", "| tee", "|& tee" или
"2>&1| tee")
глобальная опция
Опция используется для указания строки, которая заставляет оболочку
помещать вывод команды ":make" в файл ошибок.



Оказалось, у моего VIM по умолчанию shellpipe=>%s 2>$1. Похоже, есть возможность взять внешнюю утилиту командной строки и как-нибудь засунуть ее в серединку этой самой shellpipe.

Возьмем iconv, которая есть в проекте GnuWin32 на страничке libiconv. Она может принимать данные из файла или из консольного потока. Я положил ее в C:\bin\, где уже лежат make, ctags, 7z, пара вспомогательных командных файлов и пара-тройка dll. Не забываем и про зависимости (Dependencies, а именно libintl3.dll, лежит на странице утилиты).


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



:set shellpipe=\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251>%s\ 2>&1




Символ вертикальной черты, пробелы и обратные слэши в полном пути к утилите экранируются обратными слэшами. Насчет полного пути — можно, конечно, так не извращаться, а прописать путь к iconv в PATH, но лично я с некоторых пор не люблю этот способ: четыре IDE/CAD на рабочем компьютере имеют в своем составе make, не вполне совместимые между собой, и все прописаны в PATH. Полные пути надежнее.

В общем, заработало. Указанную строчку я записал (без двоеточего в начале) в файл $VIM/vimfile/ftplugin/a6403.vim. Теперь «труба оболочки» изменяется на перекодирующую только при открытии именно этого хитрого типа файла. Вот результат:


рис. 7рис. 8


Русские комментарии в исходнике читаемы, сообщения об ошибках — тоже, по ошибкам прыгается. Решение не идальное:



  • Пришлось использовать стороннюю утилиту при наличии встроенных средств перекодировки. Отмазка: Не особенно страшно в данном случае — все равно использовать сторонний компилятор, и сторонний ctags, и сторонний make. Ну, появились еще файлики в моем c:\bin\…

  • Опция shellpipe глобальная, будет применена ко всем буферам. Отмазка: если не открывать файлы этого специфического ассемблера — никто и не почувствует. Если открывать и при этом параллельно работать в других одновременно открытых буферах с другим транслятором — англоговорящим компиляторам будет фиолетово (проверено), русскоговорящим (на cp866) — только на пользу.




Для устранения второго недостатка можно локально (setlocal) переопределить опцию makeprg, добавив после собственно make специальную «заглушку» в виде последовательности "$*", которая будет заменена аргументами командной строки, и вызов iconv. Тогда shellpipe можно не трогать. А вертикальную черту придется экранировать аж тремя обратными слэшами: один для команды :set, второй — чтобы экранировать третий, нужный при разборе команды.

setlocal makeprg=c:\bin\make.exe\ $*\ \\\|c:\\bin\\iconv\\iconv.exe\ -c\ -f\ CP866\ -t\ CP1251




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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



java-object-merger — больше чем просто маппер объектов

Всем привет! Хотел бы представить вам новую библиотеку на java для маппинга/мержинга объектов, которую я “скромно” позиционирую как возможную альтернативу dozer-у. Если вы разрабатываете enterprise приложения на java, вам не безразлична эффективность вашей работы, и хочется писать меньше скучного кода, то приглашаю почитать дальше!


Для чего нужны мапперы объектов?



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

В мире энтерпрайз приложений принято бить внутреннюю структуру на слои: слой доступа к базе, бизнес и представление/веб сервиса. В слое доступа к базе как правило обитают объекты мапящиеся на таблицы в базе. Условимся называть их DTO (от Data transfer object). По хорошему, они только переносят данные из таблиц и не содержат бизнес логики. На слое представления/веб сервисов, находятся объекты, доставляющие данные клиенту (браузер / клиенты веб сервисов). Назовем их VO (от View object). VO могут требовать только часть тех данных, которые есть в DTO, или же агрегировать данные из нескольких DTO. Они могут дополнительно заниматься локализацией или преобразованием данных в удобный для представления вид. Так что передавать DTO сразу на представление не совсем правильно. Так же иногда в бизнес слое выделяют бизнес объекты BO (Business object). Они являются обертками над DTO и содержат бизнес логику работы с ними: сохранение, модифицирование, бизнес операции. На фоне этого возникает задача по переносу данных между объектами из разных слоев. Скажем, замапить часть данных из DTO на VO. Или из VO на BO и потом сохранить то что получилось.

Если решать задачу в лоб, то получается примерно такой “тупой” код:




employeeVO.setPositionName(employee.getPositionName());
employeeVO.setPerson(new PersonVO());
PersionVO personVO = employeeVO.getPerson();
PersonDTD person = employee.getPerson();
personVO.setFirstName(person.getFirstName());
personVO.setMiddleName(person.getMiddleName());
personVO.setLastName(person.getLastName());
...




Знакомо? :) Если да, то могу вас обрадовать. Для этой проблемы уже придумали решение.
Мапперы объектов



Придуманы конечно-же не мной. Реализаций на java много. Вы можете ознакомится, к примеру тут.

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

Мапперы из списка выше — все разные, более или менее примитивные. Самый мощный пожалуй dozer, с ним я работал около 2 лет, и некоторые вещи в нем перестали устраивать. А вялый темп дальнейшей разработки дозера побудили написать свой “велосипед” (да, я знакомился с другими мапперами — для наших требовний они еще хуже).
Чем плох dozer




  1. Бедная поддержка конфигурирования через аннотации (есть только @Mapping).

  2. Невозможно мапить из нескольких полей в одно (к примеру собрать полное имя из имени, фамилии и отчества).

  3. Проблемы с маппингом генерик свойств. Если в родительском абстрактном классе есть геттер возвращающий генерик тип T, где <T extends IEntity>, а в чайлде T определен, то при маппинге чайлда будет учитываться только спецификация типа T. Будто бы он IEntity, а не тот, которым он определен в чайлдовом классе…

  4. Классы свойств хранятся как строки во внутреннем кэше дозера, и чтобы получить класс, используется специальный класс лоадер. Проблемы с этим возникают в osgi окружении, когда dozer находится в одном бандле, а нужный класс бина в другом, не доступным из первого. Проблему мы побороли хоть и стандартным способом — подсунув нужный класс лоадер, но сама реализация: хранить класс в виде строки — выглядит странно. Возможно это для того чтобы не создавать perm gen space мемори ликов. Но все равно не очень понятно.

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


Какими качествами должен обладать маппер?




  1. Широкая поддержка конфигурации через аннотации.

  2. Полная поддержка генериков.

  3. Чистый, понятный код, который сможет подебажить любой не рискуя сломать мозг.

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

  5. Должна быть возможность тонкой настройки (не хуже чем у дозера).


Почему merger а не mapper?



java-object-merger отличает от других мапперов одна особенность. Основополагающая идея была в том, чтобы дать возможность создавать снимки объектов (Snapshot) на некоторый момент времени, и потом, сравнивая их, находить различия (Diff) подобно тому, как находим diff между двумя текстами. Причем должна быть возможность просмотра снапшотов и диффов в понятном для человека текстовом виде. Так, чтобы раз взглянув на дифф сразу стали ясны все отличия, а так же как будет изменен целевой объект после применения диффа. Таким образом добиваемся полной прозрачности процесса. Никакой магии и черных ящиков! Создание снапшотов открывает еще один интересный сценарий. Можно сделать снапшот объекта, потом как-то изменив его, сделать новый снапшот — проверить что изменилось, и, при желании, откатить изменения. Кстати дифф можно обойти специальным visitor-ом, и пометить только те изменения, которые хочется применить, а остальные проигнорировать.

Так что можно сказать, что merger — это нечто большее чем просто mapper.
Использование



Программа “Hello world” выглядит примерно так:

import net.sf.brunneng.jom.IMergingContext;
import net.sf.brunneng.jom.MergingContext;

public class Main {

public static class A1 {
private String field1;

public String getField1() {
return field1;
}

public void setField1(String field1) {
this.field1 = field1;
}
}

public static class A2 {
private String field1;

public A2(String field1) {
this.field1 = field1;
}

public String getField1() {
return field1;
}
}

public static void main(String[] args) {
IMergingContext context = new MergingContext();
A2 a2 = new A2("Hello world!");
A1 a1 = context.map(a2, A1.class);
System.out.println(a1.getField1());
}
}


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


Посмотрим же как реализован метод map. Это поможет понять многие вещи о библиотеке.



@Override
public <T> T map(Object source, Class<T> destinationClass) {
Snapshot sourceSnapshot = createSnapshot(source);

Snapshot destSnapshot = null;
if (sourceSnapshot.getRoot().getType().equals(DataNodeType.BEAN)) {
Object identifier = ((BeanDataNode)sourceSnapshot.getRoot()).getIdentifier();
if (identifier != null) {
destSnapshot = createSnapshot(destinationClass, identifier);
}
}
if (destSnapshot == null) {
destSnapshot = createSnapshot(destinationClass);
}

Diff diff = destSnapshot.findDiffFrom(sourceSnapshot);
diff.apply();
return (T)destSnapshot.getRoot().getObject();
}



Если исходный снапшот это бин, и если у него есть identifier, тогда пытаемся найти целевой бин для класса destinationClass используя IBeanFinder-ы [тут createSnapshot(destinationClass, identifier);]. Мы такие не регистрировали, да и identifier-а нет, значит идем дальше. В противном случает бин создается используя подходящий IObjectCreator [тут createSnapshot(destinationClass)]. Мы таких тоже не регистрировали, однако в стандартной поставке имеется создатель объектов конструктором по умолчанию — он и используется. Далее у целевого снапшота берется дифф от снапшота источника и применяется к целевому объекту. Все.


Кстати, дифф, для этого простого случая, будет выглядеть так:



MODIFY {
dest object : Main$A1@28a38b58
src object : Main$A2@76f8d6a6

ADD {
dest property : String field1 = null
src property : String field1 = "Hello world!"
}
}


Основные аннотации



Находятся в пакете net.sf.brunneng.jom.annotations.


  • @Mapping — задает путь к полю для маппинга на другом конце ассоциации (например “employee.person.firstName”). Может быть указано на классе целевого объекта или объекта источника.

  • @Skip — поле не попадает в снапшот, не сравнивается и не мапится.

  • @Identifier — помечает поле которое считаеся идентификатором бина. Таким образом при сравнении коллекций мы будем знать какой объект с каким должен сравниваться. А именно будут сравниваться объекты с совпадающими идентификаторами. Так же, если в процессе применения диффа возникнет потребность создать бин, и при этом известен идентификатор, то будет попытка вначале найти этот бин при помощи зарегистрированных IBeanFinder-ов. Так, реализация IBeanFInder может искать бины к примеру в базе данных.

  • @MapFromMany — то же самое что и @Mapping только указывается на классе целевого объекта и позволяет указать массив свойств на объекте источнике которые будут мапится на поле в целевом объекте.

  • @Converter — позволяет задать на свойстве класс наследник PropertyConverter. — он выполнит преобразование между свойствами. Конвертер свойств обязателен при маппинге нескольких полей на одно, т.к. он как раз и должен будет собрать все значения из источника воедино и сформировать из них одно значение.

  • @OnPropertyChange, @OnBeanMappingStarted, @OnBeanMappingFinished — позволяют пометить методы прослушивающие соответствующие эвенты в жизненном цикле маппинга, которые происходят в данном бине.

  • И другие.


Преобразования типов



В IMergingContext можно регистрировать пользовательские преобразователи типов, из одного типа в другой (интерфейс TypeConverter). Стандартный набор преобразователей включает преобразования:


  • примитивных типов в обертки, и наоборот

  • преобразования дат

  • объектов в строку

  • энумы в энумы, и строки в энумы по имени константы энума


Категории объектов



Маппер разделяет все объекты на такие категории как:


  1. Объекты значения: примитивные типы, объекты в пакете java.lang, даты, массивы объектов значений. Список классов считающихся значениями можно расширять через IMergingConext.

  2. Коллекции — массивы, все наследующиеся от java.util.Collection.

  3. Мапы — все наследующиеся от java.util.Map.

  4. Бины — все остальные.


Производительность



Честно говоря, пока писал библиотеку — о производительности особо не задумывался. Да и изначально в целях высокой производительности не было. Однако, решил замерять время маппинга N раз на один тестовый объект. Исходный код теста. Объект довольно сложный, с полями значениями, дочерними бинами, коллекциями и мапами. Для сравнения взял dozer последней на текущий момент версии 5.4.0. Ожидал, что дозер не оставит никаких шансов. Но получилось совсем наоборот! dozer замапил 5000 тестовых объектов за 32 секунды, а java-object-merger 50000 объектов за 8 секунд. Разница какая-то дикая — в 40 раз…
Применение



java-object-merger был опробован на текущем проекте с моей основной работы (osgi, spring, hibernate, сотни мапящихся классов). Чтобы заменить им дозер полностью ушло менее 1 дня. По ходу находились некоторые явные косяки, но, после исправления, все основные сценарии работали нормально.
Ленивые снапшоты



Одна из явных проблем, найденных во время прикручивания маппера к реальному проекту было то, что если делать снапшот на DTO у которой есть ленивые списки других сущностей, а те другие ссылаются на третьи и т.д, то за создание одного снапшота можно, ненароком, выкачать пол базы. Поэтому было решено сделать все свойства в снапшоте ленивыми по умолчанию. Это означает, что они не будут вытаскиваться из объектов до момента сравнения с соответствующим свойством при взятии диффа. Или пока явно не вызовем на снапшоте метод loadLazyProperties(). А при вытаскивании свойства происходит автоматическое достраивание снапшота — опять же с ленивыми свойствами, которые ждут пока их догрузят.
Заключение



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

Качайте, пробуйте, пишите свои отзывы :). Обещаю оперативно реагировать и прислушиваться к вашим пожеланиям.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Инфографика: Death to Bullshit или Смерть Бесполезности


сегодня в 19:01


Доброго времени суток уважаемые хабравчане. Недавно я увидел интересную презентацию «Death To Bullshit» от Брэда Фроста c его выступления на Creative Mornings. В презентации есть некоторая статистика, где приведенные числа рассматриваются не как впечатляющие цифры современных трендов/тенденций, а как угнетающее количество мусора в интернете и в жизни, которое большинство людей так привыкло распространять и создавать. Я убежден, что будущие технологии должны объединять умы людей путем лаконичного поиска «идеально-релевантной» информации и создания «идеально-сформированных» комьюнити. С этими мыслями мне захотелось сделать свою первую инфографику. Результат получился благодаря замечательному infogr.am, о котором я рассказывал в одном из своих дайджестов. Внутри еще две занимательных видео-инфографики.

Инфографика: Death to Bullshit или Смерть Бесполезности

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


Death to Bullshit или Смерть Бесполезности




Инфографика: Death to Bullshit или Смерть Бесполезности

Internet Porn (все цивильно)





The state of the internet








Большое спасибо всем за внимание.





Developers, stick with Russians – work in London




Переводы с

карты на карту


Переводы

через QR-Код


Новая функция

«Мой контроль»




Возьми Lumia 925 на тест-драйв сейчас.




Впечатляющие возможности

в стильном тонком корпусе из металла




Boomburum

исследует LTE


Эволюция средств связи

в путешествии по России




Проблемы коммуникации внутри бизнеса?


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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:



Большой Адронный Коллайдер своими глазами. Часть 3

Продолжу свой рассказ про посещение дня открытых дверей в CERN.

Первая часть здесь


Вторая часть здесь


Часть 3. Вычислительный центр.


В этой части я расскажу о месте, где хранят и обрабатывают то, что является продуктом работы CERN — результаты экспериментов. Речь пойдет про вычислительный центр, хотя правильнее, наверное, его назвать дата центром. Но сначала я немного коснусь проблематики вычислений и хранения данных в CERN. Каждый год один только Большой Адронный Коллайдер производит такое количество данных, что если их записать на CD, получится стопка высотой 20 километров. Это происходит из-за того, что при работе коллайдера пучки сталкиваются 30 миллионов раз в секунду и при каждом столкновении возникает примерно 20 событий, каждое из которых производит большое количество информации в детекторе. Конечно, эта информация обрабатывается сначала в самом детекторе, затем поступает в локальный вычислительный центр и только потом передается в главный центр хранения и обработки данных. Тем не менее, приходится обрабатывать примерно пентабайт данных каждый день. К этому надо добавить то, что эти данные надо не только хранить но и распределять между исследовательскими центрами по всему миру, а кроме того, поддерживать примерно 4000 пользователей WiFi сети в самом CERN. Необходимо добавить, что существует вспомогательный центр хранения и обработки данных в Венгрии, с которым существует 100 гигабитный линк. При этом внутри CERN проложено 35000 километров оптического кабеля.

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


image


Сейчас произошел переход от мейнфреймов к гриду обычных РС. В настоящее время центр обладает 90000 процессорных ядер в 10000 серверов, которые работают 24 часа в сутки 7 дней в неделю. В среднем на этом гриде одновременно работает 250000 заданий по обработке данных. Этот вычислительный центр находится на пике современных технологий и, часто, двигает вычислительную технику и IT вперед для решения задач, необходимых для хранения и обработки таких больших объемов данных. Достаточно упомянуть то, что в здании, находящемся недалеко от вычислительного центра Тимом Бернерсом-Ли был изобретен World Wide Web (расскажите об этом тем идиотам альтернативно одаренным, которые, сидя в интернете, говорят, что фундаментальная наука не приносит пользы).


Однако вернемся к проблеме хранения данных. На фотографии видно, что в допотопные времена раньше данные хранились на магнитных дисках (Да, да, я помню эти диски объемом 29 мегабайт на ЕС ЭВМ).


image


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


image


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


image


Большая часть зала занята этими самыми шкафами.


image


В них хранится порядка 100 пентабайт информации (что эквивалентно 700 годам Full HD видео) в 480 миллионах файлов. Интересно, что к этой информации имеют доступ примерно 10000 физиков по всему миру в 160 вычислительных центрах. Эта информация содержит все экспериментальные данные начиная с 70-х годов прошлого века. Если присмотреться повнимательнее, видно, как эти магнитные ленты расположены внутри шкафов.


image


В некоторых стойках находятся процессорные модули.


image


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


image


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


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


image


Пройдя далее можно увидеть стойки с другим оборудованием.


image


image


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


image


image


После этого появилась другая группа посетителей и нас попросили на выход. Делаю последнюю фотографию и покидаю вычислительный центр.


image


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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends: