• Websocket\long poling на rails, лучшая практика?

    MAXOPKA
    @MAXOPKA
    Месяца 2-3 назад написал чат с использованием этого замечательного гема. Суть в том, что параллельно с приложением, запускается Websocket-сервер, висит на определенном порту, и принимает входящие websocket запросы.
    Ответ написан
    3 комментария
  • Не помешает ли мне изучение PHP потом перейти на RoR?

    Freika
    @Freika
    Senior Ruby on Rails developer
    Отчасти поможет: что-то вы уже будете знать и уметь, а опыт лишним не бывает (практически никогда).

    Отчасти помешает: вы будете смотреть на какие-то общепринятые для Ruby/Rails соглашения и недоумевать: "Что за бред? А запилю-ка я лучше по-своему, как в старом-добром пхп делал". И вот это тот случай, когда опыт как раз бывает лишним. Хотя это не обязательно будет именно так, но вероятность есть.
    Ответ написан
    Комментировать
  • Как сделать так, чтобы функция выполнялась только после того, как другая завершится?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега JavaScript
    Дисклеймер
    Кому не нравится название "обещания", мысленно заменяйте его на то, которое считаете подходящим. Я выбрал именно его, чтобы концепция, лежащая в их основе, была интуитивно понятна.

    Если функция асинхронная, то лучше всего использовать обещания, что вы и попытались сделать (интерактивный пример).
    one().done(two);
    
    function one() {
        var dfd = new $.Deferred();
    
        // Запускаем асинхронную задачу. Например, ajax-запрос.
        setTimeout(function () {
            var foo = 'bar';
    
            // "Выполняем обещание", передавая в него какую-то информацию.
            // Передавать аргументы, разумеется, не обязательно.
            dfd.resolve(foo);
        }, 2000);
    
        // Возвращаем из функции обещание, на которое могут подписаться другие функции.
        // Обратите внимание, этот код выполнится до того, как завершится асинхронная задача.
        return dfd.promise();
    }
    
    function two(foo) {
        // Обрабатываем данные, полученные внутри асинхронной функции one.
        console.log('two', foo);
    }

    Для трех функций расклад немного сложнее, но принцип такой же.
    Есть и более элегантный способ запуска цепочки из трех функций:
    код
    one().then(two, onOneError).then(three, onTwoError);
    
    function one() {
        var dfd = new $.Deferred();
    
        setTimeout(function () {
            console.log('one');
            
            if (Math.round(Math.random() * 10) >= 5)
            {
                dfd.resolve();
            }
            else
            {
                dfd.reject();
            }
        }, 1000);
    
        return dfd.promise();
    }
    
    function two() {
        var dfd = new $.Deferred();
    
        setTimeout(function () {
            console.log('two');
            
            if (Math.round(Math.random() * 10) >= 5)
            {
                dfd.resolve();
            }
            else
            {
                dfd.reject();
            }
        }, 1000);
    
        return dfd.promise();
    }
    
    function three() {
        setTimeout(function () {
            console.log('three');
        }, 1000);
    }
    
    function onTwoError() {
        console.log('twoError', arguments);
    }
    
    function onOneError() {
        console.log('oneError', arguments);
    }

    Обратите внимание, что в этом примере показано, что обещания можно не только выполнять, но и отказываться от них и такие ситуации нужно обрабатывать отдельно.


    Обещания - самый современный и удобный вариант, с ними код становится чище и понятнее. Единственная проблема, связанная с ними - это необходимость использовать сторонние библиотеки или полифилы, потому что обещания пока поддерживаются далеко не во всех браузерах.

    Другой вариант - передавать callback, но это прямой путь в callback hell. Для запуска трех и более функций подряд я его не рекомендую - смотрите сами, на что становится похож код:
    one(function () {
        two(three)
    });
    
    function one(callback) {
        console.log('one');
        setTimeout(callback, 1000);
    }
    
    function two(callback) {
        console.log('two');
        setTimeout(callback, 1000);
    }
    
    function three() {
        console.log('three');
    }


    Есть еще один (очень, очень, очень плохой) вариант, основанный на таймерах и внешних флагах. Никогда так не делайте (код для системы из трех функций еще хуже).

    Если внутри функций ничего асинхронного нет, то можно просто вызвать их друг за другом - следующая и так запустится после предыдущей (пример).
    Ответ написан
    5 комментариев
  • А нужна ли переменная?

    In4in
    @In4in
    °•× JavaScript Developer ^_^ ו°
    workStrLength (12 символов) VS str.length (10 символов) выносить не стоит
    А вот когда так, грубо говоря:
    dDE VS document.documentElement.clientHeight, то, конечно, лучше записать отдельно.

    А вообще, такие мелочи делают код приятнее и удобнее для просмотра. Писать так, как вы - правильно, в каком-то смысле, так что не волнуйтесь :)
    Ответ написан
    2 комментария
  • Что не так с моими ответами по sql и как стоило бы ответить?

    Нормальные ответы. Проблема не в них, а в проводящем собеседование, имхо.
    Ответ написан
    1 комментарий
  • Как научиться писать такой ООП код?

    @Copperfield
    Android dude
    Мне в школе физрук говорил:"Чтобы много подтягиваться - нужно много подтягиваться".
    Ответ написан
    Комментировать
  • Стоит ли отказываться от JS в мобильных версиях сайта?

    aaadddminnn
    @aaadddminnn
    php it ubuntu debian
    наоборот аякс будет экономить трафик. Просто надо писать на "чистом" js
    В идеале вообще заюзайте HISTORY api
    Ответ написан
    3 комментария
  • React или Angular 2, ваши прогнозы?

    Почему люди продолжают сравнивать Angular с React'ом, это же разные вещи, "реакт" есть смысл сравнивать лишь с рендером "ангуляра", потому как "ангуляр" это fullstack фреймворк, а "реакт" библиотека для отрисовки. Это как сравнивать Tesla Model S с двигателем TSI, что как минимум странно.
    Ответ написан
    3 комментария
  • С чего начать школьнику 16 лет?

    Freika
    @Freika
    Senior Ruby on Rails developer
    С нуля и до "я уже кое-что могу" в Ruby и Ruby on Rails: frey.su/diving-into-web-development
    Подборка бесплатных курсов по Ruby и Rails, тоже в основном с нуля: onrails.club/t/kursy-po-ruby-i-ruby-on-rails
    Ответ написан
    Комментировать
  • С чего начать школьнику 16 лет?

    @pashwrs
    с англ языка стоит начать
    Ответ написан
    Комментировать
  • Нагрузка когда с sqlite нужно уходить?

    Stac
    @Stac
    У SQLITE проблемы могут быть только с записью. Там ведется специальный журнал, что может тормозить. Но его можно отключить. Наверняка есть еще куча настроек.
    Еще можно использовать очереди на запись, если это приемлемо.

    Я делал системы учета трафика, где по 10-20 тыс. переходов в день (с тизерных сетей) записывалось в базу нормально. Правда длился это эксперимент всего неделю.

    Другой опыт с меньшей нагрузкой (до несколько тысяч переходов день) живет третий год с более млн. записей.

    Не знаю, насколько вам будет это полезно.

    И да, SQLITE это полноценная СУБД, только встраиваемая, а не клиент-серверная. Хотя есть и сервера для SQLITE, да и свой сервер можно написать под конкретную задачу, если приспичит.
    Ответ написан
    Комментировать
  • Как правильно разработать легкомасштабируемую платёжную систему?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. Скрипт на крон - однозначно плохая идея. Более правильная история - постоянно работающий скрипт который из очереди получает очередную задачу. Отличный вариант для организации очереди rabbitmq

    2. Слабая связанность компонент это хорошо. В вашем случае однозначно api (не очень правда понимаю метания от php к java но дело Ваше. пишите на том, что лучше знаете) + расширяемые апи для внешних интеграций + интерфейсы цепляемые к апи.

    По поводу синхронности/асинхронности - это вполне можно уместить в одном апи. Какие методы делать синхронными, какие нет - целиком зависит от вашей бизнес логики.
    На мой взгляд получение баланса например вполне можно сделать синхронным.

    3. С точки зрения быстродействия - Вы достаточно быстро упретесь в базу. Соответственно надо сразу думать о шардировании данных, о том как система будет себя вести в случае выхода из строя одной из задействованных в транзакции нод итд.

    4. Вам важна data consistency. Сразу думайте про железо. Любые сервера горят. Брендовые сервера горят точно так же как и не брендовые. С учетом п3 - я бы делал полностью независимые друг от друга ноды, с физическим дублированием внутри ноды, и привязывал каждый счет к одной ноде.

    5 [философский] Поймите важный момент - без ОЧЕНЬ серьезных инвестиций в маркетинг, проекты не взлетают. Если бы эти инвестиции были - Вы бы тут не писали (не в обиду). Соответственно вероятность того что к Вам внезапно придет огромный поток транзакций - стремится к нулю. К тому моменту когда Вы раскрутитесь - Вы успеете 5 раз сменить архитектуру проекта. Нельзя иметь одну архитектуру у стартапа собранного одним человеком, и у проекта с высокими HL/HA.
    Пишите на чем нравится, у Вас будет куча времени что бы переписать узкие места например на C.

    6 [юридический] Вы в курсе что Вам нужна пачка лицензий на осуществление деятельности в качестве оператора электронных денег и денежных переводов без открытия банковского счёта? :)

    PS Я хочу верить что Ваш вопрос - это задачка для саморазвития. Иначе я не представляю себе что это за система платежная, которую делает один человек, спрашивающий совета как делать такие штуки (опять же не в обиду Вам ) :)
    Ответ написан
    Комментировать
  • Как реализовать рекомендательную систему по формуле Байеса?

    barmaley_exe
    @barmaley_exe
    Видимо, речь идёт о наивном Байесовском классификаторе.

    Во-первых, поставим проблему чуть иначе: вместо рекомендациях следует говорить о классификации на 2 класса (нравится или не нравится).

    Далее, наивный Байесовский классификатор основывается на 2 идеях: собственно, Теорема Байеса и условная независимость признаков объектов.

    Пусть P(like|x) — вероятность того, что данному пользователю понравится объект x, описывающийся характеристиками x1, ..., xn. Эти характеристики могут быть совершенно произвольными, не обязательно одного "типа". Вопрос лишь в том, какое вы зададите на них распределение. Очевидно, что если вероятность P(like|x) > 1/2, то вероятность негативной оценки будет меньше, а значит, нужно предсказывать "нравится". Таким образом, нашей задачей является оценить вероятности P(like|x) и P(dislike|x) (которая, в свою очередь равна 1-P(like|x), поскольку сумма вероятностей равна 1) и выбрать наибольшую.

    Тут самое время применить теорему Байеса:

    P(like|x) = P(x|like) P(like) / P(x) и P(dislike|x) = P(x|dislike) P(dislike) / P(x)

    Примечательным фактом является то, что знаменатель мы можем проигнорировать, ведь он один и тот же для P(like|x) и P(dislike|x), а нас интересует только соотношение между этими числами, а не они сами. Тогда сравнивать мы будем P(x|like) P(like) и P(x|dislike) P(dislike). В данном случае P(like) выражает наши априорные знания о том, насколько вероятно, что объект понравится пользователю. Если таких знаний нет, можно смело брать 1/2.
    P(x|like), в свою очередь, описывает, насколько вероятно встретить такой объект в классе понравившихся. Вся наивность рассматриваемого классификатора заключается именно в моделировании этого распределения.

    Поскольку вероятность P(x|like) может зависеть от x самым причудливым и произвольным образом, нам нужно сделать какое-то предположение. В случае наивного Байесовского классификатора этим предположением выступает ничем не подкреплённая гипотеза условной независимости признаков объекта при заданном классе, то есть: P(x|like) = P1(x1|like) ... Pn(xn|like). Здесь Pk — произвольное распределение, оно может быть как дискретным (цвет или тип, в Вашем случае), так и "непрерывным" (клиренс). Данные распределения должны быть выбраны разработчиком классификатора. Обычно они содержат какие-то параметры, которые мы в дальнейшем настроим по данным с помощью метода максимального правдоподобия. Для многих распределений оценки можно выписать аналитически. Например, для дискретных признаков можно посчитать эмпирическую частоту значения (плюс сглаживание для тех объектов, которые пользователь ни разу не видел), а для нормального распределения посчитать выборочное среднее и дисперсию.

    Резюмируя, ответы на Ваши вопросы:

    1. Формула Байеса имеет такое же отношение к Байесовскому классификатору, какое дерево к столу. Да, формула используется, но это ещё не всё.

    2. Про известные подходы ничего не скажу, но на ум приходит следующее: при классификации можно сравнивать не произведение вероятностей, а его логарифм (благодаря его монотонности) log(P1(x1|like) ... Pn(xn|like)) = log(P1(x1|like)) + ... + log(Pn(xn|like)). Чем больше эта сумма — тем больше вероятность лайка. Можно попробовать взвесить эти слагаемые.

    3. На отдельные признаки можно задавать произвольные распределения, например, нормальное для численных значений.

    Теперь о проблемах: вышеописанный подход хорош, но обладает существенным недостатком: если применять её ко всем пользователям без разбору, то получится модель среднего пользователя, которое будет рекомендовать всем одно и то же. Фишка же рекомендательной системы заключается в персонализации. С другой стороны, если строить по байесовскому классификатору на пользователя, скорее всего, Вам не хватит данных для получения каких-либо значимых результатов. Со второй проблемой можно бороться, если принять во внимание существование похожих пользователей: Если Алиса заинтересовалась объектами {A, B, C, D}, а Борису понравились {B, C, D, E}, то наивный Байес либо усреднит их со всеми остальными (представим, что существует 1000 пользователей, заинтересовавшихся объектом P. Тогда его "вес" будет существенно больше, но только лишь благодаря его популярности, а ведь для нахождения наиболее популярных объектов хватит и простой сортировки), либо построит для обоих по собственному классификатору, даже не подозревая о том, что эти пользователи похожи. Одним из подходов, учитывающих это, является коллаборативная фильтрация, наиболее активно используемая в задачах рекомендации.
    Ответ написан
    Комментировать
  • Интересно, как научить CRM перезванивать номера и проверять сняли трубку или нет?

    shcherbanich
    @shcherbanich
    Программист
    Надеюсь эта компания не знает мой номер)
    Ответ написан
    Комментировать
  • Есть ли в Yii2 возможность получить массив в экшине из параметров url?

    Почему нельзя использовать POST? Cookies и туда писать JSON?
    Можете записывать при помощи JSON синтаксиса
    site.ru/users/view/user/56?params={date: day, status: 1}
    Ответ написан
    4 комментария
  • Как эмулировать браузер на php?

    То что ты ищешь! SNOOPY
    Ответ написан
    Комментировать
  • Доменная зона .io — что я пропустил?

    Один из омонимичных доменов:

    .am — национальный домен Республики Армения, созвучен с диапазоном радиостанций AM или как зона AMerica.
    .cd — национальный домен Демократической республики Конго (иначе — Заира), совпадает с сокращением для компакт-диска.
    .dj — национальный домен Джибути, совпадает с сокращением «диджей».
    .fm — национальный домен Федеративных Штатов Микронезии, созвучен с диапазоном радиостанций FM. Пример: last.fm.
    .im — национальный домен Острова Мэн. Совпадает с сокращением Instant Messaging («мгновенные сообщения»).
    .io — национальный домен Британских территорий в Индийском океане. Совпадает с сокращением Input Output («ввод/вывод»).
    .is — национальный домен Исландии. Совпадает со словом is, формой третьего лица единственного числа английского глагола to be. Пример: who.is
    .it — национальный домен Италии. Совпадает с сокращением IT (информационные технологии), а также с английским местоимением it («это»). Пример: ok.undo.it
    .md — национальный домен Молдавии. Совпадает с сокращением аудионосителя MiniDisc и с сокращением Must Die. Также совпадает с сокращением от англ. medical doctor, используемым повсеместно в англоязычных странах. Например, известный американский сериал «Доктор Хаус» в оригинале называется House, MD.
    .me — национальный домен Черногории. Совпадает с местоимением «меня», «мне» в английском и других европейских языках.
    .net — общий домен верхнего уровня, совпадает с русским словом «нет», из-за чего обрёл в России (и не только) дополнительную популярность. Часто используется с доменными именами в виде транслитерированных русских слов. Примеры: mozga.net, lishnih.net.
    .nu — национальный домен острова Ниуэ, созвучно со словом ню.
    .tm — национальный домен Туркменистана, совпадает с аббревиатурой «™» (англ. trade mark — торговая марка).
    .tv — национальный домен Тувалу, совпадает с аббревиатурой «Телевидение».
    .ws — национальный домен Западного Самоа, совпадает с аббревиатурой Web Site.
    .in — национальный домен Индии, с английского языка переводится как предлог «в».
    .li — национальный домен Лихтенштейна. Совпадает с окончанием глаголов и имён существительных в русском языке. Используется с доменными именами в виде транслитерированных русских слов. Примеры: zadolba.li, zastuka.li, vaf.li, gus.li, yas.li.
    .pro - общий домен верхнего уровня для профессионалов в своей области.
    Ответ написан
    3 комментария
  • Кто зарабатывает больше программиста?

    rizhenkov
    @rizhenkov
    Веб-программист
    1. Нормальные работодатели на образование никогда не смотрят. Это может быть приятный бонус к специалисту, но не определяющий фактор.
    2. Больше программиста может зарабатывать опытный программист, у которого другие в подчинении. Ну или хороший дизайнер.
    3. Если не ограничиваться IT-тематикой, то в целом гораздо больше программистов получают всякие управленцы, но как туда попасть - чёткого рецепта нет.
    --
    Итог: если вам действительно нужны именно деньги, открывайте свой бизнес, там ваша ЗП будет зависеть только от вас.
    Ответ написан
    2 комментария
  • Coffeescript vs. TypeScript vs. ClojureScript

    mrakolice
    @mrakolice
    Главный вопрос — это зачем Вам нужны статические типы в Вашем приложении. Я пишу на TypeScript и мне, например, очень не нравится то, что приходится на каждый чих изменения модели данных добавлять поле в модель или ставить тип any, причем указывать это явно. И даже хуже. Если какой-нибудь метод в качестве параметра принимает массив, в котором могут быть разные типы, то необходимо явно его кастовать к типу any[].
    Я соггласен, что компиляция — это хорошо. Статическая типизация — тоже хорошо. Однако мое сугубое ИМХО, что к скриптовым языкам нужно относиться со скриптовым мышлением.
    Возможно, если в том же WebStorm 7.0 значительно улучшилась поддержка TypeScript, мое негодование будет меньшим, либо сойдет на нет.
    Однако, TypeScript предлагает писать в стиле того же шарпа без такого же инструмента, как решарпер.
    Минус в сторону TypeScript и плюс в CoffeeScript — меньший объем кода, символов и тд.

    Личное мнение, основанное исключительно на ощущениях — CoffeeScript няшечка, TypeScript монструозен.
    Если писать на том же AngularJS, ИМХО TypeScript бессмысленен. Хотя при большом желании можно и это достаточно успешно делать.

    Как советовал человек выше — посмотрите livescript, на мой беглый взгляд он даже больше няша, чем Coffee. Однако сразу оговорю, что ни строчки кода на LiveScript я не писал, впечатление сугубо от внешнего вида и его возможностей.
    Ответ написан
    Комментировать