如何在命令行中使用 proxy

国内的网络形势你懂的,要翻墙,无法是 VPN 或者 proxy。我个人还是用 proxy 比较多,浏览器里装个插件就能自动适应。但是那只是针对浏览器,命令行也很常用,遇墙就会卡着不动了。

有一个软件可以帮助你在 Command Line 里使用 proxy,叫 ProxyChains-NG (new generation)

在 Mac 上安装超简单(只要你机器上装好了 brew

brew install proxychains-ng

==> Downloading https://downloads.sourceforge.net/project/proxychains-ng/proxychains-4.7.tar.bz2
 ######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/proxychains-ng/4.7 --sysconfdir=/usr/local/Cellar/proxychains-ng/4.7/etc
==> make
==> make install
==> make install-config
==> /usr/local/Cellar/proxychains-ng/4.7: 9 files, 92K, built in 10 seconds

其它平台的安装大同小异,先找找有没有一个命令能搞掂的,没有的话参考一下其文档的 Installation 部分。

然后,做一个简单配置,打开配置文件

vi /usr/local/etc/proxychains.conf

视乎你的安装方式不同,配置文件的地方略有不同,但会遵从平台的一般规范,例如在 Linux 上安装,配置文件的位置可能在 /etc/proxychains.conf

打开配置文件之后,略过前面所有,直奔最后一行,默认配置是使用 tor 的,根据你机器上 proxy 的种类配置好就可以了。常见的配置

http    127.0.0.1  8080
socks5  127.0.0.1  1080

其实上面几行就有 example ,找到合适的照抄就是了。

最后,使用也非常简单,只要在命令前面加个 proxychains4,比如

proxychains4 telnet targethost.com

PS. 还有个名字接近但更加老牌的同类软件, ProxyChains ,使用方法几乎一样。

Font Awesome – Iconic Font for Bootstrap

从 v1.4 开始使用 Bootstrap,从此(内部)项目的 UI 告别了自制样式的时代,风格清新而且使用简便,是目前见过最好使的 CSS 框架。对于哪个妙句 “Build for and by nerds”,我都不知道说什么好了。如果想自定义样式,对于了解 LESS 的是非常容易的,但门槛并不在 LESS 本身,而是在于有些资源在国内是不能访问的。

而 v2.0 之后引入了 由 Glyphicons 提供的 Icons,应用到项目中去,顿时使整个 UI 的感觉上升了一个档次,真是锦上添花的好东西啊。

但是,需求总有惊喜的部分存在。
比如,想在字号较大的 title 位置也应用 icons;
又比如,在一个希望可以起到警惕作用的位置使用 .icon-ban-circle,无论是黑色还是白色(目前只有这两种颜色可供选择)都不能达到这个要求;
幸好是内部系统,不需要兼容什么老的 IE 版本,使用 png 实现的 icons,欸~~

解决方案总是会有的。 Continue reading

从分享文档的角度观察开源社区

国内的开源社区环境不咋地,朦朦胧胧的问题困扰着各个开源项目,而这个绝不是因为怀着开放理想的开源人做不出好的东西。

LOVE OPEN SOURCE尴尬的状态在持续着,脾气再好的人时间长了也会忍不住发发牢骚。

我也很费解,到底是为什么,我们到底应该怎么做?

有人说就算不参与提交代码,写些文字分享一下总可以的吧?有人就说没什么好分享的。
类似的争论总有发生的时候。这里不具体讨论这些观点,就从分享文档的角度来看看事情。

相信有许多人都有这样的经历,在使用某开源项目时遇到困难就 google,搜索结果中排名靠前的并不一定是官方的,特别是各种细致的问题,从摘要都可以看出来那个 post 所描述的问题正好就是自己遇到的,心中一乐,点开链接之后数秒,问题解决。

假设没有搜索引擎(天哪!),但是你只是知道有官方文档,然后你去查,发现写这个项目的文档写得非常特别,可能项目比较新,或者开发者就是这么特别,你只好开始刨那些文档。运气好的,能从 FAQ 里面找到你想要的,运气不好的,不太会觉得是自己运气不好,会认为这个项目开始不靠谱了,但是问题,还是得解决,于是想着既然开源的,就看看代码吧,正好自己也会哪门语言,强大的你下载了源码,不管 3721,连上调试尝试快速寻找突破口,经过 N ( >=1 ) 个循环之后,终于找到了问题,原来只是自己理解的问题,修改一下自己的代码即可轻松绕过。为了掩饰自己的“无知”,你可能选择了什么事情都没有发生。

另一个“强大的你”在地球的另外一个角度重温了一下刚才那一幕,也许太忙了,就忘了~~
还有另一个“强大的你”也遇到了,但是你也很特别,不会码字,然后就忘了~~
……
第 M 个人同样遇到个类似的问题,就会有 M 种理由当什么事情都没有发生过,就会有 M 个人开始对这个项目产生坏印象。使用的人开始减少,项目维护的热情在消减。

但情况非常之容易改善,只要中间有一个人为此记录下来,发布到网上,就会产生 P ( < M ) 个开心秒杀的情况。当中微妙的差别可以影响很多。这 M + 1 ( 1 是开发者 )个人是不是就可以形成开源社区,只要每个问题循环中有一人提交解决结果,其它人都可以直接读取这个缓存,看上去是不是非常简单而美妙。 现实中,情况可能复杂得多,只是可能,因为相对于每一个使用开源项目的个体,所要付出的和最大收益是不成比例的。整理成文字发表出去的成本非常低,网上有大量的免费服务可供选择。 开源社区可能不是以这种方式建立起来的。 只是开源社区对于开源项目是非常重要的,缺乏社区的支持,项目很难得到全面发展。 开源社区并不意味这固定的组织,任何人都可以作出贡献,比如只是一篇简单的分享,任何人都可以分享当中的喜悦。 非常简单的自然法则。

生活理想,开源

下班回家的路上,听见有歌声,在围观的人群里,发现了一个人在自弹自唱,唱得不错,从围观的数量来看,透过人群,地面上铺了一块布,晚上,灯光朦胧,上面的小字看不清楚,只看到标题:生活理想。

我顿时惊呆了。静下来听了一阵,他是嘶声竭力地吼着,歌词内容也很热血。然而,我却感觉一丝不对劲,反观围观的人,个个表情都很淡定,只是那些眼神透露出来一些闪光,是在听吗?还是在发挥着自己的想象力?还是在回忆着曾经的青葱岁月呢?忽然间,脑海里闪过一个影像,同样是艺术家在街头表演,不过不同的是观众的表情和反应,他们是享受的,他们是轻松的,他们是无悔的。

今天,群里热闹的在讨论开源的事情。我作为新手,这些讨论,让我激动着,觉得很有趣,给我很多启发。多么希望可以立刻将这些美妙的想法实践起来,将这些拥有开放思维的脑袋集中到一起,那将是多么美好的事情啊!

唯一让我感觉不自在的,就是不可避免地要去探讨残酷的事实现状,项目深入开展的困难,能不能养活贡献者等等。我试图唤醒一些人,就说:我喜欢做没钱的事。我其实不希望有人认为这是另类或者境界什么的。 Continue reading

Flex SDK 几个版本之间的关系

http://opensource.adobe.com/wiki/display/flexsdk/Downloads

一开始看总有点茫然的,怎么有三个下载链接?
Free Adobe Flex x SDK | Open Source Flex SDK | Adobe Add-ons for Open Source Flex SDK
到底是哪个跟哪个?
页面上方有几段文字,是被我skip掉了,里面有写三者之间的关系
基本就是 license 的区别。

Adobe Flex SDK 是包含开源和闭源的组件。
Open Source Flex SDK 是仅包含开源组件
Add-ons 则是闭源组件

可以简单的理解为
Adobe Flex SDK = Open Source Flex SDK + Adobe Add-ons for Open Source Flex SDK

可以根据自己的版权需求和应用需求的情况去选择

开源软件在军事领域的应用

五角大楼在年初推出了专门为军方服务的开源代码托管平台Forge.mil,这只是一个开始。

现在美国国防部将和一些开源厂商于8月12日到13日在乔治亚理工大学举行工作组会议,与会者包括了一位驻伊拉克的美国海军陆战队远征军的少校

参与会议讨论的开源项目有

转自:Solidot

Jscombiner

为自己写个工具 Jscombiner,除了帮助自己高效完成任务,可以自娱自乐,还可以开源,和别人分享。

这个工具前一个版本是命令行方式的,一方面技术所限,另一方面是一直坚持认为前台和后台开发是可以而且应该分开进行的。

当然思考的结果是会变的,该分开的还是分开,但有时后台也应该为前台开发提供一些帮助,而单纯的apache httpd提供不了,也有想过用asp, php,但是按照目前的态势,java应该更熟手一点。而且我主要是想和公司的其它同事分享这种开发方式,他们的机器上大多有tomcat而没有apache。

Jscombiner 的基本目标就是减少程序员开发 javascript 项目时所需要投入的管理成本。让 javascript 脚本采取自描述的方式来方便进行管理。因此,开发者可以在开发过程中,随心所欲地更新脚本,而无需担心重构或者脚本规模增长所带来的管理成本。是不是已经有同样的东西存在,我不确定,有是正常的,多个选择,多个竞争,才会有进步的。也许是有开发者像我这样不善推广的。

现在的状况是基本功能以及有了,自己一直在用,我期望的使用感受是感觉不到它的存在。

不过,不是为了做这个东西而做的,还有其它的目标任务,而且只有我一个人在瞎搞,而且主要的更新都是针对自己的实际应用需求的(我相信我所遇到的问题,其它人也会在某个时刻遇到),所以更新会比较慢。

等当前任务完成了,再做一个example出来。不过其实想想也很简单的,mvn archetype:generate一个项目出来,加入依赖,将脚本丢进去,然后mvn jetty:run,立马就可以着手开发了。

关于这个项目的改进计划会在Issue里面发起。目前想到的一个就是先实现前一版本中的一个功能,合并大脚本,这个应该不难,只是怎么提供出来,会更实用,更有趣呢?敬请期待啦!