В жизни каждого инженера‑фронтендера наступает момент, когда осознаёшь: далее не обойтись без кэширования данных из API. Всё может начаться с самых невинных вещей: сохраняем предыдущую страницу с данными, чтобы кнопка «Назад» срабатывала мгновенно; реализуем простенькую логику отмены действия или обеспечиваем слияние нескольких состояний от различных запросов к API. Но все мы знаем, чем такое кончается. Один за другим возникают запросы на новые фичи, и вскоре мы уже не покладая рук реализуем кэши данных, индексы для работы вручную, оптимистические мутации и рекурсивную инвалидацию кэша.
Рубрика «клиент»
Прекратите клепать базы данных
2023-12-05 в 22:07, admin, рубрики: sql, клиент, микроменеджмент, обработка данных, серверЭволюция игрового фреймворка. Введение 1. Постановка проблемы
2022-07-03 в 9:19, admin, рубрики: actionscript, flash, haxe, OpenFL, python, Анализ и проектирование систем, клиент, разработка игр, сервер, управление разработкой, фреймворкПроблема
Скорость разработки и качество кода — вот, пожалуй, одно из главнейших противоречий IT-индустрии. Можно долго продумывать архитектуру приложения, потом ее совершенствовать, улучшать, а в итоге так ничего и не сделать. А можно быстро что-то сварганить, а потом и зарелизить, но из-за ошибок проектирования завести весь проект в тупик. На каждые два часа разработки, шесть часов будет уходить на поиск и исправление багов, в результате чего вся последующая разработка фактически застопорится.
Что необычного пишут люди в поддержку VDS-хостинга
2021-08-31 в 12:02, admin, рубрики: ruvds_статьи, vds, Блог компании RUVDS.com, клиент, поддержка, сервис, управление проектами, хостингКлиенты пишут в поддержку по рабочим вопросам — ну знаете, всё то, что ещё не автоматизировано и нельзя сделать из личного кабинета — и по странным. С учётом, что у нас разработка постоянно добавляет функции в ЛК по мере накопления тикетов, которые надо автоматизировать, постепенно работа поддержки всё больше сводится к разбору странного.
Например, часто клиенты берут демопериод и спрашивают, можно ли спамить с наших серверов, ломать чьи-то кошельки и так далее. Когда мы показываем пункты оферты, по которым нельзя, просят пустить их по-братски. Заканчивается обычно вот примерно так:
Клиент на демопериоде: Разблокируйте. Просто хотел блокчейн запустить на сервере и получил бан.
Сотрудник: Данные в паспорте не соотносятся с тем, что вы заполнили, поэтому либо заполните согласно паспорту, либо предоставьте надлежащую копию.
Клиент: Готово. Исправил ошибку.
Сотрудник: Разблокировали.
Клиент: Снова разблокируйте.
Сотрудник: Укажите назначение и цель использования программ, за которым поступили блокировки одна за одной.
Клиент: Еммм. Взлом своего бтц-кошелька. Жалобы от кого? )
Сотрудник: К сожалению, разблокировка сервера в этой ситуации возможна только после его оплаты на общих основаниях.
Клиент: Ахааххах, странные вы ) очень ) идите на**й )
Обычно на этом диалог и заканчивается, поскольку мы отказываем клиентам в обслуживании после оскорбления сотрудника поддержки. При этом если клиент матерился просто безадресно, на ситуацию, это более-менее приемлемо, а вот если адресно послал или обозвал сотрудника — уже нет. Это простое правило, возможно, стоило нам нескольких десятков клиентов, но сберегло море нервов сотрудников.
Конечно, самое ценное — это когда нам присылают баг. Или жалуются на что-то, что легко исправить и получить ещё одно преимущество. Вот, например, недавно был случай, когда выяснилось, что в личном кабинете можно менять 1 рубль на 1 доллар, — курс получался вполне себе даже ничего. Читать полностью »
Делаем поддержку дешевле, стараясь не растерять качество
2020-05-26 в 12:03, admin, рубрики: service desk, vds, vps, автоматизация, Блог компании RUVDS.com, клиент, оператор, оптимизация, поддержка, сервис, техподдержка, тикет, управление проектами, хостинг, шаблонАварийный режим (также упоминается как IPKVM), позволяющий подключаться к VPS без RDP прямо с уровня гипервизора, экономит 15–20 минут в неделю.
Первое и главное — не бесить людей. Во всём мире поддержка разделена на линии, и сотрудник первой должен попробовать типичные способы решения. Если задача выбивается за их пределы — передать второй линии. Так вот, среди администраторов VDS достаточно часто попадаются люди, которые умеют думать. В отличие от многих других поддержек. Ну, по крайней мере, существенно чаще. И они хорошо структурируют тикет, сразу описывая всё что нужно. Если у первой линии «глаз замылится» и они случайно в ответ на такое попросят включить и выключить — это фиаско.
Задача стоит очень простая: сделать поддержку нашего VDS-хостинга адекватной при минимуме затрат. Потому что мы фастфуд мира хостинг-провайдеров: никакого особого «облизывания», низкие цены, нормальное качество. Ранее уже был рассказ про то, что с появлением инстаграм-няшек, пытающихся автоматизировать ведение аккаунта и владельцев малого бизнеса с удалённой бухгалтерией и остальных не слишком прокачанных в технологиях людей, общение «как админ с админом» прокатывать перестало. Пришлось менять язык общения.
Теперь расскажу о процессах чуть больше — и о неминуемых косяках с ними.
Читать полностью »
Как мы переучивали поддержку разговаривать по-человечески, и что получилось
2020-05-19 в 11:04, admin, рубрики: gtd, service desk, vds, vpn, Блог компании RUVDS.com, клиент, оператор, поддержка, сервис, тикет, управление проектами, хостинг, шаблонПоддержка разговаривала с пользователями сухо, коротко и официально. Пользователи обижались. Например, вот:
Клиент: Привет, как поднять VPN на сервере?
Поддержка: Ваш сервер в порядке, мы не занимаемся серверным администрированием [закрывает тикет].
Поддержка права? Права. Но клиент обиделся. Потому что можно было то же самое написать нормально:
Клиент: Привет, как поднять VPN на сервере?
Поддержка: Добрый день! Я не могу помочь вам настроить VPN, потому что мы оказываем поддержку только в случае, если что-то не работает на нашей стороне. Но у нас есть статья в базе знаний, как просто поднять VPN. Спасибо за обращение [закрывает тикет].
Что поменялось? Клиент понял, что его не послали, а что всё ещё уважают, но услуга не входит в пакет. Для тех, кому первая фраза кажется слишком сухой, есть элементы этикета, которые используют все вежливые люди. Есть понятный следующий шаг.
Мы стараемся давать максимум технических вещей за минимум денег, и поддержка традиционно оставалась за бортом: она дорогая в расчёте на стоимость месячного тарифа VDS. Но оказалось, что можно поменять многое довольно дёшево. Мы и поменяли. И протестировали. Ниже — несколько основных вещей:
- Как вежливо ответить, если помогать не будем.
- Как убрать бюрократизм из ответов.
- Нужно не забывать извиняться, если проблема была на нашей стороне.
- Как отвечать по делу, а не «вы находитесь на воздушном шаре».
- Почему уважение — это не слово «уважаемый» в начале.
- Почему надо говорить о своих действиях в процессе.
- Почему вообще надо писать по-человечески.
Под капотом бота-клиента Яндекс.Музыки
2020-02-07 в 13:00, admin, рубрики: api, python, клиент, Яндекс APIВведение
Привет! Вновь я с уже второй статьей, затрагивающей API Яндекс.Музыки. Дело запланированное и упоминалось в первой статье.
Руки дошли, дело сделано. Сегодня я расскажу об интересных, на мой взгляд, моментах, которые присутствуют в кодовой базе моего Telegram бота, позиционирующего себя как полноценный клиент я.музыки. Ещё мы затронем API для распознавания музыки от Яндекс.
Перед тем, как приступить к попунктному рассказу реализации той или иной вещи, стоило бы иметь представление о самом боте и его функциональных возможностях.
В основной части я расскажу про следующее:
- Авторизация в аккаунт через сайт на GitHub Pages (зачем и почему).
- Формат данных, его упаковка и использование в данных для кнопок.
- Роутинг апдейтов, версионность данных, прокидывание контекста в обработчики.
- Сервисы:
- Сервис перезаливки трека в Telegram.
- Сервис «подписок» на получение трека с отправкой статуса о загрузке.
- Наипростейшая и элегантная реализация кэширования запросов.
- Распознавание трека по голосовому сообщению и как это вообще появилось в боте.
- Мелкие заметки.
Если Вас заинтересовал хоть один пункт — добро пожаловать под кат.
Читать полностью »
Профиль неидеального клиента. Каким клиентам отказывать и почему это жизненно важно
2018-03-22 в 8:18, admin, рубрики: SaaS, SaaS / S+S, Блог компании Alconost, интернет-маркетинг, клиент, маркетинг, Управление продажами, Управление продуктомПредставьте такую ситуацию: вы — основатель совсем молодой SaaS-компании, стараетесь найти первых потенциальных клиентов и заинтересовать их, и вдруг перед вами появляется огромная корпорация и начинает размахивать своими деньжищами. Они вас нашли и хотят купить то, что вы продаете.
Но погодите. Вы же не разрабатываете инструменты для таких компаний. И, черт побери, даже никогда не работали с корпоративными клиентами. А деньги так и манят: стоит лишь протянуть руку — и они ваши.
Что же предпринять?
Большинство в таком случае выбирает деньги — и это одна из самых крупных ошибок, которые только можно совершить.
Брать деньги не у тех клиентов — это смертный приговор для компании. И мне следовало это понимать.
Переведено в AlconostЧитать полностью »
Эволюция приложений или куда мы идем
2017-04-12 в 0:16, admin, рубрики: api, RPC, Анализ и проектирование систем, архитектура, браузер, браузеры, ветхий веб, высокая производительность, интернет, исследование, клиент, обзор, прогноз, Программирование, протокол, Разработка веб-сайтов, реактивность, сервер, СУБДНазывать статью «Эволюция прикладных информационных систем и перспективы развития их архитектуры» было бы слишком академично, а ведь тут будет очень краткая выжимка из реального практического опыта, возможные варианты развития технологий, вызвавшие их потребности и пути решения. Я надеюсь, что статья поможет обобщить и переосмыслить широкий круг задач, связанных с прикладными ИС, и сразу хочу уточнить, что понимаю под этими терминами. ИС — это системы, обеспечивающие обработку, передачу и хранение данных. Это далеко не все программирование, но сейчас ИС чаще всего ассоциируются с веб и мобильными приложениями, хотя и не совпадают с ними полностью, знак равенства между UI и ИС нельзя ставить тем более. Очень прошу всех посмотреть на вопрос как можно шире и присоединяться к обсуждению в комментариях. И еще, я намеренно не буду использовать названия фреймворков и технологий, чтобы избежать лишних холиваров, ограничившись общепринятыми названиями архитектур, стандартов и протоколов, что и вам рекомендую в комментариях.
Читать полностью »
Начало продаж UC АТС 3CX Phone System v15
2016-07-12 в 10:16, admin, рубрики: 3cx, uc, v15, zero admin, Блог компании 3CX Ltd., ит-инфраструктура, клиент, продажи, Разработка систем связи, Сетевые технологии, системное администрированиеРасширенный набор функций и упрощенное администрирование позволяют развернуть систему на корпоративном сервере или в частном облаке
Представляем новую версию UC АТС 3CX v15, значительно упрощающей администрирование и обладающей новыми функциями, дополнительной безопасностью, современным интерфейсом и простой интеграцией со сторонними приложениями.Читать полностью »
Создание in-memory кэша первого уровня для .NET-клиентов StackExchange.Redis
2016-05-23 в 10:57, admin, рубрики: .net, in-memory, redis, Блог компании Plarium, клиент, Клиентская оптимизация, кэш, оптимизация, Программирование, Серверная оптимизацияДжонатан Карди написал .NET-библиотеку StackRedis.L1 с открытым исходным кодом, которая позволяет создавать кэш первого уровня для Redis. Иными словами, используя библиотеку StackExchange.Redis в .NET-приложении, вы можете подключить к ней StackRedis.L1 для ускорения работы за счет локального кэширования данных в оперативной памяти. Это позволяет избежать лишних обращений к Redis в тех случаях, когда данные не подвергались изменениям. Библиотека доступна на GitHub и NuGet.
В этой статье рассказывается о том, как и почему она была создана.