  |
はてなキーワード: ランタイムとは
修正後: https://thinkit.co.jp/article/11373
差分: http://difff.jp/4jrxz.html
以下、大きく変わった箇所を抜き出します。
ちょまど：もう一つ言えば、開発ツールが無償じゃないのもなんか間違ってるって思っていたんですよ。なのでXamarinがマイクロソフトに買収されたって聞いた時にすごく喜んだんです。これでXamarinはきっとOSSになって無償になるって思って。
↓
ちょまど：もう一つ言えば、開発ツールが有償だと開発者に浸透しにくいって思っていたんですよ。なのでXamarinがマイクロソフトに買収されたって聞いた時にすごく喜んだんです。Xamarinはライセンス代が高かったけど、これによりきっと無償になるし、しかも（XamarinチームはもともとMonoチームが母体でOSS好きなのもあり）XamarinのランタイムがOSSになって人に勧めやすくなるかなって思って。
----
ちょまど：そうです。私は逆にマイクロソフトはWindowsの会社としか知らなくて、開発者になってからはVisual StudioやC#の会社で、とってもOSSな会社だって思ったんですが、入って気づいたのは世の中にはものすごくマイクロソフトがキライな人が多いって言うことで（苦笑）。なんかアンチな人が特にインターネットには多いです。
----
ちょまど：さきほどからマイクロソフトが変わって衝撃を受けていると言う話がみなさんから出てきてますけど、私からすればエディターがOSSなのは当たり前だし、開発ツールは当然マルチプラットフォーム対応だし、そういうのはもうホントに当たり前だったので一緒に盛り上がれなくて悲しいです（笑）。
↓
ちょまど：（さきほどからマイクロソフトが変わって衝撃を受けていると言う話がみなさんから出てきてますけど、）私からすればVisual Studio CodeのようにエディターがOSSなのは当たり前だし、Mac版のVisual Studioが出たように開発ツールは当然マルチプラットフォーム対応だし。マイクロソフトが変わって衝撃！ という話題で一緒に盛り上がれなくて悲しいです（笑）。
----
ちょまど：でも無料じゃない開発ツールっていうのが不思議だったんですよ、そんなことしたら開発する人も増えないし、結果的に不利益を被るのは目に見えてるじゃないですか。「どんなに良いツール作ってもお金取ったら無意味だ！」って思ってました。なのでXamarinがマイクロソフトに買収されてホントに嬉しかったです。だってAndroidとiOSの両方作ろうと思ったら1年で25万円くらいかかるんですよ。
↓
ちょまど：でも無料じゃない開発ツールっていうのが不思議だったんですよ、ベースが有料だと、開発する人も増えにくいし、結果的に不利益を被るのは目に見えてるじゃないですか。「どんなに良いツール作ってもお金取ったら広まりにくいよ！」って思ってました。XamarinでAndroidとiOS版の両方のアプリを作ろうと思ったら、ライセンス代が1年で25万円くらいかかってたんですよ。私みたいな社会人歴2〜3年の人が趣味でやるには高過ぎる値段でした。
----
正直言って元記事のちょまど氏の発言は不正確なところが多々あった。
Microsoftの方によると
修正は本来ならあり得ないんですけど、コンテキストが落ちちゃってるところがいくぶんあったので(^_^; https://t.co/5TzS8rY5cH— Azure工事担任者 (@rioriost) 2017年5月12日
インタビューなので、なかなか難しい...。分かってる前提、つまりハイコンテキストで喋ってるわけで、そういう前提までは記事に書かれてないんですよ(^_^; https://t.co/lXLjOVg9D7— Azure工事担任者 (@rioriost) 2017年5月12日
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
前回、JSP？を軽く勉強したから今回は、フレームワークを導入した。
前回の教訓もあって、プロジェクトをimportしたあとプロジェクトのファセットから動的Webモジュールとして設定。
HTTPステータス 404 - /sa%dstruts%dtutorial/と文字化けっぽいエラー。
困った。。。
プロジェクトのファセットの隣にランタイムってやつを発見。Tomcatにチェックを入れてみたら
HTTPステータス 404 - /sa-dstruts-dtutorial/
文字化けが直った。
あとは、デプロイメントの記述子の設定を確認。ウェルカムページのweb.xmlが見当たらない…
プロジェクトの中にあるはずだけど、仕方ないから参照してるページにコピペ。
Javaってのは難しい言語だ。なんで環境設定こんな複雑なんだろう
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
Javaで開発されたアプリケーションにはインストールにまつわる難点がある。
それによりせっかく興味をもってくれたユーザーも試す前に諦めてしまいがちである。
また、サーバーサイドアプリケーションもJava製である場合、デプロイや監視の際の難点が多く運用者を悩ませてきた。
javafxで導入されたパッケージャを用いることで各OSネイティブなインストーラーの作成が可能になり、この問題を解消・緩和できる。
SpringBoot などを用いた ExecutableJar を作成するアプリケーションであれば、サーバーサイドアプリケーションであっても一部制限があるもののパッケージングできる。
Javaで開発されたアプリケーションの配布には以下の問題点がある。
javafx-maven-pluginを使うとよい。javafxと冠しているが実態はパッケージングツール。
javafxの冠があるがためにスタンドアロンアプリ開発者以外を遠ざけている感あり。
Windows(msi/exe), Linux(rpm/deb), Mac(dmg) など各OS・ディストリビューション固有のパッケージングが行える。
公式ページ( http://zenjava.com/javafx/maven/ )では更新が止まっているが、Github( https://github.com/zonski/javafx-maven-plugin )とMavenRepository( http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.zenjava%22%20AND%20a%3A%22javafx-maven-plugin%22 )を確認するとちゃんと開発は続いている。
pom.xml に以下を追加する。
mainClassはSpringBootなら@SpringBootApplicationのついてるクラスですね。
vendor は適当に組織や個人の名前を入れておきましょう。
※ 以下の XML が化けるのは増田の不具合か仕様っぽい。 http://anond.hatelabo.jp/20100205210805
<plugin> <groupId>com.zenjava</groupId> <artifactId>javafx-maven-plugin</artifactId> <version>8.1.2</version> <configuration> <mainClass>[main method class]</mainClass> <vendor>[Vendor Name]</vendor> </configuration> </plugin>
あとはそのままビルドすればよい。
maven clean jfx:native
ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。
本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。
これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。
/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。
app の下にはビルドした jar ファイルや依存ライブラリが置かれています。
runtime の下には実行用の jre が配備されています。
実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です）
最近、地方→中央省庁のとあるデータのやりとりが、Accessベース（Access＋VisualBasic）からExcelベース（Excel＋マクロ）に変わったんだが…。
うちの県ではVisualBasicのランタイムを作業用ＰＣにインストールするだけで折衝に一年越しだったから、一応変更自体は歓迎だったんだけれども、これが…。
ちなみに、扱うデータ量は、ざっくり言って、一都道府県当たり平均で5000行×1000列の表くらい。多い都や府なら、列の方がこの数倍行くだろうな。で、あくまで個人的な感想として、どんな感じかつーと、
(1)データ触ったり集計したりしにくくなった。
前のシステムは、データ自体は単なるAccessのデータだったので、間違いを修正したり別の集計に使用したりが意外と気楽に出来た。
今度は、Excelを無理矢理マクロやらで動かしてデータベース化してるから、Accessの時代よりも途中でデータが触りにくくなった。で、データにミスがあれば、いちいち一番大元の支所の担当者に連絡して最初の打ち込みデータから変更して貰わないとならない。
(2)めちゃくちゃ重くなった。
これは、まあ想像つくと思うけど…重い。Excelとはいえファイルが数十メガとかあって、デカいから扱いに困るし、重さについては、特にデータから選択して表示させる機能が弱いらしく、やたらに時間がかかる。これが結構致命的かも。支所に配付した入力システムですら、４年前のPCではフリーズしまくった（新しいＰＣ使えと言ったら、結局個人用のＰＣ使ったとかいう噂も……ウソでしょ？）。県庁での取込・集計システムは、取り込んだデータの10支所ごとのまとめ表を閲覧表示しようとするだけで大体数分かかる。なお、一支所毎に表示する機能がないので（なんだそれ）仕方なく、支所ごとに、システムから一覧表（紙）を打ち出して送付してもらっているが（なんだそれ）、そうなると今度は、データと紙が一致しないという事例が発生した。表示機能が特に重いので、先方でも、データの中身は余り見ずに送ってるらしく、最終段階でデータいじったのを忘れたりしてそういうことが起こるらしい（なんだそれ）。
これは仕方ないことだが、RDBなら元々ソフトの機能でしていることをマクロでやらせてて、そこを触られたくないからだろうが、やってることの中身が把握できない。で、たとえばデータ保存の際にいろいろエラーメッセージが出ることがあるんだが（２年前のシステムで、標準で.xlsで保存する仕様になってるため、「機能低下が云々」とか）、おそらく問題なかろうとは思いつつも、不安なまま運用してる。
エクセルだから、入力とか扱いとか、気楽になった部分は評価する。なので、データベースとしての運用を想定したＤＢ機能強化版のExcel Proとか出ないものか？ と。
建前としては2つのOSを併用しての慣れ、移行を意識したもの。デュアルブートをしてみること自体にDIY的な興味もありました。
対象は、Windows XP Home 32bitがインストールされたデスクトップPCです。
1台目のハードディスク（ディスク0）はパーティションが2分割されており、CドライブにWindowsXPがインストールされ、Dドライブはその他のデータ用です。未割当の領域は無いのでパーティション操作ツールを使ってDドライブを縮めて空きを作るつもりです。
そこにもう一つのOS/Windows7 Home Premium 64bit DSP版をインストールし、XPとのデュアルブートにします。以下、覚書です。
まずは、情報収集です。「Windows XP 7 デュアルブート」などで検索しました。
やはり公式ということでMicrosoftのウェブサイトの説明をはじめによく確認しました。http://windows.microsoft.com/ja-JP/windows7/Install-more-than-one-operating-system-multiboot
説明としては割とシンプルなもので、要はOSは古い順にインストールせよ、新しいOSを空きパーティションにインストールせよというだけのものです。
次いで移行wikiやmynavi、DOSVレポート、ITAYA氏のサイト等各所詳しい方々の記事も参考にしました。
http://news.mynavi.jp/special/2009/windows7/023.html
http://www.dosv.jp/other/0907/16.htm
http://www.geocities.jp/itaya_ys/TIPS/DualBoot/index.html
基本的に先にXPがインストールされていれば、さほど難しいこともなく7もインストールでき、起動時にブートメニューが示され「以前のバージョンのwindows」か「windows 7」のどちらを起動するか選べるようになるとのことでした。このときの既定のOSや待ち時間はWindows７のシステムのプロパティから設定できるようです。
ブートマネージャーをコマンドプロンプトで編集する方法や、EasyBCDで編集する方法も紹介されていました。
Windows7 64bitに必要なドライバをダウンロードしておきます。
マザーボードメーカーのサイトから、チップセット、LAN、サウンド、グラフィックの各ドライバをダウンロード。
Easeus to do Backup
インストール先のハードディスク（ディスク0）を丸ごとイメージバックアップします。
Easeus to do Backup 5.5でディスク0を外付けハードディスクにディスクコピー。
Mini Tool Partition Wizard 7.7でDドライブのサイズを縮める。
特に異常なさそうなことを確認。
はじめXPを起動したままインストールしようとしたが、「このインストールディスクは、お使いのバージョンのWindowsと互換性がありません。詳細については、コンピューターのシステム情報を参照してください。Windowsを新しくインストールするには、インストールディスクを使ってコンピューターを再起動（ブート）し、［新規インストール（カスタム）］を選択してください。」などとメッセージが出てきた。問答無用に上書きしようとするらしいが、32bitと64bitだし、DSP版だし、でアップグレードインストールできないのは当然。
Win7のインストールDVDを入れたままPC再起動。BIOSポスト画面でキーを押してDVDドライブからの起動を優先させる。
インストーラが起動し、インストールを進めていく。インストール先に未割当の領域を選ぶ。
その後普通にインストールを進める…はずが、うっかりインストール途中の再起動時「Press any key to boot from CD or DVD」と表示されているときにキーに触ってしまい、初めからインストールやり直しになってしまった。無駄にWindows.oldを作ることになった。
再起動やシャットダウン後の起動を行い、XP・７いずれもブートメニューから選んで問題なく起動することを確認。
チップセットドライバ、LANドライバ、サウンドドライバをインストール再起動。
.NET Framework 4.5をインストール（Radeon の新しいCatalystには4か4.5が必要。なぜドライバのユーティリティにこんな大きなランタイムめいたものが必要なのか…）
Windows 7の標準機能でシステムイメージバックアップ。起動に必要なファイルが含まれるのでXPのパーティションも一緒にバックアップされる。
XPから、Windows7のパーティションへのアクセスを不能にする。
http://www.geocities.jp/itaya_ys/TIPS/Vista/Vista05.html
XPからは容量0・空き容量0・未フォーマットのローカルディスクとして見えるようになる。（アクセス不可）
Cドライブ（XP）、Dドライブがあるので、なんとなくEドライブがWin7のシステムドライブになると思っていたが、Win7を起動したらインストールされたドライブはCに、XPのドライブはDに、DドライブだったものはEに、以下他のドライブレターも順にずれていた。
当然XPを起動したときはもとのドライブレターのまま。（Win7はE）
ディスクの先頭に約100MBのシステムパーティションが作られる、と聞いていたが今回は作られなかった。
WindowsXPのあるCドライブのbootフォルダの中に関係ファイルがあるようだ。
『「以前のバージョンのWindows」を選択実行した場合は、NTLDRが読み込まれ、BOOT.INIに複数のOSが設定されていれば、そのメニューを表示し、BOOT.INIに1つのOSしか設定されていない場合は、すぐにそのOSが起動します。』（http://www.geocities.jp/itaya_ys/TIPS/DualBoot/index.html）
なるほど。たとえば、XPと2000がインストールされている場合、以前のバージョンの．．．を選んだら、XPと2000のどちらを起動するかメニューが表示される、と。
日本語化された公式ドキュメント。全てを読むのは難しいが、「Objective-C プログラミング言語」「Objective-Cによるプログラミング」を読めば、大半の入門書より網羅的に解説している。
ろくに書籍化されていない情報を日本語で読むにはここしかない。
某androidでは一切ドキュメントが日本語化されず、公式チュートリアルの日本語化でさえ有難がられる（そして一般の開発者が理解していない）惨状なので、日本語資料の存在を有難がるべき。
XCode内で調べたいクラスでOption＋右クリックでクイックヘルプを開き、更にクラス名をクリックすると、オーガナイザにクラスリファレンスが表示される。
ここで概要を読めばおおよそは分かる。
リファレンスに使われている単語は限られているので、英語が苦手で文法が不明瞭でも、読み続けさえすればある程度意味は把握できるようになる。
福井高専の有志による日本語リファレンスが存在するが、更新が古い上に意味を真逆に捉えた最悪な翻訳が野放しになっており、オリジナルへのリンクもない仕様なので、読むべきではない。
紙ベースでObjective-Cの入門書が欲しいのであれば、この本一択。
iOSに限定しないことで、Cocoa TouchがCocoaのサブセットであるがゆえの制約など、iOSだけ見ているとなぜそういう仕様になっているのか分からない部分が明瞭になる。
ある程度理解したつもりでいるiOSプログラマでも、おそらく新しい発見がある。
マイナビの連載でwebで無料で読むことができるが、加筆修正された書籍版も販売されている。
約7年前に始まった連載なので、情報としては古く、ポージングなど既に廃止されたテクニックについて語っていたりもするが、その内容は色褪せない。
Objective-Cランタイムがどのようにオブジェクト指向とC言語を結び付けているのか、クラスやメソッドの実体とは何なのかを明らかにしていく。
正直詳解と呼ぶほど詳しくないので、UIKitで困ったら素直にクラスリファレンスに頼った方が良い（ネットでググるのは間違った情報に当たる確率が高いのでおすすめしない…）。
しかし丁寧な解説はUIKitに触れる際に一読する価値はある。
惜しむらくはiOS4時代のもので、バージョンアップ時にそれなりにUIKitに変更が加えられるので、それを考慮に入れて読むこと。
タイトルからは中級者以上を想定しているように見えるが、実際には初学者向けで、retainを使ったメモリ管理から話が始まる。当然、MRC時代の本。
しかしデバッガを用いたクラッシュ原因の特定や、Instrumentを使ったメモリリークの防止など、より品質の高いアプリケーションを作るノウハウについて触れているのが異色。
iOS開発で多用するMVCを利用したデータ管理や、テーブルビューによるリスト表示などをパターンとして紹介する本。
「使い方は分かったけど、どう作ればわからない」という人に作成の一つの指針としておすすめだが、万人に対してこの通りに作れ、とは薦めにくい。
この本は、強力な仕組みながら解説の乏しいCore Dataをプッシュしてページ数を割いているのが貴重なのだけど、NSFetchedResultsController（訂正しました。指摘ありがとうございます!)をスルーしているため実用性を大きく欠いてしまっている。
大半の用途ではAVAudioPlayerを使用すれば困らないと思うのだけど、日本語でCoreフレームワークについて1冊本が出ていて、これだけ詳細な情報が手に入るというだけで読まないと損。
独創的で優れた楽器アプリが日本のAppStoreからこれだけ多く登場したのは、この本の存在があったからに他ならないように思う。
２０１２年はてな匿名ダイアリー名作ランキング５０選様に取り上げて頂いた関係で、再び日の目を見ているようですので、この一冊を追加。
冒頭のメモリ管理の話が平易すぎて読む本を間違えたかと思ったが、ARCやBlocksの挙動を実装レベルで解説する以降の章はまさにエキスパートに相応しい内容。「使い方」の一歩先を知りたい人におすすめ。
ここがどういうことを言ってるのかちょっとよくわからないんだけど、
アプリ間の依存関係はまぁそれほど問題にならないからどうでもいいかな。
下位レイヤがほんと酷い。
dllだのランタイムライブラリだの、スクリプト言語の実行環境だの何だの
パッケージ単位で全部解決させようとするからどのインストーラにもいちいちpythonとか入ってやがる。
逆にその辺がまとまってないソフトを入れようとすると、依存関係を自分で解決する必要があって大体ハマる。
管理システムへの登録スクリプト環境をきちんとしとけば（例えばmacのhomebrewはrubyに統一されてる）、
Tomcat上のJRubyから呼んだJavaプログラムから呼び出し元のJRubyの環境(Runtime)を使いたいときにどうすればいいのか？
方法が1つわかったのでメモ。
(追記2:こんなめんどいことしなくてもJRuby.runtimeで取れたみたい)
イメージ的には以下の感じ
↑↓
↑
JRubyは1.4.0、jruby-rack.jarは0.9.7、warblerは1.0.1
まずは必要なクラスをimport
import org.jruby.Ruby; import org.jruby.rack.PoolingRackApplicationFactory; import org.jruby.rack.RackApplication; import org.jruby.rack.RackServletContextListener;
ServletContextをどっかから取ってくる(Listener作ってfieldに埋めるとかして)(追記：$servlet_contextで取れる[JRuby-Rack使うから])
ServletContext context;//=～～～
warblerでwar化するとweb.xmlにRailsServletContextListener(extends RackServletContextListener)が登録される。
そのListener起動時にFactoryがServletContextに登録されるので、それを取得する
PoolingRackApplicationFactory factory = (PoolingRackApplicationFactory)context.getAttribute(RackServletContextListener.FACTORY_KEY);
PoolingRackApplicationFactoryのapplicationPoolを取ってくる
(protected fieldなのでリフレクションを使用)
Field poolField = factory.getClass().getDeclaredField("applicationPool"); poolField.setAccessible(true); Queue<RackApplication> pool = (Queue<RackApplication>)poolField.get(factory);
RackApplication ap = pool.peek(); Ruby ruby = ap.getRuntime();
呼び出しもとのJRuby環境を使ってRubyコードを実行できる
ruby.evalScriptlet("p 'test'");
実際に使うときは、applicationPoolにちゃんと入っているかなどのチェックが必要になる。
ふと思いついてWin XP SP3をインストールした 特に不具合はなし
ただX-GUARDが起動するたび
XTRM VB Runtime.msiを指定してインストールしろだの出てくるので
XTRM VB RuntimeやらX-GUARD入れ直したりしたが駄目で
そこでググったところランタイムのバージョンがふるいんじゃね？
Visual Basic 6.0 SP6 ランタイムライブラリを入れたらいんじゃね？
と言われ入れたら解決した
とにかくXTRM VB Runtimeの関係のが先に進まない場合
↓の入れれば解決するってこった
Visual Basic 6.0 SP6 ランタイムライブラリ
http://www.vector.co.jp/soft/win95/util/se188840.html
俺はAdobeの旧Macromedia部分が嫌い。こいつらは10年以上大風呂敷だけ広げて見せてるだけだから。
でも世の中がそれを必要とするってんならそれぐらいは認める。
で、AIRってなんじゃいと思ってみたらただのローカルアプリケーション開発環境だった。しかも統合されたもツールらしきものは無く散発的な既存製品とランタイム。なんじゃそれ。相変わらず手抜きだな。
ネットワークプラットフォームとか言ってるけど要するにやりたいのは単純にFlashによるローカルアプリケーションを書くこと。むしろネットワークとは逆の方向に影響力を伸ばしたいって訳で、それなんてDirector？
時代に合わせて表現にFlashやHTMLやJavascriptも使えますよってことだろ？じゃあそういえよ。で、まーた2、3年したら放り出すのか。別の新機軸を取り入れて鋭意開発中って言い続けて何年経つんだよ。
いいからさっさとIllustratorのバグ取れよ、このハッタリ会社め。
これひどいな…。誰もつっこまないのか？
>>「ランタイムなどを使用せず」というのは無理です。C／C++の標準に、ネットワーク系の関数が無いからです。たとえばWindowsなら、Winsockライブラリが使用できるので、それを利用することになります。<<
質問している人が言うランタイムって別途配布する必要があるライブラリのことだろ？最初からインストールされているWinsockや静的にリンクできるライブラリは別物だろ？
>>WindowsだとC++で書いてもMFCを使っちゃうとランタイムが必要ですよ。<<
これも静的にリンクできるよ。ひょっとして入門版の開発ツールを使ってるのか？
ブックマークでも人気のこちらを見て考えた。
80年代に隆盛を誇った8bitホビーパソコンの追憶の詩と映像である。若くてそんなの知らない向きにはこちら→Wikipedia 8ビットパソコン、ホビーパソコン
要するに貧相な計算能力ながらようやく「人間にも分かる」表示能力と発音能力を持った初期のパソコンの、ユーザーがその表現をプログラム側からながら自由に扱うことができるところに面白みのあった一時代についての懐古である。曲も素晴らしい。
もちろん私も8bitホビーパソコンのストライクゾーンユーザーだったわけで上記クリップの言わんとする感じは良く分かる。逆に世代が違うとそれだけでこのビデオ作品には何も感じないかもしれない。
しかしそんな懐かしズムについて語りたいわけではない。いや、むしろ猛然と語りたくてしかたないのか。ともあれ、この国産8bit時代に我々現30代はアーダコーダと雑誌を横に機械語まで弄ったりしたのだ。頭の柔らかい中学生ぐらいだから理系とか関係なく自然と言語を取り扱えた。いきなりバイナリでコードを組んでる姿は親からみたら異星人だったに違いない。それでもクラスに数人はいたはずだ。希少種というほどでもない。
そこで疑問に思うのがそんな我々30代が社会で中堅と相成った現在において、この日本のソフトウェア産業のレベルが低いのはどういうことなのだろうか。かように自主的にコンピュータの実習をしてきたにもかかわらずだ。
怪しい部分はいろいろある。
8bitパソコンにうつつを抜かしている間言われたのは「プログラマーでは食っていけない」という呪いだった。実際、私も特性があったとも思えないが選択肢から最初から除外していた。この辺の妥当性は現在プログラマーの人のコメントを待ちたい。外見的にはWebプログラマーとして人材が流れ込む現在とは対照的だとは思う。
また、90年代の停滞だ。Macintoshの廉価版と続くPC/ATとWindows95の普及まで「パソコン」は暗黒期にあった。さらに言うと2000年ごろのウェブプラットフォームが現実感として開けてくるまで80年代のような「パーソナル」さはなかったように思う。
思うに、80年代のパソコンと90年代（後半）以降のコンピューティングは全くの別物だったのではないだろうか。
そこで8bitパソコンがなんだったかというと、実際はパーソナル「コンピュータ」ではなくパーソナル「メディア」だったのだろうと思うのだ。（当時ログインで伊藤ガビンがPCメディア論を振るっていたが、ここではもっと画用紙同様の素直な意味である）今からみると惨めな表現力しかないのだが自由に、難しい表現だが、扱うことができた。サラリとその場でBASICを組めばキーに音を割り振れるような自由だ。いくつかの8x8マスのカラフルな独自“文字”を設定してテレビ局しか触ることのできなかったCRT画面を芝生“文字”や樹木“文字”で埋め尽くし草原にしてしまう自由だ。
特に当時は計算能力に限界があったためユーザーも遅くて動かないアルゴリズムに凝ることより表現に凝ることに走ったのかもしれない。
ゆえにコンピューティングの正統な進化たるMacintoshやPC/ATではそれを引き継ぐことはできず、ラピッドプロダクションで表現を行うメディアであるウェブの普及までその再来感覚がなかったのだ。
そしてこれはコミック（60年代??）、アニメ（70年代??）と続きゲーム（90??年）が引き継いだ日本のサブカルチャーの基底をなす一つでもあると思う。
だから大人になったパソコン少年※が作るのはウェブプラットフォームランタイムではなく『PC-6601が歌うタイニーゼビウス』なのである。
あいつらのほとんどは所詮実行環境に過ぎん。
自己書き換えがほとんど不能なランタイム・エンバイロメントである。
機械ではなくて人間なのだから、法適用時に極力社会リソースを必要としない方向へ改善する圧力を自己としても持ってほしいものだが…
それは政治家の仕事ではあるが、政治家が常に法律家、しかも単なる実行環境ではなく実行環境を自ら改革する意思を持った法律の専門家たちを必要とするようになんとか持っていけないのだろうか。
SEの仕事には顧客企業における無駄な手続きや申請を合理化したり、闇に隠れていた秘密の手続きを明らかにしたりすることが含まれる。
そしてその会社をコンピュータを入れるという名目で合理化することで、世界を変えている。でもあいつらは。
また、社会学者や経済学者の視点で読めばおそらく社会が「誤ったインセンティブ」で導かれてしまっているのが手に取るようにわかるのだろう。
正しいインセンティブで導かれれば減少する不幸がどれだけあることか。でもあいつらは。
昔持っていた敬意はどこかへ雲散霧消してしまったよ。
パン屋の旦那と同じくらいには尊敬できるけど。
いや、パン屋の方がやっぱり尊敬できるな。
パン屋の若旦那は工夫をこらした新作パンを創造してくれるもの。
法律家にはそれがない。
