Jaric – Chapter 3 – Career

由黑暗執行緒站長 Jeffrey 親自操刀、費時數月完成的邊做邊學 jQuery 系列影片(含文章)終於完整上線，一共 15 集精闢入裡的 jQuery 觀念解說與精彩範例 (錄影的時間總共 126 分 15 秒)，絕對能讓原本就會一些 JavaScript 的開發人員快速上手 jQuery，甚至於我認為已經在使用 jQuery 的開發人員更應該看一遍這些影片與文章，也許能帶給你許多意外的收穫喔！

工欲善其事，必先利其器！在開始學習之前，先告訴各位一個不可或缺的學習工具：Mini jQuery Lab ！

若在學習 jQuery 的過程中需要練習編寫 jQuery 程式碼時，可以利用 Mini jQuery Lab 進行線上實驗，這讓任何人不需要在本機編輯網頁就能測試 jQuery 的效果，非常的方便！

短短兩個小時的精彩課程絕對不可錯過，以下是所有課程的連結：

read more »

php 的 相關framework 在之前比較有研究的，就是 Codeigniter，

特別是在 Rasmus 對各家Framework 做過 benchmark之後，更是對於 Codeigniter 信心倍增。

至於 symfony，在最初的 survey 時有看過，不過當時覺得 symfony的輕巧性，完全比不上 Codeigniter。

最近因為某些因素，恰巧有機會可以讓我好好重新認識一次 symfony 。

赫然發現，symfony 做到的，遠遠超過我對於 PHP framework的期待。

Ten reasons why Symfony rocks – Part 1

Ten reasons why Symfony rocks – Part 2

Codeigniter & Symfony 都是值得花時間好好了解的 framework。

–

在深入了解一個東西之前，絕對沒有資格說不喜歡。

Chunghe 推薦的 xpath toturial

http://www.zvon.org/xxl/XPathTutorial/Output/example1.html

http://www.slideshare.net/cheilmann/open-hack-london-introduction-to-yql?type=presentation
 select * from flickr.photos.info where photo_id in (select id from flickr.photos.search where woe_id in (select woeid from geo.places where text = ‘london,uk’) and license=4)
 http://github.com/spullara/yql-tables/tree/master 這個好阿

read more »

在大陸想連無名、youtube，又害怕使用proxy會被敲門的捧友有福了:D

根據友人Ronald在大陸(東莞)的實際測試，安裝使用之後，可以連到無名小站、Youtube。

read more »

From

Interactive session from MySQL Camp I:

Specific Query Performance Tips (see also database design tips for tips on indexes):

1. Use EXPLAIN to profile the query execution plan
2. Use Slow Query Log (always have it on!)
3. Don’t use DISTINCT when you have or could use GROUP BY
4. Insert performance
   1. Batch INSERT and REPLACE
   2. Use LOAD DATA instead of INSERT
5. LIMIT m,n may not be as fast as it sounds
6. Don’t use ORDER BY RAND() if you have > ~2K records
7. Use SQL_NO_CACHE when you are SELECTing frequently updated data or large sets of data
8. Avoid wildcards at the start of LIKE queries
9. Avoid correlated subqueries and in select and where clause (try to avoid in)
10. No calculated comparisons — isolate indexed columns
11. ORDER BY and LIMIT work best with equalities and covered indexes
12. Separate text/blobs from metadata, don’t put text/blobs in results if you don’t need them
13. Derived tables (subqueries in the FROM clause) can be useful for retrieving BLOBs without sorting them. (Self-join can speed up a query if 1st part finds the IDs and uses then to fetch the rest)
14. ALTER TABLE…ORDER BY can take data sorted chronologically and re-order it by a different field — this can make queries on that field run faster (maybe this goes in indexing?)
15. Know when to split a complex query and join smaller ones
16. Delete small amounts at a time if you can
17. Make similar queries consistent so cache is used
18. Have good SQL query standards
19. Don’t use deprecated features
20. Turning OR on multiple index fields (<5.0) into UNION may speed things up (with LIMIT), after 5.0 the index_merge should pick stuff up.
21. Don’t use COUNT * on Innodb tables for every search, do it a few times and/or summary tables, or if you need it for the total # of rows, use SQL_CALC_FOUND_ROWS and SELECT FOUND_ROWS()
22. Use INSERT … ON DUPLICATE KEY update (INSERT IGNORE) to avoid having to SELECT
23. use groupwise maximum instead of subqueries

Scaling Performance Tips:

1. Use benchmarking
2. isolate workloads don’t let administrative work interfere with customer performance. (ie backups)
3. Debugging sucks, testing rocks!
4. As your data grows, indexing may change (cardinality and selectivity change). Structuring may want to change. Make your schema as modular as your code. Make your code able to scale. Plan and embrace change, and get developers to do the same.

Network Performance Tips:

1. Minimize traffic by fetching only what you need.
   1. Paging/chunked data retrieval to limit
   2. Don’t use SELECT *
   3. Be wary of lots of small quick queries if a longer query can be more efficient
2. Use multi_query if appropriate to reduce round-trips
3. Use stored procedures to avoid bandwidth wastage

OS Performance Tips:

1. Use proper data partitions
   1. For Cluster. Start thinking about Cluster *before* you need them
2. Keep the database host as clean as possible. Do you really need a windowing system on that server?
3. Utilize the strengths of the OS
4. pare down cron scripts
5. create a test environment
6. source control schema and config files
7. for LVM innodb backups, restore to a different instance of MySQL so Innodb can roll forward
8. partition appropriately
9. partition your database when you have real data — do not assume you know your dataset until you have real data

MySQL Server Overall Tips:

1. innodb_flush_commit=0 can help slave lag
2. Optimize for data types, use consistent data types. Use PROCEDURE ANALYSE() to help determine the smallest data type for your needs.
3. use optimistic locking, not pessimistic locking. try to use shared lock, not exclusive lock. share mode vs. FOR UPDATE
4. if you can, compress text/blobs
5. compress static data
6. don’t back up static data as often
7. enable and increase the query and buffer caches if appropriate
8. config params — http://docs.cellblue.nl/2007/03/17/easy-mysql-performance-tweaks/ is a good reference
9. Config variables & tips:
   1. use one of the supplied config files
   2. key_buffer, unix cache (leave some RAM free), per-connection variables, innodb memory variables
   3. be aware of global vs. per-connection variables
   4. check SHOW STATUS and SHOW VARIABLES (GLOBAL|SESSION in 5.0 and up)
   5. be aware of swapping esp. with Linux, “swappiness” (bypass OS filecache for innodb data files, innodb_flush_method=O_DIRECT if possible (this is also OS specific))
   6. defragment tables, rebuild indexes, do table maintenance
   7. If you use innodb_flush_txn_commit=1, use a battery-backed hardware cache write controller
   8. more RAM is good so faster disk speed
   9. use 64-bit architectures
10. –skip-name-resolve
11. increase myisam_sort_buffer_size to optimize large inserts (this is a per-connection variable)
12. look up memory tuning parameter for on-insert caching
13. increase temp table size in a data warehousing environment (default is 32Mb) so it doesn’t write to disk (also constrained by max_heap_table_size, default 16Mb)
14. Run in SQL_MODE=STRICT to help identify warnings
15. /tmp dir on battery-backed write cache
16. consider battery-backed RAM for innodb logfiles
17. use –safe-updates for client
18. Redundant data is redundant

Storage Engine Performance Tips:

1. InnoDB ALWAYS keeps the primary key as part of each index, so do not make the primary key very large
2. Utilize different storage engines on master/slave ie, if you need fulltext indexing on a table.
3. BLACKHOLE engine and replication is much faster than FEDERATED tables for things like logs.
4. Know your storage engines and what performs best for your needs, know that different ones exist.
   1. ie, use MERGE tables ARCHIVE tables for logs
   2. Archive old data — don’t be a pack-rat! 2 common engines for this are ARCHIVE tables and MERGE tables
5. use row-level instead of table-level locking for OLTP workloads
6. try out a few schemas and storage engines in your test environment before picking one.

Database Design Performance Tips:

1. Design sane query schemas. don’t be afraid of table joins, often they are faster than denormalization
2. Don’t use boolean flags
3. Use Indexes
4. Don’t Index Everything
5. Do not duplicate indexes
6. Do not use large columns in indexes if the ratio of SELECTs:INSERTs is low.
7. be careful of redundant columns in an index or across indexes
8. Use a clever key and ORDER BY instead of MAX
9. Normalize first, and denormalize where appropriate.
10. Databases are not spreadsheets, even though Access really really looks like one. Then again, Access isn’t a real database
11. use INET_ATON and INET_NTOA for IP addresses, not char or varchar
12. make it a habit to REVERSE() email addresses, so you can easily search domains (this will help avoid wildcards at the start of LIKE queries if you want to find everyone whose e-mail is in a certain domain)
13. A NULL data type can take more room to store than NOT NULL
14. Choose appropriate character sets & collations — UTF16 will store each character in 2 bytes, whether it needs it or not, latin1 is faster than UTF8.
15. Use Triggers wisely
16. use min_rows and max_rows to specify approximate data size so space can be pre-allocated and reference points can be calculated.
17. Use HASH indexing for indexing across columns with similar data prefixes
18. Use myisam_pack_keys for int data
19. be able to change your schema without ruining functionality of your code
20. segregate tables/databases that benefit from different configuration variables

Other:

1. Hire a MySQL ™ Certified DBA
2. Know that there are many consulting companies out there that can help, as well as MySQL’s Professional Services.
3. Read and post to MySQL Planet at http://www.planetmysql.org
4. Attend the yearly MySQL Conference and Expo or other conferences with MySQL tracks (link to the conference here)
5. Support your local User Group (link to forge page w/user groups here)

1. Don’t use foreach loop as long as you can avoid it, for loops are faster than any other looping constructs.
   When it comes to various looping constructs and control statements it could differ based on case to case. Please refer http://www.phpbench.com/ by Chris Vincent, he has done remarkable job by providing detailed benchmarks with various combinations. 
2. echo is faster than print. As echo is one of the language construct which don’t return anything while print will return 0 or 1 based on success or failure. 
3. include_once is costlier then include statement. As it will have to look whether class definition you are trying to include is already included or not? 
4. Always use single quotes for long strings and not the double quotes. Because for double quotes php will try to search and evaluate $vars found in that string. So in that case echo ‘It was really a long story to finish ‘. $name is faster then echo “It was really a long story to finish $name”.
   But then echo ‘It was really a long story to finish’ , $name can be faster then first one too, as it don’t required any string manipulation from php and just outputting all arguments to screen. This matters most when we need to do lots of text processing or html to be generate from our application/scripts.
5. Magic methods like __string,__set,__get can slow down things. But it’s okey as it can give more clarity in our code. Personally I like to use __set and __get as it let me stay away from getter and setter methods. __autoload is expensive and if you don’t really need it then don’t use them. 
6. Don’t use for($i=0; $i<=count($arrPerson); $i++) {..} instead use,
   for($i=0,$total = count($arrPerson); $i<$total; $i++) {..}. The previous one will call count function for each iteration of the loop while the second one will call count function just once. 
7. If you can declare a method as static then let it be static, they are faster around 33% then member functions. 
8. $arrPerson[‘name'] is faster than $arrPerson[name]. So try using single quotes for associative arrays. 
9. If you can solve your any problem without using regular expressions, then don’t use them. Regex functions are slower than their php counterparts. For example use str_replace instead of preg_replace if it can do serve your purpose. 
10. If you will provide array as any argument for str_replace it will be faster instead of giving string inputs for single search and replacement.
    Slow:
    str_replace( ‘search’, ‘replace’,$strAssay);
    Fast:
    str_replace(array(‘search’),array(‘replace’),$strAssay);
11. Try to minimize the relative paths for file include. For relative path includes it will search into default include path then current directory and so on.. So file search in that case can take long time. Instead specify WEB_ROOT constant which will be physical path of your web directory and which could be defined by following way.
    define(’WEB_ROOT’,str_replace(array(’\’),array(’/’),dirname(__FILE__)) . ‘/’);
12. Identical operator (===) is faster than (==) operator as identical operator will include type checking also. So If( 1 == ‘1′) will return true, If( 0 == ”) will return true while if you use identical operator both this conditions If( 1 === ‘1′) and If(0 === ”) will return false. So it is recommended to use identical operator when you are going to use some boolean variables for deciding the flow/control of your application. 
13. Don’t use short tags <? and try using <?php, it can heart you when you go an deploy your application on some other servers. 
14. Don’t use or relay on register_globals or magic quotes and read and configure your php.ini settings carefully. You can read comments over parameters and can set those parameters based on your server setup and application requirement for optimum performance. 
15. Disable or comment extensions you are not going to use ever from php.ini

In addition to all this develop or follow coding standard for variables, classes, methods and file naming. It will reduce development time due to certainty. Always use proper variable names there is nothing wrong having variable name like $blnIsVARAdminLoggedIn. Proper naming convention will help you and your team members while it comes to maintenance part of the project. Writing comments for not understandable variable or method names would be less helpful. Use editors with auto-complete feature like Eclipse, Aptana which would reduce the hard-work for typing long variable or method names.

Related Material: PHP Coding Standard by Fredrik Kristiansen / DB Medialab

http://pear.php.net/manual/en/package.php.php-codesniffer.intro.php

pecl install php_codesniffer

使用方法 ： 

phpcs /path/to/code/myfile.php

FILE: /path/to/code/myfile.php
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
  2 | ERROR | Missing file doc comment
 20 | ERROR | PHP keywords must be lowercase; expected "false" but found "FALSE"
 47 | ERROR | Line not indented correctly; expected 4 spaces but found 1
 51 | ERROR | Missing function doc comment
 88 | ERROR | Line not indented correctly; expected 9 spaces but found 6
--------------------------------------------------------------------------------

phpcs /path/to/code

FILE: /path/to/code/myfile.php
--------------------------------------------------------------------------------
FOUND 5 ERROR(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
  2 | ERROR | Missing file doc comment
 20 | ERROR | PHP keywords must be lowercase; expected "false" but found "FALSE"
 47 | ERROR | Line not indented correctly; expected 4 spaces but found 1
 51 | ERROR | Missing function doc comment
 88 | ERROR | Line not indented correctly; expected 9 spaces but found 6
--------------------------------------------------------------------------------

FILE: /path/to/code/yourfile.php
--------------------------------------------------------------------------------
FOUND 1 ERROR(S) AND 1 WARNING(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
 21 | ERROR   | PHP keywords must be lowercase; expected "false" but found
    |         | "FALSE"
 21 | WARNING | Equals sign not aligned with surrounding assignments
--------------------------------------------------------------------------------

http://0rz.tw/DTZDp

Cite CRM
vtiger CRM
Sugar CRM