1. 我看团队

    谈一谈团队

    我是一个对团队要求很高的人,这也许是我一直找不到团队的原因。但其实我是一个对团队要求很少的人。

    想想,在大学,我曾在两个团队里工作过。

    第一个,是我引以为豪的团队 Stu Developers Team,学子天地技术部。可以说,大学所学到的技术,都是在这里学到的。 之所以比其他人了解更多,是因为这里有我很喜欢的技术交流氛围,不定时的技术分享会,时常的 QQ 群交流,每天都能认识到新的知识。 在这里是真的在追求开源的方式进行开发,也是因为这样才让自己更喜欢开源吧。

    在 SDT 里,影响我的事情很多,其中有一件必须提,那就是“软件工程范儿”。 我自认自己写的代码还是挺漂亮。这是在 SDT 里一直强调的事情,一定要写“可读可维护”的代码。 从一开始就一直强迫自己把代码写得好看,不管要修改多少次。 遗憾的是,没有 TonySeek 的那种超强理解力与记忆力。看过的书理解不透又容易忘记。

    SDT 是一支技术强大的团队,至少在深大,我们敢说第二 ...



  2. 游戏与数学

    前段日子看了看 Pygame 的使用方法,其中看到一个之前从来没想过的东西,觉得很神奇,记录下来。

    物体与坐标

    熟悉 html、css,或者 Java GUI 甚至 Flash、Photoshop 的童鞋应该对定位并不陌生。在计算机中,常常使用坐标来对物体进行定位的。 例如,以 Flash 为例,Scene 左上角的像素点就是坐标的原点,而最顶部的像素构成的线是 x 轴,正方向向右;最左边像素构成的线是 y 轴,正方向向下。

    另外需要注意的是,哪一个像素点才是物体的参考点,一般来说是对象正方形区域,左上角的点作为参考点。

    通过将物体以一个(参考点坐标,长,宽)这样的形式来对物体进行定位,可以使得我们很方便的改变物体的位置。

    while True:
        screen.blit(dennis, (position_x, position_y ...

  3. Thoughts on 2014-2-9

    2月9日的胡思乱想

    今天 2 月 9 日。还有一个学期就要找实习了。

    因为 江哥(tonyseek) 的影响,也爱上 Python 了。一年前就定下目标,想要到 http://www.douban.com 实习、工作。

    还记得蛇年初,在豆瓣上写了这样一句话

    蛇年玩蟒蛇

    然后真的不知不觉地玩 Python 玩了一年(其实准确地说应该是后半年时间)。

    这半年对 Python 自身没有多深的造化,倒是学了不少 Web Framework 还有不少 Libraries 的使用。 现在很多编程(好吧是所有)都是用 Python 来完成。

    一年,还没玩够。还想继续玩。

    下半年最后两个月,在为学校写一个 MOOC 系统 ...


  4. Some Note

    最近好少博文= =

    面试

    在开始写正文之前,想写一些关于 面试 的感想与自己最近在思考的一些人生问题。

    这学期一共参与了 3 个组织的面试,包括学生会信息部,学子天地以及技术联盟连客计划的面试。再加上高中的学生会以及去年一些面试经历,有些感想需要记录下来,给未来的自己提个醒。

    仪容

    信息部的面试,我是面向面试者进行面试,因此特别留意面试者的仪容,包括着装和精神面貌,这是所谓的形象分。曾经有篇报道说中国往往有先入为主的观念,第一印象好的人,一般会觉得他就是好人(表现出来就是有好感),而且会一直这么认为。因此第一印象常常决定了别人心目中你的形象,并且这个影响是长期持续的。

    如果面试的时候仪容引起了面试官的反感,接下来的面试可能就会比较吃力了。而仪容博得面试官的喜爱,之后面试的“容错性”也自然高点。

    关于这点在 linkedin 看到了相关的讨论:http://www.linkedin.com/groupItem?view=&srchtype=discussedNews&gid=108525&item=277251498&type=member ...


  5. Team and manager

    团队与管理者

    何为团队?

    首先,一个人肯定不是团队,那只是一个个体。而两个人也不能算是一个团队,那是两个相互支撑。

    一个团队至少需要三个人,这样就有了团队的基本特性:①主从 ②监督 ③责任

    当然,这并不代表一个人或者两个人的开发行为并不能成功。

    一个团队,所有成员的目标应该一致,同时也需要一些制度来制约每个成员的行为,以求团队工作效率最高。

    任何团队,都需要一个管理者。作为团队的管理者,勇于承担责任是最基本的素质,管理者未必是团队中能力最强的人,但管理者应该对团队负责。当团队项目失败了,管理者的责任应该是最大的,而不是团队的其他技术人员,因为团队是由管理者所管理的,技术人员的进度、产品的质量也是由管理者所把握的。

    对于项目的成败,主要由以下两个方面进行评估:

    1. 项目完成的质量
    2. 项目完成的时间

    对于“项目完成时间”这一评估标准,一般需要在项目开始之前就做一些估算,经验丰富的工程师可有尽可能接近预计的工期,但没有办法保证工期绝对合理。也因此,项目总是会因为进度而修改工期。所以团队的管理者需要学习如何掌握工期,这需要一定的时间来成长。


  6. Lounger created methods

    懒人造就了方法

    人的精力终归是有限的。提出问的解决方法才是影响做事成效的根本问题。

    在早起的汇编语言中,GOTO语句使用非常频繁,将GOTO语句写到另一个文件中十分不便,因此开发人员习惯将程序写在同一个文件中。久而久之就养成了这样的习惯,并一直延续到高级语言出现之后。

    但随着程序功能日益复杂,代码自然也增多,几千行代码的程序也不罕见了,如此长的代码,PageUp/PageDown 自然成为开发人员最喜欢的按键了。

    但这世界上总有一些懒人,他们疲于天天的 PageUp/PageDown,他们打破习惯的约束,将程序拆分成多个文件编写,这就是“单元文件”的开发方式。“单元文件”使得程序容易修改维护。

    “单元文件”的概念出现之后,很快也有“模块”的概念,把一个大模块分成许多小模块,把小模块分成更小的模块,每个模块对应一个单元,于是历史上的“单文件代码”被拆分成许多的小文件,每个文件由一个团队不同的开发人员完成编写,促进了团队开发模式,也提高了程序的开发效率。

    “单元文件”和“模块”的概念出现之后,便有了“结构化编程”的概念,“结构化编程”实际上也是我们所说的 ...


  7. Essence of Programming

    编程的精义

    编程的根本是顺序、分支以及循环,再复杂的工作都可以通过这三个环节的组合来完成。因此所谓编程实质上是制定某项任务执行的顺序(顺序),找出该项任务中重复执行的步骤(循环)和任务中的特殊情况(分支),之后才是代码层面的实现。

    N.Wirth提出“程序 = 算法 + 数据结构”,至今仍被大多数程序员所认同。其中的加数“算法”暗示了在开始编程之前必须明白程序的逻辑方法,否则计算机是无法理解你想要做什么,自然程序也是无法实现出来的。而另一个加数“数据结构”则表示程序所依赖的数据实体结构。因此,在实现代码之前,要分析清楚任务的前后逻辑关系(算法)和依赖关系(结构),当逻辑关系与依赖关系都明确之后,剩下的就是体力活了。

    所以编程的本质并非使用编程语言,而是用(任一、合适的)编程语言实现算法与结构的过程。而算法与结构需在代码实现之前明确构建。

    对于编程语言,它们的底层函数库都是十分相似,API 也都依赖于系统,而它们的差别仅仅在于适用范围。例如 PHP 只适用于制作网站,Python 可以方便进行数值处理,而C ...


  8. Thinking in my life

    在同龄人里,我算是较早地接触电脑。 当时是小学四年级,学校组织兴趣班,进行培训参加比赛。

    第一次培训,我接触了 Flash。因为从一开始就做的很顺利,所以很快就喜欢上 Flash。 接着在家里的电脑装上了这个软件,在家里疯狂地学习、制作 Flash。从纯粹的动画,到 AS 。 很快认识了 FrontPage 和 Dreamweaver 这两个软件,于是开始对制作网站感兴趣。

    当时做了 Flash ,做了网站,参加了比赛。也拿到很不错的成绩。 从那时开始,就不停地与电脑打交道。

    在那时,我已经会学少许的代码。Html CSS Js 以及 AS。

    一直满足于自己的成绩,直到小学毕业,进入初中。

    初中的班主任是个会电脑的人,为我们班制作了一个班级网站,ASP语言的。 一直以来就很好奇怎么编写动态的网站。这次终于找到一个方向。

    于是,初二的假期 ...


  9. About Comment

    关于注释

    一直觉得写程序,注释需要很多很多,那一行行的灰色的英文甚至比那些带着各种颜色的单词更让我觉得兴奋。 看了《代码整洁之道》的“注释”这一章又结合最近一些开发经验,对注释的看法有一个彻头彻尾的改变:没有注释的代码才是好代码。

    1. 注释存在的原因是你对你所写的代码不自信的一种心理弥补。你试图通过注释向维护者阐明这段代码在做什么要做什么。这种做法还不如重构代码,将代码写得清晰。只要程序思路够清晰,只要每个函数都只做一件事,只要KISS,维护者就能够看明白程序在做什么。
    2. 多了注释,就多了维护的成本。注释的地位常常介于实现代码与僵尸代码之间。很多时候对实现代码进行了修改却忘记修改注释,提供错误的注释比不提供注释更要迷惑维护者!这种情况非常容易发生,因为程序永远会有 bug …
    3. 需要特别提一下的是,维护者往往是几天几周几个月之后的自己。
    4. 但文档是必须的!不管程序是否有非开发者的用户都需要一份详细的使用操作文档。文档和注释不是一回事。

Page 1 / 2