Google Analytics : 自定特殊統計 tag sample

https://developers.google.com/analytics/devguides/collection/analyticsjs/events

 

<script>
…….
ga(‘create’, ‘UA-xxxxxxxx-1’, ‘xxxx.com’);
ga(‘send’, ‘pageview’);
ga(‘send’, ‘event’, ‘分類瀏覽數’, ‘xxx’);
ga(‘send’, ‘event’, ‘分類瀏覽數’, ‘yyy’);
ga(‘send’, ‘event’, ‘小計瀏覽數’, ‘zzz’);
</script>

 

Hypertext Transfer Protocol — HTTP/1.1 – 這可是現今最偉大的 protocol 呀!

The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers
http://tools.ietf.org/html/rfc2616

Status Code Definitions
http://tools.ietf.org/html/rfc2616#section-10

204 No Content

The server has fulfilled the request but does not need to return an
entity-body, and might want to return updated metainformation. The
response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant.

If the client is a user agent, it SHOULD NOT change its document view
from that which caused the request to be sent. This response is
primarily intended to allow input for actions to take place without
causing a change to the user agent’s active document view, although
any new or updated metainformation SHOULD be applied to the document
currently in the user agent’s active view.

The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.

可以利用這點作一些事, 譬如記錄 user 的訪問, log 等等

PHP Coding Standards

參考: Mantis : http://www.mantisbt.org/guidelines.php

中文翻譯: http://www.ichiayi.com/wikipage/tech/mantis_coding

First, start off by reading the PHP Coding Standards document. I’ve deviated in a few places but just about everything in the document applies here as well.

Above all, write code that is easy to read and maintain. Comment blocks of code and functions at all times. And get on my case if I deviate too much as well!

Naming Variables
  • Use all lower case.
  • Use _ to separate words, e.g. $green_color_value
  • Use descriptive names (except loop variables).
  • Loop variables can be of the usual variety: $i, $j, $k, etc.
  • Count variables should follow the format $*_count, e.g. $bug_count
  • Global variables should be prefixed with g_
  • Temporary variables should be prefixed with t_
  • Parameters and variables passed from forms that have been cleaned of any special SQL chars (i.e. slashes) should be prefixed with c_
  • Uncleaned function parameters should be prefixed with p_
  • Uncleaned variables passed from forms should be prefixed with f_
  • Other variables are prefixed with v_, v2_, etc.
  • Never prefix with l_ or o_ or q_ (visually confusing)
  • $query and $result should be used for SQL query and results respectively
Naming Functions
  • Use all lower case.
  • Use _ to separate words, e.g. setup_page_breaks()
  • Keep functions to 5 words or less
  • Functions that print should be prefixed with print_.
  • Try to use prefixes to group functions (i.e., email_, news_, etc.)
Naming Classes
  • Use FirstLetterOfWordIsCaptilized style
  • Variables that are class objects should have the prefix coo_
Naming Files
  • Use all lower case.
  • Use _ to separate words, e.g. view_new_bugs_page.php
  • Use .php file extensions
  • Filenames must be less than 32 characters in length. This plays nice with older file systems like Mac OS.
  • Included files should be suffixed by _inc.php
SQL formatting
  • UPPERCASE all SQL keywords:
    $query = "SELECT *
    	FROM $g_mantis_bug_table
    	WHERE id='1'";
  • Always assign a query string to a variable. This makes code easier to debug when problems occur. Do not create the query in the call to the function.
  • Break up SQL queries over multiple lines to be easy to read.
General Formatting
  • Use TABS with a size of 4
  • Follow the table formatting of existing pages
  • Use <?php ?> for php delimiters.
  • Try not to print/echo HTML unless it’s short or in a function loop
  • Do not use the EOF construct
Miscellaneous
  • Don’t use the ?: construct except in very rare cases. It is confusing and has a lot of bug potential.
  • Avoid magic numbers. The only magic numbers in use should be 1 and 0 and their meaning should be obvious.
Page Guidelines
  • The first item should be the copyright notice
  • At the bottom will be the footer information and closing print_ functions.
Braces and Parantheses
  • Parantheses should be right after a function name, e.g. function() not function ()
  • Parantheses should have a space right after a keyword (if, while, for), e.g. for (…)
  • Formatting of braces is illustrating below. We use unmatched placing.
  • Arrays should be referenced with no spaces, e.g. $arr[‘index’] not $arr[ ‘index’ ]
    for (...) {
        blah
    }
    
    or
    
    if (...) {
        blah
    }
  • if … else blocks should be in this format:
    if (...) {
        blah1
    } else {
        blah2
    }
Comparisons
  • The NOT operator should be placed next to its operand. No spaces, e.g. !$value
  • Parentheses should be used for grouping, especially with multiple comparisons, e.g. if ( ( null == $val ) && ( null == $val2 ) )
Strings
  • Use spaces around the string concatenation operator, e.g. ‘str ‘ . $value . ‘ str2’;
  • Use ‘ instead of " if there are no variables or special characters.
Comments
  • Use the # symbol for line commenting, not //
  • Use /* */ for block commenting unless you nest /* */ comments. Generally, only use this during development.
  • Use @@@ followed by a brief message (BROKEN, TEMPORARY, etc) as a "look at this" indicator. Leaving your name next to is a good idea. This way critical items can easily be found.
Editor Features
  • Search and replace in multiple files
  • Goto line number
  • Syntax highlighting
  • Adjustable TAB spacing