はてなキーワード: MacOsXとは
おじいちゃんの遺言でApple製品は使わない – NorthPage
父親がApple信者だったのでお下がりのPerforma 588を使っていた。
当時からMac系の雑誌では「MacOSはもうダメだ」と言われていたと思う。
元記事で指摘されている「マルチタスクができない」なども悩みの種だった。
「システムはWindowsが良いがGUIはMacが素晴らしい」というのが大方のApple信者の認識だった。
もちろん対外的には「すべての面でMacは優れている」と主張するのが当然だったが。
次期MacOSではそれらの欠点がすべて解消され、夢のようなOSになると言われていたが、
その開発に失敗したことでApple社への不満は頂点に達した。
https://ja.wikipedia.org/wiki/Copland
正確には、私がMacを使いはじめたのはコープランド開発中止のあとなので、リアルタイムの感想は分からない。
しかし雑誌などでは「コープランドが成功していればこうなるはずだった」というようなことがたびたび書かれ、
まるで理想国家建設に失敗して「どうしてこうなった」と嘆く共産主義者のようだったことは覚えている。
もちろん対外的には「MacはWinに負けてない」と主張するのが当然だったが。
「Macはディレクトリでなくフォルダだから素晴らしい」というのはよく分からない。
もっと昔はそういう言説もあったのかもしれない。
たとえば「マニュアルを見なくてもドラッグ&ドロップの意味が分かる」みたいなことではなく、
「このファイルをここにドラッグ&ドロップすればこうなりそう」という直感が当たる、といったような話だった。
このあたりは現在のiOSなどにも引き継がれているところだと思う。
まあ、どの企業もGUIデザインに気を遣うようになって相対的な優位性は無くなっているが…。
自分にとってジョブズは「教祖」というよりは「過激派の司祭」だった。
Windowsを攻撃するぶんには頼りになるが、彼の言うことを何でも信じていたわけではなかった。
MacとWinPCの性能比較には無理があったし、過去に言っていたことをすぐにひっくり返すし。
もちろん対外的には「ジョブズは素晴らしい」と主張するのが当然だったが。
とりあえずジョブズが復帰して、iMacが発売されて、Appleは勢いを得た。
同時期のWindows2000の画面と比べてみてくださいよ。
https://pc.watch.impress.co.jp/docs/article/990628/desktop.jpg
https://pc.watch.impress.co.jp/docs/article/20001018/wpe05_04.jpg
完全に未来でしょ。美しすぎるでしょ。これは調子乗っちゃうでしょ。
マカーが「MacはWindowsより美しい」と言いはじめたのはMacOSX以降じゃないかと思う。
それまでは「Macは可愛い」とか「人間味がある」「愛嬌がある」といった評価が多かったのでは。
話の落とし所がわからなくなってきた。
自分がなぜApple製品を使っているのかを考えると「最初に使ったから」という刷り込みが大きいのだが、
もう一つとして「Apple信者だから」というのがあるように思う。
Apple製品は良くも悪くもユーザーに使い方を押し付けるようなところがある。
これに関してはひとつ思い出がある。
初代iMacの「ホッケーパックマウス」は非常に酷評されていた。
しかし当時のAppleは「そもそも持ち方が違うのだ」と主張していた。
それまで(というか現在でも多いと思うが)マウスは「手のひらで包むように持つ」のが普通だった。
しかしホッケーパックマウスは「指で摘まむように持つ」ようにデザインされていた。
手首ではなく指を動かして操作するから腱鞘炎になりにくいのだ。
私はちゃんと摘まむように使っていたので、ホッケーパックマウスはコンパクトで使いやすいとさえ思っていた。
みんな、どうしてAppleの言うとおりにしないのだろうかと不思議だった。
信じる者は救われるのだ。
プログラマじゃないけどプログラミング完全に理解した()おばさんが理解してる基礎知識書くよ。
(追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず)
ターミナル、いわゆる黒い窓からCUI(コマンドユーザーインターフェース)でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。(追記 すごく間が抜けてたけどMacOSXはUnix系OSです)
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou > aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか?とりあえずやってみよう。ここで>は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。(追記 ブコメ指摘感謝)
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか7割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
(追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました)
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF(エンドオブファイル)とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
(追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います)
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか?こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
(追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです)
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
---------------------------
Finderで「移動」→「フォルダへ移動...」で下記を入れて「移動」
/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A
/Volumes/TimeMachine/Backups.backupdb/***/***/Macintosh HD/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A
(***のところは環境に合わせて書き換え←TimeMachineのHDを開いて確認)
Mac側の「MobileDevice」を「MobileDevice_」などとリネームしてバックアップして、
TimeMachineの方の同名ファイルをMac側にドラッグ&ドロップ
---------------------------
https://developer.apple.com/download/more/
#Yosemiteにインストール可能なのはVer6.3 - 7.2
#下記でバージョンチェック
https://en.wikipedia.org/wiki/Xcode
2) 下記にMobileDeviceがインストールされる
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A
Replace
/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
It works.
---------------------------
Finder - Go - Go to the folder...
/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A
Backup:
/Volumes/TimeMachine/Backups.backupdb/***/***/Macintosh HD/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A
#You must rewrite the *** according to your environment (see your TimeMachine hard drive)
You can see the file 'MobileDevice' in both folder.
#You should back up your original file before replace.
---------------------------
if you don't have backup, try this.
1) Download and Install 'Xcode'
https://developer.apple.com/download/more/
#Require ID (free registration)
#check this ;
https://en.wikipedia.org/wiki/Xcode
2) You can find the file 'MobileDevice' at
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A
ちょっとMacOSX 10.7 lion(古いな)の要約サービス.appと比べてみよう。
MacOSX 10.2(2002)ぐらいでもうすでにあった機能だけど、Macが新しくなったよってアップデートされたニュースの中にはなかった気がする。
まず、ブラウザ上でコピーできるテキスト範囲を選択して、メニューバーのアプリケーション名の下にでてくる「サービス」から「要約」を選ぶと「要約サービス」が立ち上がる。
ラジオボタンで「文」・「段落」を選択できるが、とりあえず「文」でやってみる。
パーセンテージを適当に調整して5行にまとめてみる。つまみを左右に動かしてサクサク文章量が変わるので、とくにAIで分析してますって感じがしない。
2002年に触ったときも、モッサリMacにしては早いと思ったんで、やっぱ特に変わってないんでは……。
結果。
そもそも時代をさかのぼっても、蕎麦などの麺類以外は音を立てずに食べるのが常識です。
...蕎麦はすすって食べたほうが風味を感じられて美味しいと言いますが、本当にそう思っていますか?
ラーメンもすすって食べたほうが汁の味と風味を鼻の奥で感じられるといいますが、本当にそうですか?
...もう時代は変わって音をたてて食べる人のほうが少なくなってきてることに気がついてほしいです。
次は「段落」
そもそも時代をさかのぼっても、蕎麦などの麺類以外は音を立てずに食べるのが常識です。
たくあんなどの漬物でさえ無音で食べるほうが良いとされています。
とりあえず
■ラーメンをすすって食べる人のことが大嫌いです。
って、大事な部分がスッポリ抜けてしまい、直前の文に対して受けた「そもそも」で始まってしまうのが致命的。
これでは文と文がつがらない(文脈がない)。この点においてIMAKITAの優秀さが分かる。
とはいえ、要約サービス.appが想定しているのは長文メールや契約書をザッと見直して注意点をピックアップする機能なんだろうからこれはこれでいいだろう。
トラックパッドの三本指スワイプでデスクトップ切り替え・ウインドウ切り替え。
これがMacOSXの操作方針なのでトラックパッドは必須。マウスは使えない。
たとえばジニーアクションは「ウィンドウがどこに収まったか」を強調するためのものなので、
けっしてオサレだけではないのだよ。
あと、Winで「これがないと作業できない」というアプリがあるのなら、それはもうWinを使うしかない。
Macの中で「Winのときと同じ仕事」をしているなら、そりゃWinでやった方がいいのは当然だ。
それはOSの出来とは関係のない、どこの世界でも共通の、仕方のないことだよ。
サイト作ったよー! - はてコま! | はてブコメまとめ B!
このサイト作っていろいろ確認とかして「さーて公開」って思った矢先に自分の作ったサイトからこんな記事見つけて「うひゃー!」ってなりましたw
はてなブックマークのトップページって、正直なんか飽きちゃったし、スクロールせずに表示できるのが数エントリーだけで、やたらヘッダがでかかったり、広告がでかかったり、欲しい情報がほんのちょっとしか表示されないし、気のせいかエロいサイトのサムネイルが表示されなかったり、デザインもまじめくさいし、改善したらもっともっと使いやすくシャレオツになるし、アクセスも稼げるんじゃないのって思います。
私も自分のサイトを作ろうと思った経緯はこの方とほぼ同じです。。公式って少し見辛いって思っていました。
そんなときにはてブ1000users超え記事アンテナ(´・ω・)|トップページを見つけて「あぁ自分で作るか」ってなりました。
週6フリーターさんがいろいろと使用したものを紹介してくれて、あまり技術のない自分でも作ることができました!
この場をお借りして、お礼を申し上げます。ありがとうございます!
では、恒例化している感じがする、サイト作成にあたってのご報告です。
使い方はいたって簡単。タグを選ぶか検索すると最近のはてブ100以上の記事があがってきます。
最初、サイトを作るにあたって「フリーターさんのものと差別化したいなぁ」と思ったので、私は"はてブエントリーのコメント"を"見る"ものに仕上げようと思いました。
なんでコメントを見たいと思ったかという原因はこちらの記事です。
この記事を読んでる人にも感じた人がいると思うのですが、タイトルを読んで「?」となりませんか?
記事を読み進めていくと更に「NSLog」が問題なのか??と混乱しませんか?
最初のタイトルの印象が強すぎて、はてブのコメントを読んでやっと正確に判断できました。
なので、コメントをもうちょい読みたいなーと思い、こういったサイトにしました。
それと、フリーターさんのとこに書いてあるものを参考にさせてもらってます。
本当にありがとうございます。
Webサービスを作ったことがなかったのですが、HTMLやCSSは知っていましたので、ほとんどVimでコーディングし、ブラウザで確認するという普通の作業をしていました。
phpは勉強したことがなかったので、わからないことがあれば都度ネットで検索していました。
JavaScriptでFeedを取得したり、PHPを使ってAPIからJSONを取得など、ファイルがまとまっていない感があります。
実は、bootstrapで作ったナビゲーションバーのドロップボタンがスマフォだと押せないんですよね。。
こういう問題があるときにフレームワークを使ったのを後悔しますよね。
実に手軽に使えるbootstrapですが、なんとなく使うのはオススメしません。
ネット上には他にグリッドシステムだけや、違う素材を配布しているサイトがあるので、俺俺フレームワークを作ることをオススメです。(でも、まとまっているという観点でbootstrapは使いたいですよね。)
サーバーはさくらインターネットのホスティングサーバーを使用しています。
初めて、こういったサービスを作ったのですが、小さい微調整に非常に時間がかかりますね。
見難い、見易いを考えながらコードを変更して、ブラウザで確認して・・・を繰り返すのは時間がもったいないですね。どなたかいいノウハウをお持ちではないでしょうか?
みなさんも、こう立て続けにはてな関連のサービスが立ち上がると自分でも何か作りたくなりますよね。
思ったら作って便利な世の中にしましょう!えいえいおー!
警告ウィンドウ等が画面中央に表示される
これはたぶん間違い。
画面中央に表示されるだけじゃ「モーダル」とは言わなくて、他の操作を受け付けなくなる物が「モーダル」。
「モーダルダイアログ」の方が一般的な呼称の気がしないでもないが、ダイアログって言うとブラウザのalert();とかのダイアログに限定してそうな響きがあるから、「モーダルなボックス要素」ってことでモーダルボックスって言うんかな。
→ アクアボタン
これは間違い、って言おうと思ったけど、そうでもないのか。
MacOSXのUIのスタイルが「Aqua」って言って、そのAqua風のボタンだから「アクア風ボタン」。ボタンに限らず、チェックボックスでもスクロールバーでもAqua風になりうる。
こないだNHKオンデマンドに申し込もうとしたの。
そしたらなぜか登録できないわけ。
必要事項は入力してあるのに、登録ボタンをを押すと必要事項を入力して下さいって言われる。
おかしいなぁと思いつつIEで試したらちゃんとログインできたんだよ。
あれー?firefoxに対応してないのかなぁと思って問い合わせたらこんなメールが来たよ。
はやくマックや他のブラウザでも使えるように、みんな、おらに力を貸してくれ!!
NHKにメールを送って。他のOSやブラウザにも対応してって。
申し訳ございません。現在、Macintoshや他ブラウザでの、
使用は出来ない状態です。
NHKオンデマンドサービスは、可能な限りオープンな規格の採用を
目指していますが、コンテンツ保護、サービスモデルの実現等の観点から、
端末機器のソフトウェア・機能に関する一定の条件を設け、こうした
ソフトウェア・機能を備えたものを逐次対象に加えることとしています。
ビデオ・オンデマンド・サービスを実現できるDRM(Digital Rights Management)
が必要となりますが、システム構築を開始する時点では、安定運用の実績があり、
コストなどの観点からこの条件を満たすDRMは、Windows Media DRMしか選択肢がないと
判断いたしました。結果として、WindowsMedia DRMが稼働しないMacOSXはサービス開始時点では非対応とさせていただきました。対象OSの拡大は、今後のサービス拡充の大きな柱の
1本と考えており、調査、検証などを踏まえまして、実現を目指していきたいと考えて
おりますので、よろしくお願いいたします。
改善していけるように致しますので、今後とも
ご意見・ご要望などお待ちしております。
僕はMacユーザだ。最初に買ったのはスケルトンのiMac。FirewireとDVD-ROMがついているやつで、色はグリーンだった。OSはMacOS9.0.2。もう10年近く前の話だ。
僕がMacを買ったのは、ひとえに絵が描きたいからだった。正直Windowsにするかどうか、とても悩んだ。でもその頃買った色彩王国という色の塗り方をプロにインタビューした本では、CG塗りをしている人はMacを使っていた。だから僕もMacを買った。その頃は絵のプロになる気満々だったから、A3までプリントでき、カートリッジを交換すれば同じくA3までスキャンできるプリンターと、とても高かったけどPhotoshop 5.5J、そしてタブレットも一緒に買った。さすがにタブレットまではお金が回らなくて、Favoの一番安い奴になっちゃったけど。本を読んでPhotoshopでの絵の塗り方を勉強した。自分なりにいろいろいじって、デジタルトーンのかけ方を覚えたりもした。それで僕は満足していた。その頃に描いた絵は今もちゃんととってあってpixivにアップしてあったりする。
でもMacに不満がないわけでもなかった。興味本位でプログラミングをやってみたいと思っていたけど、ネット環境もなく大型書店もない田舎住まいの僕にはMacでのプログラミング方法なんて分かんなかった。それに、爆弾がよく出たりとか、どこにファイルを置いたのかすぐ忘れてしまったりとか、そういうところでも不満があった。
そして、絵のプロを目指すとか思っていたのに、いろいろ思う所あって実家を離れ大学に進学した。学科はプログラミングが出来そうな情報系を選んだ。そして大学で、コンピュータ室の管理のアルバイトをすることになった。
そのアルバイトでは、大学で使っているUNIXシステムのユーザサポートと、その他の雑用をやった。雑用用にはWindowsXPだったか2000だったかのマシンを使わせてもらえることになった。そして驚いた。WindowsはMacよりも使いやすかったことに。
ユーザのホームがあってその下にマイドキュメントがあって、とどこにファイルを保存すればいいのか簡単に分かったし、それゆえ作ったファイルが行方不明になってしまうこともなかった。安定性も高かった。
ただ、プログラミングに関しては大学の授業とバイトの兼ね合いで、WindowsではなくUNIXを使ってやることになった。最初に覚えたのはCだ。UNIXの世界に触れたのも、僕にとっては非常に大きなカルチャーショックだった。それまでアイコンをクリックして何かが出てきて、といったGUIの世界しか体験したことのない僕にとって、コマンドを打ち込んであれこれやるというCUIの世界は、なんと言ったらいいんだろうか?効率性とかそういうものも当然感じたけれど、でもそれ以上にコンピュータの原点というか、よりコンピュータの弱いところというか、コンピュータに自分が降りていくというか、そんなことを感じた。変なことを書いたがとにかく、コマンドを使ってファイルを作って消して実行して、自分がどこに居るかということは見た目ではなく自分の頭の中で把握していなければならない、自分の他にもコンピュータのユーザが居る、まるでコンピュータの中のマンションに住んでいるような錯覚を覚える文化に、虜になったとまではいわないが非常に感銘を受けた。
さて、次に買うマシンはどうしよう?と思ったとき、僕はWindowsを買おうと思った。UNIXシステムは大学にあるし、Linuxを入れるにしてもまずはPCを買わなければならない。そう、このとき僕の中で2代目のマシンをMacにするという選択肢は綺麗に消えていた。しかし、そんな僕を変える出来事があった。MacOSXとの出会いだ。
バイト先ではどんな環境のユーザから問い合わせがあるか分からないから出来る限りいろんな環境を揃えなくてはならないという理由で、2台だけだったがMacも置いてあった。僕がMacユーザだと知った技官の方は、そのMacの管理を僕に一任した。そのMacに当時ですら古かったMacOSX10.0が入っていたのだ。
この最初のMacOSXは評判が悪かった。すぐ固まる、落ちる、今までのソフトが使えない、そんな悪評を僕はマックの雑誌で沢山目にしてきた。しかし実際にこのMacOSX10.0をみて、それらの評判がそう的外れなものではないということはすぐわかったが、MacOS9に比べると、Windowsのように自分のホームがあって基本的にファイルがそこに置かれるというところは改善点だと思った。だがそれ以上に僕を魅了したものがあった。ターミナルの存在だ。今までのようにGUIを使ってファイルを作ったり移動したりすることができる。しかもそれをUNIXのように(実際UNIXなのだが)CUIの世界から眺めることもできる。その逆もしかり。それにWindowsでは面倒なUNIXへのログインも、sshを使って簡単にできる。そんなことにとても感動した。そしていろいろ調べているうちに当時最新のMacOSX10.2だったらX11betaも使うことができると知って、技官の方や先生へ直談判した。技術的なことにどん欲な彼らはそれに非常に興味を示し、MacOSX10.2を買ってもらえた。僕は早速それらをインストールし、Mac上でUNIXサーバからEmacsの窓を引っ張ってきた。それだけのことであるが、それがたまらなく楽しかった。いつどこの研究室からどんな問い合わせが来るか分からないから、暇なときはMacを使って勉強しなさい、と言ってもらえ、僕はMacに夢中になった。日本語Texを入れたり、Mac上でCやJavaの勉強をしたりと、それはとても楽しい時間だった。そんな僕は次のマシンもMacにするぞ、と固く心に近い、そしてその通りまたMacを買った。友人達がコンピュータ室にこもってプログラミングの課題をこなしているとき、僕は早々に家に帰って自宅のMacからサーバにログインして課題をこなしたものだ。
今この文章も、当然Macで書いている。今はWeb開発系のバイトをしていて、その上でもMacはいい選択肢だと思っている。ペーペーの僕の遥か上を行く開発チーフ達もうちの会社の場合ほとんどMacだ。ApacheをはじめとしてWeb開発に必要なものはほとんどあらかじめインストールされているし、足りないものはMacPortを使ってすぐにインストールできる。ブラウザでの表示確認にはSafari、Firefoxをはじめとしたモダンブラウザが使えるし、Parallels Desktopを使えばWindowsもインストールでき、そのブラウザからMac側で動かしているWebアプリの表示確認をすることだって出来る(たいていはIEに失望することになるが)。
絵を描きたいというところから始まった僕のMac人生だけれど、Web屋もどきになった今でも重宝している。これからもよっぽどのことがない限り変えることはないだろう。非常に長く主観的な思い入ればっかりの文章を書き連ねてきたけど、これが僕がMacユーザを続けてるわけ。
気になったエントリをいくつかクリップしてみる。47氏やジーン・カン氏はどんな未来を想像していたのかが知りたい。
楽曲対価を支払うたったひとつ(ではないかもしれない)の冴えたやり方
...
著作物に対する権利の主張と確保、という点からのみ語られがちな一連の問題を、著作物に対する対価の支払いを進んで積極的にしたいと思ってる側から考えてみる。
...
むしろ、そういうJASRACが噛まない料金徴収システム(送金システム)を、ユーザーのフェアユーズ&シェアユーズを満たす形で整備したほうが、事業者にとってもユーザーにとっても原曲作者にとってもプラスなんじゃないの? と思ったりはする。
さぼり記 2007-12-20 http://d.hatena.ne.jp/azuki-glg/20071220/1198121928
コンテンツは何のために必要なのか
...
私的録音録画小委員会: 反対意見多数でも「ダウンロード違法化」のなぜ (1/2)
この内容は流石に怒っても良いよね?
...
そういった、今のお金を大切に思うが余り施行した法により、未来のこれから出てきたかもしれない革新的な文化活動の発展を萎縮させ、クリエイターの卵となるべき人たちの芽をたたきつぶしたといったことの大きさを憂える。ひたすらに。
rerofumiのつぶやき 2007/12/19 http://www.fumi2kick.com/rrtalk/archives/932
誰が音楽文化を支えるのか
...
音楽の世界だって書籍と同じように、オリコンチャートを意識して売り捌きようのない枚数のCDをプレスするという時代錯誤で不毛なチキンレースは遠からず終わり、いくつダウンロードされたか、総額いくら寄付を受けたか、世界中でノベ何時間再生されたか、そこからどういった二次著作物が生まれたか、誰をどう触発したか、何にマッシュアップされたかといった、もっと本質的な尺度で測られるようになるだろう。
雑種路線でいこう 2007-12-04 http://d.hatena.ne.jp/mkusunok/20071204/music
音楽そのものについての考察がおきざりにされた著作権議論の不毛
...
音楽著作権というのは無前提に音楽の創造者にある権利だとして、そこの検証が全くされないままそれが前提に議論がされているが、音楽著作権という考え方そのものがそもそもイリュージョンだったのではないかという検証は本当に必要ではないのだろうか?
...
「グヌーテラは音楽著作権を侵害しているがどう思うのか?」という質問が次々投げられた。この質問に対してジーン・カンは実に冷静に答えていた。
「グヌーテラを停止させることはもはや私にもできないのだ。
いわゆる『音楽著作権』の侵害はあるかと聞かれれば『その通りだ』と答えざるをないが、もはや『覆水盆に返らず』だということを認識した方が良い。
それよりもこの状況に合わせた新しい権利の設定を考えた方が遥かに現実的だ。
現在の音楽の著作権は太古の昔から存在しているようにみんな勘違いしているが、音楽家とは本来その演奏に対する対価として報酬を受け取っていたので、著作権という抽象的な録音定着、複写の制限を定めた権利はつい最近生まれたものだ。
まずそのことを勘違いしない方が良い。
MacOSXの新着アプリテスト記録とトラブルシューティング http://nmuta.fri.macserver.jp/unei0712.html#musiquecultual
47氏が見たラジカルな世界
...
まず、言えることは、47氏は現状のWinny自体にはそれほど関心を持っているわけでもないということだ。問題は次だ。
4. コンテンツ提供者側の集金問題
話変わりますが、最近私の方ではコンテンツ流通側とは逆側のコンテンツ提供者側に関するシステムについて考えてることが多いです(コンテンツ提供者向けのシステムであって、よくあるようなコンテンツの保護技術に興味があるわけではないので注意)
そもそも私がファイル共有ソフトに興味を持ったのは、当時ファイル共有ソフト使用ユーザーから逮捕者が出たということ(これは明らかに変だと思った)というのもありましたが、どうやったらコンテンツ作成側にちゃんとお金が集まるのか?ということに、もともと興味があったからです。
インターネットの一般への普及の結果、従来のパッケージベースのデジタルコンテンツビジネスモデルはすでに時代遅れであって、インターネットそのものを使用禁止にでもしない限りユーザー間の自由な情報のやりとりを保護する技術の方が最終的に勝利してしまうだろうと前々から思ってました。そして Freenetを知って、もはやこの流れは止められないだろうと。
極東ブログ 2004.05.11 http://finalvent.cocolog-nifty.com/fareastblog/2004/05/47.html