特定のユーザーのイベントによるGitHub ActionsのActionを保留状態にしておき、後で手動実行できるようにする - その手の平は尻もつかめるさ
dependabotだとかrenovateだとかを使ってライブラリのバージョンアップのpull requestを自動的に送ってもらう、というような機構を利用されている方が多いと思います。 常にこれらのpull requestに目を光らせておいて常に取り込み続けるというのが理想的な形・そうあるべきだとは思うのですが、ふと気を抜くとバージョンアップのpull requestが溜まっていき、pull request自身も改訂に改訂を重ねている......みたいなことが起きがちではないでしょうか。 そういった折、誰も結果を見もしないCI (i.e. GitHub Actions) だけが回り続けているのを見て「このチェックは『ライブラリアップグレード業』をやる時に手動で回せばコンピューティングリソースの削減になるのでは？」と思い、それを試したという次第です。 この記事では例として、renovate
最近のgitを使った開発フローについて - その手の平は尻もつかめるさ
最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン
管理画面まわりの事情，負の UI/UX について - その手の平は尻もつかめるさ
管理画面を作ってると，「みだりに押されたくはないが，かといって無いと不便」みたいなボタン (或いはそれ以外の何か) を画面上に置きたくなる時があると思う． 例えばバッチで行うような処理を (なんらかの事情で) 即時実行するボタンのようなやつ．こういったボタンは便利だけれど，無闇に押されるとシステムに対する負荷が上がり，サービスの提供に悪影響を及ぼす場合があるのでなるべく押しにくくあるべきだと思う． そういった，おもてなしを目的とはせず，むしろ或る操作に対する敷居を高くするための，謂わば負の UI・負の UX をどうするべきかを軽く考えたのでここに記す． 警告を出す 例えばこの画像のような感じ． こうして注意を喚起することで精神に注意を促すくことで，みだりな利用を抑制するという方法．ボタンを赤くすることで危険な処理であることも表している． 加えてボタンが押された時に念を押すための confi
情報共有システム (Wiki みたいなやつ) に求めること - その手の平は尻もつかめるさ
いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて，気に食わないところを twitter にガーッと書いたんだけど，さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので，僕の思う情報共有システムに求めることをここでまとめておくことにする． エディタが腐ってない これは本当に重要で，エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし，起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある．さもなくば Wiki は廃墟と化す． WYSIWYG なエディタを利用するのは難しいと思っていて，本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) の
相手の GitHub の ID さえ知っていれば暗号化したメッセージを送れる naisho というのを作った - その手の平は尻もつかめるさ
色々な事情があり，秘密のメッセージを送り合う必要性が今年に入ってから多数発生していて， そのたびに毎度毎度手で暗号化して〜みたいな風にやるのめんどいですね，そうですね， ということでこの度 naisho というものをこさえました．みんなには内緒ですよ． これは何かと言うと，やりとりしたい相手の GitHub の ID を指定するだけで その ID のユーザの ssh-rsa の公開鍵を引っ張ってきて その ID のユーザのメールアドレスを引っ張ってきて そのメールアドレスに対して公開鍵で暗号化したメッセージを添付ファイルにしてメールで送りつける という動きをするコマンドです． golang で書きたかったというのと golang で書くと便利なのではと思ったので golang で書いてあります． Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする -
実行中のプログラムの進捗度を手っ取り早く確認したい - その手の平は尻もつかめるさ
完了するまでに結構時間がかかるプログラムを実行している時，そのプログラムの進捗度を確認したくなることがままあると思います．ほんとに動いてんのかお前，みたいな． そうした時に考えうる最も簡単な方法は，こんな感じで進捗度を標準出力に流してしまうという方法でしょう． (1..100).each do |i| # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例) sleep 0.1 # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可) puts "#{i}%" end 簡単なものだとこれで良いでしょうが，途中で端末のセッションが切れると「アッアッ」という感じになったり，そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし，というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします．
ページャNight 1ページ目という勉強会やりました - その手の平は尻もつかめるさ
そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前
「Kyoto.なんか」でgithub-commit-comment.vimの話をしました - その手の平は尻もつかめるさ
「Kyoto.なんか」というイベントで，最近書いたgithub-commit-comment.vimというVimプラグインの話をしてきました．お招きいただきありがとうございます． github-commit-comment.vim https://github.com/moznion/github-commit-comment.vim Vim上からGitHubのコミットコメントの投稿と参照が出来るというプラグインです． GitHubのコミットコメントには， 行単位のコメント ファイル単位のコメント コミット単位のコメント と，3種類のコミットコメントが存在しており，これらすべてに対するコメントが可能となっています． 詳しくは上記URLのREADMEを読むと良いと思います．Gifアニメを大量に貼っているので，なんとなく雰囲気がつかめるでしょう． なお，READMEには書いていないのですが，こ
Ukigumoの新機能一覧 - その手の平は尻もつかめるさ
https://metacpan.org/pod/Ukigumo::Server https://metacpan.org/pod/Ukigumo::Client https://metacpan.org/pod/Ukigumo::Agent ゆるふわCIエコシステムのUkigumoですが，最近ひと通りアップグレードしたのでそれに伴って搭載された新機能について紹介します． 注意 Ukigumo::Server 2.0.0以降はDBのスキーマが変更されているので，テーブルのALTERが必要です． ALTER TABLE report ADD compare_url VARCHAR(255) DEFAULT NULL; などとしてやる必要があります． Ukigumo::AgentがGitHubのWebhooksに対応した /api/github_hookにGitHubのWebhookを飛ばして
tmux 1.9系でもcurrent pathの情報を引き継いでnew-windowやsplit-windowしたい - その手の平は尻もつかめるさ
去る2014年2月22日にtmux 1.9がリリースされたので勇んでアップデートしたところ，1.9からはdefault-pathオプションが削除されており，またそれが原因かどうかは定かではありませんが *1，new-windowやsplit-windowするとcurrent pathの情報を引き継いで *2 くれなくなってめっちゃ不便！！！！ ってなって，「これもう1.9にアップデートしなくても良くね？？？ CHANGES見てもこれといった変更ないし……」という心意気に一時はなったんですが，僕みたいな糞ミーハーはやっぱり新しいものを使いたいのでちょっと調べてみました． 結論 bind '"' split-window -vc "#{pane_current_path}" bind '%' split-window -hc "#{pane_current_path}" bind 'c' ne
Pod::Text::Color::Delight というモジュールをリリースしました - その手の平は尻もつかめるさ
[追記] 色々と問題を修正しましたので、最新版 (v0.0.5) をご利用なさる事をおすすめ致します。 (問題を報告して下さった@__gfx__さん、@uzullaさんありがとうございます) [追記ここまで] この度、Pod::Text::Color::Delight というモジュールをリリース致しました。 https://metacpan.org/pod/Pod::Text::Color::Delight https://github.com/moznion/Pod-Text-Color-Delight Perlの入門書や入門エントリ等を読みますと、「Perlのドキュメント調べるなら、`perldoc` コマンドでひくのが手っ取り早くて良い！」みたいな事がよく書かれていて、まあまあそれはその通りだよなーとは感じつつも、 `perldoc` コマンドで出力されるドキュメントって白黒で淡泊す
unite から Git で conflict したファイルの一覧を持ってこれるようにした - その手の平は尻もつかめるさ
Vim (ビムとも言う) の話です。 さて複数人で Git を使いながら開発していると、ファイルの conflict って頻繁に起きるので、もう皆さん conflict とは仲良しこよしのことと存じます。 大体のひとは、conflict してしまったファイルをエディタで開いて修正すると思うんですが、*1 いちいちターミナルで git statusとか実行して、その結果を見ながら「どのファイルが conflict しているか」を確認して、 エディタで該当するファイルを開いて *2 修正するのってちょっと面倒臭い感じがしますよね。 やはり開発するひとも人間ですから、 「どうせだったら、エディタが conflict しているファイルをピックアップしてきてくれれば良いのに……」 「そうすれば、いちいち git のコマンドをタイプする必要がなくなって、エディタから直接ファイルを開けるのに……」 とい
テストにコケる度にシーザーが死ぬ仕組みを作りました - その手の平は尻もつかめるさ
タイトルは釣りです。 App::WithSound をリリース致しました。 https://github.com/moznion/App--WithSound https://metacpan.org/module/MOZNION/App-WithSound-v1.0.2/with-sound (2013.03.06 追記) App::WithSound はv1.1.0 にバージョンアップしました。 コマンドの成功・失敗時だけでなく、コマンドの実行中にも音声を再生出来るようになっています。 https://metacpan.org/module/MOZNION/App-WithSound-v1.1.0/with-sound (追記ここまで) App::WithSound? コマンドが成功するか失敗するかによって、その結果に対応した音声が流れるアプリケーションです。 まず、このモジュールはm
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
