Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Ikemefula, Вы писали: I>>Типичный кейс — ментор команды дотнета пытается объяснить фронтам как ихний бакенд собрать, развернуть, настроить. Вот почему то такой херни на ноде как то не выходит, все само работает. В итоге у одних фронт и бек друг о друге не знают даже на финише, а у других это есть прямо со старта. S>О, это интересно. Я тут подумываю возродить дотнет в нашем универе.
Интересно. В нашем, он особо и не умирал — достаточно удобная среда для студенческих проектов и преподавателям он вполне нравится.
S>Несут, что характерно, в основном джаву/спринг. Изредка котлин или какой-нибудь питон.
Я могу судить только по дипломам. Там частично, конечно, выбор диктуется окружающими условиями (и если диплом пишется у работодателя, то не о каком самостоятельном выборе среды речь не идет), но выглядит так, что Java встречается крайне редко.
S>На ноде пока что не было никого.
Аналогично.
Здравствуйте, Михаил Романов, Вы писали: МР>А на сколько давний опыт?
Май 2022. МР>У меня реально давний и, допускаю, с тех пор могло пойти в худшую сторону.
Похоже на то.
Upd: может быть, причина не в техе, а в том, что я — тупой. Нельзя так сразу исключать самое простое и очевидное объяснение.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Михаил Романов, Вы писали:
МР>>>В общем именно с "развернуть" и "очень базово начать работать" я проблем не испытал. Но, быть может, у вас был прямо противоположный опыт
+1
S>>Именно противоположный, и именно с миктехом. И именно в рамках "хочу не трахаясь сверстать себе диплом". МР>А на сколько давний опыт?
в +-2003 году никаких проблем не наблюдалось.
Возможно с русским пришлось что-то делать, чтобы техбук скомпилить, но в целом норм.
помню еще TexLive диск был, но его не пробовал.
Здравствуйте, Sinclair, Вы писали:
МР>>В общем именно с "развернуть" и "очень базово начать работать" я проблем не испытал. Но, быть может, у вас был прямо противоположный опыт S>Именно противоположный, и именно с миктехом. И именно в рамках "хочу не трахаясь сверстать себе диплом". S>В итоге заразил систему АктивПерлом (за что получил гневное письмо от корпоративной безопасности), а тех так и не заработал. Стандартная для опенсорса проблема: одна субстанция не может найти другую субстанцию.
как понять "заразил систему АктивПерлом" и почему за это ругается безопасность?
S>В интернете все советы очень доброжелательные, но бесполезные — либо ссылаются на ныне не существующие версии софта, либо просто не помогают.
с TexLive не пробовал ставить? (еще один бесполезный совет, т.к тоже давно тех не использовал, но по идее он делался чтобы наиболее просто поставить, а с ДВД еще пишут что можно работать не устанавливая)
Здравствуйте, night beast, Вы писали: NB>как понять "заразил систему АктивПерлом"
У ActiveState очень оригинальный взгляд на то, что значит "uninstall". https://community.activestate.com/t/cant-uninstall-activeperl-5-32/6696 NB>и почему за это ругается безопасность?
Потому, что скачивание state-installer.zip при помощи повершелла считается подозрительной активностью.
Подозреваю, что первопричина — в предыдущем пункте.
Процитирую одного из комментаторов:
This is completely unprofessional. No method of uninstallation should be considered malware.
А вот что мне написали наши безопасники:
Hello Anton,
The Security Operations Center has detected some PowerShell activities from your endpoint “******”
We noticed that through PowerShell a connection was established to “platform.activestate.com” and file “state-installer.zip” was downloaded.
File path: c:\users\****\appdata\local\temp\42b8c64b-b1a3-43ea-9d5f-9a5cffc213ab\state-installer.zip
S>>В интернете все советы очень доброжелательные, но бесполезные — либо ссылаются на ныне не существующие версии софта, либо просто не помогают. NB>с TexLive не пробовал ставить? (еще один бесполезный совет, т.к тоже давно тех не использовал, но по идее он делался чтобы наиболее просто поставить, а с ДВД еще пишут что можно работать не устанавливая)
Мне было нужно интерактивное редактирование документов, т.к. с техом я дело имел кратко, давно, и неправда.
Не помню уже. Я просто пошёл по пути https://github.com/James-Yu/LaTeX-Workshop/wiki/Install — и после N неудачных попыток запинать зверюшку тупо плюнул и сверстал всё в Ворде.
В следующий раз я буду это пробовать весьма нескоро.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
SD>>>>>>PS: забавно, что про всякие там stock market большими буквами пишут "past performance is not an indication of the future performance". Про стартапы, однако, так не пишут. I>Вероятно, я не понял, что ты хотел сказать.
Суть моего высказывания в том, что очень часто можно встретить заявления типа "вы стартап и прогорите, потому что 90% стартапов прогорают, а значит, вам не следует использовать технологии, архитектуры и инструменты с прицелом на будущее — пилите на node.js, лишь бы вчера".
Я справедливо указываю на "самосбываемость" такого пророчества, т.к. "пиление абы как" нередко и приводит к тем самым 90%, которые тоже пилили абы как. Потому что им тоже так сказали инвесторы.
I>Что бы вести речь про качество, нужно сначала узнать требования.
Стоит сначала договорится о терминах. Требования — это такая штука, которая меняется быстрее, чем флюгер у меня около дома направление меняет. Если качество будет прыгать с такой же амплитудой и частотой, вряд ли удастся хоть что-то соорудить.
I>"через пару недель уже нельзя читать" — это болезнь начинающи на любом языке. Сужу по студентам. Скорее всего сын тебе донес твою же мысль. Вероятнее всего, ты сам не понимаешь, в чем особенность динамики, а потому научить не сможешь — невозможно поделиться тем, чего у тебя нет.
За переход на личности — незачет. Крайне невежливо. Особенно не зная собеседника.
Про "особенности языков с динамической типизацией" предлагаю поговорить тогда, когда вы поработаете в реально больших проектах. Заодно посмотрите теорию на тему сильной/слабой, и статической/динамической типизацией.
И если что, type checker'ов для JS наделано куча.
Но дело не в них, а в том, что JS реально убог. Популярность же его обеспечена вовсе не удобством или чем-то еще, а всего лишь случайной возможностью оказаться на пустой нише. Как kubernetes — отвратительный, ужасный, organically grown в худшем своем варианте.
I>Со временем и гиганты подтянулись. Это далеко не сразу произошло. Отсутствие использования гигантами говорит о том, что технология нездоровая. У каждого гиганта унутре огромное количество подразделений, по которым легко собрать статистику. Выяснили, что всё хорошо на питоне — начали хором использвать питон. С хаскелем такое не прокатило, не взлетел.
Вы просто не понимаете, как гиганты работают.
Могут выяснить, что на питоне все очень-очень плохо, но из 40.000 нанятых за последние полгода порядка 30.000 будут на нем писать (они на чем угодно согласны писать, yes-maaam). И очень громкое меньшинство фанатиков питона обработают руководство (которому пофиг).
Если вы наивно думаете, что технические свойства того или иного инструмента имеют хоть сколь-нибудь заметное значение — я вас разочарую. Политика и sales, sales и политика.
I>Вот-вот. Именно этому ты научил своего ребенка. Начатый на ххх проект продолжают заваливать баблом и костылями — я такое видел и на С++, дотнет, джава, итд итд. Причины, как правило, большей частью не в коде, а в менеджменте, архитектуре, требования, сроках и тдю
Опять персональные нападки, теперь уже и ребенку перепадает. Если продолжится, то будете сами с собой беседовать, мне так неинтересно. Причины всегда в политике (деньгах), потом уже догнивает и до менеджмента с архитектурой и сроками.
I>Примеров успешных проектов на динамике полно, стоит только глаза раскрыть.
Вы о чем вообще спорите? Я делаю вполне конкретное заявление: большой проект конкретно на JavaScript сложно читать, сопровождать и поддерживать. А вы уже начинаете мне приписывать фанатизм сторонников статической типизации (к коим я вообще не отношусь).
I>Сейчас вообще пишется однодневок на порядок другой больше. Вот и создается такая иллюзия, что ничего другого и нет.
Вот вы эту иллюзию и пытаетесь развивать куда не надо, пихая node.js в бэкенд. Где ему не место. На что вам резонно отвечают — делаете фронтенд-однодневку — делайте на js (выбора все равно нет). Но на сервере выбор есть, и не в пользу JS.
Здравствуйте, Ikemefula, Вы писали:
I>Опаньки — это пермишны, пути, кеш нугета, какая то хрень с подгрузкой сборок, бд не той версии/схемы. Я бы не сказал, что это большие препятствия. Но вот периодически выстреливают.
Мы на CI-серваке собираем self-contained сборки и через башню заливаем их на целевой сервак. Ну или упаковываем в контейнер (опять же в процессе CI) и загоняем в корпоративное облако. Никаких проблем нет уже минимум пару лет, устанавливать на целевом серваке ничего не нужно, все зависимости таскаем с собой, запускается как любой линуксовый исполняемый файл — ./MyCompany.MyProject.MyApplication.Console. В некоторых случаях можно вообще всё собрать в один исполняемый файл — тогда не нужно будет даже копировать кучу файлов.
Здравствуйте, SkyDance, Вы писали:
SD>пилите на node.js, лишь бы вчера
SD>Я справедливо указываю на "самосбываемость" такого пророчества, т.к. "пиление абы как" нередко и приводит
Почему node.js это обязательно "абы как"? Меньше затрат на борьбу с инструментом, это идеал, к которому бизнес должен стремиться. А не "другие кушают кактус и мы не хуже". Тогда уж, чтоб совсем не абы как, предлагаю пилить микросервис на ассемблере.
Здравствуйте, SkyDance, Вы писали:
I>>Что бы вести речь про качество, нужно сначала узнать требования.
SD>Стоит сначала договорится о терминах. Требования — это такая штука, которая меняется быстрее, чем флюгер у меня около дома направление меняет. Если качество будет прыгать с такой же амплитудой и частотой, вряд ли удастся хоть что-то соорудить.
Качество это степень соответствия требованиям. Если нужно изменить БЛ, а ты не успеваешь, то качество твоего софта уже ниже плинтуса — никому не нужна БЛ для старого подхода.
> За переход на личности — незачет. Крайне невежливо. Особенно не зная собеседника.
Аргумент про своего ребенка тащишь ты сам. Я тебя не оскорбляю, а показываю тебе же, что твой аргумент с твоим ребенком невалидный.
Если ты такой чувствительный — не используй аргумент с ребенком как затычку.
SD>Про "особенности языков с динамической типизацией" предлагаю поговорить тогда, когда вы поработаете в реально больших проектах. Заодно посмотрите теорию на тему сильной/слабой, и статической/динамической типизацией. SD>И если что, type checker'ов для JS наделано куча.
Спасибо, посмеялся. По основной работе у тебя только большие долгострои. Самый короткий проект был 4 года.
SD>Но дело не в них, а в том, что JS реально убог. Популярность же его обеспечена вовсе не удобством или чем-то еще, а всего лишь случайной возможностью оказаться на пустой нише. Как kubernetes — отвратительный, ужасный, organically grown в худшем своем варианте.
Конспирологический аргумент. Возможностей оказаться там же была у целой кучи конкурентов. Все они работали в браузере и все до одного слились.
— куча языков. Ты вероятно даже не подозреваешь, сколько языков в свое время поддерживались браузерами нативно, в конце 90х начале 00х.
— сервлеты
— активикс
— флеш
— сервелат
— разного сорта расширения
Поэтому нет никакой "случайной возможностью оказаться на пустой нише", а была долгая борьба в которой жээсу понадобилось около 10 лет, что бы сбороть бОльшую часть. Последний конкурент — флеш, отгнил всего несколько лет назад.
SD>Вы просто не понимаете, как гиганты работают.
Наблюдаю это изнутри последние 12 лет.
SD>Если вы наивно думаете, что технические свойства того или иного инструмента имеют хоть сколь-нибудь заметное значение — я вас разочарую. Политика и sales, sales и политика.
Сам придумал, сам опроверг.
I>>Вот-вот. Именно этому ты научил своего ребенка. Начатый на ххх проект продолжают заваливать баблом и костылями — я такое видел и на С++, дотнет, джава, итд итд. Причины, как правило, большей частью не в коде, а в менеджменте, архитектуре, требования, сроках и тдю
SD>Опять персональные нападки, теперь уже и ребенку перепадает. Если продолжится, то будете сами с собой беседовать, мне так неинтересно. Причины всегда в политике (деньгах), потом уже догнивает и до менеджмента с архитектурой и сроками.
Итого — мы выяснили, что твой аргумент был невалидным, т.к. причины не в яп, с твоих же слов.
> Опять персональные нападки, теперь уже и ребенку перепадает.
На секундочку — мои высказывания корректны. "На питоне, рубе, и тем более перле с пхп тоже нельзя. " вот это твоя мысль. Скорее всего у ребенка твоё видение мира, потому что именно ты его воспитываешь, а до взрослого, осознанного опыта ему еще лет 7 жить.
не нравится, что я валидирую твои же аргументы с ребенком — не используй их.
I>>Сейчас вообще пишется однодневок на порядок другой больше. Вот и создается такая иллюзия, что ничего другого и нет.
SD>Вот вы эту иллюзию и пытаетесь развивать куда не надо, пихая node.js в бэкенд. Где ему не место.
Голословно. Нода позволяет реализовать очень толковый подход к разработке — бакенд, апи, фронтенд, бд пилятся как части одного целого, при этом облегчается проектирование, планирование, стаффинг, итд. Джава-дотнет вводят языковый и платформенный барьер, который перешагнуть не так то просто.
Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать.
А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Без этого получается так — бакенд это чтото страшное где то там, бд это чтото еще страшнее еще дальше. Из такого подхода и растут ошибки.
Здравствуйте, SkyDance, Вы писали:
SD>Суть моего высказывания в том, что очень часто можно встретить заявления типа "вы стартап и прогорите, потому что 90% стартапов прогорают, а значит, вам не следует использовать технологии, архитектуры и инструменты с прицелом на будущее — пилите на node.js, лишь бы вчера".
Стартапы прогорают не по причине технологий, а по причине того, что конкретный бизнес не даёт эффект. Очевидно, что технологиями решить такую проблему не получится.
SD>Я справедливо указываю на "самосбываемость" такого пророчества, т.к. "пиление абы как" нередко и приводит к тем самым 90%, которые тоже пилили абы как. Потому что им тоже так сказали инвесторы.
Стартап пилится на те ресурсы, что есть у инвестора. Других нет. Ктото инвестирует деньги, ктото инвестирует время.
Отсюда, что нас интересует 1 time-to-market и 2 недорогая разработка.
Все долгосрочные технологические решения только отдаляют п.1 и ухудшают п.2
Отсюда ясно, что нет никакого самосбывающегося пророчества. Ты же сам сказал — перформанс тенического решения слабо коррелирует с перформансом бизнеса. Все ровно то же со стартапом. И прогорают они в основном из за того, что сам бизнес не взлетает или не дает эффекта, на который расчитывали.
Здравствуйте, Ikemefula, Вы писали:
I>Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным.
Это что такое?
I> не надо ждать бакенда, пока он закончит чтото другое, тоже важное
Это что такое?
I> В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Я про инпуты этого итога не понял. Вот как мне представляется весь холивар Java vs Node / Go: на жаве тупо больше букв писать, де-факто фреймворки типа вот спринг бут- такой ужасный black box, который либо магически работает с одной строчки аннотации, либо не работает и ковыряться в кишках его под тоннами наслоений его абстракций. Еще не укушенный александреску, но в том же направлении движение. А нода или го- тяп-ляп и в продакшен, все работает.
I>Без этого получается так — бакенд это чтото страшное где то там, бд это чтото еще страшнее еще дальше. Из такого подхода и растут ошибки.
Фулстек программист может во все это. Мантра "все одним всемогутором разрабатывать"- это к C++ — никам.
Re[27]: Какой язык стоит выбрать для написания микросервисов
I> Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать. I>А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
Остальное поскипал, т.к. оно элементарно вытекает из процитированного выше абзаца.
Который звучит примерно так:
— бэкендеры ну тупыыыые
— фронтендеры ближе к заказчику
— фронтендеры что-то могут пилить на JS, но не умеют дот-нет
Из чего делается вывод "если бэкенд писать на JS, то фронтендеры смогут делать и бэкенд тоже, и будут делать это лучше, чем специализирующиеся на бэкенде люди".
Обычно после этого мне хочется спросить "а не получалось ли так, что вы последение N лет слишком плотно сидели на JS, и ничего другого уже не умеете", но не хочу уподобляться, и переходить на личности. Отмечу лишь, что боюсь лишь одного — что подобные заявления про "миллионы мух не могут ошибаться" все чаще и чаще будут попадать в головы менеджмента и бизнеса. И те, вместо того чтобы слушать грамотных людей, заменят выбор профессионала "демократическим голосованием".
PS: лишь бы и до врачей это не докатилось, когда диагноз будут ставить не по исследованию профессионала, а путем голосования 20 джуниоров.
Здравствуйте, Артём, Вы писали:
I>>Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. I>> не надо ждать бакенда, пока он закончит чтото другое, тоже важное Аё>Это что такое?
Это правильный подход к фулстек разработке. Используем архитектуры вида bff, edge-services итд. То есть, у нас АПИ это не "вон то и там, пилится бакендами, когда у них приоритеты позволят" а "мы делаем для себя, что бы приложение работало так как ожидает приёмка"
Здравствуйте, SkyDance, Вы писали:
I>> Фронтенды не умеют дотнет, а бакенды не умеют фронтенд. Это оксюморон — они только думают, что знают фронтенд. Большей частью это иллюзии вида "а чо там думать, там же всё тривиально" из чего рождаются дикие чудовища и самопальные велосипеды, которые никто не может поддерживать. I>>А вот на ноде элементарно и естественно передать фронтам построение апи для фронтенда, которое меняется с той же частотой, что и треботвания. При этом устраняются проблемы с горизонтальными зависимостям — не надо ждать бакенда, пока он закончит чтото другое, тоже важное В итоге продуктивность команды будет наголову выше чем в другом стеке технологий.
SD>Остальное поскипал, т.к. оно элементарно вытекает из процитированного выше абзаца. SD>Который звучит примерно так: SD>- бэкендеры ну тупыыыые
Это твоя интерпретация на твоём личном опыте. На самом деле чистый бакенд в общем не в курсе, что конкретно нужно фронтенду, почему это нужно, и приоритеты у него другие в силу естественных причин. Отсюда и сложности. Например — бакенд в шоке от того, что фронты тащут 20мб данных при релоаде или шлют 50 запросов на каждый чих. Причины как правило находятся в том, что бакенд и фронтенд это разные команды/люди/менеджеры/бюджеты/приоритеты. И в силу такого разделения крайне трудно управлять лавиной мелких изменений в требованиях каждое из которых потенциально требует того самого согласования.
Вместо этого нужно отдать фронтам возможность перепиливать апи по их усмотрению.
SD>- фронтендеры ближе к заказчику
Это факт.
SD>- фронтендеры что-то могут пилить на JS, но не умеют дот-нет
В основном — нет, как и наоборот. Более того, совмещая такие вещи люди как правило все равно остаются в своем стеке примерно 80/20 или 20/80. Такая особенность сильно ограничивает в решении сложных задач, которые периодически возникают.
Потому изоморфные приложения гораздо выгоднее, тк. человек осваивает вариации одной платформы.
SD>Из чего делается вывод "если бэкенд писать на JS, то фронтендеры смогут делать и бэкенд тоже, и будут делать это лучше, чем специализирующиеся на бэкенде люди".
SD>
SD>Обычно после этого мне хочется спросить "а не получалось ли так, что вы последение N лет слишком плотно сидели на JS, и ничего другого уже не умеете", но не хочу уподобляться, и переходить на личности. Отмечу лишь, что боюсь лишь одного — что подобные заявления про "миллионы мух не могут ошибаться" все чаще и чаще будут попадать в головы менеджмента и бизнеса. И те, вместо того чтобы слушать грамотных людей, заменят выбор профессионала "демократическим голосованием".
Собственно ты целым абзацем выразил чтото среднее между "так не правильно" и "я не согласен". Есть у тебя какие более развернутые аргументы?
Re[28]: Какой язык стоит выбрать для написания микросервисов
Здравствуйте, Ikemefula, Вы писали:
I>>>Например, сделать consumer driven api бакенда на дотнете/джаве не представляется возможным. I>>> не надо ждать бакенда, пока он закончит чтото другое, тоже важное Аё>>Это что такое?
I>Это правильный подход к фулстек разработке. Используем архитектуры вида bff, edge-services итд.
Молодцы, что используете. У нас эти BFF / edge / microservices на Springboot. Фуллстек пилят и жаву, и тайпскрипт, монго, скуль. Хотя чистые веб-фронт получше знают css.
Здравствуйте, Ikemefula, Вы писали:
I>Это твоя интерпретация на твоём личном опыте. На самом деле чистый бакенд в общем не в курсе, что конкретно нужно фронтенду, почему это нужно, и приоритеты у него другие в силу естественных причин. Отсюда и сложности.
Это лечится режимом frontend first. Т.е. фронтендеры выдают свои требования к бэку, можно даже в виде мока-прототипа на ноде, а потом бэкендеры приводят это в работающее состояние.