タグ

ブックマーク / blog.shibayu36.org (129)

  • 採用手法の良し悪しを判断するための基礎知識を身に付ける - 「人事と採用のセオリー」を読んだ - $shibayu36->blog;

    今後採用に積極的に携わることになったので、じゃあ基礎知識を自分が身につけておかないと人事の人にも信頼されないよなと思い、社内の人事の方に紹介された「人事と採用のセオリー」というを読んだ。 人事と採用のセオリー 成長企業に共通する組織運営の原理と原則 作者:曽和 利光ソシムAmazon 今の自分が知りたい情報に完全にマッチしていたため最高のであった。人事とはどういう役割を担うかという簡単なサマリーや、採用を考える際の基的な知識をざっくり学ぶことが出来たと思う。ネット上の記事ではいろんな採用の手法がどんどん話題になるけど、その良し悪しや自社へのマッチ度を判断するために必要な知識を得られたと感じる。 特に 要員計画を立てた上で、採用計画はその枠の中の一つと捉える。要員計画を達成する手段は「採用」だけでなく「育成」「配置」「外部委託」などもある 採用フローでの歩留まりの考え方 ポテンシャルを

    採用手法の良し悪しを判断するための基礎知識を身に付ける - 「人事と採用のセオリー」を読んだ - $shibayu36->blog;
  • 「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました - $shibayu36->blog;

    エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました Engineering Manager Meetup #5で「エンジニアメンター制度の効果的な運用を目指して」という発表をしてきました。 自分も久々の発表で緊張しましたが、自分の頭をまとめる良い機会になりました。他の発表も学びが多く、とにかく濃いミートアップでした。このような機会を与えてくれた運営の方に感謝です。また機会があったら参加・発表したいです! 以下は発表内容のまとめです。 発表内容 アジェンダ はてなのチーム横断のエンジニアメンター制度とは 実際にどのような課題があったか どのように改善したか 改善施策により最終的にどうなったか 今回の施策を通しての気付き: マネージャ向けにも当たり前のことをする イントロ 自分がマネージャっぽい仕事をしていると以下

    「エンジニアメンター制度の効果的な運用を目指して」という発表をEngineering Manager Meetup #5でしました - $shibayu36->blog;
  • 入門 考える技術・書く技術を読んだ - $shibayu36->blog;

    人に分かりやすく伝える技術が不足していると感じたので読んだ。 入門 考える技術・書く技術――日人のロジカルシンキング実践法 作者:山崎 康司ダイヤモンド社Amazon ビジネス文書を書くために実践的に使えるテクニックを手早く知るためには良いだと思った。また日語における固有の難しさについても触れているので、いつも日語を使っている僕らが知りたいことについても書かれていた。以前読んだ「考える技術・書く技術」というは結構ボリュームがあり難しかった記憶があるので、とりあえず「入門 考える技術・書く技術」を読んで実践してみると良さそう。 個人的に印象に残ったのは OPQ分析というフレームワーク 何か文章を書くときには必ずやってみたい 感謝の言葉にPDFというフレームワーク メールの文章を書く時には良さそう。グループウェアとかで質問があった時に、簡単な返信をするフレームワークとしても良さそう

    入門 考える技術・書く技術を読んだ - $shibayu36->blog;
  • 問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;

    自分の置かれた環境で問題意識を感じることってありますよね。例えば 上司全然ちゃんとやってくれないじゃん!最悪! 会社にこういう問題あるじゃん!なんで直らないの!最悪! みたいな感じ。 昔はこういう問題意識を持った時、自分で「良い状況に変える」ことに苦労をしていました。しかし、最近は自分の意識を変えることで「効率的に良い状況に変える」ことをしやすくなったなと感じています。そこで今回は、どのように自分が意識を変えたかということと、問題意識を感じた時に最近試しているアクションについて書いてみようと思います。 昔に自分がよくやっていたアクション 問題意識を感じた時、昔に自分がよくやってしまっていたのは 飲み会の場で愚痴る 上司に詰め寄る 問題意識だけを提起する というようなアクションです。このようなアクションをした時、良い上司はちゃんと話を聞いてくれて、実際に問題が解決することも多くありました。

    問題意識を感じたときに「効率的に良い状況に変える」ためのアクションリスト - $shibayu36->blog;
  • アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;

    最近話題になっていた「入門 監視」を読んだ。アプリケーションの監視をするための実践的なノウハウが詰まっていて非常に参考になる書籍だった。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon このでは、アプリケーションを監視するための骨格となる考え方や、様々な層(フロントエンドからOSのメトリックまで)での監視の入れ方の実践的なノウハウ、さらには障害対応をスムーズに行うためのフローや障害の根対応をチームで行えるようにするためのやり方まで書かれている。実践的なすぐに取り入れられるような内容が多く、「アプリケーションをどう監視したら良いか分からない!」「障害対応をもっとうまくやる方法はないのだろうか?」と思う人には参考になる部分が多いと思う。 個人的にこのの中で一番良いなと思ったのは、 SREだけでなくアプリケーションエ

    アプリケーションは全員で監視する - 「入門 監視」を読んだ - $shibayu36->blog;
  • macでの定期実行はcronじゃなくてlaunchdを使う - $shibayu36->blog;

    手元PC(mac)で、スクリプトを定期実行したいときにどうするんだろう?という気持ちになり、いろいろ調べたところcronとかではなくてlaunchdを使ったら良さそうらしいと知ったのでメモ。 定期実行をlaunchdを使って登録する launchdで定期的にスクリプトを実行 - Qiita が非常に参考になる。基的にはStartIntervalかStartCalendarIntervalを使ったらcronのように定期実行ができる。例えば10分に一回実行したかったらこんな感じ。 ~/Library/LaunchAgents/com.github.shibayu36.mycommand.plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http:

    macでの定期実行はcronじゃなくてlaunchdを使う - $shibayu36->blog;
  • Amazon SESとSNSを利用してバウンスメールを自動的にハンドリングする - $shibayu36->blog;

    メールを送るアプリケーションを作成していると、使われていないメールアドレスで登録された時や、携帯のメールアドレス変更によって登録されているメールアドレスが使えない状態になって、メール送信時にバウンスメールとして返ってくることがある。この時バウンスメールとして返ってくるメールアドレスをアプリケーション側で無効にするなどしておかないと、メール送信の無駄が発生する。また、AWS SESを使っている場合、バウンス率が高くなった場合、規制されることもある( https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/e-faq-bn.html )。 今回は、AWSを利用してバウンスメールとして返ってきたメールアドレスを自動的にハンドリングするというのをやってみたので、それを書いてみる。 前提 今回はAWS SESを利用して、メールを送信して

    Amazon SESとSNSを利用してバウンスメールを自動的にハンドリングする - $shibayu36->blog;
  • パターンから組織改善のきっかけを得る - 「組織パターン」読んだ - $shibayu36->blog;

    組織の勉強の一環として「組織パターン」読んだ。 組織パターン 作者:James O. Coplien,Neil B. Harriosn翔泳社Amazon このは、チームや組織が、よく陥る問題とその解決策について、組織パターンという形でまとめて教えてくれる。パターンは パターンの名前と重要度 ・・・の後にコンテキスト 星三つのあとにパターンの背後にあるフォースやトレードオフ それゆえの後に解決策 星三つのあとに、なぜそのパターンがうまくいくか そのあとに他パターンへの参照 のように書かれていて、特定問題が起こる背景や、そのとき解決の一案、さらにその解決策がなぜ効果的かというのが分かるようになっている。ただし、このの最後の方に「組織パターンはインスピレーションをもたらすのに使うべきで、そのまま適用するべきではない」と書かれているように、そのまま適用するというより、気づきを得て自分の考えのサ

    パターンから組織改善のきっかけを得る - 「組織パターン」読んだ - $shibayu36->blog;
    fumikony
    fumikony 2018/06/15
  • サーバで動いているプロセスを知るために使ったコマンド - $shibayu36->blog;

    今日会社の開発サーバでhitode君と遊んでて、動いているプロセスを調べていたのでメモ。 動いているプロセスを知りたい 基的。 ps ax ps auxとかすると、メモリ使用量とかいろいろ見れる。 動いているプロセスの関係も含めて知りたい pstreeコマンドでできる。とりあえずどんな感じに実行されているかサマリーを知りたい時は以下のコマンド。 pstree いろいろ折りたたまれているので、それを展開したい時は-cをつける。 pstree -c コマンドの引数とかも表示したい時は-aつける pstree -ac pidを知りたい時は-pつける pstree -acp 表示してみると{}で囲まれているやつがあるけど、これは多分threadなんだろうと思う。linuxではthreadのidはpidのように管理されているみたい。 メモリやCPUを消費しているプロセスを知る topとかでいろいろ

    サーバで動いているプロセスを知るために使ったコマンド - $shibayu36->blog;
    fumikony
    fumikony 2017/11/08
  • 「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;

    最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon このLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる。このを読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの?ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ

    「ふつうのLinuxプログラミング」でLinuxの基本概念やシェルの仕組みについて学んだ - $shibayu36->blog;
  • gotest.elを使って、Emacs上でgolangのテストを実行する - $shibayu36->blog;

    ScalaEmacsで現在編集している部分のテストを実行する - $shibayu36->blog; と同じようなことをgolangでもやりたいと思って調べたら、gotest.el というのを使えば同様のことを簡単にできることが分かったので使ってみた。 今回できること 現在編集中のファイルのテストを実行する 現在編集中のテストメソッドのみ実行する 以下のような感じ。 設定 まずはインストール。 M-x package-install RET gotestあとはrequireして、自分の好きなキーバインドを当てるだけ。 (require 'gotest) (setq go-test-verbose t) ;; verboseフラグ付きでgotestする (define-key go-mode-map (kbd "C-c C-t") 'go-test-current-file) (defi

    gotest.elを使って、Emacs上でgolangのテストを実行する - $shibayu36->blog;
  • ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;

    先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座:DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co

    ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
    fumikony
    fumikony 2017/10/03
  • 「みんなの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

    「みんなのGo言語」を読んだ - $shibayu36->blog;
  • 雑に書いたブログ記事が問題を起こさないようにする工夫 - $shibayu36->blog;

    ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog; で、ちょっとしたことでも雑にブログに書いておくと良いことが起こるよということを書いた。さらに余談として最低限の雑さについても書いた。 これをきっかけに、公開の場でアウトプットする時の最低限の雑さとはなんだろうという疑問が自分に生まれ、雑さによる問題や、それを引き起こさないようにするための自分の工夫について少し頭がまとまってきたので、自分の考えを書いておく。 過度な雑さから生じる最大の問題 まずあまりにも雑に公開の場に書いてしまった場合の最大の問題について考える。この時、一番起こってほしくない問題は、「読み手が誤った情報を正しい情報と信じてしまう」ことだと考えた。 あまりにも雑な文章は読み手の誤認を引き起こし、正しい情報ではないのに正しいと読み手が解釈してしまう問題がある。正しいと解釈してシ

    雑に書いたブログ記事が問題を起こさないようにする工夫 - $shibayu36->blog;
  • ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog;

    僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる

    ちょっとしたことでも雑にブログに書いておくと良いことが起こる - $shibayu36->blog;
  • 初めて学ぶ知識をどのように学習しているか - $shibayu36->blog;

    ふと、自分が初めて学ぶ知識をどのように学習しているか疑問に思ったので、考えてみたことをブログに書いておく。初めて学ぶ知識というのは、自分がやったことだと例えばマネジメント、プロジェクト管理、コーチングなどがある。 僕はある知識を初めて学ぶ時、まずはストーリー仕立てで知識を解説してくれるを読んでいることが多い。特にそのストーリーの背景に体系的な理論が見え隠れするようなものであれば、さらに良いと感じている。例えば以下のブログで紹介したようなを最初に読んでいる。 つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog; モチベーションと目標設定・教育と褒める叱る - 「1分間マネジャー」を読んだ - $shibayu36->blog; 問題の効率的な解決方法を学ぶ - 「世界一やさしい問題解決の授業」読んだ - $shibayu36->

    初めて学ぶ知識をどのように学習しているか - $shibayu36->blog;
  • 「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;

    理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus) 作者:奥野 幹也技術評論社Amazon 積ん読に入っていたので読んだ。 このはリレーショナルモデルを理解することによってRDBの知識を深めようというようなRDBを実践で使っている人がさらに知識を深めるためのという感じ。内容としては重要な理論がRDBと紐付けられて解説されていて面白かった。一方で、専門用語が文章中に多く使われていて、個人的には何か頭に入ってこなかった点は残念だった。 このを読みながらわからないところを調べていて見つけたのだけど、このの著者の昔の発表資料である「データベース設計徹底指南!!」がこのの端的なまとめになっていて、しかも非常に良い資料なので当におすすめ。で紹介されているリレーショナルモデルや正規化理論などがわずか15分程度で理解できる

    「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;
  • 問題解決のための質問群を学んだ - 「考える技術・書く技術」を読んだ - $shibayu36->blog;

    最近、自分は問題をうまく分割して解決する能力や、他の人に分かりやすく伝える能力がまだ足りていないと感じていた。そのあたりを強化するために、おすすめと言われた「考える技術・書く技術」を読んだ。 考える技術・書く技術―問題解決力を伸ばすピラミッド原則 作者:バーバラ ミントダイヤモンド社Amazon このは、わかりやすい文章を作るために、ピラミッド構造で論理構造を作るという技術を教えてくれるだ。このを読み終わって、ピラミッド構造を作るという考え方は、問題を分割するということにも、文章を他の人に伝わるように分かりやすく書くということにも応用できる、非常に有用な考え方であると感じた。 まず最初にぱらぱら読んでいた感想は、非常に良いことが書かれてそうなのだけど、なぜか頭に入ってこないということだった。このためあまり面白くないなと思いながら、気になるところを付箋はったりメモしたりしながら読んでい

    問題解決のための質問群を学んだ - 「考える技術・書く技術」を読んだ - $shibayu36->blog;
  • ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog;

    半年前から会社でシニアエンジニアという役職で、エンジニアのメンターの役割を担っている。その役割を出来るだけうまく演じられるように、半年間はコーチングの学習を進めてきた。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog; 「コーチングのすべて」読んだ - $shibayu36->blog; また、半年間、目標・1on1・評価と一通りの業務をこなし、コーチングの実践が出来た。 そこで今回はコーチングの学習と一通りの実践を通して学んだことで、特に役に立ったと思うことについて一旦まとめてみる。特に役に立ったと思った知識は以下の二つである。 ゴールを決め、現在位置とのギャップを考え、目標を決める 解決案を与えるのではなく質問する ゴールを決め、現在位置とのギャップを

    ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog;
  • Union Findアルゴリズムの様々な実装とパフォーマンス計測 - $shibayu36->blog;

    CourseraにAlgorithms Part1という授業があり、これが非常に評判が良いので、会社で勉強会をしている。Week1にUnion Findというアルゴリズムが出てきて、その実装パターンがいくつかあった。それぞれ計算量が違うらしいのだけど、速度がどのように変化するか試したかったので、実装してパフォーマンス計測をしてみた。それぞれの実装の詳しい説明が知りたかったら、https://www.coursera.org/learn/algorithms-part1 を見ると良い。 Union Findとは何か 二つのノードを繋いでいき(Union)、あるノードとあるノードがつながっているか(Find or Connected)を判定するアルゴリズム。 例えば、union(1,6)、union(5,6)、union(2,7)、union(3,8)、union(4,9)、union(8,9

    Union Findアルゴリズムの様々な実装とパフォーマンス計測 - $shibayu36->blog;