Суть темы. Приветствую тебя умный анон. Суть темы в том, что материала типа "выучи джаву за 21 день и стань джуном" куча, но очень мало материала по сайтостроению или EE. И хотелось бы собрать инфу по этому вопросу.
Предисловие. Программируя на пхп, я осознал свою никчемность я осознал, что мне нужно реальное веб приложение, с более менее хорошим быстродействием и параллельными вкусностями (а не круговорот постоянных инициализаций каждый раз в скриптах), статическая типизация, компиляция и прочее вкусности для приложений средний или большой величины.
Вопросы. Пробегаясь по языкам, я остановился на джаве, но открыв джава EE я несколько офигел. Отсюда выплыли следующие вопросы.
1. Есть ли более легкие пути чем EE для создания сайтов, если такое имеется, то имеет ли это все какой-то термин, чтобы можно было загуглить?
2. Какой стек технологий сейчас используется для построения простых веб приложений (не совсем хоум странички, но и не энтерпрайз банка, например, хочу написать по старинке некий портал с форумом)?
3. Можно где-то откопать сорцы сайтов (типа гитхаба) или CMS'ок, чтобы посмотреть, как вообще пишут сайты на джаве?
4. Кидайте вообще любые материалы по теме, хочется собрать все что возможно, так как я немного в ступоре (материал русскоязычный так же приветствуется, даже устаревший, хотя конечно я все понимаю - инглиш наше все).
PS так же можете кидать ссылки по любой тематике джавы, не только для веб-сайтов, все полезное схоронится и передастся так же потомкам, вспоминая труды анона.
>>618065 сервлеты смотрел, смотрел jsp и даже о jsf узнал, поэтому хотелось бы полный стек услышать, чтобы быть в тренде, а не на голых сервлетах писать.
С первым получаешь немного магии, быстрый старт и минимальное приложение, разбираешься и добавляешь функциональности. Со вторым - получаешь сразу просто дохуя магии, бест практис по версии авторов и ковыряешься в куче всего, чего тебе даже не понадобится.
По play, если интересует java, то нужно смотреть первый.
>>618114 хипстеры конечно хорошо, но хочется быть в мейнстриме. Пускай со всей болью, но надежно и надолго. Конечно интересуют лучшие практики. Пока нарыл такой стек -maven (помима управления пакетов им еще развертывавают) -spring DI (в видосах говорят что достаточно депендеси инжекшен только, хотя у j2EE есть вроде CDI крутой какой-то?) -Hibernate(для базы) -log4j (для логов) -я так понимаю jsp (не уловил фишку jsf, там XHTML, а HTML 5 не поддерживается?).
Томкат - как "сервер", я так понял один томкат на один сайт? А для нескольких доменов glassfish?
Вроде ничего не забыл.
Насколько это будет все шустро, если я проект с пхп перенесу, не выйдет так, что я смогу еще просесть в производительности или по ОЗУ (например из-за хибернейта)? При условиях, что я пишу правильно :) (то есть насколько это все тяжело для простого сайта)
>>618128 Нарыл тесты хибернейта и jdbc, ну собственно оверхед как в любой ORM там, в моем случае наверно jdbc через (пока мне неизвестный) DAO лучше подойдет?
>>618191 Стек технологий большой, но в то же время (я себя успокаиваю), что все это как бы проверенное годами и какой-то де-факто стандарт. Например, взяв другой язык с фреймворком, можно словить кучу внутри особенностей, сравнимых с со стеком в джаве. В пхп вообще каша, от части что-то похоже, от части больная фантазия очередного автора. Поэтому тут если и осилить, то более менее одно и все (а не каждые два года смотреть, что там выдумали нового).
По поводу ментора, это вообще проблема ИТ. Профи не хотят возиться, хеллоуворщики (любители тупо почесать языком, начитавшись хабра, но сами имеющие минимум практики) вообще могут бред в голову вбить, проку никакого. Имхо, развиваться можно только силами самих обучающихся (буду бампать тему, как буду что годное находить).
>>618191 Про технологии это все бред. Я лично знаю человека который работает начальником отдела разработки ПО одного из крупнейших банков на территории экс-совка, он мне по секрету признался что когда принимает на работу смотрит на самого человека, его качества и поведение, а то какие он там технологии знает это уже все до одного места. Технологий миллиард, в энтерпрайзе миллионы, все не выучишь ни при каких условиях, если тебя захотят загрузить на собеседовании то с легкостью загрузят. Претендентов сотни на место, им есть из кого выбирать. Что нужно чтобы устроиться на работу? Ходить по собеседованиям, это как игра - если будешь часто кидать кубики, то рано или поздно выпадут нужные цифры.
Ты на каком уровне "погрязания" во все эти технологии?
По конторам рассылал резюме, был даже на стажировке. Учителя сказали, что каждая компания редко использует опенсорсные фреймворки, часто это коммерческие, вбив название которых в Гугл мало что узнаешь. Но мне даже названия не сказали - по рангу было не положено.
>Предисловие. >Программируя на пхп, я осознал свою никчемность я осознал, что мне нужно реальное веб приложение, с более менее хорошим быстродействием и параллельными вкусностями (а не круговорот постоянных инициализаций каждый раз в скриптах), статическая типизация, компиляция и прочее вкусности для приложений средний или большой величины. C S H A R P S H A R P
>>618605 если только ты оплатишь мне все мелкомягкие лицензии на дедик и еще будешь админить с гарантией, а не с чистой верой что все это в боевых условиях выживет.
О мире шарпея А вообще, сейчас фокус это веб разработка и мобильное гуано. Поэтому винда, даже с корявой моно, даже с опенсорсным с сообществом 2-3 человека, и даже с обещаниями, что патентами не тронут :) - идет просто лесом.
Да мой юный студент, когда тебе промывали мозг в универе, весь мир писал на опенсорсе и не хило так поднялся не имея зависимости от одного поставщика. Поэтому иди со своим шарпом в конторы где надо конвертировать эксель таблички с вордом и не мешай дядькам творить будущее.
>>618635 >если только ты оплатишь мне все мелкомягкие лицензии на дедик На дедик чего, ебанашка? ASP.NET давно уж легко крутится на прыщах. >еще будешь админить с гарантией, а не с чистой верой что все это в боевых условиях выживет Что несет, вообще охуеть. >:) >идет просто лесом Бля... >Да мой юный студент, когда тебе промывали мозг в универе, весь мир писал на опенсорсе Даденька, почему вы дегенерат? ASP.NET опенсорс уж давно. https://github.com/aspnet >не мешай дядькам творить будущее >жаба >будущее М, ясн...
>>619130 тебе явно сказали, с кривым моно или костылевыми поддержками идти лесом. Запустить хеллоуворд в 100 строчек, еще не значит вести проект на линухе с хреновым количеством запросов в секунду. То есть, ты можешь писать код, а можешь себе загнать в кишку метровую трубу. Писать код как бы ты будешь, но в последнем случае весьма неудобно. Так вот шарп на линухе это как эта труба, и возникает вопрос - зачем? Опенсор нахер не вкотился без большого комьюнити.
В общем, все эти доводы бестолковы, это как онанизм, вроде юные головые успокаивает, но на практике проблем не решает.
>>619391 >тебе явно сказали, с кривым моно или костылевыми поддержками идти лесом. Причем тут моно, уебан? ASP.NET vNext + .NET Core нативны для линукса. >Запустить хеллоуворд в 100 строчек, еще не значит вести проект на линухе с хреновым количеством запросов в секунду. Расскажи это разработчикам стаковерфлоу, уебище беспруфное. >Опенсор нахер не вкотился без большого комьюнити. Дефайн большое комьюнити. >В общем, все эти доводы бестолковы, это как онанизм, вроде юные головые успокаивает, но на практике проблем не решает. Проблема тут только в твоей ДНК.
Работаю в организации джуниором, разрабатываем систему в сфере транспортной логистики, в общем самый энтерпрайз.
JBoss используется в качестве сервера приложений (аналог GlassFish) К нему в нагрузку идет MS SQL Server и Hibernate. Далее сразу в веб часть. Наши веб порталы реализованы в виде отдельных веб приложений. По одному приложению "на сайт" (условно, так одно приложения для конечных клиентов, второе для внутреннего пользования, и так далее). Вертятся все на одном томкате. Далее по внутренностям. Maven для сборки Spring Framework как основа основ, как я понял это таки и есть стандарт дефакто. К слову этот же фреймворк можно юзать и для разработки standalone (ну т.е. десктопных) приложений. Spring MVC - этакая обертка над сервлетами, более высокий уровень абстракции Spring Security - авторизация и аутентификация пользователей с прочими куками. Кроме этого юзают ExtJS для написания клиентского приложения (то что в браузер пользователю загрузится)
В более упрощенном виде Apache Tomcat используется как сервер приложений, т.е. то самое пресловутое веб приложение и будет твоей центральной частью, оно будет взаимодействовать с базой, с ним же будет взаимодействовать пользователь через клиентское приложение. СУБД можешь юзать любую (ну точнее что подойдет под твои нужды). ORM - тот же Hibernate, особенно если у тебя развесистая модель данных, но можно юзать JDBC как есть, тот же spring имеет удобные обертки для работы с JDBC драйвером, зацени еще SqlBuilder с валидацией из коробки дабы SQL чистым текстом не писать. В общем и целом накодил серверную часть, задеплоил в виде war архива на tomcat, далее стучишься по адресу из браузера.
О куче технологий в стеке. Да, может несколько демотивировать. Я когда пришел в организацию энтерпрайз даже близко не видел, не говоря уж о том что не знал как оно работает. Тем не менее под рукой были исходники системы. На текущий момент удалось изучить то что необходимо хотя бы для минимального использования так сказать в быту. Поэтому все в твоих руках, были бы исходники.
Попробуй на том же GitHub поискать веб приложения по ключам war, tomcat, spring mvc.
Про Dependency Injection. Сам по себе Java EE это набор спецификаций, их реализацией являются серверы приложений - JBoss, GlassFish и другие. Кроме всего прочего спецификация описывает такое понятие как IoC - https://en.wikipedia.org/wiki/Inversion_of_control , суть такова - тяжесть управления зависимостями между компонентами твоего приложения ложится на т.н. "контейнер", компонент спецификации и сервера приложений в частности. В его задачи входит управление частями твоего приложения - бинами. Контейнер выполняет внедрение ссылок одних бинов в другие (раньше делалось через развесистые XML, ныне через удобные аннотации). Бины в общем случае это сервисы предоставляющие услуги для работы с некоторого рода данными.
Скажем ты делаешь портал для управления персоналом (условно). Тогда в таком приложении могут присутствовать следующие сервисы EmployeeService - предоставляет операции для добавления/уволнения сотрудников, получения различной информации по сотрудникам WageService - сервис для начисления зарплат сотрудникам, такой сервис точно должен быть связан с предыдущим так как нужно получить где-то списки сотрудников для расчета зарплаты. Оба сервиса также имеют ссылку на компонент обеспечивающий работу с базой (предоставляется самим контейнером). Ну ты понел.
В общем и целом, контейнер (IoC, CDI или DI) предоставляется спецификацией ЕЕ и присутствует в типовых серверах приложений. Tomcat однако не реализовывает спецификацию, поэтому своего контейнера не имеет. В тоже время контейнер есть у Spring (опять же, в разработке под десктоп Spring дает все плюшки IoC). В области сайтов на Java я начал бы с семейства фреймвороков Spring, а как основы будут усвоены можно глянуть на что-нибудь еще.
Яков Файн - приятный украинский еврей вещает из ньюйоркщины тотал нуфагам, ооочень годно, толково и доходчиво, прям с нуля и хорошо по стеку и принципам идет, с примерами и задачами. Слышал что один работодатель приннимает на работу узнав что нуфаг обучался по его книжке. Не знаю на какой ты стадии, может кому-то другому будет полезно.- https://www.youtube.com/playlist?list=PLkKunJj_bZefB1_hhS68092rbF4HFtKjW
А вот Сергей Немчиский, ссылки на его статью здесь уже вбросили, на своем канале очень много и в деталях рассказывает об особенностях ЕЕ кухни в этих странах, менторство, устройство, собеседования, рабочий процесс, стек технологий которыми пользуються реально, а не хипсторы, и т.д. Иногда беседует в чатике лайв - https://www.youtube.com/channel/UCVbz7l0COUdLupcY4YtYH0w
[режим теории заговора] на месте мс я бы не стал делать дотнет лучше чем на винде вообще. Я бы сделал так, что как бы можно было бы, но чтобы если уже серьезный продукт вести нужно было обосраться и перейти на основную среду дотнета (это желание будет куда ярче если у вас уже тонна кода и программистов)
>>619475 >Расскажи это разработчикам стаковерфлоу, уебище беспруфное. У них же вин сервер, не? Недавно обновляли пост с описанием своих технологий, win server стал r2, а не просто 2012.
Шалом, парни. Тут есть кто-то кто работал с корпоративными приложениями? Нужны пару советов по архитектуре и вообще процессу. У меня есть задача построить что-то внутренней корпоративной социальной сети с разными типами пользователей, возможностью загрузки видео, документов, изображений для определенных групп и определенных пользователей. В энтерпрайзе никогда не работал, но опыт своих поделий на схожем стеке имею. Приложение строю на Spring Container, Sping Data, Spring MVC, Spring Seurity. На чем писать фронт еще не решил, скорее всего Angular, не будет получаться, буду пилить на JSP. Пока что только сконфигурировал слоя, что дальше делать плохо представляю, кажется нужно маппить сущности - вот только не знаю как это сделать правильно с учетом моего Security слоя, прибегнуть ли к наследованию, или нет. Короче если есть желание немного подсказать - оставьте фейкомыльца, или я свое оставлю, не важно.
>>620112 Касательно модели данных - по возможности избегай наследования. Допустим есть у тебя сотрудники, они делятся на некоторые категории, которые в свою очередь подразделяются на дополнительные категории, ну ты понел. Так вот в этом случае лучше всего реализовать один класс для сущности "сотрудник", а категории реализовать в виде свойств такого класса. Много проще потом это все в БД хранить ну и работать с этим.
А вообще я для себя выработал примерно такой порядок: - модель данных (отражение предметной области в коде), сюда включаем создание классов сущностей и маппинг через твою ORM (Hibernate я надеюсь) - сервисы - они же бины, предоставляющие услуги конечным "потребителям" по обработке твоих сущностей, добавление новых, удаление старых, формирование списков и так далее; сюда же включаем бизнес логику, которая выполняет некоторые дополнительные вычисления над данными перед тем как они уйдут в БД. - клиентская часть - то что собственно и будет видеть пользователь, веб портал, мобильно приложение, возможно веб или REST сервис
В самом кошерном виде твои сервисы должны быть спроектированы так, чтобы предоставлять услуги любым потребителям. В этом случае ты не связан по рукам и ногам в реализации клиентской части. Сегодня намутил сайт, а завтра андроид приложение, при этом используя одни и те же сервисы твоего ядра.
Перед тем как непосредственно кодить лучше спроектировать свое решение. Определить требования, которые предъявляются системе, какие возможности она должна иметь, что пользователям можно будет делать с ней. Т.е. скажем, начинаешь проектирование с пользовательского интерфейса, в течение этого процесса формируешь требования для твоих сервисов в ядре. Модель данных впрочем лучше строить на основе прикладной части с которой ты работаешь, потом немного корректируя под нужды или же ограничения системы.
Стремись к снижению сложности разработки. Между реализацией какой-то супер мега универсальной фичи и более простым но возможно топорным вариантом выбирай топорный. Во первых понизишь сложность разработки, во вторых проще будет потому самому сопровождать, в третьих сократишь время разработки. В конце концов с течением времени когда будет готов костяк системы можно будет реализовывать те самые супер мега фичи, но опять же всегда следуй принципу сокращения сложности разработки.
Помни еще один немаловажный момент. Разработка это во многом итерационный процесс. Порой решить некоторую задачу невозможно до тех пора пока ты собственно не начнешь ее решать. Некоторых подводных камней не видно в самом начале и ощутить всю сложность затеи можно только погрязнув в ней с головой. Поэтому и следует стремиться к сокращению сложности разработки - ты быстрее реализуешь первую версию, столкнешься с основными подводными камнями и с этим знанием сможешь приступить к следующей итерации и выпуску уже второй версии (при этом мы учитываем что первая версия должна быть юзабельной). Не стоит стремиться сделать сразу все идеально - можно в итоге никогда не закончить.
Фейкомыльца - на мой взгляд идея плохая. В треде затронута очень важная тема. Оп все верно написал что есть тонна книга о том как изучить базись, но о том как именно кодить реальные рабочие системы написано крайне мало. Поэтому это стоит обсуждать в открытую - мне в свое время этого крайне не хватало.
На досуге рекомендую почитать Стива Макконнелла - Совершенный код. Книга фактически компиляция самых годных best practice именно о разработке вообще. Как стоит делать, как не стоит делать, как корректнее приступать и выполнять проектирование.
>>620153 Спасибо тебе антоша за такой развернутый ответ, очень помогло! Теперь хоть понятно с чего и как начинать. Совершенный код читал конечно, но там больше технические детали языка, хотя вроде и по проектированию интерфейсов есть пару страниц.
>>620175 >Совершенный код Наоборот же, главы до пятой рассказывают как раз о процессе проектирования вообще. Именно Стив Макконнелл пишет про сокращение сложности как об основном принципе которым следует руководствоваться при разработке и проектировании. В любом случае добра тебе и успехов в разработке. Пиши читабельный и легко сопровождаемый код.
Spring MVC (JSP/Servlet) + JS-скрипты на клиентской части Как вариант, все запросы к серверу делать через JS, на джаве только сервлеты
JSF/Tapestry/прочие компонентные фреймворки - с виду выглядит неплохо, но реально медленные, и если нужны кастомные компоненты или поведение - начинаются большие проблемы
>>620153 >Оп все верно написал что есть тонна книга о том как изучить базись, но о том как именно кодить реальные рабочие системы написано крайне мало
Так и есть, когда ты вроде уже умеешь кодить, нужен материал каких-то лучших практик, чтобы сразу ворваться и писать "как все" (точнее учиться писать как все, хуже нет, когда впитываешь инфу, а потом она просто оказывается не актуальна). Поэтому надеюсь сорцы найти, или быть может кто опубликует что (какой-то каркас, что не жалко). Нужен ориентир. Если не найду попробую какую CMS поковырять (хотя код CMS это та еще каша для головы).
========================
Может кто прям внятно расписать из каких слоев состоит веб приложение? Как я уловил сервлеты->сервисы бизнес логики -> данные (типа сишных структур, рекорды еще зовут, но с геттерами и сеттерами)
Мне вот интересно, как например организовать кошерно в джаве такой подход: Создание поста (сообщения) где либо (пользователь создает сообщение уже послал данные):
-адресуем (/post/save) на нужный сервлет:
-обрабатываем POST запрос, проверка корректности данных POST запроса (проверка наличия всех нужных переменных, их длин и определения какого-то поведения при наличие каких-то управляющих переменных (пользователь например отключил смайлы в посте)).
-парсинг тегов (например BB тегов как на дваче). -парсинг смайлов (спец-маркеры переделываем в ссылки на смайлик). -фильтрация/экранирование безопасности, вырезаем html и js возможные вставки.
-передача на сохранение (быть может какая-то операция экранирования для SQL безопасности)
-переадресация 302 на страницу комментов (допустим без ajax мы)
Как это все будет выглядеть в джаве? (прям детально не надо, надо базис уловить)
>>622000 Разделяй весь процесс на абстракции. Скажем твой же пример.
>-адресуем (/post/save) на нужный сервлет: >-обрабатываем POST запрос, проверка корректности данных POST запроса (проверка наличия всех нужных переменных, их длин и определения какого-то поведения при наличие каких-то управляющих переменных (пользователь например отключил смайлы в посте)).
Несомненно это вещи связанные непосредственно с транспортировкой запросов от клиента к серверу и должно это оставаться в пределах того же сервлета.
Далее
>-парсинг тегов (например BB тегов как на дваче). >-парсинг смайлов (спец-маркеры переделываем в ссылки на смайлик). >-фильтрация/экранирование безопасности, вырезаем html и js возможные вставки.
Это уже логика твоего приложения. Логика не должна знать подробностей о реализации транспартировки данных от клиента к серверу, не должна знать как потом данные будут у тебя храниться. Логика выполняет некоторую последовательность действий связанную с твоей предметной областью. В твоем примере это обработка сообщений от пользователя. Зацитированные пункты канонично должны находится в сервисе/бине твоего приложения. Есть некий метод который и выполняет обработку, т.е. представляет собой некий черный ящик, который на входе получает сырую информацию, а на выходе отдает данные готовые для сохранения или каких-либо дополнительных действий. Описанные действия можно в принципе разделить на отдельные сервисные методы, особенно если часть логики предполагается использовать в другом месте.
Последнее
>-передача на сохранение (быть может какая-то операция экранирования для SQL безопасности) >-переадресация 302 на страницу комментов (допустим без ajax мы)
Готовые данные отправляются на сохранение. Сохранением в БД в энтерпрайзе занимается EntityManager, у Hibernate для этого есть SessionManager, у JDBC драйвера это DataSource (если не путаю). В общем и целом это отдельный компонент, который также через CDI может быть внедрен в твои сервисные бины и именно этому компоненту потом передается информация для сохранения данных. Если никаких исключений в процессе не упало то возвращаем пользователю ОК, в противном случае страницу/сообщение с ошибкой.
В итоге имеем следующее: - сервлет принимает запрос от клиента, валидирует его и сырые данные передает твоему сервису (MessageHandlerService.handleMessage()) - сервис вызывает метод выполняющий непосредственную обработку данных (MessageHandlerService.parseMessage()), такой метод можно будет покрыть тестами - далее сервис выполняет сохранение либо через DAO объект (MessageDAO.updateMessage()), либо через непосредственный вызов того же EntityManager (на случай если процедура сохранения не предполагает каких-либо сложных действий и обрабатываемая модель данных не имеет сложную иерархию)
Т.е. все можно свести к следующему порядку: 1. Обработка запроса от клиента 2. Передача сырых данных сервису 3. Сервис выполняет: - непосредственную обработку данных - сохранение данных в БД
Плюсом того что логика обработки данных вынесена в отдельный метод является возможность написания тестов. В этом случае не придется городить огород с тестовыми БД, моками сервлетов и прочего.
Дроби код на различные сервисы, одна сложная операция может быть разбита на несколько более простых, которые относятся к разным сферам твоей предметной области, и которые в дальнейшем можно будет переиспользовать в другом месте твоего веб приложения.
>>622000 >Может кто прям внятно расписать из каких слоев состоит веб приложение? >Как я уловил сервлеты->сервисы бизнес логики -> данные (типа сишных структур, рекорды еще зовут, но с геттерами и сеттерами)
Все верно. Данные также называют сущностями, сущностями твоей предметной области, для которой ты пишешь свое приложение. Сишные структуры, рекорды - в общем смысле это все сущности. Сущности затем перекладываются на реляционную модель твоей БД. Скажем в твоем примере можно выделить: пользователь - содержит имя, почту, etc сообщение - содержит текст, пользователя автора, возможно изображения или другое медиа тема - содержит набор сообщений ветка/раздел - содержит набор тем изображение - содержит линк на изображения на твоем сервере, либо само изображение в BLOB (условно) и так далее.
Сущности обрабатываются бизнес логикой в сервисах. Методы сервисов вызываются клиентами запросами через сервлеты, RMI запросами, SOAP или RESTfull сервисами, т.е. любыми внешними потребителями. Как правило сервисы взаимодействуют друг с другом, сервисы с более простыми операциями вызываются сервисами с более сложной логикой. Но общий процесс остается неизменен.
Чем сложнее предметная область, которую охватывает твой сайт/система, тем больше будет сущностей и тем сложнее будет связь между ними. Чем больше система тем больше возможностей по обработке данных она должна предоставлять, и соответственно тем более развесистым будет набор твоих сервисов с бизнес логикой.
>>618046 (OP) EE - самое основное отличие от всякого рода php- твоё приложение не самостоятельно. Его исполняет контейнер. Этот пункт часто опускается, как сам собой разумеющийся. но он крайне важен для быстрого понимания, как быстро запилить скелет приложения.
Исходя из этого - 1)требуется сторонний сервер, который вообще может выполнять EE приложения, например glassfish. 2)поставив этот самый glassfish нужно настроить там datasourse и прочее, т.к. твоё приложение по сути раб контейнера и юзает тот em что дают. 3) смотри структуру папок в проекте, который собирает maven
Когда всё настроено(тут надо курить гайды и мануалы, надо чтобы пустой проект взлетал и было всё понятно в конфигах итд), создай java файл и читая документацию по WS запили первый роут, который ответит hello world на get запрос.
Дальше сразу выяснится что размещать логику прямо в роутах - говнокод высшего калибра из чего и следуют все традиционные слои (dao, сервисы итд)
>>619130 > ASP.NET давно уж легко крутится на прыщах. Нахуя он там нужен? Спермоутки пусть дальше посасывают на своим окошках, а хипстеры всякие вообще на нод.жс/го/раст/<вставить название любого недоязыка младше 2005 года> сайты пишут. мимо
>>622648 Вот кстати вопрос, а сервера приложений да и стек технологий различается для веб приложений внутреннего применения и для интернета? Где то, наверно на хабре, проскакивало нечто типа (суть): "ошибка пытаться выполнить желание заказчика, адаптировать написанное для внутреннего использования приложение для открытого доступа из интернет"...
>>622783 Пожалуй корпоративное приложение(написанное для применения фирмой и её контрагентами) действительно не лучшая идея делать общедоступным сервисом(но тут решает совет директоров же. Хотя зачем ему это?). Сервер приложений в принципе имеет нормальную производительность, тем более если приложение горизонтально масштабируется, то стак технологий не создаст особых проблем.
>>618046 (OP) В 2016 сайты делают на JavaScript. Максимум куда можно воткнуть джаву - это REST сервисы. По этой теме рекомендую посмотреть на Dropwizard - очень практичный набор инструментов без налета энтерпрайз-безумия
спасибо за инфу, по сути в бизнес логике можно творить что хочешь? Я так понял, каких-то там стандартов нет (ну в рамках модульности и ООПшности писать)
>>620153 Антоша, я >>620112-кун который возможно займется реализацией проекта из описания в посте, хотел спросить такую штуку — на твой взгляд, сколько времени может занять реализация такого проекта, при условии что над ним будет работать два человека, один из которых имеет небольшой опыт в спринге и сопутствующих технологиях, а второй только с фронтендом? Да вопрос глупый, куча факторов, но все же — есть какие-то средние цифры? Пол-года, год? И еще один тоже довольно каверзный вопрос — есть какие-то денежные рамки при разработке подобного? Как считается конечная стоимость — по количеству строк кода, времени на разработку... фазы луны, етс.
>>623500 Очень сложный вопрос, по крайней мере для меня. Смотря как вы будете работать - полный рабочий день или только по вечерам в свободное время, но даже в первом случае разработка может затянутся до года. Хотя эта цифра очень абстрактная. Я могу сильно ошибиться в масштабности вашей затеи, пусть кто-нибудь из местных анонов еще прикинет примерное время.
Считать стоимость по строкам кода - дикий пиздец. Насколько мне известно за основу берется стоимость часа у конкретного разработчика, а затем прикидывается сколько по времени займет реализация того или иного функционала. При этом как писал небезызвестный Стив Макконнелл - порой оценить реальную сложность задачи можно только после того как приступишь к ее решению, следовательно временные рамки могут раздвинуться и соответственно вырастет стоимость разработки.
>>622938 Фактически да, но опять же как и энтерпрайзе в целом так и в Spring в частности есть несколько разных типов бинов заточенные под различные типы задач. Stateless/statefull/singleton/др. бины по спецификации EE, prototype/singleton/др. по Spring'у. В простом варианте все бины являются синглтонами. Но если необходимо чтобы приложение можно было масштабировать, плюс если необходимо использовать плюшки серверов приложений то нужно смотреть в сторону stateless/statefull бинов. Пусть анон поправит меня если я где ошибся, потому как этом направлении ориентируюсь не достаточно хорошо.
>полный рабочий день или только по вечерам в свободное время, но даже в первом случае разработка может затянутся до года
Я написал суровую веб-платформу под нагрузку за 2 месяца, максимум сидел часов 10 в неделю. Один!
Все эти гавно шаражки где у них там штат по 100 человек, синьёры, хуёры. Сидят они там, сидят, что-то пилят.
Однажды я туда ради прикола устроился. Кароче, там 90% сами не понимают что они делают, остальные 10 процентов кое-как может и шарят, что большинство времени сидят в вк или пьют кофе в коридоре. Ебали они программирование и вообще разработку.
Дай мне 2-3 человека средней руки и 1 дизайнера, чтобы кнопки нарисовал. Я подниму гугл или вк за пол года неспеша.
И да, писал на спринге с мощной базой, кеш серверами и с 0 реализовывал авторизацию и админку. Я предусмотрел все дыры безопастности и конечно же написал в правильном и грамотно всё стиле. Я даже блять дизайн нарисовал и написал весь фронт на ЧИСТОМ джаваскрипте.
Если я дебил такое поднял, я не представляю что могут поднять грамотные и прошаренные ребята за столько же времени.
>>623773 >предусмотрел все дыры безопастности Очень смелое утверждение
>Кароче, там 90% сами не понимают что они делают, остальные 10 процентов кое-как может и шарят, что большинство времени сидят в вк или пьют кофе в коридоре. >Ебали они программирование и вообще разработку.
А вот тут согласен. Особенно с последним утверждением.
Да и вообще, можно горы свернуть, было б только желание. А если желания нет то и задачи средней легкости будут тяжело даваться.
>>622896 >Dropwizard люто плюсую этого адеквата. я сам джавист, на работе пришёл заказ написать rest на dropwizard на бэке и angularjs на фронте. Сначала поебались знатно по незнанию, но когда размутились поняли, как это охуенно. Dropwizard хорош тем, что он из коробки умеет в json, в базу и в angularjs. т.е. он сразу идёт в комплекте с jetty сервером, и соответственно angular app уже разворачивает в нём. знали бы вы как это охуенно!!!!
ОП, не слушай мудаков. Если тебе нужно просто налабать быстро небольшой сайт - твой выбор Spark + Freemarker как темплейт енджин. Нужна бд - хуяришь JDBC или просто подцепляешь легкий Ebean. И у тебя выйдет небольшое приложение, которое будет летать на Raspberry и на днище машине. Если хочешь прокачаться именно по карьере - Spring + Hibernate без вариантов. EE мертв. Play для мудаков.
>>628210 Те же хабровята в комментах писали, что на прстых примерах все круто, но как только дело доходит до серьезных вещей начинают вылезать ограничения и подводные камни. Сам не пользовался, добавить мне нечего. Может кто из анонов еще что-нибудь подскажет.
>>623500 Вдвоём? Я думаю в лучшем случае год, хотя это условно, ведь задача очень абстрактно поставлена. А оценивать куда уж проще? Время разработчиков, вот это и считайте.
Хочу создать свой двачь новой расцветки, так как заебало сидеть там, где записываются все IP и выдаются ФСБ в случае чего. Пусть там будут сидеть только мои одноклассники и вайпать все говном, а я буду думать, что чего-то стою в этой жизни.
Тред не читал. Сам пользуюсь связкой Stripes framework + apache myBatis для работы с бд. Упорот и самодостаточен. На спрингоблядей посматриваю, как на говно. Перегруженное enterprise нечто.
>>658939 за скалу ничего не знаю, как-то с недоверием смотрел на эту моду (уходящую) со смешением ФП и всего и вся (что превращало код в подобии с++, т.е. код для сопровождения становился перегруженным). Что меня привлекает в котлине, это настоящая обратная совместимость и политика не трогать синтаксис.
>>658960 >с недоверием смотрел на эту моду (уходящую) со смешением ФП и всего и вся ФП - то будущее куда, мы все движемся. Достаточно осторожное, но его нельзя не заметить. А вот смешение со всем подряд - действительно плохо. Смешение должно быть вдумчивым.
>настоящая обратная совместимость и политика не трогать синтаксис Да, за счет прагматичного дизайна и экспертизы JetBrains Котлин может выстрелить.
>>659102 чаще я вижу, что ФП это объект измерения собственной важности у программистов (почему-то у многих это главная линейка), больше никакой практической пользы и реальных телодвижений не видел. Конечно есть там интересные решения и их давно просто к себе перетащили, поэтому развития не будет уже точно (высосали все что нужно было).
Писать мудрено не сложно, сопровождать высер больного разума "гения", это беда. Сейчас вроде тенденция к упрощению и я рад этому (лучше я напишу на 5 строчек больше кода, чем потом повисну мозгами на какой-то "умной" строчке кода)
>>659138 Посмотри на ReactJS и Redux. Там ФП прячет вообще всю сложность создания и менеджа UI: Больше не нужно вручную описывать, как именно интерфейс должен меняться при действиях пользователя или получения каких-то событий с бекенда. Нужно просто написать функцию, которая из данных (State) создает VirtualDOM интерфейса. Тоже самое с диспетчеризацией действий пользователя: получили Action, вернули новый экземпляр Store. Интерфейс сапдейтился через уже написанную функцию store -> VirtualDOM. Никакого геморроя с Observable, привязкой данных к UI и т.п. Пример хорошего годного ФП подхода.
>>659176 Этого двачую. Функциональщина уже на фронте, на фронте блджад! А жавамакаки всё копаются в своей процедурной хуете, производя по 150 строчек кода там, где достаточно десяти. Хотя им то что, зарплату платят, а раз так, то будут однотипные действия повторять.
У меня по клику на таблицу стоит эвент, если кликнут 3й столбец, то условие. Все нормально работает, но при этом в консоли, если любой другой столбец кликнут, вылетает куча ошибок.
я и про ООП так же думаю, по сути все там пишут в процедурном стиле (пустые данные и сервисы, что как бы напоминает сишные функции и структуры с геттерами и сеттирами (просто верх развития программирования, лол)).
ООП выстрелил за счет умения связать отдельные кучки программистов, в одну продуктивную работу, чтоб те обезьяны не срались между собой и не мешали друг другу (за счет интерфейсов, он же полиморфизм), ну и за возможно реально спрятать от других данные (инкапсуляция). А в остальном там костыли такие, что даже есть паттерны решающие по сути недостатки ООП.
Так же невидимой фишкой ООП является то, что начинающий программист по умолчанию сразу более менее структурирует свои алгоритмы (хватает мозгов собрать в классы). Процедурный же дает много вольностей и писать модульно, надо еще научится (хотя я и в классах вижу чудеса)
Но мне на самом деле похер, просто это эпичное наебалово, которое смогли "продать". Что насчет ФП, так тут в истории аналогии нет, я уже сказал, все хорошее высосали.
>>659379 >я и про ООП так же думаю Всё с тобой ясно, мартыхан
>напоминает сишные функции и структуры Это потому что болезные процедурные дебилы всегда пытаются переизобрести ООП, передачей указателя на структуру первым аргументом и т.п. анальными ухищрениями, лишь бы не признавать убогость своего недоязычка.
>>659393 Ага, такие дебилы как например Martin Fowler и его (а может не его, но им представленная) анемичная модель предметной области.
Просто некоторому юному поколению того времени, которым промывали мозги ООП, пришлось пройти некоторую боль и сделать неожиданное открытие, что данные и алгоритмы должны быть раздельными и это уже общепринятая норма (но ты конечно городишь god object и счастлив, не понимая в программирование нефига (кстати на нативном уровне именно так и реализовано, в памяти же не дублируются методы)).
Что касается передачи объекта в свой метод, это да, анахронизм полный (но именно это я понял тебя больше всего и коробит, ты слишком ленив для еще одного аргумента и вся критика сводится не к теории программирования или проектирования языков, а все лишь к ебучему лишнему аргументу в методе :D )
>>659546 пыха для меня все, она начала пародировать java, при этом пародия то неудачная. Каждый раз фронт инитит тысячи классов и это боль. Не по пути скрипта пошла пыха, для полноценной ООП-радости нужно работающие приложение в памяти, а не дрочка инициализаций и проверкой типов каждый раз.
Короче, скрипт, который делает колонки таблицы по размеру текста. как к нему добавить разворачивание по клику или хотя бы полосу прокрутки к ячейкам. cmodel.getColumn(4).setCellRenderer(textAreaRenderer); только к колонке применяется. http://ideone.com/ECAnuo
Еще раз напоминаю три основных обсёра ООП макак 1) Полиморфизм. Для ООП-макаки полиморфизм = сабтайпинг. 2) Инкапсуляция. Уровня private членов класса. Модулей низавизли. 3) Наследование. Решает для манкипатчинга в скриптах. На большее не годится.
Приветствую тебя умный анон. Суть темы в том, что материала типа "выучи джаву за 21 день и стань джуном" куча, но очень мало материала по сайтостроению или EE. И хотелось бы собрать инфу по этому вопросу.
Предисловие.
Программируя на пхп, я осознал свою никчемность я осознал, что мне нужно реальное веб приложение, с более менее хорошим быстродействием и параллельными вкусностями (а не круговорот постоянных инициализаций каждый раз в скриптах), статическая типизация, компиляция и прочее вкусности для приложений средний или большой величины.
Вопросы.
Пробегаясь по языкам, я остановился на джаве, но открыв джава EE я несколько офигел.
Отсюда выплыли следующие вопросы.
1. Есть ли более легкие пути чем EE для создания сайтов, если такое имеется, то имеет ли это все какой-то термин, чтобы можно было загуглить?
2. Какой стек технологий сейчас используется для построения простых веб приложений (не совсем хоум странички, но и не энтерпрайз банка, например, хочу написать по старинке некий портал с форумом)?
3. Можно где-то откопать сорцы сайтов (типа гитхаба) или CMS'ок, чтобы посмотреть, как вообще пишут сайты на джаве?
4. Кидайте вообще любые материалы по теме, хочется собрать все что возможно, так как я немного в ступоре (материал русскоязычный так же приветствуется, даже устаревший, хотя конечно я все понимаю - инглиш наше все).
PS так же можете кидать ссылки по любой тематике джавы, не только для веб-сайтов, все полезное схоронится и передастся так же потомкам, вспоминая труды анона.