我的生活有时候很乱

快毕业了，和丫头也快一年了， 好像很快的样子， 工作找到了， 驾照也快考到了， 毕设也快做出来了， 貌似一切都很圆满都很好， 可是我却感觉很累， 可能是身体很久没运动过了， 也可能是生活太单调了， 爱情呢， 好像越来越平淡了， 妞的生日也过得让我觉得很对不住她， 而且平时也让她觉得我不关心她， 而且自己经常精神恍惚， 不能专注精神， 有点累， 一旦我们之间不高兴了， 一定是我又做错了什么， 可是我记得也有很多次你说我对你很好啊， 也有几次说你突然对我这么好干什么， 不适应， 看来我平时是不关心她。 我想关心， 可是我找不到一个出口， 我还停留在那个可以有自己的地盘， 有一个自己的房间的地方来显示我的关心， 走在这个校园， 在这个地方， 我找不到关心的地方， 要不就是我自己的问题， 因为你说过关心人是不用想的， 你爱她自然就会关心他， 我总是抱怨环境， 总是在找借口， 不去面对， 从什么时候开始， 我的生活开始变得这么单调，乏味， 让人厌烦。 最让我感到讨厌的是我们的关系进入一个怪圈， 似乎不在床上， 而且平时总是想起那事， 其实也不多， 但是这正常吗？ 我又在幻想， 我决定了， 给你买个你喜欢的MP3。 然后在我们一年的时候送给你， 可是我在想， 我想买nano可是却给你买了一个低一档次的staffer， 这样不好吧。 可是如果我给你买了nano， 钱就不够再买一个了， 我还是学不会攒钱， 我想浪漫， 可是却让你很疲惫， 听到你说你很烦的时候真想砍掉自己的手， 我喜欢摸你的肚肚就像你喜欢摸你妈妈的肚肚一样， 也许这让你反感了， 对不起， 以后我不了， 你现在在洗澡吧。 你现在一定也在想我们的事情吧， 我不想你选择妥协， 因为那样不是你。 是我的后知后觉后动让你这样了吧，也许我可以躲藏在自己的性格后面说这是性格的原因吧， 但是我想争取， 我想做事利落一点， 不再瞻前顾后， 犹犹豫豫。 这就是为什么把一开始说给自己的话，后来说给你。 这是我这几天全部想的。 我想他们不要扰乱我们， 我想我不再被一些小事困扰（不是说我们的事，我们的事没小事） ， 我不想精神恍惚， 我想干干脆脆， 我想我们开开心心， 甜甜蜜蜜， 我想你

2008年“两会”部分精彩言论摘录

1、全国政协委员、国资委副主任王瑞祥：“对于所谓垄断要科学界定，比如电信行业，固话业务、移动业务都有竞争，怎么能算垄断企业呢？当然不是。”　　　　 2、全国人大代表、北京铁路局常务副局长罗金保：“春运期间铁路一票难求的现象始终得不到缓解，根本原因在于铁路票价太低。”

3、全国人大代表、铁道部副部长陆东福：“铁路部门在雪灾中的表现，至少打90分，不足的10分中，有七八分是失在我们运输能力不足造成的，另外两三分失在抗灾预案的估计不足。”

4、全国政协委员、中国气象局局长郑国光：“春运混乱为什么要气象局道歉？这要说明白，为什么要气象局道歉？”

5、全国人大代表、贵州省省长林树森：“雪灾是一场自然灾害，除了部分擅自离岗、渎职等情况外，贵州省的干部表现得还比较好，不存在问责的问题。”

6、全国人大代表、陕西省省长袁纯清（当被问到华南虎事件时）： “在两会上，我们应该把精力主要放在审议政府工作报告上。”

7、全国政协委员、陕西海星集团董事长荣海：“（华南虎事件）政府最初的愿望可能是好的。”

8、全国人大代表、世界银行副行长兼首席经济学家林毅夫：“《政府工作报告》中所提出的4.8%的物价涨幅预期目标是合适的，即便是到5%，也是可以的。”

9、全国政协委员、玖龙纸业公司董事长张茵：“降低富人税负，把月薪10万元以上的最高累进税率从45%减至30%。”

10、全国政协委员、北京兆泰房地产开发有限公司董事长穆麒茹：“钉子户为了他个人的利益，损害了包括开发商在内的多数人的利益！这也是房价上涨的原因之一。”“虽然房地产产业对国民经济作出了贡献，但总体仍受到了不甚公正的待遇。”

12、全国政协委员、星河湾地产董事长黄文仔：“房价高其实没关系，政府可以通过税收形成良性循环，这样对大家都有利。”

13、全国政协委员、祈福房产董事长彭磷基：“如果你还没有买房的话，快点去买，现在是一个很好的价格。”

14、全国政协委员、信息产业部电信研究院副院长曹淑敏：“手机通话费不是高收费。”

15、全国人大代表、吉林省副省长陈晓光：“现在老百姓所反映的‘上学难、上学贵’的论调是不对的，我们从来没有过‘上学难’，也没有过‘上学贵’，我国也不存在‘上学难、上学贵’的问题。”

16、政协列席、国家新闻出版总署署长柳斌杰：“如果实行分级管理，等于承认淫秽色情可以大量出版。”

17、政协委员、广州市卫生局副局长曾其毅：“所谓看病难看病贵，我走遍全世界，看病最不难是中国，看病最不贵是中国。”“其实在中国看病并不贵，是人们的价值观念问题。”

18、全国政协委员、西北大学经济管理学院副院长韦苇：“国内旅游是省域之间互掏腰包，不会增加社会财富总量，反而污染环境，消耗能源，损坏文物，所以要控制国内游的规模。”

19、全国人大代表、山东济宁市长张振川：“允许有争论，但是标志城肯定要建。”(在回应108个政协委员签名反对在山东济宁建设“中华文化标志城”一事时张振川如是表示。2004年做过的一次预算认为，建造这个标志城将耗资300亿元人民币）

20、全国政协委员李晓东、王二虎、周一波、王西林联名提交提案：“每年清明节黄帝陵祭祖活动由全国人大、国务院、全国政协共同主办，陕西省政府或国内各 省轮流承办，国家主要领导人担当主祭，各省负责人率团、港澳台代表、海外各国华人代表共同参加祭祀，电视全球转播，把祭祀黄帝上升为国家级的大典。”

来源于互联网

好多冲突，好艰巨的任务哦。

写了一天， 终于the c++ programming language后面带的C++语法全部转换成了bison。
编译以后你猜有多少个冲突？

8000多个R/s 9000多个 R/r冲突。。。 看来消除这些冲突真是一件艰巨的任务阿！

C++的语法真是太美妙了， 不过也是我自己的水平不行。。。

先吃点东西休息一下。。。

ps: 怪事！ 打开了一个没有开封的桶状康师傅方便面， 里面的蔬菜包竟然已经被倒进了面里面，其他的料包都还完好。。。。 该不该吃呢。。。算了吧。 说不定装配这个方便面的工人还吐了口水进去。。。。

firefox浏览器使用wqy字体以后变满的解决办法

某同学的抱怨ubuntu下面firefox反应超慢， 其实是字体的原因了， wqy字体采用的是压缩的PCM字体， 就是在每次调用字体的时候就要解压缩来找这个东西， 所以在有大量文字的网页firefox就好像被卡住一样。 好了， 现在说解决的办法把。
cd /path/to/wqy/font/    #在我的ubuntu7.10上面是 /usr/share/X11/fonts/misc/
sudo gunzip wenquanyi*pcf.gz
sudo rm fonts.dir fonts.scale fonts.cache*
sudo mkfontdir .
sudo cp fonts.dir fonts.scale
sudo fc-cache -fv

然后 CTRL＋ALT＋BACKSPACE重启X以后， 打开FF就会发现浏览速度和飞一样拉。 爽！

ref:http://www.linuxdiyf.com/bbs/thread-82090-1-1.html

【转】Top-10 Application-Design Mistakes

 

Jakob Nielsen's Alertbox, February 19, 2008:

Top-10 Application-Design Mistakes

Summary:
Application usability is enhanced when users know how to operate the UI and it guides them through the workflow. Violating common guidelines prevents both.

It's hard to write a general article about application design mistakes because the very worst mistakes are domain-specific and idiosyncratic. Usually, applications fail because they (a) solve the wrong problem, (b) have the wrong features for the right problem, or (c) make the right features too complicated for users to understand.

Any of these three mistakes will doom your app, and yet I still can't tell you what to do. What's the right problem? What are the right features? What complicating curlicues can safely be cut from those features? For each domain and user category, these questions have specific and very different answers.

The only generalizable advice is this: rather than rely on your own best guesses, base your decisions on user research:

• Conduct field studies and task analysis before deciding what your app should do.


• Paper prototype your initial ideas before doing any detailed design — and definitely before wasting resources implementing something you'd have to change as soon as you get user feedback.


• Design iteratively, conducting many rounds of quick user testing as you refine your features.

Of course, people don't want to hear me say that they need to test their UI. And they definitely don't want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support.The general idea seems to be that real programmers can't be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they've spent a day observing a few end users.

(Whatever you do, at least promise me this: Don't just implement feature requests from "user representatives" or "business analysts." The most common way to get usability wrong is to listen to what users say rather than actually watching what they do. Requirement specifications are always wrong. You must prototype the requirements quickly and show users something concrete to find out what they really need.)

All that said, there are still plenty of general guidelines for application UIs — so many, in fact, that we have a hard time cramming the most important into our two-day course. Here's my list of 10 usability violations that are both particularly egregious and often seen in a wide variety of applications.

1. Non-Standard GUI Controls

Basic GUI widgets — command links and buttons, radio buttons and checkboxes, scrollbars, close boxes, and so on — are the lexical units that form dialog design's vocabulary. If you change the appearance or behavior of these units, it's like suddenly injecting foreign words into a natural-language communication. Det vil gøre læserne forvirrede (or, to revert to English: Doing so will confuse readers). For some reason, homemade design's most common victims are scrollbars. For years, we've encountered non-standard scrollbars in our studies, and they almost always cause users to overlook some of their options. We're seeing this again this year, in the studies we're conducting to update our course on Fundamental Guidelines for Web Usability. (The linked article includes screenshots of offending scroll controls.)

Some of the world's best interaction designers have refined the standard look-and-feel of GUI controls over 30 years, supported by thousands of user-testing hours. It's unlikely that you'll invent a better button over the weekend.

But even if your homemade design, seen in isolation, were hypothetically better than the standard, it's never seen in isolation in the real world. Your dialog controls will be used by people with years of experience operating standard GUIs.

If Jakob's Law is "users spend most of their time on other websites," then Jakob's Second Law is even more critical: "Users have several thousand times more experience with standard GUI controls than with any individual new design."

Users will most likely fail if you deviate from expectations on something as basic as the controls to operate a UI. And, even if they don't fail, they'll expend substantial brainpower trying to operate something that shouldn't require a second thought. Users' cognitive resources are better spent understanding how your application's features can help them achieve their goals.

1.a. Looking Like a GUI Control Without Being One

The opposite problem — having something that looks like a GUI control when it isn't one — can reduce usability even more. We often see text and headlines that look like links (by being colored or underlined, for example) but aren't clickable. When users click these look-alikes and nothing happens, they think the site is broken. (So please comply with guidelines for visualizing links.) A similar problem occurs when something looks like a button but doesn't initiate an action, or looks like a radio button but isn't a choice. We found an example of this in our current round of studies.

To design a custom-tailored shirt on Liste Rouge Paris, you must provide your measurements. As the following screenshot shows, there are two different paths through the application here, depending on whether your measurements are already on file with the tailor.

Our test user clicked incessantly on the New Customer button to indicate that he was indeed a new customer. Unfortunately, this screen element was not a button at all, but rather a non-clickable heading.

He was the only user to test this site because he encountered it during a task in which users could choose a site to visit (usually from a search listing). In this case, the user eventually overcame the confusion and proceeded to enter his measurements. If we had tested more users, a small percentage would have likely failed at this point. Each small error in dialog design reduces usage only by a small amount, but most UIs contain bundles of errors, and the number of lost customers adds up.

As an aside, this screen also uses radio buttons incorrectly. In theory, all five choices are mutually exclusive, which does call for radio buttons. But in the user's mental model of the workflow, there are actually two issues here: (a) new vs. old customers, and (b) how to provide the measurements for your situation. You should use a single set of radio buttons only when users will choose between options for a single issue.

So, in the case above, a better design would first ask users to decide the new/existing customer question, and then reveal the relevant radio buttons for the option they choose.

2. Inconsistency

Non-standard GUI controls are a special case of the general problem of inconsistent design.Confusion results when applications use different words or commands for the same thing, or when they use the same word for multiple concepts in different parts of the application. Similarly, users are confused when things move around, violating display inertia.

Using the same name for the same thing in the same place makes things easy.

Remember the double-D rule: differences are difficult.

Another example from our current study: Expedia pops up a two-month calendar view when users specify the departure or return date for a trip. The composite screenshot below was taken in February and shows what happens when you want to book a trip that starts on March 10 and ends on March 15.

In the second pop-up, the month of March has moved to the left, leaving room for April to appear on the right. This may seem like a convenient shortcut, since there's no way the user would want a February return date when traveling out in March.

In reality, however, the user is looking for March 15 in the same spot where it appeared in the first pop-up calendar: in the right-most column.

In our testing, the inconsistent placement of the months in the second pop-up caused confusion and delays, but users ultimately figured it out. We tested only a few users with this site, but if you observe this kind of almost-miss error in user testing, it's usually a sign that a few users will make the mistake for real during actual use.

Booking the wrong return date can have disastrous consequences — customers could arrive at the airport without a ticket for their expected flight. If a site has good confirmation emails, users might discover the problem before departure, but even that will cause aggravation and expensive customer support calls to resolve the situation.

Even if people eventually use the calendar correctly, it takes more time to ponder the inconsistent design than the time users save by not having to click the next-month button for April departures.

The shortcut that moves the months around saves time only for very frequent users who learn how to efficiently operate this part of the UI. So, an application for professional travel agents should probably use Expedia's calendar design. A site targeting average consumers should not.

3. No Perceived Affordance

"Affordance" means what you can do to an object. For example, a checkbox affords turning on and off, and a slider affords moving up or down. "Perceived affordances" are actions you understand just by looking at the object, before you start using it (or feeling it, if it's a physical device rather than an on-screen UI element). All of this is discussed in Don Norman's book The Design of Everyday Things. Perceived affordances are especially important in UI design, because all screen pixels afford clicking — even though nothing usually happens if you click. There are so many visible things on a computer screen that users don't have time for a mine sweeping game, clicking around hoping to find something actionable. (Exception: small children sometimes like to explore screens by clicking around.)

Drag-and-drop designs are often the worst offenders when it's not apparent that something can be dragged or where something can be dropped. (Or what will happen if you do drag or drop.) In contrast, simple checkboxes and command buttons usually make it painfully obvious what you can click.

Common symptoms of the lack of perceived affordances are:

• Users say, "What do I do here?"


• Users don't go near a feature that would help them.


• A profusion of screen text tries to overcome these two problems. (Even worse are verbose, multi-stage instructions that disappear after you perform the first of several actions.)

When I tested some of the first Macintosh applications in the mid-1980s, users were often stumped by the empty screen that appeared when they launched, say, MacWrite. What do I do here, indeed. The first step was supposed to be to create a new document, but that command was not shown anywhere in the otherwise highly visible Macintosh UI unless you happened to pull down the File menu. Later application releases opened up with a blank document on the screen, complete with an inviting, blinking insertion point that provided the perceived affordance for "start typing."

3.a. Tiny Click Targets

An associated problem here is click targets that are so small that users miss and click outside the active area. Even if they originally perceived the associated affordance correctly, users often change their mind and start believing that something isn't actionable because they think they clicked it and nothing happened. (Small click zones are a particular problem for old users and users with motor skill disabilities.)

4. No Feedback

One of the most basic guidelines for improving a dialog's usability is to provide feedback:

• Show users the system's current state.


• Tell users how their commands have been interpreted.


• Tell users what's happening.

Sites that keep quiet leave users guessing. Often, they guess wrong. (For an example of the problems with poor feedback, see the screenshot of VW's car configurator toward the bottom of my recent article reporting on our current round of testing: Because users couldn't tell which tire was selected, they had trouble designing their preferred car.)

4.a. Out to Lunch Without a Progress Indicator

A variant on lack of feedback is when a system fails to notify users that it's taking a long time to complete an action. Users often think that the application is broken, or they start clicking on new actions. If you can't meet the recommended response time limits, say so, and keep users informed about what's going on:

• If a command takes more than 1 second, show the "busy" cursor. This tells users to hold their horses and not click on anything else until the normal cursor returns.


• If a command takes more than 10 seconds, put up an explicit progress bar, preferably as a percent-done indicator (unless you truly can't predict how much work is left until the operation is done).

5. Bad Error Messages

Error messages are a special form of feedback: they tell users that something has gone wrong. We've known the guidelines for error messages for almost 30 years, and yet many applications still violate them. The most common guideline violation is when an error message simply says something is wrong, without explaining why and how the user can fix the problem. Such messages leave users stranded.

Informative error messages not only help users fix their current problems, they can also serve as a teachable moment. Typically, users won't invest time in reading and learning about features, but they will spend the time to understand an error situation if you explain it clearly, because they want to overcome the error.

On the Web, there's a second common problem with error messages: people overlook them on most Web pages because they're buried in masses of junk. Obviously, having simpler pages is one way to alleviate this problem, but it's also necessary to make error messages more prominent in Web-based UIs.

6. Asking for the Same Info Twice

Users shouldn't have to enter the same information more than once. After all, computers are pretty good at remembering data. The only reason users have to repeat themselves is because programmers get lazy and don't transfer the answers from one part of the app to another.

7. No Default Values

Defaults help users in many ways. Most importantly, defaults can:

• speed up the interaction by freeing users from having to specify a value if the default is acceptable;


• teach, by example, the type of answer that is appropriate for the question; and


• direct novice users toward a safe or common outcome, by letting them accept the default if they don't know what else to do.

Because I used Liste Rouge Paris as a bad example under Mistake #1a, I thought I'd play nice and use them as a good example here. The tailor offers 15 different collar styles (among many other options) for people ordering custom-designed shirts. Luckily, they also provide good defaults for each of the many choices. In testing, this proved helpful to our first-time user, because the defaults steered him toward the most common or appropriate options when he didn't have a particular preference.

Dialog to specify your shirt's collar on www.listerouge-paris.com (3 of 15 styles shown).

8. Dumping Users into the App

Most Web-based applications are ephemeral applications that users encounter as a by-product of their surfing. Even if users deliberately seek out a new app, they often approach it without a conceptual model of how it works. People don't know the workflow or the steps, they don't know the expected outcome, and they don't know the basic concepts that they'll be manipulating.For traditional applications, this is less of a problem. Even if someone has never used PowerPoint, they've probably seen a slide presentation. Thus, a new PowerPoint user will typically have at least a bare-bones understanding of the application before double-clicking the icon for the first time.

For mission-critical applications, you can often assume that most users have tried the app many times before. You can also often assume that new users will get some training before seeing the UI on their own. At the minimum, they'll usually have nearby colleagues who can give them a few pointers on the basics. And a good boss will give new hires some background info as to why they're being asked to use the application and what they're supposed to accomplish with it.

Sadly, none of these aides to understanding apply for most Web-based applications. They don't even apply for many ephemeral intranet applications.

Usability suffers when users are dumped directly into an application's guts without any set-up to give them an idea of what's going to happen. Unfortunately, most users won't read a lot of upfront instructions, so you might have to offer them in a short bulleted list or through a single image that lets them grok the application's main point in one view.

As an example, our test user who was trying to order a custom-tailored shirt was highly confused when the first screen in Hamilton Shirts' "Create Your Shirt" process displayed a fully designed shirt with an "Add to Bag" button. This screen mixed two metaphors: a configurator and an e-commerce product screen.

This is a case where a default value isn't helpful: people who want to design their own shirt are unlikely to want to buy a pre-designed shirt on the first screen.

(This screen also suffers from Mistake #1: non-standard GUI controls. In addition to its non-standard drop-down selection menus in a tabbed dialog that doesn't look enough like tabs, the screen has a non-standard way of paging through additional fabric swatches. Users are less likely to understand how to select fabrics when the controls are presented in this manner.)

Our test user never understood the process of designing his own shirt on this site and ultimately took his business elsewhere.

9. Not Indicating How Info Will Be Used

The worst instance of forcing users through a workflow without making the outcome clear is worth singling out as a separate mistake: Asking users to enter information without telling them what you'll use it for.A classic example is the "nickname" field in the registration process for a bulletin board application. Many users don't realize the nickname will be used to identify them in their postings for the rest of eternity — so they often enter something inappropriate.

As another example, we once tested an e-commerce site that smacked users with a demand for their ZIP code before they could view product pages. This was a big turn-off and many users left the site due to privacy concerns. People hate snoopy sites. An alternative design worked much better: It explained that the site needed to know the user's location so it could state shipping charges for the very heavy products in question.

10. System-Centric Features

Too many applications expose their dirty laundry, offering features that reflect the system's internal view of the data rather than users' understanding of the problem space.In our current study, one user wanted to reallocate her retirement savings among various investments offered by her company's plan (for example, to invest more in bonds and less in stocks). She thought she did this correctly, but in fact she had changed only the allocation of future additions to her retirement account. Her existing investments remained unchanged.

As far as the mutual funds company is concerned, new investments and current investments are treated differently. Reallocating future additions means changing the funds they'll buy when the employer transfers money into the account. Reallocating current investments means selling some of the holdings in existing mutual funds and using the proceeds to buy into other funds.

The key insights here?

• Our test user didn't have this distinction between new and old money; she simply wanted her retirement savings allocated according to her revised investment strategy.


• Even users who understand the distinction between new and old money might prefer to treat their retirement savings as a single unit rather than make separate decisions (and issue separate commands) for the new and old money.

It would probably be better to offer a prominent feature for changing the entire account's allocation, and use progressive disclosure to reveal expert settings for users who want to make the more detailed distinction between the two classes of money.

Bonus Mistake: Reset Button on Web Forms

This mistake relates to Web forms, but because so many applications are rich in forms, I'll mention it here: It's almost always wrong to have a Reset button on a Web form.The reset button clears the user's entire input and returns the form to its pristine state. Users would want that only if they're repeatedly completing the same form with completely different data, which almost never happens on websites. (Call center operators are a different matter.)

Making it easy for users to destroy their work in a single click violates one of the most basic usability principles, which is to respect and protect the user's work at almost any cost. (That's why you need confirmation dialogs for the most destructive actions.)

Design Competition

Have you designed a great application UI for a substantial real-life problem? Submit it for the Application Design Annual 2008 and get a chance to win the glory you deserve. Deadline: February 29.

Learn More

Full-day courses at the Usability Week 2008 conference in New York, San Francisco, London, and Melbourne:

• Application Usability 1: Page-Level Building Blocks for Feature Design


• Application Usability 2: Dialog and Workflow Design

Other Top-10 Lists

• Worst Web design mistakes of all time
  Summary based on the main elements of the other lists


• 10 High-Profit Redesign Priorities


• Usability in the Movies — Top 10 Bloopers


• Most violated homepage guidelines


• Top homepage usability guidelines


• Good deeds in Web design


• Web design mistakes (2005)


• Web design mistakes (2003)


• Web design mistakes (2002)
  With cartoons


• Web design mistakes (1999)


• Web design mistakes (1996)

See also: Usability 101: Introduction to Usability

好牛的妈妈

今天看邮件列表， 有一个人在问学习C++需要多大的勇气。 这种问题好像已经腐朽了， 不过回答的人还是很多。
忽然又问兄台这样回答

给个现实的例子。俺五十八岁的老母亲退休在家，这个月刚学会Ja va的SWT和JFace，现在开始摸Python，每天一两个小程序玩得不亦乐乎，她
老人家说：“就是那么回事，搞明白基本的机制，剩下都是语法细节，用的时候到书上查，到网上google就可以了”

呵呵，恕我直言，只不过是一门编程语言，别搞得和苦行僧出家一样 ，如果真的那么痛苦不学也罢，学了也不容易学好:)

真是好牛的妈妈！！厉害厉害。

另外， 论坛的地址是： http://groups.google.com/group/pongba/topics?hl=zh-CN有兴趣可以看一看。

恶毒的C＋＋语法

这几天在写毕设相关的东西， 得写一个C＋＋的解析器(parser), 发现开源的这个东西不多， 而且都还挺复杂。 拿到一份文法表， 光文法就有14页之巨。看了这些东西才真正的体会到C＋＋语法的恶毒。 真是巨大阿。。。

如果有幸能完成， 一定开源给大家用。 写这个东西真是个硬差使。

还是LISP的语法简单阿。。。。