分类目录归档:编程

MySQL 5.7的JSON数据类型

The 2018 World Cup is fast approaching, with national sides making their final preparations ahead of this summer’s tournament.

We now know the groups after December’s draw. England have been put together with Belgium, Tunisia and Panama in Group G.

Gareth Southgate’s side were not among the top seeds, meaning they featured in pot two during the proceedings.

And with England’s route now mapped out, Southgate will be able to ramp up preparations for the 2018 tournament. 2018 World cup, football News ,Gaming ,Betscore ,Casino …..Sports.vin

PHP中的traits

  PHP 5.4中的traits,是新引入的特性,中文还真不知道如何准确翻译好。其实际的目的,是为了有的场合想用多继承,但PHP又没多继承,于是就发明了这样的一个东西。
Traits可以理解为一组能被不同的类都能调用到的方法集合,但Traits不是类!不能被实例化。先来例子看下语法:

复制代码

trait myTrait{
function traitMethod1(){}
function traitMethod2(){}

}

//然后是调用这个traits,语法为:
class myClass{
use myTrait;
}

//这样就可以通过use myTraits,调用Traits中的方法了,比如:
$obj = new myClass();
$obj-> traitMethod1 ();
$obj-> traitMethod2 ();
>

复制代码

接下来,我们探究下为什么要用traits,举个例子,比如有两个类,分别为business(商务者)和Individual(个人),它们 都有地址的属性,传统的做法是,再抽象出一个这两个类都共同有特性的父类,比如client,在client类中设置访问属性 address,business和individual分别继承之,如下代码:

复制代码

// Class Client  
class Client {
private $address;
public getAddress() {
return $this->address;
}
public setAddress($address) {
$this->address = $address;
}
}

class Business extends Client{
//这里可以使用address属性
}

// Class Individual
class Individual extends Client{
//这里可以使用address属性
}

复制代码

但假如又有一个叫order类的,需要访问同样的地址属性,那怎么办呢?order类是没办法继承client类的,因为这个不符合OOP的原则。这个时候traits就派上用场了,可以定义一个traits,用来定义这些公共属性。

复制代码

// Trait Address
trait Address{
private $address;
public getAddress() {
eturn $this->address;
}
public setAddress($address) {
$this->address = $address;
}
}
// Class Business
class Business{
use Address;
// 这里可以使用address属性
}
// Class Individual
class Individual{
use Address;
//这里可以使用address属性
}
// Class Order
class Order{
use Address;
//这里可以使用address属性
}

复制代码

这样就方便多了!

如果你做的事情毫不费力,就是在浪费时间

  注:本文作者 Heidi Roizen 系 DFJ Venture 合伙人,曾任苹果公司主管开发者关系的高级副总裁,女性创业者。

Heidi Roizen女士一度是硅谷人人争相学习的典范。她曾创办自己的公司并管理了 14 年之久。后来,她担任苹果公司主管开发者关系的高级副总裁。现在,她是 DFJ Venture 的一位风投家,她还在斯坦福主讲一门名叫“企业家精神”的课程。她几乎认识硅谷的所有重要人物并且灵活地运用着自己的影响力。哈佛商学院甚至还有专门关于 她的案例。

以下是 Roizen 提出的八条原则,她正是利用这些原则来指导自己的工作、建立起广泛的人际网络并不断推动创新。这些过来人的经验对于新入行者弥足珍贵,可以作为职业生涯各个阶段发展重要的领航灯。

1)如果你做的事情毫不费力,那就是在浪费时间

梅琳达·盖茨曾有一次路过小女儿的房间,看着她在尝试着自己穿鞋,她女儿说:“这很难,但是我喜欢困难的事。”

我喜欢这种态度。在你经历过很多困难时期后,你会发现渡过难关是你最美好的经历。

成功的创业者追求一种永不止步的状态。你努力工作,超越能力的极限,不断地尝试、失败、再尝试;你每天、每周都问自己“我还能做什么更有难度的事情吗”,这时你才能理解这种劲头。

有趣的是,很多怀有雄心壮志的人却力求消除工作中的困难。他们想平步青云,顺利到达梦想彼岸,这是不对的。”现实情况是,即使你真的轻松成功,你也会感到无聊。所以,找点困难的事情做吧。

  创业的美妙之处正在于其艰难。没有安全可言,没有稳定的收入,你必须完全靠自己。

2)你的品德决定了你生活的基调

做第一家公司 T/Maker 的 CEO 时,曾有一次防火洒水器故障毁掉了所有库存商品。幸运的是,大多数产品都不太值钱。更幸运的是(从另一个角度说),房东不知道货品不值钱,愿意用保险赔付一切损失。

当时的条件确实很诱人,我们本可以收到 15 万美元的赔款。但是我们决定说出真相,因为不仅我们知道库存的价值,我们的员工也知道,如果我们决定作假,那我们怎么向员工交代。

你要成为员工的榜样,清楚自己所做每件事的后果。如果公司领导层决定收了这笔钱,那就等于告诉员工,作假是被允许的,就好像是在说:“虚报费用是没问题的,如果想要的话把多余的设备带回家也行。”

这看起来轻而易举,但是真正做到却不容易。你可能会想:“我可以怎么简单怎么来,我可以这么说,我可以对消费者撒谎来达成交易。”

  有时你能逃脱掉,有时却逃不掉,大多数情况你最终都是逃不掉的。

  3)你的内心比你掌握更多的信息

你的行为决定了公司的文化基调。做有些事是为了晚上能睡个安稳觉,另一些是为了搭建良好的工作关系。当你把标准定得更高时,你会发现更容易把持自己。

在斯坦福商学院,有一门“商业创新”课程,要求学生进行一周练习:睡前把你明天要做的一个决定写在纸上,第二天早上起来立即做决定。这个练习的目的是告诉学生直觉是如何做决定的,以及直觉能够有多么准确。

但是科技圈的认知却朝向相反的方向发展,做决定越来越靠无尽的数据。人们认为掌握的数据越多就能作出正确的决定。对于有些事情来说,这种方法是有效的,但是并不是所有事。内心的直觉建立在多年的经验以及对于人类行为持续不断的观察上。我们甚至不知道它的具体形式。

我在做一些艰难的决定时往往会听从直觉,尤其是涉及到人的时候——和谁工作,和谁保持联系,把谁炒鱿鱼等。每次数据指示和我想的不一样时,听从数据都会让我后悔不已。

4)挑选团队是你要做的最重要的事情

  绝大多数公司的成败都取决于团队的质量。

过去这些年里,Roizen 见过太多年轻的创业者犯同一个错误:他们有一个创意,开了一家公司,但是当需要聘用管理人员的时候,他们不想找一个比他们更懂的人来做。他们不想被威胁, 所以就找跟他们同龄,和他们懂得一样多的,找自己信任的熟人。这种做法听起来不错,但是同时,创业者因为怕被压制或大权旁落而错失了许多专业人才。

5)如果你希望成为团队内最聪明的人,那你会建立一支平庸的队伍。

你真的希望你负责销售的副总比你还不懂销售?你想要你的 CFO 不如你懂财务?当然不是。你应该去冒险,找到正确的人,并且信任他们。你的工作是激励这些人,并确保他们和睦相处。

我的目标永远是成为团队里最笨的人,我希望我的身边都是些真正有才华的人。这才是让人兴奋的事情,我们才能完成最艰难的挑战。

6)生活真的是反复无常的

倒霉事儿会发生在你头上,你会失败,失控的事情会发生,你需要接受现实。在这种境遇下,你如何挺过去,坚持到成功呢?一条建议:把事情都想成一团糟。

  快乐的关键是降低你的预期。这并不是说你不应该追求自己的目标,这意味着你应该对前进路上的不完美做好准 备。比如说,Roizen 出国旅行时会设想行李丢失、航班晚点或是租的车没有按时到达等各种情况。我想到了各种事情最坏的结果,那么当坏事真的发生时,我也不会感到难过。我在随身 行李中放了换洗衣服,我在落地两小时内没有安排任何会议。我预期很低,如果坏事没有发生,那我就会很欣喜。95%的压力都是自找的。

Roizen 想起她认识的一位总是严谨制定计划的创业者,每一件事都计划得滴水不漏,但是实际上事情从没有完全按计划施行过。

如果你期待每件事都顺利进行,坏事就可能会落到你身上。生活有时候可能很遭,当这种情况真的发生时,整顿行装,继续前行。

  如果你跌倒了却爬不起来,那么你的余生也将一事无成。

记住,就像硬币的两面一样,生活的跌宕也可能带来好事。当机会来临时,不要错过,你不知道接下来会发生什么。如果你得到 3 个不错的工作 offer,不要总想着选个最正确的。

可能你选了一个不太好的工作,业绩不好,你被炒了,但以后可能还有更好的工作机会。而且在这份工作中学到的经验教训在另一份更稳定的工作中是得不到的。

Roizen 回忆起自己不久前看的一本书,书中说在问到过去 5 年发生过的最好和最坏的事情是什么时,大部人说出的都是同一件事,甚至包括离婚、得癌症或是失业等。

但当你接着问他什么是促使生活向好的方向发展的事情时,往往就是这些坏事。有时,接受生活的起伏,你会发现一些伪装起来的好事。

7)充分利用时间

  你所拥有的最重要的东西就是你的时间,因为你不能创造更多时间。

你可以用钱或他人的帮助来节约你的时间,但是,最终你还是会用光自己的时间。所以,你需要对自己如何利用时间了如指掌。很多人不知道每件事情花 了多少时间,他们有 1000 封未回复的邮件,却还说不知道怎么处理。解决方法就是每天安排的工作不要超过 5 个小时,留出 3 个小时回邮件,打电话,阅读,获取最新消息。当别人说没时间时,我会说,你当然有时间,但你用来做别的事情了。

想想所有需要花时间的事情,开始时对它们一视同仁。你要明白,睡觉是花时间的,阅读也是花时间的。搞清楚你喜欢做什么,什么能够最大限度的拓展 你的能力,然后重新规划时间,把时间花在正确的事情上。理想的情况是,你能留出一些时间用来思考和睡觉,但是 Roizen 说有时候也确实很难实现。

在工作上花更多的时间就意味着陪家人和朋友的时间少了。人们有一种幻觉认为关系和交流不需要用时间来维系,但是实际上不是这样的。你可能没法完全平衡你的时间,但是至少试着来。

  如果你不给你自己留时间,那就没时间做些正确的事,总会有各种突发情况。

  8)20-40-60 法则

演员 Shirley MacLaine 最早提出了这个法则,主要内容是:20 岁时,你总在担心别人是怎么看你的;40 岁时你觉醒了,我才不管别人是怎么想的。60 岁时你才发现,根本没人管你。这个法则的核心理念就是:从一开始就没有人想着你。

当然,这既是好事儿,也是坏事。坏处在于没有人在一直关心你好不好,挣多少钱,你对工作和人际关系是否满意。“你需要为自己着想,如果你在做一件不喜欢的工作,你需要自己做出决定是否换个工作,你不能在办公室等着别人帮你做决定。

  你的老板不会想着你,你的同事没有想着你,你需要替自己着想。

  这听起来令人难以接受。有些人花很多时间思忖别人是怎么看待自己的,深受折磨,其实完全没必要这样。

我曾经也总是顾虑长途飞行后穿着不合时宜的鞋和褶皱的套装时开会是什么状态。我会很担心人们看到我连自己都收拾不利索会怎么看我。但是,有一次开会时,我发现,并没有人认为“虽然这个家伙很聪明,但是他衣冠不整,这人肯定不行”。

人们总是为一些犯过的小错误折磨自己,在会上说错话,叫错人名等。你可能浪费几个星期的时间来懊恼,导致工作效率低下。如果你发现自己是这样的,那么请记住:没有人像你自己一样关注你。所以就不要担心太多了。

【本文原载于微信公众号“LinkedIn中国”。LinkedIn领英是全球最大的职业社交网站,会员人数在世界范围内超过3亿,每个《财 富》500强公司均有高管加入。LinkedIn微信(ID:linkedin_china)每日推送深度文章,汇聚全球商业领袖的思想精华。】

本文系作者 LinkedIn领英 授权钛媒体发表,并经钛媒体编辑,转载请注明出处和本文链接

继续阅读

如何避免软件工程中最昂贵错误的发生

  英文原文:The Effective Engineer

影响软件工程进度的原因有很多种,而代码重写无疑是最耗费时间的变更之一。那么重写的时候需要注意哪些细节才能把资源开销控制到最低或可接受的程度呢?本文作者Edmond Lau在其博文中进行了阐述。以下为译文。

前几周,一位年轻的初创企业工程师过来寻求我有关代码重写的建议。其管理层希望她的团队在4周内完成Web产品的代码重写工作。这已进行了3个 多月,但估计还要多花2个月才能完成。她们每周的工作时间将近80多个小时,伴随的还有一堆堆的错误需要更改。时间对于初创公司来说无疑是重中之重,她们 该如何处理目前这个困境呢?

在我职业生涯早期,也曾碰到过类似的困境——原本估计4个月完成的项目,在通过重写后,最终用了9个月才完成。在这个痛苦的过程里,最令人抓狂 的事情之一是如果市场出现新的机遇,由这引起的改动是最优先的。换言之,我们只能不断的缝缝补补。打这以后对于项目重写,我变得慎之又慎。

  Google Docs的故事

在今年初,我与Sam Schillace会面时也讨论过有关重写的问题,它是Box的技术副总裁,前Google Apps负责人。我向他提了一个问题,“你们工程团队曾遇到过的最昂贵的错误是什么?”

他的回答是,“尝试从零开始开展代码重写。”

Schillace的创业公司在2006年被Google收购了,他们当时的团队有4人,产品名字是Writely即Google Docs的前身。在他们发布了一个试验性的C#原型作品后,用户数很快就突破了50万。加入Google后,他们收到的第一个商业任务是进行项目迁移,从 而充分利用Google的架构体系以实现高容量和高扩展性。每天用户数仍在快速增长,而他们也开始意识到之前所写代码的扩展瓶颈。

我还在Google工作时,我知道Google的软件堆栈是不支持C#的。所以当Schillace说到这里时,我很自然地问到,“当你们进行Writely到Google Docs的转换时,你们是不是只能从零开始?”。

Schillace的回答是,“是的。”当他们开展重写工作时,有个合伙人提出边转换边重写,因为如果进行彻底推翻,将极大增加工作量。 Schillace并不认同。最终,他说服团队只设置一个非常有限的重写目标,延后其它更多的目标工作。他们定下一个清晰的目标先把系统在Google数 据中心运转起来,然后再整合12种不同的Google技术。他们花费了一个星期来调试并最终编译成功。调试过程中,很多错误是由于Java和C#不同的语 义表达引起的,例如==双等号的不同含义。

“这真的真的非常痛苦。”Schillace说道。继续奋战12个星期后,他们最终完成了一个“令人惊讶的,奇怪的,晦涩难懂的”代码库。但它 也最终在Google数据中心里成功运转了,这也创造了一项纪录—被收购后最快适应Google架构的转换项目。如果他们不是摒弃了过多的目标,也许还不 能这么快就完成。同时如果他们把更多精力放在代码质量上,时间也会用得更多,因为需要修正一堆堆的正则表达式。相反地,他们的目标是使Writely先尽 快运转起来。

  经验教训

以上所说并不代表重写或推倒重写就是绝对的对或错。MongoDB的创始人Eliot Horowitz曾说过,“我们应该把代码看成有3-5年的半生命周期,因此应该定期进行更新。”MapReduce,Bigtable等技术的Google架构师Jeff Dean也曾说过,“我们不妨以放大10倍的规模来设计软件,这样一来我们会发现它的与众不同。”

如果我们一口气就把整个代码进行重写,问题便会出现。我们会倾向于低估了开销而高估了益处。

当我们缺乏经验时,这是很正常的。我们没有足够的底气和知识来阻止过激的进度计划,同时也没有划分好先后优先级的技能。我们可能会想,一个好的工程团队会有人能完成这一切。因此可能会认为只要按部就班、兢兢业业地去做事就万事大吉了。

经过一段时间历练,也不一定就能避免所有错误,因为评估工作仍然复杂而我们也会因为有了经验而高估了自己。这是一个有关虚幻优越感的事例。如果 你去调查100位驾驶员的驾驶水平,80%的人会认为自己的水平是中上的。如果调查100位教练,68%的人会认为自己处于前列。类似的情况在IQ测试, 自我评价等测评中屡见不鲜。所以,对于软件工程师来说,很自然会认为不能按时完成任务只会在较低水平团队中出现,所以当真的出现超期情况时,会使得重写工 作一再拖长。

一旦重写出现超期,我们往往会自欺欺人地认为只要多加几天班,多开几次会就能把进度赶上。我们也不会再去想别的途径。一两次或许可以侥幸通过,但长期来看这是不能持续的,“罗马非一天建成”。

  最佳的策略是全方位评估推倒重写的价值。如果需要这样做,例如Schillace所做的,不妨为项目设置一 个有限的目标集合然后使之尽快实现并不断完善。如果你所在的团队陷入了一个一再延迟的项目,你需要站出来,指出商业目标和实际工作的差距—看是否需要减少 过多功能,是否需要设置更切实可行的目标,是否把项目看成是沉没成本而彻底终止。对于采取何种策略,需要实事求是,而不能生搬硬套。(编译:伍昆 责编:张红月)

【转】什么是程序员的核心竞争力?

如题所说,我现在是个刚毕业的小本,野鸡学校,而且不是正统的计算机专业,现在踏入了程序员这一行,到底什么样的技能才是才是程序员的核心竞争力,换言之,我在工作的前几年,需要累积什么样的技能,之后才能更好的和老板要工资,提要求。

图片来自 yestone


姚冬,招聘音视频相关算法工程师

学 习能力,尤其是自学能力,你啥时看到那些有名的程序高手在论坛上问“学习 XX 该看什么书,如何快速学习 XXX,学习 XXX 有什么代码推荐”之类 的问题,他们想学什么很快就能自己找到相关资料。这个行业发展太快,技术淘汰的速度也很快,3 年不学新东西就可能落伍了。

动手能力,都是看书看资料,当别人还在纠结看什么书,还在纠结书里的字句是什么意思的时候,有些人的几百上千行代码都已经能运行了。

耐心和毅力,做程序员兴趣固然重要,写自己喜欢的代码那是相当愉快的事情,但是程序开发中无论如何还有大量乏味无趣的事情,要能坚持,咬牙把这些做完。

表达能力,能在大庭广众下,把自己的想法逻辑清晰流畅地讲出来,让人听懂。

那么技术呢?技术不重要,有了以上几种能力,市场上需要什么技术,很快就能掌握了。

最后再说说工资的事,记住两句话:

工资不是老板对你过去贡献的回报而是对你未来贡献的预期。

现任老板不可能给出让你满意的工资,下一任老板才会。

曹政,数据控/历史控/考证控

姚冬回答的非常好,我狗尾续貂的说几句。

我们都知道学习能力很重要,那么学习能力从何而来,除了去看书上课这种,如何在实践工作中学习成长?

我之前微博说了一个笼统的概念,什么是能力? 对待问题的态度,以及处理问题的思路和方法。

先说态度

你服务器偶尔出 501 错误,也许比例不高(知乎也出现过很多次),很多程序员,没错,是很多,假装看不见,不在乎,或者归咎于人品问题。 这就是态度问题。

再 往后,负载高了或者其他什么原因,突然频繁出现 501 错误,不去追寻深入的原因,而是找各种借口, 什么 IDC 服务商不好,服务器品牌不好,操作 系统不好,数据库不好,CDN 不好,网络状况不好,web server 不好,甚至,直接对 Boss 说我们被 DDOS 啦!(遇到过,帮 他 Boss 找过多个安全专家会诊,最后发现根本不是 DDOS,是程序员太烂。)

这就是态度,触目惊心,如果能对问题有敏感性,能知 道对任何小的,轻微的问题有足够的敏锐度,你就有了一个快速成长的基础。对问题的敏锐度是非常重要的。很多性能或程序逻辑上非致命的 bug,在不够敏锐 的时候是发现不了的,但是一旦进入特殊场景就会骤然爆发,你多一点敏锐度,就会减少这种危机的风险。

第二个态度是解决问题的态度,有人对 自己的解决方案信心满满,认为万无一失,但有的人就会多留一条后路;就好比你说我服务器要不要做安全加固,肯定要做对不对,要做到尽可能严谨和周全,但是 你数据库保存密码的时候是不是还要加密?而且要随机 salt,不就是防止万一依然有漏洞被人拿库怎么办么。程序也一样,以前写的一些服务端守护进程, 有 bug,会莫名其妙的终止,这个 bug 当然要定位,要修复,但是同时,写一个 cron 检查这个守护进程状态,一旦遇到终止给予自动恢复,这就 是第二手准备,即便你多么不希望他执行,这个准备还是要做的。对问题做两手甚至三手准备,也是优秀程序员,架构师的关键素质。

第三个态度 是基于沟通与理解的态度,产品或运营提了一个不靠谱需求,一句话打回去当然很爽很威风,但是有没有仔细沟通分析过,这个需求基于怎样的实际诉求,这个实际 诉求有没有更合理的实现途径,一句话“这个没法做,这个实现成本太高”,不是正确的沟通态度,而且,最优秀的产品,往往是实现了那些原本人们认为无法实现 的诉求。

这样的态度,才有了一个持续进步的基础,下面说思路和方法。

优秀的程序员和平庸的程序员,如果只看敲打代码的速度,我觉得是分不出来的,也许每人都可以一天写很多行代码,但是遇到问题后,平庸的程序员的解决效率,和优秀程序员相比就会有天壤之别。 所谓解决效率,不外乎对 bug 的分析、定位,以及思考。

最基本的一条,看执行日志,看各种日志,web server 的日志,数据库的日志,慢查询日志,binlog 日志,php 的错误日志,等等等等,线上出问题瞎猜连日志都不看的大有人在。看日志不仔细不完整的也大有人在,你能去认真研究日志已经超越很多人了。

第 二条,模块测试和断点分析,程序员一个坏习惯就是上来就写很大一坨代码然后再执行,不知道一个模块一个模块来写来测试,执行出了问题不知道设置断点,缩小 范围逐步分析。断点分析非常简单,将整个代码中插几个中间输出,观察哪个环节出了问题,或者观察每个环节的系统开销,对调错和性能优化都非常重要,高手们 大概认为这是 ABC 的东西,但是就这玩意我看到的大部分程序员都没有这个习惯。

第三条,错误信息的理解和搜索,搜索引擎上有各种丰富 的技术资料和技术问答,你所遇到的错误信息和错误提示,通常都能在网上搜索到,当然,搜索到后要结合你的场景认真思考,并理解透彻,而不是照猫画虎的去处 理,否则可能这次运气好就蒙对了,下次运气不好又不知道怎么回事了。

第四条,不断总结归纳,对一个问题,一类问题,以及不同类型的问题, 善于归纳整理,不断反思自己的问题,即便是不出 bug 的代码,你经过一段时间去回头看,也有很多思考不正确不合理的地方,有很多优化点,如果你觉得自 己的代码一向牛逼,毫无破绽,那你一定是原地踏步,毫无进展。

关于归纳总结,我说个案例

以前我们有个系统,请求量非常大,负载非常高,有个不错的技术经理来处理,他列了几个升级计划,都很靠谱,去执行了,效果非常好,然后我们跟进汇报的时候他来讲,做了几项升级,整体效果如何,然后我就批评了他。

我 批评了什么呢?他是一起做的升级,然后一起观测的效果,那么这几个方案里,具体每个方案的实际效果怎样,对提升的帮助多大,他没有任何数据。所以对具体每 个升级方案的价值和重要性,他没有任何概念。你正确的解决了问题,却没有认真的去归纳整理,你的收获是有限的。一起做升级不能说是错的,但是效果评估需要 单独去做,而这个数据是非常有价值的,知识积累,不是你处理过的就一定有积累,而是整理过的。

大概就这些

最后重述一遍

什么是能力?

遇到问题的态度

处理问题的思路和方法

这就是能力