上周應谷歌廣告聯盟Iris的邀請，進行了一次線上新書讨論會。在開始之前的一個星期Iris就給我寫了預備的10個問題，如果讨論會沒人提問就用，但實際上一個都沒用用上，從第一個問題就是回答網友提出的問題，原定30-45分鐘，一共用足了45分鐘，網友還有不少問題，但也隻好結束了。

　　線上讨論會使用的千聊軟件平台，可以從微信進去，也可以下載app，我是直接使用的微信，頭一天測試了一次，知道大概流程和用法，第二天正式使用中還算基本順利，沒有遇到特别的意外，當時都是用語音回答的，現場Iris都做了一個簡短的文字小結，其内容在千聊平台永久保存，錯過的同學可以随時去聽：本次線上

　　我們做了這麼多年的AdSense，在廣告的擺放上還是很注意的，特别是位置，要讓可見率提高非常重要。

　　當然，還有一些細節，例如前一陣子發現有些廣告自動在手機端變成了全屏寬度，在某些地方遮蓋住了頁面中的邊框線，顯得不夠美觀，于是我們就改為了300x250的固定寬度。

　　接下來還有一個問題，300x250固定寬度廣告在不同寬度的手機上的位置有時居中有時偏左，特别是大屏手機上，偏左也不好看，最好能居中顯示。

　　請教美工設計同事後，給出了修改CSS的方案：

　　辦法1 - 直接在AdSense代碼中修改。

　　Linux中crontab是一個很有用的定時工具，可以設置很多定時任務，我們一直都在使用。

　　最近同事提出白天在服務器上導入數據會讓負載增大、影響用戶正常訪問，希望能設置到晚上自動運行，這個應該很簡單，隻要把手工運行的導入程序命令放在一個定時批處理文件dingshi.sh中，設置crontab晚上自動運行就可以，但要考慮不能重複運行導入。

00 3 * * * root sh /root/dingshi.sh

　　避免重複的辦法應該不止一種，我想到的辦法是在這個dingshi.sh的最後一行寫一條修改自己文件名

　　最近寫了幾段PHP程序，給同事來導入數據到MySQL數據庫，同事偶爾反映遇到這樣類似的報錯：

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'state' at row 1: UPDATE `table` SET `address` = 'xxx', `state` = '過長内容', `id` = &#03
  

　　昨天剛寫了一篇《不要誤屏蔽百度MIP的爬蟲》，順着我們就繼續檢查其它站是否有被誤屏蔽的事情，流量來源主要是百度的國内站可以看百度站長平台（百度搜索資源平台）裡面的信息，流量來源主要是Google的國外站可以看Google Webmaster Tools (Google Search Console)。

　　今天同事發現一個台灣繁體版站的索引情況有異常：

　　我們很早前就開始做百度MIP版本頁面了，通過這種方式也獲得了流量的增長和比較好的用戶體驗。但最近流量不太穩定，有的站MIP流量曾經很高，但後來跌落很厲害。還有的站MIP流量下降後，對應的普通WEB版流量上升。

　　我們做了各種推測和試驗，今天發現了一條重要線索：百度的MIP爬蟲曾經被我們屏蔽。

　　按照百度官方的說法，其MIP爬蟲的User Agent是這樣的：

Mozilla/5.0 (Linux;u;Android 4.2.2;zh-cn;) AppleWebKit/534.46 (KHTML,like Geck
  

　　最近和采集者杠上了，不斷與這些采集者糾纏，周一一大早就看到網站監控報警，服務器帶寬被占滿，在從iftop -i eth1看到有兩個IP段一直占據前列：

　　再仔細一查，這兩個IP段是已經被我們在.htaccess裡面屏蔽的，從tail -f access.log看這兩個IP段的地址訪問都是403被拒絕狀态，但不知道是哪家的傻爬蟲（220.243.135.*/220.243

　　前些天寫了一篇《為網站面包屑導航添加結構化數據》，主要說的是為Drupal網站的面包屑導航添加結構化數據标簽，從實際應用來看是可以起到預期效果的。

　　後來我又嘗試了在MediaWiki網站中也為面包屑導航添加結構化數據标簽，做起來麻煩一些但依然是可行的，今天來記錄一下。

　　我們從2006年很早就開始使用MediaWiki軟件了，嘗試了用模闆來做一個面包屑導航，代碼類似這樣：

<div class="breadcrumb">
[[link:|首頁]]
>
[[link:{
  

　　最近新增了一些網站内容，結果正常的訪問者還沒有開始來，采集的爬蟲就來了，真像是嗜血的鲨魚，發現哪裡有美味馬上就盯上了😰。

　　近期也看了一些關于反采集的文章，世上沒有完美、一勞永逸的反采集辦法，成了與采集者的對峙，雙方不斷變換對抗辦法，成了一種體力活。

　　我們現在也不得不采取更嚴格的反采集措施，看到很多采集IP都來自amazon雲計算，這就可以用hostname反查來進行屏蔽，以前曾經做過測試，今天再次測試并記錄。

　　在apache的httpd.conf文件中添加一行：

HostnameLoo
  

　　我們在采用《使用Apache模塊mod_qos反采集》的辦法以後，确實有一些效果，但從apache報錯日志中看到也有百度、Google等搜索引擎的IP被屏蔽了，現在來收集整理一下常見搜索引擎的IP地址段，以便加入白名單中：

Googlebot：

• 66.249.
• 203.208.60.
• 216.239.
• 66.102.
• 64.233.
• 72.14.

Baiduspider：