业务应用系统都有大量的打印需求，包括交接用的单据，内部使用的作业单，各类报表。Web报表从来都不是一项轻松的活，有时可能会要求更高。就我本身的经验来看，做报表是一件体力活，吃力不讨好。然而，在掌握了一些技巧之后，报表就会变成纯粹的技术问题.我只用过JasperReports做web报表，其它的工具还没有深入研究过，所以这里只以此为例。同时也向大家推荐JasperReports--一款强大的web报表打印工具.
首先就是格式的问题，就算我们只有一个客户，格式的变动也足够频繁了。每一个报表从初稿到最后稳定下来，至少要经过三个回合的沟通。虽然前两个回合的工作有一定的意义，但无疑存在一定的浪费。有人 ...
我已经工作了差不多七年，常常会发现自己在过去的职业生涯中规划不足，错失了不少机会。“如果重头再来，一定会做得更好。”这种想法时不时地在敲打着我，我也希望那些刚刚开始工作的同学们能汲取教训，包括工作了好几年的，好好规划自己的职业生涯。
做感兴趣的工作。兴趣是首要条件，可以激发你更多的热情，并长期保持这种热情。如果只是为生存，恐怕很难把工作做好，更不要说再上层楼。
认真负责。我想这一点不需要再多说了，无论对自己还是对别人，认真负责是最基本的要求。没有人喜欢跟不负责的人一起合作，做事不认真只会浪费你和他人更多的时间和精力。
积极主动。这一点的重要性是不言而喻的，积极做好各项工作，并主动承担更 ...
千万不要把今天能做的事留到明天。 —— 本杰明·富兰克林
我们总是习惯于让行动晚于计划，不管是工作还是生活。我们总是有这样或那样的借口，让自己的行动一再的拖延，甚至取消。不到最后关头，不愿意去做。为什么现在就要开始呢，总觉得前面重重困难，再看看吧，也许还有别的办法。实际上恰恰相反，很多事情并没有我们想象得那么困难。一旦开始行动，一切都变得简单起来。
拒绝一切借口。推迟行动的理由往往看起来都那么充分：
条件还不成熟。永远没有万事具备的时候，条件还不成熟通常就是你要立刻开始行动标志。比别人先走一步比什么都重要，行进中开火，不断调整目标，你会比预想中更早到达目标。而不是干坐着等待，奢望目标会自 ...
每个业务系统都不可避免要涉及到计费需求，如何解决计费问题总是没那么容易。做得少了满足不了用户的基本需求，一些费用登记不了。做得多了变成一个不专业的财务系统，被使用的可能性极小，通常各企业都有自己的财务系统，财务人员不可能再到业务系统里去做一遍数据。
最常见的托运单都是把费用填在单据中的，而不是单独计费的。例如，运费、送货费、提货费、保费等，五花八门。而单据的明细条目则通常在三条以内，有些甚至只有一条。而费用则是由各个明细条目一起计算出来的，只有一条当然好算，如果是多条的话，就稍微有点麻烦了。因为有些情况下是按整单计费的，没法精确知道各个条目所分担的运费。或者先是按各条目计费，然后把合计的费用 ...
运输公司常常要求我们的系统能够提供一些实时查询的功能，方便他们跟踪客户的货物。例如，客户的某一票货现在在哪辆车上，车大概到了什么地方，是否可以准时到达。而我们的设计则不能直接发映出这些功能，运输公司跟客户交接用的是托运单，司机则拿的是配载单，上面列有详细的货物信息。我们的方案基本能满足他们的需求，但做起来就发现问题多多。
首先，托运单和配载单是多对多的关系，如果你直接去建立他们之间的关系，无疑会复杂化实现。采取折衷的方案会更好，我们把配载单的明细记录和托运单的明细记录进行关系，形成多对一的关系，间接解决了前在提到的多对多关系。再把每次配载的数量写到托运单明细记录中，记录已经配载了多少数量，而 ...
我曾经参与过几个运输公司系统的项目开发，基本上大同小异。他们的业务模式主要分为两类，一类是做干线运输，只做点到点运输。他们的自有车辆比较少，覆盖面窄。如果客户的业务要求运到他们无法到达地方，直接转包给别的运输公司--他们的二级承运商。这种模式的优点是成本较低，运送到达准时率、货物完好率比较高，同时有时间保障。这类公司通常认为中途的装卸会导致破损率升高，且耽误时间。缺点是车辆满载率无法保证，对车辆的调配要求比较高。同时外包业务也存在一定的风险。
另一类是做干线中转业务，他们的车辆比较多，线路覆盖比较广，基本上不会把业务转包出去。通常他们的车辆都是装有多个城市的货物，在中途也需要卸货/装货。这种 ...
所谓依赖，指代码中的耦合。依赖倒置，是相对于传统的面向过程的设计结构而言，面向对象的结构把依赖关系倒置了。
DIP原则：
高层模块不应该依赖于低层模块，二者都应该依赖于抽象。高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略实现。首先高层模块和低层模块都要抽象出来，高层抽象不依赖于高层和低层模块的具体实现，最多只依赖于低层的抽象。高层的实现独立于低层模块不应该依赖于低层模块，而是依赖于低层抽象。同时，低层的抽象和实现也只依赖于高层的抽象.为什么要依赖于抽象呢？因为抽象/接口都是相对稳定的，不会被频繁改动的，依赖是可以信任的。如果都依赖于具体的实现，想想吧，改动一小块代码是 ...
最近常常会听到有人在讲如何如何研究某某大公司的行政制度，薪酬制度，然后再断章取义，把其中的某一部分照搬过来开始在自己的小企业内部实施。虽然遇到了重重困难，但给别人和自己的理由都是非常冠冕堂皇：某某公司就是这么做的。最后就是画虎不成反像猫，吃力不讨好。
我们也常常会看到大公司的管理层常常在谈如何才能像小公司一样灵活敏捷，好像Welch在他的自传中也提到过这一点。
看到了吗？小公司拼命想学大公司，希望变得更死板僵化。大公司则千方百计地希望能变得更灵活小巧，迅速做出反应。
这很有趣，不是吗？
Salesforce是一家提供SaaS服务的企业，大概有十年历史。他已经与Google开展了深度合作，同时向他们的客户出售Google Docs服务，当然是集成在他们的系统中使用。现在就有可能存在双方之间的交易--Google会收购Salesforce。
一方面，Google希望把他们的应用出售给一些企业客户，另一方面，salesforce也已经使用了大约41000个Google的应用。如果交易成功，对双方都是有利的。
关于领导的概念理解有许多不同的解释，这里我要谈的是技术领导。
技术领导的概念不同于管理，通常我们所说的领导就是指管理一组人来完成一项任务，而实际上技术领导是营造一种使他人可以更富有成效，更有效率工作的环境(出自Weinberg)。并不是只有管理者才可以领导，事实上每个人都有领导的才能并发挥着领导的作用。
首先，帮助他人就是帮助自己。对于一个团队中个体来讲，你只有更好的帮助别人完成工作，才会使自己的工作的价值最大化。如果整个团队失败了，个体的任务程度的成功都会变得没有意义。这样的例子我们常常会看到，拥有明星级的开发人员，却开发不出明星级的产品。不只是项目经理要认识到这一点，团队中的每个人都要 ...
samuelray
- 浏览: 48012 次
- 性别:
- 来自: 深圳
- 详细资料
搜索本博客
最新评论
-
规划职业生涯
beyondqinghua 写道哪个人不想好好的静下心踏踏实实的学习,但是经常生 ...
-- by samuelray -
规划职业生涯
踏实、兴趣、激情、健康；宽容、沟通！与君共勉！
-- by shaquan6776 -
规划职业生涯
不错,支持一下!
-- by intfloat -
规划职业生涯
共勉～
-- by justin8335 -
规划职业生涯
哪个人不想好好的静下心踏踏实实的学习,但是经常生活的压力总是让你更加浮躁啊!
-- by beyondqinghua
评论排行榜