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

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

Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
liaren
–6
Не совсем понятно на какой сегмент пользователей ориентировалась Motorola выпуская такой телефон. На бедных школьников, которые часто пишут смски?
liaren
0
Полностью с вами согласен. Сам много лет работал на фрилансе и понял, что бесконечно так продолжаться не может. Держать себя в тонусе работая дома можно только ведя очень активный образ жизни, но на это порой не хватает ни времени, ни возможности. Общение с людьми близкими по духу многого стоит.
liaren
–2
Человек — существо социальное.
liaren
+37
Ему запрещено Интернетом пользоваться. Так он и не пользуется. От руки пишет статьи, а жена перепечатывает. Это как бы немного разные вещи. Даже в колониях строгого режима людям разрешено письма писать вне зависимости от того, что потом с этими письмами кто делает. Так почему человек под домашним арестом не может жене письма писать?
liaren
0
А ещё есть PHP библиотека github.com/barbushin/speed-out достаточно гибкая и расширяемая.
liaren
0
ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.

Я видел сценарии build & delivery реализованные на Ant и на Maven в десятки тысяч строк(XML), разбитые на десятки под-файлов с несколькими десятками под-сценариев, с достаточно сложной, но легко читаемой логикой зависимостей между ними. И вот представить всю эту красоту описанной на deb + bash… извините, но лично мне не хватает фантазии.

Понятно, что опытные админы могут легко читать bash скрипты любых размеров и сложности. Но, опять таки, как я уже писал выше, я за то, чтобы сценарии сборки и выкладки проектов писались программистами, а не админами. Как-то раз столкнулся с ситуацией, когда после увольнение админа команда ещё неделю с ума сходила, чтобы в его deb + bash скриптах разобраться. Хотя сценарий выкладки там был не такой уж сложный. С тех пор я эти решения на дух не переношу.

А в плане хитрого delivery, всё о чём вы говорите вполне реализуемо на Ant/Maven, весь необходимый функционал для этого там есть. Был бы только мозг способный этим функционалом правильно воспользоваться.
liaren
+1
Нет, веб-проекты — это не серверное ПО. Ничего не имею против того, чтобы админы использовали deb/rpm пакеты для обновления серверного ПО т.к. там не такие сложные сценарии, и т.к. программистам в принципе лучше не соваться в эти сценарии.

Сценарий сборки и выкладки веб-проектов не так просты как сценарии обновления серверного ПО т.к. они во много зависят от архитектуры проекта(которую админ может не понимать до конца), от бизнес-логики некоторых компонентов(о которой админ может не знать) и т.д. и т.п. Ни один админ не будет знать логику функционирования веб-проекта лучше чем программист, который его реализовал. Поэтому, моё мнение, что сценарий сборки и выкладки должны описывать программисты, а не админы. Поэтому, я считаю, что сценарии сборки и выкладки должны описываться не на deb/rpm пакетах, а на легко читаемых и кроссплатформенных инструментах деплоя типа Ant/Phing/Maven и т.п.
liaren
0
А почему вы считаете, что Ant/Phing/Maven и т.п. инструменты в плане delivery хуже систем обновления пакетами deb/rpm/..? Сценарии описываемые на XML в том же Ant Script прекрасно читаемы всеми программистами и более того могут быть более безопасно подправлены. И более того, при грамотном написании эти сценарии являются платформонезависимыми позволяя отлаживать и тестировать их на локальных машинах разработчиков.

ИМХО deb подходит для обновления и конфигурации серверного ПО — всего того, что попаает в зону ответственности админов. А всё что касается архитектуры веб-проектов, тонкости функционирования различных компонентов — зона ответственности программистов, и только они должны принимать решения о сценарии сборки и выкладки.

И что касается разделения использования Ant/Phing/Maven для сборки и dev/rpm для выкладки — зачем это разделять, если Ant/Phing/Maven прекрасно справляются и с первым, и с последним?
liaren
0
Проблема в том, что алгоритм выкладки читаем лишь админами, которые его прописывали. Изначально deb и т.п. *nix пакетные системы деплоя преднозначен для обновления серверного ПО, а не для delivery и тем более build веб проектов.

Есть множество инструментов изначально предназначенных для сборки и delivery веб-проектов. Будь то Ant, или Phing на нём построенные или хоть даже Maven. Не суть важно. Они предоставляют более прозрачный интерфейс для сборки и выкладки веб-проектов чем deb/rpm/wtf… обновляторы заточенные тупо на обновление серверного ПО.

Из более двух десятков известных мне веб-проектов лишь несколько использовали deb/rpm деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.
liaren
–2
Разливаем через deb пакеты
Поубивал бы…
liaren
0
Да что вы говорите? Я multi_curl в классы оборачивал github.com/barbushin/multirequest И где тут АД? А про Guzzle слышали?
liaren
0
А где вы видели теннисистов с ассиметрично развитой мускулатурой? :)
liaren
0
317 грамм — это вес профессиональной ракетки. Мне кажется любители такой или локоть себе травмируют или просто технику изуродуют. Для женщин в принципе не подходит.
liaren
+1
95 самый ходовой? Большой разницы между 95 и 100 нет? От куда такая информация? Вы профессионально теннисом занимаетесь? Я не профи, любитель, но и то разницу между 98 и 100 очень сильно чувствую. 95 это уже для профи, у кого техника грамотно поставлена т.к. там ударное пятно маленькое, нужна высокая точность и концентрация. И не совсем понятен смысл того, чтобы тренировочная и турнирная ракетки так сильно отличались. Под каждую ракетку привыкание постепенно приходит и вот так перестраиваться каждый раз ни к чему хорошему не приведёт. Чувство мяча потеряете просто.
liaren
+1
Ах да, я ещё забыл про такой параметр как «толщина ручки»!

Итого. Т.к. про настройку веса ничего не сказано, то при таком большом диапазоне параметров «самый ходовой размер + вес + баланс + размер ручки»(к примеру 100"/300гр/центр/3) будет актуален менее чем для 10% игроков. И вот эти 10% будут представлены группой взрослых теннисистов любителей. И кто сказал, что их выбор о покупке этого «гаджета» совпадёт c выбором прочих групп(начинающие/профи/дети)?

Мне кажется намного правильнее было бы сделать универсальную систему датчикав закрепляемую на любой ракетке с криплением блутус модуля и батарейки в пустом триугольном основании ракетки. Тогда и стоимость гаджета могла бы быть в 5-10 раз меньше, и спрос на порядок больше. Но ведь Babolat в первую очередь хочет не повышать качество техники теннисистов во всём Мире, а тупо увеличить свою долю в продаже ракеток среди других брэндов. Мать его маркетинг…
liaren
+2
Сама ракетка, несмотря на сложное строение и обилие дополнительных деталей, весит ровно столько же, сколько и обычные ракетки
Смешно читать такое. У современных ракеток есть 3 основных параметра: вес(200-350гр), баланс(в ручку/центр/головку) и площадь головки(90-110кв.дюймов). У каждого теннисиста есть своя комфортная для него конфигурация, даже у любителей. Не существует такого понятия как «обычная ракетка».

Ну ладно с весом и балансом они могут что-то придумать за счёт системы вкручиваемых грузиков, но размер головки как подгонять? Он правда очень отличается у разных игроков и очень важную роль играет.
liaren
0
Под «у каждого расширения должно быть одно и только одно понятное предназначение» можно понимать всё что угодно. И какая вообще связь между «единственностью предназначения» и «лаконичностью интерфейса» расширений? У идеологов-юристов Google не хватило мозгов, чтобы более чётко сформулировать каким критериям должно соответствовать расширение чтобы не слишком загромождать интерфейс браузера?

Да это всё равно, что на государственном уровне утвердить для всех граждан страны диету с раздельным питанием.

Тупо как-то.
liaren
+1
А ответ на ваш вопро,- потому что любой фрейиворк силбно зависит от ОРМ
Никогда прежде не слышал ничего подобного в отношении фреймворков, только в отношении CMS или CMF. Мне кажется в идеале фреймворк должен предоставлять интерфейсы абстрагирования взаимодействия модулей с ORM таким образом, чтобы к нему можно было прикрутить любую ORM просто реализовав необходимые интерфейсы-адаптеры.
liaren
0
Не вижу ничего плохого в изобретении новых ORM. Не понимаю только зачем их разрабатывать с привязкой к конкретному фреймворку?
liaren
+3
Кто-нибудь, объясните пожалуйста дураку, почему разработчики фреймворков так любят изобретать собственные ORM с привязкой к их фреймворкам? Почему нельзя реализовать ORM как standalone пакет, как Doctrine например?
liaren
0
В данный момент общаюсь с разработчиком этого модуля, по его словам в последней версии всё исправлено. Обновите код модуля и код php-console библиотеки.
liaren
0
1. Код не обфусцирован, а сжат при помощи Google Closure с опцией Advanced Optimization.
2. Сжатие кода в данном случае очень даже влияет на скорость его работы и на размер потребляемой оперативки.
3. Т.к. код не обфусцирован, то при большом желании вы можете его проанализировать на предмет скрытой отправки данных.
4. Анализировать код расширения на безопасность бессмысленно т.к. разработчик может просто на 1 день выпустить обновление с «вредоносным кодом», и на следующий день закрыть его новым «безопасным» обновлением.
5. При загрузке расширения на WebStore его код пропукается через гугловый анализатор, который отслеживает всякого рода вредности и при необходимости блокирует расширение.
6. Предыдущие версии расширения у вас на жёстком диске хранит сам Chrome, и в память загружается только последняя версия(ту что я последней загрузил на WebStore).
7. Ну и в конце концов, в расширении стоит ссылка на мой профиль на LinkedIn. Если бы я планировал делать что-то нехорошее с пользовательскими данными, как вы думаете, стал бы я так светиться? :)

Но так или иначе, спасибо за вопрос! :)
liaren
+3
Жаль нет данных по UnixBench и прочим бенчмаркам, как на ServerBear.
liaren
0
И это всё :) Но только Lagger уже не совместим с новой PHP Console. Можете просто использовать их параллельно, конфликтовать они не будут.
liaren
+2
Это обзорная статья посвещённая одному конкретному продукту, а не вопросу: Как лучше дебажиться в PHP. Вы с тем же успехом можете обзор любого другого приложения или устройства на хабре критикаовать мол «А что вы с другими продуктами не сравниваете? А что вы мне тут про функционал новой версии PostgreSQL рассказываете без сравнения с MySQL? А зачем мне переходить на вашу PostgreSQL, если MySQL полностью удовлетворяет моим потребностям?» :)

Если бы я начал проводить расширенное сравнение, давать свою оценку чужим продуктам и способам их использования, то это могло бы привести к очередному бессмысленному холивару. А так каждый сам принимает своё решение.
liaren
0
Если вас интересует именно старая версия, то вот тут описано как её установить groups.google.com/forum/?hl=ru#!forum/php-console-deprecated-version

Новая версия chrome.google.com/webstore/detail/php-console/nfhmhhlpfleoednkpnnnkolmclajemef
liaren
0
OnYourLips предлагает вставлять обработчик, который будет пробрасывать 500-ю, и если при выполнении на сайте действия при котором отправляется ajax запрос происходит что-то странное, то лезть в консоль Network, искать там запрос с 500-ой, и если найдёте, то смотреть дамп ошибки в Response запроса.

Всё ведь просто :)
liaren
0
Пробовал с двух компьютеров(Win 7 & Ubuntu) — везде всё работает. Можно вас попросить проверить, есть ли какие-то ошибки в js консоли расширения? Как открыть консоль расширеня описано тут github.com/barbushin/php-console/wiki/How-to-report-bug-or-feature#attach-google-chrome-extension-javascript-errors

Спасибо
liaren
0
Ну просто кроме вас двоих меня пока никто не спрашивал где и как можно этим расширением пользоваться :) Если бы спрашивало чуть больше людей, то обязательно описал бы. Сейчас у меня на это просто времени нет, люди пишут про мелкие баги в Ubuntu, приходится со всеми сейчас диалог вести.

Самый просто пример использования: включаете обработчик ошибок, включаете логирование всех SQL запросов, в случае ошибки наблюдаете что где упало и при каких запросах.

Если у вас в команде есть тестеры, то тоже может быть полезно: включаете обработчик ошибок и отображение Copy to clipboard button. Тестеры проходят сценарии по сайту, всплывает попап с ошибкой, кликают на Copy to clipboard, заводят тикет с описанием действий при которых произошла ошибка и прикрепляют дамп ошибки с трейсом и т.п.
liaren
0
Ребята, вы оба правы. Xdebug + PhpStorm/NetBeans — действительно много лучше и удобней, чем какое-то там расширение в Хроме. Надеюсь кто-нибудь из вас напишет статью для широкой публики с описанием всех фич, которые даёт эта связка. После этого сможем по существу поговорить в каких именно фичах и в каких случаях то или иное решение является лучшим выбором.

Не обижайтесь только, но пока вы задаёте больше абстрактно-обобщённых вопросов, чем приводите конкретные случаи использования конкретного функционала.
liaren
0
Я могу ответить на 100 ваших вопросах т.к. очень хорошо разбираюсь в том как работают удалённые отладчики в том же PhpStorm, и зачем была написана PHP Console и в каких целях используется. Вы можете тезисно изложить свою позицию?

Например: я считаю, что бессмысленно использовать PHP Console, когда есть xdebug+PhpStorm.