显示下一条  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 
 
 
 

上海市 徐汇区 狮子座

 发消息  写留言

 
新生代程序员
 
博客等级加载中...
今日访问加载中...
总访问量加载中...
最后登录加载中...
 
 
 
 
 

日志分类

 
 
日志分类列表加载中...
 
 
 
 
 

热门日志

 
 
数据列表加载中...
 
 
 
 
 
 
 
心情随笔列表加载中...
 
 
 
 
 
 
 
日志评论
评论列表加载中...
 
 
 
 
 
 我要留言
 
 
 
留言列表加载中...
 
 
 
 
 

自定义模块

 
 
模块内容加载中...
 
 
 
 
 
 
 
 

读《深入浅出WPF》

2012-5-16 9:46:06 阅读7 评论0 162012/05 May16

正文之前

微软在WPF技术方面有相当的务实精神和决心.net开发人员学习WPF的回报是相当高的,几乎整个微软新一代开发框架都能看到WPF的影子。学习完WPF,WF也会了一小半;学习完WPF后,Silverlight可以算是会了80%Windows Phone 7中运行的Silverlight与浏览器中运行的Silverlight别无二致MVC(Model-View-Control)模式和MVP(Model-View-Presenter)模式均使用事件驱动事件驱动时代,用户每进行一个操作会激发程序发生一个事件,事件发生后,用于响应事件的事件处理器就会执行。事件处理器是一个方法,在这个方法中,程序员可以处理数据或调用别的方法,这样程序就在事件的驱动下向前执行了。事件驱动时代的数据是静态的、被动的;界面控件是主动的、界面逻辑与业务逻辑之间的桥梁是时间。数据驱动下,当数据发生变化时,会主动通知界面控件、推动控件展示最新的数据;同时,用户对控件的操作会直接送达数据,就好像控件是透明的。数据占据主动地位、控件和控件事件被弱化(控件事件一般只参与界面逻辑,不再染指业务逻辑,使程序复杂度得到有效控制)

第一部分 深入浅入话XAML

第1章 XAML概览

UI代码与逻辑代码纠缠在一起的后果:无论是软件功能还是UI设计有所变化或者是出了bug,都将导致大量代码的修改会让逻辑代码更难理解——修改往往比重写更困难,因为在修改之前必须先读懂重用逻辑代码编程了Mission ImpossibleXAML帮助开发团队真正实现了UI与逻辑的剥离。因根本无法在其中加入程序逻辑,这就强制的把逻辑代码从UI代码中赶走了

作者  | 2012-5-16 9:46:06 | 阅读(7) |评论(0) | 阅读全文>>

[转]HTML5,庞氏傀儡

2012-5-3 11:15:50 阅读34 评论0 32012/05 May3

谨以此文献给初出茅庐以及在纠结中往复徘徊的HTML5开发者们

昨天,听朋友说HTML5开发了一款很牛气的3D页游,名叫《霸刀》。于是乎,我怀着忐忑的心打开了官方网站,注册好账号后才发现:

咋咋呼呼的原以为神一级的WebGL突然转世重生临幸人间;怎知却冒出个非得安装HTML5插件来……大哥,别忽悠我了,你是病毒吧?!

说真的,我从来没有听说过HTML5还要安装插件?至于这样玩弄我的感情吗?

算了,码农肚里能撑船,不和它计较。哥5月底还要参加在职研究生考试呢,回家好好复习去。

屁股坐稳,打开家里那台老旧的破电脑,强忍着“咯吱咯吱”比锯木头好听点的硬盘声,终于进入了神马《..研究生..平台》;你要知道,这可是能与《火车…售票网站…》一决高下的殿堂级产品,日访问量不下百万的国家顶级IT技术专家开发的网站!不管你信不信,我反正信了。

接下来又是一场惊心动魄之旅,我用Firefox打开它,突然蹦出乱七八糟的界面,顿时吓得四脚朝天,口吐白沫。你Niang的不兼容Firefox也用不着拿这东西来吓唬我吧?!

愤愤的,我果断拿起手中的行动电话致电教育部热线,信息科一位很甜美的声音回复说:您好,感谢您的宝贵意见。我们的系统已经运作了很多年,运行非常稳定,界面清晰,结构合理,得到广大考生们的一致好评,将来打算长期使用下去。

生气,真的很生气。做为一名职业高强度密集型技术宅男,这是对我智商最深层次的侮辱!郁闷,难道支持HTML5的浏览器比中国人活得还要艰难?

算了,哥想得开。因为,还有Chrome嘛。

作者  | 2012-5-3 11:15:50 | 阅读(34) |评论(0) | 阅读全文>>

得到当前正在运行的方法或属性名[C#]

2012-4-18 22:50:08 阅读51 评论0 182012/04 Apr18

C/C++在编译时有个__FUNCTION__宏可以获取当前的方法名,而C#中并没有这样的预处理宏,无法在编译时获得函数名信息。但C#中却可以通过反射来在运行时拿到这些信息。MethodBase.GetCurrentMethod().Name就是一个很好的渠道; 而通过指定可忽略的栈深度new StackFrame(0).GetMethod().Name提供了更大的灵活性。

以上方法在可以方便得到普通函数的名称,但将其用于属性(Property)时,会得到get_Property或set_Property这样被修饰过的名字。如果我们要得到代码中的属性名,需要将签名的get_和set_修饰去掉。当然不能简单的进行Substring(4),否则就无法和用户定义的get_UserMethod方法区分。这是个问题...

public static string GetMethodName()

作者  | 2012-4-18 22:50:08 | 阅读(51) |评论(0) | 阅读全文>>

[转]动画图解一般看不见的机械原理

2012-4-4 11:31:29 阅读88 评论4 42012/04 Apr4

现代生活离不开各种机械,无数复杂的机械走进了我们寻常百姓的生活中,小到我们家里客厅墙上的挂钟,大到出门上班用以代步的汽车,都离不开机械在其中默默的工作。不知道你有没有偶尔想问,究竟是什么样的机械,通过怎样的方式在运转,让我们的生活更便利呢? 平日里,我们习惯了在产品外观上品头论足,感慨设计师的精彩创意,那么今天,我们来通过以下动画来感受一下工程师们那不亚于艺术家的机械设计的美感吧。

作者  | 2012-4-4 11:31:29 | 阅读(88) |评论(4) | 阅读全文>>

[转]需求变化与IoC

2012-3-27 17:47:48 阅读47 评论0 272012/03 Mar27

需求又变了,怎么办?

先上一个轻松的段子:

程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫。可他的Lead和亲人没有放弃,他们根据XX工作如命的作风,每天都在他身边念:“XX,需求又改了,该干活了,你快来呀!”,奇迹终于发生了,XX醒来了,第一句话:“需求又改了?”。

这个段子用幽默的方式反映了需求变化是每一个程序员、架构师或项目经理都会经常遇到的问题。面对这个问题,不同的人有不同的应对之道,最近微博上有一段关于需求变化的讨论:

@假装刺猬的猪:我们在软件开发过程中,会持续碰到客户需求变更的情况。如果没有领域建模,我们单纯将问题使用直觉将问题解决,那么等到客户需求变更或者有新的需求时,就会面临一个僵硬的前设计!无法在以前的设计上持续深入的优化模型,导致需求变更无法及时深化。设计实现均滞后与变更!

@高煥堂: <碰到客户需求变更的情况>是合理的;但<领域建模>不是美好的手段!!!

@weidagang: 要不被客户牵着鼻子走,需要自己有很强的设计能力,反过来让客户跟着你的设计来满足你的要求。能做到这点的公司很少,但这是软件行业唯一有希望的出路。

@高煥堂: <这是软件行业唯一有希望的出路>。 Great!!

如何应对需求变化? @假装刺猬的猪 的答案是领域建模,并持续优化模型,适应需求的变化。@高煥堂 则认为领域建模不是美好的手段。我进一步补充,应该“反过来”让自己在需求变化中处于主导地位,而不是被动地适应。

作者  | 2012-3-27 17:47:48 | 阅读(47) |评论(0) | 阅读全文>>

查看所有日志>>

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2012

   
创建博客 登录  
 关注