2つの文化、2つの世界
背景
これまで自分はシステム開発において、大きく分けて2つの世界で開発に携わってきました。どちらも要件定義～テスト、保守までかかわったことがあります。
前者はユーザー企業の業務系で主に業務改善に関わるところで、よく揶揄されるCOBOL、Excel、VBといういずれの文化を持っていて、古いIT企業のイメージを当てはめると大体当たっているような気がします。
ただし、新しいプロジェクトではC#（ASP.NET Core）、Angular、TypeScriptあたりを触っていたので、すべてが古いというわけではなく歴史的な問題も大きいです。保守対象が明らかに広いので、古い資産が残るのはどうしようもないです。
ユーザー数は最大で数千人ですが、基本的には事業部単位でシステムを組んでいたので、普段は100人未満ぐらいだったと記憶しています。
後者はWeb系で厳密なところは置いておいて、toCの会社です。持っているサービスはいくつかありますが、現状ではほぼ1つのサービスで収益を上げています。
こちらも一般的なWeb系のイメージで考えてもらえればよくて、フレックス、リモートが可能で、Rails、Nuxt.jsでゴリゴリ新機能を追加していくという感じです。
ユーザー数はアクティブかどうかは置いておいて、数10万という単位なので、少なくとも前者とは桁が違います。
前者にいた経験が長くてWeb系への憧れがとても強かったのですが、今少し時間が経ってきて前者の戦略に理解ができてきたので、その世界を中心に考察してみたいと思います。
ちなみに、会社（システム部門）の人数はどちらも100人足らずぐらいで同じです。
ユーザー系の世界
他のユーザー系の事情もそれなりに聞いているので、ユーザー系という主語が大きいのは承知の上ですが、いい名づけが思いつかなかったので、許してください。
開発技術の選定
選定ポイントはいくつかあって、まずは開発している組織が大きいかどうか、サポートを受けられるかどうかに大きな比重が置かれていたように思います。
データベースはOracleが最も多く、開発環境はVisual Studio、言語はC#、OSはWindowsです。Micorsoftとべたべたです。
実際メールで問い合わせをして確認したり、営業の方と話をする機会は多かったです。
ここにはグループウェアがOffice365で、新しい不具合を毎回踏まされるという事情もあるにはありました。ついでにWindows Updateによる影響も切実でした。
ライブラリ選定も基本的には大多数に合わせろ、です。なぜかというと、マイナーなOSSを使って将来的に更新されなくなった時に直す技術力がないからです。
個人的にはVisual Studioの機能の豊富さがすごくて、ほとんどの作業がGUIでできる経験がつめたのは大きい経験でした。
あのエディタのおかげで会社の技術力が底上げされていた感があります。Vimとか、VSCodeでは環境すら作れなかったと思います。
Microsoft縛りで辛かったのは認証回りと、IEがサポートから絶対に外せないことぐらいですかね。（あとはiPhone対応が辛かった）
もう1つあったのは、組織で技術を統一しようという文化がありました。プログラミング言語、ライブラリ、エディタ等々を全部統一して、勉強範囲と開発範囲を最小限にしようという考えです。
当時は反発がありましたが、戦略として今ではわからなくもないです。
社内ライブラリ
実は結構作っていました。プログラミング言語が統一されているのでスケールしやすかったのもあるでしょう。
あとは、技術力が高い人が数人いて、その人たちで他の人の分の作業をすべてするにはどうするかみたいな話があったように思います。
その結論としてできる限り、超高性能なライブラリを作って、それ以外の人は詳細をほとんど知らなくても済むようにしようというそういうプロジェクトがありました。
例えば、新しい管理画面を作るときは、テーブル定義をGUIで設定すると、自動でスキャフォールディングが走って画面の大体ができるみたいな仕組みがありました。
コンポーネント集もあって、それでほとんど賄えるようにしていました。
作っているのは数人で、使っているユーザー数はその10倍くらいいたんですかね。
ただ、中身をみると結構地道なコードで書かれていて、新しい技術は使わないという方針がありました。
なので、OSSをforkして作ったとかそういうことはしてないです。
コーディングの作法
ルールを作って縛る、これが大原則です。
Linterはもちろん、変数名のルールが決まっていましたし、画面ごとのメソッドのインターフェースも決まっていました。細かいことを言うと、テーブル名、カラム名も誰がつけても同じになるようなシステムがありました。
使える技術的な範囲（新しい構文は使わない）も制限されていて、これも優秀な人がレビューして、全部そろえるという原則がありました。
忙しい時は週末に出勤して1日中リファクタリングしている時もあった気がします。
ルールが世間一般と同じかというとそうでもなく、独自インターフェースみたいなものがあったように思います。
それはWeb、デスクトップの両方で統一された世界観でした。ここでも技術的な統一が果たされていました。
機能面
業務系はとにかくビューを作る仕事が多かったです。
作った画面の8割ぐらいは検索系でこんな見方をしたい、こんな出力をしたいという要望（最初はCSVですが、必ずExcelになる）でした。
ここも自動化が進んでいた理由になる気はします。
更新系の画面もありましたが、これは入力項目がひたすら多く、デザイン以前に並べるのがしんどかったです。
ユーザー系の会社だと入力項目をいかに増やすかという要望が大半だったかもしれないですね。
非機能要件については、パフォーマンス要件がかなり厳しくて、レスポンスが何ミリ秒以下みたいな基準がありました。
しかし、社内ネットワークから出さないことも多いので、セキュリティなどはそこまで厳しくなく、サーバーも1台あればさばくのに問題はなかったです。
要件定義、設計
人材の半分以上をここに突っ込んでいて、年長者は軒並みここに配置されているので力の入れ方が違います。
要件定義で数年というケースもあるほどで、どれぐらい正確にやるかというものでした。
こういう分け方をするということはアジャイルではなく、ウォーターフォールということですが、現実にアジャイルでは無理だと思います。
文化として納期の正確さ、機能の欠落が許されないところがあり、調査をかなり綿密にやらないとうまくいかなかったです。作りながらではやはりもれました。
業務を分析して、どこを直すと業務を直すかというのをフローを書いたり、というので専門性があったように思います。
技術と同様にその事業について詳しくないととてもではないが、口にだせる領域ではなかったです。
人材育成
基本的には新卒から育成でした。文系、理系も特に問わなかったので、対人能力と論理的に話せることあたりが採用方針だったと思います。
勉強熱心さはそこまで求められていなかったです。
ただ優秀な数人の半分ぐらいは外部でしたので、優秀な技術力を持つ人を育てることは最終的にできていなかったかもしれないです。
そもそも採用のための広報もほとんどしていなかったので、通年で応募が数十件もなかったです。
仕事の振り方
自分でどんどん見つけたことをやるというよりは、基本的な方針が上から振ってくるのでそれに従います。
もちろん新しい提案はしてもいいのですが、承認プロセスが結構上まで行かないとだめなことも多かったです。
Web系の世界
皆さん知っていそうなので、あまり詳しくは書きません（力尽きている）。
基本的には技術力志向が強いように思います。
レビューもありますが、それを踏まえても最低限のコーディングルールしか注意されず、機能面でのレビューが多い気がします。
開発環境はOSこそMa統一ですが、エディタなどは自由でVSCode派が多いですが、Vim、Emacsなど色々いるみたいです。
言語やライブラリはマイナーすぎるものは選びませんが、サポートなどはあまり気にしていない様子です。
特にフロントエンドについてはいざとなれば自分たちで置き換えたり、直したりできる技量があるので、よければ採用ぐらいの方針です。
社内共通ライブラリは今のところないです。改善する可能性は高いですが、前ほど大規模にやることはないように思います。
画面はコピーで作れるものも少ないのでスクラッチでコツコツ書くという形です。要件定義は誰でも参加できるので、自由に意見を言えます。
業界のルールや知識はありますが、ユーザー系ほど専門領域ではないです。
採用も今の段階では自分たちと同レベルの人をとるというのが基本方針です。
仕事も上からほとんど降ってこないので、自分たちで見つけてすぐに手を出すというやりかたです。
振り返って感じること
ユーザー系の企業のやりかたはシンプルで「技術は優秀な個人に任せて、他は専門領域で勝負しよう」です。
一方Web系の企業は「優秀な個人の数を増やして、全員が多くの領域に参加しよう」でした。
Web系で仕事をする前はとてもうらやましいという気持ちがありましたが、優秀な人のレベルは大きく変わりませんでした。
なので、もし前者で優秀な技術者が多ければ、下のような戦略を取っていた可能性はある気がしています。
Web系の企業は特殊な技術を採用すると人が集まりづらいのはあると思っています。個人の技術力の向上の機会を会社が提供することが一種の福利厚生になっているからです。
特殊な技術ができても、中途で他のところに移るのが難しいですからね。
どんな技術にも好きな人はいるので、そういう会社には行けると思いますが、幅となると辛いのかなという思いはあります。
そういうところで一般的な技術を使いこなしているのすごいなぁ、技術力が高いなぁと思って見ていたのですが、ユーザー系のやり方は一般的ではないやり方をしているだけで知恵がありました。
今のIT界隈は基本的には有名な技術を知っていることを技術力が高いと評価していますが、その評価は正当なのかなと思いを馳せます。
前の会社には技術力を上げたいと言って抜けさせてもらった手前、申し訳ないなという思いがあります。今はとても勉強になっていますが、ユーザー系の会社にとってはやりかたが違うので参考になる部分は少ないでしょう。
だから、自分がWeb系に入って優秀になったということはなく、ただ今のやり方の中から学べることを真摯に学んで、折衷点みたいなところを探したいなと思っています。
Perlに夢中
きっかけ
最近、Perlに目覚めてしまいました。
きっかけはMacbookで開発するようになり、ちょっとしたスクリプトを書かないといけない機会がぼちぼちでてきたことです。
これまでWindowsマシンで仕事してきていたので、何となく調べながらやっているとシェルスクリプトの話になって、そこから芋づる式にPerlに当たったように思います。
前に一度文法書を読んだ時はしっくりこなかったので継続していませんでしたが、今勉強し直すときれいに線でつながるようになり、とても楽しく学べています。
あと、「Let Over Lambda」でダグ・ホイト氏が学ぶべき言語に挙げていたのもあります（他はCとHaskellもあったような）。
やったこと
文法書を何冊か読んで、リポジトリをちらちら覗いています。入門書ではないですが、「Perl Hacks」がメタプログラミングとか、テスト駆動的なトピックも多くて面白かったです。
あとは、「初めてのPerl 」が入門としてはよかったです。
Perlについて思ったこと
機能が意外に多い
Perl6は機能がモダンになっていると聞いていたのですが、Perl5についてはあまり期待しておらずVB6ぐらいの印象を持っていました。Perlで関数型、Perlでオブジェクト指向という文章を見たことがなかったので、シェルスクリプトより少し書きやすい言語なのかなと。
調べていくと関数を値として渡すことも、オブジェクト指向的に扱うこともできました。
分配束縛みたいなこともできますし、タプル、ストリームに近いこともできますし、自分の中でモダンに近いと思えることは大体できました。
細かい差はあるのでコールではないのですが、どうしてこうなっているかという仕組みがわかりやすい分Perlのやりかたは気に入っています。
他の言語との共通点が見つかる
これがPerlを見ていて一番楽しいところです。
PHPは個人的に好印象ではなかったのですが、Perlの文法を見てからとらえ直すと「だから、こういうやり方になったのか」とハッとすることが多いです。変数の宣言もそうですし、スカラーという概念などもここから来ているのかというのを感じる瞬間がとても楽しいです。
Rubyは最初期ほどPerlの影響を受けていないと聞いていますが、それでも正規表現リテラルとか文字列の生成あたりにPerlっぽいシンタックスあったりして、そういうのを見つけた時、にやりとします。
Lispとの共通点で言うとダイナミック変数を使うところとかでしょうか。一時的に設定を上書きするというやりかたをPerlではそこそこ使うので、前に勉強したぞとなりました。
まだ、本格的に勉強していないですが、ソースフィルターをつかえばマクロ的なこともできそうな気はします。Lispほど直感的にはならない気はしますが、ハックとしては楽しそうです。
Perlの後付けオブジェクト指向も、Lispの後付け文法（マクロ）に近い感じがしますね。そういうことを考えるのが楽しい言語です。
読みやすい、書きやすい
Perlというと好きなように書けるので読みづらい、暗黙的なコンテキストに依存するから保守しにくいと聞いていました。個人的にはそういうハックは普通に好きなので、なんだそれ最高だなと。
とはいえ学んでみた感じだと、規則性もしっかりしているので慣れたらそこまで黒魔術ではないんじゃないかという気持ちです。何が起きているのかわからないということはないです。
RubyやJavaScriptでも黒魔術めいたコードをこっそり書く人もいますし、程度の問題ですかね。
Perlは言語学者が設計していて、読みやすく書きやすいようにしているという話があって、慣れてくると自然に読めるという意味でも完成度は高いと感じます。
基本的には大いなる責任が伴ってもいいので、自由に使える言語が好きです。
シェルスクリプトと同時に学べる
シェルスクリプトの延長に近い言語なので、今学ぶと相互的に理解できていいです。
今まで学んだ言語は抽象化されていてあたかも言語の機能みたいになっているところが、Perlでは隠されていなかったりするので、それが見えるのは面白い体験です。
今後とまとめ
文法やこんなモジュールがあるよ！というのを見ているだけで楽しいんですけど、もう少し深堀りしたいなぁという思いがあります。
リポジトリを何個かあたりをつけて研究しつつ、何か作るとすればコンソール系のスクリプトをさらさらと書けるところまで練習するつもりです。
まだまだ未知なことも多いので、一つずつ先人が切り開いた世界を見てみたいです。
あと、昔Perlを書いていたプログラマの人は今Goを書いているという現象を何度か観測しているので、そっちもどこかで手を出すかもなぁと思っています。
仕事とステートマシン
何となく思いついたので、小ネタです。
仕事のとらえ方
仕事をしている状態をどういう認識でとらえるべきか？というのが最近の興味です。
この前の分析ではプログラミングという仕事はパターンの発見、繰り返し、組み合わせあたりで行っているのではないかなという仮説を立てました。
それと似たような見方として、ステートマシン（状態遷移）でも説明できるのではないかと考え中です。
簡単な状態遷移
例えば、単純な疲労度で言うと、
- 元気
- 普通
- 疲れている
- 限界
あたりの状態があって、１日の中でそれが変化しているという可能性はまぁまぁ高いです。その中で、状態ごとにできる振舞いがあって、遷移条件があると考えられます。
そこらへんを明確に定式化してとらえられると便利な使い方ができるの可能性があると思います。
応用例
思考に関しても、
- 深く集中する
- 広く注意を向ける
- 機械的に判断する
- 誰かの思考になりきる
あたりの状態があって、それを適当に切り替えているのではないかと思います。
それを意図的にどういう状態があるのか、どういう時にそれを使うべきか、どうすれば切り替えれるかを認識できれば、もう少し深いものの見方ができる気がします。
やりたいこと
要するに自分が仕事をしているときにどういう状態にあるのか、何ができるのかを知りたいなと思っています。
暗黙的な思考や状態をどこまで自分の管理下におけるのかというところで、言葉や概念にして説明できればいいなと。
ステートマシンの概念はその切り口として役に立ちそうなので、もう少し考えてみたいところです。
2018年振り返りと今年の抱負
2018年の反省
学んだこと
傾向
手を広げたがる
プログラミング言語に5個も手を出してたり、Vue.js、React、Angularのすべて動向をウォッチしているあたり、節操がないと言われても仕方ないと思います。
ここに書いていないものもとりあえずの気持ちで追っかけているので、実際にはもう少し多いですし。
パターンを見つけるのが好き
手を広げたがるのはパターンを読むのが好きだから、という感じです。
自分で新しいパターンを作るよりも、プロジェクトを探してその構造を解析する読むほうが好きなんだなと今年気付きました。
1から新しいプロジェクトを作るよりも、色んなパターンを組み合わせてバランスをとるような物の作り方をしていて、今年はその傾向が特に強かったような感じがします。
技術以外のパターンについて
人についても比較的パターンを見つけて、それを自分の糧にするような学習方法だった気がします。
例えば、
- あらゆることを計算式で表現できる形に直したい人
- コードのすべてのパスに対して、テストを書きたがる人
- あらゆる説明を図に書いて、紙で説明する人
- テストをするときはユーザーの気持ちに完全になり切る人
- すべての作業に対して新しいツールで楽できないか考える人
こういう人たちが周りにいて面白いなと思ったので、時々こういう思考を意図的にトレースして、使ったりしていました。
どちらかというと郷に入っては郷に従えで、その人と話しているときに合わせるケースが1番多い感じでしょうか。
課題
2018年を総括すると、色んなパターンを見つけてはその場に合ったものを選ぶ、というような能力を磨いてきた1年だったかなという風に思います。
なんですけど、今のやり方は例えるなら、職場のコードのパターンを見つけて、それに溶け込むようなコードを書くという使い方で、どうかなぁという気持ちがあります。
仕事ではVue.jsを書いていて、エディタはVSCodeなんですけど、職場で使っている人が多いからぐらいの理由しかないです。
Vim、Emacs、Lispあたりの勉強で身に着けたキーバインド、REPL駆動、その他諸々がつながっていないんじゃないかという感覚があります。
2019年の方向性
考えてみるとパターンを覚えて、それを活かすというやり方は中学生ぐらいから鍛えてきたものなので、今から戦う武器としてはまずこれを前提に置くべきなのかなという気持ちがあります。
そのなかで色んなパターンとか能力をどれだけ越境できるのかを考えてみたいなと思います。
パターンを認識してそれを使うというのはそこまで意識的にやっていなかったので、自分の中で言語化したり、課題を考えたりして、もう少し意図的に使ってみるというのが今年の課題ですかね。
技術的にはGraphQLとWeb Workerあたりには手を付けてみると思います。あとは、Rails、Rubyを業務で使えるまでは慣れたいです。
途中参加のプロジェクトに慣れるまで
近況
最近、これまでとは違うプロジェクトに途中参加することになって、大きな環境の変化に対応する日々を過ごしていました。
これまではフロントエンド・バックエンドの両方を触っていましたが、今はほぼフロントエンド専任です。
技術的にはNuxt.jsが中心で、Angularに似ているとはいえ、その違いを吸収するのに時間を使っていました。
事前にNuxtとVueの情報を拾っていたので「たぶん、行けるだろう」と思いきや、プロジェクトの理解に半日ぐらいかかって、自分の中で困惑することが多かったので、その知見を書いてみようと思います。
プロジェクトを理解するまで
実際の画面を触ってみる
参加するころには大体の画面はできていたので、とりあえず何も考えずに触ってみました。ある意味、ユーザー目線に近かったので、この時の気持ちを書いておけばよかったのでは、と今更ながら思ったりします。
何となく20分ぐらい触って大体の機能を拾っただろう、とこの時点では思っていたのですが、ここで開けなかったページがあったみたいです。
手探りだと体系的にはいかないですね。ちなみに仕様書はあったそうですが、「最初は書いていたけど、更新されている自信はない」といわれたので、あまり確認していません。
フォルダ階層をざっとみる
Nuxtは基本階層が決まっているので簡単かなと思ってみていました。
２階層目以降は、スマートフォンとPCでコンポーネントを分けているという話を事前に聞いていたので、まだつかめました。
3階層目はドメインごとに切られていましたが、ここがわからなかったです。実際の画面の言葉は日本語で、ファイル名は英語なのでそこが微妙にしっくりきませんでした。
それでもなんとなくは理解して、これで仕事できるかなと思いました。
直近のIssueを直してみる
Issueをつぶすのが当面の仕事だと言われていたので、直近3つぐらいのものを適当に取り出して、直せれば理解できたんじゃないかと勝手に考えて、やってみました。
ですが、全然できませんでした。
Issueは大体ドメインの言葉で書かれていて、それがどこに当たるのか全く分からないという感じです。Issueも砕けた表現が多く、暗黙的に大体知っているよねみたいなコンテキストで書かれている気がしました。
なので、まずIssueの内容が理解できなかったので、その対策を考えました。
用語表を作る
とりあえず、ドメインで使われている用語、変数名、意味の対応表をひたすら作っていきました。
コンポーネント志向なので、その階層も意識しながらひたすら書き込んでいきます。
そうすると明らかに同じ意味でありながら、違う変数名があったり、違う階層なのに名前が近いものなど不思議なものもいくつかありました。
そういう絶妙なものが理解を難しくしていたところもあり、それをはっきりと定義づけできるとやっとIssueの意味が理解できるようになりました。
コンポーネントを図にする
最後にIssueはデザインを修正するものだったのですが、意味が分かってもコンポーネントの配置関係がわからないと直せないなとなりました。
最初は開発者ツールでやっていましたが、同時の視認性が弱いなぁと思って、スケッチブックにページごとにコンポーネントの配置を書きました。
それで見ると、どこがデザインの要なのかがわかって、それでIssueの解法がわかりました。そこまでくると、他のIssueもやっつけられそうになったので、理解を終えました。
知見
Issue駆動でプロジェクトをとらえる
最初は漠然とプロジェクトを見ていましたが、「何を知りたいのか」「何を直したいのか」をはっきりと定義することで理解が加速した気がします。
それがIssueである必要はないと思うのですが、はっきりとした問いを立ててそこから理解するようにするとものの見方が定まるように思います。
用語を理解する
用語の問題がここまで大きいとはあまり考えていなかったです。バックエンドのロジックであれば、DDD的なものの見方が大事だと思っていたのですが、フロントエンドの部品もドメイン的な性質が大きいんだなと感じました。
名前と意味を正確に定義するということ、フォルダの切り方の大切さと、最初にそれを説明するのが結構大事なんだなと思いました。こういうのもREADMEにあってもいいのかもしれないですね。
手を動かす大事さ
見るとか、理解するという感覚は漠然としやすいです。なので、書くことが大事な気がします。
コンポーネント図を作っていると見やすいというのもありますし、能動的な頭の働きがあって、疑問とかも浮かびやすいです。なので、最近は複雑なことを始めるときは大抵紙から始めます。
Scrapboxとかに表を書くこともありますが、どちらにせよ見るではなく新しく作るのがいい気がします。
まとめ
今までライブラリとかを覗くことが多かったので、「今回も大丈夫だろう」という謎の自信があったのですが、実際業務レベルで理解するとなると戸惑うところが大きかったです。
これまではベストプラクティスの勉強が多かったのですが、そこにドメインが絡んできたり、デザイン回りの話が絡んだりで必要な見方が違ったんだろうなと思います。
その中で問題を整理しながら、理解のための手順を踏めたのはいい経験になりました。
あとから、Vue.jsのDevtoolsを使えば、もっと早かったのでは思いましたが、紙に書くのが少し楽になるぐらいの感じでしょうね。
新しくライブラリを見るときあたりに、こういう視点で見れたらまた知見がありそうなので、それもやってみたいです。
ポートフォリオ作りました
成果物
公開ページ（GitHub Pages） dexia2.github.io
ソース github.com
製作期間
構想：1週間
基本的な実装：5日
動機
エンジニアなのにも関わらずあまりOSS活動をしておらず、簡単な技術を証明する何かが必要だろうと思い立って作りました。
デザイン
デザイナーではなくプログラマーなので、なんとなく機械的というか2次元的な感触のデザインのほうがイメージに合うかなと思って、そうしました。
また、最初にレスポンシブ対応もすると決めました。ポートフォリオにたどり着く方の多くはPCでアクセスするような気もしましたが、技術力の一つとしてスマホ用のデザインが要求されることも多いので対応することにしました。
内容は業務経歴書などを参考にしました。
使った技術
- Angular6
- TypeScript
- Scss
- Angular Material
- Chart.js
- reset.css
大体、業務で使っている技術スタックそのままです。
デプロイ先
凝ったものではないので、GitHub Pagesを使わせてもらいました。
感想
AngularとAngular Materialが便利
静的Webサイトを作ったのは初めてなのですが、Angularから始めるととても楽でいいです。
TypeScript、Sassあたりのビルド設定、自動更新のサーバーを勝手に用意してくれますし、CSSもカプセル化されています。
それを自前でやることで技術力を見せるべきでは？と言われるとその通りなのですが、主題に早く入れるのはありがたかったです。
Angular Materialのパーツはレスポンシブデザインに対応していて、そのまま使えました。デザインは一部書き換えましたが、その方法もシンプルなのですごく楽させてもらいました。
技術的に遊べる
CSSはFlexbox、CSS Grid Layout 、アニメーションあたりを使って、すごく楽しんでいました。業務ではライブラリに投げている部分も多く、自前で組む楽しさがありました。
あとは色々な方のWebサイトを開発者ツールで覗きながら開発していたので、勉強になりました。
最近は常時、開発者ツールを開いて文書構造とCSSを当てるゲームをしていますが、結構楽しいです。
プログラマーの技量はあまり示せなかった
TypeScriptでガリガリ書く部分がそうそうなかったので、マークアップを頑張ったぐらいしか伝わらないなぁと感じました。
最近はCSSでできることが多くて、スクリプトで頑張らなくても大体のことはできました。
WebGLとかで表現を入れようかと思いましたが、自分のPCだとカクカクするので、あまり情報を見るためのサイトに使うのもどうかなという気持ちがあります。
今後
コンポーネント化の構想だったり、アクセシビリティだとかを含めてもう何回か見直すだろうと思います。
ただ、今回は無難に作りすぎたきらいがあるので、もっと遊んだものを作りたい気持ちがあります。最初は中国風のデザインを目指して、太極図や陰陽五行、八卦のアニメーションなどを作ったりしていましたが、レスポンシブ対応が辛くて諦めていました。
今回とりあえずの成果物を作れたので、趣味のほうも試せる環境にあります。なので、今後はちょっと遊びモードに入れたらなぁと思います。
まとめ
CSSやデザインの勉強がしたい人の題材として、ポートフォリオづくりはいいと思います。
早急にポートフォリオを作る必要がある人はAngularとAngular Materialを使うと、サクッとできて楽です。
最近取り組んできたこと（2018年4月～8月）
Web周り
表現方法の工夫
アニメーションへの興味がなぜか沸々とわいてきていたので、そこらへんを追求していました。
SVG
仮想DOMとSVGを組み合わせれば、独創的なUIがサクサク作れるとどこかで聞いたので、Angularであみだくじを作ってみました。
コンポーネント化したりとか、定数の外出しをしたほうがいいんでしょうけど、技術的な実験だったので1ファイル簡潔でさらさら書きました。
最初はdivと罫線で頑張っていたのですが、線に触れた時のイベントまわりが複雑になりそうだったので、SVGに転換しました。
line要素とか、直感的にマークアップを書けるのでよかったです。x軸、y軸の計算ロジックは増えたので、そこらへんは多少面倒でしたが。
CSSアニメーション
ローカルで色々と試していました。あんまり実例は残っていないですが、キーフレームあたりもちゃんと理解したので、ローディングとかは自前で書けそうなレベルです。
キーフレームとSVGを組み合わせてというのとか、あとはCSSの変数を使ってローディングの%表示をするというのが面白かった記憶があります。
3D
本を読んで勉強したり、APIのリファレンス、リポジトリを延々と眺めていました。
ただ、三角関数や頂点の計算などが合って、かなり数学的なにおいがして、手を出せていません。WebGLは直で触っても行けそうな感じはしましたが、three.jsとかのほうが情報量が多そうで悩み中です。
CSSでも簡単なものならできるらしいですね。
Chrome 拡張
Slackと連携したり、Amazonへのリンクを飛ばしたり簡単なものを実装しました。
地味に便利なことができそうと思いつつ、それ以降は触っていません。でも、簡単な割には可能性を感じました。
言語の勉強
Clojure
core系のAPIと実装を追うところまではやっていました。core.matchの実装が拡張ポイントを押さえていて気持ちいいなぁとか思っていました。
core.async、core.logicは使い方だけ抑えたところで終了。
APIとか実装を調査して記事を書こうと思ったのですが、思いのほか皆さん色々紹介してくれていたり、APIリファレンスが詳しかったりしたので、途中で挫折しました。
とりあえずClojureで書ける大まかな手法は理解できたんじゃないかと思って、ちょっと最近は別居中というかそんな感じです。
いろいろな言語に手を出す
なぜかいろいろな言語への興味がわいてきたので、手あたり次第に言語の勉強をしています。
どの言語も一度は勉強していたのですが、疎遠になっていました。Clojureを理解したあたりで、もう一度勉強し直してみるとなぜかすいすい頭に入ってしまって、はまってしまいました。
Pythonも以前見た時は普通じゃないか？と思っていたのですけど、今見ると色々そろっていてまぁ使いやすいよなぁと思ったり。
とはいえ、Clojureをまじめに触った時に本当に言語を学ぶときは集中して時間を書けるしかないと学んだので、どこかで絞るだろうと思います。
最近の流れだとPythonとGoですかね。言語的にはRustとScalaが好きですが、いかんせんそういう用途で書かないので。
ちなみに、自分は１冊の技術書を１日20ページ以上読めないので、分散しています。こういう読み方が単に好きなんですね。
勉強方法としては
あたりですかね。技術書を読んだ後、具体的なリポジトリを探してにらめっこが一番多いパターンな気がします。
今後
諸事情で趣味よりは技術的にやっていないところを補うことになると思います。
- GraphQL
- React/Redux
- WebSocket
- WebWorker
ここらへんと趣味のバランスが難しいですが、どこかでまとめてやらないとつらそうですね。
言語の勉強が楽しすぎて実用性より構文を眺めてしまうので、ちょっとそっちは休憩しないとかもです。
