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

Twitter это всем известный сервис, он предоставляет инфраструктуру для обмена короткими текстовыми сообщениями, поиска, расстановки тегов и пр.

Но это именно то, что нужно большинству сервисов обмена небольшими данными. В моём случае это редактор рифов (коротких мелодий):

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

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

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

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

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

Память, медленная-медленная память

В начале 1980-х время, необходимое для получения данных из ОЗУ и время, необходимое для произведения вычислений с этими данными, были примерно одинаковым. Можно было использовать алгоритм, который случайно двигался по динамической памяти, собирая и обрабатывая данные. С тех пор процессоры стали производить вычисления в разы быстрее, от 100 до 1000 раз, чем получать данные из ОЗУ. Это значит, что пока процессор ждет данных из памяти, он простаивает сотни циклов, ничего не делая. Конечно, это было бы совсем глупо, поэтому современные процессоры содержат несколько уровней встроенного кэша. Каждый раз когда вы запрашиваете один фрагмент данных из памяти, дополнительные прилегающие фрагменты памяти будут записаны в кэш процессора. В итоге, при последовательном проходе по памяти можно получать к ней доступ почти настолько же быстро, насколько процессор может обрабатывать информацию, потому что куски памяти будут постоянно записываться в кэш L1. Если же двигаться по случайным адресам памяти, то зачастую кэш использовать не получится, и производительность может сильно пострадать. Если хотите узнать больше, то доклад Майка Актона на CppCon — это отличная отправная точка (и отлично проведенное время).

Часть 2 — градиентный спуск начало

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

Существует и другая версия алгоритма — стохастический градиентный спуск. Стохастический = случайный.

Привет Хабр! Если вам были интересны публикации из нашего блога, то наверняка вам будет интересно принять участие во встрече экспертов в области Data Science и машинного обучения, которая пройдёт 31 августа (среда) в DI Telegraph (Москва, Тверская 7). На встрече будет обсуждаться широкий круг вопросов, связанных с применением алгоритмов машинного обучения для решения задач анализа больших данных, тематического моделирования и генеративных алгоритмов.

Партнером и соорганизатором мероприятия выступаем мы — российская технологическая компания DCA (Data-Centric Alliance), специализирующаяся на работе с большими данными и высоконагруженными системами. Информация про формат и спикеров под катом.

Доводилось ли вам сталкиваться с системами искусственного интеллекта? Полагаем, ответ большинства хабравчан будет положительным. Ведь ИИ уже перестал быть «чем-то за гранью фантастики». Системы распознавания речи Siri, IBM Watson, ViaVoice, виртуальные игроки Deep Blue, AlphaGo и даже такие ранние системы, как MYCIN, разработанная в 1970-х годах в Стэнфордском университете и предназначенная для диагностирования бактерий, вызывающих тяжелые инфекции, а также для рекомендации необходимого количества антибиотиков — все это вариации на тему ИИ. Но, несмотря на то, что технологии стремительно набирают ход, современные системы все еще весьма «угловаты», и главная проблема, с которой сталкиваются исследователи, — это языковое обучение. Заставить систему говорить не сложно, но объяснить ей «физику» окружающего мира — то, что человек понимает на интуитивном уровне — пока не удавалось никому.

Тема языковой проблемы искусственного интеллекта широко раскрывается в статье Уилла Найта, главного редактора AI MIT Technology Review, которую специалисты PayOnline, системы автоматизации приема онлайн-платежей, старательно перевели для пользователей Хабрахабра. Ниже представляем сам перевод.

Примерно в середине крайне напряженной игры в Го, проходившей в южнокорейском Сеуле, участниками которой были один из лучших игроков всех времен Ли Седоль и созданный Google искусственный интеллект под названием AlphaGo, программа сделала загадочный шаг, продемонстрировавший пугающее преимущество над своим человеческим оппонентом.

Здравствуйте, Хабр!

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

Сегодня все очарованы новыми режимами (цифрового) взаимодействия. Есть много интересных и свежих идей относительного того, что может стать доминирующей средой для взаимодействия в будущем. Прикосновение? Жест? Голос? Трекинг глаз?

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

В дискуссиях по поводу дизайна взаимодействия я редко, если вообще когда-либо, вижу упоминание о клавишах быстрого доступа. (Начиная отсюда, я буду говорить о desktop web, так как он использует аппаратную клавиатуру). Это стало возможно, потому что дизайн взаимодействия, в общем и целом, кажется сосредоточенным на веб-дизайне, а сочетания клавиш были отнесены к сфере настольного ПО ^[1] (я не знаю, почему их перенесли не полностью). Однако там, где они есть, они, как правило, используются – я уверен, что проектировщики взаимодействия используют их все время, когда используют Illustrator, Photoshop, Omnigraffle и т.д. По иронии судьбы, горячие клавиши всегда кажутся запоздалой мыслью в конструкциях, созданных этими программами (если о них вообще думают).

В данной статье я затрону современные интерфейсы. Не все из них плохие. Но складывается впечатление, что такие титаны создания ПО, как Microsoft и Google, идут неверным путем. И этот путь заведет всех нас в глубокую … ситуацию.
Внимание, много букв!

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


Картинка для привлечения внимания.

Глубокой ночью ничто не предвещало беды… Но в четыре утра от фрилансерской биржи Upwork пришло письмо с радостным, выделенным полужирным начертанием сообщением:

Чем больше вы работаете с клиентом на Upwork, тем больше из заработанного вы оставляете себе!

Казалось бы, радоваться надо, но если вчитаться, то обнаруживаются некоторые детали: комиссию Upwork не уменьшил, а увеличил. Если раньше на все контракты распространялась комиссия 10%, то сейчас она становится ступенчатой: 20%, 10% и 5% при порогах в $0, $500 и $10 000.

В этом выпуске «Без слайдов» гостем выступил Вадим Макеев aka pepelsbey, евангелист компании Opera Software, один из самых известных фронтенд-людей в стране, организатор многих мероприятий в индустрии.

Мы успели обсудить:

• эволюцию WebKit;
• путь Microsoft и новую модель браузера;
• архитектуру современных браузеров;
• как Opera выбирала между WebKit и Blink;
• стандартизацию в вебе;
• насколько трудна работа веб-разработчика;
• JavaScript и его «продолжения»;
• jQuery, и почему он все еще нужен;
• HTTP/2;
• ритм жизни евангелиста;
• мобильный веб и Opera Mini;

Интервью взято в феврале, но руки дошли до публикации только сейчас.

Видео-версия нашей беседы вот тут:


А для тех, кто предпочитает читать, — под катом расшифровка нашей беседы.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы и интересные материалы из области фронтенда

Это седьмая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:

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

Функторы

За понятием функтора стоит очень простая, но мощная идея (как бы заезжено это ни прозвучало). Просто теория категорий полна простых и мощных идей. Функтор есть отображение между категориями. Пусть даны две категории C и D, а функтор F отображает объекты из C в объекты из D — это функция над объектами. Если a — это объект из C, то будем обозначать его образ из D как F a (без скобок). Но ведь категория — это не только объекты, но еще и соединяющие их морфизмы. Функтор также отображает и морфизмы — это функция над морфизмами. Но морфизмы отображаются не как попало, а так, чтобы сохранять связи. А именно, если морфизм f из C связывает объект a с объектом b,

f :: a -> b

то образ f в D, F f, связывает образ a с образом b:

F f :: F a -> F b

(Надеемся, что такая смесь математических обозначений и синтаксиса Haskell понятна читателю. Мы не будем писать скобки, применяя функторы к объектам или морфизмам.)

Представляю вашему вниманию перевод своей статьи Amazon software engineer interview, изначально опубликованной на английском на sobit.me.

Не так давно со мной связался технический рекрутер из Amazon. Компания организовывала трехдневное онсайт собеседование по найму программистов в их берлинский офис.

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

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

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

Немного забегая вперед, хочу показать, что же у нас есть в итоге…
Когда обнаруживается время расслабиться и включить сериальчик, я запускаю Alfred, ввожу "сериалы" и получаю в ответ список загруженных.

Сегодня внутренняя разработка компании Яндекс — аналитическая СУБД ClickHouse, стала доступна каждому. Исходники опубликованы на GitHub под лицензией Apache 2.0.



ClickHouse позволяет выполнять аналитические запросы в интерактивном режиме по данным, обновляемым в реальном времени. Система способна масштабироваться до десятков триллионов записей и петабайт хранимых данных. Использование ClickHouse открывает возможности, которые раньше было даже трудно представить: вы можете сохранять весь поток данных без предварительной агрегации и быстро получать отчёты в любых разрезах. ClickHouse разработан в Яндексе для задач Яндекс.Метрики — второй по величине системы веб-аналитики в мире.

В этой статье мы расскажем, как и для чего ClickHouse появился в Яндексе и что он умеет; сравним его с другими системами и покажем, как его поднять у себя с минимальными усилиями.

Недавний стремительный взлёт основанного на децентрализованной платформе «Эфириум» проекта «The DAO (ДАО)» (в ходе запуска которого было собрано порядка 150 млн USD инвестиций), вызвал всеобщее воодушевление относительно концепции Децентрализованных Автономных Организаций. При этом для криптовалюты Dash существование в режиме ДАО — это уже “прошлогодний снег”. В этой переводной статье будут рассказаны подробности об этом.

Клонирование объектов в JavaScript довольно частая операция. К сожалению, JS не предоставляет быстрых нативных методов для решения этой задачи.

К примеру, популярная Node.JS ORM Sequelize, которую мы используем на backend-е нашего проекта, значительно теряет в производительности на предвыборке большого (1000+) количества строк, только на одном клонировании. Если вместе с этим, к примеру, в бизнес-логике использовать метод clone известной библиотеки lodash — производительность падает в десятки раз.

Но, как оказалось, не всё так плохо и современные JS-движки, такие как, например, V8 JavaScript Engine, могут успешно справляться с этой задачей, если правильно использовать их архитектурные решения. Желающим узнать как клонировать 1 млн. объектов за 30 мс — добро пожаловать под кат, все остальные могут сразу посмотреть реализацию.