« 2010年8月 | トップページ | 2010年10月 »

2010年9月

ツールの「使い方」と「正しい使い方」

ツールなんてのは、まあ、用途次第でどうとでも使えるもので。
とはいえ、例えばドライバーで、「穴を開けようとする」のは、効率が悪いわけです。
でも、実際には開けてるひともいたりして。(笑)

シンプルであればあるほど、ツールってのは、幅広い用途に使えるのも事実です。
前述のドライバーであれば、サイズさえあれば、組立家具を作るのから、自動車のメンテナンス、果ては工作機械の組立まで、様々な用途に使えるわけです。
#っても、目的はただひとつ、ねじを締める、緩める、だけ、ですけどね。

一方で、専用ツールというのも存在し、これは「用途が限定」されているツールなわけですね。
それ専用に作られていて、それをするのに、すごく効率がよい。
#ちと一般的な例が思い浮かびませんが、治具と呼ばれる類のものがそれにあたりますかね。

という辺りが前置きで。(笑)

Twitterの話だったりしますけど。
まあ、これもツールなわけです。
捉え方は色々ありそうな気もしますが、ツールであることには間違いない。

で、ツールなので、使い方がある。
もちろん、用途も、目的もある。

でも、Twitterってのは「シンプルなツール」なわけですよ。
用途は幅広い。汎用的なツールといえるでしょう、ドライバーのように。
情報交換に使えるでしょうし、単なる雑談にも使えるでしょうし、ホントに「つぶやき」にも使えるでしょうし。
単に、用途としては、140字以内の「言葉」をポストするツールに過ぎないわけです。

で、これの使い方はどういう使い方をすればいいか、というと。
「目的」から考えれば、別になんでもいいんですよね。140文字という制限の中で、適当にポストする。
これが「正しい」使い方です。
ツールの目的がそれしかないので。

それ以外のフォローがどうとか、リプライがどうとか、RTとか。
この辺は、ツールの機能としては、おまけ、なんですよね。
目的からすれば。

ツールが作られた目的と「使う人の目的」を混同すると、話はややこしくなる、とワタクシは考えています。
ツールの作られた目的は前述の通り。
ただ、ユーザーの目的は様々だったりします。
そのツールを使いたい用途が異なるので。

汎用ツールなのに、「ドライバーでカラーボックスを作るのは間違っている、それは車のメンテナンス用に使うべきだ」とか言われても困るわけですね。
だって、カラーボックスだって、作れてしまうのですから。
ただ、穴を開けるのには向きませんけどね。(笑)

まあ、なんの話かというと、Twitterのような「汎用ツール」は、使う人の目的によって「正しい使い方」が異なるわけです。
ただ、ツールの性格とか目的から、140字以内という制約があるので、それを守っていれば、使い方としては「正しい」んですよね。
なので、用途の違うひとに対して、「その使い方は間違っている」って主張するのは、単なる押し付けに過ぎないわけです。なので、齟齬が生まれたり、軋轢が発生したりする。
幸いTwitterには、そういう「同じ目的のひと」を探すための機能も備わってるし、そうじゃないと解ったときには、切り離すための機能も備わってるわけで、声高にそれを叫ぶよりも、黙ってリムーブ、が穏当なやり方なんじゃないですかね。

まあ、別に主張に使ってもいいので、主張するな、とはいいませんが。
名指しでやる場合には、ちょっと注意が必要かも知れません。

こと、Twitterに関しては「こうあるべき」は、本当にひとによって異なると思います。
なので、目的や用途が異なるツィートに出会ったときは、「まあ、そういう使い方もあるか」程度に考えて、スルーするのがいいんじゃないのかな、とワタクシなんぞは思いますがね。

| | コメント (4) | トラックバック (0)

なんじゃこら?

Twitter見てたら、こんなアドレスが紹介されてた。
壁紙らしいのだが…。

まあ、日本でもWindows7の時に窓辺ななみとやらでキャラクター戦略を取ってたので、各国法人で、それぞれの販売戦略があるのかも知れない。

Silverlightの用途は、いまのところよく解ってないので、なんとも言えないが、ヲタ向けの機能満載なのだとしたら、存外このキャラクター戦略というのも間違ってないのかも知れないけど。

正直意外だった。(笑)

まあ、日本のななみちゃんの時も、なんじゃそら、と思ったものだけど。
MSそのものは、結構柔軟な企業なのかも知れない。

まあ、頭が固い、のはLinux陣営の方かも知れないしね。

最近は萌えOSとか、萌えぶんちゅとか出てきてて、日本のLinuxもだいぶ柔らかくなってきてるよな、とは思ってたけど。

それでも、まだまだLinuxには、ヲタなアプリは少ないし。
#Windowsに比較して。

MS各国法人が、萌え戦略を取ってきたら、ヲタな連中は、やっぱりWindowsじゃね?ってことになりそうな。(笑)

Appleもこういう動きを受けて、なんかやれば面白くなるのに。
本家US法人のMSがなんか動きを見せないと、対抗はないかな?(笑)

ま、いずれにせよ、これで眉を顰めているようでは頭が固い、と言われても仕方ないですな。
なかなかやるな、と笑い飛ばせるくらいじゃないと。(笑)

| | コメント (2) | トラックバック (0)

悪い方向に転ばなければいいけどね。

OpenOffice.orgコミュニティ、Oracleから独立。名称も「LibreOffice」に - SourceForge.JP Magazine : オープンソースの話題満載

OpenOffice.orgの開発コミュニティは9月28日、10年間に渡って同プロジェクトを支援してきたOracle(旧Sun Microsystems)から離れ、新たに独立組織「The Document Foundation」を立ち上げると発表した。同組織の下、OpenOffice.orgは新たに「LibreOffice」という名称で開発やリリースが続けられる。

ある程度、予測されていたこととはいえ。
こうなりましたか、やはり。

Oracleは、何がしたかったのかなー、と改めて思ってしまいましたが。
やっぱり単にJavaと仮想化技術が欲しかったのかなー。

一番大きいのはJavaかな、という気がしないでもないけど。

いずれにせよ、Oracleは、小物を相手にしてないのと思われるし、本家DBの売上だけで充分な利益を出せてると思われるんだけども。

もう少し、OSSに対して寛容なところを見せた方が、各種コミュニティに対して、好印象を持たれて、優れた技術者を得ることも可能になるんじゃないかと、思われるんですがね。
ま、それすらも、Oracleは十分と考えてる、ってことなのかも知れないんですが。

大物二つ、Oracleの手から離れたわけで。
さて、他のはどうなるんですかねぇ。

| | コメント (0) | トラックバック (0)

FirefoxSyncを入れてみた。

なんだかXMarksがサポート終了になるらしく。
仕方ないので、FirefoxSyncを入れてみた。
んで、今のところ、他のPCとの連携も含めて全部XMarksでやってたんですが、まあ仕方ない。
iPhoneでも使えるみたいなので、そちらにも入れてみる。

で。
意外に便利。>FirefoxSync
特にiPhoneで。(笑)

まあ、別にiPhoneで普段と同じサイトなんて見ないでしょ、と思ってたんですが。意外に見るもんですね、てか、見れるとなると見るものなんですね。(^^;

Chromeとの同期が取れなくなるので、XMarks使ってたんですが、まあ、こればかりは仕方ないかな。
ほとんどFirefoxしか使ってないし。
Chromeは、たまに興味で使うだけだしな。

というわけで、移行しましたよ、っと。

ちなみに、移行ってほどのものではなく、FirefoxSyncのアドオンを入れて、XMarksを削除した、ってだけですかね。
まあユーザー名やらパスワードやら秘密の言葉やらは、KeePassXで管理しとけば間違いないところでしょうか。

まあ、iPhoneを使ってるのなら、悪くないかも知れませんね。

| | コメント (0) | トラックバック (0)

AVアンプをPCに接続して見た。

先日、義兄から貰ったAVアンプをPCの方にも接続して見た。
2分岐のピンジャック買ってきて、ピンジャック→RACケーブルで。
まあ、そういう点で見るとケーブルそのものの品質は、間違いなく悪い。
そんでも。
やっぱり音は違うもんで。

みくった〜♪の通知音が妙に厚みのある音で再生されて、違和感があったり。(笑)
せっかくだから、みくでも、と思って、みくつべ♪を起動して再生して見ました。

で、思ったのが。
「PCはしょぼいスピーカーでいいや」とか。(^^;

思っていたより、YouTubeに上がってる動画ってのは、音声品質に差があるようで、動画ごとのその品質の差がはっきり解っちゃうんですよね。
これまで、そんなの全然気にならなかったのに。
もちろん、良い音の動画は、大変よく聞こえます。
まあ、ビットレートの問題なんでしょうが、こう妙に音が薄っぺらいのがある、って感じといえばいいんですかね。
先日PS3に接続してBDの映画を試しに再生した時なんかは、そらもう迫力ある音で再生されて、こらすげぇと思ったんですが、ソースが貧弱だと、その差が明確になってしまう、という弊害もあるんだなぁ、と改めて思いました。

当然ちゃ当然の話で。
これまでは、良いはずの音が再生環境が劣悪なせいで悪く聞こえていたので、ある意味最適化されて、どれを聞いても同じ、という状態だったのが、再生環境が改善されて、「ソースなりに」聞こえるようになってしまったので、その差が明確に現れているという。
元々オーディオ関係は疎い方でも、これだけ明らかに違うと、はっきり聞いて解ります。
悪いのは、良いのと比較してしまうと、ぶっちゃけ聞くに堪えない。(^^;
低音ないし、高音も妙に薄っぺらいし。

義兄が、以前に「MP3なんてダメ」って言ってたのを思い出しました。
WAVEで吸い出すなら聞けるけど、MP3で圧縮したものは聞いてられない、と言ってたんですよね。
当時のワタクシは、それほど差があるとも思ってなかったし、耳がいいひとは違うもんだなー、なんて思ってたんです。
#後日、義兄のところで、「ワタクシには」高級ヘッドフォンで聞き比べをさせられて、納得したもんですが。

圧縮時のビットレートでMP3でも、大きな劣化なく圧縮は出来ると思うんですが、YouTubeの場合には、それがバラバラで。
もちろん、動画サイズの制限とか、初期は厳しかったし、事情やら都合やらあるとは思うんですが。

で、結論的には。
常時使うのはやめよう、と。(笑)

なんか、ソースのいいのを聞くときだけ、AVアンプを使うことにしましょうかね、とワタクシ的に結論しました。
#CD再生とか。
しかし。
違うもんですねぇ。(笑)

なんか、久しぶりに帰ったら、「我が祖国」でも聞くかな。

| | コメント (2) | トラックバック (0)

大丈夫だよ、Jack。

ユーザーに優しいソフトウェアの条件とは--満たすべき10箇条を紹介 - IT業界を生き抜く秘密10箇条 - ZDNet Japan

筆者は最近、ユーザーの使いやすさ(特にLinuxに関するユーザーの使いやすさ)の問題について、何人かの読者の神経を逆なでしてしまったようだ。もちろん、この議論はLinuxだけに限った問題ではない。ユーザーの使いやすさの議論は、あらゆるOS、エンドユーザーアプリケーション、社内の専用アプリケーション、その他さまざまなソフトウェアに適用できるものだ。

大丈夫だよ、Jack。君の記事で神経を逆撫でされたりしない。
ワタクシは、君の記事をいつも楽しみにしているよ。(笑)

ってことで。(爆)

1.インストールしやすい

これはイマサラ、な部分がありますな。
*BSDが素人ウケしないのは、まさにこれでしょうし。
ラクなUnixが使いたいひとがMacOSXに流れるのは、これゆえでしょう。
異論なし。

2.アップデートしやすい

これもその通りだろう。MSがMicrosoftUpdateを導入したのはこのためだし。
MSの行ったことは、間違ってない。
…アップデートのたびに再起動を要求されなければ…。

3.直感的

まあ、概ね同意なんですがね。GUIが貧弱だと使われない傾向にあるのは事実だし。アプリケーションの品質や性能が良くても、見た目が悪いと使われないし、使いにくいGUIはCLIにも劣るのは間違いところで。
ただ、一点論法が違うというか。
GUIに頼りすぎてはいけない、ってのは、そんなことなくて。
まず、ソフトウェアは期待通りに動作しなければならない、ってのは大前提なんだよね。これが成り立ってないと、「ユーザーに優しいGUI」も「使いやすいGUI」も成立しない。
期待した動作を正しく行うソフトウェアであることを前提として、UIの優劣は初めて語れるものであろう、とワタクシは思うんですが。
なので、「GUIには頼り切って良い」とワタクシは考えるところ、かな。

4.効率的

で、ここでようやく、ネタ的に美味しい話が出てくるんですが。
MSのリボンインターフェースですが、デザイン上の問題じゃないと、ワタクシは実は考えています。
というのも、これまでのドロップダウンメニューでは表現しえない、視覚的な情報をユーザーに同時に与えているわけで、不慣れなひとにも、ある程度効率的な操作を可能にしている、とワタクシは考えています。
さらに付け加えるなら、階層的メニューの操作性と効率の悪さは、マウスはともかく、タッチパッドなどのデバイス、そしてこれから現れるであろうタッチパネルなどのデバイスとは、あまり相性が良くないだろうことが想像できるんですね。
しかし、リボンインターフェースなら、充分なサイズがあり、かつアイコンによる視覚的ガイドによって、直感的な操作を提供するんじゃないか、と。
ただ、唯一問題は、そのサイズ。
XGA程度の解像度だと肝心のドキュメントの領域が狭くなってしまう。
ただし、これも、簡単なショートカット操作で表示/非表示を切り替えられるし、操作の熟練度によって、より簡単に素早く操作出来るというMSの伝統は守られていると考えてるんですよ。
さらに言えば、従来のドロップダウンメニューからの脱却により、これまで整理の困難だったカテゴリを整理しなおすことで、より直感的な操作を目指したのではないか、とワタクシは考えているのです。
改悪、デグレードと思われてるリボンインターフェースですが、その裏には、これからPCの世界を席巻するであろうタッチパネルへの布石ではないか、と。
MSは、常にUIには先手を打ってきました。
そのMSが、今、何も考えずにあれを採用するはずがない、という側面から考えた結果、行き着いた結論なんですがね。

ああ、あとリボンインターフェースの「現時点」での欠点として、カスタマイズが出来ないってのがありますが、まあ、どうも次のバージョンで改善されるみたいだし、正直カスタマイズ性は、さほど重要とは考えてないので、ワタクシには欠点ではありえませんでしたが。

いずれにせよ、旧来のインターフェースが、タッチパネルに対して優位足りえるか、と考えると、ワタクシの回答は否、でしかありません。
これからのOfficeを考えたとき、リボンインターフェースは、「正しかった選択」になる可能性は高い、と考えてます。
ま、3年後くらいにはっきりするんじゃないですかね。(笑)

5.心地よく、分かりやすいGUI

うん、もう書いちゃったんだけど「従来のUIと異なる配置だから使いにくい」ってのは、思考停止と言っていいと思うんですよ。
なぜ、そのGUIなのか、そこを論じるべきであろう、と。
見た目がよい、それは実は本質じゃないと思うんですね。
なぜ見た目をよく出来たか。それは、面積が大きいからなんです。
だからデザイナーが見た目を良くする余地ができた。
従来のドロップダウンメニューでは、それは困難だったし。
ただ、それは余録、オマケに過ぎない、とワタクシは考えてるのです。
理由は前述の通り。
デバイスの進化に対して、いち早くMSの出した回答がリボンインターフェースだろう、と思っているのです。

つまり、旧Officeをタッチパネルで使ってみてどう思うか、と。

めちゃくちゃ使いにくんじゃねぇの?とワタクシは考えたんですね。
なので、「これから先のPCでも」心地良く解り易いGUIを目指した結果がリボンインターフェースではないか、と。
まあ、先に書いた通りです。

6.簡単に削除できる

まあ、これも同意ですが、Linuxアプリが簡単に削除できる、と思って言ってるなら、勘違いかと思われます。
結構ゴミ残るんだよね。HOMEとかに。(笑)
ま、その辺は大目に見たとしても/etcとかにも残る場合があり、案外パッケージシステムも、稼働してから作成されるファイルまでは面倒みてくれないので、パッケージャに依存するところではあるなぁ、と、思ったりしました。

ちなみに、最近のWindowsアプリの方が、よほど綺麗にアンインストールしてくれます。レジストリまで含めて綺麗にしてくれるのが増えましたね。
まあ、まだお行儀の悪いのは残ってますけど。
フリーウェア系は注意が必要ですかね。

7.サードパーティーソフトウェアを必要としない

えー、Linuxって、ある意味サードパーティアプリケーションのカタマリじゃないかと思うんですが、そこはツッコムところじゃないんですね、解ります。

8.トラブルシュートしやすい

これは、開発者にとっては、尤も注意を払うべきところであり、尤も頭の痛いところであるのは事実です。
実に様々な環境で動作させられるOSなどは、むしろトラブルが起こらない方が不思議だろう、と。
なので、このトラブルシュートしやすい、というのは非常に重要ですが、なかなか、綺麗に解決出来ている例を見ません。
MS製品でも、まだまだ、ですね。
情報は収集して、次回バージョンとかに反映されるのかも知れませんが、エンドユーザーにとっては「今」困ってるわけで。
ま、非常に困難なことである、とだけ。(笑)

9.標準に従っている

えー、いまや世界標準はMSです。
Emacsは(ry
Vimも、…おっと誰か来たようだ。

10.効果的なエラー処理

8に通じるところでしょうかね。

まあ、正直テーマであるところの「ユーザーに優しいとはどういうことか」に関しては、あまり突っ込んだ記事ではなかったようですが。

ワタクシ的に、ユーザーに優しいシステム、およびアプリケーションというのは、「空気のように意識されない」システム、およびアプリケーションだと思います。
それだけ存在感のないものである方が、「作業をする」「成果物を作る」ことに集中できるわけで。
まあ、そういうアプリケーションも、世の中にはありそうですが、「意識されない」だけに、宣伝もされないんでしょうね、きっと。(笑)

ただ、真にユーザーに優しい、というのは、非常に困難である、とは、開発者のひとりとして書いておきましょうか。
ユーザーのレベルというのは、本当に様々です。
今日PCを使い始まったひとから、PCがマイコンと呼ばれていた時代から使ってるひとまで、熟練度で考えると、本当に天と地ほどの差がある。
その万人に対して、優しいシステムというのを実現するには、やはり「熟練度に合わせて操作を簡便化できる」ことが意識されている必要があると思うんですね。
MacOSXは、使ってないので解りませんが、Windowsは、その点でもよく出来ている、とワタクシは考えますが。
まあ、これは元記事の筆者とは意見の異なる部分かも知れませんね。(笑)

| | コメント (0) | トラックバック (0)

AVアンプ貰った。

義兄にAVアンプを貰った。モノは年代モノで、製品発売は1997年。実に十年以上前の代物。
棄てる予定だったらしいが、使うなら、ということで、持ってきて貰ったんですが。
PS3に繋ぐのに使おうと思いまして。
実はこれまでも安物のコンポに繋いで、それなりにスピーカーから音は出してたんですけど、まあ、TVというか、AVモニタのちゃちなスピーカーよりはマシでしょって感じで。
んで、これが。
貰ったAVアンプに繋いで見ると明らかに音が違う。
まあ、そちらに関しては素人なので、具体的に何がどうとか解らないんですが、音に厚みが増したと言えば伝わりやすいでしょうかね。
同じスピーカーから出ている音とは思えない。(笑)
入力端子もたくさんついてるし。
思わずPCもこちらにつないじゃろうか、と思った程で。
ま、PCの方はそんな立派なスピーカーから音出してもね、ってのはあるんで、多分見送りだと思うけど。(笑)

そんで、値段調べてみたら、当時の新品価格が12万!
そんなの買ってたのか、あのひとは!とか思ってしまいました。
まあ、オーディオマニアとは聞いてたけど。
とまあ、自室のAV環境がいきなり改善されてしまいました。(笑)
とはいえ、スピーカーがしょぼしょぼなので、実力は発揮されてないとは思いますけどね。
なんか、こうなると5.1chとかもためしてみたくなるよなー(笑)

| | コメント (0) | トラックバック (0)

bootchartの不思議

なんか、SATAEI-LPPCIを導入してから、起動に時間がかかるようになったので、何が原因かを調べるために、bootchartをインストールしてみたんです。

そしたら、なぜか高速化されてしまいました。
謎です。
bootchartインストール時にinitdr.imgとかは再構築されるんですが、それはすでに手動でも行っていたので、ちと納得行かない点が。
何が起きたのか。

結果、16秒でbootchart記録部分は起動するようになってますが、謎すぎる。
ちなみに、結果を確認したので、bootchartはアンインストールしたんですが。

やはりSSD性能がボトルネックになってますねー。読み出し140MB/sは出てるんですが。
200MB/s超のSSDじゃないと、bootchart10秒切りは難しいかも。
いろいろサービスも起動してるわけで。
#sambaとか。

それで、この起動時間なら十分満足のいく性能とは言えるんですけどね。
ま、10.10でも、また高速化されてるらしいので、そちらに期待しましょうか。

| | コメント (0) | トラックバック (0)

SATAポート増設。

これもTwitterで話題に上ったので買ってみた。(笑)
PCIのSATAカードは、比較的安価なので。
で、買ってみて失敗だったのは、1ポートはeSATAだったってこと。orz
まあ、箱買えば、いいか。

カード装着は問題なし。
買ったのは、玄人志向のSATAEI-LPPCI。
玄人志向 インターフェースボード SerialATAII eSATA PCI LowProfile対応 SATAEI-LPPCI
無事にUbuntuでも認識。
sata_silだったかな、のドライバで認識はしたんですが。

これ、SATAなのね。(^^;
SATA−IIのAHCIを使いたかったんだけど、まあ、買ったものは仕方ない。

ということで、内部1ポートだしってことで、ここにDVDドライブを接続。
試してみたら、無事にブートメニューからブートも出来るし、そういう点では問題ない。
で、空いた内部ポートをリムーバブルケースの方につないで、どうにかSSDは内蔵可能に。

まあ、外見はすっきりしました。
ちと、内部の接触不良気味なところが気にならないではないんですがー>リムーバブルケース

これは、このカードとは別の問題なので。
リムーバブルケースも買い直した方がいいかも知れんね、そのうち。
なんか不調なときがあるから。

このリムーバブルケースで、Windows起動とかしてるんで、使えないとすごく困る。
バックアップ用のベアドライブもここに入れてバックアップ取ってるし。

SATAカードのドライブ認識に2秒ほど掛かってるようで、若干遅いは遅いんだけど、まあ、仕方ない。この辺はガマンするしかないねー。

ってことで。

ああ、るびきちさんにも報告しとかないとな。

| | コメント (0) | トラックバック (0)

UbuntuでLVMとかiSCSIとか。

Twitterの方で、ちと話題になりまして。
そんな上手く行かないものなのかー、と思って試してみました。

ちなみに、LVMを構築する環境はVirtualBox上のUbuntu10.10β。
接続するクライアントは実機のUbuntu10.04です。

まあ、実機にはLVM作れるような環境がないので、仮想環境側にLVMを作成し、実機からiSCSIで接続してみる、という手順で。
まずか仮想環境の方にディスクを2台追加しました。
これは、まあVirtualBoxの機能で簡単に出来ます。お試しなので、10GBx2で。

んで、以下のコマンドでLVM用のGUIをインストール。

$ sudo apt-get install system-config-lvm

これで、LVM関係のコマンドも道連れで入ってくれると思いますが、入らないようなら、追加で以下のパッケージもインストール。
<span style="color: rgb(0, 0, 255);">$ sudo aptitude install lvm2<br /></span>

※ワタクシはaptitudeを追加インストールしているので、してない方はapt-getを使用してください。
ただ、依存関係に入ってるので、OKかと。
初期化されてないエンティティから、LVMに追加したいデバイスを選択し、エンティティを初期化していきます。
その後、ボリュームグループを作成し、2台のドライブをボリュームグループとして登録します。
GUIだと結構直感的に操作可能です。
で、最終的に論理ボリュームを作成するのですが、その際、フォーマットも選択できるので、とりあえずext4でフォーマットしてしまいました。

これで、LVMは作成完了。
簡単です。

次に、iSCSIの設定に入ります。
参考にしたサイトはこちら
いつもの技評サイトです。
が、どうも10.10から変わったのか、設定ファイルの位置とか変わってます。
とりあえず、パッケージをインストール。
>$ sudo aptitude install iscsitarget<br />

んで、geditで設定ファイルを編集するのですが、技評サイトとは場所が異なります。
>$ sudo gedit /etc/iet/ietd.conf <br />

として、設定ファイルを開き、LVMをiSCSIデバイスとして登録します。
ワタクシの場合は以下の設定をファイルの最後に追加しました。
<br />Target iqn.2010-09.kaoru-desktop:Merveric32.disk <br />       Lun 0 Path=/dev/dm-0,Type=blockio<br />

命名規約があるそうなので、そこは技評サイトを参照してください。
さらに。
>$ sudo gedit /etc/default/iscsitarget<br />

として、ISCSITARGET_ENABLE=trueと変更します。
こうしないと、サービスが起動しないので。(^^;

で、ここまで来たら、サービスを起動するだけです。
>$sudo service iscsitarget restart<br />


これで、ターゲット側は設定完了。

次にクライアント側になります。
>$ sudo aptitude install open-iscsi<br />

として、イニシエータ側をインストール。

で、このコマンドでターゲットを認識しているか確認。
>$ sudo iscsiadm -m discovery -t st -p 192.168.1.10<br />
IPアドレスは自分の環境に合わせましょう。はい。
確認できたらデバイスノードをチェック。
>$ sudo iscsiadm -m node<br />

チェックできたら接続です。
>$ sudo iscsiadm -m node --targetname "iqn.2010.09.kaoru-desktop:Merveric32.disk" --portal "192.168.1.10:3260" --login<br />

これで、/dev/sdx(xは任意の数字)にターゲットのiSCSIデバイスが見えるようになるので、あとは適当な場所にマウントすればOK。
用途にも依るでしょうが、必要であれば起動時にマウントするようにしておけばいいかも知れませんね。

本格運用は、自宅サーバ導入後になりそうですが、これ、毎度接続とか必要だと面倒だよなー、とか思ってしまいました。
性能出るからいいのかな?

まあ、その辺の話は本格運用を試みてから、ってことで。
まずはこの手順でうまく行きました、ってところですかね。

注意が必要なのは、ターゲットと同じマシンで、イニシエータも接続しようとすると、どうも見当たらない、ってことになるような気配。
ちと検証不足気味なんですが…。

お試しするなら仮想環境2台とかでもいいかも知れませんが、ターゲットとイニシエータは分けた方が簡単みたいですな。

| | コメント (3) | トラックバック (0)

んなことたぁねーよ。

【総論】 仕事の達人は「近道」を知っている:即効1秒!キー操作術

仕事ができる人のパソコン操作を見ていると、共通の特徴があることに気付く。キーボードから手を離さずに操作しているのだ。

 これを実現しているのが「ショートカットキー」。実は、WindowsやExcelなどで日ごろ実行しているさまざまな操作は、特定のキー操作に割り当てられている。そのキーの組み合わせを押すことで、マウスだと手数の掛かる操作を一瞬で実行することができる。


初心者向け記事に難癖付けるのも如何なものか、とも思いますが。(^^;

マウスから手を話さずにキーボード併用で仕事をこなす達人もいますし。
キーボードから手を離さずに仕事をこなせれば、確かに速いのは認めますが、それ以上に「仕事の達人」は作業をルーチン化しているから速いのです。

ショートカットキーを覚えたから、仕事が速くなるわけではありません。
マウス併用操作で、すべてのウィンドウを最小化して、デスクトップを表示するのに5秒掛かったとします。
ショートカットキーを使えば1秒です。
で、ここに4秒の差があります。
10回積み重なれば、40秒の差です。100回なら400秒、約6分になります。
#100回やるかどうかはさておき。
6分の差というのは、大きいと見るか、小さいと見るか。

単純に作業しかしてない、思考時間0なら、この差は大きいでしょうね。
例えばウィンドウ切り替えにも同様の差があるとするなら、複数のアプリケーション切り替えで、発生するタイムラグは、最終的には致命的な差となって現れる可能性はあるでしょう。
ただ、100回やって5分の差というのは、一回の休憩で詰まる差に過ぎないのも事実です。

例えば高速道路での移動なんかがそうですが、150Km/hで移動するのと、100Km/hで移動するのでは、1.5倍の差があります。
#すでに速度違反なのは、さておき。
しかしながら、高速道路の移動に慣れていない場合、150Km/hで移動する場合、かなりの神経を使います。
追い越しが頻繁に発生し、その分回りへの注意も必要になり、「疲れる」のです。
そして、その疲れた分、SAなどによって、15分休憩してしまうと、その差はなくなってしまいます。
他の車の動きを想像出来る運転の達人ならば、疲れることもなく、150Km/hで移動できることでしょう。これならば、間違いなく、1.5倍速いと言えます。

仕事の達人は、それらの操作が速いのではなく、「考える時間」が短いから、仕事が速いだけです。
例えば、マウス操作を併用しているひとでも、その操作中には、操作のことを考えているわけではなく、作業の手順や次にやるべきことを考えています。
手を動かすことも含めて、作業をルーチン化し、思考時間を短くすることで効率を上げているのです。

キーボードから手を離さないから作業効率が上がる、なんてのは都市伝説です。(笑)
むしろ、達人の考え方を学ばねば、作業効率など上がりませんし、形だけ達人の真似をしても、単に無駄にウィンドウが速く隠れるだけで、結局は頭の中では作業の内容が未整理のままで、次の作業に入れないのが実情でしょう。

作業を効率よく進めるために必要なのは、間違いなく「無駄な思考時間を省くこと」です。
無駄な操作を省くこと、じゃありません。
よく勘違いされてるみたいですが。

PCの一操作にショートカットキーを使おうが、マウス操作を併用しようが、分単位で掛かることなど滅多にありません。
#アプリが遅くて時間が掛かるなら、ショートカットキーでもマウス併用でも同じです。

仕事の達人になりたいのなら、作業を整理して、作業そのものを、どのように行えば効率がよくなるのか、順番を含めて考えてみることをお勧めします。
ショートカットキーによるキー操作など、一手段に過ぎません。それを覚えたから作業が効率的になるわけではありません。
むしろ些細な問題です。
新たに覚えようとして、結局慣れない操作に戸惑う時間で無駄にするより、慣れ親しんだマウス併用の操作が速い場合もあります。

あともうひとつ。
無駄な作業を省くこと。これは無駄な思考時間を省くことにもつながりますが。
一連の作業の流れを整理すること、見直しをするこで、自分のルーチンワークを作り上げ、作業全体の効率を見直すことで、操作の見直しなんかよりも遥かに効率的に作業を行うことが出来るようになります。
操作が速い、なんてのは瑣末な問題に過ぎません。

ま、キーボード操作のみで操作している方が「達人に見える」ので、そういう見栄を張りたいなら、それもアリでしょうし、「こんなこともできるんだぜ?」と同僚に自慢するネタに使えるので、覚えるのがダメだ、なんてことはありませんが、「操作が速いから、作業の効率が良くなる」のは嘘です。
そこだけは、はっきり言っておきます。

作業を整理して、全体の効率を見直し、考えることなく作業を進められるようにすることこそが、達人の業であり、もっとも作業効率が高いやり方になるのです。

そこを無視して、操作だけ速くても無意味なんですよね。
こういう記事は、その辺の視点を抜かして、操作だけ紹介してるら意味ないと思うんですが。
どんなもんでしょうかね。

| | コメント (4) | トラックバック (0)

KDEなんでスルーしようと思ったんですが、感想だけ。(笑)

「KDE 4.5」をデスクトップとして選択する10の理由 - IT業界を生き抜く秘密10箇条 - ZDNet Japan

最新バージョンであるKDE 4.5のリリースに至るまで、KDEはユーザーフレンドリーかつ、最も優れた設計のデスクトップを目指して着々と歩を進めていたのだった。そんなことは信じられないという方も、デスクトップとしてKDE 4.5を選択すべき以下の理由に目を通してもらいたい。

KDEそのものは、触ったことがないなら、一度は触った方がいいと思ってるDEであるのは間違いないです。
不安定さから、嫌われていたり、昔からLinux使ってたひとにはQtのライセンスで嫌われていたり、という時代背景もありますが、Qtのライセンスは解決しているはずだし、巷の噂を聞く限りでは4.5は安定しているらしいので。

まあ、このヒトの記事なので、100%鵜呑みには出来ないんですが、以前に触ったことのある印象、および、Twitterなどで聞く評判とかけ離れてないので、本当によいリリースになっているのであろう、と思います。

ワタクシ自身はGNOME派なので、KDEを常用することはないのですが、それでもDVDライターにはK3bを使ってますし、K9Copyも愛用しています。
ツールそのものは、KDEのツールは、使いやすいのです。

それというのも、KDEの思想なのだと思うのですが、操作ガイドが徹底していて、GUIにツールチップによるヘルプは必ず付いてますし、アニメーションカーソルによる直感的な操作ガイド、Prismoidの柔軟性など、ユーザビリティに関しては、明らかにGNOMEより上だとワタクシは考えております。

ウィンドウのタイリングなどは、GNOMEのWMにはない機能ですし、Windowsでは当たり前に使える機能なので、ちょっとしたUIのカスタマイズで、Windowsからの移行組には、KDEの方がとっつきやすいかも知れません。

まあ、ワタクシはGNOME派なので使いませんが。

ただ、これだけ持ち上げられているということは、たぶん、本当に安定性は上がったんだと思われます。

これまで一度もKDEを使ったことのない方は、10.10辺りをめどに、一度触ってみることをお勧めします。
案外、GNOMEでの不満が一気に解消される可能性もありますし、LinuxというOSの柔軟性に改めて驚くことになると思います。
ここまでUIが激変しても、同じLinuxなのか、と。(笑)

また、Linuxの不満だと思っていたことが実はDEであるGNOMEへの不満だった、とかの可能性もありますしね。

正直、GNOMEは、それほど親切なDEではありません。(^^;

Ubuntuでも、ちょっと使いにくいなー、と思ってる方は、本当に一度KDEを試してみるとよいと思いますよ。

| | コメント (0) | トラックバック (0)

iPhoneのATOK導入

ATOK padというiPhoneアプリを購入。
初回特典で割引されていたので。
変換効率は、さすがATOKと言っていい。
ただIMとしての提供ではなく、アプリとして提供されているのは、おそらくiPhone側の仕様が公開されてないなどの事情があるためと思われる。
標準のIMとしてATOKが使えるならば、iPhone使用時のストレスは大幅に改善されるとワタクシは考えるし、ある程度の長文入力も苦にならないのではないか、とも考える。
#ちなみにワタクシは、元々はアンチATOKである。
そのくらい、この手のデバイスや、PCを使用する際の日本語入力というのは重要とワタクシは考えているのだが、やはりiPhone標準はあまりに酷い。
現状、iPadには未対応とのことだが、iPadユーザーならば、早めの対応を期待したいところではなかろうか?
なおAndroid端末への対応も進んでいるようなので、Androidユーザーは期待して待つと良かろうと思われる。
まあ、Linuxでももずくが、だいぶ改善してくれたとはいえ、まだまだ感は否めない。
ジャストシステムには、今後も幅広い対応を期待したいところだ。

| | コメント (0) | トラックバック (0)

Ubuntuの環境再構築時のメモ

なんか、ちらっとTwitterで話題になったので、メモ。

ワタクシは、基本的にバックアップはSBackupで取っております。
まあ、週一でフルバックアップなんですけど。
で、環境再構築の時には、これは使いません。(笑)

手動でやることが多いんですが。
前提として、/と/homeは別パーティションになってること、というのがあります。

手順的には、以下の感じ。

  1. /etc/apt/sources.list.dをバックアップというか、別の場所にコピー(/home/user名とか。)
  2. /etcを別の場所にコピー
  3. /usr/sharを別の場所にコピー
  4. Synapticなどで現在インストールされているパッケージの一覧を出力(SBackup使ってるなら、そこに同じものが出てるけど)
  5. OSインストール
  6. OSのアップデート
  7. プロプラドライバインストール
  8. /etc/apt/sources.list.dをレストア
  9. パッケージの一覧を読み込んで、インストールパッケージの復帰
  10. meldで/etcの差分を取り込み(fstabとgrub.cfgには注意)
  11. meldで/shareの差分を取り込み(主にscreenlets)
  12. update-grub
  13. リブート

こんな感じ。
meldによる手作業が結構時間掛かるので、まあ全部やって3時間くらいですかね。
場合によっては、綺麗さっぱり新規に構築って場合もありますけど。
例えば、ドライブを交換した場合とか、こんな感じになります。

今はブート可能なパーティションが二つあるので、片方が/のバックアップみたいになってますけど。
まあ、10.10へ向けてSSDを起動ドライブに変更したので、そうなってますが。(笑)

普段は上記手順で再構築してますかね。
特に起動しなくなる、fstab、grub回りは一行ずつ目視確認です。(爆)

ま、こんなやり方もあるよ、ってことで、メモ。

| | コメント (4) | トラックバック (0)

直るもんなんだ、ドット抜け。

いきなり現れた、液晶モニターのドット抜けが、直った件について - Sickly Life はてな版

突然PLB2409HDS-B1の画面中央やや右上辺りに、シミのようなものが現れたので、何なんだと観察してみたらドットが白くなっていた\(^o^)/。

液晶のドット抜けは、もはや致命傷で仕方のないもんだと思ってたけど、直るもんなんだねぇ。
まあ、直らない場合も多かろうとは思うけど。
同じような症状がでたら、試してみよう。

| | コメント (4) | トラックバック (0)

アピールはしてもいいと思うんだけどね。

HOW to 就職 実はやってはいけないアピール | nanapi[ナナピ]

アピールしてはいけないこと

してはいけないところは複数あります。以下にご紹介します。
その1 「専門学校行きました。」

よく勘違いされるんですが、専門学校や何かしらのスクーリングというのはあまり評価されない傾向、業界によっては悪評価になる時があります。

というのも、専門知識があるということで鼻にかけがちな学生が案外多いんです。

もう一つ付け加えれば、実は専門学校の知識が現場では無用の知識が多いんです。専門知識を持っているよりも、はじめから叩き込む方が使いやすい社員になると考えられています。


Twitterから拾ってきたネタ。(笑)

まあ、就職は困難な時代になってるってのは、転職も困難なので、よく解るんですが。
#もっと給料のいいところに移りたい…。

ITの中小企業を対象なら、即戦力に近いレベルが求められてる場合が多いので、この辺はアピールポイントにはなると思うんですがね。
ただ、「鼻にかける」のは、よろしくない、と。(笑)

以前にTwitterでポストしたことがあるんですが、中途半端な知識は、会社に入ってからの業務には、まるで役に立たないことも多いのも事実で、まあ、「ほどほどに」アピールすること、柔軟な対応が可能であること、も合わせてアピールして置けばOKかと。

ただまあ、学校で教えてくれるような基礎知識が、まるで役に立たない業務なんかもあるわけで、そういう会社の場合には、逆効果ってのは確かにあるようで。
それと、ひとによって、だとは思うんですが、そういう「専門知識を持った新人」を扱いにくい、と感じるひともいるようです。

まあ、これ、結局は「今時の若いものは」って話(笑)なので、年寄りのヤッカミと思ってもいいとは思うんですが、本当に技術に自信があるならば、どんどんアピールした方が、IT業界の場合にはいいような気がします。
本当の大手は、そこはどうせ見ないので。(^^;
#あって当然と思ってるフシがある。

一方で、注意すべきは入社してからの方で、「技術を鼻にかけてる」と疎ましがられる傾向があるのは事実です。
そういう部分は「さりげなく」アピールするか、「業務の実績」として出した方がよい結果、つまり上司ウケがよいと思われます。(笑)

ま、ここまでは、元ネタからの解釈の話で。

結構、ワタクシは新人教育が好きなんですよ。
というのも、まあ、新しもの好きってのもあるんですが、やはり、新しい若い感性に触れるというのは、自分にとっても刺激になるし、まあ、面白いわけです。
また、そういう新人に対して指導や、教育を行うこと、つまり整理して教えることで、自分の中で曖昧だったことが、きちんと整理されることも多く、「これってどういうことですか?」に対しての回答を行っていくうちに、未整理だったものが整理されていくんですね。
これは、自分にとっても、大きなメリットで、整理されるということは、以後、効率よくその情報を使えるということにもつながるのです。
新人教育というと、自分の時間を喰われることも多いのですが、それ以上のメリットもある、ということを、教える立場になったときには意識してみるといいかも知れませんよ、という話で。

新人がかわいい女の子だったら、教える方にも張り合いが出るしね。(笑)

| | コメント (0) | トラックバック (0)

GUIでGUIGUI。

おっさんでも解るPython、略しておっPyは、一部で盛り上がりを…見せておりませんが。(笑)

これは、GUIを主体に初学者に対して、プログラミングの敷居を下げるために書いてるものです。
なので、別にPythonじゃなくてもいいんじゃ、とかいうところもあるのですが、ワタクシの使ってるのが最近Pythonなので、Pythonを選択しているだけで、言語入門的な側面はあまり持ってません。
で、先日tminさんを実験台(笑)に、解り難かったところ、追記した方がよい部分、サンプルコードの間違いなどを修正したんですが。

まあ、それは余談というか、つかみの話で。

最近のひとはGUIプログラミングをしたがる、とかGUIに興味がないとか、まあ、様々な意見があるようで。
まあ、そもそもLinuxの場合には、端末が多機能なので、CLIで困らないことも多いんですが、これがWindowsとなると寂しい限りで、お世辞にも「シェル」と呼べるほどの機能は…、ってのが現実です。
なので、必然的にGUIプログラミングになるんですが。

一方で、Linuxでも、最近のDEはGUIが強力になりつつあり、まずGUIを備えてないアプリケーションは見ません。
#ツールレベルなら多数あるし、伝統的なコマンドも、もちろん残ってますけど。

MacはもとよりGUIで使うことを前提としていますし、伝統的なUnixくらいでしょうか、CLI主体というか、SSHで入ってコマンド叩く、なんてのは。
つまりサーバ管理者とか、そういうある意味特殊技能が必要とされるひと以外は、CLIを使えなくても困ることがなくなってきているのが現実ではないか、と。

んじゃ、CLIが不要か、というと、そんなこともなく、やはり伝統的なコマンドが便利な場面も多数あり、シェルスクリプトとか書けると、驚くほど作業が効率的になったりすることもあります。
例えばルーチンワークで、メールを一括でダウンロードして、フォルダに振り分けて、とか、そんな作業とかですか。
#あくまで例えば、で、今更そんなことしてるひといないと思いますけど。
まあ、使い分けってところなんですが。

とはいえ。
CLIの使いにくさ、シェルスクリプトの敷居の高さは言うまでもなく、自動処理ってのは、ある意味危険性を秘めてもいるわけで。
手作業で行う効率の悪さは、もちろんありますが、「手作業で行う」ことによる「目視確認」の安全性ってのも、間違いなくあります。
シェルスクリプトと言っても、自分で、てきとーに書いたものには、バグが潜んでいる可能性も大いにありますし、それが削除系のものであるならば、場合によっては、取り返しのつかないミスを誘発する場合もあるわけです。
#そんな時のためのバックアップ、ともいいますが。

ま、ルーチンワークの大多数は、それほど重要なものでもないのでしょうから、そこはシェルで自動化、ってのが効率がいいのかも知れませんが。
それでも、工場などの現場では安全性の確保の為に、指差し確認なども行われてるわけで、重要な作業であればあるほど、手作業による「面倒な確認」が重視されることも多いわけです。
#どうしても最後は「人間が保証する」「安全性を担保する」「責任を取る」ことになるわけで。

そんな場合に「使いやすいGUI」の提供は、安全性と効率の両面に於いて役に立つんですが、まあ、なかなかそんなのもないのが実情で。
ないなら、作ればいいじゃん、ってのも、そう簡単には行かないし、ってところが痛し痒し、ってところなんですよね。

おっPyの目的のひとつでもある、初学者へのプログラミングへの誘いってのは、まあ、こんな場合にも役に立つでしょう、という思いもあり。
まあ、元々もは冗談から始まってるわけですが。(笑)

んで。
最後に本音を書いときますけど。
GUIに興味がないひとは、使いやすいGUIは作れません。
自分で使う気がないものを、相手のことを考えて、使い易くしようってのは無理なんです。
まず、自分が使い易いものは何か、それをキチンと考えた上で、相手の意見も取り入れる、じゃないと、使い勝手が問題になったときに、自分で解決出来ません。
人間工学に基づいた、なんて立派な口上を述べるつもりはないんですが。
そういうのをキチンと学んで、最初からデザインをするのがベストなのかも知れませんが、まあ、大抵の場合は、プログラムの設計者が、そのままGUIの設計をしたりすることが多いわけで、その場合に、「じゃあ使いやすいGUIって何よ」は意識されてないと、とんでもないGUIが出来上がります。
#現実に色々と見てきてたりするわけですが。(笑)

目的によって、GUIデザインなんてのは大きく変わります。
その目的をきちんと捉えて、ある程度の動線を押さえて、そのユーザーの考えの流れに沿ったパーツの配置ってのがあるんです。
GUIに興味のない人には、これは出来ません。
もちろん、見栄えも問題になります。
重要な入力項目には注意書きが書いてあったり、入力例を示したりするのも、GUIならではの工夫でしょう。
自分で使わないひとには、それらの注意を払うことは出来ないんです。
#KDEのGUIが、こういう観点ではよく出来ています。GNOMEの負け。(笑)

興味のないものは、うまく作れません。
ま、なんでも同じですけどね。料理に興味がなければ、美味しい料理を作りたいとも思わないでしょうし、作れないでしょう。

まあ、趣味でプログラミングしてるひとは、あんまし気にしなくてもいい領域かも知れませんが、職業としてプログラミングをするひとなら、GUIは、おそらく避けて通れない時代になって来ていると思われるので、GUIに興味がないなら、その道を目指さないか、ちょっと無理してでも興味を持つようにした方がいいんじゃないのかな、とワタクシは思ってますが。
これ、単なるクライアントアプリだけではなくWebデザインなんかでも同じなんですよね。
見やすさ、使いやすさってのは、工業デザイン全般に言えるので。
「いやぁ、自分GUI苦手なんで」ってひとには、そういう仕事は必然的に回ってこなくなるので、まあ、それを貫き通す、という手もありますけどね。(笑)

| | コメント (0) | トラックバック (0)

AIRを入れてみた。

以前にうまく行かなかったのに、今回はなぜかすんなり。
Adobeのサイトから、AIRのbinをダウンロードしてきて、実行属性つけて、sudoで実行。


chmod +x AdobeAIRInstaller.bin
sudo ./AdobeAIRInstaller.bin

こんだけで、インストール出来ます。
以前はいろいろ手続きが必要だったみたいですが、10.04だと、こんだけみたいですね。
逆に色々やると問題あるっぽい。

で、はがきデザインキットをインストールして、以前に日本語入力できなかったのが、可能になったのか試してみました。
もずくで無事に入力できるようになってましたな。

やはり、変に32bitライブラリ導入とかに問題があったようで。
この辺、色々と改善がなされているようなので、次のバージョンでも問題ないことを祈りたいもんです。(笑)

| | コメント (0) | トラックバック (0)

オチの部分だけ引用。(笑)

Island Life - 手段としてのプロ

したがって、「いつでも確実に要求水準をクリアする」というプロ意識と、 「持てる力の全てを注ぎ込んで最高のものをつくる」という一種のアマ意識は 同居し得るものだと思う。仕事で受けた場合は前者を優先せざるを得ない だろうけれど (だから、余暇に自分のつくりたいものをつくるという ニコ動でいう「プロの犯行」が出てくるわけだ)。

プロを手段として選択した人は、 いつか、自分のつくりたいものに全てを賭けられる機会にめぐり逢えると思って やっているんだと思う。 そういう「個人の本気」が、新しい地平を開いてゆくのだろう。

けれども、業界そのものを成り立たせている「しくみ」の部分は 「頼まれた水準をきちんとクリアする」という 割り切ったプロ意識で支えられているわけで。それが崩れると 新しい地平にジャンプしようとしても土台が無くなっちゃう。 どっちが本質、というものではなく、両方見ながらやってかなくちゃね、ってことだな。


なんかネタにしようと思って忘れてた。(笑)

まあ、善し悪しは別として、結構プロなひとって全力で仕事してないような気はするんですよね。
まあ、新人とか別だけど。
#全力じゃないとついてこれないから。

何のために、仕事してますか、って問われれば、色んな答えがあるんじゃないかと思うんですが、まずは「生活のため」ですかね。
で、その生活のために何をしなければならないか、ってぇと「継続する」ことが重要なわけで。
まあ、サラリーマンでもフリーランスでも、一定以上の水準の仕事をこなしてないと、干されるわけですね。(笑)

その「一定以上の水準」ってのが、クセモノだったりするんですが。
まあ、ワタクシの業界なんかだと、それなりにユーザーも解ってるので、そんな無理な要求はなかったりしますが、少しは無茶なものも来る。
で、その場合でも「一定以上の水準」は維持されなければならないんですよ。

それに、いろんな突発的なことが起こります。
事故だったり、設計のミスだったり、病気だったり。
そんな場合でも、「一定以上の水準」は越えてないとならないんですよね。

なので、必ず、どこかに余力を持つ、ってのがプロの条件のひとつでもあるのかな、と思ってるんですが。
なんかあったら、その余力の部分でカバーする、と。

一方で、毎日全力で仕事してたら、遊ぶ気力すらなくなるので、そんなの「生活のため」の仕事じゃないよな、とも思うわけで。
「仕事のための仕事」じゃないか、と。
余暇も余力も大事だし、まあ、仕事そのものを楽しむのも大事だけど、こう、時々は、なんでこの仕事してるんだっけ、とか考えて、改めてプロの仕事ってどんなんだっけ、って考えることも必要だよな、なんて、元記事を見て思ったりしました。

まあ、いみじくもプロを名乗るなら、「出来ません」は言えないし、「間に合いませんでした」はもっと有り得ない。
約束は絶対だし、守れない約束をしたら、もうプロじゃないよね、と思うわけで。

ま、元記事でもオチとして言ってますが、プロなら、割り切った意識で、仕事は仕事、趣味は趣味とするのがいいような気はしますがね。

むしろ、全力叩き込むのは趣味の方だよねー、なんて、ワタクシは思いますがね。(笑)

| | コメント (4) | トラックバック (0)

カーネル野良ビルドには要注意。(笑)

先日ハマったので、メモ。
まずはbuild-essentialのインストールは当然として、以下のパッケージも必要。


libncurses5-dev
libqt3-mt-dev

これがないと、xconfigが動かない。
次に、既存のカーネルをビルドし直しなら問題がないんだけど、新規に作成する場合には、initrd.imgがないので、新規に作成しないとならない。
ので、以下のコマンドをカーネルビルド後に実行する。

sudo update-initramfs -c -k カーネルバージョン

最初ブートしなくて焦った。(^^;

ついでに、grub復旧の手順


sudo mount /dev/sdxy /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /sys /mnt/sys
sudo mount --bind /proc /mnt/proc
sudo chroot /mnt
sudo update-grub
(または)sudo grub-install /dev/sdx

※xはsdaなどのドライブyはパーティション番号

これで一時間程度ロスしたな。(^^;

またありそうな話なので、一応記録として。

| | コメント (0) | トラックバック (0)

さて、今回の道場は?

ASCII.jp:~師範、Ubuntu10.10の特徴を教えてください!~|行っとけ! Ubuntu道場!

hito:10.10、ひとことで特徴を言うと「10.04改」という感じですねぇ。

小林:ブラッシュアップ版、という傾向は強いですね。

あわしろいくや:LTS後って、結局出てくるものはそんな感じですよねぇ。8.10とかもそうでしたし。


まあ、テーマも10.10だったし、それほどツッコミどころはありませんでしたが。
逆に言えば、見所もない、という気もします。

この道場では引用した部分がすべて、な気がしますね。
10.10は10.04改に過ぎない、と。
まあ、ある意味、11.04が、かなり大幅な変更が入りそうなので、その前の下拵え的リリースになりそうな気配がひしひしと伝わってきます。

とはいえ、10.04がかなり安定したリリースであったこともあり、それをリファインしただけでも、充分な出来になるでしょうし、辺に新機能を無理矢理詰め込まれるよりも、安心してアップグレード出来るかな、と思わないでもないです。

まあ、目玉のbtrfsは、本格導入は11.04まで持ち越しのようですし、これがきちんと導入されれば、アップデート時におかしくなった場合の、「復元」まで対応予定ってんですから、これは期待が高まります。

とはいえ。

なんか、道場見てると、すげー他人事モードに見えんですけど。
あんたら当事者じゃなかったっけ?みたいな。

まあ、実際には日本語Remixも始まっているので、今頃は当事者モード全開でヒーヒーいいながらやってるのかも知れませんが。
LTS後の新リリースなんだから、もう少し、この辺が変わったよ、変わる予定だよ、を熱く語ってくれてもいいとは思うんですが、そこまで何も語ることのないリリースなんですかね、もしかして。(笑)

まあ、仮想環境にベータを入れてみましたが、実際に、細々とした見た目が変わってる印象しかないので、案外そんなところなのかも知れません。

ま、実際に、モノが出てくるまではなんとも言えませんがー。(笑)
今回は、結構見送るひとが出てくるかも知れませんねぇ。
そのくらい10.04は安定してるもんな。

| | コメント (4) | トラックバック (0)

Ubuntu10.10へ向けて環境をバックアップ

ついでに。
余ってたというか、遊んでいたSSDをメインの起動ドライブにするべく、そちらに10.04をクリーンインストール。
最近、色々とインストールして遊んでたんで、まあ、ついでに、って感じで。
まあ、まずは使わんのでAIRも外してしまいました。

ってことで、今まで約3時間ほど掛けて、現在の環境をSSDに移行しました。
まあ、TV関係とか、細々した設定がなければ、一時間程度で環境の再セットアップなんて終わるんですが、システム関係でちと変更しているのがあるので。
#TVカードとか、ファンコントロールとか。

その他、いくつか設定やらファイルコピーやらを手動でやってたので時間が掛かりましたが、インストールそのものは、やはりUbuntu、速いですねー。

んで、久しぶりのSSD。
やっぱり、読み出しは速い。
起動とか含めて、アプリの起動も速くなるので、Linuxなら、起動ドライブにSSDはお勧めかも知れません。

ただ、あんまし安価なSSDや容量の小さなものだと、結構速度が出てないので、64GBで一万円程度のモノなら、そこそこ速さは感じ取れるんじゃないでしょうかね。
最近は安くなったよなぁ、SSDも。

転送レートで200MB/sくらい出てれば、HDDよりも圧倒的に速いので、間違いなく体感出来ると思います。

ま、これでブートパーティションが二つ用意できたので、10/10のリリース時に、あるいはRC提供時にアップグレード掛けて、最悪の事態になっても乗り切れます。(笑)

| | コメント (0) | トラックバック (0)

Flashプラグインの64bit版が更新されたらしい。

Adobe Labs - Downloads: Flash Player "Square" Preview Release

#
# dlDownload plug-in for 64-bit Linux (TAR.GZ, 4.1 MB)

Adobeはamd64を見捨ててなかった。(笑)

後で試してみよう。

| | コメント (0) | トラックバック (0)

奇妙な夢を見た。

得てして「夢」というものは奇妙なものだが、妙にはっきり覚えている。
夢の中でワタクシは20代前半の若者であり、小学生の「自称恋人」がいるようであった。
部屋は木造アパートで、畳敷き、しかも部屋にはPCがない。
#リアルなワタクシでは絶対にありえない。

その自称恋人が、部屋に遊びに来て、妙に艶かしく迫るものだから、ワタクシは辟易して部屋から逃げ出し、外出するのだ。
外は明るく、適度に風があり、夏のようではあるが、さほど不快な感じではなかった。近くに河原があり、そちらの方に向かって、ワタクシは歩いて行く。

その後、なんかあったようだが、そこは覚えていない。
どうも、一大冒険があったような気がするのだが。

その帰り道、河を渡る大きな橋があり、歩道を歩いていると、そのまま部屋に帰る道には戻れず、河原に降りるようになっている。
車道を歩けば、部屋へ帰る道に行けるが、さすがに大きな橋であり、車の交通量を考えると、とても車道を歩く気にはならず、その上、ご老人が自転車に乗って、その行こうと思う先からよろよろとやってくる。
危険この上ないな、と思いながら、ワタクシは河原へ降りる階段へと向かった。

古びたコンクリートの階段には、やはり錆びついた手すりがついており、その橋が作られた年代を感じさせる。バリアフリーなどと叫ばれてた時代に作られた代物ではありえない。

コンクリートの階段を降り切ると、そのまま、両脇に杭の打たれた、未舗装の遊歩道につながっており、そこだけはひとが頻繁に行き来するのか、草が生えていない。
しかし、その遊歩道の行き先を見てみると、河の中を突っ切って、向こう岸に続いている。
さて、この遊歩道は、なんのために、このような作りになっているのか、ワタクシは疑問に思いつつ、途中まではその遊歩道を歩いて行った。
そのまま、もしかしたら、この遊歩道は河川上を歩けるのではないか、という妙な期待を持ちつつも、まあありえないな、とその遊歩道を作ったひとのセンスを疑いつつ、遊歩道を外れ、部屋へ帰る方向に足を向ける。

短い下草のある河川敷を歩いて行くと、大きな広場になっているのか、遊んでいる子供の姿も見える。
まあ、最近は公園で遊ぶ子供の姿も見なくなったと聞くが、案外いるものだな、と思いつつよそ見をしながら歩いていたら、大阪の食い倒れ人形そっくりの人形のようなモノに激突された。
ワタクシからぶつかったのではなく、向こうから激突されたのだ。
胸には、「自走式ロボット」と書いてある。
え?と思って、よく見てみると、どうも段ボール製らしい。その隙間から、一輪車にまたがった子供の姿が見えた。
つまり、自走式とかいいつつ、単に一輪車に載った子供が被ってロボットのふりをする、というそういうおもちゃというか、工作のようだった。
その子供の父親らしきひとが、しきりに笑顔で頭を下げながら、こちらに近づいてきた。
ワタクシは軽く会釈をしながら、その場を立ち去る。
妙な工作もあったものだな、とは思ったが、きっと子供と父親と一生懸命に作ったのだろうな、と微笑ましい思いをしながら。

そして、河原から上がる階段の側まで来たところ、見覚えのないトンネルを見つけた。
#夢の中で見覚えのない、もないものだが。
まだ陽も高く、急いで部屋へ帰る必要もないワタクシは、奇妙な冒険心とともに、そのトンネルにはいることにした。
トンネルの中は、上に蛍光灯がぽちぽちとついており、歩くに困るほどではないが、さすがに夏の陽の下から入ったものだから、目が慣れるまで、しばらく掛かった。
そして、意外に長いトンネルを歩いて行くと、唐突に行き止まりになる。
その行き止まりは、どうやら、橋の根元付近のようで、天井がなく、明るい日差しが差し込んでいた。

そこで、ワタクシは、その行き止まりの左脇に扉があることを発見する。
木製の重厚な扉には、「懐古堂」だか「珍奇堂」とか言った表札とでも言うべきものが張ってあった。

何かの店なのだろうか、とワタクシは、扉を開けて中に入る。
その店内には、博物館でよく見られるような引き出しが大量についたラックのようなもの(引き出すと展示物が見られるようなもの)が両脇に並んでいて、通路と呼べそうな部分は、ひとひとりがやっとと思われるような作りになっている。
はて、勝手に引き出しを開けて中を見てもいいものか、測りかねているワタクシの前に、奥から、巨体のイタリア人がやってきた。
そのイタリア人は、右手に棒から下げられたメニューのようなもの、まあ、言ってしまえば、掛け軸にお品書が書いてあるようなモノを持っていて、ワタクシの前に突き出す。
どうも日本語を理解しないらしく、まともに店番も出来ないので、それで対応をするもののようだ。
その掛け軸の一番上には「特価セール中!」の文字が見える。
それで、ワタクシは、ここが何らかのお店であることを確信する。

そのメニューを見てみると、先程の「自走式ロボット」も並んでおり、ああ、あの親子はここでアレを買ったのだな、と納得する。
他にも奇妙なアイテムが並んでいるが、どれもワタクシには不要なものばかりだった。
ひとつだけ、気になったのが、歴代ファイナルファンタジーのセーブデータを販売しており、その中で、FF7か8の、ヒロインのエッチなシーンが見れるセーブデータというのがあった。
注意書きとして、そのシーンを見た後にプレイを続けると、主人公がひどいことになる、的なことが書かれている。

興味は惹かれたが、別段買うものはないので、そのまま、店を出た。

木製の重厚な扉を押し開いて、外に出ると、天井のない古びたコンクリートに囲まれた狭い空間は眩しいばかりである。

すると、後ろで扉の閉まる音がした。
例のイタリア人が閉めたものか、と振り返ると、果たして、そこには扉はなかった。
「えっ!」
とワタクシが思って、立ちすくんだところで目が覚めた。

まさに夢オチである。(笑)

| | コメント (2) | トラックバック (0)

VMWarePlayerをインストールしてみた。

なんか、SUNがOracleに買収されてしまって、OpenSolarisの動きも怪しくなってきて、このままではVirtualBoxもどうなるか解らんなー、と思っていたので、フリーな環境でなんかないものかと、まずは仮想環境の雄、VMWareを試してみることに。

とりあえず、仮想マシンの変換が出来れば、Playerでもいいかな、と思ってダウンロードしてみたんですが。
いつの間にやら、VMWarePlayerでも、仮想マシンが作れるようになってたんですね。
知らなかった。

ダウンロードしたバージョンは3.1.1ってことで、一応、最新。
とりあえず、新規に仮想マシンを作って、Ubuntuの10.04をインストールしてみましたが、問題なく起動。
もしかしたら、これ、VirtualBoxよりも扱いラクかも、とか思ってたんですが。
USBのプリンタを認識しねぇ。orz

なんか、リリースノートにホストがUbuntu10.04だとUSBがダメかもね、的なことが書いてあったんですが。
見事に玉砕。
まあ、この辺は、sambaでつないで印刷とか出来ればOKなんで、そんなに気にしなくてもいいとこかも知れませんけど。

まあ、なにより使い勝手がよさそうだと思ったのが、クリップボード経由でファイルのコピーが出来ること。
ホストマシンとネットワークでつながなくとも、簡単にファイルのやりとりがコピペで出来る。
これは、ワタクシ的には嬉しいところ。

なんでか、ってぇと、主にUbuntuの仮想マシンを使う場合ってのは、みくかべ♪などのツールの動作確認な訳で、debファイルを気軽にコピペ出来るのは、メリットこそあれ、なんもデメリットはないわけで。

まあ、そういう用途に使う分には印刷とかできなくても問題ないので、これはこれでアリかな、とか。

ただ、予定していたWindowsの仮想マシンの移動が出来ないので、これはもう、最後までVirtualBoxで使って、いよいよとなったら、再インストールの方向で考えるしかないかな、とか思ってたりします。

面倒なんだよねー。Windowsの再インストールとか。(^^;

ま、それはそれで仕方ない。
いっそ綺麗になるからいいかも知れないけど。

というわけで、意外に使えることが解ったので、とりあえず仮想環境に関して、Oracleがなんかやらかしても、困ることはなさそうな気配です。

ま、まずはこれで一安心。

ちなみに、ダウンロードするときに、個人情報入れて、登録しないと、ダウンロード出来ません。その手のがキライなひとには向かないかも。(爆)

| | コメント (5) | トラックバック (0)

おっさんにも解るPython推敲中

おっさんにも解るPythonを推敲してます。
てか、まだ書き足しレベルですが。
とりあえず、構文ブロックの説明とインデントの関係について追記してました。

あと若干のタイトル見直しか。
タイトルから、何をしているのか想像つかないと、なんかワクワク感がないかな、ってことで、次は何をするのか、ってのが解るタイトルがいいよな、ってことで、見直してますが。
ま、まだこれも半端な状態。

ついでにライセンスも明示してみたり。
本文テキストはCC、ソースコードはBSDライセンスってことに。

特にソースコードは最初GPLでやろうかと思ったんですが、なんかそれだと著作権表示を引き継がなきゃならんそうで、母体として公開しているソースにそんな面倒なライセンス付けるのもアレだな、と。

その点BSDライセンスなら、好き勝手に利用してよいようなので。

それはそれとして。
初学者対象というのが譲れない線なので、IDEであるNetBeansの使い方も、ある程度は解説が必要なのかな、と。
特にデバッグにまつわる話は、別ページとして記載がいるかな、と思ってみたり。
まあ、探せば、NetBeansの使い方くらいは載ってるサイトがあるかも知れないので、そういうのはそっちを参照とかにしたいんですけどね。

Pythonの場合、IDEでデバッガ組み込み動作が可能なので、その辺の説明もうまいことやれれば、もう少し、取り組み易くなるのかなとか思うわけです。

まあ、初学者の場合、ソースコードを書く、までは可能でも、エラー原因の特定とか、正常に動作してない場合の対処法をまず知らないので、原始的なデバッグの方法を提示しとくのも悪くないかも、とも思うんですが。
#デバッガがもう少しマシなら、そんな苦労もないんだけど。

とまあ、最近おっPyネタが続きますが。
実はこれしかやってなかったり。(笑)

ぼちぼち、VirtualBox以外の仮想環境を試す、とかもやりたいんですけどね。
OracleにSUNが買収されてから、ちと色々とキナ臭いので。
使える間はVirtualBoxを使うつもりではいますが、ダメになったとき、何に移行するのか、今のうちに選定しといた方がいいよな、ってことで。

D&Dが使えるらしいのでVMWareがいいのかな、とも思ってるんですがー。
フリー版で、どこまで機能があるのかも疑問と言えば疑問。
まあ、この辺、調べて試してみるのが確実なので。

近日中にはやっときたいところだなー。

| | コメント (3) | トラックバック (0)

おっさんにも解るPythonに関して

おっさんにも解るPython、第一部完としてたんですが。
ある識者に無理やり読んでもらって(笑)、意見を求めたんですが、初学者には敷居が高いところがあるということで、見出しも含めて、もう少し見直しが必要なのだな、と感じてました。

まあ、実際のところ、tminさんも苦戦しており、もう少し、最初の段階でPythonの特徴であるところの構文ブロックなど、詳しく説明を追加する必要があるのかな、とも思ったわけですが。

実はIDEを使うと、この辺のシンタックスエラーの類は、エラー発生行に!がついて、alt+Enterで、エラー内容が表示されるので、まあ、放置でもいいかな、と思ってたりしたんですが。(笑)
#そのそも、その使い方の説明もしてなかったり。(^^;

NetBeansの細かいTipsも含めて、もう少し追記や、見直しは必要かな、と。
その辺、ひと通り終わって、初めて完成、そして第二部へ、てな流れになりそうですな。

u-bonさんとこで、紹介されて、なんか一気にPV増えてたんで、その辺の作業は近々にやっとかないと、せっかく見に来てくれたひと、これからPythonプログラムを始めようとするひとを、挫折させる要因になってしまうので、なるべく早めに手を入れていこうと思います。

解らんなら、コメント頂けると、こちらも助かるんですが、まあ、初学者で初見のひとが、「ここが解らん」と言えるなら、実際本人も苦労しないんだろうな、という想像も付くわけで。

こちらから、積極的に改訂していくのが吉なんでしょう、たぶん。

てなわけで、もう少し内容は、大なり小なり見直して行きますかね。

| | コメント (15) | トラックバック (0)

ChromeとFirefox

結局Firefoxばっかり使ってるなぁ、ってのが実際のところ。
Chromeは、見た目にもレンダリングが速いのが解るし、まあ、確かに軽快に動作してるなーってのは解るんですが。
ibusとの相性の悪さも解消したし。
一時、メインブラウザにしようかな、と思ったこともあったんですが。

そんでも。
結局Firefoxになってしまってますね。

なんで、ってのは、まずChromeのメリットであるレンダリング速度は、今のワタクシのメインマシンでは、ぶっちゃけ大差ないので、仮にChromeの方が倍速いとして、その時間差は1秒程度しかないんですよね。
で、Web見るときに1秒が重要か、というとそういう使い方をしてない。

また、Chromeのメリットとして、ツールバーなどが整理され、リンクバーなんかも通常は非表示、また、一番下のバー(名前忘れた)も必要がある場合に、最低限しか表示されないという、ブラウザの表示領域を最大に取ってくれる、ってのもあると思うんです。

で、これも今のメインマシンだと、あまりメリットに感じない。(^^;
#ネトブとか、縦が狭いPCだと、かなり強力なメリットであると思います。

今後熟成が進めば解りませんが、現時点では、FirefoxのプラグインであるScribeFireというブログエディタ、この存在があるので、Firefoxから離れられない、ってのが実際の話です。

このように、いきなり何のネタもなく書き始める場合には、別にブログエディタなんて使わなくてもいいんですが、Firefox上のScribeFireを使えば、気になったページの引用したい部分をマークして、それについてブログを書く、ってのが右クリックメニューに追加されて、この機能を大変に重宝しているので、これが使えないうちは、Chromeに移るメリットがないな、というのが大きな理由であると、ワタクシは考えています。

てか、それしかないんだけど。(笑)

一度、これに慣れてしまうと、なかなか、他のブログエディタとか使う気にならず。
ChromeにもScribeFireが出てきたんですが、この辺、まだ機能が足りないんですよね。
ブログエディタとしての画面レイアウトも、ChromeのScribeFireの方が、ちと自由度が低いというか、縦の行数が多く取れないので、やはり、まだまだか、という印象。

もっと別のでもいいんですが、ScribeFire並のブログエディタがChromeにあれば、Chromeをメインに据えるかも知れません。
今のところは、ScribeFireが手放せないので、しばらくはFirefoxのままでしょうかねぇ。

| | コメント (0) | トラックバック (0)

おっとびっくり。

おっさんにもできた! PythonによるGUIプログラミング環境をUbuntuベースで構築する。 | Viva! Ubuntu!!

いやぁ、ありがたきコンテンツが公開されております。
その名も

「おっさんにも解るPython」。

「Project Mikunchu♪」の首謀者、いや(^_^;;;中心メンバーであらせられる、かおりんさんによるありがたき福音書です。

プログラミングに手を出すくらいならば、開発環境くらい、自分でググッて調べて構築するよね。。。(^_^;と言われちゃうところでしょうが、おっさんは意外と忙しかったりするんですよね。。。ってことで、下記に手順をまとめてみました。
経験豊富な妄想力を発揮して、週末プログラマーなんていかがでしょ?

ゆくゆくは、かおりんさんによるこの原作がマンガとして世に出るといいなぁなどと思ったりしながら、
おっさんのひとりである私も、さっそく手順通りにやってみました。


おっPyがu-bonさんとこで紹介されている!
ちょっとびっくりした。(笑)

ちなみに、一言言わせてもらうなら、萌えOSに対抗はしてたかも知れませんが、特にダメ出しをして発足したわけではなく、単なる冗談から始まったのがみくんちゅ♪であり、首謀者はtminさんです。ワタクシが大将と呼ぶ場合は、大抵はtminさんのことで、プロジェクト全体を取りまとめているのが、彼ですね。
ワタクシは単なる協力者に過ぎず、Project Mikunchu♪そのものが、tminさんの成果物である、ということに、実は彼は気がついてないようなのですが、まあ、それはそれとして。(笑)

おっさんにも解るPythonでは、この手の環境設定の手順に関しては、思いっきり省きましたので、補足記事はありがたいところ。(笑)

あとでtminさんとこの記事も含めてリンクを張らせていただきましょうか。(笑)

ま、瀬尾ペンさんにマンガにでもして貰えれば嬉しいところですけどねぇ。(笑)
瀬尾ペンさんもプロですし、そんなことやってるヒマはなさそうですが。(爆)

漫画化かぁ。面白そうだけどなー。

| | コメント (0) | トラックバック (0)

MiniDLNAとPS3で、動画環境構築すべし。

miniDLNAなるDLNAサーバを試す。」というエントリで、インストールしたMiniDLNAですが、やはり、今一番、お勧めのDLNAサーバではないかと思われます。
リポジトリにないのが残念ですが。
BRAVIAは前述の通り、mpgファイルしか再生出来ないとか、動画回りにちと残念なところがあるものの、PS3との相性が抜群です。
トランスエンコードがないので、mkvとか、isoとか再生できないのは痛いところですが、その辺は、予めHandBrake等でmp4化してしまえば、ほぼなんでもPS3で再生可能でした。

他のDLNAサーバ、例えばPMSとか、MediaTomb等で正しくPS3で認識されないMP4ファイルも、MiniDLNAなら、きちんとPS3側で認識し、しかも10倍速や、30倍速などのスキップも可能です。
元々小さいしCで書かれてるようで、常駐量も少なく、設定もトランスエンコードがないぶん簡単です。

もう、これでOKな感じですね。
ワタクシは、もう一台、DLNAクライアントとしてPS3を買う決心をしてしまいました。(笑)
そんで、TVにつなげれば、もうDLNAで悩む必要もないし、TVもDLNAにこだわる必要ないし。
まあ、無線LANの速度でも安定して性能出るのか、は試してみないと、ですが、最悪NECのAtermの子機をもう一台買ってしまえばいいわけで。
#出費は嵩むが。

幸い、まだエコポイントは継続になるようなので、次のTVを買ったエコポイントでPS3を増設しようと考えております。

DVD画質(SD画質)をフルHDにアップコンバートして、こんだけ綺麗に再生出来るのは、いまんとこ、PS3が一番お得なんじゃないでしょうかね。
オマケでゲームも出来るし。
トルネもあるから、そっちのPS3につないでしまえば、普通に録画を家族で見ることも出来そうです。

MiniDLNA+PS3、今のところ、ワタクシの中ではベストの組み合わせですな、動画サーバ環境としては。

お勧めです。

| | コメント (0) | トラックバック (0)

おっさんにも解るPython 第一部完(笑)

おっさんにも解るPythonですが、第一部を書き終わりました。
まあ、これで「なんとなく」PythonでGUIは作れるはずです。

あくまで、あれを母体として、なら。

スクラッチで自分で一から組み立てるとなると、また話は変ってくるかも知れませんが、必ずしもそうしなければならい、なんてルールはないし、OSSなので、利用可能なソースはライセンスの範囲で自由に利用すればいいと思いますし。

とりあえず、第二部の案も考えてはいますが、まあ、着手は未定です。

第二部の構成は、まず、自分が何をしたいのか、を考えてみよう、から始めることになると思います。
まず、手を動かしてしまったので、じゃあ、プログラミングに着手するまでの過程として、どんなことを考えていけばいいのか、実際にプログラミングするまでに、しなければならないこと、理解しておいた方がいいこと、が主体になるかな、と。
その上で、どうして、こういうプログラムになるのか、というプログラム構成や、関数化、メソッド化、オブジェクト化するための道筋というのを示したい、と思ってたりします。

まあ、こうなると言語入門というよりは「プログラミング入門」の側面が強くなってしまうので、タイトルとそぐわなくなるので、さて、という課題はありますが。

まあ、Pythonという言語を前提としたプログラム構成というのはあるので、そんなに大外しでもないかも知れません。

第一部では、ネタは決まっていました。
もう「これを作ろう、こういう形で作ろう」が決まってる前提から始まっていたわけです。
なので、いきなり手を付けることが可能だったわけですが、その前段階、じゃあ何を作ろう、から、それを作るためには、どう考えればいいの、は端折られています。
決まっていたので。

第二部は、その辺を中心に据えたいんですが、これ、たぶんツマラナイんですよね。(笑)

まあ、ちと着手してみないと、ってとこもありますし、もう少し汎用的なGUIフロントエンド母体を作ってみる、って手もあるのかな、と思ったりもしているので、今構想中の第二部は、第三部まで引っ張るかも知れませんが。

プログラムの構造をどう考えるのか、の視点が今の「おっさんにも解るPython」には抜けているので、そこをどう埋めるのか、が課題ではあるな、と思ってますけどね。

さて、まあ、少し期間を開けて、現在の内容をリファインしながら、次に着手しようかと思ってます。

ま、まずはtminさんが、きちんとみくんちゅ♪セットアップヘルパを完成させるまでは、生暖かく見守りたいと思ってますけどね。(笑)

| | コメント (2) | トラックバック (0)

Ubuntu10.10βに触ってみた。

まだ、触ってみた、程度なんですが。
印象としては、10.04から、細かいところが変わったバージョンな印象。
もちろんカーネルは新しくなっているし、対応ドライバも増えてるはずなので、10.04で困ってた部分は解消されてるんじゃないかと思いますが、実機がないので、その辺は試せないのが残念なところ。
確か無線LANサポートとか強化されたと思うんで、10.04まで鬼門だったチップも、案外すんなり認識されるようになっているのでは?
と期待してますが。
#ワタクシ的には、わりとどうでもいい項目ですが。(爆)

まあ、そういう比較的「裏側」の部分には手が入ってると思いますし、パッケージの整理も進んでいるようで、aptitudeが標準では入らなくなったなど、「機能の被ってる」パッケージは排除の方向のようで。
まあ、aptitude便利なんで、ソッコー入れますけど。(笑)

あとはアプリケーションセンターが少し見た目変わったかな。
細かく手は入ってるみたいで、微妙にあちこち変わってますな。通知領域とか。
安定性に関しては、まだβなんでなんとも言えないんですが、10.04の出来がいいだけに、ここで乗り換えるか。というとどうだろうか。というのが悩みどこなひとも多いかも。
それほど、今回は新機能と呼べるものはないので、例えばbtrfsは入ってますが、まだ/bootが対応してない(grubが対応してない。)ので、常用はどうかな、とか。
まあ、次ですかね。11.04辺りでは、入ってきそうですが。
んでも、その頃だと、zfs辺りも含まれてきそうで、常用fsで悩みそうな気配。

これから大きな変更が入るとは思えませんが。
10.04が、かなり安定したリリース、かつLTSなので、ある程度Ubuntuに慣れたひとなら、10.04をベースに必要なパッケージだけ野良ビルド、でもいいかも知れません。
FireFoxは、一応、新バージョンはサポートリリース全部に適用されるし、コアな部分はまあ、問題ないと思われるので。

ワタクシはリリース時か、RCの時には移行しますけどね。

ちなみに。
早々とβから試したのは、みくつべ♪とみくかべ♪の動作確認のタメでした。(笑)
PPAの都合上、早めに作っておきたかったので。

まあ、さらっとしか動かしてませんが、どちらのパッケージも問題ないようです。
なので、特に手を入れずにパッケージだけ、10.10用にして、PPAに入れときました。

まあ、RCの時には実機確認の必要がありそうなので、入れますが。

あと、ネトブには今回はネトブエディション入れてみようかな、と思ってますけどね。RCのタイミングで。
使えないようなら、10.04に戻すかも。(笑)

| | コメント (2) | トラックバック (0)

Conkyが擬似透過じゃなくなってたらしい。

[ Conkyで擬似透過ではなく真に透過をする方法と画像表示をする方法] by ひねもすLinux

Conkyのバージョンを気にせず使っていたのですが、気がつくと大分アップデートされていたようです。
kde4でConkyの背景を透過する方法 で苦労したのも束の間、便利になったものです。
Conky1.8からこの透過が使えるようになっているようです。

上記の画像はKDE4のPlasmoidウィジェットがConkyに邪魔されずに透過しているサンプルです。
それ以外にも、アイコン、その他、なんでも透過してくれます。
Gnomeなどでも同様でしょう。


Conky使ってるひとは多いと思うんですが。
背景透過できるし、結構使いでがあるんですよね。
各種情報表示するには。

んで、そのConky背景の透過がこれまでは擬似透過だったわけです。
というのは、デスクトップの壁紙の一部を自分のウィンドウの背景としてコピーして表示していたんですね。
完全な透過表現ではなかった。
それが、完全な透過になったようです。

透過率とかももしかしたら指定できんのかな。
そうすれば、壁紙に依らず見やすい、って表示に出来そうですけどね。

KDE等とも相性がよくなったそうで。
KDEを使ってるひとは要チェックだ。(笑)

| | コメント (0) | トラックバック (0)

VirtualBoxにUbuntu10.10 β版を入れる

Fix Virtualbox guest addition installation issue in Ubuntu 10.10 Maverick Meerkat | Unixmen

Open terminal and enter the commands bellow:

sudo apt-get update
sudo apt-get install build-essential linux-headers-$(uname -r)
sudo apt-get install virtualbox-ose-guest-x11

After installation is finished, restart your virtualBox machine then go to System -->Preferences -->Monitors and change the resolution of your screen.

ってことで、上記は、β版でGuesutAddtionがインストール出来なかったので、ぐぐったら出てきた情報。
なんか、専用のドライバあるみたいね。

これで無事認識。まずは一安心。

ってことで、メモ。

| | コメント (4) | トラックバック (0)

セオリー通りということ。セオリーを無視するということ。

Twitterの方で、ぼちぼちと呟いてたりするんですが。
ちと、まとめとこうかと。

昔、ラジコンをやってまして、車の方ですが。
これがまた、セッティングとか非常に細かいレベルで調整するんですが、天気、温度や湿度、そんなものまで影響していて、大枠のセッティングと美著性ってのが必ず入ってきます。

で、これにも、「こう見ていく」というセオリーがあって。
ただ、そのセオリーってのは、「特定の場所」でしか通用しないものも多く、別の場所でうまく走らない時は、「セオリーから外して、逆をやる」なんて柔軟な発想も必要だったりします。
まあ、事実、何人かでチームだったりすると、敢えてみんなバラバラのセットで走って、その後感想を伝えあって方向性を決めたりする、なんてこともあるんですが。

んで。
このセオリーってのは、「経験によって蓄積された知識」によって成り立ってると思うんですが、それが通用しない場面では、敢えてそれを捨てる、という柔軟さも必要だと思うんですよね。

まあ、なんの話かというと、実はラジコンじゃなくて。(笑)

最近、なぜかプログラミングの話題に巻き込まれることも多く。
#自分で引き金引くことも多いんですが。(笑)

「プログラミングを学びたい」に対しての回答が「まずC言語」ってのは、昔のセオリーでした。
なぜか。
「汎用的に使える」言語が、C言語かアセンブラしかなかったからです。
#BASICもあったな。あ、Pascalもか。(笑)

当時のC言語は、今で言うJavaのように「ポータビリティに優れた言語である」と言われていました。
まあ、CLIの時代の話ですし、OSの壁は標準ライブラリが吸収するという考え方があり、「書き方によっては」ポータビリティに優れている、というのもあながち嘘ではなかったし、確かに、当時のほとんどのOSでC言語の処理系があったんじゃないかと思います。

ま、現実にはポータビリティなんて、幻想に過ぎなかったわけですが。
#もちろん、ポータビリティの高いコードを書いていたウィザードと呼ばれるプログラマ達がいたのは事実ですが。

そんで、今も「プログラミングを学びたい」に対しての回答は「まずC言語」なんですよね。
今、C言語を勧めるひとに、その理由を聞いても、明確な理由はないと思います、たぶん。
てか、思いつかないし。
そもそもワタクシは、今、初学者に勧める言語にC/C++は含めません。
そんなの後回しだろ、と。

昔のC言語は、アセンブラに比べて、圧倒的に解り易い言語でした。
プログラミングというと、まずアセンブラ、という時代に、劇的な変化をもたらしたのは間違いないでしょう。

同様に、今は、初学者が「プログラミング」を学ぶための敷居の低い言語がいくつかあります。
Javaを筆頭に、Perl、Ruby、Python。
いずれもライブラリが豊富で、熟練すれば、それだけでキチンとアプリケーションも構築できますし、なによりメモリ管理がきちんと言語側で管理され、「OSごと落とす」ようなキケンなプログラムを書く心配がない。
C言語は、「OSごと落とす」ようなキケンなプログラムを書けてしまう言語なわけです。
#間違いで。

また、プログラミングを学ぶ上で、「オブジェクト指向型言語だから、オブジェクト思考を理解しないと先に進めない」なんて話も聞いたりしますが、プログラム言語ってのは、そんなに不自由なもんじゃありません。
オブジェクト指向型言語が、構造化プログラミングだけで書けないか、というと、そんなことはないんです。

プログラミングの学習のセオリーに、オブジェクト指向が、まず入ってくるのはおかしいと思ってます。(笑)

構造化は、もう仕方がない。これは、避けて通れないと思います。
冗長な表現を避けて関数化する、変な分岐やジャンプはしない、これはもう当然なので、構造化プログラミングは「意識されない」と思いますが、避けて通れない部分でしょう。

しかしながら、オブジェクト指向プログラミングなんてのは、いわば、大規模開発のための設計技法なので、プロを目指すならともかく、趣味のプログラミングで、「完全に理解」なんてする必要はないし、そもそも「なんかこんな感じー」で十分です。
必ずインターフェースや、基底クラスを作って、そこから派生させて、なんてやる必要なんてないんですよ。
それはフレームワークを作成するために必要な知識であり、技法です。
継承すら、場合にはよっては知識として不要だと思ってます。

学習するプログラミング言語に関しても、すべての構文なんて、まず最初に覚える必要なんてなくて、最低限の構文、変数の宣言や関数宣言、そして制御文、これくらい知ってしまったら、まず書くことができるんですよ。
プログラムを「効率よく書くためのセオリー」はあるかも知れません。

でも、「プログラミングを学ぶ」ためのセオリーなんてないんじゃないか、とワタクシは考えています。
ひとによって考え方、学び方は様々あるし、まずきちんと理屈を学んでからじゃないと手を付けられないひと、まず手を動かして、痛い目を見ながらkじゃないと学んでいけないひと、両極端ですが、両方あると思うんですよね。
なので、初学の方法を「決まった形」で勧めるのは、間違いじゃないかと思うんですよ。
まず「何をやりたいのか」でも、学習の手順が変ってくると思います。
例えば、「Rubyを極めたい」ひとに、まずは手を動かせ、って言っても納得しないでしょうし。

まあ、一方で。
「プログラミングを学びたい」ひとが、明確に目的を持ってることも少ないのも事実です。
でも、それはそれでOKかとも思ってるんです。
「なんとなくプログラミングってやってみたいんだけど、どこから手をつければいいの?」な質問はアリだと思います。
それこそ、「んじゃJavaからやってみれば?」「Rubyがいんじゃね?」とか言えるわけで。

質問に回答する方も「それがセオリーだから」と思ってるのかも知れませんが、そのセオリーが間違ってる可能性があることも考えた方がいいんじゃないか、とワタクシは思います。

なぜ、それを勧めるのか。
自身で明確な回答が出せないなら、それを勧めるべきではありませんし、自身のレベルで、初学者のことを考えるのもナンセンスです。

世に出回っているセオリーは、時に無視することも大事であろう、とワタクシなぞは考えますがね。
特に、自分で学習する場合、まずはセオリーに乗ってみるのもいいですが、なんか違う、と思ったら、手順を疑ってみる、そういう必要もあるんじゃないかと思いますよ。
こと、プログラミングに関して言えば。
したり顔の上級者の言うことは、あまり信じない方が吉です。(爆)
#ま、つまりこの文章も信じない方がいいってことになりますか。(笑)

さて、どんなもんでしょうか。

| | コメント (0) | トラックバック (0)

さて、今回は?

ユーザーのLinux移行を円滑にするためのティップス5選 - IT業界を生き抜く秘密10箇条 - ZDNet Japan

Linux初心者にとっての移行エクスペリエンスを素晴らしいものにするために、どのようなことをしておくべきかについては、以前にも記事で採り上げている。本記事では、Linux初心者、および移行を準備するあなたの双方にとって円滑な移行を実現するうえで役立つさらなるティップスを紹介している。

例の記者による記事が来ましたが。
まあ、今回も、案外マトモかなぁ。

#1:基本的なことを教えておく

ってことなんですが、あまり、基本的なことを教えてる場面って見たことないような気がするんですよね。まあ、IT業界にいるせいかも知れませんし、最近は学校でWindowsくらい触ってくるからかも知れませんが。

説明して解れば、それに越したことはないんですが…。

ま、何度も操作しないと覚えないのも事実だし。
むしろ、何も説明しないで、「これやったらどうなるのかな?」くらいに興味を持って弄ってもらった方が早いような気も。
Linuxなら、大抵のことなら、PCそのものが起動しなくなるような操作は一般ユーザーでは、できないし。
設定ファイル飛ばしたところで、さほどダメージもないしね。
まあ、sudoパスワード教えてしまう、とかうかつなことをしなければ、ある程度は、放置でもいいような気がするけどね。

#2:まずGNOMEを使ってもらう

まあ、GNOME派なんで、それ自体は賛成なんだけども。
KDEが複雑っても、ある意味、一箇所で集中管理出来ているわけでGUIの整合性も、KDEの方が一枚上手だと思うんだがね。
ただ、ちょっとした操作がWindowsとかなり違うんで、戸惑うんだよ。
WindowsからLinuxに移行するなら、GNOMEの方がWindowsに「似ている」んだ。操作性が。見た目じゃなく。
GNOMEを推す理由としたら、そこだと思うんだけど。
シンプルな操作性とか、KDEのコンセプトが理解出来ないとか、そんなことじゃなく、単に「Windowsに似ているかどうか」だけで、GNOMEを選んだ方がいいと思うよ。
どうせ初心者には、GNOMEにしてもKDEにしても、Windowsにせよ、Macだって、「GUIのコンセプト」なんて理解しないからさ。w

#3:マシンは完全な状態にしてから渡すようにする
#4:OpenOffice.orgのデフォルトファイルフォーマットをMicrosoft製品のものに設定しておく

ま、これは同意。予めセットアップしたものを渡すなら、問題はないでしょ。そこで一手間かけて置けば、トラブルの予防にもなるし、管理者の時間が無意味に奪われることもなくなるしね。前回と同じだね。

前回と同じTipsってのは、いよいよネタが尽きかけている?(笑)

#5:ユーザーがリムーバブルメディアについて理解していることを確認しておく

これ、Linux関係ないし。

なんか不完全燃焼。
Tipsっぽくもないしなー。前回と同じネタ、二つも混ぜないでよ。(笑)

ま、5個だし、次に期待かなー。

| | コメント (0) | トラックバック (0)

最低限の知識でどうにかする。

まあ、主にプログラミング時の話になってしまうかも知れませんが。
基本的には、ワタクシの場合、「知らなければどうにもならない最低限の知識」が得られた時点で、手を動かすようにしています。

そうしないと、まず話が前に進みませんし、知識を得るための座学ばかりしていても、飽きてしまうからです。

以前に、会社の研修で行かされた研修の講師が、似たようなことを言っていて、「やはり」と思ったと同時に、その研修が非常に実践的で満足した覚えがあります。

やはり、座学だけでは、知識を「得た」という実感が湧きませんし、手を動かして、体験することにより、初めて「会得した」という実感とともに、脳内に深く刻まれるのではないか、とも思うわけです。

とはいえ。
読書などの疑似体験に依る知識を否定するものでもありません。
偉人の伝記や、冒険譚など、自分ではとても体験できない様なことを綴った本を読むことで、擬似的な体験をして、知識を得る、ということもまた、間違いではないと思っています。

ただ、やはり読書は読書、技術は技術と思うところがあり、実際に手を動かして為すことは、自身の体験として行なってしまった方が手っ取り早いと思いますし、例えばピアニストの自伝を読んで、ピアノが華麗に弾けるようになるか、というと、そんなこともないと思うんですね。

自分が為すことは、やはり自身の手で経験することが重要であろう、と思ってはいます。
#重ねて言いますが、読書による知識の蓄積を否定するものではありません。

なので、「手を動かすことの出来る最低限の知識」を得た時点で、手を動かしてしまうようにしています。
もちろん、「最低限の知識」しか持ち合わせていないので、失敗は多いです。
しかしながら、人間、成功から得られる知識、知恵よりも、失敗から得られるものの方が多いと思うのです。

まあ、仕事で失敗するのは痛いですが。(笑)

趣味のLinux環境構築や、プログラミングで失敗する分には、せいぜい自分が被害を被る程度で済みますし、何度でもやり直しが出来るので、興味のある分野では、どんどん失敗を重ねています。

まあ、何より、手を動かしていると「飽きない」ので、それが重要なのではないかな、と思うんですね。
興味があること、やってみたいと思うことはすぐにやる。
結果、失敗したら、また調べてやり直す。
あまり失敗しすぎてメゲることもありますが。(笑)
それでも、何もしないよりはマシだと、ワタクシは思っています。

努力は、必ず報われるとは限りませんが、努力した結果が、何も残さない、ということはないのです。

まずは、やってみましょうか。
ぼちぼち、Ubuntuの新バージョンもリリースされますしね。(笑)

| | コメント (0) | トラックバック (1)

アスワンにはこれを入れてみるかな。

Ubuntuの新たなる分野へのチャレンジへの象徴となる「Unity」を搭載した、Ubuntu 10.10 Netbook Editionのベータ版も公開。 | Viva! Ubuntu!!

ネットブックのコンパクトな画面を有効に活かして使いやすいようにデザインされることはもちろん、マルチタッチ機能と合わせて、タブレットPCやスレート型PCでの利用をも視野にいれて開発されているわけです。 従来リリースされていたNetbookリミックス版/NetbookエディションのGUIを一新し、このUnityに文字通り統合されていくことになります。

iPhoneを買ったおかげで、放置気味だったアスワンですが。(笑) これ、かなり画面的にいいですね。ネトブの狭い画面でも有効に使えそうな雰囲気。 まあ、ワタクシのアスワンは古いので、縦が600pxという狭い画面なので、それでも厳しいかも知れませんが。(^^;

パッと見、縦配列されてるランチャがよいな、と。WSVGAなので、横は割と余裕があるんですよね。>アスワン

まあ、取っとく設定とかもほとんどないから、今回は、これ新規でインストールしてみようかな。
もちろん、正式版がリリースされたら。(笑)

| | コメント (0) | トラックバック (0)

OOoのWriterやCalcの作図って

おっさんにも解るPython用にちょっと作図しようと思って、OOoの表計算を起動したんですが。
仕事だと、作図と結構Excelでやってしまって、画面スナップ取って張り付けたり、とかするもので、その感覚で。

そしたら。
OOoの表計算の作図って、アンカー使えないんですね。知りませんでした。
アンカーってのは、図と図を線でつなぐ場合に、特定の位置で結線して、図が移動しても、きちんと追従してくれる便利な線なのですが。
特に行き当たりばったりで作図して、文字量とか増えたら移動してなんてことをやるんですが、その時に、アンカーが使えないと結構致命的。

で、調べてみたら。Drawで作図するとアンカーが使えるらしいので、そっちで作図しました。
エクスポート機能で、pngとかにも落とせるので、余計な部分はGIMPでカットして使いましたけど。

でまあ、正直、OOoではMS-Officeには敵わんな、というのが感想。
もちろん、ごくごく普通に使ってる分には、全然問題ないし、多機能で、これだけのものがフリーであるのは、凄いことだと思うのですが。

やはり一歩及ばない。

つくづく、WindowsとMS-Officeの牙城は、まだしばらく崩れないな、と思いました。(笑)

ま、使い方が間違ってるって話もないではないですが、作図機能があるのに、アンカーないとかないだろ、と。(^^;

ま、そんだけです。

| | コメント (4) | トラックバック (0)

Bloggerでプログラムコードを表示するとき便利なウィジェット

クリボウの Blogger Tips: コードをハイライトする「Blogger Syntax Highlighter」ウィジェット

このウィジェットは、Google Code に公開されている「syntaxhighlighter」というコードを元に作られています。

忘れないようにブログに書いとく。

これを導入すると、Bloggerでプログラムコードを記載するときに便利。
読者も便利。(笑)

コピペするときに、ViewPlainとか選択出来て、素のままのソースコードが表示される。

ココログにBloggerの話を書くのもなんだけど、覚書。

| | コメント (0) | トラックバック (0)

家庭内サーバによさげ

日本エイサー、ひし形のコンパクトなデスクトップPC:ニュース

「eMachines」ブランドのコンパクトなパソコンで、薄い、ひし形の特徴的なデザインを採用した。価格はオープンで、予想実売価格は3万9800円前後。

AthronII Neoの実力がAtomとどの程度差があるか、てのが悩ましいところだけど、GeForce搭載ってことはCUDAも使えるわけで、ホームサーバ的に使うにはよいかも。
まあ、サーバにするには、HDD容量が圧倒的に不足するけど、そこは外部ストレージで間に合わせればいいし。

あとはWindows7 HomePremiumとやらがリモートデスクトップに対応しているかどうか、かな。
USB3.0とかe-SATAとか付いてるなら、十分使えそう。
安いし。(笑)

まあ、候補のひとつにしとこう。

| | コメント (0) | トラックバック (0)

わりと頷けるというか、宣伝なのかね。

筆者がWindowsからUbuntuに乗り換えた理由 - IT業界を生き抜く秘密10箇条 - ZDNet Japan

この流れにさらに一石を投じたいのだが、強烈なMicrosoft嫌いでありながらWindowsを使い続けてきたわたしは、とうとうWindows 7(たしかに素晴らしいOSだ)からUbuntu 10.04への移行を果たした。

いつもの記事とは筆者が違うようなので、さほどツッコミどころはないんですが、わりと良い記事だったので、ネタにしてみます。(笑)

実際、最新のWindowsは最新のPCで、が基本だとワタクシは思っています。
OSはバージョンアップするものではない、という考えです。
その点でいけば、AppleのOSに対する考え方は、あまり間違ってないな、とも思います。
基本、その時のそのハードに最適化してあるOSなので、新しいバージョンのOSを使いたいなら、ハードもそれに見合ったものにしなければならないので、OSのバージョンアップは提供しない、というものですね。
#まあ、セキュリティフィックスや、多少のバグフィックスはするんでしょうけど。

まあ、この考えからするとネトブのようなパフォーマンスを多少犠牲にしたようなPCで、最新のWindowsは若干無理があるわけです。
いいとこXPでしょう、みたいな。
#そんでも重い。(笑)

その点、Ubuntuであれば、GNOMEやKDE「でも」XP程度には動作してくれると思われますし、もっと他のDEやWMを選択することにより、Windows2Kのような軽量さにすることも可能です。

もっとも、その為には多少のスキルは要求されますし、Linuxの入門者がいきなりチャレンジするものではない、とワタクシは考えていますが。
まずは、Ubuntuの標準状態GNOMEのままで、一ヶ月、使ってみるといいと思うんですよ。
その上で、どこに不満があるのか、そこを明確にしておくと。
例えばウィンドウ操作時の重さが気になるなら、軽量なDEにする、という選択があるでしょうし、操作性の簡便さが不足しているというのであれば、ツールの追加や、ScreenletsのようなDAで対応可能な場合もあると思われます。

まず、一ヶ月ガマンして、その間に情報を集める、と。
その後、どうしても気になるポイントだけ、フォローするという形で、案外使えてしまうと思います。
ま、そんでもガマンできないなら、無理してLinuxを使うことはないと思いますが。(笑)
文句言いながら使うよりは、素直にWindowsに戻ったほうが安全な気はします。
特にハードウェア関連でトラブルになるなら、あまり無理はしない方がいいと思いますね。
元記事の筆者は幸いなことに、デバイスに関して、トラブルに見舞われなかったようなので、素直に移行することが出来たのだと思うのですが。
実際、AcerのAspireOneは、そんなにハードトラブルなくUbuntuが導入できるので、ある意味、オススメの機種ではあります。
てか、ワタクシも使ってますし。

元記事で上げられているメリットの最後の項目が、ワタクシ的に最もツボだったところです。(笑)
ま、無料ってのは大きいですよね、イメージとして。
ただ、やはり学習コストは掛かるもので、そこを無視して、無料だからよいか、ってぇとそうでもない、ってことは覚えておいて欲しいところです。
Windowsなら、使い慣れてるから、学習コストも低くて済みますが、Linuxだと、Ubuntuといえども、それは低くはないんです。

まあ、慣れてしまえば、どちらも大差ないとは思うんですが。
事実、ワタクシは、もうUbuntuの方がWindowsより使い易いですしね。(笑)

| | コメント (0) | トラックバック (0)

GoogleDocsは、微妙に使えなかった。

普通に使う分には、画像の挿入とか作図も出来るので、結構便利だし、使えると思うんですが。
いわゆるcodeタグとか、そういうのが使えないので、プログラムのソースコードが書けない。

んで、今の目的には、ちょっと合わないので、Bloggerに移行してみた。
ところがこれはこれで、更新された順番というか、日付ごとに記事が並んでしまうので、先頭から読むというのが困難。

どちらも帯に短し襷に長し、という状況で、もしかしたら、しばらく放浪するかも知れない。

Bloggerの方には、適当なことを書いとくブログを作ってたんですが、結局Twitterで事足りるので、あちらには書かなくなってしまったので、浮いてるといえば、浮いてる状態だったわけですが。

ちなみに、何を書いてるかというと。
おっさんにも解るPython
紹介文に書いてることが全てなんですが、一応記載しとくとこんな内容。
「おっさんにも、このブログを読めば、GTKによるLinux上でのGUIプログラミングを可能にすることを目的に書かれています。別にPythonエキスパートを養成するものではありません。(笑) おっさんなので、適当にそれらしくでっち上げられれば、それでいい、というポリシーでゆるく書かれています。生暖かい目で見守ってください。」
本格的なPythonプログラミングを学ぼうってんではなく、すでにCLIなどがある場合のGUIフロントエンドを作れるようになるまで、を目的に書いてます。
Linuxというか、Ubuntuの場合には、優れたコマンド群が大量にあるので、それを組み合わせる、或いはオプション指定をやり易くするでけで、格段に使いやすくなる「はず」なので、そういう部分を自前でGUIを作って、自分用のフロントエンドを作ってしまいましょうかね、的な入門を考えてるわけです。

プログラミングをしたことのないひとを対象に考えてますが、もう最低限の知識だけでプログラムを作れるように、ってのを前提に、面倒な説明やらは、本格的なPythonチュートリアルとかを参照してもらおうと思ってます。

まあ、今までプログラミングをしたことのないひとの取り掛かりにでもなれば、と。

仮想読者というか、対象読者がひとりいるので、そのひとの反応を見ながら、加筆/修正はしていくつもりですが、ワタクシ自身、Pythonエキスパートではないので、まあ、そんなレベルでも使えるし、プログラミングなんてできるものなのですよ、的なサイトというか入門を書いてみようかな、と。
エキスパートになってから書くと、どうしても入門時の気持ちは忘れてしまうし、どこが解らなかったポイントか、というのも忘れてしまうもんだし。
さらにいえば、エキスパートになればなるほど、その言語の特徴的な便利な機能というか仕様を使いこなせてしまうので、素人には意味不明な高効率なコードを書くようになってしまい、そのコードの意味の説明に長々と時間を割くことになるので、教えられる方が「飽きてしまう」と思うんですよね。
エキスパートに当然の話は、素人には当然じゃないんですよ。

まあ、実際にここまで書いたものを読んでもらって、強く感じましたけど。
ワタクシはプログラムを生業としていますので、「こんなの当然」な部分が多数ありますが、そうじゃないひとには「常識ですらない」わけです。
こうして文書に起こしてみると、そういうことが解りますし、実際に反応を見ながら修正もかけられるので、試験的なドキュメントとしては面白いかな、と思ってますが。

こちらも毎日、のレベルで加筆/修正を行っていく予定ですが、これだけやってるわけじゃないので、なかなかね。

もしもPythonプログラミングに興味があるなら、覗いてみてもらって、素人視点から、こういうのって解らない、って指摘貰えると、ちょっと嬉しいかも知れないですね。(笑)

| | コメント (2) | トラックバック (1)

« 2010年8月 | トップページ | 2010年10月 »