• Bitcasa стартанула!
    0
    Декрементирую и благодарю.
  • Чуть-чуть «извращений» над моделями django
    +1
    Я правильно понимаю логику порождения объекта (как-то уж слишком много условий у Вас)?
    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»

  • Чуть-чуть «извращений» над моделями django
    0
    Вычленил 4 мысли, поправьте если чего недопонял:
    • Атрибут не надо называть глаголом
      +1. Я бы еще не стал называть параметр, у которого назначение — принимать значение по-умолчанию «status». Без чтения коментариев не понять. Другое дело если назвать «default» (не зря же дальше параметр передается именно с таким именем).
    • Создатели джанго — из особенной касты — им можно использовать метаклассы и прочие нетривиальные конструкции. А самим лучше туда не соваться. На худой конец чуть-чуть можно, если ты разработчик «3-rd party».
      Утрировал конечно, но все же: чем пользователь фреймворка хуже?
    • Чувствую возможные сайд-эффекты. В чем именно проблема не наю, но чувствую что добром не кончится.
      Ну можно конечно всю жизнь себя ограничивать в использовании конструкций сложнее @login_required, но зачем? :)
      Проверить что новая моедль ведет себя нормально на самом деле не очень трудно.
    • Что сложно N-цать раз прописать одинаковые атрибуты и менеджеры?
      Если из 200 моделей в проекте найдется парочка вот таких — да, лучше дописать явно.
      А вот если из 200 моделей в 150 встречается добавление этого enabled, и что еще хуже для каждого queryset дописывается filter(enabled=True) — извините, но это уже плохой код. И попытка его улучшить не взирая сложность джанговского ORM-а — по-моему весьма похвальна.
  • Советы себе в прошлом
    +2
    Наверное сумбурно излагаю :)
    Искренне верю, что «изучать паттерны» до того как «изобрел паттерны сам» — зло.

    В самом деле, как начинающий программист должен понять, что не надо тыкать паттерны повсюду? Он еще не дошел свои умом, что некоторые концепции в дизайне его классов являются повторно используемыми, а его уже загоняют в рамки каких-то шаблонов, причем все чаще в формулироваке: «Это же сами GoF, каждый уважающий специалист должен знать на зубок!». Чего стоит один тот факт, что погонять по паттернам — излюбленный прием на собесдованиях.
  • Советы себе в прошлом
    +4
    В каком-то смысле, но не хочу быть неправильно истолкованным. Я считаю, что шаблоны — это хорошо (касается и design patterns, и development methodology, и подалуй даже процессов в команде). Это как повторное использование функций (т.е. удачных решений), но на ином уровне абстракции. Только чтобы по-нормальному думать такими категориями нужно сначала половину паттернов GoF (или любых других) самому изобрести и осознать.

    А зло — это подход, предлагаемый автором:
    Здесь вы не отвертитесь и применить хотя бы пару основных паттернов где-нибудь просто обязаны

    По моим наблюдениям беды начинаются именно когда разработчик начинает думать: «Так, я же профессиноал, я знаю паттерны. Задача ясна, какой бы шаблон сюда прикрутить?..»
  • Советы себе в прошлом
    +11
    Научитесь пользоваться отладчиком

    Прошел бы мимо, если бы не «критично». Нужно понимать как отлаживать код и уметь это делать. А вот само наличие какого-то конкретного отладчика и 8-й дан по его использованию — вторичны. Хорошо когда окружение дружественно, но если из знаний об отладке софта — только опыт использования чего-либо гуевого встроенного в IDE, многие интересные области окажутся закрытыми.

    Познакомьтесь с шаблонами (паттернами) проектирования

    Кругозор — это хорошо, как и умение быстро объясниться с коллегами. Только вот почему-то хуже слабеньких программистов встречаются только слабенькие программисты, обчитавшиеся паттернами.

    Познакомьтесь с методологиями разработки

    Кругозор — это очень хорошо. Изучение чужого удачног опыта — более чем похвально. Только вот почему-то хуже слабеньких лидов… ну вы поняли.
  • Git 1.7.7
    +3
    Не совсем понятен из ответа критерий по которому коммитятся файлы, но в любом случае мне кажется в Вашем случае нужно держать второй локальный репозиторий, а не просто дублирующую папку — так много проще и отбирать файлы для комита (бонус: можно коммитить только часть файлов; см. `git add -p`), и обновлять только изменившиеся файлы (обычным пушем, ведь только нужные файлы окажутся закоммиченными в дублируюший репозиторий).
    Если немного дополнить схему работы, можно также обеспесить версионирование файлов, которые изменяются, но сейчас не комитятся («для продакщена»).
  • По Екатеринбургу, Нижнему Новгороду и Челябинску на общественном транспорте
    0
    С другой стороны, в Нижнем Новгороде (за другие города не берусь утверждать) та самая широкая аудитория уже давно плотно окучена (2гис, дорога.тв, русавтобус, ...). Кроме временной форы им на руку играет более узкая специализация: в удачном интерфейсе для выбора маршрута общественного транспорта карте отводится в лушем случае половина места, ИМХО.
    Несастным 30% же, особенно пытающимся строить маршруты на мобильном устройстве, приходится куда менее сладко, и ваше приложение для смартфонов могуло бы существенно помочь.

    P.S. Почему размер аудитории является более более важным показателем, нежели частота использования фичи (которая по Вашей же оценке была бы выше, начни Яндекс с автомобильных маршрутов)? Вы же не за узнаваемость бренда боретесь. Или уникальные посетители потребляют больше дополнительных услуг?
  • Паттерны проектирования для iOS разработчиков. Observer, часть I
    +2
    Может пригодится (если кто еще не видел): Cocoa Design Patterns
  • ВикиГид — Android-энциклопедия достопримечательностей Украины
    0
    Надеюсь отсутствие библиотечного бэйз64 — самая большая неприятность, доставленная платформой. Мы на пару с андройд-программистом параллельно разрабатывали версии приложения, также требующие кодирования/декодирования в бэйз — ни в айфоновской, ни в андройдной версии SDK не оказалось нужных библиотек. Он по-моему мерджил из будущих версий, мне пришлось самому писать (для ObjC в принципе меньше библиотек). В общем достаточно типичная и к счастью не серьезная проблема при разработке для мобильных устройств.
    Идея отличная, реализацию только на эмуляторе смогу завтра заценить. Отдельно рад что API жуйка развивается. Ты большой молодец, желаю успехов на конкурсе.
    P.S. Также хочется верить, что такое неожиданное изменение даст толчок к синхронизации и доведения до полного состояния всех вариантов API, и что все большее число разработчиков буду этим пользоваться.
  • Парсинг XML в NSDictionary при помощи libxml
    0
    Ну, значит я изначально не ошибся и Вы позиционируете данное решние как готовое.
    Тогда первый комментарий в силе, и я продолжаю утверждать, что предложенным на выход форматом пользоваться неудобно (ага, это мое субъективное мнение, но я был бы рад услышать о перпендикулярных критериях удобства). Я уж не знаю какие нужды у Вас, если даже искать все item в result нет подтребности, но обычно хотя бы такие вызовы бывают нужны (наряду с получить значение аттрибута в виде строки/числа/boolean).

    Общие замечания:
    — Вы же хотели «поделиться своим решением парсинга XML», а не научить писать самому ради интереса, правильно?
    — Обычно «парсинг» предполагает более-менее универсальную форму, подходящую под множество прикладных задач. Писать отдельный парсер под каждую микрозадачу — это наверное «интересно» и уж точно «не проще», но и цель не ясна ;)

    P.S. Последнего предложения я не понял вовсе, потому что а) обычно стараются использовать наиболее высокоуровневые возможности (т.е. классы Objective-C в данном случае) и б) насколько я понимаю, libxml и так доступен, и всегда таковым был.
  • Парсинг XML в NSDictionary при помощи libxml
    0
    Навероное плохо выразился или недопонял суть статьи.

    Насколько я понял, Вами предлагается иметь на входе массив данных в формате XML, на выходе — словарь предложенной структуры. Я всего лишь заметил, что с таким выходом работать нелегко. Конечно под капотом потребуется итерация (хотя наверняка можно придумать, более быстрые варианты, чем обход всех детей в поисках нужных) по внутренним элементам, но суть моего предложения — поиметь удобные методы для работы, типа:

    [(DDXMLElement *) root elementsForName:@«item»];

    Всегда можно сказать: «надо всего лишь описать метод в 5 строк для выборки», а потом «дополнительная индексация прикручивается за 2 хода» и закончить «ничего не мешает объединить это все в единый класс». Я же говорю всего лишь о возможности сразу взять готовый набор классов и методов (с потенциальной возможностью выкинуть этот код безболезненно в будущих версиях SDK).
  • Парсинг XML в NSDictionary при помощи libxml
    0
    +1 зы KissXML. Во-первых, его классы совместимы с маковскими NSXML… анлогами, что дает надежду на замену нативными средствами в будущем. А во-вторых, та самая структура результатов, о которой упоминул автор, дает возможность более удобной обработки. Так тривиальная и постоянно встречающаяся задача «вытащить все элементы item из result», решаемая вызовом единственного метода, при описанном в статье подход превращается у увлекаельное итерирование по всем элементам child, на сколько я понимаю.
  • Альтернатива UISplitViewController (отображение MasterView в книжной ориентации устройства)
    0
    Cпасибо за эту статью, а анонсированную в конце прочел бы с особым интересом.
  • Comment from a drafted post.
  • Развертывание сайта на Джанго, используя FastCGI
    +1
    Александр Кошелев там в первом же комментарии весьма аргументировано, как мне кажется, высказался, почему тот тест лучше вообще не читать
  • Развертывание сайта на Джанго, используя FastCGI
    +2
    Оставляя в стороне всякие незначительные стилистические моменты типа вопросительных знаков в описаниях опций и странности в обращении к читателю (то на «ты», то на «вы», причем именно с маленькой буквы), хочется заметить, что перевод пары терминов на русский (на мой вкус) выглядит спорным:
    — «метод конкуренции» — неудачная калька с английского. Метод распараллеливания, способ одновременного исполнения,…
    — «и это очень хорошее чтение» — под «чтением» обычно подразумевают процесс. «Чтиво» (если просторечно) или, например, источник.

    Сам откладывал чтение Advent'а до выхода последней статьи, поэтому Ваш перевод прочитал раньше оригинала. Большое спасибо за труд; сборка советов очень грамотная, поэтому буду использовать сам и рекомендовать в качестве памятки.
  • Развертывание сайта на Джанго, используя FastCGI
    0
    Если мы хотим использовать команду sudo с нашим пользователем, то нам так же нужно отредактировать /etc/service

    Подозреваю, речь шла об /etc/sudoers
  • Управление памятью в Objective C, работа с KeyChain, GUI-утилита для монтирования SSHFS
    +1
    не требует запуска отдельного демона

    Ну вот еще бы исправить это «достоинство» (конечно же интересует не демоническая природа сама по себе, а наличие быстрого доступа к статусу/командам через иконку в notification area — как у той же ExpandDrive) и утилита станет не только юзабельна, но и годна для повседневного интенивного применения.
    Большое спасибо за цикл, полагаю многим начинающим Objective-C разработчикам будет небезинтересно.
    На всякий случай пример с системной областью уведомления:
  • Организация SSH Layer 3 туннеля
    0
    1. Хочется придираться — придирайтесь по делу (только вот зачем, на смысл ведь не влияет?). Правильно киби-, а не кило- (потому что в основании 2-ка, а не 10-ка). И как уже сказали бита, а не байта.
    2. Ваше последнее утверждение сродни следующему: «в сантиметрах — только деления на линейке, а все остальное измеряется в метрах». На самом же деле, ничего не мешает все измеряемое в байтах измерять и в битах, и наоборот.
    3. Если же Вы про традиции, намекая на боды (бит/с), в которых на самом деле измеряют только скорость, то в шифровании использование битов, а не байтов — не менее классический случай.
  • PastryKit: средство разработки сайтов для iPhone, написанное в Apple
    +1
    Скажу честно — не видел его ни разу, но судя по замечанию в оригинальной статье:
    But on the whole this User Guide app and the PastryKit framework are rather amazing. The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?

    видимо не все так хорошо…
  • Route Me — альтернатива встроенному Google Maps контролу из iPhone SDK 3.0+
    +1
    Спасибо за статью — всегда приятно узнать про имеющиеся открытые альтернативы. Смотрел месяца 3 назад на Cloud Made'овскую библиотеку, был неприятно поражен чужеродностью. Кругом бросалось в глаза явное портирование с Plain C (к примеру методы без именнованых параметров). Приведенный здесь код выглядит приятнее, хотя на отрисовку маршрута неплохо было бы посмотреть.

    Незначительный вопрос/замечание по коду: после
    BOOL toShow = [mapSourcePicker isHidden];

    этот вызов используется еще пару раз. Это специально сделано? Потому что использование переменной вместо вызовов кажется предпочтительныи не только по соображениям производительности, но еще и читаемости.
  • PastryKit: средство разработки сайтов для iPhone, написанное в Apple
    +1
    Если пройти по любой ссылке из поста — сразу отпадет половина вопросов. И про проблемы с фиксацией, и про разницу в прокрутках и про устранение адресой строки (не только при запуске с десктопа) — весьма доходчиво написано. Сделать без библиотек можно вообще все — они же пользуются общедоступными средствами JS и CSS. Вопрос — надо ли самому пытаться переписать например систему View, чтобы веб-приложение выглядело нативно, если есть уже готоовая либа от Эппла?
  • Google Chrome получил собственный клиппер
    0
    Опера нерасширябельна. Так что приходится обходиться без 1Password и Evernote
  • Вместо Qt Opera будет использовать Xlib
    +1
    Вот я тоже когда читал Ваш комментарий все думал про DirectFB (у нас просто Opera крутится именно в такой модификации внутри embedded-устройства). Почему уж сразу не оставить только DFB версию? И, даже если предположить что иксы можно почти везде, с чего это их везде нужно?
    По поводу же самой новости — весь в недоумении. Выигрыш вижу только в уменьшении размера (приотказе от статически прилинкованного фреймворка), что на современном десктопе довод весьма сомнительный по-моему.
    А вот чего они рискуют огрести — так это дополнительных багов при интеграции. Чисто для примера: на двухмониторной конфигурации combo-box'ы иногда выпадали не на том дисплее. Пользуешься большим фреймворком — авось за тебя пофиксят, но никто не мешает и самим патч предложить. А так все придется самим лечить (а ведь таких мелочей насобирать немало можно).
  • Управляем Rhythmbox'ом по ssh
    +7
    Я дико извиняюсь, но вся эта пляска со скринами — ради того чтобы не назначать номер дисплея в окружении?
    DISPLAY=:0 rhythmbox-client --next
  • doubleTwist или как троллить Стива Джобса
    0
    P.S. Имелся в виду Амарок который под 4-е кеды
  • doubleTwist или как троллить Стива Джобса
    0
    Ну когда я последний раз запускал Амарок (также третьей версии), тот умел синхронизировать многие айподы, но не Тач, и не айФон. А кроме них в хозяйстве уже ничего и не осталось. Еще под гномом был достаточно приятно-аскетичный плеер (он еще кажется умел подкасты синхронизировать) — та же фигня. Поскольку обе программы были мэйн-стримными — сделал вывод, что под линуксом с айФонами все плохо. Так 4-я версия Амарока все меняет? А то я присоединяюсь к оригинатору гневного вопроса :)
  • как способ изучения Английского
    +1
    Ссылка на сам поток
  • как способ изучения Английского
    +1
    Большое спасибо, один забрал в коллекцию
  • iPhone — Курсы ЦБ РФ
    0
    Вы меня похоже не понимаете, попробую с другой стороны. Если никогда не нужна ежемесячная группа (т.е. не отмеченно ни одной валюты и этой группы) — не тяните ее вообще. Если вопрос в том, что статистика меняется раз в месяц, а тянется каждый раз — запоминайте время операции и не тяните по напрасну. Пользователю безинтересны эти группы как таковые, их получение информации о конкретной валюте интересует. Не заставляйте их париться о выключении группы, которой они никогда не пользуются, и уж тем более париться о том, чтобы вовремя включить получение ежемесячной статистики. Вот приблизительно так бы я рассуждал на месте девелопера, хотя не исключаю, что не понимаю технических особенностей конкретно данной аппликухи.
  • iPhone — Курсы ЦБ РФ
    0
    как ИП не пробовали регистрироваться?
  • iPhone — Курсы ЦБ РФ
    0
    я все понимаю о чем Вы написали. есть две группы, некоторых интересуют объекты из второй группы, дать мозможность отключать ненужные объекты — экономить траффик. мой вопрос был скорее об интересности самой группы для пользователя. хорошо представляю, о чем должен думать пользователь, чтобы захотеть шекелей, но совершенно не представляю о чем он должен думать чтобы захотеть «отключить доставку ежемесячных валют», например.
  • iPhone — Курсы ЦБ РФ
    0
    Выглядит неплохо. Пара вопросов по настройкам:
    — возможность отображать только ежемесячные курсы валют, только ежедневные или и те и другие;

    Правда ли существует, например, такой юз-кейс: «Хочу только ежемесячные курсы»? Просто я себе с трудом представляю, зачем может понадобиться дифференциация именно по этому признаку.
    возможность отображать разницу с предыдущим курсом валют в процентах, просто предыдущее значение курса или разница в рублях.

    Наверное дело вкуса, но я бы оставил только разницу (абсолютную и в процентах), причем с мозможностью выбора 2-х опция одновременно (т.е. скорее два чек-бокса, нежели один 3-позиционный радио-баттон). В смысле, правда есть юз-кейс: «Хочу видеть не разницу, а именно предыдущее значение»?
  • Katahdin: метапрограммирование на грани фантастики
    +3
    недавно вот на Жуйке поднимался вопрос о выборе текстового редактора для кодера. одним из важных критериев было «чтобы расширялся на таком-то языке».
    ну вот наверное неплохая область для применения: встраиваемый язык для написания плагинов (возможно не требующих высокой производительности).
    если бы расширения к TextMate'у например писались по заводу не на Ruby, а на Katahdin, то всяким прочим питонистам и пхп-шникам жилось бы проще: доставляешь модуль своего любимого языка и пишешь расширение удобное именно тебе, на хорошо известном тебе скриптовом языке.
  • Работаем с фреймворком iPhone SDK MapKit
    +1
    Спасибо, все очень подробно рассписано; рецепту — путь в избранное. :)
    Наверное только можно было бы еще тайтл и сабтайтл заменить на что-нибудь разумное (видимо между
    addAnnotation = [[AddressAnnotation alloc] initWithCoordinate:location];

    и
    [mapView addAnnotation:addAnnotation];

    можно устанавливать свойтва аннотации)
  • MVC на iPhone: «The Model» (Часть 1)
    +3
    Весьма любопытно, спасибо. У самого опыт работы с фреймворком не слишком большой, заметил несколько моментов для обсуждения, и буду рад комментариям.
    На сколько я помню, при выбранном подходе NSNotification было бы использовать удобнее в случае нескольких получателей уведомления об изменении состояния модели.
    Общеприянтой практикой, как я понял, является объявление подобных Model сущностей в Application Delegate, с дальнейшим осуществлением доступа через sharedApplication. Т.е. одного синглтона (предоставляемого приложением) казалось бы достаточно, и вводить новые — избыточно.
    Такое ощущение, что доставка подобного рода уведомлений обычно осуществляется несколько по-другому: к сеттеру совйства прикручивается вызов метода, описываемого в протоколе соответствующего делегата. Все заинтересованные в уведомлениях сущности (обычно контроллеры) после получения доступа к разделяемой сущности (свойства sharedApplication) добавляют себя в список делегатов (тоже ничего писать не нужно, какой-то стандартный метод типа addDelegate есть). Реализуя необходимое подмножество протокольных методов получаем необходимые нотификации. В качестве бонуса: общая логика связанная с уведомлениями может быть релизована на стороне источника, а в методы делегата передается уже результат. Такой механизм представляется более очевидным, чем KVO или использование NSNotification.
  • Полноценный доступ ко всем Linux-файловым системам в Windows 2000/XP/Vista/7 с помощью coLinux
    +1
    Интересно, но если использовать coLinux только для доступа к ФС (и тем более запускать его как сервис), то по-моему лучше использовать не предпочитаемый дистрибутив, но почти голое ядро, причем еще и облегченное по-максимуму (оставить сеть + драйвера ФС). Также можно попробовать обойтись без самбы вовсе, а из винды доступаться к дискам через ssh (NetDrive'ом например), возможно еще и скорость вырастет.
  • icq2twitter.ru — ICQ-шлюз для Твиттера
    +6
    Тем, кому идея управлять микро-блогами при помощи мессенджера кажется привлекательной, но по каким-либо причинам еще не добравшимся до жуйка — рекомендую juick.com.
    Там изначально так задумано, что никаких шлюзов не нужно, и авторизация осуществляется путем добавления бота в контакт-лист. Правда сервиса по «сжатию/разжатию ссылок» там никогда не будет :)
    Преимущества джаббера перед ICQ на хабре уже расписаны сто раз, главные примущества жуйка перед тви: отсутствие ограничений на размер поста, разделение сообщений на посты и комментарии к ним (и прочие мелкие плюшки, типа интеграции медиа- и геолокационных данных)
    P.S. Для людей жестко привязанных к твиттеру предлженный сервис будет, безусловно, полезен. Спасибо за труды :)