V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lyris  ›  全部回复第 1 页 / 共 1 页
回复总数  17
想起上古时代,我用过网海拾贝 netcollect 很多年,每次系统要重装都备份好
2018-05-17 18:01:50 +08:00
回复了 lyris 创建的主题 问与答 求 reddit 回复风格的 V2EX 站油猴脚本
@TypeNANA 多谢,这个可以!
2017-06-19 18:20:07 +08:00
回复了 lyris 创建的主题 VPS 搬瓦工彻底被墙了么?今天开始彻底失联了
忽略,自己的问题,错怪 wall 了
但是大多数网站并不是单页面应用,却非得搞成单页面,或半单页面(肯定也有蹩脚的页面路由),我觉得就是走上邪路了
@janrykk 这也是我一直非常喜欢 bootstrap , ace 这种前端库的原因,既能适配手机,又能满足功能,界面还快,现在每次看到新框架做的花里胡哨的页面,花了非常多的时间做出来,居然连手机也不能自适应,各种浏览器兼容问题,页面源码全是 js 就觉得这绝逼要玩玩啊,如果是微博网页版和微博聊天,纯 js 渲染我觉得是正道
最为一个后端狗,恰好在前后两个公司经历过两种模式的开发:

第一种就是 前后端不分离, 前端用 freemarker 辅以 js, 页面的主体框架部分是 freemarker,数据提交验证,侧边栏之类的都是 ajax post 来验证或渲染。每个开发周期,前端负责和美工要图,切图,静态页面的 css+静态 js ( js 用的也是 jquery )交互效果,后端负责后台实现接口,套 freemarker 页面, js 动态数据交互,后端一个人完成一个功能,由于 js 请求有各自的 namespace ,也不会出现各个模块 js 冲突之类。页面简洁干脆。各种前端技术稳定,浏览器兼容性好,周边工具( js/css 合并,压缩,版本控制)基本不出问题

第二种就是现在前后端分离,后端提供 api ,前端用 mvc 前端框架 knockout js ,由于时间短+任务紧,开发的系统功能点繁多,使用对象复杂, api 数量暴增,尼玛一个鼻屎大的功能就得提供分页列表,增删改查各种接口啊,各种全局定义的枚举也需要提供接口给前端啊,由于 knockout js 有自己的 MVC, 所以后台接口增加一个字段,或者重构一个字段,推动前段去改比推动牛还慢啊,各种格式化库新来的前端不熟悉,要引入各种 js plugin (传统的各种控件要适应 knockout js 框架你不可能一行代码不改动就去适配吧)啊,时间来不及就强迫让后端做各种格式化好的数据喂到前段面前啊。

感受:

1.前后端未分离时代,本人还可以自称全栈,团队开发效果奇高,页面上的数据权限控制非常简单。 在前后端分离后,出现问题本人已经改不动那些 js 了,后端已经实现了一遍 MVC ,现在前端又来一遍业务上的 MVC ,心累,除了偶尔写过几个 knockout js 的 plugin ,但是前端这种 MVC 框架层出不穷,熟悉各种东西需要花时间吧,技能还停留在 Mongo + express + angularJS + NodeJS 阶段,对 bower, gulp , yeoman 之类的非常有好感,但对新花样的前端 MVC 代码非常厌倦了。数据接口往往会把一些前端用不到的数据也吐给 json api 上来,个人觉得是一个安全隐患,但是不这样,前端的日子也不好过,真要做好权限控制,个人觉得前端的 MVC 中的 V 也要多做几套,否则那些页面元素只是隐藏啊,丑陋不堪。各种周边脚本一会是 grunt,一会儿是 gulp ,一会儿又是 webpack ,喜欢前后端分离的前端往往喜欢作死用最新的技术最新的版本,而自己又 hold 不住,线上各种问题。

2.前后端分离带来的好处。如果接口提供给多个终端用,比如手机,后端提供的接口标准化还是非常有用的。一套接口可以应付所有终端,以前前后端分离的时候接口的质量也没有太高。还有一个重大好处是部署的时候前后端分离部署,后端部署和前端部署各自部署各自的,没有耦合,但在前端用 MVC 框架下,本程序狗已经改不动一个完整的功能模块了,前端部分还要看到一遍业务 MVC 就感觉恶心,改不动。对于个人而言,工作量反倒变少了,只用自己写好测试格式好接口就行了,不依赖页面。

总之,痛点还是以前的 freemarker/velocity 和 jquery 太好用而新出的前端 MVC 框架喜欢挖坑;而我时不时喜欢做点东西,喜欢一个人做完整个功能,沟通太费事了,又目睹了前端 MVC 及其周边发布工具的挫样,哀其苦逼但又无可奈何。
2015-04-09 13:10:54 +08:00
回复了 ChiangDi 创建的主题 Z shell 那些我希望在一开始使用 Zsh(oh-my-zsh) 时就知道的
zsh启动太慢不能忍,用一段时间后卸载了
2015-04-08 10:18:05 +08:00
回复了 cs202 创建的主题 分享发现 趣站推荐:乡音苑——不要让你的家乡话被后代遗忘
非常不错
2015-03-26 10:39:25 +08:00
回复了 Sin 创建的主题 分享发现 Windows 10 的回收站终于被拍扁了
大色块+扁平,现在的设计啊,会到windows3.1 了……
2014-05-04 16:19:47 +08:00
回复了 matrix32767 创建的主题 分享发现 vagex 开放注册了,附赚零花钱教程
跟风,楼下继续
http://vagex.com/?ref=285855
2013-08-29 14:10:32 +08:00
回复了 lyris 创建的主题 MongoDB MongoDB 里面日期查询的问题
嗯,谢谢!

JavaScript(MongoDB Shel)里面用 new ISODate() 来将字符串转化为Date类型,
对应Java 里面用 new BasicDBObject("ts", date);
这样就恍然大悟了。

原来还以为BasicDBObject 生成的toString()可以直接给MongoDb 的JavaScript Shell拿来用呢,发现还不是,至少JSON规范里面就不能处理 new ISODate 这种内建函数。

Java里面代码很累赘,不过用Java还是喜欢它的速度和编译检查。


SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'");
try {
Date date = sdf.parse("2012-05-17T08:14:15.656Z");
BasicDBObject time = new BasicDBObject("ts", date); //实际上这里面"ts" 可以为任意键值
System.out.println(time.toString());
} catch (ParseException e) {
e.printStackTrace();
}
2013-08-29 13:45:43 +08:00
回复了 lyris 创建的主题 MongoDB MongoDB 里面日期查询的问题
看来java如果要直接兼容mongo shell 里面的手写查询,只能来个正则把形如new ISODate("2012-05-17 08:14:15.656") 这种直接翻译成 { "$date" : "2012-05-17T08:14:15.656Z"} 得了,日期类型真是麻烦。
2013-08-29 13:34:14 +08:00
回复了 lyris 创建的主题 MongoDB MongoDB 里面日期查询的问题
@juicy 有道理,谢谢。
现在我如果吧 {"manufacture_details.release_date": {"$gte": new ISODate("2012-05-17 08:14:15.656")}} 这个直接给Java 代码的话,JSON都pass不过, 发愁
如:
queryStr = "{\"manufacture_details.release_date\": {\"$gte\": new ISODate(\"2012-05-17 08:14:15.656\")}}";
DBObject queryObject = (DBObject) JSON.parse(queryStr);
cursor = collection.find(queryObject);
直接抛异常:
Exception in thread "main" com.mongodb.util.JSONParseException:
{"manufacture_details.release_date": {"$gte": new ISODate("2012-05-17 08:14:15.656")}}
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   889 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 23ms · UTC 21:53 · PVG 05:53 · LAX 13:53 · JFK 16:53
Developed with CodeLauncher
♥ Do have faith in what you're doing.