Привет, Хабр! Представляю вашему вниманию перевод статьи "Anatomy of Channels in Go" автора Uday Hiwarale.

Что такое каналы?

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

Создание канала

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

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

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

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

Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.

Возможно, мы никогда не сможем прийти к эмпирическому определению «хорошего кода» или «чистого кода». Это означает, что мнение одного человека о мнении другого человека о «чистом коде» обязательно очень субъективно. Я не могу рассматривать книгу Роберта Мартина «Чистый код» 2008 года с чужой точки зрения, только со своей.

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

15 лет мы, производство компании Антиплагиат, жили в простых и гармоничных отношениях с бизнесом и пиаром. Сначала мы выкатывали новый функционал на прод. Затем пиар начинал его пиарить: писать новости, пресс-релизы, давать интервью и т.п. Ничего, собственно, не мешало развиваться таким отношениям и дальше, пока… Хотя нет, обо всем по порядку.

В конце 2019 года мы провели стратегическую сессию: озвучили и записали большое количество идей, которые лежали в головах разработчиков, тестировщиков, аналитиков, devops'ов, в общем, того самого производства. Посмотрев на наши идеи, руководство (а вместе с ним и пиар) решилось на отчаянный шаг – дать производству самому рассказать о наших идеях, собрать отклики, продвинуть на рынок. Эта статья – первый пробный шажок простых производственных парней по неизведанной планете под названием «рынок».

А еще мы выиграли грант РВК на развитие искусственного интеллекта в области обработки текстов на естественном языке. Поэтому почувствовали себя обязанными обрисовать ближайшие планы.

Привет, Хабр! Представляю вашему вниманию перевод статьи «Scheduling In Go: Part I — OS Scheduler» автора Билла Кеннеди, о том, как работает внутренний планировщик Go.

Это первый пост в серии из трех частей, который даст представление о механике и семантике, лежащей в основе планировщика в Go. Этот пост посвящен планировщику операционной системы. Начнем!

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

Тимлиды часто оценивают проекты, и не все делают это хорошо. Тут многое зависит от личности самого тимлида, а также от его понимания команды. Есть много техник оценки проектов от метода “по аналогии” до PERT. Но сегодня я расскажу о том, как я применяю planning poker и другие приемы, чтобы оценивать точнее и с большей пользой.

Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.

Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.

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



Тем, кому не терпится приступить к практике, автор предлагает использовать в существующих Python-проектах Flake8, pytest и Sphinx. Он, кроме того, рекомендует взглянуть на pre-commit, Black и Pylint. Тем, кто планирует начать новый проект, он советует обратить внимание на Poetry и Dependabot.

Проектировщики самолёта отвечают на вопрос о его безопасности:
— Ничто не вечно, но современные авиалайнеры невероятно устойчивы, а самолёт — самый безопасный транспорт в мире.
Инженеры-строители отвечают о безопасности лифтов:
— Лифты защищены множеством отказоустойчивых механизмов. Их практически невозможно уронить в свободное падение.
Программисты отвечают на вопрос об электронном голосовании:
— Это просто ужасно.
— Серьёзно?
— Абсолютно. Не доверяйте программам для электронного голосования и не верьте никому, кто уверяет в их надёжности.
— Почему?
— Не совсем знаю, как это выразить, но вся наша область плоха в том, что мы делаем, и если вы будете полагаться на нас, то все умрут.
— Говорят, что надёжность гарантируется технологией под названием «блокчейн».
— А-а-а-а-а!!! Что бы они ни говорили, не прикасайтесь к этому! Закопайте поглубже. Не забудьте перчатки!
Источник: XKCD, лицензия Creative Commons 2.5

Глюк мобильного приложения для подсчёта голосов на прошлой неделе добавил хаоса на Съезде фракций Демократической партии в Айове. Через несколько часов после открытия собраний по всему штату стало ясно: что-то пошло не так. Результаты неизвестны до сих пор. Появились сообщения с описанием технических проблем и недоразумений. Демократическая партия Айовы опубликовала заявление, в котором отрицает слухи о кибератаке, но подтверждает технические проблемы с мобильным приложением.

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

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

Всвязи с этим, "Руководство компании Google по проведению ревью" выглядит очень ценным документом, перевод первой части которого и представлен далее. Переводы остальных частей выйдут позже отдельными постами. Стоит отметить, что это адаптированный перевод, не все переведено слово-в-слово, во имя более русских формулировок и предложений.

Терминология:

CL: "changelist" — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

Key promoter X

Использование сочетаний клавиш вместо мыши может значительно повысить производительность. С таким количеством функций, которые предлагает IDEA, это может быть пугающим и трудным для изучения всех быстрых клавиш. К счастью, есть плагин под названием Key Promoter X, который может вам помочь.

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

В мире JVM про корутины знают в большей степени благодаря языку Kotlin и Project Loom. Хорошего описания принципа работы котлиновских корутин я не видел, а код библиотеки kotlin-coroutines совершенно не понятен неподготовленному человеку. По моему опыту, большинство людей знает о корутинах только то, что это "облегченные потоки", и что в котлине они работают через умную генерацию байткода. Таким был и я до недавнего времени. И мне пришла в голову идея, что раз корутины могут быть реализованы в байткоде, то почему бы не реализовать их в java. Из этой идеи, впоследствии, появилась небольшая и достаточно простая библиотека, в устройстве которой, я надеюсь, может разобраться практически любой разработчик. Подробности под катом.

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

Если вы уже писали код который используется больше чем в одном месте, то вам знакома такая ситуация:

1. Вы создаете многократно используемый фрагмент кода (это может быть функция, React компонент, React хук и тд) и делитесь им (для совместной работы или публикуя в опенсорс).
2. Кто-то обращается к вам с просьбой добавить новый функционал. Ваш код не поддерживает предложенный функционал, но мог бы, если бы вы сделали небольшое изменение.
3. Вы добавляете новый аргумент/проп/опцию в свой код и в связанную с ним логику для поддержания работы этого нового функционала.
4. Повторите стадии 2 и 3 несколько раз (или много-много раз).
5. Теперь ваш повторно используемый код тяжело использовать и поддерживать.

Что именно делает код кошмаром для использования и поддержки? Есть несколько аспектов, которые могут сделать ваш код проблемным:

Введение

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

Мы начинаем серию постов, в которой продемонстрируем некоторые из множества возможностей сервисной сетки Istio Service Mesh в сочетании с Red Hat OpenShift и Kubernetes.



Часть первая, сегодняшняя:

• Объясним концепцию sidecar-контейнеров Kubernetes и сформулируем лейтмотив этой серии постов: «вам не надо ничего менять в своем коде».
• Представим основополагающую вещь Istio – правила маршрутизации. На них строятся все остальные возможности Istio, поскольку именно правила позволяют направлять трафик к микросервисам, используя для этого внешние по отношению к коду сервисов файлы YAML. Также рассматриваем схему развертывания Canary Deployment. Новогодний бонус – 10 интерактивных занятий по Istio

Дошли руки до книги Чеда Фаулера «Программист-фанатик».

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

Очень хотелось назвать статью «Proxy-сервис на Go в 3 строчки», но я выше этого.

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

proxy := httputil.NewSingleHostReverseProxy(url)
r.Header.Set(header, value)
proxy.ServeHTTP(w, r)

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

Разберём, для чего нужен прокси-сервис, как его реализовать и что под капотом у стандартной библиотеки.

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

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

В данной статье речь пойдет о машинном обучении как части искусственного интеллекта. ИИ во многом подразумевает под собой разговорную составляющую, ведь общение – то, что делает нас людьми. Соответственно, если мы будем делать системы, которые могут нас понимать, отвечать на наши слова, мы в какой-то степени приблизимся к разработке искусственного интеллекта. Однако это все теория на грани философии. Давайте перейдем к практике.