Browsed by
标签:程序员

一次Ajax查错的经历

一次Ajax查错的经历

先说故事,再说想法吧。

我有一朋友做网站,用jQuery的Ajax方法从后端载入一段HTML代码然后动态插入到网页的Div元件中。这个东西太普遍了。jQuery强大的load方法可以完成这个事情。朋友的代码是这么写的:

var tab = jQuery("#dynamic_tab");
var url = "/list_ajax/";
tab.load(url);

简单到不能再简单了。在Chrome,Firefox,Safari下运行一点问题也没有,只有IE不行,不管是IE7,IE8,还是IE9。问题的症壮是,使用IE访问那个Ajax的链接,没有问题,但是在jQuery的Ajax方法返回了“undefined”的respons对象。没有任何报错!

怎么搞也搞不定,只好Google了一下——“jQuery load IE”,一看,很多人都在问这个问题。于是开始了散弹枪编程方式

排在第一的就是StackOverflow被浏览了33K次的这个问题:jQuery’s .load() not working in IE – but fine in Firefox, Chrome and Safari,答案没有被打勾(不靠谱),StackOverflow还有很多人问相似的问题,不过都没有答案。不管三七二十一,先试了一下,散弹枪嘛。试了半天都没有用。

然后上Google查,又看到有人说的IE缓存的问题,什么,要把cache设置成false,或是用下面的方法来解决:

var tab = jQuery("#dynamic_tab");
var fuckie = Math.random();
var url = "/list_ajax/"+"?fuckie="+fuckie;
tab.load(url);

反正还是一样,统统不Work,几乎所有的都试了,都不Work。搞了一天的朋友恼怒道:“Microsoft应该快点倒闭吧,产品太烂了”。IE的确是太烂了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (20 人打了分,平均分: 4.55 )
Loading...
为什么我反对纯算法面试题

为什么我反对纯算法面试题

算法面试可能是微软搞出来的面试方法,现在很多公司都在效仿,而且我们的程序员也乐于解算法题,我个人以为,这是应试教育的毒瘤!我在《再谈“我是怎么招程序员”》中比较保守地说过,“问难的算法题并没有错,错的很多面试官只是在肤浅甚至错误地理解着面试算法题的目的。”,今天,我想加强一下这个观点——我反对纯算法题面试!(注意,我说的是纯算法题)

图片源Wikipedia(点击图片查看词条)

我再次引用我以前的一个观点——

能解算法题并不意味着这个人就有能力就能在工作中解决问题,你可以想想,小学奥数题可能比这些题更难,但并不意味着那些奥数能手就能解决实际问题。

好了,让我们来看一个示例(这个示例是昨天在微博上的一个讨论),这个题是——“找出无序数组中第2大的数”,几乎所有的人都用了O(n)的算法,我相信对于我们这些应试教育出来的人来说,不用排序用O(n)算法是很正常的事,连我都不由自主地认为O(n)算法是这个题的标准答案。我们太习惯于标准答案了,这是我国教育最悲哀的地方。(广义的洗脑就是让你的意识依赖于某个标准答案,然后通过给你标准答案让你不会思考而控制你)

功能性需求分析

试想,如果我们在实际工作中得到这样一个题 我们会怎么做?我一定会分析这个需求,因为我害怕需求未来会改变,今天你叫我找一个第2大的数,明天你找我找一个第4大的数,后天叫我找一个第100大的数,我不搞死了。需求变化是很正常的事。分析完这个需求后,我会很自然地去写找第K大数的算法——难度一下子就增大了。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (39 人打了分,平均分: 4.82 )
Loading...
对技术的态度

对技术的态度

最近人品爆发,图灵社区,InfoQ,51CTO相继对我做了采访,前两天我把InfoQ对我的采访张贴了出来,今天,图灵社区和51CTO对我的采访发布了(图灵的访谈 ,51CTO的访谈),我是一个有技术焦虑症的人,我的经历比较特殊,对大家来说可能也没有什么意思,这两个采都有一些重叠的部分,不过有些观点我想再加强一些,并放在这里和大家一起分享一下。

对于日新月异的新技术,你是什么态度?

遇到新技术我会去了解,但不会把很大的精力放在这些技术(如:NoSQL,Node.js,等)。这些技术尚不成熟,只需要跟得住就可以了。技术十年以上可能是一个门槛。有人说技术更新换代很快,我一点儿都不觉得是这样想。虽然有不成熟的技术不断地涌出,但是成熟的技术,比如Unix,40多年,C,40多年,C++,30多年,TCP/IP,20多年,Java也有将近20年了……,所以,如果你着眼成熟的技术,其实并不多。

我的观点是——要了解技术就一定需要了解整个计算机的技术历史发展和进化路线。(这个观点,我在《程序员练级攻略》和《C++的坑多吗?》中提到过多次了。)因为,你要朝着球运动的轨迹去,而不是朝着球的位置去,要知道球的运动轨迹,你就需要知道它历史上是怎么跑的

如果要捋一个技术的脉络,70年代Unix的出现,是软件发展方面的一个里程碑,那个时期的C语言,也是语言方面的里程碑。(当时)所有的项目都在Unix/C上,全世界人都在用这两样东西写软件。Linux跟随的是Unix, Windows下的开发也是 C/C++。这时候出现的C++很自然就被大家接受了,企业级的系统很自然就会迁移到这上面,C++虽然接过了C的接力棒,但是它的问题是它没有一个企业方面的架构,而且太随意了,否则也不会有今天的Java。C++和C非常接近,它只不过是C的一个扩展,长年没有一个企业架构的框架。而Java在被发明后,被IBM把企业架构这部分的需求接了过来,J2EE的出现让C/C++捉襟见肘了,在语言进化上,还有Python/Ruby,后面还有了.NET,但可惜的是这只局限在Windows平台上。这些就是企业级软件方面语言层面就是C -> C++ -> Java这条主干,操作系统是Unix -> Linux/Windows这条主干,软件开发中需要了解的网络知识就是Ethernet -> IP -> TCP/UDP 这条主干。另外一条脉络就是互联网方面的(HTML/CSS/JS/LAMP…)。我是一个有技术忧虑症的人,这几条软件开发的主线一定不能放弃。

另外,从架构上来说,我们可以看到,

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (31 人打了分,平均分: 4.90 )
Loading...
InfoQ的ArchSummit大会对我的采访

InfoQ的ArchSummit大会对我的采访

偷个懒,做个更新,今天下午InfoQ的ArchSummit对我的一些采访。我整理了一下,算做是我个人写酷壳的一些想法和总结。不过问我的这些问题并不尖锐,呵呵,不像@图灵谢工 问我的问题:“你的价值观太过理想,根本不现实,你站在道德的高点拷问社会,是不是想炒作自己?”。

1) 作为酷壳的博主,请您大概介绍下酷壳是什么时候开始的,初衷是什么 ?

我写blog是从2002年开始(那时还没有blog这个词),当时对我来说,没有自己的电脑,上网很不方便,而我有写学习笔记的习惯,读书和工作中学到的一些东西需要保存在某个地方,我希望这个地方可以让我在任何地方都可以调出来看看(因为我当时的工作出差太多),正好当时的CSDN有个“专家专栏”的功能,也就是后来出现的blog。

后来Blog出现后,CSDN把自己的“专家专栏”全部迁移到了blog.csdn.net上,07-08年这段时间,CSDN的blog基本上是不能使用,性能差得不能再差,每天宕机,上传图片,贴代码,都非常不好用。也许,这就是使用.NET/Windows平台的问题(开个玩笑)。

我是从2009年3月开始创建酷壳的,创建的初衷如下:

  • 我需要一个更稳定,更方便的地方,我的博客的风格不会被大众的风格所掩盖的地方。
  • 我的从事新闻的老婆很不待见我在CSDN的博客,她觉得太技术,书呆子。
  • 我正好看到了煎蛋这个国外娱乐新闻文摘的blog,而我正好每天会有2个小时阅读国外社区的东西。

基于上述三个原因,我自己花了4500元/年租了个主机,建了酷壳。所以,这也是你一开始看到酷壳基本上是娱乐性比较强的博客,我收集一些比较有意思的程序员中发生的事情,也收集一各式各样的程序员圈子里的各处观点。

我当时的想法是,一些特别技术的东西,我会和CSDN同步,而一些轻松的话题,我会放在酷壳。我当时的初衷就是想说明程序员并不是一个木纳、书呆子、不食人间烟火、巨无趣的一个群体,程序员圈子里同样也有很多有趣的东西。所以,你可以看到11年初以前的东西我有很多网络恶搞式乱调侃的语言。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (19 人打了分,平均分: 4.74 )
Loading...
做个环保主义的程序员

做个环保主义的程序员

十多年前刚走入社会工作的时候,那时的中国软件开发根本没有什么版本管理,也没有什么编程规范,软件开发相比起今天来说非常地混乱,那时仅凭自己的一些学习总结了一些C语言编程中的好的小笔记,后来,这些笔记写成了一篇叫《编程修养》的文章。今天,又有些感触,想把这个话题扩大一下,从“个人修养”扩大到“环境保护”,所谓,穷则独善其身,富则达济天下,今天的技术人员比十多年前在技术和环境上都富有了许多,所以,也应该或多或少地担负起“达济天下”的责任了。

环境保护说白了就是保护一个良好的环境,为好的环境添砖加瓦,与破坏环境的人和事做斗争。其实,从技术人员来说,我们可以做一些力所能及的事。因为我们身边的技术环境还有很大的改善的空间,而一些来之不易的东西还需要我们去小心维护。另外,对于我们自己来说,少吃一些垃圾食品,健康生活,对自己也有益。

环保主义软件开发

先说说软件开发中的环保。比如:

  • 环保需求。当我们分析需求的时候,如果我们能做到不要像“这是到底是谁的错”一文中那样的来者不拒,如果我们在面对需求能多问这样几个问题:为什么 要有这样的需求?这个功能主要能解决什么 样的问题?为什么不是另外那一种?可不可以简化一下?其实,我们并不需要创新,只需要真正地问好这几个问题,我们就可以少看着一些弯路,少一些苦逼的加班,少一些内耗,少一些埋怨,也就可以为这个社会节省下一些资源,从而环保。
  • 环保开发。当我们做设计写代码的时候,如果我们多花一些时间去思考一下,我们就可以少一些代码(参看“多一些时间少一些代码”)。如果我们在一开始多思考一下,不要急着马上去用迭代的方式认识世界,多思考一下怎么把复杂的东西解藕,把复杂的东西简化,怎么做出一个优雅的设计,怎么让我们的程序少一些tricky的东西,怎么让我们的程序变得更简洁,更清楚,更直,在一开始思考一下未来需求可能的变化,未来软件需要怎么测试,未来的系统需要怎么的运维,那么,我们可以少一些返工,少一些重构,少欠一些债,少一些低级错误,少承担一些系统上线后的压力,那么,我们同样可以为这个社会节约一些资源。说得再直白一点,你用更少的代码产生出更高的效益,少耗一些CPU,就能省一些电,间接地保护了环境。(参看 Why C++?
好烂啊有点差凑合看看还不错很精彩 (122 人打了分,平均分: 4.63 )
Loading...
这到底是谁之错?

这到底是谁之错?

【感谢 @风枫峰 投递本文】

故事一:
背景介绍:RT是一个外包公司,ZWZX是项目承接公司,YD是甲方。

RT公司每天下班的时候都会接到ZWZX负责人的电话,询问一天的工作情况,然后布置任务要求晚上加班做完,RT公司的员工很无奈也很气愤因为每天都要加班,员工们就问项目经理:“为什么天天加班赶需求,今天才提一个需求,明天就要上线,还让不让人活了?” 项目经理无奈的说:“我有什么办法啊?这是人家ZWZX负责人说的啊,对方逼得紧。”

多次以后项目经理也忍不住了,就问ZWZX的负责人怎么天天这样啊,ZWZX的负责人就说了:”明天就要向YD的负责人展示这个页面,我也没有办法啊?YD那边老总就是这么要求的,我怎么办,我也不想这样啊?”

然后RT的项目经理实在受不了了就辞职了,新上任的项目经理又会走他的老路,因为从开始我们就被培养“满足客户的需求是最重要的”。RT的员工也就这样一直抱怨着,一直忍受着。天天在心里咒骂YD的老总真是没有人性,不拿人当人看啊!

人换了一批又一批,加班也就慢慢的变成了应该的,你不加班说明你不敬业,不合格。

故事二:
IE6一直存活着,所有的前端开发人员都痛恨它,都不想兼容它,可是产品经理看到IE6的市场占有率还是这么高,就会要求前端开发人员必须兼容IE6。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.72 )
Loading...
挑战无处不在

挑战无处不在

面试过一些应聘者,当我问到为什么换工作的时候,他们都会告诉我,现在的工作没有挑战,无聊,所以想换一个有挑战的工作。于是我问了一下他的工作情况,发现那些有挑战的东西他还没有搞懂。我总是为有这样的认识的朋友感到惋惜,因为我总是认为有挑战的东西无处不在啊,不能因为工作上没有,自己就放纵了自己。比如,面试过一个做地图的工程师,他的工作是做计算地图上任意两点的最短或最优路径的一部分功能。我觉得这个事很有挑战,也有难度,应聘者说,没什么挑战,因为他做的东西只是调用相关的算法库。他在这个项目干了2年了,当我问他有没有看过算法库,知不知道地图是怎么存储的?他却告诉我,因为没有去做,所以就没有去了解,等做的时候再了解(我希望有这样想法的人都去看看程序员的谎谬之言还是至理名言?)。这样的例子很多,很多应聘者在面试中不能和我一起解决某个问题的时候,比如:OOD,数据库设计,系统设计,等,他们都会告诉我,不好意思,因为没有做过相关的事情,所以就不懂了,所以,他需要一个像我们这样的项目来学习和锻炼。我并不要求你能解决你所不擅长的问题,但毕竟数据库,OO,系统设计都是软件开发的基础知识,多少要懂一些吧。

但另外一方面,他们都会告诉我他们对技术充满和热情和兴趣,有着很强的学习能力,也有很能吃苦的态度。这也许是某面试宝典上看来的,面经上可能都会说,如果面对不能作答问题,可以说一下自己的态度和决心。可惜的是,我并不这么想的,我在我的两篇关于招聘的文章里(我是怎么招聘程序员的再谈我是怎么招聘程序员的)都说过一些我对如何择人的想法。这里重点说明一下其中两个观点:

  • 关于热情和态度,说白了就是不要给自己找借口。比如:“工作忙事多没时间学所以可以不懂”,“工作中没用到所以可以不懂”,“工作没有挑战,一直没有遇到合适的项目”等等。时间可以挤,工作之余可以学,随时随地去思考,挑战是无处不在的…… 想想那些你有热情的事,你会发现,几乎没有什么可以阻止你去做那些事。
  • 对于某些事情,如果以前没有在你身上发生过,那么这个事情在未来也不会发生。如果你以前没有对你接触过的东西去学习,去深挖,去思考,去改善,那么我不会相信你会在未来面对新的东西的时候也会有这样的态度;如果你以前没有用业余时间学习一些项目之外的东西,那么我也不会相信你会在未来会这样做;如果你以前没有把你的热情和态度转换成你的知识,经验和成果,那么我也不会相信你会在未来能做到。

这两个观点可能太刻薄了,但是,当我回想我自己的经历的时候,观察程序员的成长过程的时候,我发现,优秀的程序员都是相似的,当他们还在是一个菜鸟的时候,就已经有各种成为高手的苗头了,这些苗头就是——他们热爱思考,喜欢解决难题,对新鲜事物非常好奇,总是找人讨论,可以用自己的业余时间狠命研究很多和工作无关的技术,会在业余的时间里写些有趣的小程序,或是会把自己的思路书写下来,等等,等等

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (52 人打了分,平均分: 4.87 )
Loading...
我们需要专职的QA吗?

我们需要专职的QA吗?

这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去认真地深入思考,我也会高兴,如果你反对,没关系,可以讨论。

在此之前,我想说明一下我观点里的这个“专职QA”是怎么定义的。

  1. 其是很多公司成立的专门做测试的技术人员,仅测试不开发。
  2. 这些QA对于软件开发技术并不熟悉,甚至不懂。

我经历过一些公司都有专职的QA团队(专职的测试人员),自从上个公司我的开发团队在一个项目上被QA部门搞得一团糟,我越来越怀疑专职QA存在在意义。我的观点不一定对,但请让我鲜明地表达一下——我觉得是不需要全职的QA的,甚至不需要QA这一专职角色或部门,因为,不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选,这必然是未来的趋势 (因为我已经看到了中国程序员的进步,相比起10年前,今天的程序员已经是非常全面了,再来十年,必然证明我的观点是对的)。

在我正在展开说明之前,我想引用两篇文章:

两篇文章

一篇是  “On testers and testing”(中文翻译),本文的作者Sriram Krishnan是一名程序员,曾在Yahoo和微软工作过,开发过很多软件,曾被纽约时报报道,写过一本书,本文是他的一篇博客。他在文章中表达了这几个观点——

大多数的开发团队并不需要一个独立的测试角色。即使要有,那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗?光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook,还是30年前最初的NT团队,很多伟大的产品都是出自没有或很少测试人员的团队。

开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试,全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”,那你需要更好的程序员。

另一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”,这是一篇很不错的文章。他在文章里提到了分工的必要性,比如第三方的鉴定机构,并且也指出了分工的一些问题,比如,画地为牢的分工,无明确责任的分工,等,这些问题直接命中了分工的要害。我隐约觉得,我和邹欣的很多观点是相同的,我们内容上是相同的,只是形式上还有分歧。另外,我的观点太鲜明了,从而容易导向极端的理解。

你看,我们都同意,Dev要懂测试,QA要懂开发,只不过分工不同,既然你中有我,我中有你,那就不要分彼此了,一起携手开发测试吧。(另外,我个人觉得不懂开发的测试人员不可能测试得好)

—- update—- {

     //本篇文章出来后,网上出现了一些对此讨论的文章,我一并更新在这里
【 《对《我们需要专职QA吗?》的回应》作者:@段念-段文韬 】
【 《关于“我们需要专职的QA吗”》作者:@Jacky郭
【 《我们需要专职的QA吗?(评)》作者:@Monkey陳曄曄
【《 《我们需要专职的QA吗?》读后感》作者:@ 花生色魔叔

}

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (49 人打了分,平均分: 4.53 )
Loading...
Bret Victor – Inventing on Principle

Bret Victor – Inventing on Principle

Bret Victor简历) – 苹果公司的UI交互设计师(大神级的人),在 CUSECCanadian University Software Engineering Conference) 上做了一个题为 “Inventing on Principle” 的演讲(vimeo视频链接),这个演讲中展示了五个示例:

  • 用程序画树。如何把程序绘图变成实时的,如何把程序和图映射起来。
  • 游戏调试。在实时编程的基础上,可以更容易的让你看到程序参数对游戏的调整,甚至对游戏过程的可视化调试。
  • 算法调试。在写二分查找算法时可以实时看到程序的执行过程。边写边看到。
  • 电路图。可以实时地看到电路图中各个部件的对1/0信号的处理。
  • 动画。一种比flash制作动画更NB 的方法。

下面是优酷上的视频——你一定会被示例中的那些编程工具所震撼!

不过,Bret并不是在说什么编程,也不是在说什么技术,他是在说 How to live your life。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (52 人打了分,平均分: 4.92 )
Loading...
千万别惹程序员

千万别惹程序员

酷壳好久没有发娱乐性质的技术文章了,搞得气氛有点严肃了,考虑到程序员们都是比较严肃和容易较真的类书呆子的群体,所以,需要更新一个有娱乐性质的文章了。正好最近看到了两个比较有趣的图,在新浪微博上都得到了比较不错的反响,因此,更新到酷壳上来。

如果编程语言是一种刀

下面这个图是把编程语言看做是一种刀,那么会是什么样的。这个图我个人感觉很有意思。

对于这个图,最好不要解释,意会就好。不过,我却有点想不解风情,忍不住想解释一下。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (21 人打了分,平均分: 4.76 )
Loading...
软件开发的“三重门”

软件开发的“三重门”

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

前言

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

第一阶段:我 刚毕业时在家乡的某银行工作,做些银行的业务系统,还搞些网络,电子邮件系统,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。这八年多的时候,全是在和这些高计算高性能的项目打交量,几乎没有什么业务,都是纯技术,积累到了很多和性能有关的高并发高计算系统 架构级的知识。

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (45 人打了分,平均分: 4.93 )
Loading...
程序员因为女孩而美丽!

程序员因为女孩而美丽!

女程序员是程序员里美丽的风景线,我希望这些女程序员的经历能让我们在这个“重男轻女”的社会中可以给女程员有更多平等的机会和条件,以及相应的尊重因为,她们其中不乏优秀的程序员,而且在心态、态度和努力上还强过很多男性程序员,很多东西都值得我们大家向她们学习

这篇文章的来由是因为Eva在“三个事和三个问题”的评论里问我女孩子是否能做技术,她说她的很多师兄都告诉他不要做技术,所以,她有些不坚定了。我的回复是告诉了她我工作经历中的两个技术很牛的女孩,并且我从她们身上学到了多技术。但是,后面有一些人回复说我误导了别人。所以,我在新浪微博twitter上征集女程序员的故事和想法。我一共收到了19封邮件,其中有17封邮件来自女程序员。其中有一个已经发布了(一个女程序员的故事),其中的一些观点已经在网上传播,并得到了大家的刮目和称赞。但这并不是特例,因为下面的这些故事中,还有很多令人刮目相看的东西。

说明:先说明一下,这篇文章并不想讨论女孩子是不是适合做技术,这不值得讨论,因为,在“一个女程序员的故事”中我们已经知道,态度和努力才是原因,而不是性别。这里,也只是想告诉那些有“性别歧视”、“看不起女程序员”、“骄傲自大”的男程序员们,那些女程序员不为所知的一面。我把几乎所有的故事都列在这篇文章里了,我觉得我不用再多说什么了,这些故事组成的风景线,可以让你充分地了解女程序员

Ada Lovelace 世界第一个程序员
Ada Lovelace 世界第一个程序员

在看到那些故事之前,我们需要了解这样的现实——

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (25 人打了分,平均分: 4.92 )
Loading...