コンピュータやソフトウェアのあれこれ＠道民（＆元道民）
WordPress
WordPressのユーザープロフィールにアイコンをセットする方法
2月 13th
前回の開発オフで教えてもらったことをメモ。
WPでは管理しているユーザーにアイコンをセットすることができるようである。
Wordpress3.3になってから（？）ダッシュボードの右上に「こんにちは、iarallyさん！」という表示が出るようになって、デフォルトアイコンなのが気になってきた。
そこで、いつものオムライスに変更…しようと思ったら、アイコン写真をアップロードする場所がない。
プラグイン必要なのかなーなんなのかなーと思っていたら、Gravaterと連携しているのでGravater設定をすればOKであるということを教えてもらいました。
対応としては次のどちらか。
- ユーザープロフィールの「メールアドレス」欄に、Gravaterで登録しているメールアドレスを使う
- WPのメールアドレス欄で使用しているアドレスでGravaterに登録する
あっという間にこのブログでもオムライスを表示できるようになりました。
@webbingstudioさん、@makiesさん、ありがとうございました！
達人プログラマー読書会@札幌-2011.08.23 に参加しました
8月 26th
8月30日(火)に、達人プログラマー読書会@札幌に参加しました。
今回は第2章 達人のアプローチ 9.可逆性 ～ 2章の終わりまで。
実際にプログラミングをするときに心がけておくべき事がたくさんありました。
9. 可逆性
変更に強く、柔軟に対応できるプログラミングをすることの重要性について。
柔軟で適合性のあるソフトウェアを目指すことは「変化を恐れない」ことにもつながりますね。
実際の仕事の時には「どこを変えれば対応できるか把握できている」「変更の可能性を常に頭の片隅に入れておく」とかが大事になると思いました。
重大な決定を行うたびに、プロジェクト・チームは小さな目標ー選択肢の少ない狭くて現実的なビジョンーに向かって進んでいくことになるのです。
「重大なことはさっさときめてほしい」「こんな大事なことを今覆すなんて…！」と思ったことがあるあるすぎて、確かにダメージの少ないように（リソースの許す範囲で）考えておくことは重要だなと思いました。
10. 曳光弾
プロジェクトは完了することがない作業である。
小さな動くものを作って、それを育てていくことの大切さが書いてありました。
Agile的な精神。
今、いろいろ読んでいる本のすべての種はこの本に書かれているんだなぁ、と改めて感じました。
目標をとらえるまで何度でも書く、ちょっと書いたコードが違うものでも落胆してはいけない。
ソースコードを書くことが目的ではなくて、ユーザーが求めるソフトウェアを作ることが最終目的、ということを再確認しました。
11. プロトタイプとポストイット・ノート
- プロトタイプは捨てるものである
ということがとても強調されていました。
たしかに、動くかどうか確認することを目的にしているので、わりとぐちゃっとソースコードを書いてしまうことが多いので、捨てるのが懸命。プロトライプが曳光弾になることもあるけど。
12. 専用の言語
実際に言語を作ったことはないけれど、
- わかりやすい名前をつける
- ユースケースを書く
- フューチャーのテストを作る
という今やっていることにつながることなのかな、と理解。
言語も含めて、どんどん発展していって、先駆者のおかげで幸せなプログラミングができているなぁと感じました。
13. 見積もり
現実のお仕事で最近色々苦労した部分でもあったので「ハッ」としました。
気づきをたくさん得られました。（現状の問題点を把握できたという意味の気づきも含めて）
見積もりとは何なのか、見積もりの粒度についてどうやって意識を共有していくか、そして確度の高い見積もりを出せるようにするにはどうすればいいか。
まずは自分の精度を磨くところから、やっていきたいと思いました。
風邪をひいて、第2回に参加できていない分を次までにちゃんとキャッチアップしておきたいと思います。
公開サイトにどの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になります）
大きな画像を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の場合、インラインスタイルで画像幅が入るので、制作側が特に何もしなくてもその問題を回避してくれます。
はてなスターを付けれるようにしました。
7月 26th
僕のこのブログはWordPressで運用していますが、以前は、はてなダイアリーでブログを付けていました。
ついさっき、こんなブログを書いたところ(LEDシリコンアサラトが届いた！)、はてなスターを付けたいと言ってくれた人がいたので、対応してみました。
はてなスターの設置方法は「はてなスターをブログに設置するには」というサイトに設置方法が載っていて、ほぼそのとおりだったのですが、HTMLの構造的な問題でちと苦戦しました。
外部ブログにはてなスターを設置する場合、HTML構造がはてなスターに合っていれば、簡単に設置できるようですが、僕のようにWordPressでデザインテーマを他から引っ張ってきた人間にはちと面倒があります。
まず、参照リンク先にある説明のとおり、JavaScriptを読み込むように、head部を編集しました。
$ vi /[Documentルート]/wp-content/themes/grey-matter/header.php
ヘッダ部(<head>～</head>)の最下部に以下を追記。
※順番が大事です。からなず最初にHatenaStar.jsを読み込むようにして下さい。
<script src="http://s.hatena.ne.jp/js/HatenaStar.js" type="text/javascript"></script>
<script type="text/javascript">
Hatena.Star.Token = '**********************';
</script>
Hatena.Star.SiteConfig = {
entryNodes: {
'div.content2': [ ←content2というクラスで繰り返される、
{ uri: 'h1 a',title: 'h1',container: 'h1'} ←h1タグに対してHatena Starを設置する。
]
}
};
僕が使っていたテーマでは、classで繰り返し表示されるようになっていなかったので、「index.php」と「single.php」の記事タイトルとなるh1タグをdiv.content2で囲いました。※ちゃんとコードなりなんなりを読める人ならもっと楽な方法があるかもしれませんね。
そして、Hatena Starの追加ボタンなどを表示させるためには、そのタグにリンクが貼られていないとだめらしいので、single.phpのh1タグの部分に対して、
<h1><?php the_title(); ?></h1>を
<h1><a href="<?php the_permalink() ?>" rel="bookmark" title="<?php _e('Permanent link to this post','grey_matter'); ?>"><?php the_title(); ?></a></h1>
という変更を加えて対応しました！
とりいそぎ自分用メモ的なです。