Так как нас не устраивала скорость и надежность исходной имплементации на Ruby, в последние несколько лет мы постепенно выводили критический функционал из нашего Rails-монолита GitHub.com и переписывали часть кода на Go. Например, на Github Satellite в прошлом году мы анонсировали — и имплементировали — возможность «более контролируемой авторизации» с использованием сервиса authzd.

Работа с authzd оказалась очень интересной и значимой для нас задачей, поскольку это был наш первый сервис на Go для работы с чтением данных из баз MySQL на продакшне в ходе веб-реквеста. У нас имелся опыт развертывания других работающих с базами MySQL-сервисов на Go, но при этом они были либо службами внутреннего контроля (наша кластерная поисковая система manticore), либо асинхронными пакетными заданиями (оркестратор резервного копирования Git gitbackups). Требования к производительности и надежности authzd отличаются от них повышенной строгостью, поскольку обычный реквест к Rails-монолиту вызывает этот сервис неоднократно.

Кроме того, проблемы с большими задержками при открытии TCP соединений на наших Kubernetes кластерах особенно влияли на пул соединений Go MySQL драйвера. Это добавляло работы, ведь именно на Kubernetes мы и развернули authzd. Одним из самых опасных самообманов программиста в этом отношении является вера в надежность сети, поскольку да, в большинстве случаев сеть действительно надежна… но как только она начинает тормозить или барахлить, нас настигают базовые проблемы таких же базовых библиотек, и все начинает рушиться.

Так чего нам в итоге стоила подготовка authzd к обработке всего нашего рабочего трафика через SQL, да еще и в соответствии с нашими целями доступности?

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

Предлагаю ознакомиться с расшифровкой доклада конца 2019 года Александра Валялкина "Go optimizations in VictoriaMetrics"

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

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

Детали под катом.

Современный веб состоит из множества разных технологий, которые предоставляют самые разные возможности… но ещё и создают немалое количество угроз. Современные браузеры давно стали самыми сложными приложениями на компе, обогнав по сложности даже ядро ОС (в Firefox в несколько раз больше строк кода, чем в ядре Linux или офисных пакетах). Мы проводим в браузере большую часть своего времени, так что не удивительно, что браузер находится под прицелом: его постоянно пытаются взломать, использовать в ботнете, пытаются украсть из него наши данные, прослушать его трафик, отслеживать посещаемые нами сайты и наши действия на этих сайтах.

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

Тем не менее, для усиления защиты браузера можно много чего сделать.

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



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

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

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

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

Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.

UPD от 2017-03-04: кто-то выполнил английский перевод. Обсуждение на Hacker News.

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

Костыли в UNIX начали возникать ещё с момента появления UNIX, а это было ещё раньше появления не только Windows, но даже вроде бы Microsoft DOS (вроде бы, мне лень проверять, проверяйте сами). Если лень читать, хотя бы просмотрите все пункты, что-нибудь интересное найдёте. Это далеко не полный список, это просто те косяки, который я захотел упомянуть.

В очередной статье нашего цикла публикаций, посвященного интернет-разведке, рассмотрим, как операторы продвинутого поиска Google (advanced search operators) позволяют быстро находить необходимую информацию о конкретном человеке.

В комментариях к первой нашей статье, читатели просили побольше практических примеров и скриншотов, поэтому в этой статье практики и графики будем много. Для демонстрации возможностей «продвинутого» поиска Google в качестве целей были выбраны личные аккаунты автора. Сделано это, чтобы никого не обидеть излишним интересом к его частной жизни. Хочу сразу предупредить, что никогда не задавался целью скрыть свое присутствие в интернете, поэтому описанные методы подойдут для сбора данных об обычных людях, и могут быть не очень эффективны для деанонимизации фэйковых аккаунтов, созданных для разовых акций. Интересующимся читателям предлагаю повторить приведенные примеры запросов в отношении своих аккаунтов и оценить насколько легко собирать информацию по ним.

Предисловие

Об этом руководстве

Добро пожаловать в первую из четырех частей обучающего руководства по основам Linux, разработанного чтобы подготовить вас к сдаче экзамена Linux Professional Institute 101. В нем вы познакомитесь с bash (стандартной оболочкой командного интерпретатора в Linux), узнаете о большинстве возможностей таких стандартных команд Linux, как ls, cp и mv, разберетесь в инодах, жестких и символьных ссылках, и многом другом. К концу этого руководства у вас сформируется некий фундамент знаний, и вы будете готовы к изучению основ администрирования Linux. К концу всего курса (8 частей), у вас будет достаточно навыков, чтобы стать системным администратором Linux и пройти сертификацию LPIC Level 1 от Linux Professional Institute, если конечно захотите.

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

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

О том, как заставит ноутбук работать под линуксами как можно дольше, написано немало, в том числе и на хабре. В какой-то степени я еще раз соберу все советы воедино, от очевидных до обскурных, заодно опишу несколько проблем и решений, которые у меня оказались достаточно «индивидуальными».

Устанавливал я Ubuntu 10.10 на ноутбук Acer Aspire Timeline 5810TG. Эта машина обладает экраном в почти 16 дюймов и относительно производительным железом, зато батарея достаточно емкая, чтобы ставить с ней личные рекорды.

Мои предыдущие посты об использовании Vim (1, 2) читатели приняли хорошо, и пришло время обновления. В Vim 8 появилось много очень нужной функциональности, а новые сайты сообществ вроде VimAwesome облегчили поиск и выбор плагинов. В последнее время я много работаю с Vim и организовал рабочий процесс исходя из максимальной эффективности, вот снимок моей текущей работы.

Вкратце:

• FZF и FZF.vim — для поиска файлов.
• ack.vim и ag — для поиска файлов.
• Vim + tmux — ключ к победе.
• Благодаря асинхронности ALE — это новый Syntastic.
• …И многое другое. Об этом ниже.

Примечание от переводчика:

Этот пост был написан и опубликован на Medium разработчиком приложений Адрианом Космачевским из Швейцарии. Кроме подготовки перевода его публикации, я также пригласил и самого автора, Адриана ( akosma ), на Хабр, для того, чтобы он смог лично ответить на любые вопросы участников сообщества, если таковые возникнут. Думаю, для общего удобства при общении в комментариях с ним стоит использовать английский (и, при желании, дублировать на русском).

---

Привет всем, я — сорокадвухлетний программист-самоучка, а это моя история.

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



Эти размышления привели меня туда, откуда все начиналось.

Я дебютировал в роли разработчика программного обеспечения в 10 часов утра 6 октября 1997 года, в городе Оливос, к северу от Буэнос-Айреса, в Аргентине. Был понедельник. Не так давно я праздновал свой 24-й день рождения.

Мир в 1997 году

Тогда он был немного другим. На веб-сайтах не было предупреждений об использовании cookie. Новаторскими в сети были сайты вида Excite.com, а моим любимым поисковиком был AltaVista.

Мой электронный ящик имел вид kosmacze@sc2a.unige.ch и был расположен на личном веб-сайте, который размещался по адресу http://sc2a.unige.ch/~kosmacze. Тогда мы еще оплакивали принцессу Диану, а Стив Джобс только-только вернулся на роль CEO и убедил Microsoft «вбросить» в Apple Computer 150 миллионов долларов. Digital Equipment Corporation подала в суд на Dell, останки Че Гевары вернули на Кубу, только начался четвертый (!) сезон «Друзей». Был убит Джанни Версаче, скончались Мать Тереза, Рой Лихтенштейн и Жанна Кальман. Люди зависали за Final Fantasy 7 на PlayStation, будто бы были наркоманами, Би-Би-2 начал вещание телепузиков, а Кэмерон только собирался показать миру свой «Титаник».

Введение

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

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

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

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

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

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

Перевёл после прочтения комментариев к статье «О ненависти к C++». В цитатах можно найти ответы на большинство возникших там вопросов.

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

49. Lisp — это не язык, а строительный материал.
— Alan Kay

48. Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены.
— Edward V Berard

Привет всему сообществу Хабра.
Это мой первый пост и, надеюсь, не последний. Поэтому неизбежны всяческие недочеты, баги и некоторая водянистость текста, так что прошу строго не судить :)
К написанию этого поста меня сподвиг топик «Консоль для новичка.» habrahabr.ru/blog/linux/46610.html, где ISVir поднял острую, на мой взгляд, тему — как доступным языком рассказать новичкам о консоли, не отпугнув их мнимой сверх-сложностью.

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

Итак, что мы имеем:

find — поиск файлов. позволяет искать файлы, каталоги, симлинки и другие файловые объекты. find Позволяет задать множество опций поиска таких как:

• поиск по маске (в имени )
• контроль глубины вложенности поиска
• поиск определенных типов файлов(каталог, симлинки, сокеты)
• поиск по времени создания/модификации файла
• можно задать размер (от и до в диапазоне) файла
• выполнение действий с каждым найденным файлом

в мане к find можно прочесть об остальных опциях и параметрах.

итак, с места в карьер — поиск всех файлов в каталоге /etc/, измененных за последние сутки: