Мой друган в очередной раз объяснял кому-то в уличной курилке, как устроен C#. Я глотнул кофе, закурил и облокотился на ограду, чтобы послушать. Он рассказывал, какие интересные тонкости нашел в сборщике мусора. Говорит, в дотнете он устроен довольно просто снаружи, но очень хитро в деталях реализации.

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

Навеяно этим.

Kаждый день десять мужчин собираются вместе в баре, чтобы выпить по кружке пива, и получают общий счет на $100. Они оплачивали свой счет так, как мы платим свои налоги, это выглядело примерно так: Первые четыре человека (самые бедные) не платили ничего. Пятый платил $1. Шестой платил $3. Седьмой платил $7. Восьмой — $12. Девятый — $18. Десятый (самый богатый) платил $59.

Я хотела бы начать этот пост очень пафосно. Например, так: «Я работаю в бизнесе уже 10 лет, получила железное сердце и обросла панцирем». Или так: «Да-да, Хабр, я работник коммерческой службы: когда-то аналитик, потом продажник, потом маркетолог. Я тот самый, кого вы все не любите». В конце концов, именно так должен выглядеть пост первого января. Но нет. Никакого пафоса и романтики. Работаю в коммерции ИТ-компаний некруглые 11,5 лет. Была всем: разработчиком, проджектом, маркетологом, продажником, внедренцем, редактором, ИТ-консультантом. До этого была на госслужбе и преподавала. И я сегодня, несмотря на сто доводов против, могу сказать: «Бизнес, я люблю тебя!» Ну понятно, что развитие этой мысли под катом.

Однажды в моей команде был настолько слабый парень, что его собирались уволить (уволить разработчика!). Каждый мой коммент на ревью к его коду был гвоздем в крышку гроба. Я почти слышал стук молотка, нажимая «submit review». Он был приятным человеком, я даже переживал за него, но это не мешало мне разносить его старания в щепки. Мое право критиковать его работу казалось очевидным и неотъемлемым. Все просто — я сильнее, я прав. Никто же не хочет сказать, что плохой код — это хорошо, а? Его уволили, предварительно лишая стандартной премии в течение нескольких месяцев.

Я говорил себе: «Но ведь не делать же мне всю работу за него!? Он занимал место более талантливого разработчика. Я все правильно сделал». Но почему-то на душе скребли кошки. И когда мне пришел на ревью очередной pull request, что-то очень сильно поменялось.

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

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.

Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и наслаждается полученным результатом. Но вскоре он понимает, что для того, чтобы управлять менюшкой, хорошо бы знать закрыто оно сейчас или нет. Мы-то с вами тут программисты опытные, все понимаем, что нужно добавить флаг. Не вопрос, флаг есть.

var opened = false;

Вроде, работает. Но, если быстро кликать по кнопке, меню начинает моргать, открываясь и закрываясь не успев доанимироваться в конечное состояние. Вася добавляет флаг animating. Теперь код у нас такой:

var opened = false;
var animating = false;

function onClick(event) {
  if (animating) return;
  if (opened) close();
  else open();
}

Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:

if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.

Знакомьтесь, это Вася.

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

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.

Спасибо Loriowar за приглашение на Хабр. Я уже давно почитываю, но никогда не писала. Я сама IT рекрутер из Канады, и мне очень прикольно читать, как программеры воспринимают процесс рекрутмента и hr-ов. Я сама когда-то пыталась стать программистом, прошла весь угар поиска работы да еще в чужой стране, на чужом языке, да и в момент обвала рынка dotcom-ов. Потом мне надоело извиваться как угорь на сковородке перед тупыми рекрутершами, и я решила стать одной из них. Я думала, что никогда не буду вести себя как они, но пришлось, сама логика найма принуждает к этому. Так что я знакома с претензиями обеих сторон к друг другу.

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

Кстати, рекрутмент в Штатах и в Канаде устроен одинаково, кроме некоторых аспектов, вызванных различиями в законодательстве и иммиграционной политике. А так, методы, подходы, инструменты все одинаковые.

Вот, кстати, и первое отличие — в Штатах до сих пор существуют агентства называемые Employment Services/Placement Consultants/Job Placement Agency и т.п. Они берут оплату с кандидатов за факт трудоустройства. В России такие фирмы, кажется, называются кадровыми агентствами. В Канаде, и по-моему в Англии, данный вид деятельности запрещен законодательно т.к. считается неэтичным.

Перевод 27 Amazing Web Development Tools for the Past Year (v.2018)

В 2017-м мы сравнили около 7 500 open source-инструментов для веб-разработки, из которых выбрали 27 лучших (0,4%). Это крайне конкурентный список, в который вошли инструменты, библиотеки и проекты, опубликованные в течение 2017-го. Mybridge AI оценивает их качество на основании популярности, заинтересованности и новизне. Чтобы было понятно, у выбранных продуктов среднее количество звёзд на Github — 5260.

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

Работа 24 на 7

«Всем привет, меня зовут Антон, и я — трудоголик. Я часто работаю по 12 часов в день. Моя семья очень страдает от этого. Я очень хочу начать жить, как все нормальные люди, но каждый раз срываюсь и засиживаясь заполночь...» — наверное так бы я начал свою речь, если бы состоял в клубе анонимных трудоголиков.

Мой трекер продуктивности — это «волшебное зеркало», но вместо времени, погоды и мотивационных цитат оно показывает:

• Сколько времени я сегодня потратил на рабочие задачи за компьютером и в смартфоне (RescueTime).
• Мой список дел из Trello.
• «Радарный график», отображающий мои затраты времени на разные категории приложений по сравнению со вчерашним днём (RescueTime).
• Недельные итоги (RescueTime).

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

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

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

Сегодня только ленивый не говорит (пишет, думает) про машинное обучение, нейросети и искусственный интеллект в целом. Всего лишь в прошлом году ML сравнили с подростковым сексом — все хотят, но никто не занимается. Сегодня все озабочены тем, что ИИ нас оставит без работы. Хотя, судя по последним исследованиям Gartner, можно успокоиться, так как к 2020 году благодаря ИИ появится больше рабочих мест, чем ликвидируется. Так что, дорогой друг, учи ML, и будет тебе счастье.

(source)

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

А почему так важно, чтобы переменные в линейной регрессии были независимы?

или

А почему для изображений используются именно свёрточные сети, а не обычные полносвязные?

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

Так давайте не будем мучить себя и других и просто вспомним основные понятия теории вероятностей.

Статистика в последнее время получила мощную PR поддержку со стороны более новых и шумных дисциплин — Машинного Обучения и Больших Данных. Тем, кто стремится оседлать эту волну необходимо подружится с уравнениями регрессии. Желательно при этом не только усвоить 2-3 приемчика и сдать экзамен, а уметь решать проблемы из повседневной жизни: найти зависимость между переменными, а в идеале — уметь отличить сигнал от шума.

Для этой цели мы будем использовать язык программирования и среду разработки R, который как нельзя лучше приспособлен к таким задачам. Заодно, проверим от чего зависят рейтинг Хабрапоста на статистике собственных статей.

Последние четыре года я работал разработчиком программного обеспечения в Google, но 1 февраля уволился, потому что они не сделали мне подарок на Рождество.

Шучу, на самом деле всё немного сложнее.

Первые два года

Первые два года я любил Google.

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

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


Мой обычный день в Google.
— Ещё тортика, господин Программист? Он бесплатен в любом количестве.
— Не сегодня, Пьер. Я опаздываю на массаж, он тоже бесплатный.

Было снежное воскресенье, притом еще и Прощенное, и с утра было принято решение сбросить с себя одеяло и начать подготовку своего отъетого за время масленицы тела к летнему пляжному сезону. Питер не очень благосклонен в данный сезон к занятиям спортом на улице, абонемент в спортзал закончился, так что после 5 км лыжного кросса энергия требовала выхода на свободу.
Конечно же, просто залипнуть в Интернет не получилось, и вспомнилась идея предсказания победителя премии «Оскар» в 2018 году, результаты которой будут известны совсем скоро 4-го марта. Данная идея была сформирована в общении с одним интересным человеком, так что спасибо ему за идею.

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

Заодно у меня получилось рассмотреть основные функции и методы Apache Spark, так что данную статью можно рассматривать еще и как небольшой туториал по спарку.

Введение

Надеюсь что мы с вами набрались достаточно опыта, чтобы смоделировать что-нибудь более серьезное, чем полет камня. Предлагаю такую задачу

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

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