コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
React(+Redux)+gRPCで実現するクリーンアーキテクチャ＋マイクロサービス構成
はじめに 設計がしっかりしていないまま開発をしてしまうとビジネスロジックとライブラリが密結合となりがちです。 密結合度が高いほど修正が困難となり、継続的な開発の難易度が上がっていきます。（技術的負債） またプロジェクトが大きくなってくると扱うデータ量も多くなり処理速度もデータ量に比例するため、計算量オーダーの影響を受けます。 プロジェクトのそれぞれの機能に対して 1. 再利用可能 2. テストしやすい 3. 機能追加しやすい 4. ビジネスロジックとライブラリ、REST API（+マスターデータ）を分離できる となっていれば継続的な開発がしやすいです。 最近ではクライアントサイドではクリーンアーキテクチャ、Atomic Design、バックエンドではマイクロサービス化という設計方法があります。 この設計が良いと感じているのはビジネスロジックと機能の責務を分離し、 ライブラリとREST AP
ノンデザイナーでもイケてるLPを作成する方法 - Qiita
はじめに イケてるは誇張かもしれませんが社内にデザイナーがいなく、 エンジニアにランディングページを作ってと振られたときのケースを想定して ノンデザイナーでも体系的にCSSコーディングすることでそれっぽいランディングページを作成できることを目的としてます。 デザインは一朝一夕でできるものではなく、ブランディングに関わる部分の画像に関しては、商材の撮影やPhotoShopやIllustratorで専用のアイコンやロゴ画像を別途制作する必要があります。 本格的に作成する場合はやはり本職のデザイナーさんに依頼した方が良いでしょう。 （それっぽいといったのは今回はそれらのブランディングに関わる画像の作成を省いて、素材画像やCSSでごまかしているからです。） 今回はCSS Designerという仮想CSSエディターの商材を想定してランディングページを作成しました。 作ったページ全体のサンプルはこちら
AWS料金早見表
サーバレスアーキテクチャ構成にしたときに 実際のところ、どれくらいの料金になるのか気になったので算出してみようと思います。 (あくまでシミュレーションしたものでAWS側で値段や計算方法が変わったりするため、責任は負いかねますので導入する際は自己責任でお願いします。) AWSのどこにどれくらいの料金がかかっているのか知ることは大事だと思ったのですが、トータルだとなかなかまとまってなかったのでまとめてみました。 間違ってたらご指摘いただけると助かります。 サーバレスアーキテクチャって何？って方はこちら参照してください 世界に先駆けてAWSサーバレスアーキテクチャでユーザ認証とAPI認可の実装をしてみた AWSサーバレスアーキテクチャでCloudFrontからWAFをかけてAPI Gatewayを呼ぶ Lambda+RDSはアンチパターン 全部教えます！ サーバレスアプリのアンチパターン とチュ
世界に先駆けてAWSサーバレスアーキテクチャでユーザ認証とAPI認可の実装をしてみた - Qiita
下記GitHubにサンプルをアップロードしました。 https://github.com/teradonburi/CognitoUserAuthApiApproval サーバレスアーキテクチャとは サーバを運用する場合、大まかにわけて次の３つの選択肢が存在すると思います。 1. 自社でサーバを管理するケース（オンプレミス型） 2. クラウドサービスでサーバを管理してもらうケース（IaaSクラウド型） 3. クラウド上でビジネスロジックのみ記述して、必要な時だけサーバを稼働させ、スケールもクラウドサービスに任せるケース（サーバレス型） クラウドに依存するほど自前でカスタマイズできる自由度が減る代わりにサーバ運用コストが下がります。 ざっくり言ってしまうとオンプレのサーバは運用が大変なのとコストが高くて自社で持ちたくないのでクラウドのサーバを使いたい。クラウド型だと常時稼働していると運用コスト
xcodeでAutoLayoutでレスポンシブデザイン - Qiita
xcode6になって 対応しなければならない画面サイズ（解像度の比率の種類）が５種類に増えました （iPhone4S,iPhone5(S),iPhone6(S),iPhone6 Plus(S)、iPad） デバイスの画面サイズの種類が増えたことで StoryboardやxibでAutoLayoutを使わないやり方でやると １つのレイアウトファイルではマルチデバイスのサイズに 対応ができなくなってしまっています 自分は今までAutoLayoutを使って来なかったので苦戦したので 他の困っている人向けに備忘録として残しておきます XCode7以降でも基本的には同じです。 長いです まず、AutoLayoutを使わない方法もあります ViewControllerを選択して ・Use Auto Layout ・Use Size Classes のデフォルトチェックを外します。 すると、従来通りAu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
