リンク goo天気 東京の過去の天気 1995年7月 - goo天気 1995年7月の東京の過去天気をまとめています。1961年からの全国の過去天気データを網羅。 8
![「昔はこんなに暑くなかった」というがここで1995年の気温を見てみましょう「32度で猛暑」「エアコンを使わなくても生きていけた」](https://cdn-ak-scissors.b.st-hatena.com/image/square/fd158b8742d3baf13a246bcec5d8f63060c7178b/height=288;version=1;width=512/https%3A%2F%2Fs.togetter.com%2Fogp2%2F9e2de4cc908e49720e76157580e8db50-1200x630.png)
既存 AWS IAM Identity Center ユーザーを Terraformにインポートする【import ブロックで超簡単】 どうも、ちゃだいん(@chazuke4649)です。 Terraform v1.5にて新たに import ブロックと既存リソースのHCL生成が追加され、config-driven import (手動ではなく設定ファイルが起点となるインポート) が可能となりました。 背景 今まで既存のAWSリソースをTerraformにインポートする方法といえば、 terraform import コマンドによる地道な作業 Terraformer ツール頼み でどちらも厳しい状況でした。 そんな中、v1.5では救世主とも呼べる新たな選択肢が誕生しました。 今回は試しに、マネコン あるいは CLI で作成していた既存の AWS IAM Identity Center ユー
多くの人は資産を残したまま死ぬ。 これを無駄と考える人もいれば、素晴らしいと捉える人もいる。 この違いはどこから生じるのか。 煽り立てるサイトのざんねんな矛盾 この記事がちょっと話題になっていた。 大した話ではないが、要点を紹介しよう。 架空の女性エリザベスは退職時に資産が77万ドル (約1億円) あった 彼女が85歳で亡くなった時、資産は13万ドル残っていた これは彼女が現役で働いていた年収の2年半以上に相当する つまり彼女は2年半以上も無駄に働いたと言える こうならないよう、ゼロで死ぬことを目指せ この記事の主張に対してどう思うだろうか。真っ先に「これは無駄ではなくマージンだろ」と思ってしまう。彼女が85歳で死に、13万ドル残ったのは結果論に過ぎない。もしあと5年長生きしていたらどうなるか。消費ペースが変わらなければ、老後資金は不足していたことになる。 では「退職時に資産1億円も貯める
日焼け止めは2~3時間おきに塗り直しましょう 日焼け止めは数値よりもこまめな塗り直しが大切です そんなようなことを聞いたことがあるでしょう。 やつらはいつもそうだ。 そう言うんだ。 でも実際そんなに頻繁に塗り直せる? メイクの上からはどうやって? 私もこの世に生を受け、猛暑日の観光地、炎天下の物販列、真夏の野外フェス、ディズニー、スポーツ観戦などなどを経験し、 「メイクの上から日焼け止めを塗り直したい」 とか 「荷物を持って日傘をさして、片手が塞がって立った状態で日焼け止めを塗り直したい」 とか、そういうシーンには何度も直面してきました。 そういう中で出会ってきたアイテムたちを、すこし紹介してみようかと思います。 オタクというほどでもない素人ですし、「年間5兆円をコスメに使う美容オタクの私が1億種類の日焼け止めを試して選んだおすすめアイテム2000選!」みたいな大それたものではないですが、
Amazon Web Services ブログ CCOEを構築するときに避けるべき7つの落とし穴 Cloud Center of Excellence (CCOE)を設立することは、多くの場合、企業のクラウドへの移行を迅速に開始し、ベストプラクティスと長期的な適合性を考慮して移行をガイドするための優れた方法です。 そういった企業は、クラウドのベストプラクティスに関する専門家のチームを編成し、彼らのスキルとクラウドへの情熱を利用して、その企業の残りのクラウドトランスフォーメーションに緊急性を与えています。 AWSでは、CCOEを設立するときに組織がうまくいかない可能性のあるいくつかのやり方を特定しました。 このブログ投稿では、AWSのシニアパートナーソリューションアーキテクトであるNéstor GándaraとEric Linが、これらの落とし穴を回避し、CCOEの可能性を最大限に引き出す方
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、プラットフォームエンジニアの中山です。 Web サイトにはしばしば 3rd-party JavaScript を導入することがあります。たとえば Web 解析ツール、いいねボタンのような SNS 連携機能、広告掲載や効果測定目的のコードスニペットなどは多くの Web サイトで導入されています。 その一方で 3rd-party JavaScript は Web サイトを閲覧するユーザーに対して悪影響を及ぼしかねないため、導入とあわせたリスク対策も必要となります。 そこで、今回は Content Security Policy(以降 CSP)を活用した 3rd-party JavaScript のリスク対策について、ヤフー
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
概要 モダンなウェブアプリケーションを開発していくにあたり、サービスのパフォーマンスを向上したいと思うケースってよくありますよね。 きっとその際に、インメモリデータストアとキャッシュ技術を利用し高速なパフォーマンスを実現することも解決策の1つになると思います。 Memcached や Redis、AWSを利用していればそれらソフトウェアの互換性のあるフルマネージドサービス Amazon ElastiCacheなどを利用しているんじゃないでしょうか。 今回は、そんなキャッシュ技術について、そもそもキャッシュってなんだっけを改めて振り返る記事となっております。 ※本記事は Umer Mansoor さんが執筆されたBrief Overview of Caching and Cache Invalidationの内容を基に翻訳し、加筆、独自解釈したものです。 ※ Umer Mansoor さんか
AWS News Blog AWS Fargate Enables Faster Container Startup using Seekable OCI While developing with containers is becoming an increasingly popular way for deploying and scaling applications, there are still areas where improvements can be made. One of the main issues with scaling containerized applications is the long startup time, especially during scale up when newer instances need to be added.
データドリブンにプロダクトを改善していきたい、とはどんなプロダクトマネージャーでも志すことですが現実には上手く行かないこともあると思います。その時に、参考になる動画を見つけたので紹介します。 Product School のチャンネルで公開されている Webinar: Top 10 Digital Analytics Mistakes by Amplitude's Adam Greco and WillowTree's Jeremy Stern です。登壇者の Adam Greco さんは Amplitude という分析プラットフォームの Product Evangelist 、 Jeremy Stern さんは WillowTree というプロダクトでのデータ活用を支援するコンサルティングサービスの Director of Product Analysis を担当されています。動画の見ど
とにかくポイントが"貯まりやすい"楽天カード 楽天市場の利用でさらにお得!楽天ポイントカードが使えるお店でもポイントをゲット 貯まったポイントは楽天ポイントカードが使えるお店、楽天カードのお支払いはもちろん、楽天グループのサービスでも使える! まずは、マンション購入に興味を持つきっかけとなった出来事について話したいと思います。 それまで住んでいたのは、都内にある家賃8万円の賃貸マンション。学生時代から約10年間住み続けていました。 この賃貸マンションは立地が良く、周辺環境も充実していました。そして、なにより学生時代から10年間一切家賃を値上げしなかったのです。 心情としては、10年間同じ賃貸マンションに住み続けるのは、いい加減飽き飽きしていたのですが、このお得さに絆(ほだ)され、ずるずると付き合い続けた恋人のような存在になってしまい、引っ越しができなかったのです。 そして、2022年の春。
ソフトウェア設計のトレードオフと誤り ―プログラミングの際により良い選択をするには 作者:Tomasz Lelek,Jon SkeetオライリージャパンAmazon ソフトウェア開発経験の最初の段階で「一つの機能には複数の選択肢が有って、メリット・デメリットがそれぞれ有り、それらはトレードオフの関係に有り、容易には決めることができない」という事実を教えてもらえる機会に遭遇できていれば、その人はとても幸運だと思う。 先輩や上司が一方的に、「一つの確かな方法」をただ伝える、みたいな場面(それが必ずしも一般的にはそうとは言えない方法であったとしても)も多いのではないでしょうか。 どんなに設計上の意思決定ができている人でも、その頭の中では「色々な選択肢の中で悩んで、ベストではないかもしれないけど、前の前の課題に対してよりベターな方法」を選んでいる。でもその思考の過程を見せてくれる人はとても少ない。
こんにちは、つくぼし(tsukuboshi0755)です! 現在 DevelopersIO 2023の一環として、YouTube でのビデオセッションが公開されています。 今回私の方では、「AWSとGitHubを用いたパターン別CI/CD構成解説」というタイトルで投稿しました。 概要 AWS基盤でCI/CD構成を作りたいが、どのようなサービスを組み合わせて作るべきだろうか? 特にCI/CDに関する有名なサービスとして、AWSのCodeシリーズとGitHubがあるが、両者の使い分けはどのようにすれば良いだろうか? そんなお悩みをすっきり解決するため、様々なパターンを想定したCI/CD構成をまとめて解説します。 動画 スライド 参考サイト ECS用のCDパイプラインに対する考察 CodeDeploy / GitHub Actions|Rails × CloudFormation ハンズオン A
5 年前、Bill Gates はマイクロソフトの全従業員にメモを送り、より安全なソフトウェアを構築することの重要性を説きました。以来、マイクロソフトの多くの従業員は、担当製品のセキュリティ向上に取り組んできました。その過程で、より安全なソフトウェアを構築するためには何が必要なのかについて、多くの教訓を得ることができました。 セキュリティは静的な領域ではありません。攻撃者が攻撃を仕掛け、防御者がそれを防御し、両者が互いのテクニックについて学ぶなかで、セキュリティは絶えず進化しています。セキュリティはいわば軍備拡大競争です。常に相手よりも優位に立って攻撃を予測するために、私たち防御者は自らの失敗に学び、ユーザーを攻撃から守るためのより良い方法を作り出す必要があります。
毎月や半年に一回といったように、リリースする時期(間隔)を決めて更新するタイプのパッケージがあります。 具体的には、次のtextlintのプリセットルールは1月と7月という形で半年に一回リリースしています。 textlint-ja/textlint-rule-preset-japanese: textlint rule preset for Japanese. textlint-ja/textlint-rule-preset-ja-technical-writing: 技術文書向けのtextlintルールプリセット なぜ、このようにリリースする時期を決めているかというと、これらのパッケージは他のパッケージに依存していて、他のパッケージの更新がそのままメジャーアップデートになりやすい性質があるためです。 そのため、依存を更新してリリースすると、頻繁にメジャーアップデートしないといけなくなりま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く