API

　　做网站运营的很早前就使用过Google Maps等API，后来我们自己的站点也可以提供IP查询、字典等API，但我们基本上没有使用过收费的API，也没有对外部提供API（目前只对公司内部的不同项目提供）。

　　2009年开始我们就在网址中调用了Google Maps API，后来Google因故退出中国大陆，Google的多项服务都无法使用，我们就让主要针对国外浏览者的站点继续使用

　　最近需要编写一段程序来读取Drupal网站中页面Node的某个文本字段，进行处理、判断、匹配后，将这个页面归类Taxonomy到某个术语表Vocabulary的术语Term中。

　　很早以前我们就在MediaWiki网站的页面中嵌入过Google Search API代码，见我2008年记录的《Google AJAX Search

　　OCR文字识别其实可以算很老的技术了，一二十年前购买扫描仪的时候就配有文字识别软件，记得用起来比较勉强，在比较复杂的中英文混排、版面不规则的情况下，很难获得满意的识别效果。

　　这几年我们在做Web展示网站的时候，有些原始资料只有扫描件，尝试过OCR软件识别或者网上的OCR识别服务，但都不理想，而手工录入、校对的工作量太大，也搁置下来了。

　　Google的网站站长管理平台中可以看到Google Bot抓取遇到的错误，而且错误比较多的时候，会有邮件提醒，这是个不错的功能，当系列网站多以及页面多、服务器多的时候，很难人工都及时检查到各种页面的各种错误，有Google的提醒能让我们及时获取异常信息、及时检查处理。

　　早在2009年，我就在MediaWiki中通过Google Maps API调用谷歌地图，但后来随着Go

　　Google Webmaster Tools我们很早就在用，去年也开始使用其API，写过一篇记录《调用Google Webmaster Data API批量

　　这些天在做系列网站的时候，遇到多个子网站、每个子网站都有多个内容类型，希望在首页展示内容类型、包含的字段名称以及页面数量，以前是人工来读取的，但网站多了就很麻烦，而且以后不便更新，这次用Drupal的API调用及SQL语句来实现了。

　　我们一些使用Drupal的网站中启用了系统自带的留言功能contact模块，用户使用的时候填入表单就可以反馈，不需要另外发送邮件，还是很方便的，但同事发现一些要求更改或者删除某个页面的留言中，用户并没有按照我们的提示填写需要更改或者删除的页面网址，导致需要反复联系多次，增加了工作量也不利于客户体验。