нет) это 2 проекта между которыми ты переключаешься. но они не открыты одновременно. они не могут использовать как общий ресурс например третий проект.
это то-же самое, что открыть 2 проекта в 2-х разных окнах. только переключаешься ты между ними не через альт-таб, а верхним перелючателем, который вы показали.
для сравнения: в эклипсе у меня например в пространстве открыто (условно) 3 проекта (в реальности конечно больше). один - это модуль в исходных кодах, который используется двумя другими. например это может быть общий модуль с описанием сущностей и 2 проекта - например сервер, и тестовый клиент который продергивает запросы по заданному сценарию.
я просто правлю сущность, и перезапускаю тест. а сервер эклипс сам передеплоивает на томкат, причем частично и нагорячую - только те классы что изменились.
и все три у меня открыты одновременно, в одном рабочем пространстве. мне не надо между ними "переключаться".
Ну может для webStorm оно и работает. А вот для "IntelliJ IDEA" - нет. Как минимум текущая доступная версия "2024.*.* (Community Edition)" демонстрирует совершенно иное поведение.
С жабой не работаю, поэтому нюансов модулей не знаю.
Вот и ответ. Очень рад за вас, как пхпшников, но увы.
Ваши представления об idea, которая java-ide, в данном случае не соответствуют действительности.
Открыть 2 java проекта в idea, без костылей с псевдо-модулями - нельзя. А в конфигурации 2 проекта с общим модулем - как это можно без проблем сделать в "классических" IDE и том же эклипсе - и с костылями в идее выглядит геморройным квестом.
Ну, или показывайте пошаговое описание, и именно в "IntelliJ IDEA 2024.*.* (Community Edition)".
Во первых, какая у вас, версия идеи ? )) у меня "IntelliJ IDEA 2024.1.2 (Community Edition)" и там нет такой кнопочки в меню открытия проекта.
Поиск по сети по картинке выдал какой-то пост в телеграмме про PhpStorm ( https://telegram.me/s/beerphp/62?q=%23packages ) и, насколько я понял, там речь идет об открытии нескольких репозиториев, причем как модулей к проекту.
Это несколько сильно другое, чем несколько проектов в одном рабочем пространстве. Это несколько модулей к одному проекту.
А в Эклипсе, например, я могу открыть совершенно разные даже не связанные проекты, причем даже под разные платформы. И не "фазовращать" всю эту конструкцию через настройки проекта, как описано в постах выше и как упоминал @mr-garrick ... а просто "открыть".
Например, пока разработка под андроид велась в эклипсе, у меня была связка 2-х прекрасных java-проектов, один под андроид, второй серверный - два проекта, использующих один общий модуль с объявлением сущностей. У меня в Эклипсе было 3 проекта - "контейнер с общим кодом и сущностями", и 2 "запускаемых" проекта. Я просто правил атрибуты сущностей, и перезапускал проекты - что бы проверить связку клиента и сервера с новым набором атрибутов. Это, знаете ли, тупо удобно ).
И как вы понимаете, я описываю вариант, когда не "несколько модулей к одному проекту", а "2 проекта с общим модулем".
В описанных выше сценариях для Идеи - такое сделать невозможно. А вот Эклипсе - "проще паренной репы".
И так. коллега. Расскажите, пожалуйста подробнее. 1) Что надо сделать что бы в Идее открыть несколько проектов? и какой именно версии идеи и как её получить ? 2) Причем открыть не как модули одного проекта, а как 2 проекта, может даже с одним общим модулем ? 3) И как вы получили продемонстрированный вами скриншот ?
Я говорю про "несколько проектов в одном окне", фиче, которая визуально всего-лишь добавляет в дереве "Project" ещё один уровень вложенности в дереве - проект. и эта фича не может "жрать место по вертикали". Ну как минимум так это сделано в Эклипсе или нетБинсе )
Нет в идее многопроектности. Как минимум не было до последних релизов. У меня например сейчас стоит "IntelliJ IDEA 2024.1.2 (Community Edition)" и там нет такого скриншота, как показано у PsychodelEKS ниже. У меня только 3 кнопки, без [Attach].
Вы ... "слегка не то... показываете". В показываете группировку проектов на стартовом окне. Это "немного" другое чем "открыть несколько проектов в рабочем пространстве".
Вот ваш коллега постом ниже - уже показывает более адекватно. т.е. получается... они, наконец, "осилили"? ну хорошо. только когда? месяц назад? два?
Для "не вранья" стоит бы сказать с какого времени в идее появилась мультипроектность в рабочем пространстве, и как именно она выглядит? ))
Ну и по фичам как именно это выглядит, что умеет? Эклипс, например, умеет у мавеновского многомодульного проекта - если модуль исходниками загружен в рабочее пространство - собирать эти мавеновские модули сам, без мавена, "мавен-инстала" и затрагивания локального репозитория, и включать обновленные собранные классы в сборку исходного - и это происходит практически мгновенно, а не с той скоростью как это делает мавен. А что там у идеи?
"Лошадь сдохла - слезь." Говорят, мудрость есть такая.
Оттягивать неизбежный переход на другие IDE некоторое время, конечно, получится. Но как долго ?
И тут важно понимать, что с IDE ситуация совсем не как с ютубом - в других IDE инструментарий есть, и он такой же рабочий и функциональный, решает такие же проблемы, а местами и даже побольше.
Лучше бы написали как людям, которые привыкли работать в Idea слезть с неё, и освоиться в других IDE. Как найти привычные или аналогичные инструменты в том же Eclipse или Netbeans.
Ни одна здравомыслящая компания не будет позволять вам использовать нелицензионный софт на рабочем месте.
А завязывать процесс работы на хаки и полулегальные сценарии, которые ещё и могут завтра не заработать - это вообще сумасбродство.
Почему завтра у вас опенсорсная идея может накрыться медным тазом ? Потому что "типа опенсорс завязанный на одну частную компанию" - легко закрывается от доступа извне. Посмотрите на Qt - сейчас можно получить сорсы только из линуксовых реп и те, кажется, не последних версий. И только под Линукс.
Вспомните историю : тот же Соурсфордж запрещал доступ разработчикам из Ирана и Ирака. Даже Гитлаб таким грешил.
С чего вы решили что джетбрейнзы позволят скачивать и использовать "опенсорс" версию коммерческого продукта? Они коммерческие обязательства не исполняют и блокируют оплаченное, а вы забесплатно ждёте? нуну...
Ну и напомню : на работе вы всё равно маловероятно будете работать на идее - см выше про здравомыслящую компанию.
_______
Добавлю от себя: если вы джавист - то вам рано или поздно придется осваивать мультипроектную парадигму работы с кодом (назовем это так) когда у вас несколько проектов открыто исходным кодом одновременно в одной рабочей среде.
И с "инструментом хорошо показаашим себя вам на уровне курсовых работ" Idea - вам ... "не то что бы по пути". Многие не согласятся и продолжат пилить свои утилитки, ну и я рад за них, но сейчас не про них, а про удобную организацию чуть более сложных проектов. Например когда вы подключаете общий модуль в виде исходного кода, а не как скомпиленный сторонний джарник и правите одновременно и свой проект и патчи в общий модуль делаете. И собираете как одно целое, а не взвесь библиотек в мавен репозитории, без "мавен инстала" к примеру. и т.д.
Я бы рекомендовал не кочевряжиться и, наконец, освоить Eclipse.
Вроде как в Netbeans тоже похожая организация проектов, но я его не щупал.
Письменный экзамен IPMA - на русском. Совнет - национальная организация IPMA - и всё, в том числе и требования к квалификации - на русском.
Как минимум до уровня собеседования.Но "собеседование на французском" - это уже уровень A - управление международными программами. Ну и участие в этих программах на соответствующем уровне надо подтверждать, лет за 10 минимум кажется - нам с вами до этого далеко)
На уровень D - это 1 день, письменный экзамен на русском, ничего подтверждать не надо (ну может кроме условного стажа, что вы хотя-бы год или два вообще работаете и участвовали хоть в какой-то проектной деятельности - уточните текущие требования в Совнет).
_______________ Насчет крыжения галочек на тему PMI - ничего не скажу. Там, может, вопросы и на английском.
RUP - это именно методология - это методика создания методики управления проектом
Тут важно уточнить что не "проектом вообще", а "процессами разработки ПО" - которые являются частью процессов проекта. Можно было бы сказать что "проектом разработки ПО", но тогда придется выкинуть "за скобки" кучу процессов, типа взаимоотношения с клиентами или управление договорами и пр. Какое-нибудь "управление портфелями проектов" - так и вообще штука из "перпендикулярной реальности" по отношению к этому. Потому всё же "процессов разработки ПО".
ICB, NCB, PMBoK - это именно свод знаний и систематизация всех вариантов
ICB и NCB - всё же не свод знаний в том виде как это дает PMBoK (поправьте меня?). ICB и NCB - это перечень требований о том, что должен знать и уметь специалист по управлению проектами.
Сами знания - они во вне - в "окружающих источниках" (читайте книги, разные) а умения - достигаются на практике.
Добавлю что экзамен в IPMA - длится от 1 до 3-х дней на разные ступени. Письменный 4-х часовой экзамен с открытыми вопросами в первый день (для младшей ступени этого достаточно). Имитационная игра во второй, и собеседование (на английском, французском или кажется немецком?) в третий день.
вы, меня, "конечно извините" за то что сейчас скажу, но информация в статье... ну не знаю... скажем так... ложна. ?...
Сначала про даты и хронологию. они не верны.
1965год. начинается история международной ассоциации управления проектами - IPMA. International Project Management Association. Веха из разряда "слона то я и не приметил".
1969 год. начинается история PMI. Project Management Institute. Как человек, "сдавший экзамены IPMA", обязательно упомяну, что это американская организация, которая начала заявлять о себе как о "международной" много позже.
Про PRINCE2 много не скажу, кроме того, что таких национальных стандартов и подходов по управлению проектами наподобии "принца" - пред пруди было в истории. И европейских, и советских и американских, Захотите, вытащу Совнетовские конспекты и дам вам развернутую справку.
А кучка российских гостов? и я не только про 34-ю и 19-ю серию, всем набившую оскомину, но и про кучку всяких "ИСО МЭК" по управлению проектами и просто по менеджменту и процессам.
Теперь про "некорректные противопоставления".
Ставить в один ряд "конкретный подход", и базы знаний по управлению проектами... - это даже не теплое с мягким. Это мешать "котлеты", "мухи", и... "красное". добавив, что "в противовес им есть "холодное".
Тот же Prince2, Scrum, Agile, экстремальное программирование,(про RUP отдельно, потому что это методология по управлению проектами) - это конкретные методики и подходы.
В отличии от них - выпускаемые IPMA и PMI материалы - IPMA ICB (международные требования к компетенции), IPMA NCB (национальные требования к компетенции) и PMI PMBoK (книга знаний по управлению проектами) не содержат конкретных указаний "как надо" - они включают в себя и систематизируют накопленные сведения о разных методиках, подходах, инструментах и знаниях по управлению проектами. И водопад, и итеративный подход, и спирали, и четкое планирование, и адаптивное когда детализируемя по ходу развития истории - это всё там есть. Как конкретные примеры и знания о том, что так можно делать.
Прочитайте хотя бы "Руководство по проектному управлению" Родни Тернера и узнайте про "планирование по вехам" и "планирование набегающей волной" и и поймите что "итеративный подход" - это ... "частный случай" из кучи промежуточных вариантов организации процессов от жесткого планирования, до гибкого адаптивного процесса.
ICB, NCB, PMBoK - это именно свод знаний и систематизация всех вариантов - и больших тяжеловесных и маленьких легковесных, иногда с описанием того где какие методы хорошо подходят.
Кстати, смею сказать что "кибернетический подход" взятый в IPMA - имхо -более адекватен и системен чем древовидная структура процессов и подпроцессов PMI. И на экзаменах IPMA (взять тот же письменный экзамен) - оцениваются и качества менеджера - например риторика и умение излагать мысли на бумаге. Чего невозможно достичь крыженеием галочек в на тесте по PMI.
Теперь про RUP.
Ну какой нафиг IBM и Майкрософт?! Что за бред, извините меня ? Компания Rational начала выпускать свою унифицированную методологию по управлению программным проектом задолго до того как их купил IBM. А о майкрософте вообще речи нет.
И , RUP - это именно методология - это методика создания методики управления проектом. Это большой систематизированный шведский стол инструментов , "Процессный Фреймворк" в котором вы выстраиваете тот вариант процесса который вам нужен именно на этом проекте. можно построить, и главное - дать описание команде процесса, и что то неформальное легковесное с требованиями на салфесках, или какой нибудь аналог "extrim prigramming". А можно сделать тяжеловесное, с утверждением и согласованием каждого артефакта, трассировкой требований от фичи до теста и программного модуля.
А вы назвали это фактически тяжеловесным подходом и противопоставили какому то скруму.
Да как так то ?!
В общем отвечая на заголовок вашей статьи : всё с этим вопросом нормально. Это, простите, "просто вы не в курсе".
Идите, пожалуйста, для начала - читайте по программной разработке RUP (причем желательно 6й руп, до того как его испортила IBM. можно ещё OpenUP почитать что бы увидеть как в RUP можно описать и вариант процесса по 34-му ГОСТ, и Agile - используя один и тот же подход к описанию процессов, в одном типе диаграмм), а по управлению проектами - упомянутую выше книгу Дж Родни Тернера "Руководство по проектному управлению".
После, желательно, пройдите курсы по управлению проектами в Совнете - национальной организации IPMA, разрабатывающей наш, российский NCB. Там вам систематизированные сведения дадут не только об истории? но и текущем состоянии вопроса. И да будет всем счастье и не будет таких статей.
ну, с виндоус-то, предположим, ситуация вполне ясно-понятная. и в плане засилья, и в плане что с этим делать, и почему так, и как-оно-сейчас, и прогресс видно-и-слышно...
Обязательно надо начать инициативу "Whitespace for Linux Core" !
Смотрите - есть целый план: рекламировать безопасность и надежность, хвалить за простоту синтаксиса и синтаксический сахар; призывать всех переходить на "пробельчики"; пытаться банить в онлайн-конференциях неугодных разработчиков; через пару лет - слиться в туман сославшись на разные не-технические причины, и ретроградизм кодеров. XD))
если грубо, то у меня возникает впечатление что "носятся с rust, как с дураки с писаниной торбой". да и говорят про "не технические вопросы", а сами ничего не делают в области снятия долговременных технических рисков.
почему я это утверждаю? потому что вместо того, что бы заняться снятием долговременных технических рисков с языком - а именно : подготовка стандарта языка, организация процесса тестирования "альтернативных реализаций языка" и "его-же новых версий" на предмет соответствия уже существующему стандарту - эти люди "на полном серьезе" рассуждают в бложиках, что им важнее "инклюзивный и гибкий процесс развития языка". (бложик где это звучало сейчас не подскажу, пишу с мобилы, но для интересующихся - дам в комментариях.)
стандартизация языка разработки на котором пишется система, контролируемость, плавность процесса его развития - это критичный для любой большой системы фактор на долгом периоде.
вспомним историю : хоть питон и руби. когда новые версии языка не позволяли перенести на них на них код уже написанной системы. у питоновцев, к их чести, совести хватило не бросить старую версию и она до сих пор её тянут. а у разработчика руби - не хватило - он прекратил поддержку старых версий, "и да он знает что многие не могут перейти на новую версию потому что это надо глубоко перерабатывать систему".
ну и вот : подумайте : что будет с ядром линукса, когда в языке, не обложенном стандартами, тестами, контролируемым процессом принятия изменений, вдруг, "по решению инклюзивного сообщества" решат что надо что-то критически поменять, сломав совместимость со старой версией? а вы уже всё ядро уже переписали на этот язык и под его старую версию. что будет ?
сначала перед вами станет проблема рефакторинга и снова переписывания всего - а это время и деньги; а потом - станет проблема безопасности, потому что когда производитель прекратит выпуск патчей безопасности под старый компилятор - вы сядете в лужу.
и отсутствие в rust альтернативных совместимых компиляторов, в том числе и от коммерческих производителей - это важный признак неготовности языка и среды его поддержки к использованию в больших и серьезных проектах.
а теперь хотите страшного? представьте в сообществе rust пару менеджеров майкрософта ? и на фоне наличия описанных технических рисков - вся эта "шумиха и движ" по части переписывания ядра Линукс на руст, ... тут как бы вообще создается впечатление целенаправленного саботажа.
а неоднократное уже появление "истерик" по поводу "нас не оценили мы ходим" (не первый раз же происходит , кстати) - вообще возникают ассоциации совсем с другими, процессами.
повторюсь : если осуществить описанный выше сценарий со "сломом обратной совместимости языка" в условиях, когда на нем уже переписано ядро - вся линукс-экосистема сядет в лужу.
и пока у языка нет стандарта, механизмов проверки соответствия стандарту и процесса принятия изменений с учетом этого стандарта - эти риски не то что не иллюзорны - именно к ним, фактически, целенаправленно, различные руст-активисты и пытаются привести. осознанно или нет - это другой вопрос.
так что не надо называть разработчиков ядра "ретроградами" и "староверами". они то как раз очень хорошо понимают к чему может привести переход на язык разработки, у которого нет стабильности и хоть каких-то гарантий по части ровного "недерганного" развития.
вам всего лишь говорят, что заявления о "фрагментированности экосистемы" - мягко говоря, несостоятельны. (наличие множества совместимых между собой альтернативных джавамашин - это никак не фрагментированность. ключевое тут - "полностью совместимых между собой")
аналогично не соответствует действительности и мнение про "закрытость языка" по лицензиям - вы путаете официальную сборку джавамашины от оракла , и сам язык java (как набор стандатов, описаний и требований к логическому механизму).
вы же, очень похоже, к сожалению, не слышите оппонента, его аргументов и не пытаетесь понять о чем он вам говорит.
в статье упущены ключевые фичи языка и стратегии его поддержки, без которых язык не стал бы едва ли не единственным языком написания больших бизнес приложений, и тем явлением которое мы сегодня имеем.
собственно, отсутствие этих вещей у многочисленных "убийц джавы", и стало причиной того что все они - на обочине истории, а джава как была, ведущим языком для бизнес-приложений, так и остается.
первое: наличие четкого описания работы языка.
описания достаточного для того, что бы можно было сделать две ключевые вещи:
а) сделать полностью совместимую альтернативную реализацию компилятора
б) провести тест на совместимость различных компиляторов.
собственно это и есть вторым важным пунктом :
наличие процесса тестирования на совместимость компиляторов. как компиляторов разных версий (обеспечение обратной совместимости и неизменности работы вашего кода на новых версиях языка/компилятора, так и кроссплатформенная совместимлсть )
причем у sun, процесс тестирования был закреплён юридически и без этого нельзя было объявить ваш компилятор - джавой.
помните историю такого поделия майкрософта как J# ? и куда оно "внезапно делось"?
подскажу: юристы sun выиграли дело у мелклмягких и запретили им создавать несовместимую со стандартом версию "java" (там дальше пошла цепочка событий "откуда есть пошел c#, и нафига и кому он был нужен", но это совершенно другая истоия). причем произошло это очень быстро - буквально год или около того. издательство bhv успело даже книжек понавыпускать... а потом их "как смыло".
именно ~100% обратная совместимость (обеспеченная наличием стандарта и тестов) и статическая типизация - и сделали язык тем незаменимым и фактически безальтернативным средством для написания бизнес приложений с длительным жизненным циклом, которым java сегодня и является.
это, а не "какие то там свойства языка".
всё, собственно, потому, что у бизнеса который вкладывает деньги в большой софт на много-много лет - нет никакого желания тратить деньги на рефакторинг кода, после выхода новой версии компилятора.
с джавой процесс переезда на новую версию компилятора - максимально безболезненный (ps: если, конечно, вы "находитесь в пределах стандарта языка", не пользуете недокументированные фичи типа доступа к приватным методам через рефлекшен как было у многих с 6й джавай, или не пытаетесь заигрывать с байткодом ... но это тоже долгая история и повод для холиваров долгими зимними вечерами у камина)
—————
вы скажете что же js и с/с++ ? прекрасный выбор. есть стандарты, есть возможность проверить компилятор, но с обратной и/или кроссплатформенной совместимостью не так как у джавы. хорошие языки для своей ниши - скриптование в браузере (именно скриптование, а не то тяжеловеское безумие с концепцией "js новый ассемблер" которое сегодня творится) и написание близкого к железу кода. это, а не написание приложений с бизнес логикой и длительным жц.
котлин? этот очередной недоубийца джавы (без стандарта, альтернативных реализаций и тестирования совместимости) тоже ушел бы на обочину истории, но оказался нужен гуглу как запасной аэродром от нападок менеджеров оракла по поводу джавы. собственно, в мобильной разработке, с коротким жц приложений (вышла новая версия телефона - надо всё переписывать) - ему вполне себе комфортно. тут многие языки не соблюдающие принципов совместимости и наличия полного описания будут прекрасно жить.
"К тому же на андроиде приложения подсанкционных банков тоже выпиливают." - вы зачем "забываете", что это только гугль выпиливает ?
Для андроида - есть еще Самсунг-стор, Магазинчик хуавея, банальные apk с сайта сбера... в общем куча альтернатив.
ВТБ и Сбер прекрасно "переустаналиваются в один клик" из самсунговского магазина, даже настройки менять не надо. Я так и сделал, например.
А под яблоко - эппл-магазин - это вообще единственный способ распространять своё приложение. Нет в ябломагазине - нет вообще нигде. Так что ваше сравнение - совершенно не к месту.
нет) это 2 проекта между которыми ты переключаешься. но они не открыты одновременно.
они не могут использовать как общий ресурс например третий проект.
это то-же самое, что открыть 2 проекта в 2-х разных окнах. только переключаешься ты между ними не через альт-таб, а верхним перелючателем, который вы показали.
для сравнения: в эклипсе у меня например в пространстве открыто (условно) 3 проекта (в реальности конечно больше). один - это модуль в исходных кодах, который используется двумя другими. например это может быть общий модуль с описанием сущностей и 2 проекта - например сервер, и тестовый клиент который продергивает запросы по заданному сценарию.
я просто правлю сущность, и перезапускаю тест. а сервер эклипс сам передеплоивает на томкат, причем частично и нагорячую - только те классы что изменились.
и все три у меня открыты одновременно, в одном рабочем пространстве. мне не надо между ними "переключаться".
Ну может для webStorm оно и работает. А вот для "IntelliJ IDEA" - нет. Как минимум текущая доступная версия "2024.*.* (Community Edition)" демонстрирует совершенно иное поведение.
в указанном окне в идеее нет кнопки attach.
Простите но повторю ответ данный вашему коллеге, тоже пользователю WebStorm: https://habr.com/ru/companies/spring_aio/articles/852526/comments/#comment_27480202
"Увы, но ваши представления об idea, java-ide, в данном случае, не соответствуют действительности.".
Итог: Тов. Java-разработчики, не кочевряжтесь. Переходите на Эклипс, Нетбинс или другую классическую IDE.
"Лошадь сдохла - слезь"(c).
Вот и ответ. Очень рад за вас, как пхпшников, но увы.
Ваши представления об idea, которая java-ide, в данном случае не соответствуют действительности.
Открыть 2 java проекта в idea, без костылей с псевдо-модулями - нельзя. А в конфигурации 2 проекта с общим модулем - как это можно без проблем сделать в "классических" IDE и том же эклипсе - и с костылями в идее выглядит геморройным квестом.
Ну, или показывайте пошаговое описание, и именно в "IntelliJ IDEA 2024.*.* (Community Edition)".
Тогда вы, пожалуйста, ответьте на вопрос заданный @PsychodelEKS
вот тут: https://habr.com/ru/companies/spring_aio/articles/852526/comments/#comment_27458508
1) Что надо сделать что бы в Идее открыть несколько проектов? и какой именно версии идеи и как её получить ?
2) Причем открыть не как модули одного проекта, а как 2 проекта, с разными "групповыми" помниками, - использующими один общий модуль ?
3) И как получилть продемонстрированный @PsychodelEKS скриншот ?
Потому, что, есть стойкое впечатление, что вы путаете "несколько модулей к одному проекту" и "2 независимых проекта с общим модулем".
Коллега, давайте разберемся подробнее.
Во первых, какая у вас, версия идеи ? )) у меня "IntelliJ IDEA 2024.1.2 (Community Edition)" и там нет такой кнопочки в меню открытия проекта.
Поиск по сети по картинке выдал какой-то пост в телеграмме про PhpStorm ( https://telegram.me/s/beerphp/62?q=%23packages ) и, насколько я понял, там речь идет об открытии нескольких репозиториев, причем как модулей к проекту.
С моей точки зрения, как человека далекого от погружения в особенности настройки Идеи - это как-то отдаленно похоже на то, как написано тут: https://www.jetbrains.com/guide/java/tutorials/import-project/open-multiple-projects
Это несколько сильно другое, чем несколько проектов в одном рабочем пространстве.
Это несколько модулей к одному проекту.
А в Эклипсе, например, я могу открыть совершенно разные даже не связанные проекты, причем даже под разные платформы. И не "фазовращать" всю эту конструкцию через настройки проекта, как описано в постах выше и как упоминал @mr-garrick ... а просто "открыть".
Например, пока разработка под андроид велась в эклипсе, у меня была связка 2-х прекрасных java-проектов, один под андроид, второй серверный - два проекта, использующих один общий модуль с объявлением сущностей. У меня в Эклипсе было 3 проекта - "контейнер с общим кодом и сущностями", и 2 "запускаемых" проекта. Я просто правил атрибуты сущностей, и перезапускал проекты - что бы проверить связку клиента и сервера с новым набором атрибутов.
Это, знаете ли, тупо удобно ).
И как вы понимаете, я описываю вариант, когда не "несколько модулей к одному проекту", а "2 проекта с общим модулем".
В описанных выше сценариях для Идеи - такое сделать невозможно.
А вот Эклипсе - "проще паренной репы".
И так. коллега. Расскажите, пожалуйста подробнее.
1) Что надо сделать что бы в Идее открыть несколько проектов? и какой именно версии идеи и как её получить ?
2) Причем открыть не как модули одного проекта, а как 2 проекта, может даже с одним общим модулем ?
3) И как вы получили продемонстрированный вами скриншот ?
Мы, кажется, снова о чем-то разном говорим.
Я говорю про "несколько проектов в одном окне", фиче, которая визуально всего-лишь добавляет в дереве "Project" ещё один уровень вложенности в дереве - проект. и эта фича не может "жрать место по вертикали".
Ну как минимум так это сделано в Эклипсе или нетБинсе )
Нет в идее многопроектности. Как минимум не было до последних релизов.
У меня например сейчас стоит "IntelliJ IDEA 2024.1.2 (Community Edition)" и там нет такого скриншота, как показано у PsychodelEKS ниже. У меня только 3 кнопки, без [Attach].
Вы ... "слегка не то... показываете".
В показываете группировку проектов на стартовом окне.
Это "немного" другое чем "открыть несколько проектов в рабочем пространстве".
Вот ваш коллега постом ниже - уже показывает более адекватно.
т.е. получается... они, наконец, "осилили"? ну хорошо. только когда? месяц назад? два?
Для "не вранья" стоит бы сказать с какого времени в идее появилась мультипроектность в рабочем пространстве, и как именно она выглядит? ))
Ну и по фичам как именно это выглядит, что умеет? Эклипс, например, умеет у мавеновского многомодульного проекта - если модуль исходниками загружен в рабочее пространство - собирать эти мавеновские модули сам, без мавена, "мавен-инстала" и затрагивания локального репозитория, и включать обновленные собранные классы в сборку исходного - и это происходит практически мгновенно, а не с той скоростью как это делает мавен. А что там у идеи?
"Лошадь сдохла - слезь." Говорят, мудрость есть такая.
Оттягивать неизбежный переход на другие IDE некоторое время, конечно, получится. Но как долго ?
И тут важно понимать, что с IDE ситуация совсем не как с ютубом - в других IDE инструментарий есть, и он такой же рабочий и функциональный, решает такие же проблемы, а местами и даже побольше.
Лучше бы написали как людям, которые привыкли работать в Idea слезть с неё, и освоиться в других IDE. Как найти привычные или аналогичные инструменты в том же Eclipse или Netbeans.
Ни одна здравомыслящая компания не будет позволять вам использовать нелицензионный софт на рабочем месте.
А завязывать процесс работы на хаки и полулегальные сценарии, которые ещё и могут завтра не заработать - это вообще сумасбродство.
Почему завтра у вас опенсорсная идея может накрыться медным тазом ? Потому что "типа опенсорс завязанный на одну частную компанию" - легко закрывается от доступа извне. Посмотрите на Qt - сейчас можно получить сорсы только из линуксовых реп и те, кажется, не последних версий. И только под Линукс.
Вспомните историю : тот же Соурсфордж запрещал доступ разработчикам из Ирана и Ирака. Даже Гитлаб таким грешил.
С чего вы решили что джетбрейнзы позволят скачивать и использовать "опенсорс" версию коммерческого продукта? Они коммерческие обязательства не исполняют и блокируют оплаченное, а вы забесплатно ждёте? нуну...
Ну и напомню : на работе вы всё равно маловероятно будете работать на идее - см выше про здравомыслящую компанию.
_______
Добавлю от себя: если вы джавист - то вам рано или поздно придется осваивать мультипроектную парадигму работы с кодом (назовем это так) когда у вас несколько проектов открыто исходным кодом одновременно в одной рабочей среде.
И с "
инструментом хорошо показаашим себя вам на уровне курсовых работ" Idea - вам ... "не то что бы по пути". Многие не согласятся и продолжат пилить свои утилитки, ну и я рад за них, но сейчас не про них, а про удобную организацию чуть более сложных проектов. Например когда вы подключаете общий модуль в виде исходного кода, а не как скомпиленный сторонний джарник и правите одновременно и свой проект и патчи в общий модуль делаете. И собираете как одно целое, а не взвесь библиотек в мавен репозитории, без "мавен инстала" к примеру. и т.д.Я бы рекомендовал не кочевряжиться и, наконец, освоить Eclipse.
Вроде как в Netbeans тоже похожая организация проектов, но я его не щупал.
Письменный экзамен IPMA - на русском. Совнет - национальная организация IPMA - и всё, в том числе и требования к квалификации - на русском.
Как минимум до уровня собеседования.Но "собеседование на французском" - это уже уровень A - управление международными программами. Ну и участие в этих программах на соответствующем уровне надо подтверждать, лет за 10 минимум кажется - нам с вами до этого далеко)
На уровень D - это 1 день, письменный экзамен на русском, ничего подтверждать не надо (ну может кроме условного стажа, что вы хотя-бы год или два вообще работаете и участвовали хоть в какой-то проектной деятельности - уточните текущие требования в Совнет).
_______________
Насчет крыжения галочек на тему PMI - ничего не скажу. Там, может, вопросы и на английском.
пара "уточнений опосля":
Тут важно уточнить что не "проектом вообще", а "процессами разработки ПО" - которые являются частью процессов проекта. Можно было бы сказать что "проектом разработки ПО", но тогда придется выкинуть "за скобки" кучу процессов, типа взаимоотношения с клиентами или управление договорами и пр. Какое-нибудь "управление портфелями проектов" - так и вообще штука из "перпендикулярной реальности" по отношению к этому. Потому всё же "процессов разработки ПО".
ICB и NCB - всё же не свод знаний в том виде как это дает PMBoK (поправьте меня?).
ICB и NCB - это перечень требований о том, что должен знать и уметь специалист по управлению проектами.
Сами знания - они во вне - в "окружающих источниках" (читайте книги, разные) а умения - достигаются на практике.
Добавлю что экзамен в IPMA - длится от 1 до 3-х дней на разные ступени. Письменный 4-х часовой экзамен с открытыми вопросами в первый день (для младшей ступени этого достаточно). Имитационная игра во второй, и собеседование (на английском, французском или кажется немецком?) в третий день.
вы, меня, "конечно извините" за то что сейчас скажу, но информация в статье... ну не знаю... скажем так... ложна. ?...
Сначала про даты и хронологию. они не верны.
1965год. начинается история международной ассоциации управления проектами - IPMA. International Project Management Association. Веха из разряда "слона то я и не приметил".
1969 год. начинается история PMI. Project Management Institute. Как человек, "сдавший экзамены IPMA", обязательно упомяну, что это американская организация, которая начала заявлять о себе как о "международной" много позже.
Про PRINCE2 много не скажу, кроме того, что таких национальных стандартов и подходов по управлению проектами наподобии "принца" - пред пруди было в истории. И европейских, и советских и американских, Захотите, вытащу Совнетовские конспекты и дам вам развернутую справку.
А кучка российских гостов? и я не только про 34-ю и 19-ю серию, всем набившую оскомину, но и про кучку всяких "ИСО МЭК" по управлению проектами и просто по менеджменту и процессам.
Теперь про "некорректные противопоставления".
Ставить в один ряд "конкретный подход", и базы знаний по управлению проектами... - это даже не теплое с мягким. Это мешать "котлеты", "мухи", и... "красное". добавив, что "в противовес им есть "холодное".
Тот же Prince2, Scrum, Agile, экстремальное программирование,(про RUP отдельно, потому что это методология по управлению проектами) - это конкретные методики и подходы.
В отличии от них - выпускаемые IPMA и PMI материалы - IPMA ICB (международные требования к компетенции), IPMA NCB (национальные требования к компетенции) и PMI PMBoK (книга знаний по управлению проектами) не содержат конкретных указаний "как надо" - они включают в себя и систематизируют накопленные сведения о разных методиках, подходах, инструментах и знаниях по управлению проектами. И водопад, и итеративный подход, и спирали, и четкое планирование, и адаптивное когда детализируемя по ходу развития истории - это всё там есть. Как конкретные примеры и знания о том, что так можно делать.
Прочитайте хотя бы "Руководство по проектному управлению" Родни Тернера и узнайте про "планирование по вехам" и "планирование набегающей волной" и и поймите что "итеративный подход" - это ... "частный случай" из кучи промежуточных вариантов организации процессов от жесткого планирования, до гибкого адаптивного процесса.
ICB, NCB, PMBoK - это именно свод знаний и систематизация всех вариантов - и больших тяжеловесных и маленьких легковесных, иногда с описанием того где какие методы хорошо подходят.
Кстати, смею сказать что "кибернетический подход" взятый в IPMA - имхо -более адекватен и системен чем древовидная структура процессов и подпроцессов PMI. И на экзаменах IPMA (взять тот же письменный экзамен) - оцениваются и качества менеджера - например риторика и умение излагать мысли на бумаге. Чего невозможно достичь крыженеием галочек в на тесте по PMI.
Теперь про RUP.
Ну какой нафиг IBM и Майкрософт?! Что за бред, извините меня ? Компания Rational начала выпускать свою унифицированную методологию по управлению программным проектом задолго до того как их купил IBM. А о майкрософте вообще речи нет.
И , RUP - это именно методология - это методика создания методики управления проектом. Это большой систематизированный шведский стол инструментов , "Процессный Фреймворк" в котором вы выстраиваете тот вариант процесса который вам нужен именно на этом проекте. можно построить, и главное - дать описание команде процесса, и что то неформальное легковесное с требованиями на салфесках, или какой нибудь аналог "extrim prigramming". А можно сделать тяжеловесное, с утверждением и согласованием каждого артефакта, трассировкой требований от фичи до теста и программного модуля.
А вы назвали это фактически тяжеловесным подходом и противопоставили какому то скруму.
Да как так то ?!
В общем отвечая на заголовок вашей статьи : всё с этим вопросом нормально.
Это, простите, "просто вы не в курсе".
Идите, пожалуйста, для начала - читайте по программной разработке RUP (причем желательно 6й руп, до того как его испортила IBM. можно ещё OpenUP почитать что бы увидеть как в RUP можно описать и вариант процесса по 34-му ГОСТ, и Agile - используя один и тот же подход к описанию процессов, в одном типе диаграмм), а по управлению проектами - упомянутую выше книгу Дж Родни Тернера "Руководство по проектному управлению".
После, желательно, пройдите курсы по управлению проектами в Совнете - национальной организации IPMA, разрабатывающей наш, российский NCB. Там вам систематизированные сведения дадут не только об истории? но и текущем состоянии вопроса. И да будет всем счастье и не будет таких статей.
Извините если обидел.
ну, с виндоус-то, предположим, ситуация вполне ясно-понятная. и в плане засилья, и в плане что с этим делать, и почему так, и как-оно-сейчас, и прогресс видно-и-слышно...
а вот про сап было желание уточнить ))
Обязательно надо начать инициативу "Whitespace for Linux Core" !
Смотрите - есть целый план: рекламировать безопасность и надежность, хвалить за простоту синтаксиса и синтаксический сахар; призывать всех переходить на "пробельчики"; пытаться банить в онлайн-конференциях неугодных разработчиков; через пару лет - слиться в туман сославшись на разные не-технические причины, и ретроградизм кодеров. XD))
Я, конечно, извиняюсь, оффтоп, наверное, но разве sap не
сказал "гудбай-пока-раша"прекратил свою деятельность в России ?Т.е. вопросы связанные не с миграцией с сап
на 1Сна что то другое - они вообще востребованы ?Вопрос, конечно, "с троллингом", но узнать о фактическом состоянии дел, тоже было бы интересно. Заранее спасибо.
если грубо, то у меня возникает впечатление что "носятся с rust, как с дураки с писаниной торбой". да и говорят про "не технические вопросы", а сами ничего не делают в области снятия долговременных технических рисков.
почему я это утверждаю? потому что вместо того, что бы заняться снятием долговременных технических рисков с языком - а именно : подготовка стандарта языка, организация процесса тестирования "альтернативных реализаций языка" и "его-же новых версий" на предмет соответствия уже существующему стандарту - эти люди "на полном серьезе" рассуждают в бложиках, что им важнее "инклюзивный и гибкий процесс развития языка". (бложик где это звучало сейчас не подскажу, пишу с мобилы, но для интересующихся - дам в комментариях.)
стандартизация языка разработки на котором пишется система, контролируемость, плавность процесса его развития - это критичный для любой большой системы фактор на долгом периоде.
вспомним историю : хоть питон и руби. когда новые версии языка не позволяли перенести на них на них код уже написанной системы. у питоновцев, к их чести, совести хватило не бросить старую версию и она до сих пор её тянут. а у разработчика руби - не хватило - он прекратил поддержку старых версий, "и да он знает что многие не могут перейти на новую версию потому что это надо глубоко перерабатывать систему".
ну и вот : подумайте : что будет с ядром линукса, когда в языке, не обложенном стандартами, тестами, контролируемым процессом принятия изменений, вдруг, "по решению инклюзивного сообщества" решат что надо что-то критически поменять, сломав совместимость со старой версией? а вы уже всё ядро уже переписали на этот язык и под его старую версию. что будет ?
сначала перед вами станет проблема рефакторинга и снова переписывания всего - а это время и деньги; а потом - станет проблема безопасности, потому что когда производитель прекратит выпуск патчей безопасности под старый компилятор - вы сядете в лужу.
и отсутствие в rust альтернативных совместимых компиляторов, в том числе и от коммерческих производителей - это важный признак неготовности языка и среды его поддержки к использованию в больших и серьезных проектах.
а теперь хотите страшного? представьте в сообществе rust пару менеджеров майкрософта ? и на фоне наличия описанных технических рисков - вся эта "шумиха и движ" по части переписывания ядра Линукс на руст, ... тут как бы вообще создается впечатление целенаправленного саботажа.
а неоднократное уже появление "истерик" по поводу "нас не оценили мы ходим" (не первый раз же происходит , кстати) - вообще возникают ассоциации совсем с другими, процессами.
повторюсь : если осуществить описанный выше сценарий со "сломом обратной совместимости языка" в условиях, когда на нем уже переписано ядро - вся линукс-экосистема сядет в лужу.
и пока у языка нет стандарта, механизмов проверки соответствия стандарту и процесса принятия изменений с учетом этого стандарта - эти риски не то что не иллюзорны - именно к ним, фактически, целенаправленно, различные руст-активисты и пытаются привести. осознанно или нет - это другой вопрос.
так что не надо называть разработчиков ядра "ретроградами" и "староверами". они то как раз очень хорошо понимают к чему может привести переход на язык разработки, у которого нет стабильности и хоть каких-то гарантий по части ровного "недерганного" развития.
присоединюсь к аргументам @BugM .
вам всего лишь говорят, что заявления о "фрагментированности экосистемы" - мягко говоря, несостоятельны. (наличие множества совместимых между собой альтернативных джавамашин - это никак не фрагментированность. ключевое тут - "полностью совместимых между собой")
аналогично не соответствует действительности и мнение про "закрытость языка" по лицензиям - вы путаете официальную сборку джавамашины от оракла , и сам язык java (как набор стандатов, описаний и требований к логическому механизму).
вы же, очень похоже, к сожалению, не слышите оппонента, его аргументов и не пытаетесь понять о чем он вам говорит.
в статье упущены ключевые фичи языка и стратегии его поддержки, без которых язык не стал бы едва ли не единственным языком написания больших бизнес приложений, и тем явлением которое мы сегодня имеем.
собственно, отсутствие этих вещей у многочисленных "убийц джавы", и стало причиной того что все они - на обочине истории, а джава как была, ведущим языком для бизнес-приложений, так и остается.
первое: наличие четкого описания работы языка.
описания достаточного для того, что бы можно было сделать две ключевые вещи:
а) сделать полностью совместимую альтернативную реализацию компилятора
б) провести тест на совместимость различных компиляторов.
собственно это и есть вторым важным пунктом :
наличие процесса тестирования на совместимость компиляторов. как компиляторов разных версий (обеспечение обратной совместимости и неизменности работы вашего кода на новых версиях языка/компилятора, так и кроссплатформенная совместимлсть )
причем у sun, процесс тестирования был закреплён юридически и без этого нельзя было объявить ваш компилятор - джавой.
помните историю такого поделия майкрософта как J# ? и куда оно "внезапно делось"?
подскажу: юристы sun выиграли дело у мелклмягких и запретили им создавать несовместимую со стандартом версию "java" (там дальше пошла цепочка событий "откуда есть пошел c#, и нафига и кому он был нужен", но это совершенно другая истоия). причем произошло это очень быстро - буквально год или около того. издательство bhv успело даже книжек понавыпускать... а потом их "как смыло".
именно ~100% обратная совместимость (обеспеченная наличием стандарта и тестов) и статическая типизация - и сделали язык тем незаменимым и фактически безальтернативным средством для написания бизнес приложений с длительным жизненным циклом, которым java сегодня и является.
это, а не "какие то там свойства языка".
всё, собственно, потому, что у бизнеса который вкладывает деньги в большой софт на много-много лет - нет никакого желания тратить деньги на рефакторинг кода, после выхода новой версии компилятора.
с джавой процесс переезда на новую версию компилятора - максимально безболезненный (ps: если, конечно, вы "находитесь в пределах стандарта языка", не пользуете недокументированные фичи типа доступа к приватным методам через рефлекшен как было у многих с 6й джавай, или не пытаетесь заигрывать с байткодом ... но это тоже долгая история и повод для холиваров долгими зимними вечерами у камина)
—————
вы скажете что же js и с/с++ ? прекрасный выбор. есть стандарты, есть возможность проверить компилятор, но с обратной и/или кроссплатформенной совместимостью не так как у джавы. хорошие языки для своей ниши - скриптование в браузере (именно скриптование, а не то тяжеловеское безумие с концепцией "js новый ассемблер" которое сегодня творится) и написание близкого к железу кода. это, а не написание приложений с бизнес логикой и длительным жц.
котлин? этот очередной недоубийца джавы (без стандарта, альтернативных реализаций и тестирования совместимости) тоже ушел бы на обочину истории, но оказался нужен гуглу как запасной аэродром от нападок менеджеров оракла по поводу джавы. собственно, в мобильной разработке, с коротким жц приложений (вышла новая версия телефона - надо всё переписывать) - ему вполне себе комфортно. тут многие языки не соблюдающие принципов совместимости и наличия полного описания будут прекрасно жить.
про остальное... потом как-нибудь ))
Урра! теперь моё "дергание лапкой" - вовсе не невротическое расстройство, а врожденный способ похудания! йухху! )))
"...сервисы можно оплачивать не только в айосе, но и в вебе "
- у Тима Суини, помнится, были похожие мысли.
Ну, и как там дела, у "Фортнайт под иос" ? Играете? ))
"К тому же на андроиде приложения подсанкционных банков тоже выпиливают."
- вы зачем "забываете", что это только гугль выпиливает ?
Для андроида - есть еще Самсунг-стор, Магазинчик хуавея, банальные apk с сайта сбера... в общем куча альтернатив.
ВТБ и Сбер прекрасно "переустаналиваются в один клик" из самсунговского магазина, даже настройки менять не надо. Я так и сделал, например.
А под яблоко - эппл-магазин - это вообще единственный способ распространять своё приложение. Нет в ябломагазине - нет вообще нигде. Так что ваше сравнение - совершенно не к месту.