Согласен костыль… Всё смог настроить, правда немного пришлость потанцевать с бубном. Но Fring по сравнению с SIPDroid не имеет опции набора номера из контакт листа :(
Я использую SIPDroid для звонков из Канады в Россию и в Узбекистан. Не стал заморачиваться с PBXes а прикрутил напрямую свой родной sip провайдер. Доволен качеством, благо 3G есть почти везде. Могу посоветовать провайдера www.voipcheap.com т.к. данные ребята предатавляют халявные звонки (до 300 минутов в 7 дней) на городские телефонные номера по Москве и Питеру (и еще 60 разных стран/городов). Там есть правда одна загвозка в том что надо положить деньги на счёт
ну я сумму привел утрированную. Я не знаю по чем продукты и стоимость готовки будет у вас, там где вы проживаете.
Я правда немного не уточнил, что это было лет 5 назад и тогда цены были пониже, да действие сие происходило в одной из небогатых пост-союзных республик.
Короче говоря нам это обходилось по 10-20 долларов в месяц на человека, что было раза в 2-3 дешевле чем питаться тому же человеку на улице. Может ситуация сейчас поменялось. А приятные воспоминания остались.
П.С. Извиняюсь за орфографию и пунктуацию, они плетутся сзади меня с класса так с 7-8…
думаете? на похожем стартапе мы тоже так делали. потому что банально посчитали что приготовить «домашную еду» для 5-8 мужиков дешевле. чем их сводить на обед.
так что если вам просто накинут 10 доларов в месяц вам будет лучше житься чем вас будут кормить вкусной едой
У нас где то откопали старый NINTENDO и подцепили его на кухне к 52" плазме…
так обеды стали проходить весело, бурно и долго… гоняя братьев марио.
Правда потом шеф сказал 4часовой обеденный перерыв это нагло и забрал NINTENDO =(
VIEW был бы один из самых лучших выходов. потому что тогда мы бы могли многое сделать. но у наших IT не очень прямые руки и добавление VIEW почему то роняло всё бд (сразу все 4 сервера) Видимо наш «replication» скрипт написан далеко не правильно =(
Сорри, я ко всему диалогу забыл добавить, что у нас цель кроме нормализации таблиц еще и обновить MySQL до последней версии. А так у нас сейчас MySQL 3х-4х летней давности.
Поэтому с нормализацией БД мы не спешим. Хотим заняться оптимизацией БД одним махом.
К прикручиванию этих костылей занимался не я, но вот поддерживать их придётся мне.
Мне тоже очень интересно как это работает, и мне скоро всё это будут объяснять. Обещаюсь как только появиться более-менее реальная информация ею поделиться.
во всё никак не мог вспомнить слово.
это и есть кумулятивные отчёты =( а босы у меня вообще «чистые евреи» (не в обиду наций) очень милые и умные люди. просто надо их уметь варить.
во во… вы думаете что «босы» которым уже по много лет будут верить какому-то молодому специалисту из СНГ??? неа здесь найдется свой умный человек а ты делай как он скажет =(
была бы моя воля я бы сделал ваш вариант. а еще на шаге номер 2 можно было бы забить на информацию старее 2-3х лет. кому нужен детальный трафик за такой древний период?
мы похожим методом решали проблему с более мелкими таблицами. но с этой у нас почему то не заладилось (для начало мы все проверяем на dev и stage серверах). тут в Канаде, босы очень бояться брать на себя любую ответственность. К тому же пока идет постоянный большой трафик шефы не хотят тормозить систему =(
поэтому пошли «долгим» путем.
нужен 100% uptime…
Нам (фирме) пришлось приобрести довольно дорогое программное обеспечение от IBM IBM WebSphere Идея данной технологии заключается в том что она может быть прослойкой между несколькими приложениями. В нашем случае между PHP и MySQL. Данная комбинация в скопе с MemCache позволяет нам отключаться БД из рабочего цикла на ограниченное долгое время (до пары недель). Внедрение почти закончилось. скоро будем пробовать alpha тестирование на дев боксе.
а трабл у нас работе очень простой. есть таблица из порядка 20 полей, которую нельзя выключать. А таблица была сделана в далеком 2004 году и не соответсвует сегодняшним требованиям. Нам необходимо добавить пару новых полей / убрать старые и наложить дополнительные индексы.
но мы столкнулись с тем что обычный ALTER TABLE занимает почти неделю чтобы сделать что-нибудь… а эти таблицы еще с replication по системе 2+2 (2 master => 2 slaves)
но мы правда нашли решение как вывести из строя mysql без ущерба для нас самих (если интересно могу поделиться)
15Гб это мало у нас пару таблиц занимают по 70~80Гб вот как туда поставить поставить индексы (а нам они нужны и даже очень) у нас нету идей.
Вариант с физической игрой файлов не получиться т.к. базу нельзя остановить.
а 70-80 гигов набралось за пару лет ведения сгрупированной статистики кликов по рекламе.
Я правда немного не уточнил, что это было лет 5 назад и тогда цены были пониже, да действие сие происходило в одной из небогатых пост-союзных республик.
Короче говоря нам это обходилось по 10-20 долларов в месяц на человека, что было раза в 2-3 дешевле чем питаться тому же человеку на улице. Может ситуация сейчас поменялось. А приятные воспоминания остались.
П.С. Извиняюсь за орфографию и пунктуацию, они плетутся сзади меня с класса так с 7-8…
А потом кого считать курильщиком? Кто курит каждый день? Включать тех кто курить только по праздникам и не в трезвом виде?
так что если вам просто накинут 10 доларов в месяц вам будет лучше житься чем вас будут кормить вкусной едой
Я так прикупил себе отличные наушники (ну не могу я без музыки, надо же как то болтовню вокруг себя забить)
думаю в следующем месяце заменить грызуна без привязи (прошлый перестал работать)
так обеды стали проходить весело, бурно и долго… гоняя братьев марио.
Правда потом шеф сказал 4часовой обеденный перерыв это нагло и забрал NINTENDO =(
Поэтому с нормализацией БД мы не спешим. Хотим заняться оптимизацией БД одним махом.
Мне тоже очень интересно как это работает, и мне скоро всё это будут объяснять. Обещаюсь как только появиться более-менее реальная информация ею поделиться.
это и есть кумулятивные отчёты =( а босы у меня вообще «чистые евреи» (не в обиду наций) очень милые и умные люди. просто надо их уметь варить.
была бы моя воля я бы сделал ваш вариант. а еще на шаге номер 2 можно было бы забить на информацию старее 2-3х лет. кому нужен детальный трафик за такой древний период?
поэтому пошли «долгим» путем.
нужен 100% uptime…
а трабл у нас работе очень простой. есть таблица из порядка 20 полей, которую нельзя выключать. А таблица была сделана в далеком 2004 году и не соответсвует сегодняшним требованиям. Нам необходимо добавить пару новых полей / убрать старые и наложить дополнительные индексы.
но мы столкнулись с тем что обычный ALTER TABLE занимает почти неделю чтобы сделать что-нибудь… а эти таблицы еще с replication по системе 2+2 (2 master => 2 slaves)
но мы правда нашли решение как вывести из строя mysql без ущерба для нас самих (если интересно могу поделиться)
Вариант с физической игрой файлов не получиться т.к. базу нельзя остановить.
а 70-80 гигов набралось за пару лет ведения сгрупированной статистики кликов по рекламе.