Алексей Черемисин

А, дьюди, такая же проблема! Под OSX он совсем не нативный и работает через ж.., упс, через ХеОкна11, страх и ненавись. Я для себя эту проблему решил по другому, установил в пареллелях Ubuntu и ненарадуюсь обладанию inkscape. Собственно и в винде под параллелями тоже хорошо работает.

Здесь как минимум нужно немного залезть в предметную область и ответить себе на вопросы (до таблиц и полей):
- что такое "погода", чем она измеряется, какие у нее характеристики, есть ли табличные данные: типа привязки к местности (город, район и т.д.), таблицы комфорта (комфортно не очень, не комфортно) или влажности (сухо, влажно, мокро и т.д.)?
- тоже самое расписываем для прогноза.
- теперь по отчетам, какие типы отчетов планируются ( за день по местности, пелевантность по прогнозу и т.д.).
Что касается отчетов, то они бывают (обычно) двух типов.
Одни формируются простой выборкой из базы данных с агрегацией - это простые агрегированные отчеты (средняя температура за час, или минимум/максимум за период по местности). Для таких отчетов обычно не нужно создавать таблиц и хранить промежуточные данные, если только не для ускорения предоставления и не в целях архивации (например подсчет и сохранение средней температуры день/ночь ежедневно по окончании суток).
Вторые - аналитические. Например средняя ошибка в прогнозах за одинаковые периоды по местностям. Это те отчеты, которые требуют агрегации нескольких выборок, здесь приходится создавать промежуточные таблицы с результатами выборок, и уже по ним формировать выходные данные ( как нахождение второй и третьей производных функций).
В общем, сначала описываете СЛОВАМИ что у вас есть на входе по погоде и температуре, и какие отчеты хотелось бы получить. А уже из этого делаете модель данных под простые отчеты, и в самом конце занимаетесь аналитикой. Также сразу позаботьтесь об объемах данных, вдруг их придется шардировать, архивировать и т.д..
Наводящие вопросы я задал. Отвечайте, двинемся дальше.

Собственно ничего сложного нет. Пишем такие же unit-тесты, а результаты assert-ов складываем в отдельную область памяти. Её потом легко просматривать на наличие единиц (можно сделать даже битовым сдвигом). Другими словами, нам нужно только написать функцию assert, которая сравнивает два своих аргумента и результат заносит в следующий бит (или байт) в выделенной области памяти (0 - хорошо, 1 - плохо). По позиции в памяти вычисляем сбойный ассерт. Если памяти много, то можно еще добавить аргумент с номером теста к ассерту, тогда у нас будет один байт номер теста, второй - результат.
Ну, кстати, так и логиваться можно прямо в режиме работы, только нужно в ассерте еще и циклический буфер сделать и указатель на текущий элемент.
А собственно, я в свое время так и отлаживался. Подходит для отладки очень быстрых процессов!!!!

В соответствии с уровнем команды выбирается язык (или языки) программирования (php, python, java, scala, perl, erlang). Далее Архитекторами выбирается:
- архитектура приложения (приложений): фронтэнт, бекэнд, базы данных, кеши, очереди сообщений и т.д., CMS или CMF или фреймворк/фреймворки.
И так, у нас есть команда, что, как и на чем делать.
После этого Дизайнер делает графические файлы и передает их Верстальщику.
В этот момент Программисты вполне могут делать основную машинерию сайта, выписывать взаимодействие с базами, фронтэндом/бекэндом, создавать ORM и запросы, делать прототипы документов и бизнес-логику.
Как только от Верстальщиков с Дизайнерами поступают куски разметки, то их натягивают на уже существующую машинерию.
При этом Тестировщики непрерывно в режиме continius integration белают функциональные и нагрузочные тесты.
Далее этапы наступают этапы тестирования и исправления ошибок всей командой по кругу.
Как только Менеджер доволен получившейся работой, то отдают Заказчику. А далее - этапы тестирования и исправления ошибок всей командой по кругу, пока Заказчик не будет доволен.

Ну а по хорошему, так как двух одинаковых проектов практически не бывает, то все работы можно прорисовать в диаграмме Ганта. Тогда сразу будет видно, кто и что параллельно делает в данном проекте - infineconomics.blogspot.ru/2014/04/gantt-chart-in-...

Простым языком. ESB помогает связать кучу разрозненных приложений в единое целое. Например. Есть старый ftp, email серверы и новое приложение j2ee. Нужно, по приходу файла на ftp сообщить об этом по email и обработав, залить через REST в j2ee приложение. ESB будет сканировать папку на ftp, сообщит об этом по email, отпарсит файло и пульнет результат по http в j2ee.
В нутрях у ESB обычно прячется MQ, но не всегда.

MQ, собственно, занимается умной доставкой сообщений, и только, предоставляя пару тройку API для этого.

Другими словами, ESB не подразумевает внедрения нового кода в старые приложения, MQ требует использовать во всех приложениях совместимый API.

Не хочу разводить холивары, купите параллели, все работает как надо и винды и линуксы. С VirtualBox в плане производительности не подружился ни в линуксе (KVM пользую везде.), ни в винде (только в виртуалке её и вижу теперь), ни в OS X (пользую параллели).