Joost - 網路電視不打烊

Joost - 網路電視不打烊

軟體:Joost(版本:0.10.3)
類別:網路多媒體
性質:Freeware(9.7 M)

【編輯/王國淵】

近年來,由於網路建設發展迅速,使用者們家中所使用的網路已經由原本的數據機撥接、ADSL 、Cabel 進步到目前最新的 FTTB 了,隨著所使用的頻寬持續成長,許多的多媒體應用就能夠被透過網路來實現,而網路電視就是很好的一個例子。但是,要欣賞網路電視前,你當然要有一套合適的播放軟體囉,Joost 就是一款值得你一試選擇。

Joost 是一款免費的網路電視軟體,使用者只要安裝之後,就可以透過它內建的選台器功能,選擇觀看數百個線上頻道,這麼多頻道數,可是沒有一家第四台業者比得上的喔。舉凡新聞、體育、電影、卡通,都可能在這包羅萬象的網路電視上找到,讓你想看什麼、就看什麼,再也不用擔心電視上撥的都是老舊又重複的節目或影片了。

網路是無遠弗屆的,也因此,網路電視台的種類也是千奇百怪。而使用 Joost 的好處就是,它內建的節目頻道功能會不斷地擴充,讓你每天都有不同的選擇,永遠不會嫌膩。如果想要看看多元化的節目,甚至是想聽聽外語新聞,那麼 Joost 可是一個免費又方便的選擇喔!


下載:http://www.joost.com/getjoost.html

Concurrency Testing in JAVA Applications


Testing and optimizing Java code to handle concurrent activities is difficult without test automation. Even with test automation, being able to correlate the test activity from the client side to observations of thread, memory, object and database connection use on the server side is difficult at best. In this article, Frank Cohen describes methods for concurrency testing in Java applications and shows a new technique to correlate what a Java application server is doing on the server side while a load test automation tool drives a test on the client side.


Introduction


This article picks up where Brian Goetz’s article Testing Concurrent Programs ends. Goetz describes the need to use concurrency mechanisms in Java programs and gives tips to test concurrency mechanisms. For instance, Goetz article introduces a technique to avoid Java’s inherent concurrency problems – mutable and static objects – by shielding the mutable objects by wrapping them in immutable objects. Goetz says “all this sounds like a lot of work, and it is.” At this point in your concurrency testing, an investigation into test automation tools may help your effort.


Concurrency testing is well known, but hard to do


Most IT managers agree that concurrency testing is the appropriate way to determine many performance bottlenecks, resource contention issues, and service interruptions. However, in my experience few ever do concurrency testing because the available test tools are not satisfactory.


Consider the minimum functions a test automation tool needs to support to expose concurrency issues:



  • Unit test of a specific function.

  • Variations on the input data the unit test sends to a function.

  • Business flows through a system function using sequences of functional unit tests.

  • Operating the business flows in concurrently running threads. Additionally, in large-scale concurrency tests the flows may need to be operated across multiple test machines.

  • Variations in the mix of business flows in the concurrent running threads. For instance, the first mix may test at 20% of the business flows operating a create-a-new-user flow while 80% operate a sign-in flow and a second test reverses the mix to 80% create and 20% sign-in.

  • Variations in the test parameters based on usage factors. For instance, changing the test parameters based on the time-of-day or end-of-quarter.

There is no concurrency testing heaven here. You can never create a deterministic test to uncover a non-deterministic concurrency issue. The goal instead is to get close to the problem and to get lucky. Operating a concurrency test with as many of the above operational parameters might not guarantee that the test will surface concurrency issues but it will work the odds in your favor to run across the right conditions to trigger a failure.


From Unit Tests to Concurrency Tests


There are some things you should expect in today’s test automation tools. For instance, many test automation tools are now using unit tests in ways that aid in surfacing concurrency problems. Each unit test operates a particular method or class. Stringing unit tests together into a sequence forms a functional test of a business flow.



You should also expect the test tool to provide libraries that embellish unit tests to use protocol handlers to speak the native protocols of the application or service under test, including HTTP, SOAP, Ajax, REST, Email, and custom network protocols. Additionally, you should expect the test tool embellishes functional unit tests with a Data Production Library (DPL) to provide test data as input to the unit test and data to validate the service or class response.


It is reasonable to find a test automation framework wrapping unit tests into functional tests that may be operated concurrently to identify concurrency issues in an application. I coined the term TestScenario in my open-source test tool (TestMaker) to name this wrapper.



A TestScenario operates the unit tests as a functional test by operating a sequence of unit tests once, as a load test by operating sequences of the unit tests in concurrently running threads, and as service monitors by running the unit tests periodically. The TestScenario gives us the flexibility to try multiple sequences of business flows concurrently.


The TestScenario defines which TestNodes will operate the test. I coined the term TestNode for the distributed test environment operating on a remote machine or a rack of machines in a QA lab. When the TestScenario begins it moves the unit test and any other resource files to the defined TestNodes. The unit test speaks the native protocols of the application under test. The TestNodes provide the unit test data through the DPL, operates the unit tests, and logs the results.


As the TestScenario operates the test, a monitor watches the application host and logs usage and resource statistics. The test tools then correlate the monitored data to the unit test operation to identify performance bottlenecks and available optimizations.


The key to using a test automation platform for concurrency testing is to identify what is happening on the server side. I find it valuable to observe at least the following:



  • Java Virtual Machine statistics (heap, memory, thread, object instantiations, and garbage collection)

  • Service call statistics (time to serve request, external service and database query times, properties settings, and service interface request values and schema)

  • Subsystem statistics (if the system uses a database then I want to see the transaction logs, input parameters, and query operations)

Eventually all of these observations are going to come with the manual expense of the time to correlate the observed data to what the test automation tool is operating on the client-side. Recently I began finding agent and agentless tools to monitor server-side activity in a way that can be snapshot correlated to the test operation. One such agent-based tool is Glassbox.


Tools like Glassbox watch an application server receive requests, operate objects and EJBs, communicate with databases, and interact with message buses. These tools provide a service interface that test environments can use to automate the correlations. For instance, Glassbox uses the Java Management Extensions (JMX) interface to communicate performance observations.


Glassbox installs an agent named the Glassbox Inspector to monitor traffic through the Java virtual machine and send data to an analysis application called Glassbox Troubleshooter. The system diagnoses problems by constructing a virtual application model describing the application components and how they connect to each other using aspects. Using a singly directed graph the system represents a component or resource within the application and at each edge a usage relationship. Using aspects Glassbox discovers the components dynamically as the application runs and constructs a model automatically.


The model allows Glassbox to go beyond simple correlation analysis to trace causality through the system. For example, a correlation analysis might reveal that a slow operation occurred at the same time the database was running slowly overall, suggesting a database tuning problem. Because the virtual application model allows walking the usage relationships in both directions, the model reveals that the slow database was in fact caused by a long-running report query and identifies that as the cause.


I recently used Glassbox to observe the Sun Blueprint’s Java Petstore and correlated the observations to a load tests. Some things became clear. While I had thought the browser-to-server communication would lead to performance bottlenecks at parsing the incoming requests and marshalling the responses, we found that more often communication between the EJBs and the database caused the biggest hotspots in performance.



I was able to operate a load test of the PetStore and identify the slowest performing functions by correlating the load test to an alert for slow database operations.


Integration gives correlation capability


Some of the test automation tools and server-side monitors are going further to provide correlations between the test activity and observations at the Thread and object level on what happens in the backend.


For instance, most test automation tools produce a Scalability Index chart that shows Transaction Per Second (TPS) ratings for increasing levels of concurrent requests to a service. The following chart shows the TPS values for two use cases.



In the above chart the red bar shows the service operating at 0.17 TPS when the test use case operates for 10 minutes at 20 concurrent virtual users (threads.) The blue bar shows the service operating at 0.08 TPS at 40 concurrent virtual users. I modified the chart to also show a Performance Alert when Glassbox observes an operation that falls outside of a normal time to complete the operation. (Glassbox uses properties files to set the parameters for normal time operation.) Clicking on the Performance Alert button brings you directly to the Glassbox Inspector for an explanation of the problem and details needed to understand and solve the performance problem.


While concurrency testing is often arduous, difficult to stage, and lengthy there are a new crop of test automation tools that make development and operation of concurrency tests relatively easy. Combining these test tools with monitoring software enables correlations of load testing activity on the front-end to thread, object, and service activity to surface concurrency issues. This is not guaranteed to surface concurrency issues but it will work the odds in your favor to run across the right conditions to trigger a failure and remediate a solution.


Resources


Brian Goetz article Testing Concurrent Programs


PushToTest TestMaker – open-source test automation


Glassbox – open-source troubleshooting agent for Java applications


Toward a Benchmark for Multi-Threaded Testing Tools

Testing Concurrent Programs

Writing correct concurrent programs is harder than writing sequential ones. This is because the set of potential risks and failure modes is larger – anything that can go wrong in a sequential program can also go wrong in a concurrent one, and with concurrency comes additional hazards not present in sequential programs such as race conditions, data races, deadlocks, missed signals, and livelock.


Testing concurrent programs is also harder than testing sequential ones. This is trivially true: tests for concurrent programs are themselves concurrent programs. But it is also true for another reason: the failure modes of concurrent programs are less predictable and repeatable than for sequential programs. Failures in sequential programs are deterministic; if a sequential program fails with a given set of inputs and initial state, it will fail every time. Failures in concurrent programs, on the other hand, tend to be rare probabilistic events.


Because of this, reproducing failures in concurrent programs can be maddeningly difficult. Not only might the failure be rare, and therefore not manifest itself frequently, but it might not occur at all in certain platform configurations, so that bug that happens daily at your customer’s site might never happen at all in your test lab. Further, attempts to debug or monitor the program can introduce timing or synchronization artifacts that prevents the bug from appearing at all. As in Heisenberg’s uncertainty principle, observing the state of the system may in fact change it.


So, given all this depressing news, how are we supposed to ensure that concurrent programs work properly? The same way we manage complexity in any other engineering endeavor – attempt to isolate the complexity.


Structuring programs to limit concurrent interactions


It is possible to write functioning programs entirely with public, static variables. Mind you, it’s not a good idea, but it can be done – it’s just harder, and more fragile. The value of encapsulation is that it makes it possible to analyze the behavior of a portion of a program without having to review the code for the entire program.


Similarly, by encapsulating concurrent interactions in a few places, such as workflow managers, resource pools, work queues, and other concurrent objects, it becomes simpler to analyze and test concurrent programs. Once the concurrent interactions are encapsulated, you can focus the majority of your testing efforts primarily on the concurrency mechanisms themselves.


Concurrency mechanisms, such as shared work queues, often act as conduits for moving objects from one thread to another. These mechanisms contain sufficient synchronization to protect the integrity of their internal data structures, but the objects being passed in and out belong to the application, not the work queue, and the application is responsible for the thread-safety of these objects. You can make these domain objects thread-safe (making them immutable is often the easiest and most reliable way to do so), but there is often another option: make them effectively immutability.


Effectively immutable objects are those which are not necessarily immutable by design – they may have mutable state – but which the program treats as if they were immutable after they are published where they might be accessed by other threads. In other words, once you put a mutable object into a shared data structure, where other threads might then have access to it, make sure that it is not modified again by any thread. The judicious use of Immutability and effective immutability limit the range of potentially incorrect concurrent actions by limiting mutability to a few core classes that can be strenuously unit-tested.


Listing 1 shows an example of how effective immutability can greatly simplify testing. The client code submits a request to a work manager, in this case an Executor, to factor a large number. The calculation is represented as a Callable<BigInteger[]>, and the Executor returns a Future<BigInteger[]> representing the calculation. The client code then waits on the Future for the result.


The FactorTask class is immutable, and therefore thread-safe, so no additional testing is required to prevent unwanted concurrent interactions. But FactorTask returns an array, and arrays are mutable. Shared mutable state needs to be guarded with synchronization, but because the application code is structured so that once the array of BigIntegers is returned by the FactorTask its contents are never modified, the client and task code can “piggyback” on the synchronization implicit in the Executor framework and do not need to provide additional synchronization when accessing the array of factors. If it were possible that any thread might modify the contents of the array of factors after it was created, this technique would not work.


    ExecutorService exec = …
class FactorTask implements Callable<BigInteger[]> {
private final BigInteger number;

public FactorTask(BigInteger number) {
this.number = number;
}

public BigInteger[] call() throws Exception {
return factorNumber(number);
}
}

Future<BigInteger[]> future = exec.submit(new FactorTask(number));
// do some stuff
BigInteger[] factors = future.get();



This technique can be combined with nearly all the concurrency mechanisms in the class library, including Executor, BlockingQueue, and ConcurrentMap – by only passing effectively immutable objects to these facilities (and returning effectively immutable objects from callbacks), you can avoid much of the complexity of creating and testing thread-safe classes.


Testing concurrent building blocks


Once you’ve isolated concurrent interactions to a handful of components, you can focus your testing efforts on those components. Since testing concurrent code is difficult, you should expect to spend more time designing and executing concurrent tests than you do for sequential ones.


The factors below are some of the concepts to consider when designing and running tests for concurrent classes. They, as well as others, are covered in much greater detail in the Testing chapter of Java Concurrency in Practice.



  • Tests are probabilistic. Because the failures you are searching for are probabilistic ones, your test cases are (at best) probabilistic as well. To give yourself the maximum chance of running across the right conditions to trigger a failure, you should plan to run concurrent tests for much longer.

  • Explore more of the state space. Running tests for a longer time is not going to find the problem if you are simply retrying the same inputs and the same initial state over and over again. You want to explore more of the state space, which with concurrent programs, includes temporal considerations as well. For example, if testing insertion and removal in a queue, you’ll want to explore all the relative timings and orderings with which the two operations might be initiated.

  • Explore more interleavings. The scheduler may preempt a thread at any time, but most of the time short synchronized blocks will run to completion without preemption. This limits the likelihood that race conditions will be disclosed, as other (potentially undersynchronized) code is less likely to run while another thread is in the middle of a synchronized block. Tools like ConTest can randomly introduce yield() calls into synchronized blocks to explore more possible interleavings.

  • Match thread count to the platform. If you run as many threads as you have processors, threads will never be preempted by the scheduler, reducing the number of potential interactions between active and waiting threads. Similarly, if you run many more threads than you have processors, you reduce the number of potential interactions between active threads. Tailoring thread count so that the number of runnable threads at any time is a small multiple of the processor count will often result in a more interesting variety of interleavings.

  • Avoid introducing timing or synchronization artifacts. Tests for concurrent data structures often involve having some threads inserting elements while other threads remove them, and asserting things like “everything that went in came out”, “nothing that didn’t go in came out”, and “everything came out in the right order.” The obvious way to code such tests involves maintaining data structures shared across the test threads, which will themselves require synchronization. But if the test program does its own synchronization, it may perturb the timing or scheduling with which the component being tested runs, masking potential negative interactions.

All this sounds like a lot of work, and it is. But by limiting the scope of concurrent interactions to a few widely-used, well-tested components, you greatly reduce the amount of effort required to test an application. And, by reusing existing tested library components, such as the classes in the java.util.concurrent package, you further reduce your testing burden.


Evan Almighty 王牌天神

Evan Almighty 王牌天神

軟體:Evan Almighty(版本:N/A)
類別:動作遊戲
性質:Freeware()

【編輯/宗文】

這是一款動作遊戲,遊戲的目標是將畫面中所有的動物都順利送至方舟中,只要玩家接觸到動物,便能將其舉起,此時如果靠近畫面右側的梯子就可以將動物順利送入方舟中。

遊戲中玩家的動作要快,因為大洪水會從底層升起,如果動作不快就會被洪水淹沒。另外還要小心跑來跑去的議員或記者,如果不小心碰觸到可是會扣一點紅心值的。玩家可以藉由跳躍來躲避他們的追趕。遊戲中玩家可以直接跳躍到上層的平台,但是無法直接下降到低層的平台,必須找尋平台的左右兩端才能下去,這常常會浪費許多時間,玩家要特別注意。遊戲中會不定時不定點出現一些物品,玩家取得後可以增加積分。



遊戲操控說明:
1.利用方向鍵中的左右鍵移動主角。
2.方向鍵中的上鍵可以進行跳躍。

下載:http://www.miniclip.com/games/evan-almighty/es/

Blobular 奇特的橘色生物

Blobular 奇特的橘色生物

軟體:Blobular(版本:N/A)
類別:動作遊戲
性質:Freeware()

【編輯/宗文】

遊戲中玩家必須在每一個關卡中,收集所有的蔬菜或水果,例如香菇、蘋果或西瓜等等,收集完畢後才能順利過關,並且可以挑戰更艱難的下一關。玩家要注意在每一個關卡當中,都是有時間限制的喔!因此玩家收集蔬菜或水果的速度一定要加快!另外遊戲中有些地方比較狹窄,玩家可以讓體型變大的主角分裂成數個較小的型態,來順利通過狹隘的地方。



有時玩家會覺得不知道目前所在關卡何處,或是不瞭解那邊還有要收集的蔬菜或水果,此時可以利用滑鼠左鍵點擊畫面下方的「Map」,如此可以看到整個關卡的全景以及所有的物品。遊戲裏玩家要注意有些地上的尖刺,或者空中帶刺的圓盤等等,不能碰觸到它們。另外遊戲中會出現一些寶物,例如玩家如能取得鬧鐘的圖示,則可以延長限制的時間,這是幫助玩家過關的好用寶物。



遊戲操控說明:
1.利用方向鍵中的左右鍵移動主角。
2.方向鍵中的上鍵可以跳躍,下鍵可以擠過稍微窄的地方。
3.按A鍵可以讓身體便大的主角分裂成數個小顆的,S鍵可以組合成原狀。

下載:http://www.freeworldgroup.com/games6/gameindex/blobular.htm

Danger Girl 具危險性的女孩

Danger Girl 具危險性的女孩

軟體:Danger Girl(版本:N/A)
類別:動作遊戲
性質:Freeware()

【編輯/宗文】

遊戲中玩家必須在每一個關卡中,擊退所有的外星人才能過關,並且可以挑戰更艱難的下一個關卡。玩家將可以利用女孩身邊的球,將球丟向外星人所駕駛的飛碟,有些飛碟要被球擊中數次才會掉落。飛碟掉落時記得要躲開,以免被撞及而扣生命值,另外飛碟掉落後會有金幣出現,或者有一些水果、醫藥箱,拾取金幣可以增加積分,水果和醫藥箱則可以補充生命值。

遊戲中敵人會從天空中射擊子彈,玩家必須及時躲開,才能避免遭受攻擊。除了一般敵人之外,還會有大頭目登場喔!這些大頭目的武器非常精良,玩家要小心避開,再利用時機對他們加以攻擊。遊戲操控方面,利用滑鼠移動可以控制女主角行動,按滑鼠左鍵不放開會出現瞄準游標,玩家可用來瞄準要攻擊的方向,放開左鍵後便可將球丟出。另外在沒有拿球時,按滑鼠左鍵可以跳躍,躲避敵人的攻擊。



下載:http://www.gamesheep.com/game/danger-girl/index.php?act=PlayNow

Death Village 鬼屋

Death Village 鬼屋

軟體:Death Village(版本:N/A)
類別:動作遊戲
性質:Freeware()

【編輯/宗文】

遊戲中玩家必須引導主角到達出口處的大門,如此才能順利過關。遊戲有一個特點,就是畫面會隨著玩家滑鼠游標的移動來自動拉遠拉近,讓遊戲畫面更有變化性。遊戲的每一個關卡可是有時間限制的,因此玩家動作要快,才能夠順利過關。

遊戲中玩家並無法直接操控主角移動,而是要利用周邊的物品、鬼魂或木乃伊等等來引導他走入正確的路徑。例如玩家可以拉開門讓主角走入不同房間,可以按樓梯讓階梯暫時消失不讓主角爬上樓梯,又或者可以敲窗戶以及敲棺木讓鬼魂及木乃伊現身。不過玩家要注意一點,可以讓鬼魂驚嚇主角,但是不能讓他直接碰觸到,否則驚嚇過度遊戲就會結束。



遊戲操控方面,利用滑鼠左鍵點擊適當的位置既可。畫面中玩家的滑鼠移動時,會有一個白色手套跟著移動,當手套呈現敲打或緊握的狀態時,表示這個地方可以有動作發生。

下載:http://nigoro.jp/game/deathvillage/deathvillage.html

Super B B超人

Super B B超人

軟體:Super B(版本:N/A)
類別:動作遊戲
性質:Freeware()

【編輯/宗文】

遊戲中玩家必須注意每關前面的說明指示,如此才能順利依照指示來達成任務而順利過關。畫面右上角會有一個線條與帶B字的圖示,B字會由左到右移動,這是代表由起點出發,而B字到最右邊時則抵達終點。在這期間玩家會遭遇到許多敵人與障礙物,玩家可以利用B超人的攻擊力量將其摧毀,如果來不及擊倒就必須趕緊躲避,以免降低生命值。

遊戲中會有一些救人質的任務,玩家除了要小心敵人的攻擊之外,還要注意關卡規定救人質的數量,一定要超過此數量否則既使超人抵達終點也不能過關。另外還要注意不要隨意攻擊,把人質都給殺光了。遊戲中提供了一些武器的升級或者暫時性的防護能力,玩家可以利用在關卡中賺取的積分來購買這些升級超人的能力,如此才能夠對抗愈來愈強大的敵人。



遊戲操控方面,利用四個方向鍵移動主角,滑鼠游標可以操控超人攻擊瞄準的地方,按左鍵可以進行攻擊。

下載:http://www.freeworldgroup.com/games6/gameindex/super-b.htm

Shield Defense 超級基地防護器

Shield Defense 超級基地防護器

軟體:Shield Defense(版本:N/A)
類別:動作遊戲
性質:Freeware()

【編輯/宗文】

遊戲中玩家將會利用基地的防護檔板,將敵人發射的武器反彈回去,並藉此來攻擊敵人。一開始的敵人動作慢,所配備的武器也不精良,因此較好應付,但隨著遊戲的進行,敵人的數量與攻擊威力會隨之增加,移動速度也加快,玩家必須眼明手快,否則很難應付愈來愈困難的關卡。



遊戲中玩家可以利用擊毀敵人所賺取的金錢,用來購買各式不同提升武力或防禦力的武器,又或者修復基地等等,升級後玩家將有更強大的能力來對抗這些頑強的敵軍。一些特殊提升的能力相當好用,例如玩家如果購買了「Sticky Shield」之後,原本只有反彈敵方子彈的檔板,此時將具有黏住敵方一發子彈的能力,並且能隨時發射這一發子彈,如此發射方位玩家較好掌握,擊潰敵軍的效率也能大為提升。



遊戲操控方面,利用滑鼠移動來控制檔板移動,按左鍵可以發射被防護檔板所吸附的子彈(有購買才有作用。)

下載: