Mysql 修改了socket文件路径后的错误

2012-05-16

Timeout error occurred trying to start MySQL Daemon

http://tech.ddvip.com/2009-02/1234284172108165.html

 

今天一台机器出问题，发现是/var空间满了，当初分区的时候/var分区划分的空间就很小，mysql数据库的默认位置又是在/var/lib/mysql下面，结果被mysql撑满了。

 

于是停止mysql，将/var/lib/mysql整个移走，然后修改/etc/my.cnf，将新的路径修改好。但是启动的时候发现，mysql服务实际上起来了，但是启动脚本仍旧报错显示联系不上mysql daemon。

搜索后发现上面文章的提示，原来mysql的启动脚本中，mysqladmin程序要通过ping命令检测一下mysql的启动情况。

于是在/etc/my.cnf里面加上

[mysqladmin]
socket=/data/mysql/mysql.sock

将新的socket路径给他就好了。

后来想了想，其实搬家的时候，保留/var/lib/mysql/这个目录，socket文件还是放在这里好了…. 我勒个去！

 

乖宝宝:)

2012-05-10

 

乖宝宝:)

关闭 php X-Powered-By 信息

2012-05-09

在请求头的时候可以看到 X-Powered-By 字样,为了 安全可以去掉.看你的需要了

linux 下 执行 curl -head http://blog.wumashi.com 会显示出如下信息

要去掉  X-Powered-By: PHP/5.2.1
则修改 php.ini 文件 设置 expose_php = Off

决定服务器上是否暴露安装有PHP，
（例如:把这些信息加到Web服务器头响应）。这是不安全的。
但能确定你的服务器时候运行着PHP。
意思就是打开的话可以告诉其他人这台服务器可以运行PHP，但不一定安全，可以关掉

关闭输出 X-Powered-By 信息

这个服务员在计算机屏幕上干什么？

2012-03-12

本文的主人公、瑞典企业家 Richard Gatarski

本文的主人公、瑞典企业家 Richard Gatarski

Richard Gatarski和几个朋友打算在瑞典诺尔彻平市搞一次聚餐，他们几个星期前就在市中心的一家看起来不错的意大利餐馆预订了一张桌子。

当他们到达那里时，餐馆的领班热情的接待了他们，问他们有没有预订，Richard 告诉了他预订的信息，领班对着电脑屏幕看来起来。

”Gatarski? 哦，让我看看…找到了，这是你们的预订。欢迎！“

领班拿起一支笔来，Richard起初以为那是一种新式的电子笔，看领班拿着笔指向了屏幕。Richard是科技企业界的精英，他十分好奇餐馆里的这些人使用的是什么样的新式装备。他把身子倾过去，靠近了一点看。

领班用一支普通的白板笔在屏幕上核销来到的客人！

Richard 突然意识到，那是一只普通的漂亮的白板软尖笔。领班是直接在屏幕上用它在这他们的预订上画了一个“X”！

“这太有趣了，”Richard对领班说。“你怎么会想到这样做？”

“哦，是这样的，你知道，”领班长叹了一声。“开发这套系统的那帮家伙，他们…” 你知道吗，你无法按照你想要的方式使用它们。你可以在这个系统里核销一个预订，用鼠标来操作，但是，嘿，你需要在这个界面上至少点4下。而且系统中还看不出来客人是已经领到了他们的桌边还是还等待在吧台前。所以，直接在屏幕上画更简单。(当店里打烊时拿抹布在屏幕上擦去就行了。)我们这里很忙，这样做很方便。”

顺便说一下，菜的味道非常的好。

* * *

那么，这个现实世界的故事告诉了我们什么？

  1. 计算机系统并不总是按照开发人员设想的方式被使用。
  2. 人是有创造性的。他们可以、他们喜欢发明各种方法来简化他们的日常工作。
  3. ”我们非常忙。” 用户在工作中有很多更重要的事情去做。 相对于去学习一下那些看起来价值和用途都不太明显的事情，我们更愿意把时间花在我们认为更重要的事情上(例如，开发出客户从来没有尝过的最好的调味酱)。
  4. 对这样一个预订系统的投资看起来是完全浪费了。 一个真正的小白板就解决了他们的问题，既便宜又方便。
  5. 有一种可能，预订系统的计算机化(相对于一个真正的白板)，可以生成一些统计数据：每月的客户量，每周预订情况的对比，一定周期内桌子预订的百分比。销售计算机软件系统(各种形式，各种业务)的公司通常会最大限度的挖掘这种数据，把它作为他们的软件的最大优势。但做这些有价值吗？很多情况下，一个领班通常会根据经验或大致情况知道什么是最重要的。这讨厌又费时的来来回回点数次鼠标，只是为了产生这些数据，并不觉得很值得去做。
  6. 最后：想知道对于用户来说什么是最重要的，用户真正是如何使用系统的，你需要去观察真正的用户，到现场观察。

核销预订，在屏幕上标记

[本文英文原文链接：What’s the waiter doing with the computer screen? ]

转载自：http://www.aqee.net/whats-the-waiter-doing-with-the-computer-screen/

 

一声叹息：两台服务器是为失败者准备的

2012-02-27

一、

总裁：“我们不需要两台服务器”

我：“可是我们需要双机备份”

总裁：“两台服务器是为失败者准备的，优秀的团队绝对不允许任何一台服务器出问题”

我：“唉…”

二、

领导：“我们的外网网站应该支持IE8”

开发：“我们需要安装IE8才能测试

领导：“技术支持部门会为你们测试”

技术支持：“我们不支持IE8”

开发：“我们需要安装IE8来测试

领导：“你们不允许安装未经批准的软件

开发：“唉…”

领导：“为什么我们的外网网站还没有支持IE8？”

三、

技术总监：“我们要准备把我们的MySQL换成SQL Server。”

开发人员：“这是出于什么目的？一切都运转良好呀，而且买SQL Server需要花费￥￥￥…”

技术总监：“因为MySQL不是‘企业级’的。”

唉…

四、

一个同事在写单元测试。当运行起来后，他发现有个测试断言失败了。他如何解决这个问题？他把它给删了，因为“没有人会注意到这些”。

唉…

五、

老板：我们需要在这放一个cookie——他指着屏幕。

我：什么？

老板：在这放一个cookie——他再次指了一下屏幕。

我：呃…

技术负责人：他的意思是一个下拉列表。

六、

我：在我们把这些屏幕截图通过网络送出去之前应该用ffmpeg工具包把它们压缩一下…

团队负责人：谁打算去学习这些没有文档的api？我们先用多线程技术直接发送数据…

我：这样可能数据量太大…

团队负责人：没错，先干着。你抽空在“业余”时间研究一下那个api。

团队：哈哈…

….. 一个月后，多线程版的实现了…

团队：局域网上运行表现非常好…放到WiFi网络上试试

…. 由于数据延迟，慢的像蜗牛…

团队负责人：你有没有在业余时间研究一下那个ffmpeg？

我：唉…

七、

我知道，我们需要用 pngquaint软件 压缩60多个总共20多兆的PNG图片。

pngquaint软件崩溃了，怎么回事？

研究发现，这些PNG文件实际上是JPG文件，只是名称被改成了PNG，不知道之前那个程序员她想干嘛。

唉…

本文转载自: 外刊IT评论 http://www.aqee.net/

亲爱的老板：程序员的10分钟就是3个小时

2012-02-07

国外程序员艾德·韦斯曼（Ed Weissman ）从业32年。某天老板告诉他产品有个问题，10分钟可以修复问题，谁知结果一干就是3个小时。本文就是艾德记录下的过程。

 

10:48

老板：嗨，艾德，苏在底特律说，“产品历史屏幕”上经常出现错误的发票号码（Invoice Part Number）。你能帮我们搞定这个问题么？

艾德： 我现在在忙其他事。你到我的任务队列中提交一个ticket吧。

老板： 这事10分钟就够了。

艾德： 你确信么？

老板： 嗯，确定。我一会开个网络会议。苏会演示给你看，然后你有空的时候再仔细看看。

艾德： 好的。

老板： 嗯。去你的 Outlook 中查收（会议）邀请吧。 阅读全文 »

Dear Boss: For a programmer, 10 minutes = 3 hours

2012-02-07

Dear Boss: For a programmer, 10 minutes = 3 hours

http://edweissman.com/dear-boss-for-a-programmer-10-minutes-3-hours

 

10:48

Boss: Hey Ed, Sue in Detroit says that sometimes, the wrong Invoice Part Number is showing up on the Product History Screen. Can you help us figure this out.

Ed: I’m busy with something else at the moment. Put the ticket in my queue.

Boss: This will only take 10 minutes.

Ed: Are you sure about that?

Boss: Yes. I’ll just set up a web conference. Sue can show you right away, then you can look into it when you have time.

Ed: OK.

Boss: Great. Check your Outlook for an invite.

阅读全文 »

转载：节油小贴士

2012-02-03

节油小贴士：

1、避免急加速、急减速

    很多车主会在堵车的时候，见缝就插。经常强行超车、挤车，当超不过去时就大力刹车。这样的驾驶习惯不但会增加油耗，更不利于行车安全。

2、避免反复启动发动机

    有部分车主会堵车的时候短暂关闭发动机，认为这样做可以减少油耗。其实这样的做法有待商榷，发动机正常启动一次所消耗的燃油量，可以供车辆行驶300米左右。

3、大油门起步

车辆采用大油门起步还是小油门起步，在实际驾驶过程中对车辆油耗的影响是非常明显的。相反，从加速效果来看，无论采用哪种起步方式，实际区别不大。

4、不要拖挡行驶

    车辆行驶时，只有选择合理的档位，才能使行驶阻力与牵引力达到一个平衡。使车辆平稳行驶，降低油耗。

5、减少车内无谓的重量

    很多车主喜欢在车内放置大量的矿泉水、杂志、车用保养产品、备用机油、备用防冻液等。这些东西会一定程度的增加车辆的重了，消耗更多的燃油。并且还长期占用了车辆的储物空间。

6、保持正常的胎压

    胎压过低，不但会使车辆轮胎的磨损增加，而且会很多程度的增加车辆的行驶阻力，增加油耗。

FROM：http://www.autohome.com.cn/drive/200904/57901.html

呼叫转移设置

2012-02-01

鬼手机没发现有设置呼叫转移的地方，找到设置方法，记录哈子~
1、无条件转移
设置：*72 + 被转号码(区号+固号，手机前不加0) 接通键 。取消：*720接通键
2、关机无应答（并存）转移
设置：*92+ 被转号码(区号+固号，手机前不加0) 。取消：*920接通键
3、遇忙转移
设置： *9+ 被转号码(区号+固号，手机前不加0) 。取消： *900接通键
4、呼叫等待
开通：*74 接通键 。取消：*740 接通键

 

软件开发的“三重门”

2012-01-31

出处：http://coolshell.cn/articles/6526.html

自从上次写了“程序员技术练级攻略” 以来，就觉得似乎还有很多东西没有谈到，但当时没有继续思考了。而春节前有人问我，是做底层技术，还是做业务。这问题让我思考了很多，不由自主地回顾了一 下我这十多年的软件开发经历，并顺着整理分类了一下自己解决过的若干问题，还发散想了很多，经过了一个春节假期的发酵，产生了下面这篇文章。

前言

这篇文章必然是通过我的个人经历来写的。所以，我先说说个人经历吧。我的经历基本分成三个阶段。

第一阶段：我 刚毕业时在家乡的某银行工作，做些银行的业务系统，还搞些网络，电子邮件系统，OA什么的，因为大四的时候在老师的公司里实习，银行里的人际关系太复杂， 而且技术都包给了产商，所以在银行的每一天都觉得不能适应里面的工作环境。两年后离职，单位分的房也不要了，直接去了上海，在上海呆了两年，本来想做互联 网的，但是泡沫来了，最终去了一家做系统集成的国企公司还是继续做银行业务。这四年来，主要解决的都是一些业务上的问题，银行里的会计业务，OA业务，国 际业务，中间对公业务都非常地复杂，而且因为当时的软件开发相当的不规模，所以基本上是在一种比较混乱的状态下度过的，而银行方面又很强势，所以，这段时 间主要是做业务。所以，技术上主要是积累了如何使用那些技术。C+/Java， Windows编程，Unix编程，网络编程主要是这段时间学的，看了太多的书（我大学课程里没有C++和Java，也没有Windows/Unix和网 络编程，所以，只能拼命地看书和自学）。

第二阶段：然后，我来了北京，到了一家做分布式计算系统的公 司，整天和一个高性能技术高可用性的企业级的集群式的软件产品打交道（这家公司去年被IBM收购了），在这家公司把Windows/Unix和网络编程有 了更深入的了解，对我长进比较大的是明白了怎么做一个性能高，可用性高的集群式的系统，天天和底层打交道，干了4年多。然后去了一家金融信息公司，这家金 融公司主要做全球的金融信息数据处理，而我主要还是做核心数据发布系统的性能调优的项目，金融数据的实时性要求的高，数据量非常地大，高可用性要求得高， 得想尽一切办法省网络带宽，增加系统性能，还要保持高的可用性，不当机，不丢包。又干了4年多，去的时候从国外接过来两个系统，其性能单机每秒可处理 120K message，我走的时候，我和团队把其优化到了每秒1.4M messages 的吞吐，另一个系统，从接手时的100k message/s优化到了500k message/s。这八年多的时候，全是在和这些高计算高性能的项目打交量，几乎没有什么业务，都是纯技术，积累到了很多和性能有关的高并发高计算系统 架构级的知识。

 

第三阶段：两 年前来到了现在的做电子商务的互联网公司Amazon，还是在做一个数据处理量很大的业务系统，因为要干的是要把电子商务全球化的东西。但是，因为电子商 务的特殊性，必需要去兼顾业务的特点，而且在Amazon，耳读目染了很多有趣的业务难题，比如，库存计划，配送优化，等等。虽然很多东西还不明白，但发 现，用技术来解决业务难题真是太有意思了。

我的这三个阶段，第一个阶段花了4年，第二个阶段花了8年，第三阶段刚刚开始2年不到，有时候我也去别的公司讲课，所以，我很有幸经历了中国软件开发的进化过程。我的经历就是中国软件行业进程的一个缩影，而我把这三个阶段称为——软件开发的三重门。它们分别是：

  • 业务功能
  • 业务性能
  • 业务智能

之所以加上“业务”二字，是因为我以为计算机是一个工具，其用来解决实际问题，所以，什么都离不开业务，就算是性能优化也一样，通过之前那篇“12306.cn的性能优化”中的“业务分析”段落，我们可以知道业务的不同，系统的难度和解决方法就可以不同。所以，我们总是用技术在解决业务问题。业务的形态对软件的开发有决定性的作用。

下面让我具体描述一下。

一重门：业务功能

这 是软件开发的第一重门，也就是掌握可以实现业务功能的技术。通常分成三块：语言+系统+数据处理。在这个阶段，主要是能掌握各种技术，比如：开发用的各种 工具（如：IDE，XUnit，Debugger，等），各种代码库和框架（如：C++的STL，ACE，Boost，等，Java的 Spring，Hibernate等），各种系统知识（如：Windows API，Unix/Linux API，TCP/IP，Socket，多线程多进程间的同步、互斥，并发安全，还包括Web平台，移动平台，等等），还需要掌握数据处理的知识（如：数据 结构，基本算法，数据库设计，数据库引擎 ，SQL等）。

这个阶段主要是把这些不同的技术组织成可以实现业务功能的解决方案。重点是能掌握和使用技术。很多流程和方法论的东西基本上就在这一重门里。这重门主要解决的是实现问题。

二重门：业务性能

业务的功能搞定了以后，就是业务的性能问题了。搞定功能并不难，搞定性能是有点技术含量的事。有句话不是那么说的吗——每个人都可以搞一个网站出来，但不是每个人都能搞出能支持百万级访问量的网站。但是，我看到很多技术团队或是工程师脱离了业务，只单纯地搞性能，比如：单台服务器支持10万个TCP链接的并发，等等。这些东西虽然在技术上有点意思，但是没有业务的环境，也只能是自娱自乐了。

我们可以看到一些企业开始注重这个问题了，性能问题也是最近被大家讨论得最多的问题，京东商场的性能问题，12306的性能问题，等等。

当然，所谓性能不并单单指系统的吞吐力，还指系统运行时的总体性能，比如，系统安全性能，系统的Accessbility的性能，系统的扩展性性能，等等，就像是前些天中“Web开发中需要注意的问题”一文中谈到的那些事一样。这表明着你对系统的全面和深入的了解。

在 这个阶段，需要对业务模型，数据流，业务流，系统架构，算法，和各种技术有深入的了解，要了解到本质上来。比如，在第一重门中，我们只需同要知 道，Java有同步关键字，在这一重门中，我们还要知道同步或互斥对性能的巨大伤害性，在第一重门中，我们只需要知道STL中的智能指针或是STL的用 法，这一重门中，我们还要知道智能指针中的refcnt的同步加锁对性能的损害，还需要知道STL中容器的size()方法在某些时候是性能很差的。在第 一重门中，我们需要知道hash表的效率，在这一重门中，我们还需要知道hash表的碰撞问题。

最重要的是，在这重门重点是软件的设计问题。你需要有足够多的经验能比较不同设计方案的优缺点，比如TCP和UDP，同步和异步，epoll和select，push和pull，水平扩展的各种方案…… 还记得本站的那篇“程序员的谎谬之言还是至理名言”，广度是你深度的副产品。所以，这重门是看你的技术视野有多深有多广。

三重门：业务智能

这 重门可能是最难的一重门了，如果你能进到这重门里，你应该是科学家级的程序员了。让你有智能的业务，这个事可能是顶级的技术难题了。第一和第二重门都不算 难，这重门是最难的。参看Amazon的个性化推荐系统，或是Google搜索引擎的结果个性化推荐等等（比如我输入“黑天鹅”关键字，你怎么知道我要找 的是动物，电影，还是本书？怎么让搜索出来的结果排名即公正又可个性？），你就知道，用技术来解决这种类似的问题难度可想而知，不然就不会出现如 Hadoop之类的技术了。

我再举两个这重门里的业务方面的例子。

  • 一个例子是关于库存计划的，需要像天气预报一样 预测未来的销售量从而决定库存，所以，最简单的做法是，监测各个商品的销售统计，然后看一下最近的销售趋势，还要看一下往年的销售趋势（因为某些节假日会 是一个高峰期），还要分析一下大众的喜好变化，比如，在某影评网站上的某电影的热度其会告诉我哪个电影的DVD要滞销了，得打折卖，哪个电影的DVD要畅 销了，得多进货了。还可能需要监控新闻评论，比如某权威人士推荐了某个商品，那么我得赶快进货了。等等。这完全就是一门科学。
  • 还有一个例子是配送问题。我有一辆卡车要处理我仓库和配送站间的物流问题，我需要找到一条最经济的路线来在有限的时间内处理最多的物流。这个不是最短路径问题，这是个计划统筹学的东西。也是一门科学。

还有近期“方韩之争”里有很多人来分析文章相似度的技术，这些东西都属于三重门里的东西。

到了这重门里，可能技术反而不是重要的了，而是数学模型。这重门里主要是业务模型，数据模型和算法问题。这些东西和你的业务模型密切相关。能解决这样的问题，是真正的大牛。对于我来说，可能是高山仰止了。

后记

通过上面的说明，我们可以看到下面这些东西，

  • 一重门像是开垦荒地，二重门像是扩大生产，三重门像是精耕细作。
  • 一重门（业务实现）里聚集着大量的劳动密集型的企业，劳动密集型的企业通常都需要流程和方法论。敏捷过程改进这类的东西只在一重门里。
  • 二重门和三重门里只有少数不多的技术型的公司。这类的公司通常非常注重技术，并且是企业文化是工程师的文化。
  • 三重门里可以产生的创新和那些可以用来改变世界的技术。
  • 国内现在的情况是，一重门优化阶段 + 二重门的学习阶段。三重门里似乎还没有什么见术。不过，我看到一些公司已在尝试三重门的东西了。
  • 作为技术人员的你，如果你想跟上时代，让自己有价值的话，你至少要达到二重门。
  • 因 为国内的技术环境等不良因素，导致大量的程序员在一重门的时候就已经失去信心，或被大浪淘沙淘掉了，所以，二重门里的程序员比较少了，但是随着年轻的一代 和技术的日趋成熟，也会慢慢多起来的，我现在已经看到这个趋势了。而三重门里的程序员成了稀缺的大熊猫。因为大量的二重门程序员干到那个时候都转管理了。

我的这些言论不一定对，但希望能让大家有启发，有所思考。

注：本来这篇文章的标题想取成“程序员要解决的三种问题”， 但是因为过年都在关注 “方韩之争”，所以，干脆取成了这个名字。你可以认为我比较调皮，也可以认为我爱ZB，还可以认为我标题党，反正，请随意理解。（这篇文章是我的自己写 的，没有代笔，因为你一定会在这篇文章中看到属于我的用五笔打出来的错别字，当然，我无法自证，哈哈）

（转载时请注明作者和出处，请勿用于商业用途）