「Qiita」の記事 - Crieit

Dartを使った大規模なアプリ開発

2022-01-20T19:00:13+09:00

こんにちは、Quireです。

Quireは、Dartで開発された初めてのWebアプリケーションではありませんが、クライアントとサーバーの両方でDartをふんだんに使ったものとしては、初めてかもしれません。

動作の軽い、徹底して階層構造のタスク管理ツールです。このプロジェクトはDartコードで合計53992行、1620 KB。コミュニティーからのオープンソースライブラリも使っています。

私たちについて

このプロジェクトを開始するまで、私たちはRikuloというDartファンの集まりでした。Rikuloはこれまで、UIフレームワークやUIライブラリ、Webサーバー、メッセージサーバー、DBクライアントなどのDartライブラリをリリースしています。
Dartが2011年に初めてリリースされたとき、すぐに将来性を感じ、さっそく小規模のプロジェクトに着手。その後、ほとんどDartで書かれた大規模アプリの開発へと進みました。今回はそのときの経験をお話しします。Dartによる開発に興味を持っていただければ幸いです。

なぜDartか

私たちがDartを選んだ理由はたくさんありますが、以下に大きなものを挙げてみます。
- 強く型付けされていて、無数の小さなミスを防ぐことができる。公式IDEのDart Editorは、タイプミスへの即時フィードバックやオートコンプリート機能を備えており、トラッキングも容易。
- 継承がクラスベースで、プロトタイプベースよりも直感的に使える。
- クライアントとサーバーの両方で同じ言語が使えて、データモデルやコードベースを共有できる。
- JavaScriptの問題点をほぼ解消。完全ではないが、以前にあった問題の99％には対応している。
- JavaScript Harmonyで人気の特徴をいくつか備えている。例えばFuture（Promise）パターン、矢印関数など。
- 強力なチームの後ろ盾があり、ハイクオリティーな公式ライブラリや使いやすいAPIを利用できる。まだ開発途上ながら、仕様はすでにかなり安定している。
- サーバーサイドではマルチスレッドではなくイベントループ方式で、好みだった。
- JavaScriptへのコンパイル時にTree Shakingできる（下記参照）。

もちろんデメリットもあります。以下に挙げてみます。

コミュニティーがJavaScriptよりも圧倒的に小さい。
DartとJavaScript間の通信が自明でない。
強い型付けなので、APIのPolyfillが面倒。
Dart Editorの性能が（今のところ）大規模プロジェクトに適さない。

強い型のサポートにより、書くプロセスがJavaScriptよりもずっとロバストです。また、Javaよりもシンプルで、Vanilla JavaScriptと比べてもシンプルなことがあります（関数の書き方など）。全体的にDartは扱いやすい言語ですが、以下のような例外はあります。

コンストラクタのボディよりも先にイニシャライザでFinalフィールドを初期化する必要がある。
ミックスインの仕様が使いにくく、2.0まで改善されそうにない。
ジェネリック型パラメータがクラスにしかなく、関数宣言にない。（そのためコンパイラの負荷が増す）。

クライアントサイド

Dart VMがChromeに統合される日まで、JavaScriptにコンパイルして作成することになります。JavaScriptにコンパイルする言語はたくさんありますが、Dartには以下のような独自のメリットがあります。

私たちは開発時、Dart VMを内蔵したChromiumベースのブラウザー、DartiumでDartをネイティブに実行している。このイテレーションではコンパイルが不要で、スムーズに進めることができる。
テストとプロダクションの段階でJavaScriptにコンパイルし、すべてのメジャーなブラウザーで実行する。このとき使用するコンパイラがTree Shakingを行い、不要なコードを除去するため、JavaScriptのコードサイズを小さくできる。

サーバーサイド

サーバーサイドについてはあまりコミュニティーで話題になりませんが、私たちは以下の理由から、Dartはサーバーサイドのプログラミング言語に入ると考えています。

Webサービスは本質的に非同期なため、イベントループ方式と相性がいい（マルチスレッドと比べて）。
クライアントサイドよりもサーバーサイドのほうが、よりロバストで安全なコードが必要。強い型付けの言語はこの点において有利。

サポートライブラリ

Quireは約30のライブラリをインポートしています。そのうち10ライブラリはコミュニティーからで、残りはDartからリリースされたものです。Dartに詳しい方ならAngularDARTとPolymer.dartがあると思うかもしれませんが、実はどちらも使っていません。

AngularDARTを使わない理由は、以下のとおりです。

DOMを細かく制御したい。
私たちはクライアント構造の構築に独自のアーキテクチャガイドラインを使用しており、そのパラダイムがAngularのロジックと異なる。
AngularDARTについて調べたとき、コンパイルされたJavaScriptのコードサイズにかなりのオーバーヘッドが生じた。ただし、これはその後かなり改善された。

私たちは以下の理由から、Polymer.dartも使っていません。

カプセル化とイベントリターゲティングのため、ShadowDOMはBootstrapのようなセレクター指向のフレームワークと併用できない。
ShadowDOMの外部からスタイルを適用できない。サードパーティーのコンポーネントセットがPolymerで作成されている場合、ユーザーが見た目や感じを変えることは不可能に近い。(更新：2013年12月時点で、内部のスタイルを外部から変更可能。Shadow DOM 201を参照。)

DQuery＆Bootjack

私たちのクライアントサイドスタックの基盤は、Rikuloリリースのオープンソースプロジェクト、DQueryとBootjackです。
- DQueryはjQueryの一部、特にイベントデリゲートの仕組みの部分をDartに移植したものです。
- BootjackはBootstrap 3の完全な移植で、CSS およびAPIとほぼ同じです。

このようにアプリケーションスタックを構築して、JavaScriptについて知っていること、できることを活用しています。

Stream

私たちのWebサーバーは、Dartのみで書かれ、ルーティング、フィルター、サーバーサイドMVCなどを備えたStreamです。イベントループ方式とシームレスに連携して動作します。リクエストハンドラーも、ノンブロッキングのルーチンをつなげるだけで書くことができ、従来のマルチスレッド方式よりも生産的かつ快適に仕事ができます。私たちは、Webサービスをスケールし、nginxでHTTPSを処理し、Streamにリクエストをデリゲートしたりもしています。このアーキテクチャによりDart VMを個別にSpawn／Despawnでき、サーバーのアップグレードもユーザーの使用を妨げずに実施できます。

終わりに

Dartは使い勝手の良い言語です。この記事がDartコミュニティー成長の一助となることを願っています。最後に、Dartで何ができるか興味のある方は、ぜひQuireを試してみてください。

QiitaにはてなブックマークとPocketボタンを設置するためのスクリプトを作成してみた

2019-02-09T15:50:38+09:00

Qiitaの記事にもはてなブックマークとPocketのボタンが欲しいですよね。
そこで、それらのボタンと同じ機能を持つリンクを生成するためのJavaScriptスクリプトを書きました。
Qiitaの記事編集画面で開発者用ツールを開き、以下のJavaScriptをコピペして実行して下さい。
実行すると結果がクリップボードにコピーされます。

const userId = Qiita.user.url_name
const itemId = window.location.href.split('/').splice(-2,1)[0]
const hatebuURL = `//b.hatena.ne.jp/add?mode=confirm&url=https://qiita.com/${userId}/items/${itemId}`
const pocketURL = `//getpocket.com/edit?url=https://qiita.com/${userId}/items/${itemId}`
const  htmlToElement = (html)=> {
  var template = document.createElement('template');
  html = html.trim(); // Never return a text node of whitespace as the result
  template.innerHTML = html;
  return template.content.firstChild;
}
const copyToClipboard = str => {
    if(!str || typeof(str) != "string") {
      return "";
    }
    //elmはtextareaノード
    var elm =htmlToElement("" + str + "")
    //strを含んだtextareaをbodyタグの末尾に設置
    document.body.appendChild(elm);
    //select()でtextarea内の文字を選択
    elm.select();
    //rangeでtextarea内の文字を選択
    var range = document.createRange();
    range.selectNodeContents(elm);
    var sel = window.getSelection();
    sel.removeAllRanges();
    sel.addRange(range);
    elm.setSelectionRange(0, 999999);
    //execCommandを実施
    document.execCommand("copy");
    //textareaを削除
    document.body.removeChild(elm);
  };

copyToClipboard(`## はてなブックマーク・Pocketはこちらから
[はてなブックマークに追加](${hatebuURL})
[Pocketに追加](${pocketURL})`)
alert('コピーしました。')

コピーされた内容をQiitaのエディターの一番下に貼り付けて下さい。
このようになります。

はてなブックマーク・Pocketはこちらから

はてなブックマークに追加
 Pocketに追加

　最後に

いかがでしたか？
どなたかこのコードを元にしてChrome拡張を作って頂けると泣いて喜びます。
さて、今後はこのリンクを記事の一番下に掲載しておくことにします。ありがとうございました。

はてなブックマーク・Pocketはこちらから

はてなブックマークに追加
 Pocketに追加

今の時代、日本語で書いた記事でも意外に海外から読んでもらえるものなので、ぼくらはもっと自信をもって日本語で書いてもいいのかも

2019-01-01T12:19:04+09:00

ご挨拶

あけましておめでとうございます、2019年、来年はついに C++20 がやってくるのかと思うとワクワクしてきますね

はじめに

日本語で書いたQiita の記事にコメントで質問を英語で頂くことがこれまでに２回ありまして、質問をいただいているので単なる通りすがりのおちゃらかしではなくて記事に興味を持ってくださって、どうにかして読んでくださって、なおかつ疑問に残ったことを英語で質問してくださったんだろうなと思うとちょっと胸熱でウルウルしてました

私のささやかな声でも、世界に届くことがあるんだな
この喜びと勇気を諸兄諸姉にも届けたい、と思ったことが本稿を寄稿いたしましたモチベーションでございます

ところで、日本語で書いた記事って実際に どれ位海外で読まれる ものなのでしょうか？
千人に１人の 0.1% ぐらい、というのは希望的すぎるので万人に１人の 0.01% ぐらいでしょうか？

検証

Qiita はありがたいことに アナリティクスの設置ができますので、それで自分の記事がどれぐらい日本以外で参照してもらえているものなのか調べてみようと思います

期間は2018年の 9月3日から 2019年1月1日（今日ですね、あけましておめでとうございます）までの 約４ヶ月間、これまで Qiita に上梓させていただきました 75本 の記事が対称です

Resarch Question

RQ1: 日本語の記事がグローバルに参照される比率はどれぐらいなのか

結果

ぱっとみてビックリしました

コメントの内容から北米とヨーロッパは予想してたのですが、南米、アジア、オセアニア、ロシアと余すところなく、西アフリカと中央アジア意外ほぼ全域でよんでもらえてるなんてもう感動ものです

中央アフリカでもタンザニアとケニアといった近年急速に産業が発達してるとちょっとまえに BBCで紹介されてた国で読んでいただけてて、もしも私の記事がそういうことに少しでも貢献できていたとしたらそれにまさる喜びはありません

イエメンとか４０人も読んでくださった方がいらっしゃいまして、もし私の記事がなにかの役に経つことがあれば僥倖の至りです

チュニジア（行こうとしてた年にジャスミン革命がおきてしまって行きそこなった悲しい思い出が）やモロッコみたいないつかは行きたいマグレブ諸国でも読んでくださってる方がいらっしゃるんだとおもうともうなんというか感動です

世界の皆様、あんな記事をわざわざ読んでいただきまして本当にありがとうございますだ

都市で見てみるとこんなかんじで

私は赤貧生活をしているのが影響してか「100円でつくれる〜」みたいなボンビくさい記事が多いのですがなぜ港区みたいなリッチな所の方々にうけているのかが謎です ^^;;;

で、70位になんとパリがはいってるんですよ、gilets jaunes の皆様が頑張っていらっしゃるあのパリで、しかも 57% って凄い低い直帰率

76位のサナアはさきほど少しふれたイエメンの街です。こちらも直帰率たったの 50%、読んでくださってありがたいです

そして

87位にオスロが、94位にサン・ペテルブルグが、95位にロンドンが、福島や甲府の方々よりも読んでくださってます

さらに大都市だけでなく

Huddersfield って知らなかったのですがマンチェスターの近くの人口16万人ほどの街で、Randburg はヨハネスブルグ北西部の人口33万人ほどの街なんだそうです

世界の街で、こんなに読んでくださっている方がいらっしゃるんですね

なんて感慨に浸ってないで（感動は研究の最強のモチベーションであるとはおもうのですが）、前述の RQ の検証にもどりますと

日本からの参照が 95.46%、なので 海外からの参照は 4.54% ですね、桁違いに多い、マジで有意な数の参照が海外から だったんですね

ところで日本国内にも日本語話者でない IT エンジニアの方がたくさんいらっしゃいますし、海外で働いている日本語話者の IT エンジニアの方もたくさんいらっしゃいます
日本語話者ではないと思われる方がどれ位参照してくださっているものなのかというと

ええと、だいたい 7.01% ぐらい？
これ、凄くないですか？日本語で書いてるのに

考察

機械翻訳が進んだ昨今、何語で書いてあるかは問題じゃなくなってきてるということなのでしょうか？

結論

日本語で書いた記事ってみんなが信じてる以上に実際は世界に届いているみたいですよ

ご立派な方々から 日本語での情報発信はグローバルな価値はゼロだよ なんてよく腐されておりました グローバル言語弱者 の私といたしましては、日本語で書いた記事でも実に 読者の 4.5% は海外の、7%は日本語ユーザーでない人 だったという事実は、 少なくとも「価値はゼロ」なんてことは決してない みたいです

本稿は某所に上梓させていただきましたこれを revise して、新年の希望にみちあふれる内容にしようと思ったんですけどイマイチうまくできませんでした
どうも本当にすみません、希望ってむずかしい

QiitaとQrunchとCrieitを比較してみた

2018-10-14T20:22:11+09:00

先日 Qrunch という技術ブログサービスがリリースされました。

Aboutを見ると「Qiita・dev.toの中間的な存在」、且つクロス投稿も可能ということでかなり僕が開発したCrieitとコンセプトとして共通していると感じました。そのためここで一度Qiitaベースの３サービスを比較してみました。

サービス自体の違い

Qiitaはプログラミングに関する記事を投稿するサービス
Qrunchは技術ブログサービス
Crieitはプログラマー、クリエイター向けのコミュニティ

大まかには下記のようになっており、サービスの内容的に類似はしていますがベースとなるもの自体はどれも異なっているようです。

その他の部分としてQiitaはQiita:Teamを展開していたりOrganizationという枠組みで活動できたりというところがあり、Qrunchは小さなメモをつぶやける「ログ」という機能があったりします。

投稿した内容の帰属

Qiitaは投稿は全てQiitaへの寄稿のような形となります。著作権は所有者にあると思いますが、SEO的にはQiitaとしてのコンテンツになってしまいます。

Qrunch、Crieitはカノニカルを利用したクロス投稿ができるようになっています。どちらも標準ではQiitaのような寄稿の形をとりますが、カノニカルURLを指定することで最終的に引っ越しなども可能ですので、SEO上そのコンテンツがサービス内に骨を埋める形になってしまったりということがありません。

また、Qrunchはブログという形を取っているため、自分の所有物、という印象は更に強まりそうです。

投稿できる内容

QiitaはQrunch、Crieitの開発者が困っている部分としてあげているとおり、プログラミングに関することを投稿してほしい、というコミュニティガイドラインがあります。

Qrunch、Crieitは何でも投稿が可能です。Qrunchはそもそもブログですので通常の内容であれば規制される内容自体がありませんし、Crieitは何でもOKと定めているので問題ありません。

運営者

Qiitaは法人の運営ですのでしっかりとした体制が整っていますが、Qrunch、Crieitは個人開発になります。全体的な安定性はQiitaの一強となります。

機能の違い

Qiitaは長年続いている巨大サービスで、ユーザー数も記事数もかなり多いです。それに適応した機能が揃っており、普段滞在してサービス内をうろうろしたり再アクセスしたりするのに十分な楽しさがあります。このあたりはさすが大手という感じです。

Crieitはとにかく最低限の実装を意識しているので、投稿やユーザーが少ない間はあまり使われなそうな機能はほとんど実際していません。その時の状況に合わせてブラッシュアップしていきます。そのため、現在は投稿関連のメイン機能以外はほとんど機能がありません。ですのでわりと迷いにくいのでは、と思っています。

Qrunchはリリース直後からそこそこ色々な機能が実装されています。ユーザー同士でフォローしあったり、アクセス解析等も標準でついていたりします。安心感はありますが、まだあまり使わない機能が表示されていたりしてちょっと迷ってしまう部分などもありそうです。ただ、今後ユーザーや記事が増えていった場合にも安心して使っていけそうなイメージがあります。

デザイン

Qiitaは大勢の人が見慣れているのでThe Qiita、という感じですね。

Qrunchは全部自分で実装されているということのようですね。クオリティ高くてやばい…。

CrieitはBootstrap Material Designを入れているだけでデザインは一切していません。ロゴ（Twitterカード画像）もfaviconも青背景にフォントも考えず適当に文字をおいただけですし…。

繁栄の傾向

Qiitaはもう繁栄していますので、これからどうやって調整していくか、というところが見ものです。現在も色々調整されているようですね。

Qrunchはすごいですね、一気に広まっていますし、初日からガンガン投稿が増えています。Twitterをみてもかなり評判が良く今後もどんどん繁栄していきそうな感じがします。

Crieitは未だに自分の知り合いの方々しか知らないのではないのかというくらいで、全く広まっていません。アクセスも非常に少ないです。何を作っても流行らない呪いのため、僕の作ったサービスはいつもユーザー数やアクセスが皆無（１桁とか）なので、これでも一番の快挙なレベルではあります。地道に育成できる系のサービスではあるので、引き続きコツコツと成長を目指していきます。

将来性

Qiitaはもう何年も続いてますし安定しているのではないかと思います。

QrunchとCrieitは個人開発のため、今後どうなっていくか、というのは不明な点も多いです。ただ、Qrunchの開発者の方のツイートを見ると、うまくいかなかったら自分のブログとして使う、というような発言があったため、このあたりは僕と同じ思想で面白かったです。個人開発の弱みであり強みですね。

まとめ - 今後技術系記事界隈はどうなっていくと良いか

何の人脈がなくても人から記事を読んでもらいやすい技術系記事投稿サービス、というのは、日本ではQiitaしかありません。他にも色々投稿サービス自体はありますが、はっきり言って集客力がないとどれだけ頑張って書いても誰にも読んでもらえません。

そのためクロス投稿ができたり、投稿できる内容の自由さを求めたりすると別のサービスが必要となります。今年はCrieit、Qrunchとリリースが続いているのでそれが何か一つの大きな転機で、今後色々と細かい問題を解決するための類似のサービスがどんどん出てくるのでは、という気がしてきました。

今後大きな会社が組織的に同様のサービスを出してくる可能性もありそうですし、もしかしたらQiitaが大幅にガイドラインや機能を変えてくる可能性もあるかもしれません。

Qiita、Qrunch、Crieitのどれかが、ということではなく、全てがそれぞれ色々な問題を解決して成長していければいいな、と思っています。

…しかし、これで技術系記事をクロス投稿できるサービスがMedium、dev.to、Qrunch、Crieitと４つになったので、何かクロス投稿を一括でできるサービスがほしいところです。

Qiitaの様なサービスを公開して１ヶ月経った雑感

2018-07-11T12:09:46+09:00

Crieit――Qiitaの様だけど何でも気軽に書けるコミュニティ Crieit――をαバージョンで公開して１ヶ月ちょっと過ぎました。その間に色々と感じた雑感を書き残しておこうと思います。

どれくらい完成したのか

一応ロードマップも公開しています。

Crieitロードマップ

まだまだ必要な機能の中でできていないものもたくさんあります。ただ、ユーザーや投稿が増えないと意味のない機能もあるため、αバージョンのままでも最低限問題ないくらいの状態にはどこかのタイミングでなるのではないかと思います。

そのため必要な機能よりも、アクセスした人がユーザーとして使ってみたくなる、ユーザーになった人が居心地が良くなる改善の方を先にどんどんやっていった方がいい部分もあるかなと感じています。

記事も書いている

とりあえず投稿を増やしていかなければならないため、現在思いついたことはどんどん記事にして自分で投稿していっています。６月は10記事程書きました。引き続きどんどん書いていきたいと思います。

ちなみに元々はてなブログにあった自分の記事をCrieitにコピーしてはじめました。はてなブログも元々はWordpress、更には名前忘れましたがフリーのCMS時代の記事も元々コピーしていたため、最初から200記事以上はありました。

はてなブログ側をそのままにしておくと、Crieitの記事が重複記事として評価が無価値になりそうだったため、はてなブログ側は非公開にしました。

あとはQiitaで書いていた記事で、全然いいねはもらえなかったけど結構検索流入が多い記事などもあったため、そういったものもちょこちょこQiita側の記事を削除して移動してきています。

やはり投稿の量が重要なサービスのため、αバージョンで早めに公開してページを増やせているのは良かったと思います。

記事系サービスは結構いい

記事系サービスは運営するのに結構良いと思います。特に、僕のような凡人で色々サービス作ってみても全く流行ったことも無い人にはおすすめです。なぜかというと、下記のような理由です。

頑張って書いた。バズれ！　→　バズらない。でも記事がひとつ増えるだけでSEO的にはポイントが上がる
色々な記事を書いて何度も挑戦できる

こんな感じで、集客力もカリスマ性もなくても、コツコツ頑張るだけで徐々にサービス全体の質があがっていきます。面白いサービスを作って流行らせることができなくても、徐々にサービスを育成することができます。とくにお金をかけて一気に記事をふやしまくればかなりの集客力がつくと思うので、キュレーションサイトが増えてたのは非常に頷けます。

もしそのうち多くの人が投稿してくれるようになれば大幅な成長が見込めるので、非常に面白いと思います。こういうサービスにしろ、ブログにしろ、誰もがひとつは長期的にのんびり時間をかけて運営していった方がいいサービスの一つかな、と感じました。

逆に言うと、そういうことをやりたい人は早めにどんどんはじめた方が良いと思います。

文章を書くのはそこそこ好きっぽい

Crieitも含め、元々ブログやQiitaでも記事を書いていましたが、わりと記事を書くのは好きなんじゃないかなと思います。書く時は集中してどんどん書けますし、記事が完成すると達成感があります。

そういえば昔も個人でテキストサイトをやっていましたし、小説を書いて応募して１次審査突破したこともあります（１次はつまらなくても突破できるようになっています）。文章を書くことはずーっとやっているので、得意不得意は抜きにして結構自分にあっているのではないかと思います。そのため、このサービス自体も今まで作ったものに比べやってて楽しい感じがあります。

運営に失敗しても、最悪の場合自分のブログとして使えるので非常に良いですし。

Google Analyticsが面白い

長くなったので別記事に分割しました。

Google Analyticsで見ると面白いところ

f1-micro怖い

f1-microは無料で運用できますが、スペックが非常に低いです。下記の記事とか何故かマイナーそうなのにちょっとだけテクノロジーのホッテントリに載ったのでその間は怖かったです…。スペックを上げるにはサーバーを一度止めないといけないので。

PHP+Laravel+FCMでWebプッシュ通知を送る

下記も載りました。上記より多かったですが、でも結構大丈夫でした。結局、瞬間的にさばききれない程のアクセスが来るとまずそうですが、数秒間隔とかで適当にアクセスがある程度であれば全然問題なさそうな気もしました。

SlackはPHPっぽいもので作られているらしい

Google Cloud Storageは止めなくても変えることができるとどこかで見た気がするので、とりあえずDBだけはどこかのタイミングで分けた方がよさそうです。

まとめ

とりあえずSEO楽しい、自分で記事書くのもわりと好きということで、今まで作ったサービスの中では一番好きかもしれません。

あとはなんとか投稿してくれる人を増やしていかなければならないので、自分で頑張って記事を書いて広めていきたいと思います。自分できっちり記事をバズらせることができる能力があればよかったんですが…。記事がバズる毎に先着１０記事まで１万円プレゼントキャンペーンでもやりますか〜…。

ということでよろしければ是非モチベーションが上がった時にでもどなたか記事の投稿をぜひよろしくお願いします。カノニカルURLを指定できるので、ご自身のブログの記事の丸々コピーでも全く問題ないです。

カノニカルとは？

QiitaがやっているSEO対策を調べてみた

2018-06-04T09:38:26+09:00

はじめに

Crieitを開発中、いくつかのサービスを参考にしました。そのためQiitaのSEOはこうやっている、というのを多少感じ取れた部分がありますので、いくつか紹介していきたいと思います。（このサービスをざっと見ていただいた方はお気づきかと思いますが、Qiitaの構成もかなり参考にしています）

ちなみに裏技のようなものの紹介は特にありません。基本的な、大事な部分をちゃんとやっている、というところがメインの話になります。

元々存在しない価値を生み出すものではなく、コンテンツを無駄にしないためのSEOです。

（このあとリニューアルしたため内容と現在のサイトが異なっている場合があります）

コンテンツを増やす

コンテンツが増えると、検索流入もその分多くなりアクセスを増やすことの要因の一つとなります。

ではコンテンツとは何か、というとQiitaでは当然記事があります。

ただ、それだけではもったいないです。付随する色々なデータがあるので、それらもコンテンツとして配置することで一気にサービス上のコンテンツのボリュームを増やすことができます。

ユーザープロフィール

ユーザーにはそれぞれプロフィールページが設けられています。これも一つのコンテンツとしてみなすことができます。

しかも、これは１ページにとどまりません。プロフィールに入った最初のページはそのユーザーの記事一覧があります。さらにタブをクリックすると、その人がいいねした履歴やフォロワー一覧等もそれぞれ１ページのコンテンツとすることで、１ユーザー増える毎にコンテンツが何倍にも増えるようにしています。

全てのページにちゃんとアクセスできるようにする

SEO上、ベースとなる部分で一番大事なことは、ちゃんとクローラに認識してもらうことです。つまり、まずは全部のページにちゃんと辿ってアクセスできるようにしてあげる必要があります。

Qiitaはこのあたりをちゃんとしていました。具体的にはフッターにあるこのリンクです。

このリンクは、全てのページにアクセスできるようにするためのリンクです。主にクローラのために配置されているもので、ユーザーが普段利用するページではありません。

前述したユーザー、タグページも重要なコンテンツですので、これらにも全てアクセスできるようになっています。

今これを読んでいる方の中にもサイトやサービスを作っている方は多いと思いますが、こういった仕組みは導入されていますか？

検索パラメータでページはかなり増えるけど、formだから実質クローラはアクセスできない、なんて事になっていたら非常にもったいないと思います。気になる方はぜひ見直してみましょう。

ちなみに、ページングは個別ページとしては利用できません。メタタグを利用して同一ページとして認識させることができますので、そういった対応を行いましょう。例えばQiitaでは下記のようになっています。

ページ内の重要なワードの出現回数を増やす

ページ内の需要なワードを違和感ない程度に増やすことで、各ページがそのワードのページとしてのSEO上の価値が高まり、検索結果に表示されやすくなります。（劇的な効果があるわけではないと思います）

具体的に見ていきます。

記事ページ

記事はユーザーが投稿するもののため、自由にキーワードの出現頻度を増やすことができません。そのため、いくつかの工夫がなされています。

見出し一覧

Qiitaで特徴的なのはやはり右側に表示されている見出し一覧。

単なる便利機能ではなく、見出しには重要なワードが含まれることが多いので、この機能を追加して出現頻度を上げているものと思われます。

タグページ

前述した全てのタグの一覧ページを見てみると、単に列挙しているだけではなく、人気のあるタグを最初にいくつか説明文の中で列挙しています。

Qiitaに登録されているタグの一覧です。 JavaScript、Ruby、PHP、iPhone、Android、Vim、Emacs、Objective-C、CoffeeScript、gitなど、Qiitaでは毎日様々なジャンルの投稿がされています。気になるタグを探してフォローしてみましょう。

たった１ページではありますが、このサイトはこういう内容がメインのサービスだよ、というのをクローラに伝えるためにこういった記述になっていると思われます。

気になったところ

Qiitaにログインしていない状態でだけアクセスできるトップページがあります。その中に、「Hello Hackers」という文言がありますがこれがh1になっています。このあたりは不思議ですね。あまり重要ではないのでしょうか。

Crieitもそれを真似てBootstrapのサンプルそのままのHello, worldをh1タグにしています。

まとめ

以上がQiitaが対応しているSEO対策についての雑感になります。おそらく他にも気づかないところですごいことをやっている可能性もありますが、今のところ僕が気づいたところはこういったところです。

結局、すごいことをやるわけではなく、ちゃんと基本ができているか、というところになりますので、あまり深く追いすぎても意味はないと思います。やりすぎは逆にマイナスだと思いますので。

キーワードについてちゃんと考える
導線を考える
メタタグをちゃんと整備する

あくまでもこういった基本的な大事なところをきっちりするためのSEOとして役立つ諸々の対策になるかと思います。

繰り返しますが、元々存在しない価値を生み出すものではなく、コンテンツを無駄にしないためのSEOです。

最後に

その他サービス開発上色々気がついたことなどは随時このCrieit上に投稿していきます。気になる方はぜひフォローをお願いします。（Crieit上にフォロー機能がまだないのですが…）