20200922のGitに関する記事は5件です。

Ubuntu 18.04にKallitheaを構築する

概要

KallitheaはGit と Mercurial に対応したオープンソース(GPLv3)のリポジトリホスティングソフトウェアです.
今回はそのKallitheaをubuntu上に構築していきます.

Kallitheaとは

環境

Software Version
ESXi 6.7
Ubuntu 18.04

パッケージのアップデート

sudo apt update

インストール

1. パッケージのインストール

sudo apt install build-essential git libffi-dev python3-dev npm mercurial python3-pip

2. ディレクトリを作成

  • 今回は/opt配下に構築していきます
# kallitheaとリポジトリ配置用のディレクトリ(repos)を作成
sudo mkdir -p /opt/kallithea/repos
# 書き込み可能なパーミッションに変更
sudo chmod -R 777 /opt/kallithea

3. kallitheaのインストール

# kallitheaディレクトリに移動
cd /opt/kallithea
# kallitheaをインストール
pip3 install kallithea

初期セットアップ

1. Kallithea構成ファイルの作成

# kallitheaディレクトリに移動
cd /opt/kallithea
# 構成ファイルの作成
kallithea-cli config-create my.ini

2. Kallitheaで使用するDBの作成

kallithea-cli db-create -c my.ini

3. フロントエンドファイルの作成

kallithea-cli front-end-build

Kallitheaの実行

# 起動
gearbox serve -c my.ini

# デーモン化
gearbox serve -c my.ini --daemon
  • http://localhost:5000 でアクセスできる

  • Port及びIPを変更したい場合はmy.iniの[server:main]セクションで変更する.

[server:main]
host = 127.0.0.1
port = 5000

サブディレクトリで運用する

  • Apacheでの設定例です.

1. Apacheの仮想ホストファイルの設定

  • 仮想ホストファイルに下記を追記
<Location /kallithea >
  ProxyPass http://127.0.0.1:5000/kallithea
  ProxyPassReverse http://127.0.0.1:5000/kallithea
  SetEnvIf X-Url-Scheme https HTTPS=1
</Location>

2. my.iniファイルに設定を追記

  • my.iniファイルの[app:main]セクションに下記を追記
[app:main]
use = egg:kallithea

# 下記を追記
filter-with = proxy-prefix

参考

Kallitheaのインストール手順

Kallithea Installation on Unix/Linux

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Gitコマンド

リポジトリを作成

作成後に表示されるURLをメモしておく

  • 作業フォルダを作成し、移動する

(後のローカルリポジトリなので、1で作成したリポジトリ名に合わせると良い)

$ mkdir work

$ cd work
  • ローカルリポジトリとして初期化する
$ git init
  • ファイルをインデックスと呼ばれる領域に登録する(ステージングという)
$ git add ファイル名
  • ステージングしたファイルをコミットする

mオプションでコミットにメッセージを付与

$ git commit -m "first commit"
  • リモートリポジトリに登録
$ git remote add origin メモしたURL

$ git push origin master

リモートブランチを取り込む

  • リモートブランチの変更を取り込む
$ git pull origin ブランチ名
  • ローカルリポジトリにローカルブランチを作成
$ git checkout -b ブランチ名 origin/ブランチ名
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

初心者がReact学習歴1週間でWebアプリ作成に挑戦してみた

はじめに

Reactの学習兼ねてWebアプリを作成してみました。
タイトル通り、Reactのインプット期間は1週間程です。
(仕事してるので時間でいうと恐らく数日程度です)

今回の記事では、インプット学習歴1週間でもなんとか作れた話をお伝えします。

※挑戦する段階で1週間程度のインプットで開発を始めたという話です。
開発期間は余裕で1ヶ月以上かかりました。

私についてですが、今年6月からフロントエンドエンジニアを目指して独学中です。
アプリを作り始めたスキルレベルは、主にHTML/CSS/JavaScriptを勉強しておりました。

0から作ったことはないので、今回が初めてのアプリ作成になります。

見ていただくとわかる通り比較的シンプルなアプリなのですが、
私にとっては全く簡単ではなく、、
でも試行錯誤しながら何とか作成できました!

今回作ったもの

ログイン機能付きの収支管理アプリです。
いわゆる家計簿アプリ的な物です。
毎月の収入と支出をリスト化し月の残高を表示します。

メイン画面
mainpic.png

サインアップ画面
Page-Signup.png

ログイン画面
Page-Signin.png

操作動画はTwitterにアップしてます。(画質粗くなってしまいましたが)

このアプリを作った背景

  • Reactを理解するため
  • 身近な人を助けたかったため

母が未だに家計簿をノートで管理していていました。(驚愕です)
管理が大変そうで、「便利」を作ってあげたいと思ったからですね。
「家計簿アプリどれがいいかよくわからない。表とかいらない」ということで、、
私がシンプルな物を作ってあげようと思いました!

あと、クレジットカードについて、金額がリアルタイムに更新されず困っていたんですね。
カード会社によってはありますよね、時差生じるの。

なのでこちらは、家計簿として使ってもOK、収支管理として使ってもOK、というシンプルで自由なアプリです。
スマフォで入力することが多いと思うので、ホームiconとかレスポンシブにも勿論対応してます。

実装した機能

  • データを保存/取り出し
  • ユーザー登録
  • ログイン機能
  • 表の代わりに支出割合を%で表示
  • 月ごとに管理(実装中)

環境・使用技術

  • node (version 14.8.0)
  • React(version 16.13.1)
    • Router
    • クラスの代わりにHooks
  • Firebase
    • Authentication
    • Cloud Firestore
    • Hosting
  • CSS/material-ui(スタイル)

ソース管理

Git/Githubを使いました。
個人開発ですが、チームの開発を想定して毎回issueを作り、branchを切って作業を進めておりました。

今回のソースはこちら。
https://github.com/kana-wwib/My-budget-app

まだ追加機能とか修正箇所がありますので、コードは変わっていきます。

大変だったこと

細かいことあげると本当にキリがないくらい大変なことだらけですが、、
例えば円のカンマ区切りに苦労したり、リストが順番おかしくなったり。

でもとりあえず、大きく3つに分けて書きます。

Reactの書き方

  • hooksを使う
  • propsの渡し方

基本のキだと思うんですが、超初心者からすると苦労しました。

まず、hooksに関しては、当初インプット学習してた時classの書き方だったんですね。
hooksを全然知らなかったので、それって何?状態から調べました。

今回使用しているのは、useState useEffect useContext です。
classに慣れていたレベルでも勿論ないですが、hooksで一から学び直しながら作るのは大変でしたね。

でも結果、hooksの方が圧倒的にシンプルで書きやすかったです!
今はもうhooksの方が慣れ親しんでます。(今後classで作ることは無いとは思ってます)

propsについては、これもインプットした時分かっていたつもりが多分あまり分かってなかったんですね。
実際に自分で書こうとすると、どうやって渡すんだっけ?という状況でした。

ステートの書く場所も作りながら変わりましたね。やっぱりメインで書かないとだめだ、みたいな。

useContextを認証系で使ってますが、それ以外は基本親→子供に渡すという基本を作りながら理解しました。

あと余談ですが、Reactでは、データは常に単一方向で、Vue.jsは双方向性って最初何のこと?と思ってましたが、こういうことかと実感しました。

Firebaseのデータベース

データを保存/取り出しをするのに、今回Firebaseを使いました。
書籍で学んだ時、一応Firebase使ったんですが、Realtime Databaseだったんですね。

今回のアプリではCloud Firestoreの方を使ったのでやり方が違いました。
ちなみにこちらを選んだ理由は、最新でより高機能だからです。

私はそもそもデータベースについて知識が皆無で、SQL?NoSQL?というレベルでした。
※FirebaseはNoSQL

Firebaseの公式の説明や動画などを見て、どのような形でデータが保存されるのかを試行錯誤しながら進めました。
もちろん、公式以外もいっぱい参考にしてます。

最終的なデータの形はこうなっています。
最初は収入と支出分けなくてもと思いましたが、後々の計算の為分けて保存してます。
collection.png

作り始めの時は、データとログインのユーザーをどうやって繋げるんだ...と思う程未知でしたが、
色々調べてログインしたユーザはuidを使ってうまく個人のデータに分けることができました。

スタイル

スタイルは今回メインでCSSを使ってます。
独学初めの当初に勉強してましたが、最近はずっとJavaScriptを集中的に学んでいたので、すっかり忘れていました...

デザインの知識は皆無なので、前にチュートリアル でやっていた見た目のデザインを真似しました。
あとは色々な見やすい色合いや配置等を調べて参考にしました。
例えばログイン画面ですら、「あれ、普通どんなんだっけ?」という状況でした。

何とか調べながらいい感じにできたわけですが、追加機能をつけるたびにスタイルも調整するという手間があったり。
おそらくCSSメインで書かなければもっと楽だったのかなと思うので、material-uiもっと使いこなせるようになろうと思いましたね。

参考記事・動画

教材としては、色々な記事やYoutubeを参考にしました。

何より例があるとより分かりやすかったです!

色々読みまくったので全部は取り上げませんが、分かりやすくて印象に残ってる分を抜粋します。

追加予定機能(実装中含む)

  • 月ごとのデータ管理
  • 項目の検索機能(月ごと)
  • レシートから料金を文字化してinput(これはできればくらい)

作ってみた感想

よく皆さん言うことですが、アウトプットしながらの勉強は本当に効果があります。
私の場合最初にインプットで学んだ内容は、もはや結局使わず仕舞いでした。

たかがReact1週間の学習歴でWebアプリの作成に挑戦したのですが、
結局は作りながら学ぶので、インプット期間は最小限で何とかなります。
インプットに時間をかけても意味がないというのを本当に実感しました。

最初学んでる時多少分かった気になっていたんですが、、、
実際に作ってみることできちんと理解していないことがわかりました。(私の場合は)
自分の手で実際に作ることで、きちんと深く理解ができたと思います。

あと、思い描いた内容がきちんと反映されて動くのは、最高に嬉しかったですね。
エラーと葛藤してた内容とか、実装方法に苦労してた内容とかは、特に感じました。

まだ追加したい機能もありますし、一つ一つ時間もかかりますが、
また新たなアプリを作りながら学習していこうと思います!

最後に、今回は一つ一つの機能の実装方法について触れていないので、
次回の記事で初心者のための初心者による記事という感じで、解説していこうと思います。
ご興味ある方は是非ご覧くださいませ。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【プログラミング学習~3ヶ月以内の方必見】Gitを使った基本的な開発の流れを丁寧に説明してみた

はじめに

執筆日:2020/9
この記事を見れば、「Gitを使った基本的な開発の流れを理解できる」を目的に進めていこうと思います。

私が学習を始めた当初も、Gitに関する記事はたくさんありました。ですが、流れを把握するイメージがつき辛く理解するのに苦労しました。その経験から、この記事では応用的なコマンドなどの説明は扱わず、あくまで「Git活用時の基本となる大まかな流れ」をお伝えしていこうと思います。
図を用いてイメージしやすい様に作った分、少し分量が多くなりました。小まめに見返す様にしてみてください!

対象となる方

  • プログラミング学習~3ヶ月以内の初学者の方
  • これから初の共同開発をしたいと思っているが、Gitはまだよくわからないと不安な方

上記の方々のお力になれれば幸いです。

この記事の使い方

Gitは大まかな流れを理解できれば、決して難しくはないです。ただ、目に見えて「どこどこの段階にいる」という事が可視化されにくいので、理解できるまでは何度もこの記事を繰り返し見返す事をおすすめします。(可視化できるツールももちろん存在しますよ!)
そうする事によって頭の中に大まかな地図ができる様になると思います。そうなれば、他のより実践的な記事の内容がスムーズに理解できる様になり、非常に効率的だと思います。

Gitとは?

一言でお伝えすると変更履歴を管理するバージョンシステムです。

これからなぜ変更履歴を管理する事が良いのかを紹介します。
良い点は大きく分けて2つあり、イメージがつきやすい様にイメージ図を交えてお伝えしていきます。

1.好きなタイミングで戻したい位置にファイルを戻す事ができる。
スクリーンショット 2020-09-18 23.36.57.png

上図の様に、開発の日にちが経てばファイルの中身は改編されていく事になります。Gitは一旦書き換えてしまったファイルを任意の地点まで戻りたい場合、簡単に戻す事ができます。(ロールプレイングゲームのセーブポイントの様な機能を想像してもらえれば、わかりやすいと思います。)
特に新しい機能を実装したいときに使うと便利です。なぜなら、バグが発生した時にどこから修正すべきかを簡単に段階を踏んで見直す事ができるからです。なおこの使い方は、1人で開発を進める時にも有効です。

2.同じファイルの同じ箇所を同時に2人以上が編集してしまう事を防止できる。
スクリーンショット 2020-09-19 8.40.38.png

複数人での開発だと上図の様な事が起こりえます。もしファイルが次から次に上書きしていく様な管理方法だと複数人が同ファイル・同箇所・同時期に編集した場合、意図しない動作やバグが発生するだけでなく、後々の現状把握が難しくなってしまいます。こういった場合を想定してGitは複数人からの同ファイル・同箇所・同時期の修正があった場合にお知らせをしてくれる機能が搭載されています。

まとめますと、

  • 一旦書き換えてしまったファイルを任意の地点まで戻りたい場合に簡単に戻す事ができる
  • 複数人からの同ファイル・同箇所・同時期の修正があった場合にお知らせをしてくれる機能がある

この2点からGitは円滑に開発業務を行なう上で非常に便利である事から実際の業務で採用されている企業が非常に多いのだと私は思っております。ですので、これからチームで開発する事を前提にプログラミングをされている方は言語の習得と同様にGitの使い方も習得できる様に是非取り組んでみてください!

Gitのイメージ図

Gitを理解するに当たって大きな2つの流れがあります。それは、Gitと個人の関係と、Gitとチームの関係です。以下がイメージ図です。

1.Gitと個人のイメージ図
スクリーンショット 2020-09-19 17.01.10.png

2.Gitとチームのイメージ図
スクリーンショット 2020-09-19 21.04.57.png

開発を行なうにあたって、個人はまず図1の様な流れで開発を行っていきます。それと並行してチームメイトも同様に開発を進めていく事になります。そして、区切りの良い段階で図2の様に皆とファイルを共有して作成していきます。

細かい流れはまた後に説明していきますが、ここではこういった流れで開発を進めていくのだなぁという事をイメージできる様にしておいて下さい。

用語の説明

前節の図で出てきた用語を簡単に説明しておきます。

  • 作業用ディレクトリ・・・一般的にはフォルダと呼ばれるもの。この中にHTMLファイル、CSSファイル、JavaScriptファイル、Rubyファイルetc...を入れて作業を行っていきます。
  • リポジトリ・・・ファイルやディレクトリの履歴を管理する場所のことです。
  • ローカルリポジトリ・・・自分のパソコン内でバージョン管理するために作成したリポジトリ
  • ステージング・・・作業用ディレクトリからローカルリポジトリにファイルを置くための前段階です。(ステージングの必要性は今回は言及しません。ある程度理解ができてきたら、調べてみてください。)
  • リモートリポジトリ・・・ネット上に存在するリポジトリ。ファイルをアップロードした状態でファイルを管理するもの(具体的なGitホスティングサービスはGitHub、Bitbucketなどがあります。)

できるだけ簡潔に,難しくなりすぎない様に説明しました。意味が不足していたり、多少の齟齬のある箇所もありますが、大体の意味は捉えたつもりです。理解が進んだらより詳しい記事で是非学習してみてください!

ローカル環境とリモートのフロー図

ローカル環境とは、自分のPC内の環境のことです。下図だと緑色の部分がローカル環境を指します。
下図はどういったコマンドを叩くと実行できるのかをお伝えしています。
スクリーンショット 2020-09-19 23.01.42.png
それぞれ段階を進めていく為のコマンドが存在します。次に実際の作業フローをお伝えしていきます。

共同開発での作業フロー(全体)

ここからは複数人の共同開発を想定して、実際の作業フローを具体的に書き進めていきます。
0. リモートリポジトリをクローンしてコードをローカル環境に入れる
1. ブランチを作成して(切って)、ブランチに移動する
2. 何かしらファイルに変更を加える
3. git addコマンドを用いて、変更したファイルをステージングに追加する
4. git commitでステージングにあるファイルをローカルリポジトリへ追加・変更を加える
5. 2~4を繰り返す
6. git pushでローカルリポジトリの内容をリモートリポジトリ(GitHub)に反映させる
7. プルリクエスト(通称プルリク)を作成してチームリーダー等にレビューをしてもらう
8. 承認されれば、masterブランチにマージされる(共同開発の初期ではほとんどの場合、自分でする事はないと思います。)
9. masterブランチに移動後、git pullコマンドでリモートの最新状態をローカルに反映させる
10. 1に戻る

大まかな流れとしては、この様な流れをとる事になると思います。ここからは、コマンドの使用方法も含めてより詳細にお伝えしていきます。

具体的な流れ~その0(クローン作成)

この記事での共同開発の定義

まず、ご自身が共同開発に取り組むに当たって2パターンの開始方法が存在します。

  1. ご自身がプロジェクトを立ち上げて、仲間を集う場合
  2. 誰かが立ち上げたプロジェクトに参画する場合

この記事では、プログラミングの学習を始めたばかりの方を対象にした記事ですので、最初からご自身でプロジェクトを立ち上げるという方は少ないと思います。ですので、今回は2の場合で話を進めていきたいと思います。

なお、今回説明で使用するGitホスティングサービスは「GitHub」です。

共同開発の準備

共同開発に参画をして始めに行なう事は、共同開発を行なうリモートリポジトリのURLを用いて、GitHub上のファイルの内容をローカル環境にコピーする事です。
下はイメージ図とコピー場所です。

スクリーンショット 2020-09-21 12.26.02.png

イメージ図の下の様に共同開発を行なうリポジトリにアクセスして、赤丸の部分をクリックします。そうすると横に書かれたURLをコピーしてくれますので、これを下のコマンドを用いてローカル環境にクローン(複製物)を作ります。(一般的にはこれを「クローンする」と呼んでいます。)

git clone [クローンしたいリポジトリのURL]

コマンド実行後、このファイルのリモートリポジトリはクローン元のリポジトリに紐付けされます。
これで共同開発の準備ができました!
ここの作業は1プロジェクトにつき1回だけ行ない、次からの作業は繰り返して行ないます。

具体的な流れ~その1(ブランチ操作)

ブランチを理解する

次にブランチについてお伝えしていきます。まずブランチとは、goo国語辞書では次の様に説明されています。

枝・枝分かれしたもの。部門・分科。

Gitにおけるブランチも同様に枝分かれをして各々で開発を進めていくという認識で大丈夫です。
具体的には、

  • Aさんはログイン機能を実装する
  • Bさんはトップページを実装する
  • Cさんはアカウントの編集ページを実装する

といった様にそれぞれ担当を決めて開発を行ないます。イメージ図を表すと以下の様になります。

スクリーンショット 2020-09-21 17.48.19.png

この様にブランチを活用すると2つの点でメリットがあります。

  • 複数の変更を同時進行で可能になる点
  • 別のブランチで作業をすることで他のブランチに影響を与えずに作業が可能になる点

以上の点からGitを用いた開発では、ブランチの機能を利用する事が一般的です。
なお、ブランチを作成する事をブランチをきるといった表現でよく使います。

ブランチ操作で扱う基本のコマンド

ブランチ一覧の確認
git branch
ブランチの切り替え
ブランチAに移動する
git checkout [ブランチA]
bオプションを使ってブランチBを作って移動する
git checkout -b [ブランチB]

具体的な流れ~その2(ステージングへの追加~ローカルリポジトリの追加)

ブランチを切って、そのブランチ内で必要な機能が実装できたら、リモートリポジトリに反映させたい訳ですがいきなりはできません。なのでその前段階として、まずローカルリポジトリに反映するところまで見ていきましょう。
下図が作業用ディレクトリ~ローカルリポジトリまでの道のりです。
スクリーンショット 2020-09-21 18.50.26.png

作業ディレクトリ→ステージング

まず1の作業から行ないます。
作業ディレクトリ→ステージングへ上げるコマンド
git add [ファイル名]
カレントディレクトリ(対象にしているディレクトリ)以下のファイル全てステージングに上げるコマンド
git add .
ファイルがステージングにあるかどうか確認する為のコマンド
git status
スクリーンショット 2020-09-21 22.08.02.png

上図の赤線の様にコマンドを打ち込むとレスポンスが返ってきます。
index_add.htmlファイルはあらかじめステージングに上げておいたので、緑色の表記で返ってきます。これが正しい挙動です。
それに対して、index_not_add.htmlファイルはステージングに上げておりません。そうなると赤色の表記で返ってきます。この場合は、git addコマンドでステージングに上げる作業を行ってください。
もう一度確認すれば、緑色の表記で返ってきますので、それでOKです。

ステージング→ローカルリポジトリ

次は2の作業に移ります。
以下のコマンドでステージングにある全てのファイルを1つのコミットととしてローカルリポジトリに反映させます。(コミットとは、新しく作成・編集したファイルを確定させるという様な意味)
git commit -m “ログイン機能の実装”
mオプションでコミットに対するメッセージを追加できます。後でリモートリポジトリで確認する際に一目でどのコミットかを見分けられるので便利です。

具体的な流れ~その3(リモートリポジトリへの追加~masterブランチへのマージ)

リモートリポジトリへの追加

いよいよリモートリポジトリへファイルを追加していきます。イメージ図は以下です。
スクリーンショット 2020-09-21 23.10.26.png
originというのはリモートリポジトリのニックネームです。
以下のコマンドを入力すると、リモートリポジトリにブランチが生成されます。
git push origin [ブランチ名]

プルリクエスト(プルリク)とは?

git pushコマンドを実行して、無事に処理が成功するとリモートリポジトリにも同じブランチが生成されます。また、それと同時にプルリクエストというものも生成されます。
プルリクエスト(プルリク)は、開発メンバーにコードの中身を見てもらい、修正するか・採用するかを確かめる場所です。
1人で作ると気がつかないコードの指摘やバグや記述ミスの発見ができ、コードの品質を高めるのに役立つ機能です。
以下がプルリクエストによる流れのイメージ図です。

スクリーンショット 2020-09-22 10.58.39.png

プルリクエストの生成方法

先ほどもpushが成功したらプルリクエストが生成されると説明しましたが、具体的には下図の様にポップアップとして表示されて、そこをクリックして作成していく流れとなります。

スクリーンショット 2020-09-22 11.23.39.png
続いて、クリックすると下図の様な画面に遷移します。
スクリーンショット 2020-09-22 11.31.12.png
ここでは、プルリクエストについてのタイトル・詳細を記入します。
書き方はチームで決める事になると思いますので、開発リーダーの方にお聞きになると良いと思います。ここでは割愛致します。
タイトル・詳細を書き終えたら右下の緑のボタンをクリックするとプルリクの作成が完了して、チームメンバーに共有されます。
クリック後は下図の様な画面に遷移します。

スクリーンショット 2020-09-22 11.52.53.png
上図の上の赤枠のところで開発メンバーの修正依頼を受け付けます。チャット形式でのやり取りなので時系列に沿って依頼を確認する事ができます。
注意して頂きたいのが、下の赤枠のボタンです。このボタンはmasterブランチに合体する(マージする)ためのものです。間違って押してしまうと、そのまま実装したファイルが反映されてしまいます。
チームメンバーに大きな迷惑を掛けてしまうので、慣れないうちは確認せずに絶対押さないでください!!

具体的な流れ~その4(リモートリポジトリ→ローカルリポジトリ)

無事に開発メンバーからOKを頂いたら、マージ後にmasterブランチに反映されます。よって行ってきたタスクは終了です!(おめでとうございます!(^^))

最後にリモートリポジトリの最新の状態をローカルリポジトリに反映します。そうする事によって他の開発メンバーが実装してくれたファイルの編集(コミット)が自分のローカルリポジトリにも反映されます。
以下がそのイメージ図です。
スクリーンショット 2020-09-22 13.48.10.png
まず、以下のコマンドで作業を行っていたブランチから、masterブランチに移動します。
git checkout master
masterブランチに移動できたら、以下のコマンドでリモートリポジトリの内容をローカルに反映させます。
git pull origin master
ここまで出来たら次は具体的な流れ~その1(ブランチ操作)に戻り、新しいタスクに取り掛かってください。
以上が「Gitを使った基本的な開発の流れ」の説明でした。

さいごに

長々と最後までお付き合いいただき、本当にありがとうございました。これから「プログラミングを学習していこう」という方や「共同開発に興味はあるけど、Gitはまだよくわからない不安だ」という方のお力になりたいと思い、今回書かせていただきました。
そういった気持ちがある一方で、私自身もプログラミングを学習し始めて、まだ1年と経っていない身であるので偉そうな事は言えないとも思っておりました。なので、これからお互いに切磋琢磨して技術を磨いていけたらと思ってます!
今回の記事は単なる執筆に止まらず、自分の学習してきた内容を頭の中で整理をしながら言語化する事で私にとってもすごく勉強になりました。「学習しながらアウトプットは間違いなく最強である」を確信しました!
また、時間を作りこういったアウトプットを増やしていきたいと思います。
(この記事があなたのお役に立てた記事でしたら是非LGTMのボタンを押して頂けると更に頑張れます!)
また、その時は是非よろしくお願いします☆

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

そろそろ本格的にプログラミング用語を置き換える時期なのかも

先日GitHubから以下の発表がありました。
GitHub to replace 'master' with 'main' starting next month /
GitHub来月10月からブランチの「master」を「main」に名称を置き換える

sample.png

GitHubでは、来月からmasterブランチという名称は使わず、mainブランチという名称に変更するという発表でした。来月ってもう普通にすぐだけど、、、。

実は元々数ヶ月前に発表はあったんだけど、そこまで日本では話題にならなかった。
GitHub abandons 'master' term to avoid slavery row

なんでこうなった?

大体の人はニュースなどで話題になったり、最近ではテニスの大阪なおみ選手が身につけているマスクで再度日本中でも話題になったので知っている人がほとんどだと思いますが、アメリカで起きた黒人差別などの事件から起きた「black lives matter(通称:BLM運動)」から派生した動きです。

元々、プログラミング用語というかIT業界における用語には黒人差別に近いような言葉だったり、奴隷制度を連想させるような言葉があります。日本人だと特段横文字ってこともあって特に意識する人もそんなに多くはないと思いますが、大体のIT用語は世界共通で使われているので、外国の方では結構その用語を使うこと自体に抵抗があるらしい。

具体例

  • master / slave
    • 主人 / 奴隷といった事を意味する(奴隷制度連想)
    • こちらの業界で使う意味としてはサーバーなどの名称によく使います。日本人からするとslave = サブ機みたいな認識くらい
  • Whitelist / Blacklist
    • ホワイトリスト / ブラックリスト(黒人/白人など"肌の色"を連想させるような用語)
    • これはIT業界に限らずまあまあ使う。「ブラックリスト = 除外対象/悪質対象」「ホワイトリスト = 非除外対象」的な感じ
    • 「ブラック = 悪い」 「ホワイト = 良い」みたいな連想を促すので、master/slaveより露骨な言葉かも

これからどう変わっていくの?

既にTwitterやApple, GoogleやMicrosoftでは用語の代替が始まっているみたいです。

IT用語も「奴隷」廃止の動き 「slave」は「フォロワー」や「レプリカ」に__l_koya_twitter_png__-_ITmedia_NEWS.png

まだ言語自体の大体は混在していて
Master(マスター)/Slave(スレーブ)の代替語

  • leader/follower
  • primary/replica
  • primary/standby

Pythonはslaveを「worker」「helper」に、master processは「parent process」
プログラミング言語の中でも処理の名称が変わっていっている。

Blaklist(ブラックリスト)/Whitelist(ホワイトリスト)の代替語

  • blocklist/allowlist
  • blocklist/safelist
  • blocklist/passlist
  • denylist/allowlist
  • stoplist/golist
  • redlist/greenlist

とか会社によってまちまちだったりしているっぽい。
会社によって変わってくると職場が変わった時に混乱不可避になる(あと他社との打ち合わせの時とかに不便ちゃ不便

日本でもだんだんと差別用語を使わない流れに変わっていくかな

元々、上記で出てきた用語ってIT業界の中でもう既に定着してきている言葉で、会社の中でもめっちゃ普通に使ってしまうし定着してきている人からすると違和感が半端ないと思います。ただ時代はグローバル「日本だけまだ差別用語使って仕事してんの?w 遅れてんねw」とか外国の人に言われたりしたら単純に会社としても恥やん。
特に外国の方がいる他社との取引がある会社では、上記の用語を気を付けなくてはいけない。

て事で社内からまずは改革していくのが良いのかも。

ポエム

用語がツール毎や言語によって変わるの辛いから統一してほしい(ボソっ
GitHubがmainブランチに変更しているのに、Git自体がmaster使ってたりするとちょっと不便やで...!!
ついでにSourceTreeとかもどうなるんでしょか...!!

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む