newghost (myown)

收录了 2014 年 RubyConf China 的部分 PPT

newghost — Mon, 27 Apr 2015 13:26:36 +0800

收录了 RubyConf China 2014 年的部分 PPT，不是很全，目前只找到这些，有没有同学可以提供其他演讲的 PPT？

50 分钟用 RubyMotion 开发 DiggMotion by 张泽涛

Rails Services - Create micro services with (or without) Rails by 罗昕

Ruby 的快与慢 by 谢文威

从数据库记录到 ActiveRecord 对象 by 陈恺

另外这次大会的录音或视频也没有找到，有没有同学可以分享一下？

做了一个 Side Prject；分享制作 PPT 的希望大家帮忙测试一下，顺便改个名

newghost — Wed, 25 Mar 2015 09:51:55 +0800

http://airjd.com/

是一个 PPT 在线设计制做分享平台（）可带录音），目前收录了一些在公开场合发表的 PPT 和录音；

这两天新购了两台最便宜的云服务器（一台数据主站，一台静态资源），刚刚布署完成，已经发现不少问题。

目前叫云焦点，发现这个名字可能不太好，以后有可能被会 yunjd 截流，大家有没有好的名字推荐？

十分感谢。欢迎拍砖。

Chrome V8 将实现 ES6 的类语法（class）

newghost — Tue, 19 Aug 2014 11:14:57 +0800

mplement ES6 classes including:

class declaration syntax
enchancements to objects literal syntax
‘super’ keyword and Function.prototype.toMethod

The implementation will proceed in V8 under --harmony-classes flag.

Owners: Adam Klein (adamk@chromium.org), Erik Arvidsson (arv@chromium.org), Dmitry Lomov (dslomov@chromium.org)

TC39 acceptance

Classes (in the form of compromise “maximally-minimal” classes) has been a part of ES6 for more than a year now. The complete spec has been in ES6 specification draft for quite a while.

At a July 2014 TC39 meeting some significant changes to instantiation semantics for classes were proposed, so the specification may still change in certain aspects.

However implementation of classes is a significant effort for V8, and critically important for Javascript community. It is critical that TC39 receives deep implementation feedback on the feature earlier than later. To mitigate spec changes impact, two of the owners (Erik & Dmitry) are directly involved with ‘instantiation reform’ proposal on TC39. Therefore we believe now is the right time to proceed with ES6 classes’ implementation.

Interest from other vendors

None of browser vendors currently ship ES6 classes, even though both Firefox and IE stated the intent of doing so.

Technical considerations

Design document:

https://docs.google.com/a/chromium.org/document/d/1UaIt5SeiM-DI8tSOhtM39eSOpjkDiv2UxP9eFK35Rno/

Cheers, Adam, Erik, Dmitry

翻译 http://ourjs.com/detail/53f1af7ba9fd2b242d000002

编程女孩儿：谁说女生不适合写代码!

newghost — Tue, 07 Jan 2014 13:34:53 +0800

http://ourjs.com/detail/52caa4a491c7ccb71400000e

不用 HTML/CSS，JS 就够了

newghost — Tue, 22 Oct 2013 09:48:01 +0800

有人在 Github 上面建了一个很有意思的项目。你只需要 JS 就可以创建网页。原理其实很简单，创建一些“html 函数”，如：p, div, ul, li 来创建你的网页，而且可以和 backbone 无缝结合，下面有个例子：

h1('HTML Creation');

p('Tags are functions.')

p('Attributes are objects...', {
  style:{fontStyle:'italic'}
})

ul(function(){
  li('Nest');
  li('with');
  li('functions!');
});

你也用 JS 来设置些 CSS

h1('CSS Creation')

css({
  '.red':{color:'#e00'},
  '.big':{fontSize:'25px'}
});

div({'class':'red'}, 'This is red');
div({c:'big'}, 'This is big');
div({c:'big red'}, 'This is both');

Github 地址： https://github.com/ojjs/oj/

转自： OurJS

Groupon 抛弃 Rails

newghost — Fri, 11 Oct 2013 09:25:22 +0800

知名团购网站 Groupon 近日在官网宣布，目前 Groupon 已经完成了从 Ruby on Rails 向 Node.js 的迁移过程，这一过程历时 1 年之久。迁移后，Groupon 将成为全球最大的 Node.js 部署产品之一。

Groupon 工程师团队表示，迁移后，整体响应时间继续减少。Groupon 会在接下来的几个月中，逐步发布驱动其 Node.js 平台的相关库。

Twitter 在 2008 年将其业务后端代码从 Rails 迁移到了 Scala，而 Groupon 如今也抛弃了 Rails 架构，其原因大致相同——在大型系统的可扩展性和性能上，Rails 显得捉襟见肘。

在过去一年半的时间中，Groupon 的后端服务已经全面过渡到了 SOA（面向服务架构），并且在前端也应用了这这种模式。这样，每个团队可以只拥有他们所负责的服务页面或应用，而不是有一个大型的应用程序，共享的逻辑已经被移到了服务和库中，以便团队只需专注于构建自己所负责的功能。

Geekon: I-Tier Today is exciting: we’ve completed a year-long project to move Groupon’s web traffic from our legacy Ruby on Rails application to Node.js. We’ve been working hard on this transition and have learned a lot along the way. Groupon will be one of the largest production deploys of Node.js worldwide. We’re currently serving ~50,000rpm and our overall response times have dropped dramatically. Over the next few months we’ll be releasing the libraries we used to power our new Node.js platform and we will be blogging stories about this intense transition.

Some history: Groupon started as a monolithic Ruby on Rails app. Over the last year and a half we’ve been transitioning to a service oriented architecture (SOA) for all of our back-end services. We applied the SOA design pattern to our front-end as well. Instead of having one large web application each internal team can own their own application that only serves the pages for which that team is responsible. Shared logic has moved into services and libraries so teams only need to focus on building the features that their teams own. Groupon is doing cutting edge work in mobile, with nearly 50% of our North American transactions completed on a mobile device in June. Our mobile applications use a JSON API, and our web applications now use the same API, allowing us to focus on maintaining a single contract for all of our consumer web data.

转自： http://ourjs.com/detail/525750fd0a44ef3c03000013

NodeJS 即将超越 Ruby，正在悄悄改变开源面貌

newghost — Sat, 21 Sep 2013 20:35:26 +0800

截至 2013-09-11 日：现在你打开 https://npmjs.org/ 你会看到基于 nodejs 的包已经超过 4W 了 , 基于 NodeJS 的模块数据增长惊人，在过去的5个时间里，包的数量增加了了 1.4W个，增长接近 50%, 已经接近 Ruby。

关注下 pypi，npm, rubygems 社区上的开源包的发布，从 python（1991），ruby(1995)，和 node.js(2009) 发布日期开始，这些社区上每年发布的开源包以下面的比例增长： python: 29,720 包/22 年 = 1351 包每年 ruby: 54,385 包/18 年 = 3022 包每年 node.js: 26,966 包/4 年 = 6742 包每年

这种 node.js 开源包惊人的增长现象，怎么会成为可能？

不内置电池

如果，你曾经需要一个 Python 的客户端库，你可能问你自己"我是要用 urllib, urllib2, 还是 httplib 呢？”，就像其他所有人 . 好吧，答案可能是你应该使用 requests. 它是一个很简单，直观的 HTTP 客户端库，很好的封装了很多标准库的陷阱和 bug，但很可惜的是它不像上面其他库一样是标准库。 Python 的“电池内置”策略在 90 年代中期绝对是正确的，这也是我很喜欢它的一个原因。在那个年代，没有现代化的包管理，查找和安装社区创建的库并不是很容易。现在，虽然，我认为这样效率并不高，但当时社区的开发者很少想去和标准库竞争，所以人们很少尝试着去写出提升标准库的改良库。

开发者也很不喜欢在他们的项目中使用非标准库。我听到过很多人隐忍着使用次等的标准库只是为了“不依赖外部库”。但在现在，大容量存储器如此便宜，又拥有现代化的包管理工具，人们不应该再采用“不依赖外部库”的策略. 相反，node.js 核心开发者实际上想尽可能的最小化标准库。他们已经多次从标准库里移除的特性，而鼓励大家使用社区实现的版本。这样的方法允许最大的多样性，让最好的实现版本胜出（当然，当有人实现出来一个更好的版本就会再次替换!）。想像一下，这样对标准库维护者也是多么自由啊。node.js 标准库是相当小，这样可以释放核心开发者更专注在核心的部件上。

小就是美 (The Tiny Module Aesthetic)

这种方法也并不是多特别，起码在 node.js 社区。这个社区被一群开发者领导，其中每个开发者都发布了几百个包。我从前都不相信有这种可能性. 当然，我们不可能限制其他语言也这么做，所以，我更相信是社区文化起了决定性的影响。像 Ruby on Rails 这种大单体框架并没有侵占 node.js 社区的份额，我想部分原因在于"小模块更美"(“tiny module aesthetic”) 这种思想，而且这个思想也更适合 node.js。对我来说，像 Rails 这种大框架没有一个清晰的边界，所以他们倾向于无限的扩张从而包含一个应用可能需要的所有东西。这导致人们坚信 Rails 是所有问题的最好解决方案，从而阻碍了 Ruby 社区在 web 应用领域的变革。

这种小模块更美的思想也导致了一个高度重用的生态系统。当一个包只做必要的事情时，它非常容易理解和更容易集成到其他应用。相反的，大单体框架趋向于出现在大量的终端用户应用中，而很少被其他包依赖。这对我来说感到很遗憾，因为那些软件那么优秀，却那么难重用。

git 和 github.com 单种栽培 (monoculture)

老实说，对我来说软件开发过程中，很少有东西比版本控制让我更厌烦的。而且我发现 git 对我来说有点太复杂了。但是我还没听说过那个 node.js 开发者不用 git 的，这种单种栽培有非常大的价值。这意味着他们使用同一种通用语言，当他们想为其他人的项目贡献时，没有任何障碍。 Github.com 在降低开发者相互贡献的障碍时有同样的效果。我很少看见 node.js 项目不在 github 上。这意味着如果我想做出贡献，我可以马上知道去哪里找到源代码。 github 单种栽培的优缺点远远超过这些，但要完全说明它们，恐怕要开单独的一个文章来说明。

自由的许可 (Permissive Licensing)

Node.js 包倾向于使用非常自由的许可，例如 MIT 和 BSD 许可。实际上，使用npm init创建一个包时，缺省的许可是 BSD. 我想这是新时代的另一个标志。很少的人会在意别人创建新分支 (forks) 却不回馈 (contribute back)。而且人们如果不回馈也收获甚少，因为要花精力维护自己的分支。这很重要，因为没有人想去处理牵涉到法律后果和更多法律责任的事务。像 GPL 这样的许可，因为这个原因，最终减缓了软件重用。

http://ourjs.com/detail/52303fce1b89c7b703000005