独断と偏見で、プログラマをレベル付けして特徴をまとめました。

＊Level 1 〜 5 に収まるようまとめる予定ですが、とりあえず Level 3 まで投稿しておきます。

プログラミングに触れたばかりの初心者に相当するレベルです。

コーディングを担当する範囲は「プログラミング言語の公式リファレンスを見れば書ける」程度のものが多いです。

このレベル帯の方は、言語仕様の理解が追いつかないままネットで見つけたコードをコピペして利用することが多く、それ故にコンパイルエラーと戦う時間が長い傾向があります。

意外とコーディングのスピードが早く、最初は進捗が良く見えますが、疎通やテストのタイミングで根本的な手戻りや根深いバグに遭遇してしまい、最終的に遅延していることが多い印象です。

プログラマの成長には「成功体験」や「楽しんだ時間」が非常に大切です。自分のレベルに合ったコードを沢山書きましょう

自分の書いたコードを「人に説明できる程度に」理解しましょう

できる範囲で「コピペ」をやめて「読む→理解する→頭の中身を書き出す」に置き換えてみましょう

プログラミング言語仕様をある程度理解している初心者に相当するレベルです。

コーディングを担当する範囲は「小規模で影響範囲の狭い画面やビジネスロジック」などが多いです。慣れてくると「中規模」や「小規模ながら影響範囲の広いもの」が割り振られる場合もあります。

このレベル帯の方は、膨大な量を誇るプログラミング言語仕様のうち、頻繁に使用する範囲を暗記している為、ある程度スムーズにコーディングすることができます。しかし無意識のうちに「知っている範囲の言語仕様」と言う柵に囚われてしまい、最終的に可読性や保守性の低いコードを書くことが多い印象です。

コードは常に複数のパターンを考え、その中で一番良いものを選ぶようにしましょう

「やりたいこと」と「コード量」が一致しない等の違和感を感じたら、公式リファレンスを確認してより良い方法が無いか確認しましょう

「半年後の自分がメンテナンスしやすいコード」を意識して書いてみましょう

デザインパターンに一定の理解がある中堅者に相当するレベルです。

コーディングを担当する範囲は「小規模システムの全域」や「中〜大規模システムのうち難易度が高すぎない箇所」などが多いです。

このレベル帯の方は、ある程度複雑なアルゴリズムをコーディングすることができ、さらに定石ロジックを身に付けているため基本的にコーディングスピードが速いです。また、デザインパターンや定石を駆使したコードを書くため、クオリティのコントロールがしやすく、コーディングした量に比べてバグの数が少ないと感じることが多い印象です。

さらに視野を広げて責務分担や責任分界点、テスタビリティを意識してコードをデザインしてみましょう

「脳内のコーディングスピード」と「実際のタイピングスピード」の差が大きくなりやすいので、IDE のショートカットなどを積極的に利用してみましょう

最初に書いたコードはフィージビリティ検証用として破棄して、少なくとも１度リファクタリングしたバージョンを利用しましょう

システム全体をデザインできる熟練者に相当するレベルです。

担当する範囲は「システム全体のデザイン」に加え「システムのうち特に難易度の高い部分」になることが多いです。このレベル帯からはシステムのデザインに時間を割くことが多くなり、必然的にコーディング量が減る傾向が強いです。

このレベル帯の方は、概念レベルの設計や責務分担・責任分界点などを考慮してシステムをデザインすることができ、概念レイヤなどシステムの動作に直接関係のない部分のソースコードが必要になるため、Level-3 以下のプログラマを育成しながらコーディングしていることが多い印象です。

概念レイヤまでコーディングした後、具象化はチームメンバーに委ねましょう

レベル別プログラマの特徴まとめ

 の場合だけ」のように特定の条件を満たす時に環境変数を設定したい場合がありますよね。しかし 

 としてビルド時の分岐がそもそもサポートされていないので、今回はそのような場合に有効な 

 コマンドは、それぞれが独立したコンテキストで動作します。そのため 

 した環境変数が、 それ以外の 

 コマンドの環境変数に影響することはありません。後述では 

 コマンドを跨いで環境変数を設定する方法を紹介します。

 などの場合でも基本的な考え方は非常に似ているので、 

 などの利用を検討してみてください。

ログインせずに環境変数を設定する場合

FROM alpine:latest

# '-i' でインタラクティブモードを有効化しないと初期化シェルをロードできないので注意
SHELL [ "/bin/sh", "-i", "-c" ]

# '-i' でロードする環境変数を含んだ初期化シェルを指定
ENV ENV /root/.shinit

# '.shinit' に環境変数を追記
RUN echo 'export TEST_ENV=test-env-value' >> ~/.shinit

# ルートユーザの環境変数をチェック
RUN echo -e "User : $(whoami)\nEnv  : $TEST_ENV" > /root/env.txt
# /root/env.txt
# User : root
# Env  : test-env-value

# その他ユーザの環境変数をチェック
RUN adduser -S other
USER other
RUN echo -e "User : $(whoami)\nEnv  : $TEST_ENV" > /home/other/env.txt
# /home/other/env.txt
# User : other
# Env  :

USER root
CMD less /root/env.txt /home/other/env.txt

ログインユーザ全員に環境変数を設定する場合

FROM alpine:latest

# '-l' でログインモードを有効化しないと初期化シェルをロードできないので注意
SHELL [ "/bin/sh", "-l", "-c" ]

# '/etc/profile' に環境変数を追記
RUN echo 'export TEST_ENV=test-env-value' >> /etc/profile

# ルートユーザの環境変数をチェック
RUN echo -e "User : $(whoami)\nEnv  : $TEST_ENV" > /root/env.txt
# /root/env.txt
# User : root
# Env  : test-env-value

# その他ユーザの環境変数をチェック
RUN adduser -S other
USER other
RUN echo -e "User : $(whoami)\nEnv  : $TEST_ENV" > /home/other/env.txt
# /home/other/env.txt
# User : other
# Env  : test-env-value

USER root
CMD less /root/env.txt /home/other/env.txt

ログイン中のユーザ別に環境変数を設定する場合

FROM alpine:latest

SHELL [ "/bin/sh", "-l", "-c" ]

RUN echo 'export TEST_ENV=test-env-value-A' >> /root/.profile

RUN adduser -S other
RUN echo 'export TEST_ENV=test-env-value-B' >> /home/other/.profile

# Checks the environment variable of the root user.
RUN echo -e "User : $(whoami)\nEnv  : $TEST_ENV" > /root/env.txt
# /root/env.txt
# User : root
# Env  : test-env-value-A

# Checks the environment variable of the other user.
USER other
RUN echo -e "User : $(whoami)\nEnv  : $TEST_ENV" > /home/other/env.txt
# /home/other/env.txt
# User : other
# Env  : test-env-value-B

USER root
CMD less /root/env.txt /home/other/env.txt

 Skip to content You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab...

docker-examples/dynamic-environment at main · laziness-works/docker-examples · GitHub

 { const container = $el; // The div with overflow const item = document.getElementById('sidebar-current-page') if (item) { const containerTop = container.scrollTop; const containerBottom = containerT...

Dockerfile reference | Docker Docs


busybox/shell/ash.c at 836b79211df3aeaba1b8b65c6db5ee6193172cc0 · mirror/busybox · GitHub

Alpine Linux の Docker イメージで動的に環境変数を設定するベストプラクティス

ローカル環境で動作を確認しながら開発していると、サクッとデータベースに接続したくなるタイミングが割とすぐに来ますよね。AWS などの PaaS で立ち上げても良いのですが、やはりローカル開発ならローカルで済むに越したことはありません。さらに、頻繁にデータを入れ替えたりする場合は AWS だと逆に手間やコストがかかる場合もあります。

私は使用したいデータベースの公式 Docker イメージが提供されている場合は、Docker で済ませてしまいます。今回は Docker コンテナで動作するデータベースに、初期データをロードする方法についてベストプラクティスを紹介します。

公式 Docker イメージの多くは、コンテナを立ち上げた段階でデータベースに接続して利用できる状態になります。つまり、Docker コンテナを起動した後にデータロードの処理を実装する隙がないケースがほとんどです。これは Docker コンテナ起動後に、コンテナの外側からわざわざ接続して、データをロードする必要が有ることを意味しています。後述の説明では、Redis を例に Docker コンテナの内側から、コンテナの起動と同時にデータをロードする方法を紹介します。

まずはディレクトリ構成です。
任意のディレクトリに後述の３つのファイルを作成します。

.
├ preload-data
│  └ example.txt
├ docker-compose.yml
└ startup.sh

起動処理をオーバーライドする

Redis の起動処理をオーバーライドする 

 を作成します。
このシェルを 

 に指定すればデータのプリロードを実現できますが、今回は 

#!/bin/bash

# ジョブコントロールを有効化 （最後の fg コマンドを利用するため）
set -m

# redis-server をバックグラウンドで起動して３秒待機 （秒数は適宜調整）
redis-server &
sleep 3             

# データロード処理
# （1行目のように直接書いても良いが、２行目のファイルから読み込む方法がオススメ）
redis-cli set test-data test-value
redis-cli < ./preload-data/example.txt

# バックグラウンドの redis-server をフォアグランドに戻す
fg %1

プリロードデータをシェルの外から読み込む場合に必要なファイルです。

set batch-test-data1 batch-test-value1
hset batch-test-data2 key1 batch-test-value2-1
hset batch-test-data2 key2 batch-test-value2-2

 を作成しても良いのですが、データディレクトリのマウントやデータの入れ替えを考えると、最初から 

 でデータディレクトリをマウントした状態で Docker コンテナを起動した方が捗るため、以下のファイルを作成します。

version: "3.7"

services:

  database:
    image: redis:6.2.6
    command: /bin/bash /data/startup.sh
    ports:
      - 6379:6379
    volumes:
      - ./startup.sh:/data/startup.sh
      - ./preload-data:/data/preload-data

データがロードされたか確認する

Docker コンテナを起動して、データがロードされるか確認します。


 に、想定通りのキーが出力されれば OK です。

% cd （docker-compose.ymd を配置したフォルダ）
% docker-compose up -d
Creating network "example_default" with the default driver
Creating example_database_1 ... done
% docker ps
CONTAINER ID   IMAGE         COMMAND                  CREATED          STATUS          PORTS      NAMES
(CONTAINER-ID) redis:6.2.6   "docker-entrypoint.s…"   14 seconds ago   Up 13 seconds   6379/tcp   example_database_1
% docker exec -it (CONTAINER-ID) bash
xxxxx@(CONTAINER-ID):/data# redis-cli
127.0.0.1:6379>keys *
1) "batch-test-data2"
2) "test-data"
3) "batch-test-data1"

docker-examples/redis-data-preload at main · laziness-works/docker-examples · GitHub

Run multiple processes in a container | Docker Docs


Docker の Redis イメージに初期データをロードするベストプラクティス

Web サイトに対してアクセス解析を行う場合、一般的には Google Analytics を利用します。今回は Next.js で作成した Web サイトに Google Analytics を導入する方法について紹介します。

Google Analytics では解析データを収集するために、以下のコードを Web サイトに埋め込む必要があります。

しかし、TypeScript を利用している場合など、型チェックが働いている環境では、Next.js にコードをコピペするとコンパイルエラーが発生してしまいます。少し古い情報だと 

 を使ってスクリプトを一旦文字列として埋め込む方法もありますが、2021年10月 現在では後述の方法がおすすめです。

 タグを、Next.js に実装されている 

 タグに置き換えて埋め込みます。この方法を使えば、 

 のようなサニタイズしたくなってしまう方法を使わず、スマートに記述できます。以下のコードは全てのページに Google Analytics のコードを埋め込みます。環境変数（ 

 ）に値が設定されている場合のみ、コードを埋め込む条件を追加しているので、うまく環境変数を設定すればローカル環境やプレビュー環境からのノイズを気にしなくて良くなります。

import type { AppProps } from 'next/app'
import Script from 'next/script'

const analyticsId = process.env.NEXT_PUBLIC_GOOGLE_ANALYTICS_ID

const MyApp = ({ Component, pageProps }: AppProps): JSX.Element => (
  <>
    {analyticsId &&
      <>
        <Script async src={`https://www.googletagmanager.com/gtag/js?id=${analyticsId}`} />
        <Script id="gtag">{`
          window.dataLayer = window.dataLayer || [];
          function gtag(){dataLayer.push(arguments);}
          gtag('js', new Date());
          gtag('config', '${analyticsId}');
        `}</Script>
      </>
    }
    <Component {...pageProps} />
  </>
)

export default MyApp

環境変数の型定義も合わせて載せておきます。

namespace NodeJS {
  interface ProcessEnv {
    NEXT_PUBLIC_GOOGLE_ANALYTICS_ID: string | undefined
  }
}

 Menu Using App Router Features available in /app Using Latest Version 15.2.2 Getting Started Installation Project Structure Layouts and Pages Images and Fonts CSS Fetching Data Updating Data Error Ha...

Optimizing: Scripts | Next.js

Next.js に Google Analytics を導入する際のベストプラクティス

システムの開発中など、ローカルに WebAPI 用のサーバを立てた経験、ありますよね？
最近は Docker でサクッと立ち上がるケースが増えてきて、こんなに簡単で良いのだろうかと思ってしまう程です。本当に良い時代になりました。

今回は、サーバも準備できたし動作確認しよう！と思って WebAPI を叩いた時に発生しがちなエラーの回避方法を紹介します。

Node.js からローカルサーバの WebAPI（ HTTPS ）をコールした際に、以下のエラーが発生する。

ローカルサーバの WebAPI レスポンスの署名が、自己証明書（通称オレオレ証明書）によるものであるため。

Node.js の環境変数に以下を設定すると

署名のチェックがスキップされ

、エラーが発生しなくなります。あくまで環境変数なので、 

 などに記述しても良いでしょう。

process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'

＊この設定は HTTPS の安全性を失う設定なので、ローカル開発環境でのみ設定が有効になるよう、予め工夫しておくことがポイントです。Node.js 公式が「強く推奨していない」設定です。

 Node.js About this documentation Usage and example Assertion testing Asynchronous context tracking Async hooks Buffer C++ addons C/C++ addons with Node-API C++ embedder API Child processes Cluster Co...