Обновить
15
Виталий Дятлов@xytop

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

3
Подписчики
Отправить сообщение

В таком приложении удалить базу не страшно :)

За такую 10% такой зп можно иметь карманного индуса за океаном, которому аутсорсить всю свою работу :)

Парсинг продукта заключается в парсинге микроразметки?

Я и не говорил что он плохой, трекер хороший. Но используется он в купе с проектом (без отрыва от кода). Создавать проект на github ради Issues это как гвозди микроскопом забивать, мое мнение.

Во-первых, Глупо использовать github исключительно как bug tracker, есть более подходящие инструменты.
А во-вторых, я думаю, что если администраторам сильно захочется, они могут добавить на сайт виджет типа uservoice, что гораздо удобнее в плане UX.

Я 8 лет на одном месте проработал.
Несколько раз пытался уволиться, но все заканчивалось звонком шефа и повышением зарплаты…
В последний раз поставил шефа перед фактом, что рабочее место новое уже найдено и ни под каким соусом не остаюсь, он согласился, но попытки вернуть не оставлял ещё несколько месяцев.
Условия были хорошие, но никакого профессионального роста не чувствовалось абсолютно, казалось что как программист я сдуваюсь.

А как насчет такого алгоритма:
Программа показывает 10 иконок.
Пользователь смотрит на иконки и жмет на кнопку с количеством иконок, которые он выбрал ("0", "1", "2 и больше"). Это повторяется, скажем, 5 раз. Если все 5 раз пользователь ответил верно, значит аутентификация прошла.

Размер файла. У вас 10 мегабайт, а там 600 килобайт всего. Не знаю правда сколько нейронов там используется на выходе.

Интересно, что размер модели меньше более чем в 10 раз при лучшем качестве :)

После определения показывается отмасштабированная картинка приведенного исходника ( 28х28 пикселей).
Каждое новое определение снова меняет масштаб, отсюда и разница.

Использование регулярок сильно лишнее в таком просто методе, замедляет его без нужды.
Если сильно хочется их использовать, то нужно кешировать.


Как-то так:


var isPalindrome = function(){
    var invalidCharsRgx = /^[a-z0-9]/ig;
    return function(){ /* ... */ };
}();
Точно уже не помню, но после Портера и 's остаётся порядка 300к слов. Для достижения 80% коэффициент ошибки для блума должен быть 0.6 кажется… Короче я подобрал такой размер блума чтобы оно после архивации влезало в лимит, на тестах было 78-79 процентов.
Товарищ по работе сделал больше 81%, но он дополнительно вырезал длинные слова, в остальном алгоритм тот же
Как сделать 80%:
Убираем из слов все окончания 's, потом делаем
porter2+bloom+gzip
Профит.
У меня 76.3%, но я еще не оптимизировал толком…
Нужно смотреть логи редиса, там должно быть что-то по этому поводу.
Ну и еще maxclients для Redis надо увеличить за миллион :)
Не совсем правы Вы :)
  1. Одновременно соединений у вас больше, потому что после close не поставлены скобки. Функция без скобок в PHP не вызывается.
  2. Лимит надо ставить не на миллион, а больше, потому что есть еще другие системные процессы плюс сам редис под себя часть дескриптором забирает. Почитайте тут: http://redis.io/topics/clients

Попробуйте так задать:
`
ulimit -Sn 101000
sysctl -w fs.file-max=1001000
`
Я бы сказал, что это единственная деталь :)
Если выставить правильный лимит, то стабильность будет намного выше чем у TCP, ну и скорость конечно же.
Покажите вывод
cat /proc/sys/fs/file-max
Количество одновременно открытых UNIX-сокетов ограничено максимальным количеством файловых дескрипторов. Там у вас и сидит значение меньше миллиона. Его вы не изменили для теста, поэтому и ошибки полезли.
Нет, не виноват. Я про заголовок говорил :)

Информация

В рейтинге
Не участвует
Откуда
Тирасполь, Молдова, Молдова
Дата рождения
Зарегистрирован
Активность