P*H
2 楼
我考古的帖子说6年算resident，就可以用turbotax了。但是turbotax官网说做不了F1。
另外，这个6年算resident好像只是federal的。州好像都没有这种说法。
我现在是8年f1，去年4月 opt。外州搬加州。这种情况可以用turbotax吗？
另外，这个6年算resident好像只是federal的。州好像都没有这种说法。
我现在是8年f1，去年4月 opt。外州搬加州。这种情况可以用turbotax吗？
m*t
3 楼
140， H1好像都停滞了一样，不pp就不动了。连trackitt上都没有什么进展。
s*y
4 楼
上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
Tomcat、MySql组成后台服务器，中间用Web Service相连接。
像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
Tomcat、MySql组成后台服务器，中间用Web Service相连接。
像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
l*r
5 楼
Female
The hotel is close to the convention center.
post for others, please reply to:
g*********[email protected]
Thanks :)
The hotel is close to the convention center.
post for others, please reply to:
g*********[email protected]
Thanks :)
w*k
6 楼
静安那十套房子都卖掉，立马就突破了
房哥你努力一些！
【在 C*****5 的大作中提到】
: 这次把老脸豁出去了。下周怕是真的要突破了，个人认为概率大于75%，大家周末愉快
: ！
房哥你努力一些！
【在 C*****5 的大作中提到】
: 这次把老脸豁出去了。下周怕是真的要突破了，个人认为概率大于75%，大家周末愉快
: ！
s*e
7 楼
3月份递交的AP现在还没有下来
p*2
8 楼
是 小公司mean就够了
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
C*5
9 楼
等哥有静安10套房把mitbbs买下来，股版几个和哥不对付的IDs挂在首页示众可好？
【在 w**********k 的大作中提到】
: 静安那十套房子都卖掉，立马就突破了
: 房哥你努力一些！
【在 w**********k 的大作中提到】
: 静安那十套房子都卖掉，立马就突破了
: 房哥你努力一些！
m*t
10 楼
是啊， 估计所有的io都弄去批485去了
【在 s********e 的大作中提到】
: 3月份递交的AP现在还没有下来
s*y
11 楼
刚才看到知乎上有人讨论，ms评价不高
http://www.zhihu.com/question/23512853
http://www.zhihu.com/question/23512853
z*0
12 楼
是老静安还是新静安啊？区别不是一点点啊！
y*n
13 楼
PP 15天。
再说，140不用急，前面485能尽早被clear了，才是对后来人最重要的。
【在 m******t 的大作中提到】
:
: 是啊， 估计所有的io都弄去批485去了
再说，140不用急，前面485能尽早被clear了，才是对后来人最重要的。
【在 m******t 的大作中提到】
:
: 是啊， 估计所有的io都弄去批485去了
g*g
14 楼
几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
势很大。
性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
常发生。
就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
势很大。
性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
常发生。
就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
C*5
15 楼
前闸北的大宁也是不错的。竟然已经开始和徐家汇叫板了又有没有。
【在 z******0 的大作中提到】
: 是老静安还是新静安啊？区别不是一点点啊！
【在 z******0 的大作中提到】
: 是老静安还是新静安啊？区别不是一点点啊！
m*t
16 楼
着急是没有用的。但是7个多月还不批，太他妈的折磨人了
【在 y***n 的大作中提到】
: PP 15天。
: 再说，140不用急，前面485能尽早被clear了，才是对后来人最重要的。
w*z
17 楼
你们 web service 用 Jersey, webserver 用什么？
【在 g*****g 的大作中提到】
: 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
: 势很大。
: 性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
: 范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
: 个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
: feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
: 常发生。
: 就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
【在 g*****g 的大作中提到】
: 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
: 势很大。
: 性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
: 范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
: 个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
: feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
: 常发生。
: 就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
d*v
18 楼
大宁和徐家汇还是差挺多的，普通shopping mall和某某广场的区别
【在 C*****5 的大作中提到】
: 前闸北的大宁也是不错的。竟然已经开始和徐家汇叫板了又有没有。
【在 C*****5 的大作中提到】
: 前闸北的大宁也是不错的。竟然已经开始和徐家汇叫板了又有没有。
g*g
19 楼
tomcat.
【在 w**z 的大作中提到】
: 你们 web service 用 Jersey, webserver 用什么？
【在 w**z 的大作中提到】
: 你们 web service 用 Jersey, webserver 用什么？
C*5
20 楼
大宁的久光快建好了，和港汇有得一比。不过这两的地方都和我无关，谁赢我都没意
见。
【在 d******v 的大作中提到】
: 大宁和徐家汇还是差挺多的，普通shopping mall和某某广场的区别
见。
【在 d******v 的大作中提到】
: 大宁和徐家汇还是差挺多的，普通shopping mall和某某广场的区别
c*e
21 楼
web services要买ssl,有的公司为了省这个钱，不用web services,用其它的办法。
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
z*0
22 楼
刚从上海回来，好多看似高大上的mall，没看到过给残疾人的开门按钮。整个人民广场
就找到一个无障碍电梯到下面大厅，从大厅到下面站台要从员工通道里下去！！！各类
人员素质还是同二十年前差不多，房价是高了，上海基本成农村了。整个成下只角了！
！！
就找到一个无障碍电梯到下面大厅，从大厅到下面站台要从员工通道里下去！！！各类
人员素质还是同二十年前差不多，房价是高了，上海基本成农村了。整个成下只角了！
！！
D*r
23 楼
SOA数据库访问是不是一般又必须设计高响应的网络
加复杂的cache体系，否则会慢的哭。
【在 g*****g 的大作中提到】
: 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
: 势很大。
: 性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
: 范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
: 个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
: feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
: 常发生。
: 就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
加复杂的cache体系，否则会慢的哭。
【在 g*****g 的大作中提到】
: 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
: 势很大。
: 性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
: 范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
: 个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
: feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
: 常发生。
: 就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
l*r
24 楼
静安有10套房，不用上买卖提了
【在 C*****5 的大作中提到】
: 等哥有静安10套房把mitbbs买下来，股版几个和哥不对付的IDs挂在首页示众可好？
【在 C*****5 的大作中提到】
: 等哥有静安10套房把mitbbs买下来，股版几个和哥不对付的IDs挂在首页示众可好？
w*z
25 楼
你们的ws 分内部和公开的吗？ 内部访问的就不用authentication了？
【在 g*****g 的大作中提到】
: tomcat.
【在 g*****g 的大作中提到】
: tomcat.
C*5
26 楼
咋样？真的突破了。把股票抱紧了，别高抛低吸了，小心偷鸡不成蚀把米。老老实实把
这个主升段吃完得了。
【在 C*****5 的大作中提到】
: 这次把老脸豁出去了。下周怕是真的要突破了，个人认为概率大于75%，大家周末愉快
: ！
这个主升段吃完得了。
【在 C*****5 的大作中提到】
: 这次把老脸豁出去了。下周怕是真的要突破了，个人认为概率大于75%，大家周末愉快
: ！
s*y
27 楼
怎么买SSL（Secure Sockets Layer）？
【在 c*********e 的大作中提到】
: web services要买ssl,有的公司为了省这个钱，不用web services,用其它的办法。
w*z
28 楼
根据domain 买个 signed certificate 装在Web server 上。要不browser 就报waning.
【在 s****y 的大作中提到】
:
: 怎么买SSL（Secure Sockets Layer）？
【在 s****y 的大作中提到】
:
: 怎么买SSL（Secure Sockets Layer）？
l*s
29 楼
PayPal的架构是，Dust.js/Backbone.js/Node.js + RESTful services (Java or
Scala).
Scala).
g*g
30 楼
内部不用验证，直接Eureka做mid tier load balancing. 只有个别服务有对外的WS，
验证应该跟网站类似。
【在 w**z 的大作中提到】
: 你们的ws 分内部和公开的吗？ 内部访问的就不用authentication了？
验证应该跟网站类似。
【在 w**z 的大作中提到】
: 你们的ws 分内部和公开的吗？ 内部访问的就不用authentication了？
g*g
31 楼
不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
.9%的
availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
circuit breaker, graceful degradation的问题都要考虑。
【在 D*****r 的大作中提到】
: SOA数据库访问是不是一般又必须设计高响应的网络
: 加复杂的cache体系，否则会慢的哭。
.9%的
availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
circuit breaker, graceful degradation的问题都要考虑。
【在 D*****r 的大作中提到】
: SOA数据库访问是不是一般又必须设计高响应的网络
: 加复杂的cache体系，否则会慢的哭。
w*z
32 楼
就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
ation service down 了， 搞个static list 糊弄一下你。
99
【在 g*****g 的大作中提到】
: 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
: .9%的
: availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
: circuit breaker, graceful degradation的问题都要考虑。
ation service down 了， 搞个static list 糊弄一下你。
99
【在 g*****g 的大作中提到】
: 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
: .9%的
: availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
: circuit breaker, graceful degradation的问题都要考虑。
p*2
33 楼
我觉得是 所以其实挺麻烦的
【在 w**z 的大作中提到】
: 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
: ation service down 了， 搞个static list 糊弄一下你。
:
: 99
【在 w**z 的大作中提到】
: 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
: ation service down 了， 搞个static list 糊弄一下你。
:
: 99
w*z
34 楼
是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
code 同时run, 如何切换，如何 rollback, 确实不容易。
【在 p*****2 的大作中提到】
: 我觉得是 所以其实挺麻烦的
，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
code 同时run, 如何切换，如何 rollback, 确实不容易。
【在 p*****2 的大作中提到】
: 我觉得是 所以其实挺麻烦的
p*2
35 楼
这也是challenge和经验呀
所以要像你们这些大牛学习了
感觉半海这方面是专家
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
所以要像你们这些大牛学习了
感觉半海这方面是专家
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
y*u
36 楼
其实我觉得小公司基本上不太需要有后端开发
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
g*g
37 楼
其实没有那么难，有问题，就会有人去做轮子，有规范化的设计模式，说到底都是经验
而已。
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
而已。
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
c*e
38 楼
外面的网站能调用公司内部的web services吗？
【在 g*****g 的大作中提到】
: 内部不用验证，直接Eureka做mid tier load balancing. 只有个别服务有对外的WS，
: 验证应该跟网站类似。
【在 g*****g 的大作中提到】
: 内部不用验证，直接Eureka做mid tier load balancing. 只有个别服务有对外的WS，
: 验证应该跟网站类似。
c*e
39 楼
那不就相当于redirect到400,500 error page了吗？自己搞一个static list 放error
page上，看着象没有error一样？
【在 w**z 的大作中提到】
: 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
: ation service down 了， 搞个static list 糊弄一下你。
:
: 99
page上，看着象没有error一样？
【在 w**z 的大作中提到】
: 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
: ation service down 了， 搞个static list 糊弄一下你。
:
: 99
c*e
40 楼
goodbug到底在netflix做java programming还是network administration的阿？
【在 g*****g 的大作中提到】
: 其实没有那么难，有问题，就会有人去做轮子，有规范化的设计模式，说到底都是经验
: 而已。
【在 g*****g 的大作中提到】
: 其实没有那么难，有问题，就会有人去做轮子，有规范化的设计模式，说到底都是经验
: 而已。
w*z
41 楼
比这复杂。一个页面，可能要。调用几十个service。 一个error page 哪行啊。
error
【在 c*********e 的大作中提到】
: 那不就相当于redirect到400,500 error page了吗？自己搞一个static list 放error
: page上，看着象没有error一样？
error
【在 c*********e 的大作中提到】
: 那不就相当于redirect到400,500 error page了吗？自己搞一个static list 放error
: page上，看着象没有error一样？
z*e
42 楼
扯
我工作过的小公司哪怕只有20多个人
都有前后端分离
他们用的是php+spring
【在 y**********u 的大作中提到】
: 其实我觉得小公司基本上不太需要有后端开发
我工作过的小公司哪怕只有20多个人
都有前后端分离
他们用的是php+spring
【在 y**********u 的大作中提到】
: 其实我觉得小公司基本上不太需要有后端开发
D*r
43 楼
有道理，这种软处理的high availability很有意思。我原来一想到HA，就想到一个
daemon进程盯着、进程死了就重新启一下，或者热备一个系统、VRRP什么的热备份一个
，系统复杂了很多，工行2014年7月16日银证系统网络设备故障，热备系统切换期间出
现单边交账，这种很容易出问题。
circuit breaker\graceful degradation能让系统健壮很多，而且也不会造成复杂度爆
炸。
并行异步处理，可能对reddit这种小条目的架构能做到惊人的吞吐量，关键服务的数据
库的处理如果用这个，感觉还是危险。
99
【在 g*****g 的大作中提到】
: 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
: .9%的
: availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
: circuit breaker, graceful degradation的问题都要考虑。
daemon进程盯着、进程死了就重新启一下，或者热备一个系统、VRRP什么的热备份一个
，系统复杂了很多，工行2014年7月16日银证系统网络设备故障，热备系统切换期间出
现单边交账，这种很容易出问题。
circuit breaker\graceful degradation能让系统健壮很多，而且也不会造成复杂度爆
炸。
并行异步处理，可能对reddit这种小条目的架构能做到惊人的吞吐量，关键服务的数据
库的处理如果用这个，感觉还是危险。
99
【在 g*****g 的大作中提到】
: 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
: .9%的
: availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
: circuit breaker, graceful degradation的问题都要考虑。
D*r
44 楼
据说他家做了chaos monkey，专门随机搞死一个个的节点，来测稳定性……
多个版本的可以对应请求把版本号带上，比如用发布日期做版本号。
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
多个版本的可以对应请求把版本号带上，比如用发布日期做版本号。
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
g*g
45 楼
大多数网站，主页面可能过几十个服务，但不过是读而已，很多服务之间也没有顺序的
要求。所以异步并行是可能的。
Ajax的本质如此。
【在 D*****r 的大作中提到】
: 有道理，这种软处理的high availability很有意思。我原来一想到HA，就想到一个
: daemon进程盯着、进程死了就重新启一下，或者热备一个系统、VRRP什么的热备份一个
: ，系统复杂了很多，工行2014年7月16日银证系统网络设备故障，热备系统切换期间出
: 现单边交账，这种很容易出问题。
: circuit breaker\graceful degradation能让系统健壮很多，而且也不会造成复杂度爆
: 炸。
: 并行异步处理，可能对reddit这种小条目的架构能做到惊人的吞吐量，关键服务的数据
: 库的处理如果用这个，感觉还是危险。
:
: 99
要求。所以异步并行是可能的。
Ajax的本质如此。
【在 D*****r 的大作中提到】
: 有道理，这种软处理的high availability很有意思。我原来一想到HA，就想到一个
: daemon进程盯着、进程死了就重新启一下，或者热备一个系统、VRRP什么的热备份一个
: ，系统复杂了很多，工行2014年7月16日银证系统网络设备故障，热备系统切换期间出
: 现单边交账，这种很容易出问题。
: circuit breaker\graceful degradation能让系统健壮很多，而且也不会造成复杂度爆
: 炸。
: 并行异步处理，可能对reddit这种小条目的架构能做到惊人的吞吐量，关键服务的数据
: 库的处理如果用这个，感觉还是危险。
:
: 99
w*z
46 楼
听说它们不止搞死节点，还搞死AZ， 甚至整个region 做测试。
【在 D*****r 的大作中提到】
: 据说他家做了chaos monkey，专门随机搞死一个个的节点，来测稳定性……
: 多个版本的可以对应请求把版本号带上，比如用发布日期做版本号。
【在 D*****r 的大作中提到】
: 据说他家做了chaos monkey，专门随机搞死一个个的节点，来测稳定性……
: 多个版本的可以对应请求把版本号带上，比如用发布日期做版本号。
z*e
47 楼
这样好，可以有效减少on call次数
【在 w**z 的大作中提到】
: 听说它们不止搞死节点，还搞死AZ， 甚至整个region 做测试。
【在 w**z 的大作中提到】
: 听说它们不止搞死节点，还搞死AZ， 甚至整个region 做测试。
c*0
48 楼
您接触的小公司或者数量不够，或者类型单一。
【在 y**********u 的大作中提到】
: 其实我觉得小公司基本上不太需要有后端开发
相关阅读
Paper help, Thanks!报一个Amazon湾区的offer，求问是否该接 (转载)回国还是继续留在国外 大家帮忙做下分析paper help (转载)亚特兰大地区technician位置Paper help, Thank you!paper help!jacs/angew/pnas/nature chemistry/nature communications请问：双键的顺反异构如何通过2D NOESY确定？Paper help. Thanks!Paper help! Thanks!paper help请教一个关于gaussian unfchk的问题Paper help, thanks!paper help,Thanks化学要转行的可以参考一下这位姐姐的人生轨迹有没有人申请了carestream的啊？这些傻逼叫兽负了我们这个方向如何：木材生产生物燃料？谢谢了。求国内生物医药猎头推荐------------谢谢