博客园_探知，不断发现

Quartz 的SB问题 GetNextValidTimeAfter 输出和输出时区不同步，好傻的方法？

2012-06-04T10:08:00Z

测试代码如下

  DateTime kk = new DateTime(2012, 6, 4, 15, 0, 0);
            Quartz.CronExpression cron = new Quartz.CronExpression("0 14 15 ? * *");
            var dt = cron.GetNextValidTimeAfter(kk);

好傻好伤。

dt的时候是

{2012/6/5 7:14:00} 跑出了一个7点来了。

正确的期待值应该是 2012-6-4 15:14:00:00

后面才想到这个时间跟好跟我们差8个小时。(没有去验证它的代码是否真的是这个问题)

后面用了

dt.Value.ToLocalTime();

得到的时间是 {2012/6/5 15:14:00} 跟我们期待值差一天。

查了一下它的方法。还有一个方法 GetNextInvalidTimeAfter

var dtInvalid = cron.GetNextInvalidTimeAfter(kk);

得到的时间是

2012-6-4 15:14:00:00

跟我们的期待值完全一样。不明白原来写的人为什么会这么用啊。

又试了下。

DateTime currenTime2 = new DateTime(2012, 6, 5, 15, 15, 0);
            Quartz.CronExpression cron = new Quartz.CronExpression("0 14 15 ? * *");

            var dt2 = cron.GetNextValidTimeAfter(currenTime2);
            var dt3 = cron.GetNextInvalidTimeAfter(currenTime2);

发现
dt2 是{2012/6/6 7:14:00} // local time后是 2012/6/6 15:14:00:00正确了。 6月5号的触发时间已过了。所以时间应该是 6-6正确。

dt3 是{2012/6/5 15:15:00} //不对原来 GetNextInvalidTimeAfter 是不行的。

本文链接

新的一家公司Web开发选择的控件是Dev Express 太烂了，发现项目结构也是混乱的。

2012-06-01T08:59:00Z

ajax模型跟其它的不太一样

没有现在比较流行的哪种ajaxPanel的概念。有一个CallBackPanel按它的例子去写了。结果发现object是null没有选到。看了别人代码发现很多得用客户端来传递哪个值。（官方文档帮助比较不好看，它的模型也是有点特色的）

多写代码量 3-4倍

AspxGridView烂自定义分页要用很复杂的方式来搞定。（发现一些代码根本就不分页了，直接取1000条出来绑定。。给哥造成很大的压力，改写太难改写。不改写看到了又很受不了。）Telerik的用Onneed_DataSource模型很强大。

原来我主导的项目开发。都是行云流水般的顺利，这边发现太糟糕了。一碰到改代码或新加功能都是碰到一堆长代码。200多行的方法。html不用写在代码的也写在代码里面了。

每深入开发一个功能都发现代码写得烂。而且都伴随着1-3个超明显的Bug。

后面只能先修改和重构导致新功能都没有办法顺利完成的。哪些影响不大的只能先放着。一步步蚕食掉不太好的代码。全盘来是不太可能的。

项目架构不合里（WCF框架应用目的不明确，N多项目各自为战。）
项目结构，（n个类会放在同一个文件）文件夹没有分好，公用基类项目没有搞好。
开发流程没有弄好。（在上一轮的功能没有完成，功能测试具体的测试没有完成就进行了下一轮开发。）
项目主负责人认知不过或没有检查团队成员写的代码。

函数级别也没有搞好。重复代码太多。函数超长。职责不独立。该犯的错都犯了。

不过整个项目还是可以跑得动的。

整个东西最主要还是流程。也就是我们整个项目要有一个结构。这样后面进来的人就可以按这个结构继续工作下去。然后负责人要对新来的要重点照顾一下。再慢慢的减少观察。

要保证它写的代码要符合规范要求（比代码的书写规范要重要。）

1.简单的说一个页面承载多个功能，该独立出Usercontrol要独立出来。而不是一直混在page哪边。

2.重复代码2次以上，必须整理

3.类的职责单一。把相关的整理到一起，把不相关的移出去。太大了考虑是否拆分。

4.需要设计模式的要用。而不是弄了比较烂的n多catch.

5.项目里面传递类型的单位应该是用类，而不是用string来组合到另一个方法哪边再次拆开（原来是绝对想不到有人这样用的）

6.业务模型（领域模型），没有继承意义的时候，千万别因为它们的物理模型有相似的地方来搞继承。没有哪个必要（刚好用的是EF4.1结果生成的SQL就超恐怖了，都是上千行几千的sql语句。）

7.别把简单搞复杂，好多简单的东西变得复杂好多（有部分是受到类库的限制。但更多的是人为自己造成的，比如哪个鸟grid分页就会变得好复杂了）

8.合理分目录（随着代码量不断增加该移动的要不断移动）

9.n个类写成一个文件（禁止。有利于代码快速定位）

10.html结构该被包含的要成被包含，而不是并列关系， li里面是单独的选项。

11.合理使用控件应该使用checkobxlist的地方不要再去用 n个checkbox了。

（待续，如果有发现新的问题）

总结：代码你会感觉符合自然的美，仿佛世界本来就应该是这个样子的。需要写代码的人有一个敏感的心去感触它们，抽象归纳动手整理。

作者：Lovebanyi
出处：http://www.cnblogs.com/Lovebanyi/
关于作者：本人正在做股票自动化交易的软件
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接

本文链接

使用lambda表达式对属性进行验证。

2012-04-06T03:03:00Z

public class NullResult
    {
        public bool Resulst
        { get; set; }

        public string Message
        { get; set; }
    }

class MailConfig
{
    public string MailFrom { get; set; }

        public string MailTo { get; set; }

        public string MailSubject { get; set; }

        public string MailBody { get; set; }

        public bool IsHtml { get; set; }

   public NullResult ParmCheck(Expression<Func<MailConfig, string>> exp)
        {
            MemberExpression memberExp = exp.Body as MemberExpression;
            string name = memberExp.Member.Name;
            string temp = exp.Compile().Invoke(this);
            if (string.IsNullOrEmpty(temp))
            {
                return new NullResult() { Resulst = false, Message = name + " is empty" };
            }
            return new NullResult() { Resulst = true };

        }

        public void Check()
        {

            List<NullResult> list = new List<NullResult>() { ParmCheck(it => it.MailFrom),ParmCheck(it=>it.MailTo),ParmCheck(it=>it.MailSubject), ParmCheck(it => it.MailBody) };
            var query = list.Where(it => !it.Resulst);
            if (query.Count() > 0)
            {
                throw new ArgumentException(string.Join(",",query.Select(it=>it.Message).ToArray()));
            }
            bool _isHtml = false;
            bool.TryParse(settings["IsHtml"], out _isHtml);
            IsHtml = _isHtml;
        }


    }

假设我们有一个接口然后我想对这个接口内部的属性进行一些验证是否有值了。我们这次不想直接用Attribute标签的形式来进行验证。而是希望用lambda的形式来验证。

所以我们我构造了一个

ParmCheck 的方法可以允许我们的代码编写人员直接用lambda表达式的方式来过量行验证了。

ParmCheck(it => it.MailFrom);如果这个属性通不过验证。它就会直接报出这个这个属性通不过的消息了。

这样的好处是在我们如果重构了MailForm属性的时候我们不需要去更改字符串的信息

本文链接

数据库连接字符串配置的流程改进

2012-03-23T09:14:00Z

在几个人一起做项目的时候，（包括和国外的客户一起进行工作的时候），为了调试的方便，（不会影响到他人）我们必须去修改数据库的连接字符串，
因为我们一般还会用源代码的管理工具，比如说SVN，这样很多人比较粗心的就会经常把哪些文件给签进去，这样对于其它人来说就是一个很大的问题了，还有我们的自动每日构建。
对于细心的人也是一个小小的心智负担，这样的情况可以避免的话，我们就要尽量去避免它了。

曾经我们有一个客户是采用，把web.config这样的文件加入Ingore的方案。然后再建一个web.config.default.的文件，但是这样的话会造成我们每次更新是很麻烦的，在我们改变web.config的时候，我们要去通知项目的所有涉众你要去重新获取这个了。

我们的解决方案就是用域名的方式。
连接字符串哪边不直接写ip或者某个服务器的名称，而是域名。这样每个人可以通过自己的Host来修改这个域名。或者更强大的是自己架的域名服务器，可以跟据来源ip来调整不同的反回值。都是可以的。

然后接下来就是装数据库的时候哪个最好都用默认实例。然后数据库连接的用户名和密码也是一样的。（最好不要用SA的帐号）

本文链接

从解放劳动力来看未来的科技进程

2012-03-19T02:33:00Z

有人说直立行走是猴子进化人的标志。自己懂得自己想要的工具才是一个非常重要的标志，智能产生的标识。而我们的发展最终也会走到创造人工智能方面，然后最终有可能被人工智能所灭亡。

从最早的时候我们的祖先开始进化了，他们也许通过归纳总结的方式，可以创造出符合自己使用的东西了。这样可以让自己的工作效率得到一定的提高。

慢慢的也许也懂得使用畜力，水力，和大自然的风力。但是这些力量方面的使用可能都不是非常的方便，水力很多方面都需要河流和落差。有一些能源不好转化为机械的运动。但是不管如何使用这些动力和相关的机械，使得很多的工作是机械自动化了。这样我们的劳动力又得到了部分解放。

再接下来有一个地方就是使用人造动力了，蒸气机的使用，内燃机的使用，特别是电力的使用，由于电力能源的转换性非常好，我们可以在各个领域采用电力能源了。同时由于电力使用的方便性，我们在很多领域都可以实现更加复杂的机械自动化。（我们社会在这方面也没有全部实现自动化，还有好多人工的地方，因为出现了人工成本比机械成本还低。这个随着机械成本的降低，很多人同样会面临失业。）

在解决体力劳动力方面，上面的实际上已经做得不错了，只需要不断加强这样的一个过程就可以了。

接下来，当然是脑力劳动方面的了。就拿一个计算机器来说，它的计算可以比我手动计算要快多了。现在我们大部分的东西实际就是处在这个阶段。各种各样东西的计算，统计，自动处理，比如常见的有，各种排课系统，布匹裁剪，钢筋剪切，火车的防追尾，行的自助存取款，等非常多。但是这些东西都有一个特点是，他们没有创造性，他们的自动处理过程，都是我们人类为他们编制好虽然有一些东西也叫做人工智能，但哪实际上都并不是真正的人工智能，他们大部分是没有自主性的思维，因为没有自主性的思维所以它们还没有办法做我们人类一些可以做的事情。但是这个过程实际还在发展当中，比哪些更高级的还有，股票自动化交易的程序，自动发垃圾贴的机器人，自动聊天机器人，可以理解人类部分思想的智能助手，就是当下的我们社会所处的阶段了。（而我们要想取得比较好的成绩当然得在这方面努力，取得足够的资金并进入下一个阶段的研究了，所以我自己也花了蛮大的时间在研究股票自动化交易，如果这方面做得好的话，哪就可以为我们提供蛮多的资金了。）因为脑力方面自动化，同样的可以让我们制作出可以完成复杂功能的自动化械。比如有自动扫地机。

人脑的终级解放，懂得自我创造的机器人，人工智能。这个肯定是未来发展一个大的方向，而且应该也是没有办法避免的事实。可能现在大部分人研究的方向不太对。研究这个东西我觉得要去研究一个小孩子是如何学会我们社会当中的一些东西的。个人的感觉是要制作出一个可以归纳总结推理可以接受外界反馈和对外界产生反馈的东西就可以达到这样的目标了。
当然这些同样需要电脑的计算速度不断的提高。不然哪些自动总结和推理可能会蛮浪费时间的。

机器人对人类造成的问题。如果人类没有在体力上或者某方面超越机器人的话，哪么机器人最终肯定会取代人。成为所谓的硅基生命。而这也是我们没有办法避免的问题。机器人三大定律根本是不可能解决这样的问题的。

本文链接

SNS商业

2012-03-11T03:35:00Z

业务的一个场景，我想每一个人都会经常碰到有一些人不懂某个方面的知识，然后来问我们，比如说“厦门哪边有免税商店卖aplle”，但是有时候我们也不知道我们的哪些同事谁可以帮我们，谁有提供这种服务。
分析一下上面的这一个场景，为什么会这样呢？为什么他会问你，因为他信任你，信任你这方面的知识，知道你如果有帮他的话可以帮他做得更好。
朋友的朋友，很多时候我们本身并没有办法帮朋友提供某种服务。但是我可能认识有的朋友有这样的服务，并且我们也信任他，知道他可以帮我们把事情做好。
六度理论：你和任何一个陌生人之间所间隔的人不会超过六个，也就是说，最多通过六个人你就能够认识任何一个陌生人。这就是六度分割理论，也叫小世界理论。
在来一个实例，我要买一台笔记本，我搜 “笔记本”。 ok这个时候要发生什么样的事情。我们将聚合他的服务和他朋友的服务，也许包括他朋友的朋友的服务，如果有某个有这个服务的话哪他就可以找到了。

本人没有办法去做这个了。有想法就直接写出来了。

本文链接

需求的理解

2012-03-11T02:58:00Z

需求的理解 (在这边我们假设拿到的需求说明书（有可能是OO的文档，有可能会掺着一些设计，很多时候经常是会忽略好多的业务逻辑，或者业务逻辑自相矛盾。）)

这是一个什么样的系统呢？
如何进行这个操作呢？当拿到一份文档的时候我们当然是打开阅读它了在通读之后我们大概需要了解的
第一个事情呢？就是我们是需要搞明白这个系统到底是为某个行业服务，或者说是什么类型的系统。比较简单的来说我们可以判定他是一个（销售激励，网店，企业网站，某种信息类型服务（hotel查询，或者垂直搜索），娱乐性站点，）
这个系统大吗？
它是否会涉及到很多的用户，一般来说平台类型的系统都是属于大型的系统。这个在后续的数据库中就要注意到这个问题了。
是否存在什么样的技术难点？全局规约是否有没有注意到的地方。
视频转换，垂直搜索，域名注册，在线支付，SSL, TCP/Socket, 手机浏览器
一般来说你没有碰到过的技术都可以认为是你的难点，如何去处理它呢？所以是找自己所在的小组里面的成员来咨询一下，前面他碰到这个东西的时候是如何处理的。有没有什么东西是需要注意到的。这样做的好处是？不这样做会带来什么样的影响。如果你对方面一点知识也没有的话最好是先baidu,google一下。是
业务规则有冲突吗？业务设计是否完善，是否存在某个方面的缺陷，
如果是只是单纯的阅读，我们有时候没有办法让自己身其境去考虑问题。思路进行是一个一维的过程。我们也比较难得出，他会有什么东西没有弄好。
这个时候我们需要的是画出他的用例，不断的从上面的哪一份文档中，画出所需要的用例，然后合并角色，这个时候时候我们基本就可以找出所有的用例了。所有系统必须做的东西，然后我们就需要组合这些用例画出我们的业务场景，并在业务场景，找出他这个文档没有描述的到东西记录到临时文档里，等需求分析结束后发给用户来确认。
这里边一般是会要求到经验了：
某些系统需要的用到的通用功能他都没有描述是他不懂还是无意中的没有记录进来呢（比如用户退出，用户忘记密码）文档有时候只会描述用户登录跟本就不会描述到退出，通常我们需要进行一下逆向思维。如果你有组员的你可以向他们重述一下整个系统。这时候他们就比较容易发现某个地方没有弄好。你也可能是自己发现了.
用例场景如果时间比较充裕的话我们可以深入到每一个用例场景，有一张用例场景太一样了。基本每个系统都是哪样进行的，我们就可以舍去了。而一些比较重要的场景我们就必须画出来了。在后面的需求确认文档里就会用到了.

作者：Lovebanyi
出处：http://www.cnblogs.com/Lovebanyi/
关于作者：菜鸟一枚。如有问题或建议，请多多赐教！
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接
如果您阅读了我的文章并觉得有价值在充话费的时候就到小店充话费吧

本文链接

需求调查

2012-03-11T02:56:00Z

常常用户是没有办法告诉你，他想用的是什么样的一个东西，如果是传统行业的话，我们就有必要自己上门不断的了解每个岗位上的他所会做的东西。

而在公司的现有环境中，我们基本上是不会做到这个的。需求的文档是有客户完成的。但是如果有时候我们在业余的时间还是会接触到一些小单子的，
这个时候我们就需要自己来做这个需求的分析了，需求要是没有分析好。到时候客户就会拖欠钱款，并且可能对你印象不好。好不容易可能发展的一个客户，
就因为你做出来的东西，跟人家要求的不太一样。而拿不到钱。白白辛苦了时间。

做需求分析，我个人比较推荐的是。《大象--Thinking in UML》从作者还没有出书就刚开看他的序列文章了。
在做需求的时候，我们需要知道这个系统，所参与的角色有哪些。我们需要引导一些不太懂行的用户去思考，他做出这样的一个系统，是为谁服务的，有哪些用户可以用到这个系统，
哪些用户在用这个系统的时候会用到哪些功能（实际就是用例了）这些用例的场景又是如何呢？系统的边界在哪里，有一些用例我们会发现是我们系统自己完成的，
我通常会把这个角色定义为Robot，就是Robot有哪些自己的用例要完成。（比如定时清除系统的一些文件，日记，进行一些信息统计等。）

（发现自己的哪本《大象--Thinking in UML》又不见了，不懂被谁给借去了。）

本文链接

前言让自己的思路可以成为一个比较好的系统。而不断的改进完善。

2012-03-11T02:41:00Z

当一个项目来的时候，我们是很糊途的渡过呢。还是很清楚自己是在哪一步，我们开发中碰到了问题什么处理，
我们经验让他它白白流失吗。

在开发的过程中有时候我们会突然想到一些点子，一些处理方法的特有套路，规则。你是否记录了下来呢？

我自己就记录了我在开发过程中碰到的一些问题。及不断总结的规则了。这样当我们在处理一些新的项目的时候，我们就可以有很轻松的完成这样的任务了，
而不是很茫然的完成它。事否感觉没有一点点的进步。进步的只是conding技巧罢了。

在我们不断总结规则的时候，我们可以跟其它一些人的观点进行对比。归纳出最合适的方法。

感谢原来的同事在公司推荐了一个知识文章管理的小软件CyberArticle。用了这个软件之后，我的大部分的文档就不断得到了积累了。

本文链接

WCF枚举属性出错 wcf 枚举的一个陷阱

2012-03-02T06:18:00Z

[DataContract]
    public enum GetMailType
    {

        [EnumMember]
        DDA=1,
        [EnumMember]
        KVK=2,
        [EnumMember]
        BTW=3,
    }

我们有一个类。放在数据库当中用的

[DataContract(IsReference = true)]
public class UnaddressConfig
{

[DataMember]

public int GetMailTypeID
{ get; set; }

[NotMapped]
        [DataMember]
        public GetMailType GetMailType
        {
            get { return (GetMailType)GetMailTypeID; }
            set { GetMailTypeID = (int)value; }
        }

}

我们系统当中有一个方法 Save(UnaddressConfig config)
客户端添加WCF引用后调用这个方法的时候可能会造成。
config.GetMailType=GetMailType.DDA

在服务端我们会发现在这个值可能是0

为什么会这样呢？

因为

GetMailTypeID 这个值就是0.

解决的方法是把 GetMailTypeID的Atribute

[DataMember]

去掉。因为我们客户端实际也不需要这个。只是数据库哪边需要。(如果 Entity framework哪边直接支持枚举就更好了).

本文链接

博客园_探知，不断发现

Quartz 的SB问题 GetNextValidTimeAfter 输出和输出 时区 不同步，好傻的方法？

新的一家公司Web开发选择的控件是Dev Express 太烂了，发现项目结构也是混乱的。

使用lambda表达式对属性进行验证。

数据库连接字符串配置的流程改进

从解放劳动力来看未来的科技进程

SNS商业

需求的理解

需求调查

前言 让自己的思路可以成为一个比较好的系统。而不断的改进完善。

WCF枚举属性 出错 wcf 枚举的一个陷阱

Quartz 的SB问题 GetNextValidTimeAfter 输出和输出时区不同步，好傻的方法？

前言让自己的思路可以成为一个比较好的系统。而不断的改进完善。

WCF枚举属性出错 wcf 枚举的一个陷阱