Apple, Photography, Stargazing, DIY, "Garage Life", F1, Fly Fishing
東側から見た「パーゴラ」側面図を作成しました。（木材はまだ加工していないので、変更になる可能性があります。）棟板なしのトラス構造です。接合部はシンプソン金具タイプレートとOSBガセットで補強する予定です。柱と桁の接合部は枘組みを考えています。2×4の垂木はバーズマウス切り込みを施して桁に載せます。垂木の全長が2,139mmになったので、8’の2×4材が必要になります。二本の短い小屋束と小屋梁は東西両端部のみ設置する予定です。屋根勾配を20ºから25ºに、軒の出を250mmから300mmに変更したので軽自動車を余裕を持ってパーゴラ内に駐車可能。
中間部では上の画像のようになります。トラスの構造計算はしていないのでどの程度の積雪や風圧に耐えれるか不明です。強度に問題がありそうなら、製作過程で方杖や筋交いなどの補強材を追加しようと考えています。この図面も使い慣れたiWork Numbersで製図しました。
南側から見た「パーゴラ」の側面図がほぼ完成しました。（屋根勾配を20ºから25ºに変更し、棟板をなくしたので、6月7日と6月8日に図面を差し替えました。）左（西）から右（東）に向かって下り坂になっている土地に建設しますが、勾配を計算すると僅か1.5ºしかありません。水平は沓石（束石）の高さではなく、柱の高さで調整します。具体的な数値は90mm角の杉材を立てて見ないとわかりませんが、図面では柱の高さは左から2,200、2,275、2,300mmにしてあります。
切妻屋根の高さは桁上821mmなので、束石上面から東側で最高3,261mm、西側で最低3,111mmぐらいになります。屋根勾配は25º、軒の出は300mm、2×4の垂木は566.2mm間隔で片面に11本、合計22本になります。棟板ありのパターンも考えましたが、トラスを地上で組み立ててから持ち上げて桁の上に載せた方が精確に作業しやすいので、棟板なしにしました。コメリのサイトによると、8’の2×4材で重さはおよそ2.9kgなので、トラスを組んでも一組で6~7kgだろうと思われるので、一人で持ち上げることが可能であると判断しました。垂木の間隔はガレージと同じ24″（およそ600mm）を基本に等間隔に配置すると、566.2mmになりました。
長さ3,000mmの杉材を試しに沓石の上に置いたら自立しました。柱底面が精確にカットしてあり、沓石が水平に埋まっていることを示すものです。作業はすべて一人で行う予定ですが、柱が自立するのなら固定するのはそれほど難しくないかもしれません。
ガレージ裏の空き地を有効利用して作業小屋を建てる計画が、母屋南側の細長いウッドデッキに隣接する「パーゴラ」の建築に変更になりました。法律上、建築物とは見做されない「パーゴラ」であれば、建築確認申請を行う必要がありません。しかし、「パーゴラ」に屋根を葺いた時点で「簡易的開放建築物」に分類されるので、建築基準法による制限を受けることになります。このような事情を鑑みた上で、少し迷いましたが、トラスを組み上げるまで、当ブログで進捗状況を公開することにしました。何らかの問題があれば、公開を停止し、「パーゴラ」を撤去する予定です。
iWork Numbersで作成した図面を元に、母屋南側の更地に「パーゴラ」のレイアウトを作成します。
遣り方に使用する杭は2年前にご近所さんのウッドデッキを撤去した際にいただいた余材と廃材を活用して製作しました。
母屋の布基礎を基準に測量しながら、自家製の杭を建物の四隅から少し離した位置に打ち込みました。次回は既設ウッドデッキのフェンスを撤去します。
Wood Carport — Part 2へと続く。
Kit Garage “Huron” Extending — Part 4に戻る。
納車10日後に初めて給油しました。Numbersで作成したファイルに走行距離（311.1km）と給油したレギュラーガソリンの量（18.50L）を入力すると、燃費が算出されます。
JC08モードでのカタログ値26.6km/Lに対し、気になる実走行での燃費は、16.8km/Lでした。納車前の点検や、納車直後の渋滞、途中でスタッドレスタイヤに交換したことなどを考慮すると、悪くはないと思います。
Suzuki HUSTLER A 2WD CVT Mileage — Part 2へと続く。
総走行距離：311km
永久にベータが外れそうにないiCloud Numbersなので、文句は言えませんが、一つ困ったことがありました。iCloud DriveにアップロードしたNumbersのファイルがSafariなどのブラウザーで開かないという問題です。応急処置として、Excelにデータを書き出して、Dropbox経由で共有することにしました。ここで不便に感じたことは、Numbersの「表」がExcelでは「シート」に変換されてしまい、ものすごく見づらくなるということでした。またチェックボタンやプルダウンメニューが適切に変換されないこともありました。
すべての共有ファイルが開かないわけではなく、また特定のiCloudアカウントで問題が発生しているわけでもなさそうでした。開かないファイルの多くはパスワードを設定していました。そこで、File > Change Password… で元のパスワードを入力してからRemove Passwordをタップすると、パスワードが外れて、ブラウザーでファイルを開くことができるようになりました。
解体、製作中のウッドデッキの図面（Plan 1）がほぼ完成しました。当初は図面なしで改修できるかと考えていましたが、解体し始めると結局、全撤去して根太と束石だけ再利用しながら大きさと形状を変更して、一から組み立てることになり、図面が必須となりました。
施主様の希望を最優先するには必要となる資材の発注と製作開始前に図面を見てもらって、より具体的にイメージできるようにしなければなりません。本来はSketchUpなど、3DのCADを使って製図すれば、完成後のウッドデッキを立体的にイメージすることができますが、使い慣れたアプリケーションが手元にないので、作成した図面は平面図になりました。
図面の作成にはApple純正スプレッドシート、Numbersを使用しました。Numbersを使って本格的な図面を引くのは初めてでしたが、表計算では使い慣れているので、製図にもすぐに慣れました。物差しの単位がポイント、インチ、センチメートルからしか選べない（ミリメートルが選択できない）ことや、ミリ単位でオブジェクトの配置やグリッドへの吸着ができたりできなかったりする、あるいは物差しを自由に移動できないなど、CADとして使い辛い部分もありました。ミリ単位でのオブジェクトの配置に関しては、座標軸に数値を直接、打ち込む必要がありました。
Numbersで製図する最大のメリットは、仕上がったファイルをiCloud Driveを介して共有できることです。家庭用プリンターでは印刷できない大きなファイル（縮小すれば数字が読めない）をOSプラットフォームに依存することなく、修正と改良を重ねた最新ファイルをブラウザーで閲覧することができます。施主様だけではなく、製作する人も現場で図面を見ながら作業ができます。iPhoneの小さな画面でも拡大すれば数字はくっきりと読み取れます。すべてのオブジェクトを一時的にロックしておけば、タップやピンチアウトの操作時にオブジェクトがずれることもありません。
ウッドデッキの製作工法に関しては、日本では束柱を二枚の根太で挟むサンドイッチ工法がより一般的に採用されるようです。モノマニアックな私としては、根太の枚数と束石と束柱の数が比例して、強度上、必要以上に束石が増えるサンドイッチ工法は避けたいと考えました。デッキ床面までの高さが低い（例えば、50〜60cmほど）場合は、屈まない限り、足元は良く見えないので、どんな外観でも強度面で問題がなく、製作が容易であればそれで良いということになりますが。
今回、改修するウッドデッキは母屋のログハウス土台の高さに合わせてあり、デッキ床面の高さが場所によっては1メートルを超える高床式になっています。足元が丸見えであり、必要以上に束柱と束石が多くなりがちなサンドイッチ工法を採用すると、資材に要する費用が増えるだけでなく、見栄えに関しても、たとえそれが裏庭に製作するデッキであったとしても、許容できないということになります。
解体中のデッキは、必要最低限で一列に配した束石と束柱の上に4×8の長い大引きを載せ、その上に比較的短い間隔で配した2×6の根太を直角に固定する「大引き工法」が採用されています。この工法は見栄えは良いけれども、重くて大きな大引きを水平に束柱の上に載せるのが極めて困難であるという製作上の大きなデメリットを抱えています。慎重に製作しても束柱と大引きの間に隙間ができてしまうかもしれません。解体、撤去中のデッキも、大引きが浮いているところがあり、1×4材端材で束柱の高さを調整してありました。浮いていないところも見栄えを揃えるために（粗を隠すために）すべての束柱と大引きの間に端材が取り付けてありました。この部分がサンドイッチになっていて不恰好ではありますが、新たに製作するデッキにもこの案を参考にしようと考えています。
本日、Numbers、Pages、Keynoteをアップデートしました。アップデートの内容は安定性の改善とバグ修正とのことです。ほぼ同時にiOS用のNumbers、Pages、Keynoteもアップデートになりました。
iCloud Driveが利用できるようにiCloudのアカウントをiOS 8経由でアップグレードしたら、iCloudにアップロードしてあるNumbersのファイルをiCloud経由で共有できなくなり、OS X Yosemiteにアップデートすることを促す上のような警告が表示されました。本来はiOS 8の公開と同時にYosemiteも公開すべきだったようにも思いますが… なんらかの事情で間に合わなかったか、意図的に遅らせたかのいずれかなのでしょう。
この警告を無視してこのままMavericls上でNumbersを含むiWork Appを使い続けると、iCloud DriveやiOS機器で編集したファイルがMacで自動更新されないので、思い切ってYosemiteのベータ版をメインマシンであるiMacの内臓起動ディスクにインストールすることにしました。
インストールしたYosemiteのベータ版は製品版一歩手前の最新版10.10 (14A379b) で、これまでのところ、安定しており、問題なく使用できています。アプリケーションがクラッシュすることもないし、Safariが若干、速くなったような気さえします。
iPad mini with Retinaディスプレイ購入時に無料で付いてきたApple純正のiOS Appである、iMovie、iPhoto、Keynote、Pagesが他の既存iOS機器でも無料でダウンロードすることができるようになりました。NumbersとGarageBandはすでに購入、ダウンロード済みでした。
iTunes App StoreやMusic Storeで同じApple IDを登録していると、購入した新製品だけではなく、前から所有しているiPhoneやiPod touch、iPadでも、インストールしているiOSが対応していれば、「購入済み」になるので、何度でもダウンロード可能です。
ちょっと驚いたことに、iOS 5.1.1の初代iPadでApp Storeを覗いてみると、最新バージョンのApple純正Appが購入済みになっており、インストールしようとすると、このiPadには対応していないけれど、旧バージョンで良ければ、インストールできるとの表示がありました。以前は有料だったPagesの旧バージョンを無料でダウンロードすることができる。iPhotoとiMovieはフロントカメラが初代iPadには搭載されていないという理由でインストール不可。
最新iOSバージョンに随時アップデートしているiPhone 5とiPhone 4では最新版のApple純正Appがすべて問題なくインストールできました。iPhone 4では快適に使えないかもしれません。
iWorkの表計算AppであるNumbersがiOS用とMac用の両方がアップデートされ、iCloudに保存した場合に非常に使い易くなりました。以前はMacでファイルを開くとレイアウトが崩れることがありましたが、アップデート後はMac用のNumbersがiOS用Numbersに近付いたためか、レイアウトが崩れるようなことはほぼなくなりました。
iPhoneで開いた上の燃費管理用スプレッドシートは左が入力フォーム、右が入力フォームに連動して自動的に生成される表。以前のバージョンと比べると英語フォントが綺麗になっており、給油時にガソリンスタンドで使う入力フォームがすっきりとしています。
Continue reading “Numbers for iCloud”
Apple純正スプレッドシート、Numbersをv.2.3からv.3.0へアップデートしました。今回は大幅なアップデートになっており、iOS版により近づいた印象があります。
シートの表示が左から上に移動していたり、別ウィンドーに開いていたインスペクターがフォーマットとフィルターに名称変更して、右サイドバーに移動していたりと、最初は戸惑いを感じるほどでした。一つ、慣れそうにないのが水平方向のスクロールバー。v.2.3の時はウィンドウを横方向に拡大すれば、水平スクロールバーが消えて、垂直方向にスクロールした時、左右に振れることはありませんでした。それが、v.3.0になって、横方向に拡大しても水平スクロールバーが消えず、垂直方向にスクロールすると、左右に振れます。この現象はiOS版のNumbersの特徴であり、使い辛いと感じていたものです。
スクロール時に左右にゆらゆらしても、テーブル（表）自体が移動することはないので実害はありませんが、ユーザーはちょっと気持ち悪くなります。私の設定が間違っている可能性があることは否定できません。水平スクロールバーが消せるようになるまで、垂直方向の移動はキーボードのPAGE UP、PAGE DOWNを使用することで、この問題に対処します。
Numbersを最新バージョンにアップデートしたことで、他にもちょっと困った問題が発生しました。新バージョンで自動保存したファイルがiWork ’09の旧バージョンで開くことができなくなったと言うことです。Dropbox上にある共有ファイルを新バージョンで開いてしまうと、旧バージョンを使用しているユーザーがファイルを開いて編集することができなくなりました。
幸い、iWork ’09（旧バージョン）のフォルダーにあるNumbers App (v.2.3)は、上書きされずにApplication Folderに残っているので、共有ファイルは旧バージョンで開き、編集することで、互換性の問題に対処しようと考えています。バージョンが異なるAppを編集するファイルに応じて使い分けるのは、ファイルのダブルクリックができないので手間がかかりますが、ユーザーが新バージョンにアップデートするか、iCloud上で共有ファイルの編集ができるようになるまでは、この方法で対応するつもりです。
OS X 10.7.2にアップデート後、Numbers 2.1の自動保存に関連する不具合が修正されたようです。8月2日付けのポストで、
しかし、MacBook (Late 2008)でNumbersのセルに入力しようとすると、Auto Saveが動きだし、挙動が一テンポ遅れるので使いものにならない状況です。同じファイルをiMac （Mid 2010）で編集する場合はそのようなことは起こりません。搭載メモリとCPU性能の差がスピードに反映されているのかもしれません。あるいはバグでしょうか。
上記のような不具合を書きました。この不具合はその後、iMac（Mid 2010）でも起こっていました。それが、OS X Lion 10.7.2にアップデートしてから一テンポ遅れて使いものにならないという状況が改善され、Snow Leopardの時と同じように快適に使用できるようになりました。
The document “FileName” is on a volume that does not support permanent version storage. You will not be able to access older versions of this document once you close it.
iDiskに保存してあるNumbers 2.1のファイルを閉じようとした時に現れたメッセージです。NumbersをLion対応の2.1にアップデートしてからSave As…がなくなり、代わりにSave A Versionになりました。上書き保存しようとしているだけなので、古いバージョンは不要です。iOS用のNumbersと同じような自動保存は確かに便利ではありますが、今一つ、私には使い方が理解できていません。
Dropboxに保存してあるファイルの場合は、上のようなメッセージは現れません。しかし、MacBook (Late 2008)でNumbersのセルに入力しようとすると、Auto Saveが動きだし、挙動が一テンポ遅れるので使いものにならない状況です。同じファイルをiMac （Mid 2010）で編集する場合はそのようなことは起こりません。搭載メモリとCPU性能の差がスピードに反映されているのかもしれません。あるいはバグでしょうか。