web
安装好了memcacheD，如何通过php来连接之，测试是否正确运行呢？下面这段代码可以帮助我们测试。注意，我们使用的是memcacheD. $cacheServer = new Memcached(); //create memcacheD instance $cacheServer->addServer(‘127.0.0.1’, 11211); //connect to memcacheD server $cacheServer->set(‘uname’, ‘flower’); // add key and […]
IntelliJ IDEA 2016.3 2016.3 PREVIEW 发布了，这个曾经与Eclipse分庭抗衡到现在到现在占领大部分市场份额并被公认为最高效的Java IDE工具重磅推出了2016的第三个PREVIEW。下面是一些IntelliJ IDEA 2016.3 2016.3 PREVIEW的新特性： Java部分更新 1. Refactoring to Java 8(具体特性参看下图) Now, if you
很多时候不遇到问题，是不会想着去解决问题的，WordPress加速问题对与笔者这种懒惰的家伙亦是如此。昨天突然发现wordpress打开超级慢，于是乎开始了问题寻找之旅。首先linode后台，查看longview.关于什么是longview，可以看看笔者之前的文章Linode Longview简单使用，首先发现httpd占用cpu的确蛮高，会不会是这个问题呢？不管是不是，能想办法降低下cpu的负载吗？带着这个问题第一反映就是静态化，于是乎第一个给力的插件出现了WP Super Cache,这货可以在对应的目录下生成wordpress对应的纯静态页面，这样，负载将直接从apache转嫁到nginx上。不必php引擎解释，不必mariadb查询，不必….还可以js,css各种缓存。总之，静态话好处多多，速度很快！(其实说到静态化，随之而来的另一个方案就是CDN，静态化后很多资源都可以通过CDN来加速，抛开后台动态解析以及数据加载等开销，单单CDN一项就值得我们这样去做！) 静态化之后，再次尝试访问歇歇脚，发现仍然卡顿。呃。。。这不应该啊。监控一下，发现1. Google CDN js脚本加载缓慢， 2.Gravatar加载缓慢。原因比不说，大家都知道。那么有么有办法解决呢？于是乎第二个给力的插件出现WP Acceleration for China，从下面的图中可以看到，加载js地址已经从google cdn变为ajax.lug.ustc.edu.cn。如此一来速度已经飞起。
Apache静态编译： 在使用./configure 编译的时候，如果不指定某个模块为动态，即没有使用：enable-mods-shared=module或者enable-module=shared 这个2个中的一个，那么所有的默认模块为静态。 那么何谓静态？ 其实就是编译的时候所有的模块自己编译进 httpd 这个文件中（我们启动可以使用这个执行文件,如： ./httpd & ） ，启动的时候这些模块就已经加载进来了，也就是可以使用了， 通常为： 来配置。所以大家看到的配置都是 ，很显然，module.c这个东西已经存在 httpd这个文件中了。 Apache动态编译： 就是编译的时候，使用enable-module=shared 或者enable-modules-shared=module 来动态编译。
今天看linode后台，发现一个叫做Longview的监控工具。因为最近重新折腾了下vps，所以想看看到底性能怎么样。于是乎安装Longview尝试了一下。Longview分为免费版和收费版。收费版本为Longview Pro，刷新周期短（貌似为1分钟刷新一次），可监控的节点也比免费节点多，免费的为10个。当然还有其他限制，各位有兴趣的看官老爷可以自己去看看喽。安装过程十分简单，按照后台提示即可。具体使用方法可以参考这里：https://www.linode.com/docs/platform/longview/，同时值得注意的是如果apache端口修改过，那么对应/etc/linode/longview.d/Apache.conf下面的内容也要修改，比如： location http://127.0.0.1：81/server-status?auto 最后附上一张简单的Longview效果图，确实很好看！:)
编译php5.4，碰到一个妖异的错误。 undefined reference to icu 55， icu4c是我手工编译的icu4c-55_1，于是乎卸载掉，重新编译最新版本的icu4c-57_1,安装臂弯重新编译php5.4结果继续出现undefined reference to icu 57。搜索了半天，终于发现貌似是在之编译其他软件时候安装了CentOS7.2源里的icu4c,只要干掉默认安装的即可解决问题。从下面的查询可以看到，源里的版本是50.1.2，而我使用的是55.1和57.1,但编译过程中会自动去寻找系统安装的50.1.2版本，不知道是否是因为我没有指定icu目录的问题，有时间再编译一次试试。 yum list |grep icu icu.x86_64 50.1.2-15.el7 base libicu.i686 50.1.2-15.el7
年底了,各大商家再次开始纷纷推出优惠活动了，当然Godaddy也不例外，虽然前段时间推出了不少优惠码，但不是有时间限制，就是前10000名有效，但对于一些没有购买过域名的朋友，即使没有这些优惠码仍然可以享受到$1.99的优惠政策。还在等什么，赶快行动吧？至于为什么不在万网等购买域名，相信原因不用笔者多做解释了，既然大环境不允许我们有足够的自由空间，那么我们只能退而求其次了。 Godaddy再推$1.99域名链接地址：
LinkChecker 6.2下载地址发布了，关注LinkChecker的朋友可以直接去LinkChecker官方获取最新的LinkChecker 6.2下载地址下载试用。LinkChecker 是一款比较有趣的工具，对于开发人员来说，LinkChecker是测试的好帮手。它不但可以用于测试应用是否正常工作还可以对应用响应的的页面进行分析，对响应代码中的css,html语法进行校验（如果网站被挂马，也能检测出来）。当然对于笔者来说这款有趣的工具还有一个有用的地方，那就是对死链的检测。如果有朋友对SEO比较熟悉的话，一定知道死链是SEO中的大忌。国内外都有类似的死链检测工具，就是为了保证无论是静态页面还是动态页面是完整串联在一起的，这样在SE的支柱爬行过来的是后，可以最大限度的将网站的内容战线给SE，同时有效的网站各处的权重进行传递。因此从上面的内容来看LinkChecker 6.2不但对开发者有用，对于搜索引擎优化的爱好者来说也是个不错的选择，毕竟LinkChecker是免费软件，同时功能十分强大，而且开源，如果对需求有不满还可以自行修改。 LinkChecker 6.2主要改进包括： LinkChecker 6.2增加了递归检测PHP文件的功能 LinkChecker 6.2去掉了对话框中的复位按钮 LinkChecker 6.2在图形界面中增加了检测新版本功能（貌似软件升级做的越简单，用户越喜欢，否则也不会出现pacman,apt-get之类的东东了） LinkChecker 6.2下载地址： LinkChecker 6.2下载
web编程对于很多人来说似乎就是处理一下网页，而对于网页编程来说，似乎就是用工具那么拖拖拽拽就行了。一切显得那么简单。或许对于普通用户来说，做web应用似乎是一件十分简单轻松的事情，或许学习一下asp,php真的很简单，但web编程就只是这些吗？让我们一起来看看国外某高人的感悟“Web编程真的很难_一个精通C/C++嵌入式高手的自白” 说老实话，我过去很生气那些互联网公司，我送去简历，他们却根本不给我一点机会和时间。我已经很久没有向互联网工作职位投过简历了，因为我知道我的简介会被第一个丢到废纸篓里。 两个月前，我还不能理解为什么互联网公司对我的大量的C/C++/指令控制/嵌入式系统的简历毫不感兴趣。现在我知道了。下面写的就是为什么 … Web软件开发体现了一种全新的思维方式。例如，我过去是用微软的.NET来做界面程序的。当经过了几个月的 CSS，HTML，JavaScript学习之后，我可以老实的说我很惭愧。做为一个非Web软件开发者，我想起了曾有无数的嵌入式软件技术人员随手把 Web编程工作写作一种“琐碎的”或“无聊的”工作。然而，经过了过去两个月对Web编程的钻研，我发现事实正好相反。 就让我们先看看前端的这些东西： 学习CSS，HTML，JavaScript，Jquery 以及把它们之间的相互作用关系搞通，并不是件容易的事情。事实上，对于那些从 .NET，C++ 或 Qt 思维模式过来的人，它会困难的让人沮丧。GUI Toolkit这些东西跟Web前端的东西比较起来显得笨头笨脑没有灵性。 这个世界已经永远的抛弃了那些设计糟糕的、令人讨厌的桌面图形界面。而互联网对此要求的近乎苛刻 — 一个糟糕的用户界面设计会毁了一个互联网公司。人们经常在说，Facebook更简约的界面设计正是致使Myspace逐渐败退、几近消亡的关键原因。有 一个在一个新近突起互联网公司工作的软件技术人员告诉我： 每天，新代码都会受到考验，来自不同地区的数百万的用户采用不同的方式，使用任何你能想到的软件、硬件对程序进行测试。你在数秒钟内就能获得反馈信息。如果某处改动可能会导致某种灾难性错误，我们可以只向1%的用户开放，并记录一切发生的事情。很遗憾，大多数桌面图形程序不会遇到这么大的压力。
随着互联网的急速膨胀和发展，现有的HTML技术(HTML4)似乎已经无法满如日益膨胀的信息和人们的感官需求。于是乎在众多网民的呼声和各大浏览器厂商的力挺下，HTML 5终于被推举了出来。但是由于各大厂商对HTML 5规范的意见不统一，导致HTML 5规范目前仍然没有完全定下来。但就是目前不完整的HTML 5规范也被各大厂商极力退从，各种浏览器开始马不停蹄的支持，随着HTML 5技术的不断发展，有关它的话题讨论越来越热烈，比如HTML 5存在哪些不足、开发人员应该尝试还是旁观等，InfoQ中文站就相关问题专访了Opera技术布道专家谢子斌。 InfoQ：请您先介绍一下HTML 5的历史。 子斌：众所周知，HTML5是W3C的一个规范。如果追溯起源，并非W3C提出的HTML5。它最初起源于一个叫做WHATWG的小组。2004年，W3C正建立XHTML2的规范，Opera和火狐当时给W3C提供了一些改善HTML标准的建议，但是W3C拒绝了这个报告。 Opera和火狐还有苹果三个公司的技术人员共同成立了WHATWG小组，开始一起制定HTML4的规范，但还是不叫HTML5。直到2007年W3C决定开始制定后HTML4的规范，我们才把自己写的一些规范并入W3C刚成立的HTML5小组。 InfoQ： 浏览器厂商对HTML 5的发展持怎样的态度？有哪些举措？ 子斌：W3C有700多个会员，其中包括很多浏览器厂商，谷歌、微软、Opera、火狐等。他们参与了规范的制定，在推出之前，争执和讨论早已发生，内部已经统一了对规范的看法，所以对HTML5的支持，大家基本都是一致的。虽然有我们不满意的地方，但是我们在实施HTML5的时候基本是希望看到兼容性的，比方说你是第一个实现HTML5某个技术的浏览器，他肯定也希望其他浏览器厂商能实现这个技术。因为只有大家都实现这个技术的时候，程序员才会采用这种技术。如果只在特定浏览器才能实现，那么程序员可能就会采用这个技术应用。这种技术上的实现和推广可以比作一个长跑，可能是你暂时领先，也可能暂时是我领先，但是只有大家都跑到终点，这场长跑才会结束。 InfoQ：对于Web应用的架构师和开发人员来说，现在应该如何对待HTML 5？尝试还是观望？ 子斌：每次和程序员交流的时候，他们都会有这个疑问。我觉得大家使用HTML5只是一个时间问题。不管你现在使用，还是两年后再使用，但是最后肯定是要使用HTML5。我们在推广的时候，就考虑到这个方面，采用所谓优雅降级的做法，可以尝试提供一些HTML5技术给前卫的用户来体验，同时也不拒绝一般用户，比如说IE6的用户，虽然不能使用HTML5，但是可以浏览加入该技术应用的网站。比方说CSS 3，它不是HTML 5，但有些人把他们混为一谈，你用它在图片上实现一个圆角的效果，我觉得可以采用这种优雅的方式，如果你的浏览器可以实现，你就给它一个圆角的效果，如果不能，则给它一个一般的效果就可以了。大家都可以浏览你的网站。再比方说video标签，IE