サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
コーヒー沼
yaruki-strong-zero.hatenablog.jp
dockerコンテナを使ってローカルで開発作業をするとき、local側のディレクトリとコンテナ側のディレクトリを共有してコンテナ側で生成されるファイルを永続化したりする事がある。 このとき、コンテナ側で生成されたファイルがroot権限で作成されたりするとlocal側での取り扱いがめんどくさい。(sudoしないとファイルを削除できなかったり) ローカル側のUID, GIDとコンテナ側でのUID, GIDを揃えられるようにDockerfileやdocker-composeを用意しておくと、このあたりがスムーズに行くようになる。 #Dockerfile FROM ubuntu:20.04 ARG USERNAME=app ARG GROUPNAME=app ARG UID=1000 ARG GID=1000 RUN groupadd -g $GID $GROUPNAME && \ useradd
こんがらがったシステムの保守開発で苦労した経験から新規開発では「シンプルな構成・シンプルな実装にしよう」という話が出る。 目指す方向としては間違って無いように思えるのに、それだけだとうまく行かない。 「保守しやすい構造」とはそれなりに多くの知識が必要なので、これらの知識を持たず単純に「シンプルな構成・シンプルな実装」を目指すと失敗する。 「保守しやすい構造」を作るには「どういう構造が保守しやすいのか?」を学ぶ必要がある。 これについて書く。 「シンプル」を目指したつもりが複雑になって失敗する例 まずは、ありがちな失敗例を示す。 実装する処理を減らしてシンプルにしたら複雑化した コードの複雑さを減らすため、実装する機能を絞った。 コード量が減ったのでシンプルになった。 しかしここで削られた機能の処理は結局はどこかでやる必要があった為、後日別の場所(連携する別システム側など)に実装された。 や
例えば「ユーザー名」など重複を許さない項目はDBへ登録クエリを投げる前にバリデーションで重複チェックするが、普通にやっていると「重複チェックをパスしたのに、DB登録実行時点では重複が発生している」となるケースが存在する。 「重複チェック」と「DB登録実行」が同一トランザクション内に記載されていても起こる。 ※ファントムリードが起こるために発生する。 二人(A君、B君)が別の画面から同時に同じユーザー名で登録を実行した場合 A君:重複チェック => OK(重複は存在しない) B君:重複チェック => OK(重複は存在しない) A君:DB登録実行 => OK(重複は存在しない) B君:DB登録実行 => NG(A君の登録したユーザー名と重複) この状況を防ぐには、「重複チェック」の際に対象テーブルに対してテーブルロックをかける必要がある。 そうすれば、イメージ通りの挙動になる。(が、非推奨)
macキーボードを認識させる デフォルトでは英数・かなキーおしても認識していなかったので下記設定を行った。 参考) https://qiita.com/koreyou/items/341e1fac95c72d9743ad sudo dpkg-reconfigure keyboard-configuration を実行して、下記を選択 Apple アルミニウムキーボード (JIS) Japanese Japanese - Japanese (Macintosh) No toggling No temporaly switch The default for the keyboard 英数・かなキーでIME切り替えできるようにする ubuntu画面の右上の入力切替で「日本語(Mozc)」を選択する。(なければ追加する。) 同じく画面右上の入力切り替えドロップダウンメニューの中から「ツール」->
ぼやっとは理解してたけど、この記事を見て知識が定着した気がする。 DI・DIコンテナ、ちゃんと理解出来てる・・? - Qiita この記事ではDIとDIコンテナとサービスロケータについて触れてたけど、 ここではDIについてだけ改めて自分でまとめてみる。 サンプルケース 例えばこんなコードがある。 ※phpぽいけど疑似コードです。 class Human { public void function __construct(string name) { this->brain = new Database() # DBアクセスライブラリ this->name = name } # 覚える public void function memolize(string keyword, string some_string){ this->brain.save(keyword, some_strin
Djangoを動かすのには nginx -> uWSGI -> Django という感じの構成にするのが良いっぽい。 uWSGIの使い方について調べたのでまとめる。 ここの荒い翻訳になっている。 Quickstart for Python/WSGI applications — uWSGI 2.0 documentation インストール pip install uwsgi 単体で実行 foobar.pyを用意。 def application(env, start_response): start_response('200 OK', [('Content-Type','text/html')]) return [b"Hello World"] uwsgi --http :9090 --wsgi-file foobar.py これでlocalhost:9090でHello Worldが表
このページを最初にブックマークしてみませんか?
『yaruki-strong-zero.hatenablog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く