@
mooyo C# 在工业领域有着绝对的优势. 很多设备都是 winform 拖拽的一个桌面程序与设备通讯,单机运行. 完成数据采集,记录, 甚至控制. 早先很多工业软件和组件都是基于微软的 COM 技术,且 winform 的拖拽开发个界面极其简单.导致很多电气工程师身虽然不是软件出身,但是依据厂商给出的范例,照葫芦画瓢,拖拽个程序就能跑.
这就体现出 C# 的低门槛,且强大. 因为设备一般都是 7x24 小时运行,程序可能几个月不关. 而 c#能让"面向对象"都不懂的人,写出稳定运行几个月的程序.
另外我是因为工作需要才被迫使用 C#,一开始也是认为这是上古语言了.....直到使用一段时间后,嗯..真香!.
C# 语言本身很多特性都是很优秀的,LINQ,委托,操作符重新,dynamic 类型,再就是各种语法糖. 很多其它语言津津乐道的小特性在 c#早有实现.
计算机语言本身就是一种逻辑的描述工具. 无非就是 变量,条件判断,循环,函数,类,对象,功能块. 这些知识.
但是不同的方向会依赖特定领域的知识.
1. 游戏: 我仅仅了解过概念,坐标系的处理,物理引擎,动画渲染等,还是比较杂的.
2. 后端: 基本上是围绕 Http 协议展开+缓存+数据库+服务治理,捎带一些运维的知识(也或许得负责运维...)
3. 桌面端:避免不了 GUI 的开发,这点与前端类似.甚至概念都类似. 但是会涉及到一些多线程,文件处理,通信处理,数据库.
以上三个领域都有其他语言可以实现,且领域知识就是一套. 所以更应该的是学习领域知识.而不是纠结语言上怎么学
还是 IPhone,真心觉得安卓系统下应对各种花里胡哨的后台广告,垃圾应用太烦了. 就想流畅的打开软件,玩玩游戏.而不是把精力放在怎么跟垃圾 app 折腾上.
投简历时,可以过 HR 的邮件筛选,或许能给你打个电话,或者得到一个面试机会. 而不是直接被过滤出去.
舔狗舔狗,一无所有. 没错,也是在说楼主.
为啥在发现她和小三一直没完没了的时候,不戳瞎自己双眼.
所有争论,解释都无法去改变一个人的心.倒不如成全人家俩,你是怕自己找不到更好的?还是觉得你能拯救人家?
关键是 影音资源库 以及 资源的音画质量(4K/8K HDR,杜比音效之类的) .
资源库决定了,你能看到什么内容. 与硬件无关
音画质量决定了,你看到的效果是怎么样的. 与硬件相关,网速,电视机画质,音响效果
Infuse 是个软件,只负责管理影音资源. 以及播放. 但是影音资源从哪里来,质量如何.需要自己去解决,或者花钱解决. 也可能需要自行花钱解决(搭建 NAS,又累又花钱,还得自己找资源,家里占地方,耗电.....) 这一点需要自己想清楚.
我觉得要看自己平时的观影习惯.
1. 以英美剧,电影居多,且画质有一定要求: Apple TV + 大流量机场 + Netflix/Disney(账号拼车即可) + 千兆网 +[可选:音响系统]= 极致体验
2. 以国内多媒体资源,电视剧,综艺居多,偶尔看一下电影: 目前电视就行(国内流媒体画质相对国外流媒体画质差很多,无需担心电视参数不够的问题), 爱折腾的话, Kodi + Emby(公益服/收费服)都行. 看看电视,别人整理好的电影. 挂个 网盘,平时自己找点想看的电影. 完全够用.
我认为是源自于根深蒂固的 "等级" 观念以及不自知的 "奴性". 不尊重规则
领导会认为自己高高在上,可以随意安排下属工作,最不尊重公司规定的,基本都是领导
而不自知的"奴性"会为了讨好领导,同时领导安排的工作,即便违反规则,也是领导安排的
当底层员工升迁后,这种模式就会继续延续下去
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% 情况下不存在.大家几乎都是自己岗位的熟练工而已....如果不信可以找公司会计问问,如果要开发一个 财务系统,希望他给你讲讲财务领域的知识,同时让他给设计建议,保证你最后实现了,也就你们公司能用. 根本达不到 财务领域 通用的程度.
一堆人费劲心思提出了这么个 Promise 规范,解决异步带来的麻烦, 然后你要在这基础上硬生生的在退回原始方式....