之前在博客里贴过无限分类的介绍,那是官方的例子,但上次在给同事们做介绍的时候,却发现官方的网站已经打不开了。所幸,又找到了一篇,好象这个才是原文?
原文来自:http://www.vbmysql.com/articles/database-design/managing-hierarchical-data-in-mysql
为了这次保证所有的数据都能够记录下来而不是再被茫茫的互联网淹没,所以我做了备份。
mysql.7z
但同样的,我也再次复制一部分的内容下来,好象是说这种无限分类的效率,在被其他项目查询的时候是最高的,但CRUD的时候就有点纠结。
OK,上主菜:
The Nested Set Model
What I would like to focus on in this article is a different approach, commonly referred to as the Nested Set Model. In the Nested Set Model, we can look at our hierarchy in a new way, not as nodes and lines, but as nested containers. Try picturing our electronics categories this way:
Notice how our hierarchy is still maintained, as parent categories envelop their children.We represent this form of hierarchy in a table through the use of left and right values to represent the nesting of our nodes:
CREATE TABLE nested_category ( category_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(20) NOT NULL, lft INT NOT NULL, rgt INT NOT NULL ); INSERT INTO nested_category VALUES(1,'ELECTRONICS',1,20),(2,'TELEVISIONS',2,9),(3,'TUBE',3,4), (4,'LCD',5,6),(5,'PLASMA',7,8),(6,'PORTABLE ELECTRONICS',10,19),(7,'MP3 PLAYERS',11,14),(8,'FLASH',12,13), (9,'CD PLAYERS',15,16),(10,'2 WAY RADIOS',17,18); SELECT * FROM nested_category ORDER BY category_id; +-------------+----------------------+-----+-----+ | category_id | name | lft | rgt | +-------------+----------------------+-----+-----+ | 1 | ELECTRONICS | 1 | 20 | | 2 | TELEVISIONS | 2 | 9 | | 3 | TUBE | 3 | 4 | | 4 | LCD | 5 | 6 | | 5 | PLASMA | 7 | 8 | | 6 | PORTABLE ELECTRONICS | 10 | 19 | | 7 | MP3 PLAYERS | 11 | 14 | | 8 | FLASH | 12 | 13 | | 9 | CD PLAYERS | 15 | 16 | | 10 | 2 WAY RADIOS | 17 | 18 | +-------------+----------------------+-----+-----+
We use lft and rgt because left and right are reserved words in MySQL, see http://dev.mysql.com/doc/mysql/en/reserved-words.html for the full list of reserved words.
So how do we determine left and right values? We start numbering at the leftmost side of the outer node and continue to the right:
This design can be applied to a typical tree as well:
When working with a tree, we work from left to right, one layer at a time, descending to each node’s children before assigning a right-hand number and moving on to the right. This approach is called the modified preorder tree traversal algorithm.
因为我已经在压缩包里做了备份,所以我图片就引用外站的了。
看到本文时突然想起以前单位的一位美工,每天都是下午1点上班,晚上9、10点回家,他说这样对他来说效率最好。
由于他的工作和其他人的工作没有过多的配合等,所以领导也就默认了这样的考勤时间,只是从那之后就再也没有看到过类似的情况了。
于是本文就特别让我感慨,原文来自:http://news.csdn.net/a/20110817/303173.html:
八小时工作日,在国内很多IT公司是铁定的工作制度。这一制度是否有利于开发者高效地工作呢?除此之外,灵活的工作制度对开发者工作效率又会有怎样的影响?GitHub工程师Zach Holman针对GitHub的运营管理,写了一篇博文《How GitHub Works: Hours are Bullshit》,文中分享了GitHub的运营管理之道,现把该文进行了编译,译文如下:
俗话说,时间就是金钱,速度越快越好。时间越多越好。
时间就是废话
在很多工业企业中,时间是决定生产效率的一个主要因素,但对于GitHub不是。在一个创业公司中,你不可能在一个问题上投入更多的时间,以期得到彻底解决。代码才是努力的方向。你需要具有正确的思维模式,以便创造出高质量的代码。
回想最近一次令你印象深刻或生气的事。你的工作效率如何?回想一下你最近真正高效的一次经历。代码从指间如飞般产出。当你具有正确的思维模式时,某一天高效的代码编程,可以胜过你一周受挫的编程工作。
我们希望员工尽可能在这一状态下工作。限定员工在办公室中办公的时间会影响他们的工作状态。如果要求我在9点之前必须到达办公室,我是很难保持这种高效状态的,但对于在GitHub的一半员工来说,上午可能是他们工作状态最好的时间。
允许员工更加灵活的工作时间,可以营造一个令员工兴奋的工作环境。在这个环境中,他们可以工作更长的时间,并一直保持高效的工作效率。
一天的工作
在GitHub,每个人的一天的工作时间安排是不同的。同样我的每天也是不同的,下面是一个大概的时间安排:
1.上午十点钟左右起床;
2.坐公共汽车去上班,并在中午或下午一点去吃午饭;
3.从下午一点找个地方工作,下午六点到九点在办公室里工作;
4.之后回家,并在家中沙发上工作或休息到早上两点。有时也会和同事出去吃饭。
有的同事可能在上午7点就来到办公室工作;也有的在下午3点才来。有的同事觉得在家工作比较高效。如果员工不喜欢在办公室工作,他们可以不用每天来公司(虽然大多数情况下,每个人都会来公司)。
我们一天的工作时间为什么如此“松散”,原因有二,一是工作在宽松的环境中,可以使我们在我们喜欢的时间和地方工作;二是我们希望创造一个可以使员工最高效率工作的工作环境。因为每个人高效工作的时间都不相同,所以我们不会强迫任何一个人。
限制性工作
现在GitHub有35名员工,并且还在增长中。这个方法带来了很好的效果。但是管理者仍喜欢固定的工作时间,原因有一:他们有一种错觉,认为时间是衡量员工工作的标准。
如果对工作时间很难把握,你需要寻找其他的衡量方法。他们的代码写得很出色吗?他们把Bug都处理完了吗?他们全身心地投入到工作中了吗?工作上更大的灵活性是否激发了他们工作的积极性?
对此很难做出定性的判断,但是相比起“在工作日的十小时内把这件事做好”,上面这些方法更有价值。因为当你用时间来衡量工作时,他们的工作就会变成更多的时间编写更少的代码。
原文链接:How GitHub Works: Hours are Bullshit
------------------------
如果你是BOSS,你又会怎么样对你的员工呢?即使真的象上文所说的,其实也不一定就好,毕竟如果多人工作内容有交互,怎么更好的合理安排时间才是最痛苦的。
说实话,自从它到了腾讯后变成腾讯的软件后,我一直以为他就那样的死去了。
从很久以前,我就一直在用它,6.0给我带来的惊喜已经逐渐离我远去了。从6.0到6.5,从6.5到7.0,你以为你是玻璃渣?几年才出一个?
不过WEB mail这一块还是有更新的,所以我一直以为6.5不会再出新版了。所以我才觉得那样的意外。。。
http://fox.foxmail.com.cn/index.htm
官方有介绍了,这次的新版的界面超象outlook呀。而且也全面支持Exchange了
主要是由于一些计划任务在用,而且有时候从苹果里发出来的邮件中内嵌图片的,我居然用foxmail收下来是显示不了的。而又占用了空间,TNND,所以暂时我目前已经不在使用了
有兴趣的可以尝试一下下
YII是一个PHP框架。
ZendFramework也是一个PHP框架
在Yii里配置ZF框架,刷刷的就一个RSS阅读器就出来了。
代码很简单,把Zend整合COPY到protected/extensions目录下
在控制器的init方法里加入:
Yii::import("ext.*");
require_once("Zend_Feed_Reader.php");
然后在需要的方法里加入
$feed = Zend_Feed_Reader::import("http://neatstudio.com/rss.php");
这样就创建了一个读的对象了。然后。。。。。
你懂的:
PHP代码
- $data = array(
- 'title' => $feed->getTitle(),
- 'link' => $feed->getLink(),
- 'dateModified' => $feed->getDateModified(),
- 'description' => $feed->getDescription(),
- 'language' => $feed->getLanguage(),
- 'entries' => array(),
- );
-
- foreach ($feed as $entry) {
- $edata = array(
- 'title' => $entry->getTitle(),
- 'description' => $entry->getDescription(),
- 'dateModified' => $entry->getDateModified(),
- 'authors' => $entry->getAuthors(),
- 'link' => $entry->getLink(),
- 'content' => $entry->getContent()
- );
- $data['entries'][] = $edata;
- }
- print_r($data);
就这样,一个刚刚的RSS阅读器就出来了。
当然,它没有缓存,没有这没有那的,不过,都解析完了,剩下的功能还会远吗?
看上这个软件是因为NOOK下面读PDF还是会有点小问题,但EPUB对中文的默认支持又不好,真TMD纠结。
软件还没有试用,不过能够放出来,估计问题不会特别大
PDF to EPUB Converter是一个将PDF转换为EPUB格式的软件,有文本和图片两种转换模式,支持编辑EPUB信息,包括名称、作者、ISBN、发行商、图片 类别与注释等。EPUB是一种电子图书标准,其文字内容可以根据阅读设备的不同而以最佳阅读方式显示,iPad、iPhone、Android等均支持 EPUB图书。
软件有点大,这个链接可以下载:http://www.weste.net/download.php?a_k=XAsPAlIBCxBUXAxCEkMNTRlDHgYDAUoACQ4YAAgJA05UR0FPHVQMQT9HAAtXFURfEEINBgEFV1ZWWwdRUEMPEQgHCQRKCAkAHFBUBEgEAURbCwA%3D
当然,如果不行,你看到这个网址没,点进去搜索一下就OK了。
我只是纯备份,还没有测试(所以也不知道有没有病毒啊)