жители евросоюза имели право запросить историю всех своих твитов и раньше. Видимо теперь twitter это решил сделать доступным для всех. Формат наверное будет таким же как и раньше. Вот уже есть скрипт на ruby для парсинга и складывания в mongoDB gist.github.com/3089893 Думаю, что пригодится ;)
механизм миграций несколько смущает… в статье упоминается, что идёт проверка не добавились ли новые сущности или свойства. А как насчет переименовывания, изменения типа, удаления?
Если ты работал с rails, то имеешь представление о механизме миграций там. Наверное и тут было бы удобно иметь что-то подобное. Схему базы можно например хранить в plist. При запуске приложения смотришь есть ли файлик с базой, если нету, то создаёшь базу из plist. Если файлик базы есть, то смотришь какая версия, а затем применяешь миграции от текущей версии до последней если таковые имеются. При примерно таком раскладе мне кажется будет более гибкий механизм. В точ числе можно будет добавлять индексы на поля, чем сейчас сделать как я понял нельзя. Ну и прочие фишки)
Механизм с пропертями, которые автоматически являются и полями в базе мне не очень нравится. А ещё в добавок и надо указывать какая проперти не лежит в базе. Не удобно это и лишний раз люди могут допускать ошибки. Может аналогично как в CoreData стоит сделать? Т.е. да, для того, чтобы они были видны и всё такое придётся в h файле объявлять эти проперти. Но синтесайзить их где-нибудь в твоих классах на основе той же схемы. А в m файле люди будут для них писать @dynamic. Плюс это позволит ещё сделать удобную фичу, которой лично мне в core data не очень хватает: работа с обычными типами данных, особенно BOOL часто бывает нужен. Ну оборачивать BOOL в NSNumber ну совсем не прикольно. Иногда специально дополнительный геттер и сеттер, чтобы работать с ним как с BOOL, а не NSNumber. Так вот если синтесайз пропертей будет проиходить где-то в твоих классах либы, то наверное и получится как раз дать пользователю работать с обычными BOOL если надо! Имхо было бы удобненько)
да, автор добавьте плиз в пост ещё и CocoaPods!!! Must have! Значительно ускоряет процесс втягиваниая, обновления и управления зависимостями либ! Хватит ручками кучей разных способов втягивать либы! =)
плюс в app store тоже есть целый ряд гугловых приложений. Среди них: gmail, blogger, google+, google переводчик, google authenticator и тд и тп) Так что им есть для кого писать objective-c guidelines))
ну вы при таком подходе на каждом проекте по новой пишите одно и то же, а я делаю много сайтов и я заинтересован в оптимизации своей работы и ускорении. и поэтому я не хочу каждый раз одно и то же писать.
Время — деньги! ;)
можно, но это в друпале не очень быстро.
Дело в том, что крайней не рекомендуется переписывать что-то прямо в коде самого друпаля или готовых модулей. Надо специфические для данного ресурса правки делать в отдельном модуле или теме. Т.е. если нам надо изменить класс, которым присваивается диву, внутрпи которого лежит пэйджер, то мы не открываем и правим готовую функцию, а скорее сперва её находим и потом в своей теме или модуле её переопределяем на нужный нам вывод. Т.е. скорее всего копируем функцию к себе изменяя её название и затем уже правим в ней то, что надо. И каждый элемент переопределять у себя не очень удобно. Тем более если это приходится делать не на одном проекте, а на многих и регулярно. Тогда полюбому начинаешь задумываться о том, чтобы этот процесс оптимизировать.
Я вобще удивлён почему тут такого рода оптимизация воспринимается в штыки и утверждается, что друпаль лажовый в этом плане. При разработке на других системах ведь тоже будет время разработки уменьшено если не надо будет каждый элемент переопределять…
вы не объективно оцениваете время выполнения работы. бьюсь об заклад, что вы не сверстаете ни один из этих сайтов за 4 часа. В лучшем случае вы за день сверстаете asatex. Если у вас конечно лни не по 16 часов))
А верстальщика в офисе мы не держим. Фрилансеры верстают.
ну вот когда делаешь один за одним постоянно сайты, то волей-неволей начинаешь задумываться о том, что каждый раз для каждого проекта переписывать свои функции темизации не прикольно. Вот и рождаются такие требования.
ну и кстати тут требования никак не в духе гарланда, а от стандартных выводов. гарланд в себе только пару функций тем переопределяет и то мелких. Я писал по системным выводам.
я в 95% случаев переопределяю свои views-view.tpl.php, views-view-unformatted.tpl.php, views-view-fields.tpl.php для каждого view. При этом для порядка я раскидываю их по папкам внутри темы (благо views сканят все папки в теме и поэтому раскладывать шаблоны можно в любой удобной структуре).
И в них я вобще мало что родного оставляю. Тут вобщем я оставляю свободу верстальщику, а сам потом очень быстро это прикручиваю.
ну ето не совсем чтобы требования… Возможно я не очень точно подобрал заголовок. Это скорее пожелания. Никаких проблем, чтобы верстальщик сделал как ему удобнее, а программист потом переколбасит вывод всех элементов. Это вполне можно сделать. Но зачем? Мы на друпале делаем в основном мелкие проекты, например промо-сайты, где время ограничено и надо максимально быстро всё сделать. Вот и ищутся способы по оптимизации рабочего процесса. Выставление кое-каких требований к верстальщику заметно ускоряет этот процесс, а значит это выгодно.
Время — деньги!
ну сегодня мелкий баг вылез, я его поправил. завтра тоже и я тоже поправил, а потом вылазит мега большой баг и отправляется на доработку верстальщику. и тогда стоит вопрос: либо выбирать свои изменения из кода и отдавать ему или же он сам всё делает и потом применять снова свои исправления. И тот и тот вариант не удобен. Каждый должен делать свою работу.
ну я имел опыт вёрстки сразу в тему, но не сказал бы, что это удобно и приятно. Ну и плюс я не могу успевать делать всю работу. Процесс надо разбивать на несколько человек. И в принципе если верстальщик по такого рода требования что-то делает, то вполне быстро можно прикручивать.
Мне вполне удобно переписать стандартные шаблоны в соответствии с обычной присланной вёрсткой. И код в итоге получается красивым и аккуратным. примеры: asatex.by stereolife.by pix.by
Так ведь качественнее ;)
так мы это на работе для верстальщиков сразу как требование выставляем и никуда им от нас не деться)))
хотя править мне потом всё равно приходится конечно
smind, если будешь что-то доделывать в скриптах, то это будет где-нибудь выкладываться в общественных местах? например git hub…
Если да, то было бы здорово знать где =)
Если ты работал с rails, то имеешь представление о механизме миграций там. Наверное и тут было бы удобно иметь что-то подобное. Схему базы можно например хранить в plist. При запуске приложения смотришь есть ли файлик с базой, если нету, то создаёшь базу из plist. Если файлик базы есть, то смотришь какая версия, а затем применяешь миграции от текущей версии до последней если таковые имеются. При примерно таком раскладе мне кажется будет более гибкий механизм. В точ числе можно будет добавлять индексы на поля, чем сейчас сделать как я понял нельзя. Ну и прочие фишки)
Механизм с пропертями, которые автоматически являются и полями в базе мне не очень нравится. А ещё в добавок и надо указывать какая проперти не лежит в базе. Не удобно это и лишний раз люди могут допускать ошибки. Может аналогично как в CoreData стоит сделать? Т.е. да, для того, чтобы они были видны и всё такое придётся в h файле объявлять эти проперти. Но синтесайзить их где-нибудь в твоих классах на основе той же схемы. А в m файле люди будут для них писать
@dynamic. Плюс это позволит ещё сделать удобную фичу, которой лично мне в core data не очень хватает: работа с обычными типами данных, особенно BOOL часто бывает нужен. Ну оборачивать BOOL в NSNumber ну совсем не прикольно. Иногда специально дополнительный геттер и сеттер, чтобы работать с ним как с BOOL, а не NSNumber. Так вот если синтесайз пропертей будет проиходить где-то в твоих классах либы, то наверное и получится как раз дать пользователю работать с обычными BOOL если надо! Имхо было бы удобненько)Отдельное спасибо за поддержку CocoaPods ;)
Время — деньги! ;)
Дело в том, что крайней не рекомендуется переписывать что-то прямо в коде самого друпаля или готовых модулей. Надо специфические для данного ресурса правки делать в отдельном модуле или теме. Т.е. если нам надо изменить класс, которым присваивается диву, внутрпи которого лежит пэйджер, то мы не открываем и правим готовую функцию, а скорее сперва её находим и потом в своей теме или модуле её переопределяем на нужный нам вывод. Т.е. скорее всего копируем функцию к себе изменяя её название и затем уже правим в ней то, что надо. И каждый элемент переопределять у себя не очень удобно. Тем более если это приходится делать не на одном проекте, а на многих и регулярно. Тогда полюбому начинаешь задумываться о том, чтобы этот процесс оптимизировать.
Я вобще удивлён почему тут такого рода оптимизация воспринимается в штыки и утверждается, что друпаль лажовый в этом плане. При разработке на других системах ведь тоже будет время разработки уменьшено если не надо будет каждый элемент переопределять…
А верстальщика в офисе мы не держим. Фрилансеры верстают.
ну и кстати тут требования никак не в духе гарланда, а от стандартных выводов. гарланд в себе только пару функций тем переопределяет и то мелких. Я писал по системным выводам.
И в них я вобще мало что родного оставляю. Тут вобщем я оставляю свободу верстальщику, а сам потом очень быстро это прикручиваю.
Время — деньги!
Мне вполне удобно переписать стандартные шаблоны в соответствии с обычной присланной вёрсткой. И код в итоге получается красивым и аккуратным. примеры: asatex.by stereolife.by pix.by
Так ведь качественнее ;)
хотя править мне потом всё равно приходится конечно
Если да, то было бы здорово знать где =)
спасибо