иммутабельность хорошо, но недостаточно. Ключевые слова «Сервер приложений».
Конечный пользователь берет и устанавливает несколько экземпляров приложения, с разными контекстами, на одной виртуальной машине. Какой будет результат?
Про библиотеки и говорить нечего
На самом деле, тема статьи намекает.
Для бэкенд-разработчика статика — зло очевидное. Да и за глобальными объектами нужно внимательно приглядывать. Тут даже кода не надо приводить, только 2 волшебных слова: «сервер приложений»
Хорошая статья.
Тоже в свое время пришлось заниматься интернационализацией web-приложений, и работа с календарями оказалась немаловажной её частью. Вот от меня 2 копейки.
1) site.icu-project.org — проект, включающий в себя, кроме прочего, классы для работы со временем за пределами григорианского календаря. Какие — можно посмотреть тут
2) В статье встречается Calendar.getInstance(). Данный метод теоретически может вернуть не григорианский календарь (хотя практически, на данный момент — нет). Поэтому в проектах, распределенных по разным странам, я бы избегал использования данного метода, заменяя на new GregorianCalendar(). Просто для того, чтобы быть уверенным, что и в будущем летоисчисление и манипуляции с датами во всех подсистемах будут одинаковыми.
Ну, 1с — одна такая, её приходится брать в расчет.
А в «зрелых» системах fb в расчет не принимают, там oracle, pgsql, mysql, на крайний случай — hsql (я про java). Квотировать идентификаторы — значит, вносить в рабочий код дополнительные метаданные, и ради fb никто этого делать не станет. Просто используют одну из альтернативных СУБД.
Так что более гибкая политика идентификаторов в версии 3.5, скажем, позволила бы fb поконкурировать со «старшими», и пошла бы только на пользу
Хороший сервер, но приходится частенько от него отказываться из-за зарезервированных слов. Их нельзя использовать не только там, где они имеют значение по контексту, но и везде.
Например, VALUE — имеет значение только в определении ограничений для домена, но назвать столбец таблицы так нельзя. Берешь готовую систему — на любой сервер встает, на FB не хочет, и только потому, что там столбец VALUE — криминал
Затем МКС будет снижаться, смещаясь к востоку, и в 22:48:52 войдет в тень Земли
. Конечно, не с востока на восток, а все-таки с запада на восток, по направлению вращения Земли. Да и Франция, упоминающаяся в тексте, находится на западе
Ну нельзя так :). Хоть выводы и правильные, но физические законы, из которых они выведены, сформулированы неуверенно, а то и неверно.
имеет вид экспоненциальной (логарифмической) функции
— неплохо бы определиться. На самом деле разница температуры остывающего тела и окружающей среды изменяется по экспоненте, нет тут никакой логарифмической функции.
Количество тепла, которое тело отдаёт/принимает, пропорционально объёму. Сопротивление передачи пропорционально поверхности.
— Сформулировано с точностью до наоборот. На самом деле, коэффициент в экспоненте (e-kt), по которой изменяется температура, напрямую зависит от площади поверхности. Чем больше поверхность, тем лучше теплообмен. О чем и говориться дальше
Значит, чем больше соотношение поверхности к объёму, тем быстрее идёт процесс передачи тепла.
Прочитал, действительно, беру свои слова обратно. 69600 тетрамин в спец-версии тертиса (только из прямых и обратных Z) или 127200 Z-тетрамин из любого расклада (а значит, из классической версии тетриса) неизбежно приводят к проигрышу. Поскольку в бесконечной последовательности обязательно выпадет последовательность из 127200 Z, то бесконечная игра неизбежно проигрышная.
Но тут сразу возникает вопрос для исследования:
Тетрис — это компьютерная игра, и для её генерации используется некий детерминированный ДСЧ. Понятно, что можно взять «плохой» генератор, выдающий только Z, но в такую игру играть никто не будет. Предположим, что это все-таки ДСЧ с равномерным распределением, котором фигура z-типа выпадает с вероятностью 2/7. И второе предположение — там не используются большие таблицы (во времена изобретения тетриса с памятью было туго).
Скорее всего, в оригинальной версии использовался просто линейный генератор, с циклом длиной P, где P — некое большое протое число, и о бесконечных последовательностях речь не идет.
К чему клоню. В принципе, можно ли было на 8/16 битных процессорах построить детерминированный ГСЧ с равномерным распределением, но в котором компьютер неизбежно выигрывает?
Начать с того, что из 7 фигур тетриса НЕВОЗМОЖНО собрать моноблок со стороной 8: 4*7=28. Кроме того, в «классической» версии игрок видит не только текущую фигуру, но и следующую, что значительно упрощает «упаковку».
Так что в доказательство не верю.
А опытные игроки так вообще играли, стартуя с наполовину заполненного стакана. Разобрал до дна — считай вииграл, дальше было неинтересно
habrahabr.ru/post/240301/ habrahabr.ru/post/239423/
Если резюмировать: в первую среду каждого года происходит переход на летнее время. Кроме того, обратный переход в последнее воскресенье октября. Касается только тех ОС, где установлен патч с RTZ.
Слышал такое предположение, что браузеры просто распространяют установки текущего года вперед и назад по времени, и начиная со следующего года всё устаканится (в следующем году переходов на зимнее время уже не будет). А пока — патчим кто как может
В первую среду каждого года этот нелепый переход с зимнего на летнее время. Но это ладно, в основном попадает на праздники.
Но ведь логика подсказывает, что где-то в середине года должен быть и обратный переход! Может, RTZ — это часть санкций? :)
Присоединяюсь. Тем более странно называть это подвигом.
Автору рекомендую посмотреть предыдущие топики на тему JS+RTZ, например Хром, укравший рождество или Новая таймзона — новые проблемы, может, появятся более дельные мысли
Не только от ОС, но и от факта установки апдейта KB2998527. Win10 по ссылке нет, и не удивительно — систему анонсировали позже. А в принципе, таймзона RTZ есть в Win10?
Каким-то образом отразилось и на Firefox. 26 октября выводится 2 раза (запись к врачу на портале pgu.mos.ru):
Тот же datepicker из jquery ui, на этот раз в FF 33.0
написал сегодня похожее сообщение, пока не стал удалять, так как в нем указал возможное решение.
Календарь в jquery ui я исправил следующим образом:
— если старая версия, то необходимо поменять функцию
/* Find the number of days in a given month. */
_getDaysInMonth: function(year, month) {
return new Date(year, month+1, 0).getDate();
},
Без данного исправления декабрь 2013 состоял из 1 дня (тут украли не то что рождество, а целый месяц). В актуальных версиях эта функция работает правильно.
Кроме того, необходимо изменить функцию вычисления дня недели первого дня месяца, добавив к дате хотя бы 1 час (4-й аргумент):
/* Find the day of the week of the first of a month. */
_getFirstDayOfMonth: function(year, month) {
return new Date(year, month, 1, 1).getDay();
},
И это не проблема 2020 года. Без данного исправления неправильно отображается уже январь 2014 — как будто он начался во вторник.
Проблема с датами в хроме (в ближайшем обновлении будет исправлена) и в эксплорере. После указанного исправления календарь везде работает нормально.
Конечный пользователь берет и устанавливает несколько экземпляров приложения, с разными контекстами, на одной виртуальной машине. Какой будет результат?
Про библиотеки и говорить нечего
Для бэкенд-разработчика статика — зло очевидное. Да и за глобальными объектами нужно внимательно приглядывать. Тут даже кода не надо приводить, только 2 волшебных слова: «сервер приложений»
Тоже в свое время пришлось заниматься интернационализацией web-приложений, и работа с календарями оказалась немаловажной её частью. Вот от меня 2 копейки.
1) site.icu-project.org — проект, включающий в себя, кроме прочего, классы для работы со временем за пределами григорианского календаря. Какие — можно посмотреть тут
2) В статье встречается Calendar.getInstance(). Данный метод теоретически может вернуть не григорианский календарь (хотя практически, на данный момент — нет). Поэтому в проектах, распределенных по разным странам, я бы избегал использования данного метода, заменяя на new GregorianCalendar(). Просто для того, чтобы быть уверенным, что и в будущем летоисчисление и манипуляции с датами во всех подсистемах будут одинаковыми.
А в «зрелых» системах fb в расчет не принимают, там oracle, pgsql, mysql, на крайний случай — hsql (я про java). Квотировать идентификаторы — значит, вносить в рабочий код дополнительные метаданные, и ради fb никто этого делать не станет. Просто используют одну из альтернативных СУБД.
Так что более гибкая политика идентификаторов в версии 3.5, скажем, позволила бы fb поконкурировать со «старшими», и пошла бы только на пользу
Например, VALUE — имеет значение только в определении ограничений для домена, но назвать столбец таблицы так нельзя. Берешь готовую систему — на любой сервер встает, на FB не хочет, и только потому, что там столбец VALUE — криминал
— неплохо бы определиться. На самом деле разница температуры остывающего тела и окружающей среды изменяется по экспоненте, нет тут никакой логарифмической функции.
— Сформулировано с точностью до наоборот. На самом деле, коэффициент в экспоненте (e-kt), по которой изменяется температура, напрямую зависит от площади поверхности. Чем больше поверхность, тем лучше теплообмен. О чем и говориться дальше
Но тут сразу возникает вопрос для исследования:
Тетрис — это компьютерная игра, и для её генерации используется некий детерминированный ДСЧ. Понятно, что можно взять «плохой» генератор, выдающий только Z, но в такую игру играть никто не будет. Предположим, что это все-таки ДСЧ с равномерным распределением, котором фигура z-типа выпадает с вероятностью 2/7. И второе предположение — там не используются большие таблицы (во времена изобретения тетриса с памятью было туго).
Скорее всего, в оригинальной версии использовался просто линейный генератор, с циклом длиной P, где P — некое большое протое число, и о бесконечных последовательностях речь не идет.
К чему клоню. В принципе, можно ли было на 8/16 битных процессорах построить детерминированный ГСЧ с равномерным распределением, но в котором компьютер неизбежно выигрывает?
Так что в доказательство не верю.
А опытные игроки так вообще играли, стартуя с наполовину заполненного стакана. Разобрал до дна — считай вииграл, дальше было неинтересно
habrahabr.ru/post/239423/
Если резюмировать: в первую среду каждого года происходит переход на летнее время. Кроме того, обратный переход в последнее воскресенье октября. Касается только тех ОС, где установлен патч с RTZ.
Слышал такое предположение, что браузеры просто распространяют установки текущего года вперед и назад по времени, и начиная со следующего года всё устаканится (в следующем году переходов на зимнее время уже не будет). А пока — патчим кто как может
Но ведь логика подсказывает, что где-то в середине года должен быть и обратный переход! Может, RTZ — это часть санкций? :)
Автору рекомендую посмотреть предыдущие топики на тему JS+RTZ, например Хром, укравший рождество или Новая таймзона — новые проблемы, может, появятся более дельные мысли
В хроме то же самое
Тот же datepicker из jquery ui, на этот раз в FF 33.0
Календарь в jquery ui я исправил следующим образом:
— если старая версия, то необходимо поменять функцию
Без данного исправления декабрь 2013 состоял из 1 дня (тут украли не то что рождество, а целый месяц). В актуальных версиях эта функция работает правильно.
Кроме того, необходимо изменить функцию вычисления дня недели первого дня месяца, добавив к дате хотя бы 1 час (4-й аргумент):
И это не проблема 2020 года. Без данного исправления неправильно отображается уже январь 2014 — как будто он начался во вторник.
Проблема с датами в хроме (в ближайшем обновлении будет исправлена) и в эксплорере. После указанного исправления календарь везде работает нормально.