2006年05月17日

转自Official Google Blog


Making AJAX development easier

A Googler May 16, 2006

 - 

Show original item

Posted by Bret Taylor, Product Manager




AJAX has
the power to make your site more compelling and more dynamic, but AJAX
development is often complicated, with much of the development time
spent working around browser quirks and the fragility of AJAX
components. Trust us, we know–the development of our own AJAX apps,
like Google Maps and Google Calendar, caused us no small amount of
AJAX-induced frustration.


That’s why we’re bringing you Google Web Toolkit. GWT is a new
publicly available software development tool that makes creating AJAX
applications much easier. With GWT, you can develop and debug your own
AJAX applications in Java code using the Java development tools of your
choice. When you deploy your application to production, the GWT
compiler simply translates your Java application to browser-compliant
JavaScript and HTML.


Check it out over on Google Code.

2006年04月13日

下面是地址,使用以前的google帐号就可有登陆
http://calendar.google.com/

期盼已久,果然是相当不错

2006年04月06日
Summary

Bjarne offers a sneak peek at the next version of standard C++ ("C++0x") which
should be complete by 2009.The work on C++0x has entered a decisive phase. The ISO C++ committee aims for
C++0x to become C++09. It follows that the standard must be complete for ratification
by the ISO member nations in 2008. The set of facilities offered will be chosen from
those currently being considered. To finish in time, the committee has stopped looking
for new proposals and concentrates on the ones already being considered.

This paper briefly outlines the guiding principles of the work on C++0x, presents a few
examples of likely language extensions, and lists some proposed new standard libraries.

[Note: This paper was first presented to the "Modern C++ Design & Programming" conference
in Shanghai, November 18, 2005]

Guiding Principles

C++ is a general-purpose programming language with a bias towards systems
programming that:

  • is a better C
  • supports data abstraction
  • supports object-oriented programming
  • supports generic programming

By "systems programming", I mean programming the kind of tasks traditionally
associated with the operating system and fundamental tools. This includes the operating
system kernel, device drivers, system utilities, networking, word processing tools,
compilers, some kinds of graphics and GUI, database systems, games engines,
CAD/CAM, telecommunications systems, etc. This kind of work is strongly represented
among current C++ users. For example, see my "applications" page:
http://www.research.att.com/~bs/applications.html.

The aim of C++0x is for that characterization above to remain true. It is not an aim to eliminate
one of those styles (or "paradigms"; e.g. to make C++ less compatible with C) or to add a
radically new paradigm. The most effective styles of programming use a combination of
these techniques. Using these techniques in concert is often called "multi-paradigm programming," so we
can say that we want to improve C++ as a multi-paradigm programming language.

The high level aims for the language part of C++0x are to:

  • Make C++ a better language for systems programming and library building

    • Rather than providing specialized facilities for a particular sub-community (e.g.,
      numeric computation or Windows-style application development)
  • Make C++ easier to teach and learn
    • Through increased uniformity, stronger guarantees, and facilities supportive of
      novices

In other words, C++0x should be better than C++98 where C++98 is already
strong—and maybe in a few more areas that are natural generalizations of what
C++98 supports. When it comes to supporting specialized application areas, such as
numeric computation, Windows-style application development, and embedded systems
programming, C++0x will rely on libraries. The efficiency of the basic language features
(such as, stack-allocated objects and pointers) plus the generality and flexibility of
its abstraction mechanisms (such as classes and templates) make the use of libraries
attractive in an incredibly broad set of application areas and reduce the need for new
language features.

We cannot make the language simpler to teach and learn by removing features. Stability
and compatibility are major concerns, so eliminating anything of importance (in any way)
is not an option (and eliminating something of no importance would not be a help). This
leaves us with the options of generalizing rules and adding easier-to-use features. We aim
at both, but the latter is easier. For example, better library facilities, such as containers
and algorithms, save users from some of the problems associated with lower-level
facilities like arrays and pointers. Language facilities that simplify the definition and
use of libraries (such as concepts and generalized initializer lists—see below) will therefore
contribute to the ease of use of C++0x.

Some people object: "Don’t dumb-down C++ for novices—there are
languages enough for those", or "The sooner novices become experts the
better!" These people have a point, but there will always be more novices
than experts. Many C++ users quite reasonably don’t want to become C++
experts—they are experts in their own fields (e.g., physicists,
graphics specialists, or hardware engineers) who use C++. In my opinion,
C++ has become too "expert friendly" and it will cost us little to provide
much better support for "novices". It will cost us nothing in terms of
performance (the zero-overhead principle still holds), in flexibility (we
don’t propose to prohibit anything), or in terseness of code. On the
contrary, we aim to simplify expression of ideas. Finally, C++ is so
large, is used in so many application areas, and there are so many useful
C++ design techniques, that we are all "novices" much of the time.

The C++0x improvements should be done in such a way that the resulting language is
easier to learn and use. Among the rules of thumb for the committee are:

  • Provide stability and compatibility (with C++98, and, if possible, with C)
  • Prefer standard library facilities to language extensions
  • Make only changes that change the way people think
  • Prefer generality to specialization
  • Support both experts and novices
  • Increase type safety (by providing safe alternatives to currently unsafe facilities)
  • Improve performance and ability to work directly with hardware
  • Fit into the real world

Naturally, applying these ideals and rules is an art rather than a science and people can
(and do) disagree on what is a natural development of C++ and what would be a new
paradigm. C++0x will most likely support optional garbage collection and it will support
concurrency in the form of a machine model plus standard library facilities supporting
threads (and maybe more). Some would consider that radical, but I don’t; people have
used garbage collection with C++ for years (where that makes sense) and just about
everybody uses threads sometime. In these cases, the issue is simply to standardize
current practice.

We try to focus on extensions that "change the way people think" because that way we
gain the greatest benefits for our efforts. Every change has a cost in terms of
implementation, learning, etc., and the cost of a change does not always directly relate to its
benefits. The major advances/benefits do not come from improving the way a
programmer writes an individual line of code, but from improving the way a programmer
solves problems and organizes programs. Object-oriented programming and generic
programming have changed the way many people think—and that was the purpose
of the C++ language facilities supporting those styles. Thus, the best use of our time as
language and library designers is to work on facilities and techniques that help change the
way people think.

Please note the last rule, "Fit into the real world". As usual for C++, the aim is not to
create the most beautiful language—though we all prefer elegance when we can
get it—but to provide the most useful language. This implies that compatibility,
performance, ease of learning, and interoperability with other systems and languages are
serious interrelated concerns.

Language Features

Let’s see how code using new C++0x features might look:

template<class T> using Vec = vector<T,My_alloc<T>>;
Vec<double> v = { 2.3, 1.2, 6.7, 4.5 };
sort(v);
for(auto p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;

Each line except the last is illegal in C++98, and in C++98 we’d have to write more (error-prone) code
to get the work done. I hope you can guess the meaning of this code without
explanation, but let’s look each line individually.

template<class T> using Vec = vector<T,My_alloc<T>>;

Here, we define Vec<T> to be an alias of
vector<T,My_alloc<T>>. That is, we define a vector called
Vec that works exactly like vector except that it uses my
allocator (My_alloc) rather than the default allocator. The ability to
define such aliases and to bind some but not all parameters of a template has been
missing from C++. It has traditionally been referred to as a "template typedefs" because
typedef is what we typically use for defining type aliases, but for
technical reasons, we preferred using. One advantage of this syntax is
that it introduces the name being defined where it is easy for the human reader to spot.
Note also another detail. I didn’t write

template<class T> using Vec = vector< T,My_alloc<T> >;

It will no longer be necessary to add that space between the terminating >’s. These two
extensions have already been accepted in principle.

Next we define and initialize a Vec:

Vec<double> v = { 2.3, 1.2, 6.7, 4.5  };

Initializing a user-defined container
(vector<double,My_allocator<double>>) with an
initializer list is new. In C++98, we can only use such initializer lists for aggregates
(arrays and classic structs). Exactly how this extension will be achieved is still
being discussed, but the solution will most likely involve a new kind of
constructor—a "sequence constructor". Allowing the above implies that
C++ better meets one of its fundamental design criteria: support user-defined and built-in
types equally well. In C++98 arrays have a notational advantage over
vectors. In C++0x, that will no longer be the case.

Next, we sort the vector:

sort(v); 

To do that within the framework of the STL we must overload sort for
containers and for iterators. For example:

template<Container C> // sort container using <
void sort(C& c);

template<Container C, Predicate Cmp> // sort container using Cmp
where Can_call_with<Cmp,typename C::value_type>
void sort(C& c, Cmp less);

template<Random_access_iterator Ran> // sort sequence using <
void sort(Ran first, Ran last);

template<Random_access_iterator Ran, Predicate Cmp> // sort sequence using Cmp
where Can_call_with<Cmp,typename Ran::value_type>
void sort(Ran first, Ran last, Cmp less);

This illustrates the most significant proposed C++0x language extension that is likely to be accepted: concepts.
Basically, a concept is the type of a type; it specifies the properties required of a type. In
this case, the concept Container is used to specify that the two first
versions of sort need an argument that meets the standard library
container requirements. The where-clauses are used to specify the
required relationship between the template arguments: that the predicates can be applied
to the containers’ element types. Given concepts we can provide far better error
messages than is currently possible and distinguish between templates taking the same
number of arguments, such as

sort(v, Case_insensitive_less());   // container and predicate

and

sort(v.begin(), v.end());           // two random access iterators

The difficulty in the design of “concept” is to maintain the flexibility
of templates so that we don’t require template arguments to fit into class
hierarchies or require all operations to be accessed through virtual
functions (as for Java and C# generics). In “generics”, an argument must
be of a class derived from an interface (the C++ equivalent to “interface”
is “abstract class”) specified in the definition of the generic. That
means that all generic argument types must fit into a hierarchy. That
imposes unnecessary constraints on designs requires unreasonable foresight
on the part of developers. For example, if you write a generic and I
define a class, people can’t use my class as an argument to your generic
unless I knew about the interface you specified and had derived my class
from it. That’s rigid.

There are workarounds, of course, but they complicate code. Another problem is that you
cannot use built-in types directly with generics, because built-in types, such as
int, are not classes and don’t have the functions required by interfaces
specified by a generic—you then have to make wrapper classes for holding built-in
types and access elements indirectly through pointers. Also, the typical operation on a
generic is implemented as a virtual function call. That can be very expensive (compared
to just using a simple built-in operation, such as + or <). Implemented that way,
generics are simply syntactic sugar for abstract classes.

Given "concepts", templates will retain their flexibility and performance.
There is still much work left before the committee can accept a specific
and detailed concept design. However, concepts are a most likely
extension because they promise significantly better type checking, much
better error messages, and greater expressive power. That should lead to
significantly better library interfaces, starting with the current
standard containers, iterators, and algorithms.

Finally, consider the last line that outputs the elements of our vector:

for (auto p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;

The difference from C++98 here is that we don’t have to mention the type of the iterator:
auto means “deduce the type of the declared variable from the
initializer”. Such uses of auto are far less verbose and also less
error-prone than current alternatives, such as:

for (vector< double, My_alloc<double> >::const_iterator p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;

The new language features mentioned here are all aimed at simplifying generic
programming. The reason is that generic programming has become so popular that it is
seriously strains the language facilities. Many “modern” generic programming techniques
border on “write only” techniques and threaten to isolate its users. To make generic
programming mainstream, as object-oriented programming was made mainstream, we
must make template code easier to read, write, and use. Many current uses are too clever
for their own good. Good code is simple (relative to what it is trying to do), easy to
check, and easy to optimize (i.e., efficient). This implies that a wide range of simple ideas
can be expressed simply in C++0x and that the resulting code is uncompromisingly
efficient. The former is not the case in C++98—at least not for a sufficiently large
range of techniques relying on templates. Better type checking and more extensive use of
type information to shorten code will make code shorter and clearer, and easier to maintain,
as well as more likely to be correct.

Library Facilities

Ideally, we’d leave the C++ language mostly unchanged and focus on adding standard
libraries. However, libraries that are sufficiently general to be standard are not easy to
design and the standards committee is—as usual—short of resources. We
are a relatively small group of volunteers and all have “day jobs”. This puts unfortunate
limits on how adventurous we can be with new libraries. On the other hand, the
committee started early and a technical report on libraries ("The Library TR") was recently approved by vote. It
provides several facilities that are directly useful to programmers:

  • Hash Tables
  • Regular Expressions
  • General Purpose Smart Pointers
  • Extensible Random Number Facility
  • Mathematical Special Functions

I particularly appreciate having standard versions of regular expression matching and
hash tables (called unordered_maps) available. In
addition, the Library TR provides extensive facilities for builders of generic libraries
building on the STL:

  • Polymorphic Function Object Wrapper
  • Tuple Types
  • Type Traits
  • Enhanced Member Pointer Adaptor
  • Reference Wrapper
  • Uniform Method for Computing Function Object Return Types
  • Enhanced Binder

This is not the place to go into details about these libraries or into the further facilities
that the committee would like to provide. If you are interested, I suggest you look at the
proposals on the WG21 site (see “information sources” below), the libraries “wish list”
(on my home pages), and the BOOST libraries (www.boost.org). I personally would like
to see more libraries that are immediately useful to applications builders, such as Beman
Dawes’ library for manipulating files and directories (currently a BOOST library) and a
socket library.

The list of proposals is still quite modest and not anywhere as
ambitious as I’d like. However, more proposals from the committee’s
large backlog of suggestions are being considered and more libraries
will appear either as part of the C++0x standard itself or as further
committee technical reports. Unfortunately, lack of resources (time,
money, skills, people, etc.) will continue to limit progress in this
direction. Sadly, I cannot offer hope for the most frequently wished
for new standard library: a standard GUI library. A GUI library is
simply too large a task for the volunteers of the C++ standards
committee to handle and too difficult a task given the many
(non-standard but huge, useful, and supported) GUI libraries available.
Please notice that even though they are not standard, the major C++
GUIs have more users than most programming languages and are often
better supported.

In addition to these general-purpose libraries, the committee presented a library interface
to the most basic level of hardware in its “Performance TR”. That TR is primarily aimed
to help embedded systems programmers and to disprove myths about poor performance
of C++ code and about C++ being unsuitable for low-level tasks.

Putting It All Together

“Drawing all shapes in an array” is a classical example of object-oriented programming
(going back to the early Simula days). Using generic programming, we can generalize
that to drawing each element of any container holding (pointers to) shapes:

template<Container C>
void draw_all(C& c)
where Usable_as<typename C::value_type,Shape*>
{
for_each(c, mem_fun(&Shape::draw));
}

In C++0x, we hope to have Container as a standard concept and Usable_as
as a standard predicate. The
for_each algorithm is already in C++98, but the version that takes a
container (rather than a pair of iterators) will have to wait for concepts in C++0x. The
where-clause is a mechanism through which an algorithm can express
requirements on its arguments. Here, draw_all() requires (obviously) that
the elements of the container must be usable as (implicitly convertible to)
Shape*. In this case, the where-clause gives us a degree of
flexibility/generality not offered by simply requiring a container of
Shape*’s. In addition to any container of Shape*’s, we can
use any container with elements that can be used as Shape*’s, such as a
list<shared_ptr<Shape*>> (where
shared_ptr is a likely C++0x standard library class) or a container of
pointers to a class derived from Shape*, such as
deque<Circle*>.

Assuming that we have points p1, p2, and p3, we can test
draw_all() like this

vector<Shape*> v = {
new Circle(p1,20),
new Triangle(p1,p2,p3),
new Rectangle(p3,30,20)
};

draw_all(v);

list<shared_ptr<Shape*>> v2 = {
new Circle(p1,20),
new Triangle(p1,p2,p3),
new Rectangle(p3,30,20)
};

draw_all(v2);

The "draw all shapes" example is important because when you can do that well, you can
do much of what’s key to object-oriented programming. As written here, the example
demonstrates the power of multi-paradigm programming by also employing generic
programming (concepts and templates), conventional programming (e.g. the
free-standing standard-library function mem_fun()), and simple data
abstraction (the function object returned by mem_fun()). Thus, this
simple example opens the door to a host of elegant and efficient programming
techniques.

I hope that after looking a bit at this example, your reaction will be "How simple!" rather
than "How clever! How advanced!" In my opinion, many people are trying too hard to
be clever and advanced. The real aim of design and programming is to produce the
simplest solution that does the job and express it in the clearest possible way. The aim of
the C++0x design is to better support such simple solutions.

Information Sources

My web pages (http://www.research.att.com/~bs)
contain much useful information.
There you will find information about my own work (books, articles, interviews, FAQs, etc.) and
links to sources that I find most helpful, such as a list of interesting C++ applications, a list of
C++ compilers, and links to useful libraries (e.g., BOOST). In connection with C++0x,
you can find:

  • "Wish lists" for language features and library facilities
  • The Standard: IOC/IEC 14882—International Standard for Information
    Systems—Programming Language C++
  • The Performance TR: ISO/IEC PDTR 18015—Technical Report on C++
    Performance.
  • The Library TR: JTC1.22.19768 ISO/IEC TR 19768—C++ Library
    Extensions.
  • A link to the WG21 (ISO C++ Standards Committee) site, where you can find all the proposals being considered
  • A page with some of my proposals (including "concepts") to the committee. (Please
    remember that not all proposals are accepted and that essentially all proposals that are
    accepted incorporate major changes and improvements before acceptance.)

Acknowledgements

Thanks to Rong Yao ("Royal") who encouraged me to clarify many points. Also thanks
to Nicholas Stroustrup, Bjorn Karlsson, and students from my 689 class for
their helpful comments.


About the Author

Bjarne Stroustrup is the designer and original implementor of the C++
Programming Language. He is currently the College of Engineering Endowed Chair
in Computer Science at Texas A&M University.
He formerly worked as the head of AT&T Lab’s Large-scale Programming Research
department, from its creation until late 2002.

2006年03月30日

最近在写项目的文档,直接是用latex写的,很方便可以生成漂亮的英文文档。但是当我加入一些图片时,却发生了一些小错误。

错误1:加入用metapost生成的图片时,出现下面的错误提示:
! LaTeX Error: Unknown graphics extension: .1.

后来才发现是使用了pdflatex来生成文档时,而产生的错误。
解决方法:加一句  \DeclareGraphicsRule{*}{mps}{*}{}
wangyin的页面

错误2:另外有些图片是用openoffice画的,其输出的是后缀为eps的文件。再直接加入时有下面的错误:
<use ./figures/stack.png> [MP to PDF] (./figures/packet.eps
! TeX capacity exceeded, sorry [save size=5000].
\dohandleMPpathA …he \nofMParguments \endcsname

后来发现也是图片和pdflatex一起用时的错误。可以讲eps文件转换为pdf图片
更多的解决方法见下列页面

关于pdflatex,可见wikipedia。(竟然发现wikipedia可以用了?奇怪的是过了一会又不能用了)
tex处理过tex文件后生成dvi文件,然后通过dvipdf转换成pdf文件
pdflatex直接处理tex文件,输出pdf文件
pdflatex使用jpg,png能图片格式,不能加入eps文件

wikipedia怎么突然能用了,然后又闪电般的不能用了?

2006年03月22日

早上,发现邮箱里有封信是google发来的。邀请我使用page creator。



发现这个服务还不错。这是我的页面。但是,好像lianliming很早就有这个邀请了吧,为什么我的要慢这么多呢,上次的那个gtalk就是我晚一些才收到了google的邀请。

2006年03月20日

最近看到朋友的文章,谈到了要记住朋友的生日。仔细想想,我也是相当的惭愧,自己这些年来忙来忙去,也常常忘记朋友的生日,还有好多的朋友的渐少联系了。而这真是因为工作有那么忙?自己有blog也是想写就写,懒了也就不写了。实际上现在的通讯和交流方式是很多的,完全是可以做的更好的。
所以,对自己的网络使用方式进行重构。经常写点自己的情况,多和朋友们联系和沟通。
这个blog以后作为技术blog,讨论技术话题。在msn新建了blog,更多的是用来和朋友交流。
我的邮箱是gmail的那个,欢迎朋友来信联系。

2006年03月13日

仔细想了想,今天还是发生了好多的事的,就记下来吧。

先是因为要给zyn复印论文,今天就偷懒没有去单位。所以早上也就可以小小的有个懒觉。

在还没有睡醒时,yj给我发短信说她的那个工作泡汤了,好多留洋的人和她竞争,找个好工作是不容易阿。

先去图书馆问了复印论文的一些要求,所是要找那个论文的作者或者其导师的同意,我得在下午zyn来之前把这个搞定了,然后下午她来就直接可以印论文了。

还好我要给zyn印的两个论文的作者都是一个老师的学生,但我不知道那个老师的办公室在那里。就先回世宁放下书包,然后查到那个老师在流体力学国家实验室那里。

然后,我就凭着自己的印象和问别人,找到那个学院的院办。那个楼很旧,里面人不是很多,有一些人在开会。最后问到了教务办公室,里面一个中年女人,我都看不出她脸上抹了几层,:P。看她手头好像有什么事,对我也爱理不理。她告诉我到对面的国家重点实验室去找那个老师。

从那个楼出来,我就找那个楼的入口,对面有个mm好像再等人,她看到我,走过来问我505教研室在那里,我当然是不知道了。但是很奇怪,周围的楼好像没有超过5层的。怎么看她长得像上回lxx带去打羽毛球的那个很厉害的那个mm呢?

我进了那个重点实验室的大楼,里面有点冷清,好多巨粗的管子,好像是实验用的,我逮着一个人就问,yxg老师在那个教研室,然后那个人让我到3楼去看,还指着就是那个方向的那个屋子,我想这下找到了,但是到了3层之后,又问一个人,他说yxg老师不在这里,说是可能在rx楼或者yf楼,真奇怪,我就没直接走。然后一转身,竟然碰到刚才在楼地下碰到的那个向我问路的mm,笑盈盈的走了过去,真奇怪,这不是3楼么。然后我敲另外一个屋子的门,里面的人没有反应。外面倒是来了个人问我找谁,我说我找yxg老师,他奇怪地看着我说,你是考研的学生吧。我说我找yxg老师复印论文。他也说yxg老师不再这里。我就准备走了。看看几点,就收到了zyn发的短信,她说别人告诉她,可以通过馆际借阅那些论文,不麻烦我了,我也不用再跑了,回世宁。

看以前的那个codeblue和robot的论文。

忽然想到,最近考研的复试线该下了吧,就发短信给sm,她的分数比较悬,她也是很焦急,从短信看得出来。我查了那个学校今年和往年的招生的列表,然后计算了他的成绩在所有公布的人里的情况,在边缘上,但应该是可以复试了。然后安慰她说不要着急,好好休息。

中午去清真食堂吃饭,那里的菜还可以,只是贵了点。期间,tj的小弟打电话来说bh的分数线下来了,是315。大家都说今年的分数线太低了,真是丢人。其实我以前复习了两个月考的成绩也不高,但是对分数这个东西,却真是没有一点感觉。

下午来了继续看文章。

突然,看今天的日期是3.13。就想到了明天是yj 的生日,就给她发短信问。结果她好像很感动,但是因为工作的情况,今年不想过生日,但是我还是混到他一顿饭:P

看论文,研究公司的其他部门 的业务,产品。最后发现一个部门有MA认证,这是一个突破口,决定根据这个写一个场景的描述。同时,进一步想到了前一段美国的矿难时,他们好像使用了机器人来营救被困人,就此查到了美国劳工部专门有一个组织,矿山安全和健康委员会。上面有很多资料,现在需要初步了解这个行业,提出好的方案。

吃晚饭,fvv和我提到syf,我就开玩笑说,不要提她。然后,tj很关切的给我说有gf的好处等等,搞的我很不好意思。找到一个互相都喜欢的人是需要缘分的,我倒是不是很急。fvv说道师母,要给实验室的师兄介绍,赞那:)。最近开了一遍《围城》,的确是相当的经典的小说。最近爱胡思乱想,索性有找了一堆电子书,晚上下班后看。

从keso的blog的文章找到了阎辉的blog,还不错,上面有一篇文章吸引了我,最真实的2006年应届毕业生真实薪水, 在他的blog里的照片又发现了开复和code jam的选手们的合影,真是羡慕阿,下一次是一定要参加,试试自己的实力。今天好像又在什么地方看到了上海交大获得了05年代acm程序设计大赛的全球总冠军,想到我一个叔叔的小孩wht,高二结束就保送到了上海交大去本硕博连读。这个小孩挺聪明的,也对计算机着迷,估计在下几次的比赛中会有他的身影。

看到google刚刚发表的 google mars, google的人就是能想,这的确是很吸引人的。

看刘艺的文章,关于教育,真是感慨。

2006年02月16日


Pal写的新书:Programming TinyOS

TinyOS技术交流会:TTX3 Demonstrations and Posters

TinyOS 2.0 Beta Release
2006年02月07日

年前,准备回家,到超市去买东西,突然发现了有魔方买,也不贵,5元,就买了一个。小小的魔方又勾起了在附中时的美好的回忆阿。还能记得那时有个数学大牛金某,大家都叫他老大吧,他玩魔方的速度超快,好像是一分钟以内吧,还给魔方建模,是我等崇拜的偶像阿。那时魔方很流行,那场面大阿,夸张的说,是人手一魔方阿,:P。

魔方的英文是magic cube,另外和这个词比较相近的也很有意思的是magic square,中文翻译成幻方(最简单的幻方是九宫格。有一个暑假我就借过一本关于幻方的书,看了后真是感觉不看不知道,世界真奇妙阿,关于幻方的世界也是相当的有趣,以后有时间再把关于幻方的也补上)

下面是关于魔方的一些资源:
怎样玩魔方
国内很不错的一个站点,魔方吧
另外一个摩方的站点,资料也很全
更晕的4d魔方
很多关于魔方的一些数学资料,也有和幻方相关的资源
魔方的另一些资源,有书,软件等
魔方applet:

2006年01月05日
这给脚本程序的功能比较简单,还有很多可以完善的地方,但是其已经足够说明linux环境下的方便和强大


#!/bin/bash

args=$#
progname=$0
filetype=$1
path=$2

function usage {
    echo "=========================================="
    echo " Usage: $progname type path"
    echo "      type: the type of files what you want to count  "
    echo "      path: the path where the files are located"
    echo "=========================================="
}

function testArgs {
    if [ $args != $1 ]; then
        usage
        exit
    fi
}

testArgs 2
find $path -name "*.$filetype" -print | xargs wc
exit