「Crieit」の記事 - Crieit

Crieitを閉鎖します

2024-05-01T18:35:39+09:00

Crieitは閉鎖します。

最近はほとんどがよくわからない宣伝記事みたいなものばかりになり有害性ばかりが増えていくだけになっているため、Crieitを閉鎖することとしました。

エクスポート機能を作成だけしようとも思いましたが、恐らくほとんどのユーザー様がエクスポート機能が無くてもコピペで済む数の記事の投稿になると思いますので、開発している時間が取れないこともありエクスポート機能の提供は行わないこととしました。

必要な方は手動でエクスポートしますので直接お申し付けください。

閉鎖時期は未定ですが数ヶ月したら特に予告なく閉鎖させていただきます。

ご利用していただいた方々とはとても楽しい時間を過ごせたことを思い出しました。まことにありがとうございました。

Crieit用ユーザスタイルシート

2021-01-09T12:23:32+09:00

Stylus でスタイル当ててみました。コード部分は等幅になっているのが好きなので……。

pre, code {
    font-family: monospace !important;
}

p > code, li > code {
    color: #824 !important;
}

/* プレビューで hr が見えるように色を調整 */
.tui-editor-contents hr {
    border-top: 1px solid #ddd;
}

.hljs-comment {
    color: #99a;
    font-style: normal;
}

以下は見栄え確認用のサンプル。

fdsa fdsa fdsa

fdsa fdsa fdsa

https://crieit.net/posts/Crieit-5ff921b4cf458

# コメント

Qrunch から Crieit に引越しする

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

TL; DR

Qrunch から引越しました。

はじめに

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

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

引越し手順

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

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

Qrunch 記事のエクスポート

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

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

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

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

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

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タグごとにコピペする必要があります。

おわりに

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

有料記事を販売できるようになりました

2020-04-30T08:59:39+09:00

Crieitで有料記事を販売できるようになりました。記事の前半を無料、後半を有料という形で販売することが可能です。下記は実際の有料記事のサンプルです。

https://crieit.net/posts/GCE-Cloud-Run

利用方法の解説を行います。

仕様

Stripeという決済サービスの、Stripe Connectという機能を利用しています。販売者はStripeに登録して独自にコンテンツを販売する形となります。CrieitはConnectを利用することで場の提供のみを行います。手数料は ~~10%~~ 現在0%（Crieit分）＋3.6%（Stripe分）です（Stripe側に変更がある場合はそちらに準じます）。

販売者設定

有料記事を作成するためにはまず事前に販売者設定を行う必要があります。ユーザー設定の「記事販売者設定」にて設定します。

https://crieit.net/sales-profiles/create

Stripeへの登録

次にStripeへの登録を行います。

一部難しい部分がありますので、下記の記事を参考に入力を行います。

https://crieit.net/posts/stripe-connect-registration

一通り入力し、登録ができれば準備は完了です。

Stripeについて

あくまでもユーザー自身が販売事業者となります。StripeアカウントもCrieitとはConnect以外では何の関係もなく、自由にユーザーが利用するものとなります。

有料記事の作成

次に有料記事の作成方法について説明します。まずは記事編集画面にて「オプション」を開きます。

販売設定が完了していると下記のような有料記事のメニューが追加されています。

こちらにチェックを行い、価格を設定してください。販売時にはこの価格から手数料が引かれます。

チェックを入れたあとは、下記のように無料部分、有料部分の編集を切り替えるボタンが現れますのでそちらで切り替えつつ編集を行います。

あとは通常通り記事を登録すれば有料販売が可能です。売上の確認はStripeにログインして行ってください。

その他

当サービスは広告を表示していますが、有料記事の場合は読者がコンテンツに集中しやすいよう、ページ上の広告は非表示としています。

まとめ

有料記事の販売方法を解説しました。まだリリースしたばかりのため、問題や不明点があれば一緒に改善していきたいと思いますので、ぜひフィードバックをお願いします。

記事は無料部分も有益にし、そこだけでも読めて満足だった、と思ってもらえるようにしておくと、有料部分も購入してもらいやすくなるのではないかと思います。

Stripeアカウントの連結手順

2020-04-27T20:36:57+09:00

Stripeと連携する処理を進めると下記の画面に遷移します。

ここでStripeアカウントを作成しますが、画像の右上にあるリンクから既にお持ちのStripeアカウントを利用することも出来ます。

基本的に全ての入力内容は、あなたご自身が事業を行う前提での質問となります。「お客様の事業」はあなたが記事を販売する事業、「顧客」はあなたの記事を購入したユーザーのこととなります。あくまでもCrieitとあなたの事業の手数料連携のみという扱いになり、Crieitがあなたの事業の管理及び保護を行うものではありませんので、その前提で入力を進めてください。

コンプライアンス関連の質問

まず最初にコンプライアンス関連の質問に回答します。こちらは自動的に下書きされますのでゆっくり入力して途中であとから続きを進めることも可能です。

基本的には下記のように回答すれば問題ありません。その他は適宜確認のうえ適切なものを選択してください。

今後、顧客のカード番号を取り扱う予定はありますか？

→いいえ

今後、お客様の事業で、または他事業の代理として決済を生成する接続アプリケーション (Connect Standard) で、顧客の身元を特定することを目的として、何らかの種類の付加的な検証手段を利用する予定はありますか？

→いいえ

今後、お客様の事業で、または他事業の代理として決済を生成する接続アプリケーション (Connect Standard) で、決済ごとにカードのセキュリティコードを要求する予定はありますか？

→はい

今後、お客様の事業で、または他事業の代理として決済を生成する接続アプリケーション (Connect Standard) で、疑わしい配送先住所を検出するための対策を講じる予定はありますか？

→いいえ

本番環境利用の申請

ご自身が事業者としての入力を行ってください。Crieitの情報を書く部分はありません。「ビジネスの Web サイト」はCrieitのご自身のプロフィールページURLを使って頂いて大丈夫です。

Nowで運用している画像配信サーバーにリサイズ機能を追加した

2020-04-13T08:27:03+09:00

Cloud Runに引っ越したことで重いページとそうでないページがはっきりしてきた（以前は全てのページが重くて逆に気にならなかった）のだが、その際にLighthouseで調べているとPerformanceのスコアが非常に悪く、画像の読み込みにめちゃくちゃ時間がかかっていることに気づいた。

トップページの記事ランキングなどにはサムネイルを表示していたりするのだが、アップロードされた画像をそのまま表示していた。中には横幅2000とか3000以上の画像もあったりする。そのためそういう画像がいくつも同じページ内にあると当然読み込みに時間がかかるし、Wifiじゃない状況でスマホで見たりすると通信容量の消費も激しくなるだろうし全然ユーザーフレンドリーじゃない。

ということで丁度モチベーション切れだったこともあり、せっかく気になってきたので対応してみることにした。

画像配信サーバーの改造

アップロードされた画像は全てZeitのNowで運用している画像配信サーバーで配信している。

NowのエッジキャッシュでCloud Storage節約サーバー作成

ということで、これを改造してリサイズに対応できればよいのではないかと思った。具体的には通常の画像のURLの後ろに ?mw=700&mh=300 のように、パラメータを指定した場合だけリサイズするようにする形。

リサイズに使用したパッケージ

リサイズと言えばImageMagick（現在はgm？）かなと思ったが、一応調べてみたところsharpというパッケージも非常に人気があるらしかったのでそちらを使ってみることにした。

lovell/sharp: High performance Node.js image processing, the fastest module to resize JPEG, PNG, WebP and TIFF images. Uses the libvips library.

一番シンプルな形だとこんな感じでいける。BufferをリサイズしてBufferにするパターン。

const resized = await sharp(image).resize(width).toBuffer()

めちゃくちゃ簡単。ImageMagickだとサーバーに何かインストールしておかなきゃいけないんじゃないかとか色々気になったりするが、特にそういう必要もない。

実際の実装方法

横幅だけを指定する場合

記事ページなどは許可する最大の横幅を指定し、それ以上だったらリサイズする形にした。

さすがにfitでこの条件指定までは出来なかったため、チェックは自分で行った。さすがに画像を変換する時にサイズの取得は必要になるため、多分サイズを取得する機能があるだろうと思ったがやはりあった。ということで下記のような処理を作った。metadataというメソッドでサイズや画像の形式など、色々な情報が取れる。

async function resizeByMaxWidth(image, maxWidth) {
  const sharpImage = sharp(image)
  const metadata = await sharpImage.metadata()
  if (metadata.width < maxWidth) {
    return image
  }

  return await sharpImage.resize(maxWidth).toBuffer()
}

まとめ

ということで色々対応したが、スコアは全然改善しなかった。他にもAPIで取ってきたデータのユーザー画像のサイズが大きかったりして、対応しきれていない部分がある。

とはいえ、やろうと思えばあらゆるURLの画像を同様の配信サーバーを作ってプロキシすることで縮小できるため、他にも色々使い所はありそう（今回は自分用のリポジトリに実装しているので前述URL内で公開しているリポジトリには反映していない。機能的にもブレるため）。Nowなのでサーバーの管理も不要だしCDNキャッシュしてくれて高速だし本当に楽。

GCEからCloud Runに引っ越してみた

2020-04-06T07:53:02+09:00

当サービスCrieitをGoogle Compute EngineからCloud Runに引っ越ししてみました（2020/4）。選定理由、実際にやったこと、懸念点などを色々書いてみます。

費用についても書きたいのですが、まだ引っ越ししたばかりのためわかりません。１，２ヶ月ほど経ったら追記しますので気になる方はフォローやブックマークなどしておいてください。

※当記事は一部有料です。後半の実際にRunを使う方しか興味がなさそうな内容あたりは有料となっています。使ってみた感じやRunに関係ない引っ越しメモ等は無料です。費用については無料部分に書きます。

元々の構成

Compute Engineの1台構成です。f1-microインスタンスを利用しておりMySQLもこの中にインストールしているのでAlways FreeのおかげでWebサーバー、DBサーバー自体は無料運用です。ファイルなどはStorageです。

ちなみにLaravelで作られており、詳しい構成は下記に書かれています。
Crieitの構成

新しい構成

WebサーバーにCloud Run、DBサーバーはCloud SQL（db-f1-micro）にしました。Cloud SQLは無料枠がないため費用がかかりますが、とりあえず広告費用内でまかなえるので以前からそのうち使おうと思っていました。全部１台のサーバーに入れているのはやはりなんとなく怖かったため。

なぜ引っ越したのか

たまに落ちる

Compute Engineは普通のサーバーですので、やはり何らかの状況によって時々落ちるというかフリーズします。多分なにかボットのアクセスが激しい時にスワップしてしまってそのままになってしまうのだと思いますが。

とは言っても約２年くらい運営してきてそんな感じで止まることはめったにありませんでした。たまに数分だけ重いとMackerelから通知が来たりはしていましたが。ただ、最近1日に2回も大きなフリーズがあったので、さすがに怖くなったのが引っ越すことになった一番のきっかけかもしれません。

むちゃくちゃ遅い

リリースする時に深く考えず、us-eastに構築してしまいました。これのせいでもうとにかくすごく遅い。あらゆるページで表示されるまでに1秒位かかっていました。こちらも元々そのうちwestに引っ越したいなと思っていました。

なぜCloud Runを選択したのか

サーバーを管理したくなかった

最初から決めていたわけではなく、App EngineとCloud Runを試して決めよう、という感じでやっていました。どちらもマネージドで、自分でサーバーを管理する必要がありません。とにかくCloud SQLに費用を払うことになってでもサーバーを管理したくなくなったというのが一番の理由です。

結局Runの方を選んだのですが、理由としてはApp Engineはデプロイするために、結構ローカル開発環境を本番向けに変えたりスイッチしたりする必要があります。もちろんデプロイを自動化すればいい話ですが、そもそもその前に一旦試してみるのが面倒になってやめました。最初にCloud Runの実験をしていたのですが、そちらはDockerイメージ内で適当にファイルを調整すればいいのでローカル環境を汚さず簡単に試せて非常に良いと感じました。

デプロイが簡単

ローカルでコマンドをいくつか実行するだけでデプロイできます。バッチとしてまとめているので１コマンドで行けるようになりました。

@echo off
FOR /F %%i in ('git rev-parse HEAD') do set HASH=%%i
set IMAGE=gcr.io/プロジェクトID/イメージ名:%HASH%

@echo on
call gcloud builds submit --tag %IMAGE% --project プロジェクトID
call gcloud run deploy Runのサービス名 --image %IMAGE% --project プロジェクトID --region asia-northeast1 --platform managed --quiet

今回はやっていませんがCIによる自動化もコマンドベースなので簡単そうです。

GitHub Actionsを使うとCloud Runへのデリバリが最高に捗るぞ🚀 - Qiita

東京リージョンが使える

App EngineもCloud Runも東京リージョンが使えます。GCEのようにアメリカだけ無料、とかではないので安心です。ただまあネットワーク料がかかってくると思いますのでそちらは気になりますが。

実験したところ元々1秒くらいかかっていたページの表示が300～500ミリ秒くらいになっていました。すごく速いというわけではなさそうですが、とりあえず元々遅すぎたのでだいぶいい感じにはなりました。

安い？

Cloud Run自体はこんな感じで実際に使ったリソースの分しか消費されないので無料枠内で結構いけてしまうのかな…？　と感じました。これはでも実際どうかわからないため、１、２ヶ月ほどしたら追記します。

追記）ネットワーク料金が14円で、CPU、メモリは費用内で無料でした。やはりデプロイ時に設定するメモリ料での計算でなく、実際に使った量だけみたいです。

ロールバックも簡単

これは実際に使ってみて気づきましたが、デプロイのリビジョンが残っているため何か不具合などがあってロールバックしたくなったときも簡単に戻すことができます。このあたりはGAE等ほかの簡単デプロイ系サービスでも同じかもしれませんが。

実際にやったこと

ストレージの引っ越し

まずはアップロードされた画像が入っているストレージだけ先に引っ越しました。というのも、Crieitの場合アップロード画像は直接ストレージのURLを使うわけではなく、Now経由でCDNキャッシュさせて費用を節約させています(NowのエッジキャッシュでCloud Storage節約サーバー作成)。ということで、引っ越しても画像のURLが変わるわけではありませんし、独立して先に引っ越しできるため先に移動しました。

具体的には下記の方法です。転送機能が用意されています。S3やAzureからも可能のようです。Cloud Storage間であればコマンドでも可能です。僕の場合は1GBもなかったので一瞬で終わりました。

バケットの移動と名前変更

通信料金も変わると思いますが、引っ越すまでの期間であればたいして影響も無いでしょう。とりあえずこれで一つやることが完全に減らせました。

ファイル保存している部分の調整

セッションやキャッシュはデフォルトでファイル保存になっています。しかしCloud Runは必要に応じてインスタンスが立ち上がったりするためファイルだと正常にセッションの維持などができません。そのためデータベース保存に変更しました。具体的にはまず下記でマイグレーションファイルを生成して実行します。

php artisan session:table
php artisan cache:table

そしてあとは環境変数をdatabaseに変えます。

CACHE_DRIVER=database
SESSION_DRIVER=database

まあここは他にもRedisを使ったり自由で良いと思います。

あとはログの出力も変更しておきます。これもファイルだとログを見ることもできないため、stderrにしておきます。こうすると自動的にCloud Runのコンソール上でログを見ることができます（その他にもいくつか方法はあります）。

LOG_CHANNEL=stderr

DBの設定

今回はCloud SQLを使っています。接続にはCloud SQL Proxyを使っています。例えばLaravelの場合、下記のようにソケットを指定します。

DB_SOCKET=/cloudsql/インスタンス接続名

インスタンス名はCloud SQLの詳細画面で確認できます。

DBの移行

DBの移行は、元々使っているGoole Compute EngineにMySQLをインストールしていたので、mysqldumpを利用しました。サーバー上のデータをmysqldumpでダンプし、そしてcloud_sql_proxyを実行するとCloud SQLにソケットでアクセスできるようになりますので、それでインポートしました。具体的なインポート方法は下記のようになります。

mysql -u ユーザー名 -p -S /cloudsql/インスタンス接続名 < dump.sql

参考）
Cloud SQL Proxy を使用した接続
 GCEでcloud_sql_proxyが実行できない時

メンテナンスモード

ストレージもDBも、ユーザー操作中に移行を行うと一部データが失われてしまう可能性があります。そのためメンテナンスモードにしておく必要があります。

Laravelの場合、メンテナンスモードのコマンドが元々あるようなのでそちらを利用しました。メンテナンスモードに入るときは php artisan down 復帰するときは php artisan up です。

downの場合はメッセージや許可IPなども指定できます。

Maintenance Mode - Configuration - Laravel - The PHP Framework For Web Artisans

引っ越しの場合は新しいサーバーにアクセスが行くようになったらもう古いサーバーは使われませんので、upする必要もないかもしれません。

結局ネックとなるのはDBの同期です。Cloud Runの設定も含め、これ以外で事前にできることはなるべく済ましておきました。

プロキシ用の設定

元々Nginxを使っていた場合などは関係ない場合もありますが、プロキシ経由でなく直接アプリケーションにアクセスさせていた場合、このあたりの設定をする必要があります。例えばLaravelではTrustProxiesというミドルウェアのproxiesを許可するように設定しておく必要があります。

    protected $proxies = '*';

その他うまく動かない場合はSSLやホスト名の設定も問題ないか見てみる必要があります。Nginxのパターンとはちょっと違う可能性もありそうです。

バッチ等はどうしたか

Cloud RunはSSHアクセスできませんので、コマンドの実行や定期処理などは考える必要があります。一応公式としてはCloud Schedulerを使うということになっています。

Running services on a schedule

ただし、httpアクセスになるためちょっとコードを調整したりする必要もあり面倒です。そのため、今回はGCEからの移転ということもあり、定期処理や時々コマンドを実行したいときはもうそのGCE上で行うようにすることにしました。アプリケーションのDB接続もCloud SQLに行うようにしてあります。リージョンも違うので遅いとは思いますがどれも一瞬実行するだけなので問題は恐らく無いでしょう。Cloud SQLへの接続はcloud_sql_proxyをSystemdでサービス化して行っています（参考 GCP Cloud SQLにCloud SQL Proxyで接続しよう。Systemd化してデーモン化！ | システムガーディアン株式会社）。

以下は有料です。下記のような内容を書いています。

実際に作ったDockerfileの例（Laravel & Apache）
vendorフォルダが無視されることへの対処
.envファイルが無視されることへの対処
ポートの指定について
Dockerイメージのビルド方法（Cloud Buildの利用）
Cloud Runのサービスを作成する具体的な手順とエラーにならないようにするための注意点
独自ドメインの利用方法
ステージング環境の作成例
Cloudflareで525 SSL handshake failedエラーが出た場合

Webサービスを1週間で作るイベント開催の概要

2020-02-21T08:38:19+09:00

参加者それぞれがちょっとしたWebアプリを1週間で作って見せ合うイベント（オンライン）を開催します。

Unity 1週間ゲームジャムを参考にさせていただきました。それのWebサービス開発版みたいなものです。

開催概要

開催初日にお題を発表します。そのお題に沿って何かしらのWebアプリを作成していただきます。

1週間しかありませんので、練習程度に作ったちょっとした1機能のものでも、不具合だらけでほとんど動かないようなものでも大丈夫です。逆に余裕があれば大作を作っていただいても大丈夫です。他の人とネタがかぶっちゃっても全然だいじょうぶです。また、1週間かける必要があるわけではないので1日だけ作ってみる感じでもOKです。

とにかくお気軽に参加していただき、たくさんの作品が集まれば良いなと思っています。今まで何も作ったこともないしプログラミングも勉強し始めたばかりだよ、という方にもどんどん参加していただきたいです。

開催スケジュール

7/19（月）0:00～7/25（日）23:59の1週間
7/19の0時にお題を発表

参加方法

特に参加申請はありません。Webサービスが公開できたらイベント用ボードに投稿して発表してください（締め切りを過ぎてしまっても投稿していただいて大丈夫です）。

（今回）
（7/19～7/25）１週間でWebサービスを作るイベント - お題「バケーション」
投稿ページはこちら

（過去の例）
（2/22～2/28）１週間でWebサービスを作るイベント - お題「増やす」
（9/7～9/13）１週間でWebサービスを作るイベント - お題「2」
（5/18～5/24）１週間でWebサービスを作るイベント - お題「Like」
（3/9～3/15）１週間でWebサービスを作るイベント - お題「Home」

自分の作品の投稿が終わったり、ちょっと休憩したい時にでも他の方の投稿を見てみると面白いと思います。

また、開発中はTwitterなどで #web1week というハッシュタグで開発時のつぶやきをしていただくとみんなで楽しめると思います。画像や動画を一緒につぶやくと面白いかもしれませんし、やったことがない方は練習がてらやってみるとよいでしょう。

1週間は想像以上に時間が少ないので、早めに終わらせて、早めに一旦公開テストまでしておく、というぐらいにしておいて、余裕があったら拡張していくような進め方が安心です。

投稿について

投稿した内容にアップロードされた画像が含まれている場合、その最初の画像を一覧ページや、Twitterにシェアした際に表示される画像として利用します。

単にタイトルとリンクを貼るだけでなく、スクリーンショットを貼ったり、サービスの説明や、どういった技術を使って作ったかを書いたりするともっと楽しく見えると思います。

フィードバック

見た際に、いいなと思ったら下記のようないいねボタンがありますので、是非ボタンを押してフィードバックしてあげてください。フィードバックがあると作った人の励みになります。

また、コメント機能もありますのでそちらで直接言葉で伝えるのも良いと思います。

その他、Twitterボタンもありますので気になったものがあったら是非Twitterでシェアしてください。

事前の準備

とくにはありませんが、未経験の方はなにか適当に作ったものを公開するところまで試しておいたほうが良さそうです。

あとは当サービスへの登録も事前にお願いします。テストボードで書き込みのテストもしていただくことも出来ます。

何も作ったことがない方

簡単にサービスを公開できるサンプルの記事を書いておきました。参考になる部分があれば試してみてください。（公開方法は自由ですのでこの方法である必要はありません）

あとはCodePen等でも簡単に作ったものを公開できます。

https://codepen.io/

サンプルも解説してみました。

まとめ

以上になりますが、不明点などあればお気軽にコメントでもTwitterでのリプライなど送ってください。

12月にAdvent Calendarを開催します

2019-10-24T22:18:21+09:00

もうすぐ年末ですね。去年CrieitでAdvent Calendarを開催しましたが、今年も開催を予定しています。

昨年との違い

誰でもカレンダーを作ることができる

去年は何でも書いていいCrieit Advent Calendarというカレンダーと、個人開発サービスに用いられている技術 Advent Calendarの２つのカレンダー固定で開催していました。

Crieit Advent Calendarは今年も僕が作りますが、あとはQiitaやAdventarと同様に誰でも自由にカレンダーを作れるようにしています。

予約投稿可能

去年は当日までに下書きを書いておいて、それを忙しい当日の朝に投稿し、カレンダーに登録、という非常に使い勝手の悪い仕様で利用していただいていました。今回は予約投稿できるようにしているため、カレンダーに登録して下書きを指定して頂ければ当日の7時に自動的に記事が本登録されるようになっています。

スケジュール

11/1～　カレンダーに予約開始、及びカレンダーの作成機能公開
12/1～　カレンダー進行

今年のスタンス

去年はCrieitがリリースして間もないということもあり、かなり多くの方にご協力いただきました。年末の忙しい時期にバタバタとしながら投稿していただいたことに感謝しています。しかし今年はリリース後１年たち、２度めの年末となりました。あとはもう無理せず、Advent Calendarものんびり運用していければいいかなと考えています。

盛り上がり的には絶対的にQiitaやAdventarでAdvent Calendarに参加していただいた方が楽しいと思います。ただ、そちらは敷居が高くて投稿しづらい、という場合があると思います。また、そちらにはなんとなく参加したいものがないし、書きたいものがガチポエムみたいなものだとするとサービスの色にマッチしていないという場合もあると思いますので、その場合は是非CrieitのAdvent Calendarを利用して頂ければ幸いです（なんならAdvent Calendarの機能を無視して非公開ボードで投稿していただいても良いと思います）。

僕が立てるCrieit Advent Calendarは前年と同様、どなたでも何でも投稿していただいてOKです（埋まらない場合は僕が瀕死で全部埋めます）。もちろん一人でAdvent Calendarを埋めたい、という場合は自分用のカレンダーを作って挑戦していただいても大丈夫です。また、特定のジャンルの記事があつまるといいなぁ、と思う場合にも是非カレンダーを作ってみてください。僕の知識で分かるものがあれば僕は絶対投稿します。

ということで、ゆるい感じでやっていきたいと思いますので、何にも気兼ねなく、各々が思うがままに気軽な感じで適当にシステムを使って頂ければと思います。

下書きを公開できるようになりました

2019-09-19T09:35:34+09:00

下書きを公開できるようになりました。

記事の登録画面のオプションボタンをクリックすると開く設定画面に「下書きを公開する」チェックボックスが追加されています。そちらをオンにすると下書きが公開されます。

とりあえず書きかけのものを見てほしい場合などに利用できます。

ユーザーのプロフィールからも一覧できます。

続きが読みたいボタン

続きが読みたいボタンを押せるようになりました。

非ログインでもクリックでき、何度でもクリックできます。

随時開発中

下記は実装するかどうか検討中です。

コメントができるようにする
いいね

ユーザーをフォローする機能

2019-06-22T22:50:20+09:00

ユーザーをフォローする機能を作成しました。

使い方

ユーザー詳細画面でフォロー及びフォローの解除を行うことが出来ます。また、各ナビのメニューから自分がフォローしているユーザー一覧ページにアクセスできます。

機能

現在は、フォローしているユーザーが記事を投稿した時にメール通知する機能のみとなります。随時便利になるような機能を追加していきたいと思います。追加し次第こちらのページで紹介を追記していきます。

通知はユーザーの設定画面で無効にすることも出来ます。

経験値とは？

2019-06-19T22:03:10+09:00

Crieit上で何かしらのアクションを行うと経験値がたまっていきます。経験値は現在下記で利用されています。

ユーザー詳細画面に累計経験値を表示
トップページに過去30日、365日の経験値ランキングを表示

経験値のため方

経験値は下記のアクションを行うことで上がっていきます。基本的な思想として、棚ぼた的に得られるものではなく、あくまでもサービス上でアクションをして頂けたことに対して上がっていくものとなっています。

記事投稿…3
ボード作成…2
ボード投稿…2
コメント…1
ボードコメント…1

まとめ

よろしければサービス内で楽しむための指標としてご利用ください。

今後も色々となにかに使えないか随意検討を行っていきます。またそのため、アクションによる経験値の重み付けは今後変わる場合や追加される場合があります。

Qiitaのようなサービスを1年運営してみたデータや振り返り

2019-06-04T21:11:22+09:00

Qiitaとdev.toの様なサービスということで作ったCrieitをリリースしてから１年が経ちました。せっかくですので色々と振り返ったりデータを公開してみたいと思います。

ただし最初にことわっておきますと正直たいしたデータではないため、すごいデータが見たい方や、元々サービス開発や運営が得意な方にとっては全くおもしろくないと思います。「うちのブログの方がすごいんだけど…」という方もたくさんいると思います。

僕と同様、今まで色々やってきたんだけど全く何もうまくいかなくて困っている……という方にとって、ちょっとでも何かの参考になればいいかな、と思っています。

検索流入

下記はSearch Consoleのグラフです。

去年の年末にも公開しましたが、それからもなんとか検索流入は伸びてきています。水色でなく青い方がクリック数で、最後の落ちてないところがだいたい800くらいです。

ちなみに１週間毎にでこぼこしていますが、へこんでいるところが土日です。また１月と5月に大きな谷がありますが、正月とゴールデンウィークで、ひどい事になっています。

GW明けの５月はグラフがぐちゃぐちゃになっていますが、なんともぎゃさんが５月中に３度もはてブ１位になるほどバズらせてくれたおかげで検索にも影響が出て何が何だかわからなくなりました。感謝です。今まではバズった記事があっても検索流入に影響はなかったみたいですが、VSCodeのRemote Developmentの話だったため記事に関係なく関心の多い人が多かったのだと思われます。

ちなみに平均CTRが7%で、平均掲載順位が18.9位です。もちろんこの記事はわりと人気あるな、という記事は一応あるのですが、とはいえどれがダントツという感じではなく、全体的にいろいろアクセスがあっての積み重ね、という感じのようです。CakePHP vs Laravelがかなり多く、あとはエンジニアのブログやPCの情報とか、Nuxtの情報あたりのアクセスが割と多いようです。

ただ、僕のメインのスキル範囲外の言語やフレームワークの話は全然まだ書かれていなかったりするので、そのあたりの記事は伸びしろがある可能性はあるのかもしれません。

とにかくやればやるほど伸びていくので、運営していて一番モチベーションの上がるデータとなっています。

Google Analytics

下記はGoogle Analyticsのグラフです。

平常時とバズった記事がある時の差があるので正直良くわかりません…。５月のバズはすごかったのですが他は5,000PV程度のため平常時が低すぎてこんな感じになっている気がします。

細かいアクセスの推移を見ていきます。

最初の月

5月末にリリースしたので6月はほぼ最初の１ヶ月内です。正直今までリリースしたサービスは毎日アクセス１ケタとかだったためわりと健闘しています。また、同じ6月でも結構アクセスが増えている日がありました。

あまり覚えてないのですが多分下記に多少アクセスがあったのかもしれません。

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

今考えると１ヶ月目でこれは僕の中ではかなり驚異的な数値ですね…！　６月からもう頑張って11記事ほど書いていたようです。

最初のバズ

グラフの最初の突起はなんとか自分でバズらせることができた最初の記事です。多分下記です。Twitterで許可をもらってなんとか頑張って翻訳しました。サーバーの強さが分からなかったのでまだリアルタイム解析を見ながらドキドキしていました。

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

あと、同じ月にもう一つバズり、これははてブの１位に一瞬なっていたと思います。

Vue.jsとHTMLとCSSで3Dアクアリウムを作ってみた

これ以降もちょくちょくはてブに載る記事はありましたが、僕が自分で書いた記事で大きくバズったものはもうなかったと思います。バズらせるのはむずかしい…。

下記はその後の平常時のアクセスです。

何回かバズったことで、恐らく色々なところからの流入が徐々に伸びるようになっていったのではないかと思います。また、元々はてなブログで書いていた記事も最初に移行していたので、そのあたりの影響も連動して出てきたのではないかと思います。

アドベントカレンダー

年末にアドベントカレンダーを開催しました。アクセスはそれまではたまに増えたりはしますが、基本的には平坦な感じでした。よく諦めず頑張りました。ただ、この時の12月は毎日通常の倍くらいのアクセスがありました。毎日記事をいろいろな方に投稿していただけたので、皆さんのツイートと自分の毎日のツイート＆RTで頑張っていました。

あとは下記の記事がバズっていました。ありがたいです。

今年

今年は３月に久しぶりにバズった記事がありました。

月500円の不労所得を得るためにWEBサービスを開発した話(1)

おかげさまで平日のPVがだんだん1,000を超えるようになりました。

5月のバズった記事は下記です。GWはPV数などはもうぐちゃぐちゃで平常時のものではないので省略します。

収益は現在AdSenseのみです。僕は今までのサービスを含め基本的に毎日クリック数はゼロで、たま～にクリックがある日がある、という感じでした。

ただ、今年に入ってから突然クリックが増え始め、あっというまに元々と逆転しゼロの日がほとんどない状態になりました。不思議な感覚です。とはいえ収益は平均で月数千円程度です…。無料枠を駆使して運用しているので黒字ですが、お金をかける人であれば赤字になっていることもあるでしょう。

ただ、今のところまだアクセスはアップしているところですので今後が気になるところです。また、これだけすくないのであれば逆にうまい広告の打ち方があれば全部使っていいかな、という気持ちにもなります。

ちなみにどの広告がよくクリックされているか、というのが下記の画像です。

右上ディスプレイがダントツですが、これはいろんなページに貼っていた気がするのであくまで参考程度に見たほうが良さそうです。基本的にはやはり特定の記事に来てそのまま直帰するパターンが多いと思いますのでやはり記事の下辺りのクリックが多そうです。

独自の集計

Laravel Admin上に指標として重要そうな独自の集計をいくつか作っています。

記事の投稿数

記事の投稿数も大事ですが、どれだけ多くの方に投稿していただけたかというのも重視しています。今のところ一応増えていってはいるようですが、たまたま一度だけ書いたり、書いていたけどもうやめてしまった、という方もいますし今後もそれの繰り返しだと思いますので、なんとかこの値が増えていくようやっていきたいところです。

とはいえ以前は僕が主に月１０記事程度書くのが主なコンテンツの増加だったところが、いまや50～70記事ほど他の方に書いていただけるということになりますので本当にもう一つ一つの積み重ねになっている全ての記事が大切で、感謝しています。

ユーザー登録数

ユーザー登録数も大事ですが、どれだけ増加していけばいい感じの状態なのかがいまいちわからないのと、登録しても何かを投稿していただけたりのアクションに必ずつながるというわけではないため、あまり詳しくは見ていません。

このあたりはアクセスが増えればある程度連動していく箇所でもあると思いますし、それよりはアクション率を高める方が重要だと思うのでとりあえず他のところを考えているような感じになります。

元々は記事を見るためにアクセスしてきた方が登録されて記事の投稿などまでいけばいいな、と感じていましたが、そもそも記事を書く人、見る人の属性は全く別物で見る人は見だけの役割、というものもサービス上にはあるような気がしていますので、そのあたりも試行錯誤しつつも考えすぎておかしな施策をしすぎたりしないほうがいいのかな、とも考えるようになってきています。

Contributionランキング

丁度ちょっと前にContributionランキングを作っていたのでそちらです。

１位はコリさんで、いくつも連載を投稿してくださっています。連載機能はコリさんの大量の投稿やアイデアから考えて作ることになったものです。

２位はこうしえんさんで、ボードにたくさんの投稿をしていただけています。こちらもこうしえんさんが投稿したものを見てこれはやばいな、と思った箇所を調整することでたくさんの改善ができました。

３位はうえださんで、記事もコメントもたくさん書いていただけました。

今後色々調整したりすると思いますが、現在はGitHubと同様どのアクションも＋１になるしくみですので、これだけのアクションをしていただけたのだなぁ、と感謝の気持ちでいっぱいです。アクションはコンテンツの増量だけでなく、サービス自体の改善すべき箇所の発見にも直結するため本当にクオリティとか量とか一切関係なく、どんなアクションでも全部ありがたいです。

ですのでもし何かしらのアクションに対して躊躇されている方などがいれば、是非何も気にせず思いつきのレベルで問題ありませんので是非試してみていただければと思います。

まとめ

ということで初になりますがいろいろとデータを公開してみました。他のすごいサービスに比べたいしたデータを公開できないのが申し訳なく残念です。もっとすごければ定期報告でもしてなにかの役にたてていただければとも思うのですが。

ただ、継続は力なりということでサービス運営において何の取り柄のない、何一つうまくやり遂げたことのない開発者でもここくらいまではいける、ということが示せたので、同じように悩んでいる方々の何かの参考になれば幸いです。（ただ、適当なものを作って長期頑張っても意味がないと思いますので、何を解決できるサービスかはしっかり考えていった方が良いと思います）

また、各データはまだ伸びている段階ですので、このまま続けていくとどうなるのだろう、という楽しみが自分の作ったサービスの中で一番大きいものになっています。引き続きいろいろと試してみたいと思います。

今後の展望

ロードマップに書いてあるものも書き忘れているものもいくつかアイデアがありますが、なかなか全部できる時間もないためまた優先的に色々ためしにやっていきたいと思っています。

開発だけでなく、こちらに投稿していただいたチャレンジ的な企画を年中やって盛り上げる、的なこともずっとやってみたいと思っていたのですが、なかなか心理的な障壁が高くてできていなかったため、せっかくですのでこの機会に試していきたいと思います。

あとは有料系の機能も徐々に試していきたいな、と思っています。たとえば有料記事、FANBOXのような有料ボード、有料広告枠等。このあたりは作っても多分使われないと思いますが、ただ人気がなくても使いたい人にとっては特に迷うことなく使えるものだと思いますので機能だけ作りつつデータを集めて様子を見はじめなきゃなと思っています。（とはいえ有料記事は僕自身も何を書けばいいかよくわからないのでなかなかモチベーションが上がりません）

あと話はずれますが、Crieitはユーザー属性が偏っており、多分技術系の人以外にこういうサービスをやってる、と言っても「？？？」となると思いますし、それゆえ単純に人の母数が限られていたり広告収入も渋かったりというところがあると思いますので、Crieitの運用と並行して常時他にも色々とジャンルの違うサービスを作っていきたいと思っています。

今年は下記を作ったりしました。

100の質問メーカー
 TLシェア

とはいえバタバタしてるとやっぱり作りっぱなしで運営の方が放置気味になってしまいますが…。

こんな感じで何か一つガッツリ運営するサービスを持ちつつ、合間で他にも作って試してみる、というのは色々な意味でおすすめです。ただ、時間がないと全部おざなりになる可能性もあるためそうなる場合は一つのサービスに注力した方が良いかもしれません。もしくは、おざなりでもなんとかなるものをたくさん作って行った方が良いと思います。

「noteで書く」ボタンを追加しました。

2019-05-22T22:09:48+09:00

本日noteにてリリースされた「noteで書く」ボタンに対応しました。記事やボードなどでボタンを押してnoteに関連する記事を書くことができます。

是非気になる記事や、何か読んだ内容について考察など書いてみたい場合などにご利用ください。

Twitterアンケートではてブについて聞いた件の考察

2019-04-28T23:10:50+09:00

Crieitにて次に開発すべき内容について非常に悩んで何も進まない状態だったのでTwitterでアンケートを試してみました。ほとんど回答なんてないだろうと思ってましたが、自分的には思いがけず結構多くの方に回答して頂けたようで本当に感謝＆参考になりました。Twitterアンケートって匿名だしワンクリックで手軽だから本当にそのへんの軽さのおかげっぽいのですごい。

プログラミングをやったことある方に質問です。はてなブックマークって…
— だら@技術系投稿サービスや100の質問メーカー運営中 (@dala00) April 27, 2019

背景

Crieitの開発で次は何を進めようかずっと悩むばかりで手が止まっていました。具体的に何を悩んでいたかというと、うちのサービスは検索流入が主なアクセス獲得方法となっているため、下記のような課題があります。

その主となるアクセスユーザーは多分Crieit上で何もアクションせず素通り
アクションを行うのはそれ以外のTwitter等からアクセスされた方が主になると思うので、割合的には少ない

そのためその課題を解決するための一つの方法として、主なアクセス獲得方法となっている検索流入ユーザーが気軽に何かしらのアクションができる仕組みを作れないかとずっと考えていました。

解決案

記事詳細ページの好きなところに付箋を貼ることができると良いんじゃないかなと思いました。これだけで下記のような多くの事が望めるのでは…と。

付箋した箇所をあとで見返すことができるのでリピートしてくれる可能性が出てくる
記事を書いた人も「いいね」やはてブとは別のフィードバックになり嬉しい
ついでに感想も書けるようにすると上記の効果が増大し、且つそのままTwitterシェアできるようにすれば拡散にも役立ちそう。また、新たなコンテンツにもなる
付箋機能を使うためにユーザー登録してくれる

もともとロードマップにいくつかアイデアを書いていたのですが、ちょうどそれらのいくつかにマッチするような内容でもありました。

問題点

ただ、この付箋機能には問題点があります。それはレスポンシブなサービス且つ投稿された記事では不可能ということです。

レスポンシブであるがゆえに、付箋の位置はアクセスした人それぞれによって変わってしまうため特定ができません。では位置ではなく段落毎に付箋を付けられるようにしようかとも思いましたが、そもそも段落も記事の編集で変わったり消えたりする可能性があるためやはりメリットが薄れてしまいます。

延々と悩む

そんなこんなでここで延々と悩み始めました。

とりあえず作ってみればいいんじゃないか
でも結構作るの大変そうだし駄目だったときの時間のロスも大きそうだし…。
そもそも段落毎にボタンとかあったら邪魔じゃない？（これはまあ自由位置でも同様ではあるけど…）
もういっそストック的な機能でいいんじゃない？　前述の機能とテーブル構成殆ど変わらない（位置情報があるかどうかの違い）っぽいし
それだったらそもそもはてブでいいんじゃないの？　そこに時間かける必要ある？

浮かんだ疑問

そこまで考えてふと思いました、そもそも、プログラミングしてる人って全員はてなブックマーク使ってるのか…と。

使っているのであれば、もっとはてなブックマークのボタンゴリ押しする形でUIとか変えれば良いんじゃないか、という気がしましたし、もしそれほど使われてないんだったらQiitaみたいに独自にブックマーク機能を作って、検索で来た人が簡単にサービス上にストックしておける機能を作ってあげたほうがいいんじゃないか、と思いました。

ただ、こんなのははっきり言って実際どうなのか全く想像できななかったので、Twitterアンケートしてみたらどうだろう…？　とふと思いました。回答はあまりされないだろうけど、まあとりあえずいいか、という感じで。

結果と考察

結果、先程のツイートの通り、はてなブックマークを使っている人の割合は想像していたものに比べものすごく低いことが分かりました。4人に1人くらいしか使っていないという結果のようです。もちろんユーザー属性が偏っているので確実に正しい結果とは言えませんが、むしろ偏ってる中でこれくらいということであれば結構本当なのでは…という気がしました。

自分的にはやはりみんな使っているものだと思っていたのでかなり意外な結果でした。とはいえ自分もさほどブックマークはしませんし、どちらかというと見る専的な感じですので、実際にはさほど意外な結果では無いのかもしれません。

というか「ブクマする」じゃなくて「使う」という曖昧な言葉にしたのは間違ったかな、と思ったのですが、この結果だとあまりどちらの書き方でも問題ない感じになったので幸いでした。

ということで、はてブボタンをゴリ押しするUIに変える、というのは完全に間違いで、とりあえずCrieit内に独自のストック機能をつけてあげる、という対応が今一番望ましいのではないかという判断となりました。とりあえずそこだけ作っておけばあとで位置を加えられるようにする拡張はすぐできそうですし。

まあこれが本当にいま一番すべきこと＆多くのことを解決することなのかは完全に空想上の話のためよくわからないですが、とにかく悩んでいたことがスッキリしたことが一番ありがたいことでした。回答していただいた方全員にとても感謝です。

エイプリルフールはじめました

2019-04-01T07:14:06+09:00

リリースしてからはじめてのエイプリールフールだったのでちょっと遊んでみました。ふわふわと飛んでいるのはくりえいとくんです。

元々

Crieit

という文字が顔に見えたのでそれをそのまま絵にしてみたらおばけになった、という感じです。クリックすると色々喋ります。

特筆することも無いので動き回らせているプログラムでも貼っておきます。

おばけクラス

move()で動かし、getX()とgetY()で表示するための位置を取得しているだけのよくあるクラスです。

Goast.ts

const ymax = 50
const width = 100

export default class Ghost {
  id: number
  private x = 0
  private y = 0
  private basey = 0
  private ax = 0
  private angle = 0

  constructor() {
    this.id = Date.now()

    if (Math.round(Math.random()) === 0) {
      this.x = -width
      this.ax = Math.floor(Math.random() * 2 + 2)
    } else {
      this.x = window.innerWidth
      this.ax = -Math.floor(Math.random() * 2 + 2)
    }

    this.basey = Math.floor(Math.random() * window.innerHeight)
    this.calculateY()
  }

  calculateY() {
    this.y = this.basey + Math.sin(this.angle) * ymax
  }

  move() {
    this.x += this.ax
    this.angle += Math.PI / 50
    if (this.angle >= Math.PI * 2) {
      this.angle -= Math.PI * 2
    }
    this.calculateY()
  }

  finished() {
    if (this.ax < 0 && this.x < -width) {
      return true
    }
    if (this.ax > 0 && this.x > window.innerWidth) {
      return true
    }
    return false
  }

  getX() {
    return this.x
  }

  getY() {
    return Math.floor(this.y)
  }

  getAx() {
    return this.ax
  }
}

おばけたちの管理コンポーネント

これも特に特筆することのない単なるゲームループ的なコンポーネントです。おばけを管理して画面からはみ出したら削除したりしています。

おばけコンポーネント

もう動きはおばけクラス、管理は前述のコンポーネントで行われているので、ここでは表示したりクリックイベントを処理したりするだけです。これで一通り完了です。面倒だったので表示はfixedにしてスクロールは考慮しないようにしています。

まとめ

さあ、みなさんも新元号のことは忘れてエイプリールフールやりましょう。今からでも間に合います！！！！！（？）

作業記録ボードにログを残していこう

2019-02-06T21:59:37+09:00

自分用の作業記録ボードを作って個人で開発しているものの記録を残すのにボード機能はぴったりです。投稿をシェアすれば自分の作っているものを他の人に知ってもらうことができますし、単にツイートするよりは、ボードにまとまっていた方が自他ともにあとで何をやっていたのか見返しやすいです。

ボードの作成画面にも作業記録ボードのプリセットがあるため、ボタン一つでだいたいの設定を行うことができます。

下記のようなオススメ設定にしています。

タイトルを入力可能
タグを入力可能
自分のみ書き込み可能

何かサービスを作っている場合や運用中のサービスやアプリがある場合はボードの説明にURLやスクリーンショットを貼っておくと良いと思います。

日々の投稿

何か開発を行った日、その日の進捗を書きいてツイッターなどにシェアしましょう。開発中の画面のスクリーンショットを撮って貼っておくと見る人も楽しいと思いますし、画像がなくてもMarkdownでコードを書いておくとツイートにコードのスクリーンショットが表示されます。

例として、下記はCrieitの開発ボードです。

Crieitの開発

是非お試しください！

掲示板を作る

2019-02-04T23:39:39+09:00

Crieitのボードは自分専用のものだけではなく、誰でも投稿できるものを作ることができます。みんなで技術的なことやクリエイティブなことについて雑談したりする掲示板を作ったりできます。

プリセットもありますので、すぐ作成可能です。

基本的にはプライベートと自分専用チェックを外しておけば問題ないと思います。もしもっと誰にでも書き込みやすいボードにしたい場合は匿名にもチェックを入れると良いでしょう。

掲示板は例えば下記のようなものを作ってコミュニケーションできると楽しいと思います。

プログラミング言語についての話
フレームワークについての話
何かのソフトについての話
仕事についての話
趣味での開発や制作についての話
何かのグループ内での話
問い合わせのやり取りなど
意見や情報募集の掲示板

是非それぞれのアイデアで色々なボードを試してみてください！

Crieitボードで非公開のメモやひとりごとを書く

2019-01-29T21:22:22+09:00

Crieitのボードにはプライベート機能があるため、自分用のシークレットボードを作って自由に何かを書くことができます。

この画像のように、ボード作成時には権限が設定でき、「プライベート」にチェックを入れてボードを作ることで自分だけが閲覧、書き込みができるプライベートなボードを作ることができます。

用途

例えば下記のような用途があるのではないかと思います。

アイデアノート

誰にも見られたくないけど、どこかに書き起こしておきたいアイデアをまとめたノート。例えば作りたいWebサービスのネタや、開催したいイベントのアイデアなど。

タイトルやタグを付けることもできるので、アイデアをタグでまとめたりすることもできる。また、ある程度きっちりまとめておくと、ボツになったアイデアや、ある時急に公開した方がよくなったタイミングなどで使いまわしやすい。

日記

思っていることをひたすら書く日記帳。誰かに見せたいわけじゃないけど、Markdownできっちりまとめて自分の気持をまとめてみたい時など。

Markdownの練習

何か公開したい物があるわけではないけど、今後Markdownを何かしらで使っていきたいので練習のため色々書いてみたいときに。

参考リンク

ボードとは？

100DaysOfCodeをCrieitボードではじめよう

2019-01-28T21:07:45+09:00

Twitterで流行っている100DaysOfCodeを、Crieitボードを使って進めると色々とメリットがあります。

そもそも100DaysOfCodeというのは何かというと、Twitter上で#100DaysOfCodeというハッシュタグをつけ、毎日プログラミング学習を行ったことをツイートすることです。

100DaysOfCodeの詳しいやり方

基本的にはTwitter上で行います。どの工程もすべて#100DaysOfCodeというハッシュタグを付けましょう。

開始を宣言する

まずやることに決めたら、これからはじめるよ！　ということをツイートで宣言しましょう。ハッシュタグを忘れずに。

毎日ツイートする

毎日、その日やったことをツイートします。Day10や1/10など、わかりやすい形でその日が何日目かということも本文に含めます。例えば下記のような感じです。

Day12
・データの投稿機能を作成した
・ツイッターにシェアできる機能を作った
#100DaysOfCode

Crieitボードで行う

これをCrieitのボード機能を使って行うと、下記のようなメリットがあります。

コードも書ける

ボードの投稿はMarkdownで行うため、実際に書いたコードも一緒に投稿することができます。例えばJavaScriptであれば下記のような書き方です。

    ```javascript
    function test(a) {
      return a
    }
    ```

すると下記のような形で表示されます。

function test(a) {
  return a
}

ツイート上では表示できませんが、URLと一緒にシェアすればリンクをクリックされた場合にコードを見ることができるので他の人が参考にすることもできますし、自分の備忘録としても有用です。

ちゃんとログとして残せる

ツイートだと他のツイートに混じってしまいますが、100DaysOfCode専用のボードを作ってそちらに投稿する形であれば、他のものと混じらずそれ専用のログとして残すことができ、あとで見返すことも簡単ですし、これが自分のログだよ、と他の人にシェアすることも容易です。

実際の進め方

実際の進め方は下記になります。

自分の100DaysOfCode専用のボードを作成する
そのボードに毎日投稿していく

ボードの作り方

まず、画面上部のボードを作成ボタンから作成ページに行きます。

ボード作成にはプリセット機能というものがあり、100DaysOfCodeのプリセットもあるため、このボタンを押すとボード作成に必要なほとんどの情報を入力してくれます。

必要に応じて調整しましょう。

ボード名を自分の名前にする
ボードIDのyourIDを自分のIDにする
その他意気込みなどがあれば概要に追記する

等。

作ったボードをシェアする

ボードを作成すると、概要の右下にシェアボタンが表示されます。これでツイッターに意気込みをシェアしましょう。

毎日書く

あとは投稿ボタンから実際の投稿を毎日行っていきます。

投稿後、各投稿の右下にもシェアボタンがあるため、そちらからツイートを行うことでその日は完了となります。これを頑張って100日続けていきましょう。

コードはツイートしてもあまり意味がないと思いますので、ツイートのシェア文からは削除しても問題ないと思います。コードは投稿しておけばツイートのリンクをクリックして訪れた人は見ることができます。ツイートの本文にはその日やったことのリストを主に書くようにしましょう。シェアする際にシェア文は調整可能です。

見やすく調整して投稿しましょう。

本文の最後を途切れさせておくと、まだ続くのかな？　とアクセスしてもらえる可能性があがりそうです。

参考リンク

開発者が行った実際の例 dala00の100DaysOfCode
ボードとは？