2015.03.29

jQuery iOSでもひよこを止めろ!

以前jQuery スクロールに付いてくるtopに戻るボタンという記事を書きました。
iPhoneでは謎の挙動で実現できなかった下までスクロールしたらfooterの他の物と重ならない位置に追随ボタンを固定したい。という望みが一応、叶いましたので備忘録として書き留めたいと思います。

ヘンな高さを算出してる問題

Mobile Safariの ’$(window).height()’で取得する数値が変なのよねーという問題だったようです。
当時は調べ方が悪く.scrollまわりのバグ?という情報しか拾えませんでしたが、scrollは関係なかったもよう。

正しいwindowの高さを取得するには、javascriptのinnerHeightを使うとのこと。

参考サイト:
jQueryでMobile Safariの$(window).height()の正しい値を得る方法 – memo.yomukaku.net

まるっと頂きました。

画像やAjaxを読み込む前に高さを算出してる問題

原因はもう一つ。
症状は止めたい位置にボタンがさしかかるといきなり画面上から消えてしまうというものでした。表示外のとんでもない位置に固定されていたんですねw 画像が全て読み込まれないreadyイベントの段階でdocument全体の高さを習得していたのも原因のようです。
画像を含めたページ全体の読み込みが出来たところで、documentの高さを.height()で取得するために
今回はjQueryの

を使うことにしました。

最初のスライド動作がぎこちなくなるものの、ボタンがどっかに行っちゃうことはなくなりました。

でもでも、画像の読み込み後の処理は別にした方が良くない?問題

これでいいかなぁーと思っていたのですが、既にreadyイベントの中で’$(window).on(‘load’,function{..’ を使っている部分があったのを思い出しました。
モバイルなどでは、ページ読み込み完了前にスクロールを始めることの方が多いかもしれませんし、ボタンのスクリプト自体はDOMの構築後発動してくれておもいっきり差し支えない訳で…
ボタンを止める位置のスクリプト部分のみ.onの引数のfunction内に書き直しました。

これでブラウザ共通のスクリプトになりました。iPhoneの分岐を書かなくてよくなったので、コードを少し減らす事ができました。
はーすっきり。

2015.01.11

今年はなんとなくやってきた

おくればせながら、新年あけましておめでとうございます。
hiyopan

今年はなんとなくやってきて、いつのまにか日常が始まっておりました。
なんの抱負もないのですが、これでいいのかもなぁ〜。
やれる事は気負わずさらっとやる。
そんな感じで行こうかと。

それに!ブログをいっぱい書く!それだ!
gitはあんまり使いこなせてないしw
jQueryの勉強はjavascriptからやろうとしたら頓挫してるしw
実は8月からブログ書いてなかったという…orz
ネタはたくさんあったはずなんですけど。

近況は椅子を買いました。中古なんですけど。
そんな事もブログに書けばいいのにね。

今年は健康を保ちつつ、ちょっと無理してみたい。さらっと。
みなさんの今年が良い年になりますように。

2014.08.31

腕時計の遊革が切れたので革ひもを編んで修理してみた

たまにはパソコンから離れて手作り方面の話題でも。
愛用の腕時計の革ベルトのループ部分(遊革)が切れて一年くらい放置してました。定革もへにょへにょで今にも切れそう。
teikaku
薄い革が二個無くなったくらいであきらめるには愛着があります。
アクセサリー作りに使っている丸革ひもを使ってリペアしました。
fin1
200円以内です。
わーい。十分使用できるし、ビーズのおかげでちょっと可愛いような気がします。

最初は革を買って切って輪っか作ろうと思ったのですが、レザークラフトの世界は奥が深すぎました。
1mm厚以下の革を探すのがまず難しい。革はカスタマイズで薄く漉くそうなんです。
ごつい時計だし多少の厚みには目をつぶって1mmの革でいいとしても、輪っかの重なり部分を接着するためには両端を斜めに削いで張り合わせるとか…
敷居高いわー
絶対しょぼい仕上がりになるに違いありません。
その点、革ひもならあんまり難しいことはないです。色が合わんくても質感がちがってもけっこうマッチします。

オリハルコンをつかわない簡単な材料

丸革ひも1mm幅 90cm使用(ベルトの幅2cm 革の厚さは3mm×2の場合)
天然石ビーズ

革ひもは楽天で1m90円でした。ちょっと色味が合いませんが。
逆にまったく違う色の革ひもとか異素材を使ってみるのもイイかもしれない。ビビットなオレンジとか蠟引きひもとか。緊急時?には荷造り用麻ひもとか…
天然石ビーズは6mmのスノーフレークオブシディアンを使用。直感力、決断力を高めますわよ。
fin2
ターコイズも良いですが、スノーフレークオブシディアンと革。すんごく合います。

たのしい作り方

ヘンプやコードでアクセサリーを作る人にはおなじみの平編みだけで出来ます。
hira_ami
左の紐から動かしても右からでもどっちから初めてもいいです。途中で左右分かんなくなったら、横のポッチが上に来てる側の紐を動かすです(図丸1’)。

1.
コードをコイル状に3回巻きます。
これが芯紐になります。ひもの左右の両端をここに編み込んでゆくです。
芯紐は1本でも2本でも3本以上でもいいです。数が多いほど幅の広い平編みになります。
knot_1
裏面が汚くてすまない。
ビーズを使う場合はコードにビーズを通してから巻いて、真ん中のひもに来るように。
stone
画像では角で縛ってますが、縛らないでいきなり平編みをする方がシームレスな仕上がりになります。編み終わってから気付いた。
縛らずに平編みから始める場合は上から革ひもが来てる側から編み始める。縛った場合はどちらからでも大丈夫。
平編みから始める場合、下側から来てるひもをどうすりゃいいんだい?って感じになりますが、こんな感じ。出演くま。
start
コードはかなり緩めに巻かないとベルトが差し込めなくなるだす。激しく意味がありません。
編み目の重なり分もあるけど革はある程度伸びるので、ベルトを重ねた時上下左右でコードが楽に一本づつ潜れる感じの弛みが要ります。
今回は一周くるっと平編みをしましたが、表面真ん中3目くらいで3本のコードをあえて見せるのもいいかもしれないし、その場合はもっときつく巻いてもいいかもしれない。

2.
編み進めます。
knot_2

ビーズのとこまできました。
toB

ビーズを巻き込んで平編み
knot_3
knot_4

3.
編み終わりはコードを編み目に差し込み引っ張りますよ。二目くらい潜らせるといい感じ。
きっついので抜けません。
loopend

4.
ちょっとひっぱりつつカット
cut

5.
でけた!装着!
finish

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”もだめ。

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

3 / 4112345...102030...最後 »
PageTop