zpf124 最近的时间轴更新
zpf124

zpf124

懒~~~
V2EX 第 164342 号会员,加入于 2016-03-22 09:03:34 +08:00
zpf124 最近回复了
@x66 见过 es - elasticsearch #滑稽
https 是传输数据全加密的,除了请求的目标 IP ,中间设备是抓不到任何内容的,path 部分 body 体都一样,除非请求发起端被黑了,信任了中间人的证书,然后被中间人劫持。
(题外话,所以不要在公司的加域电脑或者需要安装上网控制的内网上干私人的事,对于 IT 和老板你 https 了也是光屁股的)

这个后端找借口都不会 , 我教他俩百分百对的。
"Restful 对于某些业务很难抽象,比如网上各种对注册登录的实现,要么破坏规则与其他 restful 不统一,要么强行把简单的逻辑抽象成了复杂还别扭的规则。"

"公司运维有统一请求分析控流组件,每个项目都是统一接入的,而这个组件不支持 url 里的携带变量,要求运维发开升级组件难度很大,影响范围很大并且升级后稳定性无法评估。(或者 这是采购的第三方产品,且除软件外还包含专用防火墙硬件设备,厂家无法支持升级,需要购买新设备替换)"。
就是一个标准统一就好,我个人更喜欢驼峰。
虽然阿里巴巴的标准是全大写,并且目前我们项目领导也要求这样,我也遵守了这样的规范。

DTO 和 HTTP 、URL 、SQL 、NBA 、NASA 、API 、GUI 、REST 一样都是一类专有名词缩写,针对于驼峰命名法而言,我的理解是按照驼峰结构修改,和普通单词一样,按照驼峰方式拼写。
QueryUrl 、UpdateSql 、NbaList 、FakeApi 、Rest 、UserDto 、UserVo 。

而 DTO 、VO 、DAO 这类东西和前面其他专有名词缩写有一点不一样的地方在于它在名字中是存在特定编程含义的,而其他专有名词在技术层面没有任何意义。
NbaList 、CnCity 、这类缩写对于某个新加入项目的人而言与 AList 、BObject 并无区别理解代码改造代码的时候无需了解这个缩写的含义; DTO 和 VO 你看到他们的时候你就知道这个类的用途。

所以我可以理解为什么有人认为该保持全大写,但我个人更倾向于统一用驼峰,不能因为它表达的含义不同就专门例外。
19 天前
回复了 yezheyu 创建的主题 程序员 关于 web 服务器架构的一点疑问
前后端分离指的主要是渲染视图和数据分离, 不一定前端非得有专门的服务器。

比如完全可以直接生成静态的 html ,用户请求之前这个页面就已经生成完成, 然后由浏览器直接渲染这个完整的 html ,再执行 js ,通过 ajax 读取到数据 A ,再把数据也渲染出来。当用户访问其他页面的时候就是访问另外一个 html ,从页头到页脚都重新读取重新渲染不管一样不一样,然后再去读取另一个数据 B 。


但这样就出现了一个最主要的问题,当是搜索引擎爬虫访问或者用户网络不好的时候,他们只能看到一个空框架没有任何数据内容。
为了解决这个问题,所以才又专门准备一个渲染服务器,也就是你说的前端服务器,html 页不再是直接生成好的空框架页面了, 而是可以先读取空框架模版再由渲染服务器去访问后端服务器获取数据,然后生成包含数据的 html 页,这时候再返回给用户。
24 天前
回复了 fbichijing 创建的主题 程序员 GPL 协议的疑惑?
0 、GPL 不限制收费,只要你给源码,哪怕你直接拿开源软件就改个名字去卖一个亿都不违反 GPL 协议。


先说 web 项目和网站用户的问题,GPL 诞生的年代 Web 的形态和现在差得远呢,他们确实没有考虑到这种形式。所以你的网站如果只是提供服务,那么 GPL 的代码你在修改之后也不需要给谁,因为你只是在使用,没有“发布、分发”,所以自然不需要为你分发的客户提供源代码。 网站的用户只是通过某种协议访问了你提供的服务,但他们并没有你这个服务的所有权。

---------------
比如你拿一个 GPL 开源的 wordpress 插件修改成了一个在国内很优秀的功能,你自己搭建了一个网站大堆用户都用这个插件的功能,这时候你不需要给他们源码; 然后你选择售卖这个插件盈利,那么你有义务向购买了你程序的其他网站站长提供源代码。
----------------
38 天前
回复了 abczise 创建的主题 问与答 各位大佬服务器被攻击咋解决啊
我以为偏技术性的论坛对于服务器防护还会比较关注。

没想到大家安全防护意识这么低的么...

如果说向安全大佬一样,所有端口都采取白名单那确实不现实,毕竟很多时候我们访问自己服务器的出口 ip 不是固定的。
但不开放常用端口,常用协议不使用默认端口和不使用弱口令好像真的挺常识的....
@xiayushengfan mongodb ,我们用的也不是很有心得,我们还是按照关系型数据库的用法或者 k-v 缓存的用法在用。

比如我们如果用 mongodb 存站内信的话,就是一个集合是所有消息,或者一个集合是一个月的消息之类的维度,每个文档包含文档的全部内容包括所有的接受用户 id ,以及已读状态, 查询的时候 直接查当前用户 id 的文档数据。
@kaiki 最后我们是发多条了,没有组的概念,这种情况下按照你说的方式确实能优化一些存储。

针对后面的问题,我们的文章表有 n 多字段,对于消息来说都是完全没用的,而且文章没有记录多少人已读的。
最后我们的站内信不是用户给用户发送的,基本都是系统通知,"你订阅的 某个资源更新了,url " 类似这种,所以我们和楼主的也不完全相似,因为我们的消息大多数是分组的,个别是全站群发,没有用户间私信。
最后说说你的需求
1 、数据肯定要落库的,虽然这个数据重要性不高丢了就丢了,但发消息偶尔会出现收不到肯定最起码业务领导会不爽。
所以如果想要性能那就用搜索引擎 es 或者其他非关系数据库如 mongoDB ,数据读取层面还可以加 redis 。

2 ,3 、阅读很少那就把阅读单独建表, 就像我们那种, 阅读表包含消息 id 、用户 id 、是否已读、已读时间、创建时间啥的。
本来当时打算有个消息发送组的概念,消息分为发给个人还是发给某个组, 然后组里面有个魔法值是群发。
结果这个功能对于我们本事不是很重要,而且人手要优先干其他的,所以这里就简化了,有给某个组群发的需求,就 foreach ,创建多条信息发送给指定的人。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3934 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 09:04 · PVG 17:04 · LAX 01:04 · JFK 04:04
Developed with CodeLauncher
♥ Do have faith in what you're doing.