ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog;
半年前から会社でシニアエンジニアという役職で、エンジニアのメンターの役割を担っている。その役割を出来るだけうまく演じられるように、半年間はコーチングの学習を進めてきた。 目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog; なぜ最近コーチングや人間の学習モデルの勉強をしているのか - $shibayu36->blog; 「コーチングのすべて」読んだ - $shibayu36->blog; また、半年間、目標・1on1・評価と一通りの業務をこなし、コーチングの実践が出来た。 そこで今回はコーチングの学習と一通りの実践を通して学んだことで、特に役に立ったと思うことについて一旦まとめてみる。特に役に立ったと思った知識は以下の二つである。 ゴールを決め、現在位置とのギャップを考え、目標を決める 解決案を与えるのではなく質問する ゴールを決め、現在位置とのギャップを
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
基礎技術の学習のモチベーションをどう保つか - $shibayu36->blog;
最近、コンピュータサイエンスなどの基礎的な知識を学習するように心がけている。できる限り今後も長い期間役に立つ、寿命の長い技術や知識を付けておきたいためである。その一貫で アルゴリズムを学習 してみている。 学習をはじめて感じた課題 しかし、とりあえずアルゴリズムを学習してみると、学習を続けられるか分からないという課題も感じた。 寿命の長い技術であるほど、日々の開発にすぐに利用できないことが多い 例えばアルゴリズムを学んだとしても、それが役立つまでいくにはある程度長い時間が必要 日々の開発に利用できていないと、モチベーションをずっと保ち続けるのが難しい モチベーションが保てないと、結局途中で勉強をやめてしまい、日々の開発に利用できるレベルまでたどり着けない 流行りの技術とかは、すぐに開発に導入してみるとかができるので、とりあえずモチベーションは保ちやすい。しかし、数学とかアルゴリズムとかLi
Working With TCP Socketsを読んだ - $shibayu36->blog;
Working with TCP Socketsを読みました。 [asin:B00BPYT6PK:detail] これまでネットワークプログラミングの基礎みたいなことをあまり考えたことなかったので、結構勉強になりました。 次のようなことが勉強になりました。 serverやclientが通信を行うときにどのようなlifecycleをたどるのか bind, listen, connectなど 通信を効率的に行うために、kernelがどのようなことをするか buffer層みたいなところで何をするか サイズ指定のreadを実行した時にkernelはどのような領域を確保するか 普通にnetcatとかlsofが便利とか Network Architecture Patternsの基本形とか 基本的なことを簡単に解説するという感じだったので、webサーバとかnginxのproxyとか普通に使ってるけど、
目標設定の仕方を学ぶ - 「ザ・コーチ」読んだ - $shibayu36->blog;
最近コーチングという分野に興味を持って、まずは簡単でさくっと読めそうな「ザ・コーチ」という本を読んだ。 ザ・コーチ 最高の自分に気づく本 (小学館文庫プレジデントセレクト) 作者:貴彦, 谷口小学館Amazon この本は、副題も含めると「ザ・コーチ - 最高の自分に出会える『目標の達人ノート』」という題名で、その名のとおり目標設定をなぜ行うのか、どうやって行うのかについて知ることが出来る本だった。1分間シリーズのように小説形式となっていて、すぐに読むことが出来る。 現在、自分が目標って何のためにあるのかもう一度知りたいと思っていた時期だったので、非常に面白かった。読書メモがかなりの量になった。マネージャーをやっている人や、その方向に行きたいと思っている人、他にも教育を担当している人は是非おすすめ。 以下のことが印象に残ったので、それについて書こうと思う。 目的・目標・ゴールの定義と、目標設
関数の仕様を正しく実装していることをどう保証するのか - $shibayu36->blog;
静的型チェックがあったらテストはあまり書かなくて良いのか - $shibayu36->blog; で静的型チェックがあったとしても、テストをあまり書かなくて良いわけではないという話を書いた。するとブコメでいろいろ意見をもらえた。これらの意見から、関数の仕様を正しく実装していることをどう保証するのかについてもう少し深く考えてみようと思い、その考えがまとまってきたので、ブログに書いておく。 一応前提として、今回の話は自分の経験とこれまでの本を読んだ知識を元に自分で考えたものであり、何かの理論に則って話しているわけではない。この部分が違うなどあれば突っ込みを受けたい。 今回考える仕様 このようなことを考える時、非常にシンプルに考えたほうが理解がしやすいので、以下の様な仕様を持つ関数addNaturalIntを考える。 関数addNaturalIntは正の整数を二つ受け取り、足しあわせて正の整数を
MySQLを使って簡易的にサービスの数値を集計する - $shibayu36->blog;
最近色んな機能を作る時に、簡単に数値を集計してみて様子を見るということがよくあった。そこで今回はその時に使ったクエリの紹介。 【2016/10/18 10:28追記】 社内でHOUR関数とかGROUP BYにalias名を使ったらもっと簡単にできるよと言われたので、それぞれ追記してみます。 日間の作成数の集計 1日このアクションが何回行われたかとかが集計できる。date_columnにはcreatedみたいなカラムを指定し、table_nameには集計したいテーブルを入れる。他にもCOUNTの仕方を工夫したらいろいろ集計できそう。 SELECT DATE(date_column) as date, COUNT(*) as count FROM table_name GROUP BY DATE(date_column); 【改善版】 SELECT DATE(date_column) as d
「チームが機能するとはどういうことか」を読んだ - $shibayu36->blog;
【2016/09/26 12:30補足】 思ったよりこの記事が読まれてしまったので補足。ちょっと本についてネガティブなことを書いてしまったけど、僕個人が今の知識の状態で読んだ時に、1分間マネージャーシリーズなどの他の書籍である程度知っていた事もあって、文章を読む大変さに比べて満足度が低かったなあと感じただけでした。もし自分がマネージャをやっていて、かつなぜか部下への指示が多くなってしまい、自分の考える時間が少なくなってしまっているなあと思っている人は一読すると良いかもしれません。特にフレーミングの話は参考になると思います。 ただ、個人的にはこの本は少し長々としているなとも思っているので、先に他の人が読んだ読書ブログやnaoyaさんのプレゼンを読んでから読むと良さそうです。さらに各章の最後にLessons & Actionsみたいなまとめがあり、その部分が章で言いたいことを端的に表しているの
医療情報の信頼性問題から、情報の受け手が心がけることを考える - $shibayu36->blog;
bylines.news.yahoo.co.jp 上の記事が素晴らしいなーと思ったので、関連して以前に医者に聞いた話とその話について自分が思ったことを書いておきたい。 最近少し重めの病気にかかったこともあり、医療情報をインターネットを通じて調べるということが昔より多くなった。そのため、いろんな記事を見ていたのだが、そうしているとインターネット上における医療の情報や健康に関する情報は信頼性の低いものが非常に多いということが分かった。無意味に恐怖心を煽るような記事や、逆に無責任に症状について問題ないと書いている記事、他にも全く根拠の無い治療法について書かれている記事など、素人による記事が非常に多い。このような記事は病人にとって無益なだけでなく、暗い気持ちにさせたり他人に変なレッテルを貼られる原因となったりと有害である。 このように医療情報や健康に関する情報は信頼性が低いことが多いのだが、それで
「オブジェクト指向入門 第2版」の上下巻を全て読み終えた - $shibayu36->blog;
「オブジェクト指向入門 第2版 方法論・実践」を読み終えた。これでようやく「オブジェクト指向入門 第2版」を全て読み終えることが出来た。読むのは確かに大変だったけど、抽象データ型や契約による設計などといったエンジニアにとって役立つ概念を学ぶことができ、今後のプログラムの設計に大いに役立つだろうと思った。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング) 作者:バートランド・メイヤー翔泳社Amazon 上巻 原則・コンセプト 上巻は特に「第3章 モジュール性」、「第6章 抽象データ型」、「第11章 契約による設計」の3つの章が面白かった
知識ゼロからElasticsearchを実践で使えるようになろう！ - $shibayu36->blog;
以前少しだけElasticsearchを触った時に、自分流Elasticsearch入門 - $shibayu36->blog; というElasticsearchに入門した時のメモをまとめていた。しかし、その頃はElasticsearchを使って完全に一人で一つの機能を作るというところまではいけなかった。 最近になってまたElasticsearchを一から導入する仕事をすることになった。この時以前自分がまとめた記事を読みながらやっていたのだが、実践で一から導入するためにはこの記事だけでは知識が足りなかった。 そこで、前の記事の知識をベースに、一から導入するために少しずつ学んでいき、自分のブログにまとめるなどのことをしてきたので、今回はその締めくくりとして、知識ゼロからElasticsearchを使えるようになるために学習したことについて書いておきたいと思う。 今回書くこと・書かないこと 今
Elasticsearchのインデックス定義を設計する手順 - $shibayu36->blog;
Elasticsearchを使おうとすると、まずアプリケーションの仕様にしたがってインデックス定義やマッピング定義を設計しなければならない。これはMySQLを使っていてスキーマを考えるフェーズに相当する。 この時、考えることが非常に多く、いろいろなドキュメントを参照し設計したので、今回はその手順について書いていきたいと思う。 インデックスやマッピングが何かという話は、次の記事を参考に。 Elasticsearchチュートリアル - 不可視点 Mapping and Analysis | Elasticsearch: The Definitive Guide [2.x] | Elastic また対象とするElasticsearchのversionは記事執筆時点の安定版の2.3.5とする。 今回サンプルとする例 実際のプロジェクトを参考例にすることは流石にできないので、今回はブログの記事を検索
論理的な文章の技術を学ぶため「理科系の作文技術」を読んだ - $shibayu36->blog;
理科系の作文技術 (中公新書 624) 作者:木下 是雄中央公論新社Amazon 最近ブログで文章を書く時にどのように書けばよいか迷うことが多いため、久しぶりに「理科系の作文技術」を読んだ。昔はあまり文章を書いてない時に読んだのでピンと来ないことが多かったが、今回はブログをずっと書き続けていたおかげか、面白く感じるポイントが多かった。 論理的な文章を書くために重要な技術が学べるので、研究論文を書く人やブログを書く人、仕事で文章を書く人全てにおすすめできる。 特に面白いと感じたのは以下の3点だ。この点について自分の言葉でまとめてみたい。 文書を書く前の準備作業 序論に必要なこと 意見を記述するときの書き方 文書を書く前の準備作業 この本では文書を書く前にまず準備作業をすることが大事だと述べている。もしそれを無視していきなり書きはじめると、文章の失敗の原因になることが多いようだ。 準備には次の
Macでdtrussを使ってシステムコールの実行時間を知る - $shibayu36->blog;
最近lsofを使ってportの利用状況をチェックしようとしたら、なぜか数秒固まるということが起こり、drussを使ってどこで止まっているか確かめたのでメモ。 dtrussというのは、簡単にいえばstraceのOSX版という感じ。どうやって使うかはOSXでもstraceしたい？よろしい、ならばdtrussだ - すがブロあたりをとりあえず見ると分かる。 ただ、単にdtrussを実行しただけだと、結局どこに時間がかかっていたのかよくわからなかった。manを見ていると、以下のようなオプションがあり、便利そうなので試してみた。 -e : それぞれのシステムコールの実行時間をmicrosecondsで出力する -d : コマンド開始からの実行時間をmicrosecondsで出力する とりあえず-eと-dオプション付きでlsofでどこに時間がかかっているか調べてみる。 $ sudo dtruss -e
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書くテクニック - $shibayu36->blog;
blog.shibayu36.org 上の記事が思ったより読まれていたので、自分がこの基準を満たせるようにやっているテクニックも箇条書きで書いておく。 PullRequestを作ったら必ず自分でコードレビューをする コードを書いているとき、その一部一部はこれで完璧と思ってるけど、実は全体を見直すと分かりにくかったりする 1日寝てから見直す 1日経つとちょっと忘れて新鮮な気持ちで見れる 1週間後にもう一回見てみる 1週間くらい経つともうだいぶ忘れて、穴が見えてくる 穴があったら別PullRequestで直す もう一度同じところを担当することがあればチャンス。自分でもこれどういうことだっけってググり始めたら基準を満たせていない 自分が全く関わっていない部分のところを触りだしたらかなりチャンス。本当にまっさらな頭で基準を満たすか見れる。他人がやったことだからとか思わずにちゃんとその時に直す やっ
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
漫画のアシスタントをして感じたこと - $shibayu36->blog;
最近、簡単な漫画(フィクションではなくコミックエッセイ)のアシスタントをやった。僕自身は絵は全く描けないので、やったこととしては単に肌の色塗り、単調な服の色塗り・トーン貼り、髪の色塗りなどを手伝った。 これまで漫画には読み手という立場でしか関わったことはなく、書き手として初めて関わり、新鮮な体験を得られたので、感じたことを書いてみる。 手間がかかる まず一番最初に感じたのが、とにかく手間がかかっているということ。僕がやったところは、本当に単調で一番時間がかからないところだったけれど、それでも100ページくらい担当すると大体丸二日くらい時間がかかった。やった作業としてはおそらく全体の2~3%くらいしかなく、これとは別にネーム、ペン入れとか、トーンや色で絵の技術が必要なところとか全部やろうとすると、どれだけ時間がかかるのだろうかと思った。週刊連載で毎週16ページくらい書かれているのは本当に大変
プロジェクト単位でElasticsearchのローカル開発環境を作成する - $shibayu36->blog;
最近Elasticsearchを触っていて、まずはローカル開発環境を作ることになった。ただ、Elasticsearchはバージョンがかなり変わり、別プロジェクトと利用したいバージョンが異なっていたので、プロジェクト単位で使い分けるにはどうすればよいかを考えた。 やりたいこと プロジェクトごとにElasticsearchのバージョンを切り替えられるようにしたい MySQLだったら同じようなものにmysqlenvなどがある また、他の人が一瞬で環境を整えられるようにしておきたい 利用するプラグインなども含めて一瞬で バージョンを上げる時もローカル環境なら簡単にあげたい 作戦 Elasticsearchはここ からダウンロードして、特定のディレクトリに展開するだけでも利用できる そこでプロジェクトルートのelasticsearch/ディレクトリ以下に展開し、ここに展開したバイナリを利用するように
Emacsで特定のプロジェクトでだけ編集モードの設定を変える - $shibayu36->blog;
最近JSを触っていて、このプロジェクトはインデントが2だけど、このプロジェクトはインデントが4で、プロジェクトごとに設定できないかなーという課題意識を持っていた。今まで全く知らなかったのだけど、これは.dir-local.elというのを利用すれば出来るようだった。 formatting - How to set project-specific javscript indentation using js2-mode - Emacs Stack Exchange EmacsWiki: Directory Variables 設定は単純で特定のプロジェクトのrootディレクトリに.dir-local.elというファイルを置くだけ。例えばあるプロジェクトではjs2-modeのインデントを2にしたいという時は、.dir-local.elに以下のように記述しておくだけでいい。 ((js-mode
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
