https://avatars0.githubusercontent.com/u/5625783

海拉鲁编程客

GraphQL 的一些项目经验

0x00 前言 本文最早行文于 2018 年中,那时 GraphQL 的生态尚未成熟,也缺乏社区总结的一些经验。 2020 年末,复盘一下 GraphQL 的一些使用经验。 名词约定 接口生产端 / 服务端 下面统一称「生产端」 接口消费端 / 客户端 下面统一称「消费端」 0x01 流水的技术方案,铁打的需求。 年幼时看笑傲江湖,华山派两派居然为了剑宗和气宗争个你死我活。 觉得甚是幼稚。 年纪渐大之后发现社会处处充满着这种荒谬的争论。 剑宗 or 气宗 自然美 or 人造美 Java or Python Editor or IDE Rest or GraphQL 单体应用 or 微服务 剑招是死的,人是活的。 打个比方,当讨论问题的时候,下面两个问题意义可能并不是很大。 用剑宗初学者和气宗高手比,或者相反,这个完全没有多大意义? 用剑宗初学者和气宗初学者比,有一点意义,但意义也不是很大。 GraphQL 作为挑战者,下面几个问题是很有意义的。 GraphQL 相比于原先成熟稳定的方案,GraphQL 现有方案存在哪些问题? 新方案解决了哪些原先没有解决的问题。 新方案更低成本解决了哪些问题。 现有的痛点是否存在一些新老方案都无法解决的问题。 有无前车之鉴,有无社区最佳实践。 迁移成本和学习成本是多少。 回滚成本多少。 0x02 RESTful 的缺点 RESTful 有很多接口上最佳实践,但生搬硬套就会使得接口比较诡异。

React Stack

0x00 前言 16 年~20 年先后折腾过 vue 2 angular 4 react class component angular 4 react hooks vue 3 综合考虑了 开发工具链 社区生态 跨端方案 与 Typescript 的结合程度 最后形成了较为稳定的 react 技术栈 0x01 桌面端 https://github.com/twocucao/react-starter react hooks typescript mobx css tailwindcss format with prettier lint with eslint 0x02 移动端 https://github.com/twocucao/react-starter 0x03 小程序端 https://github.com/twocucao/react-starter-remaxjs https://github.com/twocucao/react-starter-taro All Feature Supported By RemaxJS Type Hint - Typescript for better multi-user developing experience style management - tailwind like utils which called minimal.

Modern Shell

0x01 更好的替代品 find -> fd {}: A placeholder token that will be replaced with the path of the search result (documents/images/party.jpg). {.}: Like {}, but without the file extension (documents/images/party). {/}: A placeholder that will be replaced by the basename of the search result (party.jpg). {//}: Uses the parent of the discovered path (documents/images). {/.}: Uses the basename, with the extension removed (party). # Convert all jpg files to png files: fd -e jpg -x convert {} {.

开源认证基础服务

0x00 前言 随着业务的增长,往往需要统一体系内的服务的账户。 经过一番调研,决定尝试一下 ory 的开源认证基础服务 0x01 ORY 尝试解决问题? ORY 提供了四个主要项目,每个项目着力于解决一个边界清晰的认证 / 鉴权问题 ORY Kratos 提供了用户认证服务 ORY Hydra 提供了 OAuth 2.0 & OpenID Connect provider. ORY Keto 提供了 访问控制 ORY Oathkeeper 提供了认证访问代理 0x02 用户认证服务 Kratos 常见方案 方案 1, 选择全栈式解决方案 - 比如 Java 社区的 JGroups 方案 2, 选择 IDaas - 比如 Login With Apple, Google 方案 3, 选择自己来 - 比如 Java 社区的 JGroups 三种方案各有利弊 全栈式解决方案上手极快,但 扩展性不强 绑定 Java 技术栈 数据模型固定 登陆流程固定 更新迭代慢 Login With Google 虽然方便,但是并没有解决如下的问题 更新 Profile 添加第二个恢复邮箱 2FA 存储管理 Sessions 全局登出 自己来,需要处理事情也挺多 方案二遇到的问题,一个不会少 加密算法 流程可能较为复杂,比如先用邮箱注册,然后用 Sign Up Using Google, 或者先用 Sign Up Google, 然后使用邮箱登陆。(PS: 我国的登陆姿势就更多了) 是不是某种方案是最好的呢?其实未必

如何写出整洁的 Python 代码 下

0x00 前言 本文是《提升你的 Python 项目代码健壮性和性能》系列的第八篇文章。 本文是《整洁下篇》,本文的诞生,要感谢我前公司的技术主管豪蔚老师和产品主管刚哥,在上海工作这几年,总是和能优秀的人工作,确实是我幸运的地方。 这篇文章憋了很久,思考了许久,《整洁下篇》干脆就聊聊编程中,不是写代码的部分; 如果说,写代码是硬技能,那么本期就是来聊软技能的。更确切的说,是复盘几年的工作经验中,我发现的一些有趣的,影响效率的事情以及我的解决方案。 凡用兵之法,全国为上,破国次之;全军为上,破军次之;全旅为上,破旅次之;全卒为上,破卒次之;全伍为上,破伍次之。是故百战百胜,非善之善者也;不战而屈人之兵,善之善者也。 — 《孙子兵法·谋攻篇》 什么叫做有效率,不战而屈人之兵,善之善者也。 最整洁的代码,是少写代码,甚至不写代码。 如何做到? 几年的工作经验下来,我发现我处理的往往不是技术问题,而是大量的非技术性问题以及伴随着非技术问题带来的成倍的技术问题。 因需求的变化的返工。 因追求完美而为了不必要优化的地方而优化。 因沟通不到位导致的加班加点。 因缺乏单元测试导致的重构没有底气,甚至懒得重构。 因缺乏话语权导致的被动开发。 因考虑不周到而导致的硬着头皮加班。 因命名不够规范,代码可维护性低下,导致后面定位问题的时间指数性上升。 应然如此?实然如此! 0x01 处理需求的姿势 以前呢,我自以为编程水平还算不错,撸起代码来像是一道春天的闪电。但时间长了,发现技术行,但总体产出不高效。为什么呢? 比如有如下的问题: 问题一:战术上很勤奋,一个需求过来,我的第一反应是把这个功能『通过系统』做出来。 问题二:没有深入和产品运营沟通,于是后期被动的应对需求的变动 问题三:没有三思而行,做项目没有计划性,想到哪里做到哪里。 问题一的结果:这导致了很多时候,把这个功能『通过系统』做出来了,但是其实是个伪需求。或者,是个没必要做到系统里面的需求。 问题二的结果:导致了一些过度设计或者过于粗糙的设计。最后忙于返工,以及各种数据迁移和逻辑修改 问题三的结果:没有做好足够的规划,『码在当下』, 没有前瞻性。 速度再快,也要返工,唯一不变的就是变化本身。 我想了很久,才意识到,很多时候,产品在传递需求的时候是存在很多的信息损失的。 背后的原因,可能来源于产品的态度和能力上,可能是产品的上一级需求传递过来的问题,也可能是团队对待产品以及自己的错误的态度上。 经验告诉我,作为对项目负责的程序员千万不要跟着产品经理的思路走。 如果是新功能,一定要就要展开一番对话。 问清楚为什么要做这个需求 / 变动,藏在后面的思路是什么。对于用户、对于产品有什么价值。 和产品经理互杠,用户的具体使用场景是什么。 看看是不是一定要放在系统里面解决。如果放在系统里面解决,那么应该怎么做。让产品方给出一个粗糙的方案。 化简这个方案后再次和产品互杠。 确定方案后分解安排任务。 任务上线之后如何确定这个功能是有效果的。 还记得上面的话么?不战而屈人之兵。 要做的需求,如果产品经理不能简单清晰的描述,做出来一定是一坨。 作为合格的工程师,则是必须要将不清晰、不合理的、拍脑袋的需求拒掉。所谓上梁不正下梁歪,出题人的思路是混乱的,解答者的思路肯定不会清晰到哪里去。 当然,这也存在一些例外的情况,如果你到了一个工作地方,没什么话语权,认真推进事情发展也没什么暖用的地方的话,好好反思一下自己为什么在这种地方干活,然后认真修炼自己。 早些年,我还以为有时间不够的情况,后来也逐渐明白,没有开发不了的任务,程序写到后面都是妥协,无非就多快好省的妥协 多 - 功能的数量和完成度 快 - 完工时间 好 - 软件最终质量,满意程度 省 - 成本,花多少个人力和精力 鱼和熊掌不能得兼

如何写出整洁的 Python 代码 中

0x00 前言 本文是《提升你的 Python 项目代码健壮性和性能》系列的第七篇文章。 上篇《如何写出整洁的代码 上》 从变量命名 / 函数 / 注释整洁 / 格式整洁上写出干净的代码 https://zhuanlan.zhihu.com/p/59510165 本文还是通过代码上的一些小技巧和一些原则来让代码更加整齐。 0x01 避免过深的缩进 场景,你在做一个 B2B2C 的商城系统。商家的活动需要在某些比较严格的条件下才能参与(假设有五个字段吧)。 如果不动手捋一捋判断的路径,上来就动手写代码,则很容易写出如下的代码。 if cond1: dosomething() if cond2: dosomething() if cond3 and cond4: dosomething() else: dosomething() if condx: dosomething() else: if cond2: dosomething() if cond3 and cond4: dosomething() if condx: dosomething() 想想你这个时候才判断了 5 个字段… 如果想都不想就开始写这种代码的话,就做好修改的时候崩溃吧。 当你写出 if 超过两层缩进的时候,代码的复杂度就值得注意了。 这个时候,应该火速的拿出纸和笔出来,快速的捋一捋所有的变量和情况, 『以减少缩进为目标』 能提前判断掉的就提前判断掉 # 能提前判断掉的就提前判断掉 if cond2: raise AlreadPaid(): if cond3: raise ActivityExhaused(): if cond4: raise ActivityCancel(): 代码的缩进越浅,代表着代码越容易维护,用学长的话说,老手才知道『九浅一深』的奥妙……

如何写出整洁的 Python 代码 上

本文是《提升你的 Python 项目代码健壮性和性能》系列的第六篇文章。 接下来的三篇,围绕另一个主题 如何写出整洁的代码 『整洁』三篇是基于**『代码整洁之道』和『架构整洁之道』**的一些切身的理解和体会。 感谢这两本书的作者 Bob 大叔。 PPS: 某东读书 VIP 会员有不少 IT 资源类的书籍可以免费看,比如『代码整洁之道』 0x00 前言 软件系统的腐败之路 随着项目代码行数的增加,不可避免的遇到软件架构腐败的问题。 具体表现为:随着每一次产品版本的发布,对现有流程进行优化和修改就格外的费事和吃力。工程师的生产力就开始直线下降。 所谓 眼看他起朱楼,眼看他宴宾客,眼看他楼塌了。 清 孔尚任《桃花扇》 0x01 讨论 为什么会出现腐败的系统 原因可能是多方面的,比如常见的场景: 步骤 1. 领域建模的人对业务里概念的理解不到位,流程不深入了解。 步骤 2. 工程师在实现的时候,按照自己的理解,没有梳理整个流程。就开始动手实现。并且全程人肉测试。 步骤 3. 需求变动,流程更改。 第一步容易埋下坑点: 对『该领域』理解的不到位,导致『流程』就不清晰,也导致原型设计等同于 Axure 画的『表单』。 『关键概念』没有解释,『关键字段』没有解释,也没有『流程图』,也没有关于业务主体『状态图』,前后端面向表单开发。(Form Oriented Programming) 接着,领域理解不到位就会带来另一个问题。 对于需要『建模的实施者』一般是后端工程师,将花费比较多的时间来梳理流程。 前后端代码结构不清晰。比如,前端页面的路由命名不清晰,Page 组件命名不清晰,请求 API 接口不清晰。比如,后端路由命名不清晰,view func 不清晰,serializer 不清晰,table 命名不清晰。 经验老道的程序员会通过一些手段,比如让这些命名不清晰的东西统一一下,然后等概念清晰了。再改回来。 第二步容易埋下坑点: 全程口头对需求,『没有文档』落下来,产品之间和开发之间**『缺乏共通的文档理解指南』**。 当更改已有流程或者是出问题的时候,除了一脸懵逼就还剩下甩锅了。

Python ORM

0x00 前言 Python 圈内三大 ORM SQLAlchemy VS Django ORM VS Peewee SQLAlchemy 复杂程度最高,同时,这也意味着 SQLAlchemy 可以做更多的事情。使用 DataMapper 方式实现 Django ORM 个人最喜欢,使用 ActiveRecord 实现 如果不是因为现在 Flask 项目已经是用了 SQLAlchemy , 否则的话我甚至会考虑将 Django ORM 配置到 Flask 项目中。当然,也有蛋疼的 SqlAlchemy 使用者已经移植给 django 配置了 SQLAlchemy 的库。 Peewee 没用过,不好评论。以后有机会试试。 0x01 如何访问数据库 那,既然已经可以访问数据库,本着『如无必要,勿增实体』的原则,为什么要不辞劳苦的用个库呢? 0x02 数据库抽象的两种理论 理论一:Active Record 理论二:Data Mapper 0x03 数据库抽象的两种实现 实现一:Django ORM 实现二:Sqlalchemy 0x04 工具的强弱 https://www.thoughtfulcode.com/orm-active-record-vs-data-mapper/ 2.0 SQLAlchemy VS DjangoORM ORM 通常有 DataMapper 实现和 ActiveRecord 实现两种。

如何优雅的使用 Windows 10

0x00 前言 最近入手了 SP6, 于是把 2015 年写的这篇文章修订为 2019 版 笔者已过了爱折腾的年纪,仅从提升工作效率方面来说。 背景: Pythonista && Nodejs 工作机 MBP 2017 款机器 生活机 Surface Pro 6, 轻办公,有时也用来调试 Windows 上的程序。 本文目录 ▼ 0x00 前言 : section 0x01 文件整理 : section ▼ 0x02 自带功能 : section 2.1 快捷键 : section 2.2 触摸板 : section 2.3 Win+R -- 运行 : section ▼ 0x03 必备软件 : section 3.1 文件管理 : section 3.2 资讯浏览 : section 3.

如何通过测试提升 Python 代码的健壮性

0x00 前言 本文是《提升你的 Python 项目代码健壮性和性能》系列的第二篇文章。 本文的测试更多专注于 Python 后端的程序员。 在上一篇文章中,我提到了代码覆盖率,即测试的一种指标。 本期就聊聊测试这件小事情。 0x01 测试的分类 测试有很多种, 按照测试设计的方法可以分为: 1. 黑盒 2. 白盒 按照测试目的: 1. 功能测试 单元测试 功能测试 集成测试 场景测试 A/B 测试 2. 非功能测试 压力测试 安全性测试 可访问性测试 其他 回归测试 易用性测试 还有不少,懒得去整理了..... 代码覆盖率顾名思义,就是测试用例覆盖运行代码的比重。 后端主要关注哪些测试 单元测试 功能测试 端对端测试 性能测试 0x02 为什么要写测试 来讲讲测试的优点。 为什么要写测试来覆盖代码。 适当的测试可以让发布代码的时候更加有底气。 适当的测试可以让新手更快的了解代码。 适当的测试可以让程序更容易重构。 适当的测试可以加快团队的开发速度。 既不是不写,也不是狂写一气。看到这里你可能有些疑惑?写测试还加快速度?Are you kidding? 一个一个来解释吧。 举个简化版本的例子,『用户下单』到『用户收货』。 用户『查询产品』 用户『使用优惠券』下单 用户『在线支付』。当然,用户也可以让不付款,让订单失效。或者直接取消订单。 商家『确认发货』。 物流公司更新运单『发货中』。 用户『确认收货』。当然,用户也可以发起退款。 让新手更快的了解代码 测试用例里的数据,往往是能跑通某段代码的最佳测试数据集合。 假如,有个程序员写了 『下单-在线支付-确认收货』的集成测试。作为刚接手这段代码的人。可以在最短的时间内,通过阅读测试代码从而理解整个流程。