2022年度リクルート エンジニアコース新人研修の講義資料です
The Twelve-Factor App (以降、「12FA」といいます) とは、Heroku の共同創設者である Adam Wiggins 氏が提唱した、優れたソフトウェアを開発するための方法論です。 2011 年頃に提唱されてからすでに 10 年以上経過していますが、クラウド上の分散アーキテクチャとしてソフトウェアを開発する上で、12FA はアプリケーションの移植性を最大化し、継続的なデプロイを可能とし、レジリエンスや堅牢性を高めるための優れたプラクティスとして、今でも多くの開発者に親しまれています。 2016 年に開催された AWS re:Invent では、Amazon CTO の Werner Vogels 氏による キーノートスピーチ においても、ソフトウェア開発の変革に必要かつクラウドの利点を最大化するためのベストプラクティスとして 12FA が紹介されています。
メルペイでプロダクトマネージャをしてます、さとじゅんです。 メルペイでto B向けプロダクトの開発をしてます。なので、主にto B向けプロダクトについての話になります。 たまに思うこと突然ですがPMは新しい機能を作る時は仕様書を書くことが多いですよね。 PRD(プロダクト要求仕様書)とかですね。 「Why」とか「What」とか「How」とか書きますよね。 それでリリースして運用していくと思うのですが、運用中にいろんな課題をこなしていくうちにひとつの事に気づきます。 「もう少しビジネスとシステムとオペレーションがひとつのつながりで理解できる資料が欲しいな」と。 to C向けのプロダクトに比べ、to B向けのプロダクトにはセールスやオペレーションのチームなど1つのプロダクトに関わる人が多くなる特徴があると思います。 PLGという考え方もあると思いますが、だいたいのto B向けプロダクトがto
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1~2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文: www.industrialempathy.com 関連書籍: Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安:11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
Working with Json JSON basics JSON with HTTP JSON Reads/Writes/Format Combinators JSON automated mapping JSON Transformers Main concepts Section introduction Configuration API HTTP programming Asynchronous HTTP programming The Twirl template engine Form submission and validation Working with Json Working with XML Handling file upload Accessing an SQL database Using the Cache Calling REST APIs with
はじめに お久しぶりです。2021年末以来の投稿になります。 先日、とある金融情報サービス系の会社に所属する知り合いの方から、「AWS × アプリケーション開発者 × コンテナ に関連したトピックで社内向け勉強会にて講演してくれないか?」とご相談をいただき、「コンテナ・サーバレスがもたらす世界と開発者がAWS上で取り組むべきこと」というタイトルでお話させていただきました。 その会社様は、これからまさにシステムをAWS上のコンテナ技術で刷新していく取り組みを推進されており、アプリケーション開発者に刺激を与えたり知見を獲得する上でも、ぜひお願いしたいとのことで、僭越ながらお話させていただきました。 ただ、今回の登壇内容は、勉強会の参加者のみならずその他の幅広いエンジニアの方々にも役立つのかな、との想いもありました。 そこで、先方に許可をいただき、多少デフォルメして資料を公開することにしました。
Scalaについて勉強した時のメモ(その4)です。for式の扱い方について。 ※ 元々はmarkdownで書いていたテキストの転載。 for { a <- abcDao.find(id) b <- abcDao.find(a) } yeild f(a, b) Scalaのfor文はJavaなどと同様に、foreach文の役割を持つ。Haskellのdo記法に由来するという話をどこかで読んだ気がするが出典は不明。ただし、yield節を追加することで、for-yield式(for内包記法)となり、map/flatMap/filter(With)を使ったジェネレータとなる。基本的にはListのジェネレータを他のデータ型(OptionやFuture)向けに一般化したものとして考えるのが筋のような気がする (が実際のところは分からない)。map/flatMap/withFilter等が定義されたデー
シンプラル法律事務所 〒530-0047 大阪市北区西天満2丁目6番8号 堂島ビルヂング823号室TEL(06)6363-1860
15 9 11 1 5 1.1 5 1.2 5 1.3 7 1.4 8 1.5 8 2 11 2.1 11 2.2 11 2.3 12 2.4 14 2.5 15 2.6 18 3 21 3.1 21 3.2 21 3.2.1 21 3.2.2 23 3.3 24 3.3.1 24 3.3.2 25 3.3.3 26 3.4 27 3.4.1 27 3.4.2 28 3.4.3 28 3.4.4 29 4 UML 30 4.1 30 4.2 30 4.2.1 30 4.2.2 31 4.3 32 4.3.1 32 4.3.2 32 4.3.3 33 4.3.4 34 4.3.5 34 1 4.4 UML 35 4.4.1 35 4.4.2 UML 36 4.5 36 4.5.1 37 4.5.2 38 5 39 5.1 39 5.2 40 5.3 Demarco 41 5.4 42 5.5
こんにちは。株式会社プラハCEOの松原です。 弊社は主にスタートアップの新規事業に特化してデザイン・開発をするものづくり集団です。 最近改めて「プラハでエンジニアとして働く上で最低限必要なスキルって何よ?」という話になったのでリスト化してみました。 ついでにそれらにまつわる知識をうまくまとめてくれている情報源を追記しておくので、何かしらの学習素材として使っていただけると幸いです。 前提 前提として弊社が相手にしているスタートアップや新規事業の開発においては とにかく速く仮説検証し続けること が重要なので、継続的に機能改修しやすい柔らかなソフトウェアを作ることに重点が置かれています。他の事業であれば他のスキルが重視されますし、これらが新規事業の開発において絶対の指針だと言うつもりは全くないので 「あ〜新規事業の開発を主に手掛けているプラハっていう特定の会社(N=1)ではこんなスキルが求められ
この講義は、はじめてディジタル論理回路を学ぶ人を対象とし、回路の理解と設計の基本を学ぶことを目的とする。具体的な流れは、2進数の算法、論理演算、組合せ回路の設計法と代表的な組合せ回路、フリップフロップ、順序回路の設計法と代表的な順序回路、論理回路の実現、メモリ、ディジタル回路からコンピュータへ、という具合である。この授業の特徴は、(1)回路設計などのわかりやすい実例を多数示すことで受講者の理解を容易にした点、(2)クワイン・マクラスキー法などを入れて一般性を高めた点、(3)適切なレベルの演習問題を出し、全問題の解答を示す点、(4)例示した回路を組み合わせることによってコンピュータの基本をボトムアップ的にわかるようにした点、などである。
坂井修一『コンピュータアーキテクチャ』(コロナ社、電子情報レクチャーシリーズC-9) 坂井修一『実践 コンピュータアーキテクチャ』(コロナ社) 教科書通りやります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く