こんにちは。福岡です。
私がいる事務所は調布ベースという名前になりました。調布の駅近にありますが、具体的な場所は非公開です。
大学に入った時に調布に来て以来、ほぼ調布にいます。駅、市役所や病院など町の機能がコンパクトに収まり、かつ混みすぎないので快適な町と思って気に入っています。開発でも、近くにある電通大の学生がアルバイトに来てくれていて、とても助かっています。
そんないい町、調布のお店を紹介します。今回は「海南記」という中華料理屋さんです。
たぶん中国の人がやっています。中国語はよくわかりませんが、たぶん中国語で店員さんが話していたり、たぶん中国語の音楽がかかっていたり、回転する丸テーブルがあったりと、雰囲気もそれっぽいです。
夜は行ったことありませんが、ランチは680円でしっかり食べられます。日替わりメニューといつものメニューがあります。
食レポみたいに上手いこと書けませんが、美味しいので週一くらいで行ってます。
こんにちは。福岡です。
調布ベースでは、だいたい月に１回、社内で勉強会を開いています。開発等に関して、みんなでネタを持ち寄って発表しています。今日も夕方というか夜にやっていました。
私は好きでネタも考えますが、こういうのは好きな人そうでない人、また意味があると考える人もいれば無駄と考える人もいます。そのあたりを少し整理しようと思います。
私は「やろうよ」と声をかけることもある身として、以下を考えています。
ネタと言っても、私はあまりクオリティの高いネタを用意できないので、緩くでいいかなと。
一方で、他に参加する人にはその人たちの思惑もあってしかりと思います。
ときどき気になるのが、他の人は負担ばかりで出たくないと思っているんじゃないか？ という点です。
ちなみに、うちでは自由参加で時給が出るので、決して自主性を重んじて云々みたいな綺麗ごとだけの会ではないと信じています。ですが、それより作業を進めてさっさと帰りたいと思うこともあれば、みんな出てると断りずらいなと思うこともあると思います。
技術力向上させたいと思って会をひらくなら、研修の形をとるのが良いはずです。もう少し研修も充実させたいとも思っています。その点、「研修やるぞ」と構えるほどではなく「こんなのあるよ」と伝える機会が持てているのは、ありがたく思っています。とはいえ、研修にするならするで、私自身も時間の使い方に気を付けないといけませんね。
結局のところ、活かすかどうかはその後どうするかだと思います。特に聞くだけだった人は、その後で自分で実践したり練習したりして自分のものにする時間と労を投入しない限り、ただ聞いただけになります。
ただ、「その後」が次の日でなければいけないと考えすぎると、しんどいですね。半年後に「そういえば」でつながることもあると思います。その点を考慮して、時間や頻度など調整していく必要があると思っています。
緩く行けるといいなという点と、やるからにはという点と、いつも考えています。
うじうじ考えるだけの駄文になってしまいました。
僕としては、学んだり挑戦しようとする人は支援したいです。そういうところはまじめに行きたいです。でもできたら、楽しくできたらいいなと思います。
いつも通り、評価版は期限付きで無料で試せるようです。
v7 からの違いをまとめたブログ記事を見つけました。
ntp パッケージが消えて chrony に統一されたり、出来たと思ったところの firewald が早くも消えたりと、また変化がありますね。
CentOS については、まだ v8 のアナウンスはありません。いつも少し遅れて出てきます。
RHEL のバージョンとサポート状況はこんな感じです。
いろいろフェーズがありますが、WebClass がサポートを続けるのは Maintenance Support 2 までです。この後のEnd of Extended Life-cycle Support フェーズは、RHELのサポートサイト上でドキュメント等は残っていますが、セキュリティ修正も提供されないフェーズです。RHEL6 はEnd of Maintenance Support 2 の期限が 2020/11/30 までとなっています。
WebClass についてはこれ以降は RHEL6 を考慮した実装やテストは行いません。また、実際の利用状況や、技術的な状況を加味して早めに切り上げることもあります。
Debian は2年の周期でメジャーバージョンが上がります。メジャーバージョンが１つ古くなってから1年は通常のサポートに含まれます。つまり、メジャーバージョンがリリースされてからだいたい3年のサポート期間があります。
その後は LTS (Long term support) が2年カバーします。
つまり、最長で5年程度のサポート期間があります。
現在カレントバージョンである Debian9 は 2022年6月末まで、1つ前の Debian 8 は 2020年6月末までとなります。
Debian は apt システムによりメジャーバージョンのアップグレードが可能です。入れ直しを必要としないので、あまりLTSをあてにしすぎずにアップデートしていくことを考えています。
いずれにせよ、WebClass は LTS の切れたバージョンはサポート外としています。
RHEL8 にはまだ対応していませんが、対応させていきます。ただし、現時点ではまだ具体的な予定日等は確定していません。
一方で、OS ベンダーの方でサポート切れになっている OS もまた、WebClass のサポートから外れていきます。
WebClass もだんだんと大学の授業で広く使っていただけるようになり、サービスの停止時間を確保することが難しくなってきている学校もあります。
一方で、安心して利用し続けていただくためにも現在の技術動向に対応していったり、セキュリティアップデート等のメンテナンスは必要になります。
やりくりの難しいところもあるとは思いますが、システム管理者や利用者の方々と協力して、維持していけたらと思います。
こんにちは。福岡です。
WebClass の画面は一昨年にデザインを改めましたが、まだまだ古いままの画面も残っています。利用者からは統一感のなさを指摘いただく機会も多々あり、至らなさを感じるところです。
ここでは画面の置き換え、もしくは機能の入れ替えについて、開発チームで共有しておきたい全体的な方向性についてまとめておきます。一番に想定している読者は開発チームです。また新機能の開発についてはここでは扱いません。
もちろんです。使いやすい・わかりやすい画面、もしくはより便利な機能に改めていきたいと考えています。
ただし、小さなチームでの開発ですのでリソースの問題は常に付きまといます。また、いざ取り掛かるにあたり、どう直したらいいのかというのが次にぶつかる問題です。
残念ながらやみくもに手当たり次第に取りかかれるわけではない中で、どう切り崩していこうかと常に考えたり、情報収集しています。
WebClass の開発で常に意識している点は以下です。
コース画面のデザインを改めた際に目指した、主に利用者目線の点は以下です。
画面を直すにあたり、コードの設計も改めていっています。開発目線の点は以下です。
2000年代のころは大学で LMS を使っていただく方は、eラーニングや LMS の活用に積極的な方が多くありました。このような利用者から多数のご意見・ご要望を頂きながら WebClass も様々な機能をそろえることができました。
2010年代にはいって大学での LMS 利用が浸透し、先生方に教育でのシステム利用に興味があるなしに関わらず、学校設備の1つとして広く授業で使われるようになってきています。また、学生の方もとりあえずスマホでアクセスするのが当たり前になってきています。また、普段から利用する先生が増えるに従い、システムの不具合があった時に与える影響も大きくなっています。こうした変化に伴い、WebClass が先に取り組んでいたのは学生のスマホ利用への対応、ソフトウェア開発工程とソフトウェアテストの改善、セキュリティ実装でした。
そこからさらに一歩進める改善が、一昨年からの新画面の取り組みです。今ではあまり高度な機能がありすぎても、普段ちょっと使うにはかえって扱いづらいと感じられるケースが増えています。また、利用端末もスマホだけでなくタブレットが加わり、学生が使うかと思いきや先生もタブレットで利用するケースがあり、とても多様化しています。セキュリティについても、ますます重大なテーマとなっています。
先月、松川さんが「ソフトウェア設計 勉強の手引き」という記事をちょうど書いてくれました。
例えばある機能の画面をきれいに直すにあたり、見た目だけ直せればいいやと考えて HTML と CSS ＋ Javascript だけの書き直しでうまくいくかというと、経験的にはそう簡単に行きません。見た目の整理は取り扱う情報の整理になるので、結果的にはプレゼンテーション以前のデータ構造やデータの受け渡し経路を見直す必要が出てきます。特に Ajax を使った SPA にしたい場合、JSONデータインタフェースの実装が必要になるので、当然ながらインタフェースの拡張が必要になります。これらはセキュリティ実装でも同じことが言えます。したがって多かれ少なかれリファクタリングをすることになります。
利用者から見えないリファクタリングに時間を食われるのをもどかしく思うこともありますが、私は画面の改善でリファクタリングが必要になるのは好機と見ています。素早く確実にソフトウェアを改善し続けるためには、コードの保守性は重要です。これまで画面を変えられなかったのは、その様なコードの体制がなかったのも原因の1つです。ですがコードの問題は画面の改善だけでなく、テスト可能性やテストのコストにも反映されます。
幸いなことに、コードの設計は手本になる本やオープンソースのライブラリやプロダクトが多数あります。したがって、何を実現するかがはっきりしていれば解は比較的見つけやすいです。また、基本的には良いパターンを使いまわしていきます。なので、一か所で何とかすれば、同じような個所を一気に片付けることができます。そして、その後は維持しやすくなると期待できます。
コードベースの問題を乗り越えて実質的な機能修正に取り組むにあたり、一番問題になるのは「本当に使いやすいのか？」という点です。
コードの良さは計測しやすく、開発チーム内でコンセンサスが得られればOKという意味で、評価しやすいです。一方、画面や機能について利用者がどう思うかは計測・確認がしにくく、いろんな利用者がいてコメントの方向性が定まらないケースもあります。また、仮にいい画面になったとしても、慣れの問題が付きまといます。この点について個人的に印象深いのは Microsoft Office 2007 のリボンUIです。出た当時はいろいろ言われていましたし、私も「なんで？」と思いました。従来のメニューでは一通りの機能を本当に扱いきれなかったのかどうか私には評価できませんが、今では慣れて特に問題なく使っていますし、スタイルの適用などはUI表示域の広さと表示される情報とが程よく、便利だなと思っています。
真似しやすいコード設計に対して、UIや機能の設計は基本は考えてひねり出すのが良いと思います。利用者のコメントはありがたい参考資料になりますが、そのまま受け入れるだけだとブレます。特定の利用シナリオにぴたりと寄り添うほど汎用性を失って、オプションを必要としてしまいます。オプションも加えれば加えるほど動きがわかりにくくなり、テストやマニュアルの周辺作業が積みあがってしまい、機能を洗練させる時間を取れなくなります。
ではどうしたら良い機能や画面をひねり出せるか、これは私もいつも悩む問題です。やはりここは、いろいろ聞いたり試したりするしかないと思っています。特に、先生がどんな状況でどんなことをしようとしているか、というあたりでしょうか。WebClass のあるなしに関わらない、もう少し根本的なシーンやシナリオが見えてくると、考えやすいです。でも、特定のケースに固執しすぎては汎用性を失います。ここが難しいといつも思います。
利用者がいてくれる限り、WebClass の開発は終わりません。その時ごとにテーマや課題があり、常に変化・対応し続けていきます。今いいものも、2年後には利用環境と乖離して使い物にならなくなっている可能性もあります。それどころか、後になって昔の機能の価値を再発見してしまうこともあります。そういう意味で、コードベースの改善も画面・機能の改善も果てがなく、あまり考えすぎてしまってもしょうがないところがあります。
なので私たちはアジャイルなソフトウェア開発の仕方を取り入れています。小さく手堅い修正を素早く重ねて行く作戦です。画面の置き換えも、表には見えないリファクタリングだけ先に進めたところもあります。その中で、試したけど捨てたコードも多数あります。いいと思って採用したけど、思ったようには行かなかったコードも多数あります。ですが、これらは「うまくいかない」ことがわかった成果として無駄ではなかったと思っています。
いずれにせよ、多くの利用者が使うシステムでは「パパッと作って何とかなる」とは行きにくくなります。タイムリーに新機能や改善を提供し続けるためにも、普段からリファクタリングや試行錯誤を常にやり続け、そして学び続け、堅実なコミットを積み重ねていきます。
この記事は弊社の後輩プログラマーを読者と想定して書いています。しかし一般的な内容でもあると思いますのでここに公開します。
プロのプログラマーは、堅牢で、なおかつ要望を即座に実現するソフトウェアを構築するために、「プログラムの変更が容易である」状態を維持しなければならない。もう何十年も先達プログラマー達はそのためのノウハウを蓄積し、原理原則レベルまで抽象化して落とし込んでいる。これを学び体得することが、プロのプログラマーには必要である。
まず、設計スキルを完璧に身につけた！と言い切れる人は多分いない。プログラマーは皆、常に勉強し続けるのみである。設計スキルを向上させるための基本的な方法は、他人のコードや本で良い設計のエッセンスをインプットし、自分の書くコードにアウトプットする、これを繰り返すことである。
インプットの方法だが、まずは他人のコードを読む習慣があると良い。会社やサークルで、メンバーの書いたコードを読み、その設計の良し悪しについて話しあってみる。公開されているOSSはネット上に無数にあるので、興味があるプロジェクトを見つけてコードを読んでみる。できればOSSにコミットするコントリビュータを目指すといい。
設計に関する原理原則、体系だった情報を得るには、本を読むことになる。以下はどの資料をどういう順番で読むといいかを例示する。この通りに読まなくても、自分に合う本をピックアップして良いし、興味のあるところから取り組んでも良い。
設計の原理原則はプログラマーの教養であり、共通言語である。知らないと他の本が読みづらい。
コードが正しく動いているかチェックするには？プログラマーは皆テストを「書いている」。それに伴い、テストをしやすいコードが良いコード、という指標が存在する。テストを書くとはどういうことか知らないといけない。
これ以降は、目的に応じて細分化していく。
コードは書いたら書きっぱなしじゃない、常に改善を繰り返していくものだ。設計についてもそうだ。複雑で手を出しにくい設計に修正を加えないといけない時、どう立ち向かうか？
普段使っている言語とは異なる言語思想と文法を持つプログラミング言語を学ぶことで、その考え方の良い点を設計手法に反映できる。特に関数型プログラミングと呼ばれる思想は、最近勃興してきたプログラミング言語の基礎（の一部）として採用されている。既存のPHPのようなプログラミング言語でも、関数型プログラミングのエッセンスを活かした設計手法が存在する。
とりあえずこんなところ。
この記事を書いている人ももちろん勉強の道半ばです。自分が書くコードの設計についてレビューでガンガン指摘してもらったり、話し合ったりしたいです。オススメの資料があれば教えてください。宜しくお願いします。