Я уже писал про CS50 здесь. Опрос показал, что народ заинтересован в переводах субтитров. Я приношу извинения за то, что забросил эту тему на некоторое время. К этому моменту у меня накопились переводы лекций с 0-ой недели по 3-тью. Думаю к концу календарного года (а может и раньше) справлюсь со всем курсом.

Кому надо забирайте. Буду обновлять этот файл добавляя туда новые субтитры со средней частотой раз в неделю. Если кто-то хочет добавить в этот архив какой-нибудь перевод шлите на soslan[a]tabuev.com.

В последнее время в научных публикациях всё чаще упоминается алгоритм достижения консенсуса в распределенных системах под названием Paxos. Среди таких публикаций ряд работ сотрудников Google (Chubby, Megastore, Spanner) ранее уже частично освещенных на хабре, архитектуры систем WANdisco, Ceph и пр. В то же время, сам алгоритм Paxos считается сложным для понимания, хоть и основывается он на элементарных принципах.

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

При написании собственных веб-приложений часто возникают такие ситуации, в которых приходится делать выбор между синхронным и асинхронным выполнением запросов. С одной стороны, идея синхронной работы выглядит вполне логичной: мы запускаем некоторый процесс, дожидаемся его завершения и после этого продолжаем работу. Но на деле такой подход хорош только в случае простых вычислений. Представьте, что в процессе выполнения вам нужно, к примеру, сделать сложный запрос к базе данных — а то и, еще лучше, отправить запрос к другому серверу и дождаться от него результатов. В этом случае дальнейшая работа потока будет остановлена на довольно продолжительное время — а это, понятное дело, далеко не всегда является приемлемым. Именно в таких случаях на помощь приходят асинхронные запросы. Давайте посмотрим, как работа с ними реализована в Play framework.

ВВЕДЕНИЕ

Данный пост подразумевает хорошее интро в N2O на русском.

Что такое Erlang/OTP Web Framework N2O и в чём его фишка для веб-разработки, можно узнать на странице в github и официальном сайте SynRC. Там всё как вы любите с графиками и презентациями.

А здесь рассмотрим принципы работы фреймворка и поговорим о вечном.

Добрый день, Хабражитель!

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

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

Для реализации такой задачи есть три решения:

• «бесконечный iframe»,
• используя XMLHttpRequest (a.k.a. Ajax),
• используя WebSocket.

Первое решение я сразу «отметаю» (причины объяснять не буду, web-разработчики меня поймут).

Второе решение нравится гораздо больше, но у него есть свои минусы:

• браузер отправляет запрос каждую секунду создавая лишнюю нагрузку на:
  • сервер;
  • ОС, на которой работает браузер;
  • и еще раз на сервер, так как сервер постоянно выполняет запрос БД на выборку последних уведомлений.
• тяжело отследить онлайн-статус пользователя (то есть нужно, например, хранить сессии в БД и постоянно мониторить каждую на timeout).

Третье решение — как раз то, что доктор прописал.

Итак, WebSocket.

Version: 0.2

Возникла у меня потребность атомарного обновления в реальном времени страницы у некоторого количества пользователей в зависимости от действий других пользователей (не гербалайф чат). Понятное дело, можно всё выкинуть в помойку и, по-молодецки, запилить с нуля на tornado/twisted.web, но явно не самый продуктивный путь (да и я не мо́лодец ни разу) когда всё что надо — уже работает на Django и нужно всего-то чуть-чуть… Естественным образом, по сути своей, сюда просится WebSocket. И всё бы ничего но Django WSGI приложение, а этот стандарт не предполагает таких выкрутасов даже близко (пока). Гугления интернетов навели, в очередной раз, на труд известного python-гуру kmike (это без сарказма, т.к. его работы выручали меня лично уже не однократно, за что нижайший ему поклон!).

Итак если вы хотите скрестить ваш Django проект с websocket посредством js библиотеки socket.io или sockjs — вилькоммен!

Недавно я запустил сайт backgrounddating.com и написал об этом здесь, на Хабрахабре. Разумеется, я уже тогда рассказал о некоторых технических деталях реализации этого проекта, но об одной из возможностей сайта я бы хотел написать отдельно, тем более, что документации (как на русском, так и на английском) на эту тему в Интернете пока что довольно мало. Итак, речь пойдёт о чате в реальном времени между двумя пользователями. Задача состоит в том, чтобы любой пользователь мог отправлять другим пользователям сообщения, и, если у получателя сообщения открыт чат с этим пользователям, то он сразу же видел входящие сообщения (а в ином случае он мог прочитать сообщения позже: то есть при открытии чата загружается история последних сообщений).

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

Сразу уточню, что это не единственный способ реализовать подобное. Вы можете использовать другой асинхронный веб-сервер (например node.js), можете использовать другую очередь сообщений (или вообще её не использовать, если вам подходят особенности такого варианта: с пользователями одного канала обязательно общается один и тот же worker веб-сервера). Я даже не утверждаю, что этот вариант самый лучший (но в данном случае он подошёл лучше всех). В конце концов, мы здесь вообще не будем рассматривать костыли (long polling, Flash) для старых браузеров (а это почти все версии IE, например), не поддерживающих веб-сокеты, и даже не будем рассматривать возможность подключаться из тех браузеров, которые уже поддерживают протокол WebSocket, но не стандартизированную версию (RFC 6455), а одну из устаревших. О том, как можно включить поддержку устаревшей версии «draft 76» (она же «hixie-76»), смотрите в документации Tornado.

Websocket′ы полезны постоянным дуплексным соединением backend-сервера с браузером клиента — это прочный мост между сервисом и посетителями, по которому удобно беспрепятственно транспортировать потоки данных в обе стороны.

В результате внедрения websocket′ов наш проект получил возможность в реальном времени менять по своему усмотрению отображение страниц в браузере на протяжении всей клиентской сессии и иметь обратную связь.

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

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

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

Итак, начнем с постановки задачи классификации. Пусть X — множество описаний объектов, Y — множество номеров (или наименований) классов. Существует неизвестная целевая зависимость — отображение , значения которой известны только на объектах конечной обучающей выборки . Требуется построить алгоритм , способный классифицировать произвольный объект x∈X. Однако более распространенным является вероятностная постановка задачи. Пусть X — множество описаний объектов, Y — множество номеров (или наименований) классов. На множестве пар «объект, класс» X×Y определена вероятностная мера P. Имеется конечная обучающая выборка независимых наблюдений , полученных согласно вероятностной мере P.

В iOS 6 Apple представили замечательную возможность для вёрстки UI для iOS-приложений — Auto Layout. Но вот что удивительно, до сих пор очень немногие проекты используют эту возможность. А ведь это очень сильный инструмент, если с умом подойти к вёрстке UI, можно сэкономить очень много времени на подстраивании элементов для 3,5” и 4” экранов, портретно-ландшафтном расположении экрана и даже на универсальной вёрстке для iPhone и iPad.

И это всё не считая того, что скоро представят iPhone 6 и никто до сих пор точно не знает, какое там будет разрешение и какой экран. Лучше бы заранее подстраховаться.

В основном, тема Auto Layout довольно простая, и изучить её несложно. Но лично я столкнулся с большой проблемой при расположении элементов в UIScrollView. Я потратил немало времени и нервов на изучение того, как же правильно расположить элементы и указать размер контента для того чтобы ScrollView начал пролистываться.

Хоть и решение довольно простое, но на него не так просто выйти. В данной статье я бы хотел рассказать, как же всё-таки правильно готовить UIScrollView в Auto Layout.

Мы уже рассказали вам, что такое Cocaine и как его развернуть «в домашних условиях». Сегодня речь пойдёт о том, как пользоваться его инфраструктурой на уровне программиста. Кстати, 26 апреля в 14:00 в московском офисе Яндекса пройдет встреча, на которой можно будет вживую пообщаться с нами — командой, которая делает Cocaine. Приходите, но не забывайте регистрироваться.



Итак, из сегодняшнего поста вы узнаете:

• как писать приложения;
• как пользоваться приложениями и сервисами нативно, используя предоставленные фреймворки;
• как изменить приложение, чтобы оно отвечало по http, а также как потестировать эти приложения, используя Cocaine http proxy;
• как написать собственный сервис.

Давайте же начнем наше погружение в «кокаиновые» будни программиста.

Здравствуйте, уважаемые читатели!

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

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

Ни RAID-массивы, ни «железные» СХД не способны решить все перечисленные задачи одновременно. Именно поэтому все большее распространение в индустрии хостинга приобретает Software-defined storage. Одним из ярких представителей SDS является распределенное хранилище под названием Ceph.

Мы решили рассказать об этом замечательном продукте, который используется в CERN, 2GIS, Mail.ru и в нашем облачном хостинге.

Добрый день.
Меня зовут Головач Иван, я руковожу небольшой образовательной компанией и преподаю сам:

1. Java Core
2. Junior Java Developer: Servlet API, JDBC, Maven, JUnit, Mockito, Log4J, основы Spring/SpringMVC, основы JPA/Hibernate, шаблоны/архитектуры MVC/IoC/DAO.
3. Multicore programming in Java.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

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

(GolovachCourses.com)

Здесь собраны несколько вариантов записи моего курса Java Core.
Модуль #1 (Procedural Java):
Набор июль 2013: #1, #2, #3, #4
Набор апрель 2013: #1, #2, #3, #4
Набор февраль 2013: #1, #2, #3, #4
Набор январь 2013: #1, #2, #3, #4
Набор октябрь 2012: #1, #2, #3, #4.

Ratchet — так называется HTML5-фреймворк для быстрого прототипирования мобильных приложений, который 1,5 года назад создали те же парни, которые когда-то выпустили Bootstrap.

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

Я являюсь поклонником Ratchet с момента выхода первой версии. Тогда он был доступен только под iOS.
Не так давно вышла вторая версия, которая наряду с iOS поддерживает Android. Ура-ура!
(правда, обратной совместимости с первой версией нет)

Кому интересно про новые возможности Ratchet 2.0 — прошу под кат!

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

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



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

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

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

Цель этой статьи — рассказать о языке программирования Go (Golang) тем разработчикам, которые смотрят в сторону этого языка, но еще не решились взяться за его изучение. Рассказ будет вестись на примере реального приложения, которое представляет из себя RESTful API веб-сервис.

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

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



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

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

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



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

Это третья часть переведённых заметок «Good User Interface». Первые 16 частей уже ранее перевели наши коллеги из ADV на Хабре, а вторые 11 перевели мы.

Идея 28


Используйте варианты по-умолчанию, не заставляя людей выбирать

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

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

Сегодня я хочу рассказать о некоторых решениях проблем, которые возникают во время использования высоконагруженных систем. Все, о чем пойдет речь в этом материале, проверено на собственном опыте: я – Social Games Server Team Lead в компании Plarium, которая занимается разработкой социальных, мобильных, браузерных игр.

Для начала немного статистики. Plarium занимается разработкой игр с 2009 года. На данный момент наши проекты запущены во всех наиболее популярных социальных сетях («Вконтакте», «Мой мир», «Одноклассники», Facebook), несколько игр интегрированы в крупные игровые порталы: games.mail.ru, Kabam. Отдельно существует браузерная и мобильная (iOS) версии стратегии «Правила войны». В базах числятся более 80 миллионов пользователей (5 игр, локализация на 7 языках, 3 миллиона уникальных игроков в день), в итоге все наши серверы получают в среднем около 6500 запросов в секунду и 561 миллион запросов в сутки.

В качестве аппаратной платформы на боевых серверах в основном используются два серверных CPU с 4 ядрами (x2 HT), 32-64 GB RAM, 1-2 TB HDD. Серверы работают на базе Windows Server 2008 R2. Контент раздается через CDN с пропускной способностью до 5 Gbps.
Разработка ведется под .NET Framework 4.5 на языке программирования C#.

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