サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
blog.shibayu36.org
LLM、GPT界隈を追いかけていて、GPTの仕組みと限界についての考察(2.1) - conceptualizationという記事を見かけた。これを見たとき、「どういうことか全然理解できない」という気持ちになった。また、その他LLMの解説記事を理解できないことが多く、自分の機械学習知識不足が明確になった。 理解できなかったことは悔しいし、LLMやChatGPTをうまく使いこなすには最低限どのような原理で動いているか理解したいと感じた。そこで一歩目として「ゼロから作るDeep Learning」を完走した。 ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装 作者:斎藤 康毅オライリージャパンAmazon 知識なしからはじめたので時間はかかったが、次のように進めていった。 自分もコードを写経しながら読む レポジトリは https://github.co
長い文章を読むときに一旦要約を読んでから中身を深く読みたい時がある。そのような時にChatGPTを使って要約できると便利だ。しかしGPT-3.5を利用しているとトークン数上限は4096であり、大体4000文字を超えた文章を要約しようとするとエラーとなってしまう。今回はそのような時でも要約するスクリプトを書いたのでメモしておく。 できたもの STDINに入力した文章を要約するスクリプトを作った。 summarize-text.py たとえば締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;は4800文字程度の文章量がある。この長さだとインプット + 文章 + アウトプットの合計はトークン数の上限を超えてしまうため一度のAPIリクエストでは要約ができない。しかし、このスクリプトを通せばうまくやってくれる。 $ pbpaste | O
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
chat-hatenablogをpip installでインストール可能にした - $shibayu36->blog;にてchat-hatenablogをpip installできるようにするとき、ユーザー設定ファイルやデータをどこに配置するかに迷った。このツールでは、環境変数の設定として.envファイルを、ブログデータのインデックスとしてindex.pickleファイルを使っている。 これらのファイルの置き場所について少しだけ調べたので、現状分かったことをメモしておく。 まず選択肢としては二つありそうだった。 ~/.chat-hatenablog/.envと~/.chat-hatenablog/index.pickle 例) ~/.asdf、~/.docker、~/.gemなど XDG Base Directoryの仕様に沿って、~/.config/chat-hatenablog/.en
https://github.com/shibayu36/chat-hatenablog/releases/tag/v0.3.0 chat-hatenablog v0.3.0にてchat-hatenablogをpip installできるようにした。以下のようにすれば、GitHubから直接コマンドをインストールできる。 pip install git+https://github.com/shibayu36/chat-hatenablog.git この結果、current directoryをベースとして、index.pickleや.envを置くことはできなくなったため、配置場所を変えた。 ~/.chat-hatenablog/index.pickle ~/.chat-hatenablog/.env 今回の変更で、git cloneしてそのディレクトリで実行するといった面倒なことをする必要
全く初めての言語を扱うとき、その言語の一般的なやり方がわからないことが多い。これまでは書籍を読むことに加え、その言語をよく知る人に「どのレポジトリが参考になりますか?」と聞いて回り、参考になるレポジトリから一般的なやり方を理解していた。 ChatGPT(GPT-4)が出たことにより、ネット上の記事や参考レポジトリを調べ回らなくても一般的なやり方をChatGPTに直接聞くことができるようになった。一方で学習内容が2021/9までしかないため、その参考コードが古い情報を含んでいることが多い。 これらの問題を解決するため、ChatGPTに参考コードを出してもらった上で参考となるレポジトリもいくつか一緒に聞いてみると便利だった。今回はその紹介をする。 GitHub Actionsでpytestを動かしたいケース 例えばGitHub Actionsでpytestを動かしたいと考えた時、僕自身はPyt
【2023/04/18追記】現在、この記事で説明したものから使い方のインターフェースが変わっているので、実際に使うときは https://github.com/shibayu36/chat-hatenablog のREADME.mdを参考にしてください。 以下の記事を見て、もっと気軽に自分のはてなブログとチャットしたいなと思った。 自分のScrapboxをChatGPTにつないだ - 西尾泰和のScrapbox 自分のはてなブログをChat GPTにつないだ - hitode909の日記 ChatWP: WordPressをAI化しておしゃべりする そこで自分のはてなブログとチャットするツールを作ってみた。 https://github.com/shibayu36/chat-hatenablog やりたかったこと 僕はコードレビューでコメントする時、自分の意見を補足する目的で、参考となる自
最近ChatGPT周りを見ていて、自分のブログをChatGPTに繋いでブログが言いそうな回答を出してもらうという記事に興味を持った。 自分のScrapboxをChatGPTにつないだ - 西尾泰和のScrapbox 自分のはてなブログをChat GPTにつないだ - hitode909の日記 ChatWP: WordPressをAI化しておしゃべりする しかし、その仕組みが分からなかったため、自分で実際に動かしながら内容を理解してみたい。 ブログを読んだときに感じた疑問点 なぜembeddings APIを使って数値ベクトルを使うことで、そのブログが答えそうな回答を得ることができるのか。数値をプロンプトに入れても意味はなさそうだが、どのようにしているのか? まずは動かしてみる 自分もはてなブログを使っているので、https://blog.sushi.money/entry/2023/03/
久々のオフライン開催ということで、YAPC Kyoto 2023に参加してきた。 久々に大量の知り合いと話せて、とにかく楽しかった! YAPCは昔から参加していたので、大量の知り合いと久々に会えた。オンライン開催だと立ち話とかもあまりできなかったので、オフラインで「最近どうですか」から色々話せるのは楽しいんだなと思い出せた。 僕は、好きなことがある人が無限に最近やっている話をしてくれるのを聞くのが好きなので、カンファレンスで久々にそういう体験ができた。これだよこれ〜〜という気分になった。 前日祭の後も飲み会を開催したら10人くらいきてくれたり、その後はてなのオフィスに行ったらいろんな飲み会から集結して数十人くらいで集まれたのも楽しかったな〜。 本編で印象に残った話 ar_tamaさん あの日ハッカーに憧れた自分が、「ハッカーの呪縛」から解き放たれるまで - Speaker Deck 最近僕
最近Rubyを学び直したり、アルゴリズムの基礎練をしたりしているのだが、debug.gemおよびvscode-rdbgが便利すぎるので紹介。 debug.gemやvscode-rdbgとは debug.gem( https://github.com/ruby/debug )とは最近のRubyのモダンなdebugger。これまでlib/debug.rbやbyebug、debaseなどがあったが、それらのいくつかの課題を解決したdebuggerとなっている。Ruby 3.1 の debug.gem を自慢したい - クックパッド開発者ブログ に背景や基本的な使い方が詳しく載っている。 またRubyKaigi 2022のruby/debug - The best investment for your productivity - RubyKaigi 2022でも紹介された。Scriptable
最近は仕事ができない感から完全脱却してみる|牛尾 剛|noteに触発されて基本に戻ろうと思い、アルゴリズムの勉強をしている。今回は迷路の最短経路を幅優先探索で解くというのをやってみた。 やりたいこと 迷路を以下のような文字列で与えられたときに .#....#G .#.#.... ...#.##. #.##...# ...###.# .#.....# ...#.#.. S....... 最短経路の手数と、その経路を出力する。 16 .#****#G .#*#.*** .**#.##. #*##...# **.###.# *#.....# *..#.#.. S....... 実装 以下のように実装した。アルゴリズム理解のためなので再利用性や設計の綺麗さなどはあまり考えていない。 class SolveMaze VECTOR = [[0, 1], [0, -1], [1, 0], [-1, 0]
Rails勉強し直している - DB操作編 - $shibayu36->blog;に引き続きRailsを勉強し直している。今回はHatena-TextbookのWebアプリケーションの課題を通して学習した。 作ったもの diffはこの辺。ユーザーが存在する前提で、記事のCRUD処理を実装した。 今回学んだことを雑多に記録していく。 /:username/entries/:id のようなルーティングを作る方法 あるユーザーの記事一覧というURLを作るため、/:username/entries/:id というルーティングが作りたかった。gitlabのこの辺とかを参考にすると、scopeを使うと良さそうであった。 例えばこんな感じ。 scope '/users/:username' do resources :entries end またルーティングヘルパーにUserモデルを渡すだけで /use
基本に戻ろうと思い、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
次のページ
このページを最初にブックマークしてみませんか?
『$shibayu36->blog;』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く