くうと徒然なるままに

モバイルアプリを作りながらバックエンドも作っています。

Firebase SDK on Nodejs で Firebase App named '[DEFAULT]' already exists (app/duplicate-app).' ってでた。

Firebase SDK を利用して Nodejs で適当なアプリを書いてたら以下のようなエラーが出ました。

エラーメッセージ

Exception: Worker was unable to load function uploadMeetupListToFirebase: '[DEFAULT]: Firebase: Firebase App named '[DEFAULT]' already exists (app/duplicate-app).'

解決方法

Firebase を初期化するコードを複数回読んでるのが問題らしいです。

firebase.initializeApp(firebaseConfig)

ので、シングルトン的な感じでFirebase クライアントを使いまわすことで解決。

#エンジニア女子だけどフォロワー伸びてない ってタグで一番バズったツイートをした

8RT, 40 Fav でタグの中では一番バズってる

f:id:kuxumarin:20181004013118p:plain

要因

猫パワー

新しいアイコンに変えた, Twitter, Slack, Line とかに使う

某社のずんださんに新しいアイコンを書いてもらいました。

流れ

ずんださんがやるぞ宣言で おえかき宣言 をしていました。

私は、便乗して マグロの中とろ を書いてもらいました。

文句言いながら書いてくれるずんだプロ最高✨

書いてもらった

プロフにした

f:id:kuxumarin:20181003164834j:plain

まとめ

Thank you for Zunda-san!!

ハッカソンって何??実体験も交えて書くよ!

同じ大学の友人にハッカソンについて説明する機会があったのでネットの海にも放流します。

誰?ハッカソンの参加歴は?

今までで合計6個ぐらいのハッカソンに参加しました。
そんなに多いわけではないので間違っている部分があると思います。指摘してください。

ハッカソンの定義をWikipedia から引用してみる

ハッカソン(英語: hackathon 、別名:hack day ,hackfest ,codefest )とはソフトウェア開発分野のプログラマやグラフィックデザイナー、ユーザインタフェース設計者、プロジェクトマネージャらが集中的に作業をするソフトウェア関連プロジェクトのイベントである。

ちょっとお堅い文章なのでまとめると

数日間~数週間集中して開発を行うイベント

ハッカソンでやること

全てのパターンでやることを書くと文章量が爆発するため、一部にしぼって書きます。

今回説明するモデルケースの前提とか

  • 土日開催
  • 技術者向けハッカソン
  • 企業が主体となりスポンサー企業が複数社付いている

1日目

1日目はチーム作りとアイディアソン

ある意味一番重要なところチーム作りでミスったりアイディアの合意が取れてなかったりすると色々大変な目に...

作業スピードが早いチームは午前中にすでに開発に取り掛かるところも。

チームによっては徹夜で作業を進めていくところも...!

個人的には徹夜で作業をする必要になるのは作業量か効率のどちらかの見積もりを間違えたのかなーとか思ってます。 効率が落ちるので徹夜厳禁. 絶対に嫌だ。

2日目

開発本番の日、とはいえども新規機能の実装などは前日までに終了しているのが理想的。みたいな。

午後から発表があったりする。

デザイナーのいるチームのプレゼン資料は異様に綺麗。

ハッカソンに参加することで得ることができるもの

  • 成果物
  • チームでやり遂げた充実感・肯定感
  • 短い時間の中で何をして何を切り捨てるべきかの判断

成果物、特にチーム開発が少ない学生のうちなら参加しとくと就活でのネタになるかなとも。

一番最後の奴は特に重要だと思っていて、ハッカソンに参加する人でたまによくいるのが「すごく壮大なものを作ろうとして結局何作りたいのかよくわからない割に、チームの人は徹夜明けみたいに大変そう」みたいな悲しいパターンです。

個人的な感想では、いい感じなMVPを定義したりとか、技術的な方面での解決だとRails とかのフルスタックフレームワークを使わずに AWS Lamda みたいな Serverless technology を駆使していかに早く作り上げる方向に持ってくかとかの工夫をすることで低コストである程度のものを作れるかなと思ってます。

とはいえども、自分もハッカソンに出たのは数回しかないので何を得れるのかとかはあまりよくわかってない領域です...

ハッカソンが開催される目的

色々あります。その中から一部だけご紹介

  • 地域・特定の会社の製品のため
  • IT企業が採用目的で
  • 単純にハッカソンが好きなので開催した

一番下が理想かなとは思います。けど、(観測範囲内では)一番上もかなりの数開催されている印象です。

地域・特定の会社の製品のため

一番よく行われるタイプのハッカソンだと個人的には感じてます。

企業がスポンサーについてるやつは技術者の人が応援に来てたりいろいろ環境が良いのでかなりおすすめ。

例えば、こんなのとか

www.shibuyaku-hack.tech

hackth.line.me

IT企業が採用目的で

こちらも割と見かけます。

こちらが何をできるかを面接とか以外の部分でアピールできるのでいいかも。

goodfind.jp

prtimes.co.jp

単純にハッカソンが好きなので開催した

周りのすごい人が主催してる奴ですが宇宙がめちゃ好きだから開催した感があります。

tokyo.spaceappschallenge.org

ハッカソンの期間

期間は2種類ぐらいにまとめられます。

  • 土日祝などの数日かけるタイプ
  • 長期間かけるタイプ

土日祝などの数日かけるタイプ

こちらが主流です。

土日などの休日にハッカソンを行う。社会人や学生などの平日忙しい人種でも気軽に参加できる感じの。

長期間かけるタイプ

名古屋ハッカソン豊橋三大学ハッカソンのように1ヶ月とか半年とか長期間開催されるタイプです。

こちらのタイプはあまり参加したことがないのでよくわからないのが正直なところ

とはいえ、数日では成し遂げれないこともできるかなと思います。

ハッカソンの参加者

ハッカソン、参加者層がそれぞれでかなり違います。そこに注意しないと色々不幸が起きるかも...

例えば、

  • 新しい刺激が欲しくて参加してるのに技術しかやれなかったりとか...
  • ガチエンジニアリングしに来てるのに非技術者ばかりのイベントに来てしまうと...

大体な構成

  • 技術中心
  • 技術だけではなく非技術者も楽しめる
  • 学生中心

技術中心

ガチエンジニアリングがハックをするために参加してるハッカソン

こういう系では最低限、プログラミングかデザインとかリーダーとしてめちゃめちゃできる(技術中心イベントでこういう人は嫌われる傾向にある)とかができない人が参加するとお互い不幸になります...

技術だけではなく非技術者も楽しめる

技術に着目するだけではなくてもっと幅広い視点とか価値観を持ってやろうぜ!ってイベント。

目的が違うので怒られるかもですが、スタートアップウィークエンドみたいなのを想像してます。 nposw.org

学生中心

実際のところ学生だと特に技術レベルの差がかなりあるかなと思います。(まだ入門レベルな人が参加するのは否定はしませんが...

実際数日という短い期間で何か成果を出せるだけの技術力・デザイン力がある人を見抜いてチーム作るときに全力をかけないと何か作り上げるのが大変になってしまうカモです... (とはいえ、どんなチームでも作り上げなければいけないのはありますが....

求められる技術の傾向

  • Web
  • IoT
  • Mobile App

Web

Webサービスは鉄板です。何と言っても開発スピードが段違い。

とはいえ最近はネタも尽きてきてどこかで見たことがあるようなものばかりになってきたので衰退してきてるらしい。

IoT

最近需要の高い技術

IoT なことをするための基盤(Arduino, Raspberry Pie, Mesh など)が揃ってきたのが原因なのかな?

Mobile App

個人的にモバイルアプリ大好きなので追記した。

けど、SPAJAM とかじゃない限りハッカソンでモバイルアプリは大変だと思う。

Web 等に比べて開発に時間かかるからね...

個人的にはUWP アプリで色々なAPI を雑に叩くアプリを高速に錬成するのは好きです。
カメラとかも(細かいところに気を配らねければ)扱うの楽だし

ハッカソンの開催される地域

主に東京で開催されます。(それはそう)

ただ、地方で開催されるハッカソンは特色なものが多いので開始されてたら参加してみるとおもろい人がいるので良いかも!

おまけ

ハッカソンのなかでちょっとコンテキストが高いワードとかがあるのでちょっと列挙してみる

ハッカソンマスター

ハッカソンに参加して優勝をかっさらってくおじさんのこと。

私自身はまだあったことないのでどんな人かわからないのです。。。

色々なところのハッカソンに参加してるらしい

プレゼンマスター

イケイケな会社のイケイケな人が製品ほとんどできてないのにプレゼンで優勝をかっさらってく人。

それもそれで一つの手段なので否定することはできないけどね... 

個人的には嫌い。

まとめ

  • ハッカソンは数日で開発をするイベント
  • 技術者・デザイナーが中心みを感じる
  • ハードウェアできる人とか最近は需要高い

プログラミングする人全員に読んでほしい!Clean Architecture 達人に学ぶソフトウェアの構造と設計 を読んだ感想を書くよ!!

「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだ感想を書きます!

お硬いタイトルですが、簡単に言うと見やすいプログラムを書くために必要なことが書かれた本です!

こんな体験をしたことがある人に特におすすめです!(体験したことない人や体験したくない人にもおすすめ!!

  • コードがぐちゃぐちゃで見にくい... コードをあまり見たくない...
  • ViewController, Controller, Activity のコード行数が数百行以上...
  • より綺麗な設計のコードを書きたい!

※過去の私であることは秘密です...

読んだ感想を一言で!

プログラムを綺麗に書くにはどうすればいいのかについて書いてある!!

実は、最初 Clean Architecture について延々と書いてあるのかなーと思ってました。

ところが読み進めていくとその認識が間違っていると気づきました。

具体的な実装についてはほとんど書いてなく、概念と気をつけるべきポイントを中心に描かれてました!

本にも書いてあるように「遅くとも着実であれば競争に勝つ」なので、アーキテクチャ等を着実に自分のものにしてプログラムを書いていければ良さげかなと!!

どんなことが書いてあるの?

例えば

特に気に入ってる部分

個人的には設計の原則のところが良きでした。

今まで自分がプログラムを書くうえでなんとなくこうするといいよね?ってやってきたことが言語化されてました!
こう書くのはこんな名前がついてるのか!」 みたいな

単一責任の原則 とか オープンクローズドの原則 とかは聞いたことあるんじゃないかなと!
※単一責任の原則とは一つのモジュール(クラス)は一つの責務(機能)しか持たないって意味
※オープンクローズドの原則とは拡張しやすいけど、修正しても影響範囲は狭いって意味

「こんな感じでこう言う原則があるよ〜」って話やこんな感じで作ると良きよ〜!って話があったり!

変に略してないのでわかりやすい

ネットでここら調べててよくあるのが「動物クラスを継承して犬クラスを実装したらオブジェクト指向を理解できる」とか「Todoアプリのサンプルを見せただけでアーキテクチャについて説明した気になっている」とかの結局よくわからない怪文で説明されること。

この本は内容はがっつり!(けど個人的に変に略してないのでわかりやすかった!

上述しましたが、具体的な実装についてはあまり触れてないので今後も役立つ知識を付けれるかと!!!!(こう言う本は少ない....

ちょっと面白かった部分

アーキテクチャ考古学」と言う部分が面白かったです!

昔のIT業界のアーキテクチャについてとか書いてある!!!

私はWindows 98 と同い年な98年生まれなので昔の人がどんな感じでプログラムを書いてるか!とかについてはほとんど知りません!(ベテランエンジニアの人との飲み会では軽く聞いたりはしてますが...)

まとめ

もっと早くに買うべきでした...! リーダブルコード(ITエンジニアの中で聖書と言われてる本)並みにみんな買うべき本!!!! Kindle版が存在するのでKindle版を買うと荷物が増えなくて良いかも!!
開発の途中にチラ見しながらコード書くと綺麗な設計なコードが書けるようになる!(気がするw

筆者に感謝です!!

Azure Functions の V2 を使おうとしたら The binding type(s) 'queue' are not registered. Please ensure the type is correct and the binding extension is installed. ってエラーがでた

最近何かと Azure Functions で手軽に作ることが多いです。

今回は新しく Azure Functions を使って作ってこうと思ってたらタイトル通りなエラーが出ました。

やろうとしてたこと

Azure Storage Queue とバインディングして色々する感じのやつです。
よくある感じの

The binding type(s) 'queue' are not registered. Please ensure the type is correct and the binding extension is installed.

面倒だったので deploy は Github にプッシュしたコードを自動でデプロイするように最近プレビューになっているデプロイセンターより利用してました。

エラーが出る原因(というか出ないと思って進めた原因)

Azure Functions V2 から Storage Extensions は すでに入っているのではなく使うたびにinstall する形になったようです。

Azure Functions Runtime 2.0.12050-alpha breaking changes notice · Issue #129 · Azure/app-service-announcements · GitHub

ダメだった対処法

無理やりインストールしてみる

dotnet コマンドが入ってそうな雰囲気がしたので nodejs で無理やり パッケージを無理やりインストールしてみました。

具体的には以下のような手順で入れてみました。

そもそも func コマンドが入っていなかったのでnpm で入れて、それから func コマンドを利用して Extension を入れるって感じのあれです。

npm install -g azure-function-core-tools
func extensions install --package Microsoft.Azure.WebJobs.Extensions.Storage --version 3.0.0-beta8
dotnet restore

動きませんでした。

解決した対処法

まず、色々環境を汚してしまったので再度 Azure Functions を作り直しました。

その後、 Storage を利用するテンプレート関数を新規作成しようとしました。
するとStorage の Extension をインストールしますか?的なポップアップが出るのでインストールしました。

ここが悪い

GUIで 任意の Extension を 任意のタイミングでできない...
とはいえ、最近の変更に沿ったUI を作り続けるのは大変だと思うので中の人頑張って... 感が。

まとめ

Azure Functions の Storage Extension を明示的にインストールする必要がある Portal からゴリゴリしてもうまく動かないかも... Github から deploy するようにしてると罠にハマるかも...

Navigation Architecture Component で BottomNavigation と Include した Navigation Graph を紐付ける

Android 3.2 正式リリース && Androidx 1.0 おめでとうございます🎊

さて、 Android Studio 3.2 から入ってきた Navigation Architecture Component (NAC)
NAC には BottomNavigationView (and DrawerView?) と紐づけ、Fragment の ID と menu の id を一緒にすることで タップした時によしなにナビゲーションしてくれる機能があります。

https://willowtreeapps.com/ideas/exploring-androids-navigation-architecture-component

また、NAC の中には、 他のNavigation Graph を include する機能があります。
そんな状況でNavigation できるようにする方法について書いていきます。

課題点

ドキュメント等には、 Root Navigation Graph の中にある Fragment と BottonnavigationView を紐づける方法について書いてはあっても Include したやつと 紐づける方法については書いてない

解決策

Include された Navigation Graph の @+id?hoge を menu の ID と同じにすればおk

<navigation xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto" 
   **android:id="@+id/huge"**
    app:startDestination="@id/hoge>
// many Fragments
</navigation>

Android で Databinding しようとしたら Cause: couldn't make a guess for {Class Name} ってエラーがでる

状況

以下のようなエラーが出てしまいました...

Cause: couldn't make a guess for {Class Name}

解決策・原因

パッケージネームに大文字が混入してたのが原因です。 意外に見つけにくい...