«Не надто пишайтеся цими технічними досягненнями, які ви збудували. Здатність знищити планету – ніщо в порівнянні з могутністю Сабо», – Дарт Вейдер про Зірку Смерті.
The Linux Command Line by William Shotts. Читайте цю книжку не як роман «50 відтінків сірого», а як повноцінний інтерактивний курс – відкривайте термінал та повторюйте за автором. Хочеться основ та як влаштований Linux? Не братимемо Computer Science і курс операційних систем - це в наступній частині. Зайдіть на edx.org і спробуйте пройти нескладний курс Introduction to Linux . Є ще книга з вищезгаданої серії How Linux Works: What Every Досить ілюстроване видання, приділяється увага і networking і девайсам, resource management.
Йдемо далі? Є чудова книга, яка, до речі у мене десь тут ... ага (струшує пил) ... ось вона! Unix та Linux: керівництво системного адміністратора. Еві Немет.
Досить велике керівництво, непогано перекладене. Чесно зізнаюся, я особисто не подужав, але основи адміністрування (перша частина) мені дуже сподобалися. Природно, не можна пройти повз Shell scripting. Краще спробувати це все на практиці, ну, а з книжок можна переглянути Learning the bash Shell.
Така величезна кількість літератури з Linux/Unix неможливо охопити в повному обсязі, та ще й у цій статті, де Linux знаходиться на другому плані. Мій колега по роботі, який собаку з'їв на цій справі, порадив досить практичну річ: Скачай ArchLinux і спробуй його підняти. У процесі навчишся саме не хочу!
Наприклад, якщо ви використовуєте PowerShell, зверніть увагу на чудову книгу Windows PowerShell in Action Manning by Bruce Payette . Я розумію, що 1000 сторінок пройти нереально, але її як мінімум можна тримати при собі як довідник. Нічого іншого не потрібне, я вважаю.
Як підсумок — зверніть увагу на прогалини у своїх знаннях щодо використання Windows і пошукайте цікаву для вас інформацію в інтернеті.
Для підвищення рівня підійде створення свого плагіна. Не замислюйтесь про те, який саме плагін потрібно створити, адже багато вже є! Спробуйте створити якийсь аналог, вивчіть фази як двічі по два.
У цій книзі навіть розглядається створення власної CI системи. Давайте зупинимося на двох найпопулярніших рішеннях у цій галузі.
Якщо ви так звикли до ракушки (TortoiseSVN, прим. автора), і боїтеся консолі, ви, звичайно, можете завантажити його аналог TortoiseGit, але, на мій погляд, куди більш приємним і естетичним рішенням є продукт від Atlassian - SourceTreeApp. Можна потренуватися з remote репозиторіями, благо хост-сервісів в інтернеті достатньо. Якщо хочете, потренуйтеся локально. Ні? Тоді створіть обліковий запис на GitHub і попрацюйте у повноцінному режимі: зробіть пару коммітів, fork'ніте якийсь opensource проект, зроби пару merge між бранчами і так далі.
Мені вона сподобалася тим, що тут приділяється увага адмініструванню самого сервера SVN. Сподіваюся, я не пропустив основні моменти.
Звичайно, тут не тільки JUnit і Mockito. Тут автор знайомить і з Matcher'ами, і пропонує приклади parameterized тестів, і поверхово проходить по TDD. Є також книга, яка вийшла зовсім нещодавно. Це Pragmatic Unit Testing in Java 8 by Jeff Langr
Автор знайомить із Hamcrest, описує Best Practices, ну і, звичайно, Java 8. Можна сміливо читати після книги Tomek'a. До речі, щодо TDD. Я не хочу піднімати холівар з приводу того, чи варто їх використовувати, чи це погано, чи добре, чи потрібні вони замовникам. Просто запам'ятайте: працювати за TDD — не дивина, і в багатьох проектах така методологія використовується, і для багатьох це єдине і незаперечне правило. За теорією можна прочитати класику. Kent Beck - Test Driven Development: By Example . Найбільше мені сподобалася частина про патерни TDD.
Як не дивно, є хороший курс від першої особи – Let's Play TDD (200 відео!) на Youtube. Не менш цікавою є дискусія самого Фаулера— варто чи не варто застосовувати TDD, чи псує він дизайн тощо. Запам'ятаєте просто раз і назавжди: TDD не створює поганий дизайн, його створюєте особисто ви. Якщо ви більше використовуєте BDD (одно іншому не заважає) і, наприклад, використовуєте Cucumber на проекті, це трохи інша площина. Хороша книжка з цього приводу — Manning BDD in Action: Behavior-driven development for the whole software lifecycle by John Ferguson Smart .
До речі, John Ferguson Smart активно просуває цю тему у маси. Якщо ви - скрам майстер або ПМ, якому нарешті не ріже очі, а любо-дорого дивитися на when-if-then тести, тоді обов'язково підпишіться на твіттер Джона . Щодо Cucumber — перегляньте Java імплементацію на офіційному сайтіта ознайомтесь з книгою The Cucumber Book: Behaviour-Driven Development by Matt Wayne .
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 1](https://cdn.javarush.com/images/article/d7b1e03f-8c71-4458-9df7-3c9cc129d60d/800.jpeg)
Intro
Напевно, наступні дві частини з циклу статей для багатьох найочікуваніші, і недарма. Що ж там, за горизонтом, за чистою Java? Чим дихають Java девелопери у кожному проекті? Вважайте це справжнім повноцінним посібником для самонавчання будь-якого back-end engineer'а середньої руки, для якого основна мова програмування - саме Java. Я маю намір охопити максимально середнє значення по лікарні та описати не лише найбільш популярні фреймворки, а й рішення, які вважаються актуальними на даний момент. Природно, інструментів дуже багато, і зрозуміти, які є найважливіші та найкращі – це шлях у нікуди. Кожен із вас розглядав розділ «Робота»на DOU і знаходив стек технологій, які постійно повторюються від вакансії до вакансії. Розумію, описати все неможливо, але придумати загальні рамки — цілком, тому спробуємо дотримуватися цього напряму. Якось у минулому, на одному з проектів стався досить цікавий конфуз, який, я думаю, повторювався і повторюється постійно у багатьох у тій чи іншій галузі. Було поставлене завдання — до готового функціонала прикріпити рендер однієї HTML-сторінки просто для того, щоби показувати статус окремих сутностей. У результаті мій колега вирішив прикріпити spring thymeleaf, який тягнув за собою частину core залежностей самого Spring, коли при цьому спринг ніхто не використовував. І це все для однієї звичайної сторінки, яка просто показує статус 2-3 сутностей. «Ніколи не бачив особливого сенсу використовувати два світлові мечі ... на мій погляд, це випендреж»- Обі-Ван Кенобі. З одного боку, розробник вирішив завдання максимально швидко, прикрутив фреймворк, з яким мав досвід користування та інтегрував його в проект за лічені години. Але з іншого боку, наша програма зросла в розмірах, тому постає просте запитання: чи правильно він вчинив? Для таких атомарних завдань, коли ти точно знаєш, що більше цей thymeleaf/ Spring MVC і т.п. ніде використовуватись не буде, краще взагалі не використовувати. Мене завжди дивують фрази на кшталт «О! Та ми тут заюзали Hibernate! Подивися, все круто, ORM!», а на закономірне запитання, чи можна тут обійтися звичайним JDBC, вони знизують плечима. Є звичайна архітектура, яка має бути проста, до якої слід ставитися з трепетом, не захаращувати її модними та суперсучасними фреймворками. Як сказав вище Обі-Ван, це не більше ніж випендреж, хоча вміти користуватися ними потрібно. Молодому джавісту, на мій погляд, не пощастило найбільше — стільки специфікацій, стільки бібліотек, які треба вивчати. Одна тільки Java EE включає документації вище даху. Виникає питання, за що братися новачкові, що вчити далі, що робити після Хорстмана? Проста відповідь: на жаль, знайомитись з багатьма. І ми почнемо не з бізнес-фреймворків, а з більш приземлених необхідних речей.Operating Systems
Linux
Крім вінди або затишного Yosemite необхідно з посмішкою простягнути свої руки до Linux. Для одних проектів досить бути користувачем, вміти поводитися з командним рядком, для інших — значно більше. Який спосіб найкраще? В інтернеті книг/туторіалів просто темрява. Почніть з установки Ubuntu або будь-якого іншого симпатичного вам дистрибутива і спробуйте використовувати його як основну операційну систему найближчий місяць-два. Буде набагато краще, якщо ви почнете навчати Java всередині Linux, компілюючи та маніпулюючи файлуми за допомогою терміналу.![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 2](https://cdn.javarush.com/images/article/35116f24-bf16-4ba7-8a6c-747c04c5a0e6/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 3](https://cdn.javarush.com/images/article/a82885cc-9c47-4f92-b24c-2b72ff21c101/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 4](https://cdn.javarush.com/images/article/93507150-934d-4c8d-9444-1bd2a56daa64/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 5](https://cdn.javarush.com/images/article/19d91ffe-0c93-4067-8e0c-b1f5fb109ca3/256.jpeg)
Windows
У резюме програмістів зустрічається графа: «досвід Windows понад 10 років». Я вас, звичайно, вітаю, що ви в контру шпаболи з 10 років на вінді, але попрошу завчасно не вирити собі яму на співбесіді, тому що на проекті, де йде тісна робота з IIS, batch/powershell, не дай Боже, реєстром, співбесіда виявиться не реально важким, і крім усмішки навпроти того, хто сидить тих. Ліда ви отримаєте ще й дозу приниження. Це вам потрібно? Відповідь напрошується сама собою. Відкладіть піратську вінду з торрента і спробуйте встановити на якусь віртуалку Windows Server. Вивчіть її не тільки з боку користувача та установки JAVA_HOME. У цьому плані практично повноцінне керівництво існує у вигляді книги Mastering Windows Server 2012 R2 by Mark Minasi .![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 6](https://cdn.javarush.com/images/article/a5820f30-dab2-4797-a996-c89bb371f2de/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 7](https://cdn.javarush.com/images/article/7006be31-3d3e-4603-8add-29bd3176d639/256.jpeg)
Build Tools
Maven
Що головне потрібно зрозуміти у Maven? Ось перші кроки та завдання:- Вивчіть, що Maven робить у кожній фазі, можна навіть зазубрити. Це майже 80% успіху і дасть вам наочну картинку.
- Створіть локально свої sandbox проекти з мультимодульною системою, з явним dependency management. Спробуйте прикрутити сторонні бібліотеки, спробуйте створити щось, використовуючи їх.
- Грати з profile
- Розберіться з plugin management та вивчіть список найпопулярніших плагінів на офіційному сайті.
- Дослідіть, як краще використовувати maven вам у вашому проекті. Наприклад, parallel builds може значно скоротити час складання.
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 8](https://cdn.javarush.com/images/article/8aed98e6-b239-405a-9505-a5fead47963a/256.jpeg)
ANT
Даний інструмент виглядає набагато легше, тому і вчити тут особливо нічого. До цих пір існує проекти, в яких інструментом збирання є тільки ANT. Це абсолютно нормально: ANT зарекомендував себе як простий та зрозумілий інструмент складання в контексті управління маленькими атомарними тасками (ant tasks). Звичайно ж, тут є багато плагінів, як і у Maven. Як знайомство з ANT виконайте таке:- Спробуйте маніпулювати файлуми та папками
- Реалізуйте різний порядок виконання тасків. На основі цього вивчіть залежності та пріоритет завдань у ANT.
- Розпакуйте та/або запакуйте zip архів. У тасках спробуйте погратись із вмістом архіву тощо.
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 9](https://cdn.javarush.com/images/article/86960724-30f3-48cd-8b1b-ef0314f88649/256.jpeg)
Gradle
Для мене Gradle ближче до ANT, ніж Maven, але його повноцінно можна назвати зведеним братом цих двох хлопців. У нього присутній і lifecycle, схожий на Maven, і гнучкість тих же тяг, які є у ANT. Ну, а найголовніше — Gradle не використовує XML і, більше того, з ним можна робити все, що забажаєш, якщо більш-менш знайомий з Groovy. Загалом досить смачна штука. Не бійтеся використовувати Ant/Maven/Gradle у контексті вашої IDE. Ці інструменти тісно інтегровані в Eclipse/IDEA і використовувати ці тулзи в контексті IDE досить комфортно.Continious Integration
Theory
Це програми-ангели, які бережуть вас від звільнення. Якщо коротко, це софт, який стежить за змінами коду, білдить і ганяє написані вам тести. Якщо все добре після кожного комміту/мержа, то білд світиться приємним зеленим/синім світлом. Як тільки ви щось зламаєте, CI система одразу повідомить про це. Втім, трохи теорії – це до класики! Continuous Integration: Improving Software Quality and Reducing Risk до Paul Duvall . (Вона ж - «Безперервна Інтеграція» російською)![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 10](https://cdn.javarush.com/images/article/877e6e74-0123-40a9-8637-319546764d75/256.jpeg)
Jenkins
Jenkins, він же Hudson. Відкрита, доброзичлива, проста у використанні аплікуха. Щоб ближче познайомитися з Jenkins, спробуйте зробити таке:- Завантажте його собі на комп'ютер. Встановіть та налаштуйте JDK, Maven, ANT та все, що вам потрібно для проекту.
- Створіть перший Job і вкажіть розташування вашого проекту, наприклад, головного pom.xml. Запустіть, переконайтеся, що у вас є якийсь тест, щоб було видно.
- Навчіться запускати ваш проект з різними налаштуваннями та опціями.
- Прикрутіть різні плагіни, подивіться, як вони працюють у зв'язку з вашим проектом.
- Сформулюйте тригери різних job'ів. Створити невеликий pipeline.
- Вивчіть DSL і спробуйте інтегрувати його в Jenkins.
- Налаштуйте slave з іншого комп'ютера та/або зробіть його регулярною тачкою для прогону білдів.
- Створіть nightly білди.
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 11](https://cdn.javarush.com/images/article/4137bb44-1e49-4adb-98f9-3a47b3db4057/256.jpeg)
TeamCity
Так, TeamCity не безкоштовний, але ви подивіться, до чого чудово він інтегрований в екосистему продуктів JetBrains. Intellij Idea та TeamCity – чудовий союз. За великим рахунком, якщо ви вже знайомі з Jenkins, TeamCity не стане для вас чорним лісом, і навпаки. Замість slave - agents, ті ж тригери і так далі. Але на відміну від Jenkins, TeamCity може похвалитися такими приголомшливими фічами як, наприклад, remote run, він же pre-tested commit, куди наочніша статистика і ще багато всього. Мені дуже подобається user guide на youtube, який зробила сама JetBrains (Part 1 of 9) — Introduction). Я вважаю, що TeamCity є інтуїтивно простий, і документація на високому рівні. Але якщо ви вважаєте, що є якась цікава книга, будь ласка, залиште це в коментарях. Звичайно, я перерахував лише малу частину цих CI систем, але у нас обмежено за обсягом. Напевно, найкращим керівництвом для вивчення буде лише практика. Встановив собі на комп'ютер, позапускав, повалив/відновив білди і ліг спати. І потім можна сміливо нести мені заліковку (якщо хочете:).Version Control System
Багато говорити про VCS не варто. Це просто те, що має бути, і без чого управління проектом було схоже на мезозойську еру. Подібно до CI систем, давайте розглянемо два найпопулярніші рішення: Git і SVN.Git
Наш Git зарекомендував себе як стабільну розподілену систему управління версіями. Почніть вивчення звідси і пройдіть усі розділи з налаштованим Git'ом у себе. Потім є чудова серія інтерактивних туторіалів від Code School. Також є від них короткий посібник Try Git: Code School . З книг можу порекомендувати Version Control with Git by Jon Loeliger![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 12](https://cdn.javarush.com/images/article/76829290-9df3-4a4e-bb60-d452c70761e8/256.jpeg)
SVN
Інша не менш популярна VCS – це SVN. Ця система неспроможна похвалитися розподіленістю. У кожної з них свої підходи, свої плюси та мінуси. Прочитайте обов'язково цікаву розмову новачка та користувача SVN . Є безкоштовна книга від read-bean.com із російським перекладом. Також буде вкрай корисний міні-курс від TutorialsPoint . Не проходьте повз офіційний Apache сайт subversion.apache.org . Найцікавішим клієнтом для мене є згаданий TortoiseSVN. З книжок можна назвати одну: Version Control with Subversion by Michael Pilato .![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 13](https://cdn.javarush.com/images/article/c9466ee5-c523-4e9f-8324-50a11650f362/256.jpeg)
Testing tools
Непогано було б розібратися на своїх маленьких sandbox проектах, що таке юніт-тести, інтеграційне та регресійне тестування. JUnit Теорія юніт-тестів добре описана у книгах із попередньої статті. Зокрема, Clean Code навіть описує junit як одну з популярних бібліотек у цій галузі. Але якщо торкатися конкретно JUnit, є чудова маленька книга Practice Unit Testing with JUnit and Mockito by Tomek Kaszanowski![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 14](https://cdn.javarush.com/images/article/77ed1492-aa29-4847-be06-f37c36b3439d/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 15](https://cdn.javarush.com/images/article/8c881985-1c4d-4bec-a767-6cfaaa7edf72/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 16](https://cdn.javarush.com/images/article/e6072b2d-26c5-41cf-b50c-a3d27075b10a/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 17](https://cdn.javarush.com/images/article/78963359-7ba5-4240-a7ad-2a229234a6fd/256.jpeg)
![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 18](https://cdn.javarush.com/images/article/6f8e542f-6832-48e3-97e3-f2ff67a32c18/256.jpeg)
3rd party libraries
Важливо вміти використовувати популярні бібліотеки, де це необхідно - вони полегшують повсякденне життя кожного Java розробника. З популярних рішень можна назвати такі: Joda Time. Пропонує повністю замінити незручні рідні Date та Time зручнішими JodaTime. Ось один хороший референс . Зверніть увагу, що якщо ви вже використовуєте Java 8, JodaTime мало чим допоможе. Справа в тому, що новий DateTime API повністю витіснив цю бібліотеку, і подекуди навіть хитро скопіпастил. Відповідно до статті самого автора , кожен клас Joda може бути зручно замінений на аналогію з java.time. Google Guava.Багато в чому Java 8 витісняє навіть Guava. Той же Objects, Stream API, Java Predicate і багато всього пропонує замінити і взагалі її не використовувати. Повторюся, якщо у вас не Java 8 - краще за цього гіда і своїх прямих рук нічого немає.Apache Commons
З цим монстром не так просто розтанути: близько 40 бібліотек на всі випадки життя, від усіх відомого commons.lang до валідації xml, від DBUtils до commons.io . Звісно, знайомитися з усім не потрібно, але Cookbook книги та туторіали буде корисно мати при собі. Наприклад, щоб зрозуміти, що собою представляє взагалі Apache Commons, можна погортати Jakarta Commons Cookbook by Timothy O'Brein![Посібник для майбутнього Java розробника. Enterprise - частина 1 - 19](https://cdn.javarush.com/images/article/038c1ca8-7d58-4388-8b4d-c8b6d2fc2c30/256.jpeg)
Висновок
Enterprise настільки неосяжний, що починати обговорювати відразу JavaEE та інші фреймворки було б безглуздо без усього, що цей Enterprise оточує. Тому у другій частині ми будемо фокусуватися на кожному шарі з multitier архітектури, розглянемо services тощо. Дуже дякую за увагу. Кінець першої частини. Попередні частини циклу:- Посібник для майбутнього Java розробника. Основи Java
- Посібник для майбутнього Java розробника. Елегантний код
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ