DockerとSSHでセキュリティと手軽さを両立したリモート開発環境を構築する
リモートワークが一般的になり、一方でさまざまな課題が生じてきています。特にコミュニケーションの課題などは多くの人に関係するため大きな関心を集め、急速にさまざまなソリューションが出てきています。一方で開発業務に目を向けると、少しずつ進みつつあるものの、デファクトと言えるほどのものもなく、情報もあまり共有されていないように思います。そこで、筆者がいろいろと試行錯誤をしながら行った施策について紹介したいと思います。 はじめに 今の開発現場ではDockerなどを使った仮想化コンテナを使うことが一般的になっています。そのため、ソースリポジトリ（Gitなど）と仮想化コンテナを使えば、各開発者が開発環境を構築し、業務を進められます。つまり、オフィスのPCを自宅に持ち帰るか、もしくは自宅のPC上で開発環境を構築してしまえばそれで問題は解決するのです。 しかし、どちらの方法もセキュリティや情報管理の観点から
AppStore のアプリ審査通知をノーコードで Slack に通知しよう！ - Qiita
AppStore の審査通知って地味に見逃しますよね... まあ、App Store Connect のアプリを入れれば通知してくれますが、できれば Slack で通知してチーム全員で見たいもの。 というわけで、サクッとアプリ審査通知を Slack に投げましょう！ フロー Slack チャンネルにはメールアドレスを設定でき、そのメアドに送られてきたメールをチャンネルに投稿してくれます。 これを利用して、App Store Connect からのメールを転送するだけです。 実装 1. Slack チャンネルにメールアドレスを設定 チャンネル情報を開いてインテグレーションタブを押し、「このチャンネルにメールを送信する」を押します。 すると、メアドが生成できるので控えておきましょう。 2. App Store Connect からのメールを転送 App Store Connect ってタイトル
AWS SAMでGo+API Gateway+Lambda+DynamoDBのサーバレスAPI構築をIaC化した - Qiita
AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: go-serverless-app-4 Resources: Function: Type: AWS::Serverless::Function Properties: FunctionName: PostAmazonURLFunction Handler: PostAmazonURLFunction Role: !GetAtt FunctionRole.Arn Runtime: go1.x CodeUri: . Timeout: 60 Architectures: - x86_64 Events: CatchAll: Type: Api Properties: Path: /post Method: POST
TLSが難しい？RustとLinuxカーネルで実装しよう！
TLS（Transport Layer Security）が難しすぎると、お嘆きのセキュリティファースト世代の皆様、RustでLinuxカーネルを実装しながら学んでみましょう！ カーネルモジュールの実装は難しい？それは誤解です。TLSをアプリケーションとして実装しようとすると、各種のライブラリを検索していたつもりが、SNSを眺めていて、一日が終わっていることありますよね。カーネルモジュールを実装するために使えるのはカーネルの機能だけです。検索する必要はなく、雑念が生じる余地はありません。その集中力があれば、カーネル開発は難しくありません。 TLSとLinuxカーネル皆様の中には、LinuxカーネルはTLSをサポートしているのでは？と思っている方がいるかもしれません。TLSは実際のデータの送受信の前に、ハンドシェイクと呼ばれる、暗号鍵の合意や相手の認証を実施します。ハンドシェイク後、Linu
VRM1.0を使うメモ（URP対応含む） - Qiita
はじめに VRM1.0を使ってアバターを読み込む時のメモ書きです。 メモ VRMの導入 https://github.com/vrm-c/UniVRM/releases/tag/v0.108.0 に従う。 パッケージマネージャーを使うのが楽。Packages/manifest.jsonのdependenciesに次を追記してEditorを開けば自動インポートが実行される。 ややこしいが、com.vrmc.univrmが0.x系、com.vrmc.vrmが1.x系。混在可能。 // Packages/manifest.json { "dependencies": { // ... "com.vrmc.vrmshaders": "https://github.com/vrm-c/UniVRM.git?path=/Assets/VRMShaders#v0.108.0", "com.vrmc.gl
Maestroで快適なiOS/AndroidのUIテストを！
こんにちは！テラーノベルでiOS/Android/Webとフロントエンド周りを担当している @kazutoyoです！ iOS/Androidといったモバイル向けのUIテストって作るのも大変だし、メンテナンスも大変ですよね🤯 それらをいい感じにメンテナンスしてくれるサービスもあり、テラーノベルでは導入を検討をしていました。 そんな中、今回紹介するMaestroを見つけ、これは…！となったので今回はそちらのお話をします。 🔎 Maestroとは MaestroはiOS/Android用のUIテストフレームワークです。 iOS/Androidのネイティブアプリケーションだけではなく、FlutterやReact Nativeなどのクロスプラットフォームで動作するアプリケーションにも対応しています。 こちらが実際にテストを記述して実行した様子。かんたん！ 🎖️ Maestroの特に優れている点
なぜJestのmockライブラリに混乱してしまうのか？ - Qiita
はじめに JavaScriptのモックライブラリでは、 sinon などが有名であるが、テスティングフレームワークに Jest を使ってるならば Jest組み込みのモックライブラリで済ませたほうが学習コスト少なくて済むだろうと思える。 しかし、 sinon の感覚でJestのモックライブラリを使おうとすると違和感というのか、モックへの考え方の違いに気づかされる。 ということで今回は、Jestのモックライブラリの考え方と使い方を整理していきたいと思う。 モックの用語整理とJestモックライブラリの位置づけ モックと一言でいっても、それが指す内容は微妙に異なる。 ここでは、モックを 広義のMock Object と 狭義のMock Object と分けて整理してくれているテスト駆動開発を参考に用語を整理する。 テスト駆動開発では、モック用語を、下図のとおり、テストダブルとそのサブクラスとして
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
