Думаю, госуслуги чисто для авторизации. Контроль за суммами и выплату налогов физлиц осуществляет депозитарий а его контролирует ЦБ. И там уже отлаженная схема, особо не требующая улучшений.
Есть готовые мат библиотеки для подбора вектора коэффициентов, минимизирующих функцию. В вашем случае что-нибудь из симплекс метода подошло бы Например, для .NET платная библиотека но 30 дней бесплатно.
Хм, а зачем фича-ветки между собой сливались?
1. Отпочковали фича-ветку от главной
2. разработали фичу (n коммитов).
3. во время разработки время от времени забирали себе основную ветку (к — служебных слияний).
4. один раз влили в основную ветку. — 1 слияние.
И да, я отношусь с тем, кто не понимает, зачем нужна чистая история. Всмысле, что в ней такого чистого после ребейза.
И да, в hg мы не используем jit-flow. Одна ветка = одна версия. Ветка со временем выходит в пререлиз и в релиз. В момент смены состояний даже коммита делать не нужно, т.к. статус релизности ветки имхо можно и нужно отслеживать на сервере интеграции а не в репозитории.
Да нет. Увы, проблема с коллизиями так просто не решится. Вы можете задать ограничение на такую же длину, можете добавить сколько угодно дополнительный проверок (например, совпадение первых и последних 1000 символов словаря) но до тех пор, пока размер информации меньше, чем наиболее оптимальное сжатие словаря (в 64к без потерь не вмещается) все равно будут коллизии равные объему нехватки информации.
Было бы здорово, если бы где то была карта всех ресторанов с Вашими столами. Я бы сходил в ближайший по возможности. Да и Вашим клиентам была бы реклама и это бы подтолкнуло их к покупкам.
Я бы во главу угла поставил Гигантские улучшения inmemory OLTP. В 2014 фактически это была не работающая технология из за большого объема ограничений. И почти что все эти ограничения были убраны в 2016.
Испытывал технологию на ctp3.3 на боевых данных порядка 20Гб: на многих рабочих сценариях улучшение в 100 раз!
Однако есть и ложка дегтя: по необъяснимым для меня причинам время поднятия бд — несколько часов! Например детач и аттач бд на 20Gb у меня проходит 3 часа.
При аттаче в errorlog сыпятся:
2016-03-11 17:48:38.75 spid43s Error: 41383, Severity: 16, State: 124. 2016-03-11 17:48:38.75 spid43s An internal error occurred while running the DMV query. This was likely caused by concurrent DDL operations. Please retry the query.
примерно раз в две секунды.
Если в релизе удастся побороть эти проблемы, то киллер-фича MSSQL 2016 — это inmemory OLTP!
Кстати, я задумывался над тем, что текущее представление хранения позиции — не оптимально. Проблем две:
Дело в том, что большинство позиций, который можно выставить на доске полным перебором — не валидны с точки зрения правил игры. Или крайне низковероятны. Например: три чернопольных слона с любой из сторон.
Между соседними ходами очень небольшое изменение. Т.е. если озадачится именно проблемой ХРАНЕНИЯ позиций то можно сделать так, что совокупность позиций опирается на базовую, храня только дельту изменения к ней.
Размышляя над возможными исправлениями недостатков я уверен, что можно сделать алгоритм хранения с переменным размером бит на позицию. От 60 до 120 бит, в зависимости от того, как много фигур осталось на доске и на сколько хорошо подобраны узловые позиции.
Получив такое компактное хранение можно их пронумеровать и результат оценки для 9 фигур по принципу, схожему с Syzygy. Игра в эндшпиле для компьютера будет сводиться к довольно сложному получению порядкового номера всех полу-ходовых позиции и проверка их в базе на результат.
Понятно, что такое представление будет иметь недостатки, в виде того, что позиция представлено номером и при ее оценке не была известна информация о предыдущем ходе (взятие на проходе) а также возможности рокировки (но это и сейчас в эндшпильных таблицах отсутствует).
Зато можно хранить таблицу для 9 а то и 10 фигур на одном обычном компьютере! Отдельный вопрос: как быстро будет посчитана такая таблица, но это уже отдельная история.
ПО сможет определить, что запущено на виртуальной машине?
Иначе я могу открыть в отдельном окне бразур в основной операционке. А виртуальная машина при этом не будет ловить событий смены активного окна.
Иногда в комментариях мы вместо вопросов пишем наше отношение к предмету статьи или ее качеству.
У меня вопросов с целью понимания архитектуры и не было. Была публичная критика, которую я старался сделать конструктивной.
Увы, видимо я совсем не в тренде ( Подтверждение опыта, что понятие архитектуры везде слышится по разному?! Да, я определенно перестаю понимать ценности в статьях об архитектуре.
Елена, добрый день. Вы говорите, что пишите о собственном опыте, мне же кажется, что это как раз не так.
Предлагаю взять любую из глав в любой части. Например последнюю:
Когда компании нужно вкладываться в Архитектуру? И что будет, если этого не делать?
Поправьте меня, мне кажется у Вас тут две мысли:
1. Если не вкладываться, то компании когда нибудь станет плохо.
2. Все компании разные.
Отложим момент, что мне не удалось найти в этом разделе какого нибудь ответа на «когда». Видимо, Вы подразумеваете: «всегда, если хотим, чтобы компании было хорошо».
У меня к Вам следующий вопрос: что из этого раздела на три с половиной тысячи знаков является Вашим опытом? Можно ли привести какую то мысль и описать, как она стала результатом опыта? У меня это не получается.
Беру, например:
Кроме того, на архитектурные процессы влияют особенности корпоративной культуры компании – особенно модель принятия решений, способы коммуникации, информационная открытость и т.д.
И вижу типовой шаблон: «архитектура влияет на все». Если ударится в философию, то любой процесс в компании влияет на другой любой процесс.
Для меня этот абзац обрел бы смысл, если бы Вы пояснили: какое влияние Вы имели ввиду, почему посчитали его важным и на каком примере из жизни. Сейчас же, простите мне мою уже сделанную оценку, это выглядит как клише.
Я не вижу ценности в таких мыслях. Т.е. я пробую представить человека, кто, например является или хочет стать архитектором и раньше он чего то не знал а теперь узнает. Или, раньше у него были разрозненные знания а тут он что то структурировал. Или еще какая либо ценность?
Прочел две части текста и попытался для себя ответить на вопрос: о чем эти записки?
О том, как разрабатывается архитектура? О роли архитектора в этом процессе? О том, какие должны быть спецификации?
И если я пробую найти ответ уже на конкретный вопрос, то в статье вижу только общий набор клише. Либо, просто поднимается перечень вопросов, которые так же оставляются в статье без ответа.
Не знаю, выше видел много восторженных отзывов, но для меня это было, увы, потраченное время. Может быть есть что то, что я упустил?
Вроде в условии не сказано, что число должно встречаться РОВНО N/4. Тогда за константу можно найти ВСЕ такие последовательности, сколько бы их не было. Максимум все 4 )
1. Отпочковали фича-ветку от главной
2. разработали фичу (n коммитов).
3. во время разработки время от времени забирали себе основную ветку (к — служебных слияний).
4. один раз влили в основную ветку. — 1 слияние.
И да, я отношусь с тем, кто не понимает, зачем нужна чистая история. Всмысле, что в ней такого чистого после ребейза.
И да, в hg мы не используем jit-flow. Одна ветка = одна версия. Ветка со временем выходит в пререлиз и в релиз. В момент смены состояний даже коммита делать не нужно, т.к. статус релизности ветки имхо можно и нужно отслеживать на сервере интеграции а не в репозитории.
Испытывал технологию на ctp3.3 на боевых данных порядка 20Гб: на многих рабочих сценариях улучшение в 100 раз!
Однако есть и ложка дегтя: по необъяснимым для меня причинам время поднятия бд — несколько часов! Например детач и аттач бд на 20Gb у меня проходит 3 часа.
При аттаче в errorlog сыпятся:
2016-03-11 17:48:38.75 spid43s Error: 41383, Severity: 16, State: 124. 2016-03-11 17:48:38.75 spid43s An internal error occurred while running the DMV query. This was likely caused by concurrent DDL operations. Please retry the query.примерно раз в две секунды.
Если в релизе удастся побороть эти проблемы, то киллер-фича MSSQL 2016 — это inmemory OLTP!
AppModel.js:168 1: 7, 7
AppModel.js:168 2: 8, 6
AppModel.js:168 3: 7, 6
AppModel.js:168 4: 9, 5
AppModel.js:168 5: 7, 5
AppModel.js:168 6: 7, 8
AppModel.js:168 7: 7, 4
AppModel.js:168 8: 7, 3
AppModel.js:168 9: 8, 4
AppModel.js:168 10: 10, 4
AppModel.js:168 11: 6, 6
AppModel.js:168 12: 9, 3
AppModel.js:168 13: 9, 4
AppModel.js:168 14: 8, 2
AppModel.js:168 15: 11, 5
AppModel.js:168 16: 6, 4
AppModel.js:168 17: 5, 5
AppModel.js:168 18: 4, 4
AppModel.js:168 19: 8, 5
AppModel.js:168 20: 11, 3
AppModel.js:168 21: 10, 3
AppModel.js:168 22: 12, 2
AppModel.js:168 2: 8, 6
AppModel.js:168 3: 7, 6
AppModel.js:168 4: 7, 8
AppModel.js:168 5: 7, 5
AppModel.js:168 6: 5, 6
AppModel.js:168 7: 6, 7
AppModel.js:168 8: 8, 7
AppModel.js:168 9: 8, 5
AppModel.js:168 10: 5, 8
AppModel.js:168 11: 5, 7
AppModel.js:168 12: 8, 8
AppModel.js:168 13: 6, 8
AppModel.js:168 14: 6, 9
AppModel.js:168 15: 9, 6
AppModel.js:168 16: 8, 9
AppModel.js:168 17: 8, 10
AppModel.js:168 18: 7, 9
AppModel.js:168 19: 5, 9
AppModel.js:168 20: 6, 10
AppModel.js:168 21: 9, 7
AppModel.js:168 22: 7, 10
AppModel.js:168 23: 4, 7
AppModel.js:168 24: 3, 7
AppModel.js:168 25: 9, 8
AppModel.js:168 26: 9, 9
AppModel.js:168 27: 10, 9
AppModel.js:168 28: 5, 11
AppModel.js:168 29: 4, 12
AppModel.js:168 30: 8, 11
AppModel.js:168 31: 9, 12
AppModel.js:168 32: 7, 11
AppModel.js:168 33: 7, 12
AppModel.js:168 34: 6, 11
AppModel.js:168 35: 4, 11
AppModel.js:168 36: 9, 11
Играйте за 0.
AppModel.js:168 2: 8, 6
AppModel.js:168 3: 7, 6
AppModel.js:168 4: 7, 5
AppModel.js:168 5: 9, 7
AppModel.js:168 6: 6, 7
AppModel.js:168 7: 8, 7
AppModel.js:168 8: 6, 6
AppModel.js:168 9: 6, 5
AppModel.js:168 10: 9, 8
AppModel.js:168 11: 5, 7
AppModel.js:168 12: 10, 7
AppModel.js:168 13: 8, 9
AppModel.js:168 14: 6, 8
AppModel.js:168 15: 8, 8
AppModel.js:168 16: 10, 6
AppModel.js:168 17: 6, 10
AppModel.js:168 18: 7, 9
AppModel.js:168 19: 8, 10
AppModel.js:168 20: 8, 11
AppModel.js:168 21: 7, 10
AppModel.js:168 22: 9, 10
AppModel.js:168 23: 10, 9
AppModel.js:168 24: 9, 6
AppModel.js:168 25: 11, 6
AppModel.js:168 26: 8, 4
AppModel.js:168 27: 8, 5
AppModel.js:168 28: 9, 3
AppModel.js:168 29: 10, 2
AppModel.js:168 30: 10, 4
AppModel.js:168 31: 10, 5
AppModel.js:168 32: 9, 4
AppModel.js:168 33: 7, 4
AppModel.js:168 34: 9, 5
AppModel.js:168 35: 9, 2
AppModel.js:168 36: 7, 3
AppModel.js:168 37: 11, 7
AppModel.js:168 38: 6, 2
Размышляя над возможными исправлениями недостатков я уверен, что можно сделать алгоритм хранения с переменным размером бит на позицию. От 60 до 120 бит, в зависимости от того, как много фигур осталось на доске и на сколько хорошо подобраны узловые позиции.
Получив такое компактное хранение можно их пронумеровать и результат оценки для 9 фигур по принципу, схожему с Syzygy. Игра в эндшпиле для компьютера будет сводиться к довольно сложному получению порядкового номера всех полу-ходовых позиции и проверка их в базе на результат.
Понятно, что такое представление будет иметь недостатки, в виде того, что позиция представлено номером и при ее оценке не была известна информация о предыдущем ходе (взятие на проходе) а также возможности рокировки (но это и сейчас в эндшпильных таблицах отсутствует).
Зато можно хранить таблицу для 9 а то и 10 фигур на одном обычном компьютере! Отдельный вопрос: как быстро будет посчитана такая таблица, но это уже отдельная история.
Иначе я могу открыть в отдельном окне бразур в основной операционке. А виртуальная машина при этом не будет ловить событий смены активного окна.
У меня вопросов с целью понимания архитектуры и не было. Была публичная критика, которую я старался сделать конструктивной.
Предлагаю взять любую из глав в любой части. Например последнюю:
Поправьте меня, мне кажется у Вас тут две мысли:
1. Если не вкладываться, то компании когда нибудь станет плохо.
2. Все компании разные.
Отложим момент, что мне не удалось найти в этом разделе какого нибудь ответа на «когда». Видимо, Вы подразумеваете: «всегда, если хотим, чтобы компании было хорошо».
У меня к Вам следующий вопрос: что из этого раздела на три с половиной тысячи знаков является Вашим опытом? Можно ли привести какую то мысль и описать, как она стала результатом опыта? У меня это не получается.
Беру, например:
И вижу типовой шаблон: «архитектура влияет на все». Если ударится в философию, то любой процесс в компании влияет на другой любой процесс.
Для меня этот абзац обрел бы смысл, если бы Вы пояснили: какое влияние Вы имели ввиду, почему посчитали его важным и на каком примере из жизни. Сейчас же, простите мне мою уже сделанную оценку, это выглядит как клише.
Я не вижу ценности в таких мыслях. Т.е. я пробую представить человека, кто, например является или хочет стать архитектором и раньше он чего то не знал а теперь узнает. Или, раньше у него были разрозненные знания а тут он что то структурировал. Или еще какая либо ценность?
О том, как разрабатывается архитектура? О роли архитектора в этом процессе? О том, какие должны быть спецификации?
И если я пробую найти ответ уже на конкретный вопрос, то в статье вижу только общий набор клише. Либо, просто поднимается перечень вопросов, которые так же оставляются в статье без ответа.
Не знаю, выше видел много восторженных отзывов, но для меня это было, увы, потраченное время. Может быть есть что то, что я упустил?
Со своей стороны могу предложить в следующей статье, например, разобрать любую главу из Руководство Microsoft по проектированию архитектуры приложений.
Или, например, защитить концепцию, что Архитектор — это больше менеджер чем инженер.