Я не знаю что на данный момент, но на самом деле это намного верней чем то, что предложено MS. Ведь на самом деле пользователю можно предложить состроить рожицу. Например подмигнуть правым глазом, улыбнутся, показать язык, дотронутся пальцем до кончика носа, надуть щеки или все одновременно. Вообще можно придумать много разных отличительных факторов, которые помимо самого лица должны совпасть (это ведь могут быть и не детали лица, а например лицо + раскрытая ладонь, или лицо + фак ю). Или вы будете показывать в камеру десятки специально сделанных фотографий на которых пользователь то улыбается, то подмигивает? А если еще и после N-ого провального доступа по изображению лица убирать такую возможность доступа, и включать только более безопасные методы? Так что верный подход найден, остается только постепенно довести его до ума… а то что делают микрософт явно шаг не в ту сторону.
(и опять я случайно оправил комментарий, извиняюсь, я кстати соврал, вот этот комментарий будет последним =)
Но ваш пример не корректен — в вашем случае «попытка подгадить» так же является одним из видов критики.
Если говорить формально, да наверно является. Но опять таки это какая-то мелкая придирка. Я бы даже не назвал это неконструктивной критикой, неконструктивная критика — это, как из моего примера выше, где говоришь что не так, но не предлагаешь как это исправить. А «Ваш сайт говно» — это просто ваше личное мнение, никакая это не критика (стоит ли это мнение учитывать или нет другой вопрос, если 1000 человек скажут вам это, наверно стоит задуматься). Как я уже сказал довольно печально, что люди сравнивают свое личное мнение и критику так прямо.
С вами довольно интересно спорить ) Хотя я и не совсем согласен с вами, пожалуй, чтобы не флудить бесконечно, этот мой комментарий будет последним.
Уважать и проявлять уважение немного разные вещи, не улавливаете?
Ну есть, но очень небольшая… Или вы хотите чтобы вас как ребенка поощряли, в духе: «да ты это сделал хорошо». Вообще мне кажется, что здесь вы немного придираетесь…
(извиняюсь случайно нажал CTRL+Enter и сообщения отправилось, продолжу ответ на цитату «Тут так-же проявление уважения к работе другого человека.»)
А до этого вы не знали, что работу другого человека следуют уважать =)?
Да тут даже толком и непонятно, что такое критика. Понимаете, реакция человека на «критику» зависит от того является ли так называемая «критика» критикой, а не простой попыткой подгадить. На критику взрослый вменяемый человек реагирует вполне нормально, ничего не надо ему объяснять, мы же с вами не в детсаду.
Сравните: «Ваш сайт говно».
И: «Ваш сайт не работает так как следует. Не отображается нормально в IE* и Хроме* и Opere*. Некоторые картинки не загружаются. Консоль выдает кучу JS ошибок...».
Я думаю вы поняли мысль. Или вы думаете что в ответ на второе замечание (хотя оно тоже не идеально, можно было бы точнее рассказать об ошибках) разработчик (нормальный) обидится и покончит с собой?
> Тут так-же проявление уважения к работе другого человека.
Вот ппц ведь. Неужели кто-то может принимать это всерьез? Какая-то психология для чайников… И с самого начала ошибка, критика — это не просто сказать: «Фу, это атцтой» или «Этот дизайн мне совсем не нравится» (признаю, что дальше в диалоге все немного иначе, но все равно есть какое-то фундаментальное недопонимание). Нужно объяснить почему. Иначе мы получаем не критику, а фиг знает что. Вот меня поражает насколько люди обнаглели, если считают, что для критики достаточно выразить свое субъективное мнения, вроде: «Ваш сайт говно». У критики должна быть причина, цель, и конкретные претензии к объекту критики. Если вам просто делать нечего и захотелось «насрать в комментарии», пересильте себя и оставьте свои мысли при себе. Критикуйте по делу (и желательно вежливо) и любой вменяемый человек вам будет только благодарен. Или вы и вправду не знаете, что никто не любит грубости и беспричинных замечаний?
Doctrine 2 и ZF2 — прекрасны. Я прямо таки дождаться не могу когда они зарелизятся. И если насчет Doctrine 2 все более менее ясно (команда стремительно движется к релизу), то с ZF2 придется прилично подождать. Сейчас завершилась стадия перехода на неймспейсы, и по сути ZF2dev1 это — тот же ZF1 только с неймспейсами. Осенью будет последний релиз ветки 1.Х, и где-то в это же время станет точнее известна дата релиза второй версии (если вам интересны новости о ZF, подпишитесь на списки рассылки). Однако очень радует то, к чему команда стремится — упрощение фреймворка, разделение обязанностей, производительность, улучшение документации и другое.
Опять таки, если вы можете улучшить код годовалой давности, а не переписать проект заново, то это на мой взгляд не такой уж и плохой код. Да он не идеальный, и вы можете его улучшить, но это не тоже самое, что «весь код дерьмо». Часть кода уродлива, но в целом проект логичен, и поэтому поддаются расширению, улучшению и изменению.
А вот мне не хочется =) Я не крутой программист, но мне вседаки кажется, что автор (конечно, автор оригинальной статьи, и я обращаюсь к нему =) этой статьи в чем-то не прав, или выступает в роли кэпа. Позвольте пару комментариев:
1. Мы не правы
Любой так называемый «открывающий глаза пост», обязательно должен смешать программиста с говном. Без этого никак. Абсолютно бесполезное и временами даже вредное утверждение. Очевидно, что не стоит думать, что ты прав и не слушать никого (и штука, в том, что это касается не только программистов) — вот только, зачем писать об этом каждый раз? Высокое эго у программистов? Да ладно вам… любой, кто имеет хоть минимальный опыт, уже знает, что он не господь бог.
2. Все, что может сломаться, ломается
А все, что может испортиться, испортится. Хорошие утверждение, вот только очень общее, и поэтому практически бесполезное. Даже вот не знаю, что еще сказать =) Здорово, вы так задвинули, по философски =) Можно наверно сказать, что вредно думать обо всем, что может сломаться, ибо не так и важно нам это «все». Нам важно, чтобы ниче не сломалось, на данном нам уровне абстракции. Остальное мы не тестируем, и никак не можем (и хотим ли?) на это повлиять. Мы, по умолчанию, принимаем то, что куча вещей не может испортится (что противоречит исходному утверждению =), и что более важно, как привило, это недалеко от истины. Если непонятно, то я имею ввиду: вряд ли кто-то программируя на PHP, заботится о том, как сетевая карта посылает туда сюда пакеты, возникают ли там ошибки, и как их исправлять.
3. Весь код — дерьмо
Нет, не весь. Если весь ваш код говно — вы хреновый программист. Код перестает быть говном, как только программист говорит, что-то вроде: «Да вот, тут, и там, и здесь я лажанулся, но это можно исправить». Т.е когда не приходится переписывать всю программу заново(т.е. система очень грамотно разбита на модули). Мне кажется, что вседаки есть очень большая разница м/у дерьмовым кодом и не дерьмовым. На мой взгляд она принципиальна — хороший можно изменять, расширить и улучшать, а не переписывать.
4. В программе всегда есть баг
Ну вряд ли бесконечное. Я тоже где-то в книжке это видел, но число ошибок точно конечно(хотя в больших программах, оно наверно настолько большое, что можно смело считать его бесконечным). Ну тут ведь тоже не все так просто, могут быть ошибки в методе, классе, модуле, или в интеграции модулей. И вот ошибок в методе, уже точно не может быть бесконечно много. Мне кажется корректней было бы утверждать, что шанс того, что в программе есть ошибка всегда не равен нулю =) Весь вопрос в том, чтобы сделать так, что этот шанс -> 0. И еще было бы круто, еслиб мы знали, где именно может возникнуть ошибка, и могли оценить ее значимость. Вот в винде и других ОС бесконечно возникают ошибки. И что? Всем плевать, ибо они ну ОЧЕНЬ редко выводят систему из строя (особенно в «других ОС»). Не стоит бояться, этого мифического «бесконечного числа ошибок», на самом деле это не так (чтобы меня не запинали, это конечно так, но всем пофиг =) В программе, конечно, что-то может пойти не так, но можно сделать так, чтобы ошибка скорее возникала в каком-то определенном месте, а не где-то в программе, и так же (что важно) можно на эту ошибку среагировать и восстановить программу.
5. Наиболее важная вещь — это клиент
Да, клиенту на это вообще плевать. Но, вот что забавно, ему будет не плевать, когда проект провалиться, из-за того что вы не использовали, современные методики/средства и пр. Программисты не пишут на асм, не из-за клиента, а из-за себя. Ведь именно им потом со всем этим работать. Технологии очень сильно влияют на продукт, и то что клиент этого не понимает (ему нет непосредственной или мгновенной пользы от этого) не должно играть никакой роли при их использовании.
7. Меньше — лучше
Да и проще тоже — лучше =) Я не совсем понимаю этого тезиса, что имеют ввиду автор? Что не стоит заранее писать расширенную функциональность? Мб не стоит усложнять код? Или не стоит писать лишний (sic!) код? Не стоит предсказывать все возможные случаи? Тогда, да, пожалуй, всего этого делать не стоит =)
8. Кодирование занимает 20% времени
Да, заказчики, очень любят послушать программистское исполнение роли Гамлета. Главная задача программиста — писать код ( ну и кончено «отладку, тестирование», обсуждение). Общение с заказчиками, вряд ли требуется от рядового программиста (тут конечно тоже много нюансов, но лучше бы программисту общаться только с другим программистами). Вообще, мне кажется, что порой к программисту предъявляют слишком много требований, не удивительно, что по некоторым из них он не подходит (поэтому в больших проектах, роли всегда достаточно хорошо разделены, и никто не требует от программистов всего).
9. Заказчик НИКОГДА не знает, что он хочет
Да, поэтому и передумывают всякие методы разработки. Моглибы упомянуть об этом. Заказчик как и любой другой человек не может предсказать всего. Проект оживает, и когда заказчик это видит, вполне естественно, что в живую у заказчика сформировывается более точное и правильное мнение, как должна работать та, или иная функция. Т.е он как-бы смотрит: ага да вот оно как на самом дело-то будет, и думает, а точно ли он именно это хотел (заказчик со временем лучше узнает проект). Это раздражает, но от этого наверно нельзя уйти =)
10. Кто-то это уже делал
Точно, и написано уже миллион раз. Но этот полюбому особенный.
У хабра и эльфа не спрашивай совета: оба скажут в ответ — что да, то и нет. Так же заметил, что многие топики с обещаниями я-готов-сделать-что-то-мега-полезное, имеют довольно странный характер, топик есть а результата нет. Вы сначала перевидите и озвучите, хотя бы пару серий, а там видно будет =)
> Я не придираюсь. Мне действительно интересно, почему люди так им интересуются.
Да я и не думал, что вы придираетесь. Просто решил упомянуть забавный факт из биографии мистера Фейнмана. Но главным образом, хотел вседаки дать ссылку, на статью о математике, уж очень она мне кажется интересной.
Да ладно вам, одно только то, как он доказал, что человек может справлять малую нужду не благодаря силе тяжести, а мышечным усилиям вызывает интерес к его персоне =)
Про математику недавно наткнулся(спасибо тому, кто дал ссылку, но уже не помню где) на просто поразительную статью о школьной математике: Пол Локхард «Плач математика». Советую хотябы бегло прочитать.
Вот, теперь все ясно. Отвечаю (раз уж начал, то до конца) =) Да вы правы, и действительно свойство $_instance будет одно на всех. Для того чтобы это избежать, нужно делать что-то вроде, того что привел автор. Ну или объявлять static protected $_instance в потомках (и в родительском классе), и так же использовать везде static:: вместо self::. Я думаю можно еще найти какие-то способы, но все они мне почему-то не очень нравятся, ибо помахивают каким-то не здравым шаманством.
> Хотя все эти вопросы чисто теоретические — мне вряд ли светит переход на php6 :)
Ну в общем то php6 тут и не нужен, хватит php 5.3.
> А в случае self::$_instance не перепишется приватное поле родительского класса?
Гм, я не уверен, что понял, что именно вы спрашиваете. Если объявить в классе B static private $_instance, то нет, ничего не перепишется. Обращаясь к B self::$_instance и к Sin self::$_instance вы получите. Т.е когда модификатор свойства private потомок не может напрямую получить доступ к нему.
class Sin
{
static private $_instance = 'Sin $_instance';
public function test()
{
return self::$_instance;
}
}
class B extends Sin
{
static protected $_instance = 'B $_instance';
public function test2()
{
return self::$_instance;
}
}
$s = new B;
var_dump($s->test()); // Sin $_instance
echo '<Br>';
var_dump($s->test2()); // B $_instance
Потому что $_instance приватное свойство класса Sin, и не доступно для потомков. Вообще можно объявить $_instance как protected, тогда можно будет использовать static::$_instance. Я просто хотел чтобы было как у автора (private свойство), он вроде тоже об этом упоминает.
> А скобочки после new static не нужны?
Как вам больше нравиться =) Классы можно создавать и так и так. Т.е:
class B {}
$a = new B;
тоже вполне допустимо.
> Или static:: работает только для методов, но не для полей?
Нет, работает и так и так, как я уже писал здесь self только из-за того что поле private.
и кстати если распознавание грамотно сделано, то покрутив фотку чего вы добьетесь? Фотка дает 180º а надо то больше.
Если говорить формально, да наверно является. Но опять таки это какая-то мелкая придирка. Я бы даже не назвал это неконструктивной критикой, неконструктивная критика — это, как из моего примера выше, где говоришь что не так, но не предлагаешь как это исправить. А «Ваш сайт говно» — это просто ваше личное мнение, никакая это не критика (стоит ли это мнение учитывать или нет другой вопрос, если 1000 человек скажут вам это, наверно стоит задуматься). Как я уже сказал довольно печально, что люди сравнивают свое личное мнение и критику так прямо.
Ну есть, но очень небольшая… Или вы хотите чтобы вас как ребенка поощряли, в духе: «да ты это сделал хорошо». Вообще мне кажется, что здесь вы немного придираетесь…
А до этого вы не знали, что работу другого человека следуют уважать =)?
Сравните: «Ваш сайт говно».
И: «Ваш сайт не работает так как следует. Не отображается нормально в IE* и Хроме* и Opere*. Некоторые картинки не загружаются. Консоль выдает кучу JS ошибок...».
Я думаю вы поняли мысль. Или вы думаете что в ответ на второе замечание (хотя оно тоже не идеально, можно было бы точнее рассказать об ошибках) разработчик (нормальный) обидится и покончит с собой?
> Тут так-же проявление уважения к работе другого человека.
Любой так называемый «открывающий глаза пост», обязательно должен смешать программиста с говном. Без этого никак. Абсолютно бесполезное и временами даже вредное утверждение. Очевидно, что не стоит думать, что ты прав и не слушать никого (и штука, в том, что это касается не только программистов) — вот только, зачем писать об этом каждый раз? Высокое эго у программистов? Да ладно вам… любой, кто имеет хоть минимальный опыт, уже знает, что он не господь бог.
А все, что может испортиться, испортится. Хорошие утверждение, вот только очень общее, и поэтому практически бесполезное. Даже вот не знаю, что еще сказать =) Здорово, вы так задвинули, по философски =) Можно наверно сказать, что вредно думать обо всем, что может сломаться, ибо не так и важно нам это «все». Нам важно, чтобы ниче не сломалось, на данном нам уровне абстракции. Остальное мы не тестируем, и никак не можем (и хотим ли?) на это повлиять. Мы, по умолчанию, принимаем то, что куча вещей не может испортится (что противоречит исходному утверждению =), и что более важно, как привило, это недалеко от истины. Если непонятно, то я имею ввиду: вряд ли кто-то программируя на PHP, заботится о том, как сетевая карта посылает туда сюда пакеты, возникают ли там ошибки, и как их исправлять.
Нет, не весь. Если весь ваш код говно — вы хреновый программист. Код перестает быть говном, как только программист говорит, что-то вроде: «Да вот, тут, и там, и здесь я лажанулся, но это можно исправить». Т.е когда не приходится переписывать всю программу заново(т.е. система очень грамотно разбита на модули). Мне кажется, что вседаки есть очень большая разница м/у дерьмовым кодом и не дерьмовым. На мой взгляд она принципиальна — хороший можно изменять, расширить и улучшать, а не переписывать.
Ну вряд ли бесконечное. Я тоже где-то в книжке это видел, но число ошибок точно конечно(хотя в больших программах, оно наверно настолько большое, что можно смело считать его бесконечным). Ну тут ведь тоже не все так просто, могут быть ошибки в методе, классе, модуле, или в интеграции модулей. И вот ошибок в методе, уже точно не может быть бесконечно много. Мне кажется корректней было бы утверждать, что шанс того, что в программе есть ошибка всегда не равен нулю =) Весь вопрос в том, чтобы сделать так, что этот шанс -> 0. И еще было бы круто, еслиб мы знали, где именно может возникнуть ошибка, и могли оценить ее значимость. Вот в винде и других ОС бесконечно возникают ошибки. И что? Всем плевать, ибо они ну ОЧЕНЬ редко выводят систему из строя (особенно в «других ОС»). Не стоит бояться, этого мифического «бесконечного числа ошибок», на самом деле это не так (чтобы меня не запинали, это конечно так, но всем пофиг =) В программе, конечно, что-то может пойти не так, но можно сделать так, чтобы ошибка скорее возникала в каком-то определенном месте, а не где-то в программе, и так же (что важно) можно на эту ошибку среагировать и восстановить программу.
Да, клиенту на это вообще плевать. Но, вот что забавно, ему будет не плевать, когда проект провалиться, из-за того что вы не использовали, современные методики/средства и пр. Программисты не пишут на асм, не из-за клиента, а из-за себя. Ведь именно им потом со всем этим работать. Технологии очень сильно влияют на продукт, и то что клиент этого не понимает (ему нет непосредственной или мгновенной пользы от этого) не должно играть никакой роли при их использовании.
Да и проще тоже — лучше =) Я не совсем понимаю этого тезиса, что имеют ввиду автор? Что не стоит заранее писать расширенную функциональность? Мб не стоит усложнять код? Или не стоит писать лишний (sic!) код? Не стоит предсказывать все возможные случаи? Тогда, да, пожалуй, всего этого делать не стоит =)
Да, заказчики, очень любят послушать программистское исполнение роли Гамлета. Главная задача программиста — писать код ( ну и кончено «отладку, тестирование», обсуждение). Общение с заказчиками, вряд ли требуется от рядового программиста (тут конечно тоже много нюансов, но лучше бы программисту общаться только с другим программистами). Вообще, мне кажется, что порой к программисту предъявляют слишком много требований, не удивительно, что по некоторым из них он не подходит (поэтому в больших проектах, роли всегда достаточно хорошо разделены, и никто не требует от программистов всего).
Да, поэтому и передумывают всякие методы разработки. Моглибы упомянуть об этом. Заказчик как и любой другой человек не может предсказать всего. Проект оживает, и когда заказчик это видит, вполне естественно, что в живую у заказчика сформировывается более точное и правильное мнение, как должна работать та, или иная функция. Т.е он как-бы смотрит: ага да вот оно как на самом дело-то будет, и думает, а точно ли он именно это хотел (заказчик со временем лучше узнает проект). Это раздражает, но от этого наверно нельзя уйти =)
Точно, и написано уже миллион раз. Но этот полюбому особенный.
Да я и не думал, что вы придираетесь. Просто решил упомянуть забавный факт из биографии мистера Фейнмана. Но главным образом, хотел вседаки дать ссылку, на статью о математике, уж очень она мне кажется интересной.
Про математику недавно наткнулся(спасибо тому, кто дал ссылку, но уже не помню где) на просто поразительную статью о школьной математике: Пол Локхард «Плач математика». Советую хотябы бегло прочитать.
Ну в общем то php6 тут и не нужен, хватит php 5.3.
> А в случае self::$_instance не перепишется приватное поле родительского класса?
Гм, я не уверен, что понял, что именно вы спрашиваете. Если объявить в классе B static private $_instance, то нет, ничего не перепишется. Обращаясь к B self::$_instance и к Sin self::$_instance вы получите. Т.е когда модификатор свойства private потомок не может напрямую получить доступ к нему.
> А скобочки после new static не нужны?
Как вам больше нравиться =) Классы можно создавать и так и так. Т.е:
class B {}
$a = new B;
тоже вполне допустимо.
> Или static:: работает только для методов, но не для полей?
Нет, работает и так и так, как я уже писал здесь self только из-за того что поле private.