タグ

ブックマーク / blog.sushi.money (5)

  • 歌詞の音階と実際の音がずれている曲が気になる - hitode909の日記

    ミ♭ファソの歌詞がドレミ、にくわえて、ファシ♭ソファの歌詞がソラシド これは前から知っていて、嫌だな、と思ってた。 ドド♯ド♯ド♯の歌詞がドレミファ はじめてのおつかいって昔あったよね、と話してたらイントロでドレミファドレミファって歌ってるのを発見してしまった。 サビではドレミファソラシドって言ってるけど音階はソラドレミファ♯ソなのでここは転調されてるのだと思えばギリギリ耐えられる。イントロのドレミファドレミファはきびしいと思う。 こういう曲だけを集めていつかDJデビューしたい。 ほかにこういう状態になっている曲を知ってたら教えてください。 そういえば、ヤマハ音楽教室で歌うドレミファソラファミレドは一致していてうれしい。すべての曲がこういう形になってほしいものですね。 追記 コメント欄で教えてもらえた。まとまってておもしろい。上記2曲はこの動画でも冒頭の2曲で、代表的な音ずれソングっぽい。

    歌詞の音階と実際の音がずれている曲が気になる - hitode909の日記
    tsucchi1022
    tsucchi1022 2021/09/10
    僕はこれ全然大丈夫なんだよな。。。音取りしてる時だとイラッとしそうだけど、普通に聞いてる分には気にならない
  • 開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記

    ふだんの開発では,稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている.どんな事を考えてやっているか記しておきます. フィーチャートグルを使う すべてのコードが番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で,フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり,フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で,実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに,ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の

    開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記
  • 気が狂った設計 - hitode909の日記

    大きめのこととか,自信のないところを触るときは,コード書く前に,こういう作戦考えてみたけどどうですかって聞いてみたり,こういうことやりたいんだけど一緒に考えませんかって,いっしょに話して設計考えたりするとよいと思う. 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので,未然に変な設計のままコード書いてしまうのを防げる. 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「(こんな実装は)有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う.我が社にはそんな強い言葉でレビュー書く人はいない. 我が社には,普段から強い言葉を発する人もいなくて,みんな物腰柔らかな変な言葉を話している. 言葉使いや文体は,ずっと過ごしてると同僚から移ったりするので,普段からそういう言葉を話していると,全体の雰囲気も悪くなりそ

    気が狂った設計 - hitode909の日記
  • YAPC::Asia Tokyo 2014でPerlの静的解析やリファクタリングについて喋りました - hitode909の日記

    Perlでソースコードを解析して数値を発見したらとりあえず倍にすることで滅茶苦茶なFizzBuzzを生成するといった活動を紹介しました. スライドは以下です.160枚くらいあるので見るの疲れそう. Perlの静的解析入門とPerlリファクタリングツールApp::PRTのご紹介 // Speaker Deck お知らせ 静的解析友達募集中です #yapcasia— 趣味はマリンスポーツです (@hitode909) 2014年8月30日

    YAPC::Asia Tokyo 2014でPerlの静的解析やリファクタリングについて喋りました - hitode909の日記
  • テスト書きすぎ問題 - hitode909の日記

    テスト書きすぎるとよくないって言ってる人がいた.DHHっていう人.作業時間の1/3以上テストしてたらおかしいとか,ActiveRecordのバリデーションなど,Railsの機能はテストしない,とか. Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で,テスト手抜き派の人に良い材料を与えてしまった.僕は意見ちがって,作業時間半分以上はテスト書いたりしてる. テストたくさん書くと,最初に書くときのコストは増える.けど,あとから読む時や,変更したい時には,読むだけだし,書くのも差分だけで良い.コード体を理解できれば,要らないテスト捨てるのは,落ちたのを消すだけだから簡単.あとで見て,テスト足りないと分かったときに,明文化されてない仕様からテストを補う

    テスト書きすぎ問題 - hitode909の日記
  • 1