私がいる事務所は調布ベースという名前になりました。調布の駅近にありますが、具体的な場所は非公開です。大学に入った時に調布に来て以来、ほぼ調布にいます。駅、市役所や病院など町の機能がコンパクトに収まり、かつ混みすぎないので快適な町と思って気に入っています。開発でも、近くにある電通大の学生がアルバイトに来てくれていて、とても助かっています。そんないい町、調布のお店を紹介します。今回は「海南記」という中華料理屋さんです。中国の人がやっています。中国語はよくわかりませんが、たぶん中国語で店員さんが話していたり、たぶん中国語の音楽がかかっていたり、回転する丸テーブルがあったりと、雰囲気もそれっぽいです。夜は行ったことありませんが、ランチは680円でしっかり食べられます。日替わりメニューといつものメニューがあります。食レポみたいに上手いこと書けませんが、美味しいので週一くらいで行ってます。社内勉強会こんにちは。調布ベースでは、だいたい月に1回、社内で勉強会を開いています。開発等に関して、みんなでネタを持ち寄って発表しています。今日も夕方というか夜にやっていました。私は好きでネタも考えますが、こういうのは好きな人そうでない人、また意味があると考える人もいれば無駄と考える人もいます。そのあたりを少し整理しようと思います。勉強会で何を狙っているか私は「やろうよ」と声をかけることもある身として、以下を考えています。見つけたネタを共有できたら楽しい。自分もそうだし、同じように考える人がいたら聞いてみたいなまっすぐに自分の業務の内容だけ調べていると刺激が薄れるので、変わったネタを仕入れたい。他の人にもそんな刺激ができたらいいな。普段は、特に学生は時間がばらばらなことも多いので、たまにみんなで集まって楽しく話したりしたいなネタと言っても、私はあまりクオリティの高いネタを用意できないので、緩くでいいかなと。一方で、他に参加する人にはその人たちの思惑もあってしかりと思います。ちなみに、うちでは自由参加で時給が出るので、決して自主性を重んじて云々みたいな綺麗ごとだけの会ではないと信じています。それより作業を進めてさっさと帰りたいと思うこともあれば、みんな出てると断りずらいなと思うこともあると思います。技術力向上させたいと思って会をひらくなら、研修の形をとるのが良いはずです。研修も充実させたいとも思っています。その点、「研修やるぞ」と構えるほどではなく「こんなのあるよ」と伝える機会が持てているのは、ありがたく思っています。いえ、研修にするならするで、私自身も時間の使い方に気を付けないといけませんね。無駄にしないために結局のところ、活かすかどうかはその後どうするかだと思います。聞くだけだった人は、その後で自分で実践したり練習したりして自分のものにする時間と労を投入しない限り、ただ聞いただけになります。「その後」が次の日でなければいけないと考えすぎると、しんどいですね。半年後に「そういえば」でつながることもあると思います。その点を考慮して、時間や頻度など調整していく必要があると思っています。緩く行けるといいなという点と、やるからにはという点と、いつも考えています。楽しく、まじめにうじうじ考えるだけの駄文になってしまいました。僕としては、学んだり挑戦しようとする人は支援したいです。いうところはまじめに行きたいです。できたら、楽しくできたらいいなと思います。リリースとサポート状況RHEL8がリリースされたようです。8いつも通り、評価版は期限付きで無料で試せるようです。違いをまとめたブログ記事を見つけました。早くも消えたりと、また変化がありますね。アナウンスはありません。いつも少し遅れて出てきます。バージョンとサポート状況はこんな感じです。フェーズは、RHELのサポートサイト上でドキュメント等は残っていますが、セキュリティ修正も提供されないフェーズです。考慮した実装やテストは行いません。実際の利用状況や、技術的な状況を加味して早めに切り上げることもあります。2年の周期でメジャーバージョンが上がります。メジャーバージョンが1つ古くなってから1年は通常のサポートに含まれます。メジャーバージョンがリリースされてからだいたい3年のサポート期間があります。LTSつまり、最長で5年程度のサポート期間があります。2020年6月末までとなります。システムによりメジャーバージョンのアップグレードが可能です。入れ直しを必要としないので、あまりLTSをあてにしすぎずにアップデートしていくことを考えています。切れたバージョンはサポート外としています。対応していませんが、対応させていきます。現時点ではまだ具体的な予定日等は確定していません。サポートから外れていきます。大学の授業で広く使っていただけるようになり、サービスの停止時間を確保することが難しくなってきている学校もあります。一方で、安心して利用し続けていただくためにも現在の技術動向に対応していったり、セキュリティアップデート等のメンテナンスは必要になります。やりくりの難しいところもあるとは思いますが、システム管理者や利用者の方々と協力して、維持していけたらと思います。古いコードとの闘いこんにちは。画面は一昨年にデザインを改めましたが、まだまだ古いままの画面も残っています。利用者からは統一感のなさを指摘いただく機会も多々あり、至らなさを感じるところです。ここでは画面の置き換え、もしくは機能の入れ替えについて、開発チームで共有しておきたい全体的な方向性についてまとめておきます。一番に想定している読者は開発チームです。新機能の開発についてはここでは扱いません。直すつもりはあるのか?もちろんです。使いやすい・わかりやすい画面、もしくはより便利な機能に改めていきたいと考えています。小さなチームでの開発ですのでリソースの問題は常に付きまといます。いざ取り掛かるにあたり、どう直したらいいのかというのが次にぶつかる問題です。残念ながらやみくもに手当たり次第に取りかかれるわけではない中で、どう切り崩していこうかと常に考えたり、情報収集しています。開発で常に意識している点は以下です。できる限り多様な環境で利用できることわかりやすく汎用性の高い、シンプルな画面・機能であること素早く変化し続けること安くあること連携コース画面のデザインを改めた際に目指した、主に利用者目線の点は以下です。画面を直すにあたり、コードの設計も改めていっています。開発目線の点は以下です。活用に積極的な方が多くありました。様々な機能をそろえることができました。利用が浸透し、先生方に教育でのシステム利用に興味があるなしに関わらず、学校設備の1つとして広く授業で使われるようになってきています。学生の方もとりあえずスマホでアクセスするのが当たり前になってきています。普段から利用する先生が増えるに従い、システムの不具合があった時に与える影響も大きくなっています。先に取り組んでいたのは学生のスマホ利用への対応、ソフトウェア開発工程とソフトウェアテストの改善、セキュリティ実装でした。そこからさらに一歩進める改善が、一昨年からの新画面の取り組みです。今ではあまり高度な機能がありすぎても、普段ちょっと使うにはかえって扱いづらいと感じられるケースが増えています。利用端末もスマホだけでなくタブレットが加わり、学生が使うかと思いきや先生もタブレットで利用するケースがあり、とても多様化しています。セキュリティについても、ますます重大なテーマとなっています。勉強の手引き」という記事をちょうど書いてくれました。書き直しでうまくいくかというと、経験的にはそう簡単に行きません。見た目の整理は取り扱う情報の整理になるので、結果的にはプレゼンテーション以前のデータ構造やデータの受け渡し経路を見直す必要が出てきます。したい場合、JSONデータインタフェースの実装が必要になるので、当然ながらインタフェースの拡張が必要になります。これらはセキュリティ実装でも同じことが言えます。したがって多かれ少なかれリファクタリングをすることになります。利用者から見えないリファクタリングに時間を食われるのをもどかしく思うこともありますが、私は画面の改善でリファクタリングが必要になるのは好機と見ています。素早く確実にソフトウェアを改善し続けるためには、コードの保守性は重要です。これまで画面を変えられなかったのは、その様なコードの体制がなかったのも原因の1つです。コードの問題は画面の改善だけでなく、テスト可能性やテストのコストにも反映されます。幸いなことに、コードの設計は手本になる本やオープンソースのライブラリやプロダクトが多数あります。したがって、何を実現するかがはっきりしていれば解は比較的見つけやすいです。基本的には良いパターンを使いまわしていきます。一か所で何とかすれば、同じような個所を一気に片付けることができます。その後は維持しやすくなると期待できます。見た目・機能の改善コードベースの問題を乗り越えて実質的な機能修正に取り組むにあたり、一番問題になるのは「本当に使いやすいのか?」という点です。コードの良さは計測しやすく、開発チーム内でコンセンサスが得られればOKという意味で、評価しやすいです。画面や機能について利用者がどう思うかは計測・確認がしにくく、いろんな利用者がいてコメントの方向性が定まらないケースもあります。仮にいい画面になったとしても、慣れの問題が付きまといます。出た当時はいろいろ言われていましたし、私も「なんで?」と思いました。従来のメニューでは一通りの機能を本当に扱いきれなかったのかどうか私には評価できませんが、今では慣れて特に問題なく使っていますし、スタイルの適用などはUI表示域の広さと表示される情報とが程よく、便利だなと思っています。真似しやすいコード設計に対して、UIや機能の設計は基本は考えてひねり出すのが良いと思います。利用者のコメントはありがたい参考資料になりますが、そのまま受け入れるだけだとブレます。特定の利用シナリオにぴたりと寄り添うほど汎用性を失って、オプションを必要としてしまいます。オプションも加えれば加えるほど動きがわかりにくくなり、テストやマニュアルの周辺作業が積みあがってしまい、機能を洗練させる時間を取れなくなります。したら良い機能や画面をひねり出せるか、これは私もいつも悩む問題です。ここは、いろいろ聞いたり試したりするしかないと思っています。先生がどんな状況でどんなことをしようとしているか、というあたりでしょうか。あるなしに関わらない、もう少し根本的なシーンやシナリオが見えてくると、考えやすいです。特定のケースに固執しすぎては汎用性を失います。ここが難しいといつも思います。その時ごとにテーマや課題があり、常に変化・対応し続けていきます。今いいものも、2年後には利用環境と乖離して使い物にならなくなっている可能性もあります。それどころか、後になって昔の機能の価値を再発見してしまうこともあります。いう意味で、コードベースの改善も画面・機能の改善も果てがなく、あまり考えすぎてしまってもしょうがないところがあります。私たちはアジャイルなソフトウェア開発の仕方を取り入れています。小さく手堅い修正を素早く重ねて行く作戦です。画面の置き換えも、表には見えないリファクタリングだけ先に進めたところもあります。その中で、試したけど捨てたコードも多数あります。いいと思って採用したけど、思ったようには行かなかったコードも多数あります。これらは「うまくいかない」ことがわかった成果として無駄ではなかったと思っています。いずれにせよ、多くの利用者が使うシステムでは「パパッと作って何とかなる」とは行きにくくなります。タイムリーに新機能や改善を提供し続けるためにも、普段からリファクタリングや試行錯誤を常にやり続け、そして学び続け、堅実なコミットを積み重ねていきます。