サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
2024年ランキング
meetup-jp.toast.com
レプリケーション(Replication) ここからはRedisのHA(High Availability)について調べてみましょう。Redisは、マスター(Master) – レプリカ(Replica)形式の複製を提供しています。レプリケーション接続がされている間、マスターノードのデータはリアルタイムでレプリカノードにコピーされます。したがって、サービスを提供していたマスターノードがダウンしても、レプリカノードにアプリケーションを再接続すればサービスを継続できます。 1つのマスターに複数のレプリカノードをつけることができ、レプリカノードに別のレプリカノードを接続することも可能ですが、1つの複製グループには、常に1つのマスターノードのみが存在します。マルチマスターの構造で両方にデータを複製することはできません。 複製方法は非常に簡単で、たとえばマスターノードのIPアドレスが127.0.0.
[Java] Integer.valueOf(127)== Integer.valueOf(127)は真か? Javaには最適化のためオブジェクトをキャッシュするロジックがあります。キャッシュロジックは、アプリケーションのパフォーマンス改善に役立ちますが、意図しない結果を発生させることがあります。さらにクリティカルな障害状況の原因にもなります。 Naresh Joshiの[Java Integer Cache – Why Integer.valueOf(127) == Integer.valueOf(127) Is True]のブログ記事内容を紹介します。Java Integer Cacheについて考えてみましょう。 インタビューで、次のような質問を受けました。 Integer a = 127; Integer b = 127; 上のような2つのIntegerオブジェクトがあります。 a
1.ストレージの種類と特徴 現在、主に使用されているデータストアは、RDBMSとNoSQLに分けられます。それぞれの特性を見てみましょう。 RDBMS 長い歴史を持つ成熟した技術 リレーション(Relation)に基づいて重複保存を最小限に抑える 高い信頼性を持つ 比較的高い性能と多様な機能を持つ 管理の利便性が高く、追加の管理コストが相対的に小さい 変更や拡張が難しい 高性能装置が必要で、リソース消費が多く費用が高い スキーマ(Schema)の変更が困難 テーブルが大きくなるほど遅くなる 拡張が困難 RDBMSは基本的に単一装置で運営されるもので、そのほとんどが水平拡張が困難であったり、制限的である 拡張性不足を解決するには別途方法の検討が必要で、例として次のようなものがある シャーディング(Sharding):アプリケーションで関連ロジックを開発したり、別途ミドルウェアを使用する 読み
はじめに 前回の「メールセキュリティ強化機能 – ドメイン保護」に続き、今回はメール認証方法であるDKIM(DomainKeys Identified Mail)、DMARC(Domain-based Message Authentication, Reporting and Conformance)について紹介します。 DKIM(DomainKeys Identified Mail) TOAST Emailでメールドメインの登録が完了すると、DKIM機能を使用することができます。DKIMは電子メールの認証方法のひとつで、受信サーバーから受信したメールが偽造されていないかをデジタル署名を利用して検証する技術です。送信サーバーは、メール送信時に送信者、受信者、件名、内容などを秘密鍵で署名します。この署名値をDKIM-Signatureヘッダー(Header)に追加します。受信サーバーは、DK
Cookieの値の要件と処理 最も違いが多く複雑な部分では、バージョン別に異なるスペックを提示しています。 Netscape V0 Netscape NAME=VALUE This string is a sequence of characters excluding semi-colon, comma and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, though no encoding is defined or required. This is the only required attribute on the Set-Cookie head
開発を進めていくと、if-else構文やswitch-case構文を本当に多く使用します。論理的思考に基づくと、分岐処理は必須領域であり有用です。しかし、分岐処理は手続き型プログラミングのレガシーとなり、オブジェクト指向の考え方を妨害する要因の1つになりました。 我々が開発でよく考えていることは「可能な限り、分岐処理をなくさなければならない。」というものです。単純な反復分岐を最小化しようと努力すると、その対価としてオブジェクト指向の考え方とコードをナレッジとして得ることができます。 さらに一般化すると、DRY(重複排除)を守る – boiler plateしたコードを減らす – 努力をすると、その答えの1つであるオブジェクト指向の考え方を得られます。 ショッピングモール割引ポリシー 多くの方が理解しやすいショッピングモールドメインでサンプルを作ってみました。 同じ種類の分岐処理がコードのあ
Webコンポーネント(1):Keep calm and #UseThePlatform Webコンポーネント(2):Custom Elements Webコンポーネント(3):Shadow DOM Webコンポーネント(4):テンプレート要素&HTMLインポート 今回は、Webコンポーネントをreactのようにコーディングしてみよう。サンプルで使うコードは、Todo Web Componentsから参照できます。前回の記事で調べたカスタム要素、Shadow DOM、lit-HTMLを使ったWebコンポーネントアプリケーションの作成方法を、サンプルを使って確認してみよう。 WebコンポーネントTODO APP まず、以下のリンクからサンプルページを開いてみよう。 Todo Web Componentsアプリストア Todo Web Componentsアプリのデモ 今回使用するTodo We
これだけはしないでください! それでは多くの方からリクエストいただいたRedisの障害ポイントについてお話したいと思います。Redisがよく分からなくてもこれだけは注意しましょう。 要件を把握する(キャッシュ用 or リポジトリ用?) サービスにRedisを導入する際には、キャッシュ用に使用するか、あるいはリポジトリに使用するかを明確にする必要があります。つまり、Redisに保存したデータがなくなっても同じデータがRDBMSに残っていれば問題ないか、あるいは一部の値が失われても問題がないのか、確認が必要です。特別な場合を除き、一般的にはRedisを永久保存用として使用するのはおすすめしません。 その理由は、Redisのデータをファイルに保存するためのパーシステンス(Persistence)機能(RDB、AOF)によって障害が発生する可能性が非常に高いからです。fork()によるCOW(Co
2部では、ストーリーブックを使ってビジュアル要素のテストを自動化する方法を紹介しました。私たちが作成したタスク管理アプリケーションの実行手順をもう一度整理してみましょう。 アプリケーションが実行されたら、画面にメインUIを表示する APIサーバーから「ToDoリスト」のデータを受け取り、Reduxストアに保存する 保存されたストアの値に応じてToDoリストをUIで表示する ユーザーが入力ボックスをクリックし、「昼寝」と入力してEnterキーを入力する ReduxストアのToDoリストに「昼寝」を追加する 変更されたストアの値によってUIを更新する 変更されたストアの状態をサーバーに送信して同期する この実行手順は、「アプリケーションの状態」を基準に2つに区分できます。まず、取り消し線がついた1,3,6は、現在のアプリケーションの状態を画面(UI)に表示する段階です。2部では、この段階でテス
ローカルテスト環境の限界 前回、単一PCにテスト環境を構築してテストを実行する過程を説明しました。 ローカルPC内でブラウザの自動テストを実行する場合、karma-chrome-launcherが、現在のkarmaの実行環境にインストールされたChromeブラウザを実行します。ローカルPC内で他のブラウザを同時にテストしたい場合、Firefox、Safari、Internet ExplorerやEdgeのkarma launcherを追加登録すれば、テストを実行できます。しかしこのような場合、OSXではInternet Explorerのテストが、WindowsではSafariのテストができません。 そこで今回は、ローカルPC上でテストを実行するのではなく、さまざまなOS・ブラウザ環境において、ブラウザの自動テストを行う方法を調べます。 この記事では、サンプルのテスト環境であるIntern
はじめに TOASTクラウドメッセージングプラットフォームサービスの1つであるPushに追加されたAPNs(Apple Push Notification service)JWT認証機能について、開発中に行った技術調査の内容を共有します。この記事は「JWTの概要」と「JWTをさらに詳しく」の2部構成になっています。「JWTの概要」では、JWTの構造や作成および検証方法について説明し、「JWTをさらに詳しく」では、JWTの特徴や使用事例について紹介します。JWTを利用した機能を開発する際や、JWTを使用する開発者の方に役立つ内容になれば幸いです。 気になった点があれば、LinkedInやGitHubからご連絡お願いいたします。 https://www.linkedin.com/in/jinho-shin-7a9b3292 https://github.com/gimbimloki JWT(J
はじめに アプリケーションを開発するとき、データのバリデーションチェックは一般的にアプリケーション全体で発生します。TOASTのメッセージングプラットフォーム商品であるNotificationは、メッセージ形式、メールアドレス形式、受信・発信者番号など、クライアントの入力値に対して多くの検証を行います。そして、入力値の検証に失敗した際には、エラーに対する原因を把握して理解しやすいようにAPIで適切にレスポンスする必要があります。このような目標を達成するため、Javaにおけるデータのバリデーションチェック標準技術であるBean Validationを採用しました。 この記事では、NHN Forward 2019で発表された、PaaS&API Developer Experience(https://youtu.be/zvuhOz8VhhI)で扱われたBean Validationの内容を文章
はじめに 今回は、Android テスティングフレームワークのRobolectricについて紹介します。 まずは簡単にAndroidのテスト種類を調べて、その後、Robolectricについて紹介していきたいと思います。 Android Test Androidで開発してみると、自然と「テスト」に目が行くようになります。Androidのテストは次の方法に大きく分けられます。 ユニットテスト(Unit Test) インストゥルメント化テスト(Instrumentation Test) ユニットテストは、文字通り「単体テスト」を意味します。テスト駆動開発(TDD、Test-Driven Development)で、「事前テスト第一」での開発をしていると、「機能単位別」にテストコードを構成して、そのテストコードを通過する実際のコードを作成したりしますね。あるいはその逆も可能です。このとき使用され
この記事は、Chris BeamsのHow to Write a Git Commit Messageブログの内容を簡単にまとめた資料で、翻訳・編集して、役に立つ内容を追加したものです。 Gitのコミットメッセージをうまく作成すべき理由 なぜコミットメッセージをうまく書く必要があるのか?理由は色々ありますが、うまく書かれたコミットメッセージが有益であるという事実は、多くのプログラマが同意することでしょう。そのうち代表的な3つの例を挙げてみます。 コミットログの読みやすさ より良いコラボレーションとレビュープロセス コード保守の容易さ 「良いコミットメッセージについて考えることは素晴らしいアイデアだと思う。しかし、良いメッセージの正解があるかは分からない。個人によって良いコミットメッセージと捉える基準が異なるためだ。多くの人々が共感できる良いコミットメッセージをうまく作るためのルールはないだ
最近の開発者が最も好むドキュメント形式を挙げるとしたら断然マークダウンになるでしょう。マークダウンは、GitHub、GitLab、Bitbucketなど、タスクやイシュー管理に対応するほとんどのサービスにおいて、基本のドキュメント形式として使用されています。また、IntelliJ、VSCode、Vim、Emacsなど、ほぼすべてのテキスト編集ツールでも、プラグインを通じてマークダウン文書の強調構文やプレビュー機能を使用することができます。 TOAST UI Editorはここからさらに一歩進んで、マークダウンエディターとウィジウィグエディターを統合した形式のインターフェースを提供しています。ウィジウィグエディターを使用すると、テーブルなどの複雑な文法をより直感的に簡単に編集することができ、マークダウンに慣れていないユーザーでもマークダウン基盤の文書を簡単に編集できます。特に、開発者と非開発
現在はまさしく、JavaScriptの時代と言えるでしょう。最近の2〜3年で、JavaScriptは最も人気のある言語ランキング1位を維持しており、今も急速に成長しています。10年前、Web標準という概念すらないときからフロントエンドの開発を続けてきた開発者にとっては、非常に感慨深いものがあるでしょう。当時は開発環境という言葉すら恥ずかしいほどに不毛な環境でしたが、現在流通している新しい技術と開発ツールを眺めてみると、まさに”豊かな時代”と言えるでしょう。 なかでも、特に有望なのは「テスト方法論とツールの発展」でしょう。この数年間、フロントエンドのテストは、はるか彼方にある幻想のようなものでした。従来のどのような方法を試してみても、フロントエンドのコードテストには適しておらず、テストコードを作成する努力に比べて、実際に得られる効果はわずかなものでした。しかし、最近登場したテストツールは、過
このページを最初にブックマークしてみませんか?
『NHN Cloud Meetup』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く