Sand box on the shoulder

今や、プログラミング開発に欠かせない存在となったGit。上司や同僚から「修正版をブランチ"devlop"にプッシュしたから、それを反映させてね」「安定版はタグ”v1.2”だから、よろしくね」と言われることもあるでしょう。その時に「どうやってブランチやタグって変えたらいいかわからない」「そもそも言われたブランチやタグが見当たらないんだけど…」となったら、とても困ってしまいます。そんなときにどうしたらいいか、本記事では Sourcetree を使用している環境を想定して、おすすめの手順を紹介します。環境によって具体的な操作は異なるものの、手順自体は一緒です。基本的には、 フェッチ(fetch)をしてリモートリポジトリをちゃんと確認 すればよいのです。 1. コミットしていないファイルをなくそう まず、Sourcetreeのコミット一覧に「コミットされていない変更があります」とあるかどうか確認します（下記図赤下線参照）。「コミット」の箇所に青マークでコミットされてないファイル数も表示されます（下記図赤枠参照）。その変更をコミットするか、破棄するかを行い、コミットされていない変更がない、きれいな状態にしましょう。そうしないと、後の作業中にエラー等が発生して進まなくなってしまいます。 2. フェッチしよう フェッチとは、 リモートリポジトリの最新の履歴の取得だけを行う 操作です。これによって、自分から見えていなかったブランチ・タグが見えるようになります。ブランチへのマージが伴うプッシュやプルと異なり、単に履歴を取得するだけなので、意図しないコミットが発生しません。安心して実施しましょう。Sourcetreeでは下記図赤枠部分をクリックすれば、フェッチを行うことができます。 その際出てくるポップアップで「すべてのリモートからフェッチ」「全てのタグを取得」をチェックしてください（下図赤下線参照）。 3. 目的のブランチ・タグを見つけよう 目的のブランチ・タグを見つけるのに便利なのが、Sourcetreeの左側領域にある「ブランチ」「タグ」「リモート」「スタッシュ」です。目的のブランチを探したい場合は「リモート」をクリックして現れる「origin」をさらにクリックしましょう。これでリモート上にあるブランチの一覧を見ることができます。タグの場合は「タグ」をクリック

日本卸売電力取引所（JEPX）が市場取引を開始したのが2005年4月、東日本大震災を契機とした電力システム改革が実施されたのが2015年から2020年にかけてです。このように電力事業の規制緩和が進んでいる中、実際に電力市場の取引量がどれくらい増えたのでしょうか？ 現在の電力市場の状況がわかりやすくまとまっているのが、経産省の 電力・ガス取引監視等委員会 で定期的に開催されている 制度設計専門会合 です。月１程度の頻度で実施されており、３ヶ月に１度「⾃主的取組・競争状態のモニタリング報告」という報告書が公表されています。最新の 令和３年4⽉〜令和３年6⽉期の報告書 に記載されている電⼒需要に対する市場取引量の推移グラフを以下に示します。 図より、 2017年くらいから一気に増えて、2019年位から40％前後を推移 していることがわかります。すでに電力需要の半分近くの量が電力市場を介して取引されているんですね。 それでは、2017年から一気に市場取引が増えた理由はなんでしょうか？それは、2017年4月から実施された 「グロス・ビディング（gross bidding）」 にあります。グロス・ビディングとは、旧一般電気事業者の社内取引分の一部をスポット市場を介して取引するように変更することです。その結果、上記の図のように市場取引量が一気に増加しました。 グロス・ビディングは市場の流動的向上、価格変動の抑制や透明性の向上を期待されて導入されました。 2021年8月の報告書 では市場の流動的向上、価格変動の抑制に関しては一定の効果を得られたが、透明性の向上に関してはまだ不十分であり改善の余地があると報告されています。 参考URL JEPX ( http://www.jepx.org/index.html ) 電力・ガス取引監視等委員会 ( https://www.emsc.meti.go.jp/ ) 第65回 制度設計専⾨会合 事務局提出資料 「⾃主的取組・競争状態のモニタリング報告（令和３年4⽉〜令和３年6⽉期）」( https://www.emsc.meti.go.jp/activity/emsc_system/pdf/065_10_01.pdf ) リム情報開発 「グロスビディング」（ https://www.rim-intelligence.co.jp/glossary

Pythonのコーディングを進めていくと、改行の位置や空白の置き方などに一定のルールに従って記載したくなってくるかと思います。特に多人数で共同で開発を進める場合、それぞれが独自のルールと感性でコーディングをしていきますと、フォーマットがバラバラになってしまいます。この違いは他の人のコードを確認するときのストレスの元になってしまいます。 その問題を解決する方法の一つに 「コーディングルールを決める」 という手段があります。このルールに則っていたら、大丈夫、もう文句は言わない！という決め事をしてしまえば、もうその事で言い合いになる心配はありません。プロジェクトの目的そのものに集中することができます。Pythonには PEP8 という一般的に用いられるコーディング規約があります。多くのコードがこのPEP8に基づいて作成されています。このPEP8に則っているかどうかをチェックして、自動に整形してくれる フォーマッター がPythonのパッケージとしていくつか公開されています。その中で、筆者が一番オススメなのが " black " というパッケージです。 Pythonのコンソール上で、 整理したいファイルのあるディレクトリに移動し、以下のコマンドを実行してみましょう。 black . これで、現在のディレクトリ以下にある全てのPythonファイルを自動で整形してくれます。blackは他のフォーマッターと違って、元となるPEP8よりも厳しいルールを用いており、オプションでもそのルールをほとんど変更することができない、という特徴を持っています。もともとPEP8は結構融通の効くルールなので、どうしても人によって書き方がバラけてしまう、という問題があります。それならば、ガチガチに固めてしまいましょう、という思想のフォーマッターです。そこまでコードの綺麗さにこだわりがない筆者にとっては、余計な事を考えずに全てのコードの形式を統一できるので、非常に助かっています。 「コマンドが見つかりません」と表示されて実施できない場合 blackがインストールされていない環境のようです。環境管理にpipを用いている場合は、以下のコマンドを実行してみて、現在の環境にインストールされているパッケージを確認してみましょう pip list リストの中にblackがない場合、pi

科学計算のためにPythonを実施する際にとても便利な環境がAnacondaです。多くの方々が利用しているかと思います。しかし、せっかく作成した環境にどんどんとパッケージをインストール、アップデートしていってしまうと、依存関係がわからなくなってしまい、他の計算機で環境を再現できなくなってしまうこともあります。 そうなることを防ぐために、環境設定ファイルをしっかりと作成・管理して、だれでもどこでも仮想環境を再現できるようにしましょう。本記事では、初心者でも利用できるようにCUIではなくGUIであるAnacnoda Navigatorで環境設定ファイルから仮想環境を作成する方法を紹介します。 1. 環境設定ファイル(yamlファイル)を用意する 環境設定ファイル「env.yml」の記述例を以下に示します。ファイル名は任意で大丈夫ですが、拡張子はymlとしておきましょう。 name: test-env channels: - defaults - gurobi dependencies: - python=3.8 - gurobi - spyder - pandas - openpyxl "name"は仮想環境の名前です。この環境を使う目的など、わかりやすい名前をつけましょう。日本語だと上手に反映できない場合がありますので、基本、アルファベットでつけましょう。 "channels"ではパッケージのダウンロード元となるチャンネルを指定します。多くのパッケージは”defaults”が書いてあれば問題ありませんが、特定のパッケージは特別にチャンネルを指定する必要があります。使用したいパッケージがどこからダウンロードできるか、確認しておきましょう。 ”dependencies”は、この環境にインストールしたいパッケージを指定します。基本的に最新版をインストールしますが、バージョンを指定したい場合には、パッケージ名の後ろに"="をつけて、バージョンを指定しましょう。 この環境設定ファイルを作成したプログラミング毎に管理するようにしましょう。プログラミング１つに対して１環境です。プログラミングをGitで管理している場合は、環境設定ファイルをGitの追跡対象に追加することで、自然に一緒に管理すること

 以前、 SourceTreeを使って、GitHubのプライベートリポジトリにアクセスする方法 を記事にしました。その際、プライベートリポジトリからクローンできても、プッシュできない！という現象に遭遇するときがあります。下記のように、”そんなリポジトリは存在しないよ”というエラーが表示されます。 remote: Repository not found. もし、そのリポジトリがOrganaizationに属するものならば、 あなたのアカウントの権限が”Read”のみで、”Write”になっていない 可能性があります。権限に関してOrganaizationの管理者に確認してもらいましょう。 管理者がどういうルールで権限を決定しているのかによって、対応が変わるかと思います。一番手っ取り早い対応は、全てのメンバーのデフォルト権限を”Write”に変えてしまえばよいでしょう。Organaizationのページの右上にある「Settings」をクリックし、左に表示されるメニューから「Member privileges」を選択します。すると、左下のような画面が表示されますので、赤枠で囲っている「Base permissions」のプルダウン部分を"Write"に変更してください。 その他に、リポジトリ毎にアクセスできるメンバーを管理したい場合もあるかと思います。その際にはリポジトリの「Settings」→「Manage access」を選択し、設定等を変更してください。

 Pythonファイルの冒頭に書かれるimport文ですが、表記順をどうしようか、迷ってしまうことはありませんでしょうか？そんな時に簡単に整理してくれるのが" isort " というコマンドです。Pythonのコンソール上で、 整理したいファイルのあるディレクトリに移動し、以下のコマンドを実行してみましょう。 isort . これで、現在のディレクトリ以下にある全てのPythonファイルのimport文の順番を綺麗に整理してくれます。順番はPythonコードのコーディング規約 PEP8 のルールに則て整理されます。 import 文 は次の順番でグループ化すべきです: 標準ライブラリ サードパーティに関連するもの ローカルな アプリケーション/ライブラリ に特有のもの 上のグループそれぞれの間には、1行空白を置くべきです。 さらに、isortではグループ内の順番はアルファベット順に整理されます。これでもう迷いませんね。 「コマンドが見つかりません」と表示されて実施できない場合 isortがインストールされていない環境のようです。環境管理にpipを用いている場合は、以下のコマンドを実行してみて、現在の環境にインストールされているパッケージを確認してみましょう pip list リストの中にisortがない場合、pipを使ってisortをインストールしましょう。下記のコマンドでインストールできます。 pip install isort Spyderで実施したい場合 Python用の総合開発環境Spyderでも、コンソールがありますので、isortを実施する事ができます。ですが、Spyderはデフォルトでは対話式シェルIPythonで起動されるので、そのままでは実施できません。下記のコマンドで実行する必要があります。 !isort . 先頭に"!"をつけることで、システムシェルでの実行に切り替えることができます。 対象ファイルを指定したい場合 整理を行うファイルを指定したい場合には"."の代わりに、ファイル名を入力します。 isort file.py 整理されるファイルがあるか確認したい場合 オプション"-c"をつけることで、順序ルールに違反しているファイルがあるかどうかチェックを行い、表示し