Не понял, как это относится к «самостоятельному» восстановлению. Вот если бы вы мне описали, как этот демон мониторится, какие факторы используются для трактовки его смерти/недоступности, какими средствами он автоматически ликвидируется, и какой механизм используется для его восстановления, как эксплуататор api умеет и пытается повторить упущенные за время простоя демона шаги, это можно было бы как-то считать самостоятельностью.
Очевидно, мы с вами подразумеваем под системой разные её уровни, либо вовсе разные вещи.
В общем, комментарий задумывался о том, что самостоятельность восстановления системы в большинстве случаев избыточна (если, конечно, мы не говорим о системе жизнеобеспечения на php %)) или неподъёмна/недостижима в текущих условиях.
Система должна самостоятельно уметь восстанавливаться после смерти в любой произвольный момент времени [...]
К сожалению, для большинства случаев это утопия, а потому я бы сместил планку пониже: система должна предоставлять инструменты для контроля смерти, или, на худой конец, — жизни %P Примерно об этом и пишет автор.
Все говорят про какой-то абстрактный порог вхождения.
Не скажу за всех, но в целом всё верно: порог вхожения — понятие абстрактное и по-иному быть не может, ибо для каждого этот порог свой.
Вот честное слово, такое чувство будто человек который будет заниматься версткой это медицинский дебил.
Странное чувство. Непонятно, откуда оно у вас. Речь шла о том, что людям, занимающимся дизайном/вёрсткой должно быть не досуг думать о том, как, например, обратиться к атрибуту сущности (вне зависимости от того, массив это, скажем, или объект), как обработать ошибку доступа к методу объекта, и в том же духе, — им бы вместо этого свою работу выполнять и другим проблем не создавать.
Давайте уже не кривя душей скажем, что 95% кодинга [...]
Возможно покрываются, возможно нет. Никогда не интересовался этим процентом.
Просто вот лично я не видел ни разу чтобы шаблоны имели хоть какое-то реально положительное влияние на проект.
Ну, я тоже, к примеру, не видел, чтобы поклонение шаблонам проектирования имело какое-то реально положительное влияние на проект, а некоторые божатся, что такое имеет место быть %)
Джинжу Армин срисовывал с Джанго, не удивительно, что синтаксис «почти такой же».
Портировать Джинжу полноценно не получилось бы в любом случае: Армин пытался, но понял тщетность затеи. Потом, правда, идею подхватил Фабьен в своём Твиге, адаптировав под реалии PHP — и со скоростью у него всё в порядке вышло, да только в области расширения случился прокол — слишком накладно писать свои теги.
забавно, когда-то, когда писал на php
Скорее закономерно: идеи кочуют. Хорошо, когда это хорошие идеи %)
Слова «сравнительное тестирование» для меня звучат зловеще. Если често, то я не уверен, что в сравнительных тестированиях есть толк, в смысле их полезности для кого-либо, кроме тестирующего.
Поясню:
Во-первых, не ясно, кому какие критерии интересны.
Во-вторых, не ясно на какой конфигурации проводить замеры. Ещё ни разу, ознакомившись с результатами тестов, я не смог прикинуть, как этот пациент будет вести себя на целевой конфигурации.
Во-третьих, результаты тестирования будут отражать состояние вещей на текущий конкретный момент и уже завтра могут перестать соответствовать действительности.
Поэтому для себя я просто сравниваю. Без тестов.
Впрочем, мои тараканы, конечно же, ни к коей мере не мешают производителям шаблонизаторов, например, замерять скорость работы. А эти данные обычно имеются в открытом доступе на сайтах производителей.
Не понял, конфигурацию чего вы имеете в виду, но в качестве запрошенного примера могу предложить описания из разделов статьи «Синтаксис» и «Безопасность», то есть это опять-таки разговор о количестве логики, которую можно вынести в шаблоны — об уровнях абстакции. Если для вас дополнительный слой логики обоснованно избыточен — не нужно его использовать. Проводя аналогию: ООП — это тоже слой абстракции, без которого люди успешно обходятся и будут обходиться.
О примерах: если поручить работу над шаблонами лицу, не связанному с программированием [не знакомому с PHP], это лицо быстрее выучивает ограниченный набор команд шаблонизатора. Видимо, потому, что объем материала меньше. У этого лица не будет возможности вмешатся в функционирование основного потока приложения и, возможно нечаянно, но с большой вероятностью озадачить разработчиков поиском ошибки в своём коде. Если шаблоны поддерживают программисты, то им часто шаблонизатор диктует держаться в рамках: замечено, что при использовании шаблонизатора чаще задумываешься о том, стоит ли ту или иную часть логики реализовывать в шаблоне.
Повторюсь: всё описанное, конечно, возможно и без применения шаблонизаторов, просто требует большего количества усилий, например, организаторских.
И на всякий случай поясню, что «жизненно» из цитаты относится к успешности существования проекта, а не его участников %)
В советских-российских школах элементы гамификации введены скорее для других целей и не все педагоги понимают их возможности.
Скорее так: элементы игры присутствуют в школах по всему миру, ввиду неоспоримого (благодаря обильной практике со времен происхождения человека, наблюдениям, и исследованиям по данной теме) факта, что до определенного возраста (см. методички по методике преподавания в педагогических ВУЗах) игровая деятельность является для детей ведущей.
Таким образом, взрослые люди используют игру для обучения детей, превращая её в средство познания мира. Это игра ради познания.
Среди взрослых людей более распространена игра ради самоутверждения. Вот достижения, награды и пр. линейки как раз про это.
И апофеозом всему — терминальная стадия — игра ради игры.
Если помните, все эти «эксперименты» индуцировала Nintendo с консолью Wii. И с эксклюзивами там традиционно было всё путём. Да и сейчас всё ещё можно надеяться, что Wii U тоже неплохо себя покажет.
Адекватные аналоги на русском можно и нужно использовать, как бы ужасно, по чьему-либо мнению, они не звучали. Чего не стоит делать, так это мешать «coroutines», «сопрограммы» и «корутины» в одном месте.
Калькирование «корутины» уже плохо тем, что провоцирует лингвистически неискушенного человека на ошибки при склонении.
В остальном перевод читается довольно гладко. Спасибо.
Понятия «правильной архитектуры» и «эффективного программирования» ортогональны обоим упомянутым вам понятиям типизации. Напрасно вы всё это в кучу собрали.
Эффективность обуславливается опытом и инструментами (как на уровня языка, так и уровня сред программирования), а правильность архитектуры вообще эфимерна.
Остается только расценивать вашу статью как обзор phpDoc и typehinting.
Очевидно, мы с вами подразумеваем под системой разные её уровни, либо вовсе разные вещи.
В общем, комментарий задумывался о том, что самостоятельность восстановления системы в большинстве случаев избыточна (если, конечно, мы не говорим о системе жизнеобеспечения на php %)) или неподъёмна/недостижима в текущих условиях.
К сожалению, для большинства случаев это утопия, а потому я бы сместил планку пониже: система должна предоставлять инструменты для контроля смерти, или, на худой конец, — жизни %P Примерно об этом и пишет автор.
На прошлой неделе Джейкоб забегал, рассказал про «экспериментальность» — github.com/idlesign/django-sitetree/pull/93#issuecomment-13890792
Не скажу за всех, но в целом всё верно: порог вхожения — понятие абстрактное и по-иному быть не может, ибо для каждого этот порог свой.
Странное чувство. Непонятно, откуда оно у вас. Речь шла о том, что людям, занимающимся дизайном/вёрсткой должно быть не досуг думать о том, как, например, обратиться к атрибуту сущности (вне зависимости от того, массив это, скажем, или объект), как обработать ошибку доступа к методу объекта, и в том же духе, — им бы вместо этого свою работу выполнять и другим проблем не создавать.
Возможно покрываются, возможно нет. Никогда не интересовался этим процентом.
Ну, я тоже, к примеру, не видел, чтобы поклонение шаблонам проектирования имело какое-то реально положительное влияние на проект, а некоторые божатся, что такое имеет место быть %)
Портировать Джинжу полноценно не получилось бы в любом случае: Армин пытался, но понял тщетность затеи. Потом, правда, идею подхватил Фабьен в своём Твиге, адаптировав под реалии PHP — и со скоростью у него всё в порядке вышло, да только в области расширения случился прокол — слишком накладно писать свои теги.
Скорее закономерно: идеи кочуют. Хорошо, когда это хорошие идеи %)
Поясню:
Поэтому для себя я просто сравниваю. Без тестов.
Впрочем, мои тараканы, конечно же, ни к коей мере не мешают производителям шаблонизаторов, например, замерять скорость работы. А эти данные обычно имеются в открытом доступе на сайтах производителей.
О примерах: если поручить работу над шаблонами лицу, не связанному с программированием [не знакомому с PHP], это лицо быстрее выучивает ограниченный набор команд шаблонизатора. Видимо, потому, что объем материала меньше. У этого лица не будет возможности вмешатся в функционирование основного потока приложения и, возможно нечаянно, но с большой вероятностью озадачить разработчиков поиском ошибки в своём коде. Если шаблоны поддерживают программисты, то им часто шаблонизатор диктует держаться в рамках: замечено, что при использовании шаблонизатора чаще задумываешься о том, стоит ли ту или иную часть логики реализовывать в шаблоне.
Повторюсь: всё описанное, конечно, возможно и без применения шаблонизаторов, просто требует большего количества усилий, например, организаторских.
И на всякий случай поясню, что «жизненно» из цитаты относится к успешности существования проекта, а не его участников %)
Скорее так: элементы игры присутствуют в школах по всему миру, ввиду неоспоримого (благодаря обильной практике со времен происхождения человека, наблюдениям, и исследованиям по данной теме) факта, что до определенного возраста (см. методички по методике преподавания в педагогических ВУЗах) игровая деятельность является для детей ведущей.
Таким образом, взрослые люди используют игру для обучения детей, превращая её в средство познания мира. Это игра ради познания.
Среди взрослых людей более распространена игра ради самоутверждения. Вот достижения, награды и пр. линейки как раз про это.
И апофеозом всему — терминальная стадия — игра ради игры.
Калькирование «корутины» уже плохо тем, что провоцирует лингвистически неискушенного человека на ошибки при склонении.
В остальном перевод читается довольно гладко. Спасибо.
Эффективность обуславливается опытом и инструментами (как на уровня языка, так и уровня сред программирования), а правильность архитектуры вообще эфимерна.
Остается только расценивать вашу статью как обзор phpDoc и typehinting.