Пару недель назад разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.
Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
— приложения, следующие стандартам;
— «долгоиграющие» веб-приложения;
— комплексные приложения со множеством различных асинхронных блоков на странице;
— кросс-доменные приложения.

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

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

По слухам, сегодня должен состояться релиз 7.1. Поэтому хотелось бы немного оглянуться назад и посмотреть, а как же php вырос из набора костылей и подпорок в полноценный язык для веба. Прямо по шагам, т.е. по версиям. А в конце хотелось бы немного поразжигать поразмыслить о роли php в современной экосистеме.

Давайте мысленно вернемся во времена php4, когда получили своё развитие wordpress, bitrix и миллионы других CMS и домашних страничек.

Бывало ли так, что вы видите на веб-странице картинки и оформление, но не видите текста — он появляется на пару (десятков) секунд позже? Это загружаются кастомные веб-шрифты. Объясняем, почему это происходит и как этого избежать.

Классический вопрос на собеседовании ops-инженеров и программистов: вы написали в адресной строке браузера habr.com и нажали Enter. Что произойдет? (Ответ на 10 страницах)

Ок, мы указали для своего текста font-family: PFRegal, «Times New Roman». Что произойдет?

Браузер посмотрит, есть ли для PFRegal объявление font-face. Если оно есть, то начнется загрузка файла шрифта. Что будут видеть читатели те секунды (десятки секунд на 3G), пока происходит загрузка?

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

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

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

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

Сразу после запуска вся наша архитектура выглядела так:



Это была 1 виртуалка от Digital Ocean за 80$ в мес (4 CPU, 8 GB RAM, 80 GB SSD). Взяли с запасом. Так как “а вдруг лоад пойдет?”. Тогда мы действительно думали, что, вот, запустимся и тысячи пользователей ринут на нас. Как оказалось — привлечь и заманить пользователей та еще задача и нагрузка на сервер — последнее о чем стоит думать. Из технологий на тот момент была лишь Java 8 и Netty с нашим собственным бинарным протоколом на ssl/tcp сокетах (да да, без БД, spring, hibernate, tomcat, websphere и прочих прелестей кровавого энтерпрайза).

Все пользовательские данные хранились просто в памяти и периодически сбрасывались в файлы:

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
  writer.write(user.toJson());
}

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

Однако, совсем недавно Apple дала нам iPad 3 небольшую фору, для того, чтобы привести дела впорядок. iPad'ом уже пользуются вполне себе полноценно, поэтому сайты должны выглядеть на нем ничуть не хуже, чем на ноутбуке или стационарном компьютере. И я считаю, что iPad 3 — это лишь первый шаг к полноценному внедрению Retina экранов в те же ноутбуки, а за ними и в стационарные мониторы. Apple уже готовит свою OS для Retina, у Windows 8 скорее всего с этим тоже проблем не будет, с их новым подходом в дизайне интерфейсов.

Пиксель всегда был наименьшей единицей в цифровом дизайне. Это невидимая величина измерения для дизайнеров. Фраза «пиксель пиксель пиксель» была принята в помощь принт-дизайнерам, чтобы те могли понимать концепт фиксированной плотности экрана. Веб-дизайнеры в свою очередь приняли пиксели взамен точкам.

Вместе с ростом мобильного интернета растёт и необходимость оптимизации скорости работы мобильных сайтов. Даже самые современные смартфоны на Android, iOS, WebOS, BlackBerry OS и др. обладают процессорами с частотой не более 1Ghz, а скорости 3G можно считать достаточно медленными (скорость загрузки в 3 раза меньше DSL).

Мобильные устройства унаследовали проблемы “больших” машин: от количества http-запросов до эффективности работы JavaScript.

Особенности мобильных устройств

Кроме того, что они часто помещаются в карман и их легче потерять, существует несколько ключевых отличий мобильных устройств по отношению к десктопам:

• маленькое разрешение экрана;
• медленные соединения;
• ограниченный размер кэша;
• много различных устройств и форм-факторов;
• низкая мощность процессоров;
• широкая поддержка HTML5;
• относительно новые браузеры (в этом мире не знают о IE6).

Сергей Аверин ( XEK )

Изначально я хотел сделать доклад про сравнение фреймворков, но потом подумал, что закидают помидорами, поэтому доклад — просто адский троллинг, как водится у меня. И он, скорее, не про HighLoad, а про менеджерскую задачу, которая стоит над всем этим делом, включая фронтенд.

Про что же, все-таки, получился доклад? Доклад про то, как выбирали новый фреймворк, почему выбирали, и какие задачи решали.

На фотографии — чеклист самолета Cessna: в какие положения нужно установить переключатели перед запуском двигателя, допустимые полетные параметры и так далее. Пилот не в первый раз видит этот список. Выучить — раз плюнуть. Но мозг может перезаписывать информацию, создавая ложные воспоминания, но при этом при «запросе» данные будут помечены как «верные». А вот напечатанное на бумаге не изменяется, поэтому ей можно доверять на 100%. SEO — это не управление самолетом с сотней человек на борту. Потерять можно всего-то несколько десятков тысяч рублей (если, например, начать продвижение с закрытыми от индексации в robots.txt страницами). Но не проще ли потратить 5-10 минут на проверку и убедиться, что все сделано правильно?..

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

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

Конструкторы различных стран носят “национальный отпечаток” — когда по сугубо маркетинговым, а когда по историческим причинам. При этом культура, искусство или достижения одной страны часто служат вдохновением, а то и прочной основой для коммерческого продукта из другой части света. Это был краткий пересказ первого выпуска с конструкторами Японии, России и еще трех стран.

Переходим ко второй:



Возьмем еще пять стран с разных континентов и посмотрим, что там с обычными и цифровыми конструкторами, — в попытке установить, а могли 600 одинаковых деталей повлиять на локальное становление технаря?

Во всех лабораториях, где я работала, упоминание фильма Люка Бессона «Люси» (2014) вызывало широкий спектр реакций, большинство из которых находилось в промежутке от усталого вздоха до плохо скрываемого напряжения вен на лбу. А его даже не все смотрели! Так почему же его так невзлюбили? Сам фильм вполне может быть развлекательным, но при этом он продолжает продвигать миф о том, что мы используем наш мозг лишь на 10% (после увеличения использования мозга до 90% героиня Скарлетт Йохансон научилась телепатии, телекинезу и антигравитации). Меня жутко угнетает зрелище того, как пропагандируют мифы о моей области деятельности. Поэтому я хотела разоблачить некоторые живучие мифы о самой удивительной вещи во Вселенной (ладно, постараюсь без фанатизма).

1) Мы используем лишь 10% от мощности нашего мозга

TL;DR: НЕТ нет нет НЕТ НЕТ нет НЕТ!

Если разделять языки программирования по популярности, то они делятся на три эшелона. Первый эшелон включает мейнстрим-языки, такие как Java, JavaScript, Python, Ruby, PHP, C#, C++ и Objective-C. Несмотря на то, что некоторые из ведущих языков возможно увядают, вам лучше знать один или несколько из них, если вы хотите иметь возможность легко найти работу.

Языки второго эшелона пытаются пробиться в мейнстрим, но ещё не добились этого. Они доказали свою состоятельность путем создания сильных сообществ, но они до сих пор не используются большинством консервативных IT-компаний. Scala, Go, Swift, Clojure и Haskell — языки, которые я бы отнёс ко второму эшелону. Некоторые компании используют эти языки для отдельных сервисов, но широкое применение встречается редко (за исключением Swift, который начинает обгонять Objective-C в качестве основного языка для iOS). Go и Swift имеют хорошие шансы на переход из второго эшелона в первый в течение ближайших двух-трёх лет.

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

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

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

В примерах используется JavaScript ES2015). (Почему JavaScript?)

Работа над материалом продолжается; присылайте свои пулл-реквесты в оригинальный репозиторий на английском языке.

В документе используются термины из спецификации Fantasy Land spec по мере необходимости.

Arity (арность)

Количество аргументов функции. От слов унарный, бинарный, тернарный (unary, binary, ternary) и так далее. Это необычное слово, потому что состоит из двух суффиксов: "-ary" и "-ity.". Сложение, к примеру, принимает два аргумента, поэтому это бинарная функция, или функция, у которой арность равна двум. Иногда используют термин "диадный" (dyadic), если предпочитают греческие корни вместо латинских. Функция, которая принимает произвольное количество аргументов называется, соответственно, вариативной (variadic). Но бинарная функция может принимать два и только два аргумента, без учета каррирования или частичного применения.

Генеральный директор студии lab.AG Артём Геллер, работавший над новой версией президентского сайта Kremlin.ru, дал интервью изданию Smashing Magazine — в нём он рассказал о разработке ресурса, технических аспектах работы с администрацией президента, создании адаптивного интерфейса сайта, а также раскрыл некоторые детали проекта.

В мире PHP-программирования существует набор трендов. Некоторые люди активно продвигают их (в книгах и на сайтах) как «современный PHP», а другие подходы выставляют как устаревшие, глупые или просто неверные.

Похоже, все эти люди без устали стараются заставить каждого программировать так, как они считают нужным. Эта статья написана, чтобы поделиться прагматичным взглядом на PHP-программирование. Взглядом, продиктованным опытом и практическими последствиями, а не популярными тенденциями, теориями или академическими догмами. Материалы, представленные на сайте PHP — The Wrong Way, будут обновляться по мере появления новой информации. Приглашаем всех поучаствовать в этом.

^{В Екатеринбурге в одном из зданий для международных конференций есть проблема с «немного глупыми» иностранцами. Говорят, такие же автоматы начали ставить в Москве.}

«Пользователь пьян» — базовый принцип проектировщика. Ещё пользователь нечеловечески изобретателен, умён и привередлив, но прямо сейчас пьян. То же самое касается передачи информации. Сейчас покажу физические ограничения на ошибки пользовательских интерфейсов.



Начнём со специальной клавиатурной чашки.

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

Трудно одним заголовком сформулировать, чем же является Galen Framework. Все началось с того, что у меня возникла потребность тестировать сайты в различных браузерах и проверять: не поехала ли разметка, например, в том же Internet Explore или Chrome. Затем возникла мода на Responsive Web-Design, и пришлось вручную менять ширину браузера и проверять, как отображаются сайты. И, хотя все это время были WebDriver и Selenium Grid под рукой, так и не получалось нормально тестировать верстку сайта в Java коде. Одна из идей была: делать скриншоты в разных браузерах в Selenium Grid и затем собирать их все в один большой отчет, по которому один из тестировщиков обязан пробежаться глазами и, в случае обнаружения несоответствий, рапортовать о дефекте. К сожалению, вся эта затея долго не продержалась. Тестировщикам стало лень листать огромный отчет и сравнивать скриншоты, и они все равно пропускали мелкие дефекты. А затем пошли требования внедрения во всех сайтах Responsive Design. И вот тут появился Galen Framework. Решение оказалось простым: проверять размер и расположение элементов относительно друг друга. Для этого понадобился специальный язык Galen Specs, который было бы легко читать и понимать.



Если коротко, Galen Framework — это специальный язык и инструмент для тестирования отображения сайта в браузере. Он позволяет тестировать адаптивный дизайн, а также проводить кросс-браузерное тестирование сайта.