「Qrunch」の記事 - Crieit

Qrunch から Crieit に引越しする

2020-10-05T00:21:23+09:00

TL; DR

Qrunch から引越しました。

はじめに

Qrunch がサービス終了することになり、引越し先を決めなければならなくなりました。

一旦、 Crieit に移行することにし、 Qrunch との違いなどを記載しようと思います。

引越し手順

以下の手順で、手動で引越しします。

Qrunch 記事のエクスポート
Crieit への記事追加（下書き）
下書き記事の公開
Qrunch 記事のカノニカル設定付与

Qrunch 記事のエクスポート

Qrunch の記事をエクスポートし、Markdown 形式のテキストファイルをダウンロードします。

Crieit への記事追加（下書き）

エクスポートした記事ファイルから、次の3つを移行します。

記事本文
記事タイトル
タグ／カテゴリ

下書きとして全17記事を保存します。

下書き記事の公開

下書き記事を、順次公開します。
公開するごとに URL を記録しておきます。

Qrunch 記事のカノニカル設定付与

Crieit に公開した記事の URL を、 Qrunch 記事のカノニカル設定 URL に付与します。
カノニカル設定をすることで、 Qrunch の記事購読者の流出防止を期待してます（正しい使い方なのかは分かりませんが......）。

Qrunch の記事は 2020/10/4 まで編集可能であったため、それまでに何としてでもこれを設定したかったです。

Tips

単純に移行は、やはりできませんでした。
そのため、いくつか移行時にコツがあるため、それについて記載します。

Qrunch 記事の絵文字が一部正常にエクスポートできない

Qrunch の記事として記載していた絵文字が、一部正常にエクスポートできませんでした。
こちらは、単純に記述すれば問題ありません。

Crieit のコード記述 Markdown でコードタイトルが記述できない

Crieit のコード記述 Markdown は、コードタイトルが記述できません。

この問題に気づいたのは、記事を公開してからです。
記事記述中のプレビューと、記事公開時の画面では、表示が異なっていました。
コードタイトルを記述している場合、正常にコード表示できません。

しかも、 Markdown の構文解析を常時実施しているわけではなさそうで、一部だけコードのように記述される場合があるなど、表示させるためには多少のコツが必要っぽいです。

Qrunch のタグとカテゴリを合わせる必要がある

Qrunch には、タグとカテゴリの2種類が存在しました。
当然、 Crieit にはタグの1種類しか存在しないため、合わせる必要があります。

Crieit のタグはコピペで設定できない

Crieit のタグは空白文字区切りでないため、エクスポートファイルのタグ表示欄を単純にコピペはできません。
コピペする場合、1タグごとにコピペする必要があります。

おわりに

永住の地が無いことは承知の上ですが、一旦はこれで腰を落ち着かせようと思います。
使い勝手が違うため、いろいろ間違っているかもしれませんが、ご了承ください。

Qrunchにおける自身のブログページからタグを消す方法

2020-10-04T23:24:24+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchにおける自身のブログページからタグを消す方法 - 雑木林

TL; DR

次の2つを実施すれば良いです。

「よく使うタグ」モジュールの除去
記事下のタグ表示エリアの除去

はじめに

以前、Qrunchにおけるタグとカテゴリの使い分けについての記事を書きました。
その際、「タグはQrunchサービス全体の分類子として、カテゴリは自身のブログ内の分類子として、それぞれ使い分けができそう」と書きました。

Qrunchのタグとカテゴリの使い分けベストプラクティス

しかし、Qrunchのブログページにおけるデフォルトデザインには、何ヶ所かタグを表示しています。
そのため、タグをブログページでは使わないようにするための手法が、完全に使えるとは言えません。

本記事では、Qrunchのブログページからタグを消す方法を記します。

タグを消す方法

まず、デザイン修正方法を記します。

Qrunchでは、ブログページのデザインをカスタマイズできます。
ダッシュボードのサイドバーにおける、デザイン欄を選択してください。

すると、「デザインの設定」ページに飛びます。
この画面から、デザインを修正していきます。

Qrunchのブログページに存在するタグ表示エリアは、サイドモジュールとフッターの2箇所です。
それぞれについて、消す方法を記します。

サイドモジュールからタグを消す

サイドモジュールからタグを消す方法は、ワンクリックで可能です。

サイドバーにおける「サイドモジュール」欄の「よく使うタグ」項目を削除すれば良いです。

フッターからタグを消す

フッターのデザインは、カスタムCSSで消します。

サイドバーにおける「カスタムCSS」欄のテキストエリアに、 .content-module.tag-content-module.entry-content-module クラスを非表示にするCSSを入力します。

.content-module.tag-content-module.entry-content-module {
    display: none;
}

おわりに

これで、Qrunchのブログはカテゴリでしか分類できなくなりました！
タグをカテゴリをうまく使い分け、よいQrunchライフを送ってください。

Qrunchのタグとカテゴリの使い分けベストプラクティス

2020-10-04T23:21:48+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchのタグとカテゴリの使い分けベストプラクティス - 雑木林

TL; DR

タグはたくさん書こう。
カテゴリは少なく書こう。

はじめに

Qrunchで記事を書くときに、真っ先に出てくるタグをカテゴリ。

この2つの違いを正確に理解している人は、果たしてどれだけいるんでしょうか？
僕はわかりません！

ということで、Qrunchのタグとカテゴリの挙動から、どのように使い分けたらいいのか、そのベストプラクティスを探ります。

挙動調査

下記のような記事を作成し、タグとカテゴリの挙動を調べます。

事前知識

タグとカテゴリを知る前に、どうしても理解しておく必要があるものがあります。
それは、「Qrunch.net」と「Qrunchブログ」です（この2つの名称は、本記事独自のものです）。

「Qrunch.net」とは、いわゆるこの画面です。

Qrunchの記事として書かれた様々な項目が、一覧として表示されています。

一方、「Qrunchブログ」というのは、上記画面の記事を書いている各ユーザーが主体のブログのことです。
これは、各ユーザーごとにフォーマットが異なります。

Qrunchというサービスは、この「Qrunch.net」と「Qrunchブログ」の2つを併せ持つサービスのことです。
ということを前提に、話を進めていきます。

また、「Qrunchブログ」のフォーマットは、Editorialを利用しています。

カテゴリ

記事にカテゴリを付けると、「Qrunchブログ」における記事上部にカテゴリとして表示されます。

また、「Qrunchブログ」の側面に、既存の記事全てのカテゴリを「カテゴリ」という項目として一覧表示しています。

しかし、「Qrunch.net」の記事の方には、何も表示されません。
「Qrunch.net」を色々見てみましたが、それらしい項目は見つかりませんでした。

「Qrunchブログ」のカテゴリをクリックすると、同じカテゴリを付けている自身の記事が一覧表示できます。

つまりカテゴリとは、「Qrunchブログ」にのみ表示される分類子ということです。

挙動調査まとめ

タグは「Qrunch.net」と「Qrunchブログ」の両方に影響を与えるのに対して、カテゴリは「Qrunchブログ」にのみ影響を与えるみたいです。

また、タグもカテゴリも分類子であり、タグは「Qrunch.net」における他ユーザーの記事も表示できるのに対し、カテゴリは「Qrunchブログ」の自身の記事のみ表示できるようです。

ベストプラクティス

次のような使い方を提案します。

タグの使い方

記事におけるタグは、その記事に関連していそうなキーワードをできるだけ書いておきましょう。

これにより、次のような効果が期待できます。

「Qrunch.net」からのユーザー流入の向上
- 他ユーザーの記事のタグと同じタグを指定できれば、関連記事としてユーザー流入を見込めます。
「Qrunch.net」における他記事タグとの表記揺れの解消
- 大文字小文字を区別する仕様があったり、英語表記カタカナ表記といった表記揺れを解消することで、同じタグの指定率の向上が見込めます。

しかし、次のようなデメリットも存在します。

「Qrunchブログ」の関連記事が見つかりづらい
- 自身の「Qrunchブログ」で関連記事を見つけたい場合、どのタグで検索すれば良いかわかりづらい
タグの管理が大変になりやすい
- 全ての表記揺れに対応する場合、タグの表記揺れ対応項目を全て記録しなければ、タグから関連記事への遷移が困難になってしまいます。

上記デメリットを解消するのが、カテゴリの利用です。

カテゴリの利用

記事におけるカテゴリは、自身の「Qurnchブログ」における分類子として、自身が管理できる量だけ記載しましょう。

これにより、次のような効果が期待できます。

タグ乱立による「Qrunchブログ」関連記事検索性低下の防止
- 自身の「Qrunchブログ」内では、タグ検索ではなくカテゴリ検索を使うことで、「Qrunchブログ」内の関連記事の検索性を維持できます。
タグ乱立によるタグ管理性低下の防止
- 自身の「Qrunchブログ」内では、カテゴリ検索による関連記事への遷移を主軸とするため、タグ管理をする必要がなくなります。
- カテゴリ管理はする必要がありますが、カテゴリの量は少なく（管理できる量だけ記載）するため、管理の負担は少なくなります。
独自の分類子による「Qrunchブログ」内の検索性向上
- 自身の「Qrunchブログ」でしか通用しない独自の分類子を、カテゴリとして指定することにより、「Qrunch.net」のタグとは無関係そうな分類子を独自に定義できます。
- シリーズ物などに独自カテゴリを指定することで、「Qrunchブログ」の検索性の向上が見込めます。

カテゴリが「Qrunch.net」に影響を与えないことを逆手にとった活用法が考案できます。

おわりに

Qrunchにおけるタグとカテゴリは、影響範囲が異なります。
つまり、タグはQrunchサービス全体の分類子として、カテゴリは自身のブログ内の分類子として、それぞれ使い分けができそうです。

もちろん、タグの濫用は御法度ですよ。
他ユーザーの迷惑にならない程度に、全く無関係のタグは付けないようにしましょうね。

用法用量を守って、良いQrunch生活を送りましょう！

Qrunchの記事を間違えて全削除してしまった！！！から頑張って復活させた

2020-10-04T23:21:00+09:00

本記事は、 Qrunch からの移転記事です。

移転元: Qrunchの記事を間違えて全削除してしまった！！！から頑張って復活させた - 雑木林

それは起きてしまった悲劇

2020年4月25日、早朝4:30頃の出来事でした。
「数か月ぶりにQrunchでも書こう」
16日間もの長期休みを手に入れ、仕事終わりに動画鑑賞で夜明けを迎える直前に、ふと思い立ったのです。

記事の内容は、タグとカテゴリの整理についてです。
そのため、記事を書く前に、まずは自身のQrunch記事のタグとカテゴリの整理をしておきたかったのです。

一旦、既存の全記事に目を通し、タグとカテゴリを整理しました。
更新が必要な記事は更新ボタンを、そうでない記事は戻るボタンを、それぞれ押下して、整理していきました。

PlantUMLはこちら

@startuml
title Qrunchにおける記事更新の画面遷移

hide empty description

state "Qrunchトップ" as qrunch
' state "ダッシュボード" as dashboard {
    state "ダッシュボードトップ" as dashboard
    state "記事の管理" as console
    ' [*] -> dashboard.top
    ' dashboard.console -> [*]
' }
state "記事" as entry
state "更新完了" as updated
entry : do / 更新すべき箇所を確認する

[*] --> qrunch : https://qrunch.net を開く
qrunch --> dashboard : 自身のアイコンから\n「ダッシュボード」メニューを選択する
dashboard --> console : 「記事の管理」\nメニューを\n選択する
console --> entry : まだ見ていない記事を開く\n[未確認記事が有る場合]
entry -> updated : 更新する\n[更新内容が有る場合]
updated --> console : 「記事の管理」メニューを\n選択する
entry --> console : 戻る\n[更新内容が無い場合]\n/投稿未完了ポップアップの表示
console --> [*] : [未確認記事が無い場合]
@enduml

そして、「記事を書く」ボタンを押しました。

記事を書こうとしたところ、ちょっと思い立って、編集画面で1箇所も手を入れずに、戻りました。
すると、ステートマシン図における「戻る」契機実施時と同様、「投稿未完了ポップアップ」が出たので、キャンセルを押下しました。

「記事の管理」画面に戻ってくると、何やらタイトルも内容も書いてない記事が生成されているようにみえるじゃないですか（再現画像です）。
（赤枠で囲った箇所です。 ~~え、どう見てもテーブルヘッダーですか？夜更かしで疲れてたんですよ！~~）

深く考えずに、チェックを入れます。
すると、チェックを入れたすぐそばに「記事を削除する」メニューが登場しました（再現画像）。

この時、僕は下の欄にある全ての記事にチェックが付いていることに気づきませんでした。
深く考えず、削除しようとします。

すると、Qrunchくんは丁寧に「削除した記事は戻せません」と警告してくれます。
優しいです。

でも、僕は空記事を削除したいので、気にせずOKします。

押した後、すぐには画面上に変化がありません。
空記事もそのまま残っているので、不思議だなと眺めていました。

直後、気づきました。
「あれ、この欄って、空記事じゃなくてテーブルヘッダーじゃね？」と。

焦るものの、まだ画面上には残っています。
一縷の望みをかけ、リロードします（悪手）。

すると、リロードするたびに、記事が消えていくではありませんか！
焦りますが、それでも正常性バイアスにより、リロードを続ける手は止まりません。

なんということでしょう。
綺麗になりましたね。

エンジニア魂に火がつく

焦りました。

記事が無くなることで被る被害は、下記の通りです。

記事の内容というドキュメントが消える
記事の内容を再び第三者に見てもらう機会が消える
過去の栄光が消える

1番目と2番目の理由により、ドキュメントが消えるのは非常に困りました。
また、プチバズった記事により今月（2020年4月現在）のQrunch「今日／今週／月間トレンド」第1位を総なめしたことで、僕の精神が支えられていたこともあり、3番目の理由によって非常に落胆してしまいました。

こんな時、どうすればよいでしょうか？

僕が最初に考えたのは、Qrunchのフィードバックで、全記事消しちゃいましたと泣き言を垂れることでした。
しかし......
初期のころから応援している／何度もTwitterで記事を拡散してくれる／ときどき拍手を50個くらいくれる......
そんなQrunch運営に「泣きつく手段がフィードバックかよ」と冷静になり、踏みとどまりました。

次に考えたのが、報告記事にすることでした。
Qrunch運営なら、きっと見てくれるだろう。
そんな期待を込めて、「消えちゃいました！助けてください」という報告記事を書こうと思いました。
~~（既にキャプチャ画像にタイトルだけの記事の下書きを作ってるのが見えてますね）~~
これなら、別に見てもらわなくても、ポエム記事として書けば正当化できます。

しかし、書こうとする直前で思いつきました。
せっかくなら、エンジニアらしく、記事を復活させてみよう、と。
運営の手間を取らせなくても、自分だけでできることをしてみよう、と。

ここで、僕の記事の内容は変わりました。

Qrunchの記事を削除してしまった際の手順

長い前段は終わりです。
ここからが、本記事の主題です。

すなわち、もしQrunchの記事を削除（全削除）してしまった場合、どうすればよいかの手順をここに記します。
僕が実際に行った事のうち、成果があったものについてのみ書きます（効果がなかったけど試してみたことについては、後程書きます）。

動作確認環境を、以下に記します。

Windows 10 Pro: version 1909, OS Build 18363.778
Google Chrome: version 80.0.3987.163（Official Build）, 64 ビット

ブラウザ上のWebページを遷移させないように保存する

まず大切なのは、現場保存です。
やみくもに動いてしまうのは、逆効果になりかねません。

まず、いま開いているQrunchの画面を表示しているブラウザ（タブ）を、残しておきましょう。
Chromeの場合、裏で待機しているタブ画面を呼出す際に、強制的に再読込する場合があるため、別ウィンドウで置いておくと良いでしょう。

また、HTML形式でローカル保存しておきましょう。
もし記事が残っている画面で保存できれば、記事のタイトル／タグ／URL等を記録できます。

僕は、偶然にも別タブでQrunchブログを開いていたため、そちらをローカル保存しました。

編集画面を戻る

偶然にも、僕は直前まで記事の編集をしていました。
そこで、開いているタブを戻ると、なんと、記事がそのまま残っているじゃないですか！

しかし、「記事を更新する」ボタンを押下すると、下記画面に遷移してしまいます。

そこで、記事の内容をコピーし、別記事として新規作成することで、記事の内容を避難させました。
（新着記事を荒らしてしまいました、すみません。）

僕の場合は、全8記事中6記事を更新したため、6記事はそのまま再作成できました。

Googleキャッシュに頼る

残り2記事ですが、うち片方の記事は大した内容を書いていないため、無くなっても問題ありません。
しかし、もう1つの方の記事は、アドベントカレンダーにも連携しており、またビューも多かった、思い入れのある記事でした。
この内容が消えるのだけは避けたかったです。

そこで、閃きました。
ビューが多いなら、Googleキャッシュにあるんじゃないだろうか？と。

調べてみると、なんと......
ありました！！

キャッシュしているWebページのHTMLを展開し、内容をタグごと直接記事にコピペすれば復活できます。

これで、ほぼ全ての記事を復活できました。

まとめ

記事の内容は復活できましたが、記事の記録は復活できませんでした。
しかし今は、ドキュメントさえ残ってくれたら、あまり気にすることはないかなと考えています。
トレンド1位という記録に浮かれすぎていた自分には、いい薬だったかもしれませんね。

まとめると、以下の通りです。

Qrunchの記事を全削除しちゃいました
頑張って復活させました
一部復活できなかったものがありますが気にしてません
仮に戻せるとしても、現状で特段困っていないので問題ありません

追記

なんと、Qrunch開発者である @codomisu さんから、直々にコメントをいただきました。
バックアップがあるとのことだったので、復旧をお願いしたところ、全て復旧していただけました。

しかも、僕が頑張って復活させた記事については、下書きへと変更してくださる気の利きように、感服いたしました。
復旧を確認次第、手動復活記事は消そうと思っていたので、ありがたかったです。

その上、実はここで一切触れていない下書き記事についても、復旧していただけました！
下書き記事については、そもそも要らないかなと無視していたのと、公開されてないし無理だろうと諦めていたので、まさか戻ってくるとは思いませんでした。

新たにまとめると、運営に泣きつけば全て解決していたのでは？というオチでした！！！
~~@codomisu さんには頭が上がりません。またファンになってしまうじゃないですか。~~

以上です、ご清覧ありがとうございました。

おまけと追記

要望

Qrunch運営さんがこの記事を読んでくれた時のために、要望を書いておきます。

記事一覧のテーブルヘッダーは、色を付けるなど、テーブルデータとの差異を強くしてほしい
記事削除時のメッセージは、別の場所に表示してほしい
（余力があれば）ユーザーによる削除処理ロールバックを可能にしてほしい

Qrunch開発者の @codomisu さんが検討してくださるとのことです。
ありがとうございます！

旧記事URL

削除してしまった旧記事のタイトルおよびURLを、下記に記します。
保存できなかった記事については、 ⭐ 絵文字を併記しています。

こちら、 @codomisu さんの手動復旧により、全て回復しました。

試してみたが駄目だったこと

「Qrunchの記事を削除してしまった際の手順」として試してみたが効果が無かったものについて、下記に示します。

Chromeキャッシュの呼出し

Chromeのキャッシュに記事内容が保存されていることを期待して、 ChromeCacheView を使ってみました。
実際に保存されている記事もあったものの、その全ては別手段で取得できるものでした。

また、キャッシュの中からjQueryを発見したので、URLが直接書いてあったりしないかと期待して探したのですが、当然のようにありませんでした。

アーカイブサイトの利用

アーカイブサイトを閲覧するために、僕が時々使う Internet Archive: Digital Library of Free & Borrowable Books, Movies, Music & Wayback Machine を利用してみました。
実際には、Qrunchトップページしか保存していないようでした（ブログの規模によって異なる可能性あり）。

ありがとうQrunch

2020-10-04T23:03:43+09:00

本記事は、 Qrunch からの移転記事です。

移転元: ありがとうQrunch - 雑木林

TL; DR

Qrunch のことは、忘れません。

はじめに

Qrunch がサ終するみたいですね......

サービス終了のお知らせ | Qrunch（クランチ）

非常に悲しいですが、「始まりがあるものにはすべて終わりがある」のは世の常ですから、まずは運営の皆様にお疲れ様でしたと言わせてください。

お疲れ様でした。

サービスを閉じるということは、いろいろな話があったはずです。
僕がこうして欲しいとか、こうして欲しかったとか、今更言っても詮無い事ですから。

ただ、なぜ僕が Qrunch を選んだのか、これは書く価値があるはずです。
かつての記憶を頼りに、歴史を遡ってお話ししようと思います。

Qrunch 最後の記事になります。

Qrunch の登場

Qiita のポエム記事問題で沸いていた2018年ごろ（まあ、この問題は数年サイクルで沸いてましたが）、よく同サービスとして比較される Crieit とほぼ同時期（と記憶してます）に、 Qrunch は登場しました。

Qiita のポエム記事問題についての詳細は、他の方の話を聞いていただければとして、端的に言えば「技術記事」の定義の食い違いです。
これを解決する手段の1つとして、以前は（もちろん今でも）技術記事以外も書けるブログに（部分）移行する手法がよく取られていました。

しかし、我々が欲していたのはブログではなく、技術の集合知サービスです。
自身が技術系の記事を書き、また同様の他者の記事を簡単に読めるような、そんなサービスです。
~~ついでにいいねも欲しい！~~

そのような要求に答えたのが、 Crieit であり、 Qrunch でした。

Qrunch との出会い

例に漏れず、 Qiita で記事を書いていた僕も、技術記事以外を書きたい欲求が出てきました。

特に、僕がメインで書きたいと考えていた UML 関連の記事は、定義や説明が多く、また、ソースコードの登場が少ないため、 Qiita において技術記事ではないと言われる恐れがありました。
他にも、他愛もないメモ書き程度のことも、 Qiita では不適切な気がしていました。

個人的には、技術記事の判定に、ソースコードの登場有無は使えないと考えています。
上流工程で利用する UML や、超上流工程と言われる要求分析、さらにはコミュニケーションの取り方などについても、ソースコードは登場しませんが、僕は技術であると認識しています。
しかし、自分がよければ問題ないかと言われると、不安でした。
つまり、記事を書いても（公開しても）問題ないという、安心感を欲していました。

その中で、 Crieit と Qrunch が同時期に登場しました。
どちらでも良かったのが正直ですが、僕は Qrunch を選びました。

なぜ Qrunch を選んだかというと、個人運営である点が最も大きかったです。
そこには、大きく2つの考えがあったからです。

運営とユーザーの距離が近いのではないか？

大きなサービスほど、運営とユーザーの距離は遠くなりがちです。
ちょっとしたことを知らせたり、小さな要望を伝えるために、メールなどの大掛かりな作業をしたくはありません。

個人運営であれば、運営とユーザーの距離がそこまで遠くじゃないのではないか？と考えていました。

応援したい

作ったばかりのサービスの運営とは、すごく大変なものです。
それを応援したい気持ちが、純粋にありました。

Qrunch を使ってみて

運営との距離間は、想像していた以上に近く、凄くありがたかったです。
特に、記事を全消ししてしまった際は、わざわざコメント欄で返信していただき、より運営への信頼感が増しました。

小さなサービスだからこそかもですが、日間／週間／月間ランキングトップを飾ったこともありました。
嬉しかったですし、仲間内に自慢もできて、良い経験を得られました。

たしかに、何度か不具合が長引いたことはありましたが、そこは個人運営であることを考えれば、大きな問題と捉えていませんでした。
むしろ、応援欲が高まったくらいです。

サービス終了直前までサポート機能追加をしてくださる運営には、感謝しかありません。

投稿コンテンツのエクスポート機能の提供を開始しました | Qrunch（クランチ）

おわりに

短い間ですが、楽しい UX をありがとうございました。