Adventar 始めます。
はじめまして。Hinataです。
明日から12月ですね。
エンジニア×12月といえば、Advend Calendar ということで、
Adventar始めてみました。
「脳波を紐解く」
拙いながら毎日更新していこうと思います。
脳波について詳しくは知らないが興味がある人に対して有益な記事にしようと思っています。
よろしくお願いします。
【まとめ】「Webを支える技術 HTTP,URI,HTML,そしてREST」を読んだ
こんにちは、Hinataです。
「Webを支える技術 HTTP,URI,HTML,そしてREST」を読みました。
読んだ内容をまとめたいと思います。
定性すべき箇所あれば、ご指摘いただけると本人のためにもなりますので、
よろしくお願いしますm(_ _)m
この本を読んだ目的
Webフレームワーク、WebAPIの中の仕組みを理解するため
フレームワークやAPIは複雑な手順が隠蔽されており、自動化されているから、その中を理解したかった
Web概論
Webとは何か
WebはHTTPとURIとHTMLで構成されている。
Webはハイパーメディアシステムと分散システムという２つの側面を持っている。
Webの用途
Webサイト
UI（ユーザインターフェース）デバイスの設定画面
WebAPI
リクエスト(キーワード絞り込み等)を送ると、情報がXMLやJSON、RSS形式等で出力されて帰ってくる。(XML、JSON形式を採用しているAPIが多い。)
そのあとXMLやJSON形式のデータをいじって人が見やすいHTMLに整える。
その時PHPとかJavascript等のプログラミング言語を用いる。
PHPとかで自動リクエスト⇒自動で取得⇒自動でHTML表示するように仕組みを作る。
REST-Webのアーキテクチャスタイル
RESTはシンプルでできるだけクライアントとサーバ間で通信を少なくした仕組み。
RESTは以下の特徴を備えたアーキテクチャスタイル。
クライアント/サーバ…ユーザインターフェースと処理を分離する
ステートレスサーバ…サーバ側でアプリケーション状態を持たない
キャッシュ…クライアントとサーバの通信回数と量を減らす
階層化システム…システムを階層に分離する
コードオンデマンド…プログラムをクライアントにダウンロードして実行する
キーワード整理：
アーキテクチャスタイル…REST
アーキテクチャ…サーバ、ブラウザ、プロキシ
実装…firefox,Apache,InternetExplorer
リソース…情報（東京の天気予報等）
URI…リソースの名前
URIを用いることで、プログラムはリソースが持つ情報にアクセスできるようになる
ステートレスサーバ…クライアント側のアプリケーション状態をサーバで管理しない
HTTPをステートフルにする代表格はCookie
キャッシュ…リソースの鮮度に基づいて、一度獲得したリソースをクライアント側で使いまわす方式のこと。
サーバとクライアントの間の通信料を減らす役割がある。
コードオンデマンド…プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイルのこと。JavascriptやFlash
オーバーヘッド…追加的に発生する処理（負荷）
URI
Webにあるリソースは、全てURIで示すことができ、かつHTTPで操作できる。
HTTP
HTTPの基本
HTTPはTCP/IPをベースとした、Webの基盤となるプロトコル
インターネットのプロトコルは階層性になっている。
アプリケーション層:HTTP,NTP,SSH,SMTP,DNS
トランスポート層:UDP,TCP（データの抜け漏れをチェックし、データの到達を保証する）
インターネット層:IP（ネットワークでデータを実際にやり取りする。データを送るのみ）
ネットワークインターフェース層:物理的なケーブルとネットワークアダプタ
TCPで接続したコネクションで転送するデータが、どのアプリケーションに渡るかを決定するのがポート番号。
TCPでプログラムを作るときは、ソケットというライブラリを使うのが一般的。ソケットはネットワークでのデータのやり取りを抽象化したAPIで、接続、送信、受信、切断などの基本的な機能を備えています。HTTPサーバやブラウザはソケットを用いて実装する。
今はどの言語でもHTTPを実装したライブラリがついているから、ソケットを用いてHTTPを実装することはないが。。。
HTTPはステートレスなプロトコルとして設計されている
ステートレスとは、サーバがクライアントのアプリケーション状態を保存しない制約のこと。
ステートレスなアーキテクチャでは、クライアントは、リクエストの処理に必要な情報がすべて含まれているメッセージ「自己記述的メッセージ」を送信する。
ステートレスの利点
・クライアントが自らのアプリケーション状態を覚えているので、サーバの処理が少ない
ステートレスの欠点
・パフォーマンスの低下
・通信エラーへの対処
（ステートレスなアーキテクチャでは、ネットワークトラブルが起きたときにそのリクエストが処理されたかどうかがわからない。）
ハイパーメディアフォーマット
WebAPIを開発するときには、Webサービスの特性に合わせてベースとなるプロトコルやデータフォーマットを選ぼう。
HTML
HTMLは、タグで文書の構造を表現するコンピュータ言語である、マークアップ言語の一つ。ただ、人がブラウザで読むために利用しているため、プログラムでの処理が難しいというデメリットがある。
Atom
汎用XMLフォーマット
JSON
データ構造の記述が得意。Ajax（ウェブブラウザ内で非同期通信を行いながらインターフェイスの構築を行うプログラミング手法）では必須の技術
上３つよりもより軽量なデータ表現形式
記法はJavascriptですが、多くの言語でライブラリがあるために言語間でデータを受け渡すことが可能
Webサービスの設計
リソース設計において重要なこと
WebサービスとWebAPIを分けて考えないこと
リソース設計に必要なスキル
・URI設計方法
・最適な表現選択
・リンクの設計
読み取り専用のWEBサービスの設計
例：郵便番号検索サービス
リソース指向アーキテクチャのアプローチをもとに設計してみる
1.Webサービスで提供するデータを特定する
2.データをリソースに分ける
※実はここが一番重要
最適なリソース分割にすること。
リソース分割については下記
3.リソースにURIで名前をつける
4.クライアントに提供するリソースの表現を設計する
Webの代表的な表現方式
リソースや設計に合わせた表現方式を選ぶ
5.リンクとフォームを利用してリソース同士を結びつける
6.イベントの標準的なコースを検討する
7.エラーについて検討する
書込み可能なWebサービスの設計
書き込み可能なWebサービスを作るとき考えるべきこと
バッチ処理
リソースを一括で送信すること。
トランザクション
複数のリソースのまたがった変更をひとまとまりに行うこと。
片方のリソースの変更が成功して、もう片方が失敗したりしないように、2つとも処理が成功するか、もしくは２つとも失敗するようにする。
排他制御
複数のクライアントが一度に一つのリソースを編集して競合が起こらないように、一つのクライアントのみが編集するよう制御する処理のこと。
悲観的ロック
ユーザをあまり信頼せずに、競合が発生しないようにする排他制御の方法
ロックの権限を持っている人しか編集できない
楽観的ロック
通常の編集では文書をロックせずに競合が起きたときだけ対処する
リソースの設計
リソース指向アーキテクチャの設計アプローチの罠
「Webサービスで提供するデータを特定」し、「データをリソースに分ける方法」が確立されていないこと
現状は以下を用いるといい
・関係モデルとオブジェクト指向モデルを組み合わせる
関係モデル
中心となるテーブルが持っている属性をリソースに持たせて、リソースが持つデータを検討する
オブジェクト指向モデル
クラスのメゾットを操作結果リソースと考えてリソースを分けてみる
図書館情報学の観点からデータを切り分ける
わかったこと
ネットワークの構造
Webアプリの内部構造や、設計方法
初心者で、WEBフレームワークやAPIについて理解したい人にはおすすめです！
ここ最近の気づきについて
こんばんは、Hinataです。
ここ最近で、考えたことがあるので忘備録として残しておきます。
ほとんど一度は他者から言われたり、書籍で見たことではあるけれども、
自分の頭で考えたり、経験したうえで納得すると、
今後の自分の思考プロセスにそれを使えるのでとても良いです。
最近考えたこと（箇条書き）
・世の中にポジティブもネガティブもない、ただ事象のみが存在すること
・正しい、良き生き方は存在しないこと
・相手の心や考え方を想像しようとするのは悪いことではない
ただ、相手の心や考え方を完全に理解できると思わないほうがいいこと
・世の中には自分の努力ではどうにもならないことが存在すること
・「社会を良くしたい」という考え方には、今の社会に対する不安・怯え・憤りがあること
・人の性格には長所と短所があるようにみえるが、
その長所が嫌いな人、その短所が嫌いな人も一定数存在すること
だから人の性格に優劣は存在しないこと
・人を理論で納得させるのは限界があること
納得できてもそれを自分の中に落とし込むのは難しい
真に理解するためには自分の頭で一回考えたり、経験してみて納得するしかないこと
・自分が危機感や不安だったり辛い思いを感じていても
自分を俯瞰的に見ると、いくらでも人生における選択肢は存在しており
取り返しのつかない失敗はほとんど存在しないこと
・上記だからこそ人が強迫観念を負わず、一貫性を保ち続けることは難しい
本当に心から思うことだけをやることが、
精神的安定と一貫性の両立なのではないか
・人に嫌悪を感じる時は、
自分もその嫌悪を持った対象と近いものを持っており、
その自分に嫌悪感を感じているにすぎないこと
・人はとてつもなく不安定で一貫性のない人間というものに意思決定を望むし、
価値観を左右されるし、信頼するしかないこと
・人には守るべきものがあるため、全員の味方にはなれないこと
優先順位が存在するのは仕方ないことである
・極論、自分を救えるのは自分しかいないこと
・私が考えたことが客観的に真実であるかどうかは最も重要なわけではない、
ただ「自分はこうなりたい、これを信じる」と思ったことは真実であり、重要なことであること
人にそれを否定されても、誰も自分を変えることはできない
それと同じで、自分も相手の信念を変えることはできないということ
・何かを達成することが人生の目的である必要はないこと
・（これは完全に個人の意見ですが）
世の中にポジティブもネガティブもないことを踏まえると、
幸せであるとは、「自分の行動に納得し、現状に満足している」状態を指しているのではないか。
これは社会的地位にも金銭にも成功体験にも左右されないので、
「頑張る」「成長する」ことでつかめるものではない
ただ気づくしかないこと
・上記より、大切なものは目に見えないものであること
これを自分の頭で思いつき、咀嚼して落とし込めたことは
大きな価値なのではないかと思います。
これらのことは自分の中では理解していたつもりなのではあったのですが、
相手から言われて納得するのではなく、
行動した結果から、自分の頭でこの結論に至らないと自分に落とし込むことはできないですね。
これからも常に行動し続け、
その結果を受けての気づきを大事にしていきたいです。
TGS2017で感じた、開発側とユーザの感覚の違いについて
こんばんは、Hinataです。
今日は、10時から16時まで、た～～っぷりとTGSを楽しんでまいりました。
今回、VRブースに注目して、多くまわっておりました。
楽しい紹介記事は他の方がお書きになっていると思うので、
私はそこで得た気づきをシェアできればと思っております。
※私は、先端テクノロジー系の会社に属しておりますが、VR関係者ではございません。
先端テクノロジーに関する、開発側とユーザの意識の違い
先端テクノロジー分野は、とかくプロダクトの価格が消費者側の高いハードルになっています。
それでもいかにして、ユーザに足を運んでもらうorハードを買ってもらうかが勝負です。
その時にとても重要な問いが、
「それって”OO”である必要あるの？？」
ユーザからすると、
多機能でいろいろなことができるようになったみたいだけど、
ただ、お金を出すには至らない…
TGSの場合VRで置き換えてみてください。
VRに人々が求めているのは「圧倒的没入感」だと思います。
ということは、
そのプロダクトは、VR使って、人々の没入感を本当に強められてる？
そもそもそのプロダクトによって感じたい感覚、体験は「圧倒的没入感」が必要なの？？
この質問にYesと答えられるかが大事です。
でなければ、
ユーザからすると、制作側がそのテクノロジーを使ってみたいから作っただけ、
ということになってしまいます。
それを考えてみると、
VRが今後伸びるのは、アダルト業界ではないか？と私は見ています。
先端テクノロジー業界は、いかに、そのテクノロジーでないと達成できない価値を生み出せるかがカギなのではないでしょうか。
私にもとても耳が痛い話なのですが、
他業界の展示場で大きな学びを得ることができました。
自分の業界にたとえて、
もう少し考えられたらと思っております。
二週間開けるとプログラミングの勉強はきつくなる。
こんにちは、Hinataです。
最近、プログラミングに触れられず2週間が過ぎました。
ブログを見てくれている方は、ご存知かとは思いますが、
ずっとメンバーと一緒に頭を絞っていたので、
手を動かすことはあまりしませんでした。
その代わり、2週間でプログラミングの勉強についてたくさんアドバイスをもらいました。
ググる力がとても大切であること。
ものを作ってみると、楽しく勉強ができること。
基本から少しずつ積み上げていくこと。
アルコリズム理論を理解すること。
データ処理では、データの前処理が作業の8割を占め、前処理で基礎的なプログラミングスキルが生きてくること。
プログラミングとはエラーとの戦いであること。
わからなかったらすぐ調べること。
などなど。
まず今日中に、
「IDEではなく、pythonファイルを作って、コマンドプロンプトで開けるようになること、
コマンドプロンプトの使い方をもう一度おさらいすること」
この二つをこなしてから、
簡単なプロダクトでも制作してみようと思います。
思考法2～考え方を考える
こんにちは、Hinataです。
目的を視野に置きつつ、
最適な問いを考えるようになることが
目下の課題です。
これが出来ないと何が困るのかって、
闇雲に考えていても、
とても時間がかかり、
かつあまりいい答えがでないからです。
以下に考え方のフローをあげてみるので、
参考にしてみてください。
もっとこういう方がいいのではとかあれば是非！
何を目的とするのか
その目的を達成するために考えるべき問いを考える
なぜその問いに至ったのか
なぜその問い以外ではないのか
その問いは目的にそっているのか
考える
その問いに答えを出す
この答えの理由を考える
別の視点で考えてみる
その問いは本当に必要なのか考える
答えが出せないならどこがわかったらその問いに答えが出せるのか考える
問いが抽象的すぎてないか？
その問いの中で定義が曖昧なものはないか？
（頭の中で、考えることが目的なのではなく、目的を達成するために考えているのだという意識を常に持っておくこと）
意味のある思考をし続けるのってとても難しいです。
日々成長し続けようと思います。
