子の泣いてる時間を観察したくてM5StickCで泣き声モニタを作った - hitode909の日記
深夜に絶叫する子を抱っこしていると、いつから泣いてるのか、いつまで泣いてるのか、など考えてしまって精神的に参ってくる。 実際のところどれくらいのペースで泣いてるのか可視化したくなって、M5StickCで可視化するグッズを作った。 作りたいもの 常時マイク入力がオンになっていて、直近しばらくの音量の履歴が可視化されたら便利そうだと考えた。 可視化によって子が泣き止むわけではなくても、「しばらく泣いてる気がしたけどまだ3分くらいだ」とか、「10分間に渡って静かにしていて偉い」とか数値を見て客観的な考察をできるようになりたい。 M5StickC M5StickCは小型のM5Stack。 小さくて邪魔にならなさそうなのと、マイクがついているので買ってみた。 3000円以下で買ってきて書いたコードが動いて画面に表示もできるのでおもしろいと思う。 www.switch-science.com 実装する
1画面1APIと比べるとGraphQLのAPIはどこから作ったらいいか分かりにくい - hitode909の日記
Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。 グラフをたどって開発することになる GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。 このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。 スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係
リモートワーク大全 - hitode909の日記
リモートワークでの働き化ががちゃんと定まってない、他社の事例を参考にしよう、という話があったので読んでみた。シックス・アパートの人たちのリモートワーク情報が載っている本。 文化が明文化されている 信頼、性善説に基づいて無駄を省こう、みたいな、主となる方針が明文化されているのが良いと思った。 リモートワークで暮らす上で、こっちとこっちなら、どっちが望ましい状態なんだっけ、というときに、毎回、個人で考えるんじゃなくて、ここに立ち返るとこっち、とすぐに判断できそうだし、そこは前提として議論が進むので楽そう。こういうものがないと、真に生産性が上がるのはどっち?とか、生産性上げたいんだっけ、それよりはこっちのほうが大事、とか、どこから議論を出発するか苦労することになる。 ちょっとしたTIPSがまとまっている YESともNOともとれる，曖昧な返事をやめよう、みたいな、ちょっとしたテクニックが載っていた
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
雑なVSCode拡張を作ろう #kyotoasterisk - hitode909の日記
プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる id:hitode909です．Kyoto.なんか #4 に飛び入りでLTするための資料です． VSCode拡張を作ろう ここ2ヶ月くらい早起きして作っている 友達作りのため様子を紹介 自己紹介 はてなで働いている Emacs→Atom→VSCode 練習 祝日を挿入するコマンド gyazo.com const holidayList = "元日 成人の日 建国記念の日 春分の日 昭和の日 憲法記念日 みどりの日 こどもの日 海の日 山の日 敬老の日 秋分の日 体育の日 文化の日 勤労感謝の日 天皇誕生日 元日 成人の日 建国記念の日 建国記念の日 振替休日 春分の日 昭和の日 昭和の日 振替休日 憲法記念日 みどりの日 こどもの日 海の日 山の日 敬老の日 秋分の日 秋分の日 振替休日 体育の日 文化の日 勤労感謝
人月の暗黙知の本 - hitode909の日記
見積りについて興味が出てきたので読んだ．コードコンプリートを書いたスティーブマコネルの本． 具体的な見積りの技法が紹介されているけど，それよりも，いい話がたくさん書いてあって良かった． 見積りとターゲット 見積り=作業量とか規模とか ターゲット=いつまでにほしいとか 数ヶ月後の発表会のための開発なら，その規模のものは作れませんではなく，間に合うような物を一緒に考える 技術的な知識を使っていろんな代案を出すのは技術者の責任 即興で見積りしてはいけない→正確ではない 専門家の判断は品質が低い→正確ではない 計算できるなら計算しなければならない 見積りに幅を持たせる この期間で終わる確率は何%とか，最良で何週間， 最低で何週間，とか そのときも計算する 高く見積るとプロジェクトが却下されるからといって安く見積ってはいけない 正しい情報を提供できないので，意思決定できなくなってしまう リソースが本
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
Reactビギナーズガイド読んでよかったところ - hitode909の日記
最初はJSXも使わず平易にスタートして，最終的にはワインを管理するアプリケーションを作る例が載っている． ビギナーズ向けだけど，おすすめテクニックが紹介されていて参考になった． よかったところ コンポーネントにコンポーネント名のクラスを付与する Buttonコンポーネントならclass="Button"をつけておく コンポーネントごとにCSSのファイルを分ける 管理しやすくなりそう コンポーネントのリストを見れるページを用意する ボタンとかダイアログとか，そういう単位での再利用がしやすくなる Flowについての章で，面倒だけど便利，という話 このように型をいちいち指定するのは面倒だと思われるかもしれません。しかし、受け渡しされる値について深く考える機会が与えられるというのは大きなメリットです。 僕も仕事でちょっとReact使っているけど，ふだんの使い道としては，JSで新しく凝ったことすると
FRONTEND CONFERENCE 2017に行ってきた - hitode909の日記
梅田でフロントエンドを学べるイベントをやってたので行ってきた． kfug.jp 向かってる このおもしろいビルで開催されていた．ふだん勘でHTMLやJSやCSSなど書いていたので，本気でやっている人の話を聞けるのがおもしろく，また，W3CとWHATWGの最新の動向を追いかけてる人から，スマートフォン向けのUI/UXの話まであって，話題も広くてよかった． 印象に残った話をいくつかメモ． ワイヤーフレームの話 Sketchを作ってUIのプロトタイプを作と，シンボルをネストしたりオーバーライドしたりして，パーツを再利用できる．全体として統一感のとれたデザインができる． このスライドもSketchで作られています，という話でおもしろかった．エンジニアから見るとKeynoteかHTMLで作ってしまいそう． HTMLのスナップショットの話 W3CとWHATWGの歴史13年分くらいを10分くらいでさらっ
なぜひどいコードを書いてはいけないか - hitode909の日記
ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な
DSLでAPIを書きたい!!APISchemaでらくらくAPI生活をはじめよう - hitode909の日記
この記事は，はてなエンジニアアドベントカレンダー2015の5日目です． 前日はこの記事でした．スクリーンショットで振り返る・はてなブログ記事編集画面デザインの歴史 - Hatena Developer Blog 最近作った(といっても去年から作っている…)，APISchemaというライブラリをご紹介します． APISchemaとは BMIを計算しよう スキーマを書こう メタデータ リソースの定義 エンドポイントの定義 スキーマを使う スキーマのパース ルーターを生成して，ルーティングをおこなう リクエストのバリデーションをおこなう レスポンスのバリデーションをおこなう APIのドキュメントを配信する 採用実績 関連 JSON Schema 便利グッズ まとめ APISchemaとは APISchemaは，DSLでHTTP APIの定義を書けるものです．以下のような機能を持っています． AP
fitbitのAPIから心拍数をとってきてツイートできてついでに心拍数ぴったりのBPMのYouTube動画を見れるウェブサービス作った - hitode909の日記
せっかくfitbitで心拍数を取ってるのに，友達に共有できないのはもったいない!!ということで，心拍数をツイートできるウェブサービス作った． heartbeatwonderland OAuthで認証して，心拍数を測るボタンを押すと，こういうツイートができる． 🙋💓 BPM83 https://t.co/vtfADFGlKu #heartbeatwonderland— 趣味はマリンスポーツです (@hitode909) 2015, 11月 29 BPMごとのページができて，心拍数にぴったりのYouTube動画を閲覧できて便利．心拍数が80といわれても，どんな雰囲気なのかよくわからないけど，BPMがぴったりの曲が流れると，さぼってるとか，がんばってるとか，そういう雰囲気が分かると思う． BPM73くらいだとおだやかなリラクゼーションという感じ． BPM73 - heartbeatwonde
ひどいソフトウェア作りたくなくて考えること - hitode909の日記
ソフトウェア作ってるとどうしようもないひどい状況になったり、知らないプロダクトを読んだらひどい状況になってたりすることがあって、どんなときにそういうことになるのか、必ずそうなるのか、そうなることを予見できないか、完成したソフトウェアを見てひどいかどうか判定できるか、とか気になってる。 作ってる途中に気付けないものか 作る前に気づけることはあるかひどいのは分かってるけどやるしかないときにだけひどいものができるのか時間はあるけどやる気がないとそうなるのかプライベートでなんかあるとそうなるのか書いてから時間が経つと大体のものはそうなるのかコードは正しくて読者が使われてるパターンに理解がないだけなのかパターンの使い方が変だと読めなくなるのか当時と環境、社会情勢や実行環境、データ量、などが変わってひどくなるのかいい技術が発明される前なのでしかたないのかいい技術が発明されたときにキャッチアップすべきか
70ページでドメイン駆動設計の要点を押さえられるDomain-Driven Design Reference - hitode909の日記
Domain-Driven Design Reference，Amazon見てたら発見して，安かったから買ってみた． ぺらっとしてて，ポケット索引集みたいな雰囲気．エリックエヴァンスのドメイン駆動設計から，要約が抜粋されていて，70ページくらいで，重要な概念を押さえられる．原著は著者の経験を語ってくれるコーナーが大半を占めるけど，この本ではバサッと切られて，定義だけが載ってる． 前の本から10年くらい経ったので，新しい内容も増えてる．ドメインイベントとパートナーシップ，巨大な泥団子．いずれも実践ドメイン駆動設計に出てきた． これだけ読んでドメイン駆動設計さあ始めよう，とはならないだろうけど，でかい本読みたくないけど議論には参加したい，とか，どんなものか軽く眺めたい，みたいな人が読むにはてっとり早いかもしれない． 唯一役立ったのが前書きで，エリックエヴァンスのドメイン駆動設計の本のことをTh
Emacsのウィンドウが勝手にびよんびよんなってたのしいやつ - hitode909の日記
Emacsのウィンドウが勝手にびよんびよんなってたのしいやつができたぞ!!! (run-with-timer 0 0.1 '(lambda () (set-frame-size (selected-frame) (floor (* 20 (+ (sin (* 2 (float-time))) 2))) (floor (* 10 (+ (cos (* 2 (float-time))) 2))) ))) これをscratchに貼るとびよんびよんなってたのしい．まったく仕事できない． 疲れてるときに便利です 疲れた!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!— 趣味はマリンスポーツです (@hitode909) 2015年9月3日
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
■ - hitode909の日記
今日テストなくてめちゃくちゃに壊れてるアプリケーションのテストを一から書いてて、わりと書けてよかった。午前中セットアップに手間取ってて、午後からテスト書き始めて、小さいアプリケーションだったのでC0 90%くらいまでいけた。3年間くらいテストないせいでびくびくみんな触っててめちゃくちゃに壊れててよくなかった。テストえいって書けば書けるんだから、隙を見て書いていきたい。ずっとテストのあるWebアプリケーション眺めてるのでだんだんコツが分かって気がする。まず最初にCIに載せて、カバレッジ測れるようにする。面倒だけど、これやっておくと後で役立つ。普通にテスト書くと、実行環境までは定められないけど、CIがあれば、そこをベースに議論できる。最初は、アプリケーションのルートのモジュールをuse_okするだけ、くらいでまず通して、カバレッジも取れるようにする。たとえば、MyAppっていうアプリケーション
設定のクラスを作るとすっきりしそう - hitode909の日記
設定のテストを書くとよいって言ってる人がいた． 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った． こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい． 個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか． like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"
ドメイン駆動設計読んだ - hitode909の日記
ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
