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



Эту метафору будет проще понять, если провести аналогию с черной дырой: мы не знаем, что находится под ее горизонтом событий, и чтобы это узнать нам нужно придумать способ, как туда добраться. Нечто подобное существует в мире математики. Данное уравнение — это настоящая «формула» простого числа, но чтобы ею пользоваться, нам нужно придумать, как искать подходящие {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, w, v, x, y, z}.

Черная дыра и данное уравнение — это предельные состояния чего-то реального и абстрактного. И, если о первом существует достаточно догадок и представлений, то о втором, практически ничего не известно. Но, что если это действительно «математическая» черная дыра? Разве вам не интересно что может произойти, если мы попадем под горизонт?

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

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


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

Если вкратце, то я бы посоветовал читать много книг, не имеющих отношения к информатике.



Важно понимать, какое место занимает понятие «science» в «Computer Science», и что означает «engineering» в «Software Engineering».

Современное понятие «науки» можно сформулировать так: это попытка перевести явления в модели, которые можно более-менее легко объяснить и предсказать. На эту тему можно прочесть «Sciences of the Artificial» (одна из важных книг Герберта Саймона). На это можно смотреть с такой точки зрения: если люди (особенно разработчики) строят мосты, то учёные могут объяснять эти явления, создавая модели. Самое интересное в этом то, что наука почти постоянно будет находить новые, лучшие способы наведения мостов, так что дружеские отношения между учеными и разработчиками вполне могут улучшаться с каждым годом.

Примером подобного из сферы Computer Science является Джон Маккарти, размышляющий о компьютерах в конце 50-х годов, то есть о невероятно большом спектре того, что они могут сделать (может быть, ИИ?), и создание модели вычислений, которая является языком, и может служить в качестве собственного метаязыка (Lisp). Моя любимая книга на эту тему — «The Lisp 1.5 Manual» от MIT Press (автор Маккарти с соавторами). Первая часть этой книги по-прежнему остается классикой того, как нужно думать в целом и об информационных технологиях в частности.

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

Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.

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

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

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

Мы в компании создаем сервис, который извлекает юридические факты из переписки клиента и заказчика. Сервис вырос из одной простой идеи — мои постоянные клиенты из решили упросить работу менеджерам и создать “генератор договоров”. Первую задачу — подтягивать в договор реквизиты клиента и заказчика мы решили легко.

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

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

Обсуждение итогов года во фронтэнде внезапно стало предметом дискуссии. Добавлю свое мнение, и буду рад услышать мнение других.

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

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

источник картинки

Во время очередного спора знакомый озвучил мысль, которая меня очень сильно задела. «В большинстве популярных ЯПов существует очень много разных путей сделать одно и то же. Это приводит к проблемам. А вот в Go всё не так. Философия языка такова, что на Go разные разработчики решают одинаковые проблемы одинаковым образом. Поэтому их код легко читаем, предсказуем и надежен. И поэтому крупный бизнес выбирает Go». Это достаточно мощный аргумент, над которым нужно как следует поразмыслить, прежде чем опровергать.

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

В 2012 году на северо-востоке Москвы случился пожар. Загорелось старое здание с деревянными перекрытиями, огонь быстро перекинулся на соседние дома. Пожарные расчеты не могли подобраться к месту — все парковки вокруг были заставлены машинами. Огонь охватил полторы тысячи квадратных метров. Подобраться к гидранту тоже не удавалось, поэтому спасатели использовали пожарный поезд и даже два вертолета. Один сотрудник МЧС погиб в огне.

Как выяснилось позже, пожар начался в доме издательства «Мир».

Вряд ли это название что-то говорит большинству людей. Издательство и издательство, очередное привидение из советских времен, которое уже лет тридцать ничего не выпускало, но почему-то продолжало существовать. В конце нулевых оно было на грани банкротства, но каким-то образом возвращало долги, кому бы и что оно там ни было должно. Вся его современная история — это пара строк в Википедии о чехарде между всякими государственными МГУП ШМУП ФМУП, которые пылятся в папочках Ростеха (если верить Википедии, опять же).

Но за бюрократическими строчками нет ни слова о том, какое огромное наследие «Мир» оставил в Индии и как повлиял на жизнь нескольких поколений.

Введение

Умножение матриц — это один из базовых алгоритмов, который широко применяется в различных численных методах, и в частности в алгоритмах машинного обучения. Многие реализации прямого и обратного распространения сигнала в сверточных слоях неронной сети базируются на этой операции. Так порой до 90-95% всего времени, затрачиваемого на машинное обучение, приходится именно на эту операцию. Почему так происходит? Ответ кроется в очень эффективной реализации этого алгоритма для процессоров, графических ускорителей (а в последнее время и специальных ускорителей матричного умножения). Матричное умножение — один из немногих алгоритмов, которые позволяет эффективно задействовать все вычислительные ресурсы современных процессоров и графических ускорителей. Поэтому не удивительно, что многие алгоритмы стараются свести к матричному умножению — дополнительная расходы, связанные с подготовкой данных, как правило с лихвой окупаются общим ускорением алгоритмов.

Так как реализован алгоритм матричного умножения? Хотя сейчас существуют множество реализаций данного алгоритма, в том числе и в открытых исходных кодах. Но к сожалению, код данных реализаций (большей частью на ассемблере) весьма сложен. Существует хорошая англоязычная статья, подробно описывающая эти алгоритмы. К моему удивлению, я не обнаружил аналогов на Хабре. Как по мне, этого повода вполне достаточно, чтобы написать собственную статью. С целью ограничить объем изложения, я ограничился описанием однопоточного алгоритма для обычных процессоров. Тема многопоточности и алгоритмов для графических ускорителей явно заслуживает отдельной статьи.

Процесс изложения будет вестись ввиде шагов с примерами по последовательному ускорению алгоритма. Я старался писать максимально упрощая задачу, но не более того. Надеюсь у меня получилось…

Екатерина Малахова, редактор-фрилансер, специально для блога Нетологии адаптировала статью Beau Carnes об основных типах структур данных.

«Плохие программисты думают о коде. Хорошие программисты думают о структурах данных и их взаимосвязях», — Линус Торвальдс, создатель Linux.

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

В этой статье я покажу вам 10 самых распространенных структур данных.

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

Что там будет под капотом, ни одна живая душа уже не поймет. Команда «хреновина» интерпретируется в абзац с описанием, который интерпретируется в ключевые слова, который интерпретируется в набор векторных обозначений, который интерпретируется в какой-нибудь С, который скомпилируется в…

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

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

Просто я задумался — а не стали ли наши ЯПы уже чем-то таким? Чуть более умным эквивалентом фразы «компьютер, сделай хреновину». Кучей формализованных протоколов для электричества, про которое мы уже забыть забыли. Штукой, которая все сильнее рвет нашу связь с механической реальностью.

Я часто слышу фразу: «Фил, отступись, хватит думать обо всякой чепухе». Но блин, будь проклят тот день, когда на Хабре напишут «хватит думать».

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

Google рассказывала о своём графе знаний, но ничего о внутренней инфраструктуре. Однако в компании тоже есть для него специализированные подсистемы. На самом деле сейчас графу знаний уделяется большое внимание. Лично я поставил на эту лошадку минимум два своих повышения по службе — и начал работу над новым графом ещё в 2010 году.

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

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

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

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

^{Заброшенная колода}

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

Как довольно быстро выяснилось в СССР, участки около высоковольтных ЛЭП пчёлы не собирают. Собственно, у них как-то отключается навигация из-за электромагнитных помех.

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

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

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

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

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Привет, сообщество! Мы в Хекслете составили список из пяти бесплатных автоматизированных онлайн-платформ для новичков.

На русском:

HTML Academy
«Академия» учит верстать сайты. Основной контент в формате подписки (390 рублей в месяц) и интенсивов (от 12500 рублей), но есть несколько бесплатных автоматизированных курсов по основам HTML, CSS и JavaScript.

В HTML Academy не столько задания для прокачки в программировании, сколько для знакомства с основами веб-разработки. Но это идеальный формат для тех, кто никогда не писал код и хочет попробовать. Большое количество веб-разработчиков начинало путь именно здесь.

Code Basics
Это новый бесплатный сервис от Хекслета. Его основная идея — через решение простых заданий прямо в браузере погружать новичков в основы программирования. Сейчас есть уроки по PHP, JavaScript и Python, ближайшее время появятся — новые. Платформа подойдет лучше всего для изучения основ синтаксиса, и меньше — для прокачки алгоритмов.

Обучение построено вокруг чередования небольших порций теории (3-4 абзаца) и закрепления практики в тренажере. У каждого практического задания есть решение учителя, которое можно сравнить со своим после успешного прохождения и раздел для обсуждения задания.

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

CheckiO

Проект из Украины «Чекио» сфокусирован на Python и JavaScript. Это сборник игровых задач по программированию для тех, кто уже не новичок. Большой упор на геймификацию, симпатичную графику и общение в сообществе. В самом решении задач игрового процесса нет, но есть общий сценарий для прохождения платформы. Полезная фича — смотреть другие решения и подсказывать студентам как их можно улучшить.

leetcode

Сборник задач по программированию на разных языках. Цель сервиса — готовить программистов к заданиям, которые встречаются на интервью. Платформа сразу даёт фидбэк на правильность и эффективность решения, показывает варианты решений и позволяет обсудить их с другими участниками. В платной версии можно пройти автоматизированное интервью в Google, Facebook или Amazon: робот подберёт вопросы, засечёт время и даже поможет оценить.

Это новая статья из разбора задач с собеседований в Google. Когда я там работал, то предлагал кандидатам такие задачи. Потом произошла утечка, и их запретили. Но у медали есть обратная сторона: теперь я могу свободно объяснить решение.