В банк пришло резюме

Иван Абрамович Левый

г. Харьков, квартиру снимаю
дом. нету
моб. все равно не позвоните, резюме потеряете, сам вам позвоню.

Позиция:

Ведущий разработчик, руководитель проекта. Глубокое понимание отрасли разработки ПО в условиях аутсорсинга, раскручивания заказчика на бабки, создание мощной видимости работы команды и развития проекта при реальной нулевой отдаче и отсутствии у программистов каких бы то ни было навыков.
Большой опыт руководства коллективами ничего не знающих студентов (ХИРЭ), напыщенных что-то знающих выпускников (ХАИ) и что-то знающих умников-халявщиков, которые все равно через два месяца свалят на бОльшую зарплату или за границу (ФизТех/МехМат ХГУ).
Глубокое понимание ведения переговоров с заказчиками/инвесторами, знание скидок во всех престижных саунах, клубах и, хм… массажных центрах.

Сергей Зубов (CDNvideo)

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

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

Есть большая ТЭЦ. Работает как обычно: жжёт газ, вырабатывает тепло для отопления домов и электричество для общей сети. Первая задача — отопление. Вторая — продать всё выработанное электричество на оптовом рынке. Иногда ещё в мороз при ясном небе появляется снег, но это побочный эффект работы градирен.

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

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

Про то как мерзлота может стать если не «белым пушным зверьком», то уж точно «чёрным лебедем», притаившим полтора триллиона тонн углерода — читаем первую часть «Мох и мамонты».

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

Без преувеличения можно сказать, что SQL — один из самых распространенных в мире языков. Информационные системы могут быть написаны на Java, Python, JavaScript, C#, PHP и десятке других языков, но SQL база в том или ином виде будет в абсолютном большинстве таких систем. Среди бизнес-приложений процент систем, использующих SQL, вообще стремится к 100%.

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

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

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

Пост лучше всего подойдет разработчикам «one-man-company» или командам. Я расскажу, как достаточно легко и просто (при отсутствии или минимальном бюджете) попасть в топ поисковой выдачи в развитых странах в нише разработки и перестать бороться за клиентов в СНГ, которые хотят круто, классно, без ТЗ (ну ты понял, бро, хотим, чтобы все было красиво) и так, чтобы за $4/час и вообще оплата по факту. В конце попробую свести все в чеклист. Кто попробует ему следовать и отпишется о результатах в комментариях, обязательно дам фидбек с советами.

Что делать, если хочется побольше узнать про нейронные сети, методы распознавания образов, компьютерное зрение и глубокое обучение? Один из очевидных вариантов — подыскать для себя какие-либо курсы и начать активно изучать теорию и решать практические задачи. Однако на это придется выделить значительную часть личного времени. Есть другой способ — обратиться к «пассивному» источнику знаний: выбрать для себя литературу и погрузиться в тему, уделяя этому всего полчаса-час в день.

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