「アドベントカレンダー」の記事 - Crieit

チンタラ英語を勉強していくつもりが、いつの間にか変な所に来てしまった話

2020-12-22T03:28:56+09:00

Crieitの、なんでも Advent Calendar 2020 21日目の記事として投稿させて頂きました。

福岡で物流系のエンジニアやってる、かきそふとです。

思いつきから英語の勉強を初め、英語で日記を書き続けて 500日程経過しました。

その他には、オンライン英会話を１日 30分ほど、あとは個人的に教わっている先生が、カナダ・イギリス・スペインに居て、週１で１時間ほどレッスンを受けています。

あとは Language Exchange Partner（「日本語を教える代わりに、英語を教えて」という間柄）と不定期に連絡を取っています。

別に大それた目標があったわけではなく、「仕事、英語との親和性が高いんで、やっといて損はないか」程度のノリで始めました。
が、特別英語が好きなわけでは無いので、何か工夫をしないと途中で投げ出す事は目に見えている。

そこで、継続させるために色々と工夫をしていたら、結構面白い事もあったんで、それを書き連ねていきます。

英語で日記を書いてみた

現在も継続中。
kaki en talk　～英語が苦手な日本人エンジニアが書く　英語の日記～

継続期間は 16ヶ月と長いものの、トップページの「Author」を「Auther」とずっとスペルミスしていたのを最近ようやく直したという何だかもう恥ずかしい入り口となっておりました。
書いた英文は凄まじい怪しさを放っているので、先生に添削してもらってます。

書き始めるきっかけは、こんな感じ。
英語で日記をつけて５０日ぐらい経ちました。それまでの経緯とか。
英語で日記をつけて５０日ぐらい経ちました。（全体の構成編）
（※「50日」は、上記のブログを書いた頃の継続日数）

（要約）
小さい子供たちに邪魔されて、全然趣味のコードを書く事に集中できんのじゃあ！
よし。それなら邪魔されても気にならない事（別に好きでもないこと）をやろう。
という事で、英語で日記でも書いてみるか。

添削は英語が得意な知人にお願いした。
が、新しい事業の立ち上げで忙しくなったので、途中から断念。

義理の姉が海外で生活していた経験があるので頼んでみた所、快く引き受けてくれました。

ちなみに義理姉、確か５～６国語ぐらい話す事ができ、瞬間映像記憶なる超特殊能力を保持しているという、何かもうワケ分からない人。

東大を余裕で合格できる学力がありながらも、「近いから」という理由で地元の大学に行き、それを全力で先生全員から止められたというスラムダンクの流川楓みたいなエピソードがあったりする。

そんな素敵な才女である義理姉の旦那（私の兄）は、「出身は鈴蘭高校です（漫画「クローズ」に出てくる超ヤンキー校）」と言ってしまうようなお茶目さんで（実際にヤンキー校出身。学生時代、前述の「クローズ」や「ろくでなしブルース」のようなバイオレンスな世界に生きていた）、そのあまりの不釣り合いっぷりに、結婚前に

「何でコレ（ウチの兄）を選んだんですか！？考え直してください！今ならまだ間に合います！」

と心配して声をかけるも、

「もう既に色々な人に言われてるんで大丈夫ですw」

とにこやかに返してくれました。
ちなみに同じ事をウチの両親にも言われたらしい。どんだけやねん。

そんな元ヤンのウチの兄、現在は介護職に落ち着き（ハタから見てる分には天職みたい）つつも、副業でオカリナ吹きをやっており、時には有料、時にはチャリティーでコンサートを開催し、「オカリナ福祉士」というワケ分からん肩書きで様々な活動をしつつ、時には YouTuberやってたり有名どころのバンドとコラボしてたりと、意味不明な行動力があったりする。

話が逸れた。英語の日記だ。
200日を越えたあたりで、「英語で日記を書き続ける事で、何を得る事ができたか」をまとめときました。
英語で日記を２００日書き続けたら、様々な学びがあった。

自分で言うのも何だけど、結果のみでなく実際に書いてきた日記と突きつけ合わせながら効果を検証した、読み応えのある内容になっていると思う。

英語でスライド作ってみた

こんなの作ってみました。
WHAT I GOT FROM WRITING AN ENGLISH DIARY FOR 5 MONTHS
※ 「5 MONTHS」は、スライド発表時の継続日数

（要約）
英語で日記書いて５ヶ月経ったけど、まだ全然ダメだよ！
でも、少しは上達してるし、得られるものもあった。
これからも継続したいけど、実は問題が・・・
実は、添削をお願いしている先生が、ご妊娠されたので、新しい先生を探しています。

そう。おめでたい事に、義理姉には新しい命が宿っていたのです！
おおーーー！！めでたいーー！！

ちなみに現時点では元気な男の子が生まれており、すくすくと育っております。
兄の悪影響で、名前に「龍信（「クローズ」の登場人物の名前）」とか付けたらどうしようかとちょっとドキドキしていたが、特に変な名前が付けられる事はありませんでした。よかったです。

多分、義理姉が上手い事制御してくれているのだと思います。

これがきっかけで、新しい英語の先生を探す事になりました。

その時の内容は、こんな感じ。
【英語学習】英語日記の添削をお願いできる方を探しています。
「こんな方にお願いしたい」といった人物像および自分の学習スタンスをはっきりさせておきました。

学習記録を残した

色々な勉強法を試していく中で、「これは合わない」という勉強法が分かったり、
「こんな方法はどうだろ？」というのをいくつか試してみたり、
「こんな方法が合ってる」というのが分かってきたりしたので、メモを残す事にした。

英語学習で大切な事は、ボクシングが教えてくれた

英文法の第２文型が今でもさっぱり分からない。しかし、それはエジソンに続く道だった！？

自分の学習スタンスをはっきりさせ、その意見に肯定的な意見を示してくれる方にお願いしたいと思っていたので、この辺りは文章化しておきたかった。
実際、探す時は上記のブログのエントリを使いました。

オンライン英会話を試してみた

「とにかく会話する時間を増やそう！」という事で、色々なオンライン英会話を試してみた。
とりあえず DMM英会話に落ち着いたものの、やっぱり合わないと感じ始めていた。

DMMが悪いという事ではなく、「英会話教室」というシステムそのものが自分に合わない気がしてきていた。
詳しくは以下を。

オンライン英会話サービスをいくつか利用してみた感想と、今後の方向性について

専属の先生を探してみた

英会話の以下の点が合わないと思った。

毎回、その場限りの会話をするのが虚しくなった
講師の当たり外れが大きい
会話のネタを探すのに困る事がある

そして、以下のスタンスで会話をしたいと思った。

特定の講師から習いたい
教えてくれる方は、スペシャリストでなくてもいい
緩い雰囲気で、ざっくりなトークがしたい

そんなスタンスで探してみようかと思ったのをまとめたブログがこちら。
オンライン英会話サービスを利用してみた結果、別の学習法を試したくなった話

こちらも無事、見つける事ができました。

何だかんだでオンライン英会話を続けてる

とりあえず、自分の要望を満たす事はできたものの、退会まで猶予があるな。どうしよう。
・・・と思い、せっかくなんで色々試してみた。

オンライン英会話レッスンを使い分けてみようと思った話

正直、英会話講師との会話に虚しさを感じ始めていた頃だったので、「どうやったら面白くできるか」ばかりを考えるようになった。
何だかんだで現在まで続いていて、少しは楽しめるようになっています。

英会話レッスンなんてどうでもよくて、海のレジャーについて聞きたくなった話

オンライン英会話にて、講師がデートをしていた場合に使えるフレーズ集！

「猫派」は英語で「cat person」。ほかに、どんな派閥があるのか調べてみた

【英会話】カタコト英語ではなく、講師から「正しい表現」を聞きたい！そんな時に使えるフレーズをご紹介。

英語日記の書き方を変えてみた

英語日記を書き続けて 400日ほど経過したところ、今後伸ばしていきたいスキルの方向性を考え、別のスタンスで進めたくなった。
日記を書く事で、ついでに会話能力もあげられないかと思ったが、案外そうでもなかった。
具体的には以下の点に気付き始めたので、方向転換をしてみたくなった。

「書く」と「話す」は、表現方法が異なる
インタラクティブ性が鍛えられない
リアクション時に使う言葉のボキャブラリが全く増えない
文章化するのは結構大変

詳しくはこちらを。
英語日記を１年続け、方向性を見直してみようと思った話

具体的には、
「文章として書くのではなく、あたかもチャットをしているかのように書く」
というスタンスに切り替えた。

自分にとっては効果絶大で、どのくらいの成果があるのかは以下に書きました。
英語日記をチャット形式で書いたら、想像以上に大きな学びがあった

英語で技術ブログ書いてみた

DEV に投稿てみた。
fibonacci estimation method to minimize the harmful effects of death march of engineers

「英語記事→日本語」の方向はよく見るけど、「日本語→英語」の技術記事はあんまり見ないな。
と思い、書いてみた。

ちなみに、元記事はこちら。
フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法

※元記事の作者から許可を頂いたうえで執筆しております

元記事の@ジャバ・ザ・ハットリさん、ありがとうございます。

書いた英文は、先生にチェックをお願いしました。
読むのは数分ですが、完成までに８時間ぐらいかかりました。
現在、２つ目を執筆中。こっちは元記事が自分が書いたものなので、だいぶ楽。

その他のアウトプット

英語スライド：パート２
Accounting for engineers（エンジニアの会計）
エンジニア向け英語LTイベント第7回 Try English LT! for engineers様にて発表させて頂きました。

オンライン英会話で起こった面白かった出来事をネタに、ブログエントリにした
「オンライン英会話の先生の GitHubアカウントを聞いたら、全然違う人だった！というかエンジニアですらなかった！」そんな時に使える会話例

一見、「こんなクールなサイトができたぜ！」と錯覚させる事ができるものの、しょーもない事しか言ってないネタサイト。
https://atarima-e.studio.site/

現在の状況

そんな感じで、ダメなりに色々とアウトプットを続けている状態です。

「Xヶ月で英語ペラペラに！」と、短期で走りきる目標を立てるのではなく、「惰性で続けられるようにしよう」と、継続に主眼を置いたところ、こんな感じになりました。

現在の状況としては、
「せっかくここまで続いたんだから、ここで辞めるのも勿体ない」
と、より思ってるんで、こんな感じでしばらく続けて行こうかと思います。

企業に所属する前に、大学で学んで良かったこと、もっと学んでおけば良かったこと

2020-10-04T23:18:52+09:00

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

移転元: 企業に所属する前に、大学で学んで良かったこと、もっと学んでおけば良かったこと - 雑木林

TL; DR

必要になって、自ずと勉強できれば、それで大丈夫です。
気軽に生きていきましょう。

でも、読書だけはガチでやっておきましょう。
大学で読みたい本は、全て読み切ることをオススメします。

社会人枠です

本記事は、宮崎大学アドベントカレンダー2019における8日目のエントリー記事です。

ペーペーですが、これでも社会人として生活しています。
ちょっと前まで学生だったので、学生時代に得たものを整理したいなと思いました。

学生さんは、ご参考までに、今後の学生時代を謳歌してください。
そうでない方は、自分もこんな時代があったと、ノスタルジーに浸ってください。

学んで良かったこと

以降、大学で学んで良かったことを記述します。
自慢話みたいなものです、温かく眺めてください。

対人コミュニケーション

学生時代にお酒を飲むようにしていたのは、社会人はお酒を飲めたほうがいいのかな、と漠然と考えていたからですが、大当たりでした。
私の所属しているプロジェクトチームは、学生時代の研究室以上に飲み会が多く、2次会も何度かありました。
2次会を楽しめる人間でよかったなと、2次会に参加するたびに思っています（だいたい奢ってくれます）。

あまり口数は多くないですが、Slackなどのコミュニケーションツールでは喋るようにしています。
自身のtimesチャンネルがあるため、独り言を言いやすい環境でもありますが、ネット弁慶時代の性格をうまく活用し、ネット上では話しやすい雰囲気を務めています。
お蔭で、プロジェクトチーム外の人からも話しかけられることが多く、自身からも質問しやすく、社内の雰囲気は良好です（個人の感想です）。

仕事は人対人のコミュニケーションで成立しているため、コミュニケーションを避けては通れません。
しかし、話せれば良いわけではなく、しっかり会話が成立し、人間関係を良好にすることが肝心です。
人間関係が良くなれば信頼してもらえますし、そうなれば新人であっても、けっこう話を聞いてもらえます。
これを活用し、自身からの提案が通ったりすると、仕事も楽しくなりますよ。

コミュニケーションが苦手？――なら「なたもだ」で解決すればいいじゃない
https://www.atmarkit.co.jp/ait/spv/1912/11/news005.html

自動化への意識

現在の所属プロジェクトには、CI/CD環境が一部整っていますが、すべてが自動化されているわけではなく、非常にまどろっこしく感じる時があります。
しかし、中には機械的に淡々と同じ作業をしている人もいるため、メンバー全員が自動化を考えているわけではないのだな、と意外に思いました。

とあるシステムに、バイナリファイルを手動で設定しなければならないディレクトリがありました。
そのバイナリファイルを更新するためには、手動でコンパイルしたバイナリファイルを、手動で上書きし、手動でプルリクをしなければなりませんでした。
私は嫌だったので、自動化したいと提案し、そして実装しました。

人手による作業はヒヤリハットの温床になるため、できるだけ潰しておきたいです。
その考え方が、私の自動化への意識を生み出してくれました。

開発環境におけるこだわりと柔軟性

現在の所属プロジェクトの開発環境ですが、IDEとしてほぼ全員がVS Codeを使用しています。
しかし、僕だけなぜかVimをメインで使用しています。
開発環境に対して強制が無かったというのもありますが、PythonならVimでいいかなという気持ちで独自路線を進んだのが、正直な理由です。

ですがその際に、チームの開発環境に合わせる必要があります。
VS Codeで利用しているプラグインやLintツールがあれば、それをVimに組込まなければなりません。
私はVimの設定を多少いじれたので、VS CodeじゃなくてもPythonを編集できることを証明しつづけています。

一方で、妥協したものもあります。
既存システムにRustを使っていたものがあったのですが、代替品としてPythonを使っていたシステムがあり、そちらに移行すべきか否か、という話が持ち上がりました。

個人的には、Rustを勉強していたこともあり、Rustを推したい欲がありました。
しかし、他のメンバーはPythonの方が読みやすいです（当時は私しかRustを読めていませんでした）。
属人化が怖かったため、私からPythonのシステムに変えてほしいと頼みました。
結果として、多くのメリットが生まれました。
今でも若干後悔していますが、これで良かったとも思っています。

こだわりは大事、妥協も大事です。
折合いを付けることが重要なことですね。

ソフトウェア工学

オブジェクト指向という概念を理解できていない人は、意外と今でもいます。
TDD文化がないプロジェクトはたくさんありますし、UMLを正しく読み書きできない人もたくさんいます。
テスト手法とかカバレッジ測定とか、名前は知ってても開発で使える道具にできる人は、あまり多くいません。

ソフトウェア工学は、システム開発全般で使える、かなり汎用的な知識を学べる学問だと思います。
学生時代にCI/CD環境を整えたのは、想像以上に役に立っています。

様々なプログラミング言語／ツールの概念や利用方法

事前に学習して良かったと思ったプログラミング言語／ツールは、以下の通りです。
これらを学生時代に学んでいたことで、会社のチーム配属直後からスムーズに開発を担当できました。

Perl
Git/GitHub
CI/CD
Slack
C++
Raspbian/Raspberry Pi

私はPerlを勉強していましたが、それによりRubyやPythonなんて比較的簡単に使えるだろうと自己判断していましたし、実際にチームで開発やレビューを行う立場となっています。
Gitを使っていたことで、GitHubでのプルリクという文化や、コンフリクトとの格闘について、長く苦しめられることもありませんでした。
なにより、CI/CD環境の構築を経験していたおかげで、どのようにシステムをアップデートするのかの概要理解は非常に役立ちました。
ラズパイに至っては、知らなければ使い方すらわからない気がしますが、スムーズにRaspbianをmicroSDカードに焼いて ssh [email protected] できました（簡単なことですが、意外と凄いことだと思いますよ）。

これらに関しては、運の要素が結構絡みます。
もし配属先のプロジェクトが、SVNでバージョン管理しているCOBOLシステムサーバーの保守運用（コミュニケーションツールはEメール）みたいな場合、全く役に立たなかった可能性もあります。
気負わずに、勉強したいことをすればいいと思います。

もっと学んでおけば良かったこと

以降、大学でもっと学んでおけば良かったことを記述します。
反面教師として、ご活用ください。

Javascript

現在のJavascriptについては、殆ど理解できていません。
流行っているものは勉強したくない、という私の天邪鬼な性格が災いしました。
それは、以下に示す、私の学生時代に使っていた言語からも、お察しできると思います（1つだけ例外あり）。

Perl
Java
C++
Rust

流行というものは、使われているから発生するものです。
現に、私の所属しているチームでもJavascriptを扱っていますし、もしかしたら私も今後触ることがあるかもしれません。
しかし、基本的な文法ならともかく、JavascriptはPerlやC++と同じくらい闇が深いと考えているため、モチベーションも相まってなかなか触りたいと思えません。

すごく勿体ないことですし、自身の性格を直すためにも触ってみようかなと思ったり、逡巡したりを繰返す日々を過ごしています。

Webサイト開発

Javascriptの節とも関係していますが、基本的な HTML + CSS + Javascript + Webサーバー という構成Webサイトについては、1度しっかりと勉強したほうが良かったかもしれません。

学生時代にふるーいCGIサーバーを触っていたせいで、HTMLはWebサーバーで丸ごと動的生成するものだと思っていました。
HTMLとCSSで体裁を整えて、中の要素だけをWebサーバーで動的生成するほうが、シンプルで疎結合だと気付いたのは、業務で取扱うようになってからです。
HTMLとCSSとJavascriptとWebサーバーの役割を、もっとちゃんと学習すべきだったなぁと反省しています。

Docker

とある業務でDockerを触る機会がありました。
そこで、次のようなDockerfileを作ってしまい、動かないなーというミスを2日ほど経験しました。

1番目のsetup.shはどうして動かないの？

# 前略

CMD ["bash", "./setup.sh"]
CMD ["bash," "./run,sh"]

初歩的過ぎるミスなのか、調べてもどこにも「CMDコマンドでは2つのコマンドを実行できない」という文言を見つけきれませんでした（公式サイトにもちょこっと書いてあるだけでした）。
今ではDocker無しの生活は考えられませんが、学生時代にちょっとでも触っておけばよかったです。

サーバー運用

とにかくネットワーク系は苦手でした。
大学でもネットワークの授業はありましたが、基本的なコマンドさえ頭から消えていました（arp、netstat、iptables などなど）。
しかし、ネットワーク系を触るとなると、インフラを整備するような環境でもない限り、あまり機会が無いと思います。

また、基本的なサーバー運用時のイロハも学んでおけばよかったです。
プロセスの整理、インタフェースの把握、デーモンの理解、ネットワーク設定などなど、サーバー運用で学習できる内容は数知れません。

学生時代にこれらを学ぶ機会はあまり無いかもしれませんが、せっかく研究室にサーバーがあったのに、使いこなせなかったのは勿体なかったです。

ライセンス関係

学生時代、ツールは実質タダ、OSS使い放題の環境でした。
しかし、社会人になるとそう簡単ではありません。

学生であればフリーソフトでも、商用になった途端に有料というツールは珍しくなくなってきました。
もし商用利用不可／商用利用有料のツールでしか開発できない人間になってしまうと、非常に苦労すると思います。
私も、GitKrakenが使えなかったり、CLionが使えなかったりと、ライセンスの壁を認識して過ごしています。

またOSSについても、ライセンスが問題になる場合があります。
いわゆるGPL汚染と呼ばれるものですが、実際にお金を取得するプロジェクトでは、かなり気をつけなければなりません。
この辺りは、ソフトウェア工学としてフォローできそうな気がします。
ぜひ、どなたか研究してみてはいかがでしょうか？

読書

本を読む時間が減ります。
読む気力が残っていない日々ばかりです。

大学というのは、タダで高額な書籍の読み放題機関であると心得るべきでした。
時間もたっぷりあったはずなので、悔やんでも悔やみきれません。

料理

正直、こんなにコンビニ弁当の日々が続くとは思っていませんでした。
朝はパン、昼は外食、夜はコンビニ弁当のルーティンができてしまい、気付けば5キロ太っていました。
食費も結構かかります。

しかし、想像以上に料理ができません。
都会の部屋の狭さもあり、効率的な動きを余儀なくされます。
基本がなっていない人間に効率的な動きを求められても、なかなかうまく行きません。

それでも最近は少しずつ自炊をしています。
カレーを作ると2時間、麻婆豆腐を作ると1時間かかりますが......

振返って一言

いろいろありましたが、学生時代は楽しかったです。
もちろん、今の生活も楽しいです。

なんだかんだ言って、その場その時を生きていける力が最も大切なことかもしれませんね。

2019年を振り返るポエム

2019-12-19T03:09:13+09:00

この記事はcrieitのなんでも Advent Calendar 2019の19日目の記事です。前日はhammhikoさんによるlocalhost監獄でした。localhostに自分専用のアプリが増殖していくのはプログラマあるあるですね！こういったアプリケーションは世に出ることは無いとしても自分の経験や成長につながりますし、なんていうか、盆栽みたいな感じで自分好みに魔改造していくのが楽しいですよね。

さてさて、本当ならこの記事には今やっているKubernetesとかGoとかPythonがらみのネタを書こうかなーと思ってたけど、どうにも記事が煮詰まらないまま今日を迎えてしまいました。ということで、ここはポエム…というか、今年１年の振り返りをしようかなと思います。

自社は地方都市にあり企業の規模はまぁまぁ大きいWeb系企業です。そんなところで、私はいまは小さいチーム（本当に小さい。メンバーの異動と退職が相次いで今はなんと２人！もはやチームではなくてペアと呼んだほうが正しい）のマネージャーをしている。チームの役割としては、インフラのためのアプリケーションを開発したり運用したりしている。個人としては、これまでのプログラマの仕事に加えて、マネージャー業、特に採用活動もやっている。採用活動というのは本当に大変で、自分のチームにフィットする人というのは予想以上にいなかったりする。また、これまでのプログラマとしての仕事が減ることなく、というかむしろ増え続けていて、振り返ってみるとそれなりに消耗した一年になってしまったように思います。

突然ですが、今って空前絶後の人手不足じゃないですか。それは弊社でも同じで全然人が採用できない！というかそもそも応募が無い！わけあって、外部のリクルーターを使うのをやめてしまったため、自分で候補者を探す必要があるんだけど、ちょっと知り合ったやつの口車に乗って選考に応募する奇特な人など見つかるはずもなく…。自分の個人的な人脈とかを駆使しても、なかなか応募まで至らなかったりする…人望をどこかに置いてきてしまったらしい…

ということで、そもそもなんでこんなに応募が無いのか、あるいは応募してもらうことができてないのかということをここ最近（数ヶ月以上）ずっと考えている。たぶん色々理由はあって、うちに来たらどのくらいのお賃金がもらえるよとか、どういうことをやってもらいたいと思っているよ、とかそういう具体的な話ができないことが多いからということがある。もちろん、ある程度のことは話せるんだけど、なかなか相手に刺さるようなことが言えない。まぁこれは私の会話力が低いからなんだろうけど…

いずれにしてもこのまま採用活動しててもなかなかうまいこといかないなーというのが今年の反省。来年はもっとカンファレンスでの登壇とかを増やして自社の知名度をあげるのと、海外遠征も視野に入れて採用活動をしないといけないかもなーと思っている。なにせ地方には人がいない！地元からの応募があれば嬉しいんだけど、なかなかマッチするひとがいない…

次に技術的な振り返り。去年もそうだったけど、今年もたくさんコードを書いた。なにせ人手不足なものでね…アラフォーですよ、私…35歳定年説はどこいった。まぁそれはおいといて、今年はKubernetesを実戦で使うことができてサービス投入までできたのでそれは良かったなー。まぁ私が関わったのは最初の立ち上げのところまでで、今は別のメンバーが運用しているんだけど…Kubernetesに関しては運用のほうが圧倒的に大変で、だけど、学ぶところが多いのでインフラレイヤーに興味がある人は絶対に触っておいたほうが良い。まぁでも世の中的にKubernetesが必要なサービスってどのくらいあるのか、言うほどKubernetesが必要になることって無いんじゃないかなとは思うけど。もっと簡単に問題が解決できるなら、Kubernetesは無理に使わなくてもいいと思う。Ref: Maybe You Don't Need Kubernetes

多分、今年一番書いたコードはGoだと思う。自分でも意外だったけど、GoでWebアプリケーションを書いたことがあんまりなくって、初めてechoというフレームワークを使った。Flaskとかfalconみたいなマイクロフレームワークを使ったことがある人ならすんなり使えるんじゃないかなと思う。ただ、個人的な感想としては、Goで複雑なモデル操作が必要なアプリケーションは書かないほうがいいんじゃないかなって思う。やっぱりPythonみたいな動的言語と比べると、コード量が増えがちだし、面倒ではある。もちろん型付言語としてのメリットを享受することはできるんだけど。まぁでもGoは楽しい言語だし、使い勝手が良い言語なので、これからもGoをたくさん書くんだろうなーと思う。Goで面白いトピックはなんかあったけなーと思ったけど、面白い話題はだいたいDave Cheneyのブログにあるので、これを暇なときに読んでいれば良いと思う。

えー、次はPythonですかね。Pythonでは別のWebアプリケーションを作った。なんか最近はresponderとかいうWebフレームワークが流行っているらしく、開発者はrequestsとかpipenvを作った人らしい。ということで、まず間違いなく近いうちに主流になってそうなんだけど、色々あってDjangoを使った。というのは別にどうでも良いんだけど、今回はPaste Deploymentを紹介したい。

Paste Deploymentは設定管理のためのソフトウェアみたいなやつで、アプリケーションの設定をスクリプトじゃなくて宣言的に管理することを目的に開発されたもの。また、こいつはDjangoが起動させるWSGIアプリケーションを読み込むことができるんだけど、HTTPリクエストをpipelineで処理させることができる。どういうことか簡単に言うと、自分のアプリケーションに来る前（あるいは後）に別のアプリケーションをフィルターとして置いて、ユーザーからのHTTPリクエストを事前/事後に処理することができる。

これの何が嬉しいのか？それは認証処理のような、本来アプリケーションのビジネスロジックとは無関係なものを自分のアプリケーションから切り出すことができる。それにより、自分のアプリケーションは本来集中すべき処理に集中することができるので、余計なロジックを持たなくて良くなる。これにより、テストが格段に書きやすくなる。認証処理を考慮してテストを書くのは本当に面倒で、OAuth的な認証処理とかだったりするときはこういったやり方がとても便利。フィルターを利用したWebフレームワーク自体はそんなに珍しくないし、むしろ古くからあるんだけど、自分のアプリケーションから切り離して利用することができるのは結構珍しいんじゃないかなと思う。どっかで話すことができたら良いな。

（なんか文字数がこのあたりで2,700を超えてきたので、そろそろまとめに入ろう…）

そんなこんなで技術的には色々挑戦できて学びが多かったけど、いかんせん業務量が多くてつらぽよだった…特に採用活動は本当にどうにかしないといけなくて、来年はどうにか解決したい。あと、せっかくcrieitに記事をポツポツと投稿していることだし、個人開発のビッグウェーブに乗りたいところ。アイデアはボチボチあるけど、時間を作らないと…来年はゆとりある暮らしをしたいですな…

ということで、3,000字を超えそうなので、このへんで終わりにします。明日はきんみさんです！お楽しみに！

localhost監獄

2019-12-18T23:20:07+09:00

ここはlocalhost監獄。様々なwebアプリやスマホアプリが投獄されて日々を過ごしている。
あなたはアプリを監獄(localhost)にぶち込んだ、検察官であり、裁判官であり、看守(アプリの開発者)である。
今のあなたの仕事は、囚人(アプリ)を更生(完成)させ外の世界(インターネット)に旅立たせる(リリースする)ことだ。
ところがこの囚人(アプリ)たち、なかなか厄介で、思った様に働いてくれない。
彼らが日の目を浴びる日はいつくるのやら。

さて

crieitのなんでも Advent Calendar 2019の18日目の記事です。ぎりぎりまだ18日です。
前日はHataさんのプログラミングが好きでずっとプログラミングしていたい。2019でした。
ハートフルでなんかこう、好きなことに打ち込むっていいな、と思わせてくれる記事でした。
そんな記事の翌日に、こんな意味のわからんポエムから始まる記事をぶっ込んで申し訳ない。懺悔します。
（あと、たぶん、赤っぽいジャケットの長髪のカツラの人は彦じゃなくて、…きみま…）

localhostになんかいる。いっぱい

さてさて。去年、公共HP検索というサイトを作って以来、実は色々とwebアプリを作ってきました。
そいつらがみんな、ローカルホストで鎮座している。
上記のサイトですら閑古鳥が鳴く状態なのですが、それ以外は世に出てすらいない。
まあ、理由ははっきりしているんですけど。

理由1.完成させようとしている

個人開発の先人方はみんな言っていると思うので、今更なんですが。
完成させようとしたらいつまでも完成しない。個人開発は締め切りがないのでパーキンソンの法則にしたがって、仕事量が無限に膨れ上がる。
ある程度見切りをつけてリリースしないとダメ。
わかってます。それでもリリースできないのは他にも理由があるからです。

理由2.localhostで十分

これが結構マズい。
そもそも、僕が何かを作る時って、
こういうの欲しいな、どっかにないかな？→ないなー→よし、作るか！
こんな感じなので、一番の利用者は自分。自分が使うならlocalhostで十分ってなりがちです。出先で使いたいってなっても、最低限で作ってherokuやfirebaseにデプロイして、不安なら認証もかければ十分。
そうやって完成度4割5割のアプリがどんどん増えていく。

とはいえ、作りかけのものを友達に見てもらうと（お世辞かもしれないけど）褒めてもらえるので、やっぱり他の人にも使ってもらいたいなという欲はあるんです。
それでもリリースできないのは他にも理由が(ry

理由3.個人開発に対する優先度が低い

いや、割と致命的だよね。
平日はフルタイムで働いて、定時後はジム行って汗流して、週末はクラブチーム所属でスポーツしてるんだもん。そりゃあ個人開発に時間取れないよねーって。
（個人開発の話じゃないけど、完全にこれですよね）
まあ、そういう風に物事の優先度を設定しているのは他ならぬ自分なので、致し方ないというか。
第一、みんな他にやることある中で、時間見つけて個人開発しているはずですから、条件一緒のはずなんですよね。

それでも良くね？

例えば、
プロ野球選手が草野球をやっている人に対して「真面目にやれ！」と怒ることはないと思います。
逆に、草野球の人がプロ野球を見てレベルの差を見て「自分が野球をやるなんておこがましい」と卑屈になる人もいないと思います。
あたりまえですよね（たぶん）。

個人開発だって一緒で、いろんなスタンスの人がいるはずです。
これを読んでいる人も「何を当たり前のことを」と思っていると思います。
けど、twitterとかで個人開発にすごい熱量を注いでいる人を見ると、卑屈になってしまう自分がいて、その気持ちを落ち着かせるために文章にする必要があって、今書いているわけです。

結局のところ、自分が楽しいとか面白いとか思えればそれで良いのでは、って思ってます。
（うまくいかないとか、辛いとかの試行錯誤とか諸々含めての「楽しい」）

面白ければ良いんだ。面白ければ、無駄遣いではない。子供の砂遊びと同じだよ。面白くなかったら、誰が研究なんてするもんか。¹

森博嗣「冷たい密室と博士たち」より

とはいえ

全然何も世の中に出さずにこんな事を語るのも居心地が悪いので、新しいwebアプリをリリースしようと思います。（小規模なやつだけど）
本当はこの日に間に合わせるはずでしたが、色々諸事情でできなかったので、年末年始でリリースします。

頑張ります

明日はshigeさんです！

ドラマ化したときにこのセリフが採用されなかったのが本当に納得できない。このシーンあったのに ↩︎

プログラミングが好きでずっとプログラミングしていたい。2019

2019-12-18T04:45:35+09:00

昨日のアドベントカレンダーの記事は、kakisoftさんの
２０１９年：乱発したアウトプットの振り返り
でした。

す、すごいアウトプットの量、、作れたらいいな〜と考えても、全然量産出来ないので尊敬です。しかもポートフォリオの技術欄にも、いっぱい星が並んでるー！

あ、スマホアプリ作って広告貼れば、アドセンスよりは収益いいかもしれません…
（私は受け取れるほど稼いでいませんが…AdMob上に貯まっていってます…）

■ 2019年の個人的なふりかえりと自己紹介です

ちょうど一年前のアドベントカレンダーに、思いきって初めて書いたのが以下のポエム記事です。

今年スマホアプリを作ってプログラマーになった40代女性の話。https://crieit.net/posts/40

あれから1年…

（赤っぽいジャケットの長髪のカツラの人が思い浮かびましたが、名前が出てこない…彦…）

今日も「なんでも」ポエムを書かせていただきます。
ポエムって「技術記事ではない」という意味で使っています。つまりこれは私的な散文です。

あ、注意書きに「プログラマー、クリエイターが興味のあることであれば」って載ってましたね。
興味のあること…orz

■ 2019年の仕事

2018年11月末で2018年6月からプログラマーとして働いていた会社を辞めた私は、
2019年2月から3月末ぐらいまでフルリモートで働き、
2019年5月に技術派遣で始めた仕事は2日で辞め、
2019年6月末から、現在の会社で主にVBAで仕事をしております。

その間に何度かCrieitに記事を書かせていただいたので
もし気になる方がいればこちらをどうぞ。
https://crieit.net/users/33hata33

怒涛の1年でした。
今年も転職の年というか、ひとところにとどまらない日々でした。
フルリモートでハートブレイクした後は、技術派遣を2日で辞めたことでさらに傷つき、
凹みまくり、あああもうどんな仕事もできないかもしれないいいいい・・・・と、なっておりました。

もううどんかもしれないいいいいいと言ったところで
税金などの請求は来る訳で、、生きているとお金がかかりますね。

ちょっとでもいいから収入を得なければ、ということで、
とりあえず（社会復帰のリハビリのために）これなら大丈夫かな〜？と
おそるおそる週3日のCAD仕事に応募しまして。

ふと気付いたら、
その会社で、上司にも周りの人にも恵まれ（人間関係とても大事ですね〜）
結局CADではなく、初めてのVBAで開発を担当して、
とても楽しく仕事をさせていただいております。ありがたや〜

今年の働いた日数こんなです。
1月は0日、2月は約20日、3月は約10日、4月は0日、5月は2日、6月は3日、
7月,8月は週3日、9月,10月は週2,3日…

ぼこぼこに凹んだメンタルは、安定して小稼働で働くことで、
こんな記事を書けるまでに回復しました。

今の仕事は、気分的には、お題を出されて解答を考えるとお金がもらえる、みたいな気分でできてます。
本人にとっては、クイズの答えを考えるのが仕事みたいで、ラッキー♪タナボタ♪みたいな感じです。

（でもまあ…11月頃からちょっと状況が変わってきて、難易度が上がって、やりがいもその分ありますが…）
（楽しいけど時間が…足り…な…い…？）

■ 2019年の個人開発

Web

1つWebサービスを作ってみました。
勉強していたLaravelを使って、何かしら完成させようと思い、ハードルを下げまくって作りました。
ハードル上げると完成できなくなるので。

なんのために作ったのかって、これ、ポートフォリオにするつもりだったみたいです。
せっかくだから広く公開しちゃえ〜と出しました。

サービスリリースしました(=ﾟ-ﾟ)ﾉ週休5日のプログラマーは快適という話。

そして学んだことは、（技術云々はさておき）
Webサービスは、AppleのAppStoreに並べられないから、
ほっといても知らない人が検索して見つけて使ってくれることはあまりないのだろう、ということ。

「作る」のは楽しくても、それ以外の作業が膨大に存在すること。
そうはいっても、ユーザーをちゃんと獲得している人々がいること。

たくさん作ったら、どれかはヒットするかもしれない。
それだけ数が作れるようになっていれば技術も向上しているだろうし…なんて妄想はします。

別のアイディアもあるのですが（脳内に）。

スマホアプリ

Appleのデベロッパー登録も、2年目の更新はしたものの、
今年は、ちょっとバージョンアップしただけになっています。

ところが、ずっとどうしてもこれだけは活用せねばならない、という使命感のある絵がありまして。
そのままもう1年以上経っているのですが、2020年はスマホアプリを完成させますよ…！

そしてまあ…スマホアプリ作れると知られると、作ってほしい！と言われることがありますね。
最近そう言われて、珍しくいやだと思わなかったので、前述のアプリを完成させたあと、
取りかかれたらいいな。（来年の抱負）

■ 大切にしたいこと

いろいろやっていみて気付きました。

プログラミングが大好き

私は「プログラミング」自体が好きです。どうやって実現するか、ロジックを考えるのも好きです。
設計も好きです。ドキュメントを見栄え良く作るのは、あまり得意ではないですが。

プログラミングが好きなので、何を作るかというのは二の次です。
作れそうなものを作っています。

何が好きって、業務システムがわりと好きです。
どちらかといえば、求人サイトを作るよりは、特定の事業者向けの専門ソフトを作る方が好みです。

コード書いてる時が幸せです。

新しいことを知るのが好き

デザインは苦手ですが、今年はCSSの基本をやってみたりはしました。
やったことのないことをやってみるのが好きです。
自分にとって簡単すぎることを続けるのはちょっと苦痛です。

自由が好き

決められていることが苦手です。
毎日会社に行かねばならないのは辛い。
会社が好きでも辛い（気力と体力が）。

人が大勢いるところ（職場とか）にずっと居続けるのがちょっと辛い。
カフェも人がいるので、家が一番ホッとします。

今はなぜか、半分会社で半分家で仕事をしている上に
出社日も融通がきくのでとても助かっています。

自由な時間は、たくさんある方がいいです。

週2日会社に行くと、人と話すリハビリになるので、
私にとってはちょうど良い頻度みたいです。

安心したい

安心して過ごしていないと、不安だと何もできなくなります。
なので、ある程度の収入と自由な時間がバランス良くあると良いです。

大半の人はそうかも…？

窮地に追い込んで力を発揮するタイプではありません。

脳内お花畑

テレビのニュースは基本的に見ません。
事件や事故のニュースを聞くと、映像が頭に浮かんで怖いからです（子供の頃はそうだった）。

私は、自分の頭の中は、ホワホワ幸せでいたいのです。
みんな仲良く平和に楽しく過ごしている、と思いたいのです。

たとえ本当はそうでなくても、私が知らなければそれで良いと思っています。
社内の人間関係の裏話とか聞きたくないです。

NHK教育テレビ番組の、子供向け番組の、
どちらかといえば人間が出てこないものの方が好きです。（誰も聞いてないって）

■ 総括

私は、2017年頃（それまでも）、
「プログラマーとして仕事したいなあ、でもやっぱりむりかなあ、でもやりたいなあ」
と思っていました。

理由は、プログラミングが好きでずっとプログラミングしていたいから。

2018年にスマホアプリを初めて作りました。
プログラマーとして仕事も始めることができました。
家から自転車で20分の距離の会社に、ホームページのお問い合わせフォームから問い合わせました。
（半年で辞めたけど。今は会社自体が引っ越してもっと遠くなりました。）

2019年は、上に書いた派遣に行く前も、決まってから1ヶ月ぐらいあったので、
ずっと家で勉強してました。
でも会社に行ったら、誰も教えてくれない状態で、
10年以上前の複雑で膨大なコードを読むのは心折れました。

入門書をいくら読んだところで、書籍でいくら実践したところで、
実務のコードがスラスラ読める訳ではないですもんね。
しかもプログラム実行もできない環境で、順に追っていくことすら難しく。
質問しても、そのぐらいわからないと後で困るから、という感じで答えてもらえず。

それにしても2日は早いだろう、と思いますが、社内の雰囲気もちょっと…で。
たらればですが、もし一緒に面談を受けた人が一緒に入っていたら、励ましあって頑張れたかもしれません。

打たれ弱いんです。ここで負けないぞ！と歯を食いしばって頑張れるタイプではないのです。

でも、そのおかげで、今のとても恵まれた環境で、楽しい気持ちで仕事ができているので、
人生ってどう転ぶかわかりませんね。

YOUも勝手に自分を諦めずに、生きているうちにやりたいことやろう〜♪

２０１９年：乱発したアウトプットの振り返り

2019-12-16T07:00:09+09:00

今年は、
「クオリティの高低は置いといて、アウトプットを増やしていこう！」
と思い、作ったものは片っ端から晒していったので、それを振り返っていくエントリです。

ポートフォリオ

https://kakisoft-portfolio-v2.netlify.com/

さすがに bootstrap3 で作ってそのまま放置というのは気持ち悪くなってきたのでリニューアル。
作った物の整頓もしたくなったし。
Vue.js/vuetify で作り、Netlify にホスティング。

公園を中心とした、子供と遊ぶ場所をピックアップしていくサイト

https://kaki-playground.com/

コンセプトは、
「歩いて行ける、子供と遊ぶ場所！」
（対象：福岡市周辺）

ちっちゃな子供がいると行動範囲が限定される！
旅行に行っても子供たちが覚えてないから思い出にもならないし、子供かかえたままだと親側も楽しめない！

そんな悩みをかかえ、
「じゃ、せめて周辺で遊べる場所をピックアップしていくかー！」
という動機で始めたサイト。

もう少し言えば、
「公園を探すサービスがいくつかあるけど、全国区で探す必要なくない？
せいぜい半径５キロぐらいの範囲がカバーできてればそれでいいのでは？」
と思ったのがきっかけ。

週１ペースくらいで更新していこうかと思ったが、最近、息子君がインドア派になってきたせいで、絶賛凍結中！
ここから発展形の妄想だけは膨らませているので、温かくなったら再開したい。。。
やってみたい事が、子供が一緒に遊んでくれる間じゃないと実現しづらいので、優先度上げて何とかせねば。

GatsbyJS で作って、Netlify にホスティング。

人狼ゲーム用語集（英語）

https://kakisoft.github.io/WerewolfGameInEnglish/

英語で人狼ゲームをやって遊ぶコミュニティに参加した時に作った。

リニューアルして、管理者はキーワードが追加できるなどの機能を追加・・・したいんだけど時間ががが
来年、ちゃんと作りたい。

MkDocs で作成し、GitHub Pagesにデプロイ。

作ったチンケなアプリ１：異名ジェネレータ

https://another-name-generator.netlify.com/

異名ってありますよね！

「死の天使」とか
「砂漠の狐」とか
「音速の貴公子」とか、そういうの。

いいのが思いつかない時に、ランダムに言葉組み合わせて、おりゃーなんか出ろーって生成しちゃうサービス。

Vue.js で作って、Netlify にホスティング。

作ったチンケなアプリ２：CSV to TABLE

https://csv-to-table.netlify.com/

CSV をテキストエリアに入力したら、ちょっといい感じにテーブル化する。

ダウンロードして遊ぼうと思ってたデータがCSV形式だったんで、その過程で作ってみた。

同じく、Vue.js を使い、Netlify にホスティング。

ネタポートフォリオ

https://kakisoft-tmp-portfolio.studio.design/11

ネタで作成した、情報量ゼロのポートフォリオサイト。見た目だけはちょっと良さげ。
個人的には、ちょっと気に入ってる。

STUDIOを使ってます。

良さげな画像と適当な英語を並べた、一見クールなサイト

https://atarima-e.studio.design/

ネタサイト。
一見、「こんなクールなサイトができたぜ！」と錯覚させる事ができました。

同じく、STUDIO を使ってます。

技術ブログ（2016年～）

https://www.kakistamp.com/

コンセプトは、
「必要な情報をパッと取り出して、すぐに自分のタスクに戻りたい人向け」

不要な情報はトコトン削ぎ落とし、可能な限り短く簡潔に書くことを心がけています。

最近はペースが落ちて、月に１本くらいしか書いてない。
そして今年の後半は完全にサボってる。
継続してちゃんと書こう。

はてなブログを使っています。

ゆるく書いてるブログ（３月～）　※現在は閉鎖

https://kakiflow.com/

「こんな事ができた！」
ではなく、
「うぎゃーー！わからーーん！！」
というポイントに焦点を当て、それらをどう消化して行ってるかを記録する目的で書き始めたブログ。
だんだん技術と関係ない事も書くようになってきた。
毎日、何かしらのログとして書き残していこうかと思ったが、子育てがしんどすぎて断念。詳細は後述。

気がつけば、読んでもらう事を前提としないようなポエム的なエントリと、読んでもらう事を意識したエントリがごちゃまぜになって訳わからなさが加速してるんで、趣旨およびブログ名を変え、ドメインの取り直しからやり直す予定。

色々と失敗してんなと思ったが、元々、特に深い考えも無しに走り出したし、走っている間に色々と考えが整理できて次の方向性の案も出てきたので、結果オーライと思ってる。

WordPressを使ってます。

英語で書いてるブログ（８月～）

https://kaki-en-talk.com/

個人開発に興味があったものの、手のかかる子供たちにを相手にしながらやり遂げるのがキツ過ぎたんで、
「よし！妨害されながらでも出来る事をやろう！」という考えから始めた。

書いた内容は、先生にチェックしてもらい、修正しております。
基本、
「文法的に正しいかどうか自信がなくても無理にでも英文を書く → 悪い所を指摘してもらって修正する」
というサイクルで進めてる。

現在、書き始めて連続更新４ヶ月が経過。
おお。よく続いてるな。
しょーもない内容を垂れ流し続けるだけでなく、別の利用方も考えているが、多分、もう少し先。

WordPressを使っているが、色々あって GatsbyJS か Gridsome あたりに移行したいなと考えてる。
理由は後述。

英文イディオム集

https://englishtextbook01.netlify.com/

英文の添削をお願いしている先生から、「語彙力が弱いので、強化しといた方がいい」と言われたので書き始めた。

こちらは GatsbyJS + Netlify で作成。サクサク動くのが気持ちいい。
こういった、何度も読み返して頭に叩き込む系の代物は、サイトがスピーディーに動いていた方がいいな。と思い、日記の方も爆速フレームワークを使いたくなった。

日記は WordPress を使っているが、記事は WP Editor.md というプラグインを使ってマークダウンで書いているので、移行がしやすいようにしている。

検索機能がついてないので、超絶に使いづらい。
が、改善するかどうかは気分次第。

投稿日時が妙に過去なのは、日付をソートの条件として使ってるせい。
マッハ雑に作り、雑なまま使い続けている。

スライド

２人目の子供が生まれ、家が大変になってきて家庭を優先しはじめたので、後半は勉強会への参加数が減少。
もっと積極的に参加し、アウトプットのクオリティも高めていきたいっすなー。

「Vue.js 分からーん！」と感じていたのは、自分が『オブジェクト指向の奴隷』だったんだと気がついた話。

スマートスピーカーで英語の勉強をしている話

お手軽に使う PHP

スライドには GitPitchという、マークダウンでいい感じにスライドが作れるサービスを使っています。
GitPitchの使い方をスライドにした資料は、ちょっと自信作。

GitHubだけで作成するスライド「GitPitch」の使い方　～基本編～
GitHubだけで作成するスライド「GitPitch」の使い方　～応用編～

仕事で使うちょっとしたツール

https://github.com/kakisoft/MyTrivialTools
ブチ適当でもとりあえず作って、後からブラッシュアップしていくスタイルのちょっとしたツール。
今年は確か３つ作った。
正直、自分以外の人間が使う事を想定していないので、デザインやUIは超絶に終わってる。
しかも一部は上位互換がネットのあちこちにあったりと、完全に存在意義を見失っているのもちらほら。

所感

アウトプットするにあたり、１つ決めていたことは、
「ITとあんま関係ない事も合わせて、積極的に晒していこう！」
って事だったんだけど、発信する情報に全く一貫性がねぇ・・・。

来年はもう少し何をするかにスコープを絞った方がいいのかもしんない。
でも、あれもこれもと手を出すのも楽しいので、そこはバランスの取り方って事で。

アウトプットついでの収益化を考えた

せっかくなんぼかアウトプットしてるんで、Google Adsenseつけて少しは稼げんかな。と考えてつけてみた。
技術ブログの方は月１万PVくらいあるので、少しは稼いでくれんかなと思って。（調子がいいときは２万くらいあったが、最近、かなり落ちた。）

結果、１日１～２円くらい。
小遣いにすらなりゃしねえ・・・。

考えらえれる要因はいくつか。

コンセプトが「必要な情報をパッと取り出して、すぐに自分のタスクに戻ってもらう」という趣旨。それが書き手の意図通りに動いている。（Adsenseで稼ぐ事を考えるなら、真逆の行動が必要となる）
結果、回遊率は異常に低く、離脱率も非常に高い。（他のエントリを読んでもらえない）
余計な情報は極力削ぎ落とし、できるだけ少ない文章で書くように心がけている。結果、エンタメ的な要素が皆無となり、じっくり読ませるような内容でなく、人の心に残りづらい。
書き手のキャラに興味を持ってもらうような内容にしていない
アクセスが多いのは主に Oracle関連のエントリ。調べる人は別に Oracleが好きな訳でも興味があるわけでもなく、「業務で使っているから」という理由で、職場で見ている人が大多数だと思う。（土日祝はアクセス数は十分の一ぐらいになる）
「職場で見る＝広告は業務に関連するものばかり」となり、収入の源泉にしづらい。
見る人は全員エンジニアだろうし、広告をブロックするプラグインを入れている人が大半と思われる。

という感じで、収益化に結び付く要素が何一つとして存在しない。
当初は、「アウトプットついでに、小金でも稼いでくれんかな。」と思っていたが、それにすら到達できなさそうだ。

その他、SEO絡みについては色々実験もしたので、自分なりに調査した事のを書きました。
はてなブログを独自ドメイン化したら、検索順位は下がるの？　～実験編～

はてなブログを独自ドメイン化したら、検索順位は下がるの？　～結果編～

エンジニア視点のSEOの話

SEO対策について、他ではあまり言われていない仮説

一応、AdSense とSEOコンサルで稼いでいる、その道のプロの方に、お金払ってちゃんと話を聞いてみたが、AdSense で稼ぐには、相応の戦略が必要となる事がわかった。
よくよく考えれば当然だな。
少なくとも、「とりあえず定期的にアウトプットしてたら、ついでに稼げちゃった♪」などという夢は見ない方がいいな。という事が分かっただけでも収穫だ。

エンジニアなら、技術的なアウトプットに限れば、AdSenseで稼ぐよりも、公開した内容を多くの人の目が触れる場所に投稿し、それによって自分の知名度を上げ、それを収入アップに結び付ける方が効率良さそうな気がする。
というか、”収入を上げる”というのが一番の目的とするなら、「副業で稼ぐ」よりも、「本業の収入を増やす」のが効率いい気がする。多くの場合。

なので、技術チックな事を書く場合は、何かしらの理由が無い限りは、自分のブログ以外のプラットフォームに書いた方がいいんじゃないかと思った次第。（単発記事の場合。連載記事なら話は変わってくると思う。）

「AdSenseで稼ぐ」というアクションについては、自分が苦手意識のある事がいくつか含まれている。
それをどう折り合いをつけてやっていくか、もしくは別の事をするか、というのは悩みどころだ。
といっても、自分なりの答えは出していて、「こういう方向でやってみよう！」という考えが既にあり、実践はもう少し先になる予定。
というか、よくよく観察していると、自分だけが特別苦手というわけでもなく、大多数の人がそんな気がしてきたんで、多分慣れの問題なんだと思う。

まとめ

並べるとそれなりに多そうに見えるものの、どれも小粒なので、もっとじっくりと時間をかけて育てていくものを作っていきたいなと思った。
来年は長男が幼稚園に行くし、少しは負担が減らないかなー。個人開発する時間が取りやすくなってくんないかな。

自作クソアプリを無謀にもドヤ顔で晒す…

2019-12-14T07:00:08+09:00

クソアプリ紹介記事を開いていただき本当にありがとうございます。高田と申します。

どんなクソアプリなの？

ズバリ。「福笑い」でございます。
https://portrait.piggy3.com/ja/index.html

遊び方

１．サイトにアクセスする

トップ画面が開いたらやることは１つ。「似顔絵を作成する」を押しましょう。

【クソポイント】
・ログイン機能の実装で挫折
・なのに英語対応（英語力はクソ）
・さらに独自ドメイン取得

２．遊びたい絵を選択

これは！と感じた絵を選びましょう。

【クソポイント】
・素材の追加で挫折
・このためだけに契約したPhotoshopに月々980円を払い続けている
・もうすぐお正月だから素材を充実させたい気持ちもアリ

３．自由にパーツを配置

ここだ！と感じた場所にパーツをドラッグ。「位置を確定して次へ」を押すと次のパーツの配置に進みます。この繰り返し。

【クソポイント】
・操作が直感的ではない
・「位置を確定して次へ」ボタンいらなかったかも…ドラッグして離したら自動で次のパーツに進むようにすれば良かった
・でも修正する気ナシ

４．タイトルを設定

これだ！というタイトルを付けてあげましょう。あえて未設定も可。心の準備ができたら「確定」を押します。

【クソポイント】
完成した絵を確認する前にタイトル付けを強要

５．完成！

おめでとうございます！完成した作品のURLをコピーしてSNSにシェアしましょう！

【クソポイント】
・SNSのシェアボタンではなくURLコピペスタイル

最後に作者の自己紹介

ここまでお読みいただき本当にありがとうございます。

お仕事ではOffice 365などのクラウドサービス導入支援・利活用サービス提供を生業としております。最近は営業寄りの活動が中心になっており仕事上では技術に触れる機会が激減中です。

本クソアプリはAWSのサーバーレスに興味があり趣味の範疇で手を出してみた結果です。Web開発で飯を食う目標は持っていませんが、自分でやってみることで本格的なサービスを開発しているエンジニアの皆様の凄さをより理解できるようになりました。なにより、モノづくりの過程であれこれと勉強している時間が本当に楽しかったです（ある程度形になると飽きっぽさが出てしまいます…）。Udemyの動画教材でAWSを契約するところから学んだのですが、ついつい楽しくて徹夜をしてしまったこともあり。仕事の合間に短期集中で１か月くらいの期間で作成しました。

最後の最後にクソアプリの構成だけ載せておきます。

AWSサービス名	役割
Lambda	・サーバー側処理の実行（Pythonを使用）
S3	・htmlやjsなどの静的コンテンツ配置・Lambdaで生成した画像データ保管
DynamoDB	・システム用レコード管理・ユーザー作成の画像データに紐づくプロパティ情報保管
API Gateway	・Lambdaの処理をREST APIとして提供するための設定
CloudFront	・キャッシュ管理（CDN）・S3/API Gatewayのコンテンツにユーザーがアクセスするためのマッピング設定
Route53	・ドメイン管理・S3/API GatewayをCloudFrontにマッピングするための定義

今更、「AWSなのに、エモい」の読書感想文

2019-12-02T11:36:03+09:00

この記事は「Qiitadon Advent Calendar」の2日目の記事です。

なお、1日目はこの記事を書いている時点では誰もエントリーしておりませんでした。

思いつきでアドベントカレンダーを立ち上げるからこうなるのである。

そしてさらに厄介なことに、立ち上げた当人がそこまでQiitadonにまつわるネタがあるわけでもなかった。

「とりあえず楽しそう」という安易な気持ちが、いつも自分の首を締めるのである。

なので私は改めて、ほぼ躁状態で書いたであろう「Qiitadon Advent Calendar」の説明文を読み直した。

明美（Qiitaファンミーティング（非公式含む））、大喜利、お勧めクライアント、ROM専の方の自己紹介、ポエム、カーテン、エモい話、Qiitadon説明書やQiitadonの皆さんに助けられましたなど。どうぞ。

カーテン、エモい話

明らかにある人物を意識している文節がある。かろてん氏だ。

そしてかろてん氏に頼まれていた宿題を、全くやっていなかった。
「書評」である。

ということで、この記事を書くために先程「AWSなのに、エモい。」を読んだ。

主人公の「透（すける）」がAmazonの運営している施設で1枚のフロッピーディスクを拾ったところから物語は始まる。全ページで87ページくらいなので、なにか大切な気持ちを失いかけていたAWS利用者は読むと何かが思い出せるかもしれない（著者はそれを「エモい気持ち」と称しているが）。

サーバーというものが私達の身近で物理的に存在を感じれるものではなくなってから、思ったより時間が経っただろう。

コマンドを叩けば――もしかするとブラウザの画面からマウス操作で――AWSのインスタンスやリソースを操作できるこの時代、そこまでHTTPやTCP/IPのことを分かっていなくても、つまりそのコマンドが何を意図して伝達されるのかなぞ、意識しなくてもいいのかもしれない。

たとえそれが、中で誰を幽閉していたとしても、もしくは古代の文明の力で動いていたとしても、オペレーターが知る必要が無いのかもしれない。
この「AWSなのに、エモい」は、そういった皮肉を、とてもうまく物語としてまとめているのである。

全体としても分量は多くないものの、読後感はむしろ清々しいのがこの物語の強いところである。
もちろん、巻末には解説が載っているので技術書の体裁をしている。

大人になって忘れてしまった気持ちを取り戻せる技術書である。エモい。

Koretteのオモテとウラ

2018-12-07T07:27:05+09:00

こちらはCrieitの個人開発サービスに用いられている技術 Advent Calendar 2018の7日目の記事です。

前日は🍃🥜🗼sola🗼🥜🍃さんの「初めてのウェブサービスを WordPress + Vue.js で開発した話」についてでした！

Koretteって？

「Korette（コレッテ）」というのは、私が運営している、観光地の魅力を題材にしたクイズの回答と投稿ができるWebサービスのことです。

本業エンジニアではなく、IT業界の人間ですらなかった自分が、ほぼゼロから独学でプログラミングを学びながら、9ヶ月かけてリリースしました。

https://korette.jp/

このサービスを作ったのは、私が30代半ば頃から感じ始めた、「社会のために何か役立つことがしたい」、「組織の肩書きではなく個人として何かを成し遂げたい」、「自分が人に直接人の役に立つ実感が得られることがしたい」、そういったことを思うようになったことがきっかけです。

具体的になにをするかを延々と考えた末、「地域の人が自分の街の魅力を知り、好きになり、誰かに伝える、次の世代に残したくなる」そういう社会を実現しようと思い至り、それを実現するプラットフォームとしてKoretteを開発することにしました。

Koretteは観光地の魅力を歴史や音楽、人物などといった魅力を、クイズ化するというアプローチにより、さまざまな切り口に細分化し、訴求力の高い形で観光地に興味を持つ人に伝えることができるのが特徴です。

また、クイズの作成・投稿を地域に住む人や縁のある人が行うことにより、地域密着の情報が可視化されるという特徴や、地域に住む人が魅力を再発見できることも狙っています。

さらに、題材となる観光スポットのデータには自治体のオープンデータ（約1万件）を活用しており、2018年3月には東京都主催の「東京都オープンデータアプリコンテスト」で準優勝（優秀賞）を頂きました。

少し古いですが、東京都のコンテストに応募した際の企画書をSlideShereにアップしています。

サービスへの思い入れの強さもあって、2017年12月末にこのサービスをリリースしてから、ずっとこのサービス１本でやっています。

今日はこのKoretteのオモテとウラ、テーマに沿って、Webサービスで採用している技術をオモテ（フロントエンド）とウラ（バックエンド）ということで紹介していきたいと思います。

※サービス開発の背景やリリースするまでの話などは、こちらにもまとめています。
　良かったら読んでみてください。

「中年の危機」ど真ん中のオッサンがWEBサービス作ってみた(Qiita)。

「中年の危機」ど真ん中のオッサンのWebサービスが東京都のコンテストで入賞するまで(はてなブログ）。

基本的な構成

Koretteのサービスは、フロント・サーバーサイドともにASP.NET Core（MVC）を採用、MicrosoftAzureでWindowsServer（IIS）とSQLServerを使っています。

ASP.NET Core（MVC）は、Microsoft社が提供する、C#でWebアプリケーションを作るためのMVCフレームワーク（動作環境）です。

個人開発でWebサービスを開発するときは、PHPやRubyを活用している人が多いと思いますので異端に感じる方も多いのではないでしょうか。

これは、プログラミング経験がほぼ無い自分が、かろうじて持っていた数少ない知識や経験をもとに、そこから最小の学習コストでWebサービスをリリースできるだろうと考えたのが理由です。

その時の経験から、今回Webサービスを開発するにあたり、PHPやRubyやJavaも含めいろいろな言語や開発環境を試してみたところ、C#（とその開発環境のVisualStudio）が自分で一番しっくりくる感じがありました。
これは、大学生の頃にDelphiとVisual Basicを少しだけ触ったことがあり、Delphiの元開発者がC#の開発に関わっているそうなので思想が似ている感じを受けたのかなという気がします。

そいういうわけで、KoretteはASP.NET Core（MVC）をベースに開発スタートしました。
リリース後、機能改善を進めるなかで画面遷移させたくない箇所についてWebAPI＋Ajaxでフロント側を更新するページを徐々に増やしていき、今の形になっています。

徐々にフロント側の動的更新の比重が増えてきたことから、現在はかなりJavaScriptを弄る比重が高くなっています。ただ、これもC#をベースに色々と学んだお陰で応用が利いていて、イチからJavaScriptを学ぶより遙かに習得が早くなってい気がしています（たぶん最初からJavaScriptだと発狂してリリースに至らなかったかも・・・）。

オモテ（フロントエンド）

採用しているフレームワーク・ライブラリなど

ASP.NET Core（MVC）で表示されたビューのHTMLのDOMをJQueryを使って書き換えるという古典的な手法を採用しています。

VueやReactといったフレームワークは採用していないのは、プログラミング経験んがほとんどない自分がWebサービスをリリースするにあたり、フロントとバックと両方にフレームワークを学習するという二正面作戦は無理だと判断したためです。

Bootstrap4.0
リリース当初は3.x系でしたが、ページデザインのリニューアルを機にアップデートしました。
JQuery　3.3.1
リリース当初は2.2.x系でしたが、ページデザインのリニューアルを機にアップデートしました。
Material Design for Bootstrap 4（https://mdbootstrap.com/）
マテリアルデアインのUIキットです。無料版もありますが有償版の方を使ってます。
カード型のスタイルなど、Koretteのデザインのベースになっています。
leafletjs（https://leafletjs.com/）
OpenStreetMapの地図操作ライブラリです。
地図ライブラリは、当初はYahooMapを利用していましたが、OpenStreetMapの方がマッピングパーティといった地域の人が地図を更新するイベントが行われるなど、Koretteと目指すところが近いものを感じたことからOpenStreetMapに変更することにしました。
観光スポット紹介ページの地図情報などで利用しています。
Croppie（https://foliotek.github.io/Croppie/）
画像の縦横変換、切り抜き＆リサイズライブラリ。
クイズ投稿時の画像投稿機能で利用しています。
当初はアップロードしてサーバーサイドでリサイズしていましたが、ネットワーク負荷軽減などを考慮し、クライアント側で行うように変更しました。
Garlic（http://garlicjs.org/）
　投稿フォームで入力中に別画面へ遷移した際に入力内容を保持しておくライブラリ。
　利用者さんからの要望で追加した機能です。

ウラ（バックエンド）

採用しているフレームワーク・ライブラリなど

CoreTweet（https://github.com/CoreTweet/CoreTweet）
　Twitter連携のライブラリ。Koretteのアカウントへのピックアップクイズの投稿に利用しています。
SixLabors.ImageSharp（https://github.com/SixLabors/ImageSharp）
ASP.NET Core対応の画像処理ライブラリです。
当初はユーザーの投稿画像をこのライブラリでリサイズしていましたが、現在はフロント側でリサイズされてサーバサイドに飛んできますので、飛んできた画像をもとにサムネイル用とOGP用の画像を生成する際に利用しています。サムネイル用は単なるリサイズですが、OGP用は1200×630の白紙キャンパスに飛んできた画像をセンタリングして配置し縦横比を変換するという処理を行っています。
また、このライブリでは、画像無しでクイズを投稿した際にタイトル名を画像化する機能としても利用しています。

バッチ処理

リリース後の機能追加で、人気クイズのランキングや、投稿者ランキングなどを実装しました。

これらの機能について、リリース当初はユーザーが表示リクエストをした際に、クイズの解答履歴データを都度集計してランキング表示をしていました。またクイズの回答数も回答履歴を都度集計して表示していました。

利用者が増え、徐々に回答履歴データが肥大化していくとともに、これらの処理が重くなっていきました。

そこで、これらの処理をバッチ処理化することにしました。

とはいっても、専用のジョブ管理ツールとか入れるまでのレベルではないと考えたので、ASP.NET CoreのWebAPIで処理を作成し、WindowsのタスクスケジューラからPowershellのスクリプトを定時キック、PowershellのスクリプトがWebAPIに鍵情報を付加したhttpリクエストを行うことにより処理を開始するという、「なんちゃってバッチ」で実装しています。

また、バッチ処理化にあたり、大量にデータ更新するテーブルについては、障害対応とロック対策のために２テーブル化を行いました。

PrimaryテーブルとSecondaryテーブルを作成し、Primaryテーブル参照時間帯にSecondaryテーブルをバッチで更新、時間経過後はその逆を行うという形にしています。
万が一バッチ処理の異常終了でテーブルがぶっ壊れた場合は、更新テーブールに切り替わるまでに復旧作業を行える時間稼ぎができるようになっています（実際はサラリーマンやってる時間にぶっ飛んだらどうにもなりませんがｗ）。

また、バッチ化により、ランキングアルゴリズムを回答数だけでなく、複数の要素を組み合わせて集計するといったより高度な処理にすることも可能となりました。

インフラ周り

MicrosoftAzureでWindowsServer2012R2のVMを立てて、WEB・APサーバーとDBサーバー（SQLServer2016）を同居させています。

VMのDISKは容量を最小にする代わりにPremium SSDを採用しIOのボトルネックを最小化。利用者の投稿画像などは別途BLOBストレージを用意し、そちらに配置するようにしています。

自分の学習コストを最小限にするためにAzureやWindowsServerを選択していますが、ASP.NET CoreはLinuxでも動作するようになったので、Linuxへ以降すれば運用コストを減らすことができると思います（現在移行を検討中）。

技術の選択には学習コストの視点も

冒頭に触れたように、私がプログラミングをほぼゼロから覚えてリリースできたのは、少しだけあった過去の経験から学習コストが最小となるWindows系とC#を選択したというのも大きかったのかなと思います。

サービスをリリースまで至るには、技術的にオーソドックスじゃない、古くてもイケてなくても、自分の学習コストが最小化できるのであれば、それを選択しても良いと思うのです。

一度、何かの技術を使ってサービスをリリースするまで至ることができれば、そこで得た基本的な知識や他の技術でもある程度応用がきいて、学習スピードは圧倒的に上がります。

なので、いくつか軽く触ってみて、わかりやすい、使いやすいと思った言語や技術でとりあえず作ってみると良いのだと思います。

プログラミングはハマると楽しくなって、ついつい新しい技術に手を出したくなることがあります。でもサービスをリリースするという視点で考えれば、学ぶことが目的ではなく、リリースするために学ぶのが目的のはずです。
であれば、最小の学習コストという視点も観点のひとつとしてあるのかなと思います。

まずは、自分で良さそうと思うものを決めて、あとは浮気せずリリースまで突っ走ってみると良いのではと思います。

サービスのリリースはゴールではなくスタートです。
まずはどんな形でもスタートラインに立ってみると、違う世界が見えてくると思いますよ。
私のサービスはリリースしてもうすぐ1年ですが、まだスタートラインをウロウロしている気もしなくはないですが・・・。

頑張ってリリースまで到達できたら、山のように迷うことや選択を迫られることが出てきます。
そのときは、必要に応じてアドバイスをもらえる環境も大切です。特に以下2つのSlackコミュニティは知見を持った人が沢山所属していて、アドバイスや情報交換ができるのでオススメです。私も所属させてもらっています。
門を叩いてみましょう。

・マシュマロの運営者でもあるダースさんが運営している「運営者ギルド」

・SeekGeeksというプランナーとエンジニアのマッチングWebアプリを運営しているny(にぃ）さんが運営する「Monetize-Geek-JAM」

上記のコミュニティの他に、私も場合は「Koretteサポーターズ」というコミュニティを自分で作ってしまいました。
Koretteの目指すところに共感頂ける有志の方を公募させていただき、現在6名のサポーターに支えられています。
支援者＆利用者の立場で、UXの改善をはじめ、迷ったときの相談相手になって頂いていて、凄く助かっています。

Koretteのこれから

ここからは少し宣伝チックな内容です。

Koretteですが、皆様の応援に支えられ、少しづつですが利用者も増え、12月27日にリリース1周年を迎えるところです。

これまで個人サービスとしてやっていましたが、このタイミングで、非営利の運営団体を設立し、Koretteの運営を団体として行っていこうと思います。

設立する団体名は「CultiVision（カルティVision）」です。
Vison（ありたい将来）をCulti（耕す）という意味を込めて造った造語です。

「地域の人が自分の街の魅力を知り、好きになり、誰かに伝える、次の世代に残したくなる」
そんな社会の実現に向けた活動を、農業の土作りのように、地域の人とともに畑を耕すように長期的な実りを期待して活動をしていけたらと思っています。

団体化により、これまで個人名ではやりにくかった企業などとのコラボやイベントの開催などを行うなども予定しています。
Webサービスとリアルの活動を組み合わせながら、サービスのさらなる普及を目指し、ありたい将来の実現に向けて進めていく予定です。

まず、団体としての活動の第一弾として、12月中にKoretteのスマホアプリ版のリリースを予定しています！
スマホアプリ化により、より気軽に楽しく遊んで頂けるようにしていきたいと思っています。
その際は、プレスリリースも投げて、認知度を高めて行く予定です。

サービスのみためもUXもまだまだですが、サービスにかける想いだけは、他の方に負けないように、あとは沢山の人に助けてもらいながら頑張っていきたいと思っています。

今後とも応援の程、どうぞよろしくお願いいたします。

最後に

ちょっと読者ターゲットが絞れない記事になってしまったかもしれません・・。
この記事が、ほんの少しでも、みなさんのヒントになれれば幸いです。

個人開発サービスに用いられている技術 Advent Calendar 2018、明日はckoshienさんの「野球リーグスコア管理システムに用いている技術について」の記事です！お楽しみに！

なるべくお金をかけず個人開発をしていくには

2018-12-05T09:08:01+09:00

こちらはCrieitのアドベントカレンダー Advent Calendar 2018の5日目の記事です。

自分は結婚しておりまして現在お小遣い制です。
独身時代と比較すると自由に使えるお金がそんなに多くありません。

そんな中、個人でWebサービスを作るというのを趣味にしてます。
Webサービスを作るためにはお金が色々かかるわけです。

サーバー
ドメイン
素材

そこでいかにお金をかけずに個人開発をしていくかを考えながら開発しています。
そのノウハウをこの記事で書いていきたいと思います。

サーバー

作ったWebサービスを動かすための基盤が必要になるわけですがここが結構お金がかかるポイントじゃないでしょうか。
さくらのVPSやConohaを使うのが最初に思いつくと思うのですが、これは月額制です。
払っているお金以上請求が来ないというのはすごく安心感があり魅力的です。

ただ自分の場合そこにお金をあまりかけたくないです。ものすごくケチです・・・

ということでSaasなどをうまく使ってお金を最低限しかかけないようにしてます。

SaaS/PaaS/MBaaSをうまく使う

Webサービスを作るとなると

Webアプリを動かすためにWebサーバーが必要
APIを動かすためのアプリケーションサーバーが必要
DBを動かすためにDBサーバーが必要

といろんなサーバーが必要になりますし、運用を楽にするならそれぞれ冗長化をしたいところです。
となるとやたらお金がかかるので自分でインフラは用意したくないです。

ということでこういうのはSaas/PaaS/MBaaSを使って無料枠を駆使します。

Webホスティング

SPAを前提としますが、html/css/JavaScriptは静的ファイルです。
最近は無料で静的ファイルをホスティングできるところが増えてきています。

Netlify
GItHub Pages
Firebase Hosting

その他にはAWS S3でもWebホスティングできるので安く済ませることが出来ます。

またこれらはHTTPSに必要な証明書も無料で発行してくれます。
今時であれば必ずHTTPS対応しておきたいので、これは嬉しい。Let's Encryptさまさまです！
（S3であればCloud Frontを使ってHTTPS対応する必要がありますが）

APIやDB

ブラウザからは直接叩けないものをバックエンドのAPIから叩きたいとか
情報をDBに保存したいという要件は必ずあるでしょう。

これはFirebaseやHerokuといったMBaasやPassの無料枠を使うことが出来ます。

Firebase
- 認証/API/DB/ストレージと全部揃ってる
- DBはNoSQLなので要件にあったら使うといい
- 無料プランがある
Heroku
- RailsなどのWebアプリケーション置ける
- MySQLやRedisが無料で使える（制限がきついけど）

もちろんFirebaseとHerokuを組み合わせて使うことも出来るのでおすすめです。

ちなみになんですがこういうインフラを考えなくて良いサービスを作ってると監視も最低限で済みます。
Firebase起因の障害でない限り落ちたりはしないので！
監視をしたい場合はメトリクスの保持期間の少なさや制限が多いですがMackerelもフリープランがあるのでそれが使えます。

ストレージ

画像や動画を保存したくなると思いますが、それも最近は従量課金やその無料枠で使うことが出来ます。

AWS S3
Firebase Storage
Cloud Storage

ドメイン

Webサービスを公開するためにはできれば独自ドメインがほしいところです。
ただWebホスティングできるサービスはだいたいそこの無料ドメインを提供してくれるので、お金をケチりたかったらそれを使ってもいいと思います。

サブドメインをサービスのドメインにする

せっかく自分のWebサービスを作ったんだから、どうせならイケてるドメインにしたいですよね！
Kibelaは「kibe.la」というドメインで非常に美しいです・・・

ただドメインを取得するにはお金がかかります。
1ドメインが安くても年間1,000円前後はかかるんじゃないですかね。（セールはありますが！）

しかし1回買って終わりじゃなく、毎年請求がきます。
1サービスだったらいいかもしれませんが、何個も何十個も作っていくと結構な額になります。

そこで自分は、作ったサービスはほとんどサブドメインにしてます。

nyaaan.haramishio.xyz
markdowntable.haramishio.xyz
blog.haramishio.xyz
trash.haramishio.xyz

オシャレ感はありませんが、1ドメイン分のお金しか払わなくていいので安く済みます。

またサブドメイン戦略は他にもメリットがあります。

サブドメインだと広告を出すのが楽

以下の内容は間違いで、一回ルートドメインで審査通れば別ドメインでも広告出せるみたいです。

Google Adsenseで広告を出すのは一般的じゃないかなと思ってるのですが、
Adsenseはそのドメインで広告を出す許可をもらったら、そのサブドメインすべてで広告を載せることが出来ます。

僕の場合は、このブログのドメインで広告を出す許可をもらったのでその他のサブドメインで広告を載せられるようになりました。
1つ1つのサービスでドメインを取っていると毎回広告を出す申請（結構ハードル高い）をしないといけないので大変です。

素材

Webサービスを作ってると、どうしてもイラストやロゴなど素材が必要になります。
僕は絵を書くスキルが皆無なのでフリー素材でどうにかしています。

ロゴ

サービスのロゴはフリーイラストとフリーフォントで作ってます。
フリーフォントでいいのないかなーと探すときに便利なのがためしがきです。

これで良さそうなフォントを見つけたら、Gimpに入れてロゴを作ってます。

素材

フリーのイラストは「フリーイラスト ○○」でひかかったものを使ってます。
特にこれ！っていうサイトはないですが、「いらすとや」はなるべく使わないようにしてます。

なぜかというと、いらすとやのイラストの世界観が強すぎてうまくサービスにマッチしないときが多いからです。

運用方針

個人で開発・運用してますのである程度「俺ルール」を使えると思っています。

なので、現在Firebaseを従量課金プランで使うことが多いのですが
もしトラフィックが多くなり多額の請求が来そうになったらサービスを止めると思います
そういう割り切りを行えるのも個人開発のいいところだと思います。

ただ永久閉鎖というわけではなく、利益を取れるようマネタイズを考えた上でインフラをきちっと整えたものでまた出せればと思ってます。
そんな機会あるのかわかりませんがｗ

最後に

ということで、なるべくお金をかけずに個人開発をしていくにはというお話をしました。
昔よりはだいぶ安く済ませるためのサービスが出ているので、いい時代になりました。

同じようにお金あんまりかけられない・・・って人はぜひ参考にしていただけばと思います！

ちなみになんですが、現在4サービス運営しておりまして
そのサーバー費用やドメイン費用合わせて 毎月200円くらいです。
ほぼドメイン費用とDNSサーバー費用です。

次回はSさんです。お楽しみに！

Nyaaanを支える技術

2018-12-02T08:57:46+09:00

こちらはCrieitの個人開発サービスに用いられている技術 Advent Calendar 2018の2日目の記事です。
前日はなべさんの日本語のフリーフォントを一度に試せる「ためしがき」に用いられている技術についてでした！

11/5にNyaaanというWebサービスをリリースしました。

そこで

どのような技術を使ってるのか
どういう知見が得られたのか

を書いていこうと思います！

どういうサービスかは以下の記事を読んでいただけたらと思います！

https://blog.haramishio.xyz/entry/service-nyaaan

使用している技術

ざっくりな構成でいうと

フロントエンド
- Nuxt.js
Webホスティング
- Netlify
バックエンド
- Firebase

です。

Nuxt.js

Nuxt.jsはVue.jsアプリケーションを作るためのフレームワークです。
ちょっと大きめのVue.jsアプリを作る際に必要なVuexやVue Routerなどが入ってるのでNuxtをインストールすればすぐにWebアプリが作れます。
今回はSSR（サーバーサイドレンダリング）を行わないため、SPAモードで利用しています。

Netlify

Webホスティングはさまざまな種類がありますが、今回はNetlifyを選択しました。
選択した理由としては・・・

ビルドを勝手にやってくれる（npm run build がビルドコマンドよ！ってNetlifyに登録しとくだけでいい)
ビルドしたらデプロイもやってくれる
他のホスティングサービスと比較して無料枠の制限が少ない

Firebase

APIやDBが必要になったのですが、すべてFirebaseで行いました。
主要なFirebaseサービスはHostingとML Kit以外使いました。

それぞれの用途としては・・・

Authentication
- Twitter認証のため利用
Firestore
- ユーザ投稿データやユーザデータを保存
Functions
- Twitter APIに問い合わせる処理やユーザ削除機能で利用
Storage
- ユーザのアイコンの保存で利用

得られた知見

Firestoreのクエリーのクセ

FirestoreはNoSQLです。RDBのような柔軟なクエリーを書くことは出来ません。
その制限にひっかかってちょっと苦しんだ事例があるので共有します。

Nyaaanでは「有効期限」という機能があり
これを設定すると1時間または1日経つと、鳴き声（つぶやきみたいなもの）が見れなくなるというものです。

その鳴き声テーブルはこんな感じになってます（本当はもっとカラムあります）

カラム	型
ID	string
鳴き声	string
本音	string
有効期限	timestamp
作成時間	timestamp

Nyaaanにはタイムラインがあり、鳴き声は作成時間の降順でソートしたいです。
なので・・・

// カラム名はわかりやすく日本語にしてます
mewRef.where("有効期限", ">", now).orderBy("作成時間", "desc").limit(10).get()

としたかったのですがこれはNG。
範囲フィルタ(>や>=)を使う場合は、orderByの最初の要素はその範囲フィルタで使用したカラムしか指定できません。
Cloud Firestore でのデータの並べ替えと制限

RDBならこういうのは普通にできますが、NoSQLはこういう制限があるのかと勉強になりました。

結局どうしたかというと、後述するバッチ的なもので有効期限をチェックして削除してます。

FirebaseでCron的なことをしたいとき

上述したバッチ的なものの話です。

サービスを作っていくとバッチが必要になる場面があるとおもいます。
なにかしらの処理を定期的に動かすとなるとCronを使ったりJenkinsを使ったり色々あると思います。
これらはサーバーが必要になりますよね。
すでに持ってる人はそれを使えば良いんですが、僕はお金をかけたくないのでどうにかしてサーバーレスにしたいです。

さて、FirebaseのFunctionsはHTTPSフックで起動することが出来ます。
つまりcronでcurlを定期実行すればバッチみたいなことができるわけです！

そして世の中には外形監視のために定期的に指定したURLを叩いてくれるサービスがあります。
cron-job.orgやUptime Robotがそれです。

これを利用してFunctionsを定期的にトリガーするようにしてバッチ処理をサーバーレスで実現しました。

懸念点として、Functionsの実行を外部からできるようにしてしまっているのでセキュリティ的に問題ないのか？という点ですが
今回の場合はリクエスト時にGETパラメーターでアクセストークンを渡しており、そのアクセストークンじゃないとアクセス拒否するようにコーディングしています。
それでも攻撃されて突破されるリスクもなくはないので、センシティブなことをしたい場合はやめたほうがいいと思います。

Functionsの様々なトリガー

Fucntionsのトリガーは色々あります。

トリガー	内容
HTTPS	URLを叩くだけ
onCall	クライアントから直接呼び出し
Authentication	ユーザの登録/削除で呼び出し
Firestore	ドキュメントの登録/更新/削除で呼び出し
Storage	オブジェクトの登録/更新/削除で呼び出し
Pub/Sub	Cloud Pub/SubのPublishで呼び出し

NyaaanではHTTPSとAuthenticationのトリガーを使用してます。
特にAuthenticationトリガーは便利で、以下のようにFunctionsに書くだけで簡単に書くことが出来ます。

// ユーザが削除されたら実行されるFunction
exports.removeUser = functions.region('asia-northeast1').auth.user().onDelete(function(user, context) {
~~~
});

Nyaaanではユーザ削除されると今までの鳴き声が消えるようになってます。
クライアントでそこまでやると重いので、クライアントではAuthenticationのユーザだけ削除してレスポンスをすぐ返し、
FunctionsのAuthenticationトリガーで非同期で削除処理を走らせてます。

Netlifyのリダイレクト設定

Nuxt.jsのSPAモードを使用していて、Netlifyでホスティングしていたのですが
ルートパス以外を直接呼び出すと404エラーになってしまいます。(例: https://nyaaan.haramishio.xyz/top)

SPAではルートパス以外でアクセスされたらindex.htmlへリダイレクト処理をする必要があります。

Netlifyはリダイレクトの機能があり、デプロイするディレクトリのトップに _redirects を配置しそこにリダイレクト設定を記述するとリダイレクトしてくれます。

/*    /index.html   200

この話をもうちょいちゃんと説明したのがこちらの記事になります。
Netlifyを使ってたらルートパス以外が404になった話とその解決方法

最後に

ということでNyaaanの使用技術とそこから得た知見を書きました！
この記事でみなさんの開発のヒントになれれば幸いです！

さて、明日はこのアドベントカレンダーが開催されているCrieitの運営者のだらさんです！