От переводчика: так сложилось, что в русскоязычном интернете мало информации о TDD и в основном описываются механические действия разработчика. Главному же – идее – уделяется совсем мало внимания. Эта статья является попыткой восполнить этот пробел. Важно отметить, что она не для тех, у кого нет времени на тесты, и тем более не для тех, кто не осознает важность слабосвязанной архитектуры. Статья (оригинал) адресована тем, кто делает или собирается сделать первые шаги в TDD.

Продолжение. Начало здесь.

Как все это использовать?

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

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

Мы давно и практически безуспешно ищем светлую голову, желающую потеснить на рынке господина Кента Бека — то есть, ищем того, кто готов написать для нас книгу по TDD. C реальными примерами, рассказом о собственных шишках и достижениях. Книг на эту тему совсем мало, да и не будешь ведь классику оспаривать… может быть, поэтому мы с этой головой пока не встретились.

Поэтому мы решили не только вновь напомнить, что ищем такого человека, но и предложить перевод достаточно дискуссионной статьи, автор которой, Дуг Аркури (Doug Arcuri), делится собственными соображениями о том, почему TDD так и не стала мейнстримом. Давайте обсудим, прав ли он, и если нет — почему.

Анатомия веб-сервиса

Андрей Смирнов

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

Какую часть я называю веб-сервисом, бэкендом, application-сервером? В классической архитектуре это то, что стоит за http rеverse proxy или load-балансировщиком, а с другой стороны у него находятся база данных, memcached и др. Вот только об этом бэкенде и будет идти речь.

Если вы знаете, почему после выполнения `hset mySey foo bar` мы потратим не менее 296 байт оперативной памяти, почему инженеры instagram не используют строковые ключи, зачем всегда стоит менять hash-max-ziplist-entries/hash-max-ziplist-val и почему тип данных, лежащий в основе hash это и часть list, sorted set, set — не читайте. Для остальных я попробую об этом рассказать. Понимание устройства и работы хеш таблиц в Redis критически важно при написания систем, где важна экономия памяти.

О чём эта статья — какие расходы несёт Redis на хранения самого ключа, что такое ziplist и dict, когда и для чего они используются, сколько занимают в памяти. Когда hash хранится в ziplist, когда в dicth и что нам это даёт. Какие советы из модных статей об оптимизации Redis не стоит воспринимать всерьёз и почему.

В первой части я сказал, что хеш таблица это немного LIST, SET и SORTED SET. Судите сами — LIST состоит из ziplist/linkedlist, SET состоит из dict/intset, а SORTED SET это ziplist/skiplist. Мы уже рассмотрели словарь (dict), а во второй части статьи будем рассматривать структуру ziplist — вторую наиболее часто применимую структуру под капотом Redis. Посмотрим на LIST — вторая часть его «кухни» это простая реализация связного списка. Это пригодится нам, чтобы внимательно рассмотреть часто упоминаемый совет об оптимизацию хеш таблиц через их замену на списки. Посчитаем сколько памяти требуется на накладные расходы при использовании этих структур, какую цену вы платите за экономию памяти. Подведём итоги при работе с хеш таблицами, при использовании кодировки в ziplist.

В прошлый раз мы закончили на том, что сохранённые с использованием ziplist 1,000,000 ключей заняли 16 мб оперативной памяти, тогда как в dict эти же данные потребовали 104 мб (ziplist в 6 раз меньше!). Давайте разбираться какой ценой:

Содержание

1. Blockchain на Go. Часть 1: Прототип
2. Blockchain на Go. Часть 2: Proof-of-Work
3. Blockchain на Go. Часть 3: Постоянная память и интерфейс командной строки
4. Blockchain на Go. Часть 4: Транзакции, часть 1
5. Blockchain на Go. Часть 5: Адреса
6. Blockchain на Go. Часть 6: Транзакции, часть 2
7. Blockchain на Go. Часть 7: Сеть

Вступление

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

Недавно прочел достаточно неплохую статью о инсталяции программ на Go. Где был показан простой пример того как можно реализовать установку бинарника под «любую» (unix friendly) операционную систему. Решил написать более подробный цикл статей на эту тему.

Я использую Go для написания рекламной сети вот уже почти год. Разработку веду на сервере Intel i7-7700, 16Gb RAM, 256Gb SSD. И в скрипте который выполняется раз в сутки появилась задача выбрать все показы за прошедшие сутки и пересчитать на этой основе статистику за день сразу по нескольким объектам (сайт, кампания, баннер).

По идиомам Go делается всё достаточно тривиально:

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «The Laws of Reflection» от создателя языка.

Рефлексия — способность программы исследовать собственную структуру, в особенности через типы. Это форма метапрограммирования и отличный источник путаницы.
В Go рефлексия широко используется, например, в пакетах test и fmt. В этой статье попытаемся избавиться от «магии», объяснив, как рефлексия работает в Go.

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

В эту пятницу состоялся релиз Go 1.11. Ключевые вещи релиза — экспериментальная поддержка WebAssembly, а также новая концепция Модулей, которые призваны стать стандартом распространения кода.

Мотивация

Микросервисная архитектура позволяет выбирать между технологиями и языками программирования при написании REST api сервисов. Какой язык лучше выбрать, для написании REST api приложения, чтобы обеспечить большее количество одновременных пользователей быстрым и стабильным ответом на одном и том же железе? Чтобы ответить на этот вопрос было бы хорошо увидеть разницу в производительности одного и того же приложения написанного на Java и GO.

Дисклеймер

Все результаты представленные в данном эксперименте являются частным примером использования Java и GO и не должны использоваться для описания производительности этих языков в других условиях.

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

Введение в микросервисную архитектуру

Часть 1 из 10

Адаптация статей Ewan Valentine.

Это серия из десяти частей, я постараюсь раз в месяц писать про построение микросервисов на Golang. Я буду использовать protobuf и gRPC в качестве основного транспортного протокола.

Стек, который я использовал: golang, mongodb, grpc, docker, Google Cloud, Kubernetes, NATS, CircleCI, Terraform и go-micro.

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

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

• грузы
• инвентарь
• суда
• пользователи
• роли
• аутентификация

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

Только вот пока Go 2 лишь виднеется на горизонте, а ждать уж очень тягостно и грустно. Посему берем дело в свои руки. Немножко кодогенерации, чуть работы с ast, и легким движением руки паники превращаются, превращаются паники… в элегантные исключения!

На самом деле это всё о смартконтрактах

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

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



Существует мнение, что разработанный Google язык Golang, может в конечном итоге вытеснить JavaScript (или, лучше сказать, Node.js) из сферы IoT приложений. Правда ли суслик может победить в этой битве? Давайте подробнее рассмотрим, как Golang, так и JS, их преимущества и недостатки для IoT решений.