«Через год-два .NET Core потеснит Java на рынке enterprise решений», — Интервью с Jon Skeet, Google

    Наверняка, вы знаете, кто такой Джон Скит: №1 на Stack Overflow, автор C# in Depth, одной из лучших книг по .NET, разработчик в Google и 14-кратный MVP. Разработчиков такого масштаба не так много, хватит двух порядков, чтобы их всех перечислить. 19-20 мая Джон приедет в Петербург и выступит на DotNext 2017 Piter.

    Мне удалось пообщаться с Джоном и взять у него большое интервью по поводу судьбы .NET, .NET Core, нововведений в C# 7 и общем уровне развития среднего разработчика в 2017 году.



    Если говорить конкретно, то обсудили следующие вопросы:

    • Общее направление развития .NET и ошибки Microsoft;
    • Чего ждать от .NET Core в ближайшем будущем;
    • Стоит ли мигрировать на .NET Core, если у вас легаси на .NET Framework;
    • Проблемы и победы .NET на поприще кроссплатформенности;
    • Java vs .NET на рынке enterprise решений;
    • Чем хороши tuples и pattern matching в С# 7, а что стоило сделать иначе;
    • Небольшие, но приятные фичи C# 7;
    • Деградация сообщества разработчиков (и есть ли она);
    • Правильный подход к диагностике багов и постановке правильных вопросов на SO;
    • Гайд по изучению новых языков и платформ;
    • Проблемы с базовыми типами: числа, текст, дата и время;

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

    О развитии .NET как платформы


    — Приветствую, Джон, начнём с простых вопросов. В последнее время .NET Core и ASP.NET Core развиваются очень быстро и постоянно меняются. Вам, как разработчику, кажется, что платформа взяла верный курс?

    — Я думаю, вопрос затрагивает два разных аспекта. Первый — это направление развития платформы, а второе — процесс поиска этого направления: Microsoft стали гораздо более открытыми во всём, что связано с .NET. сейчас почти все стало open source и это здорово. С другой стороны, это влечёт за собой изменения в ряде вещей: например, в процессе принятия решений. Мы будем наблюдать промежуточные шаги, вроде project.json-проектов и KVM. Во времена «старого» Майкрософт с его традиционным корпоративным путем разработки ПО подобного бы точно не произошло, и, возможно, мы сразу увидели бы инструментарий .NET в его текущем виде. Да, в сообществе была полная неразбериха, и лично мне было многое непонятно, но со временем ситуация прояснялась. На этой неделе я задал вопрос на Stack Overflow о том, что же представляет собой .NET Standard Library, и ситуация становится все лучше.

    Однако, по-моему, мы как сообщество должны понимать, что преимущество открытости платформы в виде возможности планировать, видеть и влиять на происходящее сопровождается одним недостатком: вы должны либо сознательно игнорировать ещё не финализированные изменения, либо погружаться в них, осознавая вероятность того, что вы просто потеряете время, если эти изменения откатят. Судя по всему, большинству это подходит, и открытость идёт на пользу, но для .NET-сообщества это своего рода культурный шок.

    С учетом всего этого нельзя не отметить несколько, как бы сказать… коммуникативных осечек, которые можно легко понять: несложно допустить ошибку при создании принципиально новой версии чего-либо. Конечно, ещё были ошибки с нумерацией версий, с выбором дат релизов, с решениями о готовности. В общем, всё шло не так гладко, как хотелось бы, но это не страшно: в конце концов, никто не совершенен, и мы как сообщество должны это принять. Чем больше видишь, тем больше несовершенства замечаешь. Это что касается процесса развития платформы.

    Если же говорить о направлении движения .NET, то здесь я крайне, крайне оптимистичен. Приятно видеть и активное развитие .NET как платформы, и её расширение на мобильные платформы, и то, как Xamarin ложится на всю эту историю. Все это сложно, но вдохновляет, и также наблюдается большой прогресс в языках, в инструментах. На мой взгляд, ситуация в целом прекрасна. Для меня это всё ещё и происходит в то время, когда я работаю над Google Cloud Platform в Google, стараясь сделать GCP отличным окружением для C#-разработчиков, и, конечно, .NET Core — важная часть этого.

    Недавно на конференции Google Cloud Next 2017 мы с моим менеджером обсуждали возможность работы ASP.NET Core-приложений на GCP как в App Engine Flexible Environment, так и в контейнерах. И это одна из тех вещей, которые буквально несколько лет назад считались бы нелепыми. Требовалось провести работу с нашей стороны (в Google у нас есть расширение для Visual Studio, позволяющее деплоить в обе среды напрямую из VS), но также в этом не было бы смысла и без того, что Microsoft сделали с .NET Core. Честно говоря, мне кажется, что складывается выигрышная ситуация для всех.

    — Я правильно понимаю, что сейчас вы занимаетесь Google Cloud Platform, которая является прямым конкурентов для MS Azure?

    — Всё так, GCP конкурирует с MS Azure и Amazon AWS. Вообще, напрямую в разработку «кишков» платформы я не вовлечён. Все те крутые штуки, которые создают мои коллеги — вроде Cloud Spanner, BigQuery, Datastore или различных API машинного обучения — это великолепно, но не приносит пользы С#-разработчику, если он не может это использовать. Так что я создаю мост: у нас есть автогенерируемые библиотеки классов и некоторые новые виды кодогенераторов для упрощения всего процесса. И я добавляю туда немного рукописного кода в качестве клея или обёртки, чтобы сделать всё как можно бесшовнее и элегантнее.

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

    — То есть ваша работа, фактически, сделать так, чтобы автогенерируемый код мог пройти тест Тьюринга? :)

    — Хаха, это было бы замечательно! Я не думаю что мы близки к этому, но он проходит другой тест: когда используешь кодогенератор, то либо чувствуешь себя подчинённым его капризам, либо чувствуешь, что он работает на тебя. Я твёрдо уверен, что в нашем случае разработчик контролирует процесс.

    — Возвращаясь к платформе .NET: какие наиболее масштабные изменения следует ждать .NET-разработчикам в ближайшем будущем? На годы вперёд загадывать сложно, но возможно, поделитесь ожиданиями на ближайшие месяцы?

    — Всё зависит от того, где вы находитесь. Если ваш проект застрял в эпохе project.json или «я плевал на всё, я до сих пор на VS2013», то есть что наверстывать до последних релизов. Вышла VS2017, вышел .NET Core SDK, всё зарелизили, это больше не beta — и я призываю всех разобраться в том, что это значит. Да, на это нужно время, а документация всё ещё активно улучшается. Но это речь о пути, который надо проделать, чтобы нагнать текущее положение дел.

    А если говорить о будущем, следующая глобальная вещь, которая нас ожидает — это .NET Standard 2.0. У нас уже были .NET Standard 1.0, 1.2, 1.3, и т.д. — это не первая попытка облегчения кроссплатформенной разработки относительно portable class libraries. Но .NET Standard 2.0 — это дивный новый мир, покрывающий гораздо больше платформ, чем мы привыкли по десктопному .NET. Будут невероятно умные инструменты, позволяющие использовать библиотеки классов, написанные только под .NET 4.5: их авторы может быть даже их уже не поддерживают, но это не помешает запустить их в .NET Standard 2.0. Кроме того, я верю, что инструментарий становится все более низкоуровневым. Главное убедитесь, что не используете WPF и WinForms, и всё будет хорошо, такую библиотеку можно использовать в контексте .NET Standard 2.0.

    Нам обещают именно такой путь развития, и текущий .NET Core SDK не просто хорош, а по-настоящему хорош — огромный шаг вперед по сравнению с тем, что было раньше. И я думаю, Microsoft на этом не остановится. Поэтому, если вы не пишете пользовательские приложения (где, очевидно, UI будет важен, и от платформы будет многое зависеть), вы во многом можете полагаться на то, что .NET есть .NET, и кроссплатформить по полной. Что всё это будет означать в контексте деплоя из Xamarin для Android и iOS — пока непонятно, но мне будет очень интересно посмотреть, как все получится.

    — Вы рекомендуете всем по мере возможности переходить на новые версии .NET Core как можно раньше, поскольку он уже стабилен. А что делать с древними .NET 4.0 легаси проектами?

    — В таком случае нет необходимости обновляться до .NET Core. Я бы сказал, что если используешь .NET Core со старой SDK, используешь project.json, то вот тогда определённо стоит мигрировать на новый инструментарий как можно поскорее. Торопиться не надо, но в roadmap это добавить стоит.

    А если у вас только унаследованное приложение, которое работает только с .NET 4… тут все зависит от конкретного случая: если вы видите у него долгосрочное будущее, то может быть смысл инвестировать время в его обновление до .NET Core есть. Если у вас TargetFramework это .NET 4.0, и вы не используете какие-нибудь сомнительные библиотеки, то, скорее всего сможете просто портировать его на .NET Core и обнаружить, что выбор сред развёртывания сильно расширился.

    Скажем, у вас уже есть некоторое количество сервисов, крутящихся на Windows Server, и вы слышите много хорошего о Linux-контейнерах (я в курсе, что существуют win-контейнеры, но в случае с Linux выбор куда шире). Если вы портируете их в .NET Core (а если предположить, что у вас ASP.NET-приложение, то в ASP.NET Core, это немного другое), то выиграете от улучшений тулинга и ширины выбора платформ. Скажем, когда дело дойдёт до Continuous Integration, у вас будет куда больше доступных окружений: вы можете использовать Travis, который не поддерживается Windows: «Эй, это не проблема, я всё также могу запускать тесты на Travis в рамках моей обычной CI». Все эти вещи улучшают жизнь.

    Конечно, это относится не ко всем. Если у вас старое приложение, в котором не ожидается больших изменений, и которое в идеале вообще будет заменено в ближайшее время, то вся работа по портированию будет бессмысленна. Но я думаю, мы склонны недооценивать время, которое проект будет находиться в продакшене, и то количество изменений, которое ему предстоит. Не стоит думать «ничего, вот тут допилю, соберу билд на какой-нибудь старой VS или типа того, в конце концов, таких изменений больше толком и не будет». После того, как вам придётся сделать 20 подобных изменений, год за годом расходуя силы на деплой в устаревших окружениях, вы наконец придёте к мысли «мне стоило постараться раньше и перейти на что-то более современное».

    Кроссплатформенность .NET и конкуренция на рынке серверного enterpise


    — Понятно. Есть ещё вопрос о кроссплатформенности .NET: вы действительно думаете, что поддержка многих платформ — это хорошая идея? Вы уже упомянули, что у вас огромная инфраструктура, но сможет ли .NET соперничать с Java в категории кроссплатформенного энтерпрайза и бэкенда?

    — Абсолютно! Я бы сказал, что это не просто хорошая идея для .NET, это необходимая идея для .NET. Я считаю, что судьба .NET в виде Windows-only платформы с поддержкой сторонних не-очень-то-хорошо-поддерживаемых окружений, нишевых платформ, с которыми люди больше страдают, чем работают, никогда не была перспективной. Так что это была необходимая работа, которая не просто высвободила большой потенциал, но также и не позволит .NET устареть через несколько лет. Я думаю, не-кроссплатформенным серверным решениям придётся несладко. Мы видим то же с окружениями, которые раньше были Linux-only или относились к среде Windows как к «бедной родственнице»: в Windows появилась поддержка для Ruby и Python, которая с течением времени стала заметно лучше. То же самое с Git… Да даже Bash (Shell) теперь есть на Windows. Я думаю, что мультиплатформенность сейчас — это «прожиточный минимум».

    — Понятно. Не могу не задать холиварный вопрос: что вы думаете про .NET в сравнении с Java? Особенно на энтерпрайз-рынке, который, насколько я понимаю, глядя на работу Microsoft над Azure и энтерпрайз-инфраструктурой, является одним из целевых для компании.

    — Я бы сказал, .NET определённо может конкурировать с Java, и если быть честным, я лично всегда предпочту разрабатывать на C#. Просто потому что сам язык намного лучше.

    Тем не менее, у Java есть определенные преимущества: гораздо больше библиотек с открытым кодом (хотя не факт, что они лучше), больше вариантов решения какой-либо проблемы. Если ты выбираешь фреймворк вебсервиса, в Java у тебя, скорее всего, будет не менее 30 вариантов, а в .NET, возможно, 5. Но в любом случае использовать вы будете только один из них, так что в случае, когда и в Java, и в .NET есть хотя бы один хороший вариант, разнообразие Java помогает, но в то же время может сбивать с толку. А если нет доминирующего игрока, разнообразие только усложняет процесс поиска хороших решений. Так что, если вы хотите просто найти фреймворк с хорошей реализацией, это получается почти преимуществом на стороне .NET.

    Кроме того, существует инерция. Мы знаем, что в мире много энтерпрайзных Java-программистов и приложений, и я не думаю, что многие люди скажут «Давайте возьмем это работающее Java-приложение и перепишем его под .NET». Скорее будет так: «Нам по-любому переписывать приложение, поэтому надо выбрать из парочки платформ». А если вы создаете новое приложение — неважно, веб-приложение, сервис или что-то подобное, я думаю, в этом случае Java и .NET должны идти ноздря в ноздрю. Я предполагаю что энтерпрайз будет остерегаться .NET Core ещё год-два, пока он не докажет свою состоятельность, но после этого ожидаю рост использования в энтерпрайзе, и тогда преимущества C# должны дать о себе знать.

    — Да, я понял, спасибо. Я не буду здесь затрагивать более developer-friendly JVM-языки, потому что мы здесь не для холивара :) Но у меня ещё один вопрос: у вас уже есть реально накопленный опыт актуального живого опыта разработки приложений или сервисов под Linux на .NET?

    — Вообще я не разрабатываю приложения в чистом виде, но недавно для Google Cloud Next 2017 вместе с моим менеджером мы внедрили очень маленькое веб-приложение на ASP.NET Core, которое я потом задеплоил в контейнер в AppEngineFlexible Environment. В таком масштабе — да, опыт есть. Также сайт Noda Time построен на ASP.NET Core, сейчас он задеплоен на Windows, но я надеюсь перенести его на Linux, и я не вижу абсолютно никаких причин, почему оно не должно заработать из коробки.

    И по моему опыту, .NET Core для Linux очень хорош, пока вы используете только его. Места, в которых я нашёл проблемы, были в билд-скриптах: только сегодня утром я установил VS Code на мой Linux box, и с Noda Time всё было прекрасно для netcoreapp и netstandard-версий, но при попытке собрать код для .NET 4.5.1 оно сказало: «Эй, я понятия не имею что такое .NET 4.5.1» — поэтому потребовалось включить в билд пару ссылок на референсные сборки. Итак, если вы абсолютно кроссплатформены и нацелены только на .NET Core, я думаю всё хорошо, но если у вас уже есть несколько сборок, где некоторые куски кроссплатформенны, а другие привязаны к полному .NET Framework, тогда все не так хорошо, как хотелось бы. Я уверен, MS работают над этим, и я сам бы мог исправить ситуацию установкой референсных сборок в определённых местах, но я не хочу запускать Windows-код под Linux — я просто хочу кроссплатформеннный код. И эта часть, как я уже сказал, особенно хороша.

    Пара слов о С# 7


    — Поговорим о С#. Версия C# 7 уже вышла и доступна в VS 2017, у нас есть классы кортежей (tuples), pattern matching и другие фичи. Что вы как девелопер думаете об этом релизе и новых фишках? Будут ли они широко использоваться? Или вы бы предпочли, чтобы язык получил какие-то другие примочки?

    — Я крайне доволен C# 7. Сейчас я пишу о нём в четвёртом издании «C# in Depth», поэтому узнаю его гораздо лучше, чем раньше. Прямо сейчас я пишу о кортежах (tuples), фиче, которая выглядит простой, но имеет много скрытых мелочей. Изначально я настороженно относился к кортежам, но теперь вижу их преимущества в реализации. В чём я сейчас не уверен, так это стал бы ли я писать публичные API и выставлять кортежи наружу. Это решение ограничивает разработчиков языка легковесным неинкапсулируемым возвратным типом. В то время как, если возвращать определённый класс, это можно было бы улучшить с течением времени.

    Кортежи станут большим подспорьем для ленивых разработчиков, а мы все должны быть в какой-то мере ленивыми. В пределах определённого класса или даже библиотеки, использующей кортежи (tuples) как легковесный способ группировки переменных вместе, всё должно быть круто.

    Другая важная фича, которую ты упомянул — pattern matching. И самое ценное в pattern matching в С# 7 — это не паттерны, которые мы получили, а введение самой идеи паттернов. Я сознательно разделяю эти понятия. В данный момент мы можем использовать паттерны в операторе «is» и в switch cases. Единственные паттерны, которые у нас есть сейчас — это эквивалентность и совпадение типов. Так что можно или задать «case x is 5», и найдётся совпадение, если значение равно 5, или можно искать совпадение по типу: «x is String». Ранее type matching вызывал возражения, но на практике оказался реально полезным.

    Я уже принял первый C# 7 пулл-реквест в Noda Time от моего друга Билла Вагнера, и этот пулл-реквест наглядно показывает преимущества pattern matching на конкретных примерах. Но на самом деле это показывает извлечённые уроки из F# и Haskell, позволяющих описать функцию через то, как она будет вести себя в разных ситуациях — это по-настоящему понятный путь описания по сравнению с if-else-if-else-if-else. Когда мы говорим «этот case соответствует такому результату, а этот такому», по сути, мы делаем то же, что и if-else, но в гораздо более простом для понимания виде. Все это выглядит многообещающе, и я надеюсь, что в каких-то промежуточных релизах, вроде C# 7.1, мы увидим больше паттернов, таких как деконструкция значений.

    Представим такую ситуацию. У вас есть DateTime, вы можете деконструировать его и найти с pattern matching случаи, где год больше 2016. Вы можете сделать нечто подобное и в C# 6, но поиск соответствий не будет использовать деконструкцию. Так что pattern matching в будущем может дать ещё многое. Это самые большие фичи С# 7, и их не стоит недооценивать.

    Другое большое преимущество для большинства ASP.NET Core пользователей лежит в плосткости async/await: если раньше async-метод мог вернуть только Task, Task или void, то теперь можно вернуть что угодно, совпадающее с определённым паттерном (но это не то же, что pattern matching!), если там есть атрибут, говорящий если ты не создаёшь значение данного типа, используй эту фабрику». Я не думаю, что многие люди будут применять этот паттерн в своем коде, но они могут использовать имплементацию других людей. И ValueTask — более легковесную версия Task — будут использовать почти все, это структура, которую команда ASP.NET Core оптимизировала различными способами, и она будет особенно полезна в ситуациях с низким временем отклика, когда хочется получить все преимущества async, но при этом не нагружать GC заботой о лишних Task-объектах. На мой взгляд, это интересная фича, которую многие будут использовать, не вникая в детали «как имплементировать свой собственный возвратный тип».

    Если просто посмотреть на список фич, то C#, помимо крупных нововведений, получает и небольшие — штуки вроде ref-local и ref-return, довольно сложные для понимания (по крайней мере, для меня). Я полагаю, они будут весьма полезны для Unity-разработчиков высокопроизводительных игр, которые весьма чувствительны к определённым аспектам перфоманса, вроде GC и тому подобного — есть ощушение, что они используют structs больше, чем другие разработчики.

    Также есть замечательные маленькие улучшения вроде out-переменных: возможности объявить переменную в то же время, когда вы используете её для аргумента для выходного параметра, так что больше нет необходимости объявлять:

    int x;
    if (int.TryParse("some text", out x))
    {
    // ...
    }
    

    достаточно просто if (int.TryParse("some text", out int x)), это объявит и распарсит одновременно. Это просто устранение маленького неудобства, и оно показывает намерения проектировщиков C#: везде, где есть какой-то дискомфорт и приходится писать какой-то код, который не хочется писать, потому что он выглядит некрасиво, это исправляют. И out-переменные помогают в этом, как и числовые литералы.

    Наконец, локальные функции. У меня есть пара юзкейсов для локальных функций, связанных с проверкой аргумента, где раньше могло потребоваться разделить метод на два: или async-метод, где вы хотели сделать асинхронную проверку аргумента до перехода к асинхронной части, или, в похожем случае, у вас есть iterator-метод, то при предполагаемом вызове он фактически не исполнит ничего, включая проверку аргументов, поэтому зачастую у меня есть обычный метод, который занимается проверкой аргумента, а потом возвращает FooImpl, где происходит реальная имплементация с итератором. И теперь я смогу писать этот FooImpl как локальный метод. Возможно это не та вещь, которую все будут использовать каждый день, это решение, которое сглаживает шероховатости при написании кода.

    О сообществе разработчиков и умении диагностировать проблемы


    — Я думаю, на этом мы закончили с вопросами по .NET, но у меня есть еще пара более общих вопросов. В данный момент вы #1 в рейтинге Stack Overflow — вы годами отвечали там на тонны вопросов. Можете ли вы сказать, эволюционируют ли разработчики или становится всё больше глупых вопросов?

    — Дело не в том, становятся ли программисты умнее или нет. Я бы сказал так: в ранние периоды вопросы на Stack Overflow были в целом качественнее, так как сайт был не так популярен. Уже давно его использование стало обычным делом, но сейчас это повсеместная практика — а это означает, что менее опытные разработчики, которые были всегда, теперь с большей вероятностью задают свои вопросы. Кроме того, множество хороших вопросов были заданы давно и остаются актуальными и по сей день, и если их задают сейчас, их по вполне понятным причинам закрывают как дубликаты. И я поймал себя на том, что я меньше отвечаю на вопросы, зато оставляю куда больше комментариев вида: «Вам следует попытаться продиагностировать проблему чуть глубже до того, как задавать вопрос, вот несколько советов, как это сделать, а пока что вопрос не очень хороший по содержанию». Я куда больше времени трачу на это, чем непосредственно отвечая на вопросы, потому что, по сути, сейчас не так много вопросов, на которые требуется ответ. Хотя в свете выхода C# 7 должны начать появляться хоршие вопросы конкретно об этой версии.

    Нельзя сказать, что разработчики хуже, чем они должны быть, или что не осталось интересных вопросов. Просто баланс слегка сместился… А вто что меня действительно расстраивает: я вижу множество неопытных разработчиков (часть из которых не считает себя неопытными), демонстрирующих невнимание к другим людям. Они просто думают: «У меня есть проблема, но я не собираюсь сам искать решение, поэтому я попросту задам вопрос», — после чего идёт либо простыня кода, либо вообще никакого кода и фраза: «У меня тут проблемка, можете помочь?». Мы действительно сталкиваемся с вопросами, где нет никакой информации, кроме такой. Хотелось бы, чтобы люди прикладывали больше усилий к формулировке вопроса или учились исследовать проблему, если у них пока недостаточно навыков в диагностических техниках. Когда я учу новый язык или у меня возникает проблема, я всегда пытаюсь свести пример к необходимому минимуму. Ведь даже если люди ожидают, что я знаю ответ, это не всегда так.

    Некоторое время назад я написал блог-пост о том, как запускал некоторые тесты на NUnit для Noda Time, и по каким-то причинам на Linux они работали сильно медленнее, чем на Windows. Следует заметить, что я запускал тесты с локалью en-uk, где было немного кода на NUnit, и в итоге оказалось, что он приводил к использованию String.EndsWith() на каждый assert.EndsWith() делает проверку с учётом локали, хотя NUnit это не требовалось, в итоге это было исправлено. В итоге я обнаружил, что эта проверка и вызывала проблемы. Это было примерно так:

    1. я вижу, что это занимает очень много времени
    2. задаю себе вопрос — это мой код тормозит процесс, или какой-то другой?
    3. я нашёл один тест, который показал проблему
    4. далее я убрал столько кода, сколько мог из этого теста
    5. после этого я исключил Noda Time, написав маленький проект, запускающий NUnit вообще без логического кода
    6. после чего исключил NUnit из схемы, покопавшись в коде NUnit-код и найдя проблему «ааа, String.EndsWith(), окей, давай посмотрим, как оно выполняется»
    7. в этот момент я уже мог воспроизвести проблему с кодом 10 строк длины, запускавшим String.EndsWith() в цикле тысячи раз
    8. стало понятно, что именно этот код на Linux отрабатывал медленно, а на Windows очень быстро
    9. и предоставив всю эту информацию на SO, я смог получить ответ о том, что причина в локали: она оптимизирована под Windows с UK English и не оптимизирована для Linux
    10. в итоге я смог подтвердить это путём запуска этого куска на US English, который был быстр и на Linux.

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

    И я обнаружил, что многие люди не знают, как это делать, или просто не запариваются — они предпочитают задавать вопросы. Еще многие прыгают с головой в языки и платформы до того, как будут действительно готовы. Лично я пытаюсь изучать вещи по одной, зато как следует, но есть куча людей, которые говорят: «Я совершенно новенький в программировании. Сейчас я пишу приложение под Android на Java, взаимодействующее с SQLite. И этот код не работает», — окей, а это проблема Java, проблема Android или проблема SQLite? Вряд ли все три сразу. Что вы сделали, чтобы понять, что является источником проблемы? Поймите, я не докапываюсь, я пытаюсь научить людей помогать самим себе. Я твёрдо убежден, что понимание «как работает мой язык», отдельное от «как работает моя платформа» — это реальное преимущество в отношении того, как быстро вы сможете разобраться и начинать применять что-то при изучении нового.

    — Что вы посоветуете начинающим программистам для относительно гладкого старта в целом или на какой бы то ни было платформах? Стоит ли мне обучаться самостоятельно, или лучше начать с фундаментального образования? На что делать в первую очередь?

    — Учиться можно по-разному, рекомендую начать с книги, — я сам автор, так что это и в моих интересах тоже, но мои книги не предназначены для новичков. Я пытался написать книгу формата «С# для начинающих», но это сложно. В целом, я бы выбрал конкретный язык, и большинство языков подходят для того, чтобы освоиться в них с нуля, если есть подходящий обучающий материал. Так что просто найдите книгу, и убедитесь, что она относительно свежая и охватывает последние изменения языка/платформы. Я бы не начинал с платформ, на которых сложно заниматься диагностикой.

    При изучении новой платформы или языка я всегда начинаю с небольшого консольного приложения, если там вообще есть консоль. С JavaScript сложнее, если только не учишь Node.js или что-то подобное. Для обычных языков вроде C#, Java, Ruby, Python убедитесь, что у вас есть набор инструментов, подходящий для старта. И не пытайтесь сразу сделать веб-приложение или веб-сервис — начните с маленького консольного приложения. У меня есть небольшой набор приложений, которые я пишу на старте. Одна из них — игра, которая загадывает число, а задача пользователя за 5 попыток угадать его, а она говорит, твой вариант больше правильного, меньше или правильный.

    Разработка подобной программы отлично подходит в качестве первого шага овладения языком, потому что нет необходимости знать много о структурах данных, которые поддерживает платформа, о том, как работают словари и другие подобные вещи. Но ее достаточно, чтобы начать. А после этого уже можно сказать: «Окей, теперь я знаю, как выводить в консоль, как читать из консоли». Это может быть не слишком нужно для веб-приложения, но просто необходимо для диагностики: можно разбираться с кодом в отладчике, и вы скорее будете делать это в консольном приложении, чем в iOS-приложении, например. Я уверен, что под iOS отладочные инструменты тоже есть, но их гораздо сложнее понять, пока вы не погрузитесь в язык полностью.

    Как я уже упоминал, этот первый шаг не затрагивает словари, списки, функции и тому подобное. Поэтому дальше начинайте писать следующее консольное приложение, которое покрывает все эти возможности, например: «создать список Strings и сделать на его основе другой список из перевёрнутых Strings» — маленькое приложение, которое делает только это. И если у вас появятся какие-либо проблемы, вы будете знать, что проблема только в понимании той конкретной темы, над которой вы сейчас работаете. Если вы хотите создать бесподобное приложение или игру, то держите это в голове. Но никогда не начинайте погружение в проект с нее. Вам нужен серьёзный фундамент, прежде чем создать что-то большое. Это всё равно что сказать «Мне хочется пробежать марафон, так что завтра, никогда раньше не бегав, я пойду и пробегу марафон». У вас не получится, это деморализует вас, и это только навредит вам — до этого нужно дорасти. Так же и с программным обеспечением.

    Сложности в создании компьютерной модели реального мира


    — Ого, последний пример хорош. Вот о чем я еще хотел спросить, в своем докладе для DotNext «Back to Basics» вы говорите о связи между реальной жизнью и моделями, которые мы создаём в разработке ПО: типами данных, структурами и тому подобным. Что-либо поменялось в этой области за последние пару лет?

    — Доклад посвящён трём наборам типов: как компьютеры взаимодействуют с числами, текстом, и датой/временем. В широком смысле за последние годы ничего не поменялось, легче точно не стало, возможно, даже стало слегка сложнее из-за Unicode как общемирового способа работы с текстом. Существует 65536 кодовых пунктов, некоторые из которых не назначены, и всё это называется Basic Multilingual Plane. А есть ещё другие planes, и раньше я мог говорить «можете их игнорировать, всё, что вам когда-либо понадобится, есть в BMP», так что не нужно беспокоиться о представлении не-BMP символов как пар BMP. И даже это уже неправда из-за эмодзи! 10 лет назад можно было никогда встретить символ не из BMP, а теперь большинство людей, читающих это интервью, видят как минимум один не-BMP символ в день.

    Вот пример: у вас есть поле ввода, где пользователь может набрать не более 10 символов, что это значит? Даже без BMP вы можете иметь «e» с острым ударением на нём, и это может быть представлено как двумя символами, так и одним, в зависимости от нормализации. То же самое работает для emoji: в Java и .NET, если вы используете String.Length(), увидите длину два символа для каждого символа эмодзи. Значит ли это, что пользователь может ввести всего пять? Это будет странно с точки зрения пользователя: им говорят, что у них есть десять символов, но они могут ввести только пять. Так что да, эмодзи сделали жизнь сложнее.

    В отношении чисел, похоже, ничего не изменилось. В отношении даты и времени с момента, когда я выступал с этим докладом впервые, кое-что поменялось на фронте .NET: Noda Time, моя собственная библиотека для работы с датами и временем. Она дошла до релиза, а сейчас я уже выпустил версию 2.0. Я бы сказал, что в случае с датой и временем всё постепенно становится лучше, всё больше людей проникаются пониманием, что проблема существует. У меня есть пара друзей, которые работают над улучшением основных типов даты и времени в JavaScript и добавлением новых, потому что мы использовали Date в JS очень долго, а оно во многих случаях работает неправильно. Поэтому они усердно работают над созданием более практичного JavaScript API для даты и времени, чем есть сейчас.

    Все развивается, но базовые задачи компьютеров предполагают простые модели, а разработчики считают, что компьютер должен понимать и предметную область, и тогда возникают вопросы вроде: «я разделил 5 на 10 и получил 0, а не 0.5», — ну, стоило использовать числа с плавающей точкой или ещё что.

    Вместо заключения


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

    — Хорошо, я перейду от некоторых очень конкретных идей к некоторым обобщениям:

    1. Определённо, попробуйте Noda Time, если вы используете где-либо в вашем коде дату и время. Если у вас есть DateTime.Now() где-то в вашей кодовой базе, то есть вероятность, что у вас есть ошибки. Поэтому я настоятельно рекомендую изучить Noda Time.

    2. Если говорить в общем, мне также хочется, чтобы люди больше думали о документации. Есть проект под названием DocFX, который в некотором роде превзошёл Sandcastle, но я думаю, что мы можем сделать намного больше. Дополнительная документация с перекрёстными ссылками между разными элементами. Только представьте мир, в котором документация является достаточно машиночитаемой, чтобы, когда вы ссылаетесь на какую-либо документацию в Stack Overflow, вы просто нажимаете кнопку, начинаете вводить имя типа, и видите предварительный просмотр: «это тот тип, который вы имеете в виду?» Я думаю, жить в таком мире было бы замечательно.

    3. Ещё важнее этого разнообразие людей в мире технологий. Я выступаю на многих конференциях, и аудитория, как правило, — белые мужчины, и это расстраивает меня. Нам нужно больше гендерного разнообразия, нам нужно больше расового разнообразия, просто взгляните на статистику… она расстраивает. Каждый должен участвовать в искоренении всех форм сексуального домогательства, всех форм расизма в нашей отрасли. Более того, поощрять окружающих, понимать подсознательные предубеждения и бороться за то, чтобы создать как можно более равное условия деятельности для всех.

    Если отстраниться от нашей индустрии, мои личные интересы — это гендерное равенство в целом, скажем так, я уже 2,5 года начинающий феминист. Поэтому я рекомендую всем прочитать что-то вроде «Everyday sexism», чтобы посмотреть, как этот мир выглядит с точки зрения других людей. Все это довольно страшно, и это, безусловно, изменило мой взгляд на многие вещи.



    Отдельно хочу поблагодарить Женю phillennium Трифонова и Андрея DreamWalker Акиньшина за помощь в подготовке поста. Плюсы вам в карму!
    Метки:
    JUG.ru Group 859,63
    Конференции для взрослых. Java, .NET, JS и др. 18+
    Поделиться публикацией
    Комментарии 530
    • +13

      Ага когда выпустили .NET говорили что он убьет java очень скоро, мс даже спец программу организовало JUMP — Java User Migration Path. Не выгорело тогда, не выгорит и сейчас. MS с core конопашуться уже больше года, у java jigsaw должен выйти этим летом, не все так просто.

      • +18
        Так никто не говорит об убийстве. Речь о возможности выбора и здоровой конкуренции.
        • +5

          Выбор есть и сейчас. Вы уж простите но слышать о здоровой конкуренции в отношении MS как то без тика не получается.

          • +13
            С Oracle получается?
            • 0

              Не Oracle единым жива java, хвала аллаху.

              • +8
                Не Microsoft единым жив .Net ;)
                • +2
                  А чем еще он жив? Не продвигай Microsoft активно свой продукты среди студентов и университетов, ситуация с .NET была бы в худшую сторону
                  • +11
                    Да, именно на студентах .Net и держится. (до оракла у Sun были Java ambassador если что).


                    • –14

                      смешно видеть на этой картинке JetBrains, которые даже под .net (resharper) пишут на Java/Kotlin ;)

                      • +19
                        Смешно читать такие глупости на хабре
                        • +5
                          Решарпер-то как раз на .NET. Вот тут они пишут про проблемы с ним на Mono.
                          • +5
                            решарпер написан на c#. Вы путаете с графической оболочкой написанной на java. Даже доклад про то, как они делали протокол общения между рантаймами
                      • +7
                        Как минимум есть еще Unity, в котором большинство людей предпочитает использовать именно c#, несмотря на кучу других вариантов языков. А это уже очень большой приток людей.
                        • 0
                          Нет в Юнити никакой кучи языков. Кроме C#, были еще UnityScript и Boo, второй уже окончательно похоронили давно, первый собираются похоронить со следующей версии. Так что да, практически все пишут на С#
                          • +2
                            Простите что вмешиваюсь, а разве Javascript в Unity не было?..
                            • +2
                              Был UnityScript, который все называли JavaScript. Между ними огромная пропасть, но если не присматриваться, то было похоже на JS. Всего лишь завлекалочка для новичков и веб-разработчиков.
                              • +1
                                Javascript в Unity отличается от стандарта и называется UnityScript.
                    • +4

                      Java заняла нишу enterprise когда oracle был ещё не при делах. Тогда это был ещё Sun.

                    • +2
                      А о здоровой конкуренции в отношении Oracle? Это ещё менее вероятно.
                    • +3
                      Ждем IDE уровня IntelliJ IDE написанную на .NET и кроссплатформенную при этом. Тогда можно будет говорить о переходе.

                      Уточню — целиком на .NET. Проект Rider — не то. Хотя если имплементировать какой то бекэнд, который сможет воспользоваться наработками Rider…

                      Там Visual Studio еще не портировали на Linux?
                        • +11
                          Visual Studio Code и Visual Studio это две совершенно разные вещи.
                          • +8

                            Это как Java и JavaScript. Обречены на неразбериху во имя маркетинга.

                          • +4
                            Во первых это не Visual Studio, как заметили выше. В качестве текстового редактора я могу и ViM (Sublime, emacs, etc.) использовать.
                            Во вторых достаточно того что и во первых это приложение на Electron. Увы :(
                          • +4

                            Какое отношение эта гипотетическая IDE имеет к энтерпрайзу?

                            • +3
                              Показатель зрелости платформы. Наличие на Linux/MacOS IDE для .NET написаной на этом самом .NET означает возможность писать самые разнообразные приложения(desktop + server).

                              Уточню — это лишь мое мнение, но в любом случае — в чем то же надо писать код? Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). Ежели я ошибаюсь — прошу меня поправить и указать на мою ошибку ссылкой.
                              • 0

                                Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.


                                Используют же некоторые дизайнеры MacOS чтобы рисовать интерфейсы под винду...

                                • +4
                                  Вообще-то, между «писать код» и «рисовать интерфейсы» имеется принципиальная разница. Но т.к. целевая аудитория маркетоложцев эту разницу не знает, то в рекламе Ваш аргумент вполне сгодится.
                                  • +1
                                    Ну вообще-то куча всего для мобильных устройств /приставок/всякого специального железа пишется в Винде отлаживается в ней же или в эмуляторах, и никакая «принципиальная разница» никого не.

                                    В случае «пилим кговавый ынтерпрайз, работающий на сервере в виртуальной машине» ИМХО вообще пофигу на среду, к которой пишем. И довольно значительный процент явистов, пишущих в винде тому подтверждение.
                                  • 0
                                    Мешает. Самооценка и тараканы в голове. Ну это лично мне.

                                    Мне не повезло познакомится с линуксом в раннем возрасте и учиться писать код я начинал именно с линукса. С тех пор родовая травма — не могу использовать Windows для разработки. Точнее могу, но это неприятно.
                                    • –1
                                      Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.
                                      Мешает. Для того, чтобы использовать «default operating system» в местах, где она не «default» нужна уйма инфраструктуры. Kerberos и LDAP использовать нельзя, нужны сервера на Windows и масса плясок с бубнами, чтобы две операционки подружить. Это для начала. А потом выяснится что и принтеры нужно особо поддерживать и прочее.

                                      Понятно, что живущие в «default operating system» об этом не задумываются (как и живущие в «default city»), но Microsoft Windows — это «остров, у которого всё своё». Собственно это специально сделали — и этот подход отлично работал: стоит вам использовать хоть что-то от Microsoft — и вам придётся использовать массу других вещей от них же. Но в Enterprise — всё не так: не нужен там никакой Microsoft (у них Oracle рулит и стонут они от него так же, как от Microsoft'а стонет малый бизнес — но это другая история), так что IDE под «default opertaion system», извините, не вариант.

                                      Собственно Microsoft это осознал примерно тогда же, когда и все остальные — но, увы, если «стены» стоить десятилятеями, то дальше их разрушить за пару лет — не выйдет.
                                      • 0

                                        Э… а конкретные примеры того, что нельзя подружить, будут?


                                        Для меня, как для программиста, все довольно понятно — есть задача, есть протокол/формат/что-то еще, есть библиотека, пишу решение. Если нет библиотеки — пишу решение дольше, с перспективой создания библиотеки.


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

                                        • –1
                                          Э… а конкретные примеры того, что нельзя подружить, будут?
                                          А того, что написано выше — недостаточно?

                                          В какой момент возникают пляски с бубнами, которые не позволяют мне писать решение для задачи?
                                          В тот момент, когда вы решили, что хотите использовать «default operation system».

                                          Вспомните ещё раз: мы тут про «ынтырпрайз», да? Ну и хорошо, понеслась. Для доступа в Internet — у вас какой-нибудь Uberproxy с правами доступа в LDAP и авторизацией через Kerberos. Печатаете вы через CUPS, общие файлы — выкладываются на NFS, а управляется это всё — через Ansible.

                                          И вот вы во всё это желаете вкрутить вашу «default operation system». Кто будет «дружить» эти два мира? Притом, что Windows-админы, которых вы можете найти на рынке обычно — «ни в зуб ногой в области POSIX-технологий», а POSIX-админам — ваши «default operation system» со всеми их заморочками — не нужны от слова «совсем»?
                                          • –1

                                            Все еще не понимаю, зачем в такой структуре нужны виндовые серверы.

                                            • –1
                                              Они не нужны. Как и виндовые десктопы для разработки :)
                                            • 0

                                              А, я понял. Вы рассматриваете гипотетическую ситуацию, когда какая-то совтописательная фирма с инфраструктурой только на линуксе пытается начать писать на .NET.


                                              Да, это может внезапно оказаться довольно сложным процессом.


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

                                              • 0
                                                Вы забыли время на изучение инфраструктуры для разработки на этом языке и время на изучение ОС. Разработчики они разные. Я вот Windows дома не держу уже несколько лет.
                                                • –1
                                                  ок, тогда что вы тут в комментариях делаете? Да, вам .net core не подходит, это стало понятно из комментариев выше, мне это было важно и дествительно интересно услышать. Но если вам он не подходит, не значит что не подходит другим.
                                                  • 0
                                                    Внезапно! Они утверждают, что .NET пригоден для разработки под Linux без лишних телодвижений!

                                                    Вот я и пытаюсь понять, они немного преувеличивают, преувеличивают нагло или же все хорошо и можно писать код?

                                                    Пока что получается, что преувеличивают нагло и среднестатистический разработчик не желающий использовать Windows удобным образом писать под .NET не сможет. Согласны?
                                                    • 0
                                                      Собственно в этом весь смысл всех этих телодвижений. Как уже говорилось много лет назад: Microsoft категорически не заинтересован в том, чтобы люди могли использовать их инструменты без их экосистемы. Попытку сделать так, чтобы люди использовали везде и всюду только и исключительно экосистему Microsoft провалилась. Таким образом приходится мириться с существованием других систем и пытаться сделать так, чтобы разработчики туда не убежали.

                                                      Ну подумайте сами: какой смысл Microsoft'у делать хоть что-то для того, чтобы улучшить жизнь разрабочиков, использующих не Windows?
                                                • 0
                                                  Но конкретному разработчику, в отличие от организации, перейти на новый язык довольно просто.
                                                  Читаем заголовок статьи, которую мы тут обсуждаем, да?
                                                      Через год-два .NET Core потеснит Java на рынке enterprise решений

                                                  Это у вас «конкретный разработчик» не связанный ни с какой организацией играет на рынке «enterprise решений»?
                                                  • 0

                                                    Все проекты делаются конкретными разработчиками.

                                                    • 0
                                                      Вот только в случае с «enterprise решениями» они, как правило, работают не в одиночку, а в команде. И интересы пресловутого «enterprise» в 100 раз важнее интересов конкретного разработчика.

                                                      Разработать без интеграции с существующими решаниями вам дадут разве что «приложение» для заказа пиццы в офис. Во всех остальных случаях — я придётся учитывать и ограничения вещей, созданных 40 лет назад на Cobol'е и 10 лет назад на Java.
                                                      • 0

                                                        Не вижу никаких проблем интегрироваться с чем-то, созданным 40 лет назад на Cobol или 10 лет назад на Java.

                                          • +1
                                            Т.е. Вы предлагает к ИДЕ докупить еше и винду + выделить для нее машину (виртуалку), только чтобы…?
                                            • +6

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

                                              • –2
                                                Если вы и правда квалифицированный энтерпрайз-разработчик, чье время ценно.
                                                Если вы «квалифицированный энтерпрайз-разработчик, чье время ценно», то вы в гробу видали «винду, IDE и даже новый компьютер», зато, возможно, неплохо знаете Cobol.

                                                В мире энтерпрайзра Windows — так и не стала «default operation system», несмотря на все потуги (если бы стала — рассказов про то, что она вот-вот «всех порвёт на энтерпрайз-рынке» не было бы). Так что вам, в прикуску к «новому языку» придётся одновременно изучить новую OS и новую IDE.

                                                То есть вы должны быть фактически готовы переехать в другую страну, выучить новый язык, сменить машину, работу и жену — и всё это ради каких-то мифических плюшек этого языка, про которые вы заранее ничего не знаете?

                                                Вы точно уверены, что вы всё ещё «квалифицированный энтерпрайз-разработчик, чье время ценно», а не «безбашенный стартапер, которому семь вёрст не крюк»?
                                                • 0
                                                  В мире энтерпрайзра Windows — так и не стала «default operation system»

                                                  AD и Exchange есть у всех, даже в Яндексе с Фейсбуком.
                                                  • 0
                                                    А можно чуть подробней про Exchange в Яндексе? Зачем он им?
                                                    • +1
                                                      OWA извне больше недоступна, есть только Autodiscover:

                                                      Non-authoritative answer:
                                                      Name:    exchange-2013.yandex-team.ru
                                                      Addresses:  2a02:6b8:0:3400::1:25
                                                                213.180.205.25
                                                      Aliases:  autodiscover.yandex-team.ru
                                                                amber.yandex-team.ru
                                                                amber-2013.yandex-team.ru
                                                      

                                                      Подробности надо спрашивать у яндексоидов, думаю оставили для бизнеса привыкшего к удобству: достойных конкурентов связке Outlook + Exchange так и не появилось.
                                                    • 0
                                                      Одно дело — иметь тестовый стенд для разработки Windows-приложений, совсем другое — давать доступ в корпоративную сеть.
                                                      • 0
                                                        Большинство российских банков использует AD для авторизации/аутентификации, хотя бизнес-приложения могут крутиться на Linux, AIX или OS/400.
                                                        • 0
                                                          Продакшен-системы мобильных операторов тоже. Лично писал надстройку над OpenLdap для интеграции нашей Linux-системы — нахождения нужных данных в распределенном по разным серверам дереве AD.
                                                  • –3
                                                    В моей жизни было полгода(с конца августа по середину марта) когда я вынужден был использовать Windows 7 как ОС для разработки на Java.

                                                    Спасало только наличие неплохого GUI в IntelliJ IDEA. Любой шаг в сторону от стандартного флоу «закодил — > запустил тесты -> закоммитил» был тяжек и труден. Все что в линуксе решается в одном окошке консоли на винде требовало больше усилий и движений. В гробу я видал Windows 7 как ОС для разработки на Java.

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

                                                    P.S.: Удобное рабочее окружение — это повод купить Mac. Однако не все могут согласиться с этим.
                                                    • 0

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


                                                      Мне кажется, это просто сказывалась субъективная непривычность обстановки, а не какие-то объективные недостатки.


                                                      Не могли бы вы уточнить что именно требовало у вас избыточного числа движений?

                                                      • 0
                                                        1. Работа с Git
                                                        2. Работа с удаленными серверами по SSH
                                                        3. Сборка проекта с нестандартными параметрами
                                                        4. Обработка данных при помощи простеньких скриптов

                                                        Поясню на примере — для выполнения этих задач в Linux мне требовалось всего одно окошко терминала в котором я мог все эти задачи выполнить одинаково хорошо. В Windows это требовало 4 разных окошек — Git Bash, SuperPutty, окошко запуска команд в IntelliJ IDEA и наконец Cygwin. Половина из этих инструментов не кастомизировалась или кастомизировалась весьма не просто в плане внешнего вида(банальные шрифты).

                                                        Этого достаточно?
                                                        • +1

                                                          Для всех этих задач вполне достаточно одного окна, раз уж для вас это так важно.


                                                          Для начала, Git Bash для работы с Git не обязателен.


                                                          Далее, никто не запрещает вместо Putty (кстати, что это за сборка такая — SuperPutty?) использовать OpenSSH, тем более что ssh.exe идет вместе с git.


                                                          Сборку проекта можно делать в том же самом окне если правильно прописать переменные окружения.


                                                          Для четверной задачи, раз вы привыкли к linux-окружению, конечно же придется использовать cygwin… Вот только cygwin не отбирает у вас возможность использовать git, openssh и собирать проект в том же самом окне.

                                                          • –3
                                                            К сожалению все вместе так и не получилось это настроить удобным образом. Возможно дело в руках или отсутствии желания.

                                                            Да и выглядит это все как то не очень красиво (я сейчас именно про внешний вид), возможно из-за ограничений виндового терминала.
                                                            • 0

                                                              Ну, это больше ограничения стандартных шрифтов. И стандартного же cmd.exe. Те же git bash или консоль cygwin выглядят довольно неплохо, на мой вкус.


                                                              Говорят, еще в десятой винде консоль значительно переделали. Но сам я десятку еще не трогал, сижу на семерках-восьмерках.

                                                              • 0
                                                                Была бы на моей прошлой работе десятка с Ubuntu on Windows — я бы может и относился бы к винде по другому. С семеркой подружиться после нескольких лет линукса не получилось.

                                                                P.S.: Хабрасуицид совершен успешно)
                                                    • –2
                                                      При всем обилии адептов Windows, которые плачутся что Linux слишком сложен, я впервые вижу линуксоида, который плачется что windows слишком сложен. Как говорится, не думал что доживу до этого момента.
                                                      • +3
                                                        Он не сложен, он не удобен. Он заставляет ломать сложившиеся привычки. Как и Linux для пользователей Windows.

                                                        Все дело в привычках. Банальная вставка по средней клавиши мыши(отвыкать пришлось долго). Удобный и красивый эмулятор терминала. И много других мелочей которых нет на тех версиях Windows, с которыми я работал и которые есть в Linux. Ну и разумеется отсутствие привычного софта без костылей для установки и использования.

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

                                                        Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие места в кровавом энтерпрайзе? Я искренне радовался выходу Ubuntu on Windows. А потома до меня дошло, что большая часть работодателей вряд ли в ближайшее время запланируют апгрейд. И следовательно смысла в этой подсистеме не очень много.
                                                        • +1

                                                          Вставку по средней кнопке в протоколе Нового Более Лучшего Дисплейного Сервера убрали, кстати. Во всяких федорах её сбоку изолентой прикрутили

                                                          • 0
                                                            Нового Более Лучшего Дисплейного Сервера

                                                            Это вы так вайланд обозвали?

                                                            Блин, сволочи они(
                                                          • 0
                                                            Я искренне радовался выходу Ubuntu on Windows.
                                                            Это не клиентская фича, она работает только в режиме разработчика.
                                                            • 0
                                                              Это что-то меняет для разработика или админа? :)
                                                              • 0
                                                                На клиентской машине баш-скрипты не запустишь.
                                                                • 0
                                                                  А зачем они вам на клиентской машине, а не серваке? 0_о
                                                                  • 0
                                                                    Я не админ, поэтому плохо понимаю, зачем они на винде вообще. Но в комменте, на который я отвечал
                                                                    Возможно, Windows 10 многое изменит, но когда она еще попадет на рабочие местав кровавом энтерпрайзе?
                                                                    Так что перенаправьте вопрос TheKnight, зачем ему Ubuntu на клиентских виндах.
                                                                    • +1
                                                                      Задачи разные бывают. К примеру, иногда эти скрипты надо отлаживать и писать.
                                                    • 0
                                                      Ничто не мешает для написания кода использовать default desktop operating system, даже если запускаться он должен будет под Linux или MacOS.

                                                      Использовать можно. Удобно — далеко не всегда. Можно конечно пользоваться виртуалками, но это опять таки менее удобно получается. Всякие hot redeploy и прочее далеко не всегда работают сквозь виртуалку.

                                                      • 0
                                                        Ubuntu on Windows. Там вполне неплохо поддержали много апи в AE. Редиска уже там, все утилиты то же через это чудо. wrk нормально собирается и работает. Пока другое не пробовал, но вполне. Может будет интересно.
                                                        • +1

                                                          Напомню, мы говорим об энтерпрайзе. Тут считается нормальным купить за большие деньги Talend MDM, который идет со своей Talend MDM Studio на базе Eclipse и не имеет консольных утилит для сборки (прощай, CI и CD!), и посадить опытных Java-разработчиков парсить XML-документы регулярками, потому что другого API не завезли.


                                                          И чтобы жизнь медом не казалась, надо загнать всех на удаленную работу через тормозной и глючный VPN, работающий только через IE на терминальный сервер, где один экземпляр Talend MDM Studio выжирает по 2 гига памяти, а их запущено пять штук...


                                                          А когда настанет время развертывания релиза на стенде интеграционного тестирования — то десять тысяч документов будут загружаться напрямую в базу вручную разработчиками потому что Talend на таких объемах умирает.


                                                          А другой разработчик будет их же публиковать на портале, потому что интеграция не работает в этом режиме.


                                                          И после этого вы жалуетесь на какие-то виртуалки? Между прочим, на хорошем железе виртуалки довольно шустро работают, даже если внутрях — серверная винда с Sharepoint… Тоже, кстати, тормозная хрень, но хотя бы память не выжирает и CI поддерживает.

                                                          • 0

                                                            Рассуждения "у кого-то процесс разработки построен через жопу, поэтому мы тоже через жопу делать будем" порочны по самой своей сути.


                                                            А виртуалки мне не нравятся не из-за тормознутости (вот как раз эта проблема решается легко).
                                                            Вот один пример из жизни пример — на одном из проектов были тесты, которые нормально работают только под линукс. А разработка под виндой. Как результат нельзя просто взять и запустить тесты из IDE. Можно запустить из консоли через билд систему (maven), но там запускаются все тесты, а прогон всех тестов занимает минут 20-30. Да, это можно решить отдав правильные аргументы maven'у, но все-равно неудобно. Ну и запустить таким образом тесты с дебагом становится отдельным испытанием.

                                                    • +3

                                                      Насколько я понимаю, на альтернативных платформах у дотнета в принципе нет официально поддерживаемого GUI.

                                                      • +2
                                                        А чем все-таки Rider не угодил?
                                                        • 0
                                                          1. EAP — релиз обещали осенью 2016, ЕМНИП
                                                          2. Не чистый .NET
                                                          3. Из-за некоторых технических решений является пруфом(возможным) того, что .NET Core из коробки нельзя использовать для определенного класса задач совсем. Подразумевается написание десктопных приложений.


                                                          В остальном я верю в JetBrains и в то, что у них выйдет офигенный инструмент. У меня и претензий то к нему нет, есть претензии к отсутствию аналога написанного целиком на .NET.

                                                          P.S.: [humor]А как прописывается тег хабрасуицид?[/humor]
                                                          • +1
                                                            Абсолютно согласен, что Rider нельзя называть примерном зрелости кросплатформенного .net, мой вопрос был больше к фразе «Пока что я не вижу IDE уровня IntelliJ IDEA или Visual Studio под эти платформы (да даже не важно на чем оно написано). » =)
                                                            • 0
                                                              Наверное дело все же в EAP статусе Rider. Все же этот статус накладывает определенные ограничения на его использование. Точнее, на его оценку как хорошего инструмента.

                                                              Что то может измениться, в том числе и критично для пользователя. Посему, конкретные выводы делать рано. Но я в вас верю :)
                                                            • +1
                                                              зачем вам чистый .NET?
                                                              • +1
                                                                Затем что мне не хочется писать гибридное приложение с GUI на Java и логикой на .NET.

                                                                Кроме того хочется переиспользовать имеющиеся наработки и просто портировать приложение внутри одной платформы, не переписывая его целиком на другом языке.
                                                                • –2
                                                                  Rider. В нем графическая оболочка это java, а логика c#. Как раз тот пример, который вам нужен?
                                                                  • +1
                                                                    Это как раз пример того, что мне не нужно. Читайте пожалуйста внимательней.
                                                                    • 0
                                                                      Точно, приношу извинения.
                                                                  • 0
                                                                    уже есть либы позволяющие писать кросплатформенную графику на .net core
                                                            • +2

                                                              Тем, что он не является полноценной заменой Visual Studio:


                                                              1. Он будет платный, тогда как VS бесплатна даже для использования в небольших коммерческих проектах.
                                                              2. Не поддерживает несколько языков в одном солюшене.
                                                              3. В стадии EAP: имеет ряд багов, тормозит на больших проектах и файлах, которые VS тянет легко.
                                                              4. Имеет очень слабый функционал по отладке приложений по сравнению с Visual Studio:
                                                                • слабый Expression Evaluation (нет поддержки пользовательского отображения значений);
                                                                • нет нормальной поддержки асихронных задач (невозможность пошаговой отладки при использовании async/await);
                                                                • нет остановки в момент выброса любого исключения (проблему в разы быстрее решить прямо на месте, чем изучать стектрейсы).

                                                              Лично для меня эти моменты очень приципиальны. Поэтому для написания кода я обычно использую Rider, но если нужен отладчик — переключаюсь в VS.

                                                              • 0
                                                                Ну так и в статье написано, что «через год-два». Первый пункт неоспорим, а остальные мы надеемся поправить к этому времени =)
                                                                • +2
                                                                  ормозит на больших проектах и файлах, которые VS тянет легко.

                                                                  В нашем solution (150 проектов, WPF, Xamarin), тянет на ура. При вытягивании изменений из гита, за 1-2 секунды готов уже к работе, тогда как студия с трудом переживает внешние изменения в более чем 2-3 проектах. Как правило выжирает 2гб оперативной памяти и зависает.

                                                                  Райдер (не холодный запуск) за 5с открывает наш solution, тогда как студия (2015) 30-40с.
                                                                  Никаких тормозов уже не наблюдаю. 2 месяца пишу только в нем.

                                                                  Последние 2-3 EAP стали вполне рабочими, хотя баги встречаются, но не были для меня принципиальными.
                                                                  • 0
                                                                    Решит ли проблему, использования nuget пакетов вместо проектов? Можно ли подцепить туда pdb, чтобы можно было отлажиывться в «чужих» проектах?
                                                        • 0

                                                          Да дело далеко не только в IDE. И вообще не в языках. Я бы лично хотел посмотреть на хоть какой-то аналог OSGI. Или ESB (что-нибудь вроде Camel). Или я не туда смотрю — но ничего подобного вобще не попадается на глаза.

                                                          • +2

                                                            OSGI -> AppDomains
                                                            ESB -> WCF
                                                            Конечно они не идентичны, но решают похожие задачи

                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                              • 0

                                                                Насколько я понимаю (хотя тут я могу ошибаться), WCF далеко не аналог шине в нормальном ее виде. Т.е. скажем это ближе к Apache CXF, в лучшем случае, а до Karaf + Camel + CXF + MQ, так как выглядит нормальная шина в мире Java, ему как до луны.


                                                                Вот насколько они не идентичны — настолько .Net code Java и потеснит в энтерпрайзе :)

                                                                • +2

                                                                  Все дело в том, что значит "нормальная".
                                                                  Когда я делал корпоративное ПО на java, я тоже так считал, но потом у меня появилась возможность сравнить.
                                                                  В java нет такого понятия как сборка (Assembly — the smallest unit of versioning, security, deployment and reusability of code in .Net.)
                                                                  Из этого маленького нюанса растут все различия в корпоративных фреймворках для .net и jvm.
                                                                  Например, в .net не аналога Camel, не потому что он "не энтерпрайзный", а потому что нет самой проблемы которую он призван решить. Поэтому же нет прямого аналога OSGI. WCF+IOC+MQ-брокер + AppDomains, как изолированная среда, это примерный аналог.
                                                                  Я не вижу такой технической проблемы в корпоративном ПО, которую невозможно/сложнее решать на .net, чем на java. Просто используется другой набор фреймворков, немного другие подходы.
                                                                  Думаю посыл статьи в том, что с приходом .NETStandard 2 все это добро будет доступно на unix-системах, вот и получается прямая конкуренция.

                                                                  • 0

                                                                    Что значит "нет проблемы", которую решает Camel?


                                                                    Camel не решает технические проблемы JVM или языка — он решает бизнес проблемы интеграции. И аналоги у него есть совершенно прямые — например MS SSIS. И это не просто ужас, а ужас-ужас-ужас. Это я не к тому, что решения от MS плохие, а к тому, что есть бизнес проблема интеграции, которую пытается решать например SSIS, и решает ее по сравнению с Camel ужасно. Суть в том, что потребность есть, и еще какая.


                                                                    OSGI в общем-то тоже — потому что проблема иметь независимые взаимодействующие компоненты называйте их как хотите, но не будете же вы утверждать, что возня вокруг "микросервисов" происходит на пустом месте?).


                                                                    Так вот OSGI — это и есть микросервисы в чистом виде. IOC ему кстати не замена, а лишь маленькая его часть.


                                                                    Ну и кстати в разрезе IDE — меня лично гораздо больше волнуют другие инструменты, потому что после maven/gtadle/чего угодно такая штуковина как MSBuild просто выводит из себя.

                                                                    • 0
                                                                      Не MSBuild ом единым.Есть PSake, Cake. Для F# есть Fake. Это из тех что я знаю.
                                                                      А что у вас с MSBuild? В принципе после прочтения пары док вполне неплохо. Собираю им сложные проекты, в него же уехали gulp, npm, webpack и куча PS скриптов.
                                                                      • 0
                                                                        Fake не только для F#, так же как и PSake и Cake не только для проектов на C#.
                                                                      • +1

                                                                        SSIS — это хрень, которую продают никогда не писавшие кода маркетологи никогда не писавшим кода архитекторам.


                                                                        Не следует по этой хрени судить о экосистеме .NET, тут есть и более приятные вещи.

                                                                        • 0

                                                                          Я его привел исключительно в качестве примера наличия потребности, которой якобы нет.

                                                                          • 0

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

                                                                            • 0

                                                                              Ну, типичный кейс выглядит как-то так — есть несвязанные между собой изначально системы. Нужно как-то их связать, передавая данные. Как принято, на входе с ними работает процесс ETL. Он может принимать файлы, а может таблицы из другой базы. И на выходе может делать разное. Как мне тут намекнули, WCF все-таки очень похожая штука — есть endpoints, которые являются входами и выходами, и есть некие маршруты обработки и передачи данных между ними (обычно именуемые EIP).


                                                                              Вот эти вот ETL на нем и пишут. В моем проекте я ровно тоже самое делал на Camel, при этом значительно удобнее.


                                                                              Опять же — это не довод за то, что какие-то там другие решения плохи или хороши — это довод именно за то, что потребность в разного рода ETL очень широкая.


                                                                              Я про банки, если что...

                                                                              • 0

                                                                                Нет, WCF — это не про ETL. WCF — это про SOA.


                                                                                У меня был опыт работы с ETL, и я считаю, что самый лучший формат для ETL-процедуры — это обычное консольное приложение.


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

                                                                                • –1

                                                                                  А какая разница, SOA или нет, если там реально есть EIP? На входе например клиент SOA, потом маршрут обработки, потом какой-то выход. Если входы и выходы хоть как-то настраиваются, и есть какой-никакой язык для описания маршрутов (ну скажем, годится BPEL), то это и будет в конечном счете ESB или шина. Все же ETL это как правило некий клей для сервисов, написанных разными командами, и для этого удобнее средства типа скриптовых языков, или похожие инструменты.


                                                                                  Что же до консольного приложения в качестве ETL, то оно как бы и нормально, пока у вас их два. А когда их двадцать два, ими надо рулить, хотя бы в объеме чтобы само запустилось после рестарта сервера. Ну и как вы представляете себе 22 микросервиса в виде сервисов windows, например? Ну и потом, они могут быть хоть и независимые друг от друга по логике, но все равно зависимы по данным (например, на 100 сервисов порядка 10 коннектов к разным базам), поэтому настраивать теже коннкеты все-таки проще один раз, нежели для каждого из 100 микросервисов помнить, какая у нас тут база, это PROD или тестовый сервер, ну и все такое.


                                                                                  Ну то есть если совсем просто — то ESB или шина это обычно куча мелких сервисов интеграции, но с централизованным управлением и мониторингом.

                                                                                  • 0

                                                                                    Какой нафиг язык для описания маршрутов? Какой клей? Не выдумывайте чего не знаете. WCF — это библиотека для написания веб-сервисов, и ничего более.

                                                                                    • 0

                                                                                      Это вопрос не ко мне. Про наличие там EIP не я придумал. Отмотайте комменты, да посмотрите.


                                                                                      @dimaaan 28 апреля 2017 в 18:40


                                                                                      Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF

                                                                                      Так вы договоритесь между собой, есть в WCF pipes, filters, или нету? Если есть — то то и есть маршруты.

                                                                                      • 0

                                                                                        Это случайное совпадение — одни и те же слова используются в разных смыслах. Тот кого вы цитируете увидел знакомые слова и сказал что это все есть.


                                                                                        Повторюсь: WCF — это библиотека для написания веб-сервисов или подключения к ним, а не платформа для их интеграции

                                                                                        • 0

                                                                                          Я совершенно не специалист в WCF, но по-моему вы как минимум упрощаете. Я видел в документации (а не в комментах) и упоминание workflow, и message filters, и много чего еще, что явно не является веб-сервисами, а именно интеграцией. Это конечно может быть случайным совпадением, но MS в явном виде упоминает в доках на WCF как EIP вообще, так и конкретные паттерны, со ссылками на их реализацию.

                                                                                          • 0

                                                                                            Workflow — это отдельная библиотека, WWF (Windows Workflow Foundation).


                                                                                            Message filters и routing в WCF действительно есть — но нет инструментов для трансформации сообщений. И никаких аналогов биндингов из вот этого списка кроме трех там тоже нет.

                                                                                  • 0

                                                                                    Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.


                                                                                    Для 22 ETL-процедур за глаза хватает одного консольного приложения с одним конфигом, нет необходимости разводить 22 отдельных проекта до тех пор, пока их разрабатывает один разработчик.


                                                                                    Запускать их можно через системный планировщик или через MS SQL Server Agent. К слову, те же джобы SSIS или Pentaho запускаются точно так же, в этом плане запуск консольного приложения ничем не отличается от того что предлагают якобы профессиональные инструменты.


                                                                                    Зато консольное приложение:


                                                                                    1. проще в отладке и настройке;
                                                                                    2. пишется на богатом на возможности статически типизируемом языке с возможностью обобщенного программирования, рефлексии и метапрограммирования;
                                                                                    3. может использовать любые библиотеки, а не те которые удалось подключить;
                                                                                    4. использует общепринятые системы ведения логов а не то что придумали вендоры;
                                                                                    5. может поддерживаться любым разработчиком, а не редким специалистом, прошедшим кучу курсов.
                                                                                    • 0
                                                                                      Что же до ETL, то постоянно они работать не должны, ETL это по определению пакетная обработка по расписанию.

                                                                                      Кто вам сказал эту чепуху? Если вы никогда не видели ETL, работающего по сообщениям скажем из MQ — это не значит, что их не бывает.

                                                                                      • 0

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

                                                                                        • 0

                                                                                          Я просто работаю над этой темой уже лет 10. Базы даных и файлы — это было когда-то. А сейчас нормальные инструменты для делания ETL предполагают и позволяют переваривать данные, приходящие в любом режиме, и откуда угодно. Информатика какая-нибудь, или тот же camel — им по большому счету все равно, сообщения это или база. Возможно это меняет смысл термина, но тем не менее — то на чем сегодня делается ETL, оно именно такое. 24/7, терабайты данных в сутки, смесь пакетных загрузок и стриминга.

                                                                                          • 0

                                                                                            Одинаковые инструменты не говорят об одинаковости задач.


                                                                                            Но да, если мне нужно будет делать онлайн-обработку сообщений, бегущих через MQ — консольное приложение для этого я писать уже не буду. Сделаю вин-сервис :-)


                                                                                            Кстати, в 22 вин-сервисах на самом деле нет ничего страшного. Но проще, конечно же, обойтись одним.

                                                                        • 0

                                                                          Не знаком с SSIS, да и с Camel тоже. Насколько я понимаю это ETL инструменты. Я лишь хотел сказать, что EIP типа Каналы сообщений, Pipes, Filters, Router, Translator, Endpoint это все тоже часть WCF, поэтому и нет проблемы.


                                                                          Насчет "OSGI — это и есть микросервисы", тогда и WCF — это тоже микросервисы. Значит опять нет проблемы.


                                                                          П.С.
                                                                          maven все же не совсем аналог msbuild. скорее аналог Ant.
                                                                          Или же maven аналог msbuild+nuget.
                                                                          А знакомство с системами сборки вообще частенько выводит из себя :)
                                                                          В maven'е куча плагинов, надо с каждым разбираться (прямо как webpack).
                                                                          В .net core конфиги msbuild похудели, так что все не так уж и плохо.

                                                                          • 0

                                                                            Я в общем слабо знаком с WCF, поэтому пожалуй в такой формулировке соглашусь с тем, что это похоже на Camel. Лучше или хуже — не знаю, по похоже очевидно.


                                                                            По вопросу микросервисов — ну тут дьявол как обычно в деталях.


                                                                            OSGI в виде реализации — это все же не одни только микросервисы, там много чего поверх уже есть. Если совсем уж просто — то на сегодня это ближе скажем к kubernetes Т.е. это еще и оркестрация кластеров микросервисов, например.


                                                                            Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо? Ни maven, ни ant, ни gradle не требуют никакой установки (как впрочем и JDK/JRE) — это просто папки.


                                                                            Тоже самое впрочем касается и проблемы зависимостей как таковых, в мире Java это как правило jar, в разных его подвидах, и некий набор соглашений, где в нем могут лежать зависимости. И он рекурсивный по сути, т.е. один jar внутри другого — ничего такого в этом нет, и обработать это тоже легко.


                                                                            То есть, я могу собрать только свои классы, запаковать обычным zip, и посмотреть потом тоже, и ресурсы положить туда же — и тоже посмотреть например far-ом. И поправить, если что. А могу собрать свои + зависимости, и сделать так называемый fat jar или uber jar — и задеплоить одним куском. Ничего близкого к этой идеологии в мире .Net мне пока не попадается.

                                                                            • 0

                                                                              Как вы запустите maven или ant из агента CI, если это "просто папка", лежащая незнамо где?


                                                                              Надо или в PATH прописать, или положить в известное место, или завести отдельную. переменную окружения, или настроить свойство в агенте...


                                                                              Хоть это все и мелочи, но в итоге получается что установить msbuild не сложнее чем maven. Хоть там и надо прокликать "далее"-"далее"-"далее" или заморачиваться с "тихой" установкой — но зато msbuild всегда лежит по известному пути.




                                                                              Для деплоя на IIS можно собрать zip-архив и задеплоить его одним куском при помощи msdeploy.


                                                                              Для деплоя на Sharepoint нужно собирать не zip, а cab.


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


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

                                                                              • 0

                                                                                Я запущу, и для этого конечно нужно знать папку. Но этих папок можно быть сколько угодно (как это обычно и бывает под Jenkins где-нибудь). Т.е. десять разных версий maven — никаких проблем не вызывает. Более того, дженкинс сам их и поставит, когда нужно. Одна версия из IDEA, другая из эклипса.


                                                                                А внутри у Weblogic (и у груви заодно) — своя версия ant. Зачем — не знаю, но есть и работает.


                                                                                Т.е. установки, как таковой, нет вообще, начиная с JDK, которую конечно тоже можно ставить из msi — а можно потом взять готовую папку и скопировать, и не будет никакой разницы (ну, почти никакой, если честно).


                                                                                при помощи msdeploy.
                                                                                А что, просто скопировать никак? Вот из таких мелочей оно все и состоит.

                                                                                А что до msi… ну я как бы прекрасно знаю, что это такое. По сравнению с форматами установок типа jar/war — это примерно также, как старый OLE формат файлов ворда, по сравнению с новым zip форматом у него же — удобство просто несравнимое.


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


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

                                                                                • 0

                                                                                  Ну, разные версии msbuild тоже в разные папки ставятся.


                                                                                  А что, просто скопировать никак? Вот из таких мелочей оно все и состоит.

                                                                                  Можно и скопировать. Но вы же сами хотели деплоить одним куском...


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

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

                                                                                  Полностью с вами согласен, я и сам считаю так же. Но поверьте — в .NET в этом плане все сделано правильно.


                                                                                  msbuild — это расширяемая система сборки, возможностей которой хватает для очень большого круга задач. А где не хватает — там можно сделать <Exec Command="..." WorkingDirectory="..." />.

                                                                                  • 0
                                                                                    Можно и скопировать.

                                                                                    А зачем тогда msdeploy? ) Тут я кстати серьезно — сталкивался ровно с тем же, когда результат работы SSIS нужно установить на хост с базой. И написано, что нужно (или можно) для этого некую утилиту. При этом кто-то из команды просто взял, и скопировал, и оно работает, что вызывает некоторые вопросы — а зачем собственно утилита-то, и что она делает кроме копирования файлов?


                                                                                    Но вы же сами хотели деплоить одним куском...

                                                                                    Я не хотел одним куском. Я хотел в зависимости от задачи.


                                                                                    Ни разу и не говорил, что она никуда не годится — это у меня с ней некоторая несовместимость. Ну скажем так — я предпочитаю несколько больший уровень контроля с моей стороны, куда и что класть. И больший уровень понимания, как оно внутри работает (при том что претензий к MSDN у меня в общем-то никогда не было, документации много, и она приличного качества — но вот подиж ты, зачастую части идеологии куда-то ускользают).

                                                                                    • 0

                                                                                      Во-первых, msdeploy умеет создавать сайты, пулы и прочее (простое копирование сделает приложение частью существующего сайта или заменит существующий сайт).


                                                                                      Во-вторых, msdeploy работает по сети и является заменой колхозу на сетевых папках.


                                                                                      Соответственно, в зависимости от задачи можно использовать msdeploy, а можно — копирование.




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




                                                                                      Ну скажем так — я предпочитаю несколько больший уровень контроля с моей стороны, куда и что класть. И больший уровень понимания, как оно внутри работает

                                                                                      Ну, если вы не понимаете чего-то конкретного, можете задать вопрос на ru.SO. Я там часто отвечаю.


                                                                                      Что же до идеологии… Я не вполне понимаю что такое идеология системы сборки но думаю, что у msbuild и ant идеология общая.

                                                                                    • 0

                                                                                      Ну. exec command — это не плагин, это бяка ) Понятно что это на клайний случай, но все равно, это какая-то фича из эпохи make, по-хорошему, команде должен передаваться проект, а не непойми что. Причем она должна понимать, как он устроен, и где что лежит.

                                                                                      • 0

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

                                                                                        • 0

                                                                                          exec я упомянул скорее как возможность сбежать с msbuild на любую другую систему сборки, поставив заглушки на цели Build, Rebuild и Clean :-)


                                                                                          Проект Visual Studio — это обычно и есть msbuild-файл. Если не использовать кривые магические надстройки для студии, то любой проект студии может быть собран msbuild, а любой файл msbuild может быть открыт студией как проект если дать ему правильное расширение и прописать правильный ProjectType.


                                                                                          Я так, кстати, часто делаю — создаю шарповый проект, удаляю из него импорт шарпового тулчейна и добавляю свои таргеты. Например, есть у меня проект, где исходниками являются jar-файлы, которые при сборке подаются на вход ikvmc...




                                                                                          Кстати, задача Exec в msbuild намного мощнее чем то же самое в make за счет языковых средств msbuild. MSBuild умеет работать со списками элементов проекта, преобразовывать их, фильтровать, группировать. Сами элементы проекта могут быть добавлены в явном виде (например, через IDE), получены сканированием директорий или получены как выходные параметры других задач.


                                                                                          Ну и ничто не мешает добавлять свои задачи, причем для этих целей есть аж три способа. Можно сделать свою сборку с задачами, можно создать задачу из C#-кода при помощи фабрики задач или же можно создать задачу из скрипта на powershell при помощи сторонней фабрики.

                                                                                    • 0
                                                                                      зато msbuild всегда лежит по известному пути.

                                                                                      Это пока у вас он один. Как только вам нужно подерживать скажем старую версию — вы приплыли.

                                                                                      • 0

                                                                                        Старая версия лежит по другому пути, не беспокойтесь.

                                                                                    • –1
                                                                                      Что же до msbuild… ну тут сложно и длинно. Например, первое что не нравится — его еще и устанавливать надо?

                                                                                      Он с .NET поставляется, в "%SystemRoot%\Microsoft.NET\Framework\" соответствующей версии.