Привет. Как и планировалось в прошлом посте об ограниченных машинах Больцмана, в этом будет рассмотрено применение RBM для предобучения обыкновенной многослойной сети прямого распространения. Такая сеть обычно обучается алгоритмом обратного распространения ошибки, который зависит от многих параметров, и пока не существует точного алгоритма выбора этих самых параметров обучения, как и оптимальной архитектуры сети. Разработано множество эвристик, позволяющих сократить пространство поиска, а также методик оценки качества выбранных параметров (например, кросс-валидация). Мало того, оказывается, и сам алгоритм обратного распространения не так уж хорош. Хотя Румельхарт, Хинтон и Вильямс показали сходимость алгоритма обратного распространения (тут еще более математическое доказательство сходимости), но есть небольшой нюанс: алгоритм сходится при бесконечно малых изменениях весов (т.е. при скорости обучения, стремящейся к нулю). И даже это не все. Как правило, этим алгоритмом обучают небольшие сети с одним или двумя скрытыми слоями из-за того, что эффект обучения не доходит до дальних слоев. Далее мы поговорим подробнее о том, почему же не доходит, и применим технику инициализации весов с помощью обученной RBM, которую разработал Джеффри Хинтон.

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

Этим вопросами я заинтересовался года два назад. Как оказалось, задача максимум решаема, а мечта о свободном времяпрепровождении до 60 лет вполне реальна. Более того, на Западе популярен подход «asset allocation», который позволяет тратить на вопрос инвестирования до часа в год и иметь на выходе результаты, сравнимые с профессиональными инвесторами. Причем необходимо всего лишь крепко разобраться в базовой информации и не погружаться в пучины технического и фундаментального анализа.

Как оказалось, этот подход доступен и в нашей стране, в нашей действительности. Результатами исследования я хочу поделиться с вами. Да, пока только исследования… Через 30 лет расскажу о результатах практики.

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

P. S. Почему «Сделай сам»? Потому что вы сами можете накопить себе неплохие деньги — вы, а не банки, пенсионный фонд или финансовые компании!
UPD. P. P. S. Мои размышления базируются на статье Сергея Спирина «Портфель лежебоки, или как за 12 лет увеличить капитал в 118 раз». Собственно, от него я и узнал про эту инвестиционную стратегию. Я — IT-шник, а не финансист. Посему за подробностями от эксперта — к нему!

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

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

Так вот с чем мы столкнулись и что поняли.

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



А знаете почему?

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

Это с моей точки зрения вполне объяснимо. Кто до недавнего времени был основным поставщиком траффика на любой сайт? Конечно поисковики. И в голову многих вебмастеров вбит стандарт подачи контента под поисковые машины. Ну вы сами их знаете.

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

Но давайте по порядку:

Итак, как мыслит вебмастер, например контентного сайта? Ага, я написал хорошую статью, все по SEO правильно, у меня на сайте есть социальные кнопки в начале (это хороший тон) и в конце статьи (что тоже неплохо). Посетитель прочитает, нажмет соцкнопку, зарепостит статью себе на стену и вот он социальный траффик у меня в кармане. Это работает, но слабо.

Почему? Потому что вебмастер думает как все. Хотите больше социального траффика – думайте иначе. Думайте на шаг вперед.

Пытайтесь заинтересовать не столько ваших посетителей сколько их друзей в социальных сетях. Ведь именно их вы хотите привлечь на свой сайт с помощью SMO.

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

… или что такое на самом деле 'raid edition' для жёстких дисков

Немного теории

Существуют две стратегии поведения НЖМД при обнаружении ошибки:

• standalone/desktop — пытаться прочитать до последнего. Это ощущается как «тормозящий винт», который всё-таки работает, если это единичный сбой, то «затупило, но прошло», плюс характерный перестук перекалибрующихся головок.
• raid — отваливаться тут же. Это ощущается как «внезапно была ошибка диска но потом mhdd и т.д. НИЧЕГО НЕ НАШЁЛ ЧТО МНЕ ДЕЛАТЬ».

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

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

Расшифровка названия

Возможность управления поведением диска при ошибках называется очень и очень путанно: SCT ERC. Это расшифровывается как SCT Error Recovery Control. SCT в свою очередь название общего протокола SMART Command Transport. SMART в свою очередь расшифровывается как Self-Monitoring, Analysis and Reporting Technology, таким образом, полная расшифровка SCT ERC звучит так: Self-Monitoring, Analysis and Reporting Technology Command Transport Error Recovery Control (выдохнули).

Всем привет!

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

Недавно случайно наткнулся на ютубе на фильм с Брайаном Грином «Тайны мироздания» и удивился, что у видео так мало просмотров.

Не сказать, чтобы такая подача материала мне очень нравилась, но все равно, местами довольно интересно :) Может быть, будет интересно не только мне.

Сами видео под катом.

Часть 1.

Краткий анализ существующих подходов к сильному ИИ.

Когнитивные архитектуры.

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

От универсального интеллекта к сильному ИИ. Перспективы создания сильного искусственного интеллекта

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

Все менеджеры пакетов в Unix имеют определенные недостатки и большинство Linux-дистрибутивов пытаются по-разному эти недостатки обойти. В этом посте я расскажу про Homebrew — новый менеджер пакетов, нацеленный на простоту использования.

До Homebrew было несколько различных попыток создать эффективные пакетные менеджеры для OS X. Две наиболее популярные вылились в итоге в Fink и Macports, но у каждой из них все равно есть свои острые углы. В частности, в обоих создание своих пакетов или портов является черезчур сложным.

В Homebrew создавать новые пакеты и работать с ними проще пареной репы. Давайте посмотрим.

При разработке одного проекта встала задача – определить по IP-адресу посетителя его страну и город, на русском языке. Поиск готового решения оказался безуспешным – русскоязычные базы стран можно найти (например, wipmania.com), но баз городов нет. Помощь пришла из-за границы, в лице англоязычного maxmind.com. База была приведена к нормальному состоянию (MySQL) и частично переведена на русский язык с помощью нескольких справочников (~6,000 названий, с учетом городов-тезок ~15,500).   Результат этой работы доступен для свободного скачивания.

Привет!
Я занимаюсь вопросами инвестирования уже 8 лет, и из которых последние 2 года – возможностями быстрого, простого и массового инвестирования в стартапы. Проще говоря, моя задача – получить платформу, где можно нажать на кнопку «заплатить 1000 рублей» — и эта 1000 рублей сразу же станет полноценной инвестицией со всей необходимой юридической обвязкой.

Раньше я уже писал, что единственный проверенный до настоящего момента способ – это открытие ОАО или ЗАО на стартап. Это требует кучи времени, ресурсов и не даёт запускать маленькие проекты. Сейчас нашелся метод гораздо, гораздо проще. Про него я и расскажу ниже.

Типичная работа сотрудника глазами самого сотрудника и глазами отдела безопасности

Первые две части данной темы были посвящены преимущественно веб-ресурсам. Эта часть более общая и не имеет как таковой привязки к профилю проекта (все же за исключением пары пунктов). Она освещает возможные, популярные векторы атак на сотрудников и на техническое обеспечение офиса компании (p.s. изначально хотел написать про security-тестирование, но решил «перепрыгнуть» эту тему в силу разных причин).

Автор не несет никакой ответственности за незаконное использование описанных методик и/или инструментов.

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

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

Erlang on Xen позволяет запускать приложения Erlang без операционной системы, на голом гипервизоре Xen. От момента запуска VM до начала работы приложения проходит всего 50 миллисекунд — в 100-1000 раз меньше, чем нужно для запуска привычного сочетания Linux+Erlang, а размер образа машины составляет лишь около 1 Мб. Это позволяет добиться практически мгновенного масштабирования, вплоть до запуска экземпляра VM после того, как пришёл запрос от клиента.

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

Лежащая в основе Erlang on Xen виртуальная машина Ling показывает производительность, сравнимую со стандартной для Erlang VM BEAM (Bogdan/Björn’s Erlang Abstract Machine).

Введение

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

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

При управлении конфигурацией при помощи Chef, особенно в самом начале использования, возникает необходимость на свеже-введённой в работу системе установить необходимые наборы пакетов. Например, если привычка диктует что на системе должен быть htop и mc. Добавим сложности, нам надо что бы пакеты были из конкретного репозитария. Как можно решить такую задачу средствами Chef?

Способов хостинга mercurial репозиториев достаточно, но я сочинил именно такой вариант по следующим причинам:

1. nginx: мало кушает, быстро работает — скорость
2. supervisor: мониторит процесс, перезапускает если что — надёжность
3. gunicorn: wsgi, большие возможности по настройке — эффективность

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

Если вас заинтересовала тема, то конкретные инструкции и конфиги — под катом.

Многие знают что для подстановки значений в конфигурационные файлы Spring можно использовать context:property-placeholder.

<context:property-placeholder location="classpath*:/prop/*.properties"/> <!-- здесь будут искаться property файлы -->

<bean id="mongoTemplate" class="org.springframework.data.mongodb.core.MongoTemplate">
    <constructor-arg ref="mongo"/>
    <constructor-arg name="databaseName" value="${mongo.db}"/> <!-- здесь будет подставлено значение из найденных property -->
</bean>

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

Когда передо мной встала задача, в зависимости от окружения (dev, prod, load-test), изменить логику развертывания — я искренне попытался использовать старый проверенный способ через property.

Потапов, А. С. «Искусственный интеллект и универсальное мышление».

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