Не рекомендовал бы изучать гит со статью с алиасами вместо реальных команд. Алиасы это вкусовщина и оптимизация имхо, даже не знаю стоит ли об этом писать в таком ключе.
никто и не говорит, что это специфика git, но часто именно это поведение VS становится причиной поломанных билдов. и именно из-за этого в истории git вижу докомиты по одному забытому проектному файлу.
я бы не сказал, что оно очевидно и удобно. когда ты редактируешь файл и в нем есть несохраненные изменения есть какая-то индикация этого, если изменил проектный файл ничего нет. добавил файл в проект нажал Ctrl-S, вроде бы должно хватать, а нет.
etw одна из самых недооценённых технологий windows. это очень производительная подсистема, мы использовали ее чтобы на лету получать «логи» и метрики с высоконагруженной биржевой системы без влияния на производительность системы.
удивительная история, спасибо за расследование. как будто уже сталкивался с таким. а как дела обстоят под виртуализацией? по идее тоже должно воспроизводится.
Вот любопытно. Я прошел ваш турнамент на архитектора в прошлом году в Польше, и по факту прошёл прямо там собеседование, потом завел профиль в вашей системе всё там сделал и всё. Вообще ничего не было со стороны вашей компании, тишина.
В целом, согласен с автором. Доброжелательность имеет значение для создания сплоченной команды в долгосрочной перспективе.
В данный момент я работаю в Европе, до этого работал в разных коллективах в России и могу сказать, что у нас огромная разница в культуре общения. В Европе, как мне кажется, более доброжелательны на работе, более вежливы в переписке и ревью.
Мне кажется главное в ревью и письмах не переходить на личности. Сам стараюсь констатировать факты и говорить, что-то вроде «We can get NullReferenceException here if ...».
Вообще большая и интересная тема, с опытом начал понимать, что правильная коммуникация на работе очень важна, наряду с профессиональными навыками.
Автору спасибо, что поделился интересным подходом к использованию возможностей языка, возможно это где-то хорошо применимо, но я бы не стал брать это как библиотеку и добавлять в свой проект.
Согласен с impwx и lair очень неоднозначные конструкции получились. Неверное, больше всего не нравится, что добавляются переменные в область видимости, и это, возможно, увеличит вероятность ошибки.
такого, насколько я знаю, не будет. в трансляции были официальные разборы задач и время от времени показывали экраны разных команд с кодом, если очень инетересно, можно почитать.
По первой части сам давно пользуюсь скриптами ola.hallengren.com. Они учитывают особенности разных версий SQL Server умеют создавать job'ы, пишут логи и имеют кучу настроек.
В дополнение к этому существует огромное недопонимание между декларацией типа и его реальным значением. Например, в .NET Array принимает Integer как индекс в диапазоне [-2^31, 2^31], поэтому мы декларируем поддержку для чисел -1,-2,… как значений индекса. В это же время допустимы только неотрицательные числа, т.е. [0, 2^31]. Для честного и ясного кода должно быть обозначение Array[NonnegativeInteger].
.NET поддерживает отрицательные индексы в массивах.
В этом случае компилятор проверяет, что речь идет о размере и он не может быть отрицательным:
var array = new int[-1];
Но отрицательные индексы допустимы:
var array = Array.CreateInstance(typeof(int), new[] { 10 }, new[] { -5 });
for (int i = -5; i < 5; i++)
{
array.SetValue(i, i);
}
я бы не сказал, что оно очевидно и удобно. когда ты редактируешь файл и в нем есть несохраненные изменения есть какая-то индикация этого, если изменил проектный файл ничего нет. добавил файл в проект нажал Ctrl-S, вроде бы должно хватать, а нет.
ну ещё из специфичного — в Visual Studio нужно сделать Save All, иначе изменения в проектых не попадут на диск.
aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpus-are-sometimes-50-slower-how-intel-has-broken-existing-code/#comment-274
В данном случае у вас есть фидбек?
В данный момент я работаю в Европе, до этого работал в разных коллективах в России и могу сказать, что у нас огромная разница в культуре общения. В Европе, как мне кажется, более доброжелательны на работе, более вежливы в переписке и ревью.
Мне кажется главное в ревью и письмах не переходить на личности. Сам стараюсь констатировать факты и говорить, что-то вроде «We can get NullReferenceException here if ...».
Вообще большая и интересная тема, с опытом начал понимать, что правильная коммуникация на работе очень важна, наряду с профессиональными навыками.
Согласен с impwx и lair очень неоднозначные конструкции получились. Неверное, больше всего не нравится, что добавляются переменные в область видимости, и это, возможно, увеличит вероятность ошибки.
.NET поддерживает отрицательные индексы в массивах.
В этом случае компилятор проверяет, что речь идет о размере и он не может быть отрицательным:
Но отрицательные индексы допустимы: