My first Drupal module is complete! The Asymptote Filter is in it's dev stage, but it's perfectly usable for Drupal 5. It read everything between the <asy> tags and use Asymptote to convert it into eps and then ghostscript convert it into png. Don't use it on production server, the most important of the module, the security filter, does not exist.
I wrote it so I don't have to write a extension for DruTex. DruTex is powerful, and the trade off the the complexity of the code. To port DruTex to Drupal 6 or create new features are really difficult task. So I chose to write my own(both Drupal 5 and 6 version), and scatter them into single modules(for now, Asymptote only) so people can activate or remove. In the future, I will also create plugin for FlexiFilter, but for performance sake, a hard coded module is faster than a module interpreted by FlexiFilter.
I still recommend DruTex, some of the features I will never intend to create for my filters. LaTeX2HTML, HTML2LaTeX and remotely render LaTeX does not fit my need. 
Download and try it out :)
In this informational world, it becomes more and more difficult to classify data, till now, many ways have been suggested, each one of them have some flaws.
Trees
Tree is a classic taxonomy system. It's widely used in classifying living organisms, file systems and most paper's organizations. Each parent term can have a few or no child terms. Each child term can have only one direct parent term.
Pros
1. easy to navigate
2. easy to manage
Problems
The importance of each term can be understand differently. For example, should equilateral triangle be equilateral polygon->triangle or should it be triangle->equilateral.
Easy navigation require some amount of knowledge about how item are categorized.
Multiple inheritance
It's the same as the tree system, but each term can have more than one direct parent term. The equilateral triangle can be classified as the child term of equilateral polygon and triangle.
Pros
1. easy to navigate
2. easy to manage, more difficult than tree
Problems
Since equilateral triangle is belongs to both equilateral polygon and triangle, and they are both belong to polygon. Should equilateral polygon and triangle classified as the same kind of item? It's sure that triangle, pentagon and hexagon are more related than equilateral polygon's relationship to triangle. Should a new parent created just to differ these two apart? Like "relative length of the polygon side" and "amount of sides".
Naive Tagging
Pros
1. Easy to tag
2. Easy to navigate when there is a smart system
3. Social tagging power
Problems
No sense of parent and child. So someone can tag equilateral triangle "math", "geometry" and "polygon". But we know polygon is part of geometry, which is part of math. but if someone searches "math" and it only got tagged by "geometry", it will not show up. To make an item fully accessible, an item have to be tagged with a tag and all it's parent tags.
Few word can have the same meaning. Different user would tag it differently and result search for one, the other don't show up. For example "Triangle" and "Polygon with 3 sides" are the identical tag by the definition of triangle, but they are different tags.
A word can mean different things. Like "Python" can mean a programming language or a special group of snakes. Search python as the language, turns out a lot of snakes are not intended.
Finally, after Drupal's Taxonomy system come out, I saw the best categorizing system, yet.
Tagging with multiple inheritance and synonym support + more than one vocabularies
The most powerful taxonomy system Drupal can offer is Tagging with multiple inheritance synonym support. And as a extra, "related tags" field. It's not formal to use related tags, because there is no standard to define what the relation is between the tags and how to act for different relations.
Vocabularies are complete different set of term, they have have no relationship with another set of vocabularies. So they can have the same term("python") but they are used differently(Vocabulary of programming and vocabulary of snakes). Basically, it's the same as categorizing one set of terms into one single parent, except they are defined not to have any relation with another set of terms.
Pros
1. Really powerful at classifying data
Problems
Beside the huge difficulty of constant adding synonyms for a tag, format all the possible inheritance, and a lot of database queries. This system still can't fix the multi meaning word problem, but if the taxonomy managers are careful, it will not happen. The basic rule: Never let a term be ambiguous. For example, instead of using "Python" for both the snake and programming language, do "Python(Programming Language)" and "Python(snake)". This problem does not exist in tree based system. If anyone can think of a better suggestion, please let me know :)
Also, a few category problem seems impossible unless one knows how to perfectly define vocabularies. For a personal example, let's say there is are two vocabularies, time and space. An item appeared in China at 2001, and also appeared in US at 2003. So this item will be tagged:
Space: US, China
Time: 2001, 2003
but, the space are not directly associated with the time, one with no knowledge about the item can inferred the item also appeared in China at 2003, a wrong statement. When I was the Space and Time vocabularies, I found it makes perfect sense, user can browse by time or by space. until I finally meet a problem like this and have to consider redefine the vocabularies. The only solution requires the removal of combine 2 vocabularies. Create terms like "China 2001" inherit from "2001" and "China". If we think about it. For many cases, there can be only 1 term directly inherits 2 term, those times I like to think it as a synonym of 2 term combined. The disadvantage will be a huge amount of database usage, say, there are 200+ countries and human have recorded history for more than 5000 years. If the original database contain like 5000 terms now, it should be over million terms.
Future...
I want to hear suggestions on how these problems can be solved. because I have no idea.
Before I work with Drupal, I use Wordpress for all my site. Wordpress is in fact a nice popular script made for personal blogs Drupal's motto is more about the community. What would be the reason using Drupal for personal sites? For me, it's because the taxonomy system in the core relates to the perfect classification system of information. For everyone else, Drupal have high extendibility to match all the needs if you ever want to transform your personal little site into a community (because your band(or drunk) video have over 1 million views on youtube).
To set up a personal site with Drupal, you have to download Drupal, install it, and then add these modules:
Pathauto
Token
Smileys
CCK
Views
Gallery
This article are intended for readers who knows how to:
1. Install Drupal
2. Install Modules and activates them
3. Access the admin panel
If you don't understand 1-3, check the handbook. If the admin panel is too confusing, add the Drupal Administration Menu module
1. The Foundation
After you have created a admin account. Start change the basic information of your site destination (Administer > Site Information)
Activate all the third party modules mentioned in the start and core modules include Blog, Blog API, Path, Ping, Profile, Contact and Upload. destination (Administer > Site building > Modules)
Create a free tagging vocabulary that work on each one of the the contents
destination (Administer > Content management > Categories > Add vocabulary)
2. The about page
Almost every site in the world have a about page. For a personal site, maybe write something about about who you are (Facebook widgets), your interests(Twitter and Delicious) and your debts(NetworthIQ stats).
Drupal came with the content type "Page". destination (Create content > Page)
It's like writing a post for all kind of Drupal pages, it's best to select it as Full HTML.
3. The blog
Drupal have a built in module for blogging. destination (Create content > Blog).
Nice paths
The blog module is simple, it don't even have a neat a URL like http://yoursite.com/2007/12/08/blog-entry-title. The path module is required for nice URLs.
By activating the path module, a new field gets activated, the URL path settings.
If you are a casual blogger, write it yourself isn't a big deal. But if you are lazy or blogging intensively, the pathauto module you activated can do the dirty work for you.
Go to the main configuration to pathauto. destination (Administer > Site configuration > Pathauto)
Nothing much need to be changed, except the Node Path Settings. For blogs, it's best to have url in the yyyy/mm/dd/title format. For pages, just a title is enough.
Submit and it's done. After that, any post created will automatically follows the convention setting in the pathauto module.
Smileys please
You have already activated the smileys module, why isn't there any smiley selection box when you are writing a post? To show smileys box, you have to set it manually.
destination (Administer > Site configuration > Smileys > Settings)
Enable showing smileys box on both nodes and comments
3. Reviews on books/CDs/sites
There are two options to do reviews. Using the book review module, or CCK + Views. Using the previous one can not show the real power of Drupal + CCK + Views. Using CCK + Views can do more than just reviews, other contents are possible.
Create a new content, reviews
First, create a new content type, "reviews". destination (Administer>Content management>Content types>Add content type)
Then, edit the reviews content type, one of the new options from CCK will come up, add field.
Chose add field. Add a new field called ratings, then chose it as text/selected list and create field.
After that, go to the bottom of the page and find allowed text, add some possible values for ratings and submit
Now, a new field will appear in the review content type, and will allow selection of the rating.
View all the reviews
How can reviews get presented? Like all the reviews posted on the website.
Views module is exactly the one to use. destination (Site Building > Views > Add)
Give the view a name
Provide a page view and set the url to access the view. view type is a full node, set the title to anything you want.
Go to filters and set which node will be filtered out and presented to the reader. In this case select Node: Published, Node: Distinct and Node Type as reviews.
Create a sorting criteria, sorting by time posted is reasonable.
Save and create a link to the reviews in the menu. destination (Site Building -> Menus -> Add Menu item)
The reviews are successfully integrated into the site! It can be accessed directly though the menu.
4. Gallery
A personal gallery that show your looks, can be created with CCK and views. But this section will introduce the alternative, the Gallery module, it acts as a bridge, connect Drupal with Gallery, a professional PHP gallery system. For the CCK version, please read the how to page in the handbook.
First of all, install Gallery according to the steps on it's wiki. Install it in a new directory, call it"gallery2" and put it in the Drupal root directory. Remember to activate the image block module for Gallery.
destination (Administer > Site configuration > Gallery settings)
Usually, gallery can configure it self, but in case it doesn't, it will show you all the errors and ways to fix it.
The really nice thing about gallery module is most configuration are already done, include the menu, navigation and such. Only the blocks need to be considered now.
Go to the block configuration page, activate. Gallery Image Block, and Gallery Navigation.
Time to add some photos into the gallery. A link to gallery suppose to be in the menu. When there is no photos, there is a huge link saying "add photos".
adding photos is easy, just go with the instructions
After uploading it, a page will show up with the link to the new photos
Result looks nice :)
5. Contact form
You might have(or more likely haven't) left your contact information in the about page, but there are lazy people who doesn't want to touch the email clients. Built a contact form saves some potential friends :)
destination (Administer > Site building > Contact form > Add category)
Follow the instructions, image below shows a good example
Go to the list of the menus and activate the contact form
The contact form now can be accessed in the menu.
I'm participating in The Google Highly Open Participation Contest, I will work on Drupal because I'm one of it's users and it be nice if I can understand it's internal and work on it. Amazing for college essay xD.
This is a draft for my first task, Research Microformats and recommend ways they could be used in Drupal.
Microformats are a format based on the common XHTML. There are a few popular Microformats recommendation (I refuse to call it a standard) specifications, most notable are hCard, XFN, hCalendar and XOXO.
XFN are the most likely to be useful to Drupal(and the entire internet). Out going links are unavoidable part of every site, XFN is made to show the human to human relationship instead of content to content relationship of the out going link by adding rel="tag1 tag2 ... tagn".
I don't know if XFN can be extended, the background for XFN suggest there are a standard set of XFN rel tags [Friend, Acquaintance, Contact, Met, Co-worker, Colleague, Co-resident, Neighbor, Child, Parent, Sibling, Spouse, Kin, Muse, Crush, Date, Sweetheart, Me].
XFN is already used by Wordpress in it's blogroll, I believe it can also be used in the same way in Drupal for these few reasons:
1. In the future, search engines might recognize XFN and map out the relationship between 2 links. Thus construct a social map of related people's sites.
2. Superfluous introduction of links to the reader. For example
<a href="http://kuzew.net:81">My colleague and friend Kuzew's site</a>
can be changed to
<a href="http://kuzew.net:81" rel="friend met colleague co-resident">kuzew's site</a>
any small javascript pop up can show up the information in the rel tag when mouse over.
3. A possibility of a module that aggregate all the links posted on the site and use the XFN information for easy browsing.
4. Map out each user's relationship
Outgoing links: XFN does not need to be implemented in the core because there is no core module used for creating out going links; however, it's nice to use it for modules like Links or CCK. XFN can construct it's own taxonomy group, where each one of the possible descriptions are tags.
There are suggestions to implement XFN in the core. Users can tag other users with their relationship. It's really complicated. Different user have different relationship to the same person. XFN did not say it should be in one domain to refer to another, but one node refer to another, but search engines are stupid and get confused easily, it's likely the search engine assumes a site is owned by one person, and 2 user pages link to each other does not make sense to the bots [opinion, might not be true, but this did confused me and I believe I'm smarter than bots.]. Even if the search engines are smart, mapping out the relationship between users are costly, a new table have to be provided to do the relationship linking. I don't believe most Drupal users need a social map and genealogy, that feature is best used as a contribute module.
hCard is a microformats used to show profile of a person or a object.
1. hCard can be a extended part of each user's profile.
2. hCard as part of the site information
A uber basic hCard
<div id="hcard-Chao-Xu" class="vcard"> <span class="fn">Chao Xu</span> <div class="org">Mgccl's Blog</div> <div class="adr"> <div class="street-address">123 fake street</div> </div> </div>
hCard is contained inside a div, The div id starts with "hcard", follows by the full name of the user, use hyphens instead of space. The id is not required. the class for the DIV is vcard, it shows this is a hCard that follows the vCard, it's required so parsers understand this as a hCard.
Each node's in the hCard indicates what type of information it contains. for example, fn contain the full name.
Visit the wiki to see the full specification for hCard
The site information can be directly built into the core, adding a few more field to the original site information page and tweak the output.
The user hCard should be a extension to the profile module, create fields(first name, last name, etc) for profile module. Then it will render the hCards inside the user profile pages. Since it creates field inside the profile module, the information on the hCard can be searched though the site.
XOXO is a outline format(not hugs and kisses), intended for describe each node of a list and allow easy rendering. The extension of the outline are done by embed definition list inside each list item.
0. Lists are more meaningful and easily aggregated in the future.
1. Book module's Outline
2. Outline of the taxonomy
Books module's book outline and the chapter outline can be done with XOXO. Description, url and title are 3 of the properties useful for the outline. just adding the following for each node in the list is enough
List of the taxonomy can be another application of XOXO, description of each category or tag can be embedded with XOXO. Best implemented in the core
There are no other places in the core requires XOXO, users might write posts embed XOXO, but like all other XHTML, user should not depend on core Drupal providing tools for posting, but rather write himself, use a WYSIWYG editor support microformats, or get a contributed filter with this supported.
The family of rel attributes act as a simple description for links. The most famous one would be rel-nofollow, telling the search engine not to give the link any credit when ranking websites. rel-tag show the link as a tag, it has already implemented in Drupal 6. rel-license describe links connect to a license page.
1. rel-nofollow can fight spammers
2. rel-license provide information for bots
rel-nofollow should be part of the core for the comment module. and add a setting for global allow or disallow. Should be easy to add a rel="nofollow" condition(I assume... I don't know what handles external URLs...)
rel-license is not much useful for the core because most sites only link one license at the bottom of the page. but it should be implemented in the CCK, in case anyone uses CCK to create a download site, then each page can have a license field.
XFN, rel-nofollow, rel-license and rel-tag all embed themselves inside the rel attribute.
rel is a attribute for a collection of relationships of the linked document to the current one. They all describe the link in some way, XFN is different from the other ones. It describes the relationships between the owners of the documents instead of the document itself.
hCalendar is a format to explain a event in time.
Serve as a input/output format for event and calendar CCK, some softwares can interpret them.
<div class="vevent" id="hcalendar-Owning-noobs"> <a class="url" href="http://mgccl.com"> <abbr class="dtstart" title="2007-12-05">December 5th</abbr>, <abbr class="dtend" title="2007-12-06"> 2007</abbr> <span class="summary">Owning noobs</span>— at <span class="location">Long Island</span> </a> <div class="description">describe the event</div> <div class="tags">Tags: <a href="http://eventful.com/events/tags/PWNING">PWNING</a> <a href="http://eventful.com/events/tags/NOOB">NOOB</a> </div> </div>
The div class "vevent" defines this block uses hCalendar.
Like hCard, every container for the information are declared by it;s class attribute. All class attributes are obvious what it means. For the nodes contain time, the title attribute contains the ISO8601 time format. It's much easier for computer to read than "October 13th".
Clearly, it should work with Event module. Event module will add a page to import hCalendar into database, it can be separate and not depend on any Drupal scripts. Event's output on pages should also be hCalendar, that's all the changes the module should endure. The output are XHTML for each individual event page. Create a template and replace some variable would do.
Calender CCK could do the same.
Microformats parser could help with the parsing.
Some other microformats are in draft stage, it's not recommend for Drupal. hAtom is worth a mention, hAtom embed itself on normal XHTML, enables syndication. Personally I don't like that idea, it's better to create a separate Atom, saves bandwidth.
rel is not important enough for dedicated parameter in l(). l() are for internal links, the only internal link I found would use rel is the rel-tags. l() uses drupal_attributes() to add the attributes, adding a rel flag would be over kill.
The autosave module creates loads of node revisions and soon it would take up a whole lot of space if no one is manually deleting them.
A nice snippet here to help delete all revisions~ 
[yet]
Recent comments
11 hours 52 min ago
1 day 1 hour ago
1 day 1 hour ago
1 day 9 hours ago
1 day 16 hours ago
2 days 14 hours ago
3 days 1 hour ago
1 week 10 hours ago
1 week 4 days ago
1 week 5 days ago