g****t
发帖数: 31659 | 1 android类似于"日系车”
本身就不是一家。用户交钱也不是给单一的公司。
Apple类似于BMW类型的单一品牌。
今后长期并存是必然的。就算apple完了。还会有别人pick up这条路。 |
|
g*****g
发帖数: 34805 | 2 iOS先写，再上android是没错，那是因为android fragmentation的问题，比较麻烦。
反正两者都要写，
先弄简单的。BMW单一品牌比日系钱赚得可是少多了。资本逐利。 |
|
g*****g
发帖数: 34805 | 3 Goog在desktop上的流量和利润都在减少。FB大涨也是因为证明能把流量换到mobile上。 |
|
|
g*****g
发帖数: 34805 | 5 你想说啥？web 作为平台再走下坡路，html5/js是可以用来写mobile app, 但现在还是
native 当道。
日后IoT火了，显示的部分减少／简化，html/js不是更没用了？
你说说nest要html/js干啥？除了他们自己的网站，没什么流量的。 |
|
g****t
发帖数: 31659 | 6 你前面不是在说生命力么。
难道你认为日系车比BMW,MB更有生命力?
我的看法是会长久共存。 |
|
g*****g
发帖数: 34805 | 7 windows/mac也长久共存，但利益差多了。 |
|
g****t
发帖数: 31659 | 8 如果比profit. android公司几十上百家，
加在一起跟ios比利润比用户数有意义么？"
Windows当初是一家公司。这根android
不是一回事。Tim cook访谈正好也说了这个区别。
这点我前面说过了。你又说回来。
从business角度看，其实是很清楚的。 |
|
g*****g
发帖数: 34805 | 9 我又不是给狗狗打工的，最多写个app而已。这个趋势下去，只有android app才是必写
的。
而且光看revenue也是短视的。大量的银行，医院政府机构等等，他们也需要mobile
app, 没广告，也不卖钱，没revenue，但developer还得雇吧。你觉得对他们android和
iOS哪个平台重要？ |
|
g****t
发帖数: 31659 | 10 android说不定过几天就被老印自己灭了。
Chrome os去年增长很不错的。这个事情schmit这个2B开始就犯很多大错。只能等GooG
修复过来才知道未来会怎么样。
另外我觉得engineer,coder, developer今后会是泥土一样没价值的。懂design,知道房
子怎么样才能有价值。 |
|
g*****g
发帖数: 34805 | 11 别逗了，好歹狗狗还是Page说了算得。软软才可能倍烙印自己灭了。
GooG |
|
g*********e
发帖数: 14401 | 12
当然是ios重要。服务用iphone的土豪最要紧。
安卓平台的屌丝客户，弄个in app purchase都要犹豫半天，谁搭理？ |
|
g*****g
发帖数: 34805 | 13 架不住人多， revenue在那里摆着的，赶上也就一两年的事情。这还是没算中国的。算
上中国估计已经超过了。 |
|
g****t
发帖数: 31659 | 14 你查查chrome os吧。值得关注。
Page做的很不错。但GooG换schmit太晚了。人baidu没有OS,在国内平均每部手机6个它
家的apps. Goog至少要提升到这个水平，才能说它家将来一定支持Android.
现在GooG从mobile上套取的利润还不够优秀，所以路线还是有疑问的。 |
|
d********f
发帖数: 43471 | 15 你说的和我说的完全没矛盾啊，unix和windows之争就好比安猪和ios之争，你牛b但是
你挣不到钱还不是白搭么，什么是盈利模式，twitter比fb牛b但是你赚不到钱市值只能
是人家的1/10 |
|
c********l
发帖数: 8138 | 16 很多岗位都是devop
不光是小公司招全栈工程师时需要，甚至一些大公司都招这类人 |
|
g*****g
发帖数: 34805 | 17 你说反了，后端的人一般都不熟悉js，node.js给前端开发人员提供了一个全栈的机会
，既然js怎么都得用，用js来做mvc是合适的。 |
|
g*****g
发帖数: 34805 | 18 知识面这个说的没有错，复杂的网站搞不了，简单的还是可以。所以意义还是有的。
简单的就全栈了，替代以前的php。复杂的做SOA，不用去搞后端的优化。统一语言可以
减少切换的开销。 |
|
g*****g
发帖数: 34805 | 19 你就没明白前后分开啥意思。但凡公司有几十个engineer，做UI和做后端的不是一帮人。
startup，UI要求高，后端简单，雇几个做UI的顺带把后端给做了。
企业内部应用，后端复杂，UI不用好看，做后端的顺带把UI给做了。这些都可以叫全栈。
但前后都要求高的时候，必须前后分开。做前端的人根本没有scalability设计这些素
养，做不了后端。Node的主要好处是让做前端的人可以专注于一个语言。他们本来用
Spring MVC也好，RoR也好，不是本质区别。
后端的人是做服务的，不是做MVC的。 |
|
g*****g
发帖数: 34805 | 20 你要快糙猛搞Prototype，原来也是Ruby和Python的市场呀。Twitter RoR做了出来。量
上来之后后端就改Scala和Java。你把RoR改成Node当然是可以的。
全栈并不是Node之后才有的概念。我说来说去就是Node跟Java竞争不大，跟Ruby,
Python竞争比较大。 |
|
g*****g
发帖数: 34805 | 21 生产力是轮子堆出来的，不是语言堆出来的。JVM的生态系统上，clojure和scala写些
并行类库，groovy写脚本，Java写应用，才是最佳的使用。在不同语言里来回切换，会
大大降低效率。从效率的角度讲，应该是分工使得切换的开销最小，而不是全栈。这也
是NodeJS火的原因之一。 |
|
w***g
发帖数: 5958 | 22 我可能是在找骂。我的理解是一个startup的产品是需要很多iteration的。按那钱时间
分的话是
1. 拿angel fund之前：出一个糙快猛的demo，但是没有什么会最终保留到产品里。这
个阶段发挥作用的主要是founder，并不需要很好的代码质量。每个人拿的equity可能>
10%，没有工资。
2. 拿series A之前：有确定的磁盘数据结构(sql schema)和模块间的接口。最核心的
那些代码可能基本上finalize了，但是外围由很多还是糙快猛的东西。这个阶段需要一
两个技术大拿来确定基本框架，加起来可能有三五个全栈程序员以一当十把东西做出来
。这个阶段加入的人equity最多也就1~2%，一般可能也就0.x%。这时候加入的那些人基
本上确定了整个公司的culture，这些人几年之内不应该离职。
3. 拿到series A之后由足够的人力了，再精打细造各个模块和增加更多的模块。这时
候再加入，除非公司IPO或者卖大钱，equity实际上已经没太大意义了。这时候单个员
工做的东西和公司的生死存亡其实已经没太大关系了。
2之前最重要的是设计/架构而不是编码，2之后才... 阅读全帖 |
|
|
m***r
发帖数: 359 | 24 和一些小伙伴们新建了个，主要是收集微博上相关的讨论，
http://web.memect.com/
板上牛人众多，求批评和建议，看怎么能做得更好些。
最近几期：
2014-12-31 (加长版 52条)
* AngularJS vs. Backbone.js vs. Ember.js
* 构建C1000K的服务器
* 免费开发课程《HTML5离线应用实战演练》
* 从0到100——知乎架构变迁史
* 维基百科将所有服务器的PHP引擎变为HHVM
2014-12-30 (加长版 40条)
* Cocos2d-JS v3.2重构Web引擎的渲染器等
* ECUG（实效云计算用户组）专题回顾PPT
* Material design非官方中文指导手册
* 《CSS Secrets》
* fibjs 和 nodejs 并发模型上的差异性分析
2014-12-29 (加长版 34条)
* W3C和WhatWG HTML5标准的差异
* ArchSummit北京2014十大优秀演讲PPT
* 《架构师》（2014年12月）
* (开源游戏引擎)Egret 的童话与现实
EC... 阅读全帖 |
|
c*******0
发帖数: 5247 | 25
这些只要做过一遍，一个全栈就是一个星期搞定啊
social login上，FB和Twitter都有全面的SDK，你要是用他们的oauth系统，两边都可
以一天搞定。
google analytics网页上就是一行代码，iOS和Android都是现成sdk，一天也没问题。
afnetworking和volley做REST的接口都是现成的，你用cocoapad和gradle一行代码就两
个都能用了。
hockeyapp或者testflight大概一天熟悉流程一点问题都没有，现在都是直接找tester
要邮件了。
你要说这里面真费时的，那可能是是如果自己要搞用户系统，然后之前没有cookie/
session经验的，确实要花一些时间理解一下。其他的话，这些东西要是一周搞不定的
人，那属于对Mobile或者前端完全不熟的人，这种人可能确
实适合用Parse。
当然，你要说一个真实系统这些东西能不能一周搞定，那完全取决于你的api怎么设计
，比如
你的后端和前端的交互，哪些数据，怎么放。这是你用parse还是用EC2都要设计的。复
杂的设计本身就要超过一周，简单的设计几个小时就搞定了。 |
|
m*******e
发帖数: 1598 | 26 有几个能自己写机器码的
有几个能自己设计处理器的
有几个能自己设计电路的
有几个能自己提纯硅的
...
有几个能自己生火的
缺一条都不算全栈码工 |
|
|
g*****g
发帖数: 34805 | 28 错了，我老是有自知之明。比如什么要全栈的地方，俺就不往那里凑热闹。但凡写上
functional的地方，俺也躲着走。我老就这一亩三分地，少费了很多时间在跟语言较
劲上，多花了很多时间Google StackOverflow，经验那是耿耿的。这年头都要culture
fit，八字不合的地方，我都不去面。 |
|
t********e
发帖数: 1169 | 29 能写让10亿人用的后端系统，也能写能让十亿人下载的app |
|
|
z*******3
发帖数: 13709 | 31
这两个本来是打算让事情变简单的
结果反而变复杂了 |
|
d**********6
发帖数: 4434 | 32 你还缺好几样呢，db，ui，ux等等
实际上full stack是个无边无际的东西，就看老板怎么定义了 |
|
l**********n
发帖数: 8443 | 33 .net, java, ruby样样精通，或者会vertx |
|
k**n
发帖数: 3989 | 34 那找工作写自己是all stack 不丢份吧.. |
|
w**z
发帖数: 8232 | 35 我看到简历是full stack 都直接扔了。 |
|
|
n*********u
发帖数: 1030 | 37 不喜欢前端就做后端工程师呗。硬去做full stack做了也不开心。当然即使是后端工程
师，会一点前端也是有必要的，但也算不上full stack。
尝试过hardcore的full stack之后才发现前端也是博大精深的，不只是时间活儿。光js
和css做个小project是很简单，但是东西大了后还是需要framework之类的，不然就成
无法忍受的spaghetti code了。 |
|
|
|
g*****g
发帖数: 34805 | 40 主要就是不用ORM这一层了，大量 UI程序员觉得存储简单了，变身全栈了。事实上是大
多数应用不需要 scale, 性能要求也不高，倒是关系和交易不能避免，所以 Mongo在这
方面是合适的。 |
|
f******2
发帖数: 2455 | 41 如果老姜做ceo/cofounder，卫老师做cto/cofounder，zhaoce做vp of eng，
goodbug做全栈工程师出去融资的话，我觉得怎么也有2000万左右的估值 |
|
f******2
发帖数: 2455 | 42 做高频交易的shop的团队都怎么配置人员啊？
搞2个你老这样的搭架子，再搞两个在上面写算法? 还是大家都全栈呢？
听说算法本身倒是非常简单，没啥math，是真的吗？ |
|
T********i
发帖数: 2416 | 43 Hot standby，2台还是200台，技术上有差别么？就是堆机器而已。至于为啥不用200台
，不需要而已。
说白了，完全从底层做起，也就是千八百行的东西，用现成的轮子，也就几十行。
问题是，我说的那些轮子，这些人见都没见过，听都没听说过，根本想象不到这世界上
还有这玩意儿而已。fangtuo说的对，那些大公司全栈出来的不会有这么偏执。你真以
为这些公司除了对开源轮子啥都没有？
比可靠性，成本，都很简单，故意算错就是无耻了。别忘了，条件变了，我的架构也可
以无限scale up，而且单节点性能仍然大数百倍。
我的核心算法也就几十行的代码。比实现难易程度，也没人能比得上吧？
说白了，所有这些应用还真就是一计数器。 |
|
w********m
发帖数: 1137 | 44 全栈狗感觉，过去一年前台的任务越来越重。
后台的MVC都要转移到前台。然后后台就简单做做REST。
现在前台还要直接render成手机上的native app。
以后后台会不会退化成DBA这样的角色？ |
|
T*******e
发帖数: 4928 | 45 "两个月"？前端真的那么快（从上手到找工作）？看来下次跳槽我要
把简历上的前端经验好好推销一下。以前我从没找过前端或全栈的工作。
如果楼主学Java，以外行的基础，估计至少要一年才能找到工作。 |
|
w********m
发帖数: 1137 | 46 不对。
你问alex, wdong.
他们肯定不认为自己是data scientist.
他们做网站可不比一般人差。
这才是真正的全栈。 |
|
|
|
h*i
发帖数: 3446 | 49 So far, mostly Clojure/Clojurescript.
That can change, if there are compelling reasons. I am running a business,
after all. |
|
|
