MySQLでNested Loopなクエリはインデックスをどう辿っているか - $shibayu36->blog;
タイムライン的なものをSELECTだけで実装しようと思った時に、Nested LoopなクエリでUsing temporary; Using filesortが出るようなそこそこ遅いクエリになる。その時にMySQLがインデックスをどう辿っているかを知りたかったので調べてみた。MySQLバージョンは8.0.33。 あまり自信はないので、もし間違った話をしていたら教えて欲しい。 どのようなクエリを検証するか タイムラインの取得ができるような、ユーザー・フォロー関係・投稿の3つのテーブルを作る。スキーマは次の通り。 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL ); CREATE TABLE follows ( id INTEGER PRIMARY KEY AUTO_I
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog;
Gitで開発していて、あるサブディレクトリ以下を別のレポジトリに移行したいと思うことがある。今回はそういうことをしてみたのでメモ。 まずGitHubにそのようなやり方の指南がある（Splitting a subfolder out into a new repository - GitHub Docs）。大体これで良いのだけれど、このやり方だとサブディレクトリのpathがそのままになってしまうという問題がある。大抵のケースで、あるサブディレクトリを別のレポジトリに分割したいとなった時、そのサブディレクトリがレポジトリルートに来てほしい。 そういう場合はGit Filter Repo — Splitting a Subfolder Into A New Repository | by Edward Ezekiel | Mediumにも紹介されているようにgit filter-repo --s
LLMを理解する一歩として「ゼロから作るDeep Learning」をやった - $shibayu36->blog;
LLM、GPT界隈を追いかけていて、GPTの仕組みと限界についての考察（2.1） - conceptualizationという記事を見かけた。これを見たとき、「どういうことか全然理解できない」という気持ちになった。また、その他LLMの解説記事を理解できないことが多く、自分の機械学習知識不足が明確になった。 理解できなかったことは悔しいし、LLMやChatGPTをうまく使いこなすには最低限どのような原理で動いているか理解したいと感じた。そこで一歩目として「ゼロから作るDeep Learning」を完走した。 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 作者:斎藤 康毅オライリージャパンAmazon 知識なしからはじめたので時間はかかったが、次のように進めていった。 自分もコードを写経しながら読む レポジトリは https://github.co
Pythonで作ったCLIツールをGitHubから直接pipでinstallできるようにする方法 - $shibayu36->blog;
chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog; にて、pip installで直接CLIツールをインストールできるようにした。 pip install git+https://github.com/shibayu36/chat-hatenablog.git この時に調べたことをメモしておく。 やったこと setup.pyを配置し、entry_points.console_scriptsにCLIとして動かしたいものを指定するだけ。 import os from setuptools import setup, find_packages here = os.path.abspath(os.path.dirname(__file__)) about = {} with open(os.path.join(here, "ch
コード変更で抜け漏れやミスを少なくするための習慣 - $shibayu36->blog;
自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に
モンテッソーリ教育の研究者に学ぶ子育てがぐっとラクになる「言葉がけ」のコツが出版されました - $shibayu36->blog;
最近妻が子育てに関する書籍を出版したので宣伝です。 モンテッソーリ教育の研究者に学ぶ 子育てがぐっとラクになる「言葉がけ」のコツ (コミックエッセイ) 作者:てらいまきKADOKAWAAmazon この本は子育てで自分たち夫婦が「子供に伝わり、かつ自分たちもラクになるために、どうやって声がけしたら良いか」と悩んでいることを、モンテッソーリ教育の研究者である島村華子先生に質問して教えてもらうというコミックエッセイです。例えば、 子供に伝わりやすい褒め方はどのようなものか どうやったら子供も一緒に片付けをしてくれるのか 保育園で起こった出来事を教えてもらうにはどうしたら良いか 子供に一緒に遊んで欲しいと言われた時に、親はそんな気分じゃない時はどうすれば良いか といった内容を教えてもらいました。 聞いた内容を実際に試したところ、もちろん育児において全てうまくいくということはなく、うまくいったりい
読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;
最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本
部下の困りごとをマネジャーが解決しすぎない方が良い - $shibayu36->blog;
マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
レビュータイムや定期的なissueチェックのためにGithubのissueを検索してSlackに投稿するCLIツールを作った - $shibayu36->blog;
https://github.com/shibayu36/notify-issues-to-slack というツールを作ったので紹介です。 背景 はてな社内では各チームでレビュータイムという時間を設けていることが多い。その時間にチーム内のissueやPull Requestを全部見るという心がけをしている。レビュータイムについては昔に以下のような記事を書いた。 blog.shibayu36.org 一方レビュータイムを導入したとしても、レビュー依頼中のissueやPull Request一覧がSlackに流れてこないと、レビューやっていくぞという気持ちが高まらないことがある。そのためレビュータイムになったらレビュー依頼中のissueをSlackに流すツールを各チームでそれぞれ作っていた。 最近自分もまた同じようなツールを作ろうとしてしまった。しかし、みんな同じツールを作っているのは良くない
「イシューからはじめよ」再読 - $shibayu36->blog;
イシューからはじめよ──知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon 最近仕事で「やるべきと思うこと」が溢れてきて良くない傾向になっていたので、「本当にやるべきこと」を見極める方法を知りたく、昔読んだことのある「イシューからはじめよ」を再読した。 良いこと言っていると思いつつ、なぜか自分に落とし込めてない。前も同じ感想を抱いた気がする。なんだろうな、結局この本から自分の納得の行くアクションが抽出できていない。100個問題っぽいものがあったら2~3個しか今の段階で解くべきものはないからそれを見つけろという意見は分かるが、見つけるためのアクションが咀嚼できてない。困った。 【13:30追記】 課題のどれからやるべきかを決める方法を悩んでいたけど最近のISUCONの時のやり方が参考になりそうだと思った。 ISUCONは改善すべきポイントは無数にあるが、実際には一番ボトルネック
人事の仕事の全容を知る - 「人事管理入門」読んだ - $shibayu36->blog;
評価制度などの仕組みを考えるにあたり、一度人事関連の教科書を読んで全容を知らないといけないなと思ったので、おすすめされていた「人事管理入門」を読んだ。 マネジメント・テキスト 人事管理入門<第2版> 作者:今野 浩一郎,佐藤 博樹日本経済新聞出版Amazon とにかく面白く、教科書的に体系的にまとめられているのに関わらず分かりやすく、読んで非常に参考になった。この本を読むと、人事とはどういう役割なのか、グレード制度とは何か、人事評価とはどういう目的で行われるのかなど、人事にまつわる知識が体系的に身につけられる。そのため、人事部に所属している人にはとにかくおすすめだし、人事に関わってなくとも組織に興味があるならおすすめ。人事に関わる制度を考えるときには何度も読み返したい本だなと思った。 今の自分だと、「第1章 人事管理のとらえ方」「第2章 戦略・組織と人事管理」「第3章 社員区分制度と社員格
コードコンプリートを再読した - $shibayu36->blog;
以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ
dockerの公式のGet Startedのドキュメントが今のコンテナ技術の概念をいろいろ学べてお得 - $shibayu36->blog;
https://docs.docker.com/get-started/をやってみたのだけど、今のコンテナ技術の概念をいろいろ学べてお得だった。 Orientation and setup | Docker Documentation で、コンテナとVMの違いって何？というのが分かる Redirecting…でpythonのwebアプリを動かしながら、Dockerfileやコンテナやイメージの概念を学べる Redirecting…で、docker-compose.ymlとdocker swarmを用いて、コンテナをデプロイするのをやる これでコンテナをスケールさせてデプロイするイメージが分かる Redirecting…で、複数のノードに分散してコンテナをデプロイするのをやる これでコンテナとクラスタ管理のイメージが分かる k8sとかECSとかがやっていることが分かるイメージ Redirec
PostgreSQLでauto_explainを使ってどのクエリが遅いか把握する - $shibayu36->blog;
ある機能が重いなどといった理由で、DBのどのクエリが遅いか把握したいことはよくあります。そんな時、PostgreSQLのauto_explainが便利だったので紹介。 auto_explainを使うと、指定した実行時間以上を利用しているクエリに対して、自動で実行計画をログファイルに出力してくれるというもの。詳細はこちら。 https://www.postgresql.jp/document/9.6/html/auto-explain.html https://www.postgresql.jp/document/9.6/html/using-explain.html 最近便利に使えたのは以下の設定。 # 自動でEXPLAIN ANALYZEしてパフォーマンス解析したい時用 session_preload_libraries = 'auto_explain' auto_explain.log
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
pyenv + venvでPython3環境を構築する - $shibayu36->blog;
機械学習のモチベーションを上げるためにTensorFlowを触ろうとしている。まずは環境設定でしょうということで、ひとまずPython3環境を作る。今はpyenv + venvで作るのが良いみたいなので、それでやってみたメモ。 pyenvでpythonをインストールする pyenvが必要かどうかフローチャート - Qiita も参考にしたのだけど、まあ細かくPythonのversionを指定したくなる時もありそうだし、とりあえずpyenvを入れておく。 自分は anyenv を使っているので、それでpyenvをインストール。 $ anyenv install pyenv 次にpyenvでpython 3.6.1をインストール。 $ pyenv install 3.6.1 $ pyenv versions system * 3.6.1 (set by /Users/shibayu36/.an
どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
