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

はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs

先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変

Elasticsearchを使おうとすると、まずアプリケーションの仕様にしたがってインデックス定義やマッピング定義を設計しなければならない。これはMySQLを使っていてスキーマを考えるフェーズに相当する。 この時、考えることが非常に多く、いろいろなドキュメントを参照し設計したので、今回はその手順について書いていきたいと思う。 インデックスやマッピングが何かという話は、次の記事を参考に。 Elasticsearchチュートリアル - 不可視点 Mapping and Analysis | Elasticsearch: The Definitive Guide [2.x] | Elastic また対象とするElasticsearchのversionは記事執筆時点の安定版の2.3.5とする。 今回サンプルとする例 実際のプロジェクトを参考例にすることは流石にできないので、今回はブログの記事を検索

CourseraのAlgorithms, Part Iというコースで、高速なRandomized Queueを実装するという話題があったので、試しに作ってみた。 高速なRandomized Queueとは Randomized Queueとは、Queueからdequeueするときに、中に入っている要素の中からランダムに一要素取り出すようなQueueである。 また「高速な」とは、enqueue、dequeue、isEmpty、sizeなどの操作の実行時間が、"constant amortized time"であること、つまり何回も操作を繰り返していくと、平均的には定数時間でそれぞれの操作が終わるということである。 この二つを満たすものを高速なRandomized Queueと呼ぶ。 実装 高速なRandomized Queueを実装すると次のようになった。 import java.util.

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

自分の頭を整理するために書いておく。正しいかは知らない。 まず前提として、Javaの内部表現としての「文字」は16ビット長のUTF-16ということがある。そうすると、普通に長さを取得すると、UTF-16のサロゲートペアで表される文字は2文字と扱われる。 また、文字には合成済み文字という話がある。「か」の後に濁点を結合することで、「が」を表現するみたいなやつ。 これらから、どこまで考慮して文字列の長さを取得するかでやり方が違う。 UTF-16のサロゲートペアを考慮しない UTF-16のサロゲートペアを考慮する 合成済み文字を考慮する 以下試したサンプルコード。 import java.text.BreakIterator; public class UnicodeCharSample { public static void main(String[] args) { // 𪛀あが St

はてなインターンの事前課題で非常に簡単な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

最近フロントエンドの速度改善をほんの少しだけやって、いろんな資料を参考にしたので、今後また速度改善をする時に備えて、参考になった資料をまとめておく。今回パフォーマンス改善やった項目としてはExpiresヘッダ付ける、gzip圧縮かける、JSをbodyの一番下にとか基本的なことしかやらなかったので、そのあたりはこの記事ではまとめていません。 今回は「測定する」「ブラウザがどう表示しているか知る」「改善を検討する」の流れで調べていったのでその順にまとめる。 測定する 何はともあれ測定しないと何も始まらないので、まずは測定の仕方について調べた。 PageSpeed Insights( https://developers.google.com/speed/pagespeed/insights/ )と、webpagetest( http://www.webpagetest.org/ ) はとりあえ