Та же самая проблема будет, если вы не используете EditorConfig: работаешь с одним проектом — ставь глобально табы, работаешь с другим — ставь глобально пробелы.
Похоже, единственной адекватной опцией при работе с Visual Studio (в которой нет концепции локальных настроек отступов) является использование EditorConfig везде, на всех проектах. При этом «засорять» сторониие репозитории этим файлом необязательно — можно просто помещать его уровнем выше относительно *.sln. В такой конфигурации он тоже должен работать (но, честно признаюсь, я проверял довольно давно).
Ну и начиная с 2017 студии можно держать несколько её инсталляций, заточенных на разные проекты (наверное, и настройки отступов тоже будут разные). Но из-за такой мелочи держать отдельную инсталляцию Visual Studio — это, конечно, оверхед.
В таких случаях всё равно стоит создать пул (мерж)-реквест и предложить доработать его кому-нибудь другому. Было дело, я поднимал такие пул-реквесты других людей и допиливал, после чего их мержили в апстрим.
Людая работа опенсорс-сообществу может пригодиться.
Надо заметить, что out-of-source сборки, похоже, в основном используются только у разработчиков на C и C++. Я не видел ни одного проекта на C#, Java, Python или JavaScript, которые бы использовали out-of-source сборки.
Ну то есть ваш совет полезен только применительно к конкретным системам сборки и конкретным языкам.
Нет, вам ничего не потребуется дублировать: GitHub поддерживает отображение README без расширений; файл COPYING тоже поддерживается.
Вообще говоря, до недавнего времени никакой особой «поддержки» для файлов с лицензиями не было и не требовалось. Но с некоторых пор GitHub пытается анализировать эти файлы и высвечивать лицензии (если их удалось определить) на страничке репозитория.
Для CHANGELOG, NEWS и т.п. файлов никакой особенной поддержки нет. Если они у вас есть в GNU-структуре проекта — можете их просто закоммитить, и пользователи смогут эти файлы почитать.
К сожалению, с сегодняшнего дня Fedora официально нельзя использовать в Крыму.
Напоминаем, что у нас, в проекте, действует правило "Don't Ask Don't Tell", и вы не обязаны сообщать откуда вы, и как и где собираетесь использовать Fedora.
По поводу проблем с DNS — в комьюнити говорят, что это просто какие-то временные проблемы, не связанные с введением соглашения.
Отвечаю на первую половину вашего вопроса: для F# можно пробовать использовать те же ORM, что и для C#, но без поддержки discriminated unions. Вот тут есть довольно старая статья, по которой можно примерно оценить, с какими сложностями предстоит столкнуться.
А по второй половине: в F# распространена парадигма работы с БД, отличная от использования обычных ORM, к которым мы с вами привыкли по C#. Тут часто используют т.н. провайдеры типов. Вот руководство от Microsoft, которое описывает работу с FSharp.Data.TypeProviders. Есть и другие провайдеры, которые могут вас заинтересовать: SqlClient, SQLProvider.
Я думаю, что понимаю, о чём вы говорите, и поддержки такого уровня для F# пока что нет. Некий потенциал для такой поддержки на самом деле видится (как минимум, можно было бы заставить редактор генерировать ветки для pattern matching), но Idris всё-таки даёт для таких вещей намного больше возможностей благодаря куда более продвинутой системе типов.
Отвечу про F#. Я уже в течение некоторого времени решаю некоторые научные и инженерные задачи с помощью F#, и могу сказать следующее: F# мешает писать приложение неправильно, и в этом его основное преимущество.
F# мешает вам использовать мутабельные переменные (синтаксис для этого есть, но его надо вспоминать, и выглядит громоздко). F# мешает вам делать запутанную многостороннюю архитектуру в проекте благодаря линейному порядку файлов в проекте и определений внутри файла (есть синтаксис для того, чтобы сделать нелинейный порядок, но выглядит это некрасиво и его нужно вспоминать). F# мешает вам сделать у объекта несколько конструкторов, и тем самым мешает делать большие объекты, нарушающие SRP (ну вы поняли, да, синтаксис для этого есть, но вспоминать его редко когда хочется). F# мешает вам перепутать единицы измерения в физической формуле (или загнать туда неопределённые единицы) после того, как вы начинаете их использовать в программе.
Мне он напоминает мудрого наставника, который указывает мне недостатки программы ещё во время написания кода. И это очень, очень удобно.
Ну и чуть меньшее преимущество F# заключается уже в том, что он помогает писать программы в функцональном стиле, с применением операторов типа |>, композиции функций, паттерн-матчинга.
как легко (то есть без установки IDE) писать свои модули к PowerShell
Здесь принцип одинаков как для C#, так и для F#: нужны будут
сборки от целевой версии PowerShell (Windows PowerShell хранит их в GAC, а для PowerShell Core можно всё скачать из NuGet)
инструменты для сборки модулей (для Windows PowerShell, вероятно, понадобятся MSBuild и standalone-компилятор, которые можно попробовать установить без IDE вместе с VS Build Tools; для .NET Standard всё проще, потому что ставится из NuGet)
Я бы вам советовал самостоятельно попробовать написать простенький модуль на C#, а потом этот же опыт применить для разработки на F#.
Насколько я понимаю, сегодня есть рекомендация писать портабельные модули на .NET Standard, и их можно будет использовать и для старого, и для нового PowerShell. Это сильно упрощает задачу «писать модули без установки IDE», причём без привязки к языку.
Вот ещё нагуглился какой-то небольшой пост, который описывает опыт разработки модуля с .NET Core (без IDE). Опять же, повторюсь, история с F# принципиально не отличается; F# официально поддерживает .NET Core уже в течение некоторого времени.
Это утверждение не совсем точное: на самом деле F# поддерживает .NET Core (и вы можете в консоли создать и скомпилировать такой проект), а вот с инструментами (кроме Ionide) пока что не очень.
VSCode + Ionide в таком режиме работают отлично
Visual Studio пока не поддерживает, но обещали сделать в Update 3
Rider пока не поддерживает, но обещали сделать в одном из обновлений версии 2017 (т.е. в этом году)
про VS for Mac, к сожалению, не знаю
В общем, хочется верить, что это временное явление, и в будущем основные IDE будут поддерживать всё как положено.
Вопрос не такой уж и провокационный, как могло показаться. Мне действительно встречались вполне логичные рассуждения некоторых товарищей, которые полагают, что Microsoft хочет интегрировать ядро Linux в свою операционную систему, и в итоге отказаться от старого ядра (типа того, что когда-то сделали в Apple). При этом основная мотивация — это совместимость с большой массой полезного софта для разработчиков и более высокое качество кода в ядре Linux (по второму — пруфы вот: http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/).
Друзья, пожалуйста, учтите, что код по ссылке на gist не мой, а я просто его вовремя стянул с форума и выложил на всеобщее обозрение (поскольку ссылки с форума на gamedev давно протухли, это вполне полезно). Свой код я так не пишу!
Способа применить научный метод при разработке или проектировании я пока что не вижу (но буду рад, если подскажут, как можно это сделать). При анализе техзадания его неявно применяли и раньше. Например, если что-нибудь в задании непонятно — строишь гипотезу, описываешь её, и направляешь постановщику задач. В зависимости от того, подтверждает он гипотезу или нет, можно делать дальнейшие выводы о задаче.
(Задания бывают очень сложные и мутные настолько, что прямые вопросы "как должно работать то или другое" постановщику ставить бесполезно, и приходится строить вместе с ним такие вот мысленные эксперименты, чтобы понять, как должен работать софт. Вообще говоря, эта проблема может быть на корню решена с помощью DDD, но пока его внедряют не везде.)
До применения научного метода чинили баги так — тут пошаманим, там пошаманим, починилось — и славно. Теперь строим гипотезы, проверяем, строим дальнейшие, и таким образом всегда докапываемся до истины.
Объективной статистикой не владею, но субъективно могу сказать, что раньше отладка могла занимать в среднем O(n) от количества возможных действий по починке бага, а теперь O(log n).
Практическая разница не сильная (то есть не на порядок), но уверенность в результатах своих действий стала намного выше. Стало ли в действительности меньше переоткрытых багов — опять-таки, объективно сказать не могу, простите. Подобного рода статистикой не занимались.
Та же самая проблема будет, если вы не используете EditorConfig: работаешь с одним проектом — ставь глобально табы, работаешь с другим — ставь глобально пробелы.
Похоже, единственной адекватной опцией при работе с Visual Studio (в которой нет концепции локальных настроек отступов) является использование EditorConfig везде, на всех проектах. При этом «засорять» сторониие репозитории этим файлом необязательно — можно просто помещать его уровнем выше относительно
*.sln. В такой конфигурации он тоже должен работать (но, честно признаюсь, я проверял довольно давно).Ну и начиная с 2017 студии можно держать несколько её инсталляций, заточенных на разные проекты (наверное, и настройки отступов тоже будут разные). Но из-за такой мелочи держать отдельную инсталляцию Visual Studio — это, конечно, оверхед.
В таких случаях всё равно стоит создать пул (мерж)-реквест и предложить доработать его кому-нибудь другому. Было дело, я поднимал такие пул-реквесты других людей и допиливал, после чего их мержили в апстрим.
Людая работа опенсорс-сообществу может пригодиться.
Надо заметить, что out-of-source сборки, похоже, в основном используются только у разработчиков на C и C++. Я не видел ни одного проекта на C#, Java, Python или JavaScript, которые бы использовали out-of-source сборки.
Ну то есть ваш совет полезен только применительно к конкретным системам сборки и конкретным языкам.
Нет, вам ничего не потребуется дублировать: GitHub поддерживает отображение
READMEбез расширений; файлCOPYINGтоже поддерживается.Вообще говоря, до недавнего времени никакой особой «поддержки» для файлов с лицензиями не было и не требовалось. Но с некоторых пор GitHub пытается анализировать эти файлы и высвечивать лицензии (если их удалось определить) на страничке репозитория.
Для
CHANGELOG,NEWSи т.п. файлов никакой особенной поддержки нет. Если они у вас есть в GNU-структуре проекта — можете их просто закоммитить, и пользователи смогут эти файлы почитать.Вот новость на сайте Russian Fedora community: http://ru.fedoracommunity.org/posts/fedora-zapreshcheno-eksportirovat-v-krym/
По поводу проблем с DNS — в комьюнити говорят, что это просто какие-то временные проблемы, не связанные с введением соглашения.
В примере на Scala тоже показали не каррированную.
(но замечание справедливое)
Отвечаю на первую половину вашего вопроса: для F# можно пробовать использовать те же ORM, что и для C#, но без поддержки discriminated unions. Вот тут есть довольно старая статья, по которой можно примерно оценить, с какими сложностями предстоит столкнуться.
А по второй половине: в F# распространена парадигма работы с БД, отличная от использования обычных ORM, к которым мы с вами привыкли по C#. Тут часто используют т.н. провайдеры типов. Вот руководство от Microsoft, которое описывает работу с
FSharp.Data.TypeProviders. Есть и другие провайдеры, которые могут вас заинтересовать: SqlClient, SQLProvider.Выше тов. Liminiens это тоже упоминал.
Я думаю, что понимаю, о чём вы говорите, и поддержки такого уровня для F# пока что нет. Некий потенциал для такой поддержки на самом деле видится (как минимум, можно было бы заставить редактор генерировать ветки для pattern matching), но Idris всё-таки даёт для таких вещей намного больше возможностей благодаря куда более продвинутой системе типов.
По описанию звучит похоже на лекции Брагилевского, посмотреть можно на тытрубе.
упс, не сразу понял, что вопрос относится к посту уровнем выше, удалил комментарий
Было бы интересно послушать. Напишите, пожалуйста :)
Отвечу про F#. Я уже в течение некоторого времени решаю некоторые научные и инженерные задачи с помощью F#, и могу сказать следующее: F# мешает писать приложение неправильно, и в этом его основное преимущество.
F# мешает вам использовать мутабельные переменные (синтаксис для этого есть, но его надо вспоминать, и выглядит громоздко). F# мешает вам делать запутанную многостороннюю архитектуру в проекте благодаря линейному порядку файлов в проекте и определений внутри файла (есть синтаксис для того, чтобы сделать нелинейный порядок, но выглядит это некрасиво и его нужно вспоминать). F# мешает вам сделать у объекта несколько конструкторов, и тем самым мешает делать большие объекты, нарушающие SRP (ну вы поняли, да, синтаксис для этого есть, но вспоминать его редко когда хочется). F# мешает вам перепутать единицы измерения в физической формуле (или загнать туда неопределённые единицы) после того, как вы начинаете их использовать в программе.
Мне он напоминает мудрого наставника, который указывает мне недостатки программы ещё во время написания кода. И это очень, очень удобно.
Ну и чуть меньшее преимущество F# заключается уже в том, что он помогает писать программы в функцональном стиле, с применением операторов типа
|>, композиции функций, паттерн-матчинга.Здесь принцип одинаков как для C#, так и для F#: нужны будут
Я бы вам советовал самостоятельно попробовать написать простенький модуль на C#, а потом этот же опыт применить для разработки на F#.
Насколько я понимаю, сегодня есть рекомендация писать портабельные модули на .NET Standard, и их можно будет использовать и для старого, и для нового PowerShell. Это сильно упрощает задачу «писать модули без установки IDE», причём без привязки к языку.
Вот ещё нагуглился какой-то небольшой пост, который описывает опыт разработки модуля с .NET Core (без IDE). Опять же, повторюсь, история с F# принципиально не отличается; F# официально поддерживает .NET Core уже в течение некоторого времени.
Это утверждение не совсем точное: на самом деле F# поддерживает .NET Core (и вы можете в консоли создать и скомпилировать такой проект), а вот с инструментами (кроме Ionide) пока что не очень.
В общем, хочется верить, что это временное явление, и в будущем основные IDE будут поддерживать всё как положено.
Везде должно нормально работать. Это Conemu с кастомизациями, когда я сидел под семёркой — то прекрасно её поддерживало.
Мне кажется, что то же самое было бы с анонимным объектом (а-ля
new { x, y }.y()), так что это не новая грабля :)Вопрос не такой уж и провокационный, как могло показаться. Мне действительно встречались вполне логичные рассуждения некоторых товарищей, которые полагают, что Microsoft хочет интегрировать ядро Linux в свою операционную систему, и в итоге отказаться от старого ядра (типа того, что когда-то сделали в Apple). При этом основная мотивация — это совместимость с большой массой полезного софта для разработчиков и более высокое качество кода в ядре Linux (по второму — пруфы вот: http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-we-are-slower-than-other-oper/).
Друзья, пожалуйста, учтите, что код по ссылке на gist не мой, а я просто его вовремя стянул с форума и выложил на всеобщее обозрение (поскольку ссылки с форума на gamedev давно протухли, это вполне полезно). Свой код я так не пишу!
Способа применить научный метод при разработке или проектировании я пока что не вижу (но буду рад, если подскажут, как можно это сделать). При анализе техзадания его неявно применяли и раньше. Например, если что-нибудь в задании непонятно — строишь гипотезу, описываешь её, и направляешь постановщику задач. В зависимости от того, подтверждает он гипотезу или нет, можно делать дальнейшие выводы о задаче.
(Задания бывают очень сложные и мутные настолько, что прямые вопросы "как должно работать то или другое" постановщику ставить бесполезно, и приходится строить вместе с ним такие вот мысленные эксперименты, чтобы понять, как должен работать софт. Вообще говоря, эта проблема может быть на корню решена с помощью DDD, но пока его внедряют не везде.)
До применения научного метода чинили баги так — тут пошаманим, там пошаманим, починилось — и славно. Теперь строим гипотезы, проверяем, строим дальнейшие, и таким образом всегда докапываемся до истины.
Объективной статистикой не владею, но субъективно могу сказать, что раньше отладка могла занимать в среднем O(n) от количества возможных действий по починке бага, а теперь O(log n).
Практическая разница не сильная (то есть не на порядок), но уверенность в результатах своих действий стала намного выше. Стало ли в действительности меньше переоткрытых багов — опять-таки, объективно сказать не могу, простите. Подобного рода статистикой не занимались.