Ребята, очень круто и интересно будет посмотреть. Но насчёт того, что первая в мире поспорю — мы в https://github.com/paysuper предоставляем пока меньше того, что есть у вас, но это готовый процессор с формами, онбордингом, дашбордом. Написан на golang + vuejs — порог вхождения имхо сильно проще элексира. Работает в кубере или AWS.
Я ни разу не встречал, чтобы 100к+ просили денег. Денег хотят в диапазоне 10к-30к — большинство тех, кто работает по коммерческим оферам ничего не дают: аудитория накачана левая или активность и конверсии аудитории нулевые.
Да, я об этом тоже напишу. Сейчас, кратко, не менее 2,000 проданных копий в регионе в сутки, чтобы быть в топ-20. Влияет только число продаж, топ продаж для каждого региона свой.
Показы для старта дают — это напрямую зависит от количества людей в wishlist до начала продаж, отзывов и их числа. В том числе динамика продаж за первые дни после старта.
Они начиная с 3.0.3 наконец-то отказались от dlmalloc в пользу jemalloc и порт стало реально рассматривать для боевого применения. С другой стороны там какой-то ад с тем как они обошли fork для сохранения данных на диск. Разработчики порта называют его point-in-time heap snapshot. Они там здорово заморочились — я давно смотрел описание, как это сделано, в исходники глубоко не заглядывая. Самая спорная часть при использовании на бою — при сохранении они могут «выжрать» до 3-х раз больше памяти, чем нужно linux версии. При этом такое поведение считается нормальным, т.к. swap файл в windows легко может быть до 3-х раз больше, чем реальное количество оперативной памяти. Как по мне — это приемлемо только если использовать Redis под LRU cache или не использовать сохранение вовсе.
Поймите, я не хочу сказать, что решения нет. Я хочу сказать, что в соседнем огороде (в том же тарантуле) люди обошлись без костылей. И в редисе могли бы. Проблемы с репликой и LUA были ещё на этапе alpha preview, то, что будут ограничения было понятно ещё до выхода фичи в их стабильную ветку. Я настаиваю на том, что разработчиками стоило бы поправить проблемы в проектировании репликации вместо цикла решений об ограничении функциональности скриптовой части. В любом случае мы с вами про одно и тоже, просто немного с разных сторон.
Я понимаю как работает репликация, ровно как и ограничения с этим связанные. Попробуйте посмотреть на это с такой стороны. Сразу после релиза 2.6 (в котором добавили LUA) сразу же подняли вопрос и про RANDOMKEY и про SRANDMEMBER. Это весьма логично, т.к. сама структура SET подразумевает, что вам для широкого спектра бизнес задач нужно получать из неё N случайных элементов (не даром в 2.6 в эту функцию добавили второй аргумент — количество случайных элементов). Когда впервые поднимался этот вопрос Сальваторе предлагали альтернативу с тем, чтобы переписать репликацию для SET с тем, чтобы свести внутреннюю структуру SET на слейве и мастере — тогда возможно было бы обращаться к элементам сета по индексам. Он ответил в духе — «Это не возможно». К чему я так цепляюсь к этому случае — в редис почти всё так. Смотрите, я отвечаю (и читаю) вопросы по редису на stackoverflow. Аудитория продукта (а редис продукт, который Сальваторе продаёт) часто задаёт вопросы, ответ на который — используйте уникальный список с произвольным доступом. Т.е. или в LIST возможность взять индекс по значению (LRANK request) или в SET получить аналог LRANGE (простите на память не помню как назывался тикет на гитхабе). И тогда можно на LUA можно эффективно решать этот класс задач. И на оба вопроса ответ — «Напишите как нить сами на LUA». Это, имхо, вопрос отношения показывающий отношения основного мейнтейнера в своему продукту. К слову, в том же Tarantool Костя Осипов с командой идёт от решения конкретных проблем и кейсов своих пользователей, вместо отсылок в случае редиса. Как и в 2.8 (поправьте если путаю) вхерачили Global variables protection в LUA — на все вопросы оставьте хотя бы в конфиге шанс выключить это ответ «Не, а то вдруг что». Только не дали в замен никаких вариантов шарить между скриптами вспомогательные функции (а их, к слову, превиликое множество получается при написании чего-то длиннее пары строчек). Простите, накипело.
Да, вы правы. С какой логикой это сделал Сальваторе понятно и я считаю, что это скорее ограничение корявой реализации репликации/интеграции LUA для части команд. К примеру встроенный генератор случайных числе из самой LUA вам доступен. И часть танцев с бубном вокруг SRANDMEMBER так и работает — получите весь список, кидайте кубик в LUA и формируйте таблицу выдачи. В redis много такого — в конкретной фиче всё супер, но чего-то, самую малость, не хватает.
Важно ещё помнить про то, что в Lua у вас есть доступ не ко всем функциям редиса. К примеру нельзя использовать SRANDMEMBER, что фактически не позволит вам писать процедуры с логикой «Вернуть N случайных значений из SET» или семейство SCAN функций. Т.е. скажем сделать какой-то аналог «воркера», который выполнит операцию над семейством ключей или полей в LUA не выйдет. Помните, что у вас не будет человеческой отладки, если вы решили писать что-то действительно сложное, что до сих пор нет нормальных библиотек для тестирования LUA процедур. Насколько я знаю ни на одном языке (хорошая идея для проекта на гитхаб). Это совсем не обычная ситуацию, но помните про ограничение с LUAI_MAXCSTACK. Помните, что любые битовые операции в LUA удивят вас тем, что при поддержки 64 битных целых чисел все битовые операции ограничены 32 битными со знаком. Помните, что фактически у вас нет скриптов, если вы используете кластер, т.к. нет авто переадресации запросов на соседние ноды. LUA в редисе прекрасно позволяет решать огромный спектр вопросов, но это совсем не панацея.
Да, практически с момента его выхода. До этого использовали сатис и для внутренних пакетов и для наиболее часто используемых важных внешних. Был какой-то период когда у нас постоянно были проблемы то с доступностью гитхаба, откуда тянулось пара наших открытых пакетов, потом был период с недоступностью или лагами самого сайта packagist.org. Это регулярно разбавлялось проблемами нашего основного провайдера в офисе. Торан реальная палочка выручалочка — всё равно есть интернет, нет интернета и что сейчас доступно, а что нет, всё стянется из локальной копии на его сервере. В целом — очень рекомендую.
C сатисом не удобно то, что добавлять пакеты нужно руками. Если хочется комфортного и прозрачного проксирования то лучше Toran Proxy — коммерческий аналог Satis от автора composer. Он автоматически умеет кешировать и обновлять пакеты, если его прописать как замену packinst.org. Он в таком случае всегда стягивает себе отсутствующие пакеты себе и отдает вам их из локального хранилища.
Да, действительно, с 3.5 появилась. Правда jira.atlassian.com/browse/STASH-2823 они пока даже не запланировали :( нас много QML в ревью, а для него имеющиеся в CodeMirror схемы не особо подходят. Насколько я понимаю, чтобы добавить кастомную подсветку нужно кинуть пул реквест в CodeMirror и ждать очередного релиза обоих продуктов или патчить сам stash? Вы не знаете?
Вы лукавите в той, части, где говорите о ветвлении. У вас есть возможность выбрать тип автоматического flow, которое поддерживает stash — gitflow, forking (feature branch собственно его разновидность). Часто gitflow совершенно избыточен. По большому счёту flow в stash даёт вам только созданные автоматически ветки (вы сами выбираете, что вам нужно). Вся прелесть их открывается при использовании вместе с jira — вы в 1 клик можете создать ветку для решения проблемы или создания новой фичи. При этом имя ветки формируется на основе версий в которой проблема найдена и в какой версии планируется релиз. Всё вместе позволяет включить автоматический merge для gitflow (на текущий момент, насколько знаю работает только для него). В том числе очень удобная история с тем, что смерджив реквест вы можете настроить автоматические закрытие тикета в джире.
В stash можно запретить прямые комиты в ветки — и в 2 и 3 версиях. Это делается в branch permissions.
Чем сейчас stash не удобен:
— если ваши ревью затрагивают несколько проектов, то fisheye предпочтительнее, т.к. ревью в stash это только возможность оставить свои комментарии к пул реквесту. Не более того.
— в stash ваши комментарии удаляются из текста файла в diff после любого комита, затрагивающего этот файл. Фактически это приводит к тому, что в не можете эффективно посмотреть, исправлено ли ваше замечание или что писали другие ваши коллеги. Т.е. к примеру вы в троем оставили в файле 4 комментария, автор исправляет замечание по одному из них и комитит. Всё, все остальные комментарии ему и читателям доступны только в activity stream.
— в stash по прежнему нет цитирования кода в комментариях — нужно копировать и вставлять куски руками.
— в stash по прежнему нет возможности посмотреть диапазон комитов в файле. Только «было» и «стало». Возможно я просто зажрался, но когда смотришь большие объемы изменений этого очень не хватает.
— из серии «очень хотелось бы» это подсветка синтаксиса, которая очень помогает в fisheye. Plain text и код с подсветкой всё таки совсем разная степень удобства. Подсветки синтаксиса в stash сейчас нет, есть классическая подсветка «удаленный фрагмент» и «добавленный фрагмент» для дифа.
Я считаю, что рассматривать stash как отдельный инструмент для ревью кода рановато. Как реализация git scm он просто прекрасен. В нём с самого начала есть (и остаются) проблемы с большими репозитариями (очень выжирает память на клоне и пуле), но всем всё равно советую попробовать.
p.s. Сами для ревью используем и fisheye и stash. Stash для небольших пул реквестов, fisheye для больших изменений или случаев, когда 1 тикет затрагивает более 2-3 репозитариев.
Дело в том, что большая часть «расходов» ляжет именно на отправку и получение ответа от redis. Выполнение этих запросов внутри контекста redis сервера существенно быстрее их же выполнения из клиентского скрипта и помогает немного сэкономить — используя LUA вам уже не нужно использовать MULTI запросы.
Все круто. Вы молодцы! Будем дружить домами ;)
Ребята, очень круто и интересно будет посмотреть. Но насчёт того, что первая в мире поспорю — мы в https://github.com/paysuper предоставляем пока меньше того, что есть у вас, но это готовый процессор с формами, онбордингом, дашбордом. Написан на golang + vuejs — порог вхождения имхо сильно проще элексира. Работает в кубере или AWS.
Вы лукавите в той, части, где говорите о ветвлении. У вас есть возможность выбрать тип автоматического flow, которое поддерживает stash — gitflow, forking (feature branch собственно его разновидность). Часто gitflow совершенно избыточен. По большому счёту flow в stash даёт вам только созданные автоматически ветки (вы сами выбираете, что вам нужно). Вся прелесть их открывается при использовании вместе с jira — вы в 1 клик можете создать ветку для решения проблемы или создания новой фичи. При этом имя ветки формируется на основе версий в которой проблема найдена и в какой версии планируется релиз. Всё вместе позволяет включить автоматический merge для gitflow (на текущий момент, насколько знаю работает только для него). В том числе очень удобная история с тем, что смерджив реквест вы можете настроить автоматические закрытие тикета в джире.
В stash можно запретить прямые комиты в ветки — и в 2 и 3 версиях. Это делается в branch permissions.
Чем сейчас stash не удобен:
— если ваши ревью затрагивают несколько проектов, то fisheye предпочтительнее, т.к. ревью в stash это только возможность оставить свои комментарии к пул реквесту. Не более того.
— в stash ваши комментарии удаляются из текста файла в diff после любого комита, затрагивающего этот файл. Фактически это приводит к тому, что в не можете эффективно посмотреть, исправлено ли ваше замечание или что писали другие ваши коллеги. Т.е. к примеру вы в троем оставили в файле 4 комментария, автор исправляет замечание по одному из них и комитит. Всё, все остальные комментарии ему и читателям доступны только в activity stream.
— в stash по прежнему нет цитирования кода в комментариях — нужно копировать и вставлять куски руками.
— в stash по прежнему нет возможности посмотреть диапазон комитов в файле. Только «было» и «стало». Возможно я просто зажрался, но когда смотришь большие объемы изменений этого очень не хватает.
— из серии «очень хотелось бы» это подсветка синтаксиса, которая очень помогает в fisheye. Plain text и код с подсветкой всё таки совсем разная степень удобства. Подсветки синтаксиса в stash сейчас нет, есть классическая подсветка «удаленный фрагмент» и «добавленный фрагмент» для дифа.
Я считаю, что рассматривать stash как отдельный инструмент для ревью кода рановато. Как реализация git scm он просто прекрасен. В нём с самого начала есть (и остаются) проблемы с большими репозитариями (очень выжирает память на клоне и пуле), но всем всё равно советую попробовать.
p.s. Сами для ревью используем и fisheye и stash. Stash для небольших пул реквестов, fisheye для больших изменений или случаев, когда 1 тикет затрагивает более 2-3 репозитариев.