雑史

思ったこととかメモとか

Google Cloud FunctionsからスプレッドシートAPIをPythonで操作する

Python GCP

はじめに

タイトル通りのことがしたかったんだけど、意外とこの組み合わせのサンプルっぽいものが無かったのです記録に残しておく。
サンプルリポジトリ作りました。

github.com

スプレッドシートAPIを有効にする

まずはじめに、GoogleのデベロッパーコンソールからスプレッドシートAPIを有効にする。

f:id:kzk0829:20200504220706p:plain
プロジェクトの選択

ここから、プロジェクトを選択する。
そしたら、検索ボックスから「Sheets API」を検索して、有効化する。

サービスアカウントのアドレスをスプレッドシートに登録する

まずはGCPコンソールにログイン。

左上のナビゲーションメニューからIAMと管理＞サービスアカウントを選択する。

f:id:kzk0829:20200504221426p:plain

そしたら、名前がApp Engine default service accountのメールをコピーする。

f:id:kzk0829:20200504221623p:plain

コピーしたらそのアドレスをスプレッドシートの共有設定に登録する。

f:id:kzk0829:20200504221826p:plain

最後にスプレッドシートの以下部分をコピーしておく。
あとで、SPREADSHEET_KEYとして使う。

https://docs.google.com/spreadsheets/d/{ここの部分！}/edit#gid=0

設定はこれでおしまい。

ソースコード

import gspread
import google.auth

def main(event, context):

    # ここで認証情報を取得する。デフォルトのサービスアカウントが適用される
    credentials, _ = google.auth.default(scopes=['https://spreadsheets.google.com/feeds', 'https://www.googleapis.com/auth/drive'])

    # ここでスプレッドシートの認証
    gc = gspread.authorize(credentials)

    # 先ほどコピーしたスプレッドシートキーを変数に
    SPREADSHEET_KEY = '{your-spreadsheet-key}'

    # sheet1を取得
    worksheet = gc.open_by_key(SPREADSHEET_KEY).sheet1

    import_value = int(worksheet.acell('A1').value)

    export_value = import_value + 100
    worksheet.update_cell(1, 2, export_value)

上記のような感じで操作する。
なかなか認証周りの資料がない中、そのプロジェクトのデフォルトのサービスアカウントの情報をスプレッドシートに登録しておけばjsonファイル等がなくても操作できることがわかった。

オブジェクト指向でなぜつくるのか 第6章

オブジェクト指向 学習ログ 読書

はじめに

kzk0829.hatenablog.com

これの続き

OOPがもたらしたソフトウェアとアイデアの再利用

  • OOPで開発するときは、毎回ゼロから作るわけではなく、再利用するよね
  • ソフトウェアの再利用とアイデアの再利用についての章

ソフトウェアの再利用

　 - クラスライブラリ - フレームワーク - コンポーネント

といったようなものたち。

クラスライブラリ

汎用的な機能を持つクラスを集めたもの。
アプリケーションから呼び出して利用したりする。
標準のクラスライブラリや外部のクラスライブラリ等がある。

  • 言語の標準クラスライブラリ
  • 外部のクラスライブラリ
    • 上記PHPのDateTimeをラップした日付操作ライブラリのCarbon github.com

フレームワーク

特定のプログラミング言語で書かれた、特定の目的を持つ再利用部品群のこと
基本的な制御の流れをフレームワーク側で用意して、アプリケーションで個別の処理を組み込む
クラスライブラリとは違い、フレームワークがアプリケーションの処理を呼び出す

LaravelやRuby on Rails等

アイデアの再利用

デザインパターン

設計のパターンのこと
再利用がしやすいソフトウェアを作るために先人たちが工夫したアイデアを文書にまとめたものである。
特に有名なのが、GoFのデザインパターン

まとめ

この章は、再利用にはこのようなパターンがあるよという話で、具体的な話はなかった。
ただ、ライブラリやフレームワークに関しては、当たり前のように使っていたものの定義をしっかりと確認できてよかった。

オブジェクト指向でなぜ作るのか 第5章を読んだ

オブジェクト指向 学習ログ 読書

はじめに

kzk0829.hatenablog.com

これの続き

メモリの仕組みの理解はプログラマのたしなみ

  • 比較的新しく作られた言語は、メモリのことを意識しなくて済む
    • ただ、何が行われて動いているか理解していないと、途方にくれるかもしれない
    • だから最低限理解しておく必要があるよという章

コンパイラとインタプリタ

　 - コンパイル言語はコンパイラがソースコードを機械語に変換して実行を行う - インタプリタ言語は実行時にソースコードの解釈を行う

まあこの辺は当たり前の前提知識という感じ。
個人的にはコンパイル言語の方が好き。

上記以外に中間コード方式というのもある。
コンパイルはするが、専用のインタプリタ上で実行することで異なる実行環境でも動作する。（JVM上のJavaなど）
JavaがJVM上で動作することは知っていたが、中間コード方式ということは知らなかった。

CPUは複数のスレッドを同時実行する

  • スレッドとはプロセスよりも小さな単位
  • スレッドは一つの作業を最初から最後まで一気に行うわけではなく、中断して他のスレッドの作業を実行する。
  • これをマルチスレッドという。

この辺も最低限は知っていた。
マルチスレッドができる理由は、全体効率を上げるため。CPUのリソースを効率よく使用することができる。

静的領域、ヒープ領域、スタック領域で管理する

メモリの使い方について。

  • メモリの領域は基本的に静的領域、ヒープ領域、スタック領域の3つの領域で管理する。

静的領域について

  • プログラムの開始時に確保され、プログラムが終了するまで配置が固定される領域のこと
  • 静的な変数、つまりグローバル変数とプログラムの命令を実行可能な形式に変換したコードが配置される

ヒープ領域について

  • プログラムの実行時に動的に確保するメモリ領域のこと
  • 必要に応じてアプリケーションに割り当てる

スタック領域について

  • スレッドの制御のために使うメモリ領域のこと
  • スレッドに一つずつ用意される
  • メソッドの引数やローカル変数、戻り値などが格納される

この辺の領域については曖昧な知識だったので、改めて確認することができてよかった。
ここまで説明されてきた、内容はあくまで常識とのこと。
心に留めておきたい。

OOPの特徴はメモリの使い方にあり

ここからはOOP固有の話

クラス情報はクラスにつき1つだけロードされる

  • 同じクラスから作られた異なるインスタンスであっても、メソッドに書かれたコード情報同じため、1つのロードが行われる
  • このクラス情報がロードされる領域は静的領域

インスタンス生成のたびにヒープ領域が使われる

  • 作成したインスタンスは全てヒープ領域に格納される
  • プログラマは、」有限なメモリ領域であるヒープ領域を大量に使って動くことを理解しておくべき

変数にはインスタンスのポインタが格納される

  • 作成したインスタンスを格納する変数には、ヒープ領域に作成されたインスタンスのポインタが格納される
  • ポインタはメモリ領域の場所を示す情報
  • javaでは変数のコピーに注意が必要
    • 変数にはポインタが入るため

まとめ

この章は結構ボリュームがあった。
なんとなくで知っていたことや、意外と知らなかった知識を分かりやすいJavaのコード例と、図で示してくれていたので、とても勉強になった。
今まではあまりなかったが、これからはちょっとはメモリのことを意識してコードを書いていきたい。

2年目を終えて

はじめに

昨日3/31を持って社会人2年目及び新卒で入った会社からグループ内転籍（面接したしほぼ転職）したので振り返り。
新卒でエンジニアに配属された会社は、がっつり営業会社。

やったこと

こう見ると少人数だった分色んなタスクが降ってきてそれをこなしたなーという感じ。
未経験から配属された割に領域問わずフロント、バック、インフラと満遍なくさわれていい経験できたなという感じ。

できるようになったこと

  • PHP/Laravel
  • サーバー構築最低限（Ansibleも最低限）
  • 動くアプリケーションを構築すること

業務で触れてきた範囲は最低限できるようになったかなあという感じ。

まだ未熟なもの

色んな言語触ってしまったし、そういう環境にあったからだが、割と深いところまで学びきれなかった。
組織的にも高めていこうという気概は鈍かった気がする。もっとバックエンド開発における足腰を鍛えなければなと。

これからやること

グループ内のがっつりしたエンジニア組織（会社）に転籍する。

こう見るとエンジニア組織としてかなりモダンでしっかりとした環境に移ることになる。
自分で望んだことだし、また1から日々精進するのみ。

テーマ

これから勉強というか身に付けたいなと思っているテーマ。

過去から大きく変わらない部分の力をつける

これは、t_wadaさんの技術選定の審美眼という話の中で書かれたものからインスパイアされた。
この資料の長生きしている技術に学ぶ部分あたりをしっかりと身につけようと思う。
ちょうどRDBMS（SQL）については勉強していたところだし。
あと、個人的にはGoを結構楽しく勉強していたので、それも引き続きやっていきたい。

オブジェクト指向でなぜ作るのか 第4章を読んだ

はじめに

kzk0829.hatenablog.com

このエントリーの続き。 引き続き思考の整理、アウトプットとして。

第4章 OOPは無駄を省いて整理整頓するプログラミング技術

今までの章の流れから、じゃあ実際OOPってどういう特徴があって何が嬉しいの？の部分をちょっと長めに取って説明している章。

OOPには三つの大きな要素がある

それぞれの効能（嬉しい点）については以下

クラス

  • まとめる
  • 隠す
  • たくさん作る

上記がクラスの効能。

  • 部品が減るというメリット
  • 命名が楽になるというメリット
  • 部品が探しやすくなるというメリット

がある。

この辺は当たり前のようにやっているので改めて説明されて再確認という感じ。逆にクラスがなかったら、とっちらかっているという説明をしっかりとされて、偉大さを再確認できた。
また、機能をクラスにまとめているので命名も楽になるし部品が探しやすくもなる。
命名は気をつけなければいけないものではあるものの、クラス内の部品という隠された内部のことであるならばシンプルに保てるよねという話。
探しやすさについてはIDEの進化も合間ってすごく楽。

ポリモーフィズム

呼び出す側のロジックを共通化する仕組み
ポリモーフィズムについては、今まで一番言葉の定義を曖昧にしながら使ってきたものかもしれない。interfaceのようなものと理解した。
自分としてはinterface設計自体があまり得意ではなく、慣れていないので、しっかりとできるようにしたい。
その効能としては、接点を共通化することで、実装を隠蔽することができる。という風に認識している。似たような処理を一つのinterfaceとして提供することで、呼び出し側での手戻りを少なくできる。

継承

複数クラスの共通する部分を別クラス（スーパークラス）にまとめて、コードの重複を排除する仕組み。
これはよく使うから馴染みがある。
ただ、クラス設計をうまくできずに巨大なスーパークラスが出来上がってしまったこともある。
個人的には継承とポリモーフィズムを綺麗に使い分けて整頓されたコードを仕上げることをできるようになることが課題かなと思う。

これで三つの説明をまとめた。
この他に、パッケージ、例外、ガベージコレクションについても軽く触れられていたので説明する。

  • パッケージ
    • クラスをまとめる仕組み
      • PHPで自作パッケージを使用することがなかった（それほど大規模なプロダクトじゃなかった）のでイメージはComposerでインストールするパッケージやライブラリたち
  • 例外
    • 戻り値と違う形で特別なエラーを返す仕組み
      • 当たり前のように使っていたが、例外がないと全てハンドリングして返さなければいけない
      • Golangをちょっとやった時に例外がなくて大変だなと苦労した
  • ガベージコレクション
    • インスタンスを作った時、不要になった時点で自動でメモリを解放してくれる機能
    • 意識したことがなかったが、こんなに素晴らしい機能が標準で言語に備わっているのかというお気持ち

今までの章と比べるとボリュームがあったが、いい感じにまとめられていて読みやすかった。

オブジェクト指向でなぜ作るか 第3章を読みました

オブジェクト指向 学習ログ 読書

はじめに

kzk0829.hatenablog.com

このエントリーの続き。
引き続き思考の整理、アウトプットとして。

第3章 OOPを理解する近道はプログラミング言語の歴史にあり

先人たちがオブジェクト指向という「ソフトウェア開発の総合技術」にたどり着くまでの歴史について。
どのようにプログラミングは発展し、何が問題で、どのように解決してきた結果オブジェクト指向プログラミングにたどり着いたのかということを述べた章。

ざっくりとした歴史の流れは以下

高級言語の発明までは、表現力の向上に重きが置かれ、構造化プログラミングは保守性、再利用性の向上に重きが置かれている

では、構造化プログラミングとはどんなものか？
正しく分かりやすい構造にする必要がある、という考えのもと普及した。これは、当時ソフトウェア需要が増大していたことにも関係してくる。
この構造化プログラミングの基本三構造は以下の通り。

  • 順次進行
    • 処理は呼ばれた順に上から実行
  • 条件分岐
    • 命令によって次の処理を決定
  • 繰り返し
    • ある条件に当てはまるまで一定回数繰り返す

この理論がシンプルだったため当時受け入れられたという。 また、当時の工夫が独立性を高め、保守に強くすること。
例えば、グローバル変数の使用を少なくするという工夫。何か不正があった場合に調べる範囲が広く保守性が低いため。
自分も意識しないうちにグローバル変数をあまり使わないように意識していたので、納得感が高かった。
この保守に強い構造にするということは、プログラムの寿命が伸びたことに起因している。
当時は10年以上後も自分の書いたコードが使われるという考えはなかったという。
それが違うと分かってきて、複雑さを避け、理解しやすさを重視し、使い回しによる生産性の向上が求められるような時代に入っていった。
ただ、グローバル変数の利用制限、大規模な再利用は構造化プログラミングでは限界があったことによって生まれたのがOOPであるという。

次の章からオブジェクト指向プログラミングの話に入っていく。

オブジェクト指向でなぜつくるのかを読み始めました

学習ログ 読書 オブジェクト指向

はじめに

タイトルの通り。

オブジェクト指向でなぜつくるのか 第2版

オブジェクト指向でなぜつくるのか 第2版

  • 作者:平澤 章
  • 発売日: 2011/04/07
  • メディア: 単行本

なぜ読み始めたのか

OOPであるPHPを利用して当たり前のようにLaravelで開発しているものの、オブジェクト指向は雰囲気でしか理解していないし、一度しっかりとしたインプットをして活かしていきたいと思ったから。
例のごとく1章ずつ読むたびにこまめにアウトプットしていこうと思う。

第1章 オブジェクト指向はソフトウェア開発を楽にする技術

この書籍の導入となる章。
細かな話は何もない。
オブジェクト指向とは「ソフトウェア開発の総合技術」だが、難しく感じてしまう理由は以下の通り

  • 用語の洪水
    • 難しい専門（横文字で聞いたことない）用語がたくさん出てくる
  • 比喩の乱用
    • 説明時の比喩が分かりにくく理解しにくい
  • なんでもオブジェクト症候群
    • 言葉が広すぎてなんでもオブジェクトになってしまう

確かに、比喩でしっかり理解できた感覚はないし、難しい用語が多いなと感じる。
しっかり読んで身につけていこうと思う。

第2章 オブジェクト指向と現実世界は似て非なるもの

まず、オブジェクト指向の三大要素である、

について、超ざっくり説明があった。言葉の意味はだいたい知っているし、意味も分かっているが、ポリモーフィズムはうまく使いこなしてるとは言えない。
ネットで調べると、たまにあるくらいの入門的な内容。

上記1,2章が導入だった。