江边闲话集

码农如何写好一封邮件

做技术管理做了有些年了,和不同的team、不同的客户打交道也是非常多的,自认为在写邮件这件事情上还是做的还算可以。相反,我发现很多朋友或同行在写邮件上不得要领,或是想写好但是不知道怎么写。今天这篇文章分享我的一些经验,如果反响还不错,这是我最大的动力,我会展开来写。 在我看来,邮件其实文档的一种,所以邮件一个最主要的目的是用来沟通。既然是沟通,那么我们要达到让对方以最快的速度知道你想要表达的意思,这就是中心点,后面这些都是围绕这个主题进行。 当然,邮件是有很多技巧的,熟练使用这些技巧,会让你事半功倍。 邮件种类 先说邮件的种类,一般来说有四种: 无需回复的邮件。 这种邮件主要是想告诉收件者一些信息,例如我们平常收到一些报表邮件,部分监控邮件等,这些邮件我们无需回复,知道这些即可。 查询邮件。 这种邮件比较多,你写邮件是想从收件人那里知道一些事情,比如建议,意见或者动作等,希望收件人能够回复你。 开放式结尾的邮件。 主要是一些开放式结尾的邮件,例如保持联系。当然这也是为了将来以后的联系方便,获取进一步的结果或者便利。举个例子,我们想问某个公司的HR有没有职位招聘,HR说暂时没有,你可以说保持联系,以后有的话再发邮件去问,而且最好是基于该邮件去问,这样HR看到邮件的承前启后,知道你是谁,问什么事,不至于太突兀。 需要采取动作的邮件。 这种邮件不仅仅是期望得到你的答复,而是需要得到你的动作。例如,老板发邮件给小明,让他预定一个会议。小明需要将预定好的会议信息回复给老板,包括时间、地点(会议室)、邀请的人物。如果需要电话会议,电话会议的URL、拨入的电话号码和方式。 邮件组成 那么怎么写好一封邮件呢? 首先我们得弄清楚邮件的组成: To(收件人) CC BCC 邮件主体 一般邮件主体又分为 邮件标题(Subject Line) 开场白(Opening Sentence) 消息体 结束语 如何写邮件 收件人 收件人是你要发送给谁的,是邮件的直接接收者。可能收件人会有多个,因为他们这几个人都是直接的接收者。 CC CC一般是指抄送,FYI的目的,让CC的人知道就行了,但是不建议把不太相关的人放到这里,因为绝大部分人只关心和自己有关的事情和邮件。把一些不相关的邮件发送给不相关的人,可能会对方起到骚扰作用。 BCC 密送,既然是密送,在To,CC里的人不知道BCC里的人列表。这个某些情况下非常有用,可以保护一些隐私。举个例子,我收到过很多离职邮件,一般人可能这么写。 发件人:David Cook 收件人:David Cook 主题:Cook’s Farwell 我收到这封邮件,说明我是接收人,但是我并不在收件人里,为什么?因为我在BCC里。那么为什么我会在BCC里?可能是发件人为了避免尴尬,省去一些不别要的麻烦。 邮件标题 邮件标题非常重要,这是能够快速了解邮件目的的最直接的信息。试想,一般来说邮件进入我们的收件箱里,都是邮件列表里的一条记录而已,如果你想看具体内容,还得单击或者双击一下该邮件记录。所以,为了让收件人快速理解邮件的主题,邮件标题是最好的入门。 合理的邮件标题会让人省时间,觉得你非常专业。 一般来说,邮件标题没有固定的格式,把事情说清楚就好了。 先看看下面一个例子: Subject:Meeting Hi David,I just wanted to remind you about the meeting we scheduled in last Friday,  do let me know if you can attend it […]

继续阅读...

Web安全-隐藏Web Server信息

这是一个非常容易忽略的点。 Web Server的信息包括: Web Server的类型,常见的如Tomcat, Apache Httpd,Ngnix等。 版本信息。即web server的版本信息。 为什么要隐藏这些信息呢?原因很简单,我们非常容易获取web server的软件信息。那么对于攻击者可以做什么呢?我们知道每种软件都是有漏洞的,尤其是对于这些著名的软件。如果出现安全性漏洞,一般都是公开的,而且有些漏洞有详细的复现步骤。 Apache Tomcat 安全漏洞:https://tomcat.apache.org/security-8.html Apache HTTPd 安全漏洞:https://httpd.apache.org/security/vulnerabilities_24.html  其他web server不在这里例举了。 所以,当攻击者知道web server信息,又加上这对每个漏洞的详细解释,攻击就简单多了。 那么如何隐藏web 容器信息呢?一般来说是可以通过配置解决的。 Apache Tomcat 可以在server.xml里的Connector的server属性解决。参考https://tomcat.apache.org/tomcat-7.0-doc/config/http.html Apache HTTPd security.conf里的ServerSignature Off

继续阅读...

Web安全- Command Injection

Command Injection,是指Web App调用系统命令去实现某些功能,同时因为不安全的web请求数据(例如Form,Cookie,HTTP header等)利用该功能造成一些安全影响。 实例 下面的例子便于理解。 本例子来源https://www.owasp.org/index.php/Command_Injection 下面的PHP代码会引起Command Injection: <?php print(“Please specify the name of the file to delete”); print(“<p>”); $file=$_GET[‘filename’]; system(“rm $file”); ?> 我们看看请求和返回。 请求 http://127.0.0.1/delete.php?filename=bob.txt;id 响应 Please specify the name of the file to delete uid=33(www-data) gid=33(www-data) groups=33(www-data) 我们可以看到,如果执行web的function id足够大的话,是极有可能把不应该的数据删除了,例如filename为/,同时我们也可以看到该id所在的group。 解决方案 可以尽量使用API。例如上面要删除一个文件,可以使用php语言的api去删除文件,而不是调用OS的rm命令。 如果没有相关的API去调用,一定要调用这些command,务必做好命令的验证。就个人经验看,验证允许的command比验证不允许的command要简单一些。

继续阅读...

软件开发规则

最后版本: rev 5 最后更新: 2017-04-21 设计 注重软件设计。 High Available需要考虑。 Geo Redundancy也需要考虑,如果设计web的话。 考虑软件的需求,有无可能复杂化,定制化,这决定了软件架构, 将需求详细化,但实现时简单化。 数据库主从结构,Replication,数据一直等。 web的安全性方面是必须考虑的。 软件都是逐步迭代的,为了让后期迭代的成本更小,起点最好高一些。 事先定义软件的版本管理。 站在使用者的角度去思考。 解放思想,考虑问题站在高一点的位置。 防止过度设计。 Coding 一个文件代码不要太多,1K行左右,一个函数也不同太多,100行左右,如果太多的话,就应该考虑如何去分拆了。 代码一开始就要考虑模块化。 代码可重用性。 代码不能太耦合。 对于异常case务必写日志,不要认为捕获了就OK了。 良好的代码目录结构。 对于SQL等一些reserved keywords建议用大写,例如SELECT * FROM <tbl-name> WHERE field1=v AND field2 = v2 代码格式上须易于阅读,空格,空行等是必要的。Java有Java的代码规范,可以作为参考准则。 注释需要合理,不在于多,而在于精。对业务复杂的业务逻辑,加适当的注释会锦上添花。 代码格式可以利用一些专业化的工具进行检测,例如Sonar,JSLint等。 写代码是软件开发里非常简单的事情,但是做好不容易。基础非常重要。态度谦逊,借鉴优秀人员的代码,避免自己的不足。 一开始就要写好,不要以后面可以重构当借口。 对于web开发,安全性非常重要。可以写完后用安全扫描工具(例如AppScan等)进行扫描。掌握经验,在后面的coding种尽量去避免。 尽量将问题或需求想的全面,实现时根据实际情况可以取舍。 设计准备好了才可以写代码。 对于异常case多处理,不要认为发生的可能性不大。 尽量让代码的适应性强一些,考虑一些配置来适应未来的需求。 代码用Maven,Gradle等进行build 拼接SQL语句需要考虑的SQL安全性,SQL 的 保留关键字或字符,建议用PreparedStatement去完成。 Log 清晰的日志易于做troubleshooting 清晰的日志易于team之间的交流和学习。 日志注意拼写错误,英文合适。 […]

继续阅读...

文档

在工作中,一份好的文档对于project起到非常积极的作用,过多的益处我就不再赘述,很多书籍已经说明。 但是,一份质量差的文档呢?恐怕会适得其反。 很多时候,每个项目都有固定的流程,所以写文档就是为了走流程这样一个目的。无论你文档写的再好,也是没有人看的。写的好也就罢了,但是写的不好呢?我想是没有人看的,这样的情况下不写也罢。 很多时候,每个公司都有自己的文档规范。所以新员工不知道是怎么回事情,如果不培训的话,不要期望在短时间内写出好的文档。但是这样的公司还是挺多的。这样的情况下,不写也罢。 很多时候,即使你知道文档格式,但是文档内容有时也不太清楚,所以也不要太指望写出好的文档,只有在自己熟悉的基础上才能写出好文档。如果你不能清楚知道内容,这种情况下,不写也罢。 我倒不是反对写文档,相反,我是非常支持的。但是如何写出好文档,至少需要以下几个方面: 1. 良好的文档格式 2. 良好的写作能力 3. 良好的掌握所写内容 4. 良好的培训 5. 良好的公司氛围来写文档 我写这些,知道意味着什么吗?

继续阅读...