おそらくリファクタリングの工数を確保する説得力のある材料がほしくて、リファクタリングの効果をどう示すか悩んでる人がいたのですが、リファクタリングって非開発者に示せるような数字だすのは難しいよねという結論になったので、そのまとめ。 工数としてはコード管理費みたいな感じで乗せるのがよさそう。 まず、リファクタリングはそれ自体では価値を示せません。人工衛星に搭載するプログラムで、動きだしたらメンテナンスできないようなコードを最後にリファクタリングしたとして、どのような価値を示せるかと考えると想像できるのではないかと思います。 なのでリファクタリングの価値というのは、その後で新しいコードを追加したり既存のコードを変更したりといった作業がどれだけ作業時間短く品質高くなったかという間接的な指標で測ることになります。 ここでまず、最初のコードを書いた人とリファクタリングする人が同じなら、そこまで保守性か

代数データ型という考え方があって、型に対する代数的な操作を行うものっぽいです。代数的な操作というのは、足し算とか掛け算ですね。直和型と直積型というのがあります。 直積型は構造体のようなもので、Javaだとrecordが導入されましたね。 record A(int p1, boolean p2) {} みたいなものです。 これがなぜ積なのかというと、このレコードAの取りうる値の組み合わせは、intの値のパターン数(2 ^ 32) × booleanの値のパターン数(2)で2 ^ 33になるからなんだと思います。 直和型は、型がこれかこれ、みたいになるやつです。Javaだとtry-catchのcatch句に直和型が指定できて、この例外かこの例外、みたいな書き方ができますね。 catch (NullPointerException | NumberFormatException ex) あとse

定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代

JavaやCで組むのは他人のためのプログラムで、Pythonで組むのは自分のためのプログラム、という違いがないかなという話。 TIOBEでとうとうPythonが1位になったというニュースが流れてました。 https://internet.watch.impress.co.jp/docs/yajiuma/1357645.html でも、Pythonが1位になったとはいえ、CやJavaであったような、世の中のプログラム全部Pythonになるみたいな雰囲気はないなと思いました。 で、こんなツイートをしたわけです。 PythonがJavaやCを抜いて1位になるのは、JavaやCが担っていたところがPythonに置き換えられたのではなくて、他人のためのプログラミングではなく自分のためのプログラミングが増えたということじゃないかなと思う。https://t.co/LeM3ADCwAA— きしだൠ(K1

基礎と低レイヤーは混同しがちという現象をみかけたのでメモ よくあるのが、「IDEを使うと基礎が勉強できない、メモ帳でコードを書いてコマンドラインでjavac / javaするところから始めるべき」みたいな話。 ツールを使わずツールが隠してる部分を自分でやって勉強せよ、フレームワークを使わずフレームワークが隠してる部分を自分でやって勉強せよ、という話は、これ自体は間違いではないのだけど、これを「基礎」と言ってしまうと違った方向に行ってしまう。 これは基礎ではなくて低レイヤーではなかろうか。 そして、低レイヤーは「ツールを使わずにやれ」と言ってる人の想定する「ツールを使わず」というのもすでにツールを使っていたりする。ほんとに低レイヤー知りたいなら、javac使わずハンドコンパイルでしょう。Javaバイトコード知っておくべきでしょう。 と、だんだんマニアックなこと知ってる自慢になっていく。 こう

「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？ 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac

プログラムを作成するときに、メッセージの文字列などを適当にそれっぽく生成したい場合があります。 そういうとき、とりあえずこういうプログラムが考えられます。 public static void main(String[] args){ String[] users = {"nowokay", "higayasuo", "t_yano"}; String[] pre = {"ところで", "じつは", "さて、", "なかんずく、"}; String[] msg = {"こんにちは", "はらへ", "おはよう", "ねる", "きたく", "ビールのむ"}; for(int i = 0; i < users.length * pre.length * msg.length; ++i){ System.out.printf("|%s|%s%s|%n", users[i / (pre.leng

間違った情報をblogに書くのはやめてくれという趣旨なのだろうだけど、「正しい情報しか書いてはいけない」のだとしたらblogなど書けないし、「blogに書くのはやめてくれ」などといってる人も正しい情報だけを書いているわけではない。せめて、過去指摘された自らの問題点を、すべて正してから言わなければいけないのではないかな。 まあ、その書いた人自身のことはどうでもいいか。 ブログに書く内容として、いま勉強してることを書いている人は多いと思う。 そうすると、そこまでの情報で書かざるをえないから、間違った内容や考慮に欠ける内容になることも多い。 そういうのは、やさしい言葉や厳しい言葉やらで、指摘して正しい方向に導くなりボロクソにこき下ろしたりすればいいのであって、「blogを書くな」などというべきではない。 学習過程を載せてモチベーションにするということを、阻むべきではないと思う。 blogに限らず