Mac OSX phpunit install

To install via terminal:
$ curl https://phar.phpunit.de/phpunit.phar -o phpunit.phar
$ chmod +x phpunit.phar
$ cp phpunit.phar /usr/local/bin/.
$ mv phpunit.phar /usr/local/bin/phpunit

PHP 使用 CURL 同步抓取多個網頁

一般 CURL 抓網頁的方法, 是一頁一頁抓, 假設要抓 4頁, 所費時間各別是 5,10,7,5 秒, 那全部總合所花的時間就是 5 + 10 + 7 + 5 = 27 秒. 若能同時間去抓取多個網頁, 所花費的時間 5,10,7,5 秒, 全部總合所花的時間是 10 秒.(花費最多時間的秒數) 於 JavaScript 可使用 AJAX 的 async(YAHOO.util.Connect.asyncRequest) 來達成, 於 PHP 可以用 CURL 來達成此 Multi-Threading 的效果. 官方文件: PHP: curl_multi_init 程式(async.php) View Raw Code? 0) // 每個 connect 要間隔多久 usleep($wait_usec); // 250000 = 0.25 sec } while ($running > 0); */ /* 此做法就可以避免掉 CPU loading 100% 的問題 */ // 參考自: http://www.hengss.com/xueyuan/sort0362/php/info-36963.html /* 此作法可能會發生無窮迴圈 do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); while ($active and $mrc == CURLM_OK) { if (curl_multi_select($mh) != -1) { do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); } } */ /* // 感謝 Ren 指點的作法. (需要在測試一下) // curl_multi_exec的返回值是用來返回多線程處裡時的錯誤，正常來說返回值是0，也就是說只用$mrc捕捉返回值當成判斷式的迴圈只會運行一次，而真的發生錯誤時，有拿$mrc判斷的都會變死迴圈。 // 而curl_multi_select的功能是curl發送請求後，在有回應前會一直處於等待狀態，所以不需要把它導入空迴圈，它就像是會自己做判斷&自己決定等待時間的sleep()。 */ do { curl_multi_exec($mh, $running); curl_multi_select($mh); } while ($running > 0); /* 讀取資料 */ foreach($handle as $i => $ch) { $content = curl_multi_getcontent($ch); $data[$i] = (curl_errno($ch) == 0) ? $content : false; } /* 移除 handle*/ foreach($handle as $ch) { curl_multi_remove_handle($mh, $ch); } curl_multi_close($mh); return $data; } ?> 使用 View Raw Code? example1, [1] => example2 ?> 測試 sleep.php # 看時間延長取得的效果 View Raw Code? View Raw Code? 5, [1] => 10, [2] => 7, [3] => 5 ?> http://blog.longwin.com.tw/2009/10/php-multi-thread-curl-2009/

Resolving Stubborn Wi-Fi Connection Problems in Mac OS X

A fair amount of Mac users have encountered long lasting Wi-Fi connection issues, whether it’s a dropping connection, a refusal to reconnect after waking from sleep, or any other number of oddities pertaining to wireless networking. Often these connection problems can be resolved with renewing a DHCP lease and changing the MTU size, but sometimes things are more stubborn and a wireless connection will continue to drop or throw unusual connection errors when waking from sleep. If you find yourself struggling with persistent wifi problems, try deleting all preference plist files associated with wireless settings in OS X:

Fix Stubborn Wi-Fi Problems by Deleting Preference Files

Before beginning, be sure to have the wi-fi password of your primary network handy. You will need it to rejoin the network.

• Pull down the Wi-Fi menu and turn Wi-FI OFF

• From any Finder window, hit Command+Shift+G to bring up Go To Folder, and enter the following path:
/Library/Preferences/SystemConfiguration/

• Locate the following files, copy them to the desktop for a backup, then delete them from the /SystemConfiguration/ folder:
com.apple.airport.preferences.plist
com.apple.network.identification.plist
NetworkInterfaces.plist
preferences.plist

• Empty the Trash and reboot the Mac
• Turn Wi-Fi back ON from the Wi-Fi menu, join your preferred network as usual

This process forces OS X to create all new preference files for wireless networking, which can be an effective troubleshooting strategy if the wi-fi problems began after upgrading versions of Mac OS X and even installing incremental system updates.

The wi-fi connection should now work as expected unless there’s a deeper problem, whether it’s a compatibility issue with the router (often resolved by this DHCP and MTU fix), a problem the router itself, or something as simple as network interference (here’s how to check connection strength and interference issues), which can often be resolved by reconfiguring a routers physical arrangement or changing it’s broadcast channel.

Let us know if this worked for you, or if you have any other helpful wifi troubleshooting tips. 

reference : http://osxdaily.com/2012/11/30/resolving-stubborn-wi-fi-connection-problems-in-mac-os-x/

Muyueh 李慕約 - Big Data Visualization 醫療、核四、漢堡資料視覺化

http://muyueh.com/42/

Plunker Helping developers make the web

http://plnkr.co/

MSSQL xml indexed

XML data type is usually used to store semi-structured data with great flexibility and query capabilities. It’s a good choice for developing platform agnostic applications to separate storage of complex data from processing at application layer, which understands the complex data relationship. To achieve optimal performance of querying XML data in SQL Server, extra steps need to be taken to ensure query access pattern matches how XML data is stored and indexed.

Here are 3 quick tips from query performance perspective based on real customer experience.

1.       Promoting key XML attribute/property to relational column. Promoting to relational column will get you to on-par performance with relational queries, the best you can get out of modern RDBMS. To achieve optimal performance and scalability with XML data, I strongly recommend you first consider this option. The idea is identifying hot elements or attributes that your workload queries on the most. Then add computed columns using user functions to promote the elements or attributes out of XML data. Note it does require application code change to modify queries to take advantage of the promoted columns. A simple example below is a table with “XMLDATA” that has a hot element “a1”. Here are steps to add a computed column to promote the element (Note adding the computed column is offline operation for the table). 

CREATE FUNCTION udf_get_a1 (@xData xml)

RETURNS varchar(30)

WITH SCHEMABINDING

BEGIN

   DECLARE @a1  varchar(30)

   SELECT @a1 = @xData.value('(/Dept[1]/orders/a1/text())[1]', 'varchar(30)')

   RETURN @a1

END

Go

ALTER TABLE Orders

ADD a1 AS dbo.udf_get_a1(XMLDATA) PERSISTED

Go

CREATE INDEX ind_a1 ON Orders(a1)

Go

Now the original query below

SELECT *

FROM Orders t

WHERE t.XMLDATA.exist(N'(/Dept[1]/orders/a1/text())[1][.="Company10001Special"]') = 1

Needs to be rewritten as

SELECT *

FROM Orders

WHERE a1='Company10001Special'

In a customer lab, we observed exponential performance gain by using this method (1000+ times faster!!). To caution against over-promotion, when you add too many promoted columns, the overhead of index change could reduce the performance gain.

2.       Typed or Untyped XML data? Typed XML means there is validating schema defined against the data. For untyped XML, the whole XML data is treated as a big string. To decide whether or not to define typed XML, you need to examine your XML query access pattern. Generally speaking, schema speeds up lookups since the data types of XML elements/attributes are known. But it would slow down INSERT due to overhead of validating new data. For UPDATE, it would benefit from faster lookups like SELECT, but incur same schema validation overhead like INSERT.

	Better off	Worse off
Typed (w/ schema)	Faster SELECT	Slower INSERT
Untyped (w/o schema)	Faster INSERT	Slower SELECT

3.       What XML indexes to add? Again depending on query access pattern, you may choose different XML indexes. Note XML index strategy is different than relational index. Popular DTA (Database Tuning Advisor) tool wouldn’t be able to recommend XML indexes. Fortunately there are only 3 types of secondary XML indexes to consider in addition to the required primary XML index.

Secondary XML index type	Benefits this type of queries
Path	XPath queries  with explicit path expression (XMLcol.exist ('/Dept/Orders/[@id="10001"]')= 1)
Value	XPath queries  with no explicit path expression but with value predicate (XMLcol.exist('//[@id="10001"]') = 1)
Property	XPath queries  with multiple row results

As straight forward as it sounds, you may find it difficult to examine your application and find out what appropriate indexes to add. The best way I recommend is to add all 3 types of XML indexes and test your workload to find out which XML indexes were used to determine the ones to keep (Be aware of rebuilding index affecting system availability). You can build XML indexes on either untyped or typed data. But you will get more gain with indexes on typed data. I see up to 50 times faster query response (SELECT queries) compared to plain untyped XML! However for DML queries, they could be significantly impacted by the overhead of XML index change plus schema validation. So again the key is to test your workload to find out if it makes sense to add XML indexes.

In conclusion, Promotion to relational column is the primary option you should consider when working with XML data. Whether or not to use XML schema and XML indexes, you need to be careful about your decision. Test your workload and identify the XQueries, which are critical to the overall performance. There is no DTA to help you, no query hints apply to XQueries either. Examine the query plans of those XQueries thoroughly to eliminate inefficiency.

reference : http://blogs.msdn.com/b/sqlcat/archive/2010/03/01/performance-tips-of-using-xml-data-in-sql-server.aspx

Basecamp is everyone's favorite project management app.