История "успеха"

Добрый день, уважаемые джаварашевцы и джаварашевки!
На джавараше мы часто читаем так называемые «истории успеха». Ну это про «паровозика, который смог». Но не всегда все так радужно. Вот достаточно закономерная при капитализме история.
Бесплатный совет от юриста, более 20 лет занимающегося правовым сопровождением коммерческой деятельности: ВСЕ ваши договоренности должны быть закреплены в договоре в установленном законом порядке, else 1) вы предлагаете потенциальному работодателю заняться нетрадиционным сексом с автобусом; 2) немедленно встаете и уходите. If вы этого не сделаете, то потенциальный работодатель вас заставит заняться нетрадиционным сексом с автобусом. Что и произошло в описываемой истории.
Удачи вам! Будьте бдительны!

С уважением,
Зеленая лягушка.
  • ,

Маленькие хаки с javarush

Где-то весной, учился полтора месяца на JR. Делал это с edge (да да). Он автоматом растягивал изображение по ширине экрана,

В последствие достигнув 26 уровня я немного остановил темпы, так-как нашел работу в небольшом сайтостроительном агентстве (кодя на php :D). Так как чувства, которые я испытываю к java слишком сильные я решил вернуться сюда и продолжить обучение.Зашел я на сайт с google chrome, потому-что осознал какое же уг (в fronend, отладке и тд) edge. И тут я увидел это.

Мне дико не понравились полоски по краям и то что текст не выравнивается по ширине экрана.
Если кому-то тоже не понравятся данные полоски, прилагаю решение для устранения их.

Нажимаем f12 в google chrome, в остальных же браузерах (кроме оперы) эта клавиша работает одинаково. В opera это Инструменты > Дополнительно > Средства для разработчика.
Находим следующий код, и стиль к нему.

Отключаем его.

Сайт встал по ширине экрана, но основная текстовая часть не встала так-как надо, поэтому переходим сюда.И отключаем следующие стили. (они отвечают за ширину контейнерной части на разных разрешениях экрана)

Воаля, после данных нехитрых операций сайт становится вот таким


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

Создание собственной коллекции

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

при этом при добавлении элемента все элементы увеличивают свое значение на добавляемый элемент

Недопустим ввод в коллекцию null, символов и других значений, кроме целых чисел.

необходимо направить в правильное русло, так как я учусь.
  • ,

Учеба на JavaRush. Поиск работы и прохождение собеседований. Часть 2.

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

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

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

На первой странице нужно указать всю самую важную информацию, что бы hr заинтересовался вами. Я там писал знание языков, прохождение курса JavaRush и кратко что изучал, прохождение стажировки и какие там были технологии. Далее, поскольку я шел на Android Developer, то писал все технологии и библиотеки какие знал по данной платформе. Далее можно написать про паттерны проектирования, системы контроля версий, системы сборки (maven, gradle), а так же в каких средах разработки вы работали.

После этого напишите о предыдущем опыте работы, если такой присутствует (если он никак не связан с программирование, то просто кратко опишите чего вы там достигли, какие улучшение в работе сделали). Потом идет образование и в самом конце я писал о своих проектах. Так как превалирующее большинство технологий вы напишете на первой странице, то не нужно на 100% повторяться и писать, что все они присутствуют в ваших проектах – напишите только самое важное.

Поиск работы. Начал я отправлять резюме где-то в средине весны 2017. На удивление вакансий на Android Developer даже в Киеве совсем немного, если посмотреть на самых популярных сайтах поиска работы, то их наберется до 30 штук, больше половины которых хотят уровень middle/senior. Но все же они постоянно обновляются и за весь период поиска думаю до сотни резюме я отправил.

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

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

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

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

Прохождении собеседований. Подготовка к первым собеседования была очень туманная. После курса JavaRush и начала изучения android я не занимался теорией вообще, а тут нужно было за пару дней повторить все, что ты знаешь и не знаешь о Java и Android. Это такие моменты, когда ты вообще не понимаешь с чего начать и что учить. Просидел я с утра до вечера читая разные статьи, даже лекции JavaRush открывал по многопоточности.

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

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

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

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

Если говорить о том, что нужно железно знать на позицию Android Developer (думаю на позицию Java Developer так же), то это ОПП. Там сразу будет понятно или ты только заучил как называются основные принципы или же ты знаешь их саму суть и можешь нормально использовать на практике. Так же нужно знать жизненные циклы активити, фрагментов. Про паттерн Observable часто спрашивают, так как он довольно часто используется и даже лежит в основе библиотеки RxJava. А вообще о чем будут спрашивать не угадаешь – могут больше уклон делать на java, а могут на android. Я, например, очень старался сделать хорошим свое портфолио, а меня о моем одном проекте спросили только на последнем собеседовании.

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

В предыдущей статье я писал, что у меня друг работает android разработчиком. Вот недавно ему предложили работу в другой компании и так как он уходил, то на его место искали нового кандидата. Он порекомендовал провести со мной собеседование. Изначально мне прислали сделать тестовое задание и дали время 1 неделю с учетом того, что чем быстрее сделаешь, тем лучше. Сделал я задание за 4 дня (друг мне как честный человек в этом деле не помогал). После этого меня пригласили на собеседование.

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

Собеседование было по больше мене с уклоном на практическую сторону и по времени длилось час. После мне сказали, что дадут ответ в течении двух недель, так как хотят еще посмотреть других кандидатов. И вот недавно мне пришло письмо, что я приглашен на испытательный срок на позицию Android Developer – радости было не отнять:)

Если вы изучаете андроид, все задания на startandroid и других ресурсах уже прошли, то что я могу вам посоветовать попрактиковать. Есть хороший сайт. Там генерируете список json обьектов. Создайте андроид приложение в котором вы будете загружать этот список (в отдельном потоке или в сервисе или с помощью сторонних либ) и отображать его потом пользователю. Базу данных используйте либо SqlLite либо сторонние либы Realm. В списке пусть будет краткая информация, а при нажатии на эл списка – открывается фрагмент с полной информацией. Еще для усложнения задания сделайте адаптацию на планшеты – разделение на два экрана в повороте в горизонтальное положение, в вертикальном же один экран (для этого используйте фрагменты). Так же можно добавить navigation drawer и там какие-то пункты настроек (смена языка приложения, фона, шрифта и т.д.). Что-то похожее было в моем тестовом задании.

В общем, что хочется сказать всем, кому еще предстоит поиск работы – напишите хорошее резюме, так как это самое первое, что вас характеризирует. Выбирайте стажировки и вакансии только в хороших компаниях (по крайней мере в тех, кто не поленился нормально составить описание вакансии). Учите теорию – хоть иногда и кажется, что это только для собеседований, а на практике гугл всегда под рукой, но по своему опыту скажу, что со знанием всей основной теории программировать становится легче. После каждого собеседования изучайте все вопросы, на которые не знали ответа и в которых были не очень уверены – так уже после 4-5 собеседования вы будете знать ответы на все самые распространенные вопросы. Хотелось еще сказать, что бы не волновались, но это все естественно и этого не отнять – мы же не машины :)

Ссылка на все вопросы, что у меня были на собеседованиях (ответы ищете в гугле) – вопросы на собеседованиях
Всем спасибо за внимание и всем удачного трудоустройства!
  • ,

Учеба на JavaRush. Первые проекты, что Вас ждет и как лучше не делать. Часть 1.

Добрый день! Наконец-то я дождался того времени, когда готов поделиться своей историей успеха. Рассказать хочется много, поэтому разделю на две части – так сказать «первые проекты и как лучше не делать» и собственно «поиск работы и прохождение собеседований».
О себе много рассказывать не буду, скажу только, что как и почти все здесь я отучился и поработал на другой специальности, но потом решил стать программистом:)

Поговорим сразу об обучении. Начал я заниматься на JavaRush в начале 2016 года. Долго выбирал где изучать программирование и, конечно, как и все наши люди не хотел платить за обучение. Изучать хотел именно Java, так как моя мечта – программировать на Android. Курс JavaRush несколько раз попадался мне на глаза во время поиска, но я его отбрасывал, так как он условно-бесплатный. Начал заниматься по видео урокам на ютубе. Потом все же какая-то сила меня заставила попробовать порешать бесплатные задачки на JavaRush, и я настолько удивился, что после прохождения 50 видео уроков (я считал их довольно нормальными) и написанию кода за лектором, я с большим трудом и далеко не с первой попытки решал начальные задачи курса. Качество курса и то, что он мне даст, если я его пройду полностью я оценил почти сразу, потом посмотрел на форуме, что время от времени там бывают хорошие скидки на подписку решил, что буду брать полную версию.
Да, многие учащиеся злятся и негодуют насчет курса — задачи дают по материалу, который еще не рассматривали, валидатор их не понимает и много-много чего можно почитать на форуме и в комментариях. И знаете что? Я тоже таким был:) У меня до сих пор висит большая задача на 34 уровне и я перепробовал все решения, но ее не принимает валидатор. Хорошо, что в тех поддержке мне докинули черной материи и я смог до конца добить курс. В общем, как выпускник курса JavaRush скажу свое субъективное мнение, что мне понравилось и не понравилось в курсе (да простят меня админы).

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

Если это подытожить, то я доволен курсом и тем, что он мне дал. Вспоминаю себя год назад, как мне друг пытался объяснить что такое boolean, void, что такое методы и как они возвращают значения. Помню как долго не мог понять зачем нужно возвращать эти значения:)
Сейчас же мне часто вспоминается сцена из фильма Матрица:
Нео: Ты что научишь меня уворачиваться от пуль?
Морфиус: Когда придет время тебе это уже не понадобится.
И действительно, когда пришло время у него уже априори были эти навыки.

На 30 уровне курса я хотел попасть на стажировку, которую предлагает JavaRush. Посмотрел тестовое задание и немного ужаснулся. Очень надеялся, что поможет друг его сделать, но за неделю до дедлайна он сказал, что вот тебе Гугл, вот тут вбивай все технологии и там будет куча примеров. Я ему очень благодарен, что так получилось, так как тогда я впервые почувствовал, что значит быть программистом. За 4 полных дня я сделал задание и был невероятно рад, что попал на стажировку.

Стажировка. Стажировку я до конца не прошел, так как в это же время начал делать свой первый проект и все же он для меня оказался приоритетнее и интереснее + я не хотел работать в enterprise. Что могу сказать о самой стажировке – есть свои плюсы и минусы, но в целом довольно таки хорошо. Если планируете дальше идти в enterprise, то думаю ее стоит пройти.

Первый проект. Как и упоминал выше, что где-то на 30х уровнях я попал на стажировку и начал делать свой проект. Это был и есть бот в телеграмме. Желание создать бота было у меня еще на 20-30 уровнях курса, но я никак не мог найти подходящей либы либо инструкции how to start. И все же случайным образом мне попалась такая статья и я сразу начал пробовать. Если кому интересно – вот ссылка на статью —
How to write bot in telegram Java
Откровенно говоря, автор этой статьи мне потом еще очень сильно помог, речь о чем пойдет чуть ниже. Идея для бота была такая – мне как программисту нужно изучать Английский язык. Грамматику я знал относительно хорошо, а вот словарный запас захотел подтянуть. Подумал, что неплохо бы было иметь бота для изучения слов. Подробную информацию о боте я уже писал в статье ранее, поэтому повторятся не буду – вот ссылка Телеграм бот Words

Расскажу, с какими трудностями мне пришлось столкнуться, при его создании. Во-первых это первая работа с telegram api. Хоть многие и говорят, что это одно из простейших и наиболее лучше документированных api, но мне тогда как новичку было очень сложно. Все делал путем подбора :) Иногда на то, что бы сделать какую-то фичу, например, убрать кнопку после ее нажатия мне приходилось потратить полный день. Где-то за пол месяца удалось написать самую первую бета версию, весь код которой был в одном java классе, и хотел попробовать залить ее на сервер. Проект у меня не коммерческий, поэтому платные сервера я сразу же отбрасывал. Вспомнил о сервере heroku, который кстати используют для размещения сайта на стажировке. Пробовал этот сервер два полных дня и уже был в полном отчаянии, так как не получалось вообще ничего – все инструкции которые были относились к сайтам, а у меня бот и там нужно действовать немного по-другому. В итоге я решил написать автору статьи о боте и спросить, какой он использует сервер для размещения бота. И тут удача мне улыбнулась – автор оказался очень крутым программистом (я с ним до сих пор поддерживаю связь), и он мне предложил разместить бота у себя на Linux сервере (и если я знаю линус, то выделит мне аккаунт). На начальное изучение линукса ушло один день и, конечно, не без ошибок и сложностей бот начал крутиться на сервере. Так же между всем этим делом я добил курс JavaRush и был очень доволен :)

Базу данных для бота я выбрал MySql, пересмотрел много уроков по оптимизации таблиц, выбору движка и всего прочего. Дам совет всем, кто будет делать свой первый проект – старайтесь сразу продумать всю его структуру и строить хотя бы относительно расширяемую архитектуру. Я же свой переписывал, наверное, раза 3 из-за таких ошибок. Да, это сложно, так как очень часто ты не знаешь что захочешь следующее добавить в свой проект, но все же на минимальном уровне сделать можно. Не пишите весь код в одном классе!!! Попробуйте использовать MVC, вспомните ООП и т.д. Самое смешное, что некоторые основные принципы ООП я начал использовать в проекте, когда он уже был почти готов. До этого я даже не задумывался о них. Конечно, пользователю вообще все равно на каком языке написан продукт, какие там используются паттерны и технологии использовались, но когда вы через пару месяцев его открываете и хотите что-то туда добавить, то очень много хороших слов о себе подумаете :) Так же не забывайте делать логирование – это позволяет как отслеживать ошибки, так и смотреть какими функциями пользователи больше пользуются и что нужно дальше развивать. В телеграмме это кстати можно очень круто сделать – отправлять все логи в режиме реального времени себе в приватный канал, так сказать можно сделать некую big data :)

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

Второй проект. Моя цель была стать Android программистом, поэтому когда более менее закончив с ботом я решил адаптировать его на Android платформу. Начал обучение с курса startandroid, так же мой лучший друг android разработчик давал мне много крутых заданий, проверял их и говорил что нужно переделать и доделать. Когда получил уже базовые навыки начал делать свое приложение. Как и с первым проектом было много разных трудностей, но если брать в целом, то немного меньше. Где-то за полтора месяца была готовая первая бета версия (пару раз пришлось переписывать весь дизайн приложения, так как я понятия не имел как он будет выглядеть). Потом я зарегистрировался как разработчик в гугл плей и залил его в маркет. Последнее время занимался оптимизацией и синхронизацией двух своих проектов. Для общей базы данных выбрал Firebase – очень хорошая документация, много уроков и для небольших проектов бесплатной версии в 1гб объема более чем достаточно.

Если кратко сказать о наибольших трудностях во втором проекте (я думаю некоторые из этих трудностей возникают и у опытных разработчиков), то это — создание многопоточности в android, много заморочек з размерами и расширениями экранов, для создания дизайна пришлось подружиться с photoshop, поддержка старых версий андроида, а так же никогда не используйте Recycler View, если у вас в списке будет анимация :) После блокировки в Украине Яндекса, а именно от туда я беру большую часть перевода и озвучки слов, пришлось добавлять дополнительные проверки в код, и просто сообщать пользвателям, что бы воспользовались vpn. Трудности даже возникли при регистрации в гугл плей – там что бы стать разработчиком нужно одноразово(в отличии от апл стора) заплатить взнос в размере 25$. У меня же при оплате стоял лимит на карточке и оплата моя зависла. Пришлось пообщаться с тех поддержкой гугла и в общем они меня посылали от одного оператора к другому, пока я не понял, что меня просто вежливо посылают :) Пришлось удалять все и заново регистрироваться (сразу бы до этого додумался).

Еще пару слов по поводу продвижения своих проектов. С ботом дела обстояли немного проще – сама идея ботов относительно новая (в самый мейнстрим я не попал, но все же нормально). Есть каталог ботов, группы вк, фб другие ресурсы. Сейчас мой бот занимает 5 место в разделе образовательных и для меня это очень хороший результат. Что бы продвигаться в каталоге ботов, нужно что бы его оценивали. Я сделал предложение для пользователя о голосовании, которое возникает всего один раз (сам не люблю навящивости), когда пользователь сыграет определенное количество игр (как бы проведет некоторое время в боте).

С андроид приложением дела обстоят намного хуже. Скажу одно – без рекламы ваше приложение никто не заметит в маркете даже по ключевым словам, так как их там миллионы. После того как я сделал синхронизацию между проэктами, то дал объявление в боте о моем приложении. После этого у меня появилось первые 14 скачиваний :)

Если кто дочитал до этого момента, то вот ссылка на приложение, если будет интересно — Android приложение Words.
Ссылка же на бота есть в статье о нем чуть выше по тексту.

Всем спасибо за внимание. О своем опыте собеседований, вопросах которые там задавали и вообще поиске работы расскажу во второй части.
  • ,

Как гуманитарий стал Java-программистом и переехал в Иннополис

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

Как и многие пользователи JR, я всегда с интересом читал «Истории успеха». Они неплохо мотивируют, да и в самом рассказе можно что-то почерпнуть для себя, плюс – задать автору вопросы в комментариях. И вот в комментах-то очень часто появлялась целая россыпь отговорок участников сообщества на тему «Почему у %username% получилось, а у меня не получится». Самые распространенные:
— «Я гуманитарий» («Автору легко, он закончил физтех, а я филфак»)
— «Нет времени» («Автору легко, он студент, а я на основной работе по 8 часов в день»)
— «Я слишком старый» («Автору легко, ему 23, а мне за 30 уже»)
В этом плане моя история, наверное, будет очень показательной.

Вкратце о себе.
Возраст – 25 лет на момент начала обучения. Образование – историческое. В школе терпеть не мог математику и информатику (хотя до 7 класса был олимпиадником — дальше не повезло с учителем), поэтому все часы этих предметов проводились за игрой в Counter-Strike в ближайшем компьютерном клубе. В итоге я благополучно сбежал от этих предметов на истфак, благо историю полюбил со школьных лет.

После окончания вуза встал выбор: идти работать по специальности (вставьте сюда любую шутку про зарплату учителей), поступать в аспирантуру или заниматься чем-то другим. Вариант идти в школу отпал сразу, аспирантура – еще 3 года учебы и неясные перспективы. В результате поисков работы я оказался на позиции оператора колл-центра в одном из крупных коммерческих банков. Не бог весть что, но платили там вполне неплохо (уж точно больше, чем учителям и аспирантам), да и я за первые несколько месяцев навострился продавать клиентам кредитки и страховки, за счет чего получал неплохую премию. Но работа была действительно тяжелой. Не шахта, конечно, но принимать 200 звонков ежедневно, поверьте, то еще удовольствие.

Тем не менее, в компании были неплохие возможности карьерного роста, и за 2 года я дорос до начальника группы. Уровень зарплаты – вырос, уровень ненависти к работе – тоже. Причем второе выросло значительно больше. Теперь приходилось работать в ночную смену, отвечать за полтора десятка человек и выслушивать ежедневные уроки жизни от начальства – «эффективных менеджеров» made in USSR.
Кризис и рост курса валют после известных событий сильно ударил по банковской отрасли в России, в результате чего в конце 2015 года я в числе многих остался без работы. Именно тогда я впервые наткнулся на JavaRush, точнее – на их группу ВКонтакте. «Невозможно пройти все уровни и не стать программистом» — звучало амбициозно. Программирование не было моей мечтой, но почему бы не освоить новую профессию? Вдруг понравится, да и что я теряю? В конце концов, «программист» — уж точно не хуже, чем «менеджер по продажам»:)

Попробовать решил просто «от балды», тем более что самостоятельное обучение онлайн мне всегда нравилось, до этого я неплохо прокачал английский на LinguaLeo.
Первые 10 уровней я прошел относительно быстро. К моему удивлению, у меня все получалось, поэтому было принято решение все-таки купить подписку и идти до победного. Мой процесс обучения мало отличался от остальных. Так же ленился и забивал на 2-3 недели, как многие, так же тупил на многопоточности после 20-го уровня, так же плюнул за большую задачу на 27-ом)) Впрочем, в итоге мне все-таки удавалось заставить себя заниматься более-менее стабильно даже в условиях усталости после работы. В результате за год в свободное от работы время было пройдено 36 уровней.
Посчитав свои навыки уже довольно высокими, я решил принять участие в стажировке (благо подписка позволяла). Скачал тестовое задание, иии… Вот в этот момент я был максимально близок к тому, чтобы на все плюнуть и забить на программирование. Я вообще не понимал, с какого бока к нему подступиться. В перечисленных технологиях, естественно, ни бум-бум. Spring, Hibernate, базы данных, JSP какие-то… Попытки делать «по гайдам» ни к чему ни привели. Запросы в гугле «зачем нужен Spring» выдавали какой-то непонятный ад и курс Батыршинова, состоящий из 178 видео.
Я не на шутку расстроился, ведь считал себя уже готовым к настоящей работе. В результате на месяц или полтора о программировании я забыл и занимался основной работой (на тот момент уже в другой компании).
По славной голливудской традиции в каждом фильме должен быть Момент, Который Изменил Все. В моем случае это был день, когда мне на глаза попалась реклама курсов программирования с возможностью переезда в город Иннополис.

apply.innopolis.ru/stc/

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

Сама идея показалась очень заманчивой. Город выглядел круто. Бесплатное проживание в течение 2-месяцев, обучение у опытного преподавателя – тоже бесплатное. Но главное – организаторы брали на себя вопрос организации собеседований в компаниях-резидентах Иннополиса (а попасть на собеседование, как известно, уже полдела). Была только одна проблема – нужно было увольняться с нелюбимой, но худо-бедно оплачиваемой работы и ехать в незнакомую Казань. В буквальном смысле «все бросить и уехать». Тем не менее, после недолгих совещаний моя девушка и два кота меня поддержали, и было принято решение попробовать. Да и действительно, чего ради я учился целый год?
Возможно, кто-то из читающих вспомнит мой пост того периода, который я оставлял перед поездкой, в надежде «разведать обстановку».
2 месяца в Казани были одним из лучших периодов моей жизни. Вместе с другими «студентами» (возрастом от 19 до 40 лет) мы жили в Деревне Универсиады (в студенческие времена мне не удалось пожить в общаге, так что можно сказать — наверстал). Первая половина дня проходила на курсах, вторая – за выполнением домашнего задания. На курсах удалось пройти и Spring, и Hibernate, и PostgreSQL и еще целую россыпь технологий. Школа JavaRush очень пригодилась. Обучение начиналось с JavaCore, которые многие видели впервые в жизни, а я уже неплохо знал. В процессе я выполнил и задание для стажировки без особых проблем.

После обучения меня пригласили на собеседование в одну из компаний-резидентов Иннополиса. Первое собеседование, ура! Я не филонил и усердно готовился. В итоге прошел его вполне достойно. Конечно, как и многие новички, от волнения пару раз накосячил на элементарных вопросах (типа приведения типов), но при этом без проблем отвечал на относительно сложные, чем весьма позабавил собеседующего. Собеседование длилось без малого 2 часа, но оно того стоило. Ведь уже вечером мне сообщили, что компания намерена сделать мне оффер. Предварительное предложение со всеми условиями тоже пришло на почту почти сразу.
Обрадовав девушку и котов по телефону (скоро переезжаем!) и отметив с однокурсниками радостное событие, я засобирался домой. Учеба подошла к концу. Радости и гордости не было предела. Еще бы, первое собеседование – и сразу успех!

Если читатель думает, что на этом история закончена, то могу сказать, что самое интересное еще впереди:)
И раз уж я начал следовать славным голливудским традициям, то в каждом фильме должен наступить Момент, Когда Все Становится Плохо.

Сбор вещей и завершение текущих дел дома занял пару недель. Однако, компания почему-то не торопилась отправлять мне итоговый оффер. Стоит отметить, что на тот момент ни я, ни моя девушка уже не работали и готовились к переезду. Я связался с отделом кадров, где информацию проверили и ответили мне что-то в духе «Ой, мы про вас забыли». Спасибо, очень приятно. Ну, хоть не зря о себе напомнил. Однако прошло еще две недели, а потом еще две. Тем не менее, серьезных поводов для беспокойства не было: со мной теперь хотя бы регулярно связывались. Сначала попросили пройти внутренний тест (с которым я успешно справился), после – выслать некоторые документы.

Но вот прошло еще 2 недели. Итого общий срок ожидания составил уже 2 месяца, что уже было как-то совсем неадекватно. Написав на электронную почту HR, я получил ответ следующего содержания:
«Добрый день! Со стороны отдела кадров получена информация, что найм, к сожалению, остановлен ввиду отсутствия у Вас профильного (IT) образования.»

С позволения читателей, я не буду приводить текст письма, который я отправил в ответ. Но, думаю, мое состояние в тот момент легко представить. Я бросил работу, уехал учиться в другой город, прошел собеседование, получил предложение о работе, обрадовался и обрадовал семью – и такой печальный итог. Не говоря уж о финансовой ситуации; выжить в эти пару месяцев после учебы удалось только благодаря имевшейся заначке, которая уже подходила к концу.
И самое обидное – на каждом этапе компания знала, какое у меня образование. Даже собеседующий меня сотрудник отметил это («О, гуманитарий-самоучка? Прикольно»). Мое образование было указано и в резюме, что не помешало им позвать меня на собеседование, а мне – успешно его пройти.
Но делать было нечего, надо было искать работу. Откликнувшись на кучу вакансий в «Моем круге» я получил одно приглашение на собеседование в компанию из Санкт-Петербурга, но на фоне всех происходящих событий настроение было такое, что я полностью его провалил.

Идее стать программистом, можно сказать, пришел конец.

Но в каждом фильме есть Момент, Когда Все Стало Хорошо:)

Обо всей ситуации узнала куратор университета, в котором я учился на курсах. Она связалась с ресурсным центом Иннополиса, а после – со мной, сообщив, что еще в одной компании Иннополиса ищут Java-разработчика, и хотели бы провести со мной собеседование по Skype через три дня.
Стоит ли говорить, что мотивации у меня было хоть отбавляй. За первые 2 дня был целиком прочитан Head First SQL (я засыпался на вопросах по БД на предыдущем собеседовании), третий день ушел на разбор остальных тем, в которых я плавал.
В итоге мое третье по счету собеседование в жизни оказалось самым удачным. Я справился процентов на 95, чуть застопорившись разве что на вопросах про транзакционность.
Уже через день я общался с техническим директором, который подробно рассказал об условиях работы. Через неделю я был оформлен в штат компании и начал работать удаленно, а еще через две переехал в Иннополис.
Воистину, нет худа без добра. Новая компания предложила зарплату значительно большую, чем предыдущая, и ко всему прочему оплачивает 2-комнатную квартиру в Иннополисе.
Я живу здесь уже 3 месяца, пару дней назад закончился мой испытательный срок.
Отличная работа, прекрасный город, дружный коллектив и все возможности для профессионального развития.
Хотя, конечно, без стресса поначалу не обошлось, особенно когда в первый же день мне упала задача реализовать модуль на Reaсt+Redux. Стоит ли говорить, что о JavaScript я знал на тот момент только из статьи в Википедии))
Поэтому, коллеги, когда на JavaRush в очередной раз попадается задача из серии «эту технологию мы еще не проходили» — привыкайте. В реальном проекте вполне может прилететь задача не то что на технологии, а на языке, который вы впервые видите:)

Несколько слов в завершение.

Большое спасибо команде JavaRush за то, что вы создали лучший обучающий ресурс в Рунете. Отдельное спасибо за помощь с резюме – пользуюсь вашими шаблонами до сих пор.

Спасибо всем юзерам форумов help и info, которые помогали с задачами весь год. Вы лучшие!

Друзья, даже если вы безнадежный гуманитарий, как я, или вам уже за 30, у вас жена и дети, как у автора вот этой истории – пробуйте, и у вас все получится. Насчет последнего могу сказать точно, ведь с этим человеком, так уж вышло, мы теперь работаем в одной компании и сидим за соседними столами:)

Я не уверен насчет дальнейшего ведения этого блога, но несколько идей у меня есть.
Я хотел бы написать о жизни в Иннополисе глазами жителя (в интернете большая часть инфы — или реклама, или отзывы приехавших на пару дней туристов). Также неплохо было бы соорудить пост в помощь тем, кто пытается поступить на стажировку (мне бы в свое время такой пост точно пригодился). А также свести в одном месте советы тем, кто скоро выйдет на тропу войны поиска работы, с изложением личного опыта.
Я не уверен, что вся эта писанина будет хоть кому-то интересна; но если вы из таких людей – подписывайтесь на блог, при наличии читательского интереса грех будет забросить все это дело:) На вопросы буду рад ответить в комментариях, туда же можно адресовать «Автор, напиши отдельно про…»
Успехов вам!

Что изучать дальше?

Добрый вечер. Мне 15 лет. Прошёл первые 10 уровней Javarush, немного изучал Android разработку, делаю свои приложения. Разработка под Android очень нравится, но чувствую что надо ещё что-то по Javе подучить. Порекомендуйте, пожалуйста, какие интересные книги по Java для развития почитать или что-нибудь другое.
P.S Стоит ли покупать подписку на Javarush, и какую?
P.P.S Также, интересно было бы узнать, как делать программы на java под Windows и сделать самому такую.
P.P.P.S Ещё ищу хороший и объемный материал по Android разработке
  • ,

Сколько ты стоишь (перевод)

Перевод с сайта yegor256.com. Оригинал статьи на английском.

Статья вызывала достаточно бурную реакцию в блоге Евгения Бугаенко. В ней описываются критерии, которые по мнению автора влияют на размер почасовой оплаты программиста. Позиция не однозначная, вызывает вопросы, но, тем не менее имеет место быть.

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

Оригинал перевода размещен здесь.

________________________

Я получаю несколько писем каждый день от программистов заинтересованных работать с teamed.io удаленно. Первый вопрос, который я обычно задаю это «Какая твоя почасовая ставка?» (мы платим по часам). Меня удивляет как часто люди некорректно оценивают себя как в большую так и в меньшую сторону.

Мне называют различные цифры, от 5 до 500$ в час. Я никогда не говорю нет, но обычно прихожу к своей оценке часовой ставки. Эта статья объясняет какие факторы я рассматриваю а какие нет. Это мои персональные критерии, не принимайте их как профессиональный стандарт. Мне они кажутся объективными и логичными.

Вклад в проекты с открытым исходным кодом.

badge

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

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

Вторая возможная причина, это ты работаешь с девяти до пяти за еду, без страсти. На самом деле в этом никто не сознается. Я часто слышу что-то вроде «моя компания не платит мне за вклад в open source проекты, а дома я хочу проводить время со своей семьей». В современной разработке ПО, большинство кода, с которым мы работаем, является открытым – библиотеки, фрэймворки, инструменты и прочее. Почти все что ты используешь в твоем коммерческом проекте — это open source. Платя тебе зарплату твой работодатель уже осуществил вклад в продукты с открытым кодом, потому что ты активно их используешь. Проблема в том, что ты при этом не заинтересован быть более активным и делать свой вклад в open source проекты. Я вижу это как недостаток страсти и мотивации. Будешь ли ты эффективным разработчиком в наших проектах? Вряд ли, потому что наша система менеджмента опирается на само-мотивацию.

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

Поэтому, если твой GitHub аккант пуст и твое CV не содержит строчки «активно участвую в развитии ядра Linux» (а почему бы и нет?), я моментально теряю интерес. С другой стороны, когда я вижу 100+ звездочный проект на твоем GitHub, я воодушевляюсь и готов предложить большую оплату.

Месторасположение

Распространенная практика платить больше тем, кто живет в более дорогих странах. Когда я получаю резюме из Сан-Франциско, запрашиваемые ставки составляют $70+ в час. Те же самые навыки и опыт стоит $15-20 для Карачи. Причина – стоимость жизни в США значительно выше, чем в Пакистане.

Однако, эта причина для меня нелогична. Если ты ездишь на более дорогой машине, обязаны ли мы тебе платить большую зарплату? Аналогично с твоим местоположением. Ты выбрал страну проживания. Ты пользуешься всеми преимуществами развитой страны и платишь за это. Это твой выбор. Ты решил тратить больше денег за качество жизни – какое это имеет отношение ко мне?

Хочешь платить $30 за ланч? Стань лучше как разработчик. До тех пор, покупай хот дог за пару баксов. Просто фраза «Я уже здесь и мой ланч стоит $30» — не аргумент.

Соответственно если ты живешь в более дорогом месте, меньше денег остается в твоем кармане. Для нас это значит, что $100 замотивируют программиста из Карачи гораздо сильнее чем те же самые $100 замотивируют того же самого человека, если бы он жил в Сан-Франциско. Поэтому мы предпочитаем работать с людьми, чьи расходы ниже. Наши деньги таким образом лучше работают.

Репутация на StackOverflow.com

Мы все знаем, что на StackOverflow очень мало людей, даже удивительно мало людей, которые активно вносят в него свой вклад. Если твой профиль пустой (или если у тебя его нет), тогда понятно, что у тебя 1) нет вопросов чтобы задавать, 2) тебе нечего отвечать.

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

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

Я часто слышу, что люди решают большинство их проблем, задавая вопросы коллегам, сидящим рядом с ними в офисе. Они говорят, StackOverflow им просто не нужен (или другие похожие ресурсы, если они существуют), потому что их команда так хороша, что всегда можно получить ответ на любой вопрос. Это хорошо для команды, но плохо для тебя. Почему? У тебя нет важного навыка – нахождение ответа в публичном Интернете. В наших проектах мы не поощряем любые горизонтальные коммуникации между программистами, и ты не сможешь получить помощь ни от кого. Ты будешь сам по себе и ты провалишься, потому что ты привык получать помощь от старших в своем офисе.

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

Стаж работы

badge

«Я писал на Java 10 лет!» — и что? Это число значит только одну вещь для меня – ты сумел выжить в каком-то офисе в течение 10-ти лет. Или может быть в нескольких офисах. Ты убедил кого-то, что он должен платить тебе за твои 10 лет проведенных в его здании. Значит ли это, что ты писал что-то полезное? Значит ли это, что твой код был идеальным? Ни первое, ни второе.

Стаж работы это ложный индикатор. Это даже может сыграть против тебя, в комбинации с другими индикаторами, обозначенными выше. Если твое CV говорит, что ты только начал программировать 2 года назад и твой GitHub и StackOverflow аккаунты пустые – есть возможность что ты исправишься. Ты просто в начале своей карьеры. Однако, если твое CV говорит что ты «10-ти летний системный архитектор» с нулевым вкладом в открытые проекты — это значит что ты или лжёшь о 10-ти годах или ты абсолютно бесполезен как архитектор.

Моя точка зрения такова, что «опыт работы», как аргумент, должен быть использован очень аккуратно. Разыгрывай эту карту, только если у тебя есть другие достоинства. В противном
случае, держи это при себе.

Сертификаты.

Oracle, Zend, Amazon, IBM, MySQL и прочие – вот о каких сертификатах я говорю. Чтобы получить их ты должен пройти экзамен. Не легкий, и не онлайн. Это реальный экзамен, который сдается в сертификационных центрах, где ты будешь сидеть за компьютером, в условиях ограниченного времени, без книг или доступа к Интернету и будешь отвечать на вопросы. Достаточно унизительно для такого уважаемого разработчика? Ага. И также очень высока вероятность провалится, что тоже достаточно неловко.

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

Первая, ты боишься провала. Серьезная сертификация может стоить несколько сотен долларов (я платил более $700 за SCEA) и ты не получишь их назад если провалишься. Если ты боишься проиграть, ты боишься сражаться. Это значит, что ты струсишь в реальных ситуациях, когда надо решать реальные проблемы.

Второе, ты не инвестируешь в себя. Это скорее всего значит что ты не хочешь менять компании и предпочитаешь найти уютный офис, где ты бы мог сидеть вечно. Я помню однажды сказал своему другу – «Ты значительно улучшишь свое CV, если получишь этот сертификат». Он ответил с улыбкой – «Я надеюсь, что мне не понадобится CV. Мне нравится эта компания». Этот подход хорош для компании, на которую ты работаешь, но это точно работает против тебя.

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

Разнообразие навыков.

Чем больше технологий или языков программирования ты знаешь, тем меньше ты стоишь. Я не говорю, что невозможно быть экспертом во многих вещах одновременно – это абсолютно возможно. Но позволь мне дать прагматическую причину почему не следует этого делать – конкуренция. На рынке тысячи программистов на Java7 – мы можем легко взять любого, кто нам нужен. Но не так много программистов Hadoop или XSLT дизайнеров.

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

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

Выступления и Публикации

badge

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

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

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

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

Предыдущее место работы

Я обычно не обращаю большое внимание на этот раздел твоего CV. Наша модель управления настолько отличается от всего, что ты мог где-либо видеть, что это не имеет никакого значения сколько раз тебя увольняли или как высок был твой пост в твоей компании. Даже если твоя должность «Технический директор Twitter» — это ничего не значит для меня.

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

Я более заинтересован в том «Что ты делал» в последние годы, чем «Где ты делал» это или «Как тебя называли» пока ты этим занимался.

Образование

BSc, MSc, PhD… важно ли это? Не думаю. Образование очень схоже с «Предыдущим местом работы», обозначенным выше. Не так уж и важно где ты провел пять лет после школы. Важно что ты делал в это время. Если тебе нечего сказать о своей активности в студенческие годы, тогда что мне скажет название твоего ВУЗа?

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

Оплата

$100+ в час мы с радостью платим эксперту который владеет несколькими продуктами с открытым исходным кодом, имеет рейтинг на StackOverflow более 20к, имеет сертификаты, статьи, презентации или даже патенты.

$50+ мы платим профессиональному программисту, владеющему проектом с открытым исходным кодом или является активным участником такого проекта, имеющему рейтинг на StackOverflow больше 5к, пишущему о разработке ПО, владеющему сертификатами.

$30+ мы платим программисту регулярно вносящему вклад в проекты с открытым исходным кодом, имеющему активность на StackOverflow, с несколькими сертификатами.

$15+ мы платим всем остальным.

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

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

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

Кстати, иллюстрации к посту созданы Andreea Mironiuc.


https://www.youtube.com/watch?v=GS45LzE3LPQ

Мои ответы на вопросы собеседований из 40 уровня

Собственно, такие вопросы были на этом уровне:
1. Что такое IP-адрес?
2. В чем отличие host и domain?
3. Какие методы в HTTP вы знаете
4. Чем отличаются методы GET, POST и HEAD?
5. Что такое REST?
6. Зачем нужен класс Calendar в Java?
7. Как преобразовать дату в Java к нужному формату?
8. В чем отличие URI и URL?
9. Что такое сокеты?
10. Отличие классов Socket и URL?

А вот мои ответы:
1. IP-адрес — это уникальный сетевой адрес узла в компьютерной сети, построенной на стеке протоколов TCP/IP. В сети Интернет требуется глобальная уникальность адреса; в случае работы в локальной сети требуется уникальность адреса в пределах сети. В версии протокола IPv4 IP-адрес имеет длину 4 байта, а в версии протокола IPv6 IP-адрес имеет длину 16 байт. Обычно IP-адрес в версии протокола IPv4 записывают в виде четырёх десятичных чисел со значениями от 0 до 255, разделённых точкой, например, 192.168.0.3.

2. Домен — это адрес сайта или определённая зона, которая имеет своё имя, не похожее ни на какое другое имя в системе доменных имён. Домены бывают первого уровня, второго уровня, третьего уровня и т.д. Обычно домен первого уровня не доступен обычным пользователям для регистрации (примеры доменов первого уровня — ".ru", ".com", ".net"). Обычно домены третьего и следующих уровней называют субдоменами.
Хост — это определённый компьютер или сервер, подключенный к локальной или глобальной сети. Хост обладает обладает уникальным адресом в среде сервисов TCP/IP (IP-адресом).

3.GET, POST, PUT, DELETE, OPTIONS, HEAD, PATCH, TRACE, LINK, UNLINK, CONNECT.

4.

                        GET	POST	HEAD
---------------------------------------------
Тело Запроса            Нет	Есть	Нет
Тело Ответа             Да	Да	Нет
Кеширование
результата Запроса      Да	Нет	Да, заголовки	
Идемпотентность         Да	Нет	Да


Метод GET используется для запроса содержимого указанного ресурса. Метод POST применяется для передачи пользовательских данных заданному ресурсу. Метод HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения. Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Метода GET считает упрощённой версией POST, потому как метод GET не предполагает полноценного запроса, только URL в качестве такового.

5. REST — это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Термин был введён Роем Филдингом в 2000 году. Также им были введены требования, которым должно удовлетворять распределённое приложение, чтобы соответствовать архитектуре REST (такие приложения ещё называют RESTful). Вот эти требования:
1) Модель «Клиент-Сервер» (означает, что сеть должна состоять из клиента и сервера; сервер — это тот, кто обладает ресурсами, клиент — тот, который их запрашивает))
2) Отсутствие состояния (означает, что ни клиент, ни сервер не отслеживают состояния друг друга)
3) Кеширование (клиенты и промежуточные узлы могут кешировать результаты запросов; сооответственно, ответы сервера должны иметь явное или неявное обозначение, что они кешируемые или некешируемые)
4) Единообразие интерфейса (означает, что между клиентами и серверами существует общий язык взаимодействия, который позволяет им быть заменяемыми или изменяемыми, без нарушения целостности системы):
а) Определение ресурса (означает, что каждый ресурс должны быть обозначен постоянным идентефикатором)
б) Управление ресурсами через представление (означает, что клиент хранит ресурс в виде его представления, и при желании изменения ресурса он отправляет серверу информацию о том, в каком виде он хотел бы видеть этот ресурс; сервер же рассматривает этот как запрос как предложение, и сам решает, что делать ему с хранимым ресурсом)
в) Самодостаточные сообщения (каждое сообщение содержит достаточно информации, чтобы понять, как его обрабатывать)
г) Гипермедиа (означает, что клиенты изменяют состояние системы только через действия, которые динамически определены в гипермедиа на сервер)
5) Система слоёв (означает, что в системе может быть больше двух слоёв (клиент и сервер), и при этом каждый такой слой знает только о своих соседних слоях, и не знает об остальных слоях, и взаимодействует только с соседними слоями)
6) Код по требованию (означает, что функциональность клиента может быть расширения за счёт загрузки кода с сервера в виде апплетов или сценариев)

Удовлетворение этим требованиям позволяет добиться следующего:
* Надёжность
* Производительность
* Масштабируемость
* Прозрачность взаимодействия
* Простота интерфейсов
* Портативность компонентов
* Лёгкость внесения изменений
* Способность эволюционировать, приспасабливаясь к новым требованиям

6. Он нужен для более удобной работы с датой и временем. Он позволяет работать с датой в рамках календаря, то есть позволяет прибавлять и отнимать дни от какой-то конкретной даты, причём будут учитывать и високосные года. Кроме того, он позволяет представить время миллисекундах в удобном виде — год, месяц, день, часы, минуты, секунды. Также есть много методов для установки и получения разных параметров даты и времени, например: день недели, день месяца, день в году, номер недели в месяце, номер недели в году.

7. Для этого существует удобный класс SimpleDateFormat. Экземпляру этого класс можно передать шаблон представления даты, и тогда он в таком виде будет возвращать дату (в формате строки String), либо считывать дату (из строки String). Выглядит это всё следющим образом:
Date date = new Date(); // получаем текущую дату
SimpleDateFormat formatter = new SimpleDateFormat(«d-MM-yy HH:mm:ss»); //создаём экземпляр класса SimpleDateFormat
//и передаём ему шаблон представления даты и времени
String dateAsString = formatter.format(date); //преобразуем дату в строку заданного формата

Date dateAfterConversion = formatter.parse(dateAsString); //преобразуем строку обратно в дату

8. URI расшифровывается как Uniform Resource Identifier и переводится как «унифицированный идентификатор ресурса». URI — это последовательность символов, идентифицирующая абстрактный или физический ресурс. URL расшифровывается как Uniform Resource Locator. То есть это некий унифицированный указатель на ресурс, однозначно определяющий его месторасположение. URL служит стандартизированным способом записи адреса ресурса в сети Интернет.
Их отличия в том, что URI — это некоторый идентификатор ресурса, который позволяет этот ресурс как-то идентифицировать, а URL — это указатель на ресурс, он даёт информацию о том, где находится ресурс. Таким образом URL — это URI, который помимо индетификации ресурса, даёт информацию о его местонахождении.

9. Сокеты — это связка IP-адрес + порт, позволяющая из внешней сети однозначно идентифицировать программу на компютере или сервере. В Java для работы с сокетами есть два класса Socket и ServerSocket. Экземпляры первого класса играют роль клиента, экземпляры второго — роль сервера. Клиент может отправлять и принимать сообщения через сокет. Сервер же постоянно отслеживает запросы пользователей и отвечает на них.
Для того, чтобы отправить данные через сокет, в классе Socket существует класс getOutnputStream(), возвращающий исходящий поток, с которым уже можно работать как обычно. Для приёма информациию нужно воспользоваться методом getInputStream(), который возвращает входящий поток. Дальше с этим потоком можно работать как с обычно потом ввода. Также стоит отметить, что при создании клиентского сокета (экземпляра класса Socket) в конструктор нужно передать ip-адрес сервера и порт, на котором он работает принимающая программа-сервер.
При создании серверного сокета (экземпляра класса ServerSocket) нужно указывать только порт, через который будет работать программа. После этого вызывается метод accept(). Этот метод ожидание подключение клиента, а после этого возвращает экземпляр класса Socket, необходимый для взаимодействия с этим клиентом. Дальше работать идёт с экземпляром класса Socket, как в первом случае (в случае клиента).

10. Главное отличие в том, что класс URL предназначен для работы с URL-строкой (парсинг URL-строки), а Socket используется для соединения с удалённым сервером и отправки информации на сервер и/или приёма информации от сервера (хотя, используя класс URL, можно получить доступ к ресурсу, на который указывает сам URL; но делается это не напрямую, а через объект класса URLConnection). Также, если смотреть в общем, то Socket используется для связи с сервером (другой программой), а URL — для доступа к ресурсу (например, к файлу). Кроме того, URL и URLConnection ориентированы в основном на работу с HTTP, тогда как Socket может работать с любыми протоколами.
  • ,

com.javarush.task.task23.task2312; (Змейка 11)

Змейка(11)
Теперь логика управления мышью.

С мышью у нас будут происходить две вещи.
Первая — змея съедает мышь.
Вторая — появляется новая мышь в случайной точке комнаты.
Надо написать и реализовать метод createMouse() в классе Room.
В этом методе мы просто должны создавать новую мышь со случайными координатами в комнате.
Как получить случайные координаты?
Это ты уже должен был знать. На всякий случай даю подсказку:
int x = (int) (Math.random() * width);
Еще понадобится метод — eatMouse(), на случай, если мышь все-таки кто-то съест :)
Пока сложной логики в этом методе не будет — просто будем вызывать метод createMouse и все.
Требования:
1. В классе Room должен быть создан метод createMouse.
2. В методе createMouse должна быть создана новая мышь по правилам описанным в условии и сохранена в поле mouse.
3. В классе Room должен быть создан метод eatMouse.
4. В методе eatMouse должен содержаться вызов метода createMouse.

public void eatMouse() {
createMouse();
}

public void createMouse() {
int x = (int) (Math.random() * width);
int y = (int) (Math.random() * height);
mouse = new Mouse(x, y);
}

ПОМОГИТЕ! Что не так делаю? ВАЛИДАТОР не принимает решение, хотя в интернете оно абсолютно то же самое и у людей подобное решение валидатор принял.

Мои ответы на вопросы собеседований из 39 уровня

Список вопросов:
1. Что такое web-сервер?
2. Что такое Tomcat?
3. Что такое сервлеты и где они используются?
4. Какие режимы запуска приложений в IDEA вы знаете?
5. Можно ли дебажить приложение/сервлет, которое запущено внутри Tomcat’а?
6. Как в IDEA установить точку остановки?
7. Как в IDEA посмотреть список всех точек остановки?
8. Можно ли с помощью IDEA поменять значение переменной в процессе работы программы?
9. Как в IDEA настроить отступы?
10. Как в IDEA настроить, чтобы { отображалось на той же строке, а не на новой?

Мои ответы:
1. Веб-сервер — это сервер, принимающий HTTP-запросы от клиенты (чаще всего — браузеров) и выдающий им HTTP-ответы, как правило вместе с HTML-страницей, изображений, файлом, медиа-потоком и другими данными.

2. Apache Tomcat — это контейнер сервлетов, разработанный компанией Apache Software Foundation. Реализует спецификацию сервлетов и спецификацию JSP (JavaServer Pages) и JSF(JavaServer Faces). Позволяет запускать веб-приложения, содержит ряд программ для самоконфигурирования. Может выступать в качестве самостоятельного веб-сервера, в качестве контента (в сочении с Apache HTP Server), а также в качестве контейнера сервлетов в серверах приложений JBoss и GlassFish.

3. Сервлет — это Java-класс, наследуемый от класса HttpServlet и реализующий любые из методов: doGet(), doPost(), doPut(), doDelete(), а также init() и destroy(). Этот класс используется веб-сервером для обработки запросов и формирования ответов на эти запросы. Каждый запрос обрабатывается в отдельном потоке. Контейнер контейнер вызывает метод service() для каждого запроса. Этот метода смотрит на тим входящего запроса и пересылает его соответствующему методу. Если данный метода не реализован в сервлете, то этот метод вызывается у супер-класса, и обычно завершается возвращение ошибки инициатору запроса.

4. Приложение в IDEA можно запустить в двух режимах: обычный запуск приложения и запуск в режиме отладки. Обычный запуск приложения — это обычно его выполнение. В режиме отладки же приложение можно выполнять построчно. Также в этом режиме можно ставить точки останова (breakpoints) на некоторые строчки кода (программа будет выполнять как обычно, пока не встретит такую точку; как она её встретит, она остановится). Кроме того, этот режим позволяет смотреть значения переменных во время выполнения программы.

5. Да, это можно делать, и это можно делать даже из самой IDE. Например, чтобы запустить отладку сервлета из IDEA, нужно сделать следующее:
1) Зайти в найстроки отладки/запуска приложения
2) Добавить конфигурацию Remote
3) Далее выводится страница, где нужно изменить адрес хоста, на котором находится Tomcat, и порт
4) Открыть файл catalina.bat (для Windows) и исправить в нём строчку «set DEBUG_OPTS=». Туда нужно дописать следующее "-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1985". Последнее число — это адрес порта, который мы указали на шаге 3.
5) Перестартовать Tomcat
6) Выставить точки останова в коде в нужных местах
7) Нажать Debug в IDEA
8) Отправить запрос
9) Произвести отладку из среды разработки

6. Либо можно нажать мышкой в поле между номером строчки и началом строки, либо встать на какую-то строчку и нажать на клавиатуре ctrl+F8, либо встать на строку и вверху в меню выбрать Run -> Toggle line BreakPoint.

7. Либо сочетанием клавиш ctrl+shift+F8, либо выбрать в меню Run -> View Breakpoints…

8. Да, есть такая возможность. Это можно сделать в режиме отладки. Во время отладки нужно в окне переменных выбрать нужную переменную и нажать F2, либо щёлкнуть по переменной правой кнопкой мыши и в открывшемся меню выбрать «set value», и ввести нужное значение переменной.

9. Нужно зайти в настройки (Settings), там выбрать Editor, потом — Code Style. Там уже можно изменить общий опции, либо изменить найстройки отступов для каждого поддерживаемого формата файла.

10. Нужно перейти по следующему пути Settings -> Editor -> Code Style -> Java -> Wrapping and Braces, и дальше в разделе Braces Placement изменять найстройки (для класса, метода, лямбда-выражений, других случаев).

Мои ответы на вопросы собеседований из 38 уровня

Здравсвтвуйте. Опять-таки, похоже нет ответов на вопросы из этого уровня. Поэтому, как обычно, выкладываю свои. Вдруг, кому помогут (или кто-то что-то дополнит или ответит лучше).
Итак, были такие вопросы:
1. Что такое Agile?
2. Что такое Scrum?
3. Какие роли Scrum вы знаете?
4. Что такое спринт? Расскажите с подробностями
5. Кто такие QA?
6. Кто такой product owner?
7. Расскажите об иерархии исключений
8. Что делать если JVM выкинула Error?
9. Какие нововведения в области исключений из Java 7 вы знаете?
10. Зачем нужны аннотации? Как ими пользоваться?

А теперь мои ответы:
1. Agile — это серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате взаимодействия внутри самооранизующихся рабочих групп, состоящих из специалистов разных профилией. Существует несколько методик, относящих к гибкой методологии разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

Основные концепции agile-методов:
* люди и взаимодействие важнее процессов и инструментов;
* работающий продукт важнее исчерпывающей документации;
* сотрудничество с заказчиком важнее согласование условий контракта;
* готовность к изменениям важнее следованию первоначального плана.

Также были сформулированы основные приципы такого подхода:
* удовлетвореие клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
* приветствие изменений требований даже в конце разработки (это может повысить конкурентноспособность продукта на рынке);
* частая поставка рабочего программного обеспечения (каждый месяц или каждую неделю, или даже ещё чаще);
* тесное, ежедневно общение заказчика с разработчика на протяжении всего проекта;
* проектом занимаются мотивированные личности, обеспеченые нужные условиями работы, поддержкой и доверием;
* рекомендуемый метода передачи информации — личный разговор (лицом к лицу);
* работающее программное обеспечение — лучший измеритель прогресса;
* спонсоры, разработчики и пользователи должны поддерживать постоянный темп на неопределённый срок;
* постоянно внимание улучшению технического мастерства и удобному дизайну;
* простота — искусство не делать лишней работы;
* лучшие технические требования, архитектура и дизайн полуются у самороорганизованной команды;
* постоянная адаптация к изменяющимся условиям.

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

2. Scrum — это одна из методик гибкой разработки. Она делает акцент на качественном контроле процесса разработки. Основая особенность скрама — это разбиение процесса разработки на итерации имеющий чёткую протажённость по времени (обычно 2-6 недель; их называют «спринтами»).
В начале спринта проводится «планирование спринта» — совещание на 3-4 часа, где обсуждаются основные задачи, которые будут решаться на протяжении спринта. В конце спринта проводится «демо» — демонтрация результатов работы команды за этот спринт.
Перед самым первым спринтом заказчик (или его представитель) формирует список требований, предъявляемых к будущему продукту. Такие требования называются «user story», а самого заказчика называют «product owner». Также в этом списке заказчик (PO) указывает приоритет для каждой задачи. Сначала будут реализовываться задачи с более высоким приоритетом. Весь список называется «product backlog», или «резерв продукта».
Кроме product owner, среди участников ещё выделяют scrum-мастера: он проводит все совещания, следит за соблюдением всех принципов скрама, разрешает противоречения и защищает команду от отвлекающих факторов. Обычно в качестве скрам-мастера выступает кто-то из команды.
На первом совещании в начале спринта каждой задаче, кроме того, что назчается приоритет, даётся ещё приблизительная оценка в «абстрактных человеко-днях», которые ещё называют «story point». Затем команда решает, сколько она успеет выполнить задач за время спринта. Например, заказчик отобрал 7 задач, а команда сможет сделать только 5. Тогда остальные две задачи пойдут на следующий спринт. Если заказчику это не нравится, он может повысить их приоритет, но тогда другие задачи выпадут из спринта. Кроме того, скрам-мастер может разбить некоторые задачи на более мелкие и расставить им различные приоритеты, чтобы заказчик остался доволен.
Список отобраных задач на спринт называются «sprint backlog», или «резерв спринта». Для лучшей наглядности обычно составляется таблица, в которой указываются задачи, которые нужно реализовать, которые находятся в процессе реализации, и те которые уже выполнены. Также строится диаграмма «сгорания задач». Она графическ показывает, сколько ещё задач осталось выполнить. В идеале график сгорания задач к концу спринта должен опустится до нуля.
Также в течение спринта каждый день или через день проводятся небольшие совещания внутри команды на 5-15 минут, где каждый участник команды рассказывает, что сделал за этот день (или эти два дня), что ещё ему предстоит сделать, а также рассказывает о том, что ему мешает что-то сделать.
Когда спринт завершается, scrum-master проводит demo, на котором демонстрируется список всего, что полностью сделано. Затем проводится «разбор полетов» — совещание тоже на пару часов. На нем обычно пытаются выяснить, что было сделано хорошо, а что (и как) можно было сделать лучше.
Обычно за 2-3 спринта можно выявить основные проблемы, которые мешают команде работать эффективнее, и устранить их. Это приводит к большей продуктивности, не увеличивая нагрузку на команду. Такое было невозможным до эры гибких методологий.
Также в середине спринта, иногда еще проводят «вычесывание» — совещание посвященное планированию следующего спринта. На нем обычно уточняют приоритеты задач, а так же могут разбить некоторые задачи на части и/или добавить новые задачи в product backlog – резерв продукта.

3. В крам участников делят на «свиней» и «кур». «Свиньи» полностью задействованы в процессе, «куры» — только частично. К категории «свиней» относят следующие роли:
* Скрам-мастер (проводит совещания, следит за выполнением принципов скрама и пр.; это кто-то из команды, produst owner не может быть скрам-мастером);
* Владелей продукта (Product Owner) (представляет интересы конечных пользователей и других заинтересованных в продукте сторон);
* Команда разработки (Development Team) (кросс-функциональная команда, состоящая из специалистов разных профилей: разработчиков, тестировщиков, дизайнеров, архитекторов и т.д. Размер команды в идеале составляет от 3 до 9 человек. Команда является единственные полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто, кроме команды, не может вмешиваться в процесс разработки на протяжении спринта).

К «курам» относятся следующие роли:
* Пользователи (Users)
* Клиенты, продавцы (Stakeholders) (лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review));
* Управляющие (Managers) (люди, которые управляют персоналом);
* Эксперты-консультанты (Consulting Experts).

4. Спринт — это одна итерация цикла разработки программного обеспечения в Скраме. Обычно спринт жёстко фиксирован по времени. Продолжительность спринта выбирается на основании размера команды, специфики работы, требований, размера проекта. Чаще всего это подбирается опытным путём, на основании проб и ошибок. В среднем спринт может быть продолжительность от 2 недель до 4 (хотя в некоторых компания его продолжительность бывает равна и 6 неделям). Для оценка объёма работ в спринте может быть использована предварительная оценка, измеряемая в очках истории. Предварительная оценка фиксируется в беклоге проекта.

5. QA расшифровывается как Quality Assuarance (то есть «Гарантия качества», если перевести дословно). К этой категории относятся тестировщики. Это люди, которые выявляют в программе баги и ошибки. Для этого они используют разные средства, как ручные, так и автоматические. После выявления багов и ошибок они сообщают об этом разработчикам, и те исправляют эти ошибки.

6. Product Owner (владелец проекта) — это заказчик или представитель заказчика. Это либо кто-то со стороны клиента (сторонняя фирма или физ.лицо), либо какой-то другой сотрудник фирмы, определящий требования к конечному продукту и следяющий за их выполнений (например, бизнес-аналитик). Как уже было сказано, он определяет требования к продукту и задачи, которые дожна решить команда разработки, чтобы получить конечный продукт. Список требований (или задач) он оформляет в определённым порядке и с заданным приоритетом для каждого требования (задачи). Обычно он участвует в планировании спринта (перед началом спринта) и в демонтрации результатов спринта (после окончания спринта).

7. Во главе иерархии исключений в Java стоит класс Throwable. От не наследуются два класса: Error и Exception. Объекты первого класс выбрасываются, когда возникают какие-то серьёзные ошибки в работе программы и джава-машины в целом (а также в работе ОС и аппаратной части копьютера), так, что программа больше не может продолжать работать и закрывается. Это может быть недостаток памяти (OutOfMemoryError) или переполнение стека (StackOverflowError).
Экземпляры второго класса могут выбраться при самых различных исключительных ситуаций. Собственно от этого класса наследуется класс RuntimeException и все остальные классы. Первый класс так выделяют, потому что, во-первых, исключительные ситуации такого типа являются непроверяемые (unchecked), а, во-вторых, к данным исключительным ситуациям относятся ошибки выполнения программы. Обычно это возникает из-за несовершенства кода. Все остальные исключительные ситуации обычно являются следствием непредвиденного стечения обстоятельств, например, ошибки ввода-вывода.
Также исключения делятся на проверяемые (checked) и непроверяемые (unchecked). Первые необходимо либо отлавливать в блоке try-catch, либо указывать в качестве выбрасываемых в сигнатуре метода (используя слово throws). Непроверяемые этого не требуют, и выбор остаётся за программистом. К проверяемым относятся исключения типа Throwable (а также наследуемые от него) и типа Exception (и наследуемые от него, кроме исключений типа RuntimeException). К непроверяемым относятся исключения типа Error (а также наследуемые от него) и исключения типа Runtime (и наследуемые от него).

8. Ничего, программа просто закроется. Обычно это критические ошибки, не всегда возникшие по вине программиста (например, выход из строя жёсткого диска или сбой операционной системе). Правда, среди них есть две ошибки, которые могу следствием несовершенства кода — это StackOverflowError и OutOfMemoryError. Первый тип ошибок возник, при переполнении стека вызовов — то есть, когда вызывается слишком много методов и стек вызовов становится слишком больший (типичный пример — бесконечная рекурсия или рекурсия с большим количеством итераций). Вторая ошибка — OutOfMemoryError — возникает, когда переполняет память отведённая под объекты, то есть когда создаётся слишком много тяжеловесных объектов, и они все держатся в памяти (или когда сборщик мусора не успевает их уничтожать).

9. В Java 7 в плане исключение были введены три новых «вещи»:
* Multicatching. Это когда в одном catch-блоке сразу обрабатывается несколько исключений:
try {
} catch (Exception1|Exception2|Exception3|… | ExceptionN ex) {}
В таком случае параметр ex будет неявно иметь модификатор final. Кроме того, байт-код, сгенерированный компиляцией такого кода (с единым catch-блоком) будет короче, чем байт-код, сгенерированный компиляцией кода с несколькими catch-блоками.

* Try-with-resources. Эта контрукция позволяет после слова try в скобках указать открываемые ресурсы, которые сами закроются после окончания конструкции try () {} catch{}. В качестве ресурса в данной конструкции может быть использован любой объект, реализующий интерфейс AutoCloseable.
Во время закрытия ресурсов тоже может быть брошено исключение. В try-with-resources добавлена возможность хранения «подавленных» исключений, и брошенное try-блоком исключение имеет больший приоритет, чем исключения, получившиеся во время закрытия. Получить последние можно вызовом метода getSuppressed() от исключения, брошенного try-блоком.

* Rethrowing. Перебрасывание исключений с улучшенной проверкой соответствия типов.
Компилятор Java SE 7 тщательнее анализирует перебрасываемые исключения. Рассмотрим следующий пример:

static class FirstException extends Exception { }
static class SecondException extends Exception { }
public void rethrowException(String exceptionName) throws Exception {
try {
if («First».equals(exceptionName)) {
throw new FirstException();
} else {
throw new SecondException();
}
} catch (Exception ex) {
throw e;
}
}

В примере try-блок может бросить либо FirstException, либо SecondException. В версиях до Java SE 7 невозможно указать эти исключения в декларации метода, потому что catch-блок перебрасывает исключение ex, тип которого — Exception.

В Java SE 7 вы можете указать, что метод rethrowException бросает только FirstException и SecondException. Компилятор определит, что исключение Exception ex могло возникнуть только в try-блоке, в котором может быть брошено FirstException или SecondException. Даже если тип параметра catch — Exception, компилятор определит, что это экземпляр либо FirstException, либо SecondException:

public void rethrowException(String exceptionName) throws FirstException, SecondException {
try {
//…
} catch (Exception e) {
throw e;
}
}

Если FirstException и SecondException не являются наследниками Exception, то необходимо указать и Exception в объявлении метода.

10. Аннотации используются для размещения рядом с классом, полем, методом или переменой какой-то дополнительной, служебной информации (метаданных), относящейся к ней. Чтобы указать аннотацию, надо над заголовком класса или метода, либо надо объявлением поля или переменной, написать после @ название аннотации (класса аннотации), например так:

@Override
public void doSomeThing() {
}


Кроме того, у аннотации могут быть свойства, они указывают в скобках через запятую в виде пар «ключ=значение», где в качестве ключа выступает название свойства, а качестве значения — собственно, значение, которое должно принять это свойство. Выглядит это так:
@CatInfo(manager=Catmanager.class, unique=true)
class Cat {}
Если указывается указывает значение только для одного свойства, то имя свойства и знак равно можно не писать: @SuppressWarnings(«unchecked).
Также можно вообще не ставить скобки, если никаким свойствам не присваиваются никакие значения.
Чтобы создать свою аннотацию, надо указать модификатор доступа, потом после пробела ключевое слово „@interface“ и дальше опять после пробела имя аннотации (принять начинать его с большой буква). Дальше идёт тело аннотации в фигурных скобках. Внутри тела указываются свойства в виде объявлений методов (как в интерфейсах). Также у свойств можно указать значения по умолчанию (они их будут принимать, если при указании аннотации в нужном месте, этому свойству не будет присвоено какое-то значение). Всё вместе это выглядит так:
@interface CatManager
{
Class manager();
boolean unique();
String name() default „Unknown Cat“;
}

Аннотации выполняют следующие функции:
а) дают необходимую информацию для компилятора;
б) дают информацию различным инструментам для генерации другого кода, конфигураций и т. д.;
в) могут использоваться во время работы кода;
е) повышают читабельность кода и его понимание программистами.
На данный момент компилятором используют три аннотации: @Deprecated, @Override и @SuppressWarnings. Первой аннотацией помечаются устаревшие методы и классы, нерекомендованные к использованию (комплятор по их поводу показывает предупреждение). Вторая аннтоцая ставится над переопределёнными методами класса-наследника (это позволяет контролировать связь между исходным методом и переопределённым). Третья аннотация позволяет подавлять (не выводить) некоторые исключительные предупреждения, обычно выводимые компилятором в связи с данным методом или классом (например, что он уже устарел и нерекомендован к использованию).