Когда-то давно я мечтал стать программистом. Еще со средних класов школы начал ездить на олимпиады по программированию, писал игровые моды и просто нереально кайфовал от того, что делал. Начинал еще с Turbo Pascal, потом С, потом скриптовые языки, в универе математическое моделирование на С++ и matlab. Только в универе пришлось на теор.физике тусоваться, ибо не прошел по балах на программирование, но да ладно. Спустя 3 года я все таки решил кинуть физику, так как просто не видел денег в этой сфере в своей стране, и получил все таки первую долгожданном ИТ. Это была серверная разработка на Python.
С тех пор прошло уже 6 лет. Не могу сказать, что я сверх нерд и мое мнение авторитетное - но какой-то опыт в своей сфере все таки имею. Повидать успел с десяток различных компаний - от крупнейших в СНГ и крупных на диком западе, до мелких стартапов ( не думайте, что я во всех них успел поработать - это тема отдельная). Это печально...
Я решил поделиться своим видением на параметризованные юнит-тесты, как делаем это мы, и как возможно не делаете (но захотите делать) вы.
Хочется написать красивую фразу, о том что тестировать надо правильно, и тесты это важно, но до меня сказано и написано уже много материала, я лишь попробую резюмировать и осветить то, что по моему мнению людьми редко используется(понимается), на что в основном задвигается.
Моему другу почти 32 и он программист (java-разработчик, если хотите). Раньше я любил читать «мотивашки», о том как люди приходят в IT, я читал их пачками, и каждая следующая, хоть и была похожа на предыдущую, давала свежий глоток позитива и оптимизма, веры в светлое будущее и чудеса. История моего друга возможно тоже могла бы послужить «мотивашкой» для кого-то, и раз есть хотя бы небольшой шанс на это — ее нужно рассказать.
Описанная ниже задача не была новаторской или чертовски полезной, компания в которой я работаю не получит за нее прибыль, а я премию.
Но эта задача была, а значит ее пришлось решить.
Intro
В статье вы часто будете встречать слово Lombok, прошу хейтеров не торопиться с выводами.
Я не собираюсь «топить» за Lombok или его отсутствие, я как Геральт Сапковского, стараюсь хранить нейтралитет, и могу спокойно и без дрожи в веке читать код как с Lombok, так и без оного.
Но на текущем проекте упомянутая библиотека присутствует, и что-то подсказывает мне, что наш проект такой не единственный.
Так вот.
Пример 1. Занимательный говнокодкод. Занимает уйму времени, на то чтоб понять что происходит. Характерной особенностью воплощения обозначенной теории в коде является довольно лютая свалка, которая местами дико напоминает процедурный код. О том что этот вариант кода лучше не трогать на проекте знает каждый технолог, методолог и продуктолог. Заходят в этот код что-то поправить в случае крайней нужды(когда совсем сломалось), о доработке каких либо фичей речи не идет. Ибо сломать страшно. Второй яркой особенностью, обосабливающий данный тип является наличие могучих таких switch, на весь экран.
На этот счет даже есть шутеечка:
Напишем небольшое веб приложение, без использование Web-фреймворков, внешних библиотек, и сервера приложений.
Цель данной статьи показать общую суть происходящего под капотом веб-сервиса, на примере Java. Итак, поехали. Мы не должны использовать сторонние библиотеки, а также сервлет. Поэтому проект соберем Maven-ом, но без зависимостей.
Что происходит когда пользователь вводит некий ip-адрес(ну или dns который превращается в ip-адрес) в адресной строке браузера? Происходит запрос к ServerSocket указанного host-a, на указанный порт.
Организуем на нашем localhost, socket на случайном свободном порту(например 9001).
