`
17studio
  • 浏览: 200048 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论
文章列表
在接触过darkstar和erlang后,对高性能服务器有了更进一步的认识,下一阶段,开始学习erlang了。。。
用一种桌面功能构建,功能组合的方式,提供负责个人全新的操作界面,体现人性化和个性化,真是相当不错的设计(无论从技术上和产品上都是如此) 面向用户的产品,这就是所谓的底蕴,难怪一推出没多久,微软就开始模仿了 google的产品系列有一大特点,就是相互渗透能力很强,其实微软也是。。。腾讯也是。。。这不得不归功于产品部的真知灼见
原来E extends java.lang.Enum<E>这个是为了语法顺畅而做的,解决父类和子类协作时,统一语法面使用方法 下面是从别的地方copy来的资料。。。做个标志 考虑下面的语法 E extends Foo<E> E被识别为Foo的子类,这个情况相当于把一个子类或者自己当成参数,传入到自身,引起一些特别的语法效果,例如 abstract class Foo<SubClassOfFoo extends Foo<SubClassOfFoo>> {     /**  subclasses are forced to return them ...
呵呵 因为最近和新同事团队磨合,发现自己一些云里来雾里去的构思,让别人不知所措,以后沟通的时候,需要注意的是,把沟通的层面变得平实一点,从大局观考虑的想法,自己来控制就好。。。 准确点说,需要注意对方思路的接受过程,以及对方的背景知识
实时交互类,采用技术 1. 前端 Jsp, ajax 2. 后端 Java servlet, ibatis for persist 3. client <-> server pushlet, comet, json     pushlet的性能 pushlet的价值在于,这是一个简单的java解决方案,为java开发者提供了省事的底层支持,虽然有其他方案的出现,但其他方案还没有压倒性的优势,如果能够改进原有不足,还是可以利用的。 pushlet的问题在于: a、代码里面的同步处理 b、每个连接都使用了一个servlet资源,并且会长时间保持 c、 ...
1. fullstack framework: appfuse, ruby on rails, rife, grails 2. fast develop framework in client 3. system architecture
将了分层和展开,开始谈谈设计的总体思路了 最近也在网络上找了找关于软件设计过程的整体思路,遗憾的是,可以成为教科书的可以说是没有,有的只是以前的基于流程化设计和个别人的观点 自己对自己的设计思路做一下总结 1、分解,用思维导向法,把问题分解成为独立节点,要求,最终节点不可分割 2、对表示逻辑的节点,使用流程法,描述最终节点;对表示交互关系的节点,使用交互设计,描述最终节点;对表示存储的节点,使用数据库技术,描述最终节点;。。。 3、把最终节点中参与的对象和关系,用E-R进行描述 4、整理节点和关系,使用分层技术和对象技术,简化出公用类库,实现耦合与解耦(相关导致耦合、模式减少解耦),这里建议不要 ...
1. flash体系     a. xmlhttp + servlet     b. xmlhttp + tcpserver (quickserver) 2. ajax体系     a.  dojo, yui + servlet 3. openlaszlo 4. ruby on rails 类似的php或者其他的web开发语言如python,都有这样的框架   flash体系的表现力无疑是最强的,这跟flash是客户端activex不可分割,难怪微软要抛弃了以前多activex嵌入的思路,弄一个silverlight了。。。 其他的大都借助xmlhttp,javascript和dhtml,导致了 ...
以下是项目组管理实践的依循规则,做个记录 1. 以身作则,努力做事 2. 树立目标,注重承诺 3. 项目任务并行设计,简短会议时间,减少沟通成本 4. 使用双周计划,建立目标 5. 使用敏捷流程方法,建立目标进度监督 6. 使用测试用例,检查产出内容,保证产出质量 7. 强调团队学习,强调团队监督 对项目组长要求 1. 和部门负责人沟通,了解项目要求 2. 根据项目要求,构思实现思路 (实现步骤+每步骤实现方案) 3. 考虑如何并行实现步骤中的任务 4. 任务分派 5. 检查组员是否明白任务,辅导组员学习所需知识 6. 检查jira查出 7. 检查完成时间点及相关测试用例 8. 每项目步骤完成 ...
在反对了技术导向的方式后,谈谈我心中的健康的团队构成 1、CTO,负责技术选型,为技术的生命力和可发展性负责,所需知识,商业知识及深厚的技术功底 2、架构师,使用CTO所指定的技术,构建系统,所需知识,大型系统的整体设计经验,产品领域知识 3、设计师,完成系统组件的某一组件的设计,所需知识,语言层面的设计能力,编码经验 4、程序员,实现组件,所需知识,编码能力,良好的工作习惯 5、研究团队,为其他团队提供技术信息支持及相关培训 6、管理团队,领导并监督技术人员的工作专注于手头的工作,可从技术组长<->程序员,项目经理<->设计师,部门总监<->架构师,CEO& ...
有感于国内的IT现状,技术思维之弱而言。 我常常看到某某仁兄说,我们现在要用这个技术!于是,一个新技术就被拿来当作基础框架实践,上线。。。我不否认能吃透一门技术所需要的技术功底的深厚和个人能力的高超,但是,我想说的是,对商业来说,技术只是提供服务的。 做一个商品,可以实现的方法有很多种,并不是使用技术最高明者,才是最厉害的,这取决于技术是否能够适应当前公司的资源以及技术所带来的竞争优势,两者缺一不可。 这里我就不举具体的例子了,我只是想问问,所有想用新技术的人,是否考虑过,你所带来的新技术,这门新技术未来会否成为主流,公司想找个人接手是否容易,用了这门技术,可以给公司的产品带来什么超越竞争对手的 ...
还是从上一篇的学生管理系统入手,如果老板说,呃,我觉得后台存储,要用文件。。。 咣当,完蛋了,没有了jdbc,如何存储记录?OK,这里就是告诉大家,代码运行在组件上面 b/s,多线程,并发,数据库,这些是组件所提供的功能,组件包括j2ee的编码规范,resin,mysql这些玩意,如果没有的话,就得看看谁,提供了这样的组件,或者自己来实现一个,一般来说,如果不是业务特定需求,自己做一个高复杂度的组件是没有必要的 所以,明确自己所在的层次,了解组件所提供的能力,是非常重要,这个,称为特定领域知识 从编码的角度来看,也就是分层,下一层提供了一个功能集合,上层才能在这个功能集合上干活,减少自己的工作量 ...
嗯,这篇文章是用来拨开迷雾的 在学校里面学到很多的概念,常常都会和实际有偏差,比如,如何做一个项目,那么就是一堆的需求表,设计表,然后来类设计的各种规范,各种要求。。。一下子头晕 初出茅庐的学生们需要谋 ...
在我的代码编写过程中,减少错误最重要的一个环节是测试代码 有几个原因把让代码的质量直接体现为错误的多少。第一:其实没有完美的设计,所以灵活度总是有限的,而且没有指标衡量;第二:功能实现对测试人员和业务人员来说,是一个黑盒;第三:日志配置这类高级玩意,一般人都不会检查。所以,最终代码的质量,就是体现在错误的多少 测试用例可以分为三种,一种是需求所对应的测试用例,一种是测试类之间交互的测试用例,还有一种则是类本身是否正确运行的测试用例 使用了敏捷的开发方法后,客户需求被映射到每一条的测试用例上,所以,测试用例必须保证,能够完善测试用户的所有需求,并且保证质量 类之间交互的测试方式有很多,这个可以参考 ...
回顾以前的开发历程,偶得出一个属于自己的经典经验,那就是,开发流程根据项目规模和团队成员情况而定 OK,不相信,我举一个例子,现在要写一个Helloworld,请问您会选择RUP还是Agile? 很简单,答案不言而喻,那就是直接写 ...
Global site tag (gtag.js) - Google Analytics