不知道是我太迟顿,又或者是我的流览器的关系?我感觉google reader的界面改掉了。原来的界面很朴素啊,现在不对了。风格很强烈的说。
仔细一看,原来右边还有一条提示:New! Things look pretty different around here. Learn more about Reader's fresh new look. Dismiss this message.
哇,原来是这样的,我就想,我就应没有那么傻吧。确实是变了,一下子都没有适应过来。。
Submitted by gouki on 2008, December 6, 11:39 PM
不知道是我太迟顿,又或者是我的流览器的关系?我感觉google reader的界面改掉了。原来的界面很朴素啊,现在不对了。风格很强烈的说。
仔细一看,原来右边还有一条提示:New! Things look pretty different around here. Learn more about Reader's fresh new look. Dismiss this message.
哇,原来是这样的,我就想,我就应没有那么傻吧。确实是变了,一下子都没有适应过来。。
Submitted by gouki on 2008, December 6, 1:51 PM
天时不如地利,地利不如人和。
三里之城,七里之郭,环而攻之而不胜。夫环而攻之,必有得天时者矣;然而不胜者,是天时不如地利也。
城非不高也,池非不深也,兵革非不坚利也,米粟非不多也;委而去之,是地利不如人和也。
故曰: 域民不以封疆之界,固国不以山溪之险,威天下不以兵革之利。 得道者多助,失道者寡助。寡助之至,亲戚畔⑧之;多助之至,天下顺之。以天下之所顺,攻亲戚之所畔;故君子有不战,战必胜矣。”
Submitted by gouki on 2008, December 5, 9:30 PM
好象是说这款MSN软件不错(当然是linux下的),先加入源,顺便说一下,我的源是通过ubuntu tweak来进行更新的,这款tweak软件很方便,只要在第三方源里加入再刷新就行了,以下是需要加入的源的内容:
deb http://ppa.launchpad.net/galaxium/ubuntu hardy main
deb-src http://ppa.launchpad.net/galaxium/ubuntu hardy main
然后更新一下:apt-get update
最后运行 安装程序 :apt-get install galaxium
然后就可以运行 了,界面也和msn差不多。。。
就是,连接的速度和成功率不如MSN,唉,没办法。。。没有先天优势啊
Submitted by gouki on 2008, December 5, 3:06 PM
这两个域名在我身边很久了,当初的一些想法最后都没有做。在征得团队成员的同意后,决定出售这两个域名。
有需要的可以在此留言,或者加我QQ或者MSN等 。。。
QQ:19129540
msn:goukixiao@hotmail.com,学学坏人,用全角,呵呵
Submitted by gouki on 2008, December 5, 12:13 AM
by Kevin Yank
The following is republished from the Tech Times #165.
When interviewing a PHP developer candidate for a job at SitePoint, there is one question that I almost always ask, because their answer tells me so much about the kind of programmer they are. Here’s the question: “In your mind, what are the differences between good PHP code and bad PHP code?”
The reason I like this question is because it tests more than just a candidate’s encyclopedic knowledge of PHP’s functions. Zend’s PHP certification does a good job of that (as does the test that Yahoo! issues to applicants for its PHP developer jobs, apparently).
Rather, the answer to this question tells me whether a PHP developer has, for example, experienced the pain of working with poorly-written code inherited from a careless predecessor, and whether he or she will go the extra mile to save the rest of the team from that same pain.
I don’t have a set notion of the perfect answer to the question, but I do know the kinds of things I’m hoping to hear. Just off the top of my head:
Good PHP code should be structured. Long chunks of code can be broken up into functions or methods that achieve sub-tasks with simple code, while non-obvious snippets should be commented to make their meaning plain. As much as possible, you should separate frontend HTML/CSS/JavaScript code from the server-side logic of your applications. PHP’s object oriented programming features give you some especially powerful tools to break up your applications into sensible units.
Good PHP code should be consistent. Whether that means setting rules for the names of variables and functions, adopting standard approaches to recurring tasks like database access and error handling, or simply making sure all of your code is indented the same way, consistency makes your code easier for others to read.
Good PHP code should be portable. PHP has a number of features, such as magic quotes and short tags, that can break fragile code when they are switched on or off. If you know what you’re doing, however, you can write code that works by adapting to its environment.
Good PHP code should be secure. While PHP offers excellent performance and flexibility out of the box, it leaves important issues like security entirely in the hands of the developer. A deep understanding of potential security holes like Cross-Site Scripting (XSS), Cross-Site Request Forgeries (CSRF), code injection vulnerabilities, and character encoding loopholes is essential for a professional PHP developer these days.
Once a candidate has answered this question, I usually have a pretty good idea of whether they’ll be hired or not. Of course, there’s always the possibility that an interviewee simply isn’t able to articulate these types of things, so we also have our candidates sit a PHP developer exam.
Many of the questions in this exam seem straightforward on the surface, but they give candidates plenty of opportunity to show how much they care about the little details.
The following “bad” code is a highly simplified example of the sort of thing we might put in our PHP developer exam. The question might be something like “How would you rewrite this code to make it better?”
<?php
echo("<p>Search results for query: " .
$_GET['query'] . ".</p>");
?>
<?php
echo("<p>Search results for query: " . $_GET['query'] . ".</p>");
?>
The main problem in this code is that the user-submitted value ($_GET['query']) is output directly to the page, resulting in a Cross Site Scripting (XSS) vulnerability. But there are plenty of other ways in which it can be improved.
So, what sort of answer are we hoping for?
Good:
<?php
echo("<p>Search results for query: " .
htmlspecialchars($_GET['query']) . ".</p>");
?>
<?php
echo("<p>Search results for query: " .
htmlspecialchars($_GET['query']) . ".</p>");
?>
This is the least we expect. The XSS vulnerability has been remedied using htmlspecialchars to escape dangerous characters in the submitted value.
Better:
<?php
if (isset($_GET['query']))
{
echo '<p>Search results for query: ',
htmlspecialchars($_GET['query'], ENT_QUOTES), '.</p>';
}
?>
<?php
if (isset($_GET['query'])) {
echo '<p>Search results for query: ',
htmlspecialchars($_GET['query'], ENT_QUOTES), '.</p>';
}
?>
Now this looks like someone we might want to hire:
* The “short” opening PHP tag (<?) has been replaced with the more portable (and XML-friendly) <?php form.
* Before attempting to output the value of $_GET['query'], isset is used to verify that it actually has a value.
* The unnecessary brackets (()) around the value passed to echo have been removed.
* Strings are delimited by single quotes instead of double quotes to avoid the performance hit of PHP searching for variables to interpolate within the strings.
* Rather than using the string concatenation operator (.) to pass a single string to the echo statement, the strings to be output by echo are separated by commas for a tiny performance boost.
* Passing the ENT_QUOTES argument to htmlspecialchars to ensure that single quotes (') are also escaped isn’t strictly necessary in this case, but it’s a good habit to get into.
Somewhat distressingly, the number of PHP developers looking for work that are able to give a fully satisfactory answer to this sort of question—at least here in Melbourne—are few and far between. We spent a good three months interviewing for this latest position before we found someone with whom we were happy!
So, how would you do when asked a question like this one? Are there any factors that make PHP code good or bad that you feel I’ve left out? And what else would you look for in a PHP developer?