Если честно, я думал (надеялся), что порча процессоров от того, что плохо охлаждается далеко в прошлом. Полагал, они отключаются или отключают конвейеры или что-то там такое. А если тупо кулер сломается? Странно всё это…
Не все понимают почему то, что именно есть «патент». Не обязательно всех засудят, о чём вы говорите? К тому же нельзя запатентовать задачу. Можно только запатентовать конкретное решение и то с очень многими ограничениями. В данном случае я вижу некоторые отклонения от стандартного списка и в описании и по картинке (правда, там не очень разборчиво). Если доказано, что этого не было до сего времени и это реально помогает, то вполне годится на патент. Да, всё это дуто и, может быть, местами натянуто. Но примерно так же ищутся чаще всего темы для диссертаций и прочих квалификационных и научных работ — что-то придумывают, что-то дополняют, и вот тебе новизна, а уж актуальность (тоже необходимый критерий для получения патента) всегда можно доказать. Насколько это полезно и вообще не вредно ли — вопрос отдельный. Оглянитесь вокруг — большинство вещей содержат в себе те или иные патенты (шариковая ручка — классический пример), никого ещё не посадили.
На самом деле почти везде (в известных движках) в таких случаях используется редирект, почему сразу гавнокодинг. С другой стороны везде идёт вдобавок проверка по ключу. Методы никак друг другу не противоречат, а, наоборот, успешно дополняют. В чём проблема редиректа то?
Ну прям уж) Не должен сервер это делать, вы что. Что значит «правильный код»? Это должно приложение решать — какой код возврата «правильный», это прикладное понятие, а не протокольное.
Судя по недавней истории с логином на фейсбук ( lotares.habrahabr.ru/blog/84473/ ) большинство «обычных» пользователей (о которых и пекутся в этой статье) вообще понятия не имеют где находится адресная строка и зачем она там.
А что такого? У меня, например, остались ещё с «тех» времён. Ещё лет 5-6 назад вполне в ходу были дискеты. А ещё года два назад меня вынуждали ими пользоваться (статьи на печать принимали на дискете only).
Ну, метод явно имеет место быть. Но по первому впечатлению это весьма специфичный «фреймворк», так скажем. Оттого и короткий. На вид. Просто ведь тут у вас выложен сам «роутер», а к нему ещё прикручен немаленький шаблонизатор, который берёт на себя всю генерацию выхода и разные контроллеры, которые берут на себя всю логику. Так что минимализм — это по большей части оптический обман :)
На 02 звонить и уточнять всегда полезно — все звонки туда строго фиксируются (и потом при необходимости являются доказательством факта) и если «менты» знают, что в данный момент могут быть не очень правы, то очень нервничают и вообще не любят связываться. Проверено :)
Правда, в данном случае это бы не возымело эффекта, ибо пришедшие, как видно, были уверены в своей правоте и законности.
Не, ну почему всё же без «выводов» и «общего бала»? Так не пойдёт. Смысл то какой тогда в обзоре? Ну, в каждом тесте кто-то победил, кто-то проиграл. Пытался найти закономерности, вроде фаерфокс слил в большем количестве Ваших тестов? Вы на это намекаете? А как с самим обзором связано вступление про свободный и несвободный софт и про лайт и ультра? В общем, простите, но лично я нифига не понял…
Статья очень хорошая, побольше бы таких авторских статей. Буду ждать обещанных следующих. Немного прокомментирую «интро».
Я разделяю (довольно распространённое) мнение, что изучение (и, как следствие, попытки «обдуманного» использования) шаблонов проектирования на ранних этапах становления программиста скорее вредно, чем полезно. В развитии через «велосипеды» нет ничего плохого, скорее наоборот — все проходят через эти стадии. И в итоге вырабатываются свои пути мышления, и свои особенности видения каждой практической проблемы и придумываются свои фишки для каждого конкретного случая. Прикол как раз в том, что набор шаблонов охватывает большинство разумных случаев таких архитектурных фишек. И направление их применения должно быть именно «проблема» -> «о, я знаю как решить» -> «да это же шаблон '...'!», а не обратное. Видел в практике кучу случаев, когда пытались сувать шаблон туда, куда он ну никак не лез. Говоришь: «ну не получается ведь, сделай ты вот так и так, ведь короче, проще и логичнее», а он: «нет, здесь, походу, нужна фабрика и я её приделаю». Зачем вот так вот?
К чему я это? К описанному Вами назначению шаблонов. Немного непонятно, как шаблоны могут помочь избежать велосипедов, ведь это просто схематические описания архитектурных конструкций. Всё же я считаю, что основное назначение шаблонов — в классификации кода и, возможно, приведении его к какому-либо каноническому виду. Чтобы, например, при обсуждении с коллегами каких-либо поставленных проблем и их решений или самого кода «этот вот класс, хранящий статический экземпляр объекта в единственном виде» называть синглтоном, а «типа очередь объектов определённой длины, чтобы их не создавать каждый раз, а брать оттуда и класть обратно» — пулом объектов. А шаблоны ради шаблонов — зло. Имхо.
Я не фанат вконтакта, конечно, но… круто :) Разбить бы сообщения на стене на отдельные «файлы» и дать возможность создавать у друзей и читать/удалять у себя. Ну и прочее такое же с остальными сущностями.
Правда, в данном случае это бы не возымело эффекта, ибо пришедшие, как видно, были уверены в своей правоте и законности.
Я разделяю (довольно распространённое) мнение, что изучение (и, как следствие, попытки «обдуманного» использования) шаблонов проектирования на ранних этапах становления программиста скорее вредно, чем полезно. В развитии через «велосипеды» нет ничего плохого, скорее наоборот — все проходят через эти стадии. И в итоге вырабатываются свои пути мышления, и свои особенности видения каждой практической проблемы и придумываются свои фишки для каждого конкретного случая. Прикол как раз в том, что набор шаблонов охватывает большинство разумных случаев таких архитектурных фишек. И направление их применения должно быть именно «проблема» -> «о, я знаю как решить» -> «да это же шаблон '...'!», а не обратное. Видел в практике кучу случаев, когда пытались сувать шаблон туда, куда он ну никак не лез. Говоришь: «ну не получается ведь, сделай ты вот так и так, ведь короче, проще и логичнее», а он: «нет, здесь, походу, нужна фабрика и я её приделаю». Зачем вот так вот?
К чему я это? К описанному Вами назначению шаблонов. Немного непонятно, как шаблоны могут помочь избежать велосипедов, ведь это просто схематические описания архитектурных конструкций. Всё же я считаю, что основное назначение шаблонов — в классификации кода и, возможно, приведении его к какому-либо каноническому виду. Чтобы, например, при обсуждении с коллегами каких-либо поставленных проблем и их решений или самого кода «этот вот класс, хранящий статический экземпляр объекта в единственном виде» называть синглтоном, а «типа очередь объектов определённой длины, чтобы их не создавать каждый раз, а брать оттуда и класть обратно» — пулом объектов. А шаблоны ради шаблонов — зло. Имхо.