時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記
最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのこ
シェルのhistoryをクラウドに保存する取り組み - hitode909の日記
ある日zshの履歴が消えた悲しみからいくつか課題感を持っていた。 巨大な1ファイルにどんどん書いていくので、壊れたときの影響が大きい 追記方式なので、複数の端末で共有するためGitやDropboxなどに入れるとコンフリクトしやすい 履歴から取り出すときにどのディレクトリで実行したコマンドなのかわからない シェル履歴をファイルに書いて終わりという暮らしは数十年変わっていない。 履歴はクラウドサーバーに保存して、補完したいときにAPI経由で問い合わせるというアーキテクチャが良いと思ったので、作ってみた。 github.com コマンドの実行時 zshのフックを使って、コマンドの実行時に、実行したコマンドと$pwdをAPIにPOSTする Cloud Functionsが立っていて、送られたコマンドをCloud Datastoreに保存する Cloud FunctionsはGoogle製のAWS
チェックボックスを並べてお絵描きしたりアニメーションしたりする - hitode909の日記
チェックボックスは通常ユーザーの入力を得るためのものだけど，チェックボックスを並べてお絵描きしたりアニメーションしたりすると楽しそうと思ったのでやってみた． マイクジャックにヘッドフォンを差して叫んで録音したり，光線銃に受光センサーがついてたり，トイレが逆流したりするように，インプットとアウトプットが入れ替わるのは楽しい気がする． 簡単なやつ．xとyとステップ数を足して，4で割った余りが0ならチェックつける，みたいな感じ． 円が真ん中から広がっていくやつ．中華料理屋の光る看板とかこんな動きをしている気がする． 動きをブラウザで直接書けるようにしたやつ．[ [true, false], [false, true] ]みたいな構造を返す関数を書いて，それをevalして(ひどい)，trueのときチェックがつくようレンダリングしている．式がおかしいと背景が赤くなるシンタックスチェック機能つき(ev
querySelectorAllしてmapしたいとき[...すると短い - hitode909の日記
表示中のHTMLから情報を雑に抜き出して利用するため，ブラウザのデベロッパツールなどでquerySelectorAllしてmapしたい．しかし，querySelectorAllはNodeListを返すので，mapするにはArrayに変換する必要がある． NodeListをArrayに変換するときに短く書く方法ないですかって同僚に聞いたらいろいろ教えてもらえたのでメモ． Array.prototype.slice.callする オーソドックスな手法．昔からこれを書いていて，長くて困っていた．最近はアロー関数を使えるのでちょっと短くなったけど長い． Array.prototype.slice.call(document.querySelectorAll('a')).map(a => a.href) [].slice.callする Array.prototypeのかわりに[]で書く．ちょっと短い
きれいなコード - hitode909の日記
これまで、きれいなコード書くにはどうしたらいいか考えてたけど、そんなことではいけないと思った。 ソフトウェアとして意味があるためには、誰もこれまでに書いたことがない、すばらしい働きをするコードでないといけない。 めちゃくちゃいい働きをするコードができたら、あとできれいにすればよい。誰にでもきれいにできるような些細なところはほっといて、本質的に難しいところを解決したほうがいい。 どんなにコードがきれいでも、正しく動かなかったり、使用に耐えないくらい性能が低くてはしかたがない。また、普通に動くソフトウェアは世界中に普通にあるから、それを超えるすごい便利さとか、使いやすさとか、他にこんなのはないとか、なんかそういうのがないと、作る価値はないと思う。 ということを思った。最近難しいことをいろいろやってて、夕方にはくたびれてくる。そこそこいいけど、まだめちゃくちゃよくはないから、もう一声という感じ。
一つしかない想定で作ってあとから複数出現してめちゃくちゃになる - hitode909の日記
ソフトウェア作ってて，最初は一つしかない想定で作るけど，あとから複数出現することになって改修するのが大変，ということがある． 最悪サーバーサイド もう終了したサービスであったのが，ユーザーは自分のアイテムを飾れる部屋を1つ持てるという仕様だったのが，複数の部屋を切り替えられるようにして，部屋ごとに置けるアイテムのシリーズが変わって，シリーズごとにグリッドの細かさも変わるとか．とにかく大変で，全部のテーブルにあとからシリーズidを持たせたり，クラスメソッドで済んでたのをシリーズidを持つオブジェクトのメソッドにしたり，ORMのItemをRoomに渡すのをやめて，その層とは別に独立した画像合成用のItemとRoomを作ってやり取りするとか，最初からそうなってるときより大変なことになる． 最悪クライアントサイド クライアントサイドでも同じようなことはあって，HTML内に一つしか出現しない前提で作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
