Pull to refresh
5
0
Рустам @RustamS

Пользователь

Send message

Давно это было). Тогда и в http запросах пришлось разобраться и формат файлов китайских регистраторов реверсить, и с добавлением его декодирования в ffmpeg экспериментировать.

Позволяет ли указанный регистратор забирать видеофайлы с диска по HTTP/FTP? (нужна возможность удаленно скачать выборочно нужный фрагмент с камеры по дате)
Не понятно — как в этом кейсе используется блокчейн? Не увидел различий от публичной централизованной базы (в которой часть данных зашифрована пользовательским ключом).
Зашёл на Waves Explorer — там только одна нода (если правильно понял).
Получается что реестр не распределённый вовсе.
Если ошибаюсь — просьба пояснить, кто ещё участвует в распределённой системе и какой для них экономический смысл участия.

Можете посоветовать что-то для прочтения по customer developmnet? Интересует применение этих методик в дизайне на начальном этапе, когда ещё нет большой аудитории.
Используете ли gulp-watch? С ним часто происходят ошибки при создании/удалении каталогов, и gulp-plumber не подавляет их. Нет ли решения такой проблемы?
github.com/gulpjs/gulp/issues/660 github.com/floatdrop/gulp-watch/issues/83
Позволит ли нормальный тачпад одним движением перетащить указатель через весь экран с сохранением точности?
Или для таких действий на тачпаде всё равно придётся привыкать к нескольким движениям пальцем вперёд-назад?
Основная деятельность:
Банковское ПО. В частности АБС Колвир. Разработка под Oracle (PL/SQL). Автоматизация тестирования на HP QTP, UFT, LoadRunner.
В свободное время разрабатываю Web сайты и приложения JS (Angular,Jquery,Vanilla), PHP,Python и изредка для desktop/mobile.
www.facebook.com/rustam.sydykov.5
vk.com/rustamspl
Ещё интересуют вопросы:
1) «подсунуть очень большую историю куда сложнее чем пару блоков» — а если понизить сложность, корректируя предыдущую историю?
2) Гипотетический пример: Имеется крупный участник с большими вычислительными ресурсами (но значительно меньше 50% всей сети ). Он хранит всю историю транзакций и по частям предоставляет её большому количеству лёгких клиентов. Дополнительно является большим провайдером и имеет доступ к каналам связи. Насколько сложно ему будет обмануть клиентов в своей сети, подсунув фальшивую историю и заблокировав/перехватив обмен с внешней сетью?
3)Имеется ли ориентировочный прогноз по ожидаемому приросту размера базы?
4)Из вопроса 3 — может ли стать узким местом для работы Bitcoin у небольших участников скорость дисковых операций/поиск старых транзакций? И если да — то как скоро?

Можно подробнее про этот момент?
При инициализации ведь нужно прокачать все транзакции? Иначе нам могут подсунуть фальшивую историю.
Со временем обычным пользователям скачать всю историю станет крайне проблематично (рост популярности, большее количество транзакций за период, значительное увеличение размера базы).
Возможно, большинство будет использовать облачные сервисы, доверяя выданному хэшу последнего блока.
В этом случае облачные сервисы теоретически смогут обманывать пользователей?
И как проверять баланс какого-нибудь кошелька, не имея всей истории?

Интересно было бы узнать принцип действия этих радиоуправляемых ножниц.
А как процесс перерезания веревки происходил?
Из-за лагов не смог посмотреть.
топик мало помогает понять, где и что именно нужно оптимизировать.

Давайте попытаемся выяснить в комментариях.

На данный момент всё просчитывается в SQL запросах «на лету».
Уже есть предложения использовать словарь тегов с рейтингом.
Но вопрос остаётся открытым — как сохранить контекстнозависимость рейтинга?
Пока не могу придумать — как сделать контекстнозависимый рейтинг тегов с использованием словаря с рейтингом?

И ещё вопрос — как оцениваете контекстнозависимый рейтинг в поиске?
Действительно ли удобно?
Изначально пытался самостоятельно завершить и выпустить проект (более полугода назад).
Но натолкнулся на вышеописанные проблемы и всё остановилось.
Цель публикации — попытка сдвинуть проект с мёртвой точки.

Изначально начал писать на Jquery ajax.idhost.kz/tag_v0/.
Но эта версия тормозила на моём старом компе. В итоге решил заоптимизировать
клиентскую сторону и написать на чистом JS. Сделал свой минифрейворк. IMHO вышло не намного сложнее.
Возможно, что-то из моего кода пригодится кому-то из читателей. Готов ответит на все вопросы.

По оформлению — буду исправляться. Надеюсь сильно не осудите.
По кэшированию:
на данный момент рейтинг определяется контекстом текущего запроса т.е. набором уже введенных тегов.
Хранение пар (контекст, тэг)=>рейтинг займёт очень много места, по сравнению с самими тэгами.

Целесообразно ли?

По поводу морфологии и значения слов — существуют ли автоматические алгоритмы, или придётся заводить словарь малозначимых слов?

Хотелось бы добиться максимальной автоматизированности процесса.
Пока приостановил добавление — система стала превращаться в чат.
Основная суть всё же в поиске.
Ни смотря ни на что жду коментариев.
Обнаружил ошибки в коде. Чуть поправил.
Спасибо twix-у.
У меня бывало похожее из-за перегрева штекера- вздувалась пластмасса между контактами. Приходилось срезать/обтачивать.
Есть желание освить Zend Framework, но после Codeigniter-a,Kohana и YII смущает
размер фрейворка (несколько десятков мегабайт).Возможно ли как-то
отделить от него только необходимые, используемые классы, чтобы зря не загружать на сервер? Предполагаю, что на начальном этапе мне не понадобится всё их разнообразие.
1

Information

Rating
Does not participate
Location
Казахстан
Registered
Activity