サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
WWDC25
qiita.com/tonluqclml
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 1970年頃のホンダでは、エンジンの冷却方法について激しい対立が起きました。 熱力学的には水冷の方が合理的ですが、創業者社長の本田宗一郎は空冷にこだわりました。 宗一郎曰く: 「砂漠の真ん中でエンストしたときに水なんかあるか!空冷だ」 「水冷だってラジエーターを空気で冷やすんだから、最初から空冷のほうが合理的」 実は、宗一郎には、過去に水冷エンジンを開発した際、液漏れに苦労した体験がありました。空冷なら信頼性が高いだろうというわけです。 しかし、宗一郎肝いりで開発した空冷エンジン搭載の「ホンダ・1300」は商業的には失敗してしまいます。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 某所で見かけたシステム運用作業手順書の記事に、「作業直前に作業手順書の変更はしない」「手順書に無い作業をしない」といった事が書かれていました。 いや、それはあくまで心掛けの話であって、それも大事だけど、そもそも作業手順書はどうあるべきかという話が抜けおちているのではないか?それは世間ではあまり明文化されていないのではないか?と思いました。 不遜ながら、私が思う作業手順書のあり方を書いてみます。 1. 存在している まさか、本番作業を勘とノリでやっちゃうなんて。まさかね… 2. 保存されている Githubでも、Google Driveで
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 「取り返しのつかないことをしない」 昔、同僚と議論していて口走った言葉です。実はプログラマーとしてわりと重要な考えなのではないかと思います。 例: EC2のパブリックIPをスマホアプリに直書きする スマホアプリ向けの静的ファイルやバックエンドAPIをAWSに実装した際、最初はスモールスタートだと言うことでEC2インスタンス1台の構成にしたところまではいいが、インスタンスに自動で割り当てられるIPアドレスをスマホ側で直接参照する実装にしてしまった。 こうなると、AWS側はアーキテクチャを変えるどころか、EC2インスタンスを再起動することす
とっくの昔ですが、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 を定義すると、仮想環境はその下に作られます。
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
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
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 はやめてほしい 」という記事が分かりやすいです(文体は辛辣ですけど) これが(きっと)ベストプラクティス
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? プログラムで時刻を扱うときは、必ずタイムゾーン付きの方の時刻型を使いますよね? 「UTCの時刻に変換してdatetime without timezone型の列に格納」なんて、レガシー対応以外ではしませんよね!? REST APIで、パラメータで時刻渡すときは2019-11-29T20:36:37+09:00みたいにタイムゾーン付きの表記にしますよね!? 「当たり前じゃないか」という方には、この記事は蛇足です。 でも、 「datetime without timezoneで、サーバーのタイムゾーンを使えばいい」 「内部ではUTCに揃えて
プログラミング業界では定期的に「美しいコード」が話題になり、そのたびに炎上が発生します: コードの美しさは実務には関係ない 美しくても動かなければ意味がない 「美しさ」は主観的で、プログラマーの自己満足に過ぎない 汚くたって俺は読める。読めないお前が悪い などなど・・・ 私もコードは美しくあれかしとは思いつつも、 「確かに『美しい』って曖昧だよな」とか、 「どうして = の位置がそろっているのを『美しい』というのだろう?『整然としている』なら分かるけど」とか、 「『可読性が高い』でもいいけど、今一つ『美しい』との違いが判らん」 「そもそも、どうして美しいコードの方が読みやすいと言えるんだ?」 と、割り切れなく思っていました。 ところで、最近の心理学・脳科学ではこんな説があるようです(本当かどうかは知らないよ): 中野:(中略)美人の顔って対称性が高いって言われますよね。あれは別に体が健康だ
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を書く」といった、良く知られた・日本語に限定されない話題は省略しています。 1. 俗称を使わない・造語しない 製品名・機能名な
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以前[Pythonのパッケージ周りのベストプラクティスを理解する(2019年現在)] (https://www.m3tech.blog/entry/python-packaging)を書きました。 この記事では「基本的には pipenvを使えばOK」と書きましたが、意図的に無視していた部分があります。 Poetryです。 Poetryは調べてみたのですが、各種日本語の記事(は一部の英語記事)はざっと読んだ限りでは、Poetryはどうにも了解できないことが多かったからです。そして、現時点ではPoetryよりPipenvの方が知名度が高そう
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 営業一課で使っている PHPアプリを保守してくれないかな? ○○さんが1人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか?私は過去に何度か経験した1のですが、こういった仕事はなぜか: 正確な仕様を知っている人はいない(知ってた人は辞めた) テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初
この記事では、Pythonのパッケージの作り方・PyPIで公開する方法を説明します。 もちろん、すでに同様の記事はあるのですが、情報が古かったり(後述)、一部のツール(TwineやPipenv)が紹介されていない記事が多いようなので、「2019年版」として最新と思われる方法を説明します。 使用するツール 以下のツールを使います。なお、この記事では、シンプルな(説明が楽な)ケースのみ説明しているので、詳細な使い方は各ツールのドキュメントを参照してください。 Setuptools パッケージの内容を定義するための標準ライブラリ。setup.pyやsetup.cfgなどの設定ファイルはsetuptoolsが使う Pipenv 開発中に、仮想環境を作ったり、依存パッケージを管理したり、Pythonのバージョンを切り替えるためのツール。サードパーティだがデファクトスタンダード。 pytest サード
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 は不吉な兆候 例外条項 インターフェースの実装(
みなさん 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でGUIなのか? なぜ Ruby, JS, C# ではなくPythonなのか? Python言語自体が書きやすい (vs JS) WindowsでもMacでも動作する (vs Ruby, C#) データ分析や画像処理などのライブラリが充実している ctypesやCythonでC/C++のコードを呼び出せる Pythonの主なGUIライブラリ tkinter 標準添付 turtle 標準添付・カメさんがカワイイ Kivy 新しい PyQt5 今日のオススメ PyQt5のご紹介 QtはOSSのアプリケーションフレームワーク 1992〜 (現在 v5.8) C++ 製 クロスプラットフォーム(OSネイティブのスタイルで描画) 豊富なウィジェット _ 使いやすいAPI(シグナル、レイアウト、MV) ツール (IDE, UIデザイナ) PyQt5 は Qt5.x のラッパー SIP
このページを最初にブックマークしてみませんか?
『@tonluqclmlのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く