CLIツールを作るとき、ユーザー設定ファイルやデータをどこに配置するか - $shibayu36->blog;
chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog;にてchat-hatenablogをpip installできるようにするとき、ユーザー設定ファイルやデータをどこに配置するかに迷った。このツールでは、環境変数の設定として.envファイルを、ブログデータのインデックスとしてindex.pickleファイルを使っている。 これらのファイルの置き場所について少しだけ調べたので、現状分かったことをメモしておく。 まず選択肢としては二つありそうだった。 ~/.chat-hatenablog/.envと~/.chat-hatenablog/index.pickle 例) ~/.asdf、~/.docker、~/.gemなど XDG Base Directoryの仕様に沿って、~/.config/chat-hatenablog/.en
VSCodeのFindで今マッチしている場所にボーダーを引いて見やすくする - $shibayu36->blog;
VSCodeでFindしている時に、マッチしているwordは背景色が変わって分かるのだけど、今どこにフォーカスしているかが分かりづらかった。これが特に問題が起こるのがReplaceをしようとしている時で、Replaceするたびに今どこ？とマッチ箇所を探していた。これだと時間がかかって困る。 調べてみるとTheme Color | Visual Studio Code Extension APIに書かれているように、自分のsettings.json内で自分用に色を調整し、見やすくカスタマイズ出来ることが分かった。これでFindの現在のマッチ箇所を見やすくしてみる。 Findの色のカスタマイズは editor.findMatchBackground: Color of the current search match. editor.findMatchHighlightBackground:
PullRequestからチーム開発の生産性・健全性を測るCLIツールを書いてみた - $shibayu36->blog;
最近、開発チームの生産性や健全性をどのように計測したら良いかについて興味を持っている。その中で「LeanとDevOpsの科学」の中に書いてあるようなデプロイの頻度・変更のリードタイム・MTTR・変更失敗率の4指標や、開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiitaに興味を持った。 一方、それらの指標を考えてみた時、以下のような点について悩んでいた。 マイクロサービスなどで複数レポジトリとなり、さらにデプロイ手法がそれぞれ違う状況の場合、変更のリードタイム = コミット〜本番稼働までの時間を計測するのがなかなか難しい コミットという単位だとかなり小さく、個々人のばらつきも大きすぎるように感じるので、もう少し良い単位はないのだろうか このような悩みから、PullRequestの単位で集計することで、生産性や健全性をもう少し測りやす
現代のソフトウェア開発を学ぶために「正しいものを正しくつくる」を読んだ - $shibayu36->blog;
最近はいかにエンジニアリングの立場でプロダクトを成長させられるかについて考えている。そこで、現代のソフトウェア開発やアジャイルについて学ぶため、同僚にオススメされた「正しいものを正しくつくる」を読んだ。 正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について 作者:市谷聡啓ビー・エヌ・エヌ新社Amazon なぜ現代ソフトウェア開発は難しいのかから始まり、現代ソフトウェア開発の不確実性へ対処するためにアジャイルを利用するという流れになっていて非常にわかりやすかった。また「正しいものをつくる」ことと「正しくつくる」ことをうまく切り分けて説明してくれたので、自分の中で論点を整理しやすかった。 「正しくつくる」部分に関しては、これまで自分も注力してきたところであったので、かなり経験知を言語化できた。一方「正しいものをつくる」部分に関しては、まだ経験が
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
人事の仕事の全容を知る - 「人事管理入門」読んだ - $shibayu36->blog;
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;
最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon この本はLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる本。この本を読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの？ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ
goxc + ghrを使って、Goで書いたツールのバイナリをGithub Releasesで配布する - $shibayu36->blog;
先日の goreleaserを使ってGoで書いたツールのバイナリをGithub Releasesで配布する - $shibayu36->blog; で、Goツールのバイナリ配布ができるようになった。しかし、アーカイブ周りの処理が少し期待と違い、作成したzipをunzipコマンドで取り出すとファイルのアクセス権がおかしくなり、バイナリに実行権限がつかなくなるという問題が起こった。これは困る。 goreleaserを深追いをしても良いけど、ひとまず別の方法も試してみようと思って、goxc + ghrを使うようにしてみた。これがうまくいったので、メモしておく。 今回のコードは以下のところで確認できる。 https://github.com/shibayu36/shibayu36/tree/v0.0.7 https://github.com/shibayu36/shibayu36/pull/1 バ
OSSライセンス参考資料 - $shibayu36->blog;
OSSライセンスについて調べてたのだけど、毎回どこ見たら良いか分からなくなるのでメモ。OSSライセンスまじむずい。 Githubによる、オープンソースライセンスの選び方 | オープンソース・ライセンスの談話室 ざっと把握するための参考 たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ | コリス いろんなライセンスの特徴知るために 自作ソースコードに、MITライセンスを適用する３つのやり方 | オープンソース・ライセンスの談話室 MITライセンスの適用方法 図解：Apache License2.0の特許条項 | オープンソース・ライセンスの談話室 Apacheライセンスについて オープンソース法 詳しくは
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
「みんなのGo言語」を読んだ - $shibayu36->blog;
Go言語の学習のため、A Tour of Goに引き続き、「みんなのGo言語」を読んだ。 みんなのGo言語[現場で使える実践テクニック] 作者:松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太技術評論社Amazon 「みんなのGo言語」はGo言語を実践的に使うためのTipsがいろいろまとめられていて非常に良かった。Go言語のA Tour of Goをやったけど、次にどうすればよいかわからない、具体的にGoの良い書き方が分からないという人が読むと非常に勉強になりそう。 僕はまだGoをそこまで書いていないので、「第1章Goによるチーム開発のはじめ方とコードを書く上での心得」と「第4章コマンドラインツールを作る」が非常に参考になった。例えば以下のようなものが参考になった(数字はKindleのロケーション番号)。 Goプロジェクトのプロジェクト構成やディレクトリ構成 519, 2389
手元からpsqlでログインする時にパスワード入力せずにログインできてしまう理由 - $shibayu36->blog;
sudo brew install postgresqlでMacにpostgresqlを入れて、 $ psql postgres postgres=# create role dbuser createdb login inherit password 'dbuser';のようにroleを作ってみたのだけど psql --username=dbuser postgresでパスワード指定せずにログインできてしまった。 ？？？となって少し調べてみたら、pg_hba.conf*1にデフォルトで以下のように設定されていて、この時localhostからpsqlでログインするときにはパスワードは不要になるようだった。ちょっと怖い。 # "local" is for Unix domain socket connections only local all all trust # IPv4 local
zsh-autoenvを使って、virtualenvの自動activate/deactivateを実現する - $shibayu36->blog;
pyenv + venvでPython3環境を構築する - $shibayu36->blog; の記事で、特定のPythonプロジェクト用のvirtualenv環境を導入することが出来ました。しかし、このプロジェクトに入るたびにsource venv/bin/activateし、逆に抜ける時にdeactivateするのは 面倒 どう考えても実行を忘れる という問題があります。 そこでzsh-autoenvというzshプラグインを使って、自動でactivateとdeactivateを出来るようにしたのでメモしておきます。 zplugを導入する 今回の本題から外れますが、zshのプラグインの管理ツールをこれまで入れてこなかったので、この機会にzplugを導入しました。 おい、Antigen もいいけど zplug 使えよ - Qiita https://github.com/zplug/zpl
pyenv + venvでPython3環境を構築する - $shibayu36->blog;
機械学習のモチベーションを上げるためにTensorFlowを触ろうとしている。まずは環境設定でしょうということで、ひとまずPython3環境を作る。今はpyenv + venvで作るのが良いみたいなので、それでやってみたメモ。 pyenvでpythonをインストールする pyenvが必要かどうかフローチャート - Qiita も参考にしたのだけど、まあ細かくPythonのversionを指定したくなる時もありそうだし、とりあえずpyenvを入れておく。 自分は anyenv を使っているので、それでpyenvをインストール。 $ anyenv install pyenv 次にpyenvでpython 3.6.1をインストール。 $ pyenv install 3.6.1 $ pyenv versions system * 3.6.1 (set by /Users/shibayu36/.an
はてなインターンの事前課題をJavaでやった - Java入門記(その2) - $shibayu36->blog;
はてなインターンの事前課題で非常に簡単なltsvパーサーを作るやつがあるのだけど、Javaの勉強のためにJavaで実装してみた。ltsvパーサーは結構いろんな言語で誰かが実装しているので、これどうするのがいいのかってなったら、その実装を見に行くとやり方を理解できて便利。 事前課題 https://github.com/hatena/Hatena-Intern-Exercise2015 やったやつ https://github.com/shibayu36/java-Intern-Exercise これでいいのか気になるところもあるので、詳しい人に添削されたい。 日付操作こんなのでいいのか https://github.com/shibayu36/java-Intern-Exercise/blob/master/src/main/java/org/shibayu36/intern/exerci
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
goのprojectを始める - $shibayu36->blog;
一切go触ってなくて全く何も分からなかったので、goのprojectの始め方すらも分からないのでググったのメモっておく。 私のプログラミングの始め方 : Go | Yakst 基本的にはmkdirをしてprojectを開始するようだ。とりあえずこの記事を見ればgoのprojectを開始できる。 さあGoを始めよう！環境構築，”Hello World”から簡単なバックエンドサーバーまで | POSTD この記事もとりあえずの入門に参考になる。 これからGoを始める人のためのTips集 | The Wacul Blog Tips集もあった。gofmtの-rオプションとか便利そう。 http://r7kamura.github.io/2014/06/21/ghq.html あとはこの一番下に書いてあるとおり、ghqのpathとgoのpathは合わせた。 これでとりあえずは作れそう。
curlとjqで簡単にAPIの調査をする - $shibayu36->blog;
ちょっとAPIを調査したいと思った時に、スクリプトを書くのも面倒なのでcurlとjqとかを利用してみたら、便利だったのでメモ。今回はTrelloをちょっといじってみた。 Redirecter ひとまずcurlでjsonを出す これは普通にcurlするだけ。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards'これでは見づらい。 curlで出たjsonをpretty化する jqに通すだけでpretty化と更に色付けされる。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards' | jq '.' curlで出たjsonの一部だけ表示する jqはjsonをいろいろ絞り込み出来る。 例えばリストの5件目まで表示。 curl 'h
「イシューからはじめよ」を読んだ - $shibayu36->blog;
最近やることがたくさんあってどうしたら良いか分からなかったので、同僚の薦めもあって「イシューからはじめよ」を読んだ。結構面白かった。 イシューからはじめよ──知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon この本には、やるべきことがたくさんあった時に、タスクをやる効率をどんどん上げていくという方向にまず走るのではなく、その中で重要なイシューを見極めてそれを重点的に取り組むべきである、というようなことが書かれていた。とにかくやるのではなく、まずやることを見極めよみたいな感じ。確かに忙しい時はとにかくやるとなりがちだけど、とにかくやっててもあんまり成果が上がらないことがあるので、まず見極めないといけないと思った。 この本の中で 悩まずに考える 「これは何に答えを出すものなのか」を明確にしてから問題に取り組む 一次情報を死守 という言葉が印象に残ったので、それについて書く。 悩
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
