Последняя версия InoReader внешне почти один в один как Google Reader, даже лучше. По функционалу тоже ничем не уступает. Поддерживает импорт гуглового OPML файла подписок.
Так ведь «отсутствие схемы и неудобный язык запросов» решаются использованием ORM, которая может контролировать соблюдение схемы и вводить свой оригинальный язык построения запросов. Не?
На этот счёт в 2010 на хабре была хорошая статья Программизм: история одной болезни. Т.е. на самом деле перфекционизмом страдают те, кто таки не эволюционировали в то, что в статье описывается как «Стадия третья. Просветление». Профессионал — это тот, кто делает свою работу быстро и качественно. Всех остальных можно причислять в лучшем случае к «опытным специалистам».
На мой взгляд, чем программист более опытен — тем больше у него в запасе качественных и проверенных решений, тем он продуктивней. Стремление довести код до совершенство — это не признак профессионализма, а первый синдром такого понятия как…
Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
Полностью с вами согласен. Сам много лет работал на фрилансе и понял, что бесконечно так продолжаться не может. Держать себя в тонусе работая дома можно только ведя очень активный образ жизни, но на это порой не хватает ни времени, ни возможности. Общение с людьми близкими по духу многого стоит.
Ему запрещено Интернетом пользоваться. Так он и не пользуется. От руки пишет статьи, а жена перепечатывает. Это как бы немного разные вещи. Даже в колониях строгого режима людям разрешено письма писать вне зависимости от того, что потом с этими письмами кто делает. Так почему человек под домашним арестом не может жене письма писать?
ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.
Я видел сценарии build & delivery реализованные на Ant и на Maven в десятки тысяч строк(XML), разбитые на десятки под-файлов с несколькими десятками под-сценариев, с достаточно сложной, но легко читаемой логикой зависимостей между ними. И вот представить всю эту красоту описанной на deb + bash… извините, но лично мне не хватает фантазии.
Понятно, что опытные админы могут легко читать bash скрипты любых размеров и сложности. Но, опять таки, как я уже писал выше, я за то, чтобы сценарии сборки и выкладки проектов писались программистами, а не админами. Как-то раз столкнулся с ситуацией, когда после увольнение админа команда ещё неделю с ума сходила, чтобы в его deb + bash скриптах разобраться. Хотя сценарий выкладки там был не такой уж сложный. С тех пор я эти решения на дух не переношу.
А в плане хитрого delivery, всё о чём вы говорите вполне реализуемо на Ant/Maven, весь необходимый функционал для этого там есть. Был бы только мозг способный этим функционалом правильно воспользоваться.
Нет, веб-проекты — это не серверное ПО. Ничего не имею против того, чтобы админы использовали deb/rpm пакеты для обновления серверного ПО т.к. там не такие сложные сценарии, и т.к. программистам в принципе лучше не соваться в эти сценарии.
Сценарий сборки и выкладки веб-проектов не так просты как сценарии обновления серверного ПО т.к. они во много зависят от архитектуры проекта(которую админ может не понимать до конца), от бизнес-логики некоторых компонентов(о которой админ может не знать) и т.д. и т.п. Ни один админ не будет знать логику функционирования веб-проекта лучше чем программист, который его реализовал. Поэтому, моё мнение, что сценарий сборки и выкладки должны описывать программисты, а не админы. Поэтому, я считаю, что сценарии сборки и выкладки должны описываться не на deb/rpm пакетах, а на легко читаемых и кроссплатформенных инструментах деплоя типа Ant/Phing/Maven и т.п.
А почему вы считаете, что Ant/Phing/Maven и т.п. инструменты в плане delivery хуже систем обновления пакетами deb/rpm/..? Сценарии описываемые на XML в том же Ant Script прекрасно читаемы всеми программистами и более того могут быть более безопасно подправлены. И более того, при грамотном написании эти сценарии являются платформонезависимыми позволяя отлаживать и тестировать их на локальных машинах разработчиков.
ИМХО deb подходит для обновления и конфигурации серверного ПО — всего того, что попаает в зону ответственности админов. А всё что касается архитектуры веб-проектов, тонкости функционирования различных компонентов — зона ответственности программистов, и только они должны принимать решения о сценарии сборки и выкладки.
И что касается разделения использования Ant/Phing/Maven для сборки и dev/rpm для выкладки — зачем это разделять, если Ant/Phing/Maven прекрасно справляются и с первым, и с последним?
Проблема в том, что алгоритм выкладки читаем лишь админами, которые его прописывали. Изначально deb и т.п. *nix пакетные системы деплоя преднозначен для обновления серверного ПО, а не для delivery и тем более build веб проектов.
Есть множество инструментов изначально предназначенных для сборки и delivery веб-проектов. Будь то Ant, или Phing на нём построенные или хоть даже Maven. Не суть важно. Они предоставляют более прозрачный интерфейс для сборки и выкладки веб-проектов чем deb/rpm/wtf… обновляторы заточенные тупо на обновление серверного ПО.
Из более двух десятков известных мне веб-проектов лишь несколько использовали deb/rpm деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.
Спасибо вам!
На этот счёт в 2010 на хабре была хорошая статья Программизм: история одной болезни. Т.е. на самом деле перфекционизмом страдают те, кто таки не эволюционировали в то, что в статье описывается как «Стадия третья. Просветление». Профессионал — это тот, кто делает свою работу быстро и качественно. Всех остальных можно причислять в лучшем случае к «опытным специалистам».
Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
Я видел сценарии build & delivery реализованные на Ant и на Maven в десятки тысяч строк(XML), разбитые на десятки под-файлов с несколькими десятками под-сценариев, с достаточно сложной, но легко читаемой логикой зависимостей между ними. И вот представить всю эту красоту описанной на deb + bash… извините, но лично мне не хватает фантазии.
Понятно, что опытные админы могут легко читать bash скрипты любых размеров и сложности. Но, опять таки, как я уже писал выше, я за то, чтобы сценарии сборки и выкладки проектов писались программистами, а не админами. Как-то раз столкнулся с ситуацией, когда после увольнение админа команда ещё неделю с ума сходила, чтобы в его deb + bash скриптах разобраться. Хотя сценарий выкладки там был не такой уж сложный. С тех пор я эти решения на дух не переношу.
А в плане хитрого delivery, всё о чём вы говорите вполне реализуемо на Ant/Maven, весь необходимый функционал для этого там есть. Был бы только мозг способный этим функционалом правильно воспользоваться.
Сценарий сборки и выкладки веб-проектов не так просты как сценарии обновления серверного ПО т.к. они во много зависят от архитектуры проекта(которую админ может не понимать до конца), от бизнес-логики некоторых компонентов(о которой админ может не знать) и т.д. и т.п. Ни один админ не будет знать логику функционирования веб-проекта лучше чем программист, который его реализовал. Поэтому, моё мнение, что сценарий сборки и выкладки должны описывать программисты, а не админы. Поэтому, я считаю, что сценарии сборки и выкладки должны описываться не на deb/rpm пакетах, а на легко читаемых и кроссплатформенных инструментах деплоя типа Ant/Phing/Maven и т.п.
ИМХО deb подходит для обновления и конфигурации серверного ПО — всего того, что попаает в зону ответственности админов. А всё что касается архитектуры веб-проектов, тонкости функционирования различных компонентов — зона ответственности программистов, и только они должны принимать решения о сценарии сборки и выкладки.
И что касается разделения использования Ant/Phing/Maven для сборки и dev/rpm для выкладки — зачем это разделять, если Ant/Phing/Maven прекрасно справляются и с первым, и с последним?
Есть множество инструментов изначально предназначенных для сборки и delivery веб-проектов. Будь то Ant, или Phing на нём построенные или хоть даже Maven. Не суть важно. Они предоставляют более прозрачный интерфейс для сборки и выкладки веб-проектов чем deb/rpm/wtf… обновляторы заточенные тупо на обновление серверного ПО.
Из более двух десятков известных мне веб-проектов лишь несколько использовали deb/rpm деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.