[公費教育]Day 41
基本的なjavascript文法を学び、今日は気分文法をもとにWeb APIを分析し、状況に応じてカスタマイズした実習時間です.
しかし、APIの概念は分かりにくいので、この機会にAPI、Library、FrameWorkについて簡単にまとめたいと思います.
APIはアプリケーションプログラミングインターフェースの略であり、プログラム間のインタラクションの媒介である.簡単に言えば、APIはリモコンの役割を果たしています.
例えばテレビの電源を入れます.では、リモコンやテレビのボタンを押してテレビをつけます.このとき、リモコンは私たちがテレビを起動させる機能を利用できるインタフェースです.
これを番組に代入すると、テレビという番組の電源機能を利用するために、私たちの番組はリモコンというAPIを通じて要求し、APIは対応する機能をアクティブにしてテレビの電源を入れます.
これにより,APIはプログラム間の接続点となる.ここでさらに,APIの実装ロジックは,一般ユーザがそのロジックを見るのが困難であることを指摘する.
同様に、リモコンもリモコンの回路を知って使用することは少ない.したがって,開発者はプログラムユーザにAPIの使用方法を提供し,これに基づいてユーザから要求を出す.
論理概念では、ライブラリとフレームワークはメモリ上で実行されるモジュールにすぎません.しかし、抽象的な概念から言えば、両者には明らかな違いがある.もちろん区別がはっきりしない人もいますが、決めたほうがいいです.
そこで両者の違いをどう整理するかを考えて、「建物」でライブラリとフレームを整理しました.
私たちは「建築」を建てた建築家です.今からビルを建てましょう.もちろん、建築過程はもっと複雑ですが、簡単な例として、あまり投入しないでください.
私たちが一人で建物を建てるなら、自分で準備しなければなりません.招待者、設計図、そして投資は、立地から一つ一つ選びます.また、着工する場合はパイプを設置したり、骨格を独自に持ち上げたりします.
簡単にするために、答えはすでに作られたものを使うことです.そのため、建築デザイナーから設計図をもらい、専門企業を通じて人材を募集し、不動産企業を通じて土地を知るなど、独自に行うのではなく、「特定の機能」を持つ企業に任せる.
開発の観点から見ると、図庫がなく、開発は「独立自主」である.したがって、開発効率を向上させるために、ライブラリでいくつかの機能が検索され、使用されています.つまり、必要に応じて使います.
もちろん、開発前に必要なライブラリを事前に作成したり、必要に応じて他のライブラリを変更したりすることができます.この点,ライブラリの重点は開発者がライブラリを「インポート」することである.
すなわち,開発者はプログラムの必要性に応じてライブラリ内のメソッドと変数を呼び出す.これがフレームワークとライブラリを区別する境界点です.
建設過程で必要に応じてライブラリを使用した場合,フレームワークの目的は明確である.
例えば、フレームワークは私が建てる建物のすべてのものを確定しました.すなわち、別荘、オフィスビル、田園住宅、マンション、ビルなどの建築対象によって、使用する企業、技術、材料が決定される.
そして、種類を確定すると、フレームワークは私たちに建物を建てるように要求します.別荘を建てることを決めた場合、フレームワークは「この部分に別荘設計図が必要で、パイプは特定の種類で、鉄筋はどのブランドなどですか」と要求されます.
私たちがそれに従って伝えると、フレームワークが建物を建ててくれます.もちろん、フレームワークは同じ結果を生成しません.つまり、フレームは建築に骨格を提供するだけで、フレーム内、内部設計のようなもので、建設者はカスタマイズすることができます.
開発プロセスから見ると,効率的に開発を行うことはライブラリと変わらない.私たちのプログラムにライブラリをインポートするだけであれば、フレームワークは私たちが開発するプログラムのタイプに応じて選択して使用されます.
もちろんこれも作ることができますが、市場にはすでに多くの人が使っている様々なフレームワークが存在しています.また,ユーザが多いため,機能や話題の処理速度も比較的速い.
また,最も重要なライブラリとの分離点は,開発の主導権は開発者ではなくフレームワークにある.そこで,開発者はフレームワークに基づいて作成したルールに従って対応するコードを入力する.もちろんその中で私たちは.
この方式は,オブジェクト向けの継承と抽象によって実現される方式に従う.すなわち,開発者は単純なメソッド呼び出しではなくフレームワークの要求に従って充填する.
したがって、ライブラリとフレームワークの違いは、「開発主導者は誰ですか?」はい.
Web APIとは、Web上で使用されるAPIのことである.これは、他人が作成したWebアプリケーションを使用したい場合に、Web APIの使用方法に従ってアプリケーションを操作できるHTTPサービスです.
このようなWeb APIはNAVER、KACAなど無数の企業が作成して提供している.独自のプラットフォームを拡張する手段として、「NAVER IDへの登録」などが典型的なWeb APIである.
無料で多く提供されていますが、接続サーバであるため、呼び出しの制限にかかわるため、適切に使用するのは礼儀正しいです.もちろん使用してもよいし、許容範囲内で適用してもよい.
しかし、APIの概念は分かりにくいので、この機会にAPI、Library、FrameWorkについて簡単にまとめたいと思います.
API
APIはアプリケーションプログラミングインターフェースの略であり、プログラム間のインタラクションの媒介である.簡単に言えば、APIはリモコンの役割を果たしています.
例えばテレビの電源を入れます.では、リモコンやテレビのボタンを押してテレビをつけます.このとき、リモコンは私たちがテレビを起動させる機能を利用できるインタフェースです.
これを番組に代入すると、テレビという番組の電源機能を利用するために、私たちの番組はリモコンというAPIを通じて要求し、APIは対応する機能をアクティブにしてテレビの電源を入れます.
これにより,APIはプログラム間の接続点となる.ここでさらに,APIの実装ロジックは,一般ユーザがそのロジックを見るのが困難であることを指摘する.
同様に、リモコンもリモコンの回路を知って使用することは少ない.したがって,開発者はプログラムユーザにAPIの使用方法を提供し,これに基づいてユーザから要求を出す.
論理概念では、ライブラリとフレームワークはメモリ上で実行されるモジュールにすぎません.しかし、抽象的な概念から言えば、両者には明らかな違いがある.もちろん区別がはっきりしない人もいますが、決めたほうがいいです.
そこで両者の違いをどう整理するかを考えて、「建物」でライブラリとフレームを整理しました.
私たちは「建築」を建てた建築家です.今からビルを建てましょう.もちろん、建築過程はもっと複雑ですが、簡単な例として、あまり投入しないでください.
Library
私たちが一人で建物を建てるなら、自分で準備しなければなりません.招待者、設計図、そして投資は、立地から一つ一つ選びます.また、着工する場合はパイプを設置したり、骨格を独自に持ち上げたりします.
簡単にするために、答えはすでに作られたものを使うことです.そのため、建築デザイナーから設計図をもらい、専門企業を通じて人材を募集し、不動産企業を通じて土地を知るなど、独自に行うのではなく、「特定の機能」を持つ企業に任せる.
開発の観点から見ると、図庫がなく、開発は「独立自主」である.したがって、開発効率を向上させるために、ライブラリでいくつかの機能が検索され、使用されています.つまり、必要に応じて使います.
もちろん、開発前に必要なライブラリを事前に作成したり、必要に応じて他のライブラリを変更したりすることができます.この点,ライブラリの重点は開発者がライブラリを「インポート」することである.
すなわち,開発者はプログラムの必要性に応じてライブラリ内のメソッドと変数を呼び出す.これがフレームワークとライブラリを区別する境界点です.
Framework
建設過程で必要に応じてライブラリを使用した場合,フレームワークの目的は明確である.
例えば、フレームワークは私が建てる建物のすべてのものを確定しました.すなわち、別荘、オフィスビル、田園住宅、マンション、ビルなどの建築対象によって、使用する企業、技術、材料が決定される.
そして、種類を確定すると、フレームワークは私たちに建物を建てるように要求します.別荘を建てることを決めた場合、フレームワークは「この部分に別荘設計図が必要で、パイプは特定の種類で、鉄筋はどのブランドなどですか」と要求されます.
私たちがそれに従って伝えると、フレームワークが建物を建ててくれます.もちろん、フレームワークは同じ結果を生成しません.つまり、フレームは建築に骨格を提供するだけで、フレーム内、内部設計のようなもので、建設者はカスタマイズすることができます.
開発プロセスから見ると,効率的に開発を行うことはライブラリと変わらない.私たちのプログラムにライブラリをインポートするだけであれば、フレームワークは私たちが開発するプログラムのタイプに応じて選択して使用されます.
もちろんこれも作ることができますが、市場にはすでに多くの人が使っている様々なフレームワークが存在しています.また,ユーザが多いため,機能や話題の処理速度も比較的速い.
また,最も重要なライブラリとの分離点は,開発の主導権は開発者ではなくフレームワークにある.そこで,開発者はフレームワークに基づいて作成したルールに従って対応するコードを入力する.もちろんその中で私たちは.
この方式は,オブジェクト向けの継承と抽象によって実現される方式に従う.すなわち,開発者は単純なメソッド呼び出しではなくフレームワークの要求に従って充填する.
したがって、ライブラリとフレームワークの違いは、「開発主導者は誰ですか?」はい.
Web API
Web APIとは、Web上で使用されるAPIのことである.これは、他人が作成したWebアプリケーションを使用したい場合に、Web APIの使用方法に従ってアプリケーションを操作できるHTTPサービスです.
このようなWeb APIはNAVER、KACAなど無数の企業が作成して提供している.独自のプラットフォームを拡張する手段として、「NAVER IDへの登録」などが典型的なWeb APIである.
無料で多く提供されていますが、接続サーバであるため、呼び出しの制限にかかわるため、適切に使用するのは礼儀正しいです.もちろん使用してもよいし、許容範囲内で適用してもよい.
例1:カカオ郵便番号API(https://postcode.map.daum.net/guide )
<!--(External) API 호출-->
<head>
<script src="//t1.daumcdn.net/mapjsapi/bundle/postcode/prod/postcode.v2.js"></script>
</head>
<body>
<input type="text" id="postcode" placeholder="우편번호">
<input id="search" type="button" onclick="execDaumPostcode()" value="우편번호 찾기">
<!-- 이벤트를 속성으로 주는 방법. 해당 이벤트 발생시 함수가 실행 됨. -->
<input type="text" id="jibunAddress" placeholder="지번주소">
<script>
// 1. 이벤트 처리
document.getElementById("search").onclick = function () {
// 2. Postcode 객체 생성
new daum.Postcode({
// 3. oncomplete 실행 : 팝업에서 검색결과 항목을 클릭했을때 실행할 코드를 작성하는 부분.
"oncomplete": function (data) {
// 4. data의 필드를 요소의 값으로 세팅
document.getElementById('postcode').value = data.zonecode;
document.getElementById("jibunAddress").value = data.jibunAddress;
}
}).open();
// function() { new daum.Postcode({}).open(); }
}
</script>
</body>
例2:KACA MAP API(https://apis.map.kakao.com )
<head>
<script type="text/javascript"
src="//dapi.kakao.com/v2/maps/sdk.js?appkey=52ec254ddb8604aaaeda68c52f02a0c1"></script>
</head>
<body>
<!--지도를 담을 레이아웃 -->
<div id="map" style="width:500px;height:400px;"></div>
<!--응용 : 여러 개의 마커 찍기, 우클릭으로 마커 없애기, 마커 보이기/감추기 -->
<p>
<!--마커 표시 버튼 -->
<button onclick="hideMarkers()">마커 감추기</button>
<button onclick="showMarkers()">마커 보이기</button>
</p>
<script>
let container = document.getElementById('map'); // 지도를 담을 영역의 DOM 레퍼런스
let options = { // 지도를 생성할 때 필요한 기본 옵션
center: new kakao.maps.LatLng(37.566535, 126.97796919), //지도의 기본좌표.
level: 6 // 지도의 레벨(확대, 축소 정도)
};
let map = new kakao.maps.Map(container, options); // 지도 생성 및 객체 리턴
// MAP CONTROL
let mapTypeControl = new kakao.maps.MapTypeControl();
map.addControl(mapTypeControl, kakao.maps.ControlPosition.BOTTOMLEFT);
let zoomControl = new kakao.maps.ZoomControl();
map.addControl(zoomControl, kakao.maps.ControlPosition.LEFT);
// 이벤트 처리
kakao.maps.event.addListener(map, 'click', function (mouseEvent) {
// 클릭한 위치에 마커 표기할 함수 호출
addMarker(mouseEvent.latLng);
});
// 마커 객체를 담을 배열 생성
let markers = [];
// 마커 객체를 생성하고 지도위에 표시하는 함수
function addMarker(position) {
// 마커 객체 생성
let marker = new kakao.maps.Marker({
position: position
});
// 마커 객체에 우클릭 이벤트 처리(삭제)
kakao.maps.event.addListener(marker, 'rightclick', function () {
marker.setMap(null);
});
// 마커가 지도 위에 표시 설정
marker.setMap(map);
// 생성된 마커를 배열에 추가
markers.push(marker);
}
// 배열에 추가된 마커의 표시 설정값을 바꾸는 함수
function setMarkers(map) {
for (let i = 0; i < markers.length; i++) {
markers[i].setMap(map);
}
}
// "마커 보이기" 버튼을 클릭하면 호출되어 배열에 추가된 마커를 지도에 표시
function showMarkers() {
setMarkers(map)
}
// "마커 감추기" 버튼을 클릭하면 호출되어 배열에 추가된 마커의 설정값을 바꿈
function hideMarkers() {
setMarkers(null);
}
</script>
</body>
Reference
この問題について([公費教育]Day 41), 我々は、より多くの情報をここで見つけました https://velog.io/@ho_c/국비교육-Day-41テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol