2026 上 83 2025 下 45 2025 上 31 2024 下 50 2024 上 25 2022 下 1 2024 下半年 · 50 条
https://t.co/0Nb4et8Ay5 这网站我也挺久没维护了,也没做宣传,现在每天稳定有差不多 30 左右的新增用户。这就是被动增长了么😆
👁 16,735 ♥ 73 🔁 9 💬 6
我认为一个人只要 1️⃣ 足够聪明 2️⃣ 对 💰 足够渴望 那么他终归会赚到他想赚到的 💰 的。反思下自己哪一点还不够吧 🤔
👁 2,399 ♥ 23 🔁 0 💬 5
交易起来 💸💸💸
👁 1,490 ♥ 4 🔁 0 💬 1
结识大佬最快的方式:付费 👀 大多数人对「投资」这个词没什么概念,实际上💰能成为很多事情的杠杆,包括人脉。
👁 2,782 ♥ 22 🔁 1 💬 2
这两天抽空折腾了下,放弃了 🤪
1️⃣ 本来想修改官方的 time series plugin 支持下使用 js 来预处理数据,但是发现这个 plugin 是 built in 的,大量依赖内部的代码,没法方便的抽离出来
2️⃣ 后来想着看看 grafana 能否支持自定义 transformation,但是找了下发现官方还没这个计划
https://t.co/N1sJfSnu25 3️⃣ 最后想着试试能不能在 prometheus 的 data source plugin 上做点文章,发现这家伙也是 built in 的 😅
最后只能用 business charts 这个第三方插件来处理了,可视化用的是 echarts,样式、交互和功能和官方的 time series(内部用的 uplot)有不少差异。
啥时候能支持自定义 transformation 那就美滋滋了。
nekocode @nekocode_cn 也不知道我是什么体质,日常工作中不管用什么库/工具,总会遇到各种 bug 或者没法满足我需求的 case。 因为又不想不管,导致我得去研究它的代码然后在本地 patch,最后或许还能去给上游贡献点代码 😅 最近一个新的 case 就是 grafana + prometheus 没法满足我一些复杂的数据后处理逻辑,目前打算去改造官方的 time series plugin 了,支持下使用 js 进行后处理再可视化。
👁 1,800 ♥ 3 🔁 0 💬 0
100% 同意。但是现实是大多数的利益分配者不会愿意多付这 100% 的支出。 贪婪和压榨是资本的天性。
Yishi @ohyishi 聪明的人沟通起来就是爽,你刚说完30%的需求,他就能 get 到120%,多出来的那20%是超额执行,考虑了各种边缘情况和向后兼容,考虑得比你还周全。 不聪明的人,你完整交代100%的需求,他只能做到30%,多不了一点,只管上线,脏活全丢给 qa。然后你被逼着不停拉会,非常疲惫。 不要为了省那20%预算招不聪明的人,应该花200%的钱招聪明的人。
👁 1,470 ♥ 5 🔁 0 💬 0
看看过去 24 小时里暴跌行情 📉 我们资金曲线的表现 👀
👁 1,513 ♥ 9 🔁 0 💬 1
让我想起我的一个前同事,在他的个人项目里用到我们内部的某个 token,然后还 push 到 github public repo 幸好最后被我发现的事 😅 我甚至最开始还不知道他的 github id,是收到风险预警 email 后再在 github 上搜这个 token 文本才找到他并确认的。
Ruifeng @liruifengv vant、@rspack/core、@rspack/cli 被盗号者注入恶意脚本,请升级到 vant 4.9.15、@rspack/core 1.1.8 、@rspack/cli 1.1.8
https://t.co/EU715y7zVz https://t.co/KntX26q96S 👁 1,572 ♥ 5 🔁 0 💬 0
也不知道我是什么体质,日常工作中不管用什么库/工具,总会遇到各种 bug 或者没法满足我需求的 case。 因为又不想不管,导致我得去研究它的代码然后在本地 patch,最后或许还能去给上游贡献点代码 😅 最近一个新的 case 就是 grafana + prometheus 没法满足我一些复杂的数据后处理逻辑,目前打算去改造官方的 time series plugin 了,支持下使用 js 进行后处理再可视化。
👁 2,987 ♥ 6 🔁 0 💬 0
😎 用 grafana 搭建的量化表现面板。 🆒🆒🆒💵💵💵
👁 1,228 ♥ 9 🔁 0 💬 0
最近 crypto 行情好起来了,老板说他的资产又回到前高了,顺便把创业亏掉的窟窿也都补回来了😆 后续老板和我们几个合伙人讨论了下,决定后面不搞产品了,把其余人员都解散了,剩下我们几个就专心研究下交易/quant 就好。 对他来说,比起做产品,还是做交易的反馈来得直接😂
👁 2,733 ♥ 14 🔁 0 💬 4
这年头,还有月薪超过 30k 的后端工程师拒绝使用 docker 来部署,想问下这合理么😅
👁 2,953 ♥ 10 🔁 0 💬 17
最近在看老板花了几个 w 报的 quant 课程给的代码,一个感想:「搞科研的和搞代码的真的是两拨人」。代码乱、抽象差、工程性差、运行效率差 🫠 要不信的话,你去看看 quant 或最近热门的 ai 领域的开源项目,其实挺多都是代码质量一般的。而且有很多 poc 还都只是停留在 jupyter notebook 阶段。 当然,这种现象非常合理,毕竟术业有专攻。能跨领域本身就已经是稀缺人才了。
👁 1,092 ♥ 6 🔁 0 💬 0
强烈推荐下 react-scan 这个新工具。react 生态下终于有一款简单方便的杀手级 profiling 工具了!
Aiden Bai @aidenybai github, please fix your React re-renders.
literally every time i scroll it renders 100×
https://t.co/7dKd5lWrZt 👁 1,222 ♥ 9 🔁 1 💬 0
创业过多次,和三个 ceo 同住过。之前的两个 ceo 在我们解散后都已经起飞了。一个做了家全国某类别 top 1 的新媒体公司,另一个做了家国内私域领域 top 级别的操盘公司 🥲 那还有一个 ceo 呢?其实就是我们现在团队的 ceo,目前还在挣扎中。能看到团队起飞的那天么🥺
👁 7,186 ♥ 16 🔁 0 💬 1
1️⃣ 在服务器上配置并启动你的代理客户端/容器
2️⃣ 启动一个 redsocks 容器来代理容器内的网络流量到你的代理客户端/容器(推荐个 redsocks 镜像:
https://t.co/tKwcU5LhS6 3️⃣ 把你要代理的应用的容器的 network_mode 设置为 redsocks 容器 id,共享网络栈
它比起设置 HTTP_PROXY 环境变量的好处是能更彻底的代理所有流量。
举个简单的例子:
👁 2,587 ♥ 7 🔁 2 💬 0
希望大家不会用上的技巧之:
💡如何代理某个 docker 容器内所有的网络流量。
背景:
我想让某个跑在国内服务器上的 nestjs 应用支持下 google 登录。应用是跑在容器内的,所以你懂的,得代理下容器内所有与
https://t.co/Ua4slLfG9e 之间的请求。
方法👇:
👁 1,473 ♥ 11 🔁 0 💬 2
我们团队最早是做 crypto 套利的,后来市场环境没那么好之后老板才决定去做产品。 一开始是做 crypto 的交易工具,一直不愠不火。后来 gpt 火了之后又跑去做 ai 套壳工具,本来其实已经做出起色来了(搞了几十万用户),后来遇到个「黑天鹅」事件直接又给搞熄火了。 最近老板花了几万块买了个量化的课程,打算又回到老本行做 crypto 量化交易了 😶
👁 3,661 ♥ 17 🔁 3 💬 7
RT @Ehco1996: 最终还是准备重回职场打工了,求推友们帮忙介绍和转发🙏
github:
https://t.co/AZDNmKOb6I 另外附了一些基本介绍,有兴趣的瞅瞅,欢迎私信/邮箱联系我
👁 0 ♥ 0 🔁 61 💬 0
时代的微尘落到每个人头上都是一座大山。 最近看到太多太多例子了,聪明如中产,仍旧挡不住被大环境的收割一夜返贫,太难了。
👁 961 ♥ 4 🔁 0 💬 0
我们用的是自部署的 gitlab,然后我们的 runner 是和 gitlab 一起跑在一台配置一般的 aws ec2 上。
之前测试过,我们的项目在这台 ec2 上构建的话太慢了,大概需要 30 分钟左右。因为不想浪费钱开台独立的更高配置的服务器(只用来跑 runner 的话利用率太低了,最差的情况可能一天一个 job 都没),所以这些项目我们一直是人工在本机构建和部署。🤔
最近翻 gitlab 的文档发现 gitlab ci 支持「按需」分配 ec2 来跑 ci job:
🔗
https://t.co/UHiXTxiOSX 这表示我们可以按需使用更高配置的服务器来跑持续集成!长时间没有新 job 的话 gitlab 会自动帮我们回收服务器 🤗
最终我们项目在 ci 上跑一次 build 的时间缩小到 4 分钟左右,解放了我人工运维的工作 🎉
其他一些细节:
1️⃣ 使用 docker in docker 来构建
2️⃣ 除了一些 linux 基础命令,其余命令全部使用 docker 来跑(例如 node, aws-cli, aliyun-cli 等
3️⃣ 构建产物是 docker 镜像,在 ci 中 push 到 gitlab registry 然后部署到服务器
👁 853 ♥ 5 🔁 1 💬 0
能把 build in public 搞清楚的独立开发者应该都知道,打造个人 ip 比产品本身更重要
👁 948 ♥ 5 🔁 0 💬 0
现在想想,90 后 + 选计算机专业,真的是少有的开挂通道了👀
👁 643 ♥ 3 🔁 0 💬 0
👁 596 ♥ 5 🔁 0 💬 0
说件两件可怕的事情: 1️⃣ 在目前这么可怕的就业环境下,明年还将有 1222 万大学生毕业,同比增长 43 万人 2️⃣ 最近的出生人口增长拐点在 2016 年,这意味着大概到 2040 年之前,每年的大学毕业生数量还会不断上升 毕业即失业,找不到工作又去卷考研、考公,往后 10 年可能会越来越难🫠
👁 3,411 ♥ 11 🔁 4 💬 1
最近给 biome 和 graphql-code-generator 提交的 pr 进度都不太顺利,一个因为涉及另外一个大改动暂时卡住了,一个一直没人有空 review 🫠
👁 630 ♥ 5 🔁 0 💬 0
杠杆只是种金融工具,没必要妖魔化,而且现代金融世界想要高速发展也离不开杠杆的
polebug @polebug 最近看到很多大 v 说千万不要开杠杆/合约,我不太认同。 杠杆/合约并不等于高风险,这个命题的关键在于“欲望”,欲望越大,杠杆倍率越高,这样才导致了高风险。 作为一个一开始控制不住欲望爆仓了,但是后面吸取教训,做好仓位管理,现在能轻松翻倍的合约玩家来说,杠杆是一种能快速提升资产的方式。
👁 676 ♥ 3 🔁 0 💬 0
在国内四个不同团队用过 nest.js,其中有三个团队是我主导用的。我们主要技术栈是 nest.js + typeorm + graphql,选择 nest.js 主要是因为它是 node.js 下目前最靠谱的选择。 至于为什么选择 node.js,主要原因有几个: 1️⃣ 在非计算密集的场景下,会比其他很多主流后端语言更容易写出高性能的代码。举个例子,async 相较于 multi-thread,以前在写 java 时,除非用 rx 之流,不然一些复杂的异步问题都不好解决,用上多线程的话,很多时候不合理的锁、线程间交互会严重影响整体耗时,而 js/ts 的 async/await 对这类问题基本是降维打击。而后端恰恰大部分是 io 密集的场景,使用多线程模型并没有优势。 2️⃣ 语言优势。js 有着庞大的生态、社区、开发群体。而 ts 有着现代语言里最强大的类型系统,用于开发大型系统是完全没问题的,而各种现代化的语法糖能提高开发效率、代码可读性。 3️⃣使用 graphql 的「无奈之举」。在目前所有的 graphql 的服务端实现里,node.js 下的是最完善、成熟的。 个人感觉 node.js 其实是创业团队前期很不错的选择,性能上依托于 v8 基本是脚本语言里最快的了,另外在 serverless 领域里,js 也是首要支持的语言。
👁 31,392 ♥ 106 🔁 10 💬 13
偶尔会收到邮件有用户主动愿意付费的,太难得了😆 比真的赚到钱还要高兴。
👁 793 ♥ 6 🔁 0 💬 0
习惯不错。一个哲理「外部状态是魔鬼」,函数式编程的一个核心就是状态和方法完全分离(抛弃 class),这样有助于保证方法更简单、可预测、可测试👀
wwwgoubuli @wwwgoubuli 我不喜欢也几乎从来不使用class 来组织功能相关联的代码,我几乎只用函数。 而我需要把管理的代码组织在一起的时候,我就丢到一个文件里各自export,或者同一个文件夹下。 class 对我而言是一种抽象的“打包”,我喜欢让功能和文件/文件夹产生物理关联。 只是一个小小的个人习惯,看看有没有类似的。
👁 790 ♥ 4 🔁 1 💬 0
📈最近 eth 回本了,要不要换台 mbp max 呢?m1 max 已经用了好几年了🙃
👁 640 ♥ 4 🔁 0 💬 3
真心建议所有开发者把 ai copilot 用起来!🚀🚀🚀 很多人可能严重低估了 ai 对编程效率的帮助,以我自己使用 github copilot 的体验为例,感觉是符合二八定律的。ai 能帮我解决掉本要花费 80% 时间的 20% 的难题里的 80%。约等于能帮我节省一半的时间! 兄弟们,面向 comment 编程是真的爽!
👁 822 ♥ 6 🔁 0 💬 1
一个震惊的现实: 我发现很多工程师(甚至有月薪达到 30k 的),对代码的运行效率没概念。 举个例子,一段看似有很多计算的代码,没深入思考就认为瓶颈在 cpu 就要求升级设备,而现实是计算步骤中会不断把结果写入到数据库,瓶颈完全在 io 上,其实优化下代码就能极大的提升效率。 不得不问,有多少人对「计算密集」和「io 密集」这两个有很明确的概念的?又有多少人对性能 profile 和优化有经验的?🤔
👁 1,191 ♥ 9 🔁 0 💬 3
补充:我小红书总共才发了 10 条内容,目前爆了 2 条
👁 488 ♥ 1 🔁 0 💬 1
repost 下,证明下这还真不是偶然。小红书非常适合获取公域流量,而且用户质量普遍偏高 🤔
nekocode @nekocode_cn 小📕的流量这么大么,新号发了条 po 能给这么多流量🤔
👁 997 ♥ 3 🔁 0 💬 1
我试过很多方法,只有 project scope 的隔离是最彻底的而且最通用的,这样能强迫你把通用的代码摘得很干净
👁 2,309 ♥ 5 🔁 0 💬 0
为什么我非常建议所有开发者在每一个项目都把 mono-repo/workspace 用起来? 一个很重要的原因是因为它能实现对代码的 project scope 的「完全隔离」。这样你可以把常用的代码抽象 & 隔离到一个单独的 project,实现代码在不同项目的快速复用。
👁 47,495 ♥ 234 🔁 21 💬 19
你遇到过这样的事么?吐槽下以前我在某厂的一次经历: 原定颁发给我的某个奖项,因为我已经提了离职,某空降的上上级直接把这个奖项换给了另一个同事😅(还是我的直属上级和我私下说的)
👁 804 ♥ 4 🔁 0 💬 2
一些补充: 1️⃣ 有 X 友好奇我怎么知道的老板的薪资,其实是老板自己告诉我们的 2️⃣ 老板是炒币发家的,自从创业后,据说目前已经烧掉了 8 位数的钱了 3️⃣ 当前情况确实挺艰难,没有收入 + 暂时没拉到新的融资,目前在努力做一些挽救 & 尝试
nekocode @nekocode_cn 最近比较震惊的一件八卦: 老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k,能 cover 住服务器的费用...
👁 1,862 ♥ 10 🔁 0 💬 3
最近比较震惊的一件八卦: 老板跑去外面 remote 当 pm 打工赚钱补贴我们团队了😂月薪将近 40k,能 cover 住服务器的费用...
👁 185,510 ♥ 617 🔁 49 💬 46
今天详细看了下 apollo 对 react suspense 支持,发现支持得真棒👍准备在小破站把 suspense 用起来了,把 loading 和 error 的渲染剥离出去,「别 catch 了,直接往上 throw 吧」👀
https://t.co/bv3wUPRTAF 👁 1,236 ♥ 3 🔁 0 💬 0
今天打开 AWS Route 53 时发现的。如果你用过 JSX,应该对这个不陌生😆 #Memes
👁 883 ♥ 2 🔁 0 💬 1
吐槽下阿里云的 aliyun-cli,和 aws-cli 对比质量差太远了: ❌ aliyun oss cp -f -r ./build/ oss://xxx/ ✅ aliyun oss cp ./build/ oss://xxx/ -f -r 参数都没给处理好。报错信息毫无作用,不得已翻了他们源码才知道问题😅
👁 825 ♥ 4 🔁 0 💬 1
建议有使用 svgr 的 > react 18 的项目都可以使用上
👁 513 ♥ 1 🔁 0 💬 0
提交的一个 mr merged 了:
https://t.co/goPaiD3Cl0 顺便推荐下这个 svgr plugin,可以把导入的 svg 组件的 id 使用 React.useId 给替换掉,这样的好处是:
1️⃣ 保证 ssr 和 csr 后的 id 一致,避免水合问题
2️⃣ 在页面中同时渲染两个组件的情况下不会出现 id 冲突(
https://t.co/LrgA3edM7J 👁 741 ♥ 2 🔁 0 💬 1
👁 722 ♥ 3 🔁 0 💬 0
一个有趣的建议: 一个功能完备、提供开放接口的在线表格,能省掉绝大多数小型产品的后台管理开发成本。 举个例子:
👁 1,919 ♥ 7 🔁 1 💬 4
小破站在0️⃣营销成本的情况下,终于突破 10K 用户了!🎉
这个小破站是我近年来转型 Web 前端后探索 Next.js 最佳实践的试验田,没想到能靠自然增长获得我定的第一个小目标:10K 用户😄
https://t.co/PPaECsaUJw 👁 6,643 ♥ 24 🔁 2 💬 5
小📕的流量这么大么,新号发了条 po 能给这么多流量🤔
👁 3,188 ♥ 7 🔁 0 💬 6
#memes 部署一个 Node.js 项目 be like:
👁 741 ♥ 6 🔁 0 💬 1