+

net стек — в моєму розумінні, це як правило великий ентерпрайз зі всіма його плюсами і мінусами.
тут подивився список вакансія в розділі .net — там через одну також і мінімальні знання js потрібно. Думаю причина проста — вміти і фронт якщо треба правити. Досить часто бекендери того не люблять)

node.js став популярним в першу чергу коли великі апплікейний почали дробити на більш меньші сервіси. Плюс досить часто node.js апплікейшиний — це backend для frontend.

Наскільки я знаю, то сучасний .net стек це вже не чітко microsoft-based, всякі кубернетуси, докери там також активно використовуються.

Треба розуміти що сучастний node.js. апплікейший, це не тільки знання JS + express/nest.js. Тут як правило потрібно також знання linux на базовому рівні, докер, sql/nosql бази, cloud native підходи.

Стосовно перспектив для входу треба розуміти цілі — якщо просто потрібно запригнути і почати працювати, тут тупо рекомендація одна — на те що зараз є попит.

Якщо дивитись на горизонт планування в років 5 і що буде актуально тоді — майже впевненний що .net стек все ще буде досить актуальним. Зараз дуже багато всього на ньому роблять, і питання підтримки нікуди не зникне.

В свій час коли я пробував різні мови і технології .net шлях мені не зайшов причині того, що то був чіткий Microsoft напрямок (Visual Studio, MS SQL, etc).

Дуже не далекий комментар.
Багато хто з українського АйТі живе в своєму специфічному коконі, де розуміння того звідки на їхні рахунки кожного місяця падала певна сумма взагалі немає.

+

Интересно узнать — в текущей конфигурации dev-ops инженеры вообще не общаются с командами разработки? Все идет через тикеты и PM?

шо такое инфляция — автор коммента походу не знает)

Крутой опрос! Много чего себе записал в список на прочтение!

www.youtube.com/watch?v=dan7ly1ye1k рекоммендую посмотреть

А на чем основано такой утверждение? Я могу аргументированно утверждать что в Серве сотни людей которые пришли интернами/джунами без опыта и доросли до нормального уровня (и я не про лычки).

Вроде во всяких ПМБуках это называется пипл и риск менеджмент)

А вообще, если у гребца есть менеджер и он вообще не интересуется как у гребца дела — я бы тут задал вопрос о его компетентности и зачем он тогда вообще нужен)

Вроде все что тут описано — банальная сессия на куках)

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

Статья тупое ни о чем.

Вот это меня очень часто улыбает)

Просто в продуктовых работать будет интереснее.

Конечно все зависит от ситуации но очень часто даже может быть все наоборот.

Мне вот интересно какое количество продуктовых компаний которым автор помог с АйТи имеют хедофисы у нас тут и работают по КЗоТу.
Очень часто местные «предприниматели» рассказывают про то как нужно страну любить сами являются супер-спецами в оптимизации тех же самых налогов.

Хорсев крутой тип, но со своими приколами, очень давно за ними слежу и свой вклад в развитии продуктовой части украинского айти ребята точно сделали. Понятно что он будет топить за свою позицию и принципы.

По поводу его аргумента со знанием английского — он уверен что у него тоже все английский знают, при этом это сводится к умению прочитать текст))) Я наоборот очень часто наблюдал картину что людям с опытом работы в «локальных продуктах» по несколько лет где нету потребности хотя-бы минимально общаться на английском очень сложно сформулировать несколько предложений.

Хорошая статья!
Еще интересный вопрос в работе с Elastic — как организовывать репликацию данных с основной БД. Как у вас это было организовано? Вы писали свое решение или использовали какое-то готовое?

Первое что нужно понять что такое MVP.
Потому что иногда для того чтобы протестировать гипотезу вообще не нужно писать код.
Иногда для такого хватает это все собрать на основе существующих сервисов.

Дальше нужно понимать что будет выполнять данное MVP.
Если внутри какая-то хитрая сложная логика — написания кода вместе с юнит тестами только поможет это все написать более правильно.

Проблема в том что многие после того как инвестировали какое-то время и ресурсы в прототип потом на его основе пытаются наворачивать функционал без понимания как это правильно сделать — в итоге потом и получается то что получается.

Юнит, интегрешин или e2e?
Мое мнение — для какого-то небольшого прототипа (именно блек-бокс который имеет какой-то протокол взаимодействия и выполняет пару функций) золотая середина — интеграционные.
Если внутри хитрая логика — дополнительно покрываем часть unit.

Если есть UI — на первых парах хватит и мануального тестирования — если полетит — потом это можно автоматизировать.

Но технарь-технарь конечно же всегда скажет что надо чтобы было не меньше 80% покрытия — потому что так правильно))

Хорошая статья!
В последнее время как-то много толковых статей выходит.

Агов — автор походу не видел ДОУ до 2007 года)
Норм дизайн! Все ок

Это одному мне кажется что основная цель данной статьи — набить лидов на интервью в стартап?)

Кафедра АПЕПС на ТЕФе.
Не знаю как сейчас — но в мое время это была отличная альтернатива всяким ФИОТам)