• 2014-03-06

    开源的比特币交易记录项目Btcplex采用SSDB数据库

    Views: 19311 | 2 Comments

    由法国人 tsileo 开发的比特币交易记录查看软件 Btcplex 采用国人开发的 SSDB NoSQL 数据库作为持久化存储服务. Btplex 是用 Go 语言开发的, 并在 github 上开源. 你可以用它来搜索和查看比特币的交易记录(块链, Block chain).

    比特币块链是整个比特币网络依赖的一个公开共享的交易记录。所有已确认的交易均毫无例外地包含在块链中 ... 由于块链的存在,比特币的交易记录得以很明确地表示!

    Btcplex 的环境要求:

    • A bitcoind instance (you can build bitcoind in Disable-wallet mode)
    • Go >=1.2
    • Redis 2.6+
    • SSDB
    • LevelDB
    • 150+GB disk space / 4+GB RAM

    SSDB 是由国人开发的高性能 NoSQL 数据库, 支持 Redis 的丰富的数据结构, 并且兼容 Redis 的客户端和 API. SSDB 在国内外的知名互联网企业和创业团队中得到广泛应用, 用于取代 Redis.

    Posted by ideawu at 2014-03-06 23:00:52
  • 2014-03-06

    谈谈程序员试用期薪水打折的问题

    Views: 7181 | 2 Comments

    似乎业界有个约定, 试用期的员工只能拿到 90% 的工资. 比如我当初毕业加入某公司时, 也是拿了6个月的 90% 工资, 当时并没有太多疑问. 后来我加入另一家公司, 试用期拿的是 100% 的工资. 其实试用期薪水打折, 不仅对员工不友好, 其实对企业没有任何好处.

    首先, 试用期薪水打折对员工是不利的. 其次, 试用期薪水打折对企业没有任何金钱和员工动力方面收益.

    试用期对于员工和企业来说, 都是相互考察的阶段, 一旦任何一方认为对方不合适, 是可以立即终止合同而不必付出金钱补偿的. 在试用期的员工, 肯定会努力工作以证明自己, 虽然员工刚接触新工作会有工作效率方面的问题, 但这个成本应该由企业来承担.

    试用期是有可能员工效率不及未来100%的风险成本, 但是为什么我认为应该由企业来承担这部分的成本呢? 因为试用期的员工已经承担了可能因试用期无法通过被合法辞退而失业的风险, 这个风险已经足够大了. 所以, 好的企业应该为员工承担这份合作风险, 而不是还拼命从试用期薪水打折方面抠一点小钱, 这相当于与民争食.

    所以, 试用期应该是员工和企业 100%+ 合作的阶段, 而不是双方的付出打折的阶段. 试用期的员工的工作热情不会打折, 企业给员工的薪水也不应该打折!

    Posted by ideawu at 22:26:53
  • 2014-02-17

    TCP网络协议及其思想的应用

    Views: 12160 | 3 Comments

    大部分程序员都听说过 TCP/IP 网络协议, 或者都写过 TCP socket 网络的程序, 甚至还学过 TCP 原理, 少部分看过 TCP 协议的某一个实现版本. 不过, 真正掌握 TCP 原理及思想的人, 我觉得不多. 只有理解了 TCP 原理及实现, 并且把它背后的思想和技术活学活用到其它的领域, 那才算是真正掌握了 TCP.

    TCP 协议的目的, 是在不可靠传输的 IP 层之上建立一套可靠传输的机制, 它所应用的技术, 如滑动窗口, 慢启动, 指数退避, Negal 算法等, 都是优化目的.

    Continue reading »

    Posted by ideawu at 2014-02-17 23:33:17
  • 2014-01-15

    用 Markdown 来给开源项目写文档

    Views: 13515 | 2 Comments

    良好和专业的文档对于一个开源软件项目来说, 其重要程度和软件的功能不相上下. 项目有了良好的文档, 体现出专业程度, 用户便会放心试用软件, 从而成为真正的用户.

    对于一个开源软件项目来说, 文档一般是指 API 文档, 配置帮助文档, 用户手册(Manual), 教程(Tutorial), 设计思路等等. 那么, 用什么工具来编写文档呢? 其实, 不同项目使用的工具各不相同, 比较常用的工具是 Doxygen, Docbook. 这两个工具我都用过, 说实话, 我没掌握它们的精髓, 使用起来不是很爽.

    Doxygen 主要用来从代码注释中提取生成 API 文档, 但说实话, 默认的模板十分难看, 生成的文档不知所云, 比 Javadoc 生成的文档的清晰度差远了, 我无法理解它的文档组织结构的优点. Doxygen 也能生成 API 文档之外的其它类型的文档.

    我曾经用 Docbook 写过一个教程, 有点想写书, 是用 XML 写的, 生成的文档也是有章节的那种, 但不太适合用来编写以篇为单位的那种文档.

    最终, 我采用了 Markdown (格式和工具) 来给 SSDB 数据库项目编写文档, 并使用 bootstrap 来做界面美化. 以前我便使用 Markdown 格式来写了一些文章, 但 SSDB 的文档完全采用 Markdown 来编写, 是受了 beego 项目的启发. Beego 的项目文档, 是我见过了国内开源项目中最专业化和最美观的项目之一.

    Beego 采用 Markdown 格式编写文章, 然后用一个 Go 语言的工具实时生成 HTML 网页. 我的服务器还没有用 Go 语言, 所以找了一个 Python 的 Markdown 解析库(Python Markdown), 然后用 PHP 做了包装, 做成一个文档生成工具. 之所以使用 PHP, 是因为 PHP 本身是一个模板语言, 同时也有丰富的函数, 处理文本文件非常方便.

    最后做成的就是 ssdb-docs 这个 SSDB 数据库的文档项目. 大家如果感兴趣, 可以直接把这个 Markdown 文档工具拿来用, 也给自己的项目写文档. 用起来非常方便, 把你的 .md 文件放到一个目录, 就能一行命令解析并生成 HTML 文件.

    Posted by ideawu at 2014-01-15 00:06:52
  • 2013-12-21

    亚马逊AWS, Linode, 阿里云等云服务对比

    Views: 23336 | 2 Comments

    最近, 有消息称亚马逊云服务(AWS)要进入中国, 在中国建立 IDC. 一石激起千层浪, 国内云服务纷纷降价. 根据我使用和了解到的云服务, 我觉得有必要对比下各个厂商的云服务, 希望支大家有帮助.

    产品 CPU 内存 硬盘 带宽或月流量 价格(月)
    Amazon EC2 m3.xlarge 4 15GB 80GB SSD 1TB RMB 828
    Linode 1GB 8 1GB 48GB 2TB RMB 121
    阿里云 1 0.5GB 20GB 1Mbps RMB 55

    m3.xlarge 价格:

    • 实例 - $0.45/小时
    • 网络传输 - $0.12/GB

    看起来, 似乎阿里云的价格最低, 但是, 阿里云的 CPU 和内存非常弱, 我在上面编译 PHP 源码, 竟然花了近一个小时! 相比较而言, Linode 的 VPS 性能则较为良好.

    AWS 的价格极其昂贵! 我没有实际使用过, 但据一位在上面部署了 SSDB 的朋友反馈的数据, 他所使用的 AWS 的性能只有 Linode 的一半. AWS 的成本主要是网络带宽成本, 达到 $0.12/GB. 如果你的服务器不对外提供网络服务, 只是做一些内部计算, 我觉得 AWS 会相对比较便宜.

    阿里云的带宽价格也非常贵, 最低级的带宽套餐只有 128KB/s, 根本不是正常使用的带宽, 如果加到 1MB/s, 成本急剧增加 600 元. 而我使用 Linode, 在家里也能达到单连接 300KB, 在公司网络好时能达到单连接 2.5MB, 所以说, Linode 的带宽成本非常低.

    不过, 阿里云也有一个非常明显的优势, 那就是网络延时非常小. 这是因为阿里云的机房在国内, 而其它两个在国外(主要是美国), 使用阿里云提供 Web 服务, 给用户的感觉就是网页打开速度快.

    最后, 我做了如下感性的总结:

    产品 性能 网速 价格 性价比
    AWS 一般 一般 昂贵 /
    Linode 不错 一般 便宜
    阿里云 不高

    所以, 还是很期待亚马逊能尽快建立国内机房, 提高网速, 降低价格. 希望 Linode 建立香港机房, 既能提供高性能服务器, 也能提供境外服务器的优势. 希望阿里云提高服务器性能, 提高性价比.

    Posted by ideawu at 2013-12-21 14:51:35 Tags: , ,
  • 2013-10-27

    Redis 的作者狂喷某 NoSQL 数据库

    Views: 10679 | No Comments

    今天在 Redis 的 maillist 里看到一个帖子, 说的是某数据库(HyperDex)和 Redis 的性能对比. 说实话, 这个数据库的网站我看过, 没有深究, 后来就不再关注了. Redis 的作者 Salvatore Sanfilippo 有一条说的我比较认可:

    2) In all the other tests, probably they are comparing single-core
    Redis with multi-core HyperDex, or multi-node HyperDex. To give you an
    example Redis LPUSH can easily insert 1 million items per second into
    lists, but if you push against four instances at the same time, one
    per core, you can reach 3/4 million inserts per second. This does not
    mean we should write "four millions operations per second11!1!!!one"
    in our home page.

    简单翻译一下:

    单个 Redis 实例每秒能处理 1 百万次 LPUSH 操作, 但是, 如果你启了 4 个 Redis 实例, 那当然能每秒处理 3 到 4 百万次插入. 但我们绝不会在网站首页写"每秒 4 百万次操作!!!".

    Posted by ideawu at 2013-10-27 19:40:09 Tags:
|<<<123456789>>>| 4/13 Pages, 73 Results.