啥叫 On site ？

马云公司有啥好的？人傻钱多？

An anonymous reader writes

How 'DevOps' is Killing the Developer There are two recent trends I really hate: DevOps and the notion of the "full-stack" developer. The DevOps movement is so popular that I may as well say I hate the x86 architecture or monolithic kernels. But it's true: I can't stand it. The underlying cause of my pain? This fact: not every company is a start-up, though it appears that every company must act as though they were. DevOps "DevOps" is meant to denote a close collaboration and cross-pollination between what were previously purely development roles, purely operations roles, and purely QA roles. Because software needs to be released at an ever-increasing rate, the old "waterfall" develop-test-release cycle is seen as broken. Developers must also take responsibility for the quality of the testing and release environments.

The increasing scope of responsibility of the "developer" (whether or not that term is even appropriate anymore is debatable) has given rise to a chimera-like job candidate: the "full-stack" developer. Such a developer is capable of doing the job of developer, QA team member, operations analyst, sysadmin, and DBA. Before you accuse me of hyperbole, go back and read that list again. Is there any role in the list whose duties you wouldn't expect a "full-stack" developer to be well versed in?

Where did these concepts come from? Start-ups, of course (and the Agile methodology). Start-ups are a peculiar beast and need to function in a very lean way to survive their first few years. I don't deny this. Unfortunately, we've taken the multiple technical roles that engineers at start-ups were forced to play due to lack of resources into a set of minimum qualifications for the role of "developer".

Many Hats Imagine you're at a start-up with a development team of seven. You're one year into development of a web applications that X's all the Y's and things are going well, though it's always a frantic scramble to keep everything going. If there's a particularly nasty issue that seems to require deep database knowledge, you don't have the liberty of saying "that's not my specialty," and handing it off to a DBA team to investigate. Due to constrained resources, you're forced to take on the role of DBA and fix the issue yourself.

Now expand that scenario across all the roles listed earlier. At any one time, a developer at a start-up may be acting as a developer, QA tester, deployment/operations analyst, sysadmin, or DBA. That's just the nature of the business, and some people thrive in that type of environment. Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once.

If such people even existed, "full-stack" developers still wouldn't be used as they should. Rather than temporarily taking on a single role for a short period of time, then transitioning into the next role, they are meant to be performing all the roles, all the time. And here's what really sucks: most good developers can almost pull this off.

The Totem Pole Good developers are smart people. I know I'm going to get a ton of hate mail, but there is a hierarchy of usefulness of technology roles in an organization. Developer is at the top, followed by sysadmin and DBA. QA teams, "operations" people, release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this?

Because each role can do the job of all roles below it if necessary.

Start-ups taught us this. Good developers can be passable DBAs if need be. They make decent testers, "deployment engineers", and whatever other ridiculous term you'd like to use. Their job requires them to know much of the domain of "lower" roles. There's one big problem with this, and hopefully by now you see it:

It doesn't work in the opposite direction.

A QA person can't just do the job of a developer in a pinch, nor can a build-engineer do the job of a DBA. They never acquired the specialized knowledge required to perform the role. And that's fine. Like it or not, there are hierarchies in every organization, and people have different skill sets and levels of ability. However, when you make developers take on other roles, you don't have anyone to take on the role of development!

An example will make this more clear. My dad is a dentist running his own practice. He employs a secretary, hygienist, and dental assistant. Under some sort of "DentOps" movement, my dad would be making appointments and cleaning people's teeth while trying to find time to drill cavities, perform root canals, etc. My dad can do all of the other jobs in his office, because he has all the specialized knowledge required to do so.

But no one, not even all of his employees combined, can do his job.

Such a movement does a disservice to everyone involved, except (of course) employers. What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (while doing less, less useful work) and lower-level positions simply don't exist.

And this is the crux of the issue. All of the positions previously held by people of various levels of ability are made redundant by the "full-stack" engineer. Large companies love this, as it means they can hire far fewer people to do the same amount of work. In the process, though, actual development becomes a vanishingly small part of a developer's job. This is why we see so many developers that can't pass FizzBuzz: they never really had to write any code. All too common a question now, can you imagine interviewing a chef and asking him what portion of the day he actually devotes to cooking?

Jack of All Trades, Master of None If you are a developer of moderately sized software, you need a deployment system in place. Quick, what are the benefits and drawbacks of the following such systems: Puppet, Chef, Salt, Ansible, Vagrant, Docker. Now implement your deployment solution! Did you even realize which systems had no business being in that list?

We specialize for a reason: human beings are only capable of retaining so much knowledge. Task-switching is cognitively expensive. Forcing developers to take on additional roles traditionally performed by specialists means that they:

aren't spending their time developing need to keep up with an enormous domain of knowledge are going to burn out What's more, by forcing developers to take on "full-stack" responsibilities, they are paying their employees far more than the market average for most of those tasks. If a developer makes 100K a year, you can pay four developers 100K per year to do 50% development and 50% release management on a single, two-person task. Or, simply hire a release manager at, say, 75K and two developers who develop full-time. And notice the time wasted by developers who are part time release-managers but don't always have releases to manage.

Don't Kill the Developer The effect of all of this is to destroy the role of "developer" and replace it with a sort of "technology utility-player". Every developer I know got into programming because they actually enjoyed doing it (at one point). You do a disservice to everyone involved when you force your brightest people to take on additional roles.

Not every company is a start-up. Start-ups don't make developers wear multiple hats by choice, they do so out of necessity. Your company likely has enough resource constraints without you inventing some. Please, don't confuse "being lean" with "running with the fewest possible employees". And for God's sake, let developers write code!

Posted on Apr 15, 2014 by Jeff Knupp

@ 左耳朵耗子 有人转了个《DevOps 是怎样扼杀开发者的》http://t.cn/RvG61cN ，这篇文章对 “全栈” 和 “DevOps” 吐了槽。为了客观认识，还请大家去看看国外的相关讨论，原文下的（http://t.cn/8s0nRWtHacker）， News 上的（http://t.cn/8s0m0M9Slashdot 上的（http://t.cn/Rv5zlq1））还有

@ 曹伟 - 鸣嵩: 但现实是，开发不去做测试就很难写高质量的代码，不去做运维就不明白什么是高可用和容错，不去分析真实的数据就很难弄清楚需求。全栈其实是要求全局视野。

大家一年多平均增加了不到 1300 块钱。物价横飞啊，咱们的薪资涨幅太小了。

好的。没问题。纪念品有两种， 1）《配置管理最佳实践》书籍一本 2）配置管理之路的纪念杯子一个。

两种纪念品 [color=Red] 只能选一种 。请把邮寄地址、姓名、公司、手机号码发送到

scmroad AT gmail DOT com

恭喜恭喜。

gggddz yuipr heihei6868 nearness st_simon

里边都是这个问题，没有一个是解决了的。除了一个是分配状态，其他状态都是 new

[attach] 2367[/attach]

崛起之路

　　cnzz.com 一样有 bug，有问题，有很多不足;但是比起 1tong 而言，稳定性有了很大提高，功能性也有了一定的提高。而更重要的是阿飞的参与度;我一直说自己不是什么牛逼的技术，这话不是自谦，是实事求是，1tong 的各任技术负责人 (人员流动好快的说) 都说我代码不行，我承认他们有道理，但是阿飞觉得行，行在哪里呢?

　　第一，他需要的东西，我都解决了，从功能到性能;第二，代码我大概说说他就看得懂，自己能改。阿飞本身也不是科班技术出身，他一直想做统计，还专门找人开发，但是总是卡在关键问题上处理不过来，拿过我的代码，界面不行，展示太粗陋，他找个美工设计一下，自己从代码里咔嚓就改了。有什么需要升级更新的，我跟他大概说说，他自己咔嚓就改了。所以 cnzz 成为市场第一，他是贡献最大的。

　　而且，从一开始没多久，cnzz 就有一个综合搜索分析后台，类似现在的 data.cnzz.com，但功能更强悍，这个后台并不针对个站，而是综合分析所有搜索来路的数据，并给出每个搜索引擎的流量分布，地区分布;每个地区的搜索引擎流量分布 (当时发现，上海的 google 使用率是东北、湖南的 5 倍以上;所以当时一些调研机构集中在北上广做搜索引擎市场使用率调研的数据，基本没法看。);每个客户端的搜索引擎流量分布;更重要的功能是，每个搜索引擎的渠道分布! 完整掌握百度，google, soso,sogou 的流量渠道构成，以及彼此的对比 (比如 hao123 给百度的贡献以及 265 给 google 的贡献，以此类推)。这个数据现在 cnzz 也不敢开放出来。

　　我最近才明白我的优势在哪里，我技术肯定不是最好的，但是遇到问题时候我还是有很多野路子使的 (这就是被人正规技术一直鄙视的原因，他们只看到了不合理的代码，却没体会到具体解决问题的诉求在哪里);我产品观还可以，不算特别好，但是总算能找到一些要点。

　　所以在 2005 年之前，在统计领域，我自己的跨界优势没有对手，而另一项优势是，看到数据在那里，我能知道价值在哪里，怎么弄出来，我在百度商业分析部的时候，搞的很多东西，都是没有领导吩咐，自己鼓捣出来的。cnzz 对我而言，是一个赌气的产品，因为 1tong 说我的代码很烂，百度的领导说我的东西不行。我当然有怨气，我想证明自己，也很感谢阿飞帮我证明了自己，靠我个人是搞不定后面很多东西的，光前端就要我命了。

　　好玩的是，在百度也一直没人知道，cnzz 就是我写的系统。所以他们 09 年以合作的名义找 cnzz 去讲课 (那时候操盘手已经从阿飞换成了强姐)，然后底下认真的记笔记，然后推出了百度统计，我都觉得好笑，你们直接找我讲就好了，我不要钱，每个细节我都告诉你，源代码都给你。干嘛这么纠结呢？

　　各路对手狭路相逢

　　05 年把统计给阿飞，而自己完全不参与 (没要一点股份)，另一个原因是，当时 Google Analytics 免费了。实话说，我对 google 统计免费的第一感觉是，绝望，我认为免费统计终结了，大家不用再做了，阿飞反而坚持还有机会，事实证明他是对的。 4399 曹政讲述中国互联网网站统计史 　　

　　好吧，必须说一下 51la，这是个非常不错的统计，可惜和 cnzz 顶在了一个时代，他们最初也是在技术上有所欠缺，并发支撑能力比 cnzz 有缺陷，所以只在 1tong 衰落和 cnzz 崛起之间的一段时间保持了领先，然后就被 cnzz 超越，到 07 年左右的时候，51la 的技术能力已经接近或追平 cnzz，但是市场格局也大势已去。顺便再说一下，50bang 也黯然关闭，而 07-08 年，为了适应更大规模的统计需求以及更复杂的功能需求，cnzz 进行了代码重构，核心技术人员，来自于 50bang，所以今天的 cnzz，已经没有我的代码了。

　　另外，cnzz 崛起后，庞升东直接把 1tong 卖给了互动通，也就是太极榜的公司，互动通派来一个技术和我交流，他一直强调他们太极榜的技术多牛，数据仓库多先进，嗯，我老老实实的把 1tong 的问题和 cnzz 的升级方案给他们了，然后，也没有然后了。

　　网友提醒，51yes 也是一款优秀的统计，此外还有量子统计必须提一下，实话说，我一度很想通过淘宝开放平台搞一套店铺统计，后来发现淘宝不允许嵌入 js，而很多重要的统计项目只有内部接口，也就是完全无法和量子统计平等竞争，虽然仍有很多切入点值得深挖，但是懒散的我已经没有动力去弄了。。。嗯，还有雅虎统计，这个，呵呵。

　　百度统计在 10 年后基本成型，到今天，这么讲，我给人推荐都是百度统计多，原因无他，第一是功能上各家基本雷同，没什么太大差异; 第二是百度统计有个加分项，可以统计百度真实收录数，这可是站长极为关心的;而第三则是，第二隐藏了一个潜台词，有理由怀疑，使用百度统计可以给百度蜘蛛提交新页面，可以增加百度收录数! 所以，还有什么理由拒绝百度统计呢？

　　关于网站统计的未来

　　那么，现在的网站统计，是否还有提升空间呢？有，极大有。

　　07 年还是 08 年，有一个号称中科院参与合作的一个特别牛的统计系统 --- 纬度统计，号称各种数学模型和人群分析的统计，拿了一些投资，当时我就非常不看好，很简单，第一，这种技术非常不成熟，所有的模型都是基于一些想象的分类基准，很难落实成为可信的东西;第二，让这些高大上的人群去理解草根站长，实在太难了。很快那个产品也没了。

　　但是有个强需求，我从 07 年开始提，一直没有人实现，哦，我努力尝试去实现过，但是正值 cnzz 大改版，我也无法介入新系统，只好建议几下，然后似乎也不了了之。

　　具体来说就是，传统的网站统计，都是基于页面的统计，每个目标页面的访问情况，每个来路页面的转化情况;稍微有一点变化的，可以基于子域名和目录统计，但是这些都不够! 远远不够!!

　　真正需要的，是行为统计和行为间转化;举例而言，比如说百度空间，你要看的不是哪个文章有多少访问量 (运营人员或许要看)，你要看的是什么行为有多少访问量 (多少次文章阅读，多少次个人主页浏览。多少次评论发布，等等)，以及行为到行为的转化和漏斗模型，从什么行为到什么行为，而不是从什么页面到什么页面。

　　将每个 page 的数据通过某种规则聚合行为，才是统计价值所在；google 统计本身有这个功能，但是配置起来很复杂，而实际上，对于大部分使用通用 cms, 论坛系统，商城系统的网站来说，预置行为定义是很简单的事情 (以商城为例，要看的统计是多少人次浏览商品，多少人次搜索商品，多少人次浏览目录，多少人次下单，多少人次加入购物车，等等行为以及行为之间的转化)。

　　而对于其他类型的网站，配置可以作为增值服务提供，并不十分复杂，所以，要我说，现在的各种网站统计，基本停留在不思进取的境界。

　　App 兴起，移动统计开始崛起，友盟占了先筹，而现在 TalkingData 似乎后劲更足。具体产品我了解不多，就不敢妄言了。

　　但是说一个要点，统计需求，说白了，两大目标

　　第一，是对市场运营行为的指导和分析，提醒运营者，不同流量渠道的价值和转化情况，来优化运营，优化市场投放，提升运营效率。

　　第二，是对产品的指导和分析，提醒产品设计者，不同类型用户的行为特征和转化分析，来优化产品设计，优化产品本身的指标。

　　不客气的说，很多做统计的人连这个都没搞明白。

　　嗯，自夸的成分很大，您凑活看吧。　

配置管理之路 Scmroad 微信号: scmroad，欢迎大家添加或者扫一扫。

可能性有： 1）密码错误 2）更改的密码中含有 non-ascii 字符

可以从命令行下测试： svn info --username USERNAME --password PASSWORD --no-auth-cache https://server/svn/repository/

@ 左耳朵耗子：

亚马逊的工程师级别有，SDE1，2，3 分别对应于 Level 4,5,6，上面是 Principle SDE，Senior Principle SDE 对应层级 Level 7,8,9,10。但是基本上来说，90% 左右的工程师止步于 SDE2，有的 SDE2 一干就是 7，8 年（SDE2 一般相当于淘宝的 P7/P8），有少数的技术能力可匹敌于淘宝的 P10，但还是无法晋升。也够悲催的。

亚马逊的办公环境是我职业生涯中经历过最差的地方，居然比 15 年前的网吧还差。淘宝的差旅报销系统则是我经历过最差的系统，居然比 15 年前的纯手工报销还啰嗦。

这么多年在外企，都在努力一个事——“让中国团队有更多的话语权和领导力”，一开始觉得是语言和技术的问题，发现都不是。后来觉得是需求源的问题，需求不在本地，本质上就是外包。但结果也不是需求，因为本地需求优先级远小于国外需求。花时间努力这事太不值了。所以，决定离开亚马逊了…（猎头忽扰）

亚马逊的招聘，如果你有 5 年的工作经验，但达不到 SDE2 的标准（就是有比较强的各种软件设计架构能力，还有非常不错的解决难题的能力，以及对技术充满热情），那就不要了。而且这标准每年都在升，升到现在在美国都基本都招不到人了，目前又是扩张期，有想出国的朋友，不妨试试把简历直接投到美国。

上周回北京见一下以前在亚马逊的同事，听到亚马逊在实施个怪异的 HR 制度，如果你在亚马逊呆一年就走了，公司给你 2000 刀，呆两年走了，公司给你 4000 刀，呆三年走了给你 6000 刀。感到比较诡异，这是让人走呢，还是让人留下呢？

就是应聘者的回答，这里用来做占位符

合适的人放在合适的位置最重要。一台机器有很多零部件组成，如果每个零部件都能安全、可靠地运转，这台机器才能有最大的产出。全栈工程师未必不好，但如果成为老板压榨员工的一种手段就偏了。 何况一个正规的公司会允许所有的人前端、后端、测试、运维各个岗位跳么？他们只不过是想让你多干些活，公司少支出些成本罢了

[i=s] 本帖最后由 laofo 于 2014-5-27 09:10 编辑

@ 俞小八：要全精通···那就是无敌了····

@ 知名不具呀：精通一个就够了，scm 还是 git 算本行。其余都属于龙套

@scmroad配置管理之路 回复 @ 知名不具呀:国内的公司恨不得各个都是孙悟空

@ 哈哈 - 木-: 希望我们的 scm 也懂写代码做运营

@ 知名不具呀：毕竟是配置管理工程师，精通配置管理工具和程序，熟悉一种语言来编写脚本以达到自动化，理解 DB,运营，QA....

@ 知名不具呀:孙悟空的过人之处不是 72 变，毕竟猪八戒也会 36 变。而是他的金箍棒和火眼金睛，多次化险为夷、反败而胜

@scmroad配置管理之路 回复 @ 知名不具呀:这他们也要。72 变 + 金箍棒 + 火眼金睛 + 多次化险为夷 + 反败而胜。。的孙悟空才是他们要找的孙悟空。

@ 小和平鸽：你们这些玩配置管理的究竟都干些什么啊？

@scmroad配置管理之路:回复 @ 小和平鸽:其实我们都是沙和尚，结果唐僧说你 Y 的太懒惰，从来不出去化缘，也抓不住妖怪，明天起你们三个要是全栈和尚：一个化缘，一个喂马，一个做饭，三天一轮回。结果猴子去做饭了，八戒去化缘了，我在喂马。

@aroundercn：当都是全栈和尚时候，团队新的问题又来了。

@jeffery-陈帆 ：放在合适的位置最重要

盘点那些上市未果的互联网公司

今年是整个中概股中 TMT 公司最为疯狂的一年。无论是已经挂牌上市，还是即将启动上市的 TMT 公司，都在诠释了一句：这是最好的时代，也是最坏的时代。当京东、聚美、途牛、猎豹等互联网公司不断刷新中概股的同时，我们也看到了退出上市的触控科技、二次启动上市的迅雷、IPO 无望的拉手网、渐行渐远的凡客、等待出售的盛大文学…… 互联网公司 IPO 当京东、聚美、途牛、猎豹等互联网公司不断刷新中概股的同时，我们也看到了退出上市的触控科技、二次启动上市的迅雷，特别而又令人思考。 毋庸置疑，今年是整个中概股中 TMT 公司最为疯狂的一年。无论是已经挂牌上市，还是即将启动上市的 TMT 公司，都在诠释了一句：这是最好的时代，也是最坏的时代。 本文选取了 2011 年以来，几家提交过 IPO 申请、亦或离 IPO 申请只差临门一脚的互联网公司作为样板。不过，我始终坚信，上市只是个手段，并非终极目标。而只有当企业真正成熟到走向资本市场时，上市也只是个顺势而为的过程。

二次启动上市的迅雷 2011 年，提交上市的几家 TMT 公司里，迅雷当属其中一葩，6 月份提交 IPO 申请，10 月份撤销。短短 4 个月时间里，迅雷玩了一把过山车。 迅雷的商业模式很简单，网络广告、付费增值、游戏以及其他业务。2011 年，网络广告收入占 51%，付费增值占近 25%，游戏以及其他服务占 24% 左右。 随着视频第一梯队的马太效应发挥，迅雷、酷六、56 网、激动网等二三线视频网站开始往下滑，集中表现在广告收入的急速下滑。迅雷在刚刚提交的 SEC 文件上，可以发现广告收入已经下滑到只剩下 20% 的市场份额，2014 年 Q1 广告收入只剩下 18.3%。 而放眼整个视频行业，广告依然是各家的主要口粮。换句话说，迅雷已经不算是一个靠广告为主的视频公司，变成了付费用户为主、游戏为辅的公司。但是这两者目前来看，都是向消费者收费的模式，并不能持续。 就在昨日，迅雷向资本市场再度发起了冲击，最多融资 1 亿美元。第一次冲击 IPO 失败，官方口径可以说是资本大环境不好，如果这次中概股 IPO 潮再失败，迅雷基本就只有告别 IPO 了。

等待出售的盛大文学 和其他公司相比，盛大文学上市失败是最具客观色彩的。但随后剧情的发展，又颇有主观行为。 2011 年 5 月，盛大文学提交了 IPO 申请，作为网络文学绝对的霸主，无论是给资本市场讲故事也好，证明盈利能力也罢，都具备无可争议的优势。可惜，资本市场的大环境确实非常差，一方面是整个中概股普跌，排队上市的公司迟迟无法挂牌。而在私募市场，众多互联网公司融不到资。 在这样的客观条件下，盛大文学确实躺着中了枪。盛大文学在苦等无望后，内部爆发了一系列矛盾。而此时整个盛大集团的战略逐步调整，从最早的五架马车（游戏、文学、在线、视频、影业），变为三横三纵（游戏、文学、视频三个内容平台，盛付通、盛大云、广告三个纵向业务），再到盛大 PE 化，陈天桥趋向把公司变为一家投资控股公司。 盛大文学被陈天桥列在了待售的名单里。剧情发展到这一步，已经不再是盛大文学的团队是否再想冲击 IPO 了。侯小强以及创始团队的陆续出走，让盛大文学陷入了困局。这进一步加剧了陈天桥出售盛大文学的想法。而坊间消息，阿里巴巴投资的可能性较大。 不过，作为网络文学的一股重要力量，盛大文学从冲击 IPO，到等待出售，这该是一部多么意外的戏剧啊。

IPO 无望的拉手网 已经很久没有听到拉手网的消息了，这可是曾经一度风靡团购行业的巨头。2011 年 10，拉手网甚至还向 SEC 提交了 F-1 文件，申请 IPO，一年不到，拉手网撤消了 IPO 申请。 而拉手网上市失败后，爆发了震惊业内的创始人和投资人的矛盾风波，最后以吴波为首的创始团队离开了拉手网，投资方、金沙江创投合伙人朱啸虎自己干起了拉手网的负责人。这也印证了投行圈的一句戏言，投资人最大的悲哀就是把自己投进去了，做起了企业的 CEO。 随后的拉手网也是经历了几次洗牌，人事调整也是反反复复。一位原拉手网某大区负责人甚至私下做了团购网站，利用拉手网资源给自己搞起了小金库。这实际上，和拉手网管理上的混乱不无关系。 千团大战后，美团、大众点评、糯米等都将方向瞄准了本地生活服务领域，做起了 O2O。这些企业，用资本和血的教训证明了，团购只是其商业模式的一环，并非终极模式。在本地生活服务领域，团购还只是排头兵。 如今，大众点评选择了腾讯，美团选择了阿里巴巴，糯米选择了百度，三家团购网站选择了 BAT 不同的三家做背书，一方面是发展所需的资本，而另一方面则是接 BAT 的平台资源，将触角伸向更为广阔的本地生活服务领域。而只靠团购做背书的拉手网，显得过于单薄，重启 IPO 已经遥遥无期了。

渐行渐远的凡客 “凡客现在只剩下 200 多号人了。” 一位前凡客说。这和巅峰时期的凡客比起来，零头都算不上。 经历了 7 轮融资后，凡客开始做减法，回归做品牌的路子，不再是一家杂货铺，什么都吆喝着卖。我理解，凡客做品牌的方向是对的，不管未来是否能够成功上市，亦或再能融到钱，这条路是必须要走下去的。 在如今电商林立的山头上，做个平台不现实，再做个服饰垂直电商会也不现实，凡客要继续在资本市场讲故事，必须走差异化路线，自主品牌电商是条路子。有了故事，再给资本市场证明公司具备可持续盈利的能力，那就有了双保险。 所以，凡客裁员也好，缩窄业务也罢，甚至把如风达剥离出来，凡客都是将成本继续做小，集中把营收做高，那么盈利才有希望，持续盈利的能力也就成了时间问题。当然，这都是在理想的状态下。 严格意义上，凡客并不算提交 IPO 申请的一波，但是 2011 年，凡客是最接近 IPO 的一年。未来，凡客再重启 IPO 已经没有时间表了。如果，服饰特卖起家的唯品会能够注资凡客，帮助凡客曲线上市也是说不定的事情，那就看凡客的投资方们愿不愿意放下姿态了。

依然不看好的触控科技 我在触控科技上市前时，写过一篇稿子，大致是不看好触控上市的几点理由。其中有谈到几点，一是游戏概念股在资本市场不受认可，PE 基本只能给到 5-6 倍左右；二是触控的核心竞争力问题。实际上，触控主要依赖运营《捕鱼达人》这款游戏在手游界大热，而这款游戏是由其投资的一家游戏公司开发完成的。也就是说，触控作为一家手游公司，并未证明其开发实力，而其标榜的游戏开发引擎，在国内的商业化上是问题，以此做成平台更是有点高远。端游和页游没有做成的事情，触控如果能做成就更好了，毕竟想法是好的。三，游戏公司的持续成长性。游戏是文化创意产业，世界顶尖级游戏公司暴雪也没法抵挡住现在持续下滑的业绩，以及后续作品推出来乏力的宿命。可见，如果解决可持续发展，是所有游戏公司的一门必修课。 就在 5 月 21 日，触控科技的 CEO 陈昊芝在给公司内部员工发的邮件中表示，由于估值太低，触控决定暂缓上市，保持相关上市公开递交的状态可以随时重启。 戏剧的是，陈昊芝在内部邮件中，提到了刚刚 IPO 成功的猎豹移动，说是牺牲了员工利益完成了股东以及老板们的私欲。随后，猎豹的 CEO 傅盛在微博上做了强有力的回击，说是 CEO 只玩概念做不好公司导致上市不了，而员工连套现的机会都丧失了。 双方的口水战最终是以握手言和作罢。事实上，触控科技还是具备了上市的条件，况且今年也是互联网公司集中上市的一年，也可能是最好的一年。但是这么一折腾，触控再图他日东山再起，不知待何时。

http://www.tmtpost.com/112514.html （关注更多钛媒体作者观点，参与钛媒体微信互动（微信搜索 “钛媒体” 或 “taimeiti”））

@ 人力资源研究：某人目前月薪 2 万，去一家公司面试，各方面老板都很满意，但此人要求 2.5 万/月，老板说只能给到 1.5 万/月，但补充说公司未来不可限量，团队很棒、产品很好、市场前景非常好，3 年内上市，到时候可给股份，现在还处于创业奋斗期，希望。。。此人说：咱们好像没什么交情，你的目的是赚钱，我的目的也是赚钱！

@ 达牌汽水: 这种单位就像那种说 “虽然我现在给不了你什么，但将来一定让你成为全世界最幸福的女人” 的男人，远离就是了。

@scmroad配置管理之路:现实是国内比较大方的老板很少；拼了命压低工资，口头给股份，甚至不给股份的占多数。国内能把股份落到纸面上的有几个？据说京东算一个，结果还把纸合同又收回去了。

@scmroad配置管理之路 ：要么给钱，要么给股份，而且是落到纸面上的。忽悠需要养家糊口的人去给你卖命却不给相应报酬的人是不道德的。

@ 周士竞 CodeAtHome:今年我的目标是搞定 ARM，PCB，Common Lisp

@ 老赵织围脖:makefile 学习

@ 怖畔:python、json、jenkins

@ 张于_V：opengrok

完全可以啊。我支持。

所以说，在职的时候，得到老板的认可才是最主要的。

北京大兴亦庄开发区

乐视貌似在成都还没点

免费版本的确有限制。他们的目的就是让你实验一些功能，看看怎么用。

公司真想用了，还是得买 license

回国乡愁：关注中国 热爱美食

《舌尖上的中国》这款具有浓郁中国特色的节目，会勾起思乡的情结。

　　虽然已经出国多年，但乡愁仍然是中国程序员们挥之不去的情节。相隔万里太平洋，每年的假期又有限，回国对中国程序员来说成为了一件奢侈的事情。几乎每个要回国休假的人都会受到周围中国好友的羡慕。苹果等一些与中国业务密切的公司，相关岗位的中国程序员会经常回国出差，更是令周边的好友羡慕不已。

　　美食是中国程序员们最常见的思乡情结。他们会一集集的在网络上看《舌尖上的中国》，一次次刺激自己的味蕾，然后在周边寻找可能的中国餐馆。即便硅谷是美国中餐馆最为密集的地区，但也不可能为来自中国各地的程序员提供完整的家乡味道。思念家乡特色食物的他们，甚至会自己动手来学做各种风味小吃。

　　国内上映的影视大片，他们会通过视频网站来及时收看，为相聚时的闲聊提供话资。偶尔有一两部中国电影在旧金山和 Cupertino 的 AMC 影院上映，总会吸引大量得知消息的中国程序员们。陈奕迅、五月天、曲婉婷等中国歌星来硅谷开演唱会，更是会令硅谷的中国人兴奋异常。记得去年 11 月陈奕迅在旧金山和圣何塞的演唱会，吸引了几乎所有硅谷中国人的关注，当天晚上，自己的微信朋友圈被一轮轮的陈奕迅演唱会刷屏。

　　漂泊在国外的中国程序员，也同样关心着国内的各种新闻。以前他们通过论坛了解中国的动态，而现在则通过微博来获知新闻。国内发生灾难，他们也会难过心酸。国内的腐败案件，他们也会愤慨激动。但相对于国内的网友，这些人在硅谷的中国程序员通常心态更加平和，微博言论也更加理性，极少出现偏激谩骂的语言。

创业梦想：回国创业或等待绿卡

　　硅谷是创业和创新的圣地。和所有这里的科技精英一样，中国程序员的心里也有着创业梦想。但相对于美国本地的人才，中国科技精英还有更为现实的问题——签证和绿卡。那张薄薄的卡片，也是很多硅谷中国人的最大烦恼。什么时候才能拿到绿卡，可以自由创业或者回国，成为他们最为渴望的现实目标。

　　回国创业是一个共同的话题。相对于十多年前，如今中国与美国的经济实力之差已经大幅缩小。对中国程序员来说，相对于在硅谷创业的天花板，回到中国创业更容易获得风投支持，也更容易打开巨大的市场。更重要的是，这里是他们原本的家园。在 2010 年的一份调查中，就有近八成的硅谷中国留学生考虑回国创业，而他们的年龄大部分在 30 岁到 45 岁之间。

　　在很多立志创业的中国程序员来看，创业的机遇比绿卡更为重要。一位 Facebook 的中国员工对新浪科技表示，在 Facebook 发展没有太大的空间，自己一直都有回国创业的想法，但也在一直进行各种权衡。在硅谷生活很安逸，家庭也很幸福，而回国创业就要面临各种变化。“但有好的机会，自己肯定还是想回国发展的。”

　　但为了未来选择和家庭考虑，也有不少中国程序员都会等到获得绿卡 (永久居民卡)，才会考虑跳槽或者创业等选择。如果是常规的美国硕士毕业来到硅谷工作，走 EB2 渠道申请绿卡，按照目前的排期也需要等待 4-5 年。而且回国创业或许还会面临家庭的阻力。给孩子一个较好的生活环境，也是促使他们继续留在美国的重要考虑因素。

　　而另一位在苹果工作的中国工程师则完全没有回国的打算。“在美国已经好些年，回国一切都要从头开始。虽然我也在等待绿卡，但拿到了也没有打算回国，我有老婆孩子，要为他们打算。未来？我希望在苹果做到总监级别。苹果不是谷歌，印度人在这里没有拉帮结派的资本。”