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

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

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

В преддверии DevOpsConf Виталий Хабаров взял интервью у Дмитрия Столярова (distol), технического директора и соучредителя компании «Флант». Виталий расспросил Дмитрия про то, чем занимается «Флант», про Kubernetes, развитие экосистемы, поддержку. Обсудили, зачем нужен Kubernetes и нужен ли вообще. А еще про микросервисы, Amazon AWS, подход «Мне повезет» в DevOps, будущее самого Kubernetes, почему, когда и как он захватит мир, перспективы DevOps и к чему готовиться инженерам в светлом и близком будущем с упрощением и нейросетями.

Оригинал интервью в виде подкаста послушайте на DevOps Дефлопе — русскоязычном подкасте о DevOps, а ниже — текстовая версия.



Здесь и далее вопросы задает Виталий Хабаров инженер из Express42.

Амбициозный лунный проект на 10 лет, согласно которому будут выполнены: 37 запусков с Земли, 5 посадок на поверхность с экипажем, создание первой лунной базы.

Луна снова в моде и там скоро будет тесно, на ее орбите уж точно.

Для всех хабравчан, у которых возникло ощущение дежавю: Написать этот пост меня побудили статья "Введение в Python" и комментарии к ней. К сожалению, качество этого "введения" кхм… не будем о грустном. Но ещё грустнее было наблюдать склоки в комментариях, из разряда "C++ быстрее Python", "Rust ещё быстрее C++", "Python не нужен" и т.д. Удивительно, что не вспомнили Ruby!

Как сказал Бьярн Страуструп,

«Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует».

Добро пожаловать под кат всем, кто хотел бы познакомиться с Python, не опускаясь при этом до грязных ругательств!

Многие программисты начали переходить со второй версии Python на третью из-за того, что уже довольно скоро поддержка Python 2 будет прекращена. Автор статьи, перевод которой мы публикуем, отмечает, что основной объём Python 3-кода, который ему доводилось видеть, выглядит как код со скобками, написанный на Python 2. По его словам, он и сам грешит чем-то подобным. Здесь он приводит примеры некоторых замечательных возможностей, доступных лишь тем, кто пользуется Python 3. Он надеется, что эти возможности облегчат жизнь тем, кто о них узнает.



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

Пришлось мне недавно решать задачку по оптимизации поиска дубликатов изображений.

Существующее решение работает на довольно известной библиотеке, написанной на Python, — Image Match, основанной на работе «AN IMAGE SIGNATURE FOR ANY KIND OF IMAGE» за авторством H. Chi Wong, Marshall Bern и David Goldberg.

По ряду причин было принято решение переписать всё на Kotlin, заодно отказавшись от хранения и поиска в ElasticSearch, который требует заметно больше ресурсов, как железных, так и человеческих на поддержку и администрирование, в пользу поиска в локальном in-memory кэше.

Для понимания того, как оно работает, пришлось с головой погружаться в «эталонный» код на Python, так как оригинальная работа порой не совсем очевидна, а в паре мест заставляет вспомнить мем «как нарисовать сову». Собственно, результатами этого изучения я и хочу поделиться, заодно рассказав про некоторые оптимизации, как по объёму данных, так и по скорости поиска. Может, кому пригодится.

Некоторые опции Bash хорошо известны и часто используются. Например, многие в начале скрипта пишут

set -o xtrace

для отладки,

set -o errexit

для выхода по ошибке или

set -o errunset

для выхода, если вызванная переменная не установлена.

Но есть много других опций. Иногда они слишком путано описаны в манах, поэтому я собрал здесь некоторые из наиболее полезных, с объяснением.

_{Паяльник второй половины XIX века, который нагревался на огне}

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

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

Хочу рассказать как безопасно хранить SSH-ключи на локальной машине, не боясь того, что какое-то приложение может украсть или расшифровать их.

Статья будет полезна тем, кто так и не нашел элегантного решения после паранои в 2018 и продолжает хранить ключи в $HOME/.ssh.

Для решения данной проблемы предлагаю использовать KeePassXC, который является одним из лучших менеджеров паролей, он использует сильные алгоритмы шифрования, а также имеет встроенный SSH-агент.

Это дает возможность безопасно хранить все ключи прямо в базе паролей и автоматически добавлять их в систему при её открытии. Как только база будет закрыта, использование SSH-ключей также станет невозможным.

Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы просто поговорим о DevOps, и я поделюсь своим опытом.



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

В то время, когда видеоигры ещё находились в эпохе Pac-Man, аниматоры студии Disney Фрэнк Томас и Олли Джонсон перечислили в своей книге 1981 года «The Illusion of Life: Disney Animation» то, что сегодня считается базовыми правилами анимации — 12 основных принципов.

1. Сжатие и растяжение (Squash & stretch)
2. Сценичность (Staging)
3. Подготовка, или упреждение (Anticipation)
4. Использование компоновок и прямого фазованного движения (Straight ahead & pose to pose)
5. Сквозное движение (или доводка) и захлест действия (Follow-through & overlapping action)
6. Смягчение начала и завершения движения (Slow in & slow out)
7. Дуги (Arcs)
8. Дополнительное действие (Secondary action)
9. Привлекательность (Appeal)
10. Расчёт времени (Timing)
11. Преувеличение, утрирование (Exaggeration)
12. Профессиональный рисунок (Solid drawing)

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

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

Продолжая серию заметок о менее известных функциях bash, покажу вам семь переменных, о которых вы могли не знать.

1) PROMPT_COMMAND

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

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

Попробуйте запустить это в новом шелле, и увидите, что произойдёт с сессией:

$ PROMPT_COMMAND='echo -n "writing the prompt at " && date'

Привет Хабр!
Чаще в статьях приводят вместо электрических схем красочные картинки, из-за этого возникают споры в комментариях.
В связи с этим, решил написать небольшую статью-ликбез по типам электрических схем, классифицируемых в Единой системе конструкторской документации (ЕСКД).

В последнее время появилось много фантастических исследований по 2D-рендерингу. Пётр Кобаличек и Фабиан Айзерман работают над Blend2D: это один из самых быстрых и точных CPU-растеризаторов на рынке, с инновационной техникой JIT. Патрик Уолтон из Mozilla изучил не один, а три разных подхода в Pathfinder, кульминацией чего стал Pathfinder v3. Раф Левиен построил вычислительный конвейер по технологии, описанной в научной статье Гана с коллегами о векторных текстурах (2014). Похоже, некое дальнейшее развитие получают поля расстояний со знаком: здесь независимо работают Адам Симмонс и Сара Фрискен.

Кто-то может спросить: а почему вокруг 2D так много шума? Это ведь не может быть намного сложнее, чем 3D, верно? 3D — совершенно другое измерение! Тут у нас на носу трассировка лучей в режиме реального времени с точным освещением, а вы не можете осилить невзрачную 2D-графику со сплошными цветами?

Для тех, кто не очень хорошо разбирается в деталях современного GPU, это вправду очень удивительно! Но в 2D-графике множество уникальных ограничений, которые чрезвычайно её усложняют. К тому же она не поддаётся параллелизации. Давайте прогуляемся по исторической дорожке, которая нас сюда привела.

Автор статьи, перевод которой мы сегодня публикуем, говорит, что она предназначена для тех разработчиков, которые хотят изучить Docker Compose и идут к тому, чтобы создать своё первое клиент-серверное приложение с использованием Docker. Предполагается, что читатель этого материала знаком с основами Docker. Если это не так — можете взглянуть на эту серию материалов, на эту публикацию, где основы Docker рассмотрены вместе с основами Kubernetes, и на эту статью для начинающих.

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

На EP8266 можно эмулировать «Радио-86РК», но до микропроцессора 8080 был 8008, о котором сегодня ретрокомпьютерщики вспоминают реже. Его тоже удалось эмулировать на этой платформе и запустить интерпретатор Бейсика SCELBAL.

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

Но сначала необходимо сделать одно важное пояснение – люди, о которых пойдёт речь в описании, представляли себе электричество при помощи совершенно отличных от наших категорий и концепций. Наши учебники физики упаковали разношёрстное прошлое в причёсанный набор концепций и уравнений, исключив столетия развития и конфликтов между разными философскими школами. Например, Ом никогда не писал формулу V = IR, а Максвелл не создавал уравнения Максвелла.

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

<< До этого: Из горнила войны

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

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

Однако ничего этого бы не произошло, если бы изобретение транзистора остановилось бы на работе Бардина и Бреттейна.