做这样一个简单的 app:
一个天气应用,干净清爽的界面,天气信息一目了然。它不仅可以精确预测未来 10 天的天气,还可以显示某地的历史天气信息。它具有自定义提醒功能,支持 web 版本, iOS 版, Android 版。
为什么想要做这样一个 App ?因为你喜欢旅行,但没找到一个天气 App 可以提供你下个月或者某个特定月份的天气信息;因为你懒你没有每天看天气预报的习惯,你想要在第二天温度达到 30 度以上或者温差有 +/-7 度的时候,获得温馨提示;因为你要成为一个 Full Stack Engineer ,你必须不断训练每个 stack 的能力。
## Web版
你决定用 MySql 来存储用户数据,用 NoSql 存储历史天气数据。你用 Redis 作为 cache ,缓存一些最常请求的天气数据。你用 Python 写后台,功能简单,后台不复杂,用户注册登录,抓取返回某城市的天气数据,某地的历史天气数据,很快便搞定。
后台开发并测试好了,接下来是 Web 前端。你十分清楚一个好的 UI 设计对一个 App 的重要性,你也明白 UI 的设计不只是为了美观,更重要的是提高信息的可读性和程序的可用性。幸好你平日的积累这次派上用场了。你把之前保存下来的上百个优秀的UI设计作品拿来研究,你从书架上拿出Norman 的那本经典 - The Design of Everyday Things 重新细读。最终你用白纸黑笔敲定了第一个版本的 UI,简洁直观,没有任何多余的设计,所有元素的排列间距 大小颜色都恰到好处。你相信即使天气不好,但用户只要使用这个 App 都会有着愉悦的心情。
那么开始写前端吧。啊,别急,都忘了还有 Icon 和 Logo ,可是不会 PS ,不会 AI ,不会 Sketch 怎么办呢,学吧。你平日喜欢结交不同领域的朋友,正好几周前在一个活动上你认识一位朋友做设计的。她花一个下午的时间教你基本的 Sketch 的使用,并对你的 UI 设计给出了一些意见。你请她吃了顿晚饭表示感谢,然后立即回家根据她的一些建议重新调整了 UI ,这次你在 PS 里把 UI 画了出来,Icons 和 Logo 也顺道一起做了。
接下来的一周,你学习 HTML,CSS,以及 Javascript,并漂亮地把前端搞定。
## 发布 App
在朋友圈发了个状态,找人帮你做 Beta 测试。他们都首先问你是什么 App,一开始你简单回答一个天气的 App。但你发现,这不能提起他们的兴趣。你觉得你需要用语言,用故事包装一下。不光是作为别人「是什么 App」提问的回答,也是成为 Full stack Engineer 道路上的一个重要技能。
你去看了所有你喜欢的产品的主页,从他们的文案上获得一些灵感启发;你读了经典的 On Writing Well ,发现好的文案,好的设计,其实和好的代码很相似,都是重在交流,如何让他人毫不费劲地明白你要表达的内容。你的故事要吸引人,你的产品介绍要在1分钟内解释清楚,并确保你的父母可以毫无压力听明白。
一切就绪,产品上线了。反响不错,用户持续增加。很多用户希望有移动版本,于是你立即投入到iOS 版本的开发上。
## iOS 版 及 后台优化
你花一周不到时间学习了基本的语法和工具使用便投入到 App 的开发中。你知道 Learn by Doing 是最好也是最快的。由于之前学习了设计的基础,UI ,Icons 很快搞定,不久 iOS 版本便发布了。iOS 的发布带来了更多的用户增长,后台服务器的压力颇大,你知道是时候优化后台了。
你在 AWS 上多开了 2 台服务器,并写了一个 Script 来自动化部署过程。
你改用 uWSGi 协议,用 uwsgi 作为 Application Server。
你使用 Nginx 来做并发,负载均衡 ...
......
......
## 成立公司
用户持续增长,每天你都会收到十几二十封用户的邮件。你很感激这些愿意花时间给你写邮件的用户,你相信他们是你最重要的用户,是潜在的付费用户。如果你把他们像上帝一样对待,他们同样也会把你看作是上帝。所以除了睡觉时间的发来的邮件,每一封邮件,你都会在2小时内给予回复。
果然这样的付出是收获巨大的,他们不仅惊讶且非常感谢你的快速回复,他们会在app store里给你★★★★★的评价,他们在社交网站上分享你的app,他们甚至会主动提出捐款给你。
你从快速的用户增长中嗅到了商机,你开始思考如何赚钱。广告你是坚决不能允许的,你认为再精确的广告也会影响用户体验。你设计了 2 个不同的付费方案,你打算用 A/B 测试看哪个方案更好。你分别给 200 个用户发去邀请尝试付费的邮件,邮件内容你精心打磨过,并在最后写上:CEO & Founder. 通过分析 2 种方案的用户行为,你决定将使用第一种方案。
接下来,你相信差不多是时候成立个公司了。为了省时间,你花 2000 块钱找了个园区挂靠并帮你注册公司。公司的名字让你头疼了很久,你不想只是简单的用这个 App 的名字作为公司名字,你知道公司将来还会做出其他优秀的产品。你希望这个名字简单易记,同时其含义也是你公司文化的象征。
公司注册下来了,但银行那边得自己跑。你联系了一些媒体编辑,邀请他们来试用你的产品;你重新设计了产品主页,并开始写产品的 Blog ;你在各大社交网络都给 App 注册了账号,即做社区客服也为宣传... 这些事大大压缩你写代码的时间。以往你都是以代码量作为衡量自己当天工作效率的指标,所以这些天你总感觉没做啥工作。
这样的发展早已超过你的预期,这个 App 从一个 Side Project 几乎变成了你生活的全部。你跟你女朋友半个月才出去约会一次,她抱怨不断;你1个月没跟朋友出去玩耍喝酒了;你 2 个月都没锻炼过身体... 你意识到, YOU CAN NOT DO THIS ALONE,你需要帮手,你需要找人一起把这个做下去。
但你不是要成为 Full Stack Engineer 么?你现在是了么?
## Full Stack Engineer
设计,后台开发,前端开发,移动开发,运营维护,PS,文案... 好像都会了,这算 Full Stack Engineer 了么?
不,这只是踏上成为 Full Stack Engineer 的第一步。你知道目前只是每个 stack 都懂一点,离senior 或者 expert 还差得远,而要每个 stack 都做到极致,需要大量的时间和精力。精力有限,产品开发紧迫,力不从心啊,这条道路也太孤独,因为你不需要与任何人进行协作。难道要把一些stack的任务交给别人做么?这样算是放弃成为 Full Stack Engineer 么?
不!这不是。
什么是 Engineer?「Engineers are versatile minds who create links between science, technology, and society」。
Engineer 的本质工作是设计,开发出应用于大众的产品。
一个真正的 Full Stack Engineer ,他从生活中发现问题,洞察需求,他设计解决方案,并开发出初始版本的产品。为了达到目标,他愿意去学习任何领域的技能和知识。同时他不追求一个人完成所有工作,如果有人可以比他在某方面做得更出色,便会十分热情的邀请他们加入。
最终他的职位也许不再是 Engineer ,他不再设计 UI ,不再写代码 ... 他的工作不再是 design and building an app or product,因为他有更大更重要的任务要做 - design and building a team or a company which builds great products.
而这时,社会给了他们另一个称呼 - 创业者。尽管众人已忘记他们 Engineer 的身份,但在他们骨子里,内心深处,自己始终都是一个 Engineer 。当他们需要从头再来时,他们毫不犹豫从设计开发产品做起。Nikola Tesla,Ferdinand Porsche,Henry Ford,Jack Dorsey,Mark zuckerberg,Elon Musk ... 细数那些改变了或正改变世界的创业者,他们大多数是 Engineer 背景,热衷于设计创造。他们学习技能和知识,不是为了成为某个领域的专家;而是因为那些 是完成自己目标所需要的。
以上,为我认可的 Full Stack Engineer
---
发个招聘广告!Airbnb 北京办公室正在招人,iOS 工程师(会 report 给我)、Fullstack 工程师、产品经理等都有职位空缺。欢迎感兴趣的小伙伴私信联系我。
Peng
Full Stack Developer 在国内不被接受的一个主要原因是公司缺乏稳定的 T 线(技术职位晋升路线)。
太多有才华的人写了几年代码最后都去做了管理。而今天的网络相关技术,聪明又能持续学习的人,在三年之内可以在一个领域做到很高的水准。那么如果你做五年,十年甚至十五年呢?
我以为你成为 Full Stack Developer 是很自然的选择,而且可以跟随最顶尖的技术。这种人并不罕见,我认识的人中
@徐 乐乐就是个例子。
相信 Full Stack Developer 的核心并非否定团队和协作,而是更多的体现在架构设计,快速原型和 TroubleShooting 方面。
随着今天的分层越来越清晰,平台和语言越来越有特点,更加全面的技术人员可以根据不同的语言搭建整个架构。
数据一致性要求高?那么使用事务管理久经考验的 Spring?还要考虑 scale ?那么放在 Oracle 里面做还是放在 Application Server 的 Transaction 管理里面做?简单请求的高并发?那么 Node.js 也许不错。 Web App 快速原型,那么 Rails 也许不错。邮件模板和自动发送? PHP 有现成的东西为什么不用?前端数据和交互复杂? 为什么不试试 emberjs ( PS :选前端框架对于架构人员来说简直像女人逛银座一样令人兴奋。甚至有人用几乎所有的框架写了同样的 Web App 来供他们试用:
TodoMVC)?想绕过苹果的 App Store 的审查机制频繁发布?可以考虑在 iOS Apps 里面嵌入 HTML5 。
Full Stack Developer 在快速原型上也很有优势,因为省去了大量的管理和沟通成本。而且,这并非就意味着一定在代码质量或者测试上有缩水。
MVC 前后都可以用。一个写过 test_helper.rb 的人做前端,一定会搜索 javascript TTD 。同样,用过 javascipt lint 的人一定可以找到 stylecheck 。语言和平台会变化,聪明的方法和工具都是共通的。懂得基本的字体知识和排版审美难道和 CSS 不是天生一对?
TroubleShooting 方面 Full Stack Developer 同样优势巨大。
服务器压力太大未必需要通过后端解决,优化个 SQL 写个 Hint 是选择,而拿一部分数据和运算到前端也许是更加合理和低成本的选择。一个系统运行多年,最后遗留的问题很可能需要对业务和技术都有深入理解的人才能解决。
从以上内容可以看出, Full Stack Developer 并非杂而全 - Facebook 也不会雇庸手。他要求的是一种更加全面的深入。 一方面,他是技术人员不断学习的结果。另一方面,他也是对自己事业的一种责任:
技术人员的价值不是指派做了一半的 issue 给队友,而是更快更好的搞定事情。
不是经济学专业,对两德合并无力回答,但是有关两德统一的公法事实的错误有必要指出。
现在讨论两德统一的问题。事实上,从来没有过两德统一,只有东德灭亡。1990年6月,东德政府决定引入西德马克来拯救陷入崩溃边缘东德经济。在之后的几个月内,由于经济无法改善,愤怒的人民走上街头,有良知的东德领导人们不愿意向人民开枪,政府迫于高压,自行解散。此时,1990年9月20日,全世界再也没有东德政府这个名词了。政府解散后,旧有各州纷纷独立,并最终仿照60年代萨尔州的例子,加入联邦德国,西德议会一一批准,才有了今天统一的德国。世界历史提到10月3日两德统一的日子,其实是照顾东德人民的感情。这在当时是联邦德国和几个州之间的事,东德政府已经在半个月之前不复存在了。
这一段不符合史实。东德政府并不是自行解散,而是根据两德条约的法定步骤,这是柏林墙倒塌后一步一步地来的。
1989年11月28日,西德总理提出分阶段建立德国邦联(还不是联邦)的计划。
1990年2月13日,华约与北约成员国外长会议做出决议,规定东德大选后成立的新东德政府就可以开始统一谈判。
1990年3月18日,东德举行大选,西德基民盟支持的东德“德国联盟”获得胜利,成立了新的东德政府。此时的东德实际上已经不是彼时的东德了,“有良知的东德领导人们”的几句话无从说起。
1990年5月18日,两德政府签订了第一个国家条约,确定了货币、经济和社会的联盟。货币联盟于7月1日起生效。
1990年8月3日,两德政府签订在两个德国境内举行全德议会选举的准备与实施协议。这个协议又于8月28日得到修改。
1990年8月23日东德国会通过了东德各州以州的身份加入联邦德国的决议。根据这个决议,为了符合基本法的规定才按照德国传统上的划分恢复各州;早前的1952年,为了便于统治,东德的历史上的5个州被划分为13个专区。这也是形式上的,东德五州真正建立起民选政府是统一之后的事情了,各州纷纷独立的说法无从说起。直到统一后的1990年10月13号,东德五州才进行了第一次州选举。
1990年8月31号由两德签署第二个国家条约确认两德统一,这个条约确定了两德统一的具体形式是东德解体、以各州的名义分别加入联邦德国。(Vertrag zwischen der Bundesrepublik Deutschland und der Deutschen Demokratischen Republik über die Herstellung der Einheit Deutschlands;Treaty between the Federal Republic of Germany and the German Democratic Republic on the Establishment of German Unity)
然后两德同四个占领国进行谈判,并于1990年9月12日签订有关修改德国国际法地位的“二加四协议”。
总结:东德政府解散并不是崩溃式的,而是根据相关宪法性法律和国际条约进行的法律步骤。
参考资料:康拉德·黑塞,商务印书馆,《联邦德国宪法纲要》第68-74页。(Grundzüge des Verfassungsrechts der Bundesrepublik Deutschland, 20. Auflage, Heidelberg 1995 (Neudruck 1999),pp95-98)
德国自神圣罗马帝国崩溃后的统一问题,政治学和国际关系上被称为German Question。可以去Google Scholar查找。
手边有两本英书可以推荐。
Peter Alter的《The German Question and Europe:A History》和Dirk Verheyen的《The German Question:A Cultural, Historical and Geopolitical Exploration》。
中文书可以参考玛丽·弗尔布鲁克的《德国史:1918-2008》。
这几本书的最后几章都是讨论两德统一后的政治、经济与社会状况,写作的年代也比较新,都是2000年之后写成或者最新修订的。