Copilotがうるさい
．．．と、ずっと思ってた。
簡単に機能をOFFることも出来ないし。
最初はEdgeで検索かけるとCopilotが
「しばらくお待ちください」
とか言って何やらAIによる回答を生成し始めるのを見て
「お前に聞いてんじゃねーよ。毎回うるせーよ。なんか重いし」
と毒づいていたのだが、ある時を境に状況は一変した。
現在の案件の作業支持者の方から
「Copilotで社内の情報も検索可能になりました。Teamsで質問可能です」
とのアナウンスがされた。
作業に関連する資料を読んでいて分からない単語があり
試しにTeamsのCopilotに質問すると面白い回答が得られた。
全てがピンポイントの情報とは言えないが
関連資料が山のようにクラウド上にまき散らされている状況下では
かなり有効な結果を示してくれる。
ググってみると
「Copilot とは、Microsoftが提供するAIアシスタント機能のこと」
となっている。
最近ではOfficeがらみのアシスタント機能も充実しているらしく
Excelなど立ち上げてもCopilotが随所に顔を出す。
ただ、冒頭でお話したEdgeでのAIによる検索結果の要約は
Googleの生成AI検索「AI Overviews」に比べるとイケてない。
IT関連の情報を色々発信しているYouTube動画で
EdgeとGoogleではシェアに大差がついていて
AIが使用する情報コンテンツそのものが圧倒的に足りない事実を知った。
そうなると、生成AI検索も当然のように「格差」がついてしまうのだろう。
会社の環境ではEdgeを使用しBingで検索しているのだが
「お前に聞いてんじゃねーよ」状態の時には
Edgeを立ち上げておきながら、Google Searchで検索していた。
最近久しぶりにbingに戻したら、検索結果に物足りなさを感じた。
それでも社内の情報を検索する方法がOne Driveの検索だけだと
的確に絞れないし、絞ってもイマイチピンポイントの結果に
なっていないことが多々あった。
Copilotのおかげでそのストレスからは解放されたと思う。
さて。Copilotネタだけだと間が持たないので直近の仕事中に
とても楽しかったことがあったのでそちらのネタにシフトしよう。
現在の仕事ではJavaを使用しているのだが
DBのテーブルの内容をCSV形式で出力する機能を実装した。
対象のテーブル数が90以上あり、90数個のファイルを作成するのが
面倒だったため１つのファイルにまとめていたのだが
ファイルを分けた方がいいという指摘を受けた。
getter,setter,printCSVを含む形で90数個のクラスを実装することになるが
それぞれのクラスに差異が生ずる部分はテーブル名とカラム群だけなので
いつものように、一部自動生成で実装することにした。
色々な案件で、今回と同様の「同じような実装」を多数必要とするケースでは
いつも使っていた手である。
「自動生成」というと何やら偉そうだがただの力業で
差分部分を吸収した形でJavaコードを出力するだけである。
今回の場合なら簡略化すると以下のような実装が必要となる。
public class ＜テーブル１＞ {
private String ＜カラム１＞;
private String ＜カラム２＞;
.
.
.
private String ＜カラムｎ＞;
public String get＜カラム１＞() {
return ＜カラム１＞;
}
public void set＜カラム１＞(String col) {
this.＜カラム１＞ = col;
}
.
. (カラムｎまでgetter,setterを実装する)
.
public void printCSV() {
＜テーブル１＞の内容をCSV形式で出力
}
}
例えば「TABLE_A」と「TABLE_B」があるとしたら
＜テーブル１＞の部分をそれぞれ「TABLE_A」と「TABLE_B」に
それぞれのテーブルのカラムを＜カラム１＞から＜カラムｎ＞に
置き換えて実装してやればいい。
こんなのを、90数個手作業でやる気には到底ならないので
スクリプトを使用して上記のJavaコードをひねり出す。
（コードに限らず、入力データ等こういった力業の
自動生成をするシーンは多々ある）
今回はPythonスクリプトを使用したのだが、
いかにもロートルプログラマらしい「楽しみ」がそこにあった。
「楽しみ」の前にまたちょっと寄り道。
スクリプトはBourne Shellから始まって、C-Shell,Perl,Ruby,bash,Pythonと
その時流行っているものを選択してきた。
特筆すべきは「Ruby」で、以下のコードに一目惚れした。
5.times do
puts "こんにちわ"
end
「5.times do」がかっこ良すぎる！（個人的見解）
とにかくRubyでコードを書きたくって仕方ない。
その当時デグレード確認のための機能テストを自動化していたのだが
かなり自由に作業を任されていたので
当然Ruby!ここはRuby!と、ウハウハしながら組んでいた。
Ruby20周年のとき、「仕事でRubyを使用している方」という括りを利用して
Rubyアソシエーションの会合に不適切にまんまと潜り込みmatzにもお会いした。
（私以外にも単なる「Rubyファン」の男性が参加していた）
AIが脚光を浴び始めた頃にはRubyからPythonに時代は移行し
新しいもの好きの私は今、Pythonを選択している。
ここでやっと話が元に戻る。
先に紹介したJavaコードの自動生成処理で
クラス名のネーミング規則の話がレビュアーから出た。
Javaではクラス名は大文字で始める。
私の実装ではDBのテーブル名をそのままクラス名に使用していたため
「Class TABLE_AAA」といったクラス名になっていた。
クラス名に「_」（アンダーバー）の使用はあまりないという指摘も受けた。
「Class TABLE_AAA」なら「Class TableAaa」となるのが通例だという。
後者はキャメルケースと呼ばれ、Java以外でも古くからお目にかかる表記方法だ。
「おーし。それならキャメルにしちゃうよん」と私。
レビュアーから
「この場合、このままでもいいんじゃないかな」
との意見を貰っていたにも関わらず
どうしてもキャメルケースにしたくなったので、コーディングしてみた。
ここでロートルプログラマのC言語脳で単純に考えると、まずはこんな感じ。
#include <stdio.h>
void camel_case(char *src_pointer, char *dest_pointer) {
char *keep_src_pointer;
keep_src_pointer = src_pointer;
while (1) {
if(*src_pointer == '_') {
src_pointer++;
*src_pointer = toupper(*src_pointer);
}
else {
if (src_pointer == keep_src_pointer) {
*src_pointer = toupper(*src_pointer);
} else {
*src_pointer = tolower(*src_pointer);
}
}
*dest_pointer = *src_pointer;
if(!(*src_pointer)) {
return;
}
src_pointer++;
dest_pointer++;
}
}
int main(void){
char src_buff[20];
strcpy(src_buff,"TABLE_AAA_BBB");
char dest_buff[30];
camel_case(src_buff, dest_buff);
printf("%s",dest_buff);
}
同じことをPythonでやる段になって
「はて、1文字ずつの処理ってやるのかな？」
と思いググってみると
Pythonで文字列を1文字ずつ分割してリストに入れる
なんていう恐ろしいものがHITし、「ひえー」と思っていると
pythonで文字列の先頭文字を大文字にする
なーんて素敵な関数を発見し、それならばこうだ！とウキウキコーディング。
srcString = "TABLE_AAA_BBB"
targets = srcString.split('_')
result = ""
for target in targets:
result = result + target.capitalize()
print(result)
こんな些細な発想の転換が楽しくて嬉しくて、プログラマやめられないっす。
（でも、キャメルケースはこの場合可読性が悪いと感じて使用するのはやめた）
C,Python共にWEBベースの実行環境で動作確認済みですが
やはり久しぶりのCにはちょいと手こずりました。
（何とか動かせた。よかったー。Intel286時代の感覚で組みました。今はCも進化してるかなー）
もう、Python大好き(笑)
