自動テストの「開拓」と「慣れ」 - ジンジャー研究室
自動テストを書くべきだということに異を唱える人は居ないと思うが、実際の現場ではあれこれと理由をつけて省略されがちだ。あれこれと言っても理由はひっくるめると一つで「コスト」だ。そう、テストを書くのはコストが高い。本当だろうか。 コストが高いとは言いつつ、何故かテスティング・トロフィーの両端はそこそこ頑張っていたりする。型検査とかリントは当たり前のように入れている現場が多いし、一気通貫でテストしたいときは Playwright で E2E テストを書く。あとは申し訳程度にユーティリティ関数にユニットテストが書かれている。しかし、最も重要とされるトロフィーの真ん中あたりはなかなかテストが増えなかったりする。 なぜそこにテストを書かないのか。仕事なので「コストが高いから」と答えるが、「腰が重いから」というのが本音である。じゃあ何故そんなに腰が重いのかというと、個人的な感覚では「どう書けば良いのかパ
設計を考える時のメモ - ジンジャー研究室
お仕事で Design Doc を書く前に色々整理するのだが、その作業をシンプルなフォーマットで効率化してみた。 やることは本当に簡単で、箇条書きに色をつけるだけ。 赤：誰かに質問や相談をしないといけないところ 緑：他の人のボールで待ち状態になっているところ 青：自分で調べるところ 黒：その他 設計を考える時、最初から全てのコードが頭の中に入っているわけではないので基本的には調査から入る。 その際、やるべきこと、分かったこと、分からないこと、気になったこと、不安なこと、全てを片っ端からメモっていく。 そうすると巨大な箇条書きのリストが出来上がるので、そこに上記の要領で色をつけていく。 まず「誰かに質問や相談をしないといけないところ」を赤文字にする。 こういう場合はどういう挙動になるのが正解？ ここはもっと良いデザインがあるんじゃないか 既存仕様がどうなってるのか分からん ここは一人で考えて
優先順位が口癖になる危機感 - ジンジャー研究室
開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない） 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する
2023 年、改めて React と Elm Architecture を比較する - ジンジャー研究室
最近 React のドキュメントが新しくなったということで読んでみた。第一印象としては、とにかく懇切丁寧で React というか JavaScript すら初心者という読者でも基礎的な考え方が身に付くようになっている。ただ、深い内容まで読み進めると「同じ Virtual DOM のフレームワークでも Elm とだいぶ違うな」と改めて思った。 これはどちらが良いとか悪いということではなく、一長一短あると思う。筆者は長いこと Elm を使ってきたが React も嫌いではなく、趣味を含め色々な場面で重宝している。ただ、 Elm Architecture の提供するシンプルな仕組みには依然として価値があると思っており、それがあまり世の中に知られていないのが勿体無い。というのが、この記事を書こうと思った動機である。 昔は「部分的に取り入れても Elm メリットは享受できないから Elm やってよ」
極端なことを言っている時、何を考えているのか - ジンジャー研究室
たまに極端なことを言ったりすることがある。 「ぶっちゃけ X って要らなくない？」 「それなら X しちゃえばいいんじゃないか」 そうしたら、ある日そこから議論が収集つかない方向にいってしまい、後になって「ああ、あれはそういう意図だったんですか。あんまり極端な物言いをされると拒否反応を起こすのでやめてください」のようなことを言われた。まあ会社なのでそこまで出鱈目なことは言っていなくて真面目に議論していたつもりだったのだが、なるほどそれで噛み合わなかったのかと妙に納得してしまった。 色々考えているうちに、自分がそういう極端なことを言っている時に何を考えているのか整理したくなった。 自分の中の常識や思い込みを壊したい 長い時間をかけて自分の中に培われた常識や思い込みを、時に疑ったり真逆の思考をしてみたくなることがある。 例えば、ずっと静的型付き言語でやってきたのにいきなり「型なんて要る？」とか
Cloudflare Workers + Durable Objects でホワイトボードを作ってみた - ジンジャー研究室
Cloudflare の比較的新しい機能、 Durable Objects を使ってオンラインホワイトボードを作ってみた。 github.com エレベーターピッチ（テンプレはこちらからお借りしました） - １秒で適当な概念図を描き始めて議論をしたい - ソフトウェア開発者向けの、 - Whiteboard というプロダクトは、 - オンライン共同編集アプリです。 - これは直感的かつ雑念の入る余地のない最低限の操作ができ、 - Google Jamboard とは違って、 - Slack コマンドから一瞬でログインできる仕組みが備わっている。 本当に Jamboard に勝ってるの？まあ、お遊びなので許して。 あと、今のところ組織内で使う想定だから自分でデプロイしないと使えないよ。 Durable Object を雑に紹介 ベータ版の公式のアナウンスが分かりやすい。エッジから状態を管理す
自分のやりたいことを正確に把握するのは難しい - ジンジャー研究室
キャリアの話になると、学生に向けて「自分の本当にやりたいことに向き合いましょう」というメッセージが発せられることが多い。それに対する学生側のよくある悩みは「やりたいことが見つかりません」「やりたいことがよく分かりません」というものだ。その様子を見ていて「やりたいことなんて考えなくても常にあるし簡単じゃん」と思ってたんだけど、最近は「本当にやりたいことを把握するのはめちゃくちゃ難しい」と思っている。 以下は個人的な話で、キャリアというよりは趣味レベルの話だけど、それでも難しいと感じている。 他人のやりたいことの影響を受ける 例えば SNS に、個人で Web サービスを作っている人とか、 OSS に貢献している人とかがいると、なんとなく自分もそれがやりたいような気持ちになってしまう。実際に Web サービスを作り始めてみると、ある程度動くようになったところでふと「よく考えたら別に Web サ
紙にタスクを書くのが便利 - ジンジャー研究室
抱えているタスクが増えてパンク寸前だったので、紙に書き出して PC の横に置いておいたら神ツールだった。紙だけに。 着手してるタスクが増えすぎて紙にリスト作ってるけど、なにこの便利ツール。— Yosuke Torii / ジンジャー (@jinjor) 2020年10月15日 タスク管理に便利なツールは色々存在していて、専用のツールもあるし、開発する機能やバグであれば GitHub の Issue にすればいいし、複数のリポジトリを跨がる場合はプロジェクト機能もある。Slack でプライベートなチャンネルを作っておいてそこに書き留めておくこともできる。あとは Spread Sheet でもいいし、他にもタスクを管理できるツールは山ほどあるのだが、このようなデジタルなソリューションには共通して「アプリを開いて見に行かないといけない」という弱点があり、これが地味にめんどくさい。 何か作業をして
すごいコード - ジンジャー研究室
OSS とかのコードを巡っていると、時々「すごいコード」に出会うことがある。 もちろん「すごい」と言っても色々な凄さがあって、「読みやすくメンテしやすいコード」とか「技術的に凄いことをしている」とか「最新のライブラリを上手く使っているコード」はもちろんそうなのだが、それ以上に「圧倒される」コードがある。 全部頭に入ってる人が一気に書いたコードって、なんか見て分かるよね。また出会った。— Yosuke Torii / ジンジャー (@jinjor) 2020年9月18日 凡人の発想と違うことがあり、一見して読みにくく取っつきにくいこともあるが、そういう感想はすぐに吹き飛んでしまう。 その特徴を思いつくままに列挙してみる。 癖があるが終始一貫した書き方 世に出回っているベストプラクティスに則っていない フォーマッターを使っていない 細かいユーティリティ関数がない 初手で完璧に近い 静的型でない
Netlify Functions + FaunaDB 使ってみた - ジンジャー研究室
aws-cdk と Netlify Functions どっちやろうか迷う。— Yosuke Torii / ジンジャー (@jinjor) 2019年9月1日 個人開発でサクッと何か作りたいとき、 Heroku みたいに手軽に「git push はいリリース」なノリのやつがあると便利なんだけど Heroku は無料だと半日寝てるし東京に居ないしアドオンも少しまともに使うと値段が跳ね上がる。ので、なんか良い代替がないかなと探していたら、 Netlify Functions というものを見つけた。静的コンテンツなら Netlify が便利なのは言うまでもないとして、サーバーサイドも何か書きたいときにはこれを使って AWS Lambda を動かせると言うことらしい。従量課金でお金も節約できそう？というわけで、やってみた。 以下、「何も情報がないよりはマシだろう」程度のメモ。日記なので技術記事だ
CSS フレームワークを使いたくない - ジンジャー研究室
CSS フレームワークが辛い。 ここでいう CSS フレームワークとは Bootstrap とか Bulma とかそういうやつのことである。昔から自分はこういうのが苦手で、一定の便利さは感じつつもどうしても馴染めないという状態が続いていて、それでも「それは使い方が悪いだけで、ちゃんと使いこなせばペイするんだろう」と思って今までズルズル使ってきてしまったのだが、やっぱりそれでもどうしても辛くなり脱フレームワークしようと思う。 もちろん使いこなせる人には使いこなせるんだろうし「使うべきでない！」という主張をするつもりはない。頭のいい人には使えるんだろう。昔は「今すぐ〜すべき 10 の理由」みたいなことを適当に書いてたんだけど、どうせ自分がやってることは「 Web 系」のメインストリームからは外れてるんだろうし、合わせるつもりもなければ合わせさせるつもりでもない。使う理由も使わない理由も人それぞ
Elm 本書きました - ジンジャー研究室
Elm の本を書いていました。 基礎からわかる Elm 実は 2017 年時点で Amazon に存在していたのですが「出した直後に Elm がバージョンアップして紙くずになりました」という事態をどうしても避けたかったので 0.19 が出るのをひたすら待ってました。0.18 から半年くらいで出るだろうと踏んでいたんですが、蓋を開けたら１年半経ってました。実際バージョンアップで elm-make が elm make に、 elm-package.json が elm.json に、 elm-lang/* が elm/* に、toString が Debug.toString や String.fromInt に、Html.program が Browser.element に、と色々変わってしまったので、あの時点で出していたら本当に紙くずになってましたね。 内容 Elm は公式ガイドがかな
JavaScript フレームワークを巡った話 - ジンジャー研究室
ポエムです。 自分の今の立場としては「Elm の人」ということになってるんだけど、どういう変遷でここまできて今どういうスタンスなのかっていうのはあんまり話す機会がない。だから整理のために考えてることを書いていくよ、というのがこの記事の趣旨。 非 Web の立場から そもそも自分は「Web 系」の出身ではない。新卒入社したワークスでは ERP パッケージを提供するのに画面を Web 技術で作ってるというだけで、別に SEO の順位を競ったり広告をどうという話ではないし、瞬時に画面が表示されないと離脱率が〜という話でもない。ただ、画面はとにかく複雑で設定項目とががうじゃうじゃある。 あと、学生時代に PC に触れたのが Windows で「黒画面なにそれ美味しいの？」くらいに GUI に染まりきってたというのがある。工学系の研究を効率化するために C# で GUI を作ってたら、なんかソフトウ
deno で Elm の live reload を作ってみた + 感想 - ジンジャー研究室
deno はこれ。 github.com Node.js 作った人が今度は TypeScript で作り直してるっていう話らしい。 yosuke-furukawa.hatenablog.com で、今はまだまだ実用段階ではないんだけど、一応それなりには動く模様。 ぜひ！私もコアには手を出せなそうなので、ユーティリティ書けたら書きたいなと思ってます。なにせTSファイル一つ書いてどこかにアップロードするだけなので気軽ですね— はっしゅろっく (@hashedrock) 2018年12月22日 まじで、置いとけば動くの。 うおー本当だ。なにこれ楽しい！ 試しに作ってみた github.com deno で Elm のライブリロード。 こんな感じで起動して、ソースの .elm ファイルを更新するとコンパイルしたついでに画面が更新される。 deno ../index.ts src/Main.elm
個人的によく使う npm ライブラリを紹介してみる - ジンジャー研究室
偏ってます。 もっと有名なのは沢山あるけど、自分が普段よく使うのじゃないと紹介できないので。 argv 引数をパースするやつ。 chalk 色をつけるやつ。 dotenv 環境変数をファイルから読むやつ。 fs-extra fs に欲しいけどないやつ。 watch ファイルを監視してコマンドを実行するやつ。 nodemon ファイルを監視してサーバーを再起動するやつ。 mocha テスト。 prettier フォーマッター。 puppeteer ヘッドレス Chrome 。 express サーバー。 passport OAuth 。 typescript TypeScript 。 elm Elm 。 npm Node.js 用のパッケージマネージャー。
puppeteer + express + mocha で快適 TDD している話（続編） - ジンジャー研究室
前回の記事の続き。 jinjor-labo.hatenablog.com 会社で開発中でオープンソース化していないテストツールがまたいくらか便利になったので進捗報告してみる。 ツールの概要は上の記事で説明しているけど、一言で言うと「mocha から puppeteer 叩いて express に届いたリクエストにアサーションをかける」ようなテストが楽に書ける。 前との差分 以下、前回より便利になったポイントを自慢していく。 API のカバレッジが取れるようになった API が一度でも叩かれたかどうかを調べて網羅率を見る。 テストが一通り終わった後、こういうのが出る。 [ OK ] GET /foo/foo [ OK ] PUT /foo/foo [ OK ] GET /bar/:barId/bar [ NG ] POST /bar/:barId/bar covered 3/4 ページのカバ
puppeteer + express + mocha で快適 TDD している話 - ジンジャー研究室
TDD という用語を使うとテストおじさんがやってきて、それはそうじゃないとか色々言い出すと思うんだけど、それが趣旨ではないので勘弁して欲しい。予防線ここまで。 Puppeteer でテスト Puppeteer が世間的にも個人的にもブームだ。ヘッドレス Chrome を操ってクローリングしたりスクリーンショットを撮ったり色々出来る。 github.com で、あれこれと遊んでいるうちにテストに使えるんじゃね？ということに気づいたので実践してみたら快適だったという話。ブラウザ操作してテストというのは昔から Selenium というのがあり、こちらはクロスブラウザで出来たりするんだけどまあ大掛かりでだるさを感じてしまう。メリットデメリットの比較はさておき、どうせならナウいやつを使ってみたい。よし使おう。 何をテストするか 普段から画面を見ながら開発しているので、どこに何が表示されているべきとい
スケーラブルなプログラミングのために何が必要か - ジンジャー研究室
Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した
海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方３つ - ジンジャー研究室
プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日本でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日本でも言及されても良いと思ったやつを３つ紹介。 Simple Made Easy Rich Hickey（Clojure言語の作者）による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい
Elm のパイプ |> の良さ - ジンジャー研究室
小ネタ。 JavaScript の [1,2,3].map(a => a + 1) が、 Elm だと [1,2,3] |> List.map (\a -> a + 1) で、両方とも左から右に読めるからそんなに変わらないなーと思ってたんだけど、一つ違う点に気づいた。JavaScript で Promise を気持ちよく連鎖してて書いてて、いざ並列実行しようとなった時に const promises = [1,2,3].map(a => a + 1).map(toPromise) Promise.all(promises) のように少し回りくどくなり、なぜ promises.all() と書けないのかと考えたら「配列にメソッドを追加するのが微妙だから」と気づいた（prototype 拡張で不可能ではない）。一般的に言うと既存の型に何か関数を追加できない。 Elm のパイプを使う場合、その制
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
