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

За долгое время работы в Яндексе нам удалось систематизировать все наши знания и огромный опыт в создании фронтенда веб-сервисов. Результатом этого осмысления и длительной работы стала первая Школа разработки интерфейсов, занятие которой шли в московском офисе Яндекса. Вся практическая часть обучения проходила в реальных проектах Яндекса. Теоретическая же состояла из лекций, которые читали ведущие разработчики интерфейсов Яндекса: Сергей veged Бережной, Михаил mishanga Трошев, Алексей doochik Андросов, Михаил azproduction Давыдов и другие.



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

Полгода назад здесь была опубликована статья, которая меня возмутила. В комментариях я обещал, что напишу свою версию. С другой стороны мне не хотелось этого делать, так как получу закономерные вопросы: «А ты собственно кто такой?». Не люблю подписываться в интернет-постах, у меня портилось мнение о многих писателях после того, как читал их жж-блог. Читаешь книгу, думаешь: «Классный чувак!», почитаешь блог, мнение меняется: «Что за кретин?». Такая разница возникает из-за того, что книга проходит пост-обработку, много раз редактируется.
Данная статья переписывалась несколько раз, в этом варианте, считаю, что она получилась наиболее взвешенной. Статья вполне подходит для хабрахабр, так как от людей технической направленности выходило немало известных произведений. И кому-то из вас захочется написать свою историю.

Все мы пользуемся профайлерами. Традиционная схема работы с ними такова, что приходится изначально запускать программу «под профайлером» а затем, после окончания ее работы, анализировать сырой дамп с помощью дополнительных утилит.
А что делать если мы не имея root'а хотим запрофилировать уже работающую программу, которая долго работала «как надо», а сейчас что-то пошло не так. И хотим это сделать быстро. Знакомая ситуация?
Тогда рассмотрим наиболее популярные профайлеры и принципы их работы. А затем профайлер, который решает именно указанную задачу.

Как известно, в основной реализации Питона CPython (python.org) используется Global Interpreter Lock (GIL). Эта штука позволяет одновременно запускать только один питоновский поток — остальные обязаны ждать переключения GIL на них.

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

Идея свежая, но имеет один существенный недостаток — она не работает…

Опять понедельник, и опять что-то интересное у нас на столе в Box Overview! На этот раз — интеллектуальное зарядное устройство для Ni-Mh аккумуляторов типоразмера AAA и AA.
Почему интеллектуальное?


В отличие от обычных зарядных устройств, которые продаются задешево китайцами или входят в комплекты типа «10 дешевых аккумуляторов и дешевая зарядка за 2000 рублей», и заряжают «капельным» способом, это зарядное устройство имеет в себе контроллер, в который заложены программы быстрой зарядки аккумуляторов, и некоторые другие фишки — вроде определения емкости и «тренировки» аккумуляторов для восстановления емкости.

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

История и краеугольные принципы Google Chrome.

Google Chrome был представлен во второй половине 2008 года, как бета версия для Windows платформы. Код Chrome, авторство которого принадлежит Google, был сделан доступным под либеральной BSD лицензией — как и Chromium проект. Для большинства заинтересованных, такой поворот событий стал сюрпризом — война браузеров возвращается? Сможет ли Google сделать свой продукт действительно лучше других?

«Это было столь хорошо, что заставило меня изменить свое мнение..» — Эрих Шмидт, первоначально не желающий принимать идею Google Chrome.

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

Итак, что мы представляем из себя на данный момент? В Stack Exchange сейчас работают 75 человек, примерно половина занимается продажами (маркетинг и реклама), остальные же — созданием продуктов (разработка, дизайн, управление сообществами). БОльшая часть удалённо работающих сотрудников занимаются разработкой: 16 удалённых и 18 офисных разработчиков, сисадминов, дизайнеров. У нас команда-гибрид, которая, как мне кажется, лучшая в мире. Я руковожу отделом проектирования, так что буду говорить в основном о разработчиках, но это применимо ко всем должностям.

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

Алекс, STL не реализует объектную модель персистентности (постоянного хранения) объектов. Map и Multimap являются особенно хорошими кандидатами для постоянного хранения контейнеров как инвертированных индексов в базах данных постоянного хранения объектов. Скажите, работали ли Вы в этом направлении или же Вы можете хотя бы прокомментировать реализации этой идеи?

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

Как реализовать long polling с помощью Nginx и Javascript в сети достаточно много материала. Но полного руководства я ещё не встречал. То возникают проблемы с компиляцией модуля под Nginx, то в браузере вертится иконка загрузки при long poll запросах. Под катом, полный материал как же все таки это сделать правильно.

«Гу́гол (от англ. googol) — десятичной системе счисления изображаемое единицей со ста нулями».
(Википедия).
Многие знают многоликость Google — это и популярный поисковик, и социальная сеть, а также еще множество других полезных и новаторских сервисов. Но мало кто задумывался: каким образом удалось компании развернуть и поддерживать их со столь высоким быстродействием и отказоустойчивостью? Как организовано то, что обеспечивает такие возможности,— дата-центр Google, каковы его особенности? Как раз об этом и пойдет речь в данной статье.

Собственно, корпорация Google уже давно никого не удивляет мощной динамикой своего роста. Активный борец за «зеленую энергетику», множество патентов в различных областях, открытость и дружественность по отношению к пользователям — вот те первые ассоциации, которые возникают при упоминании Google у многих. Не менее впечатляет и ЦОД компании: это целая сеть дата-центров, размещённых по всему миру, суммарной мощностью220 МВт (по состоянию на прошлый год). Учитывая тот факт, что инвестиции в ЦОД только за последний год составили 2,5 миллиарда долларов, понятно, что компания считает это направление стратегически важным и перспективным. В то же время наблюдается некое диалектическое противоречие, ведь, несмотря на публичность деятельности корпорации Google, его дата-центры являются этаким ноу-хау, тайной, скрытой за семью печатями. В компании считают, что разглашение деталей проектов может быть использовано конкурентами, поэтому лишь часть информации о наиболее передовых решениях просачивается в широкие массы, но даже эта информация весьма интересна.

Что это?

Треугольник Серпинского

Треугольник Серпинского — один из известнейших фракталов, его построение — одна из первых лабораторных работ на рекурсию по соответствующим дисциплинам во многих ВУЗах. Выглядит фрактал следующим образом:

Треугольник Паскаля

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

И что с того?

Есть в треугольнике Паскаля интересная особенность.

Задача: в массиве длиной N найти элемент, который повторяется больше N/2 раз.

Казалось бы, чего тут думать? Возьмём Dictionary<значение элемента, число появлений>, за один проход по массиву сосчитаем появления каждого элемента, потом выберем из словаря искомый элемент. Решение за O(N), куда может быть ещё быстрее?

Есть один нюанс: для словаря нам потребуется O(N) дополнительной памяти — в несколько раз больше размера исходного массива, и это при реализации словаря хоть хэш-таблицей, хоть деревом. Что будем делать, если наша цель — обработка сигнала неким устройством с маленькой памятью? Массив — замеры уровня сигнала, из которых один — «настоящий» передаваемый уровень, а остальные — шум и помехи. Неужели придётся для определения «настоящего» уровня возиться с хэш-таблицами и деревьями?

К счастью, нет: достаточно O(1) дополнительной памяти, и по-прежнему одного прохода по массиву.

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

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

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

Естественное напряжение (sic!)

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

Но кому нужно это «организованное напряжение»? Даже когда вы просто делаете, то что должно, вам и без того хватает стресса — зачем добавлять новый, от которого к тому же никак нельзя будет избавиться?

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

Приложения – это большой бизнес, а самый большой бизнес приложений – это игры. В 2012 году по оценкам Flurry доход, полученный от приложений, достигнет $ 10 млрд., где на долю игр приходится более 80% от дохода. Бизнес-модель бесплатной игры (aka freemium), где потребители скачивают и играют в «базовую часть» (“core loop”) игры бесплатно, но потом платят за виртуальные товары и валюту через микро-транзакции, является наиболее прибыльной бизнес-моделью в новую эпоху цифровой дистрибуции. Когда дело доходит до использования приложений на iOS и Android смарт-устройствах, потребители тратят около 40% всего времени на игры.

Facebook Hacker Cup 2011 проходит в 4 раунда — квалификационный, два онлайн раунда и финальный, в главном офисе.

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

А вот первый онлайн раунд, прервав ближе к завершению, перенесли из-за технических проблем минимум на неделю:
We've decided to push back the remaining subrounds of round 1 until we are sure that they can run smoothly. Updates will follow here, but you can safely assume that the subrounds will not occur at least until next weekend.

Исторически в Почте Mail.Ru использовался механизм от «большого» Поиска (go.mail.ru); однако для задач поиска по почтовым ящикам такой вариант не был оптимальным ввиду большого потребления ресурсов и относительной сложности в обслуживании. Поиском по почте пользуются около 3% владельцев почтовых ящиков; однако, хотя эта цифра кажется относительно небольшой, ящики этих людей обычно достаточно объемны, и поиск им действительно необходим. Поэтому мы приняли решение написать специализированный поисковый демон, который будет заниматься именно поиском по почте. Основными требованиями к нему стали ограничения по потребляемым ресурсам (размер индекса — не более 3% от размера почтового ящика, среднее потребление оперативной памяти — не более 100 Мб, средняя утилизация CPU — не более 3%) и скорости исполнения запросов (среднее время — не более 200 мс). О том, как он был организован, я расскажу ниже.

      Времена, когда программисты пытались выжать максимум из размера своего приложения, безвозвратно ушли. Основной причиной является существенное увеличение объемов оперативной памяти и дискового пространства на современных компьютерах. Немногие помнят, как при загрузке приложения с кассеты можно было пойти покушать. Или как можно было считать моргания дисковода, косвенно определяя размер приложения. Пожалуй, только разработчики програмного обеспечения под встраиваемые системы до сих пор заботятся о размере кода и потребляемой памяти. Могут ли таблетки и смартфоны вернуть разработчиков «назад в будущее»?
      Данная статья призвана помочь разработчикам програмного обеспечения, использующим GCC компилятор, уменьшить размер кода своих приложений. Все данные в статье получены при помощи x86 GCC компилятора версии 4.7.2 на операционной система Fedora 17 для архитектуры Intel Atom.

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

И действительно, как же доказать, что 2 × 2 = 4? Ответ под хабракатом.

Дисклеймер

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

Это перевод статьи с ReadWrite.com от Майка МакДермента — основателя и CEO FreshBooks. Читайте его в Twitter @MikeMcDerment



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

Нет, не так.