コンピュータやソフトウェアのあれこれ@道民(&元道民)
WebbingStudio
This user hasn't shared any biographical information
Homepage: http://blog.webbingstudio.com
Posts by WebbingStudio
Gmailで予約送信できる拡張「Boomerang For Gmail」を試してみた
1月 29th
私は昔から睡眠のサイクルが崩れやすく、特に冬場は、夜中作業して午前中寝るようになります。
自宅で仕事をしている分には問題ないのですが、深夜や朝方にメールを送るとクライアントさんに
「遅くまでお仕事ですか…無理しないでくださいね(;ω;` ブワッ」
と心配されてしまうことがたまにあります。
夜中に先方の携帯が鳴るかもしれないし、カタギの皆さんにはご迷惑はかけられませんぜ…というわけで、できるだけ朝まで待ってメールを送るようにしていますが、一般の始業時間(10:00)まで起きているのは流石に辛いです。
で、Gmailで予約送信ができないかな…と思っていたら、ありました。
- Gmailの送受信スケジュールを管理してくれる拡張機能「Boomerang」が開発中 : ライフハッカー[日本版]
- Gmailに予約送信とリマインダー機能を搭載できる「Boomerang For Gmail」が便利*二十歳街道まっしぐら
「Boomerang」は、指定した時間にGmailを送信可能になるFirefoxとChromeの拡張なのですが、紹介記事ではきちんと検証がされていません。
Windows7版Firefoxと、MacOS版Chromeでテストしてみました。
まず、公式サイトからBoomerangをインストールします。
Firefoxアドオンの場合は、再起動が必要です。
Scheduled sending and email reminders | Boomerang for Gmail
インストールに成功すると、Gmailの画面の上にブーメランアイコンが出るようになります。
Google色になっているのがかわいいです^^
初回のみ、アイコン横のリンクをクリックして、アクセスを許可します。
…と、これで使えるようになるのですが
Gmailの言語設定が「English(US)」になっていないと以降の操作ができません。
Gmailに慣れていれば、インターフェースが英語でもあまり困ることはないと思います。
エラーになるのは予約設定をしたときだけなので、気になる場合は、Boomerangを利用するときだけ英語にして、普段は日本語に戻しても構いません。
通常通りメールを書いたら、
ボタンをクリックして、一旦現在のメールを保存します。
そのあと、通常の送信ボタンではなく
プルダウンから、いつ送信するのかを選択します。
「1時間後・2時間後・4時間後・1日後・一ヶ月後」などの他に、
「明日の朝(6:00)」「明日の昼(12:00)」「指定した時刻(At a specific time)」も指定可能です。
いろいろやってみましたが、どれもきちんと動作しました。
ただし「次の朝」などは時差の関係なのか、2・3分ズレるようなのでぴったりの時刻に送られるとは限りません。
設定後は、メールに専用ラベルが付いて待機状態になり、指定の時刻に送信されます。
(注:ラベルの色は変更しています)
ブラウザを閉じたり、端末を落としてもちゃんと処理されました。
さっきのブーメランアイコンをクリックすると、待機状態のメールの設定ができます。
予約時間の変更・取り消し・即送信ができます。
予約送信に関しては、だいたいこのような手順です。
他にも
「一定時間後に未読に戻る(アラートを使っている場合、通知もされます)」
「送信後、一定時間が経ってもレスがなければメールが戻ってくる」
という機能もあります。後者の方はまだ未検証ですが、予約送信とリマインダだけでも、かなり使い勝手はいいと思います。
「ちゃんと送信されるのだろうか…」とものすごく不安になってしまうので、重要なメールには使えないかもしれませんが、作業時間のコントロールができるようになるのは助かるので、積極的に使ってみたいと思います。
そりゃ、私が朝型になるに越したことはないのですが… _ノ乙(、ン、)_
Facebook。はじめるか判断する基準と細かすぎるポイント
1月 24th
Facebook創業者をモデルにした映画「ソーシャル・ネットワーク」を観てきました。
私も一ヶ月くらい前からFacebookをはじめているので、映画の感想はあっちのノートにアップしました。
Facebookのアカウントがあれば見られますので興味があればどうぞ。
友達登録は、会ったことがある人・札幌のFacebookユーザーに限定していますが、該当する方はお気軽に申請ください。
mixiが全く続かなかった私が、どういうわけかFacebookは割と気に入っています。
単に青系が好きで、スイーツ感がないからかもしれないですが。
今回の話は、一ヶ月くらい利用して考えた
Facebookをはじめるかを「判断する基準」と「細かすぎるポイント」についてです。
判断する基準
実名公開を避ける、日本人の場合ですが…
「便利さや利益のために少々面倒なことを厭わないか」
ではないかと思います。
私は興味を持つと面倒なことを平気でします。
電化製品を買うと、説明書に目を通します。
ゲームやWebサービスをはじめると、環境設定を開きます。
なので、Facebookでもプロフィールはほぼ全て埋まっていますし、通知やプライバシー設定もカスタマイズしています。
Facebookは能動的に機能を使うほど、楽しさが増していくように思います。
この段階で「めんどくせえええええええ」と思った方。ちょっと厳しいかもです。
どんどん細かくなりますよ!興味のある方のみ以降をどうぞ。
Twitterとの違い:交流のコントロール
Twitterをそのまま流している人がいますが、即やめた方がいいです。
全く意味がないし、設定でブロックされます。
Facebookは鍵付きのTwitterに近いです。
私の場合、こんな話題はあちらでしています。
- 趣味や娯楽の長話
- リアルなお仕事の話(守秘義務に反しない範囲で)
- 検索で拾われない方が良さそうな話
…あれ?エロい話は(ry
FacebookもTwitter同様、友達の数が一ケタだとちっとも面白くありません。
かと言って、友達をむやみに増やすと、ウォールには文字制限がなく、ファンページやコメントがバンバン流れてくるので、Twitterよりグダグダになってしまいます。
「全く知らない人を友達にしない」というのは、Facebookでも注記されています。
相手に交際関係・オンライン状態がわかることを含めても、友達承認をする範囲ははじめに決めておいた方がいいです。友達100人できるかな、くらいでちょうどいいのかも。
mixiとの違い:発言のコントロール
Facebookは、つぶやくたびに「公開範囲」を変更できます。
mixiでも「マイミクのマイミク/マイミク/マイミクの特別な人」という区分ができますが、Facebookは友達をTwitterのようにリスト分けして、そのリストの人だけにつぶやきを発することができます。
(foursquare・ロケタッチなどの外部サービスではできません)
普通の人はここまでやらなくていいです。私は公的な関係と私的な関係がいっしょくたになっているので、ときどきこれで調整しています。
その他のWebサービスとの違い:連携のコントロール
他Webサービスとの連携も少しずつ分けています。
- はてブ:参照している人が多いようなのでtwitterのまま
- Foursquare:twitterに流しても文字しか出ないのでFacebook
- 動画サイト:クリックですぐ観てもらえるのでFacebook(手動)
- Instagram:ナイスが欲しいので両方
- Flickr:写真にこだわりを持たないのでFacebookに切り替えようかな
Twitterでもあまりつぶやかないし…という人は私的なWebサービス置き場からはじめるといいかもです。
「いいね!」がもらえてちょっと嬉しいです。
ファンページ
先日、北海道開発オフのファンページを作りました。
何かの団体に属している人は、試しにファンページを作ってみてください。
「いいねの数」「いいねした人」「アクティブユーザーの数」などを知ることができます。
基本機能やファン同士の交流ならmixiのコミュの方が良さげですが、アプリケーションと連携させることでかなり細かいことができます。
うーんめんどくさいですね。私がめんどくさい使い方をしているだけですが。
この一ヶ月でだいぶルールが整理できてきました。
海外の人たちは、自分を晒すリスクより利益と承認欲求を重視して、ホイホイこの手のSNSをはじめます。
その代わり、セルフアピール・セルフコントロール能力に長けていますし
「出る杭は打たれる」文化があまりありません。
強固な理性、奥ゆかしさは日本人のいいところではありますが、21世紀ですし、冒険してみてもいい頃じゃないでしょうか。
特に、きちんとプロフィールを記入している人はビジネスでの信頼性が高いです。SOHOや管理職の人は積極的に使ってみるといいと思います。
映画みたいに、会ったばかりの女の子とあんなことやこんなことはできないと思いますがwww
第20回北海道開発オフ:ゲームの共同開発をしてみる
1月 17th

北海道開発オフが丸三年、20回目を迎えました。
メンバーの皆さんおめでとうございます。
これまで参加した皆さんありがとうございます。
20回記念ということで、今回は少し趣向を変えて、同じアプリケーションを違うプログラミング言語で作成する「共同開発」を行いました。
参加者同士でやってみたいことを相談した結果
- 一定ターンまで選択肢でを能力上昇させる「育てゲー」の設計
- Ruby on RailsチームとPython+Google App Engineチームでそれぞれ作る
となりました。
私はフレームワークを扱えないので、どうしようか…と思っていたところ、
参加者のわたなべさんから
「じゃあ、うぇびんさんは仕様に添ってゲーム画面作ってください。
HTML5とCANVASで。」
という素晴らしい無茶振りをいただきました。
こ、ここは期待されててなくても応えるべきよね!
うぇびんたん頑張ったよ!
成果発表(ゲーム画面)
ドラクエやWIZ風のUIにしてみましたが、CSS3のプロパティを駆使すればファイナルファンタジー風に変更することも可能です。
HTML5なので閲覧にはChromeかSafariを推薦します。
HTML5、CANVAS、プログラミングの勉強の素材にしてみたい方は自由にソースコードをご利用ください。
私もこれを使って、PHPでゲームを作ったらいい勉強になるかなと考えています。パラメーターなどの要素をTwitterのAPIと連携させても面白いかもしれませんね。
※「おむこ」というのはRuby on Railsチームのプロジェクト名です。
成果発表(開発側)
Python+GAEチームは、基本動作まで形になりました。
Ruby on Railsチームは、コマンドラインでのキャラ生成まで。
詳しくはsmokeymonkeyさんの記事をご覧ください。
次回からは、また普通のユルユル独習会になります。
開発オフという勉強の場があったおかげか、独習かCMSのカスタマイズでしかプログラミングを扱う機会がない私が、お仕事でPHP+MySQLの簡単なアプリケーションを作れるまでになりました。
これからも初心者が勉強会に参加できる気軽な窓口として、各種言語の技術者が交流できるハブとして、活動のお手伝いができればいいなと思います。
札幌で話題の勉強会「えにしテックカフェ」を見学した
1月 16th

北海道Rubyistの旗手の、新しい試みとは。
Ruby札幌の島田浩二さん(写真の人)が設立した企業「えにしテック」については以前記事にしましたが、
えにしテックが定期的に開いている小さな勉強会が「とても楽しい!」とTwitterで話題になっているので、ものすごく気になって見学させてもらいました。
一般のスクール形式をイメージしていざ入ってみると、参加者がちゃぶ台を囲んでジュースやお菓子を食べながら島田さんに質問をしているという、ユルユルな集まりでした。

今回のテーマはRuby愛好者に人気の、ソースコードの公開と共同開発ができるサイト「GitHub」について。
GitHubについてはこちらの記事を参考にしてください。
とっても優しい github の使い方 – ¬¬日常日記
参加者の一人が公開コードにバグを発見して修正パッチを作ったものの、コミットする方法がわからないということで、ちゃぶ台の上にある大きなモニターを通して、副代表の設楽さん(ばずったーの中の人)が丁寧に実演。
Rubyで「Hello world!」しか出したことがないレベルの私でも、他の参加者さんとゆっくり雑談したりして楽しめました。

えにしテックがマンションの一室ということもあり、
「偉いプログラマの講演を聴いている」
というより
「学校や職場の先輩の家で宿題を教えてもらってる」
ような雰囲気です。
島田さんたちが執筆した「レシピ先輩の本」を思い出しました。
21:00終了の予定が話が盛り上がり、一時間近くも延長に。
お二人の「ご来店ありがとうございました! :D」の声に送られて、えにしテックをあとにしました。
会話の中で、島田さんは何度も「オープンソースへの貢献」という言葉を口にしていました。
全国でも著名なRubyistながら、地元に拠点を置いて草の根的な活動を続ける、島田さんの性格を表しているようでした。
学ぶことを楽しむ。技術者の原点であると思います。
島田さん、設楽さんどうもおじゃましましたー^^
公開サイトにどのCMSが使われているか見分ける方法
12月 25th
フリーになってからご無沙汰していたので、久しぶりに前の勤め先にご挨拶をしてきました。
そのときに、私の後任の制作の人にこんな質問をされました。
「公開されてるサイトにどんなCMSが使われてるか、一発で見やぶる方法ないすか?」
実務でやっていると、使用されているCMSを調べたいという場面はけっこうあります。
CMSベースと思われるのに精密なデザインのサイトに出会ったときとか、新規案件の相談を受けたものの、現状サイトにどのCMSが使われているのか聞かされていない場合などです。
私が扱ったことがある、MovableType・WordPress・XOOPS・a-blog cms・SOY CMSに絞ってまとめてみます。
Firefoxの解析ツール「Wappalyzer」

「Wappalyzer」というFirefoxアドオンがあります。
これは表示しているページのソースを解析して、どのようなアプリケーションが絡んでいるか調べてくれるものです。主にGoogle Analyticsの有無などで使うようですが、MovableTypeやWordPress、XOOPSも対象になります。
ただ、あまりCMSに関する精度は高くなく、一部埋め込みや、根本からテーマを構築するような作り方をしたサイトは解析できません。
※ツールの名前を思い出せませんでした。川上さんありがとうございます。
MovableType
検索フォーム
どのCMSにも言えることですが、検索フォームが付いていればform要素周辺を見ることで、かなりの確率で見破ることができます。
サイト全体がCMSで管理されていれば、普通はCMS内蔵の検索エンジンを使うからです。
MovableTypeの場合、環境変数でパスを変えていない限り、検索エンジンのファイル名は必ず「mt-search.cgi」になります。
また、limitやincludeBlogsなどのオプションが引数で渡されています。
不自然な改行
MovableTypeは「ブロックタグや条件分岐タグの前後に改行が出力されてしまう」という仕様上の特徴があります。
プラグイン追加や、タグの前後の改行を詰めてしまうことで回避できますが、前者は再構築の速度に影響しますし、後者はコードの可読性が落ちるので、そこまでするコーダーはあまりいません。
このため、他のCMSで作られたサイトよりソースコードに余計な改行が多くなります。
新着情報の各エントリーの前後が二行以上開いていたり、head要素内に改行が多数存在している場合は、MovableTypeを使っている確率が高いです。
画像配置
MovableTypeで作成された新着情報などで画像が貼られている個所を見てみると、「mt-enclosure」というspan要素で囲まれていることがあります。
また、冗長なインラインスタイルが入っています。

WordPress
head要素
WordPressはMovableTypeほどコーディングの自由が利かないため、だいたいはWappalyzerで見破ることができます。
head要素にマニフェストファイルが自動リンクされるのも特徴的です。
また、METAの管理に「All in One SEO」を使用するのが一般的なので、これを導入しているサイトではhead要素のかなり下の方にdescription・keywords・canonicalがあります。
クォーテーションの混在
WordPressは不特定多数の手によって開発されてきたせいなのか、リストなどの自動出力部分のHTMLに、「シングルクォーテーション」が使用されている個所と「ダブルクォーテーション」が使用されている個所が混在しています。
なので、全体のコードをざっくり見てもなんとなくわかると思います。
XOOPS
検索フォーム
少し古いXOOPSのテーマだと、検索フォームに「xoops」という接頭語が付いた引数が指定されていることがあります。
div要素
XOOPSは、本文を囲むカラムのdivに「blockContent」classが付けられる慣習があります。
公式テーマがそうだからです。
~
また、通常コンテンツの管理には「pico」というモジュールが使われることが多いので、会社概要やプライバシーポリシーなどの本文上にpicoのアンカーが入っているかもしれません。
XOOPSは外部のモジュールを多数組み合わせて構築する性格上、どうしてもソースコードに一貫性がなくなります。
XHTMLとHTML4の書式が混在していたり、一部だけやたらインラインスタイルが使われていたら、XOOPSの可能性が高いのではと思います。
a-blog cms
a-blog cmsは、かなりわかりやすいです。
「特定のフォルダに入れたHTMLがそのままサイトルートに反映される」という仕様があるため、cssやjsなどのパスがかなり変わった相対パスになっていますし、パス内には必ず「themes」があるはずです。
また、head内に管理用のjavascriptが読み込まれていますし、METAのgeneratorも必ず入ることになっています。
<meta name="generator" content="a-blog cms v1.3.1" />
実際、中にどのCMSが使われているかというのは、運営側にはバレバレでもどうということはありません。
a-blog cmsはその分、管理しやすさを重要視しているということなのでしょう。
SOY CMS
今のところ、SOY CMSでできたサイトを見分ける方法はよくわかりません。すみません。
現状、既存のサイトにCMSを埋め込むような使われ方が多いので、ソースコードに特徴が出ないのです。
SOY CMS2ではa-blog cmsやJimdoと同様のユニット式が採用されるので、今後はクセが出てくるものと思います。
現状ではRSSが配信されていた場合、ファイル名が「feed?feed=rss」になっているというくらいでしょうか。
(SOY CMS2ではフレンドリーURLになります)
フォントが変わるとアイコンがずれる問題の対策
12月 7th
要素の先頭にアイコンを表示するときには、CSSの「padding」と「background-position」を使うのが一般的です。
a.pdf {
padding-left: 24px;
background: url(../images/parts/pdf_ico.gif) no-repeat 0 0;
}
ですが、対象がテキストリンクなどのインライン要素で、かつアイコンの大きさがフォントサイズギリギリだった場合
「フォントが『メイリオ』や『ヒラギノ角ゴ』だとちゃんと表示されるのに、『MS Pゴシック』だとアイコンの下が欠ける」
という現象が起きてしまいます。
これはWindowsのMS Pゴシックとそれ以外でテキストの開始位置が異なっているために起こる現象らしく、ブラウザ別のCSSハックでは回避できません。
また、最新OSのWindows7でも、ブラウザのデフォルトフォントは「MS Pゴシック」なので、閲覧者のOSやブラウザの設定によっては今後も引き続き対策をしなければいけません。
現状考えられる回避方法をまとめます。
1:アイコンの高さをフォントサイズより小さくする
当たり前っちゃあ当たり前なんですが…現状最も確実な方法ではあります。
だいたい3ピクセル以上小さいと、ずれはしますが欠けないようです。
2:background-positionのY値をem単位で配置する
background-positionは、二つ目の値が上下(Y)になります。
ここの単位を「em」にすると、「px」「%」よりはずれが少ないようです。文字サイズ変更にも追随します。
a.icon {
padding-left: 12px;
background: url(../images/parts/icon.gif) no-repeat 0 0.2em;
}
ただし、変動値になるのでCSSスプライトを使ってサーバーへのリクエストを節約するテクニックが使えません。
インライン要素のリストマークに対してはCSSスプライトは使わない方がよさそうです。
CSSスプライトで画像を円滑に表示させる | Webクリエイターボックス
下にpaddingを取る
本来、インライン要素はpaddingが無効になるはずですが、Internet Explorerでは有効になります。
それを利用してずれそうな分だけ下に余白を取ります。
a.icon {
padding-left: 12px;
padding-bottom: 2px;
background: url(../images/parts/icon.gif) no-repeat 0 0.2em;
}
ただし、有効なのはIEだけで、FirefoxやOperaだったりすると効果がありません。
4:要素をインラインブロックにする
現状で、最も確実に回避できる方法がこれです。
- a要素をインラインブロックにする
- アイコンの高さ分の行高さを取る
- テキストを縦中央にする
a.icon {
display: -moz-inline-box;
display: inline-block;
vertical-align: middle;
line-height: 16px;
padding-left: 12px;
padding-bottom: 2px;
background: url(../images/parts/icon.gif) no-repeat 0 0.2em;
}
要素がインラインではなくなるので、アイコンをフォントに関係なく中央に寄せることができます。
Internet Explorer 6にも対応しています。
ただし、行高さを指定してしまうため、二行以上のリストに対応することができません。
私が把握してるのはこれくらいです。他にないですか…(’д`)
インライン要素の行高さは、メイリオが特に顕著なようです。
bodyのline-heightを「1.5」などにすると、この辺の回避が難しくなります。
デフォルト値は「1.1」としておいて、要素別に都度line-heightを指定するのが、面倒ではありますが無難だと思います。
「a-blog cms Training Camp 2010 Autumn」に参加しました
11月 22nd
a-blog cmsの本拠地・愛知県で開催された、ユーザー同士の合宿に参加してきました。
a-blog cms Training Camp 2010 Autumn告知ページ
全国のパワーユーザーさんと交流できるなかなかない機会だし、開発の皆さんにいろいろ教えてもらいたいことがあったので、思い切っての名古屋旅行。
参加者33人。a-blog cmsの勢いを改めて確認する二日間となりました。
会場は愛知県の南端にある絶景の宿。
ここで実質24時間こもって、セッションやLTが行われます。
とりあえず、私が聞いてきたことをざっくりと。
次期バージョン(1.4)の新機能
ユニットごとのダイレクト編集
Jimdo、SOY CMSと同様の編集機能
カーソルを置くとハイライト→クリックで入力フォームがポップアップ→ユニットの一部だけすぐ編集
よくわからない人は、Flickrのタイトル・キャプション編集を思い出してみてください。
管理画面に増えた機能
- モジュールIDの複製
- カテゴリーの詳細設定画面で親カテゴリーを指定(新規エントリーからも可)
- エントリーのブログ間移動
- アクセスログの運用(CSVダウンロード・削除)
- 画像アップロードも必須項目に設定できるようになった
- どのブログに登録されているユーザーでも、設定したいで他のブログへログインできるようになった
その他の機能
- GoogleAPIによるサイト内検索
- パブリッシュ(処理に時間がかかるパーツだけ事前に生成しておく機能)
- ドメインエイリアス(設定により、異なるドメインで同じブログにアクセスが可能になる)
フィールドグループ
複数の項目を組にした、いくつでも増やせるカスタムフィールドを作れる
dtとdd、thとtdなどの表作成に便利
(5回まで等、繰り返し回数を制御することはできない)
ユーザーの有効期限設定
一定期間後にユーザーアカウントを停止させることができるようになった
(日付指定・xx日後等は現状ではできない)
マイクロページ
1エントリーを指定したユニット数ごとに数ページに分割できる、WordPress・Joomla等にある機能
アクセス制限
IP等、特定の環境からしか編集やログインができないようにできる
ナビゲーションモジュール
WordPressと同様のカスタムメニューが作成できる
現状バージョンの機能
セッションで聞いたこと以外にも、社長の山本さんや開発の皆さんにわからないことを直接教えてもらってきました。
カスタムフィールドを表示の制御に使う
モジュールIDの引数を「hogehoge/true」とすると
hogehogeがtrueの記事のみ表示される
ポストインクルード
内蔵のJSを利用して別のエントリーの情報を呼び出す(次のエントリーのカスタムフィールド等)
ユニットのテキストフォーマットを定義する
以前の解説で触れた「投稿画面の見出しは基本ではレベル3からだが、レベル1や2を追加することもできる」機能について。
よく使う飾り枠、二段組などのフォーマットの追加に加え、一覧ページと詳細ページで見出しレベルを変更することもできる
(とても便利なので、いずれ解説記事を書きます)
アクセスしたユーザーごとにテーマを変更する
プルダウンやラジオボタンなどで各ユーザーがテーマを選択できる
以降はcookieに補完され、自動で以前選択したテーマが表示される
他のCMSでもJavaScriptでCSSのみ切り替えるテクニックがありますが、a-blog cmsの場合はHTMLや投稿画面を含め、テーマをそっくり入れ替えることができます。
…他にもカスタムフィールドの詳しい使い方や、jQuery mobileとの連携などのセッションもあったのですがまとめ切れず。
とにかく密度の濃い二日間でした。
名古屋へ来たのははじめてのはずなのに、たくさんの参加者さんが私を知っていたのがなんとも恥ずかしかったです///
夜は産まれてはじめてのふぐ料理、翌日は伊勢湾の素晴らしい朝日を堪能しました><
「どの案件にも使える、パーフェクトなCMSはない」というのが私の考え方です。
設置しやすいとか構築しやすいとか、何かに特化すると他の部分が扱いにくくなってしまうのは当然だからです。
そんな中で、a-blog cmsは制作者・更新担当者双方への使いやすさを持った、利用できる範囲が広いCMSだと思っています。
このブログではチーム制作や担当者を分割しての制作に向いている、という表現をしてきました。
でも、ひとつのシステムで利用できる範囲が広いということは、CMSの学習に長い時間を割けないSOHO・フリーランサーとも相性が良いのだな、と、他のユーザーさんとの交流を通して改めて感じました。
私はまだまだa-blog cmsに関しては勉強中の身です。また札幌でコツコツ自習となりますが、これからももっと理解を深めて行きたいと思います。
a-blog cmsの実務制作(7)個別ページの作成
11月 18th
a-blog cmsの実務制作の流れをまとめています。
今回は詳細ページの作成についてです。
コード部分をSyntax Highlighterに対応させてみました。
CMSの独自タグは色分けがうまく行かないようだし、右上にメニューアイコンが出てこないんですが…まあ、前よりは読みやすいだろうということでお願いします…
WordPressだとソースコードが書きにくい…このブログもa-blog cmsに移行したいっす…
HTMLのファイル名について
a-blog cmsにはいくつかのデフォルトテーマがありますが、どのファイル名のHTMLを詳細ページとして扱うかは、テーマによって異なっています。「entry.html」が指定されているものもあれば、「index.html」で全てのテンプレートをまかなっているものもあります。
この辺りはテーマファイルの構成によって臨機応変に…となるのですが、今回は「entry.html」を詳細ページとして扱うことにします。
「カテゴリーのコードネーム」が付いたフォルダに同名のテンプレートがある場合はそちらを優先する仕様は、一覧ページのときと同じです。
なので、基本の詳細ページ用テンプレートをいちばん上の階層に作っておき、レイアウトが違っているカテゴリーのみ、フォルダ内に置いたテンプレートで上書きするのがおすすめです。
編集ページとユニット追加ページ
記事を書いたり編集できるようにするには、「編集画面」のテンプレートが必要になります。
またa-blog cmsの場合、見落としがちですが「一旦作成した記事にユニットを追加するときの画面」のテンプレートも必要です。
これも、テーマによっては「edit.html」「add.html」と別ファイルになっていることがありますが、だいたいは詳細ページと兼用することができます。
今回はこれらのテンプレートも「entry.html」とすることで以降の解説を進めます。
繰り返し・ブロック関連のタグを追加する
モジュールの開始・終了/エントリーループの開始・終了
エントリー詳細を表示しているページのうち、「タイトル」から「前後のページナビゲーション」までの範囲を、「BEGIN_MODULE」〜「END_MODULE」タグで囲みます。
ここでは全ての記事情報を参照できる「Entry_Body」モジュールを使用してください。モジュールIDは特に必要ありません。
また、詳細ページは記事を一回しか繰り返しませんが「entry:loop」タグも入れ子にする形で追加してください。
(エントリータイトル) (エントリー本文) (ページナビゲーション)
ダミーテキストを隠す
一覧ページのときと同じように、不要な文字列を「sample:veil」タグで隠します。本文を囲むくらいでいいのではと思います。
(隠したいダミーテキスト)
ページナビゲーション
新着情報などで前後リンクが必要な場合は、ページナビゲーションを「entry:loop」タグの外側に追加します。
これも一覧ページのときと同様、a-blog cmsの公式スニペットをそのまま利用して良いと思います。「BEGIN serialNavi:veil」〜「END serialNavi:veil」内が前後リンクを表示している箇所です。
以下は、私が自分のコーディングに併せて作った「serialNavi:veil」タグのサンプルです。ここもカスタマイズしたい方は参考にどうぞ。
<div class="page-navi"> <ul> <li class="pnavi-p">«{name}[trim(30, '...')|escape]</li> <li class="pnavi-i">%{CATEGORY_NAME}一覧</li> <li class="pnavi-n">{name}[trim(30, '...')|escape]»</li> </ul> </div>
※%7B・%7Dは「半角波カッコ」にしてください。
記事が見つからない場合
「notFound」タグで囲まれている場所は、記事が見つからない場合に表示されます…が、「404ページ用のテンプレート」が別途指定されていると、これは有効にならないようです。
「404ページ用のテンプレート」に「entry.html」を指定した場合は、「entry:loop」タグの外側に以下のようなコードを追加してください。
<h1>ページが見つかりません</h1> <p class="message">お探しのページはURLが変更されたか、削除された可能性があります。<br /> お手数ですが、ホームから目的のページをお探しください。</p>
記事情報タグを追加する
entry:loopタグ内の記事情報を、a-blog cmsの変数に置き換えていきましょう。
記事情報のタグに関しては、(5)一覧ページの作成の説明を参照してください。
ただし、詳細ページではグローバル変数「%{ENTRY_TITLE}」を使うことができるので、ページタイトル部分はこっちでもいいと思います。
本文にユニットを呼び出す
a-blog cmsは、本文を「ユニット」と呼ばれるブロックを積み重ねる形で表示します。
これらを表示するには、以下のタグを貼付けます。
「column:veil」タグは、エントリー詳細ページでは本文を、編集ページでは各ユニットの入力フォームを呼び出します。
「/include/column.html」は、「system」テーマ内の同じパスから呼び出されているので、新規作成したり、テーマにコピーしたりする必要は特にありません。
編集関連のパーツを呼び出す
このままでは、まだ記事の表示しかできません。さらに、エントリーの編集に必要なパーツを追加していきます。
記事のメタ情報
記事のメタ情報(タイトル・公開日時など)を編集するパーツを呼び出すには、以下のタグを貼付けます。本文のすぐ上が良いと思います。
保存ボタン・ユニット追加ボタン
編集画面で記事を更新したり、ユニットを追加したりするパーツを呼び出すには、以下のタグを貼付けます。これは本文のすぐ下が良いと思います。
「/admin/entry/edit.html」「/admin/entry/add.html」は、「system」テーマ内の同じパスから呼び出されているので、新規作成したり、テーマにコピーしたりする必要は特にありません。
インクルードを囲んでいる「adminEntryEdit」は「エントリー編集画面のみ内側のタグを実行する」という意味のようです。後述するタッチモジュールと似ているようですが、詳しいことはちょっとわかりません。
編集画面へ移動するボタン
保存ボタン・ユニット追加ボタンのすぐ下に、詳細ページから編集ページへ移動するためのパーツを呼び出します。
以下のコードを貼付けてください。
インクルードを囲んでいる「Touch_Login」は「ログインしているときだけ内側のタグを実行する」という意味です。
これが入っていないと、ログアウト後の公開画面でも編集ボタンが出てきてしまいます。
a-blog cmsでは、このようなページの状態による条件分岐タグのことを「タッチモジュール」と呼びます。
条件分岐をうまく使えば、テンプレート数を節約することもできますが、ソースコードがごちゃつきがちになるので、ご利用は計画的に。
タッチモジュール | a-blog cms – Web制作者のためのCMS
表示・動作を確認する
ここで一旦サーバーにアップロードして、きちんと詳細ページが表示されるか、編集が可能かどうかチェックしてみてください。
以下はよくあるトラブルシューティングです。
ユニット編集画面がうまく動作しない
- (4)共通のタグを埋め込むのときに、head要素にJavaScript・CSSを追加するのを忘れていませんか?
- 編集用のパーツを、ループタグの外で呼び出していませんか?
- 開始・終了タグの大文字・小文字を間違えていませんか?
編集画面が崩れる・文字サイズが小さすぎる・サイトの色調に合わない
編集画面の表示は、作成したウェブサイトのスタイルシートの影響を受けます。
たとえば、元のサイトのCSSで以下のような指定をしていると
table td {
font-size: 80%;
}
tdが入れ子になっている、a-blog cmsの編集画面の文字サイズがかなり小さくなってしまいます。
元のサイトのスタイルシートを調整するのがいちばんですが、かなりレガシーなマークアップで編集が難しいと言う場合は、入力フォーム用のCSSを調整する必要があります。
また、a-blog cmsの入力フォームは白系のサイトを想定したカラーリングになっているので、黒ベースのサイトで浮いてしまう、という場合も調整が必要です。
「system」テーマにある「/css/acms.css」をコピーして、作成したテーマの同じパスに置くと、CSSを上書きすることができます。CSSファイル内の説明書きを参考に、任意で編集してみてください。
編集画面で記事情報が変数のまま表示される
今回のように、詳細ページと編集ページを同じテンプレートにしていると、必ずこの現象が起こります。
日付などのEntry_Bodyの変数は、編集画面では変数のまま表示されてしまいます。
この場合は、タッチモジュール「Touch_NotAdmin」で囲むと編集画面で表示しないようにすることができます。
<p class="date">更新:{date#Y}年{date#m}月{date#d}日</p>
詳細ページ・編集ページの作成は、a-blog cmsのテーマ作成でいちばん難しいところです。
公開サイトに編集フォームを埋め込むという仕様のため、公開サイトのCSSを雑に書いていると、もろに編集フォームの崩れにつながってしまいます。
逆に、普段から計画的なコーディングをして、それぞれのタグの意味がわかっていれば、文字を大きくしてみる、不要なHTMLを消す、アイコンを出してみるなど、案件に併せたデザイン変更が自在にできると思います。
a-blog cmsの「Web制作者のためのCMS」というキャッチコピーは、このような特徴によるものなのです。
この記事で、構築に最低限必要なチュートリアルはだいたい終わりです。
今後は「ルール」「カスタムフィールド」機能などについて書いていけたらと思います。
大きな画像をCMSにアップしたときのことを、考えたことはあるかい
11月 14th

ネットをしているとよくある経験。
美しい写真がたくさん掲載されているブログを見に行って、何気なく記事中のサムネイルをクリックしたら、ものすごく大きな原寸写真が表示された…
最近の光回線に慣れっこで、ネットの経験が浅い人は「大きな画像をアップすると読み込みに時間がかかる」ことを理解できません。
これまで多くのCMSサイトを扱ってきましたが、
「更新担当者がデジカメ写真を原寸サイズでアップしてしまう」
という問題は、なかなか解決できないでいます。
その場合はWebサービスや画像縮小ソフトの存在を教えるのですが、CMSの操作の他に覚えなければならないことが増えると、やっぱりストレスになるようです。
私が扱っているCMSに高解像度画像をアップした場合、どうなるかを調べてみました。
MovableType
クリック後の画像は、原寸ママで表示されます。
表題の件で相談を受けたのは、MTの案件なので当然ですな… (´ー` 三
ですが「LightBoxプラグイン」を入れると、クリック後の限界値も指定可能になるらしいです。
LightBoxプラグイン(改良版)。 – Junnama Online
次回の案件から標準で入れようと心に誓う私でした。
尚、カスタムフィールドにすれば、最大サイズをmt:AssetThumbnailURLタグで固定してしまうことができます。
大規模案件などでこのような問題を出したくない場合は、本文に自由に画像を貼らせるのでなく、カスタムフィールドでの計画的な構築を検討した方が良いでしょう。
WordPress
WordPressも原寸ママです。↓↓↓↓クリック注意
まだ調べていませんが、シェアの高いCMSですから、限界値を管理するプラグインが出ていそうです。
a-blog cms
私がa-blog cmsをプッシュしている理由のひとつに、ユーザーのことを考えた細かい投稿画面設定ができる点があります。

a-blog cmsはクリック後の限界値をデフォルトで管理でき、PC用・携帯用で別途設定可能です。
また、モーダルポップアップも自動で行われます。
SOY CMS
初期バージョンでは画像の自動縮小ができなかったSOY CMS。
正直これが私にとって最大のネックだったのですが、バージョン2ベータでは、アップロード後に大・中・小の3サイズのサムネイルを作成するようになりました。
クリック後の画像へのリンクはやっぱり原寸サイズなのですが、開発元が私のTwitterのつぶやきを聞いて対応を検討してくれるそうなので、次のバージョンでは限界値が実装されるかもしれません。
Joomla!
最近改めて勉強をはじめた、中〜大規模案件向けのCMSです。
海外でシェアが大きいので期待していたのですが…
Joomla!は初期状態では画像の自動縮小もできません。
本文欄に巨大な写真がそのまんま貼り付けられてしまいました。
TinyMCEをエディタに採用してる時点でだめだろJK…
どうもJoomla!は、有志のプラグインを組み合わせることで真価を発揮するタイプらしく、いくつか公開されている画像管理プラグインを試す必要がありそうです。
WordPressと同様に、バージョンアップ後の不具合の可能性などを視野に入れなければいけないのは悩ましいところです。
Jimdo
無料で開設でき、直感的なUIで更新できるレンタルCMSです。
機能的には他のCMSと比べるとシンプルですが、画像をアップしたときの限界値がちゃんと指定されています。
クリック後の画像サイズは1024ピクセル×786ピクセルとなります。
実際に↓↓↓↓このページでやっているので参考にしてください。
そんなこんなで、開発元のみなさんには重箱の隅を突くような話で申し訳ないのですが。
クライアントはCMSに関して、特に画像を絡めたレイアウトに期待を持っているようなので、レンタルブログからは一歩進んだ機能を期待したいところです。
補足:a-blog cmsのおまけ
地味なことですが、a-blog cmsは画像を「中央寄せ」にしたときに画像の左右までリンク範囲が広がってしまったりもしません。
MovableType・WordPressの場合は制作側が中央寄せの場合のCSSを指定するのですが、自動出力されるタグの関係で、画像幅にぴったり添った状態で中央に寄せることができないのです。
(display:inline-blockでもだめでした…CSSでできる方法知ってる人がいたら教えてくださいorz)
a-blog cmsの場合、インラインスタイルで画像幅が入るので、制作側が特に何もしなくてもその問題を回避してくれます。













