#ソフトウェアのおはなし

[ya-sojiro-blog]

最新のPhotoshopやLightroomが凄いらしい

　写真編集ソフトと言えば、Adobe製品のPhotoshopやLightroomだろう。プロの方からアマチュアの方まで利用するこの最強ソフトウェアに、素晴らしいアップデートが来たとSNSで話題になっていたので試してみることにした。

※写真は全て管理人が撮影・編集したもので、著作権があります。複製や加工などの二次利用を厳しく禁止しています。ルールが守れない方は必要な措置を講じる場合がありますので、ご注意ください。

　物は試しとのことで、とりあえず現像とレタッチを終えてまとめてみた。私はPhotoshopとCamera Rawで現像とレタッチを行う派なので、今回もこのソフトウェアを使用している。Photoshopのバージョンは24.3、Camera Rawは15.3だ。上の画像から分かるように、素晴らしいアップデートで追加された機能は「AIを活用したノイズ軽減（AIノイズ除去）」。これまでは自分で輝度やディテールなどを設定してノイズの軽減を行っていたが、これからはAIの技術を用いたノイズ軽減が主流となっていくだろう。

　ノイズを除去する前の写真がこちらである。写真データのISO感度は10000で、かなりノイズが目立ち、ザラっとしている。

　従来のノイズ除去を行った写真がこちら。輝度は80、ディテールは100で設定。確かにノイズは軽減されたが、正直美しいレベルではなく、全体的にディテールが失われてのっぺりしている。

　AIノイズ除去を行った写真がこちら。適用量は80で設定。目に見えるほど美しい仕上がりとなった。従来のノイズ除去では表現できなかった細部のディテールまで、しっかりと表現されている。しかし適用量の上げすぎには注意したいところ。写真が不自然にならないように適用量や他の機能も活用して調整することが大事だ。また、適用されるまでに時間を要すので、パソコンのスペックに自信がない方は要注意である。

　このAIを活用したノイズ軽減は他社製のソフトウェアが有名で、Adobe製品は後発となった。しかし、このアップデートは素晴らしい機能と言える。他社製のソフトウェアを別に用意することも無くなり、今後の写真編集が大いに捗りそうだ。気になる方は要チェックだ。

※写真は全て管理人が撮影・編集したもので、著作権があります。複製や加工などの二次利用を厳しく禁止しています。ルールが守れない方は必要な措置を講じる場合がありますので、ご注意ください。

[kennak]

30 年近くソフトウェア エンジニアリングに携わってきた中で、私は何年も前に、ほとんどの締め切りは完全に恣意的なものであるという結論に達しました。 1 週間、あるいは 6 か月も遅れることがあったとしても、ビジネスが失敗することはありません。また、失敗したとしても、自社の納期見積もりを繰り返し破るほど機能不全に陥っていない限り、おそらくエンジニアリングのせいではありません。 確かに、規制上の期限、顧客の POC、または納品の期限があります。 しかし、ビジネス/営業側に根本的な問題がない限り、本当に厳しい期限が「来週終わらせなければならない」という理由で現れることはありません。 うまく機能しているエンジニアリング/ビジネス ユニットは、そのような期限をかなり前から知っているため、既存のエンジニアリング組織が大幅に詰め込まれたスケジュール内で機能を提供できるかどうかが問題になります。 別の言い方をすると、一定のペースでリリースされなかったという理由で、顧客がその製品から離れていくのを見たことがないと思います。実際、多くの顧客は、要求した問題を修正しない限り、アップグレードに満足していません。 また、販売/POC サイクルは、多くの場合、顧客が実際に代替ソリューションを持っていない可能性があり、たとえ持っていたとしても、来年ではなく今年が X であるという理由だけで顧客が貴社の製品に切り替える可能性は、左右されるものではありません。エンジニアリングチームが短いサイクルで実行できる小さな要素。 製品が優れているなどの理由で勝ちますが、それは一夜にして起こるものではありません。 そのため、ストレスを感じて週に80時間延々と働くことはおそらく逆効果であり、壊れ続けるため人々が手放そうとする低品質の製品を生み出すことになるでしょう。

ソフトウェアエンジニアリングにおけるメンタルヘルス | ハッカーニュース

[nihongo]

StreamBuilder：あなたのダッシュボードを強化するオープンソース・フレームワーク

この度、Tumblrのダッシュボードを強化するために構築されたカスタムフレームワークのオープンソース化を発表できることをとても嬉しく思っています。Tumblrでは、これをStreamBuilderと呼び、長年使用してきました。

まず最初に、オープンソース化についてご説明します。オープンソース化とは、オープンなコラボレーションを奨励する分散型のソフトウェア開発モデルです。よりわかりやすい言葉で言えば、ユーザーや他のデベロッパーのニーズに合わせて、ソースコードを使用または変更できるようにしたプログラムのことです。

では、StreamBuilderとは何でしょうか？実は、フォロー中フィード、あなたへのオススメ、検索結果、ブログの投稿、タグ付けされた投稿のリスト、あるいはオススメブログをチェックするたびに、あなたはこのフレームワークを使用しています。コードを知りたい方は、GitHubのこちらを���覧ください！

StreamBuilderには、たくさんの役割があります。主な設計は、ブログからの投稿、フォロー中のブログのリスト、特定のタグを使った投稿、検索に関連する投稿など、コンテンツの「ストリーム（流れ）」を中心に構成されてます。これらは別々の種類のストリームであり、ミックスしたり、特定の基準に基づいてフィルタリングしたり、関連性やエンゲージメントの見込みをランク付けしたりすることが可能です。

これからは、Tumblrのダッシュボードでは、フォロー中のブログからの投稿とフォローしているタグからの投稿、そしてオススメブログからの投稿が混在している様子を見られるようになりました。これらはそれぞれ別のストリームであり、独自のロジックを有していますが、同じフレームワークを共有しています。Tumblrでは、一定の間隔でオススメを投入し、あなたがブロックしているユーザーに基づいて投稿をフィルタリングし、「人気順」を有効にしている場合は関連性をベースに投稿をランク付けします。これらはすべて、StreamBuilderが提供してくれる機能の一例です。

オープンソース化されるものは、以下の通りです

プラットフォーム上で目にするほぼすべてのコンテンツのフィードを強化するための、現在Tumblrで使用しているコードの完全なフレームワークライブラリ。

コンテンツのストリームを構成するためのYAML構文と、それらをフィルタリング、投入、ランク付けする方法。

ストリームをプログラムで構成、フィルタリング、ランク付け、投入、デバッグするための抽象化。

カルーセルやストリーム内のストリームなど、ストリームを組み合わせて構成するための抽象化。

複雑なストリームテンプレートのためのカーソルベースのページ分割の抽象化。

ライブラリのパブリックインターフェースと、基盤となるコードの大部分をカバーするユニットテスト。

今後の追加予定

ドキュメント。Tumblrの内部ツールからこちらに移行すべきものがたくさんあります！

より多くのストリームテンプレート例と、さまざまな一般的ストリームの実装例。

質問がある場合は、コードをチェックしていただき、そこで問題をお知らせください。

[lastscenecom]

数年前、トリップアドバイザーは、ウェブサイトから直接レストランを予約できる新機能に対するユーザーの関心を測りたいと考えていました。 同社は、インフラストラクチャ全体を開発して予約を可能にするシステムを統合する代わりに、Web サイトに新機能のボタンを追加するだけで済みました。ただし、ユーザーがこのボタンをクリックすると、この機能はまだ利用できないことが通知されます。 この実験の目的は、ユーザーをイライラさせることではなく、提案された機能に対する純粋な関心に関するデータを収集することでした。 トリップアドバイザーは、ボタンをクリックした人の数を監視することで、新機能の開発に時間と資金を投資する前に、新機能に対するユーザーの関心を定量化できます。 このアプローチは、最小実行可能製品 (MVP) として知られる、最小限の労力で仮説を検証することの重要性を強調するリーン スタートアップの哲学を例示しています。

フィーチャー ファクトリを超えて: ソフトウェア イノベーションにおける影響を優先する |ベック ノヴァエス著 | 2024 年 2 月 |中くらい

[petapeta]

コードを書くことは大変な作業です。 ソースコードを書くのは、もっと大変です。もっと、もっと大変なのです。 セキュリティの機能を実装するコードを書いているとわかりますが、このようなコードは詳細まで精査されたアーキテクチャとデザインに基づいています。 さらに世界中でレビューされるというプロセスを経た、パーフェクトで破られることがないスタンダードが反映されているかもしれません。 （「パーフェクトで破られることがない」まあ、本当かどうかは置いておいて、そう仮定しましょう） が、このようにデザインとアーキテクチャが素晴らしくても、実際のソフトウェアに組み込むのはとても特殊なことです。 数学的にソフトウェアが正しいと証明されても、実現しようとしている機能が正しく実装できるソフトウェアを書くということは、科学と芸術の間にあるようなものです。（デザインとアーキテクチャに寄るとは言っても結局自分が何をしたいかに寄るのですが。） ソフトウェアをデバッグしたり、ソフトウェアに踏み入ることでその正確さを推測しようとする人にとっては、当然のことです。ただ、このブログ記事のポイントではありません。 誰も（コードを5行以上書いたことがある人、Perlでだったら6行）実際にソフトウェアがこのプロセスでパーフェクトになるとは思わないでしょう。 しかしソフトウェアは出来るだけパーフェクトでバグがないよう作るべきだ、というのはわかってもらえると思います。 だからこそ、コードレビューはソフトウェア開発の中心なのです。 ラッキーなことに（少なくとも私的には）、私たちが日々使うコードのほとんどはオープンソースです。これは誰もがコード見ることができ、何千もの人にレビューしてもらうことができる、ということです。 ここで問題が生じます。 オープンソースがたくさんの人にレビューされるということは、全てのバグが解決されるという考え方があります。 これは神話です。とても危険な都市伝説です。 先ほどの考えには二面性があります。 一つ目は、「ビルドすれば、出来上がる」という間違った考え方です。 世界中に全てのウェブサイトがリストされていた昔、そこにあなたのウェブサイトを登録すれば皆さんに見てもらえると思った時代があったでしょう。 （私も登録しました。見てもらえました。これは奇跡です） 同じように、オープンソースプロジェクトは（おそらく）少なかったので、たくさんの人がコードレビューしてくれました。 このような時代は終わりました。ずっと昔に。 二つ目に、セキュリティの機能を、良い例として暗号化の基礎などですが、正しくレビューできる人はすごく少ないのです。 ベンダー特有のコードに問題が少ないという訳ではありません。むし���、正反対です。 ベンダー特有のコードのデザインやアーキテクチャがレビューに対してオープンになっていない、ということではなく、コードを見てくれる人が少なくてヒエラルキーなプレッシャーと組織的な考え方に寄る危険性がとても大きいということなのです。 「ベンダーのコードは安全だ」というのは神話というより、フェイクニュースでしょうね。 多くの企業がセキュリティソフトを隠したい理由がよくわかります。 「知的財産の保護」と彼らがよく言うのは、実際リリースするのに安全ではないからなのではないか、と心配してしまいます。 私にとってセキュリティソフトとは、一貫して「オープンなソース」なのです。 では、何ができるでしょう。 セキュリティを気にする企業や組織はリソースを割いて機能を実装したりコードのチェックやレビューができるはずです。そして、そうする責任があると私は考えます。 その部分に私の勤めるRed Hatがコミットしているのです。 同時にオープンソースコミュニティはクリティカルなプロジェクトをサポートし、コードに含まれるレビューの数を増やそうとする方法を探しているのです。（例えば Linux Foundationの Core Infrastructure Initiativeです） さらに学術組織に、オープンソースソフトの大切さをハイライトすることはもちろん、セキュリティソフトの書き方とレビューという暗黒アートを 生徒に訓練させるよう推奨する必要があります。 改善できることはあるでしょう。事実、改善もしています。 「多くのレビュー（略）神話」はコードを改善できないという訳ではなく、むしろできるということを認識しなければいけません。ただ、もっとエキスパートのレビューが必要だということです。

大勢がレビューしていても信用しないという仮説 – Alice, Eve and Bob – a security blog

[diarytheroomoffuji]

フジカラー

懐かしい

X-T10など、とても古い機種の中古価格も高騰してて本当に驚く。

私は細かい事は全く分からないし、気にしてもいないけど（笑）最近のXシリーズは、触ったことも触れた事もないので分かりません。高いよね～カメラ。

フィルム時代の富士フイルムにも大変お世話になってましたが、デジタルカメラの画像では、この頃のXシリーズの色合いは気に入っている。まあでも、ソフトウェアでどうにでもなってしまう現代ですけどね・・・

デジタルカメラが世に出した頃は、個体差って大きかったけど結局は、その人が何を撮りたいか？そして使い心地が気に入るのならセンサーサイズ話は置いといて、最近のデジタルカメラ本体は、どれでも大した差がないように感じてます。

実際フィルム時代でも使うフィルムとレンズ、そして現像で色合いは決まったし、カメラ本体はフォーマットや機能の違いだけだったわけで、それを使い手が目的と好みで選んでいたから。

趣味の範囲での話です

[ari0921]

　「宮崎正弘の国際情勢解題」　

　令和六年（２０２４）２月２６日（月曜日）

　　　　　通巻第８１５０号　

　サイバー戦争のデータから判断できた事実

　　やっぱり中国とロシアがハッカーの元凶である

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

日本で最初にハッカー攻撃の脅威を書籍で著したのは宮脇磊介『サイバー・クライシス』（ＰＨＰ研究所。２００１年）だった。インターネットの通信革命が本格化したのが１９９０年代、その頃は単に「ネット」といわれ、ハリウッド映画の邦題が『インターネット』（サンドラ・ブロック主演）。公開は１９９５年だった。

筆者もすぐに見に行った。

この映画は犯罪集団が株価操作によりウォール街が大混乱に陥る恐怖を描き出した。何か異常な通信の革命が起きていると考えた筆者は米国に取材し、『インターネット情報学』〔１９９６年、東急エージェンシー。絶版〕を世に問うた。

前掲宮脇磊介の著作は「日本企業や政府、官庁がハッカーや外国の情報機関によるサイバーテロの絶好の標的になっている」と警告し、IT革命の裏側で頻発するハッカーや海外の情報機関によるサイバー攻撃の実態を活写した。彼は元内閣広報官だから政・官界への影響力があった。

ハッカー集団は「日本の危機管理は甘く、格好の標的」と豪語していた。

CIAなど海外の情報機関が日本企業の情報を盗み、それを自国の当該企業などに流して日本企業をとの商談を有利に進めたり、破談にしているとも警告した。

　まさに「見えない敵」との戦いが激化していたのだが、日本の危機管理はユル褌だった。

宮脇は皇宮警察本部長から内閣広報官（中曽根政権）。退官後もハッカーの究明と、事件の概要のレポートなどを作成する個人事務所をもっておられ、その頃、筆者も何回か氏とあった。

　欧州のサイバーセキュリティ対策は米英とともに進んでいる。『欧州サイバー事故リポジトリー』（ＥＵＲＥＰＯＣ）の調査報告では、常習犯的なハッカーグループは６７９���確認されているとする。

リポジトリーとは『貯蔵庫』『倉庫』だが、転じて『データベース』「アーカイブ」の意味で使われている。

▼ハッカーの識別では案の定、中国がトップ、ついでロシア

　同ＥＵＲＥＰＯＣが２０００年から２０２３年までの注目すべき「ハッカー事件」を調べてデータベース化したところ、ハッカー発信の国別シェアがまとまった。

　発信元不明　　　４４・８％

　中国　　　　　　１１・９

　ロシア　　　　　１１・６

　イラン　　　　　　５・３％

　北朝鮮　　　　　　４・７

　ウクライナ　　　　２・６

　米国　　　　　　　２・３

　パキスタン　　　　１・８

　トルコ　　　　　　１・７％

　ほか　　　　　　１３・４％

（出典　ＳＴＡＴＩＳＴＡ）

　

国家そのものの政治宣伝目的のハッカーは全体の三分の一、そして身代金要求のハッカー集団は、エネルギー、発電、通信目、医療機関、運輸などを攻撃目標にしている。

中国では民間企業の「アイスン（ＩＳＯＯＮ）」などにハッカーの機密盗取などを委託していることは前号までに小誌でも紹介した。

中国は米国官庁、大企業、ペンタゴン、ハイテクラボ、大學などから機密データを大量に盗み出していたことも判明している。米国のサイバーセキュリティ庁（ＣＩＳＡ）、国家安全局（ＮＳＡ）、そしてＦＢＩはこうした実態の脅威を警告している。

　日本の警察庁にはハッカー対策部隊があり、先頃インターポールと組んで犯人逮捕に漕ぎ着けている。コンピューターウイルス、ランサムウェアで攻撃を仕掛けるハッカー集団「LockBit」の主犯格二人を摘発した。

このLockBitランサムウェアは、ユーザーがPCやスマートフォンなどにアクセスできないようにし、身代金を要求するソフトウェアだ。多額の身代金を要求できそうな標的に暗号化する。

被害者が要求に従わない場合データを盗難し違法に公開すると脅迫する。

LockBitの標的は国家機関や医療機関、金融機関など、業務を妨害して多額の金銭を要求すれば、応じる可能性が高く、資金力のある組織の狙い撃ちが得意。だが、ロシアやCIS（独立国家共同体）の国々のシステムへの攻撃は意図的に避けている。

日本の警察庁ハッカー対策部隊は、被害にあった団体や組織などのデータベース復元に成功している。

[gu4]

サン・マイクロシステムズ（以下、サン）に強い憧れを持っていたため転職しました。私は大学時代にUNIX関連のOSに触れていました。そして大学院時代にはJavaの研究を行っていたので、Javaを生み出しSunOS/SolarisというUNIX系OSを提供する会社であるサンに入れば、力を発揮できると思ったのです。 しかし、最初から希望の部門で働けたわけではありません。最初はシステムのサポート部門に所属しました。完全な裏方仕事で、Javaのサポートもあまりなく、SolarisのOSに関する問い合わせが圧倒的に多かったのです。この時期はJavaアプリの開発から一時的に遠ざかっていました。その後にサンの組織構造の変更に伴って部署を異動し、私が本当に行きたいと思っていたJava系のソフトウェアのコンサルティング部門で働けるようになりました。 このときの経験を踏まえて、読者の方々に伝えたいことがあります。私はサンに入ってすぐに、表舞台で大活躍をしたわけではありません。サポート部門というと問い合わせを受ける立場ですので、お客さまからお叱りをいただくことも多々ありました。でも私のキャリアにおいて、その経験をしておいて本当に良かったと思うのです。 そこで仕事をしたことで「自分とは異なる立場で働く人たちに気持ちよく仕事をしてもらうためにはどうすればいいか」を考えるようになりました。また、サポート部門は障害に関する調査を行うことも多かったため、問題調査能力、解決能力が飛躍的に伸びたのです。若い方々は、自分の望んでいた配属先で働けず気落ちしてしまうこともあるかもしれません。ですが、置かれた場所で一生懸命にがんばっていれば、習得したスキルは必ず自分の武器になります。

逆境でも乗り越えられたのは、心の底からJavaが好きだから。「#てらだよしおがんばれ」に支えられた半生 - Findy Engineer Lab - ファインディエンジニアラボ

[moment-japan]

フリーの楽譜作成ソフト「MuseScore」

MuseScoreは、ベルギーのブリュッセルを拠点に開発されている無料の楽譜作成ソフトウェアです。

楽譜作成ソフトの中で最も有名なのが一般販売されている「Finale」ですが、それにも引けをとらないパフォーマンスを持つフリーソフトがこのMuseScoreです。

サンプル画像は英語表記ですが、日本語で表記・製作できます。

（マニュアルも日本語）

MuseScoreには、調号、拍子、臨時記号、移調、演奏時のアーティキュレーション指定、スゥイング、各種テキスト・歌詞表記（フォント指定含む）、アルベジオ、グリッサンド、スラー、各種強弱等のヘアピン記号、装飾音符、連譜、オクターブ線、繰り返し、ジャンプ反復番号括弧、楽器のチューニングやピッチ変更等、譜面作成に必要な記述系は全て揃っています。

また古典音楽よりも古い音楽である古楽（バロック、ルネサンス音楽）の譜面も製作できます。

（これは結構凄い）

ギター１本の弾き語り用から大編成のオーケストラ譜まで柔軟に製作できます。

弦楽器においてはタブラチュア（TAB譜）も作れます。

タブ譜は初心者用の楽譜指定と思われがちですが決してそうではありません。

弦楽器は弦やフレットの位置によって同じ音でも違う響きになります。 そういったマニアックで細かい指定を生かせるのがタブ譜の利点でもあります。 フォークギター用にカポ指定も出来ます。

このソフトは無料でありながら、フレットボードダイアグラムパレットというのがあり、そこにはダイアトニックスケールトーンが装備されていて、標準でメジャー、マイナー、セブンスコードからなるダイアグラムがあり、それらを譜面に美しく表記できます。

（フレットボードダイアグラムとは、よくギターの楽譜にコードの押さえ方を書いたイラスト表のあれです。）

また、チューニングやピッチの変更表記も可能。

弦楽器、鍵盤楽器、ブラス・木管系を問わず、楽器ごとにフィンガリング（使う指）指定もでき、楽器初心者や和楽器にも優しい作譜が可能です。

リズムセクションではドラムセット、パーカッション類の細かい変更・指定もでき、ドラム譜（各種リズム含む）はMIDIキーボードやパッド、ＰＣキーボードからリアルタイム入力もできます。

出来上がったスコアはMIDIでプレイバック再生が出来、ピアノロールエディターも装備、SFZといったサンプリング系サウンドフォント系フォーマットも普通に指定、再生できます。

ミキシングセクションでは譜表途中での音色変更も可能で、DAWソフトで使うような細かい指定をして音を鳴らすことができます。

「Community」といういわゆるクラウドサービスのようなサイトがあり、作成した楽譜をやり取りしあえるということができて、有名な曲をアレンジした作品やオリジナル作品のやり取りが活発に行われているようです。（一部有料）

DAWソフトと同じように覚える部分が膨大にある譜面作成ソフトですが、MIDIデータをインポートして譜面表記と再生も出来るので、市販のデータを読み込んで楽曲の解析・研究も出来る優れたフリー・ソフトウエアだと思います。

上記の楽譜「大きな古時計（おじいさんの古時計）」はこのソフトの楽譜から鳴らしたものです。下のアドレス 「Community」 で聞くことが出来ます。

（製作者にお礼）

https://musescore.com/k_kobayashi/my-grandfather-s-clock

[fantasybrade]

ディスガイア7クリアした

なんか勢いで買ってクリアした 自分はずっと最近の日本一ソフトウェアからは距離を置いていた

あ～～～ もうその辺から全部もうかいとこ…

中学生の時にプリニーの体験版をPSPでプレイしてからこのシリーズにのめりこんでいた 1234とプレイし、青春はディスガイアの中で過ごした

自分がディスガイア周りに「ん…？」ってなりだしたのはD2からで プレイ開始直後からバストアップイラストの異様な数の少なさや、なんか面白みのないGUI、キャラクターのアイコンイラストが新規でない、などの、細かいところがすごく気になっていた いざクリアすると、初代ディスガイアの続きのストーリーなのに影も形もなくなった地球勇者一行とか、なんかよくわからない女体化エンドや突然に現れたメインキャラの兄・妹 なんか、怪しい雰囲気がしていた

しばらくして発売した5で、「ん…？」は「んんん…………？？」くらいになってた 発売前はドット絵のクオリティが4以上に上がっていたり、キャラデザがカラフルでわくわくしたし、GUIもかなり仕上がっていて今までにないディスガイアを体験できると楽しみにしていたんだけど とにかくシナリオが変で、なんだ、これ…？みたいになっていた

5のストーリーはそれまでと比べても特に王道っぽいんだけど 妙にノリが強いというか ディスガイアのキャラにしては、なんかアクのない面子が集っている感じがあって それぞれが自分たちの心に何か重たいものを抱えていて、それを一人ずつ克服して「家族」になっていく そういう、自分がディスガイアに求めていない優しさみたいなものが作品にすごい詰まっている感じがして 妙な違和感 キャラクターが出会って面子が揃うと、そのままそれぞれのキャラクターの過去克服成長パートが始まる 一章につき一人一人が順番に過去を克服して成長していく ここらへんで「なんか、順番にやってんな…」みたいな感じになってかなり変な感じがするんだけど キャラが自分たちで「今度は◯◯さんが過去を克服するんだね！」みたいな感じで自分たちでそのシナリオを茶化し始める え、え…？みたいになったのを今でも覚えてる

やっていることはこれまでのシリーズも同じようなもので キャラクターが一人ずつ増えていき、パーティメンバーが揃い、そしてそれぞれの過去を克服して、黒幕を倒す 同じはずなのになんか、なんかメチャクチャ雰囲気違うな…と思った

ノリが寒いとか言いたいのではない ディスガイアはそもそもノリが寒い 俺はそのノリの寒さがメチャクチャ好きだったんだけど 寒さの種類が変わっちゃった感じがあって 急にいきなり受け入れられなくなった

で、ディスガイアRPGっていうソシャゲが出るわけですが ここで、なんか決定的にノリの合わなさを感じて、日本一ソフトウェアと距離を置いた ここらへんで気づいたんだけど多分おれはなってしまっている、反転アンチに 自分が見ていた頃のディスガイアのスタッフではない人が作っているディスガイアを受け入れられなくなって発狂してしまった

6が発表されて、キャラグラフィックが3Dになった時は仰天した ここまでドット絵のクオリティを上げてきたのにここで3D サモンナイトが死んだ道を歩き始めたと思った 3D化があまりにショックで6はシリーズで初めて買わなかった いずれやろうとは思っているんだけど、値段に尻込みしてしまう シリーズにのめり込んでる時は値段とか全然見てなかったのに

それで、6から間もなくしてすぐ7が発表されて…

7を買ったのにはいくつか理由があった ・ピリリカがかわいい ・ピリリカの声がかわいい ・鬼滅ブームにスーパースピードで乗っかるのおもろい ・7なので7人の侍ってこと？おもろ！ ・公式サイトに書かれてるあらすじがいい感じに怪文書っぽくてディスガイアらしさを感じた

そしてなにより、「ガレリア」のこともある D2に疑問を感じ、5にショックを受けている間、自分はずっと魔女シリーズの方にのめり込んでいた 初めてプレイしたのが「プリニー」だったのもあって、泉氏がディレクションするディスガイア感がすごく肌に合った 魔女と百騎兵に衝撃を受けて、「ルフラン」の完成度の高さに惚れ込んで、「ガレリア」もプレイしたんだけど 「ガレリア」には、正直なところ複雑な気持ちがある ストーリーもぼろぼろ泣いたんだけど、それ以上に未完成なゲーム部分がすごく目についてしまって(公式設定資料集の1ページ目がディレクターの謝罪文から始まるゲームってどうなの？の気持ち) それに、なんかシナリオ部分も妙な尖り方をしていて… ディスガイアシリーズと��また違った意味で、こちらにもなんというかすごく複雑な思いを抱くことになってしまった 好きなんですけどね

そういうのもあって長らく目を背けていたディスガイアシリーズにもまた触れてみようかなという気持ちになっていた

それで、7をクリアしたんだけど もうディスガイアは完全に自分の知らないものになってしまった

まず、3D空間上のイベントシーンが一つもない　全てがバストアップイラストの掛け合いで行われる その場で起きている出来事を絵で説明できないから、キャラクターが出来事をすべてセリフで喋る 「ものすごい勢いで◯◯さんが建物を破壊しながらこっちに近づいてきます！！」みたいな チュートリアルもキャラ同士のかけあいの中ひとつひとつ教えるのではなく、ゲーム開始直後にいきなり17ページある文章を読まされる こういうの細かい部分だとは思うし作り手側の様々な気持ちを組み切ることはできないんだけど 私にはこれらがとにかく印象として悪かった

ストーリー部分も、自分はほとんどついていけなかった ノリは相変わらずだと思う キャラクターが仲間になる過程、それぞれの抱えてた問題が発覚する過程、いろんな部分に極端な描写不足を感じる 成り行きで集まったメンバーのはずなのに、なんかいきなりみんなメチャクチャ仲良く打ち解けているというか あまり具体例を上げたりするとちょっと悪口っぽくなって嫌なんだけど

例えばこういうところで、「いや、お前が言う…？」みたいな気持ちになったり(他のキャラからフォローがない) シーフォーとスイセンは特にヤバかった印象 次回予告はこれまでのパロディに加えてネットネタも多く、にぎやかだったとは思うけど これもほぼついていけなかった

ディスガイアは、4以降明確に「絆」を描くことに徹底している印象がある 私は4の、主人公の思い描く絆のイメージ像が一般的なものと少しズレているような、それでいて、他のキャラクターたちもちょっと困惑しているような、ああいった部分に味わいを感じていた 5,7で描かれている絆に、正直私は平坦な印象を受けた キャラクターの相関の矢印がどれも同じ大きさの友愛であり、感情に大小がなく、一致団結している

4は良くも悪くもシリーズの方向性を決定付けたような印象があり、そこに自分と制作スタッフの解釈の違いが生まれてしまっているのだろうと思う

総評として、このシリーズと自分には大きな距離があることを再確認してしまったことになるんだけど 7はユーザーにとにかく好評で、6で失った信用を見事に取り戻した印象がある 自分はここまでダラダラと文句を言ったわけだけど、自分以外はとくにこういう問題を感じていない メインのユーザーが満足しているならシリーズの作品として何一つ文句はない

自分は魔女シリーズが大好きだけども 毎回のように延期して、挙げ句ガレリアに至っては未完成品を提供して画集で謝罪しているDを見て、かなり複雑な気持ちになった 対してディスガイアは、6でユーザーから出た不満を全て解決した上に、かなり短い開発期間の中で削れるところは削り、力を入れるところはとことん力を入れて、延期もせず予定通り発売して5万本を売り上げている。6があれほど酷評されたというのに… 失った信用を迅速に取り戻し、これからのシリーズに繋げながら一作としてもとても良い作品になっている そういう意味で、自分の離れてしまったシリーズが今もちゃんと生きていることを確認できたような感覚があって、そこはすごい嬉しかった 今作を担当したDや、現在のディスガイアスタッフにたいする巨大な尊敬があります それに7は、テキストの節々に「ディスガイア節」のようなものを感じることがたくさんあって、それもなんか嬉しかった 全体のノリにはずっと馴れなかったものの、「これこれ！」みたいになるシーンはとても多かったように思う

インフィニットの「俺様が暗殺されたぞ～！」といい、ディスガイアにはこういうテキストをよく見かけるイメージがある

ピリリカは喋るたびに面白い

この辺は、「おお、俺はディスガイアのテキストを読んでいる・・・！」みたいな大きな感動がありましたね 「悪魔将棋」に関してはいかにもディスガイアの世界に存在するバカすぎるゲームって感じで、ノリに懐かしさを感じます

それに、いろんな部分で過去作から削られたものを感じながらも、新しい「魔界観光」システムなんかは作品に対するスタッフの愛を感じてなんか嬉しくなった このパスタ屋さん、こうやって後から話しかけることができるだけで、ぽっと出のキャラとしても印象がガラッと変わる 過去作ネタの入れ方とかも、しれっとバレないように仕込んでる感じがあって、スタッフはシリーズが好きなことがすごく伝わってくる

今作は「ピリリカ」と「フジ」、どちらも主人公だと捉えられるようなストーリーになってたけど、そこにも納得があった ピリリカ、(物語の役割としての)ポジションはフロンなんだけど、同時にこのキャラクターはヴァルバトーゼ的でもある(執事がいるし、超・性善説の描写を見るに明らかに意識されていると思う)　2つをうまく混ぜたような造形で(まあそれより遥かにマチカネフクキタルなんだけど) 彼女が物語の中で主人公がいるべき場所に居続けるのには大きな納得があった フジはラハールのように自分の父親を乗り越えるのだけど、過去に抱えた問題にはキリアを彷彿とさせる部分もある ピリリカが死んだフジを蘇らせるシーンには、初代ディスガイアに対する大きなアンサーのようなものを感じた 死ぬ方と生き返らせる方が、ディスガイア1と反対になってる ネタ部分で今作はジェンダーレス的な部分に触れまくっていた感じもあって、ここらへんかなり楽しめた って、ストーリーの骨組みだけを見ると、自分は結構この作品が好きで ただノリだけがずっとわからなくてついていけなかった 彼らの間にある絆やそれぞれの思いみたいなものが、描かれていることだけはわかるけど、描かれているということ以外はわからなかったというか まあどう考えてもユーザーとしての自分が間違えてる

ようはシリーズに対しての愛情の方向性が、1ユーザーとしての自分と、制作者の間で少しだけズレていただけなんだろう

魔女シリーズの方も、ディスガイアに対する愛情を節々に感じるのですが こちらはこちらで愛情が歪な形すぎてちょっと困惑するところがあります 魔女シリーズって新作出るのかな…

[mesotokyo]

xTool M1で木材を加工してみる

先日購入したレーザー加工機「xTool M1」で木材を加工してみた話です。

レーザー加工機「xTool M1」を買った話の続きです。ひとまずパッケージを開梱して設置してみたので、続いてはレーザー加工機購入の主目的である切断・彫刻加工を試してみました。

Inkscapeで描いた図を基に切断加工をやってみる

xToolシリーズには専用のソフトウェアとして「xTool Creative Space（XCS）」というソフトウェアが付属しているのですが、単体で複雑なデザインを作るのは大変そうなので、フリーのドローソフト「Inkscape」でデザインを作成し、それをXCSにインポートするフローを試してみます。

まずInkscapeでカットする部分をパスで描きます。ちなみにこちらは自作のLEDコントロールユニットをモジュラーシンセケースの1U部分にマウントするためのパネルです。

続いてXCSを起動して、まず加工対象の設定をします。

今回は2.5mmのMDFを使用したのですが、素材のプリセットに同等のものがなかったので多分似たような感じの3mmバスウッド（＝シナ）合板を選択しています。また、M1に付属する三角柱を板の下に敷いて加工するので、「底上げした高さ」は「三角柱」を選択しました。

続いてInkscapeで作成したファイルをXCSに読み込ませます。Inkscapeのデフォルト保存形式はSVGで、XCSではこれを直接読み込むことができます。XCSに読み込ませたあとにパスを選択し、加工モードとして「切断」を選択して「設定」を参照にすると、自動的に加工パラメータが設定されます。

続いてxTool M1の電源を入れてPCと接続した状態で「再読み込み」ボタンをクリックすると、内蔵カメラで加工機内の状態が撮影され、加工される大まかな位置を確認できます（この段階で画面キャプチャを撮るのを忘れていたので次の画像は別のときに撮影したものです）。

ただ、この写真の位置通りに厳密に加工が行われるわけではなく、若干ずれが発生します。そのため、加工エリアの外周にそって光を照らすだけのレベルのレーザーを照射して加工範囲を確認する「フレーミング」を行います。これは「フレーミング」ボタンをクリックすれば実行できます。

加工範囲が素材内に収まっていることを確認したら、その後「加工」を実行します。なお、フレーミングも加工もXCS上で操作を行ったあとに、本体側の前面にあるボタンを押して初めて開始されるする仕組みです（必ず本体の状況を確認してから加工を始めさせるための制約と思われます）。

本体側のボタンを押して加工をスタートさせたら、あとは加工の様子を眺めるだけです。今回は加工範囲が小さいので1～2分ほどで完了。次のようなものができました。

レーザー加工機は対象を高熱で焼き切って切断するので、木材の場合切断面が焦げて黒くなります。さらに切断した部分の付近にスス汚れも付きますが、これは中性洗剤（食器洗い洗剤）で水洗いすればおおむね落とすことができます。上の画像も若干表面が汚れていますが、そちらは水洗いできれいに落とすことができました。

洗浄後、基板を取り付けたものがこちら。設計通りにできました。

彫刻加工をやってみる

続いては、文字や図形をレーザーで彫る彫刻加工で、自作エフェクターのパネルを作成してみます。XCSでは要素ごとに加工方法として彫刻と切断を選択でき、同時に彫刻と切断を行えるようなのですが、今回は彫刻用のデータと切断用のデータをそれぞれ別々に作成していた関係で、切断→彫刻の順で別工程で加工をしてみました。

切断工程については基本上記の手順と同じなので割愛。彫刻に関しては以前写真用紙に印刷してパネルを作ったデータを流用しました。なお、文字データに関しては適切にインポートできない可能性があるため事前にパスに変換しています。

これを先ほどと同じようにXCSにインポートして、加工方法として彫刻を選択します。

あとは同じようにフレーミング→加工を実行するだけです。なお、彫刻の場合は切断の場合と比べて加工速度がとても速い設定になっているのですが、細いレーザーを彫刻する面積全体に照射するため、切断よりも時間がかかりました。

最終的な完成品はこちら。文字の部分をもっとしっかり焦がした状態にできると良いのですが、そのあたりは試行錯誤が必要そうです。

[capybara-is-watching]

大規模言語モデルが、100万行ものエンタープライズ・プログラムを書ける日は来るだろうか？ と最後にルキダスは問いかける。おそらくは来るだろう。しかし、それを指示するプロンプトを誰かが書かなければならないということを意味する。それを行う人間は、問題の複雑さを理解し、それを管理するというプログラミングの宿命といえる問題に直面することになると締めくくっている。

ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴

The Real Problem with Software Development – O’Reilly

オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。

[kennak]

人間は人生に満足と意味をもたらす仕事を求めます。 技術が進歩するたびに、最初に廃れてしまうのは職人たちです。 確かに、使い古された繊維でいっぱいの埋め立て地があり、市場はそれが良いと言っていますが、全体として、私たちは人間が意味を求めることを可能にするものを破壊し続けています。 私たちの政府と社会は、価値を生み出さなければ尊厳に値しないことを明確にしています。 アートをコンピューターに委託しているので、アートを理解していない人でもすぐにアートを手に入れることができます。 今はエンジニアリングを外注しているので、分からない人でも安くやってもらえます。 治療法を理解していない人が AI がセラピストになれると示唆したり、医学を理解していない人が AI が医師に代わることができると示唆したりする話を聞きます。 何が残るでしょうか？ 私たちはどこにいるのでしょうか？ 尊厳も目的もなく立ち往生し、価値を生み出さなくなったときに朽ち果てるままに放置されます。 私は複数の文脈でこの質問をよくしますが、その目的は何でしょうか? こうした進歩の恩恵を受けるのは誰でしょうか? CEOや株主もそうでしょうが、何かをより安く見つけられるからといって、それが生活を改善するわけではありません。 私たちの服は一年も持たない、靴はボロボロになる。 当社のデバイスにはあらかじめ定められた有効期限が設定されています。 将来私たちはどこにいるのでしょうか？ お金に生まれた人々は、お金を回し続けることができ、数字が上がることを求める貨物崇拝が行われます。 しかし、他の人はどうでしょうか？

デビン: AI ソフトウェア エンジニア | ハッカーニュース

[worktank-no-sekido-desu]

From: Worktank info@bcage.net Reply-To: info@wtage.net Subject: 人材紹介手数料は不要。直接　ITエンジニアをご紹介します！ 人事採用ご責任者様 いつもお世話になっております。 株式会社ワークタンクの関戸と申します。 ①SESの場合 　エンジニアの所属会社を直接ご紹介します。 　単金に上乗せはいたしません。 ②エンジニアを採用する場合 　年収３０％の紹介手数料は不要です。 【今すぐ採用予定あり　　】 【または近日中の予定あり】 の方はすぐ、ご対応いたします。 案件情報がありましたら、メールしてください。 すぐに候補者を返信いたします。 案件情報を頂く際は、 ★開発言語 ★ご連絡先携帯番号 ご提示頂きますようお願い致します。 申し訳ございませませんが、 ZOOMやWeb会議は制限があるため行っておりません。 ===================================== mailto:info@wtage.net まで 株式会社ワークタンク 担当:関戸　（せきど） TEL : 03-5324-2815 ○電話　平日月～金８：３０～１８：００まで 　それ以外の時間は、お手数ですがメールでご連絡下さい。 　ご返信いたします。 ・゜゜・:.。..。.:・゜・゜゜・:.。..。.:・゜・゜゜・:.。..。.:・ 【今週の登録者】 ☆38才　JAVA開発経験 ☆36才　サーバー構築経験 ☆31才　Python開発経験 他にもJAVA .net C++ Linux Oracle　サーバー構築　ネットワーク等のエンジニア が登録しておりますので、何なりとお申し付けください。 //////////////////////////////////////////////////////////////////////// ID 039 性別 男性 出身地 静岡県 現住所 東京都 年齢 38 最終学歴 ４年制理系大学卒 勤務先の業種 ソフトウェア・情報処理 現勤務先の従業員規模 100～299名 現在の年収 550 ～ 600 万円 現在の勤務状況 在職中 経験職種・経験年数 プログラマー(Web・モバイル関連) 　J2EE/J2SE 5年 　JavaScript 5年 　PHP 4年 Webサーバー設計・構築 　Linux 4年 社内SE 　社内SE 5年 語学関連のキャリア 検定資格 会話能力 所有資格 希望雇用形態 正社員 委託社員 希望職種 プログラマー(Web・モバイル関連) 希望の勤務地 東京23区 横浜・川崎 愛知県 職務経歴 業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語 ソフトウェア・情報系 プリペイドカードオンラインチャージシステムリプレース 業務系(ＷＥＢ系) [ ＥＣ：販売系システム ] 100人以下 基本設計 詳細設計 プログラミング サーバ設計/構築 OS： Linux データベース： MySQL Java JavaScript PHP システム構成は、AWSを使用した標準的な構成でOS、PHPのバージョンアップ案件でした。 ・PHP5.4→PHP7.3 ・FWはEthna→Codeigniter EC2インスタンスに実装でしたが、PHPのバージョンが変更されるのでWebサーバも一新しました。 EthnaからのCodeigniterへの実装でしたのでほぼ一新しました。 旧環境から新環境への切り替え時に、ダウンタイムゼロの要件だったので同時接続を考慮した実装に苦労しました。 //////////////////////////////////////////////////////////////////////// ID 099 性別 男性 出身地 三重県 現住所 東京都 年齢 36 最終学歴 ４年制理系大学卒 勤務先の業種 ソフトウェア・情報処理 現勤務先の従業員規模 100～299名 現在の年収 500 ～ 550 万円 現在の勤務状況 在職中 経験職種・経験年数 ネットワークエンジニア(設計・構築) 　ルータ(Cisco) 5年 Webサーバー設計・構築 　Linux 4年 語学関連のキャリア 検定資格 会話能力 　英会話 日常会話レベル 所有資格 希望雇用形態 正社員 委託社員 希望職種 Webサーバー設計・構築 希望の勤務地 東京23区 東京都下 横浜・川崎 神奈川県下 愛知県 三重県 職務経歴 業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語 ソフトウェア・情報系 ■仮想基盤構築支援 インフラ(基盤)系 [ サーバー ] 100人以下 サーバ設計/構築 OS： Linux 仮想ソフト： Vmware ≪担当業務　取得技術≫ 　・仮想基盤サーバの構築/設計 　　OSはESXiサーバ 　・VMWare仮想環境の構築技術 　��基本設計書、パラメータシート等構築時資料に関する知識 　・テスト実施のための資料作成/実施準備に関する知識 ≪コメント≫ ・本番環境にて稼働中のシステムに対し、 　仮想基盤サーバの追加、および業務用仮想マシンの複製を実施。 　システム運用メンバーと連携しながら構築作業に従事。 //////////////////////////////////////////////////////////////////////// ID 370 性別 男性 出身地 千葉県 現住所 東京都 年齢 31 最終学歴 専門学校卒 勤務先の業種 ソフトウェア・情報処理 現勤務先の従業員規模 50～99名 現在の年収 600 ～ 650 万円 現在の勤務状況 求職中 経験職種・経験年数 プログラマー(Web・モバイル関連) 　C/C++ 4年 　C# 5年 　Python 3年 語学関連のキャリア 検定資格 　TOEFL 601～650点 会話能力 所有資格 希望雇用形態 契約社員 委託社員 希望職種 プログラマー(UNIX系) 希望の勤務地 東京23区 東京都下 横浜・川崎 神奈川県下 職務経歴 業務内容/プロジェクト 開発ジャンル 規模 担当 開発環境 使用言語 ソフトウェア・情報系 ロボット用Linux組込開発 制御・ファーム系 [ 工業／FA機器 ] 100人以下 基本設計 詳細設計 プログラミング C++ Visual C# １社目ではＸ線発生装置の開発を経験し、電子銃とＸ線ターゲットの設計、試作及び性能評価を担当しました。 海外子会社との共同開発や海外研究者とコンタクトを取りながらの開発業務を経験しました。 2社目以降では、ジェットエンジン及び爆発事象に関するCFD解析、ネットワークセキュリティ関連ソフトウェア開発、 ロボット用Linux組込開発、マシンビジョン開発、顧客データシステム運用・管理を担当しました。 倉庫内搬送用ロボットのマシンビジョン関連開発 ロボットに搭載されたカメラのキャリブレーション法の改良、 搬送ロボットのルートの床に貼付されたマーカーの読み取り方法の改良。 ・カメラを用いた実験及び既存のアプリケーションの改変。 Windows，Ubuntu(Linux)， PYthon，Visual Studio， Open CV，FlyCapture， tortoise SVN，VMWare、 倉庫内搬送用ロボット等 産業用ロボットアームの組込開発・アプリケーション開発 ロボットアームのティーチング・ペンダント用GUIの開発。 ・Linuxカーネル，デバイスドライバ，Linux組込ボード（1GHz ARM Cortex A8） 　Ubuntu(Linux)，GCC, GNU Make，C言語，C++，Qt4.8，GitHub，redmine

2023.12.27 From: Worktank info@bcage.net

[moko1590m]

かつてない自律機能を目指す巨大なロボット戦車RHP 　比較対象がないのでわかりにくいが、RHPは重さなんと12トン、長さ6メートルの大型戦車だそう。 　特筆すべき点はまだある。RHPのミッションは前述したとおり、でこぼこな無舗装面や道なき道など、複雑で予測しがたいオフロードを走行するという戦闘規模の自律性だ。これは従来の戦車にはない機能となる。 　なおRHPには、米テキストロンシステムズ社開発の Textron M5 ベース プラットフォーム が使われている。 　このプラットフォームは、以前アメリカ陸軍が行った新技術や新戦略の開発活動の向けに同社が開発した、無人戦闘車両 Ripsaw M5 の設計の基礎になっている。 　 つまりRHPの場合は基本 Ripsaw M5と同様の設計で、そこに今回のRACERプログラムの自律制御ハードウェアとソフトウェアが追加されているという。 緑色の「目」がある戦車として話題に 　しかしとりわけ注目されているのが、印象的な緑色の「目」だ。 　これは実際には、車両のステータスを示すインジケーターライトで、緑色に光ってる時が自動運転モードのオンを示すそう。確かに緑じゃない時もある。その時は遠隔操縦中なのかも。 　と知っても、やはり一種の目の錯覚、シュミクラ現象というかパレイドリアというか、この2つのライトが目にしかみえない。配置も正面の絶妙なところだし、一度そうなるとそんな風にしか見えないんだわ。 　それだけでDARPA自慢のRHPが顔のある戦車になるから不思議。まるで何かのキャラみたいで親しみまでわいてくる。ただよくみるとこのライト前後両方にあるような？

(緑色に光るライトが目に見えて親しみがわいてくる、DARPAの自律走行の新型戦車 : カラパイアから)

[petapeta]

Windows HeartBeat #9 (1994年3月) 永久プログラマー 　このところ、ハードウェアとソフトウェアが車の両輪のように、うまく歩調を合わせて、進化している。7、8年前、Windowsやページ記述言語のPostScriptに出会った時、どうして、こんな大げさなソフトウェアが必要なのか、疑問を持った。8086や68000など初期の16ビットMPUが全盛の時代に、システムサイズが600KBや1MB近い基本ソフトは、処理速度も遅く、普及するとは思えない代物であった。 　4、5年前、WindowsやPostScriptが米国で定着したのを見て、｢ソフトウェアの開発には時間がかかる。���ードウェアの急速な進歩を見越して、数年先を先取りしたシステムデザインをしなければならなかったのか｣と合点した。 　そして現在、開発に時間がかかるはずのシステム・ソフトウェアが、ハードウェアと同じスピードで、どんどん変化している。 　新しいソフトウェアが矢継ぎ早に発表される背景には、米国を中心としたコンピュータ・サイエンスに対する基礎研究の充実と、膨大な良質のソフトウェア資産の蓄積、そしていくつかの極への開発の集中が挙げられる。極とは、マイクロソフト、アップル、IBMなどのシステム・ソフトウェア・メーカーである。 　システム・ソフトウェアの変化が激しくなると、アプリケーション・ソフトウェアの開発者は、その理解のために、開発時間の多くを割かれることになる。Windowsにしても、開発キットに添付されているサンプル・ソース・プログラムを試し、入門書を読み、プログラマーズ・リファレンス・マニュアルを眺めないと、その｢思想｣は理解できない。　DOSには、思想など存在しなかったが、Windowsは明らかに思想を持っている。思想に反した使い方やプログラミングを行なうと、Windowsはぎこちない動きをしてしまう。 　ソフトウェアの作成工程は、設計、開発、試験の3工程で、工数は各工程でちょうど3等分されると昔からいわれてきたが、Windowsのアプリケーション開発では、その前に｢調査｣という工程が入る。思想を理解する工程である。Windowsは、グラフィックス、テキスト操作、メモリ管理、フォント操作、デバイスドライバなどで様々な思想を持っている。DOSでは生き字引きが何人もいたが、Windowsのすべてを理解している人は、世界中探しても見つからないであろう。Windowsプログラマーといっても、開発実績を持つ特定分野のことは理解していても、他の分野については素人である。新しいソフトウェアを作る時には、Windowsプログラマーといえども、先ずは調査をして、あれこれ試してみる必要がある。 　Windowsだけをとっても、たくさんのソフトウェア技術者が毎日、たいへんな苦労をしながらプログラミングしているのが、日本の現状である。その上、今後、C++を理解し、クラスライブラリの使い方を覚え、OLE2やODBCを使いこなさねばならない。 　昨年のComdex/Fallで華々しくデビューしたMicrosoft Office4.0では、アプリケーションが画面上にアイコンとして表示される、新しい試みがなされている。また、Word6.0では、ダイアログ内にメニュー展開用の｢タブ｣という新しいユー��・インタフェースが採用された。MDI(複数文書操作)、OLE(オブジェクト結合手順)などの例に見られるように、アプリケーション開発チームが実現させた基本機能を、システム側が取り込むのがマイクロソフトの通例となっている。アイコン表示やタブもその内、OSの機能として組み込まれるのであろう。Windowsの次バージョンであるChicagoで、タイトルバーの文字列表示が左寄せに変わっても、アプリケーションでは何の変更も必要ない。しかし、タブをサポートするためのは、ユーザ・インタフェースの設計からやり直さなければならない。 　Excel5.0のような、3Dの立体感のあるダイアログの作成でも、Windows3.1の開発キット(SDK)を使って実現するには、結構苦労した。それが、VisualC++1.5のMFC2.5には、標準ライブラリとして入っているらしい。VC++1.5にはもっと大切なOLE2対応のクラスライブラリや、ODBCの各種ドライバも入っている。Accessエンジンもロイヤリティなしでアプリケーションに組み込んで使えるのである。開発環境も、いつになく速いペースで改善されつつある。 　システム・ソフトウェアや開発言語が、急速に進歩する｢過渡期｣であるため、プログラマーは勉強の連続になってしまう。過渡期といっても、この状態が21世紀まで続く可能性があり、Windowsソフトウェアを開発しようとしても、どこから、何に手を付けて良いやら分からない状況となりつつある。高級なクラスライブラリやオブジェクト指向OS、Visual Basic for Application(VBA)のような1ランク上の開発ツールの出現など、待てば待つほど、充実した開発環境でプログラミングが行えることが目に見えている。　パソコン・ハードウェア本体の｢半年で旧型機｣と同じサイクルにシステム・ソフトウェアも突入してしまった。東芝の部長さんが言っていた｢最高のダイナブックが欲しければ、死ぬ1日前に買いなさい｣というブラックジョークが笑えなくなってきた。　最高の開発環境で仕事をしたければ、死ぬ1日前に着手しなさい｣ではプログラマーは誰も笑えない。 　開発に着手したプロジェクトでは、更に話は複雑である。 　A君は優秀なWindowsプログラマーである。彼は、1年半ほど前に、｢これからはC++の時代だ｣と一念発起して、マイクロソフトC/C++7.0とクラスライブラリMFC1.0を使って、アプリケーションを作り始めた。半分ほどプログラミングした時点でVisualC++1.0が米国で出荷された。その開発環境の良さやMFC2.0の高級な機能に刺激されて、VC++に開発環境を移行した。MFC1.0は、Win16APIにクラスライブラリの皮を被せただけの簡単なものである。彼はこの上に、独自の高級なクラス構築していたのだが、MFC2.0が見事にそれを葬ってくれた。MFC2.0に合わせて、モジュール構造から作り直すのに6ヵ月ほどを費やした。 　そして、今、彼はVC++1.5への移行を真剣に考えている。ソフトウェアを出荷できるのは、いくらがんばっても今年の年末。その頃にはExcel5.0やWord6.0の日本語版も出ているに違いない。｢OLE2をサポートしないソフトなんて、みんなに見向きもされないのでは?｣と心配している。VC++1.5に付属しているMFC2.5のOLE2サポート機能は魅力である。独自に裸のOLE2をサポートするなど、ひとりでプログラミングを行なっている彼にとっては気の遠くなる話だ。マイクロソフトはMFC2.5でOLE2をサポートするために、2万行ものプログラミングを行なっている。これを使わない手はない。 　Win32も気になる。半年も待てば、VC++2.0が出荷されて、32ビットで高速に稼働するアプリケーションが作れるであろう。Win32APIは、マイクロソフトが推奨しており、Macへの道も開かれるので、ぜひとも対応したい。このままVisualC++1.0で開発を続けるか、1.5に乗り換えるか、はた又、2.0まで待とうか。とにかく、MFC2.5のOLE2部分は使うことに決めたようである。 　Chicago、Cairo、OLE、ODBC、MAPIなどの登場、そしてVisualC++の立て続けのバージョンアップで、｢僕のプログラミング・スピードより、OSや言語の変化の方が、速度が速い｣と、彼は嘆いている。今年の終わり頃には、オブジェクト指向OSであるCairoが姿を表わすであろう。すると、Win32APIよりも、はるか上位のプログラムインタフェースがクラスライブラリとして提供されることになる。完璧なソフトウェアを目指す、プログラマーの鑑のようなA君は、Cairoへの対応をすぐに検討するであろう。 　こうして、プログラマーとしてA級の技術を持つA君は、プログラミングをやり続け、いつになってもソフトウェアが完成しない｢永久プログラマー｣となるのである。

永久プログラマー