Pull to refresh
10
0
Роман Покровский @RomanPokrovskij

программист, фрилансер

Send message
У vintage большой антирейтинг вовсе из-за не заголовков, а потому что сомневается в «священных коровах».
Правильная настолка это та в которой много дипломатии: иначе зачем мы тут все собрались? В Twilight Imperium дипломатия хороша, но ее невозможно доиграть до конца и вовсе не из-за того что «надо много думать», процедур много. Соответственно и глубины нет: «сколько раз интересно переигрывать?» ответить невозможно, тут бы разок доиграть.
Из года в год обзор «графиков» ведется с позиций «давайте маркетинговые обещания каталогизировать», и нет обзоров с позиций архитектуры: во первых надо выделить истинно графики по большим данным от всяких «пирогов» и «грантов» (отдельные жанры). Во-вторых из первых надо выделить те которые умеют сервер сайд зум, потому что обещание «мы такие производительные быстро рендерим 100 000 точек» это бред — эти сто тысяч точек слать не надо на монитор с резолюцией в 1000 точек.
Ваш юмор выдает ваше невежество. Я вам расскажу о цивилиозованных привычках: мыть надо весь сортируемый мусор, и пакетики конечно. Во-первых правила такие (там на другом конце люди у конвейера стоят и проводят «досортировку», хотя конечно у каждого муниципалитета свои линии переработки и соответсвенно правила, но в целом так), во-вторых сортируемый мусор лежит у вас дома дольше бытового (выносится реже) и чтобы не пах.
Воздушные шарики — второй по части неприятности мусор после прозрачных сигаретных оберток (котрые курильшики разрывают и собирать приходится по маленьким ошметакам, при чем у них это все на автомате — и даже вычислить свинью нельзя). Я в сосновом парке рядом с которым живу могу поагитировать прибрать за собой нерадивых потребителей «коктейльпалочек и одноразовых стаканчиков», но стратегию которую применить можно было бы к детям, которые приходят с шариками и тортами делать селфи, а потом шарики оставляют (чеще вего в виде лохмотьев и что странно прибрав остальной мусор) выработать не смог — не хочется пугать, «незнакомый человек» и все-такое. Просто молча прибираю. Не то чтобы меня сильно напрягают сами дети — нет они прекрасны — но вот именно то что навязчиво мучает «ну блин, ну что ж вы этим прекрасным своим детям не объясните».
А напишите коротенькую статью как это бы выглядело в C#? Слева «как записать сейчас», справа «было бы здорово».
При достижении определенного уровня композиции это общая проблема. Конструкции тут не при чем (известно с лиспа). Если проблема решается разворачиванием композиции в императивный код — это оно самое. Жаль что нет готовых инструментов для такого разворачивания (аттрибутов подсказок например).
Еще предстоит разобраться что было с головой, что так повело рассуждение. Ошибка. Спасибо что обратили внимание. Сейчас бы написал «немного полезного синтаксиса вокруг условных присваиваний».
Документация конкретной реализации не дает виденья. У меня остался возможно наивный вопрос, вот эта фича развивается от релиза к релизу, так что ее двигает и куда ее двигают? Как из заявленной решаемой задачи «разложения данных на составные части или извлечения информации из данных различными способами» — например пусть это будет конкретно Natural Language Processing — вырастает запрос на pattern-matching? Никак не вырастает потому что программеры работающие с этой задачей (NLP) работают с функциями своих NLP шных библиотек и мыслят в них. Зачем им новые statementы?

Если бы проще заявили «немного полезного синтаксиса над рефлекшном» я бы не мучился, а так остается недоумение — что я упускаю.

Знатоки, напишите статью, и поделитесь пожалуйста примерами до чего дошел Pattern Matching в F# или других языках развивающих эту концепцию? Хотелось бы понять «о чем мечтает команда разработчиков C#» и к чему стремится прогресс. И конкретно, а где нибудь уже дошли до разбора выражений языка средствами языка?

Отдал был часть кармы если бы Хабр позволял «краудфайндить» на статьи.
Т.е. статью можно заменить на одно предложение: строя PropertyExpression PropertyInfo нужно брать из базового класса? Я не из вредности, просто хочу понять есть еще что-то важное, на что автор хотел обратить внимание, а я упустил?
Не просто требование «работы на высоком абстрактном уровне» требуется, а конкретно «проектирование» — умение видеть код до его написания и желательно в законченном виде. Если не увидеть все абстракции сразу — функциональный код придется очень много переписывать. ООП шникам проще — они видят классы предметной области и легко в них новые «абстракции» запихнут, что лезет, что плохо лезет, и что не лезет, но иметь отношение (соответствует их пониманию прекрасного) не позволяя изменениям далеко распостраняться. А с точки зрения функциональщика и его понимания прекрасного при обнаружении новой абстракции скорее всего переписывать придется гораздо больше (всё по стеку).
Для себя сформулировал что «сторонний логгер» нужен чтобы не писать свое управление лог-файлами (разбиение, арихивирование в зип, удаление т.п.) — муторный код, который еще и настраивать нужно по ходу эксплоатации, а все остальное (форматирование, буфферизация, отличные от файловой системы destination) решается своим кодом гораздо проще чем через сторонний логгер. С этой точки зрения у nlog работа с файлами богаче чем у log4net. github.com/nlog/NLog/wiki/File-target.
Спасибо. Если не тяжело, поделитесь примером того чем можно интересоваться (писать в лог) когда HTTPContextа нету? Сходу не приходит в голову… А HTTPContext действительно такой дорогой что безопасность есть смысл проверять до его создания? Про ситуацию «уже нету» догадываюсь, — можно трейсить утечки — но опять же утечки по разному можно трейсить. А еще лучше «подарите удочку» — порекомендуйте статью что в каком порядке создается и уничтожается.
А вы не могли бы рассказать в двух словах для чего execution steps нужно использовать? searchcode никаких примеров применения OnExecuteRequestStep и ExecutionStepInvoker не приводит… github приводит OnExecuteRequestStep в каких-то вызовах телеметрии, что уж очень специфично, т.е. выглядит как «ну дополнительный каунтер» а не «фишка».
нет, этому много лет. именно что планировался флеш по условию получения конкретного сообщения.
Из вопросов по последним фичам как они сделали буфферизацию? Или она еще в беттах? Я так понял авторы хотели ввести буфферизацию событий и флеш спо условию — одно из них получение сообщение об ошибке. Если сообщение не пришло то дисмисс — лишнего не логим. Так было в альфах 5ой, как сейчас не знаю.
Смените автора. Фраза «крутые фичи VS 2019» да еще и в контрасте с примитивностью демонстрируемой автоматизации (лениво было найти полезный пример?) создает удручающее впечатление.
потому что все очевидное юридически зафиксировано в уровне техники, а неочевидное попробуй придумай.
Понял что, критерий очевидности у вас эмпирический: очевидная идея это идея чье гипотетическое применение обсуждается за N лет до появления технической возможности, в настоящий момент N равно 20. Готов принять.

«Деньги жгутся факелом и все. Так это выглядит со стороны ответчика.»
Разве у ответчика остутсвует возможность вчитаться в аргументы и недоводя до решения суда, без лишних трат, предложить мировую?

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

Но вы вроде говорите во всех примерах о конфликте доводенном до вынесения решения. И вот тут я не понимаю почему отсутсвует практика компенсации затрат на процесс.

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

Information

Rating
Does not participate
Location
Вильнюс, Литва, Литва
Registered
Activity