Я вот не понимаю этой массовой истерии с выходом PowerShell под Linux. Никто не заставляет ем пользоваться и bash никто из Linux не удалит:) Все прекрасно знают зачем он вышел, что бы удобнее было админить .Net core приложения.Nu-get пакеты удобнее разворачивать сразу на 2-х ОС. Конечно, желательно, что бы 1 команда работала на Linux и Windows одинаково.
Всем спасибо, вы облегчили мой выбор :)
Просто проект большой, существуещего JS кода уже 700 000 строк, вот хочется взять что-то удобное хотя бы для рендеринга.
Я вот то же в последние пару недель столкнулся, решил выбрать для проекта хорошую библиотку для рендеринга UI(Мочи больше нет рендерить все руками на JS). Это просто зоопарк. Я попробывал React.js, React +TS, Angular.js, Angular 2, emder.js. knockout.js и прочитал еще о такой куче всего что голова кругом. И все они не совместимы и выбрать что-то одно это как хождение по миному полю.
В этом разница, что js проще контролировать, чем выполнение кода с возможностью прямого обращения к памяти. И отладить это все до надлежащего уровня будет ой как не просто.
Спасибо за объяснение.
Код компилируется более предсказуемо с точки зрения безопасности из js нежели из c++. И всяких дыр там будет хватать, ладно пока в действии не увидишь, не узнаем, но будущие туманно.
Это конечно все круто и быстро. У меня только один вопрос на сколько это будет безопасно?
Давайте так я пишу на C++ под браузер, у меня есть указатель на адрес в памяти и я могу в теории, обратится к любому участку памяти текущего процесса, я бы не считал это особо безопасным. Можно таких дел натворить.
Спасибо, инструмент уже может порадовать. В решении 1 000 000 строк кода нашел 64 варнингов первого приоритета. Для даже не беты считаю уже не плохо. Особенно удивил код в одном из старых не используемых классах:
if (this.urlBox != null)
{
while (this.testHyperLinkControl != null)
{
this.testHyperLinkControl.NavigateUrl = "javascript:TestURL('" + SPHttpUtility.EcmaScriptStringLiteralEncode(this.urlBox.ClientID) + "')";
break;
}
}
Очевидно, Go явно в этом выигрывает. Но если теперь вспомнить, какие языки выросли из старого доброго С – это С++, C#, Java — все они используют определение переменных такого типа. И они построены на парадигмах ООП и не используют (или практически не используют) передачу указателей на функции, все это нам заменили классы. Недостатки, которые выявляются у определения типа переменной слева, улетучиваются при использовании ООП.
Вы, вырвали слова из контекста и все сказано в следующих 2-х предложения.
Пока sharepoint online, предлагает, что он предлагает. Использовать его все равно не получится, слишком малый уровень возможности кастомизации.
Режим реального времени это у задача другая, и не вохможность использования в системе стандартных методов поиска отсюда и вытекает. Все недостатки понятны, я пытаюсь только сказать, что для конкретной ситуации этот выход вполне предпочтителен. Тем более в статье, основной упор делается на то как сделать новый тип поля.
1) Поддержка SharePoint Online не нужна.
2) Новых типов полей в нашем решении уже больше 10-ка, каких-там только нет. Особо больших проблем в поиске не было. Тем более решение должно работать в режиме реального времени и использование систем поиска не очень удобно.
3) Вы предлагаете при каждом сохранении элементов проверять их метаданные, зачем, если это нужно в основном только в справочных списках. Это лишняя нагрузка и она не к чему.
Мое мнение вариант с типом поля намного проще и логичнее.
Во-первых полей около десятка. Тыкают не пользователи, а внедренцы — это совсем другие люди. А внедренцу намного проще создать новое поле, и задать ему шаблон. чем всякой другой ересью заниматься, тем более еще ресивер вешать. Это не маленькое решение для одиночной задачи, а тиражное решение. Тут уже совсем другие приоритеты.
Ну как минимум для шаблонов ввода есть проблема, если его применить, программное создание элемента падает. А ресивер не подошел потому что, хотелось что пользователь сразу видел, что произошло сразу берез передачи на сервер, и на самом деле уже в продакшине у этого поле используется маска ввода.
За обзор спасибо! Много слышел о языке, и вот увидел первую ссылку и решил поробывать, за один день «Тур с заданиями по Go — это должен пройти каждый; (EN)» и практически прошел.
У меня возник только один вопрос зачем типы переменных справа. Я как человек воспитанный на C подобных языках, этого совершенно не понимаю. Может кто-нибудь из знающих подскажет сокральный смысл этой фишки.
шикарно…
Просто проект большой, существуещего JS кода уже 700 000 строк, вот хочется взять что-то удобное хотя бы для рендеринга.
Код компилируется более предсказуемо с точки зрения безопасности из js нежели из c++. И всяких дыр там будет хватать, ладно пока в действии не увидишь, не узнаем, но будущие туманно.
Давайте так я пишу на C++ под браузер, у меня есть указатель на адрес в памяти и я могу в теории, обратится к любому участку памяти текущего процесса, я бы не считал это особо безопасным. Можно таких дел натворить.
Вы, вырвали слова из контекста и все сказано в следующих 2-х предложения.
Режим реального времени это у задача другая, и не вохможность использования в системе стандартных методов поиска отсюда и вытекает. Все недостатки понятны, я пытаюсь только сказать, что для конкретной ситуации этот выход вполне предпочтителен. Тем более в статье, основной упор делается на то как сделать новый тип поля.
2) Новых типов полей в нашем решении уже больше 10-ка, каких-там только нет. Особо больших проблем в поиске не было. Тем более решение должно работать в режиме реального времени и использование систем поиска не очень удобно.
3) Вы предлагаете при каждом сохранении элементов проверять их метаданные, зачем, если это нужно в основном только в справочных списках. Это лишняя нагрузка и она не к чему.
Мое мнение вариант с типом поля намного проще и логичнее.
У меня возник только один вопрос зачем типы переменных справа. Я как человек воспитанный на C подобных языках, этого совершенно не понимаю. Может кто-нибудь из знающих подскажет сокральный смысл этой фишки.