いろんなSQL ~副問い合わせ編~

どうも、原田です。

急に寒くなりましたね、、。私はインフルエンザというものにかかったことがないという自慢があります!

 

ナッガーイSQLって本当読む気失せますよね。なんでwhereでまたselectしてんの?とかとか!けどSQLって便利なので、頑張って取得したいっす(´ι_` )

::::::::::::本日のラインナップ::::::::::::::::::::::

一、副問い合わせってナンダ

二、DISTINCT,  EXIST,   IN….

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

 

一、副問い合わせってナンダ

さっきも言ったんですが、selectの条件でwhereを使いますが、そのwhereの中にまたselectしてる(selectをネストしてる)!なにこれ〜!?

→これが「副問い合わせ」です。

わかりやすく書こうとすると二文とかにして、文を分けれるのですが、つなげっちゃったのが「副問い合わせ」とやらです。

《シチュエーション》’原田泰三’と年齢が上の人の名前を知りたい時

「副問い合わせ」使った時(一文)

イコール

「副問い合わせ」使わない時(二文に分けた時)

SELECT age FROM member_all WHERE name=’原田泰三’;

//age=20を取得

をクエリした後、そこで得たageの値(age=20)をもとに、、、

SELECT  name FROM member_all WHERE age>20;

 

()内のselectが副問い合わせ、外側のselectが主問い合わせと呼ぶらしいです。

 

では、もっといろんな大文字を使って、どんな感じで使ってるのか?

 

 

二、DISTINCT,  EXIST,   IN….

□DISTINCT

取り出したレコード(結果)から重複する行の削除を行う

EXIST  

副問合せによって返されたレコードが一つでもあれば真でそのレコードを返す,なければ偽でそのレコードを返さなさい。

□IN    

  副問合せによって返された値のいずれかと等しいかを評価する

例文;

CSSを書くときに考えていること

こんばんは、有村です。
かき氷が大好きで家でもよく食べます。でも最近買ったイチゴ味の蜜がやたら甘くてがっかりです。甘いものは苦手です。

このブログは技術仕様について語るような高尚なものではない(はず)ので、最近CSSを書くときに考えていることをメモ代わりに好き勝手書きます。
そんなんチラシの裏に書いとけってなるけど、チラシはすぐ無くすもん。私の机は汚いのだ。

汎用クラスはやっぱり便利だよね
floatするだけ、marginとるだけ、コーディングする上でそういう場面多いです。

.hoge {
margin: 0 0 10px;
}
.fuga {
margin: 0 0 10px;
}
.hogefuga {
margin: 0 0 10px;
}

みたいな。いくつ量産する気やねんという。
であれば、

.mb10 {
margin-bottom: 10px!important;
}

っていう使い回しがきく定義を1個作っておけばいいんじゃないですかね。
定義した汎用クラス同士を組み合わせて、

div class="mb10 floatL"

みたいにもできるし。
今も悩んでいるのは、importantの有無について。
汎用クラスは拡張クラスとしての意味合いもあるのかなと思っています。たとえば、margin-bottomを30pxとしているクラスがあるけれど、ここで使うときは10pxにしたいんだよね〜みたいな。
となると、既に定義するものを拡張(上書き)する必要が出てくるので、それを確実に成功させるにはimportantがあったほうがいいよね、という。
しかしこれをやってしまうと、いわゆるimportant祭りの音頭が鳴り響き、CSS全体がワッショイ状態になってしまうのではとも思っています。
私は、importantつけたいですが。

抽象的に考える
使い回しを考えるなら、クラス定義するときに「今から定義しようとしているものは何者なのか」を抽象的に考えたほうがよさそうです。
たとえば、赤くて大きくて「SUBMIT」というテキストのデザインのボタンがあったとして…。安直に考えるならこれは「.btn_submit」ですが、もし同じデザインで「SAVE」というテキストのボタンが出てきたら?
使い回そうと思ったら、.btn_submitという名前がついていた…。これはSAVEボタンだから、submitと書かれた定義を使うのは抵抗がある…。じゃあ.btn_saveって名前で新しい定義作ろう…。となるのではないでしょうか。
このように、具体的かつ依存が高い状態でクラスを定義していくと、行数があれよあれよと増えていきます。
ので、抽象的に考えるのであれば、これは「SUBMITボタン」ではなく「赤くて大きいボタン」ですよね。さらに言えば「大きいボタン」もしくは「赤いボタン」であり、行きつくところは「ボタン」なのだと思います。
「ボタン」という基礎に対して、「大きい」とか「赤い」とかの肉付けをしていくイメージでしょうか。
ただ、あまりに抽象化してしまうと、肉付けをするためにhtmlでたくさんのクラスを指定しなければならず、今度はhtml側が肥大化してしまいます。
なので、「ある程度使い回せるまとまり」をどこに定めるか、そこで設計センスを問われるのかな…と思っています。

まだ残したいメモはあるけど、長くなったので明日以降に回します。
それでは、今日はこのへんで。

INSERTとUPDATE

この二つの使い分けが曖昧だっだので、簡単に調べた件!by原田

私は「違い」を知るのが好きみたい。

今更言いますが、原田はパソコン系・IT系クソド素人です。

ぜひ間違って入れば、ツッコミお願いします。

 

端的に言うと、、

指定テーブルに既に存在する項目だが、値が入っていないものを新たに追加したい時はINSERT 。基本全く同じ情報があっても、上書きされない!

指定テーブルに既に存在する項目で、値が既に入っているものを更新したい時はUPDATE。条件に引っかかるものは全て上書きされちゃう!

INSERTって新たに項目も追加できるもんやとおもってた!!!

UPDATEって下手になにも考えず実行しちゃうとめちゃくちゃ危ない!!

 

 

例 INSERT INTO station (‘name’) VALUES(‘tokyo ‘);

◯INSERT文
INSERT INTO テーブル名 [(列名,列名…)]
VALUES    (値,値…)

 

例 UPDATE station SET name=’tokyo’ WHERE id=’1′;

◯UPDATE文
UPDATE テーブル名
SET
列名 = 値
WHERE
条件

 

 

エイリアスだから大丈夫

こんばんは。有村です。
今まで一体型のオシャレサイクロン掃除機を使ってたんですが、最近いわゆるフツーの紙パック掃除機に買い替えました。ノズルやヘッドを用途に応じて取り替えられるので、とても便利です。なんか、引数で振る舞いを変えてるみたいですね。
あまりに感動して、掃除機片手に「これや!これがオブジェクト指向ってことなんや!一体型は拡張性がなくて不便や!」と騒いでいたら若干引かれました。エンジニアだったらこの感動が伝わるはずなのに。

昨日はシェルについて調べましたが、今日はエイリアスについておべんきょーしてみます。

始まりは、先輩とのこんな会話。

先輩「シェルコマンド使ってログを追うやでー^^」
わし「(おっ、tail -f やな!最近覚えたで!)」
先輩「tailf hoge.log ポチー」
わし「!?!?先輩、tail -f ですよ。間違ってますぜ」
先輩「大丈夫、tail -f のエイリアスだから^^」
わし「^^^^^^」

すみません、何が大丈夫なんですかね????

ということで、エイリアスとは…?
調べました。

シェルにおける長いコマンドやコマンド + オプションを、別名の新しいコマンドとして定義したものなのですね。
要は変数定義のようなものでしょうか?
例えば先ほどの例だと、私は9割がたtailコマンドはオプションの-fを一緒に使いますが、ている すぺーす はいふん えふ と毎回打つのは地味に面倒ですよね。(エンジニアはなぜか異常に面倒くさがりが多い!ふしぎ!)
それであれば、「tailf」を「tail -f」のエイリアスとして登録しておけば、2回(スペースとハイフン分)もタイピングの手間が省けるじゃないか!という理屈ですね。

上の例はちょっとありがたみが薄く思えたりもしますが、もっと長いコマンドは沢山ありそうなので、長ければ長いほど効果を感じられる気がします。

登録の仕方によっては引数も使えるそうなので、毎回毎回同じようなコマンド打つのが億劫になったら使ってみます。今はまだシェル自体を全然使えてないので…。

先輩、「エイリアスだから大丈夫」の意味、今なら分かります。

それでは、今日はこのへんで。

シェルについて調べてみた

こんばんは。有村です。
引越しのときに仕舞ったきり、ギターを一度もケースから出してないことを思い出しました。セミアコなんですけど、ずっとほっとくとカビたりするんですかね?こわい。

今日は、ずっと曖昧だったシェルという存在について調べてみました。
私とシェルとの出会いは、いま思い起こせば高校生のときでした。何をしたかったのかはもはや覚えていませんが、ターミナルでsudoとかliとか打ってましたね。
ただ、それがシェルコマンドって言うってことは、10年近く謎のままでしたが…。

この仕事をはじめて、人生初の.sh拡張子に出会うことになったのですが、まずこれをシェルスクリプトと呼ぶことを知りました。
認識としては、「ターミナル上で動くスクリプト」。ファイル内の文字を書き換えてくれたり、ローカルサーバをいい感じに整えてくれたり、手動でやるには面倒な作業を機械的にやってくれるニクい奴です。

で、私はこのシェルスクリプトと、いわゆるliとかmkdirとかのコマンドって全然別物で別次元の話だと思っていたのですが…
こいつらがシェルコマンドということ。さらに根っこが同じだということを知って衝撃を受けました。

根っこ = シェルとは一体何者なんでしょうか。
調べてみて、まさに「殻」だということが分かりました。

何を覆っている殻なのか?その守っている中身は、PCの魂である「OS」なのだそうな。
たとえば、ファイルの一覧を見たければ「ファイルの一覧を出力する機能」を呼び出しますが、そのような機能を持っているのは誰なのかというと、OSの中核が該当します。(こいつがカーネルというらしい)
しかし、カーネル先生を直接いじくってしまうと、致命的エラーが発生してしまうかも知れない。カーネル先生が瀕死ということは、OSもろとも南無…という事態になってしまいます。
そのため、OSを覆うように「シェル」という外殻を設けて、そこを仲介役としてOSの機能を呼び出しているのです。

なので、まとめると。

シェルはOSとユーザとの仲介役。

シェルコマンドは、シェルにお伺いを立てて、OSの機能を使うためのコマンドを指す。

シェルスクリプトは、例えば「ファイルを検索して、さらにその中の文字列を精査し、◯◯という文字が含まれていたら××に書き換える」など一連の作業の流れをシェル(ひいてはOS)に命令するためのスクリプトファイル。

みたいな感じでしょうか?
この辺も駆使できるようになれば、作業効率も上がる気がしますね!

それでは、今日はこのへんで。

MDNを訳す:4日目

こんばんは。有村です。
金曜はMDN日記が無事最終回を迎えるはずでしたが、見事に夏バテてました。夏はいちばん苦手。

ということで、ちょっと日があいてしまいましたが、最終回。
本日も訳すページはこちら。

最後のワードはマルチパラダイムですね。
マルチはわかるけど、パラダイムはわかりません。わたし日本人。
というわけで、調べてみました。

Wikipediaさんは、こう言っています…。
複数のプログラミングパラダイムに対応するプログラミング言語の総称である。

複数のプログラミングパラダイム…なるほど!そのまんまだね。

では、パラダイムとは一体なんでしょうか?
パラダイム自体の意味は、「物事の見方や考え方の枠組み」を指すようですね。
それを踏まえて、プログラミングパラダイムとはなんぞや…というと、プログラミングの見方と表現するのが良さそうです。
これをWikipedia先生の解説に当てはめると、マルチパラダイムとは「複数のプログラムの見方に対応するプログラミング言語」となりますね。

なんとなくですが、思い当たる節はあります。
超雑な例えですが、例えば緊急対応や場当たり対応で「使い回しと汎用性とか必要ねェ!」状態になったときは

のように依存ベッタリのベタベタ実装をします。
逆に、ちゃんと設計や使い回しを考慮して組む場合は、引数で要素や色を手軽に変更できるようなプラグインを作って、変化にも柔軟に対応できるようにします。

みたいな。
実際はこんなわけわからんプラグイン作らないと思いますが、例えね!例え!!

で、有村的な訳し方だと、マルチパラダイムって↑みたいな雰囲気の意味合いなのかなと思いました。
その場の状況や方向性に応じて、プログラミングの見方を変える = どのように書くかを選ぶことができる、みたいな感じ。
なので、1つのプロジェクトでベタで書く人だったりオブジェクト指向で書く人だったりが混じっていても、問題なく実装ができるのですね。(あまりに入り混じりすぎると読みにくくなりそうですが…)

…これにてMDNを訳す第1回、終了です!
用語を知っておくということは、プログラミングする上でもそうですし、技術者同士の意思疎通においても重要なのだと実感しました。
同じ言葉を話せたら、ツーカーで理解し合えたりしますもんね。

またネタを見つけたら、◯◯を訳すシリーズをやってみようかな。その前に私、夏の暑さで溶けてそうですが。

それでは、今日はこのへんで。

->メソッド()と::メソッド()の違いってなんだ?《PHP編》

どうも原田です。

今週末2日間のフェスに行くため、日焼けしてきますの原田です。

来年の目標はFUJIROCKに行くことです!

 

本題ですが、この前コードを書いてて、ふとというか、

毎回わかなんないけど、曖昧なままにしていたこと(タイトル通り)について調べました。

 

調べていくと、すっごいわかりました!一瞬。以上

この報告と共に終わりたいところですが、忘れないうちに書いておこう。

 

>>$this->メソッド()とself::メソッド()の違い

■self::
自クラスのプロパティ、及びメソッドへの静的(static)アクセスを行う。
クラス外からの呼び出しでも、呼び出し先がpublicならアクセスできる!(その時はクラス名::)
■$this
自分自身のオブジェクトを指す。疑似変数

 

>>そこで新たな疑問が・・・静的(static)メソッドとは?

・クラスの中のプロパティもしくはメソッドを static として宣言することで、クラスのインスタンス化($obj = new class();)せずにアクセスできる!
<?php
class Example
{
    public $param1 'NOT staticなプロパティ';
    public static $param2 'staticなプロパティ';
    public static function test()
    {
        returnself::$param2;
    }
    public  static  function test_error() {
        return $this->param2;
    }
}
//クラス名Exampleのインスタンス化
$obj=new Example();
//$param1はstaticなプロパティではないため、インスタンスしたクラスを’->’でアクセス可能
$res1=$obj->param1;
//$param2はstaticなプロパティのため、インスタンス化せずに簡単に’::’でアクセス可能
$res2=Example::$param2;
$res3=Example::test();
逆に、
・static なプロパティは、インスタンス化されたクラスオブジェクトから アクセスすることはできない(static なメソッドにはアクセスできます)。
・static プロパティは、矢印演算子 -> によりオブジェクトからアクセス することはできない。
//クラス名Exampleのインスタンス化
$obj=new Example();
//$param2はstaticなプロパティのため、インスタンス化されたクラスオブジェクトから ‘->’でのアクセス不可
$res1=$obj->param2;
//$param1はstaticなプロパティではないため、クラスのインスタンス化無しに’::’ではアクセスできない。
$res2=Example::$param1;
//例外
//test()はstaticなメソッドのため、インスタンス化されたクラスオブジェクトからのアクセス可能
$res3=$obj->test();

・疑似変数 $this は、 static として宣言されたメソッドの内部から利用することはできない。

class Example
{
    public $param1 'NOT staticなプロパティ';
    public static $param2 'staticなプロパティ';

   public  static  function  test_error()

    {

        return $this->param2;

    }
}
ほうほう!!!!!
PHPを触り始めて早約3ヶ月、6月では意味不明だったことも飲み込める気がしてきた、そんな夏。

 

 

 

 

MDNを訳す:3日目

こんばんは。有村です。
蝉の屍を見かけるようになりましたね。虫嫌いな私はこの季節は生き地獄です。

さて、昨日おとといに引き続き、「MDNを訳す」の続きやっていきます。
テーマになっているページはこちら。

もはや文章として訳すのは無理だわ、という方向転換があったので、今日もそれぞれの用語を調べていこうと思います。

*****
JavaScript は プロトタイプベースで、動的型付けを持ち、そしてオブジェクト指向、命令形、そして関数プログラミングといったスタイルをサポートするマルチパラダイムのスクリプト言語です。
*****

プロトタイプベースと動的型付けは昨日やったので、オブジェクト指向から。

*****
【オブジェクト指向】

よく聞くけど、その実なにも分かっていない用語NO.1(有村調べ)。
以前の師匠には、「人間」というシステムを作るとき、「人間」の動きを1つのfunctionに丸ごと収めるのではなく、「走る」「泣く」「食べる」などそれぞれの役割ごとのfunctionを作り、それらを組み合わせて「人間」を作っていくのだと教えてもらいました。
改めて調べてみたら、超超基本的な考え方としては合っているような…。

が、ちゃんとやろうとすると「継承」「ポリモーフィズム」「カプセル化」という三原則を理解しないと詰むそうな。
特に大事なのはカプセル化だということが各所に書かれています。個人的にはポリモーフィズムもキモのような気が。

外の世界に振り回されることなく、誰かとの依存関係はない。かといって頑固者ではなく、呼び出し元のオーダー(引数とか?)によって振る舞いを変えられるようにする。
そんなカッコイイ女像みたいなのがオブジェクト指向の姿なんですかね…と理解している。今のところ。
*****

*****
【命令型と関数プログラミング】

私は比較をしないと物事を理解できない人間なので、命令型と対を成す「関数プログラミング」を比べて書いてみます!

<命令型>
「どういった手順で、どう処理をするのか」など、手順や内容を命令するように記述する。
JSでのイメージとしては、functionの中に「$(“.hoge)を探してきて、テキストの値は
“fuga”にし、さらにその色をblueにする」のように、動きを流れに沿ってベタで書いていく感じなんでしょうか?

<関数プログラミング(関数型)>
「どの手順で」「どのように」という具体的な方法は外から決めることなく、ただ「何をしたいか」「どの値を使うか」を指定すれば結果が返ってくるみたいなイメージなんでしょうか…。
分かりやすかった例えは、SQL。
確かにあれって、SELECTはこれ、FROMはこれ、って対象だけをオーダーするけれど、「こうやって探せよ!」とかの指定はしていない。
さらに、「同じ値を入れたら、必ず同じ結果が返る」のも特徴みたいです。そんなの当たり前〜と思ったのですが、例えば計算に用いる変数が外の影響でコロコロ値が変わるようなものだったとしたら、「絶対に同じ結果になる」という保証はできないのですね。
そのため、関数型は変数や関数の上書き、再代入ができないようになっているそうです。
オブジェクト指向と似てるな〜と思っていましたが、そこが大きな違いな気がしています。
*****

んー、ここまで見てみると、「JSって色んな書き方ができるんやで!すごいやろ!」という結論になるのかなと予想。
マルチパラダイムを残して今日は力尽きましたが、マルチって言ってるし上述したような内容だったりして。
パラダイムの意味はわからないけど!明日調べよう明日!!

それでは、今日はこのへんで。

MDNを訳す:2日目

こんばんは。有村です。
誰も見てないんだろうなと思っても挨拶は大事。

さて今日も昨日の続きで、MDNの内容を有村でも理解できる言葉で勝手に訳していこうと思います。
対象のURLはこちら。
早速行きます!

*****
Webページでよく使用されるスクリプト言語として知られ、node.js や Apache CouchDB といった多くの非ブラウザ環境においても使用されています。
*****

これは、やさしいにほんごなので特に訳は必要ないですね。
特筆すべきは非ブラウザ環境においても使用されています。の部分ではないでしょうか。
私はSCSSを書くことがあるので、gulp.jsのお世話になっています。JSでタスクランナーが書けるなんて、昔は思いもしなかった。

では続き。

*****
JavaScript は プロトタイプベースで、動的型付けを持ち、そしてオブジェクト指向、命令形、そして関数プログラミングといったスタイルをサポートするマルチパラダイムのスクリプト言語です。
*****

ほら出た!意味不明な言葉のオンパレードだよ!
…うーん、これはそれぞれの用語自体を有村語に訳したほうがよさそうですね。文章にできない。

*****
【プロトタイプベース】

プロトタイプって言っても、ガンダムじゃないよ。
まずはプロトタイプベースと対を成す、クラスタイプベースについて触れておくほうが良いと思いました。

クラスタイプベースは、クラスとインスタンスという2つの要素が必要です。クラスという抽象的な設計図から、インスタンスという具体的な実体を生み出す方式ですね。
ロボットというクラスがあってはじめて、ドラえもんというインスタンスを実体化できるという感覚でしょうか。

対してプロトタイプであるJavaScriptは、設計図がなくてもいきなり「ドラえもん」という実体を作ることができます。
なんだかプロトタイプベースのほうが自由にコードを書ける印象です。
*****

*****
【動的型付け】

これも、動的型付けの対の存在、静的型付けとの比較が分かりやすいと思いました。

例:変数hogeを用意し、数字の10を代入する。
動的型付け … var hoge = 10;
静的型付け … int hoge = 10;

このように、静的型付けでは「hogeに入る値は数値である」ことを宣言するintを使います。
このhogeに対して文字列など数値以外の値を代入するとエラーになります。

動的型付けでは型宣言は必要なく、実行時にそれが何の型なのかを判断します。
console.log(hoge + 10);
だったら、「お、計算するからhogeは数値型の10やな!」みたいな。要は空気を読める子。

ただ、型宣言が必要ない分、エラーの予防や結果の想定が苦手という側面があるそうです。
console.log(hoge + “10”);
の結果は「20」になるのか「1010」になるのか、実行してみないと分からない…といった感じですね。
*****

超長くなったけどまだ半分も終わってない…。
飽きなければ明日も続きを書きます。

それでは、今日はこのへんで。

MDNを訳す

こんばんは。有村です。
今日はねむくない。

さて今日は、「MDNを訳す」をテーマにしたいと思います。
MDNは…WEBに携わる人間にとっては神コンテンツらしいのですが、正直私は最近初めて認知したくそやろうです。
よって、その中をちゃんと見始めたのも、ここ数ヶ月のことなんですよね。

で、私のようななんちゃってエンジニアがMDNを見てまず思うことは、日本語でおkではないでしょうか。書いてあるのは日本語だけどね。
しかし、「ふええ、書いてあることが分からないよぉ〜;;」という逃げもいい加減通用しないので、少しずつでも私の言葉で翻訳していこうと思います。

まずはこちら。JavaScriptについての記事です。
冒頭から見ていきます。
https://developer.mozilla.org/ja/docs/Web/JavaScript

*****
JavaScript (JS) は軽量で、インタプリタ型の、第一級関数を備えたプログラミング言語です。
*****

これを「あー、はいはい」と理解できる方は、どうか回れ右してそのまま私の師匠になってください!
なにこれイミフな方、もうしばらくお付き合いください。
では有村訳。

*****
JSは軽量で、ソースコードを書くだけでブラウザ上で実行できる、プログラミング言語です。このような言語をインタプリタ言語と呼びます。
逆にソースコードだけでは動作しない言語もあります。それらは実行するためのコンパイル作業が必要になるため、コンパイラ言語と呼ばれます。

インタプリタ言語は、ソースを書いたそばから即実行できる便利さがありますが、処理が複雑化すると実行速度が落ちる傾向にあります。
コンパイラ言語は、動作確認の際には都度コンパイルが発生する手間や、ビルドに時間がかかる場合がありますが、その分実行速度が速いという利点があります。また、単独で実行できる点もメリットです。(例えばインタプリタ言語であるJSの場合は、ブラウザが無ければ実行できません)

また、JSの関数は、代入・演算・生成などに制限がありません。
そのため、関数を変数に代入する・戻り値に関数を設定する・引数に関数を入れるなど、関数を自在に使うことができるのです。
*****

こんな感じですかね〜?
なんとなく理解できてきた気がします。つまりJSって使い勝手のいいやつなんだなって…。(感想が雑)

明日以降も、続きを訳していこうと思います。
ゆっくりですが、私が途中で飽きないように見守ってください。

それでは、今日はこのへんで。