出社した直後ぐらいからだるくなり、12時ごろに「もうこれはだめだな」と思い早退。
帰宅時点では37°ぐらいの微熱。悪寒がするので熱めの風呂に入ってからすぐ寝て、15時ぐらいに37.8°ぐらい。生卵をTKGとして摂取してひたすら寝つ続け、20時ぐらいに37.3°ぐらいまで下がる。それからまたひたすら寝て朝がたに36.5°ぐらいの平熱になった。
出社した直後ぐらいからだるくなり、12時ごろに「もうこれはだめだな」と思い早退。
帰宅時点では37°ぐらいの微熱。悪寒がするので熱めの風呂に入ってからすぐ寝て、15時ぐらいに37.8°ぐらい。生卵をTKGとして摂取してひたすら寝つ続け、20時ぐらいに37.3°ぐらいまで下がる。それからまたひたすら寝て朝がたに36.5°ぐらいの平熱になった。
布を切るといえば裁ち鋏でしょ??と思って思考停止していたけど、ローリングカッターを使ったほうが圧倒的に楽チンだった。
ただし欠点があって、一度に切れる長さはカッターマットの大きさに制限される。
裁断が結構気が重い作業だけど気が楽になるし、時短できるしチートアイテムっぽい。
アイロンで写せる型紙を購入したのだけれど、見ての通り色の濃い生地を買ってしまったので全く写らず (写ってるけど見えない)、チャコペーパーをひいてがんばって写した…… というか厚紙に型紙起こしなおしたほうがいいかもしれない。むずかしい。
キルティング地なのですこし不安だったけど、とくに問題もなく製作できた。
紐の通し口の処理が勉強になった。
布端のかがりを細かいジグザグではじめてしまったのでだいぶ時間がかかってしまった。とはいえ全体の作業時間は型紙写すのに試行錯誤した時間を含め2時間弱ぐらい。
これも保育園グッズの一つなのだが、保育園からの要求仕様には「コップ入れ」とか書かれておらず、どのぐらいのサイズが必要なのか、全くわからない。中に入れるコップのサイズが分からないのに、コップ入れを用意しろといわれる。世の中は厳しい。
保育園入園時に必要なものに、サイズ指定のグッズいろいろがあり、調達に悩んだ結果自作した話。
といった方法がある
習得も含めた時間などのコストと得られるメリットとのトレードオフになる。外注できるならしてもいいが
といった点を鑑みてミシンを買った。これ
トーヨー 電動ミシン レッド JY-1R cho45
実際に作る場合、ほかにもいろいろ必要なものがある。
ずっと裁縫道具は保存していたのでだいたいはなんとかなった。
大抵100円均一でも売ってるのでとりあえずはなんとかなりそう。ただ刃物系、糸切りハサミと断ちバサミはちゃんとしたのを買ったほうがストレスが少ないと思われる。
まず作ったのが布団カバー。1つあたり布が260cmぐらい必要なので、布代だけで 2000 円はかかる (800円/m だとして)
比較的簡単だと思うが、縫う距離が長いので時間がかかる。裁断からやってできあがりまで、1枚あたり2時間〜3時間ぐらいかかった。
つまり時給1500円でも人件費だけで3000円〜4500円かかることになり、オーダーメイドの工賃は十分妥当な金額とわかる。
なので、その金額を外に出すか、自分でその分の仕事をするかの選択になる。(前述の通り内製で処理することにした。気楽に自力でそれだけ稼げる仕事なんてなかなかないわけだし)
品質はともかく作ることはできた。自分の子供が使うのだから過剰に品質にこだわることもないだろう。
まだまだ作るのがある。たぶんコツを捕めば楽しい気がするのでがんばる。
自分でやるのとコストがあまり変わらない場合 (スケールメリットがないとか) で自分でなんとかできそうなことなら、自分でやるほうを優先したい。外注してもスキルは得られず金が減るが、自作すればスキルも得られて金が出ていなかない。なにより技術力はずっと残って財産になる。
Xcode 6.1.1 で Shortcut Recorder の 440a3d18e688142cd00fc88e4dc36ff355448fa6 を使ってみたらうまくいかなかった。
Xcode 上の Interface Builder で Custom View を追加し、Class を SRRecorderControl にすると、ビューがロードされてちゃんと表示される、という状態までは簡単にいけた。
しかし起動させてみるとグレーアウトされた状態になってしまった。これは enabled になっていないようなので、awakeFromNib で sr.enabled = true を付け加えた。これで起動させると、ひとまず動き、キー入力を受け付ける状態までは進むようになった。
しかし、キーを実際に入力しようとすると一切入力できず、無反応だった。これはどうやたら修飾キーまわりの設定が全くされていないとこのような挙動になるようだ。
結局 Shortcut Recorder のソースコードに println() を仕込みながら調べるハメになったが、デフォルトで設定されるはずのプロパティが一切設定されていないということがわかった。なので結局のところ自力で以下のようなコードを追加した。
inputHotkey.delegate = self
inputHotkey.allowsEscapeToCancelRecording = true
inputHotkey.setAllowedModifierFlags((NSEventModifierFlags.ShiftKeyMask | NSEventModifierFlags.CommandKeyMask | NSEventModifierFlags.ControlKeyMask | NSEventModifierFlags.AlternateKeyMask).rawValue, requiredModifierFlags: 0, allowsEmptyModifierFlags: false)
inputHotkey.enabled = true 該当コントロールのデフォルト値は initWithFrame: で行われているが、Interface Builder で配置したコントローラは initWithCoder: で初期化されるようなので、この処理が走らない。
Interface Builder 経由で置くことが想定されていないのだろうか。とはいえ README では IB で置けとも書いてあるし、よくわからない。
水曜日に体調不良で会社を休んだ。といっても自分は頭痛と身体がだるいというだけで熱はなく、妻が高熱を出したために主に子供の面倒を見る必要があった。
子供の熱からの両親ダウンというパターンだった。これ思いのほか厳しい。子供が元気になってから親が体調不良になると、子供はとにかく元気良く、相手をするのが辛い。
あと自分は普段離乳食を作っておらず任せっぱなしだったので勝手がわからず苦労した。レトルトもあったので使ったらよかったが、頭が働いておらず効率的な方法を描けなかった。普段からの訓練が必要とは思っていながらも、やってもらってると甘えてしまう。
書いてなかったけど保育園は第一希望で内定しました。既に入園検診済み。
園長面談(平日だけど両親参加必須)というのがどういうものなのか心配……
前にMacRuby でスクリーンキャスト用のキーストローク表示スクリプトを書いたんですが、それを Swift で書きなおして機能を追加したりしてアプリにしました。
基本的に AXSecureTextField への入力って、そもそもアクセシビリティのコールバックにこない?っぽいのですが、一部のアプリでは飛んできてしまったり、よくわからない挙動をします。
なので、こちらのツール側で、パスワードフィールドかどうかを判定して非表示に切り替えています。
と書くと簡単なんですが、実際一番やりたい Google Chrome ではデフォルトではアクセシビリティオブジェクトが生成されないみたいな罠があったり (VoiceOver が有効でなければアクセシビリティオブジェクトを作らない)、やっかいです。
あとよくやるパスワード入力といえば sudo ですが、ローカルについては sudo のプロセスが生きている限り自動的に非表示にするようにできるのですが、リモートではうまくできる方法が思いついていません (Terminal.app の画面内容をちゃんととれればヒューリスティックに判定できそうなんですが、screen 内だとそもそもとれないので諦めた)
github で公開しつつ Mac AppStore に試しに出してみたいなと思っていたんですが、そもそもアクセシビリティAPIで他のアプリにちょっかいを出すアプリは、Mac AppStore で要求される App Sandbox 内では正常に動作しないみたいなので諦めました。
つまりアクセシビリティ機能を向上するためのアプリ (Assistive app) というのは Mac AppStore では出せないってことっぽいですね。純正の VoiceOver でも使ってろってことなんでしょうかね。
Garage CL-147H というやつ (約24kg)。fantoni GT-147H というやつ (約34kg) のほうがかっこいいけど、高い。
天板の色が濃くて、丈夫なやつが安くほしかった。これはかなり満足してる。ウォールナットタイプは幕板がないので左右に揺れやすいみたいだけど、普段使いでは全く気にしたことはない 。
天板自体に鉄パイプで補強がしてあり、60kg まで耐荷重がある。最近のモニタは軽いのでまずギリギリになることはなさそう。ゆすろうとすれば揺れるが、キーボード叩きまくる程度ではほとんど揺れることはない。キーボードを叩いてモニタが揺れたりすると、案外かなりイライラしてくるので、机はできるだけ丈夫で重いのを買うほうが良いと感じる。
窓に背を向ける形、部屋の中のほうを向いて座っている。こうするとモニタを隔てて狭いスペースに身体が押しこめられるような形になって(狭くて雑然としているのが好きな自分には) 集中しやすい。
この配置だと家族と会話するとき後ろに振りかえる必要がない (ただしモニタで遮られているので相手か自分が少し動く必要がある) し、モニタで表示している内容をカジュアルに見られたりすることがないので、エロ画像を見ててもバレにくいというメリットがある (あんまり家で仕事しないけど、最悪自宅で仕事するときも都合が良い)。
中古 13000円ぐらいで買ったイトーキのプラオチェアというのを使ってる (前書いたエントリ)。現時点で全く問題に感じる点はない。新品でも5万円ぐらいで、アーロンチェアとかと比べたらかなり安いと思うけど必要十分な機能はあると思う。ただ、金が無限にあるならバロンチェアが欲しいです。
賃貸なので床にシートをひいている。これは今のところ不満はあまりない (ちょっと見た目が悪いとか、床にくっつきすぎるとかが不満) けど、本質的な問題は次に引越すときに出てきそうなのでなんともいえない。
Dell 4Kモニター 23.8インチ P2415Q(3年間無輝点交換保証/sRGB 99%/広視野角/IPS非光沢/フリッカーフリー/DP,mDP,HDMI/高さ調整/回転) cho45
Dell ディスプレイ モニター U2713H 27インチ/WQHD/IPS非光沢/6ms/DVI(DL),HDMI.DPx2(MST)/AdobeRGB 99%/USBハブ/3 cho45
をディスプレイアームで固定している。電子工作する関係でとにかくデスクの空いているスペースを広くとりたいので、モニタの本体はデスクの端よりも外に出るように設置している。
エルゴトロン LX デスク モニターアーム アルミニウム 34インチ(3.2~11.3kg)まで VESA規格対応 45-241-026 cho45
SteelSeries ゲーミングマウスパッド ノンスリップラバーベース 32cm×27cm×0.2cm QcK 63004 ブラック cho45
マウスはロジクールの M310 という無線マウス。手にあうマウスって案外すくないけど、これは使いやすい。
マウスパッドは Steel Series QCK。会社もこれ。ずっとこれ。最高。いちばん売れてるサイズよりもワンサイズ上かな? 小さくてもいい気はしてます。
今使っているキーボードは先日 @naoya_ito さんから頂いた HHKB Pro2 墨で、会社もこれを使ってる (少し前までは自宅では MacBook のキーボードを直接叩いてた) 後ろに「ナオヤモデル」って今度サインしようと思います。最近会うことがないので、自分で…
ソースコードではなく物理的なコード
デスクの裏に100均のワイヤーラティス(網)をつけているというのは前に書いたが、最近はこれまた100均で2個100円で売られているC型クランプを4つ使い固定するようにした。前まで両面テープで固定していたが、どうしても時間が経過すると落ちてきてしまっていた。クランプを使うことにより完全に落ちなくなったのである程度重さがあるACアダプタとかもデスク裏に置いておけるようになった。ref. 500 Can't connect to lowreal.net:443 (certificate verify failed)
配線ボックスに入れるよりは放熱性があるかなという感じ。机の裏のはじっこのほうは案外デッドスペースなので活用できると嬉しい。
C型クランプはこういう感じのやつ (100均のなので、これよりもっと安いけど)
アルミ C型クランプ 50mm cho45
Vertex Standard スタンダード HF/50MHz オールモードトランシーバー FT-450DM(HF・50MHz/50W) cho45
アマチュア無線関係の機器と電子工作用の機器が端っこに置いてある。前までデスクの上で置いていたけど、作業スペースを増やしたいので、別の棚の上に置く形にしている。
子どものときから、雑然としていて機械いっぱいに囲まれているデスクに憧れがある。昨今の風潮としてはモノは少ないほど良いというのがあって、まぁそれはそうだろうと思うし、なんか賢そうで良いと思うんだけど、それには逆行する形でいろいろ導入している。
測定器は憧れの最たるところで、とにかくかっこいいし夢が広がる。とはいえ現状では「必要に応じて」という原則をどうしても持っているので、自分のスキルレベルが上がらなければ新しい測定器の必要性が出てこない。
ものが増えると(特に家が狭い場合)保有コストというのがバカにならないので、あらゆるモノの導入には抵抗があるが、なんとかしてゴチャゴチャいろいろ置きたい。
Xcode のメニューから C ファイルをヘッダファイル込みで作ろうとすると Bridging Header を作るか? と聞かれるので、作るを選ぶと、*-Bridging-Header.h という Obj-C の(?)ヘッダファイルができ、作った C ファイルのヘッダファイルが #import されている。
あとはできた C ファイルに適当に書いて C ファイルのヘッダに適当に関数シグネチャを書けば、Swift 側ではプロジェクト内のグローバル関数として使えるようになっている。全部 Unmanaged だけど調べればほぼその通りうごいてくれる。
ただし一部の複雑な struct を書くと Swift のコンパイルで刺さることがある。自分は kinfo_proc を使いたかったんだけど、まんまとこの罠でハマって2時間ぐらい悩んだ。
takeRetainedValue()
→ 呼び出した関数内で値が retain されている場合こちらを使う。Swift 側でアンラップする際には retain しないでメモリマネジメントに加える。
takeUnretainedValue()
→ 呼びだした関数内で値が retain されていない場合こちらを使う。Swift 側でアンラップする際 retain を行いメモリマネジメントに加える。
とりあえず takeRetainedValue() を使い、問題が起こらないならそれでよい? もしヌルポが起これば takeUnretainedValue() に変えてみるとか?
Swift の参照カウンタのチェックポイントは関数脱出時のようなので、関数内で完結する分には常に takeRetainedValue() で取り出しても問題がおきない (勝手に解放されない) と思うが、よくわからない。
UIElementInspector は Apple が提供している開発ツールで、マウスカーソル直下にあるアクセシビリティオブジェクトについて、どんな属性と値があるかを表示してくれる。便利
https://developer.apple.com/library/mac/samplecode/UIElementInspector/Introduction/Intro.html
自分のアプリケーション (AXApplication ) の AXEnhancedUserInterface (bool) を調べて、1 が入っていたら VoiceOver が起動している。
Google Chrome はこの値を見てアクセシビリティオブジェクトを作るかどうかを決めているようで (パフォーマンスのため?)、デフォルトではアクセシビリティオブジェクトが生成されない。
自分で作ったアプリケーションでアクセシビリティを使いたい場合、これは不便な仕様である。必要に応じて
みたいなことが必要になる。
なお Google Chrome でアクセシビリティが有効化されているかどうかは chrome://accessibility を見ればわかる。また、上記 AXEnhancedUserInterface を設定しなくても、一時的でいいのならこのページでアクセシビリティを有効にできる。
有効にしたあとはページのリロードが必要、と思ったけど必要ないっぽい…
ちょいちょい「環境設定」→「セキュリティとプライバシー」→「アクセシビリティ」を開かせたいケースがあるが、openURL とかで Security.prefPane を開くだけだと「どこやねん」となりがちなので、アクセシビリティを設定するところまで一気に移動したくなる。
ScriptingBridge を使えばできるのだが、Objective-C でやる場合でもメソッド定義のヘッダファイルを生成して使うみたいな感じになっており、Swift からちょっと気軽に使おうと思うとダルくなってしまう。
フル機能を使うなら一度 Objective-C でラッパー書くのが正当だと思うが、一行も Objective-C を書きたくない気分のときは、プロトコルとエクステンションで必要なメソッドを強制的に定義してコンパイラを騙せば乘りきることができるようだ。
import Cocoa
import ScriptingBridge
// 元にないやつは optional にしないと extension でエラーになる
@objc protocol SBSystemPreferencesApplication {
optional var panes: SBElementArray {get}
func activate()
}
@objc protocol SBSystemPreferencesPane {
optional var anchors: SBElementArray {get}
optional var id: NSString {get}
}
@objc protocol SBSystemPreferencesAnchor {
optional var name: NSString {get}
optional func reveal() -> id_t
}
// protocol 定義を無理矢理使えるようにする
extension SBApplication : SBSystemPreferencesApplication {}
extension SBObject : SBSystemPreferencesPane, SBSystemPreferencesAnchor {}
struct Accessibility {
static func checkAccessibilityEnabled(app: NSApplicationDelegate) {
if AXIsProcessTrusted() != 1 {
let alert = NSAlert()
alert.messageText = "Require accessibility setting"
alert.alertStyle = NSAlertStyle.CriticalAlertStyle
alert.addButtonWithTitle("Open System Preference")
alert.addButtonWithTitle("Quit")
if alert.runModal() == 1000 {
openSecurityPane()
NSApplication.sharedApplication().terminate(app)
} else {
NSApplication.sharedApplication().terminate(app)
}
}
}
static func openSecurityPane() {
// openURL 使うのが最も簡単だが、アクセシビリティの項目まで選択された状態で開くことができない
// NSWorkspace.sharedWorkspace().openURL( NSURL.fileURLWithPath("/System/Library/PreferencePanes/Security.prefPane")! )
// ScriptingBridge を使い、表示したいところまで自動で移動させる
// open System Preference -> Security and Privacy -> Accessibility
let prefs = SBApplication.applicationWithBundleIdentifier("com.apple.systempreferences")! as SBSystemPreferencesApplication
prefs.activate()
for pane_ in prefs.panes! {
let pane = pane_ as SBSystemPreferencesPane
if pane.id == "com.apple.preference.security" {
for anchor_ in pane.anchors! {
let anchor = anchor_ as SBSystemPreferencesAnchor
if anchor.name == "Privacy_Accessibility" {
println(pane, anchor)
anchor.reveal!()
break
}
}
break
}
}
}
}
フルサイズ5060万画素
ところで以前レンズの理論上の解像度限界というのを求めたことがあった。これは、絞りを絞るほど回折によってボケてしまうという物理的な絶対的制約からくる解像度限界だった。
フルサイズセンサ (36x24mm) で 8688x5792pixel だとすると、画素サイズは 約 0.00414mm なので、F7 波長500nm でのレイリー限界 0.00427mm よりも細かくなる。
高画素数になるということは、より回折にシビアなセンサーになるということになる。ある程度よりも (この機種の場合 F7 程度) 絞ってしまえば、いくら高画素でも解像度はあがらないので意味がない。
実際のところでは、回折ボケよりも手ぶれのほうが厳しい場合が多いように思われるが、とにかく回折による解像度の限界を感じやすくなる。
高画素化することによって空間的なサンプリング周波数があがり、ナイキスト周波数(=サンプリング周波数の半分)も上げることができる。十分に高いナイキスト周波数 (具体的にはレンズの性能よりもセンサーが勝る=レンズがローパスフィルタとして働く) の場合、センサー直前のローパスフィルタを省くことで画質の向上をはかることができる (ローパスフィルタでは、ナイキスト周波数ぴったりで遮断するということはできないので、いくらか解像度が犠牲になる)。
画素サイズを(アスペクト比間違いにより)間違えていたので、いろいろ修正しました。