i***h
发帖数: 12655 | 1 想到这几个问题:
1.地图里街道是用线段数组表达的么? 地图本身呢?
2.google map driving direction 是在服务器上算好送过来
还是在用户端计算的?
3.driving direction 是 shortest path 问题么? |
|
p*********t
发帖数: 2690 | 2 javascript有一堆函数，作为用户端语言还是好的。 |
|
|
c*********e
发帖数: 16335 | 4 俺没说server side validation不需要，嘿嘿。
我说的是某些简单的比如validate用户输入的是数字啊，email啊,就在用户端做，客户
端做就慢些,不可取。当然，用户可以disable javascript. |
|
T********i
发帖数: 2416 | 5 你错了，用户的单子，没有ack，DC挂了。丢了就丢了。用户需要过几秒回来再check。
我说过了，即使DC不挂，用户端几百台web server也会经常有挂的。用户不是照样需要
回来再check?
没ack的单子，直接扔掉就好了。反正DC宕机是百年不遇的。不过web server宕机经常
发生，不可避免。用户那边的现象是一模一样。
Amaxon之类的，下单后直接白屏，也是隔三差五。你要是能保证几百台web server永不
宕机，那是意淫。
DC出事概率极低，出事了，扔单子，保障consistency，也是业界惯例。扔掉的本来都
是没ack的，有啥大不了的？反正DC的web server也跟着挂了。本来用户就是要重新
check的。 |
|
d*******r
发帖数: 3299 | 6 我现在组里有从大量用户端 (live video players, like Twitch) 采集 metrics/logs
不断写到 Cassandra 里面，是个老美在做，他就喜欢 Cassandra。上头要我回头从
Cassandra 里面 real time 地分析这些 data stream, 我准备扔到 Storm 上去处理，
大牛大概看看这么做靠谱不? 因为以前我也误解 Cassandra read 慢，怕这样读速度
跟不上，但自己还没有 Cassandra 的经验。 |
|
d*******r
发帖数: 3299 | 7 就是把实时采集到的用户端数据，基本都放在内存(过了几秒以上的，persisent到硬盘
)，然后用内存database里的数据，做一些非常实时的计算 (要支持比较复杂的查询)。
具体的需求还在完善。但是我想要一个快的，而且强大的 memory database, 这样后续
开发方便。
看了 Redis 的表现能力，觉得很爽。就是不支持 Cluster scale out.
Riak 用的人很少吧。我怕查不到资料和经验。难道 Riak 有 Redis 一样高性能的的内
存数据库功能，persistent 做得还比 Redis 好很多？我知道 Riak scale out 不错的。 |
|
k**********g
发帖数: 989 | 8
早在 mid-1990s 时已有人提出的 Thin Client 概念。 唯一目的是节省成本。
Saas也不是全新的概念。 Cloud-based Saas 才是。
用户端得长期定位在 $200 美元以下才算 meeting the thin client goal。 如果某
Thin client 实现不能节省成本，那都是空谈。
http://en.wikipedia.org/wiki/Thin_client |
|
k**********g
发帖数: 989 | 9
是否需要考虑图片缩放问题？高清桌面还是流动用户端？
同主题阅读∶ architecture of 500px, written by the CTO https://news.
ycombinator.com/item?id=9553302 |
|
t**********1
发帖数: 550 | 10 想想下游有一个ACID的MESSAGE QUEUE。假设1M/s速率好了。
注意，抢到票才会送到下游。而下游的MQ是ACID的就是带persistence。保证persist后
才ACK。
那么，假定一天卖1000万张票。及时两秒抢光，用户等10秒也能收到确认。注意，我们
写入MQ，等ACK，再给用户确认。MQ消息带用户端ReqID。
别问我ACID MQ怎么做？你给我$1万，我给你做一个软件，硬件你自己买，保证指标合
格。
至于没来及写入MQ的，crash后恢复，当作没发生好了。
这东西恢复也就1秒以内。因为是hot standby。差的也就是最后几笔交易而已。 |
|
g****t
发帖数: 31659 | 11 我不是好看公司资厉和title.我高看的是市场。
你说的情况一定是存在的。简单说企业应用代码复杂有两个情况。功能无非出自两个源
头。
A 程序猿的头目为了让自己组有工开。加一些没用的功能。
B 用户端出现的的corner cases的修补和市场的新需求
这两种情况必然都是存在的。能一眼看出来哪个项目是做什么的才能混日子。不然要么
就是第一种假装瞎忙，要么就是第二种王寅这种，被人忙了还不知道在干啥。
简单说，不掌握以及不了解demand的动机和源头的程序猿只能按你说的路子走。只能
按别人发过来的demand混日子。发功能的往往是老印。
市场是技术的重要源头。
: 你想多了，太高看公司级别和资历了...
: 公司代码愈发复杂，多半是逐步腐败的结果，就是每次一个老油条老员工
来加个
功能,
: 老油条只在乎用最小的力气，冒最小的风险，交作业交差, 然后领工资去
混下个
项目.
: 老油条剩下大把时间，拍拍马屁, 搞政治, 或者刷刷题，跳跳槽, 资历和
级别涨
得更快.
: 老王只是不明白(或者死不认)这个道理，老是要认真干项目, 所以总是吃
亏心里
... 阅读全帖 |
|
q**u
发帖数: 12289 | 12 就是通过IIS漏洞修改网页脚本，然后通过scripting host传染用户端。 |
|
t*******e
发帖数: 216 | 13 我是没有专门做过hifi，说得不对就请专家纠正了。
传统hifi基本上应该算是模拟电路，因为其位于电子产品的用户端 （耳朵），涉及的
知识为低频模拟电路，Hz-几十kHz，功放设计，低噪设计，线性设计，当然有声学的物
理设计。数字技术也不完全在其前端，因为近些年的一些数字噪声处理（编码）飞速发
展，高性能模数转换器技术，也可以用到对于原本音质不好的音轨进行数字再处理合成
（算是midi了）。我认为搞音乐/音响的人，midi和hifi一般不分开，所以这个应该是
个模拟电子+数字电子+数模信号处理的综合
good luck |
|
c***4
发帖数: 56 | 14 你去google一下HVAC，ME不跟电网配送打交道，跟发电才有关系，到了用户端就跟走线
有关系了 |
|
z*****2
发帖数: 498 | 15 所谓数据库无非一是存一是取。在用户端主要是取。怎么取，靠搜索。这么多年
试了很多方法，但总是不尽人意。
去年年尾，按照一个医生朋友的建议，花了近三天修改了 “Adv. Search" 的
程序，然后邀上几位志愿者试着搜了一番，看上去个个眉头紧锁，但也都承认比
以前好了。 于是选个黄道吉日，2012春节推出，但好像搜客们并没有注意到变
动， 大概以前的"Adv. Search" 太烂，以至现在大家都在躲着它。CMG 网友
们呀，不管好不好，试试再说，并欢迎把批评建议送到 a***[email protected]，
版主天天想夜夜盼的就是读者来信。 以下是 ”Adv. Search" 的链接：
http://physician.cmgforum.net/search4.php
其实没有什么新鲜的， 就是一些联合搜索而已（conjunction)，有专业和学校
的联合，专业地域以及学校地域的联合。譬如您要想知道纽约州的北医毕业的医生
们，就用学校地域联合搜索就成了。这三个搜素基本上弥补了其他几个搜索的缺陷。
当然还是那句老话，No Guarantee! |
|
d*b
发帖数: 21830 | 16 我说的意思是，user level的应用越来越倾向于script language而不是纯粹的高级语
言，而算法的开发则从user中分离开来。由专业公司来进行。这也是现在工业界很流行
的做法。
不要说工业界，就是物理领域的大型项目都是走这条路，比如现在的LHC，跟Tevatron
软件开发最大的区别是，基本是专业计算机人士开发framework, 而physicist开发基于
framework的应用。语言上介于纯粹的C++和script之间，比如ROOT的CINT和macro就是
这样。而硬件控制方面从用户端运行的程序（daemon)向web based control演化。这个
类似于IT界流行的widget.
这种趋势是把physicist从繁重的重覆劳动中解放出来，变开发+应用为单纯的应用。很
多人没有多少大型项目的研究经验，就空谈这个那个，至于fortran,我老进physics这
行的第一天就被人告知，no fortran, no c, C++ only。CERN lib都重写了，geant都
重写了，pythina都重写了，我看你就别谈什么历史包袱了，不是2个summer |
|
发帖数: 1 | 17 14小时前
“阿里影业账面资金仍有百亿规模，因此还将继续加大对淘票票的投入，暂时没有上限
。”在第二十届上海国际电影节上，阿里影业董事局主席俞永福对2016年亏损10亿元的
情况作出表态。透过这段充满土豪气息的发言，不难发现烧钱还将是阿里影业下阶段的
主旋律之一。贵为“阿里太子”，财大气粗的俞永福自然有任性的资本，但其嫡系UC已
经在这种思维下失败，此番阿里影业的烧钱模式又能有几分胜算？
近两年来，阿里影业的业绩一路下滑，至2016年跌入谷底，净亏损9.59亿元，较2015年
下跌305.8%。而巨额缺口主要源自阿里影业支持旗下APP淘票票参与票补大战，导致市
场推广费用激增，2016年亏损金额达到6.074亿元，净利润较2015年下跌6.3亿元，单项
亏损金额大约占亏损总额的70%。
面对淘票票这个烧钱的无底洞，俞永福坚持不设上限的投入难免引人遐想，这或许与阿
里影业在内容领域的疲软有关：内容生产上，去年阿里影业首部主投主控的影片《摆渡
人》没能达到业界期望，人们对其在内容环节的控制能力产生疑问，分发渠道上，优酷
的播放量和用户覆盖被爱奇艺、腾讯视频超越，土豆网在短视频领域刚开始，还... 阅读全帖 |
|
b*******x
发帖数: 100 | 18 大部分R爱好者都用过SAS，也没人非要挤兑SAS，有时候为了工作我们可能也要学习使
用SAS。但是
SAS爱好者你们也别挤兑R，抛开功能不讲，抛开用户端不讲，所有开源社区天生在原动
力和原创力上就
是有优势，你让SAS把源码开放了让大家找bug你看他们敢不敢啊。
future |
|
|
d*b
发帖数: 21830 | 20 我说的不是一般的手机版，是一个类似聊天器的连接单个版面的手机版。介于micro
blog和sms chat之间，具体的用户端界面类似于sidekick。
你不用花多少心思，你只要开发SQL接口，接口标准，客户端软件类似于widget,完全可
以由用户自己开发。工艺流程可以参考amazon.
那些伪币寿衣钻风啥的，根本不能让你占领high ground. |
|
a****t
发帖数: 7049 | 21 呵呵，不会停止的，远不止他那边服务器cache的问题，用户端脚本也cache了，只要有
病源就会继续传播。要么用户清除cache并且把脚本域名列入blacklist，要么站方出面
清理用户信息。更不说这漏洞本身还没解决，别人也可以来继续乱搞。 |
|
发帖数: 1 | 22 您好，事隔很久另外想请教
发现贵站 ssh 用的版本还是 ssh1
但最近大部份较新的 ssh 用户端都已经限制只支援 ssh2 了
基于相关安全连线考量
不知贵站有无考虑调整相关设定，谢谢！ |
|
l******d
发帖数: 5255 | 23 在一个产业里，只要一个企业可以控制这个产业链条上的任何一个环节或者在这个环节
上占优势地位，它就可以利用这个优势跟上下游bargin来赚钱。这就是企业都想垄断的
根本原因。
fb说到底就是这个牛，它控制了用户端。号称有5亿用户，基本都是实名。世界上哪还
有什么网站有这个地位。靠这个，fb就可以做很多事。前几天电影版那几个id完全不理
解形势，跟桃花源中人似的，现在还在纠缠什么fb没技术含量，也不看看这都什么年代
了。google上市才几年，现在都快日过午了。groupon从创立到现在才3年不到，都价值
60亿了。那几个兄弟居然现在还在说fb没前途。简直让人震惊。 |
|
l******d
发帖数: 5255 | 24 在一个产业里，只要一个企业可以控制这个产业链条上的任何一个环节或者在这个环节
上占优势地位，它就可以利用这个优势跟上下游bargin来赚钱。这就是企业都想垄断的
根本原因。
fb说到底就是这个牛，它控制了用户端。号称有5亿用户，基本都是实名。世界上哪还
有什么网站有这个地位。靠这个，fb就可以做很多事。前几天电影版那几个id完全不理
解形势，跟桃花源中人似的，现在还在纠缠什么fb没技术含量，也不看看这都什么年代
了。google上市才几年，现在都快日过午了。groupon从创立到现在才3年不到，都价值
60亿了。那几个兄弟居然现在还在说fb没前途。简直让人震惊。 |
|
