Создание новых типов данных — важная часть работы каждого программиста. В большинстве языков определение типа состоит из описания его полей и методов. В Golang помимо этого нужно решить, какую семантику получателя для методов нового типа использовать: значение (value) или указатель (pointer). На первый взгляд это решение может показаться второстепенным, ведь в большинстве случаев программа будет работать при любой семантике получателя. Поэтому многие пропускают этот момент и пишут код, так и не разобравшись до конца, на что влияет семантика получателя метода. А чтобы разобраться, нужно немного углубиться в то, как устроен Golang.

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

Билл Кеннеди в одной из лекций своего замечательного курса Ultimate Go programming сказал:

Многие разработчики стремятся оптимизировать свой код. Они берут строчку и переписывают ее, говоря, что так станет быстрее. Нужно остановиться. Говорить, что тот или иной код быстрее, можно только после того, как он отпрофилирован и сделаны бенчмарки. Гадание не является правильным подходом к написанию кода.

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

Создать хорошее приложение непросто. Какое бы уникальное и полезное приложение вы ни написали, если оно не нравится пользователю, то у вас, как говорится, 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 всего за полчаса, используя эти пакеты, можно реализовать такую нетривиальную задачу, как локализация писем.

Перевод статьи Scott Arciszewski «A Gentle Introduction to Application Security».

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

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

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