jQuery Mobile on JSFIDDLEでレイアウトがレスポンシブにならないんです

portraitになったらui-responsiveが付くと思っていたけど付かない。

しょうがないので自前で何となくそんな感じになるようにした。

ああそうか、Gistと同じでJSFIDDLEで書くと記事検索には引っかからなくなるのか。。

参考

jQueryで現在のウィンドウサイズの取得と判定をして処理を変えるやり方 | bl6.jp

jQueryをざっくり勉強

このへんを知っていれば「jQueryって何ですか」状態にはならずにすむかと。もちろん後追いでちゃんと勉強しなきゃだけど。

$(selector).get(0)って何なのかとずっと思っていたけど、DOMエレメントを取り出していたんですね-。

JavaScriptをざっくり勉強

1個前のエントリであんなこと書いておいて2週間以上放置かっこいいです><

高校生の時でしたか、HTMLを自分で勉強してじゃあ次ってことでJavaScriptの本を買って勉強しましたが、1時間もせずに挫折しました。

時を経て仕事で使うために勉強し直しましたが、今ではさすがに理解できるようです。ただこの文法……最初に学ぶプログラミング言語として選ぶのは薦められないですねー。

ざっくり把握するために

以下でざっくり把握できました。感謝。

これだけ読んでおけば、あとは適宜ググれば適当にこなせるでしょう。いつかちゃんと勉強しないといけない。

ハマったところ

var v = 1;

function f1() {
  alert(v); // 1

  v = 2;
  alert(v); // 2
}

alert(v); // 1
f1();
alert(v); // 2

なんか不思議な感じがするけど、まあふつう。

var v = 1;

function f1() {
  alert(v); // undefined

  var v = 2;
  alert(v); // 2
}

alert(v); // 1
f1();
alert(v); // 1

なんでundefinedなんや。。
同様の例がJavaScript基本概念最速マスターのスコープチェーンの所に」あるが、変数定義はそのスコープの先頭で全部やったことになる様子。

まあ、ふつうこんなコード書くことなんてないけど。ウンコード。

参照

ブログ続いてない

実は会社に提出した年間目標と結びついているブログだったりするが、どう見ても続いていません。

これについて2件のエントリを提示して、次に繋げたいと思います。

  • 勉強のやる気の出し方 | ライフハックちゃんねる弐式

    やらないからやる気でないんであって一回参考書やったら自然とできてくる
    やる気なんて得体の知れないものを待ってたらベトナムに行く前に戦争が終わる 勉強してる内にやる気が湧いてくる
    教科書開くまでが一番辛い
    30秒だげ勉強しよう 30秒だけ勉強しよう って思いながらノート開いて問題一問だけやってみると以外とできる

  • とあるゲーム会社が求めてやまない人材とは

    ただ、僕がずっと誤解してたのは、行動力とか営業力のほうが伸びると思っていましたが、実はセンスのほうが伸びるんですよ。だから、行動力が高い人を採用するようにしたんです。

    そういう積極性のある人達って、自身で思っている以上に、何かをアウトプットすることのハードルが低いんだと思う。
    「自分はまだ拙いから、誰かに見せるなら、ちゃんとしたモノに仕上げないと嫌だ」なんてことを考える前にアウトプットする。

動き出さなきゃ始まらないってのはその通りで、元気があればなんでもできるってのもその通りかな。

問題は行動力の上げ方で、これはきっと自分自身がすごく変わらないといけない。ひとまず、長期的な目標にこれを据えたい。行動力を付ける。

SQL*LoaderでCSVを読み込みたいんです 追記

SQL*LoaderでCSVを読み込みたいんです - なんでや。。
この愚かな記事に愚かな追記を。。

PRESERVE BLANKSで空白保持しても、DECIMAL EXTERNALやDATEのカラム(たぶんZONEDも)は勝手に空白トリムしてからうまくキャストしてロードしてくれる。CHARのカラムは空白保持したまま。

フィールドリストを以下のように書いたとする。

        EMPLOYEE_ID     DECIMAL EXTERNAL(6) ":EMPLOYEE_ID + 1",
        START_DATE      DATE 'FMYYYY/MM/DD',
        END_DATE        CONST '2012/03/04',
        JOB_ID          CHAR(10),
        DEPARTMENT_ID   POSITION(2) DECIMAL EXTERNAL(4)

試していないが、読み込んだCSVに対して以下のように挙動すると思われる。

  1. CSV1~2列目をEMPLOYEE_ID, START_DATEへマッピング。
    EMPLOYEE_IDはCSVの値にプラス1される。演算したい場合はこのようにダブルクオートで括って書く。確かINSERT文に書ける書き方なら何でもOKとかどこかに書いてあった気がする。
  2. END_DATEはCONSTANTなのでCSVからは読み込まない。書いてある通り2012/3/4がマッピングされる。
    またCONSTANTだからか演算結果をマッピングさせることはできない。
  3. CSV3列目をJOB_IDへマッピング。
  4. CSV2文字目(POSITION(2))から次のデリミタの手前までをDEPARTMENT_IDへマッピング。

読み込んだファイルのレコード先頭から末尾に向かってデリミタが来るまで読み込んで順番にフィールドにマッピングするのが原則と思われる。
POSITIONを指定することで無理矢理マッピングすることも可能だが、可変長レコードの場合はPOSITION(1)としか書けないはず。
CONSTANT指定したフィールドについてはファイルを読み進まないでくれるが、それ以外は必ず読み込むので、例えSTART_DATE DATE "SYSDATE"などと書いてあってもCSVはそのフィールドの分読み進まれる。

上記のようなフィールドリストなら、このようなCSVに対して

123,1999/12/31,IT_PROG

このようにINSERTされる(はず)。

123, 1999/12/31, 2012/03/04, IT_PROG, 23

おそらくこのように挙動するため、各カラムにランダムにマッピングしたいと思っても無理。
できるのは演算不可なCONSTANT値を指定することと、

HOGE "SYSDATE",
PIYO "1024 * 1024",
FUGA POSITION(1) DECIMAL EXTERNAL,
FOO CHAR,
BAR CHAR

みたいに途中で1文字目からポジションを指定し直すことくらい。
もうちょっとやり用はあるかも知れないけど、それくらい融通が利かない。

ちなみにCSV中のいらん列をFILLERという仮想カラムに対してマッピングすることで無視することが出来る。

ちょっとまとまりなくて読みにくいかも。。

参考

SQL*Loader制御ファイル・リファレンス

SQL*LoaderでCSVを読み込みたいんです

余計なことを考えずに書く。

LOAD DATA
    -- DATA files , BAD , DISC file
    INFILE       'ldrSample.dat'
    BADFILE      'ldrSample.bad'
    DISCARDFILE  'ldrSample.dis'
    -- APPEND ROWS
    APPEND
        PRESERVE BLANKS
        INTO TABLE JOB_HISTORY
    FIELDS
        TERMINATED BY ','
        OPTIONALLY ENCLOSED BY '"'
    (
        EMPLOYEE_ID     DECIMAL EXTERNAL(6),
        START_DATE      DATE 'FMYYYY/MM/DD',
        END_DATE        DATE 'FMYYYY/MM/DD',
        JOB_ID          CHAR(10),
        DEPARTMENT_ID   DECIMAL EXTERNAL(4)
    )

コントロールファイルはこの調子。ファイルは

100,2001/1/3,2010/11/22,60
100,2001/2/3,2010/11/22,60
100,2001/3/3,2010/11/22,60

一部カラムはCSVに書かずにコントロールファイルに書いてあっても、うまくCSVからあてはめてロードしてくれる。

PRESERVE BLANKSがなかなか認識されなくてはまった。。APPEND・INSERTなどの後ろに書かないといけないのね。

参考

対象レコードを絞ってOUTER JOINしたいんです

先に書くと、絞ってからjoinしたいならonのところで絞っておくこと。特にouter joinは。
inner joinはどっちでもいいけど、可読性考えて同じようにonに書くのがいいでしょうね。


職種一覧と、各職種で最も最近雇用した人を表示するSQLを書こうとします。同時雇用した人がいたらしょうがないってことで。。

職種はjobsにあり、従業員リストと雇用日の情報はemployeesが持っています。
リレーションはこちらを参照してください。。

SELECT
  J.JOB_ID
  ,E.FIRST_NAME || ' ' || E.LAST_NAME AS NAME
  ,HIRE_DATE
FROM
  JOBS J
    LEFT OUTER JOIN (
      SELECT
        EMP.*
        ,MAX(HIRE_DATE) OVER (PARTITION BY JOB_ID) AS LAST_DATE
      FROM
        EMPLOYEES EMP
    ) E
      ON J.JOB_ID = E.JOB_ID
      AND E.HIRE_DATE = E.LAST_DATE
;

こう書いてみました。
「employees各行に対しウィンドウ関数で職種ごとのmax雇用日を追加するをサブクエリ」をouter joinしていて、ONに条件を追加することで外部結合時にレコードを絞れます。

これをwhereで絞ってしまうと、外部結合ですから結合されたカラムがnullになるような行が出てくるわけで、その行が除外されてしまいます。
この例だとたまたま(たまたまじゃないか。。)全職種の人がemployeesにいるので以下のように出力されます。

JOB_ID        NAME                HIRE_DAT
------------- ------------------- --------
AC_ACCOUNT    William Gietz       02-06-07
AC_MGR        Shelley Higgins     02-06-07
AD_ASST       Jennifer Whalen     03-09-17
AD_PRES       Steven King         03-06-17
AD_VP         Neena Kochhar       05-09-21
FI_ACCOUNT    Luis Popp           07-12-07
FI_MGR        Nancy Greenberg     02-08-17
HR_REP        Susan Mavris        02-06-07
IT_PROG       Bruce Ernst         07-05-21
MK_MAN        Michael Hartstein   04-02-17
MK_REP        Pat Fay             05-08-17
PR_REP        Hermann Baer        02-06-07
PU_CLERK      Karen Colmenares    07-08-10
PU_MAN        Den Raphaely        02-12-07
SA_MAN        Eleni Zlotkey       08-01-29
SA_REP        Amit Banda          08-04-21
SA_REP        Sundita Kumar       08-04-21
SH_CLERK       yamada             13-08-03
ST_CLERK      Steven Markle       08-03-08
ST_MAN        Kevin Mourgos       07-11-16

20行が選択されました。

でも現在社内に人がいない職種があったら

JOB_ID        NAME                HIRE_DAT
------------- ------------------- --------
AC_ACCOUNT    William Gietz       02-06-07
AC_MGR
AD_ASST
AD_PRES       Steven King         03-06-17

こんな感じになります。
このようにouter joinされたあとにE.HIRE_DATE = E.LAST_DATEなんてしたらAC_MGR, AD_ASSTの行が選択されなくなってしまう、とこういうわけですね。

inner joinだとマッチしない行はそもそも選択されないので、絞り込み条件をonに書こうがwhereに書こうが同じ。ですよね。。

標準SQLで複雑なJOINを書く時にいつも微妙に困っていたのでちょっとすっきり。

参考

結合する表がたくさんある場合はjoinをどんどん繋げていって、onにはそこまでに登場した表のカラムを使っていいんだよってことですね。

本件ではこの2ページが一番参考になりました。

上記を読む前に「そもそも構文どうなってんだよ。。」と思って調べたのが以下。Syntax Rulesの所は全然読んでません。

結局はこんな感じ:
INNER | {LEFT | RIGHT | FULL}[ OUTER] JOIN table[ PARTITION BY (column[, column...])] {ON search_condition | USING (column[, column...])}
onの所はもうなんでもありって感じ?
で、「え、joinにpartition byなんて書けるの?」って分かって読んだのが以下。

使いどころが来た時にこの機能を思い出せるかどうか自信ないです。。