TGTGInsightтелеграм анализLIVE / telegram public index
← Такты, стеки, два колеса

TGINSIGHT SIMILAR POSTS

Намери подобно съдържание

Изходен канал @clockstackwheels · Post #601 · 18.10

Лена у себя написала про беспомощную западную техноддержку. Я вам тоже о нескольких таких случаях из своей жизни рассказывал. Возможно, у вас ссылка не откроется, процитирую небольшой кусочек: «...современные автоматизированные поддержки, которые работают по алгоритму, задизайнены совсем не для таких людей, как я — кто инициирует синхронное взаимодействие с человеком только после того, как исчерпает ресурсы найти ответ на вопрос самостоятельно. При этом хорошо, если отвечает сразу человек — а теперь ведь нередко и робот, который в принципе никогда не может ответить на мой запрос, потому что ответы на простые вопросы я нахожу самостоятельно. И уж если я и обратилась в поддержку, то это всегда какой-то сложный вопрос или нестандартная ситуация, на который робот не ответит никогда. Но даже и с белковым агентом поддержки в последнее время все чаще натыкаешься на ситуацию, когда твоя проблема не вписывается в лекала частых вопросов и проблем и спустя десятки минут бесплодного общения <...> всё, что они делают, — это разводят руками: „Мы исчерпали наши возможности“. Более того, не эскалируют проблему тем, кто компетентен в ней разобраться и ее решить..» Это абсолютная правда, хотя в России я натыкался на такие вещи существенно реже. Либо вообще русские цифровые сервисы сделаны лучше, и приходится обращаться в саппорт меньше. Либо просто русский человек не так часто может изображать из себя идиота, даже если ему дан приказ работать по скрипту. Я задумался -- почему всё-таки поддержка у крупных компаний в основном именно такая? По крайней мере мой личный опыт весьма однозначен: за последний год было штук пять обращений в разные англоязычные сервисы, и четыре из них зависли на скрипте (не завис Гитхаб -- честно решил мою проблему). Видимо, бизнесу выгодно содержать такую поддержку и не выгодно содержать другую. Моя гипотеза: стоимость незаскриптованного человека достаточно велика, а количество не тупых обращений достаточно мало, чтобы не было смысла заморачиваться. Жаль, что в интерфейсах не делают галочки "Я не тупой". Компании могли бы содержать одного умного специалиста поддержки, он бы получал по одному сообщению в день от редких умных людей, которые действительно наткнулись на серьёзную проблему. А скрипто-обезьянки обрабатывали бы запросы, ответ на которые выпадает первой строчкой в гугле. Но, наверное, человечеству нужно идти ещё дальше и пускать в интернет людей только после сдачи экзамена по работе с интерфейсами. Да, знаю, компании и сами то не спешат сейчас делать вменяемый UI: например, была история о том, что для остановки платной подписки на Amazon нужно было сделать десяток очень неочевидных действий, нажимать на кнопки с непонятным содержимым мелким шрифтом, проматывать страницы до конца, ставить строго определённые галочки и так далее. Наказанием для таких компаний был бы отказ пользователей от их услуг, но в рамках капиталистических монополий у юзеров особо нет выбора. Возможно люди, которые когда-то сдавали сложный экзамен по UI, позже, работая в корпорациях, будут с меньшей охотой делать запарный и непонятный интерфейс. #web

Hashtags

Резултати

Намерени 84 подобни публикации

Търсене: #nodejs

当前筛选 #nodejs清除筛选
Tomoko RD

@tomoko_channel · Post #705 · 10.10.2024 г., 12:24

Node.js 纪录片感想(小抄) 1. Ryan Dahl 创建 Node.js 当时流行的 Web 框架(如 Ruby on Rails)在处理高并发时效率不够高,特别是在处理 I/O 密集型任务时性能显得不足。虽然这些框架也支持异步 I/O,但用起来很别扭。 他也尝试过其他语言(如 Python、Lua、Haskell),但发现这些语言的运行时已经沉淀了多年,深受传统同步编程模型的限制,很难进行根本性的变革。 于是 Boy Meet Girl,算是终于让他看见了 Javascript 这个本身就在浏览器中天天需要处理异步场景的语言。(JavaScript 本身就依赖事件循环和异步操作来处理用户交互与网络请求。) 关键点是 easily build optimal server 以及 forcing them to only use async IO。也是 Node.js 的核心优势。 2. Isaac Schlueter 加入 & npm 的诞生 这点倒是没什么好说的,pip 比它要早一点,08年 vs 10年。 想起我大二那年,被 pacman 什么都能下载给震撼住了。真的是,生在这种什么都有的年代真是被惯坏了。不过即使我在那个年代,也不会造出这样的轮子吧 3. Joyent 买下 Node.js 这一阶段就是真的让 Node.js 成为一个企业级产品了,毕竟有公司去资助一批工程师去全职开发。 也是在这个阶段支持了 Windows,让用户量大大增加了。(通过实现 LibUV 库来处理 Windows 特有的 I/O 操作和事件循环,兼容了 linux 和 win 的操作) 4. Ryan 退出 & 社区分裂 Ryan 在 Windows 版本出来之后就腻了,看来是那种喜欢写新功能而不想全天在修 BUG 的人?于是负责人从 Ryan -> Issac -> TJ Fontaine。 至于创始人离开之后,社区的贡献者自然就觉得给 Joyent 打白工非常无趣,于是就去 fork 了 io.js(确实,虽然 MySQL 是开源的,但谁会乐意无偿贡献代码给 Oracle 呢?) 5. 基金会成立 最后是双方妥协,Joyent 将 Node.js 的管理权交给了基金会, io.js 和 Node.js 最终合并。可喜可贺,可喜可贺。 不过这也是社区力量占主导才能强迫公司妥协,不然就变成现在的 MariaDB 了? --- (仅仅是笔记,不一定对,需要勘误) https://www.youtube.com/watch?v=LB8KwiiUGy0 #TIL#nodejs

Hashtags

AprilNEA's Notebook

@AprilNEALab · Post #75 · 31.08.2024 г., 14:44

#NodeJS#ORM 这么严重的问题花了一年才被修复。 https://github.com/drizzle-team/drizzle-orm/issues/724 https://github.com/drizzle-team/drizzle-orm/releases/tag/0.33.0 TL;DR Drizzle ORM 导致 JSONB 在 Postgres 数据库中错误的以 JSON String 表示

Hashtags

123•••67
ПредишнаСтр. 1 от 7Следваща