旧サイト記事の移行
年明けの勉強会の予習というかメモ書き。 クロコラボ #20 headタグの中を考えてみよう 少しずつ書き足していきます。 文書メタデータ（ヘッダー）要素 文書レベルメタデータ要素 Qiita:色々あるHTMLのmetaタグなど一覧 JavaScriptはhead内で読み込みたい 結論としてはhead内で良さそう。 Document metadata - HTML 5.2 W3C Recommendation, 14 December 2017 headタグの短い例 headタグの長い例 文書レベルメタデータ要素
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
読書会のときは、以前に手掛けたAndroidのカメラアプリが頭の中にあって、機種依存で苦労したことを考えていたのですが、今思えば他の仕事（ウェブサイト）でも派生させてそのままになっているコードも存在していて、このあたり一つに集約する努力が足りていないなぁとあらためて反省。 今、この記事を書きながら考えているのですが、共通部分を派生させて使いまわすのではなくて、共通部分を完全に分離して、汎用的に使えるように作り込めば良いはず。今、すでに複数のプラグインでメンテナンスが必要になっている部分を切り出して汎用化する方向で検討してみます。
旧サイト記事の移行
明日の勉強会の準備。メモ書き程度です。 1.5.1 Herokuのセットアップ このあたりの作業中。 ndenvのnpmをインストール済みなので、
$ npm install -g heroku-cliを試したところ、npm WARN ... 'heroku-cli' has been renamed 'heroku' と表示されたもののインストールはできた様子。 それと、cross-spawn no longer requires a build toolchain, use it instead という警告もあり。 cross-spawn-async cross-spawn
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
ここでは失敗事例が結構なまなましく語られていて、とても強い気持ちが感じられるセクションです。規模の大きなシステムで長期間にわたって開発が続く場合、期日にまとめてリリースしようとしてたいていの場合失敗する。しかも、数ヶ月とか1年が過ぎると、そもそもの要望が大幅に変わって来たり。スケジュールが大幅に遅れて、かなり無理をして新たなシステムに移行したものの、個々の機能にあれこれ問題が発覚して、そのような状況で大幅な変更とか、まぁ対応できるわけがありません。ですが、なんだかよく聞くようなストーリーです。 直前の「本物の顧客参加」にもつながりますが、部分的にでも使える状態にして、実際に使ってもらって、そのフィードバックをもとに次の機能を進めていく。その積み重ね。問題があれば、速やかに対応。日数が経過してからだと、対応にも時間がかかったりしますが、そうでなければ対応も比較的楽ですよね。そうして、ちゃんと機能するものが積み上がっていって、しかもこまめにフィードバックも得ているので、あるタイミングで大幅な変更で混乱、という事態にもなりにくいと思います。あるいは、多少大きめの変更が発生するとしても、それまでの実績があるので、その時点での変更コストが見通しやすい。
旧サイト記事の移行
この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。
メトリクスが気づきにつながることもある
読書会のときに「数値化できていないなぁ」と書いておきながら、今、この記事を書きながら実践できていない（放置状態）ことに気がつきました。何か方法を考えないと… Git Webフック このあたりを活用してみるか… といいつつ、何もないところからスマートに行こうとして、結局何も進まないことになりそうなので、コミット履歴をもとにして、数値化できるものを手で拾うところから始めてみます。 さて、プラクティスのマッピングについて。 なるほど、気になるキーワードを書き出して、絵にしてみれば良いんですね。読書会の当時は、あまりピンときていなかったのですが、今になって腹落ちした感じです。普段だと、キーワードとか何か言葉なり文章なりを書くとしたら、こういうブログ記事でもそうですが、エディタとかで整然と書くだけで、それでは変化がなくて発見につながらない。そうではなくて、紙の上に向きや形を変えながらキーワードの関係を手で描いてみる。それを共有することでさらなる発見につながる。という感じですかね。 ところで、この一連の読書会のふりかえりをしていて思ったのですが、一度読むとなかなか自分では解釈を変えられない、というか、思い込みのまま読み過ごしてしまうことが多い、ということです。せっかく良いことが書いてあっても、勘違いしたままで、後で読み直しても、最初の解釈のままだったり。あるいは、なかなか頭に入ってこないセクションがあったとして、やはり後で読み直しても同じ感じで、そのままやり過ごしてしまうとか。もちろん自分の読解力の問題もあると思いますが、でもこういう読書会であれば「自分はこう思うんだけど…？」と投げかけてみることで違う解釈が聞けたりすると学びになりますよね。 あと、最近気になるのはアジャイルが △△ vs ○○ という構図で表現されることが多くて、アジャイル手法だと □□ だから注意しないといけない、というコメントなど。XPとかアジャイルとかの本で書かれているのは、過去の様々なプロジェクトでいろいろ問題があって、どこも同じような問題を抱えていて、それをどうやって改善してきたか、どうすればみんなが少しでも幸せになれるか、というノウハウの集大成のようなものだと思っています。もちろん、こうすれば必ずうまくいくということではなくて、状況に応じて何を適用するかという判断も必要と思います。ですが、アジャイルを否定するためのあら探しをしたところであまり生産には結びつかないと思います。もちろん、何か問題点に気がつけば対策を考えるなり改善していけば良いわけで。 それと、自分の組織やチームの中だけでは気がつかないことも多く、こういうコミュニティの中でディスカッションすることで、いろいろと気づきや改善、プラクティスにつながったりするんだと思います。 自分に言い聞かせるような感じで、なんども同じことを書いている気がしますが、ご容赦のほど。 今日はこのへんにしておきます。