休憩時間やパーティで、他の参加者の方とコミュニケーションを取ることもtry! Swiftでは推奨されてました。僕は結構こういう場で話すのが苦手で技術的なコンプレックスもあってあまり話せなかったのが残念でした。結構先輩の社会人の方から色々とお話を聞かせていただくだけになってしまったので、次回は自分にしかない経験をたっぷりと用意して行きたいですね。

ワークショップは手厚くサポートしてくれる

ワークショップもありました。僕はServer Side Swiftのハンズオンコースだったんですが、いい感じにハンズオンを区切ってくれて質問がしやすい環境で、そのテーマに詳しくない人でも問題なくついていけるようになっていました。

ハンズオン資料

github.com

意外とガチ勢ばかりではない

意外とSwift歴1年程度(僕があった人はほぼ業務で触ってましたが)の方も多く、雑談の際の話が合わないというレベルではなかったように思います。（そもそも技術的な話というよりは、作っているものの内容やどんな開発体制をとっているか（何言語か、どんなチームかなど）という話が多かったです）

みなさんもぜひtry!してみては

はじめてのカンファレンスで結構反省すべきところも多かったですが、参加して良かったと思える素晴らしいカンファレンスでした！

少しでも興味のある方はぜひ参加してみてはいかがでしょうか。

2019-02-26

Djangoのfunction based viewとclass based viewの違い・メリット・デメリットを調べた

DjangoにはRailsなどと異なり、class based viewとfunction based viewという概念があります。MTVで言う所のView、MVCでいうところのControllerにあたる所のメソッドの定義の仕方に２通りメジャーなやり方があるという感じになっています。

調べてみた

この記事が詳しかったです

simpleisbetterthancomplex.com

以下、上の記事で挙げられていた中で自分が大事だなと思った違い（メリット）をあげます。もっと知りたい人は上の記事を参照してください。

class based viewの主なメリット

継承が使える
- コードが少なくなる
- 一覧などのテンプレコードを使い回すこと（再利用）ができる
HTTPのメソッドがそのままクラスのメソッドになり 、わかりやすい

class based viewの主なデメリット

コードが読みづらい
デコレータが使いづらい
継承やmixinが複雑になることがある

function based viewの主なメリット

実装がシンプルで、読みやすい
関数なので、デコレータが使いやすい

function based viewの主なデメリット

再利用しづらい
GET, POSTなどを関数内で分岐させないといけない

思ったこと

function based viewの実装がシンプルで読みやすいというのがいまいちわからなかったです。シンプルなのは確かに基本的に一つの関数だけで完結するため（内部で別の関数を呼ぶことはもちろんあるが）ということかもしれないが、読みやすいというのはどうなんだろう。クラスを使わない分、メンバを気にする必要がなく、関数の中にある変数だけを気にすればいいため、コードを読むとき目を比較的上下させなくていいことや、必然的に継承ではなく委譲を使うことになるためだろうか。

ちなみに、フロントエンドを描きやすくするためにReactやVue、Angularなどを使ってバックエンドはAPIにするという形をとるのが主流な現在では、RESTに則ってGET, POST, PUT, DELETEを活用するため、それらをクラスのメソッドとして実装できるclass based viewが優勢なのかもしれません。

多分今後APIを作るときは、class based viewを使うと思います。

今後に活かしたい

DjangoはDRYの原則に乗っ取ったつくりになっていることを考えると、class based viewの方がいいのかもしれません。いままでなんとなくfunction based viewを使っていましたが、メリットを活かして書いていけるよう意識していこうと思います。

2019-02-17

IdeaVimで :w で保存してもhot reloadが効かない（Flutter on Android Studio）

環境

macOS 10.14.3
Android Studio 3.3.1
IdeaVim

対策

慌てずに ctrl + s ならhot reload効くのでとりあえずそれで我慢しましょう。

2019-02-10

初めてのOSSへのプルリクエスト（ドキュメント編）

今回プルリクを送ったリポジトリ

github.com

Djangoで作られたECサイトのプロジェクトです。このサイトで実際に運用されています。http://getsaleor.com

なぜこのリポジトリを選んだか

単純に自分が結構参考にしていたリポジトリだったからです。現状バイト等でも綺麗なコードを読む機会があまりなかったので、大きめのOSSのコードリーディングをやってみたいと思ったのが始まりです。

なぜプルリクを送ろうと思ったか

どうせならコードリーディングだけじゃなくてコントリビューションもやりたいと思い、何気なくcontribution guideを読んでいたところ、typoに気づきました。 typoに気づいたら、これはコントリビューションチャンス！ということでプルリクを送ろうと決めました。

プルリクを送ると決めてから調べたこと

コントリビューションガイド

READMEから見つけた。以下のことについて注意して読んだ。

issueを立てるべきか
- issue文のテンプレはあるか？
pull request文のテンプレはあるか？
テストについて

読んだ感じだと、どうやら特にやれることはなさそうだった。（今回はドキュメントのfixなので特にテストする必要もなく、CIに任せることにした）

マージされた似たようなプルリクを調べる

Githubの左上の検索ボックスから、「Fix typo」と検索

以下のような似たようなプルリクが見つかった。

https://github.com/mirumee/saleor/pull/3100

forkする

今回、実は先にリポジトリをクローンしてpushしてみたが、pushがリジェクトされてしまった。ブランチ名を見ると、tetsufe:fix-type のようにコロンで区切られていた。 forkすると、こんな感じで表示されるらしかった。そういうわけでforkしてからプルリクを送ることにした。

forkからpull requestの送り方は以下を参考にした。

qiita.com

ブランチ名

マージされた似たようなプルリクを調べる https://github.com/mirumee/saleor/pull/3100

タイトル
issueを立てるべきかどうか

修正する

ドキュメントを修正します。今回はPotsgreSQLと書かれていたのをPostgreSQLに直しました。これだけです。笑

一応、プロジェクト全体を検索し、ここしかその間違いがないことも確認しました。

コミットメッセージ

コミットメッセージは特殊である必要はないらしかったので適当に"Fix typo in docs about search" としました。英弱ですね。

プルリクの作成

pull requestをリンクから作成するとテンプレが自動生成される。しかもfork元に自動的にプルリクが作成される楽々仕様でした

$ git push
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 12 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 436 bytes | 436.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote: 
remote: Create a pull request for 'fix-typo' on GitHub by visiting:
remote:      https://github.com/TetsuFe/saleor/pull/new/fix-typo
remote: 
To github.com:TetsuFe/saleor.git
 * [new branch]          fix-typo -> fix-typo

この https://github.com/TetsuFe/saleor/pull/new/fix-typo リンクから行くと、勝手にプルリクのテンプレが入力された状態でフォームが出てきました。

f:id:swiftfe:20190210202158p:plain

プルリクのタイトル

コミットメッセージと同じでもOKらしかったので、そうしました。

プルリクの本文

I want to merge this change because... のプルリクのテンプレに従って、

I want to merge this change because potsgreSQL is wrong, postgreSQL is correct.

と書いた。意味はわかるはず。

完成！

github.com

プルリクを作成すると、CIが回り、そして終わります。この辺はさすが質の良いオープンソースプロジェクト感があります！

f:id:swiftfe:20190210202310p:plain

迷ったところ

pull requestのテンプレが見つからない（あとでわかったが、forkしてpushした時にコンソールに出てくるリンクからプルリクを作ろうとすると自動的にテンプレ文が入力された状態で始まる仕様らしかった。）

後日、マージされました！

github.com

メンテナの方からも感謝の言葉をいただき、割とテンション上がりました。笑

今度はコードでコントリビュートしたいですね！

皆さんも簡単なところからOSSへのプルリクエストを送ってみてはいかがでしょうか？

2019-01-11

個人開発サービス「ホクマ」のコンセプトを再考する

ホクマ

「ホクマ」とは

2018年10月にリリースした、北大生限定のフリマサービスです。(でした)

http://swiftfe0.hatenablog.com/entry/2018/10/06/094817

商品の出品
購入
チャット
商品・金銭の受け渡しはあって直接

元々のコンセプト

リリース当時は以下のコンセプトを念頭において作っていました。

北大生限定のサービス
- 他のフリマサービスよりも安心して利用できると考えている(同じ大学の学生との取引なので、相手の素性が分かっている)
- 北大生限定という「北大愛」を持って利用してもらえる
フリマサービス
- 大学生の要らなくなった教科書をより多くのお金に換えられる
  - 教科書などは使わなくなるが、古本屋などで売ると大したお金にならない
  - フリマサービスで売った方が高く売れる
- お金のない学生は安く教科書などを買える

数ヶ月経った後の変化

運用を続ける上で考えの変化や気づきもありました。

「会って渡す」ことによる出会いが何かを生むのではないか
- 実際に開発者の自分も利用することで良い出会いがあった
- せっかく北大生限定のサービスとしてユーザを集めたので、他にも「出会い」を中心としたローカルサービスとして発展させられないか(「ジモティー」の成功例もある)
  - 元々、フリマサービスだけでは売るもの・買うものがなくなった人は利用しなくなってしまうことが多い
    - 特に教科書を買うシーズン以外は使われないのではないか
    - 「出会い」は、買い物よりも希少性が高く、このサイトを使う価値となるのではないか
    - 「出会い」は定期的に欲しくなるものではないか
      - 新しい趣味の友達がほしい(趣味が変わる、増える度に欲しくなる)
      - 何度か段階的にチームに人数を増やしたい
      - 面白い人がいたら会いたくなる

今後の「ホクマ」のコンセプト

そんなことを考えた結果、

「ホクマ」を「北大生のためのフリマサービス」から、「北大生が欲しいものを手に入れられるサービス」へと発展させていこうと考えています。

今後は

フリマ
仲間の募集

この二つを軸にした機能を展開し、「モノ」「お金」のやりとりだけでなく、「仲間」を見つける手助けをしていきたいと考えています。北大生同士なので、「身近な出会い」も魅力として推していきたいです。

もちろん、僕自身も「ホクマ」を通じて色々なチャンスを掴んでいけたらと考えています。笑

2019-01-01

フリマサイト「ホクマ」の類似サービス、「ジモティー」の簡単な分析をしてみました

ホクマ

「ホクマ」に新機能を追加したい

北大生限定Webフリマアプリ「ホクマ」では、サイト上で「出品」と「購入」ができるというサービスを提供しています。

hufurima.com

最近、「出会い」要素をもうちょっと追加したいという考えになり、どのようにそれを落としこもうか考えて、Twitterでアンケートをとったりしていました。

WHY: なぜ「出会い」要素を追加したいのか

個人的に、「出会い」を増やしたい（ほどほどに）
アンケートをした結果、「一緒に勉強する友達」を募集する機能などは需要があるらしい
シーズン通して使われる機能がほしい（「出会い」はシーズンに左右されにくい）
- 現状、「出品」・「購入」の機能だけで、新しい学期からまだ遠いため、教科書などのやりとりも少ない
- 新学期には取引の活発化が予測されるが、新学期シーズンが終わればせっかく登録してくれたユーザが離脱してしまうだろう

でもどうするのが正解だろうか？

「出会い」（マッチング）を実現するために、どんな機能を作ればいいのか？はわからなかった。

「一緒に勉強する友達」のように絞ってしまう方が良いのか？
「友達募集」のように広く使いやすい方が良いのか？

そこで、類似サービスである「ジモティー」を見て参考にすることにした。

ジモティーの場合、同じCtoCのサイトではあるけど、商品の売り買いだけじゃなくて、もっと他のこともできる。

例えば、「譲って・助けて」っていうカテゴリーがあって、「英会話を教えてください」みたいな募集から、「旅行に行くからおすすめの場所教えて」とかまである https://jmty.jp/hokkaido/coop-les

ジモティーでは、「募集」に以下の大カテゴリがある。

売ります・あげます
中古車
里親募集
メンバー募集
譲って・助けて
アルバイト
正社員
教室・スクール
不動産
イベント
地元のお店

「出会い」っていうコンセプトで行くと、

イベント
メンバー募集
譲って・助けて

あたりが該当する

イベントに関しては、ジモティーでもfacebookと同時投稿している人が多いようだし、あまり需要はないかもしれない https://jmty.jp/hokkaido/eve-fes/article-bo0gt

「メンバー募集」はどうなんだろう。

ジモティーでは、「メンバー募集」の中に「友達」っていうサブカテゴリがあって、「ラーメン友達募集」 https://jmty.jp/shizuoka/com-fri/article-bo8kw とか今からのみませんか！ https://jmty.jp/tokyo/com-fri/article-bo8ki とかの投稿がある

「友達」以外にも、「バンド」とか「スポーツ」とかがある社会人のサークル設立とか、そういう需要があるらしい。 https://jmty.jp/hokkaido/com-spo/article-bl956

「ホクマ」を見てくれる人がどれくらいいるかはわからんけど、こういった「サークルメンバー募集」とかを掲示しとくのはありなんかも。（まあツイッターとかホームページとかあるから微妙なところではある）

結論

ホクマでやるなら、以下のあたりで大雑把にやる方がいいように思った。

「oo友達募集」
「教えて・知りたい」
「イベント」
「買わせて・譲って」

理由

「ジモティー」がこんなアバウトなカテゴリわけでも一定のユーザ数（北海道でもだいたいどのサブカテゴリでも1日1募集くらいはあった）を保っていること
「ホクマ」は実験的サービスなので、まずは自由な使い方をしてもらった方が思わぬ使い方に気づかせてくれるかもしれない
上記のカテゴリなら北大生にも需要がありそう

その他、気づいたこと

それと、他に気づいたジモティーの面白いところとしては、いろんなカテゴリで投稿（投稿というのは上の https://jmty.jp/hokkaido/com-spo/article-bl956 のようなもの）ができるけど、そのフォーマットは同じということ。

つまり、「友達募集」カテゴリのフォーマットも、「売ります」のフォーマットも全く同じだということ。これがUI/UX的にいいのかはわからないけど、ある程度利用者がいるということを見ると、色んなカテゴリがあってもその投稿フォーマットは同じで問題ない、あるいはその方がむしろ見やすい/使いやすい可能性があるということ

14章 継承と委譲 template method と strategy の違い

初めてのプログラミング系カンファレンス参加

Swiftのマニアックで深い議論

デザイン(UI・アプリケーション設計)の話も多い

開発者としての価値観やマインドについての話も

休憩時間やパーティーでお話ししたり

ワークショップは手厚くサポートしてくれる

意外とガチ勢ばかりではない

みなさんもぜひtry!してみては

調べてみた

class based viewの主なメリット

class based viewの主なデメリット

function based viewの主なメリット

function based viewの主なデメリット

思ったこと

今後に活かしたい

環境

対策

初めてのOSSへのプルリクエスト（ドキュメント編）

今回プルリクを送ったリポジトリ

なぜこのリポジトリを選んだか

なぜプルリクを送ろうと思ったか

プルリクを送ると決めてから調べたこと

コントリビューションガイド

マージされた似たようなプルリクを調べる

forkする

ブランチ名

修正する

コミットメッセージ

プルリクの作成

プルリクのタイトル

プルリクの本文

完成！

迷ったところ

後日、マージされました！

「ホクマ」とは

元々のコンセプト

数ヶ月経った後の変化

今後の「ホクマ」のコンセプト

「ホクマ」に新機能を追加したい

WHY: なぜ「出会い」要素を追加したいのか

でもどうするのが正解だろうか？

結論

理由

その他、気づいたこと

14章継承と委譲 template method と strategy の違い