AWS 初心者向けWebinar Amazon Web Services料金の見積り方法 -料金計算の考え方・見積り方法・お支払方法-Amazon Web Services Japan

設計サンプルで学ぶ、AWS構築の原則 - Webアプリ アーキテクチャのベストプラクティスを理解する AWS入門者に向け、同サービスのエキスパートである、クラスメソッドの八幡豊さんが、Webアプリケーション開発のためのAWS構築の基本を解説します。広範な領域をフォローするAWSですが、広範ゆえに、なにをどのように選ぶべきか……。こんなお悩みを持つ方はぜひご一読を。 クラウドコンピューティングサービス・Amazon Web Services（以下、AWS）は、数多くの高機能なクラウドサービスを簡単に利用できることから、多くの企業が導入しています。AWSの知識を身につけることは、いまやエンジニアにとっての必修科目です。 そのサービス範囲は広範にわたることから、「なにを」「どうやって」使うかのかが重要な知識になってきます。AWSの各サービスのポテンシャルを引き出すためには、それぞれの長所・短所を

このエントリは、随筆風にだらだら書きたいと思います。 （なんとなくそういう気分だからです） このブログの過去エントリを翻ってみると、 はじめてAWSに関するエントリを書いたのが2012年11月。 実際に使い始めたのはもっと前からなので、 AWSを扱い始めてから、もう5年以上過ぎていることになります。 AWSの進化は速く、 この5年の間にいろいろなサービスがリリースされました。 ですが、同時に、基本的な考え方は変わってないなとも思っています。 このエントリでは、 私がAWSでシステム構成を考えるときに気をつけていることを、 （その中でも特にずっと変わっていないこと） 改めてまとめてみたいと思います。 消えて困るものはとにかくS3昔から、JAWS-UG (AWS User Group - Japan)で登壇者は、 自分の好きなAWSのサービスを言う習慣がありますが。 私は好きなサービスの一つは

// スクロールを無効にする $(window).on('touchmove.noScroll', function(e) { e.preventDefault(); }); // スクロール無効を解除する $(window).off('.noScroll'); スマホの独自イベントのtouchmoveイベントを切ってスクロールを止める。 解除したい時はoffする。 イベント名に、.noScrollと名前を付けることで、他の部分でtouchmoveイベントを使っていたとしても、そのtouchmoveイベントまでイベントをoff()してしまうこともなく、.noScrollの名前のイベントのみをoff()することができる。 参考 iphoneでスクロールをさせない処理をする。 特定のエリアのみスクロールを無効にする方法 ドロワーメニューを左側に表示するときにコンテンツ側を固定するときなど //

Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR

大急ぎでRails+Reactのアプリケーションを作るときにやったこと前編 posted at 2020-12-01 05:04:09 +0900 by kinoppyd このエントリは、SmartHR Advent Calender 2020 の1日目です ある日突然、大慌てでWebアプリを作らなくてはいけなくなった 先日、勤め先のSmartHR社である奇妙な福利厚生制度が爆誕し、盛り上がった。この福利厚生制度に関してはちょっとした理由で詳しく書けないので、ぜひSmartHR社にカジュアル面談という形で話を聞きに来て確かめてほしい。 で、その福利厚生制度は、あるルールで複数の従業員の組み合わせが条件を満たしたときに効力を発するものだった。その組み合わせの条件はそんなに大変ではないが、自分から能動的に制度を利用しようと思う人でなければなかなか面倒というか、とにかく誰もかもが「制度を使うため

追記：Homebrew 3.0.0 がリリースされ正式にm1 mac 対応されました brew.sh はじめに この記事は、 Makuake Advent Calendar 2020 24日目の記事です。 M1 Macはサードパーティ製ソフトがまだ追いついてないものがあり、 開発環境の構築をするのが大変です。 後々のことも考えできるだけ今まで通りの手順で 手間と時間をかけない方法で環境構築してみました。 結果的に面倒なのはhomebrew周りだけになりました。 すべてのソフト、パッケージのインストール、起動の成否については詳しく載せてませんが、参考になれば幸いです。 方針 開発に必須でhomebrewなどでお手軽に入らないものは頑張ります なるべくhomebrewでインストールします homebrew自体は頑張ります homebrewのパッケージをインストールするときは --build-f

Apple Silicon (ARM, M1) のmacOSにaarch64とx86_64のhomebrewを共存させるMachomebrewx86-64aarch64M1 ARM版Macで開発を始めている方も多いかと思います。 Rosetta2やDocker Desktop on macのおかげでウェブ開発において全く開発ができないということはないんじゃないかと思います。 一方で、Dockerを使わずにネイティブで開発するにはいくつかの問題もまだ残っています。 例えば、homebrewでpythonのいくつかのバージョンがインストールできないとか、Rustがインストールできないとか、そういう問題にぶつかることがあるでしょう。 そこで、本記事ではhomebrewのx86_64 (intel) 版と、aarch64 (ARM) 版を共存させ、どちらを使うか選べるようにします。 Homebre

こんにちは。 今年の年始からジョインした遠藤です。 さて、入社したところ会社支給のMacBook ProがM1チップのものでした。 はい、現状は開発環境で苦労するとか色々噂を聞くやつです。 実際に試したのですが、 現状の開発環境構築スクリプト、手順書が一切使えない VitualBox, Vagrantは利用不可 Dockerは利用可能ではあるが、一部イメージが対応されてない 古いパッケージは動かす手段がない などなど、通常ではぶつからない問題にぶつかります。 食べチョクでは、 Ruby Node.js MySQL Redis ElasticSearch Kibana を利用しています。 この辺りをメインに話つつ、Intel版とこんな風に違うのかっていう辺りの雰囲気を感じ取っていただければと思います。 どこに開発環境を構築するか まず、どこで開発環境を構築するかを考えてみたいと思います。 ロ

言いたいこと webpackをあまり知らない人がwebpackerを用いることで簡単に導入できるけど以下のことはちゃんと知っておいてほしかったり、考えてほしい。（切実） ビルドはRubyからコマンド実行してるけど、実際に発行しているnpm scriptはwebpack(-dev-sever) --config config/webpack/(development|test|production).jsなんで覚えておけ。 デフォルトでmultiple entryになっているのでSplitChunksPluginかCommonsChunkPluginの設定はとりあえず入れておけ。 本当にwebpackerは必要ですか？時期が来たら捨てろ。 webpackerの落とし穴 昨今では当たり前となっているwebpackの導入をwebpackをあまり理解していない人が簡単に入れれるという特徴がある。こ

私は長年に渡って、Ruby on Railsアプリでさまざまなセキュリティ問題を発見・修正する機会が何度もありました。この経験を元に、皆さんのRailsアプリをさらにセキュアにする方法をご紹介いたします。ここでご紹介するセキュリティ問題が皆さまのアプリで発生していなければ幸いです。 🔗 1. 「セッションに期限を設定していない」問題 🔗 セキュリティ問題の解説 「Railsセキュリティガイド」には以下のように記載されています。 セッションを無期限にすると、攻撃される機会を増やしてしまいます (クロスサイトリクエストフォージェリ (CSRF)、セッションハイジャック、セッション固定など)。 ユーザーエクスペリエンスを考慮すれば（ユーザーはずっとサインインしたままになるので、アプリを開くたびにサインインしなくても済む）、無期限セッションの方が正しいアプローチと思われそうですが、無期限セッシ

この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut

nginxでは、 設定ファイル(/etc/nginx/nginx.conf)にrewrite文を書くだけで URLをリダイレクトすることができます。 rewriteの使い方 rewirteを使用するときはこのような書式で設定し、 server, location, ifディレクティブ内に設定します。 rewrite regex replacement [flag]; regex : 正規表現でのマッチパターン※Apacheと違いURIのパラメータは「/」から始まります。 replacement : マッチパターンに一致した場合の変換パターン flag : リダイレクトフラグ 最後のリダイレクトフラグの指定によって、HTTPのステータスコードを変えることができます。指定できるのは下記のものとなっています。 ▼last rewriteディレクティブの処理を停止し、書き換えられたURIに対して最

久々に、「ザ・プロフィット 利益はどのようにして生まれるのか 」を読み返してみた。 この本は、ビジネスの仕組みやモデルを、どこから利益が生まれるかというポイントからモデル化して整理している本だ。最初読んだ時は、中途半端な物語形式に嫌気が刺したが、何度か読み返すたびに、「利益」というところに着目して、ビジネスを見てみるということが、物凄い発見だということがよくわかるようになった。 本の中では23の利益モデルが示されている。中には、それが「モデルなの？」ってツッコミ入れたくなるようなものもいくつか含まれていたり、このモデルとこのモデルのどこが違うのか、よーわかん、みたいなものもあるが、ひとまず簡単にポイントだけそれぞれのモデルについてまとめておこうと思う。世の中のビジネスは、それぞれどれか１つのモデルに当てはまるというよりは、複数のモデルの組み合わせによって成立しているもののほうが多いかもしれ

概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Lifecycle of a Rails Request 原文公開日: 2019/05/02 著者: Godfrey Chan サイト: Skylight 日本語タイトルは内容に即したものにしました。画像は元記事の引用です。 2019/10/03: 初版公開 2022/08/02: 更新 参考 以下のサイトで、Railsのリクエストの全ライフサイクルをビジュアル表示で追うことができます。本記事と合わせて参照することで理解が進むと思います。 サイト: Rails Trace rails-trace.chriszetter.comより 本記事は、私達がRailsConf 2019で行ったスピーチのまとめです。スライドはこちらでご覧いただけます。 エディタでコントローラのファイルを開き、アクションメソッドにRubyコードを少々書

リモートワークしてるエンジニアなので、座りっぱなし作業環境を改善したく、DIYタイプの電動昇降デスクを購入してみた。 今回買ったのは FlexiSpot E3B で 5万円ぐらい。電動昇降デスクの中ではコスパがいいほう。 購入ツイートしたら、興味ある人が多かったようなので、ちゃんとレビューしてみた。 導入前の机 最適な机の高さ 電動昇降デスクの選定 天板の選定 FlexiSpotの組み立て 使ってみた感想 導入前の机 導入前はIKEAで購入した机を使ってた。雑だけどヤスリがけして、オイル塗ったんで愛着がある。 電動昇降デスク導入前 天板: IKEA - GERTON イェルトン（送料含めて2万円ぐらい）*1 脚: IKEA - ADILS オディリス （4本で1000円） 良かったところ ある程度の幅・奥行きが確保されている（155x75） 木製の天板がいい 高価すぎない（組み立てに電動ド

※本記事はコロナ以前の2019年に書かれたものです。コロナ禍で在宅需要が高まった2021年初頭のいま、天板、電動昇降脚、ワトコオイルのすべての材料において、在庫が逼迫している状況のようです。なるべく手戻りのない作業となるよう、本記事が誰かのデスク製作の参考になれば幸いです。 この度自宅に念願の書斎スペースを手に入れたので、現時点で理想とする作業環境を整えるべく、作業用デスクを自作した。なんとこの机、電動昇降機能付きである。 ボタン操作でヌルヌル電動昇降 構想から作り方までをまとめてみる。天板はタモ材にワトコオイルでフィニッシュなので、その作例を知りたい方にも参考になれば幸いです。 私が机に求めたこと 材料 電動昇降脚 天板 タモ材 x ワトコオイル（ナチュラル）の塗装 （2021年2月追記）ヒノキ材 x ワトコオイル（ダークウォルナット）の塗装 ケーブルトレイ まとめ 私が机に求めたこと