最近、数年ぶりTOEICの新しい問題集を買った。
朝日新聞出版、加藤 優 (著)の「新TOEIC TEST 900点特急 パート5&6」
この「特急〜」シリーズは新書で値段が821￥と安い上に持ち運びも便利。
更に音声データが購入していない本も含めて無料でダウンロードできる。
と、かなりお得な本になっていると思った。
この「新TOEIC TEST 900点特急 パート5&6」は900レベルの難問を集めてあるので、全130問の中でも知らない事が多く効率的に勉強出来るような気がする。
また、解説も詳しく直接問題の解答とは関係ない部分の説明もあり、知識が増やせる。
単に問題を解くだけではなくて、下記の様な活用の仕方も冒頭に記載されていた。
選択肢を見ないで解答する。
問題文のスクリプト(巻末)の気になるところ全部伏字にした問題を自分で作成して解答する。
問題文の日本語から英語を英作文する。
音声データを聞く。リピーティング、シャドーイングする。
上記は他の問題集でも、英文の題材でも、英語以外でも適用できる方法。
ここまで出来たら結構勉強になるとは思うが、ちょっと面倒なので実施は腰が重い。。。
とりあえず問題を解く他には、気になったところ電子ファイルにメモしてそれを見直して復習する様にはして行きたい。
また、記憶術の要領で何も見ないでポイントとなっている所を記憶して思い出す練習も良いかもしれない。
これは手元に何も無くても復習が出来るので、隙間時間の有効活用には向いている気がする。
本の内容に話を戻すと、所々に書いてあるコラムの一つの「テクニックから脱却」という話が興味深かった。
TOEICでは選択肢の先読みや、空所の前後のみ先に読んで解答する等、色々と細かい受験テクニックがある。
ただ、レベル上がると普通に頭から全部問題文を読んで理解して、その後に設問を読んで答える方が高得点が取れると言う段階になるという事。
これは確かにそういう気がする。前回の1月の試験べ勉強の時から、設問を先に読むより兎に角問題文を頭から読む方が早い気がしてはいた。
TOEICでは英語の実運用能力を見るために、「一回の速読してどこまで内容を理解できるか？」を試している様なに思えてきた。
文法問題についても、「どの単語を当てはめるたら自然な英文と感じるか」を試しているような気がする。
まだ、完全にこれが出来るようにはなっていないが、なるべくたくさんの英語に触れるのが大切だと思った。
2014年6月30日月曜日
2014年6月27日金曜日
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (6th Virtual office hours)
==== W5A4 ====
weekrefrenceの中身は任意のタイミングでGCされている可能性がある。
したがって値がnullの場合も考慮すべき。
OutputTextViewInterfaceを使ってる。
mActivity.get().getSef()を使っている。
try/catchを使っている。
ifでnullチェックもしている。
何時GCされるかわからないから一時変数に入れずに1linerで書けと言っている。
?? こんなことはLectureでもforumでも議論されていなかった気がするが。。。??
?? これは改善されたAssignmentの答え?? another option??
nullチェックしていなくても点数は引かずにコメントを残せば良い。
done()もrunnableをactivityに送らないで、その場で実行している。
activityに送るのでも良いとは言っている。
try/catchはなし。
await()はtry/catchしているが不要と書いてある。
other solutionがある??
メモリーリークやweekreferenceの問題で途中で実装を変えたから?
自分の提出はこちらの方になっているがevaluationは大丈夫か??
他の人もこれでやっている??
改善版は後で終わってから出すと言っているので多分古いのでも大丈夫。
循環参照の対策としてweekreferenceを使う。
==== W6A5 ====
値のエラーチェックとか例外の処理とかは講義用にシンプルにしているのでやっていない。
@Overrideを付けている。
two way message
TODOが手元で見たよりもたくさんあるような気がするが、気のせい?
GeoNamesAppというexの配下にあるexampleの話も合った。色々見ている人もいるらしい。
thread pool serviceは手動で止める必要あるが、assignmentでは気にしない。
activityが何かの理由で途中でなくなるかも知れないからtry/catchしても良い。
really paranoidだが、実用上は悪くないidea
==== Etc. ====
問題で急遽VOHを別のシステム??で行ったらしい。
google plusのページから見ると質問内容も見れるので話が分かりやすい。
途中で実装を変えると混乱する。VOHでしか説明が無いので見るのが必須??
VOHは単に回答を示すだけではなくてそれ以上に改善された例を示している??
closureの話も合った。
weekrefrenceの中身は任意のタイミングでGCされている可能性がある。
したがって値がnullの場合も考慮すべき。
OutputTextViewInterfaceを使ってる。
mActivity.get().getSef()を使っている。
try/catchを使っている。
ifでnullチェックもしている。
何時GCされるかわからないから一時変数に入れずに1linerで書けと言っている。
?? こんなことはLectureでもforumでも議論されていなかった気がするが。。。??
?? これは改善されたAssignmentの答え?? another option??
nullチェックしていなくても点数は引かずにコメントを残せば良い。
done()もrunnableをactivityに送らないで、その場で実行している。
activityに送るのでも良いとは言っている。
try/catchはなし。
await()はtry/catchしているが不要と書いてある。
other solutionがある??
メモリーリークやweekreferenceの問題で途中で実装を変えたから?
自分の提出はこちらの方になっているがevaluationは大丈夫か??
他の人もこれでやっている??
改善版は後で終わってから出すと言っているので多分古いのでも大丈夫。
循環参照の対策としてweekreferenceを使う。
==== W6A5 ====
値のエラーチェックとか例外の処理とかは講義用にシンプルにしているのでやっていない。
@Overrideを付けている。
two way message
TODOが手元で見たよりもたくさんあるような気がするが、気のせい?
GeoNamesAppというexの配下にあるexampleの話も合った。色々見ている人もいるらしい。
thread pool serviceは手動で止める必要あるが、assignmentでは気にしない。
activityが何かの理由で途中でなくなるかも知れないからtry/catchしても良い。
really paranoidだが、実用上は悪くないidea
==== Etc. ====
問題で急遽VOHを別のシステム??で行ったらしい。
google plusのページから見ると質問内容も見れるので話が分かりやすい。
途中で実装を変えると混乱する。VOHでしか説明が無いので見るのが必須??
VOHは単に回答を示すだけではなくてそれ以上に改善された例を示している??
closureの話も合った。
2014年6月26日木曜日
Programming in Scala, First Edition: Chapter 23
23. For Expressions Revisited
forはmap,flatMap,filterの組み合わせと透過。
forの方がmap,flatMap,filterの組み合わせより読みやすい。
23.1 For expressions
for {
pat_g1 <- expr_g1 // 1st generator
pat_d2 = expr_g2 // 1st definition
if expr_f1 // 1st filter
pat_g2 <- expr_g2 // 2nd generator
...
} yield expr_y
for {
p <- persons // a generator
n = p.name // a definition
if (n startsWith "To") // a filter
} yield n
generator
exprはListを返す場合が多い。実際は後述の様により一般的なtypeが使える。
patはChapter 15のpattern matchingが使える。
matchしなかった場合はnoMatchErrorがthrowされる。
一番多いのは単に値 x <- expr とする場合。この場合は単にexprを走査するだけ。
definition
val pat = expr と同じ
一番多いのは単に値 x = expr とする場合。単に値を割り当てているだけ。
filter
exprはBooleanを返す。falseの場合はyieldや以降のgeneratorが実行されない。
ifの後の()は省略可能。(if expressionでは省略できない)
generator一つに対して、definition, filterは複数定義できる。
generator,definition,filterの組も複数定義出来る。
上のgeneratorの一つの要素に対して下のgenerator全体が実施される。
上のgeneratorが外側のループで、下のgeneratorが内側のループ
23.2 The n-queens problem
8-queens問題をNxNに一般化したn-queens問題の解法。
縦、横、斜めに重複しない様にn個のqueenを配置する問題。
forを使ったcombinatorial searchがポイント。
幅優先探索を使って全ての解を求める。
一行毎に制約を満たすような可能なqueenの配置をすべて求めていく。
再帰的なアルゴリズムになる事を示唆している。
新しい情報の追加はListの先頭に行うようにする。(stack)
def queens(n: Int): List[List[(Int, Int)]] = {
def placeQueens(k: Int): List[List[(Int, Int)]] =
if (k == 0) List(List())
else for {
queens <- placeQueens(k - 1)
column <- 1 to n; queen = (k, column); if isSafe(queen, queens)
} yield queen :: queens
placeQueens(n)
}
def isSafe(queen: (Int, Int), queens: List[(Int, Int)]) =
queens forall (q => !inCheck(queen, q))
def inCheck(q1: (Int, Int), q2: (Int, Int)) =
q1._1 == q2._1 || // same row, it can be removed.
q1._2 == q2._2 || // same column
(q1._1 - q2._1).abs == (q1._2 - q2._2).abs // on diagonal
23.3 Querying with for expressions
forの記法は本質的にはSQLの様なDBのqueryと同じ操作。
23.4 Translation of for expressions
forは下記で変換できる。compilerが変換している
一番内側のループはmap
外側のループはflatMap
if節はfilter
pattern matchingはcase
yieldなしのforについてはmap/flatMapの代わりにforeachに変換できる。
23.5 Going the other way
map,flatMap,filterをforに変換する事も出来る。
23.6 Generalizing for
map,flatMap,filter,foreachを実装しているdata typeならfor記法が使える。
ranges, iterators, streams, sets等。
自分で作ったdata typeも同じmethodを実装すればfor記法が使える。
4つ全てではなくて一部の実装でもOK
map: 一重ループ
mapとflatMap: 多重ループ
filter: filter
foreach: yieldなしの一重、多重ループ
for記法からmap等への変換は型チェックの前に行われる。
for記法そのものはチェックされず、変換後のにチェックされる。
forに対応しているclassの標準的なmethodのsignature
abstract class C[A] {
def map[B](f: A => B): C[B]
def flatMap[B](f: A => C[B]): C[B]
def filter(p: A => Boolean): C[A]
def foreach(b: A => Unit): Unit
}
monad
数多くの計算の型(type)を説明できるmonadと言う概念がある。
collections, state, I/O, backtracking等幅広い計算を扱える。
map,flatMap,filterとunit constructorで全てのmonadを特徴づけられる。
unit constructorはobject-oriented languageのfactory method。
monadのfunctional conceptのobject-oriented versionと捉えられる。
for記法は上記のmethodの適用と等しいので、monadのsyntaxと捉えられる。
for記法が単にcollectionを操作する以上の一般的な概念であると示唆している。
非同期I/Oでもfor記法が使える。
optional valuesの代替記法としても使える。
scalaライブラリのforが使用方法が参考になる。
23.7 Conclusion
** haskellのmonadのdo記法と同様なものと捉える事も出来る。
forはmap,flatMap,filterの組み合わせと透過。
forの方がmap,flatMap,filterの組み合わせより読みやすい。
23.1 For expressions
for {
pat_g1 <- expr_g1 // 1st generator
pat_d2 = expr_g2 // 1st definition
if expr_f1 // 1st filter
pat_g2 <- expr_g2 // 2nd generator
...
} yield expr_y
for {
p <- persons // a generator
n = p.name // a definition
if (n startsWith "To") // a filter
} yield n
generator
exprはListを返す場合が多い。実際は後述の様により一般的なtypeが使える。
patはChapter 15のpattern matchingが使える。
matchしなかった場合はnoMatchErrorがthrowされる。
一番多いのは単に値 x <- expr とする場合。この場合は単にexprを走査するだけ。
definition
val pat = expr と同じ
一番多いのは単に値 x = expr とする場合。単に値を割り当てているだけ。
filter
exprはBooleanを返す。falseの場合はyieldや以降のgeneratorが実行されない。
ifの後の()は省略可能。(if expressionでは省略できない)
generator一つに対して、definition, filterは複数定義できる。
generator,definition,filterの組も複数定義出来る。
上のgeneratorの一つの要素に対して下のgenerator全体が実施される。
上のgeneratorが外側のループで、下のgeneratorが内側のループ
23.2 The n-queens problem
8-queens問題をNxNに一般化したn-queens問題の解法。
縦、横、斜めに重複しない様にn個のqueenを配置する問題。
forを使ったcombinatorial searchがポイント。
幅優先探索を使って全ての解を求める。
一行毎に制約を満たすような可能なqueenの配置をすべて求めていく。
再帰的なアルゴリズムになる事を示唆している。
新しい情報の追加はListの先頭に行うようにする。(stack)
def queens(n: Int): List[List[(Int, Int)]] = {
def placeQueens(k: Int): List[List[(Int, Int)]] =
if (k == 0) List(List())
else for {
queens <- placeQueens(k - 1)
column <- 1 to n; queen = (k, column); if isSafe(queen, queens)
} yield queen :: queens
placeQueens(n)
}
def isSafe(queen: (Int, Int), queens: List[(Int, Int)]) =
queens forall (q => !inCheck(queen, q))
def inCheck(q1: (Int, Int), q2: (Int, Int)) =
q1._1 == q2._1 || // same row, it can be removed.
q1._2 == q2._2 || // same column
(q1._1 - q2._1).abs == (q1._2 - q2._2).abs // on diagonal
23.3 Querying with for expressions
forの記法は本質的にはSQLの様なDBのqueryと同じ操作。
23.4 Translation of for expressions
forは下記で変換できる。compilerが変換している
一番内側のループはmap
外側のループはflatMap
if節はfilter
pattern matchingはcase
yieldなしのforについてはmap/flatMapの代わりにforeachに変換できる。
23.5 Going the other way
map,flatMap,filterをforに変換する事も出来る。
23.6 Generalizing for
map,flatMap,filter,foreachを実装しているdata typeならfor記法が使える。
ranges, iterators, streams, sets等。
自分で作ったdata typeも同じmethodを実装すればfor記法が使える。
4つ全てではなくて一部の実装でもOK
map: 一重ループ
mapとflatMap: 多重ループ
filter: filter
foreach: yieldなしの一重、多重ループ
for記法からmap等への変換は型チェックの前に行われる。
for記法そのものはチェックされず、変換後のにチェックされる。
forに対応しているclassの標準的なmethodのsignature
abstract class C[A] {
def map[B](f: A => B): C[B]
def flatMap[B](f: A => C[B]): C[B]
def filter(p: A => Boolean): C[A]
def foreach(b: A => Unit): Unit
}
monad
数多くの計算の型(type)を説明できるmonadと言う概念がある。
collections, state, I/O, backtracking等幅広い計算を扱える。
map,flatMap,filterとunit constructorで全てのmonadを特徴づけられる。
unit constructorはobject-oriented languageのfactory method。
monadのfunctional conceptのobject-oriented versionと捉えられる。
for記法は上記のmethodの適用と等しいので、monadのsyntaxと捉えられる。
for記法が単にcollectionを操作する以上の一般的な概念であると示唆している。
非同期I/Oでもfor記法が使える。
optional valuesの代替記法としても使える。
scalaライブラリのforが使用方法が参考になる。
23.7 Conclusion
** haskellのmonadのdo記法と同様なものと捉える事も出来る。
2014年6月25日水曜日
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (Week 4)
==== Lecture ====
Section 1 Module 3 Part 6: The AsyncTask Framework (Part 1) (9:56)
[AsyncTask framework]
HaMeR: must understand pattern, lose connected
AsyncTask: strongly connected, handler, message, runnable等を理解しなくても使える。
public method: execute(), cancel(). アプリによって実行される。
protected method: onReExcecute, doInBackground等
hook methids overriddenで振る舞いを変える。
長くかかる処理をbackgroundで行う。UIの裏側など。UIを簡単にする。
cancel()の方が難しい。
frameworkの特徴: inversion control, Domein-specific, semi-complete
Section 1 Module 3 Part 7: The AsyncTask Framework (Part 2) (8:14)
[AsyncTask framework]
black-box framework: strategy, decorator, interfaceのみ知っていればよい。
white-box framework: template, state, 実装を知っている必要がある。
AsyncTaskのWhite-box elements: template(hook) mothods, sub classで実装。
AsyncTaskのBlac-box elements: strategyを渡すことでconfig出来る。
作りやすさと使いやすさのtrade-offs
Section 1 Module 3 Part 8: Programming with the Android Concurrency Frameworks (Part 1) (7:17)
[ThreadedDownload App]
HaMeR, AsyncTask
3 waysの実装方法を試す。
Posting & processing Runnables
Sending & handling Messages
Executing AsyncTasks
image URLを入力して、メニューボタンから処理を選んで、progress dialog、imageを表示。
Reset imageボタンも作る。
[Androidの3つのkey elements]
java source code
resource files: ボタンのアイコンデータ、UIのレイアウト、国際化文字列等。
manifest: xmlでapplicationの実行に必要な情報を定義する。
permissionやmain Activity(ThreadedDownload class)
UNレイアウトはmain.xmlで決める。処理を選ぶbuttonのhandler登録もここで行う。
ThreadedDownload AppのjavaのコードにUIのボタンなどをhard-configしなくて良い。
Section 1 Module 3 Part 9: Programming with the Android Concurrency Frameworks (Part 2) (13:10)
[ThreadedDownload App]
3つの手法の比較。
AsyncTaskは簡単で使いやすいが拡張性と効率は劣る。
Messageは拡張性、効率は上だが作るのが難しい。
Runnableは効率は良いが拡張性は低い?? 作りやすさは中間。
ダウンロードをbackgroundで行う。
イメージの表示は共通部品にする。
Benefits and Limitations of Patterns and Frameworks (Part 1) (25:00) [Optional Lecture]
Benefits and Limitations of Patterns and Frameworks (Part 2) (17:30) [Optional Lecture]
More Information on Patterns and Frameworks (11:30) [Optional Lecture]
==== Quiz ====
Lectureが4つだったので各2問で8問。
一回目は22/29, 2回目で満点だった。
==== Assignment ====
[Week-4-Assignment-3]
今週はPingPongでまたLectureの内容とはずれてた。
DownloadのAppは来週つくるのか??
FairとNon-Fairどちら? => 特に指定なし。non-fairで十分??
await()はtryするべき? => 呼出し元が割り込みを投げるので不要??
countDown()はtry不要? => non-blockingなので不要。
定数はfinal staticするべき? => TODOになってないから不要??
run,それともstart,join? => 例を見るとstartでjoinなし?
ping,pongどちらを先に実行? => どちらでもOKなので、ping?
acquire()のinterruptは? => catchしてstack traceする??
変数は出来るだけfinalにする? 初期化する? => 初期化がの場合が多そう??
=> Semaphoreの方も直す? => 今更面倒だから直さない??
try/finally, final, this, private, volatile, Lock, 初期化
constructorはlock不要。(W2-A1と同様)
volatileを使えばcacheの一貫性は保てる? => yes.
Uninterruptiblyでもtry/finallyするべき? => yes?
countのreturnでもlock必要? => yes.
ローカル変数も初期化すべき? finalをつけるべき? => yes.
thisはつけるべき? => 付けていない人の方が多い感じなのでつけないで命名規則で。
インスタンス変数にはmXxxxの名前にすべき? => yes.
importのunusedがある場合は親クラスとして使うかもしれない。
=> ちょっと待って。W4-A3ではimport Lockが削除されている。。。W3-A2も直すべき?
=> W3-A2はそのままになっているので、そっちはそのままにする。
Your work was submitted. Review your work to make sure everything looks OK.
のリンクから提出状況を確認できる。submit直後のみ。
[Evaluation]
thisを使っている人もそれなりにいた。
配列を使わない人もいた。
配列の初期化はメンバ変数宣言時点で行う人が多い。
finalは使わない。
fairがほとんどだった。どこかに記載あった??
S1
thisを使っている。
配列を使わないでメンバ変数を二つ用意している。
System.out.formatを使っている。
acquireUninterruptibly()
fair
S2
reflect.Array
concurrent.CyclicBarrier
importしているが使っていない。skeltonが古い??
acquireUninterruptibly()
fair
S3
acquireUninterruptibly()
fair
S4
acquire()、関数も勝手にthrowを付け加えている。
fair
await()をtry/catchしている。
S5
acquireUninterruptibly()
no-fair
await()をtry/catchしている。
JUnitTestでfail!!
引数で渡された文字列を使わずに、文字を直に書いてしまっていたため。
Self
TODOのコメントを２カ所間違って消してしまった。。。
引数のリストの中のコメントだったので。まあ良いとしよう。
[Results]
無事に満点で完了!
==== Etc ====
今週はAndroidの話が中心。
画像ダウンロードの演習の説明。
オプションの講義が半分あるが手が回らない。。。
Javaでは未使用の引数があってもwarning出ない??
Eclipseでも特に出ている様子はないが、オプションで変えられる??
メンバ変数で未使用の場合はwarningが出ている。
[Eclipse]
formatterでindentにtabを使わないでスペースを使うようにする。
==== log ====
2014/06/05 00:45 Lecture
2014/06/06 00:45 Lecture
2014/06/07 00:25 Lecture, Quiz
2014/06/07 02:20 Assignments
2014/06/19 01:15 Evaluation
2014/06/25 00:10 Result
Section 1 Module 3 Part 6: The AsyncTask Framework (Part 1) (9:56)
[AsyncTask framework]
HaMeR: must understand pattern, lose connected
AsyncTask: strongly connected, handler, message, runnable等を理解しなくても使える。
public method: execute(), cancel(). アプリによって実行される。
protected method: onReExcecute, doInBackground等
hook methids overriddenで振る舞いを変える。
長くかかる処理をbackgroundで行う。UIの裏側など。UIを簡単にする。
cancel()の方が難しい。
frameworkの特徴: inversion control, Domein-specific, semi-complete
Section 1 Module 3 Part 7: The AsyncTask Framework (Part 2) (8:14)
[AsyncTask framework]
black-box framework: strategy, decorator, interfaceのみ知っていればよい。
white-box framework: template, state, 実装を知っている必要がある。
AsyncTaskのWhite-box elements: template(hook) mothods, sub classで実装。
AsyncTaskのBlac-box elements: strategyを渡すことでconfig出来る。
作りやすさと使いやすさのtrade-offs
Section 1 Module 3 Part 8: Programming with the Android Concurrency Frameworks (Part 1) (7:17)
[ThreadedDownload App]
HaMeR, AsyncTask
3 waysの実装方法を試す。
Posting & processing Runnables
Sending & handling Messages
Executing AsyncTasks
image URLを入力して、メニューボタンから処理を選んで、progress dialog、imageを表示。
Reset imageボタンも作る。
[Androidの3つのkey elements]
java source code
resource files: ボタンのアイコンデータ、UIのレイアウト、国際化文字列等。
manifest: xmlでapplicationの実行に必要な情報を定義する。
permissionやmain Activity(ThreadedDownload class)
UNレイアウトはmain.xmlで決める。処理を選ぶbuttonのhandler登録もここで行う。
ThreadedDownload AppのjavaのコードにUIのボタンなどをhard-configしなくて良い。
Section 1 Module 3 Part 9: Programming with the Android Concurrency Frameworks (Part 2) (13:10)
[ThreadedDownload App]
3つの手法の比較。
AsyncTaskは簡単で使いやすいが拡張性と効率は劣る。
Messageは拡張性、効率は上だが作るのが難しい。
Runnableは効率は良いが拡張性は低い?? 作りやすさは中間。
ダウンロードをbackgroundで行う。
イメージの表示は共通部品にする。
Benefits and Limitations of Patterns and Frameworks (Part 1) (25:00) [Optional Lecture]
Benefits and Limitations of Patterns and Frameworks (Part 2) (17:30) [Optional Lecture]
More Information on Patterns and Frameworks (11:30) [Optional Lecture]
==== Quiz ====
Lectureが4つだったので各2問で8問。
一回目は22/29, 2回目で満点だった。
==== Assignment ====
[Week-4-Assignment-3]
今週はPingPongでまたLectureの内容とはずれてた。
DownloadのAppは来週つくるのか??
FairとNon-Fairどちら? => 特に指定なし。non-fairで十分??
await()はtryするべき? => 呼出し元が割り込みを投げるので不要??
countDown()はtry不要? => non-blockingなので不要。
定数はfinal staticするべき? => TODOになってないから不要??
run,それともstart,join? => 例を見るとstartでjoinなし?
ping,pongどちらを先に実行? => どちらでもOKなので、ping?
acquire()のinterruptは? => catchしてstack traceする??
変数は出来るだけfinalにする? 初期化する? => 初期化がの場合が多そう??
=> Semaphoreの方も直す? => 今更面倒だから直さない??
try/finally, final, this, private, volatile, Lock, 初期化
constructorはlock不要。(W2-A1と同様)
volatileを使えばcacheの一貫性は保てる? => yes.
Uninterruptiblyでもtry/finallyするべき? => yes?
countのreturnでもlock必要? => yes.
ローカル変数も初期化すべき? finalをつけるべき? => yes.
thisはつけるべき? => 付けていない人の方が多い感じなのでつけないで命名規則で。
インスタンス変数にはmXxxxの名前にすべき? => yes.
importのunusedがある場合は親クラスとして使うかもしれない。
=> ちょっと待って。W4-A3ではimport Lockが削除されている。。。W3-A2も直すべき?
=> W3-A2はそのままになっているので、そっちはそのままにする。
Your work was submitted. Review your work to make sure everything looks OK.
のリンクから提出状況を確認できる。submit直後のみ。
[Evaluation]
thisを使っている人もそれなりにいた。
配列を使わない人もいた。
配列の初期化はメンバ変数宣言時点で行う人が多い。
finalは使わない。
fairがほとんどだった。どこかに記載あった??
S1
thisを使っている。
配列を使わないでメンバ変数を二つ用意している。
System.out.formatを使っている。
acquireUninterruptibly()
fair
S2
reflect.Array
concurrent.CyclicBarrier
importしているが使っていない。skeltonが古い??
acquireUninterruptibly()
fair
S3
acquireUninterruptibly()
fair
S4
acquire()、関数も勝手にthrowを付け加えている。
fair
await()をtry/catchしている。
S5
acquireUninterruptibly()
no-fair
await()をtry/catchしている。
JUnitTestでfail!!
引数で渡された文字列を使わずに、文字を直に書いてしまっていたため。
Self
TODOのコメントを２カ所間違って消してしまった。。。
引数のリストの中のコメントだったので。まあ良いとしよう。
[Results]
無事に満点で完了!
==== Etc ====
今週はAndroidの話が中心。
画像ダウンロードの演習の説明。
オプションの講義が半分あるが手が回らない。。。
Javaでは未使用の引数があってもwarning出ない??
Eclipseでも特に出ている様子はないが、オプションで変えられる??
メンバ変数で未使用の場合はwarningが出ている。
[Eclipse]
formatterでindentにtabを使わないでスペースを使うようにする。
==== log ====
2014/06/05 00:45 Lecture
2014/06/06 00:45 Lecture
2014/06/07 00:25 Lecture, Quiz
2014/06/07 02:20 Assignments
2014/06/19 01:15 Evaluation
2014/06/25 00:10 Result
2014年6月24日火曜日
David Christian, The history of our world in 18 minutes を見て
NHKのスーパープレゼンテーションで久々に#TEDを見た。
エントロピー増大の法則に反して、歴史は複雑度を増加させる方向に動いている。
複雑度を増加させるには特定の条件がそろう必要がある。
複雑度を一気に増加させるbreak throughが歴史上時々起きている。
集団的学習は人間だけの特徴で、情報を共有して後の時代に残せることで、さらに複雑度を増加させることが可能になった。
複雑度を増加させることは不安定で崩れやすい状態になると言う事。
人類が集団的学習をコントロール出来ているのかは現状では何とも言えない。
エントロピー増大の法則に反して、歴史は複雑度を増加させる方向に動いている。
複雑度を増加させるには特定の条件がそろう必要がある。
複雑度を一気に増加させるbreak throughが歴史上時々起きている。
集団的学習は人間だけの特徴で、情報を共有して後の時代に残せることで、さらに複雑度を増加させることが可能になった。
複雑度を増加させることは不安定で崩れやすい状態になると言う事。
人類が集団的学習をコントロール出来ているのかは現状では何とも言えない。
2014年6月21日土曜日
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (5th Virtual office hours)
==== W4A3 ====
インストラクターの好みでは、finalを結構使っている。
runでtry/finally{countDown}を使っている。TODOの外に追加している??
定数もどこかで定義した方が良いとは言っているが、TODOの外になる??
性能の関係でnon-fairで良い。falseにするのではなくて引数省略(overload??)。
mLatch.await()ではtryしていない。
==== W5A4 ====
PingPongCondとSema両方使っている。
Condは複数回連続でpingやpongを表示できるように拡張されている。
consoleとandroidで違はほとんどない。基本はprint()だけ。
doneについても実装は変えられる。
単にmLatchをcountdownだけでも良いが、講師はrunnableをUIに送ってそこでcoundownさせたとか。
そうするとすべてが完了してからcountdown出来るかと言っていた。
ping/pong threadから表示のrunnableを送っているので、その処理が終わってからcountdownさせると言う意味だと思う。
みんなそんなして来ないような気がするけど。。。
==== Etc. ====
前の週のAssingmentを使うのは現実の再利用の練習も兼ねている。
正しく動かせるようになるのが先。性能はその後の改善と考えている。
正式なバージョンのAssignmentをダウンロードして使うべき。
CourseのHPのリンクが正式版。
これも結局GitHubの最新版を指しているだけで、しかもAssignmentの実施期間中にも更新されている様子。。。
途中にサッカーのワールドカップの話などジョーク的な話も混ざっていた。
このVOHはMOOCでもinteractiveな要素を取り入れると言う先進的な取り組みらしい。
確かに自分が思っているのと同じような疑問に講師が答えてくれるのは面白い。
ただ、これだけ人数がいると何時やっても質問は出尽くすような気がするので、何処かでおこなったビデオを後で見ても自分も疑問に答えてくれている様に感じると思う。
なのでリアルタイム性はあまり重要ではないのかもしれない。
インストラクターの好みでは、finalを結構使っている。
runでtry/finally{countDown}を使っている。TODOの外に追加している??
定数もどこかで定義した方が良いとは言っているが、TODOの外になる??
性能の関係でnon-fairで良い。falseにするのではなくて引数省略(overload??)。
mLatch.await()ではtryしていない。
==== W5A4 ====
PingPongCondとSema両方使っている。
Condは複数回連続でpingやpongを表示できるように拡張されている。
consoleとandroidで違はほとんどない。基本はprint()だけ。
doneについても実装は変えられる。
単にmLatchをcountdownだけでも良いが、講師はrunnableをUIに送ってそこでcoundownさせたとか。
そうするとすべてが完了してからcountdown出来るかと言っていた。
ping/pong threadから表示のrunnableを送っているので、その処理が終わってからcountdownさせると言う意味だと思う。
みんなそんなして来ないような気がするけど。。。
==== Etc. ====
前の週のAssingmentを使うのは現実の再利用の練習も兼ねている。
正しく動かせるようになるのが先。性能はその後の改善と考えている。
正式なバージョンのAssignmentをダウンロードして使うべき。
CourseのHPのリンクが正式版。
これも結局GitHubの最新版を指しているだけで、しかもAssignmentの実施期間中にも更新されている様子。。。
途中にサッカーのワールドカップの話などジョーク的な話も混ざっていた。
このVOHはMOOCでもinteractiveな要素を取り入れると言う先進的な取り組みらしい。
確かに自分が思っているのと同じような疑問に講師が答えてくれるのは面白い。
ただ、これだけ人数がいると何時やっても質問は出尽くすような気がするので、何処かでおこなったビデオを後で見ても自分も疑問に答えてくれている様に感じると思う。
なのでリアルタイム性はあまり重要ではないのかもしれない。
2014年6月20日金曜日
モナドについて少し考えた
函手(functor)、モナドについて少し分かった??
ある要素をある「機能」をもったコンテナに格納する。(unit constractor)
その要素に対する演算を定義して、それをコンテナにも適用可能。(map, functor)
その要素に対する演算を行って更にコンテナに格納(constractor)する演算(アクション)を、コンテナが入れ子にならない様に適用可能(flatmap, monad)
この「機能」はOptionやCollectionやStateのようなものだったり、I/Oの様に言語上では実装を表現できないシステム依存の物でも良い。
アクションを適用する際に副作用が発生する様にすれば、flatmapの連続で副作用を連続的に実行できる??
コンテナに格納した値を取り出す時には、前のアクションが評価済の必要があるので、評価の順序を制御出来る??
I/Oモナドに関する下記が分かり易かった。
http://cs.hatenablog.jp/entry/2013/08/23/075647
下記は内容は理解できていない。。。
http://www.mew.org/~kazu/material/2012-monad.pdf
DSL、制御構造を表せる、チューリング完全、リスト内包表現、scalaのfor...
文脈、前の値を使える、関数の連続から入れ子に変換出来る。
mapは関数の連続適用、fmapは関数の入れ子適用。
計算の階層化、抽象化、大枠を個別の値に関係無く共通的に扱う。
隠ぺい、包む、コンテナ、ブラックボックス
状態系、失敗系
Functor, Applicative, Monad
参照透過と言うのは同じ引数なら常に同じ戻り値になると言う事。
常に同じ内部処理が実行される必要はない！
外から見て同じならそれでOK。
ある要素をある「機能」をもったコンテナに格納する。(unit constractor)
その要素に対する演算を定義して、それをコンテナにも適用可能。(map, functor)
その要素に対する演算を行って更にコンテナに格納(constractor)する演算(アクション)を、コンテナが入れ子にならない様に適用可能(flatmap, monad)
この「機能」はOptionやCollectionやStateのようなものだったり、I/Oの様に言語上では実装を表現できないシステム依存の物でも良い。
アクションを適用する際に副作用が発生する様にすれば、flatmapの連続で副作用を連続的に実行できる??
コンテナに格納した値を取り出す時には、前のアクションが評価済の必要があるので、評価の順序を制御出来る??
I/Oモナドに関する下記が分かり易かった。
http://cs.hatenablog.jp/entry/2013/08/23/075647
下記は内容は理解できていない。。。
http://www.mew.org/~kazu/material/2012-monad.pdf
DSL、制御構造を表せる、チューリング完全、リスト内包表現、scalaのfor...
文脈、前の値を使える、関数の連続から入れ子に変換出来る。
mapは関数の連続適用、fmapは関数の入れ子適用。
計算の階層化、抽象化、大枠を個別の値に関係無く共通的に扱う。
隠ぺい、包む、コンテナ、ブラックボックス
状態系、失敗系
Functor, Applicative, Monad
参照透過と言うのは同じ引数なら常に同じ戻り値になると言う事。
常に同じ内部処理が実行される必要はない！
外から見て同じならそれでOK。
2014年6月18日水曜日
Programming in Scala, First Edition: Chapter 22
22. Implementing Lists
Listはこの本の何処にでも出てくる。
Listはscalaで一番よく使われるデータ構造だから。
今回はListの実装について言及する。
Listを効率良く使えるようになる。
自分のlibraryを作る時の参考に出来る。
Listを実例としてscalaの型システムの概念を学べる。
22.1 The List class in principle
Listは組み込み型ではない。
abstract classとして実装されている。
subclassは::とNil
** memberではなくてsubclassと言うのが面白い。
abstract class List[+T] {..}
+Tはcovariantを示す。
val xs: List[Any] = List(1, 2, 3)が可能。
isEmpty, head, tailが基本関数。
class Listではabstractで定義されている。
subclass ::, Nilで実装されている。
The Nil object
case object Nil extends List[Nothing] {..}
covariantなのでList[Nothing]は全てのList[T]と互換性がある。(代入出来る)
headはNothingを返す必要があるが、それは不可能なので例外を投げるしかない。
tailは逆に例外ではなくてNilを返すと言う仕様もあり得る。
The :: class
final case class ::[T](head: T, tail: List[T]) extends List[T] {..}
consと呼ばれる。constructの意味。
constructor :: をpattern matchingで使えるようにcase classで定義する。
finalを付けることでsubclassの作成(実装の変更)を禁止。10.10参照。
head, tailはパラメタ無抽象methodをfieldで実装している。20.3参照。
Some more methods
他の全てのmethodはhead,tail,isEmptyを使う事で実装出来る。
List construction
::,:::は:で終わっているのでreceiverは右辺値になる。
::はclass ::のconstructorでもあるが、同名のmethodでもある。
Listの要素が異なるtypeの場合は、共通のsuper classがListのtypeになる。
def ::[U >: T](x: U): List[U] = new scala.::(x, this)
UはTとxの共通のsuper typeになる。
:::も同様。
def :::[U >: T](prefix: List[U]): List[U] =
if (prefix.isEmpty) this
else prefix.head :: prefix.tail ::: this
22.2 The ListBuffer class
import scala.collection.mutable.ListBuffer
"buf += elem"が出来る。
Listを生成する時に、要素を末尾に追加していける。
生成したらtoListでListにする。
通常のListを使ったら非常に非効率。
tail recursive ではない呼び出しだと30,000-50,000位でstackが溢れる。
22.3 The List class in practice
実際のListの実装は効率のためにListBufferとloopを使っている。
stack overflowを避けるために再帰呼び出しを使わない様にしている。
tail recursiveに出来れば同様に効率的に出来る。
ListBufferのtoListの計算量は少ない。
長さに無関係に少ない数のサイクルしか掛からない。
実際の::の実装はtailがprivate[scala] varで実装されている!!
private[scala]でpackage scala内でのアクセスに制限している。
ユーザからはアクセスできない。
ListBufferからアクセス可能。
ListBufferはtailを書き換えてつなぎかえるようにしている。
Listの構成を保ったまま拡張しているのでList化の計算コストはO(0)
?? 一旦List化した後の追加は高コストとあるが、何故??
22.4 Functional on the outside
Listはoutsideからはpurely functionalだがinsideではmutableな実装をしている。
scalaでは典型的な戦略。
impureな操作の影響を注意深く取り除く事でpureでefficientな実装にする。
purityは重要。
purityがcopy無でListの共有を可能にする。
効率的で分かりやすい実装が出来る。
val ys = 1 :: xs; val zs = 2 :: xsでysのxs部分を書き換えたらzsに影響する。
影響させないためにはcopyする必要があり、効率が悪くなる。
scalaでは末尾に追加する生成方法のためにListBufferを用意している。
Listのpurityを保つために分離して提供しているのが重要。
JavaのStringとStringBuffer/StringBuildersと同様の発想。
::はrecursive algorithmsで分割統治styleを使う場合に適している。
ListBufferはloopのstyleに適している。
22.5 Conclusion
Listの実装は洗練されている。
外部からはfunctionalに見えるようにしている。
内部では効率のためにmutableなListBufferを使っている。
Listはこの本の何処にでも出てくる。
Listはscalaで一番よく使われるデータ構造だから。
今回はListの実装について言及する。
Listを効率良く使えるようになる。
自分のlibraryを作る時の参考に出来る。
Listを実例としてscalaの型システムの概念を学べる。
22.1 The List class in principle
Listは組み込み型ではない。
abstract classとして実装されている。
subclassは::とNil
** memberではなくてsubclassと言うのが面白い。
abstract class List[+T] {..}
+Tはcovariantを示す。
val xs: List[Any] = List(1, 2, 3)が可能。
isEmpty, head, tailが基本関数。
class Listではabstractで定義されている。
subclass ::, Nilで実装されている。
The Nil object
case object Nil extends List[Nothing] {..}
covariantなのでList[Nothing]は全てのList[T]と互換性がある。(代入出来る)
headはNothingを返す必要があるが、それは不可能なので例外を投げるしかない。
tailは逆に例外ではなくてNilを返すと言う仕様もあり得る。
The :: class
final case class ::[T](head: T, tail: List[T]) extends List[T] {..}
consと呼ばれる。constructの意味。
constructor :: をpattern matchingで使えるようにcase classで定義する。
finalを付けることでsubclassの作成(実装の変更)を禁止。10.10参照。
head, tailはパラメタ無抽象methodをfieldで実装している。20.3参照。
Some more methods
他の全てのmethodはhead,tail,isEmptyを使う事で実装出来る。
List construction
::,:::は:で終わっているのでreceiverは右辺値になる。
::はclass ::のconstructorでもあるが、同名のmethodでもある。
Listの要素が異なるtypeの場合は、共通のsuper classがListのtypeになる。
def ::[U >: T](x: U): List[U] = new scala.::(x, this)
UはTとxの共通のsuper typeになる。
:::も同様。
def :::[U >: T](prefix: List[U]): List[U] =
if (prefix.isEmpty) this
else prefix.head :: prefix.tail ::: this
22.2 The ListBuffer class
import scala.collection.mutable.ListBuffer
"buf += elem"が出来る。
Listを生成する時に、要素を末尾に追加していける。
生成したらtoListでListにする。
通常のListを使ったら非常に非効率。
tail recursive ではない呼び出しだと30,000-50,000位でstackが溢れる。
22.3 The List class in practice
実際のListの実装は効率のためにListBufferとloopを使っている。
stack overflowを避けるために再帰呼び出しを使わない様にしている。
tail recursiveに出来れば同様に効率的に出来る。
ListBufferのtoListの計算量は少ない。
長さに無関係に少ない数のサイクルしか掛からない。
実際の::の実装はtailがprivate[scala] varで実装されている!!
private[scala]でpackage scala内でのアクセスに制限している。
ユーザからはアクセスできない。
ListBufferからアクセス可能。
ListBufferはtailを書き換えてつなぎかえるようにしている。
Listの構成を保ったまま拡張しているのでList化の計算コストはO(0)
?? 一旦List化した後の追加は高コストとあるが、何故??
22.4 Functional on the outside
Listはoutsideからはpurely functionalだがinsideではmutableな実装をしている。
scalaでは典型的な戦略。
impureな操作の影響を注意深く取り除く事でpureでefficientな実装にする。
purityは重要。
purityがcopy無でListの共有を可能にする。
効率的で分かりやすい実装が出来る。
val ys = 1 :: xs; val zs = 2 :: xsでysのxs部分を書き換えたらzsに影響する。
影響させないためにはcopyする必要があり、効率が悪くなる。
scalaでは末尾に追加する生成方法のためにListBufferを用意している。
Listのpurityを保つために分離して提供しているのが重要。
JavaのStringとStringBuffer/StringBuildersと同様の発想。
::はrecursive algorithmsで分割統治styleを使う場合に適している。
ListBufferはloopのstyleに適している。
22.5 Conclusion
Listの実装は洗練されている。
外部からはfunctionalに見えるようにしている。
内部では効率のためにmutableなListBufferを使っている。
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (Week 3)
==== Lecture ====
Section 1 Module 3: Introduction to Android Concurrency Frameworks (2:19)
HaMeR framwork: handler, message, runnable,
=> lose connected, long duration, background, 結果をUIに伝える
AysncTask framework:
=> tightly connected, long duration, background, small
=> thread, handler, runnable, messageを目地的に使わないでUIを操作する。
Section 1 Module 3 Part 1: Overview of Android Concurrency Frameworks and Idioms (12:22)
Androidのconcurrent soft開発には制約がある
=> ANRを(Application Not Responding)を避ける必要がある。
=> Non-UI ThreadはUI toolkitに触れない。thread-safeでないから。
javaの仕組みだけでは十分ではない。Android frameworkも必要
HaMeRとAsync framework
Looper: Thread Specific Storage pattern => 1threadに1looperを保証。
POSAとGoFのpattern, idiom: Command processor, Active Object, HsHa, Factory method, Strategy
message queue: monitor object pattern = in queue and dequeue messages concurrently.
Messages: factory method pattern
Handlers: active object pattern, command processor pattern
=> sender and receiver threads to run concurrently
AsyncTask framework: Half-Sync, Half-Async pattern
=> decouple asynchronous and synchronous processing, simplify programming, enhance performance
Section 1 Module 3 Part 2: Android Looper (7:48)
template methodとthread specific storage patternを使う。
Section 1 Module 3 Part 3: Overview of Android Handlers (6:16)
command processor pattern と active object patternを使っている。
遅延実行のために自分から自分に送る場合もある。
Section 1 Module 3 Part 4: Posting and Processing Runnables with Android Handler (8:46)
command processor pattern
closure
runnableをcallbackする。送信側で処理の準備をする。
Section 1 Module 3 Part 5: Sending and Handling Messages with Android Handler (9:57)
active object pattern
countdown timer
受信側でmessageを処理する準備をする。
Framework Examples (Part 1) (14:00) [Optional Lecture]
Framework Examples (Part 2) (12:30) [Optional Lecture]
==== Quiz ====
今週は8問と少ない。内容も難しくは無さそう。
1回目で全問正解!
==== Assignment ====
[Week-3-Assignment-2]
Your work was submitted. Review your work to make sure everything looks OK.
のリンクから提出状況を確認できる。
try/finally, final, this, private, volatile, Lock, 初期化
FareとNon-Fare
constructorはlock不要。(W2-A1と同様)
volatileを使えばcacheの一貫性は保てる? => yes.
Uninterruptiblyでもtry/finallyするべき? => yes?
countのreturnでもlock必要? => yes.
ローカル変数も初期化すべき? finalをつけるべき? => yes.
thisはつけるべき? => 付けていない人の方が多い感じなのでつけないで命名規則で。
インスタンス変数にはmXxxxの名前にすべき? => yes.
importの話もW2-A1と同様。
Reentrant Lock, Conditional Object, Counting SemaphoreとWeek2のLectureの内容。
Week3のLectureの内容とは無関係でLectureとAssignmentsが合っていない。。。
https://class.coursera.org/posa-002/forum/thread?thread_id=1502#post-5328
lockInterruptibly()を使うべき。
https://class.coursera.org/posa-002/forum/thread?thread_id=1515#post-5329
mCountはlockしてもしなくても良い。
https://class.coursera.org/posa-002/forum/thread?thread_id=1103#comment-2326
signal()を使った方が良い。
signalAll()でも動作上問題ないが、すべてのthreadを起床しようとする分無駄がある。
[Evaluation]
S1-SimpleAtomicLong
W2A1のスケルトンを使っている。
ローカル変数を定義したり初期化しているのに使っていない。
S1-SimpleSemaphore
メンバ変数のlockをLockで宣言している。
lockInterruptibly()は未使用。
availablePermitsの取得をLock無しで行っている。
S2-SimpleAtomicLong
W2A1のスケルトンを使っている。
コンストラクタで不要なlockをしている。
ローカル変数は初期化はしていない。
S2-SimpleSemaphore
lockやnotEmptyをprivateで宣言していない。
lockInterruptibly()は未使用。
availablePermitsの取得をLock無しで行っている。
S3-SimpleAtomicLong
W2A1のスケルトンを使っている。
コンストラクタで不要なlockをしている。
S3-SimpleSemaphore
メンバ変数をfinal宣言していない所あり。
lockInterruptibly()を使用。
availablePermitsの取得をLock無しで行っている。
S4-SimpleAtomicLong
インデントが変更されてる。
コンストラクタで不要なlockをしている。
get&modifyでgetの部分で別途readLockを使っている。
S4-SimpleSemaphore
インデントが変更されてる。
availablePermitsをstaticにしている。volatileしていない!!
lockInterruptibly()は未使用。
acquire()でawait()した後signal()している!!
throws InterruptedExceptionが削除されている!!
availablePermitsの取得をLock無しで行っている。
S5-SimpleAtomicLong
readLock, writeLockをメンバ変数にしている。finalはしていない。
thisを使ってる。
ローカル変数を使っていない。
S5-SimpleSemaphore
メンバ変数を初期化してfinalしていない。
thisを使っている。
lockInterruptibly()は未使用。
signalAll()を使ってる。
availablePermitsの取得をLockありで行っている。
JUnitは全員OK!!
[Results]
14/14満点で終了!
==== Etc ====
今週はAndroidの話が中心。
optionalのlectureまで手が回らない。
無理に手を出すよりもmandatoryのLectureに時間を掛けた方が良いかもしれない。
=> Optional Lectureは後回しにして、先にAssignmentを行う。
Palantir: 指輪物語に出てくる水晶玉みたいなもの。
演習とは関係ないが遊び心があってGood!
Evaluationに時間が掛かり過ぎてバテてしまった。
[Eclipse]
gitの使い方を結構覚えた。これはこれで面白い。
==== log ====
2014/05/27 00:20 準備, Quiz
2014/05/29 00:45 Lecture
2014/06/01 00:10 Lecture
2014/06/02 00:40 Lecture
2014/06/02 00:20 Quiz
2014/06/04 03:30 Assignments
2014/06/04 01:15 Assignments
2014/06/11 01:00 Evaluation
2014/06/13 02:00 Evaluation
Section 1 Module 3: Introduction to Android Concurrency Frameworks (2:19)
HaMeR framwork: handler, message, runnable,
=> lose connected, long duration, background, 結果をUIに伝える
AysncTask framework:
=> tightly connected, long duration, background, small
=> thread, handler, runnable, messageを目地的に使わないでUIを操作する。
Section 1 Module 3 Part 1: Overview of Android Concurrency Frameworks and Idioms (12:22)
Androidのconcurrent soft開発には制約がある
=> ANRを(Application Not Responding)を避ける必要がある。
=> Non-UI ThreadはUI toolkitに触れない。thread-safeでないから。
javaの仕組みだけでは十分ではない。Android frameworkも必要
HaMeRとAsync framework
Looper: Thread Specific Storage pattern => 1threadに1looperを保証。
POSAとGoFのpattern, idiom: Command processor, Active Object, HsHa, Factory method, Strategy
message queue: monitor object pattern = in queue and dequeue messages concurrently.
Messages: factory method pattern
Handlers: active object pattern, command processor pattern
=> sender and receiver threads to run concurrently
AsyncTask framework: Half-Sync, Half-Async pattern
=> decouple asynchronous and synchronous processing, simplify programming, enhance performance
Section 1 Module 3 Part 2: Android Looper (7:48)
template methodとthread specific storage patternを使う。
Section 1 Module 3 Part 3: Overview of Android Handlers (6:16)
command processor pattern と active object patternを使っている。
遅延実行のために自分から自分に送る場合もある。
Section 1 Module 3 Part 4: Posting and Processing Runnables with Android Handler (8:46)
command processor pattern
closure
runnableをcallbackする。送信側で処理の準備をする。
Section 1 Module 3 Part 5: Sending and Handling Messages with Android Handler (9:57)
active object pattern
countdown timer
受信側でmessageを処理する準備をする。
Framework Examples (Part 1) (14:00) [Optional Lecture]
Framework Examples (Part 2) (12:30) [Optional Lecture]
==== Quiz ====
今週は8問と少ない。内容も難しくは無さそう。
1回目で全問正解!
==== Assignment ====
[Week-3-Assignment-2]
Your work was submitted. Review your work to make sure everything looks OK.
のリンクから提出状況を確認できる。
try/finally, final, this, private, volatile, Lock, 初期化
FareとNon-Fare
constructorはlock不要。(W2-A1と同様)
volatileを使えばcacheの一貫性は保てる? => yes.
Uninterruptiblyでもtry/finallyするべき? => yes?
countのreturnでもlock必要? => yes.
ローカル変数も初期化すべき? finalをつけるべき? => yes.
thisはつけるべき? => 付けていない人の方が多い感じなのでつけないで命名規則で。
インスタンス変数にはmXxxxの名前にすべき? => yes.
importの話もW2-A1と同様。
Reentrant Lock, Conditional Object, Counting SemaphoreとWeek2のLectureの内容。
Week3のLectureの内容とは無関係でLectureとAssignmentsが合っていない。。。
https://class.coursera.org/posa-002/forum/thread?thread_id=1502#post-5328
lockInterruptibly()を使うべき。
https://class.coursera.org/posa-002/forum/thread?thread_id=1515#post-5329
mCountはlockしてもしなくても良い。
https://class.coursera.org/posa-002/forum/thread?thread_id=1103#comment-2326
signal()を使った方が良い。
signalAll()でも動作上問題ないが、すべてのthreadを起床しようとする分無駄がある。
[Evaluation]
S1-SimpleAtomicLong
W2A1のスケルトンを使っている。
ローカル変数を定義したり初期化しているのに使っていない。
S1-SimpleSemaphore
メンバ変数のlockをLockで宣言している。
lockInterruptibly()は未使用。
availablePermitsの取得をLock無しで行っている。
S2-SimpleAtomicLong
W2A1のスケルトンを使っている。
コンストラクタで不要なlockをしている。
ローカル変数は初期化はしていない。
S2-SimpleSemaphore
lockやnotEmptyをprivateで宣言していない。
lockInterruptibly()は未使用。
availablePermitsの取得をLock無しで行っている。
S3-SimpleAtomicLong
W2A1のスケルトンを使っている。
コンストラクタで不要なlockをしている。
S3-SimpleSemaphore
メンバ変数をfinal宣言していない所あり。
lockInterruptibly()を使用。
availablePermitsの取得をLock無しで行っている。
S4-SimpleAtomicLong
インデントが変更されてる。
コンストラクタで不要なlockをしている。
get&modifyでgetの部分で別途readLockを使っている。
S4-SimpleSemaphore
インデントが変更されてる。
availablePermitsをstaticにしている。volatileしていない!!
lockInterruptibly()は未使用。
acquire()でawait()した後signal()している!!
throws InterruptedExceptionが削除されている!!
availablePermitsの取得をLock無しで行っている。
S5-SimpleAtomicLong
readLock, writeLockをメンバ変数にしている。finalはしていない。
thisを使ってる。
ローカル変数を使っていない。
S5-SimpleSemaphore
メンバ変数を初期化してfinalしていない。
thisを使っている。
lockInterruptibly()は未使用。
signalAll()を使ってる。
availablePermitsの取得をLockありで行っている。
JUnitは全員OK!!
[Results]
14/14満点で終了!
==== Etc ====
今週はAndroidの話が中心。
optionalのlectureまで手が回らない。
無理に手を出すよりもmandatoryのLectureに時間を掛けた方が良いかもしれない。
=> Optional Lectureは後回しにして、先にAssignmentを行う。
Palantir: 指輪物語に出てくる水晶玉みたいなもの。
演習とは関係ないが遊び心があってGood!
Evaluationに時間が掛かり過ぎてバテてしまった。
[Eclipse]
gitの使い方を結構覚えた。これはこれで面白い。
==== log ====
2014/05/27 00:20 準備, Quiz
2014/05/29 00:45 Lecture
2014/06/01 00:10 Lecture
2014/06/02 00:40 Lecture
2014/06/02 00:20 Quiz
2014/06/04 03:30 Assignments
2014/06/04 01:15 Assignments
2014/06/11 01:00 Evaluation
2014/06/13 02:00 Evaluation
2014年6月16日月曜日
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (4th Virtual office hours)
[W3A2(simple-semaphore)]
メンバ変数を初期化もfinalもしていない。
finalに何故しないのかと言う質問があったが、しても良いと言ってただけのような気がする。。。
mCountをstaticにすべきではない。UnitTestでNGになる??
volatileは無くても良い??
初期化時にcountは負になる場合も考慮しているが、0まででもOK。
Uninterruptibilyでロジック上は割り込みは発生しないのでtryは不要だが、書いた方が良いと講師は考えている。良い習慣や不慮のexceptionに備えて。
mCountの取得はvolatileなのでjavaではlock不要。atomicは保障されている。
lockしていても不要なだけなのでpointは引くなと言っているが。。。
[W4A3(ping-poing)]
こちはら実装前のskeletonを見ながらの説明。
acquire()ではUninterruptiblyを使うのが推奨。
CountDownLatchではなくてjoinでも済むが、練習のためのと次の課題のために使っている。
mLatch.await()もtry{}が推奨と言っていたが、finallyするものが無いのでは?
[git]
説明videoだけの様なので省略。
[Etc.]
Assignmentの細かい説明があった。皆から上がった疑問に基づいているので興味深い。
自分も同じ課題を解いているので、同じ疑問や違った視点もあり面白かった。
単なるvideo baseのcourseよりinteractiveになっていて良い。
peer evaluationの基準は「間違っていない事」。
冗長な部分や非効率があってもそこでは点数は引かない。コメントに記載する。
「これは教育目的の演習だから許すけど、実プロジェクトなら許さない」等のコメントもあり面白かった。
メンバ変数を初期化もfinalもしていない。
finalに何故しないのかと言う質問があったが、しても良いと言ってただけのような気がする。。。
mCountをstaticにすべきではない。UnitTestでNGになる??
volatileは無くても良い??
初期化時にcountは負になる場合も考慮しているが、0まででもOK。
Uninterruptibilyでロジック上は割り込みは発生しないのでtryは不要だが、書いた方が良いと講師は考えている。良い習慣や不慮のexceptionに備えて。
mCountの取得はvolatileなのでjavaではlock不要。atomicは保障されている。
lockしていても不要なだけなのでpointは引くなと言っているが。。。
[W4A3(ping-poing)]
こちはら実装前のskeletonを見ながらの説明。
acquire()ではUninterruptiblyを使うのが推奨。
CountDownLatchではなくてjoinでも済むが、練習のためのと次の課題のために使っている。
mLatch.await()もtry{}が推奨と言っていたが、finallyするものが無いのでは?
[git]
説明videoだけの様なので省略。
[Etc.]
Assignmentの細かい説明があった。皆から上がった疑問に基づいているので興味深い。
自分も同じ課題を解いているので、同じ疑問や違った視点もあり面白かった。
単なるvideo baseのcourseよりinteractiveになっていて良い。
peer evaluationの基準は「間違っていない事」。
冗長な部分や非効率があってもそこでは点数は引かない。コメントに記載する。
「これは教育目的の演習だから許すけど、実プロジェクトなら許さない」等のコメントもあり面白かった。
Programming in Scala, First Edition: Chapter 21
21. Implicit Conversions and Parameters
既存classにどうやって機能を追加するか?
これは難しい問題。
各言語で色々な方法が試されている。
rubyではmodule, smalltalkではpackage
良く分からない他人のclassに手を入れるのは危険
C#3.0ではstatic extension method
影響は限定的だが、制約が多くて不便
scalaではimplicit conversionとparameter
the interesting, non-trivial partsにfocus出来る。
21.1 Implicit conversions
typeがmismatchした時にcompilerが変換関数を探して自動的に適用する機能。
分数を扱う簡易Rational classを定義する。
class Rational(val n: Int, val d: Int) {
def this(n: Int) = this(n, 1)
def + (that: Rational) = new Rational(n * that.d + d * that.n , d * that.d)
override def toString = this.n + "/" + this.d
}
1 + 1/2 を実施。
scala> (new Rational(1)) + (new Rational(1, 2))
res0: Rational = 3/2
receiverがIntだとtype errorになって使えない。
Intの + methodのparameterにRationalが定義されていないから。
scala> 1 + (new Rational(1, 2))
<console>:9: error: overloaded method value + with alternatives:
(x: Double)Double <and>
(x: Float)Float <and>
(x: Long)Long <and>
(x: Int)Int <and>
(x: Char)Int <and>
(x: Short)Int <and>
(x: Byte)Int <and>
(x: String)String
cannot be applied to (Rational)
1 + (new Rational(1, 2))
^
RationalにIntを足してもtype errorになって使えない。
Rationalの + methodのparameterにIntが定義されていないから。
scala> (new Rational(1, 2)) + 1
<console>:9: error: type mismatch;
found : Int(1)
required: Rational
(new Rational(1, 2)) + 1
^
implicit conversionを使うときは下記をimportする。
importしないとwarningが出る。implicitの使い過ぎの抑制のため。
scala> import scala.language.implicitConversions
Int=>Rational型変換関数をimplicitで宣言する。
scala> implicit def int2rational(x: Int) = new Rational(x)
receiver Intに対応出来るmethodがないと、compilerが変換関数を検索。
int2rational(1)に置き換えて実行される。
scala> 1 + (new Rational(1, 2))
res3: Rational = 3/2
receiver Rationalに対応出来るparameterがないと、compilerが変換関数を検索。
int2rational(1)に置き換えて実行される。
scala> (new Rational(1, 2)) + 1
res4: Rational = 3/2
parameterの型変換 > receiverの型変換の優先順位で実施される。
21.2 Rules for implicits
Marking Rule
implicitで定義されている場合のみ。
variable, function, object何でもimplicitに出来る。
Scope Rule
single identifierとしてscope内にある場合のみ。
変換関数をimportでscope内に入れる必要がある。
更にsingle identifierとなるように入れる必要がある。
path.convertはNG。convertになるようにimportする。
companion objectは例外としてsingle identifierではなくても検索される。
source, target type両方のcompanion objectがimport不要。
importしていない所にあるimplicitまでは把握しきれない。
Non-Ambiguity Rule
変換関数が一意に決まる場合のみ。
二つ以上の候補がある場合は適用されない。
?? より内側のscopeにあるなど、優先度がある??
One-at-a-time Rule
一回につき一段の変換しない。
convert1(convert2(x))のような多段の変換はしない。
compile時間が長くなるし、プログラマが把握しきれなくなるから。
implicit parameterを持つimplicitは例外。(後述)
Explicits-First Rule
無変換でtype checkが通ったら変換しない。
型変換関数をexplicitに書いてもOK。
冗長さと明確さのトレードオフ。ケースバイケースで判断する。
implicit conversion(変換関数)にも任意の名前を付けられる。
implicitに適用されているときはtypeしか見ないので名前な何でも良い。
explicitに適用したいときに使う。
自分の考えている変換関数がそこで使えるかの確認にも使える。
特定の変換関数のみをimportする時にも使える。
21.3 Implicit conversion to an expected type
type違いの時にtype変換関数があると適用される。
3つのimplicitの中で一番優先的に適用される。
通常は制約の多い(低機能)typeからより適用範囲(高機能)の広いtypeに変換する。
Int -> doubleへの変換はOK。逆はnot recommended。
** より機能追加されたsub typeを定義して、それに変換する。
21.4 Converting the receiver
receiverにmemberがなかったらmemberがあるtypeへの変換関数が適用される。
既存class階層に新しいclassを追加しやすくなる。
DSLをサポートしやすくなる。
Interoperating with new types
21.1のRationalの例を参照。
Simulating new syntax
文法を拡張した様に見せかける場合に有用。
Mapの`->`は組み込むの文法ではなくて単なるmethod!!
Map(1 -> "one", 2 -> "two", 3 -> "three")
Predefのclass ArrowAssocで->とimplicit any2ArrowAssocが定義されている。
1 -> "one"は
any2ArrowAssoc(1).->("one")と変換されて
(1, "one")になる。
"rich wrappers"はライブラリが文法を拡張した様に見せかける時によく使う。
receiverに存在しないmethodを適用しているときはimplicitの可能性が高い。
Richxxxといclassがあったら、xxxにimplicitで機能追加している可能性が高い。
これはDSLを定義する際に有用
他の言語だとexternal DSLが必要な場合でもscalaならinternalに定義出来る。
21.5 Implicit parameters
curry化した最後のパラメータリストそのもが省略されているときに、パラメータのtypeのobjectがあったら適用される。
適用したくない時はplace holder _を付けて省略ではない事を伝える必要あり。
implicit parameterの型は特殊であるものにすべき。
補完対象を型だけで決めるので重複や想定外の適用を避けるため。
型定義からimplicit parameterの役割が分かるような型を付けるべき。
21.6 View bounds
implicit parameterで渡される関数でimplicit conversionが出来る。
この場合はanonymousで良い。
[T <% Ordered[T]]
T => Ordered[T] がanonymousの関数値として適用されて、使用される。
implicit parameterは補完する/される両方で使われる。
省略した時に他のimplicit宣言されている値で補完される。
implicit parameterのscope内でimplicitが必要であれば適用される。
外側のscopeに同じsignatureのimplicitが定義されていてもhideされる。
implicitは主な使用目的はtypeのconversion
implicit parameterは値の補完にも使えるが、通常は型変換関数値の補完。
View bounds and upper bounds
<%は<:の適用範囲を更に広げたものと考える事が出来る。
sub typeの場合はそのまま使用される。
sub typeでない場合は変換関数が検索、適用されて使用される。
sub typeであるか変換関数があるかどちらかの条件を満たしていれば適用できる。
21.7 Debugging implicits
implicitは強力だが正しく使うのもdebugするのも難しい場合がある。
implicitが適用されない理由が分からない場合
implicitを使わずにexplicitで書いてみる。
エラーになればimplicitの問題ではない。
エラーにならなかったらimplicitの適用ルールを確認する。
どのimplicitが使われているかはcompile option -Xprint:typerで出力出来る。
scalac -Xprint:typerだとcomiple時に適用される。
scala -Xprint:typerでREPLでの適用結果も出力できる。
沢山出力されるので注意が必要。
?? どういうimplicitが宣言済か把握するには?
?? implicitを抑制する方法は??
21.8 Conclusion
implicitは実行時ではなくてcompile時に変換、チェック出来る。
implicitは強力だが乱用は避けるべき。
implicitを使う前にinheritance, mixin, overloading等で代替出来ないかを考える。
全部がダメで、更にコードが無駄冗長な場合は、implicitの使い所になるかも。
既存classにどうやって機能を追加するか?
これは難しい問題。
各言語で色々な方法が試されている。
rubyではmodule, smalltalkではpackage
良く分からない他人のclassに手を入れるのは危険
C#3.0ではstatic extension method
影響は限定的だが、制約が多くて不便
scalaではimplicit conversionとparameter
the interesting, non-trivial partsにfocus出来る。
21.1 Implicit conversions
typeがmismatchした時にcompilerが変換関数を探して自動的に適用する機能。
分数を扱う簡易Rational classを定義する。
class Rational(val n: Int, val d: Int) {
def this(n: Int) = this(n, 1)
def + (that: Rational) = new Rational(n * that.d + d * that.n , d * that.d)
override def toString = this.n + "/" + this.d
}
1 + 1/2 を実施。
scala> (new Rational(1)) + (new Rational(1, 2))
res0: Rational = 3/2
receiverがIntだとtype errorになって使えない。
Intの + methodのparameterにRationalが定義されていないから。
scala> 1 + (new Rational(1, 2))
<console>:9: error: overloaded method value + with alternatives:
(x: Double)Double <and>
(x: Float)Float <and>
(x: Long)Long <and>
(x: Int)Int <and>
(x: Char)Int <and>
(x: Short)Int <and>
(x: Byte)Int <and>
(x: String)String
cannot be applied to (Rational)
1 + (new Rational(1, 2))
^
RationalにIntを足してもtype errorになって使えない。
Rationalの + methodのparameterにIntが定義されていないから。
scala> (new Rational(1, 2)) + 1
<console>:9: error: type mismatch;
found : Int(1)
required: Rational
(new Rational(1, 2)) + 1
^
implicit conversionを使うときは下記をimportする。
importしないとwarningが出る。implicitの使い過ぎの抑制のため。
scala> import scala.language.implicitConversions
Int=>Rational型変換関数をimplicitで宣言する。
scala> implicit def int2rational(x: Int) = new Rational(x)
receiver Intに対応出来るmethodがないと、compilerが変換関数を検索。
int2rational(1)に置き換えて実行される。
scala> 1 + (new Rational(1, 2))
res3: Rational = 3/2
receiver Rationalに対応出来るparameterがないと、compilerが変換関数を検索。
int2rational(1)に置き換えて実行される。
scala> (new Rational(1, 2)) + 1
res4: Rational = 3/2
parameterの型変換 > receiverの型変換の優先順位で実施される。
21.2 Rules for implicits
Marking Rule
implicitで定義されている場合のみ。
variable, function, object何でもimplicitに出来る。
Scope Rule
single identifierとしてscope内にある場合のみ。
変換関数をimportでscope内に入れる必要がある。
更にsingle identifierとなるように入れる必要がある。
path.convertはNG。convertになるようにimportする。
companion objectは例外としてsingle identifierではなくても検索される。
source, target type両方のcompanion objectがimport不要。
importしていない所にあるimplicitまでは把握しきれない。
Non-Ambiguity Rule
変換関数が一意に決まる場合のみ。
二つ以上の候補がある場合は適用されない。
?? より内側のscopeにあるなど、優先度がある??
One-at-a-time Rule
一回につき一段の変換しない。
convert1(convert2(x))のような多段の変換はしない。
compile時間が長くなるし、プログラマが把握しきれなくなるから。
implicit parameterを持つimplicitは例外。(後述)
Explicits-First Rule
無変換でtype checkが通ったら変換しない。
型変換関数をexplicitに書いてもOK。
冗長さと明確さのトレードオフ。ケースバイケースで判断する。
implicit conversion(変換関数)にも任意の名前を付けられる。
implicitに適用されているときはtypeしか見ないので名前な何でも良い。
explicitに適用したいときに使う。
自分の考えている変換関数がそこで使えるかの確認にも使える。
特定の変換関数のみをimportする時にも使える。
21.3 Implicit conversion to an expected type
type違いの時にtype変換関数があると適用される。
3つのimplicitの中で一番優先的に適用される。
通常は制約の多い(低機能)typeからより適用範囲(高機能)の広いtypeに変換する。
Int -> doubleへの変換はOK。逆はnot recommended。
** より機能追加されたsub typeを定義して、それに変換する。
21.4 Converting the receiver
receiverにmemberがなかったらmemberがあるtypeへの変換関数が適用される。
既存class階層に新しいclassを追加しやすくなる。
DSLをサポートしやすくなる。
Interoperating with new types
21.1のRationalの例を参照。
Simulating new syntax
文法を拡張した様に見せかける場合に有用。
Mapの`->`は組み込むの文法ではなくて単なるmethod!!
Map(1 -> "one", 2 -> "two", 3 -> "three")
Predefのclass ArrowAssocで->とimplicit any2ArrowAssocが定義されている。
1 -> "one"は
any2ArrowAssoc(1).->("one")と変換されて
(1, "one")になる。
"rich wrappers"はライブラリが文法を拡張した様に見せかける時によく使う。
receiverに存在しないmethodを適用しているときはimplicitの可能性が高い。
Richxxxといclassがあったら、xxxにimplicitで機能追加している可能性が高い。
これはDSLを定義する際に有用
他の言語だとexternal DSLが必要な場合でもscalaならinternalに定義出来る。
21.5 Implicit parameters
curry化した最後のパラメータリストそのもが省略されているときに、パラメータのtypeのobjectがあったら適用される。
適用したくない時はplace holder _を付けて省略ではない事を伝える必要あり。
implicit parameterの型は特殊であるものにすべき。
補完対象を型だけで決めるので重複や想定外の適用を避けるため。
型定義からimplicit parameterの役割が分かるような型を付けるべき。
21.6 View bounds
implicit parameterで渡される関数でimplicit conversionが出来る。
この場合はanonymousで良い。
[T <% Ordered[T]]
T => Ordered[T] がanonymousの関数値として適用されて、使用される。
implicit parameterは補完する/される両方で使われる。
省略した時に他のimplicit宣言されている値で補完される。
implicit parameterのscope内でimplicitが必要であれば適用される。
外側のscopeに同じsignatureのimplicitが定義されていてもhideされる。
implicitは主な使用目的はtypeのconversion
implicit parameterは値の補完にも使えるが、通常は型変換関数値の補完。
View bounds and upper bounds
<%は<:の適用範囲を更に広げたものと考える事が出来る。
sub typeの場合はそのまま使用される。
sub typeでない場合は変換関数が検索、適用されて使用される。
sub typeであるか変換関数があるかどちらかの条件を満たしていれば適用できる。
21.7 Debugging implicits
implicitは強力だが正しく使うのもdebugするのも難しい場合がある。
implicitが適用されない理由が分からない場合
implicitを使わずにexplicitで書いてみる。
エラーになればimplicitの問題ではない。
エラーにならなかったらimplicitの適用ルールを確認する。
どのimplicitが使われているかはcompile option -Xprint:typerで出力出来る。
scalac -Xprint:typerだとcomiple時に適用される。
scala -Xprint:typerでREPLでの適用結果も出力できる。
沢山出力されるので注意が必要。
?? どういうimplicitが宣言済か把握するには?
?? implicitを抑制する方法は??
21.8 Conclusion
implicitは実行時ではなくてcompile時に変換、チェック出来る。
implicitは強力だが乱用は避けるべき。
implicitを使う前にinheritance, mixin, overloading等で代替出来ないかを考える。
全部がダメで、更にコードが無駄冗長な場合は、implicitの使い所になるかも。
2014年6月15日日曜日
Functional Programming Principles in Scala (Week 7: Lazy Evaluation)
==== Lectures ====
Lecture 7.1 - Structural Induction on Trees (15:10)
[IntSets]
BinaryTree構造のIntSetsの実装の正しさの証明をInduction(Reasoning)で行う。
制約条件を上げて一つずつ置き換えで証明する。
Online講義ではoptional。大学ではテストに出る?
Lecture 7.2 - Streams (12:12)
[Stream]
Stream: tailが必要な時のみに評価されるList。
不要な部分をあらかじめ計算してしまうのを抑制できる。
無限集合も扱える。
遅延評価。tailを関数値として未評価で保持している?
consのtailにby-name parameterを使う。Listでは普通のparameter。
Listのmethodはほとんど使える。
x :: xs はListになる。
x #:: xs だとStreamになる。
Streamは過去にアクセスした要素を覚えているので、メモリを消費する。
Iteratorは使い捨てなのでメモリは消費しないが、複数回要素にアクセスできない。
Lecture 7.3 - Lazy Evaluation (11:38)
[lazy]
遅延評価。必要な時に計算。
一度計算したら結果を保持して再利用。何回計算しても同じなのが重要。
by-nameでは毎回計算する??
副作用があると計算順序やタイミングが読みにくいので使いにくい。
lazy val x = exprは一回しか計算されない。def x = expr は毎回計算。
Stream.consのby-name parameterもlazy valにすれば効率が良くなる。
Lecture 7.4 - Computing with Infinite Sequences (9:01)
[Infinite Streams]
def from(n: Int): Stream[Int] = n #:: from(n+1)
from(n+1)がlazyで必要になるまで実行されない。
終了条件が必要ない。
Eratosthenesの篩もそのまま実施出来る。
√2のような無限小数も求める事が出来る。
Lecture 7.5 - Case Study: the Water Pouring Problem (31:45)
[Water Pouring Problem]
既にpyhtonで解かれた例がある。
pure functionalで一般的な解法。
Streamを使う。
recursiveを同等のfoldで表現出来る場合が多い。慣れないと難しいかも。
Name evrything you can.
natural scopes.
refactoring.
Lecture 7.6 - Course Conclusion (5:34)
[Conclusion]
効果関数。パターンマッチング、不変集合、参照透過、strict/lazy/by-name評価
更なるtopic: mixed with mutable, parallelism, DSL
==== Assignments ====
[Bloxorz]
flashのゲームみたい。そのソルバーを開発する。古典的な人工知能っぽい問題。
最終課題という事でそこそこの規模もあり、複数のファイルで構成されてる。
Water Pouring Problemと同様に幅優先探索で解を求める。
1回目の提出では解が存在しない場合に無限ループに入っていて減点。19.3/20
2回目の提出で満点!!
gradingは通ったが、fromの実装が講師の意図通りなのかちょっと不安。
Water Pouring Problemとほぼ同様にしてみたが。。。
[IntelliJ]
workspaceの使い方がわからない。名前空間はどうなっている?
debugボタンで実行すればbreak pointが動いた。
イマイチ効率の良い使い方は分からない。
==== Etc. ====
[全体を振り返って]
予習をしていたこともあり、内容はそんなに難しくなったので、初めてのMOOCに丁度良かった。
あまり難しくない割にはAssignmentは結構時間が掛かってしまった。
講義はもう少し詳しく見た方が良かったかもしれない。
ポイントは押えたつもりだが、個々の例題などは追い切れていない。
プログラムを実行するという事は「置き換え」だという事が印象に残った。
置き換え回数が計算量になる。
副作用が無ければどの部分からどの順序で置き換えても良い。
これが関数型プログラミングと並列計算の相性の良い所。
==== Log ====
2014/06/09 00:50 Lecture
2014/06/10 00:30 Assignment
2014/06/11 00:50 Lecture
2014/06/13 00:20 Assignment
2014/06/14 04:30 Assignment
Lecture 7.1 - Structural Induction on Trees (15:10)
[IntSets]
BinaryTree構造のIntSetsの実装の正しさの証明をInduction(Reasoning)で行う。
制約条件を上げて一つずつ置き換えで証明する。
Online講義ではoptional。大学ではテストに出る?
Lecture 7.2 - Streams (12:12)
[Stream]
Stream: tailが必要な時のみに評価されるList。
不要な部分をあらかじめ計算してしまうのを抑制できる。
無限集合も扱える。
遅延評価。tailを関数値として未評価で保持している?
consのtailにby-name parameterを使う。Listでは普通のparameter。
Listのmethodはほとんど使える。
x :: xs はListになる。
x #:: xs だとStreamになる。
Streamは過去にアクセスした要素を覚えているので、メモリを消費する。
Iteratorは使い捨てなのでメモリは消費しないが、複数回要素にアクセスできない。
Lecture 7.3 - Lazy Evaluation (11:38)
[lazy]
遅延評価。必要な時に計算。
一度計算したら結果を保持して再利用。何回計算しても同じなのが重要。
by-nameでは毎回計算する??
副作用があると計算順序やタイミングが読みにくいので使いにくい。
lazy val x = exprは一回しか計算されない。def x = expr は毎回計算。
Stream.consのby-name parameterもlazy valにすれば効率が良くなる。
Lecture 7.4 - Computing with Infinite Sequences (9:01)
[Infinite Streams]
def from(n: Int): Stream[Int] = n #:: from(n+1)
from(n+1)がlazyで必要になるまで実行されない。
終了条件が必要ない。
Eratosthenesの篩もそのまま実施出来る。
√2のような無限小数も求める事が出来る。
Lecture 7.5 - Case Study: the Water Pouring Problem (31:45)
[Water Pouring Problem]
既にpyhtonで解かれた例がある。
pure functionalで一般的な解法。
Streamを使う。
recursiveを同等のfoldで表現出来る場合が多い。慣れないと難しいかも。
Name evrything you can.
natural scopes.
refactoring.
Lecture 7.6 - Course Conclusion (5:34)
[Conclusion]
効果関数。パターンマッチング、不変集合、参照透過、strict/lazy/by-name評価
更なるtopic: mixed with mutable, parallelism, DSL
==== Assignments ====
[Bloxorz]
flashのゲームみたい。そのソルバーを開発する。古典的な人工知能っぽい問題。
最終課題という事でそこそこの規模もあり、複数のファイルで構成されてる。
Water Pouring Problemと同様に幅優先探索で解を求める。
1回目の提出では解が存在しない場合に無限ループに入っていて減点。19.3/20
2回目の提出で満点!!
gradingは通ったが、fromの実装が講師の意図通りなのかちょっと不安。
Water Pouring Problemとほぼ同様にしてみたが。。。
[IntelliJ]
workspaceの使い方がわからない。名前空間はどうなっている?
debugボタンで実行すればbreak pointが動いた。
イマイチ効率の良い使い方は分からない。
==== Etc. ====
[全体を振り返って]
予習をしていたこともあり、内容はそんなに難しくなったので、初めてのMOOCに丁度良かった。
あまり難しくない割にはAssignmentは結構時間が掛かってしまった。
講義はもう少し詳しく見た方が良かったかもしれない。
ポイントは押えたつもりだが、個々の例題などは追い切れていない。
プログラムを実行するという事は「置き換え」だという事が印象に残った。
置き換え回数が計算量になる。
副作用が無ければどの部分からどの順序で置き換えても良い。
これが関数型プログラミングと並列計算の相性の良い所。
==== Log ====
2014/06/09 00:50 Lecture
2014/06/10 00:30 Assignment
2014/06/11 00:50 Lecture
2014/06/13 00:20 Assignment
2014/06/14 04:30 Assignment
2014年6月14日土曜日
親密さとモラルハザード
身内の様な親密な関係だと、モラルハザードに陥りやすい?
モラルハザードは「誰も見ていないから大丈夫」と言うような他人の監視がない場合に発生しやすいが、身内からの監視のみの場合は「身内が相手なら大丈夫」と甘えからモラルハザードになりやすい?
子供に思うように勉強などの親が必要と思っていることをさせられないので、上記の様に考えてみたが、あまり言い訳にならない様な気がする。。。
子供と一緒にいると、自分が感情的で非合理的であることを、良い意味で思い知らされる。
モラルハザードは「誰も見ていないから大丈夫」と言うような他人の監視がない場合に発生しやすいが、身内からの監視のみの場合は「身内が相手なら大丈夫」と甘えからモラルハザードになりやすい?
子供に思うように勉強などの親が必要と思っていることをさせられないので、上記の様に考えてみたが、あまり言い訳にならない様な気がする。。。
子供と一緒にいると、自分が感情的で非合理的であることを、良い意味で思い知らされる。
ツールの進歩と人間のスキル
最近のツール(機械)進歩は目覚ましいものがある。
将棋でプロの棋士に勝利するなど、人間の得意領域とされていた部分でもコンピュータが優位になる部分が出てきている。
こういう状況の中、ツールを使いこなせるかが人間のスキルとしてはより重要になってくる。
ツールに望ましいアウトプットを出させるためにはツールの特性に人が合わせる必要があり、これが今後の人のスキルとして重要になる。
機械に人間が合わせるのはバカらしい気もするが、機械は人間程融通が利かないのでより融通が利く人間が合わせないと能力を発揮できない。
融通に関してはしばらくは人間の方が機械より上だと思う。
仮に機械が人間並みに融通が利くようになっても、他の人間に何かを頼むときに、相手の特性を理解して頼めるかどうかが重要と言うのと同じように、やはり機械の特性への理解と適応は重要なスキルとして残りそう。
ただ人間以上に機械の方が融通が利くようになったらどうなるんだろう?
誰でも等しく使いこなすことが出来る状態になるのかもしれない。
そして多くの面で人間より機械の方が能力が高くなってしまったら?
こうしたいという「意思」だけは最後まで人間に残るはず?
SF等で良く語られる哲学的な問題で、色々と思考を巡らせるのは面白い。
将棋でプロの棋士に勝利するなど、人間の得意領域とされていた部分でもコンピュータが優位になる部分が出てきている。
こういう状況の中、ツールを使いこなせるかが人間のスキルとしてはより重要になってくる。
ツールに望ましいアウトプットを出させるためにはツールの特性に人が合わせる必要があり、これが今後の人のスキルとして重要になる。
機械に人間が合わせるのはバカらしい気もするが、機械は人間程融通が利かないのでより融通が利く人間が合わせないと能力を発揮できない。
融通に関してはしばらくは人間の方が機械より上だと思う。
仮に機械が人間並みに融通が利くようになっても、他の人間に何かを頼むときに、相手の特性を理解して頼めるかどうかが重要と言うのと同じように、やはり機械の特性への理解と適応は重要なスキルとして残りそう。
ただ人間以上に機械の方が融通が利くようになったらどうなるんだろう?
誰でも等しく使いこなすことが出来る状態になるのかもしれない。
そして多くの面で人間より機械の方が能力が高くなってしまったら?
こうしたいという「意思」だけは最後まで人間に残るはず?
SF等で良く語られる哲学的な問題で、色々と思考を巡らせるのは面白い。
2014年6月12日木曜日
ポジティブ思考とスキル習得
自分の手持ちの手法を「この部分は使えるかもしれない」と言うスタンスを取れれば、手法の適用分野が広がることに加えて、新しい手法に出会った時に肯定して自分の引き出しを増やすことが出来る。
自分の手持ちの手法を「この部分が合わないから使えない」と言うスタンスを取ってしまうと、手法の適用分野が狭くなってしまう上に、新しい手法に出会っても否定してしまって自分の引き出しを増やせない。
こうやって、同じ環境でも、出来る人は好循環で益々出来るようになり、出来ない人は何時まで経っても出来るようにならない。
結局、ポジティブに物事を捉えられるかが重要になる。
自分の手持ちの手法を「この部分が合わないから使えない」と言うスタンスを取ってしまうと、手法の適用分野が狭くなってしまう上に、新しい手法に出会っても否定してしまって自分の引き出しを増やせない。
こうやって、同じ環境でも、出来る人は好循環で益々出来るようになり、出来ない人は何時まで経っても出来るようにならない。
結局、ポジティブに物事を捉えられるかが重要になる。
2014年6月11日水曜日
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (Week 2)
==== Lecture ====
Section 1 Module 2 Part 4: Java Synchronization and Scheduling Classes
Reentrant lock, Reentrant readwrite lock, semaphore, conditional object, countDown Latch
性能問題についての考察も必要。
Section 1 Module 2 Part 5: Java ReentrantLock
[ReentrantLock - Java]
排他ロック
bracketed: lockする人と解除する人が同じ。
bridge pattern: GoF
fair, non-fair: lockの獲得方法。
fairだと待ち時間が長いthread優先。non-fairは順番の保証なしだが軽い。
recursive lock: 同一threadからの再取得可能。
javaのbuilt-in機能よりは拡張されている(interrupt, non-blocking, timed lock acquisition)
[ArrayBlokingQueue - Android]
Data menberをvolatileにする必要ない。monitor lockの仕組みでcacheの更新を保証。
Section 1 Module 2 Part 6: Java ReentrantReadWriteLock
[ReentrantReadWriteLock - Java]
synchronization mechanism: 同時に複数のthreadが同じ共有資源にアクセス。
あるthreadでwriteしている時は他threadからはread/write出来なくする。
writeよりreadが多いmulti-core環境での性能向上に貢献する。
bridge pattern - GoF: AbstractQueuedSynchronizerの機能を継承。fair/non-fairを共通インタフェースで実装。
[BluetoothSocket - Android]
closable interface
全員が使っていない時にcloseするのにread-write lockが使える。
Section 1 Module 2 Part 7: Java Semaphore
[Semaphore - Java]
有限個数の共有資源へのアクセス。
bracketed: bracketed以外の使い方も出来る。
bridge pattern: cube synchronizer classから継承。fair/non-fairを共通インタフェースで実装。
blockingはsleepを使う。spinより末場合はoverhead大きい。
[VideoEditor - Android]
fair acquisition model
bracketedではない。backgroundでtakeしてuser interfaceでgiveする。
間違いやすいので主にunit testに限定されて他ではあまり見かけない。
Section 1 Module 2 Part 8: Java ConditionObject
[ConditionObject - Java]
synchronization and scheduling mechanism
guarded suspension patternを実装するために使う。
built-in monitor objectは一つしか作れないが、ConditionObjectは沢山作れる。
[Arrayblockingqueue]
Section 1 Module 2 Part 9: Java CountDownLatch
[CountDownLatch - Java]
barrier synchronization
一つのthreadの完了を複数で待ったり、複数のthreadの完了を一つのthreadで待ったり。
bridge-pattan: AbstractQueuedSynchronizerから機能を継承して所有。
カウントは通常はreset出来ない。一回使い切り。
CyclicBarrierでは待ち合わせが完了すると自動的にresetされる。固定数のthreadでお互いに待つ時に使う。
[Contacts Provider - Android]
初期化完了待ちにCountDownLatchを使う。
[bridge-pattan - GoF]
複数の継承関係がある場合に、片方の属性を別の継承ツリーに委譲して所有する。
縦横問題。
Section 1 Module 2 Part 10- Java Synchronization and Scheduling Example (Part 1)
[exapmle: ping pong - Java]
template method, strategy, factory method: reusable,flexible, portable
Section 1 Module 2 Part 11- Java Synchronization and Scheduling Example (Part 2)
[exapmle: ping pong - Java]
strategy pattern: platform strategy print method
template method pattern: the acquire and release
factory method: semaphore based or condition object based
ConditionObject base: more flexible, to print multiple ping or pong strings
Section 1 Module 2 Part 12- Java Built-in Monitor Objects
[Java built-in monitor object]
Java synchronized keyword: synchronized同士の排他実行。変化が他から見える。
synchronizedだけだとqueueが空や一杯の時のblockingが出来ない。
built-in monitor object: JVMに実装されているblokingと通知の仕組み
one wait queueしか持てない
Android's JVMではmonitor objectをPOSIXのmutual lockやcondition variableで実装。
nested monitor lockout problem
notify allの時誰がwake upするかは実装依存。
==== Quiz ====
Quizの内容から大よそLectureの内容が想像できる。
今回はJavaの同期のための仕組みについて。
lock(spin, sleep, reentrant, readwrite), binary/count semaphore, condition-object, synchronize
ping-pong programの話もあり、課題とも関係してそう。
Lectureを全部見終わってからまとめてQuizに挑戦。3回目で52/52獲得。
==== Assignment ====
[Week-2-Assignment-1]
ReentrantReadWriteLockを使う課題。
ReentrantReadWriteLockの説明は下記にある。
http://tutorials.jenkov.com/java-util-concurrent/readwritelock.html
とても短くて簡素な説明のみ。
BuggyLongTest.java
をjava applicationとして実施してfailする事を確認。
とても簡単で20分程度で書けてJUnitもpassしたが、eclipseのwarningが出ている。
CourseのFAQを調べると既に質問されている事項だった。
ただ、これはLectureを注意深く見ても気が付けないと思うが。。。
また、Assignment-Description.txtの記載も微妙で、それもFAQで既に聞いている人がいた。
上記の様な所で悩んで結局予想以上に時間を使ってしまった。
[Peer Evaluation]
Student 1
Warning: The import java.util.concurrent.locks.Lock is never used.
catchしてe.printStackTrace();している。
this.mValue++;等thisを使ってる。でもmRWLockはthisを使っていないなんで?
long value = 0;で初期化している。
Student 2
間違って変更前ファイルを提出している。。。
Student 3
Warning: The import java.util.concurrent.locks.Lock is never used.
try/finallyを使っていない。ただ、evaluationにはどちらでもよいとあり。
defaultではなくてfairで初期化してた。
indentが違うので見づらい。
UnitTestの実行に凄く時間が掛かった。fairにしているからの模様。
Student 4
Warning: The import java.util.concurrent.locks.Lock is never used.
try/finallyを使っていない。ただ、evaluationにはどちらでもよいとあり。
finalをつけている。good。初期化している。thisは使っていない。
Student 5
Warning: The import java.util.concurrent.locks.Lock is never used.
try/finallyを使っていない。ただ、evaluationにはどちらでもよいとあり。
初期化したりしなかったり。thisは使っていない。
[Self Evaluation]
当然満点。ただ、初期化は行った方がよいかも or final? thisは微妙な所。
[Results]
満点で完了!!
[etc.]
5人分のpeer reviewが必要。やらなかった場合は20%のpenalty。
先週はpeer reviewをやらないと自分のevaluationが出来ないとあった気がするが。
今回はthisや初期化やfinal等他の人のコードが参考になって良かった。
==== Etc ====
排他制御、同期制御は普段からよく使うので特に難しくはない。
まだJavaの比率が高くてAndroidの比率は少ない。
排他や同期の概念を説明するためのプログラムと関係ない例が出てきて面白い。
多くのLectureが同じパターンの構成になっている。パターンの講義だから?
==== log ====
2014/05/22 Quiz 00:20
2014/05/22 Lecture 01:00
2014/05/23 Lecture 00:25
2014/05/23 Lecture 02:30
2014/05/24 Quiz 00:15
2014/05/25 Assignments 02:00
2014/06/05 Evaluation 01:15
2014/06/11 Results 00:10
Section 1 Module 2 Part 4: Java Synchronization and Scheduling Classes
Reentrant lock, Reentrant readwrite lock, semaphore, conditional object, countDown Latch
性能問題についての考察も必要。
Section 1 Module 2 Part 5: Java ReentrantLock
[ReentrantLock - Java]
排他ロック
bracketed: lockする人と解除する人が同じ。
bridge pattern: GoF
fair, non-fair: lockの獲得方法。
fairだと待ち時間が長いthread優先。non-fairは順番の保証なしだが軽い。
recursive lock: 同一threadからの再取得可能。
javaのbuilt-in機能よりは拡張されている(interrupt, non-blocking, timed lock acquisition)
[ArrayBlokingQueue - Android]
Data menberをvolatileにする必要ない。monitor lockの仕組みでcacheの更新を保証。
Section 1 Module 2 Part 6: Java ReentrantReadWriteLock
[ReentrantReadWriteLock - Java]
synchronization mechanism: 同時に複数のthreadが同じ共有資源にアクセス。
あるthreadでwriteしている時は他threadからはread/write出来なくする。
writeよりreadが多いmulti-core環境での性能向上に貢献する。
bridge pattern - GoF: AbstractQueuedSynchronizerの機能を継承。fair/non-fairを共通インタフェースで実装。
[BluetoothSocket - Android]
closable interface
全員が使っていない時にcloseするのにread-write lockが使える。
Section 1 Module 2 Part 7: Java Semaphore
[Semaphore - Java]
有限個数の共有資源へのアクセス。
bracketed: bracketed以外の使い方も出来る。
bridge pattern: cube synchronizer classから継承。fair/non-fairを共通インタフェースで実装。
blockingはsleepを使う。spinより末場合はoverhead大きい。
[VideoEditor - Android]
fair acquisition model
bracketedではない。backgroundでtakeしてuser interfaceでgiveする。
間違いやすいので主にunit testに限定されて他ではあまり見かけない。
Section 1 Module 2 Part 8: Java ConditionObject
[ConditionObject - Java]
synchronization and scheduling mechanism
guarded suspension patternを実装するために使う。
built-in monitor objectは一つしか作れないが、ConditionObjectは沢山作れる。
[Arrayblockingqueue]
Section 1 Module 2 Part 9: Java CountDownLatch
[CountDownLatch - Java]
barrier synchronization
一つのthreadの完了を複数で待ったり、複数のthreadの完了を一つのthreadで待ったり。
bridge-pattan: AbstractQueuedSynchronizerから機能を継承して所有。
カウントは通常はreset出来ない。一回使い切り。
CyclicBarrierでは待ち合わせが完了すると自動的にresetされる。固定数のthreadでお互いに待つ時に使う。
[Contacts Provider - Android]
初期化完了待ちにCountDownLatchを使う。
[bridge-pattan - GoF]
複数の継承関係がある場合に、片方の属性を別の継承ツリーに委譲して所有する。
縦横問題。
Section 1 Module 2 Part 10- Java Synchronization and Scheduling Example (Part 1)
[exapmle: ping pong - Java]
template method, strategy, factory method: reusable,flexible, portable
Section 1 Module 2 Part 11- Java Synchronization and Scheduling Example (Part 2)
[exapmle: ping pong - Java]
strategy pattern: platform strategy print method
template method pattern: the acquire and release
factory method: semaphore based or condition object based
ConditionObject base: more flexible, to print multiple ping or pong strings
Section 1 Module 2 Part 12- Java Built-in Monitor Objects
[Java built-in monitor object]
Java synchronized keyword: synchronized同士の排他実行。変化が他から見える。
synchronizedだけだとqueueが空や一杯の時のblockingが出来ない。
built-in monitor object: JVMに実装されているblokingと通知の仕組み
one wait queueしか持てない
Android's JVMではmonitor objectをPOSIXのmutual lockやcondition variableで実装。
nested monitor lockout problem
notify allの時誰がwake upするかは実装依存。
==== Quiz ====
Quizの内容から大よそLectureの内容が想像できる。
今回はJavaの同期のための仕組みについて。
lock(spin, sleep, reentrant, readwrite), binary/count semaphore, condition-object, synchronize
ping-pong programの話もあり、課題とも関係してそう。
Lectureを全部見終わってからまとめてQuizに挑戦。3回目で52/52獲得。
==== Assignment ====
[Week-2-Assignment-1]
ReentrantReadWriteLockを使う課題。
ReentrantReadWriteLockの説明は下記にある。
http://tutorials.jenkov.com/java-util-concurrent/readwritelock.html
とても短くて簡素な説明のみ。
BuggyLongTest.java
をjava applicationとして実施してfailする事を確認。
とても簡単で20分程度で書けてJUnitもpassしたが、eclipseのwarningが出ている。
CourseのFAQを調べると既に質問されている事項だった。
ただ、これはLectureを注意深く見ても気が付けないと思うが。。。
また、Assignment-Description.txtの記載も微妙で、それもFAQで既に聞いている人がいた。
上記の様な所で悩んで結局予想以上に時間を使ってしまった。
[Peer Evaluation]
Student 1
Warning: The import java.util.concurrent.locks.Lock is never used.
catchしてe.printStackTrace();している。
this.mValue++;等thisを使ってる。でもmRWLockはthisを使っていないなんで?
long value = 0;で初期化している。
Student 2
間違って変更前ファイルを提出している。。。
Student 3
Warning: The import java.util.concurrent.locks.Lock is never used.
try/finallyを使っていない。ただ、evaluationにはどちらでもよいとあり。
defaultではなくてfairで初期化してた。
indentが違うので見づらい。
UnitTestの実行に凄く時間が掛かった。fairにしているからの模様。
Student 4
Warning: The import java.util.concurrent.locks.Lock is never used.
try/finallyを使っていない。ただ、evaluationにはどちらでもよいとあり。
finalをつけている。good。初期化している。thisは使っていない。
Student 5
Warning: The import java.util.concurrent.locks.Lock is never used.
try/finallyを使っていない。ただ、evaluationにはどちらでもよいとあり。
初期化したりしなかったり。thisは使っていない。
[Self Evaluation]
当然満点。ただ、初期化は行った方がよいかも or final? thisは微妙な所。
[Results]
満点で完了!!
[etc.]
5人分のpeer reviewが必要。やらなかった場合は20%のpenalty。
先週はpeer reviewをやらないと自分のevaluationが出来ないとあった気がするが。
今回はthisや初期化やfinal等他の人のコードが参考になって良かった。
==== Etc ====
排他制御、同期制御は普段からよく使うので特に難しくはない。
まだJavaの比率が高くてAndroidの比率は少ない。
排他や同期の概念を説明するためのプログラムと関係ない例が出てきて面白い。
多くのLectureが同じパターンの構成になっている。パターンの講義だから?
==== log ====
2014/05/22 Quiz 00:20
2014/05/22 Lecture 01:00
2014/05/23 Lecture 00:25
2014/05/23 Lecture 02:30
2014/05/24 Quiz 00:15
2014/05/25 Assignments 02:00
2014/06/05 Evaluation 01:15
2014/06/11 Results 00:10
2014年6月8日日曜日
bookmarklet作成のメモ
飛行機のチケットの予約をする時に、家族全員の名前などを毎回入れるは結構面倒。
特にお盆休みや正月に帰省する時は予約開始時間から直ぐに予約が一杯になるので、もたもた入力している暇も無い。
これまではOperaのextensionを使って入力していたが、Chromeに乗り換えたので今回はbookmarkletを作ってみることにした。
参考にしたのは下記のサイト
ブックマークレット／Bookmarkletの作り方
ブックマークレットを作るときのTips
Bookmarklet を作ってみる
jQueryも使えるようなのでそのうち試してみたい。
ブックマークレットで jQuery を使う魔法の 210 文字
[実際に作ったbookmarklet]
skymarkの予約ページに名前などの情報をセットするjavascriptを作成した。
これをChromeのbookmarkにURLのフィールドに貼り付けたら動いた。
Chromeは6k文字,IEでも2k文字程度は大丈夫な様子。
名前などをなるべく短く書こうとしたが、ちょっとしたことならそこまで無理はしなくて良いかも。
上記のbookmarkletで0,6k文字程度。
ローカル変数の宣言(var)をする代わりに関数の引数を増やすとvarの文字列を省略出来る。
[一行制限]
全てを一行で書く必要があるようだが、Chromeでは上記を改行ありのままでURLフィールドに貼り付けたら勝手に改行が削除されて上手く動いた。
他のブラウザでは上手く行かないのかもしれない。
[URIエンコード]
制御文字(スペース、引用符)や日本語はURIエンコードする必要がある様だが、ChromeではエンコードしないでそのままURLフィールドに貼り付けても上手く動いた。
他のブラウザでは上手く行かないのかもしれない
[名前空間]
bookmarkletは元ページのJavaScriptと同じ名前空間で動作するので、無名関数等使ってbookmarklet内の名前が外側から見えないようにする必要がある。
特にお盆休みや正月に帰省する時は予約開始時間から直ぐに予約が一杯になるので、もたもた入力している暇も無い。
これまではOperaのextensionを使って入力していたが、Chromeに乗り換えたので今回はbookmarkletを作ってみることにした。
参考にしたのは下記のサイト
ブックマークレット／Bookmarkletの作り方
ブックマークレットを作るときのTips
Bookmarklet を作ってみる
jQueryも使えるようなのでそのうち試してみたい。
ブックマークレットで jQuery を使う魔法の 210 文字
[実際に作ったbookmarklet]
skymarkの予約ページに名前などの情報をセットするjavascriptを作成した。
これをChromeのbookmarkにURLのフィールドに貼り付けたら動いた。
javascript:(function(d,v,n,c){
v=function(n,v){d.getElementsByName(n)[0].value=v};
v("tel","xxxxxxxx");
v("mailAddressPC","xxxxxxxx");
v("mailAddressMB","xxxxxxxx");
c=function(i){d.getElementById(i).checked="checked"};
c("callerSame");
n=function(x,i,r,j,a,s){v(x+"LastName"+i,"xxxx");v(x+"LastNameJ"+i,"xxxx");v(x+"FirstName"+i,r);v(x+"FirstNameJ"+i,j);v(x+"Age"+i,a);c(x+"Sex_"+s+i)};
n("a",0,"xxxx","xx",99,"M");
n("a",1,"xxxx","xx",88,"F");
n("ca",0,"xxxx","xx",9,"F");
n("c",0,"xxxx","xx",4,"M");
}(document))
[文字数制限]Chromeは6k文字,IEでも2k文字程度は大丈夫な様子。
名前などをなるべく短く書こうとしたが、ちょっとしたことならそこまで無理はしなくて良いかも。
上記のbookmarkletで0,6k文字程度。
ローカル変数の宣言(var)をする代わりに関数の引数を増やすとvarの文字列を省略出来る。
[一行制限]
全てを一行で書く必要があるようだが、Chromeでは上記を改行ありのままでURLフィールドに貼り付けたら勝手に改行が削除されて上手く動いた。
他のブラウザでは上手く行かないのかもしれない。
[URIエンコード]
制御文字(スペース、引用符)や日本語はURIエンコードする必要がある様だが、ChromeではエンコードしないでそのままURLフィールドに貼り付けても上手く動いた。
他のブラウザでは上手く行かないのかもしれない
[名前空間]
bookmarkletは元ページのJavaScriptと同じ名前空間で動作するので、無名関数等使ってbookmarklet内の名前が外側から見えないようにする必要がある。
2014年6月7日土曜日
Functional Programming Principles in Scala (Week 6: Collections)
==== Lectures ====
Lecture 6.1 - Other Collections (20:45)
[Vector]
32個のユニットで深くなる木構造。
Listよりランダムアクセス、bulk operationに適している。
O(log(N))
[Seq]
List,Vector,Rangeの親クラス。さらにSetと共通の親はIterable
filter,map,flatMap,exists,forall,zip,unzip,sum,product,max,min等が使える。
x => x match { case p1 => e1 ... } は { case p1 => 1 e1 ... } とも書ける。
Lecture 6.2 - Combinatorial Search and For-Expressions (13:12)
[for]
Nestしているcollectionはmapやfilterを多重に使うよりもforとyieldを使った方が分かりやすい。
Chapter 23 of Programming in Scala, First Edition: For Expressions Revisited
Lecture 6.3 - Combinatorial Search Example (16:54)
[Set]
Iterableのsub type。map等Seqの操作の大部分が使える。
unordered, not duplicate, fundamental operation is contains
[N-Queen問題]
forの combinational searchの例としてSetも使って解いてみる。
Lecture 6.4 - Queries with For (7:50)
[for]
forの combinational search はSQLなどデータベースのQueryと同じ。
search元のデータをSetにすればsearch結果もSetになる。
Lecture 6.5 - Translation of For (11:23)
[for]
forとmap, flatMap, filterの透過性について。
scalaのcompilerはforをmap, flatMap, lazy filter(withFilter)に変換している。
forの方が見やすいから。
同じアイデアが使われている。ScalaQuery, Slick, Microsoft's LINQ。
Lecture 6.6 - Maps (22:39)
[Map]
連想配列、辞書。
withDefaultで値が場合にdefault値を返すように出来る。
Map(1 -> "a", 2 -> "b") ++ Map(2 -> "c", 3 -> "d") は Map(1 -> "a", 2 -> "c", 3 -> "d")
ListにgroupBy(element => key)でke -> List(e1, e2...)のMapが作れる。
[Option]
None,Some(x) 値がない場合も統一的に扱える。
Mapのget methodを使えばOption typeが取れる。
Lecture 6.7 - Putting the Pieces Together (20:35)
[example of collection]
今週の課題の内容と似ている。辞書から可能なwordsを選ぶ。
既刊の本の問題から取っている。既に色々な言語(java, c, c++, python等)でテスト済。
スクリプト言語だと100loc, 他の言語だと200-300locの規模。そこそこのサイズ。
scala.io.Sourceで辞書をダウンロードして使う。
同じことは2回書かない様にする。元ネタを変換する。
境界条件から考える。nullや1個の時。
scala collectionsの利点: easy, concise, safe, fast, universal
==== Assignments ====
[Anagrams]
英語の綴りを変更して意味のある文を見つける事。
?? プログラムで意味があるかをどうやって判断する??
=> 単語の辞書が用意されている。
計算量がものすごく多くなりそうだが大丈夫か?
計算量を減らす追加課題もあるがとりあえず時間が無いのでパス。
毎回パズル的な問題で頭の体操としては面白い。
今回も1回目の提出で満点!!
[IntelliJ]
worksheetとプログラムと結果のずれがなくなった。
バージョンアップのせいか、コメントなしにしたせいか?
==== Etc. ====
Lectureは1.5倍速で字幕なしで見ている。大体は理解できている気がする。
Programming in Scala, First Editionの予習が追いついていない所が出てきた。
==== Log ====
2014/06/02 00:45 Lecture
2014/06/02 00:20 Lecture
2014/06/03 00:45 Lecture
2014/06/04 00:45 Lecture
2014/06/05 00:20 Assignments
2014/06/06 02:00 Assignments
2014/06/07 01:15 Assignments
Lecture 6.1 - Other Collections (20:45)
[Vector]
32個のユニットで深くなる木構造。
Listよりランダムアクセス、bulk operationに適している。
O(log(N))
[Seq]
List,Vector,Rangeの親クラス。さらにSetと共通の親はIterable
filter,map,flatMap,exists,forall,zip,unzip,sum,product,max,min等が使える。
x => x match { case p1 => e1 ... } は { case p1 => 1 e1 ... } とも書ける。
Lecture 6.2 - Combinatorial Search and For-Expressions (13:12)
[for]
Nestしているcollectionはmapやfilterを多重に使うよりもforとyieldを使った方が分かりやすい。
Chapter 23 of Programming in Scala, First Edition: For Expressions Revisited
Lecture 6.3 - Combinatorial Search Example (16:54)
[Set]
Iterableのsub type。map等Seqの操作の大部分が使える。
unordered, not duplicate, fundamental operation is contains
[N-Queen問題]
forの combinational searchの例としてSetも使って解いてみる。
Lecture 6.4 - Queries with For (7:50)
[for]
forの combinational search はSQLなどデータベースのQueryと同じ。
search元のデータをSetにすればsearch結果もSetになる。
Lecture 6.5 - Translation of For (11:23)
[for]
forとmap, flatMap, filterの透過性について。
scalaのcompilerはforをmap, flatMap, lazy filter(withFilter)に変換している。
forの方が見やすいから。
同じアイデアが使われている。ScalaQuery, Slick, Microsoft's LINQ。
Lecture 6.6 - Maps (22:39)
[Map]
連想配列、辞書。
withDefaultで値が場合にdefault値を返すように出来る。
Map(1 -> "a", 2 -> "b") ++ Map(2 -> "c", 3 -> "d") は Map(1 -> "a", 2 -> "c", 3 -> "d")
ListにgroupBy(element => key)でke -> List(e1, e2...)のMapが作れる。
[Option]
None,Some(x) 値がない場合も統一的に扱える。
Mapのget methodを使えばOption typeが取れる。
Lecture 6.7 - Putting the Pieces Together (20:35)
[example of collection]
今週の課題の内容と似ている。辞書から可能なwordsを選ぶ。
既刊の本の問題から取っている。既に色々な言語(java, c, c++, python等)でテスト済。
スクリプト言語だと100loc, 他の言語だと200-300locの規模。そこそこのサイズ。
scala.io.Sourceで辞書をダウンロードして使う。
同じことは2回書かない様にする。元ネタを変換する。
境界条件から考える。nullや1個の時。
scala collectionsの利点: easy, concise, safe, fast, universal
==== Assignments ====
[Anagrams]
英語の綴りを変更して意味のある文を見つける事。
?? プログラムで意味があるかをどうやって判断する??
=> 単語の辞書が用意されている。
計算量がものすごく多くなりそうだが大丈夫か?
計算量を減らす追加課題もあるがとりあえず時間が無いのでパス。
毎回パズル的な問題で頭の体操としては面白い。
今回も1回目の提出で満点!!
[IntelliJ]
worksheetとプログラムと結果のずれがなくなった。
バージョンアップのせいか、コメントなしにしたせいか?
==== Etc. ====
Lectureは1.5倍速で字幕なしで見ている。大体は理解できている気がする。
Programming in Scala, First Editionの予習が追いついていない所が出てきた。
==== Log ====
2014/06/02 00:45 Lecture
2014/06/02 00:20 Lecture
2014/06/03 00:45 Lecture
2014/06/04 00:45 Lecture
2014/06/05 00:20 Assignments
2014/06/06 02:00 Assignments
2014/06/07 01:15 Assignments
2014/5/26-6/6
==== 2014/5/26 ====
[#3good]
#codecademy Max Streak Count of 65 バッジ獲得!!
#codecademy jQuery Functions and Selectors バッジ獲得!!
#scalaをちょっとした文字列処理のスクリプト言語として使用してみた。
#Courseraの講義の前にimplicit parameterの章を予習出来た。
==== 2014/5/27 ====
[雑感]
ウォルター・ルーウィン教授の「NHK MIT白熱教室 第8回 星はどう生まれ どう死ぬのか？」を見た。
宇宙スケールの大きさや重さや距離等を身近なものと比較して説明していた。
イメージしやすくて面白かった。
アウトプットを意識しながら情報収集した方が良い。
アウトプットの機会は少ないから、意図的に増やすようにした方が良い。
何か見たり読んだりしたら、一言でも良いので思ったことをメモする様にするのが重要。
#scalaでhttpの取得が出来た。思ったより簡単だった。
[tips - win7]
タスクバーで右クリック、左クリック後にマウスを動かすとウインド選択が出る。
[MOOC]
http://chronicle.com/article/Major-Players-in-the-MOOC/138817/?cid=wc
coursera, udacity, edx, Khan AcademyがMOOCのmajorらしい。
[scala]
http://blog.kzfmix.com/entry/1255605525
scalaの標準libraryでhttp getをする方法。
http://www.mwsoft.jp/programming/scala/web_scraping.html
http://www.ne.jp/asahi/hishidama/home/tech/scala/xml.html
htmlをparseするのも何とか出来そう?
http://stackoverflow.com/questions/13146019/reading-password-from-console-in-scala
System.console()はcygwinやeclipseではnullになるので注意。
readLine()やSystem.inやio.Source.stdinは使える。
==== 2014/5/28 ====
ロジックツリーはドキュメントの網羅性改善にも役に立ちそう。
#Coursera posa-002 Week 1 peer and self evaluation 完了! 間違えないか心配だったので結構手間取った。
#Coursera progfun-004 Week 5完了! 今週はassignmentが休みだった。
[tips - eclipse]
http://devlights.hatenablog.com/entry/20121114/p2
http://futurismo.biz/archives/1256
http://devlights.hatenablog.com/entry/20121114/p2
http://www.eclipse.org/forums/index.php/t/316243/
eclipseでWinMergeを使う方法
[Programming in Scala, First Edition]
2014/5/28 00 chapter21 0/8
昨日使ったscala.io.Sourceの記載もあった。
復習と校正と分かった事を追記するために一度見直した方が良いが。。。
==== 2014/5/31 ====
#3good サーティーワンでアイスが31%offだった。
#3good つくばイオンのフードコートのパスタが美味しかった。
#3good サンといちご二人だけで近所のスーパーまで歩けた。
[畑の学校]
気温30度超で扱った。落花生の種蒔きと生き物観察
==== 2014/6/1 ====
エキスポセンターでもらったスチロールプレーン作成完了!! 思ったより難しかった。
サンの乳歯が更に２本抜けた!!
いちごの北海道一人旅計画進行!!
==== 2014/6/2 ====
久々にミスドを食べた!!
今日は涼しくて過ごしやすかった。
子供たちが起きている時間に帰れた。
[雑感]
単なる流し読みと、メモを取りながらの読むのでは時間、理解とも結構差がある様に感じる。
==== 2014/6/3 ====
bootcamp downloadプログラムをscalaで作成!! 初scala実用プログラム。
Edx系のDelftx(デルフト工科大学:オランダ)で秋にHaskellのMOOCを予定している。
facebookのlikeボタンを自動的に小さくするchrome extensionを作成!!
gitについて調べた。思ったより分かりやすい?
いちごが町内会でのキッザニアを無事に楽しんできたらしい。
==== 2014/6/5 ====
#Coursera #posa-002 Week 1のResultsは満点で無事に完了! 結構長かった。
#Coursera #posa-002 Week 3 Assignments提出!!
#Coursera #posa-002 Week 2 Evaluation
#bootcampを4か月ぶりに再開!!
javaのthisは殆どの人が必ず付けるようにしている訳ではないらしい。。。
gitとmercurialだとgitのshareが多いみたい。
Egitでmergetoolを使うにはlocalの変更を無い状態にしてからmergeする必要がある？
==== 2014/6/6 ====
久々に朝10時に出社だったので朝皆を見送れた。
#eclipse でformatterの設定方法が分かった!! 細かく設定できる。
[行動経済学]
Dan Arielyの行動経済学の白熱教室を見た。
やっぱり行動経済学は面白い。
人間の「怠惰」を甘く見てはいけない。想像以上に面倒を避ける傾向がある。
目標や目的などの大きな事よりも目の前の小さな環境の変化に行動は左右される。
小さな変化で良い行動へ導ける可能性がある。
gamificationに通じる。
[#3good]
#codecademy Max Streak Count of 65 バッジ獲得!!
#codecademy jQuery Functions and Selectors バッジ獲得!!
#scalaをちょっとした文字列処理のスクリプト言語として使用してみた。
#Courseraの講義の前にimplicit parameterの章を予習出来た。
==== 2014/5/27 ====
[雑感]
ウォルター・ルーウィン教授の「NHK MIT白熱教室 第8回 星はどう生まれ どう死ぬのか？」を見た。
宇宙スケールの大きさや重さや距離等を身近なものと比較して説明していた。
イメージしやすくて面白かった。
アウトプットを意識しながら情報収集した方が良い。
アウトプットの機会は少ないから、意図的に増やすようにした方が良い。
何か見たり読んだりしたら、一言でも良いので思ったことをメモする様にするのが重要。
#scalaでhttpの取得が出来た。思ったより簡単だった。
[tips - win7]
タスクバーで右クリック、左クリック後にマウスを動かすとウインド選択が出る。
[MOOC]
http://chronicle.com/article/Major-Players-in-the-MOOC/138817/?cid=wc
coursera, udacity, edx, Khan AcademyがMOOCのmajorらしい。
[scala]
http://blog.kzfmix.com/entry/1255605525
scalaの標準libraryでhttp getをする方法。
http://www.mwsoft.jp/programming/scala/web_scraping.html
http://www.ne.jp/asahi/hishidama/home/tech/scala/xml.html
htmlをparseするのも何とか出来そう?
http://stackoverflow.com/questions/13146019/reading-password-from-console-in-scala
System.console()はcygwinやeclipseではnullになるので注意。
readLine()やSystem.inやio.Source.stdinは使える。
==== 2014/5/28 ====
ロジックツリーはドキュメントの網羅性改善にも役に立ちそう。
#Coursera posa-002 Week 1 peer and self evaluation 完了! 間違えないか心配だったので結構手間取った。
#Coursera progfun-004 Week 5完了! 今週はassignmentが休みだった。
[tips - eclipse]
http://devlights.hatenablog.com/entry/20121114/p2
http://futurismo.biz/archives/1256
http://devlights.hatenablog.com/entry/20121114/p2
http://www.eclipse.org/forums/index.php/t/316243/
eclipseでWinMergeを使う方法
[Programming in Scala, First Edition]
2014/5/28 00 chapter21 0/8
昨日使ったscala.io.Sourceの記載もあった。
復習と校正と分かった事を追記するために一度見直した方が良いが。。。
==== 2014/5/31 ====
#3good サーティーワンでアイスが31%offだった。
#3good つくばイオンのフードコートのパスタが美味しかった。
#3good サンといちご二人だけで近所のスーパーまで歩けた。
[畑の学校]
気温30度超で扱った。落花生の種蒔きと生き物観察
==== 2014/6/1 ====
エキスポセンターでもらったスチロールプレーン作成完了!! 思ったより難しかった。
サンの乳歯が更に２本抜けた!!
いちごの北海道一人旅計画進行!!
==== 2014/6/2 ====
久々にミスドを食べた!!
今日は涼しくて過ごしやすかった。
子供たちが起きている時間に帰れた。
[雑感]
単なる流し読みと、メモを取りながらの読むのでは時間、理解とも結構差がある様に感じる。
==== 2014/6/3 ====
bootcamp downloadプログラムをscalaで作成!! 初scala実用プログラム。
Edx系のDelftx(デルフト工科大学:オランダ)で秋にHaskellのMOOCを予定している。
facebookのlikeボタンを自動的に小さくするchrome extensionを作成!!
gitについて調べた。思ったより分かりやすい?
いちごが町内会でのキッザニアを無事に楽しんできたらしい。
==== 2014/6/5 ====
#Coursera #posa-002 Week 1のResultsは満点で無事に完了! 結構長かった。
#Coursera #posa-002 Week 3 Assignments提出!!
#Coursera #posa-002 Week 2 Evaluation
#bootcampを4か月ぶりに再開!!
javaのthisは殆どの人が必ず付けるようにしている訳ではないらしい。。。
gitとmercurialだとgitのshareが多いみたい。
Egitでmergetoolを使うにはlocalの変更を無い状態にしてからmergeする必要がある？
==== 2014/6/6 ====
久々に朝10時に出社だったので朝皆を見送れた。
#eclipse でformatterの設定方法が分かった!! 細かく設定できる。
[行動経済学]
Dan Arielyの行動経済学の白熱教室を見た。
やっぱり行動経済学は面白い。
人間の「怠惰」を甘く見てはいけない。想像以上に面倒を避ける傾向がある。
目標や目的などの大きな事よりも目の前の小さな環境の変化に行動は左右される。
小さな変化で良い行動へ導ける可能性がある。
gamificationに通じる。
2014年6月5日木曜日
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems (Week 1)
Pattern-Oriented Software Architectures: Programming Mobile Services for Android Handheld Systems(Week 1)
==== Lecture ====
Section 0: Course Introduction
特にコメントなし。
Section 0 Part 1 - Overview of Mobile Cloud Computing with Android
The "Mobile Cloud Computing with Android" Specialization
この講義を含めて３つの連続した講義がSpecializationになっている。
その概要の説明。
motivations for concurrency, inherit and accidental complexities等のキーワードも出てきた。
Section 0 Part 2 - Course Structure and Topics
GoFのパターンも使う。
コースのHomeから必要な情報には辿れるようになっている。
inherit and accidental complexitiesの理解と対処方法の習得が重要。
Section 0 Part 3 - Course Prerequisites and Learning Strategies
受講生の前提とか、コースの活用の仕方など。
Section 0 Part 4 - Overview of Patterns and Frameworks
patternとframeworkの重要性について。Observer patternが例に出ていた。
Section 0 Part 5 - Overview of Patterns and Frameworks
POSAとGoFのpatternについて矢継ぎ早に説明があった。
今後のLectureで出てくるらしい。
Androidはopenなのでpatternの実例として勉強するのに向いている。
https://class.coursera.org/posa-002/wiki/Source_Code_By_Week
にコードへのポインタの記載がある。
https://github.com/android/からplatform_dalvikを指定してbranch/tagから目的のバージョンを取り出せる。
Section 1: Introduction to Android Concurrency
処理順序と共有資源の不整合を防ぐためにsynchronizationとschedulingが必要。
Javaに元々ある仕組みとAndroid frameworkにある仕組み両方を学ぶ。
AndroidのapplicationとframeworkでGoF,POSAのpatternがどの様に使われているか見る。
Androidの表面的な動作だけでなくて内部のmiddlewareについても学ぶ。
Androidのコードの説明が多いので、ダウンロードした方が良いかもしれない。
Section 1 Module 1: Introduction to Concurrency Motivations and Challenges
multi-core化などでConcurrencyを正しく作れる技術者への要求が高まっている。
ハードウエアの能力を十分に引き出すため。
Concurrent softwareの質はハードに追いついていない。
Section 1 Module 1 Part 1: Concurrency Motivations
multi-coreを有効活用するためにthreadを利用する。
threadを使えば性能を上げるだけではなく作りをシンプルに出来る。
single-coreであってもthreadによる疑似並列処理は性能、簡素化に役立つ。
Section 1 Module 1 Part 2: Concurrency Challenges
[accidental complexities]
通常使っているツールやテクニックが制限される事。
low levelの非標準apiの使用によるツールでのチェック力低下。
観測問題によるステップ実行によるデバッグ力の低下。
競合をツールで見つけるのは大変。
改善方法はリンクが示されているのみで説明はなかった。
[inherent complexities]
Concurrent softwareのドメイン固有問題。
synchronization, scheduling, deadlock
こちらも解決策はリンクを示すのみ。
Section 1 Module 2: Introduction to Java Concurrency Mechanisms
Javaのthreadのsynchronization, schedulingの機能を学ぶ。
GoFやPOSAのpatternでどの様に拡張されるかも見る。
Section 1 Module 2 Part 1: Overview of Java Threads 1
[Javaのthreadの作り方]
(1) threadをextendsしてrun()をoverrideしてstart()で起動する。
(2) runnableをimplementsしてrun()をoverrideしてrunnableをthreadに渡してstart()で起動する。
(3) runnableをthreadに渡す時にrun()をinner classで実装してstart()で起動する。
これがAndroidではcommon idiom
[threadのlifecycle]
start()でthread生成、run()が実施される。
run()がreturnするまで動き続けるが、実際はOSによってtime sharingされる。
run()がreturnするのを他のthreadからjoin()で待ち合わせ出来る。
join()を使わない場合は単に終了する。
sleep()と他のthreadからshutdown要求するinterrupt()も重要。
currentThead()で実行中のthread objectが取得出来る。
Section 1 Module 2 Part 2: Overview of Java Threads 2
theadの状態遷移マシン,new, runnable, running, blocked, timed waiting, waiting, terminated
startよりstopの方が難しい。
stop flagを使う方法もある。この場合はblock中はチェックできない。
interruptを使うとblockをbreakする事が出来る。UnixのE_INTRと似たような感じ。
blockしていない時は明示的にチェックすればinterruptが来ているかはわかる。
Dalvikと標準のJVMとは違いがある。
Section 1 Module 2 Part 3: Motivating Java Synchronization & Scheduling Mechanisms
producer-consumerとping-pongの同期をとっていない場合の例。
これを見て同期バージョンをAssignmentで作ると言うこと?
シーケンス図とコード断片が出ていたのでスライドは参考になりそう。
accidental complexitiesによりツール見つけるのも、debugするのも大変。
解決方法は次週なのに、今週のAssignmentで先に解決策の演習をしてしまう?
==== Quiz ====
Quizはhard deadline 6/7のみで普通のdeadlineはなさそう。
100回まで?再提出出来そう。
Quizの順序はLectureの順とあっていて、行ったり来たりが必要なかった。
Quizとほぼ同じ問題がLecture内のQuizでも出てきた。
何時もこの形式なら楽なのだが。
自動採点は提出後すぐに行われた。
一回目の提出で満点！
どのLectureの問題かの解説もあった。
==== Assignment ====
[全般]
Assignmentは期限までは何回?(100回?)でも再提出可能。
このコースの課題はpeer assessmentが必要。progfunより大変そう。
提出期限後にノルマ分(５人)の他の人の評価をすると自分の評価が出来る。
Assignmentはgithubからダウンロードする。eclipseのplug-inを使う.
TODOのコメントは消さない。追加のみを行う。
SynchronizerQueue.javaをcouseraのwebサイトにuploadする。
JRE1.6の環境でテストする必要がある。評価もその環境で行う必要がある。
JRE1.6はセキュリティの問題で公開が終わっているが、JRE1.7でも良いのか？
下記からJRE1.6をダウンロードしてインストール、JRE1.7にupdateするとJRE1.6が消えるとあるが？
http://sourceforge.jp/projects/sfnet_javaautoupgrade/downloads/jre-6u25-windows-i586-s/jre-6u25-windows-i586-s.exe/
preference -> java -> compiler を 1.6にする必要あり。
preference -> java -> Installed JREs も1.6にした方が無難かもしれない。
1.7のままでも動いたが。。。
どうも課題に不備が有った様で提出済の課題を修正するかの議論があった。
結論は不備部分のテストを削除して提出済のもをそのまま使う。
提出期限が5/27で評価期限が6/3
"Virtual Office Hours"でAssignmentの問題と答えにつてい議論する。
staticクラス: classの内部クラスでstatic methodと同じようにクラスに付随する。
indentは基本スペースだが、所々にtabが混じっている。注意必要。
formatterをjava conventionalにして、formatコマンドは使わない様にする。
[Week-1-Assignment-0]
BlockingQueueはjavaの標準のインターフェース, offer()とpoll()を使う。
実装する部分が殆どなかったので思ったより簡単だった。
環境設定の方が大変。
==== Evaluation ====
Virtual Office Hoursで説明あると言っていたけど、大した説明はなかった。
Forumを見ると結構勘違いして提出してしまっている人もいるらしい。
私の担当分は5人とも全部OKだった。
空白や空行や処理の順番が多少違うだけで問題ない。
JUnitもすべてOK。
Self Evaluationも満点で完了!
Peer Evaluationも満点で完了!
==== Etc ====
subtitleの出来はprogfunよりposaの方が上。表示タイミングもgood!
と、最初は思ったけどLectureによってバラつきがある。間違いが多いものもある。
[Eclipse]
Quick Accessにgitと入れてgit cloneで持ってこれた。
Compare withでgitのリポジトリとのdiffが取れる。
Package exploreでファイルを二つ選んでCompare with -> Each Otherでもdiffが取れる。
Eclipseのdiffは賢くない?? 直ぐに全体差分ありなってしまった。
?? 何か改善策はないか?
emacsのediffであれば正しく見える。
==== log ====
2014/05/11 Section 0.0 00:10
2014/05/15 Survey 00:20
2014/05/16 Section 0.1,0.2 00:30
2014/05/17 Assignment準備 00:30
2014/05/17 Quiz & Lecture 0.3-1.3(完) 04:00
2014/05/18 Assignment submit 02:00
2014/05/28 Evaluation 03:40
2014/06/05 Results 00:10
==== Lecture ====
Section 0: Course Introduction
特にコメントなし。
Section 0 Part 1 - Overview of Mobile Cloud Computing with Android
The "Mobile Cloud Computing with Android" Specialization
この講義を含めて３つの連続した講義がSpecializationになっている。
その概要の説明。
motivations for concurrency, inherit and accidental complexities等のキーワードも出てきた。
Section 0 Part 2 - Course Structure and Topics
GoFのパターンも使う。
コースのHomeから必要な情報には辿れるようになっている。
inherit and accidental complexitiesの理解と対処方法の習得が重要。
Section 0 Part 3 - Course Prerequisites and Learning Strategies
受講生の前提とか、コースの活用の仕方など。
Section 0 Part 4 - Overview of Patterns and Frameworks
patternとframeworkの重要性について。Observer patternが例に出ていた。
Section 0 Part 5 - Overview of Patterns and Frameworks
POSAとGoFのpatternについて矢継ぎ早に説明があった。
今後のLectureで出てくるらしい。
Androidはopenなのでpatternの実例として勉強するのに向いている。
https://class.coursera.org/posa-002/wiki/Source_Code_By_Week
にコードへのポインタの記載がある。
https://github.com/android/からplatform_dalvikを指定してbranch/tagから目的のバージョンを取り出せる。
Section 1: Introduction to Android Concurrency
処理順序と共有資源の不整合を防ぐためにsynchronizationとschedulingが必要。
Javaに元々ある仕組みとAndroid frameworkにある仕組み両方を学ぶ。
AndroidのapplicationとframeworkでGoF,POSAのpatternがどの様に使われているか見る。
Androidの表面的な動作だけでなくて内部のmiddlewareについても学ぶ。
Androidのコードの説明が多いので、ダウンロードした方が良いかもしれない。
Section 1 Module 1: Introduction to Concurrency Motivations and Challenges
multi-core化などでConcurrencyを正しく作れる技術者への要求が高まっている。
ハードウエアの能力を十分に引き出すため。
Concurrent softwareの質はハードに追いついていない。
Section 1 Module 1 Part 1: Concurrency Motivations
multi-coreを有効活用するためにthreadを利用する。
threadを使えば性能を上げるだけではなく作りをシンプルに出来る。
single-coreであってもthreadによる疑似並列処理は性能、簡素化に役立つ。
Section 1 Module 1 Part 2: Concurrency Challenges
[accidental complexities]
通常使っているツールやテクニックが制限される事。
low levelの非標準apiの使用によるツールでのチェック力低下。
観測問題によるステップ実行によるデバッグ力の低下。
競合をツールで見つけるのは大変。
改善方法はリンクが示されているのみで説明はなかった。
[inherent complexities]
Concurrent softwareのドメイン固有問題。
synchronization, scheduling, deadlock
こちらも解決策はリンクを示すのみ。
Section 1 Module 2: Introduction to Java Concurrency Mechanisms
Javaのthreadのsynchronization, schedulingの機能を学ぶ。
GoFやPOSAのpatternでどの様に拡張されるかも見る。
Section 1 Module 2 Part 1: Overview of Java Threads 1
[Javaのthreadの作り方]
(1) threadをextendsしてrun()をoverrideしてstart()で起動する。
(2) runnableをimplementsしてrun()をoverrideしてrunnableをthreadに渡してstart()で起動する。
(3) runnableをthreadに渡す時にrun()をinner classで実装してstart()で起動する。
これがAndroidではcommon idiom
[threadのlifecycle]
start()でthread生成、run()が実施される。
run()がreturnするまで動き続けるが、実際はOSによってtime sharingされる。
run()がreturnするのを他のthreadからjoin()で待ち合わせ出来る。
join()を使わない場合は単に終了する。
sleep()と他のthreadからshutdown要求するinterrupt()も重要。
currentThead()で実行中のthread objectが取得出来る。
Section 1 Module 2 Part 2: Overview of Java Threads 2
theadの状態遷移マシン,new, runnable, running, blocked, timed waiting, waiting, terminated
startよりstopの方が難しい。
stop flagを使う方法もある。この場合はblock中はチェックできない。
interruptを使うとblockをbreakする事が出来る。UnixのE_INTRと似たような感じ。
blockしていない時は明示的にチェックすればinterruptが来ているかはわかる。
Dalvikと標準のJVMとは違いがある。
Section 1 Module 2 Part 3: Motivating Java Synchronization & Scheduling Mechanisms
producer-consumerとping-pongの同期をとっていない場合の例。
これを見て同期バージョンをAssignmentで作ると言うこと?
シーケンス図とコード断片が出ていたのでスライドは参考になりそう。
accidental complexitiesによりツール見つけるのも、debugするのも大変。
解決方法は次週なのに、今週のAssignmentで先に解決策の演習をしてしまう?
==== Quiz ====
Quizはhard deadline 6/7のみで普通のdeadlineはなさそう。
100回まで?再提出出来そう。
Quizの順序はLectureの順とあっていて、行ったり来たりが必要なかった。
Quizとほぼ同じ問題がLecture内のQuizでも出てきた。
何時もこの形式なら楽なのだが。
自動採点は提出後すぐに行われた。
一回目の提出で満点！
どのLectureの問題かの解説もあった。
==== Assignment ====
[全般]
Assignmentは期限までは何回?(100回?)でも再提出可能。
このコースの課題はpeer assessmentが必要。progfunより大変そう。
提出期限後にノルマ分(５人)の他の人の評価をすると自分の評価が出来る。
Assignmentはgithubからダウンロードする。eclipseのplug-inを使う.
TODOのコメントは消さない。追加のみを行う。
SynchronizerQueue.javaをcouseraのwebサイトにuploadする。
JRE1.6の環境でテストする必要がある。評価もその環境で行う必要がある。
JRE1.6はセキュリティの問題で公開が終わっているが、JRE1.7でも良いのか？
下記からJRE1.6をダウンロードしてインストール、JRE1.7にupdateするとJRE1.6が消えるとあるが？
http://sourceforge.jp/projects/sfnet_javaautoupgrade/downloads/jre-6u25-windows-i586-s/jre-6u25-windows-i586-s.exe/
preference -> java -> compiler を 1.6にする必要あり。
preference -> java -> Installed JREs も1.6にした方が無難かもしれない。
1.7のままでも動いたが。。。
どうも課題に不備が有った様で提出済の課題を修正するかの議論があった。
結論は不備部分のテストを削除して提出済のもをそのまま使う。
提出期限が5/27で評価期限が6/3
"Virtual Office Hours"でAssignmentの問題と答えにつてい議論する。
staticクラス: classの内部クラスでstatic methodと同じようにクラスに付随する。
indentは基本スペースだが、所々にtabが混じっている。注意必要。
formatterをjava conventionalにして、formatコマンドは使わない様にする。
[Week-1-Assignment-0]
BlockingQueueはjavaの標準のインターフェース, offer()とpoll()を使う。
実装する部分が殆どなかったので思ったより簡単だった。
環境設定の方が大変。
==== Evaluation ====
Virtual Office Hoursで説明あると言っていたけど、大した説明はなかった。
Forumを見ると結構勘違いして提出してしまっている人もいるらしい。
私の担当分は5人とも全部OKだった。
空白や空行や処理の順番が多少違うだけで問題ない。
JUnitもすべてOK。
Self Evaluationも満点で完了!
Peer Evaluationも満点で完了!
==== Etc ====
subtitleの出来はprogfunよりposaの方が上。表示タイミングもgood!
と、最初は思ったけどLectureによってバラつきがある。間違いが多いものもある。
[Eclipse]
Quick Accessにgitと入れてgit cloneで持ってこれた。
Compare withでgitのリポジトリとのdiffが取れる。
Package exploreでファイルを二つ選んでCompare with -> Each Otherでもdiffが取れる。
Eclipseのdiffは賢くない?? 直ぐに全体差分ありなってしまった。
?? 何か改善策はないか?
emacsのediffであれば正しく見える。
==== log ====
2014/05/11 Section 0.0 00:10
2014/05/15 Survey 00:20
2014/05/16 Section 0.1,0.2 00:30
2014/05/17 Assignment準備 00:30
2014/05/17 Quiz & Lecture 0.3-1.3(完) 04:00
2014/05/18 Assignment submit 02:00
2014/05/28 Evaluation 03:40
2014/06/05 Results 00:10
登録:
投稿 (Atom)