Не знаю как сейчас, а раньше они были регулярно — в часы пик на Арбатско-Покровской линии участок до Крылатского до Киевской. В последнее время вроде бы поменьше стали.
На OS3 должна быть включена во время сна. А проверка на OS4 — в планах, если там все действительно все хорошо с многозадачностью и все прозрачно, то должна заработать из коробки
Нет, за 25% оставшегося до крайней границы пробуждения времени он зазвонит. Ну например: поставили Вы с 9 до 11. Если к 10.30 уровень пробок не уменьшился — зазвонит.
Человек не является идейным вдохновителем стартапа, а просто отвечает за его техническую реализацию. «Мой стартап» в данном контексте обозначал бы, что человек является автором идеи.
Не совсем понял такие вещи:
1. На чем именно Вы собирались зарабатывать? Ясно, что на стартапе, пока его нет, не заработаешь.
2. Какой суммы Вам хватает на покушать? Судя по числам, Вы в состоянии зарабатывать в 5 раз больше нее, если планируете отвести для ее зарабатывания 20% времени. Либо Вы гений, либо Вам мало нужно.
А капитал потребуется еще на технические моменты вроде аренды серверов и продвижение. Как минимум (ну тут уже от конкретной идеи зависит). Да и поддержка тоже будет время занимать.
Еще нужен оборотный капитал, как минимум. Даже если идея есть и примерная структура реализации, надо ведь еще его создавать. А в это время тоже хочется кушать.
ну, вообще Вы правы, я согласен. Проблема бывает в том, что иногда проект в таком состоянии, что там рефакторинг ни к чему не привяжешь — весь фундамент гнилой. При этом менеджеры не понимают необходимости процедуры, а потому не дают на нее времени.
Но вопрос заключался даже не в этом. А в том, как бороться с постепенными изменениями? Как распознать, что это только начало и будет продолжение? Или делать с самого начала по-нормальному, даже если на хак ушло бы пять минут, а на переделку гораздо больше времени?
А интересно, как кто поступает с постепенной, не такой глобальной сменой дизайна, да и функционала вообще? Приходит менеджер и говорит: «ну нам тут только чуть-чуть подправить, тут вот одну фишечку добавить, там другую...». Прикидываешь все это, понимаешь, что действительно будет быстрее дописать, а не переписать. Корпеешь над этим всем, где-то приходится хак-другой написать, где-то неочевидную логику зашиваешь, ну ладно, думаешь, комментарии поставлю, потом их почитаю, если что, разберусь. Менеджер смотрит на это и говорит: «Круто! А давай еще вот эту фишечку и вот это повесим, и еще у нас вот на том проекте так классно было». Ты постепенно звереешь, так как понятно, что если бы раньше про это знал, предпринял бы уже более глобальные действия, поменял бы что-нибудь кардинально. Но плюешь, добавляешь еще пару хаков. А потом к менеджеру приходит начальник и требует еще такие и такие изменения. В конце концов суммарно получается переделка 70-80% всего, и если бы знал, что так будет, с самого начала бы делал как следует. В очередную доделку ты говоришь менеджеру, что сайт скоро рухнет под собственным весом, и теперь добавление очередной малой возможности займет несколько дней. На что встречаешь в лучшем случае, непонимание. Обычно менеджеры боятся брать на себя такую ответственность по глобальным изменениям.
Так еще на все это наслаивается и то, что проект чужой, был разработан ногами, а на его переделку не выделили время, так как посчитали нецелесообразным. И вот лежит он такой, частями нетронутый в говнокоде, и ты стараешься туда не залезать без особой надобности, а если уж залез, так переделать по-нормальному. Как раз сейчас ищу ту грань для себя, когда нужно переделать, а когда можно и оставить, как есть, а просто дописать под нужные требования.
Коды некоторые платежные системы действительно предоставляют, однако от кода, например, вебмани лично меня воротит. Использовать его в чистом виде мне противно, годится только разве как иллюстрация.
Насчет разжеванного API — у меня даже был такой случай. Подключаем новую платежную систему, сделали пробный заказ, отправил данные по заказу человеку, который занимался подключением с их стороны (система предусматривала платеж с терминалов, так что оплачивать заказ надо было вручную). Отправил ему, жду. Час проходит, второй, я уже забыл про него. Вспоминаю, спрашиваю — ну как там заказ-то мой, оплатили? Да нет, говорит, подожди, сейчас парсинг ответа допишу и продолжим. Так что и такие бывают.
Насчет режимов тестирования, кстати, тоже не все гладко — разве только у вебмани и еще у кого-то. У яндекса такой режим тоже есть, но переключается он их менеджерами и очень неохотно. Помнится, они долго ломались его включать, когда у нас проблемы возникли, и надо было отладить без реальных денег. Я с этим поступил просто — при подключении приходится писать эмулятор системы, что-то типа простого юнит-теста. Конечно, это не панацея, но от глобальных ошибок спасает. Да и если вдруг что-то потребуется поменятьв обработчике, лишняя проверка.
Можно постараться интегрировать как можно более изящно. Иногда это физически невозможно — тогда надо хотя бы обеспечить работу костыля. Чтобы хотя бы работало. Если удалось хотя бы что-то — уже хорошо, кому-то может пригодиться опыт. У меня иногда даже просыпается спортивный интерес — кто кого переборет — человеческий ум или машина.
А насчет того, что стыдно — не знаю, мне не стыдно. Не Вы же битрикс писали. А на своих проектах я битрикс всегда обновлял помолясь, то есть с полным бэкапом всего, даже если его ядро не хакал.
1. На чем именно Вы собирались зарабатывать? Ясно, что на стартапе, пока его нет, не заработаешь.
2. Какой суммы Вам хватает на покушать? Судя по числам, Вы в состоянии зарабатывать в 5 раз больше нее, если планируете отвести для ее зарабатывания 20% времени. Либо Вы гений, либо Вам мало нужно.
А капитал потребуется еще на технические моменты вроде аренды серверов и продвижение. Как минимум (ну тут уже от конкретной идеи зависит). Да и поддержка тоже будет время занимать.
Но вопрос заключался даже не в этом. А в том, как бороться с постепенными изменениями? Как распознать, что это только начало и будет продолжение? Или делать с самого начала по-нормальному, даже если на хак ушло бы пять минут, а на переделку гораздо больше времени?
Так еще на все это наслаивается и то, что проект чужой, был разработан ногами, а на его переделку не выделили время, так как посчитали нецелесообразным. И вот лежит он такой, частями нетронутый в говнокоде, и ты стараешься туда не залезать без особой надобности, а если уж залез, так переделать по-нормальному. Как раз сейчас ищу ту грань для себя, когда нужно переделать, а когда можно и оставить, как есть, а просто дописать под нужные требования.
Насчет разжеванного API — у меня даже был такой случай. Подключаем новую платежную систему, сделали пробный заказ, отправил данные по заказу человеку, который занимался подключением с их стороны (система предусматривала платеж с терминалов, так что оплачивать заказ надо было вручную). Отправил ему, жду. Час проходит, второй, я уже забыл про него. Вспоминаю, спрашиваю — ну как там заказ-то мой, оплатили? Да нет, говорит, подожди, сейчас парсинг ответа допишу и продолжим. Так что и такие бывают.
Насчет режимов тестирования, кстати, тоже не все гладко — разве только у вебмани и еще у кого-то. У яндекса такой режим тоже есть, но переключается он их менеджерами и очень неохотно. Помнится, они долго ломались его включать, когда у нас проблемы возникли, и надо было отладить без реальных денег. Я с этим поступил просто — при подключении приходится писать эмулятор системы, что-то типа простого юнит-теста. Конечно, это не панацея, но от глобальных ошибок спасает. Да и если вдруг что-то потребуется поменятьв обработчике, лишняя проверка.
А насчет того, что стыдно — не знаю, мне не стыдно. Не Вы же битрикс писали. А на своих проектах я битрикс всегда обновлял помолясь, то есть с полным бэкапом всего, даже если его ядро не хакал.
А извратами делились бы, может, кому и пригодятся