• Порекомендуйте, на чём сделать backend?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    - node.js, Смущает его однопоточность. Есть немалый риск что новый запрос придёт до того, как закончится обработка старого. Как это отлаживать - хз.

    Дык за это отвечает платформа. Новые запросы просто стоят в очереди (ну естественно если их не оборвет по таймауту клиент или reverse proxy).
    Ответ написан
    2 комментария
  • Порекомендуйте, на чём сделать backend?

    saboteur_kiev
    @saboteur_kiev Куратор тега Python
    software engineer
    > хранить на сервере базы данных, но тогда каждый запуск скрипта означает ещё и обращение к серверу баз данных
    можно использовать memcached
    Ответ написан
    1 комментарий
  • Порекомендуйте, на чём сделать backend?

    @Levhav
    Возьмусь за разработку проектов любой сложности.
    Попробуйте связку PHP + CppComet в ней CppComet будет обслуживать конекты по вебсокетам, а php бекенд будет обслуживать обычные http запросы и выполнять бизнеслогику вашего приложения.

    Вопрос с авторизацией решится просто так как в api CppComet предусмотрен механизм авторизации
    Сам по себе CppComet является многопоточным сервером на C++, а апи вызовы можно делать от любого бекенда.
    Ответ написан
    Комментировать
  • Как узнать что посетитель с мобильного браузера - тот же человек, что и с настольного?

    Goodluck
    @Goodluck
    https://support.google.com/analytics/answer/312366...

    Похоже у Google Analytics есть такая функция.
    Ответ написан
    Комментировать
  • Как объяснить рядовому клиенту, что сайт, сделанный руками, а не на шаблоне, для него будет лучшим выбором?

    @mamayama
    Зачем вы хотите навязать человеку вещь, которая ему не нужна?
    Ручной вариант - нааааааааааааааааааааамного дороже, а он не окупится, ведь, о, мальчик, живущий в Сети - у большинства людей весь бизнес в реале, и его прибыль не зависит от сайта.


    Как вы, уважаемые коллеги, объясняете своим заказчикам, что проект, созданный командой разработчиков (UX-дизайнер, верстальщик, программист и т.д.) будет заведомо лучшим выбором, нежели, чем тот, который собран на коленках школьником вечером после уроков быстро/сердито/дешево?


    Если конкурентом вашей команды являются школьники, подрабатывающие по вечерам - то грош цена вашей команде.


    Команда, подобная описанной выше - должна решать очень серьезные проблемы клиентов. До которых школьникам как до Луны.
    Ответ написан
    1 комментарий
  • Как объяснить рядовому клиенту, что сайт, сделанный руками, а не на шаблоне, для него будет лучшим выбором?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    > Как вы, уважаемые коллеги, объясняете своим заказчикам, что проект, созданный командой разработчиков (UX-дизайнер, верстальщик, программист и т.д.) будет заведомо лучшим выбором, нежели, чем тот, который собран на коленках школьником вечером после уроков быстро/сердито/дешево?

    У вас категорически неверное понимание того, что такое сайт на движке. Я не могу понять, почему вы считаете, что Ваша поделка на коленке, состряпанная за пару недель вчерашними школьниками, каким-то образом лучше Продукта, написанного сотнями и тысячами программистов в опенсорсе и опробованная миллионами пользователей.

    > "Как объяснить рядовому клиенту, что сайт, сделанный руками, а не на шаблоне, для него будет лучшим выбором?"

    Сперва убедитесь, что именно ВЫ понимаете, что хочет клиент. Например вы сможете с цифрами доказать, что сайт, созданный вами с нуля повысит продажи клиента на 10%, а сайт на шаблоне не повысит? Вы точно это сможете сделать? Если нет, то зачем клиенту знать какие кишки внутри сайта, если он выполняет свою бизнес задачу за минимальные деньги?

    > Рынок буквально переполнен дешевыми предложениями о создании сайтов (лендингов, интернет-магазинов и т.д.), которые созданы на универсальных шаблонах к WP/Joomla или конструкторах Wix/Lpgenerator/и т.д. Стоимость таких предложений довольно низкая. Рядовой клиент все чаще выбирает исполнителя по наименьшей цене.

    И правильно делает. Зачем для сайта-визитки среднестатистической компании что-то еще? Для ИХ БИЗНЕСА, этого ДОСТАТОЧНО, и понятно, что чем ниже цена, тем лучше клиенту. Для развозки пиццы покупают маленькие мотороллеры, а не крутые, вручную собранные харлеи. Потому что все это - инструменты, а не самоцель.
    Ответ написан
    3 комментария
  • Как объяснить рядовому клиенту, что сайт, сделанный руками, а не на шаблоне, для него будет лучшим выбором?

    VasyaPertrov
    @VasyaPertrov
    Изготовление и безопастность сайтов. WP и др.
    проект, созданный командой разработчиков (UX-дизайнер, верстальщик, программист и т.д.) будет заведомо лучшим выбором, нежели, чем тот, который собран на коленках школьником вечером после уроков быстро/сердито/дешево?

    1. С чего ты взял что твой "проект" будет лучше шаблонов, сделанных специалистками и проверенными-перепроверенными ещё сотней-тысячью других? ЧСВ зашкаливает?

    2. Какая связь межу шаблоном, сборкой и школьниками? Уже это говорит что ты не понимаешь предмета.

    А клиенту опасно связываться с такими самодельщиками - никто не проверит что там в реальности, доработать может быть сложнее и дороже.
    Ответ написан
    1 комментарий
  • Что учить Angular или React новичку?

    vitali1995
    @vitali1995
    Если говорить в двух словах:
    * Реакт проще в освоении, труднее в использовании.
    * Ангуляр проще в использовании, труднее в освоении.
    Ответ написан
    3 комментария
  • Биржа upwork как источник заказов для IT компании?

    @polifill
    Не с той стороны заходите.

    Самая большая проблема - ВЗЯТЬ нормальный заказ на бирже UpWork.
    Ну а вам как бизнесмену - брать такие заказы РЕГУЛЯРНО, чтобы обеспечивать свой штат постоянной загрузкой по работе.

    Все остальные озвучанные вами проблемы - полнейшая ерунда и вообще не являются проблемой на фоне той проблемы, что действительно вам будет трудно решить для того чтобы начать свою деятельность на Upwork - РЕГУЛЯРНО БРАТЬ ХОРОШИЕ ЗАКАЗЫ.

    Неплохие специалисты на Upwork годами работают - и предел их мечтаний "взять заказ на 500 долларов", а вы сходу на постоянные заказы по $3000 рот раззеваете....

    Не хотите, чтобы ваши конечные исполнители видели ваши заказы и заказчиков - работайте с исполнителями мимо Upwork, а через Upwork только с заказчиками работайте, - в чем проблема-то????

    От того, что ваши работники узнают, что вы берете заказы через Upwork - ничего принципиально не изменится.

    1. Одиночному специалиста не так просто брать крупные заказы.
    2. Чтобы раскрутиться на Upwork - нужно время, и довольно долго новичок получает не особо интересные и не особо денежные предложения.
    3. Если вы обеспечиваете сотрудников постоянным потоком работ - они не будут искать доп. заработок на сайтах типа Upwork.
    4. Не всем нужен этот гемморой с прямым заказчиком. Подавляющее большинство людей в мире работает в каких-либо фирмах и получает работу через начальника, а то и через большую цепочку начальников... Многим людям так намного комфортнее.

    Проблема у вас будет только в одном случае - если вы будете откусывать ЗДОРОВЕННЫЙ процент, при этом никакой СВОЙ ВКЛАД НЕ ДОБАВЛЯЯ.

    Но в наше время, когда о Upwork знают почти все - никак вы эту проблему не устраните.

    Только внося свой дополнительный вклад (например, прекрасным знанием английского языка, постоянным вниканием в глубину проектов и тем, что будете крайне внимательно относится к своей репутации на Upwork и будете работать над репутацией долгие месяцы) вы будете застрахованы, что работать через вас будет выгоднее, чем напрямую.
    Ответ написан
    8 комментариев
  • Как узнать что посетитель с мобильного браузера - тот же человек, что и с настольного?

    Olej
    @Olej
    инженер, программист, преподаватель
    А как это узнать программно?

    Достоверно - никак.

    В годы Великой Отечественной Войны радисток определяли по стилю ("почерку") "морзянки".
    Можете попробовать ;-)
    Ответ написан
    Комментировать
  • Порекомендуйте язык/фреймфорк/технологию для websocket-сервера?

    @jacob1237
    Асинхронная модель обработки сетевых соединений можно сказать что единственно верная для данной задачи.
    Корень зла здесь - так называемая "проблема C10k", то есть "проблема 10 тысяч соединений": https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D...
    При построении чатов эта проблема стоит особенно остро, т.к. если у Вас, например, 2000 онлайн пользователей, то и соединений с ними тоже 2000, которые необходимо поддерживать в активном состоянии в режиме реального времени.
    Именно в таких случаях асинхронная модель выигрывает, потому что на каждое соединение получается очень небольшой оверхед по памяти, в отличие например от модели когда на каждое соединение создается системный поток - thread.

    Теперь про возможные технологии. Написать чат на вебсокетах возможно много на чем.
    Фаворитами по скорости программирования здесь будут, ИМХО, JavaScript (Node.js) и Python. По скорости же работы - Go, Erlang и прочие компилируемые языки.

    Python:
    1. Twisted + sockjs-twisted
    2. Tornado + sockjs-tornado (уже приводили здесь)
    3. Crossbar.io (http://crossbar.io/) - комплексное решение, которое позволит сконцентрироваться на логике приложения, а не на технических вопросах.
    4. Разные вариации библиотек (Authobahn.io, asyncio etc.)

    JavaScript (Node.js):
    1. Socket.io (socket.io/) - достаточно известное решение, комплексное, позволяет не думать о технической части
    2. SockJS (https://github.com/sockjs/sockjs-node) - больше библиотека чем фреймворк. Например мультиплексирование (несколько "виртуальных" соединений внутри одного сокета) придется пилить вручную (правда есть библиотеки)

    Хочется отметить, что вне зависимости от использования Socket.io или SockJS, настанет момент, когда Вы захотите использовать все ядра своего процессора для обработки пользовательских соединений (по одному запущенному процессу на ядро). И вот тут на Python придется вручную писать логику построения кластера из нескольких процессов.
    В Node.js эту проблему решает модуль "Cluster" (https://nodejs.org/api/cluster.html).
    В принципе на Python тоже можно быстро написать этот функционал (например на Twisted), но осадочек, как говорится, остался)

    По поводу скорости - JavaScript (Node.js) априори будет быстрее чем Python, т.к. там JIT компиляция.
    Уравновесить ситуацию поможет PyPy - нестандартный интерпретатор Python, который тоже использует JIT-компиляцию. В этом случае разницы в скорости практически не будет заметно.

    Сам я люблю и уважаю Python, поэтому порекомендую его. Хотя бы потому что в Twisted, Tornado да и asyncio есть корутины (coroutines), а в новых версиях Python даже async/await. Эти конструкции позволят Вам писать в линейном стиле и избежать лапшекода как в JavaScript.

    PHP:
    1. Ratchet (уже писали о нем)
    2. phpDaemon

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

    Если очень нужна высокая скорость и нетребовательность к ресурсам, пишите сразу на Go. Вот выше Вам уже посоветовали комплексные решения типа Centrifugo (который кстати сначала был написан на Python + Tornado).

    P. S. Забыл отметить, что если Вам нужны исключительно веб-сокеты (которые будут работать во всех современных браузерах), то Вы вообще можете отказаться от Socket.io и SockJS. Эти библиотеки хороши для обеспечения совместимости со старыми браузерами, ну или для случаев, когда вебсокеты режутся сетевым оборудованием. Эти библиотеки по-умолчанию переключат браузер в режим long-polling.

    Однако если Вам все это не нужно - то не берите, тем самым уменьшите оверхед на браузер и сервер.
    Ответ написан
    Комментировать
  • Порекомендуйте язык/фреймфорк/технологию для websocket-сервера?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    https://icicle.io/
    Full-featured event loop for asynchronous programming
    Multiple event loop back-ends
    Asynchronous TCP and UDP sockets
    Asynchronous DNS resolution
    Standalone HTTP and WebSocket server
    Multi-processing using forking or child processes
    Multi-threading using native threads
    Asynchronous process signal handling
    Worker pool for running blocking tasks
    Non-blocking concurrency primitives
    Ответ написан
    Комментировать
  • Порекомендуйте язык/фреймфорк/технологию для websocket-сервера?

    @serious911
    Если нужно все быстро и из коробки, то рекомендую Node.js + Socket.io. Можно также использовать SockJS, но нужно учитывать, что это только продвинутая обертка над стандартными вебсокетами и нужно будет разбиратся/создавать свой функционал/API и т.п.
    Ответ написан
    2 комментария
  • Порекомендуйте язык/фреймфорк/технологию для websocket-сервера?

    JRazor
    @JRazor
    Senior StarkOverFlow Programmer
    Могу порекомендовать в качестве сервера для Python: Tornado framework + SockJS для работы с сокетами + Queue (очереди). Выбирал между оригинальными сокетами, Socket.io и SockJS: последний имел меньше всего багов на тот момент и держал больше соединений.

    И да, асинхронность в работе с сокетами - полезная штука. Чего-то развелось чатов, которые падают при нагрузке выше 5К в последнее время.
    Ответ написан
    1 комментарий