Go *

Вы когда-нибудь искали альтернативу Emacs Lisp'у? Давайте попробуем добавить в Emacs ещё один язык программирования.

В этой статье:

• Потенциальные преимущества, которые будут получены при возможности расширять Emacs на Go;
• Определим способы взаимодействия Go и Emacs Lisp;
• Затронем некоторые детали реализации описанного транскомпилятора;

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

В самом конце статьи представлена ссылка на work in progress проект, который позволяет конвертировать Go в Emacs Lisp.

Перевод статьи Дейва Чини — ответа на предыдущий пост Питера Бургона "Теория современного Go" — с попыткой провести мысленный эксперимент, как бы выглядел Go без переменных в глобальной области видимости вообще. Хотя в некоторых абзацах можно сломать язык, но пост достаточно интересный.

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

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

tl;dr магия это плохо; глобальные состояние это магия → глобальные переменные в пакетах это плохо; функция init() не нужна.

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

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

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


Backend для мессенджера написан на Go, поэтому и примеры будут на этом языке. Не желая изобретать велосипед, мы решили взять за основу XACML — стандарт для ABAC (Attribute-Based Access Control) — и максимально упростили его, чтобы он подходил для нашей задачи. Хотим отметить, что мы не ставили перед собой цель написать собственную реализацию XACML. Он был взят как пример работающей системы, из которого мы могли бы извлечь нужный для нас опыт.

Для знакомства с XACML и ABAC есть отличные статьи:

→ Знакомство с XACML — стандартом для Attribute-Based Access Control
→ Подходы к контролю доступа: RBAC vs. ABAC

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

В результате предыдущих статей у нас получилось приложение на Go, которое может обслуживать небольшой кусочек HTML. Эта статья расскажет о клиентской части, которая, увы, состоит в основном, из JavaScript, а не Go.

Итак, наше приложение будет иметь две основные части: клиентская и серверная. (Какой сейчас год?). Серверная часть будет на Go, а клиентская — на JS. Давайте сначала поговорим о серверной части.

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

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

Сервисы по продаже подержанных автомобилей обычно построены по одному принципу: «разместил объявление, позвонили, показал машину, продал». В таких проектах высокие технологии сконцентрированы, в основном, вокруг самого сайта. Но у нас всё иначе. Мы создали платформу, на которой любой желающий может продать автодилерам через аукционную систему свою подержанную машину (даже аварийную), с проверкой технического состояния нашими специалистами. За кажущейся простотой описания скрывается сложная экосистема из самописных и сторонних программных продуктов, о которой мы хотим рассказать.

На прошлой неделе компания CoreOS порадовала очередным Open Source-проектом — zetcd. На самом деле о нём было известно ещё с прошлого года, но теперь состоялся первый релиз, который перевёл продукт в статус бета-тестирования — заявил о готовности продукта к серьёзным испытаниям перед выпуском в мир production. Авторы позиционируют zetcd как готовую замену для ZooKeeper внутри таких распределённых/кластерных решений, как Mesos, Apache Kafka и Apache Drill. Их настрою не препятствует даже тот факт, что etcd предлагает «плоское» хранение ключей-значений против иерархического подхода своего конкурента. Как они к этому пришли?

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

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

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

Как обычно выглядят тесты?

Очень схематично, каждый юнит-тест обычно состоит из следующих шагов:

1. Инициализации входных данных;
2. Выполнения бизнес-логики и получения результата;
3. Сравнения результата с эталоном.

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

Но ведь все это можно унифицировать!

Представляю вам перевод моей статьи на Medium.com.

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

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

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

У меня возник вопрос, а нет ли похожей ситуации с типом map? Ведь у него тоже есть capacity, и он тоже может менять аллокацию в памяти при росте числа пар значений.

Тема может и банальная, но когда программа начинает работать как то не так, и вообще вести себя очень странно, часто приходится читать логи. И много логов, особенно если нет возможности отлаживать программу и не получается воспроизвести ошибку. Наверно каждый выработал для себя какие то правила, что, как и когда логировать. Ниже я хочу рассмотреть несколько правил записи сообщений в лог, а также будет небольшое сравнение библиотек логирования для языков php, ruby и go. Сборщики логов и системы доставки не будут рассматриваться сознательно (их обсуждали уже много раз).

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

Но что, если необходимо написать с десяток разных сервисов, работающих в одной инфраструктуре?

Если каждый демон будет использовать все свежие разнообразные «смузи»-технологии, получится «зоопарк», который сложно и дорого поддерживать, не говоря уже о добавлении в них новой функциональности.

У нас в Badoo крутятся >30 самописных демонов, написанных на разных языках, и ~10 из них – на Go. Все эти демоны работают на порядка 300 серверах. Как мы к этому пришли, не получив в итоге «зоопарк», как админы с мониторингом умудряются спать спокойно, не ограничивая при этом никого в смузи, а девелоперы, QA и релизеры живут дружно и до сих пор не переругались – читайте под катом.

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

Эта статья о новых оптимизациях компилятора, которые готовятся к релизу Go 1.9, но я бы хотел начать разговор с логирования.

Soft Mocks для Go!

Основная идея Soft Mocks для PHP — это переписывание кода «на лету» перед include(), чтобы можно было поменять реализацию любых методов, функций и констант во время исполнения. Поскольку go — компилируемый язык, то логично делать то же самое на этапе компиляции. В этой статье я расскажу по свой проект Soft Mocks for Go.

Функциональность

Возможности Soft Mocks for Go весьма ограничены — вы можете временно переопределить нужные вам функции и методы, а потом откатить свои правки. Также можно вызвать оригинальную функцию.

При использовании soft mocks, следующий код:

func main() {
    closeFunc := (*os.File).Close
    soft.Mock(closeFunc, func(f *os.File) error {
        fmt.Printf("File is going to be closed: %s\n", f.Name())
        res, _ := soft.CallOriginal(closeFunc, f)[0].(error)
        return res 
    })  
    fp, _ := os.Open("/dev/null")
    fmt.Printf("Hello, world: %v!\n", fp.Close())
}

Напечатает вот что:

File is going to be closed: /dev/null
Hello, world: <nil>!

Скачать библиотеку можно тут.

Всем доброго времени суток, только что подошел к концу двухнедельный HackQuest от PHDays. Не смотря на преобладание заданий связанных с WEB, организаторы не оставили без внимания и задания связанные с реверсом. Решение одного из таких заданий (erawmosnar), я бы хотел сегодня рассмотреть. К тому же думаю после WannaCry подобная тема станет ещё актуальнее.
К заданию была всего 1 подсказка:

Warn: erawmosnar == ransomware, do not run it, if you do not know what you doing.

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

Список лекций:

• Лекция 1. Введение
• Лекция 2. Функции, структуры, интерфейсы. Объектная модель
• Лекция 3. Асинхронная модель
• Лекция 4. Web. Работа с сетью
• Лекция 5. Работа с СУБД
• Лекция 6. Система тестирования
• Лекция 7. Reflect or generate?
• Лекция 8. Производительность
• Лекция 9. Context, unsafe, cgo