  |
はてなキーワード: 連想配列とは
経営者としてお答えしよう
ファック死ね
業務時間を割いてなにかやってるのは知っていが注意すると拗ねてモチベ下げるので黙っているが、管理職には絶対に上げないフラグを立ててるからな
持続可能性
頼むよ、これを意識してよ
仮に５秒短縮が当該業務担当５人、１０回／日だとして年間１６時間。。。
ん？わりとデカいな。
頑張れ
違う違うちがう
どうせ空いた時間は給湯室でくっちゃべってるだけだ
知るかボケ
あのな、頑張って勉強して業務効率化に寄与してくれるのはありがたいが、
オマエ死んだらどーすんの、連想配列が保守メンテできるスタッフ他にいる？
ワークシート上のセル式ならなんとか追いかけられますが、VBAでややこしいことやれたらわかりませーん、だよね？
VBAでゴチャゴチャやられるといざ業務拡大近代化の時に余計な工数もかかるの。
ワークシート上で処理完結してて適度にコメントも書いてくれてたらそれがそのまま要求仕様、ドキュメントになるの。
プログラム化されちゃうと要求仕様はそこから紐解かなきゃならない、そんだけ余分な工数がかかる。
残業して連想配列してるのは分かってるが、さっさと帰って婚活でもして、ブサイクな嫁とアホの子供でも作って、あぁもう迂闊に会社辞められねぇ、ってなってくれたほうが会社はありがたいの。
美しくない？
知るかボケ
どこにどれほどリソース割くべきか
こっちもアホでは無い、経営多変数パラメーターを加味して妥協し方向性と優先順位決めてるんだ
頼むから言う事聞いてよ
他人のことは放っておけ
手作業頑張った感が出る中間ファイル生成させるとかやって、空いた時間で勉強するんやぞ
ExcelVBAの後にどうせだから他のVBAもやっとくかと遊んでたら、OutlookVBAで名前空間と出会って衝撃的だった
会社から365移行するとか言われたんでOfficeScript触って連想配列とかいう素晴らしいものと出会った
GraphAPI使って、メールも含めて仕事してるフリが出来るようになってだいぶ満足感出てきた
さぁ次は何しようかなー
この日記の内容は、会社の後輩から「最近エクセルマクロを勉強し始めて（キラキラ）」という話を聞いて、先輩ムーブをかますために話した内容になります。
とにかくこれから説明する「計算用シート」が憎くて憎くてたまらず、ちょっと引かれるほど熱弁してしまいました。
ただ、他の方がどうされているのかや、逆に「計算用シート」を愛用する方の意見も聞きたくなり、増田に書いてみました。
エクセルマクロのお作法とか書きましたが、要するにエクセルマクロで「計算用シート」って色々な意味でよくないよね、という話をしたいです。
３行でまとめます。
〇 エクセルシートはユーザーインターフェース（インプット）か出力結果（アウトプット）のためのものとすべき
〇 データ加工をする場合には、原則配列や辞書型配列（連想配列）に格納して加工を行い、最後の結果だけシートに出力するべき
〇 何事にも例外はある。
エクセルマクロにも色々あると思いますが、今回は下記を想定します。
日付や人物名などを入力し、データベースや別のエクセルファイル、別のシートから取得したデータを入力された値を基に加工し、加工後のデータをシートに出力する
この場合、入力欄があり編集可能なシートがユーザーインターフェース、最終的に加工されたデータが出力されるシートが出力結果です。
（もちろん、ユーザーインターフェースの別の欄（セル）に出力する場合もあるし、その場合はユーザーインターフェースと出力結果が一体のものとみなします。）
また、データ用シートは同じエクセルファイル内に基となるデータが含まれる場合を想定します。
（これ自体が非推奨で、SQLデータベースかせめてAccessを使え、という意見はありますがそれは別にして…）
ではここで定義する計算用シートとはなにかというと、文字通り計算を行うためのシートです。
１．元となるcsvファイルをエクセルに読み出してシートに格納
２．そのデータは日付が数値型になっているので、日付（数値型）の入った列を文字列に変換した日付（文字列型）列を新たに作成
これは極端な例ですが、とにかく変数や配列を定義せず（あるいはエクセルのセルオブジェクトを変数のように扱い）、エクセルに値を入力し、それを直接加工することで目的となるデータ加工をしたり、様々な処理をします。
なんかこんな感じの処理をしているエクセルマクロ、どこの会社でも腐るほどあるんじゃないでしょうか。
ある程度マクロに慣れた気の利く人なら、このシートはロックや非表示にして、ユーザーから触れないようにするでしょう。
・・・これ、やめたほうが良くないですか？。
ある程度詳しい人なら同意してくれると思いますが、このやり方でダメな理由はいっぱいあります。
後で説明する配列や辞書型配列（連想配列）と比べると格段に処理が遅いです。
ちょっと詳しい人が知っている「画面更新の非表示」を駆使しても、配列を使った処理からみれば止まったハエです。
いったんエクセルシートにデータを格納して加工しているので、コードとエクセルシートを両方見る必要があり、とても読みにくいです。
変数として命名されていないのも致命的で、処理の意図が余計に分からなくなります。
計算用シートを事前に用意して、別のセルに関数を格納しておき、マクロと関数を使ってデータ加工をするものも見たことがあります。
あまり知られていませんが、セルの最大文字数は32,767 文字です。
セルの最大文字数を超えると自動的に隣のセルに値が入り、シートが滅茶苦茶になります。
他にもエクセルの数値を丸める自動変換の仕様とか文字列→日付の自動変換とか、いくつものバグに苦しめられます。
できる人だと、いちいち最大文字数が多い場合の処理を書いたり自動変換機能を殺したりしてくれますが、そんなことに手間をかけているから日本のGDPは上がらないんだと思います。
他にも、データが大きくなると処理が重くなり不安定になる、計算用シートを人が触ってしまうリスクがある、などいくらでも理由は上げられます。
（逆に利点は、目の前でガチャガチャ動いてスーパーハッカーになった気分になれるくらいしか思いつかない・・・）
配列を使いましょう。
配列とは何ぞや、という人はググってください。
配列にデータを入れて、データ加工は配列や変数に対して行い、一番最後の出力だけセルに値を格納する。
個人的にオススメしたいのは辞書型配列（連想配列）で、うまく使うとデータの管理が簡単になり、処理も爆速になります。
（参考）【VBA】大量データから高速で値を検索【Dictionaryを使う】
csvファイルもなまじエクセルで開けるだけに別のブックやシートで開きがちですが、これは悪魔のささやきです。
直接ファイルを読み出してLine InputやSplitで配列に格納しましょう。
エクセルとして開くやり方はコード書くのは簡単でも、実行時間に天と地ほどの差が出ます。エクセル開くと処理もめちゃ不安定です。
（参考）Excel VBAでCSVオープンするときのパフォーマンス比較
いや、冒頭のマクロを書く人の気持ちも分かるつもりです。自分もコードを書き始めたころは全部シート上で操作していました。
冒頭のマクロのほうが直感的なんですよね。自分が手で書くことをマクロにやらせる、というマクロ本来の趣旨にはあっていますし。
途中の計算過程もすべて目の前で展開されるから分かりやすいです。
ただ、それではダメなんです。。。処理は遅いし挙動は不安定だし後で改修・保守する人が死にます。
あと、エクセルシートやセルは当然エクセルにしかないので、エクセルマクロ（VBA）から他の言語に移れなくなります。
自分もエクセルマクロの里の出なので、計算用シート脱却には苦労しましたが、苦労して会得した配列や辞書型配列（連想配列）のスキルはそのまま他の言語に活かすことができました。
配列の中身を見る方法は別にある（ローカルウィンドウやDebug.printを使うなど）ので、リハビリに取り組んでほしいです。
（参考）VBA デバッグの仕方
計算用シートを許容できる、使うべきケースもあると思います。。
個人的には、
（最後のは、なんでも自分で確認しないと気が済まない上司の発注で、意味不明と思いましたしたがしぶしぶやりました。）
この場合、インプットのエクセルシートに直接加工するのは論外なので、計算用（加工用）のシートを用意してそこで操作を行うことは必要だと思います。
他にも、こういうときは「計算用シート」があったほうが良い、という状況があれば教えてもらえると嬉しいです。
そもそもツッコミとして、「データ加工するならエクセルマクロを使わずにpythonとかRとかもっとまともな言語使えよ」という言葉が来そうな気がします。
ただ、個人的にはエクセルマクロ（VBA）は大好きですし、初心者にもおすすめしたいです。
自分のような非エンジニアだと、セキュリティの関係などでPythonの開発環境とかすごく用意しにくいんですよね。
（あと、コマンドプロンプトの真っ黒な画面が怖かった）
その点エクセルマクロは、開発環境の用意はプロパティでチェック項目を一つオンにするだけだし、入門書がたくさんあるし、セルの挙動を追えば視覚的にプログラムを理解できるし、初心者に優しいです。
（そのやさしさが上述したとおり悪魔の罠なわけですが。）
最初は計算用シートに頼ってでもエクセルマクロからプログラミングを始めて、本格的なデータ加工をし始めたあたりで計算用シートという諸悪の根源から脱却する。
さらに本格的なデータ処理を行うために、PythonやRなど別の言語を習得したり、エクセルからSQLデータベースやACCESSなどに切り替えていく、というプロセスがいいのではと個人的に思います。
世間一般的に読みにくいコードというと、コメントついてないとか
名前が狂ってるというのは、
JSONParserとか言いながらJSONが関係していないクラスとか、
getUserみたいなメソッド名なのに引数としてuserを渡すとかそういうやつ。
JSONParserクラスの名前を付けた奴は、中のコードからすると、
どうもネストした連想配列のことをJSONだと思っていたらしい。
ネストした連想配列から個別の値を取得するのがJSONParserだった。
文字列を受け取って、ネストした連想配列を返すparserメソッドが
あるクラスであればJSONParserという名前で合っている。
getUserはuserIdフィールドだけ値を設定したUserインスタンスを
書いた奴は、データベースから値を取得するのをgetだと思っていたのだろう。
日曜日が終わってしまうので、ここらで一発、何らかの生産的な行動をやっていきたいぞ、と思ったわけですけども、なぜかこうして増田に張り付いています。
前頭前野の敗北であり、辺縁系の勝利です。勝利、勝利、大勝利。長良は辺縁系ではありません。
なぜか私のPCデスクには知恵の輪が転がっています。なぜでしょう。お見舞いでもらった品です。なぜ知恵の輪。ボケ防止にとのことでしたが。
ところで、先程PCデスクと言いましたが、これは厳密に言うと、いえ別にそんな厳密とかじゃなくて普通に言ってそうなんですが、私が今パソコンを置いている場所は、PCデスクなどという大層な代物ではありません。
というかデスクですらありません。
私は椅子の上にディスプレイとキーボードとマウスを置いています。
正確には、椅子の上に、ホームセンターで買った合板を乗せて、それを机とし、周辺機器を乗っけているのです。
これは案外便利です。広い、安い、手軽、収納しやすい。見た目のアレさにさえ目をつむれば、非常に合理的な選択であると言ってよいでしょう。
あるいは、見た目などという些事に囚われていないことが、余計に合理的な選択であることを強調している、とさえ言ってもよいかもしれません。
ところで、さっきまで、やむを得ない事情により、VBAなる恐ろしい言語を使っていたのですが、これには様々な謎仕様があるようです。それらは名状しがたき恐怖で我々を戦かせます。
一般的に知られていると思われる謎仕様と致しましては、例えば、配列におけるReDimなるステートメントが上げられるでしょう。
他にも、例えばマクロの高速化のための方策として、範囲を配列に代入するというテクニックが紹介されることがありますが、この配列と範囲との間にも謎の関係性が存在しています。
この手のソフトウェアを扱うに当たり、いちいち一つずつセルに値を書き込むことはご法度、というのが定番ではありまして、私も素直にこの定石にしたがい、セル範囲を二次元配列に格納したりしております。
しかし、範囲を配列に代入した場合、その配列の要素のインデックスは、どうも1から始まるようなのです。
なぜ1スタートなのでしょうか。VBAの仕様においても、配列の添字はいちおう0から始まることになっているのですが、範囲を配列に格納した場合、0行0列の要素は空となっており、Array(1,1)にRangeの始点の値が格納されております。
まあたとえ1スタートであっても、言語内で仕様が統一されているのであれば、まだよいのです。
しかしここが彼の言語の恐怖ポイントなのでありまして、どういうことかといいますと、
すなわち、今度は逆に配列を範囲に代入、すなわち配列の各要素の値を対応する範囲のセルに書き込む場合、インデックスが0である要素から順に処理されるのです。
範囲を配列に代入するときはインデックスが1から始まるのに、配列を範囲に代入するときはインデックスが0から始まるのです。
Array = Range
Range = Array
とすると、一番上の行と一番左の列が、空白行、空白列になってしまうのです。
なんですかこれは。誰が考えたんですか。おかしいでしょう。私はおかしさのあまり死にました。
この理不尽さに比べれば、Collectionなる連想配列の添字が1から始まることなど些事に過ぎません。
昨日までJavaJavaしていた人は、どうやら配列なんぞには目もくれていなかった様子でしたので、この謎仕様に気づくこともなかったのでしょうが、悲しいことに、この謎仕様の配列を用いた高速化テクニックはほぼ必須のスキルでありますので、例の御人も、遅かれ早かれ、この罠に絡め取られていたことでしょう。
あるいは、この謎現象を回避するための方策はきちんと用意されており、無知な私はそれを知らないがゆえに、このような的はずれな不満をぶちまけているのかもしれません。
しかし、上述したような単純かつ直感的な代入が上手くいかないという仕様は、やはり、なかなかの欠陥ではないかと思うわけです。
まあそんな愚痴はどうでもいいのです。変な仕様は適当にハックしてやればよいのです。
でもクラスモジュールとやらのパワーは貧弱なのでそれも大変困難ではあります。
標準モジュールでライブラリもどきをちまちまと作っていくしかないのでしょうか。
とてもではありませんが、こんなもんを極める気にはなりませんので、そこら辺のことをいい感じにまとめてくれている知見があればよいのですけれども、しかし、まともな人間はこんなもんを相手にしたりはしない、というパラドックスがあります。
（https://sites.google.com/site/compositiosystemae/home/vbaworld/upper/interface はわりとよかったような気がします。システムハンガリアン使ってますけど）
こんなもんを扱わざるを得ないような環境に留まってしまっている私がおかしいという話もあります。
悪いことは言いません。pythonで書かせてください。お願いします。
そんな増田の切なる願いは、社会という名の抗いがたい泥沼に絡め取られ、今日も悲しみに満ち満ちたコードを生成していくのであります。
そういえば今日は休日でした。休日は普通楽しいものなのではないでしょうか。どうしてこんな悲しい気分になっているのでしょう。
答えは簡単でして、悲しいことを書いているからです。楽しい気分になるには、楽しいことを書く必要があります。
楽しいこととは何でしょうか。例えばオナニーなどが挙げられます。人生において、オナニーよりも楽しいことは、あまりありません。
よって、楽しくなるには、オナニーの話をすればよいです。
私は一時期、DLditeで同人音声を漁っておりまして、催眠に掛かるべく邁進していた時期もありました。
なぜ私は催眠に掛かれないのか。
集中力の欠如、衝動性の強さ、慢心、環境の違いなど、様々な要因が考えられますが、最も大きな原因と思われるのは、台詞がめっちゃ気になることです。
おっさんが考えた可愛い二次元の女の子みたいな台詞が、えらく癇に障るのです。
そのために、可愛らしい女性の声に没頭できないばかりか、声によって現実に引き戻されてしまう、という逆説に襲われるのです。
おっさんは蓮を咲かせる泥だという話もありますが、恐らく、真に良質な泥おっさんというのは、非常に稀な存在なのでしょう。
つまり、いいおっさんは泥ですが、悪いおっさんはゲロということです。
しかし、これもおっさんに限らず、大抵のことに言える話でありまして、良質なものはどこでも少ないものです。
生の増田を見てもそうでしょう。
ホッテントリに上がる増田しか見ないライト増田、あるいはブクマカには想像もできない世界が、生の増田には広がっています。例えばこの増田とかです。
（これは私見ですが、VIPやなんｊ、あるいは虹裏などと比べても、増田の毛色は違います）
増田のほとんどは泥であり、ホッテントリに上がった増田は花なのです。
何だかまた悲しい話になってるじゃないですか。なぜ私はいつも悲しい話をしてしまうのですか。
それは恐らく、心の通奏低音（俗用）のようなものが、悲しみに染まっているからです。
基本的に悲しんでいるので、無意識に任せて話すと、悲しい話ばかりが飛び出てくる、というわけです。
ほげとひげとはげ、ホゲとヒゲとハゲがそれぞれ別のペアとして使われるなら、前者がいいんじゃない？
例えば、こんな感じなら、前者の方が配列の中からその連想配列を見つけてそれだけを見れば済むので楽な気がする。
[{bald: "はげ", language: "japanese"}, {bald: "calvo", language: "italian"}, {bald: "chauve", language: "french"}...]
for文でlanguageが希望のものになるまで配列をたぐってから、baldの値をとってくればいい気がするし。
これが後者の方式だと、for文で回した後にそのインデックスが何かを覚えておいて、baldの配列からそのインデックスで探すことになるから一手間かかるかな。
それに、前者の方法ならもしハゲが無いけどヒゲならある言語がある場合、ヒゲだけ値を入れておけばいいという気がする。
特に配列の要素ごとにまとまりが無いなら後者のデータ構造の方がいいかな。
はてなユーザーには馴染み深いであろう、「SIerへのdisり」で有名なpaizaのスキルチェックをやってみた。
ちなみに、私は現在SIerに勤めており、最近仕事への不満が高まっているので、転職を考えている。
といって別にSIerが憎いわけでもないし、paizaのポジショントークはどうかと思っている。Web系に行きたいわけでもない。
ただ色々な転職サイトに登録してる流れでpaizaも登録したので、せっかくだしプログラミングスキルチェックをやってみた。
スキルチェックするにはプログラミングの問題を解けばいい。問題にはランクがあり、難易度順にS,A,B,C,Dの5段階。問題を解くと100点満点で評価される。
得点は「テストケースに通るか？」と「時間内に解けたか？」で決まり、各ランクの問題で81点以上とれば、自身のpaizaランクが上がる。（paizaランクはS～Eまで）
問題は多数用意されているが、1問でも81点以上取ればランクが上がるので、ランクアップのハードルは低い。しかもランクが落ちることもない。
B 普通。稀にひらめきが必要な問題もあったが、特に迷わず解ける。
A やや難しい。自分の能力不足かも知れないが、少し実装が込み入ってくる。しかし解けないものは無い。
S 難しい。解けない問題もある。愚直に解くと計算量が多すぎたり。アルゴリズムの知識が必要だったり。
Aランク以下の問題はほぼ全て81点以上（というかほとんど100点）だったので、全体的な難易度は低い。
「高ランクだと企業からオファーが来ます！」っていう触れ込みだけど、最近は業務でワードエクセルしか触っていない私でもこんな感じなので、単なる足切り程度の意味しかない気がする。
まじな話をすると、N予備校のプログラミング入門コースやるのがオススメ。
一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。
月額1000円だけどしっかり勉強すれば一ヶ月の無料期間中に終わると思う。
もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラムで講師曰く去年はこれで二人エンジニア就職を決めたらしい。
内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職に必要な環境構築やセキュリティまでみっちりやる。
で講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。
↓みたいなことが学べる
----
Web ブラウザとは (Chrome, デベロッパーコンソール, alert)
はじめてのHTML (VSCode, HTML, Emmet)
さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)
HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)
はじめてのJavaScript (JS, ES6, エラー)
JavaScriptでの計算 (値, 算術演算子, 変数, 代入)
JavaScriptで論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)
JavaScriptのループ (ループ, for)
JavaScriptのコレクション (コレクション, 配列, 添字, undefined)
JavaScriptの関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)
JavaScriptのオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)
はじめてのCSS (CSS, セレクタ, background-color, border)
CSSを使ったプログラミング (transform, id, class)
Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)
診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)
診断機能の組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)
ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)
LinuxというOS (VirtualBox, Vagrant, Ubuntuのインストール, OS, CUIの大切さ)
コンピューターの構成要素 (ノイマン型コンピューター, プロセス, lshw, man, ps, dfの使い方)
ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)
標準出力 (標準入力、標準出力、標準エラー出力、パイプ、grep)
vi (vimtutor)
シェルプログラミング (シバン, echo, read, 変数, if)
通信とネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)
サーバーとクライアント (tmux, nc, telnet)
HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)
GitHubでウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)
イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)
GitとGitHubと連携 (git, ssh, clone, pull)
GitHubへのpush (init, add, status, インデックス, commit, push, tag)
Gitのブランチ (branch, checkout, merge, gh-pages)
Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)
集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)
アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)
ライブラリ (ライブラリ, パッケージマネージャー, npm)
Slackのボット開発 (slack, mention, bot)
HubotとSlackアダプタ (hubot, yo)
モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)
ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)
同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)
例外処理 (try, catch, finally, throw)
HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsのイベントループ, リスナー)
HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)
HTMLのフォーム (フォームの仕組み, form, input)
HerokuでWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)
認証で利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)
Cookie を使った秘密の匿名掲示板 (Cookie, Set-Cookie, expire)
UI、URI、モジュールの設計 (モジュール設計, フォームのメソッド制限, リダイレクト, 302)
フォームによる投稿機能の実装 (モジュール性, textarea, 303)
認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)
データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)
トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)
削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)
管理者機能の実装 (Web サービスの管理責任, 管理者機能の重要性)
デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)
脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)
XSS脆弱性の対策 (XSS, 適切なエスケープ処理, リグレッション)
パスワードの脆弱性の対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)
セッション固定化攻撃脆弱性の対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)
より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)
安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)
Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)
ExpressのAPI (app, Properties, Request, Response, Router)
GitHubを使った外部認証 (Passport, OAuth)
テスティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)
継続的インテグレーション (CircleCI)
クライアントのフレームワーク (Webpack, Chrome 以外のブラウザでもES6)
DOM操作のフレームワーク (jQuery, jQueryアニメーション, this)
AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)
WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)
RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)
テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)
インデックス (インデックス, 複合インデックス, Bツリー)
集計とソート (SUM, COUNT, ORDER BY, GROUP BY)
「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計、モジュール設計、MVC)
認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)
予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)
予定とユーザーの一覧の表示 (非同期処理, Promise, then)
出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)
出欠とコメントの更新 (Promiseチェイン, リファクタリング)
現役ペチパーだけど、元々PHPはHTMLにスクリプトを埋め込むところから始まった変態言語なので、
普通に関数を作って組み合わせてしまえば大半は事足りるのも当然なんだけども。
実務で使うと便利だなと思うのは、まとまりのある複数の変数とメソッドを1つのクラスにカプセル化できること。
例えば、ユーザの情報を管理するときに、「ユーザ情報」というクラスを作って、
その中に publicな変数として、名前、フリガナ、郵便番号、住所、電話番号、会員ID、階級、職業、性別…
を放り込んでおく。
同時に、ユーザ情報の処理に関連する処理の関数を public なメソッドとして、定義する。
ユーザ情報をタブ区切りで得るメソッド getTABDATA()
フォーム入力からユーザ情報にセットする setFromForm()
こうしておけば、
・ユーザ情報を何かの関数に渡す時は、インスタンスの変数1つ渡せば済む。
・ユーザ情報に関する処理は、ユーザ情報クラスの定義部を観れば済む。
という２大メリットが得られる。
メソッドだって１つのファイルに関数並べてインクルードすれば同じメリットが得られるやん？
…と私も思ってた。ただねぇ、開発規模が大きくなると、関数名の重複を避けた命名が面倒になったり、
連想配列だと好きな場所で勝手に変数増やされたりして、メンテナンス性が悪くなるのね。
あとは、例えばメールを送るという１つの大きな処理に関連して複数の関数を定義する場合に、
その関数をまとめてメール送信クラスとしてしまうのはあるかな。
http://web-terminal.blogspot.jp/2014/04/php-file-mail-pear.html
PHPでエクセル出力できるPHPExcelもクラスになっているから使いやすそう。
http://qiita.com/suin/items/7a8d0979b7675d6fd05b
http://cmf.ohtanz.com/blog/archives/2463
結論としては、
