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

Недавно в городе Белвью (штат Вашингтон) прошла одна из самых больших конференций С++ разработчиков — CppCon 2014. В течение пяти дней ведущие программисты таких компаний как Microsoft, Google, Dropbox, Citrix, Embarcadero, Ubisoft, разработчики стандарта языка, создатели компиляторов С++ и члены комьюнити opensource-продуктов представляли свои доклады, делились мнениями о будущем языка, предлагали новые идеи. Ниже я представлю выборку наиболее понравившихся мне видео с небольшими комментариями от себя. Хочется отметить, что вся конференция просто пропитана духом возрождения С++ в виду распространения стандартов С++11\14, люди рассказывают почему выбор С++ оказался для них верным, как они успешно мигрировали с C#\Java\Objective-C на С++ и не пожалели об этом и т.д.

Удачного просмотра!

Докладчики из Dropbox рассказывают о том, как они разрабатывают на С++ кроссплатформенные мобильные приложения.
Когда-то у Дропбокса были классические мобильные приложения: Java-код для Android и Objetive-C для iOs. Однако со временем команде разработчиков надоело писать одно и то же по 2 раза на разных языках и они пришли к выводу о необходимости создания общей кодовой базы на С++. Со временем оказалось, что какую бы архитектуру не имело приложение (MVC, MVVM или что-нибудь другое), фактически весь код кроме вьюх может быть вынесен в С++. Действительно, на С++ можно реализовать модель данных, контроллеры, бизнес-логику, вспомогательные библиотеки для работы с сетью, базами данных, парсингу и т.д. Всё, что остаётся на долю Java и Objective-C — нарисовать «родные» для данной платформы кнопки\списки\лейбы на вьюхах. И этот подход существенно более прагматичен, чем писать всё дважды.

Первое видео более обзорное, второе более практическое:

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



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

Ранее habrahabr.ru/post/145309 мы сделали обзор подхода к универсальному искусственному интеллекту (ИИ). Но что такое универсальный ИИ? Чего именно недостает современным практическим системам ИИ, чтобы называться универсальными? Для большей конкретности обсуждения этого вопроса давайте рассмотрим его на примере машинного обучения, являющегося необходимым компонентом ИИ.

Открыв сегодня Хабр с утра, я обнаружил там статью в хабе Human Resources, «У Вас много денег? Тогда мы идем к Вам!»
Мне по работе не раз приходилось встречаться с ситуацией, описанной там, да, уверен, большинству читающих ситуация хорошо знакома.
Однако буквально на днях, бродя по Википедии, я нашел ответ на вопрос «Что же за phukinglyphuk приосходит с этим миром?», мучавшим меня на протяжении многих лет. Своей находкой я хочу поделиться здесь:

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

В любом обнаружении NoSQL баз данных кто-нибудь обязательно вспомнит о CAP-«теореме». Я не случайно пишу слово «теорема» в кавычках. CAP-«теорема» вовсе не теорема в математическом понимании этого слова. Это неформальное утверждение, сделанное Эриком Брюером в докладе на конференции Principles of Distributed Computing (PODC) в 2000 году. Эрик утверждал, что невозможно создать распределенное (состоящие из нескольких равноценных экземпляров — звеньев) веб-приложение, которое будет одновременно обладать тремя свойствами: согласованность (consistency), доступность(availability) и устойчивость к разделению(partition tolerance), сокращенно CAP. Неформальность утверждения заключается в том, что Брюер не дал определения этим трем понятиям.

Спустя два года Сет Гилберт и Ненси Линч опубликовали исследование, где дали определения понятиям CAP а также формализовали "отложенную согласованность" (Delayed Consistency), которую потом прозвали "согласованность в конечном счете" (Eventual Consistency) и доказали CAP-«теорему» в терминах указанных определений. Если вы еще не читали исследование, то это обязательно стоит сделать — lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

Эта «теорема» так бы и не была никому нужна, если бы её не взяли на вооружение маркетологи NoSQL.

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

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

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

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

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

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



Думаю, каждый из вас при очередном релизе задавался вопросами: «Точно ли мы отсылаем верный запрос?» или «Точно ли мы передали все необходимые параметры этому сервису?». Всем должно быть известно и о существовании негативных сценариев развития событий наравне с позитивными. Это знание должно активно порождать вопросы из серии «Что если..?». Что если сервис станет обрабатывать соединения с задержкой в 2 часа? Что если сервис ответит абракадабру вместо данных в формате json?

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

В первом посте об аналитической системе Sports.ru и Tribuna.com мы рассказали о том, как используем нашу инфраструктуру в повседневной жизни: наполняем контентом рекомендательную систему, наблюдаем за бизнес-метриками, ищем среди пользовательского контента бриллианты, находим ответы на вопросы “Как работает лучше?” и “Почему?”, нарезаем пользователей для почтовых рассылок и строим красивые отчеты о деятельности компании. Всю техническую часть повествования мы скромно спрятали за этой схемой:



Читатели законно потребовали продолжить повествование со смешными котиками, а olegbunin пригласил рассказать о всем, что было скрыто, на РИТ++. Что ж, изложим некоторые технические детали – в продолжении веселого поста.

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

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

25 и 26 января лаборатория проводит практический учебный курс по визуализации данных.



Весь прошлый год мы в лаборатории решали задачи по визуализации и придумывали новые форматы представления данных, я вела обычные и живые советы, читала лекции и проводила практические занятия со студентам МАИ, МГУ и участниками питерского «Дизайн-трека». Мы собрали огромное количество материала, которым не трепится поделиться, и подготовили двухдневный практический курс для тех, кто хочет перейти «на ты» со сложными данными и с головой погрузиться в тему.

На курсе участники учатся работать с данными с помощью дизайнерских инструментов. В первый день мы разберём хорошие и плохие примеры, по-новому взглянем на привычные таблицы, графики и диаграммы, познакомимся с необычными форматами — удавом, слоёным пирогом, мозаикой, домограммой. Во второй день Дима Тихвинский devgru, веб-технолог лаборатории, покажет как применить эти навыки при работе с библиотекой D3.js — самым современным и гибким инструментом интерактивных визуализаций. Все участники курса получат раздаточные материалы с кратким конспектом лекций:


Курс будет полезен дизайнерам, аналитикам, менеджерам, программистам, журналистам и редакторам онлайн-изданий. Предварительного знакомства с D3.js не требуется, опыт работы с HTML, CSS и JavaScript полезен, но не обязателен.

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

Для тех, кому одного курса на праздники мало и кто хочет больше, продолжаем нашу серию курсов от Школы анализа данных Яндекса. Сегодня подошла очередь курса «Дискретный анализ и теория вероятностей» – даже более фундаментального, чем предыдущий. Но без него нельзя представить ещё большую часть современной обработки данных.

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



Читает курс Андрей Райгородский. Доктор физико-математических наук. Профессор кафедры математической статистики и случайных процессов механико-математического факультета МГУ им. М. В. Ломоносова. Заведующий кафедрой Дискретной математики ФИВТ МФТИ. Профессор и научный руководитель бакалавриата кафедры «Анализ данных» факультета инноваций и высоких технологий МФТИ. Руководитель отдела теоретических и прикладных исследований компании «Яндекс». (Ещё больше можно узнать в статье о нём на Википедии).

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

Сегодня — о самом важном. Современный анализ данных без него представить невозможно. В рамках курса рассматриваются основные задачи обучения по прецедентам: классификация, кластеризация, регрессия, понижение размерности. Изучаются методы их решения, как классические, так и новые, созданные за последние 10–15 лет. Упор делается на глубокое понимание математических основ, взаимосвязей, достоинств и ограничений рассматриваемых методов. Отдельные теоремы приводятся с доказательствами.



Читает курс лекций Константин Вячеславович Воронцов, старший научный сотрудник Вычислительного центра РАН. Заместитель директора по науке ЗАО «Форексис». Заместитель заведующего кафедрой «Интеллектуальные системы» ФУПМ МФТИ. Доцент кафедры «Математические методы прогнозирования» ВМиК МГУ. Эксперт компании «Яндекс». Доктор физико-математических наук.

Photon – масштабируемая, отказоустойчивая и географически распределенная система обработки потоковых данных в режиме реального времени. Система является внутренним продуктом Google и используется в Google Advertising System. Research paper [5], описывающие базовые принципы и архитектуру Photon, был представлен на научной конференции ACM SIGMOD в 2013 году.

В paper [5] заявлено, что пиковая нагрузка на систему может составлять миллионы событий в минуту со средней end-to-end задержкой менее 10 секунд.
* 'Скорость света' в заголовке — наглая ложь гипербола.

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

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

Всего лишь рассказ о 5-ти, по-моему, интересных книгах.

Привет, {{habrauser}}.

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

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

Привет, я занимаюсь фронтенд разработкой, и как-то так сложилось, что в своей повседневной работе активно использую vim.

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

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

Как ни странно — в статье много картинок ;)