Я правильно понимаю логику порождения объекта (как-то уж слишком много условий у Вас)?
if cls and mixin:
raise DecoratorMixinException
if mixin:
return Class
elif cls:
decorator(cls)
else:
decorator
P.S.
Раз уж Вы спросили. Каноническое именование декоратов классов, как и фабрики mixin-ов — с маленькой буквы.
Ну и пару комментарев бы поправил:
:param cls: class that would updates — мне кажется тут нужен пассивный залог
:param set_manager: sets is EnableManager is required — опечатка, первый «is» -> «if»
Атрибут не надо называть глаголом
+1. Я бы еще не стал называть параметр, у которого назначение — принимать значение по-умолчанию «status». Без чтения коментариев не понять. Другое дело если назвать «default» (не зря же дальше параметр передается именно с таким именем).
Создатели джанго — из особенной касты — им можно использовать метаклассы и прочие нетривиальные конструкции. А самим лучше туда не соваться. На худой конец чуть-чуть можно, если ты разработчик «3-rd party».
Утрировал конечно, но все же: чем пользователь фреймворка хуже?
Чувствую возможные сайд-эффекты. В чем именно проблема не наю, но чувствую что добром не кончится.
Ну можно конечно всю жизнь себя ограничивать в использовании конструкций сложнее @login_required, но зачем? :)
Проверить что новая моедль ведет себя нормально на самом деле не очень трудно.
Что сложно N-цать раз прописать одинаковые атрибуты и менеджеры?
Если из 200 моделей в проекте найдется парочка вот таких — да, лучше дописать явно.
А вот если из 200 моделей в 150 встречается добавление этого enabled, и что еще хуже для каждого queryset дописывается filter(enabled=True) — извините, но это уже плохой код. И попытка его улучшить не взирая сложность джанговского ORM-а — по-моему весьма похвальна.
Наверное сумбурно излагаю :)
Искренне верю, что «изучать паттерны» до того как «изобрел паттерны сам» — зло.
В самом деле, как начинающий программист должен понять, что не надо тыкать паттерны повсюду? Он еще не дошел свои умом, что некоторые концепции в дизайне его классов являются повторно используемыми, а его уже загоняют в рамки каких-то шаблонов, причем все чаще в формулироваке: «Это же сами GoF, каждый уважающий специалист должен знать на зубок!». Чего стоит один тот факт, что погонять по паттернам — излюбленный прием на собесдованиях.
В каком-то смысле, но не хочу быть неправильно истолкованным. Я считаю, что шаблоны — это хорошо (касается и design patterns, и development methodology, и подалуй даже процессов в команде). Это как повторное использование функций (т.е. удачных решений), но на ином уровне абстракции. Только чтобы по-нормальному думать такими категориями нужно сначала половину паттернов GoF (или любых других) самому изобрести и осознать.
А зло — это подход, предлагаемый автором:
Здесь вы не отвертитесь и применить хотя бы пару основных паттернов где-нибудь просто обязаны
По моим наблюдениям беды начинаются именно когда разработчик начинает думать: «Так, я же профессиноал, я знаю паттерны. Задача ясна, какой бы шаблон сюда прикрутить?..»
Прошел бы мимо, если бы не «критично». Нужно понимать как отлаживать код и уметь это делать. А вот само наличие какого-то конкретного отладчика и 8-й дан по его использованию — вторичны. Хорошо когда окружение дружественно, но если из знаний об отладке софта — только опыт использования чего-либо гуевого встроенного в IDE, многие интересные области окажутся закрытыми.
Познакомьтесь с шаблонами (паттернами) проектирования
Кругозор — это хорошо, как и умение быстро объясниться с коллегами. Только вот почему-то хуже слабеньких программистов встречаются только слабенькие программисты, обчитавшиеся паттернами.
Познакомьтесь с методологиями разработки
Кругозор — это очень хорошо. Изучение чужого удачног опыта — более чем похвально. Только вот почему-то хуже слабеньких лидов… ну вы поняли.
Не совсем понятен из ответа критерий по которому коммитятся файлы, но в любом случае мне кажется в Вашем случае нужно держать второй локальный репозиторий, а не просто дублирующую папку — так много проще и отбирать файлы для комита (бонус: можно коммитить только часть файлов; см. `git add -p`), и обновлять только изменившиеся файлы (обычным пушем, ведь только нужные файлы окажутся закоммиченными в дублируюший репозиторий).
Если немного дополнить схему работы, можно также обеспесить версионирование файлов, которые изменяются, но сейчас не комитятся («для продакщена»).
С другой стороны, в Нижнем Новгороде (за другие города не берусь утверждать) та самая широкая аудитория уже давно плотно окучена (2гис, дорога.тв, русавтобус, ...). Кроме временной форы им на руку играет более узкая специализация: в удачном интерфейсе для выбора маршрута общественного транспорта карте отводится в лушем случае половина места, ИМХО.
Несастным 30% же, особенно пытающимся строить маршруты на мобильном устройстве, приходится куда менее сладко, и ваше приложение для смартфонов могуло бы существенно помочь.
P.S. Почему размер аудитории является более более важным показателем, нежели частота использования фичи (которая по Вашей же оценке была бы выше, начни Яндекс с автомобильных маршрутов)? Вы же не за узнаваемость бренда боретесь. Или уникальные посетители потребляют больше дополнительных услуг?
Надеюсь отсутствие библиотечного бэйз64 — самая большая неприятность, доставленная платформой. Мы на пару с андройд-программистом параллельно разрабатывали версии приложения, также требующие кодирования/декодирования в бэйз — ни в айфоновской, ни в андройдной версии SDK не оказалось нужных библиотек. Он по-моему мерджил из будущих версий, мне пришлось самому писать (для ObjC в принципе меньше библиотек). В общем достаточно типичная и к счастью не серьезная проблема при разработке для мобильных устройств.
Идея отличная, реализацию только на эмуляторе смогу завтра заценить. Отдельно рад что API жуйка развивается. Ты большой молодец, желаю успехов на конкурсе.
P.S. Также хочется верить, что такое неожиданное изменение даст толчок к синхронизации и доведения до полного состояния всех вариантов API, и что все большее число разработчиков буду этим пользоваться.
Ну, значит я изначально не ошибся и Вы позиционируете данное решние как готовое.
Тогда первый комментарий в силе, и я продолжаю утверждать, что предложенным на выход форматом пользоваться неудобно (ага, это мое субъективное мнение, но я был бы рад услышать о перпендикулярных критериях удобства). Я уж не знаю какие нужды у Вас, если даже искать все item в result нет подтребности, но обычно хотя бы такие вызовы бывают нужны (наряду с получить значение аттрибута в виде строки/числа/boolean).
Общие замечания:
— Вы же хотели «поделиться своим решением парсинга XML», а не научить писать самому ради интереса, правильно?
— Обычно «парсинг» предполагает более-менее универсальную форму, подходящую под множество прикладных задач. Писать отдельный парсер под каждую микрозадачу — это наверное «интересно» и уж точно «не проще», но и цель не ясна ;)
P.S. Последнего предложения я не понял вовсе, потому что а) обычно стараются использовать наиболее высокоуровневые возможности (т.е. классы Objective-C в данном случае) и б) насколько я понимаю, libxml и так доступен, и всегда таковым был.
Навероное плохо выразился или недопонял суть статьи.
Насколько я понял, Вами предлагается иметь на входе массив данных в формате XML, на выходе — словарь предложенной структуры. Я всего лишь заметил, что с таким выходом работать нелегко. Конечно под капотом потребуется итерация (хотя наверняка можно придумать, более быстрые варианты, чем обход всех детей в поисках нужных) по внутренним элементам, но суть моего предложения — поиметь удобные методы для работы, типа:
[(DDXMLElement *) root elementsForName:@«item»];
Всегда можно сказать: «надо всего лишь описать метод в 5 строк для выборки», а потом «дополнительная индексация прикручивается за 2 хода» и закончить «ничего не мешает объединить это все в единый класс». Я же говорю всего лишь о возможности сразу взять готовый набор классов и методов (с потенциальной возможностью выкинуть этот код безболезненно в будущих версиях SDK).
+1 зы KissXML. Во-первых, его классы совместимы с маковскими NSXML… анлогами, что дает надежду на замену нативными средствами в будущем. А во-вторых, та самая структура результатов, о которой упоминул автор, дает возможность более удобной обработки. Так тривиальная и постоянно встречающаяся задача «вытащить все элементы item из result», решаемая вызовом единственного метода, при описанном в статье подход превращается у увлекаельное итерирование по всем элементам child, на сколько я понимаю.
Оставляя в стороне всякие незначительные стилистические моменты типа вопросительных знаков в описаниях опций и странности в обращении к читателю (то на «ты», то на «вы», причем именно с маленькой буквы), хочется заметить, что перевод пары терминов на русский (на мой вкус) выглядит спорным:
— «метод конкуренции» — неудачная калька с английского. Метод распараллеливания, способ одновременного исполнения,…
— «и это очень хорошее чтение» — под «чтением» обычно подразумевают процесс. «Чтиво» (если просторечно) или, например, источник.
Сам откладывал чтение Advent'а до выхода последней статьи, поэтому Ваш перевод прочитал раньше оригинала. Большое спасибо за труд; сборка советов очень грамотная, поэтому буду использовать сам и рекомендовать в качестве памятки.
Ну вот еще бы исправить это «достоинство» (конечно же интересует не демоническая природа сама по себе, а наличие быстрого доступа к статусу/командам через иконку в notification area — как у той же ExpandDrive) и утилита станет не только юзабельна, но и годна для повседневного интенивного применения.
Большое спасибо за цикл, полагаю многим начинающим Objective-C разработчикам будет небезинтересно.
На всякий случай пример с системной областью уведомления:
1. Хочется придираться — придирайтесь по делу (только вот зачем, на смысл ведь не влияет?). Правильно киби-, а не кило- (потому что в основании 2-ка, а не 10-ка). И как уже сказали бита, а не байта.
2. Ваше последнее утверждение сродни следующему: «в сантиметрах — только деления на линейке, а все остальное измеряется в метрах». На самом же деле, ничего не мешает все измеряемое в байтах измерять и в битах, и наоборот.
3. Если же Вы про традиции, намекая на боды (бит/с), в которых на самом деле измеряют только скорость, то в шифровании использование битов, а не байтов — не менее классический случай.
P.S.
Раз уж Вы спросили. Каноническое именование декоратов классов, как и фабрики mixin-ов — с маленькой буквы.
Ну и пару комментарев бы поправил:
:param cls: class that would updates — мне кажется тут нужен пассивный залог
:param set_manager: sets is EnableManager is required — опечатка, первый «is» -> «if»
+1. Я бы еще не стал называть параметр, у которого назначение — принимать значение по-умолчанию «status». Без чтения коментариев не понять. Другое дело если назвать «default» (не зря же дальше параметр передается именно с таким именем).
Утрировал конечно, но все же: чем пользователь фреймворка хуже?
Ну можно конечно всю жизнь себя ограничивать в использовании конструкций сложнее @login_required, но зачем? :)
Проверить что новая моедль ведет себя нормально на самом деле не очень трудно.
Если из 200 моделей в проекте найдется парочка вот таких — да, лучше дописать явно.
А вот если из 200 моделей в 150 встречается добавление этого enabled, и что еще хуже для каждого queryset дописывается filter(enabled=True) — извините, но это уже плохой код. И попытка его улучшить не взирая сложность джанговского ORM-а — по-моему весьма похвальна.
Искренне верю, что «изучать паттерны» до того как «изобрел паттерны сам» — зло.
В самом деле, как начинающий программист должен понять, что не надо тыкать паттерны повсюду? Он еще не дошел свои умом, что некоторые концепции в дизайне его классов являются повторно используемыми, а его уже загоняют в рамки каких-то шаблонов, причем все чаще в формулироваке: «Это же сами GoF, каждый уважающий специалист должен знать на зубок!». Чего стоит один тот факт, что погонять по паттернам — излюбленный прием на собесдованиях.
А зло — это подход, предлагаемый автором:
По моим наблюдениям беды начинаются именно когда разработчик начинает думать: «Так, я же профессиноал, я знаю паттерны. Задача ясна, какой бы шаблон сюда прикрутить?..»
Прошел бы мимо, если бы не «критично». Нужно понимать как отлаживать код и уметь это делать. А вот само наличие какого-то конкретного отладчика и 8-й дан по его использованию — вторичны. Хорошо когда окружение дружественно, но если из знаний об отладке софта — только опыт использования чего-либо гуевого встроенного в IDE, многие интересные области окажутся закрытыми.
Кругозор — это хорошо, как и умение быстро объясниться с коллегами. Только вот почему-то хуже слабеньких программистов встречаются только слабенькие программисты, обчитавшиеся паттернами.
Кругозор — это очень хорошо. Изучение чужого удачног опыта — более чем похвально. Только вот почему-то хуже слабеньких лидов… ну вы поняли.
Если немного дополнить схему работы, можно также обеспесить версионирование файлов, которые изменяются, но сейчас не комитятся («для продакщена»).
Несастным 30% же, особенно пытающимся строить маршруты на мобильном устройстве, приходится куда менее сладко, и ваше приложение для смартфонов могуло бы существенно помочь.
P.S. Почему размер аудитории является более более важным показателем, нежели частота использования фичи (которая по Вашей же оценке была бы выше, начни Яндекс с автомобильных маршрутов)? Вы же не за узнаваемость бренда боретесь. Или уникальные посетители потребляют больше дополнительных услуг?
Идея отличная, реализацию только на эмуляторе смогу завтра заценить. Отдельно рад что API жуйка развивается. Ты большой молодец, желаю успехов на конкурсе.
P.S. Также хочется верить, что такое неожиданное изменение даст толчок к синхронизации и доведения до полного состояния всех вариантов API, и что все большее число разработчиков буду этим пользоваться.
Тогда первый комментарий в силе, и я продолжаю утверждать, что предложенным на выход форматом пользоваться неудобно (ага, это мое субъективное мнение, но я был бы рад услышать о перпендикулярных критериях удобства). Я уж не знаю какие нужды у Вас, если даже искать все item в result нет подтребности, но обычно хотя бы такие вызовы бывают нужны (наряду с получить значение аттрибута в виде строки/числа/boolean).
Общие замечания:
— Вы же хотели «поделиться своим решением парсинга XML», а не научить писать самому ради интереса, правильно?
— Обычно «парсинг» предполагает более-менее универсальную форму, подходящую под множество прикладных задач. Писать отдельный парсер под каждую микрозадачу — это наверное «интересно» и уж точно «не проще», но и цель не ясна ;)
P.S. Последнего предложения я не понял вовсе, потому что а) обычно стараются использовать наиболее высокоуровневые возможности (т.е. классы Objective-C в данном случае) и б) насколько я понимаю, libxml и так доступен, и всегда таковым был.
Насколько я понял, Вами предлагается иметь на входе массив данных в формате XML, на выходе — словарь предложенной структуры. Я всего лишь заметил, что с таким выходом работать нелегко. Конечно под капотом потребуется итерация (хотя наверняка можно придумать, более быстрые варианты, чем обход всех детей в поисках нужных) по внутренним элементам, но суть моего предложения — поиметь удобные методы для работы, типа:
[(DDXMLElement *) root elementsForName:@«item»];
Всегда можно сказать: «надо всего лишь описать метод в 5 строк для выборки», а потом «дополнительная индексация прикручивается за 2 хода» и закончить «ничего не мешает объединить это все в единый класс». Я же говорю всего лишь о возможности сразу взять готовый набор классов и методов (с потенциальной возможностью выкинуть этот код безболезненно в будущих версиях SDK).
— «метод конкуренции» — неудачная калька с английского. Метод распараллеливания, способ одновременного исполнения,…
— «и это очень хорошее чтение» — под «чтением» обычно подразумевают процесс. «Чтиво» (если просторечно) или, например, источник.
Сам откладывал чтение Advent'а до выхода последней статьи, поэтому Ваш перевод прочитал раньше оригинала. Большое спасибо за труд; сборка советов очень грамотная, поэтому буду использовать сам и рекомендовать в качестве памятки.
Подозреваю, речь шла об /etc/sudoers
Ну вот еще бы исправить это «достоинство» (конечно же интересует не демоническая природа сама по себе, а наличие быстрого доступа к статусу/командам через иконку в notification area — как у той же ExpandDrive) и утилита станет не только юзабельна, но и годна для повседневного интенивного применения.
Большое спасибо за цикл, полагаю многим начинающим Objective-C разработчикам будет небезинтересно.
На всякий случай пример с системной областью уведомления:
2. Ваше последнее утверждение сродни следующему: «в сантиметрах — только деления на линейке, а все остальное измеряется в метрах». На самом же деле, ничего не мешает все измеряемое в байтах измерять и в битах, и наоборот.
3. Если же Вы про традиции, намекая на боды (бит/с), в которых на самом деле измеряют только скорость, то в шифровании использование битов, а не байтов — не менее классический случай.