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

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

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

Статистика, как известно, знает всё. В том числе ей прекрасно известны глобальные тенденции и движения, имеющие место в нашей цивилизации. Одна из таких тенденций – всеобщая и повальная урбанизация. Согласно прогнозам, двое из трех родившихся в ближайшие 30 лет будут жить в городах. Естественно, будут увеличиваться и сами города: к нынешним 500 «миллионникам» за 20 следующих лет прибавятся еще 200. Как эффективно управлять мегаполисом, как сделать его максимально удобным для проживания? Естественно, с помощью с цифровых технологий. В этом посте – рассказ об «умном городе», каким его представляет компания Intel.

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

Алекс, где и когда вы решили предложить STL как часть определения ANSI/ISO Стандарта C++?

В течение лета 1993 г., Эндрю Кёниг посещал Стэнфорд для преподавания курса C++. Я показал ему кое-что из наших материалов, и, я думаю, он был искренне захвачен увиденным. Он организовал приглашение для меня в качестве докладчика на ноябрьской встрече Комитета по Стандарту C++ в Сан-Хосе. Я прочитал доклад, обозначенный как «Наука программирования на C++». Моя речь была скорее теоретическая. Основная позиция заключалась в том, что существуют фундаментальные законы, которые связывают очень примитивные операции, такие как конструкторы, присваивание и равенство. C++ как язык не навязывает никаких ограничений. Вы можете определить собственный оператор равенства для того, чтобы выполнить умножение. Но равенство должно быть равенством, и оно должно быть рефлексивной операцией. A должно быть равно A. Оно должно быть симметричным. Если A равно B, то B равно A. A должно быть транзитивным. Обычные математические аксиомы. Равенство присуще другим операциям. Имеются аксиомы, связывающие конструктор и равенство. Если вы конструируете объект с копирующим конструктором из другого объекта, то два объекта должны быть равны. C++ не обязывает к этому, но это один из основных законов, которому мы должны подчиниться. Присваивание должно создавать одинаковые объекты. Т.о., я представил группу аксиом, которые связаны с этими основными операциями. Я немного говорил об аксиомах итераторов и показал некоторые обобщенные алгоритмы, обрабатывающие итераторы. Это была двухчасовая лекция и, я думаю, весьма сухая. Однако она была очень хорошо принята. В то время я не думал об использовании этой штуки в качестве части стандарта, т.к. обычно воспринималось, что это была некая продвинутая техника программирования, которая не стала бы широко использоваться в «реальном мире». Я думал, что у практичных людей не было никакого интереса к любой из этих работ.

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

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

Я довольно быстро доказал, что вероятность этого события равна нулю. Гордый собой, я запостил решение и ответ, ожидая плюсика в карму. Оказалось, однако, что авторский ответ совсем другой: 1 — 1/e. Забегая вперёд, скажу, что этот ответ неверен.

Неправильные авторские решения — довольно частое явление в интернет-головоломках. И я ни за что не стал бы писать этот пост, если бы автором задачи, а также её неверного решения, не был британский логик и алгебраист Чарльз Л. Доджсон, более известный под псевдонимом Льюис Кэрролл.

Уже некоторое время вверху моего сайта висит слоган:

Нет, я не работаю в Нью-Йорке, Вашингтоне или долине, и меня это полностью устраивает.

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

Я разработчик софта из Луисвилля, штат Кентукки, и я здесь до чертиков счастлив.

Мне часто задают вопрос: «Как ты находишь время?». Чаще всего речь идет об open source, иногда о книгах, изредка — о других вещах. Обычно я уклонялся от ответа чем-нибудь вроде: «Блин, не знаю, просто беру и нахожу». Но этот ответ не слишком полезен. Да и мне было интересно, смогу ли я справляться со временем еще лучше. Так что я немного порефлексировал, и вот как я нахожу время:

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



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

• Контрольный вопрос — ответ
• Уникальная ссылка на email
• Отсылка нового/действующего пароля на email
• SMS OTP (One-time password)

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

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

NUMA (Non-Uniform Memory Access — «Неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — технология совсем не новая. Я бы даже сказала, что совсем старая. То есть, в терминах музыкальных инструментов, это уже даже не баян, а, скорее, варган.
Но, несмотря на это, толковых статей, объясняющих, что это, а главное, как с этим эффективно работать, нет. Данный пост, исправляющий эту ситуацию, предназначен прежде всего для тех, кто ничего не знает про NUMA, но также содержит кое-что интересное и для знатоков-NUMизматов, а главное, он облегчает жизнь мне, инженеру Intel, так как отныне всех интересующихся NUMA русскоязычных разработчиков буду отсылать к нему.

Продолжение статьи Пола Грема о поиске идеи для стартапа. Первая и вторая части тут. Без лишних слов продолжаем:

Университет

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

В последние годы, когда спрос на C++ снова растёт, интересно заглянуть в недалёкое прошлое и вспомнить, как создавалась эта классическая платформа разработки. В данном вопросе безусловно содержательными являются книги Страуструпа, вроде «Дизайна и эволюции C++». Однако, не менее интересно услышать о языке от самых первых его последователей, а иногда и полноценных соавторов. Пожалуй, наиболее известным из них является наш (в общем-то :) соотечественник Алекс Степанов, автор Стандартной библиотеки шаблонов. Интервью, приводимое далее, было взято у Алекса в 1995-м году колумнистом журнала Dr.Dobbs Элом Стивенсом. Материал будет интересен как начинающим изучать C++, так и опытным пользователям языка.

Алекс, расскажите нам что-нибудь о вашем cтоль длительном интересе к обобщённому программированию.

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

Среди самых популярных вопросов, которые нам задают, безусловно, лидирует: «Как добавить деньги на карту?». В чем особенность предоплаченных карт Payoneer MasterCard и почему стоит узнать о них заранее, чтобы потом не было мучительно больно за бесцельно заказанную карту? В этом посте мы расскажем, как можно и как нельзя загрузить средства на карту Payoneer.

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

• Команда grep операционной системы Unix или аналогичные команды для поиска цепочек, которые можно встретить в Web-броузерах или системах форматирования текста. В таких системах РВ используются для описания шаблонов, которые пользователь ищет в файле. Различные поисковые системы преобразуют РВ либо в детерминированный конечный автомат (ДКА), либо недетерминированный конечный автомат (НКА) и применяют этот автомат к файлу, в котором производится поиск.
• Генераторы лексических анализаторов. Лексические анализаторы являются компонентом компилятора, они разбивают исходную программу на логические единицы (лексемы), которые могут состоять из одного или нескольких символов и имеют определенный смысл. Генератор лексических анализаторов получает формальные описания лексем, являющиеся по существу РВ, и создает ДКА, который распознает, какая из лексем появляется на его входе.
• РВ в языках программирования.

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

Данный пост является продолжением первой части перевода одной большой статьи Пола Грэма о том, как найти свою стартап-идею. Это не пошаговая инструкция, а скорее глубокое философское эссе Грема, основанное на его богатом опыте в качестве основателя YCombinator — самом успешном стартап-акселераторе. Продолжаем:

Сознание

Но как определить, есть ли путь «наружу» у идеи? Как понять, является ли это зачатком большой компании или всего лишь продуктом, обреченным на узкую нишу? Часто это не возможно сделать. Фаундеры AirBnb не осознавали в начале, на рынок какого масштаба они покусились. Изначально у них была более узкая идея. Они собирались позволить владельцам сдавать свое пространство во время выставок, конференций. Они не предвидели экспансию этой идеи; она сама себя навязывала постепенно. Все что они знали в начале, что на крючке какая-то рыба. Возможно, это столько же, сколько знали изначально Билл Гейтс и Марк Цукерберг.

Продолжаю серию обзоров образовательных курсов, начатую Darkus’ом здесь и здесь. С его же разрешения я воспользовался форматом описания.

Расскажу про четыре курса, прослушанных мной осенью 2012 года, на Coursera и edX. На самом деле, курсов я взял чуть больше, но что-то было в рамках самостоятельного просматривания архива оконченных курсов (Computer Science 101, Introduction to Databases), а что-то прекращено по личным обстоятельствам.
Итак, рассмотрим следующие курсы:

Coursera

1. Fundamentals of Programming
2. An Introduction to Interactive Programming in Python
3. Information Security and Risk Management in Context

edX

1. Introduction to Computer Science and Programming

Если вас интересуют предложенные курсы, добро пожаловать.

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

В чем ее суть?

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

К чему же приводит такая «доброта»?

Наверняка на хабре уже немало постов на эту тему. Тем не менее, я попытаюсь рассказать свою точку зрения на всё это…

Однажды я прочитал в интернете про троичную систему счисления и заинтересовался. Меня мучил вопрос, а нельзя использовать в основе компьютера симметричную троичную систему счисления (СС), и даже вдруг это увеличит производительность компьютера? Мне казалось, что это возможно, и я жаждал это проверить.

Информация:
Троичная система счисления — позиционная система счисления с целочисленным основанием, равным 3. Существует в двух вариантах: несимметричная и симметричная.
В несимметричной троичной системе счисления чаще применяются цифры {0,1,2}, а в симметричной троичной системе счисления знаки {−,0,+}, {−1,0,+1}.
У некоторых людей эта логика вызывает затруднения. Они говорят, например, приведите пример подобной логики в жизни.
Человек, немного подумавший над этой логикой поймет, что она более жизненна чем двоичная. Обычный пример троичной логики в жизни связан с постоянным током: ток движется в одну сторону, в другую сторону, его нет.

Молодые стартаперы часто мечтают о миллионе долларов кешем. Их часто даже не особо интересует то, что они делают (не важна конкретная идея), а интересует “срубить бабла по-быстрому и отвалить” (hit and run). Быстро сделать прототип, получить финансирование, что-то доделать на угасающем интересе, продать свою долю. Если быстро не получается (а дело-то сердцу не мило) стартап загибается, и молодой стартапер, может быть и не с первого раза, но превращается в старого.

Вот и мы в Alconost часто задумываемся: “Может, ну его, эти мутные стартапы и журавлей в небе? Может быть, реальный бизнес приносит больше счастья?”

Как раз об этом и рассуждает в своей статье Melanie Io.

Недавно вышла статья Пола Грэма о поиске идеи для стартапа. Грем — сам по себе культовая личность Кремниевой долины и уже только поэтому достоин внимания. Но на мой взгляд, эта статья одна из лучших в своем роде. Да, о Customer Development и Lean Startup сейчас не пишет разве что ленивый, но она отличается глубокой внутренней философией Грема и обобщает его богатый опыт в качестве основателя YCombinator, общающегося с тысячами стартаперов в год.
Статья очень длинная, поэтому я взял на себя смелость разбить ее на 5 частей, дабы никого не утомить. Поехали:

Лучший способ найти идею для стартапа — не думать о ней. Найдите проблему, и лучше — если она есть у вас самого.

Джереми Ховард — президент и «главный по науке» компании Kaggle, превратившей статистическое прогнозирование в спорт.

Peter Aldhous: Kaggle называет себя онлайн-биржей мозгов. Расскажите об этом.

Джереми Ховард: Это веб-сайт, на котором размещают конкурсы по статистическому прогнозированию. Мы провели много удивительных конкурсов. Например, разработка алгоритма оценки студенческих рефератов. Или вот недавно закончился конкурс на разработку системы обучения Microsoft Kinect жестам. Идея состояла в том, чтобы показать контроллеру жест один раз, а алгоритм должен обучиться распознавать такие жесты в будущем. Еще один конкурс — прогнозирование биологических свойств молекул при скрининге на возможные наркотические свойства.

Перевод статьи «The 4 UX Principles Microsoft Forgot That Doomed Windows 8» с сайта Usabilla.com.

При выборе будущего для Windows компания Microsoft сделала рискованную ставку на создание операционной системы, которая бы одинаково хорошо подошла и для планшетов, и для настольных компьютеров. Эта, казалось бы, весьма разумная стратегия была обречена на провал по нескольким причинам; по большому счету, все дело в том, что Microsoft забыла про необходимые основы.

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

Моя сегодняшняя история о том, как лихо просчиталась Microsoft — это всего лишь еще одна попытка показать, что случается с теми, кто нарушает основные принципы UX и бизнеса.