Search

2/25/2010

自排正確停車方法

自排正確停車方法

正確的方式:踩煞車 --> 排入 N 檔 --> 拉手煞車 --> 放掉腳煞車,確定車不會滑動--> 再排入P檔即可.


錯誤的方式:一般人都是先排入 P 檔 --> 再拉手煞車 --> 這是錯誤的觀念

自排箱的P檔.是利用一爪形駐車鉤與棘輪裝置的咬合駐車鉤裝在變速箱本體,棘輪多半裝在最終傳動系統.當停車打入P檔時,自排箱並不是靠引擎剎車,而是將傳動系統鎖住車輛. 在斜坡時停車,最好先拉手剎車,等車子幾乎不會移動時,再打入P檔,才不致於傳動軸因為車輛本身的重量,使得棘輪與駐車鉤卡死, 嚴重的話,排檔桿將無法排入或造成變速箱離合片壞損 ~~提供參考~~~

'fine by me' vs. 'fine with me'?

'fine by me' vs. 'fine with me'?

A quick answer would be - not a lot. Both obviously mean I accept that/I agree with that. Possibly and maybe here I'm simply looking for a distinction, with me is more personal than by me.

If, say among friends, you agree to accept a plan/arrangement, you would say: That's fine with me.

If the government has agreed to raise taxes and you agree that this is acceptable, you would say; that's fine by me.

2/11/2010

支援超多技術的 Multiple File Uploader

支援超多技術的 Multiple File Uploader

TinyMCE的作者們就寫了plupload,只要瀏覽器支援Google Gears、Flash、Sliverlight、Yahoo Browser Plus,或是HTML 5 File API的其中任何一項,就可以一次選擇很多檔案上傳!

Plupload - A tool for uploading files using Flash, Silverlight, Google Gears, HTML5 or Browserplus

2/07/2010

【台北中正】公館/母女の店泰式簡餐

【台北中正】公館/母女の店泰式簡餐

<母女の店泰式簡餐>
地址:台北市中正區羅斯福路三段286巷4弄10號
電話:02-2368-4300
營業時間:11:30-14:00、17:00-21:00
價目:招牌椒麻雞飯$100、酸菜牛肉飯$100

2/05/2010

Another IE Gotcha - Dynamically Created Radio Buttons

Another IE Gotcha - Dynamically Created Radio Buttons


goog.dom.createDom_ = function(doc, args) {
var tagName = args[0];
var attributes = args[1];

// Internet Explorer is dumb: http://msdn.microsoft.com/workshop/author/
// dhtml/reference/properties/name_2.asp
// Also does not allow setting of 'type' attribute on 'input' or 'button'.
if (goog.userAgent.IE && attributes && (attributes.name || attributes.type)) {
var tagNameArr = ['<', tagName];
if (attributes.name) {
tagNameArr.push(' name="', goog.string.htmlEscape(attributes.name),
'"');
}
if (attributes.type) {
tagNameArr.push(' type="', goog.string.htmlEscape(attributes.type),
'"');
// Create copy of attribute map to remove 'type' without mutating argument
attributes = goog.cloneObject(attributes);
delete attributes.type;
}
tagNameArr.push('>');
tagName = tagNameArr.join('');
}

var element = doc.createElement(tagName);

if (attributes) {
if (goog.isString(attributes)) {
element.className = attributes;
} else {
goog.dom.setProperties(element, attributes);
}
}

if (args.length > 2) {
var childHandler = function(child) {
// TODO: More coercion, ala MochiKit?
if (child) {
element.appendChild(goog.isString(child) ?
doc.createTextNode(child) : child);
}
};

for (var i = 2; i < args.length; i++) {
var arg = args[i];
// TODO: Fix isArrayLike to return false for a text node.
if (goog.isArrayLike(arg) && !goog.dom.isNodeLike(arg)) {
// If the argument is a node list, not a real array, use a clone,
// because forEach can't be used to mutate a NodeList.
goog.array.forEach(goog.dom.isNodeList(arg) ?
goog.array.clone(arg) : arg,
childHandler);
} else {
childHandler(arg);
}
}
}

return element;
};

2/04/2010

JScript Deviations from ES3

JScript Deviations from ES3

This draft provides a description of JScript’s deviations and extensions to ECMAScript 3rd Edition Specification. This is work-in-progress, and there are still a few sections to document or correct.

Writing Effective JavaScript Unit Tests with YUI Test

Writing Effective JavaScript Unit Tests with YUI Test

Functional testing, as opposed to unit testing, is designed to test the user’s experience with the product rather than input-output sets for code. If you find yourself wanting to test that the user interface responds in a specific way due to user interaction, then you really want to write some functional tests rather than unit tests. YUI Test can be used to write some basic functional tests, but the most popular (and quite good) tool for such testing is Selenium.

The best way to determine if something is a unit test is to ask if it can be written before the code that it’s designed to test actually exists. Unit tests, as part of test-driven development, are actually supposed to be written ahead of the actual code as a way to guide development efforts. Functional tests, on the other hand, cannot exist ahead of time because they are so tied to the user interface and how it changes in response to user interaction.

Each test suite can contain other test suites as well as test cases; only test cases can contain actual tests (methods beginning with the word "test"). The best way to organize your test hierarchy is to follow a very simple pattern:

* Create one test suite for every object you’re going to test.
* Create one test case for every method of an object you’re going to test and add it to the object’s test suite.
* Create one test in each test case for each input-output set.


The curious case of JavaScript unit testing
JavaScript’s dependent nature in the browser makes it difficult to accomplish true unit testing on anything but the lowest-level utility functions. JavaScript libraries are actually fairly easy to unit test because each method typically does one discrete operation given a certain set of inputs. The JavaScript library code doesn’t have any business logic or direct knowledge of the relationship between DOM elements, CSS, and the JavaScript itself. That’s why libraries such as YUI have such comprehensive unit test suites: the tests are pretty easy to write and then execute.

The larger problem is unit testing JavaScript code that runs web applications. This is where you start to run into serious dependency problems due to the interrelation HTML and CSS. The JavaScript code isn’t simply manipulating data; it’s expected to run within the web application environment. To do true unit testing, you would need to stub out the entire web application environment just to get the code to execute. And then, what do you test? A lot of the time you’re testing how the user interface responds to user input, which means you’re actually starting to cross over into the realm of functional testing (also called system testing).

Periodically, I get asked for help in running JavaScript unit tests on the command line using Rhino. While it is possible, I strongly recommend against doing this. If your JavaScript is intended to run in a web browser, then it should be tested in a web browser. Rhino is a completely different environment than any browser and, in fact, isn’t the JavaScript engine for any existing browser (it is a Java port of SpiderMonkey, the C-based library that was the JavaScript engine for Firefox prior to version 3.5). Testing JavaScript code in Rhino only tells you that the code works in Rhino, it does not tell you that the code runs in any browser.

Some folks have gone through a lot of trouble to try and bring command line JavaScript unit testing into the world. John Resig created env.js, a JavaScript utility that builds out a lot of the common browser environment in Rhino. As interesting as that is, you’re once again dealing with a browser environment that doesn’t exist in the wild. I have seen tests that work perfectly fine in all browsers and fail miserably in an env.js-powered Rhino environment. There’s no real value in testing code in an environment into which it won’t ultimately be deployed.

Even scarier is Crosscheck, a Java-based system that claims to test your code in several browsers without actually using the browser. Created by The Frontside Software, Inc., Crosscheck tries to recreate the browser environment of Internet Explorer 6, Firefox 1, and Firefox 1.5 in Java. As you might have expected, Crosscheck relies on Rhino as it’s JavaScript engine and then proceeds to build out each browser environment. An ambitious idea, for sure, but now you’re going one step further away from the truth: you’re relying on someone else’s understanding of browser quirks on which to base your tests. I’ve been in web development for a long time, but even I couldn’t sit down and list out every browser quirk. The result is that you’re testing in several mythical browser environments that have no real correlation to reality.

I’ll repeat, JavaScript code designed to be run in web browsers should be tested in web browsers. All code should be tested in the environment in which it is to be deployed. If your JavaScript code will be deployed to Rhino, then by all means, test in Rhino. But that’s the only reason you should test your JavaScript code in Rhino (or any other command line JavaScript engine).

It’s the automation, stupid

The real reason that command line tools keep trying to appear is for the purposes of automation. When the developer is sitting in front of his computer and running tests in browsers, the unit testing process is pretty simple. But that’s terribly redundant and, of course, boring. It would be much easier if the tests were automatically run periodically and the results were recorded. Really, the command line appeal is integrate test running into a continuous integration (CI) system.

The two CI systems I hear the most about are CruiseControl and Hudson. Both work in a similar manner, periodically running a series of tasks related to your build. They are capable of checking out code, running scripts, and of course, executing command-line operations. Command-line utilities fit perfectly into these systems because the output can easily be monitored for completion and errors. This represents a major problem since most of the browsers people use are GUI-based (Lynx is still around, though).

Fortunately, there is another movement of JavaScript testing focused on command line-initiated yet still browser-based testing. Leading the charge is Selenium, a tool primarily designed for functional testing is generally useful in that it can be run from the command line and can execute JavaScript inside of a browser. This means that, from the command line, you can use Selenium to fire up a browser, navigate to a particular page, run JavaScript commands, and inspect what happens to the page. What’s more, you can use Selenium Remote Control to fire up any number of browsers and perform the same tests. These results can be passed back into the command line interface, creating a seamless integration with CI systems. This is an area in which I’m currently doing more research. Stay tuned!

Another interesting tool that recently popped up is TestSwarm. TestSwarm’s approach is different than that of Selenium. Instead of manually starting browsers and navigating them to a page, TestSwarm relies on browsers to already be set up and attached to the TestSwarm server. The browsers can then poll the server to see if there are any new jobs that must be processed. The advantage is that you can add new browsers simply by opening a browser and pointing it to the TestSwarm server. Since the browsers are very loosely coupled to the system, upgrading to include new browsers is ridiculously simple.

TestSwarm also enables the crowd sourcing of tests. Anyone who wants to help test a product can joined a swarm and volunteer to leave the browser open for testing.

2/03/2010

HipHop for PHP: Move Fast

HipHop for PHP: Move Fast

HipHop for PHP isn't technically a compiler itself. Rather it is a source code transformer. HipHop programmatically transforms your PHP source code into highly optimized C++ and then uses g++ to compile it. HipHop executes the source code in a semantically equivalent manner and sacrifices some rarely used features — such as eval() — in exchange for improved performance. HipHop includes a code transformer, a reimplementation of PHP's runtime system, and a rewrite of many common PHP Extensions to take advantage of these performance optimizations.

Finding new ways to improve PHP performance isn't a new concept. At run time the Zend Engine turns your PHP source into opcodes which are then run through the Zend Virtual Machine. Open source projects such as APC and eAccelerator cache this output and are used by the majority of PHP powered websites. There's also Zend Server, a commercial product which makes PHP faster via opcode optimization and caching. Instead, we were thinking about transforming PHP source directly into C++ which can then be turned into native machine code. Even compiling PHP isn't a new idea, open source projects like Roadsend and phc compile PHP to C, Quercus compiles PHP to Java, and Phalanger compiled PHP to .Net.

The main challenge of the project was bridging the gap between PHP and C++. PHP is a scripting language with dynamic, weak typing. C++ is a compiled language with static typing. While PHP allows you to write magical dynamic features, most PHP is relatively straightforward. It's more likely that you see if (...) {...} else {..} than it is to see function foo($x) { include $x; }. This is where we gain in performance. Whenever possible our generated code uses static binding for functions and variables. We also use type inference to pick the most specific type possible for our variables and thus save memory.

The transformation process includes three main steps:

1. Static analysis where we collect information on who declares what and dependencies,
2. Type inference where we choose the most specific type between C++ scalars, String, Array, classes, Object, and Variant, and
3. Code generation which for the most part is a direct correspondence from PHP statements and expressions to C++ statements and expressions.