И в чем проблема 256/700 — не хватит запустить бубльгис?
У меня задача — в качестве мобильного браузера заказать пиццу в пробку, и чтоб дубльгис работал на нормальном экране.
Хм. Вот кросспостинг когда встречаю всегда отрубаю и блокирую такие места, но это мои личные заморочки; а вот (2)… drupal насколько помню имеет очень толстый набор кто может «из коробки» и дополнительно к нему в несколько кликов ставятся типа логинзы.
Впрочем, кросспостинг да, это вариант, хотя и не нишевый — такие продукты всё-таки есть уже.
Зачем прикручивают сторонние комментарии?
1) Прикрутить к тупому html-only хостингу.
2) Заспамили встроенное комментирование движка, взяли сторонний чтоб не мучаться.
3) Единый контроль за комментами на контент-ферме.
4) Снять нагрузочную проблему с комментариями за счет стороннего сервиса.
Пункты 1 и 2 не монетизируются. Пункт 3 готов платить очень мало. Пункт 4 вы не тянете.
Вопрос — что такое вы там родили? С какой целью, какую нишу хотите занять?
А как для пользователя это выглядит — он нажал «Опубликовать», и? Получил ошибку «попробуйте позже»? Съел, но ничего не произошло? Съел, получил реалтайм обновление, где просто нет его коммента?
внути внутреннего цикла $val модифицируется в зависимости от таблички правил модификации — где для каждой таблицы задаётся ключ модификации. текущее поле есть — $k, я добавил еще выдёргивание имён полей в момент парзинга CREATE TABLE, таким образом, внутри цикла у меня есть имя таблицы, имя поля, значение поля, и значение ID записи.
на базе этих данных я и генерирую обфусцированное значение.
То есть модификация значения вообще не регулярка, а простой такой if:
$replace = $config->{$table}->{$field};
if(!$replace) {
$replace = autodetect_replace($field); // автоматическое конвертирование полей типа *name*, *email*, итд.
}
if($replace ==1) {
$val=randgen_name($table, $id, $field);
}
elif($replace ==1) {
$val=randgen_email($table, $id, $field);
}
…
Для исправления связанных таблиц есть три момента:
1. Нормализованная база не содержит дублирающихся элементов, а потому НЕТ необходимости обновлять каскадом — можно спокойно деперсоналить каждую конкретную таблицу независимо
2. Для исправления, например, ID, полей — легко строится односторонний хеш на базе id исходной таблицы и её имени — таким образом, мы легко можем поменять foreing key в других местах, так как мы знаем на какую таблицу и какой id ссылаемся без проблем
Единственная проблема, с которой я столкнулся — это использование рандомных данных на базе только id исходной таблицы не даёт должного раскидывания результатов если меняемая строка короткая. Поэтому для строк < 6 символов я увеличиваю строки до 8.
На наших базах (~300 метров в sql.bz2) конфликтов больше небыло.
И, в отличие от sql конструкции, править пачку ифов на перле проще, чем вложенные case/elt/самопальный rnd
мне было вломы дампить с single instruction (да и импортировать после этого тяжело) — поэтому получилось 2 регулярки — вырезать каждый отдельный кусок, и потом отдельно разрезать каждый кусок на поля.
Господи, у вас для деперсонализации скрипт БАЗУ ДЁРГАЕТ?!
Вы что, делаете копию базы (дамп-рестор), потом дрочите базу, и только потом еще один дамп чтоб получить деперсонализованную?!
Не проще ли деперсонализовать дамп?! Дамп-деперсонал — готов дамп, который можно влить куда-то или юзать разработчикам локально.
Причина — наименьшие потери ресурсов на виртуализацию.
И в чем проблема 256/700 — не хватит запустить бубльгис?
У меня задача — в качестве мобильного браузера заказать пиццу в пробку, и чтоб дубльгис работал на нормальном экране.
вроде тоже интересный вариант
Я буквально вчера искал — нашел только вот это: www.aliexpress.com/product-fm/494903643-8-GPS-Dual-Camera-Capacitive-Tablet-PC-Android-2-3-3-Gingerbread-TCC8803-A8-1GHz-512MB-wholesalers.html
$211.69+$52.38 доставка-$30 скидка = $234,07
Есть достойные альтернативы?
Впрочем, кросспостинг да, это вариант, хотя и не нишевый — такие продукты всё-таки есть уже.
Удачи в развитии, и пусть успех накроет )
1) Прикрутить к тупому html-only хостингу.
2) Заспамили встроенное комментирование движка, взяли сторонний чтоб не мучаться.
3) Единый контроль за комментами на контент-ферме.
4) Снять нагрузочную проблему с комментариями за счет стороннего сервиса.
Пункты 1 и 2 не монетизируются. Пункт 3 готов платить очень мало. Пункт 4 вы не тянете.
Вопрос — что такое вы там родили? С какой целью, какую нишу хотите занять?
Как с нагрузочным тестированием? Не порвёт от траффика в 5к комментов враз на одну страницу?
на базе этих данных я и генерирую обфусцированное значение.
То есть модификация значения вообще не регулярка, а простой такой if:
$replace = $config->{$table}->{$field};
if(!$replace) {
$replace = autodetect_replace($field); // автоматическое конвертирование полей типа *name*, *email*, итд.
}
if($replace ==1) {
$val=randgen_name($table, $id, $field);
}
elif($replace ==1) {
$val=randgen_email($table, $id, $field);
}
…
Для исправления связанных таблиц есть три момента:
1. Нормализованная база не содержит дублирающихся элементов, а потому НЕТ необходимости обновлять каскадом — можно спокойно деперсоналить каждую конкретную таблицу независимо
2. Для исправления, например, ID, полей — легко строится односторонний хеш на базе id исходной таблицы и её имени — таким образом, мы легко можем поменять foreing key в других местах, так как мы знаем на какую таблицу и какой id ссылаемся без проблем
Единственная проблема, с которой я столкнулся — это использование рандомных данных на базе только id исходной таблицы не даёт должного раскидывания результатов если меняемая строка короткая. Поэтому для строк < 6 символов я увеличиваю строки до 8.
На наших базах (~300 метров в sql.bz2) конфликтов больше небыло.
И, в отличие от sql конструкции, править пачку ифов на перле проще, чем вложенные case/elt/самопальный rnd
Вы что, делаете копию базы (дамп-рестор), потом дрочите базу, и только потом еще один дамп чтоб получить деперсонализованную?!
Не проще ли деперсонализовать дамп?! Дамп-деперсонал — готов дамп, который можно влить куда-то или юзать разработчикам локально.
Вы там что курили?!