How IT Works

プログラマーやっています。技術よりも人間学的なところが好きです。

仕事とステートマシン

何となく思いついたので、小ネタです。

仕事のとらえ方

仕事をしている状態をどういう認識でとらえるべきか?というのが最近の興味です。

この前の分析ではプログラミングという仕事はパターンの発見、繰り返し、組み合わせあたりで行っているのではないかなという仮説を立てました。

それと似たような見方として、ステートマシン(状態遷移)でも説明できるのではないかと考え中です。

簡単な状態遷移

例えば、単純な疲労度で言うと、

  • 元気
  • 普通
  • 疲れている
  • 限界

あたりの状態があって、1日の中でそれが変化しているという可能性はまぁまぁ高いです。その中で、状態ごとにできる振舞いがあって、遷移条件があると考えられます。

そこらへんを明確に定式化してとらえられると便利な使い方ができるの可能性があると思います。

応用例

思考に関しても、

  • 深く集中する
  • 広く注意を向ける
  • 機械的に判断する
  • 誰かの思考になりきる

あたりの状態があって、それを適当に切り替えているのではないかと思います。

それを意図的にどういう状態があるのか、どういう時にそれを使うべきか、どうすれば切り替えれるかを認識できれば、もう少し深いものの見方ができる気がします。

やりたいこと

要するに自分が仕事をしているときにどういう状態にあるのか、何ができるのかを知りたいなと思っています。

暗黙的な思考や状態をどこまで自分の管理下におけるのかというところで、言葉や概念にして説明できればいいなと。

ステートマシンの概念はその切り口として役に立ちそうなので、もう少し考えてみたいところです。

2018年振り返りと今年の抱負

2018年の反省

学んだこと

傾向

手を広げたがる

プログラミング言語に5個も手を出してたり、Vue.js、React、Angularのすべて動向をウォッチしているあたり、節操がないと言われても仕方ないと思います。

ここに書いていないものもとりあえずの気持ちで追っかけているので、実際にはもう少し多いですし。

パターンを見つけるのが好き

手を広げたがるのはパターンを読むのが好きだから、という感じです。

自分で新しいパターンを作るよりも、プロジェクトを探してその構造を解析する読むほうが好きなんだなと今年気付きました。

1から新しいプロジェクトを作るよりも、色んなパターンを組み合わせてバランスをとるような物の作り方をしていて、今年はその傾向が特に強かったような感じがします。

技術以外のパターンについて

人についても比較的パターンを見つけて、それを自分の糧にするような学習方法だった気がします。

例えば、

  • あらゆることを計算式で表現できる形に直したい人
  • コードのすべてのパスに対して、テストを書きたがる人
  • あらゆる説明を図に書いて、紙で説明する人
  • テストをするときはユーザーの気持ちに完全になり切る人
  • すべての作業に対して新しいツールで楽できないか考える人

こういう人たちが周りにいて面白いなと思ったので、時々こういう思考を意図的にトレースして、使ったりしていました。

どちらかというと郷に入っては郷に従えで、その人と話しているときに合わせるケースが1番多い感じでしょうか。

課題

2018年を総括すると、色んなパターンを見つけてはその場に合ったものを選ぶ、というような能力を磨いてきた1年だったかなという風に思います。

なんですけど、今のやり方は例えるなら、職場のコードのパターンを見つけて、それに溶け込むようなコードを書くという使い方で、どうかなぁという気持ちがあります。

仕事ではVue.jsを書いていて、エディタはVSCodeなんですけど、職場で使っている人が多いからぐらいの理由しかないです。

VimEmacsLispあたりの勉強で身に着けたキーバインド、REPL駆動、その他諸々がつながっていないんじゃないかという感覚があります。

2019年の方向性

考えてみるとパターンを覚えて、それを活かすというやり方は中学生ぐらいから鍛えてきたものなので、今から戦う武器としてはまずこれを前提に置くべきなのかなという気持ちがあります。

そのなかで色んなパターンとか能力をどれだけ越境できるのかを考えてみたいなと思います。

パターンを認識してそれを使うというのはそこまで意識的にやっていなかったので、自分の中で言語化したり、課題を考えたりして、もう少し意図的に使ってみるというのが今年の課題ですかね。

技術的にはGraphQLとWeb Workerあたりには手を付けてみると思います。あとは、RailsRubyを業務で使えるまでは慣れたいです。

途中参加のプロジェクトに慣れるまで

近況

 最近、これまでとは違うプロジェクトに途中参加することになって、大きな環境の変化に対応する日々を過ごしていました。

 これまではフロントエンド・バックエンドの両方を触っていましたが、今はほぼフロントエンド専任です。

 技術的にはNuxt.jsが中心で、Angularに似ているとはいえ、その違いを吸収するのに時間を使っていました。

 事前にNuxtとVueの情報を拾っていたので「たぶん、行けるだろう」と思いきや、プロジェクトの理解に半日ぐらいかかって、自分の中で困惑することが多かったので、その知見を書いてみようと思います。

プロジェクトを理解するまで

実際の画面を触ってみる

 参加するころには大体の画面はできていたので、とりあえず何も考えずに触ってみました。ある意味、ユーザー目線に近かったので、この時の気持ちを書いておけばよかったのでは、と今更ながら思ったりします。

 何となく20分ぐらい触って大体の機能を拾っただろう、とこの時点では思っていたのですが、ここで開けなかったページがあったみたいです。

 手探りだと体系的にはいかないですね。ちなみに仕様書はあったそうですが、「最初は書いていたけど、更新されている自信はない」といわれたので、あまり確認していません。

フォルダ階層をざっとみる

 Nuxtは基本階層が決まっているので簡単かなと思ってみていました。

 2階層目以降は、スマートフォンと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であみだくじを作ってみました。

github.com

 コンポーネント化したりとか、定数の外出しをしたほうがいいんでしょうけど、技術的な実験だったので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が好きですが、いかんせんそういう用途で書かないので。

 ちなみに、自分は1冊の技術書を1日20ページ以上読めないので、分散しています。こういう読み方が単に好きなんですね。

 勉強方法としては

 あたりですかね。技術書を読んだ後、具体的なリポジトリを探してにらめっこが一番多いパターンな気がします。

今後

 諸事情で趣味よりは技術的にやっていないところを補うことになると思います。

  • GraphQL
  • React/Redux
  • WebSocket
  • WebWorker

 ここらへんと趣味のバランスが難しいですが、どこかでまとめてやらないとつらそうですね。

 言語の勉強が楽しすぎて実用性より構文を眺めてしまうので、ちょっとそっちは休憩しないとかもです。

Clojureを歩いている

前書き

 昨年9月ごろからLispを勉強しています。

 Lispを1か月勉強して - How IT Works

 最初はCommon Lisp、途中からEmacs Lispを経たりして、今はClojureを勉強している感じです。

 以前は「リーダマクロがない?、引数はベクターで受け取る? そんなの邪道だ」と思ってCommon Lispを中心に考えていましたが、今はClojureの設計はとてもきれいだと思って、その考えをとりあえずできる限り盗もうと思って頑張っています。

 Clojureのimmutabilityあたりにちょっと詰まりましたが、それさえ乗り越えれば、Clojureはとてもシンプルで使いやすい言語だと思います。

 逆に言うとClojureはなんとなく使いやすい言語で、なんとなく書けるのでその先に行くには意識的な努力がいるんじゃないかなというのが今の感想です。

 だから、最初はとりあえずなんとなく書きたいものを書いて、読みたいものを読むというスタンスでしたが、計画的に努力するように心がけているところです。

勉強のメディア

プログラミングClojure

 最初は本を読んで勉強していました。

 「プログラミングClojure」は日本語の中では一番まとまっていてよかったです。改めてみるとつまみ食い感がすごい気もしますが、大事な情報がきちんと入っていて3回くらい読み直しました。

 今ならちょっと古いのかもしれませんが、選択肢があまりないので導入なら問題ないかなと思います。

プログラミングClojure 第2版
Stuart Halloway and Aaron Bedra
オーム社
売り上げランキング: 346,168

Clojureによる、初めての関数型プログラミング

 基礎を固めた後としてはこれがよかったです。とてもシンプルな設計でどうやってアプリを作っていくかを学べてよかったです。

 全体としてみてどうかといわれると難しいですが、細かいテクニックとかはこれで覚えた気がします。

Clojureによる、初めての関数型プログラミング
gpsoft (2013-09-28)
売り上げランキング: 64,595

Clojure Programming

 ちょっと学んだらあとは英語で頑張れというのがClojureですが、洋書のなかで1番好きなのはこの本でしょうか。

 一つ一つの概念について丁寧にページを割いて説明してくれていて、構文への愛があります。多少古いので最先端ではないのかもですが、Clojureを学ぶという意味ではとても好きです。

 洋書であればWeb、機械学習に絞ったものなど色々ありますが、自分はきちんと基礎から学びたいタイプなのでそういう系はあんまり肌に合っていない感じはします。

 関数型、リアクティブプログラミングの設計あたりは次あたりに読んでみようかなぁと思っています。

Clojure Programming
Clojure Programming
posted with amazlet at 18.04.21
Chas Emerick Brian Carper Christophe Grand
Oreilly & Associates Inc
売り上げランキング: 69,016

Web

Git Hub

 最初はClojureのTrendのリポジトリを眺めていました。

 Trending Clojure repositories on GitHub today · GitHub

 でも、ClojureのTrendは毎日ほぼ変わらないですし、上がってくるのはほぼデータ系でこれだけに頼るのは厳しいですね。感覚的にはRubyとかJavaScriptあたりだと変動が大きくて面白かったんですけどね。

 勉強が目的なら、Clojureの公式のリポジトリをめぐるほうが楽しいと思います。

 github.com

 その先の調べ方はあんまり考えていないので、今発掘中です。

Clojure Docs

 Clojure Docsを眺めるのも勉強になってよかったです。APIにどんなものがあるか眺めるのも楽しいですし、サンプルを自分なりに作り直してREPLで叩くのも楽しいです。

Community-Powered Clojure Documentation and Examples | ClojureDocs

 Clojureは細かい関数、マクロが多いので時々API一覧を見て不要な処理を本当に書いていないのかを確かめるのがいいと思っています。

その他

 Qiitaとか、ブログとかはちょいちょいありますが、あまり更新されていないので主要な情報源にはならないかなぁという印象はあります。

 Clojure界隈にはとても優しい方々がおられるので、そういう人たちと仲良くしながら情報がないかアンテナを張っておくほうが大事かなぁと思います。

おすすめされた情報源

 一応自分なりの勉強方法はあったものの百戦錬磨のClojurianたちはどうやって勉強されているのか聞いてみました。

 redditとMLは確かに毎日眺めるにはちょうどいい感じでした。

 Podcastなどはいくつか聞いてみて、意外に英語でもプログラミング系ならわかりました。ただ、通勤しないので、聞くタイミングがなかなか作れないのでもう少し考えたいです。

 transcriptsはかみ砕きながらみないと難しいですが、研究材料としてはこれ以上なく楽しそうでした。

勉強の方法

REPL it

 やはり書くことが一番の勉強だと思っていて、本でもWebでも面白いものを見つけたらREPLに打ち込んで改変してテストするのが一番よかったです。

 マクロあたりもずーっと読んでいるだけではわからなかったものの、色んなパターンをうちこんでもう最近は間違えないですね。

テーマをもってやる

 前にも書いたのですが、Clojureは自分の思うように書きやすすぎるので特定の構文を使わなくても意外に何とかなります。自分だと、

 とかは別に自分で書かなくても何とかなるというところがあって、やっぱり時間をとって研究しないといけないなという風に思っています。

 そのためには何かアウトプットを書くといいのかなと思って、Qiitaとかにあげたりしています。正直、Clojurianの方々から見るとミスリーディングなどが多くて恐れ多い部分もありますが、それを自分だけで認識できないので開き直ってアップするという感じです。

 今のところこんな感じです。

Clojureの長めのマクロを読む - Qiita

Clojureのクォート - Qiita

メタ・テスト - Qiita

 Clojure公式リポジトリの構文上の比較研究が多いですが、いずれはライブラリ、プロジェクトあたりの研究をして、それが終われば自分なりの形を作れればいいかなと考えています。

 Clojurianへの道は遠いですが、自分は少しずつ進むほうが性に合ってそうなので、地道にやっていきます。

まとめ

 ClojureC#とかJavaScriptに比べて日本語の情報量が少ないので、より情報を得る手段が洗練されてきている気がします。

 実務はLispではないので、きっちりこのやり方をそちらにもフィードバックしていけたらエンジニアとしてのランクがちょいと上がるかなぁとか考えます。

 最近は実用物はあんまり考えていませんが、Lispの長い歴史を追いながらエンジニアはどういう風にしてきてこれからどうなっていくのだろうかというところにも興味があり、どうしようかは迷っています。

 ただ、今とても楽しいのでもう少しだけ、研究という体で学んでいきたいです。やり方がガラッと変わったら、また何か書きます。

最近取り組んできたことの振り返り(2017年末~2018年3月)

動機

 思い返すと、2017年末くらいから色々とコードを書くようになって、それなりに形にできたのでその振り返りをしたいなと思います

やってきたこと

配球ゲーム

github.com

 バドミントンの配球を2次元に落とし込んで読み込んでみようという試みで書いたシミュレーションです。製作期間は2か月足らずくらいでしょうか。

 細かいところは大体Qiitaに最近は書いているので、技術的なところはそこを見てもらえれば。

ClojureScriptで配球予測ゲームを書いてます - Qiita

 感覚的なところで言うと、これが一番収穫だったかなぁという印象です。

 Lisp系の言語を使ってそれなりに知見を貯められたとかそういうところもありますが、自分の思考とプログラムを近づけるということが一番自信を持ってできたというところで価値があります。

 表現が伝わるか難しいですが、ライフハックそのものではなく思考を拡張することこそがシステムの価値じゃないかという思いがあって、 そこに踏み込めた第一作としてはとてもよかったです。

統計ごっこ

github.com

 バドミントンのいいデータセットが見つからなかったので、とりあえず人力でJSONを書いてそれで分析していました。

 1試合どころか1ゲームで6時間かかったので、途中でまじめにやるのは無理だとわかりました。

 分析結果は一応他のブログに書きました。

バドミントン・メモ:女子シングルスを数値で見る

バドミントン・メモ:女子シングルスを数値で見る2

 簡単な分析であってもそれなりの知見が得られることはわかって、その点では満足でした。

 ただ、複雑な分析をする手段をもっていないので、そこが足りないのかなと思いました。ストローク同士の関連を見たり、複雑な相関を見る道具がそろっていないのは実感しました。

 Rとかを触ればいいのかなぁとか色々模索はしていますが、結論は出ていないです。

 また、データセットをとるためには、たぶんYoutubeAPIとOpenCVを組み合わせたりして自分でやるしかない気がしていますが、そこまでの価値があるのかちょっとわからないので、保留中です。

指示出し器

github.com

 何も考えずに買ったAmazon Echoを買いました。

 練習の指示を出したら楽しいんじゃないかと思って、指示を出してくれるスキルを作りました。

 でも、Alexaは対話型なので、一方的に話しかけてほしい自分の願いはかなわなさそうだったり、そもそも音声に反応する練習を積んでも意味がないのではと思い作って終わりです。

 ついでに作ったメモ用のスキルのほうが役になっています。

GitHub - dexia2/MemoSkill: Slackにメモを保存するスキル

Alexaを使ってSlackにメモを保存する - Qiita

 練習メニュー管理、量の記録あたりなら役に立つかもですが、ちょっと考え中です。練習テーマあたりを言ってくれたらうれしいかなぁ。

 可能性は感じましたが、まだ積極的には生かせていないです。

書籍管理

Google Apps Scriptで書籍を管理する - Qiita

 珍しく実用品を作りました。

 とはいえ、似たようなサービスはもうあるらしいので、技術の実験的なところですね。Google App Scriptは便利で自分のような個人用作品を使うにはまぁそれなりに使えそうでした。

 やる気がないところをやる気がないなりに成果を出すというところでは最高です。

振り返ってみて

 やはり一番よかったのはProcessingで遊んだ配球ゲームですね。

 機械学習や統計、画像処理をやることで他の人に貢献できるんじゃないかという気持ちはあるのですが、自分の感覚とどれくらい一致するか?というところを考えるとビジュアライゼーションの優先度が高いかなぁという気がしています。

 あるいは練習管理が結構大事で、練習のテーマ管理、テスト管理、あとはモチベーション管理あたりが課題になっていて、そこらへんの心理的側面をどれだけシステムで行けるかなぁというのが今の気持ちです。

 いろんな技術をまたげるようになってきた感じはしますが、まだ本質に近いものを量産できていないので、そこにまた近づけたらいいなと思います。

 それはさておき、Git HubとQiitaはエンジニアのInstagramとは言いえて妙ですね。本当にそんな感じです。