ナビゲーション

2914/12/31(月)ご案内

IT系の情報まとめです。

主に実務でアレコレやった備忘録とかガチャガチャ遊んでみたものを置いてます。
データベースブログとして使っているので、専門性の高いものはナビゲーションに、
そうでないものはタグに配置しました。

ご案内

ナビゲーション

専門性が高い記事を扱います。
戻る
ポータルサイトへ戻ります。
テクニカル×マガジン
ここです
Linux救急箱
UbuntuとCentOSがメイン。他にも色々さわるかも
開発日誌
アプリケーション関連でよく忘れたりするのでコマンドから書いてます
エンジニアのおもちゃばこ
ツール沼ご用達のアイテムがいっぱい!
初心者AWS
私が初心者!って言いたいだけのAmazon Web Service奮闘記
(非公式)Users's マニュアル
昔書いてたadiary Ver3.x系のオレオレマニュアル。チートシートとも

タグ

後で振り返りやすいようにざっくり分けてます。
多くなったらナビゲーションにスピンアウト!
使い方
このサイトの使い方です
ハード
マイコンとかそういう話はFPGAとかで扱うかもしれない
mapr
ビッグデータを扱うのに超便利!だけど結構クセが強いので超大変!
ポートフォリオ
サイト作りの時に参考にしたいレイアウトやスクリプト等
ツール
スピンアウトしました。エンジニアのおもちゃばこ

筆者


中の人について

2018/11/29(木)pythonのロギング界隈が恐ろしすぎてLoggerやらloggingを使うのがこわいから何と言われてもprintしか使わない

どこもかしこも
ログの階層構造の説明だの、複数ファイルで出力するときの方法だのなんだのと。
説明が冗長……とは言いませんが、詳しすぎて初心者にはきつかったです。

いや、ログのレベルの概念は理解してますねん。

pythonでのログの書き方を知りたいだけですねん。

そういう気持ちを形にしました。
とりあえず使えりゃ良いんだよ使えりゃという雑なpythonログ出力実装メモ - Qiita
っていう私のようなユーザーのための記事です。
更に低レベル…というとこの界隈だとスキルではなくレイヤーの話をされちゃうので注釈しますが、私が言いたいレベルとはQiitaに書くと噛みつかれた上に袋叩きにされそうで、そういう反応が初心者を委縮させてしまうんだぞ、って言いたいのです。
こんなことは恐ろしすぎてQiitaには絶対書けません。

QiitaやTeratailでもそうなんですが、間違っていたら諭してください。
鬼の首を取らんでください。
Microsoftのメッセージによるサポートセンターの姿勢なんて神ですよ、ああいうアプローチが出来ないのか?と私はいっつも思ってるわけです。
(対応内容自体には触れません)

間違ってる情報を出すな、正しくあれ!ってlogger,logging警備隊が白バイを飛ばすので居心地が悪くなってQiitaに記事を書くのに体力が要るとか言われるようになります。
発信したもには責任とれよオメーっていう気持ちは分かりますけど、識者でもなければ鬼の首されるのはたまらん。

事の発端

以下を読む場合の注意
この記事を記述している筆者はPythonのコミッターといったほどのPython知識を持っているとは言えません (初版公開時点でもそうでしたし、リバイズした時点でもそうです)。内容に誤りがある場合には是非ご一報ください。

また「筆者自身がloggingモジュールを知ってからもしばらくの間、チュートリアルすらきちんと読んでいなかった」という、本来なら筆者個人の問題とみなすべき事実も、この文を書くきっかけになっています。内容が一部「初心者の遠吠え」に見えなくもないところもドキュメント側の問題であると少し前のめりになっている点、ご容赦ください。
ログ出力のための print と import logging はやめてほしい - Qiita
とある通り、私もこの筆者さんと同じポジションで記事を書くことにしますが、私はloggingのプロではないことを明記しておきます。
右下にフキダシアイコンがあるので、マサカリはそちらへ。
匿名でもマサカリ投げ太郎ができます。イタズラ防止のためIPだけ取ってますので、特定のユーザーがバシバシ連投してたらブロックするぐらい…*1


なお、業務コードにはloggingをガツガツ活用しています。
これがないと保守もテストもつらいです。
運用時はともかく公開時はそういったものを削除しています。
デバッグのためのコマンドが残っている場合、見えざるTODOになってある意味管理がしやすいという面も含んでいます。
(だからこそオレオレraise関数を作ったのですが)

*1 : そんな暇な人を知らないですが

言及せざるをえなくなった

厄介なことに、これからkillする予定のプロセスの状態を保持して管理できるようにしろ、というオメー何言ってんだみたいなお話に対応する事に。
そもそもなんでkillする予定があるんだふっざけんな!ってキレたいんですが、なんかすごい運用をするというのだから私には何も言えない…

ということで、PythonのマルチプロセッシングをCtrl+C前提でコードを組むという意味わからないノウハウが蓄積していくことになりました…

私見ですが、どう考えても設計ミスです。
C++とかGolang?メモリアドレスいじれるやつでやってくださいってハナシなんですが、とりあえずここでは置いておきます。

ソースコード

解説、要りますか?

concurrent.futures.process.ProcessPoolExecutorのparamsが[[ここにスレッドへ,渡したいのを,ずらずら], [同じ,よう,に,ずらずら]]...
len([ずらずら]) == len([ほかずらずら])さえ満たしておけばおっけーです、同じ事はできます。
len == としたくない場合はparamsのリスト内タプルにlambdaを送り付けましょう。
ProcessPoolExecutorが呼び出せる関数は共通して1つなので、関数にlambdaで関数を送り付けてその中で実行を可変にしてやるという黒魔術を使えば違う処理を並列実行できます。

これは本当に黒魔術です。
便利ですが多用は厳禁。
間違いなくテスト業務担当とか他の開発メンバーあるいは運用者からヒンシュクを買います。
私ならキレる。

2018/11/12(月)gitlabのコントリビューションが想像以上にきっついハードルだった

gitlab.PNG


githubと違って誰も評価してくれない(社内で使っていてもほとんどの場合評価の対象にならないという意味)上にこの基準!
業務で使ってんだからバシバシ上げてけよっていう話ですかね?
これでgit rebase+squashでcommitログを圧縮しろって制約まであったらもうやってられない。
新規に入った人だと1日1コミットですよ、ボコボコにされますね。

github就活の時も言ったけど、あんまり基準にしすぎない方が良い気がしてきました。
どうしてもgithubを評価したいならコミットログ見るよりリポジトリやイシューなどを見るべきです。
githubを使うためにgitの知識ばっかり入って、本来の業務であるはずの担当区分に手が回らなくなるなぁ、と使っていて本当に思います。
githubの運用コマンドをまとめていて本当に思いました。

gitのコマンドのための業務なんてムダ!

運用コマンドについて

現場でgit rebase運用をしている方からのコメントが欲しい。
前提条件としては、shいっぱつでどんなケースでもいい感じにpushしてくれる方法!
ユーザーがgitコマンドなんて覚える必要はない、という思想です。
また、このgit_rebase.shはCircleCIとかJenkinsから呼ばれる想定をしていますが、実運用は手入力で実行しています…。

2018/11/12(月)ローカル開発環境構築を3大要素に分けて超簡単に解説する

ご無沙汰してます、もうやってやりましたよ感すっごい
Windows10 Pro 64bitに変えて、他のハードは変えないままでこのような環境構築をしました。
すべてUbuntu18.04です。
Raspberry PI3 ModelB+
物理環境なのでセンシングができる。圧倒的スペック不足。gitlabが動かない
Windows Subsystem Linux
Dockerコンテナを作成する点でも問題あり。ほか純正システムと異なる点が多数
Hyper-V
正しく環境構築をするなら必須。Docker for WindowsやVagrant+VirtualBox、あるいはVMWareなども含む。
Hyper-VにしたのはWSLをVSCodeの開発用にしたかったからです。
なぜここまでやったかわからないですが、Windows7 HomeEditionで開発環境ほっしーなーって言ってたあの頃はもうどこかへ消え去りました。
今では非常に満足しています。

2018/11/08(木)[certbot-auto] nomuraya.workで無料で発行したSSL証明書の期限が切れたので更新 [Let's Encrypt]

私の環境がDebian/Ubuntu系なのでapache2, aptで書いてますがCentOS系だとhttpd, yumに読み替えてください。
導入はSSL証明書の認証エラーについて、解決した方法と解説を参照してください。

自動化も考えていたんですが、当時無料・有料SSLの違いが分からなかったのでとりあえずやってみて情報を集めてみようと思ったところから。
とはいえ、調べても運用してもSSL認証局*1が発行したものと比べると「アンタのサイトは大丈夫なん?」って証明と「このサイトは大丈夫ですよ」って言ってるCAを疑い始めるとか、一般ユーザーはほとんど気にしないんでなかろうか?

っていう点では、私のサイトは私が守って私がしっかり管理してるので(私にとっては)問題ないってことでオレオレ証明書にしてます。
発行している人間が信用できるかどうか、っていうぐらいかなぁ。

なんで自分のサーバーを守るために作った自己の証明書が偽物だと言わねばならんのか、という話ですね。

*1 : CAと略される事が多いです。Certification Authority

コード

cd (certbot-auto)
sudo chmod +x ./certbot-auto
sudo ./certbot-auto renew --post-hook "sudo service apache2 restart"
これでまた3ヵ月、使えます。
切れてしまっても今日みたいに再度実行すれば3ヵ月使えます。

2018/11/02(金)DBなどの接続設定をdictで渡したい時にアスタリスクでunpackが便利らしいのでチートシート作った

事の発端

DB接続で細かいパラメーターの設定をユーザー側(関数の利用者)にぶん投げたい、と思っていたところでした。
必須パラメーターだけバリデートして後は知らん、っていうスタンス。
pythonなら辞書型のアンパックを使えばいい感じらしい、という事だったんですが、よく考えたらこの辺りをちゃんと利用した事なかったなぁ、と思ってチートシートを作りました。

続きを読む

2018/11/02(金)python3を実行したらprint()ですらコアダンプで中止されてしまう

Fatal Python error: _Py_InitializeMainInterpreter: can't initialize time
OverflowError: timestamp too large to convert to C _PyTime_t

Current thread 0x00007f92ee830700 (most recent call first):
中止 (コアダンプ)
[問題のログ]
なんだこりゃ?
ログがこんなんじゃ原因が調べようもないです。
dateが悪いのか?と思ってprintだけのファイルを作って再実行。
致命的なPythonエラー:_Py_InitializeMainInterpreter:時間を初期化できません
OverflowError:Cに変換するには大きすぎるタイムスタンプ_PyTime_t

現在のスレッド0x00007f92ee830700(最新の呼び出しを最初に実行):
中止 (コアダンプ)
[問題のログを日本語に]
変わってない。
python自体に問題があるとしか思えない…

環境

python3.7.0です。
python2.7.15は動いているので、なんか弄ってしまったのかも知れません。
開発環境なのでとりあえずapt updateをしているので、pythonの何かしらを触ってしまった可能性があります。
直に投入→pyenv→brew→brew pyenvと、もう自分でも何やってんのか分からないぐらい環境を汚してしまっているので、新しく環境を作り直した方がラクな事も。

特にWSLを使っている場合、wslconfigで起動する環境を変えてしまう手があります。

wsl.png

wslconfig.PNG


[(access failed) https://news.mynavi.jp/article/20171129-549523/]

この場合、
wslconfig /s Ubuntu-18.04
のような形で変更できます。
変更後、wslconfig /lで確認することをお忘れなく。

本当は直接起動するファイルを求めたいんですが、どこにあるか分からないのでいったんこのような形でfixさせます。

経験上、よく分からないものを無理に直そうとすると余計におかしくなるので、環境を捨ててしまうという決断はありだと思います。
参考:linuxbrewのインストール手順

2018/11/02(金)github submodules地獄から脱獄しよう。強力すぎて逆に使いにくいgitコマンドをルール化する

このコマンドリストを作って、ますますgitが嫌いになりました。

git自体は便利だし、githubをバリバリ使いこなしてますよ感を半端なく出しているので、見た目にはgithub大好きな人みたいに見えますが、あれは仕方なく使っている面が非常に強い。
運用中、gitコマンドなんて気にしたことないし、打ち込んだ履歴もない。
ただ単純にupdate.bshとpush_submodules.shの2つだけをガシガシ打ち込んでいるhistoryがズラリと並んでいるぐらいです。
当初はVSCodeで運用していたんですが、VSCodeはgit submodulesを考慮していないんですよね。
VSCodeだけでなく、gitがメインですよっていうツールでもないとgit submodulesなんて考慮してくれないんじゃないかなと。

考えてみれば当たり前だなぁ、とやってて気付いたんですが解説されないと絶対わからないわコレ。
試行錯誤してて1日に50回pushするとかいうとんでもない状況がログにありますが、まともに開発して出てきたんじゃなくてgit submodulesで苦しめられた結果があのログです。

もうホントにgit嫌いです。

続きを読む

2018/10/31(水)Python4は出ないのか?

原文
403 Forbidden
訳文
Python 3誕生の理由 ― つまり、なぜunicode/str/bytesの仕様は変更されたのか | POSTD
そろそろpython2-3がそれぞれに抱える問題点をキレイに解決できないとpython自体がダメな言語扱いされそうな気がしていて…。
この1年、本気でpython(Cpython、PIPy含め)を使ってきてますけど、機械学習のため、という目的ありきでもない限り学習メリットが低い言語であるように感じられて仕方がありません。

事の発端

先日、職場でPython2かPython3か、機械学習をメインに話題となったからです。
本音と建て前、とは言いますがブログなんで好き勝手に。

原因を見直す

機械学習でpython2を使う事が多いのでみんなpython2に残り続けている現状がある今、python3が3.6.6と3.7.0*1で若干アーキテクトが異なっているのか、必要なモジュールが増えました。
python2で使えるものがpython3では使えない、という話が多々あるため、python自体が問題児であることは変わらないのですが。

*1 : 執筆時点の最新は3.7.1

Python4について

[(access failed) https://www.curiousefficiency.org/posts/2014/08/python-4000.html]

コメントを見てるとすごいですね、
なんだかんだで期待はされているのが分かります。

python4を待つべき?あるいはこれから学びなおすなら言語は?

先に私の方針を述べておきます。
実践で使われている言語と、最近出始めた採用者が少ない流行りものと2つ抑えておくべきです。

Web系かインフラかにもよりますが、前者だとSwift, KotlinとJavascript(node)、必要な範囲でJava系、
後者だとC++,golang系とpython(2)を真面目に推したい。

前者は案件依存、後者はLinux依存です。
python2は機械学習の必要に迫られるためです。

なお、Web系の人もいずれインフラを知らないと開発が困難になるので、Dockerぐらいは知っておいていいと思います。
OK キャンセル 確認 その他