golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
情報共有システム (Wiki みたいなやつ) に求めること - その手の平は尻もつかめるさ
いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする． エディタが腐ってない これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す． WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) の
unite から Git で conflict したファイルの一覧を持ってこれるようにした - その手の平は尻もつかめるさ
Vim (ビムとも言う) の話です。 さて複数人で Git を使いながら開発していると、ファイルの conflict って頻繁に起きるので、もう皆さん conflict とは仲良しこよしのことと存じます。 大体のひとは、conflict してしまったファイルをエディタで開いて修正すると思うんですが、*1 いちいちターミナルで git statusとか実行して、その結果を見ながら「どのファイルが conflict しているか」を確認して、 エディタで該当するファイルを開いて *2 修正するのってちょっと面倒臭い感じがしますよね。 やはり開発するひとも人間ですから、 「どうせだったら、エディタが conflict しているファイルをピックアップしてきてくれれば良いのに……」 「そうすれば、いちいち git のコマンドをタイプする必要がなくなって、エディタから直接ファイルを開けるのに……」 とい
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
