Show Posts
|
Pages: [1] 2 3 »
|
А чем мы вам так не понравились. Вот лично все мои заказчики/коллеги довольны моей работой. Но и уж извините не как офисный планктон я зарабатываю. Если кому нужна команда способная реализовать качественно сложный проект. Пишите в ПМ. Готов бесплатно реализовать хорошую идею)
Боюсь, но найти логику в постах tvv будет довольно проблематично. Посему, стоит рассматривать сей вопрос лишь со стороны своего мнения)
|
|
|
Госпади, что вы несете!? Человек предложил идею, причем предложил её публично, мы взялись за реализацию в рамках своей системы. Какие деньги, что за бред!? Идея не стоит НИЧЕГО! Стоит её реализация, да и с чего вы решили, что Golobog не в доле?)
|
|
|
Хотелка следующая: понять на фига мою идею делают без меня. На фига спрашивают у людей че нужно, когда спрашивать нужно у меня, так как идея моя и есть план дальнейшей разработки. Жесть какая-то ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) ну яж спросил у тебя, ты мне сказал что хочешь увидеть. давай тогда снова в личку))
|
|
|
Сделайте личку для людей и пускай в настройках будет показывать в рейтинге свои данные или нет. Можно таблички прирост за месяц, посчитанный в BTC/USD. Можно сделать сводную табличку внесено LTC/USD/BTC выведено / Остаток
принято! добавили в туду лист
|
|
|
Так и где же веб-морда?)))
веб морда для добавления ключиков будет выкачена в выходные, во время плановых обновлений. До этого пока собираем хотелки ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
Всегда веселили высказывания о "тупом SQL", который "не нужен". Господа специалисты по реляционным СУБД, да будет вам известно, что самая большая и нагруженная БД в мире работает на PostgreSQL. ты думаешь там внутри поле интерпретации скл-запроса там не куча циклов-выборок?? ошибаешься
Выполнение SQL запроса уже лет 30 как перестало быть просто интерпретацией. Вылезай из криокамеры. ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) По сабжу же ответ прост - шары можно посчитать на лету, не сохраняя их куда бы то ни было. Или же обрабатывать текстовые логи, используя традиционные средства для работы с текстом. И работать это будет в сотни раз быстрее NoSQL или реляционных СУБД просто потому, что они не предназначены для такого рода примитивной работы. В БД нужно класть результаты, а не промежуточные данные. спасибо тебе добрый человек, за еще один аргумент
|
|
|
Резюме скинул бы что-ли. Нужна реализация фикс протокола, интересно?
|
|
|
В данный момент, это работает в виде двух кластеров и вся веб-морда, которая у них есть, это только управление системой текущей. Хочу на один из серверов добавить еще мордашку для добавления ключей. Сейчас хочется определиться в каком виде это вообще люди хотят видеть. Так что пока только ментально)) В выходные будем обновлять код на серверах, соответственно зальем и сие.
|
|
|
Начали внедрять. В ближ время выложим форму для регистрации-добавления ключей. На наших мощностях текущих, добавить парсинг еще и сделок по ключам не сильно нагрузит систему. В идеале, хотелось бы услышать мнение от людей, насчет дальнейшей статистики сего?
в случае, если человек добавляет ключ с права торговли, ему выдается еррор, в случае, если человек открывает права торговли на ключе, ему на почту приходит еррор и ключ блокируется на парсинг. если в течении недели человек не изменил обратно права ключа только на сбор статистики, ключ удаляется из системы. Ребят, нам реально очень важно ваше мнение!
|
|
|
носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии
это не модненькие технологии а изначально все базы данных были такими - DBASE2 FOXBASE ... тупой SQL придумали для того чтобы лишний раз нагрузить комп и вынудить народ купить более мощной компьютер всегда ненавидел этот тупой sql Мощности возрастают, как следствие, появляется возможность обрабатывать более сложные конструкции. Дак почему вместо того, чтобы делать десять кей-валуе запросов, не сделать один? Ах да, есть еще такой момент как целостность, ибо после получения десятого запроса нет никакой гарантии, что результаты первого до сих пор актуальные. Ставить локи на запись только ради того, что вытащить актуальные значения это путь в бездну. В один прекрасный момент, накопится такая очередь на запись, что даже мощное железо упадет на спинку лапками кверху. PS: ах да, еще. ни фокспро, ни иные xBASE движки не были кей-валуе, они были прекрасным примером реляционных субд своего времени.
|
|
|
ммм у них написано же внизу документации апи, каким образом стоит получать информацию. вы пробовали к публичной части собрать запрос аналогичный приватной части?
|
|
|
носкуль не панацея и сделан он был изначально совсем для иного, а как быстрое key=>value хранилище. Изменение архитектуры бд, вот куда стоит смотреть, а не юзать модненькие технологии
|
|
|
есессно. необходимые обороты необходимых средств довольно легко расчитываются, исходя из праздников, выходных и тд и тп. может чуть больший запас хранится
вот-вот, вот я и говорю - тока поведитесь на разводки программистов, и они вам такое напишут... (конкретные суммы называть нет смысла вообще - поскольку всегда осваивается ВЕСЬ бюджет, сколько бы его не было. Чтобы с этими разводками программистов бороться - надо требовать ТОЛЬКО GPL кода, тогда цена не будет расти всегда подбираясь к бюджету, а скорее всего выйдет сильно дешевле тк много готового есть) PS вон к битку полностью ВСЕ желающие имеют ПОЛНЫЙ доступ, и че это кому-то помогло что-то спереть?.. Так что хоститься можно хоть на сервере врага, пофиг, если архитектура софта сразу продумана... бла-бла-бла
|
|
|
Вообще-то, я думал на нормальных сервисах, в онлайне висит только часть средств для дневного оборота, а все остальное переведено в офлайн кошелек. При необходимости онлайн кошелек пополняется. Даже если хакеры и взломают биржу , то при правильной организации процесса потери будут минимальны. Основная проблема это нормальный ввод-вывод денег, такой чтобы был удобен для трейдера.
есессно. необходимые обороты необходимых средств довольно легко расчитываются, исходя из праздников, выходных и тд и тп. может чуть больший запас хранится
|
|
|
свой сервер на атоме в квартире, моментальный синк после коммита на удаленный гит на вдс, плюс ежедневная шифрованная копия в дропбокс. я не параноик, я уже ученый и опытный(всмысле мегажопа какой большой пушной зверек в гости приходил) ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) до тех пор, пока не требуется CI это гут, у нас тоже в офисе стоял) зато когда начали внедрять тестирование по полной, и надо было делать тест кластер, хапнули сильно) Теперь гитхаб и кластера на AWS
|
|
|
Пришел квазиспециалист tvv и все разрулил. Так приятно становится нам, жабокодерам, что есть такие замечательные люди. И все они знаеют, и везде они были, и про всех они знают. Прямо кладезь знаний. Только почему-то кроме сотрясания воздуха никаких действий от них не видно, но это наверное только пока. Потом когда нибудь они обязательно взорвут.
Топикстартеру советую сначала ознакомиться с мат частью, потогровать самому маленькими суммами (или не очень) на ибржах, понять плюсы-минусы.
|
|
|
Может слишком часто запрашиваете? Либо есть вариант два, что эти данные формируются именно при подстановке хедеров с подписью и ключем авторизации. На странице описания АПИ, есть пример внизу формирования запроса
|
|
|
Довольно приличный кусок уйдет в сервера и техническую составляющую, которая позволит более-менее нормально масштабироваться в дальнейшем. Насчет цифр да, примерно такая сумма и выйдет
|
|
|
У нас все с точностью наоборот, идет постоянная обработка big data пласта, посему критичность хранения данных их избыточность перекрывают все. зато AWS можно очень неплохо масштабировать с ростом сервиса.
|
|
|
10 приватных репов - 25 долларов. Более чем доступно.
|
|
|
|