Specifications не всегда подходят для сложных сценариев, не делает их "хренью". Это всего лишь инструмент, который удобно использовать, когда он подходит, и игнорировать, когда он избыточен.
Вы как раз ошибаетесь. Вы в данном предложении мыслите "сиюминутно", простите, как студент, которому надо сделать что-то на раз и забыть.
Проблема большого интерпрайз-приложения в том, что ты не знаешь в каком месте оно станет сложным через ... скажем полгода. или год.
Приложения имеют тенденцию усложняться.
И когда ты понимаешь что "тут внезапно и неожиданно стало сложно", а "спецификации" уже превратили код в нечитаемый, неразбираемый, и - главное - неотлаживаемый кусок "чего-то" - любой чих в направлении отказа от этого "новомодномолодежного API" - будет стоит денег, нервов и новых багов. Потому что они "прописаны везде".
Отсюда - это как раз именно "хрень". Потому что она обманывает тебя красивой концепцией, а потом очень сильно и больно бьет, когда в реалььной жизни ты налетаешь на сложный случай с уже написанным кодом. Причем часто после того, как человек создавший это нагромождение - когда проект ещё был простым - уже не доступен.
Исходя из этого обстоятельства - есть один очень простой выход: запрет использования этого API на серьезных проектах.
Т.е. "на всех проектах сложнее "курсовой" которую можно стереть и забыть после сдачи зачета".
1) как или откуда скачать дистрибутив ликвидбейса, если официальный сайт в "амазон клауде" и он блокирует получение файлов ? и.е. виндовый дистрибутив с официального сайта не получить
2) я правильно понимаю, что Liquibase не умеет контролировать/запоминать текущую, целевую структуру таблиц, и восстанавливать её, если что-то пошло не так? т.е. он "тупо шпарит патчи" и контролирует их выполнение, не понимая, надо ли для текущей структуры применять патч или нет, даже если это не sql, а опция " - createtable " в yaml-файле с ченджлогом?
т.е. если в работу с таблицами ликвидбейса вмешалась третья сторона или "что-то пошло не так" - мы получаем долгий изнурительный процесс восстановления структуры руками?
поясню на примере: вот прошла миграция, всё патчи/ченджлоги ликвидбейзом применены. теперь какой-то сторонний инструмент удаляет из базы таблицу. ну, так случилось. запускаем систему спрингбут с ликвидбейзом, он при старте проверяет что всё патчи применены, пишет всё хорошо, а потом мы получаем исключения при выполнении запросов, что relation в базе не существует.
как заставить ликвидбейз проверять целевую структуру бд, сравнивать её с целевой и применять изменения фрагментарно ? например - восстановить таблицу если она была "случайно" удалена?
в инфраструктуру надо вкладываться. планово, без сиюминутной отдачи, начисляя из бюджета проекта 20%, ухудшая в пользу этого формальные показатели...
потому что, если не поддерживать инфраструктуру - "оно начнет гнить". медленно, но неотвратимо приближая полный коллапс системы и процессов.
как материальная инфраструктура является чем-то малозначимые и дорогим, требующим постоянного обслуживания, не участвующим непосредственно в получении результата, но дающим вообще возможность получить результат; так и процесс должен обладать шагами, которые обслуживают вообще саму возможность получать результат длительное время.
---------
а вот почему у автора - архитектор - "невидимый" - это вопрос. может надо сделать ротацию архитекторов? чела поднять из разрабов в младшие архитекторы?
архитектор не должен быть невидимым. иначе возникает вопрос - а рп у вас вообще с головой дружит?)))
то, что хабр из заявленного изначально "сообщества профессионалов" давно стал местом обитания эмоциональных инфантилов не желающих слышать их огорчающее, даже если это объективные факты... ну да. это известно.
но если мы будем соглашаться с этим эмоциональным шантажом... то что же получится?
это надо хотя бы обсуждать, иначе скоро под профессионалом или инженером скоро будет пониматься именно "это" ( нечто с лавандовым рафом за макбуком), а не "человек с соответствующей квалификацией, навыками, образованием, техническим мышлением".
где каждый второй айтишник считает своим долгом выложить фотографию своего рабочего места с 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 вещи для начала продвижения:
1. ролик выдожить на официально доступные ресурсы.
2. идеально бы поднять сервер, где можно пощупать игру. простая виртуалка сейчас стоит пару чашек кода. обычно это подъемные деньги.
ну, или дистрибутивы для поднятия своего сервера и запуска клиента.
и не бросать игру. без автора, хотя бы дающего комментарии по коду - не взлетит.
ну и на всякий случай: документация и комментарии в коде. если этого нет - имхо, считайте что и нет кода в общем доступе.
Вы как раз ошибаетесь. Вы в данном предложении мыслите "сиюминутно", простите, как студент, которому надо сделать что-то на раз и забыть.
Проблема большого интерпрайз-приложения в том, что ты не знаешь в каком месте оно станет сложным через ... скажем полгода. или год.
Приложения имеют тенденцию усложняться.
И когда ты понимаешь что "тут внезапно и неожиданно стало сложно", а "спецификации" уже превратили код в нечитаемый, неразбираемый, и - главное - неотлаживаемый кусок "чего-то" - любой чих в направлении отказа от этого "новомодномолодежного API" - будет стоит денег, нервов и новых багов. Потому что они "прописаны везде".
Отсюда - это как раз именно "хрень". Потому что она обманывает тебя красивой концепцией, а потом очень сильно и больно бьет, когда в реалььной жизни ты налетаешь на сложный случай с уже написанным кодом. Причем часто после того, как человек создавший это нагромождение - когда проект ещё был простым - уже не доступен.
Исходя из этого обстоятельства - есть один очень простой выход: запрет использования этого API на серьезных проектах.
Т.е. "на всех проектах сложнее "курсовой" которую можно стереть и забыть после сдачи зачета".
UPD: скачивание дистрибутивов https://www.liquibase.com/open-source они вроде поправили. вопрос 1 отпадает. но что делать со вторым пунктом?
пара вопросов, если позволите.
1) как или откуда скачать дистрибутив ликвидбейса, если официальный сайт в "амазон клауде" и он блокирует получение файлов ? и.е. виндовый дистрибутив с официального сайта не получить
2) я правильно понимаю, что Liquibase не умеет контролировать/запоминать текущую, целевую структуру таблиц, и восстанавливать её, если что-то пошло не так? т.е. он "тупо шпарит патчи" и контролирует их выполнение, не понимая, надо ли для текущей структуры применять патч или нет, даже если это не sql, а опция " - createtable " в yaml-файле с ченджлогом?
т.е. если в работу с таблицами ликвидбейса вмешалась третья сторона или "что-то пошло не так" - мы получаем долгий изнурительный процесс восстановления структуры руками?
поясню на примере: вот прошла миграция, всё патчи/ченджлоги ликвидбейзом применены. теперь какой-то сторонний инструмент удаляет из базы таблицу. ну, так случилось. запускаем систему спрингбут с ликвидбейзом, он при старте проверяет что всё патчи применены, пишет всё хорошо, а потом мы получаем исключения при выполнении запросов, что relation в базе не существует.
как заставить ликвидбейз проверять целевую структуру бд, сравнивать её с целевой и применять изменения фрагментарно ? например - восстановить таблицу если она была "случайно" удалена?
----------
заранее спасибо.
это по сути "инфраструктура процесса".
в инфраструктуру надо вкладываться. планово, без сиюминутной отдачи, начисляя из бюджета проекта 20%, ухудшая в пользу этого формальные показатели...
потому что, если не поддерживать инфраструктуру - "оно начнет гнить". медленно, но неотвратимо приближая полный коллапс системы и процессов.
как материальная инфраструктура является чем-то малозначимые и дорогим, требующим постоянного обслуживания, не участвующим непосредственно в получении результата, но дающим вообще возможность получить результат; так и процесс должен обладать шагами, которые обслуживают вообще саму возможность получать результат длительное время.
---------
а вот почему у автора - архитектор - "невидимый" - это вопрос. может надо сделать ротацию архитекторов? чела поднять из разрабов в младшие архитекторы?
архитектор не должен быть невидимым. иначе возникает вопрос - а рп у вас вообще с головой дружит?)))
;)
то, что хабр из заявленного изначально "сообщества профессионалов" давно стал местом обитания эмоциональных инфантилов не желающих слышать их огорчающее, даже если это объективные факты... ну да. это известно.
но если мы будем соглашаться с этим эмоциональным шантажом... то что же получится?
это надо хотя бы обсуждать, иначе скоро под профессионалом или инженером скоро будет пониматься именно "это" ( нечто с лавандовым рафом за макбуком), а не "человек с соответствующей квалификацией, навыками, образованием, техническим мышлением".
В этом предложении у вас, простите, ошибка. В слове "айтишник" )))
В данном контексте, правильно писать "те, кто себя считает айтишником".
Как говорится, "Гуманитарии считают макбук лучшим инструментом для разработки. Но кто-ж их слушает - они-ж и считать-то толком не умеют". 😂
А если по теме - у нас в компании (небольшой интегратор, 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 месяца", проекты радостно сданы, а проблемы поддержки - это проблемы тех кто следующим выиграет госконтракт ?Риторический вопрос. Но решать надо. Всем добра.