サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
どうなる？Twitter
blog.shibayu36.org
基本に戻ろうと思い、Railsも勉強し直している。勉強し直しの時、Hatena-Textbookの課題を使うことが多いので、今回もそのようにした。 今回はデータベースの課題をRailsを使ってやってみた。 作ったもの この辺がdiff。かなり探索的に作ったのでcommitはごちゃっとしている。 簡易的にlist / add / deleteができるように作った。 bin/rails runner diary.rb add shibayu36 title body bin/rails runner diary.rb list shibayu36 title body bin/rails runner diary.rb delete shibayu36 3 あとは今回学んだことを雑多に書いていく。 Railsの初期セットアップ 何もわからず初期セットアップをしたので右往左往してしまったが、My
すごく焦ったけど良い形で対応できたので書いておく。 状況 子供が40度近い熱が出たので小児科へ。インフルエンザA型の診断を受けて薬をもらう。自転車での帰り道に違和感を感じたので後ろを振り向いたら、子供がけいれんを起こしていて泡も吹いていた。 熱性けいれんのことも頭によぎりつつ、今まで体験したことなかったので自転車を停めてすぐに119連絡。呼吸を確認してくださいと言われたので確認すると大丈夫だった。けいれんが治っても意識は戻らなかったので救急車の到着を待つ。救急車の中でけいれんの様子を救急隊員に報告する。この時熱は40.6度まで上がっていた。受け入れ病院の電話を聞きながら1~2個から断られているのを聞いて、医療崩壊怖いと感じる。 病院に着いた時、反応は薄いが多少子供の意識が回復していた。けいれんの様子や意識の回復の様子から考えて、単純性の熱性けいれんだろうと病院が判断。けいれんを防ぐ坐薬を入
性教育は幼児くらいから始めた方が良いと聞いたことがあり、「おうち性教育はじめます」という本を読んだ。 おうち性教育はじめます 一番やさしい！防犯・SEX・命の伝え方 (コミックエッセイ) 作者:フクチ マミ,村瀬 幸浩KADOKAWAAmazon 性教育について家で簡単にできること、幼児期には何をしておいたら良いか、実際の伝え方例など漫画で非常にわかりやすく解説されていた。これを読んでいると、自分達が子供の頃に学校で学んだ性教育はひどいものだったなと思ってしまった。 すぐ使える内容になっていたため、読んで良かったと思う。2~3歳以降の子供がいる家庭なら全員読んでおくと良いと思った。 個人的に印象に残ったことは プライベートパーツ（口、胸、性器、おしり）は大切に扱わなくてはいけないと伝える。親であっても勝手に触ったりみようとしてはいけない 気づき: よく親が子供がかわいくておしりを触っている
VSCodeでデバッガを起動したい時に、毎回.vscode/launch.jsonの追加をしていた。これ面倒だなと思っていたのだが、普通にsettings.jsonのlaunchというキー名で全ワークスペースで使うdebug launch configurationの設定ができた。 例えばRubyのデバッグのためにvscode-rdbgを使っていた場合、.vscode/settings.jsonに次のように設定しておくと全ての場所でVSCode上でRubyのデバッグができる。便利ですね。 "launch": { "version": "0.2.0", "configurations": [ { "type": "rdbg", "name": "Debug current file with rdbg", "request": "launch", "script": "${file}", "
アルゴリズム図鑑 絵で見てわかる26のアルゴリズム 作者:石田保輝,宮崎修一翔泳社Amazon アルゴリズム図鑑を眺めていて、二分ヒープ構造は優先度付きキューに使われることを知った。面白いなーと思うと同時に、そういえば二分ヒープ構造の実装をしたことがなく、あまり理解できていないことに気づいた。そこで簡単にRubyで実装をしてみたのでメモ。簡単なテストケースを作ったので多分合ってると思うけど、もしかしたらバグっているかも... 二分ヒープの詳細は二分ヒープ - Wikipediaも参考。 【2023/01/03 14:01追記】要素数が1の時に要素が空にならないバグがあったので修正しました。コメントありがとうございます。https://github.com/shibayu36/algorithms/commit/6c2ce588f7bc7fb890c6a560c7ab062c6f531a9a
GitHub Copilotに補完されて面白いなと思ったのでメモ。たとえばLTSVのログを格納する構造を作るときに、渡ってきたパラメータ引数名を使ってアクセサを作りたいとする。以下のようなコードで実現が可能。 class Log # パラメータ引数をハッシュで受け取って def initialize(**fields) fields.each do |key, value| # インスタンス変数を作りつつ instance_variable_set("@#{key}", value) # attr_readerで動的に定義 self.class.send(:attr_reader, key) end end end これを使うと、勝手にアクセサが生えてくる。 log = Log.new( user: 'frank', status: '200', size: '2326', ) p(log
最近ローカル環境でMySQL 5.7 + Railsの開発をしていると、たまにMysql2::Error: Lost connection to MySQL server at 'reading initial communication packet'というエラーが出て困っていた。これについては、mac osx におけるファイルディスクリプタの上限 | ++頭道++を見ると、table_open_cache=400と設定することで起きなくなるとされている。 ただ、いまいちその原理が分かってなかったので軽く調査してみた。この辺りについては自分は詳しくないので、正確性の保証はできない。 なぜLost connection to MySQL serverのエラーが起きるのか tail -1000 /opt/homebrew/var/mysql/$(hostname).err | grep Wa
自分は問題解決は得意な方だと思っている。しかし逆に不確実な状況・不安な状況・課題がある状況をそのままにして耐える力をもっと付けたいなと思っている。そこで最近目にした「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」であるネガティブ・ケイパビリティについて学ぶため本を読んでみた。 ネガティブ・ケイパビリティ 答えの出ない事態に耐える力 (朝日選書) 作者:帚木 蓬生朝日新聞出版Amazon 正直、この本は歴史的な話とか雑談も多く、少し頭に入りにくかったが、一方で示唆のあることを学べた。例えば どうにも対処が難しい課題を見つけた時に、拙速に解決策を見出すのではなく、興味を抱いてその宙吊りの状態を耐えると良い。それによって深い理解に行き着く 問題解決があまりに強調されると、まず問題設定の時に、問題そのものを平易化してしまう傾向が生まれる。この時、複雑さを削ぎ落としているので、現実
何かを進めようと思ってミーティングをとりあえず入れるというのをしてしまうことも多いが、適当にやるとミーティングが終わったが何も進んでいないとなりがちだ。そうならないように、自分用のミーティングテンプレートを作っているので、ブログに書いてみる。 ミーティングの用意で心がけること テンプレートの前に、自分がミーティングの用意で心がけることをリストアップする。ミーティングは「何かを先に進める」必要があると考えるため、次のことを心がけている。 何はともあれ「目的」を最初に決める。「〇〇を決める会議」なのか、「〇〇のアイデア出しの会議」なのか、「〇〇の認識合わせの会議」なのか 目的に合った「会議のゴール・完了条件」を決める。ゴールに到達したら成功、到達していなかったら失敗と振り返ることもできる。また、参加者がゴールに集中することで、横道に逸れづらいという効果もある 会の前に参加者にやってほしい「事前
思考のクセを変化させることで、ストレスを軽減させられると良いなあと思ったので読んだ。 マンガでやさしくわかる認知行動療法 作者:玉井仁,星井博文,深森あき日本能率協会マネジメントセンターAmazon 以下のことを学んだ。 状況確認シートで個人の反応を、認知・感情・行動・身体反応で整理することで、思考のクセを理解することができる さらに、その中で認知や行動はどちらかというと変化させやすい。整理をすることで、認知などをバランスを取れたものにとらえやすい効果もある 状況確認シートは、「不安…どうすれば？」不安なときに試したい基本中の基本のこと - ココロクエスト~レベルアップ心理学ブログ~byねこひげ先生 みたいなところでフォーマットも見れる 認知再構成法を使うことで、バランスの取れた認知に変化させることもできる。自分の認知に対して質問を繰り返し、新たな考え方をピックアップする このやり方の一つ
ANDPADに入社してRubyistになったのでRubyKaigi 2022にオフライン参加してきました。 rubykaigi.org 久しぶりのオフラインカンファレンス参加、本当に楽しかったです。最近オンラインのカンファレンスや勉強会に行っても中々いろんな人と話す機会が持てず、なんとなく行かなくなっていました。今回久々にオフライン開催ということで行ってみたら、久々に会った人と技術的な会話ができたり、ブースでいろんな企業のことを知れたり、ふらっと見てみた発表で異常な技術が発表されていたりと、楽しいことが盛りだくさんでした。オフラインとオンラインのハイブリッド開催は非常に大変だったと思いますが、運営の皆様ありがとうございました。 印象に残っていること 今回視聴者として印象に残っているのはこの辺り。 久々に技術でねじ伏せる人たちを生で見れたのが良かった。自分もまだまだ技術を学ばないとという気持
開発生産性を高めるヒントを最前線で働くエンジニアによる取り組みから考える会 - connpassのイベントで、「今の生産性向上活動で大切にしている考え方 〜開発チームに属した改善活動から得た気づき〜」というタイトルで、開発生産性に関する発表をしてきました。 speakerdeck.com 自分はこれまで、10年近く開発チームの中からボトムアップでチーム改善・生産性改善をしてきました。例えば、GitHubを使った開発フロー改善、チームごとの開発生産性の定量化・可視化、バリューストリームマップを使った、開発フローのボトルネック発見、CIの高速化などによる生産性改善、Findy Teamsを使った生産性可視化と改善などです。 それらの活動では失敗も成功もありました。その体験から、改善活動をしているときに裏で大切にした方が良い考え方についても明確になってきました。 そこで今回は、「今の生産性向上
yigarashi.hatenablog.com これが良い話だなと思ったので感想メモ。 「安定させる」のは良い。安定しないならチームの開発フローに問題が起こっていることが多く、「なんでブレちゃうんだっけ？」という議論からチームの課題が見つかることが多い。安定させるという考えなら変なハックが起こらない傾向にある印象 「上げる」は難しい。これまで、「上げよう」とした時に、ベロシティは基準によって変わる相対的指標なので、上げようと意識するとどれだけ気をつけても無意識にハックしてしまう経験がある。例えば 完了条件には完全に明文化されていないような地味かつ大切なポイントが終わっていない（例えばコードのメンテナンス品質が思ったより低い）時も、上げる意識だと終わりにしてしまいたくなる 考慮もれを見つけた時に、そのタスクで終わらせる意識ではなく、新タスクを作ってそっちで倒す意識になりがち 何となく、悲観
自分はこれまでの仕事で、バグ修正や機能追加でPullRequestを送るときに、考慮の抜けもれやケアレスミスが非常に少ない方であると思っている。振り返ってみて、これは自分に課している習慣が大いに効いていると思っているので、メモしておく。 毎回のcommit時 必要な部分だけをgit addし、git diff --cachedによって差分をセルフコードレビューした上でcommitする PullRequest作成時 filesの内容をセルフコードレビューし、直した方が良い部分は直す + わかりにくい部分にGitHub上でラインコメントを行う + コード上にコメントを残した方がいいならコメントする ユーザーの導線に影響するコードなら、必ず自動テストだけでなく、自分自身でユーザーの行動をトレースし、違和感がある部分が存在しないかチェックする。チェックした流れについては、PullRequest上に
RuboCopはキャッシュファイルを作成し、2度目以降の実行を高速化するのですが、GitHub Actionsでキャッシュを利用するために工夫が必要だったのでメモしておきます。 小規模なプロジェクトの場合 小規模なプロジェクトでRuboCopの実行時間がある程度ありキャッシュを利用したい場合は、キャッシュのvalidityチェックは完全にRuboCopにお任せし、すべてのGitHub Actionsでキャッシュを作ってしまうやり方がオススメです。理由は、小規模な場合キャッシュサイズが問題になるケースは少なく、全部キャッシュした方がシンプルかつメンテナンス性も高いためです。 参考の設定はこちら。 steps: ... - name: Cache rubocop uses: actions/cache@v3 env: cache-name: cache-rubocop-v1 with: pat
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon 読みました。非常に良かったので、スケールする組織をどうやって作るか考えている人は一読すると良さそう。とくに4つのチームタイプ、3つのインタラクションモードについて知れたのが良かった。 チームトポロジーは、チームファーストアプローチを適用し、4つの基本的なチームタイプと3つのインタラクションパターンを示す。この方法に従うと、生み出されるソフトウェアのアーキテクチャが明快で持続可能になる。結果的に、チーム間の問題を有用なシグナルとして扱えるようになり、組織の自律操舵を促す 4つの基本的なチームタイプ ストリームアラインドチーム：ビジネスの主な変更フローに沿って配置されるチーム。職能横断型で、他のチームを待つことなく、利用可能な機能をデ
GitHub Actionsのjobが失敗した時に簡単にSlackに通知する方法を探していたら、Slack公式のツールを使えば結構簡単にできたので共有します。Slack Workflowとslack-github-actionを組み合わせると良い。 できたもの ジョブが失敗した時だけ、以下のようにSlackに通知される。 やり方 Slack Workflowでパラメーターを付けられるwebhookを用意する GitHub Actionsで失敗時のみwebhookに通知する Slack Workflowでパラメーターを付けられるwebhookを用意する まずはSlack Workflowでパラメーターを付けられるwebhookを用意する。Workflowで用意すると、管理も簡単だしCollaboratorも付けやすい。 Workflow BuilderでCreateボタンを押し、Workfl
本当に最高の本でした。マイクロサービス化に取り組んでなかったとしても、規模が一定以上大きいプログラムのリファクタリング手法としても勉強になるので、みんな読みましょう！少なくともマイクロサービス化をしていきたいと思っていて、この本を読んでないならば、まずは一旦手を止めて関係する人全員でこの本を読んでから再度手を動かす、くらいでも良いレベルと感じました。 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド 作者:Sam NewmanオライリージャパンAmazon この本を読んでいると、マイクロサービス化をしたいときは、必ず以下の手順でやっていくべきと感じました。 目的を明確にする 達成したいことは何か？事業が達成しようとしていることにあった一連の成果が目的でなければならない。これは、システムのエンドユーザーへのメリットを説明する方法で明確にできる その目的を達成するために、な
最近妻が子育てに関する書籍を出版したので宣伝です。 モンテッソーリ教育の研究者に学ぶ 子育てがぐっとラクになる「言葉がけ」のコツ (コミックエッセイ) 作者:てらいまきKADOKAWAAmazon この本は子育てで自分たち夫婦が「子供に伝わり、かつ自分たちもラクになるために、どうやって声がけしたら良いか」と悩んでいることを、モンテッソーリ教育の研究者である島村華子先生に質問して教えてもらうというコミックエッセイです。例えば、 子供に伝わりやすい褒め方はどのようなものか どうやったら子供も一緒に片付けをしてくれるのか 保育園で起こった出来事を教えてもらうにはどうしたら良いか 子供に一緒に遊んで欲しいと言われた時に、親はそんな気分じゃない時はどうすれば良いか といった内容を教えてもらいました。 聞いた内容を実際に試したところ、もちろん育児において全てうまくいくということはなく、うまくいったりい
ユーザー設定画面にMFAの設定画面があり、それが設定されているときだけログイン後にMFAのフォームを出したいという要求はよくある。これをAuth0を使っている場合に達成したかった。しかし、Enable Multi-Factor Authenticationなどを見ても、全体に有効/無効しか切り替えられないようで困っていた。 いろいろ調べたところやる方法が分かったのでメモしておく。 ユーザー向けのMFA設定画面を自分のアプリケーションに実装する方法 まずユーザー向けのMFA設定画面を自分のアプリケーションに実装するには、Auth0のMFAリソースに対する権限を持ったアクセストークンを取得する必要がある。詳しくはManage Authenticator Factors with Auth0 MFA APIに書かれているが Auth0のApplication設定画面でGrant TypesにMF
あまり知らないコードを触るときに、周りのコードを参考にしたいことが多い。しかし、そのコードの技術スタックに詳しくない場合、どのコードは筋が良いかというのが全く分からないことがある。そういう時に、その分野に知見がある人が書いたコードを参考にしながら学習したい。 そのように知見を素早く吸収するために、git grepの結果に、その行を書いたAuthorを表示するとどうかと思ったのでやってみた。 git-grep-with-author #!/bin/bash git grep -n "$@" | while IFS=: read i j k do author=$(git blame -L $j,$j $i --line-porcelain | grep '^author ' | cut -d' ' -f2-) echo -e "$i:$j:$author:$k" done 例えばRailsの
開発組織をスケールする方法を学びたい - 「ユニコーン企業のひみつ」を読んだ - $shibayu36->blog;に引き続き、開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって本当に必要なものを作り続けるにはどうしたら良いのかのヒントを得るために、「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ。 Scaling Teams 開発チーム 組織と人の成長戦略 (Compass Booksシリーズ) 作者:David Loftesness,Alexander Grosseマイナビ出版Amazon めちゃくちゃ良かった！この本では、組織のスケールで重要な局面を採用・人事管理・組織・文化・コミュニケーションの5つとし、それぞれに対して何を気をつけるべきかについてまとめてくれている。特に自分の興味と合致する「採用」「組織」の部分は本当に参考になった。例えば
VSCodeでrubocopを使って自動フォーマットをしているのだが、フォーマットが本当に遅くてめちゃ困っていたのが完全に解決して感動したので記事だけ共有。 dev.to formatに3秒くらいかかっててマジつらい...って感じだったのが1秒未満とかになったので本当に最高。 Before After
OSS活動とか仕事をしてる時に、PRをチェックアウトするのだるいなと思っていた。そこで「今いるレポジトリのPR一覧をmodified順に出力し、pecoで選択したものをcheckout」出来たら便利だろうということで作った。 できたもの やり方 まずhubとpecoをインストールしておく。 zshを使っているならこんな感じで定義し、 function peco-git-recent-pull-requests () { local selected_pr_number=$(hub pr list --limit 40 --sort updated --format "%pC%>(8)%i%Creset %t (by @%au)%n" | peco | sed -r 's/^ +#([0-9]+).*$/\1/') if [ -n "$selected_pr_number" ]; then
開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって本当に必要なものを作り続けるにはどうしたら良いのか考えている。その一環として「ユニコーン企業のひみつ」を読んだ。 ユニコーン企業のひみつ ―Spotifyで学んだソフトウェアづくりと働き方 作者:Jonathan RasmussonオライリージャパンAmazon スケールするための重要なポイントについて非常によく学べた。書いてあることを自分の中で咀嚼して、スケールするためのSpotify流の方法を自分の言葉でまとめてみるとこんな感じ。 スクワッド・トライブ・チャプター・ギルド チームを、少人数の、職能横断で自律した、必要な権限を持った、自己組織化されたものにする 開発からメンテナンスまで一気通貫し、学びを蓄積できるように ミッションだけが設定されており、優先順位決めややり方は自分たちで決められる。長期的な視点にも立てる
今回は入社した会社の携わる業界理解ということで、「建設DX デジタルがもたらす建設産業のニューノーマル」を読んだ。 建設DX デジタルがもたらす建設産業のニューノーマル 作者:木村 駿日経BPAmazon この本からは、建設業がこれから5年ほどで直面する課題や、今後の建設業でのトレンド・新技術について学べた。特に業界課題を把握できたことは、顧客の本当の課題への理解の手助けになると思う。印象に残った or 自分の中の気付きは以下の点。 建設業がデジタル技術を大胆に取り入れなければ解決しない3つの時限爆弾 2024/4以降に建設業にも適用される時間外労働の上限規制 建設技能者（職人）の大量離職問題。14年度に343万人いたが、25年度までに109万人いなくなる 24年ごろからはゼネコンの技術者も一斉定年退職（バブル入社組） 建設業は「単品受注生産」「屋外生産」といった背景から、製造業と比べて生
「THE MODEL」読んだ - $shibayu36->blog;に引き続きSaaSを学ぼうということで、カスタマーサクセス──サブスクリプション時代に求められる「顧客の成功」10の原則を読んだ。なぜSaaSやサブスクリプションモデルではカスタマーサクセスが重要なのか、そもそもカスタマーサクセスとは何か、カスタマーサクセスがもたらすものは何か、カスタマーサクセスで追いかけるべき指標は何か、カスタマーサクセスを行う上で大切にすべき原則は何か、といった内容を学べた。 カスタマーサクセス――サブスクリプション時代に求められる「顧客の成功」10の原則 作者:ニック・メータ,ダン・スタインマン,リンカーン・マーフィー英治出版Amazon 特に印象に残ったのは以下の部分だった。 サブスクリプションモデルの浸透によって、たくさんの顧客に継続的に販売しなければならなくなり、カスタマーサクセスの重要性が増
SaaSをちゃんと学び直そうということでTHE MODELを読んだ。SaaSに関する営業活動のやり方全体を学べた。 THE MODEL（MarkeZine BOOKS） マーケティング・インサイドセールス・営業・カスタマーサクセスの共業プロセス 作者:福田 康隆翔泳社Amazon 以下の内容が個人的に印象に残った。 営業活動をマーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスマネージャーと顧客の状況ごとに分業するモデル 商談に至らないリード、失注、未フォローを再び商談化のプロセスへリサイクルする。ビジネスが続けば続くほど効果的となる 人間はグループに分けられると敵対しやすい。関係を良好化するには、接触回数増加・コミュニケーションの内容改善だけでは不足。共同で作業することによって達成可能な共通の目標が有効 読書メモ * あれば便利だが、なくても業務が回るものは、その必
2021/10/01から株式会社アンドパッドに入社しました。初めての転職なので緊張しているけれど、早めに馴染みたい。 andpad.co.jp 転職活動をしている中でいくつかオファーをもらっていたが、以下の理由で株式会社アンドパッドに入社を決めた。 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう 組織規模が急拡大していて、組織マネジメントの経験が深まりそう 採用フローがしっかりしていて、今後も良い人がどんどん入ってきそう 裏側よりの難しい課題をクラウドネイティブな設計で解決するタスクができそう これまでのエンジニア経験の中ではインフラ〜フロントまで全体的に触ってきたが、自分の中ではインフラ領域〜バックエンド領域の中間くらいのエンジニアリングに最もモチベーションが湧いていた。またクラウドネイティブな設計をもっとできる機会があればなあと思っていた。 このように考えてい
次のページ
このページを最初にブックマークしてみませんか？
『$shibayu36->blog;』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
