4 звезды на лоре, а резюме писать не научился?

покажи свой код на java

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

у меня есть резюме PHP-программиста на hh.ru, но есть мнение, что оно тут лишнее.

Есть другое мнение, что читать прикреплённые топики полезно и важно, там много ценных советов: https://www.linux.org.ru/forum/job/8161040.

Если ты хочешь перекваливицироваться в Java, то так и напиши в резюме, укажи то что ты умеешь и что делал. Ссылка на жид-хаб тоже не будет лишней.

А с таким постом ты только вереницу троллей соберёшь, а не работодателей.

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

//на выходных перепишу один свой маленький проект с PHP на Java и раскурю JBake, а то действительно

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

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

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

Белка дело говорит.

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

Без разницы. Программист если он действительно программист, может на любом языке программировать, пусть и обложившись справочниками. Используй свое PHP-портфолио.

к сведению принял, внесу правки. спасибо.

После двух лет работы PHP-программистом, хотелось бы участвовать в проектах побольше и посерьёзнее.

Меня сейчас закидают тухлыми помидорами, но ведь есть (наверно) серьёзные и крупные проекты и на PHP.

есть, но РНР к ним не очень предрасположен. и чем больше динамики в проекте, тем меньше там уместен РНР.

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

В силу вышеперечисленного, они либо страшные либо редкие.

Всегда думал что это так с любыми языками.

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

да, писать на них медленнее и больше, зато переделывать потом проще.

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

Ищу работу Java junior. https://github.com/$name

Только вот автору посоветовал бы годик самому что-нибудь попилить, и понять в чем дело, ибо знание основ ООП на джуниора не потянет никак. Да, все это ИМХО.

Да и если не можешь внятно раскрыть тему разницы между ArrayList и LinkedList, то пока рано. Конкретно этот вопрос не зазубришь, ибо могут и про Vector спросить. Да и много чего спросить могут.

да, писать на них медленнее и больше, зато переделывать потом проще.

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

В принципе, что PHP, что Python, что Java в плане поддержки и переписывания для меня где-то на одном, довольно высоком уровне. Правда, с поправкой на нормальное написание на PHP, а не кашу с HTML в одном флаконе :) Достаточно PSR/Composer-подходы из Java, когда один класс в одном файле, чтобы львиная доля проблем поддержки испарилась. Python тут, как раз, на том же уровне выходит потому что, с одной стороны, весьма строгий синтаксис, с другой — дурная привычка многих проектов совать серию классов в один файл.

Вот, например, Ruby в плане поддержки уже хуже. Синтаксис более мощный и потому провоцирует write-only стиль.

Perl же — совсем труба, очень быстро превращается в чистый W/O :)

для динамически языков задача «найти все использования метода SOME_CLASS.METHOD_XXX» - зачастую не реализуема, просто потому что их там можно генерить, потому что утиная типипзация и отличить METHOD_XXX одного класса от нужно практически не реально (особенно если использовать mixin)

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

исходя из этого рефакторинг (не только подобный) гораздо более трудоемкий нежели в тойже java

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

Ну, например, есть метод getSome(), требующий N аргументов. getSome(someUser,someObject,someContext)... Потребуется вписать ещё аргумент someData — нужен рефакторинг. Да ещё придётся постоянно в голове держать порядок аргументов (хотя IDE, конечно, может помочь). А в том же PHP можно просто заюзать getSome([]), указывая что нужно и когда нужно: getSome(['user'=>$user,'data'=>$data]). В результате аргументы наращивать можно с произвольной сложностью и использовать в произвольном порядке. Это отчасти снижает потребности в рефакторинге. Да, в Java можно использовать HashMap'ы и т.п., но синтаксис получаетчся намного менее удобным, особенно — обратные преобразования из боксинга. При чём нестрогость контроля аргументов в PHP компенсируется тем, что их перепутать сложнее, чем порядок аргументов в Java. Так и получается шило на мыло. В одних местах теряем, в других — приобретаем.

Ну, например, есть метод getSome(), требующий N аргументов. getSome(someUser,someObject,someContext)... Потребуется вписать ещё аргумент someData — нужен рефакторинг.

есть устоявшаяся практика - если есть вероятность то что придется его расширять то надо использовать специфический объект вместо тучи аргументов. То же самое если просто аргументов изначально много. Это без относительно ЯП.

При чём нестрогость контроля аргументов в PHP компенсируется тем

Был у меня случай на два дня из-за не строгости контроля аргументов: http://wayerr.livejournal.com/10438.html

если есть вероятность то что придется его расширять то надо использовать специфический объект вместо тучи аргументов

Если заранее знать, как будет развиваться проект, то и рефакторинг не потребуется :) Рефакторинг в первую очередь именно затыкание подобных проблем, про которые или заранее не подумали, или посчитали, что такая ситуация не возникнет.

Я видел как на практике функция от пары аргументов, которые расширять не планировалось, через год-другой разрасталась до ~15(!) аргументов :) При чём там дело ещё reflection'ом, ЕМНИП, усложнялось. Из-за чего отрефакторить нормально ни у кого руки просто не доходили :D

Был у меня случай на два дня из-за не строгости контроля аргументов

Я как-то прямо не представляю, в какой ситуации может понадобиться XOR с координатами. Сущности же несопоставимые :)

Если заранее знать, как будет развиваться проект, то и рефакторинг не потребуется :) Рефакторинг в первую очередь именно затыкание подобных проблем, про которые или заранее не подумали, или посчитали, что такая ситуация не возникнет.

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

Я видел как на практике функция от пары аргументов, которые расширять не планировалось, через год-другой разрасталась до ~15(!) аргументов :)

А у нас при первом же добавлении аргумента в функцию она переделывалась на принятие объекта (а то и вовсе интерфейса) предоставляющего аргументы.

Не говоря о том что функция с 15 аргументами - это чейто явный косяк.

Я как-то прямо не представляю, в какой ситуации может понадобиться XOR с координатами. Сущности же несопоставимые :)

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

Ынтерпрайз

Иди в Т-системс или Эксиджен. Там есть джава-школа. Потом 40 штук, непыльная работка. Но только стоит ли менять сорта говна? Я на питон перешел, модно молодежно.

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

Джуном очень тяжело найти работу на Java, практически невозможно. Нужно знать сервлеты, Hibernate/JPA, Spring и EJB. Я знаю сервлеты и JPA, немного Spring MVC и уже больше года не могу ничего найти, на hh.ru - 3 страницы отказов.

Советую изучить перечисленное, сделать свой проект, выложить на github или bitbucket и дать ссылку в резюме. Может, тебе повезет больше.

Это же деградация, с Java на гвидобейсик. Лучше бы на Scala перешел. Где-то видел на hh.ru вакансию скальщика, там предлагали зарплату 200к.

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

Писать надо грамотно, а не быдлокодить. Юнит-тесты, непрерывный рефакторинг, применение паттернов, составлять схему проекта на UML. И будет тебе счастье.

Писать надо грамотно, а не быдлокодить.

Лучше быть здоровым и богатым, чем бедным и больным.

Юнит-тесты, непрерывный рефакторинг, применение паттернов, составлять схему проекта на UML. И будет тебе счастье.

В жизни чаще все заканчивается срывом сроков.

(Признаться, чтобы еще и схемы в UML делали этого я в своей практике вообще не встречал, хотя, подозреваю, что такие прецеденты есть.)

в процессе изучения. я скорее даже не джун, а интерн(стажер). и запросы у меня соответствующие.