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


Мы впервые публикуем эту лекцию вместе с расшифровкой. Начнём с первой части. Под катом вы найдёте текст и часть слайдов.

Задача: на входе сигналы с клавиатуры (keyup, keydown) — на выходе буквы и слова декодированные по азбуке Морзе. О том, как декларативно решить данную задачу используя FRP подход, в частности Rx.js — ниже под катом. (Зачем? Because we can)

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Data Science of the Facebook World".
Выражаю огромную благодарность Кириллу Гузенко за помощь в переводе.
alizar написал краткую заметку об этой статье и описанном в ней функционале Wolfram|Alpha и Wolfram Language. В нашем блоге мы приводим её полный перевод.

---

Миллионы человек в настоящее время пользуются нашим приложением "Wolfram|Alpha персональная аналитика для Facebook". И, как часть нашего последнего обновления, в дополнение к сбору некоторых анонимных статистических данных, мы запустили программу «донорства данных», позволяющую людям поделиться с нами подробными данными, которые мы используем для научно-исследовательских целей.

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

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

Мне всегда были интересны люди и их жизненные пути. Но у меня никогда не получалось объединить это с моими научными интересами. До этого момента. Последние несколько недель прошли весьма захватывающе в наблюдении тех результатов, которые мы получили. Одни были ожидаемыми, а другие были настолько непредсказуемыми, что я никогда бы и не предположил ничего подобного. И всё это напоминало о феноменах из моего труда A New Kind of Science (Новый вид науки).

Так как же выглядят данные? Ниже приведены социальные сети несколько доноров данных — группы друзей разбиты по цвету (любой может найти свою собственную сеть, используя Wolfram|Alpha или функцию SocialMediaData в Mathematica (в последней версии Wolfram Language эта функция поддерживает работу с Facebook, GooglePlus, Instagram, LinkedIn, Twitter — прим. ред.)).

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

В этой статье речь пойдет о самом простом в реализации алгоритме генерации «идеального» лабиринта и его применении для поиска пути.

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

Заинтересовавшихся — прошу под кат.

Вот вам анекдот из конца 90-ых. Я (Dave Baggett) был одним из двух программистов (вместе с Andy Gavin), разрабатывающих Crash Bandicoot для PlayStation 1.



Оперативная память была главной проблемой даже в те времена. У PS1 было всего 2MB RAM, и нам приходилось совершать безумные вещи, чтобы уместить в них игру. У нас были уровни, содержащие более 10MB чистых данных, и эти 10 мегабайт должны были постранично загружаться и выгружаться в память динамически, без каких-либо видимых задержек для игрока, при фреймрейте в 30 кадров в секунду.

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

И тут-то меня ждало разочарование: я не был способен написать ничего кроме hello world-a. Т.е. я примерно представлял себе, как написать какую-нибудь консольную утилиту типа find или вроде того, — но первая же встреча с IO разрушала все мои представления. Библиотек для Haskell вроде бы много, а документации по ним почти совсем нету. Примеров решения типовых задач тоже очень мало.

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

Думаю, многие новички столкнулись с проблемой отсутствия практики в Haskell. Писать что-то совсем уж без интерфейса как-то не интересно, а сделать desktop- или web-приложение для начинающего хаскелиста довольно сложно. И в этой статье я собираюсь предложить простой пример, как написать сервер веб-приложения на Haskell специально для тех, кто хочет попрактиковаться в Haskell, но не знает, с какой стороны к нему подойти.

Для самых нетерпеливых: исходники здесь.

Примечание переводчика: Представленный ниже материал содержит значительное количество технических терминов, при переводе которых могут возникнуть неточности. Если вы заметили опечатку, ошибку или неточность перевода — напишите нам, и мы оперативно всё исправим.

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



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

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

1. Интро. Личное

Я готовлюсь к языковому экзамену IELTS (International English Language Testing System) — пожалуй, самому популярному
тесту на знание английского. Если хочется эмигрировать, найти работу в международной компании — диплом IELTS очень пригодится. Шкала оценок — от 0 (от испытуемого не удалось получить даже внятного мычания) до 9 (экcперт — испытуемый чертовски хорош и может устроиться даже редактором лондонской газеты).

Для учебы, например, в США, нужно не менее 6.5 баллов (бывает и 6, но не часто), для работы — 7 и выше. А для эмиграции, допустим, в Канаду — чем выше оценка, тем лучше. Мой прогнозируемый балл перед сдачей теста — 5.5. Значит, что я могу читать газеты, смотреть кино, вести беседы в знакомых ситуациях, писать ответы на письма. Но для работы в центральном офисе Гугла явно недостаточно.

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

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

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

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

Дисклеймер: некоторые описанные в статье решения могут вызывать фейспалм.

2011 год. С чего все началось

В 2011 году мы были маленькой питерской веб-студией из 4 человек. Тимлид/сеошник, программист (вернее считал себя программистом), дизайнер и менеджер по продажам. На тот момент тимлид и программист занимались сайтами уже 3 года, но особых успехов на этом поприще не достигли. Хотя мы имели уже несколько постоянных клиентов на продвижении и обслуживании, но львиную долю дохода съедали налоги, аренда офиса и прочие расходы. Оставшихся копеек на четырех человек явно не хватало. Хроническое безденежье и отсутствие перспектив угнетали. Дизайнер уже навострил лыжи, да и остальные члены команды едва держались. Вот в такой обстановке и пришла в голову потрясающая по наивности мысль: «чего это мы все для всяких дядь делаем проекты, а давайте свое что-нибудь сделаем, например, игру браузерную и запилим её во вконтакте». Все, кроме дизайнера, восприняли идею с воодушевлением.

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


Уязвимость рекурсивных алгоритмов навигации муравья: спираль смерти

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

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

React.js позволяет очень эффективно и быстро работать с DOM-ом, активно развивается и с каждым днем набирает все больше популярности. Недавно открыл для себя концепцию реактивного программирования, в частности, не менее популярную библиотеку Rx.js. Данная библиотека выводит на новый уровень работу с событиями и асинхронным кодом, которого в UI логике javascript приложений предостаточно. Пришла идея объединить мощь данных библиотек в одно целое и посмотреть что из этого выйдет. В этой статье вы узнаете о том как удалось подружить Rx.js и React.js.

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

Сегодня хочу поделиться с Вами двумя задачами с этих семинаров.

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

Задача 2. На окружности даны n дуг (отрезков), нужно выбрать максимальное по размеру подмножество непересекающихся.

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

На игру мы потратили 1 год и 3 месяца, ниже я подробно распишу, куда ушло это время.

Предыстория

Все началось с того, что мы с друзьями решили сделать совместный проект (конечно, с друзьями, типичная ситуация). Нас было 4 человека, все «айтишники», ни один из нас никогда не имел дело с разработкой игр, это был для нас темный лес, очень темный.

Диалог был примерно такой:
— Может, игру начнем делать?
— Давайте, почему бы не попробовать?
— А о чем игра то будет?

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

— Шутеров — куча, танки — есть, самолеты — есть, гонки — есть, что же тогда делать?
— Лодок нет.

А ведь и правда, никто на тот момент не мог назвать ни одной игры с использованием водного вида транспорта. «Окей, сделаем простенькую игру, чтобы научиться. Вода и лодочки, что может быть проще?» — подумали мы, и собрались искать движок, на основе которого могли бы сделать игру.

Никто из нас даже не думал о 2D игре, сразу все представляли 3D — «инновации» ведь.

От переводчика: поприще переводчика для меня ново, по этому прошу вас не судить строго.

Когда-то, читав Принципы Объектно-ориентированного JavaScript за авторством Nicholas Zakas, я наткнулся на совет об использовании Object.create(), для создания объектов унаследованных от null. Такой объект не унаследует Object.prototype и, соответственно, не будет иметь его, Object.prototype, методов. Zakaz предположил, что это может быть использовано для создания безопасного объекта «cache». Мне очень понравилась эта идея, но в соответствии с MDN (Mozilla Developer Network), Object.create() не поддерживается до IE9, что делает этот метод более требовательным при использовании в браузере. Но в Node.js, на сервере, этот метод поддерживается полностью.

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

Почему Single Div?

В мае 2013 года я присутствовала на CSSConf и услышала, как Лиа Веру говорит об укрощении свойства border-radius. Это было поучительно и позволило мне понять о CSS то, чего я раньше не понимала. Это напомнило мне времена, когда я изучала изящные искусства, когда я постоянно стремилась повысить свой профессиональный уровень. Мой уровень владения CSS можно назвать средним, поэтому я бросила себе вызов, чтобы узнать все, что я смогу, исследуя и экспериментируя со свойствами

Но почему именно один DIV?

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

Я решила запустить проект a.singlediv.com, где намеревалась каждые несколько дней размещать нечто новенькое, созданное с помощью CSS. Я поставила перед собой ограничение использовать только один DIV.

На сегодняшний день практически каждый третий взрослый, тем или иным образом подключен к облакам. Наш Gmail синхронизирован со смартфоном, ну или же фотографии залиты на Dropbox, доступны 24 часа в сутки. Не мне рассказывать, что в современном обществе как большие, так и маленькие компании не отстают от пользователей и активно «идут в облака». Тем временем облачные технологии перестраиваются и становятся все более совершенными и распространенными и это не просто слова, а тому есть множество фактов, которые уже неоднократно обсуждались хабра-сообществом. В данный момент, как показывает тенденция развития, начал повышаться акцент на доставку данных, стабильность работы и распределение трафика. Дата-центрам, как и другим технологиям, пришлось адаптироваться к растущим запросам и трендам путем внедрения новых технологий.

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

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