WebアプリケーションでJWTをセッションに使う際の保存先は（自分なりに説明できれば）どちらでもよいと思います - 日々量産
以下のツイートを読んで気持ちが昂ったので。 みんな、もうSNSでいがみ合うのはやめよう。 平和に好きなJWTの話でもしようよ。 JWTの格納場所はlocalStorageとCookieのどっちが好き？— 徳丸 浩 (@ockeghem) 2022年2月11日 というのも、JWTをセッションに使うときに保存先含めて一時期悩んでいたので、その時の自分の解。 ただ、考えるたびに変化しているので、変わるのかもしれない。 要約 タイトル。 あとは優秀な方々が既に色々考えておられるのでそちらを読むとよいでしょう。 SPAセキュリティ入門～PHP Conference Japan 2021 JWT カテゴリーの記事一覧 - r-weblife どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ - co3k.org JWT形式を採用したChatWorkのアクセストークンについて -
Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Reactを取り巻く状態管理の潮流を学ぼう。HooksやServer Componentsなどの登場で何が変わるか Reactを取り巻く状態管理のアプローチは変化を続けていますが、いま知っておくべき手法とはどのようなものでしょうか。小林 徹（@koba04）さんに、現在、そしてこの先の状態管理について執筆いただきました。 こんにちは、小林（@koba04）です。 2019年5月に『SPAにおける状態管理:関数型のアプローチも取り入れるフロントエンド系アーキテクチャの変遷』という記事を書きましたが、そこから2年以上が経過し、Reactを用いた状態管理は大きく変わりました。本記事ではReactを取り巻く状態管理の変遷について解説します。 広がるReduxの採用 Hooksの登場 コンポーネントツリーから独立した状態管理 Concurrent Featuresによる新しいユーザー体験 状態とキャ
React+Reduxアプリケーション テスト戦略 | Recruit Tech Blog
はじめに このエントリは全5回を予定する19卒新人ブログリレーの第4回目です。 はじめまして、リクルートテクノロジーズ新卒2年目の高橋 勇人です。 現在は不動産検索サービスSUUMOのフロントエンドエンジニアとして働いています。新卒入社してからの1年間、SUUMOの新機能開発に携わり、物件を地図から探す機能の開発を進めてきました。 SUUMOではこれまでJavaScript+jQueryで開発されてきましたが、SPサイト上で地図による物件探し機能を実現するために、React+Reduxという技術スタックが採用されました。 （※SP＝スマートフォン） 長期的な開発がされてきたプロダクトで、これまで使ってきていなかった技術スタックでの開発を推し進めるにあたり、継続的な保守性を向上するための取り組みの一環としてテストの整備が進められました。 本記事では、React+Reduxでの地図機能の開発に
Electronで組み込み端末向けアプリケーションを開発し3年間運用してみて
組み込み端末のアプリケーションに Electron を採用し開発・運用を行っています。 継続的な機能追加やトラブルサポートを行いながら 3 年が経過したので、Electron を採用した経緯や結果を経験を交えながら共有したいと思います。 組み込み案件自体が初めてでしたのでその話も入っています。 約 700 台ほど導入されており、なかなか大きな案件での採用と思いますので参考になれば幸いです。 ※Electron の基本的な説明は割愛します。 システムについて 一般的に「受付精算機」などと呼ばれ、店頭に何台か並べて設置して自動で受付・精算を行うシステムです。 ホテルの受付端末のイメージです。ハード的にはセルフレジにも近いです。 筐体自体は他社が用意し、弊社はその上に載せる GUI アプリケーションのみを担当しました。 機能 主な機能として 来店受付・整理券発行 予約チェックイン チェックアウト
フロントエンドを考える 〜概念編〜
この記事のシリーズでは私がフロントエンドに関して思っていることを徒然に語っていこうと思います。 ちょっと長くなり過ぎそうなので以下の4つに分けて書いていこうと思います。 1.概念的な話 - フロントエンドアプリケーションとは何でできているか フロントエンドアプリケーションを保守性とユーザへの価値提供を両立して開発するために、アプリケーションを抽象化して、いい感じの設計をする必要があります。 これの土台作りをするために概念としてフロントエンドアプリケーションとは何なのかを考えていきます。 2.技術的な話 - フロントエンドアプリケーションはどのように実行されるか Webフロントエンドはブラウザで実行され、表示のためには HTML, CSS, JS が必要です。当たり前のことではありますが、実際に開発を進めていく上では概念だけでなく、実際に動く How の部分を知る必要があります。 これらの要
Rust を始めるための資料集 - Don't Repeat Yourself
かとじゅんさんのお誘いで、私塾匠真堂にて登壇させていただき、Rust に関する話をさせていただきました。ありがとうございました。 今回のセッションを通じて Rust を始めたくなった方向けに、Rust をはじめるための資料をいくつかリストアップしてます。よかったらどうぞ。 プログラミング言語の学習方法について Rust についてまず概観を掴む 文法を学ぶ 何かアプリケーションを実装してみる ちょっと突っ込んだ話を知りたい コミュニティの力を借りる 仲間を見つける 更新履歴 プログラミング言語の学習方法について みなさんは新しいプログラミング言語を学ぶ際、どのように学びますか？ 私は、軽く制御構文やデータ型の作り方などを学んだ後は、すぐにアプリケーションを作ってみて、詰まったらリファレンスを参照するといった学び方をしていることが多いです。 逆に、リファレンスをまず眺めて、文法をしっかり把握し
RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
DBマイグレーションを行う技術 - 発明のための再発明
データベースのスキーマを変更するということはデータをいじる行為であり、最悪の場合データが消えます。 最悪の事態にはならなくとも、思わぬ場所に影響が起きたり、データの不整合が発生する恐怖と戦う必要が有ります。 テストや切り戻しを含めて計画し、大きな変更の場合にはダウンタイムまで考慮する必要があります。 そこで、RDBを対象にデータベースの変更を行う方法について書いていきます。 スキーマ変更 まずは、スキーマ変更について、 カラムを追加する 一番簡単で、影響も少ない変更です。 気をつけるのは、 ソースコードの変更よりも前にスキーマ変更を完了させる (長時間)ロックがかからない方法を選ぶ といったところでしょうか。 大抵の場合は、スキーマの変更とソースコードの変更の順番にさえ気をつければ問題は発生しません。 カラム名を変更する 「ALTER」でさくっと変えたくなりますが、ソースコードの変更が同時
アプリケーションを作るときに考える25のこと
This document contains code snippets and technical details from various programming languages and frameworks. It includes examples of database queries, model associations, HTTP requests, pagination, and tracking model changes in Ruby on Rails. Thread-local storage is demonstrated using RequestStore to make request information available across different parts of a Rails application.Read less
CarloでNode.jsのツールにUIをもたせる - Qiita
先日、GoogleがCarloというライブラリをリリースしました。 少し気になったので、軽くメモを残しておきます。 Carlo is 何 CarloはChromiumを画面描画エンジンとして動作するNode.js アプリケーションフレームワークです。 Node.js、ChromiumともにV8が動作するため、JavaScriptのみでデスクトップアプリが作れるよ、というわけです。 公式のサンプルとほぼ一緒ですが、次のようにコードを書くと、index.htmlがデスクトップアプリ風に立ち上がります。 const carlo = require('carlo'); (async () => { const app = await carlo.launch(); // html/CSS/JavaScriptを配置しているフォルダを教える app.serveFolder(__dirname); /
快適なUXを実現するOptimistic Updates(楽観的更新)とは何か
先日、とあるJavaScript関連の記事を読んでいたところ、"Optimistic Updates" という技術が紹介されていました。 日本語に直すと "楽観的更新" といったところでしょうか。 はじめて聞いた言葉で、日本語の記事も見当たらなかったため記事にしてみます。 Optimistic Updatesとは Optimistic Updatesというのは、ネイティブアプリやSPA(Single Page Application)などで使われる技術で、非同期の通信処理が成功するという前提(楽観)のもとに、通信のレスポンスを待たずに次の処理を行うというものです。 最も多いOptimistic Updatesの使い方は、UIへの反映をリクエストの結果を待たずに行うというものでしょう。 Optimistic Updatesの例 例えば、よくある「いいね」ボタンのようなものにOptimisti
DynamoDBデータモデリング虎の巻：第弐巻 〜考え方編〜 - misc.tech.notes
前巻のおさらい 前巻はDynamoDBのデータモデリングをする前に知っておいた方が良いDynamoDB自体の仕組みやデータ構造のお話でした。 marcy.hatenablog.com 今回は 今回はデータモデリングを行う際に必要なマインドセット、つまり「考え方」について書き記したいと思います。非常によく聞かれる「RDBとの考え方の違い」といった切り口で進めていきたいと思います。 RDBとはアプローチが真逆 RDBのデータモデリングをする場合、まず正規化されたデータのスキーマを決めることから始めると思います。慣れてくると律儀に第一正規化から始めずにいきなり第三正規形あたりから設計しだすことも多いと思います（私もそうです） そして、データのスキーマが決まってからそれに対してどのようにアクセスするか（＝SQL）をアプリケーションを設計する際に考えていくというのがRDBでの一般的なアプローチではな
進化するWeb ～Progressive Web Appsの実装と応用～(de:code2018より)
2018年5月に開催された日本マイクロソフト主催のイベントde:code 2018で「進化するWeb ～Progressive Web Appsの実装と応用～」というセッションを担当しました。 イベントに参加できなかった方に向けてセッションの内容を記事にまとめましたので、ぜひご覧ください。 進化する Web ～ Progressive Web Apps の実装と応用 ～ from Osamu Monoe この記事では、昨今話題に上ることが多いPWAことProgressive Webアプリケーションについて、実際の作り方を解説しながら、それがいったいどういったものであるかを詳(つまび)らかに紹介することを目的としています。 Webでは、「ネイティブアプリと同じことができる」「ネイティブアプリを置き換える」など、期待に胸を膨らませずにいられない浪漫に満ちた噂がありますが、それが本当かどうか記事
開発者が運用を経験すべき一つの理由 | DevelopersIO
はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計／実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
論理型の設定値を RDB に保存する場合の選択肢と各々のメリット・デメリット
ユーザごとに特定の機能に対して ON/OFF の設定値を持たせることはよくあると思います。 RDB にそのような設定情報を持たせる場合の選択肢として大きく次の 5 つが考えるんじゃないかと思います。 設定項目ごとにカラムを割り当てる 設定項目ごとにレコードを割り当てる（追記：アンチパターンという意見があるので最後に補足を書きました） 設定項目ごとにテーブルを割り当てる（自分は思い付かなかった） 設定項目ごとに 1 つの整数型カラムの 1 bit を割り当てる 1 つのカラムに JSON 等で全ての設定情報を持たせる データベース理論的には 1, 2, 3 以外の選択肢はない気がしますが、実用上は 4, 5 も良い選択となることがあるので、メリット・デメリットを考えて選択する必要があると思います。 そんなわけで、それぞれの選択肢に関してメリット・デメリットを自分なりに考えてみました。 考慮す
オフラインファースト的なGUIアプリケーションをScala.jsで書く話 / Scala.jsについて - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに オフラインファーストへの要求 近年、オフラインファーストというか、「オフラインのときにも普通につかえて、オンラインになったら同期する」みたいなことに対する要求が高まっているように感じます。 その場合は、ローカルにもきちんと永続データを持っておき、オンラインのときにバックエンドと通信をしながらバックエンドのデータと同期していく、というスタイルを考えるのが自然だと思います。 また、普通のJSアプリケーションであっても、「サーバーに投げる際に失敗したデータはローカルでメモリ上にもっておいてリトライしたい」などの要求もあるでしょう。 さらに、ここでモバイルアプリも視野に入っているとなると、どうしても「オッRealm Mobile Platformか！？」という感じが出てきますが、Realm Mobile Platformにロックインされるのと引き換えに開発の速を選ぶのか、それとも、という
Webアプリケーションの遅い処理を特定する話 - MEDLEYオフィシャルブログ
こんにちは、開発本部で「ジョブメドレー」の開発を担当している稲本です。 先日、社内で行っているTechLunchという勉強会で「Webアプリケーションの遅い処理を特定する話」という話をしました。 タイトルの意味する範囲が広めなので概要を記載すると以下の通りです。 NewRelicから処理速度を見ていく ChromeDeveloperTools処理速度を見ていく RoR関連のプロファイラから処理速度を見ていく 上記の様にClientからServer, Applicationまでプロファイリングを行い遅い処理を特定していく流れの話をしました。 なぜこの話をしようと思ったのか 弊社ではフロントエンドエンジニア、サーバサイドエンジニアなどのポジションが明確には分かれておらず、どのバックグラウンドを持った人間も両方開発に携わる方針のため、エンジニア同士が、お互いの得意分野を補い合いながら、各々業務や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
