久々のオフライン開催ということで、YAPC Kyoto 2023に参加してきた。 久々に大量の知り合いと話せて、とにかく楽しかった！ YAPCは昔から参加していたので、大量の知り合いと久々に会えた。オンライン開催だと立ち話とかもあまりできなかったので、オフラインで「最近どうですか」から色々話せるのは楽しいんだなと思い出せた。 僕は、好きなことがある人が無限に最近やっている話をしてくれるのを聞くのが好きなので、カンファレンスで久々にそういう体験ができた。これだよこれ〜〜という気分になった。 前日祭の後も飲み会を開催したら10人くらいきてくれたり、その後はてなのオフィスに行ったらいろんな飲み会から集結して数十人くらいで集まれたのも楽しかったな〜。 本編で印象に残った話 ar_tamaさん あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで - Speaker Deck 最近僕

これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの

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

組織論や経営への興味関心から、「殻 脱じり貧の経営」を読んだ。 殻―脱じり貧の経営 作者:高橋 伸夫ミネルヴァ書房Amazon この本は、会社がじり貧に陥る理由を「殻」という概念を提唱し説明してくれる。また最後にじり貧に陥った会社がどうやってそこから脱出するかについても論じている。 この本は経営者におすすめできる。「じり貧」というのは難しく、ゆでガエル現象と揶揄されるように、中にいるとそうなっていること自体に気づけないことが多いので、じり貧に気づくためにも一度読んでみると良いと思う。 僕は8章と終章が面白かった。一方、途中の事例紹介であるフォードの話とENIACの話は、こんなに詳細に書く必要ある？というくらい回りくどく感じたので、フォードがどのように成功し、どのようにじり貧に陥ったかというのがある程度理解できるくらいに流し読みしても良いと感じた。特にENIACの話は別に読まなくても理解でき

このコードどうしてこうなってるのかという経緯を知りたい時、git blameなどのコマンドを利用することが多い。しかし、git blameだとその行を変更したcommitが分かるだけであり、経緯が結局分からないということがよくある。 そういう時にその行を変更したPRを開けるようにしたいなーと思って、いろいろやったところ、Emacsで現在見ている行を変更したPRを開けるようになったのでメモ。 特定のコミットが含まれるPull Requestを開くには 前段階として、特定のコミットが含まれるPull Requestを開くということをやってみる。これは既にいろいろやっている人がいて Commit Hash から、該当 Pull Request を見つける方法 - Qiita How to find pull-request by a commit sha - Pitr.ch Gitベースのコード

DateTimeでtimezoneの設定をしたりしたときに、うまく整理できなくてはまったのでメモ。 今回はDateTimeでset_timezoneを利用したときにどのような仕様で時間をずらすのかという部分とDateTime::Format::MySQLの仕様を理解できていなかったために、MySQLからデータを取ってきたときにはまってしまった。 仕様(?) DateTimeオブジェクトはtimezoneを設定したときに以下の規則で時間をずらしている。 DateTimeのtimezoneがfloatingの時にtimezoneをセットしても、時間は変換されない。つまりその時のfloatingにおける時間を設定したtimezoneの時間とみなす。 DateTimeのtimezoneがfloating以外の時にtimezoneをセットすると、時間はそれらの差分の分変化する。例えばtimezone

最近心がけていることとして、「良かったことは良かったとはっきりフィードバックする」ということがある。 自分がリーダーやマネージャのポジションになった時に、方針やメッセージを打ち出す、チームの開発フローを改善するなどを行うことがあった。この時、何もフィードバックが返ってこなくて、結局良かったのか、それともあまり興味がないのか、実は不満に思っているのか、どれなのかわからず、非常に不安に思ったという経験がある。 逆に自分が伝えられる立場になった時を考えてみると、何かが行われた時、気になることはよくフィードバックするけど、良かったなと思うことは心の中で思うだけでフィードバックしないことが多いと感じた。 そこで最近は、「良かったことは良かったとはっきりフィードバックする」ように心がけている。はっきりフィードバックするというのは、どこが良かったかを出来る限り具体的に相手に伝えるということである。伝える

自分はアプリケーションエンジニアでネットワークを触ることは少ないのだけど、ネットワークも関わるタスクや障害が現れた時に話についていけないのは良くないと思い、マスタリングTCP/IP 入門編を今読んでいる。データリンク層の章まで読み、この章ではデータリンク層の通信ではMACアドレスを用いて通信していると書かれていた。 しかし、読むだけではまだ理解が足りてないなと思い、pingをサブネット内のホストに打ちながらWiresharkでフレームを眺めるということをしていた。特にIPからMACアドレスの解決をどのようにしているのかと思い、192.168.10.7から192.168.10.4にpingしながら、ARPのフレームを眺めていると、 No. Time Source Destination Protocol Length Info 1811 87.235306 Apple_42:64:b2 Ap

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

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

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

最近、CourseraのArgorithms, Part1という講義を受けている。そこでソートの講義を受けて、そういえばMySQLのORDER BYでfilesortになったときってどのソートが使われているのだろうと気になってきたので調べてみた。 調べてみると非常に難解で、結局いまいち分からなかったが、今の段階の調べた内容をひとまず書いておく。MySQLのコードを読んだのも初めてで、しかもちゃんと読み解くことができなかったので、情報が間違っている可能性も非常に高い。間違ってたら指摘してもらえるとうれしいです。 調査結果 最初に調査結果を書いておく。たぶんこれは非常に単純化したもので、詳しく見るともっといろいろチューニングされてそう。 sort_buffer_size以内のメモリ量でソートが可能な場合、メモリ内でのみソートされる ソートにsort_buffer_size以上のメモリが必要な場

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

最近、コンピュータサイエンスなどの基礎的な知識を学習するように心がけている。できる限り今後も長い期間役に立つ、寿命の長い技術や知識を付けておきたいためである。その一貫で アルゴリズムを学習 してみている。 学習をはじめて感じた課題 しかし、とりあえずアルゴリズムを学習してみると、学習を続けられるか分からないという課題も感じた。 寿命の長い技術であるほど、日々の開発にすぐに利用できないことが多い 例えばアルゴリズムを学んだとしても、それが役立つまでいくにはある程度長い時間が必要 日々の開発に利用できていないと、モチベーションをずっと保ち続けるのが難しい モチベーションが保てないと、結局途中で勉強をやめてしまい、日々の開発に利用できるレベルまでたどり着けない 流行りの技術とかは、すぐに開発に導入してみるとかができるので、とりあえずモチベーションは保ちやすい。しかし、数学とかアルゴリズムとかLi

やさしいコンピュータ科学 (Ascii books) 作者:アラン・W. ビアマンASCIIAmazon 最近、流行りのものを勉強するより、技術の賞味期限が長いコンピュータサイエンスの基本の理論を再勉強しようという気持ちが強い。そこで、とりあえず概論でも見るかという気持ちになって、「やさしいコンピュータ科学」を読んだ。 この本はコンピュータ科学の概論を出来るだけやさしく書いた本。カバーする範囲もある程度広範囲で、プログラミングとは何か、プログラミングの最小構成要素、アルゴリズム、電子回路、計算困難などを取り扱っている。やさしい、というワードを関しているだけあって、たしかに変に専門用語は使っていない。 ざっと眺めただけなのだけど、個人的には大学で習ったことをぼんやりと思い出した。ぼんやりと思い出して、そういえばこういうのもあったなあという気持ちにはなれたので、まあ全体の概論はもう理解できてい

tokuhirom blog を見て、これ便利だなーと思ったので、試しにこれを使ってprove単位でTest::mysqldを起動するやつを作ってみた。 harriet用設定を作る まずt/harriet/mysqld.plみたいなのを作る。この中でmysqldの起動とschema流し込みまでしてしまう。複数のdsnを保存しておきたければ、jsonで入れておくと良さそう。 # t/harriet/mysqld.pl use JSON::XS; use Path::Class; $ENV{TEST_EPIC_DSNS} ||= do { require Test::mysqld; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '', # no TCP socket 'default-storage-engin

WEB+DB PRESSのPerl Hackers Hubで執筆しませんかとお声がけいただいたので、「Perl開発への動的な型制約の導入」について執筆しました。本日発売です。 WEB+DB PRESS Vol.94 作者:藤原 俊一郎,朽木 拓,八木 俊広,吉田 太一郎,うらがみ,のざき ひろふみ,うさみ けんた,水嶋 淳貴,佐々木 健一,柴崎 優季,前島 真一,伊藤 直也,遠藤 雅伸,ひげぽん,海野 弘成,はまちや2,竹原技術評論社Amazon 今回は、動的な型制約とは何かや、なぜPerlに導入したいのか、Smart::Argsを使った型制約の導入方法、型制約の応用など、動的な型制約にまつわる内容について書きました。Perlでもっと安全に開発したいと思っている方には参考になると思うので、是非見ていただければと思います。見出しは次のとおりです。 なぜ動的な型制約を導入したいのか Smart

最近、簡単な漫画(フィクションではなくコミックエッセイ)のアシスタントをやった。僕自身は絵は全く描けないので、やったこととしては単に肌の色塗り、単調な服の色塗り・トーン貼り、髪の色塗りなどを手伝った。 これまで漫画には読み手という立場でしか関わったことはなく、書き手として初めて関わり、新鮮な体験を得られたので、感じたことを書いてみる。 手間がかかる まず一番最初に感じたのが、とにかく手間がかかっているということ。僕がやったところは、本当に単調で一番時間がかからないところだったけれど、それでも100ページくらい担当すると大体丸二日くらい時間がかかった。やった作業としてはおそらく全体の2~3%くらいしかなく、これとは別にネーム、ペン入れとか、トーンや色で絵の技術が必要なところとか全部やろうとすると、どれだけ時間がかかるのだろうかと思った。週刊連載で毎週16ページくらい書かれているのは本当に大変

最近コードレビューをどのように回していくかについて考えたことがあったのでブログに書いておく。 コードレビューの目的 コードレビューには誤りの発見以外にいろいろな目的がある。自分の中ではid:hisaichi5518が昔プレゼンでまとめていた目的が結構しっくり来ている。 https://speakerdeck.com/hisaichi5518/kodorebiyufalsehua?slide=8 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721 機械的に発見できない誤りの発見 技術力の向上 属人性の排除 コードレビューの目的としては誤りの発見と同様に、技術力の向上や属人性の排除といった教育的側面も重要である。 コードレビューで課題に思っていたこと 自分のチームでは基本的に一人がコードレビューをして、OKだったらmergeをして

コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの