Часть первая, теоретическая | Часть вторая, практическая

---

По мотивам твита от Evgeny Mandrikov aka godin:


В нём он задаётся вопросом, какое максимальное количество значений может быть определено в перечислении (enum) в Java. После ряда экспериментов и применения чёрной магии ConstantDynamic (JEP 309) автор вопроса приходит к числу 8191.

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

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

В этой статье я решил собрать наиболее популярные сайты/ресурсы, на которых реально найти вакансии с переездом в страны Европы.

Telegram-каналы

• RelocateMe
• Jobs abroad

Джоб-борды для IT-специалистов и нишевые сайты

AngelList

На сегодняшний день AngelList является одним из наиболее популярных сайтов по поиску работы в стартапах по всему миру. Процесс поиска вакансий с релокацией на этом сайте очень прост – во вкладке «Compensation» выбираем опцию «Company Will Sponsor Visa». Чтобы сузить полученный список вакансий до максимально релевантных, можно использовать фильтры «Role» и «Location».

Glassdoor

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

Чтобы найти вакансии, которые предлагают релокейт, пишем в поисковой строке relocation developer или relocation и название интересной вам позиции. Чтобы сузить результаты поиска, уточняем город/страну, куда хотели бы переехать.



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

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

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

IT компания победила в гостендере на разработку системы обучения. Приступила к исполнению и ее начали жестко сливать. В чем причина? Как происходит слив? И под какие риски подписывается разработчик, входя в тендер?

Часть 1: темные стороны ТЗ

Одно скромное ФГБУ (федеральное гос. богоугодное учреждение) объявило тендер на создание системы дистанционного обучения («СДО»). Сроки 5 мес., цена 4,5 млн. рублей.

Создание СДО проходило в 4 последовательных этапа: (1) анализ инфрастуктуры Заказчика, (2) создание СДО, (3) внедрение и гарантийное обслуживание.

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

«бесперебойное функционировании СДО при одновременном использовании 10 000 пользователей».

Заказчик подливает масла в огонь новой вводной, которой не было в ТЗ – объемом курсов обучения. Цитируя госзаказчика: «Подумаешь, забыли про объем написать?». Доблестный разработчик снова вглядывается в инфраструктуру, делает перерасчет и ужасается. Такой объем курсов помноженный на кол-во пользователей приведет к коллапсу системы.
Какие выходы есть?

Часть 2: адская бюрократия и решение на полмиллиона долларов

Выход первый: корректируем ТЗ путем уменьшения кол-ва одновременно находящихся на сайте юзеров. Звучит просто, но у нас же Госзаказчик. У нас 44 ФЗ! Поэтому попытка разраба согласовать на бумаге изменение ТЗ тонет в пучине согласований.

Выход второй (не, не Шереметьево и не Домодедово): взять мощности в аренду у ЦОДа. Всего-то 30 млн. рублей аренды в год. Примерно в этом месте госзаказчик понимает, что люто обдел-ся, потому что бюджет на аренду ЦОДов он не заложил, а отступить от ТЗ не может. Ведь ТЗ согласован со старшими товарищами и тогда….

Здесь описаны мои исследования, как сделать ревизию кода в команде более приятным занятием, которое может дать новый опыт всем участникам. У нас полностью географически распределённая команда, все коммуникации выполняются через интернет, и зачастую асинхронно. Мы используем Trello для описания возможностей продуктов, поодиночке создаём код, отправляем в GitHub пулл-реквесты, а также пользуемся встроенной в GitHub функцией их ревью. Это отличается от просмотра кода лицом к лицу в офисе и даже по видеочату.

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

Из документации Google's Engineering Practices

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

• Стандарт код-ревью
  
• Что проверять в коде
  
• Навигация по списку изменений (CL)
  
• Скорость код-ревью
  
• Как писать комментарии
  
• Как преодолевать сопротивление

См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.

Современный веб практически немыслим без медиаконтента: смартфоны есть практически у каждой нашей бабушки, все сидят в соцсетях, и простои в обслуживании дорого обходятся компаниям. Вашему вниманию расшифровка рассказа компании Badoo о том, как она организовала отдачу фотографий с помощью аппаратного решения, с какими проблемами производительности столкнулась в процессе, чем они были вызваны, ну и как эти проблемы были решены с помощью софтового решения на основе Nginx, обеспечив при этом отказоустойчивость на всех уровнях (видео). Благодарим авторов рассказа Олега Sannis Ефимова и Александра Дымова, которые поделились своим опытом на конференции Uptime day 4.

— Начнем с небольшого введения о том, как мы храним и кэшируем фотографии. У нас есть слой, на котором мы их храним, и слой, где мы фотографии кэшируем. При этом, если мы хотим добиваться большого хитрейта и снижать нагрузку на стораджи, нам важно, чтобы каждая фотография отдельного пользователя лежала на одном кэширующем сервере. Иначе нам пришлось бы ставить во столько раз больше дисков, во сколько у нас больше серверов. Хитрейт у нас в районе 99%, то есть мы в 100 раз снижаем нагрузку на наши storage, и для того, чтобы это сделать, еще 10 лет назад, когда все это строилось, у нас было 50 серверов. Соответственно, для того, чтобы эти фотографии отдавать, нам нужно было по сути 50 внешних доменов, которые эти серверы обслуживают.

Естественно, сразу встал вопрос: а если у нас один сервер упадет, будет недоступен, какую часть трафика мы теряем? Мы посмотрели, что есть на рынке, и решили купить железку, чтобы она решила все наши проблемы. Выбор пал на решение компании F5-network (которая, кстати, не так давно купила NGINX, Inc): BIG-IP Local Traffic Manager.

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

Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.

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

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

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

И вот мы решили ускорять то, что и так работает быстро и, заодно, поделиться опытом того, что получилось в итоге. Конечно же я расскажу о граблях, о том где не надо HTTP/2, о том почему мы покупаем 7,6Tb NVMe SSD вместо 8x1Tb SATA SSD и много другой узкоспециализированной информации.

Давайте сразу договоримся что хранение и раздача контента это 2 разные задачи и говорить мы будем только про раздачу (продвинутый кеш)

Начнем с железа…

Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.

От переводчика

Представляемый вашему вниманию перевод открывает серию статей от Jakob Jenkov, посвященных внедрению зависимостей, или DI. Примечательна серия тем, что в ней автор, анализируя понятия и практическое применение таких понятий как «зависимость», «внедрение зависимостей», «контейнер для внедрения зависимостей», сравнивая паттерны создания объектов, анализируя недостатки конкретных реализаций DI-контейнеров (например, Spring), рассказывает, как пришел к написанию собственного DI-контейнера. Таким образом, читателю предлагается познакомиться с довольно цельным взглядом на вопрос управления зависимостями в приложениях.

В данной статье сравнивается подход к настройке объектов изнутри и извне (DI). По смыслу настоящая статья продолжает статью Jakob Jenkov Understanding Dependencies, в которой дается определение самому понятию «зависимости» и их типам.

Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».

Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.

Если кто не знает: принцип DRY — это "Don't Repeat Yourself" (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.

Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!

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

Прочитав шестьдесят четыре статьи, пролистав разделы пяти книг и задав кучу вопросов в IRC и StackOverflow, я (автор оригинальной статьи Joe «begriffs» Nelson), как мне кажется, собрал куски паззла воедино и теперь смогу примирить противников. Многие споры относительно ключей возникают, на самом деле, из-за неправильного понимания чужой точки зрения.

Содержание

• Что же такое «ключи»?
• Любопытный случай первичных ключей
• Выбор естественных ключей
• Искусственные ключи
• Суррогатные ключи
• Автоинкрементные BIGINT
• UUID
• Итоги и рекомендации

Давайте разделим проблему на части, а в конце соберём её снова. Для начала зададим вопрос – что же такое «ключ»?

Бизнес увлёкся, и это стало настораживать. Нейросети, блокчейн, машинное обучение, роботы, автоматизация всего и вся создали опасную иллюзию того, что всё решено. А значит, можно увольнять, сокращать, не удерживать, не мотивировать. А зачем? Часть издержек экономится за счёт внедрения автоматизации, а на те рабочие мощности, что остались, стоят очереди из соискателей, к чему держаться за кого-то. Это не утопия, это наша данность, с которой мы входим в новый 2018 год. И её, этой данности, не должно быть. Потому что за каждой технологией стоят люди, за каждой компанией и за каждым продуктом компании — люди, и за владельцами компаний — тоже люди. За четыре дня до нового года мы хотим поговорить о том, как бизнесу ладить с сотрудниками, а сотрудникам — с бизнесом. Ведь мы по-прежнему не можем существовать друг без друга. Поэтому поговорим — как люди с людьми. О людях.


Источник: Яндекс.Картинки

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

1. Думайте своей головой и проверяйте факты

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

Прим. перев.: Неделю назад Aymen El Amri, руководящий компанией eralabs и создавший обучающий курс «Безболезненный Docker», опубликовал свой Docker Cheat Sheet — шпаргалку по основным командам Docker. Git-репозиторий этого документа на GitHub уже набрал 1000+ stars и несколько сторонних контрибьюторов, что подтвердило его актуальность и пользу.



Представленные здесь команды описаны минимально (с акцентом на читаемость как есть) и включают в себя установку Docker, работу с реестрами и репозиториями, контейнерами, образами, сетью, Docker Swarm. Ниже представлен перевод шпаргалки в её состоянии на 2 сентября с дополнениями из комментариев ниже.

Про CryptoNote, Lightning Network, Plasma, PoS и прочее

Автор статьи — Алексей Маланов, эксперт отдела развития антивирусных технологий «Лаборатории Касперского».

Недавно мы опубликовали статью «Шесть мифов о блокчейне и Биткойне, или Почему это не такая уж эффективная технология». Статья была положительно встречена Хабра-сообществом и активно обсуждалась в комментариях, что явно свидетельствует о большом интересе к этой теме.

Было среди комментаторов и несколько возмущенных. Кто-то негодовал: «Зачем вы пишете очевидное, ведь это все давно всем прекрасно известно?» На это трудно возразить по существу. Но были и те, кто писал в ключе: «Все это неправда, на самом деле все проблемы решены там-то и там-то».

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

Чат боты — довольно интересная тема, которой интересуются как гики-энтузиасты, так и компании, которые хотят организовать взаимодействие со своими клиентами наиболее удобным для них способом

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