2014.07.19

jQuery retinaディスプレイの画像を差し替えて生js多めで学習してみた。

MBPを買ってからというもの自分でも見えちゃうので、Retinaディスプレイでの自分のブログの画像の見え方、なんとかしたいな〜と思っておりました。
ご存知の通り、retina用に縦横2倍サイズの画像を用意して対策するのが良いようです。
便利なJqueryプラグインには及びませんが、いつものjQuery学習という事でタイトル周りとテンプレートのイラストとiconだけでも自分でなんとかしてみることにしました。

wordpressで投稿した画像などは未対応です。これはどうしようかまだ基本方針がかたまりませんも。

iPhoneはどうでもよくてよ!

別サイトを用意してないのでこのブログは大きいディスプレイとモバイルと共用です。
iPhoneに関しては基本、横幅1000pxの土台を縮めて表示してる訳なので、おおむね奇麗!
なるべく本文はiPhoneでも(ダブルタップで拡大されるブロックの幅調整で)見やすいようにしているつもり…という逃避w
へっぽこスクリプトも相まって画像で重くなるのもなんですし、
retinaディスプレイを切り分けて、なおかつiPhoneは除外しようと思います。

retinaディスプレイか否かはwindow.devicePixelRatioで判定。retinaは1よりも大きい数字を返すだす。
そんで、ifを入れ子にしてiPhoneかどうかを判定。

.searchメソッドは引数の正規表現が見つからない場合-1を返します。

よってこの場合、-1だったらiPhoneじゃないもんね!ということになるので、ここにiPhone以外のretinaディスプレイの場合に、画像を差し替えるスクリプトを書いてゆくだす。

差し替える画像は全部じゃないのよ…

とりあえず差し替えたい画像は、このブログで言うと

  • ブログのタイトルロゴ(img)
  • タイトルバックのイラスト(background-image)
  • 記事のタイトル h1,h2(background-image)
  • 小見出し h5(background-image)
  • リンク部分の背景(background-image)
  • Twitter用のオリジナルひよこアイコン(img)

ありゃー、imgタグによる画像挿入とcssのbackground画像と2パターンあります。うっ。
一括では行かないので先ず背景画像から何とかしてみたいと思います。

画像は従来表示していた物に加え、縦横それぞれ倍の大きさにした画像をめんどくさいけど用意しました。元データを残しといて良かったです。残ってないのもありましたが…。
2倍画像の名前の末尾に_rtiとか安易な文字を足して、replaceと正規表現でurlを書き換えます。@2とかの方がかっこいいかも。ふん。

なにからとっかかったらいいのか謎です。とりあえず背景画像(background-image)のurlを書き換える関数から作ってみることに。
$().eachはなんとか出来るようになったので、今回は苦手意識があったforで繰り返してみます。こちらの方がjavascriptネィティブで早いんだとか。

.lengthをその都度取りにいかない

ハイライトの所、i=0と同時に変数に突っ込んでおくと最初の1度で済み、より早いそうです。

一見、forやeachで繰り返し処理をしなくてもいいような気がするんですが、実際ブラウザでも各要素にstyleが書き込まれるけどエラーがでまふ。
replaceのところがundefinedになっちゃう。
複数あるh5だと最初のh5に対してだけのcssの’backgroundImage’のurlが変数に入り、次ぎからのh5のurlを拾えないからだと思うんですが、さて。

最初のeq(0)だけ拾って一括でbackgroundを指定できないの?どうなの?
と思ったのですが、例えばh5が無いページとか該当する要素が無いとやっぱりundefinedになっちゃい汎用性がありませぬ。
この関数の引数には色々突っ込むので、今回はおとなしくループをしておいた方が良いようです。

本題に戻って自作関数の引数(chunBacks)に入れているのは’$(セレクタ).トラバース’の要素を選択の部分。
retina振り分けのifの中で

とかすると呼び出されるという寸法です。

なんでもかんでも変数に入れたい病

引数に入れる要素’$(セレクタ).トラバース’を変数に入れて置きたくなりました。
何度も同じ要素を探しに行くことになるし、特に’dl.ref a’なんかclassからだし、効率が悪いような気がします。

にしたい。したいよー。

そして、backgroundの数だけこのretina関数を呼び出すのも少々うざいです。

で、今回、考えた末にこれらの変数を配列に入れて$.eachで繰り返してみました。
なんで考えたかというと、変数を$(‘#hoge,#fuga’)の様にコレとコレとする書き方が分からなかったのです(´・ω・`)。

配列を扱うにはこっちの’$.each’ってことで使ってみました。コールバックの引数にindexと値が受け渡されるので、直接valで値が渡せて便利です。

でもイケますがvalの方がスッキリ。
たしかに4回書かなくても良くなったけど、タイプ数は大して変わらない気もします。
いや、きっと対象が増えたら便利に違いない。違いないったら。

悔しいので利便性を追求してみる

配列の書き方をpushで追加方式に変えてみる。

新しいbackgroundが増えたら後ろにどんどん追加していけばいいし、見やすい気がする…
しかし、これだと要素を変数に入れてから配列に入れているので
↓ここにも変数を追加しなくちゃなりません。

めんどくさい…

オブジェクト(連想配列)にしてしまえば、個々に変数に入れなくてもいいような…一度の追記で済むんじゃ?
コンストラクタとかインスタンスとかまだ手が届かないので今回は追求しない方向で…

お名前付き関数を作りましたが、オブジェクトにすると$.eachのコールバックの引数、プロパティ名(key)とプロパティ値(value)が使えそうなのでeach内に書き直してみます。

firebagで確認するとfor文ブロックの中のvalにもオブジェクトmosBacksの値である$(‘セレクタ’)がちゃんと渡されてます。
10行目、後で上書きするしかないと思っていたところもif文でkey(プロパティ名)を比較して分岐が出来るようになりましたラッキー。(?)
よしこれで行ってみよう。

imgはどうなの

background-imageの時と大体同じ、srcを操作するだけですな。

今回はオブジェクトにブラケット表記[ ]でプロパティを追加してみました。ドッド演算子と書き方が違うだけで同じ事をしているだけなんだけど、書いてみるとなんとなく連想配列で値を取り出す方法も身に付くような?気がします。
ブラケット表記では中身を文字列として扱う。
変数も入れられる。
ちなみに6行目、for の引数の中で mkeyと変数を宣言しているので””で囲って文字列にするとundefined。
そして今度は$.eachではなく、練習の為にfor in文で繰り返してみました。

for in文はオブジェクトに含まれるプロパティの数だけ繰り返し処理をする。

順不同だけど今回の場合は全然問題なし。
backgroundの時の様に繰り返し処理をしなくても大丈夫。今のところimageは親要素に対してそれぞれ一個づつしかないしー、
複数個ある場合は繰り返さなくてはならんのであとで書き直しが生じるけど、今のところ大丈夫だしー。(ちょっと頭が追いついていません、すみません)

しかし!問題発生…(追記です。)全然大丈夫じゃなかった。がっくし。

該当するimg要素がないとundefinedになっちゃうのよ…

//2015/3 追記しました。
オブジェクトに入れたimg要素が全て揃っている時は上記の方法で問題ないのですが、ハイライト部分のimgを使わないページで、エラーがでます。

タイプエラーとな。

そもそもhtmlに要素が存在しないので、srcを取得をぶっ込んだ変数がundefined。変数を利用する文字列置き換えのスクリプトの部分が評価されず、後続の存在するimgのみならず後に読み込まれるスクリプトまでも止まってしまいます。うう。

img要素の有無を判定をして、continue的な事ができればいいんだけど…
for inだとどうやるのか分からないので、またjqueryの$.eachにお世話になります。…いいんだ学習だから。ごめん。

$.eachで処理を飛ばすには、こちらを参考に。

参考サイト:
jQuery::ループ内の continue / break [Tipsというかメモ]

ifの条件にしたい要素の有無判定をこちらを参考にさせてもらいました。

参考サイト:
jQueryによる要素の存在チェックまとめ: 小粋空間

書いてみる。

6行目、val(値)にはそのままセレクターを突っ込んであり、今の所セレクターに対応するimg要素は1個しかないのでimg要素が存在したら0番目の要素となります。
ifの条件”val[0]”でセレクターの0番目がゲットできたら処理。img要素が存在しなかったらelseとなるので、 return true(continue)で処理が飛ばされます。
しかし、やっぱり2個以上セレクターに対する要素が存在したらelseになるので、その場合はまた内部でforなりしなくてはならくなるかと。

余談だけど、なんでbackgroundの方ではh5など要素が無くてもエラーにならなかったのか疑問だったのだすが、eachの中のfor文の条件式によって処理が飛ばされておったのですな。
htmlに要素がない場合eachには’head{}’と空のオブジェクトが返ってきて、それに対して第2引数のfunctionが実行されるんだけど、中のfor文は条件式によってlengthが0の場合は実行されない。functionへの返り値は恐らくundefinedになるのかな?
eachの第2引数へfalse以外のfalse的な値が返ると要素の処理がスキップされるので結果オーライだったと…そ、そうだったのか。

eachに書き換えても存在確認の条件式が無いとタイプエラーになります。
「eachに書き換えたら、もしかしてこのundefainedスキップされるんじゃないの?」というイージーな思考が沸き起こりましたが、
このタイプエラーのundefinedは中の変数に対してであって、eachの第2引数のfunctionにundefinedが返ってる訳ではないのに早く気づくべきものでありました。(やってみた)

試行錯誤の末、全体はこんな感じになりました。

// 追記終了

iPhoneにもなんかしたくなった時は、elseの中に書いてやります。
background-imageのためのオブジェクトがifの外に出てるのは、elseでiPhoneの処理をしようと思ったときにスコープってんですか?届かないんですね。関数の中だけなのかと思っておりました。
image用もiPhone用の処理をするときにはお外に出してやらないとなりませんな。

imgにはwidthいるよね…取得できないよね…(力尽きた)

画像のサイズは2倍なので、表示サイズを指定しなくてはなりません。
background-imageだとbackground-size:containなど便利なプロパティがあるのですが、imgはそうはいかんのです。
スクリプトでどうにかしようと思ったのですが、cssに指定してしまったほうが精神的に良いという結論に落ち着きました。

Firefoxではうまく行くのだけど、safariで画像サイズが読み込みのタイミングでか取得できずページ遷移では2回に1回くらいcssの指定が0pxになってしまう。
ブラウザボタンからのリロードでもサイズが0pxに。もがっ。
srcには生のパスを突っ込まないとダメなのかもしれません。new Imageの引数にサイズも指定できますが、それらをやろうとするとcssに記述するのと同じくらいの手間になり便利さは薄い訳で…やーめた!( ´・ω・)。

やってみて

実際に当wordpressで使ってまする。へんになってたらごめんなさい。指摘してやってください。safariとfirefoxでしか見てません(・ω・;)。
今回はjavascript成分が多めの勉強になりましたが、関数リテラルとかオブジェクトオブジェクトとかコンストラクタとかインスタンスとかなにそれおいしいのワカメ?的なことのほんのとっかかりが出来たのでよかったです。
javascriptは難しいなぁ。jQueryがあってよかったよぅ。

2014.05.17

MAMP+WordPressのローカル開発環境にgitもプラス

必然というかWordpressも2台のMacで開発したくなってきたので、git管理下に置いてみることにしました。

と、言ってもMAMPで構築したローカルのテスト用Wordpressについてです。
公開サーバーがsshに対応してないのでリモートリポジトリもローカルLAN内に置きます。
テスト環境で仕上げた完全版をftpsで上げるという赤貧でめんどくさい清貧で健気な話になりますw。

めんどくさいというダメな理由で工夫をするのだ

git_wp_k
既にメイン機には、MAMPを使用したWordpress開発環境があります。サブ機にはありません。
Wordpressというのは普通のサイトと違ってデータベースがないと動かない訳ですな…
しかしサブ機にまたMAMPを入れてWordpress環境を構築したりするともう一つ環境が増えちゃう訳で…めんどう。
どうにかメイン機のデータを共有したい。そしてサブ機のブラウザからもプレビューできるようにしたい。

メイン機にあるWordpress用ディレクトリはDocumentRootにしてヴァーチャルホストの設定をしてあります。
サブ機で作業をした時、このメイン機のDocumentRootの内容を変更できればいいよねということで!
この元々使っているDocumentRootディレクトリをgitのposts-updateフックを介してサブ機から変更できるようにしたいと思います。

もちろん、本番用と開発用のブランチを使い分けねば危険。
リモート、ローカル共に常設のブランチを2つ用意しました。

  • ftpsの為の本番用ブランチ master
  • 作業&プレビュー用ブランチ develop

開発はdevelopで行い、決定版をmasterにローカルmergeするルールで運用します。

post-updateでブランチを分岐して、それぞれのブランチごとにremoteにpushしたら、ローカルwordpressディレクトリ(DocumentRoot)に自動でpullしてくるようにする。

  • remoteのmasterにpush、ローカルのmasterでpull
  • remoteのdevelopにpush、ローカルのdevelopでpull

管理する人間は一人なので同時にdevelopブランチを操作していることはないという前提です。
なんか落とし穴があるような気もしないでもないですが、とりあえずやってみることに。

Aptanaのせいで!めんどくさいけどWP専用.gitignoreを作る

WordPressやプラグインの追加・アップデートはブラウザからするので、gitで管理するのはthemes/自分のテーマディレクトリ以下になります。
もともとそこしか触った事無いもんね(‘A`)

なのでおもむろに自分のテーマディレクトリwasino-themeをgit initしました。
しかし、愛用のAptanaはプロジェクト/サブディレクトリのgitリポジトリをいっさい受け付けません。がーん。
Aptanaのターミナルは使えるけど毎度addとかcommitとかpushとかcheckoutとかmergeとか打ち込むのもめんどくさい。
どうやらAptanaのGUIでgitを使うにはプロジェクト単位でやるしか無いようです。

プロジェクト=Wordpressディレクトリ直下にローカルリポジトリを作成。
直接編集しないファイルは.gitignoreに追加して無視することで、オリジナルのテーマだけを管理することにしました。

さて、既存のWordpressディレクトリwasino-wpでリポジトリの初期化initしたあと、.gitignoreを書きました。

.gitignoreの中身はこんな感じ。

wp-*.php’で接頭詞にwp-が付いたphpは全部無視。
先に色んな階層にあるindex.phpを全て無視しているので先頭の’!’でテーマの中のだけ除外。
とにかく自分がエディタなどで編集しないものは全て無視してあります。
gitignoreの表記が正しかったかどうか一応、statusで確認しておきますた。

.gitignoreは別の環境でも使い回しますのでリモートに上げます。この段階ではまだコミットだけ。

リモートリポジトリはまだ無いけど、ローカルのコンフィグに設定しておきます。

次にリモートリポジトリを作ります。あ、すべてローカル環境での出来事です。

set upstreamを忘れずに

WPディレクトリに戻ってpushします。
警告がうざいのでmasterを -uオプションを付けてトラックしておきました。

デフォルトを愛しているので、pushの挙動をsimpleにしてあります。

simpleはカレントブランチをpush。同名のブランチがリモートにない時はpushしない。
詳しくはこちら。

参考サイト:
gitのpush.defaultに関するノウハウ
git の push.default 設定を理解する

このsimpleを使う為に設定したオプション-u(–set-upstream)が、めんどくさいからと始めた試みに知らず知らずに効いていた。便利さに感動。
というか、これをしていないと…

post-updateのpull先でbranchを分けるときにやっておくこと

post-updateをつかってbranchごとにpullする時、
pullする側でupstreamをセットしてないと、ぜーんぶmasterにマージされちゃう(`ェ´)ピャー

これが出来ないと、今回の目論みは全部失敗なのでぃす…

upstreamをセットするには、

push時に-uオプション付けてたら既にセットされてます。効いてる効いてる。

今回のテストで「ディレクトリごとにpullするpost-updata」テスト用一式を使い回して、全部masterにマージされて悩んだんですよね。
origin developって引数つけたからorigin/developにはfetchして来てる。でもdevelopにmergeするなんて明示してないから(´・ω・`)?
そういえばテスト用のはpost-updateでpullしてくるだけのディレクトリだったから、pushもしてないし、upstreamもセットってしたことないよね…
でもでも、config -lで見てもbranch -vvで見ても、merge先はセットされている。うっ。

push、pull共に

でset状況を確認できるらしい。
こちらを読むとpushはセットされてるけど、pullがセットされていなかったらしいことが分かりました。

参考サイト:
Gitでブランチをリモートに送る時の注意点 – rcmdnk’s blog

ん?remote show するとmergeの所にdevelopは無い…これかい。なんでローカルには設定されていたのか分からないけど。

よし!これでpost-updateでブランチを分岐させる&upstreamのセットで、無事にdevelopにpushしたらdevelopでpullが出来るようになりました。
サブ機側は、普通にremoteからcloneしてきます。upstream関連、デフォルトの挙動とsetを同じく設定する。

追記:と思ったら、pullする側のDocumentRootでカレントブランチにしかpullされません。(´・ω・`)
サブマシーンのdevelopからpushした時に、DocumentRoot側でmasterに居ると、fetchはしてるんだけどmergeされてない。出来た!と思ったんだけど勘違いだったのかなぁ…。
簡単にpost-updateでpullの前にcheckoutを差し挟む事にしました。

運用してみて

サブ機からは画面共有などでDocumentRootのbranchを切り替える術がないと、多少めんどくさい運用になりますな。
あと、サブ機からプレビューしたいばっかりに、こまごまとしたコミットが増えます。メリットもあるかもしれないし、rebase -i とかなんとか覚えなきゃならないかもしれない。(pushした後でのrebaseになるので、破棄前提のブランチを作り作業しなくてはならない。面倒。この実験した後、カレントブランチでしかpullできなくなったような気がするんだす…)

メイン機からpushすると、それをまたメイン機に自動でpullしてくることに疑問を感じるかもしれない。
特に警告もでないし、気にしない方向で…

おまけ '.' てなにさ!

remote: fatal: Not a git repository: ‘.’
いつも出てるむかつく致命的エラー
私の作った環境では、post-updateで –git_dir=.git オプションを付けているにも関わらず出ます。
普通にpullが成功しているだけにちょーイライラします。
GIT_DIR=”.git”もだめ。

でこの '.' ぽかーんとした顔見たいなのは居なくなりました。よかった。

2014.05.03

pen&touchで軽装備だけど重装備

モバイルもペンタブ欲しいよね。
という、新しいMacを買ったら連鎖的にいろんな物を買ってまうシリーズーぅ!な、訳で。父さん。
買いました。intuos。
intuos_c_pack
と言っても、以前はBamboo Funとしてラインナップされていた廉価機種なんです。現在はintuos pen&touchとかになってます。
そのコミックソフトバンドル版のintuos comic sというのを買ってみましたお。

機種からセレクト

一番廉価な機種に intuos penがありますが、今回これ↓は見送りました。

pen&touchとの違いはtouch機能がない、バンドルソフトが水彩LITE、ふぉと7(Windows専用)だけ。
それとペンのお尻に消しゴムがありません。
消しゴム機能そのものはソフト側の制御なので、無くても特に困りませんけど…
ペンのお尻の消しゴム機能割当に馴れきっているため、無いのは地味に不便そうだったので今回はpen&touchを選択しました。

サイズ選択とproとの比較で泥沼に迷う

本体はintuos Proと迷ったんだけど、wacomサイトがあまりにも見難い為比較検討するのがいやになり、いいじゃんpen&touchで一万円以内で買えるし!買えるし!と勢いでポチることになりました。

嘘です。ちょー比較しました。
前提に持ち運びがあったので、絶対Sサイズは譲れない線。
Mサイズは、MBP13incの一回り小さいくらいで、ほぼ同じ大きさ…デカっ。
頑張って持ち運んだとしても、出先でMBPとペンタブを広げられるスペースが確保できるか否か。コーヒーチェーン店の一人掛けテーブルではMBP置いて精一杯だろうし、そういった所では長居する作業もしないだろうけど…やっぱ大きすぎます。
やっぱりSサイズに決定。

そうするとproのSサイズという選択も生まれるわけで。
proイイよね!というか今回pen&touchを選ぶにあたってbambooとか使った事無かったので多少の不安が。
しかし、どうせproを買うならメイン機に欲しい。…メイン機で使うなら、今intuos3(Mサイズ相当)だしMサイズが欲しい…
当初の機動設定を忘れて、泥沼に陥りました。
そこで物欲を抑え、冷静に戻る。
Mac Bookではなんのソフトを使うんだっけか?
Illustratorを使いたくて、マウスやだなーと思ったのでした。
おお、やっぱりpen&touchでいいんです。危うく物欲に負けるところだった。

ペイント系のソフトで大きく腕を動かして描きたいという理由がなければ、モバイル用途やスペース苦心してまで大きいタブレットは必要ないと思いますお。
Illustratorのようなドロー系ソフトではタブレットの大小は問題にならないです。個人的には大きい方が不便な気がしないでもないです。特にマウスでの操作に慣れていると、操作ポイントまで遠いわーというという気がするかもしれません。慣れですが。

バンドルソフトからセレクト

通常のpen&touchには
☆Photoshop Elements11(ダウンロード版)
☆ArtRage 3.5 Studio(ダウンロード版)
が付いてきます。

えっ!いいなぁ〜!!
お小遣いが少ない学生さんはこのソフトで十分勉強になるよ。
わしの若い時にこんなソフトがバンドルされたものがあればなぁ。必死こいてPhotoshopと小さなペンタブ買ったよね。

Photoshop Elementsはphotoshopのさわりの勉強に凄くいいと思う。
実際、webだけしか扱わない会社ではElementsで素材バリバリ作ってるとこもあるし。
ArtRageは触った事ないけど、代表格でもあるPainterも含めペイント系のソフトって操作を熟知するってのは実はどうでもよくて、純粋に描くための道具だと思う。
ArtRageをググってみたところ描く事を学ぶには十分なソフトではないかと。

しかしわしにはすでにPhotoshopもあるし、painterもあるし…
線の補正機能があるソフトって使ったことないし試してみますかという事で!
未知のお絵描きソフトの入ったcomicエディションを選んでみましま。

pen&touch comicには
☆CLIP STUDIO PAINT PRO(ダウンロード版)(二年期限限定版)
というのと、あとは水彩とかMacでは使えないソフトが付いてきます。ブー!
Macで使えるのはCLIP SUTUDIO PAINT PROだけなので、外は割愛。

パッケージ内容とドライバインストール

intuos_c_in
画像に写っていない物はタブレットの裏蓋に収納されている替芯と替えの布製ペンホルダーとペンの黒い輪っかです。
左下はおしゃれな手編みの靴下を履いた私の足です。ごめん。
入ってるDVDはドライバインストール用です。バンドルソフトはダウンロードになります。
って、ちょっと通信速度が出なかったのでDVD入れてみてガッカリ。
ドライバ用も結局はダウンロードでした。
袋から出したり面倒臭いので、さくっとダウンロードした方が早いです。
Intuos (CTL-480、CTH-480、680)ってのです。
ダウンロードの際、対話モードのファイアウォールで見事にこけました。お気をつけください。

使用感とジェスチャー

セットするとこんな感じ。sサイズでも幅60cmのテーブルではぴっちりです。よし、想定的中。
intuos_pt_set
ついでに↑モニターに映っているのが、バンドルソフトCLIP STUDIO PAINT PROでの初描きだす。なかなかいい感じに線を補正してくれます。しかし、筆圧コントロールに訓練が必要な模様。

ペン先は芯が3よりも細いです。描いた感触はザラザラ感のあるタブレットのシート面でも滑らず引っかからずほど良いのですが、ペンの反対側消しゴム部分の感触が気になります。
一方向に動かす分にはいいのだけど、ゴシゴシという感じで使うと二度目のゴシで折り返す時に異様に引っかかりを感じ、ちょっと黒板キーッちっくで嫌です。

ジェスチャーついては、intuosのtouchを使うにあたって利き手側で操作ができるのはいいです。
MBPではトラックパッドを体の真ん中で操作しなくてはならず私としては少し使いにくい部分がありましたし。
ジェスチャーはMBPのトラックパッドに3本指ドラッグを割り当てた時と操作が同じです。
しかし3本指スワイプに馴れてしまっているので地味に不便w、操作を全く同じにするのであればMac側のトラックパッドの設定を変えて馴れるしかなさそうです。
も一つ不便なのがMission Controlをジェスチャーに割当られないことです。
仕方ないので、intuosのファンクションキーに割り当てました。
環境設定からタブレット→ファンクションキーでキーストローク 特殊キープルダウンの下から2番目でmission controlが選択できます。

気軽に始める、手軽に使うには良いペンタブ

入門機として、またはセカンドとして、選択するには満足できるペンタブレットです。
ただ当然ですが、intuos4 5からの乗り換えでは不満がでると思いますです。3からでもどうかな。

参考になるかどうかわからないけど、私はこのpen&touchと同じ筆圧レベルのintuos3 PTZ-630をメインで使ってます。
10年ほど前に発売されたペンタブですが、現在のproと同じ位置付けのモデルです。
スペックは
【PTZ-630】
筆圧レベル 1024
傾き検出 ±60レベル
読取分解能 最高0.005mm
読取速度 最高200ポイント/秒
読取精度 ±0.25mm

【pen&touch】
筆圧レベル 1024
傾き検出 なし
読取分解能 0.01mm
読取速度 最高133ポイント/秒
読取精度 ±0.5mm

と、pen&touchは筆圧レベル以外は古いproユースと比べてもスペック的に劣っておるです。
簡単に説明すると読取分解能はセンサーの間隔狭いほど精密、読取精度はペン先位置の誤差、読取速度は一秒間になんぼ読み取るか。

初めてのペンタブにproを購入するのは、もちろんありです。
一度購入したら何年も使えますし。私のPTZ-630は3台目ですが8年使ってます。
何年も使うつもりで購入する分には十分元はとれますw。
自分がどういったスタイルで描くのか、アナログで描くとしたら何の画材を使うのか。その辺に機種選定の目安があると思うです。

でも購入にあたってproは気軽じゃないんですよね。道具に振り回されるというか。
お小遣いを貯める時間を惜しんでpen&touchで描き始めちゃうという選択もおおいにアリだし、いきなり不満が出るペンタブでは無いと思う。
もし私の初めてのペンタブがpen&touchで、パソコンで絵を描き始めたのだとしたら十分に使えて勉強が出来るという感想を持ちましたの。

とか偉そうなことを言っておいて、MBPにもペイント系入れたくなってくる位にいい感じです。
モバイルのセカンドで使うにはもってこいですよ(`・ω・´)。

2018 新しいモデルがでましたね! クリスタ付きでワイヤレス!

旧バージョンは、コード邪魔でこれが欲しくなります。
が、バッテリーの持ちが悪くてねぇ。気づいたら放電してるんよ…あまりオススメできないw

2014.04.19

git-ftp 鵜呑みにできない備忘録

先生、鯖がsshに対応してません! gitでサイト更新ができません!

お得なレンタルサーバーではssh使えないこと多いですよね。
gitのpost-updateを使ってサイトの更新をデプロイできたら、いちいち更新したファイルを覚えてなくてもいいし…あ、css上げるの忘れた!とかもなくなりますしいいですよね。いーなーいーなー。
しかし、鯖をクラスチェンジする金はない。

でも、知っていたんです。
なんか調べてる時に見つけたんですよ。
git-ftpとかいうアイテムを。https://github.com/git-ftp/git-ftp

リモートリポジトリがレンタルサーバーに置けないとしても、更新箇所だけでも手動でアップするよりかは格段に便利な予感。
Aptanaのftpもちょー便利なんですよ!FTPSもSFTPも使えますし、いちいち更新ファイルを覚えていなくても「同期」で一括アップできますし、同期でもファイルの一覧から更新するかしないかも選べます。ちょとした手直しの更新なんてエクスプローラから右クリ一発です。
そこで、どっちがいいか使ってみようと思ってやってみました。
ちょっと色んな事が難しかったんで備忘録つけときます。

この記事のいい加減さ

たぶんちゃんと説明できてません。当記事は参考になりません。ペコ
git-ftpご利用の際はgit-ftp公式の説明をよくお読みになられますよう。
git-ftp.1.md
または、こちら。すごく参考になりました。

参考サイト:
Qiita git-ftp インストールと設定(Windows)
インストール

公式のインストールの説明書
Macです。
gitとcurlが必要ですがcurlコマンドは標準で搭載されているらしい。というか、要ると意識しないでやっちゃってました。
SnowLeopardではMacPorts使ってたのでopt/local/binに居るんですよね。
何にも小細工してないMountainLionではusr/binに居ましたがpathが通ってない模様。
この辺よく分からんちんなので、curlはMacPortとかHomebrewとかで落としてきた方がいいのかなぁと。
Portsで落としてきた方には、opt/local/shareにcurl-ca-bundle.crtも入ってましたし…難しすぎ。

ターミナルを起動。ホームフォルダに居ると思うので、そのままgithub.comにある公式からクローンしてくる。

#の所は入れなくていいです。
クローンしてきたらgit-ftpに移動。最新のタグにチェックアウトのちsudoでインストール。
sudoって緊張します。求められるPasswordはrootのじゃなく自分のです。表示されないので正確にタッチしてリターン。

私は最初に古い方の公式からクローンしてきたんで、新しい公式からはアップデートをしました。1.0.0-rc.1が最新だったけど、-rc.1ってなにさ?と思って0.9.0のタグからしましま。(アップデートもありUpdating using git参照
homebrewからもインストールできるようなんで、homebrew入れてたら楽そうでいいです。

git-ftpの設定とイニシャライズ

恐ろしいのでレンタルサーバーにtest用サブドメインを立ち上げました。

ローカルで、テスト用にあらかじめ作って置いたディレクトリ(index.html入り)に移動してgit configに設定をする。

初めてUPする時はイニシャライズのコマンドを使います。

これでftpで繋がりアップロードが始まります。

やっぱりftpsで繋げたいわーという所でコケる

やっぱFTPはこわいわーという事でFTPSで繋がるようやってみたところ大はまりんぐ。

今までもaptanaやあひるで設定していたFTPSサーバーのアドレスを入れたのに

initすると、そんなホストねーし!と怒りのこもったエラー(妄想)が返ってくる。

Aptanaのftpの設定を覗き見ると、SSL MethodのプルダウンでExplicit-AUTH TSL/SSLを選択してある。そういえば、そんな記憶もなきにしもあらずです。
公式のman pageを見るとURLの項目に

えっ!
どうやらgit-ftp内でftpes用のcurlオプションをつけてくれてるらしい。
試しに

としてみる。ポートはexplicitも同じ21を使う。

そしておもむろにイニシャライズ!init!
あっさりアップが始まりました。(∩・ω・)∩

ここまでの道のり実は相当長かったです…。
プロトコルの表記の仕方だのとは夢にも思わず、証明書のせいかと見当違いを疑ってみたり、知識がないので勉強になりました(´・ω・`)。
しかしAUTHコマンドのトラストストア?(勉強で仕入れた生半可な知識)って何を使ってるんですかね?←ォイ!
えーと、ログを見ると

あー、これ無いと自前で証明書とか鍵とかを用意しなきゃならないのかな?できんわーw
新しくセットアップする時はこれをチェックしてなかったら入れるようにしよう。

参考サイト:
MacPorts
MacPortsでvariants違いのパッケージをインストールする方法 | 富士山は世界遺産
homebrew
cURLのCA証明書 – There’s an echo in my head
手動
GITGITにしてやんよ | RONOR.org
決定版をアップロードしたい訳で。git hooks

いそいそと本番環境に適用しようとして気付いてしまいました。
うっかりdevelopとかの作業中のブランチに居るのに、masterに居る気まんまんでアップロードしたらいやだなぁ。
リモートリポジトリからpullだけをして来るgit-ftp専用のローカルリポジトリを用意したら安心なんじゃ?!ということで!!
そこで颯爽と登場するのがgitのフックであるpost-updateです。
.gitのhooksの中にあるpost-updateを使って、リモートリポジトリのmasterブランチにpushのタイミングで、git-ftp専用リポジトリからのpullを自動発火させます。

ほんとはこれ冒頭でうらやましがってたように、リモートリポジトリがレンタルサーバ上にあって、そのまま直に公開用リポジトリへ!だったら一番いいのですがねw
ま、贅沢は言いません。これでもかなり便利ですから。

参考サイト:
C-limber’s high: gitのブランチのpushで本番環境とテスト環境への反映を切り替える
gitでhookを使ってWebサイトの自動更新 | 半年前の私への教科書

最終データであるmasterブランチからgit-ftp専用ディレクトリへpullだけもよかったんですが、作業中debelopブランチのプレビュー用(ローカルサーバ上にview.local.com)もついでに作る事にしました。
まず、post-updateを作成。

中身。参考サイトさんを参照して、このような感じに分岐。書き方さっぱりわからん。まねっこ。

post-updateにリネームして保存。
post-updateに実行権限を付ける。

できた!これで安心git-ftp(∩・ω・)∩…でも、Lan上のサブマシーンからpushすると発火しない。
どこよ?ないよ?ftp_stagingとかに移動できないよ。と怒らりる。
うーんそうだよね。実行してるのは、別のマシーンでそのマシーンには/Users/ojiroないもんね。
否、プログラムを動かす実行権ないもんね…よく考えたらただのファイル共有でした。サーバもただのファイルサーバーだしw
ありゃーお手上げです。
masterとdevelopにpushするのは、メインマシーンからだけになっちゃいました。
いいんです…しばらく画面共有からpushしたいと思います。
もうちょっと勉強して、違うプロトコルから試してみようか否か( ´・ω・)。

追記:ローカルのマシン全部からpost-updateを発動させたい訳で…

#この記事を書いた人のリモートリポジトリはローカルのMac上にあるのです。
sshを使うことにしました。結局これが一番近道でした…orz

参考サイト:
Macにgitサーバーを構築してgit://(gitプロトコル)でアクセスできるようにする方法 | Macとかの雑記帳

↑こちらをすごく参考にしたらできました(∩・ω・)∩。ペコ

しかし、近道にもこんな障害が!
普段は文句言わないのにsshだと、git-receive-packが見つからないだとか→
~/bashrcで/opt/local/binへのpathを通す。(/opt/はMacPortsでgit-core入れた場合。)
私の環境の場合、~/.bash_profileで通してもダメで、~/.bashrcだと通る。
MacPortsを使ってインストールすると~/.profileにpathが自動で設定されるらしいんだけど、読み込み順位は~/.bash_profileより下。始めに見つけたやつだけ読み込まれるので.profileは読み込まれないことになる…色んなもののPathが切れちゃう。
それ以前に、sshでスクリプト経由の非対話モードだと~/.bash_profileが読み込まれないらすぃ…。
~/.bashrcで通ってるので現状これで好しとして、一応後学の為にenvironmentというキーワードをメモっておくだす。
pathを通すって人生で初めてやりますたよ。

参考サイト:
Mac を git の共有レポジトリにする — BONNOH FRACTION 14
Macで git push したら git-receive-pack: command not found のエラーが出たときの対処法 | わすれないように.
[ssh] ssh経由で他のサーバのスクリプトを実行するときに.bash_profileを読ませる方法 – It’s raining cats and dogs.

Permission denied (publickey,keyboard-interactive)だとか→
post-updateでpullする側のoriginのアドレスが間違うていたという凡ミスですた。
クライアント機とサーバ機を混同してssh経由のアドレスを設定してました。
私の場合はリモートリポジトリとローカルリポジトリが同機にあるので、/Users/ojiro/~ という素直なパスで良かったのでした。

webのみなさんありがとう〜

2014.04.15

ご飯が白いのよ!〜git branch

サイトを更新していて失敗することってありますよね。実験的に書いてみたスクリプトが動かなかったり、変更したレイアウトが気に入らなかったり。
今までは元に戻すためにこの地点までのバックアップをデスクトップに置くなどしてました。
しかし、居間でヌクヌクするためにgitを導入してから、元に戻すことを想定したバックアップが不要になりました。

なんとなく使えるようにはなった。けどなんかルールがいるよね?

色んな入門サイトをはしごして、なんとか自分のサイトをgitで管理できるようになりました。感謝。
しかし、2台のマシーンで開発するにあたってコンフリクトが多発w。ちょっと覚えたてのrebaseをいい気になってpush済みに使ってぐっちゃぐっちゃになってみたりもしました。
一人でやることといえ運用方針を決めておかないと「あれ?どっちのマシーンで何をしたっけ?あーコンフリクトぉぉぉぉ!」という泥沼に時間を吸い取られることになってしまいます。
そんで、こちらを参考に運用してみることにしました。

参考サイト:
見えないチカラ: A successful Git branching model を翻訳しました
ご飯が白いのよ!

とりあえず常時使うブランチは3つほどにして緩い感じで慣れて行こうと思います。

  • masterブランチには完全版しか上げません。
    常にdevelopブランチからしかmergeしません。
    常設のブランチ。
  • developブランチを開発に使います。
    常設のブランチ。
  • featureブランチは不安要素がある場合、もしくは進行してる作業に別案が出た時の比較をmaster,developからブランチを切り行う。
    mergeはdevelopのみに行う。臨時のブランチ。

A successful Git branching modelはもっと複雑で目的に応じた多くのブランチを扱います。こんな簡単じゃないです。やって行くうちにこのbranching modelの言わんとしてることが分かってくるかなと自分に理解できる必要な所だけ端折ったり統合したりしてみました。
でも、これだけ簡単な応用でもcheckoutとmargeの経路というか制限は非常に役に立つのではないかと思っています。
では、ひよこで想定してみたいと思います。

へびちゃんはdevelop界でひよこにごはんと納豆とネギとしょうゆを与えました。
nevaneva
失敗です。ねばねばです。しかもネギを可愛いがっています。ひよこに納豆ごはんの作り方を教えなかったからです。
neverboo
納豆だけを先に食べてしまったひよこは、ごはんが白いと食べられないと文句を言いますがへびちゃんは別にいいんじゃね?と思います。
何事も経験です。おなかが空いたら白いごはんもおいしいのです。

へびちゃんはdevelop界をそのままmaster界という現実にするつもりでしたが、ししちゃんは納豆は手で食べると大変な事になるということを学んだ上で正しい納豆ごはんを食べる世界にするべきだと思いました。
だいたい弟ひよこは納豆食べてませんし、かわいそうです。

しかし、もうdevelop界に納豆はありません。

そこで納豆を食べる前に戻る事にしました。なんたってししちゃんとへびちゃんは神様なのですから。

ししちゃんは納豆だけを食べる前の世界masterから亜空間featureを作りました。ここではまだ納豆は無事です。この地点から納豆を料理します。
nevacook
ひよこはなっとうごはんをたべました。
nevemogu
望ましい結果になったので、develop界の失敗をreset –hardの呪文でなかったことにしてもいいのですが、やはり記憶commitとして残しておくことにします。面白いし。
develop界で、記憶を残しつつ時を戻す呪文revertを唱え納豆を手づかみする前に戻り、時が戻ったdevelop界に正しい納豆ごはんを食べているfeature亜空間を融合mergeします。

develop界の納豆ごはんにもうまちがいは無いか確認して、完全な納豆ごはんを食べた世界を確定します。管理人的にはmasterにdevelopをmergeです。
ひよこはおいしく納豆ごはんを食べることができました。
ねばねばはもうかんべんです。

図にしてみる。
nebazu
結果(ひよこブーイング)が微妙なので、別の過程へ(納豆調理)進路をとり、結果(もぐもぐ)を比較して採用の流れ。

もし、masterにマージしてないコミットがあり、developからしか戻れない場合は

としてdevelopブランチの納豆が無事な所まで戻ってでfeatureブランチにチェックアウト。

蛇足ですが、最初このcheckoutが理解できませんでしたw
だって、checkoutってなじみ深い単語ですよね。ホテルの部屋をチェックアウトする。とかoutなんです。出てゆくんです。
masterブランチに切り替える時に『masterブランチをcheckoutします』という説明がけっこうあります。
えっ?今、masterに居ないんだけど?masterを出てゆくの?
ってなりません?

と脳内補完して覚えましたw

本家modelでは、リモートリポジトリに上げるのはmasterとdevelopだけなのですが、私一人用のシステムなのでfeatureもリモートに上げて、別マシーンでpullして作業の続きをしたりしてます。
実はローカルな構築でhooksを使う際にちょっと不便な点があったりして始めたmodelなのですが、なかなかいい感じです。

PageTop