Java и тяжелое наследие

Антон Скорко 04.04.2015 15:29

Коментар порушує правила спільноти і видалений модераторами.

Антон Скорко 04.04.2015 15:28

Коментар порушує правила спільноти і видалений модераторами.

flyman 12.06.2012 13:01

кому не подобається джава, може перейти на С++ або голий С

Відповісти

Підтримати

Viacheslav 12.06.2012 13:16

А шо в С плохого то?

Відповісти

Підтримати

flyman

flyman 12.06.2012 13:21

він бородатіше і спадщина в нього тяжча

Відповісти

Підтримати

Viacheslav

undefined pointer 12.06.2012 14:34

ну чого ви такий злий?

На Рельси, на Рельси, там майже вічний оргазм, кажуть.

Ну або на Python, там кажуть помірне задоволення. Теж надовго.

Відповісти

Підтримати

flyman

anonymous 12.06.2012 14:46

-

Відповісти

Підтримати

undefined pointer

bsod 05.06.2012 22:25

Решил поднять топик. На момент создания были сомнения, что может я просто вечно всем недовольный ворчун, который не хочет и не любит работать.
Ан нет, работа на Java, в которой присутствует собственно разработка плюс здравый смысл и свобода в выборе инструментов — чистое удовольствие.

I ♥ Java.

Відповісти

Підтримати

Batter 26.02.2012 22:55

Працюю на проекті, де JDBC це не найгірший варіант. І ще багато яких «скарбів» залишилось з часів 2000-го року. Але як на мене, криві руки програміста який навіть не спробував з"ясувати функціонал і зформувати правильну архітектуру до програмування роблять на багато більше шкоди. А нові технології можна впроваджувати з часом, коли зрозумієш функціонал.

Відповісти

Підтримати

Mykola Gurov тролль 26.02.2012 21:06

Еще
* 15 лет? Да за два года такого можно наваять, что 10 лет разгребать будешь. Есть умельцы.
* В джава, кстати, за счет развитого инструментария, вычищать код намного проще и быстрее получается. Так что даже наличие голых сервлетов и JDBC еще не показатель. Важнее комманда и ее настрой. Ну и заказчик, конечно.

* Важный критерий версия java. Если до-generic (1.4 — ) - то точно печалька будет.

Відповісти

Підтримати

Нестор Иванович 28.02.2012 23:33

голые сервлеты еще ниче так- есть куда стремится. А вот я как то видел шаблонизатор до- JSP эпохи — вот это я вам скажу травма половая.

Відповісти

Підтримати

Mykola Gurov

Yaroslav Fedevych карлсон, который живет в подвале 26.02.2012 19:23

Но с другой стороны, есть у этого языка один существенный (а по-моему, самый главный) недостаток — языку 15 лет, а значит, есть все шансы нарваться на проект 10-летней давности (скажем, на голых сервлетах и JDBC) который отдали на аутсорс и который придется кому-то поддерживать.

Ви так говорите, наче
1) ніколи в житті не бачили проектів 20-літньої давності,

2) це щось погане.

Відповісти

Підтримати

undefined pointer 26.02.2012 14:32

Подавляющее большинство программистов мира начиная с 70ых занимаются сопровождением(поддержка его работоспособности + эволюционные изменения) старого кода. Либо своего, либо чужого. Это — норма. Так было, и так будет, и Java тут ни при чем. Хотя, раз ей 15 лет, и древний код — работает, и для совсем нового — она же используется — то значит что-то в ней есть такое здоровское.
Проблема же наступает когда хочется творить. Что-то свое и великое. Не школьным учителем математики, а доказать что там осталось у Гильберта. Не художником-оформителем, а написать чтобы мир ахнул. Не типовые многоэтажки проектировать и строить, а чтобы шейхи заказали нечто эдакое и засыпали деньгами на реализацию.

Решается же проще некуда — можете творить — творите! Не можете — так работайте. Не можете творить и не можете работать — тогда рюмка, дауншифинг, гималайские пещеры, ..., - выбор большой.

Відповісти

Підтримати

bsod 26.02.2012 14:46

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

Відповісти

Підтримати

undefined pointer

undefined pointer 26.02.2012 14:52

Если оно остановились в развитии, то что же там развивают?
Или, скажем речь о программистах MS пишущих патчи под Windows XP и прочие старые продукты?
Революции в работающем ПО очень рисковы. С точки зрения — пользователей. Если их система устраивает, то у программиста тот самый выбор — или бросить их вместе с системой, или работать.
Здесь нет как таковой проблемы, сопровождение именно старого ПО, которое уже существенно не изменится — тоже вполне — норма, обыденность. А если у вас есть таланты, то вы вполне можете уйти на другую работу, более интересную. Т.е. утрировано — проблема в собственных амбициях не подкрепленных пока (а может и навсегда) талантом, навыками и просто дерзновением.

Відповісти

Підтримати

bsod

Дмитро Думанський Co-Founder в Blynk 25.02.2012 22:13

Вижу 3 варианта:
1) Уйти
2) Ничего не менять и ходить на работу как на каторгу
3) Подстроить проект под себя, прилепить нужные Вам и полезные проекту технологии.

Собственно все. Вам решать.

Відповісти

Підтримати

Просто Свят Раб в Dev Company 25.02.2012 19:25

Это всё круто, а что человек использующий Спринг, не юзал до этого сервлеты, и на JPA он перешел без JDBC? Если да, то сожалею:)

Відповісти

Підтримати

Ruslan K 25.02.2012 22:48

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

Відповісти

Підтримати

Просто Свят

Bogdan Shyiak SE or Dev 25.02.2012 23:01

Аналогия не верна (и вы еще удивляетесь почему вас попадаетсо править ХТМЛ, или это не вы :) )

Відповісти

Підтримати

Ruslan K

Ruslan K 26.02.2012 00:09

это я )) и да мне не нравится, когда java используется для верстки страничек. если даже в древнем Perl (как и в других более и менее приличных ЯПах) мешать программный код с хтмл уже давно считается дурным тоном, среди жавистов эта практика цветет и пахнет. во всяком случае среди тех, что мне пока встречались.

что до отсылов к истории и прочим легаси технологиям, с удовольствием послушаю альтернативную точку зрения. лично мне, например, довелось поработать и с JDBC и с Hibernate, но точек пересечения я не обнаружил. экспа в первом, оказалась абсолютно бесполезной для второго. аналогично, связь между Sping (учитывая все разннобразие спрингов и экзотику типа Spring Batch) и servlets не есть очевидной.

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 26.02.2012 00:24

JDBC и с Hibernate, но точек пересечения я не обнаружил

А то что хибер основан на ДжДБС? То что для многих/некоторых задач приходитсо использовать хибернейт как просто другой интерфейс выполнения запросов?

аналогично, связь между Sping (учитывая все разннобразие спрингов и экзотику типа Spring Batch) и servlets не есть очевидной.

Вот я так же не вижу аналогию :)

не всем везет на деревянные игрушки в детстве. некоторым сразу дали в руки мягкое

И в этой фразе.

Хотя подозреваю, что Кравченко Свят имел ввиду что-то вроде СпрингМВЦ.

Відповісти

Підтримати

Ruslan K

Владислав Касаткин 26.02.2012 04:04

Да имеет. Если связь между JDBC и Hibernate такая же как и между ADO.Net и EntityFrameWork, то человеку необходимо знать основы: JDBC и ADO.Net. Логика проста: зная ADO программист сможет создать EntityFramework, а вот зная EF — ADO уже не создать.

Відповісти

Підтримати

Ruslan K

Ruslan K 26.02.2012 11:41

итого получаем: умение изобретать велосипеды vs умение быстро ездить на уже изобретенных. статистика моих собеседований показывает, что первое на рынке не востребовано, в отличие от второго.

Відповісти

Підтримати

Владислав Касаткин

Bogdan Shyiak SE or Dev 26.02.2012 11:49

умение изобретать велосипеды vs умение быстро ездить на уже изобретенных

Аналогия получше. :) Суть в том, что некоторые требуют уменее быстро и долго и самостоятельно ехать на велосипеде (это уже для синьоров, обычно). «долго и самостоятельно» подразумевает умение «подкрутить» велосипед в дороге и понимание того почему и на каких участках пути он может тормозить, чтобы при возможности обойти эти участки.

Відповісти

Підтримати

Ruslan K

bsod 26.02.2012 11:05

Тут можно задать два вопроса.
1) Нужно ли знать, как все работает на низком уровне?

2) Нужно ли писать живые проекты на низком уровне?

п.1 — я бы сказал, что скорее нужно, но вообще это тема для флеймового треда на много страниц вроде «нужно ли программисту высшее образование». а вот п.2 — скорее нет: трудозатраты выше, производительность приложения ниже (если получился кривой велосипед вместо внешнего проверенного оптимизированного решения), понятность кода ниже. Со стороны программиста: больше негатива от работы с таким кодом, не растет опыт в востребованных на рынке труда областях. Чтобы осуществить п.1, не нужно поддерживать такой проект годами — темы не настолько сложные, достаточно остновательно проийтись по всем аспектам API в игрушечном приложении.

Відповісти

Підтримати

Просто Свят

Bogdan Shyiak SE or Dev 26.02.2012 12:04

трудозатраты выше

Для простых случаев — да. Для чуть сложнее чем CRUD — нет.

производительность приложения ниже

Ну это надо постаратсо :)

понятность кода ниже

Понятность кода не зависит от фреймворка. Классический пример EJB (или JSF) — считался спасением всего чего только можно, а сейчас «фууу».

больше негатива от работы с таким кодом

С чего бы это?

не растет опыт в востребованных на рынке труда областях

От тут низя не согласитсо. Но это дело такое: года 4 назад Struts был во всех вакансиях, а сейчас?

Відповісти

Підтримати

bsod

bsod 26.02.2012 12:42

Для простых случаев — да. Для чуть сложнее чем CRUD — нет.

Из CRUD и других задач, которые хорошо ложатся на ORM и популярные фреймворки, состоит значительная часть типичного веб-приложения (а иногда и все приложение :) ). Для других задач никто не мешает использовать другие методы, но пусть большой объем работы который должен и может быть простым, и будет простым.

Ну это надо постаратсо :)

например видел (правда не на Java), как велосипедостоители не подумали про n+1 problem, и вот уже вместо 2-х запросов приходит 102.

Понятность кода не зависит от фреймворка. Классический пример EJB (или JSF) — считался спасением всего чего только можно, а сейчас «фууу».

Не знаю, как был воспринят EJB2 в момент его появления, но там же сразу можно было догадаться, что что-то не то придумали по отношению плоезного кода к мусорно-шаблонному. В современной Java я такого не вижу, наоборот, все делают очень хорошо, продуманно и соблюдая DRY.

больше негатива от работы с таким кодом
С чего бы это?

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

Відповісти

Підтримати

Bogdan Shyiak

Mykola Gurov тролль 26.02.2012 20:06

Из CRUD и других задач, которые хорошо ложатся на ORM и популярные фреймворки, состоит значительная часть типичного веб-приложения (а иногда и все приложение :) ) .....

спорно. Кода для CRUDа может быть и относительно много, но самое интересное, challenging и собственно приносящее деньги как правило выходит за эту область. Процитирую умного дядьку:

... For starters, there’s no such thing as a website project. Every one is really an enterprise integration project with an HTML interface.

Відповісти

Підтримати

bsod

Назар Казымов Java Developer 26.02.2012 14:51

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

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 26.02.2012 15:07

EJB технология устарела

Это не совсем технология, это больше спека. JPA — это так же EJB, например. Поэтому дать рекомендацию «не учить» не могу :)

В многих вакансиях ее указывают.

В вакансиях много чего указывают. Если джун, то надо просто идти на пролом. ИМХО, если контора нормальная то не будут заострять на этом внимание, особенно для джуна. Второй момент, активное использование всего EJB, как правило, верный признак унылого проекта в стадии поддержки перед консервацией, хотя есть и исключения.

Відповісти

Підтримати

Назар Казымов

Mykola Gurov тролль 25.02.2012 13:05

Не принимай оффер не посмотрев код

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 25.02.2012 14:57

Требую на ДОУ кнопку «Поржал»

Відповісти

Підтримати

Mykola Gurov

Mykola Gurov тролль 26.02.2012 19:44

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

Відповісти

Підтримати

Bogdan Shyiak

Mykola Gurov тролль 26.02.2012 19:44

И показывал много раз.

Відповісти

Підтримати

Mykola Gurov

Bogdan Shyiak SE or Dev 26.02.2012 20:10

Я смотрел код на собеседовании.

Сколько времени вам надо чтобы оценить не маленький проект: более 100Мб исходников, 3+ года разработки, на выходе 3+ артефакта (включая минимум 2 ВАРника)?

Ну если это так потенциально пугает, а рынок позволяет, то почему слабо?

Простите, не понял данную фразу (какая-то она для меня не связная и не связана с моим комментом). Далеко не все могут показать код:
1) У аутсорсера могут быть жесткие контракты.

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

Відповісти

Підтримати

Mykola Gurov

Mykola Gurov тролль 26.02.2012 20:48

Это Вы про аудит. «Покажите» — на своем workstation, я сам даже клавиатуру и мышь трогать не буду. 10 минут более чем достаточно, чтобы понять о чем будет идти речь.

В более-менее серьезной конторе проблемы от такого просмотра не будет. И NDA в большинстве случаев не нарушит. Другой вопрос — параноидальные конторы. В любом случае задать вопрос ничто не мешает, может быть хорошим тестом на адекватность.

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 26.02.2012 21:17

10 минут более чем достаточно, чтобы понять о чем будет идти речь.

Кнопка «Поржал» нужна однозначно.

Небольшой пример:

Есть 10-летний проект в котором есть много костылей (за 10 то лет), при этом есть много вменяемого (а на мой взгляд хорошего) кода. За 10 минут вы (ну лично я уж точно) не сможете оценить качество кода. Этого времени хватит только чтобы понять качество одного «модуля» (логического куска) или чтобы бегло потыкаться по класам, но в таком случае нельзя провести нормально оценку качества кода (не вникая в то что он делает).

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

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

К примеру: Ваш проект полностью опенсорс? Где его можно посмотреть? Почему МС, Оракл, Гугл не открывают весь свой код (а то что открывают, как правило утилиты, а не корневая функциональность).

Відповісти

Підтримати

Mykola Gurov

Mykola Gurov тролль 26.02.2012 21:32

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

Опять же, у каждого вопроса есть область применимости, и врядли мы будем спрашивать про код на собеседовании в Гугль. И если в какой-то конторке поменьше нам адекватно скажут почему показать не могут — это тоже не проблема. Будут надувать щеки и съезжать — есть повод задуматься, насколько это соотносится с другими сигналами.

А умение тактично задавать нестандартные вопросы — это всегда хорошо для интервью. Так что я все еще не вижу что такого «ржачного» в моем совете в контексте вопроса bsod.

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 26.02.2012 21:59

Так что я все еще не вижу что такого «ржачного» в моем совете в контексте вопроса bsod.

2 момента:
1) Вполне адекватная контора может вам отказать в этом. И тут важнее как они ответят.

2) Оценить код за 10 мин вряд ли даст полноценные корректные результаты.

как и оценка подходящести кандидата или позиции.

На собеседовании оценивают человека, а его навыки программирования вы можете оценить довольно поверхностно. Точно так же если вам надо оценить проект, вы можете задавать вопросы и на основании ответов делать выводы.

А «покажите мне свой код» — это очень похоже на «Сделай тестовое задания». Далеко не каждый разработчик готов тратить время на то чтобы сделать тестовое задание хорошо — но это не значит что он плохой.

и врядли мы будем спрашивать про код на собеседовании в Гугль

Почему? В гугле нет гуанокода?

Спросить о коде может и стоит (но, ИМХО, лучше поговорить с разработчиками о проекте), но скорее чтобы посмотреть на реакцию. Но

Не принимай оффер не посмотрев код

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

Відповісти

Підтримати

Mykola Gurov

Mykola Gurov тролль 26.02.2012 22:20

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

Відповісти

Підтримати

Bogdan Shyiak

Serghei Gorodetki Development Manager в Oracle 28.02.2012 16:04

Аудит можно провести за несколько минут с помощью таких тулов как NDepend, к примеру. Общую картину точно составите.

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 28.02.2012 16:16

С вами долго разговаривают после просьбы установить левую приблуду, чтобы посмотреть код?

Відповісти

Підтримати

Serghei Gorodetki

Serghei Gorodetki Development Manager в Oracle 28.02.2012 16:30

Не только разговаривают, но и нанимают с хорошой прибавкой, когда видят какие метрики «эта левая приблуда» показывает в отчете. С надеждой что эти метрики улучшатся. Или ты предпочитаешь сказать «Ваш код — дерьмо и сопровождать я его не буду ни за какие деньги»?

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 28.02.2012 17:00

Или ты предпочитаешь сказать «Ваш код — дерьмо и сопровождать я его не буду ни за какие деньги»?

Вы тему и ветку читали?

Відповісти

Підтримати

Serghei Gorodetki

Serghei Gorodetki Development Manager в Oracle 28.02.2012 15:58

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

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 28.02.2012 16:19

Прочитайте всю ветку dou.ua/...ic/5350/#182652

я бы не был столь категоричным.

Я как раз не категоричен и говорю, что категоричная рекомендация:

Не принимай оффер не посмотрев код

Мало эффективна в общем случае.

Відповісти

Підтримати

Serghei Gorodetki

Mykola Gurov тролль 28.02.2012 22:58

вопрос стилистики и ее восприятия.

Відповісти

Підтримати

Bogdan Shyiak

proger 25.02.2012 00:20

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

в принципе это challenge с одной стороны, и более высоко оплачивается с другой (особенно если проект уже приносит деньги, сравните с каким нить стартапом, где деньги очень лимитированы)

а про ужасно — это субьективно, как по мне вся жаба ужасна и те, кто решил что живые люди должны редактировать хмл, и те, кто написал «суперуниверсальные либы» где для простых задач надо создать пять классов и имплементировать пятнадцать интерфейсов, прокляты навеки

Відповісти

Підтримати

Ruslan K 25.02.2012 01:21

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

при этом от кондидата обычно требуется
— разобраться
— пофиксить критичные баги исключительно костылями (быстро и дешево)
— писать еще в том же стиле (потому что вся команда к нему уже привыкла)

а приводить в чувство не требуется (долго и дорого)

Відповісти

Підтримати

proger

proger 25.02.2012 02:44

ну тут однозначного ответа нет, был проект, где я побыстрому свалил, хотя и согласны были переписывать, но там такая жуткая codebase была, что я решил не связываться

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

Відповісти

Підтримати

Ruslan K

Gremlin 25.02.2012 11:35

хороший код обходится недёшево, но в итоге он выгоднее чем икэбана из костылей.
вот только чтобы его получить нужно нанять девелоперов с опытом, и\или устаканить процесс разрабтки.
но д’эФфективным манагерам подай всё и сразу — за 2 недели «насобирай червонцев на рубль.»
отсорс. бессмысленный и беспощадный, развивающийся по индийской
модели.
зы: с другой стороны, благодаря маразму есть работа.

временами маразматическая.

Відповісти

Підтримати

proger

Bubo bubo 24.02.2012 23:39

мощные и удобные IDE, веб-разработка на Spring 3 — просто сказка

Попробуйте Play + Scala и эта «сказка» вам покажется адом из нагромождения костылей в которых без «мощной IDE» не разобраться.

Відповісти

Підтримати

reality_hacker 25.02.2012 07:29

А что как ОРМ используешь если не секрет?

Відповісти

Підтримати

Bubo bubo

Bogdan Shyiak SE or Dev 25.02.2012 11:02

В Плей, кажись, что-то свое есть.

Відповісти

Підтримати

reality_hacker

reality_hacker 25.02.2012 19:41

В плей кажется идет небольшая надстройка над jpa, но в scala-play к примеру они ее выпилили т.к. jpa-шные анотации не совместимы а с анотациями скала(пример неполной совместимости скала и джава кстати). Есть какие то скаловские орм, но он как по мне слишком инопланетянские.

Відповісти

Підтримати

Bogdan Shyiak

Bubo bubo 25.02.2012 11:24

К сожалению под сколько нибудь сложные задачи я ещё всё это не использовал, но я пробовал на GAE с objectify и siena.

Відповісти

Підтримати

reality_hacker

Нестор Иванович 25.02.2012 09:53

как раз о комбинации play и scala слышал очень плохие вещи. А плей просто так хвалили. Можно подробнее про ваш проект — интересно ?

Відповісти

Підтримати

Bubo bubo

Bogdan Shyiak SE or Dev 25.02.2012 11:04

как раз о комбинации play и scala слышал очень плохие вещи.

Подробнее пожалуйста.

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 25.02.2012 11:20

Сейчас попробую вспомнить
— Anorm — неюзабельные дрова без поддержки
— куча проблем совместимости java и scala в итоге писать в скала стиле почти не реально
-херовый ’хрупкий’ шаблонизатор ( может отвалится от лишнего ентера и тп)

Это мне конечно Рабиновичь напел но я ему склонен верить :)

Відповісти

Підтримати

Bogdan Shyiak

reality_hacker 25.02.2012 21:29

Ниче, им до плэй 2 еще 3 тикета осталось закрыть, возможно там получше все будет.

Відповісти

Підтримати

Нестор Иванович

Нестор Иванович 27.02.2012 05:13

хотелось бы верить, благо задумка у них хорошая.

Відповісти

Підтримати

reality_hacker

Bubo bubo 25.02.2012 11:13

Есть небольшой минус комбинации Play + Scala — большее время компиляции в но в дев моде это почти не чувствуется, ну и конечно шаблоны на скале много приятнее грувевских. К тому же Play 2.0 уже с родной поддержкой скалы, сбт и других приятных вещей.

Відповісти

Підтримати

Нестор Иванович

Bogdan Shyiak SE or Dev 25.02.2012 14:47

К тому же Play 2.0 уже

Еще не уже, а только РК2

Відповісти

Підтримати

Bubo bubo

Bubo bubo 25.02.2012 23:37

Ну конечно релиза не было ещё но шаблоны уже работают и я так сходу даже не смог поломать их компиляцию как в 1.2.4.

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 24.02.2012 22:49

есть все шансы нарваться на проект 10-летней давности (скажем, на голых сервлетах и JDBC) который отдали на аутсорс и который придется кому-то поддерживать.

И в чем проблема? Если заказчик адекватен, то прикручивайте хоть спринг10. Если заказчик не адекватен, то ни какой спринг вам не в радость будет. С продуктовыми точно так же, наверное даже проще.

Відповісти

Підтримати

bsod 24.02.2012 23:01

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

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 24.02.2012 23:24

но думаю

Меньше думайте, больше делайте.

за годы оброс костылями и больше похож на огромный карточный домик

Проекту чуть менее 10 лет. Оброс костылями (сем пару прикрутил :) ). При это никто не говорит «не трогай»; бери переделай, но ко всему надо подходить ответственно.

Минутка рекламы на ДОУ:
В Worldapp разработчики ограничены в выборе технологий только здравым смыслом.

Відповісти

Підтримати

bsod

bsod 24.02.2012 23:35

Меньше думайте, больше делайте.

Так ведь не получается ничего сделать: прикрутить опенсорсную библиотеку с либеральной лицензией заметно улучшающую некоторый аспект системы- нельзя; относительно безобидное но масштабное изменение системы — нельзя. Как-бы чего не поломалось, как-бы чего не вышло. Все уже работает, все уже приносит деньги, ничего трогать нельзя.

Відповісти

Підтримати

Bogdan Shyiak

Bogdan Shyiak SE or Dev 24.02.2012 23:36

заметно улучшающую некоторый аспект системы

Если заказчик не адекватен, то ни какой спринг вам не в радость будет.

Відповісти

Підтримати

bsod

Bogdan Shyiak SE or Dev 25.02.2012 00:26

прикрутить опенсорсную библиотеку с либеральной лицензией заметно улучшающую некоторый аспект системы

Если не секрет: Что это за либа и что за аспект?

Відповісти

Підтримати

bsod

bsod 25.02.2012 19:17

[лучше удалю во избежание :) ]

Відповісти

Підтримати

Bogdan Shyiak

Mizrah Kadima 24.02.2012 22:49

Поменяйте проект, поменяйте работу.

Відповісти

Підтримати

bsod 24.02.2012 23:13

Поменять проект не получилось (позиция компании: «Или делай что дают, или лучше сразу увольняйся», в принципе, понятная и правильная, зачем им проблемные сотрудники). Менять работу очень не хочется — и не время, и нет гарантии, что подобная ситуация не повториться в другом месте, аутсорс то один на всех.

Відповісти

Підтримати

Mizrah Kadima

Mizrah Kadima 24.02.2012 23:26

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

ИМХО, предлагайте переделывать проект, если нет — идите в другую компанию развиваться.

Відповісти

Підтримати

bsod

Ruslan K 25.02.2012 00:59

похожая проблема. что удивительно, древний код (2 таблички — 42 класса на портлет: Struts + Spring + Hibernate + чья-то доморощенная хрень, не считая JSP+JS) пишут сидящие рядом очень молодые (раза в 1.5 моложе меня) люди. и костылями их код нифига не обрастает. он с ними рождается ))) вопщем долго не выдержал. с учетом, что непосредственно с Java работать получалось не более 10% всего времени плюс еще пара менее значимых причин.. решил проблему радикально — уволился нахрен )) ну практически. 1 марта стану безработным. хожу, ищу работу. вижу в требованиях JSP, JS, HTML,CSS — отказываюсь сразу. ищу чего-нить интересного уже месяц. чем и когда все закончится — без понятия ))

Відповісти

Підтримати

bsod

Mizrah Kadima 25.02.2012 01:41

Правильно, на работу нужно ходить в удовольствие, а не на мучение.

Відповісти

Підтримати

Ruslan K

Java и тяжелое наследие

74 коментарі

Підписатись на коментарі