Ну так, содержимое — оно произвольное, но ограниченное определённым количеством строк.
Что внутри ТЕКСТОВОГО блока будет не важно, т.к нормальный текст верстается с помощью line-height а не margin. Кроме того, в этом и суть вёрстки — определить как себя будут вести элементы внутри контейнера и какие они могут быть. И «неожиданных» элементов там просто не должно быть(типа а вот в этом мини-блоке мы х**нём жирнючую надпись на пол-блока), т.к все ожидаемые элементы предусмотрены в дизайне. Как бы будет очень странно если будет неожиданное количество элементов, каждый раз идущие в разнобой по параметрам отступа(обычно заголовок-картинка+подзаголовок-текст-подпись, например в случае статей).
С ориентацией устройства, если мне память не изменяет — можно применять особые правила в css с помощью медиа-запросов. Те же яйца, только в профиль.
По поводу em-ов, ничего не поедет если изначально ориентироваться на размеры шрифта. Кроме того, можно ведь использовать «абсолютные» em-ы, ну и препроцессоры как-бы спасают ситуацию, что не нужно шариться по всему css файлу подправляя значения.
И я не к тому что Ваш вариант плох, я к тому что есть альтернативные пути решения проблемы, и в основном решаются они когда к тексту относятся как к тексту, а не как к контейнерам.
эм, а почему бы не указывать высоту и ширину блоков в em? То же и с бордерами(хотя 1px не особо заметно будет).
И сразу отпадут проблемы с обрезанным на половину текстом. Если высота строки 1.3em а нужно что бы влезало 3 строки то и height делаем равным 3.9. То же и с заголовками и прочим контентом.
А что бы гибко менять дизайн и каждый раз не считать сколько где em люди придумали препроцессоры css.
Имхо, высота/ширина в пикселях для сайтов, которым требуются колонки(обычно это новостные сайты того или иного типа) слишком неудобна, да и на разных экранах читаться будет по разному. В случае с em пользовательское масштабирование решает проблему.
>>>Да вроде ж LAMPP был?
Вот только в моё время я не знал ни о каких решениях, кроме Denwer(то что он — кривой я понял сразу) и мануальной установки и конфигурирования апача по какой то древней инструкции на Win, а установку линукса или тем более виртуальных машин — слишком сложной задачей с которой нет времени разбираться. Когда я узнал что нормальные люди поднимают веб-сервер ПРОСТО поставив галочку напротив такого пункта в ОС либо ОДНОЙ строкой в консоли — решения для Win перестали быть решениями вовсе, и я очень странно смотрю на людей которые пытаются поднять веб-сервер на винде и на мои замечания говорят что «им так удобнее».
При всём этом я не ярый фанат никсов, но как инструмент в сфере администрирования веб-серверов — он лучший. Ну, или лучше я пока ещё не видел.
calg0n я бы поумерил праведный гнев. Мы можем этого не понимать, но у людей была проблема — они её решили, и теперь получают за это свой профит. Пусть они её, по нашему мнению, и решили не особо рационально — но оно работает. Хоть и потенциально — может увеличить число таких же костылеписателей, которые в своё время просто не видели другого способа решения.
Лично я был бы очень рад если в своё время мне бы дали готовый веб-сервер под линем и показали SSH, а так же — как настроить популярные IDE для авто-деплоймента, и, возможно — пару инструкций для линь-новичков и вообще где чего в этой системе лежит. Поднимать сервер на винду и конфигурировать его — то ещё мучение, в основном благодаря тому что полезного фидбэка обычно — ноль(типа при старте апача произошла ошибка #1157, и всё, делай что хочешь).
Похоже мы просто друг друга не понимаем.
АПИ, по факту — это просто способ дёрнуть нужный функционал в бэкэнде(вот по такой вот ссылке находится такая функция, она принимает такие запросы с такими параметрами и возвращает такой ответ), это не конкретный модуль, это всего лишь способ получить нужный функционал. Теперь, вместо того что бы дёрнуть функционал напрямую — мы перенаправляем(на сервере, не на клиенте) все вызовы либо в общий модуль, занимающийся КОНКРЕТНО валидацией поступивших данных, либо в кусок кода на JS, который отвалидирует данные и отправит дальше, в «настоящий» back-end. Валидация этого плана — чисто формальная фича, типа «вот это поле — должно быть телефоном, вот это — мылом, а вон то — обязательно к заполнению». Если эта валидация проходит — дальше на такую фигню данные валидировать не нужно. При этом напрямую, в обход валидации на JS — до бэкэнда не достучатся.
Для чего такие сложности? Для того что бы реализовать фронт, провалидировать форму до отправки, а потом, на доверенном участке — провалидировать форму после отправки. Код един для фронт- и бэк-, просто бэку мы доверяем, а фронту — не очень. Код не пишется в итоге, он копипаститься с недоверенного на доверенное место.
По факту — это и становится «новым» апи, потому что все запросы проходят через него, и дальше — в быстрый и надёжный бэкенд.
В итоге схема остаётся прежней — фронт -> апи -> бэкэнд, всё методы остаются прежними и по такой ссылке остаётся необходимый функционал, просто данные проходят через призму валидации.
В итоге в схеме функционирования ничего не меняется, кроме того что появляется прослойка на JS, созданная для того что бы ускорить разработку бэкэнда.
Похоже что Вы просто рассматриваете АПИ как отдельный модуль, через который «ходят» запросы. В этом проекте АПИ(по крайней мере со взгляда фронт-энд разработчика, я не лезу в бэкенд вообще и для меня он просто чёрный ящик с доками) — просто ссылки по которым доступен определённый функционал, он выполняет только одну какую то свою функцию и функционирует независимо от других модулей, расположенных по другим ссылкам(на сколько мне известно). Т.е теоретически может отвалиться одна половина сайта, но исправно работать другая.
PS даже хз как ещё более подробно написать, дальше уже наверное нужно статью с примерами накатать.
Ну да. Можно посылать запросы к /api/название_апи, и чисто теоретически — написать свой фронт-энд, с преферансом и поэтессами.
Но в случае с прокси-прослойкой до «реального» бэкэнда не достучаться напрямую, только через проксю.
Не путаете понятие «упрощение архитектуры» с «упрощением разработки»? Архитектура, понятное дело, слегка усложнится, т.к появляется дополнительный слой. Но по факту этот самый слой не видно(в идеальной ситуации, когда никаких задержек и ошибок этот слой не несёт) т.к вся его суть — провалидировать данные и пустить дальше, в ответе вернуть ответ от «настоящего бэкэнда».
Хз, возможно это чисто субьективно, но в текущем проекте я работаю на пару с бэкэнд-прогером и у нас веб приложение -> апи -> чёрный ящик бэкэнда(с моей стороны). Так вот, этот самый бэкэнд-прогер вместо того что бы заниматься своими обработчиками и бизнес-логикой, плюс чисто бэкэндовыми вещами(оптимизация нагрузки, стабильность и т.д) пишет всякую муть вроде валидации поступающих данных и корректными ответами на неправильные данные. Кроме того, всё это я уже написал на своей стороне, что бы обычный клиент не пропихнул левые данные. Правда на текущий момент мы всё же не ввели этот слой, т.к сроки поджимают, а изначально не задумывались. Но чисто как мыслительный эксперимент — решает текущие проблемы, с которыми мы сталкиваемся.
PS и трудозатраты не увеличиваются. По факту эта фича внедряется в любой бэкэнд, просто вместо запросов на index.php(к примеру) запрос пойдёт на урл, за который отвечает node.js, а после — в зависимости от реферера — пойдёт на нужное апи в «настоящий» бэкэнд. Одна функция, по факту.
Нет, я прекрасно понимаю что бывают упёртые, которым не нужны облака.
По поводу shared folder — иногда нужен доступ к исходникам. Или на демке сайта не реализована загрузка чего-либо. Тут уж клиент может спокойно зайти в привычном ему file manager'е и сделать что хотел. Ещё бонус в том что не зайдёт во всякие папки sys потому что просто их не увидит, да и не нужны они ему.
Просто я сам одно время намучался с подобными шаманствами, и лучший вариант — «облако». В худшем случае я бы скинул готовый образ системы со всем необходимым. Если бы это было постоянной необходимостью — сделал бы небольшой скриптик который и добавляет образ сам, и в основной системе всё что нужно показывал, и кнопки функциональные(как рестарт виртуальной машины или кастомный скрипт для рестарта только веб-сервера) запилил бы.
То же со скриптами установки и обновления компонентов.
Почему так? Потому что пришлось бы на много меньше кодить(да и не код был бы а так, скрипты в две строки). Причём для «тупых» клиентов — и локальная система и удобный доступ к исходникам в «проводнике». А для умных — консоль и все благи цивилизации.
Я извиняюсь, а зачем такому клиенту ВООБЩЕ показывать что либо на его машине? У вас что, дифицит места под демку сайта?
Темболее что запустить виртуалку, распаковать образ и повесить ссылку на какой нибудь адрес внутри виртуальной сети — такого же уровня проблема. Я уж не говорю про shared folder и полный доступ к необходимой части файловой системы.
Странное решение вообщем-то. Мне кажется что Вы изобрели велосипед, который _просто_ делает названные Вами шаманства за вас.
эм, стоит включить пункт «Я — веб разработчик, потому пользуюсь многими браузерами», иначе портит статистику(веб разработчики выбирают большую часть пунктов)
В своей работе пользуюсь оперой, фф, хромом, сафари, ие(7-8-9-10), хромом канарейкой, фф бетой, фф/хром для андроида. В исключительных случаях(тикет от клиента) ставлю что нибудь экзотическое, что у клиента криво работает. Иногда — отключаю js, css, картинки и смотрю как бы мой сайт выглядел и работал в текстовом представлении.
Сёрфлю правда в хроме(он быстрее), разрабатываю в фф(у него firebug удобнее и расширений много интересных).
Ещё интересный вариант в плане упрощения разработки — javascript(front) -> javascript-api(back), он же — прокси с валидацией в настоящий бэкэнд -> бэкэнд.
Собственно фронтэнд и бэкэнд полностью разделены, при этом использование JS в качестве прокси позволяет существенно снизить затраты на валидацию полей(собственно, объёмная часть АПИ и составляет корректная валидация и нормальные ошибки), т.к код для валидации един. Ну и там всякие разные бонусы, типа можно клиенту отдавать сразу готовый html(в совершенно идиотском случае если JS у человека не работает), что в случае с graceful degradation не должно особо отразиться на функциональности.
Эм? Не понял. Никакого смысла создавать АПИ для валидации нет — им пользоваться никто не будет(как и те, кто пишет новое представление, так и кулхацкеры).
Как модуль-прослойка между бэкэндом и «основным» кодом — вполне. И этого будет не видно в REST, это чисто бэкэндовая фича(у меня например на стороне клиента есть одна глобальная функция которая посылает данные, она же — обрабатывает глобальные ошибки. Но можно написать свою спеку, и обрабатывать стандартизированные ошибки в этом методе). Запрос пойдёт по REST-правилам, просто провалидируется перед тем как выполниться.
Да и на JS правильно организованная валидация данных — не проблема(конечно, БЫВАЮТ граничные случаи, но зачастую это не существенно(ибо особенность языка) либо кривые руки). В случае структурированных данных это JSON-схема например.
PS по поводу node.js много не скажу, но очень привлекательно выглядит схема front->node->API, т.к серьёзно уменьшает затраты на написание API(правильная валидация и обработка ошибок это крайне важно для АПИ)
а если некоторое количество информации, требующейся с каждым запросом(авторизационные данные и некоторые не-касающиеся пользователя данные), необходимые для работы с апи находятся у клиента в куках — это stateful? А если в куках только идентификатор сессии будет находится, но данные будут получаться раз и до конца сессии лежать на сервере?
PS если чего, то сайт можно назвать «веб-приложением».
Бизнес логику в любом случае нужно будет продублировать, потому что пользователю нужен отзывчивый интерфейс, а не передёргивание страницы на каждый чих, вроде не заполнения обязательного поля. Для уменьшения трудозатрат можно сделать небольшую прослойку в виде node.js, который будет по сути являтся проксёй в «настоящий» бэкэнд и заниматься будет тем что валидирует то что ему пришло и отправляет данные на обработку либо заворачивает запрос.
cvv код не является паролем и по факту его может подсмотреть любой, кто имеет физический доступ к вашему монитору с расстояния пару метров(в т.ч и стырить карточку), а вероятность ошибиться в наборе cvv — уменьшает.
Вообще код этот код изначально задумывался как «закрытая часть ключа», мол номер карточки это общедоступная информация, а вот без cvv оплатить с неё чего либо невозможно, но частенько такая защита не прокатывает, потому и внедряют двухфакторную авторизацию.
А автору я советую завести виртуальный счёт или простую карточку только_для_оплаты_в_интернете, а с остальных карточек вообще заблокировать оплату в интернете. При необходимости — переводить необходимую сумму на эту карту, тогда хотя бы будешь знать какой суммой рискуешь.
Про года — быдлокодерам всегда было и будет проще поправить через N времени на свежую информацию чем написать небольшую функцию, которая считает текущий год + M от текущей даты на сервере(new Date не канает т.к зависит от времени пользователя, а она может быть любая) и отображает эти данные пользователям. В своей практике я встречал труЪ-кодеров которые сами писали считалку даты, иногда проскакивали такие лулзы как 30 февраля.
Такое себе устройство. Во первых собака его захочет снять. Во вторых — паттерны нужно ещё выявить, а для этого собаку нужно тренировать(скорее всего у каждой собаки — свои паттерны). В третьих — собаки ОТЛИЧНО справляются с передачей простых мыслей(вроде «кушать», «прогуляться», «поиграть», «не подходи» и т.д). Что бы эти «мысли» подавить собаку необходимо специально тренировать, либо нужно что бы у неё были повреждения психики. В первом случае это делается нарочно(например, некоторых собак тренируют не показывать агрессию до момента укуса), во втором случае собак усыпляют или переучивают.
Научная ценность — маленькая. Уже довольно давно известны устройства которые по паттерну мозговой деятельности могут предпринимать запрограммированные действия. «Чтеца мыслей» пока не изобрели, к сожалению. Но, зато за 300$ вы сможете попробывать сравнить мысли вашего друга с мыслями вашей собаки.
Недавно заинтересовался возможностью авто-тестирования JS'а и хочу понять как оно таки работает. Ведь по факту тест это «зеркало» кода, т.е трудозатраты возрастают раза в полтора, и иногда это всёравно может не дать нужный эффект(функции можно протестировать, а вот увидит ли пользователь то что задумывалось — уже сложнее). Знаю что есть selenium который по факту просто кликер.
Если кому не сложно — посоветуйте литературу и/или обзор библиотек для авто-тестирование JS. Больше всего интересует возможность тестирования backbone.
ну, на самом-то деле этот код легко влезет в формат js1k(учитывая что канвас там уже предоставляют, как и контекст к нему). Но не интересно просто сжать.
Что внутри ТЕКСТОВОГО блока будет не важно, т.к нормальный текст верстается с помощью line-height а не margin. Кроме того, в этом и суть вёрстки — определить как себя будут вести элементы внутри контейнера и какие они могут быть. И «неожиданных» элементов там просто не должно быть(типа а вот в этом мини-блоке мы х**нём жирнючую надпись на пол-блока), т.к все ожидаемые элементы предусмотрены в дизайне. Как бы будет очень странно если будет неожиданное количество элементов, каждый раз идущие в разнобой по параметрам отступа(обычно заголовок-картинка+подзаголовок-текст-подпись, например в случае статей).
С ориентацией устройства, если мне память не изменяет — можно применять особые правила в css с помощью медиа-запросов. Те же яйца, только в профиль.
По поводу em-ов, ничего не поедет если изначально ориентироваться на размеры шрифта. Кроме того, можно ведь использовать «абсолютные» em-ы, ну и препроцессоры как-бы спасают ситуацию, что не нужно шариться по всему css файлу подправляя значения.
И я не к тому что Ваш вариант плох, я к тому что есть альтернативные пути решения проблемы, и в основном решаются они когда к тексту относятся как к тексту, а не как к контейнерам.
И сразу отпадут проблемы с обрезанным на половину текстом. Если высота строки 1.3em а нужно что бы влезало 3 строки то и height делаем равным 3.9. То же и с заголовками и прочим контентом.
А что бы гибко менять дизайн и каждый раз не считать сколько где em люди придумали препроцессоры css.
Имхо, высота/ширина в пикселях для сайтов, которым требуются колонки(обычно это новостные сайты того или иного типа) слишком неудобна, да и на разных экранах читаться будет по разному. В случае с em пользовательское масштабирование решает проблему.
Вот только в моё время я не знал ни о каких решениях, кроме Denwer(то что он — кривой я понял сразу) и мануальной установки и конфигурирования апача по какой то древней инструкции на Win, а установку линукса или тем более виртуальных машин — слишком сложной задачей с которой нет времени разбираться. Когда я узнал что нормальные люди поднимают веб-сервер ПРОСТО поставив галочку напротив такого пункта в ОС либо ОДНОЙ строкой в консоли — решения для Win перестали быть решениями вовсе, и я очень странно смотрю на людей которые пытаются поднять веб-сервер на винде и на мои замечания говорят что «им так удобнее».
При всём этом я не ярый фанат никсов, но как инструмент в сфере администрирования веб-серверов — он лучший. Ну, или лучше я пока ещё не видел.
Лично я был бы очень рад если в своё время мне бы дали готовый веб-сервер под линем и показали SSH, а так же — как настроить популярные IDE для авто-деплоймента, и, возможно — пару инструкций для линь-новичков и вообще где чего в этой системе лежит. Поднимать сервер на винду и конфигурировать его — то ещё мучение, в основном благодаря тому что полезного фидбэка обычно — ноль(типа при старте апача произошла ошибка #1157, и всё, делай что хочешь).
АПИ, по факту — это просто способ дёрнуть нужный функционал в бэкэнде(вот по такой вот ссылке находится такая функция, она принимает такие запросы с такими параметрами и возвращает такой ответ), это не конкретный модуль, это всего лишь способ получить нужный функционал. Теперь, вместо того что бы дёрнуть функционал напрямую — мы перенаправляем(на сервере, не на клиенте) все вызовы либо в общий модуль, занимающийся КОНКРЕТНО валидацией поступивших данных, либо в кусок кода на JS, который отвалидирует данные и отправит дальше, в «настоящий» back-end. Валидация этого плана — чисто формальная фича, типа «вот это поле — должно быть телефоном, вот это — мылом, а вон то — обязательно к заполнению». Если эта валидация проходит — дальше на такую фигню данные валидировать не нужно. При этом напрямую, в обход валидации на JS — до бэкэнда не достучатся.
Для чего такие сложности? Для того что бы реализовать фронт, провалидировать форму до отправки, а потом, на доверенном участке — провалидировать форму после отправки. Код един для фронт- и бэк-, просто бэку мы доверяем, а фронту — не очень. Код не пишется в итоге, он копипаститься с недоверенного на доверенное место.
По факту — это и становится «новым» апи, потому что все запросы проходят через него, и дальше — в быстрый и надёжный бэкенд.
В итоге схема остаётся прежней — фронт -> апи -> бэкэнд, всё методы остаются прежними и по такой ссылке остаётся необходимый функционал, просто данные проходят через призму валидации.
В итоге в схеме функционирования ничего не меняется, кроме того что появляется прослойка на JS, созданная для того что бы ускорить разработку бэкэнда.
Похоже что Вы просто рассматриваете АПИ как отдельный модуль, через который «ходят» запросы. В этом проекте АПИ(по крайней мере со взгляда фронт-энд разработчика, я не лезу в бэкенд вообще и для меня он просто чёрный ящик с доками) — просто ссылки по которым доступен определённый функционал, он выполняет только одну какую то свою функцию и функционирует независимо от других модулей, расположенных по другим ссылкам(на сколько мне известно). Т.е теоретически может отвалиться одна половина сайта, но исправно работать другая.
PS даже хз как ещё более подробно написать, дальше уже наверное нужно статью с примерами накатать.
Но в случае с прокси-прослойкой до «реального» бэкэнда не достучаться напрямую, только через проксю.
Хз, возможно это чисто субьективно, но в текущем проекте я работаю на пару с бэкэнд-прогером и у нас веб приложение -> апи -> чёрный ящик бэкэнда(с моей стороны). Так вот, этот самый бэкэнд-прогер вместо того что бы заниматься своими обработчиками и бизнес-логикой, плюс чисто бэкэндовыми вещами(оптимизация нагрузки, стабильность и т.д) пишет всякую муть вроде валидации поступающих данных и корректными ответами на неправильные данные. Кроме того, всё это я уже написал на своей стороне, что бы обычный клиент не пропихнул левые данные. Правда на текущий момент мы всё же не ввели этот слой, т.к сроки поджимают, а изначально не задумывались. Но чисто как мыслительный эксперимент — решает текущие проблемы, с которыми мы сталкиваемся.
PS и трудозатраты не увеличиваются. По факту эта фича внедряется в любой бэкэнд, просто вместо запросов на index.php(к примеру) запрос пойдёт на урл, за который отвечает node.js, а после — в зависимости от реферера — пойдёт на нужное апи в «настоящий» бэкэнд. Одна функция, по факту.
По поводу shared folder — иногда нужен доступ к исходникам. Или на демке сайта не реализована загрузка чего-либо. Тут уж клиент может спокойно зайти в привычном ему file manager'е и сделать что хотел. Ещё бонус в том что не зайдёт во всякие папки sys потому что просто их не увидит, да и не нужны они ему.
Просто я сам одно время намучался с подобными шаманствами, и лучший вариант — «облако». В худшем случае я бы скинул готовый образ системы со всем необходимым. Если бы это было постоянной необходимостью — сделал бы небольшой скриптик который и добавляет образ сам, и в основной системе всё что нужно показывал, и кнопки функциональные(как рестарт виртуальной машины или кастомный скрипт для рестарта только веб-сервера) запилил бы.
То же со скриптами установки и обновления компонентов.
Почему так? Потому что пришлось бы на много меньше кодить(да и не код был бы а так, скрипты в две строки). Причём для «тупых» клиентов — и локальная система и удобный доступ к исходникам в «проводнике». А для умных — консоль и все благи цивилизации.
Темболее что запустить виртуалку, распаковать образ и повесить ссылку на какой нибудь адрес внутри виртуальной сети — такого же уровня проблема. Я уж не говорю про shared folder и полный доступ к необходимой части файловой системы.
Странное решение вообщем-то. Мне кажется что Вы изобрели велосипед, который _просто_ делает названные Вами шаманства за вас.
В своей работе пользуюсь оперой, фф, хромом, сафари, ие(7-8-9-10), хромом канарейкой, фф бетой, фф/хром для андроида. В исключительных случаях(тикет от клиента) ставлю что нибудь экзотическое, что у клиента криво работает. Иногда — отключаю js, css, картинки и смотрю как бы мой сайт выглядел и работал в текстовом представлении.
Сёрфлю правда в хроме(он быстрее), разрабатываю в фф(у него firebug удобнее и расширений много интересных).
Собственно фронтэнд и бэкэнд полностью разделены, при этом использование JS в качестве прокси позволяет существенно снизить затраты на валидацию полей(собственно, объёмная часть АПИ и составляет корректная валидация и нормальные ошибки), т.к код для валидации един. Ну и там всякие разные бонусы, типа можно клиенту отдавать сразу готовый html(в совершенно идиотском случае если JS у человека не работает), что в случае с graceful degradation не должно особо отразиться на функциональности.
Как модуль-прослойка между бэкэндом и «основным» кодом — вполне. И этого будет не видно в REST, это чисто бэкэндовая фича(у меня например на стороне клиента есть одна глобальная функция которая посылает данные, она же — обрабатывает глобальные ошибки. Но можно написать свою спеку, и обрабатывать стандартизированные ошибки в этом методе). Запрос пойдёт по REST-правилам, просто провалидируется перед тем как выполниться.
Да и на JS правильно организованная валидация данных — не проблема(конечно, БЫВАЮТ граничные случаи, но зачастую это не существенно(ибо особенность языка) либо кривые руки). В случае структурированных данных это JSON-схема например.
PS по поводу node.js много не скажу, но очень привлекательно выглядит схема front->node->API, т.к серьёзно уменьшает затраты на написание API(правильная валидация и обработка ошибок это крайне важно для АПИ)
PS если чего, то сайт можно назвать «веб-приложением».
По второму пункту — приведите пример, пожалуйста.
Вообще код этот код изначально задумывался как «закрытая часть ключа», мол номер карточки это общедоступная информация, а вот без cvv оплатить с неё чего либо невозможно, но частенько такая защита не прокатывает, потому и внедряют двухфакторную авторизацию.
А автору я советую завести виртуальный счёт или простую карточку только_для_оплаты_в_интернете, а с остальных карточек вообще заблокировать оплату в интернете. При необходимости — переводить необходимую сумму на эту карту, тогда хотя бы будешь знать какой суммой рискуешь.
Про года — быдлокодерам всегда было и будет проще поправить через N времени на свежую информацию чем написать небольшую функцию, которая считает текущий год + M от текущей даты на сервере(new Date не канает т.к зависит от времени пользователя, а она может быть любая) и отображает эти данные пользователям. В своей практике я встречал труЪ-кодеров которые сами писали считалку даты, иногда проскакивали такие лулзы как 30 февраля.
Научная ценность — маленькая. Уже довольно давно известны устройства которые по паттерну мозговой деятельности могут предпринимать запрограммированные действия. «Чтеца мыслей» пока не изобрели, к сожалению. Но, зато за 300$ вы сможете попробывать сравнить мысли вашего друга с мыслями вашей собаки.
Если кому не сложно — посоветуйте литературу и/или обзор библиотек для авто-тестирование JS. Больше всего интересует возможность тестирования backbone.