Rails5速習実践ガイドを読んで

はじめに

今回は現場で使える Ruby on Rails 5速習実践ガイドを読了したので、それについての感想を記録していきます。

チェリー本で学んだ際には、文法やメソッド、クラスであったりその他諸々、決まっている事を学ぶところが多かったように思います。
それに対し、本書ではもちろんそういった面の学習もあるのですが、課題に対するテクニックや考え方などの必ずしも決まりきっていない部分の学習があったので同じページ数くらいでしたがより長い時間が掛かったように感じました。

ちなみに、読む前の知識レベルとしては、

を行ったくらいのものです。

読んで良かったこと

Rubyならではの記述方法をおさらいできた

実際にはRuby以外でも同じような処理ができる記述方法はあると思うが、

  • nilガードの記法 。getterに利用すると便利。
  • %wで文字列の配列
  • %iでシンボルの配列
  • reciever&.method のボッチ演算子(safe navigation operator)を使うとrecieverがnilでもエラーにならない。

など、個人的に特殊な書き方に感じているので再度覚え直すことができ、少なくともそういったものがあったなと調べ直せる程度に頭に入ったように思います。

先ほど上げたRailsガイドなどで登場したメソッドなどがよくわからないままでいたが、本書で要点、使用シーンを踏まえながら再学習できた

link_toparamsなど、説明はあったものの繰り返し書くことで理解が進んだように思います。
当然、これらの他にも多く紹介されており、実際にアプリを作りながらわかりやすい説明付きで学べるので利用イメージがつきました。

Railsではないが、実務で現在Webアプリ(オフライン環境ですが)を作成している中で、この考え方はすぐ使えるぞといったものをまさに速習実践することができた

partialなんかはタイミング的にもすぐに利用できる知識でした。
元々Web系の人が周りにおらず、正直知らないことだらけのまま作り始めていたので散らかり初めていました。
おかげで大分整理されてきたように思います。

その他

  • あげられている例が実際に「そういうページあるよな〜」とイメージしやすく、説明される内容が伝わりやすく感じた。
  • 実務でよく使われるgemなどについても所々で触れられており、また開発シーンの流れについてなども触れられていてWeb開発業務の働き方イメージもなんとなく伝わってきた。
  • Railsに限らず大切な要素だと感じる内容が多くあり、また使用技術も実はRailsだけのことばかりではないので知れてよかったと思う内容が盛り沢山だった。

など、多くの良かった点があげられます。

自分としては、こういった多くの人がその言語を学ぶにあたって通ってきた道をなぞることで、同じ道を通った人と共通の認識というか、考え方を持てることが実は大きなメリットなのではないかと感じています。
リーダブルコードなども非常に有名な書籍ですが、読んだことのある人同士であるかどうかでコードから伝えられる意図などに大きな差が生まれるように思うからです。

学んだこと

  • 基本的にどういった処理はどこがあるべき場所なのかを知識として知ることができた。
    • また、あるべき場所に記述していないと、将来的にどういった問題を含むコードになっていきやすいかを知ることができた。
  • 綺麗なコードを維持していくにあたってのテクニックや考え方は、Railsにだけではなく他の言語にも当然当てはまるもので、ポータビリティのある知識を知ることができた。
  • セキュリティ関連の有名どころの知識、また危険性やそれらへの対策について知ることができた。
    • 名前は知っているものの内容をよく知らない攻撃への対策など、Railsが対策への機能を持っていることも含めて学ぶことができた。
      また、これをやってしまうとせっかくの機能を無碍にするような行為についても合わせて説明があり、注意点も同時に学習できた。
  • Railsには知らなければ魔法のように見える機能が多くあるように思っていて、それらを広く知ることができた。
    • 名前から自動で探索して解釈されていたり、ヘルパーメソッドがなぜ使えるようになっているのかなど、学習前は理解不能でした。

知識として持つことはできたが、これから実践を通して何度も見返し、使える知識にしていくことが大切に感じています。
気軽に見直せるようにTyporaを使って自分のわかりやすいようにメモを取っていったので、実用時に見直しながら身につけて行きたいと思います。

良くなかったこと

ただの自分の反省になるのですが、Rails5の書籍を購入したに関わらず、知識もないのにRails7の環境で進めた結果色々とぶつかりました。。

  • 環境構築で詰まる
  • 説明されている機能がRails7では非推奨になっていて使用するまでの壁が高い(知識があれば別なのかもしれません)

とはいえ、それらの解消について調べることで知れたこと(Hotwireなど)もあって、結果的には学びになったように思います。

難しく感じたところ

初めにも述べましたが、テクニック、考え方については難しく感じました。
実用シーンで、同じ考え方を持っていたとしても、考え方への解釈や、また前提知識が誤っていたら間違った方向へ進んでしまう事もあるだろうと考えたためです。

結局のところ、これも場数を踏んで間違った方向に進んでしまった失敗ケースも通った先に本当に得られるものなのだろうと思うので、見返し繰り返しが大切な要素だと念頭に入れておきたいと思います。

最後に

Railsは、知っていれば便利かつ強力な機能が数多く用意されていると感じています。
それ故に、知らなければ魔法のように動作しているように見えるものも多くあるかと思います。

全てを知るのは難しいので、実践の中で多く登場するものや、自分が解決したい課題に対して解決できたようなものはしっかりと覚えておき、同じようなシーンに出会ったときに引き出せるようになっていきたいと思います!

達人に学ぶDB設計徹底指南書を読んで

初めに

前回はスッキリわかるSQL入門を読んで - john-hc20230703の日記にてSQLについて学んでいきました。
今回は達人に学ぶDB設計徹底指南書を読み、設計について集中的に学習を行ったので、それについての感想になります。

DB設計について事前に持っていた知識や、感じていたことは

  • コードを書いていて、DB設計に引っ張られて煩雑なコードにせざる得ないケースが多々ある
  • 正規化は第三正規形までを基本的に行う
  • 各正規化の理由はよく分からぬまま必要なことだからという認識
  • RAIDも言葉は知っているが、それぞれの特徴は知らなかった
  • パフォーマンス改善にインデックスを付ければいいと聞いてはいたが、どんなケースで効果が高いか知らなかった
  • 悪い/良くない設計(バッドノウハウ、グレーノウハウ)があることは知っていたが、どんなものか、何が悪いかまで知らなかった

といったもので、なんとなしにDBを使っていた人は割りとこんな感じだったりするのかなと思っています。

なんとなくの理解で済まして部分が、この本を読むことで「そういうことだったのか〜!」と腹落ちしたり、設計について気をつけねばならないことを知ることができました。
また、一貫して良い面と悪い面、トレードオフを強調されていて、判断基準が養われたように思います。

良かったこと

  • 見出しレベルの知識しかなかったものについて、内容を学ぶことができた
  • 全体を通して、技術/手法の使用(正規化やインデックスなどなど)に対してのメリット/デメリットを学べた
  • ER図を見てデータの繋がりがわかるようになった
  • 最終手段である非正規化までに考えるべき多くのパフォーマンス改善の方法を学べた

などです。
1個目に上げたものに全部が内包されているような気もしますが。笑

学んだこと

データ設計の重要性

データ設計がシステムの品質を最も大きく左右する。

という言葉が本書内にあるのですが、自分が開発に携わる中で感じていたことに対してまさにといったものでした。
テーブルの設計がこうなっていればよりシンプルだったのでは…?ということが多くあったので。。

性能のボトルネックになるのはストレージのI/Oであるケースが多い

データベースのファイルを分散させること、また読み出し/書き出しを最も頻繁に行うファイルについては、最も高性能なハードウェアをあてがうことが大切。
論理設計だけでなく、物理層まで幅広い知識が必要。

サイジングは難しい。小さいよりは大きい方が絶対良い!

大きい分には後から、「ここにこんなにお金かけなくても良かったんじゃない?」と小言を聞くだけで済むだろうが、小さすぎた場合にはシステム障害に繋がる可能性が高くなる。
大は小を兼ねる考えで、しっかり安全率を掛けよう!

RAIDについて

パッと読んで、RAID6とRAID10、どっちも最低必要になるディスク数が同じなら最低コスト同じじゃないの?と思ったのですが、RAID10はミラーリングするのでディスク使用効率から考えるとより大きな容量を必要とする分、高コストになるという理解で良いのかな?
耐障害性(2本まで壊れても大丈夫か、1本までか)や読み出し性能(RAID10が優勢)で要件に合わせて選ぶことになるというのが自分としての整理。

正規化、正規形について

第1~3の正規形については、冒頭で書いたように基本的に行う必要があるという漠然とした知識を持っていたが、本書を読むことでそれぞれの正規形がなぜ必要であるのかを知ることができた。
また、より高次の正規形については存在もよく知らぬものでした。
高次の正規形にすることで、更新作業の冗長性排除、整合性を保ちやすくなるなどいい点もあるが、欲しいデータを取得するにあたって多数の結合が必要になることで高負荷な処理になるなどのデメリットもある。

性能改善を行うに当たって、パフォーマンスチューニングでどうしようもない場合の最終手段として、非正規化を行う場合がある。
正規化は機械的に出来るが、非正規化はその業務に精通し、トレードオフを見極めて行う必要がある。

様々なパフォーマンスチューニングの方法

インデックス

どのようなデータに付与するのが効果的かデメリットはなにか、またパフォーマンスチューニングでよく耳にする理由を知ることができた。
インデックスをつける規模のデータ量を扱う機会がなかったのもあるが、せっかくインデックスをつけても使用されないケースがあることも知らなかった。 とはいえ、強力な武器であることは確かなので、検討する際にまず上がってくる手法だと感じた。 よく使われるB-treeインデックス以外のビットマップインデックス、ハッシュインデックスについての特徴も学ぶことができる。

統計情報

SQLが実行された際、データへの効率的なアクセスパスを決める際に使用されるメタデータ
これが古いと適切なアクセスパスが得られない(更新されていないカーナビのようなもの)ので、大幅な更新があれば、統計情報も再収集する必要がある。
なるべく早く更新するのが好ましいが、実情は非常に重い処理なのでサービス利用者の少ない夜間に行う事が多い。 また、統計情報を凍結するという手段が有効なケースもあるということ。

様々なバッドノウハウ

ある程度データベースに触れてはいるので、「そんなことやらんやろ」と思うものもあるのですが、そうなってしまうに至る経緯まで紹介されているので、納得できる。
本書では、水平分割、垂直分割や集約についてもバッドノウハウの章に入っている。
これらは結構やりがちなケースに思うので気をつけねばならないと感じた。
特に水平分割は、多くのDBMSが持つパーティションという機能で効果を満たせるので、避けよう。 水平分割の場合だけでなく、代替手段やそれ以前の対策の方法まで書かれているのが助かります。

様々なグレーノウハウ(本書内の造語)

こちらもバッドノウハウ同様、代替手段やそれ以前の対策の方法まで紹介されています。
列持ちテーブルはやりがちだなと感じつつ、またそれに対して行持ちにすることで欠点が大分少なくなるということや、列持ちテーブルから行持ちへ変換する方法まで書かれていて有用に感じました。
また、仮想的にテーブルを作るビューや、更新を起点にSQLを発砲するトリガーは、知らぬところで多段に重なっていかないよう、用法用量をよく守って使わないと、気づけば恐ろしいことになりそうだと。。

リレーショナルデータベースが苦手な木構造の取り扱い方法

いくつかのモデルが、そのメリット/デメリットと特徴について紹介されています。
図や、ノードやリーフの取得方法を解説するSQLもありイメージが付きやすいです。

この本は2012年のものですが、入れ子区間モデルの将来性に期待するのような文章がありました。
しかし今、入れ子区間モデルについて検索してもあまり盛り上がってる雰囲気がないので実用に耐えないということでしょうか?
有力になっているのであれば、かなり使い勝手が良さそうだなと感じたのですが。。

最後に

本書はいわゆる入門書ではないので、一度で理解するのは難しく感じました。
この記事はあくまで感想を書いていますが、裏で学習した内容を自分用にまとめたものは、かなり長くなっています。
まとめられる程度に理解するにあたって、三周読んでやっとといった形でしたが、とても読んで良かったと思う内容でした!

ここまで読んでいただき、ありがとうございました!

スッキリわかるSQL入門を読んで

初めに

今回は、スッキリわかるSQL入門を読んでの感想を書いていきます。

読む前の自分の知識レベルとしては

  • 業務でPostgreSQLを使用しているが、単純なSQLで取得したいものは得られ、複雑な部分はアプリケーションサイドで処理していた
  • 4大命令は使える
  • 結合や副問い合わせも知識としては持っている
  • SQLのどういった処理が高負荷かなどはあまり気にしてこなかった
  • 絞り込みや加工、集計やトランザクションも調べつつ使用はできる

といったなんとなくは使えるものの浅い部分はかなり浅い理解のまま使っていました。

知らないがために、よりシンプルにSQLで処理できたシーンをアプリケーション側でやってしまっていたなと思う点が読んでいて多々ありました。 とはいえ、SQL、アプリケーションごちゃ混ぜになるよりは良いんですが…

良かった点

まず良かった点ですが、

  • Webで調べつつ使用するでは、本来セットで学べているだろう知識に穴のある部分に気づくことができた
  • 期待した結果は得られているが、なんとなくの理解で過ごしていた部分を理解できた
  • dokoQLを使って、本書内のSQLを実際に実行して結果を見ることができ、またそこでどう変えればどう結果が変わるかを見ることができる

など、他にもありますが主な部分はこの辺りになります。

学んだこと

Webで調べつつ使用するでは、本来セットで学べているだろう知識に穴のある部分に気づくことができた

先述した通り、アプリケーションサイドで処理していたことで知らなかった(必要とすることもなかった)ことが多くありました。

OFFSET - FETCH

limitで事足りていたので、何レコード目から何レコード目みたいな取得方法を調べたことすらなかったのです….

自分がいつも使っているPostgreSQLだと'limit offset みたいに書けるので、fetch`は使わなくても良さそうです。

TRIM / SUBSTRING / COALESCE

きっとwhereでの絞り込み処理もアプリケーションサイドでやってしまっていたので辿り着かなかったのでしょう…

アプリ内でどうこうより、DBからコンソールにクエリを打って検索したい時に幅が広がるので知れて良かったと思います。

count(*)とcount(列)でNULLの扱いが異なる

クエリを打って検索する際にこの違いを知らなければ混乱or誤った数で進んでしまうところですね。

ANY / ALL / IN演算子

PythonのDataframeが便利すぎて…. これを知ってる知ってないでは書けるクエリの幅が全然違いますよね。

相関副問い合わせ

ぱっと見、違和感のある書き方ですが、便利ですね。
高負荷であることは覚えておかなければいけないですが、単純に調べごとをする際に利用機会が多そうです。

自動コミットモードの解除

普段PostgreSQL+アプリケーション(Python)では、pythonのpsycopg2ライブラリを使ってDBを操作しているのですが、ここでは自動コミットは働かないので大丈夫でした。
今まで偶然大丈夫だっただけなので、今回知れてよかったと思います。

ロックエスカレーション

使用するDBMSによっては、内部的に自動で行われることで実はボトルネックになっていたり、デッドロックの原因になったりがあり得るということなので、知っておく必要のある知識と感じました。

DDLについてはDBMSによってはロールバックできない

作業前のバックアップは何にしろ取っておくのが吉というのは当たり前なのですが、こういった仕様のものがやはりあるので、より大切だと認識しました。

部分一致検索 / 後方一致検索ではインデックスは使用されない

知らないと、インデックスつけたし高速になってるはず!
…あれ?となっていたことでしょう。

今の所、インデックスをつける必要がない程度のデータ量しか扱っていないですが…

マテリアライズドビュー

実務でPostgreSQLGUIから見るのにa5m2を使用しており、そこでマテリアライズドビューという単語は見ていたのですがなんだろう?と思っていました。(一つも作られてはいませんでしたが)

トップダウンアプローチ / ボトムアップアプローチ

理想・要件から設計していく視点と、現状から設計していく視点、どちらも必要であり、片方では過不足が発生しやすくなる。

期待した結果は得られているが、なんとなくの理解で過ごしていた部分を理解できた

where句に書くか、having句に書くか曖昧

各句がどの順番で処理されていくかをしっかりと理解できていなかったので、なんとなく書き移して期待通りに得られた!で済ましていたように思います。
where句に書くのが正しい処理もhaving句に移しているケースもきっとあっただろうなぁ。

トランザクション分離

漠然と大切だという認識は持っていましたが、本書で紹介されている副作用について、それぞれ実際のケースが頭に入っていなかったです。

こはちょっと…と感じたところ

例題のカラム名も日本語

実務でカラム名は大抵日本語を避けると思うので。
また、入力時も入力切り替えしないといけないのでちょっとめんどくさく感じてしまいました….

参考書内はわかりやすくするため日本語になっているのは良いと思うのですが、実際にSQLを書く演習では英単語になってると良いなと。

dokoQLはちょっと使いづらい

SQLの実行回数制限がある(上限に達するとリセットしないとならない).

日本語入力すると見えてるカーソル位置と実際のカーソル位置がズレる不具合があった。
(自分だけかも知れないですが)

読了した後でも難しいと感じる部分

トレードオフを理解して採用する必要があること

経験を積むしかないことではあると思うのですが、実際自分が設計する場面を思い浮かべるとかなり苦戦するのだろうなと感じています。
設計する際にまた読み返しつつ、繰り返して身につけていきたいと思います。

複雑な副問い合わせや結合

当本を読む前よりはかなり理解しやすく感じますし、自分でSQLを書くのもスムーズになったようには思うのですが、難しさはまだ感じます。

最後に

今回はスッキリわかるSQL入門を読ませていただきました。

1度で全て理解できるわけではないので、あれ?と思うたびに読み返したいと思います。 次回は、達人に学ぶDB設計徹底指南書を読んでの感想を書く予定です!

チェリー本を読んでの感想

はじめに

こちらを作成してから、技術記事的な投稿が主だったため、Qiitaで活動しておりました。   といってもまだまだ数は少ないのですが!

今回は、かの有名なチェリー本を読んでの感想を書いていきますので、ブログが適切ということで久しぶり、というより初回以降全くの放置でしたが。。。笑

感想

長ったらしく書くのは好きではないので、先に結論的なまとめを書いてしまいます。  

まとめ

本書を読むまでのRubyに関する知識としては、Progateによる学習のみで、   「Rubyは言語に対し、Railsフレームワークである」   という認識がある程度。   ただ、「RubyRailsを使うためのもの」という認識は拭えていませんでした。  

このまま学習を進めていた場合、頭からRailsでのRubyを学ぼうとし、  

  • RailsフレームワークでのRubyと素のRubyの見分けもつかぬ状態でサイトを見て混乱
  • 大して基礎もなっていないのにRailsに入ろうとして難しく、どう手をつけていいか・・・状態

に陥っていたと思います。 

本書を読むことで一番大きかったのは、   素のRubyを学ぶことで、まずプログラミング言語として取っ付きやすく学べた   ことだと感じています。

どういうことか

チェリー本なしにRubyを学ぼうと思うと、恐らく 

  1. Ruby公式ドキュメントを読む
  2. Qiitaなどの記述記事などを読む
  3. その他、スクールなどが公開している記事を読む

あたりの行動を取ると思います。

ここで、確実に正しい情報に繋がるのは1番です。   そこで十分に理解が進めばいいかと思うのですが、私には難しく感じ、より噛み砕いてあるであろう記事を探そうと2番、3番目の行動を取ります。 

すでに素のRubyRailsのRubyの見分けがつけば良いのですが、この時点では難しいと思います。   何しろ、理解が進んでいないから記事を探している状況なので。。

また、Rubyは他の言語と比べて特殊な書き方が割と多くあると思います。   色々と記述する必要のない記法が用意されていることで、使いこなせば短く簡潔に書けるし、読み手側もスラスラと読めるのでしょうが、初心者からするとそれが壁となりもします。  

よかった点かつ学べた点

印象に残った点をあげていきます。  

  • 他言語を知る人間から見ても特殊に感じる書き方がどのような経緯でその形になったのか、段階的に説明されている。   * 個人的に、壁に感じる部分だったので順序立って解説していてくれて非常に分かりやすかったです。
  • 例題の実施において、テストを書く→プログラムを書く(細かい部分は省いてますが)の流れで進むので、実践的に学べる。   * テストを書けるということはすでに必要な機能ごとで分割できており、整理されたプログラムが書けるフローを自然に覚えられるように感じた。
  • 本書で書ききれない部分はQiitaやブログで記事にされていたりして補完されている。 qiita.com blog.jnito.com

  • 正規表現について、段階を追って詳しく説明されている。   * エディタでの置換時に使ったり、もちろんソースコードでも使用したりしますが、なんと無しに書いていたのがクリアになりました。

  • yeildProcについて、段階的に説明されている。   * 最終段階を急に見せられても???って感じになった最たるものでした。笑   まだ完全な理解はできていないですが、実使用時にしっかり見返して身につけていきたいと思います。
  • 素のRubyRailsのRubyの違いが出る理由が書かれている。

難しい感じた点

  • 初めから公式ドキュメントを読むよりも、だいぶ易しく順を追って説明されていますが、当然プログラミング言語なので簡単というわけではない。
  • 本書の冒頭に記述されているが、他言語を学習したことある人やRailsRubyに触れたことがある人を対象としているので、基礎的な部分でおざなりなところがあると詰まるかもしれない。

最後に

以上が、簡単にはなりますが、私がチェリー本を読んでの感想になります!   頻度は低いのですが、

qiita.com

へ投稿していたりもしますので、よければよろしくお願い致します。

HappinessChainへ入会し、3週間の学習を経て

はじめに

HappinessChain (以下、HC )へ入会させていただき、ちょうど3週間が経ちました!
これから学んでいく中で、心境の変化や考え方など、自分の中で完結するものは、
こちらのブログへ。
技術的なアウトプットは、Qiita へ書いていきます。

じぶんは

簡単に、どんな人間か?について知ってもらえればと思います。

  • 30代現役エンジニア(ただし、非エンジニア期間のほうが長い)
  • ざっくりとした経歴は

    1. 新卒:SE職
    2. 20代後半:半導体エンジニア職
    3. 現在:SE職

    で、新卒時は主にC言語、現在はPythonを使用しています。

  • 喋らないと怖い人に思われがちですが、基本的にはゆるい やつです。笑

ほんだい

冒頭でも書いた通り、入会からちょうど3週間が経ちました。
また課題も1つ目のまとまりを終えたタイミングで

  • なぜ入会すると決めたのか?
  • 実際入会してみての所感
  • さいごに

という構成で書いていきます!

なぜ入会したか?

これを書くにあたって、

  1. わたしの不安
  2. きっかけ
  3. 初めの印象

最後に、決め手 の順に綴っていきます。

わたしの不安

現職がSE職と書きましたが、余り良い環境とは言えません。
特に、コードレビューがない という部分に、不安を感じていました。
(他にもありますが、あえてここに書く必要はないと思うので割愛!)
また、環境を変えるにしても、今の技術力では同じような環境から出られないだろうとも考えていました。

きっかけ

Qiita Tag:HappinessChain のオススメ記事に、HC についての記事が上がっていました。
そこで興味を持って、happinesschain のタグがついた記事をいくつか読みました。

初めの印象

記事を読んだ私は、正直に書くと、「そんなうまい話あるのか?」と思いました。ごめんなさい。笑
調べても、Happiness Chainのサイトと、Qiita の記事以外にほぼ情報がなく、不透明な部分が多いように思いました。

決め手

では、なぜ入会すると決めたのか?
ぶっちゃけた部分も含め、結論から書くと、

  • ハイレベルなコードレビューがある。
  • Twitter#HappinessChain を調べると、多くの方が確かなロードマップに則り、高いモチベーションで学習しているのが見えた。
  • サブスク型なので、合わないと思っても、1ヶ月分の投資で終わるという選択も取れる。(杞憂に終わりました!)

という点でした。
この時点では、全肯定!というわけではなく、「入ってみないと分からないな」という気持ちも残っていましたが、興味と、自身の環境を変えたいという思いが勝ちました。

実際に入会してみて

ロードマップの序章も序章であり、コードレビューは未体験の状態です。
この時点でも、思いました。
誰もが書いているので見飽きてることと思いますが・・・
もっと早く知りたかった
です。

修了した範囲の学習順序も、似たような機能を持つものを、
複数の方法で繰り返し作っていくことで、新しい事を学びながらも、
同時に、先の学習内容も理解が深まるよう出来ていると感じました。

私が、この3週間を通して良いなと思った点を上げるとすると、

  • 信頼のロードマップがあるため、「次何をやればいいの?」という部分にリソースを割かなくて良い。
    (もちろん、脳死でやればいいという意味ではない)
  • Twitter#HappinessChain で調べると、仲間がいる。モチベーションを保てる。
  • 毎日やる習慣が付く。
  • 学習を継続していることで、自己肯定感が上がる!

というところになります!

さいごに

今回、初めてのアウトプットとして、こちらを書かせていただきました!
文章の書き方、見出しの分け方等、未熟な部分が多いことだと思います。

これから学習していくにあたって、技術的なアウトプットも行っていくので、
書き慣れていければと考えております。

また、最終的には、HCでスキルアップし、◯◯へ採用していただきました!のような記事を 投稿できるよう、励んでいきたいと思います。

ここまで読んでいただき、ありがとうございました!