Количество комментариев и количество просмотров так же сохраняется при каждом замере.
По просмотрам — графики просмотров очень часто выглядят как лесенки, по ним сложно ориентироваться. Похоже, что это особенность самого YouTube. Иногда в комментариях можно встретить возмущения по поводу, что заморозили просмотры. Думаю, что никто их специально не замораживает, просто просмотры подсчитываются с задержкой.
Так же была идея искать одинаковые комментарии, но пока до этого руки не дошли.
Неточность #3. Об операторе ==
«No matter what type is involved, a == a is always true.»
Это предложение не является неточностью, оно очень неудачно выдернуто из контекста:
… you need to keep in mind the mathematical properties of equality: Equality is reflexive, symmetric, and transitive. The reflexive property means that any object is equal to itself. No matter what type is involved, a == a is always true.
То есть
a == a is always true
это всего лишь определение рефлексивности.
Вообще же автор пишет о том, как должен работать оператор сравнения в том случае если программист решит его переопределить, а не о том как он на самом деле работает.
Интерфейсы всегда имеют ссылочный тип. Поэтому в данном случае реализовывать интерфейс в структуре имеет мало смысла. Потому что если бы foreach умел работать только интерфейсом, то все равно пришлось бы осуществлять операцию упаковки для этой самой структуры. И не существовало бы способа обойтись без упаковки.
Эх, все надо тестировать.
Действительно, int.MinValue по модулю на единицу больше, чем int.MaxValue. А так как в промежуточном вычислении в качестве буфера используется положительный диапазон от int, то int.MinValue в него не входит.
По всей видимости, самым простым способом исправить этот косяк — это внести следующие исправления
unsafe public static int ToInt(string s)
{
....
result = result * 10 - (ch - '0');
.....
return (isNegative) ? result : -result;
}
Точно, совсем забыл про вариант с плюсом, спасибо, сейчас исправлю.
Предложенный вами вариант быстрее моего в среднем на 6,8%. Однако в этом варианте немного другая логика: убираются ведущие пробелы, и нет проверки на входной параметр (пустая строка преобразуется в 0, «12b» преобразуется в 12). Хотя если даже добавить такую проверку, то все равно она будет работать быстрее, в среднем на 5%.
проверялся следующий код:
unsafe public static int ToIntNotMy(string s)
{
if (s == null)
{
throw new ArgumentException();
}
int sign = 1, n = 0;
fixed (char* p = s)
{
char* pS = p;
while (*pS == ' ') pS++;
switch (*pS)
{
case '-':
sign = -1;
pS++;
break;
case '+':
pS++;
break;
case '\0':
throw new ArgumentException();
}
while (*pS >= '0' && *pS <= '9')
n = 10 * n + *(pS++) - '0';
if (*pS != '\0') throw new ArgumentException();
}
return sign * n;
}
По поводу потребителей, очень понравилось как Стругацие это описали (специально нашел):
Храм — это же не всякому дано… Я же не спорю, что это достояние меньшинства, дело натуры человеческой… Но ты послушай. Я тебе сейчас расскажу, как мне это представляется. У храма есть, Изя принялся загибать пальцы, строители. Это те, кто его возводит. Затем, скажем, м-м-м… тьфу, черт, слово не подберу, лезет все религиозная терминология… Ну ладно, пускай — жрецы. Это те, кто носит его в себе. Те, через души которых он растет и в душах которых существует… И есть потребители — те, кто, так сказать, вкушает от него… Так вот Пушкин — это строитель. Я — это жрец. А ты — потребитель… И не кривись, дурак! Это же очень здорово! Ведь храм без потребителя был бы вообще лишен человеческого смысла. Ты, балда, подумай, как тебе повезло! Ведь это же нужны годы и годы специальной обработки, промывания мозгов, хитроумнейшие системы обмана, чтобы подвигнуть тебя, потребителя, на разрушение храма… А уж такого, каким ты стал теперь, и вообще нельзя на такое дело толкнуть, разве что под угрозой смерти!.. Ты подумай, сундук ты с клопами, ведь такие, как ты, — это же тоже малейшее меньшинство! Большинству ведь только мигни, разреши только — с гиком пойдут крушить ломами, факелами пойдут жечь… было уже такое, неоднократно было! И будет, наверное, еще не раз!.. А ты жалуешься! Да ведь если вообще можно поставить вопрос: для чего храм? — ответ будет один-единственный: для тебя!..
Тут каждый выбирает что ему ближе. Я вот привык rake — файлами подобные вещи собирать. И скрипты тут примитивные на самом деле:)
И какое решение не выбирай — все равно всему учиться надо. Сборка при помощи ant зависит от разработчика, который знает ant, при помощи Rhino — нужно знать Rhino, при помощи grunt — ну вы поняли:)
1. Чем вам так руби не угодил?:) Или есть какое-то правило, что Javascript можно только javascript'ом собирать?
2. Тот же Rhino в качестве зависимости Джаву тянет. Следуя вашей логике: зачем нам Mozilla Rhino (Java), ведь мы же собираем javascript проект.
Я не создавал систему сборки зависимостей, я лишь описал существующую. И по мне так описанная мной система как минимум не хуже того же grunt'а. Более того, по доступным из коробки возможностям она даже превосходит ее.
А так, воспользоваться Rhino конечно можно. Другой вопрос, будет ли это удобнее.
Разработчики jQuery круты:)
Но у меня какой-то необъяснимый страх перед файлами размером под 1000 строк кода. Поэтому стараюсь все раскидывать по маленьким файлам, а в в итоге их как-то многовато получается.
Можно, но тут порядок сборки жестко прописывается в конфиге. И если для двух файлов понадобилось столько кода, то что же будет в более сложных случаях?
Вариант с «require» мне все-таки нравится гораздо больше. Проще прописать в файле project2.js:
Действительно, классный проект. Сейчас просмотрел его документацию, остался один вопрос: можно ли каким-нибудь образом «из коробки» влиять на порядок объединения файлов? Вот, как в моем примере: если в третьем файле объявляются какие-нибудь функции, которые требуются во втором, то при сборке неплохо было бы, что бы третий файл стоял «выше» второго. При большом количестве файлов, в конфиге вручную прописывать порядок, понятное дело, не вариант.
А так, размер конфигурационных файлов grunt'а не многим меньше чем вариант с Rake::Pipeline, насколько я понимаю.
По просмотрам — графики просмотров очень часто выглядят как лесенки, по ним сложно ориентироваться. Похоже, что это особенность самого YouTube. Иногда в комментариях можно встретить возмущения по поводу, что заморозили просмотры. Думаю, что никто их специально не замораживает, просто просмотры подсчитываются с задержкой.
Так же была идея искать одинаковые комментарии, но пока до этого руки не дошли.
Это предложение не является неточностью, оно очень неудачно выдернуто из контекста:
То есть это всего лишь определение рефлексивности.
Вообще же автор пишет о том, как должен работать оператор сравнения в том случае если программист решит его переопределить, а не о том как он на самом деле работает.
Действительно, int.MinValue по модулю на единицу больше, чем int.MaxValue. А так как в промежуточном вычислении в качестве буфера используется положительный диапазон от int, то int.MinValue в него не входит.
По всей видимости, самым простым способом исправить этот косяк — это внести следующие исправления
так же не будет выполнено.
Проверка на ведущие пробелы на скорость почти не повлияла: так же на ~5% преимущество.
Внимательности не хватает.
Предложенный вами вариант быстрее моего в среднем на 6,8%. Однако в этом варианте немного другая логика: убираются ведущие пробелы, и нет проверки на входной параметр (пустая строка преобразуется в 0, «12b» преобразуется в 12). Хотя если даже добавить такую проверку, то все равно она будет работать быстрее, в среднем на 5%.
проверялся следующий код:
Так что не надо комплексовать:-)
И какое решение не выбирай — все равно всему учиться надо. Сборка при помощи ant зависит от разработчика, который знает ant, при помощи Rhino — нужно знать Rhino, при помощи grunt — ну вы поняли:)
2. Тот же Rhino в качестве зависимости Джаву тянет. Следуя вашей логике: зачем нам Mozilla Rhino (Java), ведь мы же собираем javascript проект.
Я не создавал систему сборки зависимостей, я лишь описал существующую. И по мне так описанная мной система как минимум не хуже того же grunt'а. Более того, по доступным из коробки возможностям она даже превосходит ее.
А так, воспользоваться Rhino конечно можно. Другой вопрос, будет ли это удобнее.
Но у меня какой-то необъяснимый страх перед файлами размером под 1000 строк кода. Поэтому стараюсь все раскидывать по маленьким файлам, а в в итоге их как-то многовато получается.
Вариант с «require» мне все-таки нравится гораздо больше. Проще прописать в файле project2.js:
А так, размер конфигурационных файлов grunt'а не многим меньше чем вариант с Rake::Pipeline, насколько я понимаю.