• Разработка с Docker на Windows Subsystem for Linux (WSL)
    +1
    Закоммитить index.png и index.PNG.
    Или в конфигах писать пути без учёта регистра.
    Но на практике у меня с этим проблемы бывают раз в пятилетку. Хуже переводы строк виндовые: поменяешь entrypoint.sh, не проверишь переводы строк и всё ломается, причём ошибки довольно безумные порой.
    Но всё это тоже решаемо.
    На самом деле у меня с WSL большие надежды, работать через Hyper-V сильно медленно.
  • TDD, мокисты и реальные пацаны
    0
    Ну так кто спорит, что требования могут быть разными и к ним можно применять разный подход. Одно дело фреймворк писать, другое интернет-магазин.
    Ну вот когда надо будет делать CLI, тогда можно делать генерализацию и всё остальное. Я стараюсь максимально следовать принципам KISS и YAGNI и не усложнять пока это возможно.
    Грубо говоря, CQRS удобная штука для разруливания сложных кейсов, но пихать её вообще везде глупо.
  • TDD, мокисты и реальные пацаны
    0
    Думаю, мы с вами не понимаем друг-друга. Однако, вот тут мужичок написал неплохой текст про то, что я пытаюсь донести:
    https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf
  • TDD, мокисты и реальные пацаны
    0
    Т.е. у этого кода уже сейчас, в самой простой стадии, примерно нулевая устойчивость как к ошибочным сценариям, так и к сценариям самых базовых изменений и расширений.

    Как раз его очень просто расширять и изменять. И тестировать через API. В нём просто нет кода, который нужен только для тестов. Ну а какая должна быть устойчивость? ну вернёт он пустой объект если что-то не так, ну или валидация атрибутов сработает.

    1) Представим, что в вашем клиенте баг и у вас прилетает request==null, из которого возращается 500 ошибка на клиенте, причем в логах ничего нет.

    Я не понимаю, что это за логи, которые не видят ошибку 500.
    Валидация UserProfileRequest обычно делается за счёт атрибутов самого фреймворка. Но писать валидацию в методе контроллера — это тоже нормально.
    Приложение обычно перехватывает все эксепшены и пишет их в логи. Ну если у вас какое-то публичное API, то да, имеет смысл париться тестами валидацией и сложными кейсами API (хотя IRL если клиент шлёт в API всякую хрень, то сам дурак). Но всё равно не ясно зачем это выносить на более низкий уровень.
    Если нужно будет доставать связанные сущности в самом Select'е то нет смысла это куда-то выносить, ибо это будут сущности уровня API и их можно мэппить прямо в запросе. Когда и если будет навороченная логика, тогда её стоит и выносить.
    LastName, FirstName, FullName, Middle Initial надо будет добавить только в одном месте. Если у вас пойдут слои, то это надо будет добавлять в куче мест, ещё и мэппить. И всё только для того, чтобы сделать тестирование. Ну если бюджеты бесконечные, то можно. А я за разумную достаточность.
  • TDD, мокисты и реальные пацаны
    0
    Давайте покажу, что я имею в виду, на примере:
    Например, есть у меня экшен контроллера, в котором я вытаскиваю из базы объекты ровно такие, какие нужны мне для view. Грубо говоря:

    public async Task<ActionResult<UserProfileResponse> GetUserProfile(UserProfileRequest request)
    {
        return await _dbContext.Users
           .Where(x => x.Id == request.Id)
           .Select(x => new UserProfileResponse()
            {
                Id = x.Id,
                Name = x.Name
            }).ToListAsync();
    }


    Дальше генерим webClinet через nswag и дёргаем API в функциональных тестах. Просто, легко поддерживать и мало кода, а ещё можно тюнить под конкретный запрос. Вы можете потом дать джуну задачу добавить поле в UserProfileRequest и он это сможет сделать. Вы можете взять программиста, который всё перепишет на Хаскеле, но ваш тест будет работать, ибо это API вызовы. Такие высокоуровневые тесты живут, пока не поменялись требования, они совершенно не тормозять рефакторинг системы.

    Для юнит-теста надо надо мокать базу, для этого надо пилить слои. Надо делать, какой-нибдуь IRepository.GetUserProfile(), делать слой данных, делать мэппинг данных из UserProfile в UserProfileResponse. (Вы же не будете класть объекты уровня Api в DAL).
    Кстати, вот в случае SaveUserProfile уже мэппинг и слой абстракции не повредит, потому что там будет 100500 всяких валидаций, запросов к сторонним сервисам и прочее, так что там есть смысл выносить код save из класса контроллера. Просто чтобы спрятать сложность куда-то в отдельное место.
  • DevOps — всё
    +4
    Когда не принимают PR это всегда обидно.
    Особенно, когда у твоего PR есть «пальцы вверх».
  • TDD, мокисты и реальные пацаны
    0
    Проектов, в которых надо выкладывать фиксы каждый час, а значит, и апдейты — очень мало, и тем более неясно, как это делать без хорошего покрытия.

    Сами же пишете про тестирование библиотек на юзерах.
    Я же пишу про a/b-тестирование.
    Есть много приложений (например е-магазины), где на самом деле бизнесу не нужен ваш код, бизнесу нужна конверсия. Если конверсия растёт, то код приложения работает, если конверсия падает, то стало хуже.
    Говорить о том, что функциональные тесты не проверяют негативные сценарии крайне не правильно. Очень даже хорошо ими ломать всё приложение и смотреть, как оно поведёт себя.

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

    1. Если у вас нет unit-тестирования, то вы можете выкинуть кучу кода. Все эти интерфейсы и фабрики вам не нужны, если у вас всегда одна реализация. Скорее всего, у вас станет и меньше слоёв — меньше кода, меньше багов и меньше работы по его поддержке.
    2. Юнит тесты очень сильно завязаны на реализации. Если вы захотите сделать большой рефакторинг, то тесты просто перестанут комплироваться. Чем более высокоуровневые ваши тесты, тем легче вам переписать всё целиком.
    3. Замокать окружение для высокоуровневых тестов очень сложно, намного проще запустить ваше приложение в каком-то контейнере и гонять его целиком с куском реальных данных, чем поддерживать моки.
  • DevOps — всё
    +3
    можно подумать кому-то этот PR/MR нужен. Там с той стороны сидят ребята на поддуве у facebook, microsoft или какой-другой компании и у них свой план. А на MR скорее ответят, что его как-то не так оформили или ещё как-то докопаются до мелочей.
  • TDD, мокисты и реальные пацаны
    +7
    Ложные аналогии as is.
    У каждого инструменты свои плюсы и минусы. Если вы не видите минусов юнитестов на равне с их плюсами, то это очень плохо.
    Да, unit-тесты на моках хорошо дают покрытие функций. Если у вас библиотека, то без unit-тестов никуда.
    Если у вас большой проект, который надо постоянно менять, то поддержка Unit-тестов будет очень дорогим камнем на шее. Вы просто не вытянете саппортить тестые, потому тут приходит на помощь поведенческие тесты, которые, тоже могут дать неплохое покрытие. Да, они медленные, но зато они требуют минимум поддержки. Для частых релизов и мутных приложений такие тесты могут быть идеальными.
    И если у вас проект, что надо выкладывать фиксы каждый час, то можно вообще использовать только A|B-тесты.
    Разные ситуации бывают, надо уметь выбирать самое оптмимальное решение с точки зрения бизнеса.
  • Изоляция, тревожность и депрессия на удалённой работе
    +14
    Смысл удалённой работы в том, чтобы сделать себе максимально комфортную среду для работы.
    Если ты любишь и умеешь путешествовать, то путешествуй.
    Заведи себе хобби и будешь общаться с хоббистами по всему миру.
    Понятно, что если только сидеть в номере где-нибудь на самуи и кодить, то будет депрессия. Выходить из дома надо. Круг общения — это не обязательно коллеги, даже наоборот, лучше если это были не коллеги.
  • Власти Австралии хотят ввести обязательное сканирование лица для доступа к порносайтам
    +2
    У австралийцев какие-то проблемы с порном. Даже из Ведьмака 3 повырезали все сцены.
  • DJI Mavic Mini: самый легкий складной квадрокоптер
    +9
    Глядя на характеристики трудно понять, так можно им дома чиновников снимать или нет?
  • «Разработчик хочет купить самолет через три года. Моя задача ему помочь» — Денис Пушкин о мотивации в Skyeng
    +9
    Не факт, что SkyEng вообще нанимает программистов по ТК. Скорее заключает договора с ними, как с ИПшками. Вангую, что там говорят что-то вроде: вам как ИП, или -40% зарплаты?
    image
  • «Разработчик хочет купить самолет через три года. Моя задача ему помочь» — Денис Пушкин о мотивации в Skyeng
    +7
    Я так много работаю, просто потому что провожу время с кайфом. Другие развлечения мне менее интересны, чем поработать.


    Рецепт выгорания, как есть.
    На самом деле, быть трудоголиком уже года 2 как не модно.
    И это крайне правильно, мозг надо переключать. Я сам программирую с детства и мне это очень нравится, но стараюсь заниматься другими делами тоже. И пробовать себя в разных сферах.
  • Ищем и анализируем ошибки в коде Orchard CMS
    0
    open-source аналог Wordpress CMS для .NET

    Я, кстати, однажды предъявлял Себастияну Россу, что он хотел сделать Wordpress, а сделал какого-то монстра убогого. Он мне тогда сказал, что никогда не имел в виду Wordpress, а Drupal или Jumla.

    популяризации Windows как плаформы «дешевого» веб хостинга

    Да. Azure, если быть точнее.

    им это в какой-то степени удалось,

    Абсолютно нет. Настолько нет, что Nuget плюнули и выкинули Orchard и написали всё с нуля. До версии 1.6, наверное, Орчард был очень тормозной и жрал кучу ресурсов.

    совершенно другой вопрос и думаю он не к разработчикам из команды Orchard.

    Цель была правильная. Только разрабы вместо решения этой задачи начали развлекаться с мега-супер-динамической системой рендеринга, которая IRL никому была не нужна. Конкретно архитектурные решения там принимал и принимает Себастиан, когда ему коммунити говорили, что «ребята, пилите нужные фичи», они и Бертраном Ле Роем пилили графический редактор для редактирования картинок.

    идеи динамической компиляции и подгрузки внешних модулей в рантайме

    О да, это они молодцы. Ибо это была жесть жестокая. Пример мега-фичи которая нафиг никому была не нужна.

    в угоду цели написать свой аналог Wordpress.

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

    Просто горе-ахитекторы Orchard'a не понимают одной простой вещи: сайт делает студия, делает все эти HTML, настраивает модули, компилит и выкладывает. Дальше с сайтом работают конент-редакторы, и им нужны удобные инструменты для управления контентом.
    Если нужно положить какой-то виджет, то этот виджет будет дизайнить/выкладывать студия, а не контент-редактор. Динамическая настройка Layout'ов не нужна, а именно из-за этого в Orchard такая зашкаливающая сложность.
    Ребята из Orchard никогда не делали сайтов и не работали в студиях. Например, они не понимают, что экспорт/импорт базы для таких систем — это очень важно. В итоге, он в орчарде очень убогий и глючный, возможно, они его всё-таки починили в 1.10, не проверял на реальной базе.

    Меня эта вся история тронула довольно близко, именно потому что мы в своей студии сделали ставку на Orchard и очень сильно прогорели. Про Orchard вообще можно басни слагать, как делать не надо.
  • Ищем и анализируем ошибки в коде Orchard CMS
    +2
    Ну Orchard всегда был хорошим бенчмарком для Rider и Resharper, вроде ребята из JetBrains его использовали для тестов.
    Но из реальных проектов есть:
    github.com/umbraco/Umbraco-CMS — большая, функциональная, проверенная временем. Sitecore для бедных одним словом.

    github.com/nopSolutions/nopCommerce — довольно мощный интернет-магазин.

    Можно ещё что-нибудь отсюда посмотреть:
    github.com/thangchung/awesome-dotnet-core#cms
  • Ищем и анализируем ошибки в коде Orchard CMS
    0
    OrhcardCMS надо было прикопать лет эдак 5-7 назад. Это просто пример того, как программисты на деньги MS и других инвесторов пишут абсолютно over engineering поделие не для реального мира. Причём пишут его долго и мучительно.
    Orchard 1.x оказался очень сложным, ребята сделали довольный безумный механизм рендеринга HTML из Shap'ов и всего такого. Чтобы разработчик в web-студии мог начать на нём сайты делать надо было много времени потратить. Вместо того, чтобы осознать, что людям не нужен сложный динамический рендеринг HTML, а нужен Django Admin, который можно подключить к ASP.NET MVC/API сайту. В итоге, Orchard 1.x — это очень сложный движок для рендеринга HTML с убогой админкой.
    Но мужички не учатся на отзывах пользователей и потому запилили Orchard Core частично обратно совместимым с Orchard 1.x. Те не отказались от своих сложных концепций.
    Админка, впрочем, стала немного лучше, но всё ещё ужасна, хотя они притащили туда Vue.
    Лично я ожидал, что Orchard Core зерелизят несколько лет назад вместе с .net core 2, но нет, эти перфекционисты всё ещё его пилят, и вангую, что раньше 2020ого стабильного продакшен-релиза нам ждать не стоит.

    В общем, не связывайтесь с Orchard'ом, ребята, я на него кучу денег и времени убил. Это очень дорогое в сопровождении и обучении поделие.
  • Холивар. История рунета. Часть 7. YouTube: комики, зашквары и Кремниевая долина
    0
    А что же делать всем нам?

    Донатить Медиазоне.
  • Обсуждаем будущее PHP
    0
    По крайней мере для node.js есть sequelize и mongoose. А ещё много других библиотек.
  • Обсуждаем будущее PHP
    +6
    Я PHP хоронить не предлагаю, там фреймворки мощные.
    Однако:
    — node.js с Typescript вполне годный способ писать бэкенды. Отличная модель асинхронности.
    — asp.net core с версии 2 очень годная вещь: божественный C#, простой движок похожий на node.js express, кросплатформенность, и крутая IDE Rider.

    Вместо Java сейчас есть очень годный Kotlin. Для него запилили фрэймворк ktor, который очень лёгкий без ужасов spring'а.
  • “Kak tebe takoe, Elon Musk?”. Основатель Tesla примет участие в краснодарском бизнес-форуме по видеосвязи
    –8
    Делать нечего маску быть свадебным генералом.
  • Burn Out IT-специалистов: 4 истории от управленца, разработчика, продакта и админа. И рецепт от Southbridge
    +3
    Короче рецепт от выгорания прост: женись, бери кредит, роди ребёнка, а лучше двух. Тогда дофаминовая воронка вам не грозит, будете получать удовольствие от того, чтобы поспать.
  • Холивар. История рунета. Часть 6. Блокировки: Лурк, Лента, 282-я и китайский путь
    0
    Потому что первым подозреваемы были бы вы. У них план горит, а настоящих преступников ловить надо. Шампанское применят и сознаетесь лет на 10. Полицию в России надо обходить по большому радиусу, если не хотите проблем себе и близким.
  • Холивар. История рунета. Часть 6. Блокировки: Лурк, Лента, 282-я и китайский путь
    +2
    Но ты давай вон спроси у своих детей,
    Где их папа нужней: в сводках новостей,
    Чтоб ноги об него вытирать по телику?
    Или в коридоре, чтоб сиденье поднять у велика?
  • Холивар. История рунета. Часть 6. Блокировки: Лурк, Лента, 282-я и китайский путь
    +9
    Что-то мне кажется, выпилят эту статью с хабара, слишком уж 6ая часть сильная получилась.
  • Дозиметр для Серёжи. Часть II. «столетние трубки» vs мирный атом
    +1
    Да ладно. При моей жизни была Фукусима. Власти молчали, хорошо что ветер подул не на Дальний Восток.
    Vl.ru тогда положили дозиметр и положили web-камеру.
    А ещё во Владивосток пришёл корабль ЕРуслан с грузом машин из Фукусимы. Сам корабль потом разворовали и теперь запчасти от этих машин где-то в России.
    В этом вашем Питере/Москве тоже бывают инциденты.
  • Что лучше выбрать в 2020 году — React или Vue?
    0
    Так потому React и рулит на рынке. Но мутный он какой-то. Я лично жду когда Flutter допилят.
  • Что лучше выбрать в 2020 году — React или Vue?
    +1
    По мне, так выбирать не особенно-то и нужно.
    React — очень популярен, разработчиков куча. Да, он не очень удобный (по мне так вообще не удобный), зато можно писать достойные мобильные приложения на ReactNative.
    Angular — тяжёлая штука, хороша для больших проектов и кровавого интерпрайза.
    Vue — то, каким должен был бы стать AngularJS. Леко выучить, легко использовать в популярных сценариях. Минусы в том, что Vue для мобилок ещё не допилили и проще использовать ReactNative. Не так много разработчиков под Vue.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    –1
    Вроде всё норм. Это же не боку-но-пико.
    Потом, как будто феминисткой быть — это плохо.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    –5
    Видимо, вот ответ Яндыкса:
    habr.com/ru/post/470337/#comment_20721735
    Явно завели аккаунт только ради этого коммента.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +1
    Логично. Это ж аутсорсинг. Там в разных командах разные процессы и разные бюджеты. Где бюджет пожирнее, могут и не так жадничать. Но в целом на всех галерах подход такой, что стараются задать как можно больше теоретических вопросов, чтобы получить больше неправильных ответов и сбить зарплату.
    Мол, «Вася, ты не знаешь как работает <function-name>, потому мы можем предложить вам только позицию лохомидла с лохозарплатой, однако через год ты можешь повысить рейт если повысишь квалификацию». Без разговоров берут только когда им нужна какая-то редкая компетенция.

    На самом деле, это, конечно, не сильно плохо — это рыночек. Компания хочет нанять подешевле, продать труд программиста подороже. По крайней мере с галерными ребятами в целом общаться намного приятнее, чем с Яндыксойдами. Плохо, когда компании сговариваются чтобы сбить зарплаты: habr.com/ru/post/285520
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +1
    В Luxsoft нет пафоса. Ну те он есть, когда пытаются залошить, чтобы меньше заплатить. Но в целом, они понимают, что они галера и интервьюер сильно своё ЧСВ на стол не выкладывает.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    0
    Ну так я ж о том и пишу. Нужны формальные доказательства:
    — умеешь крутить деревья — чек
    — сортировку на доске пишешь — чек
    2 бала из 2х берём. Если что отвественностьи на интервьюере никакой: он проверил, чекбоксы правильно поставил.

    А мутное «чистый код» или ответы на вопросы «а почему вы сделали так» — это не формально, большим компаниям это не нужно.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +1
    Не только Google, Facebook и Яндыкс. Это сейчас глобальный тренд. Крупные компании перешли от логических задач с люками и гномами на олимпиадные задачки.
    Ну а мелкие компании копируют крупные, так что сейчас можно легко прийти в ООО «Рога и Копыта Солюшенз», которые начнут задавать задачи с leetcode.
    Альтернатива этому ставить перед кандидатом реальные задачи и смотреть, как он их будет решать, хотя бы на уровне идеи. Но такие задачи очень сложно задавать в больших конторах, где нужны формальные признаки чтобы взять человека, а не «Мне нравится его образ мысли».
    Аутсорсинги, например, которые не могут нос воротить от тех, кто не знает сортировок, просто дают тесты на знание конкретной технологии: на сколько вопросов ответил, столько денег тебе и дадут.
  • Как я проработала 3 месяца в Я.Маркете и уволилась
    +58
    То что в ядыксе работают пафосные и токсичные хрены это не секрет.
    Ходил на собеседование в Лондонский Facebook: Оплата отеля, ланчи и вообще очень приятное впечатление.
    Собеседование в яндыексе: 4 часа решаешь логические задачки, интервьюер опазыдывает, даже не предложили чаю.

    Насмехаться над джунами — это днище. Команда может быть максимально эффективной, только если в команде есть командный дух, а не банка с пауками. Это настолько простая истина, что странно, что люди прошедшие собеседование в яндыкс этого не понимают.
  • Я мотоцикл покупал, чтобы ездить, а не чтобы падать
    0
    Межрядье. Когда еду на авто, то таких мотоциклистов ненавижу (исключение, когда стоишь в пробке). Когда еду на мото, то понимаю, что иначе не было бы смысла садиться на него. В физике — это Дуализм, а в мото?

    Ездить в междурядье в России — это очень плохо. Мотоциклистов там никто не ожидает. Мотоциклы в России вообще не особенно ожидают на улицах. Потому бросил это дело и езжу только в Таиланде, где есть и инфраструктура и водители машин тебя ожидают.
  • Почему будущее доставки всё-таки может быть за дирижаблями
    0
    > реальную экологичность
    Только если по ветру летать. Против ветра толкать такую большую площадь надо кучу энергии.
  • Почему нужно бросать всё и изучать Swift и Kotlin прямо сейчас
    +3
    Я не про вас конкретно. Я вообще про индустрию курсов. Ну что до вас, хорошее дело. Всем джунам советую поработать в большой продкутовой компании, чтобы получить «базис», а потом уже идти хоть в web-студию, хоть на галеру.
  • Почему нужно бросать всё и изучать Swift и Kotlin прямо сейчас
    +1
    сдача серьезных сертификатов

    Заучивание дампов что ли?

    Курс определяет контент и преподаватель, а не то с каким пафосом они тянут деньги с корпоративных клиентов.
    Ну и да сейчас курсы — это очень выгодно. Для примера ElasticSearch, по которому официальная дока очень «рыхлая», зато есть курсы за несколько тысяч евро.
  • Дзен-практики в open space
    0
    Я вот не понимаю почем не понаставить переборок, чтобы каждая команда сидела в своей комнате? Ну понятно, что каждой компании нужны своя конфигурация, а арендодателю проще сдавать большой ангар.
    Но почему не понаставить мобильных стен?