User
Работая на MacBook с Docker Desktop, я часто сталкивался с тем, что система становилась менее отзывчивой, особенно при запуске нескольких контейнеров одновременно. Высокая нагрузка на CPU и память заметно влияла на время автономной работы.
Но недавно я наткнулся на OrbStack, и это изменило мой рабочий процесс настолько, что я решил поделиться своим опытом. Спойлер: теперь мой MacBook не превращается в печку, батарея держится дольше, а Docker-контейнеры летают.
Привет, Хабр!
В этой статье я расскажу о своем опыте изучения английского языка и поделюсь вещами которые работали и не работали для меня. Процесс изучения языка очень индивидуален, и никогда нельзя утверждать что верный какой-то один метод / схема (хотя некоторые статьи на Хабре прямо говорят: вот этот метод правильный, а вот этот нет).
Начнем с бекграунда и причин.
Я – инженер машиностроитель (мой профиль – торцевые уплотнения вращающихся валов). Я начал работать в своей отрасли сразу после бакалавра, параллельно заканчивая магистратуру, и как только я начал работать, я стал стараться впитать как можно больше теоретических знаний по моей специальности из академических источников. Достаточно бысто я понял, что последняя серьезная книга по моей специальности на русском языке была написана в 1978 году. И спустя больше чем 40 лет технологии сильно поменялись, а вот их описание на русском языке отсутствовает. Зато я нашел на reddit людей работающих в штатах в моей же отрасли. Они мне насоветовали кучу классной литературы. Разумееется, она вся на английском, и русского перевода не имеет.
Начал свой путь изучения языка я в январе 2022 года с около нулевого уровня. В всех моих школах преподование английского языка было не на самомом высоком уровне, а в университете было достаточно выучить 30 предложений наизусть чтобы получить достойную оценку на экзамене.
Конечно, перед началом обучения я прочитал много статей на хабре о том как люди учат языки. Некоторые из них поражали скоростью овладения материалом (что-то вроде с нуля до fluent за 4 месяца). Но одна вещь была неизменна – у всех был какой-то план изучения языка.
О сложных системах простыми словами.
В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.
Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.
Возможно, немного другой формат шпаргалки покажется вам более удобным.
Для того чтобы повысить качество приложения, написанного на языке go, можно использовать разные линтеры. Один из таких линтеров — архитектурный.
В данной статье расскажу про свой бесплатный, open-source, линтер под MIT лицензией и чем он может быть полезен.
В статье посмотрим на Go Garbage Collector — механизм автоматического освобождения невостребованной памяти приложения в Go. Разберём его устройство и принципы работы.
Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.
Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.
В этой статье я рассмотрю причины такого подхода, его недостатки, а также способы решения проблем, к которым он приводит. Я выделила несколько основных принципов, которые помогут прийти к чистой истории изменений проекта. Давайте же вместе исследуем эту темную, неизведанную сторону Git, которая нам в этом поможет.
Откройте любую статью с обзором HTTP/1.1. Скорее всего, там найдётся хотя бы один пример запроса и ответа, допустим, такие:
GET / HTTP/1.1
Host: localhostHTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 38
Content-Type: text/html; charset=utf-8
<!DOCTYPE html>
<h1>Привет!</h1>Теперь откройте статью с обзором HTTP/2 или HTTP/3. Вы узнаете о мультиплексировании запросов, о сжатии заголовков, о поддержке push-технологий, но вряд ли увидите хоть одно конкретное сообщение. Ясно, почему так: HTTP/1.1 — текстовый протокол, тогда как сиквелы к нему бинарные. Это очевидное изменение открывает дорогу ко множеству оптимизаций, но упраздняет возможность просто и доступно записать сообщения.
Поэтому в этой статье предлагаю покопаться в кишках у HTTP/2: разобрать алгоритмы установки соединения, формат кадров, примеры взаимодействия клиента с сервером.
Javascript ― язык весьма оригинальный. Его можно любить, ненавидеть и даже бояться, но равнодушным он вас вряд ли оставит. Не знать или не понимать, с чем ты работаешь ― самая частая ошибка, допускаемая современными фронтенд‑разработчиками. Вам бы понравилось, если бы дантист, к которому вы пришли, не понимал, какой он инструмент использует и какие у него особенности работы? Очевидно, что нет. И рано или поздно, если вы действительно хотите стать профессионалами, вы разберётесь во всём, но как сделать так, чтоб это случилось раньше?
В этой статье в блоге ЛАНИТ хотелось бы показать, что о сложных вещах можно и нужно говорить просто.
Создать хорошее приложение непросто. Какое бы уникальное и полезное приложение вы ни написали, если оно не нравится пользователю, то у вас, как говорится, a big problem. Большинству людей не нравится и отпугивает все, что им непонятно. Зачастую пользовательский интерфейс и письма — это та видимая верхушка айсберга вашего приложения, по которой пользователь его оценивает. Поэтому локализация всего, что видит пользователь, крайне важна.
Вспомните, как еще десять лет назад, когда интернет только начинал входить в жизнь масс, а многие сегодняшние IT-гиганты находились в стадии стартап-карликов с парой десятков сотрудников, в порядке вещей было отправить пользователю письмо на английском. И пользователи относились к этому с пониманием. Сегодня же, когда в интернете присутствуют все и не нужно быть семи пядей во лбу, иметь высшее образование или знать английский, чтобы им пользоваться, считается дурным тоном не поддерживать в своем приложении локализацию. К слову, в нашей компании локализация всех текстов UI уже осуществляется на 20 языков и список поддерживаемых языков постоянно растет.
В Go, как в довольно молодом языке, все современные тренды веб-разработки реализованы на уровне базовых пакетов и не требуют дополнительных «танцев с бубном». (Я начал изучать Go несколько лет назад, но до сих пор помню то ощущение «открывшихся сверхспособностей», которое испытывал первые дни после знакомства с этим языком. Казалось, теперь я могу реализовать любую задачу, написав всего пару строк.)
Конечно, не обошли в Go стороной и локализацию. Локализация в нем доступна практически «из коробки» с помощью базовых пакетов: golang.org/x/text/language, golang.org/x/text/message и golang.org/x/text/feature/plural. Давайте рассмотрим, как просто в Go всего за полчаса, используя эти пакеты, можно реализовать такую нетривиальную задачу, как локализация писем.
Многие сейчас временно или навсегда релоцируются из РФ. При этом задача вывоза накопленных внутри страны денег часто оказывается непростой. В этом гайде я систематизировал все работающие на текущий момент способы, которыми поделились участники нашего сообщества RationalAnswer.
dig, но есть также и новые, нестандартные применения старого механизма.
Привет, Хабр! Меня зовут Вова, я разрабатываю observability-платформу в Ozon. Как-то раз в наш уголок на 42 этаже заглянули коллеги — и поделились наблюдением. Если открыть рядом графики времён запросов и ответов двух живущих в Kubernetes и общающихся между собой микросервисов, то иногда можно наблюдать большую разницу в высоких квантилях: клиент считает, что один ответ из сотни ему приходит за сто миллисекунд, сервер же говорит, что успевает ответить за десять.
Куда ушло время? Можно ли его вернуть? Под катом расскажу о том, с какими граблями может столкнуться микросервис, живущий в типичной инсталляции Kubernetes.
runtime.scanobject) потребляет значительную долю выделенных вычислительных ресурсов.
