租售比低是事实,
不过主要原因,还是房子作为蓄水池,它的价格被捧高了,显得租金低。
因为租金这玩意,房子本身价值是一部分,还跟地区收入有关。 房子再贵,最高租金,只能出这么多,比例就升不上去。
现在房子价格下跌,确实是房主在吃亏。
不过房价跌了,租金不降,比例也会升上的了。
楼主的担忧我能理解。比如一个发送端,一个接收端。
我当然希望每次接收端收到,都是一个完整的消息,不就能直接处理了么?
但如果这个消息,真的很大呢? 或许他一次发送不完,那我收到的就不全。我要等,这可就麻烦了呀。同样的,下一次把之前的尾巴,跟下个报文的头給一起发送了,我还得拆,更麻烦了。
嗯。Tcp 它就有这种操作,这不是它的问题,而是它的设计,就是基于 Stream ,像流水一样一直给你灌数据。 底层打散但是保证消息还是前后有序进来的。对于这种流,需要按流的处理方法,收取后进入缓冲区,然后在缓冲区里,根据协议里面的约定,比如固定包头,特殊符号来解析出内容。
而这个就是 HTTP 干的事情。 所以你的需求,用 HTTP 就可以实现。你可以认为 HTTP 接口每次拿到的,就是完整的数据。
WebSocket 也可以。
对我来说,首先是 NAS 的本身涵义,网络附属存储。
家里最初只有一台主力电脑,游戏,照片,电影等数据都在这里。这时对网络存储,没有需求。
但是渐渐的,家人们随身的手机,床头的平板,客厅的电视。这些设备,他们的存储容量偏低,自身的数据比如照片等等,需要经常导出;另一方面,类似看电影电视剧,又需要从外部拉取文件。
这个时候还靠那台已经不怎么开的主力电脑,干这个事情就不太合适了。
需要专门有个网络存储,供局域网里的设备共用。
我也试过一些方法,比如说,在家庭 Wifi 下挂载一个移动硬盘。权宜之计,能用,但可以更好。
所以当有了折腾的余裕后,就买了硬盘盒,加上小主机,自己 diy 了一个 NAS 。
实现了本地网盘啊,本地媒体库啊,电影分享,照片备份等等功能。
拥有了 NAS 后,从另一个角度,就等于有一台家庭服务器。那自然可以整点服务器的东西玩玩。挂一些服务,搞一点应用,这时 NAS 就是个容器。
我所知道的响应式设计,是一种布局思路,用这个思路,对不同宽度的屏幕,都能给出一个相对合理的排版。
这里的不同宽度,不仅仅是 PC ,也有 Ipad ,折叠屏,甚至手机横过来。
这个思路的要点,是优先考虑屏幕窄的情况,满足最窄屏幕的布局后,对于更宽的屏幕,可以扩大间距,拉伸组件,增加分栏,总之把它填满。
这里面竖屏手机是最窄的,所以响应式设计,也以“移动端优先”。
这跟业务上 PC 端摆烂,专注 APP 那种“移动端优先”,不是一个意思。
但实际效果,普遍没有想象中的好。首先因为手机的屏幕,相对于 PC ,实在是太窄了。手机 APP 很多是用层级菜单,底部导航栏等适配手机的组件,这些东西放到平板那个宽度,就不好沿用了,想好看的话,还是得重新设计布局。
其次,响应式设计,你得用它的栅格系统,这样的话,你的组件的宽度,组件大小,都是被限制的,不容易跟设计稿对齐。
所以我看现在像 douyin 这种愿意做 web 端的,也都是分两块。移动端弄个 m.域名,直接给你干到 app 下载页,web 端重新设计,从平板的宽度开始,向上用响应式。
Python 本身就是强类型语言,只是它提供许多默认的转换,让你可以直接转数据类型。这点写脚本很方便,不然 JS 也不会有那么多 [魔法]
现在 Python 也有代码类型标注,写的时候带上这种也是可以的。
第一个问题:
现场设备是 A , 物联网平台是 B , 手机应用是 C
A 要主动把数据,按 B 定好的格式,传给 B 。 然后 C 按 B 定好的接口,从 B 查数据。
C 要控制 A ,就按 B 定好的接口,給 B 发命令,B 收到命令后,转发給 A 。A 收到后执行。
B 对 C 开放的是 HTTP 接口,或者 Websocket 接口,不涉及到 Native ,所以 C 该怎么开发怎么开发。
Flutter 还行,RN 略有过时,写过 React 可以路径依赖,没写过推荐 Flutter 。
第二个问题
A 跟 B 怎么连,两种情况,
如果 A 本身是一个能主动往外推数据的设备,那么它默认有一个对应的 A*平台的格式,你可以自己搞个 B ,兼容 A*的格式,然后修改设备的发送地址。或者你就用 A*的平台,自己写个中间件去拿。
如果 A 本身不是所谓的物联网设备,那么它一般不会是一个能主动往外推数据的设备,需要放一个网关 D, 转成能往外推数据的设备,D 一般有个对接的平台 D*,你可以用它的平台,也可以兼容 D*的格式,弄个自己的。
像阿里,aws 那种,希望你是一个设备生产商,让你的设备,直接接入它们平台,让它们来代管。对你来说,中间的数据存储,流转,就不用你自己操心了。
说说我的体会,
1. 写刷法题,完成小作业,这种场景 C++和 Java ,没有太多区别。
2. 有 IDE 的加持下,用 C++写 windows 桌面程序,和用 Java 写 Android 移动端程序,体验也差不多。同样的模式,都是在预设的框架里按套路写。
3. C++写网络编程,就比较麻烦了,Java 写则很简单,或者说,不简单的地方,已经有高手为你写好了。
4. C++写完了并不算完。头文件管理,交叉编译,调试等等都费劲。尤其一个叫 cmake 的东西,当年把我狠狠干住了,发现没有 Visual Studio ,咋干啥都不顺。Java 这块就轻松多了。
后面用 JS ,Python ,又体会到一种语言在“领域内的垄断”。 比如 JS 在前端,Python 在科研,JAVA 在网络,那 C++呢,则在所谓的高性能领域,什么游戏引擎,网游服务器,音视频处理,高性能硬件开发等等,这个领域本来就费脑子,开发效率天然就低。
我想到上学时候的一个梗:
什么时候可以抄作业?
1. 遇到你会的题目,可以抄作业,节省时间
2. 遇到你不会的题目,可以抄作业,学习思路。
所以遇到会与不会的,都可以抄。
但抄作业不是目的,掌握知识,应试技巧,锻炼题感,拿到高分,这才是目的。
而如果只应付每天的检查,盲目的抄写,几个章节后你很可能就不知道你在抄什么了。
文章反映的也是类似的问题。
我们现在用 AI 编程风生水起,有一个前提被有意无意的忽略了,就是大家多多少少在没有 AI 的时候,学习过编程,有些底子,你去抄 AI 的东西,有底。
倘若过于依赖 AI ,就好像只抄答案不看过程,那久而久之,也就看不懂过程了。不就文盲了么。
@
Curtion 有些做硬件的厂商,它想上云会用类似阿里这一套,终端适配阿里,然后不用自己云平台后端,按他給的范式走配一配就行了。
多少有点先入为主的感觉,我是从启蒙阶段用的 vs ,
后来用过 idea 一段时间,那会也感觉 idea 是什么垃圾 啊,用不习惯。到最后也没把这玩意弄趁手。
但是 vscode 就很舒服,回头感觉 vscode 还是更接近 idea 一些的。就是 idea 也是有亮点的,当时感觉不出来。
vs 到底吊在哪,我觉得作为 Windows 端开发软件,它的大而全。比如开发 c++,除了写代码外,编译链接那坨头疼的东西它給你代管了。调试什么的他也做得
你是前端想通过 Websocket 连到 MQTT 服务器上收消息么?通过反向代理转一下?
要是指 MQTT 服务器怎么做单机并发的话,你可以参考 EMQX 是怎么做的。
游戏引擎确实不需要,但是你想做 MUD 这种还是尽可能找点工具辅助吧,算是没有界面的网络游戏,挺复杂的。
你想在互联网上,开辟一个属于自己的空间,存一些东西,搞一些网站,仅自己可见。
那你需要的是一个云服务器( VPS ),这是一台功能完全的,仅属于你的,有固定公网 IP 的电脑。你在上面再部署你要的东西,比如网盘、数据库、网站、服务接口之类的。
仅自己可见的话,对于你暴露的每个应用,你自己维护密码、密钥等安保措施。让别人不能用。
CDN 完全不是干这个的。CDN 叫做内容分发网络,作用是加快文件传播的速度,跟你的需求完全相反。比如你有音乐或者视频等大文件要传播,直接放在自己服务器上,給人下载的话,流量压力很大。这时把需要传播的内容放到 CDN ,CDN 会将内容分发到 CDN 缓存节点上。其它人请求内容时,就能从就近的 CDN 缓存节点上直接取。
至于有了 VPS 后,具体放什么应用,这个看你需求。就你表述的,我理解一个是网盘应用。另一个是个人博客,你去找各自的解决方案,套上去就可以了。
我用的绿联的硬盘盒,插上硬盘后像个烤面包机。是单独供电的,USB 线练到树莓派上挂载。
NAT 类型是描述你家内外网打通的程度。主要其实是看你家设备到公网有几层路由。路由套的越多,你这个 NAT 就越难生效,毕竟穿一层墙跟穿三层墙难度肯定不一样么。
现在一般来说是三堵墙。
第一堵是运营商給你的 IP ,因为公网 IP 资源紧张,现在分配基本都是运营商内网的 IP ,在运营商那里就已经做一层 NAT 了。你得申请运营商給你分公网 IP 才好穿这堵墙。
第二堵是在光猫那里。光猫如果开路由模式,你家自己路由器也是路由模式。你要把光猫那里改成桥接,让路由器直接拨号,可以绕开这堵墙。
第三堵是你家自己买的路由器,也算是一堵墙。绕这个墙,可以通过端口映射,或者 DMZ ,upnp 这种,把内网的设备地址暴露出来,这堵墙就过了。
你这个属于租服务器,在公网上搭存储服务,
也算网络附加存储,但是一般叫个人网络云盘。
一般说的 NAS ,放在家里的一台搭载硬盘的电脑,通过内部网络让其它设备共享存储空间。跟网络云盘比,你自己可以配大硬盘,内网不限速,价格有优势。
当然也有不方便,比如你要出差在外,就得想其它办法连,有时还得用云服务器在公网中转。
实际上制约的也确实就是钱,要是公网带宽和存储容量都很廉价,就搞个纯云上的空间自己用,当然也好。
楼主你自己算一算就你的需求值不值这个价吧
前端三件套本来是设计用来画网页的。类似传单的感觉。
现在拿来做互动界面,类似游戏里的按钮、列表啊这些。 许多地方没有约定俗称的范式,要自己去编写,这就麻烦了。
Vue React 这些框架,就是提供了一整套思路,和配套的工具,让你按他的思路去组织代码,底层的一些细节它们包解决。
最后由框架将其编译回三件套。
传感器脱钩的话,那你就只能以网关+索引去关联了吧,你看配置文件在哪写吧。
至于数据库,时序数据没有特别要设计的吧, 时间戳 ,数字,然后就是索引啦。
本地存成本最低的方案,你找像小米路由器那种可以带个移动硬盘的,让路由器来干这个活。