vscode-rdbg(debug.gem)でのRubyデバッグが便利すぎる - $shibayu36->blog;
最近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
Rails勉強し直している - Webアプリケーション編 - $shibayu36->blog;
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
妻が「私、痔主になりました」という本を出版しました - $shibayu36->blog;
妻が「ぢ 私、痔主になりました」という本を出版しました。 ぢ 私、痔主になりました 作者:てらいまき河出書房新社Amazon この本は著者が自分の痔の体験について、コメディっぽい作風で書いた本です。とにかく病院に行ったことが良いということが非常によく分かるのと、肛門科の先生の監修が入っており、先生へのインタビューも載っているので、痔の情報もちゃんと知ることができます。結婚する前後の話なのでキャラクターとして僕もむっちゃ出てきます。 手前味噌ですが、非常に笑える本になっていると思っています。興味がある人は是非購入していただけるとありがたいです！Kindle版もありますよ。 一話の試し読みは以下のサイトでできます。 teraimaki.hatenablog.com ちなみにちょっと前に京都の本も出していました。生粋の京都人の著者だからこそ紹介できる京都のコアな文化について書かれているので、京都
Macでdtrussを使ってシステムコールの実行時間を知る - $shibayu36->blog;
最近lsofを使ってportの利用状況をチェックしようとしたら、なぜか数秒固まるということが起こり、drussを使ってどこで止まっているか確かめたのでメモ。 dtrussというのは、簡単にいえばstraceのOSX版という感じ。どうやって使うかはOSXでもstraceしたい？よろしい、ならばdtrussだ - すがブロあたりをとりあえず見ると分かる。 ただ、単にdtrussを実行しただけだと、結局どこに時間がかかっていたのかよくわからなかった。manを見ていると、以下のようなオプションがあり、便利そうなので試してみた。 -e : それぞれのシステムコールの実行時間をmicrosecondsで出力する -d : コマンド開始からの実行時間をmicrosecondsで出力する とりあえず-eと-dオプション付きでlsofでどこに時間がかかっているか調べてみる。 $ sudo dtruss -e
目標と発達度によってリーダーシップを使い分ける - 「1分間リーダーシップ」読んだ - $shibayu36->blog;
チームでの自分の振る舞いを考えるために、1分間マネジメントシリーズの「1分間リーダーシップ」を読んだ。 1分間リーダーシップ―能力とヤル気に即した4つの実践指導法 作者:K.ブランチャードダイヤモンド社Amazon この本ではいくつかの種類のリーダーシップを状況によって使い分けると良いということについてフォーカスし、リーダーシップの使い方について言及されている。マネジャーになった時にリーダーシップは必要な技術なので参考になる。 この本で言いたいことは、その人の目標を決め、その人の目標に対する現在の発達度から、リーダーシップのスタイルを使い分けるべきである、ということ。それを言うためにその前提としていろいろなことを教えてくれている。マネジャーになった人なら参考になると思う。 目標と発達度によってリーダーシップを使い分けるというのが、これまでなかった観点だったので面白かったので、今回はそれにつ
Server::Starterから学ぶhot deployの仕組み - $shibayu36->blog;
以前http://tech.naver.jp/blog/?p=1369の記事を読んだのだけれど、それまでにprocessの知識が無かったりして、まったく理解できませんでした。そこでWorking with UNIX ProcessesやServer::Starterの中身を呼んでようやくhot deployの仕組みを理解できた(気になっている)ので、Server::Starterの実装を追いながら、それをまとめてみます。 hot deployとは hot deployとは「再起動の時にリクエストの処理を続けながら、変更の内容を反映するための手段」です。 通常serverをrestartさせるときは、stop -> startの流れになると思いますが、この場合stopしてから、start出来るまでの期間にリクエストを処理できない期間が発生します。その期間なしにdeployする仕組みがhot
ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->blog;
今回はドキュメントの場所をどうやって気づかせるかという話を書く。 ドキュメントがあるときの問題 以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;に書いたとおり、僕の意見としては 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う というものだった。 基本的には一番近いコメントにすると、見つけやすさ・更新しやすさともにある程度担保することが出来る。しかし、メインの部分が明確に決まらない*1いろんなパーツが関係しあう機能の場合は、ドキュメントを書かないと全体の概要が分からないということもある。このような時、ドキュメントを書いても結局そのドキュメントに気づかれないし、そのため更新されないとい
コードレビューを円滑に行いたい (#cross2014 のお話) - $shibayu36->blog;
id:antipopさんやid:studio3104さんに機会をもらえて、CROSS 2021に参加させてもらい、はてなでのレビューの話を軽くさせてもらった。はてなからは僕とid:hakobe932さんとで参加した。 http://blog.kentarok.org/entry/2014/01/18/204552 2014/1/17 #cross2014 コードレビューCROSS 〜ぶつかり稽古 2014初場所〜 - Togetter それで、今回参加して他の会社の人のレビューの話も聞いて、あーそれはあるあるとか、そういう問題解決するためにこういうことしてますとか、他の会社ではこういう時どうしているんだろとか、幾つかおもうところがあったので、もう少しレビューのことについて書いてみる。 レビューと関係性問題 レビュアーとレビュイーの関係に関して - 職質アンチパターン コードレビューと関係性
GitHubでの仕事を快適にするコマンドを紹介します - $shibayu36->blog;
趣味のプログラミングや仕事をgithubを使って行なっていると、「ちょっとこんなかんじの変更してみたんだけど、このcommit見てよ」とか、「このブランチのこのファイルちょっと見てくれない？」みたいなことがよく起こります。そういう時いちいちgithub上のページをポチポチ押して、URLを教えるみたいなことをやっているのが大変だったので、ターミナルからgithub上のページを開くコマンドを作ってみました。すでにこういうのあるかもしれません。 今回のコマンドで出来ること commitを指定してgithub上の該当commitページを開く HEAD^みたいな指定も出来る ファイル名を指定して現在のブランチのそのファイルのページを開く 行を指定してハイライトさせることも出来る それらのコマンドをエディタなどから使うことでさらに便利に使う openコマンドとperlに依存しているので、これらが使えな
Qudo, daemontools, capistranoを使ってWorker処理の仕組みを作る - $shibayu36->blog;
最近PrePANの開発を手伝っていて、Workerの仕組みをQudoで作りました。初めてWorkerの仕組みを一から作ったのでメモしておきます。 Worker処理に必要な部品、それぞれのQudoでの実装、Workerプロセスを管理するためのdaemontools、capistranoでのdeployという順番で書いていきます。 Workerとは ざっくり言うと非同期に色々実行するための仕組みです。perlだとTheSchwartz、Qudo、Jonkとかがあります。 Worker処理に必要な部品 今回作ってみて、Worker処理は大きく分けて次の三つくらいのものが必要だと分かりました。 ApplicationからJobをinsertする部分(Qudo) 実際のJobの処理(Qudo::Worker) Jobの実行を管理して、Jobに処理を委譲する部分(Qudo, Qudo::Paralle
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
rails 3でmemcachedを利用する - $shibayu36->blog;
Rails3を使っていて、memcachedを利用できるようにしたときのメモです。 memcachedを使えるようにconfigを設定する ローカル環境がすべてキャッシュを使うようになると不便なため、自分はdev_with_cachingという環境を作成しました。productionの場合もほぼ同じやり方でできるため省きます。 config/database.ymlに以下を追記。database.ymlは自分の環境に合わせてください。 dev_with_caching: adapter: mysql encoding: utf8 reconnect: false database: myapp_development pool: 5 username: root password: socket: /opt/local/var/run/mysql5/mysqld.sock config/e
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
