Странно постоянно читать 2 вещи про Россию:
1. налоги выше;
2. чиновники душат малый бизнес проверками.
Это кем-то когда-то придуманный миф, который все повторяют, и даже не пытаются его верифицировать с реальностью…
По налогам — у нас предельно-низкие ставки для предпринимателей на упрощенной системе налогообложения. Этот вариант подходит большинству веб-предпринимателей. Согласитесь, что заплатить до 10% налогов от выручки (в Питере же реально 6%), если выручка — это твой доход, не сложно. Что тут большого? Если же ты вышел за лимиты упрощенки (т.е. доход уже больше $2 млн с небольшим в год), то плати по полной. Ну дак везде так же. Выходит, что большие налоги — это не правда.
На тему душат — может милиция, пожарники, сэс и т.п. и душат мелкую торговлю, хотя было у меня несколько торговых точек в конце 90-х, но и даже там особых проблем я не замечал. Для веб предпринимательства просто нет такой проблемы: его реально никто и не контролирует, разве что налоговая и ПФ будут следить за начисление налогов и отчислений в фонды. Ну так это хлопот доставляет минимум. Мой опыт говорит о простом: с 2005 года не было ни одной проверки! НИ ОДНОЙ!
Реальная же беда России в том, что никто не хочет вкалывать, все хотят номинально работать и много денег за это.
Зоопарк разных решений по автоматизации и геморрой с их интеграцией — вот единственный работающий подход.
Нельзя все-все автоматизировать с помощью одного решения. Нужно использовать то ПО, которое позволяет вести бизнес лучше, а не выкручивать себе руки.
У любой ERP есть свои сильные стороны, но точно есть и свои слабые. И ни одна ERP идеально не ляжет на конкретный бизнес.
Выходит, что вопрос у вас какой-то теоретический, поскольку вариант «автоматизировать все-все одним» не жизнеспособен.
Есть еще два вопроса:
1. Подскажите, распределяете ли вы копии данных между датацентрами? Было бы здорово, чтобы три копии оказывались в разных ДЦ.
2. Не смог найти по этой услуге SLA.
И одна ремарка — на сайте стоило выложить договор оферты, чтобы можно было четко понять все организационно-правовые нюансы.
Меня смутило: "… иногда после потери сетевого соединения с хранилищем… ". Насколько часто такое «иногда» случается?
Необходимость восстанавливать подключение хранилища к серверу после каких-либо падений вручную не вызываем оптимизма :-(.
Мир многолик, и не надо его упрощать. Мир говорит на разных языках, и потому документации тоже должны быть на разных языках. Посмотрите, сколько официальных языков у ООН или у Евросоюза!
Конечно, удобно вести документацию на одном языке — трудоемкость ниже, но за этим следует глобальный проигрыш, ведь язык — это способ думания, и с сокращением многообразия способов думания мир станет плоским :-(, исчезнут краски.
Так что я за перевод.
Я считаю, что после изучения основ работы с php стоит переходить на изучение одного из широко используемых фреймворков. Symfony для этого вполне подходит.
Уже сейчас можно использовать функционал лайков для демонстрации количества сторонников той или иной идеи. Зачем городить огород из каких-то специальных проверенных модерируемых сайтов?
От идиотских законадательных инициатив должно спасать количество сторонников размером в 100 тысяч. С трудом верится, что наберется столько желающих с помощью думы «пропатчить KDE2 под FreeBSD». А если столько наберется — то мы не достойны гражданского общества, и наш удел — тоталитаризм.
Непонятно, отчего столько шумихи вокруг codecademy.
Идея интерактивного обучения хороша, не спорю. Но все хорошее на этом и заканчивается.
Сами уроки — не системные, написаны разными авторами, перекрывают друг-друга, отчего быстро надоедает делать одно и то же. В общем очень не интересный курс у них получился. По другим языкам учебные пособия грозятся сделать — так если будут делать так же, как по JavaScript, то можно и не начинать — хорошо не получится.
Для изучения JavaScript учебник Илья Кантора learn.javascript.ru намного лучше: материал комплексный и гораздо шире, интерактивные задания тоже есть. При этом русский язык учебника — изначально!
Раз у вас нечипованная карта — то скорее всего это мастеркард. С ними есть проблемы в некоторых европейских странах (например Нидерланды, Бельгия, Люксембург), связанные с тем, что расчеты по магнитным картам считаются недостаточно безопасными, и банки не рекомендуют принимать такие карты к оплате. Это выливается в то, что в магазинах щели для магнитных карт просто заклеены. Если их расклеить — то платеж проходит, но на такую любезность идут не часто.
К сожалению, чипованные мастеркард в России редки. К сожалению — поскольку в Европе выгоднее рассчитываться именно мастеркардами, чем визами.
Спасибо!
Я все это тестировал на gearmand 0.14 + php 5.3.10 (c pecl gearman 0.8.0 + libgearman 0.14)
Если у вас GearmanJob::sendFail будет работать, черканите, на каких версиях ПО.
>А при таком синтаксисе ($res = $client->do('function');) эта возможность теряется
Я не понял, что тут теряется? Подсказка для метода do? Не должна она тут теряться.
Воркер в начале обработки задания выводит ее данные в консоль:
$ php worker.php
Function got: «Function data» and fail < — вот он вывод в консоль
Сколько раз воркер обрабатывал задание можно понять из количества выводов в консоль.
На каждое задание 1 вывод, несмотря на завершение GearmanJob::sendFail. Т.е. повторно задания не обрабатываются.
Чуть выше мы это обсуждали. Проблема в том, что несмотря на параметр --job-retries использование GearmanJob::sendFail не приводит к возвращению задания в очередь.
Смотрите (код для примера github.com/avorobiev/gearman):
1. запускаем сервер:
$ gearmand -job-retries=2
2. добавляем задание в очередь
$ php client.php
3. проверяем наличие задания в очереди
$ php monitor.php
| function | total | running | workers |
| fail | 1 | 0 | 0 |
4. подключаем воркера
$ php worker.php
Function got: «Function data» and fail
5. проверяем очередь
$ php monitor.php
| function | total | running | workers |
| fail | 0 | 0 | 1 |
ВЫВОД: GearmanJob::sendFail не возвращает задание в очередь. Или я что-то делаю не так?
Ну если клиент поставил задачу на выполнение в бакграунде, то кроме как из воркера, ее неоткуда повторно вернуть в очередь.
Если же ее выполнения ожидает клиент, то правильнее обрабатывать на клиенте результат выполнения и повторно ставить задачу, поскольку иначе получается уже каша:
— клиент ждет ответа от воркера;
— воркер не может выполнить, добавляет задачу в очередь;
— раз клиент ждет ответа, то тогда и воркер должен ждать ответа по новой задаче, чтобы вернуть его клиенту.
При такой схеме воркер выпадает из обоймы до выполнения задачи, и так можно всех воркеров перелинковать между собой и все повесить.
Почему нет смысла? Если настроить на хосте с воркерами туннель для локального порта 4730 на тот же локальный порт Gearman-сервера, то все заработает. И распределенность будет :-). Вдобавок соединение будет шифроваться ssh.
А вы предлагаете настроить iptables? Тоже вариант, но сложнее в реализации — надо писать правила, и нет шифрования передаваемых данных.
1. налоги выше;
2. чиновники душат малый бизнес проверками.
Это кем-то когда-то придуманный миф, который все повторяют, и даже не пытаются его верифицировать с реальностью…
По налогам — у нас предельно-низкие ставки для предпринимателей на упрощенной системе налогообложения. Этот вариант подходит большинству веб-предпринимателей. Согласитесь, что заплатить до 10% налогов от выручки (в Питере же реально 6%), если выручка — это твой доход, не сложно. Что тут большого? Если же ты вышел за лимиты упрощенки (т.е. доход уже больше $2 млн с небольшим в год), то плати по полной. Ну дак везде так же. Выходит, что большие налоги — это не правда.
На тему душат — может милиция, пожарники, сэс и т.п. и душат мелкую торговлю, хотя было у меня несколько торговых точек в конце 90-х, но и даже там особых проблем я не замечал. Для веб предпринимательства просто нет такой проблемы: его реально никто и не контролирует, разве что налоговая и ПФ будут следить за начисление налогов и отчислений в фонды. Ну так это хлопот доставляет минимум. Мой опыт говорит о простом: с 2005 года не было ни одной проверки! НИ ОДНОЙ!
Реальная же беда России в том, что никто не хочет вкалывать, все хотят номинально работать и много денег за это.
Нельзя все-все автоматизировать с помощью одного решения. Нужно использовать то ПО, которое позволяет вести бизнес лучше, а не выкручивать себе руки.
У любой ERP есть свои сильные стороны, но точно есть и свои слабые. И ни одна ERP идеально не ляжет на конкретный бизнес.
Выходит, что вопрос у вас какой-то теоретический, поскольку вариант «автоматизировать все-все одним» не жизнеспособен.
Просто для облака они отдельный сайт запустили, стоило на нем тоже указать ссылки на договор и СЛА.
1. Подскажите, распределяете ли вы копии данных между датацентрами? Было бы здорово, чтобы три копии оказывались в разных ДЦ.
2. Не смог найти по этой услуге SLA.
И одна ремарка — на сайте стоило выложить договор оферты, чтобы можно было четко понять все организационно-правовые нюансы.
Необходимость восстанавливать подключение хранилища к серверу после каких-либо падений вручную не вызываем оптимизма :-(.
Конечно, удобно вести документацию на одном языке — трудоемкость ниже, но за этим следует глобальный проигрыш, ведь язык — это способ думания, и с сокращением многообразия способов думания мир станет плоским :-(, исчезнут краски.
Так что я за перевод.
От идиотских законадательных инициатив должно спасать количество сторонников размером в 100 тысяч. С трудом верится, что наберется столько желающих с помощью думы «пропатчить KDE2 под FreeBSD». А если столько наберется — то мы не достойны гражданского общества, и наш удел — тоталитаризм.
Идея интерактивного обучения хороша, не спорю. Но все хорошее на этом и заканчивается.
Сами уроки — не системные, написаны разными авторами, перекрывают друг-друга, отчего быстро надоедает делать одно и то же. В общем очень не интересный курс у них получился. По другим языкам учебные пособия грозятся сделать — так если будут делать так же, как по JavaScript, то можно и не начинать — хорошо не получится.
Для изучения JavaScript учебник Илья Кантора learn.javascript.ru намного лучше: материал комплексный и гораздо шире, интерактивные задания тоже есть. При этом русский язык учебника — изначально!
К сожалению, чипованные мастеркард в России редки. К сожалению — поскольку в Европе выгоднее рассчитываться именно мастеркардами, чем визами.
Я все это тестировал на gearmand 0.14 + php 5.3.10 (c pecl gearman 0.8.0 + libgearman 0.14)
Если у вас GearmanJob::sendFail будет работать, черканите, на каких версиях ПО.
Я не понял, что тут теряется? Подсказка для метода do? Не должна она тут теряться.
$ php worker.php
Function got: «Function data» and fail < — вот он вывод в консоль
Сколько раз воркер обрабатывал задание можно понять из количества выводов в консоль.
На каждое задание 1 вывод, несмотря на завершение GearmanJob::sendFail. Т.е. повторно задания не обрабатываются.
Смотрите (код для примера github.com/avorobiev/gearman):
1. запускаем сервер:
$ gearmand -job-retries=2
2. добавляем задание в очередь
$ php client.php
3. проверяем наличие задания в очереди
$ php monitor.php
| function | total | running | workers |
| fail | 1 | 0 | 0 |
4. подключаем воркера
$ php worker.php
Function got: «Function data» and fail
5. проверяем очередь
$ php monitor.php
| function | total | running | workers |
| fail | 0 | 0 | 1 |
ВЫВОД: GearmanJob::sendFail не возвращает задание в очередь. Или я что-то делаю не так?
Если же ее выполнения ожидает клиент, то правильнее обрабатывать на клиенте результат выполнения и повторно ставить задачу, поскольку иначе получается уже каша:
— клиент ждет ответа от воркера;
— воркер не может выполнить, добавляет задачу в очередь;
— раз клиент ждет ответа, то тогда и воркер должен ждать ответа по новой задаче, чтобы вернуть его клиенту.
При такой схеме воркер выпадает из обоймы до выполнения задачи, и так можно всех воркеров перелинковать между собой и все повесить.
А вы предлагаете настроить iptables? Тоже вариант, но сложнее в реализации — надо писать правила, и нет шифрования передаваемых данных.