Без учета 'какой то программы' все описанное ложится на один день спокойной работы, бонус к скорости тут то, что приложения уже есть и работают, т.е. вопрос в установке и переносу настроек… какие недели, откуда?
p.s. привожу пример почти универсальной миграции на другой физический сервер старого за 1-2 часа (и то, это в основном проблемы с драйверами при смене платформы ну и +физическое копирование данных, если там сотни гигабайт то подольше получится) — это использование виртуальной машины.
>> PS прямо сейчас как раз мучаюсь с ней — у неё неподписанный драйвер ставиться — а на 64-битную семерку так просто такой не поставишь…
Уже НЕ НАДО запускать windows 7 x64 в тестовом режиме, буквально пару месяцев назад выпустили обновление (я связывался по этому поводу с их службой поддержки, тешу надеждой что сертификат они сделали после моего обращения)
p.s. форум у них заброшен давно и заспамлен, очень жаль. проект замечательный. У меня используется версия на 2 рабочих места и именно как игровая платформа (2 видеокарты, 16Gb оперативки,..). Положительные впечатления (хотя, к примеру Aion от Инновы, а скорее всего защитная система Frost, тормозит компьютер в самые непонятные моменты… и к диску не обращается, и видео независимое… но это последний год, раньше спокойно работали параллельно и 3D-шутеры, и стратегия типа Diablo III...)
Было бы замечательно, собрать емкое хранилище на основе карт памяти (десяток карт по 64гб или 20-цать на 32гб), но возникает вопрос, где взять компактный ридер на десять/двадцать слотов.
Когда то решил это проблему похоже… на странице, где была кнопка для перехода к форме создания записи, вместо перехода к самой форме был переход к промежуточной странице, которая создавала пустую запись с дефолтными значениями и открывала ее на редактирование… только нужно заранее проектировать базу данных на существование таких недоделанных записей (иногда соответствующий статус помогает).
Будет еще хуже — будет форма, с дырками, которые получились из-за отломившегося материала, отломившийся, потому что от старости, грязи и слежавшести… видел 'солдатиков' в такой форме в одном поезде (ехали с обычными пассажирами, человек 20), осознайте уровень обветшалости, если в этом их отправили 'на люди'.
О реальной работе программиста могут думать считанные доли процента тех кто попадет туда 'по специальности'.
upd. постоянно ведите диалог с подрядчиком. Никакой тишины. Специально выделенные специалисты от вашей организации должны на ряду со специально выделенными людьми от подрядчика (а они будут, те кто будет изучать ваш современный бизнеспроцесс и старую базу) должны постоянно организовывать встречи (еженедельно, ежемесячно, по мере поступления проблем), на которых должны обсуждаться текущие результаты, задачи и проблемы.
Этот момент наверное даже важнее всех других, любая тишина сейчас — это проблемы потом.
Тогда у меня для вас плохие новости :(
Что бы вы не делали, сколько бы сил не потратили, 'как надо' не получится… сам не однократно вплетался в эту лямку… результат был одинаковый.
Первый маркер распила — требование подрядчика. Что бы вам не говорило начальство, у госконторы есть резервы и деньги и ставки, просто именно они уже давно распределены по дочерам и внукерам (доч/сын начальника, внук заместителя начальника и т.п.).
Советы по тз:
1. Настаивайте в ТЗ на поэтапную разработку и сдачу проекта… никаких 'через год дадим готовый проект', Должны быть прописаны ряд конкретных сроков, по которым должен быть конкретный результат, например поквартально или даже помесячно.
2. На середине срока у вас, хотя бы и на площадке заказчика, должен быть готовый работающий проект (альфа версия), на котором должны быть уже загружены все необходимые данные для работы пользователей, и в ТЗ должно быть прописан тест на примере хотя бы одного подразделения (или как еще позволяет разделить работу задача)
3. Вторая половина срока должна быть потрачена:
* на тестирование и выявление ошибок, из-за неточного ТЗ
(а ТЗ будет неточным, это реальность, так как правильное ТЗ это больше половины дела… а ведь вам 500к не заплатят, а подрядчик не достаточно знаком с вашей организацией чтобы сделать правильное ТЗ), неточного понимания задачи и т.п… возможность исправить ошибки на этом этапе должны быть прописаны в договоре с подрядчиком.
* на конвертацию данных из старой базы в новую
Об этом вечно все забывают, иногда задача может быть не легче разработки всей системы, так как может потребоваться разработка специального функционала или даже рабочих мест операторов, обслуживающих этот перенос, для случаев когда полный автомат невозможен (а это почти гарантированно будет так, одно сведение справочников старой базы к новым реалиям чего стоит).
* на установку и настройку оборудования уже на стороне заказчика
* на обучение персонала и учителей персонала
* на выявление проблем в документации
p.s. если у вас не будет этих пунктов, вы получите проект, сделанный фрилансером за пару месяцев перед окончанием срока за 1-3% от первоначальной стоимости проекта, без документации, без грамотно организованных бизнеспроцессов, при этом для начальства будет красивый дизайн, много много кнопочек и пунктиков (чтобы принимающие не сразу въехали) и тонной проблем, выползающих во время реальной эксплуатации, за исправление которых вашей организации придется обратиться к подрядчику и за нехилые бабки.
не, не, не… посмотрите слева… один fetchurl = один вызов задачи… тысячи запросов справа это просто сумма всех операций datastore слева.
Больше всего меня интересует даже не почему на один вызов примитивной задачи (позже выложу пример и напишу статью) делается 19 запросов на чтение и 2 запроса на запись… а почему при такой не высокой интенсивности (один запрос за 70 секунд, точнее 60+20*rand) за три часа приложение выжрало 50т. запросов по биллингу… как не считай это расхождение с прогнозом на порядок, т.е. должно было быть ~3т.
Если это так, то у меня для GAE плохие новости,… у них криворукие программисты :)
Но проблема в том, что штатный механизм контроля за количеством запросов не показывает такой запредельной нагрузки, а соотношение запросов на чтение к запускам задачи не изменяется по мере заполнения базы (список элементов не уменьшается… если бы каждый раз читался весь список, то нагрузка росла бы экспоненциально… а у меня при перезапуске (при сбросе статистики), отношение количества запросов остается таким же.
Да не сильно тайна… я пока его упрощаю поэтапно, хочу разобраться, где же собака порылась. Чуть чуть позже выложу пример, если не разберусь, да и если разберусь, выложу.
Просто позже я уже работал с GAE и там обычно все упиралось в записи, но никак не чтение…
Штатно, только через API, при его отсутствии реверсинженеринг протокола не выход.
p.s. Google публично не предоставляет протокола для авторизации приложений не через веб, даже его собственные приложения на дексктопах открывают во встроенном окне минибраузера окно авторизации. Для мобильных платформ протокол авторизации закрыт.
А зачем могут понадобиться файлы QR-кодов такого высокого разрешения? Сомневаюсь что обычный мобильник со своей куцей камерой способен распознать такой сложный код (если на точку будут выделены к примеру 1x1 или 2x2 пиксела при разрешении выше 1000px).
Черт, нед описал…
У меня акронис отказался восстанавливать архив (теоретически он стал поврежденным, но хотя бы хоть что возможно извлек бы… тупо писал что файл не найден), мало того, там разные версии архивов и утилит, и совместимость снизу вверх не поддерживают… в общем проприетарщина во всей красе :(
Красивый пример привел ниже, обеспечение безопасности (усложнение) доступа к данным.
Как вариант, я запускал в qemu (без виртуализации) windows xp на почти самой дешевой firstvds, вполне работоспособно (к сожалению было слишком медленно, нужно было запускать очень сложный документ excell, openofice не справлялся никак, и прикручивать к нему автоматизацию через внешнее приложение).
Например виртуалка user mode linux (это ядро linux, позволяющее запускать почти с нативной скоростью виртуалки, даже без наличия root доступа), очень неплохая альтернатива, особенно если нужен расширенный функционал снапшотов, который просто недоступен ни в одной инфраструктуре виртуальных машин, кроме только что amazon, но там дорого)
Весь цымус тут в коде этих процедур :)
Логировать сами факты изменений вместе с данными — очень уж решение в лоб… к тому же иногда избыточное, не всегда нужна фактически онлайн репликация, поэтому в простых случаях (точнее когда интерваллы между синхронизациями сравнительно большие) достаточно добавить в каждую таблицу дату последнего изменения и триггерами ставить новую эту дату… само собой удаление логировать придется в отдельную табличку (просто список id,table_name даже без индексов).
Код триггеров — по паре строчек (автоматически нагенерировать для каждой таблички), код синхронизации — с десяток строчек и пара запросов к базе на исходящей стороне, и тупой bash скрипт из трех строчек на принимающей.