В 2022 году исполняется 50 лет со времен публикации знаменитого документа «Пределы роста», подготовленного Римским Клубом. Это был обзор технологических и общественных тенденций, характерных для конца XX века – в целом сводившийся к мысли, что гибкость рынка и бережливое отношение к природе не компенсирует ее истощения. В 2014 году на русском языке вышла книга «Пределы роста: 30 лет спустя». Значительное внимание в книге уделяется возобновляемым источникам энергии, в частности – солнечным батареям и ветрофермам. Рисунок 3.15 из этой книги демонстрирует, что к началу XXI века стоимость солнечного кВт⋅ч в целом стабилизировалась после многолетнего нисходящего тренда, а стоимость ветряного кВт⋅ч продолжала снижаться.

Вне Хабра нам довелось затронуть эту тему с уважаемым @SLY_G, и он навел меня на интересные источники и идеи, указывающие на чрезмерный оптимизм по поводу ветроэнергетики, ее краткосрочных эффектов и углеродного следа. Скептические оценки крупномасштабной ветроэнергетики впервые получили научное обоснование в 2011-2013 годах – правда, пока они основаны в основном на эмпирических догадках и компьютерном моделировании. Далее я хотел бы раскрыть эту тему подробнее.

Привет! Меня зовут Павел Лакосников, я тимлид команды бэкенд-инженеров в Авито. Сегодня расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.

Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Flow, с акцентом на моего фаворита — Trunk Based Flow.

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

Это огромная дилемма: что нам делать в ближайшие нескольких столетий? Пока что, как ни посмотри, перспективы выглядят довольно печальными. Если в крупных городах Китая баллоны с чистым воздухом, которым можно дышать, — уже один из ходовых товаров, то что будет дальше?

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

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

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

А это сразу ссылка на часть 2.

Design Automation Conference (DAC) - главная выставка софтверных компаний, которые создают средства проектирования чипов. Именно на ней появляются стартапы, которые определяют проектирование через 10-15 лет (например появление Synopsys на рубеже 1980-1990-х привело к появлению iPhone в середине 2000-х).

На DAC помимо выставки и официальных докладов есть также и poster session - молодые исследователи из университетов вывешивают в виде плакатов, чем они занимаются. Я методически сфотографировал все постеры во время последней конференции DAC в Сан-Франциско, и вот перед вами картина маслом:

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

Меня зовут Максим Кульгин, моя компания (xmldatafeed) занимается парсингом сайтов в России порядка четырёх лет. Ежедневно мы парсим более 500 крупнейших интернет-магазинов в России. Теперь делимся опытом с вами. Так как тема парсинга часто привлекает внимание и вызывает эмоции (в массе негативные), подготовил статью, где ответил на основные вопросы (их получилось 43) с которыми сталкивались в процессе работы и, надеюсь, развеял некоторые мифы.

1. Можно ли зарабатывать на парсинге? Да. Мы стали активно заниматься этим бизнесом в 2018 году и с тех пор к счастью растем. Привожу открытые налоговые данные. В 2022 году надеемся, что результат будет чуть лучше.

Ссылки

• unreal rust на github
• Devlog на Youtube

Введение

Доллар и госдолг США во всех финансовых учебниках приводятся в качестве примера «безрискового» актива с наивысшей надежностью. Но не все знают, что Дядя Сэм допускал дефолт не раз, и даже не два. В этой статье мы немножко занырнем в финансовую историю Америки, а также выясним – насколько реальна угроза дефолта Штатов сейчас.

Давайте проведём исследование некоторых взаимосвязей функций, объектов, генераторов и корутин в Python.

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

Предупреждаю: мы рассмотрим рабочие, но очень странные примеры кода; я не советую вам применять их в реальных проектах!

Привет, username! Меня зовут Иван Васенков и я джуниор дата-инженер в дирекции данных и аналитики Lamoda. Но к этой профессии я пришел не сразу: окончив университет, я начал работать аналитиком данных, затем стал BI-разработчиком, а уже после этого — дата-инженером.

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

Привет, Хабр! Меня зовут Рустам, работаю программистом 9 лет. 7 лет работал в Контуре и около 2 лет в Яндексе. В этой статье расскажу про свой опыт подготовки и прохождения собеседований в большие технологические компании, поделюсь рекомендациями.

Пробовался в Facebook, Apple, Amazon, Microsoft, Google. Пять попыток: четыре на бэкенд программиста, одна на инженера по инфраструктуре. Два предложения по работе, два отказа, одно потенциальное предложение.

Принял предложение в Amazon. Сейчас в Лондоне.

В этой подборке — не только классические рекомендации книг для C++ программистов. Обычно советуют издания про паттерны, развитие стандарта или успехи большой компании. Но за всем этим изобилием «экспертных советов» и best practices теряется одна простая мысль: язык программирования — это средство выражения мысли от одного разработчика другому, а также средство описания пользовательского API в самом широком смысле.

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

Первые 5 книг этой подборки — в меньшей степени про технику, в большей степени об осознанности деятельности C++ программистов любого уровня. Остальные — «золотой фонд» классической литературы для C++ разработчиков.

• Удалённый доступ — логично, ведь для этого он и предназначался.
• Монтирование папок по сети — очень удобно для работы с кодом на удалённой машине.
• Удалённое выполнение команд — нечастая, но используемая мной операция. Удобно получать выхлоп команды в канал другой команды на текущей машине.
• Запуск графических приложений на удалённой машине.
• Проксирование трафика — способ перенаправления трафика. Этакий быстрый и простой аналог VPN.
• Обратный ssh — использую для проброса портов к системам, находящимися за NAT, когда лень настраивать firewall.

Привет, Хабр!

В последние несколько лет все больше и больше людей ищут возможность войти в ИТ или поглубже изучить Linux, повысив уровень своей квалификации. Вместе с тем полноценных обзоров с практическом уклоном по типу «все и сразу» написано не так уж и много (особенно на русском языке).

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

Асинхронное программирование в однопоточных средах JavaScript

Оглавление

1. Введение в асинхронное программирование

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

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

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

Привет! Меня зовут Леонид, я DevOps-инженер в компании KTS. 

В этой статье я рассмотрю различные оркестраторы и объясню, почему Kubernetes — лучший выбор.

Нашей компании уже 6 лет, и 4 из них мы живем с Kubernetes. До этого мы испытали все варианты деплоя приложений на серверах: начиная от простого git pull до ci/cd на нескольких серверах. 

За небольшой срок в 4 года мы набрали много опыта. Начинали с вопроса, который, возможно, стоит сейчас перед вами: «Какой оркестратор выбрать?» Мы рассмотрели разные варианты, и в итоге остановились на Kubernetes. В статье расскажу, почему.