手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2010年08月的文章

Enterprise Architect 中文版

Enterprise Architect这款软件非常不错,但是英文版让人很郁闷,毕竟不是每个人都是英文那么好的。
汉化新世纪里居然有这个汉化版,就太让人兴奋了。
Enterprise Architect是一款计算机辅助软件工程(CASE)工具,用于设计和构建软件系统、业务流程建模及更多通用的建模。
EA并不仅仅是一个UML画图工具那么简单,它对整个项目开发过程有着非常好的支持。比较亮点的功能:
· UML建模--支持UML2.1
· 代码工程--按图生成代码,导入原有的代码成为UML图
· 项目管理程序--包括项目计划,任务进度,问题集等
· 文档生成和模板--可使用文字翻译替换和自定义的模板为不同的项目打造最适合的文档类型
· 数据库建模--可从ODBC导入数据源结构,并进行ER图的编辑,还可生成建表的SQL语句
· 代码编辑、调试和运行--加入编译脚本,就可以把EA当作IDE来使用
· 版本控制,联机讨论,局域网协同开发等功能。

Enterprise Architect 8.0 在细节方面改进了非常多,在之前版本中仅是作为附加的一些功能,如代码调试和代码编辑器等等,也渐渐被重视和改进了。Enterprise Architect不仅能作为一个全功能的UML建模工具,还是一个非常成功团队项目管理工具,而如今的Enterprise Architect 8.0,更是向着更实用的IDE发展。
下载地址:http://www.hanzify.org//software/12376.html

Tags: ea, uml

万年历

网上的HTML万年历大约还是几年前的吧?今天在群里有人提到,为什么有的万年历上写立秋是8日,有的却是7日,所以就找了找资料 。

1、http://hi.baidu.com/wlzqi/blog/item/3c5679311e5bee19ebc4afc0.html,这个是介绍的最详细的,还有一些具体的算法

2、http://www.agr.cn/Calendar.htm,这个看上去最专业,但因为代码压缩过了也无法看到具体详情

然后再查资料 ,好象都是说根据现代天文算法制作的。

在这里http://www.fjptsz.com/xxjs/xjw/rj/113.htm,有一位莆田十中的朋友写下了部分代码,还有一些解释。

最后,你可以google一下《天文算法》一书,你会发现有很多链接,可以详细的学习一下(我是没能力了,一些专业的词语都看不懂。。。其实只要不用来算节气,其他的算法网上还是有简化版的,PHP可谓是拿来即可使用。)

Tags: 万年历

杂记

图上的内容我打印成文字了,只是。。。。图片上的人,我没能力打印成文字,抱歉了。

29岁的阿加瓦尔是Posterous博客平台的CEO,今年[被]入选[]美国《商业周刊》2010最具潜力创业企业家,他曾在美国苹果工作6年,近日他分享了从美国苹果公司学到的8点管理经验:

  1. 科技公司应由工程师而非管理者主导
  2. 在管理者与员工之间建立尊重
  3. 给员工更多自由去完善产品
  4. 用挑战促使员工成长
  5. 目标期限非常关键
  6. 不和竞争对手玩“功能堆砌”
  7. 招募那些有疯狂激情的员工
  8. 保持工作与生活的平衡非常重要

郁闷的是,这8点我打了三遍,每次都是快完成的时候突然页面刷新了。靠。受不了。
这个图片是微博上的,看到图片的人都说,第8点几乎是不太可能实现的,或者说在中国没法实现。。。。

2000[1].0

Tags: 印度, ceo, 管理

ThinkInLamp聚会记录

说起来,上次参加聚会到现在已经过去两个月时间了,ThinkInLamp聚会是每个月的第一周的周末举办,这是我第二次参加,在安居客公司的会议室里。
与会者嘛,还是安居客的开发占了大部分,毕竟天时地利人和啊。确实,如果有这样的聚会放在公司里,一来可以让单位的开发人员进行学习二来也可以了解认识一下其他开发人员,对于公司来说几乎没有任何投入成本,但所获颇多(毕竟真要请人来培训花的钱更多。。)
这次聚会其实就三个内容,一团队,二求职,三敏捷开发
从上个月的聚会开发stingchen就开始有他的分享了,可惜7月份无缘参加,(那次还有逍遥冰心讲的领域驱动方面的内容,也没有听到。惋惜,所以这次我怎么样也得来了。)sting介绍了团队建设方面的一些要点,以及注意事情,引起了很多人的共鸣,看来很多人在工作中遇到过类似问题啊(看来领导们很多)
板子介绍的是不要让工作外的事情来影响工作。总结起来就是有一颗平常心,不以物喜不以已悲,了解自己的真实想法做下去,不要频繁跳槽。
最后的敏捷开发就是讲的如何让工作变得更有效率。在讲之前做了一个游戏,每组8个人,每组中又有不同的分工,一个客户,一个客户老板,三个经理,每个经理下面有一个工人。然后分组开始数硬币(当然是有一定的规则)。客户将硬币交给工人时,客户与客户老板同时开始计时,当第一个工人开始翻硬币时,对应的经理开始计时。当第一个工作完成任务后,把硬币交给第二个工人时,第二个工人对应的经理开始计时。当第一个工人全部把硬币给了第二个工人时,第一个工人对应的经理停止计时。客户在收到第三个工人第一枚硬币时结束计时。当最后一枚硬币到达客户手里时,客户经理停止计时。然后做了五次不同方式的游戏,比如从左手到右手再到两只手一起,等等。DannelTeng的意思就是想让我们把工作能够细分,而且并不是在细分全部结束后再下达任务,这样的工作效率会有提高。
突然想起几件事,一小时学的语文课文里有个统筹方法,好象与此类似。还有就是在夜大学习的工商管理中的管理学,都有涉及类似方面。工厂运作本来就与程序开发有类似之处,毕竟理论是一样的,只是在实现的方法中有不同的方式而已,就如那句:戏法人人会变,手法各有不同。当然,如果没有经过培训过的人,可能在工作过程中也会摸索出类似的方式,但如果经过事先培训,岂不是会更加增加工作效率 ?

最后再做一个广告,锅巴哥哥准备在10月份左右举办一次数据库的专题会,他说到时候会请一些数据库方面的专家来与大家分享和讨论数据库设计方面的事情。也坦言在PHP开发中,其实DBA处于一个很尴尬的地位,即DBA在开发中几乎是没有介入开发中的机会,往往数据库的设计都是由开发人员自行设计,这导致在遇到问题时无法进行调优。而这次分享会上,就是请不同行业的专家们来分享如何更好的设计数据库,以及一些调优方法 。
顺便,锅巴哥哥说的原来从最初设计MYSQL时就是为了电信级的应用。我承认我真不了解这个背景,我想,恐怕80%的PHP开发者不了解MYSQL设计的背景吧。了解的最多的恐怕就是开源、免费。想着MYSQL被我们用成这样,不知道那些数据库设计人员是否会很郁闷。
估计,下一周就会有今天分享的PPT和视频出现在thinkinlamp官方网站了。你也可以到官网查看往期的分享(官网:www.thinkinlamp.com)。

Tags: lamp, 聚会, 分享

知道分子:这个版本太新了

知道分子的这个事例事实也经常遇到过。只是谁都没有提出来当成一回事
在自己的机器上,各种不同版本的PHP一直存在着,或许,相对稳定的也就apache和mysql吧?每次要升级前都看着changelog,但即使这样,也会有或多或少的问题发生,然而,在公司的版本库里,测试机里等等中早就存在着不同版本的PHP,只是可能从来就没有注意过罢了。

升还是不升这是个问题,但如果真的版本不对了,出现的问题也就稀奇古怪了,所以,保证版本号一致还是有着非常重要的作用(如果为了新特性需要升级,那就通知所有的人一起升,最终仅保留一台两台有明显记号的,旧版本的服务器专门用来调试,开发人员有虚拟机的也通通升级到统一的版本号里,一切为了稳定 )

下面是知识分子的内容:这个版本太新了

以前偶尔听到同事 A 问同事 B,某软件出新版本了,我们要不要升级?同事 B 果断地回答,这个版本太新了,我们还是别急着升级吧。同事 A 深以为然,刚出来的版本就升级,万一出个故障谁负责?何况现在这个软件跑得好好的,没事最好别折腾。后来 A、B 两人都忘了这件事,也就没有了下文。

 
再后来,同事 C 在另一处需要用到该软件,去官方网站上下载了“最新稳定版”(也就是前面那个“太新了”的版本),用着没问题。又过了一段时间,这个软件又出新版本,同事 D 问同事 E,我们要不要升级?同事 E 说,这个版本太新了,你懂的。于是同事 D 拈花微笑,信受奉行。
 
如此循环往复,同样一个软件,在开发/测试/生产环境里运行着无数个“太新了”的不同版本。
 
先不谈管理成本,“这个版本太新了”是否构成不升级的理由,颇值得解析一番。为什么要出新版本?不外乎安全漏洞 修补、bug 修正、新功能三者(或混合)。安全漏洞显然是要尽早尽快修补的,明知有安全漏洞而不及时修补,无异于后门洞开等待爆菊,有受虐倾向。整体或所调用部分相关 的 bug 也是要修补的,紧急程度视 bug 可能造成的损失大小而定。新功能则要看未来是否会用到,才决定要不要升级。
 
“这个版本太新了”之所以被接受,其中也有一定的合理成分。“太新了”指的是新版本没有经过完整的兼容性、稳定性和性能测试,也许会对现有应用造成影响。这个意思永远是对的,或者不客气地说,就是一句废话。任何一个新版本软件都一样,不去做测试你怎么知道有没有影响?
 
同一个软件,不同的版本,随意分布在多个环境中,这无疑增加了管理的复杂度,当然也有人认为,这体现了“个性 化”。复杂度也好,“个性化”也罢,都是效率的大敌。标准化的高效运维,应该是同一个软件、同一个版本,并且有统一机制进行追踪、测试、升级,保证安全漏 洞、bug 得到及时修补,新功能尽在掌握。

Tags: 版本

Records:45123456789