то, что хабр из заявленного изначально "сообщества профессионалов" давно стал местом обитания эмоциональных инфантилов не желающих слышать их огорчающее, даже если это объективные факты... ну да. это известно.
но если мы будем соглашаться с этим эмоциональным шантажом... то что же получится?
это надо хотя бы обсуждать, иначе скоро под профессионалом или инженером скоро будет пониматься именно "это" ( нечто с лавандовым рафом за макбуком), а не "человек с соответствующей квалификацией, навыками, образованием, техническим мышлением".
где каждый второй айтишник считает своим долгом выложить фотографию своего рабочего места с MacBook и кружкой с лавандовым рафом.
В этом предложении у вас, простите, ошибка. В слове "айтишник" ))) В данном контексте, правильно писать "те, кто себя считает айтишником".
Как говорится, "Гуманитарии считают макбук лучшим инструментом для разработки. Но кто-ж их слушает - они-ж и считать-то толком не умеют". 😂
А если по теме - у нас в компании (небольшой интегратор, 100+ человек, 90% сотрудников - люди с высшим техническим образованием) макбуков, наверное, от силы штук 5 наберется.
Совпадение? Не думаю.
По моему личному впечатлению и наблюдениям, обладание высшим техническим образованием "уменьшает вероятность и желание" стать обладателем яблочной продукции "до нескольких процентов".🤷♂️
1.мне начали начислять за кодинг в 1994м. детские игровые обучающие программы для класса дошкольного развития.
2. за софт скиллы морочились всегда, только оно так не называлось, и именно отдельно в особую категорию скиллы не выделялось. просто были способности к математике, технике, психологии, работе с людьми, организаторские способности.
если сейчас софт скиллы выделают как первейшие... я согласен что это глупость, но я не вижу такого выпячивания. впрочем это может быть как засилье жаворонков, утверждающих что просыпаться рано утром полезнее и лучше. а мне повезло увернуться, а вы попали под удар.
но софт скиллы - это мастхев. к сожалению, мы живём в обществе приматов в основной своей массе не обученных рефлексии и осознанной деятельности. и ваш менеджер - тому ярчайший пример )). потому, начиная с мидла - софт скиллы - это обязательно. у нас например ты мидлом конечно станешь, но средненьким максимум (у нас 3 ступени в мидлах). без софт скиллов, контактов с заказчиком или его представителями, в лиды не пробьешься. разработка софта - командный спорт. кому нужен сферический конь в вакууме , пусть и кодящий на отлично?))
ну и вот. мастер на производстве со временем просто становился "житейски мудрее" и умел говорить с начальством. просто не заметил таких ноток в статье. "ну штошъ". сорян))
3. да не, тоже норм. у меня как инженера вообще от половины идей маркетингового онанизма подгорает. вон, глядишь, сам доберусь до статьи про микросервисы...
я, наверное, постараюсь избегать в дальнейшем написания подобных статей
а вот это вы бросьте. кто-ж будет маркетолухам противостоять и хоть где-то школоте и студентам что то рассказывать?)))
или... простите за наглость, но у меня ещё 2 вопроса :
у вас точно 25 лет опыта в индустрии?))
если так, то как можно дожить до 40+ лет и не набраться опыта во взаимодействии с менеджерами? вы не просто обязаны быть "как минимум мидлом"(и знать про особенности некоторых менеджеров ) но и тупо, по налёту лет, не просто столкнуться раз 5-10 с такими манагерами, но и научиться обрабатывать эти ситуации на уровне чуть более мудром, чем "я думаю уволиться".
отсюда вывод: или вы привираете, или написали заказную хайповую статью.
у вас исследование какое или просто чешете себе ЧСВ перед школьниками ?))
У меня вопрос : а почему вы про это всё нам тут плачетесь, а не рассказываете "это всё" вашему архитектору?
потому что тут выслушают?))) что думает по этому поводу ваш архитектор? если всё так, а я подозреваю что всё у вас действительно так, то решать менеджерский вопрос надо менеджерский и пустыми. эскалируйте факт наличия технической проблемы наверх по иерархии и пусть технически подкованные архитектор (понимающий вас), обладающий скидками и доверием уровня менеджера (ему доверяет менеджер), объясняет менеджеру, что идея, мягко говоря, плоха.
так. а не слезливой статьёй на хабре.
... а..... или вы и есть тот самый архитектор?
тогда вопрос : вы не пользуетесь доверием/уважением менеджера? тогда вы не архитектор. ему без софт скиллов и умения работать с менеджерами - никак. вы уж простите.
... или у вас менеджер играет в "я начальник ты дурак"? тогда конечно швах.
можно было бы посоветовать вам поиграть в менеджерский игры вида "дай идиоту оступиться" (сделать как хочет человек, с фиксацией рисков и опасений, и формулировкой "ну раз вы платите, и рискуете своими деньгами, то пожалуйста", а когда всё пойдёт по ...медному тазу - вытащить из загашника старое письмо ), но чую этот вариант не для вас.
...
как итог ? вы - забейте.
если менеджер невразумляемый идиот, поддающийся на маркетинговые уловки - то вашему продукту пи.... ...медным тазом, в общем... он закроется. и вас менеджер , как минимум сейчас, слушать не будет.
в лучшем случае - дайте ему почитать Брукса, и скажите, что кодогенерящие нейронки - совсем не серебряная пуля. и для вашего продукта этот вариант не применим.
юзать кодоген-нейронку - это всё равно, что нанять забесценок студента второкурсника , чтобы с ним, в режиме диалога пилить сайт. если менеджер не послушает такую аналогию - то он дурак. делайте что хотите ))) дело не в вас и не в вайб-кодинге.
студентов генерящих "правильные, красивые, задёшево, идиотические решения" приводили на предприятия всегда. ну теперь вот нейронку привели, с такой же формулировкой и посылом.так что, вот так же , по аналогии и отбивайтесь.
и самое большое инфоцыганство - это микросервисы. XD))
нет, серьезно - кто-нибудь знает что это такое?
и я не про определение и теорию, я про то, что называется "микросервисом" в реальных проектах.
насколько оно соответствует определению, насколько оно действительно решает проблемы (а не приносит кучу новых)... ?
кому удается избежать проблемы "микросервисного монолита" (когда вроде и (микро)(нет)сервисы, но все перезавязано друг на друга так, что не разобрать, и в итоге боязно хоть что-то трогать, потому что не известно что отвалится)... ?
ау! кто видел курсы "по микросервсиной архитектуре" где есть пункт - "когда не надо пилить монолит на микросервисы"?))) нет такого пункта? ну тогда вы поняли.
про вытеснение на Андроиде: см выше. это не свойства языка. Это результат политики/коммерческой деятельности Гугля. Котлин - это сейчас по факту - нишевый язык, аналогичный Свифту или Обджектив-си, который поддерживается исключительно усилиями платформодержателя.
Даже С#, как по факту, платфоменный язык для разработки под Виндоус, созданный после провальной попытки создать собственную несовместимую с основной спекой реалищацию java (юристы Sun знатно тогда поимели Майкрософт за J#), создаваемый на замену winApi+VC - он по факту более адекватен в этом плане (как универсальный промышленный язык выходящий за границы платформы и претендующий на создание бизнес-решений).
Про стиль джавы: новомодности в джаве, конечно придают популярности "среди молодежных движений", но повторюсь: они одни не способны вытянуть язык.
Вспоминайте историю последних 10 лет: ни одного "убийцы джавы" нет в живых, а джава есть. Может быть, у джавы есть что то более серьёзное чем модные фичи, лямбды и синтаксический сахар? что то касающееся подробного описания спецификации языка, тестирования на совместимость, наличие альтернативных совместимых компиляторов и обратную совместимость? читайте мой основной пост выше чтобы найти ответ.
увы но это в основном андроид. и это не свойства языка.
андроид - область в которой есть 2 аспекта:
(1) гуглю нужен "запасной аэродром" от нападок оракула. Собственно, если бы не гуль, никому Котлин и даром не вздался бы. А гуглю Котлин нужен вовсе не из-за технических качеств языка. более того - см ниже - Котлин джаве не конкурент, потому что ... (см ниже)
(2) у андроид программ короткий жизненный цикл, завязанный на выпуск новых версий андроида (т.е. о переносимости старых программ на новый андроид речи не идет). а это значит я что ваша систему надо перерабатывать/дорабатывать/обновлять каждый раз как гуль сделает новый андроид.
а это означает, что системы на котлине Андроиде, не могут быть большими - точнее с ростом объема, затраты на их содержание растут, и как правило совсем не линейно.
и да, я напомню основные проблемы всех (само)убийц джавы: отсутствие спеки, тестов, альтернативных компиляторов. по этим признакам Котлин ничем не лучше всей той массы самописных язычков, толпами порождавшихся десять лет назад, и там же подохнувших на обочине истории. как только гуглю всбредет в голову что джава лучше, или ораул прекратит преследования за джаву - Котлин сдохнет. например как обджектив-си, будучи замеченный свифтом на яблоке. никому, как промышленный язык, обджектив-си не нужен. увы.
Народ, скажите, у нас что - криокапсула с адептом "напишем свой язык" откуда-то вывалилась? Ведь это уже давно было - только с языками.
Вспоминайте, как 10-12 лет назад, ту же Java ругали как только можно, совершенно игнорируя ключевые, важные для бизнеса фичи не столько самого языка, сколько поддержки и стиля развития. Каждый изучивший теорию компиляции/интерпретации делал своего убийцу джавы... С кучей синтаксического сахара, лямбда выражениями, и чем только нельзя...
Но вот - прошло 10 лет, джава есть, новых языков способных тягаться с джавай - нет. Потому что это очень дорогого стоит - не просто полностью описать внутреннюю модель языка, но и наладить тестирование и сертификацию на совместимость, обеспечить ~100% обратную совместимость. Но кто-ж это объяснит тем, кто кричит про архаичность, в погоне за синтаксическим сахаром ?
Вот и теперь. Дитё Человек воспитанный роботами модно-молодежными технологиями в упор не видит даже не армии методистов-архитекторов, создавших удобные и хорошо продуманные учётные механизмы (читай регистры. я очень хочу иметь такой же инструмент в джава - засунул туда измерения, накидал данные - а оно само посчитало остатки, движения, развернуло обороты и промежуточные срезы "буквально как только хочешь"... и olap тут во многих аспектах - рядом не стоял), механизмы отчётности (дайте мне такой же табличный шаблонизатор в java с визуальным редактором! я хочу просто клепать отчёты за полдня, а не это всё вытягивающее нервы-время-и-деньги тряхомудие с беком, рест-функциями, недопсевдомикросервисами, фронтом, джаваскрипт-библиотечками и семинаристками фронтендерами пилящими любой чих по полтора месяца...), систему метаданных с орм (хибернейт с jpa тут рядом не валялся потому, что не знает ничего про бизнес-сущности - документы и справочники с табличными частями)...
... вот не столько он не видит этого всего, сколько "не замечает" системы выпуска обновлений под постоянно меняющееся законодательство и налоговые требования, армии юристов и методистов это всё изучающими.
Это очень дорогого стоит - выпускать своевременно обновления под квартальную отчётность. И бизнесу важно ЭТО, а не "эти ваши кубернетиксы", открытые системы, и вся та чушь, написанная автором в разделе "почему это архаика" в статье выше.
Пожалуйста, изучайте вопрос, прежде чем делать такого рода выс...выбросы вбросы.
Если штука существует, существует долго, вопреки всему (как вам кажется), значит, как правило - что-то она делает правильно.
Давайте лучше винду все вместе поругаем, а? Ну реально же, больше толка будет))) Всем бобра.
Ну что я могу сказать... не прошло и пяти десяти лет с тех пор как каждый второй школьник, не читавший Брукса и проблему серебряной пули, вдохновившись коллективным безумием и хайпом писал статью про то как он пилил монолит на микросервисы, а за оспаривание этого безобразия можно было отхватить и дизлайки и минусы в карму... как вот, наконец, до авторов начало доходить понимание, что маркетологов и школьников нельзя пускать в архитектуру.
Это, конечно, похвально. Нет, я серьезно - я то вот как бы сразу говорил, что "и миллиард муравьёв не вытащат бульдозер из карьера - для этого нужен другой бульдозер", что "микросервисы - очень частный случай компонентно-ориентированной архитектуры" и уже из-за того, что в них маниакально выкрутили в абсолют "фичу развязанности" - их нельзя применять огульно без понимания зачем это тебе... да кто-ж меня слушал ))))
Но, теперь то, дорогие мои, что делать то будем с уже наклепанными на коленке системами, в которых сотни дублирующих друг друга микросервисов, мирриады практически одинаковых ДТО-шек, которые боязно трогать... и разваливающиеся дышащие на ладан процессы завязанные на кучу "независимо разработанных фич", между которыми (о ужас! "никогда не было и вот опять!") есть зависимости, которые никто никогда не документировал, ни понимал.. ?
А ведь ещё есть толпы спринг-бут-овцев заточенных строго на один процесс разработки, один (имхо, достаточно примитивный) инструмент, и считающих что спрингбут=java....?
Что? бюджеты освоены, лохи окучены обучены на курсах "программист за 3 месяца", проекты радостно сданы, а проблемы поддержки - это проблемы тех кто следующим выиграет госконтракт ?
а где в этой архитектуре находится модуль/подсистема, контролирующая бизнес процесс?
подсказка: у вас не архитектура "среднегагруженного проекта" - у вас архитектура "проекта в котором нет бизнес процессов" или они (процессы) примитивны - на уровне задач фейсбука, твиттера или вконташечки. нагрузка - это не только "тысячи примитивных рест-запросов к мьетлесс-микросервтсам", это ещё и "сотня ниток сложных бизнес процессов", которые дают вам такую же, а то и большую нагрузку.
пс: даже миллион микросервисных муравьев не вытащат из карьера промышленный бульдозер хоть сколько нибудь сложного бизнес-процесса. тут нужен другой бульдозер.
пс2: и если вы не контролируете юизнес-логику на сервере - у вас начинается утекание бизнес логики в код клиента, и в итоге вы получаете систему в которой высока вероятность "сделать запрещенное", послав запросы не в том порядке, как это предусмотрено нужным вам процессом.
действительно... IPMA с PMI тихонько и нервно курят в сторонке... их пошатнули.
вы меня простите, наверное это можно посчитать критицизмом... но давайте сначала вы ознакомитесь с современными подходами к управлению проектами. потому что начиная с первого абзаца чувствуется что с актуальными подходами к управлению проектами автор как раз и не ознакомился .
да хоть возьмите классификацию проектов от IPMA и её кибернетическую многомерную модель проектной деятельности. и уже сразу станет понятно насколько узка и не полна предлагаемая в статье классификация деятельности.
то что деятельность на определенном уровне в направлении исполнения уже поставленной задачи можно уложить как фрактал... эта мысль вроде и понятна. это прямое следствие концепции декомпозиции.
очень часто атомарные задачи для управляющего - это мини проект для подчинённого.
да, непонимание этой простой истины часто приводит к идиотии вида "интеграции мс-проджекта и вижуал-студии", когда задача в плане менеджера - это "просто галочка" в списке туду в видал студии. галочки даже без иерархии. в одноуровневом списке галочек (фейспалм).
....
попытки систематизировать деятельность конечно можно только приветствовать. но надо бы и изучить хотя бы уже существующие систематизации и классификации проектной деятельности, прежде чем заявлять про универсальность в управлении проектами.
а то напоминает заявления вида "багзилла это инструмент управления проектом". и кучу... мухи, котлеты, ракеты, мясо , суп...
ну тут да. пока не возникнет потребность, и (чуть погодя) ты не начнешь получать некоторую синергию от одновременного свободного доступа ко всему сразу - это понять сложно.
я себя вспоминаю - я на эклипс пересаживался тоже с какой-то однопроектной среды, и мне было сильно не понятно почему эклипс требует переносить проект в его среду (в его пространство, в каталог пространства) а не умеет открывать из того каталога где лежат исходники (на самом деле умеет, он импортирует его, создается типа ссылка в списке проектов, но это не так интересно по некоторым причинам) и не понимал какой вообще толк.
а сейчас - у меня в эклипсе штук 5 рабочих пространств, под те проекты которыми мы занимаемся уже по несколько лет.
и далее при запуске IDE я выбираю уже не программный проект, а заранее настроенное мною "пространство", а в нем, этом пространстве - уже вся пачка всех нужных исходников загружены - и это всё сразу одним махом "открывается" - и исполняемые проекты, и утилиты, и все модули, и инструменты с плагинами настроены именно под этот профиль проекта (т.е. например тот же ломбок и плагины под спринг у меня загружены только в одно пространство).
и рефакторинг очень удобно проводить. например ты переименовываешь функцию в каком-то общем модуле/библиотеке - а эклипс тебе находит где это используется во всех зависимых открытых проектах и одним махом рефакторит и их тоже.
______________ но поначалу может быть не привычно, понимаю)
это не мы отстали от жизни - это джетбрейнс отстали ))
джетбрейнз "нестормозили", и, на 10й (?) год существования среды разработки, наконец осознали/признали что концепция одного проекта ущербна и осиливают то, что в нормальных IDE всегда было из коробки ?))
вот это - уже сильно более адекватно походит на то что есть в эклипсе от рождения. остается потом разобраться как эти элементы в мультипроектном пространстве работают друг с другом, и т.п .______ offtop : вообще, вся эта эпопея напоминает историю вокруг яблочной "однокнопочности". сначала всем впаривали что "одной мышиной кнопки" хватает и "нашим пользователям сложно с тремя будет управляться", а потом яблоко выпускает "типа однокнокнопочную мышь", но у которой если нажать на левую половину тачпада - это клик, а на правую половину - о великое чудо - контекстное меню будет".
вот и тут. однопроектность - ну суть как та кнопка. не прошло и 10 лет.))
нет) это 2 проекта между которыми ты переключаешься. но они не открыты одновременно. они не могут использовать как общий ресурс например третий проект.
это то-же самое, что открыть 2 проекта в 2-х разных окнах. только переключаешься ты между ними не через альт-таб, а верхним перелючателем, который вы показали.
для сравнения: в эклипсе у меня например в пространстве открыто (условно) 3 проекта (в реальности конечно больше). один - это модуль в исходных кодах, который используется двумя другими. например это может быть общий модуль с описанием сущностей и 2 проекта - например сервер, и тестовый клиент который продергивает запросы по заданному сценарию.
я просто правлю сущность, и перезапускаю тест. а сервер эклипс сам передеплоивает на томкат, причем частично и нагорячую - только те классы что изменились.
и все три у меня открыты одновременно, в одном рабочем пространстве. мне не надо между ними "переключаться".
;)
то, что хабр из заявленного изначально "сообщества профессионалов" давно стал местом обитания эмоциональных инфантилов не желающих слышать их огорчающее, даже если это объективные факты... ну да. это известно.
но если мы будем соглашаться с этим эмоциональным шантажом... то что же получится?
это надо хотя бы обсуждать, иначе скоро под профессионалом или инженером скоро будет пониматься именно "это" ( нечто с лавандовым рафом за макбуком), а не "человек с соответствующей квалификацией, навыками, образованием, техническим мышлением".
В этом предложении у вас, простите, ошибка. В слове "айтишник" )))
В данном контексте, правильно писать "те, кто себя считает айтишником".
Как говорится, "Гуманитарии считают макбук лучшим инструментом для разработки. Но кто-ж их слушает - они-ж и считать-то толком не умеют". 😂
А если по теме - у нас в компании (небольшой интегратор, 100+ человек, 90% сотрудников - люди с высшим техническим образованием) макбуков, наверное, от силы штук 5 наберется.
Совпадение? Не думаю.
По моему личному впечатлению и наблюдениям, обладание высшим техническим образованием "уменьшает вероятность и желание" стать обладателем яблочной продукции "до нескольких процентов".🤷♂️
по аналогии:
1.мне начали начислять за кодинг в 1994м. детские игровые обучающие программы для класса дошкольного развития.
2. за софт скиллы морочились всегда, только оно так не называлось, и именно отдельно в особую категорию скиллы не выделялось. просто были способности к математике, технике, психологии, работе с людьми, организаторские способности.
если сейчас софт скиллы выделают как первейшие... я согласен что это глупость, но я не вижу такого выпячивания. впрочем это может быть как засилье жаворонков, утверждающих что просыпаться рано утром полезнее и лучше. а мне повезло увернуться, а вы попали под удар.
но софт скиллы - это мастхев. к сожалению, мы живём в обществе приматов в основной своей массе не обученных рефлексии и осознанной деятельности. и ваш менеджер - тому ярчайший пример )). потому, начиная с мидла - софт скиллы - это обязательно. у нас например ты мидлом конечно станешь, но средненьким максимум (у нас 3 ступени в мидлах). без софт скиллов, контактов с заказчиком или его представителями, в лиды не пробьешься. разработка софта - командный спорт. кому нужен сферический конь в вакууме , пусть и кодящий на отлично?))
ну и вот. мастер на производстве со временем просто становился "житейски мудрее" и умел говорить с начальством. просто не заметил таких ноток в статье. "ну штошъ". сорян))
3. да не, тоже норм. у меня как инженера вообще от половины идей маркетингового онанизма подгорает. вон, глядишь, сам доберусь до статьи про микросервисы...
а вот это вы бросьте. кто-ж будет маркетолухам противостоять и хоть где-то школоте и студентам что то рассказывать?)))
или... простите за наглость, но у меня ещё 2 вопроса :
у вас точно 25 лет опыта в индустрии?))
если так, то как можно дожить до 40+ лет и не набраться опыта во взаимодействии с менеджерами? вы не просто обязаны быть "как минимум мидлом"(и знать про особенности некоторых менеджеров ) но и тупо, по налёту лет, не просто столкнуться раз 5-10 с такими манагерами, но и научиться обрабатывать эти ситуации на уровне чуть более мудром, чем "я думаю уволиться".
отсюда вывод: или вы привираете, или написали заказную хайповую статью.
у вас исследование какое или просто чешете себе ЧСВ перед школьниками ?))
У меня вопрос : а почему вы про это всё нам тут плачетесь, а не рассказываете "это всё" вашему архитектору?
потому что тут выслушают?)))что думает по этому поводу ваш архитектор? если всё так, а я подозреваю что всё у вас действительно так, то решать менеджерский вопрос надо менеджерский и пустыми. эскалируйте факт наличия технической проблемы наверх по иерархии и пусть технически подкованные архитектор (понимающий вас), обладающий скидками и доверием уровня менеджера (ему доверяет менеджер), объясняет менеджеру, что идея, мягко говоря, плоха.так. а не слезливой статьёй на хабре.
... а..... или вы и есть тот самый архитектор?
тогда вопрос : вы не пользуетесь доверием/уважением менеджера? тогда вы не архитектор. ему без софт скиллов и умения работать с менеджерами - никак. вы уж простите.
... или у вас менеджер играет в "я начальник ты дурак"? тогда конечно швах.
можно было бы посоветовать вам поиграть в менеджерский игры вида "дай идиоту оступиться" (сделать как хочет человек, с фиксацией рисков и опасений, и формулировкой "ну раз вы платите, и рискуете своими деньгами, то пожалуйста", а когда всё пойдёт по ...медному тазу - вытащить из загашника старое письмо ), но чую этот вариант не для вас.
...
как итог ? вы - забейте.
если менеджер невразумляемый идиот, поддающийся на маркетинговые уловки - то вашему продукту пи.... ...медным тазом, в общем... он закроется. и вас менеджер , как минимум сейчас, слушать не будет.
в лучшем случае - дайте ему почитать Брукса, и скажите, что кодогенерящие нейронки - совсем не серебряная пуля. и для вашего продукта этот вариант не применим.
юзать кодоген-нейронку - это всё равно, что нанять забесценок студента второкурсника , чтобы с ним, в режиме диалога пилить сайт. если менеджер не послушает такую аналогию - то он дурак. делайте что хотите ))) дело не в вас и не в вайб-кодинге.
студентов генерящих "правильные, красивые, задёшево, идиотические решения" приводили на предприятия всегда. ну теперь вот нейронку привели, с такой же формулировкой и посылом.так что, вот так же , по аналогии и отбивайтесь.
и самое большое инфоцыганство - это микросервисы. XD))
нет, серьезно - кто-нибудь знает что это такое?
и я не про определение и теорию, я про то, что называется "микросервисом" в реальных проектах.
насколько оно соответствует определению, насколько оно действительно решает проблемы (а не приносит кучу новых)... ?
кому удается избежать проблемы "микросервисного монолита" (когда вроде и (микро)(нет)сервисы, но все перезавязано друг на друга так, что не разобрать, и в итоге боязно хоть что-то трогать, потому что не известно что отвалится)... ?
ау! кто видел курсы "по микросервсиной архитектуре" где есть пункт - "когда не надо пилить монолит на микросервисы"?))) нет такого пункта? ну тогда вы поняли.
Ну и пачка вопросов на последок :
Как вложить скрипт в расширение и привязать вызов функции из скрипта в пункт меню?
Как собрать и вложить джарник, и вызвать из пункта меню метод какого-либо его класса?
Как подключить формы?
Всё почти хорошо, за исключением того, что в значениях xml-атрибутов надо поисключать треугольные скобочки. т.е.
должно быть
Ну и в других местах тоже. Без этого - "не работает".
Как там говорили?
А можно вот всё точно так же, но только если ушел с киносеанса в течении первых 30 минут - и тебе возвращают деньги?
про вытеснение на Андроиде: см выше. это не свойства языка. Это результат политики/коммерческой деятельности Гугля. Котлин - это сейчас по факту - нишевый язык, аналогичный Свифту или Обджектив-си, который поддерживается исключительно усилиями платформодержателя.
Даже С#, как по факту, платфоменный язык для разработки под Виндоус, созданный после провальной попытки создать собственную несовместимую с основной спекой реалищацию java (юристы Sun знатно тогда поимели Майкрософт за J#), создаваемый на замену winApi+VC - он по факту более адекватен в этом плане (как универсальный промышленный язык выходящий за границы платформы и претендующий на создание бизнес-решений).
Про стиль джавы: новомодности в джаве, конечно придают популярности "среди молодежных движений", но повторюсь: они одни не способны вытянуть язык.
Вспоминайте историю последних 10 лет: ни одного "убийцы джавы" нет в живых, а джава есть. Может быть, у джавы есть что то более серьёзное чем модные фичи, лямбды и синтаксический сахар? что то касающееся подробного описания спецификации языка, тестирования на совместимость, наличие альтернативных совместимых компиляторов и обратную совместимость? читайте мой основной пост выше чтобы найти ответ.
увы но это в основном андроид. и это не свойства языка.
андроид - область в которой есть 2 аспекта:
(1) гуглю нужен "запасной аэродром" от нападок оракула. Собственно, если бы не гуль, никому Котлин и даром не вздался бы. А гуглю Котлин нужен вовсе не из-за технических качеств языка. более того - см ниже - Котлин джаве не конкурент, потому что ... (см ниже)
(2) у андроид программ короткий жизненный цикл, завязанный на выпуск новых версий андроида (т.е. о переносимости старых программ на новый андроид речи не идет). а это значит я что ваша систему надо перерабатывать/дорабатывать/обновлять каждый раз как гуль сделает новый андроид.
а это означает, что системы на котлине Андроиде, не могут быть большими - точнее с ростом объема, затраты на их содержание растут, и как правило совсем не линейно.
и да, я напомню основные проблемы всех (само)убийц джавы: отсутствие спеки, тестов, альтернативных компиляторов. по этим признакам Котлин ничем не лучше всей той массы самописных язычков, толпами порождавшихся десять лет назад, и там же подохнувших на обочине истории. как только гуглю всбредет в голову что джава лучше, или ораул прекратит преследования за джаву - Котлин сдохнет. например как обджектив-си, будучи замеченный свифтом на яблоке. никому, как промышленный язык, обджектив-си не нужен. увы.
"Ах моська, знать она сильна..."
Народ, скажите, у нас что - криокапсула с адептом "напишем свой язык" откуда-то вывалилась? Ведь это уже давно было - только с языками.
Вспоминайте, как 10-12 лет назад, ту же Java ругали как только можно, совершенно игнорируя ключевые, важные для бизнеса фичи не столько самого языка, сколько поддержки и стиля развития. Каждый изучивший теорию компиляции/интерпретации делал своего убийцу джавы... С кучей синтаксического сахара, лямбда выражениями, и чем только нельзя...
Но вот - прошло 10 лет, джава есть, новых языков способных тягаться с джавай - нет. Потому что это очень дорогого стоит - не просто полностью описать внутреннюю модель языка, но и наладить тестирование и сертификацию на совместимость, обеспечить ~100% обратную совместимость. Но кто-ж это объяснит тем, кто кричит про архаичность, в погоне за синтаксическим сахаром ?
Вот и теперь.
ДитёЧеловек воспитанныйроботамимодно-молодежными технологиями в упор не видит даже не армии методистов-архитекторов, создавших удобные и хорошо продуманные учётные механизмы (читай регистры. я очень хочу иметь такой же инструмент в джава - засунул туда измерения, накидал данные - а оно само посчитало остатки, движения, развернуло обороты и промежуточные срезы "буквально как только хочешь"... и olap тут во многих аспектах - рядом не стоял), механизмы отчётности (дайте мне такой же табличный шаблонизатор в java с визуальным редактором! я хочу просто клепать отчёты за полдня, а не это всё вытягивающее нервы-время-и-деньги тряхомудие с беком, рест-функциями, недопсевдомикросервисами, фронтом, джаваскрипт-библиотечками исеминаристкамифронтендерами пилящими любой чих по полтора месяца...), систему метаданных с орм (хибернейт с jpa тут рядом не валялся потому, что не знает ничего про бизнес-сущности - документы и справочники с табличными частями)...... вот не столько он не видит этого всего, сколько "не замечает" системы выпуска обновлений под постоянно меняющееся законодательство и налоговые требования, армии юристов и методистов это всё изучающими.
Это очень дорогого стоит - выпускать своевременно обновления под квартальную отчётность. И бизнесу важно ЭТО, а не "эти ваши кубернетиксы", открытые системы, и вся та чушь, написанная автором в разделе "почему это архаика" в статье выше.
Пожалуйста, изучайте вопрос, прежде чем делать такого рода
выс...выбросывбросы.Если штука существует, существует долго, вопреки всему (как вам кажется), значит, как правило - что-то она делает правильно.
Давайте лучше винду все вместе поругаем, а? Ну реально же, больше толка будет))) Всем бобра.
Это изделие умеет "в несколько проектов" как эклипс или это такая-же модно-молодежная однопроектная фигня/среда для разработки курсовых как и идея?а... это форк опенсорсной идеи ? вопрос снимается.
Ну что я могу сказать... не прошло и
пятидесяти лет с тех пор как каждый второй школьник, не читавший Брукса и проблему серебряной пули, вдохновившись коллективным безумием и хайпом писал статью про то как он пилил монолит на микросервисы, а за оспаривание этого безобразия можно было отхватить и дизлайки и минусы в карму... как вот, наконец, до авторов начало доходить понимание, что маркетологов и школьников нельзя пускать в архитектуру.Это, конечно, похвально. Нет, я серьезно - я то вот как бы сразу говорил, что "и миллиард муравьёв не вытащат бульдозер из карьера - для этого нужен другой бульдозер", что "микросервисы - очень частный случай компонентно-ориентированной архитектуры" и уже из-за того, что в них маниакально выкрутили в абсолют "фичу развязанности" - их нельзя применять огульно без понимания зачем это тебе... да кто-ж меня слушал ))))
Но, теперь то, дорогие мои, что делать то будем с уже наклепанными на коленке системами, в которых сотни дублирующих друг друга микросервисов, мирриады практически одинаковых ДТО-шек, которые боязно трогать... и разваливающиеся дышащие на ладан процессы завязанные на кучу "независимо разработанных фич", между которыми (о ужас! "никогда не было и вот опять!") есть зависимости, которые никто никогда не документировал, ни понимал.. ?
А ведь ещё есть толпы спринг-бут-овцев заточенных строго на один процесс разработки, один (имхо, достаточно примитивный) инструмент, и считающих что спрингбут=java....?
Что? бюджеты освоены, лохи
окученыобучены на курсах "программист за 3 месяца", проекты радостно сданы, а проблемы поддержки - это проблемы тех кто следующим выиграет госконтракт ?Риторический вопрос. Но решать надо. Всем добра.
а где в этой архитектуре находится модуль/подсистема, контролирующая бизнес процесс?
подсказка: у вас не архитектура "среднегагруженного проекта" - у вас архитектура "проекта в котором нет бизнес процессов" или они (процессы) примитивны - на уровне задач фейсбука, твиттера или вконташечки. нагрузка - это не только "тысячи примитивных рест-запросов к мьетлесс-микросервтсам", это ещё и "сотня ниток сложных бизнес процессов", которые дают вам такую же, а то и большую нагрузку.
пс: даже миллион микросервисных муравьев не вытащат из карьера промышленный бульдозер хоть сколько нибудь сложного бизнес-процесса. тут нужен другой бульдозер.
пс2: и если вы не контролируете юизнес-логику на сервере - у вас начинается утекание бизнес логики в код клиента, и в итоге вы получаете систему в которой высока вероятность "сделать запрещенное", послав запросы не в том порядке, как это предусмотрено нужным вам процессом.
действительно... IPMA с PMI тихонько и нервно курят в сторонке... их пошатнули.
вы меня простите, наверное это можно посчитать критицизмом... но давайте сначала вы ознакомитесь с современными подходами к управлению проектами. потому что начиная с первого абзаца чувствуется что с актуальными подходами к управлению проектами автор как раз и не ознакомился .
да хоть возьмите классификацию проектов от IPMA и её кибернетическую многомерную модель проектной деятельности. и уже сразу станет понятно насколько узка и не полна предлагаемая в статье классификация деятельности.
то что деятельность на определенном уровне в направлении исполнения уже поставленной задачи можно уложить как фрактал... эта мысль вроде и понятна. это прямое следствие концепции декомпозиции.
очень часто атомарные задачи для управляющего - это мини проект для подчинённого.
да, непонимание этой простой истины часто приводит к идиотии вида "интеграции мс-проджекта и вижуал-студии", когда задача в плане менеджера - это "просто галочка" в списке туду в видал студии. галочки даже без иерархии. в одноуровневом списке галочек (фейспалм).
....
попытки систематизировать деятельность конечно можно только приветствовать. но надо бы и изучить хотя бы уже существующие систематизации и классификации проектной деятельности, прежде чем заявлять про универсальность в управлении проектами.
а то напоминает заявления вида "багзилла это инструмент управления проектом". и кучу... мухи, котлеты, ракеты, мясо , суп...
ну право.
ну тут да. пока не возникнет потребность, и (чуть погодя) ты не начнешь получать некоторую синергию от одновременного свободного доступа ко всему сразу - это понять сложно.
я себя вспоминаю - я на эклипс пересаживался тоже с какой-то однопроектной среды, и мне было сильно не понятно почему эклипс требует переносить проект в его среду (в его пространство, в каталог пространства) а не умеет открывать из того каталога где лежат исходники (на самом деле умеет, он импортирует его, создается типа ссылка в списке проектов, но это не так интересно по некоторым причинам) и не понимал какой вообще толк.
а сейчас - у меня в эклипсе штук 5 рабочих пространств, под те проекты которыми мы занимаемся уже по несколько лет.
и далее при запуске IDE я выбираю уже не программный проект, а заранее настроенное мною "пространство", а в нем, этом пространстве - уже вся пачка всех нужных исходников загружены - и это всё сразу одним махом "открывается" - и исполняемые проекты, и утилиты, и все модули, и инструменты с плагинами настроены именно под этот профиль проекта (т.е. например тот же ломбок и плагины под спринг у меня загружены только в одно пространство).
и рефакторинг очень удобно проводить. например ты переименовываешь функцию в каком-то общем модуле/библиотеке - а эклипс тебе находит где это используется во всех зависимых открытых проектах и одним махом рефакторит и их тоже.
______________
но поначалу может быть не привычно, понимаю)
там вон подсказывают, что джетбрейнзы, наконец, почти осилили : https://habr.com/ru/companies/spring_aio/articles/852526/comments/#comment_27481152
но не так как вы показываете.
это не мы отстали от жизни - это джетбрейнс отстали ))
джетбрейнз "нестормозили", и, на 10й (?) год существования среды разработки, наконец осознали/признали что концепция одного проекта ущербна и осиливают то, что в нормальных IDE всегда было из коробки ?))
вот это - уже сильно более адекватно походит на то что есть в эклипсе от рождения.
остается потом разобраться как эти элементы в мультипроектном пространстве работают друг с другом, и т.п
.______
offtop : вообще, вся эта эпопея напоминает историю вокруг яблочной "однокнопочности". сначала всем впаривали что "одной мышиной кнопки" хватает и "нашим пользователям сложно с тремя будет управляться", а потом яблоко выпускает "типа однокнокнопочную мышь", но у которой если нажать на левую половину тачпада - это клик, а на правую половину - о великое чудо - контекстное меню будет".
вот и тут. однопроектность - ну суть как та кнопка. не прошло и 10 лет.))
нет) это 2 проекта между которыми ты переключаешься. но они не открыты одновременно.
они не могут использовать как общий ресурс например третий проект.
это то-же самое, что открыть 2 проекта в 2-х разных окнах. только переключаешься ты между ними не через альт-таб, а верхним перелючателем, который вы показали.
для сравнения: в эклипсе у меня например в пространстве открыто (условно) 3 проекта (в реальности конечно больше). один - это модуль в исходных кодах, который используется двумя другими. например это может быть общий модуль с описанием сущностей и 2 проекта - например сервер, и тестовый клиент который продергивает запросы по заданному сценарию.
я просто правлю сущность, и перезапускаю тест. а сервер эклипс сам передеплоивает на томкат, причем частично и нагорячую - только те классы что изменились.
и все три у меня открыты одновременно, в одном рабочем пространстве. мне не надо между ними "переключаться".