Продолжаю рассказывать об интересных докладах на MBC Symposium (MBC, кстати, расшифровывается как Mind Brain Computation).

Surya Ganguli — человек из теоретического neuroscience, то есть, занимается тем, чтобы понять, как работает мозг, на основе измерений импульсов нейронов на различных уровнях.

И вот тут независимо от neuroscience в мире случается deep learning, и у нас получается некую искусственную систему чему-то научить.
В отличие от мозга, в котором у нас ограниченное разрешение, сложность с повторяемостью, итд итп, про deep network-то мы знаем абсолютно все, про все веса, про все состояния. Возникает вопрос — если мы собираемся разобраться, как работает мозг, может попробуем для начала понять как и почему работает вот такая маленькая система?

Без надежд, что мозг работает также, скорее с прицелом разработать какие-то методы, которые могут быть применимы потом.

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

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


Дома в центре Москвы разного цвета в зависимости от площади здания.
Данные: © Участники OpenStreetMap

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

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

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

В последней апрельской публикации мы хотели бы рассказать вам о замечательной книге Майкла Керриска «Linux Programming Interface», которая в очередной раз вернулась в наше поле зрения благодаря превосходным продажам другой литературы по Linux:



Конечно, сложная книга о системном программировании объемом 1500+ страниц — литература, прямо скажем, на любителя. Но, поскольку отзывы о ней до сих пор восторженные, а нам потратиться на Linux завсегда не жалко предлагаем почитать ее обзор, опубликованный в далеком 2011 году.

_{Grimoire ensorcele by naiiade}

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

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

^{Aqua Mine}
Ревизор — программно±аппаратный комплекс для мониторинга доступа к сайтам из реестра со стороны провайдеров — берет свое начало в октябре 2015 года, когда компания «МФИ Софт», та же компания, что сделала СОРМы, выиграла тендер на разработку ПО за 84 миллиона рублей. Согласно условиям тендера, разработчик должен был предоставить работоспособное ПО под Windows и Linux и 700 аппаратных «Агентов» в срок до 14.12.2015, всего через 2.5 месяца, и, похоже, все было готово даже на пару недель раньше дедлайна. Провайдерам в добровольно-принудительном порядке уже в начале декабря предлагалось установить один из трех вариантов Ревизора: в виде образа виртуальной машины VMWare, основанной на OpenWRT 14.07, в виде программы-сервиса под Windows, либо же в виде железного «Агента», который представлял из себя маршрутизатор TP-Link MR3020 с установленным на него OpenWRT и необходимым ПО. Многие провайдеры отказывались от установки комплекса из-за того, что он не сертифицирован, а использоваться будет только им во вред, а другим устройств просто не досталось, и им пришлось установить софтовую версию.

Итак, у меня в руках последняя версия VMWare-образа и exe-файла Ревизора. Давайте же посмотрим, что внутри!

Зачитался я последнее время про Tarantool, интересно стало. Идея хорошая — код рядом с базой данных, хранимка в такой быстрой Redis-подобной среде.

И что-то задумался — мы вот сейчас используем активно на работе Golang, собственно, мысль пришла что на Go написано много всего, в т.ч. и встраиваемых баз. А что если сравнить, например, Go+LevelDB (собственно, можно было бы и любую другую) против Tarantool. Тестировал еще Go+RocksDB, но там оказалось все немного сложнее, а результат примерно тот же на небольших данных.

Тестировал простую задачу — HTTP сервер, при запросе — записать ключик в базу, достать его же по имени (без всяких проверок на race), отправить назад простенький JSON из этого value.

Сравнил: go+leveldb, tarantool, go+go-tarantool, nginx upstream tnt_pass

Об авторе. Питер Хинченс — бельгийский разработчик, писатель и бывший президент Фонда свободной информационной инфраструктуры, ассоциации, которая борется с софтверными патентами в Европе. Автор более 30 протоколов и распределённых систем, основатель свободного проекта ZeroMQ и проекта Edgenet по созданию полностью безопасной, анонимной глобальной P2P-сети, исполнительный директор и ведущий программист компании iMatrix. Автор книг «Культура и империя: цифровая революция», «Код психопата», «Масштабируемый Си» и др.

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

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

Я был изолированным и одиноким юношей. Немного аутистичным, наверное. Я думал только о работе, плавании, своих домашних животных, снова о работе. Мысль о том, что людям может нравиться моё общество, была странной. По крайней мере моя работа, казалось, имеет значение. Мы писали генераторы кода на Cobol. Я написал редактор кода, который нравился сотрудникам, потому что элегантно работал на всём. Я самостоятельно выучил Си, ассемблер 8086 и писал программы shareware. Так медленно прошли 90-е.

КДПВ

От переводчика:
Большинство моих знакомых для измерения времени в разного вида бенчмарках в С++ используют chrono или, в особо запущенных случаях, ctime. Но для бенчмаркинга гораздо полезнее замерять процессорное время. Недавно я наткнулся на статью о кроссплатформенном замере процессорного времени и решил поделиться ею тут, возможно несколько увеличив качество местных бенчмарков.

P.S. Когда в статье написано "сегодня" или "сейчас", имеется ввиду "на момент выхода статьи", то есть, если я не ошибаюсь, март 2012. Ни я, ни автор не гарантируем, что это до сих пор так.
P.P.S. На момент публикации оригинал недоступен, но хранится в кэше Яндекса

Функции API, позволяющие получить процессорное время, использованное процессом, отличаются в разных операционных системах: Windows, Linux, OSX, BSD, Solaris, а также прочих UNIX-подобных ОС. Эта статья предоставляет кросс-платформенную функцию, получающую процессорное время процесса и объясняет, какие функции поддерживает каждая ОС.

См. две другие статьи этой группы — Делаем многозадачность и Преемптивность: как отнять процессор.

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

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

Как я уже говорил, шедулер — это просто функция, которая отвечает на вопрос: какую нить и на сколько времени поставить на процессор.

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

Говоря о шедулере нельзя не сказать о приоритетах.

Приоритет — свойство нити (или процесса) влияющее на конкуренцию этой нити с другими нитями за процессор.

Приоритет обычно описывается парой <класс приоритета, значение приоритета внутри класса>.

Мы продолжаем готовиться к PG Day’16 и знакомить вас с интересными возможностями PostgreSQL.

В предыдущих постах этой серии я говорил о том, как читать вывод EXPLAIN и что означает каждая строка (операция/узел).

В заключительном посте я постараюсь объяснить, почему Постгрес выбирает «Операцию X», а не «Операцию Y».

Я стараюсь чередовать статьи про разработку ОС вообще и специфические для ОС Фантом статьи. Эта статья — общего плана. Хотя, конечно, я буду давать примеры именно из кода Фантома.

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

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

Шедулер — это функция, которая отвечает на вопрос «какой нити отдать процессор прямо сейчас». Всё. Простейший шедулер просто перебирает все нити (но, конечно, готовые к исполнению, не остановленные) по кругу (RR алгоритм). Реальный шедулер учитывает приоритеты, поведение нити (интерактивные получают больше, чем вычислительные), аффинити (на каком процессоре нить работала в прошлый раз) и т.п., при этом умеет сочетать несколько классов приоритетов. Типично это класс реального времени (если есть хотя бы одна нить этого класса — работает она), класс разделения времени и класс idle (получает процессор только если два предыдущих класса пустые, то есть в них нет нитей, готовых к исполнению).

На сём пока про шедулер закончим.

Перейдём к собственно подсистеме, которая умеет отнять процессор у одной нити и отдать его другой.

Бывало ли у вас так, что хотелось использовать какую-нибудь фичу из стандарта CSS, но вы этого не делали, потому что она поддерживается не всеми браузерами? Или ещё хуже: её поддерживают все браузеры, но поддержка глючная, противоречивая или вообще несовместимая? Наверняка вы с таким сталкивались, и поэтому рекомендую вам присмотреться к Houdini.

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

Но что конкретно кроется за этими обещаниями? Это хотя бы хорошая затея? И как всё вышесказанное поможет нам, разработчикам, создавать сайты сегодня и завтра?

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

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

Важнейшая экспертиза Яндекса — машинное обучение. Она выросла из потребностей поиска, для ранжирования в котором нами была разработана известная сейчас многим технология Матрикснет. В 2014 году Яндекс стал использовать свои знания в области ML вне собственных сервисов — появилась Yandex Data Factory. Это международное направление, которое решает сложные математические задачи для других компаний.

Один из его проектов — прогноз оттока игроков World of Tanks. Илья Трофимов рассказал слушателям Малого ШАДа не только о проекте с Wargaming, но и о том, что вообще такое машинное обучение и в каких задачах оно может помогать бизнесу. Слушатели — старшеклассники, интересующиеся математикой и компьютерными науками.



Сам Илья в 2007 году окончил физический факультет МГУ по специализации «теоретическая физика». В 2011 — Школу анализа данных по специальности «анализ данных». В Яндексе занимался применением машинного обучения для оптимизации показов рекламы, сейчас решает задачи по анализу больших объёмов данных в Yandex Data Factory. Читает лекции в ШАДе по теме «Машинное обучение на больших данных».

Усилия и деньги, вкладываемые в продвижение языка Go, часто приносят пользу и другим разработчикам. В конце прошлого года на сайте gopheracademy была опубликована очень удачная статья о семантическом версионировании. Том самом, которое используется в npm, начинается с домика ^ и все ломает. Под катом спрятан перевод, который поможет вам быстро осмотреть сад граблей версионирования и как сейчас принято им пользоваться. И немного примеров на Go. Передаем слово автору!

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

«Сказка ложь – да в ней намек…»

Посадил дед… хранилище. И выросло хранилище большое-пребольшое. Вот только толком не знал, как оно устроено. И затеял дед ревью. Позвал дед бабку, внучку, кота и мышку на семейный совет. И молвит такую тему: «Выросло у нас хранилище. Данные со всех систем стекаются, таблиц видимо-невидимо. Пользователи отчеты свои стряпают. Вроде бы все хорошо – жить да жить. Да только одна печаль – никто не знает, как оно устроено. Дисков требует видимо-невидимо – не напасешься! А тут еще пользователи ко мне ходить повадились с жалобами разными: то отчет зависает, то данные устаревшие. А то и совсем беда – приходим мы с отчетами к царю-батюшке, а цифры-то между собой не сходятся. Не ровен час – разгневается царь – не сносить тогда головы – ни мне, ни вам. Вот решил я вас собрать и посоветоваться: что делать-то будем?».

Как известно, в современных архитектурах x86(_64) и ARM виртуальная память процесса линейна и непрерывна, ибо, к счастью, прошли времена char near* и int huge*. Виртуальная память поделена на страницы, типичный размер которых 4 KiB, и по умолчанию они не отображены на физическую память (mapping), так что работать с ними не получится. Чтобы посмотреть текущие отображённые интервалы адресов у процесса, в Linux смотрим /proc/<pid>/maps, в OS X vmmap <pid>. У каждого интервала адресов есть три вида защиты: от исполнения, от записи и от чтения. Как видно, самый первый интервал, начинающийся с load address (соответствующий сегменту .text у ELF в Linux, __TEXT у Mach-O в OS X), доступен на чтение и исполнение — очень логично. Ещё можно увидеть, что стек по сути ничем не отличается от других интервалов, и можно быстро вычислить его размер, вычтя из конечного адреса начальный. Отображение страниц выполняется с помощью mmap/munmap, а защита меняется с помощью mprotect. Ещё существуют brk/sbrk, deprecated древние пережитки прошлого, которые изменяют размер одного-единственного интервала «данных» и в современных системах эмулируются mmap’ом.

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

• оптимально управляет уже выделенной памятью;
• значительно уменьшает количество обращений к ядру (ведь mmap / sbrk — это syscall);
• вообще абстрагирует программиста от виртуальной памяти, так что многие пользуются malloc’ом, вообще не подозревая о существовании страниц, таблиц трансляции и т. п.

Довольно теории! Будем щупать malloc на практике. Проведём три эксперимента. Работа будет возможна на POSIX-совместимых операционках, в частности была проверена работа на Linux и на OS X.

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

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

Сегодня мы поговорим про средние и медианные зарплаты, индекс социального неравенства Джини, отношения между богатыми и бедными (индекс Rich/Poor), непреодолимый разрыв доходов (эффект Матфея) и карьерный рост.

Создание REST API это нелегкая задача. Нет, серьезно! Если вы хотите написать API правильно, вам придется о многом подумать, решить, быть прагматиком, или API маньяком. REST это не только GET, POST, PUT и Delete. На практике, у вас могут быть взаимодействия между ресурсами, нужно перемещать ресурсы куда-то еще (к примеру внутри дерева), или вы захотите получить конкретное значение ресурса.

В данной статье собрано все, чему я научился реализуя различные API сервисы, используя для этих целей Symfony2, FOSRestBundle, NelmioApiDocBundle и Propel. К примеру сделаем API для работы с пользователями.

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

Данный пост приурочен к выходу Zend Framework 2 Form RFC, так как мне кажется, что его разработчики, по сути, сделали много того, что уже было сделано нами. Конечно же всем ясно, что Zend Framework 2 должен обладать прослойкой для работы с формами, который полностью учитывает особенности компонентов, поставляемых с фреймворком. Целью данного поста является попытка показать, что Symfony2 Forms прекрасно подходит под эти требования. Функционал, присущий Symfony2, может быть легко убран: код для обработки форм и все уровни абстракций полностью независимы. Привязать же поддержку особенностей компонентов Zend-а так же не составит труда.

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