​​Примитивные типы

В Джаве есть 8 примитивных типов. Целочисленные, числа с плавающей запятой, символьный и буленовский. Подробнее описал типы в прикрепленной таблице.

Числа, которые мы пишем в коде, называются литералами. Например в строке int i = 123; литералом будет число 123. По умолчанию целочисленные литералы в Джаве определены типом int. Поэтому нужно быть аккуратным при записи чисел, которые выходят за диапазоны int. Например, максимальное значение int равно 2,147,483,647. Проверить это можно следующей строкой System.out.println(Integer.MAX_VALUE);

Записываю в переменную типа long значение, которое превыщающает максимальное интовое long max = 3123456789; И получаю ошибку компиляции. Чтобы Джава поняла, что литерал не int, а long, нужно в конце числа написать дописать букву L: long max = 3123456789L;

Для удобства большие числа можно разделять нижними подчёркиваниями long max = 3_123_456_789L;

Целые числа можно записывать в десятичной, двоичной, восьмиричной и шестнадцатеричной системах счисления. Вот примеры:
System.out.println(56); // 56
System.out.println(0b11); // 3
System.out.println(017); // 15
System.out.println(0x1F); // 31

Вопросы с собеседований

Отличие HashMap от TreeMap
Кэширование в Hibernate
Наследование в Hibernate
Скоупы Spring бинов
Отличие singletone от prototype
Жизненный цикл в Maven
Отличие install от deploy
Минусы TDD

Что посмотреть на выходных

Евгений Борисов о Spring на JPoint 2017
https://youtu.be/nGfeSo52_8A

Два сильных вопроса, которые может задать разработчик на собеседовании
https://youtu.be/ebaDjwr0lw8

Орел и решка в Сан-Франциско. Про силиконовую долину начинается на 30:38
https://youtu.be/r8GFqmbopE4

#чтопосмотреть

Вопросы с собеседований

Неделю назад проходил первый этап собеседования на проект крупного банка. Держите новую пачку вопросов.

— Collection – основные интерфейсы
— Зачем нужно красно-черное дерево в Джаве
— Есть одна таблица в БД и три сущности. Как осуществить маппинг с помощью JPA/Hibernate
— Уровни кэширования в Hibernate. Чем они отличаются
— Какие есть сторонние решения для кэширования
— Рассказать про Inversion of Control Containers и Dependency Injection
— Spring – какие есть скоупы и для чего используются
— TDD и BDD
— Для чего нужен Mockito
— Отличие Mock от Spy
— Этапы сборки проекта

Присылайте задачи и вопросы с собеседований в личку, буду публиковать @zybkin

Дикие имена

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

Примеры компилирующихся имен:
normname
НормИмя
$NORM2Name
_tozheNorm3Name
__EtoTozheNormName$

А эти имена не скомпилируются:
3DCircleClass
takSebe@Name
*$coffee
public

Три правила нейминга переменных, которые нужно знать:
— имена должны начинаться с буквы, знака нижнего подчеркивания «_» или знака доллара «$»;
— в имени могут присутствовать цифры;
— нельзя использовать в качестве имени зарезервированные слова. Например: abstract, private, static.

Ситуация. Вы руководитель проекта

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

1. Попытаться договориться с заказчиком и сдвинуть сроки на 2 месяца. По расчетам их достаточно для полной доработки.

2. Добавить ресурсов – взять разработчиков и тестировщиков из другой команды. И большей командой попробовать добить проект в срок.

3. Уменьшить функциональность. Убрать часть, которая еще не реализована, и выкатить только ту, которая готова и точно работает.

Как вы поступите?
anonymous poll

Уменьшу функционал – 354
👍👍👍👍👍👍👍 68%

Сдвину сроки – 82
👍👍 16%

Добавлю ресурсов – 82
👍👍 16%

👥 518 people voted so far.

​​Продукт vs. Проект

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

​​Agile

11 февраля 2001 года в США на горнолыжном курорте собрались 17 человек. Это были известные приверженцы разных методологий разработки: инженеры, разработчики и менеджеры. Некоторые из них были конкурентами. На встрече собравшиеся поняли, что у них много общего и выделили общие ценности, которым должны следовать успешные команды. Уже после встречи в течение двух месяцев шла бурная переписка между участниками. В её результате появилась страничка вики с 12 принципами айти команды. Так зародился Agile.

Agile – ценности и принципы, которыми руководствуются успешные команды. Их определяет Agile Manifesto. Манифест содержит 4 основные идеи и 12 принципов. Причем в нем нет практических советов.

Принципы Agile:
— Люди и взаимодействие важнее процессов и инструментов
— Работающий продукт важнее исчерпывающей документации
— Сотрудничество с заказчиком важнее согласования условий контракта
— Готовность к изменениям важнее следования первоначальному плану

И не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

http://agilemanifesto.org

​​Модификаторы доступа

private – доступ открыт только внутри класса

default или package-private – класс, методы или переменные будут видны только внутри пакета

protected – члены класса доступны внутри пакета и в наследниках

public – доступны всем

В наследниках можно менять модификаторы доступа в сторону большей видимости. Например, метод protected Object clone() можно сделать public, но нельзя сделать default.

Где взять примеры резюме

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

Зарплаты джавистов в 2018 году

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

Вот средние зарплаты джава-разработчиков в Москве за первое полугодие

#компании #зп

Вопрос про ссылочные переменные. Какие из этих фраз верны?

A. Объекты имеют доступ только по ссылке
B. Если закастить объект к его суперклассу, то вы навсегда потеряете доступ к методам, которые описаны в подклассе
C. Тип объекта определяет, какие свойства объекта хранятся в памяти
D. Тип переменной определяет, какие методы и поля доступны в программе
E. С помощью кастинга к подклассу можно добавить атрибуты объекту в памяти

Правильные ответы: A, C, D. Хоть объекты хранятся в памяти, но получить доступ к ним можно только по ссылке - вариант A верный. B не подходит, потому что если закастить объект обратно к своему типу, то у нас будет доступ ко всем методам. C, D верны и описывают различия между объектом и переменной. Вариант E неверный, потому что кастинг объекта не изменяет его в памяти.

Когда горит проект

Недавно проводил опрос "Как бы вы поступили на месте руководителя проекта, когда поняли, что проект горит" и решил задать этот же вопрос профессионалу. Олег Мохов руководитель службы разработки интерфейсов в Екатеринбургском Яндексе. Ещё он ведёт канал "Про руководство разработчиками" @teamleading. Передаю микрофон Олегу.

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

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

Итак, сроки профакаплены. Что делать? Сначала нужно довести задачу до конца, а дальше выяснять почему возникли проблемы и делать выводы. Т.е сначала приложить все усилия чтобы устранить проблему. Если нужно остаться ночью, то я буду первым кто останется ночью. Если нужно поковыряться в базе, то я сяду рядом с разработчиком и буду смотреть, даже если я сам нифига не понимаю. Если разработчик сидит удалённо, то я всё равно буду онлайн. Т.е нужно сделать всё, чтобы решить задачу

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

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

В фильме «Москва слезам не верит» главная героиня Катя, будучи директором, говорит замечательную фразу: «Меня не интересует почему нет, меня интересует что вы сделали чтобы было да». Я очень часто говорю эту фразу, например, когда кто-то говорит мне о внешних проблемах, то я всегда по максимуму узнаю что именно он ещё сделал, чтобы решить проблему. «Там уже в тикете не отвечают два дня!». «А ты звонил им?». «Может отправить им кого-то из менеджеров в Москве?», «Может командировку оформить, лично приедешь?» – это пример проблемы, и примеры вопросов, которые я задаю. Если проблема ограничилась «проблема не на моей стороне» – мы идём и разговариваем с разработчиком про это. И я рассказываю ему в который раз, что решить задачу не означает сделать только свою работу. И если задача не решена, то не бывает «я всё сделал, а они нет», т.к важно только что задача не решена.