ログ出力のための print と import logging はやめてほしい - Qiita
はじめに Python入門系の記事では概して、Pythonのロギング機能の紹介で最初にlogging.debug()といったloggingモジュール付属の関数を呼ぶ方法を案内しています。 Python本家が提供するloggingの「基本チュートリアル」でもこの点で大差ありません。Python本家の基本チュートリアルでは、print()関数を使用する方法もロギングの手段として有効であるとし、タスクに応じてprint()やlogging.debug()を使いわけよう、という流れで記述されています。 コマンドラインスクリプトやプログラムで普通に使う、コンソール出力の表示 : print() そのような「基本」の説明の後「上級」チュートリアルになってようやく、Python言語付属のロギングメカニズムの説明が始まります。「上級」では4+1種類のデータ構造が紹介され、ここで「基本」で多用されていたlo
Python で Slack API や Webhook を扱うなら公式 SDK（slack-sdk/slack-bolt）を使おう - Qiita
Python で Slack API や Webhook を扱うなら公式 SDK（slack-sdk/slack-bolt）を使おうPythonPython3Slackslackbotslack-api こんにちは、Slack で公式 SDK の開発に従事している @seratch と申します。 これから Slack の Python SDK について日本語のチュートリアルを書いていく予定で、この記事はそれらのエントリーページにしようと思っています。ご興味あれば、ぜひこの記事をストックしておいてください (良いと思ったら LGTM もぜひ） え！ Slack に Python 公式 SDK なんてあったの？ ・・と思った方も多いかもしれません。Python で Slack の Incoming Webhooks や Web API を使うとき、requests のような HTTP クライア
衰退が確定した国におけるプランB｜Taejun
経産省の「未来人材ビジョン」はとてもよく書けていて、日本の現状を突きつけるものだった。 https://www.meti.go.jp/press/2022/05/20220531001/20220531001-1.pdf 残念だけど、日本はすでに詰んでいて、今後も停滞が続くと個人的には思っている。僕がその見識を信頼する人たちも、大声では言わないけれども同じような意見だ。 なぜ詰んだといえるのか。いろいろな理由はあるけれども、一番深刻なのは高齢化と硬直的な人事制度だと思う。 社会に高齢層が増えることの一番の問題は「人は年をとると昔の自分より頑迷になる」という一般的事実に基づいている。これは高齢者攻撃の話ではなく、人間の脳は年齢とともに劣化するという事実の話だ。そして、人間はよほど自覚的でないと自分の脳の劣化には気づかない。より多くの頑迷な人が投票権を持っているので、政治は基本的にその人たちを
お悩みハンドブック
一人ひとりの悩みごとに合わせて適切な支援を案内するサービスです。あてはまる悩みにチェックをつけていくだけで200種類を超える公的支援を中心とした解決手段から利用できる可能性のある支援を提案します。
[Python]Poertyでプロジェクトのパッケージ管理をする
#HOMEで実行 $ cd # インストール $ curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python # poetryのPATHを通す $ sh $HOME/.profile # shellを再起動(source ~/.bashrcでもいいかも) $ exec $SHELL -l こんな手順で実行していきます。インストール後にできる「.profile」はbashrcにパスを追加するシェルスクリプトなのでそれを実行してパスを通しています。「cat .profile」とかやると中身みれます。 ↓インストール時のスクショ Poetry適用のプロジェクトを作成する 方法1(init) カレントディレクトリに、poetryで使うパッケージ管理ファイルのpyproj
![[Python]Poertyでプロジェクトのパッケージ管理をする](https://cdn-ak-scissors.b.st-hatena.com/image/square/c3548f3044df41a8b116a7c976f5998d9914ee5e/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--3N7BgCgB--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BPython%25255DPoerty%2525E3%252581%2525A7%2525E3%252583%252597%2525E3%252583%2525AD%2525E3%252582%2525B8%2525E3%252582%2525A7%2525E3%252582%2525AF%2525E3%252583%252588%2525E3%252581%2525AE%2525E3%252583%252591%2525E3%252583%252583%2525E3%252582%2525B1%2525E3%252583%2525BC%2525E3%252582%2525B8%2525E7%2525AE%2525A1%2525E7%252590%252586%2525E3%252582%252592%2525E3%252581%252599%2525E3%252582%25258B%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AWT%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzg3Mzc2NDYzMjYuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
共通化すれば良いとは限らない - Object.create(null)
ここのところ偶然なのか「共通化」という言葉を多く聞いているのですが, その言葉を聞くたびに身構えていることに気がついたので, この気持ちの出どころを共有しておきます. なぜ身構えているかというと, 共通化が必ずしもコードを良い状態にするとは限らないにも関わらず, それ自体が目的になってしまっている (ように見える) ことが多いからです. この手のリファクタリングの目的はあくまでコードの改善のはずで, そのことを忘れて共通化するだけで満足してしまうと, 良くてリファクタリングの効果が半減, 悪ければ逆効果になってしまいます. 個人的にコードを共通化する上で注意してほしいと思っているのは以下の二つです. コードを共通化すべきでない場合もある 共通化されたコードは一般的な原則にしたがって設計されなければならない 似たようなことは歴史の中で何度も繰り返し言われていることだろうと思いますが, 改めて
FirefoxでYoutube見続けるとSSDが早死にする問題とその対処法
FirefoxでYoutubeを見続けるとどうなるか タスクマネージャを開いてFirefoxでYoutubeを見てみると、おかしいことがわかります。 動画を見ているだけなのにSSDへの書き込みが連続して発生するのです。 試しに後述のabout:configでbrowser.cache.disk.parent_directoryでキャッシュの位置をUSBメモリなどにしてみるとよくわかります。 またキャッシュされた内容はアドレスバーにabout:cacheと入力すると確認できます。 そしてわかったこと。 なんとFirefoxはYoutube動画をすべてディスクキャッシュとしてため込んでいるのです。 動画なんて何度も見ることは少ないのでキャッシュする意味は少ないはずです。 これではSSDの書き込みが延々と発生し、SSDの寿命に影響が出そうです。 Firefoxのキャッシュの仕組み アドレスバーに
Detach (move) subdirectory into separate Git repository
I have a Git repository which contains a number of subdirectories. Now I have found that one of the subdirectories is unrelated to the other and should be detached to a separate repository. How can I do this while keeping the history of the files within the subdirectory? I guess I could make a clone and remove the unwanted parts of each clone, but I suppose this would give me the complete tree whe
Rustのスレッドとチャネルと共有メモリの話
この記事ではRustのスレッドとチャネルについてご紹介します。最後に共有メモリについても少しだけ触れます。対象としてはgolangを書ける程度の中級者レベルを想定しています。 公式ドキュメントについて Rustの公式ドキュメントはとても良く書けており英語の勉強にもなります。プログラミング・チュートリアルは圧巻ですのでぜひ原文で読んでみてください。 スレッド RustのスレッドはOSスレッド(1:1 threading)になります。GolangやJavaはグリーンスレッドです。 This model where a language calls the operating system APIs to create threads is sometimes called 1:1, meaning one operating system thread per one language thr
[追記４（最後）あり]なんでみんな外航船員にならんのか。
外航船員として数年働いてるんだけど、なんで皆ならんのかわからん。 商船大学に入るのはそこまで難しくないし、就職難易度もかなり低い。（機関士なら普通大学から中手企業行くくらいの努力で大手の日本郵船とか商船三井行けると思う） 乗船期間は半年から8か月がデフォでちょっと多いけど、その分休暇は3,4か月がデフォで、多いときは5か月とかもらえるときもある。 最近はまずないけど、乗船期間めちゃくちゃ長くなる時は12か月とかある。それ以上は労働条約を理由に船止められたりするリスクが発生するから伸ばされない。 乗船中の給料は大体倍だから初任給で額面50万近く行く。休暇中も基本給は必ず出るから、寝てるだけで金が入ってくる。 俺のいる会社は人も少ない中小企業で、給料はもちろん大手よりは安いけど1年目とかの年収は600万余裕で超えたわ（乗船期間は長かったけど） 今年は海運ボーナスどこもいいから、1年目の子でも8
![[追記４（最後）あり]なんでみんな外航船員にならんのか。](https://cdn-ak-scissors.b.st-hatena.com/image/square/b1638cdb5807a4788e4ba3c1109a984166e095fc/height=288;version=1;width=512/https%3A%2F%2Fanond.hatelabo.jp%2Fimages%2Fog-image-1500.gif)
プログラマの心の健康
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
ここがつらい！ Slack API - Qiita
半分ネタ記事です。あんまり真面目に書きません。 項目数が多いので，気力でなんとか書きます。分類は諦めます。 他にもある！っていうのがあったらコメント欄で教えて下さい。気が向いたら追記します。 公式の TypeScript 型定義がもはや型定義を諦めている 辛い度: ★★★★★ 辛い中でもこれはかなり上位に来るやつ。 こちらに OpenAPI 形式で仕様が定義されていて， https://github.com/slackapi/node-slack-sdk/tree/main/packages/web-api/types ここに仕様に基づいて TypeScript の型定義ファイルが吐かれるようになっています。 Git 管理されていないので，実際のリリースを見てみましょう。 https://unpkg.com/@slack/web-api@6.7.2/dist/response/Reacti
【MLOps】「いつか使いたい！」と思っていた人のためのMLflowまとめ - Qiita
MLflowとは？ MLflowは機械学習のライフサイクル管理（MLOps）を目的としたライブラリで、主に実験管理用途で使用されることの多いツールです。 実験管理とは、 ・使用した学習器や学習データ、ハイパーパラメータ等のモデル作成条件 ・そのモデルを評価して得られた評価指標 のセットを記録し、複数条件の比較を行うことで最適なモデル選定を行う工程です。 このような条件記録はExcel等での手入力が一般的かと思いますが、 「手入力は時間が掛かる！」 「手入力をミスして苦労して集めた結果が信頼できなくなった」 という経験をされた方も多いかと思います 上記のような経験から、MLflowにより実験管理を自動化すれば、多くのメリットが得られることはイメージが付くかと思います。 MLflowは2018年リリースの比較的新しいライブラリですが、GitHubのStarは既に1万を突破しており、下図のように
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
脳細胞に咲く「毒の花」がアルツハイマー病の真の原因と判明！ - ナゾロジー
私たちはとんでもない勘違いをしていたのかもしれません。 米国のニューヨーク大学（NYU）で行われたマウス実験によって、長年アルツハイマー病の原因と考えられてきたアミロイドベータの蓄積は、真の原因が起こした副次的な結果にすぎない可能性が示されました。 研究ではアミロイドベータが蓄積するより「かなり前」の段階で、既にマウスの脳細胞が麻痺状態にあり、「毒の花」と呼ばれる異常な構造が発生している様子が示されています。 アミロイドベータを排除するように設計された薬がどれも効果を発揮できていないのも、真の原因となる「毒の花」を見過ごしていたいたからだと考えられます。 認知能力を蝕む、美しくも恐ろしい「毒の花」の正体とはいったい何なのでしょうか？ 研究内容の詳細は2022年6月2日に『Nature Neuroscience』にて公開されました。
Rust初心者殺しの文法10選 - Qiita
概要 この記事ではRust初心者が驚いたり混乱させられたりするようなRustの文法を10項目集めてみました。 これらの項目は知らないと理解できなかったりコンパイルエラーに悩まされたりする一見厄介なものたちなのですが、そのような直感的でない挙動を敢えてさせているところには重要な意味が込められていることが多いです。 そのため、これらの項目を通してRustが目指しているものや実現したい機能の一部を垣間見ることができると思います。 1. デフォルトの代入がムーブ Rustの最大の特徴が所有権の概念であることは有名ですが、それでもなお初心者殺しになるのがムーブです。 以下のコードがコンパイルエラーになるメジャーな言語は現状Rustくらいしか無いでしょう。 let mut a = vec![1, 2, 3]; let mut b = a; // ここでaの持つベクタの所有権がbにムーブされ、aは無効に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報セキュリティ10大脅威 知っておきたい用語や仕組み｜IPA
テクニカルライティングの基本
NDLイメージバンク | 国立国会図書館
