Спросите пожалуйста, с какими приложениями интегрируется PHPUnit, ну чтобы автоматически запускались тесты и была возможность удаленно наблюдать результаты, типа CruiseControl и т.п.
Нет, в соглашении об использования сервиса пишем: участник игры согласен с публикацией личных данных там-то и там-то. Уверен, что достойная компенсация за участие в игре перекроет брезгливое отношение к своим личным данным :)
ИМХО, в россии благодарности дело последнее :) это чуть-чуть работает, но в целом нафиг никому не нужно.
По поводу партнерок: пробовали с озоном, за несколько лет (!) при переходах 5 — 10 в месяц нулевой результат, хотя конечно при существенно низкой посещаемости, однако, от партнерки толку не много.
Попробуйте продавать только уникальный контент. Например, оплату введите за новые позиции, которые бесплатными становятся, например, через пару месяцев. И пользователей не потеряете (которые пришли позже, чем опубликована нужная литератора) и доход получите с тех, кому что-то нужно срочно.
Попробуйте оценить сколько люди готовы платить, то есть поднять стоимость до 100р., например, предварительно оценив эту величину. Таким образом, поднимите общую прибыль за счет лояльных пользователей.
На мой взгляд, таким суждением вы совершаете главную ошибку: пытаетесь абстрагироваться от реляционной базы данных на уровне некоего объектного представления (реализуемого через интерфейс DIB).
Существующие проблемы, связанные с разработкой ORM-решений и их использования в основном кроются в отсутствии реального мэппинга объектов на отношения. Каждая СУБД имеет свои ограничения и свои фичи, которые необходимо учитывать и использовать в конкретных проектах. СУБД также накладывает и некоторые ограничения, которые после разработки некоего мока (IDB) потребуют переписать половину системы. Другими словами, вести разработку изначально нужно с учетом этих ограничений, а также преимуществ конкретной СУБД.
Второй момент заключается в том, что моки они годятся только для юнит-тестов, реальная база данных позволяет по-другому взглянуть на функциональность приложения, больше проверить и исправить ошибок на ранних стадиях разработки.
Используйте объектную СУБД, но сразу, и проблема разработки снизу вверх отпадает сама собой.
Конечно, разработать бОльшую часть базы данных до момента кодирования функционала освобождает от массы проблем связанных с развитием структуры данных и соответствующей модификации самих данных (что несомненно возникает при разработке снизу вверх). Однако, давно известны процессные паттерны для обслуживания этой задачи (Фаулер. «Рефакторинг баз данных»).
Я пробовал оба подхода при разработке решений с использованием базы данных: разработка сверху вниз и снизу вверх. В целом у каждого подхода есть минусы, но то что программный код неразрывно связан с логикой (запросами), реализуемой на стороне СУБД, обязывает аккуратно и внимательно относится к мэппингу при разработке.
Сынок, если люди пишут «Спасибо за ссылку, в любом случае :) Никогда не знаешь заранее, что пригодится.», значит комментарий был уместен и полезен — это то, что и ждут от Хабра.
а не хотели бы разместить информацию о проекте и вообще вести его в будущем в системе управления проектом www.devprom.net? Google Code все же много чем не удобен
Подключение пользователей в процесс развития проекта — очень правильная идея, поскольку в какой-то момент вы просто оторветесь от реальных потребностей, а проект должен постоянно и гибко изменяться — подстраиваться под их нужды.
Думаю Вам пригодится функционал, который доступен в системе управления процессом разработки: www.devprom.net
Этот сервис как раз ориентирован на создание сообщества пользователей вокруг вашего проекта, с возможностью активного участия пользователей в развитии проекта.
Тут нужно шире смотреть: сегодня у вас есть офис, а через пару месяцев его может и не стать по известным причинам. Тем более, что эффективнее может быть использование внешних ресурсов (monkey-testing как самый простой пример), где их брать? Искать людей очень долго и дорого.
Есть и другой момент: постановка и прозрачность процесса аутсорса. Небольшие деньги боятся неизвестности, хотят чтобы их максимально эффективно использовали. В частности мы хотим в этом плане помочь всем и заказчикам, и разработчикам, предоставив платформу для ведения бизнеса в данной сфере услуг (http://www.devprom.net). Призываю всех заинтересованных лиц не остаться безучастными.
И честно говоря, стрёмно выглядит эта педия.
# y = k * x + b
def get_linear(k, b):
return lambda x: k * x + b
# y = k * x^2 + b
def get_linear(k, b):
return lambda x: k * x ** 2 + b
Вторая функция видимо должна называться get_poly2 что-ли
По поводу партнерок: пробовали с озоном, за несколько лет (!) при переходах 5 — 10 в месяц нулевой результат, хотя конечно при существенно низкой посещаемости, однако, от партнерки толку не много.
Попробуйте оценить сколько люди готовы платить, то есть поднять стоимость до 100р., например, предварительно оценив эту величину. Таким образом, поднимите общую прибыль за счет лояльных пользователей.
Существующие проблемы, связанные с разработкой ORM-решений и их использования в основном кроются в отсутствии реального мэппинга объектов на отношения. Каждая СУБД имеет свои ограничения и свои фичи, которые необходимо учитывать и использовать в конкретных проектах. СУБД также накладывает и некоторые ограничения, которые после разработки некоего мока (IDB) потребуют переписать половину системы. Другими словами, вести разработку изначально нужно с учетом этих ограничений, а также преимуществ конкретной СУБД.
Второй момент заключается в том, что моки они годятся только для юнит-тестов, реальная база данных позволяет по-другому взглянуть на функциональность приложения, больше проверить и исправить ошибок на ранних стадиях разработки.
Используйте объектную СУБД, но сразу, и проблема разработки снизу вверх отпадает сама собой.
Конечно, разработать бОльшую часть базы данных до момента кодирования функционала освобождает от массы проблем связанных с развитием структуры данных и соответствующей модификации самих данных (что несомненно возникает при разработке снизу вверх). Однако, давно известны процессные паттерны для обслуживания этой задачи (Фаулер. «Рефакторинг баз данных»).
Я пробовал оба подхода при разработке решений с использованием базы данных: разработка сверху вниз и снизу вверх. В целом у каждого подхода есть минусы, но то что программный код неразрывно связан с логикой (запросами), реализуемой на стороне СУБД, обязывает аккуратно и внимательно относится к мэппингу при разработке.
разработка (железо, ПО) все сплошь из ограничений, как и собственно жизнь.
что характерно, «правильные идеи» не выживают (NEXT, BeOS)
Думаю Вам пригодится функционал, который доступен в системе управления процессом разработки: www.devprom.net
Этот сервис как раз ориентирован на создание сообщества пользователей вокруг вашего проекта, с возможностью активного участия пользователей в развитии проекта.