投稿記事

無料プランの記事 (63)

いらにか 2024/07/05 23:22

【雑記】ソフトウェアの進化論【遺伝子】

長くソフトウェアの開発をしていると、ある壁にぶつかります。


それは 刷新 とか リプレース など色々な呼ばれ方をしているのですが、より抽象的に言うならば 進化 とか 世代交代 が表現として一番しっくりきます。


アップデートや機能拡張も類似するものですが、それらは 成長 という枠の中にいて、進化とは少し異なります。
皆さんにわかりやすく説明するなら、Windowsの遍歴を思い浮かべてもらうのが簡単かもしれません。
Windows10は月次アップデートで段々と成長していきますが、Windows10からWindows11に変わるようなアップグレードではUIや操作系、機能など様々なものが変わって、明らかにWindows10とは異なるものに進化しています。


一般の方は、なぜこのような進化をするのか疑問に思うかもしれません。
Windows10のままWindows11のように機能拡張することはできないのか。
特に、Windows7からWindows8系への移行では散々な言われ方をされてました。


これらの前提として、そもそもソフトウェア開発は生み出した後が本当のスタート地点であるという特殊さがあります。
現代のソフトウェアはリリースされた後も修正パッチやアップデートなどで、バグを修正したり機能追加したり、成長させることが当然になっています。
逆に不具合などが修正されず、メンテナンスがされていないソフトウェアは忌避される傾向すらあります。


「ソフトウェアはリリース後も継続的にメンテナンス(保守)される」という文化は、ソフトウェアの発展に大きく寄与してきましたが、同時に開発者の負担にもなっていました。
開発者が保守しなくなったことで、使われなくなっていったソフトウェアも沢山みてきました。
(その度に代替になるような派生ソフトウェアが台頭してきたりしました)


たぶん、この記事を読んでいる人も使わなくなったアプリやサービスがあるんじゃないでしょうか。


ソフトウェアの死というのは、誰にも使われなくなることだと思っています。
そして開発者は「自分」と「その他ユーザ」のことを考えてソフトウェアを成長させていきます。
ですが、大きくなりすぎたソフトウェアは次第に成長が遅くなり始めます。

自己を作り上げているソースコードが膨大になり複雑化し、不具合が増え、動作が遅くなり、過去のコードが足を引っ張って思ったように機能が実装できなくなり、Etc...といった感じで、膨大に積み上げてきた積木の上にさらにブロックを積むのが困難になるのはソフトウェアの宿命とも言える問題です。
もちろんこの問題と向き合うための学問や哲学などのエトセトラが多く存在しますが、少し脱線するので割愛します。気になる人はソフトウェア工学で調べてみてください。


こうなってくると、開発者は現状を整理して、より理想的に積み上げたソフトウェアが欲しくなります。開発者の多くは理想状態を好みます。
大抵はリファクタリングと呼ばれる整理・修正作業によって改善を試みますが、手が付けられないような致命的な欠陥があると、最早イチから作り直したほうが一番早いという結論にたどり着くことがあります。
そして、古いソフトウェアから良いものを受け継ぎつつ悪いものを排除した、新しいソフトウェアが生まれます。


これらに生命の進化論に通じる部分があると感じているので、冒頭の表現として進化がしっくりきているわけです。


ここまでの説明で、感の良い人は「ソフトウェアの退化」や「モダナイゼーション(近代化)」が起こることの必然性を受け入れられるかもしれません。
端的に言えば生命ですら現在の環境に最適化しようとして退化のような進化をしてしまうのだから、ソフトウェアでも同様の事が起こりえるということです。


Windows8で不評だったModernUI(MetroUI)は、当時の世界を席巻しつつあったモバイルデバイス(スマホやタブレット)を念頭に開発された経緯があり、WindowsがモバイルデバイスのOSに進出するための試行錯誤でもありました。
マルチデバイスでの統一を図るためにモバイルデバイスにおける当たり前(強○フル画面、横スクロール、タッチ操作など)をPCの世界にも持ち込もうとしたことで混乱が大きかった印象が個人的に強いですが、Windowsにおけるウィンドウの利便性が損なわれていたことが一番の失敗だったと思います。あとWindowsボタンのスタートメニュー。
まぁ話が脱線するので戻しますが、ここで重要なのはWindows8.1以後では操作系やUIをWindows7っぽく戻しつつもアイコンのデザイン面ではWindows8のフラットデザインの要素がモダナイズがされて残った点です。


Windows7からWindows10へ移行する人の中で、当時はよくアイコンのデザインの好き嫌いの話がされていました。
Windows7時代は立体感や質感の強いデザインのアイコンで、iPhoneも初めの頃は同様に立体感や質感の強いアイコンでした。
立体感を出すことで押せるものと認識させる意図があったりしたそうです[要出典]。


フラットデザインへの転換期にあたる2012~2014年頃、PCやスマホなどデバイスによって画面解像度やサイズが多種多様すぎることで、アイコンのデザインは苦しめられていました。
例えばリアルな写真のような128x128サイズのドット絵を16x16サイズにしようとすると、情報の欠如が多すぎて元の絵と印象がだいぶ変わってきます(そもそも同じように表現できないかも)
この問題を解消するため当時はフラットデザインやマテリアルデザインなど、マルチデバイスを意識したデザインがいくつか生まれました。
フラットデザインでは、元がシンプルであるためにサイズを変えても印象があまり変わりません。
ですが以前のアイコンの立体感・物体感が持っていた「押せる印象」がフラットデザインで失われたことで、ユーザの違和感に繋がり、前述の好き嫌い論争の一因になりました。
(一応フラットデザインでは薄いシャドウなどの浮遊感によって押せる印象をもたせていたりします)


このようにアイコンの進化があったおかげで、多種多様な解像度への耐性値があがりました。
もしかすると、この転換が無ければ近年のスマホの超高解像・巨大化は無かったかもしれません。


ユーザは以前のままで良かったと思っていても、開発者側に以前のままではいられなかった理由があったりします。
このギャップが(ユーザー視点での)ソフトウェアの退化につながる一因なのかなと思います。
X(旧Twitter)とか、まさにその例かなと。


Windows8はサポート終了しているので(おそらく)滅びを迎えました。
ソフトウェアとして死んだと思いますが、その遺伝子は残り続けています。


そう考えると、死にゆくソフトウェアたちもどこかに遺伝子を残しているのだろうなと思いました。



了。

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

いらにか 2024/04/14 20:43

【感謝祭】道草恋歌アワード2023【ノミネート】

どうも、ごきげんよう。いらにかです。
まさか多忙と疲労で、道草恋歌アワード2023の記事投稿が感謝祭最終日になるとは想定外でした。

道草恋歌アワード2023では、2023年に投稿された道草恋歌の作品から、いらにかの選出した作品をノミネート(入選)作品として表彰します。
今回は大賞などの区分はありません。批評コメントも野暮なので一部以外は無しです。
(来年は一般投票で大賞選ぶとかやりたいなと思いました)



それでは、ノミネート作品の発表です!


暮れ方の 蛙と野鳥鳴く中に 湿る風吹く 田舎の暇(いとま)

作者:くぁ


まどろみと 寝息ふたつの 布団から 去ぬ猪の子や 温さのこして

作者不詳


アイス殻 ペコペコしない まねしない

作者不詳


快速が職場の最寄駅を越え道草屋まで行けばいいのに

【作者】
黒縁ナイロールのお客様


イタズラじゃないと気づいて葉っぱより重い届けを受理してしまう

作者:黒縁ナイロールのお客様


眠るまで君が宿っていたはずの耳のこんなに浅い空洞

作者:黒縁ナイロールのお客様


春の夜に 繋いだ指先 擦り上げて 微睡む顔は 子供の様で

作者:ちめ


振り向けば 短かったと 言えるのに 明日が遠い そんな冬の日

作者:ちめ


紧落雪 夜半思故人 叶归根

作者:johnsmith


※一般人には解読困難だと思うので、いらにかによる注釈
日本人が読みやすいように日本の漢字にしてみました。
 緊落雪 夜半思故人 叶帰根
私なりの意訳ですが、(かなりの)雪が降る夜半(0時前後)に遠い人(故人)を思っている歌だと解釈しています。

誤解だと恥ずかしいんですが、おそらく落葉帰根に掛けた歌だと思います。
落葉帰根は樹木の葉が落ちて根に帰る様子から、輪廻や循環や原点回帰などの例えとして使われるのですが、「人は死後に故郷へと戻る=故郷への哀愁」という解釈もあります。
落葉のさらに先の季節。
激しい雪が降る中、故人を思い、根に帰ることを願う様子が歌からも想像できますが、土地に根ざした樹木の葉ではなく、雲として遠くから運ばれてその地に降りた雪に焦点を当てていることで「異邦の故郷、第二の故郷への哀愁」という表現が非常に深まって解釈できるなと思いました。
まさに、落雪帰根。
遠い地から来た雲が雪となり、異邦の地の根に帰する様は国内外を問わず、多くの道草屋の旦那様に通じる情景と心情なのではないでしょうか。



P.S.
故人が根に帰ることを祈った鎮魂の歌として解釈しても素晴らしい歌だと思いました。
中華圏の文化にあるか不明ですが、0時頃の描写になっているのも黙祷を正午に捧げる様子と繋がっていて情緒ポイントが高いと思います。


雪解雨 更ける夜長に 通る波 微かな息が 此方に揺れる

作者:いらにか


あとがき

芹さんと
連れて往く道
帰り道

2019年10月。
ふいに脳裏に浮かんだこの句と脳内の情景に思わず涙が零れそうになり、
道草屋と詩歌の融和性と可能性を感じて#道草恋歌 を公開する場所を作りました。

道草恋歌は当初から「自由に詠むこと」「自分のペースで詠むこと」を大切にしてきました。
そんな道草恋歌が、2023年も歌人の旦那様たちのおかげで続いていて嬉しい限りです。
特に海外旦那様の道草恋歌も嬉しい出来事でした。
道草恋歌のシステムが海外旦那様に優しいかどうか不明なので、このあたりは改善しなきゃなぁとか思ってたりします。

まだ道草恋歌を詠んだことがない人はデビューお待ちしております!

https://michikusa-renka.glideapp.io/

匿名性も大事にしている道草恋歌!!
新作の感想などを川柳や短歌の形式で表現して投稿するだけでもOKです。
とにかく自由なので!!


それでは、また来年!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

いらにか 2024/04/01 06:30

【5周年】みちくさびゅあー感謝祭2024【1日~14日迄】

今年もやってきた、みちくさびゅあー感謝祭!!

今年でみちくさびゅあーも5周年です。
毎年、4月1日から2週間をみちくさびゅあー感謝祭として、なんか色々やったり、やらなかったりしてます。

現状、2代目びゅあー3代目びゅあー(開発中)の2つがリリースされているややこしい状況を整理したかったんですが、いろいろと間に合いませんでした。




代わりに、エイプリルフール企画として、桃色CODEのホームページをモダン化したパロディWebサイトを作りました。

https://momoirocodo.web.fc2.com/


URLがフィッシングサイトみたいになってるのもポイントです。
確実に怒られるレベルのものなので、4月1日が終わったら非公開にする予定です。



道草恋歌アワード2023

2023年も道草恋歌には良い歌がたくさん投稿されました。
本当にありがたい限りです。

今年の感謝祭では2023年に投稿された作品から、いらにかの独断と偏見により選出した秀作をノミネート作品として、別途記事にて紹介する予定です。

感謝祭は14日まであるので気長にお待ち下さい。

フォロワー以上限定無料

無料プランに入るとモチベーションを支援できます

無料

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

いらにか 2024/03/06 23:16

【雑記】あっという間に2月が終わった

雑記

あっという間に2月が終わった。
何もしてなかったかというと、そうでもなくて、


シュクメルリ食べたり、
A5和牛の焼肉食べたり、
弘前にクラフトビール飲みに行ったり、
同級生と久しぶりに飲みに行ったり、
喫茶&バーで飲んだくれたり、

振り返ってみると、結構いろんなことをしていた。

ただ2月はたくさん外に出たことで、考えさせられることも多かった。
そして、プライベートな時間でパソコンを起動しなかったという事実が一番の衝撃だったかもしれない。
一応、仕事ではパソコン使うし、日常生活ではスマホとかタブレットは使っていた。
なのであまり共感はしてもらえないかもしれないが、プライベートな目的でパソコンを全く使わないというのは「ずっと一緒だったテディベアを失くしてしまったのに、他のおもちゃでも日常を過ごせてしまう。でも高度に遊ぶ習慣が消え失せた」みたいな感覚だった。

正直、スマホ(タブレット)とパソコンそんな変わらないやろという人も多いと思う。
でもパソコンは日常の様々なことのハックに使いやすいのが楽しい。

例えばCi-enのマイページにNSFW画像が表示されるのを防いだり
DLsiteの作品ページから直接ギフトページを開けるようにしたり
桃色CODEのサイトにみちくさびゅあーを直接埋め込む機能作ったり
Etc...

こういうことはスマートヒョンだけでは中々できないので、パソコンの便利さを実感する。


ちなみに私物のデスクトップパソコンはあまりにも使わなすぎたので、離れて暮らす兄に貸し出している。
なので手元にあるパソコンはSurfaceGo(初代)という開発には向かない貧弱パソコンだけ。
こうやってCi-enの記事書いたりする程度には使えるのだが、タブレットでもできるからなぁ……みたいな。


そういえば久しくノートパソコンを買っていないので、アマゾンを徘徊していたら中古のリテール品がWindows11のノートPCが大量に出ていた。
しかし、CPUをみてびっくり。



Win11が正式サポートしてない世代のCPUじゃん……


ネットでの買い物も難しくなってきているなと思った。

Mes

.NET8がリリースされたら移行しようと思っていたMes。
結構致命的な設計ミスにも悩まされていて、イチから再設計しています。
正直なところ勉強も足りてなくて、このまま再実装するのも得策じゃない気がして勉強しながら設計してはバラしてを繰り返しています。

Mesの言語自体は初期の頃からコンセプトは素晴らしいと自負しています。
「デコレーション」という概念でメタ情報を扱い、それを構造化されたデータとして簡単に扱うことができ、既存のシナリオテキストをMesに書き直すのは非常に簡単なのもコンセプトが洗練されているおかげです。

テキストシナリオをプログラムで扱いやすいように構造化されたデータとして提供することで、「【Mes】ADVで使えそうな分岐管理を試験的に組み込んでみた【試験実装】」みたいな機能も比較的スムーズに開発できました

一方で、Mesの開発で一番苦労しているのはコアライブラリの実装です。
しかも、Mes本体の解析処理ではなく、Mesを便利にするための外野のフラットレイヤーとコンフィグレイヤーと呼んでいる部分で一番苦労しています。

フラットレイヤーはMesとして解析する前に、テキストに前処理を施す層です。
脚本でよく使われる表記方法の一部をMes形式に変換したり、削除していいコメントアウト部分を消したりします。
そうすることで一般的なシナリオ記述でもMesで解析できるような工夫がされています。
置換ルールと処理を書くだけなのでフラット処理単体の実装は難しくありません。
問題はコンフィグレイヤーとの関係にあります。

Mesではヘッダーと呼ばれる記述エリアに各種設定用の変数を記述することができます。
キャラ名も省略したときのデフォルト名や、各種デコレーターの記号などMesに関する設定をMesテキスト内で設定できる仕組みです。
この仕組みはMesのヘッダー部分の解析時にコンフィグへ情報の上書き処理を行います。以降の処理では上書きされたコンフィグ情報で解析されるので、デコレーター文字などの設定書き換えも可能になっています。

フラットレイヤーはヘッダー解析よりも前の段階なので、このコンフィグ書き換えの恩恵を受けられません。
フラットレイヤーでもヘッダーの変数解析をするしかありませんが、そうするとヘッダーの役割と重複します(このような役割の重複がバグの温床になります)
そうなると、ヘッダーの変数解析はフラットレイヤーに移譲するのが正しい気がしてきますが、フラットレイヤーは必ず実行されるような仕様ではなく、ライブラリ利用者が任意に外すことができる使用になっています。
(元々がテキストの前処理をしたいケースでの拡張機能的な役割なのでこのような仕様になっています)

というわけで、フラットレイヤーの前にコンフィグレイヤーを新たに作り、コンフィグレイヤーを通過したときはヘッダー解析で変数解析をスキップできるような仕様なら効率よくできそうだなとか。
そういった再設計をしています。
特にコンフィグレイヤーはまだ仕様が固まっていないのもありますが、MesEditorのようなサードパーティツール製作者がコンフィグ設定用の機構を実装しなくても機能するような柔軟な仕組みづくりを念頭にして考えています。


まだまだ時間がかかりそうですが、ここさえ満足いく作り方ができればサードパーティツールの開発はすごく楽になるのでスキルアップも兼ねてじっくり作り込もうと思います。

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

いらにか 2024/01/06 14:35

【雑記】芸術じゃない芸術の話【学びの咀嚼】

著作権法について学習している時から、芸術という言葉は非常に厄介だなと思っていた
芸術は「思想(美しさ、感性等)を人が表現する活動とその活動から生まれた作品」という意味に位置づけできる。
要するに人が生み出した思想の塊が芸術であり、芸術作品と言ってもよいだろう


しかし、私たちは人が生み出したもの以外からも芸術性のようなものを享受する機会があるように思う。
自然が生み出した雄大な富士山の姿。
ウユニ塩湖の景色。
満天の星空。
ブロッコリーのフラクタル構造。


人工的でないものからも、芸術に通じる何かを私たちは享受するが、芸術性に替わって、人工的でないそれらを的確に表す言葉が未定義だと私は思った
(もしくは私が不学で適切な言葉があるのかもしれない)

「自然が生み出した芸術」と言ってしまえば万人には通じるだろうが、それはWord to Vector的な意味合成で、

芸術 - 人工的 + 天然(自然)

の式から得られるニュアンスでしかない。


仮に、狭義の芸術を人による創作物とし、広義には感動するものを指すと位置づけても芸術の意味解釈的範囲を広げただけに過ぎず、狭義の芸術以外の芸術には依然として名前が無いままだ。これを暫定的に狭義外の芸術と呼ぶことにする。


狭義の芸術と狭義外の芸術は、人によって両者を同列で評価したり、違うものとして評価したりと個人差があるはずだ。
同じ人でもケースバイケースでこの価値観がスイッチしたりするかもしれない。
綺麗や美しいという言葉は評価の結論であり、至ったゴール地点を指す。
狭義の芸術という入口だろうが、他の入り口だろうが、その先は同じ場所に通じているかもしれない。
感情という結論で言えば喜怒哀楽のどれかに帰結するだろう。
もっと単純なら、好き or 嫌いのどちらかに帰結するかもしれない。


話を本筋の戻すが、
人が創作したものは芸術であり、芸術性を語ることができるだろう。
しかし、狭義外の芸術にも芸術性のようなものがあり、そこに適切な名前がなく、その性質を説明するために芸術の名を借りているせいで混乱してしまう状況がある。AIの生成物が芸術なのか否かみたいな議論のディスコミュニケーションもこの混乱が一因だと勝手に推測している。
本来なら芸術という言葉のスコープは人工物に限るはずなのに、スコープ外の人工的でないものから芸術に似た感動を得たとき、我々は芸術の概念を使って言葉にしてしまう。
飛躍する例えかもしれないが、斧を知らずナイフを知っている人に「木を切るナイフ」と斧を説明することに近いかもしれない。
または、タコみたいな姿の火星人がいたとして、明らかに人類とは違う生命体なのにの概念に当てはめて火星人と呼んでいることに似ていると思う。


Contemporary Artを現代美術と定義してしまったように、こと芸術分野においては混乱を招くような言葉が多すぎる。
芸術自体が明確に意味を定義したりするのが難しい概念であるという側面もあるだろうが、いずれにせよ、価値観や定義などが人によって独自実装されているのに同じプロトコルとみなしてコミュニケーションに使っていたら、そりゃぁコミュニケーショントラブル起きるでしょという話。


芸術の前提議論として、(狭義の)芸術自体が自然の模倣でしかないとか、哲学的な議論はあると思うがその話はまた別の機会に考える。
僕はしばらく、狭義の芸術じゃない芸術(人の介在しない芸術領域)について色々考えたいなと思った。


参考文献
https://www.rs.tus.ac.jp/makita/stellung/stell_phi_kunst_j.html
https://natgeo.nikkeibp.co.jp/atcl/web/15/427954/090400006/

フォロワー以上限定無料

余談

無料

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

« 1 2 3 4 5 6 7

月別アーカイブ

記事を検索