概要 毎月最低2冊程度は技術の本とそれ以外の本を1冊づつ読むようにしているが、なかなかアウトプットするための時間もとれず、読んで終わりになってしまうことが多いのでせめて毎月何を読んだかの記録だけでも残していこうと思います。 1冊目 Vue.js入門 有名どころのSPAのフレームワークを勉強してみたいなと思って読んでみた。Vue.jsの基礎的な考え方や文法(構文)も細かく記載されており読みやすかった。後半にかけては最低限アプリケーションを開発するために必要となるプラグイン(Vuex,Vue router,Vue Loader 等)についても説明されており、全部理解すれば簡単なアプリくらいなら作れるようになれそうと思った。前半部分の基礎編は今後のためにメモを下記のブログでも残してみました。 2冊目 君は何のために「働く」のか あまりこういう自己啓発っぽい本は読まないのだが、期間限定のセールで半額だったので思わずタイトルで衝動買いをしてしまった。恥ずかしながら渋沢栄一さんが誰かもわからず読んでおり、時代のギャップはかなり感じつつも感化される部分も多々あった。とりあえず、仕事や勉強に今まで以上に真面目に取り組んでいこうと思った。 3冊目 Software Design 2021年7月号 先駆けに学ぶゼロトラストの現実解TRUST ゼロトラストについて色々書いてありそうだったので、久々にSoftware Designを買ってみた。実際にゼロトラストの有識者が各自の視点でゼロトラストに関する理解や設計について記載されており非常に参考になった。
概要 「Vue.js入門 基礎から実践アプリケーション開発まで」の本を読んだのですが、特に前半パートでのVue.jsの基本的な文法を中心に備忘として整理します。後半パートでは、Vue.jsで使用できるプラグインのVue RouterやVuexなどについても記載されていたましたが、本記事では割愛します。 導入 Webの歴史 1990-2000 Webの誕生、Javascript/CSSのWebブラウザ搭載 2000-2010 サーバサイドベースのアプリケーションフレームワークの誕生Ajax/JQuery/HTML/Node.jsの登場 2010-2018 AltJsの登場、Webフロントエンドライブラリ/フレームワークの登場Babel/ESLint/Webpackなどの様々なツールの登場 AltJsとは ES2015と前後して登場したJavaScriptを変換できるAltJSと呼ばれるプログラミング言語より簡潔な構文を目指したCoffeeSript、型を注釈として付与するTypeScriptが有名 Web Componentsの要素 Custom Elements HTML Template Shadow DOM HTML imports Vue.jsの特徴 コンポーネント指向 リアクティブなデータバインディング(双方向バインディング) プログレッシブフレームワーク 宣言的レンダリング クライアントサイドルーティング = Vue RouterでSPAに対応 大規模向け状態管理 = コンポーネント間で状態の共有方法 リアクティブなデータバインディング(双方向バインディング)は以下のイメージ プログレッシブフレームワークとは=フレームワークはどんな時でも、どんな規模でも、段階的に柔軟に使えるべきである=必要になった時に問題解決するライブラリを適宜導入して問題を解決する 宣言的レンダリングとは=データ変更のたびにリアクティブなDOMレンダリングとユーザによる入力データの同期が可能 Vue.jsはビュー層に焦点があてられたライブラリで、厳密にはフレームワークではない以下のような様々なプラグインで構成されているVue Router：ルーティングプラグインVuex：大規模なWebアプリケーションを構築するための状態管理プラグインVue Loader：webpack向けのローダーライブラリVue CLI：コマンドラインツールVue DevTools：開発ツール 基本構文 UIは、データとそのデータを画面に表示するビュー、データを変更するユーザのアクションの3つから成り立っている コンストラクタ VueインスタンスをDOM要素にマウント(適用)することで、Vue.jsの機能がその要素内で使えるようになる マウント elプロパティで指定したDOM要素をマウント メソッドによるマウントelプロパティを定義せずに、$mountメソッドを用いる UIのデータ定義 dataプロパティには、UIの状態となるデータのオブジェクトを指定するdataプロパティに与えた値はVue.jsのリアクティブシステムに乗るVueインスタンス生成時にdataを与えておき、それをテンプレートで表示するのがVue.jsの表示の基本的な仕組み テンプレート構文 Mustache記法 {{ }}でデータや式を記述 ディレクティブによるHTML要素の拡張 名前がv-で始まる属性(v-bind 等 フィルタ {{ 値 | フィルタ }}フィルタは関数で定義する 算出プロパティ 公開プロパティを算出する関数を定義する ディレクティブ 条件レンダリング(v-if/v-show) 違いは、v-ifは式の結果に応じてDOM要素を追加・削除するのに対して、v-showはスタイルのdisplayプロパティの値を変更することで実現 クラスとスタイルのバインディング v-bind:class=”オブジェクト・配列”v-bind:style=”オブジェクト・配列” リストレンダリング(v-for) 配列あるいはオブジェクトのデータをリストレンダリングv-for=”要素 in 配列” イベントハンドリング v-onはイベントが起きた時に属性値を実行する v-on:イベント名=”式として実行したい属性値” フォーム入力バインディング(v-model) ビュー(DOM)で変更があった時に、その値をVueインスタンスのデータとして更新 ライフサイクルフック created: インスタンスが生成されて、データが初期化された後に呼ばれるmounted: インスタンスにDOM要素が紐づいた後に呼ばれるbeforeDestroy: インスタンスが破棄される前に呼ばれる メソッド(methods) データの変更やサーバーにHTTPリクエストを送る際に利用する コンポーネントの基礎 コンポーネントを作成する Vue.component(tagName, options) コンポーネントを継承する Vue.extend() コンポーネント間の通信 親コンポーネントから子コンポーネントにのみデータを渡すことが可能となっている propsオプションを利用する親からはテンプレートの属性(v-bind)経由で渡すことができる子コンポーネントから親コンポーネントにはカスタムイベントを使用する イベントのリスン：$on(eventName)イベントのトリガー：$emit(eventName)
概要 Lightning Web Componentで複数のコンポーネント間でパラメータを引き渡して連動して動作するための通信を行う仕組みについて整理してみました。Custom EventとLightning Message Serviceの方法を用いて、下記のように殆ど同じ動作をするサンプルを作ってみたので、それぞれでどのような実装になるかを記載します。 デモ ソースコードはこちらhttps://github.com/yhayashi30/lwc-pub-sub Custom Event デモ Lightning Message Service デモ Custom Event Custom Eventは標準のDOMイベントとなります。Custom Eventは、コンポーネント間が階層になっている場合に上位と通信する際に使用することができます。detailパラメータであらゆる型のデータを引き渡すことができます。 Custom EventのPublisher サンプルコード Custom Eventを作成するには、CustomEvent() コンストラクタを使用します。Custom Event() コンストラクタでは、第一引数のイベント名を表す文字列のみが必須のパラメータとなります。(サンプルでは”selected”を使用。onは付けなくて良いので注意。)Custom Eventをディスパッチするには、EventTarget.dispatchEvent() メソッドを引数に作成したCustom Eventをセットして実行します。Custom Event自体にパラメータを設定したい場合には、detailプロパティを用いてJSONで自由に定義して、受信側でeventリスナーを通じてアクセスすることができます。サンプルコードでは選択したContactのSalesforce IDを渡すようになっております。 Custom EventのSubscriber サンプルコード subscriberとなるコンポーネントでは、publisherのコンポーネント(c-custom-event-publisher)を子コンポーネントとして設置します。publisherで作成したCustom Eventのイベント名に”on”を付与して(今回のサンプルコードでは”onselected”となる)リスンします。 Lightning Message Service Lightning Message Serviceを使用することで、Lightningページ内のコンポーネント間でフラットに通信を行うことができます。同じ Lightning ページに組み込まれた Visualforce ページ、Aura コンポーネント、および Lightning Web コンポーネント間で通信を行うこともできます。Lightning Message Serviceを使用するには、各コンポーネントから呼び出すLightning メッセージチャネルが必要となります。Lightning メッセージチャネルを作成するには、LightningMessageChannel メタデータ型を使用します。LightningMessageChannel を作成するには、SFDX プロジェクトを用いて、force-app/main/default/messageChannels/ ディレクトリにXMLの定義を含める必要があります。LightningMessageChannelのファイル名は、messageChannelName.messageChannel-meta.xml 形式とします。これを作成して、対象の組織にデプロイします。 Lightning メッセージチャネルのサンプル SFDXプロジェクトの以下のディレクトリに作成します。/force-app/main/default/messageChannels Record_Selected.messageChannel-meta.xml LMSのPublisher サンプルコード PublisherのコンポーネントからメッセージチャネルでメッセージをPublishするには、範囲設定されたモジュール @salesforce/messageChannel をコンポーネントの JavaScript ファイルに含め、Lightning Message Service の publish() 関数をコールします。 Publisherのコンポーネントの JavaScript ファイルでは、メッセージチャネルと、メッセージチャネルを操作するために必要な Lightning Message Service 関数をインポートします。 上記でインポートした@wire(MessageContext) を使用して MessageContext オブジェクトを作成します。 handleContactClick() メソッドは、Publishするメッセージコンテンツを作成します。Lightning Message Service の publish() 関数は、メッセージコンテキスト、メッセージチャネルの名前、メッセージペイロードの 3 つのパラメータを取ります。メッセージペイロードには自由にパラメータを設定することができるので、今回のサンプルコードではContactのSalesforceIDを設定します。 LMSのSubscriber サンプルコード Subscriberのコンポーネントでも、メッセージチャネルでメッセージの登録および登録解除を行うには、メッセージチャネルを @salesforce/messageChannel 範囲設定されたモジュールから Lightning Web コンポーネントにインポートします。 Lightning Message Service の subscribe() 関数と unsubscribe() 関数をJavaScriptファイルの中で呼び出すことで制御します。@wire(MessageContext) を使用してコンテキストオブジェクトを作成します。 connectedCallback()でコンポーネントの初期化処理で、Lightning Message Service の subscribe() メソッドをコールして subscription に割り当てます。subscribe() メソッドは、メッセージコンテキスト、メッセージチャネルの名前、公開されたメッセージを処理するリスナーメソッドの 3 つの必須パラメータを取ります。 disconnectedCallback()でコンポーネントの削除処理の中で、Lightning Message Service からのメッセージの受信を停止するためにお、登録参照を渡して unsubscribe() をコールします。 Custom Event vs LMSの比較 参考 Communicate with Eventshttps://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events Message Servicehttps://developer.salesforce.com/docs/component-library/bundle/lightning-message-service/documentation Lightning Message Service を使用した DOM 間の通信https://developer.salesforce.com/docs/component-library/documentation/ja-jp/lwc/lwc.use_message_channel ライフサイクルフックhttps://developer.salesforce.com/docs/component-library/documentation/ja-jp/lwc/lwc.reference_lifecycle_hooks
概要 本記事では、Salesforceの主に外部サイトの構築のログイン認証で使用するソーシャルサインオンを整理します。ソーシャルサインオンではSalesforceがRP(Relying Party)となり、認証/認可はソーシャル(Facebook/Google/Twitter etc)で行います。基本的にはOpenID Connectを用いたシングルサインオンとなるため、内部ユーザというよりExperience Cloudなどの外部ユーザのログインに使用されるケースが多いかと思います。 内部ユーザ向けに利用されるSAMLの認証フローについては下記の記事を参考にしてください。 OpenID Connectとは RESTベースで実装されており、クラウド系のサービス、アプリケーションに向いた仕組みである。OpenIDに対応した実装を作るプログラマ視点で見るとSAMLよりも容易に実装を構築できる。先にRPにアクセスするユースケースしかサポートしていないため、ログインポータルを作ることはできない。OpenID ConnectはOAuthの技術をベースにしている。OAuthは厳密にはSSOではなく、権限移譲のためのプロトコルである。 OpenID ConnectやOAuthについて、詳細の流れやフローについては下記の記事を参考にしてください。 ソーシャルサインオンの認証フロー ソーシャルサインオンの認証フローはOpenID Connectを用いており、下記のようなシーケンスとなっております。 ソーシャルサインオンの設定 Facebookに認証用のアプリを作成 Facebookの開発者サイトから自分のアカウントにログインしてアプリ作成を行います。https://developers.facebook.com/ アプリIDとapp secretを取得します。 認証プロバイダの作成 FacebookをIDPとする認証を行うためにSalesforceの認証プロバイダを作成します。プロバイダタイプは「Facebook」を選択し、取得したアプリID→コンシューマ鍵、app secret→コンシューマの秘密を入力します。登録ハンドラは、一旦[登録ハンドラテンプレートを自動作成]を選択しておきます。 登録ハンドラーを更新 開発者コンソールから自動生成されたApexを下記のGitHubのサンプルコードで上書きします。なお、プロファイル名やアカウント名などはサンプルなので組織の情報に合わせてアップデートする必要があります。https://github.com/salesforceidentity/IdentityTrail-Module3/blob/master/SimpleFacebookRegistrationHandler.cls 外部サイトへの紐付け Experience Cloudのワークスペース – 管理 – ログイン&登録の設定で先ほど作成した認証プロバイダを有効化します。 FacebookのアプリにリダイレクトURIを登録 動作検証 外部サイトにアクセスしてログイン画面に表示されているFacebookのアイコンを押下します。 Facebookのログイン画面にリダイレクトされます。 Facebookへのログインが成功すると、Facebookの認可の画面が表示されます。 許可するとContactやUserが自動生成されてサイトへログインしている状態となりました。 参考 ソーシャルサインオンの設定https://trailhead.salesforce.com/ja/content/learn/modules/identity_external/identity_external_social 認証プロバイダhttps://help.salesforce.com/articleView?id=sf.sso_authentication_providers.htm&type=5 登録ハンドラーhttps://developer.salesforce.com/docs/atlas.ja-jp.apexcode.meta/apexcode/apex_auth_plugin.htm
概要 本記事ではSAML認証フローを用いてシングルサインオンを実現する流れをSalesforceのプラットフォームでの設定を用いて仕組みを整理します。 主な用語の内容は以下の通りになります。 Idp Identity Provider。ユーザーのIDやパスワードなどの認証情報を提供する役割を果たす。 SP Service Provider。IdPに認証を委託し、IdPによる認証情報を信頼してユーザーにサービスを提供する。OpenID Connectの場合には、RP (Relying Party) ともいう。 SAMLとは SAMLは、Security Assertion Markup Languageの略であり、Webサービスベースのシングルサインオンプロトコルである。認証情報のやりとりなどにXMLを利用。企業向けの従来型のソフトウェア製品などで採用されているケースが多い。利用者先にIdpにアクセスするユースケース(Idp Initiated)と、先にSPにアクセスするユースケース(SP Initiated)の両方をサポートしている。 OpenID Connectとの使い分け SAMLはOpenID Connectとは違いIdpとSPが直接通信を行う必要がないという点が一番大きな違いであるため、大体の使い分けは以下の通りになります。 SAML・・・エンタープライズ向け OpenID Connect・・・コンシューマーサービス向け SAMLフロー種類 Idp-Initiated Idp-Initiatedフローは、Idp側が起点となるのでユーザがIdpのログイン画面等にアクセスする処理から始まり、認証を行った後にSAMLレスポンスに含むSAMLアサーションをSPで検証してログイン状態とします。 SP-Initiated SP-Initiatedフローは、SP側が起点となり未ログインであった場合にはIdpへリダイレクトしてIdpで認証を行った後にSAMLレスポンスに含むSAMLアサーションをSPで検証してログイン状態とします。 SalesforceでのSAML SalesforceでのSAML認証フローを用いたシングルサインオンの設定を確認していきます。 統合IDを設定する シングルサインオンでログインするSalesforceのユーザに保持する統合IDを設定します。 SSOプロバイダを作成する シングルサインオン設定で『SAMLを有効化』をチェックします。 SAMLシングルサインオン構成を作成します。 上記のシングルサインオン設定に対してIDプロバイダから返されるSAMLアサーションのサンプルは以下の通りとなります。 Salesforceのログイン画面へIDPを追加 [私のドメイン]の認証設定で上記のIDPを認証サービスとして選択することで、IDPのログイン画面へリダイレクトさせることができるようになります。 参考 内部ユーザのシングルサインオンの設定https://trailhead.salesforce.com/ja/content/learn/modules/identity_login/identity_login_sso SAML シングルサインオンを使用するサービスプロバイダとして Salesforce を設定https://help.salesforce.com/articleView?id=sf.sso_saml.htm&type=5 [私のドメイン] ログインページへの ID プロバイダの追加 https://help.salesforce.com/articleView?id=sf.domain_name_login_id_prov.htm&type=5
概要 Kindle Unlimitedに加入してみて良さそうな技術書を探していたところ一番におすすめで出てきた「オブジェクト指向でなぜつくるのか 第2版」を読んでみたのでそのまとめを書きたいと思います。本書ではオブジェクト指向(以降OOPと記載、Object Oriented Programming language)の特徴を大きく「プログミング技術」と「汎用の整理術」の2面からわかりやすく言語化して記載されていました。特に「プログラミング技術」の部分では他の技術書でよくある現実世界に無理やり置き換えた比喩を極力使わずに言語と図を用いて表現されていた部分がよかったと思います。 「オブジェクト指向でなぜつくるのか 第2版」 内容 プログラミングの歴史 機械語→アセンブリ言語→高級言語→構造化言語(GOTOレス)→オブジェクト指向(OOP) 機械語：コンピュータが解釈できる言語 アセンブリ言語：アセンブリ言語を使って書いたプログラムは、それをコンパイルするアセンブラと呼ばれるプログラムに読み込ませて機械語を生成 高級言語：FORTRANやCOBOLなどの人がわかりやすい言語。 構造化言語(GOTOレスプログラミング)：基本三構造(順次実行、if文による条件分岐、for文やwhile文による繰り返し)。サブルーチンで独立性を高めて、複数サブルーチン間はグローバル変数で共有する。代表的なのはC言語。GOTO文を極力使わないように。 オブジェクト指向(OOP)：グローバル変数問題、貧弱な再利用の2つの課題を解決させるために登場。Simula67→Smalltalk→Javaの流れ。 オブジェクト指向の特徴整理 3大要素 クラス(まとめる、隠す、たくさん作る) 関連性の強いサブルーチン(関数)とグローバル変数を1つにまとめて粒度の大きいソフトウェア部品をつくる仕組み。 サブルーチンと変数を「まとめる」、メソッドとインスタンス変数(属性、フィールド) クラスの内部だけで使う変数やサブルーチンを「隠す」、カプセル化 1つのクラスからインスタンスを「たくさん作る」、インスタンス ポリモフィズム(呼び出す側を共通化) 英語で「いろいろな形に変わる、多態性、多相性」 類似したクラスに対するメッセージの送り方を共通にする仕組み 目的は呼び出す側を共通化すること 実装は継承を使う 継承(重複を排除する) モノの種類の共通点と相違点を体系的に整理する仕組み 似たもの同士のクラスの共通点と相違点を整理する仕組み 目的はクラスの共通部分を別クラスにまとめること 進化した仕組み パッケージ クラスをまとめる仕組み クラスの名前の重複を全世界で避ける役割もある 例外 戻り値とが違う形式でメソッドから特別なエラーを返す ガベージコレクション ヒープ領域に作成されて、使われていないインスタンスを自動的に削除する仕組み ガベージコレクタと呼ばれるシステムが用意する専用のプログラムがインスタンスをメモリから削除する 実行方式とメモリの使用 コンパイラ方式：プログラムに書かれた命令をコンピュータが理解できる機会に変換したから実行する方式 インタプリタ方式：ソースコードに書かれたプログラムの命令をそのばで逐次解釈しながら実行する方式 コンパイラ方式とインタプリタ方式コンパイラ方式は実行効率がよく、インタプリタ方式では同じプログラミングを異なる環境で動作させることができる 中間コード方式：ソースコードを特定の機械語に依存しない中間コードに変換し、その中間コードを専用のインタプリタによって解釈して実行する Javaや.NETで採用されている 中間コード方式により同じプログラミングを異なる実行環境で効率良く動かすことができる スレッドとプロセススレッドはプログラムの実行単位で、複数のスレッドでひとまとまりの1つのプロセスとなる 静的領域：プログラムの開始時に確保され、以降プログラムが終了するまで配置が固定される領域 ヒープ領域：プログラムの実行時に動的に確保するためのメモリ領域 スタック領域：スレッドの制御のために使うメモリ領域。ヒープ領域は複数のスレッドで共用されるが、スタック領域はスレッドに1つずつ用意される。 LIFO(Last In First Out) OOPでのメモリ領域クラス情報は静的領域にロードされる OOPのプログラムは、ヒープ領域を大量に使って動く。 インスタンスはヒープ領域に作成されるが、変数に格納されるのはメモリの場所を指すポイント。 実装で注意すべて点は、不要になったインスタンスをスタックやメソッドエリアから参照し続けないようにすること フレームワークやデザインパターン フレームワークには、「包括的なアプリケーション基盤」の意味と「特定の目的のために書かれた再利用部品群」の意味がある フレームワークでのポリモフィズムと継承の役割ハリウッドの法則(Don’t call us, we will call you)：基本的な処理はフレームワーク側で用意し、アプリケーション固有の処理はポリモフィズムを利用して呼び出す アプリケーション固有の処理は継承の仕組みを利用してあらかじめデフォルトの機能を用意しておく GoFデザインパターン(23種) 4人の技術者(Gang of Fourの略) デザインパターンに慣れる Iterator：1つ1つ数えあげる Adapter：一皮被せて再利用 サブクラスに任せる Template Method：具体的な処理をサブクラスに任せる Factory Method：インスタンス作成をサブクラスに任せる インスタンスを作る Singleton：たった一つのインスタンス Prototype：コピーしてインスタンスを作る Builder：複雑なインスタンスを組み立てる Abstract Factory：関連する部品を組み合わせて製品を作る 分けて考える Bridge：機能の階層と実装の階層を分ける Strategy：アルゴリズムをごっそり入れ替える 同一視 Composite：容器と中身の同一視 Decorator：飾り枠と中身の同一視 構造を渡り歩く Visitor：構造を渡り歩きながら仕事をする Chain of Responsibility：責任のたらい回し シンプルにする Facade：シンプルな窓口 Mediator：相手は相談役1人だけ 状態を管理する Observer：状態の変化を通知する Memento：状態を保存する State：状態をクラスとして表現する 無駄をなくす Flyweight：同じものを共有して無駄をなくす Proxy：必要になってから作る クラスで表現する Command：命令をクラスにする Interpreter：文法規則をクラスで表現する UML 13種類 クラス図：クラスの仕様とクラス間の関係を表現する 複合構造図：全体 – 部分構造を持つクラスの実行時の構造を表現する コンポーネント図：ファイルやデータベース、プロセスやスレッドのソフトウェアの実装構造を表現する 配置図：ハードウェアやネットワークなど、システムの物理構造を表現する オブジェクト図：インスタンス間の関係を表現する パッケージ図：パッケージ間の関係を表現する アクティビティ図：一連の処理における制御の流れを表現する シーケンス図：インスタンス間の相互作用を時系列に表現する コミュニケーション図：インスタンス間の相互作用を構造中心に表現する 相互作用概要図：条件によって異なる動作をするシーケンス図をアクティビティ図の中に含めることで表現する タイミング図：インスタンス間の状態遷移や相互作用を時間制約つきで表現する ユースケース図：システムが提供する機能と利用者の関係を表現する ステートマシン図：インスタンスの状態変化を表現する モデリング 業務分析 現実世界の仕事がどういう役割でどのように進めているのかを整理 合わせて、業務を遂行する上での課題を抽出し、コンピュータに任せる仕事を決めるための情報源とする 要求定義 現実世界の仕事の中からコンピュータに任せる仕事を定義する 設計 ハードウェアの能力、OSやミドルウェアの特性、プログラミング言語の表現能力などを考慮して、ソフトウェアの構造を決める 開発手法 ウォーターフォール RUP(Rational Unified Process) XP(eXtreme Programming) アジャイル TDD(Test Driven Development) リファクタリング CI(Continuous Integration) 関数型言語 関数型言語では、関数の実行を「引数に関数を適用する」と表現する 命令型言語と関数型言語の違い 命令型言語では、命令を実行すると表現するが、関数型言語では数学用語と同様に式を評価すると表現する まとめ 基礎的な内容が多かったが、初心者にも比較的わかりやすく記載されていた。経験者であっても、改めてオブジェクト指向の概要を幅広く復習できるのでおすすめできる。また、本書の途中に登場したデザインパターンは非常に気になったので次は下記を読みたくなった。 「Java言語で学ぶデザインパターン入門」https://www.amazon.co.jp/dp/B00I8ATHGW
概要 本記事は、2020/5/31に開催されたABC169のB,C問題を整理した内容を記載します。D問題までの回答を目指しているにもかかわらず、まさかのB,C問題でつまづいてしまいました。非常に不甲斐ない結果ですが、しっかりできなかったポイントを整理していきたいと思います。ただ、TwitterやYoutubeのコメントを見ていると同じようにB,Cで苦戦している人が多かったようなので、少しだけほっとしていました。 B – Multiplication2 問題 https://atcoder.jp/contests/abc169/tasks/abc169_b 解説 PDF https://img.atcoder.jp/abc169/editorial.pdf Youtube 理解 N個の整数Ajを全て掛け合わせして解を求めるという非常にシンプルな問題です。ポイントは2つあって、まず1つはAjは0になることがあるということ。もう1つはAjは最大で10の9乗であり、そのまま全てをかけるとオーバーフローを起こしてしまうということです。python3.0の場合は、int型が多倍長整数であるので基本的にメモリがある分は桁数を使用することができます。なので、単純に毎回掛けて10の18乗を超えていないかをチェックする処理で動作します。 実装 参考 – 任意精度演算 https://ja.m.wikipedia.org/wiki/%E4%BB%BB%E6%84%8F%E7%B2%BE%E5%BA%A6%E6%BC%94%E7%AE%97 C – Multiplication3 問題 https://atcoder.jp/contests/abc169/tasks/abc169_c 解説 PDF https://img.atcoder.jp/abc169/editorial.pdf Youtube 理解 与えられたAとBの2つの整数をかけて、解は小数点以下を切り捨てて表示するというC問題にしては簡単すぎる問題だと思って解いたところ、しっかりと罠が仕掛けられていました。それはfloat型の浮動小数点により掛け算を行うと精度が足りず、誤差が発生してしまうというものです。したがって、安全な方法としてはfloatからDecimalに変換して掛け算を行うことで誤差をなくすことができます。注意点としてはpythonのDecimal関数の引数は誤差をなくすためにはStringで引数を指定する必要があるということがあります。 実装 参考 – 浮動小数点数 https://ja.m.wikipedia.org/wiki/%E6%B5%AE%E5%8B%95%E5%B0%8F%E6%95%B0%E7%82%B9%E6%95%B0
概要 SalesforceのLightning Web Component(LWC)をローカルサーバーで動かせる機能がBeta版でリリースされていたので、どんなものかを触って確かめてみました。 準備 Local Dev Server用のCLIをインストール 最終的にはSalesforce CLIのパッケージに含まれるようですが、現在はBeta版なので含まれていないので、個別にインストールする必要があります。 組織の認証 Devhub組織と認証して、Scratch組織を作成しておきます。どうやら接続先はSandboxではなくScratch組織である必要があるみたいです。この辺は結構前に書いた記事ですが、下記をご参照ください。 Salesforce DXの基礎の基礎https://qiita.com/yhayashi30/items/80dd868f2e15aac67072 ローカルサーバーを起動 下記のコマンドを実行することでnode.jsがローカルサーバーを起動してくれます。 また、VSCodeのコマンドパレットで下記を実行して操作することもできます。 起動して開くSFDX: Open Local Development Server 起動SFDX: Start Local Development Server 停止SFDX: Stop Local Development Server 表示(選択したLWCのソースコードを右クリック)Preview Lightning Web Components in VS Code これで準備ができたので、localhostにアクセスすると画面が表示されるはずです。 http://localhost:3333/ 特徴 ローカルのLWCを画面描画 最初、localhostにアクセスすると自分のローカルプロジェクトに含まれているLWCがリンクでリスト表示されます。 リンクをクリックすると、LWCがローカルサーバー上で表示されます。また、画面右上にある”View in VS Code”のボタンを押下すると、画面で表示しているLWCのソースコード をVS Code上で表示してくれます。VS Code上でLWCのソースを修正すると即時にローカルサーバーにデプロイが行われて画面が最新化されるようになっているようです。 コンパイルチェックしてくれる 今までSalesforceの開発ではSandboxやScratch組織にソースコードをアップロードしないとコンパイルのチェックはできませんでしたが、ローカルサーバーを使う事でLWCの構文チェックを行ってくれて、どこでエラーが発生しているかを表示してくれます。ちなみにエラー画面は下記のようなイメージで、どこでエラーが起きているかやエラーメッセージも表示されます。 データ表示 LWCはローカルサーバーで動いているのですが、Apexの処理は接続しているScratch組織上で実行するようになっているので、組織のデータを検索したり、登録/更新することも可能なようです。 参考 Local Development (Beta)https://developer.salesforce.com/tools/vscode/en/lwc/localdev Announcing LWC Local Development Betahttps://developer.salesforce.com/blogs/2019/10/announcing-lwc-local-development-beta.html
概要 本記事は、AtCoderのABC165に参加した際に回答することができなかったの問題を解説を読んで理解した内容を記載します。C問題で回答できなかったのは久しぶりだったので、しっかりと復習したいと思います。 問題 C – Many Requirementshttps://atcoder.jp/contests/abc165/tasks/abc165_c 解説 pdf https://img.atcoder.jp/abc165/editorial.pdf 動画(Youtube) 理解 まず計算量を考える部分ですが、数の組み合わせですが等しい数も選択することができるので、玉を並べてそれらに仕切りを置くようなイメージで算出します。具体的にはN個の仕切りとM-1個の玉からN個を選択するときの組み合わせが総数となります。なので、N+M-1 Choose N となり、今回の最大数は19 Choose 9なので92378通りで全探索でも問題ない処理量と考えられます。次に全探索のdfs関数についてですが、全探索を考えるときのポイントは以下の2つです。 一回のステップでどんな処理をすることで次につなげられるか 終了条件をどうするか 今回の実装では、一回の実行ではリストの最後の値をリストに追加する処理を行います。終了条件はリストの長さがNとなると時で、そこでそのリストでの値を計算してmaxをとります。 実装
概要 本記事では、業界標準であるOAuth2.0とOpenID Connectの概要を紹介した後に、Salesforceではそれらをどのように実装することができるのかを簡単に記載していきたいと思います。 本記事のベースとなるOAuth2.0やOpenID Connectの技術的な事項はこちらの本で学習しました。クライアント、認可サーバー、保護対象リソースのそれぞれについてサンプルのソースコードでどのように動作するかが詳細に記載されており理解するのに非常に役に立ちました。おすすめです。 認証・認可とは それぞれ詳細を説明すると非常に長くなるのですが、あえて一言で言うと下記で表せます。 認証 通信の相手が誰(何)であるかを確認すること 認可 とある特定の条件に対して、リソースアクセスの権限を与えること Salesforceにおける認証・認可とは Salesforceで実現可能な認証・認可の仕組みは下記が上げられます。 # 名称 概要 機能名 1 フォーム認証 Webブラウザでユーザ名とパスワードを入力する最も基本的な認証方式 標準ログイン画面 2 2要素認証 認証に2つ目の要素を追加することでセキュリティを強化する Salesforce Authenticator 3 SSO 一回の認証で複数のサービスを利用できる仕組みSalesforceは、IdpとSPのどちらになることもできる SAMLシングルサインオン 4 証明書認証 PCもしくはモバイルデバイスに配布されたクライアント証明書でログイン認証を行う 証明書認証 5 OAuth/OpenID Connect ←本記事ではこれを解説 外部アプリケーションにSalesforceのデータへのアクセスする際にその認可を与える仕組み 接続アプリケーション 6 Social Sign on ソーシャルアカウントで認証を行う 認証プロバイダ 7 代理認証 ユーザの認証を外部サービスで行う外部サービスはSalesforceが指定するWSDLに合わせたインターフェースを実装する必要がある 代理認証 OAuth2.0とは 概要 OAuth2.0は、業界標準でありRFCに下記のように定義されております。RFC6794(The OAuth 2.0 Authorization Framework) https://tools.ietf.org/html/rfc6749 ‘OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.’ 言い換えると、下記のように表せます。 リソース所有者の代わりとして対象のリソースへのアクセスを許可するための手段 サード・パーティー製のアプリケーションがHTTPサービスへの制限されたアクセス権を取得できるするようにするためのもの OAuthとはシステムを構成しているある要素から別の構成要素にアクセス権を渡すためのもの では、なんのためにOAuthを使用して認可をするかというと サード・パーティ製のアプリケーションにユーザーの ID & パスワードを渡さない となります。 概要イメージ 0. まずユーザであるリソース所有者がクライアントのアプリケーションを使用します。1. クライアントは、保護対象リソースへアクセスするために一旦認可サーバーへリクエストを行います。2. 認可サーバーはリソース所有者との間でユーザ認証および認可を行います。3. 認可サーバーはユーザとの認証・認可が完了しているので、クライアントへアクセストークンを返却します。4. クライアントは、保護対象リソースへアクセストークンを利用してAPIアクセスを行います。 各構成要素 クライアント ・・・ ソフトウェアであり、リソース所有者の代わりとして保護対象リソースへのアクセスを行うもの 認可サーバー ・・・ OAuthの仕組みの中心的な役割を担うHTTPサーバーのこと. リソース所有者にクライアントを認可するための仕組みを提供し、トークンをクライアントに発行するもの リソース所有者 ・・・ クライアントにアクセス権を委譲する権限を持つ存在. ソフトウェアでなくユーザー. 保護対象リソース ・・・ HTTPサーバーから提供されており、そのリソースにアクセスするにはOAuthのトークンが必要となる. 保護対象リソースは提示されたトークンを検証して、リクエストに応えるかを判定する アクセストークン ・・・ 認可サーバーによってクライアントへ発行され、クライアントに権限が委譲されたことを示すもの スコープ ・・・ 保護対象リソースでの権限を表すものであり、クライアントに付与されるアクセス権限を制限するための仕組み リフレッシュトークン ・・・ 新しいアクセストークンを発行するために使用する 認可コードフロー(Authrorization Code Grant Type) OAuthのいくつかあるフローの中で最も標準的なフローである認可コードフローは下記のようになります。 認可リクエスト/認可レスポンスのイメージ response_type=codeで認可コードフローを指定 codeの値が発行された認可コード トークンリクエスト/トークンレスポンスのイメージ grant_type ・・・ authorization_codeで認可コードフローを指定。 その他のフロー # フロー名 概要 1 認可コードフロー(Authorization Code Type) 最も標準系のフロー。クライアントが認可コードを経由してアクセストークンを取得する。 2 インプリシットフロー(Implicit Grant Type) JavaScriptアプリケーション等で完全にブラウザ内で動作している場合に使用する。クライアントは認可エンドポイントから直接アクセストークンを取得する。 3 クライアント・クレデンシャルフロー(Client Credentials Grant Type) ユーザに関係なくクライアントアプリへ直接アクセストークンを発行する。 4 リソースオーナー・パスワード・クレデンシャルズフロー(Resource Owner Password Credentials Grant Type) 基本的に非推奨。(アンチパターン)アプリケーション側でID、PWを入力させて、それをトークンエンドポイントへ送り直接アクセストークンを取得する。 5 リフレッシュトークンフロー(Refresh Token Grant Type) リフレッシュトークンを使用して、アクセストークンの再発行を行う。 OpenID Connectとは 概要 OpenID Connect Core1.0https://openid.net/connect/ OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. これらをわかりやすく言い換えると下記のように表せます。 OAuth 2.0 ＋ Identity Layer ＝ OpenID Connect Identity Layer ＝ ID Token ＋ UserInfo […]
