Да нет, просто изначальное решение делать первый WebOS телефон под определенного оператора США было крайне дебильным. Попытались отбить у Apple рынок, который принадлежал ей с потрохами. Нацелься они на другие рынки — мы бы вполне могли получить шикарного конкурента подыхающей Нокии.
Демон общается с сайтом, узнавая статус ноутбука. Когда ноутбук уводят — хозяин через сайт меняет статус на «украден» и демон начинает усиленно следить за новым «хозяином» устройства :-)
Для того, чтобы его отфармотировать, нужно сначала обзавестись диском или USB с MacOS. Я сомневаюсь, что у «уважаемого» Soheil Khalilfar где-то завалялся диск MacOS ;-)
Как связаны «теплый разум» и красивый ролик ни о чем? Я уже забыл, о какой модели Нокии он, а завтра забуду, что он о какой-то модели именно Нокии. Но да, он крут. Как и сотни других, необремененных деньгами корпораций красивых роликов. Свою цель он не выполняет. И не надо рассказывать про то, что ребята в такой корпорации как Нокия знают что делают — ребята там довели компанию до состояния придатка MS, хоронящего все собственные проекты. Во многом потому, что вместо того, чтобы заниматься разработкой нетормозящих телефонов (как Apple) — снимают ниочемные ролики. Это не мои слова — моей жены, глубоко далекой от способности принимать «холодные решения» про покупки телефонов.
Серьезно? Кто-то купит телефон за 400$ лишь потому, что вчера посмотрел невнятный ролик с его названием в конце??? Вы уж извините, но сильно сомневаюсь. Может, конечно, кто-то и купит, но, ИМХО, не большинство.
Полностью согласен. В качестве творческой единицы — ролик офигенен. В качестве рекламы — нулевой. Я никогда не задумаюсь о покупке девайся исходя из подобного ролика, да и о качестве камеры устройства этот ролик не говорит ровным счетом ничего — с тем же успехом, можно было снять его на обычную камеру, а в конце воткнуть: «Этот ролик был снят на обычную видеокамеру, но на деньги от маркетинговой компании N8. Покупай Nokia N8!» — эффект был бы абсолютно такой же.
Делать из HTML PDF это то еще извращение. Тем более что сорцы доков контрибутяться в открытом репозитории и всегда доступны для скачки/генерирования :-)
Полностью согласен с тем, что Symfony2 — ближе к Java, чем к Ruby. Но ровно настолько, насколько это нужно. Потому что сам PHP намного ближе к Java (далеко не во всем и не полностью) чем к Ruby или Python. В PHP нет открытых классов, поэтому как и в JAVA — ему необходимы тулы вроде сервис контейнера для гибкой связи между отдельными модулями и дата-мапперы для персистенс лэера, так как ActiveRecord чувствует себя ужасно на языке с закрытыми классами (смотрим Doctrine1).
Да, PHP в своей реализации ООП ближе к Java нежели к другим реально динамическим языкам. Да, Symfony2 построена на «взрослых» паттернах, пришедших из мира Java и Cocoa, потому что просто нет другого способа сделать систему настолько гибкой. И нет, это не заблуждение — это просто PHP-way. Если вам нужны рельсы — пользуйте Ruby, ибо правильные рельсы возможны лишь там и нигде больше. Хотите лучший фреймворк на PHP — пользуйте Symfony и свыкайтесь с тем, что для гибкой связи между объектами в PHP не существует лучшего способа чем DIC ;-)
Как минимум вся система шаблонов (twig) позаимствована из django, основная система конфигурации (yaml) из rails, менеджер ассетов из python (assetic), ORM и DIC из java. Мне продолжать или все-еще «ничего общего»?
«В моем примере выше РНР-код нехитрыми преобразованиями транслируется в человеческий язык и обратно.»
Если подразумевается, что никто кроме программистов этот код читать не будет, зачем эти преобразования?
А если подразумевается обратное, то, извините, но ваши описания никто кроме программиста прочитать все-равно не сможет. С хитрыми преобразованиями или без.
«Модель BDD просто помогает упростить их спецификацию.»
Методология сценарного BDD описывает разработку через поведенческие сценарии. Эти сценарии являются ни чем иным, как приемочным критерем разрабатываемых фич и могут быть использованы в качестве приемочных тестов. Но основная идея — именно в коммуникции со стэк-холдерами, продакт-овнерами, менеджерами и иже с ними.
«Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. „
Изящно заменяет. Если вы итак применяете аджайл и используете что-то вроде scrum или другой историйной методологии — вы УЖЕ пишете пользовательские истории. Behat позволяет эти истории использовать в качестве функциональных тестов. Были юзер-стори, остались юзер-стори. Только теперь они исполняемы!
Если вы ватерфолите и не в зуб ногой что такое гибкая разработка, тогда да. Вам будет казаться, что Behat требует излишней дополнительной работы и вам это все не нужно.
Код по определению не может быть понятен обычному человеку. Ну или у нас слишком разняться понятия «обычности».
Если перед вами стоит задача писать простые функциональные — никаких проблем. Пишите хоть на JAVA. Но не называйте это BDD! Когда я говорю «сценарий», я имею в виду «поведенческие сценарии», являющиеся частью методологии, а не то, что называете сценариями вы ;-)
При появлении новых коммитов, генерируем pdf с расточкой Сфинкса на Латекс: jimmyg.org/blog/2009/sphinx-pdf-generation-with-latex.html
Делать из HTML PDF это то еще извращение. Тем более что сорцы доков контрибутяться в открытом репозитории и всегда доступны для скачки/генерирования :-)
Да, PHP в своей реализации ООП ближе к Java нежели к другим реально динамическим языкам. Да, Symfony2 построена на «взрослых» паттернах, пришедших из мира Java и Cocoa, потому что просто нет другого способа сделать систему настолько гибкой. И нет, это не заблуждение — это просто PHP-way. Если вам нужны рельсы — пользуйте Ruby, ибо правильные рельсы возможны лишь там и нигде больше. Хотите лучший фреймворк на PHP — пользуйте Symfony и свыкайтесь с тем, что для гибкой связи между объектами в PHP не существует лучшего способа чем DIC ;-)
Doctrine 2.1
Если подразумевается, что никто кроме программистов этот код читать не будет, зачем эти преобразования?
А если подразумевается обратное, то, извините, но ваши описания никто кроме программиста прочитать все-равно не сможет. С хитрыми преобразованиями или без.
«Модель BDD просто помогает упростить их спецификацию.»
Методология сценарного BDD описывает разработку через поведенческие сценарии. Эти сценарии являются ни чем иным, как приемочным критерем разрабатываемых фич и могут быть использованы в качестве приемочных тестов. Но основная идея — именно в коммуникции со стэк-холдерами, продакт-овнерами, менеджерами и иже с ними.
«Но когда идет речь о том, что Behat изящно заменяет именно функциональное тестирование, то тут я не согласен. „
Изящно заменяет. Если вы итак применяете аджайл и используете что-то вроде scrum или другой историйной методологии — вы УЖЕ пишете пользовательские истории. Behat позволяет эти истории использовать в качестве функциональных тестов. Были юзер-стори, остались юзер-стори. Только теперь они исполняемы!
Если вы ватерфолите и не в зуб ногой что такое гибкая разработка, тогда да. Вам будет казаться, что Behat требует излишней дополнительной работы и вам это все не нужно.
Если перед вами стоит задача писать простые функциональные — никаких проблем. Пишите хоть на JAVA. Но не называйте это BDD! Когда я говорю «сценарий», я имею в виду «поведенческие сценарии», являющиеся частью методологии, а не то, что называете сценариями вы ;-)