「AdventCalendar」の記事 - Crieit

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を埋めたい、という場合は自分用のカレンダーを作って挑戦していただいても大丈夫です。また、特定のジャンルの記事があつまるといいなぁ、と思う場合にも是非カレンダーを作ってみてください。僕の知識で分かるものがあれば僕は絶対投稿します。

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

Advent Calendarを開催してみての振り返り＆考察

2018-12-27T08:10:45+09:00

12/1～12/25まで、CrieitではAdvent Calendarを開催しました。色々と振り返って考察してみたいと思います。

どんな記事が集まったか

カレンダーは下記のものがありました。

アドベントカレンダー Advent Calendar 2018

https://crieit.net/advent-calendars/2018/crieit

何を書いてもOKなカレンダーです。

個人開発サービスに用いられている技術 Advent Calendar 2018

https://crieit.net/advent-calendars/2018/technology

主に個人開発のことについて書くカレンダーです。元々最初のカレンダーだけの予定だったのですが、こちらは @nabettu さんが発案してくださり作成することになりました。この案がなかったらカレンダーも記事も存在しなかったのかと思うの恐ろしい…くらいには良い記事が集まりました。是非ご覧ください。

この２つのカレンダーにて合計約50記事程が集まりました。僕が個人開発者だからそう感じてしまうのかはわかりませんが、どの記事も非常に面白く、且つ有益で、恐らく今年の日本で数多く生まれたAdvent Calendarの中ではこれらの有益密度が一番濃かったのではないかと思うほどでした。

参加してくれた方々

１つ目のカレンダーの説明文にも書いたとおり、枠が埋まることは想定していなかったので元々25記事毎日書くつもりでした（ジョークみたいな書き方をしていましたがジョークではありませんでした）。ただ、最初に知り合いの方々にかなり枠を入れていただけ、そのおかげか、空いていた枠も徐々に埋まっていきました。これは本当にありがたかったです。

集まって頂き、記事を書いて頂け、本当にどうやって感謝していいのかがリアルに分からないほど、感謝してもしつくせない程です。ありがとうございました。

何か貢献できたのか？

何か貢献できるのだろうか、これは正直ずっと僕の中では始まる前から現在まで明確な答えは出ません。

Crieitに書けば多くの人に見てもらえるでしょうか？　まだCrieitは小さなサービスですし、それは無いと思います。書いていただいた方々の記事がすばらしいものであればあるほど、不安と申し訳無さが大きくなりました。

Crieitじゃなく、Qiitaとかに書いた方がいいね数が伸びてもっとたくさんの人に呼んでもらえたのでは？　それぞれの得意なプラットホームで書いた方がもっとはてなブックマーク数が伸びてバズってもっと多くの人の目に触れてもらうことができたのでは？　と。

CrieitにもQiitaのように本人だけに見ることができるアクセスカウンタがあります。Qiitaに書いたことがある方であるばわかるかもしれませんが、恐らくQiitaに比べてこの数値は小さいのではないでしょうか（カウントアップの仕様は違うかもしれませんが）。DB上でその値を見る度に、皆さんがっかりされてるだろうな、と申し訳なくなります。

逆にバズったらバズったでそれも、Crieitじゃなくて自分のブログとかに書いてもらっていた方が自分の資産が増えてよかったのでは？　とまた申し訳ない気持ちになります。

貢献できたこと、今後できること

ただ、そんな不安は正直色々サービスを作っていると慣れたもので、最終的にはとにかく頑張るしか無い、というところに行き着きます。悩むのではなく、じゃあ投稿してくれた方々に何を貢献できたのか、悩んだ結果今後さらに貢献できそうなのか、それを考えていくしかありません。

記事は生き続ける

ポジティブな目で考えると、そもそも記事は一度生まれると25日しか生きられないわけではありません。今後ずっと残ります。検索で誰かがたどり着いて見てくれたり、古いツイートからたどり着いたりすることもあると思いますので、今後もずっと各記事のアクセス数は増えていきます。それだけでなく、突然誰かが記事を引用などして、爆発的にアクセスが増えたりすることもあります。実際に僕もCrieitで記事を書いてからそういったことがありました。

記事は一度生まれたことで、色々なことが起こる可能性を手に入れています。確実ではないのが悲しいところではありますが、そういった部分にも期待していきたいと思っています。

何か新しいことをする機会

今回参加された方の中に、Advent Calendarに初参加、ということを何人かの方が言われているのを見かけました。もしCrieitでAdvent Calendarを開催していなかったら、その方々はAdvent Calendarに参加するという機会を得ることができなかったかもしれません。実際には今後別途何かで参加される可能性もありますが、今年参加したのとでは、その経験の違いから、本人すらも気づかない部分で、今後の１年何かしらの考え方に影響して何かが違っていくかもしれません。

他にもこういった記事を書くこと自体がはじめてだったとか、サービスに投稿するとか、想像していた以上にTwitterなどでシェアされて投稿を読んでもらえたとか、そんな感じで、今回参加しなければ得られなかった経験を提供することができたかもしれません。

逆に、参加してがっかりしたとか、大変だったから参加しなかったら良かった、とかもあるかもしれません。また、参加しようと思ったけどできなかったとか、予約したけど取り消したり、結局書かなかった、とかもあるかもしれません。そんな負の体験でも、それぞれの方にとっては一つの大切な経験になる可能性があると考えています。

そんな感じで、どんな感情であれ、何か一つでも新しいことを提供できたのであれば、Crieitが誰かに対して何かを貢献できたのでは…と思います。今は正直そういった部分しか貢献できる部分がないのですが、今後もっとなんとかCrieitを発展させて、多くのことを提供できるようにしていきたいと思っています。

Advent Calendarを開催してのデータ

大雑把な集計ですが、だいたい11月の倍程度のアクセスがありました（とはいえ元々多かったわけではないのでものすごい量というわけではありません。あとこれを書いている当日バズっている記事があるためだいぶ変わってきているかもしれません）。やはりとにかく毎日投稿があるというのはかなりの多くのメリットですね。

単純に記事が増えること自体にメリットがありますし、それに付随して、僕や投稿者自身が紹介のツイートをすることで盛り上がったきがします。そもそも毎日２記事ペースでそれができていたので、途中からどの記事がいつの記事なのかどっちのカレンダーの記事なのかもうよく分からない感じでツイートをしていました。なんにしろ紹介できるものが毎日あるというのは嬉しいことでした。

Twitter上で広がった数も多かったような印象があります。普段僕が自分で投稿していても、RTはつくかつかないか、いいねも数回つくかどうか、みたいな感じです。でもAdvent Calendar開催中はどの投稿の紹介ツイートも何度もRT以上されたりする事が多く、10RT以上の方も何回かありました。そもそも僕のツイートだけでなく、本人のツイートや、誰かがシェアしてくれたツイートなども含めると更に多くなっていました。そんな感じでSNS上でも普段よりは賑わっていた感じがありました。

来年やりたいこと

Advent Calendarを来年やるかは特に決めていませんが、機能自体が消えるわけではないので特に問題なければまたやろうかな、とは思っています。ただ、ちょっと今年は僕自身が色々気にしたり稼働したりしすぎて辛い部分があったので、あまり僕自身は関わらず、Qiitaのようにモチベーションのあるユーザーが自由にカレンダーを作って自由に運用する、の様な形でできればな…と思っています。

あと、こういったイベント開催中は良いのですが、普段やはり自分的にもユーザー的にもCrieit上でできることが少なく、「居場所」としては成り立ちにくいです。そのためボード機能という大きな機能をリリースし、ユーザーが年がら年中Crieitを居場所にし、好き勝手にお祭り騒ぎできるようにできればいいな、と思っています。詳しくは下記の記事で先日書いていますので、もしご興味があればご覧ください。

Crieitに大きい機能で次追加したいもの

まとめ

とにかく毎日感謝の１ヶ月でした。感謝の個人開発600時間でした。これだけ毎日大勢の方に感謝をし続けた月というのは生まれてはじめてだと思います。僕自身にとっても本当に良い経験となりました。

ご協力、ご参加、そして見て頂いた皆様、ほんとうにありがとうございました。今年も残り少しとなりましたが良いお年をお過ごしください。

ランニングと１年の振り返り

2018-12-22T00:27:33+09:00

この記事は、Crieitのアドベントカレンダー Advent Calendar 2018 22日目の記事になります。

はじめに

私にとってこの一年はフリーランスを始めた年であり、
「年で合計400㌔走る！」という目標を掲げた年でもありました。

結果としては21日時点で402㌔。無事達成できました！

せっかくなのでデータを見つつ、今年を振り返ってみます。

ランニング開始の背景

妻に脇腹をつねられ「あれ？なんか付いてる。。！」という発言から。
とりあえず目標を建てないと続かないと思い、
週の半分で２キロ走ることができたら、400㌔いけるなという概算で設定。

データの計測について

runtasticというスマホのアプリを利用していました。

https://www.runtastic.com/ja/

GPSを有効にしてアプリを起動して走ると、時間や走行距離を計測してくれます。
１キロ毎に走行時間をアナウンスをしてくれるのでペースを維持するのに良かったです。

アプリのサイトに行くと、データがエクスポートできるのでそこからダウンロードしました。

利用したデータ

経緯度だけマスキングしてこちらにあります。良かったら利用してみてください。

https://github.com/u110/my_runtastic_data

※ 目標達成する前にダウンロードしたデータなので、400㌔届いておらず。

この後コード片を載せますが、分析に用いたコードもリポジトリにあります。

データ構成

１回のランニングあたりの
- 経緯度
- 開始時刻
- 走行距離

があったので今回はそれのみ。

他にも毎分あたりの経緯度やペースなども見れるようです。
コードの一部

dat = preprocess(df)  # 前処理を行ったDataFrameを返す関数を用意
dat.head()

出力結果

ヒストグラム

まずは１変数のヒストグラムを見ましょう。
データのプロットはpythonで書いています（全コードはgithubリポジトリにあります）

# 走行距離分布(単位:メートル)
# 3, 4キロあたりが多い。
dat.distance.hist()

# ランニング開始時間 基本的に6-7時台
dat.shour.hist()

swarmplot

日本語だと蜂群図(bee swarm plot)というらしいです。
データの個数やばらつぎ具合が把握できるので便利です。
（データ増えると描画に時間かかるので注意）

# １回あたりの走行距離の分布
sns.swarmplot(x="smonth", y="distance", data=dat)

データを見た気づき

時系列でみると、１回に走る距離が伸びている
- 見るまでもなく実感はあった。
- 年の始めは２キロでへばっていたが、夏場は帰省先（長野県）が快適だったのもあり結構走れていた。
4, 7, 11, 12月で走る回数が減っている
- そういえば、4月は仕事でもやもやしていた時期でしたｗ
- 7月は息子爆誕。パパ業が開始した月でした。
- 冬は寒い。。朝布団から出られないｗ
5月、9月で持ち返している
- 5月で産休の妻と実家に帰省。仕事もセーブしていたので暇だったw
- 9月はDevelopers JPに参加。slackの筋トレチャンネルで報告を始めたのが良かったのかも
- Djpの人めっちゃ褒めてくれるので頑張れる。

まとめ

走れている月は仕事やプライベートの調子も良かった。
応援もらえるの嬉しい。
データ溜まっていくと分析しがいがありそう。

他の情報についてはまだ見れていないので
時間見つけて触ってみたいです。pull requestくれても良いですよ！？

簡単ですが、以上になります。お読みいただきありがとうございました！

次のエントリをお楽しみに！！

余談: あれ？makeの話は？

https://github.com/u110/my_runtastic_data/blob/master/Makefile

経緯度の情報をマスキングする処理だけ書きましたが、
物足りなかったのでデータ分析にしましたw

Advent Calendarを開始しました

2018-10-31T23:47:20+09:00

CrieitでAdvent Calendar機能をリリースし、参加者の募集を開始しました。

アドベントカレンダーというのはクリスマスまでの日数を数えながら過ごすイベントのことで、毎年QiitaやAdventarで記事を書くお祭りイベントとして開催されています。そのイベントをCrieitでも開催してみることにしました。

今年は２つのカレンダーを作成してあります。

Crieit Advent Calendar

とりあえずやってみようということで作成したカレンダーです。

https://crieit.net/advent-calendars/2018/crieit

こちらは特にテーマはなく、Crieitの趣旨にあったものであればどんなものでも投稿可能です。アドベントカレンダーの練習や数行の投稿でも全然OKです。

個人開発サービスに用いられている技術

https://crieit.net/advent-calendars/2018/technology

個人開発者が自分のサービスの技術を公開してくれたら面白いのでは、という声をうけ急遽作成しました。

何か開発されている方ということにはなりますので誰でもというわけにはいきませんが、どんなちょっとしたものでも良いので何か作られている方がいれば是非ご参加ください。

まとめ

とにかく初ということで、且つCrieitもまだまだ小さなサービスですので、カレンダーが埋まるというところまでは想像していません。とにかく一人でも多くの方にご参加いただき少しでも楽しんでいただければな、と考えています。

開発者もどのような投稿でも非常に嬉しいですし、楽しみに見させていただきますので是非ご参加のほどよろしくお願いいたします。

12月にAdvent Calendarの開催を予定しています

2018-09-12T22:21:23+09:00

Advent Calendarとは、Web界隈では12/1～12/25まで毎日１記事ずつ記事を公開していくイベントです。Crieitでも開催してみたいと思います。

ご存知の方も多いとは思いますが、毎年QiitaやAdventarにて恒例で開催されており、たくさんの記事が集まり非常に盛り上がっています。どちらも毎年参加者もカレンダーも増えているようです。

Qiita Advent Calendar

Adventar

ちなみに元々の意味としてはクリスマスまでの日数を楽しみながら数えるためのもので、子ども向けに毎日一つずつお菓子が入ったセットなどもよく売られています。

仕様

大まかには

Qiitaのような機能を想定しています。

カレンダーは1つ

まだ開発者以外に記事を投稿してくださる方が多いわけではないため、カレンダーは１つ、計25日分の予定です。空いた日は全て開発者が埋める予定です。

ジャンルは問いません。練習でも議論でもポエムでもOKです。

一応11月になったら募集を開始してみるため、万が一埋まるようであればもう一つくらい増やすかもしれません。

余裕があれば実装する機能

大きなサービスであれば必要な機能だと思いますが、現状だとあまり必須という感じではなく、無くても運用できるため余力があれば作成する機能です。

予約投稿

事前に下書き状態でカレンダーに登録しておくと、予定した日になったタイミングで自動的に公開される機能です。

通知機能

Advent Calendar上で記事が公開されるとWeb Pushにて通知が行われる機能です。（通知を受け取りたい方はユーザー登録してPush通知を有効にしておく必要があります）

不要そうな機能

Qiitaと比べて、現状のCrieitだと不要そうな機能もあるためこのあたりは実装しないと思います。

フィード（トップページでまかなえる）
カレンダーの作成
ランキング

等

まとめ

このような形で開催していきたいと考えています。

今のところ全部埋まらない可能性も非常に高い（というか投稿が一切ない可能性もる）ため、空いた日は全て開発者が埋める予定です。開発者も普段からあれこれ開発したり記事を投稿したりする必要があるため恐らくAdvent Calendar用に記事をストックしておく余裕もなく、12月はデスマーチになる予定ですので、気が向いたら是非ご協力をお願いいたします！

Goのglide環境にてWerckerのCI導入

2017-12-23T06:27:15+09:00

Go3 Advent Calendar 2017 - Qiita

23日目

GoのアプリケーションのリポジトリをBitBucketに作っているので、WerckerでのCIを試した。

シンプルで綺麗なパスでアプリケーションを作っている場合、
多分Werckerにてアプリケーションを登録する際に表示されるサンプルそのままのwercker.ymlでそのまま動くのではないかと思う。

ただ、今回のアプリケーションはパッケージ管理にglideを使っているのでそのままでは動かない。
ちなみにフォルダ構成としては、下記に降りたところにアプリケーションが入ってる。

/src/myapp

Dockerコンテナ内では上記のルートをGOPATHとしている。ちょっと変な構成。

とりあえず動くところまでを調整してみた。
とりあえずなので変な感じになっている。

box: golang
build:
  steps:
    - setup-go-workspace

    - script:
        name: install glide
        code: |
          curl https://glide.sh/get | sh

    # Gets the dependencies
    - script:
        name: glide install
        cwd: src/crawler/
        code: |
          glide install

    # Build the project
    - script:
        name: go build
        cwd: src/crawler/
        code: |
          export GOPATH=/go/src/bitbucket.org/myaccount/myapp
          go build

    # Test the project
    - script:
        name: go test
        cwd: src/crawler/
        code: |
          export GOPATH=/go/src/bitbucket.org/myaccount/myapp
          go test $(glide novendor)

細かいところを補足していくと、まずglideのドキュメント通りにインストール

curl https://glide.sh/get | sh

最初に書いたとおりパスがちょっと違うので合わせる。

cwd: src/crawler/
code: |
  glide install

パッケージの位置がずれて読み込めていなかったので、exportでGOPATHを指定している。
（ymlの設定であるかも？）

プロジェクトの環境変数を設定すると今度はglideのインストールとかがうまくいかなくなるのでここで指定している。

cwd: src/crawler/
code: |
  export GOPATH=/go/src/bitbucket.org/myaccount/myapp
  go build

こんな感じで通った。

あとはパイプラインでデプロイの処理などと繋げれば楽だと思う。

Systemdを使ったPhoenixの本番デプロイ詳細例

2017-12-19T06:24:49+09:00

Elixir Advent Calendar 2017 - Qiita

19日目。

サーバーを準備し、コンテナを使わずに運用できるところまでの準備まで一通りまとめてみた。
Systemdで動作させる。

（以前残したログをまとめているだけなので正確でない可能性あり）

前提

Elixir1.5
Phoenix1.3
Debian

初期設定

最初だけ本番で調整したものをコミットしたりもするのでgitもちょっと設定。

sudo apt-get update
sudo apt-get install -y git dbus
sudo timedatectl set-timezone Asia/Tokyo
git config --global user.name "name"
git config --global user.email "email"

Elixir & Phoneix & Node.js

curl -sL https://deb.nodesource.com/setup_8.x | sudo -E bash -
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb && sudo dpkg -i erlang-solutions_1.0_all.deb
sudo apt-get update
sudo apt-get install -y nodejs inotify-tools esl-erlang elixir
mix local.hex --force
mix local.rebar --force
mix archive.install https://github.com/phoenixframework/archives/raw/master/phx_new.ez --force
sudo apt-get install --reinstall build-essential

DB

MySQLとかPostgreSQLとか。
普通は別サーバーだろうし省略。

ビルド

ssh-keygenかtokenかでcloneできるように準備。
適当なので環境変数とかユーザーは適宜いい感じにしてもらった方が良いかもしれない。

git clone ********.git
cd appdir
mix deps.get --only prod
sudo MIX_ENV=prod mix compile
cd assets
npm install
sudo npm install -g brunch
brunch build --production
cd ..
sudo MIX_ENV=prod mix phx.digest
sudo MIX_ENV=prod mix ecto.migrate
sudo MIX_ENV=prod mix phx.server

とりあえずここまでで動くか確認する。

Let's Encrypt

省略。下記の記事に一応詳細は書いてある。

PhoenixでLet's EncryptによるSSL - アルファブレンドプログラミングチップス

Systemd

sudo vi /etc/systemd/system/myapp.service

[Unit]
Description=My app

[Service]
WorkingDirectory=/home/username/appdir

Restart=always
Environment=MIX_ENV=prod HOME=/root
ExecStart=/usr/local/bin/mix phx.server

[Install]
WantedBy=multi-user.target

sudo systemctl enable cybozulive
sudo systemctl start cybozulive

運用

pull, compile, brunch build, digest, migrate, restart

個人開発のだいたいの流れの例

2017-12-05T07:03:13+09:00

個人開発 Advent Calendar 2017 - Qiita

の5日目。

概要

普段から時間があればプログラミングで遊びつつ何か作成している。
せっかくなので誰も使わなくてもリリースしたりしていて、
それらは特に仕事でやっているのとかけ離れているものではないので、
適当に箇条書き程度で紹介。

今作っているもの

ちょっと前にサイボウズLiveが終了すると発表された。
自分も丁度お客さんが使っていてそこでやり取りをしていた。
丁度Elixir & Phoenixを使って色々遊んでいたところに飛び込んできたニュースで、
丁度別のアプリケーションをキリのいいところまで作り終えたところだったので、
サイボウズLiveをコピーして作ってみようと思い作成中。

成果物は下記。

Copying live

ちなみに当ブログで連載中。

サイボウズLiveを作るカテゴリーの記事一覧 - アルファブレンドプログラミングチップス

進め方

とりあえずどんどん出来ていくのが楽しいので、細かいところは無視してどんどん自分のやりたいところを先に進める。
細かいところは後回し。
今もデータ登録が中心で削除等の細かい機能は放置している。

デザイン

デザイナーじゃないのでやっぱりBootstrap。
特に

Bootstrap

がおしゃれで何にでも使えるので良いと思う。
JavaScriptのフレームワーク毎にMaterial Desginのライブラリがあったりもするのでそういうのでもいい。

とりあえずの画面

掲示板

Todo

エディタ

Visual Studio Code

今のところ知っている中では軽量＆高機能＆設定手軽なものでベストだと思う。

開発環境

docker-composeを使う。Linux Mintなのでただインストールして使うだけ。

Elixir & Phoenixだと下記のような感じ。
見てのとおりだがPhoenix & MySQL & phpMyAdmin。
Phoenixのイメージは誰かがどこかで公開していたのを参考にしただけのもの。

version: '2'
volumes:
  mysql_data:
    driver: 'local'
services:
  mysql:
    image: mysql:8.0
    volumes:
      - mysql_data:/var/lib/mysql
    ports:
      - "3310:3306"
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: "true"

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    environment:
      - PMA_ARBITRARY=1
      - PMA_HOST=mysql
      - PMA_USER=root
      - PMA_PASSWORD=
    ports:
      - 8100:80

  cybozulive:
    image: dala00/phoenix:1.3.0
    env_file: .docker-env
    volumes:
      - .:/var/opt/app
    ports:
      - "4000:4000"
    tty: true
    stdin_open: true

ソース管理

自分の場合、ソースを公開していいならGitHubに置くし、
多少大きくてあまり公開したくないものはBitbucketに置いている。
(Bitbucket最近重い気がするけど)

フロント

Vueを使っている。
Phoenixは最初からbrunchが入っているのでVueを入れたらそのまま使える。
Phoenixの開発サーバーに元々ウォッチ機能がついていて、htmlもcssもJavaScriptも全部保存時に勝手に画面を更新してくれるので何も考える必要がない。
そのためjQueryを使う意味すら無いしもう全員Vueで良いと思う。
なにより簡単に適当に一部のみコンポーネント化できるのが最高。

PHPならLaravelも最初からVueが使える。
もしフレームワークに何もついてなくてもwebpack導入してwatchするだけなのでとりあえずもうVueを使っておけばいいと思う。

公開

せっかく作ったならぐちゃぐちゃでも公開していったらいいと思う。

僕の場合、PHPならさくらのスタンダードを１つ借りてるのでそちらにアップして公開する。
（バージョン上げると動かなくなるものも入っているのでもうひとつ借りたくなるところ…）

それ以外の場合、VPSとかでも１アプリケーションごとに500円とか千円とかかかってしまい、
積み重なっていくとモチベーションに影響してしまうので、最近だと全部GCEの無料のプラン。
Herokuでも良いかもしれないがどうもDBの接続が安定しないようなのでちょっと不安。

Phoenixのデプロイ方法はAdvent Calendarの別の記事で紹介する予定。

あとSSLは例えしょうもないアプリでももう必須だと思う。
焦らずにリリース前の、失敗してサーバーをぐちゃぐちゃにしても問題ないタイミングでちゃんと設定しておきたい。

会話のかみ合わないチャットボットを作った

2016-12-23T07:11:56+09:00

はじめに

チャットボット Advent Calendar 2016 - Qiita

21日目

チャットボット

適当にチャットボットを作ってみた。
本当は作るのが面倒だったので適当なAPI等は無いかと思ったが、
どうも登録に時間がかかったり費用がかかったり、
会話の流れを自分で登録していかなければならないものなどばかりだったため、
適当に作ってみることにした。

アルゴリズム

調べてみると下記のようなページがあった。

マルコフモデルを使った人工無能の作り方 - Hacking My Way ～ itogのhack日記

マルコフモデルというのを使うと会話が自動で生成できるらしく、
見て見る限り適当にデータをMySQLに保存していけばできそうだったのでこれでやってみることにした。
最近はやりの機械学習ライブラリなどは使っていない。

学習プログラムはpythonで作った。
そのうちTensorFlowなどを使う場合があればpythonがいいかと思ったが、
別に今回は小さなプログラムだったので結局何でも良かった。

学習

適当な会話データなどを拾って学習させてみた。
サーバーだとお金がかかるのでとりあえずある程度はPC上でDBに貯めこむ。
100ちょっとのファイルの会話データで、PCつけっぱなしで１週間ほどかかった。
HDDの寿命がだいぶ縮まったのではないだろうか…。

チャットアプリケーション

CakePHP3とAngularで作成した。
返事はpythonで作っていたのでコマンドを呼び出して連携している。

AiChatFront

LINE ボット

Message APIをつかってLINEボットも作ってみた。

Androidアプリ

CordovaでAndroidアプリも作ってみた。
ちなみにAndroidアプリの場合はボットが音声で話すので注意。
自分も声で話すことができる。

まとめ

やってみたが話はかみ合わない。
たまにドキッとする発言をするが。
もうちょっと調整や学習を増やせばもうちょっとまともになるかもしれない。

cakephp/migrationsにプルリクエストを送った

2016-12-22T05:55:55+09:00

はじめに

CakePHP3 Advent Calendar 2016 - Qiita

20日目が空いていたので。

内容

CakePHP3のマイグレーションにはmigration_diffという機能があり、
差分から自動的にマイグレーションファイルを作ってくれる超便利な機能がある。

ただ１点、
afterオプションだけ自動的につけてくれない、
という仕様だったのがずっと気になっていた。

気になってソースを調べてみると、
なんとなく可能なんじゃないか、という感じに見えた。
でも付けられていないということは何か理由でもあるのだろうか？

と思いつつ対応してみたら簡単にafterをつけることができた。
せっかくなのでテストも作成し、issueでPRしていいか聞いてみたところOKが出たのでPR。
Milestoneにも入ったので問題なければ恐らくマージされるのではないかと思う。

Add 'after' attribute to migration_diff by dala00 · Pull Request #281 · cakephp/migrations · GitHub

ちなみにafterが無いのは特に理由はなくまだだれも対応していなかっただけだった。

テスト方法

migration_diffのテストは、実行後git statusしてみるとだいたい分かるが、
マイグレーションファイルが作成され、それを想定される出力結果ファイルと比較する、というもの。
MySQLやPostgresでファイルが分かれているのでそれぞれテストして出力結果ファイルを修正する。

そのあたりをきちっとやったら後は環境依存のエラーやよくわからないものが出るので、
forkしたリポジトリをTravis CIでチェックして本家と同じ感じになればOKだと思われる。
PRした時も同様のチェックが自動的に行われる。

まとめ

せっかくのオープンソースなので気になったり不足を感じる点があったら是非PRしてみた方が良い。
あとはマージされることを祈るばかり。

ちなみに仕事場ではもう勝手に修正をあてている。
もしマージされなかったら永久に自分で修正し続けるしかない。

追記)マージされました。

Atomのパッケージにpull requestを送った話

2016-12-16T09:01:13+09:00

はじめに

Atom Advent Calendar 2016 - Qiita

16日目

Atomについて

Atomはご存知の通りGithubでも公開されているオープンソースのエディタで、
連携するパッケージも全て同様。

つまり、何か不便を感じた時、通常のアプリケーションのように要望を出してそれが通ったものがリリースされるまで待つ、
等ということをする必要がない。
自分で改造すればいい。

せっかく改造したなら、pull requestを送ってみるのが良いと思う。
受け入れて貰えれば今後のアップデートで反映される。

２回ほどpull requestを送ったのでその時の話。
どちらも小さなプロジェクトだったのでテストも書かず、すんなりと受け入れてもらえた。

remote-ftp

GitHub - icetee/remote-ftp: FTP/FTPS/SFTP client for Atom.io

Atom上でSCPでファイル転送できるパッケージ。

ローカルでファイルを編集して保存した時、自動的にアップロードしてくれる機能があるので使っていた。

しかし、その用途のみの利用だとリモートのツリービューが邪魔なので、デフォルトで非表示にできないか試したところ、できた。
ただ、アップデートがくると修正した箇所も消えてしまうので、
せっかくだからpull requestしてみようと思いデフォルトで非表示にするかどうかの設定をつけて、
既存のユーザーに影響が無いようにして送ってみたところマージしてもらえた。

Merge pull request #236 from dala00/showViewOnStartup · icetee/remote-ftp@b691126 · GitHub

symbols-tree-view

GitHub - xndcn/symbols-tree-view: A symbols view like taglist for Atom.io

ソース中の関数などの一覧が表示され、クリックですぐその位置に飛べる便利なパッケージ。

便利なのだが、当初はファイルを開く度にソート順を変更せねばならず、
なんとなく微妙に面倒というか使いづらいという感じだった。
何でもいいから強制的に名前順にソートできないか？　と思い試したところ、できた。

せっかくだからこれもpull requestしてみようと思い、
強制的に名前順にする処理を、現在のコードの種類で設定できるようにして、
既存のユーザーに影響が無いようにして送ってみたところマージしてもらえた。

Merge pull request #82 from dala00/sortByNameScopes · xndcn/symbols-tree-view@e71d465 · GitHub

まとめ

このように自分で拡張していけるのでとても面白い。
一度やってみると今度はもっと別のプロジェクトなどにも貢献してみたくなるので趣味の幅が広がるだろう。

ちなみにどちらも不具合というか不足点があったので修正のプルリクエストをしている。

在宅エンジニアと子育て

2016-12-10T09:01:47+09:00

はじめに

子育てエンジニア Advent Calendar 2016 - Qiita

10日目。

年表

2012年　長男誕生。週５在宅。
2014年　次男誕生。
2016年　常駐週３、在宅週２（現在）

長男が生まれてからやるようになったこと

洗濯もの干し、取り込んで片付け(毎日)
子どもをお風呂に入れる(毎日)
子どもの朝ごはん(週3,4)
子どもの口にご飯を運ぶ(休みの日)
子どもを夕方散歩に連れて行く(毎日)
子どもと遊ぶ(土日)
土日や深夜に急に病院に行く機会が増える
その他細かいこと色々
里帰りの間から１年ほどネトゲにハマってしまう

その結果＆考察

子どもはお父さん大好きになった。
子どもの細かい成長をたくさん見ることができた。
授乳等、母親にしかできないことがあるため、できることの限界を感じた。
妻は24時間休みがなくなるということを忘れてはいけない。
男だけ土日はゆっくり休みを取るとか子どもみたいなことは言わないこと。
自分でできることを探す。
仕事は子どもや妻の都合に関係なくちゃんと時間やスケジュールを決めてやる。
ネトゲやスマホゲーなど、物事にずっぽりハマってしまう経験は出産前に終わらせておいたほうがいい。妻に迷惑かけすぎ。

次男出産時

近くに親類もいないので長男はその期間前後の数カ月だけ保育園に入れた(月5万程)
出産直前、長男がインフルエンザ、水疱瘡、それに伴う中耳炎で高熱（熱性けいれん持ち）
保育園はもちろん行けないので一番重要なところで無意味に。
その１週間ほどは地獄で仕事も１日１時間出来たらいいくらいだった。
妻は病院に許可をもらい長めに入院させてもらった。面会ゼロ。
水疱瘡がヤバイので荷物も病院の前に置いといて回収してもらう形。

次男が生まれてから変わったこと

次男出産時にこの世の地獄を見たので、あれに近いことを日常的に妻に味合わせるのは危険という感情が芽生えた。

・子どもの朝ごはん(毎日)。
元々2時くらいに寝て（ご飯担当でない時は)10時くらいに起きる生活だったが、
妻が授乳しながら長男にご飯をあげるのは地獄だと思うので毎日5〜7時くらいに起きて長男にご飯を上げることに。
体が勝手に11時くらいに寝るようになる。大体7時間睡眠という一番長生きできる時間に変わる。
今もずっと二人にご飯をあげて朝の準備をさせている。

不思議なことに目覚めは良くなり、朝だらだら寝てることはなくなった。
妻が言うにはずっとうるさかったいびきもほとんどなくなったらしい。

仕事＆子育てで休みがないということが当たり前になった。苦もない。
ろくでもない生活をしてろくでもない育ち方をして将来子ども達にハンデを背負わしてしまったり、
子ども達が他者にとんでもない迷惑をかけることになる可能性を考えたら、
今一生懸命子育てをすることはとてもやりがいのあることだし、自分の命を削ってでもやる価値のあること。

在宅エンジニアのメリット

妻は子どもを家に置いて外へ行ける。（病院、美容院、ちょっとした買い物や休憩など）
妻は子ども一人だけ連れて外へ行ける。（子どもの病院、発達検査、色々な手続き、幼稚園や習い事の集まり）

↑夫が出勤して働いている核家族の妻は必ず子ども全員を連れて行かないと行けないので毎日死ぬほど大変。
腰が悪くてもおんぶだっこしなきゃいけない時もあるし、高熱が出てても休めない時だってある。

幼稚園のバスの送り迎え位ならいけるので、妻に用事があっても幼稚園へ行かせられる。

まとめ

エンジニアはリモート作業も可能なため在宅で仕事がやりやすい。
でも他業種はそうとは言えない。
親二人だけだと結構詰む事も多い。

色々な会社でリモートワークが可能になっているニュースを見かけるが、どんどん増えて欲しいと切実に思う。
また、困った時に頼れる行政上のサービス等ももっと必要。
親たちは本当に大変な思いをしながら生活している。

おまけ

どうでもいい話だが、ちょうどBOT API Trial Accountがあった時期だったので次男の写真を設定し、
Androidのアプリ上の大きいボタンをタップすると「ごはんがほしい」「本読んでほしい」
などといったメッセージが自分のLINEに飛んでくるというボットを作った。

Arduinoと安く買えるようになったWifiモジュールを使って、現実のボタンからも送信できる回路とプログラムも作ったのだが、
最後の調整や妻のLINEに仕込もうと様子を伺ったりしていたところでTrial Accountが終了し無料では送信できなくなった。

終わり。

jQueryによるコンポーネント化考察

2016-12-04T09:01:10+09:00

はじめに

JavaScript Advent Calendar 2016 - Qiita

4日目

注) SPAの話ではありません。

なぜjQueryを使うのか

今の時代、JavaScriptはAngular2やReactに代表されるコンポーネント指向の時代を迎えている。
そんな中でなぜjQueryを使うのか。
下記の条件が組み合わさっている場合にはjQueryの方が使いやすい。

JavaScriptが必要な箇所が少ない

SPAでJavaScriptをメインで使う場合はjQuery等今更使うことは無いと思うが、
ほとんどサーバーでレンダリングされるhtmlで完結しているシステムに、
時々動きを加えたい、なんて時はいちいちNodeの環境を準備、周知し、
ビルドしつつ開発する方が面倒。

開発陣が入れ替わる

ずっと同じリーダーが開発の深い部分まで指揮していない場合もある。
そういった場合はメインのエンジニアも入れ替わるし、
その場その場で違う人がコードを書く。
サーバー側のフレームワークは定まっていることが多いが、
JavaScript側は特に指定されていなければjQueryが使われることは多いと思う。

サーバー側のフレームワークが優秀

なんだかんだで世の中のサーバー側のフレームワークは優秀で、うまく使っていると開発は非常に楽。
それをわざわざAngular2やReactに置き換える場合、連携のためのコードを書いたり、
サーバー側フレームワークと同等の機能をJavaScriptで書きなおしたりなどの作業が必要となり、
逆に面倒になる。

なんとかやったとしても、今度はJavaScript側のサーバーサイドレンダリングが必要なんじゃないか、
という考えに至り、じゃあNode側のサーバーの処理も作らないと、でもそこまでやるのはなあ…
となっていき結局jQueryに落ち着く。

でもコンポーネント化したい

でもはやり最新の考え方を導入していきたい。ではそういった状況下において、jQueryでコンポーネント化し、Fluxの思想を取り入れるためにはどうすればいいのか、考察してみる。

プラグイン化

なるべく処理はプラグイン化し、至るところで再利用できるようにする。

データの流れを１方向にする

JavaScriptの開発でDOMやデータが現状どうなっているか分からなくなり不具合の温床となる、
ということがFluxの思想が生まれたベースとなった話だったと記憶している。

jQueryを使用しているとそういうことが起こりやすいのだろうが、それは適当に開発しているからだ。
きっちり考えてやればそうはなりにくくすることはできると思う。
（もちろんjQueryだからきっちりしない選択もできるので、それをするエンジニアがプロジェクト内に出てきてしまう、
というのが本質的な問題かもしれないが）

とりあえず、諸々の処理ですぐにDOMを操作せず、
「処理→最後にrender」というのを一貫すればいい。

例えば下記はjQueryプラグインのfullcalendarのソースの一部。

見ての通り中でCalendarクラスのインスタンスを作成し、最後にrenderしている。
初期化だけでなく基本的には全ての処理がこれになっている。

つまり描画されるDOMは必ずインスタンスのプロパティ通りになる。
これにより１方向の流れの基礎が出来上がる。

クラスを分ける

プラグインが大きくなるなら描画部分ごとのパーツでクラスを分ける。
パーツはなるべく親の値を参照するのみにし、
重要な値の変更が必要な場合はパーツ内ではなく大元のクラスの値変更＋再描画を徹底すれば完全にFluxだ。

htmlは変数に結合しまくりなのでやりにくいのは否定しないが、
ちゃんと処理やパーツを分ければさほど見にくくなることもない。

自動起動

jQueryプラグインはscriptタグで読み込んで、ページ内で初期化メソッドを呼び出す、という流れが多いと思うが、
BootstrapのJSのように勝手に動作してくれる方が楽だと思うし最近のコンポーネントぽいので、
そのようにしてみる。

下記の一番下にプラグインの雛形がある。

jquery プラグイン/作成

このmethodsの上に初期化スクリプトを入れてしまう。

$(function() {
  var targets = $('[data-tooltip]');
  if (targets.length > 0) {
    targets.tooltip();
  }
});

これでいちいち初期化を書かなくても全部自動起動される。
クラス名はデザイナーがいつの間にか変えている場合もあるのでdata属性がいいと思う。

初期化設定

これじゃあパーツ毎に設定ができないじゃないか、と思うかもしれないが設定もdata属性にしてしまえばいいだけ。
プラグイン側で初期化時に値をそこから読めばいい。
さっきのfullcalendarの例で言うとnew Calendarの中でやればいい。

項目名

まとめ

長々と書いたが、これくらいなら普通に開発するのとほとんど労力は変わらないと思う。

jQueryを使うデメリットは他にもある、という人もいると思うしやり方に好き嫌いはあると思うので、
ひとまずより良い方法、というよりは考察とさせていただく。

逆に言うと、まるまるAngular2やReactなどに置き換えるのではなく、
こういった手法を簡単に安全に確実に実現できる良いjQueryのラッパーライブラリなどが登場するといいのではと思う。