Здравствуйте, Farsight, Вы писали:

I>>Шериданство во всей красе. Html не в базе генерирует, и то хорошо.
F>Это же не весь код. Может, это только верхушка айсберга.
Рядом ссылка не репозиторий. Развлекайтесь раз вам весело ))

Здравствуйте, Sheridan, Вы писали:

S>Здравствуйте, Farsight, Вы писали:

S>Про ситуацию где разрабы вынуждены брать в руки говно никто не говорит. Посочувствую, но и только ибо выбора у них нет.
Чего? При чем тут твое говно? Почему не может быть два шикарных продукта от двух поставщиков на разных, опять же шикарных, версиях либ?

F>>Зачем повторять? Это же никого не интересует.
S>Да потому что вы не слышите.
Выделил.

Здравствуйте, Sheridan, Вы писали:

S>Рядом ссылка не репозиторий. Развлекайтесь раз вам весело ))
Ты уже овер 15 лет нас тут развлекаешь.

Здравствуйте, Sheridan, Вы писали:

S>>>Ну то есть такое возможно и без траты года на изучение? Или нет?
I>>Это не разработка. Когда говорят разработка, то это перемалывание длительных задач, деливери решений проблем именно бизнеса.
S>Без декомпозирования, одно ТЗ в одно лицо одним таском?

Какая разница, сколько тз и сколько людей?

I>>Жалобы на тормоза были и будут во все времена, хоть на С++, хоть на Ноде, хоть на чем угодно.
S>Соглашусь но скажу только чем низкоуровнее язык тем меньше будет жалоб.

Ога. Тормоза большей частью берутся не от языка, а от ошибок в разработке, вынужденных, и невынужденных.
С++ники такие же люди, как и другие разработчики, а потому им свойственно делать ошибки "у нас всё быстро, незачем и думать"

I>>Никакой связи. Хороший продукт это минимум три вещи, в порядке убывания важности — требования, контроль качества, квалификация команды.
S>Ну тогда и ноды не будет.

Наоборот

I>>Решение уже найдено — бакендов на фронт не пускать. Дешевле дать ноду фронтендам, и ограничить их архитектурно, например, module federation + edge service.
S>Опять бабло.

Именно. Такое решение оказалось наибоее жизнеспособным.

I>>И с дотнетом был тоже самое, и с джавой, и с питоном.
S>И все ржут до сих пор? На чом же тогда писать если куда ни плюнь — все ржут до сих пор?

Ржут до сих пор с веба на с++
Взгляни на себя http://rsdn.org/forum/flame.comp/5791789.1

Автор: Sheridan
Дата: 22.09.14

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

I>>бОльшей частью этот софт фактически несложный CRUD с небольшими вариациями. И вот для него крайне критичен хороший фронтенд. А раз так, то нода справится очень хорошо.
S>А питон ещо лучше. А плюсы ещо лучше.

Питон — хуже, т.к. на нем не будет хороших фулстеков. Хорошие фулстеки только на ноде.

Здравствуйте, Sheridan, Вы писали:

I>>Хороших примеров ты не видел, но утверждаешь, что их нету. Это специфика твоей работы — ковбойские интервенции. Там где все хорошо, тебя туда не зовут.
S>Но опыта у меня нет, ага.

http://rsdn.org/forum/flame.comp/5791789.1

Автор: Sheridan
Дата: 22.09.14

Вот этот твой код говорит о том, что ты пишешь как вечный студент. Не думаю, что ситуация изменилась за 8 лет.

I>>Не нашлось, что очевидно. Что там у тебя? "Уууу, тормоза, уууу, говнокод". Что конкретное есть? А то я тормоза и говнокод чаще всего видел/вижу в джаве и С++.
S>А я в жаве и ноде. Реже в питоне.

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

I>>Качество кода имеет в среднем довольно слабое влияние на прибыль бизнеса. Такая вот жизнь. Слишком часто бывает так, что дешевле раз на говнокодить, а потом год суппортить, чем наоборот. Нынче слишком важен time to market.
S>Поэтому в основном говно на руках и имеем.

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

Здравствуйте, Sheridan, Вы писали:

I>>А в продакшне значит хост можно хламить, да?
S>А в продакшене `apt install lib1 lib2 lib3 myproject`, следом настройка и запуск.

И как ты будешь совмещать компоненты, которые написаны на разных версиях джавы/дотнета/С++/питона ?

Здравствуйте, Sheridan, Вы писали:

НС>>Да хоть обзаглядывайся, только цель микросервисов вовсе не борьба с зависимостями библиотек.
S>Я с самого начала и сказал — обмазали корни красивыми словами и делают вид что всё ок.

Если в руках молоток — все вокруг кажется гвоздями.

S>>>Тебе же даже в вики написали: "программисты не осиливают единую кодовую базу, поэтому бьётся на отдельные проекты".
НС>>В вики такого не написано, зачем ты врешь?
S>Та фраза, которую ты цитировал фактически об этом и говорит.

Нет.

Здравствуйте, Sheridan, Вы писали:

S>>>Ты про скрипты к Space Engineers на шарпе?
НС>>Я про все твои экзерсисы. Какую то хрень для мониторинга, твои потуги по написанию сайта на С++,
S>Завидуй молча.

Было б чему.

Все что нужно знать про полезность твоего кода.

Здравствуйте, SkyDance, Вы писали:

S>>Это как? Ну генерируется у меня этот json хоть из dsl, на нем что ли теперь писать? Можно подробнее идею подраскрыть?
SD>Подробнее: самый главный язык — тот, на котором говорят все. То бишь тот самый DSL. И это, в общем-то, тупик, на мой взгляд. Заведомо проигрышная идея.
SD>Чтобы понять, что я имею в виду, нужно поразмышлять над "schema first vs code first" и над "configuration complexity clock", последней стадией усложнизма (где конфигурация становится ни чем иным, как кодом, написанным на другом языке).

Хорошо, code first плохо, схема генерируется простеньким DSL (типа xml подобного языка на коленке), а у нас речь о микросервисах. Как быть?
Я так понимаю, что в данном случае xml подобный язык это вариация code first или нет?

SD>Если начинать со "схемы" (и DSL), этот язык и становится тем, на чем пишутся ваши микросервисы. Сама идея "генерации кода" глубоко порочна, я считаю. Вместо этого следует иметь возможность экспорта обработчиков сообщений (как это было сделано еще черт-те знает когда, в Windows, а то и еще раньше).

О чем речь, о каких обработчиках и для чего?

S>А если проект вырастет за пределы "склеить пару строк"? Что тогда? Стек поменяют или начнут игры с совой и глобусом? Учитывая тот факт что "а от стек выбран, команда есть, проект пилится, балобаблобабло" — очевидно что сове не повезло.

Классика же, самоподдерживающееся пророчество.
На основе прошлой статистики известно, что 90% новых проектов пойдут в мусорку. Поэтому технология не имеет значение — лишь бы быстрее (time to market). А раз так, то зачем думать о будущем — пилить надо. Что, в свою очередь, может косвенно вести к провалу проекта (из-за немасштабирующейся технологии). Какой будет сделан вывод? Правильно, все тот же, 90% проектов пойдут в мусорку...

PS: забавно, что про всякие там stock market большими буквами пишут "past performance is not an indication of the future performance". Про стартапы, однако, так не пишут.

САД>даже сейчас, достаточно опытных JS-девелоперов, можно завалить хитрыми вопросами, да и сами они могут накосячить не мало.

Профессионализм состоит в том, чтобы не лезть в "хитрые вопросы" когда не надо. А если надо — то иметь чутье и... умение читать код. Который все эти "хитрые вопросы" делает бесхитростными. Так что кривая одинакова, и зависит в основном от общей сложности (complexity) фреймворка. Косвенный показатель — возраст и количество строчек, чем больше, тем хуже (E = mc2, errors = more * code ^ 2).

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

Вот это сильное заявление. "Месье знает тольк в извращениях" (С)
Делать бэкенд на нод.жс звучит как проклятие для сколь-нибудь масштабных проектов.

Здравствуйте, Sheridan, Вы писали:

S>Про потоки слышал? Пока один одни данные ждёт — ко второму ещо клиент приходит.

Слышал. В C# асинхронщину вообще завезли. Задачу создал, запустил, и т. д. Но как асинхронщина поможет, если я обратился к, назовем это так, главному компьютеру, и мне нужно дождаться результата. А все остальное уже выполнено. А служба, отвечающая за связь с Главным Компьютером, не умеет в многопоточность. Пример, кстати, реальный. Эту службу потом заменили, но несколько лет она работала.

S>Исключения — нештатное, форсмажор. Чтото пошло совершенно не так.

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

S>А чего ты тогда?

Я просто ничего не понял, чего ты спрашиваешь.

S>Перегибаешь.

Нет. Но все равно, в КСВ можно.

S>И у меня был. Неделю искал. ЧСХ, с умным указателем связано было. Что именно — не помню — лет пять прошло.

Небось auto_ptr в функцию передавал?

Вот, а сборщик мусора помогает как раз в таких случаях. Заметь, я не утверждаю, что он решает проблемы. Он только инструмент. Но в случае серверов очень помогает.

S>Создал — объект пожил — удалил.

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

P>А это я не вполне понимаю. Почему именно нода? Протокол решает. Формат данных согласовать, всего делов.

Так точно.
Cобственно, с этого я и начал

Автор: SkyDance
Дата: 04.06.22

Здравствуйте, Ikemefula, Вы писали:

I>Штука в том, что фронт меняется очень часто, и все время растет в сложности по ряду причин.

Меняется, это заметно. Я в вебе полный теоретик и не знаю, с чем оно связано.
<Режим КСВ>
Когда-то личный кабинет банка летал со свистом на нетбука с Атомом. А сегодня не спеша открывается на новом i5, причем проц загружен на 100%.
<Режим КСВ>

I>1 АПИ для фронта меняется не просто часто, а непрерывно — каждая фича или фикс требует чего нибудь особенного. На согласовании далеко не уедешь. Ждать бакендов, пока они раздуплятся и понаделывают роуты, неэффективно.

Ну, мы на middleware сидели. Возможно, фронт обращался к каким-то своим баазам плюс там система безопасности работала. А у нас все стабильно было.

I>*горизонтальные зависимости — это нарезка обязанностей, когда девелопер отвечает за слой. Вроде бы эффективно, но плохо масштабируется, слишко часто вся команда ждет одного такого товарища. эффективнее нарезать обязанности вертиально — когда девелопер может сделать всё, или близко к этому. Главное не увлекаться погоней за всемогуторами, ибо каждый всемогутор это сначала шеридан, а уже потом, возможно, девелопер

Я сейчас не всегда могу вертикально. У нас идет обращение к неким сервисам, работающим в других странах.

I>Кривая зависит в первую очередь от технологии, сколько всего нужно освоить, что бы выполнять разные задачи. Например, джава и дотнет предоставляют конское количество всяких апишек — коллекции, многозадачность, утилиты всех сортов, бд, итд. т.е. стандартная библиотека просто конская.
I>Джаваскрипт по большому счет вообще ничего не предоставляет. Да и нода вобщем недалеко ушла.

"Complexity has to live somewhere" (C)
Более того, фрагментированные "organically grown" языки, среди которых джаваскрипт пожалуй что самый яркий пример "органик роста", куда хуже для понимания, чем спроектированные с нуля с определенными требованиями к дизайну.

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

Другие языки — скажем, Haskell — имеют продуманный фундамент. Его сложнее понять на старте, но поняв, уже не требуется сверяться на каждый чих со stackoverflow в поисках подводных грабель. Поэтому на определенном этапе кривые обучения могут находиться выше или ниже, но в среднем разница будет невелика.

I>Отсюда ясно, почему фронтенд-разработчики начинают работать чуть не на старте обучения.

Это не из-за языка, а из-за короткого срока жизни их продукта. Бэкенд часто имеет длинный lifecycle, где требуется upfront investment, чтобы не пришлось переписывать все оптом, как это часто происходит с фронтом.

I>*горизонтальные зависимости — это нарезка обязанностей, когда девелопер отвечает за слой. Вроде бы эффективно, но плохо масштабируется, слишко часто вся команда ждет одного такого товарища. эффективнее нарезать обязанности вертиально — когда девелопер может сделать всё, или близко к этому

Это одно из самых занятных определений микросервисов (горизонтальная нарезка). Для того, чтобы не ждать "одного товарища", давайте сделаем 25 разнородных стеков. Потому что так дешевле — не надо никого учить, сами научатся тому стеку, который им по душе.

Что попросту переносит сложность с микросервисов на оркестратор таковых, и на их интеграцию. Complexity has to live somewhere.

I>А это про реляционки или вещи в т.ч. типа бигдаты, очереди какие? Не сильно знаю, что насколько гладко в дотнете с этим.

Кхе кхе. Как имеющий некое отношение к "бигдате", отмечу, что "бигдата" есть не что иногда как "не смогли масштабировать SQL, поэтому вручную решаем все те же задачи".

I>Я не специалист по БД. Что вместо монги стоит брать из no-sql на бакенде?

Сначала стоит ответить на вопрос "почему no-sql", а перед этим — "что есть nosql". Ибо последнее чаще всего "у нас такой бардак, что мы не можем привести наши данные даже в 1НФ, а посему мы не будем и пытаться, пусть будет абыкак, зато сегодня покажем прототип".

S>Контейнеры это в первую очередь когда две команды не осилили взаимодействие между собой и поприкрутили к своим проектам разные версии библиотеки. Не обновлять же! есть же изоляция!

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

Суть же, как всегда, в создании еще одного уровня абстракции и API над ним (API работы с контейнерами).

Как известно, в программировании любая проблема может быть решена путем введения еще одного уровня абстракции.
Кроме...