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

Всем доброго времени суток! Меня зовут Константин, в Badoo я работаю в команде Features Team. Скорее всего, вы уже знаете, что наш бэкенд написан на PHP и обслуживает более трёх сотен миллионов пользователей. Так что я не мог упустить шанс перевести эту статью core-разработчика PHP Никиты Попова. Уверен, она будет полезна разработчикам всех уровней, но новичкам может показаться сложноватой. Приятного (и полезного) чтения!



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

Описание сделано на основе PHP версии 7.2 (в настоящее время находится в разработке), но почти всё справедливо и для PHP 7.0/7.1. Однако отличия от виртуальных машин серии PHP 5.x являются значительными, и с ними я, как правило, не проводил параллели.

Сейчас вы прочитаете увлекательную историю моего превращения из разработчика в тимлида. Это было долгое путешествие со множеством шагов назад, которое всё же закончилось уверенным шагом вперёд. Устраивайтесь поудобнее, берите попкорн… Поехали!

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

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

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

Вот первичный анонс о внедрении нового сборщика, датированный августом 2015-го:

В Go создаётся сборщик мусора (GC) не только для 2015 года, но и для 2025-го, и ещё дальше… Сборщик в Go 1.5 возвещает о наступлении будущего, в котором паузы на сборку больше не являются барьером для перехода на безопасный язык. Это будущее, в котором приложения без труда масштабируются вместе с оборудованием, и по мере роста мощности оборудования сборщик мусора больше не является сдерживающим фактором при создании более качественного, масштабируемого ПО. Go — хороший язык для использования как минимум в ближайший десяток лет.

Создатели утверждают, что они не просто решили проблему пауз на сборку мусора, а пошли куда дальше:

Одним из высокоуровневых способов решения проблем с производительностью является добавление GC-настроек (knobs), по одной на каждую проблему. Программист может менять их, подбирая наилучшую комбинацию для своего приложения. Недостатком этого подхода является то, что при внедрении каждый год одной-двух новых настроек через десять лет придётся законодательно регулировать труд людей, которые будут менять эти настройки. Go не пошёл по этому пути. Вместо кучи настроек мы оставили одну и назвали её GOGC.

Более того, освободившись от бремени поддержки десятков настроек, разработчики могут сосредоточиться на улучшении runtime’а приложения.

Не сомневаюсь, что многие пользователи Go были просто счастливы получить новый подход к runtime’у в Go. Но у меня есть претензии к этим заявлениям: они выглядят как недостоверный маркетинговый булшит. А поскольку они раз за разом воспроизводятся в Сети, пришло время подробно с ними разобраться.

Здравствуй, Хабр! Сегодня я хочу завершить цикл статей об организации тестирования (начавшийся с изучения ошибок и опыта), рассказав о том, как же все-таки Badoo выпускает два качественных серверных релиза каждый день. Кроме пятницы, когда мы релизимся только утром. Не надо релизиться в пятницу вечером.

Я пришел в Badoo чуть более четырех лет назад. Все это время наши процессы и инструменты для тестирования непрестанно развивались и совершенствовались. Для чего? Число разработчиков и тестировщиков увеличилось примерно в два раза — значит, для каждого релиза готовится больше задач. Количество активных и зарегистрированных пользователей тоже удвоилось — а значит, и цена любой нашей ошибки стала выше. Для того чтобы доставлять пользователям максимально качественный продукт, нам нужны всё более и более мощные средства контроля качества, и эта гонка не заканчивается никогда. Цель этой статьи не только продемонстрировать работающий пример, но и показать, что какими бы крутыми ни были ваши процессы контроля качества, наверняка можно сделать их еще лучше. Технические реализации некоторых инструментов вы сможете найти по ссылкам на другие статьи, о некоторых из них нам еще предстоит написать.

В Badoo существует несколько разных QA-флоу, отличие которых обосновано разными средствами разработки и целевыми платформами (но мы используем для них общие системы: JIRA, TeamCity, Git и т.д.), и я вам расскажу о процессе тестирования и деплоя наших серверных задач (а заодно и веб-сайта). Его можно условно разделить на 5 больших этапов (хотя тут, конечно, многие мои коллеги считают по-разному), каждый из которых включает в себя и ручную, и автоматизированную составляющую. Постараюсь рассказать вам по очереди о каждом из них, отдельно выделяя то, что изменялось и развивалось в последние годы.

Перевод одной из статей Бена Джонсона из серии "Go Walkthrough" по более углублённому изучению стандартной библиотеки Go в контексте реальных задач.

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

Этот пост является одним из серии статей по более углублённому разбору стандартной библиотеки. Несмотря на то, что стандартная документация предоставляет массу полезной информации, в контексте реальных задач может быть непросто разобраться, что и когда использовать. Эта серия статей направлена на то, чтобы показать использование пакетов стандартной библиотеки в контексте реальных приложений. Если у вас есть вопросы или комментарии, вы всегда можете написать мне в Твиттер — @benbjohnson.

Введение

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

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

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

Предлагаю перевод небольшой статьи Андерса Абеля на волнующую меня в данный момент тему — качественный и формализованный процесс подготовки задач к передаче в разработку при условии, что разработка ведется по скраму. Если у кого-то есть опыт использования описанного данным автором подхода, итересно было бы, если бы вы поделились нюансами. Оригинал статьи: «Using Kanban for Scrum Backlog Grooming».

картинка по запросу grooming:



***

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

Пользователь когда-то подписался на рассылку, но уже забыл когда, и главное зачем. Теперь ежедневно к нему падает спам, а по собственному опыту он знает, для того чтобы отписаться нужно зайти по ссылке свой профиль, найти и снять там какую-то галку а главное, помнить свой логин и пароль на давно забытом им сайте.
Его действия? «В спам!»

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

И вот, с десяток таких «отписок» и гугл будет удобно отсортировывать ваши рассылки в папочку Спам (584), у ВСЕХ ваших подписчиков.

Однако многие из нас уже успели заметить: некоторые письма в Gmail при попытке отметить их «В спам!» САМИ предлагают отписаться от рассылки в один клик.

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

Google снова набирает людей.
Это отличная новость для тысяч начинающих менеджеров и разработчиков ПО, желающих найти спокойную пристань в эти сложные дни.
Теперь плохие новости:

• Google предпочитает людей из «Лиги Плюща»
• Им интересны ваши оценки (в институте), даже если вам уже за 30
• Они ищут людей, которые хотят изменить мир

Хуже того, если вы подходите по всем этим параметрам, вам все равно надо проходить собеседование.
Льюис Пин (Lewis Pin), тренер по поиску работы из Сиэтла, собрал 140 вопросов, которые в Google спрашивали его клиентов.

Сколько шариков для гольфа поместится в школьный автобус?

Позиция: Менеджер проекта

В комментариях к постам про сеть WiMAX (1, 2) и про GPRS был выражен интерес к сетям сотовой связи, поэтому решил реализовать свою давнюю задумку и описать хабрасообществу как же устроены современные сети сотовой связи.



На приведённой картинке изображена общая структура сетей сотовой связи. Изначально сеть разделяется на 2 больших подсети — сеть радиодоступа (RAN — Radio Access Network) и сеть коммутации или опорную сеть (CN — Core Network).

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

Сперва, хотелось бы рассказать в общих словах про сеть, а потом более подробно расскажу про функции каждого из элементов сети.

Интереса ради перевёл последнюю статью Джоела Спольски. Сразу предупреждаю, что некоторым перевод местами может показаться достаточно вольным — это сделано сознательно в угоду удобочитаемости по-русски.

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

Дипломные проекты и тайм-менеджмент

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

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

А как делать этот самый рефакторинг, если даже неизвестно, с чего начать? Как осушить болото кода и не утонуть нем?

Конечно, идеальный вариант — считать рефакторинг одной из активности на проекте с самого его начала и выделять на него проектное время команды. В жизни, как ни странно, однако чаще всего оказывается, что предыдущий лид проекта не сильно озадачивался этим вопросом, предпочитая плыть по течению; возможно, он надеялся когда-нибудь сбагрить эту ношу менее удачливому лиду — пока проект еще не развалился; а может быть, просто не знал, что делать. Шеф, усё пропало!

Этот перевод статьи Тима О'Рейли о Google Wave предназначен для тех, кто еще не успел или не имеет возможности посмотреть целиком ролик с оригинальной презентации. Тим рассматривает все основные моменты этого события.

Основная мысль вчерашнего Google I/O заключалась в подчеркивании мощи HTML 5 для достижения той функциональности, которой уже долгое время обладают десктопные приложения. А этим утром в Google планировали анонсировать приложение, основанное на HTML 5 — еще очень на ранней стадии разработки — которое представит значительный шаг вперед в этом направлении.

Cоздатели Google Maps Ларс и Йенс Расмуссены вышли на сцену, чтобы приоткрыть завесу над своим последним проектом, Google Wave. Ларс описывает его таким образом: «Мы поставили самими себе вопрос: какой была бы почта, если бы ее придумали сегодня?».

Чувак отлично рассказывает и подробно показывает.
Например, за 1 минуту можно выучить 50 тысяч английских слов, не верите?

В русском языке существует около 50 тысяч слов оканчивающихся на «ция» и «сия».
Так вот, почти все слова оканчивающиеся на «ция» имею окончание tion, а на «сия» — sion.
Т.е. из слова вы подставляется все до окончания «ция», «сия».
Модернизация — Modernization
Делегация — Delegation
Корпорация — Corporation
Абстракция — Abstraction
Профессия — Profession

1 урок


Остальные 3 видео доступны в плейлисте или на странице пользователя DjonikNSK
torrent: rutracker.org/forum/viewtopic.php?t=3904361

Вчера вечером мощность второй DDoS-атаки на сайт Wikileaks превысила 10 Гбит/с. Сайт по-прежнему хостится на американских и ирландских серверах Amazon Web Services, которые пока успешно справляются с нагрузкой.

Ответственность за DDoS-атаку уже взял на себя некий американский «хактивист» th3j35t3r (The Jester). У себя в твиттере он объясняет это тем, что Wikileaks «угрожает жизням наших солдат и другим активам». В блоге «Джестера» говорится о том, что он прилагает все силы в интернете для «повреждения линий коммуникаций террористов, сочувствующих им, посредников, помощников, тиранических режимов и других плохих парней».

Истории о том, как люди проходят собеседования в Google, напоминают мне о тех давно ушедших днях, когда я работал в стартапе. За десять лет проведения «современных» IT-интервью наша компания ничему не научилась, и я был частью этой проблемы несколько лет. Я просто скопировал стандартный механизм интервью тех времен, и тем самым совершил большую ошибку. Я думаю, проблемы с производительностью в компаниях, в которых во главе угла ставятся разработчики, выжжены в их ДНК процессом найма новых сотрудников — в корне порочным.

Как мы это делали

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

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

Привет, читатель Хабра!

Было ли когда-нибудь в Вашей жизни собеседование, после которого в лучшем случае Вы вышли в холодном поту и сказали: «Ну они там и звери, эти HR-ы!», а в худшем – настроение упало на весь день и не только день?
У меня, например, было. Сейчас расскажу как.

   Написано при активном содействии aGRa.
Каждый раз, когда вы фотографируете здание, памятник или иной объект архитектуры, вы создаёте производную работу от этого самого объекта. Это значит, что часть авторских прав принадлежит, помимо вас, ещё и архитектору, построившему это здание. То есть по умолчанию вы имеете право публиковать фотографии зданий, авторские права на которые ещё не истекли, только с согласия архитектора.
К счастью, в законодательстве большинства стран данный случай оговорён особо. Такие оговорки, разрешающие свободное использование фотографий объектов, находящихся в общественных местах, называются «свободой панорамы». Законодательство о ней варьируется от страны к стране (сравнение законов разных стран).
В России свобода панорамы регулируется статьёй 1276 ГК РФ:

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

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