Еще вчера я думал, что ИИ никогда не заменит меня как программиста.

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

Какие? Программа, которая превращает читабельные каракули в настоящий машинный код? Значит, теперь каждый менеджер может писать код? Мы устарели? Были ли мы автоматизированы? Пора собирать вещи и идти?

Вскоре появилось достаточно языков высокого уровня. Такие языки, как FORTRAN и COBOL. Это определенно делает ненужными настоящих программистов, не так ли? Вы можете быть инженером-механиком или бизнес-аналитиком и хорошо владеть компьютером. Вам больше не нужен программист, чтобы писать за вас код.

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

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

И хотя все эти вещи угрожали убить программирование как профессию, огромное количество программистов росло, растет и продолжает расти. И тоже экспоненциально. Каждые пять лет их число увеличивается вдвое. Население растет быстрее, чем человечество. При таких темпах все мы, все ~ 10 миллиардов будущих нас, к 2075 году будем иметь по три должности программистов.

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

Привет Хабр!

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

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

Эта статья посвящена наиболее часто используемым комбинациям клавиш при работе в командной строке Linux (в основном в командном интерпретаторе bash).

Она точно будет полезна начинающим своё знакомство с Linux и, уверен, пригодится тем, кто уже имеет опыт (не всегда годы практики учат работать быстрее).

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

Я попытался продемонстрировать многие примеры при помощи анимированных gif'ок – иногда несколько кадров больше скажут, чем несколько абзацев текста.

Приглашаем принять участие в крупнейшей технической международной конференции 2021 года Microsoft Ignite со 2 по 4 марта!

Microsoft Ignite – одно из ключевых мероприятий Microsoft – пройдет 2-4 марта 2021 года. Сатья Наделла и другие первые лица компании поделятся стратегическим видением и расскажут о важных анонсах в сфере смешанной реальности, искусственного интеллекта, облачных технологий и кибербезопасности. На конференции будут анонсированы новые инструменты для разработчиков, а также технологии и сервисы для развития бизнеса и более продуктивной работы организаций и сотрудников.

Под катом подробности про занятия на эвенте, спикеров, а также про российскую сессию!

Приглашаем на митап «Большие данные: не хайп, а индустрия» в понедельник 1 марта. Спикеры из ITSumma и Слёрма представят доклады о Big Data, ответят на вопросы участников. Будем говорить о том, как получать и обрабатывать большие данные, какие выгоды и инсайты сможет получить бизнес при правильной работе с данными и какая обработка данных принесёт вред компании.

Новое исследование пополняет чашу растущего количества фактов, указывающих на то, что кофе и чай — и, похоже, именно в больших количествах — помогают жить дольше и здоровее. В нескольких проведенных ранее исследованиях потребление кофе удалось связать со сниженным риском развития диабета 2-го типа, рака, болезни Паркинсона, депрессии и болезни Альцгеймера. Опубликованная в прошлом месяце работа связала потребление нескольких чашек кофе в день со снижением риска смерти от рака простаты на 16%. Оказалось, что люди, которые пьют чай (зеленый или черный), тоже живут дольше, и у них меньше вероятность сердечных и других смертельных заболеваний.

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

Создание пайплайнов CI с помощью Tekton (Часть 2/2)

В этой статье мы собираемся продолжить создание пайплайна CI с Tekton. В первой части мы установили Tekton на локальный кластер kind и определили нашу первую задачу, которая клонирует репозиторий GitHub и запускает тесты приложений для приложения Go (repo).

В этой части мы собираемся создать задачу, которая создаст образ Docker для нашего приложения Go и отправит его в DockerHub. После этого мы объединим наши задачи в пайплайн.

Это четвертая часть перевода книги Мохаммада Афане “Intro to Bluetooth Low Energy”. Под катом рассказ о возможностях, появившихся в новой версии стандарта а также различные методы обеспечения безопасности соединения и пользовательских данных в BLE. Мы узнаем, за счет чего стало возможно четырехкратное увеличение дальности связи, двухкратное ускорение, и почему их нельзя получить одновременно.

Уважаемые хабравчане, предлагаю вашему вниманию перевод оставшихся глав спецификации D-Bus. Полный pdf-документ можно скачать по адресу: https://vk.cc/bYQS6v

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

Спасибо за внимание.

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

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

Партнёр и управляющий фондом Movchan’s Group рассказала о том, почему перегретый рынок акций США ждёт неминуемая коррекция, как отличить хорошего управляющего от плохого, является ли биткоин пузырём, и с чего не стоит начинать инвестировать.

Я при работе с микроконтроллерами часто сталкивался с бинарными протоколами. Особенно, когда есть несколько контроллеров. Или же используется bluetooth low energy и необходимо написать код для обработки бинарных данных в характеристике. Помимо кода всегда требуется понятная документация.

Всегда возникает вопрос - а можно ли описать как-то протокол и сгенерировать на все платформы код и документацию? В этом может помочь IDL.

Это моя вторая статья на тему создания адаптивной галереи проектов на JS. На основе замечаний и комментариев к первой я постарался исправить некоторые ошибки и поработал над логикой и структурой кода. Для удобства добавил возможность просмотра галереи и полного кода в песочнице.

Цели и задачи

* Создать js-класс ImgComponent, описывающий компонент картинки галереи и принимающий следующие аргументы: тип картинки (широкая, высокая, стандартная), ссылка на изображение, ссылка на проект.

* Генерировать галерею в html.

* Реализовать механизм показа/скрытия частей галереи.

* По class.elem должен быть доступен корневой DOM элемент картинки.

Если вам еще интересно, то приглашаю к прочтению, комментариям и пожеланиям.

Всем привет! В этой статье расскажем о возможностях мониторинга производительности приложений одного из лидеров квадранта Gartner c APM-решениями — Broadcom.



Appdynamics, Dynatrace и New Relic достаточно известны на российском рынке. Broadcom чуть менее знаком, этакая серая лошадка, однако, имеет не уступающий всем троим функционал мониторинга приложений. А использование APM-решения от Broadcom в комплексе с другим их продуктом, зонтичной AIOps-системой DX Operations Intelligence, позволит создать единое окно мониторинга для разнокалиберного ПО и инфраструктуры. Под катом текст и скриншоты.

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

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

Данный пост является продолжением идей высказанных мной в предыдущем посте, если какая либо часть рассуждений кажется Вам недостаточно раскрытой возможно вы сможете найти ответ в предыдущем посте.

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

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

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

Так же предложение использовать лунный кислород одновременно дает ответ на вопрос что можно вывозить с ПЛ в столь значительных объемах на НОО земли и этот ответ тот же самый кислород.

Учитывая все выше сказанное рассмотрим повторно полет по маршруту ПЛ-НОО-ПЛ но уже опираясь на новые предпосылки. Для упрочения понимания опустим расчеты и будем оперировать уже готовыми цифрами приняв в качестве начальных данных следующие величины

I_SP = 4650 м/с

V_M1 = 1674 м/с

V_M2 = 0591 м/с

V_E2 = 3128 м/с

VE22 = V_E2 / 2 = 1564 м/с

КА на поверхности луны заправлен 680,7 тоннами топлива из которых 654,6 тонн это лунный кислород и 26,2 тонна земной водород ранее доставленный

КА стартует с поверхности луны на низкую опорную лунную орбиту расходуя 236,0 тонн топлива из которых 209,8 тонны кислород и 26,2 тонна водород. Остаток топлива 444,8 тонн кислорода.

Лекции по курсу «Управление Техническими Системами» читает Козлов Олег Степанович на кафедре «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроения» МГТУ им. Н.Э. Баумана. За что ему огромная благодарность!

Данные лекции готовятся к публикации в виде книги, а поскольку здесь есть специалисты по ТАУ, студенты и просто интересующиеся предметом, то любая критика приветствуется.

В предыдущих сериях:
1. Введение в теорию автоматического управления.
2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13.
3. ЧАСТОТНЫЕ ХАРАКТЕРИСТИКИ ЗВЕНЬЕВ И СИСТЕМ АВТОМАТИЧЕСКОГО УПРАВЛЕНИЯ (РЕГУЛИРОВАНИЯ).
3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ.

3.2. Типовые звенья систем автоматического управления (регулирования). Классификация типовых звеньев. Простейшие типовые звенья.

3.3. Апериодическое звено 1–го порядка (инерционное звено). На примере входной камеры ядерного реактора.

Тема сегодняшней статьи:
3.4. Апереодическое звено второго порядка.

Как всегда будет жестко, познавательно и интересно.

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

Но начнем мы с совершенно другой темы - с лингвистики. Предмет исследования лингвистики - человеческие языки. Это крайне сложные динамически изменяющиеся системы, хранящие в себе тонны "легаси-кода". Постоянное изменение с течением времени делает исследование языков делом иногда даже более сложным, чем исследование законов нашей Вселенной. Ведь законы физики не меняются со временем, а языки изменяются с огромной по историческим меркам скоростью, могут разниться от места к месту, делиться на диалекты и говоры, и заимствовать слова друг из друга. Прекрасным примером "легаси" в русском языке является ряд числительных десятков. В сербском и других произошедших от старославянского языках этот ряд такой - "двадесят", "тридесят", "четыредесят", "пятьдесят". В русском же "двадцать", "тридцать", "сорок", "пятьдесят". Почему "двадцать" и "тридцать" сменили суффикс с "десят" на "дцать"? Ну это ладно, почему слово "сорок" вообще не имеет корня "четыре"? Потому что на одну шубу нужно примерно 40 шкурок соболей и куниц. Абсолютно логично!

Понять, как и почему изменяются слова и правила от одной версии языка к другой - не самая сложная задача, особенно если "дифф" от версии "Русский v1.90.0" до "Русский v2.0.21" не такой уж и большой. Намного сложнее обнаружить существование этих самых правил в языке. Чтобы обнаружить грамматические законы лингвисты ставят лингвистические эксперименты, прямо как физики ставят физические эксперименты, чтобы открыть законы функционирования Вселенной. Одним из наиболее действенных способов обнаружения грамматического правила является создание искусственного примера, в котором правило нарушается. Например, прочтите следующие три предложения:

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

Например, что лучше: import module или from module import function?

Я решил разобраться в этом чуть поглубже, ответы на StackOverflow меня не удовлетворили.

Для тех, кому лень читать: все варианты хороши.