Skip to main content

Posts

UI设计那些事

自从开始工作起,就不断听到身边的同事谈论UI设计的问题,林林总总,各种论调. 大家之所以热衷于谈论这个话题,根本原因在于UI设计本身是一件和用户交互的活动,从满意性质量角度考虑,它的设计就不存到唯一的答案,因此这里没有最好,只有更好.不同的用户,不同的行为方法,不同的思考方法都将决定不同的UI设计. 我一直没有过多思考什么是好的UI设计,毕竟做了这么长时间的数据库后台工作.长期的后台设计经历让我养成了寻求简单,直击根本的习惯,所以我认为的UI设计应当是简约,直接,能够实现展示价值.从我的第一个项目,我就这么认为,然而,这样的认识确实还经历了一个过程. 最初,为某电信国企做项目,web页面的设计只能用'粗糙'来形容,没有内容组织,没有风格要求,没有可用性可言,总之只要能够展示数据,一切都好谈.而在验收标准上,毅然用'用户web界面要友好'等字眼描述,这样的项目做到最后往往是扯皮.推动验收的往往是能侃的销售经理,常见他们很自信的告诉用户这就是'友好的web设计'. 随后几年的项目,web UI的设计趋于累积内容信息,当时的UI设计师只是在调整色彩,页面结构,并没有组织起内容,以至于一个web页面充满大量的文字,不相关的信息被罗列成章.这样的设计迎合了一大部分国企领导的好评,因为看起来专业,但是实际情况是,没有多少用户真的关注这些信息. 这些年的所见所闻,让我逐渐的又回到的最初的认识.正所谓的返璞归真.专业的UI设计更加注重的用户的体验,而非一时的效仿,简约并非意味着简单,专业UI设计的每一步骤都包含着众多的思考,UI设计并非是信息的堆积,而是正确的组织.从一个用户角度讲, 评价UI好坏的标准在于能够快速的定位到有价值的信息,信息量大了不好,小了也不好.这里至少要考虑几个方面的因素: 1.被关注的信息 2.信息的相关性 3.信息的组织 本着这样的原则去审视一些网站,都会找到不少让人不爽的设计.但同时,你也会发现,这些年不少网站也在不断优化UI,使之更贴近用户,比如淘宝,至少长期不用,你至于被UI给搞糊涂.
Post a Comment
Read more
Recent posts

business intelligence 2.0

 After long term of development, Business intelligence was moving into a new stage. that’s so-called BI2.0. The new term was introduced by BO corporation and trying to influence industry in an unnatural way. After I studied the whole concept, I came up into these meaningful points, Clearly, I got rid of some tedious and unrealistic content pushed by vendors. 1.What’s business intelligence 2.0? Business intelligence 2.0 is a term most likely named after web 2.0. Based on the BI of the first generation, BI2.0 provide more experience to meet user's requirements in a larger scope, like more easy-use UI, platformlise, .etc. 2. The new characters of BI 2.0 1. it enable user to query dynamically real time data 2. more web and browser-based approached to business data. 3.imply a trend towards moving away from the standard data warehouse that business intelligence tools has used,applying a new way to relate information quickly from many sources. 3. Why BI.20? Will we continue to follow a ne...
Post a Comment
Read more

通过sqlplus来查询系统cpu时间

oracle惯用的V$OSSTAT性能视图可以随时监控系统中的资源消耗，这其中包括系统cpu的使用率。 通常我们使用sar来完成这个工作，如果通过sqlplus来实现，可以编制一套package完成一体化监控分析目的。当然，对于监控还有很多中手段，区别在于复杂度和准确，即时性。每个人都可以选择不同方式实现，我个人认为使用自己最熟悉的方式最为妥当，这样可以避免无需的学习成本。 以下是监控脚本内容：   CREATE OR REPLACE TYPE osstat_record IS OBJECT (   date_time TIMESTAMP,   idle_time NUMBER,   user_time NUMBER,   sys_time NUMBER,   iowait_time NUMBER,   nice_time NUMBER ); / CREATE OR REPLACE TYPE osstat_table AS TABLE OF osstat_record; / CREATE OR REPLACE FUNCTION osstat(p_interval IN NUMBER, p_count IN NUMBER)    RETURN osstat_table    PIPELINED IS   l_t1 osstat_record;   l_t2 osstat_record;   l_out osstat_record;   l_num_cpus NUMBER;   l_total NUMBER; BEGIN   l_t1 := osstat_record(NULL, NULL, NULL, NULL, NULL, NULL);   l_t2 := osstat_record(NULL, NULL, NULL, NULL, NULL, NULL);      SELECT value    INTO l_num_cpus   FROM v$osstat    WHERE stat_name = 'NUM_CPUS';      FOR i IN 1..p_count   LOOP     SELECT sum(decode(stat_name,'IDLE_TIME', value, NULL)) as idle_time,  ...
Post a Comment
Read more

oracle终于买下了sun

oracle终于买下了sun oracle 以74亿美元买了sun，而IBM最终错过了他的购买机会。 oracle买下sun是业界的大事，也对数据库领域起到了举足轻重的影响。我想对于oracle本身而言，正如larry Ellison所讲，oracle得到了sun的solaris 和java，将更加助力oracle成为贯穿前后台的，从底层到应用的系统集成商。可以预见不久，oracle吸纳了sun在硬件和软件上的优势，特别是mysql的优势,更加巩固oracle在数据库领域的霸主地位。 不知道Microsoft在想什么？oracle一直以来都有和ms争霸的决心和勇气，这几年的势头也处处证明了这一点。记得当初Ellison就公开坦言他比较妒忌盖茨，如今在数据信息领域，oracle已经达到了无法撼动的地位。似乎ellisson的愿望更近了一步。 有些地方还是值得关注和猜测的 1. 不久前，oracle联合HP发布的oracle exadata 和HP oracle database machine 计划。在sun的技术被购入之后，oracle会不会还一如既往的推动。希望不要成为鸡肋。 2.oracle无疑站在数据库领域的无法撼动的霸主地位，这包括开源和商业。那末mysql将来的命运如何？一方面mysql影响力极大，另一方面，照ellison的一贯手法，收购＝毁灭，mysql是否也要步以前foxpro,dbase的后尘？只能用时间来验证. 3.oracle一旦完成了收购，IT格局将大有变化。将来我们一打开电脑，就是ms，看到数据没准就是oracle。 oracle成功之后，他的下一个目标会是谁？兴许oracle也有被反垄断法告的那一天。在此环境下，ms的应对策略如何？真希望有一天，ms也迫于竞争，忙于把sql server一直到solaris的上，呵呵。
Post a Comment
Read more

绿色计算

绿色计算 所谓绿色计算，当然是和环保连系在一起的。云计算被赋予绿色计算的头衔，其原由很容易被推理:大量的主机被集中化管理，人们只要向服务提供商买服务就可以了。被集中管理的主机有利于从整体上思考环保策略，如将计算中心移到离电厂近的地方，使用管理策略减少能源消耗，等等。总之被可运作的概念和理由很多。但是我还是质疑现实情况。 我们可以类比北京的冬日取暖，究竟是集中供暖更环保还是单户的天然气独立取暖更绿色？众说纷纭，莫衷一是。 支持集中供暖的人会讲：统一管理煤炭，集中燃烧，降低了污染，有利充分利用能源达到环保。 支持单户取暖的人会说：单户方式能够根据用户意愿决定是否使用，更agile，更有利于节约能源，更绿色。 究竟谁对？当然应当看实际数据，但这年头谁又能拿到靠普的数据。本人家里采用单户取暖，冬天取暖炉根本没用过，因为房子的保温效果不错，所以没必要。论其环保，我自然支持单户方式。 现在再回到绿色计算上来，所谓的计算中心，选择降低能源消耗策略应当是顺理成章的事，也符合商家的经济利益。但综合整个社会成本，绿色不绿色就很难讲了，比如，无论运转效果如何，你都需要一个固定的能源消耗，你还需要更多的配套设施，等。总之，这年头绿色就是炒作的话题，最终目的是推广自己的概念和产品。 环保是每个人应该做的，因为大家都住在一个地球上。你怎末推广自己的产品，只要合法，也没人干涉。不过在拿环保说事的同时，要衡量清楚自己有没有真的做到。
Post a Comment
Read more

云计算

云计算是一个新潮而且听起来很牛的名词，今天探其根源，俺还是有点体会。 云计算可以说是分布式计算，网格计算的近亲，或者干脆点，就是它们的衍生品。这里的概念模糊不清，关系也并不明确。总之，不同机构有不同解释。 讲讲我的经历。记得最早接触分布式计算是在第一份工作，一个关于电信计费的大型项目。谈到计费就往往少不了数据的问题，比如如何接入通信网络，如何收集数据，也就是ETL。由于数据量庞大，这里ETL暴露出几个问题： 1.如何保证扩展性？ 2.如何保证24×7？ 3.如何保证处理效率？ 4.灾难发生，如何补偿？ 回想起那个时候的技术架构，简直就是糟糕到底。一群学院派的老前辈用OLTP方式处理这些数据ETL的问题，数据处理全部集中到数据库，其后果也是恐怖到底。好了，几个月后，数据库就是永远的瓶颈。 现在看来，ETL是最适合分布式计算的应用场景。原因： 1.被处理数据无需考虑状态。可以很随意拆分处理。 2.ETL处理的数据量往往很大，需首要考虑性能问题。分布式可以更好的提高效率。 3.既然有分布式的结构存在，自然扩展性和可靠性就很高。 当时自己也在实践中看到了这一点，所以写了一个很小的通信模块用来实现扩展性。原理很简单，只要这个程序运行，一旦它接收到控制信号，就取出一部分原始数据，执行设定的业务逻辑代码。记得当时写了两个版本，一个用UNIX C,一个用delphi。以后逐渐地把原来放在数据库中的处理，如数据清洗， 移到这些分布模块去做。很大程度上减少了数据库压力，而且效率和扩展性上有了很好的提升，架构也清晰多了。后来又完成了一个程序，起了个名字叫控制面板，就是用来监控各个分布程序的状态。基本上，这样的系统就成了分布式的并发处理系统，尽管很多其它的问题还没有考虑。 以后，偶然机会看到了一个开源项目，叫巡天望远镜计划（ http://lsstcorp.org/ ），关注了一段时间。发现其IT系统的一个模块，用来收集来自射电望远镜的数据，处理方式也是采用分布式并行处理方式，架构与我曾思考的类似。但这样的科研项目面临的挑战就大多了，其一是数据量大，50G/天。其二是，你如何找到足够的机器去完成分布运算环境。靠网友的捐助是比较好的方法，比如贡献你的机器，让它在晚上加入运算网络。当募捐到足够的机器时，一个庞大的计算网格形成了。 当回来商业环境中，我们发现类似的分布式系统还有很多，但总不能都让...
Post a Comment
Read more

Pessimistic Locking & Optimistic Locking

转载的 锁（   locking   ）   业务逻辑的实现过程中，往往需要保证数据访问的排他性。如在金融系统的日终结算   处理中，我们希望针对某个   cut-off   时间点的数据进行处理，而不希望在结算进行过程中   （可能是几秒种，也可能是几个小时），数据再发生变化。此时，我们就需要通过一些机   制来保证这些数据在某个操作过程中不会被外界修改，这样的机制，在这里，也就是所谓   的   “   锁   ”   ，即给我们选定的目标数据上锁，使其无法被其他程序修改。   Hibernate   支持两种锁机制：即通常所说的   “   悲观锁（   Pessimistic Locking   ）   ” 和   “   乐观锁（   Optimistic Locking   ）   ”   。   悲观锁（   Pessimistic Locking   ）   悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自   外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定   状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能   真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系   统不会修改数据）。   一个典型的倚赖数据库的悲观锁调用：   select * from account where name=”Erica” for update 这条   sql  语句锁定了   account  表中所有符合检索条件（   name=”Erica”   ）的记录。   本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。   Hibernate   的悲观锁，也是基于数据库的锁机制实现。   下面的代码实现了对查询记录的加锁：   String hqlStr = "from TUser as user where user.name='Erica'"; Query query = session.createQuery(hqlStr); query.setLockMode("user",LockMode.UPGRADE); //   加锁   List userLis...
Post a Comment
Read more