分析 access_log

取得前十名 access 最多的 IP 位址 

cat access_log|awk '{print $1}'|sort|uniq -c|sort -nr|head -10

取得前十名 access 最多的網頁 

cat access_log|awk '{print $11}'|sort|uniq -c|sort -nr|head -10

取得前十名下載流量最大的 zip 檔案 

cat access.log |awk '($7~/\.zip/){print $10 " " $1 " " $4 " " $7}'|sort -nr|head -10

取得前十名 Loading 最大的頁面 (大於60秒的 php 頁面) 

cat access_log |awk '($NF > 60 && $7~/\.php/){print $7}'|sort -n|uniq -c|sort -nr|head -10

取得前十名 User access 最久的頁面 

cat access_log |awk  '($7~/\.php/){print $NF " " $1 " " $4 " " $7}'|sort -nr|head -10

取得 access log 平均流量 (GB) 

cat access_log |awk '{sum+=$10} END {print sum/1024/1024/1024}'

取得所有 404 Link 

 awk '($9 ~/404/)' access_log | awk '{print $9,$7}' | sort

取得所有 access code 的 stats 數量 

cat access_log | awk -F' ' '$9 == "400" || $9 == "404" || $9 == "408" || $9 == "499" || $9 == "500" || $9 =="502" || $9 =="504" {print $9}' | sort | uniq -c | more

About ASO

https://blog.sensortower.com/blog/2013/10/02/the-definitive-3-step-process-for-selecting-keywords-that-get-your-ios-app-ranked-and-downloaded/

AARRR Model

什么是AARRR模型

AARRR是Acquisition、Activation、Retention、Revenue、Refer，这个五个单词的所写，分别对应这一款移动应用生命周期中的5个重要环节。下面我们来简单讲解一下AARRR模型中每个项目的意义。

获取用户（Acquisition）
运营一款移动应用的第一步，毫无疑问是获取用户，也就是大家通常所说的推广。如果没有用户，就谈不上运营。

提高活跃度（Activation）
很多用户可能是通过终端预置（刷机）、广告等不同的渠道进入应用的，这些用户是被动地进入应用的。如何把他们转化为活跃用户，是运营者面临的第一个问题。
当然，这里面一个重要的因素是推广渠道的质量。差的推广渠道带来的是大量的一次性用户，也就是那种启动一次，但是再也不会使用的那种用户。严格意义上说，这种不能算是真正的用户。好的推广渠道往往是有针对性地圈定了目标人群，他们带来的用户和应用设计时设定的目标人群有很大吻合度，这样的用户通常比较容易成为活跃用户。另外，挑选推广渠道的时候一定要先分析自己应用的特性（例如是否小众应用）以及目标人群。对别人来说是个好的推广渠道，对你却不一定合适。
另一个重要的因素是产品本身是否能在最初使用的几十秒钟内抓住用户。再有内涵的应用，如果给人的第一印象不好，也会“相亲”失败，成为“嫁不出去的老大难”。
此外，还有些应用会通过体验良好的新手教程来吸引新用户，这在游戏行业尤其突出。

提高留存率（Retention）
有些应用在解决了活跃度的问题以后，又发现了另一个问题：“用户来得快、走得也快”。有时候我们也说是这款应用没有用户粘性。
我们都知道，通常保留一个老客户的成本要远远低于获取一个新客户的成本。所以狗熊掰玉米（拿一个、丢一个）的情况是应用运营的大忌。但是很多应用确实并不清楚用户是在什么时间流失的，于是一方面他们不断地开拓新用户，另一方面又不断地有大量用户流失。
解决这个问题首先需要通过日留存率、周留存率、月留存率等指标监控应用的用户流失情况，并采取相应的手段在用户流失之前，激励这些用户继续使用应用。
留存率跟应用的类型也有很大关系。通常来说，工具类应用的首月留存率可能普遍比游戏类的首月流存率要高。

获取收入（Revenue）
获取收入其实是应用运营最核心的一块。极少有人开发一款应用只是纯粹出于兴趣，绝大多数开发者最关心的就是收入。即使是免费应用，也应该有其盈利的模式。
收入有很多种来源，主要的有三种：付费应用、应用内付费、以及广告。付费应用在国内的接受程度很低，包括Google Play Store在中国也只推免费应用。在国内，广告是大部分开发者的收入来源，而应用内付费目前在游戏行业应用比较多。
无论是以上哪一种，收入都直接或间接来自用户。所以，前面所提的提高活跃度、提高留存率，对获取收入来说，是必需的基础。用户基数大了，收入才有可能上量。

自传播（Refer）
以前的运营模型到第四个层次就结束了，但是社交网络的兴起，使得运营增加了一个方面，就是基于社交网络的病毒式传播，这已经成为获取用户的一个新途径。这个方式的成本很低，而且效果有可能非常好；唯一的前提是产品自身要足够好，有很好的口碑。
从自传播到再次获取新用户，应用运营形成了一个螺旋式上升的轨道。而那些优秀的应用就很好地利用了这个轨道，不断扩大自己的用户群体。
通过上述这个AARRR模型，我们看到获取用户（推广）只是整个应用运营中的第一步，好戏都还在后头。如果只看推广，不重视运管中的其它几个层次，任由用户自生自灭，那么应用的前景必定是暗淡的。

如何使用AARRR模型
通常大家在推广应用时，头痛的是后台统计的激活量比渠道提供的下载量小很多。但是前几天，有一位朋友找我咨询，说他们公司的一款App来自某个渠道的激活量突然猛增。但是他查了在那个渠道（是家应用市场）上的下载量，并没有明显的变化。于是他非常困惑，问我有没有办法帮他查到原因。
少了多了都会让人头痛——因为数据出现异常，通常就说明有某个环节出了问题。但是光看一个激活量和一个下载量，并不能揭示问题的根本原因。尤其是当我们已经了解了移动应用运营模型时，我们更需要了解在AARRR的每个环节中，我们应当关注什么样的数据，什么样的数据表现才是正常的——简单来说，只知道AARRR还不够，还要会用才行。

一、获取用户（Acquisition）
这个阶段，最初大家最关心的数据是下载量。到今天，一些媒体的报道中也还经常用下载量来衡量一个应用的用户规模和是否成功。不过，下载了应用不等于一定会安装，安装了应用也不等于一定使用了该应用。所以很快激活量成为了这个层次中大家最关心的数据，甚至是有些推广人员唯一关注的数据。通常激活量（即新增用户数量）的定义是新增的启动了该应用的独立设备的个数。从字面上看激活量似乎更应该是第二层Activation的指标，但是因为下载量、安装量这些数据都比较虚，不能真实反映用户是否已经被获取。所以大家都要看激活，这才是真正获取到了新的用户。
另一个非常重要的数据，就是分渠道统计的激活量。因为在渠道推广时，很多应用开发者选择了付费推广。结算的时候，自然要了解在某个渠道有多少真正激活的用户。即使没有付费关系，开发者也需要知道哪个渠道是最有效果的。
但是站在更高的高度看，CAC（用户获取成本 Customer Acquisition Cost）才是最需要去关注的数据。目前行业里有种粗略的说法，每个Android用户的获取成本大约在4元左右，而iOS用户大约在8元以上。当然，应用市场下载、手机预置、广告等各种不同的渠道的获取成本是完全不同的。这里面有个性价比的问题，有些渠道的获取成本比较高，但是用户质量也比较高（什么样的叫质量高，后面会有说明）。

二、提高活跃度（Activation）
看到活跃度，大家首先会想到的指标是DAU（日活跃用户）、MAU（月活跃用户）。这两个数据基本上说明了应用当前的用户群规模，在网络游戏行业这是两个运营人员必看的指标。通常活跃用户是指在指定周期内有启动的用户。但是启动是否真的等于活跃呢？如果在指定周期内只启动了一次，而且时间很短，这样的用户活跃度其实并不高（当然对某些特殊的应用来说可能算高，例如用来记录女性生理周期的应用，一月启动一次就够了）。所以其实还要看另两个指标：每次启动平均使用时长和每个用户每日平均启动次数。当这两个指标都处于上涨趋势时，可以肯定应用的用户活跃度在增加。
针对使用时长和启动次数的渠道统计同样很重要。我们把它们称为渠道的质量数据，如果某个渠道上来的用户，这两个指标很差，那么在这个渠道上投入太多是没有意义的。最典型的就是水货刷机的用户，很多预置的应用都是在刷机完成时被激活的。针对这种被动激活的用户，可以看另一个指标，叫一次性启动用户数量，也就是迄今为止只启动过一次的用户的数量。
除了渠道，另一个和活跃度相关的分析维度是版本。各个版本的使用时长和启动次数也会有差异。对产品经理来说，分析不同版本的活跃度差异有助于不断改进应用。
此外跟活跃度相关的，还有日活跃率、周活跃率、月活跃率这些指标。当然活跃率和应用的类别是很有关系的，比如桌面、省电类的应用的活跃率就比字典类的应用高。

三、提高留存率（Retention）
下载和安装——使用——卸载或者遗忘，这是用户在每个应用中的生命周期。成功的应用就是那些能尽量延长用户的生命周期，最大化用户在此生命周期内的价值（下一节会谈到生命周期价值这个话题）的应用。
对于大部分应用，应该关心的是1-Day Retention 和7-Day Retention。这里我之所以用英文，是因为其中文翻译不统一，容易引起歧义。1-Day Retention通常翻译为首日留存率，其实这个“首日”并不是指应用被安装使用的第一天（假设日期为D），而是D+1日，即安装使用的第二天。因为安装使用的第一天没有留存率这个概念（有的话，只能是100%）。到了第二天，前一天安装使用的用户中还有多少百分比的人还在启动使用这款应用，这就是1-Day Retention。因为是第二天，所以有些文章中也叫“次日留存率”。同样的，7-Day Retention是在D+7日启动使用这款应用的占D日首次安装使用这款应用的用户总数的百分比。通常用户新安装使用后的前几天是流失比例最大的时期（关于用户留存的细节，请参考我们同事的另一篇博客《读懂你的用户留存》）。所以这两个指标在留存率分析是最重要的。曾经有游戏行业的行家指出，如果想成为一款成功的游戏，1-Day Retention要达到40%， 7-Day Retention要达到 20%。
有些应用不是需要每日启动的，那样的话可以看周留存率、月留存率等指标，会更有意义。 留存率也是检验渠道的用户质量的重要指标，如果同一个应用的某个渠道的首日留存率比其它渠道低很多，那么这个渠道的质量是比较差的。

四、获取收入（Revenue）
关于收入，大家最耳熟能详的指标就是ARPU（平均每用户收入）值。对应的比较少提的还有个指标叫ARPPU（平均每付费用户收入）。前几天，@吴刚在微博里贴图比较二战风云的ARPU值时就注明了是周付费用户ARPU（所以其实是ARPPU）。但是很多人误读了以为是六十多元的周ARPU值，就会让他们对Android游戏产生过分的乐观。
是不是ARPPU高，ARPU就一定会高呢？答案是不一定。因为其中还有个指标是付费用户比例，也就是付费用户在全部用户中所占的比例。如果付费用户比例较低，那么那些收入摊到所有用户身上的平均值就低了。通常来说，如果某个游戏为了提高ARPPU，提高了虚拟道具的价格，那么付费用户比例就会相应地降低。找到一个ARPPU和付费用户比例的平衡点，才能最大化收入。
但是收入并不是最重要的，利润才是。如何最大化利润呢？利润最简化的计算公式是：利润=收入-成本。首先我们看一下成本，我们在上一篇中提到过CAC（用户获取成本）。除此之外，还有应用本身的开发成本、服务器硬件和带宽成本以及运营成本等等。不过在用户量很大的情况下，CAC会成为最主要的成本，而其它成本不在一个数量级，所以我们在后续讨论中只考虑CAC。
那么收入如何计算？ ARPU是一个和时间段相关的指标（通常讲的最多是每月的ARPU值），还不能完全和CAC对应，因为CAC和时间段并没有直接关系。所以我们还要多看一个指标：LTV（生命周期价值）。用户的生命周期是指一个用户从第一次启动应用，到最后一次启动应用之间的周期。LTV就是某个用户在生命周期内为该应用创造的收入总计，可以看成是一个长期累计的ARPU值。每个用户平均的LTV = 每月ARPU * 用户按月计的平均生命周期。
LTV – CAC的差值，就可以视为该应用从每个用户身上获取的利润。所以最大化利润，就变成如何在降低CAC的同时，提高LTV，使得这两者之间的差值最大化。更进一步的，对不同渠道来源用户做断代分析，根据他们不同的CAC和LTV，就可以推导出不同渠道来源的利润率差异。

五、自传播（Refer）

自传播，或者说病毒式营销，是最近十年才被广泛研究的营销方法。虽然大家都听过一些病毒式营销的经典案例，但是要说怎样量化评估其效果，却很少有人知道K因子(K-factor)这个衡量指标。其实K因子这个术语并非起源于市场学或软件业，而是来源于传染病学——对，就是研究真正的病毒传播的科学。K因子量化了感染的概率，即一个已经感染了病毒的宿主所能接触到的所有宿主中，会有多少宿主被其传染上病毒。
K因子的计算公式不算复杂，K = (每个用户向他的朋友们发出的邀请的数量) * (接收到邀请的人转化为新用户的转化率)。假设平均每个用户会向20个朋友发出邀请，而平均的转化率为10%的话，K =20*10%=2。这个结果还算是不错的效果——当K>1时，用户群就会象滚雪球一样增大。如果K<1的话，那么用户群到某个规模时就会停止通过自传播增长。
很遗憾的是，即使是社交类的移动应用，目前K因子大于1的也很少。所以绝大部分移动应用还不能完全依赖于自传播，还必须和其它营销方式结合。但是从产品设计阶段就加入有利于自传播的功能，还是有必要的，毕竟这种免费的推广方式可以部分地减少CAC。

以上我们列举了在应用推广运营各个层次（各个阶段）需要关注的一些指标。在整个AARRR模型中，这些量化指标都具有很重要的地位，而且很多指标的影响力是跨多个层次的。及时准确地获取这些指标的具体数据，对于应用的成功运营是必不可少的。

Facebook 權限審核

紀錄一下，這兩篇都滿詳細的

http://marcoyan0814.blogspot.tw/2014/05/2014-facebook-application-api-fb-api.html

http://blog.winwu.today/2015/03/facebook-graph-api-v2x-taggable-friends.html


後續成果，第一次送審隔天被打回來說上傳的 iOS 檔案不合法，一定要照FB的方法取得的 app 檔送審才能，重新送審後隔天就過了。

值得注意的是，我送審的 App 有 iOS/Android 版，都已有線上版本但打卡功能都已失效，這次送審我只有送 iOS 版，神奇的是 FB 竟然沒檢查安卓版就讓我過了，是他好心還是真的漏了我也不知道。

App Deeplink

 User 點擊了一個短網址，如果這個裝置有裝你的 App 就直接開啟 App 某頁並導向某一頁，若是尚未安裝就開啟 App Store。從 ASO 角度來看這功能非常的重要。

App to App 用內建的 Url Scheme 就可以簡單做到了

Web To App 需要一些小技巧了，下面這網站教的方法還滿簡單實現的。

http://support.mobileapptracking.com/entries/25539969-How-to-Deeplink-to-Your-Mobile-App-from-Your-Website


－－－－－－－更新

iOS 9 在 App linker 做了滿多的改變， URL Scheme 可能沒法像之前那麼容易使用了，但多了許多方式讓你直接連進 App，請參考 WWDC 的 SESSION 509 講得滿清楚的

使用自訂 xib 搭配 Autolayout

先記下來，這篇很重要

http://sebastiancelis.com/2014/06/12/using-xibs-layout-custom-views/

使用 innodb_file_per_table 解決 ibdata1 單一且過大

參考這裡


使用 mysql 配合 innodb 引擎在預設的情況下所有的資料都會儲存在 ibdata1

用久了這個檔案會很大，比較好的作法是把每個資料庫的 ibdata 各別儲存。

先備份全部資料庫

mysqldump -u root -p --all-databases > /home/backup/all.sql

找到 my.cnf 或是 my.ini 並加入 innodb_file_per_table=1
以我使用 EC2 自架 mysql 來說是 /etc/my.cnf
重啟資料庫  #service mysqld restart
進入資料庫

#mysql -uroot -ppassword

檢查是否開啟分類儲存功能

mysql> show variables like '%per_table%';

若已開啟會長得像

+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_file_per_table | ON    |
+-----------------------+-------+

再來把 ibdata1 以及 ib_logfile* 刪掉，此時進入資料庫應該就是空空的了
在還原之前最好先停止網路服務，我曾經還原到一半 ec2 就斷線當機給我看

#service httpd stop

還原

mysql -uroot -p < /home/backup/all.sql

啟用 innodb_file_per_table 後，當刪除資料表(DROP TABLE)、清空資料表(TRUNCATE TABLE)，佔用的空見會自動縮減。刪除資料表資料(DELETE)，則執行 OPTIMIZE TABLE 來縮減資料表空間。

OPTIMIZE TABLE 資料表名稱

最後補充一下使用別人整理的 innodb_file_per_table 的好處

1. 如果使用軟鏈結將大表分配到不同的分區上，易於管理資料文件
2. 易於監控解决IO資源使用的问题
3. 易於修復和恢復損壞的資料
    3.1 相互獨立，不影響其他innodb表
    3.2 導出導入針對單一table，而不是整個共享table
4. 解決單一文件大小的限制
5. 對於大量的delete操作，更易回收磁碟空間
6. 碎片較少，易於整理optimize table
7. 易於安全檢查
8. 易於備份

Apple Watch Human Interface Guidelines 隨手記

Apple Watch Human Interface Guidelines


Interface Style:

• Hierarchical. This style matches the navigation style in iOS and is best suited for apps with hierarchical information. In a hierarchical app, users navigate by making one choice per screen until they reach their destination. To navigate to another destination, users must retrace some or all of their steps and make different choices.
  A hierarchical model is typically better than a flat, paginated navigation model for more complex app interactions.
• Page-based. A paginated interface lets the user navigate between pages of content by swiping horizontally. A page-based interface is best suited for apps with simple data models where the data on each page is not directly tied to the data on the other pages.
  A dot indicator at the bottom of each page shows the user’s place in the set. Keep the total number of pages as small as possible to simplify navigation.

註：二擇一，避免混用

Glances are:

• Template-based. There are separate templates for the upper and lower portions of the Glance screen. Use Xcode to pick the templates you want and then design your content to those specifications.
• Not scrollable. All content must fit on a single screen.
• Read-only. Tapping anywhere on the glance opens the app.
• Optional. Not all apps need a Glance, and users can select which Glances to display.

註： Glances 非必要，可套版，不可滾動



Notification:

Be sensitive to the frequency with which you send notifications to users. Users might perceive a frequent notifications as annoying and disable notifications for your app on Apple Watch. Always make sure notifications are relevant to what the user wants.


註：有分 short look & long look，版面制式化，小心使用


Layout:


兩種SIZE

Color and Typography

Use black for your app’s background color. A black background blends seamlessly with the device bezel and maintains the illusion of there being no screen edges. Avoid bright background colors in your interface.

Use your app’s key color for branding or status. Every app defines a key color. The system uses this key color for the title string in the upper-left corner of the screen and in notification interfaces to highlight your app name or other key information. You should similarly use the key color as part of the branding of your app.

Use high contrast colors for text. High contrast colors make text more legible.

Use the built-in text styles whenever possible. The built-in styles automatically support Dynamic Type and were designed to look good on Apple Watch.

Prefer the use of a single font throughout your app. Apps can use an additional font for branding purposes, but use that extra font sparingly. Mixing many different fonts can make your app seem fragmented and sloppy. Use the UIFont text styles API to define different areas of text according to semantic usage, such as body or headline.


註：顏色採用高對比，建議使用黑色背景，字型盡量單一且使用內建字型。


Table:


Use row types consistently. You might create different row types to implement your content, headers, and footers. Be consistent in your use of those rows.

Avoid mixing rows with dramatically different types of content. When displaying content, be consistent with the row type you use to display that content. Use other row types only as section breaks or to organize the content rows. Using the same row type for content ensures that rows are sized consistently and are easier to navigate.

Limit the number of table rows displayed at one time. Tables with more than twenty rows of content become cumbersome to scroll through. Display only the subset of rows that are immediately relevant and give the user the option to load more rows.

註：單一cell，避免太多列，超迥10列給user "讀取更多" 的 button.

Button:

Create buttons that span the width of the screen. The creation of full-width buttons is strongly encouraged. If you must put more than one button in the same horizontal space, limit the total number of buttons to two.

Try to match button heights whenever possible. If you have multiple buttons onscreen together, use the same height for each. Buttons

註：寬盡量滿版，最多塞二個button

Image:

Create all image assets as @2x resources. There is no need to create non Retina images.

Dates and Timers:

Use a date object whenever you want to display the current day or time.
Always use a timer label to implement a precise countdown or count-up timer.

註：使用內建的 Dates Label 和 Timer Label


ICON:

iOS : Audio Trimming

最近在研究 iOS 音樂剪輯／播放這一塊，紀錄一下

Trim :

http://stackoverflow.com/questions/13097331/unable-to-trim-a-video-using-avassetexportsession

http://stackoverflow.com/questions/9698787/ios-audio-trimming

http://stackoverflow.com/questions/21463250/cocoa-avasset-loaded-from-file-has-0-tracks

Export Mediaitem to local file:

http://stackoverflow.com/questions/13925148/exporting-video-from-users-itunes-library

http://stackoverflow.com/questions/4238219/trim-audio-with-ios

xcode plugins

分享咱家技術長推的兩個好用的 XCode Plugins


1. FuzzyAutocompletePlugin

https://github.com/FuzzyAutocomplete/FuzzyAutocompletePlugin/releases

這是一個非常懶惰的Plugins, 原本在寫程式時要依序打 NSStringFromCGRect, Xcdoe 才會跳出選擇讓你選，裝了 Fuzzy 後你可以跳著輸入 NSS RE 就會讓你選擇 NSStringFromCGRect 了。

2. BBUncrustifyPlugin

https://github.com/benoitsan/BBUncrustifyPlugin-Xcode

這個可以簡單的幫你把大家寫的 Code 的格式全部轉成一様，在多人工作的環境下，看起來會像是同一個人寫的。

Linux 找出誰佔據了你硬碟容量&清理mysql 記錄檔

搜尋資料夾檔案大小 du --exclude="proc" | sort -g -r | head



登入mysql

mysql -u root -p

清理 mysql-bin 方法為：

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2008-12-19 21:00:00';

============================

位於 /var/spool/mail/root 信箱如果滿了,要如何一次清空呢
方法很簡單,只要下達一行指令即可

cp /dev/null  /var/spool/mail/root

App 不在背景執行也可以接收 iBeacon

有點強～

https://community.estimote.com/hc/en-us/articles/203253193-Launching-notifications-in-iOS-when-the-app-is-killed

破解 Sublime text 3 build 3059

http://www.yutent.com/?article=73

這篇是我找到最簡單的，也成功破解了， try it

UISearchDisplayController 在 鍵盤消失後 Tableview 的位置跑掉了

由於客戶要求使用 UISearchDisplayController

就弄了一下，沒想到 Display 的 table 怎様都不對，DeBug 了一個下午才解掉

有人說這是 iOS7 的 Bug，我也不知道，但的確很微妙

解答在 這裡

直接複製貼上就是完美解，

希望不要有人再浪費時間在這個問題上面。

Line API

未查證,先備份

http://blog.dreambreakerx.com/2013/09/line-api/

Mac 顯示隱藏檔案

顯示隱藏檔案：defaults write com.apple.finder AppleShowAllFiles TRUE;\killall Finder

不顯示隱藏檔案：defaults write com.apple.finder AppleShowAllFiles FALSE;\killall Finder

雷神巧克力 驗關攻略

雷神巧克力賣翻全台灣，也造成日本斷貨，於是乎就有某多事的立委要求全面撤查。

所以你也才會點進來看這篇文章。 

小弟也是為了把區區幾盒巧克力帶回家，特地從新竹跑到台北辦驗關手續。

這篇文章就當作個紀錄，也給那些為了驗關而傷透腦筋的人一些方便。 

其實驗關最主要就是要貼成份的 "中文標籤"，而雷神有好多種，每種口味的成份都不同。 

小弟只有大雷神的經驗，所以最後會提供大雷的中文標給各位，其他口味的就要自已 咕咕嚕 了。 

依照本篇的流程，只要你沒有倒楣被海關特別抽查到要驗貨，只需要花一天的時間，跑一趟台北就可以搞定了。 

有一點要先說明，單一口味沒超過6kg是不用跑這流程的，直接殺去郵局領就可以了，但只要有一種口味有超過，就得為這口味去跑流程囉。

驗關的流程就是 填申請書－＞貼中文標－＞拍照－＞回傳給社福部－＞取得通行證－＞繳稅－＞領貨

 step by step

Step 1.
先下載 查驗申請書 和 進口資料申報表 社福部應該也是處理了很多雷神的案件，所以他們做了一份範例給參考，照著填就可以了，申請書範例 和 資料申報表範例

其中要注意的是"查驗申請書"的製造廠名稱要填寫完整 “有樂製菓株式會社UTY“ ，貨品分類例填寫 18063100007 (其他口味不確定請打電話問海關)，總淨重請自已算一下，大雷一盒是 0.78公斤，若是十盒就寫 7.8 kg.

"資料申報表" 的國外出口廠商、成份和中文標示様張請填寫"如附件"即可.

填寫完畢後請掃描這兩張文件以及郵局招領單、收件人的身份證正反面、產品照片(下載)以及製作的中文標(下載)。 PS 產品照片及中文標僅大雷神可用，其他口味請自行修改，中文標的進口商，地址和電話一定要填寫與巧克力的收件人一様資料

備齊後請寄 e-mail 至 gaz119@fda.gov.tw 標題就打你要申請檢驗雷神巧克力囉，若不放心可以在寄出後打電話詢問 02-89788425 吳小姐/林小姐。

這裡要誇獎一下這兩位辦事人員，非常客氣，從頭我問到尾都很有耐心的回答，完全不像是處理了一堆重覆事件，拍拍手～～

確認收到後若有問題或要修改的地方她們也都會電話通知修改，全程以 mail 來回即可，都沒問題後就等審查通過，我好像只等了兩天就過了。

Step 2. 

審查通過後就可以把中文標印出來然後帶著你的郵局招領單殺到到台北總局(捷運大安森林公園站6號出口左轉過馬路就到了)去貼標了。

這裡要把你的申請書、資料表和私章正本一起全部帶著，等等要用到。

貼完之後要拍三張照片，第一張要拍你貼的中文標是否有貼好，不能只是浮貼，第二張要拍你所有的巧克力都有貼上中文標，最後一張要拍你巧克力盒上的食用期限。

都拍好後一様用 mail 的方式把照片寄至 gaz119@fda.gov.tw 再打電話詢問是否有收到，有收到後承辦人員會請妳去社福組找某人繳審查費(捷運昆陽站4號出口過馬路後巷子順著走2分鐘就到了)，這時你的正本就會用到了，到了社福組到櫃台請警衛幫你打電話給承辦人員，沒問題的話繳個200塊審查費後就可以等著拿通過證明了。

Step 3.

再度回到大安郵局，拿著你的通知證明給海關看就可以領貨了，但在領貨前海關會課稅，他會問你買價多少，千萬不要傻傻的跟他說你買一盒台幣要650～700，請以日本原價報價！大雷在日本一包也才53塊日幣。你可以秀發票給他看。 我遇到的海關人還不錯，沒有多問什麼，感覺他也很無耐處理了一堆巧克力。

以上就是整個流程啦，雖然麻煩，但其實不管是去貼標還是去社福組，都會遇到一堆同様為了雷神台北跑透透的人，很容易就聊起來了，也滿有趣的啦，希望有幫到各位，有問題留言囉。

Check entitlements of your provision file

security cms -D -i testSecurity.mobileprovision | grep -A12 "Entitlements"

Push Notification 增強版

http://stackoverflow.com/questions/10058768/php-apple-enhanced-push-notification-read-error-response http://blog.csdn.net/tlq1988/article/details/9612237

解決 iOS 7.1 OTA error 'Cannot install applications because the certificate for yourdomain.com is not valid'

升到 iOS 7.1 後，打開原本乖乖運作的測試版 App 網頁竟然回報錯誤

'Cannot install applications because the certificate for yourdomain.com is not valid'

我和我的小夥伴們都驚呆了，估狗了一下，原來是 Apple 改成強制要用 ssl 連線了

所以解決辦法就是為你的 Domain 申請一個 SSL 憑證，收工！！！

。。。

。。。

。。。

怎麼可能～～

就這様有什麼好寫的，除非是大公司，不然每年申請 SSL 憑證也是挺麻煩。

好在 stack overflow 有人提出了利用 dropbox 來解決這個問題，親自試驗了一下還真的可以用，也利用這篇文章紀錄一下怎麼使用囉，原文在這裡


首先你要有一個 Dropbox 的帳號，怎麼申請和基本操作就不多做說明了，自已摸索吧。

若你不是第一次製作自已的 OTA，那你一定知道每一個測試的 App 都會有三個檔案

downloadpage.html

projectname.plist

projectname.ipa

依我遇到的情況，原本都是將這三個檔案丟到自已的server裡就可以運作了。

現在改成全部丟到 DropBox 裡面去。

 downloadpage.html 裡會有一個鏈結長得像這様

itms-services://?action=download-manifest&url=http://168.1.1.10/projectname.plist

這個鏈結是指向你的 Plist，當然，我們也已經把這個 Plist 丟到 DropBox 去了。

現在到 DropBox 取得你 plist 檔案的下載網址，應該會長得像下面這様

https://www.dropbox.com/s/k2xjgdvnfmp1193/projectname.plist

接著我們把這個鏈結網域改成 dl.dropboxusercontent.com 就變下面這様了

https://dl.dropboxusercontent.com/s/k2xjgdvnfmp1193/projectname.plist

把改變過後的連結取代你原本 html 裡的 url，所以你的 html 那一整段應該長得像這様

itms-services://?action=download-manifest&url=https://dl.dropboxusercontent.com/s/k2xjgdvnfmp1193/projectname.plist

ipa 檔可以選擇放在你原有的server上，我是選擇統一放到DropBox 裡，

如果你也是統一放到 Dropbox 裡，請記得 projectname.plist 裡的 ipa 連結也要修改，也是要把網域名稱換成 dl.dropboxusercontent.com 才能正常運作。

最後，你只要取得 downloadpage.html 的連結，也同様把網域改成 dl.dropboxusercontent.com 像是這様

https://dl.dropboxusercontent.com/s/6v1ufqpthjzufck/downloadpage.html

最後把連結寄給客戶，一切就和以前一模模一様様了。