Pull to refresh
55
0
liaren @liaren

User

Send message
Не совсем так. JS при первой загрузке, после установки куки с правильной timezone сразу перезагружает страницу, см. github.com/barbushin/dater/blob/master/src/Dater/TimezoneDetector.php#L50
Фрилансер и так весь за компьютером проводит, куда ему ещё отдыхать за компом? На улицу, в спорт зал, к друзьям в гости общаться!
Последняя версия InoReader внешне почти один в один как Google Reader, даже лучше. По функционалу тоже ничем не уступает. Поддерживает импорт гуглового OPML файла подписок.
Прекрасная идея, безупречная реализация! Форкнул вас на GitHub, вдруг смогу быть чем-то полезен. Запостил пару тикетов: #3, #4.
Спасибо вам!
Так ведь «отсутствие схемы и неудобный язык запросов» решаются использованием ORM, которая может контролировать соблюдение схемы и вводить свой оригинальный язык построения запросов. Не?
Только на начальной стадии.

На этот счёт в 2010 на хабре была хорошая статья Программизм: история одной болезни. Т.е. на самом деле перфекционизмом страдают те, кто таки не эволюционировали в то, что в статье описывается как «Стадия третья. Просветление». Профессионал — это тот, кто делает свою работу быстро и качественно. Всех остальных можно причислять в лучшем случае к «опытным специалистам».
На мой взгляд, чем программист более опытен — тем больше у него в запасе качественных и проверенных решений, тем он продуктивней. Стремление довести код до совершенство — это не признак профессионализма, а первый синдром такого понятия как…

Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
Не совсем понятно на какой сегмент пользователей ориентировалась Motorola выпуская такой телефон. На бедных школьников, которые часто пишут смски?
Полностью с вами согласен. Сам много лет работал на фрилансе и понял, что бесконечно так продолжаться не может. Держать себя в тонусе работая дома можно только ведя очень активный образ жизни, но на это порой не хватает ни времени, ни возможности. Общение с людьми близкими по духу многого стоит.
Человек — существо социальное.
Ему запрещено Интернетом пользоваться. Так он и не пользуется. От руки пишет статьи, а жена перепечатывает. Это как бы немного разные вещи. Даже в колониях строгого режима людям разрешено письма писать вне зависимости от того, что потом с этими письмами кто делает. Так почему человек под домашним арестом не может жене письма писать?
А ещё есть PHP библиотека github.com/barbushin/speed-out достаточно гибкая и расширяемая.
ИМХО 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 деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.
Разливаем через deb пакеты
Поубивал бы…
Да что вы говорите? Я multi_curl в классы оборачивал github.com/barbushin/multirequest И где тут АД? А про Guzzle слышали?

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity