  |
はてなキーワード: cygwinとは
「端末エミュレータは」なら一定納得する。端末エミュレータ＋ローカルシェル環境ってことなら誰がどう考えても最弱でしょ。
http://anond.hatelabo.jp/20140322050206
■追記１
角度をいくら変えても手が痛くなるので長時間や正確な作業には不向き。
MBAでのトラックパッドが当時の他のノートに比べてダンチだったのは認める。
けど今はSurfaceのタッチパッド（ペンパッド）に比べると負ける。
■追記２
でもWinでCygwin、TeraTerm使えば仕事は問題ないと思う。
■追記３
女の子に例えてみた。
・Win子…かわいさは無い。が、色々と言う事を聞いてくれる。
掃除や料理がもともと得意なので、結婚相手には向いている（仕事には向いている）。
・Mac美…誰もが美しさを認める美人。だが付き合うと振り回されるし、
言う事聞かない事もあるのだが、そこも含めてかわいい。
議論元エントリーはこちら。
毎度のことながら、MacとWindowsの論争を見るともんにょりしますね。人類から戦争が途絶えぬ縮図が、ここに。(´ω`)
しかし、最近パソコンをはじめたユーザや、元エントリの増田のような人にとっては、信者の言葉ってワケわかめだと思うんですよ。
そんなわけでMacとWindowsの歴史を、なるべく平易に書いてみました。(´∀｀)
歴史を見返して、WindowsとMacの強み弱みを把握すれば、宗教戦争の理解が深まり、自分にピッタリのパソコンが分かるかもしれません。
たぶん。
元増田のエントリーがWindows寄りの結論になっているので、
だれかWindows寄りや、Linux寄りの視点を加筆して下さいな。当エントリの補足・指摘も歓迎します。
既存のUNIX環境向けに制作された、膨大な数のソフトウェアを扱えるのはプログラマにとっては大きな恩恵です。
たとえばWindowsではCygwinを導入する事でC言語開発環境を手に入れる事ができます。ただし、インストールは非常に煩雑で、動作速度も雲泥の差です。
MacはPOSIX互換であり、プログラミング環境のインストール等が簡単です。
FreeBSDやUNIXを過去に使用していた熟練プログラマは、Macに乗り換える事で、過去の資産を有効活用する事ができます。
シェル環境とは、よく映画で、暗い部屋の中、天才プログラマーが真っ黒な画面に流れる奇っ怪な文字列を眺めてる、アレです。
ひらたくいうと、あの文字列ひとつひとつが、コンピュータ内部で行われる処理や通信を意味しています。
LinuxやMacではターミナル、Windowsではコマンドプロンプトなどと呼ばれます。
Windowsには非搭載だが、Linux/UNIX/Macでは標準サポートされているコマンドが多数ありました。
とはいえ、これは過去の話です。現在はWindowsのシェル環境も、だいぶ充実したので、普通に使うには大きな差はありません。
が、歴史的経緯や文献量を比較すると、どうしてもWindowsのシェル環境はUNIX/Macに劣ると考えられています。
四六時中プログラマが目にするのは、文字です。ですからプログラマーは醜いフォントが許せません。
Windowsのフォントレンダリング環境は2014年3月現在も貧弱です。
WindowsVista登場時にメイリオフォントが登場し、ある程度の改善が図られましたが、Macの画面と比較すると大きな差です。
これはMacとWindowsのフォントレンダリングやアンチエイリアスの技術の違いによるものです。
WindowsでもMacTypeなどのソフトウェアを使用して、強制的にフォントのアンチエイリアスを変更する事が可能ですが、残念ながらMacに遠く及びません。
Anti-Grain Geometry - Texts Rasterization Exposures
Xcodeは、非常に優秀なIDEです。特筆すべき利点は、動作が割と軽快で、初期設定の状態でもある程度使い物になる点です。
インストールもAppStoreからワンクリックな為、簡便です。XcodeはMacのみで使用できるソフトウェアです。以前は有料のソフトウェアでしたが、ここ数年は無料で提供されています。
またiOSのソフトウェア開発では、XcodeとMacは必須です。iOSアプリの開発には、Xcodeとそれに付随するシミュレータソフト、そして開発者用アカウントが必要なのです。
Xcodeの弱点は、バージョンアップ時にインターフェースが突如として大幅変更がされる事。またここ数年は英語のみしかサポートされておらず、日本語話者にとっては使いづらいという2点です。
2014年現在は楽曲制作にMacとWindowsの差はありません。しかし、過去にはDTM=Macという暗黙の了解がありました。
特に1980年代、プロユースの音楽制作ソフトの多くがMacintosh対応でした。理由は複数ありますが、そのひとつがPCM音源の発音問題でした。
Macintosh 128K以降すべての機種でPCM音源をサポートしています。これにより同時発音数が多く、Mac向けのDTMソフトウェアが多く開発されました。
それに対してWindowsは16ビット/48KHzのPCM1チャンネルのみで、性能はCPUの能力に依存します。昔のPCはCPUの実行速度は低かった為、音声出力の機能が貧弱でした。
Mac標準搭載のGarageBandと、有料のDTMツールLogicは有名なDTMソフトウェアです。
この2つのソフトはAppStoreから購入できます。互換性もあるため、GarageBandで作曲を覚えた初心者ユーザが、Logicを購入し上級者になるという、非常にスムーズな導線が構築されています。
またLogicは数あるDTMソフトウェアの中でも安価で高機能です。iPadとの連携機能においても、他のツールより頭一つ秀でています。
MacはCoreAudioという、MIDI入出力環境を搭載しています。大変高速に動作する為、追加投資の必要がなく、DTMクリエイターに重宝されています。
Windowsの場合、オーディオドライバを別途用意する必要がある為、投資が必要です。
主に海外製のプラグインではありますが、明らかにMacよりWindowsの方が充実しています。お金をかけずにエフェクトに凝りたい人にとっては、MacよりWindowsの方が良いと言えます。
MacBookProRetinaモデルは、グラフィックデザインの仕事をする者にとっては、福音でした。
特にAdobeInDesign使用時の効果は凄まじいと感じます。紙とディスプレイの1to1の制作環境が構築可能な時代がやってきたと感じます。
さらに当時、MacはPostScriptというAdobeが開発した印刷用言語をサポートしていました。高解像度の印刷を行うには、Macしか選択肢がなかったのです。
その頃の印刷所やデザイン事務所はおのずとMacを導入しました。その歴史がある為、現在もMacの使用が続いています。
スティーブ・ジョブスが学生時代にカリグラフィーを学んだ逸話は有名です。その経験から彼はMacのフォント環境に心血を注ぎました。
現在でもAppleは高いライセンス料を支払い、各種製品にフォントを多数搭載しています。
オーソドックスで美しいセリフ体のTimes、流麗なZapfino、日本語フォントではヒラギノなど、様々な良質フォントが搭載されています。フォントを買い足さなくても、ある程度のグラフィックデザイン制作が可能です。
反面、2014年3月現在Windowsで安定して使えるフォントは、字游工房の2書体のみです。メイリオは画面表示時に使うフォントなので、DTPでは活用されにくいです。
2005年頃、出版業界はQuarkXPressからAdobeIndesignに乗り換えました。しかし、それ以前は出版用ソフトウェアはQuarkXPressが業界標準でした。
このソフトは、Macでしか対応していませんでした。QuarkXPressは、64bit対応やOSX対応が遅れため急速にシェアを落としました。
現在はAdobeIndesignが業界標準で、これはMacもWindowsも両方で使用可能です。
しかし、QuarkXPress時代から活動しているブックデザイナーやエディトリアルデザイナーにとっては、Macの方が慣れ親しんでいるでしょう。
1980年代のパソコンは、表示できる色数に制限がありました。Macintoshは安価な割に発色の性能に優れた時代がありました。
コンピュータ・グラフィックは数多のPCメーカが多額の資金を費やし研究開発した歴史があります。
一時代だけを抜き取って「Macのグラフィックが優れていた」なんて書くと、多くのツッコミが入ると思います。
とはいえ、Macは早くからキャリブレーションの機能を充実させてきた為、色管理の強さという点において、多くのデザイナーやイラストレータから支持を受けた事は、特筆に値すると思います。
問答無用で、Windows一択。PC改造を続け、最新のグラフィックを追い求めたゲームマニアは、10年前に比べると少なくなりました。
しかし、彼らのPCがMacである事など、ありえません。
最近はAdobeFlashが盛り返しを見せていますが、ブラウザゲーム市場を除けばMacを使用するメリットは薄いと考えられます。
一方、Linuxベースのメディア配信サービスSteamOSの今後の発展に期待したいところです。Steamではアマチュアからプロまで幅広いゲームクリエイターが自作のゲームを販売しています。
Windows圧勝。MicrosoftOfficeをはじめ、Windowsの方が対応ソフトが多いです。
特に会計ソフト類は、Macは壊滅的であります。また、言わずもがなですが、BtoBの業務系ソフトウェアはWindows特化のものが大半です。
とはいえ、LibreOfficeやOpenOffice.orgを使用して業務を進める団体もあります。福島県会津若松市とか、滋賀県甲賀市などがそうです。(LibreOffice採用事例)
そういえばVer4.2でCalcを大手術したLibreOffice。もうそろそろC++完全移管が完了します。
高速化が施され、今以上にチューニングされれば、Windowsの牙城に一矢報いるかもしれません。
ちなみに私は、ChromeOSとGoogleDriveが搭載されたChromeBookが、MicrosoftOffice一強状態を打ち崩すと予測しています。
あとJustSystemの一太郎も頑張ってほしい。Just do it!!
以上、チラ裏でした。
現実問題、iOSとiTunesの同期はWindowsでも可能です。しかし「持ってる携帯電話がiPhoneだから」と言う理由でMac買う人は多いです。
そりゃiTunesとiTunesStoreを使っているなら、Macに毒されてしまいますよね。
そういえばWindowsMediaPlayderが残念だった時代に、シェアを伸ばしたのがiTunesでした。音楽を愛するユーザの支持を集めた時代があった。と言っても過言ではないと思います。
使い勝手に優れます。これが理由でMacを使う人もいます。WindowsやLinux環境で、同様の使い勝手を得られるマウス・ガジェットは、2014年3月現在存在しません。
MacProではThunderboltを大量に備えています。これは今後普及する4K映像制作において活躍すると考えられます。ただ、普通に使うぶんにはThunderboltは恩恵を受けにくいと考えられますが。
これはMacに搭載された自動バックアップ機能です。Windows8にも同様の機能があるが、インターフェースの使いやすさと、設定の簡易さではMacが勝ります。
Macはクリーンインストール後に、自分のAppleIDを認証すると、最新版まで自動アップグレードを行います。
クリーンインストール後、1回の再起動で、ほぼすべてのアップデータが揃った状態になります。
WindowsUpdateの何回も繰り返さざるを得ない面倒アップデート作業に比べると、Macは楽ちんです。
ネットワークにつながった状態でリカバリを行った際、HDDが論理的に破損していても、自動で復元してくれます。というか、いつ切り替わったのか分からないレベルの自然さで勝手に復元を始めます。そう、Macならね!!
Appleの修理は迅速な印象があります。今まで5回修理に出しましたが、いつも4日程度で返送されてきます。あとまぁ、Appleサポートはごねると得をする事が多い……ような感じがします。(一個人の印象です)
Windows8タッチパネル型は画面が揺れるので、使いづらい機種が散見される(2014年3月現在)。画面を固定しながら操作できる補助道具や、ロック式のヒンジが必要だと思うのですが、まだ普及していません。
あと、SurfacePro2が店頭で買えない状況が数ヶ月続いているので、そりゃあMacに流れるのでは。(なんか、今日のニュースで久々にSurfaceが入荷されたらしいです)
スペック対価格を比較すると、CPUやメモリやらのコストパフォーマンスが悪くない、と思います。
10年前は「Macは高くつく」という印象だったものが、ここ5年で「Macって割安」という印象に変換したと記憶しています。
一昔前に比べ、自作PCの価格的メリットが薄れたから、そのように感じるんですかね。
美品なら、「だいたいこの値段で売れる」という土壌が形成されている。大幅な値崩れも少ない。新製品発表ごとに旧機種を売って、新機種に乗り換えても、損した感が少ない。
要するに、値崩れしにくい。ポジティブに受け取ると、欲しいと思った時が買い時。
SurfaceRTのように意味の分からない価格暴落が起きる心配がないですね。人によっては、安心と言えるかもしれません。
何をもって"無駄"と判断するか、非常に難しい論点ではありますが。
へんてこなアザラシのマスコットがデスクトップを泳ぎ出したり、なんとも言えないモッサリ感の明るさ調整ソフトが突如画面に出現したり。なんて事はありません。
ある時期、ある特定の界隈にて、「Macが優れる」とか「いや、Windowsがコスパが高い」なり「Linuxが一番」とか、
マァ、乱暴な言い方をすると、それぞれのムラの中で熱狂と共にコミュニティが形成されて、宗教と信者ができあがると思うんですよ。
しかし進化の早いIT業界では、一昔前の利点が追い抜かされるなんて、日常茶飯事。
だから今から見ると、信者の言葉や、その感動が伝わらない。なんて事、よくあると思います。
ジョブスも、死んだし。
とはいえ、日常生活の中で、目を輝かせてOSのすごさを語る信者とか、逆に必要以上に貶す反信者を目にしたら、
生暖かい目で「ああ、このオジサンが若い頃、こういうのが流行ったんだナァ」とか
「ああ、昔、あのOSに苦労したんだネェ」などと、受け流してあげるのが正解だと思います。
そういう時代が、あったんだ。……と。
しつこい宗教や信者は、裏返せば、その人が感動した記憶なのでしょう。
このエントリを読んだあなたが、何かの道具に感激し、愛すべきツールを誇り、誰かにしつこく薦めるようになるのを、楽しみにしています。
ツッコミ、指摘、Welcome。
だれかWindows寄りや、Linux寄りの視点を加筆して下さいな。
記事執筆時点リリースされている最新のOSバージョンはWindows8.1、Mac10.9Mavericks、LinuxKernel3.13です。
最近、まとまった形式でWindowsとMacの優劣や、歴史を比較したエントリーって少ない印象があります。
だいたいがTwitterやまとめブログで、薄っすい単文コメント……(´・ω・`)
がっつり読み応えのある論評にお目にかかりたいものです。
最後になりますが、ちなみに私はLinuxユーザです。(・∀・)
ではみなさま、どうか、ご安全に。(￣人￣)ノ
俺はターミナルを快適に使える＋普通の作業（Excel, Word, インターネット）もできるっていうのが好きだよ
perlやらシェルスクリプトやらでパパっと処理を書いたりするので、ターミナルが使えるととても助かる
fink、macport、homebrewなんかでCUIプログラムでも導入しやすいし。まあこれはLinuxならたいてい同程度以上の機能を持ってるけど。
Winでcygwinやらmingwやらも使ったことあるけど、Macみたいに基板がUNIXってわけじゃないからかどうも使いづらかった
あとはemacsみたいなショートカットキー(Ctrl+kとかCtrl+aとか)が大体のアプリで使えるっていうのも、無いとストレスが溜まるレベルでありがたい
nixなら意識しないでできる。Windowsさんもう本当に勘弁してください。
Sambaが悪いのか、Windowsのエディタが悪いのか、PuTTYが悪いのかわからん。
こいつら全員「自分はUTF-8っすよ」みたく供述するんだけど、最終的に吐き出されてるコードはANSIIなんだよおおおお！！
というか、DOSの歴史には詳しくないからわからんのだが、いい加減Windowsがnixに歩み寄ってくれればいいのに。というか、そうして欲しい。8とかほんとどうでもいいからPowershellの何がpowerなのかわからんpoorshellだろ。
おれの苦悩の過程はだいたいこんな感じだ。途中で何回か順番が変わったり戻ったりしてるけど
1. 直接できないか模索する(MSYSとかMinttyとかちょっと触るだけならいい)
2. Cygwinとか使ってみる(アイコンがきれいになって嬉しいけど結局使えない)
3. VMwareとUbuntu（笑）を組み合わせるも問答無用でしぬ。
4. Mintを試す。クソ遅くてしぬ。（なんでno codec版すら日本のサーバーがないんだ）
5. VirtualBoxでGentooを試す。早くて嬉しいが日本語が必要になってしぬ。←いまここ
ANSIIしか使えなかった時代はしょうがないと思う。。。だけどいい加減うぜえったらないね。。。だってしょうがないじゃんWindows窓から捨てたいよ。でもWineとか使えるかわからんし、でも直接Linuxをインストールするしか方法がないかもしれないな。
Webシステムとは縁遠い事務職のリーマンが、ある日思い立って、ニッチな用途の検索エンジンサービスを作ってみたので、ちょっと書いてみようと思います。
ちなみに、検索エンジンといっても、googleカスタム検索とかのお茶濁し系じゃなくて、apache Solrというオープンソース検索エンジンを、VPS上で動かしているという、それなりに本
気度の高いものです。
なんで素人がそんな物騒なものを動かす羽目になったかは、後述。
やりたい構想みたいなことを思いついたのは、もう6、7年前ほど前のこと。初めて独り暮らしを始めたときに、ひどく不便を感じたことがあり、こんなサービスがあったら便利だなあ、
ちなみにその妄想をふと高校の同期に話したとき、そのサービスはどこにあるのか？！と、えらくがっつかれたのを、覚えてます。まあ、俺と同じく偏執狂の奴だったからだと思います
が。
ただ、しがない事務職リーマンということもあり、当然、技術も無く、そのときは、やるならこんな名前のサービス名だろうなあ、とか、そんな妄想レベルで、話は終わっていました。
そんな感じで、5年ほど月日は経ち、なんとなくリーマン人生の流れも見えてきたところで、以前、妄想していたことを、ふと思い出しました。
5年も経ったら、さすがに自分が考えたようなこと、誰かがやっているだろうと調べてみたところ、意外なことに、競合になるようなサービスは存在せず。ちょうど異動があって、少し時
間が出来たこともあり、じゃあ、着手してみようかと思い立ちました。
やりたいことは、大手サイトの情報検索。ただ、商品ページ内の特定情報、それも、商品ごとに正規化されていない表記を、正規化して抽出する必要があったので、大手サイトの既設API
だけではとても実現不可能でした。
まあ、だからこそ、5年間、誰もやろうとしなかったんでしょうが。
ということで、とても一発では解決できなさそうな内容だったので、自分でなんとか実現できそうな機能に細分化して、各個撃破していくことにしました。
随分と考えた結果、
以上に区分できると考えて、これらを各個撃破していくこととしました。
また、技術もなく、プログラミングも出来ず、ましてやlinuxサーバのお守りをしたことなんて当然ないので、インターネット上に置くサーバですべての処理を完結させるのではなく、イ
ンターネット上に置くリソースは最小限に留め、できる限り、勝手がわかる自宅のwindowsパソコンで処理を行うことにしました。
ちなみにさらっと結論だけ書いてますが、ここまで至るまでに、いろいろと調べ続たり、考え込んだりしていたので、思い立ってから3ヵ月は掛かってます。。。
さて、やる方針を決めたあと、はじめに着手したのは、要の検索エンジンサーバです。
いろいろとググって調べて、mySQLというやつか、apache Solrというやつかに絞りましたが、結局、Solrを使うことにしました。
MySQLのほうが実績は多そうだったのですが、Solrのほうが検索専門で、滅茶苦茶動作が速いらしいということ、MySQLでも出来るが特に速度が遅いらしい全文検索機能も使いたかったこ
と、あとファセット機能がジャンル絞りこみに便利に使えそうだったので、というのが理由です。
ちょうどSolr本が発売されていたこともあり、それを参考に、自分が使うように設定ファイルを変更していきました。
しかし、初めは設定ファイルの内容も意味不明な上に、私の書き方も雑なのか、少しいじっただけでまったく動かなくなる。結局、設定ファイルを一文字ずつ変更しては動作検証、とい
った始末で、進捗は地を這うよう。ある程度思い通りにSolrを扱えるようになるまで、3ヵ月以上掛かったでしょうか。。。
さらに、検索エンジンのフロントエンド（Solrの検索結果を、htmlに変換するプログラム）も書かなければならない。プログラミングが出来ない人間には、これが本当に辛かった。
Solr本に、いろんなプログラミング言語でサンプルがあったのですが、迷った末に、わずか数行なら書いた（≒コピペした）経験があるという理由で、javascriptを苦渋の選択。
しかし、選択はしてみたが、基礎が本当に無いから内容がサッパリ頭に入ってこない。こちらも、わかるところから本当に1文字ずつ変えていくといった手探り状態。
プログラミングについては、今回のためだけだから、といった理由で、一切基礎をやらずに着手したのが裏目に出たのか、サンプルのソースをモノにして、書き上げるのに、ゆうに半年
以上。本当に時間が掛かりました。
さらに、Solr周りで計9ヶ月間ハマっていた頃、忘れもしない、kanzen21のおっさんが彗星のように現れて、衝撃を受けることになります。
大手サイトのページをクロールして検索エンジンを作る手法は、私と考えていた構想の枠組みとまさに「完全に一致」な訳で。。。
図書館事件に注目していたのも同じで、あまりの一致具合に衝撃を受けっぱなしでした。
その後の成り行き等も含めて、興味深く観察させて頂き、本当に参考になりました。
そんな感じで紆余曲折もありましたが、ようやく難題だった、プログラミング関連に目処が立ってきたので、あとはクローラと肝心のデータ処理です。ここからは、勝手知ったるwindows
まず、クローラですが、専用のクローラをwindows用に探してきたり、それを設定するのも大変なので、今回はテレホーダイ時代に使っていたような、フリーのweb巡回ソフトを利用する
こととしました。指定のhtmlをダウンロードしてくるだけなので、別に変に新しいものに手を出す必要もないので。
また、ダウンロードしてきたhtmlファイルについては、これまたフリーの日本語処理ツールでcsv方式に加工することにして、処理ルール部分を相当に作り込みました。
このあたりは、全体を通して見てもキモの部分なんですが、ある意味、ちょっとしたパズル感覚だったので、プログラミング言語の部分と違って、かなり楽しかったです。
あとは、msdosのバッチファイル（これは前から知っていた）で、これらの処理を繋ぎ、cygwinのcurlとかいうツールで、連続して検索エンジンサーバにcsvファイルをアップロードする
仕組みを作りました。
検索エンジンサーバには、容量は少ないが、安くて高性能という、今回の用途にピッタリだった、さくらのVPSを借りて設定。CentOSのサーバ構築ホームページを見ながら、サーバとか
Solr管理URLとかにセキュリティを掛けて、こちらも素人ながら、意外とすんなり設定。
ホームページは、vpsサーバに相乗りさせるのではなく、別にさくらのレンタルサーバを借りました。apacheの設定方法等を習得する必要がありませんし、vpsのリソースをapacheと分け
合う必要が無くなるので。ホームページのhtmlファイル、cssファイル等も調べながら設定し、画像も準備しました。
あと、構想を思いついたときに妄想していたサービス名の.comドメインは、すでに他者に取得されていたのですが、どうも使っている風にも見えなかったので、whoisで出てきたメールア
ドレスに連絡して交渉し、幾ばくか払って買い取りました。
結局、足かけ18か月。ようやく完成。
楽天市場の家具を、幅x奥行x高さ(家具サイズ)で検索できる、楽天市場・家具カテゴリ専門の検索エンジン
この商品数規模（データ収録約30万アイテム）で、1センチ単位で家具のサイズ指定検索が可能な手段は、商用サービスも含めて、ほかには存在しないと思います。
kanzen21と違って、エロじゃないから華はないけどね。。。
ちなみに冒頭で少し書いたきっかけですが、就職して独り暮らしを開始したときに、新しい家にピッタリサイズの家具が欲しかったのですが、これが楽天で探すのは至難の技でして。
楽天で家具を探してみようと思った人には判っていただけると思うのですが、楽天では、価格では範囲指定やソートができても、サイズでは検索出来ないんです。
これは、楽天では、商品のサイズ情報は商品の自由記述欄に記載することになっているためで、商品ごとにサイズの記載方法がバラバラのため、検索が事実上、不能となっています。
家電製品とかに関しては、種類が少ないこともあり、メーカーのホームページとかでサイズを確認した上で、商品型番で検索すればいいので、それほど問題にはならないのですが、家具
って、種類が非常に多く、型番もあったり無かったりで、家電のようにサイズを調べることができません。
・・・ということで、カグサイズでは、楽天の商品ページにいろいろな書式で書かれているサイズ情報を拾って解析して正規化し、範囲指定やソートして検索ができるようにしています
。
また、単に寸法サイズを拾うだけでは、梱包サイズとか引き出し内寸とかも引っ掛かってしまうので、それらは出来るだけ排除して、商品の外寸が優先して引っ掛かるよう、アルゴリズ
ムを調整しています。
単位（センチとミリ）に関しても、商品ごとにバラバラ（単に単位だけでなく、商品説明のどこに"センチ"とか"ミリ"と記載しているかについてもバラバラです。）なので、サイズ表記
の前後の状況をみて、正しいと思われる単位で拾うようにしています。
あと、変わった使い方としては、欲しい家具の価格比較みたいなこともできます。
家具は、同じ商品でも、店ごとに型番が違ったりすることがよくあり、簡単には価格の比較が行いづらいジャンルの商品です。
しかし、型番は違っても、同じ商品なら原則、サイズは同じですから、欲しい商品とまったく同じサイズで検索をかけると、同等商品があるのかどうか比較しやすい・・・といった使い
方もできます。
と、そんな感じで、しがない事務職リーマンが作ってみた、ニッチな用途の検索webサービスを、サービスインさせて頂きました。
一般に公開されていて、誰でもアクセスできる情報でも、ニーズが有りそうな切り口の条件で検索性を高めれば、新しい価値を創造できるんじゃないかという実験です。
もしよろしければ、ぜひ、使ってみてくださいー。それでは！
----------
まあ、昔はUNIXって手に入りづらかったから、UNI+とかそういうのがあったわけだ。
そこには「より一般化された方法論や機能性の強力さ」への渇望があったんだと思うし、それは「Windows 上がりなんで CUI 苦手で」とか口走る人の顔に浮かぶ恥じらいのような表情にも通底しているんだと思う。
なので、
1. dir最強
(snip)
はそのとおりだと思う。いまどきLinuxでも*BSDでもOpenSolarisでも（それこそバッドエンドかもしれないがCygwinでも）行っちゃえばいい。ただで行ける。そこには特に感興はない。
元々の感想は、大元の増田が情報を一覧整理してわざわざ増田にメモしようというような人であるにも関わらず、上のような一般性への希求があまり感じられないのが興味深いというものだったのだが、よくよく読むと大元増田にとっては「ファイル一覧イコールDVD上のMP3データ整理」なのだから、「音楽データ整理TIPS」として読めばそんなに不自然ではないのかも知れん。
おおどうもありがとうございます。
社会人暦は数年あるんですが、この業界に入ったのは今年の3月頃です。全く別職種から。
元々理系なんでCとかFORTRANのスパゲティコードくらいは書いたことがあったという感じでした。
自作PCは昔々に1台作りました。SATAの読み方は最近知りましたｗ
ジャンルはweb系ではないです。業務系でも組み込み系でもないですが。
ネットワークとDBはさっぱりです。あとGUIもわかりません。これはまずいと思っています…。
あと地味にUNIX系OSもよくわかってないです。
この前valgrindをインストールしようとしてよくわかんなくて諦めましたorz
今日はmakefileが上手く動かなくて発狂しそうになったりもしました。
emacsのキーバインドにも慣れないし、cygwinの日本語化も結局未だに上手く行かず…。
周りが優秀なので焦るばかりです。これは感謝すべきことですが。
プログラム一本で食べていけるとは思えないし、自分のやりたいこととも少し違うので、
プログラミングに関しては中の上から上の下くらいのレベルを目指そうと思っています。
あと1回は転職すると思いますし、今26なので、30までにはどこにでもいけるようになりたいと思っています。
それにしても憶えること多すぎですね…。全体がわかるようになるのはいつになるのか…orz
ああ、君にログインしたい……。今夜、telnetさせてくれないか……
嫌、telnetは嫌よ、あなたのpassが漏れちゃうわ……。ログインするなら、sshにして……
OK、sshにしよう。さあ、いつでもいい、port22を開けてくれ。僕を受け容れてくれ……
ああ、やっぱり怖いわ。私、怖い……。ログインされるのが怖い……
怖がることはないさ。誰だって初めてのリモートログインは怖いんだ。さあ、早くport22を……
……あのね、私……、本当はCygwinなの……。Linuxじゃない、にせもののLinuxなの……
何だって！？Cygwin！？君は……まさか君は、Windowsだと言うのかい！？
そう……私はWindows、Windows XP。それもHome Editionなの……
まさか、信じられない……。今まで僕は、君とrsyncだってしてきた、NFSで君をマウントだってした。僕はてっきり君のことをCentOSだとばかり思っていたのに……
ごめんなさい、あなたを騙すつもりはなかったの……
僕は君を信じていた……。だから僕は、一度も君をnmapすることはなかったんだ……
ごめんなさい、ごめんなさい……、私、ゲームをやりたかったの……、Wineでも動かないゲームをやりたかっただけなの……
……謝ることはないよ。僕は、君が好きだ。OSが何だったとしても、僕は君が好きなんだ。Cygwinの君には、立派なcygwin1.dllがあるじゃないか。
あなた……
gccの構文解析の結果（構文木）を、XMLとして出力してくれるツールです。C++の構文解析はやたらと面倒らしいので、こういうのがあるとうれしいみたいよ。
「Py++」というC++のPytyonバインディングで使われていたので、必要になりました。gcc-xml 0.6はバイナリで配布されてるんだけど、MSVC7.1までしか対応してないようで、Visual Studio 2005だと使えませんでした。うーん、困った。というわけで、最新版のソース一式を取得してビルドしてみます。
gcc-xmlのビルドには、CMakeというツールが必要になります。CMakeは、オープンソースでクロスプラットフォームのビルドシステムなんだとか。CMakeの公式サイトから、Windows版のインストーラーをダウンロードしてインストールしよう。
実は最初は、ここでcygwinのsetup.exe経由でのインストールをしてたんですけど、これだとgcc-xmlのビルドの段階でエラーが発生しちゃいました。この原因がどうしてもわかんなかったので、あきらめて公式サイトのインストーラーを使うことにした次第です。
ソース一式はCVSから取得できます。CVSクライアントはいろんなのがあるので、好きなクライアントを使って取得しよう。ここではcygwinのCVSを使って、シェルから以下の命令を実行して取得しました。40MBくらいあるみたい。
$ cvs -d :pserver:anoncvs@www.gccxml.org:/cvsroot/GCC_XML co gccxml
「Visual Studio 2005 コマンドプロンプト」を起動してください。起動したら、さきほど取得したソース一式が格納されているディレクトリに移動して、以下の命令を実行します。
$ cmake .
cmake.exeにはあらかじめパスを通しておくか、パスを直接指定するのを忘れずにね。
gcc-xmlのビルドはまだ終了してなかった！ 一度ビルドが終了しても、第二第三のビルドが必要となって…。などと恐れおののきましたが、二段階でいいみたい。
さきほどの処理が終了すると、同じディレクトリに"gccxml.sln"というソリューションファイルが新しくできあがっているかと思います。これをVisual Studio 2005から開いて、Releaseビルドしよう。ビルドが終了したら、以下の5つの実行ファイルができあがっているはずです。
まずは環境変数の設定です。Visual Studio 2005を使っていることを、gcc-xmlに高らかに宣言しておこう。
$ set GCCXML_COMPILER=msvc8
つぎに、gccからVisual Studio 2005のインクルードファイルを使えるよう、パッチをあてます。ありがたいことに、"GCC_XML/VcInstall"ディレクトリ以下にVisual Studioのバージョンによってパッチが用意されています。そのディレクトリと、パッチを当てたファイルを出力するディレクトリ（"gccxml.exe"が置いてあるディレクトリ）を指定して、"gccxml_vcconfig.exe"を実行してください。
$ bin/release/gccxml_vcconfig GCC_XML/VcInstall/ bin/release
あとはbin/releaseにパスを通せば、gcc-xmlが使えるようになったはずです。bin/release以下をどこか適当なディレクトリにコピーして、そこにパスを通してもオッケイです。やったね！ というわけで、さっそく試してみましょう。
$ gccxml eample1.cpp -fxml=example1.xml
ここでは、解析するC++のソースファイルとしてeample1.cppを入力し、eample1.xmlを出力しています。ちゃんと出力できたかな？ できたー！ やったー！
以上で終わりです。
以上のような組み合わせで出くわした困ったことと、その解決策をメモしておきます。
Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.
setup.pyに.iファイルとか.cppファイルを記述して実行すると、こんな感じのエラーメッセージが表示されました。うーん、困った！
http://labs.cybozu.co.jp/blog/mitsunari/2007/08/vc2005boostpython.html
上記のページを参考にして、"%Pythonをインストールしたフォルダ%/Lib/distutils/msvcompiler.py"を以下のように修正してみたら解決できました。ありがとうありがとう！
--- msvccompiler.py 2007-04-04 17:17:12.000000000 +0900 +++ @@ -126,7 +126,7 @@ self.set_macro("FrameworkDir", net, "installroot") try: if version > 7.0: - self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv1.1") + self.set_macro("FrameworkSDKDir", net, "sdkinstallrootv2.0") else: self.set_macro("FrameworkSDKDir", net, "sdkinstallroot") except KeyError, exc: # @@ -252,7 +252,10 @@ def initialize(self): self.__paths = [] - if os.environ.has_key("DISTUTILS_USE_SDK") and os.environ.has_key("MSSdk") and self.find_exe("cl.exe"): + if self.__version >= 7.1 or ( + os.environ.has_key("DISTUTILS_USE_SDK") and + os.environ.has_key("MSSdk") and + self.find_exe("cl.exe")): # Assume that the SDK set up everything alright; don't try to be # smarter self.cc = "cl.exe" @@ -288,10 +291,16 @@ self.preprocess_options = None if self.__arch == "Intel": - self.compile_options = [ '/nologo', '/Ox', '/MD', '/W3', '/GX' , - '/DNDEBUG'] - self.compile_options_debug = ['/nologo', '/Od', '/MDd', '/W3', '/GX', - '/Z7', '/D_DEBUG'] + if self.__version >= 7.1: + self.compile_options = [ + '/nologo', '/Ox', '/MD', '/W3', '/EHsc', '/DNDEBUG'] + self.compile_options_debug = [ + '/nologo', '/Od', '/MDd', '/W3', '/EHsc', '/Z7', '/D_DEBUG'] + else: + self.compile_options = [ + '/nologo', '/Ox', '/MD', '/W3', '/GX', '/DNDEBUG'] + self.compile_options_debug = [ + '/nologo', '/Od', '/MDd', '/W3', '/GX', '/Z7', '/D_DEBUG'] else: # Win64
setup.pyを実行するとcl.exeが見つからないみたいなエラーが表示されました。これは、アレだ。「パス通せ！」ということですね。bashを起動するときのバッチファイル（たぶん"cygwin.bat"とか）で、以下のような行を入れてやれば解決しました。
call "%VS80COMNTOOLS%vsvars32.bat"
d:\python25\include\pyconfig.h(189) : fatal error C1083: include ファイルを開けません。'basetsd.h': No such file or directory
setup.pyを実行すると、上のようなエラーが表示されました。
http://d.hatena.ne.jp/ousttrue/20070531/1180556273
上記のサイトを見るとインクルードパスが通っていない場所に"basetsd.h"があるのが原因なので、"cygwin.bat"にインクルードパスの設定をしておきました。
call "%VS80COMNTOOLS%vsvars32.bat" set INCLUDE=C:\Program Files\Microsoft Platform SDK\Include;%INCLUDE%
link: extra operand `/INCREMENTAL:NO'
詳しくは `link --help' を実行して下さい.
これは、cygwinのほうのlink.exeが実行されてるのが原因でした。スマートな解決策ではありませんが、cygwinのほうのlink.exeをリネームして解決。パスの設定順序とかでどうにかできるといいんだけど、どうすればいいんかな。
MSVCR80.dllが見つからなかったため、このアプリケーションを開始できませんでした。アプリケーションをインストールし直すとこの問題は解決される場合があります。
SWIGが生成した.pyファイルをimportしたら、こんな感じのエラーダイアログが表示されたよ。うーん、困った！
http://d.hatena.ne.jp/moriyoshi/20070525
上記のページを参考にして、"%Pythonをインストールしたフォルダ%/python.exe.manifest"として以下のようなファイルを新しく作ったら、解決できました。ありがとうありがとう！
あとこれ、bashから実行したらエラーダイアログが表示されず、importするモジュールが見つからないみたいなエラーメッセージが出力されるだけだったよ。
<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
知世入れたらkernel panicっちゃった……。
1GHzも無いCPU（Athlon4）、256MBも無いSDRAMでmakeしてたから（化石とかゆーな！そりゃKDEとかはキビシイけど、BlackBoxとかなら現役GUI環境だって可能なんだよ。でもやっぱりXfceがイイよね）、すっごく時間掛かったのに……。
またやり直さなきゃって思うと……憂鬱。祝日なのに明日休みじゃないし。
はやくdebぃあん♪debぃあん♪（「リリアン♪リリアン♪」のノリで）したいのに……。あ、debっていうのはDebian系のパッケージ名であるからして、その後楽しくインストールすることを表現しているのでもあるのですよ。XBillとか。
あと、窓から開発環境移さなくちゃだから、eclipse（CLOCKUPのじゃないよ）入れなくちゃだけれど、これも嫌ーな思い出があるから、ちょっと憂鬱。それとはやくリナ欲しいよL、I、N、A（ぽえりなじゃないよ）。何だか甘い響き。Cygwinなんてやってらんない。
