Не так давно я оценивал проект, на который другая организация уже дала оценку в $30,000. Наша оценка, достаточно детализированная, получилась минимум в два раза больше. Естественно, мы проиграли, так как сбрасывать цену и работать за бесплатно не собирались.
Я практически на 100% уверен, что конкуренты затянут проект по строкам (и заказчик в этом уверен, как ни странно), и попадут по деньгам, и будут доделывать за бесплатно.
Но заказчику это выгодней, так как он из них выжмет все что сможет.
А на качество ему плевать… тоже как ни странно…
Есть великолепная книга «Тестирование dot com» Романа Савина (на русском, и вроде на английском тоже).
Мне она случайно попалась после того, как я проработал пару лет менеджером в фирме, где был великолепно поставлен процесс разработки (а до этого в фирме, где процесс разработки был сделан на коленке, хотя тоже был не плох).
Очень советую эту книжку, прежде всего тестировщикам и менеджерам, и разрабам тоже пригодится. Процесс тестирования и взаимодействия между командами в ней расписан просто великолепно.
один случай был — при большом количестве JOIN-ов, оптимизатор учитывал только первые 6-8 JOIN-ов (у постгресса в настройках есть параметр), а остальные не оптимизировал. Получалось, что смена порядка JOIN-ов изменяла скорость выполнения запроса в раз в 20. Это дело было починено в 9.1. Другой случай — в сложном запросе был sub-query, который по логике должен был запущен 1 раз, а запрос с ним выполнялся в 100 раз медленнее, чем должен был. Тоже было починено в 9.1, а в 8.4 помогла замена на JOIN. Ну и прилично было таких случаев. Был даже случай, когда 9.1 начал тормозить на запросе, нормально выполнявшемся в 8.4, но не помню уже, в чем там дело было.
> Благодаря наследованию таблиц мы легко можем партиционировать таблицы
Вот тут ребята прикололись — «партиционировать таблицы» по постгрессе ужасно неудобно, о чем неоднократно упоминали в форумах разработчиков постгресса. Как раз в коммерческих СУБД партицирование нормально сделано.
Постгрес тоже часто на сложных запросах в full table scan сваливается — я несколько раз за последние пару лет наткнулся. 9.1 значительно лучше 8.х в этом отношении, конечно.
На самом деле эти устройства (особенно датчики влажности) постепенно выходят из строя, и начинают, к примеру, вместо плавной кривой выдавать пороговые значения (резко прыгать до 100%).
Кстати, плюс/минус 4.5% для датчика влажности — не самые хорошие показатели. У нас в продукте по защите растений некоторые вредители активизируются при влажности выше 90% (относительная влажность), и там единицы процентов играют очень важную роль.
Телефонные RFID сканеры требуют приблизить телефон практически вплотную к карточке, и секунду-другую подержать. И еще отключаются (на Самсунге, к примеру) если экран телефона выключен (типа защиты от самопроизвольного срабатывания).
Мы, к примеру, PostgreSQL активно пользуем отчасти из-за наличия PostGIS расширения для работы с географическими данными, и это очень полезно, когда с картами работаешь.
Я практически на 100% уверен, что конкуренты затянут проект по строкам (и заказчик в этом уверен, как ни странно), и попадут по деньгам, и будут доделывать за бесплатно.
Но заказчику это выгодней, так как он из них выжмет все что сможет.
А на качество ему плевать… тоже как ни странно…
Наверное, что-то там таки есть :-) просто написано популярно, доходчиво, и в тему…
Лично я бы рекомендовал людям начинать именно с Коупленда
Пытался нагуглить — не нашел. Можно ссылку?
Есть великолепная книга «Тестирование dot com» Романа Савина (на русском, и вроде на английском тоже).
Мне она случайно попалась после того, как я проработал пару лет менеджером в фирме, где был великолепно поставлен процесс разработки (а до этого в фирме, где процесс разработки был сделан на коленке, хотя тоже был не плох).
Очень советую эту книжку, прежде всего тестировщикам и менеджерам, и разрабам тоже пригодится. Процесс тестирования и взаимодействия между командами в ней расписан просто великолепно.
Вот тут ребята прикололись — «партиционировать таблицы» по постгрессе ужасно неудобно, о чем неоднократно упоминали в форумах разработчиков постгресса. Как раз в коммерческих СУБД партицирование нормально сделано.
Лениво по одной книге скачивать…
Ошибка
Сервер вернул ошибку: (InternalError): script too large stack: cib([object Object], fileName: finbudgetgrid.appspot.com/finbudgetgriddemo/565AEE3F7C6E9A487A59D92F3B89AB62.cache.html lineNumber: 3679
Хабра-эффект?
Кстати, плюс/минус 4.5% для датчика влажности — не самые хорошие показатели. У нас в продукте по защите растений некоторые вредители активизируются при влажности выше 90% (относительная влажность), и там единицы процентов играют очень важную роль.
так что ими не очень удобно данные воровать :-)