現状エンジニアへ転向する気はないのだが、ポートフォリオ的にも復習的にもまとめてみるのは悪くないかなと思い
主要な用語とかを自分なりにまとめてみる
1年前の知識を元に書くので誤りがありうる点は要注意
言語
Java
最も一般的な言語。
Pythonと比べると変数宣言やら{}やらを厳密に書かなければならない煩雑さがあるが、複雑な機能を実装するには却って明示的で便利なんだろうなあと感じた
Pythonとかでも書けるには書けるらしいが、上記の理由もあってかマイナーらしい
PC, Androidアプリ向け。
Kotlin
Android専用
書いたことはないので詳細不明
Swift
iOS専用
書いたことはないので詳細不明
基本的な機能は同じはず、多分
SQL
データベースを触る言語。
Javaはもう1年触ってないが、SQLは現在の業務でもしばしば用いる
CRMシステムのデータの抽出や分析の業務において
もちろんビジネス総合職なので使うまでもない業務が多いが、明示的に効率的に作業するにあたり知っておくに越したことはない
現在はVlookの代用的に専らJoinを主として使っているが、Webアプリだと4大命令がメインだったかなあ。実装するものにも依るだろうけど
- Select
- Insert
- Update
- Delete
HTML
ブラウザを表示させるやつ
ChromeでもF12で見れる。モダンなサイトはクソ長くてとても読んでいられないが
aタグ<a, href="link.com">link is here<a/>のような具合で、リンクをつけられるのが特徴
ただのHTMLだとあまり面白みもないが、Javaなどからパラメータを渡すことで動的に表示できる。詳細後述
Javascript
HTMLもJavaも応用できるなんかすごいやつ
前者を攻略してからでないと使いこなせない印象
そんな感じでふんわり知識しかない
CSS
HTMLをキレイにするもの
具体的には文字色やフォントを指定する
これがないと、2000年初頭を思わせるようなただの白地に黒字の殺風景なサイトしか作れない
Bootstrap
CSSをさらに伸ばしたやつ
PythonのModuleよろしく、CSSの大まかなキレイにするセットがあるので便利
モダンなデザインが詰まっているとも言えるか
Webアプリケーション
ざっくり言えばブラウザでログインするサイト全般
- SNS
- EC
- その他プラットフォーム
MVC
Model, View, Controllerの3つをまとめて読んだ形式の略称
Model
データをもらったり受け取ったりするのを制御する
バックエンドの肝
View
フロントエンドの肝
HTMLを介してModelで得たデータ等を表示し人間と橋渡しする
HTMLと実際に繋がるのはここ
アカウント名やお気に入り登録されたデータはバックエンドからもらって、それをHTMLの変数の欄に入れ込む
静的なHTMLでは対応できないので、HTML側にも変数の枠を作っておく
<p th:text="${accountname}">
Controller
名前の通り全体を制御する
サイトは入れ子の構造になっているので、そうした階層ごとの移動も補助する
例えば検索ボックスに入力して検索ボタンを押したら、検索結果のページを出すとか
検索結果は検索用語により異なるので、Javaによる動的な実装が不可欠
Javaだと@Controller, @RequestMappingを使っていた
この@の本質は結局最後まで理解しきれなかったが
Entity
ModelやQueryとの棲み分けというか境界の定義が正直難しい
要は変数の枠的な認識
Modelが計算式的なものだとして、Entityがその変数の枠で、その中身はQueryによってDBから取得される的な
Query
SQLの文章
予め要件は決まっているので、それに合わせて文字列変数などを随時使いつつ、定型化されたデータの具体の扱いを行う
GIT
コードを共有するサイト
会社のものを公開して問題になったことも以前にあったなあ
どうしてもWebアプリや他の複雑なプログラミングを1人で全部やるのは難しいので、役割分担して協力するためのツール
Clone
DNAのクローンと同じ
誰かがクラウドに上げたコードを丸パクリでコピペしてくること
そういうことができるので企業秘密を公開してはならない
とはいえそれでは社内では共有できないので、パスワードを使ったり限定公開的な機能を駆使したりする
Branch
それぞれの作業者や機能ごとに分けておくためのレイヤー的概念
AさんがContollerを触るならA Branchで作業して、Bさんは同時期にViewをB Branchで作業して混乱を避ける
Fetch
Branchを統合すること
下記のPull, Pushとセット的な概念
Pull
BranchをDLすること
Push
BranchをULすること
Conflict
Branchがうまく分けられていないことに生じる厄介事
Fetchする段階でされる側とする側で情報の競合、齟齬があることにより生まれる
先の例で言えば、AさんがViewを少し触ってしまうと、B Brachとの矛盾が生じる
そこでどちらかに決めろと言われる
他にわかりやすい例を出すなら、他のクライドファイル共有サービスが挙げられる
例えばパワーポイントをチームで編集するのにDropBoxを使っていたとき、CさんとDさんで同時にローカルで編集すると、後に保存する方は当初の名前では保存できない
これは自動的にConflictを解消させている
GITはそこを任意でどうするか個別に聞いてくれる親切さというか厄介さがある
これが面倒なのでBranchでの作業・責任分界は重要
後記
書いていると意外と忘れていたり、具体的でないと伝えにくいこともあった
空き時間を見て、ローカルで小規模に再度実装してみてもいいかもしれない
その時にははてなのコードを見やすくする機能も活用しまくりたい
またこれの対象読者層的な初心者には以下の動画とかもおすすめ
上述のものといい英語で恐縮だが、日本語の動画は個人的に低質に見えて。。
さすが覇権言語、競争による力学に優れる
基本情報取れるかな？
あと当時は超基本的な設定はお膳立てされていた
それらも一気通貫で自分でやってみれれば、かなり実力には繋げられそうだ
localhostの知識とかも曖昧なままやってたからね。。
参考：過去記事
