こんにちはecbeingでアーキテクトをやっている宮原です。
皆さんデザインパターンについてはどのくらいご存知でしょうか?
「かなり自信がある」という方も「名前は聞いたことあるけど・・・」という方もいると思います。
今日はそんなデザインパターンの中から「Factory Method」を取り上げます。
続きを読むこんにちはecbeingでアーキテクトをやっている宮原です。
皆さんデザインパターンについてはどのくらいご存知でしょうか?
「かなり自信がある」という方も「名前は聞いたことあるけど・・・」という方もいると思います。
今日はそんなデザインパターンの中から「Factory Method」を取り上げます。
続きを読む
こんにちは。ecbeing金澤です。
普段はReviCoや他のプロダクトの開発リーダーをやりつつ、管理職としてチームのマネジメントもやったりしています。
プロダクト開発統括部では、個人の面談に1on1を取り入れています。
1on1はコーチングの場と言われており、基本的にはメンティー(部下)が喋り、メンター(上司)はその内容に対してフィードバックをする。
という流れが理想なのですが、自分が普段どのくらい喋っているかというのは、なかなか自分では分からないもの。
「見えない問題は解決できない」ので、どうにか可視化できないか考えていたところ
Amazon Transcribeを使えば計測できそう、ということに辿り着きました。
binフォルダは保持されるけどセッションが切れるごとにTerraFormバージョンが元に戻るので・・・ 初回実行時 mkdir bin cd bin wget https://releases.hashicorp.com/terraform/0.13.3/terraform_0.13.3_linux_amd64.zip unzip terraform_0.13.3_linux_amd64.zip $env:PATH="$HOME/bin/:"+$env:PATH terraform -version 2回目以降 cd bin unzip terraform_0.13.3_linux_amd64.zip $env:PATH="$HOME/bin/:"+$env:PATH terraform -version・CloudShellのストレージは各アカウント容量が決まっている(5GBと説明があるが体感1GBくらい)のでTerraForm安定版のダウンロードとtfファイルくらいしか置くのをやめよう!
~ecbeingでは、新しいことに楽しんでチャレンジできるエンジニアを大募集中です!~
careers.ecbeing.tech
ブンブンHello World.
どうも開発です。
最近はNoSQLというものがだいぶメジャーになってきましたね。
プロダクト開発統括部でも過去にAzure Cosmos DBを用いたPoCを行ったことがあり、その可能性にはとても驚かされました。
そのCosmos DBは最近ではオンラインセミナーなども開催されており、かなりホットな内容であると感じています。
そこで今回は、PoCの経験も踏まえてCosmos DBについて語っていきたいと思います!
今回は、「NoSQLとは?」「Cosmos DBとは?」といったことに焦点を当てて解説したいと思います。
こんにちは、アーキテクトの小林です。
前回の記事で「データベースから設定情報を読み込む独自の ConfigurationProvider を作成して紹介してみたい」と書いておきながらも、コロナの影響やプロジェクトに忙殺されてしまったこともありまして、すっかり間が空いてしまいました。
今回は応用編となっていまして、ややディープなネタになっております。.NET Core の設定情報の基本から知りたい方は、以下の記事から先にお読みいただければと思います。
blog.ecbeing.tech blog.ecbeing.tech
続きを読むこんにちはecbeingでアーキテクトをやっている宮原です。
皆さんデザインパターンについてはどのくらいご存知でしょうか?
「かなり自信がある」という方も「名前は聞いたことあるけど・・・」という方もいると思います。
今日はそんなデザインパターンの中から「Facade」と「Mediator」を取り上げます。
ある程度デザインパターンに詳しい方なら、「FacadeとMediatorは似ている」というタイトルを読んで『あれ、そうだったっけ?』となるかもしれません。
この考え方は自分が発想したものではありません。
下記に紹介する書籍「アジャイルソフトウェア開発の奥義(以下「アジャイル奥義本」)」の第15章に書かれている内容なのです。
www.amazon.co.jp
『15章:FacadeパターンとMediatorパターン』
この章で取り上げる2つのパターンの目的は共通して言える。
どちらのパターンも、ある種の方針*1をオブジェクトに強制する。
Facadeパターンは上から方針を強制し、Mediatorパターンは下から方針を強制する。Facadeパターンは視覚的にとらえることができる制約的な方法であるのに対し、Mediatorパターンは視覚的にとらえることはできない方法で方針を強制する。
(アジャイルソフトウェア開発の奥義 p.223 より)
この抜粋した文章を読んで、『うんまあそうだよね』という感想をもった方。
申し訳ありません。
当記事はこの抜粋文章をこのあと延々と説明をするだけの記事です。
得るものはないのでそっ閉じして下さい。
それ以外の『日本語は分かるが意味がわからん』という感想を持った方、あなた達こそがこの記事がターゲットとする読者の方々です。
是非最後までお付き合い下さい。
*1:ここで使われる「方針」とは、「DBをオープンしたらクローズする」「入出力の文字コードはUTF-8を使用する」などプログラム上でのルールのことです。
はじめましてorこんにちは!
ecbeing2年目、R&D部門所属のいかちゃんです。
これまでは、Dockerの記事やスクラムに関する所感記事、JavaScriptライブラリに関する記事を書きました。
blog.ecbeing.tech
そして今回…というより本シリーズでは、泣く子も黙る『Clean Architecture』本を参考に…。
https://www.amazon.co.jp/dp/B07FSBHS2Vwww.amazon.co.jp
ソフトウェア設計の5つの原則として名高い「SOLID(ソリッド)原則」についてまとめていこうかと!
…既にSOLID原則をご存じの方は、「すごく難しい話題をまとめるんだな」と察していただけましたかね…?
SOLID原則は「原則」と名が付いているように、非常に概念的な話が多く。
※具体的な実装の話ではなく、もっと上位の概念の話が多い…という感じです
実は筆者は新卒のころにSOLID原則について学ぶ機会があったのですが…。
趣味でプログラミングしてた程度の知識しか持ってなかったからか、さっぱり身につかず。
そんな状態でSOLID原則を見ても、2週間後には「SOLIDのSってなんだっけ…」となるくらいに頭から消え去っちゃいました。
しかし、そんな筆者も今年で2年目(とちょっと)。
様々なプロダクトにプログラマとして関わってきた今の筆者なら、以前よりもSOLID原則の事が分かるようになる…と淡い希望を抱き、まとめてみようと決心した次第です。
後、社内の凄腕アーキテクトの青木さん(めっちゃすごい)が、こんなことを話してくれ…。
※筆者の要約なので、これをまんま話したわけではないです
世の中の様々なアーキテクチャを学ぶと、新技術を学ぶときに「その技術がどんなアーキテクチャを採用したか」が分かるようになる。
例えばMVVMを知っていれば、Vue.js製のプロダクトを見た時に「画面上へどんなデータが出力されるのか」はViewをたどれば見つける事が出来る。
「どこのフォルダやファイルにどの様な処理が書いているか」が、その技術を知らなくても推測できるようになるのだ。(ここ重要)
十分な知識と良く練られた良質なソフトウェアであれば、僅かなコードを見るだけで何のアーキテクチャを採用したのかが分かるようになり…。
そこまでのレベルにたどり着くと、新技術のinput速度が圧倒的に早くなる。
日進月歩が激しいこの業界で、爆速input力を身につけられればエンジニアとしてものすんごい強みになりそうだなと思い。
筆者もそうなりたい!と強く思ったというのも動機です。
((というかこっちが本命
その取っ掛かりにまず、SOLID原則を学んで行こうかなと。
…序章が長くなってしまいました…。
早速本題、「SOLID原則をまとめてみた」に入っていきましょう!