mixin とはオブジェクト指向プログラミング言語において、サブクラスによって継承されることにより機能を提供し、単体で動作することを意図しないクラスである。言語によっては、その言語でクラスや継承と呼ぶものとは別のシステムとして mixin がある場合もある(#バリエーションの節で詳述)。 オブジェクト指向プログラミングにおいて、継承は本来は特化を意図したものである。すなわち、継承する側(派生型)と継承される側(基底型)の間にはリスコフの置換原則があることを前提とする。 しかし実際のところは、実装の再利用のための手段として使われることが多い(濫用されがちであるが)。mixin における継承も、前述のような特化のためではなく、複数の機能を集めるための手段である。特にクラスの多重継承が可能なシステムでは、複数の mixin クラスを多重継承し、「単に複数の機能を持つクラス」を簡単に作る、というよ
LEDライトの特性として直進性が高く、光が拡散しにくいことが挙げられますが、液体シリコン(シリコーン)で電球内を満たすという独自開発した冷却システムで電球の温度を上げることなく光を290度の範囲まで広げることができるLED電球が「SWITCH」です。2012年にアメリカのEdison Awardsを受賞し製作の様子も公開されていたのですが、市販のLED電球とは見た目からして違うSWITCHが一体どんな感じの商品なのか気になったので、実際に購入して使ってみました。 液体冷却システム : SWITCH LED Bulbs for residential and commercial customers http://switchlighting.jp/ 左から60W形の一般電球に相当するSWITCH60、80W形の一般電球に相当するSWITCH80、100W形の一般電球に相当するSWITCH1
背景 レビューに時間を掛けているわりにあまり成果が出ていない 問題意識を感じる レビューという行為にもっと周りから理解があればいいのに、という風に考える 原因を外部に求めるのは良くないなと考え直す これまで自分が発言したコメントを読み返す 過度にフォーマル過ぎたり、コードの表層しか指摘していないところが多々あることが分かる 問題 GitHubのPull RequestやIssueでのコメントに、出来るだけ間違いや誤解が無いように気を付けられた丁寧な文章で書いてしまうことが多い。しかしながら、もっと普段互いに会話するときに使うような雑な言葉で書いて、コミュニケーションの量を増やした方が良いんだろうなと思う。 そもそもコミュニケーションの量が足りていないせいで、レビュアーがそのドメインについてあまり理解が得られず、問題の表面的な部分についてのみしか発言出来ないということが沢山ある。サービスごと
ピコピココード g=ppgraph B=ppscreen:size() Bw=B.width Bh=B.height tex=pptex:load("main.png") function set(p,d) local r r=ppsprite.new(tex) r:pos(p) r.d=d r.t=100 r:tile(2) r.idle=function(s) s:loopAnime(0.1,{2,3,4}) s:move(s.d) if not s.tane then s.d=s.d*0.98 end s.t=s.t-1 if s.t<0 then if s.tane then for j=1,5 do for i=1,360,15 do local x,y x=math.sin(i/180*math.pi) y=math.cos(i/180*math.pi) set(s,pppoi
海外出張の後の振り休で暇なので書いてみよう http://getlife.hateblo.jp/entry/2014/02/06/030300 こういう無知なおっさんが居るから、日本のIT業には魅力がないのだよなぁ、という印象 自分はプログラマというよりは、どちらかというと研究で飯を食ってる非SIのエンジニア このブログの著者のおっさんが言うところの、プラスアルファは手に入れてる側ではあるんでしょう 普通のプログラマであることでは、差別化が出来ないと考えたからこそ様々な挑戦を繰り返し 生き残るために研究開発というポジションについた 外資でも働いたし、海外でも勤務経験がある 分析役(SE、アプリケーションエンジニア、業務エンジニア、システムアーキテクトなど) 業務分析やシステム分析を行い、「何を作るべきか」を明確にするための分析役を担います。 実装役(コーダー、テスターなど) 実際に動くアプ
CIって? CIはContinuous Integration(継続的インテグレーション)の略です。 継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。 不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。 ちなみに、ソフトウェア開発手法のひとつである「エクストリームプログラミング」では、継続的インテグレー
24. ...... Lemma reduce_lemma : forall ctx (ctx' : seq (term * typ)) t ty, typing ([seq Some p.2 | p <- ctx'] ++ ctx) t ty -> Forall (fun p => reducible ctx p.1 p.2) ctx' -> reducible ctx (substitute_seq 0 [seq p.1 | p <- ctx'] t) ty. Proof. move => ctx ctx' t ty; elim: t ty ctx ctx'. - move => /= n ty ctx ctx'. rewrite /substitute_seqv typvar_seqindex subn0 size_map shiftzero. elim: ctx' n => [|
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く