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

О, а подскажите что удалить. Потому что оно у нас не работает именно с такими же симптомами. Приходится устанавливать новую версию через скачку с сайта, и не дай бог при запуске сетапа забыть закрыть сбис… Куча алёртов про невозможность заменить файл.
force
0
А чем не нравится PackDb (инструкция тут)? Написать простейший скрипт для архивирования сразу в сжатый архив и засунуть его в Task Scheduler, будет работать со всеми версиями MS SQL
force
0
3. Исторически сложился log4net — особого смысла менять, пока не видим.

Пока, имхо, стоит ждать .NET Core 2.0, смотреть что у них получится, заодно фидбека и best practices накопится. С Mono, если удастся подобрать идентичное железо попробую натравить свою числодробилку, оптимизированную под .NET, на Mono и .NET Core, посмотрю на результаты. Если не забуду, отпишусь :)
force
0
С этим .NET Core иногда нужно столько переписывать, что пункт 3 из вашего списка не кажется таким уж проблемным. То, что я увидел в .NET Core:
1. Полностью переделана конфигурация. Т.е. сегодня модно в JSON, завтра в protobuf будет. Придётся переписывать весь конфиг для проектов.
2. Очень сильно перекочеврыжен рефлекшен. В большинстве случаев решается через GetTypeInfo (обезьянкой ходишь по коду и вставляешь эту строчку). Опять же, переписывать кучу всего.
3. Потеря кучи библиотек, или сидеть ждать, когда авторы переделают, или пытаться самостоятельно, если исходники есть. Банальный log4net не работает
4. Постоянная смена API. Например, Kestrel с каждой версией полностью меняет API. При этом «каждая» версия это (1.0.0-beta, 1.0.0-rc, 1.0.0). До кучи бардак в репозиториях — тот же кестрел лежит под тремя именами.
5. Периодически мелкое изменение API стандартных библиотек в самых неожиданных местах. Например у RSA нельзя получить XML с параметрами. Т.е. весь код надо обкладывать ифами и проводить тестирование

При этом по факту, под mono работает то, что и вроде бы и не должно работать, например HttpListener. Скорость — не ясно, но числодробилки на .NET реализовывать странно, а в бизнес.приложениях всё равно всё упирается в базу данных, или как у вас в SOAP, который архитектурно никогда быстрым не был.
force
0
Ну, вообще void — это тип. System.Void, и вы можете сделать typeof(void), больше, правда ничего не можете сделать с ним. Т.е. в кишках тип номинально уже есть. Какой-нить Invoke, имеющий возвращаемый тип object, на void возвращает null (с горя). Т.е. уже встроенная библиотека .NET борется с этим типом.
На мой взгляд, Func<void> всё-таки лучше чем грустный Action. Хотелось бы, чтобы его можно было использовать более гибко.
force
0
Ну вот мне, кажется, что гораздо хуже чем null, в дизайне C#, это void. Из-за этого сейчас активно дублируется всё API по работе с функциями (Action и Func, Task и Task<>). Вот это, раздражает гораздо больше.
force
0
это цифры для какой компрессии?

normal
и что насчет времени при компрессии high\ultra — может тоже проблема с базами больше 2гб?

Да с этим вроде нет проблем, это просто 7z такой медленный.

проводили ли тесты на промышленных масштабах 200-300-500Гб? но поскольку база в кластере и утилита может работать только с локальным сервером, увы не получится...(

Тут не должно быть никаких проблем, только долго (ну и обычный бекап долгий в данном случае). А с кластером — если на одном из узлов локально запустить?

Пожелания записали, будут ресурсы — сделаем.

force
0
Смотрите, тут дело в том, что вы можете получить 7z быстрее и проще чем стандартными средствами (и не тратить место на диске). А потом этот 7z восстановить не распаковывая. А т.к. 7z жмёт гораздо лучше чем zip и стандартные средства, для долговременного хранения лучше использовать его (если есть время). Ну или для быстрых бекапов уменьшить качество сжатия.
По цифрам.
Вариант раз на слабом сервере. Стандартные средства 74 секунды бекап + 391 секунда сжатия в 7z = 465. Тот же эффект через PackDb — 446 секунд.
Варинат два на мощном сервере (база другая). 192 + 399 = 591 против 413.

Размер базы для примера: без сжатия 8.3Gb, сжатие средствами SQL — 1.9Gb, сжатие в 7z — 0.46Gb. Т.е. выигрыш на 1.5Gb для одной базы.

По поводу проблем с зипом — обнаружили, виновные будут наказаны. Есть проблемы со сжатием в zip при размерах базы более 2Gb (у зипа постоянно с этим проблемы лезут).
force
0
Для любых. Результат всегда радует, а опции выбираются под конкретную ситуацию.
force
0
Да, конечно, восстановление поддерживается. Время выполнения примерно равно сжатию, сам бекап не оказывает существенного влияния на скорость операции.
force
0
Я уточню насчёт конкретного текста, но можете использовать без ограничений для бизнеса.
force
0
А что именно вас интересует? Сам прогресс — псевдографикой, перерисовка с помощью \r
force
+1
Ок. подожду, может что-то интересное будет, ради чего и в следующем году будет иметь смысл съездить. Но общие темы пока откровенно печалят.
force
0
Мне интересен .NET, и именно в контексте: кровь, кишки, расчленёнка (Roslyn, .NET Native и прочие новомодные плюшки). Т.е. создать сайтик на ASP.NET 5, под EF, это скукота и банальщина. Я каждый день таким на работе занимаюсь (хотя вру, ASP.NET надоел, от EF дёргается глаз, от Azure просыпаюсь в холодном поту).
Интенсив по IoT, очень похож на прошлогодний хакатон, DevOps — что-то очень специализированное, на дизайн Win10 — мне всё равно.
И непонятно, за что платить +5 тыс. Т.е. вроде бы уже на конференции, просто специальные доклады, но за деньги.

Также, всегда были интересны мастер-классы по SQL, хотя это совсем не мой профиль.
force
0
Как я понял из схемы, второй день или на интенсивы (на мой взгляд унылые, но это лично моё мнение) или на сертификацию, или на очень ограниченное количество докладов? Т.е. если нет планов идти на интенсивы, то во второй день делать нечего и проще купить lite билет и не заниматься бездельем на второй день?
force
0
Будет. Ссылка обязательно где-то всплывёт, антивирусы её просканируют, пометят сайт как подозрительный, пользователи придут на WOT, понизят сайту рейтинг, на WOT придут антивирусы, увидят, что у сайта низкий рейтинг, предупредят пользователя, он пойдёт на WOT… Такая вот петля смерти.
Они все умные сейчас стали, но о последствиях не думают, главное пользователей попугать. Мне мой сайт занесли в чёрный список, потому что у него была ссылка на другой сайт, на котором оказалась ссылка с вирусом. Такая вот транзитивная смерть от антивирусов.
force
+1
Фиксировать плохо тем, что проекты движутся. Вы написали набор крутых компонентов под одну версию фреймворка, вы её зафиксировали. Потом начинается новый проект (может быть через год), и хочется использовать новую версию. А нельзя, потому что у вас есть стек компонентов, которые работают на старой. И вам надо их взять и переписать. И весь наработанный опыт идёт лесом. Даже если переписать нужно наполовину, или на треть, то получается что сущности начинают плодиться. В старый проект вы не можете ввести новые компоненты, в новый — старые.
force
+1
Тут согласен. Я забыл уточнить важный момент. До своих велосипедов, естественно надо пробовать существующие и понимать почему они так сделали, и что они решали. Т.е. с нуля своё писать интересно в плане того, понять мысли разработчиков других решений, что они хотели решить и почему они сделали именно так. И после нескольких унылых велосипедов и нескольких фреймворков начинается понимание того, что вот под твои конкретные условия, действительно велосипед будет гораздо лучше, удобнее и понятнее. Но нужен опыт, да. И иногда переписывание кусков других фреймворков по частям.
force
+1
Тут сложный момент. Например, Angular, постоянно что-то меняется и отваливается в разных версиях, и намекают что в 2.0 будет всё совсем по-другому. В результате, остаётся два варианта — или зафиксировать Angular на фиксированной версии, что плохо, либо гнаться за версиями и тратить ресурсы на поддержку изменений ангуляра.
Свой велосипед, он может и не учитывает каких-то нюансов, то ты точно знаешь, что он не учитывает, как их можно обойти и стоит ли обходить. И изменяется он тоже, фиксированно и по ситуации.
force
0
Именно так. В одном сервере за пару месяцев заменили 4 винта. Все были из одной партии. Хорошо, что не сразу умерли а постепенно :)
force
+2
Да, всё точно, ваш ответ про время закешировался, обновил браузер и получил
Скриншот


Идёт запрос на yandex.ru/internet/api/v0/datetime в ответе нет параметров кеширования. Мой вопрос оказался очень к месту, хотя был задан раньше, чем я увидел проблему у вас. :)
force
+1
Извините, я не специально, но только сейчас заметил, что у вас кешируется время на yandex.ru/internet :)

Скриншот

force
+6
А это уже бредом попахивает. Конечно, семантичненько вышло, но накручивание могучей логики ради красоты семантики это уж слишком.
force
+1
POST — несемантично, рандомное значение — костыль. Но концепцию понял, волшебства тут нет :)
force
+3
Такой вопрос: у нас есть метод, возвращающий текущее время (как пример). Логично, что он должен быть GET'ом, но при этом кешировать его явно не надо, ибо глупо. Решение в явном запрете кеширования со стороны сервера, или есть что-то умнее с учётом кеширования шарахалок по луне?
force
0
Ложное условие отлично прокатывает для проверки гипотезы — брекпоинт с заменой результата, но, поскольку, фактический возврат значения происходит в ntdll, её патч может поломать все остальные проверки для системы, что по идее не очень хорошо.
force
0
Я делал на 2012 r2, но после кучи апдейтов, в которых меняли Task Manager — слегка надоело :) Но идея та же.
force
+16
В ту же копилку, «динамический компилятор», судя по всему имеется в виду JIT. Достаточно устоявшийся термин, и гораздо более понятный.
force
0
Ок. понял, что есть в стандарте. Но используется ли она фактически? Просто вижу кучу проблем с этим: обрыв соединения сразу рушит все запросы, а дальше или забивать на проблемные соединения, или реализовывать логику по повторному докидыванию соединений. Или если один запрос длинный, все остальные встают в очередь и курят. На сервере необходимо реализовывать сложную логику по поддержке таких хитрых соединений с сильным взаимодействием между сервером и обработчиком.
force
+1
Не очень понял следующую ситуацию: допустимо ли фигачить в одном соединении несколько реквестов, а потом получить пачку респонзов. И не снесёт ли башню серверу от такой логики?
force
0
Мы используем подобные решения в нескольких проектах. Очень удобно: у нас всегда есть пользователь, т.е. не надо делать страницу авторизации, пользователю не надо придумывать отдельный пароль, мы знаем имя пользователя, возможность быстрого импорта пользователей (просто файлы с сертификатами).
Но, к сожалению, есть недостатки: клиентские сертификаты более требовательны к качеству криптографии (то Microsoft с апдейтами начудит и всё сломает, то Chrome решит истерить), для FF приходится вручную импортировать сертификат, с мобильными браузерами множество проблем (кто-то не поддерживает, импорт сертификатов приводит к некоторому геморрою).
force
+2
Это не .NET Framework и к нему не имеет отношения. Соответственно не имеет отношения к вашему первоначальному высказыванию.
И это C++ Runtime, т.е. библиотека для запуска приложений, написанных на C++ с помощью Visual Studio. Распространяется отдельно, т.к. этот рантайм разбух до неприличных размеров, чтобы засовывать его в каждый файл, он требуется куче приложений, поэтому лучше поместить в отдельное место, и к нему могут выходить апдейты и багфиксы со стороны Microsoft, которые не будут требовать перекомпиляции приложения.
force
+4
Тут вы мимо. msvcr*.dll не имеет никакого отношения к .NET Framework.
Это как раз родной С++
force
+4
Вы из какого года это пишете? Framework уже с Vista поставляется, лезет через апдейты, а количество программ, его требующих превышает все разумные пределы.
force
0
Не совсем относится к вёрстке, но в Хропере до 28-ой версии не работали клиентские сертификаты. А 12-ая от ужаса просто падала. Поэтому пришлось вычеркнуть из списка поддерживаемых.
force
0
Будем надеяться. Пока там минифицированный css, что в принципе не особая проблема.
force
+2
Я уже посмотрел на предмет украшательств:
Если отредактировать файл Application\1.0.83.38\resources\vivaldi\style\common.css, то можно поправить стили интерфейса браузера (изменить цвета, размеры, кнопки).
В частности, убрать слишком кислотные цвета.
force
0
Совместимость, судя по всему. SHA2 (кроме SHA512) уже давно всеми неплохо поддерживается, на сайт с SHA3 некоторые клиенты просто не смогут зайти.
force
0
В 2014h — изменения только в прошлых годах. Не думаю, что кому-то на Андроиде важно, что было в Новокузнецке в 1920-ом году. Если только эстетам :) 2014g — тоже самое, только прошлые даты.