.NET und C# ohne Web?
Тема "поговорить".
Десктоп на Сишарпе вообще не котируется в Германии, или как?
Просто, насколько я знаю, в основном сишарп в вебе сейчас популярен. И это странно, т.к. в разных фирмах полно внутренних приложений, которые обычно пишут для десктопа или веба (внутренних корпоративных порталов).
Ещё, кто знает, как сейчас сишарп применяется для мобильных приложений? Только через прокладку-Mono?
Не хочу связываться с вебом, т.к. последний раз, когда это делал, пришлось чуть ли не бОльшую часть времени уделять фронт-энд части, которую я знаю плохо. Похоже, вместо сишарп и дотнета придётся заниматься джаваскриптом и фронтэнд-вебфреймворками, а это противоположно тому, что я хочу.
Конечно, есть очень большие конторы, где разделяют фронт и бэк разработку, если делают сайт, например - т.е. можно сделать бэк на дотнете
и фронт на джаваскрипт и ХТМЛ. Но обычно один человек пишет и то, и другое, насколько я встречал. Ещё и базы данных для этого сайта делает - ганц-фулл-стек человек-оркестр. По крайней мере, так в России распространено. Как в Германии с этим?
Наоборот встречал - десктопные и мобильные приложухи переводят на джаваскрипт-ХТМЛ через браузерную обёртку - этакий локальный сайт. Всё это жутко тормозит и жрёт в разы больше ресурсов, но по-видимому бизнес это устраивает. Т.е. отказываются от Win Forms, WPF, UWP для десктопа в пользу веб-стека. Накатывают сверху на джаваскрипт что-нибудь объектноориентированное, типа тайпскрипта, ибо иначе сделать ничего нормально нельзя. Вместо того, чтобы нормальные и предназначенные для этого технологии использовать.
Вот тут человек подобное говорит - маркетинг головного мозга у менеджеров.
Вот типичная вакансия, которую я не хочу
Кому работу? - Программирование (germany.ru)
Пачка разных языков программирования, чтоб в базах данных дока был, куча старья со времен .NET 2.0, Вижуал Студио версии минус 2-3 от текущей. И вроде вакансия для дотнетчика, а по факту больше компетенций в вебе и джаваскрипте иметь надо. Джаву ещё до кучи приделали. Несколько разных систем контроля версий.
так а зачем Вы на форуме ищете? ну вот смотрите, первое же объявление с монстра https://www.monster.de/stellenangebot/software-entwickler-...
Спасибо за пример.
Я эту тему создал просто поговорить, обменяться опытом. Может, люди статистику какую-то знают или опять же из своего опыта могут сказать.
Искать я только начинаю, а так пока курсы прохожу, которые ещё полтора месяца длиться будут.
Десктоп на Сишарпе вообще не котируется в Германии, или как?
Даже винформс еще есть, кто хочет поддерживать 15 летнего монстра - пожалуйте. Но конечно, не юниоры. 
ВПФ тоже попадается.
Так как всё постепенно переходит на веб то нечего удивляться, что полно предложений.
уделять фронт-энд части
Ну так без формочек то никуда. Или хотите только консольные приложения писать?
а это противоположно тому, что я хочу.
А можно хоть что то озвучить, просто интересно.
Ещё и базы данных для этого сайта делает
Ну и проект без базы встречается довольно редко.
Конторы с малым количеством разработчиков довольно популярны.
Устроится в большую команду будет довольно проблематично, а если получится то задачи будут из "разных частей" - что попроще.
Но даже и в этом случае студенты
такого умудряются наворотить 
Даже винформс еще есть, кто хочет поддерживать 15 летнего монстра - пожалуйте. Но конечно, не юниоры.
ВПФ тоже попадается.
Т.е. дотнет уже 5 версия есть, сишарп 9, а работать надо будет в лучшем случае с .NET 4 и C# 4?
.net - What are the correct version numbers for C#? - Stack Overflow
Учишь-учишь такой новые возможности языка, а тебе, если даже удалось устроиться, тыкают в морду багтрекер и сиди годами разбирай .NET 2.0.
А можно хоть что то озвучить, просто интересно.
Я пробовал десктоп (вин формы, ВПФ, даже UWP начинал), АСП.НЕТ МВЦ (там и столкнулся с джаваскриптом, но немного), немного WCF, инсталляторы делал на разных технологиях (инно сэтап, инстол шилд, последнее - WiX и WiX#), всякое общение с платами сбора данных делал через TCP, боролся с недостаточной производительностью графики в WPF. До этого пытался сделать 3Д игру на ВПФ - понял, что не подходит (там комменты к видео). Да и когда захотел сделать прозрачность - оказалось, нужна ручная сортировка треугольников (хех, нашёл свой старый аккаунт на стекеоверфлоу). Сейчас Unity3D ковыряю, пока на курсы немецкого хожу. Мне почти всё подойдёт, кроме веб-фронтэнда. Я не хочу связываться с джаваскриптом - это не нормальный язык. Или это язык не для нормальной разработки.
Кстати, насколько я знаю, в некоторых конторах принципиально не берут на работу, если кандидат отзывается о каком-то языке плохо. Мол, все одинаково полезны, мало ли что когда-нибудь пригодится, и вообще, нам не нужны принципиальные. Мне-то пофиг, кому что нравится, мне не нравится, когда дотнетчику говорят, а попиши ка ты на джаваскрипте. Т.е. нанимают дотнетчика на вакансию дотнетчика, а надо бодаться с веб-фронтэндом и его заморочками.
Ну и проект без базы встречается довольно редко.
Я понимаю, что редко. Я говорю, что бывает, что у фирмы есть заточенные на конкретные задачи люди, а бывает, что все должны всех смочь подменить и во всех областях разбираться. Фулл стек, начиная с джуниора.
Но даже и в этом случае студенты такого умудряются наворотить
Странно. Даже многоступенчатые интервью, отличный немецкий и английский, знание алгоритмов, немецкий ВУЗ за плечами, кучка рекомендаций и прочий фарш в требованиях на вход не помогают?
Учишь-учишь такой новые возможности языка
Совершенно зря. До сих пор 2017 студия во многих местах.
Производство не гонится за последними новациями. Есть проги начатые и в 2000 году. Сам такую видел на С++. Или винформс с 2006.
сиди годами разбирай .NET 2.0.
Это уж тяжело будет найти, скорее 4.6.1
и прочий фарш в требованиях на вход не помогают?
Ничего кроме опыта не поможет, но на это он и есть студент. Задача заключается в том чтобы дать ему ентот опыт.
не помогают?
------
Нее, не помогают.
Даже наличие отличных оценок в УНИ и превосходные рекомендации - не помогают.
Учишь-учишь такой новые возможности языка
-----
Ну да - у кодера другого пути нет.
Я вот, например, новые возможности не "учу-учу", а сопоставляю с тем что включено в парадигму и как реализовано в других языках.
Реально нового, чего ранее нигде не было имплементировано - его настолько мало что осваивается в считанные часы.
И это при том, что меня обучали более 30 лет назад - никакой современной хрени и близко не было - Бейсик, Фортран, JCL...
Учишь-учишь такой новые возможности языка
-----
Ну да - у кодера другого пути нет.
Я вот, например, новые возможности не "учу-учу", а сопоставляю с тем что включено в парадигму и как реализовано в других языках.
Реально нового, чего ранее нигде не было имплементировано - его настолько мало что осваивается в считанные часы.
И это при том, что меня обучали более 30 лет назад - никакой современной хрени и близко не было - Бейсик, Фортран, JCL...
Берёшь код сишарпа версии 6 от 2015 года и написанный с широким применением нововведений из версии хотя бы 4.8 из 2019 года - и охреневаешь от кучи нового синтаксиса. С одной стороны, это просто сахар - раньше приходилось простыни выписывать и отдельные методы и классы громоздить, а сейчас юзаешь одно-двух-строчные новые возможности. Но это ведь всё изучить надо.
Вот для сравнения список нововведений в версии 7.х What's New in C# 7.0 - C# Guide | Microsoft Docs . Там слева оглавление, где и для 8 есть.
Как я понял, теперь возврат кортежей из метода полностью заменяет out-параметры? Не нужно городить предварительные определения будущих результатов, потом передавать их как аут-параметры?
тьфу, я думала что таки учишься программировать. Твой В2 никому не интересен
Кто меня возьмёт без бумажки с В2? Тут с В1 бевербуешься, а тебе тупо не отвечают. Надо напомнить им, может потеряли моё письмо...
А вообще, это нормально, что не отвечают на почту (электронную)? Ну пусть я для них хоть таджик, ну написали бы "вы нам не подходите". А так просто молчок. Сидел, изучал их сайт - "мы дружная команда" (там ещё bunt было) и всё такое - ну и где тут freundschaft, если даже разговаривать не хотят?
Кто меня возьмёт без бумажки с В2?
Имхо не надо посылать бумажку о уровне языка. Потому что с одной стороны как бы само собой разумеется, что потенциальный работник умеет общаться. С другой стороны в бевербунге есть раздел скиллы, там можно вписать уровень языка, но не шифром, а "in Wort und Schrift".
Или в бевербунге в аншреибен дописать типа "любые необходимые документы предоставлю по первому требованию".
Упс, уже написали. Сорры, пропустиl
Как я понял, теперь возврат кортежей из метода полностью заменяет out-параметры?
Как по-мне, кортежи в первую очередь с точки зрения читабельности кода не самая удобная штука. out-параметры гораздо удобнее. Хотя еще удобнее было бы просто сделать возврат класса/интерфейса с одними геттерами :)
Ты там в резЮме вообще не пиши эти смешные буквы В1 и В2. Пусть сами выясняют твой уровень по телефону. Просто тупо пиши "знаю немецкий". И да, убери про знание таджикского.
Wirklich?.. Nein. WIRKLICH??
(чего картинки из буфера не вставляются? во время редактирования вставляются, а после отправки поста - исчезают)
Как по-мне, кортежи в первую очередь с точки зрения читабельности кода не самая удобная штука. out-параметры гораздо удобнее. Хотя еще удобнее было бы просто сделать возврат класса/интерфейса с одними геттерами :)
Почему не удобно? Даже в версии 7.3 языка уже можно давать осмысленные имена элементам кортежа. В примере ниже при выводе в консоль res.sum и res.count подсвечиваются IntelliSense (тут и код нормально не вставляется). Хреново видно, т.к. разметки для кода нет, но и так понятно - возврат из метода кортежа с осмысленными названиями полей, результат возврата - тоже кортеж с осмысленными названиями, интеллисенс сразу всё подхватывает и подсвечивает. Возиться с предварительным объявлением аут-параметров не надо, классы объявлять не надо. Вобщем, очень похоже на анонимные типы, только тут неявный кортеж (без явного объявления Tuple). В теле метода специально назвал переменные с единичкой в конце, чтобы показать, что имена возвращаемых полей кортежа определяются в возврате метода.
public static (int sum, int count) SumNumbers(IEnumerable<int> sequence)
{
int sum1 = 0;
int count1 = 0;
foreach (var value in sequence)
{
sum1 += value;
count1++;
}
return (sum1, count1);
}
static void Main(string[] args)
{
var res = SumNumbers(Enumerable.Range(1, 5));
Console.WriteLine($"Sum: {res.sum}, Count: {res.count}");
}
Но это ведь всё изучить надо.
-----
Что именно надо изучатъ?
Что там есть такого нового, что не входит в парадигму ООП и что не было имплементированно в других языках?
Ну наберется там с 5-10 страниц описания новинок. И это должно стоить того чтобы говорить - "там столько надо учить-учить"?
Или может надо было в "школе" научится эффективно (само)обучатся?
заменяет out-параметры?
-----
А то, что наличие оут-параметров нарушало школьное определение функции тебе не мешало?
В вопросе возврата чего-то из функции меня больше интересует где будет размещен результат - куча? стек? - область его видимости и время существования. А вернуть можно хоть структуру, хоть массив объектов - с этим проблем не было со времен Пуре Си...
я Вам уже говорил когда-то: рассылайтесь веерно и не ждите окончания обучения, за ними начнутся другие курсы, а потом ещё одни
Вы когда начнёте работать, увидите, каких дятлов тут иногда за кодеров держат и будет обидно за упущенное время
Да вроде как Я такого не говорил
А я имел в виду именно это - было одно, стало другое 
. А лучше или хуже out параметры это уже вопрос конкретного использования, причем не имеющий никакой связи с тем что я хотел сказать.
Ну а любители кортежей могут попробовать написать получше хотя бы это
if(int.TryParse(strData, out int age))
{
Console.WriteLine($"Age:{age}");
}
А зачем тут кортеж? Я бы не булеан возвращал а прочитанный инт. Не можешь прочитать - кидай эксепшен.
Именно так ведет себя int.Parse (), а int.TryParse() как раз не должен кидать исключений (как и любая другая функция, имя которой начинается с Try)
Но с кортежем это не будет выглядеть лучше :)
знаете, что происходит в виуал студии при отладке и ожившим эксепшен?
Нет, не знаю. Но меня это не волнует. Допустим мелкософт не в состоянии состряпать дебаггер работающий с исключениями. Это что, повод от них отказываться?
то надо было микрософту сказать лет х этак назад
Мелкомягких надо было душить в колыбели, да.
Но если исключение нам не надо, то надо для начала решить где мы и как вообще программируем. В ОО? Тогда что-то вроде OptionalInt возвращаем. В функциональном? Конечно кортеж.
В дурной поделке в которой намешано всё что можно и сверху бантик? Придумываем очередную ерунду для аргументов, бесспорно, ref нам было мало.
P.S. Кстати, вспомнил, в Шарпе есть и подобие union type - OneOf. Можно возвращать OneOf<int, string> или int или строку с ошибкой.
Вместе с тем - есть нуллабле типы - не можешь - верни нулл и не парься..
Это разные вещи. Эксэпшион означает - я должен считать, но не могу. Поэтому обрываю работу в виду невозможности продолжения. Возврат наля означает - а я могу, у меня все в порядке, посмотрите, какую интересную фигню я вам насчитал.
Сорри, представьте, что вы рассказываете папуасу о машинах. Мерседес это как БМВ, а предком у всех был порше 
Я не шарповед, я явист. Вы мне по возможности на пальцах обьясните, вот такая классная фича, вот что можно с ней удобнее делать. В противовес массив как аргумент функции. Для чего нужна еще одна сущность, если есть массивы?
-----
https://www.geeksforgeeks.org/difference-between-ref-and-o...
2 и 4 в табличке внизу.
Чем кортеж отличается от массива?
-----
Массив, обычно, однотипен.
А у кортежа не факт что есть индексер.
А вообще - не требовлось пока до кортежей подниматься.
чем отличается out от ref
out - используется исключительно для возврата значения
ref - это входное и возвращаемое значение
что такое кортеж?
контейнер объектов. Считай, что это класс к вотором есть только геттеры.
Чем кортеж отличается от массива?
1) кортеж может хранить объекты разных типов
2) у кортежа нет итератора и нет доступа по индексу
3) кортеж хранит фиксированное (и заранее известное) количество полей
Короче говоря, если тебе надо чтобы функция возвращала больше одного значения - кортеж хорошее решение. С другой стороны, использование кортежей (aka необходимость возвращать несколько значений) оправдано практически никогда, так что говорит скорее о плохом дизайне :)
на пальцах обьясните
------
out -
ты не можешь передать значение в метод, но обязан в методе присвоить значение
ref -
ты обязан инициировать переменную и значение передается в метод, по выходе изменения в переменной переписываются в исходную переменную.
не помню содается ли копия или будут состязания.
у меня все в порядке
-----
У тебя и так все в порядке - в трай-методе ты используешь оут-параметер чтобы вернуть значение и возвращаемое значение чтобы сказать можно ли использовать возвращенное.
При возврате нулабельного типа ты получаешь оба куска информации упакованными в переменную нуллабле типа. Оут-параметер не нужен.
А эксептиона в трай-методах у нас нет.
Возврат наля означает
-----
именно возврат нулла. Не более.
Какой смысл туда вложен = зависит от программиста.
оправдано практически никогда, так что говорит скорее о плохом дизайне :)
Сказал, как отрезал.
навскидку: вот нужна мне функция, которая выдаёт корни квадрантного уравнения
Или функция, которая выдаёт немецкую календарную неделю: kw, year переданной даты.
У тебя нет ехцептионов в трай-методах. См выше.
Просто в Try- методах эксепшены обрабатываются. Собственно говоря, вопрос в том, что является ошибкой. В зависимости от задачи невозможность распарсить значение может быть как ошибкой, так и штатной ситуацией.
навскидку: вот нужна мне функция, которая выдаёт корни квадрантного уравнения
Ну очевидно, я бы сказал, что возврат IEnumerable был бы лучше, т.к. можно было бы объявить общий интерфейс для квадратного уравнения, кубического, уровнения любой степени, дифференциального уравнения, системы уравнений итд. В случае с кортежем такой гибкости нет.
Или функция, которая выдаёт немецкую календарную неделю: kw, year переданной даты.
Не совсем понял, что ты тут предлагаешь и зачем такая функция может понадобиться, когда есть DateTime, а расчет KW можно прикрутить exstension методом. Собственно говоря, решение вычислась две разных задачи в одной функции - не самое лучше решения с точки зрения дизайна ;)
Просто в Try- методах эксепшены обрабатываются.
-----
Какая разница что и как там внутри? Нет выброса исключений из функции и точка.
Собственно говоря, вопрос в том, что является ошибкой.
------
Не вопрос.
Вопросом было наличие реф/оут параметра.
В зависимости от задачи невозможность распарсить значение может быть как ошибкой, так и штатной ситуацией.
-----
Ну и?
int? parsedValue = int.Parse(myString);
надо тебе проверить как распарсилось - проверяй
if(!parsedValue.HasData) { /*obrabotka oshibki */}
Зачем городить кучу хрени со сложностями?
Какая разница что и как там внутри? Нет выброса исключений из функции и точка.
Разница в том, что считать ошибкой. В случае ошибки функция должна выбрасывать исключение. Если в случае ошибки функция возвращает null, то нельзя сказать, является ли null нештатной ситуацией.
if(!parsedValue.HasData) { /*obrabotka oshibki */}
Зачем городить кучу хрени со сложностями?
Все это мило, но код превратится во что-то слабо читаемое, если тебе надо будет распарсить десяток строк:
Сравни твой вариант:
int? parsedValue = int.Parse (strVal1); if(!parsedValue.HasData) return null; someObject.Val1 = parsedValue.Value; parsedValue = int.Parse (strVal2); if(!parsedValue.HasData) return null; someObject.Val2 = parsedValue.Value; parsedValue = int.Parse (strVal3); if(!parsedValue.HasData) return null; someObject.Val3 = parsedValue.Value; parsedValue = int.Parse (strVal4); if(!parsedValue.HasData) return null; someObject.Val4 = parsedValue.Value; parsedValue = int.Parse (strVal5); if(!parsedValue.HasData) return null; someObject.Val5 = parsedValue.Value; return someObject;
и вариант с исключением:
try
{
someObject.Val1 = int.Parse(strVal1);
someObject.Val2 = int.Parse(strVal2);
someObject.Val3 = int.Parse(strVal3);
someObject.Val4 = int.Parse(strVal4);
someObject.Val5 = int.Parse(strVal5);
return someObject;
}
catch (Exception ex)
{
logger.Error ("Can't parse value", ex);
return null;
}
честно говоря, за твой вариант с nullable int'ом отрывать руки. ИМХО :)
Exception - это ошибка
Ну скажем не ошибка, а нерабочее состояние. Состояние, в котором продолжение работы невозможно. Я проверил входные параметры и установил, что с такими параметрами считать невозможно. Я еще не сделал ошибку, не влез в расчеты. Это стратегия обработки исключительного состояния, которая позволяет обрабатывать такое состояние сразу, ценрализованно и не тащитьсообщение о нерабочем состоянии через весь стек обратно.
А то, что наличие оут-параметров нарушало школьное определение функции тебе не мешало?
Да мне пофиг на мхом поросшие определения функции. Кому надо, пусть возвращает из функции всегда только одно значение, городит для этого спецкласс и думает, что хороший мальчик и остался в той же парадигме, хотя на самом деле просто прикрыл фиговым листочком свои текущие как мартовская кошка абстракции. Тем более, что в шарпе не функции, а методы. А народу надо уже много лет возвращать несколько параметров за раз, а аут-параметры были неудобным костылём. Возврат кортежа удобнее. Может, можно и ещё улучшить, но и это уже прогресс.
В вопросе возврата чего-то из функции меня больше интересует где будет размещен результат - куча? стек?
Если программист должен постоянно задумываться о куче и стеке, когда что-то из метода возвращает, он просто напрасно тратит время и забивает голову. Языки высокого уровня были придуманы, чтобы больше времени уделять задачам, а не деталям реализации самого языка. Кому охота постоянно так задумываться и двигать битики ручками, экономя такты процессора - добро пожаловать в плюсы и чистый Си. Узкие участки оптимизируются вплоть до ассемблера, но только узкие, а не на каждый возврат из функции заморачиваться.
Хотя еще удобнее было бы просто сделать возврат класса/интерфейса
-----
Ну так нормальные прогеры так и писали.
Так писали хорошие мальчики, чтобы их не заругали, что они отступают от парадигм седобородых дядечек. Хотя на самом деле они просто городили спагетти-костыли.
Про именованные не знал. Так это конечно удобно. Но работает начиная с .Net 4.7.
С 17 года работает - каменный век по меркам веба (в котором каждый год рождается один и умирает другой фреймворк, который родился 3-4 года назад).
.net - What are the correct version numbers for C#? - Stack Overflow
я Вам уже говорил когда-то: рассылайтесь веерно и не ждите окончания обучения, за ними начнутся другие курсы, а потом ещё одни
Вы когда начнёте работать, увидите, каких дятлов тут иногда за кодеров держат и будет обидно за упущенное время
Я уже начал.
Дятлы везде есть. Я тоже в некотором смысле дятел. Я на интервью всегда заваливался, когда выдавали список из подобных вопросов
Каверзные вопросы по C# / Habr
Там народ в комментах тоже признаётся, что далеко не всё ответить может, хотя все при работе и деньгах. Приводил в пример видос, где сеньор тоже на некоторые подобные вопросы не отвечает - они там поржали над этим и сеньор пошёл дальше получать свою сеньорскую зарплату. А проваливший собес джун пошёл дальше рассылать веером бевербунги.
Я не знаю как оно там в вебе, а у меня на работе среда разработки Visual Studio 2015 и .Net 4.0. И переход на более новую версию дот нета максимально оттягивается.
Да и вообще, в реальной жизни приходится больше работать с легаси кодом, чем писать что-то новое.
TСircumference circumference = TCalculator.CalculateCircle(circle);
Эмм, интерфейс принимает данные? У нас, вроде, по всем шаблонам и абстракциям интерфейс не должен данные описывать? Тут лучше абстракный базовый тип подошёл бы
Эмм, интерфейс принимает данные
Если я правильно понимаю, то возвращается не интерфэйс, а обьект конкретного класса, имплементирующегo этот интерфэйс. Разница в том, что интерфэйс это соглашение о использовании. И, допустим в этом интерфэйсе декларированы геттеры, возвращающие что то. Что конкретно они возвращают - за это отвечает конкретный класс. А интерфейс только гарантирует нам, что они есть.
if(int.TryParse(strData, out int age))
{
Console.WriteLine($"Age:{age}");
}У вас пропущено объявление age. В реальности оно выглядит так
int age = 0;
if(int.TryParse(strData, out int age))
{
Console.WriteLine($"Age:{age}");
}Мой вариант с методом Parse (буде такой существовал), который returns "bool parsed" and "int age", when parsing was successful. А помещать сложные выражения во всяких проверках, типа if, for и т.д. всегда было плохой практикой.
var parseRes = int.Parse(strData); // returns "bool parsed" and "int age", when parsing was successful
if(parseRes.parsed)
{
Console.WriteLine($"Age:{parseRes.age}");
}Не можешь прочитать - кидай эксепшен.
-----
Кидай эксептион, лови эксептион, обрабатывай эксептион...
Можно, но меньше кода не станет.
Вместе с тем - есть нуллабле типы - не можешь - верни нулл и не парься...
Это известная проблема.
Ты проверяешь данные в коде в разных условных операторах и свичах, ты кидаешь эксепшен при неправильным данным и обрабатываешь эксепшен (это второй уровень проверок), ты пишешь юнит тесты (это третий уровень проверок)... А кто будет проверять юнит тесты? Существуют ли тесты для юнит тестов?
но код превратится во что-то слабо читаемое, если тебе надо будет распарсить десяток строк
-----
Правда? А если написать нормально?
someObject.Val1 = int.Parse(strVal1); someObject.Val2 = int.Parse(strVal2); someObject.Val3 = int.Parse(strVal3); someObject.Val4 = int.Parse(strVal4); someObject.Val5 = int.Parse(strVal5); if(!someObject.HasAllValues) logger.Error ("Can't parse value");
Думаю, что с трай-версиями ты сам все напишешь и порадуешся.
В случае ошибки функция должна выбрасывать исключение.
-----
Не должна, а может.
А может и не выбрасывать. Есть еще по крайней мере пара способов сообщить об ошибке.
Если в случае ошибки функция возвращает null, то нельзя сказать, является ли null нештатной ситуацией.
-----
Ты пытаешься сказать что int?.HasValue
не дает тебе достаточно информации чтобы понять было значение получено и присвоено или это не получилось?
Самому не смешно?
Мой вариант с методом Parse (буде такой существовал), который returns "bool parsed" and "int age", when parsing was successful.
Ну только "age" - слишком специализированное название. Ты же не будешь писать кажный раз новую имплементацию int.Parse(), когда тебе надо будет получить порядковый номер, количество знаков, количество детей итд
А в остальном, возможно когда-нибудь MS и добавит такую функцию и .Net. Но будь уверен, что в ближайшее десятилетие вариант с out никуда не уйдет.
А то будет проверять юнит тесты? Существуют ли тесты для юнит тестов?
Юнит-тест это метод, который проверяет условия. Мы что то делаем, потом проверяем результат сделанного. Цель - проверить написанный КОД. Юниттесты проверять не надо. Они испольняются каждай раз на бильдсервере и гарантируют соответствие кода определенным критериям. Не правильности кода, а именно соответствии критериям, установленным автором тестов.
ты кидаешь эксепшен при неправильным данным и обрабатываешь эксепшен (это второй уровень проверок)
Это не проверка КОДА. Это проверка данных. И не только данных. Так что это не второй уровень, это совсем другой уровень. Программа обрабатывает данные и иногда не может этого сделать. Это и есть исключительная ситуациq
Правда? А если написать нормально?
Это ты называешь нормально? :) За такое "нормально" тоже надо отрывать руки :)
Т.е. мало того, что ты поменял типы данных у стороннего объекта с int на int?, так ты еще добавил дополнительный геттер туда, где он нахрен не нужен. И все этот огород из-за того, чтобы ты не любешь исключения :D
Есть еще по крайней мере пара способов сообщить об ошибке.
Ага, вернуть номер ошибки как всатые добрые 70-е :)
Ты пытаешься сказать что int?.HasValue
не дает тебе достаточно информации чтобы понять было значение получено и присвоено или это не получилось?
Самому не смешно?
Не смешно. Особенно, когда ты рассказываешь, что пишешь софт для производства. int.Parse кидает не только FormatException. Если у тебя входная строка null (а ты, я вижу любишь возвращать null'ы), то твой подход просто проглотит исключение и будешь ты долго и упорно искать причину проблемы, которая лежит за пределами int.Parse
Правда? А если написать нормально?
someObject.Val1 = int.Parse(strVal1);
someObject.Val2 = int.Parse(strVal2);
someObject.Val3 = int.Parse(strVal3);
someObject.Val4 = int.Parse(strVal4);
someObject.Val5 = int.Parse(strVal5);
if(!someObject.HasAllValues)
logger.Error ("Can't parse value");Имхо здесь 2 возможные проблемы. В примере независимые вызовы. Если же последующие вызовы зависят от результата предыдущих, то необходимо перед каждым вызовом ставить проверку и обработку возможных проблем. И кроме того, если одна функция не прошла, возможно нет смысл прогонять остальные. Ну и кроме того обработку исключительного состояния можно организовать на любом уровне стека. А так придется тащить HasAllValues еще куда-то,
поменял типы данных у стороннего объекта
------
Я просто скопипастил твой код - ленивый Я, лениво писать тип в каждой строке.
чтобы ты не любешь исключения
-----
Над мал-мал на рЮсская языка переводить...
Что до исключенй - когда надо - пользуюсь. Но - да - предпочитаю код где они не нужны. не не используются, а не нужны.
твой подход просто проглотит исключение
-----
Как можно проглотить то чего нету?
Ну посмотри на это сбоку.
Есть метод bool TryParse(string source, out int val)
Предлагается замена int? Parse(string source)
Все тоже самое только bool и int упакованы в int?
Никаких других преимуществ или проблем - нету. Просто нету. неоткуда им там появится.
а чем отличается out от ref
если имеем ин параметры и оут параметры, то реф совмещении обоих.
Вот типа псевдокода
void abc(int [in] a) { print(a);}
void abc(int [out] out a) { a= 3;}
void abc(int [ref] ref a) { print(a); a= 3;}
оут параметр выдается наружу и присваивается исключительно внутри функции.
реф может инициализироваться вне функции
Тебе сразу показывается проблемное место.
не нужно забывать что действие может быть ошибочным, а может быть "неверным".
Ну вот есть у меня файл с данными на 1000 строк, строки могут содержать ошибочные данные, но в любом случае мне нужно прочитать весь файл.
Что будет делать с сотней исключений? Радоваться что нас бросило в место исключения? Скорее скажем, что проигнорировать. Не зная, что в другом месте это уже будет ошибкой
Если же последующие вызовы зависят от результата предыдущих
-----
У Parse()? Нее, точно не зависят.
Может зависеть состояние сомеОбект, но его не рассматриваем.
Потому как если станем рассматривать, то код поменяется на присвоение строки проперти (через прокси-класс) и парсинг спрячется внутри.
возможно нет смысл прогонять остальные
-----
Азы - проход должен выявить максимум проблем в исходных данных.
Т.е. парсить надо каждое значение и сообщать надо об каждой ошибке в данных.
тащить HasAllValues еще куда-то
-----
ООП говорит что ничего никуда тащить не надо - надо получить из объекта точное описание проблемы и скинуть полученное в лог.
Не написал потому как ленивый... да и не эта проблема рассматривается.
не нужно забывать что действие может быть ошибочным, а может быть "неверным".
Нет. Надо рассматривать встзречу определенного состояния, как такого, когда можно и нужно продолжать работу и когда работу продолжать нельзя. Потому что ИСКЛЮЧИТЕЛьНАЯ ситуация. Если файл нужно дочитать до конца, то выбрасывать исключение нет смысла - "ошибочные" данные это на самом деле не ошибочные, а такие, которые мы обрабатываем иначе и идем дальше.
Я просто скопипастил твой код - ленивый Я, лениво писать тип в каждой строке.
А ты не поленись и напиши. И тогда ты поймешь, что ты поменял типы данных в стороннем объекте.
Над мал-мал на рЮсская языка переводить...
чья бы корова мычала :)
ленивый Я, лениво писать тип в каждой строке.
Как можно проглотить то чего нету?
Его нету из-за того, что оно проглочено. Или ты думаешь, что TryParse имплементированно не через Parse? 
Ну посмотри на это сбоку.Есть метод bool TryParse(string source, out int val)Предлагается замена int? Parse(string source)Все тоже самое только bool и int упакованы в int?Никаких других преимуществ или проблем - нету. Просто нету. неоткуда им там появится.
Ну во-первых, подозреваю, что out появилось раньше, чем int?.
Во-вторых, разница в том, что в одном случае используются примитивы, а в другом контейнер.
Ну и в-третьих, разница в семантике. В одном случае проверка на "удалось ли распарсить", а в другом "удалось ли записать значение в переменную".
Что будет делать с сотней исключений?
-----
Разве это проблема? Это фигня, а не проблема.
Реальная проблема - либо надо тру-катчить каждый парсе, что даст ооочень приятный код, либо не будут отловлены все непарсимые данные и тогда будет реальная проблемa...
Мелкомягких надо было душить в колыбели, да.
Вы просто завидуете их успеху. ))))
Корявая оракловская джава лучше? Может Линукс, которому, чтобы им пользоваться, нужно посвятить жизнь? Или язык для старичков С++? Старички гордятся, что когда-то в 90-х, когда они были молодыми, оседлали тренд и теперь сидят на нём безвылазно, а никто из молодых нормально больше к ним войти не способен, и стараются сделать так, чтобы в будущем это только закрепилось - наваливают в него ещё сложностей. Ну или джаваскрипт - как из простого языка для двигания кнопочек по страничке и переключения переключателей попытаться сделать звездолёт на все случаи жизни. До сих пор пытаются - уже почти четверть века.
У Parse()? Нее, точно не зависят.
Ну мы жздесь не конкретно Parse обсуждаем. Мы говорим о обработке исключительного состояния и о том, что лучше - усключение или null
Азы - проход должен выявить максимум проблем в исходных данных.Т.е. парсить надо каждое значение и сообщать надо об каждой ошибке в данных.
Нет. Это условие зависит от задачи. Мы имеем сотню вложенных или вызываемых одна за другой функций, которые зависят друг от друга. Первая не смогла отработать и вернула неправильный результат. Можно подождать пару часов, пока отработают остальные. Результат будет одним и тем же - невозможно обработать данные.
Это не обязательно маска графической оболочки, где нужно отметить все незаполненные поля. Это может быть и импорт, где уже первая строка показывает, что формат файла неправильный.
ООП говорит что ничего никуда тащить не надо - надо получить из объекта точное описание проблемы и скинуть полученное в лог.
Лог к программе не относится, это средство для протоколирования, ООП такое не говорит и говорить не может. Обработка ошибок это не только сообщение о них юзеру, но и вyбор стратегии - а что проге делать дальше.
Мелкомягких надо было душить в колыбели, да.
Без мелокомягких мы бы имели сейчас пачку непохожих друг на друга линукс дистрибутивов, воевавших между собой за аудиторию, предлагающих каждый свой подход к написанию приложений, в которых "стандартный" С++ работал бы по-разному (следствие войны ОС - как сейчас в браузерах каждый гнёт веб-стандарты под себя и старается что-то нестандартное ввести), и убогие мобильные системы, пытающиеся выдать себя за десктопные со своими "мобилками с подключаемыми мониторами", где на твои 32-50 дюймов (у кого какие мониторы) тебе вываливают матрицу 4х5 кнопок размером с мой кулак и ни в чём себе не отказывай.
подозреваю
-----
Не подозревай - нуллабельные типы были раньше.
Не встроенные, но сторонние.
Сути это не меняет.
Или ты думаешь, что TryParse имплементированно не через Parse?
------
А для меня есть хоть какая-то разница как оно имплементировано?
В одном случае проверка на "удалось ли распарсить", а в другом "удалось ли записать значение в переменную".
-----
Гыыы?!!!
Никакой разницы.
Ну разве что результат попытки упакован со значением и проверку можно производить в удобное время.
Или ты хочешь сделать так
bool res1 = int.TryParse(myStr1, out int val1);bool res2 = int.TryParse(myStr2, out int val2);
bool res3 = int.TryParse(myStr3, out int val3);
и т.д.
и сказать что это правильно?
P.S. Кстати, вспомнил, в Шарпе есть и подобие union type - OneOf. Можно возвращать OneOf<int, string> или int или строку с ошибкой.
Это уже что-то типа кастомных вые...онов, монад и прочее сектантство-культизм.
Тогда что-то вроде OptionalInt возвращаем.
int?
Джентельмены, я не сишник, а чем отличается out от ref и что такое кортеж? Чем кортеж отличается от массива?
В шарпе кортеж это набор разнотипных данных. По сути просто класс с полями, но который не специально создаёшь, а чтобы по месту, обычно в контексте одной функции, что-то быстро вернуть-отправить. В шарпе есть ещё один костыль для этого - анонимные типы. И ещё более высокоуровневый костыль - DTO - Data Transfer Object - но то не только в шарпе. Хорошо было бы, если бы это всё заменили чем-то одним.
В противовес массив как аргумент функции. Для чего нужна еще одна сущность, если есть массивы?
Проблема та же, что и с аут параметрами - нужно предварительно объявить, зачастую инициализировать бесполезным начальным значением, а только потом использовать. Т.е. нужно писать кучу ненужного кода, потому что язык такой - костыли.
Я серьезно. Не пиши этих букв. Просто "gut" или "Sehr gut" или "Verhandlungssicher".
Эти буквы нужны, если сертификат попросят. Мне говорили, что если тебя подозревают даже, что ты не носитель языка, то требуют сертификат (типа им тоже нужно формально отбрехаться - а конкретные буквы и сертификаты им в этом помогают). С другой стороны, ты сразу показываешь, что ты "таджик понаехавший". Впрочем, если чел не идиот, то и "гут" и "зер гут" тоже показывают, что ты "таджик".
чем отличается out от ref-----
https://www.geeksforgeeks.org/difference-between-ref-and-o...
2 и 4 в табличке внизу.
Там можно копать и копать. Например, а можно ли ссылочный тип передать по ссылке и зачем это делать. На собесах любят копать, особенно если вопрошающий сам недавно это узнал и специально проштудировал, чтобы такими вопросами валить кандидатов. ))
Это уже не принципиально. Важно то что есть ситуации
Встреча определенного состояния - это и есть ситуация. Таким образом собственное исключение выбрасывается тогда, когда в этой определенной ситуации нет смысла продолжать выполнять задание дальше. Задание прочитать файл построчно и подсчитать количество ошибок. Если это неправильный файл, совсем, не тот формат, тут нечего считать. Мы не можем в принципе работать с этом файлом. Тут эксцепшион. А вот конкретные места файла, которые нам не нравятся, можно и нужно считать без ексцепшиона
Короче говоря, если тебе надо чтобы функция возвращала больше одного значения - кортеж хорошее решение. С другой стороны, использование кортежей (aka необходимость возвращать несколько значений) оправдано практически никогда, так что говорит скорее о плохом дизайне :)
Ни одному правилу не нужно следовать всегда и везде. А то некоторые сектанты заставляют писать развесистые деревья из вызывающих друг друга функций, чтобы только удовлетворить мантре, что функция возвращает только одно значение. Вместо того, чтобы написать курц и шнелль одну функцию с возвратом кортежа.
Примером тому goto, о котором легенды аж слагают, какой он плохой и всё такое - никогда не используйте... но есть мол пара случаев, когда он подходит. Бугага, оператор, который подходит под пару редких случаев - ради этого мы тащим его из
языка в язык уже полвека.
Не подозревай - нуллабельные типы были раньше.
Не встроенные, но сторонние.
Сути это не меняет.
Это кардинально меняет суть. int.TryParse - часть фреймворка, если во фреймворке нет нуллабельного типа, то его нельзя использовать.
А для меня есть хоть какая-то разница как оно имплементировано?
Ты утверждаешь, что TraParse не имеет исключений, но на самом деле этот метод работает с исключениями, просто тебе об этом не сообщает. TryParse просто тупо проглатывает исключения.
Или ты хочешь сделать так
bool res1 = int.TryParse(myStr1, out int val1);
bool res2 = int.TryParse(myStr2, out int val2);
bool res3 = int.TryParse(myStr3, out int val3);
и т.д.
и сказать что это правильно?
Я говорю, что все зависит от задачи. А код
int.TryParse(myStr1, out int val1);
int.TryParse(myStr2, out int val2);
int.TryParse(myStr3, out int val3);
и т.д.
вполне может быть правильным. Также как и другие варианты.
зачастую инициализировать бесполезным начальным значением
Это не нужно, в остальном логичная ситуация. У меня есть мешок (декларация), я даю его тебе (передача как реф-аргумента), ты его наполняешь и после окончания твоей работы как функции у меня остается наполнеnный мешок. Все интуитивно понятно. Часть кода само собой разумееющаяся, но если опустить декларацию, то получается хренова лямбда - код больше не связный текст, а обрывки слов заикающегося человека, которого ты понимаешь только потому, что с ним живешь.
Сказал, как отрезал.
навскидку: вот нужна мне функция, которая выдаёт корни квадрантного уравнения
Или функция, которая выдаёт немецкую календарную неделю: kw, year переданной даты.
Заводи класс (который только тут и будет использоваться), возвращай объект - как замшелые старички учили. И не дай бог перепутаешь, в стеке или в куче у тебя это храниться будет! Помню, раньше ещё, в 90-х объясняли, что у стека и кучи разная производительсноть, и надо там всё тонко разбирать. С тех пор у памяти настолько возросла производительность, а объёмы настолько увеличились, что прежняя оперативка влезает в сегодняший процессорный кеш. Да и компиляторы стали настолько умными, что аллоцируют везде, где им вздумается, и предсказать точно, где там что выделится, нельзя. Ты обозначил в коде так-то и так-то, а компилятор умнее тебя и оптимизирует как захочет. А на собесах до сих пор по языкам с неуправляемой памятью и компиляторм на ИИ гоняют по кучам и стекам.
Ни одному правилу не нужно следовать всегда и везде.
Это да. Надо руководствоваться здравым смыслом.
Примером тому goto, о котором легенды аж слагают, какой он плохой и всё такое - никогда не используйте... но есть мол пара случаев, когда он подходит. Бугага, оператор, который подходит под пару редких случаев - ради этого мы тащим его из языка в язык уже полвека.
Я не знаю случаев, когда в С# имеет смысл использовать goto. Таскают его скорее всего ради совместимости млм просто по привычке :)
Ну очевидно, я бы сказал, что возврат IEnumerable был бы лучше, т.к. можно было бы объявить общий интерфейс для квадратного уравнения, кубического, уровнения любой степени, дифференциального уравнения, системы уравнений итд. В случае с кортежем такой гибкости нет.
- Чем ты занимался последнюю неделю?
- Делал иерархическую систему интерфейсов для разных возвратов для решения разных типов уравнений. Нам нужно ещё 3 недели, чтобы дописать, отладить, и написать к этому документацию и тесты.
- *********************************************!!!!!!1111
- Ну ведь с кортежем такой гибкости нет!
))))
Не совсем понял, что ты тут предлагаешь и зачем такая функция может понадобиться, когда есть DateTime, а расчет KW можно прикрутить exstension методом. Собственно говоря, решение вычислась две разных задачи в одной функции - не самое лучше решения с точки зрения дизайна ;)
Одна или две задачи решаются вот этой конкретной функцией? Это философский вопрос, а кортеж можно заюзать здесь и сейчас.
Это было бы смешно, если бы не было бы так глупо :)
Интерфейс - это абстракция. Кортеж - конкретика.
Если разрабатывать софт опираясь на конкретные объекты, то рано или поздно будешь похоронен в лесу костылей. При этом костыли будут непонятным образом влиять друг на друга и все это это будет совершенно нетестируемо.
Я не знаю как оно там в вебе, а у меня на работе среда разработки Visual Studio 2015 и .Net 4.0. И переход на более новую версию дот нета максимально оттягивается.
Да и вообще, в реальной жизни приходится больше работать с легаси кодом, чем писать что-то новое.
Это понятно. Но эти кортежи в возврате вместо аут-параметров - это прям ням-ням. Не знаю почему, но меня постоянно бесило после названия функции вспоминать, что там надо пачку аутов определить, прерывать ход своих мыслей по коду и идти определять эти ауты. Ну это примерно как если бы уборщица во время погружения в код попросила тебя выйти на минутку, пока она под тобой пол помоет. Только уборщица делает это от силы раз в неделю, а аут-параметры - постоянно.
Юнит-тест это метод, который проверяет условия. Мы что то делаем, потом проверяем результат сделанного. Цель - проверить написанный КОД. Юниттесты проверять не надо. Они испольняются каждай раз на бильдсервере и гарантируют соответствие кода определенным критериям. Не правильности кода, а именно соответствии критериям, установленным автором тестов.
Да идея-то юнит тестов понятна. Они должны быть простыми, чтобы в них самих как можно меньше ошибок было. Но кто будет следить за тем, что они на самом деле что-то проверяют, что задача не изменилась? У тебя был один код, соответствующий заданию, теперь их параллельных два - и каждый описывает одно и то же задание, но теперь ещё первый описывает второй. При этом первый никто не описывает. Не кажется, что тут лишнее звено? В разработке через тестирование вроде как уходят от этого - там код подчиняется юнит тестам, тесты - заданию. Сам код заданию не подчиняется. Но сложность в том, что тогда тесты должны 100% или очень близко к этому покрывать код. Если нет - то снова получается, что в каких-то местах код должен подчиняться заданию, но тесты это не проверяют.
Проблема юнит тестов в том, что либо их мало и они тестируют всякую мелочную чушь, которая и так очевидна, либо их должно быть настолько много, чтобы они всё покрывали, но тогда разработка усложняется раза в два. Промежуточный вариант самый плохой - весь код не покрыт, разраб то по тестам проверяет свой код, то соотносится с заданием, то и то и другое вместе. Тогда разработка тормозится раза уже в три.
Ну очевидно, я бы сказал, что возврат IEnumerable был бы лучше,
тут ты прав, т.к. корни уравнения одного типа и порядок вывода не имеет значения.
Не совсем понял, что ты тут предлагаешь и зачем такая функция может понадобиться, когда есть DateTime, а расчет KW можно прикрутить exstension методом. Собственно говоря, решение вычислась две разных задачи в одной функции - не самое лучше решения с точки зрения дизайна ;)
DateTime не высчитывает немецкую календарную неделю.
а в алгоритме расчёта ты получаешь и неделю и год.
можно конечно написать две функции, но это во-первых копипаста будет и во-вторых не перфомантно.
Мат.часть учи - разрешили уже инлайн декларацию оут-параметрa...
Т.е. его можно использовать после вызова метода, не объявляя перед? Здорово, теперь я должен помнить, что область видимости параметров метода не всегда ограничивается этим методом. Если они инлайн-аут, то и продолжается после, а если рев - то контекст метода и вызывающий этот метод контекст.
От таких дырявых абстракций проще отказаться. Поэтому методы в шарпе - это не классические функции, как учили в начальных си-подобных языках. Раз у нас области видимости параметров играют как хотят, в зависимости от приписываемых параметрам модификаторов, то и с возвратом можно поизвращаться - гулять так гулять.
Не смешно. Особенно, когда ты рассказываешь, что пишешь софт для производства. int.Parse кидает не только FormatException. Если у тебя входная строка null (а ты, я вижу любишь возвращать null'ы), то твой подход просто проглотит исключение и будешь ты долго и упорно искать причину проблемы, которая лежит за пределами int.Parse
))))
поменял типы данных у стороннего объекта
------
Я просто скопипастил твой код - ленивый Я, лениво писать тип в каждой строке.
чтобы ты не любешь исключения
-----
Над мал-мал на рЮсская языка переводить...
Что до исключенй - когда надо - пользуюсь. Но - да - предпочитаю код где они не нужны. не не используются, а не нужны.
твой подход просто проглотит исключение
-----
Как можно проглотить то чего нету?
Ну посмотри на это сбоку.
Есть метод bool TryParse(string source, out int val)
Предлагается замена int? Parse(string source)
Все тоже самое только bool и int упакованы в int?
Никаких других преимуществ или проблем - нету. Просто нету. неоткуда им там появится.
Мне исключения не нравятся, потому что:
1) громоздкий синтаксис
2) пишутся сильно далеко от когда, который эти исключения бросает (где-то в конце функции)
Это понятно. Но эти кортежи в возврате вместо аут-параметров - это прям ням-ням. Не знаю почему, но меня постоянно бесило после названия функции вспоминать, что там надо пачку аутов определить, прерывать ход своих мыслей по коду и идти определять эти ауты.
Не знаю почему, но я так с ходу и не вспомню, когда писал (и писал ли вообще) функцию с out параметрами :)
DateTime не высчитывает немецкую календарную неделю.
а в алгоритме расчёта ты получаешь и неделю и год.
можно конечно написать две функции, но это во-первых копипаста будет и во-вторых не перфомантно.
Может быть я чего-то не понимаю, то год - это проперти у DateTime. Там ничего писать не надо. Надо сделать только экстеншен метод для DateTime, который бы рассчитывал немецкую календарную неделю.
Они должны быть простыми,
Нет. Они могут быть реально сложнее чем сам код. Просто это не продуктивный код. Если там что то неправильно это плохо, но не критично.
Не кажется, что тут лишнее звено?
Нет. Ввод непродуктивного проверяющего кода не гарантирует отсутствие ошибок. Но снижает их и снижает очень ощутимо. Просто надо понимать цели иправильно использовать. И помнить, что продуктивный код работает и с юниттестами и без них. И юниттесты нужны в первую очередь не для поиска ошибок, а для проверки кода на критерии. Если юниттест обвалился, то проишодит это всегда в среде разработки и тестирования и никогда в продуктивной среде. То есть есть возможность руками залезть и разобраться, кто виноват.
Проблема юнит тестов в том, что либо их мало и они тестируют всякую мелочную чушь, которая и так очевидна, либо их должно быть настолько много, чтобы они всё покрывали, но тогда разработка усложняется раза в два.
Это уже философия. Проблема в том, что программисты либо неопытные либо дорогие. Что начальство тупое либо это не наше начальство. либо-либo
Это было бы смешно, если бы не было бы так глупо :)
Интерфейс - это абстракция. Кортеж - конкретика.
Если разрабатывать софт опираясь на конкретные объекты, то рано или поздно будешь похоронен в лесу костылей. При этом костыли будут непонятным образом влиять друг на друга и все это это будет совершенно нетестируемо.
Я согласен в общем. Новичкам, и мне в том числе, не хватает опыта, чтобы уже знать и предсказывать, где могут возникнуть сложности от попыток слукавить и отойти от правил тут и там. Но на практике часто требуется именно наговнокодить несмотря на все последствия - всё горит, заказчик требует. А если заказчик при этом ещё и любые бабки платит, то сеньор-архитектор менеджер стоит над тобой и бьёт по рукам
уже за попытки сделать по-уму, а не тупо быстро наговнокодить.
Этот подход называется "хуяк, хуяк и в продакшен". Хорошего в этом мало ;)
А на практике - платят неплохие бабки. ))) Главное, на собесе это не говорить.
Там уже не про яву - просто вы упомянули джаваскрипт, что там лучше. Я вспомнил, что вот есть очень известный и распространённый продукт, где перешли с джаваскрипта на шарп. Причём джаваскрипт выкинули вообще - всё, deprecated. Сначала подержали несколько версий параллельно - можно было и на том, и на том писать, а потом выкинули. Почему, как вы думаете?
А заказчик переименовал вордовский бинарный файл в текстовой и запустил импорт
Ты неправ. Заказчик набрал студентов и они переименовывают все файлы из системы чтобы найти который из них может обвалить приложение.
Это самая распространённая практика думаю
на самом деле
------
он не выбрасывает исключений. хандлил ли он что-то внутри себя - не играет никакой роли.
Я говорю, что все зависит от задачи.
-----
Хи-хи... У нас уже правильность кода начала зависеть от того возвращаем мы два отдельных элемента и их упаковали перед возвратом...
о обработке исключительного состояния и о том, что лучше - усключение или null
-----
Вроде как тема несколько другая - иметь оут-параметер или упакованный возврат.
Исключений - не будет, возврата null тоже,
Результат будет одним и тем же - невозможно обработать данные.
------
Результат будет существенно разным;
В случае когда отвалил по первой встреченной пролеме ты не имеешь информации об остальных ошибках.
Т.е. ты сообщишь челу об ошибке и он ее исправит... как сможет... вплоть до того, что удалит строку с ошибкой и по окончании импорта/парсинга введет в ручном режиме.
После чего будет импортировать/парсить снова и уткнется в следующую ошибку и будет вынужден снова что-то делать.
А чел - ленив и допускает ошибки.
Так что имея необходимость повторить импорт/парсинг 10-15-100 раз обязательно сделает что-то неправильно.
В случае когда получается полный список того что невозможно распарсить - выполняется однократная обработка всех ошибок в ручном режиме.
В этом случае неправильных действий будет гораздо меньше.
Можно подождать пару часов, пока отработают остальные.
-----
Ну так можно и 100 раз по паре часов ждать пока найдется место которое нельзя распарсить. 
ООП такое не говорит и говорить не может.
------
ООП говорит что объект должен отвечать за себя сам.
В данном контексте - сообщить что не так со значениями пропертей.
где уже первая строка показывает
-----
Пыхх...
Ну значит возьмешь нужный парсер, делов то - запросить его у фабрики.
Но вопрос то был не в этом.
А заказчик переименовал
-----
У операторов, кстати, регулярная проблема - пришел файл, получили ошибку импорта, открыли, отредактировали, сохранили... pissec.
Потому как получили текстовый файл, открыли Вордом (.тхт) или Ехцелом (.цсв) и сохранили в формате по умолчанию.
Он будет очен рад протоколу ошибок
-----
Поверь - будет лучше поиметь охрененный список из всех ошибок, чем мудохаться с каждой не зная сколько их еще осталось.
Она никак не изменилась по сравнению со "старым" синтаксисом.
-----
Именно это и напрягает.
Когда ты декларируешь переменную в цикле - она доступна только в цикле.
А когда в вызове функции - вываливается за пределы вызова.
Для меня данный момент создает некоторый дискомфорт.
Заводи класс (который только тут и будет использоваться), возвращай объект - как замшелые старички учили. И не дай бог перепутаешь, в стеке или в куче у тебя это храниться будет! Помню, раньше ещё, в 90-х объясняли, что у стека и кучи разная производительсноть, и надо там всё тонко разбирать. С тех пор у памяти настолько возросла производительность, а объёмы настолько увеличились, что прежняя оперативка влезает в сегодняший процессорный кеш. Да и компиляторы стали настолько умными, что аллоцируют везде, где им вздумается, и предсказать точно, где там что выделится, нельзя. Ты обозначил в коде так-то и так-то, а компилятор умнее тебя и оптимизирует как захочет. А на собесах до сих пор по языкам с неуправляемой памятью и компиляторм на ИИ гоняют по кучам и стекам.
чувак, ты правильные вещи говоришь!
Может все же пойдёшь к нам работать?))
Да ладно! В яве нет генериков? :)
чувак, ты может почитаешь все же, о чем речь идёт?))
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/value-tuples
.е. ты сообщишь челу об ошибке и он ее исправит...
Нет. Ты говоришь о текущих ошибках ввода. Типа сидит оператор и пытается понять, что то там не так. Но не всегда есть оператор. Например система автоматически выбирает файлы из папки. И нашла там какую то хрень. Или идёт многоуровневая обработка данных и первый уровень гордо отрапортовал - я насчитал какую то хрень. Дальше отправлять? На следующий уровень... В этом случае обработку нужно прервать. Причем эта необходимость - это условие задачи. То есть я, как программист, вижу, что дальнейшая обработка невозможна или бессмысленна. В этом случае эксцептион и имеет преимущество. Особенно на вебе. Где бы подобная ошибка не произошла - ексцепшион выбросит курсор в централизованное место обработки исключений, которое и составит правильный ответ сервера.
Ну значит возьмешь нужный парсер, делов то - запросить его у фабрики.
Ещё раз. Мы имеем дело со случаем, когда продолжение работы невозможно. От слова совсем. Ну оборвался файл и пошел мусор. Какой парсер ты будешь к мусору искать?
И ООП ничего не говорит о логах. Или о том, как объект должен реагировать на ошибку. И даже о том, что он должен делать с ошибкой. Например это веб приложение без логов и ошибка произошла на уровне уровня доступа к базе данных. Задача - сформировать правильный ответ сервера. Но уровень не имеет выход на транспортный уровень и ошибку нужно догнать до слоя API. Где и будет сформирован и отослан ответ.
Таким образом каждое приложение имеет свою стратегию обработки ошибок, централизованную и стандартную для всего приложения, а не просто в логи пишет.
Вроде как тема несколько другая - иметь оут-параметер или упакованный возврат.
Смотри, не моя тема, умолкаю😀
вижу, что дальнейшая обработка невозможна
-----
Каким образом это определилось?
Тем, что не смогли распарсить поле?
Ой-ей - так оно - опциональное. Причем в первой версии требовалось нулевое значение для обозначения не заданности, а во второй - можно оставить просто пустым.
Какой парсер ты будешь к мусору искать?
-----
Мусорный, разумеется.
Тем не менее - даже по мусору предпочту получить отчет по каждому полю на парсинге которого произошла ошибка.
И - да - даже в том случае когда происходит чисто автоматическая обработка импорта.
приложение имеет свою стратегию обработки ошибок
-----
При любой обработке ошибок - источником проблемы когда-нибудь будет заниматься чел.
Вот этому челу и нужна будет достаточно детальная информация для выявления причин.
У меня, например, писалась не только ошибка, а вообще все исходные данные с разметкой и результирующая распасовка по полям.
По каждой записи, с описанием всех возникших ошибок.
Очень, знаешь ли, помогало при выявлении проблем.
Каким образом это определилось?
Путем интенсивной мозговой деятельности Murr, ну ты же думаешь, когда программируешь? Итак, ты ставишь проверку и продумываешь стратегию поведения проги после нахождения исключительной ситуации. У тебя действительно в жизни встечалась только одна ошибка - "не смогли распарсить поле"? Да нет никаких полей в неправильном файле. От слова совсем. Это если брать импорт. В сложном импорте с несколькими файлами это может быть отсутствие одного из файлов. Это может быть вообще не импорт
даже по мусору предпочту получить отчет по каждому полю
Откуда в мусоре поля?
Вот этому челу и нужна будет достаточно детальная информация для выявления причин.
2 Гб файл импорта, который случайно попал в прогу. 2 дня
прога пыхтела и никто не знал, как ее остановить. После чего прога вывалила 4Гб ценной информации по КАЖДОМУ полю, что оно не найдено И в конце скромно приписала - и вообще файл у вас не тот. Эти 4Гб детальной информации очень порадуют оператора, который не исправляет и не создает файлы импорта. Он их просто получает.
продумываешь стратегию поведения проги после нахождения исключительной ситуации
------
Я действительно думаю когда программирую.
Потому у меня в коде исключительные ситуации не связаны с тем какие данные обрабатываются и какие рассчеты производятся.
Это - издержки обучения - когда учили в языках никаких исключений не предусматривалось - надо было писать корректно работающий код.
Откуда в мусоре поля?
-----
А почемы ты думаешь что их там нет?
Хотя - да, их там нет. Впрочем, их нет и в корректном файле данных.
Потому как "поле" это то как прожка читает данные.
Прожка у тебя есть по определению - следовательно она будет читать поля из что-ей-там-дадут.
4Гб ценной информации по КАЖДОМУ полю, что оно не найдено
-----
Обеспечь достаточное количество пустого дискового пространства.
Остальное - забота того кто будет разбираться с ситуацией.
и никто не знал, как ее остановить
-----
Хреново же у вас пишут код... 
В комментах к видео о работе разрабом в Силиконовой долине встретил:
расскажите, пожалуйста, как на ваших местах работы (а вы уже побывали в нескольких именитых компаниях, о которых ваши зрители по бОльшей части пока что только мечтают) относятся к TDD-подходу или даже к DDD? И пользуются ли они метриками управления зависимостей при управлении архитектурой отдельных компонентов и проекта в целом, например, такими как REP / CCP / CRP?
Насколько канонично внедрен Agilie/Kanban? И интересно в целом, правда ли, что в Долине особо популярно (по сравнению с СНГ, например) следование заветам Роберта Мартина, Мартина Фаулера и других столпов индустрии или же на первом месте стоит только умение программиста "запиливать фичи быстро здесь и сейчас без оглядки на будущую поддержку"?
Почему то раньше имел субъективное мнение о "безупречности" (в разумных пределах) кода, рожденного в Долине, но некоторые ваши выпуски с рассказами о гиперактивных менеджерах, повышенном кортизоле из-за постоянного стреса и метриках, оценивающих количество фич в неделю пошатнули мою веру))
Можно ли где то встретить в коменте к мерж реквесту сообщение типа (абстрактный пример в вакууме):
"Переделай. Данный класс нарушает принцип устойчивости зависимостей SDP, т.к. его устойчивость меньше, чем устройчивость зависящих от него классов в соотношении 0.5 к 0.3"?
А у вас можно где-то встретить не то, что коммент к мерж реквесту, а хотя бы мнение коллег на кодревью, как выделено жирным? Что-то мне подсказывает, что вероятность стремится к нулю.
Сколько ни встречал описаний компаний, какие у них подходы введены, то это лишь то, к чему они как бы стремятся, а обычно в реальности всё раза в 2-3 хуже. А уж если аврал или "клиент сказал срочно надо - платит любые деньги!", то на все принципы плюют, кроме одного - "тяп-ляп и в продакшон... а там на поддержке поправим (если клиент её закажет)".
и никто не знал, как ее остановить
-----
Хреново же у вас пишут код...
В некотором ПО серверную часть просто раз в сутки перезагружают. Т.е. сами серваки перезагружают. И так делают уже много лет (точно больше 10). Потому что память течёт, и оказалось, что перезагружать раз в сутки тупо проще, чем искать оставшиеся места утечек. Проект, кстати, был успешным много лет, но потом скатился, но не из-за постоянных перезагрузок, а глупости руководства.
Хреново же у вас пишут код...
Мой пример был абстрактным. Но я вполне могу себе представить сервер, который отлавливает и импортирует мелкие файлы в пару килобайт. Для него нет графической оболочки. И нет средств прервать импорт, потому что они нахрен не нужны для импорта, который длится 2 секунды. И тут в импорт попал гигабайтный файл. И система не умеет распознавать и обрывать фальшивый импорт самостоятельно, а должна , как предлагает мурр, домучать фальшивый файл до конца. В этом случае действительно нет средств остановить импорт, кроме как прибить приложение.
Извиняюсь, не выдержал.
Я действительно думаю когда программирую.
Может быть, не знаю. Но не когда пишешь в форум - точно не думаешь.
Потому у меня в коде исключительные ситуации не связаны с тем какие данные обрабатываются и какие рассчеты производятся.
Поздравляю, Шарик, ты балбес. Который тупо не понимает что такое исключительная ситуация.
Это - издержки обучения - когда учили в языках никаких исключений не предусматривалось - надо было писать корректно работающий код.
Ага. И именно поэтому в сях шагу ступить было нельзя чтобы метод не возвращал код состояния. 0 - ок, 1 - неверное имя файла, 2 - переполнение диска и те пе. Или такого ты не видел и, конечно же, сам, в силу офигенной гениальности, не писал?
не понимает что такое исключительная ситуация
------
Деление на ноль это для тебя исключительная ситуация?
И именно поэтому в сях шагу ступить было нельзя чтобы метод не возвращал код состояния.
-----
Да-да... именно по-этому там небыло типа void...
Или был и пользовался?
А учили меня на Фортране - ни обработки ошибок, ни возможности как-то добраться до системных обработчиков.
Потому вместо бездумного тру-катча на ловлю блох пользуется голова с целью получения обезблошенного кода.
Насчёт того, где там что аллоцируется и я говорил, что сейчас такие умные компиляторы пошли, что нельзя точно сказать, где и как аллоцировалось. Вот пример для локальных методов
Local functions - C# Programming Guide | Microsoft Docs
Конечно, там написано, когда и как аллоцируются захваченные переменные, но это такие тонкости... Если дойдёт до оптимизации на этом участке кода, можно специально повторить-прочитать ещё раз подробно про подобные методы, лямбды и аллокации, а главное, какие и когда лучше по производительности. Но держать это постоянно в голове, если вы не пользуетесь этим постоянно, глупо. Такие вопросики подойдут, чтобы заваливать кандидатов на собесах - перед собесом сеньор выписал себе на бумажке основные вещи, зазубрил и давай кандидата гонять: а если так определю - какие и где аллокации и какой импакт на перформанс? а если вот так? а если вот так-растак с наподвывертом? АГА! Не знаешь!.. К сожалению, вы отвечаете не на все вопросы, поэтому мы можем преложить вам лишь 70% от первоначально запрошенной вами суммы.
Сишарп сейчас настолько усложнился, что это надо либо работать, либо учить всю эту фигню непрерывно (забив на работу). Будешь знать хорошо только то, что постоянно используешь. Реальных фулл-стеков по всему дотнету либо не существует, либо они врут, что они фулл. Ну а если есть такие уникумы джоны скиты, то они вам как правило не по карману. А если кто ещё список других языков выкатывает...
Но держать это постоянно в голове, если вы не пользуетесь этим постоянно, глупо.
-----
Аллокацию, как и упаковку\распаковку довольно часто спрашивают на интервью.
Но для меня вопрос не в этом.
Для меня вопрос в том, как зашарить значительный объем данных между потоками.
Потоки у нас изолированы, аллоцируемые ими данные тоже.
По документации - нельзя.
Но - надо.
И хрен знает как делать... хоть свой диспетчер пиши...
мы можем преложить вам лишь 70% от первоначально запрошенной вами суммы.
-----
Не вижу никаких проблем 70% от заявленной зарплаты до того как я изучу те вопросы
на которые Я не смог ответить и 130% заявленной зарплаты после этого. Список
вопросов со ссылками на соответствующие разделы документации желательно
получить до окончания интервью.
Адекватный - поймет, а с не адекватным лучше не связываться.
Как то так...
надо либо работать, либо учить всю эту фигню непрерывно
-----
В этом случае не стоит "идти в программисты".
Средненький программист учит эту фигню в фоновом режиме и почти не напрягаясь.
Реальных фулл-стеков по всему дотнету либо не
-----
Тебе нужно до-определить понятие фулл-стек.
Оно включает много, но вот требования полностью знать .Нет там нет.
Да и из используемого в программинге из .Нет'а бывает занимает менее 10%.
А если кто ещё список других языков выкатывает...
-----
Ну выкатывает и чего?
У меня тоже есть список языков.
Там напротив каждого языка стоит уровень моего интереса к работе с ним
и коэффициент применяемый к требованиям по зарплате.
15-20% - можно торговаться.
Ну а позиция с предлагаемой юниорской зарплатой
и с расчетным значением в поллимона просто отсеивается.
Аллокацию, как и упаковку\распаковку довольно часто спрашивают на интервью.
Верно. А потом забывают и пишут "говнокод".
Не вижу никаких проблем 70% от заявленной зарплаты до того как я изучу те вопросы
на которые Я не смог ответить и 130% заявленной зарплаты после этого
Разве что через смену места работы. Но на самом деле скорее всего просто сразу не возьмут - будут искать дальше того, кто будет отвечать на 100% вопросов или близко и даже немного "учить" вопрошаемого... А потом тоже не возьмут, потому что интервьюеру не нужны конкуренты. Тут тонкая игра с попытками угадать настроение интервьюера и область его компетенций, и чтобы самому не провалиться. Поэтому наиболее выгодная стратегия прохождения интервью, если нет протекции - тупо проходить их больше, тогда вероятность найма увеличится.
Список
вопросов со ссылками на соответствующие разделы документации желательно
получить до окончания интервью.
Это что за детский сад? Они для того и придумываются эти вопросы, чтобы вы на них не ответили. Если бы каждый отвечал, мир бы рухнул.
надо либо работать, либо учить всю эту фигню непрерывно
-----
В этом случае не стоит "идти в программисты".
Средненький программист учит эту фигню в фоновом режиме и почти не напрягаясь.
Если ты этим постоянно занимаешься, то учится в фоновом режиме. Иначе ты учишь это по вечерам дома и по выходным, а жена ищет себе более подходящего мужа, пока ты готовишься покорять новые интервью.
Да и из используемого в программинге из .Нет'а бывает занимает менее 10%.
А задавать каверзные вопросы вам будут по всему дотнету.
У меня тоже есть список языков.
Там напротив каждого языка стоит уровень моего интереса к работе с ним
и коэффициент применяемый к требованиям по зарплате.
Это только для суперстар, о которым при этом всем известно, что они суперстар. Если вы скромный сеньор даже с большим багажом знаний, который не имеет свой раскрученный блог и репозиторий где-нибудь на Гитхабе, то все ваши приписки по зарплате просто игнорируются. Кадровики тоже не боги - им выгоднее прогнать ТОЛПУ через СВОИ критерии и отчитаться начальству о куче проделанной работы, чем подстраиваться под ваши.
Все эти закидоны со своими правилами хороши, когда у вас есть стабильная работа и вы можете себе позволить "искать" другое место годами, пока работаете на текущем. В противном случае правила устанавливает работодатель. Это только говорится, что в айти индустрии не хватает работников, на самом деле не хватает гениев и ходячих энциклопедий за зарплату миддла или максимум скромного сеньора. Всех остальных хватает с избытком. А бизнесы тоже вовсе не отличаются эффективностью (кроме как на словах, конечно же) и я бы сказал совсем не стремятся нанимать лучших - скорее дешёвых и исполнительных (но чтобы каверзные вопросы, хотя бы половину, тоже вызубрил - это такой ритуал). В крайнем случае закроются и всё - 90% же разоряются в первый же год.
Это что за детский сад?
-----
На сениорской позиции человек должен уметь принимать решения.
В данном случае - было выслушано и оценено заготовленное интервьюором решение.
Об этом ему и сообщено. .
Если ты этим постоянно занимаешься, то учится в фоновом режиме.
-----
Без если.
Программист постоянно изучает что-то новое.
Успешный программист - угадывает что именно надо изучить в первую очередь.
Когда, где и как - не важно. Важно - постоянно и много.
А задавать каверзные вопросы вам будут по всему дотнету.
-----
Не будут.
Во-первых - сами не знают.
Во-вторых - мы ведь знакомимся - Я тоже буду задавать вопросы.
И какие они будут зависит от ситуации которую они создадут.
Вот сейчас есть позиция, на которой требуется знание Дельфи 5/6.
Я не пользовался Дельфи - не нравится Паскаль.
Но пользовался СиБилдером.
Есть смысл пробовать? Какие могут быть вопросы?
Если интервьюор толковый и знает тему, то никаких проблем не будет
- там в основе ВЦЛ написанная на Паскале и на каком-то уровне
Паскаль приходится знать.
А при тупом менеджере работать с кучей легаси кода совсем не улыбается.
все ваши приписки по зарплате просто игнорируются
-----
Кем?
Я не показываю свой список ни хрюшам, ни рекрутерам.
Я его использую для оценки предлагаемой позиции - перегрузили требованиями - ищите дальше.
когда у вас есть стабильная работа
-----
У меня НЕТ:
- работы
- пособия
- возможности сменить страну.
И мне уже пофиг что будет дальше.
бизнесы тоже вовсе не отличаются эффективностью
-----
У них другие задачи.
Если ты этим постоянно занимаешься, то учится в фоновом режиме.
-----
Без если.
Программист постоянно изучает что-то новое.
Успешный программист - угадывает что именно надо изучить в первую очередь.
Когда, где и как - не важно. Важно - постоянно и много.
Правильные фирмы не дают своим программистам сильно что-то изучать за пределами их текущих обязанностей. Чтобы их можно было прогибать по зарплате, не повышать её сильно, и не давать возможностей свалить в другую фирму (если они реально что-то полезное делают - в противном случае увольняют на раз, конечно).
h ttps://youtu.be/kQZPlYKjTkA?t=767 (тут не вставляются видео с таймкодами)
и скорость на 1,25.
Мурка, ну ты чего?
-----
Чего-чего... пострелять охота... из чего-нибудь калибром 12.6 мм...
А тут еще последний главнокомандующий ВС СССР помер...
и из запаса не уволил... т.е. надо мною, в соответствии с действующими
законами, - никого... хоть самолично войну объявляй... можно даже
соблюсти требуемые в европе приличия - проголосовать по вопросу всем
наличным гражданам СССР...
А причем тут Я?
Аксиома - программист постоянно учится.
Это независит от его состояния - работает, женат, дети. командировкi...
Перестал учится - выпал из востребованных, а там и из специальности вообще...
Это, кстати, один из моментов которые не могут понять те, кто просит научить быть
программистом.
Десктоп на Сишарпе вообще не котируется в Германии, или как?
Если что-то делается для HMI SCADA. Там хорошо себя чувствует C#/WPF. Допустим Copa-Data платиновый вроде партнёр Microsoft.
Похоже, вместо сишарп и дотнета придётся заниматься джаваскриптом и фронтэнд-вебфреймворками, а это противоположно тому, что я хочу.
JavaScript это ведь круто, очень интересный язык программирования/скриптовый язык.
Ещё и базы данных для этого сайта делает
Используйте EF / Code First какие проблемы? Раньше так и делал.
Ещё, кто знает, как сейчас сишарп применяется для мобильных приложений?
Мне кажется скоро перестанут Xamarin развивать, а разработчики Apps перейдут на Ionic Framework.
Дневник тяжелобольного инвалида
Всё это жутко тормозит и жрёт в разы больше ресурсов, но по-видимому бизнес это устраивает.
Простенькие приложение можно делать на Electron. На HTML проще UI нарисовать, чем в WinForms/WPF. А сложные десктопные приложения на Java или на Net. Проблемы начнутся когда заказчик попросит чтобы он мог создавать кастомные менюшки и формы, а так-же составитель отчёта. Раньше лепили приложения в MS Access и в MS Visual FoxPro, и заказчик мог сам менять формы, отчёты.
Дневник тяжелобольного инвалида
Не хочу связываться с вебом, т.к. последний раз, когда это делал, пришлось чуть ли не бОльшую часть времени уделять фронт-энд части, которую я знаю плохо.
Гм. Как раз на вебе есть как правило голый бекэнд. Где по определению никакого фронта нет Все хотят фуллстек, но в принципе это не обязательно. Я фронт знаю плохо.
JavaScript это ведь круто, очень интересный язык программирования/скриптовый язык.
Я с ним очень мало соприкасался, но очень много о нём мнений встречал. Вобщем, это хороший язык для того, для чего он был создан - небольшая интерактивность страничек, плюс асинхронные (без перезагрузки страницы) загрузки. А когда стали пытаться сделать из него язык для всего, для сложных приложений, а потом и вообще на десктоп тащить стали, а также в бэкэнд, то джаваскрипт резко превратился в плохой язык. Единственное, почему это стали делать - тащить джаваскрипт во все места - это доступность и массовоть джаваскрипт разработчиков. Ради этого закрывают глаза на все остальные недостатки. Но это не заслуга языка, я просто текущая конъюктура рынка.
Гм. Как раз на вебе есть как правило голый бекэнд. Где по определению никакого фронта нет
Вот-вот. Вакансии из разряда "требуется Дотнет разработчик", и далее в требованиях помимо Сишарпа ещё и джаваскрипт, ХТМЛ, CSS и какие-нибудь фронт-энд фреймворки. Вобщем, в реальности им нужен веб-фронтэндер, а на бэкэнде так - по остаточному принципу. При этом чисто бэкэндщик на Дотнете как правило не требуется - нужен, как вы сказали, фуллстек, чтобы любую часть сайта поправить мог.
а также в бэкэнд
-----
Вполне себе существует как язык бакэнда с самого начала своего существования.
Некоторые менеджеры даже был в восторге - нужны разрабы с всего одним языком...
правда, как оказалось, два - серверный и клиентский - жабьих скрипта в одном
документе требуют кораздо более высокой квалификации разраба...
А потом ещё оказалось, что без Тайпскрипта или какой другой ООП-обёртки оно нормально не взлетает, и что это далеко не последнее, чем нужно обмазать джаваскрипт, чтобы нормально на нём писать...
Глянул вакансии Xing (New Work SE) - руби на лельсах и джаваскрипт во все поля.
Jobs | NEW WORK SE (new-work.se)
Не то, что дотнетчик, а и джавист может даже не пытаться туда бевербеваться.
небольшая интерактивность страничек, плюс асинхронные (без перезагрузки страницы) загрузки. А когда стали пытаться сделать из него язык для всего, для сложных приложений, а потом и вообще на десктоп тащить стали, а также в бэкэнд, то джаваскрипт резко превратился в плохой язык
все как раз наоборот, им начали заниматься серьезные фирмы и качество кода и фреймворков заметно подросло, до этого там был полет мыслей, до jQuery и того хуже
Для этого и делали WebForms, там есть Design View, вы точно так-же тянете ASP NET компоненты как в WinForms, а начиная с версии помойму 2012 Visual Studio, там по умолчанию есть jQuery и Bootstrap. Для этого и делали разные CSS и JavaScript фреймворки, чтобы быстро делать веб приложения, и чтобы адаптивный дизайн был. А WPF больше для интерактивных Windows приложений подходит.
Дневник тяжелобольного инвалида
сравнивать Webforms с JavaScript это как сравнить английский с саксонским диалектом немецкого ))
Я имел ввиду если ТС не хочет париться с JavaScript, то может использовать WebForms, для этого и делали WebForms чтобы не пилить это на JavaScript.
Дневник тяжелобольного инвалидавы точно так-же тянете ASP NET компоненты как в WinForms
Я только ASP.NET MVC использовал - это без готовых клиентских компонентов, только серверная инфраструктура предоставляется. Все клиенсткие компоненты - со стороны. То, что там в последних версиях (ASP.NET MVC 3-5) есть шаблоны, где можно начать проект сразу с подключенными CSS- и джаваскрипт-фреймворками - это всё всё равно со стороны, а не включено в ASP.NET MVC фреймворк.
Я имел ввиду если ТС не хочет париться с JavaScript, то может использовать WebForms, для этого и делали WebForms чтобы не пилить это на JavaScript.
Насколько я знаю, это давно obsolete и либо очень старые проекты поддерживать, либо вообще никак. Почти все вакансии если и связаны с вебом для дотнета, то там ASP.NET MVC или что там ещё новее у Майкрософта есть. Когда я ASP.NET MVC использовал, то максимум что из джаваскрипта брал - функции некоторых компонентов (типа график нарисовать и прочее) - сам функции и программы на джаваскрипте на клиентской стороне не писал. Просто смотерел тьюториал по джаваскрипт-компоненту и вызывал его функцию с нужными параметрами. Если делать приложения с развитой клиенсткой частью, то там надо и клиентский слой хорошо прорабатывать - это нужен джаваскрипт-специалист, а не такой, как я, который только иногда отдельные функции компонентов дёргать может.
Тут ещё загвоздка в том, насколько в проекте собираются перетянуть одеяло на клиентскую часть, и насколько хотят урезать северную. Если всё в основном на бэкэнде делается, а клиент только представления показывает и обновляет, то достаточно джаваскрипт фреймворков с привязками (байндинги - я использовал KnockoutJS), асинхронных запросов и вызовов функций компонентов - это я делал. А когда на фронтэнде пишут полноценную логику, всякие одностраничные приложения (SPA) и прочее, то тут ASP.NET MVC и вообще сишарп со своей серверной частью отходят сильно на второй план, и я тут умываю руки - я тут не специалист.
Я имел ввиду если ТС не хочет париться с JavaScript, то может использовать WebForms, для этого и делали WebForms чтобы не пилить это на JavaScript.
ТС не хочет на позицию, где нужно будет париться с Javascript.
плюс WebForms не заменяет Javascript и наоборот
Вкратце почитал - они пишут нативно испольняемый код для каждой платформы (считай, нативный фреймворк - код пишется на шарпе, потом компилируется в натив), а вебстек используют просто для рендеринга интерфейса.
Выглядит хреново, что Блазор, что Разор - разметка перемешивается с кодом на шарпе. Такое ощущение, что это всё для небольших поделок. В больших приложениях быстро запутаешься, где тут код, где разметка, и в этой каше разбираться.
Но есть плюс у Блазора - привязка данных (байндинги) работают из коробки, без сторонних фреймворков?
ASP.NET Core Blazor data binding | Microsoft Docs
Для ASP.NET MVC даже с использованием Разор нужно было сторонний фреймворк использовать для привязки (я брал KnockoutJS).
ТС не хочет на позицию, где нужно будет париться с Javascript.
Это несправедливо, что джаваскриптеры и более обще веб-фронтэндеры лезут во все щели с одним своим джаваскриптом (плюс CSS и HTML - это для них один стек) и больше к ним никаких требований не выкатывается. А всем остальным, работающим с вебом, хоть джавистам, хоть дотнетчикам, хоть рубистам, нужно знать ДОПОЛНИТЕЛЬНО весь фронтэнд стек. И когда дотнетчик начинает что-то на фронтэнде для веба делать, то он начинает полностью в его пробелмы погружаться, а бэкэнд как бы уходит на второй план. Потому что веб-фронтэнд настолько проблемный и настолько там всё быстро меняется, что ты волей-неволей переквалифицируешься потихоньку в веб-фронтэндчика-джаваскриптера.
В нормальных и больших компаниях вроде это разделяют - бек и фронт делают разные люди. Но что-то мода пошла всё соединять в одном лице и требовать от кандидатов фуллстек. Потому если проект пишут на ноде, то требуются одни джаваскриптеры, которые делают и фронт и бек. А если на какой гибридной технологии, типа дотнета или джавы на беке, то от джавистов и дотнетчиков требуют ещё и отличное знание фронта (JS-CSS-HTML-Frontend Frameworks) со всеми его заморочками.
Потому у меня дилемма - если погружаться в веб разработку с беком на шарпе и дотнете, то будешь голову забивать фронтом вебовским, и забывать фронт десктоповский и мобильный (WPF, UWP и прочее, что там из GUI у дотнета есть). А я этого не хочу - меня тошнит от заморочек веб фронтэнда. Как зайдёшь на Хабр, почитаешь их кухню, как они костыль на костыль лепят там, где в дотнете всё давно удобно сделано, да ещё друг друга этим нахваливают и сеньорами называются...
где в дотнете всё давно удобно сделано
так если бы дотнет на всех платформах одинаково хорошо летал, то все бы на нем и писали, а так, хоть эпл, хоть линукс возьмите, как там с дотнетом, а в этом сегменте часто кастомеров больше, чем в винде, например, в медицине или химии.
Выглядит хреново,
Для меня очень даже ничего, особенно такую фигню для веба зафигачить
https://demos.devexpress.com/blazor/RichEdit
https://demos.devexpress.com/blazor/Scheduler
разметка перемешивается с кодом
С вебом особо не работаю, а что есть где не перемешивается?
В больших приложениях быстро запутаешься, где тут код, где разметка
-----
Разумеется. Если следовать образцам даваемым мелкомягкими - обязательно.
Но штука в том, что следовать совсем не обязательно - код выносится в дллки, разметка остается минималистической.
У меня как-то даже требования образовались - не более двух уровней - т..е. for-for, for-if, if...
И как только заставил писать в этом режиме - половина имевшихsя проблем исчезла...
а что есть где не перемешивается?
-----
Не знаю есть ли, но знаю что можно.
Т.е. можно построить байндер, который все заполнит коректно и при этом разметка не будет занать об источниках и наоборот.
И в ASP.NET для этого сделано довольно много. Фактически - все необходимое.
С вебом особо не работаю, а что есть где не перемешивается?
Похоже, что в вебе нет. Это-то и плохо, что веб джаваскриптеры как само собой разумеющееся считают, что перемешивать код и разметку - это нормально. Это только для коротких примеров для краткости пойдёт, как в той же моей ссылке на сайт МСДН.
Не знаю есть ли, но знаю что можно.
Т.е. можно построить байндер, который все заполнит коректно и при этом разметка не будет занать об источниках и наоборот.
И в ASP.NET для этого сделано довольно много. Фактически - все необходимое.
Вот в XAML не перемешивается - там от кода только байндинги к свойствам и методам. В примерах от МС идёт разметка, потом бац кусок шарповского кода, потом снова разметка - что Блазор, что Разор. Вроде, даже в последних версиях XAML позволили сишарповский код писать, а до этого народ свои расширения для этого делал. Ооочень редко это нужно. А то если позволишь, так народ начнёт прямо в разметке развесистые функции писать (те же сложные фильтры данных, вместо того, чтобы сослаться на них во View Model или в code behind).
А ещё иногда в Разор (да и в Блазор, похоже) делают циклами контролы. Т.е. надо из списка слепить ссылки в столбик, например - делают в цикле for или foreach элементы <li> или <a>. Тогда как в нормальных байндингах для этого специальное представление коллекций есть, которое само такие группы элементов делает.
Это несправедливо, что джаваскриптеры и более обще веб-фронтэндеры лезут во все щели с одним своим джаваскриптом (плюс CSS и HTML - это для них один стек) и больше к ним никаких требований не выкатывается.
Ой а я изучал более сложные ЯП чем JavaScript. Такие как LISP, Erlnag, Ada. Сейчас я изучаю COBOL, т.к. я не могу поставить Sap NetWeaver чтобы играться в ABAP, а если и даже смог-бы, то там тестовая версия ограниченна на 28 дней, а COBOL бесплатный. Сейчас покуда занимаюсь робототехникой изучаю ещё Lua, покуда роботы дорогие, а есть бесплатный симулятор, но там на Lua.
Дневник тяжелобольного инвалидаОоочень редко это нужно. А то если позволишь, так народ начнёт прямо в разметке развесистые функции писать (те же сложные фильтры данных, вместо того, чтобы сослаться на них во View Model или в code behind).
а потом получается, что у тебя логика и в code behind и во ViewModel, красота 
WPF мне тоже как-то не зашел
например что напрягает
<TextBox Text="{Binding object.Property}">
для Visual Studio object.property это тупо текст, ни тебе проверки, что ты тут букву пропустил, ни прыжка в класс, где есть проперти, по ф12
ни Find all References
так если бы дотнет на всех платформах одинаково хорошо летал, то все бы на нем и писали, а так, хоть эпл, хоть линукс возьмите, как там с дотнетом, а в этом сегменте часто кастомеров больше, чем в винде, например, в медицине или химии.
так не надо приложения под конкретную платформу разрабатывать, когда есть web
так не надо приложения под конкретную платформу разрабатывать, когда есть web
так я тоже об этом же. А потом удобно дать морду, чтобы кто посмотрел, попользовал как демо, а, если понравилось, то и купил. А если делать на дотнете и иже с ними, то надо для выхода на рынок сразу поддерживать всю эту галиматью в виде маков, винд, линуксов, где у каждого - свои погремушки. Как-то недавно работал с одной фирмой, в которой один фортрановский программист поддерживал бекенд и 28 человек рисовало фронты на все платформы, но начальство кололось, но не лезло на кактус жаваскрипта.
если позволишь, так народ начнёт прямо в разметке развесистые функции писать
-----
Ну так на этот случай есть полиси и коде ревью...
И когда народ хорошенько натрахается с невозможностью быстро что-то поправить в спагетти-лике - вполне себе без проблем пишет как требуется...
foreach элементы <li> или <a>
-----
В ASP.NET изначально есть шаблоны для итеративного вывода...
Вот только не каждый до их использования доходит - учить много надо - влепить <LI> куда как проще...
А что в вебе есть UI элементы которые могут себя отрисовать?
А я понял так, что ASP NET MVC Razor при попадание в AcrionResult возвращает во View коллекцию допустим из БД, которую можно во View отобразать используя foreach см. https://metanit.com/sharp/mvc5/4.1.php.
Например:
@foreach (BookStore.Models.Book b in Model)
{
<p>@b.Name</p>
}
Кстати есть вроде готовая сетка для ASP NET MVC Razor https://docs.microsoft.com/ru-ru/archive/msdn-magazine/201... не нужны эти foreach
Дневник тяжелобольного инвалида
Кстати, если можно было бы сделать в Razor View content-type как javascript см. https://stackoverflow.com/questions/4411841/how-to-set-con..., то можно было бы View-шку переделать на JavaScript, но боюсь JavaScript и C# там будет такая каша.
Дневник тяжелобольного инвалидатак я тоже об этом же. А потом удобно дать морду, чтобы кто посмотрел, попользовал как демо, а, если понравилось, то и купил. А если делать на дотнете и иже с ними, то надо для выхода на рынок сразу поддерживать всю эту галиматью в виде маков, винд, линуксов, где у каждого - свои погремушки.
чот я тебя не понимаю.
на дотнете тоже можно делать Web-приложения.
WPF мне тоже как-то не зашел
например что напрягает
для Visual Studio object.property это тупо текст, ни тебе проверки, что ты тут букву пропустил, ни прыжка в класс, где есть проперти, по ф12
ни Find all References
Надо контекст данных установить, тогда Интеллисенс вываливает список с подсказками пропертей:
XAML: Intellisense for Bindings And the Data Context -Deborah's Developer MindScape (msmvps.com)
Всего лишь эту строку
Всё верно. Причём можно это ставить для каждого подконтрола отдельно, а не для всего контрола в целом. Например, в окне объявил пространства имён для нужных тебе типов, а в конкретных контролах этого окна уже установил контексты данных для дизайна:
<Window
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:ns1="clr-namespace:MyApp.ViewModels1"
xmlns:ns2="clr-namespace:MyApp.ViewModels2">
<Grid d:DataContext="{d:DesignInstance Type=ns1:MyViewModel1}">
<ContentPresenter Content="{Binding Path=Property1.Subproperty1}"/>
<Grid d:DataContext="{d:DesignInstance Type=ns2:MyViewModel2}">
<ContentPresenter Content="{Binding Path=Property1.Subproperty1}"/>
И F12 для быстрого перехода из разметки в класс тоже работает. Единственное что плохо - синтаксис всего этого слишком многословный.
так я тоже об этом же. А потом удобно дать морду, чтобы кто посмотрел, попользовал как демо, а, если понравилось, то и купил. А если делать на дотнете и иже с ними, то надо для выхода на рынок сразу поддерживать всю эту галиматью в виде маков, винд, линуксов, где у каждого - свои погремушки. Как-то недавно работал с одной фирмой, в которой один фортрановский программист поддерживал бекенд и 28 человек рисовало фронты на все платформы, но начальство кололось, но не лезло на кактус жаваскрипта.
Браузер - это тоже платформа. Будет война браузеров с неподдерживаемыми стандартами веба (каждый будет свой подстандарт поддерживать) - придётся снова писать под каждый браузер свои хаки. Оно ещё недавно так было, да и сейчас частично - тот же Фаерфокс PWA не поддерживает
А что в вебе есть UI элементы которые могут себя отрисовать?
Мне пофиг. Я знаю, что есть ваиант лучше, и на вебовскую дикость смотрю с удивлёнными глазами - "вы ещё кипятите?!". Почему, чтобы сделать список, нужно руками прописать, что нужно в цикле создавать элементы этого списка? Ну или юзать спецкомпонент, который это сам умеет делать. Т.е. опять же - чтобы нормально что-то сделать, нужно залинковать кучку костылей-библиотек, потому что из коробки в вебе доступно примерно нифига.
чтобы сделать список, нужно руками прописать, что нужно в цикле создавать элементы этого списка?
-----
Кто это тебе сказал?
Что - можно - да, что - нужно - нет.
Ну или юзать спецкомпонент
-----
Какой спецкомпонент? Все стандартное, из коробки...
Просто учи мат.часть...
А ещё веб бесит тем, что там нет стандартов оформления - на каждом новом сайте нужно разбираться и привыкать, что как работает, где какие функции, какие кнопки жать, чтобы стандартные действия сделать. Типа того же поиска - он может быть где угодно на странице и как угодно оформить, а может и не быть вообще - вы об этом узнаете, только сначала внимательно изучив страницу.
Так мало того, даже на одном сайте всё по-разному оформлено может быть - даже одно и то же действие. Одни кнопки такие, другие - сякие. После нажатия на "удалить" перекинет на отдельную страницу "да, я хочу удалить...". Что это за мерзость? Такое ощущение, что один кусок делал один человек, другой - другой. Или тот же, но в разное время. А смотреть стили и следить за ними ему было лень. Из-за этого веб производит впечатление наколенной поделки и цирка с конями.
Дали команде задачу делать сайт - сделали. Потом через год другому чуваку дали задачу добавить страничку с доп. функционалом - он ваяет вообще другой дизайн и своё оформление. После 3-5 лет таких доработок сайт превращается в набор несвязанных друг с другом разноцветных кусков. Потому что в вебе привести всё к единому виду - боль. Каждый лепит свои костыли. Ещё и гордятся этим.
У МС дизайнер для WPF-XAML кривой-косой. И, похоже, на это давно забили - чтобы всякие удобные штуки работали, нужно надобавлять всяких расширений из Бленда. Не знаю, как в других своих XAML-фреймворках (UWP, например) они это сделали, но для WPF он глючный и многословный. Но всё ещё удобнее, чем веб фронтэндовские костыли. У веб фронтэнда разве что стили неплохо сделаны, но тоже с наследованием всё запутано, синтаксиса нормального для наследования и переопределения стилей нет - нужно запомнить кучу условностей, которые по написанию друг от друга почти не отличаются. Поэтому я и терпеть не могу веб фронтэнд - мозго...ство для восторженных студентов.
А ещё веб бесит
А меня бесит ООП. Многие современные ЯП без всяких ООП обходятся. А там где ООП хорошо развито, у меня нет денег на такие новые и платные среды разработки и фреймворки. Допустим если я программирую на древнем .NET то в моём случае нужно использовать делегаты, а если я использую делегаты, то методы должны быть статическими, а у меня конструктор есть. Я не думал что буду делегаты использовать, пол дня программировал класс (конструктор, Get-еры, Set-еры, разные методыитд), а теперь надо все методы на статический переделовать, и избавляться от конструктора.
А если я на современном NET делать, то нужно лучше тоже самое через async/await. А комп хрюкает и крехтит от Visual Studio 2019/Visual Studio 202x Community Edition.
Дневник тяжелобольного инвалидаА ещё веб бесит тем, что там нет стандартов оформления - на каждом новом сайте нужно разбираться и привыкать, что как работает, где какие функции, какие кнопки жать, чтобы стандартные действия сделать. Типа того же поиска - он может быть где угодно на странице и как угодно оформить, а может и не быть вообще - вы об этом узнаете, только сначала внимательно изучив страницу.
Так мало того, даже на одном сайте всё по-разному оформлено может быть - даже одно и то же действие. Одни кнопки такие, другие - сякие. После нажатия на "удалить" перекинет на отдельную страницу "да, я хочу удалить...". Что это за мерзость? Такое ощущение, что один кусок делал один человек, другой - другой. Или тот же, но в разное время. А смотреть стили и следить за ними ему было лень. Из-за этого веб производит впечатление наколенной поделки и цирка с конями.
А ещё это всё при загрузке тормозит. А если добавлена ленивая загрузка, которая сейчас примерно у всех, то у вас интерфейс будет прыгать и дёргаться, пока весь контент не подгрузится и всё не встанет на свои места. Даже на быстром интернете. Тебе кажется, что всё загрузилось - ну вот же виден интерфейс - и ты жмёшь на кнопку. Хрен тебе - скрипты ещё не отработали, контент снизу (или сверху - как любит Вики пихать какую-нибудь рекламу в баннер, который позже всех загружается, смещая весь интерфейс нафиг) не подгрузился. Так что жди ещё полсекунды. Если бы мне на десктопных приложухах каждая кнопка просила подождать полсекунды, я бы... А в вебе - в порядке вещей. Так что кто часто пользуется одним и тем же сайтом и хочет быстро жать на кнопки, к расположению которых он привык - фигвам, у нас тут модно-молодёжно. Типичный пример - сайт википедии и вообще на викидвижках (wictionary и т.п.). Особенно это бесит на мобилах с медленным интернетом и малыми экранами. Я привык при изучении языка часто искать слова - каждое обращение к полю поиска это боль и ожидание, пока там какой-то тупой скрипт выполнится. Если не вовремя нажать - перезагружает страницу вместо поиска. Я могу тыкать по нужным мне кнопкам по нескольку раз в секунду, т.к. все действия уже отработал до мелочей, а веб интерфейс говорит мне подождать, пока он прогрузится, прорисуется, выровняет все компоненты и вот наконец он готов... а мне уже и не нужно. Причём с соединением это не связано - уже всё передано. Это клиент-сайд пытается прожевать тонны джаваскрипта и отрисовать всё на моём устройстве (мы же экономим ресурсы нашего сервера?). Как офигенно "работать" в веб-версиях всяких офисных пакетов - хоть от МС, хоть от Гугла, хоть от кого. Если у вас куча нервов и свободного времени, а мышкой вы двигаете как будто первые два часа компьютер осваиваете - переходите работать в веб, там всё под вас заточено.
А меня бесит ООП. Многие современные ЯП без всяких ООП обходятся. А там где ООП хорошо развито, у меня нет денег на такие новые и платные среды разработки и фреймворки. Допустим если я программирую на древнем .NET то в моём случае нужно использовать делегаты, а если я использую делегаты, то методы должны быть статическими, а у меня конструктор есть. Я не думал что буду делегаты использовать, пол дня программировал класс (конструктор, Get-еры, Set-еры, разные методыитд), а теперь надо все методы на статический переделовать, и избавляться от конструктора.
А если я на современном NET делать, то нужно лучше тоже самое через async/await. А комп хрюкает и крехтит от Visual Studio 2019/Visual Studio 202x Community Edition.
Переходите в веб - там всё устаревает за 2-3 года (а не за 10-15, как в дотнете с делегатами) и куча тормозных и жрущих ресурсы сред разработки, которые едва ли до половины полноценной Студии дотягиваются. Сейчас пара-тройска ненагруженных страничек отжирает примерно гигабайт оперативы. А на этих страничках текст и несколько картинок. Когда-то я на этом гигабайте в Кризис играл, а теперь только текст и несколько картинок. Зато все модные словечки из современной веб-разработки задействованы. Всё в контейнерах крутится, на нодах всяких. Мобильный телефон с 2-3 гигабайтами оперативы сейчас невозможно нормально использовать - фактически однозадачный, постоянный своп и перезагрузка страниц.
Переходите в веб
Не, мне нужно сделать серверный командный интерпретатор, на подобие Bash, чтобы два или три файла можно было интерпретировать параллельно, а так-же чтобы можно было разделить экран на 2 или 3 участка, и чтобы можно было подключаться спомощью Telnet или PuTTY к этой программе, и ещё чтобы это всё было многопользовательским. Сначало делал одназадачным, а потом захотел сделать многозадачным. Там всё просто - сплитую строку т.е. пробелы и новую строку, дальше split возвращает массив, потом читаю из массива команду и параметры. Перед отъездом в Германию делал такое, только там было через COM порты, а тут по TCP-IP надо. Вообще никогда на экраны не разделял, может и через делегаты не то... Вдохновения появилось разделять экраны когда я посмотрел видео про компьютер GRID, там помойму можно было загрузить две программы, и разделить экран на зоны, и можно было переключаться между зонами, только всё чисто в текстовом режиме. Может быть и заброшу и переделаю всё в графическом виде. Пол дня делал парзер, теперь надо избавляться от конструктора из-за делегатов.
Дневник тяжелобольного инвалидаЗато все модные словечки из современной веб-разработки задействованы. Всё в контейнерах крутится, на нодах всяких
так может это кривожопость современных веб дезигнеров? А новомодность они притягивают, чтобы перед шефом отчитаться и не показаться дебилом, не способным сделать то, что надо, но без новомодных фреймворков.
У меня довольно развесистая самопально написанная морда, отрисовывая в 3Д одновременно 50 молекул, в каждой по 10-100 изомеров/конформеров и в каждом по 100+ атомов съедает только 39МБ браузерной памяти, а 100кб голого JS без фреймворков грузится довольно со свистом, то есть теоретически, если делать для себя, то можно сделать удобно, компактно и быстро.
Не совсем понял, что вы хотите. Можете глянуть тут Parallel Class (System.Threading.Tasks) | Microsoft Docs
Просто отрисовать - фигня. В какой-нибудь веб вьюпорт отправить результат рендеринга сторонней оптимизированной либы. Теперь попробуйте к этим молекулам через какой-нибудь Ангуляр или Реакт навесить через байндинги кучку свойств, событий, чтобы по кликам всплывали разные окошки (интерактивность, да) со вводом данных и валидацией. Сразу жор памяти пойдёт и всё тормозить начнёт.
Теперь попробуйте к этим молекулам через какой-нибудь Ангуляр или Реакт навесить через байндинги кучку свойств, событий, чтобы по кликам всплывали разные окошки (интерактивность, да) со вводом данных и валидацией. Сразу жор памяти пойдёт и всё тормозить начнёт.
А ручками без всякого ангуляра кто запрещал? У меня и все торсионные углы на лету считаются, маркируются и показываются, и менюшек куча, и перебор конформеров (а их под сотню на молекулу может быть) и выбор изотопов. Только не надо это через жопу всякие ангуляры и реакты делать, тогда и будет счастье. Могу в личку ссылку на морду послать, зацените.
В какой-нибудь веб вьюпорт отправить результат рендеринга сторонней оптимизированной либы
читайте выше внимательнее, рендерится тоже через голый JS, текст которого все так и вписывается в те самые пресловутые 100кб исходников.
Браузер - это тоже платформа... Мне пофиг.
Что то не складывается вместе.
В том то всё и дело что в вебе можно только отдавать команды браузеру и если один из них определенную команду выполняет не так как все или ее вовсе нет - то начинаются интересные вещи.
Допустим если я программирую на древнем .NET то в моём случае нужно использовать делегаты, а если я использую делегаты, то методы должны быть статическими, а у меня конструктор есть
разве?
class Math
{
public int Sum(int x, int y) { return x + y; }
}
class Program
{
delegate int Operation(int x, int y);
static void Main(string[] args)
{
Math math = new Math();
Operation del = math.Sum;
int result = del(4, 5); // math.Sum(4, 5)
Console.WriteLine(result); // 9
Console.Read();
}
}
Причём можно это ставить для каждого подконтрола отдельноМожно, но бардак как то не люблю. Хотя исключения могут быть.
Это только если в одной большой вью нужно кучу разных не связанных между собой вью моделей отобразить. Обычно это плохой дизайн. По-нормальному - через вложенные вью, где на каждую вью только одна вью модель. Тогда на самом верху у этой вью инициализируешь контекст данных и по всей вью всё привязывается и интеллисенс работает с прыжками из вью в ныжные классы.
В том то всё и дело что в вебе можно только отдавать команды браузеру и если один из них определенную команду выполняет не так как все или ее вовсе нет - то начинаются интересные вещи.
Сейчас всё в вебе на Хромиуме - т.е. привязано к одному вендору (Гуглу). Где крики "мастдай!", плюрализм мнений относительно того, как должен выглядеть веб? Когда эта идиллия кончится и начнётся снова борьба стандартов - джаваскрипт и вообще веб-фронтэнд как базовая технология для всех приложений снова уйдёт с первого места. Но с его корявостью и разбродом-шатанием веб-фреймворков даже в этой идиллии всё смотрится как-то косо-криво. Видно же, что технология с рождения уродская, не предназначенная для того, куда её сейчас применять пытаются.
Сейчас всё в вебе на Хромиуме
Я хоть и не из Веба, но что то слышал.
https://www.slant.co/versus/5226/5230/~mozilla-firefox_vs_...
Видно же, что технология с рождения уродская
Она просто другая и каждый вправе ее оценивать по своему.
как должен выглядеть веб?
Нужны еще тогда обязательно стандарты как должны выглядеть картины художников
А можно пояснить что имелось в виду?
Вот: https://youtu.be/hYpaVExfbu4?t=1909 и вот https://youtu.be/FJMsRCvMoEg?t=316
Дневник тяжелобольного инвалида
разве?
Всё я сам решил проблему:
using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
try
{
Interp i = null;
Interp i2 = null;
i = new Interp(@"C:\test\demo.int");
i2 = new Interp(@"C:\test\demo2.int");
i.Load(new Rect { x = 1, y = 1, width = 80, height = 10 });
i2.Load(new Rect { x = 1, y = 11, width = 80, height = 24 });
i.StepEvent += new Interp.StepEventHandler(Interrupt);
i2.StepEvent += new Interp.StepEventHandler(Interrupt);
i.Execute();
i2.Execute();
}
catch(Exception ex) {
Console.WriteLine(ex.ToString());
}
}
public static void Interrupt()
{
Console.WriteLine("Interrupt!");
}
}
}
Дневник тяжелобольного инвалида
Сорри, но все равно не понял. Для какой системы?
Для Windows.
Что бы в своем приложении сделать виртуальные окна системы? Что то типа расширения системы?
Ну да что-то вроде окон, только виртуальные области в окне PuTTY или Telnet, чтобы выполняла мои скрипты на сервере, и чтобы всё параллельно работало. Я уже сделал только что сам обработчик событий, при интерпретации каждой строчке срабатывает прерывание.
Дневник тяжелобольного инвалида
чтобы выполняла мои скрипты на сервере,
мне кажется вы смешиваете различные понятия в одну кучу.
Соединение с сервером по SSH - одна задача, удаленное выполнение команд, следующая.
Отображение взаимодействия - еще одна.
Тута были?
Всего лишь эту строку
Согласитесь, что просто куча мусора вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
d:DataContext="{d:DesignInstance {x:Type viewModels:SettingsPanelViewModel}}"
Я хоть и не из Веба, но что то слышал.
https://www.slant.co/versus/5226/5230/~mozilla-firefox_vs_...
Всё это туфта, и плевать, что там фрики в своих загончиках наголосовали. Бабло побеждает всё. Поэтому Мозилла с Фаерфоксом подыхает (хотя долго брыкается), а Хромиум будет жить. Поэтому Эдоуби с экшен скрипт и флеш отправляется на помойку, а джаваскрипт будет жить. Потому что за ним прямо или косвенно стояли Гугл и Эппл. В принципе, мог взлететь Сильверлайт, надо было лишь немного надавить и поддерживать давление лет 5, но тогда в МС были разброд и шатания, и правая рука не знала, что делает левая, поэтому они начинали и бросали разные штуки постоянно. Поэтому Сильверлайт с удобным сишарпом и Флеш с достаточно удобным экшен скрипт умерли, а корявый джаваскрипт, на котором без тайпскрипт нормально не поразрабатывать, будет жить. Бывшие флешевики до сих пор вспоминают удобные инструменты для быстрого создания всяких красивых и интерактивных штук и игр - на джаваскрипт до сих пор ничего подобного нет, всё надо из костылей от разных вендоров собирать и использовать сторонние библиотеки рендеринга на канвас.
мне кажется
потом позже отвечу
Дневник тяжелобольного инвалида
Согласитесь, что просто куча мусора вокруг этого всего
сорри но никак
буквочка "д" важна - это только для времени дизайна. Остальное тоже имеет смысл.
https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/ee839627(v=vs.100)
Потому что за ним прямо или косвенно стояли Гугл и Эппл... Поэтому Сильверлайт с удобным сишарпом и Флеш с достаточно удобным экшен скрипт умерли
ну чушь же, умерли потому что были громоздкие, медленные, не масштабируемые от слова "СОВСЕМ", еще и постоянно нужно плагин обновлять, и дыры в безопасности. "экшен скрипт" это вообще обновленная версия жаваскрипта которую забанил МС. Flash, сильвер для веба даже с трудом подходят, это просто костыли, максимум веселую ферму для одноклассников написать. Закладку не поставить, СЕО нулевое, поисковые машины там ничего не индексировали, грузить целиком весь swf. Java алеты бы еще вспомнили, то же ж клевая штука была ) даже с поддержкой 3D, правда заработает все, пока пользователю все мозги не вынести с установкой доп софта. Эти штуки были очень хороши для узкого ряда решений, но в целом для веба не годились.
а корявый джаваскрипт, на котором без тайпскрипт нормально не поразрабатывать, будет жить.
он корявый исключительно в корявых руках, чет за все время, что приходилось писать во фронте, ни разу тайпскрипт не понадобился, и все норм разрабатывается. Живет он потому что родился одновременно с браузером, и для браузера исключительно, и развивается параллельно с ним
инструменты для быстрого создания всяких красивых и интерактивных штук и игр - на джаваскрипт до сих пор ничего подобного нет
здрасти приехали, на жаваскрипте все интерактивности были еще со времен лохматых DHTML, работает на прямую с DOM, делай с ним что хочешь ) красивых интерактивных штук хоть отбавляй, да и большая часть из них вообще на css делается, жаваскрипт уже давно уехал в сторону бизнес логики больше. А если внедрять очередные навороченные инструменты, получатся те же грабли как и Flash - разработчикам различных браузеров, нужно будет все эти инструменты поддерживать. Они то и с css с трудом справляются, чтобы одинокого выглядело во всех браузерах
Поэтому Мозилла с Фаерфоксом подыхает (хотя долго брыкается)
с учетом что мозила есть нетскэйп, в котором и создали жаваскрипт, вряд ли по этому
Теперь попробуйте к этим молекулам через какой-нибудь Ангуляр или Реакт навесить через байндинги кучку свойств, событий, чтобы по кликам всплывали разные окошки
зачем? зачем использовать инструмент который совершенно не подходит к решению задачи, зачем забивать гвозди микроскопом )
Мозилла с Фаерфоксом подыхает
Сомниваюсь, хотя я не фанат файрфокса, из-за того что он медленно работает в Windows-е. У меня кнопочный телефон, там вроде файрфокс
Эдоуби с экшен скрипт и флеш отправляется на помойку.
Бывшие флешевики до сих пор вспоминают удобные инструменты для быстрого создания всяких красивых и интерактивных штук и игр
О да! Была крутая вещь, жаль что прекращают поддержку, хотя вроде бы Adobe Air и FlashDevelop можно до сих пор скачать и установить. У меня лично до сих пор стоит SwishMax 3 с флэшплеером от версии 4 то 10 помойму.
Дневник тяжелобольного инвалида
Согласитесь, что просто куча мусора вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
Согласитесь, что вы написали кучу мусорного текста вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
Согласитесь, что просто куча мусора вокруг этого всего. Важные вещи я выделил жирным, остальное - в помойку:
Сам по себе формат XML (и, кстати, JSON) в принципе избыточен. Я понимаю, что вы предпочитаете работать с INI, но даже там необходимо отделять разделы и необходим символ '='.
Потому что за ним прямо или косвенно стояли Гугл и Эппл... Поэтому Сильверлайт с удобным сишарпом и Флеш с достаточно удобным экшен скрипт умерлину чушь же, умерли потому что были громоздкие, медленные, не масштабируемые от слова "СОВСЕМ", еще и постоянно нужно плагин обновлять, и дыры в безопасности. "экшен скрипт" это вообще обновленная версия жаваскрипта которую забанил МС. Flash, сильвер для веба даже с трудом подходят, это просто костыли, максимум веселую ферму для одноклассников написать. Закладку не поставить, СЕО нулевое, поисковые машины там ничего не индексировали, грузить целиком весь swf. Java алеты бы еще вспомнили, то же ж клевая штука была ) даже с поддержкой 3D, правда заработает все, пока пользователю все мозги не вынести с установкой доп софта. Эти штуки были очень хороши для узкого ряда решений, но в целом для веба не годились.
Скоро придёт Антихрист! Покайтесь, неверные!
Будущее веба: станет ли рендеринг в <canvas> заменой DOM? / RUVDS.com corporate blog / Habr
Сам по себе формат XML (и, кстати, JSON) в принципе избыточен. Я понимаю, что вы предпочитаете работать с INI, но даже там необходимо отделять разделы и необходим символ '='.
Мозилла с Фаерфоксом подыхаетСомниваюсь
Года полтора-два ему осталось. От силы. Потом либо закроется. либо на Хромиум перейдёт. Опера гораздо круче была, но давно уже сдулась. А Фаерфокс просто сообщество "не таких как все" себе сообразил, но и оно уже рассасывается. Причём не то, чтобы они реально были в передовиках удобства и функциональности, как та же Опера была, а именно чтобы просто "не такие как все".
YAML
Ну во-первых, YAML тоже избыточен :)
Во-вторых, никаких особенных преимуществ по сравнению с XML я тут не вижу:
bindings: - {ircEvent: PRIVMSG, method: newUri, regexp: '^http://.*'} - {ircEvent: PRIVMSG, method: deleteUri, regexp: '^delete.*'} - {ircEvent: PRIVMSG, method: randomUri, regexp: '^random.*'}
и в XML:
<bindings> <binding ircEvent="PRIVMSG" method="newUri" regexp="^http://.*" /> <binding ircEvent="PRIVMSG" method="deleteUri" regexp="^delete.*" /> <binding ircEvent="PRIVMSG" method="randomUri" regexp="^random.*" /> </bindings>
Так себе выигрыш :)
А если сделать шаг дальше? Например такой XML:
<bindings> <httpBinding ircEvent="PRIVMSG" method="newUri" regexp="^http://.*" /> <whatEverBinding ircEvent="PRIVMSG" method="deleteUri" regexp="^delete.*" /> <randomBinding ircEvent="PRIVMSG" method="randomUri" regexp="^random.*" /> </bindings>
Как такая структура будет выглядеть в YAML?
YAML - какая-то высосаная из пальца хренотень, которая дает... ничего :)
НП. А я раньше так программировал , использовал HTML тэги и атрибуты в Java, наоборот меньше возьни с методами, и отрисовывает всё как надо:
import java.awt.*;
import javax.swing.*;
class Main extends JFrame {
public Main() {
setTitle("Test");
setSize(640, 480);
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
setLayout(new GridLayout(1, 0));
add(new JButton("<html><div style=\"border:1px solid red; background:blue; color:yellow; font-size:20pt; padding:20px 20px;\"><b>Test</b></div>"));
setVisible(true);
}
public static void main(String[] args) {
new Main();
}
}
Дневник тяжелобольного инвалида
YAML - какая-то высосаная из пальца хренотень, которая дает... ничего :)
YAML в разы быстрее парсится чем XML и не требует овердофига памяти для DOM. Те же преимущества и недостатки, что и у JSON.
А если бы у разработчиков JS был бы мозг и они умели бы читать, то мы бы жили без JSON. JS использовал бы YAML.
В экосистеме Явы YAML используется как замена .properties. У него два неоспоримых преимущества - в нём данные по дефолту в UTF-8 (а в пропертях iso-8859-1) и запись компактнее, удобнее читать.
YAML в разы быстрее парсится чем XML и не требует овердофига памяти для DOM.
-----
Об чем ты?
Даны два файла/потока с данными - один ЯМЛ, другой ХМЛ.
Почему-то один ты собираешься читать и парсить последовательно, а другой - грузить разом и создавать дополнительный набор данных...
И на этом основании заявляешь что одно хуже другого?!!
преимущества - в нём данные по дефолту в UTF-8
-----
Не вижу никакого преимущества.
Вижу - недостаток. Например, при экспорте из систем, где дальше EBCDIC
не продвинулись.
запись компактнее, удобнее читать
-----
Хи-хи...
Ну да - человеку чутка более удобнее...
Вот только проблема - чел на анализе 5-6 килобайта все одно сдохнет...
А для железа - почти пофиг - оверхед по ХТТП будет перекрывать разницу...
XML мастдай, За YAML и JSON будущее.
-----
Будущее за тем, где вместе с данными можно будет передать не только формат и разбивку на проперти, но еще и контроль доступа к данным, и некоторую функциональность для данных, исполняемую на клиенте без доп.телодвижений.
Что-то из упомянутого делалось в Жабе на рубеже веков, но или не получилось, или не пошло в массы...
YAML в разы быстрее парсится чем XML и не требует овердофига памяти для DOM.
Во-первых, это не преимущество YAML, а скорее недостаток конкретного парсера XML. В свое время, те, кто не хотел использовать DOM брали tinyxml и в ус не дули.
Во-вторых, кого в современном мире волнует память для DOM?
В-третьих, я не очень хорошо представляю себе проект, в котором скорость десериализации будет иметь какое-то более или менее серьезное значение. Возможно, что такие проекты есть, но даже в задаче "принять данные -> десериализировать -> сохданить данные в БД" об оптимизиции процесса десериализации я бы задумался в последнюю очередь.
А вот отсутствие стандартной возможности описать данные и валидировать их - серьезная проблема (в том числе и для JSON)
До тех пор, пока в YAML и JSON нет схемы и валидирования, эти форматы будут иметь довольно узкую область применения.
А эачем это нужно? Ну общается бек с фронтом, послал данные, в чем проблема-то? По типу названия фронт или бек распознали, что получили то, что надо. Что тут еще нужно? Я не спец в фронтах, я реально не понимаю, объясните, пожалуйста, на пальцах с реальным примером, чтоб я понял зачем такое надобно! Спасибо!
Что тут еще нужно?
-----
Нужно подтвердить, что не только название, но и содержимое соответствует.
На пальцах... пришел документ... в нем обязательны 20 позиций в записи...
По факту - где 20, где 15, где 30...
Валидация, до обработки, говорит - негоден.
Это тебе не базу править когда туда вбили 30 или 15 вместо 20...
пока в YAML и JSON нет схемы и валидирования, эти форматы будут иметь довольно узкую область применения
что значит узкую? json во всю торчит в вебе, веб это узкая область?
просто каждый формат имеет свою роль и предназначение.
Тем не менее для JSON есть и схема и валидирование. Хотя за частую JSON это просто средство доставки уже свалидированных и подготовленных данных с бэкэнда, бери и кушай
Я не спец в фронтах, я реально не понимаю, объясните, пожалуйста, на пальцах с реальным примером, чтоб я понял зачем такое надобно! Спасибо!
нужно если скармливать json сторонней API, для предвалидации например, по схеме чекнуть все и потом уже скормить. Потом сама API будет по той же схеме все еще раз проверять. Например https://aws.amazon.com/de/premiumsupport/knowledge-center/...
А эачем это нужно?
Для взаимодействия с разными вендорами.
Ну вот простейший пример - наше приложение обрабатывает входящие сообщения, нам из этого сообщения важны 4 поля, все остальные данные нас не интересуют. При этом есть несколько производителей оборудования, которые хотят отправлять нам сообщения. Какое решение? Мы делаем XSD и отправляем его вендорам. Очень удобно - мы делаем спецификацию и требуем ее исполнения.
Ну общается бек с фронтом, послал данные, в чем проблема-то?
Проблема в том, что бек и фронт зачастую делаются в разных командах и надо как-то договариваться о формате данных. Я уж не говорю о том, что данные существуют не только в вебе.
Меня. У меня бывают такие объемы ХМЛа, что обработать можно только чем-то типа сортировки слиянием...
Простейший пример - дифф и мерже - ну хотя бы а 100-200 mб...
Ну у тебя и код генерится шаблонами :) Давай по чесноку - твои задачи и броблемы сложно назвать типичными юз-кейсами ;)
веб это узкая область?
Это узкая специализация. В вэбе много чего делается, но веб - это довольно узкая область в программировании.
Тем не менее для JSON есть и схема и валидирование.
Есть и этих схем и валидатором ЕМНИП даже больше одной. И все они являются разработкой энтузиастов и требуют согласования. В мире XML такого бардака нет.
Прежде чем спорить стоит читать сообщения целиком.
"YAML используется как замена .properties"
Почему-то один ты собираешься читать и парсить последовательно, а другой - грузить разом и создавать дополнительный набор данных...
И на этом основании заявляешь что одно хуже другого?!!
Потому что кто-то не в курсе про все возможности XML. Включая XPath или idref. Часто без DOM не обойтись, SAX не хватает. Ну и парсить XML сложнее, даже SAX жрёт больше памяти и времени.
Вот только проблема - чел на анализе 5-6 килобайта все одно сдохнет...
Какой-то у тебя тупой человек. 5-6 килобайт это ну, пусть 200 коротких строчек. И "анализировать" их не надо - надо посмотреть парочку значений.
Вижу - недостаток. Например, при экспорте из систем, где дальше EBCDIC
Это исключительно твои проблемы. Хосты даже в немецких банках и страховках вымирают, и ориентироваться на них - верх тупости.
Ну и какбэ latin-1 тоже имеет свои проблемы при обмене с мейнфреймами. Короче садись, два. Высосанный из пальца недостаток не канает.
сложно назвать типичными юз-кейсами ;)
------
Как раз типичная ситуация на любом среднен и крупном предприятии...
Другой вопрос - чистые прикладники редко заморачиваются этими вопросами
Ибо для них производительность системы определяется количеством систем в кластере...
Какой-то у тебя тупой человек.
-----
Увы, но он такой и есть...
Часто без DOM не обойтись, SAX не хватает.
-----
Это - аргумент. Сильный. Правда в пользу ХМЛ. В силу того что ЯМЛ в дерево конвертируется сложнее.
И, кстати, не встречал задач, в которых нельзя обойтись без ДОМа.
А обратные - когда ДОМ не проходит уже приводил.
"YAML используется как замена .properties"
-----
Т.е. ты подтверждаешь, исходное что утверждение верно при размере ЯМЛа в 10 строк..
Как только потребуется что-то более крупное - придет полярная лисичка...
даже в немецких банках и страховках
------
Ты пропустил авиацию - там оно живее всех живых...
парсить XML сложнее
-----
Хи-хи...
Т.е. вот прямо так - сложнее парсить полностью размеченный документ...
Предлагается "упростить" процесс исключив из раметки маркеры окончания элемента...
Во-первых, это не преимущество YAML, а скорее недостаток конкретного парсера XML.
Не совсем. XML сложнее парсить. Так что и преимущества формата.
кого в современном мире волнует память для DOM
Ха-ха. Всех, кому приходят жалобы от клиентов, мол, открыл две ваших странички, и щё не работает. Смотрим - а хром сожрал все его 8 гигов памяти.
Потому что "программизды" тоже думали "а кого волнует память" и вхренячили 500 меговый xml. А чо? По локальной сетке, на десктопе с 32 гигами всё быстро работает.
В-третьих, я не очень хорошо представляю себе проект, в котором скорость десериализации будет иметь какое-то более или менее серьезное значение.
А зря. Год 2019. Смена формата с XML на JSON на одной страничке сэкономила нам около 10 секунд времени загрузки. Яваскрипт, понимаешь ли. Пора прекращать думать десктопами. ПО крайней мере на ближайшие 10 лет. Потом опять наверняка "откроют" что делать все приложения в браузере - тупо, надо улучшать установку модулей, станет модно уменьшать "сетевой футпринт", и может быть даже забудут жабаскрип как кошмарный сон, блин.
Да, в мире приложений для мобил XML тоже не канает. Уж слишком большой оверхед. Разница в размерах между представлением тех же самых данных в JSON и XML может быть 2-3х кратная.
Г5 эго здорово, но на GPRS принимать 500 кб или 200 очень ощутимо по времени.
А вот отсутствие стандартной возможности описать данные и валидировать их - серьезная проблема (в том числе и для JSON)
Добро пожаловать в мир будущего! JsonSchema вместо XmlSchema, OpenAPI как замена WSDL.
Что самое смешное, JSON выходил на сцену под кукареканье "свобода! чо хочу то и леплю! никаких скучных ошибок валидации! надо добавить 10 новых полей - добавляем!" Не прошло и 10 лет, как попугайчики стали перерисовывать XML Schema для своего JSON (и придумывать TypeScript для жабаскрипта).
Подводя итоги. И XML и YAML (и JSON как подмножество YAML) имеют свою нишу. XML сейчас "не секси", JSON - супермодель. Но однозначной замены той же автоматической валидации или приличной генерации кода из схемы ни для JSON ни для YAML нет. Даже для явы с генерацией кода из JsonSchema всё достаточно хреновенько. Есть что-то работающее, но как только начинается что посложнее юзера с именем и возрастом - лезут проблемы.
Для общения клиент-сервер сегодня я бы взял JSON. Сервер-сервер сравнивал бы JSON с XML.
ПыСы. Для котика - с z/OS мы общаемся через CICS и MQшные очереди JSON-овскими (ага, UTF-8) сообщениями. Хост справляется их перекодировать в UTF-EBCDIC или UTF-16.
Предлагается "упростить" процесс исключив из раметки маркеры окончания элемента...
На досуге почитай спецификацию XML. Откроешь для себя много интересного. И сравни её со спецификацией YAML. Или лучше JSON. Его ещё проще парсить.
Да даже разницы между аттрибутами и субэлементами нет. Потом как аттрибутов нет.
Проблема в том, что бек и фронт зачастую делаются в разных командах и надо как-то договариваться о формате данных. Я уж не говорю о том, что данные существуют не только в вебе.
Ну правильно, в JSON есть поля
{"AAA":{...},"BBB":{...},"CCC":{...}}
это на сколько идиотами должны быть разрабы в командах, если они не договорились, что будет лежать в форматах для AAA, BBB, CCC? Тут валидация адекватности разрабов важна, а не городить "прогграммирование ради программирования".
Все так и не понимаю для чего валидация нужна, кроме надуманных случаев когда команды друг другу создают проблемы. Может я все-таки что-то упустил и есть какой-то реально нужный пример?
Ну правильно, в JSON есть поля
{"AAA":{...},"BBB":{...},"CCC":{...}}
Ога. А есть совсем другой JSON в котором может быть 200 разных полей. Человеческим языком описывать что в каждом допустимо - легко выливается в документ страниц на 50-100. И кто ж его читать будет, пока молотком па пальцам не заставишь?
это на сколько идиотами должны быть разрабы в командах,
Намного, намного большими чем вы сможете себе вообразить. Передать 0 и 1 или WAHR / FALSCH вместо оговоренных true/false? Как два пальца. "А мы так привыкли", "а чо? Это тоже булевские значения"
Все так и не понимаю для чего валидация нужна, кроме надуманных случаев когда команды друг другу создают проблемы.
Слышали про принцип fail fast? Как считаете, проверять входящие данные в принципе нужно?
Ну и схема она не только про валидацию. Генерировать код можно, а не писать ручками. А можно генерировать тысячами правильные запросы, чтобы протестировать на нагрузку.
почитай спецификацию XML.
-----
Зачем повторять то что уже изучено?
Потом как аттрибутов нет.
-----
Где-то оно хорошо, а часто - вай-вай...
Одна из текущих задачек.
Есть несколько (миллионов) наборов шаблонов, каждый из которых работает со своими данными.
Клиент подготавливает и присылает данные в каких-то из (ему) известных форматов.
Задачка - выбрать набор шаблонов пригодных/доступных клиенту для решения его задачи
и трансформировать полученные данные в приемлемый для использования формат.
При этом Я не хочу что-либо писать руками более 1-го раза.
Ну так что будем пользовать - ХМЛ, ЯМЛ, ЖСОН?
П.С. Что Я слегка сменил заявленную целевую область Я вполне осознаю.
это на сколько идиотами должны быть разрабы в командах
-----
Да ни на сколько.
Неужели так сложно представить ситуацию, когда одна из сторон использует регламентированный инструмент и максимум что может - выполнить экспорт данных с его помощью. При этом не имея ни малейшего представления не только об том в каком формате будет выполнен экспорт, но и не понимая что форматы могут быть разными и зависят не только от действий оператора...
Ну это не считая того, что могут быть повреждения при транспортировке/трансформации.
Все так и не понимаю для чего валидация нужна
-----
В России у тебя спрашивают паспорт при покупке билета на паровоз.
Поверь - ни один шахид нацеленный на подрыв поезда не понимает зачем нужно предъявлять паспорт при покупке билета...
Да ни на сколько.
Если есть сомнения в протоколах и форматах - надо проверять консистентность данных до начала использования. Если нет, то зачем этот огород-то? Вся эта возня - это программирование ради программирования.
Единственный еще хоть как-то притянутый за уши вариант - проверка того, что генерилось с помощью автоматического написания, если, например, AI прочитал текстовую спецификацию, и послал ответ как смог и все это - в реальном времени, хотя, ИМХО, это просто надо отладить и только потом использовать.
PS: у меня в аппаратуре 11 различных типов ембеддед процессоров, серверов и архитектур с довольно сложной топологией общаются именно JSON ом, иногда бинарным, причем так, что иногда один юнит должен послать другому через третий, и как-то никогда не возникало нужды делать такую
валидацию, но да, всегда следил, чтобы все, кто это разрабатывают, придерживались одной и той же документации и спецификации и, где надо, стояли конверторы если спецификации отличаются. Проблемы с потерями данных всегда разруливались по аналогии с CRC, в некоторых случаях с избыточными кодами с возможностью для восстановления.
надо проверять консистентность данных до начала использования.
-----
Внешний источник априори не является надежным.
Внутренний - лучше, но тоже не гарантирован.
Так что данные перед использованием надо проверять.
И мне вот интересно как ты будешь "проверять консистентность данных" которые тебе будут поставляться после окончания разработки.
Ну вот написал ты обработку. Все работает. А билли - накатил апдейт и поменял формат. Без уведомления, без новой спецификации.
Ну вкачал ты данные... много вкачал... месяц-другой вкачивал... потом вылезло что что-то где-то выглядит не так как ожидалось.
Ну как - будешь это разгребать или лучше получить отлуп сразу после апдейта?
и как-то никогда не возникало нужды
-----
Нда... упорный...
Валидация это не когда все работает.
Валидация это когда отлавливается источник проблем до того как проблемы возникнут.
Нужно тебе это или тебе это не нужно - это уже твои заморочки.
Для меня валидация, если есть возможность отвалидировать данные со стороннего источника, - благо, предупреждающее возможные проблемы.
и как-то никогда не возникало нужды делать такую валидацию
ну и что будет если какой-то новый прибор по ошибке пошлет в старый не те данные? чет не хотел бы я таким пользоваться )
надо проверять консистентность данных до начала использования
ну и какой в этом смысл, ну проверил я на клиенте, все нормально, отправляю на сервер, потом вдруг окажется что не так проверил, мягкое с теплым сравнивал, а нужно было разноцветное с квадратным. Или вообще бэкэнд обновился, а на клиенте одну функцию которая после дождика в четверг вызывается, забыли обновить, и что теперь, на сервере без проверки что-то использовать?
А билли - накатил апдейт и поменял формат.
я уже писал выше, если данные не надежны, в чем проблема их распарсить и проверить то ли пришло, или нет.
Но начерта эту проверку притягивать в синтаксис JSONа или аналогичных фоматов, ибо проверку в общем случае все равно сделать невозможно, а костыли в синтексисе только создадут рабочие места для быдлокодеров, которые с пеной у рта будут рапортовать начальству, что они все автоматически валидируют, а на поверку, все будет сыпатся не через месяц, а через год, но, еще больнее.
на столько узкая, что основной поток вакансий это веб ) уот и сравнение, по рынкам
Ты понимаешь, что даже если в вебе будет 90% вакансий, это все равно ниша? И при этом довольно узкая ниша. Посмотри даже на свою картинку, веб там - это одина из девяти областей.
PS: бэк-энд далеко не всегда связан в вебом.
Не совсем. XML сложнее парсить. Так что и преимущества формата.
Не знаю, почему XML должен быть сильно сложнее JSON'а. Но возможно у тебя больше опыта в распарсивании текста...
Ха-ха. Всех, кому приходят жалобы от клиентов, мол, открыл две ваших странички, и щё не работает. Смотрим - а хром сожрал все его 8 гигов памяти.Потому что "программизды" тоже думали "а кого волнует память" и вхренячили 500 меговый xml. А чо? По локальной сетке, на десктопе с 32 гигами всё быстро работает.
Боюсь, что 500 меговый JSON или YAML точно также поставит систему раком. Тут проблема не в формате.
Смена формата с XML на JSON на одной страничке сэкономила нам около 10 секунд времени загрузки. Яваскрипт, понимаешь ли.
Не понимаю. На чем была экономия? На парсинге? На передаче? Это ж сколько надо передавать, чтобы парсер больше 10 секунд работал? 500Мб? :)
Пора прекращать думать десктопами.
Я в веб пока что не суюсь :)
Добро пожаловать в мир будущего! JsonSchema вместо XmlSchema
Я даже пробовал это использовать. Но был послан вместе с готовой схемой с аргументом, что это нестандартизированное нечто и надо договариваться с другими командами об использовании именно этого инструмента
:)
Ну правильно, в JSON есть поля{"AAA":{...},"BBB":{...},"CCC":{...}}
Проблема в том, что AAA обязательно должно присутствовать и значение должно быть числовое, BBB - опциональное поле и тип строка, но не больше 100 символов, CCC - обязательное поле и перечисление, а есть еще DDD - bool и еще 100 других полей. Можно конечно все это описать в PDF, но кто их читает? ;) Я уж не говорю о контроле, т.к. в какой-то момент команда A решает, что поле BBB теперь обязательное, рассылает всем PDF и валидуруй каждое поле в кучном режиме :)
это на сколько идиотами должны быть разрабы в командах, если они не договорились, что будет лежать в форматах для AAA, BBB, CCC? Тут валидация адекватности разрабов важна, а не городить "прогграммирование ради программирования".
Ну вот мы например фирма в Германии даем спецификацию фирме в Японии. Мы друг с другом вообще не разговариваем, в лучшем случае диалог есть при посредничестве клиента. В хорошем варианте, клиент передаст нам е-мыл другой конторы и мы сможем запросить их спеки и отправить свои. Но обычно мы даем спеки клиенту, а клиент пересылает их дальше. Так что никаких договоренностей в большинстве случаев нет.
Да и в пределах одной фирмы договоренности есть далеко не всегда. Кто-то просто предоставляет интерфейс и все.
Все так и не понимаю для чего валидация нужна, кроме надуманных случаев когда команды друг другу создают проблемы. Может я все-таки что-то упустил и есть какой-то реально нужный пример?
XSD файл - это контракт (в терминах C# это интерфейс) по которому общаются (программно) несвязанные меджу собой модули. Имея на руках XSD ты всегда можешь проверить соответствует ли твой код заданному контракту. Если два модуля не работают друг с другом, то всегда можно определить почему. При этом определить можно в автоматическом режиме.
-----
Уточни, плс, что именно и как ты собираешься проверять?
И второй вопрос - как именно ты собираешься сегодня написать проверку для того что тебе дадут завтра или через год или через пятилетку и в проекте исходники которого тебе не даюt?
Касательно ямл и его валидации - можно юзать чужие схемы валидации для ямла
xsd - YAML Schema Validation? - Stack Overflow
В ямле удобно хранить данные - куда как более читаемо и меньше размер. Не раз уже встречал ямл как основной формат для хранения данных довольно больших размеров (десятки килобайт).
В Unity префабы хранятся в ямл - пример части файла ниже. Представьте, как это было бы всё нечитаемо, если бы XML-тегами всё было обрамлено.
Меня, например, всегда напрягала многословность разметки в XAML (WPF, UWP, Silverlight) по сравнению с CSS. Описываешь стили там и там - в XAML какое-то бешеное накручивание специальных значков. Сделали бы описание интерфейса в Дотнете на основе ямл или хотябы джейсон.
1) В XML все эти параметры можно записать в виде аттрибутов. Я понимаю, что это не итак интересно для сравнения :)
2) В XML можно отобразить такую структуру:
<Servers>
<HttpServer name="..." ... />
<FtpServer name="..." ... />
<SomeOtherServer name="..." ... />
</Servers>
Продемонстрируй, как такая структура будет выглядеть в YAML?
Меня, например, всегда напрягала многословность разметки в XAML (WPF, UWP, Silverlight) по сравнению с CSS. Описываешь стили там и там - в XAML какое-то бешеное накручивание специальных значков. Сделали бы описание интерфейса в Дотнете на основе ямл или хотябы джейсон.
Ну вот простенький XAML:
<Grid>
<Grid.RowDefinitions>
<RowDefinition />
<RowDefinition Height="33" />
</Grid.RowDefinitions>
<TextBox Grid.Row="0" TextWrapping="Wrap" AcceptsReturn="True" Text="{Binding MessageTemplates, Converter={StaticResource ObservableCollection2StringConverter}}" />
<Grid Grid.Row="1">
<Grid.ColumnDefinitions>
<ColumnDefinition />
<ColumnDefinition />
<ColumnDefinition Width="100" />
</Grid.ColumnDefinitions>
<CheckBox Grid.Column="0" Content="Convert to HEX" IsChecked="{Binding ConvertToHEX}" Margin="5" VerticalAlignment="Center" />
<CheckBox Grid.Column="1" Content="Open in Explorer" IsChecked="{Binding OpenExplorer}" Margin="5" VerticalAlignment="Center" />
<Button Grid.Column="2" Content="Generate" Command="{Binding Generate}" Margin="5" VerticalAlignment="Center" />
</Grid>
</Grid>
покажи как бы такая структура выглядела бы в YAML. Чтобы было проще, названия аттрибутов с точкой можешь считать как одно слово.
В ямле удобно хранить данные - куда как более читаемо и меньше размер.
------
Наименьший размер данных будет у файла в котором нет избыточной информации - имен полей, разделителей и т.п.
Для машины - без разницы насколько он читаемый.
А для человека в любом случае нужен подходящий инструмент. Потребовать чтобы он представлял данные в удобоваримом виде - не проблема.
как это было бы всё нечитаемо, если бы
------
Угу... вот только один моментик - ссылка небольшой ХСЛТ добавленная в ХМЛ предоставит точно такое же вью... все в рамках стандартов.
А что и куда надо добавить в твоем варианте Я не знаю.
2) В XML можно отобразить такую структуру:
<Servers> <HttpServer name="..." ... /> <FtpServer name="..." ... /> <SomeOtherServer name="..." ... /> </Servers>Продемонстрируй, как такая структура будет выглядеть в YAML?
Это зависит от того, какие объекты вы сериализуете в XML. Скорее всего, они же и в YAML прекрасно сериализуются. Тут, как я понял, коллекция серверов разных типов - значит, скорее всего, эта коллекция хранит элементы некоего базового типа, к которому приводятся унаследованные от него производные типы серверов. В YAML нельзя хранить базовые типы или инфу о конкретном типе элемента в коллекции?
Я, если что, не спец по форматам - просто мне нравится, как выглядит YAML. У XML недостаток в синтаксисе - слишком много условных значков и лишние закрывающие теги - всё это сильно снижает читаемость.
Ну вот простенький XAML:
<Grid> <Grid.RowDefinitions> <RowDefinition /> <RowDefinition Height="33" /> </Grid.RowDefinitions> <TextBox Grid.Row="0" TextWrapping="Wrap" AcceptsReturn="True" Text="{Binding MessageTemplates, Converter={StaticResource ObservableCollection2StringConverter}}" /> <Grid Grid.Row="1"> <Grid.ColumnDefinitions> <ColumnDefinition /> <ColumnDefinition /> <ColumnDefinition Width="100" /> </Grid.ColumnDefinitions> <CheckBox Grid.Column="0" Content="Convert to HEX" IsChecked="{Binding ConvertToHEX}" Margin="5" VerticalAlignment="Center" /> <CheckBox Grid.Column="1" Content="Open in Explorer" IsChecked="{Binding OpenExplorer}" Margin="5" VerticalAlignment="Center" /> <Button Grid.Column="2" Content="Generate" Command="{Binding Generate}" Margin="5" VerticalAlignment="Center" /> </Grid> </Grid>покажи как бы такая структура выглядела бы в YAML. Чтобы было проще, названия аттрибутов с точкой можешь считать как одно слово.
Я не знаю как точно - не знаком подробно с ситнаксисом YAML. Ну примерно так (очень приблизительно):
Grid
Rows:
- Row
Row
Height:33
TextBox
GridRow:0
TextWrapping:wrap
AcceptsReturn:true
Text
Binding
Path:MessageTemplates
Converter
StaticResource:ObservableCollection2StringConverter
Grid
GridRow:1
Columns:
- Column
Column
Column
Width:100
CheckBox
GridColumn:0
Content:Convert to HEX
IsChecked
Binding
Path:ConvertToHEX
Margin:5
VerticalAlignment:Center
Ну и т.д.
Насколько я понимаю, запись данных что в тегах, что в атрибутах равнозначна. Просто в атрибутах пишутся простые данные, а в тегах - сложные, составные. Но в любом случае это всё свойства представляемого объекта. Просто если данное больше не делится - является элементарным типом, то его можно в атрибут поместить. А если охота его расписать - то через вложенные теги.
В YAML нельзя хранить базовые типы или инфу о конкретном типе элемента в коллекции?
Это ты у меня спрашиваешь? :) Ты же пропагандируешь YAML. Вот и скажи ;)
Ну и т.д.
Ты же понимаешь, что 18 строк XAMLа ты перевел в 29 строк (не полностью, а полностью было бы 44 строки) на YAML? По-твоему это как-то улучшило читаемость? И тебе не кажется, что это как-то не очень соотносится с "легковестностью" YAMLа?
Это ты у меня спрашиваешь? :) Ты же пропагандируешь YAML. Вот и скажи ;)
А я думал, это мне тут объяснят - тут же типа опытные собрались. )))
Я в нём не разбираюсь, я увидел несколько раз его использование в реальных проектах, почитал, в чём некоторые отличия, но в глубину не копал.
Мне вообще как программисту в нём разбираться особо и не нужно - дайте мне сериалайзер-десериалазйер и нормальный АПИ к нему - больше мне ничего не нужно. Нафига мне лезть в чёрные коробочки, если они (если!) будут нормально работать?
Ты же понимаешь, что 18 строк XAMLа ты перевел в 29 строк (не полностью, а полностью было бы 44 строки) на YAML? По-твоему это как-то улучшило читаемость? И тебе не кажется, что это как-то не очень соотносится с "легковестностью" YAMLа?
Не в строках дело, а в объёме текста, количестве служебных значков, которые все только мешают воспринимать основную информацию. У вас в XML или XAML просто строки длинные - из каждой надо выхватить несколько кусков инфы, очистив её от служебных слов и закорючек. Ямл сразу охватываешь взглядом почти всю страницу и быстро находишь, что нужно. А XML или XAML сначала "парсишь" глазами и головой. Открывая документ XML или XAML на всего лишь одну страницу, мне проще воспользоваться полнотекстовым поиском, чтобы найту нужное слово, а в ямл проще и быстрее глазами. Это если не впадать в крайности.
XML или XAML тоже могут быть достаточно читаемыми - тогда тоже придётся много строчек использовать - каждый атрибут на новой строке. Вот у вас, например, слишком длинная строка получилась и приходится форум горизонтально прокручивать. Но просто посмотрите, сколько лишней инфы находится в типичном XML или XAML при хорошей такой иерархии вложенностей
<DockPanel.Triggers>
<EventTrigger
RoutedEvent="DockPanel.MouseEnter">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation
Duration="0:0:0.100"
To="1"
Storyboard.TargetName="descriptionButton"
Storyboard.TargetProperty="Opacity" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
<EventTrigger
RoutedEvent="DockPanel.MouseLeave">
<BeginStoryboard>
<Storyboard>
<DoubleAnimation
Duration="0:0:0.100"
To="0"
Storyboard.TargetName="descriptionButton"
Storyboard.TargetProperty="Opacity" />
</Storyboard>
</BeginStoryboard>
</EventTrigger>
</DockPanel.Triggers>Блин, подсветки нет. Вот с подсветкой видно (фиолетовый цвет), что на всю кучу инфы всего несколько значений, которые важны и нужно прочитать. Полезность текста в XML или XAML где-то процентов 20-30, остальное - мусор.
Как вы сюда код вставляете с моноширинным текстом и сохранением форматирования (отступов и прочего)?
каждый атрибут на новой строке.
Это ужасно :)
Блин, подсветки нет. Вот с подсветкой видно (фиолетовый цвет), что на всю кучу инфы всего несколько значений, которые важны и нужно прочитать. Полезность текста в XML или XAML где-то процентов 20-30, остальное - мусор.
Полезность не 20-30 процентов ;) Фиолетовый - это только значения, однако имена соответствующих значений тоже важны (и они точно также есть в YAML ;) )
Вся экономия заключается в YAML
GridColumn:0
против в XML
GridColumn="0"
этономия ровно 2 символа :D
А если взять закрывающие тэги, то YAML накладывает ограничение в том, чтобы данные были вывовнены по границе объекта, к которому они принадлежат. Так что съекономили на закрывающем тэге и в 10 раз больше потратили на <TAB> :D
Ну и текстик в 44 строки не так то уж просто прочитать :)
Как вы сюда код вставляете с моноширинным текстом и сохранением форматирования (отступов и прочего)?
1) Нажимаешь кнопку "<>" (рядом с Bold)
2) пишешь текст в блоке <pre></pre>
каждый атрибут на новой строке.Это ужасно :)
Я не могу нормально читать ваши атрибуты, написанные кучей в одну строку. И когда у вас пустых строк нет между хотя бы блоками вложенностей тегов - типа коллекцию элементов RowDefinitions отделить сверху и снизу пустой строкой. Когда атрибуты каждый на своей строке, то можно и не отделать - вполне и так читаемо. Но когда всё в куче, то хотя бы пустые строки помогли бы. У вас там на экране места мало, чтоли? Я думал, уже у всех стоят минимум 2 моника на 32 дюйма хотя бы 2560х1440. ))
Но это не проблема, если есть автоформатирование при открытии файла. Открываю вашу разметку у себя - автоформат под мои требования. У всех нормальных IDE это давно идёт из коробки.
Полезность не 20-30 процентов ;) Фиолетовый - это только значения, однако имена соответствующих значений тоже важны (и они точно также есть в YAML ;) )
Das ist schon dazu gehört. Я уже прикинул имена тегов в эти 20-30%.
Ямл лучше тем, что просто пустое пространство, которое в Ямл изобилует, гораздо лучше воспринимается и не отвлекает, чем это же пространство, забитое всяким мусором.
Заметьте, как в Ямл хорошо читаются даже тексты без подсветки. В XML без подсветки чёрт ногу сломит.
Так что съекономили на закрывающем тэге и в 10 раз больше потратили на :D
Все табы проставляются автоматически, как и каретки выравниваются при переходе на новую строку - как в XML, так и в YAML. Если нужно начать новый объект и автопростановка поставила слишком много табов - убираешь табы бэкспейсом. Это происходит и в XML, и в YAML редакторах.
Ну и текстик в 44 строки не так то уж просто прочитать :)
Внимание расходуется не на количество строк, а на количество слов и символов, которые нужно "распарсить" головой.
Скука, как же повезло инглишьменам - не надо постоянно язык переключать, когда говорят о своих технологиях!
1) Нажимаешь кнопку "<>" (рядом с Bold)
2) пишешь текст в блоке <pre></pre>
Т.е. я должне вручную напечатать эти теги, да ещё как-то догадаться, что это надо сделать в режиме "<>". И всё равно подсветки не будет? "Гений ты Моцарт, и шутки у тебя гениальные." https://youtu.be/GUKdwYBi9Rs?t=184
А XML или XAML сначала "парсишь" глазами и головой.
-----
Это аккурат следует из:
Мне вообще как программисту в нём разбираться особо и не нужно
Выше Я писал - в ХМЛ достаточно втиснуть ссылку на ХСЛТишку и можно получить нужную трансформацию.
Правда чтобы это сделать... или хотя бы знать об такой возможности, об "особо и не нужно" надо забыть.
Ну что, будущее дотнета в области UI - MAUI и Blazor? Остальное можно "забывать"? Готовишься сейчас, а через годик-другой - бум вакансий по MAUI и Blazor?
.NET Multi-platform App UI (.NET MAUI)a cross-platform UI toolkit announced in May 2020 that originated as a fork of Xamarin.Forms and that can run on Android, iOS, Linux, macOS, Tizen, and Windows. .NET MAUI will run on .NET 6 and later.[25][26][27] The source code is licensed under MIT License and available on GitHub.[28]Blazora free and open-source web framework that enables developers to create Web apps using C# and HTML. Blazor Server apps are hosted on an ASP.NET Core server in ASP.NET Razor format, while Blazor WebAssembly apps are Single-page apps that are downloaded to the client's web browser before running.
https://en.wikipedia.org/wiki/List_of_.NET_libraries_and_f...
Создал консольный проект на Дотнет 5 - часть файлов конфигов на джейсоне. Только конфиг проекта на XML. Похоже, Студия тоже постепенно переезжает на джейсон. ASP.NET MVC конфиги так уже давно на нём.
XML должен умереть. Кто согласен? ))
А в Unity3D наоборот решили новый UI делать на XML,HTML-образном синтаксисе. Да что ж такое-то!..
Overview | UI Builder | 1.0.0-preview.14 (unity3d.com)
Пришло время избавиться от Angular и сэкономить миллиарды долларов / RUVDS.com company blog / Habr
Скоро до Реакта дойдут и далее по списку.
Пришло время избавиться от Angular
Автор имхо не прав. Он фронтэндовыкий разработчик с опытом и не понимает некоторых проблем на фирмах, где недостаток разработчиков с опытом чистого ява-скрипта
Автор не понимает, что люди, годами писавшие на той же яве очень тяжело переходят на ява-скрипт. Очень тяжело. На нашей фирме мы начали именно с этого. И столкнулись с рядом проблем. Проблема современного программирования не в том, что бы писать легкий и изящный код. Это никому не нужно. Основная задача - это индустриальный процесс, конвейер. И если звезда напишет охрененно классный код, который никто не сможет понять и потом сопровождать, то код рано или поздно выкинут.
Ангуляр оказался для нашей группы довольно неплохой альтернативой. Там все логично и понятно. Код тоже структуирован и понятен. Код легко поддерживается всеми программистами. Таким образом ангуляр съэкономил фирме кучу денег
А основноя проблема в этом:
то я не знаю о том, почему разработчики браузеров до сих пор не добавили в них поддержку SCSS в виде стандартного механизма для работы с CSS-кодом, но это — отдельная тема.
Именно это - современные браузеры работают с какой то мамонтовой хренью, на которой многие просто избегают писать. Отсюда куча фреймфорков, которые :
То же самое касается и любых других JavaScript-библиотек или фреймворков, код которых, в итоге, тоже компилируется в обычный JavaScript.
Автор не понимает, что люди, годами писавшие на той же яве очень тяжело переходят на ява-скрипт.
Ну да, тяжело деградировать. Деградировать, и осознавать это. Осознавать, что из-за корявого джаваскрипта, на котором пытаются писать большие приложения, приходится изобретать способы программирования как на нормальных ООП-языках, но уродливые и кривые. Т.е. тебе как бы пытаются вернуть твои же джаву или сишарп, только хуже и обмазанные костылями, которые плохо скрывают недостатки, зато жрут ресурсы и память. Тяжело осознавать, что раньше ты тесял брёвна остро заточенным топором и пилил их пилой, а теперь надо - перочинным ножиком, и то тупым. А что такого? Вот раньше мы, когда были детьми, ковыряли этими ножичками мелкие сайтики - всё же работало. А теперь нужно ими же выстругать и обтесать брёвна для дома и вообще дом построить - давайте наденем на ножички разные удлиняющие и заостряющие насадки и бросимся в бой!
Ангуляр оказался для нашей группы довольно неплохой альтернативой. Там все логично и понятно. Код тоже структуирован и понятен. Код легко поддерживается всеми программистами. Таким образом ангуляр съэкономил фирме кучу денег
Вот Ангуляр такой хороший, а от него уже начинают отказываться и следующий проект будут делать на какой-нибудь новомодной фигне. При попытке сопротивляться, тебе скажут, что ты закостенел и не хочешь учиться. Надо на следующие вакансии набирать молодых и зелёных, которым не с чем сравнивать и они не знают, как бывает лучше.
Вот Ангуляр такой хороший, а от него уже начинают отказываться и следующий проект будут делать на какой-нибудь новомодной фигне.
У нас нет. Я не знаю, какой дебил так делает, но от работающего инструмента нужно отказываться только если он перестает работать. Я не вижу никаких новых проблем с ангуляром, проблем, которые всплыли после того, как мы начали его использовать. Новый инструмент означает, что нужно во первых переучивать команду, а во вторых поддерживать ОБА инструмента для старых проектов. Это снижает и время вхождения в проект и стоимость и вообще нафиг никому не надо.
Я не вижу никаких новых проблем с ангуляром
То бишь если бы теперь тоже был выбор тоже Ангуляр или что то другое?
И речь идет о всём своем или сторонняя либа с поддержкой Ангуляра типа этого https://js.devexpress.com/?
Если бы выбор был сейчас, то как и тогда, провели бы исследование. В списке основных требований - фреймворк должен быть распространенным и решение проблем можно было бы легко найти. Должна быть нормальная документация и литература по обучению. Я не слежу за новинками фронтэнда, но коней пока менять рано. На нормальной крупной фирме должно быть запрещено писать проекты на новых технологиях без особой на то причины
Вот Ангуляр такой хороший, а от него уже начинают отказываться
никто вроде пока не собирается, афтер статьи несет феерический бред, у него полностью отсутствует понимание архитектуры проекта и менеджмента... он там кичится, что напишет свой JS UI c блэк жеком и шлюхами, но только у него ноль понимания, что поддерживать этот UI кроме него самого будет не кому. Если каждый будет писать на чистом js, что ему вздумается, то любой проект загнется быстрее чем покажет какой-то там результат.
Назовите хоть один js-фреймворк, который прожил бы более 10 лет и оставался в топе 5 используемых фреймворков? Примерно такое время нужно, чтобы технология или фреймворк появились, раскрутились и появилось достаточное количество спецов с большим опытом по этому.
Программирование для веба напоминает жизнь насекомых или даже бактерий - ярко, быстро, бессмысленно. Каждый день или неделю - новое поколение. Живущие год - долгожители.
js фреймвокри как таковые появились то всего 10 лет назад, до этого были просто библиотеки облегчающие жизнь, jQuery популярен до сих пор.
Уже вроде много раз упоминали, что веб быстро меняется, еще 10 лет назад никому особо в голову не приходило делать весь UI с логикой в браузере, пыхтели каждый в своих jspшках с <% %> потом возрадовались jstl потом еще викет подвезли... в дотнетах там что-то похожее было, пхп тож не далеко ушел, про питон, руби я не в курсе. Все это тоже постоянно менялось, развивалось, загибалось. Так что особой разницы я не вижу. Просто была фаза когде веб собирали на сервере, теперь это делают напрямую у клиента. Может со временем какой-то из фреймворков проявит себя лучше всех остальных, и его просто стандартизируют, и сделают частью каждого браузера.
Если бы выбор был сейчас, то как и тогда, провели бы исследование.
Кстати об исследованиях. Оказывается gwt ожил. Я думал всё, после 2.8.2 новых релизов уже не будет, а они 2.9.0 в прошлом году с поддержкой 11-й явы (вернее даже на 14й компилируется) всё же выпустили. Явистам на нём попроще чем с ангуляром.
Явистам на нём попроще чем с ангуляром.
Но есть 2 проблемы. Во первых "всё же выпустили" пугает. Типа как пациет все таки дернулся и непонятно, это агония или он еще дышет.
Во вторых в gwt то, что пишут программисты все таки очень далеко от того, что получается на выходе для браузера. Получается, что соскочит с gwt нельзя. Альтернативы, близкой по концепту, нет(я не знаю, что там с ваадином, но тоже вроде как не...). Если всплывут проблемы например с производительностью или компонентов перестанет хватать, то все.
Ангуляр при всех недостатках все таку реализует основную идею - инкапсулирует компонент, но основные принципы у него как и у нативного яваскрипта. Соскочить на другой фреймворк все же проще.
Во первых "всё же выпустили" пугает. Типа как пациет все таки дернулся и непонятно, это агония или он еще дышет.
Если бы это не пугало с gwt и не уходил бы никто...
Альтернативы, близкой по концепту, нет(я не знаю, что там с ваадином, но тоже вроде как не...).
ваадин копирует gwt чуть более чем полностью. До 7 (или 8й?) версии ваадин был надстройкой над gwt. Похабной "всё-в-одном, даже если тебе это нафиг не надо" надстройкой.
Ангуляр при всех недостатках все таку реализует основную идею - инкапсулирует компонент, но основные принципы у него как и у нативного яваскрипта. Соскочить на другой фреймворк все же проще.
А вот тут бааальшая ошибка. Не проще. Всё равно всё переписывать. Даже хуже. Переход с gwt на angular 2 прошёл быстрее, потому как вся серверная часть проекта осталась как была. При переходе с angularJS на 2-й пришлось переписывать всё. Концепт изменился, понимать надо.
потому как вся серверная часть проекта осталась как была.
Какой сервер? У нас ангуляр отвечает только за фронт. Это означает, что построенный код можно запускать под любым веб. Сервером. Апачем. Томкэтом. И ещё сотней других Это только нтмл+яваскрипт. И это значит, что эту часть мы можем заменить чем угодно. Например спринг МВС. Или чистым яваскриптом.
И да. Angular JS я не застал. Мы сразу с 2 начали.
Сервер в контексте ангуляра это nodejs. Единственно правильная технология (по логике ангуляристов и других явашкрыптеров). Мы говорим ангуляр понимаем nodejs. :)
На самом деле, конечно, не важно на чём я пишу серверную часть. Из ангуляра я просто общаюсь с сервером.
Кстати, тут у соседей недавно со 2-го на 8й ангуляр народ переходил. В воздухе полгода висел густой мат :)
Когда что-то новое делают, берут нод. Чтобы "проект на одном языке" (нафиг надо - непонятно. Всё равно фронтендеры проблемы бэкенда редко понимают, и наоборот).
Когда прикручивают новый гуй к старому проекту, остаётся что было. Хотя... Несколько раз "прокладку" на ноде делали. Anticorruption layer. Чтобы меньше от старого зависеть. А ещё есть модные штучки вроде google firebase, тут без нода никуда (вернее можно, но тогда надо выходит за рамки firebase).
Война остроконечников с тупоконечниками. Особенно в комментираиях.
Понравилось выражение оттуда - "обезьяна с методикой". Это наверное про фанатов TDD. )))
Нужно всех посадить за написание тестов, а код должен генериться по тестам сам, с помощью каких-нибудь умных утилит. Развелось программистов, не желающих покрывать всё тестами. Их нужно, конечно, всех уволить, а набрать написателей тестов. Тесты должны стоять во главе угла, заменять документацию и собственно сам код. Вообще, нужен язык программирования, основанный на тестах. Ну как в хороших ООП-языках (C#) нельзя строчки кода написать вне класса, так то же самое и тут, только ни строчки кода вне теста.
На одном проекте лет 5 назад пришлось столкнуться с ситуацией, похожей на описанной автором статье: в проекте было близкое к 100% покрытие unit-тестами и ноль интеграционных и функциональных, причем TDD-адепты были категорически против их написания.
Доходило до абсурдных ситуаций, когда нерабочий код вливали в релиз-бранч, причем настолько нерабочий, что приложение даже не запускалось (sic!) - выяснялось, что TDD-адепты никогда не запускали приложение перед влитием ветки в релиз-бранч(sic!!), а обходились запуском юнит-тестов.
Когда впоследствии TDD-адепты не могли обеспечить 100% ковераж чистыми юнит-тестами, в ход шли моки, фейки и стабы в настолько невероятном количестве, что юнит-тест фактически тестировал только мок-машину, а само приложение только прирастало багами, не говоря уже об уродовании кода ради удобства моков
Вот пытаешься устроиться куда-то на работу - "вы нам не подходите, у нас тут всё серьёзно, а у вас язык плохой и опыта маловато, да и места работы какие-то...". А где-то годами устраивают такой вот цирк, как выше, наверняка убытки в десятки миллионов евро, и нормально - потом чел оттуда выходит и пишет в резюме, что работал над суперкрутой системой в каком-нибудь банке, офигенный специалист с офигенным опытом.
Ваши абстракции текут, как самка собаки по весне.
Оказывается, все учат друг друга, как правильно готовить ТДД, но никто при этом это не умеет и не следует своим же рекомендациям.
Про BinaryFormatter. Что за фигня? Понавтыкали красно-жёлтых плашек - unsecure, obsolete и всё такое:
BinaryFormatter.Serialize Method (System.Runtime.Serialization.Formatters.Binary) | Microsoft Docs
BinaryFormatter security guide | Microsoft Docs
Теперь, чтобы что-то компактно сериализовать, только свою сериализацию через BinaryWriter/Reader писать? Т.е. каждый объкт руками по всем элементарным свойствам в бинарный вид переводить? Ну и, соответственно, вообще весь граф типов в иерархии наследования, если там подобные сериализуемые типы? BinaryFormatter вроде автоматически работал и всё это сам делал? В чём разница тогда - я буду руками в коде всё перебирать, или готовый класс как-то автоматом (через рефлексию?) это сделает?
https://docs.microsoft.com/en-us/dotnet/standard/serializa...
только свою сериализацию через BinaryWriter/Reader писать?
https://docs.microsoft.com/en-us/dotnet/core/compatibility...
Recommended action
- Stop using BinaryFormatter in your code. Instead, consider using JsonSerializer or XmlSerializer.
Это всё не компактно. Если хочешь компактно - только BinaryWriter/Reader остался. Но BinaryWriter/Reader - это руками каждое свойство записывать-считывать. Хочешь на автомате по расставленным атрибутам - пиши свой бинарный сериализатор, или мирись с громоздкостью JSON, XML, YAML и прочих многословных человекочитаемых форматов. Или вности зависимости, добавляя сторонний бинарный сериализатор.
BinaryFormatter делал всё компактно и тоже автоматом, как JsonSerializer or XmlSerializer.
Вот есть у вас граф объектов. Раньше вы либо просто скармливали его BinaryFormatter целиком, либо расставляли атрибуты, чтобы немного кастомизировать - что сериализовать, что нет. BinaryWriter пишет в потоr только элементарные типы и не может пройтись по графу объектов. Либо для всех типов графа пишете свою сериализацию, использую внутри BinaryWriter, либо что-то стороннее.
Это всё не компактно.
ну zip еще есть и другие варианты.
https://developers.google.com/protocol-buffers
Но когда стоит выбор между безопасностью и компактностью, всегда лучше выбрать первое.
Щас глянул один видос на ютубе. Типичная задача для джуниора - добавить поле ввода-сохранения телефона во все слои проекта в информации о пользователе. Там человек рассуждает - сначала идём в хранилище (БД) и смотрим, как хранится информация о пользователе. И нужно при этом посмотреть все триггеры-процедуры, где используется эта информация о пользователе, чтобы ничего не сломалось. А откуда человек, не делавший эту БД, узнает, где и как используется инфа о пользователе? Есть в СУБД функция "найти все места использования этого поля этой таблицы" или что-то подобное, как в IDE?
Далее, нужно добавить где нужно поле с телефоном - в сохранение данных, обновление, чтение, удаления и прочее. Ну и всё то же самое по всем слоям. На фронтэнде идём в джаваскрипт код и тоже всё это правим. На всё - неделя.
Нормальная задача для фуллстек-джуниора?
Мне вообще не понятно, это нормально, что "вот тут надо поле для телефона вбить... вообще, это Петрович за БД отвечает, но он щас занят (уволился, заболел) - давай ты", и то же самое для фронтэнда, хотя тебя брали на бэкэнд?
А откуда человек, не делавший эту БД, узнает, где и как используется инфа о пользователе? Есть в СУБД функция "найти все места использования этого поля этой таблицы" или что-то подобное, как в IDE?
Вариант первый, самый простой и самый подходящий для джуна - спросить тим лида: "я могу просто добавить поле к таблице CUSTOMER, или мне надо на что-то обратить внимание?" Или ответит или покажет где почитать.
"Что-то подобное как в IDE" у каждой RDBMS своё. Для DB2 есть IBM Data Studio, например. Читать тут: https://www.ibm.com/docs/en/db2-for-zos/12?topic=zos-tools...
Нормальная задача для фуллстек-джуниора?
Абсолютно. Если он это делает в первый раз я ему дам больше времени и буду держать руку на пульсе. Каждый день после дейли спрашивать что успел сделать, что не ясно, какие проблемы.
Мне вообще не понятно, это нормально, что "вот тут надо поле для телефона вбить... вообще, это Петрович за БД отвечает, но он щас занят (уволился, заболел) - давай ты", и то же самое для фронтэнда, хотя тебя брали на бэкэнд
В скраме нет петровичей. Все отвечают за всё, что делает команда. Если команда сама отвечает (меняет) ДБ, то это должен уметь каждый. Кто-то лучше, кто-то хуже. На code review более подкованный в ДБ проверит что наваял джун и поправит/объяснит.
никто у нас еще ничего ни за кем не правил, это тогда проще самому всё сделать.
Это исключительно ваши проблемы. Проще самому сделать, совершенно верно. Но если ты потратишь время и научишь джуна, то потом он освободит тебя от кучи рутины. Через полгода-год инвестиции времени на объяснения окупятся. Ну и ревью даже после лида стоит делать. Иногда такую фигню забываешь...
и научишь джуна
-----
Ошибка, однако... в базовой формулировке...
Джуна, до уровня когда он начнет экономить твое время, обучить за полгода нельзя. Его вообще обучить нельзя.
За полгода джун может чему-то обучится... но это весьма затратный процесс и со стороны джуна, и со стотороны лида... обычно со стороны лида достаточно других забот, а джун без руководства и прогресса забрасывает все нафиг уже к концу квартала если не раньше...
Речь шла исключительно о правке кода за кем то.
А как у вас проходит ревью? Просмотрел, увидел ошибку/корявость. Я или просто говорю об этом человеку, если знаю что он просто ошибся. Или правлю и объясняю ему что и почему я исправил если я знаю/думаю что он не понимает что он сделал не так. Ну или правлю в процессе беседы, неважно. Так что правка кода - составная часть ревью
А как у вас проходит ревью?
Берешь тикет из нужной коробки и смотришь чего там наваяли.
В зависимости от результата или ОК или "звонишь" или пишешь. ОК означает только то, что решение не навредит проекту.
Но вот исправлять - никогда, даже если в комменте буква пропущена. Пока тикет не закрыт - это ветка разработчика и туда никто не лезет.
Легко.
-----
Нее, нельзя.
Было бы можно - не было бы дефицита в ИТ специалистах всех направлений.
Просто берем баласт из желтых домов и лепим ИТ-специалистов - нагрузка бюджет снижается, ВВП растет, занятость повышается и т.п. Ляпота.
Но этого нет - так что - нельзя...
Что можно - можно отслеживать текущий уровень знаний и навыков и направлять внимание и трудозатраты туда, где джун сможет в чем-то продвинуться. Но! Он либо сделает это сам, либо его никто не сможет обучить...
и думать чему учить.
-----
Ну так Я учить - умею. И быстро, и эффективно.
Кто у меня научился - вполне себе работают по специальности.
Вот только смогли научится далеко не все - многие ожидали что Я их научу... и ничему толковому - а именно - самостоятельно учится - не научились.
Как там говорилось:
"Зайца можно научить зажигать спички! Но даже научившись, он не будет знать зачем он это делает..."
Вот так и в любой другой учебе...