駆け出しエンジニア振り返りログ（梅雨入り）
一週間で印象に残った文献を引用してまとめることで進捗した気分に浸っている駆け出しエンジニア見習いペーペーのスバルです。
梅雨入りしたっぽいですね。空調完備の家に引っ越して良かった、しみじみと。
ちょっと前まで築50年の家に住んでいたんです。マッチョ経理見習いと共に。
冬の平均気温は10度くらいの家でした。当然湿度管理もできない。風呂場に鮮明な赤色のカビが生えているような家です。
ゾッとします。エアコン無しで梅雨を迎えていたかと思うと。
最近は友達に勧められて「本日は、お日柄もよく。」を読みました。感動。スピーチ上手くなりたい。
ではまた。
サブドメインに正規表現を使う
サブドメインに使えない文字列を正規表現で制限をかける
マルチテナントサービスを運営する時にサブドメインが使われることがあります。
サブドメインに使用できない文字が存在するため、バリデーションをかけるような正規表現が求められます。
正規表現の様々な技を駆使してサブドメインに使用することを許されていない文字にバリデーションをかけました。
具体的に下記のような制約を持った文字列にバリデーションをかけることを想定します。
- [ ] 「"-"が連続で使われていない」
- [ ] 「先頭で"-".””_”大文字が使われていない」
- [ ] 「1文字以上32文字以下である」
- [ ] 「.を不許可」
- [ ] 「_を不許可」
- [ ] 「半角英数字,-は使用可能」
- [ ] 「admin www ftp mail pop smtpを使っていない」
特に、「"-"が連続で使われていない」という記述を表現することに苦戦しました。
最終的に、否定先読みという技を使用して強引に表現。
// ダブルハイフンを含まない文字列の表現
(?!.*--)
これでサブドメインに許されていない文字にActiveRecordの力を借りながらバリデーションをかけることができました。
validates :name, presence: true, exclusion: { in: %w[admin www ftp mail pop smtp] },
format: { with: /\\A[^-._A-Z](?!.*--)[a-z0-9\\-]{,31}\\z/ }
【駆け出しエンジニア必見】タスクの進め方
タスクの進め方
「分からないことが分からないから質問することができない」という事態を防ぐために、テンプレを埋めていくことが大事。独り言を発しながらテンプレを埋めることでテディベア効果も望める。
質問したい内容
実現したい内容
発生しているエラー
試したこと
その他聞きたいこと
報連相をする時の目安
1時間程度詰まってやることが明確にならない場合、上記の質問テンプレートを埋め始める。
決められた期日までに終わらなそうだった場合、期日のz前日には進捗、完成の目処を伝える
。
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方 - Qiita
issueをもらってから開発を進める段取り
いっちゃん難しい。これができたら苦労しない。
rubyで使うコンポーネント化に役立つgem 1選
今回はrubyのtrailbrazerというgemについて調べるうちに学んだことに関する記事です。
世の中いろいろな依存が存在しますよね。
恋愛依存、薬物依存、糖質依存
バランスを意識したい、極力依存しすぎることは避けたいです。
というのも、業務をしていると、「他に依存しすぎている」「疎結合させたい」といった言葉が出てきました。
コンポーネント化？疎結合？使い回し？依存度？といった用語をよく分からなかったのでまとめていき、最後にrubyでクラスをコンポーネント化させるgemをまとめていきたいと思います。
疎結合とは
疎結合とは、細分化された個々のコンポーネント同士の結びつきが比較的緩やかで、独立性が強い状態のことである。 疎結合では、個々のコンポーネント同士は相互に連携しているが、相互に依存している余地が少ない。
疎結合とは、相互に依存している余地が少ないことを指しているんですね。
クラスAの振る舞いを変更したときにクラスBに対する影響が少ないと、クラスAはクラスBに対して疎結合であるというということでしょうか。
コンポーネント化とは
使い回しやすいように要素を疎結合化させること。
もともとComponent(コンポーネント)は日本語で部品を指しているみたいです。
なので、コンポーネント化とは、一つのアプリケーションを作り上げていく中で必要な素材を小さい部品レベルに落とし込むイメージでしょうか。
それぞれの部品が他の部品に対しての依存度が低ければ、一つのアプリケーションの中で複数のプロダクトを作るときに使い回しやすくなりますし。
rubyのように責務を明らかにしてアプリの見通しをよくするような言語とコンポーネント化という概念は親和性が高いですね。
例えば、カーファクトリーというアプリケーションを作ることを想定してみます。
さらにカーファクトリーでは四輪車のみを作っていて、車タイプA、車タイプB、車タイプCという種類を作っているとする。
このとき、車タイプAで使っていた部品、ボンネットとかにしておく、を車タイプBにも使いまわしたいと考えました。しかし、その部品は車タイプAのためだけに作られた一枚板だったので、車タイプBに転用できなかった。
この場合、ボンネットのコンポーネント化が進んでいないと言えます。
ボンネットは〇〇でできていて、さらに〇〇は✖️✖︎でできている、といったように、小さな部品に落としこんでおけば、車Bにも使いまわせたかもしれません。
React,Vueなどを触っていてコンポーネント化はフロントエンドだけのものだと思っていました。
gem Trailbraizer
Tailblazer is an architectural style that provides a modern approach to implementing business logic.
ビジネスロジック層に対してモダンなアプローチを加える設計スタイルを指している。
下記のようにValidationやPolicyなど、データのやり取りを行う記述をステートレスにできることがTrailbrazerのコア部分だそうです。
class Song::Create < Trailblazer::Operation
step Model( Song, :new )
step Policy::Pundit( Application::Policy, :create? )
step Contract::Build( constant: Song::Contract::Create )
step Contract::Validate()
step Contract::Persist()
fail Notifier::DBError
pass :update_song_count!def update_song_count!(ctx, current_user:, **)
current_user.increment_song_counter
end
end
- ビジネスロジック層とは
Web アプリケーションなどのプログラムの構成を考えるとき、一番基本になる3層のうちの一つを指す。
下記の３層アーキテクチャーのうちの一つを指しているそうです。
- プレゼンテーション層 (またはユーザインターフェース層)
- ビジネスロジック層 (またはアプリケーション層)
- データアクセス層
プレゼンテーション層: ユーザーが実際に触れる部分。フロントエンド。
ビジネスロジック層: データを取り扱う部分。バックエンド。
データアクセス層: DBとやり取りをする層。
Cellとは
RubyとRailsにViewComponentを追加させるgemのこと。上記のTrailbrazerのうちの一つです。
使い方
どこからでも呼び出すことができ、下記のようにしてviewから呼び出すことができるみたいです。
- # app/views/comments/index.html.haml
%h1 Comments
@comments.each do |comment|
= concept("comment/cell", comment) #=> Comment::Cell.new(comment).show
Comment::Cell をインスタンス化してeachを使ってデータを表示させていますね。
下記記述はComment::Cell.new(comment).showをしていることと同じみたいです。
ここで使っているconcept()とは、cellを表示させるためのhelperなので、Comment::Cellクラスのshowアクションに書かれた記述がユーザーから見えます。（今回だとThis: #{mode;.inspect})
concept("comment/cell", comment)
Comment::Cellは下記のような構成でクラス化されています
class Comment::Cell < Cell::ViewModel
def show
"This: #{model.inspect}"
end
end
アクションの中でrenderのみを記述すると、アクション名。html .(slim ,erb ,haml)を丸々表示させることができるそうです。
下記の例だと、showアクションだからapp/concepts/comment/views/show.ham l が表示されます。
class Comment::Cell < Cell::ViewModel
def show
render # renders app/concepts/comment/views/show.haml
end
end
Using #render without any arguments will parse and interpolate the app/concepts/comment/views/show.haml
decorator
modelやcontrollerに影響を与えずviewへの表示内容を変えることのできるgem。
viewとmodelの間であるpresenter層を担っている。
下記のような形でメソッドをdecoratorでメソッドを定義することができるようです。
# app/decorators/article_decorator.rb
class ArticleDecorator < Draper::Decorator
delegate_all
def publication_status
if published?
"Published at #{published_at}"
else
"Unpublished"
end
end
def published_at
object.published_at.strftime("%A, %B %e")
end
end
viewでは.の後にdecorateを付けることでdecoratorで定義したメソッドを使うことができます。
articles.show.html.erb
<%= Article.new(Article.find(params[:id]).decorate%>
疎結合な関係って人間関係においては寂しい気もしますが、プログラムを書く上では嬉しいのですね。
参考
https://qiita.com/os1ma/items/7a229585ebdd8b7d86c2#アプリケーションアーキテクチャの基本は-3-層
学びのある毎日を過ごすために
同居人と築50年の家でしていた同棲生活が解消し、築2年のマンションの１階と２階で住むようになったエンジニア見習い昴です。
現在、業務委託という形で１日約５時間程、内定先の会社で業務に携わらせていただいています。
これがまた学習する内容が多すぎて頭がパンクしそうなんですね。笑
なので、半年前から初めて1月にパッタリとやめてしまったアウトプットドリブンな学習生活を始めたいと思います。
もちろん社内で使っているコードは流用しないのでご安心ください。
RUNTEQ時代の時は毎日投稿を８月の末から開始し、１月の初旬までで約135記事を投稿していました。（目的と手段を間違えていたなと反省しております。笑)
こうやって勉強する仕組みを作っていかないとだらけて弱い人間なので、暖かい目で成長を見守っていただければと思います。（マサカリは大募集でございます。）
最近見つけたライフハックを一個。
私ロフトのある1Rに住んでいるのですが、ロフトに携帯は持ち込まないというルールを作っているんです。寝る前にブルーライトを浴びないと睡眠の質が良くなるとどこかのお偉いさんが言っておりました。
たまたま携帯で設定していたアラームが6時に鳴ったんですね。いつもだったら6時に起きても2度寝、3度寝と気づいたら8時をすぎてしまっていたのですが、その時はすっきり起きれたんです。
その時の心境は、「やばい隣人に迷惑がかかるかもしれないから消さないと」から始まり、「うわまたロフトに上がって二度寝するの面倒臭い」でした。
自分の短所である「面倒臭がり」と「他人の目を気にしすぎてしまう」がここで活き、早起きに成功したという事例になります。
引っ越してから毎日この生活ができているので、僕と同じような短所を持っている方がいたらぜひ、「6時にアラームを設定して一階に置く」を実践してみてください。
あれ、短所って思っていたけど意外と長所になるかも？と自己肯定感が上がるかもしれません。
次回からはちゃんとした学習アウトプットを書いていきますので、引き続きどうぞご歓談ください。
それではまた。
【Web技術】ネットワーク用語を✅
筋トレして勉強して飯食って銭湯入る生活が一生続けば良いのにと常々思っている23期酒ケジュール改修中です。
今回は、Web技術の学習、特にネットワークの仕組みを復習していきたいと思います。
Webブラウザにデータが表示されるまでに起こっていること
アプリを作成していて、どのようにデータがやり取りされるかを今一度理解しておきたい。
1 クライアントがサイトにアクセスする
⇨クライアントとサーバ
2 データを要求する
⇨ネットワーク
3 サーバが色々処理する
⇨サーバ
4 クライアントにサーバがデータを送り返す
⇨サーバとネットワーク
5 受け取ったデータを画面に表示する
⇨ネットワークとクライアント
コンピュータ
ハードウェアとソフトウェアに分けることができる
ハードウェア
手にとって触れる機会、パソコンやスマートフォン、タブレットなど
ソフトウェア
物理的に触れられないもの。
プログラミングを指す。OSやアプリケーションのこともさす。
OSとは、オペレーティングシステムの略。
アプリケーションとは、特定用途のために作られたものを指す
アプリケーションを作るには、プログラミング言語が必要になる。
プログラミング言語を効率よく使うための共通部品、ライブラリが存在する
-
種類
Facebookでログインするための部品
Swiftで書かれた画像加工の共通部品
検索機能を実装するための部品
ライブラリは、フレームワークの中に存在する。
クライアント
具体的なクライアント
サーバ
リクエストを受け付けてレスポンスを返す役割を持つアプリケーションやコンピュータ
レスポンスとは
クライアントからの欲しい情報リクエストに対して応答すること
リクエストに応じて４つ種類がある
-
例
WEBサーバ
APサーバ
DBサーバ
検索サーバ
WEBサーバ
クライアントからリクエストを受け付けてWebページや画像を返すサーバを指す。
あらかじめ用意しておいた、ページや画像ファイルなどの静的ファイルを送り返す役割を持つ。
-
例
NginX
Apache HTTP Server
APサーバ
Webアプリケーションを動かすためのサーバ
リクエストに応じて内容が変化する動的ページを返す。
application.html.erbに書かれたページの<%= render %>部分がそうなのかも。同じレイアウトでも、ユーザーによって違うページを返す
-
例
DBサーバ
データを保存したり取り出したりする。
検索サーバ
大量のデータの中から索引する。
DBサーバからのリクエストに対して、ここにデータがあるよといったレスポンスを返す。
-
例
Elasticsearch
Solr
クライアントがデータをリクエストしたときの流れ
クライアント⇨webサーバ→
APサーバ→検索サーバ→
APサーバ→DBサーバ→
APサーバ→webサーバ⇨クライアント
補足
webサーバは静的ファイルを作成している
動的ファイルはAPサーバが作成してレスポンスしている
ネットワーク
複数のコンピュータを繋いでデータを送受信するもの
コンピュータ同士をケーブル中継器で繋いている
