ming159 最近回复了
我认为是源自于根深蒂固的 "等级" 观念以及不自知的 "奴性". 不尊重规则
领导会认为自己高高在上,可以随意安排下属工作,最不尊重公司规定的,基本都是领导
而不自知的"奴性"会为了讨好领导,同时领导安排的工作,即便违反规则,也是领导安排的
当底层员工升迁后,这种模式就会继续延续下去
AI 负责处理所有数据,并做出分析和决策, 人为 AI 从现实社会中收集信息.
天网系统-----------------------人类. 开启现实版黑客帝国
原来不止我发烧就做同样的梦啊.我的梦是这样的: 在一个没有边际的空间中,一个不规则的立方体不断的变换着,但是整个感觉是非常压抑被死死的束缚着, 如果突然松开后,也就醒了,就是一身汗,基本就退烧了
@
jimmyczm 视经销商良心而定 !!!, Intel NUC 出厂只有主体. 硬盘,内存,电源是经销商自己搭配的.(可以咨询 Intel 售后) 所以,这三个部分给你配的好就还可以,质量差就各种问题. 我们因项目需求陆陆续续采购了快 50 台了,目前出问题的已经有 7 台左右了....... 拆开后你会发现各种品牌的内存和硬盘都有
觉得力不从心应该是指 对目标任务的拆解力不从心,无从下手的感觉.而是某个语言学不会. 我相信让你做个视频转码的小工具,把一个视频转码成另外一种格式.是能做到的. 但是让你写一个应用软件.这就是涉及到软件工程了.
界面布局
人机交互
文件系统
存储,通信等等最后还要整合到一起. 需要系统的学习,也需要经验...
1. 一个 CPU 核心,在一个具体的时间点,注意是时间点,比如 某 xxx 纳秒的时候,是仅仅有一个线程是运行状态,而其它 9 个都不是. 建议复习一下 线程的生命周期. 另外,线程是你代码执行的容器,并不是你代码本身. 当你代码在某个线程中执行完后,线程就销毁了. 而线程池则是让你代码执行完后,线程并不销毁,而是重复使用. 再就是线程安全主要指的是内存中变量的读写在同一时刻只有一个线程可以操作.
2. 并发数超过线程数后,请求确实是排队中的. 只不过每个请求的处理时间很短,基本毫秒级别就结束了. 打个比方,某个请求处理耗时 5ms,那 1 个线程 1 秒就可以处理 200 个请求.理论上 10 个线程就是 2000 个请求,但线程切换是也是要消耗时间的.所以实际上达不到 2000,也正是因为线程切换要消耗资源和时间所以线程数不是越大越好.
尽管总结的字数很多,但看起来没有触及到根本问题. 需求调研没有做细致,缺少架构设计能力.任务拆分不合理.
需求调研不细致,才导致各种 "万万没想到"; 才会让你低估项目难度, 进而导致任务分配给了不合适的人身上.
缺少架构设计能力,4 个项目,老框架,中间件,插件,设备,按理说应该先收集评估相关技术,然后设计整合的架构方案.然而并没看到,而是直接分配任务了. 也会导致任务分配给不合适的人.
制造业工厂一个工厂也就一个 IT 部门,维护一下网络,电脑等,即便是程序员基本也是写点小脚本,主要还是与外包沟通需求,跟进项目进度为主.
但有一类公司,非标自动化公司,无论大小,基本都会有那么几个软件开发,目前先进一点的用软件+板卡的形式控制设备,low 一点的与 PLC 交互做采集,做所谓的数字孪生或者智能工厂
我来说一下 1/1000 DDD
1. 问题领域识别: 明确你面对问题所在领域. 例如 你要完成一个用户登录功能. 那么 往大了说,这属于 "信息安全领域"
2. 领域建模: 将这个领域中的处理模型搞清楚,并映射为对应的计算机语言设计,例如面向对象设计,将这个领域中的对象设计出来.
所以,起始最核心的是 "领域专家 " 这个角色,他有充分的专业知识和经验 能够给最初设计给出完整的领域知识的指导. 而程序员通常是计算机的"领域专家",并不是信息安全领域的,也不是 财务方面的,也不是仓库,物流,运营方面的. 如果领导让程序员去 DDD 本身就不是靠谱的事.
再退一步,其实实际工作中,"领域专家" 90% 情况下不存在.大家几乎都是自己岗位的熟练工而已....如果不信可以找公司会计问问,如果要开发一个 财务系统,希望他给你讲讲财务领域的知识,同时让他给设计建议,保证你最后实现了,也就你们公司能用. 根本达不到 财务领域 通用的程度.