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

На данный момент этот инструмент плотно вошёл в нашу жизнь, следя за единым стилем кода и уберегая от самых разных видов ошибок. Поиск ошибок происходит при сборке на CI или перед принятием pull request в версионное хранилище. Все найденные ошибки отображаются в Web-интерфейсе, где можно изучать их и управлять ими.

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

Для того, чтобы облегчить жизнь разработчикам нашей компании, использующим IntelliJ IDEA, я составил инструкцию. А в дальнейшем понял, что она может быть полезной более широкому кругу специалистов, и решил выложить её в публичный доступ.

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

Я занимаюсь программированием уже 15 лет. Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом.

Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Ни у кого вроде нет возражений.

У каждого кандидата в конце собеседованию рекрутер обычно спрашивает, есть ли вопросы. Часто люди теряются и не находят, что спросить. И лишь по прошествии некоторого времени (часто, когда человек уже работает в компании) сами собой всплывают вопросы, о которых нужно было поинтересоваться заранее, а не брать кота в мешке и удивляться «Как я сюда попал? Куда я смотрел? Почему я об этом не подумал?». Это так называемый «эффект лестницы». Я подготовил шпаргалку, что ты, %habrauser%, не растерялся.

Общее

1. Рабочий график и можно ли его двигать?
Я люблю поспать. Но на моей прошлой работе «рабочее утро» начиналось в 7:30. Мало того, что я довольно часто не мог прийти к этому времени, я еще пол дня занимался тем, что пытался привести себя в рабочую форму. Где то до 10:00. С 10:30 до 11:30 я усердно работал. Потом был обед. А потом мне хотелось спать, а не работать, т.к. я не высыпался еще с утра. Надо ли говорить, что вместо 8 часов, на которые меня нанял работодатель, я работал в «потоке» только часа 3-4. Так что для себя нужно решить вопрос – когда я наиболее трудоспособен? И обговорить рабочий график с руководством. И еще один нюанс. Попробуйте закрепить обговоренный график в трудовом договоре или контракте (далее ТД), если работодатель идет на персональный рабочий график для Вас. Никаких устных договоренностей. Иначе Вам начнут крутить руки уже в процессе работы (как это было со мной).

Все мы привыкли к тому, что на собеседованиях задают много вопросов. Обычно — работодатели кандидатам. Один из таких вопросов — “а у вас есть вопросы к нам?”. Довольно часто кандидаты не готовы к этому. И зря. Задавать вопросы работодателю — это совершенно нормально и даже необходимо. Лучше сразу уточнить все важные для вас аспекты работы, чем потом разочароваться. Более того, вопросы, заданные кандидатом, иногда даже учитываются как одна из характеристик кандидата. О чем спросил кандидат — о технологиях, о продукте или о процессах?
В этой статье я рассмотрю вопросы, часто задаваемые кандидатами разработчиками ПО. Я считаю, что эта статья будет полезна как самим кандидатам, так и рекрутерам, чтобы подготовиться к собеседованию.

Коллеги нашли свежий кейс, который замечательно иллюстрирует необходимость оформления прав на код сотрудников до наступления конфликта (Постановление Суда по интеллектуальным правам от 01.08.2019 по делу № А40-202764/2018).

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

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

Разбор дела под катом.

В недавном релизе языка Dart 2.6 в языке появилась новая функция, static extension или статические методы расширения, который позволяет вам добавить новые методы к существующим типам. Зачем вообще нужны extension? Как их использовать и на что они годятся?

Введение

Начнём с того что такое вообще extension? Extension — это синтаксический сахар, который расширяет существующий класс в месте, отличном от модуля объявления класса.

В программировании методы расширения существуют уже достаточно давно, вот они добрались и до dart. Extension активно используется в таких языках как C#, Java via Manifold, Swift, Kotlin и во множестве других.

Каждый раз, готовясь к собеседованиям на позицию «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. Многопоточность.

Вместо предисловия

или как так получилось, что появилась эта статья

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

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

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

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

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

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

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

Я посмотрел, как эти компании вычисляют показатели безопасности других компаний. Оказалось, они смотрят на сочетание использования НТТР-заголовка для безопасности и репутации IP-адресов.

Репутация IP-адреса основывается на данных черных списков и списков спамеров в сочетании с данными о владельце общедоступного IP-адреса. Она, в принципе, должна быть чистой, если ваша компания не рассылает спам и в состоянии быстро определить и остановить вредоносное внедрение. Использование заголовка безопасности НТТР вычисляется аналогично тому, как работает Observatory от Mozilla.

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

Почти полтора года прошло с момента появления на Хабре моего рассказа про самый умный обогреватель. Менялись времена года. Упал и опять начал подниматься курс биткоина. Отгремел чемпионат мира по футболу. В Терконе придумали, как сделать массовый бесшумный компьютер. Под катом — немного о нашей новой разработке. Плюс небольшой, но судьбоносный опрос.

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

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

Недавно попалась на глаза новость, что вышел очередной релиз Flutter (1.9), который обещает разные вкусности и, в том числе, раннюю поддержку веб-приложений.

На работе я занимаюсь разработкой мобильных приложений на React Native, но с любопытством поглядываю на Flutter. Для тех, кто не в курсе: на Flutter уже сейчас можно создавать приложения для Android и iOS, готовится к релизу поддержка веб-приложений, а ещё в планах поддержка десктопа.

Такое вот «одно кольцо, чтобы править всеми».

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

Под катом — рассказ о том как я решал привычные для React Native программиста задачи средствами Flutter, плюс общее впечатление от технологии.

Введение

Содержит ли Java-объект:

• поля, объявленные в суперклассе?
• private поля, объявленные в суперклассе?
• методы?
• элементы массива?
• длину массива?
• другой объект (в себе)?
• hash-код?
• тип (свой)?
• имя (своё)?

Ответы на эти (и другие) вопросы можно получить с помощью библиотеки классов org.openjdk.jol которая, в частности, позволяет уяснить, что объект — это область памяти:

• содержащая:
  • заголовок (до 16 байт), и в нём:
    
    • hash-код
    • ссылку на тип
    • длину массива (для массива)
  • все поля (включая private), объявленные во всех суперклассах
  • или элементы массива (для массива)
• не содержащая:
  
  • статические переменные
  • методы
  • другие объекты в себе
  • своё имя (то есть у объекта нет имени)
  
  

Подготовка

Здесь приведены результаты оценки памяти объектов разного типа по способу из описания пакета java.lang.instrument (смотри также здесь). Эти результаты позволяют ответить на большинство поставленных выше вопросов.

Доброго времени суток, Хабр.

Сегодня я решил представить вам перевод цикла статей для подготовки к Spring Professional Certification.

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

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

Надо ли писать код на доске? Надо ли жонглировать бинарными деревьями и знать наизусть все сложности алгоритмов, или просто разговаривать про жизнь и проекты?

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

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

Оказалось, что добиться эффекта можно разными способами. Хотя все они несильно сложные, но на примере такой задачки интересно вспомнить о разных тонкостях языка. Давайте посмотрим, какие удалось найти способы.

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

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

Необходимое вступление

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

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

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

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

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

Под катом список тем, которые покажут проблемные места там, где о них не любят упоминать.