@leighton

gnome3 和 mac 没有什么区别吧。
专注只是在一个屏幕上专注，所以毫无问题，
你切换还是有很多快捷键，多工作区，dock，多桌面都是支持的啊。

我个人觉得 gnome3 就很好，确实让我专注。

Joplin 加这个可不容易：

Joplin 没有自己的同步服务器，采用通常是第三方 webdav 之类；
密码保存在哪里？
这个密码需要同步吗？

x 云，竞价实例，自动管理

首先感谢作者对开源的贡献，
然而比较无法回避，
避免被比较的唯一办法就是胜出。

@wasd6267016
@shmilwdc
@mazyi

本想表达晚上不加班，没想到。。。

你们是对的，我错了，抱歉。

@xiaochong0302

我们的是

const LEVELS = [
self::LEVEL_JUNIOR =>'初级',
...
];

不用方法，除非需要逻辑判断的。


当然更理想的其他语言的 enum 类型，就少了一层定义，且可以采用位运算符。
use MyCLabs\Enum\Enum;

class Gender extends Enum
{
public const MALE = '男';
public const FEMALE = '女';
}

表内创建人字段和更新人字段，只存了 name，没有存人的 Id 。当时想着是应该只关心是谁做的操作，所以没有加入 id 的关联关系。但是实际上在表设计中有关联关系但是不存关联信息的数据干脆就不存，要存就都存。

我这里建议假设 post 表，需要保存更新人，那么增加是 post.update_user_id 就行，除非需要经常 “select fields from post where user.fullname like ?”，那么需要加一个 post.update_user_fullname 字段



关联表的索引关系一定要明确，该做约束的约束。该设置必输的设置必输。

数据库设计的时候一定要按最严格的约束去，但是不要嵌套删除之类的。对于可选的字段，用 null 而不是 0 或者''。



部分在代码中或者项目里比较高频的字段，表设计时最好加_info 。

什么鬼？ 有必要吗？ IDE 不会自动提示 field ？
用户名表的用户名是高频字段，所以需要 user.name_info 吗？ XJB 折腾吧！




英文尽量要合理 比如创建人不应该是 create_name 合理的应该是 creator_name，这块当时设计的时候想的是 creator_name，但是为了和创建时间和更新时间对应就统一变成了 create_name 和 lst_name 。

前面已经有答案。created_at, updated_at,create_user_id,ower_id,admin_user_id,create_username,create_user_fullname 需要根据项目和字段实际用途和存储关系来。



架构设计是门艺术，这门艺术的核心是可维护性，开发效率以及运行效率的恰如其分。

难道不是以后不听话方便跪吗？

这是一个适合技术开发者的商业点子！

表名就可以表示自身了，所以没必要加前缀，除非外键 order.user_id 这样的

经销存等等都可以无代码和低代码。

氚云，宜搭，简道云，明道云，SeaTable 。。。

可以说是当前和接下来的风口。


公司一套几十人用的经销存+CRM 就是用的 XX 。

@tachikomachann

同意 #35，

没毛病，房子只是你一人的，写了你一人名字，属于婚前财产，估计房贷还没还完，
如果你要离婚，她确实什么保障都没有啊。

首先恭喜，好好锻炼下，下次找工作就是小组长负责人起了。

团队管理最重要就一点：人们追随你时因为爱戴你。

@shiny

etf 反向对了怎么亏钱？求教？

我还以为保持年轻的秘诀就是不要笑，因为： 皱纹 --- 是你笑过的痕迹。

结果，段位差了太多。。。

买一个小主机，自动同步到云端。

“欢迎使用小米自动驾驶系统，系统正在启动！”
广告播放 60 秒钟后，
“系统已启动，正在等待下一个绿灯“。

35 之后收入下降 ？
不成立。

所以现在能买就买呗，一线大跌概率很少。


当年我就是深圳 2W 没买，买了长沙 7K 的，现在回长沙几年了压力没深圳大，也不用三点一线做社畜，但是总资产相对就少了几倍吧。

没办法，靠工单收费保持增长了。