タグ

ブックマーク / jinjor-labo.hatenablog.com (36)

  • 設計を考える時のメモ - ジンジャー研究室


    お仕事で Design Doc を書く前に色々整理するのだが、その作業をシンプルなフォーマットで効率化してみた。 やることは本当に簡単で、箇条書きに色をつけるだけ。 赤‥誰かに質問や相談をしないといけないところ 緑‥他の人のボールで待ち状態になっているところ 青‥自分で調べるところ 黒‥その他 設計を考える時、最初から全てのコードが頭の中に入っているわけではないので基本的には調査から入る。 その際、やるべきこと、分かったこと、分からないこと、気になったこと、不安なこと、全てを片っ端からメモっていく。 そうすると巨大な箇条書きのリストが出来上がるので、そこに上記の要領で色をつけていく。 まず﹁誰かに質問や相談をしないといけないところ﹂を赤文字にする。 こういう場合はどういう挙動になるのが正解？ ここはもっと良いデザインがあるんじゃないか 既存仕様がどうなってるのか分からん ここは一人で考えて
    設計を考える時のメモ - ジンジャー研究室

  • 優先順位が口癖になる危機感 - ジンジャー研究室


    開発サイクルの終盤に近づくと﹁今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう﹂という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。︵なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない︶ 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは3ヶ月後だ。そして3ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。3ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する
    優先順位が口癖になる危機感 - ジンジャー研究室

  • 極端なことを言っている時、何を考えているのか - ジンジャー研究室


    たまに極端なことを言ったりすることがある。 ﹁ぶっちゃけXって要らなくない？﹂ ﹁それならXしちゃえばいいんじゃないか﹂ そうしたら、ある日そこから議論が収集つかない方向にいってしまい、後になって﹁ああ、あれはそういう意図だったんですか。あんまり極端な物言いをされると拒否反応を起こすのでやめてください﹂のようなことを言われた。まあ会社なのでそこまで出鱈目なことは言っていなくて真面目に議論していたつもりだったのだが、なるほどそれで噛み合わなかったのかと妙に納得してしまった。 色々考えているうちに、自分がそういう極端なことを言っている時に何を考えているのか整理したくなった。 自分の中の常識や思い込みを壊したい 長い時間をかけて自分の中に培われた常識や思い込みを、時に疑ったり真逆の思考をしてみたくなることがある。 例えば、ずっと静的型付き言語でやってきたのにいきなり﹁型なんて要る？﹂とか
    極端なことを言っている時、何を考えているのか - ジンジャー研究室

  • Cloudflare Workers + Durable Objects でホワイトボードを作ってみた - ジンジャー研究室


    Cloudflare の比較的新しい機能、 Durable Objects を使ってオンラインホワイトボードを作ってみた。 github.com エレベーターピッチ︵テンプレはこちらからお借りしました︶ - １秒で適当な概念図を描き始めて議論をしたい - ソフトウェア開発者向けの、 - Whiteboard というプロダクトは、 - オンライン共同編集アプリです。 - これは直感的かつ雑念の入る余地のない最低限の操作ができ、 - Google Jamboard とは違って、 - Slack コマンドから一瞬でログインできる仕組みが備わっている。 本当に Jamboard に勝ってるの？まあ、お遊びなので許して。 あと、今のところ組織内で使う想定だから自分でデプロイしないと使えないよ。 Durable Object を雑に紹介 ベータ版の公式のアナウンスが分かりやすい。エッジから状態を管理す
    Cloudflare Workers + Durable Objects でホワイトボードを作ってみた - ジンジャー研究室
    igrep
    igrep 2022/03/22
    すごい “エッジから状態を管理するオブジェクトにアクセスできる。各オブジェクトは JavaScript クラスのインスタンスで、それぞれ裏側にストレージを持てる。Workers KV と違って強い一貫性がある。”
    リンク

  • 負債展 - ジンジャー研究室

    技術的負債、色々あると思ったので並べてみた。 スピード重視負債「ビジネスが軌道に乗るまではスピード重視ね」 ビジネス要求の変化負債「頑張ってやってもらったけど、その機能もう要らないわ」 マーケティングの失敗負債「鳴り物入りでリリースしたのに誰も使ってくれない...」 要求分析失敗負債「この機能欲しいって言ってたよね...違うの...」 重要顧客負債「どうしても必要な機能だと言うので if 分岐で対応しますね...」 法改正負債「この実装だと今後はダメだって...」 上司の無理解負債「リファクタリングの時間が全然取れないんだけど...」 コーディング能力不足負債「なんで動いてるのか分からないけどヨシ...」 技術知識不足負債「そんな綺麗なやり方あったの知らなかった...」 怠惰負債「本当は共通化した方がいいけど、めんどくさいからやめた」 TODO 負債「// TODO: あとで時間がある時に

    負債展 - ジンジャー研究室

  • 得意なこと - ジンジャー研究室

    「あの人はなんでこんなに簡単なことができないんだろう」 と思った時、それは自分が得意なことであり自分の強みであると思った方がいい。 「やるだけなのに、やってない」 とかではないのだ。

    得意なこと - ジンジャー研究室
    igrep
    igrep 2021/03/25
    確かに。
    リンク

  • 速度との戦い - ジンジャー研究室


    オーディオプログラミングは速度との戦い。特にリアルタイム処理となると常にパフォーマンスを気にしていないとすぐに死んでしまう。 なぜなら、再生に間に合うようにデータを用意しないと音が途切れてしまうから。例えば、サンプリング周波数が 48000Hz だとすると1サンプルあたり 0.02ms で処理しないと再生速度に負ける。ステレオにして沢山エフェクトをくっつけて同時発音数を増やしてとやっているとすぐに超えてしまう。 このパフォーマンスチューニングが個人的には結構面白い。 お仕事は Web の主にフロントエンドなので、パフォーマンスを気にせず富豪的に処理しても大体なんとかなってしまう。例えば React とかは Virtual DOM を immutableに作っては捨ててというのを繰り返しているので、まあGCが頑張っているはず︵もちろんメモ化はできるけど︶。 しかし話がオーディオになると
    速度との戦い - ジンジャー研究室

  • 綺麗な矩形波を作る - ジンジャー研究室


    オーディオプログラミングをしていて、よくある矩形波の作り方は1と -1 を周期的に繰り返すというもの。 で、最近までなんの疑問も持たずにそれで実装していたんだけど、 FFT で周波数スペクトルを描いてみて気づいた。 なんか汚い。 いやいやまさかね、何かの間違いでしょと思ってよく耳を澄ますと、わずかに高音にブジジジィィィ...というノイズ混じりの音が聴こえる。気がする。耳より目を信じるミュージシャンなので、見た目がそうならきっとそう。 おかしいなと思って検索しまくったら、同じことを Stackoverflow で質問して自己解決している人がいて "Band-limited waveform" を使えば良さそうと書いてあった。 自分なりの解釈だと、真の矩形波はフーリエ級数展開すると無限の周波数までの足しあわせになるんだけど、実際のデジタル波形はナイキスト周波数︵サンプリング周波数の半分︶ま
    綺麗な矩形波を作る - ジンジャー研究室
    igrep
    igrep 2021/02/25
    リンク

  • TypeScript >= 4.1 の Template Literal Types を活用した引数パーサーを作ってみた - ジンジャー研究室


    ヘルプっぽいものを書くと文字列をパースして型をつけてくれる。 デフォルト値を指定すると T | null がTになったりする。 公開は今のところ GitHub Packages だけです︵メンテしなくていい方法を考え中︶ github.com 型レベルのパーサーはこちらの記事を大いに参考にしたというかパクりました。 (ネタ) TypeScript 型パズルで作るmini interpreter | by Yosuke Kurami | Medium こんなに本格的じゃないけど。 難しいなと思ったのは、せっかく型レベルでパースしてもその結果を値レベルの実装に利用できない点。 なので、型は型、値は値でそれぞれパースして最終的に辻褄が合うように実装しました。 それでは皆さま良いお年を。
    TypeScript >= 4.1 の Template Literal Types を活用した引数パーサーを作ってみた - ジンジャー研究室

  • すごいコード - ジンジャー研究室


    OSS とかのコードを巡っていると、時々﹁すごいコード﹂に出会うことがある。 もちろん﹁すごい﹂と言っても色々な凄さがあって、﹁読みやすくメンテしやすいコード﹂とか﹁技術的に凄いことをしている﹂とか﹁最新のライブラリを上手く使っているコード﹂はもちろんそうなのだが、それ以上に﹁圧倒される﹂コードがある。 全部頭に入ってる人が一気に書いたコードって、なんか見て分かるよね。また出会った。— Yosuke Torii / ジンジャー (@jinjor) 2020年9月18日 凡人の発想と違うことがあり、一見して読みにくく取っつきにくいこともあるが、そういう感想はすぐに吹き飛んでしまう。 その特徴を思いつくままに列挙してみる。 癖があるが終始一貫した書き方 世に出回っているベストプラクティスに則っていない フォーマッターを使っていない 細かいユーティリティ関数がない 初手で完璧に近い 静的型でない
    すごいコード - ジンジャー研究室
    igrep
    igrep 2020/09/25
    リンク

  • 関数型言語 Faust で wasm な AudioWorkletNode を一瞬で作るサンプル - ジンジャー研究室


    Faust って何 faust.grame.fr 音声信号処理に特化した言語というか DSL です。次のような短い記述でサクッとシンセ が作れます。 import("stdfaust.lib"); freq = hslider("freq",200,50,1000,0.01); gain = hslider("gain",0.5,0,0.5,0.01); gate = button("gate"); process = os.sawtooth(freq) * gain * gate; 簡潔、素晴らしい。 UIも定義できますが十分に抽象的なので見た目は完全にカスタマイズできます。 Faust については次の記事が詳しいです。qiita.com AudioNode を吐き出す コンパイルターゲットの一つに wasm があり Web Audio API の AudioNode を作ってくれま
    関数型言語 Faust で wasm な AudioWorkletNode を一瞬で作るサンプル - ジンジャー研究室
    igrep
    igrep 2020/03/05
    リンク

  • Custom Elements を正しく実装するのはとても難しい - ジンジャー研究室


    React みたいなコンポーネント作る系フレームワークだと思って Custom Elements を使おうとすると、たちまち死んでしまう。まだ色々試している最中なのでアウトプットはないんだけど、とりあえず今考えてることを書いておく。役立たないし刺されたら困るからポエム宣言しとこうか。ポエムです。 Custom Elements やっていきたい Custom Elements の良さは特定のフレームワークに依存しないところだと思う。例えば React とか Vue とかだとそれぞれのフレームワークの世界にどっぷり浸かってしまい互換性がないが、 Custom Elements ならば普通の要素の延長線上でどこに持って行っても使える。npm とか使わなくても script タグで CDN とかから持ってくればすぐに動く。夢のよう。もちろん、データフローはアプリケーション固有のものになるだろうか
    Custom Elements を正しく実装するのはとても難しい - ジンジャー研究室

  • Nim v1.0 で簡単なツールを作ってみた - ジンジャー研究室

    The wait is over. Nim v1 is here. 👑https://t.co/fTmnaC0e1q pic.twitter.com/u6oIhF6QaH— Nim language (@nim_lang) September 23, 2019 Nim 今朝たまたまこんなツイートが流れてきて、聞いたことある言語だったので気になって触ってみた。 見たところ、静的型付けで文法も結構親しみやすい感じ。その上パフォーマンスが良いとか。ひょっとしてこれから来る言語なのでは。知らんけど。解説は先駆者の記事とか読んでください。最近の言語かと思ったら初登場が 2008 とからしくて意外と歴史を積み重ねてる。 お題を考える やるからには何か意味のあるものを作らないとつまらないので、お題を考える。 せっかくだから何か役に立つものをとお題を考えたんだけど、ソース中の TODO 見つけてその関連

    Nim v1.0 で簡単なツールを作ってみた - ジンジャー研究室
    igrep
    igrep 2019/09/28
    リンク

  • CSS フレームワークを使いたくない - ジンジャー研究室


    CSS フレームワークが辛い。 ここでいう CSS フレームワークとは Bootstrap とか Bulma とかそういうやつのことである。昔から自分はこういうのが苦手で、一定の便利さは感じつつもどうしても馴染めないという状態が続いていて、それでも﹁それは使い方が悪いだけで、ちゃんと使いこなせばペイするんだろう﹂と思って今までズルズル使ってきてしまったのだが、やっぱりそれでもどうしても辛くなり脱フレームワークしようと思う。 もちろん使いこなせる人には使いこなせるんだろうし﹁使うべきでない！﹂という主張をするつもりはない。頭のいい人には使えるんだろう。昔は﹁今すぐ〜すべき10の理由﹂みたいなことを適当に書いてたんだけど、どうせ自分がやってることは﹁ Web 系﹂のメインストリームからは外れてるんだろうし、合わせるつもりもなければ合わせさせるつもりでもない。使う理由も使わない理由も人それぞ
    CSS フレームワークを使いたくない - ジンジャー研究室
    igrep
    igrep 2019/03/14
    自分も正直避けてたけど、複数人での保守性とか考えたら入れるべきなんだろうな...
    リンク

  • Elm 本書きました - ジンジャー研究室


    Elm の本を書いていました。 基礎からわかる Elm 実は 2017 年時点で Amazon に存在していたのですが﹁出した直後に Elm がバージョンアップして紙くずになりました﹂という事態をどうしても避けたかったので 0.19 が出るのをひたすら待ってました。0.18 から半年くらいで出るだろうと踏んでいたんですが、蓋を開けたら1年半経ってました。実際バージョンアップで elm-make が elm make に、 elm-package.json が elm.json に、 elm-lang/* が elm/* に、toString が Debug.toString や String.fromInt に、Html.program が Browser.element に、と色々変わってしまったので、あの時点で出していたら本当に紙くずになってましたね。 内容 Elm は公式ガイドがかな
    Elm 本書きました - ジンジャー研究室
    igrep
    igrep 2019/02/26
    🎉
    リンク

  • JavaScript フレームワークを巡った話 - ジンジャー研究室


    ポエムです。 自分の今の立場としては﹁Elm の人﹂ということになってるんだけど、どういう変遷でここまできて今どういうスタンスなのかっていうのはあんまり話す機会がない。だから整理のために考えてることを書いていくよ、というのがこの記事の趣旨。 非 Web の立場から そもそも自分は﹁Web 系﹂の出身ではない。新卒入社したワークスでは ERP パッケージを提供するのに画面を Web 技術で作ってるというだけで、別に SEO の順位を競ったり広告をどうという話ではないし、瞬時に画面が表示されないと離脱率が〜という話でもない。ただ、画面はとにかく複雑で設定項目とががうじゃうじゃある。 あと、学生時代に PCに触れたのが Windows で﹁黒画面なにそれ美味しいの？﹂くらいに GUI に染まりきってたというのがある。工学系の研究を効率化するために C# で GUI を作ってたら、なんかソフトウ
    JavaScript フレームワークを巡った話 - ジンジャー研究室

  • GISC : Scaffolding のネタを Git のリポジトリから取ってくるツール作った - ジンジャー研究室


    github.com GitHub の適当なリポジトリを Scaffolding の元ネタに使っちゃおうぜ というツールを作った。Git で Scaffolding なので GISC。大文字でも小文字でも可。giscという名前にしたら disc っぽかったのでそういうロゴにした。ちなみにロゴは会社帰りに iPhone のメモアプリで描いた︵便利！︶。 使い方 インストール。npm install -g gisc jinjor/giscリポジトリの example ディレクトリをコピって my-project を作る。デフォルトだとサーバーが github.com 、プロトコルは https 、ブランチは master 。 depth は常に1。キャッシュはしない。 gisc get jinjor/gisc example my-project これでもまだ長いので alias
    GISC : Scaffolding のネタを Git のリポジトリから取ってくるツール作った - ジンジャー研究室
    igrep
    igrep 2018/11/08
    リンク

  • Elm で不正な JSON に厳しすぎる問題についてのメモ - ジンジャー研究室


    長いだけで中身は単なる雑なメモなので、結論や主張はないです。 起こりうる問題 Elm で、サーバーがおかしな JSON を返してきた時にエラーが発生してアプリが止まることがある。一般的にはシステム境界でエラーが分かるのは嬉しいのだが、不寛容すぎると問題を起こしうる。 これは JavaScript とかだと起こらない問題で、 Elm とかだと起こりうる。例えば、{ name: string } みたいな API だとして {} が来た時に ﹁nameがない！﹂とエラーになる可能性がある。これを デコードエラー と呼ぶ。それが本番で運用した時に問題にならないか、という話。確率は低そうだが考えておいて損はなさそう。 Elm 以外も含めて言語別に見ると、JSの場合、プロパティが null や undefined でも構わず処理を続け、運悪く当たるとぬるぽになる。型が違った場合は適当に処理される
    Elm で不正な JSON に厳しすぎる問題についてのメモ - ジンジャー研究室
    igrep
    igrep 2018/10/31
    リンク

  • 画像の差分を見つけるツールを作った - ジンジャー研究室

    作ったのは大分前なんだけど、想定するユースケースで実際に使えそうだと確認できたので。 作ったもの github.com 動機 デザイナーから新しいカンプをもらった時にどこが変わったのか分かりにくかった 作った機能をレビューしらもらう時にスクショのどこが変わったのか分かりにくかった 微妙なところ 完成度はぶっちゃけ高くないというか、自分の用途のために使う MVP 的なやつなので最低限しかできない。 具体的には、 遅い PNG のみ 上下にずれると全部変わったことになる 遅いのはアルゴリズムが愚直なのもあるけど、せめてファイル変わってない時は checksum 取るくらいの対策はしたい。 最後のは改善したかったけど蓋を開けたらそういう修正はほとんどなかったというか、あってもあまり問題にならなかったので放置。 ところで画像差分検知と言えばもっと有名なのがあるので、ちゃんとしたやつを使いたい人はこ

    画像の差分を見つけるツールを作った - ジンジャー研究室
    igrep
    igrep 2018/09/07
    リンク

  • Elm 0.19 の主な変更点 - ジンジャー研究室

    祝 Elm 0.19 リリース！ https://elm-lang.org/blog/small-assets-without-the-headache New version of @elmlang out today! Compiler generates small assets by default. Just add the --optimize flag!https://t.co/N1Mkbv0OzC pic.twitter.com/PXyQMlYY31— Evan Czaplicki (@czaplic) 2018年8月21日 １年半ウォッチしていたので覚えている範囲で書いてみる。 追記 ↓ここに全部書いてあるじゃん。というか上の記事からリンクされてたし、この記事いらないじゃん。 github.com コンパイルが速くなった タプルで大量にパターンマッチした時に遅くなる件も改

    Elm 0.19 の主な変更点 - ジンジャー研究室
    igrep
    igrep 2018/08/24
    相変わらずどんどん機能を削ってるなぁ。
    リンク
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.