Mikel

[转载]程序崩溃后如何更好的反馈信息 – 2012 – 博客园. 我们使用Windows都知道，整个Windows和微软提供的应用软件的稳定性和崩溃后的体验是逐步提升的。在大牛的作品《软件调试》 中有描述。 在Windows下，软件出错，常见的报告手段： 1、事件日志：这里记录了很多关键的错误信息 2、崩溃报告：可以自动提交错误的信息，或者手动提交，以不断的改进软件和方便排错 3、专用的日志工具：如Netmon，sysinternal等   那我们的软件在崩溃后如何处理呢？主要目的： 1、方便我们的排错 2、提供更好的使用体验 最近在设计一个应用系统时对这个问题进行处理。 这方面有比较多的参考： 首先在stackoverflow上可以看到，c++ release  program crashes report http://stackoverflow.com/questions/112831/how-to-get-a-stack-trace-when-c-program-crashes-using-msvc8-2005 以上有比较多的框架和工具 Windows应用程序处理的一个框架和详细参考资料 Integrating Crash Reporting into Your Application – A Beginners Tutorial http://www.codeproject.com/Articles/308634/Integrating-Crash-Reporting-into-Your-Application http://code.google.com/p/crashrpt/ http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu Google breakPad Google breakpad是 一个非常实用的跨平台的崩溃转储和分析模块，他支持Windows，Linux和Mac和Solaris。由于他本身跨平台，所以很大的减少我们在平台移 植时的工作，毕竟崩溃转储，每个平台下都不同，使用起来很难统一，而Google breakpad就帮我们做到了这一点，不管是哪个平台下的崩溃，都能够进行统一的分析。现在很多工程都在使用他：最著名的几个如 Chrome，Firefox，Picasa和Google Earth。另外他的License是BSD的，也就是说，我们即便是在商业软件中使用，也是合法的 http://code.google.com/p/google-breakpad/ http://bigasp.com/archives/450   调试Release发布版程序的Crash错误 http://www.cppblog.com/Walker/articles/146153.html http://blog.sina.com.cn/s/blog_48f93b530100fsln.html   对于托管程序也有 Good crash [...]

[转载]利用log4net记录操作日志 – justconnor – 博客园. 1，目的：将用户操作日志写入SQL server 数据库中 2，实现步骤： 一，下载log4net.dll （推荐从官网下载 http://logging.apache.org/log4net/download_log4net.cgi） 二，在项目中引用 log4net.dll 三，添加一个配置文件：我这里命名为 log4net.config（也可以在web.config里面配置为便于管理故新建了一个配置文件） View Code <!–?xml version="1.0"?–> <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net "></section> <!–这里是表示是记录1 条到缓冲区，满1条后再写入SQL server 可根据需要自定义配置–> 四，在项目的 AssemblyInfo.cs 文件的指定log4net 的配置文件路径 [assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config", Watch = true)] 五，自定义记录函数 View Code 　　public static void Operate_Log(string operateType, string describe) { log4net.ILog logToSQL = log4net.LogManager.GetLogger("iNotes"); [...]

[转载]世界上第一本交互式时间管理电子书-时间管理-时间管理行动家. 我在这次的杭州时间管理研习会上发布了这本交互式时间管理教科书，大家都觉得很酷~我也一样  ：） 回到西安之后立刻写这篇文章和大家分享！ 关于这本书 我打算制作三本时间管理教科书，分别是： 《邮件狂人》 《手机控》 《笔纸达人》 分别介绍如何用邮件、用手机、用笔纸管理好自己的行动（GTD方法） 这次放出的是第一本：《邮件狂人》，这种方法适合于想要管理好每天50+邮件的人~ 制作方法当然是用iBook author了，苹果提供的这个工具真的很酷！！ 可是因为著作权的关系，目前发现中国区上传的电子书不能被中国区下载，其他区域的账号可以，我不太清楚解决的方法，所以只能把电子书放在网站和网盘上提供下载，如果您知道解决的办法，欢迎用最下面的邮箱联系我，谢谢。 如何下载与阅读 对系统的要求： ibook2+iOS5 iPad 阅读方法： 下载电子书 拖入到iPad里 打开ibook阅读 电子书下载地址（共300M）： 我的博客 115网盘 这里有视频可以预览： http://v.youku.com/v_show/id_XMzk0MTE2NDE2.html

[转载][译] 命名有意义的版本号2.0.0-rc1 – yaoxing – 博客园. 原文链接：http://semver.org/ 在软件管理的世界里有一个可怕的地方叫“依赖地狱(dependency hell)”。你的系统越是成长壮大，你越是整合更多的软件包到你自己的系统中，你越有可能在将来的某天发现自己已经掉进了这个绝望的深渊。 在一个有着众多依赖的系统里，发布新版本可能很快成为一个恶梦。如果依赖定义得过于紧密，你就有可能进入版本锁定(version lock)的状态（版本锁定是指一旦更新一个软件包，就不得不更新其他所有依赖于它的包）。如果依赖定义得过于松散，你又难免会被版本穿插 (version promiscuity)所伤（让人以为会与多得不合理的未来版本兼容）。当你被版本锁定或版本穿插所阻挠而不能容易地让你的项目顺利前进时，你就身处依 赖地狱中了。 作为这个问题的解决方案之一，我提议用一组简单的规则和要求来约束版本号的分配和增长规则。为了让这套理论运作，你必须预先定义好自己的公共 API。这可以通过文档定义或代码强制要求来实现。无论如何，这套API的清楚明了是十分重要的。一旦你定义了公共API，你就可以通过修改相应的版本号 来通知大家你的修改。考虑使用这样的版本号格式：X.Y.Z（主版本号，次版本号，补丁版本号）修复Bug但不影响API时增长补丁版本号；API保持向 下兼容的增加/修改时增长次版本号；进行不向下兼容的修改时增长主版本号。 我把这套规则称为“语义版本命名(Semantic Versioning)”。在这套工作模式下，版本号和它们的增长模式就会传达从当前版本向下一个版本进行了怎样的修改。 语义版本(SemVer)命名规范 在篇文章里出现的关键字“必须”，“必须不”，“要求”，“应该”，“不应该”，“一定要”，“一定不要”，“推荐”，“可以”和“可选”将在RFC2119中描述和解释。（以下译文中原样使用这些关键字看上去会比较生硬，但为了清楚地传达作者的意图和保持RFC2119关键字的意义，仍然照这里的翻译来使用——译者注） 使用语义版本命名的软件系统必须定义一套公共API。这套API可以是在代码中申明或是用严格的文档定义。不管怎样做，它都应该清楚明了。 正常的版本号必须使用X.Y.Z的形式并且X/Y/Z是非负整数。X是主版本号，Y是次版本号，Z是补丁版本号。版本号每次必须只能增长1。例如：1.9.0->1.10.0->1.11.0。 当主版本号增长时，次版本号和补丁版本号必须清零。当次版本号增长时，补丁版本号必须清零。例如：1.1.9->2.0.0，2.1.7->2.2.0。 一旦发布了具有版本的包，那个版本的内容必须不能再更改。任何修改必须发布成一个新版本。 主版本号0 (0.y.z)是用来进行初始开发时使用的。任何东西都可能在任何时候改变。公共API此时应该被认为是经常变动的。 版本1.0.0开始定义公共API。这个版本及以后的版本号的增长方式将依赖于公共API以及它如何变化。 如果有任何向下兼容的bug修复发生，补丁版本号Z (x.y.Z | x > 0)必须增长1。“bug修复”被定义为内部进行的修复非正常行为的修复工作。 如果进行了新的并且向下兼容的公共API添加和修改，次版本号Y (x.Y.z | x > 0)必须增长1。如果任何公共API被标记为“过期”，次版本号必须增长1；如果有大量的新功能或改进在内部代码中发生，次版本号可以增长1；这其中也可以包含补丁级别的修改。当次版本号增长时补丁版本号必须清零。 如果对公共API有任何向下不兼容的修改，主版本号X (X.y.z | X > 0)必须增长1。这其中也可以包含次版本和补丁版本级别的修改。当主版本号增长时次版本号和补丁版本号必须清零。 预览版本（pre-release version）可以通过在补丁版本号后追加中横线以及由点分隔开的一系列标识来表达。标识必须由ASCII字符和中横线[0-9A-Za-z-]组成。预览版本能满足相关版本的要求，但优先级低于相关版本。例如：1.0.0-alpha，1.0.0-alpha.2，1.0.0-0.3.7，1.0.0-x.7.z.92。 构建版本（build version）可以通过在补丁版本号或预览版本后追加一个加号和一系列由点分隔标识来表达。标识必须由ASCII字符和中横线[0-9A-Za-z-]组成。构建版本能够满足相关版本的要求，并且优先于相关版本。例如：1.0.0+build.1，1.3.7+build.11.e0f985a。 将版本号分为主版本号、次版本号、补丁版本号，预览版本，构建版本，必须按这样的按顺序分别逐级考虑来确定版本顺序。主版本号、次版本号，补丁版本号总是通过数字大小来确定顺序。预览版本和构建版本的顺序必须由 比较由点分隔标识来确定，规则如下：如果标识只有数字，则由数字大小决定；如果标识包含字符和中横线，则由比较字符的字典顺序来确定。数字标识的顺序永远 低于非数字标识。例如：1.0.0-alpha < [...]

[转载]SVN自动更新测试服务器工作副本(C#写winform程序实现) – Machine Lee – 博客园. 根据工作需要，项目将采用SVN做版本控制，于是乎就安装了如下软件： 1、TortoiseSVN Version：1.6.7 2、Subversion Version：1.6.5 3、VisualSVN Version：2.0.6 其中1是SVN客户端，2是服务器，3是用于与VS .Net framework集成的组件。 具体安装步骤就不多讲了，网上很多帖子都详细描述过了，本文主要讲的是如何实现最新提交自动更新到测试服务器工作副本。   背景： 为什么要实现SVN自动更新呢？因为实际开发过程中，程序员一般都是在本地开发机上 开发，本地验证无误后上传至测试服务器验证生产环境正确性，修改代码多的时候，上传文件也是一件累人的活，还浪费时间，所以就有了实现SVN自动更新到测 试服务器工作副本的需求，既省时，又能保证文件不遗漏。   过程： 要实现SVN自动更新，无非就是使用SVN的钩子，网络上不少帖子都是讲如何通过版 本库hooks文件夹下post-commit文件实现自动更新的，有的是写成.bat文件，有的是shell脚本。笔者开始是借鉴网上的方法，写成了 post-commit.bat文件，实现了自动更新。但是，由于我们的项目比较大，写成.bat文件的话，就只能在根目录下执行update操作，速度 非常的慢，大概是2分钟。是可忍孰不可忍，于是上网查找，发现.exe文件也可以作为钩子程序嘛，这不就简单了，于是用C#写了个Winform程 序，commit+update瞬间完成！下面是C#代码，有详细的备注，供大家参考！ using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Text; using System.Windows.Forms; using System.Diagnostics; using System.IO; using System.Text.RegularExpressions; namespace SVNGetTheLastRes { public partial class [...]