🤗不上班之后,收获很大

🤗不上班之后,收获很大
Photo by Lawrence Chismorie / Unsplash

首先不再想着通过一个产品暴富,这种虽然很吸引人,但很多人都没看到成功者背后的努力,市面上很多产品都有竞品,为什么是他成功了呢

很多拿到结果的独立开发者也好,卖课的也好,他们付出了非常多的努力,并不是如表面所说“割韭菜”那么简单,很多人在很早之前就非常牛逼了,单纯的依靠运气起飞,我现在已经不信了,大力出奇迹,才是王道。

不再想着别人非常需要一个程序员的代码,代码就是快消品,不再执着于细节,不如等到产品有用户了,再为了优化用户真实的体验而开发。

要做产品的话,遍地都是点子,去 X 看一天,你能收获一年都做不完的产品的点子,至于是否能挣钱,另说

将自己当做一个销售,将产品卖给用户,才是最屌的,我彻底摆脱掉了程序员觉得自己技术牛逼就则怎么怎么滴的想法了

坚定的做个人 IP,水滴石穿,持续输出有价值的内容,积累粉丝,是这个时代,每个人都应该做的事情

处理好家庭关系,稳定的家庭关系,是一切事业开始的基础。

保持乐观,这点很难,国内教育,感觉根本没有教人们如何放松,反正我感觉是没学会,因为我这边房子不贵,我在没有房贷压力的情况下,还是会习惯性的焦虑,但是焦虑解决不了任何问题,我现在正在跟自己和解,告诉自己,挣不到钱没关系,认知提升了,也实践了自己之前上班的时候,一直想尝试的想法。如果实在挣不到钱,就接外包,实在接不到外包,就想办法找远程工作,如果实在找不到远程工作,我还重新投简历,大不了薪资少要一些,反正不会饿死。我必须先让自己开心起来,再去做这种不知道什么时候能有收益的事情,不然挣不到钱,心态还崩了,岂不是太亏。

今天不上班大概四五个月,到手的钱,比着上班差不多,但是不稳定,明年会继续探索,低消费,做自己觉得有意义的事情。

我是属于比较冲动的,想着自己先走起来,在路上发现机会,寻找伙伴。

Read more

从事 SEO 12 年的大佬总结的要点

从事 SEO 12 年的大佬总结的要点

从事 SEO 12 年后,以下是我能想到的所有 SEO 技巧: 1. 在 H1、H2 和 URL 部分中使用主要关键词。 2. 停止追逐虚荣指标。流量固然重要,但转化率才是最重要的。 3. 内部链接可以将“几乎完成”的页面转变为表现最佳的页面。 4. 定期检查你的网站是否有坏链接,这是一个简单的 SEO 胜利。 5. Google Search Console 是您最好的朋友,使用它来重新优化排名在第 3-7 位的页面。 6. 90% 的反向链接应来自相关的高权威网站。 7. 速度决定一切——或许应该说,速度不足会扼杀一切。确保加载时间在 2 秒以内。 8. 持续更新内容将帮助你的页面保持更高的排名。 9. 使用 NLP

Pnpm 构建 Monorepo

Pnpm 构建 Monorepo

最近开始搭建 monorepo 的项目,了解到以下方案: * lerna 有强大完善的依赖管理和构建、打包发布流程,而且 v5 版本将 nx 与 lerna 整合了,提升了性能和速度 * 业界大多使用 lerna + yarn workspace 的方式来管理,yarn 用来管理依赖,lerna 用于管理发布 之前简单使用过 lerna ,不过再加上 yarn workspace , 学习容多、配置多又得折腾,太费劲🤪,暂时搁置。 最终尝试使用单一的 pnpm workspace + changesets 的方式来构建 monorepo,本身我就使用 pnpm 作为包管理工具,目前我的场景简单,pnpm 就已足够。 本文记录自己使用 pnpm workspace 搭建 monorepo

HTTP Web 缓存总结

HTTP Web 缓存总结

友情提示:缓存什么的,是完全依赖相关http header头信息来标记和判断的 缓存读取顺序: 首先读取本地缓存,如果条件满足就取本地缓存,否则往后走代理缓存,同理,条件满足就是从代理缓存取资源(可能存在多级代理缓存) 如果一条链路上的资源都不符合,那么就去源服务器获取 缓存优先级:Cache-Control > Expires > Etag > Last-Modified 缓存的分类和优先级 * 强缓存 状态码 200 (比如 200 (from cache)) * Expires 服务器下发的绝对时间,而判断的时候以浏览器时间为准,客户端和服务器有可能会不一样 * Cache-Control 相对时间,以客户端相对时间为准 * 协商缓存 状态码 304 * Last-Modified If-Modified-Since * Etag If-None-Match 强缓存优先级高于协商缓存,强缓存不会询问服务器,直接使用缓存。协商缓存会询问服务器关于文件的可用性 对于传输过程中的中间节点,本文都称为代理服务器,包括proxy、

关于 Webpack 使用 Babel 与 Vite 使用 ESBuild 的一些思考

关于 Webpack 使用 Babel 与 Vite 使用 ESBuild 的一些思考

虽然 Vite 是基于 esbuild 构建的,并且 esbuild 在构建速度上有显著优势,但 Webpack 目前并没有直接使用 esbuild 构建的原因涉及多个方面,主要是 架构设计差异、功能需求 和 兼容性 等问题。下面是一些关键的原因: 1. Webpack 的复杂性与扩展性 • Webpack 的高度可扩展性:Webpack 的设计目标是一个 高度可配置和可扩展的打包工具。它提供了丰富的插件和 loader 机制,支持各种复杂的构建需求(如代码分割、热更新、各种资源处理等)。这些功能要求 Webpack 必须具备更细粒度的控制能力,而 esbuild 的设计理念相对简化,主要关注高速构建和基本的模块转换功能。 • Loader 和 Plugin 系统:Webpack 的强大之处在于其 loader 和