V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  flyingghost  ›  全部回复第 11 页 / 共 28 页
回复总数  560
1 ... 7  8  9  10  11  12  13  14  15  16 ... 28  
2019-03-29 17:01:02 +08:00
回复了 phpchen 创建的主题 程序员 这个数字规律该怎么循环出来呢。。。。
3 进制,0、1、2 输出的时候转成 1、2、3。
然后逆序,高位在后。
2019-03-29 15:59:07 +08:00
回复了 tuding 创建的主题 程序员 这个符号"->",你们怎么读的?
-> 读作“的”或者“指向的”。
例如:shape->area(); codereview 时就读“调用 shape(指向)的 area 函数”。
2019-03-21 11:39:49 +08:00
回复了 heron518 创建的主题 程序员 当前社会,什么事件才可以激发学习和创作动力?
动用行政力量,上压指标下造运动,搞一场全国范围的大跃进。
一切目标都指向”创作“,一切资源都倾斜过来。
利用各种宣传手段造势,把广场上的大妈大爷都卷进来,把所有人都搞癫狂搞疯魔。

当然效果嘛。。。参考大炼钢铁。/狗头
请把字段的可选、必选确定一下。
方案 1:
status/code,必选字段,为 0 表示正常,为其他表示异常。(留扩展空间,比如正常 /异常二元值之外的其他定义。http 的 status 用分段来表达很多不是错误的状态)
error,可选,如果 status 标识为错误的话,提供详细信息。

方案 2:
errorCode,可选还是必选?
如果可选,那就意味着用存在 /不存在来表达是否出错。一般不这么做,而且存在 /不存在是二元选项,无法扩展。
如果必选,=0 表示无错?
一有冗余之嫌,相比可选方案,浪费流量。
二有歧义之嫌。我按"error"搜日志居然能搜出一堆正常数据?
三引入隐含信息。0 表示没有那-1 和+1 表示什么?凭什么 0 隐含默认公认功能?需不需要额外普及和记忆?


其实以上都是废话,讨论来讨论去谁也说服不了谁。最根本的问题:你是决策人和责任人吗?凭什么和老大吵?
任何一件事我们都鼓励积极参与积极建言,但任何一件事都有最终决策人和对决策负责并承担一切后果的人。责任明确也是分工和分等级的意义之一。你可以花 5 分钟跟老大建议并探讨,然后花剩下的 7 小时 55 分钟带着怨气或者绝望把你俩的共识给落地实现,也可以花剩下的 7 小时 55 分钟仔细考虑什么时候跳槽去离开这个傻逼或者给老大的老大提出这个人不适合领导并决策。但你是凭什么花 7 小时 55 分钟针对这个问题和老大去吵一天的? How dare you!
@catalina 这语气,这质问。。。好像我是豌豆决策人你要来跟我对质一样。吓尿了。
我是没见过这情况,找了个可能的说法来供参考,一起探讨他们这做法的动机和影响。你这质询找错人了对不起,而且看起来更像气急败坏急火攻心。
不想讨论了。
问了一下前豌豆大佬,流程是这样的:
下载本身没有问题,https 本身可以保障。
安装的时候,某些国产 rom 会偷偷检查应用名,
如果自家应用市场有,那就拦截,实际上安装自家的那份。或者警告你这个包有问题。
所以需要创建一个连不上网的 VPN,实质上断流,来 block 掉 rom 厂商的校验请求。

未验证供参考。
2019-03-18 11:03:27 +08:00
回复了 roundRobin 创建的主题 程序员 假如能力只够精通一门语言,应该选择什么
如果你敢说真正的精通,那你对语言、范式、编译器、并发、容器、io。。。无数子话题都非常精通了。漫长过程中难免对触达到的某些方面也会有所涉猎,例如本职工作做游戏,会对算法、2D/3D、架构设计、脚本语言有足够的深入了解。那时候,语言本身已经不太重要,无论精通的是什么,你都是业界大牛。
所以“能力只够精通一门语言”,是伪命题。

然而基于你现在还是学生。。。任何一门语言都不可能做到精通。敢往简历上写这俩字,楼上一堆大牛会直接打死你。21 天精通 xxx 这种程度的“精通”还只能做到一门语言,这能力也只能建议转行了。

所以“能力只够'精通'一门语言”,也是伪命题。

综上,遇到具体事情,选择最合适的。除此之外,选择一门最感兴趣 /最顺手的多深入一些就好了。
2019-03-15 01:35:59 +08:00
回复了 zhuwd 创建的主题 程序员 各位有没有什么减压的手机游戏推荐?
梦幻家园,三消游戏,特别减压,有失败次数上限也不会磨掉太多时间。
话说 chm 不应该是纯数据载体格式吗?崩了难道不是 chm 阅读器的锅吗?

另外,Dash 好评。没有用过的 http://overapi.com/ 或许也是一种选择。
2019-02-25 18:01:14 +08:00
回复了 wszgrcy 创建的主题 程序员 css 残局怎么解?
这就是“维护越久换人越多,style.css 文件越大”定律。别问我怎么知道的。
如果不是时区,那就是夏令时 /冬令时的锅?
2019-02-14 15:47:41 +08:00
回复了 0xxf 创建的主题 程序员 请教一下各位关于前端多项目的问题
我问领导为啥要这样做,他说,这样方便管理,这个项目很大的,有很多内容,为了以后维护方便,维护某一个模块的时候不需要关心别的模块,
我想了下,好像多模块并不等于必须多工程,一般工程内模块划分有按目录的( java ),有按文件的( c/python ),都可以做到方便合理清晰。多库多项目依赖管理和发布版本管理的时候简直罗嗦最好有独立的项目经理和构建工程师来做这破事。

领导还说了,你要是放到了一起,以后我想升级一些包,比如升级一下 Vue 的版本,是不是要对别的包有所顾忌?假如,将来某个模块,用 react 实现会好很多,那我是不是这部分就是直接用 react 来实现?
我想了下,好像升级 vue 这种底层包无论在哪个项目中都是一件非常蛋疼的事情,而项目异构简直是双蛋齐疼。

领导还说,你把这些用了很多次的组件也弄成一个子项目,比如这个「菜单」,别的子项目也需要用到,你抽出来,以后大家用的时候直接 npm install 就可以了
我想了下,好像组件复用并不等于必须子项目一种实现方式。别的项目组 /别的公司 /别的星球的人要用,到时候再针对性的抽就是了。这么早就假设不怕这项目下个季度就死掉吗?

领导还说了,到时候部署的时候,可能是每个子项目一个独立的二级域名或者二级目录,虽然这样弄,模块间的跳转会刷新整个页面,但是莫的关系,你赶紧开工。
我想了下,独立二级目录还好,独立二级域名简直是架构级别重新设计,单一个跨域问题就烦死个人。
————心里 MMP 脸上笑嘻嘻的分割线————
我说,好的好的。
2019-02-14 12:08:24 +08:00
回复了 imherer 创建的主题 程序员 前后端分离的项目如何防止 api 被第三方利用
@geelaw #24 我的意思是对比现实世界,除了协议信息“钥匙”之外会有大量协议之外的本征信息逸散出来供我们利用。但在计算机世界 http 调接口这个场景下,ip、referer、ua、时频、参数特征和分布。。。本征信息少很多,而且要么无法利用,要么伪造简单,要么效果不佳。

其实 lz 提出的问题 X 背后,我更好奇的是问题 Y:为什么会有这样的需求场景?原始需求有没有放弃鉴权之外的其他方案?
2019-02-14 12:01:58 +08:00
回复了 licoycn 创建的主题 程序员 派公司人员到外包公司合理吗?
服从他们的管理 只是老板、项目经理方便项目管理的预设机制而已。很大很虚的一个框。

真实情况呢?还是和地位相关。
如果是真·甲方,你去了就是钦差大臣就是纪委监察组入驻,舔的你不要不要的。什么服从管理,我可以影响你的管理策略你信不信? 8 点开会我到不了,我建议你把会议时间定到 10 点我不就可以服从了吗?干活是协调出来的,不是由乙方项目经理指派的。连古代皇帝都知道把京官外派应该作为一种“赏赐”安排给手下。
如果是假·甲方。。。抱歉我还真没体验过很难给出经验了。
2019-02-14 11:19:11 +08:00
回复了 imherer 创建的主题 程序员 前后端分离的项目如何防止 api 被第三方利用
鉴权 = 识别客户端合法性。你都放弃鉴权了,等于是放弃识别能力了,又怎么要求“识别”自己人和第三方呢?
就像我家大门不需要钥匙推门就进。但我要防贼。这么等价替换的话,你就会发现,你得有一双贼眼,能发现贼身上自带的一些本征:衣着、神情、习惯动作、气味、面相、指纹、DNA。。。
然鹅,以上在 http 世界都可以仿冒,仿冒门槛还挺低,成本和技巧难度远低于 Neal Caffrey 仿冒一个良民。
楼上戳啥链接办理信用卡的,根本都不一定是发卡行给你的短信。。。现在大把的无关个人干这事。编个短信找个号码库附上自己的推荐链接无脑群发,总有一两个真点进去办理的,自己就可以拿到推荐费了。颇丰哦。

熊猫吃短信 + 通知全关 已经一两年了,iOS 除了不能分别设置“过滤信息静默,正常短信通知”小小遗憾之外,体验良好。
2019-02-01 16:28:49 +08:00
回复了 ericgui 创建的主题 全球工单系统 这是故意的吗?
2019-01-22 09:36:15 +08:00
回复了 frylkrttj 创建的主题 git git 能配置自动跟踪目录内的文件吗?
新手学习过程中看不到风险很正常。提出优化建议起码证明 lz 进一步思考了。

但 git 不这样设计不是因为 git 蠢,而是因为这样设计是错的:误提交实在是太多太多了。。。

亲身经历过同事误把 密钥.java.bak 提交进仓库,打包,发布,被竞争对手反编译,获取到公司通用算法和我部门密钥,暗搓搓上线我司在线服务的破解版,然后全部门在过年前一天飞机火车汽车逆流回司加班的壮丽事件。
日常岁月静好的代码仓库,也时不时会出现不应当提交的文件。所以需要 code review,需要服务端 commit 钩子,需要定期检查清理。

单就文件的尺度来说,git/svn 是允许你整体提交的,也就是说你无需手动一个个变更点看过来,一把梭提交整个文件。是不是和“提交整个目录”很像?所以 git 不是没想到,而是在方便和危险之间找到了平衡:文件粒度。
但我要求的最佳实践,依然是提交的时候检查精确到行,每个变更都确认需要提交。(你看我没有要求精确到字符已经很人性化很方便啦!)
宽标准=前瞻性=漏洞百出的校验?
严标准=基于现实=无法适应变化?
这两条路都不是什么好路子。
好路子难道不是
基于当前的严标准 + 配置化等易扩展易维护的结构 + 最重要的时时刻刻维护更新 嘛?
1 ... 7  8  9  10  11  12  13  14  15  16 ... 28  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2654 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 02:59 · PVG 10:59 · LAX 19:59 · JFK 22:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.