subprocess.runで環境変数を展開する[Python]

メモ Python

subprocessで展開する

> echo $HOGE
hogehoge

のような環境変数が定義されているとする．

以下のソースコードを実行すると，環境変数が展開されずに$HOGEが出力される．

import subprocess

subprocess.run(['echo', '$HOGE']) # 出力：$HOGE

subprocessでは，環境変数の展開に限らず，ワイルドカードやチルダによるホームディレクトリの展開ができない． 上記の機能を使いたい場合は，shellオプションを有効にする．

import subprocess

subprocess.run(['echo $HOGE'], shell=True) # 出力：hogehoge

これで環境変数が展開できる．

Pythonドキュメントに書いてあること

shell が True なら、指定されたコマンドはシェルによって実行されます。あなたが Python を主として (ほとんどのシステムシェル以上の) 強化された制御フローのために使用していて、さらにシェルパイプ、ファイル名ワイルドカード、環境変数展開、~ のユーザーホームディレクトリへの展開のような他のシェル機能への簡単なアクセスを望むなら、これは有用かもしれません。しかしながら、Python 自身が多くのシェル的な機能の実装を提供していることに注意してください (特に glob, fnmatch, os.walk(), os.path.expandvars(), os.path.expanduser(), shutil)。

引用元：subprocess --- サブプロセス管理 — Python 3.9.2rc1 ドキュメント

例えば，環境変数を得るなら，expandvarsを使えば良い．

import os

print(os.path.expandvars("$HOGE")) # 出力：hogehoge

所感

subprocessまみれにしてPythonでシェルスリプトを書くのはやめたほうがいいと思う．

Junit4のテストをコンソールで実行する

メモ

用意したもの

  • junit-4.13.jar
  • hamcrest-core-1.3.jar
  • sampleプロジェクト
ディレクトリ構成
root/
  ┗ sample
       ┣ Add.java
       ┗ AddTest.java
Add.java
package sample;

public class Add {
    public int add(int a, int b){
        return a + b;
    }
}
AddTest.java
package sample;

import static org.junit.Assert.*;

public class AddTest {
    @org.junit.Test
    public void Test01(){
        Add add = new Add();
        assertEquals(5, add.add(2,3));
    }
}

テスト実行

コンパイル (カレントディレクトリ：root/sample)

クラスパスにjunitへのパスを指定しないとコンパイルできない．

javac -cp /path/to/junit-4.13.jar Add.java AddTest.java

テスト実行 (カレントディレクトリ：root/)

クラスパスにカレントディレクトリ，junit, hamcrestへのパスを指定しないと実行できない．

java -cp .:/path/to/junit-4.13.jar:/path/to/hamcrest-core-1.3.jar org.junit.runner.JUnitCore sample.AddTest

出力

JUnit version 4.13
.
Time: 0.01

OK (1 test)

エラーが出るとき

何かがおかしいと，以下のようなエラーが出力される．

java.lang.IllegalArgumentException: Could not find class [AddTest]
Exception in thread "main" java.lang.NoClassDefFoundError: sample/AddTest (wrong name: AddTest)

確認する部分は以下．

  • クラスパスに，カレントディレクトリ，humcrest，junitへのパスを指定している．
  • テスト実行をパッケージの親ディレクトリで行なっている（今回の例でいうとroot/）．
  • テストクラス名にパッケージ名をつけている（今回の例でいうと，AddTestではなく，sample.AddTest）．
  • パッケージ名とディレクトリ名が正しい．

Visual Studio で .Net Core のコンソールアプリ開発をしていたら System.Drawing.Image が使えなかったので NuGet で System.Drawing.Common をインストールした際のメモ

メモ
「.Net Core の」っておかしくないか？

環境・状態

  • Windows10
  • Visual Studio2019
  • .Net Core のコンソールアプリを開発中
  • System.Drawing.Image にエラーが出る．using もできない．

System.Drawing.Image の名前参照が解決できない

アセンブリ参照を追加しなければならないとかなんとかのエラーが出る． そこで，参照の追加を試みた．

参照マネージャーから追加する

ソリューションエクスプローラーを右クリックして参照マネージャーを開く． しかし，「アセンブリ」の項目がない．

  • アセンブリ ← これがない
  • プロジェクト
  • 共有プロジェクト
  • ...

参照マネージャーからアセンブリ参照を追加するのはできなかった．

System.Drawing.Common をインストールする

System.Drawing が使えない解決策として，System.Drawing.Common を使えば良いらしい．

参考：.NET CoreでSystem.Drawingを使う - 備忘録

上記サイトではNugetでインストールしている． Nugetは.Netのパッケージマネージャーで，Visual Studioのインストーラからインストールすることもできる． 自分の環境では，デフォルトでインストールする設定になっていた．

docs.microsoft.com

上記に書いてあると通り，

ツール＞NuGetパッケージマネージャー＞パッケージマネージャーコンソール

で，コンソールを開く．

以下のコマンドでインストールする．

Install-Package System.Drawing.Common

結果

System.Drawing.Image の名前参照が解決できるようになった．

『思考・論理・分析　「正しく考え，正しくわかること」の理論と実践』を読んだ

本

公式：産業能率大学出版部 思考・論理・分析

www.hanmoto.com

かなり前から積んでいた日常用法的論理の本．普段なんとなく使っている「論理的」や「分析」の意味を定義していて，「なるほどね〜」という気持ちになった．「前提はなんだろう」「どのような論理展開をしたんだろう」という視点を持てるので，そのような考えに慣れてない人には特に良さそう．

分かることは分けること

第一章「思考」の部分で分かることは分けることであるという内容がある．

物事を識別するためには色々なものと比べることで差異を際立たせ，その物事特有の性質を理解しなければならない．比べる際には，どのような切り口で比較するかが重要となる．この切り口を列挙することが「分けること」で，複数ある切り口を用いて差異を際立たせることで「分かる」のだという．

そして，「分ける」ために以下の３つが必要であると述べている．

  • ディメンジョンの統一

    分ける，あるいは比べる対象の抽象水準を同一にする

    「りんごか野菜どちらか好きか」は抽象水準が異なるため不適切で，「りんごかトマト」「果物か野菜」の方がより適切．（親が同じでないと比較できないという感じ？）

  • クライテリアの設定

    分類基準，分類の切り口のこと．食べ物を「素材」で分けると「野菜，果物」などに分類できて，「国籍」で分けると「和食，中華」などに分類できる．

  • MECE (Mutually Exclusive, Colloectively Exhaustive)

    相互背反，集合網羅．モレがなく，かつダブりがない．現実で厳密なMECEは無理なので，MECE的な分類が必要になる．

言われてみればそれはそうだけど，あまり意識しない部分．

因果補足の難しさ

相関には単純相関と因果があって，これを見極めるのが難しい．

本書では以下の３つの留意点を挙げている．

  • 因果の強さ
    原因が結果に与える影響力はそれぞれ異なる．
  • 第三ファクター
    X -> A, X ->B のような因果関係があり，A, B に相関関係を生じさせてしまうような X．A -> B に因果関係があるように見える．
    例）X: 家族数，A: 茶碗の数，B: 米の消費量
  • 直接的連動関係
    ある結果を直接的に引き起こしている関係．

直接的連動関係についての例示は面白い．

「スピードの出し過ぎが事故の原因である」は一見正しそうに見えるが，スピードの出し過ぎが直接事故を引き起こしている訳ではない．

スピードの出し過ぎ→飛び出しに気づくのが遅れた→ブレーキを踏むのが遅れた→事故

のように，原因→結果の鎖がいくつも繋がっている．因果関係に働きかけて結果を変えるためには，複数ある原因を正しく認識することが必要である．

「人間がいなくなれば犯罪がなくなる」のような意見は，働きかける原因を間違えた例．

分析について

分析は，思考と同じように，情報を整理してなんらかの意味合いを得ることだと述べている．

分析の要件として以下の３つを挙げている．

  • 意味合いがアウトプット
    分析対象をまとめるだけでは意味がない．分析した結果，何がわかったのかというアウトプットが大事．

  • 情報収拾の必要性
    情報がなければ分析がそもそもできない．

  • 目的の存在
    原因の解決や手段の発見など，分析の目的が存在する．分けて分かることが目的でない．

目的があり，その上で必要な情報を集め，その情報から目的に沿った意味合い（結論）を見つけるのが分析であるということかな？．

最近聞いた，「データマイニングした結果を整理するだけだとアクショナブルじゃない」というのはつまり，「情報をまとめただけで意味合いが得られていない」ということか．

まとめ

  • 『思考・論理・分析　「正しく考え，正しくわかること」の理論と実践』を読んだ
  • 今までなんとなく使ってきた「論理的」の意味が少しわかった
  • こういうメタ知識は大切
  • 第三章の「分析」は知らないことが多かった

関連書籍

www.utp.or.jp

こちらは記号をいじる方の論理学．ルールに従って式を変形させるパズル的なやつ． 「トマトが野菜であるなら、トマトサラダは野菜サラダである」が証明できるようになる．

演繹法や帰納法はこっちにも載っている．

はてなサマーインターン2019に参加しました

まとめ

はてなサマーインターンに参加しました

id:noy72 です．はてなサマーインターン2019の参加記です．

インターンとの出会い

1, 2年前に研究室の繋がりではてなに遊びに行ったことがありました．私が所属する研究室のOBがはてなにおり，そのOBの方から研究室の先輩，そして私に話が流れてきました．

その時にバイトやインターンの話を聞き，機会があれば行ってみようと思いました．

インターン選考

選考は Web申し込み→簡単なプログラミング課題→面接 の順に行われます．

Web申し込み

書類を書かなくて良いのはいいですね．

プログラミング課題

プログラミング課題はROT13でした．アルゴリズム部分での差別化はあまりできないと思ったので，基礎的な部分をきちんと抑えることを意識して ROT N (-1e9 \leq N \leq 1e9 ぐらい) といくつかのテストを書きました．

面接

面接はがっつり時間をとって行われ，十分すぎるほど話せます．インターンにおいて初めの学びがこの面接で，こちらの意見に対し，面接官の方が「意見の要約＋それについて良いと思う理由」を返すのが非常に印象的でした（勘違いだったら忘れて下さい）．とても話しやすかったです．要約することで相手の意見をきちんと理解していることを伝え，その上で感想を言う…… 見習おう，と思いました．

もし私がインターンの面接をまた受けるなら，今まで何をやってきたのか→なぜこのインターンに応募したのか→どのチームに配属されたいか・何をしたいか という流れを抑えると思います．今回の面接では失敗したので．

インターン

はてなサマーインターンでは講義パートの前半部分とチーム開発の後半部分に分けられます．そこで感じたことをつらつら書きます．

インターンの参加メンバー

インターンの参加者は自分を含め 8 人です．自分以外の7人，みんな強そうだと思いました（小並感）．

前半2週間

わからなかったら人に聞く

メンターの方がちょくちょく声をかけてくれるので質問がしやすかったです．また，インターンに割いている人数が多いため，質問待ちをすることがありませんでした．

密度が高い

課題には業務時間ほぼまるごとかかりました．業務時間中に暇になることなく，残業続きになることなく，ちょうどよい分量だと思います．用意されているオブション課題を全部終わらせるなら残業は必要そうです．自分は業務後，社員さんに混じって呑気にMTGのドラフトをしていました．

学ぶ範囲が広くて面白い

前半二週間で様々な講義が行われます．Web開発に必要な知識に加え，コミュニティについてや企画についての講義もありました．

成果発表について

想定していた全ての機能を実装することはできませんでした（MTGのせいではないはず）．経験のないフロントエンドでかなり詰まったので，全く知らない事に関してはどこかでちょっと触っておくといいかなと思います．

後半2週間

丁寧に教えてくれる

質問があれば丁寧に答えてくれるし，何もわからない状態であればペアプロをしてくれる．多くの時間を使ってもらいました．

開発に参加できた

何もわからない状態から始まりましたが，メンターやチームの方のサポートがあり何とか手を動かすことができました．

TDDとかテストとか

最初からTDDのようにテストを書いてから実装を進めればよかったんじゃないかと思っています．また，テストを読めばクラスや関数がどう使われているかがわかってコードが読みやすいんじゃないでしょうか．

誰か教えて下さい．

優しい

平和に過ごせました．ありがとうございます．

後半二週間で実際にやったこと

配属先はtomato3713さんと同じくmackerelチームで，ダッシュボードのウィジェットの開発をしました．私の担当はバックエンドで，scalaでAPIを生やしました．もっと手際よく開発したかった……

開発した機能の詳細はtomato3713さんの記事に任せます．

f:id:noy72:20190913120513j:plain:w500
こんなのです

2019/09/30：追記

アップデート情報にアラートステータスウィジェットが載りました． ヘルプも増えてる〜（当たり前）

mackerel.io

mackerel.io

思ったこと

時間は大切

学びたいことがあるなら時間のある時にたくさん手を出しておいた方が良い．

悩みすぎ禁物

全くわからないときは全くわからないことを伝える．よくわかっていない状態で何かするのは無駄．

日頃の行い

そこまで時間をかけてはいないけど，技術書を読むだとか，写経でWebアプリ作るだとか，Pythonでスクレイピングするだとか，Chromeの拡張機能を作るだとかで得た知識があったおかけで，インターンでは致命傷で済みました．

学ぶぞ！ という気持ちで新しいことに挑むのもいいですが，自分が必要に思う機能を小さくても良いから作ってみるということを普段から行うのも無理なく知識を増やせていいと思いました．

あんまり会社っぽくない……？

想像の会社とちょっと雰囲気が違いました．一部の社員の方から「サークルっぽい」「研究室っぽい」という声を聞いたので，やはり特殊なようです．ただ，東京オフィスは京都オフィスより会社っぽいとの話も聞いたので，はてなというより京都オフィスの特徴のようです．

おわりに

インターンに参加しようと思っている人へ：はてなインターンおすすめです．

インターンで会った人へ：どこかで会ったらボドケで遊んでください．

他のインターン生の記事

furutsuki.hatenablog.com

utgwkk.hateblo.jp

blondenamazu.hatenablog.com

ergofriend.hatenablog.com

10-1.hatenablog.com

tomato3713.hatenablog.com

https://lunastera.hatenablog.com/entry/2019/09/14/203053lunastera.hatenablog.com

『Clean Architecture 達人に学ぶソフトウェアの構造と設計』を読んだ

技術書 アーキテクチャ

https://asciidwango.jp/post/176293765750/clean-architecture
asciidwango.jp

ソフトウェアの構造や設計についてどう考えるかを書いた本．「どのように実装するか」が気になってきた人向け．個人的にはかなり読みやすかった．

詳細の決定はあえて先延ばしにする

ソフトウェアの設計と聞くと，割と詳細まで決めてしまうというイメージがあったけど，この本では「詳細の決定を送らせろ」と述べている．初めから完璧なアーキテクチャはないため，具体的な実装部分はあえて決めないという手法を紹介している．

本書では，あるソフトウェアのデータアクセスの方法を例に先延ばしについて説明している．まずはスタブを作る．スタブでは開発が進まなくなった時，RAMにデータを保存するメソッドを実装する．そして，永続化を考えなければならなくなった時，単にファイルに書き出すメソッドを実装する．具体的な実装を簡単に切り替えるようにしておき，必要になるまで実装しないことで，後から柔軟に変更をすることができる．

データベースを先に決めてしまったため面倒なことになるという失敗はつい最近起こしたばかり．具体的な部分を決めるのが早すぎるというのは初学者あるあるかも知れない．

境界線を引く

詳細を先延ばしにするためには，機能がきちんと分けられていないといけない．依存関係をきちんと整理し，ビジネスルールと具体的な実装を分離する必要がある．具体的な実装が分離されているから，必要になった時に置き換えることができる．

やっぱりバランスが大事

同じ理由・同じタイミングで変更されるコンポーネントのまとまりと，再利用しやすいまとまりが一致するとは限らない．どんな理由でもコンポーネントをまとめることは，インタフェース分離の法則のように「必要な部分だけつまめるようにする」ことに相反する．コンポーネントをどのぐらい分離させて何をまとめるのかは，上手にバランスを取らなくてはならない．

境界線を引くと言っても，もしかしたら引かない方が良いこともある．変更される可能性が高い部分は分離させておき，変更が起きにくい部分はまとめてしまうなど，柔軟に対応する必要がある．

『コーディングを支える技術 成り立ちから学ぶプログラミング作法』を読んだ

技術書

gihyo.jp

プログラミング言語の文法や機能を，言語の比較や歴史的な背景を用いて解説した本．個別の言語の知識は数年後も役立つかは分からないので，言語に依存しない普遍的な知識を学ぶ方がいいと著者は述べている．「何の言語を勉強すればいいですか」という質問の一つの答えになりそう．

「プログラミング作法」とあるけど良いコードの書き方の話ではない．

本書の対象者を自分なりにいうと，「プログラミング言語にはそれぞれ違いがあることを知った初学者」だと思う．静的型付け，動的型付け，変数のスコープ，継承，ミックスイン……などの概念をなんとなく知っている人なら内容を楽しく読めると思う．「この言語では，その機能をこうやって実現するのか」という新しい発見ができる．プロは「そうだね」っていいそう．

あるプログラミング言語を解説した書籍はたくさんあると思うけど，この本は機能という面から複数の言語の仕様を解説している．新しい言語を学ぶ際にも，本書のように複数の知識と結びつけるようにすれば，より効果的に，学べると思う．「プログラミング言語を1つ知っていれば，別の言語を学ぶときにその知識が使える」ということ．

というわけで，色々な言語を学んでみたいと思っている初学者が読んでみると面白いんじゃないかと思う．ただ，プログラミング初心者（プログラミングについて一切知識がない人）が読んでも意味がわからないと思うので注意．

面白かった章

11章　オブジェクトとクラス

少なくとも2人のオブジェクト指向言語の設計者が，「オブジェクト指向」という言葉を全く違う意味に使っています．特に，型と継承に関しては意見が逆向きです．（p.186）

クラスとは何なのでしょうか？この質問も一般的に答えようとすると泥沼にはまる，危険な質問です．(p.189)

この章では，「変数と関数を束ねて模型を作る方法」として，以下の4種類を解説している．

  • モジュール
  • 関数も変数と同じようにハッシュに入れる
  • クロージャ
  • クラス

「変数と関数が束なった模型」の表現方法が言語によって異なり，さらに役割も異なる．そして，言語ごとに「オブジェクト指向」という言葉が意味するものも異なる．

クラスとは，オブジェクト指向とは一体……うごごご！