たまにDJしたくなる。
DJしてたのなんて、10年も昔の話です。
あの頃はホント夢中になってやっていたので、今の音楽の趣味は、ほぼあの頃のままだし、今もたまにムズムズと、MIXしたくなる。 誰のためでもなく、自分のために作ります。まとまったMIX CDを作りたくなる時は決まってて、ヤバい曲を聴いた瞬間です。
その瞬間、その曲の前後が思いついて、そしてその曲の前後が思いつく。 bpmと雰囲気が揃っていて、30分以上のカタマリになれば、繋げてみたくなって、PCを立ち上げる。 といった感じで作っております。
去年の12月に作ったコレは
映画「めがね」のサントラを聴いた時に作りたくなりました。これの1曲目ですね。
20141201 by Ryosuke Shimizu on Mixcloud
5月に作ったコレは
boogaloo / you gotta have freedom を聴いた時に作りたくなりました。これの4曲目ですね。
20150518 by Ryosuke Shimizu on Mixcloud
ファラオ・サンダ−スの名曲の生音カバーですよ。 2005年リリース、たしか友人がこれの12インチ見つけてくれて即買ったなあ。。。 と、思い出の一枚はどうやって手に入れた、という思い出まであるんです。
12月に作ったコレは
HNNY / Solsidan を聴いた時に作りたくなりました。これの7曲目ですね。
20151225 by Ryosuke Shimizu on Mixcloud
幻想的で、可愛くて、ミニマルな感じ。好きです、HNNY。
連絡ください
カフェとかだったら、よろこんでDJしたいっす。 あと、うちのカフェ用にMIX作ってよ、とかあれば連絡くださいー、 そういうの時々やってます。
開発効率・メンテナンス効率のいいCSSの設計思想とは_2
破綻しやすいCSS（その１）「HTMLの構造に依存している」
HTMLの変更と、それに合わせてCSSも変更になる場合。
MTHL
<article> <h1>Title</h1> <div> <p>article</p> </div> </article>
article h1 { border-bottom: 2px solid #000; margin-bottom: 1em; padding: 10px; font-size: 24px; font-weight: bold; }
もし、HTMLのarticleタグをdivに変更する場合、CSSも変更する場合があります。
そのため、あらかじめ次のようなclassを使ったマークアップで
MTHL
<article class="entry"> <h1 class="entry-title">Title</h1> <div class="entry-body"> <p>article</p> </div> </article>
あわせてCSSも
.entry-title { border-bottom: 2px solid #000; margin-bottom: 1em; padding: 10px; font-size: 24px; font-weight: bold; }
HTMLの構造に依存しない、classを使ったマークアップであれば、
もし、
- HTMLのarticleタグをdivに
- h1タグをh2に
変更しても、CSSを変更する必要がありません。
MTHL
<div class="entry"> <h2 class="entry-title">Title</h2> <div class="entry-body"> <p>article</p> </div> </div>
CSSは変わりません。
.entry-title { border-bottom: 2px solid #000; margin-bottom: 1em; padding: 10px; font-size: 24px; font-weight: bold; }
開発効率・メンテナンス効率のいいCSSの設計思想とは_1
よりよい設計のゴールとして、GoogleのエンジニアであるPhilip WaltonさんのBlogを引用すると。
- 予測しやすい事（Predictable）
- 再利用しやすい事（Reusable）
- 保守しやすい事（Maintainable）
- 拡張しやすい事（Scalable）
予測しやすい事
これは、思った通りの挙動であるか、という事です。他のルールが影響して、記述した通りの挙動にならない、または、追加したルールが他のルールに影響を与えないようにする事です。
再利用しやすい事
これは、抽象的で、機能ごとに分離されている必要がある事です。再利用しやすいルールを持つ事は重要です。
保守しやすい事
これは、新しいルールを追加・更新するときに、既存のルールのリファクタリング（修正）を必要としないことが大事です。
拡張しやすい事
これは、他の開発者の人が見たときに、CSS設計の学習コストは低くあるべきです。
参考文献
Ruby文法
ココに書かれたプログラムや説明文は
高橋 征義 (著), 後藤 裕蔵 (著), まつもと ゆきひろ (監修) (2013)"たのしいRuby 第4版" ソフトバンククリエイティブ
から引用しています。
_____________________________________________________________
配列の要素を全て表示したい
names = ["小林","林","高野","盛岡"] names.each do |n| puts n end
_____________________________________________________________
ハッシュの繰り返し
eachメソッドを使って、ハッシュのキーと値を１つづつ取り出し、全ての要素を処理する事ができる。配列の場合はインデックスの順だけど、ハッシュの場合は「キー」と「値」の組を取り出す事になる。
address = {name:"高橋",furigana:"タカハシ"}
address.each do |key, value|
puts "#{key}: #{value}"
end
_____________________________________________________________
正規表現とif文
配列中の「林」という文字を含む文字列だけを出力せよ。
names = ["小林","林","高野","森岡"] names.each do |name| if /林/ =~ name puts name end end
_____________________________________________________________
条件と真偽値
比較演算子以外で条件を表すメソッド、例えば文字列クラスのempty?メソッド。
文字列の長さが0の時にtrueを、そうでない時にfalseを返すメソッド。
上はtrueを返し、したはfalseを返す。
p "".empty? p "AAA".empty?
_____________________________________________________________
基本的な条件判断分。
変数に数字が入ったaとb、どちらが大きいかを判断するプログラム。
a = 10 b = 20 if a > b puts "aはbよりも大きい" elsif a < b puts "aはbよりも小さい" else puts "aとbは同じ" end
_____________________________________________________________
case文
比較したいオブジェクトが１つだけで、そのオブジェクトの値によって場合分けしたい場合。
case文を使うとシンプル。下記の例は、与えられたオブジェクトが文字列（Stringクラス）か、数値クラス（Numericクラス）か、あるいはどちらでもないかを判断して、結果を表示します。Whenに与えられたオブジェクトの種類で条件反している。
array = ["a",1,nil] array.each do |item| case item when String puts "item is String" when Numeric puts "item is Numeric" else puts "item is something" end end
好きだという事が何かの理由
師匠が言ってた。
好きなのに理由なんて無いだろ。
好きだという事が何かの理由なんだよ。
って、"好きだという事が何かの理由なんだよ。"
って、ちょっと意味分からんけど、
とても安心する言葉と思った。
なんか、多くの人が理由を求める人が多い気がする。
理由って、そんなにあるもんなのか？
