Pull to refresh
4
0
Андрей Антюфеев @sitox

User

Send message

Это просто как пример, про следовать судьбе или сделать ее самому. Грань неуловимая. Я вот очень часто из нихера создавал возможности, именно создавал, там их изначально не было. А если бы не подсуетился бы, ничего бы и не было.

Так что херня какая то это дао ) кому-то подходит наверное

Тогда можно сказать, что возможность есть всегда. Надо пойти и сделать.

ну а вот если это следование судьбы вас завела туда где вам не нравится? тогда сидеть и ждать пока что-то изменится и появится возможность или поставить цель и вылезти из "задницы" ? Допустим вы в отношениях, которые случились и вы поняли что "не то", выходить из них стресс и боль.

крч для лентяев каких-то =)

Добрый день. Потому что это не перевод, в одном случае это документация, а здесь блог пост. (оба написаны мною)
Здесь, я написал о том, что мне показалось важным.
Хотя, соглашусь, что стоит добавить ссылку на документацию в статье.
Мы рассматриваем такую возможность. Несколько тестов показали, что прирост производительность есть, но не всегда.(Увас есть какие-то пример когда это сильно улучшило ситуацию?)
Если мы решим добавить Rebuild как ещё одну рекомендацию внутри помощника, то её можно будет включить автоматически.

Есть неплохая статья по автоматизации здесь но пока да, выполнение скрипта.
К сожалению не знаком с SharePoint насколько глубоко, чтобы помочь. Могу только посоветовать описать очень подробно проблему на сайте вроде Stackoverflow. Может кто-нибудь из команды SharePoint следит за этим. :)
Лучше поздно, чем никогда :)

1) Index Advisor рекомендует те индексы, которые помогают конкретным запросам. (так же оценивает предполагаемое влияние). Так может случиться, что созданный индекс, не будет таким эфективным. (в основном потому что характер нагрузки изменился). Для этого существует этап верификации, когда оценивается общая картина нагрузки, и если созданый индекс ухудшает её, он автоматически удаляется.
2) Это интересная идея, но пока Index Advisor не может предсказать как будет себя вести только что созданный индекс. Во многом потому что тут много переменных,(нагрузка, использование и т.д.) для того что бы дать предсказание хорошего качества.
3) Это очень интересная идея, на данный момент Index Advisor не рассматривает влияние индекса на продолжительность запросов, кол-во блокировок. Но это то, на что бы обязательно обратим внимание в следующих версиях.
4) Сейчас нет, но мы рабоает над этим функционалом. Скоро мы будем выдавать рекомендации, какие индексы не используются и их можно удалить. Stay tuned, как говорится ;)
Индекс действительно создаётся, и наблюдается в течении некоторого времени, если производительность падает, то он удаляется.
Нет, Index Advisor не смотрит на текст запроса. Он смотрит на характер доступа к данным и нагрузку. Если нагрузка постоянная и есть место для улучшения, он рекомендует индекс.

Насколько я понимаю, подсказки в запросах, говорят какой план выполнения запроса выбрать. И скорее всего этот план уже достаточно хороший.
(В этом SharePoint очень строг, разработчики предпочитают все контролировать сами)
Да, удалять индексы не стоит.
Надеюсь в следующий раз, Index Advisor поможет вам сэкономить время и силы на наблюдении за запросами.
Телеметрия собирается после создания базы данных, включение Index Advisor на это не влияет. (так же как она не влияет на производительность)
Так может случиться, что ваша схема не требует улучшения в данный момент, тогда IA ничего не будет рекомендовать. (Поздравляю!)

Когда IA обнаружит постоянную нагрузку, которую можно уменьшить с помощью индекса, вы увидите новую рекомендацию.
Процесс ожидания зависит от вашей нагрузки, и IA должен быть уверен, прежде чем рекомендовать. Могу сказать, что пару часов будет точно недостаточно.

Вероятно, в будущем, модель оповещения о рекомендации измениться от pull (когда вы проверяете каждую базу данных) на push, когда вам приходит скажем письмо о новой рекомендации.

Давайте посмотрим на людей на этой фотографии, по мне они не очень похожи на программистов.

Такие условия хороши только для менеджеров, сейлзов и других бездельников (шутка, но они мало делают работы, в которой необходимо состояние потока). Решения о создании таких офисов как раз и идут от тех, у кого язык подвешен и те кто рядом с руководством, мотивируют они это креативностью и необходимостью collaboration. Когда решение принято и ясно, что делать, то программисту ничего не нужно из этого, ему нужно, что бы его никто не отвлекал и всё.

Я раньше тоже думал, что опен спейс, это круто, так делают в фейсбуках и гуглах. Но потом я поработал в своем кабинете, отличный опыт, продуктивность в разы повышается, креативность и collaboration не страдает, всегда можно поговорить с коллегами за обедом, или на скраме, нужно, что то обсудить, сходил к коллеге в кабине.

Просто аренда дорогая, вот они и продают эту идеи как нечто очень крутое.
А почему нельзя было искать контракт пока находились на постоянной работе? Или у постоянной работы слишком большой notice period для контракта?
Где посоветуете искать контракты?
вроде теперь можно и для FB такое сделать
Приятно читать о таких людях, в таких примерах должна черпать вдохновение нынешняя молодёжь, чтобы двигать Россию вперёд, а не в возращению к религии.
а передача данных идёт по защищённому каналу?
хорошо постарались, но Я всё равно не буду пользоваться Metro UI, только classic desktop
Я считаю один из самых лучших курсов по OS это совмещённый с практикой.
Мне конретно понравилося вот этот
www.stanford.edu/class/cs140/projects/pintos/pintos_1.html +
www.stanford.edu/class/cs140/projects/pintos/pintos.pdf

4 проекта в которых предлагается реализовать Threading system, User Programs, Virtual Memory, Filesystem
Имеет, Я даже в инстаграм постил с него

Information

Rating
Does not participate
Location
Латвия
Registered
Activity