はじめに BigQuery ML 2値分類チュートリアルをやってみた 01の続きです。 ステップ4のメモ SELECT * EXCEPT(dataframe) FROM `census.input_view` ステップ4のSQL文ですがEXCEPT句を久々に見たので改めて調べました。 リファレンスに記載されている書き方は下記でした。 SELECT * FROM UNNEST(ARRAY<int64>[1, 2, 3]) AS number EXCEPT DISTINCT SELECT 1; FROM句で指定するテーブルの右側にEXCEPTと除きたいデータ（ここではDISTINCT SELECT 1）を記載することで除いています。 チュートリアルに戻ると、ステップ4に関しては該当カラムを除くように使っています。挿入箇所がリファレンスと異なりますが、行ってい操作は同じになります。 このExceotの書き方はBigQueryに限った書き方ではなく、SQL ServerやPostgreSQLにもサポートされている書き方になります。 チュートリアルで説明が無かった下記の２つのオプションについて確認します。 data_split_method='NO_SPLIT', max_iterations=15) AS data_split_method は、AUTO_SPLIT, RANDOM, CUSTOM, SEQ, NO_SPLITが選べます。 https://cloud.google.com/bigquery-ml/docs/reference/standard-sql/bigqueryml-syntax-create-glm#data_split_method デフォルトはAUTO_SPLITです。 CUSTOMは指定したカラムがbool型でTRUEかNULLだと評価として使われ、FALSEだとtraiingデータとして使われるようです。 カラムの指定は別のオプションのDATA_SPLIT_COLで指定可能です。SEQを指定した場合も同様にDATA_SPLIT_COLを使います。 SEQは指定したカラムでの小さい値から指定した割合までを学習データとして、それ以降を評価データとして使います。カラムの指定はCUSTOMと同じく、 DATA_SPLIT_COL、割合の指定はDATA_SPLIT_EVAL_FRACTIONオプションで指定します。 ステップ5のメモ ステップ5のSQLの結果とモデルの詳細画面の結果が異なるので調べました。 ステップ5のSQLの結果はチュートリアルに説明があるように、入力データの中からdataframe列がevaluationのものを抽出しています。 ステップ4で作ったロジスティック回帰のモデルを作るためのSQLではデータの分け方をno_splitにしているので、 データの分離をせずにすべてのデータを学習データと評価データに使います。 そのため、モデル詳細画面に記載されている精度の各値と、dataframe列がevaluationのデータをもとに学習したモデルに入れたデータの各精度指標が異なってきます。 また、それだけではなく今回はauto_class_weights=TRUEのオプションで各クラスのウェイトを重みつけすることもしているので、 この影響もあるので下記のように単純に学習データをすべて入れても計算結果が異なります。 異なるといっても大きな差がでていないのでここではそこまで議論しなくてもよいかもしれません。 SELECT * FROM ML.EVALUATE (MODEL `census.census_model`, ( SELECT * FROM `census.input_view` ) ステップ6のメモ 実際に使うときのthresholdはML.PREDICTのthresholdを使うことで指定できます。 https://cloud....

Themeを使いつつHugoでhtmlを追加する方法 HugoでThemeを利用しているときに、ThemeでGoogle Analyticsの設定が用意されていなかったときや、 オリジナルのheader、footerを追加したいときなどにhtmlを修正したくなることがあると思います。 そのようなときにどのように対応できるか調べた限りいくつか方法がありました。 Theme上のlayoutsを編集する Theme上のlayouts内のファイルを、hugoのrootパスのlayoutsディレクトリに同じ階層で配置して改修する（参考） 改修したい内容のThemeを追加して２つのThemeを参照するように変更(参考) 方法1 Theme上のlayoutsを編集する ネットで方法を検索すると1のThemeのlayoutsを編集するのが多かった印象です（この印象は主観的です）。 この方法でできないか最初考えたのですが、Themeの更新があったときに簡単に更新できるようにしたく、submoduleでThemeを管理したいために1の方法は断念しました。 Docのディレクトリ構造を見ていない方は要チェック！ Themeを編集しないで改修できない方法がないかと考えました。 次の話に進む前にもしHugoのDocを見たことがない場合は、そちらを先にみることをおすすめします。 基本的なディレクトリ構造を理解していることが重要です。私は横着して見ておらず、 調べている途中でDocを見てから理解したので最初にディレクトリ構造を理解しておいたほうがよかったと思いました…。 ディレクトリ構造についてはこちらに記載があります。 このディレクトリ構造を理解した前提で話を進めます。 方法2 Theme上のlayouts内のファイルを、hugoのrootパスのlayoutsディレクトリに同じ階層で配置して改修する 方法1ではTheme上のlayoutsを直接編集していました。方法2ではthemes内のlayoutsにあるファイルをlayouts以下の階層構造をそのまま維持して、 hugoのrootパス配下のlayoutsにファイルを配置して上書きする方法です。 このときに同じ階層を作ることに注意してください。私は何度かスペルミスをしてなぜ動かないのか無駄に時間をかけてしまいました…。 Themeのファイルをコピーして上書きすると同じ階層に同じファイル名のファイルがあった場合は、 Theme上のlayoutsのファイルではなくて、Hugo rootパスのlayouts内のファイルを参照するという仕組みになっていますので そちらを参照することができます。 この方法でもよかったのですが、実際私の場合はhugo-theme-stackを利用しており、 その中のthemes/hugo-theme-stack/layouts/partials/head/head.html を確認するとcustom.htmlを参照していることを確認でき、 custom.htmlの中身を確認したところ空ファイルだったのでこれを利用することにしました。 Hugoのrootパスでlayouts/partials/head/custom.htmlを作成し、デフォルトのテーマから変更したいhtmlの記載を記載すると反映することができます。 head.htmlをそのまま修正することでも反映は可能かもしれないですが、Themeディレクトリのhead.htmlは残っているので できるだけコードの全体量を少なくしたいという観点からcustom.htmlを使うことにしました（そこまで影響はないと思いますので好みかと思います）。 方法3 改修したい内容のThemeを追加して２つのThemeを参照するように変更 こちらは今回検証はしなかったのですがHugoの質問サイトで記載があったので備忘録として記載します。 採用したThemeとは別のオリジナルThemeを採用し、その中に改修したいファイルを追加するなどして サイト全体を改修するという方針です。 2つのテーマを使う方法はこちらです。 themes: [“originaltheme”, “mytheme”]. 右側のThemeにあるファイルが左にあるThemeをすべて上書きするようです。 実際に確認はしていないのでこの方法を利用されるときは注意してください。 参考：https://discourse.gohugo.io/t/is-it-possible-to-append-to-a-theme-partial/26004/2 まとめ 教訓：HugoのDocはちゃんと見るようにします… 参考 https://gohugo.io/getting-started/directory-structure/ https://discourse.gohugo.io/t/how-do-you-add-a-script-into-the-head/10882 https://discourse.gohugo.io/t/is-it-possible-to-append-to-a-theme-partial/26004/3 https://github.com/CaiJimmy/hugo-theme-stack/

はじめに BigQuery MLのチュートリアルを進めるうえで困ったところや追加で調べたところを作業メモとして残します（必要に応じて本家のドキュメントにフィードバックは送っております）。 ステップ2のデータの確認の補足 https://cloud.google.com/bigquery-ml/docs/logistic-regression-prediction#run_the_query データ確認のところで下記のクエリを投稿しています。 SELECT age, workclass, marital_status, education_num, occupation, hours_per_week, income_bracket FROM `bigquery-public-data.ml_datasets.census_adult_income` LIMIT 100; ただそのQueryの結果の説明を読んでいるとeducationとfunctional_weightカラムの説明がでてきます。 Queryの中で上記２つのカラムを指定していないのでなんのことを指しているのかここだけではわからなかったので、 下記のクエリに修正して実行しました。 SELECT age, workclass, marital_status, education_num, occupation, hours_per_week, income_bracket, education, functional_weight FROM `bigquery-public-data.ml_datasets.census_adult_income` LIMIT 100; 修正したQueryの実行結果は上記です。 こちらからeducationとeducation_numが同じことを示すだけで、別々の表現になっていることを指摘していましたが educationカラムで確かに同じであることが伺えます。 ただ、すべての行で同じかどうか念の為確認したいと思い、下記のSQLを動かして確認しました。 SELECT education, education_num, count(*) FROM `bigquery-public-data.ml_datasets.census_adult_income` GROUP BY education, education_num ; こちらから得られる結果を確認するとたしかにeducationとeducation_numの結果は1:1対応しており、 educationの１つの値がeducation_numに2回使われることがありませんでした。もちろん逆も同様でした。 ステップ3の学習データのtraining, evaluation, predictionの比率 https://cloud.google.com/bigquery-ml/docs/logistic-regression-prediction#run_the_query_2 ここでの説明が学習データとして80%使い、評価用10%、予測用10%として扱う記載ありますが、実際にどれほどの比率か確認したいと思います。 SELECT dataframe, COUNT(*) AS dataframe_num, COUNT(*) / MAX(a.total) AS ratio FROM `census.input_view`, ( SELECT COUNT(*) AS total FROM `census....

どんな人におすすめ？ アジャイル開発について簡単な歴史的背景と具体的にどのような開発手法かまとまった書籍です。 はじめてアジャイル開発について学びたい人、これまで我流でアジャイル開発を進めてきて改めて体系的に概要を学びたい人。 特にChapter7のアジャイル開発の理解を深めるが非常に参考になりました。 ウォーターフォール開発に慣れている人がアジャイル開発にするときに見積もりをしない、ドキュメントを用意しないなど ウォーターフォールから比較して気になっている方が多いと思います。私の周りの気になる人が多かったです。 そのような疑問に対してもアジャイル開発に対するそれぞれの問いに対して各Lessonで説明しているところが非常に良かったです。 組織に応じて適宜修正する必要性 また序盤にこれまでの本はそのまま手法を輸入して、日本に最適化されていないという著者の説明は面白かった。 これまで自分も含めて、周りでアジャイル開発を進めようとするときにウォーターフォール開発に慣れている人からすると受け入れがたいときがあり、 日本の文化にはアジャイル開発が馴染みにくいかなと思うときがありました。 そのような経験もあったので著者の日本に最適化されていないという点は実体験から腹落ちしました。 個人的な意見として、日本とひとくくりにしないで組織や会社によって文化があると思います。 それに応じて臨機応変に最適な手法を選んだり、そのままその手法を適応するのではなく、 適応するチーム・組織にとって最適なやり方に軌道修正する必要があることはあるので、 その際は基本コンセプトは変えずに最適な方法を模索する必要があると思っています。 もちろんこれはアジャイル開発に限らないと思います。 まとめ より実践的にアジャイル開発を導入するには基礎的なことだけでしたらこの本だけで十分ですので、 アジャイル開発の基礎的なところを学びたい方にはおすすめの本です。

TL;DR GitHub ActionsでHugoを使ってbuildする際にextendが必要となった場合、GitHub Actionsのymlファイルにextend: trueを書くと解消します。 はじめに HugoのレポジトリでPull Requestを作成した際やMergeされた際にGitHub Actionsでレポジトリに登録されたコードをHugoでbuildすることができます。 Hugoでsetup（GitHub ActionsでHugoを使えるようにする）、setupしたHugoでbuildが大きな流れになります。 本ページの参考に記載した各ウェブサイトにてHugoでのsetupを参考にさせていただきましたが、Hugo extendedの対応について書かれているところが管理人は見つからなかったので、このページでまとます（他に書いているところがあったらすみません）。 GitHub ActionsでのHugo deployの仕方 やりたかったことは下記のとおりです。 Pull Request作成 GitHub Actions開始 Pull Requestを作ったレポジトリのブランチをチェックアウト(https://github.com/actions/checkout) Hugoをset up（https://github.com/peaceiris/actions-hugo） Hugoでbuild Firebaseでpreviewページをデプロイ(https://github.com/FirebaseExtended/action-hosting-deploy) 上記中で忘れがちなところは、3の最新のブランチのチェックアウトでsubmoduleもcheckoutすることとです。 これは他のサイトでも説明されています。 GitHub Actionsとしては下記のように記載します。 ~略~ - uses: actions/checkout@v2 with: submodules: true ~略~ 今回は、5.のHugo buildのところでエラーになりました。 GitHub Actionsで表示されたエラーは下記になります。 WARN XXXX/XX/XX XX:XX:XX Module "theme-name" is not compatible with this Hugo version; run "hugo mod graph" for more information. Start building sites … hugo v0.91.2-1798BD3F linux/amd64 BuildDate=2021-12-23T15:33:34Z VendorInfo=gohugoio Error: Error building site: TOCSS: failed to transform "scss/style....