Жмешь кнопку — записать макрос, выполняешь телодвижения, для изменения двуз страниц, и курсор оставляешь так, чтобы следующее повторение предыдущих действий стало раскрашивать уже следующие 2 страницы, останавливаешь запись макроса — получаешь код, который выполняет твои действия… добавляешь цикл for с количеством (или проверкой текущей страницы или еще как, не важно) и делаешь кнопку с вызовом этого кода.
если файлов очень много, в код можно добавить открытие файла, выполнение цикла раскраски, сохранение и закрытие… и еще один цикл уже по файлам.
Даже документацию читать не нужно, код любого действия (в т.ч. открытие закрытие файла) делается записью макроса.
p.s. где именно кнопки макроса ищи сам, не помню, но точно их можно добавить вручную в кустомизации интерфейса
Я дико извиняюсь, хотел подать полезную идею и сам же подсунул фигню… правда, если сделать fulltext index и использовать match…
Я просто хотел чтобы на задачу взглянули с другой стороны, в одном моем очень старом говнопроекте, где количество пользователей было ограничено и изменялось очень редко, и поэтому таблица раздачи прав представляла из себя булеву матрицу с колонками — пользователями, строками — объектами (вот их как раз могло быть очень много). Это не так уж и страшно, таблица с сотней колонок и кучи нулей, зато проверка прав доступа была действительно быстрой (в том проекте многие запросы генерировались перед исполнением — это плохая практика, но давала невероятную гибкость принципов метапрограммирования).
Да, я действительно предложил задуматься о том, чтобы убрать такое понятие как 'доступно друзьям', а триггерами на добавление/удаление друзей заполнять таблицу прав, чтобы избавиться от content_share_wide,… и в конце концов, есть же enum (правда его недостаток — при добавлении нового типа потребуется изменение типа поля таблицы, что обычно не шустро для очень больших таблиц).
Недостатки EAV неплохо решаются автоматически создаваемым кешем в виде классической таблицы поле->атрибут
Зато достоинства в виде гибкости — неоспоримы
p.s. по теме топика, каждый атрибут (я предпочитаю термин тег/метка) должен иметь возможность дополнительного свойства:
тег — 'вес', параметр тега: 200г
тег — 'цвет', параметр тега: 'красный'
тег — 'дополнительное украшение', параметры тега: цвет: 'белый', тип украшения: справочник 'Рюшечки'
Для приверженцев обычных или даже дисковых телефонов числа можно сообщить в sms или голосом, ну конечно это будет немного дороже, но за антиквариат приходится платить.
Ого, но ведь обучение чему либо нужно эффективнее начинать от простого к сложному. То есть вы и еще как минимум трое считаете что JavaScript сложнее чем C? думаете что динамическая типизация сложнее статической? отсутствие базовых/стандартных методов для строк (каждая библиотека/стандарт/фреймворк на C изобретают свои), и т.п.
butterflay labs это не китайский нонейм физик как это было у avalon, это конкретные люди с адресом и юр-лицом в правовом поле США, собрали они порядка 30кк $ и если они совершат откровенную лажу то их линчуют. Тем более что в прошлом году у них уже были успешные продажи спец-оборудования для майнинга на FPGA.
Другое дело, что они успешно могут мошенничать со сроками поставок! Даже самые оптимистичные прогнозы — заказы в марте будут обработаны не раньше сентября.
Железо у них есть, в этом плане они убедительны, вопрос правда в его количестве (12 из 72 пластин по 1к чипов к ним точно приехали), и проблемы у них вполне реальные — завышенное энергопотребление, из-за чего они не вписываются в спроектированный дизайн системы охлаждения (обещают что те, кто заказал 60GH получат две железки по 30GH, правда непонятно что с миниригами на 1.5TH).
p.s. в отличии от реального железа, у покупки долей есть дополнительная страховка от рисков — возможность их продать или наоборот купить.
А я бы волновался. Время простой реакции на ключевые слова по уму уже давно прошло. Сейчас время смысловых графов, и Щелково должно линковаться с месту и городу, а разные написания — всего лишь синтаксические ошибки и на выдачу совершенно не должны влиять, пока в запросе они не выделены кавычками. естественно.
Это решение из разряда 'bad practices'.
Очень много времени приложение, запускаемое по крону, тратит на 'восстановление состояния', конечно бывают задачи, когда для этого достаточно обычной БД, или когда таких данных очень мало. Но самое главное, работа по крону — это задержка в реакции демона на события.
А почему нет возможности контролировать уникальность идентификаторов самостоятельно? база размазана по нескольким узлам/серверам? а там обычный 'получить рандом в цикле до тех пор пока не будет уникальным' и число преобразовать в символы.
Ладно, если речь пошла про расширение структуры и алгоритмы работы с учетом большого количества серверов, обслуживающих базу данных:
Тут тоже есть варианты, вытекают из тех же вариантов.
0. Самая простая реализация размазывания базы счетов и транзакций по нодам — это привязать транзакции одного счета к своей ноде, тогда все алгоритмы становятся точно такими же как и в односерверной реализации, просто балансер, выбирающий нужную ноду должен по счету однозначно выбирать ноду за O(1), обычно это тупой хеш. Метд идеален, когда количество транзакций на счете значительно меньше количества счетов, иначе прирост в скорости за сет расширения количества нод будет не линейным.
1. Если же количество транзакций велико… Есть два вида задач, в одних, когда нужно ускорить получение остатка на счете и когда нужно быстро обрабатывать транзакции (у транзакции тоже есть моменты, транзакция создается отдельно от своего исполнения, и если есть возможность не проверять величину остатка на счете во время исполнения, например не превышает ли объем транзакции лимита на счете, то это тоже имеет смысл), и конечно ничто не мешает реализовать оба механизма:
a) ускорение исполнения транзакции: каждая нода хранит часть транзакций, т.е. один счет может быть размазан по нодам, на каждой ноде хранится информация о итоговой сумме транзакций в этой ноде, т.е. для получения остатка нужно обратиться ко всем нодам запросом.
Плюсы:
* при создании/исполнении транзакции трудоемкость O(1), затрагивается только одна нода (на самом деле тут влияет от алгоритма выбора ноды, но в общем это так)
Минусы:
* запрос на итоговое значение на счете затрагивает сразу все ноды, с трудоемкостью O(m), где m — количество нод (если конечно алгоритм выбора нод не позволит определить ее до запроса)
* при создании/исполнении транзакции необходимо пересчитывать и следить за итоговой суммой на ноде (кстати не вижу особых проблем, понятие тригеры и атомарные операции в виде транзакций хранилища есть у даже самых отсталых БД), а значит пока идет запрос к нодам, необходимо либо блокировать глобально операции по транзакциям соответствующего счета (это и есть глобальный лок на счет), либо делать как то поправку на текущие исполняемые транзакции с этим счетом на других нодах.
b) ускорение получения итоговой суммы на счете:
Решение вообще то самое простое — где то хранить и обновлять информацию о состоянии счета, не размазывая ее по нодам, т.е. для одного счета задействовать не больше одной ноды, то есть на каждой ноде дополнительная коллекция счет->итог. Для каждой транзакции в этом случае придется затрагивать от одной до двух нод (одна нода — это если итоговая информация о счете хранится на той же ноде, куда попала транзакция), но благодаря этому трудоемкость транзакции остается O(1), и при этом трудоемкость получения итога так же O(1) — затрагивает одну ноду.
2. Стоит напомнить, что хранение истории/архива транзакций и исполнение транзакций — это разные задачи, и использовать одни и те же структуры данных для них как минимум глупо. Почти наверняка требования при работе с архивом/историей отличаются от требований по работе с текущими/исполняемыми транзакциями (время исполнения транзакции — время необходимое чтобы информация о ней расползлась по нодам, даже если их всего две, а это время не только записи, но и ожидания, когда выполнится предыдущая). Отсюда напрашивается простое решение — для поддержания архива транзакций использовать алгоритм 0, а для текущих транзакций — 1.
Ничто не мешает сделать модуль работы с веб-сайтом на mono, а основную логику закодить на php, общение навести через ajax-http-запросы к localhost.
Вот скажите мне пожалуйста, какое именно из требований ограничивает в выборе языка? Мне на ум приходит только жесткие требования по оперативке, но известные мне удобные средства анализа html-dom на php кушают память так что дополнительный демон-прослойка на mono не будет заметен.
Без учета 'какой то программы' все описанное ложится на один день спокойной работы, бонус к скорости тут то, что приложения уже есть и работают, т.е. вопрос в установке и переносу настроек… какие недели, откуда?
p.s. привожу пример почти универсальной миграции на другой физический сервер старого за 1-2 часа (и то, это в основном проблемы с драйверами при смене платформы ну и +физическое копирование данных, если там сотни гигабайт то подольше получится) — это использование виртуальной машины.