暴走编程

Just Do IT

新款 MacBook Pro 无法连接 2.4G WiFi?

问题的发现

尝试优化 5G WiFi 传输速率时,发现我的 MacBook Pro(2016 Multi-Touch Bar 高配版) 无法连接 2.4G 的 WiFi。一开始是输入正确的密码,也无法连接,之后是连输入密码这一步都到不了,直接提示无法连接。用其他设备可以正常连接 2.4G WiFi,可以排除,不是路由器的问题。

以前没有发现这个问题,还以为是 macOS Mojave 系统问题,重启系统、更新系统版本到 10.14.5 (18F132) 问题依旧。

原因

查了不少资料,中文很少有说到点,最后用英文关键词搜索 macos mojave cannot connect 2.4g 应该是找到了答案:USB3.0 会干扰 2.4G WiFi

Ref: https://forums.macrumors.com/threads/wifi-issues-with-new-mbp-on-2-4ghz.2064959/#post-27194251

赶紧验证一下:

  • 拔掉 Type-C to USB 转接口(相当于断掉所有外设),重连 2.4G WiFi,秒连 ✅
  • 插上 Type-C to USB 转接口 + USB2.0 的机械键盘,重连 2.4G WiFi,秒连 ✅ (也排除,不是转接口的问题)
  • Type-C to USB 转接口 + USB3.0 移动硬盘,无法连接 2.4G WiFi ❌
  • Type-C to USB 转接口 + USB3.0 Hub(不连接其他设备),也无法连接 2.4G WiFi ❌ (特意拆开 Hub,看了一下里面有电路和芯片,即使不连接其他外设也会激活 USB3.0)

基本可以确认,使用 USB3.0 时会严重干扰 2.4G WiFi(尤其是 WiFi 连接认证的时候)

解决方案

  1. 尽量使用 5G WiFi(推荐),(BTW:有时候 5G WiFi 也有可能会被干扰到,主要是在连接认证的时候,碰到过1次)
  2. 连接 2.4G WiFi 认证时,拔掉外设,连上之后再插回去。(我试了下,连上后可以正常上网,但稳定性不好说,时间长不知道会不会掉线重连)
  3. 用 USB 2.0,像键盘是可以,没什么影响,移动硬盘用 USB2.0 就太慢了
  4. 给 USB 3.0 线和设备增加更好的屏蔽层(理论上应该可以,但有些不切实际)

后面用中文搜索关键词 macos mojave 无法连接 2.4g,发现知乎 https://www.zhihu.com/question/52372614 也有提到这个问题。

这个问题应该是个设计问题,至少目前 Apple 公司无法解决(2016/2017 MacBook Pro,都有这个问题,会不会解决还不清楚),可能和推出 Type-C 接口有很大关系。

相关参考:

最后分享两个 WiFi 相关的

1.在 macOS 中点击 WiFi 图标时,按住 option 键,可以查看到详细的 WiFi 连接信息

2.关于 5G WiFi 的优化的方法之一,使用 DFS 频道。所谓 DFS 频道,就是不同国家和地区限制部分 5Ghz 频道的使用,但符合相关设定也可以使用。

如果所在环境 5G WiFi 非常多的话,频道不够用,可以考虑使用 DFS 频道减少干扰(在有些国家和地区,不恰当使用可能违法。要遵守,在室内,在限制的发射功率内使用,避免干扰公共设施)。

有些路由器系统可以开启所有支持的频道,我实际测试下来,使用 DFS 频道效果不明显,不知道是不是兼容问题。不过周围 5G WiFi 频道不多,干扰不大,就先这样了。

了解 DFS 更多:

优化 WiFi 的时候可以借助像 WiFi Explorer 的 App 来帮助分析所在环境 WiFi 频道使用情况

关键词: Mac、WiFi、DFS

ASP.NET Web Application Automated Deployment Using MS WebDeploy - Server-side Configuration - Part 1

使用 MS WebDeploy 自动化部署 ASP.Net Web 程序 - 服务端配置(上)

## 一、环境配置 ##

  1. 安装 Windows Server(Current 2012)、配置IIS(Google 一大把,这里不做介绍了…)
  2. 安装 Web Deploy (Current 3.5),使用 Web 平台安装程序。

选择安装0

首次使用 Web 平台安装程序,会提示并要求安装

选择安装1

选择安装 Web Deploy,URL重写工具(可选)

安装完成

安装完成!

确认安装0

确认安装是否成功

确认安装1

看到管理委派默认配置,恭喜你,环境配置完成 ;)

确认安装2

安装 Web Deploy 默认会创建这两个账户,不要改动他

二、配置网站支持 Web Deploy

  1. 创建 Web Deploy 网站发布用户账号,支持Windows账户和IIS用户账号,这里我们选择使用IIS用户账号。

创建账号0

创建账号1

添加用户,要求设置强密码

2.设置站点允许使用 Web Deploy 作为发布方式

启用发布0

启用发布1

选择之前创建的 IIS 用户账号,其他可以不用设置

启用发布2

设置,当看到类似结果,恭喜你,服务端配置到此完毕!

接下来我将介绍 使用 Web Deploy 部署项目的部署配置,最终通过结合 Jenkins CI 达到自动化部署产品,敬请期待~ ;)

如何将 SVN 迁移至 GIT 并保留所有历史记录

前言

GIT 已经无处不在,你们还在用 SVN 管理源代码吗?如果你和你的小伙伴们正在考虑,从 SVN 迁移至 GIT,如果你们的 SVN 仓库已经够庞大(1W+ commits)和复杂(后面复杂情况详解),又想在迁移之后保留所有更改记录,这篇文章也许正是你要找的。

准备工作

需要安装那些软件&工具?

  1. SubGit
  2. JRE
  3. Subversion

SubGit 是个提供从 SVN 安全迁移至 GIT 的商业工具软件,这里主要是用到它将 SVN 提交历史翻译为 GIT 提交这一免费功能。其官网提供二进制包下载(目前最新版本2.0.0,支持远程 SVN 地址)。 因为 SubGit 跨平台,基于 Java 写的,需要安装 JRE(JAVA 运行环境) 才能够运行。 此外,还将用到 SVN 命令,需要安装 Subversion 并配置至 %PATH% 环境变量(这里我是直接使用 VisualSVN Server 安装目录下 bin 自带的 Subversion)。

一. 简单情况

只需要几个步骤就能完成 SVN 至 GIT 的转换:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1. 解压 SubGit-2.0.0.zip 至路径如:x:\SubGit-2.0.0,x: 替换为实际分区。
2. 执行配置,会生成默认配置,如需密码访问远程 SVN 服务器,
#    在 SubGit_repository_name\SubGit\password 设置访问密码,
# 说明:
#   SubGit_repository_name\SubGit\authors.txt 配置 SVN 中用户提交转换 GIT 提交后对应的用户名和邮箱,
#   可将多个 SVN 帐号映射到一个用户名和邮箱,格式如下
#   svnUser = Git User <user@example.com>
x:\> x:\SubGit-2.0.0\bin\SubGit.bat configure --svn-url [http://svn.domain.com/svn/svn_repository_name/ or file:///x:/svn_repository_name] SubGit_repository_name

# 执行安装
x:\> x:\SubGit-2.0.0\bin\SubGit install x:\SubGit_repository_name

# Git Bash 中输入,克隆一份 GIT 仓库,不含工作区,推送至指定 GIT 服务器
$ git clone SubGit_repository_name working-tree --bare
$ git remote add remote_name git@github.com/own_name/project_name.git
$ git push remote_name --all
$ git push remote_name --tags

二. 复杂情况

有哪些复杂情况?

1. 目录变更

前期 SVN 仓库创建时没有使用标准结构(trunk,branchs,tags),后期修改为标准结构,比如: /svn/project_name/ <=> /svn/project_name/trunk …),想保留这些提交历史记录。

比较麻烦的就是这种情况,目前还没发现有哪些转换工具可以直接支持,这里通过一种变通的方式,即先把包含不正确结构历史记录的 SVN 仓库转换为都正确结构历史记录的 SVN 仓库。

用到几个 SVN 的命令: <div class=’bogus-wrapper’>

<figcaption></figcaption><div class=”highlight”><table><tr><td class=”gutter”><pre class=”line-numbers”>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 </pre></td><td class=’code’><pre># -r 1391:1391:指定导出范围 # --incremental 增量导出 # SVN 仓库存放路径 # 导出文件存放路径 x:\> svnadmin dump -r 1391:1391 --incremental x:\Repositories\project_name > x:\temp\svn-project_name-1391-1391-bak.dump # 创建一个临时仓库,导入 SVN 记录 x:\> svnadmin create x:\Repositories\project_name_temp # 原来是什么样,导入后还是什么样 x:\> svnadmin load x:\Repositories\project_name_temp < x:\temp\svn-project_name-1391-1391-bak.dump # 将特定目录的提交分离出来 x:\> cat x:\temp\svn-project_name-0-1390-bak.dump | svndumpfilter exclude Documents --drop-empty-revs --renumber-revs > x:\temp\svn-project_name-0-1390-eDocuments-bak.dump x:\> cat x:\temp\svn-project_name-0-1390-bak.dump | svndumpfilter include Documents --drop-empty-revs --renumber-revs > x:\temp\svn-project_name-0-1390-iDocuments-bak.dump # 导入至目录:trunk/source,即 svn/abc <=> svn/trunk/source/abc x:\> svnadmin load --parent-dir trunk/sources x:\Repositories\x:project_name_temp < x:\temp\svn-project_name-1391-1391-bak.dump </pre></td></tr></table></div>
</div>

2. 有开发分支

在 SVN 仓库中有设 Develop 分支,比如:svn/project_name/trunk(稳定分支),svn/project_name/develop(开发分支)

通过修改 SubGit 配置,可以实现转换后 GIT 包含 develop 分支。

【config_001】 - x:\SubGit_repository_name\SubGit\config SubGit Remote Book
1
2
3
4
5
6
7
	trunk = trunk:refs/heads/master
	branches = Develop:refs/heads/develop # 新增,Develop 指对应 SVN 目录(svn/project_name/Develop),注意大小写
	branches = branches/*:refs/heads/*
	tags = tags/*:refs/tags/*
	shelves = shelves/*:refs/shelves/*

3. 实例

说明

项目A,托管在 Windows Server 安装的 VisualSVN Server 上,已有超过 1W+ commits,项目前期采用的结构为【1】。大概在 Commit Revesion:1391-1394 时,有位小伙伴意识到,我们应该用分支需要 Branchs,Tags,于是结构调整为【2】。再后来来了位新伙伴,说你们项目怎么没有 Develop 分支呢?于是调整新增了【3】:svn/project_a/develop 作为开发分支。

【1】 - 项目初期
1
2
3
svn/project_a
	+ sources
	+ documents
【2】 - Commit Revesion 1391-1394
1
2
3
4
5
6
7
8
svn/project_a
	+ trunk
		+- sources
			+- documents
	+ tags
	+ branchs
【3】 - 新增开发分支
1
2
3
4
5
6
7
8
9
10
11
svn/project_a
	trunk
		sources
			documents
	+ develop
		+ sources
			+ documents
	tags
	branchs

操作

实例 - 将 SVN 中所有提交历史记录,包括所有分支(branchs)和标签(tags),迁移至 GIT。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# 原仓库 x:\Reposities\project_a
# 1. 创建临时仓库
svnadmin create x:\Repositories\project_a_temp

# 2. 将目录改变的 Commits 提取出来 在临时仓库中顺序移至到了前面
svnadmin dump -r 1391:1391 --incremental x:\Reposities\project_a > x:\temp\svn-project_a-1391-1391-bak.dump
svnadmin load x:\Reposities\project_a_temp < x:\temp\svn-project_a-1391-1391-bak.dump

svnadmin dump -r 1394:1394 --incremental x:\Reposities\project_a > x:\temp\svn-project_a-1394-1394-bak.dump
svnadmin load x:\Reposities\project_a_temp < x:\temp\svn-project_a-1394-1394-bak.dump

# 3. 导出结构【1】时的 Commits,在临时仓库中重写 Commit是 为结构【2】
svnadmin dump -r 0:1390 --incremental x:\Reposities\project_a > x:\temp\svn-project_a-0-1390-bak.dump

# 3.1 分别过滤 & 提取 Document 文档的提交记录,并将其重写 svn/sources/Documents/ <=> svn/trunk/sources/Documents
cat x:\temp\svn-project_a-0-1390-bak.dump | svndumpfilter exclude Documents --drop-empty-revs --renumber-revs > x:\temp\svn-project_a-0-1390-eDocument-bak.dump
svnadmin load --parent-dir trunk/sources x:\Reposities\project_a_temp < x:\temp\svn-project_a-0-1390-eDocument-bak.dump

cat x:\temp\svn-project_a-0-1390-bak.dump | svndumpfilter include Documents --drop-empty-revs --renumber-revs > x:\temp\svn-project_a-0-1390-iDocument-bak.dump
svnadmin load --parent-dir trunk/sources x:\Reposities\project_a_temp < x:\temp\svn-project_a-0-1390-iDocument-bak.dump

# 4. 将剩下的 Commits 导出导入至临时仓库
svnadmin dump -r 1396:HEAD --incremental x:\Reposities\project_a > x:\temp\svn-project_a-1396:HEAD-bak.dump
svnadmin load x:\Reposities\project_a_temp < x:\temp\svn-project_a-1396:HEAD-bak.dump

# 5 SubGit 配置
x:\> x:\SubGit-2.0.0\bin\SubGit.bat configure --svn-url file:///x:/Reposities/project_a_temp x:\Reposities\SubGit_project_a


# 5.1 编辑开发者映射列表 SubGit_project_a\SubGit\authors.txt
# 5.2 编辑SubGit配置【config_001】,支持 Develop 分支导入
	
# 6. 执行安装,漫长的等待…
x:\> x:\SubGit-2.0.0\bin\SubGit install x:\Reposities\SubGit_project_a
	
# 7. 使用 Git Bash,克隆一份 GIT 仓库,不含工作区,推送所有分支(branchs)和标签(tags)至指定 GIT 服务器
$ git clone SubGit_project_a working-tree --bare
$ git remote add remote_name git@github.com/own_name/project_a.git
$ git push remote_name --all
$ git push remote_name --tags

写在最后

1W+ Commits 的 SVN 仓库迁移至 GIT 大概需要4-6个小时(源代码100Mb,仅当参考,但这已经比 GIT 提供的 git svn 命令不知要快多少倍了 ), 当完成迁移后为安全起见,我们还需要对源代码做一次校验,即,捡出 SVN 最新代码(svn/project_a/develop)和 GIT 最新代码(git clone git@gitserver.com project_a -b develop),让后使用 BCompare 或类似工具做一次差异比较,确认所有源代码无差异,这才恭喜你,完成了迁移。

由于 GIT 的学习有一定曲线,如果小伙伴开发团队比较大(20+ 人),小伙伴们对 GIT 接受程度肯定有所差异,为了减少迁移至 GIT 对大伙的影响,可以考虑采用 SubGit 提供的方案,同时支持 SVN 和 GIT 双向提交。

由于作者最开始这么做已经是半年前的时候(当时 SubGit 还是 v1.x.x 现在都 v2.0.0),其中 SubGit 配置和安装部分直接替换为 v2.0.0 用法。实例部分直接参考之前生产环境操作记录,重要部分也经过测试,但个人精力测试范围有限,如有遗漏或异常欢迎留言和反馈。

学习 Coffee-script 及环境安装 (Mac)

Keyword

Homebrew: http://mxcl.github.io/homebrew/index_zh-cn.html

V8: https://code.google.com/p/v8/

NodeJS: http://nodejs.org/

Coffee: http://coffeescript.org/

npm: https://npmjs.org/

环境安装(OS X)

首先确保 Homebrew 安装了, <div class=’bogus-wrapper’>

<figcaption></figcaption><div class=”highlight”><table><tr><td class=”gutter”><pre class=”line-numbers”>1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 </pre></td><td class=’code’><pre>$ brew --version 0.9.4 $ brew update # 安装 NodeJS $ brew install nodejs # 如果之前安装过旧版本的 NodeJS,升级到当前最新版本 $ brew upgrade nodejs $ node --version v0.10.5 $ npm --version 1.2.18 # 安装 Coffee $ npm install -g coffee-script npm http GET https://registry.npmjs.org/coffee-script npm http 200 https://registry.npmjs.org/coffee-script npm http GET https://registry.npmjs.org/coffee-script/-/coffee-script-1.6.2.tgz npm http 200 https://registry.npmjs.org/coffee-script/-/coffee-script-1.6.2.tgz /usr/local/share/npm/bin/coffee -> /usr/local/share/npm/lib/node_modules/coffee-script/bin/coffee /usr/local/share/npm/bin/cake -> /usr/local/share/npm/lib/node_modules/coffee-script/bin/cake $ /usr/local/share/npm/bin/coffee --version CoffeeScript version 1.6.2 # 安装 V8 JavaScript Engine,用于在 terminal 中运行 Javascript 并输出运行结果 $ brew install v8 $ v8 V8 version 3.18.2 [sample shell] > print(1+1) 2 > </pre></td></tr></table></div>
</div>

编写一个 Coffee 脚本

example_01.js.coffee
1
2
3
square = (x) -> x * x
cube = (x) -> square(x) * x
print cube(5)

将 Coffee 编译成 Javascript:

1
$ /usr/local/share/npm/bin/coffee -c example_01.js.coffee

编译后对应生成的 Javascript 文件 <div class=’bogus-wrapper’>

<figcaption></figcaption><div class=”highlight”><table><tr><td class=”gutter”><pre class=”line-numbers”>1 2 </pre></td><td class=’code’><pre>$ ls example_01.js.coffee example_01.js.js </pre></td></tr></table></div>
</div>

example_01.js.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// Generated by CoffeeScript 1.6.2
(function() {
  var cube, square;

  square = function(x) {
    return x * x;
  };

  cube = function(x) {
    return square(x) * x;
  };

  print(cube(5));

}).call(this);

运行 example_01.js.js <div class=’bogus-wrapper’>

<figcaption></figcaption><div class=”highlight”><table><tr><td class=”gutter”><pre class=”line-numbers”>1 2 </pre></td><td class=’code’><pre>$ v8 example_01.js.js 125 </pre></td></tr></table></div>
</div>

使用体会

简而言之,Coffee 的语法有点像 Ruby,数组的语法又是 yaml,对与熟悉 Rails 写过 Ruby 的很容易上手,反之,对于新手,因继承了 Ruby 的一些优点,学习来也容易理解,加上很人性的官方文档,学习的过程中可以说是一种享受,这里可能需要注意的是,如果之前没有接触过动态类型的语言,比如从事的语言 Java 比较多,可能会受些干扰,其实他们之前没有什么必然联系。如果是 C Sharp 可能稍微好些,用过 Linq 的应该有体会,包括从 C Sharp 4.0 之后加入了一些动态语言的特性.

Jenkins中Git仓库变更集中文注释显示乱码问题(二)

之前 一篇文章 写过:Jenkins 中使用 Git 仓库中有 Log 日志非 ASCII ,变更集会出现乱码以及一些解决过程。如今终于有人提交了这个 BUG 的修复,在 Jenkins 插件 Git Plugin 介绍页面可以看到最新的 Changelog,但是目前最新的版本还是 1.3,要等到下一版本发布才能享用?既然都有人提交了修复此 BUG 代码,那自己动手编译一个插件吧,于是尝试在自己的 MBP·13’ 把 git-plugin 源码 Clone 下来,开始编译插件(Jenkins 插件通过 Maven 来编译,最后编译成 .hpi 格式的文件,可以在 Jenkins 直接上传安装),编译过程颇为麻烦,主要是首次编译需要下载很多依赖,而国内网络你懂得,为此还发了一条,最后确认2个原因导致编译失败:

  1. Clone 下来的源码 Master 分支总是构建失败,可能是代码有问题,具体没去排查,JAVA虽学过,这么多年没用就不折腾了。
  2. 切换工作区至 tag:git-1.3.0,发现编译还是有错误,原因硬盘的名称中有空格,路径转换时对空格处理的不一样,导致找不到某些文件,在磁盘工具中把名称改了,发现 Terminal 中名称没改变,还重启了电脑(编译一次要4-5分支,重启只要20秒),重试,编译OK,成功后可以在 target 目录里看到名称为 git.hpi 文件。

既然这样,那就好办了,我可以 Checkout git-1.3.0 稳定版,在稳定版的基础上通过 git cherry-pick cdf149a73a51861bff07897aa42fa0535b88f99e 合并 Fixd 的提交,并做了一点点修改,最后顺利编译成功,不想折腾可以下载我已经编译好的 git.hpi,这样就可以提前享用,不用等官方发布啦。

相关知识

Maven:

$ mvn package #本地打包

$ mvn cleanup #清理编译

以上命令直接在项目根目录,pom.xml 文件所在目录下执行即可

更多参考:http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html

Git: git cherry-pike

Mac OS X Mountain Lion GIT Auto Completion

MacBook Pro 很早就安装了 Git,平时用的不多,也就没配置自动完成提示,今天有点时间在 Mac 上,想把自动提示配置加进去,网上找了发现有不同的方法,这里就记录下符合我这种情况下的。首先,要安装 Git,怎么安装就不说了,Google 上有很多教程,我是通过 Homebrew 安装的, 运行: $ brew install git bash-completion 安装过了的 brew 会提示:

1
2
Error: git-1.8.1.2 already installed
Error: bash-completion-1.3 already installed

接着, besh $ vim ~/.bash_profile

加入下面代码: <div class=’bogus-wrapper’>

<figcaption></figcaption><div class=”highlight”><table><tr><td class=”gutter”><pre class=”line-numbers”>1 2 3 </pre></td><td class=’code’><pre>if [ -f `brew --prefix`/etc/bash_completion ]; then . `brew --prefix`/etc/bash_completion fi </pre></td></tr></table></div>
</div>

保存,重新进入 bash,$ git c 按两下 Tab 键,看到下面提示,配置就完成了。

1
2
3
checkout                 ci                       clean                    column                   credential
cherry                   citool                   clone                    commit                   credential-osxkeychain
cherry-pick              cl                       co                       config

参考:https://github.com/bobthecow/git-flow-completion/wiki/Install-Bash-git-completion

Happy New Year

还有四天回去过春节了,大家新年快乐哈~~

Hello World

哈哈哈,八爪鱼,love it!!

终于解决Jenkins中Git仓库变更集中文注释显示乱码问题

问题描叙: 借用这个图片,也是这位仁兄提到的问题(http://bbs.51cto.com/thread-952489-1.html)

Jenkins使用Git仓库变更集乱码图示

解决方法:

x:\Jenkins\jenkins.xml 新增蓝色粗体标记参数(-Dfile.encoding=utf-8),然后重启Jenkins服务,完毕!

<arguments>-Xrs -Xmx256m -Dfile.encoding=utf-8 -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar “%BASE%\jenkins.war” –httpPort=8080</arguments>

原因: 为什么Jenkins 使用 SVN 仓库不会出现非 ANSI 字符乱码,因为 Git 插件获取变更集时 保存的不是 XML格式文档,虽然后缀都 .xml ,这就导致了显示的时候不知道已什么编码方式来显示,就使用了系统默认编码,中文的也就是 GBK。 而 GIT Commit 注释默认是 UTF-8。

更新:发现 msbuild 输出的 log 显示时乱码,想到把 cmd 页码也该为 UTF-8,最后试验了,问题解决。中文系统默认代码页 936 ,需要改为 65001,通过修改注册表的方式:参考:http://hi.baidu.com/study_together/item/b6dda48330b99be1e496e0f9

2013/04/10更新:已经有更好的方式来解决:(二)