pero_0104のブックマーク - はてなブックマーク

どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。僕がメンティーと目標設定を行うときは、以下のフローを辿っている。なんでも良いのでゴールのイメージを明確にする現在の自分とゴールのイメージのギャップを考えるギャップを埋める目標を考え、アクションを定めるちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。なんでも良いのでゴールのイメージを明確にする
pero_0104 2017/03/09
エンジニア

マネジメント
リンク
Test::Moreのsubtestで困っていること - $shibayu36->blog;
最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち特定のsubtestだけを実行するのが面倒前のテストの状態に依存したコードが書かれがち僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en
pero_0104 2016/07/14
perl

test
リンク
Perlで、あるファイルが必要のないモジュールをuseしてないか調べるスクリプト - $shibayu36->blog;
Test::UsedModulesを使うと使っていないモジュールを検出できる。ユーティリティとしてリファクタリングのあとに、必要なくなったuseをサクッと調べられると、便利なのじゃないかと考えてcheck-perl-used-modulesというコマンドを作ってみた。 check-perl-used-modulesというファイルを適当にPATHが通っているところに用意する。 #!/bin/bash path=$(git ls-files | peco) if [ -z "$path" ]; then exit fi perl -MTest::UsedModules -MTest::More -e "used_modules_ok('$path');done_testing()"そうするとgitのレポジトリ内からファイルを絞り込んで、チェックしてくれる。こんな感じ。やってみて思ったけど、や
pero_0104 2016/05/27
perl

emacs

git
リンク
Test::Mock::Guardを使ってみた - $shibayu36->blog;
Test::Mock::Guard Released - 日向夏特殊応援部隊を見てちょっと使ってみたのでメモ。最初はこんな感じの使い方をしてた。 package test::Sample; use strict; use warnings; use Path::Class; use lib file(__FILE__)->dir->parent->subdir('lib')->stringify; use base qw(Test::Class); use Test::Mock::Guard qw(mock_guard); use Sample; use Sample::Response::Mock; mock_guard('Sample', +{ _post => sub { my $self = shift; my ($url, $query) = @_; Sample::Respo
pero_0104 2015/09/24
perl
リンク
1