Terraform設計・運用のノウハウ - Qiita
概要 Terraformを使い始めて一年ほど経ったので、設計や運用上のノウハウを公開していこうと思います。 基本的にAWSを使うことが多いので、AWS寄りの話になります。 設計編 利用可能なプロバイダを調べる TerraformはAWSやGCPといったクラウドサービスをコード化できることで有名ですが、オフィシャルだけでも様々なプロバイダに対応しています。 私はAWSのほか、GitHubやDatadogをコード化して運用してます。 ネットワーク設計 サービスを構築する上で本番環境のほかに開発やステージング環境を作りますが、環境の分け方は大きく分けて次のいずれかになることが多いと思います。 1つのVPCに全ての環境を入れる 環境ごとにVPCを分ける 環境ごとにAWSアカウントを分ける 2のパターンで設計する場合、Terraformで構成を組む際はVPCをdevelopment、staging、
Androidアプリの審査が長くなった件 - Qiita
8/26 追記 改めて気になることがあったので、サポートチームへ問い合わせをしてみました。 一度目に問い合わせた方と別の方に対応していただいたのですが、「審査は土日祝も含めグローバルチームが対応する」という回答を頂きました。 リリース前の審査はすべてのアプリの公開、更新に対して行うのは確定なようですが、審査にかかる時間については、本記事の情報は参考程度に留めておいてください。 先日Androidアプリをリリースしようといつもどおりの作業を行ったのですが、5時間たっても公開されない状況が続いていたため、なにかあったのかと思いコンソールを見てみると、初めて見るメッセージが表示されていました。 「Androidアプリに審査…？公開後に機械的にやってるんじゃないの…？」 と思ったのですが、Twitterなどで調べてみると、Androidアプリの審査があってアプリが公開できていないという話をされてる
Reactを使ったモダンなフロントエンド開発の環境構築 - Qiita
はじめに Reactを中心としたフロントエンド開発において、以下のような構成を見かけることが多いと思います。 UIライブラリとしてReact 型のある言語としてTypeScript スタイル定義としてstyled-components コンポーネントの開発環境としてStorybook LinterとしてESLint FormatterとしてPrettier この記事では、各種ライブラリについて紹介したのち、それらを使う場合の環境構築についてハンズオン形式で説明します。 ※ アプリケーションを開発する際に必要になる設定が抜けていたので、追記しました。 各種ライブラリの紹介 まず、各ライブラリがどのようなものなのかを簡単に紹介します。 ライブラリの使い方などは公式ドキュメントなどを参照するようにしてください。 ドキュメント ReactはUI(ボタンやフォームなど)コンポーネントを作成するための
P++: 銀河に平和をもたらすための奇策と決着 - Qiita
PHP 8から、PHPは「PHP」と「P++」という2つの言語を提供するようになる というキャッチーな紹介をするP++: 静的型付けをめざすPHPという記事がそれなりに話題になり、このニュースは目覚しく革新的な内容で、多くのひとの目を引き付けました。 これは早まった理解であり、ほとんど誤報と言ってもいい内容でした。2019年8月15日には提案者本人も、少くとも「P++」の計画を短期的に実現するととは非現実的であり時期尚早であることを認めています。 この記事では、PHP開発の現状、なぜ野心的なP++計画が提案され、事実上撤回されたかの経緯について紹介します。 [中立性のための表示] この記事の著者@tadsanはPHPの静的解析を強く推進する立場です。 PHPゆるふわCI入門 PHP型検査･夢と理想と現実) 三行で要約 PHPはバージョンを経るごとに「歴史的経緯」による負債が削ぎ落されてきた
ORM成分高めで帰ってきたPrisma 2 - Qiita
はじめに 少し前にPrisma 2のpreviewがアナウンスされたので、素振りがてら調べてみました。 まだPreviewのため、実装やAPIは大きく変更される可能性があります Prisma 1 v.s. Prisma 2 Prisma 1 ってなんだっけ そもそもPrisma is 何をおさらいしておくと、Prismaは元来graphcoolというGraphQL as a Serviceのバックエンド部分を切り出したフレームワークです。 https://www.prisma.io/blog/prisma-raises-4-5m-to-build-the-graphql-data-layer-for-all-databases-663484df0f60 より また、prisma - 最速 GraphQL Server実装にも書いてある通り、 GraphQL の形をした ORM MySQL/
ngrokよりserveoがすごい。０秒で localhostを固定URLで公開 - Qiita
注意 serveoがサービス停止中です。 みんな大好きcloud functionには欠点があります。 それは、実際にコードをデプロイしないと、httpsで公開できないこと。 そのため、slackのコマンドを作ったり、ラズベリーパイとかを開発するのに不便だったりします。 以前私はngrokというcliアプリを使っていました。 とても使いやすく、ユーザー登録＋ngrokのインストール＋セットアップだけで使い始めることができます。 お金を払えば固定URLもゲットできます。 しかし、今回もっと良いものを見つけたので紹介します。 serveoです。 なんとこのserveoインストールもセットアップも不要です。 ターミナルで、以下のように ssh -R 80:localhost:3000 serveo.net と打つだけで自分のPCのlocalhost:3000を、固定URLでhttpsとして公開し
Cloud Firestoreの柔軟性を利用して新しいパーミッションの仕組みを考えた - Qiita
// /version/1/article/0 { title: "hoge", body: "hoge", isPublished: true, author: "1amageek" } // もしくは // /version/1/user/1amageek/article/0 { title: "hoge", body: "hoge", isPublished: true, author: "1amageek" } どっちがいいでしょうか？ 前者は、検索性に優れているけど、isPublished === trueを入れ忘れただけの簡単なヒューマンエラーでサービス潰す可能性ありますよね？😇 僕ならやりたくない。と言うことで、後者にしましょう。 いや待てよ。。。🤔 公開した時に必ず全文検索を噛ませないといけない。。orz このくらいはCloud Firestoreだけでやりたいじゃん。
コンテナイメージビルドが遅いなら、Kaniko使うと幸せになれる（全部入りRails Dockerfileを参考に） - Qiita
コンテナイメージビルドが遅いなら、Kaniko使うと幸せになれる（全部入りRails Dockerfileを参考に）GitLabCircleCITravisCIDockerkaniko 結論 BuildKit対応してないCI/CD（サービス）使ってるならKaniko使えば早くなるよ Google Cloud Build使ってるなら迷わず使っておくべき Amazon Elastic Container Registry（ECR）でも問題なく使用できる この記事の例でいうと未キャッシュからフルキャッシュなら 288秒→132秒に短縮（約2倍） 御託はいいのでどう書くか教えて ここに書いてますので、自分の使ってるCI/CDサービスに当てはまるのを選んで参考にどうぞ https://github.com/chimame/kaniko-example 本題 長いうんちくや説明を知りたい人向けです。
TypeScript v3.5.1 変更点 - Qiita
こんにちはメルペイ社な@vvakameです。 TypeScript 3.5がアナウンスされました。 RCのときのアナウンスはこちら。 RCが出たなーと思っていたらあれよあれよと時間が…。 What's new in TypeScript in 3.5 Breaking Changes in 3.5 TypeScript 3.5 Iteration Plan TypeScript Roadmap: January - June 2019 Roadmapはこちら。 この辺に僕が試した時のコードを投げてあります。 変更点まとめ コンストラクタと高階化推論 Higher order inferences for constructor functions 訳語があってるか全然わからん 関数の引数に、型パラメータが1個あるような関数またはコンストラクタを渡すと返り値の型が推論に利用される という意味
Dockerfileを書くためのベストプラクティス【参考訳】v18.09 - Qiita
概要 Docker Documentation にある、Best practices for writing Dockerfiles の参考日本語訳です。ドキュメントは、2019年5月31日現在のカレントである Docker v18.09 (current) です。 背景 ―― 以前の翻訳から時間が経過し、全体的に手直ししたいものの、差分が大きすぎる状況です。そのため、リファレンスや重要性の高いものから優先的に着手することにしました。 スライド資料 背景やヒント、図解などを追加した補足用スライドを作成しました Dockerfile を書くためのベストプラクティス解説編 BuildKitなどの最新機能や Dockerfile の記述例については、こちらのスライドをご覧ください。 Dockerfileを改善するためのBest Practice 2019年版 Dockerfile を書くためのベ
TypeScriptで型のユニットテストをしたい - Qiita
export type TypeEq<A, B> = (<T>() => T extends A ? 1 : 2) extends (< T >() => T extends B ? 1 : 2) ? true : false export function assertType<_T extends true>() {} export function assertNotType<_T extends false>() {} 色々複雑になっていますが、これは any や union、never などに対応するためです。 ここらへんの型は少し特殊なため、このようにしないと正常にテスト出来ません。 テストの書き方 import { TypeEq, assertType, assertNotType } from "./test" assertType<TypeEq<1, 1>>() asse
色んなMacでXcodeのビルド時間比較。開発用にどのMacを買うべきか？ - Qiita
結果を見るとモデルの新旧に関わらずシンプルにコア数×クロック数が高いほど速い。 ビルド時間はクロック数×コア数にだいたい反比例してるっぽく見える サンプル数が少なく心もとないが、グラフにするとビルド時間はコア数×クロック数にだいたい反比例してるように見える。 だとすると、ビルド速度はコア数×クロック数にだいたい比例しているということになる。 （ちゃんと見ると2コアと4コアの間に傾きの飛びがあるように見えるが、だいたい反比例していることにしておく。。。） また、速度がコア数に比例するということは、Xcodeはマルチコアを全て活用できているということになる。 CPUのTurbo Boost機能は一部のコアしか使えない場合に有効になるので、Turbo Boostの周波数はビルド速度に影響しないと予測できる。 並列設定を変えるとビルドは早くなるのか？ defaults write com.appl
モダンSalesforceアプリケーション開発 DX編 - Qiita
Salesforce DX向上委員会によるプラットフォーム愛護週間の記事です。 Salesforce組織における開発の問題点 Salesforceでシステムを作る際の良い点というのは、ほぼエンドユーザのような非エンジニアでもポイント＆クリックでカスタマイゼーションできてしまうところです。もちろん、エンジニアであっても、UIで作業をしてそのままプロトタイピングできるというのは大変効率の良いものです。 ただ、もちろんこれは諸刃の剣であって、一般的なシステム開発では当然のように使われているVCS（Version Control System; gitなど）と相性がとても悪いということが挙げられます。アプリケーションを構成する情報のソースがSalesforce組織内に閉じられてしまい、コードにコミットされたものと異なってしまいがちだからです。 Salesforceは、エンドユーザ自身がカスタマイズ
Keycloakとは - Qiita
（2022年1月14日追記）この度、日立製作所さんとNRI OpenStandiaメンバ共著でKeycloakの解説本を出版させていただくことになりました。本記事の最後に書籍のご紹介をしております。 何故、Keycloak？ Keycloakはオープンソースのアイデンティティ・アクセス管理ソフトウェアです。シングルサインオンやAPIアクセスの認証・認可制御を実現するもので、この分野のソフトウェアとして後発の部類に入ります。現在コミュニティベースの開発が進められており、この分野のソフトウェアとしては最も勢いのあるソフトウェアの1つと言われています。技術トレンドの発信元として有名なThouthtWorksのTechnology Radarでも、この3月（2017年3月）に初めて名前が上がりました。またつい先日の最新版ではASSESSからTRIALに評価が変わっており、ますます注目度が上がってい
【警鐘】[改元][Windows][.NET] 「令和」対応パッチで画面が横に伸びる、文字が見切れる ― Windows Update 手動更新はちょっと待った方がいい - Qiita
【警鐘】[改元][Windows][.NET] 「令和」対応パッチで画面が横に伸びる、文字が見切れる ― Windows Update 手動更新はちょっと待った方がいい ※2019年5月15日（日本時間）に自動配信が開始された修正版パッチで、フォント起因の横伸び、見切れ問題は解消されました。（2019/05/15 続報 をご参照ください） 2019年4月26日、「令和」対応パッチが Windows Update で配信開始されました。 日本の元号の変更について - KB4469068 現状は手動更新（「更新プログラムのチェック」）または Microsoft Update カタログからのインストールのみで、自動更新への反映は来月半ば頃と見られています。 また、Windows 10 Version 1809 / Server 2019 向けのパッチは "Coming soon" となっており、
![【警鐘】[改元][Windows][.NET] 「令和」対応パッチで画面が横に伸びる、文字が見切れる ― Windows Update 手動更新はちょっと待った方がいい - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e2cf1351e57bef57c13ab7cea6c1abd8f83acc63/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZ0eHQ9JUUzJTgwJTkwJUU4JUFEJUE2JUU5JTkwJTk4JUUzJTgwJTkxJTVCJUU2JTk0JUI5JUU1JTg1JTgzJTVEJTVCV2luZG93cyU1RCU1Qi5ORVQlNUQlMjAlRTMlODAlOEMlRTQlQkIlQTQlRTUlOTIlOEMlRTMlODAlOEQlRTUlQUYlQkUlRTUlQkYlOUMlRTMlODMlOTElRTMlODMlODMlRTMlODMlODElRTMlODElQTclRTclOTQlQkIlRTklOUQlQTIlRTMlODElOEMlRTYlQTglQUElRTMlODElQUIlRTQlQkMlQjglRTMlODElQjMlRTMlODIlOEIlRTMlODAlODElRTYlOTYlODclRTUlQUQlOTclRTMlODElOEMlRTglQTYlOEIlRTUlODglODclRTMlODIlOEMlRTMlODIlOEIlMjAlRTIlODAlOTUlMjBXaW5kb3dzJTIwVXBkYXRlJTIwJUU2JTg5JThCJUU1JThCJTk1JUU2JTlCJUI0JUU2JTk2JUIwJUUyJTgwJUE2JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kOTIyZmJkODM2M2I0MjU5ZWFiYTcxMjJmYjk2YWQ3MA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwQ29kZU9uZSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NThlYWIzMDk2OWIwYTgxNzU2Y2UzNzk1MjMyMTA0ODY%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Db1c580bcb75251edbdaf0c5747b44dc1)
AWS Glacier での破産は「過去の話」ではなかった件（90日以前削除課金） - Qiita
(2019/04/26) いただいたコメントに基づいて、わかりずらい表現を修正・補足しました。 AWS Glacier は、大容量データのアーカイブ先として大変重宝します。 2016年11月以前までは「ピーク復元レート」の考え方に基づき、短時間でのデータ取り出しにより高額請求されるリスクがありましたが、改訂後は大幅な値下げとなり、使いやすくなりました。詳細は、以下のサイトが大変わかりやすいです。 Amazon Glacierで高額料金請求は「過去の話」になりました ある日のこと、Glacier の利用料がたった一日で、月額の 1/3 を占めることになりました。 あわてて明細をみると「Glacier：最小期間追加料金」の文字が。 そう、課金の前日、Glacier 上の不要なファイルを一括削除したのでした。 3ヶ月経過する前の、若いファイルも、なにもかも。 あわてて調べた結果、以下の Q&A
スプレッドシートに OKR を書くとツリー構造で可視化されるツールを作ってみた - Qiita
これなに？ スプレッドシートに OKR の目標を書くと、社内に閉じて Web でツリー表示されるツールを作りました。 こちらで実物見れます: http://bit.ly/okr-tree-sample 概要 グロービス の開発部門で OKR のエッセンスを取り入れた目標管理をはじめました。 OKR ではアラインメントの観点で、他のチームがどういった目標を掲げているのか見える化することが大切なので、見える化の仕組みを作ってみました。 使ってみたいという方のために、導入方法も以下に書いておきます。 そもそも OKR ってなに？ ここでは OKR について説明はしませんので、 OKR についての説明は以下ご参照ください。書籍は 2 冊とも読みましたが上の方が個人的おすすめです。 Web Google re:Work - ガイド: OKRを設定する OKRとMBOの共通点・相違点は何か？即時に説明
VSCodeのオススメ拡張機能 24選 (とTipsを少し)
1. vscode-icons アイコンがついて見やすくなる。 2. GitLens とにかく強い。 「コミット単位でのファイル比較」や「最新のコミット内容とそのコミッター表示」など色々してくれる。 git blameする手間なくなる。 3. Prettier コードのフォーマットは自動でやりましょう！ 複数人のこだわりをうんたらするよりも、Prettierに委ねるのが楽。 関連のTipsはここ 4. Git History Git logが見やすい 5. Bracket Pair Colorizer カッコの対応を色付きで表示してくれる。 ものすごく読みやすくなって最高&最高！！ なおBeta版ですが、後継となるBracket Pair Colorizer 2も出ています。 6. Settings Sync どこでも同じ設定で使いたい人には便利。 ⇧ + ⌥ + U/D で設定をアップロ
Java8からJava11への変更点 - Qiita
Java 8からJava 11 http://openjdk.java.net/projects/jdk9/ http://cr.openjdk.java.net/~iris/se/9/latestSpec/apidiffs/overview-summary.html https://openjdk.java.net/projects/jdk/10/ http://cr.openjdk.java.net/~iris/se/10/latestSpec/apidiffs/overview-summary.html https://openjdk.java.net/projects/jdk/11/ http://cr.openjdk.java.net/~iris/se/11/latestSpec/apidiffs/overview-summary.html 言語 まず言語についての変更点です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git のクローンを最小量にする(サブモジュールを含めたshallow clone) - Qiita
