最新 | 最热门 | 最高评价

+0  Cuckoo Filter:设计与实现

Tag: C/C++语言 | 数据库 | 程序设计 | 趣味问题 | Algorithm | filter | hashing | 海量数据
Leo 发于 2015年09月02日 09:18 | 点击: 1157 | 展开摘要
(感谢网友 @我的上铺叫路遥 投稿)

对于海量数据处理业务,我们通常需要一个索引数据结构,用来帮助查询,快速判断数据记录是否存在,这种数据结构通常又叫过滤器(filter)。考虑这样一个场景,上网的时候需要在浏览器上输入URL,这时浏览器需要去判断这是否一个恶意的网站,它将对本地缓存的成千上万的URL索引进行过滤,如果不存在,就放行,如果(可能)存在,则向远程服务端发起验证请求,并回馈客户端给出警告。

索引的存储又分为有序和无序,前者使用关联式容器,比如B树,后者使用哈希

查看全文: http://www.udpwork.com/item/14563.html

+0  系统设计典型问题的思考

Tag: System Design | 典型问题 | 系统设计
四火 发于 2015年03月15日 15:34 | 点击: 1267 | 展开摘要
系统设计方面的问题问题是非常考验经验和思维过程的,而且和常见的算法问题、语言基础问题不同,涉及的面很广,还没有比较一致的判别标准。但无论如何,还是可以归纳一些常见的思路和典型问题的线索。

首先,反复沟通和澄清系统需求。只有把需求澄清清楚了,才可以开始思考并落到纸面上。但是需求的沟通应该是持续和循序渐进的,问题很难从一开始就思考全面。最重要的条目包括:

use cases,通常问题只需要2~3个use cases需要考虑,其他的部分会晚些考虑,或者不考虑。这样就可以简化问题

查看全文: http://www.udpwork.com/item/13993.html

+0  谜题的答案和活动的心得体会

Tag: 杂项资源 | 趣味问题 | Algorithm | Linux | Puzzle | Unix
陈皓 发于 2014年08月06日 07:47 | 点击: 1515 | 展开摘要
我于2014年8月3日周六的上午在微博、twitter、CoolShell上发布了一个和程序员有关的解谜题的活动——【活动】解谜题送礼物。我使用了二级域名fun.coolshell.cn做为这次活动的页面。

截止这篇文章发布的时候,fun.coolshell.cn的访问量UV大约有4万左右,通关人数大约有200人,但因为在活动的第二天网上就出了一些答题攻略,通过分析,实际靠自己能力通过的人数在130人左右。通过率大约不到4‰的样子。

在这里我把整个谜题和做这个活动的东西写

查看全文: http://www.udpwork.com/item/12864.html

+0  【活动】解迷题送礼物

Tag: 杂项资源 | 趣味问题 | Algorithm | Puzzle
陈皓 发于 2014年08月03日 18:52 | 点击: 1248 | 展开摘要
首先,先跟大家道歉一下最近CoolShell大约长达一个多月没有什么更新,原因主要在于,我去看世界杯去了,这一个月的世界杯熬夜看球使我的精力不佳,导致世界杯结束后的几个星期也没有缓过来,所以没有更新什么文章。好多朋友写邮件或是在微博上at我催我更新,所以有点惭愧了。

精神不佳我就不写文章了。于是,世界杯过后,我每天都会抽出每天晚上和周末的一些碎片时间,我仿照一些前端过关的游戏,做了几个和程序员有关的迷题,也是要通关的,不过和前端知识没什么关系。这个游戏我放到了下面这个二级域

查看全文: http://www.udpwork.com/item/12849.html

+0  层次

Tag: Engineering Culture | Recommended | 层次 | 工程师 | 问题
四火 发于 2014年07月19日 15:40 | 点击: 1048 | 展开摘要
以下文字,看看就好,笑笑就好。

最近在被一个问题折磨,大致上是,公司内部某些技术更替的关系,要把原有的一个鉴权的组件A淘汰掉,迁移到一个新的替代品B上,我估摸着也就一天时间搞定它绰绰有余了。没料想一猛子扎进去就没那么容易出来了,替换完成以后的测试傻了眼,发现了一个诡异的问题,于是追根溯源,把牵涉进来的林林总总一一拖出来检查排除枪毙,环境比较复杂,debug起来又比较头疼,折磨了三天半的时间;最后还靠这个替代品B的问题列表里面,有某下游产品的工程师跳出来说是这个替代品自身有问

查看全文: http://www.udpwork.com/item/12756.html

+0  如何用最有创造力的方式输出42

Tag: 趣味问题 | 轶事趣闻 | 42 | Programming | 程序员
陈皓 发于 2014年03月06日 22:42 | 点击: 1711 | 展开摘要
酷壳似乎好长时间没有像《编程真难啊》或是《老手是这样教新手编程的》或是像《如何写出无法维护的代码》这样“严肃正经”的文章了,所以,赶在大家还没有向我扔臭鸡蛋前奉献一篇。这篇文章来自CodeGolf.StackExchange上的《Most creative way to display 42》—— 请以最有创造力的方式输出42。于是出现了下面的这些答案(注:精彩的总是留在最后面)

人生和宇宙终级问题的答案:42

这里,需要介绍一下为什么要输出42。这时因为42是我们人生,

查看全文: http://www.udpwork.com/item/11908.html

+0  再谈榔头和钉子

Tag: Programming Paradigms | 编程范型 | 问题
四火 发于 2014年02月20日 11:39 | 点击: 1029 | 展开摘要
不久前写过一篇《给我一把榔头,满世界都是钉子》,从算法和数据结构的角度谈了谈对于问题和问题解决的工具这两方面我的看法;而最近看到了这样的代码,一个表格,单数行和双数行的样式不同,于是有程序员这样写道:

var trs = $("#spreadSheet tr");
for(var i=0; i<trs.size(); i++){
if(i%2)
$(trs.get(i)).children("td").css("color", "RED");

查看全文: http://www.udpwork.com/item/11747.html

+0  一个“蝇量级” C 语言协程库

Tag: C/C++语言 | 程序设计 | 趣味问题 | C++ | coroutine | Queue | yield | 协程
Leo 发于 2014年01月28日 10:50 | 点击: 5830 | 展开摘要
(感谢网友 @我的上铺叫路遥 投稿)

协程(coroutine)顾名思义就是“协作的例程”(co-operative routines)。跟具有操作系统概念的线程不一样,协程是在用户空间利用程序语言的语法语义就能实现逻辑上类似多任务的编程技巧。实际上协程的概念比线程还要早,按照 Knuth 的说法“子例程是协程的特例”,一个子例程就是一次子函数调用,那么实际上协程就是类函数一样的程序组件,你可以在一个线程里面轻松创建数十万个协程,就像数十万次函数调用一样。只不过子例程只有一

查看全文: http://www.udpwork.com/item/11640.html

+0  Hadoop无法解决的问题

Tag: Machine Learning & Big Data | Hadoop | 大数据 | 问题
四火 发于 2013年11月11日 21:54 | 点击: 1279 | 展开摘要
文章系本人原创,转载请保持完整性并注明出自《四火的唠叨》

因为项目的需要,学习使用了Hadoop,和所有过热的技术一样,“大数据”、“海量”这类词语在互联网上满天乱飞。Hadoop是一个非常优秀的分布式编程框架,设计精巧而且目前没有同级别同重量的替代品。另外也接触到一个内部使用的框架,对于Hadoop做了封装和定制,使得更满足业务需求。我最近也想写一些Hadoop的学习和使用心得,但是看到网上那么泛滥的文章,我觉得再写点笔记一样的东西实在是没有价值。倒不如在漫天颂歌的时候冷

查看全文: http://www.udpwork.com/item/11102.html

+0  伙伴分配器的一个极简实现

Tag: C/C++语言 | 程序设计 | 趣味问题 | Algorithm | Buddy | 内存管理
Leo 发于 2013年10月09日 23:10 | 点击: 1822 | 展开摘要
(感谢网友 @我的上铺叫路遥 投稿)

提起buddy system相信很多人不会陌生,它是一种经典的内存分配算法,大名鼎鼎的Linux底层的内存管理用的就是它。这里不探讨内核这么复杂实现,而仅仅是将该算法抽象提取出来,同时给出一份及其简洁的源码实现,以便定制扩展。

伙伴分配的实质就是一种特殊的“分离适配”,即将内存按2的幂进行划分,相当于分离出若干个块大小一致的空闲链表,搜索该链表并给出同需求最佳匹配的大小。其优点是快速搜索合并(O(logN)时间复杂度)以及低外部碎片(

查看全文: http://www.udpwork.com/item/10916.html

+0  换个角度思考问题

Tag: Algorithm & Data Structure | Recommended | 思考 | 角度 | 问题
四火 发于 2013年10月03日 21:52 | 点击: 632 | 展开摘要
文章系本人原创,转载请保持完整性并注明出自《四火的唠叨》

最近在看一本书,叫做《思考的乐趣》,第26节“我最爱的证明”,里面介绍了这样一则有趣的问题(文章链接在此):

设想一个平面上布满间距为1的横纵直线,形成由一个个1×1正方形组成的网格。任意给一个面积小于1个单位的图形,证明这个图形总能放在网格中而不包含任何一个格点。

初看这个论断,觉得似乎是正确的,但又不知从何下手。文中指出证明的思路很巧妙,让人感到数学的美妙。我的感触是,文中的证明大大地换了个角度,很有峰回路转

查看全文: http://www.udpwork.com/item/11016.html

+0  留心那些潜在的系统设计问题

Tag: Architecture | Recommended | 系统设计 | 评审 | 问题
四火 发于 2013年09月19日 23:21 | 点击: 656 | 展开摘要
文章系本人原创,转载请保持完整性并注明出自《四火的唠叨》

在系统设计阶段考虑全面很难,有许多人倾向于把整个设计分成若干阶段,在迭代中完成整个设计,这本身是非常好的,但是,就如同“先做出来,以后再优化”这样的经典谎言一样,本身并无错,只是许多程序员都不习惯于真正的迭代设计和迭代优化。举例来说,有一个日益复杂的类,每个人都修改一点点,一直到最后都没有人愿意去做重构,大家的心态都是一样的:“我只修改了一点点,为什么要我去动那么大的刀,于我没有任何好处”。我不在这里谈论这一问题的解

查看全文: http://www.udpwork.com/item/11018.html
|<<<123>>>| 一共3页, 28条记录