Привет, Хабрахабр!

Около года назад я написал свой предыдущий пост на Хабре Amazon глазами инсайдера. Я трижды проходил практику в компании Амазон и, тут нечего скрывать, привязался к этой компании, принял многие ее принципы, и многому научился. Причем увидел я компанию с разных сторон, так как довелось поработать и в Amazon Retail и в Kindle, и в Сиэтле и в Калифорнии. Однако моей целью, начиная со второго курса, была практика в Гугле. Поэтому, когда меня наконец пригласили на интервью, и по его результатам позвали в Mountain View на практику в качестве Software Engineer, отказаться я не смел. Провел я там три месяца, работая в команде Gmail Spam & Abuse. Поневоле и бессознательно, я сравнивал жизнь и работу в Гугле с Амазоном, о чем и хочу поделиться.

Дисклеймер: в предыдущей статье я рассказывал обо всем как есть без сравнений. Это отчасти потому, что про внутреннюю культуру Амазон мало что известно. Про Гугл же, напротив, знают все. Рассказать о Гугле «с чистого листа» не получится. Поэтому здесь приведены мои сугубо личные наблюдения и сравнения. Надеюсь, ничьих чувств не задену.

Статья является вольным переводом The Flaw Lurking In Every Deep Neural Net.

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

В статье "Интригующие свойства нейронных сетей" за авторством Christian Szegedy, Wojciech Zaremba, Ilya Sutskever, Joan Bruna, Dumitru Erhan, Ian Goodfellow and Rob Fergus, команды, включающей авторов из проекта Google по глубокому обучению, кратко описываются два открытия в поведении нейронных сетей, противоречащие тому, что мы думали прежде. И одно из них, честно говоря, поражает.

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

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

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

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

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

Сегодня в Беларуси 3,29 миллиона пользователей*, 70 тысяч сайтов, 35 тысяч доменов в зоне .BY, 3 тысячи интернет-магазинов, порядка 50 интернет-провайдеров и 30 хостинг-провайдеров**. Кто из них и в чем был первым на просторах Байнета?

Найти белоруса, которому посчастливилось первым попасть в Интернет, сегодня, пожалуй, затруднительно. Известно лишь, что доступ к электронной почте белорусы получили в 1991 году через узел сети Internet/Relcom.

Первым официальным интернет-провайдером стала компания «Соло» (1991 год). Но еще порядка пяти-семи лет доступ в Интернет оставался уделом избранным. По воспоминаниям очевидцев, даже в 1998 году стоимость часа доступа в Интернет составляла 3 доллара США.

Доменная зона .BY была зарегистрирована предприятием «Открытый контакт» в мае 1994 года. Летом 1995 года в Беларуси появился веб – то есть, Интернет в том виде, в котором мы привыкли видеть его через окно браузера. В последующие два года в Байнете начали открываться первые сайты на белорусских доменах.

Qt является одним из самых популярных и удобных фреймворков для разработки, и это вполне заслуженно. Когда нашей компании пришёл заказ на небольшое клиент-серверное приложение, мы ни минуты не сомневались в выборе инструментария. Приложение должно было работать на Windows и Linux, впоследствии к списку платформ добавился и Android. Приложение является сетевым, решает довольно простенькую задачу, и хранит все свои данные на сервере MySQL.
И тут начала вырисовываться проблема: как запрячь в одну упряжку Qt-приложение, Android, да ещё и заставить их общаться с MySQL? Решению этой достаточно нетривиальной задачи и посвящена эта статья. В качестве примера напишем небольшое приложение, которое считывает строки из таблицы MySQL и выводит их в табличное поле на форме.

Наверняка многие уже слышали о подходе FRP для организации асинхронного кода. На хабре уже писали об FRP (Реактивное программирование в Haskell, FRP на Bacon.js) и есть хорошие доклады на эту тему (Программировние UI с помощью FRP и Bacon.js, Functional Reactive Programming & ClojureScript, О Bacon.js от Juha Paananen — автора бекона)

Если коротко, FRP это подход похожий на Promise, но с неограниченным количеством возвращаемых значений, и бОльшим количеством методов для комбинирования / модифицирования потоков событий. Другими словами, если Promise позволяют работать со значением, которого у вас еще нет, так, будто оно у вас уже есть, то FRP позволяет работать со значением, меняющимся во времени, так, будто оно не меняется.

Вот что это дает по сравнению с обратными вызовами:

1) Поток событий (Event stream) и значение меняющаяся во времени (Property / Behavior) становятся объектами первого класса. Это значит что их можно передавать в функции и возвращать из функций.

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

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

К примеру можно написать функцию, возвращающую поток перетаскиваний (drag). В качестве параметров она будет принимать 3 потока — начало перетаскивания, движение, конец перетаскивания. Дальше можно передать в эту функцию: либо потоки для соответствующих событий мыши (mousedown, mousemove, mouseup), либо для touch событий (touchstart, touchmove, touchend). Сама же функция не будет ничего знать об источниках событий, а будет работать только с абстрактными потоками. Пример реализации на Bacon.

2) Явный state

Второе большое преимущество FRP это явное управление состоянием. Как известно, state — один из самых главных источников сложности программ, поэтому грамотное управление им позволяет писать более надежные и простые в поддержке программы. Отличный доклад от Рича Хикки о сложности (complexity) «Simple Made Easy».

FRP позволяет писать бОльшую часть кода на «чистых функциях» и управлять потоком данных (dataflow) явно (с помощью потоков событий), а состояния хранить тоже явно в Property.

impress.js — популярный фреймворк предназначенный для создания неординарных, искрящихся профессиональным блеском презентаций, которые демонстрируются просто в браузере^*.

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

3D трансформации между слайдами делают игру.

В предыдущей статье «Почему люди не растут: чем больше вариантов роста, тем хуже», мы договорились продолжить препарирование этой темы и перейти к ответу на вопрос «А как все-таки расти?»

Особенно, видимо, вопрос зацепил тех, кто сейчас работает больше всех и начинает что-то подозревать…

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

История 1: не пофигическая

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



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

Моя схема получения первой менеджерской позиции – «Карьерный лифт»: мой менеджер стал директором новой компании и позвал меня на позицию руководителя отдела тестирования ПО. Я учился на 4 курсе института (первая вышка), стационар, 22 года.

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

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



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

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

Можно выделить ряд чисто «технических» или даже «механических» проблем с принятием решений: это, так сказать, особенности устройства нашего мозга, который пытается уберечь нас от проблем, связанных с изменением состояния. Сейчас — все более-менее понятно, контролируемо, и поэтому мозгу хорошо, а как будет в новом состоянии — непонятно, поэтому плохо. Одна из базовых функций нашего мозга — беречь нас от непонятного, чтобы не стало хуже.

Данное руководство – серия считающихся классическими постов блога человека с ником pmarca, а в жизни – Марка Андреессена, создателя браузера Mozaic, из которого вырос Netscape, а затем и Mozilla.
Ссылки специально даются на старые версии сайтов, современные статьям, сохранённые в интернет-архиве.

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

Мой опыт в данной области собран при работе в трёх компаниях, в которых я был со-основателем: Netscape, продана America Online в 1998 за $4.2 миллиарда; Opsware (бывш. Loudcloud), софтовая компания с капитализацией порядка $1 миллиарда; Ning, интернет-компания, предоставляющая платформу для социальных сетей.

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

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

Привет, Хабр!
Ничего не писал со времен своей первой статьи, решил, что пора это исправить.

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

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

Я старался покрыть максимальное количество разных топиков, особенно тех, что спрашивают на собеседованиях. Я старался воздерживаться от domain-specific литературы: профессионалы и так знают. Все картинки содержат ссылки на амазон.

А какие книжки нравятся вам?
Также в комментах можете писать, на какие темы вам были бы интересны посты.

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

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

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

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



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

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

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

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

Эпиграф от Milfgard



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

Предыдущие части

Часть 1. Unboxing VisuMax — фемто-лазера для коррекции зрения
Часть 2. Сколько мегабит/с можно пропустить через зрительный нерв и какое разрешение у сетчатки? Немного теории
Часть 3. Знакомьтесь — лазер по имени Amaris. Переезды и первое пробуждение VisuMax
Часть 4.1 Возвращаем зрение. От очков до эксимерного лазера

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


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


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


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

data Maybe a = Nothing | Just a

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

31 августа 2012 года японский математик Cинъити Мотидзуки опубликовал в интернете четыре статьи.

Заголовки были непостижимы. Объём был пугающим: 512 страниц в сумме. Посыл был дерзким: он заявил, что доказал abc-гипотезу, знаменитую, соблазнительно лёгкую числовую теорию, которая десятилетиями заводила математиков в тупик.

Затем Мотидзуки просто ушёл. Он не отправил свою работу в Annals of Mathematics. Он не оставил сообщение ни на одном сетевом форуме, которые часто посещают математики со всего мира. Он просто опубликовал статьи и ждал.

Два дня спустя, Джордан Элленберг, профессор математики в Висконсинского университета в Мадисоне, получил почтовое оповещение от Google Scholar, сервиса, который сканирует интернет в поисках статей по указанным темам. Второго сентября Google Scholar отправил ему статьи Мотидзуки: «Это может заинтересовать вас».

«А я такой: „Да, Гугл, мне это как бы интересно!“» – вспоминает Элленберг, – «Я запостил их в Фэйсбуке и в моём блоге, с пометкой: „Между прочим, похоже, что Мотидзуки доказал abc-гипотезу“».

Интернет взорвался. В течение дней даже далёкие от математики СМИ подхватили историю. «Решена сложнейшая в мире математическая теория», – объявила Telegraph. «Возможный прорыв в abc-гипотезе», – немного скромнее писала New York Times.

На математическом форуме MathOverflow математики со всего мира стали оспаривать и обсуждать заявление Мотидзуки. Вопрос, который быстро стал самым популярным на форуме был прост: «Кто-нибудь может объяснить философию его работы и прокомментировать почему она может пролить свет на abc-гипотезу?» – спросил Энди Путман, ассистент профессора в Университете Райса. Или, если перефразировать: «Я ничего не понял. Кто-нибудь понял?»

Проблема, с которой столкнулись многие математики, сбежавшиеся к сайту Мотидзуки, была в том, что доказательство было невозможно прочесть. Первая статья под заголовком «Интер-универсальная теория Тейхмюллера 1: Построение театров Ходжа», начинается с утверждения, что цель работы в «разработке арифметической версии теории Тейхмюллера для цифровых полей ограниченных эллиптической кривой… с помощью применения теории полуграфов анабелиоидов, фробениоидов, эталь тета-функций и логарифмических оболочек».

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

«Смотря на неё, ты чувствуешь будто читаешь статью из будущего или далёкого космоса», – написал Элленберг в своём блоге.

«Она очень, очень странная», – говорит профессор Колумбийского университета Йохан де Йонг, работающий в близких сферах математики.

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

Как профессор Мун Дучин из университета Тафтса выразила это: «Он воистину создал свой собственный мир».

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

— Ты все еще не бросил свое Ruby? – взволновано спросила Татьяна. – Ты же знаешь, что сейчас на программистов облавы чуть ли не каждый день? Сергей, ты действительно хочешь, чтобы тебя отправили в ЗАТО?

Сергей понуро молчал.

После Большой свободной революции и полной победы антикопирастов, ЗАТО – закрытые абстракто-творческие общества появились по всей стране.



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

Несмотря на предсказанный рост производительности, качество художественных произведений снизилось, поставив под угрозу интересы главной фигуры любого творческого процесса – ПОТРЕБИТЕЛЯ. После длительных дебатов в парламенте, правительство было вынуждено пойти на крайние меры – была введена система «мотивирующих воздействий». Если созданное произведение не набирало норму лайков – всей бригаде урезали паек, а систематический саботаж творческой выработки мог привести к переводу в лесорубы.

От переводчика: Хоть посыл статьи Najaf Ali, переведённой ниже, и носит слегка рекламный оттенок («оставьте криптографию нам, экспертам»), но описанные в ней примеры показались мне довольно интересными и заслуживающими внимания.
Кроме того, никогда не будет лишним повторить прописную истину: не придумывайте свою крипто-защиту. И эта статья отлично иллюстрирует почему.