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

И я намеренно не пишу, для кого предназначен этот план подготовки: для senior, middle или junior разработчика — все зависит от конкретной вакансии и от требований работодателя. Поэтому опирайтесь на этот план, но фильтруйте и в то же время не воспринимайте его как исчерпывающее руководство.

1. Java core. Здесь можно ориентироваться например на книгу «OCP: Oracle Certified Professional Java SE 8 Programmer II Study Guide: Exam 1Z0-809» для подготовки к Java сертификации уровня Professional. Есть подобная книга «OCA: Oracle Certified Associate Java SE 8 Programmer I Study Guide: Exam 1Z0-808» для уровня Associate — на нее тоже можно взглянуть. Пройдитесь по оглавлению и выделите для себя, что можно повторить. Конечно же, не стоит пускаться во все тяжкие и читать книгу от корки до корки — многие темы из этой книги можно обойти стороной, например форматирование дат. Выделите самое основное. Например для меня это были следующие темы: коллекции (стандартные вопросы «Как устроена HashMap?» или «Чем отличается LinkedList от ArrayList?» все также часто задают на собеседованиях), дженерики, функциональные интерфейсы, многопоточность (тут тоже фильтруйте — не нужны вам cyclic barrier и fork join framework).
   Также не забывайте проецировать знания на свой опыт. Например, когда вам приходилось использовать многопоточное программирование? Какие проблемы вы решали? Какие блокировки использовали?
   
2. Многопоточность.

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

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

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

• camera
• image-picker

Между ними – заметная разница, и использовать их стоит по ситуации:

• camera позволяет взаимодействовать с доступными устройству камерами из вашего приложения и выводить изображение в виджет. Хорошо подходит под задачи, когда надо "кастомизировать" работу камеры под приложение.
• image-picker запускает приложение камеры и возвращает объект типа File (изображение или видеофайл, выбранный пользователем) в ваше приложение. Также image-picker дает возможность выбора файла из имеющихся на устройстве, при этом, как и в случае камеры, запускается отдельное приложение, после чего в ваше приложение возвращается выбранный объект.

---

Здесь можно посмотреть исходники.

---

English version of the post

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

TL;DR

Важное замечание: разбор продолжается и пока всё в процессе. Может «мальчика и нет», но скорее всего есть. Будет дополняться по мере появления новой информации.

Крупнейшие российские операторы связи МТС и Ростелеком внереестрово блокируют трафик на SMTP-сервера сервиса защищённой электронной почты Protonmail по письму из ФСБ. Судя по всему, уже достаточно долго, но никто особого внимания пока не обращал. А мы вот обратили.

WTF и пригорание продолжается, все участники получили соответствующие запросы и должны предоставить мотивированные ответы.

UPD: МТС предоставили скан письма ФСБ, по которому производится блокировка. Мотивировка: Универсиада и «телефонный терроризм». Чтобы письма с ProtonMail не попадали на тревожные адреса спацслужб и школ.

UPD: Protonmail удивились методам борьбы с фродом у «этих странных русских» и посоветовали более эффективный вид борьбы через abuse mailbox.

UPD: Бравая концепция борьбы ФСБ с ложными обращениями не выдержала критики: письмом поломали входящую почту на ProtonMail, а не исходящую.

UPD: Protonmail пожали плечами и сменили IP-адреса своих MX, таким образом уведя их из под блокировки по этому конкретному письму. Вопрос, что будет дальше открыт.

UPD: Судя по всему, такое письмо не одно и есть ещё набор IP-адресов VOIP-сервисов, которые внереестрово блокируются.

UPD: Так как история стала распространяться за пределы Рунета, подготовили перевод на английский язык, ссылка вверху.

Традиционными инструментами в сфере Data Science являются такие языки, как R и Python — расслабленный синтаксис и большое количество библиотек для машинного обучения и обработки данных позволяет достаточно быстро получить некоторые работающие решения. Однако бывают ситуации, когда ограничения этих инструментов становятся существенной помехой — в первую очередь, если необходимо добиться высоких показателей по скорости обработки и/или работать с действительно крупными массивами данных. В этом случае специалисту приходится, скрепя сердце, обращаться к помощи "темной стороны" и подключать инструменты на "промышленных" языках программирования: Scala, Java и C++.

Но так ли уж темна эта сторона? За годы развития инструменты "промышленного" Data Science прошли большой путь и сегодня достаточно сильно отличаются от своих же версий 2-3 летней давности. Давайте попробуем на примере задачи SNA Hackathon 2019 разобраться, насколько экосистема Scala+Spark может соответствовать Python Data Science.

Крошка-сын к отцу пришел
И спросила кроха
— Что такое хорошо
и что такое плохо

Владимир Маяковский

Эта статья о Spring Data JPA, а именно в подводных граблях, встретившихся на моём пути, ну и конечно же немного о производительности.

В моем предыдущем проекте перед нами встала задача провести обратное геокодирование для множества пар географических координат. Обратное геокодирование — это процедура, которая паре широта-долгота ставит в соответствие адрес или название объекта на карте, к которому принадлежит или близка заданная координатами точка. То есть, берем координаты, скажем такие: @55.7602485,37.6170409, и получаем результат либо «Россия, Центральный федеральный округ, Москва, Театральная площадь, дом такой-то», либо например «Большой театр».

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

В качестве исходных данных у нас на входе было примерно 100 или 200 тысяч точек, которые лежали в кластере Hadoop в виде таблицы Hive. Это чтобы был понятен масштаб задачи.

В качестве инструмента обработки в конце концов был выбран Spark, хотя в процессе мы попробовали как MapReduce, так и Apache Crunch. Но это отдельная история, возможно заслуживающая своего поста.

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

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

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

А при чем тут драконы, объясним под катом.

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


Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

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

Новгоднего настроения пост.

Завтра наступит новый 2019 год. В новом году по традиции мы все так или иначе даём себе обещание что-то сделать лучше, что-то иначе, что-то вообще не делать:) Ну и опять же по традиции в последний день года принято подводить итоги и строить планы на будущее. 2018 год стал годом рождения TeamLead Conf, конференции для тех, кто хочет перейти на новый для себя уровень управления небольшими командами. Под катом немного воспоминаний, немного размышлений, много букв планов на будущее и анонс первых докладов на наше зимнее мероприятие в Москве.

Привет, Хабр! Представляю вашему вниманию перевод с англ. статьи Pitching Flutter to your company or client (автор Wm Leler)

С момента публикации статьи What’s Revolutionary about Flutter прошло больше года (и этот материал всё ещё актуален). Когда я писал ту статью, лишь немногие мобильные разработчики слышали о Flutter, но с тех пор многое изменилось. Сейчас я не успеваю следить за потоком новых статей и видео, которые появляются в этом активном и постоянно развивающемся сообществе. Разработчики открыли для себя Flutter, и они от него без ума. Вот пример приложения от Reflectly, созданного с помощью Flutter:


Умное приложение-дневник Reflectly

Здравствуйте, коллеги!

В январе у нас наконец-то выходит долгожданная книга по Kubernetes. Речь о «Mastering Kubernetes 2nd edition» Джиджи Сайфана:


Мы не решились издавать книгу по Kubernetes около года назад, так как на тот момент технология определенно напоминала дредноут для суперкорпораций. Однако, ситуация меняется, в подтверждение чего мы предлагаем почитать большую статью Калеба Докси (Caleb Doxsey), написавшего, кстати, книгу о языке Go. Аргументы господина Докси очень интересны, и мы надеемся, что после ознакомления с ними вам действительно захочется попробовать Kubernetes на практике.

Часть 1. Строительство
Часть 2. Отопление
Часть 4. Комфорт дома и гаджеты.

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

От переводчика: LambdaMetafactory, пожалуй, один из самых недооценённых механизмов Java 8. Мы открыли его для себя совсем недавно, но уже по достоинству оценили его возможности. В версии 7.0 фреймворка CUBA улучшена производительность за счет отказа от рефлективных вызовов в пользу генерации лямбда выражений. Одно из применений этого механизма в нашем фреймворке — привязка обработчиков событий приложения по аннотациям, часто встречающаяся задача, аналог EventListener из Spring. Мы считаем, что знание принципов работы LambdaFactory может быть полезно во многих Java приложениях, и спешим поделиться с вами этим переводом.

В этой статье мы покажем несколько малоизвестных хитростей при работе с лямбда-выражениями в Java 8 и ограничения этих выражений. Целевая аудитория статьи — senior Java разработчики, исследователи и разработчики инструментария. Будет использоваться только публичный Java API без com.sun.* и других внутренних классов, поэтому код переносим между разными реализациями JVM.

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

Так какого же чёрта моё прекрасное IT превращается в детский сад «Весёлый Програм-Мишка»?

Существует огромное количество инструментов визуализации графиков, умеющих делать с ними настоящие чудеса. Все они имеют разное назначение и специализацию.

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

В большой организации работа централизованных служб часто имеет критическое значение.

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

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

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

И тут начинаются жалобы на медленную отработку запросов…

Естественно, в этой ситуации руководителю нужны фактические данные, а не слова.

На помощь приходит когортный анализ.

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

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

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

Данная статья написана, в первую очередь, для начинающих руководителей. Надеюсь, их более опытные коллеги также найдут что-то интересное для себя. Повторение – мать учения!

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

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