• Периодическое обновление данных
    0

    Можно еше поковырять ThreadPool.RegisterWaitForSingleObject() — он как раз для таких случаев подходит и избавляет от возни с вычислением миллисекунд.


    Ну а по коду вот что. Во-первых, в тех местах, где int используется в качестве "столько-то миллисекунд", замените его на человечий TimeSpan. Во-вторых, совсем правильно было бы написать метод, типа PerformPeriodicCallback(Action callback, TimeSpan interval, WaitHandle stopEvent).

  • Azure DevOps бесплатно для маленьких компаний за 1 час
    –3

    Накликай мышкой себе девопса. Позор-то какой.

  • Пять раз «Война и мир»: обзор струйного МФУ Canon PIXMA G3400 с дозаправляемыми чернильницами
    0

    Каких, например?

  • Грязные трюки в коде игр
    +12

    Построить дедупликацию на CRC32 — это сильно!

  • Как мы из CRUD-движка сервис делали
    0
    У данного подхода есть недостатки перед переменными окружения, это правда.… Они лежат в одном месте.

    Где хранится строка соединения с боевой БД? Как устроен процесс деплоя и кто подменяет строку соединения?


    Логику того, что любой ConnectionString в системе получается с помощью единого метода я готов отстаивать. Пока не вижу контраргументов. Могли бы Вы подробнее написать чем Вам не нравится данный подход и чем он грозит.

    Я не против единого метода. Я против того, чтобы этот метод был как-то связан с HttpContext'ом — хотя бы из соображений тестируемости. Ну и вызов Extensions.GetClientConnectionString(context: null) выглядит дико.


    Повторю мысль. Это единственный метод, который используется для получения ConnectionString. Для коробочных версий используется абсолютно тот же код. Если оплата просрочена – система не работает. Остальная часть системы просто получает ConnectionString, и не знает «режим работы системы».

    Повторюсь: это плохой метод (GetServiceAccount(), скорее всего, не лучше). Если метод занимается получением строки соединения, то проверять режим работы системы и контроль оплаты — не его ответственность. В кровавом энтерпрайзе это называется Cross-Cutting Concern.


    Я не знаю всей специфики предметной области, но могу предположить, что, например, веб-часть должна как-то сообщать пользователю о том, что доступ в систему не оплачен. Такое поведение гораздо красивше сделать Action Filter'ами.


    Режим же "сервиса", скорее всего, разительно отличается от режима работы веб-части, и поэтому к нему нужен особый подход. Опять же, не зная специфики я деталей не скажу, но чую, что что-то у вас нечисто.


    TaskContext используется только для запоминания ConnectionString.

    Не надо нигде его запоминать. Глобальное состояние — зло. И, скорее всего, вам нужна не строка соединения, а DbContext (или, простихосспади, репозиторий, шоб он был здоров) — а за ними сходите в соответствующий сервис или попросите DI-контейнер вам всё подсунуть.


    Про остальную логику не понял, могли бы Вы пояснить подробнее.

    Я, честно говоря, не знаю, откуда начинать. AuthHandler знает очень много пикантных деталей реализации (типа необходимости вызывать GetCacheProvider(), умения формировать URL'ы, логики обработки null'овых результатов вызова GetClientConnectionString() и т.д.). Очень грязный и запутанный код.


    Код «обобщенного кэшировщика»... Объясните пожалуйста, что именно Вам в нём не нравится, как на уровне идеи Вы предлагаете его исправить.

    Прежде всего, не уверен, что он вообще нужен. Больше похоже на попытку прикрыть низкую производительность Entity Framework. Хотя, например, если бы сделать нормальный batch'инг и за один roundtrip к БД загружать как можно больший граф объектов, то кэша, может быть, и не потребовалось бы. Или он был бы в разы проще и хранил только иммутабельные справочные данные.


    … Другая джоба ищет письма для отсылки и рассылает их.

    Давайте хотя бы об этом. Письма правильно рассылать не джобами, а через очередь. Фронтенд публикует "сообщения" типа "пользователь добавил комментарий к документу", это сообщение получает модуль, ответственный за формирование писем, компонует письмо — с правильным текстом, вложениями и т.д. — и публикует сообщение типа "электронное письмо подготовлено к отправке". Это сообщение получает "отправлятор" и медленно и неспешно отправляет письмо в SMTP-сервер. При этом фронтенд вообще не занимается долгоиграющими задачами.


    Обновление схемы БД происходит вообще само, через CodeFirst. Баз у нас потенциально очень много. Происходит по первому запросу к конкретной БД. В чём Вы видите проблему этого решения?

    Проблема как минимум в наличии прав на DDL у пользователя. И вообще: обновление схемы БД — это задача процесса развертывания, но никак не нормального режима работы.

  • Как мы из CRUD-движка сервис делали
    +1

    Код очень не айс.


    GetClientConnectionString:


    • Извращение с "DeveloperConnection-" можно и нужно заменить на хранение строк соединения в переменных окружения
    • Обработка ситуации с httpContext == null — это нечто. Вы говорите про отдельные Task'и, но кто в здравом уме внутри таска будет получать строку соединения используя конструкцию, по смыслу похожую на ((HttpContext)null).GetClientConnectionString() ?
    • Куча ненужной логики: "режим сервиса", контроль оплаты, режим коробки

    TaskContext и прочее — это грубейшее нарушение SRP.


    AuthHandler на каждый запрос обходит Reflection'ом все типы, потом проходит по методам, выковыривает атрибуты… Да и остальная логика не блещет.


    Код "обобщенного кэшировщика" физически больно видеть.


    Архитектурные же решения — отправка писем, обновление схемы БД, кэш на "несколько секунд", Access Token'ы — чад и угар.

  • Firebase: прощание с иллюзиями
    +17

    Хипстеры на марше.


    Ради задачи, для решения которой (в виде MVP) за глаза хватит SQLite, притащили адовый ворох SaaS решений, потратили кучу времени на взаимное интегрирование всего барахла (без описания, конечно же, что, куда и с какими учетными данными за чем обращается), технично разложили грабли с денормализацией и дублированием данных, да помножили в своей этой Ноде все строки на картинки.


    Оглушительный успех, я считаю.

  • Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно. Вопросы эффективности
    0

    Вот сами руки написали, клянусь макаронным монстром!

  • Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно. Вопросы эффективности
    0
    Можно конечно с кавычками, но это просто неудобно.

    Фу таким быть. Это вот после таких "неудобно" приходится каждому новичку объяснять, что "в Date у нас дата, Customar_ID — это по опечатка оплошности, и хранится там не Customer.ID, а LegalEntity.ID" и т.д.

  • Терморегулятор для отопления своими руками
    0
    Во «взрослых» приборах управление ответственной нагрузкой

    Кинетесь ссылкой на почитать?

  • Песнь о могучем Деплое: безостановочное прозрачное развёртывание веб-сервиса
    0

    Очень сложно с БД, как мне кажется. Мы у себя обратно-несовместимые изменения схем выполняем в несколько этапов.


    Почему обновление фронтов такое многомудрое? Почему нельзя выкинуть веб-сервер из ротации на балансировщике, спокойно его обновить-прогреть и вернуть обратно в балансировщик?


    Почему такие строгие требования к "версионности" сервисов? Почему не разрешить версии сервиса M.N, ранее работавшей с сервисом версии P.K, общаться с версией сервиса P.K+1?

  • Самоконфигурирующиеся приложения
    +3
    Круто, конечно, но какой-то Overengineering получается. Один из вариантов (см. The Twelve-Factor App:
    The twelve-factor app stores config in environment variables (often shortened to env vars or env).
  • Анализ производительности Windows с использованием возможностей ОС и утилиты PAL
    +3

    Что-то очень сложно.


    Как, например, следующий способ. Взять Statsify (порт Graphite под Windows), установить на требуемые сервера Statsify Agent, в statsify-agent.config перечислить, какие счётчики собирать, потом установить Grafana и наблюдать красивые графики. Плюс автоматом получаем историю, агрегирование данных и т.д.

  • Парсер математических выражений C# — опыт дилетанта
    +3

    Очень переусложнено всё и перемешано.


    Как минимум, нужно отдельно выделить лексер — тогда упростилось бы решительно всё, начиная от объектной модели и заканчивая логикой самого парсера.


    А вообще — очень рекомендую вот эту статью: Pratt Parsers: Expression Parsing Made Easy.

  • Mercurial: изменяем историю
    +2
    «Правильнее» будет называть это не «изменением истории», а «решением, какая это история будет»: You are not «rewriting» history. You are deciding history.
  • Как у Аськи лицо менялось: визуальная эволюция интерфейса ICQ
    +34
    Вот что бывает, когда программистам дают проектировать интерфейсы. Попраны все мыслимые и немыслимые указания гайдлайнов.
  • Фрактальный кустик от новичка для новичков
  • Билайн автоматически добавляет тулбар и изменяет дизайн сайтов
    0
    Добавление в Restricted Sites не помогает?
  • Выбор между C++ и C#
    0
    И все-таки С++ поддерживает работу со «строками, юникод, итераторы и кучу всего еще» в STL.
    STL есть в базе, везде и никаких boost-ов для этого не нужно.


    Напоминаю: мы сравниваем в первую очередь языки, а не библиотеки. Ну да ладно. Строки — ужасны, итераторы — покажите мне встроенный в язык foreach и yield.
  • Выбор между C++ и C#
    0
    Поподробнее:

    var selectedOrders = from o in context.Orders
                         where o.Freight > 30
                         orderby o.ShippedDate descending  
                         select o;
    
    http://localhost:12345/Northwind.svc/Orders?Orderby=ShippedDate&?filter=Freight gt 30
    


    Т.е. нарушение DRY (да, я ленив) при использовании .h-файлов — это нормально? Зачем сначала заставлять разносить объявление и определение, а потом подтыкать это подпорками в IDE?
  • Выбор между C++ и C#
    +2
    в STL: wstring, u16string, u32string — все есть, все прекрасно.

    Вы, наверное, издеваетесь:

    typedef basic_string<char16_t> u16string
    


    Что «прекрасного» есть в std::basic_string? Про Юникод она знает чуть меньше, чем ничего: ни Code Point'ов, ни графем, ни нормализации. Как «класс строка» она нежизнеспособна.
  • Выбор между C++ и C#
    +2
    Как вы лихо подменили время в рантайме временем запуска. И нет, прямой корреляции между «размером» приложения и временем запуска нет.

    «Поддержка фич в виде библиотек» — это путь PHP. «У нас нет нормального синтаксиса создания массивов, но зато есть функция!». Так и в С++: «язык не поддерживает нормальную работу со строками, Юникод, итераторы и кучу всего еще, но зато у нас есть Boost!».
  • Выбор между C++ и C#
    +1
    Про лямбды и итераторы сказал тут по соседству, а про Юникод даже не смешно. Думаю, было понятно, что Юникод должен поддерживаться не на уровне

    ВыходнойПоток << "Меня зовут " << имя;

    а таки на уровне поддержки его стандартной библиотекой и рантаймом. И вот тут все становится ожидаемо печальным.
  • Выбор между C++ и C#
    +3
    А, например, OData? Тот же LINQ, но поверх HTTP.

    .h-файл — атавизм, который адепты C/C++ пытаются всячески оправдывать; пользы от них — ни на грош. а мороки — уйма: те же разъезжающиеся сигнатуры, нарушение DRY и вообще масса способов отстрелить разные куски комиссарского тела. (И позвольте, к слову, заметить, что класс «в тысячи строк кода» — явный антипаттерн; но да что уж). Так вот все современные IDE для современных статически типизированных языков умеют замечательно показывать публичный контракт класса вместе с документацией.

    Про итератор сказали уже, но вообще странно слышать претензии к простым и понятным .NET'ным итераторам от C++-разработчика с зоопарком begin(), end(), iterator, reverse_iterator и т.д. И вообще — Iterators Must Go.

    Лямбды с Dangling Reference'ами прэлэстны, право слово.

    Ну и сравнивать библиотечную подпорку для асинхронного программирования в C++ со встроенной в C# поддержкой оного — несколько за гранью
  • Выбор между C++ и C#
    +5
    Но на этом все.

    Небесконечное время компиляции, отсутствие .h-файлов, несравнимая по человечности отладка и диагностика ошибок, LINQ в целом и применительно к БД и XML в частности, лямбды, итераторы, async/await, Unicode.
  • Рейтинг популярности облачных сервисов Microsoft в 2015 году
    +1
    Выражать рост в процентах — очень по-совковски. И что случилось со шрифтом?
  • Salt и Ansible — системы управления конфигурацией на языке Python — видео с DevConf 2014
    +7
    Выступление — ужасное.
  • Самый худший из когда-либо созданных API
    0
    Попробуйте Statsify — должно понравиться.
  • Делаем скриншоты правильно: практические советы
    0
    … детали можно увеличить, чтобы сделать акцент...

    А вот чем такое можно сделать?
  • Приемы разработки ASMX веб-сервисов
    0
    Вот не надо тут про «интероперабельность»: для того, чтобы создать хотя бы подобие оной, лучшие Энтерпрайз Архитекторы создали целое новое семейство стандартов WS-I поверх спецификации SOAP. И даже со всем этим багажом «нельзя просто так взять» и вызвать сколь-нибудь сложный .NET-сервис из Java-клиента (или наоборот) — обязательно что-нибудь где-нибудь да отъедет. И сиди потом разбирайся в хитросплетении многомудрых XML-элементов.
  • Управление удалённым IIS
    0
    Вы сейчас, по сути, изобрели Puppet/Chef, но только для IIS.
  • Антипаттерны проектирования: Functional Decomposition
    0
    набор идемпотентных функций

    Я думаю, вернее было бы сказать "чистых функций".
  • Continuous Integration с Unity
    0
    Largefiles в Mercurial?
  • Предлагаю нестандартный опросник по .Net
    +9
    Интересно, хоть сколь-нибудь статистически значимое число проектов проект провалилось из-за того, что программисты не знали, как же там JIT компилирует вызов методов?
  • Как сделать Online-логгирование с нуля
    0
    А есть какое-нибудь чтиво о внутреннем устройстве Ceres'а, окромя исходников?
  • Как сделать Online-логгирование с нуля
    +1
    Строго говоря, RRD как продукт в Graphite уже не используется. Там есть свои, со всем причитающимся, — Whisper и Ceres. Про второй не скажу, а первый — концептуально RRD, верно.
  • Как сделать Online-логгирование с нуля
    +1
    Я вот-вот уже почти скоро на днях собираюсь выложить наш порт Graphite/StatsD на .NET. Клёвая штука получилась.
  • Как сделать Online-логгирование с нуля
    +1
    Одна из самых крутых штук в Graphite — это его функциональность по «даунсэмплингу» исторических данных. На базе Graphite можно строить компактные хранилища исторических данных на многие годы назад. Например, измерения текущей температуры за последние сутки хранятся с «разрешением» в 1 минуту, данные за прошлый месяц — с «разрешением» в 1 час (т.е. берутся 60 измерений, вычисляется среднее/максимальное/минимальное значение), а за всё остальное время — с «разрешением» в, например, 4 часа.
  • Распродажа книг из серии «Head First O'Reilly»
    +5
    Для продажи электронных книг ваш сайт ну никак не «оптимизирован». Но, тем не менее, спасибо.
  • Wyvern: новый универсальный язык программирования, спонсируемый АНБ
    +13
    image