Chromeの調子がおかしかった。具体的には、特定のサイトで処理がいつまでたっても進まず、したがって表示が途中で止まったり、表示されてもスクロールができなくなったりする。長いこと使っているとそういうこともあるかと再起動してみたり、履歴が悪さをしているのかとキャッシュを削除してみたりしたが、どうにも回復しない。ちなみに、設定(~/.config/google-chrome/)を全て削除したら回復するのではないかとは思ったが、Chrome使いにとって履歴は命のようなもの。Chromeの使い勝手のよさは「使い込むほど手になじむ」というところにあるわけだから、これは痛い。なんとも凄い依存体質になっているものだと、われながら呆れてしまった。キャッシュだけでもと思って削除してみたが、それもダメ。他の設定をいくつか捨ててみても改善しない。システムモニタを開いてチェックすると、どうもフラッシュ関連のエクステンションがCPU100%と暴走しているのが原因のようだ。わかっても、じゃあどうやればいいのかわからない。なったら再インストールしかないかと思ってSynapticパッケージマネージャを起動し、google-chromeのパッケージをチェックして、ようやく気がついた。リポジトリが無効になっている。調べてみると、11.04へのアップグレード時に無効化されていた。いうことは、もう2ヶ月もアップデートなしで動作させてきたわけだ。その間、Chromiumの方は何度かアップデートがあったように記憶しているから、きっとその影響にちがいない。再インストールがいいのかなとは思ったけれど、そのまま古いリポジトリを再度有効にして再読込をかけると、アップデートのお知らせが出た。そこでアップデートしたら、その後は不調は出ていない。Ubuntuを使っているんだから、うまくリポジトリを活用してアップデートは逃さずに捕まえましょう、というオチだった。|2011年05月28日Doobleは有望なブラウザなのかもしれないいままでずいぶんいろいろな種類のブラウザをインストールしてきた。これは、ひとつには好奇心ということでもあるし、「よりよいブラウザが使いたい」という欲求であったり、そのときの環境(たいていは非力なPC)に対応した軽量な動作を求めるということでもあったりした。最近ではブラウザに残るCokkieその他の履歴が邪魔に感じる場合に、「じゃあ別のブラウザでもインストールしようか」というようなことになる。複数のアカウントを使ったり一時的にCokkieをオフにするような対処法ももちろんあるのだけれど、「それならいっそ他のブラウザを」と思うのは、上記の好奇心その他の動機があるからかもしれない。最近ではそういうサブのブラウザとしては、AroraかSeamonkeyを使うことが多い。どちらも安定しているし、それぞれ特徴があって置いておく価値があると思うからだ。そのほかこれまで印象がよかったのはMidoriとかEpiphanyとかだろうか。Konqurorを入れていたこともあるけれど、あれはいまひとつの感じだった。今日も、ひとつブラウザを入れてみようかという気になって、Synapticパッケージマネージャを立ち上げ、リポジトリにあるリストを眺めていた。すると、見慣れないDoobleというブラウザがある。興味を惹かれてインストールしてみた。Webkitベースで既にChromiumとかが入っているせいか、特に同時にインストールされるパッケージもなく、本体だけのインストールなのですぐに終わる。数日前に壊してしまい失った販売管理用のデータベースを、なんとか週末かけて復旧した。構築にかなりの手間がかかったものだけれど、作り直しにあたっては記憶も残っているのでそれほど時間はかからなかった。やり直すことを通じて全体の流れも見直せたし、Baseの使い方にもだいぶと慣れた。その成果を一例報告のような格好でステップバイステップにアップすることも考えたのだけれど、ちょっと時間がとれない。そこで、ポイントだけでも書いておこうと思う。自分自身の備忘のためにも。Ubuntuの場合、LibreOfficeはリポジトリのものではなく、本家版を使うこと。これは将来的には変わるかもしれないが、当面は重要。本家版の場合、実行ファイルは/optにあるので注意が必要。テーブルのIDは、自動入力にしておくこと。入力時に文句を言われないためにも。フォームでは、要素の編集は基本的にコントロールで行う。右クリックで出して、出しっぱなしにしておく。ウィザードで作成したフォームの要素ではラベルとフィールドがグループ化されているが、これはCtrlを押しながらクリックすると中に入れる。フォームでサブフォームを追加するのは、フォーム・ナビゲーターを使う。これはツールバーのフォーム・デザインに配置されている。ドロップダウンリストで入力できるようにするには、ボックスをコンボボックスに変更した上で、コントロール中の「ドロップダウン」を「はい」に設定する。リストは、データタブの「sql」でGUIで指定できる。フォームで、なぜかテキストが「0」と表示される場合がある。この場合、テキストボックスを「書式設定されたフィールド」にして書式設定でテキストに変更するとうまくいく場合がある(そうでない場合もある)。コントロールでのフォントの指定では、フォントの大きさは整数ポイントでしかできないようで、10.5ポイントは11ポイントに変更される。集計のためには、クエリをつくる。GroupとSumを合わせて使う。固定値(定形テキスト)をテキストに追加する方法がよくわからないので、値を1つだけ入れるテーブルをつくって、そのフィールドをクエリで足し合わせる方法でごまかした。月次処理のために月別に振り分けるクエリがうまくつくれなかったので、月次を手動入力することにした。月をまたぐ特例なんかが実際の運用で発生することがあるので、これはこれでいい方法かもしれない。見積書など、PDF化の必要のあるフォームの要素は、全てアンカーをページに置くように変更した。デフォルトは段落配置になっているが、これがレイアウトの崩れる原因となりがち。変更は面倒なようだけれど、全要素を選択しておいてコントロールでまとめて変更できる。要素を追加したときには注意。他にもあったような気がするけれど、とりあえずこのぐらいで備忘にはなるだろうな。ステップバイステップのチュートリアルでもつくれればいいんだけど、現段階でやったら恥さらしかもしれない。それでも、役に立つような気はするけれど。このBaseの素人にとってのとっつきにくさといえば半端ではないように思うので。|2011年05月21日Ubuntuのデータベース・フロントエンドあれこれ元Macユーザーの私にとってデータベースといえばFileMakerなので、データベースソフトといえばあのイメージがある。実際、あれはよくできたソフトだ。Windowsで代表的なのはAccessだろうが、ごく初期のバージョンを一時使っていた感覚では、あれはかなり高度な知識が必要になる。直感的な操作ということではFileMakerの方がいい感じだったと、まあこれはずいぶんと昔の話。いうイメージでUbuntuにやってくると、案外にもデータベースがない。いや、データベース関連のソフトはMacやWindows以上に豊富で強力なわけだ。ところが、これが素人のイメージするFileMakerやAccessとは全くちがう。mySQLやPostgreSQLのサーバーはデフォルトで入っているのだが、「それってどう使うの?」と、まるでとっかかりがない。プログラマが扱う領域なわけだ。それ以外にもオープンソースのデータベースプログラムがあるが、やっぱり敷居が高い。その上のレイヤにもいろいろなプログラムがリポジトリにはあるが、これまた使い方がわからない。結局、FileMakerだのAccessだので私のイメージにある「データベースソフト」は、フロントエンドの印象でしかないわけだ。必要なのは、本格的なデータベースサーバーではなくそのフロントエンドのGUIだということ。これがなかなか、「うん、使えるね」というのを見つけられなかった。実際には、ないわけではない。簡単なのは、やっぱりOpenOffice(あるいはLibreOffice)のBaseだろう。それでも、FileMakerやAccessに比べればずいぶんと難しい。わかってしまえば「なあんだ」というようなことでも、わからないからなかなか先に進めない。これは、ヘルプとかチュートリアルの問題ではなく、やっぱりUIの設計なのだろうなと思う。だいたいが、私はヘルプとかチュートリアル、マニュアルなんかをほとんど読まず、GUIに導かれるままにソフトを使っていく癖がついてしまっている。「習うより慣れろ」式なわけだ。MacがそういうUI思想だったから、パソコンなんてそういうものだと思ってしまったのかもしれない。いう感覚でいては、なかなかBaseは使いこなせない。5年間も何度かトライしては敗退を繰り返し、ようやく少しはわかるようになってきた。そんなとき、単純な失敗でデータをすっ飛ばしてしまうハプニングがあった。使いはじめで実質的なデータはそれほど入っていなかったので被害は小さいのだけれど、それでも一から構築し直さなければならない。それならこれを機会に他のデータベース・フロントエンドに乗り換えるのはどうだろうと、ちょっと調べてみた。データベースのフロントエンドには、有力なものとして、GnomeのGlomとKDEのKexiがある。以前、データベース用のアプリを探していた時代、どちらもそれぞれに一応チェックした。Glomは何がなんだかわからず、Kexiは当時まだ開発が進んでおらず、動きが非常に怪しかった。FeistyかHardyの頃だと思う。それでもその時代からどちらもリポジトリには入っていたようで、久しぶりにインストールしてみて、「そういえばこういうのもあったよなあ」と、ようやく思い出した始末。その頃よりは私も多少はUbuntuのことがわかってきたこともあるのだろう、今回は少しは使えそうな気がした。そこでどちらかで失われたデータベースの再構築ができないかと、ちょっといじってみた。Kexiを試してみた。使い方がよくわからないからまず見本をと思って「テンプレートから作成」を選択してみたけれど、肝心のテンプレートがない。ネットを探してみても、3つほどしか出てこないから、あまり人気のないソフトなのかもしれない。仕方ないので「新規に作成」から進んでみる。以前に触ったときのはるかな記憶と比較すると、ずいぶん進化した様子。テーブル、クエリ、フォーム、リポートと並ぶ左ペインの感じは、だいたいOpenOfficeのBaseと同じなので使えそうな気がする。ツールがタブ式に配置されているのも運用を開始したら強みになるだろう。テーブルをひとつつくってみる。だいたいBaseと同じ感じなのでそれほど迷うことはない。ところが、このテーブルを保存しようとすると文句を言われる。思ってよく見ると、どうやら日本語で入力した「キャプション」が、全て「_」と解釈されてしまっている。要は日本語対応がうまくいっていないわけだ。これではちょっと使えない。いうことで、この段階でKexiは断念。こちらは以前の記憶が全くない。これも同様にテンプレートから作成してみようとするのだけれど、これが何度やっても途中で処理が袋小路に入ってしまうらしく進まない。仕方ないので、やはり新規作成。こっちのほうがKexiよりもFileMakerに近い感じかもしれない。データはどうやらカード式に個別に保存される様子だ。これは設計としては堅牢だろうと思う。クラッシュした直後だからこれは好ましく思えた。その分だけデータのサイズが半端ではない。何もデータを入れていない段階、まだレイアウトすらやっていない段階で37MBもある。これって、運用したらどこまで膨れるのだろうと、ちょっと不安になる。なんだか使い方もよくわからないしと思って公式サイトに行くと、「Ubuntuのリポジトリにあるのはバグが多いからPPAのを使え」と書いてある。テンプレートから作成できなかったのもそのせいかと合点してリポジトリを導入してみるが、なぜか通らない。見ると、まだNatty用のリポジトリが出来ていないようなのだ。そこでMarverickのを入れてみたが、これはバージョンがUbuntu公式のものよりも低い。そっちを使おうと思うと依存関係がめんどくさそうなので、この段階でGlomも断念した。いうことで、結局はOpenOffice(LibreOffice)のBaseに戻るわけだけれど、そもそも今回データが壊れたことだって、現在の運用に問題があるからではないかという気がしている。いうのは、LibreOfficeのBaseは、どういうわけかコントロールやナビゲーターがうまく表示されず、円滑な運用ができない。しかたないのでWineでWindows版のOpenOfficeを入れてBaseに関してはそっちで運用しているのだけれど、これはさすがにWineだけあってバグっぽく、ときどきJavaを見失ってくれたりもする。いう無理な運用がやっぱりよくないと思うので、Baseを使うのならLinux上できちんと動くOpenOfficeなりLibreOfficeなりを入れたいと思う。いうことで、Natty用のOpenOfficeのリポジトリがないかと思ってあちこち探したのだけれど、見つかったものは結局はLibreOfficeへの移行パッケージで、OpenOfficeをインストールしてくれるものではなかった。公式の.debファイルをインストールするのは前回失敗しているし(本当は失敗ではなく実行ファイルを見失っていただけなのだけれど)、それならDebianの公式バイナリとか、いろいろ試したけれどダメ。実行したら、LibreOfficeの最新版がインストールされた。実行ファイルの場所だけが問題で、これは/opt/libreoffice/program内にあった。ここから起動するようにすれば全然問題はないのだけれど、以前にはわからなかったわけだ。本家版のLibreOfficeなら、Baseが全く問題なく動作する。コントロールもナビゲーションも、きちんと表示されるわけだ。LibreOfficeそのものにはバグはなかった。問題があるとしたら(私の環境だけの問題でないとしたら)、Ubuntu用のパッケージに問題があるわけだ。LibreOfficeそのものの問題としてはいくら検索しても上がってこなかったわけなんだろう。いうことで、これからLibreOfficeを使ってデータベースの再構築をすることになる。手間はかかるけれど、まあ、いろいろといい勉強をさせてもらったわけで、まあこれもよかったのかなと思う。パソコンって、そういうもののような気がするし。|2011年05月20日データベースが壊れたバックアップファイルを取っていなかった自分がいけないのだけれど、ようやくうまく稼動し始めたデータベースが壊れてしまい、全てのデータを失ってしまった。何のデータかというと、事業の販売管理データ。これまでずっと表計算(.xls形式。Excelで、後にOpenOfficeのCalc)で管理してきたのだけれど、けっこう手間がかかって鬱陶しいのでデータベースに移行しようと思った。それが1ヶ月ちょっと前のこと。使うソフトはOpenOfficeのBase。これがLibreOfficeになってうまく動かなかったりと、いろいろ問題はあったのだけれど、ようやく少し前から順調に動くようになった。それまでは旧システムと併用していたのを、いよいよ完全移行だなあと思った矢先にデータが壊れてしまった。ファイルを開こうと思っても、開けない。無理に開くとCalcかWriterが立ち上がって文字化けしたテキストとして読み込んでしまう。これではどうしようもない。バックアップを取っていなかったのは、ついこのあいだまで構築中で試行錯誤の只中だったから、バージョンがいくつもできるとややこしいと思ったからだ。完全移行と思ったときに、まっさきにバックアップをとるべきだった。途中1回でもバックアップしておけば回復の見込みはあったのにと、悔やまれてならない。嘆いてばかりいても仕方ないので、これを機に少しOpenOfficeのデータベースのデータ構造を勉強してみることにした。気がついたのは、実は拡張子.odbのファイルは、実はzipファイルだということ。拡張子をzipに変えると中身をみることができる。この段階で既にデータは壊れていて、書庫マネージャではエラーで開くことができず、Squeezeでは開くことはできるのだけれど解凍はできない。弱ったなあと思って検索しているとzipファイルの修復ソフトがWindowsにあることがわかった(こちらの記事)。そこで仮想環境のWindowsにこのソフトをインストールして壊れたデータベースファイル(拡張子を.zipにしたもの)を修復すると、無事に解凍できるようになった。12をUSBメモリで復活」という記事を書いたが、その後、無線LANが有効でないことに気がついた。このマシンは友人に譲る予定なのだが、多分彼は有線LANで使うと思う。不要といえば不要なのだけれど、できるものができないのはしゃくにさわるから、いろいろいじってみた。結論としては、かなりいい線まではいくのだけれど、接続の確立までは辿りつけなかった。LXDMでのやり方をもうちょっと調べたらどうにかなるのかもしれない。最初から素直にUbuntuの通常のデスクトップ環境にすべきだったのかもしれない。ここまでわかったことは、まずプロプライエタリのドライバを導入しなければならないということ。そのためには、日本語環境では「追加のドライバ」と表示されるjockey-gtkをsynapticからインストールする必要がある。インストール後にこれを端末からひらくと、あとはGUIで無線LAN用のドライバがインストールできる。次に、ネットワークの設定をしなければならない。これは通常はnm-appletで行うのだけれど(nm-appletはnetwork-manager-gnomeに含まれるのでこれをインストールすればいい)、どうもこれではうまく認識してくれない。Nettoolだけれど、これは接続を管理するためのものではない。調べたらnetwork-configというパッケージがよさそうなので、これをインストール。起動してメニューの「設定」のところをいじると、Wifiを認識してくれた。これでうまい具合に接続できたかというと、認識はしても接続はしてくれていない。あと一息という感じがするけれど、モチベーションも時間も切れた。今回はこのあたりにしておこうと思う。12のハードディスクを取り除き、USB端子に接続したメモリスティックで運用できるようにUbuntuをインストールした。相当に手こずったけれど、終わってみれば何ということはない。苦労したあとを辿るのもそれはそれで興味深いかもしれないが、それは(もし書くとしても)回を改めるとして、今回は、まちがいなく成功する方法を書いておこう。12のハードディスクは割としょぼいようで、そろそろ寿命を迎えるマシンも多いのではないかと思う。交換用のディスクはかなり高価なので、外付けメモリからの復活が手軽で実際的ではないかと思う。いう意味で、まずは成功した確実な方法を報告しておく意義があるだろうと思うわけだ。最終的にインストールするのは、Ubuntuではあるが、デスクトップ環境にLXDEを採用することにする。12にふさわしいようだから。ハードディスクの取り外しだけれど、これはちょっと検索すれば方法は出てくる。私はこちらのブログと、その先にあるリンクを参考にさせていただいた。本当はこのブログにあるようにディスクの換装をしたかったのだけれど、それはスキル不足で失敗。外付けメモリでの復活だけなら実際にはハードディスクを取り外す必要はない。壊れたディスクがつながりっぱなしで運用するのもどうかという気がするので、可能であれば取り外すのがいいのではなかろうか。スキルのある方で安くディスクを入手できれば、ディスク交換がいちばんいいのは言うまでもない。その場合、以下の記述は不要な情報だろう。外付けUSBメモリとしては、今回は4Gのやや古いものを用意した。これは、手持ちがそれしかなかったからに過ぎない。これが8Gとか、あるいはもっと高速の読み書きができるものだと、若干、話が変わるかもしれない。今回インストールできなかった11.04がインストールできるかもしれない。このあたりはよくわからない。2Gや1Gの容量では無理なので、最低限の容量として4Gは必要というのはいえると思う。12を外付けディスク起動で再生しようとしている。ハードウェアにかなり癖のあるマシンで、ちょっと苦労したが、何とかなりそうな気配。これに関しては終わってから詳しく報告しようと思う。それはともかく、その過程で外付けのハードディスクにシステムをインストールしようと考えて、とりあえずの実験用としてずいぶん昔にMacで使っていたハードディスクを引っ張り出した。万一古いデータを扱わなければならなくなったときに必要だろうと思っておいていたものだけれど、考えてみたらもうMacは手元にないし、使いようのないのは事実。数日前にSheepShaverで旧データのコンバートもできたし、第一もう何年もこのハードディスクには触れもしていないのだから、処分してもよかろうと、これを初期化して使うことにした。最初は順調に稼動していた。ところが、なんの前兆もなく、ある瞬間にハードディスクの回転が止まった。二度と復活しなかった。いままでハードディスクのクラッシュには何度も遭遇してきたけれど、こんなあっさりと逝ってしまったケースは初めてだ。いままでのパターンは、なんとなくデータの読み書きにエラーが多くなって、診断してみたらどうもやばそうなので使用を中止、バックアップ後にだんだんおかしくなって最終的に使えなくなるというのがほとんどだった。今回のようにたったいままで順調に動いていて突然ダメになるのは初めてのような気がする。ハードディスクというのは、長期間使わずに放置しておいても具合が悪くなるものらしい。いう意味では、こういうこともあるのかなと。処分しなければならない故障したハードディスクがむなしく溜まっていく。これって、金属資源としてもそこそこ価値はあると思うんだけど、引き取り先はあるんだろうか...。屑鉄屋でもなかろうし。|2011年05月10日SheepShaverでMacを起動してみた私はもともとMac使いで、5年前、時代遅れのiBookの遅さに耐えられずにUbuntuをインストールして以来のUbuntu使いだ。そのとき、一気にUbuntuに移行するのに確かにためらいはあった。いつでも逃げ出せるぐらいの腰の引けたUbuntuユーザーだった。それがしばらく使って、もう後戻りするつもりがなくなった。その決断を後押ししてくれたのが、SheepShaverだ。SheepShaverは、Macプラットフォームのエミュレーターだ。Mac、Windows、Linux上で動作し、MacOSの7〜9、つまりクラシック環境のMacOSをインストールできる。Macへの大規模な移行期だった。Macからはサポートされなくなる。それでもレガシーなアプリケーションを使いたい場面はある。そんなときに役立ってくれそうなのが、このSheepShaverだった。Mac上でSheepShaverをインストールすれば、その上にクラシック環境を実現できる。私は既に実験済みだった。同じSheepShaverがUbuntuでも使えるなら、MacからUbuntuへ移行してもそれほど困ることは起こらないだろうと思った。いう保険のようなものがあったから、Ubuntuへの移行に踏み切れたわけだ。ところが、現実はそういう安心感とは裏腹だった。SheepShaverはUbuntuのリポジトリにはない。ビルドするかバイナリを探してこなければならないのだが、当時の私にはいずれもハードルが高すぎた。IIがあって、こちらは(hardyまでは)リポジトリにある。ところがこちらは68Kマシンのエミュレーターで、必要なROMファイルがちがう。当時は6840搭載のLC475を使っていたのでROMを取り出すことはできたが、やはりまだUbuntu初心者の私としてはうまく動かすことまではできなかった。ひとつPowerPCのエミュレーターにPearPCというのもあったが、これはMacOSのインストールがとてつもなく難しかった。いうことで、「必要なときはいつでもエミュレーターでMacを動かせばいいや」と思っていたのに、実際には一度も実行したことがなかった。それでも何不自由なく過ごしてこれたのだから、Ubuntuはたいしたものだと思う。実際のところ、レガシーのMacアプリを使いたいと思うことはほとんどなかった。Xpressなんかでは既にどうしようもない時代にいるのは間違いない。過去を懐かしむことはあっても、実際に戻らねばならないことはなかった。自分が作成したデータに関しては、あまりに古いものはもともと使いようがないわけだし、新しめのものはOSXで作成したものだった。OSXはもともとがUnix系だから、データそのものもLinuxと相性がいい。おまけに、既にWeb時代に入っていたから、コンテンツのほとんどはWeb上に存在していたり、テキストファイルだったりした。データの移行に旧環境は必要なかったわけだ。SheepShaverのこともほとんど忘れていた。前、古いデータの見直しをした。これは、ちょっと事情があってコンテンツの量を確保しなければならなくなり、とにかく自分が著作権をもっていると主張できそうなものを洗いざらい並べてみる必要が生じたからだ。7〜8あたりをメインで使っていた時代にMacデフォルトのワープロソフトだったクラリスワークスで書いた文書がいくつか出てきた。これをUbuntu上で開くことができない。引越しの際にテキストデータに落としておけばよかったのだけれど、あまりに古い文書なのでその必要を感じなかったわけだ。Macで処理しようにも、最後のMacを先日手放したばかりだ。100%で送るパソコンライフの日常Ubuntuのある日々このブログはもともと「MacintoshでUbuntu」というタイトルで2006年にスタートしたもので、1年ほどたって別の場所に引っ越し、その際に現在のタイトルに改名しています。何度かの引っ越しを経て、ここにたどりつきました。今回、旧ブログもこのブログに合併し、カテゴリとして「MacintoshでUbuntu」として分類してあります。Ubuntuを使いはじめたその日から付けているブログなので、ずいぶんと古い記事が占める割合が多くなっています。そこで、ご覧になる方に、重要なお願いがあります。情報は古くなっている可能性が高く、また、私は決して専門家ではありませんので、内容をあまり信用しないでください。古いエントリで「あれができない、ここでトラブルを起こした」と書いてあっても、さらに新しいエントリで「あれは解決した」と書いてあることも多くあります。ブログ内検索も活用し、新しい情報で、なおかつそれを鵜呑みにせずに、自由な「Ubuntuのある日々」をお楽しみ下さいませ。私もubuntuです。すみません、取り乱しました。