Facebook等大型互联网公司推动的服务器与数据中心、大数据工具的开源化项目类似，当大型互联网公司们在超大规模基础设施运营方面面临的挑战 超出技术厂商的能力时，这些巨头就选择反客为主，成为创新技术的推动者和提供者。同样的情况也在信息安全领域中发生着。不少大型互联网公司经常会将自己开 发的顶级安全工具开源，推动整个互联网的安全发展。 本月早些时候安全牛曾介绍过Google开源的web安全测试工具Firing Range、Nogofail以及Facebook开源的Osquery等。 事实上不仅Google、Facebook，包括Netflix甚至Etsy.com这样的电商网站也都贡献过精品开源安全工具。 以下安全牛为大家汇总整理十大互联网巨头的开源安全工具，供大家收藏参考： 一、安全猴 Security Monkey “安全猴”是Netflix三年前开发的一个安全工具，能够对亚马逊云服务的配置进行监控和安全分析，组件功能包括监控各种AWS账号组件，机遇规则的开发和执行活动，在审计规则被触发时通知用户，并存储配置历史信息用作电子取证和审计目的。 二、OSquery OSquery是Facebook刚刚发布的一个安全工具，为安全专业人士提供了一个可调用底层操作系统功能的系统，例如启动进程、加载内核模块、在SQL数据库表中打开网络连接进行查询和监控等。 三、Skyline Skyline是电商网站Etsy技术团队开发的一个类似Nagios的实时异常侦测系统，主要目的是为安全团队提供一个可扩展的被动监控指标体系——可以同时跟踪成百上千的指标。 四、MIDAS MIDAS是Etsy与Facebook安全团队合作为Mac电脑开发的一个轻量级可扩展的入侵侦测系统。开发团队希望从MIDAS开始，企业开始留意OSX系统端点的常见攻击模式。 五、Secureheaders Secureheaders是Twitter送给web开发者的一份大礼，作为一款web安全开发工具，Secureheaders能够自动实施安 全相关的header规则，包括内容安全政策（CSP），防止XSS、HSTS等攻击，防止火绵羊（Firesheep）攻击以及XFO点击劫持等。 六、Google Rapid Response GRR（Google Rapid Response）是Google开发的一个时间响应框架，支持进行远程实时取证。Google将GRR以开源工具的方式与安全界分享，可以作为FireEye/Mandiant 的MIR事件响应平台的替代产品。 七、Scumblr和Sketchy Scumblr和Sketchy是Netflix今年夏天同时发布的两款web应用，可以帮助安全团队监控和记录社交媒体和网络聊天中的安全威胁和攻击。 八、Conceal Conceal是面向Android平台的一组简单的Java API，能够对SD卡等公共存储设备中的大文件进行快速加密和认证。Conceal由Facebook设计，开发者可利用Conceal开发出能适用于老版本Android的内存和处理器开销较低的加密算法。 九、Rappor RAPPOR(Randomized Aggregatable Privacy-Preserving Ordinal Response )是Google上月才发布的隐私工具，能够从终端用户软件采集众包统计数据，同时又不侵犯用户隐私。 十、Moloch Moloch由AOL的技术团队开发，是一个网络流量分析取证工具，能够大规模抓取IPv4数据包，进行索引并存储，可通过一个简单的web界面浏览、搜索和输出所有PCAP数据。 稿源：安全牛 FROM:http://www.oschina.net/news/57334/10-opensource-security-tools
View Details这是一次在 defrag 2014的演讲。 这是经过长时间地多次技术变革后的（多个）技术优势之一。你看到了实际上突破。如果你只是看到了其中的一部分，很难正确推断。你要么短期有进展，要么落后很远。令人惊讶的不是事物变化的速度，而是一点一滴长期工程实践的突破。这是史端乔交换机，一个自动连接电话线路设备，在1891年发明的。 1951年，正是转向数字交换技术之时，一个典型的集中式交换中心基本上还是维多利亚时期的技术的放大版。每个转接过来的电话都有自己单独的strowger交换机。 当时来看，这已经是最牛逼的技术。当然我们看来，这只不过是当时世界上最大的蒸汽朋克(Steampunk，背景设在19世纪的科幻小说)风格的装置艺术(art installations)。 对此感到优越感可能是不对的。虽然集成电路(integrated circuit)已经面世65年了，仍然有数亿计的这种设备嗡嗡咔咔地运行着。直到现在，我们才真正地处在完全电子计算(solid-state computing, solid-state与机械相对，指基于半导体的)的转折点。 最令人兴奋的技术转变，一个是新的模型成为可行，另一个是旧的限制不再存在。在我们的工业界，这两种类型的转变都在上演。 分布式计算(distributed computing)现在是贯穿整个软件栈的主导性的编程模型。所谓的中央处理单元(central processing unit)不再是中心化的，甚至都不是一个单元了。它仅仅算是数据之山(a mountain of data)上爬行的一群虫子(Bugs)中的一个。数据库是最后的堡垒。 同时，内存与硬盘存储间的延迟正在变得无关紧要。30年来，数据库性能的主要关心点，在于访问内存与硬盘存储上的随机数据的巨大差别。既然现在我们可以把数据全部放在内存中，这些烦恼统统不用考虑了。当然不是这么简单，你不能用一个B树，mmap一下，然后就能搞定。在完全基于内存的设计方案推出之前还有很多相关的东西要解决。 这两种新趋势产生了完全崭新的方式来思考、设计、构建应用。现在我们来谈下我们怎么达到，我们怎么做的，未来给我们的启示。 (史前时代，从下文看应该是2000年前，用户被描述成恐龙，作者的小幽默) 那时候，架构图里的每个组件都有一个确定的描述与之相关。每个东西都是一个单独的功能： “the” database(数据库)， “the” web server(服务器), characters in a one-room drama(用户). 顺便提一下，这就是“the cloud”这个词的来源。一个轻软/毛茸茸的云是WAN的标准符号，而WAN的细节我们完全不用操心。 (2000年，负载均衡解决一切) 容易实现的分布式计算得到了主流的亲睐。多个完全相同的应用程序服务器藏在一个负载均衡器(load balancer)之后，这个均衡器把负载差不多平均地分配到应用程序服务器上去。只负载均衡那些架构中状态无关的部分回避了很多哲学上的问题(理论上的情况？)。当系统扩展时，这些组件从侧翼包抄，最后包围了“the” database。我们告诉自己，给数据库换上更快的磁盘、更快的CPU很正常，毕竟还是只需要一台机器。硬件提供商很高兴地赚着我们的钱。 (2002：备份解决一切) 最后，数据库备份成为合情合理的，加了一个热备份数据库(hot spare database)后，我们的良心得到些许宽慰。然后我们告诉自己，不会再有任何故障了。当然，这种正确性只存在了几分钟。 当然，热备份经常是空闲的(sitting idle)。一旦商业分析员意识到，他们可以在不触及生产数据的情况下，也能对生产数据进行大规模查询，那么所谓的热备份也几乎跟生产数据一样开始忙碌并且至关重要了。我们又告诉自己，在紧急情况下把热备份暂时拿出来也还好。但这就如同说，我们完全没必要带备胎，因为我们可以从其他车上偷一个过来！ (2004：memcached/缓存解决一切) 然后，Brad Fitzpatrick发布了memcached，一个可以在内存中缓存数据的守护程序(因此叫memcached, memory cached)。这是个简化版的分布式哈希表，而且确实非常实用，因而之后就在学术界流行起来。它拥有很多特性：备份(a form of replication?)，水平分区，负载均衡，简单数学运算等。 我们再次告诉自己，既然大部分的负载都是读，我们为什么还要催促数据库从磁盘一遍一遍做相同的查询？你只需要一组内存很大的小规模(small-calibre,小口径)服务器，当然硬件提供商也高兴地赚我们(买内存)的钱。 也许需要你写些缓存失效(cache invalidation)代码，这听起来不难，对吧。 (2004：memcached解决一切，添加了缓存失效) 确如其声称，memcached的方案使我们受益很长时间。它把硬盘的随机IO操作替换为内存的随机IO操作。尽管如此，那台数据库机器还是越来越大，越来越忙。我们意识到，缓存的内存开销至少会跟工作集一样大(不然就是无效了)，再加上让人不能忍的缓存持久化。我们告诉自己，这就是网络级规模(web scale？)的开销。 (2006：水平分区/切分解决一切) 更令人担心的是应用越来越复杂，越来越聊天化(chattier，可能聊天程序对数据库写的次数很多)。几乎每次都会进行多次数据库写操作。现在，写，而不是读，成为了瓶颈。这时我们才最终认真对待数据库切分。Facebook最初是根据university字段来切分其用户数据，然后做成了"哈佛数据库(The Harvard Database)"，并且维持了很长一段时间。Flickr是另一个好例子。他们使用PHP手动建立了一个切分系统，这个系统使用用户ID的哈希值来切分数据库，跟memcached根据key来切分很像。在技术交流会上，他们透露，不得不对数据表去规范化(denormalize)，以及对一些对象(比如评论、消息、喜欢)进行两次写(doule-write)。 要解决无限伸缩(infinite scaling)总要付出点代价，对吧。 (2008：NoSQL解决一切) 手动切分关系型数据库的问题是，你的关系型数据库已经没了。切分API实际上成为你的查询语言了。你对操作的头疼还没好，而修改一组模式(schema)更加痛苦。 这就需要大家深呼一口气，列出大家选用的SQL实现的所有不足和瑕疵，然后因此责怪SQL。一波潮人似的NoSQL，难民似的XML数据库出现了，并且都作出了根本办不到的承诺。它们提供了自动切分，灵活的模式，一些冗余，…，一开始也就这么多。但是总比自己写要好多了。 你知道，“不用自己写”成为主要卖点的东西总是令人绝望。 (2010：Map/Reduce解决一切) 转移到NoSQL并不比使用手动切分差，因为我们已经放弃了使用常用的客户端工具控制和分析数据的希望。但这没好多少。之前由商业人员(business folks)编写的SQL查询变成了开发人员维护的报表代码。 还记得用于备份和分析的热备份数据库吧？现在它变身为Hadoop filestores以及上层的Hive查询而卷土重来了。既然奏效，商业人员再也不来烦我们了。但一个大问题是，这些系统的操作复杂性。就像航天飞机一样，它们是作为可靠且几乎不用维护的产品出售的，但是最后还是需要大量的手动操作。另一个大问题是，数据的存入和取出：花费一整天的时间已经相当不错了。第三个大问题是IO同时成为网络和磁盘的瓶颈。我们告诉自己，这就是从大数据(big data)毕业的代价。 不管怎样，Google就是这样做的，对吧。 (2012：NoSQL再次解决一切) 随着一些NoSQL数据库的逐渐成熟，它们的API发生了诡异的变化：它们开始长得像SQL一样。这时因为SQL是关系型集合理论(relational set theory)的相当直接的实现，而数学不是那么好愚弄的。 我重述下Paul Graham对Lisp那难以忍受、并自鸣得意的评论：一旦你添加了group by, filter, join，你也不能声称发明了新的查询语言，因为这仅仅算是SQL的一个新方言。而且语法很差，还没有优化器。 由于我们绕过了SQL，大部分系统都缺少了一些很重要的东西，比如存储引擎、查询优化器，而这些都是基于关系型集合理论设计的。拖延到后期去实现导致了严重的性能问题。即使对解决了性能问题的那些(或者通过停驻在内存中来掩盖此问题)，也缺少了其他东西，如合适的备份。 我知道一个非常成功的互联网初创公司(你肯定也听过)使用了4个(!!)不同的NoSQL系统来解决问题。 (2014：现在需要什么来解决一切？) 现在已经相当明显，我们不会回到单数据库以及10毫秒一次的随机定位(10-million-nanosecond random […]
View Details非在线式UPS也称后备式UPS 平时处于蓄电池充电状态，在停电时逆变器紧急切换到工作状态，将电池提供的直流电转变为稳定的交流电输出，因此后备式UPS也被称为离线式UPS。后备式UPS电源的优点是：运行效率高、噪音低、价格相对便宜，主要适用于市电波动不大，对供电质量要求不高的场合，比较适合家庭使用。然而这种UPS存在一个切换时间问题，因此不适合用在关键性的供电不能中断的场所。不过实际上这个切换时间很短，一般介于2至10毫秒，而计算机本身的交换式电源供应器在断电时应可维持10毫秒左右，所以个人计算机系统一般不会因为这个切换时间而出现问题。后备式UPS一般只能持续供电几分钟到几十分钟，主要是让您有时间备份数据，并尽快结束手头工作，其价格也较低。对不是太关键的电脑应用，比如个人家庭用户，就可配小功率的后备式UPS。 在线式UPS 在线式UPS在工作时，首先将市电转化为直流电给UPS电池充电，同时逆变器（见提示）将此直流电逆变为交流电为负载供电，由于市电经过了交流到直流、再到交流的转换过程，所以市电中原有的干扰和脉冲电压成分已经过滤得非常干净，因此，由在线式UPS逆变出来的电压很稳定。由于逆变电路始终在工作，所以当停电时，UPS能马上将其存储的电能通过逆变器转化为交流电对负载进行供电，从而达到了输出电压零中断的切换目标。另外广告里提到的双变换就是指这款UPS的输出电压经过了两次交直流的互相转换过程。而高频则表示UPS内部工作在高频环境下。高频UPS的好处是体积小，重量轻，工作效率高，其坏处是抗过载抗冲击能力差。
View Details介绍 当一个 Webform 开发者转做 MVC 开发的时候, 他会发现, 许多自己喜欢的东东不见了. 没有代码隐藏模型(behind code), 没有 view state, 没有页面生命周期(page life cycle), 没有服务端控件(server control). 你可以看这篇文章, 里头有讲 MVC 比 ASP.NET Webform少了哪些东西. 没有了这些易用的服务端控件, 相信许多人都会伤心欲绝. 最令人怀念的, 恐怕要属 gridview / datagrid 控件. 作为一个 ASP.NET Webform 开发者, 我能理解, 这种将 GridView 控件拖放到 form 里头, 然后给它绑定数据, 一会的功夫, 就能看到数据在表格中显示的开发过程, 有多爽, 多让人着迷. MVC 用 “WebGrid” 类代替 GridView . 这是个类, 再说一次, 这是个类. 别指望它能像, 有可视化快速开发工具支持的 gridview / data grid 控件那么好用. 不过要比用 HTML 的表格好的多, 起码省时间. 如果你想知道, 我们为什么不做可视化快速开发工具支持 MVC, 读下这篇文章 ASP.NET Webform 对比 ASP.NET MVC. 本文通过六个重要技巧, 教你如何更有效的使用 WebGrid。 一个简单的 MVC WebGrid 例子 “WebGrid” 的用途是, 显示集合(collection )中的数据. 集合可能是强类型列表(strong typed list), 也可能是泛型, 或其他类型. 我们先来看一个简单的例子. 这个例子将强类型对象添加到一个集合中, 然后用 “WebGrid” 显示出来. 下列代码创建一个名叫 “Custs” 列表, 然后把 “Customer” 类的 对象加进去. ? 1 2 […]
View DetailsEditor Demo Download Editor 是一个排版驱动的主题，内容在右侧展示，非常漂亮，支持移动设备浏览。 Daily Theme Demo Download 响应式布局可用于博客、相册。 Illustratr Download Download 一个微型的相册主题 Fukasawa Demo Demo Fukasawa 是适合摄影人和收藏夹使用的 WP 主题 Espied Demo Download A portfolio theme for designers and photographers. Great for showing off your image oriented projects to the world. Cody Demo Download Simple WordPress Theme for blogs and personal websites. Sketch Demo Download 整洁、响应式的组，提供网站 Logo 自定义，特色是内容滑块。 PURE WORDPRESS THEME Download Pho – Minimalist, Masonry WordPress Theme Download Pho WordPress 是一个微型的博客主题，提供漂亮的排版，大量的空间可用于展示漂亮的大图片 Hoffman Demo Download Hoffman 适合用来做博客主题 Moments Demo Download 响应式主题，适合个人博客 CleanPort Lite WordPress Theme Demo Download CleanPort 是一个平面设计的风格。 Rams Demo Download Time Demo Download Ravel Demo Download Bridging […]
View Details网页上漂亮的消息提醒不仅耳目一神，关键是引起用户的主题，实实在在起到提醒而不扰民的用途。本文向你推荐 25 个漂亮的 jQuery 消息提醒插件，你值得拥有。 偷个懒不翻译了，大家点击图片可直达官网。 1. jQuery Toastmessage jquery-toastmessage-plugin is a JQuery plugin which provides android-like notification messages. The toasted messages arriving on the screen in a seamless and natural way. 2. jQuery Notification Menu A jQuery plugin to add notification bubbles and a notification list to any menu. 3. Noty noty 是一个很有用的 jQuery 插件，用于创建 alert, success, error and confirmation 信息提示框，替换浏览器标准的对话框。每个提醒都是添加队列并进行显示的。 4. Notify Notify! is a jQuery Notification Plugin which adds simple notifications bars that you can use on your website and application to assist users while […]
View Details对于初学者来说，小型开源项目更容易理解和学习，那么目前有哪些值得学习的小型开源项目？本文收集整理了知乎上网友推荐的一些不错的小型项目，代码基本都在5000行以内，感兴趣的朋友可以研究下~ SeaJS Sea.js是一个遵循CommonJS规范的JavaScript模块加载框架，可以实现JavaScript的模块化开发及加载机制。Sea.js 追求简单、自然的代码书写和组织方式，代码非常精简。 Koa Koa 是下一代的 Node.js 的 Web 框架。由 Express 团队设计。旨在提供一个更小型、更富有表现力、更可靠的 Web 应用和 API 的开发基础。 pssh pssh 提供了并行版本的 OpenSSH 工具，特别适合用来控制有大量机器需要连接的情况，包括并行版本的 ssh、scp、rsync 和 kill 命令。该项目是Python写的，代码清晰而简短，数据结构定义的很清楚，看了之后你会称赞的。 grep-at-point 在写代码的时候，有时候会需要查看某个函数/类/变量在哪些地方被使用过。该项目用emacs lisp语言写成，可实现在项目目录下，所有指定扩展名的文件中，搜索当前光标所在的单词。 compile-make 该项目可实现emacs中一键编译的需求。在项目目录下寻找Makefile文件，并执行make命令进行编译。 语言：emacs lisp ；代码行数：19。 sigslot 很精简的 signal slot的实现，跨平台。这个源码有2000多行，但是一大半是为了模板适配不同个数的参数的代码，干货不足1000行。 UCOS uC/OS II(Micro Control Operation System Two)是一个可以基于 ROM运行的、可裁减的、抢占式、实时多任务内核，具有高度可移植性，特别适合于微处理器和控制器，是和很多商业操作系统性能相当的实时操作系统(RTOS)。 SQLite SQLite是遵守ACID的关联式数据库管理系统，它包含在一个相对小的C库中。它是D.RichardHipp建立的公有领域项目。SQLite亦可以作为桌面数据库使用。 thttpd thttpd 是一个小型的、简单的、可移植的、快速以及安全的HTTP服务器。 Boa Webserver boa是一个小型的web服务器，可以用于多种平台，在嵌入式中比较常见。 C4 4个函数实现的c编译器，大约500行。基本上已经比较完备了，可以自己编译自己。 GLib GLib 是一个包含很多有用的 C 程序的开发包，例如树、哈希、列表等。GLib 之前是属于 GTK 工具包的一部分，现在独立出来成为单独项目。 tj/co 不到三百行，用于改善 node 异步回调语法。 shadowsocks shadowsocks 是一个基于 python 的轻量级 socks 代理软件（谁用谁知道）。 aosabook 这是一本牛书aosabook的续集，500 Lines or Less的源码。里面每一章的代码不超过500行，实现了web服务器、爬虫、OCR等等“大型系统”，每一章由不同领域的大牛完成。看看作者列表，可以说是软件领域的名人堂。 from:http://www.techug.com/15-simple-opensource-projects
View Details大概大家读知道id,class以及descendant选择器，并且整体都在使用它们，那么你正在错误拥有更大级别的灵活性的选择方式。这篇文章里面提到的大部分选择器都是在CSS3标准下的，所以它们只能在相应最新版本的浏览器中才能生效，你完全应该把这些都记在你聪明的脑袋里面。 1. * ? 1 2 3 4 * { margin: 0; padding: 0; } 在我们看比较高级的选择器之前，应该认识下这个众所周知的清空选择器。星号呢会将页面上所有每一个元素都选到。许多开发者都用它来清空margin和padding。当然你在练习的时候使用这个没问题，但是我不建议在生产环境中使用它。它会给浏览器凭添许多不必要的东西。 *也可以用来选择某元素的所有子元素。 ? 1 2 3 #container * { border: 1px solid black; } 它会选中#container下的所有元素。当然，我还是不建议你去使用它，如果可能的话。 DEMO 兼容性 IE6+ Firefox Chrome Safari Opera 2. #X ? 1 2 3 4 #container { width: 960px; margin: auto; } 在选择器中使用#可以用id来定位某个元素。大家通常都会这么使用，然后使用的时候大家还是得相当小心的。 需要问自己一下：我是不是必须要给这个元素来赋值个id来定位它呢？ id选择器是很严格的并且你没办法去复用它。如果可能的话，首先试试用标签名字，HTML5中的新元素，或者是伪类。 DEMO 兼容性 IE6+ Firefox Chrome Safari Opera 3. .X ? 1 2 3 .error { color: red; } 这是个class选择器。它跟id选择器不同的是，它可以定位多个元素。当你想对多个元素进行样式修饰的时候就可以使用class。当你要对某个特定的元素进行修饰那就是用id来定位它。 DEMO 兼容性 IE6+ Firefox Chrome Safari Opera 4. X Y ? 1 2 3 li a { text-decoration: none; } 下一个常用的就是descendant选择器。如果你想更加具体的去定位元素，你可以使用它。例如，假如，你不需要定位所有的a元素，而只需要定位li标签下的a标签？这时候你就需要使用descendant选择器了。 专家提示：如果你的选择器像X Y Z A B.error这样，那你就错了。时刻都提醒自己，是否真的需要对那么多元素修饰。 DEMO 兼容性 IE6+ Firefox Chrome […]
View Details文章出处：池建强 问：池老师，我是个不爱互动的人，但是您所有的文章我都看了，非常感谢您的引导，我入手了人生第一台 MBP。现在问题来了，但是找不到更合适的人解答，只能求助于您了，如果您有时间的话。问题是这样的：我有个32bit unix file（开启一个服务进程），在 Mac 上执行时错误提示是：exec format error，但是在 Linux 服务器却可以执行，为何？Mac 上有可以运行的方案吗？期待您的回复，不胜感激。 答：Linux 和 OS X 是不同的操作系统，可以尝试在 OS X 里重新编译这个文件。 问：非常感谢！如果没有文件源码是不是就只能认命了？ 答：可以在 Mac 上装 Docker，然后对服务进行端口映射就可以了。 答：茅塞顿开。谢池老师。 以上是我和一位读者的对话，这位小伙子在拿到答案之后像一缕烟尘一样消失无踪，之后再也没有出现过。 在微信上加了很多 MacTalk 的读者之后，经常会收到一些奇奇怪怪的问题，关于职场、关于选择、关于朋友、关于 Mac、关于技术等等，不一而足。但是我能回答的却很少。问题不好没法回答，问题太复杂没法回答，问题领域超出我的认知也没法回答，耗时太长的问题我也没 时间回答，实在是惭愧的紧。好在偶尔也能够帮助一些小伙伴解决一些实际问题，心理上略感安慰，比如上面这个问题。 把这段程序员之间的对话翻译一下，大致是这么个故事： 一 位读者有一个32位的 Unix 可执行文件，可以在某种版本的 Linux 服务器上正常运行，运行这个文件作用就是起个进程，开端口，然后与其他程序进行交互。但是这个文件拿到 Mac 上完全没办法运行。就在他趴在 Mac 上愁肠百结万念俱灰的时候，突然想到了「池老师」。不就是这个老家伙把 Mac 夸的像一朵玫瑰一样，让每个程序员都去采摘么？现在扎手了，你不管谁管？于是他给我发来消息，意思就是管也得管，不管也得管，您看着办。 我 拿到问题一看，不难。Linux 和 OS X 虽然师出同门，都是从老前辈 Unix 那儿毕业的，但是后来毕竟各练各的，在 Linux 编译好的程序不可能在 OS X 上用，但是在 OS X 上重新编译一下可能就没事了。我把这个想法告诉了这位程序员，得到的反馈是：对不起哥，没有源代码！ 我被这个冷酷的回复震惊了，立刻意识到 刚才的想法并不是最优解决方案，因为在重新编译的过程中，各种包的依赖关系和编译错误足以让你焦头烂额，我随即提供了 B 计划：在 OS X 上安装 Docker，轻量级的容器 Docker 可以运行各种版本的 Linux，把文件扔到 Docker 里，然后通过主机和 Docker 之间的端口映射即可轻松解决这一问题。 虽然这里面会涉及很多技术细节，但是方向是没有问题的，所以这位程序员立刻表示「茅塞顿开」，然后「biu 」的一声就在屏幕对面消失了，没有留给我说「不客气」的机会。 这个问题装个 Linux 虚拟机也可以解决，但是虚拟机过于耗费资源，而且不如 Docker 灵活，所以不是最佳解决方案。Docker 是。 做 为一个程序员，我们除了要掌握多门程序语言和多种数据库，了解前端技术、后端技术，通晓网络七层架构，知道 TCP/IP三次握手和四次挥手，编写漂亮的代码，设计优美的架构……之外，我们还要解决研发、程序运行和产品上线过程中遇到的各种问题，而且被要求以最 小的代价来解决问题……我们容易吗？ […]
View Details2014年11月23日源创会年度盛典（北京站）正在报名 每次发这类文章时，用户集中反馈的问题包括： 好像以前发过 —— 答：标题类似，内容不同 怎么只有名称和图片，没有介绍 —— 答：介绍千篇一律，没什么特别的，图片更加直接，当然了最主要是为了偷懒，哈哈 怎么那么多前端的内容？ —— 答：多不好吗？ 1. MenuItems 2. Sidr 3. Material Menu 4. Responsive Tabbed Navigation 5. PGW Menu 6. jQuery Slimmenu 7. jQuery Sliding Menu 8. Responsive Tabs 9. Mmenu 10. Flex Nav 11. Responsive Full Width Tabs 12. Fixed Nav 13. Daisy Nav 14. Navgoco 15. Naver 16. Smart Menus 17. jQuery Fluid Content Scroller 18. Menu-aim 19. HorizontalNav 20. SlickNav 21. TinyNav.js 22. Menutron 23. Flaunt.js 24. jPanel Menu 25. Repsonsive Toggle Menu via codegeekz from:http://www.oschina.net/news/56988/responsive-jquery-navigation-plugins
View Details