Lepracaun's factory - レプラコーンファクトリー -

代替できないプラットフォームに依存することの危険性

2010-03-06T14:18:15Z

iPhoneやiPodTouch向けのアプリを販売しているApp Storeから、相次いでアプリの大量削除が続いています。
いわゆる「お色気系」アプリから、今度は「Wi-Fi関連」アプリの削除です。

「お色気」アプリ・・・つまり「露骨な性的」アプリの削除は、主に女性ユーザーからの苦情や訴訟を避けるため、もしくは家庭用／子供向けアプリへの進出が理由であると考えられます。

「Wi-Fi関連」アプリは厳密には「PlaceEngine利用」アプリのようです。PlaceEngineを利用したアプリを削除の理由はまだ正確にはつかめていませんが、競合する技術「CoreLocation」を推進するためでしょうか？

]]> いずれにせよ、アプリ開発者・アプリ開発ベンダーは大迷惑・・・場合によってはビジネスの存亡に立たされるケースもあります。
アプリの仕様を一部変更するだけで再審査できるのなら、まだマシだと思います。
しかし仕様変更するにしても開発コストはかかります。
再審査できない類のアプリでしたら、最悪アプリ開発から撤退も余儀なくされるケースも想定されます。

しかも、AppleのApp Store運営方針の変更は、今後も起きる可能性が非常に高いです。
おそらく、何度も何度も起きるでしょう。
その都度、アプリ開発者・アプリ開発ベンダーは振り回されるわけです。

これがプラットフォームを支配しているものの「力」です。
以前、「マネタイズ研究室」の「iPhoneアプリ、ソーシャルアプリのコンテンツデフレを考える」でも書きましたが、「いま最も儲かるのはプラットフォームを確立できたところ」 です。
そして「権力」を握っているのもプラットフォームを確立できたところ・・・つまりAppleです。

Appleが、App Storeに掲載しないと言えば、アプリ開発者は何も文句は言えないのです。
否、文句は言えても、掲載を強要することはできないのです。

この手のアプリ系プラットフォームで現在最強なのは、App Storeでしょう。
ですが、Appleの性格を考慮すると、この手のリスクが最も高いのもApp Storeです。

Appleに振り回されるリスクを背負いつつ、Appleとともに行くか・・・
Androidなど、他のプラットフォームに移るか・・・
思案のしどころですね・・・

【参考サイト】

現時点で最高のオンライン版マインドマップ「EasyStep」

2010-02-28T11:55:15Z

今までもいくつかのオンライン版マインドマップツールをご紹介してきました。

しかし今回紹介するのは、「マインドマップらしさ」という点において、現時点で最高の完成度と思われる「EasyStep」です。

私の言う「マインドマップらしさ」とは、「直線的ではない」という点です。
以前にも申し上げましたが、「ブランチ（枝）を曲線をマウスで自由に描くことができ、枝の上のキーワードが枝の曲線に沿って表示される」ということが大事なのです。

]]> 技術上の理由で、この要素を満たしていないマインドマップツールは数多くありました。
実を言うと、今回紹介する「EasyStep」もSynapse（シナプス）とFlats（フラッツ）の2つのモードがあります。
http://www.easystep.jp/createMenu.html

Synapse（シナプス）は、Mindmap®により近いツリー図を作成・公開したい方向けのアプリ。
Flats（フラッツ）は、平らな線で表現するツリー図が作成できるアプリです。

私が評価しているのは、当然、Synapse（シナプス）のほう。
トニー・ブザン氏のザ・マインドマップを読まれた方ならご存知だと思いますが、キーワードはブランチ（枝）に沿って曲線で描かれるのが基本です。
直線よりも曲線の方が脳の思考力の発達を促すのだとか。

この完成度のものがオンライン上でできるようになってきたことがすばらしいですね。
「EasyStep」の技術力に脱帽です。

CMSの潮流が変わってきた・・・

2010-02-28T02:51:53Z

MOONGIFTで紹介されたたCMS「SEOTOASTER」を試してみました。

『その場でコンテンツを編集するSEO対応したCMS「SEOTOASTER」』の記事でもありましたが、私自身も最近のCMSの流れが確実に変わってきたことを感じ取っています。

SEOTOASTERも既存のCMSのようながっつりとした管理画面はありません。
右端にプルダウンメニューがあり、SEOまわりの設定などをします。
実際のコンテンツに関しては、修正したい箇所のアイコンをクリックして編集するのみ。
使い勝手としては、HTMLやCSSの知識が必須な感じがしましたので、初心者向きではなさそうでした。
しかしCMSのひとつのあり方として、大変参考になります。

]]> 「ひさびさの更新、そしてこのブログの方針について。」でも紹介しましたが、簡単ホームページ作成サービス「jimdo」を使って「マネタイズ研究室」を書いています。
「jimdo」も同じようなアプローチで、がっつりとした管理画面は無く、右端にメニューがあり、そこで各種設定をします。
コンテンツ編集は、編集したい箇所をクリックすると、入力編集フォームに切り替わるという手法。
印象としては、「SEOTOASTER」より「jimdo」のほうがスマートです。

そしてパワポのように使える無料HP作成サービス「Ferret Web（フェレットウェブ）」です。
こちらも試験的に使ってみてます。
謳い文句どおり、パワーポイントのようにコンテンツをドラッグ＆ドロップできます。
ただ、書き出すHTMLやらCSSが、猛烈に長いclassやidをズラズラと吐き出すのが微妙ですが・・・
こちらもCMSのユーザビリティとしては、方向性のひとつとして極めて関心が高いです。

私もよくオリジナルのCMSを作ります。
最近はその手の案件が多いです。
なぜ、MovableTypeやらWordPressなんかで構築したほうが手っ取り早いのに、わざわざオリジナルのCMSを作るのか？

それは「見たまんま編集」をしたかったからです。

私のCMSのやり方は、書き出すページのHTMLをそのまんま投稿・編集画面にも流用してしまうという手法。
書き出されるレイアウトのまんま、フォーム画面にするので、「見たまんま編集」に限りなく近くなります。

MovableTypeなんかも、徹底的にカスタマイズすれば「見たまんま編集」っぽくできますね。
Junnama Onlineでプラグインが紹介されていました。
おそらく、いろんな経緯があって開発されたのでしょうし、確実にニーズはあると思います。
この開発力には脱帽しますが、MovableTypeの本来の方向性とは違ってきているような気もします。

どうして、MovableTypeの本来の方向性と違ってきているような気がするのかというと、MovableTypeそのものがライトでシンプルなCMSを目指しているようには思えないからです。
とりわけこのブログをMT5にアップグレードした時に感じました。

ある程度大規模な企業サイトも構築する、ひたすら機能充実を目指すCMS・・・これがMovableTypeが目指している方向なのではないでしょうか？

「CMS Designer」というCMSの説明でXOOPSやMTとはどう違うのか？という説明がありました。
このCMSも「部品型」のCMSと喧伝しています。

「お任せ型」のCMSと「部品型」のCMS・・・うまい説明かもしれません。

私がやりたいのも「部品型」のCMSです。
既存のサイトに部分的に組み込んで、「見たまんま編集」ができる。
そんなCMSが私の目指すCMS。

そしてもっと大事なポイント。
デザイナー・クリエイターが使いやすい／覚えやすいのも重要ですが、もっと重要なのはユーザー（更新管理するクライアント企業／担当者のこと）が使いやすいこと。

「SOY CMS」なんかは、まさにデザイナー・クリエイターの学習コストを低くするという点を徹底しているような気がします。
これはひとつの方向性として、とても正しいと思います。
導入させる側、つまり制作会社のデザイナーが使いやすいものでなくては、なかなか導入は進まないでしょう。
デザイナー側の学習コストが高ければ、クライアントに提案する機会も減ります。

それよりも、もっと大事にしたい点。
それはクライアントの担当者が使いやすい（投稿・編集がしやすい）ということです。

「SEOTOASTER」や「jimdo」、「Ferret Web（フェレットウェブ）」のユーザビリティの考え方は、大変参考になります。
それぞれ使ってみて、どれもまだ一長一短という感じがしますが、それだけに研究の余地がありますし、逆に言うともっともっと完了したものを自分で開発できる可能性もあるわけです。

CMSは車輪の再開発で、これ以上やる意味が無い・・・
そう思った時期がありました。
でもそれは、「思考の停止」・「考えることの放棄」でもあります。
もっともっと研究・改良していく必要がある。
改めてそう思いました。

PHP用IDEとしてNetBeansが良い件

2010-02-28T01:40:12Z

最近PHP用の開発環境としてNetBeansを使っていますが、とても快適です。

クリエイター（デザイナー・プログラマー）は開発環境やオーサリングツール、エディタについて語るのが好きな人が多いです。
今回はPHP用の開発環境の話。

さて、今までもエディタについては色々書いてきました。
その中でもとりわけAptanaについては、ひとつのカテゴリを作っているほどです。
最近はあまりAptanaについて書いていないのですが、いまだに検索キーワード「Aptana」でこのブログへアクセスしてこられる方が多いのです。

PHPですが、皆様はどのような環境で開発されてますでしょうか？

]]> 「Aptana StudioでPHP開発環境構築」でも書きましたが、PHPには決定版という開発環境がありません。
テキストエディタでゴリゴリ書かれている方も多いでしょう。
画面作りのためにDreamweaverでそのまま書いている人もいるかもしれません。

ですが最近の潮流として、PDT（PHP Development Tools）がデフェクトスタンダード化しつつあるようです。
いろいろ紹介したAptanaも、PHPに関しては実はPDTです。

この世界、デフェクトスタンダードの流れに沿ったほうが、最終的にトクであることは事実。
ですが、このPDTには問題が。

「すごく・・・重いです・・・」

これはPDTが重いというよりも、Eclipseが重いんですけどね。
EclipseのPDTプラグインを使おうが、Aptana PHPを使おうが、ほとんど同じことです。

Eclipseが重い・・・だなんて、どんだけ貧弱なPCなんだ？とおっしゃる方もいらっしゃるでしょう。
会社でも自宅でも貧弱なPC環境であることは否定しません。
ですが、自宅のPCはともかくとして、会社のPCは簡単にアップグレードできないのが現状。

どういうふうに重いかといいますと・・・
起動が遅いのは当たり前として・・・
使っているうちにどんどん重くなります。
タイピングについてこなくなるくらいに重くなります。

実は今まで、さんざんAptanaとか紹介していたクセに、PHP書くときはテキストエディタ使ったりしていたことが多かったんですよね。
がっつり腰をすえてPHP書くときだけ、AptanaやEclipse＋PDT使っていたくらいで・・・。

ですが、最近PHPでCMSやらポータルサイトやらの構築案件が増えてきてしまいました。

まじめにPHPやり始めると、PDTといったIDEの構文チェックがありがたいです。
コード補完とかコードヒントもありがたいですが、一番ありがたいのがコード書いていてリアルタイムに構文チェックしてくれるところ。

もう一度まじめに開発環境を探し始めました。

「ん？NetBeans・・・！？」

そういや思いっきりスルーしていました。
なぜスルーしていたかというと、ずいぶん昔（NetBeansが出始めたころ？）にお遊びでインストールしてみて、あまり良い印象を持たなかったからです。

久しぶりにNetBeansのサイトを見てびっくり。
バージョンが6.8とずいぶん進んでいるのは当たり前として、サイトもなんだか洗練されているではありませんか。
PHP開発だけインストールするシンプルなものがあるので、ためしにインストール。

http://netbeans.org/downloads/index.html?pagelang=ja

「すごく・・・軽いです・・・」

え？マジ軽い。
NetBeansって、Eclipseより重いとか、モッサリとか、そういう話じゃなかったでしたっけ？
ぜんぜんEclipseより軽いし、使っているうちに重くなることもない・・・。
すみません、私の認識が間違っていたようです。

Aptana（つまりPDT）からNetBeansに移行して数ヶ月。
ここ数本のPHP案件はすべてNetBeansでやりました。

重くてどうしようもないPDTからサクサクNetBeansへ・・・ストレスフリーとはまさにこのことです。

どんどん多機能化していったEclipse（AptanaもEclipseベース）。
細かい設定だとか、そんなものを利用する方はEclipseが手放せないのでしょうが、私には高度すぎて使いこなせない機能ばかり。
NetBeansで十分でした。

そんな快適なNetBeansですが、今後において大きな不安要素を抱えているのも事実。
それはOracleによるSun Microsystemsの買収です。

MySQLとかもどうなるのか、かなり不安ですが、NetBeansも危機にさらされているのです。
MySQLは当然、Oracleのデータベースと競合製品。
もちろん、MySQLを使う層と、Oracleを導入する層は違うので、競合しないという見方もできますが、一部で競合するのは事実。
MySQLの開発を継続していくと約束したそうですが、ゆるやかに開発をクローズしていく可能性は否定できません。

話が逸れましたが、NetBeansの話。
NetBeansは、MySQL以上に存亡の危機にさらされています。
もともとOracle自身で「JDeveloper」という開発環境を持っていること。
そして、Eclipseにも支援をしてきたこと。
開発環境は3つもいらんでしょ・・・というのは当然の結論。

NetBeansはつぶすわけにもいかないので、放置する・・・これが私の現時点での予想です。

まあ、NetBeansの開発が停止したら・・・Aptanaに戻ります。
そのときは、PC環境もアップグレードできるでしょう。（と思う）

AppleとAdobeのFlashをめぐる攻防で思うこと

2010-02-21T02:03:49Z

最近、AppleとAdobeのFlashをめぐるバトルが激しいですね。
AppleおよびSteve Jobsが、Flashはバグが多いから云々・・・と言いがかりをつけていますが、あちこちで言われているように、FlashでiPhone／iPadアプリをオーサリングでてきてしまうと、App Storeを中心としたAppleのビジネスモデルが崩れてしまうから・・・というのが本当の理由です。

AdobeがFlash擁護に必死なのは、Flashをスルーされる流れが定着してしまうと、Flashのオーサリングソフトで儲けているAdobeのビジネスモデルが根底から揺らぐからです。

「Flashがスルーされる＝Flashクリエイターの減少、つまりFlashオーサリングツールの購入者が減る」ということを意味しています。

]]> もちろん、AdobeはFlashだけではありません。
PhotoShopやIllustrator、Dreamweaver、Premiere、AffterEffectsなど、DTP業界・WEB業界・映像業界のデフェクトスタンダードな編集ソフトをいくつも抑えています。
しかしこれらはFlashと決定的に違う点があります。

これらのソフトで編集・オーサリングされる対象（HTMLや画像・動画）は、Adobe固有のものではない。つまり代替が利くものばかりです。

『「なぜAppleはiPadにFlashを載せるべきではない」のか』という記事に、HTML5のオーサリングソフトで、Adobeの今後生き残る道を示唆されていました。
まさしくそのとおりだと思いますが、HTML5はAdobe固有のものではありません。
つまり磐石のものではないのです。

『「AndroidならFLASHやAIRアプリが動く」、米アドビが実演』という記事なんかを読むと、Androidに活路を見出していくつもりなのかもしれませんね。

ですが、そのAndroidを開発したGoogleはHTML5推進派です。
Androidはオープンソース（ただしコアな部分は除く）なので、iPhone・iPadほど障壁は無いと思いますが、不安な要因であることには変わりありません。

さて、大手ゲーム会社までアプリを連発して提供し始めたiPhoneおよびiPad向けにアプリの件です。
iPhoneおよびiPad向けにアプリを開発しようと思ったら、次の条件を満たす必要があります。

アプリのオーサリングには、Mac OS Xが必要。
- →WindowsやLinuxでは基本的にできません。
Objective-Cを覚える必要。
- →後述する、「Adobe Flash Professional CS5」とか、HTML＋JavaScriptでiPhone/Androidアプリを作れる「Titanium Mobile」とか、いろいろ回避策はありますが、基本的には必要です。
App Storeの審査を通らなくてはならない。
- →最大のポイントはここです。

じゃあ、なぜ、App Store以外でアプリを配信できないようにするのか？
以前、「アプリ配信プラットフォームについて」という記事について書きましたが、一言で言うと「今もっとも儲かるのが、プラットフォームビジネスである」からです。

コンテンツデフレと言われる昨今ですが、コンテンツだけでなく、インフラも、ハードウェア（端末）も儲かりません。
唯一儲かっているのが、プラットフォームビジネスです。

Google、Yahoo!、mixiやGREE・モバゲータウン・Facebook、楽天やAmazon・・・
業績好調なのは、どれもプラットフォームを提供している企業です。

今、勝ち組になりたかったらプラットフォーム・レイヤーに属するしかないのです。

ネット帝国主義と日本の敗北―搾取されるカネと文化 (幻冬舎新書)という本を読むと、そのことがとてもわかりやすく書いてあります。

もちろん、このルールは未来永劫続くわけではありません。
ですが、ここ数年はこの現象は揺らがないでしょう。

プラットフォーム・レイヤーのビジネスモデルの研究は、「マネタイズ研究室」でさせていただくとして・・・

ここでApple vs. Adobeの戦いに話を戻します。
ぐっと視点を低くして、我々クリエイターとしてどうすべきでしょうか？

ゴールドラッシュの時期を過ぎてしまった感もあるけど、まだまだ熱いiPhoneアプリのクリエイターを目指すか？
Flashクリエイターとして、Adobeとともに生きていくか？
いや、Androidアプリに活路を見出すか？
HTML5の普及に期待して、iPhoneもFlashもそれほど本気にならず、適度な付き合いに留めておくか？

各クリエイター各々の判断が問われるでしょうね。
ただし、いずれにしてもこの先30年間通用するスキルなんてものはないのです。（30年後もクリエイターでいるかどうかは別として）

私はどうするのか？
Flashクリエイターの端くれとして、さらにFlashを極め、Adobeと共に生きる？
今から猛勉強して、iPhoneアプリもしくはAndroidアプリ作成技術を極める？

現時点での私の答えはいずれもNoです。
コンテンツデフレの昨今、今後数年間はコンテンツクリエイターで稼ぐのが難しいという現実が見えている状況です。
さらに、どの技術も将来的にはHTML5で代替されるような気がしています。
ただしそれは数年～10年間はかかるでしょうけど。
そしてクラウド技術の発達によって、サーバーサイド側の技術のほうが重要になってくるような気がしています。

HTML5＋サーバーサイド技術を追いかける

これが今のところの私の答えですね。
しかし現在のように、状況が目まぐるしく変わっていく中で、この答えが私にとっていつまでもベストとは限りません。
そもそもコンテンツクリエイターであること自体が、大きなリスクになる可能性だってあるわけです。
常にアンテナを張り巡らして、瞬時に変わり身できるようにしておきたいものです。

【参考サイト】

HTML＋JavaScriptでiPhone/Androidアプリを作れるTitanium Mobileとは
http://www.atmarkit.co.jp/fwcr/design/tool/titanium01/01.html

「なぜAppleはiPadにFlashを載せるべきではない」のか
http://satoshi.blogs.com/life/2010/02/ipad2.html

「AndroidならFLASHやAIRアプリが動く」、米アドビが実演
http://pc.nikkeibp.co.jp/article/news/20100219/1023071/

iPad / iPhoneのFlash非対応について、Adobeとジョブズの言い分
http://japanese.engadget.com/2010/02/01/ipad-iphone-flash-adobe/

AdobeのCTO、Kevin LynchがFlashを擁護―「HTML5はウェブビデオを暗黒時代に投げ戻す」
http://jp.techcrunch.com/archives/20100202adobe-cto-kevin-lynch-defends-flash/

iPhoneのFlash Playerに関してAdobeがAppleへ攻撃的なメッセージ発射！
http://www.gizmodo.jp/2009/11/iphoneflash_playeradobeapple.html

「Appleはいずれ市場の圧力に屈する」　AdobeがFlashめぐりコメント
http://www.itmedia.co.jp/news/articles/1002/16/news050.html

FlashアプリがiPhoneで動く――Adobeが変換ツール
http://www.itmedia.co.jp/news/articles/0910/06/news057.html

他人事ではすまない、Gumblar（ガンブラー）によるサイト改竄

2010-02-13T23:28:18Z

通称Gumblar（ガンブラー）と呼ばれる攻撃手法により、企業サイトの改竄が相次いでいます。
改竄されているのは企業サイトですが、最初の攻撃対象はサイトの制作会社（その中のサイト管理担当者）です。

Gumblar（ガンブラー）についての技術的な説明は、他のサイトにお任せするとして・・・
肝心なのはウェブ制作に携わる私のような人間、そしてウェブ制作会社、広告代理店など、企業サイトの更新管理・運営に携わる会社のセキュリティ対策です。

Gumblarという攻撃手法が狙うのはFTPアカウントです。
FTPソフトから各サイトのFTPアカウントを盗み出す、あるいはFTP通信そのものを傍受して、FTPアカウントを取得します。
企業サイトに侵入、サイトの改竄を行うというのが大まかな特徴です。

どんな理由であれ、サイト管理担当者のPCからFTPアカウントを奪取され、クライアントのサイトが改竄された場合の責任は重大です。
クライアントおよびそのサイトの規模によっては、損害賠償責任すら問われかねません。
資金的に余裕のある大手の制作会社であればともかく、中小の制作会社は損害の補填など到底できないでしょう。

そしてこんな記事も出始めました。

■ガンブラー対策、ウェブ制作会社名の公表が有効（nikkei BPnet）
http://www.nikkeibp.co.jp/article/column/20100208/209583/

]]> Gumblar（ガンブラー）およびその亜種・変種による被害が拡大していけば、その制作会社を公表して責任を取らせろ！という流れになっても不思議はありません。

我々FTPアカウントを預かるサイト制作・運営・管理担当者は、できる限りの対策をして、自分で自分の身を守るしかないのです。
この業界に身を置く以上、FlashもJavaScriptも何かもオフにする・・・というわけにはいきません。
可能な対処法はざっくり言うと下記のとおり。

OS、ブラウザ、FlashPlayer、AdobeReader、Java、QuickTimeなど、各種ソフト・プラグインを最新の状態にする。
AdobeReaderのJavaScriptを無効する。
FTPソフトにパスワードを記録しない。
FTPS、SSH、SFTPなど、FTP以外の方法で接続する。
htaccessで特定のIPのみ接続可能にする。

最初の2つは当たり前として、3つ目のパスワードを記録しないというのは現実レベルを考えると難しい。
パスワードをPC内に別途デジタルデータで保存していれば、別の手段で奪われる可能性があります。
ただ、暗号化しておけば、格段にセキュリティ度はアップするでしょう。
しかし、ただでさえ忙しいウェブ制作担当者が、サイトの更新管理の度にその都度、その手間をかけることができるかどうかは微妙です。（可能であればやるべきです）
かといって、紙でパスワードを保存するなど、盗難・紛失といった、Gumblarより遭遇確率の高いリスクにさらされます。

4つ目のFTP以外の方法で接続するという方法は、サーバーが対応しているかどうかによるので必ずしも可能とは限りませんが、現在もっとも有効ではないでしょうか？
最初に設定してしまえば、それ以降の手間は省けますし。

5つ目の特定IPアドレスのみ接続を許可するという方法も有効。
ただし、接続する制作会社、広告代理店、クライアント企業の担当者すべてのIPアドレスを固定して登録する必要があるという難点もあります。

この点で私も利用されてもらっているレンタルサーバー「heteml」とか、対処も可能な上に、説明もわかりやすく書いてありました。

■レンタルサーバー「heteml」 - Gumblarへの対策をお願いいたします
http://heteml.jp/gumblar/

【その他参考サイト】

どのように対策をしても、100％防ぐことはできません。
あくまでも、被害にあう（そしてクライアントのサイトを被害に合わせてしまう）確率を多少減らせる程度です。
ですが、FTPアカウントを預かる身として、最低限できることはしておくべきでしょう。

SyntaxHighlighterを入れてみる

2010-02-13T10:47:40Z

ブログなどでソースコードを美しく見せるためのライブラリが多数ありますが、今回から「SyntaxHighlighter」を使用することにしました。
やはりソースコードは色分けされていたほうが見やすいですしね。

いろんなライブラリがあるのですが、その中でも「SyntaxHighlighter」の表示の仕方が一番好みだったのと、一番使われているような気がしましたので採用しました。

導入方法は簡単。

SyntaxHighlighterのダウンロードページからダウンロード。いろんな言語のバージョンがあります。（ここでいう言語とはプログラム言語ではなく、英語や日本語といった自然言語のこと）
私が確認した時点（2010年2月13日）では、日本語バージョンは無かったので「English」をダウンロード。

ダウンロードしたファイルを解凍して、サーバーにアップ。
ブログの記事に記述するソースコードの言語（ここでいう言語とはJavaScriptやPHPといったプログラム言語）によって、読み込む JavaScriptが変わります。

]]> ツールバーの表示／非表示や、行番号の表示／非表示など、いろいろコンフィグでいじることができます。

MovableType用の「SyntaxHighlighter for Movable Type」というプラグインもあります。
せっかく導入したckeditorなどのリッチテキストエディタが利用できなくなるという点、コンフィグが使用できないという点もありますが、私の場合は特に問題を感じなかったので、今回はこちらを使用しました。

プラグインをダウンロードして、mtディレクトリにアップロード
「HTMLヘッダー」テンプレートに下記のようなソースを追加します。
brush属性は、記述したいソースコードの言語によって変更します。
theme属性は、見た目の変更。

<$mt:SyntaxHighlighterInclude brush="as3,css,jscript,perl,java,php,python,ruby,sql,xml" theme="default" $>

ブログ記事の編集で、フォーマット"SyntaxHighlighter"か"SyntaxHighlighter + Convert Line Breaks"を選択

あとは

タグと、ソースコードの言語によってclass名を変更するだけでOK。
プラグイン版なら、[code:～で記述できます。（上記の参考サイトを参照）
以下はCSSのソースコードを表示する場合。

/* new clearfix */
.clearfix:after {
	visibility: hidden;
	display: block;
	font-size: 0;
	content: " ";
	clear: both;
	height: 0;
	}
* html .clearfix             { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */

過去に記述したソースコードを全部修正しようかと思いましたが、面倒なのでやめました。

今後記載するソースコードで使用して行こうと思います。

Movable Type 5.01にアップグレード

2010-02-13T04:34:35Z

このブログをMovable Type 5.01にアップグレードしました。

普通にMT4.1からアップグレードしました。問題も特に発生せず。
ブログのテンプレートは、オリジナルのものを使っていたのですが、とりあえずMTのデフォルトにしました。
自作のテンプレートはもともとヘッダーやフッターをインクルードモジュールに分割していないなど、色々問題がありましたし。
そのほかにも色々理由はありますが、とりあえず当面はデフォルトのままで行きます。

アップグレードの際に、参考にしたのは下記のページ。

]]> ついでに、WYSIWYGエディタがずっと「FCKEditor」だったので、この機会に後継の「CKEditor」に変更しました。

【参考サイト】

【ダウンロードサイト】

ckeditor-for-mt

ファイル数が多くて、アップロードに時間がかかりますが、動作などは問題なしでした。

PHPフレームワーク「ちいたん」

2010-02-12T13:50:47Z

最近、仕事でPHPでCMSを構築する案件が増えてきました。
案件数が増えてくると、どうしても作業の効率性を求めてしまいます。
中規模以上のCMSならともかく、簡易なCMSなら、シンプルで動作の軽いフレームワークでさくっと済ませたいところです。

そんなときにおススメなのがPHPフレームワーク「ちいたん」です。

ずいぶんとかわいらしい名前です。
名前の由来は公式サイトで確認していただくとして・・・

このフレームワークの使いどころは2つあります。

まずは、シンプルなCMSを短期間で納品したい時。
もうひとつは、何らかの理由でデータベースが使用できない時です。

]]> 「ちいたん」の公式サイトにもあるように、世界最軽量のPHP用MVCフレームワークです。
もともと作者がCakePHPをよく利用されている方のようで、癖のないMVCフレームワークだと思います。

一覧ページと詳細ページで構成されているようなサイトを構築するためのCMSとして考えれば、必要十分な機能が揃っていると思います。

もうひとつの大きな特徴として、TEXTSQLがデフォルトで使えるという点です。

TEXTSQLはテキストベースでデータベースのテーブルを作成して、SQLでリクエストできるようにしたものです。
私がTEXTSQLの存在を知ったのは数ヶ月前。
MySQLなどのリレーショナルデータベースが使用できない案件を受注し、CSVで管理するには少々荷が重く、何とか回避策は無いものか？と探しているうちに辿り着いたライブラリです。

「ちいたん」は、そのTEXTSQLに対応したフレームワークでしたので、利用させていただきました。
その後、いくつかの簡易なCMS案件は「ちいたん」で構築させていただきました。

「ちいたん」で何本かのCMSを構築する際にハマッタところがありました。
下記の参考サイトで解決させていただきましたので、ご紹介します。

【参考サイト】

●犬とらじお氏の「■番組表から予約」
http://www.page.sannet.ne.jp/okui/simulation.html
→「ちいたん」における、textsqlとMySQLの違いが大変参考になりました。（なぜ公式サイトできちんと書かれてないのかは不明）
以下、参考になった部分を抜粋させていただきます。

【findone】
MySQLの場合
$c->dbtable->findone("id=$id");

TEXTSQLの場合
$c->dbtable->findone('$id==' . $id); // 必ず('$***==' . $***)の形である必要がある。

【sort】
MySQLの場合
$c->dbtable->find("","key,id");

TEXTSQLの場合
$c->dbtable->find("","key　,id"); //スペースを1個挿入する。ソートキーは一つだけ。

●どうにかなるBLOGの「ちいたん」でメンバー制のページを作る（認証処理）
http://dounikanarublog.com/detail/16
→このサイトを参考に、管理画面へのログイン認証機能を作成しました

「ちいたん」はシンプルなだけに動作も軽いので、シンプルなCMSや、何らかの理由でデータベースが使用できないのでTEXTSQLを使用したい場合に便利です。

ひさびさの更新、そしてこのブログの方針について。

2010-02-11T13:25:21Z

ずっとブログを放置していました。
仕事が忙しい・・・というのが最大の理由です。
それ以上に、書きたい事とこのブログの元々のテーマが乖離してきてしまったというのが本音です。

もともとこのブログはRIA（リッチインターネットアプリケーション）について書いていたのですが、興味の対象がRIAでは無くなってきたのです。
興味がなくなったといえば語弊がありますね。
もちろんクリエイターとして、デザイナーとして、今でもRIAの興味があります。
特に業務アプリケーションでのRIAの利用、ユーザビリティについては、研究したい分野でもあります。

しかしそれ以上に、ウェブ制作・ウェブサービスにおけるビジネスモデルや、システム構築に興味の比重が偏ってきたというのもあります。

「ウェブは儲からない・・・のか？」

これが現在の私の最大の課題であり、興味の対象です。

]]> そういうわけで（どういうわけで！？）
このブログで書いているテーマがぶれてきたという現状も鑑みて、ブログを3つに分けることにしました。

ひとつはこのブログ。
「雑記」という位置づけにして、これまでどおりRIA関連や、参加したセミナーなどについて書いていこうと思います。

もうひとつは「マネタイズ研究室」　http://lepracaun.jimdo.com/

ウェブにおけるビジネスモデルや、マネタイズを研究していきます。
「儲かるウェブの探求」・・・これがテーマです。
サイトは、簡単ホームページ作成サービス「jimdo」を使って構築します。
ウェブクリエイターである私が、MovableTypeやWordPressなどを使わず、なぜこの手のサービスを利用するのか？
こういったホームページ作成サービスを自分で使ってみて、研究してみるのも勉強のひとつだと考えるからです。

すでに2月に入ってしまいましたが、今年「も」色々なことにチャレンジしていきたいと思います。

ITに取り組む上で知っておきたいオフショア開発セミナーに参加してきました。

2009-08-03T15:58:31Z

2009年8月3日（月）18:30-20:30に、大阪産業創造館で開催されたセミナー、

課題解決プロジェクト【Web・ITへの苦手意識克服プロジェクト】
そのWeb、中国に発注できますか？～ITに取り組む上で知っておきたいオフショア開発～

に参加してまいりました。

システム開発業界ではオフショア開発をしている企業も多いと思いますが、ウェブの世界では一部の企業しかしていないと思います。
ただ、今後間違いなく進むと思われるウェブ制作業界でのオフショア開発。
今回のセミナーはかねてより大変興味を持っていました。

講師の方は、日本コンピューター・システム株式会社 IT調査研究室室長
新保康夫（しんぼやすを）氏です。

日本コンピューター・システム株式会社という会社は、実際に中国に子会社を持ち、オフショア開発を実践されているということですので、実務経験に基づいたお話が聞けました。

]]> 講義の前半はウェブサイトの構築についてのお話でしたので割愛します。
講義の後半は実際のオフショア開発についての内容でしたが、一部はシステム開発のワークフロー基礎知識も入っていたので、ここも割愛。

【講義を聴いた上での結論】

実際どのくらいの規模の案件なら、コストメリットがあるのか？
やはりこの点が気になりますよね。

開発費自体は日本の１／２。多くても２／３。ただし日本側のコスト（管理とか色々含む）が高い（20％～30％）
実際には２～３人月以上でないと赤字になるとのこと。
ウェブで言えば、300万円／1ヶ月　以上の受注金額の案件じゃないとペイできないということになりますか。

ブリッジSEという「橋渡し役」の確保がポイント

ブリッジSEという、日本語ができる中国人のSEがキーパーソン。
ブリッジSEは、日本語検定1級を持つ人がいることが前提。なぜか2級以下しかいないと失敗することがある。
ブリッジSEは、関西圏にはあまりいないが、東京にはゴロゴロいる（中国企業の日本法人の人、日本企業が中国から呼んだ人等々）。

やはり、ウェブをオフショア開発するにしても、システムやCGなど高額な開発費がかかる案件が向いているようです。

オフショア開発の発注側モデル

子会社設立型・・・現地に子会社を設立する方法（契約ごとや交渉ごとが厄介なので現地法人を作る）
ラボ契約型・・・仕事があろうが無かろうが、現地の企業に一定割合の人員を確保してもらう方法（人の確保と品質の安定を図れる）
競争入札型・・・一定条件下の中で評価＆選定する方法

オフショア開発の成功要因の抜粋

開発方針や開発範囲の明確化・・・ここが曖昧だとトラブルになるケースが多い。
社内のノウハウの確保・・・オフショア開発にはノウハウが要る。その蓄積。
セキュリティ管理・・・ココ重要。日本人相手と同じような感覚で信用するなということか。
モニタリングポイントの設定・・・チェック・監視は重要。
契約書や報告書の様式の統一とツールの提供

実体験によるポイント

最近では設計までも含めた拡大オフショア開発も行う中国企業が出てきている。
中国企業は人が少ないときはスキルが高いが、儲かりだすと極端に人を増やすので、ガクンとスキルが落ちることが多い。
中国人開発者は、転職によって給料が上がっていくので、一年後には当時の担当者がいないことも多い。

講師の所見によるオフショア開発の将来（抜粋）

価格だけでオフショア開発という時代はなくなる。
品質・納期にも優れた中国企業の出現
日本は、手作りが必要なニッチ市場＆アジャイル開発（迅速に反復を繰り返しす開発手法）
上流ではオフショア開発を前提した開発へ移行する。
やがてオフショア開発はネットワーク化して、価格だけでなく、品質も納期もしっかりとして、価値を生み出すところで仕事が来る

受講した感想のまとめとして・・・

単にコストメリットだけで安易にオフショア開発すると失敗しますし、事実、失敗している企業も多いそうです。

製造業、システム開発業界と・・・オフショア開発の流れは、ウェブ業界だけ無縁でいられることはないでしょう。
講師の未来予想図にもありましたが、大規模案件や高額案件ほど、オフショア開発のメリットを享受することができるので、上流工程の時点でオフショア開発前提で企画・設計することも増えると思います。

すると中小のウェブ制作会社が生き残るには、手作りが必要なニッチ市場、そしてすばやく開発するアジャイル開発、そして何よりも、「高い付加価値」を提供できるようになるしかありませんね。

やっとHTML5へ一本化か・・・

2009-07-05T01:31:04Z

「W3CがXHTML 2の策定打ち切りを決定、HTML 5の標準化に注力へ」

「XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5」

Web業界、Web制作に携わる人にとっては結構大きなニュースですね。
Web技術の標準化団体W3C（World Wide Web Consortium）が、「XHTML 2」の策定を打ち切り、「HTML 5」の標準化に力を注ぐことを決定したわけです。

現在はご存知のとおり。HTML(最新版はHTML 4.01)とXHTML（最新版はXHTML 1.1）の2つの仕様が並存しています。
最初はHTMLだけだったのに、なぜXHTMLなんてものができたのか？
そしてHTMLからXHTMLへの移行という道に進まず、なぜ今になってHTML5というものが出てきたのか？
その辺の推察は下記の記事にわかりやすく書いてあります。

「なぜ今また出てきたのか HTML5が持つ本当の意味」

簡単に言いますと・・・

]]> ■XHTMLが出てきた理由

W3Cやティム・バーナーズ＝リーは、いい加減な文法のHTMLが嫌だった。
そこで、XMLに準拠した仕様になるXHTMLを策定し、XHTMLを標準化しようとした。
そこからセマンティックウェブとかいろいろ壮大な構想があった。

■XHTMLがコケて、HTML5が出てきた理由

文法にうるさい一部の人を除いて、XMLに準拠するとかどうでもいい（むしろメンドくさい）ことだった。
ココ最近のW3Cの策定がどれも業界の空気を読んでおらず、的がハズれた（SVGやセマンティックウェブとか色々）。
W3Cの見当違いの策定（絵に描いた立派な餅だが、実際には使いづらいしわかりにくい）にWeb業界が業を煮やした。
何かにつけてW3Cがトロくさかった。

見当違いで動きも遅いW3Cに怒って、Web業界の主要メンバーがWHAT WGという団体を立ち上げで、勝手にHTML5という仕様を策定してW3Cに売り込んだというのが実態のようです。

いずれにせよ、HTMLとXHTMLという二つの仕様が並存するという馬鹿げた状況は、今後の数年でHTML5の一本化へ収束することになるでしょう。

私はXHTMLを標準化したかったW3Cやティム・バーナーズ＝リーの気持ち、なんとなくわかります。

でも・・・

日々Web制作に携わる身として、常に感じていたことがあります。
私個人はXHTML好きですよ。私はね・・・。
私は、文法もXMLに準拠した形に移行していくのはいいことだと思っていました。私はね・・・

でもね・・・

XMLに準拠しているだとか、そんなことはどうでもいい！
もっとHTMLでいろんなことができるようにしたい！

これが、世の中の9割のWebクリエイター・開発者のホンネなのです。

だいたい、XHTMLが普及し始めたといっても、ブログやCMSだけのことだし・・・
そのブログやらCMSやらでも、XHTML1.0は普及しているけど、XHTML1.1で書かれたものはほとんど無いし・・・。
っていうか、XHTML1.1で書こうとすると現行の主要ブラウザでは、不必要な苦しみを味わうし・・・。

XHTML1.0→XHTML1.1・・・→XHTML2.0というロードマップは、今のところ絶たれたわけです。
HTML4.01・・・→HTML5というロードマップが将来に残された道です。

だとすると、我々Webクリエイターの取るべき道はどうするか？

XHTML1.0（あるいはXHTML1.1）で書いたサイト（ブログ・CMS）も含めて、それをわざわざHTML5に書き直すのは、正直メンドウですね。
なので、すでにXHTMLで書いてしまったものはそのままにしておくと。

今後、新規開発するものはどうするか？
HTML5が主要ブラウザに普及して定着するのはおそらく4～5年かかるでしょう。
今から新規立ち上げしたサイトやCMS、Webアプリケーションが、4～5年後にフルリニューアルするとは限らない。
当面、XHTMLで書いて、HTML5が普及した後、フルリニューアルしたときに書き換えればいいのかもしれないが・・・。
でもXHTMLは将来性の無い（10～20年後はわかりませんが、少なくとも今のところは）ので、積極的に採用する理由が乏しくなった。

ということは、HTML5を見越して、なるべく移行しやすいHTML4.01で書くか・・・
あ、もうHTML5で書けばいいのか。

アプリ配信プラットフォームについて

2009-06-24T04:57:31Z

AppleのApp Storeの成功を見て、似たようなビジネスモデルが雨の後の竹の子のように出てきましたね。

■Android端末向けのアプリ配信プラットフォーム「Android Market」
http://www.android.com/market/

■JavaプログラムやJavaFXプログラムの販売サイト「Java Store」
http://store.java.com/

■Nokiaの携帯向けコンテンツ配信プラットフォーム「Preminet」

そのほかにもPalmあたりも検討しているようです。
App Storeの成功がよっぽど目に眩しく写るのでしょう。

]]> こういう点を見るだけでも、Appleの商売のうまさ、ビジネスモデルも含めたトータルデザインの秀逸さが目立ちます。
で、2番煎じ3番煎じの「Android Market」や「Java Store」はどうか？

ポイントは、コンテンツ提供者の課金・収益モデルをどこまでサポートできるかにかかっていると思います。

日本ではすでにドコモのiモードなどがビジネスモデルを確立していますね。
iPhoneやらAndroid携帯やら日本のガラパゴス携帯など、各端末の差は脇へ置いておいて、このコンテンツ配信プラットフォームのビジネスモデルを簡単に比較しますと・・・

■App Store

アプリは売り切りが基本で、月額課金（iPhone OS 3.0移行で提供開始）はほとんど無い。
アプリ一本あたりの料金は、無料～2000円前後。平均300円あたりのものが多い。
プラットフォーム提供側（Apple）と売上の30％～70％をシェア。
App Store以外で配信できない。
通常のウェブサイトからApp Storeへの誘導は可能。
アプリが増えすぎて、すぐに埋もれてしまう。
売り切りのため、アプリの人気の変動が激しく、人気ランキングの入れ替えが激しい。
App Store内での露出が人気に左右される上に、それをコントロールする術が無い。（人気の出るアプリを作るしかない）
iPhone OS 3.0移行でアプリ内課金や月額課金の仕組みが提供された。
アプリ開発にはMacが必要。

■iモード等

公式アプリは月額課金が多い。（最近は売り切りアプリも増えてきた）
月額300円～500円程度のものが多い。（売り切りアプリも同じぐらい）
公式になるには審査がいる。
ドコモのiモードでは勝手アプリで自由に配信可能。
auではBREWアプリは無理だが、オープンアプリ（機能は限定される・Javaで記述）はある程度自由に配信可能。
ソフトバンクは勝手にアプリを配信することは現時点では無理。
各キャリアごと開発が環境が違う。BREWアプリは開発言語そのものが違う。

■Android Market

審査がいらない（とされている）
自由に配信可能
売り上げの70％がコンテンツ開発者にシェア。
有料アプリの決済にはGoogle Checkoutを使用する。

こうしてみると、App Storeやiモード等は、配信プラットフォームの提供側（Appleやドコモ・au・ソフトバンクなど）が非常に有利であるという点。
そして、Appleは完全な囲い込みをしている点に対して、Android Marketはかなり自由度が高い（ように見える）という点。
日本のiモード等はあらゆる制約が多くて、日本以外で展開するのはまず絶望的に近いという点。

日本のiモード等はがっちりコンテンツ課金システムができあがっているので、日本国内だけに限定したらいいのかもしれません。
しかし縮小する国内市場を考えたときに、海外への収益モデルも同時に考えておいたほうがいいでしょう。

私としては、完全にAppleに拘束・支配されているApp StoreよりもAndroid Marketに希望を託したいですね。
Java Storeはまだまだ様子見です。

ビジネスロジックを極力SQLで持たせるという考え方

2009-06-23T04:04:46Z

ジーワンシステムという会社の社長が連載している「ベンチャー社長で技術者で」という記事があります。
連載記事の中で終始一貫しておっしゃっているのが、SQLを高度に極めるということ。
そしてビジネスロジックを極力SQLで持たせるという考え方

ビジネスロジックというのは、データベースとユーザーインタフェース間の情報のやりとりを制御するアルゴリズムを指す用語（Wikipedia）です。

VB6とか.NETとかはやってないのでわかりませんが、これらをPHPやPerlに置き換えたらわかりやすい。

]]> 確かに、プログラム言語は流行廃りが激しい。
リレーショナルデータベース（RDBMS）を使うWebサービス・アプリケーションの場合、プログラム言語はPHPやらPerl、Ruby、Pythonなどです。
（ASP.NETは使っていないのでよくわかりません）

ならば枯れた技術であるSQLで極力解決して、プログラム言語側で処理するのは最小限にする。
そうすれば移植もしやすいかもしれない。

この方の記事の意味を全て理解できているわけではありませんが、思い当たるフシがあるといいますが、同感・同意見だと思うところがあるので、まじめてSQLを勉強することにしました。

天邪鬼？

2009-06-22T03:37:10Z

何かと天邪鬼というか、マイナー思考な自分がいます。
最近、GoogleおよびMozilla（Firefox）を個人的に使わない傾向が出てきました。

たとえば使っているブラウザ。
Firefox3.5が正式公開されましたね・・・
でも、最近Firefoxはあまり使っていません。
今はIE8使っています。
Firefoxは開発時にFirebugとか一部のプラグイン使いたいときだけ。あとはブラウザチェックのとき。

]]> なぜか？

「Firefoxの人気が出すぎたから」

別にIEとシェアが逆転したわけではないんですが、なんかマイナーとは言い切れないほどシェアが出てきました。
だから使うのがイヤになってきたんです。

Google Chromeも軽快な動きが好きで使っていますが、あんまりシェアが出るようだったら使うのやめるでしょうね。
昔使っていたOperaはなんだか最近好きじゃないので、マイナーでも使いませんけどね。（少なくともPC版は）
あとは、Mac版よりWindows版のほうがダウンロード数が多そうなSafariですかね。

たとえば検索エンジン

日本で人気のYahoo!JAPANはもともと使っていませんでした。
最近はGoogleも使うのやめようかと思っています。

だから「Bing」
すでにブラウザの規定の検索エンジン（右上にある検索ボックス）はBingに切り替えました。
たとえばFirefoxでこれをGoogleに設定していると、MozillaにGoogleから巨額の共有広告収入が入るからです。

なぜか？

「Googleの人気が出すぎたから」

つまり、何のブラウザを使おうが規定の検索エンジンをGoogleにしている時点で、Googleにお金が入るのです。

GoogleはAndroidだけ応援します。
AdWordsもAdSenseもクリックしません。

天邪鬼というより、単なるへそ曲がりですけどね。

Lepracaun's factory - レプラコーン ファクトリー -

代替できないプラットフォームに依存することの危険性

現時点で最高のオンライン版マインドマップ「EasyStep」

CMSの潮流が変わってきた・・・

PHP用IDEとしてNetBeansが良い件

AppleとAdobeのFlashをめぐる攻防で思うこと

他人事ではすまない、Gumblar（ガンブラー）によるサイト改竄

SyntaxHighlighterを入れてみる

Movable Type 5.01にアップグレード

PHPフレームワーク「ちいたん」

ひさびさの更新、そしてこのブログの方針について。

ITに取り組む上で知っておきたいオフショア開発セミナーに参加してきました。

やっとHTML5へ一本化か・・・

アプリ配信プラットフォームについて

ビジネスロジックを極力SQLで持たせるという考え方

天邪鬼？

Lepracaun's factory - レプラコーンファクトリー -