サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
円安とは
qiita.com/tonluqclml
1970年頃のホンダでは、エンジンの冷却方法について激しい対立が起きました。 熱力学的には水冷の方が合理的ですが、創業者社長の本田宗一郎は空冷にこだわりました。 宗一郎曰く: 「砂漠の真ん中でエンストしたときに水なんかあるか!空冷だ」 「水冷だってラジエーターを空気で冷やすんだから、最初から空冷のほうが合理的」 実は、宗一郎には、過去に水冷エンジンを開発した際、液漏れに非常に苦労した体験がありました。空冷なら信頼性が高いだろうというわけです。 しかし、宗一郎肝いりで開発した空冷エンジン搭載の「ホンダ・1300」は商業的には失敗してしまいます。 宗一郎は副社長の藤沢武夫に諭され、技術者としての限界を感じていたのもあり、社長を退任します。 以後、ホンダの四輪車は水冷エンジンを採用します。 過去の苦労に囚われる レジェンド・本田宗一郎と比べるのは恐れ多いのですが、ソフトウェア開発の現場でも過去の
某所で見かけたシステム運用作業手順書の記事に、「作業直前に作業手順書の変更はしない」「手順書に無い作業をしない」といった事が書かれていました。 いや、それはあくまで心掛けの話であって、それも大事だけど、そもそも作業手順書はどうあるべきかという話が抜けおちているのではないか?それは世間ではあまり明文化されていないのではないか?と思いました。 不遜ながら、私が思う作業手順書のあり方を書いてみます。 1. 存在している まさか、本番作業を勘とノリでやっちゃうなんて。まさかね… 2. 保存されている Githubでも、Google Driveでも、Notionでも、Wikiでもいいですが、作業手順書は保管されていますね?えっ?保存していなかったら、同じような作業をもう1回することになったらどうなるんですか?障害が起きて、デプロイ手順に問題がないか調査したい時にどうするんですか? なお、保存するなら
「取り返しのつかないことをしない」 昔、同僚と議論していて口走った言葉です。実はプログラマーとしてわりと重要な考えなのではないかと思います。 例: EC2のパブリックIPをスマホアプリに直書きする スマホアプリ向けの静的ファイルやバックエンドAPIをAWSに実装した際、最初はスモールスタートだと言うことでEC2インスタンス1台の構成にしたところまではいいが、インスタンスに自動で割り当てられるIPアドレスをスマホ側で直接参照する実装にしてしまった。 こうなると、AWS側はアーキテクチャを変えるどころか、EC2インスタンスを再起動することすらできません(再起動するとIPアドレスが解放されてしまう)。スマホアプリをアップデートして、IPアドレスを直接参照するのを止められればいいのですが、一度公開したアプリを100%アップデートするのは事実上不可能です。 最初にRoute53でホスト名を解決するか
とっくの昔ですが、ECSにECS Exec機能が追加されています。 デバッグに Amazon ECS Exec を使用する - Amazon Elastic Container Service [アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました | DevelopersIO ECS Execとは? ECSサービス経由で起動したECSタスクの中でコマンドを実行できる機能です。docker exec, docker-compose exec と同様です。 なお、単発で実行したECSタスクでは利用できないみたいです。 ECS Exec を有効化する必要はあるの? 以下に示す通り、ECS Execを有効化するのは難しい作業ではありません。ただ、ECS Execを使いたくなるのは問題発生時だと思うので、その時に慌てて設定するより、事前に有効化してお
pipenv は初期設定では ~/.local/share/virtualenvs/ の下に仮想環境を作ります。 $ pipenv install ... Virtualenv location: /Users/a-hoge/.venvs/spam-O71st27X ... しかし、実際に使う上では、 ~/.local/share/virtualenvs/ではなく ~/.venvs の下に作りたい プロジェクトの直下に作りたい すでに仮想環境を作ってあるので、そこにインストールしたい などと、仮想環境の場所を変えたいことがよくあります。 $WORKON_HOME: 仮想環境の親ディレクトリを変える $WORKON_HOME を定義すると、仮想環境はその下に作られます。
$ fluentd rbenv: fluentd: command not found The `fluentd' command exists in these Ruby versions: 2.6.3 rbenv や pyenv などの、**env を使っていると、このようなエラーメッセージが出てくることがあります。 この問題を解決するには**envの仕組みを理解する必要があります。 **env の仕組み そもそも、**envを使っていると、このようにディレクトリを移動しただけで、rubyやpythonのバージョンが自動で切り替わるようになりますが、これはどのように実現されているのでしょう? $ ruby --version ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin18] $ cd my-pr
h2 2020-03-08T23:50:58.701251Z app/xxxxxx-prod-alb/xxxxxxxxx 222.222.222.222:64202 - -1 -1 -1 302 - 1254 224 "GET https://example.com:443/action_store HTTP/2.0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 - "Root=1-xxxxxxx-xxxxxxxxxxxx" "at.m3.com" "arn:aws:acm:ap-northeast-1
あなたの Window 10 には何種類の Python が入っていますか?私は5種類でしたが。という記事が「いいね!」を集めていますが、大変残念なのは「結局どの Python を残したのか。」という段落があることです。この記述があたかも「5個もPythonがインストールされているのは異常」という印象を与えてしまっています。 真のPythonistaは、もしもの時の動作確認用に、全てのPythonをインストールしておくものです!! というわけで、以下のコマンドで全てのPython(2020年3月9日現在で398種類)をインストールできます!この他にOS用のと、HomeBrewのPython2と3がインストールされているので401種類ですね!
resource "google_service_account" "logagg" { account_id = "logagg-fluentd" display_name = "logagg-fluentd" description = "fluentd が Cloud Pub/Sub にデータを挿入するためのアカウント" } resource "google_project_iam_policy" "pubsub-publisher" { project = "my-project" role = "roles/pubsub.publisher" members = [ "serviceAccount:${google_service_account.logagg.email}" ] } terraform apply → yes を実行! ドーン!! 誰もGCPの画面にログインでき
Lambdaはログを CloudWatch Logs に自動保存しますが、CloudWatch Logs にはJSON形式のログを自動でパースして整形表示したり検索したりする機能があります。是非とも、ログをJSON形式にしたいところです。 しかし、「python lambda logging json」でググって見つかる記事は、いずれも内容に不備があるようでしたので、自分がベストだと思う方法を紹介するのがこの記事です。 お断り Pythonのログ出力は標準ライブラリのloggingがスタンダードなので、この記事ではloggingを前提にしています。 printを使うべきではない理由・logging の正しい使い方については「ログ出力のための print と import logging はやめてほしい 」という記事が分かりやすいです(文体は辛辣ですけど) これが(きっと)ベストプラクティス
プログラムで時刻を扱うときは、必ずタイムゾーン付きの方の時刻型を使いますよね? 「UTCの時刻に変換してdatetime without timezone型の列に格納」なんて、レガシー対応以外ではしませんよね!? REST APIで、パラメータで時刻渡すときは2019-11-29T20:36:37+09:00みたいにタイムゾーン付きの表記にしますよね!? 「当たり前じゃないか」という方には、この記事は蛇足です。 でも、 「datetime without timezoneで、サーバーのタイムゾーンを使えばいい」 「内部ではUTCに揃えて扱う」 「パラメータは "2019-11-29T20:36:37"形式で。タイムゾーンはJSTに統一」 とか言いだす人に遭遇することが意外とあります。 次回遭遇したときに備えて(or 次回遭遇を防ぐために)、なぜタイムゾーン付きをつけるべきなのかこの記事で説
プログラミング業界では定期的に「美しいコード」が話題になり、そのたびに炎上が発生します: コードの美しさは実務には関係ない 美しくても動かなければ意味がない 「美しさ」は主観的で、プログラマーの自己満足に過ぎない 汚くたって俺は読める。読めないお前が悪い などなど・・・ 私もコードは美しくあれかしとは思いつつも、 「確かに『美しい』って曖昧だよな」とか、 「どうして = の位置がそろっているのを『美しい』というのだろう?『整然としている』なら分かるけど」とか、 「『可読性が高い』でもいいけど、今一つ『美しい』との違いが判らん」 「そもそも、どうして美しいコードの方が読みやすいと言えるんだ?」 と、割り切れなく思っていました。 ところで、最近の心理学・脳科学ではこんな説があるようです(本当かどうかは知らないよ): 中野:(中略)美人の顔って対称性が高いって言われますよね。あれは別に体が健康だ
Python 3.7から(非公式には3.6から) dict がキーの順序を保証するようになりました(collections.OrderedDict相当の動作になった)。 今更ながら「dict が順序を保存するようになって良かったナァ」とシミジミ感じているので、その気持ちをダンプします。 良かったこと 例えば pandas でデータ集計をした時に DataFrameのカラム名を日本語に直した上で順序も入れ替えたい、なんてことはあるでしょう。 Python 3.7以降では、こんな風に辞書を1つ書けばOK。 import pandas as pd df = pd.DataFrame(...) # 何処かから DataFrame を取得済みとする。カラムは "age", "name", "salary" # カラムの順序を "name, age, salary" にした上で、日本語に置き換えたい
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー(と言うか理系?)には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて!」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった(ご存知なら教えてください)ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 (※コメント欄などの指摘を受け「補足」を追加) (※タイトル変更。「コードレビュー前に直して欲しい日
以前Pythonのパッケージ周りのベストプラクティスを理解する(2019年現在)を書きました。 この記事では「基本的には pipenvを使えばOK」と書きましたが、意図的に無視していた部分があります。 Poetryです。 Poetryは調べてみたのですが、各種日本語の記事(は一部の英語記事)はざっと読んだ限りでは、Poetryはどうにも了解できないことが多かったからです。そして、現時点ではPoetryよりPipenvの方が知名度が高そうだし、Pipenv自体は十分実用的なので「pipenvを使えばOK」としました。 とは言え、来年にはPoetryが天下をとっているかもしれません。そこで、そのうち書く記事の足がかりとして、あわよくば誰かが教えてくれたらいいなという虫のいい期待を込め、疑問点を列挙したいと思います。 Pipfile の使用はPEPで決まったものではない? それはどこまで問題でし
pipenvコマンドとPipfile/Pipfile.lock で依存パッケージを管理しているプロジェクトで、ちょっとした開発ツールを入れてみたい。 でも、pipenv install --dev で、Pipfile/Pipfile.lockを変更して、他の開発メンバーに影響を与えるのは避けたい(ex. 他メンバーとは好みが違う。お試しで使ってみたいだけなど)。 解決法: pipenv run pip install を使いましょう pipenv run pip install で、Pipfileを変更せずに、仮想環境にパッケージを追加できます。 例: $ pipenv run pip install jupyter # 仮想環境にインストール $ pipenv run jupyter # 仮想環境のコマンドを実行 解説 ご存知の通り、pipenv は標準ライブラリのpip(などの)のラッ
営業一課で使っている PHPアプリを保守してくれないかな? ○○さんが1人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか?私は過去に何度か経験した1のですが、こういった仕事はなぜか: 正確な仕様を知っている人はいない(知ってた人は辞めた) テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初に何をするべきか書いていきたいと思います。 なお、ここで最悪なのは「とりあえず、緊急の不具合から直してしまおう」と、いきなりコードの修正にかかることです。 ※おことわり: 「レガシー」には様々な定義がありますが、この記事では「遵法的な職場の」「PHPやRai
この記事では、Pythonのパッケージの作り方・PyPIで公開する方法を説明します。 もちろん、すでに同様の記事はあるのですが、情報が古かったり(後述)、一部のツール(TwineやPipenv)が紹介されていない記事が多いようなので、「2019年版」として最新と思われる方法を説明します。 使用するツール 以下のツールを使います。なお、この記事では、シンプルな(説明が楽な)ケースのみ説明しているので、詳細な使い方は各ツールのドキュメントを参照してください。 Setuptools パッケージの内容を定義するための標準ライブラリ。setup.pyやsetup.cfgなどの設定ファイルはsetuptoolsが使う Pipenv 開発中に、仮想環境を作ったり、依存パッケージを管理したり、Pythonのバージョンを切り替えるためのツール。サードパーティだがデファクトスタンダード。 pytest サード
Pythonのジェネレータには .send(), .throw(), .close() というメソッドがありコルーチンとして使うことができます(PEP 342)。 しかし、残念なことにジェネレータベースのコルーチンはPython 3.10での廃止が予定されているので、async def ベースのコルーチンに書き換えなければなりません。 ・・・が、なぜか、具体的な書き換え方法はドキュメントに書かれていませんでした(ジェネレータベースのコルーチンを、@types.coroutine でラップして async ベースとして使う方法は書かれていましたが)。 書き換える方法 コルーチン関数の方は、単にdefをasync def に書き換えるだけです。 Generator-based Async-based
direnv は、ディレクトリごとに環境変数を切り替えられるツールで、複数のプロジェクトを並行開発している場合などに便利です。 Mac なら、以下のような関数を ~/.direnvrc に定義しておくと・・・ # ~/.direnvrc use_java() { if [ "$#" -ne 1 ]; then echo "usage: use java VERSION" >&2 return 1 fi local v v="$1" if [ "$v" -le "8" ]; then v="1.$v" fi export JAVA_HOME="$(/usr/libexec/java_home -v "$v")" PATH_add $JAVA_HOME/bin }
Ruby・Railsに限らず、ライブラリの古いバージョンを使い続けるのは、セキュリティ的にも開発効率的にも良くありません。 しかし、アップデートはアプリケーションの機能を向上させるものではありませんから、機能開発や不具合修正の方が優先されがちです。そのため、古いバージョンが放置されないようにするには、あらかじめ年間計画の中にアップグレード作業を織り込んでおくのが1つの方法です。 ところで、RubyもRailsも、マイナーバージョンも含めれば2・3ヶ月に1回リリースされます。アップデートはいつ行えばいいのでしょうか? RubyとRailsのリリース周期 アップデート計画を考える上では、機能の追加変更がある X.Y.0 (マイナーバージョンアップ)と、大きな不具合が見つかることが多いとされる X.Y.1 のリリースが重要です。以下で X.Y.0, X.Y.1 のリリース日を調べました。 Rub
オブジェクト指向はプログラミングの基本です。そして、継承はオブジェクト指向の基本的な操作ですから、プログラマーは呼吸をするように継承をできなくてはならないはずです1。 しかしその割に、ダメな継承の使い方をして、スパゲッティコードになるのを実務でしばしば見かけます。 これは、継承の「良い使い方」はデザインパターンとしてリストアップされているのに、「悪い使い方」はまとまっていないせいかもしれません。そこで、自分だったらコードレビューで をつけるような「悪い継承の例」を挙げてみました2。 (この記事は個人的な経験によるもので、理論的な裏付けがあるものではありません。ご意見やオススメ本があれば、コメントをお願いします。また、この記事は随時細かい表現の修正をしています。) TL;DR 継承を使ってはならない Mix-inを使ってはならない super は不吉な兆候 例外条項 インターフェースの実装(
大げさな表現を使いましたが、以下のように crontab で bash -l や source ~/.bashrc を使うのはアンチパターンだと思います。 # BAD 0 8 * * * /bin/bash -l -c 'my_daily_batch.sh' # BAD 0 18 * * * source ~/.bashrc && 'my_evening_batch.sh' なぜ ~/.bashrc を読み込みたいのか 周知の通り Cron はコマンドを ~/.bashrc を読み込んでいない環境で実行するのですが、これは初心者泣かせでもあります: 「コマンドラインだと成功するのに、cronだとエラーになるんです!どうしたらいいですか!?」 そして、ググって最初に見つけるのが source ~/.bashrcや bash -l を使う方法です。まぁ、それでうまく動くかもしれません。当面の間
みなさん pipenv を使ってますか? まだ pip ですか? 最近、pipenv を導入した際に必要だった作業を紹介します1。 pipenv とは何か?なぜ pipenv なのか? pipenv は pip のラッパーで、RubyでいうBundlerです。pip単体でもライブラリの管理はできるのですが、pipenv の方が色々便利です。 pipと同様に Python Packaging Authority が管理しています。 詳しくはドキュメントやQiitaの記事 をご覧ください。 setup.py や requirements.txt を削除 今回 pipenv 化したのは アプリケーション です。 PyPIに公開したりする必要はないので、setup.py の中身は最小限を残して削除します。 setup( name='hoge', version='1.4.5', packages=
Python のライブラリでは、よく __version__ が定義されていて、 インタラクティブシェルで、簡便なバージョン確認に使えますが、 自分でライブラリを書くのに、__verson__ を定義するのはアンチパターンじゃないかと、最近思い始めました。 じゃあどうするの? こうします。 __version__ は定義しない バージョンは setup.py に(だけ)指定する 以下理由です。 理由1: 二重管理になる バージョン番号は、setup.pyにも書かなくていけません。
なぜPythonでGUIなのか? なぜ Ruby, JS, C# ではなくPythonなのか? Python言語自体が書きやすい (vs JS) WindowsでもMacでも動作する (vs Ruby, C#) データ分析や画像処理などのライブラリが充実している ctypesやCythonでC/C++のコードを呼び出せる Pythonの主なGUIライブラリ tkinter 標準添付 turtle 標準添付・カメさんがカワイイ Kivy 新しい PyQt5 今日のオススメ QtはOSSのアプリケーションフレームワーク 1992〜 (現在 v5.8) C++ 製 クロスプラットフォーム(OSネイティブのスタイルで描画) 豊富なウィジェット _ 使いやすいAPI(シグナル、レイアウト、MV) ツール (IDE, UIデザイナ) PyQt5 は Qt5.x のラッパー SIP というツールでC++
1. とりあえず -D -E -S -P をつけるべし オプションはいくつもありますが、-D -E -S は特に副作用がないので、常に有効化することをオススメします。また、-P をつけると処理速度が向上します。
このページを最初にブックマークしてみませんか?
『@tonluqclmlのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く