Мне кажется, что если бы причина была в этом, то больше страдали бы мелкие организмы, а крупные всё-таки ещё могли какое-то время давать здоровое потомство. Но на деле ведь вымирали постоянно гиганты. Хотя может и мелкие тоже, просто о них не так много известно
Здорово переведено, статья хороша. Только похоже, что при переводе потерялся смысл там, где идёт речь о килотоннах, которые никак не связаны с тоннами (даже метрическими). Судя по заметке в Википедии, производная величина вполне себе связана с метрической тонной. И англоязычную версию глянул, но и там порядок: «...approximate energy released in the detonation of a metric ton (1,000 kilograms) of TNT». Неясно, что имел в виду автор, но тут какой-то блудняк.
Но ещё труднее понять, что переведено все правильно, а запутать нас пытается автор, когда говорит о «количестве мегатонн, которое создаст взрыв»: number of megatonnes that your nuke’s detonation will create.
Резюмируя, из косяков в этом фрагменте остаётся только tons/tonnes. Ну а почему бы и не указать в разных единицах, собственно? А что до трёх стран, игнорирующих метрическую систему... может создатели видели будущее человечества таким, что эти три страны прогнут всех остальных, и мы все в этом будущем путаемся с тонсами и тоннесами :)
А что с гонкой? Вы пробовали ab в 5 потоков. Полагаю, у вас больше одного nginx-воркера и больше одного fpm. Не смотрели, сколько раз фактически выполнился скрипт?
Я имею в виду, пока кэша не существует, но другой воркер прямо сейчас обрабатывает запрос, который может вернуть нужный результат, то как эту ситуацию разрулит nginx?
Мне кажется, что если бы библиотека и была полезной, то как раз классификацией.
Что могло быть полезного в бутстрапе с модификаторами .text-1, .text-2 или .block-1.block-2.block-n?
Собирался недавно идти на Юнону со словами «дайте смартфон за 3 тыщи», потому что в привычных мне магазинах я нашел только достаточно бодрые андроиды за 4.5+ килоруб — старьё теперь сложно найти в продаже.
Headless — безоконный режим с рендером по требованию, а headed, надо полагать, наоборот — привычный, в окне, с адресной строкой, табами, неумещающимися в узком экране
По-моему, статья не выдвигает опровержения, что «программировать сложно». Да, иногда трудности преувеличивают. Но аргументы вроде «это просто наша работа» и «нам всего-то нужно сделать все правильно», как по мне, не противоречат утверждению, что научиться хорошо программировать — сложно. Программировать, конечно, несложно, если ты это умеешь.
Хирург хорошо понимает то, что делает, и, думаю, что он сможет назвать это «несложным». Но сколько он этому учился? Ни в коем случае не хочу задеть ни одного медика, но и болезни — тоже не все смертельные. Так что, подобное противопоставление мне видится неуместным.
Я в веду к тому что всему нужно учиться. И некритичность ошибки программиста компенсируется необходимостью почти непрерывного углубления в дебри постоянно расширяющейся предметной области.
Type-хинты радуют. Не знал о том, что можно было указывать на callable. Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?
Прямо сегодня столкнулся с тем, что shr не трогает старший бит. Зачем так сделали? Неужто все эту операцию только для деления на 2 используют?
На моей машине в Chrome 43.0.2357.81 m 1M объектов {} создается за ≈1.5 сек, в то время как new AssocArray занимает ≈1.7 сек, а Object.create(null) — ≈2.1 сек.
Если это нужно для пары несложных страниц на всю систему (которая, как часто бывает, живет под девизом «нужно приспосабливаться под текущие условия — так сложилось исторически»), то все эти домыслы не к месту.
Не знаю — я так и написал.
Эксперимент с дополнительными хедерами провалился: они ничего не дают.
onreadystatechange срабатывает, но в responseText — пусто. Срабатывает столько раз, сколько пришло байт, но тело ответа пустое, а потом, когда тело становится длиннее волшебного числа 8 (в моем случае на самом деле не 20) — responseText моментально преобразуется в строку из 8 байт.
У меня были догадки на этот счет, которые упираются в Apache и Nagle. Но после наблюдений они разошлись с догадками и я не стал умничать и вводить читателя в заблуждение, а спросил.
Еще дополнение. Уже после публикации статьи я наткнулся на ситуацию в Хроме: событие onreadystatechange отрабатывало должным образом, только если Content-Type != text/plain. Если text/plain, то Хром, по видимому, складывал все в какой-то свой буфер, а уже после EOF показывал все полученные данные разом. Даже если поменять на text/unknown или text/something, проблема улетучивалась.
Существует метод XMLHttpRequest.abort(), который я пробросил в своем этом классе-обертке. В примере это есть: кнопка старта играет и роль кнопки для остановки.
Предположу, что офигенно быстро вращающееся сильное магнитное поле
UPD Прошу прощения, оно там не вращается. Ну тогда просто внезапно возникающее сильное магнитное поле
Мне кажется, что если бы причина была в этом, то больше страдали бы мелкие организмы, а крупные всё-таки ещё могли какое-то время давать здоровое потомство. Но на деле ведь вымирали постоянно гиганты. Хотя может и мелкие тоже, просто о них не так много известно
В современном айти даже высмеиваются попытки написать самостоятельно
Здорово переведено, статья хороша. Только похоже, что при переводе потерялся смысл там, где идёт речь о килотоннах, которые никак не связаны с тоннами (даже метрическими). Судя по заметке в Википедии, производная величина вполне себе связана с метрической тонной. И англоязычную версию глянул, но и там порядок: «...approximate energy released in the detonation of a metric ton (1,000 kilograms) of TNT». Неясно, что имел в виду автор, но тут какой-то блудняк.
Но ещё труднее понять, что переведено все правильно, а запутать нас пытается автор, когда говорит о «количестве мегатонн, которое создаст взрыв»: number of megatonnes that your nuke’s detonation will create.
Резюмируя, из косяков в этом фрагменте остаётся только tons/tonnes. Ну а почему бы и не указать в разных единицах, собственно? А что до трёх стран, игнорирующих метрическую систему... может создатели видели будущее человечества таким, что эти три страны прогнут всех остальных, и мы все в этом будущем путаемся с тонсами и тоннесами :)
Любой перенасыщенный длинными инструкциями язык станет легко читать, если привыкнуть к обилию в нём длинных инструкций ;)
Для статики вы можете разве что включить sendfile. Но и так всё хорошо кэшируется на уровне page cache
А что с гонкой? Вы пробовали ab в 5 потоков. Полагаю, у вас больше одного nginx-воркера и больше одного fpm. Не смотрели, сколько раз фактически выполнился скрипт?
Я имею в виду, пока кэша не существует, но другой воркер прямо сейчас обрабатывает запрос, который может вернуть нужный результат, то как эту ситуацию разрулит nginx?
Поли чем тут дырки в массиве, когда тестировалось на одинаковых массивах без дырок?
Мне кажется, что если бы библиотека и была полезной, то как раз классификацией.
Что могло быть полезного в бутстрапе с модификаторами
.text-1,.text-2или.block-1.block-2.block-n?Хирург хорошо понимает то, что делает, и, думаю, что он сможет назвать это «несложным». Но сколько он этому учился? Ни в коем случае не хочу задеть ни одного медика, но и болезни — тоже не все смертельные. Так что, подобное противопоставление мне видится неуместным.
Я в веду к тому что всему нужно учиться. И некритичность ошибки программиста компенсируется необходимостью почти непрерывного углубления в дебри постоянно расширяющейся предметной области.
Прямо сегодня столкнулся с тем, что shr не трогает старший бит. Зачем так сделали? Неужто все эту операцию только для деления на 2 используют?
Вопрос: как с производительностью (полагаю, все неважно) и как самочувствие GC после всего этого?
Смысл, ведь, тот же?
А тест производительности что-то врет, видимо.
На моей машине в Chrome 43.0.2357.81 m 1M объектов {} создается за ≈1.5 сек, в то время как new AssocArray занимает ≈1.7 сек, а Object.create(null) — ≈2.1 сек.
Эксперимент с дополнительными хедерами провалился: они ничего не дают.
onreadystatechange срабатывает, но в responseText — пусто. Срабатывает столько раз, сколько пришло байт, но тело ответа пустое, а потом, когда тело становится длиннее волшебного числа 8 (в моем случае на самом деле не 20) — responseText моментально преобразуется в строку из 8 байт.
У меня были догадки на этот счет, которые упираются в Apache и Nagle. Но после наблюдений они разошлись с догадками и я не стал умничать и вводить читателя в заблуждение, а спросил.
Быть может, у вас есть точный ответ?
Еще дополнение. Уже после публикации статьи я наткнулся на ситуацию в Хроме: событие onreadystatechange отрабатывало должным образом, только если Content-Type != text/plain. Если text/plain, то Хром, по видимому, складывал все в какой-то свой буфер, а уже после EOF показывал все полученные данные разом. Даже если поменять на text/unknown или text/something, проблема улетучивалась.