LIFE STORY WEB開発 プログラミング

WEBプログラミングのリハビリでやったこと

※本サイトはPR表記を含みます。

 

こんにちは。ふわふわしょうちゃんです。

 

現在、ツイートや、ブログを一旦停止し、プログラミングのリハビリをしていました。

その中で、やったこと、改めて感じたことなどを記しておきたいと思います。

 

 

プログラミングリハビリの経緯

先日、とある企業様へ2次選考として、「入社体験」をさせていただきました。とても有意義な時間を過ごさせていただき、誠にありがとうございました。

終始、コロナ禍の中で、人と接することの喜びを感じることができ、とても嬉しかったです。

 

プログラミングのリハビリの経緯として、その入社体験の中に、「WEB開発に関する各テスト」があったからです。

良いキッカケをいただいて、約一週間という短い期間でしたが、久しぶりにフルスロットルで開発の感覚を思い出すことができ、非常に充実した日々でした。

 

結論としては、日々、プログラミングを行うこと、WEB開発を行うことが望ましいですが、家庭・育児などがあると、中々そうもいかないのも現実です。

なので、日常的にWEB開発を行えるように、WEB開発業務に携わっていくことが、やっぱり理想的。という感想です。

 

経緯はここまでとして、以下、やったこと、感じたことです。

 

マネジメントとWEBエンジニアとしての切り替え

別の記事でも書いていますが、前職では、開発チームのチームビルディング・マネジメントをさせていただいていました。

開発チームビルディングでやったこと【前編】

続きを見る

 

僕の中では、がっつりマネジメントを行っていく中で、同時にWEB開発を行っていくことは無理があると感じています。

なぜなら、使用する思考回路が全然違うと感じるから。です。

 

マネジメントに関しては、「人の管理」の要素が強いので、常に「対人」です。

コミュニケーション能力をより高く問われますし、周りのメンバーのプロジェクトの進捗や、評価するための行動、そして、ミーティングを行い、チーム同士のコミュニケーションの促進や、目標の実行、メンバーの変化にも気を配っていかなければなりません。

 

この辺りは企業によって、マネジメントにおいて必要とされる要素は様々です。

そうした「常に散漫とした注意を払う点」について思考を巡らせつつ、WEB開発に集中するのは、無理があると僕は感じています。

 

プレイングマネージャーとして、人材を求める企業は多い印象ですが、マネージャーとしての要素を強く求めるのであれば、企業側は、かなり無理難題を求めているように思います。

比率的にはどちらも「10:10で！！」みたいな。はっきり言って無理ゲーです。

 

プレイングマネージャーとして成立すると思う比率は、開発が7、マネジメントが3ぐらいの割合だと感じます。

例えば、チームとしての方向性は示す、また、メンバー同士の意見の食い違いや、何かトラブルが起きた際のまとめ役は担う。それ以外は自立進行型で行く。というような感じです。

 

それなら、緊急時には、まとめ役として参加するが、それ以外はWEB開発に集中すればよいので現実的です。

 

僕自身、前職でマネジメント脳になっていた要素が強いので、まず、WEBエンジニア脳としての切り替えをする必要ありました。

まあ、切り替えといっても、過去の自分は、どのように考えながらWEBアプリケーションの構築を捉えていたか、とか、開発に対する姿勢とか、そうした感触を実際にWEB開発を行いながら、取り戻していった流れになります。

 

とりあえず、書く、書く、書く

僕がWEB開発において、絶対に実行すること、それは「とりあえずコード書こうぜ！！」という考え方です。

 

以下、ツイートです。

最初から、綺麗なコードを書きたがるエンジニアを見ますが、うーん、うーんと、と考えている時間は、はっきり言って勿体無いです。

まずは、何をしたいのか、期待する動作は何なのかを明確にした上で、とりあえず書いてみる。コードの良し悪しは、その先の問題です。

 

エンジニアではない機能の要求者が、「どの様にコードを記述したか」は気にしてません。

バグがなく、「期待した通りに動くかどうか」が重要なのです。

 

もちろん、汚いコードは、確実に「悪」だと思います。プロのエンジニアとしては、技術的負債の観点からも、定期的なコードのリファクタリングは必要です。

ただ、最初から過剰な美しさを求めることは、厚化粧と一緒。ナチュラルが一番美しいという考え方は、多くの方が共感してくれると思います。

 

SQLと素のPHP

SQL文とPHP、もちろんどちらも書かなければ、忘れます。ぶっちゃけ、忘れてました。ｗ

ですが、一度やり直してみると、グワーッと思い出すものなのですね。率直に、そう感じました。

 

CRUD系のSQLは染み込んでいますが、INNER JOIN(内部結合)とOUTER JOIN(外部結合)の違いとか、一瞬「ん？」ってなるんですよね。

まあ、端的に言えば、NULL要素でも結合して、データを取得するかどうかなんですが。

 

WEBシステムを開発するにあたり、フレームワークを使用するのが当たり前になりつつあるので、Cakephpに関していうと、「SQLビルダー」に慣れ過ぎてしまうため、素のSQL文を書く、という機会が著しく減ってしまうことも関係してきます。

 

問題は「書けるかどうか」ではなく、「意味を理解しているか」どうかが重要です。

意味を理解していなければ、SQLビルダーを使用することも不可能ですから。

 

SQL文法に関しては、ググりながら組み立てていけば、なんとでもなるので、問題ないと思います。

PHPに関しては、基本的な構文は忘れていませんでした。

思考ゼロで書くレベルから、意識しなければ書けないレべルまで落ち込んでいましたが、すぐに思考ゼロで書ける自信が出てきました。

 

自分が開発したWEBアプリケーションのソースコードも読み直してみましたが、中々、気持ち良くオブジェクト指向な作り方をしているな、と感じるものから、不要に定数を定義していたり、オブジェクトを入れ込み過ぎていたり感じたことは、違う意味で、エンジニアのキャリアを磨いてきた財産でもあると感じることができ、良かったと思います。

 

あと、プログラミングで一番難しいと感じるのは、「名前付け」ですね。

「プログラミングちゃうんかい！！」って、駆け出しの方は思うかもしれませんが、変数や、関数、クラス、メソッド、メンバ変数、定数、DB設計、何に関しても、名前を付ける必要があります。

 

プログラミングは英語を標準とした考え方なので、やはり、英語が出来た方が良いと感じています。

久しぶりに振り返ったコードを見ると、メソッド名とか、笑えるレベルでしたので。

 

変な英単語を使用しているので、英語を出来る人が、ソースコードを見ると、意図が全く伝わらないという問題が待ち受けています。

 

HTTPメソッドのやり取り

WWWを最初に考案した、ティム・バーナーズリーは偉大です。

 

URL・HTTP・HTMLの最初の設計も彼ですから。

頭ん中どーなっとんねん。

 

シンプルな設計であるが故、無駄がなく、今後、バージョンが上がっても、根底は変わらないと思います。

 

HTTPメソッドも至ってシンプル。GET・POST・PUT・DELETE。しかも、WEBアプリーションを開発する上では、基本はGET・POSTしか必要ありません。

忘れるわけがありません。シンプルでありがとうございます。

 

PHPでHTTPメソッドを主に使用するのは、Formタグ内だと思います。

この辺りも久しぶりにゼロからプログラミングしてみて、プログラミングの楽しさというか、つまづくこともなく、ガツガツ作っていく自分を体験できて、安定剤になりました。

 

詰まることって、楽しくないですが、今は少しエラーが出ようとも、そうそう何時間も悩むこともなくなりました。

 

WEBセキュリティ

WEBサービスはパブリックに公開するものが多いですから、常に不特定多数の人に触られるという危険も含まれています。

イタズラっ子は、どこかにいてますから。特にオレオレBOT系ね。何が楽しいのかは不明ですが。

 

ですので、WEBセキュリティに関しても、しっかりと復習しておく必要があると感じました。

XSS攻撃、CSRF攻撃、SQLインジェクション辺りは、当然のごとく抑えておかなければなりません。

 

素のPHPでCSRF対策などを施すと、セッショントークンをフォームに設置して、POST送信時にトークンが一致しているのを確認します。

実際に実装しようとすると、結構手間です。

 

一方、フレームワークでは、この辺りをすぐに実装できる所は、本当に◎だと思います。

これだけでも、使う価値ありだなって個人的には思います。他の機能に集中できるので。

 

Cakephpは「セキュリティコンポーネント」という部品がありますが、それを有効にすることで、各セキュリティを施すことができます。

 

ただし、Cakephpが推奨する開発の仕方、例えば、フォームは常にフォームヘルパーを使用することなどを守らなければ、リクエスト送信時に即刻「ブラックホール」行きになります。

慣れないうちは、ブチ切れそうになっていましたが、この辺り、「誰が作っても同じようなソースコードになること」を想定しているので、合理的な設計だな、と今は思います。

 

Cakephpで簡易CMS

最新のCakephp4を使用して、チュートリアルである簡易CMSも開発してみました。改めてCakephp、好きですね。僕的にはLaravelよりCakephpが好きです。

 

なぜなら、Laravelは自由度が高すぎるが故、どんなシステムでも、設計者に委ねられる所、属人性が高くなりがちになる所がネックです。

その反面、柔軟さはダントツでしょう。思想としての分かれ道になるのですが、「設定より規約」を強く意識しているCakephpの方が僕は好きですね。

 

しかし、世の中の流れには逆らえないので、Laravelを勉強しつつ、いずれLaravel案件にも対応できなければと意識いましたが、ぶっちゃけ、開発が面白んない。なんでやろ？

できるなら、Cakephpを極めさせてくれるような環境を求めたいと思います。

 

Cakephp財団がんばれ！！

 

プロゲートを利用してみる

ツイッターの積み上げツイートで、良く駆け出しの方が、プロゲート勉強！！みたいなものを見かけていたので、どんなもんかと思い、良い機会だったので、有料のprogateも利用してみました。

 

結論は、「意外に良かった。」というのが感想です。

 

僕は、あまりプログラミングスクールとか、こうしたサービスに興味があまりなく、とりあえず、頭ぶつけながら習得していくタイプなので、今回も利用する必要はなかったのですが、使ってみると、中々良い。

何が良かったのかというと、WEBサービスのコンセプト、「WEB上でプログラミングをいかに効率良く学んでもらうか」という観点でのアイデアなどを学ぶことができて良かった。という意味です。

 

まず、GitHubを思いっきり意識したインターフェース。サンプリングに近いですが、世の中アイデアの奪い合いなので、全然アリだと思います。

HIPHOPもサンプリングに活かすビートを乗っけて、オレスゲーだろーで原曲より売れるんですから。

 

コードスタイルもAtom的な色分けで良いと思いました。

気になったので、内部のソースコードを軽く見ましたが、Reactを採用していて、SPA的な要素が強く、「自分もこんなインターフェースのサービス作りたい」と思いました。てか、次の環境で作るで。マジで。

 

「そっちかい！！」

 

という意見が聞こえてきそうなので、もちろん、メインの教育内容も、SQLを学んでみましたが、文章が極めて少なく、要点に絞って、キャラクターも入れつつ、実習。みたいな流れで人気がある理由がわかりました。

どうせなので、自分に関連している技術は全て一通り覚えるまで、やろうと思います。

 

まとめ

面接での、開発テストという機会を頂いてから、約一週間、色々とプログラミングリハビリのために、取り組んできたことを振り返ってみました。

率直に感じたことは、一度忘れたことも、いざ、やり直してみると、思い出す速度は、予想よりも速い。ということを実感しました。

 

まだまだ、取り組みたいことは沢山あるので、この機会を大切につつ、どこにコミットするべきかを見極めてアクションを起こしていきたいと思います。

 

では、今回はこの辺で。

-LIFE, STORY, WEB開発, プログラミング
-