Если кратко описать, что такое лексикографический порядок — это сортировка в алфавитном порядке. Т.е. последовательность символов — AAA → AAB → AAC → AAD → ……… → WWW — является отсортированной в алфавитном (или в нашем случае лексикографическом) порядке.

Представьте, что у Вас есть конечная последовательность символов, например 0, 1, 2, 5, 3, 3, 0 и Вам необходимо найти все возможные перестановки этих символов. Наиболее интуитивным, но и наибольшим по сложности, является рекурсивный алгоритм, когда мы выбираем первый символ из последовательности, далее рекурсивно выбираем второй, третий итд, до тех пор, пока все символы из последовательности не будет выбраны. Понятно, что сложность такого алгоритма — O(n!).

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

Если вы считаете консистентность важной составляющей качественного кода — эта статья для вас.

Вас ждут:

• Разные способы сделать одно и то же в Go (эквивалентные операции)
• Менее очевидные факторы, влияющие на однородность вашего кода
• Способы увеличения консистентности вашего проекта

Перевод статьи разработчика компании Samsara об опыте использования Go на автомобильном роутере с 170MB оперативки.

В компании Samsara мы разрабатываем автомобильные роутеры, которые предоставляют в реальном времени телеметрию двигателя через CAN шину, данные с беспроводных термосенсоров через Bluetooth Low Energy и соединение по Wi-Fi. Эти роутера очень ограничены по ресурсам. В отличие от серверов с 16 GB оперативной памяти, у наших роутеров есть всего 170MB и всего одно ядро.

Наша новая камера CM11, закреплённая в кабине.

Чуть ранее в этом году мы выпустили видео камеру, которая крепится внутри кабины, чтобы улучшить безопасность машин для наших клиентов. Эта камера, по сути, является периферийным устройством для нашего роутера, которое генерирует много данных. Она записывает 1080p H.264 видео с частотой 30 кадров в секунду.

Наша первая реализация сервиса работы с камерой, который был отдельным процессом на роутера, потреблял 60MB, то есть почти половина всей доступной памяти, но мы знали, что можем добиться лучших результатов. Мы буферизировали только 3 секунды видео потока на 5Mpbs, и 60MB было достаточно, чтобы удерживать в памяти целых 90 секунд видео, так что мы решили посмотреть, где мы можем уменьшить использование памяти.

Перевод отрывка из интервью с создателем Node.js Раяном Далом (Ryan Dahl) в котором обсуждается модель программирования и язык Go.

— Расскажи нам, как проходила начальная разработка Node? Это ведь уже было достаточно давно, ты создал Node в 2009.

Райан: — Я думаю для себя лично, что нет лучшего момента в жизни, когда ты, как это говорится, «в потоке» и у тебя есть идея, в которую ты сильно веришь. И при этом есть время, чтобы сесть и на самом деле работать над ней. И я думаю, Node была именно такой идеей, которая ждала, чтобы её кто-то ухватил, и если бы не я, то это бы сделал кто-то другой. Но так случалось, что я был тогда достаточно свободен от работы и имел время, и мог работать нон-стоп несколько месяцев, которых как раз были нужны, чтобы выкатить начальную версию. Так что да, это был отличный период.

— Отлично, супер. Node построена на идее «полностью асинхронной» модели программирования. Удачна ли она была для Node?

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

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

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

Многие знакомы с gRPC — открытым RPC-фреймворком от Google, который поддерживает 10 языков и активно используется внутри Google, Netflix, Kubernetes, Docker и многими другими. Если вы пишете микросервисы, gRPC предоставляет массу преимуществ перед традиционным подходом REST+JSON, но на существующих проектах часто переход не так просто осуществить из-за наличия уже использующихся REST-клиентов, которые невозможно обновить за раз. Нередко общаясь на тему gRPC можно услышать "да, мы у нас в компании тоже смотрим на gRPC, но всё никак не попробуем".

Что ж, этой проблеме есть хорошее решение под названием grpc-rest-gateway, которое занимается именно этим — автогенерацией REST-gRPC прокси с поддержкой всех основных преимуществ gRPC плюс поддержка Swagger. В этой статье я покажу на примере как это выглядит и работает, и, надеюсь, это поможет и вам перейти на gRPC, не теряя существующие REST-клиенты.

На этой неделе мы отмечаем 10-летнюю годовщину создания Go.

Всё началось с обсуждения вечером в четверг, 20 сентября 2007. Оно привело к организованной встрече между Робертом Грисмайером, Робом Пайком и Кеном Томпсоном в 2 часа дня на следующий день в конференс-руме Yaounde в Здании 43 главного кампуса Google Mountain View. Название для языка появилось 25-го числа, несколько сообщений спустя после начала переписки о дизайне:

Тема: Re: обсуждение языка программирования 
От: Роб 'Коммандер' Пайк 
Дата: Вт, Сен 25, 2007 в 3:12 PM
Кому: Роберт Грисмайер, Кен Томпсон    

у меня появилась пара мыслей по этому поводу на пути домой.

1. имя

'go'. можно найти оправдания для такого имени, но у него очень хорошие свойства.
оно короткое, легко печатать, например: goc, gol, goa. если будет интерактивный 
дебаггер/интерпретатор, он может быть просто назван 'go'. расширение файла .go
...

Одним из нововведений в Go 1.9 было добавление в стандартную библиотеку нового типа sync.Map, и если вы ещё не разобрались что это и для чего он нужен, то эта статья для вас.

Для тех, кому интересен только вывод, TL;DR:

если у вас высоконагруженная (и 100нс решают) система с большим количеством ядер процессора (32+), вы можете захотеть использовать sync.Map вместо стандартного map+sync.RWMutex. В остальных случаях, sync.Map особо не нужен.

Если же интересны подробности, то давайте начнем с основ.

Если вы хоть раз были сбиты с толку, что означает символ "амперсанд" (&) или "звёздочка" ("знак умножения", *) или запутывались, когда что использовать, то это статья для вас. Авторы Go старались сделать язык знакомым большинству программистов, и многие элементы синтаксиса заимствовали из языка С. Но в 2017м уже сложно понять, большинство программистов владеют С или нет, и смею полагать, что уже нет. Поэтому концепции хорошо знакомые прошлому поколению разработчиков, могут выглядеть совершенной абракадаброй для для нового поколения. Давайте немного копнём историю и расставим все точки над ї в вопросах указателей в Go и использования символов & и *.

Содержание: Чтобы выучить Go, я портировал свой бекенд небольшого сайта с Python на Go и получил забавный и безболезненный опыт в процессе.

Я хотел начать учить Go какое-то время — мне нравилась его философия: маленький язык, приятная кривая обучения и очень быстрая компиляция (как для статически-типизированного языка). Что меня наконец заставило шагнуть дальше и таки начать его учить, так это то, что я стал видеть всё больше и больше быстрых и серьезных программ, написанных на Go — Docker и ngrok, в частности, из тех, которые я недавно использовал.

Философия Go не всем по вкусу (нет исключений, нельзя создавать свои дженерики, и т.д.), но она хорошо ложилась на мою ментальную модель. Простой, быстрый, делающий вещи очевидным способом. Во время портирования я особо был впечатлен насколько полноценной оказалась стандартная библиотека и инструментарий.

Портирование

Я начал с парочки 20-ти строчных скриптов на Go, но этого было как-бы мало, чтобы понять язык и экосистему. Поэтому я решил взять проект побольше и выбрал для портирования бекенд для моего сайта GiftyWeddings.com.

На Питоне это было около 1300 строк кода, используя Flask, WTForms, Peewee, SQLite и ещё несколько библиотек для S3, ресайзинга картинок и т.д.

Для Go-версии я хотел использовать как можно меньше внешних зависимостей, чтобы лучше освоить язык и как можно больше поработать со стандартной библиотекой. В частности, у Go есть отличные библиотеки для работы с HTTP, и я решил пока не смотреть на веб-фреймворки вообще. Но я всё же использовал несколько сторонних библиотек для S3, Stripe, SQLite, работы с паролями и ресайза картинок.

Буквально пару дней назад в Денвере закончилась очередная, уже 5-я по счёту, крупнейшая конференция по Go – GopherCon. На ней команда Go сделала важное заявление – черновики предварительного дизайна новой обработки ошибок и дженериков в Go 2 опубликованы, и все приглашаются к обсуждению.

Я постараюсь подробно пересказать суть этих черновиков в трёх статьях.

Как многим, наверняка, известно, в прошлом году (также на GopherCon) команда Go объявила, что собирает отчёты (experience reports) и предложения для решения главных проблем Go – тех моментов, которые по опросам собирали больше всего критики. В течении года все предложения и репорты изучались и рассматривались, и помогли в создании черновиков дизайна, о которых и будет идти речь.

Итак, начнём с черновиков нового механизма обработки ошибок.

[часть 2 из 2]

[часть 1 из 2]

Как нам это удалось

Мы решили перейти на GCP, чтобы повысить производительность приложений — увеличив при этом масштаб, но без существенных затрат. Весь процесс занял более 2 месяцев. Для решения этой задачи мы сформировали специальную группу инженеров.

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

Всем привет!

У нас наконец-то есть контракт на обновление книги Марка Симана "Dependency Injection in .NET" — главное, чтобы он поскорее ее дописал. А еще у нас в редактуре книга уважаемого Динеша Раджпута о паттернах проектирования в Spring 5, где одна из глав также посвящена внедрению зависимостей.

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

Эмоциональная окраска оригинала немного утихомирена, количество восклицательных знаков в переводе сокращено. Приятного чтения!

Go — простой и забавный язык. Но в нём, как и в любых других языках, есть свои подводные камни. И во многих из них сам Go не виноват. Одни — это естественное следствие прихода программистов из других языков, другие возникают из-за ложных представлений и нехватки подробностей. Если вы найдёте время и почитаете официальные спецификации, вики, почтовые рассылки, публикации в блогах и исходный код, то многие из подводных камней станут для вас очевидны. Но далеко не каждый так начинает, и это нормально. Если вы новичок в Go, статья поможет сэкономить немало часов, которые вы бы потратили на отладку кода. Мы будем рассматривать версии Go 1.5 и ниже.

19 сентября в Москве состоялся первый тематический митап HUG (Highload++ User Group), который был посвящён микросервисам. На нём прозвучал доклад «Эксплуатация микросервисов: размер имеет значение, даже если у вас Kubernetes», в котором мы поделились обширным опытом компании «Флант» в области эксплуатации проектов с микросервисной архитектурой. В первую очередь он будет полезен всем разработчикам, задумывающимся о применении этого подхода в своём настоящем или будущем проекте.



Представляем видео с докладом (50 минут, гораздо информативнее статьи), а также основную выжимку из него в текстовом виде.

NB: Видео и презентация доступны также в конце этой публикации.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Прим. перев.: Автор оригинальной статьи — Nicolas Leiva — архитектор решений Cisco, который решил поделиться со своими коллегами, сетевыми инженерами, о том, как устроена сеть Kubernetes изнутри. Для этого он исследует простейшую её конфигурацию в кластере, активно применяя здравый смысл, свои познания о сетях и стандартные утилиты Linux/Kubernetes. Получилось объёмно, зато весьма наглядно.



Помимо того факта, что руководство Kubernetes The Hard Way от Kelsey Hightower просто работает (даже на AWS!), мне понравилось, что сеть поддерживается в чистоте и простоте; и это замечательная возможность понять, какова роль, например, Container Network Interface (CNI). Сказав это, добавлю, что сеть Kubernetes в действительности не очень-то интуитивно понятна, особенно для новичков… а также не забывайте, что «такой вещи, как сети для контейнеров, попросту не существует».

Грядущий релиз версии 1.11 языка программирования Go принесет экспериментальную поддержку модулей — новую систему управления зависимостями для Go. (прим.перев.: релиз состоялся)

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

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

Оригинал статьи.

В феврале 2017 года член команды go Brad Fitzpatrick предложил сделать поддержку WebAssembly в языке. Спустя четыре месяца в ноябре 2017 автор GopherJS Ричард Музиол начал реализовывать идею. И, наконец, полная реализация была смержена в mаster. Разработчики получат wasm примерно в августе 2018, с версией go 1.11. В результате, стандартная библиотека берёт на себя почти все технические сложности с импортом и экспортом функций, знакомых вам, если вы уже пробовали компилировать Си в wasm. Звучит многообещающе. Давайте посмотрим, что можно сделать с первой версией.