我们是这样写升级日志的,处处能够体现人文情怀

做软件,特别是SaaS软件,一般都会把升级日志发布给用户。

让用户知道每次都升级了哪些内容。传统的格式无非是:

1、新增了某某button

2、改动了无法保存的错误

3、...

我们略微给升级内容增加了人文情怀。升级日志本来就是开发人员与用户的沟通的一个载体,何不写的轻松点呢?请看我们的做法。

超级表格已经升级多次了。

直到本次升级,我们发布了升级内容。内容是这样写的:

2014-05-26:这是我第一次记录升级内容。以后每次升级都会在这里累计记录

----------------------------------------------------------------------------------------------

1、添加了“自己主动保存”复选框。表格默认模式是“自己主动保存”。

也能够选择手动保存。

(感谢晓玲意见,促使我们尽快搞定这个)

2、文件菜单导航改进了。

(苏河汇用户督促)

3、在线表单页面改进:

* 提供“通过password訪问共享表格”的功能。

* “浏览历史”功能:同意提交表单的人查看提交过的记录;

* 同意改动15分钟内提交的记录。

* 加入了描写叙述字段。

(感谢佛山某校张老师提的意见)

4、原来表格行非常多时。光标移动到下方超出屏幕时,表格标题就看不到。如今能够在页面顶部显示当前列的标题。

(最好的效果是固定标题行,但...)

5、新建菜单加入了“纯文本文件”、“讨论主题”子菜单。

如今起能够创建纯文本共共享了。

(这是我们自作主张的新功能。不知大家是否用得着)

6、同意通过鼠标拖动改动列宽。

(拖动效果还是不够好)

7、改动了大量细微的bug。

(这两个月一直在改bug)

8、改进了新建表格的引导过程。

(但还是不太惬意)

----------------------------------------------------

原文请看參考这里:http://www.domypp.com/index.php/Project/main/id/14052709235862995603

今后还要改进。或许能够增加很多其它的开发新的,图片,视频什么的。处处显示我们的情怀,告别传统单调的冷冰冰的代码风格。

超级表格有兴趣的单击这里

时间: 2024-10-14 17:19:07

我们是这样写升级日志的,处处能够体现人文情怀的相关文章

我们是这样写升级日志的,处处可以体现人文情怀

做软件,特别是SaaS软件,一般都会把升级日志公布给用户.让用户知道每次都升级了哪些内容.传统的格式无非是: 1.新增了某某按钮 2.修改了无法保存的错误 3.... 我们稍微给升级内容加入了人文情怀.升级日志本来就是开发者与用户的沟通的一个载体,何不写的轻松点呢?请看我们的做法. 超级表格已经升级多次了.直到本次升级,我们公布了升级内容.内容是这样写的: 2014-05-26:这是我第一次记录升级内容,以后每次升级都会在这里累计记录-------------------------------

SQLite 预写式日志

SQLite在3.7.0版本引入了WAL (Write-Ahead-Logging),WAL的全称是Write Ahead Logging,它是很多数据库中用于实现原子事务的一种机制,引入WAL机制之前,SQLite使用rollback journal机制实现原子事务.       rollback journal机制的原理是:在修改数据库文件中的数据之前,先将修改所在分页中的数据备份在另外一个地方,然后才将修改写入到数据库文件中:如果事务失败,则将备份数据拷贝回来,撤销修改:如果事务成功,则删

python 提交SVN 写更新日志

SCENE = "mjdy_dyhry" DIRS = { "md5/scenes/" + SCENE, "data/tex/scenes/" + SCENE, "data/tex/share", "data/mesh/scenes/" + SCENE, } import os WORKSPACE = "D:/workspace/muData/"#os.getcwd()+ # execu

预写式日志WAL

Chapter 25. 预写式日志(Write-Ahead Logging (WAL)) Table of Contents 25.1. WAL 的好处 25.2. WAL 配置 25.3. 内部 预写式日志 (WAL) 是一种实现事务日志的标准方法.有关它的详细描述可以在大多数(如果不是全部的话)有关事务处理的书中找到. 简而言之,WAL 的中心思想是对数据文件的修改(它们是表和索引的载体)必须是只能发生在这些修改已经记录了日志之后, 也就是说,在描述这些变化的日志记录冲刷到永久存储器之后.

Chapter 11.预写式日志(Write-Ahead Logging (WAL)

11.1. 一般性描述 预写式日志 (WAL) 是一种实现事务日志的标准方法.有关它的详细描述可以在 大多数(如果不是全部的话)有关事务处理的书中找到. 简而言之,WAL 的中心思想是对数据文件 的修改(它们是表和索引的载体)必须是只能发生在这些修改已经 记录了日志之后 -- 也就是说,在日志记录冲刷到永久存储器之后. 如果我们遵循这个过程,那么我们就不需要在每次事务提交的时候 都把数据页冲刷到磁盘,因为我们知道在出现崩溃的情况下, 我们可以用日志来恢复数据库:任何尚未附加到数据页的记录 都将先

android 写行为日志到SD卡 并发处理 异步写入数据到文件不影响界面响应时间

公司在做一个项目 要求记录用户行为,写行为日志文件到SD卡.实现思想 不影响界面用户体验,要时时记录日志 不能漏掉. 1.并发处理日志 写一个类负责管理各个线程传过来的日志数据,日志数据放在队列中等待写线程去处理.这里每次添加一条日志数据都会检查写日志线程是否在工作,同时为了并发处理传过来的数据采用synchronized 同步: ConcurrentLinkedQueue 是基于链接节点的.线程安全的队列.并发访问不需要同步.因为它在队列的尾部添加元素并从头部删除它们,所以只要不需要知道队列的

C#写文本日志帮助类(支持多线程)

using System;using System.Configuration;using System.IO;using System.Threading; namespace FQDService.Utils{ /// <summary> /// 写日志类 /// </summary> public class FileLogger { #region 字段 public static readonly object _lock = new object(); #endregi

C#写文本日志帮助类

代码: using System; using System.Configuration; using System.IO; using System.Threading; namespace FQDService.Utils { /// <summary> /// 写日志类 /// </summary> public class FileLogger { #region 字段 public static readonly object _lock = new object();

glog另启动线程写文本日志

glog本身是非常高效的,google的大牛肯定知道大规模的写日志用glog的话肯定会影响业务线程的处理,带负荷的磁盘IO谁都桑不起.比如levelDB就是默认异步写,更不用说google的三驾马车都是分布式的.之前看过其论文,简直是引领时代. 在glog的issue里有人提出了异步写的问题,但是语焉不详,不过0.33版本已经有了接口,但是还不友好,但是完全可以实现磁盘日志的异步写. 今天算是花了点时间踩了点坑,算是基本可以搞了.稳定之后会把这个版本和glog,g2log,mudo loggin