`
17studio
  • 浏览: 194165 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论
文章列表
1. 过程式 2. 数据结构化 3. 面向对象编程 4. 设计模式 5. 泛型、组件 6. AOP 业务通常需要以下程度的支持: 1、双方理解       -- 面向对象 2、适应复杂性     -- 设计模式 3、适应变化性     -- 泛型、组件、AOP 4、适应规模性     -- 架构及性能优化
JVM 参数设置详细说明(转) 1: heap size a: -Xmx<n>                       指定 jvm 的最大 heap 大小 , 如 :-Xmx=2g b: -Xms<n>                       指定 jvm 的最小 heap 大小 , 如 :-Xms=2g , 高并发应用, 建议和-Xmx一样, 防止因为内存收缩/突然增大带来的性能影响。 c: -Xmn<n>                       指定 jvm 中 New Generation 的大小 , 如 :-Xmn2 ...
不同团队需要用不同的管理方法,管理者会因为自身的情况,调整所在团队的成员。 考虑理论情况: 1、管理者信任宽容,需要团队成员优秀负责 2、管理者严格细致,需要团队成员忠实执行 当组织文化形成时,必然会要求全员的行为一致,又或者团队成员风格和企业文化不一致,必然会有持续的冲突和革命(没有永远合适的企业文化) 做事需要调整风格适应团队,在一个磨合型团队里面(即没有绝对的领袖,各有所长),合适的做法是:先做,不要糊涂做事,要了解清楚意图,但不要提出问题和预见性猜测;实施过程中的问题自己解决,直到事情结束后有问题发生时才提出。 磨合型团队中,如果要取得大家的认可,可以尝试把自己的建议和改进方案提 ...
核心团队的价值观需要一致,大家能力不同是好事,但是价值观不一致,则是坏事。 这意味着,核心团队的工作开展,是建立在相互信任、相互理解的基础上,彼此之间相互依赖且相互信任,处于一种调和的状态。 设想有人以诡道为追求,凡事急功近利,有人以讲求长远利益;又或者有人喜欢承担责任,有人喜欢推卸责任,如何长期合作?
谈论战略,讲到领导者,构成元素: 1、具有奉献精神的志愿者 2、能理解别人 3、能理解别人对自己的不理解 在现实生活中,除了领导者外,其实还有当权者(定义为可以驱使自己行事的人),当权者所需要的,是掌握资源,被当权者所驱使的动力,是利益,通过交易形式发生。
相互依赖 相互信任 能力互补 利益互享 依赖和互补,能力不同且长期发展方向不同
http://blog.chinaunix.net/u3/98494/
重要版本的升级,可以先收集用户的意见(参考如netbeans在社区内收集大多数人的意见确认是否可以发布,多个RC版本),确认后才全面发布,这样可以避免一些测试覆盖面不足(难以全部避免)带来的问题,也可以通过该方法持续积累版本升级的关注点(用于加强下一次的版本测试)。
根据目前公司资源和项目规划做的预测 用户转换率达到一个突破临界点的状态(起步) 完成了旧有系统不合理地方的修正,整体产品处于合理状况 即将开始社区式内容和大型玩法内容的制作 按这样的状况估算,剩余4~5个月,将有余力完成年度目标,并且把整个公司提升至良性状态,在目前竞争激烈的市场环境下,取得这样的成绩可以算是不容易了
系统 # uname -a               # 查看内核/操作系统/CPU信息# head -n 1 /etc/issue   # 查看操作系统版本# cat /proc/cpuinfo      # 查看CPU信息# hostname               # 查看计算机名# lspci -tv              # 列出所有PCI设 ...
名称          默认动作            说明 SIGHUP 终止进程    终端线路挂断 SIGINT  终止进程    中断进程 SIGQUIT 建立CORE文件 终止进程,并且生成core文件 SIGILL  建立CORE文件        非法指令 SIGTRAP 建立CORE文 ...
技术团队有新血融入,新同事经验丰富,可以在工作上分担不少压力,可以预见团队发展的健康持续 公司对产品认识的深度提升了,不再是乱放枪,下一个阶段会靠谱很多,可以预期产品的稳步前进,这包括: 1、做好新用户的教育 2、建立核心的数值体系 3、完成现有系统的深化 4、持续发展各种玩法系统 还有一个是运营所负责的业务指标,也找到了做事的方法,可以持续不断有积累有突破,消除了原有的问题: 1、做完就丢 2、拍脑袋决策
很久没有关心计算机类的书籍,原因有二: 1、跟目前的工作所需关系不大 2、领域理论上的新书已经好久没有了,都是些讲技巧的 今晚心血来潮找了一下,看到JOLT一些关于敏捷方面的书,开始忍不住想要乱喷一下。 敏捷建立的基础,似乎没有啥书会去谈论,不知其所以然,就会导致一头扎进去的结果。 敏捷项目建立的基础,在需求方和实施方,都对所要做的事情,有大致的认同基础上开展的,对互联网项目而言,这恰恰是难以做到的。就像谁也不会想到facebook一开始的样子和今天的差异,推倒重来是互联网项目最大的特点(或许是中国互联网?),这样还可以敏捷不? 产品研发服务于业务,技术服务于产品研发,从逻辑链来讲,技术 ...
追求灵活性,避免官僚主义的组织建设,就是依赖人治,法治必不可少会带来种种约束,所以对发展中公司而言,挑选并培养有潜质的人,是成功的关键,这也是我一贯的观点。 挑选和培养,通过沟通和指导、制造锻炼机会,以身作则等方式进行,我最近把签名档改成“不折腾,细节,沟通,观察,思考”,就是要求自己以身作则,并且将相关理念贯彻到团队中去。 纲要讲完了,下面是部门周会一些主要细节: 1、公司当前的战略和发展信息 2、现阶段问题的思考(有张有弛,分享和思考持续进行) 3、过去一周所取得的成绩和进步 4、过去一周项目进展与执行,改善与集体讨论 5、新一周工作产出与关键点 细节要落实到每个项目和每个人
面试的人多了,为了提高效率,也为了总结积累,特记录面试经验。 对1~2年的工程师,需要考虑的是可用性(起码碰到一些初级问题不用手把手来教),在开发过的项目领域有一定的积累,熟悉一些流行框架的使用,有一定的经验(知道初级错误如何避免),经历过若干个项目,是否已经把学校里面的幼稚磨掉,并且需要喜爱自己的专业,具有良好的基础知识掌握程度,掌握问题的解决能力,是否具有项目的钻研能力, 对3~5年的工程师,需要考虑的是,知其然,也要知其所以然。如,框架的设计原理,对框架依赖技术体系的了解。目前,我觉得很适合问工程师的问题是如何做设计,如ssh是怎么设计出来的,如何取舍,系统如何做性能优化,如何攻克技术 ...
Global site tag (gtag.js) - Google Analytics