OneEyeWolf
- 浏览: 105399 次
- 性别:
- 来自: 深圳
-
最新评论
-
sunli_qun：
我觉得现在框架的问题可能在于，太过于考虑通用性，一个sprin ...
好事要做到底，我们需要full stack的设计 -
koda：
业务平台是需要日积月累，和技术平台无二。自己的平台？ 开放了就 ...
业务平台的真的存在吗 -
Tin：
这说的fullstack还是软件工厂的概念？还是基于组件的复用 ...
好事要做到底，我们需要full stack的设计 -
lgx522：
要求不要太高的话，RoR或者Grails大体上就能够full ...
好事要做到底，我们需要full stack的设计 -
ajoo：
DIY原则？？？
好事要做到底，我们需要full stack的设计
文章列表
GPS软件平台的开发是一个相对垂直的行业应用软件开发，和一般的管理信息软件开发有很大的不同，是一个软硬件一体化的平台，数据来源于GPS设备发送。依赖的技术要包括socket通信、gps定位、通信协议解析、GIS地图开发、以及常规的前后端web技术等。
初学者在网上找资料，就像垃圾堆里找个宝一样，比较浪费时间，为了节省时间，我这里做个索引，随时需要随时点开看看，免得重复搜索。
1.首先要做的是界面设计，界面上有地图、车辆、工具栏、报警弹窗等，监控界面需要花些信息才能做好。
1）GIS、GPS和视频监控界面设计
2）GPS监控客户端界面设计
3）
full-stack 的设计，意味着各层能够无缝的集成在一起，遵循的DRY原则（don't repeat yourself)，将各层共用的东西，抽取出来，并通过自顶向下的设计，无缝的集成在一起，粘合在一起，达到更高层次、更粗粒度的重用，同时为了保证灵活的可扩展性，在更高、更粗的粒度上遵守开放-封闭的原则，在各层的各个关键点，要提供诸多的钩子，回调的接口，供使用者扩展。full-stack的设计，在层与层之间，并不一味的追求松散的机制，而是相反，在层与层之间增强一定的内聚性，粘合力，以此来达到粗粒度的封装与重用。 可以说full-stack 的设计，其爆发出的威力是巨大的，相对普通的单一层面的设 ...
相信凡是开发者对用户纷繁复杂的需求，都趋之如虎，从制度上，我们建立了严格的需求变更的process, 从技术上，我们寻求一种所谓的业务平台，寻找一个冶百病的良药，在市场上，有商业软件来推销自己的平台，更在平台上加 ...
- 2007-12-19 22:09
- 浏览 1527
- 评论(1)
看了infoq中文站的那篇敏捷之文，又顺藤摸瓜，找到了太极掌门人的网站，作为一个旁观者，仿佛看到两个下盲棋的高人，飘在空中，一个说“炮五平六”，一个说“马8进7”，杀的好不激烈，另有一群评棋之人，或指点，或赞同，或反对，好不热闹。
回到JavaEye,却更觉得这是块净地，务实求进，Pragmatic, 是我看到的JavaEye的风格之一。更觉可贵，也更希望保持下去。看到很多追求卓越的人努力的改进自己所在项目的软件过程，虽处在强大的官僚机器之下，力量弱小，却又像一群拓疆之士，在大雪迷漫当中，互相扶拥，奋力前进，自己身处于其中，似乎更加亲切。
软件开发本来就是一种抽象的过程，将现实世界的连续的东 ...
长期以来，由于IBM等大的厂商，声嘶力竭、不遗余力的宣传，SOA开始在江湖盛传，但掌握着是否实施SOA的权力，掌握在高层的领导手中，而IBM的Sales，则将天花乱坠的Solution，很容易的输入到领导的大脑当中，SOA成为无所不能的利器，而领导对于实施SOA，来改变当前混乱的局面，寄于很高的期望。
而无论是在IBM、BEA、Oracle等大牌厂商，还是Mule等开源方案，都没有真正的案例，来提供很好的异构系统通信的解决方案，而这正是很多大公司长期以来，所希望解决问题。
最近在做一个公司的一个信息集成的工作，由于客户在长期信息化的过程当中，积累了多个IT遗留系统，在工作开始，客户便 ...
精心打造Team的组织架构
长期以来，很多Team的组合都是随意的，从创建到稳定, 不经意之间，一个Team就出世了，在项目进行当中，弊端尽现的时候，也没有人注意到是团队的组织架构，人员搭配是否出现了问题，Team成长过程，就好像一个树籽落在地下，然后自生自灭，有的长成了歪脖子，有的则树倒猢狲散，有一部分，运气好，成为能经风雨的大树。
几年来，虽然敏捷管理与开发，深入一些经验丰富的PM和开发人员之心，但是在推广时，却南桔北枳，没有了味道，
一些优秀的开发与设计思想或技术，如TDD、MDD，大部分只流转于个别经验丰富的开发人员之间，在团队项目开发中，不见了踪影。
这些都非 ...
最近做一个比较大的电子商务项目，预计每天订单量将在５万多单，客服人员需要频繁的下单、查询订单、操作订单，客人预订完订单后，会立即进入处理流程，为了提高服务质量，要求流水化作业，平均要在４０分钟－８０分钟内处理完订单，对于疑难订单要到第二天，才能处理完。所以订单在创建后，会在短时间内，被频繁的修改和查看。
由于在项目中ORM层主要是基于Hibernate框架，所以在调优时，很自然的就想到打开Hibernate的二级缓存，以次来减小由于Load 订单大对象时N+1次查询给数据造成的压力，自己做的测试效果也非常好，也顺利通过压力测试。
但在上线时，性能却并不佳，经过分析业务的操作特点，查 ...
计算机专业毕业的学生在学校当中，都读过软件工程这本书，而软件工程的书，都无一例外的，强行规定了一个编码阶段，并且十分严肃的告诉学生，代码在整个软件过程的生命周期阶段当中，只占了1/5左右。需求分析和设计、项目管理，更强于代码。我想对这于刚毕业的学生，是一种思想上的毒害，很多人刚毕业一两年，都耐不住性子，哭着喊着，要做architect，要做PM。
我认为回避代码是可耻的，只要编码显的有意义，我们在任何阶段，都应当投入到编码当中。
最近一个项目，我下面有两个设计人员（GM派过来的），协助我做设计，我做了一个设计的骨架，然后交给他们去迭代细代。下班前，我去看看他们的工作只有一 ...
近来为客户新做一个电子商务网站，部门经理天天给我说要把群集做进方案里，听的都吐了，在没有对于用户服务需求真正在进行好认真的分析的前提下，就将群集做进方案里，真的觉得很厌烦。
我觉得即使对于中型的电子商务网站，也不一定需要群集，群集只会增加复杂度，甚至有可能延长用户请求的响应时间。同时限制Web应用的开发方案，如对于重型的基于SessionWeb-Flow方案，你就要考虑不能使用了。但对于电子商务网站，web-flow的应用很多，想像一个网站下单的过程，-查询－预订－登陆－填写需求-填写配送单－信用卡担保（或网上支付)-生成订单。使用wegbflow框架很方便，但在群集 ...
信息系统访问量又不大，瓶颈一般不会出现在应用层，极有可能在数据库这一层，不用急着看程序。先找出逻辑读取次数最多的SQL，硬盘读取次数最多的SQL，找到SQL，对于SQL进行优化。看看有没有发生全表扫描的地方。
一般发生全表扫描，极有可能是没有建立合理的索引，或者索引由于左边引用函数或其它原因造成索引失效。
对于运行一年多的系统，最好要自己写一个自动重建索引的程序，定时重建索引。
或者使用TOAD工具帮你重建索引。
另外在看一下数据库的CPU占用率，如果占用率在经常在80%－100%，那一定要是SQL或存储过程及trigger中写的不好。
不需要从应用层找SQL，方向性错误，太累，也看不出效果 ...