Со сроками они конечно облажались, я уже почти было перестал надеяться, но вчера, наконец-то коробка поступила на склад LiteMF, и через 1-2 недели должна быть у меня :) Правда обошлось в 3 раза дороже (включая пересылку LiteFM $60, выяснилось что эта фигня может быть доставлена только USPS Express Mail).
А почему Highland только для коммуникации M и V? Где C? Просто у меня сложилась привычка связывать M и V через контроллер, и, чтобы они друг о друге не знали. У V иногда может быть своя M для внутренних состояний, он так же может быть слегка сам себе контроллер. Пример: блок с необязательными полями, который можно свернуть/развернуть. Тут есть Модель данных, которая мапится на поля ввода, и микромодель Вида с одним атрибутом скрыто/развёрнуто. V сообщает C об изменении полей, C может отправить изменения в M. Изменения M тоже слушает контроллер, и может при этом обновить V. А у вас как обычно устроено?
Кстати, хорошая идея для мильтитач-инструмента: рисование линии с толщиной зависящей от расстояния между пальцами :) Особенно на больших экранах было бы круто
О! Может вы мне ответите на этот вопрос о готовке ядер Solr-а? toster.ru/q/101767
С момента публикации вопроса ни одного ответа. Но за это время мне посоветовали перейти на ElasticSearch у которого конфиги на yaml/json, бинарник не требующий jre и другие плюшки.
И отредактировать комментарий не могу. Для тач устройств не подходит вешать события только на onclick для многих элементов. Самое простое и по-быстрому — делать $el.on(«click singleTap», ...), или touchStart
Года два назад меня посетила мысль, что в Django явно не хватает ещё одного слоя — «бизнес-логики». Сейчас понимаю, что вопрос гораздо глубже… Те кто пишет про всякие SOLID, DDD и пр. явно правее тех, кто выбирает между толстой моделью, толстым менеджером, толстым view, толстой формой или отдельным logic.py :)
Забавно, что к пониманию многих вещей меня подтолкнуло погружение в JavaScript, и, конкретно вот эта статья на Хбре. Знаю, в среде питонистов часто бытует религиозная ненависть к яваскрипту — абстрагируйтесь, почитайте, статья больше о понимании принципов чем о языке.
Вот тут можно посмотреть на js: sociation.org/static/js/sociation/compare.js
Там основная функция принимает как аргумент функцию сравнения. Они идут ниже. Чем ниже тем новее и лучше :) Самый простой и эффективный пока — последний comporator11.
Тогда проще на абсолютных числах:
— 500 и 1000 упоминаний (разность — 500, в 2 раза популярнее)
— 100500 и 101000 (разность 500, отношение 1.0049, т.е. «почти одинаково»)
Насчёт 1 и 2 — чем меньше частота, тем больше погрешность. Но нас же низкочастотные слова вообще не очень интересуют?
Если вечером будете экспериментировать, скину позже несколько формул
Если сортировать по разнице, то в одном списке будут слова характерные только для 1-го или только для 2-го ресурса, и не характерные для обоих одновременно. И то, разница в данном случае — это неверно. Нам ведь важно во сколько раз слово популярнее, а не на сколько (например 20%-10% = 10%, 100%-90% = 10%, при этом в первом случае популярность выше в 2 раза, а во втором в 1.111...).
Я когда рассуждал, придумал такую простую визуализацию. 2 оси, по одной — популярность слова в первом списке, по второй — во втором. Пусть они нормированы [0:1], тогда слова около «точки» 1,1 — это максимально популярные общие для 2-х ресурсов слова, 1,0 — характерные для 1-го, и 0,1 для второго ресурса. Вроде всё просто, нужно только правильно поделить плоскость на 3 группы (например популярные слова Хабра, Лепры и обоих одновременно). Остаётся вопрос — как именно это сделать наиболее правильным образом :)
А как вы решили задачу: есть 2 списка чего-то по популярности, нужно найти самое популярное из списка 1 при этом не популярное в списке 2 (и наоборот, соответственно)?
Я просто несколько раз сталкивался с подобной задачей в общем виде (например сравнение ассоциаций к двум словам на Sociation), находил несколько удовлетворяющих меня решений, но все они какие-то «нестопудовые» и мало математически обоснованы.
Или вы просто взяли какой-то порог, типа меньше 5-и употреблений, значит его нет?
Ради справедливости хочу заметить, что на StackOverflow довольно высокий порог входа. Там очень мощная репутацационно-кармическая система, гораздо мощнее чем у Хабра. Так что, насчёт уменьшения барьера я с вами не соглашусь.
Хорошая идея с релевантными вопросами в сайдбаре, единственная проблема — большая конкуренция на этот блок. Чего там уже только нет.
Ещё и QA, на мой взгляд, не очень удобный дизайн собранный из элементов обычной публикации.
Подброшу вам в копилку идей. В бутстрапе всего 7 основных цветов, всё остальное — их вариации. Ну, ещё вероятно опция тёмный на светлом / светлый на тёмном для фона. Было бы здорово плясать от цветовой схемы (собственной, или с того же kuler и подобных). Тема перекрашивает весь бутстрап, а дальше уже можно кастомизировать отдельные элементы.
Из тех сервисов что я видел выделяются 2 полярных типа: либо почти полная кастомизация, либо готовые стили. Мне видится полезным именно какой-то промежуточный вариант. Несколько настроек меняющие весь стиль (например основные цвета, ч/б фон, шрифт, размер шрифта маленький/большой/средний, радиус скругления уголков), а дальше более глубокая кастомизация, если требуется.
Мне подход FRP очень понравился. В какой-то момент разных событий и промисов становится так много, что напрашивался какой-то новый подход.
P.S. Спасибо за библиотеки, отличная подборка!
С момента публикации вопроса ни одного ответа. Но за это время мне посоветовали перейти на ElasticSearch у которого конфиги на yaml/json, бинарник не требующий jre и другие плюшки.
Забавно, что к пониманию многих вещей меня подтолкнуло погружение в JavaScript, и, конкретно вот эта статья на Хбре. Знаю, в среде питонистов часто бытует религиозная ненависть к яваскрипту — абстрагируйтесь, почитайте, статья больше о понимании принципов чем о языке.
sociation.org/static/js/sociation/compare.js
Там основная функция принимает как аргумент функцию сравнения. Они идут ниже. Чем ниже тем новее и лучше :) Самый простой и эффективный пока — последний comporator11.
— 500 и 1000 упоминаний (разность — 500, в 2 раза популярнее)
— 100500 и 101000 (разность 500, отношение 1.0049, т.е. «почти одинаково»)
Насчёт 1 и 2 — чем меньше частота, тем больше погрешность. Но нас же низкочастотные слова вообще не очень интересуют?
Если вечером будете экспериментировать, скину позже несколько формул
Я когда рассуждал, придумал такую простую визуализацию. 2 оси, по одной — популярность слова в первом списке, по второй — во втором. Пусть они нормированы [0:1], тогда слова около «точки» 1,1 — это максимально популярные общие для 2-х ресурсов слова, 1,0 — характерные для 1-го, и 0,1 для второго ресурса. Вроде всё просто, нужно только правильно поделить плоскость на 3 группы (например популярные слова Хабра, Лепры и обоих одновременно). Остаётся вопрос — как именно это сделать наиболее правильным образом :)
Я просто несколько раз сталкивался с подобной задачей в общем виде (например сравнение ассоциаций к двум словам на Sociation), находил несколько удовлетворяющих меня решений, но все они какие-то «нестопудовые» и мало математически обоснованы.
Или вы просто взяли какой-то порог, типа меньше 5-и употреблений, значит его нет?
Хорошая идея с релевантными вопросами в сайдбаре, единственная проблема — большая конкуренция на этот блок. Чего там уже только нет.
Ещё и QA, на мой взгляд, не очень удобный дизайн собранный из элементов обычной публикации.
Подброшу вам в копилку идей. В бутстрапе всего 7 основных цветов, всё остальное — их вариации. Ну, ещё вероятно опция тёмный на светлом / светлый на тёмном для фона. Было бы здорово плясать от цветовой схемы (собственной, или с того же kuler и подобных). Тема перекрашивает весь бутстрап, а дальше уже можно кастомизировать отдельные элементы.
Из тех сервисов что я видел выделяются 2 полярных типа: либо почти полная кастомизация, либо готовые стили. Мне видится полезным именно какой-то промежуточный вариант. Несколько настроек меняющие весь стиль (например основные цвета, ч/б фон, шрифт, размер шрифта маленький/большой/средний, радиус скругления уголков), а дальше более глубокая кастомизация, если требуется.