AWS Lambda CI/CD俺的ベストプラクティス - くりにっき
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
【新定番】レスポンシブデザインのブレイクポイントの正解はこれだった[2019最新版] - webのあれこれ
↓↓↓最新の2021年版を作成しましたのでこちらもご覧ください。↓↓↓ hashimotosan.hatenablog.jp PDFはこちらからどうぞ[508KB] 2019年Pixel 3aやGalaxy S10など一通り新機種が発表されたので、2019年改めてブレイクポイントについて考えてみました（3年ぶり！）。 3年経ってほとんどのサイトがレスポンシブデザインになって、ブレイクポイントを少なく効率よく設定していく方向になっているのだと思います 前回、ブレイクポイントの設定はフレイムワークも参考に考えていましたが、 改めて考えてみると、モバイルファーストの観点からも640px/1024pxではないのではないかと感じました。 以下が3年前の前回の記事です。 いくつかブレイクポイントを調べましたが、 だいたい以下のような分け方が多かったです。 640px/1024px 480px/896x
![【新定番】レスポンシブデザインのブレイクポイントの正解はこれだった[2019最新版] - webのあれこれ](https://cdn-ak-scissors.b.st-hatena.com/image/square/c569bf6868b0e2cd70822921c201208292c30537/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhashimotoblog%2F20190528%2F20190528165147.png)
フロントエンドのつくりかた
フロントエンドの特定技術について語る解説は多くあれど、そもそもフロントエンドのつくりかたについて語った解説は多くないのではないでしょうか。 フロントエンドという大きな領域ですので恐れ多くもありますが、私が GUI プログラミングに携わった経験をもとにお話した内容のスライドとその補足をここでしたいと考えます。 スライド スライドのページ数は多いですが、差分がほとんどですので、それほど構える必要はないです（カーソルキーに負担がかかるという問題を除いて）。 補足解説 大きなテーマごとに補足をしていきます。 スライドで取り上げているテーマは次の４つです。 GUI アーキテクチャパターン データの同期 エラーハンドリング コンポーネント構造 「GUI アーキテクチャパターン」はいわゆる MVC や MVP といわれるものがどういったものかを解説する章です。 「データの同期」は画面と実際のデータが離れ
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
何故アウトプットが大事なのか - Pepabo Tech Portal
執行役員 VP of Engineering 兼技術部長の @hsbt です。 GMO ペパボ株式会社(以下、ペパボ)では一年に二回、半期ごとにエンジニアが実績の資料を作成し、資料に基づいて評価を行う制度があります。評価資料では、ペパボが大切にしている三つのことである「なかよくすること」「ファンを増やすこと」「アウトプットすること」それぞれについて、エンジニアとしてどうコミットしたかというのを述べる必要があります。 2019 年上期(1-6月)の評価を @hsbt が行った部署のメンバーに向けて、何故エンジニアにとってアウトプットが大事なのか、ということを述べた文章を社内で共有しました。今回はその文章をアレンジして公開したいと思います。 今回の評価で、気になったこととしては、 「OSS は開発していません、発表もしていなかったのでアウトプットはBです」という自己評価が散見されたことです。一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
