blog.MagicLab.cn

奶牛“蕊蕊”，流浪猫一枚，前几天从小猫论坛上领养回来的，嘎嘎。

很乖很老实的猫，缠人，从不挠人咬人，给他洗澡也就象征性的挣扎几下，哈哈，真是越来越喜欢了。O(∩_∩)O~

露一小脸

昨天刚到货的自动供水喂食器和全封闭猫厕所，现在的人啊，真是越来越聪明了

这是刚洗完澡，哈哈

最近的工作心态，很疲惫。

角色的转换让我接触到以前没有参与过的工作，但是过于繁多的管理方面的工作，带来的是迷茫，是项目的滞后，我希望不是我的原因造成，领导也说过，去年这个团队比现在要乱的多，但我没办法觉得自己没有责任。我也试图去寻找解决办法，但是却感到这么多的问题，不是我所能够解决的，我不喜欢坐以待毙，更不喜欢在这种没有成就感的项目里煎熬，于是，又是那种感觉，那种不好的感觉又来了，我想要逃避，想跳槽。

以前就听说过这种事情，中国的程序员一旦参与管理的工作，就没办法静下心写程序的。当然，这句话是用来讽刺中国的某些不好的现象的，我以前一直认为，如果是我，将不会这样，但是现在，真正充当起这个角色的时候，确实发现了很多问题。

越来越多繁杂的琐事，严重干扰程序的开发，一个功能模块开发了一半，往往有些事情插进来，等这些事情解决完，还要重新花时间整理思绪，往往好不容易接上趟了，又来一破事，这种现象我已经注意到两个星期了，因为这两个星期我开发的进度非常非常缓慢，甚至止步不前。

还有很多事情，让我看来觉得不可思议的事情不停在发生，项目多人手少是最严重的问题，严重到往往一个项目只能安排一个程序员在开发，但是这些项目的规模在我看来，起码要3，4个人才行；人不够也没名额招人；好不容易招人进来了连个工位都没有，2个人的工位挤三个，再有人过来讨论个问题，人口密度大得让人缺氧；公司的空调也跑来做对，小小的风跟没开似地，tnnd，真是更让人烦躁！而且，通通的问题都没有解决的办法，没有解决的时间，统一的原因都是：上层领导不给批。。。。。。虽然这些都是小事，都是细节，但是，细节决定成败！

于是，我反思自己，是不是有能力在这个时间就转换角色，还是兴趣使然，以至于决定我压根不就喜欢这方面的工作，或者说目前还不喜欢，或者的或者，是不是这家公司的性质决定了我这种性格的人就没办法生存呢？我想了很久，还没一个确定的答案，加上手头教育报的项目很紧，也没有充足的时间去考虑。最近的心态也有这方面的原因，想来想去的让我觉得很疲惫。

总之，我越来越觉得自己无法胜任这个角色的工作了，我甚至有点害怕去公司上班。。。怎么会这样，苦笑。。。可是没有别的办法，咬牙坚持完手头还做开发的这个项目，要彻底整理下头绪，再做打算吧。

上周六，顶着38度的高温来了趟温榆河休闲骑，其实本来打算去香山的，根据天气状况改了路线，就这还把我胳膊晒伤了，好在不是很严重。

路线图：

全程40多公里吧，距离上来说很近，不过因为天气太热，体力消耗非常快，骑回家时也有些精疲力尽的感觉。不过温榆河的空气真是太tm好了，那里有个高尔夫球场，方圆几里内全是清新的草地的味道，真是北京近郊的一个小世外桃源啊，以后没事就可以去那边溜两圈，换换在市区吸进肺里污浊的空气。

最后展示下我的“创意”，三水壶架山地车 变身“导弹车”：

最近刚刚迷恋上自行车运动，每天上下班放弃了地铁，改骑行，单程11公里，利用上下班时间就锻炼了身体，不亦乐乎！还加入了个自行车组织，北雁车队，上周六跟组织去了趟密云采摘，因为是一个车友家里开的采摘园，无限吃，无限拿，全程175公里，早上6点半出发，晚上9点半才回到家，累得够呛，不过也很过瘾，废话不说了，直接上高清无码大图：

 嘎嘎，我们很专业吧，还有更专业的，这次活动有三两后援车，下面看看后援车上的视频：

给我的老伙计来张特写，美利达 公爵 500 刚换上把套和后货架：

最近因为工作需要，在研究ucener的SSO机制，很痛苦，代码注释那是相当少啊，看得真纠结，好在略有收获，纠正了我以前的一个错误认识。

SSO，单点登录，其基础就是统一认证，以前总认为要达到统一认证，必然需要统一的用户信息存储，即：单一的用户信息保存地址。可是发现ucenter并不是这样做的，而是在用户信息入库时，保证多个子系统统一入库（ID都必须相同），即：多个用户信息保存地址，认证时，分别认证各自的用户信息数据。

用户在某子系统登录时，请求ucenter，只返回一个用户id，各子系统通过这个用户id，查询自己的数据库，得到用户验证数据。

这种方式是有好处的，保证读写操作的平衡，降低ucenter的负载，减少数据传输负担。

当然，也是有缺陷的，自由度不高，这种机制要求子系统都必须带有用户信息库，假若我开发的某个应用根本不需要注册和登录操作，只想获取用户会话状态，就不能使用这种机制了。

另外，用户id必须相同的限制也很大，比如，我在主系统运行了一段时候以后，想挂载一个已经存在部分用户的子系统，用户数据迁移的工作量也会较大。

继续研究ing。。。。

题目很臭屁吧？哈哈，这个系统的名字更臭屁：“分布式php后台管理系统”。

需求来源于手头的一个项目，开发一个由7，8个子系统子系统组成的一个大系统，无非就是博客、论坛、sns、商城，等等。还需要一个管理中心的东东，把这几个子系统在一个统一的后台进行管理。

灵感来源于ucenter把子系统当成应用的管理方式。于是搞出了这个系统，没啥技术含量，纯属应用级的熟练工作品。

自我感觉实用性还算可以，可以把几个子系统的开发、测试完全分离开，上线前统一整合（非代码级）。

简介

目的：达到“系统”级别的“重用”，比如：我们给“客户甲”开发过“网址大全”系统，给“客户乙”开发过“在线答题”系统，现在有个 新客户“客户丙”要求一套同时包含“网址大全”和“在线答题”的系统，如果按照惯例，大多是进行多个文件或代码的复制粘贴；但是如果使用本系统进行权限整 合，就可以只通过后台简单操作，将这两套系统整合到一个系统中去，从而达到“系统重用”。

优势：一方面节省了代码复制的工作量，最大可能的避免操作中出错，另一方面有利于团队开发中的分工，团队成员在项 目初期可以分别开发自己的子系统，互相之间没有影响，项目后期进行整合操作，成为一个完整的系统。

分布式：这里所谓的分布式，并不是指分布式计算，而是指主权限系统和多个子权限系统可以分别位于多个服务器上，只 要这几台服务器之间可以通过网络交互，即可以进行系统整合操作，这种机制还有利于分散负载。

复杂数据库（待开发）：可以支持不同 数据库的子系统间的整合，目前想法是将权限框架中的权限等公共功能模块的存储方式改为文件存储（such as xml）。

流程和原理

1、申请应用：子系统——>应用管理——>应用申请——>填写相应参数提交——>向主系统发确认请求—— >验证通过——>将子系统中非通用模块（即非权限模块的特殊功能模块）提交给主系统——>主系统将这些模块入自己的模块库保存，同时记 录子系统一些必要参数数据——>子系统加入已经成为应用的标识，该标识在登录文件和判断权限文件中生效，意味着该子系统已经成为应用，必须从主系统 进行登录；同时记录主系统一些必要参数数据——>申请应用完毕！

2、角色权限帐号：角色、权限、帐号的操作从此都在主系统完成，数据也都是入主系统的数据库保存，跟子系统不存在任何关系。

3、登陆：主系统登陆——>帐号验证通过——>主系统域名记录session——>调出已经成 为应用的子系统参数数据，跟据参数生成js代码，在前台显示，这种方式是为了让用户从客户端向子系统发送请求——>js代码请求的均是子系统cgi 文件，这些cgi文件的作用是通过webservice请求主系统的cgi文件，得到用户信息（主要是权限数据），然后写入各自子系统域名session ——>登陆完成！

登陆的结果：主系统和各个子系统域名下均记录了相同的session，包括内容，有效期等等。

4、菜单生成和判断权限：用户进入后台后，看到的主框架和左侧菜单是主系统的，菜单生成方式和单独的权 限关系系统一样，但是右侧的主要页面有可能是通过iframe调用各个子系统的，所以，判断权限部分也是在各个子系统上单独进行的，所以在上一步登陆时， 要在所有成为应用的子系统上同步写session。

5、登出：原理同登陆，分别销毁session。

子系统程序下载

主系统程序下载

人人都要求别人是神，自己是猪
还要求神理解猪，按猪的意思行事

这无疑是个悲剧，“人不是神，也不是猪”，你非要把他当神，他就把你当猪。。。，这实实在在是个悲剧，然而也可能是个喜剧。。。

越把自己当神越容易从高处跌落摔碎

“不相信他是神了，还相信自己是猪”，这实在是一种诡异的智慧。。。也是猪的一种结局

我说的话你不明白，那不是因为你是猪，而是因为你从来不关心自己是不是猪。。。。
我告诉你了秘密，不代表你了解了真相，因为“秘密 ！= 真相”。。。。