Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Сначала у меня никакой команды нет.
НС>Стартап шоле?
Когда то же разработка начинается. Вот запускается новый продукт. Что делать? С чего ты взял, что разработчики уже есть? В конторе то они может и есть — разные стеки, разные ЗП, разная квалификация. Дальше то надо укомплектовать команду.
Кого будем брать в эту команду?
I>>Вопрос — кого нанимать что бы это было эффективно? НС>Именно. Поэтому крайне странно уповать на сложность освоения стека с нуля. Нанимать на новый проект нулевых людей — безумству храбрых.
Кривая вхождения в стек влияет на все аспекты. Ключевая вещь — простые задачи. Новый проект или не новый, дело как раз десятое.
I>>Кривая вхождения влияет на всю экономику проекта и конторы. Скажем, когда контора готовит своих людей, что сейчас норма
НС>Это крайне спорное утверждение. Более менее крупные конторы, конечно, своих людей, вне всякого сомнения, готовят, но ни разу не видел чтобы это составляло основную часть разработчиков.
Кривая вхождения в стек влияет на все аспекты, в том числе и на найм.
I>>Не все ведь задачи одной сложности. бОльшая часть задач они достаточно простые.
НС>Опять же, слишком смелое утверждение. У меня на текущем проекте, к примеру, простых задач очень мало.
А разве речь про твой проект? Я же сказал — Нода берется там где задачи достаточно простые. Очевидно, что речь не про твой проект.
I>>В силу кривой вхождения польза от мидла на ноде и мидла на дотнете/джаве сильно разная.
НС>Это утверждение нуждается в доказательствах. Вот микросервисы — тут да, ради этого и придумывалось. А вот чтобы на ноде задачи одинаковой сложности решались проще — это очень спорно. Принцип использования мидлов в сложных проектах один
Я пишу про простые задачи, а не использование мидлов в сложных проектах.
I>> Например, full stack на джава-дотнете это профанация, если за ним не стоит 10-20 лет опыта. Или это будет фронт, который посредственно знать бакенд, или наоборот. А вот на ноде в силу изоморфизма всё решительно иначе.
НС>Ты же помнишь что речь в топике про бэк и микросервисы?
А в микросервисах простых задач не бывает что ли? Я как раз раз разрабатываю/поддерживаю фремворк для похожих целей. Его некоторые проекты адаптировали в т.ч. под микросервисы. Для этого даже ушли с джавы.
> Совмещение фронта и бэка в одной небольшой команде имеет смысл только в совсем небольших проектах, либо в проектах, у которых сильная изоляция между вертикальным набором фронт-бек (проект, грубо говоря, представляет собой набор слабо связанных мини-приложений, у каждого из которых свой UI).
Я и пишу про такие проекты. У них бывает и бакенд, и даже микросервисы.
НС>Еще раз. Неважно сколько их учить, важна разница в зарплате уже наученных. Я большой разницы между спецами одного уровня, использующими джаву, дотнет или ноду не вижу.
В том то и дело, что важно. Кривая вхождения влияет на все аспекты.
НС>Нанимать отдельных студентов под простые задачи тоже, мягко говоря, не всегда рационально.
К сожалению индустрия пошла именно по этому пути. У нас полно студентов, которые посильнее мидлов и даже сеньоров во многих странах. А это значит, что бОльшая часть идустрии имеет квалификацию, которую можно заполучить у студента.
Здравствуйте, vaa, Вы писали:
S>> Специалисты получают примерно одинаково на любом языке. А вот джуниоры наговнят на любом языке. S>> Я бы выбрал C# c Native AOT http://rsdn.org/forum/flame.comp/8286600.1
Здравствуйте, Ikemefula, Вы писали:
I>С чего ты взял, что разработчики уже есть? В конторе то они может и есть — разные стеки, разные ЗП, разная квалификация. Дальше то надо укомплектовать команду. I>Кого будем брать в эту команду?
Обычно приоритет отдается внутренним кандидатам. При этом как правило контора тяготеет к какому то одному стеку, хотя возможны и другие. И только если внутри не удалось никого найти — тогда идем на рынок.
I>>>Не все ведь задачи одной сложности. бОльшая часть задач они достаточно простые. НС>>Опять же, слишком смелое утверждение. У меня на текущем проекте, к примеру, простых задач очень мало. I>А разве речь про твой проект?
А разве это я делаю на основании конкретных случаев безусловные обобщения?
I>Я же сказал — Нода берется там где задачи достаточно простые.
Нет, ты сказал что c#/java/go дорого, причем не уточняя что речь только про студенческие проекты.
НС>>Ты же помнишь что речь в топике про бэк и микросервисы? I>А в микросервисах простых задач не бывает что ли? Я как раз раз разрабатываю/поддерживаю фремворк для похожих целей.
Как ты там только что писал? "А разве речь про твой проект?"
>> Совмещение фронта и бэка в одной небольшой команде имеет смысл только в совсем небольших проектах, либо в проектах, у которых сильная изоляция между вертикальным набором фронт-бек (проект, грубо говоря, представляет собой набор слабо связанных мини-приложений, у каждого из которых свой UI). I>Я и пишу про такие проекты.
Ну то есть утверждение про то что c#/java/go дорого относится исключительно к небольшим несложным проектам со студентами в качестве разработчиков? Если бы сразу это небольшое уточнение сделал, ни у кого бы возражений не было.
НС>>Нанимать отдельных студентов под простые задачи тоже, мягко говоря, не всегда рационально. I>К сожалению индустрия пошла именно по этому пути.
Нет. Есть разные проекты.
I> У нас полно студентов
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Обычно приоритет отдается внутренним кандидатам. При этом как правило контора тяготеет к какому то одному стеку, хотя возможны и другие. И только если внутри не удалось никого найти — тогда идем на рынок.
В любом случае выбираем исходя из потребностей, а не абы посильнее.
НС>>>Опять же, слишком смелое утверждение. У меня на текущем проекте, к примеру, простых задач очень мало. I>>А разве речь про твой проект?
НС>А разве это я делаю на основании конкретных случаев безусловные обобщения?
А какой смысл в утверждениях "на моём проекте" ? Подавляющее большинство новых проектов никакой сложностью не обладают. Тем не менее они важные и нужные. Т.е. обычный CRUD с простым апи и никакого рокет саенса.
I>>Я же сказал — Нода берется там где задачи достаточно простые.
НС>Нет, ты сказал что c#/java/go дорого, причем не уточняя что речь только про студенческие проекты.
Похоже, ты начал в чучелко играть. Вроде ясно было сказано, что студенческий проект это __иллюстрация__.
И похоже аргументы про кривую вхождения ты пропустил мимо ушей.
НС>>>Ты же помнишь что речь в топике про бэк и микросервисы? I>>А в микросервисах простых задач не бывает что ли? Я как раз раз разрабатываю/поддерживаю фремворк для похожих целей.
НС>Как ты там только что писал? "А разве речь про твой проект?"
Мне приходится взаимодействовать с целой кучей людей из разных подразделений, разные продукты, проекты и тд. Потому речь именно что не про мой проект.
НС>Ну то есть утверждение про то что c#/java/go дорого относится исключительно к небольшим несложным проектам со студентами в качестве разработчиков? Если бы сразу это небольшое уточнение сделал, ни у кого бы возражений не было.
Цитирую себя " для простых задач", "на простых проектах". Таких проектов/задач нынче большинство. Собственно, простых задач/проектов большинство во все времена. Странно это отрицать.
НС>>>Нанимать отдельных студентов под простые задачи тоже, мягко говоря, не всегда рационально. I>>К сожалению индустрия пошла именно по этому пути.
НС>Нет. Есть разные проекты.
Проекты есть разные, а простых — большинство. Самый частый кейс — обычный CRUD с простым API.
I>> У нас полно студентов
НС>"А разве речь про твой проект?"
У нас — это в данном случае про Беларусь. И я утверждаю, что в большинстве стран мидлы и даже сеньоры будут послабее.
I>А какой смысл в утверждениях "на моём проекте" ? Подавляющее большинство новых проектов никакой сложностью не обладают. Тем не менее они важные и нужные. Т.е. обычный CRUD с простым апи и никакого рокет саенса.
Ну вот и блазор под это прекрасно подходит. Одна модель на сервере и клиенте. И джуниоров полно. Там не сложней чем ангулар или реакт.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
НС>>А разве это я делаю на основании конкретных случаев безусловные обобщения?
I>А какой смысл в утверждениях "на моём проекте" ?
Ты тоже делал такие утверждения, так что ответ дддолжен быть тебе известен.
I> Подавляющее большинство новых проектов никакой сложностью не обладают.
Опять смелое заявление без каких либо доказательств.
НС>>Нет, ты сказал что c#/java/go дорого, причем не уточняя что речь только про студенческие проекты. I>Похоже, ты начал в чучелко играть. Вроде ясно было сказано, что студенческий проект это __иллюстрация__.
Назови как хочешь. В любом случае проект, на который можно нанять большинство людей с нулевым бекграундом — это довольно специфический проект.
I>И похоже аргументы про кривую вхождения ты пропустил мимо ушей.
А там были аргументы? Там было бездоказательное утверждение, повторенное несколько раз, эдакая халва-халва.
НС>>Как ты там только что писал? "А разве речь про твой проект?" I>Мне приходится взаимодействовать с целой кучей людей из разных подразделений, разные продукты, проекты и тд.
И? Это что то меняет?
I>>> У нас полно студентов НС>>"А разве речь про твой проект?" I>У нас — это в данном случае про Беларусь.
У вас студентов сопоставимо с общим числом разработчиков? Что то гложут меня смустные сомнения.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Нет, ты сказал что c#/java/go дорого, причем не уточняя что речь только про студенческие проекты. I>>Похоже, ты начал в чучелко играть. Вроде ясно было сказано, что студенческий проект это __иллюстрация__.
НС>Назови как хочешь. В любом случае проект, на который можно нанять большинство людей с нулевым бекграундом — это довольно специфический проект.
Такое нынче положение дел во многих странах. Типичный проект это CRUD с небольшим API. Это я сужу по всем доступным мне источникам.
I>>И похоже аргументы про кривую вхождения ты пропустил мимо ушей. НС>А там были аргументы? Там было бездоказательное утверждение, повторенное несколько раз, эдакая халва-халва.
Ты снова хочешь, что бы ради форумной беседы я тебе монографию предоставил?
НС>>>Как ты там только что писал? "А разве речь про твой проект?" I>>Мне приходится взаимодействовать с целой кучей людей из разных подразделений, разные продукты, проекты и тд.
НС>И? Это что то меняет?
Именно: один — много. Еще и разница по странам видна.
НС>>>"А разве речь про твой проект?" I>>У нас — это в данном случае про Беларусь.
НС>У вас студентов сопоставимо с общим числом разработчиков? Что то гложут меня смустные сомнения.
Я сравниваю уровень студентов с уровнем специлистов в других странах. При чем здесь общее число разработчиков?
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, vaa, Вы писали:
S>>> Специалисты получают примерно одинаково на любом языке. А вот джуниоры наговнят на любом языке. S>>> Я бы выбрал C# c Native AOT http://rsdn.org/forum/flame.comp/8286600.1
S>>>Легковесный, но со сборщиком мусора
vaa>>17МБ приветмир, легковесно, однако! S> Ты хоть пример то приведи! То есть пример https://github.com/dotnet/runtime/tree/main/src/samples S>весит 17МБ?
S> Ты пробовал?
Так точно!
Здравствуйте, Ikemefula, Вы писали: I>Типичный кейс — ментор команды дотнета пытается объяснить фронтам как ихний бакенд собрать, развернуть, настроить. Вот почему то такой херни на ноде как то не выходит, все само работает. В итоге у одних фронт и бек друг о друге не знают даже на финише, а у других это есть прямо со старта.
О, это интересно. Я тут подумываю возродить дотнет в нашем универе.
В чём именно проблема с собиранием и развёртыванием ихнего бэкенда?
Там же вроде просто ставишь дотнет клац-клац инсталлером, а дальше — чекаут из гита, и dotnet run.
Буквально всё, что я пробовал из альтернатив — в разы сложнее. Даже джава, которая вроде используется в сотню тысяч раз чаще — и то вечно какой-то геморрой. Начиная от мучительных поисков JAVA_HOME, и заканчивая отсутствием концепции стандартного пакет-менеджера.
Студенческие проекты по моему курсу можно писать на чём угодно — задана только база (https://postgrespro.ru/education/demodb) и требования к сервису.
Несут, что характерно, в основном джаву/спринг. Изредка котлин или какой-нибудь питон.
На ноде пока что не было никого.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>> Ты пробовал? vaa>Так точно!
Ну вот редиска ты!
Генерится нативная Microsoft.Interop.Tests.NativeExportsNE.dll библиотека размером 945 кб. Там еще 2 дополнительные Microsoft.Interop.Tests.NativeExports.dll и Microsoft.Interop.Ancillary.dll по 20 и 12 кб
Вызов из .Net такой
namespace Demo
{
internal static partial class NativeExportsNE
{
public const string NativeExportsNE_Binary = "Microsoft.Interop.Tests." + nameof(NativeExportsNE);
[LibraryImport(NativeExportsNE_Binary, EntryPoint = "sumi")]
public static partial int Sum(int a, int b);
[LibraryImport(NativeExportsNE_Binary, EntryPoint = "sumouti")]
public static partial void Sum(int a, int b, out int c);
[LibraryImport(NativeExportsNE_Binary, EntryPoint = "sumrefi")]
public static partial void Sum(int a, ref int b);
}
internal static class Program
{
public static void Main(string[] args)
{
int a = 12;
int b = 13;
int c = NativeExportsNE.Sum(a, b);
Console.WriteLine($"{a} + {b} = {c}");
c = 0;
NativeExportsNE.Sum(a, b, out c);
Console.WriteLine($"{a} + {b} = {c}");
c = b;
NativeExportsNE.Sum(a, ref c);
Console.WriteLine($"{a} + {b} = {c}");
}
}
}
Там далеко не ПриветМир.
namespace NativeExports
{
public static unsafe class Demo
{
[UnmanagedCallersOnly(EntryPoint = "sumi")]
public static int Sum(int a, int b)
{
return a + b;
}
[UnmanagedCallersOnly(EntryPoint = "sumouti")]
public static void SumOut(int a, int b, int* c)
{
*c = a + b;
}
[UnmanagedCallersOnly(EntryPoint = "sumrefi")]
public static void SumRef(int a, int* b)
{
*b += a;
}
}
}
И еще куча классов для тестов.
например
public static unsafe class DelegatesAndFunctionPointers
{
[UnmanagedCallersOnly(EntryPoint = "invoke_callback_after_gc")]
public static void InvokeCallbackAfterGCCollect(delegate* unmanaged<void> fptr)
{
// We are at the mercy of the GC to verify our delegate has been retain
// across the native function call. This is a best effort validation.for (int i = 0; i < 5; ++i)
{
GC.Collect();
GC.WaitForPendingFinalizers();
}
// If the corresponding Delegate was collected, the runtime will rudely abort.
fptr();
}
[UnmanagedCallersOnly(EntryPoint = "invoke_managed_callback_after_gc")]
public static void InvokeManagedCallbackAfterGCCollect(void* fptr)
{
// We are at the mercy of the GC to verify our delegate has been retain
// across the native function call. This is a best effort validation.for (int i = 0; i < 5; ++i)
{
GC.Collect();
GC.WaitForPendingFinalizers();
}
// If the corresponding Delegate was collected, the runtime will rudely abort.
((delegate*<void>)fptr)();
}
[UnmanagedCallersOnly(EntryPoint = "invoke_callback_blittable_args")]
public static int InvokeCallbackWithBlittableArgument(delegate* unmanaged<int, int, int> fptr, int a, int b)
{
return fptr(a, b);
}
[UnmanagedCallersOnly(EntryPoint = "invoke_managed_callback_blittable_args")]
public static int InvokeManagedCallbackWithBlittableArgument(void* fptr, int a, int b)
{
return ((delegate*<int, int, int>)fptr)(a, b);
}
}
НС>Опять же, слишком смелое утверждение. У меня на текущем проекте, к примеру, простых задач очень мало. Настолько, что всех джунов пришлось убрать, а новым разработчикам для вхождения в проект даже на пару-тройку месяцев наскрести задач вызывает затруднение. Так что не обобщай.
И что с ними сталось? Сократили или лычки на мидлов поменяли? Или речь о вакансиях?
Кодом людям нужно помогать!
Re[2]: язык (source of truth) будет язык схемы для этого JSON
Здравствуйте, SkyDance, Вы писали:
SD>Тот, на котором микросервисы будут общаться. Как пример — это это HTTP + JSON, то основной язык (source of truth) будет язык схемы для этого JSON, если это Microsoft COM — тогда Microsoft IDL, и так далее. SD>А уж на чем реализовывать, значения не имеет. Хоть на node.js.
Это как? Ну генерируется у меня этот json хоть из dsl, на нем что ли теперь писать? Можно подробнее идею подраскрыть?
Здравствуйте, Sheridan, Вы писали:
S>А потом ноду пропихивают в бакенд.
Попробую догадаться, чем это плохо. Нет многопоточности? Но если функционал- склеить результат из параллельных запросов и вернуть, то нод вполне справится обним потоком. Он же асинхронный by design. Наспаунить пачку инстансов в облаках.
Re[2]: Какой язык стоит выбрать для написания микросервисов
DP>- для главы разработки/начальник отдела/CTO — тот, на котором больше всего есть разработчиков в наличии в штате, а также которых проще и дешевле нанять с рынка, а плюс, на экосистему которого уже тратятся деньги (IDE, оплата фреймворков, обучениях/курсы/тематические конференции для разработчиков и прочее)
Провальный, кстати, вариант. В основном имеет смысл в индус-трии, где важно "количество разработчиков в штате", а не создание работающего продукта.
Здравствуйте, Ikemefula, Вы писали:
I>>>Именно так и происходит. Только еще собеседование добавляется, что бы проверить на сколько кандидат владеет конкретным стеком и какие у него коммуникационные способности S>>Угу. И бюджет бездонный и работы овер100500. I>Бюджеты всегда ограничены. Потому и нет кейса "пиши на чом хошь".
Но людей нанимают по первому их желанию
, да?
S>>Очень важно накапливать опыт в разных областях, чтобы плесенью не покрыться. I>Смена технологического стека мало что меняет, на самом деле. Гораздо бОльшее влияние даст смена предпметной области или даже поля деятельности. I>Скажем, если ты решил идти в архитекторы, то далеко не факт, что попрыгав по стекам ты достигнешь эту цель быстрее.
Спасибо, кэп.
I>>>Если же наплодить кучку подразделений дотнет, джава, итд, то получается так — хочет товарищ поменять проект, опаньки, а там другой стек. Как правило, это является существенным препятствием и далеко не все программисты/менеджеры решаются на такой шаг. S>>И что если другой стек? Какие-то сложности? I>А ты попробуй найти работу дотнет разработчиком, Node разработчиким, фронтендом. Походи по собеседованиями да узнаешь. Получи оффер, посмотри, насколько легко будет убедить ту сторону, что ты можешь работать эффективно.
Мне достаточно повернуть голову и сказать "поцоны, давайте таски про дотнет и студию — хочецца попогроммировать".
I>Самое первое с чем сталкиваешься — при переходе в новый стек тебе приходится повторно осваивать платформу. И вот как ни странно, технически это может идти в плюс, но вот на ЗП часто сказывается в минус, особенно в краткосрочной перспективе.
Я хз что ты там имеешь в виду под платформой, но, кэп, ты сегодня в ударе.
Matrix has you...
Re[20]: Какой язык стоит выбрать для написания микросервисов
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>>>Ага, приходит такой программист в компанию и говорит: "Мне ваш стек нравится, завтра приду работать у вас. НС>>>Примерно так, да. И именно поэтому в вакансиях пишут про тот самый стек. S>>Ах, по вакансии. Яснопонятно. НС>Что то ты все позорнее и позорнее сливаешься. Не твои ли слова
? Не ты ли писал что достаточно прити в компанию и сказать "мне ваш стек нравитса — я у вас поработаю" и опа — ты там работаеш. Или щас начнёца карусель "это другое"?
Matrix has you...
Re[3]: язык (source of truth) будет язык схемы для этого JSON
S>Это как? Ну генерируется у меня этот json хоть из dsl, на нем что ли теперь писать? Можно подробнее идею подраскрыть?
Подробнее: самый главный язык — тот, на котором говорят все. То бишь тот самый DSL. И это, в общем-то, тупик, на мой взгляд. Заведомо проигрышная идея.
Чтобы понять, что я имею в виду, нужно поразмышлять над "schema first vs code first" и над "configuration complexity clock", последней стадией усложнизма (где конфигурация становится ни чем иным, как кодом, написанным на другом языке).
Если начинать со "схемы" (и DSL), этот язык и становится тем, на чем пишутся ваши микросервисы. Сама идея "генерации кода" глубоко порочна, я считаю. Вместо этого следует иметь возможность экспорта обработчиков сообщений (как это было сделано еще черт-те знает когда, в Windows, а то и еще раньше).
Re[18]: Какой язык стоит выбрать для написания микросервисов
Здравствуйте, Артём, Вы писали:
S>>А потом ноду пропихивают в бакенд. Аё>Попробую догадаться, чем это плохо. Нет многопоточности? Но если функционал- склеить результат из параллельных запросов и вернуть, то нод вполне справится обним потоком. Он же асинхронный by design. Наспаунить пачку инстансов в облаках.
Ой, все такие всегда правильные... "Ой, оказалось что бакенд посложнеее... Ну не меняяять же языык.. Ноду жэ ужэ выбрали!" и в итоге тормоза, жор ресурсов, контейнеры для масштабирования и вот это вот всё. Вместо того чтобы сразу взять язык, предназначеный для программирования а не вот этого вот "склеить пару строк из полей ввода" в голове браузера.
Я сравниваю уровень студентов с уровнем специлистов в других странах. При чем здесь общее число разработчиков?
