Если ты напишешь int main и пойдешь там создавать сокеты, то потом твоих объяснений что «так нужно было для задачи», «здесь и этого хватит» никто слушать не будет. Есть общепринятые стандартные практики, изволь действовать в рамках этих практик. Кто так не делает — тот лох, код — в мусорку. Если вся компания пишет на Spring Boot, то даже если у тебя консольный хэлловорлд, изволь оформить его в виде консольного приложения Spring Boot.
В этом кардинальное отличие джава-комьюнити от какого-нибудь C/C++ комьюнити. Это вот им можно рассказывать что «не серверами приложений едиными» и «бывает же разное». Почти никогда не бывает.
Хотя может быть, я просто вращался в соответствующих кругах, и где-то в других кругах — говнокодят. Их даже немного жаль :)
Лично для меня очень актуален вопрос совмещения написания статей с разработкой кода и участием в бизнесовых активностях. Очень. Мне было важно услышать ответ человека, который с блеском решил эту проблему.
Это как с паттернами организации кода или архитектурами ынтерпрайзной интеграции — пока тебя это не касатеся напрямую, ты ни книг не читаешь, ни докладов не слушаешь, на всё отвечая «да можно хоть так, хоть по-другому, как больше нравится, или как от задачи зависит». Но как только тебе реально нужно что-то закодировать, или прописать архитектурку в договоре — вот тут попа и начинает возгораться.
Даже если ответ Рихтера и является клише (то есть, применением типового паттерна к типовой сиутации), уже само понимание «в такой ситуации — вот этот паттерн» уже ценная информация.
В частности, раньше я решал все подобные вопросы с помощью kanban-подобной методологии. Но по отзывам нескольких успешных блоггеров вижу, что на самом деле это решается исключительно маниакальной дисциплиной и жестоким планированием.
Я попытался как-то разбавить простыню текста картиночками и подобием структуры. Не факт, что это получилось. Если есть идеи, что можно улучшить в плане подачи материала — обязательно напишите.
Сейчас в ынтерпрайз джаве очень просто. Или у тебя или Spring, или JEE, и еще несколько «легких» фреймворков на сдачу. Несмотря на то, что в обеих технологиях понапихано всякой всячины, принято исповедовать вполне конкретные философии. Так же как у эскимосов есть 50+ названий для цвета снега, у джавистов очень важно различать тонкие градации использования сервисов, бинов и так далее. Можно ли из сервиса звать сервис, и если нет — как устроена такая архитектура? Вот достойный вопрос для обсуждения. Сам факт того, что сервисы писать нужно, и во вполне определенной сервисной архитектуре — никто не обсуждает, это стандарт.
А ещё ты обязан знать паттерны проектирования, ооп, enterprise integration patterns, паттерны использования конкретной вещи типа Hazelcast. Стандартизация. Стандартные практики, стандартные философии, стандартные паттерны. Всё очень жестко задано и определяется в том числе модой и популярностью конкретных подходов.
Но если ты наговнякаешь код одним куском внутри сервлета — тебя будут за лоха считать все. Ну то есть, вообще все.
В C++ этого нет, там люди «пишут, исходя из задачи», и вот это всё. Многие ооп-то не используют, так в процедурном стиле и пишут, «си с классами». С «модными» архитектурами вообще беда. Проверено неоднократным общением с C++-разработчиками.
Если вместо того, чтобы поднять в докере аппликейшен-сервер и собрать под него war-ник специальными мегафреймворками, ты пойдешь и зафигачишь экзешник с int main, куда кривыми своими руками попытаешься закодить хттп-сервер — в C++ никто тебе, скорей всего, слова не скажет. Все так делают.
Наниматель дал задание рекрутерам найти побольше админов. Концепция DevOps слишком сложная, чтобы понять её за пару минут неквалифицированным рекрутером. Но рекрутер знает, что если назовет вакансию «DevOps» (даже если она не совсем понимает, что это вообще значит, даже если это неправда), то это может выполнить план по набору админов. Причем админов с высоко актуальными кейвордами в резюме (всякие CI/CD, скриптовые языки, итп).
> стоит сначала чего-то добиться, чтобы чему-то остальных учить
2 монаха шагали по дороге. Оба были довольно голодны. Вдруг один из них заметил лежащую у дороги палку.
— Давай сьедим эту палку! — предложил он.
— Она не сьедобна нихрена! — возразил второй монах.
— Откуда ты знаешь не попробовав? — спросил монах и укусил палку. Все передние зубы монаха сломались.
— Нефиг всё пробовать, чтобы знать! — сказал второй монах и ударил первого ногой в паховую область.
Есть идея, что вся жизнь человека обсуловлена необходимостью. Так устроены мозги.
Другое дело, какого рода это необходимость.
Например, я работаю в отделе маркетинга. Но вечерами изучаю виртуальные машины и компиляторы, пишу подкасты, и так далее.
Это необходимо, потому что в будущем я выжу себя крутым евангелистом, и что я за евангелист без коммитов в Java-компилятор? Необходимо прямо сейчас заниматься огромной кучей вещей вроде постоянного мониторинга сообщества.
Имхо, правильный разработчик — это тот, кто видит будущее, и знает, что нужно сделать прямо сейчас, чтобы это будущее наступило.
Вещи вроде «узнавать, чем живет сообщество» для меня лично — это необходимость, то самое средство сделать, чтобы наступило именно то будущее, которе я вижу.
Или можно взять другой аспект. Необходимость в самовыражении. Это реальная необходимость, потому что иначе — зачем жить? Если незачем жить, то почему бы не гуфнуться прямо сейчас?
Паша, как вы смогли целых пять лет с 2008 года по 2011 держать Котлин в тайне? Никогда не хотелось кому-нибудь рассказать? Максу Шафирову хотя бы? Что-то вроде: «АААА я пишу Котлин!!! Суть такова...».
Грамотный маркетолог может что угодно превратить во что угодно. И что? :)
Что, по вашему, должен делать докладчик — сидеть дома, ничего не говорить публично и прятаться от людей только по той причине, чтобы некий «грамотный маркетолог» не превратил это в рекламу?
Кстати, я конечно разработчик, но сейчас я работаю в отделе маркетинга. Не боитесь меня? Страшный человек же. :-)
Насколько знаю, JUG.ru Group принципиально не берет никакие рекламные доклады. Этот доклад хотела аудитория — она его и получила.
Кроме того, как уже сказал Женя, непонятно, чего кому тут продавать. Разве что, продавать идею о светлом будущем профессии тестировщика. Но с каких пор это стало чем-то плохим?
JS — очень хороший язык для сайтиков с объемом не больше 10 тысяч строк кода
JS — очень плохой язык для больших настоящих проектов.
Основной вопрос в том, что в больших проектах код в основном не пишут, а читают. Оптимизация по скорости написания не очень важна. Оптимизация по скорости чтения с использованием IDE, возможность автоматического анализа хоть чего-то, возможность стабильных недеструктивных рефакторингов — это самые важные приоритеты
Навскидку, десять тысяч строк кода для JS уже могут показаться сложными, требующими десятков джаваскриптеров (и тут вступает на сцену «мифический человеко-месяц», и утаскивает в пучину ада). Проект на сто тысяч строк кажется джаваскриптеру чем-то невероятно непредставимо сложным. Проект на десятки миллионов строк кода в JS существовать не может вообще
Большие проекты без IDE ты и не попишешь, вообще. Если IDE нет для языка, его просто не используют.
V8 — куда слабей как виртуальная машина, особенно в части сборки мусора (нет возможности работать с дейтсвительно большими объемами данных, или действительно маленькими объемами оперативной памяти)
Написать не просто серверный движок, а целый сервис вместе с бизнес-логикой? Ну это вряд ли. На то и ниши разные, решать прикладные задачи на растения, ровно как и на C/C++ — упаси
Зачем на системных языках быстро нафигаривать веб-сервер?) Берешь котлин, фигаришь. А на системном языке решаешь системные задачи. Тот же веб-сервер, но маниакально перфомансно, очень долго, очень дорого и невероятно офигенно. А потом оборачиваешь в нативную обёртку и зовёшь его из Котлина, чтобы получить лучшее из двух миров одновременно
В этом кардинальное отличие джава-комьюнити от какого-нибудь C/C++ комьюнити. Это вот им можно рассказывать что «не серверами приложений едиными» и «бывает же разное». Почти никогда не бывает.
Хотя может быть, я просто вращался в соответствующих кругах, и где-то в других кругах — говнокодят. Их даже немного жаль :)
Это как с паттернами организации кода или архитектурами ынтерпрайзной интеграции — пока тебя это не касатеся напрямую, ты ни книг не читаешь, ни докладов не слушаешь, на всё отвечая «да можно хоть так, хоть по-другому, как больше нравится, или как от задачи зависит». Но как только тебе реально нужно что-то закодировать, или прописать архитектурку в договоре — вот тут попа и начинает возгораться.
Даже если ответ Рихтера и является клише (то есть, применением типового паттерна к типовой сиутации), уже само понимание «в такой ситуации — вот этот паттерн» уже ценная информация.
В частности, раньше я решал все подобные вопросы с помощью kanban-подобной методологии. Но по отзывам нескольких успешных блоггеров вижу, что на самом деле это решается исключительно маниакальной дисциплиной и жестоким планированием.
А ещё ты обязан знать паттерны проектирования, ооп, enterprise integration patterns, паттерны использования конкретной вещи типа Hazelcast. Стандартизация. Стандартные практики, стандартные философии, стандартные паттерны. Всё очень жестко задано и определяется в том числе модой и популярностью конкретных подходов.
Но если ты наговнякаешь код одним куском внутри сервлета — тебя будут за лоха считать все. Ну то есть, вообще все.
В C++ этого нет, там люди «пишут, исходя из задачи», и вот это всё. Многие ооп-то не используют, так в процедурном стиле и пишут, «си с классами». С «модными» архитектурами вообще беда. Проверено неоднократным общением с C++-разработчиками.
Если вместо того, чтобы поднять в докере аппликейшен-сервер и собрать под него war-ник специальными мегафреймворками, ты пойдешь и зафигачишь экзешник с int main, куда кривыми своими руками попытаешься закодить хттп-сервер — в C++ никто тебе, скорей всего, слова не скажет. Все так делают.
2 монаха шагали по дороге. Оба были довольно голодны. Вдруг один из них заметил лежащую у дороги палку.
— Давай сьедим эту палку! — предложил он.
— Она не сьедобна нихрена! — возразил второй монах.
— Откуда ты знаешь не попробовав? — спросил монах и укусил палку. Все передние зубы монаха сломались.
— Нефиг всё пробовать, чтобы знать! — сказал второй монах и ударил первого ногой в паховую область.
© Дао-Какао
Воу, воу, аргументация вида «сперва добейся», серьезно?
Поведай же, какие в C++ стандарты на написание архитектуры ынтерпрайз приложений. Запасся чипсами!
> Стоит таких «узкоспециализированных» специалистов
Поискал по слову «узкоспециализированных», нашел только твой комментарий. Плохо ли я искал?
Другое дело, какого рода это необходимость.
Например, я работаю в отделе маркетинга. Но вечерами изучаю виртуальные машины и компиляторы, пишу подкасты, и так далее.
Это необходимо, потому что в будущем я выжу себя крутым евангелистом, и что я за евангелист без коммитов в Java-компилятор? Необходимо прямо сейчас заниматься огромной кучей вещей вроде постоянного мониторинга сообщества.
Имхо, правильный разработчик — это тот, кто видит будущее, и знает, что нужно сделать прямо сейчас, чтобы это будущее наступило.
Вещи вроде «узнавать, чем живет сообщество» для меня лично — это необходимость, то самое средство сделать, чтобы наступило именно то будущее, которе я вижу.
Или можно взять другой аспект. Необходимость в самовыражении. Это реальная необходимость, потому что иначе — зачем жить? Если незачем жить, то почему бы не гуфнуться прямо сейчас?
Что, по вашему, должен делать докладчик — сидеть дома, ничего не говорить публично и прятаться от людей только по той причине, чтобы некий «грамотный маркетолог» не превратил это в рекламу?
Кстати, я конечно разработчик, но сейчас я работаю в отделе маркетинга. Не боитесь меня? Страшный человек же. :-)
Кроме того, как уже сказал Женя, непонятно, чего кому тут продавать. Разве что, продавать идею о светлом будущем профессии тестировщика. Но с каких пор это стало чем-то плохим?
JS — очень хороший язык для сайтиков с объемом не больше 10 тысяч строк кода
JS — очень плохой язык для больших настоящих проектов.
Основной вопрос в том, что в больших проектах код в основном не пишут, а читают. Оптимизация по скорости написания не очень важна. Оптимизация по скорости чтения с использованием IDE, возможность автоматического анализа хоть чего-то, возможность стабильных недеструктивных рефакторингов — это самые важные приоритеты
Навскидку, десять тысяч строк кода для JS уже могут показаться сложными, требующими десятков джаваскриптеров (и тут вступает на сцену «мифический человеко-месяц», и утаскивает в пучину ада). Проект на сто тысяч строк кажется джаваскриптеру чем-то невероятно непредставимо сложным. Проект на десятки миллионов строк кода в JS существовать не может вообще
Большие проекты без IDE ты и не попишешь, вообще. Если IDE нет для языка, его просто не используют.
V8 — куда слабей как виртуальная машина, особенно в части сборки мусора (нет возможности работать с дейтсвительно большими объемами данных, или действительно маленькими объемами оперативной памяти)
Зачем на системных языках быстро нафигаривать веб-сервер?) Берешь котлин, фигаришь. А на системном языке решаешь системные задачи. Тот же веб-сервер, но маниакально перфомансно, очень долго, очень дорого и невероятно офигенно. А потом оборачиваешь в нативную обёртку и зовёшь его из Котлина, чтобы получить лучшее из двух миров одновременно