Джорджо де Кирико. Великий метафизик (The Grand Metaphysician), 1917.

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

1) CS — создание подходов, имеющих научную новизну. Разработка новых алгоритмов. Основная цель: научная новизна, развитие CS, решение проблем CS.

2) Инженерно-конструкторская деятельность – комбинирование уже известных подходов (алгоритмов, ЯП, библиотек, технологий, исходных кодов), их адаптация под конкретную задачу. Основная цель: создание продукта для решения конкретной практической задачи.

3) Техническое обеспечение — решение типовых (зачастую тривиальных) проблем в ходе эксплуатации “железа” и софта. Обеспечение бесперебойной работы ПО и оборудования с учетом возникающих требований.

Очевидно, что в такой классификации риск неудачи убывает в каждом пункте. При работе над новым алгоритмом или устройством обычно невозможно полностью гарантировать успех. При использовании уже известных алгоритмов, языков, технологий, библиотек и готовых деталей машин – вероятность успешного исполнения работы возрастает. В последнем случае (обеспечение ) работник (должность может быть разная: инженер, системный программист, системный администратор и т.д.) исходит из минимизации замен по принципу: “не трогать то, что хорошо работает”.

Как видим цели противоположные: для научной новизны бывают нужны новые рискованные решения, а для обеспечения – наоборот. Для успешной разработки продукта, желательно применять уже опробованные зарекомендовавшие себя решения, хотя при их отсутствии может понадобится и эксперимент, как в CS.

Кому и насколько в IT нужна математика? — Попробуем ответить на этот вопрос (хотя бы частично).

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

Энкодер - это устройство преобразования механического перемещения или угловых изменений положения в цифровой сигнал. В статье рассматривается самый популярный в DIY сообществе инкрементальный энкодер EC11 с кнопкой. При его вращении на выходах A и B формируются TTL сигналы в виде импульсов сдвинутые между собой по фазе на 90 градусов. Таким образом с его помощью, можно определить направление и скорость вращения, а так же рассчитать угол поворота. В отличие от потенциометров, KY-040 он надежный и долговечный.

Всем привет!

Продолжаем дайджесты новостей и других материалов о свободном и открытом ПО и немного о железе. Всё самое главное про пингвинов и не только, в России и мире.

Главные темы нового выпуска:

1. Microsoft удалил функциональность Hot Reload из открытого .NET для поставки только в Visual Studio 2022 и… вернул обратно.
2. Astra Linux Special Edition для ARM сертифицирована по 2 уровню доверия.
3. Основанный Яндексом стартап ClickHouse стал «единорогом».
4. Intel Core i9 11900K: пять дистрибутивов Linux продемонстрировали значительное превосходство над Windows 11.
5. 10 ноября, 2021 — Enterprise Open Source Summit: Взгляд со стороны бизнеса на открытый исходный код.
6. Российская компания YADRO присоединилась к инициативе по защите Linux от патентных претензий.
7. Какова цель Open Source Security Foundation. Интервью со старшим вице-президентом Linux Foundation Дереком Уиксом.
8. На ММСО эксперты «Базальт СПО» показали педагогам: с ОС «Альт» работать просто, интересно и полезно для карьеры.
9. Кураторы от «Базальт СПО» участвуют в проведении международного конкурса «Школа реальных дел 2021-2022» и приглашают к участию.
10. Проект Kerla развивает Linux-совместимое ядро на языке Rust.
11. Алексей Смирнов рассказал журналистам о том, что способствует и мешает широкому распространению российского свободного ПО.
12. Обзор kubenav для управления Kubernetes-кластерами со смартфона.

И многое другое…

В составлении дайджеста мне помогали qark, invasy и 8 пользователей через нашего Telegram бота [→]

Ещё — мы не только составляем FOSS дайджесты, но и автоматизируем процесс, все 3 проекта автоматизации тоже являются FOSS, их можно посмотреть на GitHub [→]. На очереди ML и мы собираем средства на хакатоны [→], будем рады если читатели помогут, всё ведь для вас.

Развёртывание в Kubernetes из GitLab

Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.

А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.

Желательны но необязательны базовые знания

• Docker;
• Kubernetes;
• Git;
• Node.js;
• React;
• Bash.

В дальнейшем мы сделаем следующее.

• 🧱 Познакомимся c нашим приложением, обсудим из чего оно состоит.
• 🐳 Докеризуем наше приложение.
• ☸️ Развернём наше приложение в Kubernetes локально на Docker Desktop.
• ☁️ Обсудим особенности GCP и как нужно изменить наше приложение, а затем ещё раз развернём наше приложение в Kubernetes но уже в GCP.
• 🦊 Завершим наш туториал созданием конвейера для развертывания приложения в GCP при помощи GitLab.

Привет, Хабр! В прошлом посте мы уже рассказывали о том, что происходило на первом дне Acronis #CyberFit Summit в Майами. Сегодня пришло время подвести итоги второго дня, в ходе которого проходил завтрак Woman in Tech, обсуждение прибыльности работы провайдеров, беседа с бывшим переговорщиком ФБР Крисом Воссом, а также круглый стол по вопросам перспектив отрасли киберзащиты. Если вы принимали участие в нашем гибридном мероприятии или хотели бы это сделать, добро пожаловать под кат.

В свое время мне понадобилось обернуть написанный модуль в библиотеку. Порядочно погуглив, я нашел кучу туториалов, суть которых - создается библиотека с одним-двумя .swift - файлами. У меня же был целый проект, да еще с подами (а ля Alamofire, Moya, EasyPeasy и др), и создание библиотеки именно этим и усложнялось, было непонятно как переносить поды, нужно ли их вообще переносить и как в целом правильно сбилдить такую библиотеку.

Всем доброго времени суток.

В данной статье я решил поделиться опытом, накопленным за многие годы работы во front-end`е. Как и все вы, я был молод и мечтал создать что-то бессмертное. Ах, как я был молод, и как же я был глуп. Ничего вечного не существует и всё рано или поздно умирает. Однако, можно создать то, что протянет гораздо дольше обычного и даже будет адаптироваться к изменениям какое-то время. Поэтому сегодня предлагаю поговорить о паттернах проектирования для front-end приложений, выборе технологий и о том, чего делать не стоит. В этой статье буду проводить много аналогий со строительной тематикой и причиной тому небезызвестная история: «Если бы программисты строили дома».

Из чего строить? 

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

Посмотрим и на обратную сторону медали: беря сверхнадежное решение, которому много лет, вы обрекаете проект на скорый апдейт или умирание. Знавал я одну крупную компанию, которая использовала java 8. Мотивация звучала так: она надежна как швейцарский нож.  На минуточку, на дворе 2021 год и она устарела не только морально, но и технически (на момент написания, актуальной версией является java 17). 

На этой неделе сценарист фильма «Дюна» Дени Вильнёв рассказал, что писал сценарий в программе Movie Master на MS-DOS — так как не любит перемен. И пока такие энтузиасты используют старое программное обеспечение в силу привычки, другие идут гораздо дальше в своих начинаниях и возвращают интернет во времена, когда страницы были минималистичны, а протоколы — проще сегодняшних.

Всё изначально пошло не так.

Привет, хабравчане. С детства мне нравились цифры и возможность измерить всё и вся. Когда в средней школе я увлекся шахматами, побочным эффектом оказалось знакомство с системой рейтинга Эло. Мне (как и многим другим людям в мире) она показалась удобной и логичной, и с тех пор ко мне периодически возвращалась идея применения этой системы к разнообразным спортивным соревнованиям. Первой попыткой было её применение к многострадальному чемпионату России по футболу, и было мне тогда лет 13. Поскольку на тот момент я не только не владел навыками программирования, но даже элементарно не имел компьютера, все расчеты велись в тетрадке, что делало поддержание информации в актуальном состоянии довольно трудоемкой задачей. Спустя годы я вернулся к этой идее, выбрав своей мишенью НХЛ.

Представьте: у вас есть таблица с данными, которые можно редактировать. Как мы это оформим?

Эта статья является переводом материала «TDD: What went wrong or did it?».

В сфере разработки программного обеспечения уже давно хвалят Test Driven Development (TDD, разработка через тестирование). Однако в последнее время было сказано много резких слов в адрес TDD, поскольку его обвиняют в плохом проектировании программного обеспечения и невыполнении многих своих обещаний. Кульминацией этой тенденции стал пост Дэвида Хайнемайера Ханссона «TDD is dead. Long live testing.» (TDD мертв. Да здравствует тестирование).

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

Привет, Хабр! Когда я изучал паттерны проектирования, я делал это с помощью прочтения двух книг: простую и понятную книгу от Head First одновременно со сложной и менее понятной книгой от Банды Четырех. Ниже описан мой опыт того, как именно я это делал, плюс выводы, впечатления и советы

Максимально переложив ответственность за онлайн своего приложения, ты сможешь сфокусироваться на других задачах, думать больше о новых фичах и новых приложениях. Ведь попробуй просто представить себе, как ты с утречка начинаешь поднимать 20 ботов на своём бедном Lenovo в надежде, что сегодня ни свет, ни интернет не выключится? Представил? А теперь представь если 20 ботов висят на сервере и ты с утра заходишь, смотришь какой у них статус с помощью удобного дашборда. Так и 21е приложение не за горами будет :)

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

Выглядит как промо за 50$, но на самом деле я был поражен лишь тем фактом, что если зайти на цены, то там есть раздел Hobby. Это на моей памяти первый случай, когда сервис есть в бесплатном виде, чтобы поддерживать начинания разработчиков, и потом, когда идея окажется работоспособной, тут же можно понемногу увеличивать возможности своего сервиса. Только за это уже можно читать дальше, разве нет?