• Коллеги, вы меня огорчаете
    +3

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

  • История двух стандартных библиотек Си
    0
    Хорошо бы выкинуть их к чертовой бабушке и везде пользоваться UTF-8.

    Второй пункт прямо противоречит первому

  • Коллеги, вы меня огорчаете
    0

    Метод пузырьком нахрен не нужен, потому что Шелл лучше всегда

  • .NET Core vs Node.js. Аргументы и факты
    0

    Blazor уже в релизе и .NET дает писать фронт на C# и де-юре и де-факто

  • .NET Core vs Node.js
    +1

    Net Core не медленный, просто надо было вместо EF Core брать нормальный linq2db

  • Структуры данных в Java. Полезные методы вспомогательных классов
    –11

    Шел 2019 год.
    В яве все еще принято явно указывать типы переменных.
    Методы расширения все еще ересь.
    Котлин? Не слышали.
    Так выпьем же за энтерпрайз ныне, присно и во веки веков!

  • Монада «Maybe» через async/await в C# (без Task-oв!)
    +1

    Нет, не об этом.
    При использовании исключений в синхронном коде будут затраты на выброс, раскрутку стека и отлов.
    При использовании исключений в тасках можно ничего не бросать, а просто вернуть и потом проверять.
    Но использование исключений в async-методах дает выброс-отлов на каждом (!) вызове в стеке.
    Это гарантированный гроб производительности без вариантов.

  • Монада «Maybe» через async/await в C# (без Task-oв!)
    +1

    Не единственная. Там производительность идет далеко-далеко в лес.

  • Разбираемся с интерфейсами в Go
    +1

    Не соблюдаются и не похоже.
    Никакой отдельной реализации контракта для типа нет.

  • Разбираемся с интерфейсами в Go
    0

    Нет. Классы типов — это совсем другая концепция.


    1. Контракт (класс типов) — отдельно
    2. Тип — отдельно
    3. Реализация контракта (экземпляр класса типов) для типа — отдельно
  • F# меня испортил, или почему я больше не хочу писать на C#
    0
    Про питон он отзывался в выражениях, которые на разговорный не-айтишный русский переводятся исключительно матюгами.
  • Бэкенд для фронтенда, или Как в Яндекс.Маркете создают API без костылей
    0
    Как все хорошо и красиво.
    Остается только маленький нюанс.
    Почему-то яндекс маркет при всем при этом успешно теряет настройки фильтрации после показа всех фильтров и никак не контролирует статус отложенности для текущего товара, хотя после перехода на полный список видно, что все вроде помнит.
    Раньше такой фигни не было.
  • Микросервисы делают мир проще (а вот и нет)
    0
    Не хватит ему абстракции.

    Еще как хватит. У монолита снаружи видно то, что у микросервисов есть в API Gateway.
    Все остальные API внутрипроцессные.
    С базой все точно также — бывают модули, требующие себе базу и таблицы, но в отличие от микросервисов, это тоже экзотика.


    Почему вы предлагаете одну и ту же бизнес-функциональность тестировать по разному?

    Потому что микросервис и модуль в составе монолита — это разные вещи.
    В случае монолита у нас будут


    1. Модульные тесты на классы
    2. Интеграционные тесты на модуль
    3. End2End тесты на приложение

    Для микросервиса c той же функциональностью:


    1. Модульные тесты на классы.
    2. Интеграционные тесты на модуль.
    3. Интеграционные тесты на микросервис.
    4. End2End тесты на приложение.
  • Микросервисы делают мир проще (а вот и нет)
    0
    Вот как модулю авторизации не работать с базой юзеров

    Очень просто: модулю авторизации хватит и абстракции над хранилищем.


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

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


    Не делаете реальный http-запрос при тестировании модуля, а стучитесь к роутингу как-то напрямую — не делайте его и при тестировании микросервиса

    А вот здесь все с точностью до наоборот. Микросервис — это модуль с навернутым на него веб-API и хранилищем данных. Так что если тестировать сервис, то в отличие от тестов модуля, придется проверять и это.

  • Микросервисы делают мир проще (а вот и нет)
    0

    Модулю не нужен EndPoint для браузера.
    Модулю не нужна база.
    Модулю ничего не нужно, кроме двух списков контрактов:


    1. То, что модуль обязуется реализовать.
    2. Необходимые модулю для обеспечения пункта 1

    Есть модули, которые специализированы на доступе к базе или реализации внешних точек доступа. Но для модулей, в отличие от микросервисов, это экзотика.
    Например, модуль авторизации 100% будет отвязан как от конкретной точки доступа, так и от конкретного хранилища данных.

  • Микросервисы делают мир проще (а вот и нет)
    0

    Есть один процесс и это монолит.
    А вот бинарных фалов с модулями может быть сколько угодно.
    Еще в MS DOS были оверлеи.
    В Windows появились dll.
    В Linux также есть свои подгружаемые в один процесс бинарники.
    Единственный бинарник на процесс в наше время экзотика.

  • Микросервисы делают мир проще (а вот и нет)
    0

    Реализация конкретного API микросервиса может делать вызовы к другим микросервисам и для полноценного тестирования извольте поднимать весь оркестр.


    А у модуля никакого WebAPI и тем более базы может вообще не быть. Достаточно обычных ООП-интерфейсов. У монолита WebAPI будут трогать только E2E-тесты.

  • Микросервисы делают мир проще (а вот и нет)
    0

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

  • Микросервисы делают мир проще (а вот и нет)
    0
    Протестируем как модуль интегрируется с базой в лучшем случае, но не проверим как он работает с базой.

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

  • Микросервисы делают мир проще (а вот и нет)
    0
    это уже будет не тестирование монолита, а только какой-то его части.

    Двумя сообщениями выше:


    Даже сервис тестировать сложнее, чем модуль внутри монолита, решающий те же задачи.

    Не надо сравнивать тестирование монолита целиком и одного микросервиса.
    Один микросервис есть смысл сравнивать с одним из модулей монолита.

  • Микросервисы делают мир проще (а вот и нет)
    0
    Ничего, что речь шла о тестирование модуля монолита, умеющего то же, что и один микросервис?
    Если каждый модуль нуждается в той же базе, что и монолит в целом, проблема не монолитности, а в качестве проектирования.
  • Микросервисы делают мир проще (а вот и нет)
    0
    Для «поделить работу» микросервисы не нужны. Совсем.
  • Микросервисы делают мир проще (а вот и нет)
    +2
    Пример: для теста нужна БД

    Для теста модуля монолита БД может быть не нужна совсем. Или нужна, но те же 10 табличек. Сервису же для тестов в любом случае надо базу и сетевого клиента.
    Если для тестов модуля монолита нужны все 500 таблиц, то он плохо спроектирован. Такой же по качеству микросервис также захочет 500 таблиц из базы, которую будет делить еще с 50 микросервисами.

  • Микросервисы делают мир проще (а вот и нет)
    0
    В частичный отказ монолит «умеет» и самостоятельно.
    Селективный деплой для монолита сложнее, но также возможен при аналогичном подходе к проблемам совместимости.
  • Микросервисы делают мир проще (а вот и нет)
    0
    Даже сервис тестировать сложнее, чем модуль внутри монолита, решающий те же задачи.
  • Микросервисы делают мир проще (а вот и нет)
    +1
    Инфраструктура для набора микросервисов, решающих те же задачи, что и монолит — сложнее по построению.
    Переход на микросервисы сам по себе ничего не упрощает, но превращает часть внутрипроцессных вызовов в медленные, ненадежные, плохо контролируемые на соответствие соглашениям сетевые.
    И все это ради единственного преимущества: селективного горизонтального масштабирования.
  • Микросервисы делают мир проще (а вот и нет)
    0
    Ага, особенно хорошо тестировать End2End
  • Так что же не так с поиском работы/работников в ИТ?
    0
    Это вашего возможного кандидата волнует в последнюю очередь.
  • Так что же не так с поиском работы/работников в ИТ?
    +1
    Заставить работать или не работать деньги не могут, но на выбор конкретного места работы влияют очень сильно.
  • Так что же не так с поиском работы/работников в ИТ?
    +6
    Воронеж? Дефолт-Сити рядом, конторы, оплачивающие релокацию, далеко не экзотика.
    «Сносный» оклад хорош для мидла, сеньор уже понимает, чего стоит, нащупывает потолок на малой родине, после чего удаленка или переезд.
  • Microsoft прекращает поддержку классической десктопной версии Skype c 1 ноября
    +4
    8 версия на старых машинах тупо лопается по памяти.
  • Microsoft прекращает поддержку классической десктопной версии Skype c 1 ноября
    +3
    Только лучше оно от этого не стало.
  • Моё разочарование в софте
    0

    Наверное, именно поэтому во второй версии го есть генерики и обработка ошибок.

  • Раздача халявы: нетормозящие треды в Java. Project Loom
    +1
    Разница простая — принудительного переключения нет, но само переключение очень быстрое.
    Можно писать неблокирующий код, читающий из сокета по байтику, но такой же простой, как и блокирующий.
  • Распараллеливание задач с зависимостями —  пример на .NET
    0
    Спасибо, что взялись за перевод хорошей книги.
    В выложенном отрывке есть нюанс: обычно вместо «меченое объединение» используется термин «размеченное объединение».
    И по смыслу второй вариант лучше соответствует: каждая альтернатива в объединении имеет метку, доступную во время исполнения.
  • KPI — три буквы преткновения
    +1

    А правильной для программистов не бывает, причем по построению.
    У программистов сама суть профессии в оптимизации и фальсификации (не в смысле подлога) числовых показателей.
    И само собой, показатель, от которого напрямую зависит зарплата, будет оптимизирован, а то и сфальсифицирован.


    1. В лучшем случае программист будет оптимизировать KPI, не снижая качества своей работы. Ничего хорошего в этом нет, но и плохого немного.
    2. В обычном случае в первую очередь будет оптимизирован KPI, во вторую сделана работа. Уже имеем прямой вред.
    3. В плохом случае будет делаться все для KPI, включая то, что явно вредит собственно работе, и ничего для остального, включая необходимое.

    Значение KPI должно содержать в себе экспертную оценку.

    Вы всерьез верите в то, что выводы экcперта лишь сырье для вашей формулы, а не наоборот?

  • Как я изучаю фреймворк Spring — часть 2 (помощь начинающим — дело рук самих начинающих)
    0
    Быстродействие как главный критерий выбора xml вместо кода — тут уже не лампами, а дымком от костра попахивает.
  • Как я изучаю фреймворк Spring — часть 2 (помощь начинающим — дело рук самих начинающих)
    +1
    Регистрация классов через XML в 2018 году смотрится очень тепло и лампово.
  • «Я бесполезный дурак и хочу уволиться» — 10 вопросов программисту, пилотный выпуск
    +5

    Скорее всего да. Рязань у коллег-дотнетчиков рвет и мечет не только в синтетических тестах.

  • «Я бесполезный дурак и хочу уволиться» — 10 вопросов программисту, пилотный выпуск
    +2
    Они скажут мне, что все то, что работало до этого работает и теперь.

    Они могут только сказать о том, что сломалось. По построению.