はてなブックマーク

僕のRubyKaigiを終わらせるために、参加者としての日記を書きます。 一日目 新宿駅からあずさで松本へ向かいました。 研鑽Rubyを読んだり、車窓を楽しんだりしました。 私も研鑽します pic.twitter.com/NLdrgWloic— ぎゃばん@手洗い (@ledsun) 2023年5月10日 山梨県には葡萄畑がたくさんある pic.twitter.com/2zQgImCS2z— ぎゃばん@手洗い (@ledsun) 2023年5月10日 天気がよく、山がかっこいい pic.twitter.com/OZJNsNGdFI— ぎゃばん@手洗い (@ledsun) 2023年5月10日 松本駅に着いたらお蕎麦を食べて腹ごしらえをしました。 会場に向かってMatzのキーノートを聞きます。 2001年のデンマークのJAOOで、当時インターンでPHPプログラマーをやっていたDHHと出会ってい

僕と僕の所属する会社はRubyでの受託開発を生業にしています。 ここ数年は引き合いが多くて営業で困ったことがありません。 技術力を評価していただいている面もあると思いますが。 Rubyが魅力あふれるプログラミング言語で、お金を払ってでもRubyでアプリケーションを作りたい人が、世の中にたくさんいるので成り立っています。 Ruby言語の父、まつもとゆきひろさんいわく「Rubyを作っているのはコミュニティー」であるそうです。 つぎのようなコントリビュートを待っているそうです。 ブログで記事を書こう バグレポートしよう https://bugs.ruby-lang.org/ で、機能をリクエストしよう 8割はリジェクトされます バグをなおしましょう githubでPRをうけつけています 新機能のPRは、https://bugs.ruby-lang.org/ で議論して追加する決定をしないと、取り

rubykaigi.org みんなが大好きな咳さんの発表です。 druby.hatenablog.com ご本人のブログに記事があります。 発表資料もこちらから見れます。 「検索エンジンを作りました。」という発表です。 全文検索をやろうとすると、たいてい次のような課題をクリアしないと着手できません。 namazuで分かち書きしましょう 表現の揺らぎを標準化しましょう ポケモンカードゲームだとこの部分が終わっているので、いきなり検索の実装の話に入れとのことでした。 いつも通り目の付け所が面白いです。 ポケモンカードゲームのデッキ検索エンジンをつくるには、デッキの類似度を決める必要があります。 類似度は、デッキの特徴を表現するベクトルを作って内積を計算すれば数値に出来ます。 数値にすると大小がきまるので、あるデッキに似たデッキが見つかります。 デッキのベクトルをどうやって決めるのでしょうか？

sumim.hatenablog.com の追試です。 複数のRuby実装で速さの違いを比べてみます。 スクリプト require 'benchmark' def tak(x, y, z) if x > y then tak(tak(x-1, y, z), tak(y-1, z, x), tak(z-1, x, y)) else y end end Benchmark.bm do |x| x.report do tak(14, 7, 0) end end Ruby 3.1.2preview2 ledsun@MSI:~/tarai►ruby -v tarai.rb ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] user system total real 15.766919 0.000000 15.766919 (

この文章は祈りです。 主にRuby on Railsアプリケーションを想定した話です。 Ruby on Railsアプリケーションでは、Fat Model問題という問題が起きることがあります。 ドメインオブジェクトが肥大化しメンテナンスしにくくなる問題です。 Fat Model問題に対応するためにサービスレイヤーを導入することがあります。 「ドメインモデル貧血症」と呼ばれているアンチパターンです。 ドメインモデル貧血症 ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。 Fat Modelを恐れよ Fat Modelは「単一責任原則」を満たしていないモデルです。 単一責任原則 | プログラマが知るべき97のこと 1つのサブシステムやモジュール、クラス、関数などに

RomeプロジェクトのJavaScriptフォーマッターがリリースされました。 rome.tools ちょうどPrettier を使っているプロジェクトがあったので比較してみました。 本当にめちゃくちゃ速い。 prettierで8秒掛かるのが0.5秒とかで終わる。— ぎゃばん@手洗い (@ledsun) April 6, 2022 prettierを速く動かしたくてparallel-prettierに.prettierignoreを読む修正を加えて動かして速くなったか - Qiita でNode.jsのまま並列化したparallel-prettierを試したときは やったね1.25倍速くなりました！ でした。 それと比べてるとRomeは10倍以上速くなっています。 驚異的です。 JavaScriptパーサーやASTを扱うライブラリーなどの資産がないrustで書き直すのは、大変な労力に思えま

僕がNode.jsを熱心に勉強していた頃に、スーパープログラマとして憧れていた人たちが、今何をやっているのか調べてみました。 github.com Express.jsなんかを作っていたtjは、Go言語がメインに書いているようです。 OSS活動自体あまりやっていなさそうです。 github.com Browserifyをつくっていたsubstackは、主にrustを書いているようです。 サーバーを書いていた人はGo言語に、CLIを書いていた人がrustに行くのかもしれません。 github.com Babelを書いていたsebmckもrustです。 github.com Rad VaggはGo言語とPythonのようです。 github.com tjfontaineはOSS活動がほとんど無くなっています。 ここからはNode.jsを去っていない人たちです。 github.com Guill

WSLのデフォルトのShellはBashです。 Bashだと履歴検索などが不便なので、Macで使っていたfish shellをインストールします。 fish shell - 3.x release series : “Fish shell maintainers” team sudo apt-add-repository ppa:fish-shell/release-3 sudo apt-get update sudo apt-get install fish デフォルトシェルをfishに変更 WSLでお手軽にオシャレfish環境構築 - Qiita fishをdefault shellへ設定 $ chsh Password: Changing the login shell for sugi Enter the new value, or press ENTER for the defa

world.hey.com DHHからご神託がありました。 僕の理解は次の通りです。 一番のオススメはHotwireとimport maps。HEY（Gmailクローン）も作れるし大抵のWebアプリケーションはこれでいける JavaScriptをバンドルしたい人はesbuild/rolllup/webpackの好きなものを使えばいい。Rails環境にインストールするためのコマンドは用意したよ。とくにこだわりがないならesbuildがオススメ 引き続きAPIモードもあるので、フロントエンド開発とバックエンド開発を完全に分離したい人は、APIモードを使ってね あと気になるのは There’ll be an alpha release of Rails 7 out shortly, and we intend to celebrate the final release before year

Webアプリケーションのテストに使う端末を決定するために、最初はruby -e 'p %w(iPad Firefox Android).sample'とランダムで値を返していました。 使っていると、ランダムよりは順番がよいと感じました。 また、順番も前回使った端末を覚えていて、その次から実行できると嬉しいです。 そして作ったのが、このスクリプトです。 script = File.read(__FILE__).split("__END__\n").first value = DATA.gets puts value File.open(__FILE__, 'w') do _1.write script _1.write "__END__\n" _1.write DATA.read _1.write value end __END__ iPad Firefox Android 実行すると次のよ

プログラミングが上達するのに、プログラミングする以外の方法はありません。 なるべくたくさんのプログラミング練習法を知っていて、 その時の自分の気分に合ったプログラミング練習法を使いわけて、 なるべく長い時間飽きずに、プログラミングを続ければ、スーパープログラマになれます。 練習法の名前は軽い気持ちでつけています。 かっこいい名前があれば教えて下さい。 練習法カタログ 写経 初めて使うプログラミング言語やライブラリをチュートリアルやGetting Startedに従い、自分の手で打って動作を確かめます。 未知の道具の典型的な使い方を体験します。 「デッサン」のようなものです。 説明を読んでもチンプンカンプンなプログラミング言語やライブラリも、自分でプログラムを書いて動かしてみると、あっさりわかります。 初歩的なプログラムでも動くと楽しいものです。 チュートリアルはその趣旨から、手軽な例が多く

十行程度のプログラムが読めること プログラミング言語の文法を知っている 分岐とループを追いかけることができる 変数の状態変化を追いかけることができる 関数呼び出しを追いかけることができる 十行程度のプログラムを複数回書いたことがある プログラムを読んでプログラムの動的な振る舞いを想像できる プログラムの主な処理の結果を想像できる 主な処理の終了条件がわかる プログラムから主な処理を読み取れる 似たようなプログラムを書いて、動かしたことがある 既知のプログラムと読んでいるプログラムの違いがわかる イディオムを知っている イディオムを書いたことがある プログラムがどう動くか知っている 重複したソースコードを関数に抽出できる 重複したソースコードがわかる 同じ入力と出力をもつコードブロックがわかる コードブロック単位で入出力を比較できる プログラムのある機能がソースコードのどの部分に依存している

現状は次の記事に非常にリアルに書かれていると思います。 www.megamouth.info 現状わかったから、じゃあ、どうしようか？という話を書きます。 今回扱わない話 適性ミスマッチについては扱いません。 新卒でIT企業に開発職で入ってみたが、プログラマが向いていないと気づいたときの話です。 これはメンバーシップ型雇用の欠点なので、1企業がどうこうする話ではないので、扱いません。 特に規模の小さな会社では、他の職種への転換が難しいです。 かといって、今すぐジョブ型雇用に転換できるかといえば、新卒の職業訓練する機関が足りてないので難しそうです。 DIVE INTO CODE | プログラミングスクール のような企業が増え、競争によって洗練されると違うのかもしれません*1。 社内教育 ブートキャンプ 現在では、私が新卒であった2002年頃に比べ、ブートキャンプ的な新入社員研修の効率はかなり

結論 要約 背景 本文 MVCが考えられた時代 PDSとMVC 現代Webフロントエンドの複雑さ PDS適用の困難さ PDSの放棄とプレゼンテーションモデル 結論 宣伝 結論 fluxのstoreは、（意味があって）「プレゼンテーションとドメインの分離」（PDS）に則っていないので、MVCのモデルではありません。 要約 MVCが考えられた時代では、プレゼンテーションロジックとドメインロジックが同等、もしくはドメインロジックの方が多かったです。その場合、PDSが有効でした。 現代のWebフロントエンドでは、プレゼンテーションロジックの方が圧倒的に多いです。プレゼンテーションロジックが9割ということも珍しくありません。この場合は、PDSは役に立ちません。 プレゼンテーションロジックの中で状態を持つ部分と、画面を描画する部分を分離する方が合理的に分割できます。この分離された「プレゼンテーションロ

techbookfest.org モチベーション これを解消したくて「現代Webフロントエンドデザインパターン」書いているけど、とてもSPA/SSRまではたどりつかない。（それ以前の部分で、僕の書く同人誌としては、十分のボリュームになっている。） https://t.co/BSMQwPRxfP— ぎゃばん＠技術書典4 か-20 (@ledsun) 2018年4月16日 Webフロントエンドの技術は、なかなか必要な状況や解決したい問題が明確にされないまま「流行っているからこの技術が良い」みたいな選択されることが大いように思っています。 もちろん、「新しくてかっこいい技術を使いたい」というモチベーションで新しい技術に取り組むのは良いのです。 それはそうとして、うまくマッチしない問題に適用してみて「イマイチな技術だ」っていう感想を抱いたり、 あれもこれも流行っているのに「どれにも自分は手を出せて

エンジニアの採用面接対策 - @ledsun blog 技術的なことについて自学自習できる人を見抜くコツが知りたい。簡単なテストをしてもあまり無意味な気もするし、めちゃくちゃ勉強はできるけど、仕事に全く活かせないorスピード感を掴めない人もいるし。2018/02/02 07:56 b.hatena.ne.jp 技術的なことについて自学自習できる人を見抜くコツが知りたい。 面接中に確実に見抜く方法はないという前提で、 「現職で、仕事に関する調べものを、仕事以外の時間でしたかどうか」を聞くといいのではないかと思います。 本当に欲しいのは、現在の自社の業務の周辺知識ではなく、将来ぶつかる問題を（自力である程度）調べる能力かと思います。 （労働者に要求していいのかは法的に微妙ですが）「仕事に対して、要求された以上に興味をもって試したり調べたりして欲しい」のだと思います。 「現職では、業務内容に興味

paiza.hatenablog.com に、面接で落とした理由があります。 最近は技術者が面接をすることが多いです。 技術者は採用面接に不慣れなことが多く、質問が下手くそです。 面接官側の不手際で、コミュニケーションに齟齬があって落ちていることもあると思います。 自分の採用面接経験での「こういうことが聞きたかったんだよ」という辺りを書きます。 実践すれば面接に受かることを保証するものではありません。 1位：自己表現(プレゼンテーション)力 職務経歴を聞かれて、一から十まで細かく説明しようとする人 面接の最初にお互いの緊張をほぐすために、自己紹介をしてほしくて使います。 面接官がどっから本題に入っていいのかわからないので、とりあえず聞いてみます。 30秒〜1分くらいで、簡単に説明してもらえれば良いです。 内容よりは、喋り方を見ています。 評価をするためよりは、これから会話をして行くときに「

github.com 動機 virtual-domの良さ Reactに代表されるようにGitHub - Matt-Esch/virtual-dom: A Virtual DOM and diffing algorithmを使うと、デザイン変更時に、JavaScriptのロジックを考えずに、HTMLとCSSを考えるだけよくなることがわかっています。 一方でvirtual-domはGitHub - hyperhype/hyperscript: Create HyperText with JavaScript.形式のAST（抽象構文木）を自分で作る必要があります。そこでReactではIntroducing JSX - Reactという新しい記法を作って、HTMLライクに記述できる様にしました。 JSXの悪さ JSXには２つ問題があります。 HTMLではない Babel · The compile

「忍者式テストの定義が知りたい」という意見を観測しました。 実践者の一人として、現時点の理解を記録します。 簡単に言うと？ どういうときに向いている？ どうやって実施する？ 準備 最新のプロダクトをユーザー（の立場）で操作できる環境 手動テスト項目 毎日の作業時間（数分 〜 1時間） 嬉しさ 小さなテスト手順書から始められる 発見がある テスト手順に対して プロダクトに対して 新しいバグ バグを埋め込んでから発見するまでの時間が短い 何ではないの？ 歴史 その他の参考情報 名前 おまけ 簡単に言うと？ 忍者式テストは、手動テスト手法の１つです。 開発者が、日々のテスト実施を通して テスト項目 ユーザーとしての視点 テスターとしての視点 を育てていく手法です。 どういうときに向いている？ ユーザーインターフェースのテスト プロジェクトに参加したての時 プロダクトの目的、機能をよく知らない プ

みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは？ おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや

プロジェクトを燃やした経験から、どうすれば有効なふりかえりができるのか考えてみました。 要約 失敗プロジェクト参加者の信用を回復 失敗プロジェクトの撤退戦術を共有 失敗プロジェクトの回避方法を検討 背景 「社内の失敗プロジェクトを振り返って今後に活かそう」みたいな会があったので失敗のポイントを明確にすべく張り切って他のPMに質問しまくってたら「そんな傷口を抉るようなことするな」と怒られが発生したので人間界には主旨はなく気持ちだけがあると悟った回。— モーくん (@calfscalf) 2017年5月9日 を見て考えました。 外野から見たら、確かにまったくこう見えると思います。 なぜ、傷口を抉るようなことをするなと言いたい「気持ち」になるのでしょうか？ 失敗プロジェクトの当事者の立場 デスマると、渦中の人は如何にして心を折らずに終戦までもっていくかがんばっている。社内からは、あいつらのせいで

サマリ 謎のモチベーションの高まりにより技術同人誌を書いた 30部が1.5時間ではけた Re:VIEWで書いた 想定読者が勉強会の発表より広いのはおもしろい 書いたこと 「デバッグ最速理論」という薄い本を書きました。 最終的に表紙と奥付、裏表紙等を合わせて16ページになりました。 原稿はこんなです。 当初の野望は カラー表紙 32ページ オフセット（？）印刷 でした。 3月の執筆時間が思っていたより取れなかったので、執筆時間をギリギリまで稼ぐためにコピー本に倒しました。 深夜に、コピー機でガッションガッション印刷して、ホッチキスでバッチンバッチン留めて作りました。 「デバッグ最速理論」自体は、今のところ16ページで十分表現できています。 もうちょっとデバッグ初心者や非技術者に間口を広げようと思ったら、ページ数を増やして 導入章を増やしたり、図表を増やした方がいい気はします。 部数について

ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ

d.hatena.ne.jp 椎葉さんの発表がぐっときた すごかった。 「失敗したチームメンバーがいた時に、笑ったらいかんよ」と説明すると言っていました。 「そこまでやるのか。やると意味があるのは想像できるけど、自分ではできない」という意味ですごかったです。 懇親会で聞いてみました。 実際の説明はもう少し丁寧に「悪気がなくても、思っているのとは違う伝わりかたをするので気をつけてね」 とするそうです。 なんでそこまでやるのか？ 「自分が抜けた後も、走る続けられるチームを作りたい」からだそうです。 自分とは立場が違うので無理して真似る必要はなさそうです。 （「チョットデキル人に訊け！」の話題と関係しています。） track8さんの発表が面白かった 想像できない使用環境に起因するバグをどうやって想像すればよいのか？という話でした。 純粋に楽しめました。 「チョットデキル人に訊け！」が興味深い 「