GitHub - capy-ui/capy: 💻Build one codebase and get native UI on Windows, Linux and WebYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
MagicPod（E2Eツール）を導入して品質とリリース頻度を両立している話
こんにちは！アルダグラムでエンジニアをしている @sukechannnn です。 アルダグラムの開発チームでは、QAチームを中心にMagicPodを用いてE2E自動テストを追加/運用しています。 このE2E活動をスタートしたのが今年の２月で、約半年かけてある程度の成果が見えるところまで来ました。そこで、私たちがどんな理由でE2E自動テストを運用することにしたのか、それによりどんな成果が得られたのかをこの記事では紹介します。 E2E自動テストの導入を検討している方や、どんなツールを使うか迷っている方の参考になれば幸いです。 なぜE2E自動テストを運用することにしたのか アルダグラムでは KANNA というノンデスクワーカーに向けたプロジェクト管理アプリを提供しており、Webアプリケーションとモバイルアプリ（iOS / Android）を開発しています。 KANNA は現場の方でも使いやすいア
AWS、セキュリティ問題を分析する「Amazon Detective」がAmazon EKSのKubernetesワークロードに対応
AWS、セキュリティ問題を分析する「Amazon Detective」がAmazon EKSのKubernetesワークロードに対応 Amazon Web Services（AWS）は、クラウド上で稼働するアプリケーションにおけるセキュリティの問題や不審なアクティビティなどの原因を分析、調査し、特定することを支援するサービス「Amazon Detective」が、Amazon EKSを用いたKubernetesのワークロードに対応したことを、7月26日、27日に開催したイベント「AWS re:Inforce 2022」で発表しました。 Amazon Detectiveは、悪意のあるアクティビティや異常な動作を継続的にモニタリングする脅威検出サービスのAmazon GuardDutyや、名前、住所、クレジットカード番号などの個人情報などの機密データを検出するAmazon Macie、AWSの
AWS アーキテクチャで学ぶ The Twelve Factors App 本格入門 - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
The Twelve-Factor App (以降、「12FA」といいます) とは、Heroku の共同創設者である Adam Wiggins 氏が提唱した、優れたソフトウェアを開発するための方法論です。 2011 年頃に提唱されてからすでに 10 年以上経過していますが、クラウド上の分散アーキテクチャとしてソフトウェアを開発する上で、12FA はアプリケーションの移植性を最大化し、継続的なデプロイを可能とし、レジリエンスや堅牢性を高めるための優れたプラクティスとして、今でも多くの開発者に親しまれています。 2016 年に開催された AWS re:Invent では、Amazon CTO の Werner Vogels 氏による キーノートスピーチ においても、ソフトウェア開発の変革に必要かつクラウドの利点を最大化するためのベストプラクティスとして 12FA が紹介されています。
Increasing the glibc and Linux kernel requirements | Rust Blog
The minimum requirements for Rust toolchains targeting Linux will increase with the Rust 1.64.0 release (slated for September 22nd, 2022). The new minimum requirements are: glibc >= 2.17 (previously glibc >= 2.11) kernel >= 3.2 (previously kernel >= 2.6.32) These requirements apply both to running the Rust compiler itself (and other Rust tooling like Cargo or Rustup), and to running binaries produ
Amazon EKS上でアプリケーションをGraceful Shutdownさせる際に注意すべきポイント | 株式会社ヌーラボ(Nulab inc.)
SRE課で、主にBacklogのSREを担当しているMuziです。 物理サーバやインスタンスで動作していたアプリケーションを、Kubernetesクラスタに移行する際には、いままで暗黙的に存在していた前提に目を向ける必要があります。そのような前提を無視すると、アプリケーションは動作したとしても、可用性が悪化する可能性があるためです。 私たちがBacklogをEC2インスタンスからKubernetesクラスタに移行した際にも、可用性の悪化に繋がる問題に対処する必要が生じました。今回は、そのような問題の一つであるGraceful Shutdownに関する注意点を、私たちの実体験をもとにご紹介します。 なお、以下の内容はAmazon EKSのKubernetesバージョン1.22で確認しました。Amazon EKSに固有の話題も含みますが、Kubernetes全般に共通する部分も多いかと思います
Use One Big Server - Speculative Branches
Thoughts on software, hardware, performance, math, and similar topics A lot of ink is spent on the “monoliths vs. microservices” debate, but the real issue behind this debate is about whether distributed system architecture is worth the developer time and cost overheads. By thinking about the real operational considerations of our systems, we can get some insight into whether we actually need dist
脱Firestoreするために考えていること（追記あり） - Sweet Escape
FirebaseのFirestoreをやめることにしたので雑なメモを残しておく。なお、まだ走り始めたばかりなので、内容には間違いや考慮不足も多数含まれる可能性があるので読む人はその点注意を。あと、あくまでも雑なメモなので細かいところは書いていない。 なぜ脱Firestoreするのか？ なぜGraphQLではなくREST APIなのか？ 移行にあたって検討したこと、決め事 ドキュメントIDをどう扱うか サブコレクションをどう扱うか 配列やマップといったフィールドのタイプをどう扱うか 追記: Mapの配列をどうするか Firebase Authenticationとセキュリティルールで実現しているセキュリティ機能をどうするか では実際にどんなテーブル設計にするのか 次にやること なぜ脱Firestoreするのか？ まず、脱Firestoreする理由は ユースケースとしてFirestoreでは対
Auth0のアクセストークンをLocal Storageに保存するのは安全？メリット・デメリットをin-memory方式と比較して検討する - Flatt Security Blog
※追記: 本記事の続編としてin-memory方式からアクセストークンを奪取するPoCを下記記事で公開しました。ぜひあわせてご覧ください。 はじめに こんにちは。 セキュリティエンジニアの@okazu-dm です。 この記事では、Auth0のSPA SDKでアクセストークンのキャッシュを有効化する際の考慮ポイントについて紹介し、それを切り口にアクセストークンの保存場所に関してin-memory方式とlocalStorage方式の2つについて解説します。 Auth0のようなIDaaSは昨今かなり普及が進んでいると思いますが、Flatt Securityの提供するセキュリティ診断はAuth0に限らずFirebase AuthenticationやAmazon CognitoなどのIDaaSのセキュアな利用まで観点に含めて専門家がチェックすることが可能です。 ご興味のある方は是非IDaaS利用部
Go 1.19 Release Notes - The Go Programming Language
Introduction to Go 1.19 The latest Go release, version 1.19, arrives five months after Go 1.18. Most of its changes are in the implementation of the toolchain, runtime, and libraries. As always, the release maintains the Go 1 promise of compatibility. We expect almost all Go programs to continue to compile and run as before. Changes to the language There is only one small change to the language, a
みんなの銀行がマイクロサービス導入、開発スピードはどれだけ上がったか
マイクロサービスの活用はネット企業が中心だったが、今や一般企業にも広まりつつある。その原動力は、システムを俊敏に変更したい、保守性を高めたいというニーズの高まりだ。ふくおかフィナンシャルグループ傘下の「みんなの銀行」の事例でメリットを見よう。 「競合のフィンテック企業はクラウドに素早くシステムを構築し、プロダクトを磨き上げる。同じ土俵のクラウドに乗り、アジャイル（俊敏）に改善していく」。スマートフォン専業銀行、みんなの銀行の宮本昌明執行役員CIO（最高情報責任者）はGoogle Cloud上に一から構築した勘定系を含む銀行システムのコンセプトをこう話す。 システムの俊敏な変更を可能にするために選んだのが「マイクロサービスアーキテクチャー」だ。比較的小さなサービスをAPI（アプリケーション・プログラミング・インターフェース）経由などで疎結合に連携させて、一連の処理を実現する。従来に比べてサー
送信ドメイン認証（SPF / DKIM / DMARC）の仕組みと、なりすましメール対策への活用法を徹底解説-エンタープライズIT [COLUMNS]
送信ドメイン認証（SPF / DKIM / DMARC）の仕組みと、なりすましメール対策への活用法を徹底解説 実在するメールアドレスを悪用して、マルウェアに感染させたり、ID／パスワードなどの重要情報を騙し取る「なりすましメール」の被害が後を絶ちません。偽の口座に直接金銭を振り込ませるなどの実害も発生しています。なりすましメールは実在の人物を騙り、ビジネスメールのような内容で送られてくるので、人が見分けるのは非常に困難です。この対策に有効な手法が「送信ドメイン認証」です。人では判別が難しいなりすましメールを識別し、被害を未然に防ぎます。その仕組みと効果的な活用法を詳しく紹介しましょう。 （関連記事）新潮流になるか？GoogleとYahooが発表した「今後は受信しないメール」の条件 なりすましメールの被害が拡大している理由とは ここ数年、情報や金銭を搾取される企業被害が相次いで報道されていま
![送信ドメイン認証（SPF / DKIM / DMARC）の仕組みと、なりすましメール対策への活用法を徹底解説-エンタープライズIT [COLUMNS]](https://cdn-ak-scissors.b.st-hatena.com/image/square/a8875d174039686c2e8efce10da0e4cd0d7a7650/height=288;version=1;width=512/https%3A%2F%2Fent.iij.ad.jp%2Fwp-content%2Fuploads%2F2019%2F06%2Fe-security-300x141.png)
Rustとdeno_coreを使って、独自のJavaScriptランタイムを作ってみる
Node.js、Denoに続いて、Bunという新たなJavaScriptランタイムが登場していますが、Denoの7月29日のブログにて、"Roll your own JavaScript runtime"という記事が投稿されていたので紹介します。 タイトルの通り、自分のJavaScriptランタイムを作ってみよう！という記事です。 作り方は元記事に載っているのでここでは省略して、掻い摘んだ内容をまとめていきます。 JavaScriptランタイムの材料 Rust deno_core tokio Rustのdeno_coreとtokioというクレートを使って作っていきます。 deno_core deno_coreって、もうそれdenoじゃんと思いましたが、こちらのクレートはJavaScriptエンジンであるV8との橋渡し的な役割を持つようです。 deno_coreは、複雑で大量のAPIを持つV
一意な識別子の生成でUUID/ULID/CUID/Nano IDなど検討してみた - Sweet Escape
最近、一意な識別子について検討することがあったのでその検討メモ。 一意な識別子とは つまり、重複しない、ユニークな識別子（Identifier, 以下id）のこと。ここではRDBのテーブルにおける主キーとして使うことを想定かつ前提としている。したがって、主キーの要件であるユニーク性を持ったidをどうやって生成していくか。 そんなのDBの連番でいいじゃんて話もあるがここではその話はせず、あくまでも一意な識別子をどう生成するかの話に絞る。 選択肢 一番有名だと思われるUUIDを筆頭にいくつかの選択肢がある。 UUID ULID CUID Nano ID 他にもTwitter発のSnowflakeとか今はDeprecatedになってるshortidなどがあるが、キリがないのでここでは上記の4種類だけで簡単に比較した。また、実際にはUUIDはバージョンによってSpecが異なるがここではバージョン4
オブジェクト指向プログラミングは終わった カプセル化が悪い(感想戦) - Qiita
が(良くも悪くも)注目頂き、その観測で思ったことのメモです。1年後の自分用です！ もっかい言いたいこと再考のポエムです。 概要 関数型には意図的に触れたくなかった 継承や再利用性への懐疑の共通認識 抽象化戦略開発戦略で補う話 タイトルは釣り 抽象化という言葉のふわっと感 カプセル化が問題 関数型言語には意図的に触れたくなかった ポリモーフィズムのくだりで、関数型のご指摘が多かったのですが、あえて直接は触れたくありませんでした。これは、オブジェクト指向 vs 関数型にしたくなかったからです。(結果、Rust/Goに被弾させました) なぜかと言えば、オブジェクト指向を(結果として)衰退させたのは、あくまでも 開発手法の変化 や設計論の精錬が主軸だと認識しています。 不確実性に適応する上で、継承やカプセル化による状態隠匿という戦略が、良い筋に動かず、オブジェクト指向なりに変化を遂げた結果だと考え
SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ぼくらが選んだ次のMySQL 8.0 / MySQL80 Which We Choose
RubyでDSLが書きやすい理由を整理する - Qiita
