はじめに
何かを作る上で形式を設定する必要があると考えています。
プログラミングを行う上ではRFC、JISなどの規定があり、言語ごとのコーディングルールも
あった上に、前述に影響外のところで顧客や企業や開発チーム内のルールがあります。
一見すると気難しい、うざったい印象を持たれるでしょうが、形式を持たせることで
共通化が図りやすくなり、可読性や運用性が高まります。
ただこのwikiに書いていることは必ず貴方の会社や個人で使えば極楽になることを
約束したり、強制するものではありません。
仕事や日曜プログラマーもその方々の流儀があります。自分なりに自分の生産性や
運用性を考慮した上でご自身なりの形式を持たれることをおすすめします。
最初に用意するもの
・Git
・Gitクライアント（TortoiseGit、SourceTree、Git対応テキストエディタ）
・Virtualbox
・Vagrant
・DockerCommunityEdition
・Terraform
・Ansible
・Jenkins
・Docker compose
・Slackクライアント
・IDE（VisualStudioCommunity(VSC)、Eclipse、Xcode(
MacOS)など）
・テキストエディタ（VScode、SublimeTextなど）
ウェブサービス入会
・Github
・AmazonWebService
・GoogleCloudPlatform
・Microsoft azure
・IBM
Cloud（旧Bluemix、旧watson）
・Docker Hub
・CodePen
・Slack
・Line
運用
学習は「DockerHub」でソース管理をしていきます。
Gitのユーザは「admin」「worker」を作成。
adminは本ビルド、masterへのPUSH権限を有します。
workerはadminに対してPullrequestが出来る権限まで。
一人作業であっても、masterソースの更新権限をユーザを分けて行います。
手順は次の通りです。
１．workerは製造、UT、IT(JT)までが作業範囲
２．プルリク送る＝レビュー実施
３．OKなら、adminが（で）masterにPUSH(marge)
４．adminがフル・ビルド
５．問題なければProductionリリース
一人でやるのになんで？と思うでしょうが、作る人は作ることに専念し
管理する人は管理に専念するがベストと考え、一人でも担当を分けて
限りなく実務に近い環境が良いと考えたからです。
バグやQAですが、RedmineではなくSlackやLINEを使います。
（→
与太話）
構成
Githubを使ってGitで管理していく。
GithubはPersonal(Free)版を使うので十分。Personal版はリポジトリ―がオープンなので
他人から容易に見えてしまう。しかし作成できるリポジトリは無限で、同時利用者も無限な
ので勉強するときには良いと思う。
ちなみにDeveloper版は月＄８（約840円）、Team版は月＄９。Business版は＄21。
|
Personal |
Developer |
etc |
| per month |
0 |
7 |
|
| yen/m |
0 |
840 |
|
| yen/y |
0 |
10,080 |
|
| account |
personal |
personal |
|
| pub repo |
unlimited |
unlimited |
|
| collabo |
unlimited |
unlimited |
|
| private repo |
- |
unlimited |
|
| permission |
x |
x |
Team ver |
| SAML |
x |
x |
Biz ver |
| provision |
x |
x |
Biz ver |
| support |
掲示板 |
掲示板 |
Biz ver |
| SLA |
ｘ |
ｘ |
Biz ver |
Gibhubの亜種は数多くあるので興味があれば調べて欲しい。
最近は納品をGithub指定している会社もあるのでPersonal版だけでもいいので触れておいた方が良い。
ローカル
TOP
└SANDBOX
└999example 動作検証が修学のために仮作成するディレクトリ
└ASSET ・・資産（自社や自身で作ったオリジナル）
└※１
└RESOURCE ・・資産ではない利用するもの（購入物や、有期限だが無償利用できるもの等）
└※１
└PRODUCT ・・製品開発計画
└SOURCE 個々の製品ごとのソース（コードが主）
※１（子要素）
└LIBRARY ・・ライブラリ（サード製を含むモジュール類）
└IMAGE ・・画像、動画
└DOC ・・
設計書、要件定義、テスト計画書など
大別すると①SANDBOX、②LIBRARY類、③PRODUCTの３系統で、①～③は互いに
混ざらないようにする。
③PRODUCTで②LIBRARYを利用する場合は必ずコピーやFORKして利用する。
コードはGitからCloneは行わない。
Cloneしていいのは製造責任がある立場の人のみ。というスタンス。
メンバーはMasterをFORKして、PULLリクエストをリーダーに送る。
リーダーはレビューしてOKならBranchにPUSHする。
MasterへのPUSHは上位責任者がレビューして承認を得た場合のみ。
（自分一人の場合は自分が責任者なので意味ないが）
責任者のヒエラルキーはこんな感じ。
BizManager
└PRODUCT Producer
└PRODUCT Manager
└Manufacture Director
└Manufacture Leader
└Manufacture Worker
著作権
基本的にパブリックな位置で、CreativeCommons-非営利-継承です。
しかしPRODUCT（販売目的の製品）はこの限りではありません。
GPL、Apache、BSD、MIT、EPL等の
ライセンスは様々な条件を継承したり
一般公開する責任を課せられるため、製品ごとに向き不向きが強い。
ソースコードでは3000Step以下
１Class
１Module
且つ、ビジネスロジックに関与関係しないもの。という定義でここでは
扱いをします。
過去の判例を見ると1000ステップまでは著作権を主張できないとされて
いるようですが、3000まで拡大しても良いんじゃないかと。但しビジネス
ロジック＝販売目的の製品や顧客固有処理系を含む場合は除外する、と
すれば、今より自由度が上がるんじゃないかと思っています。
- 動画、画像、３DCG、音楽の著作物のPublic Domainは、
XGAサイズ以下
30秒以下
16小節以下
200文字以下
がPublicDomain対象になり得ると考えています。
こう考える基準は原稿用紙1枚分程度ならという個人尺度なので
裁判や判例から見たらどうなるかは知見が欲しいです。
権利を主張していてもREADMEや約款書、規定書を付けないものは
権利放棄をしていると見なしています。
権利を主張する書面を付けることは著作者の「義務」で「責任」です。
書くのが面倒だからって人が多いようですが義務を果たせない人は
自分の権利を放棄したと見なしていいです。っていう考えです。
一方で、利用者はREADMEが付いてない著作物を使用するか否かの判断は
個人も団体も方針をきっちり打つ出すべきです。
仮に著作者本人が訴えてこなくともSNSで吊し上げにされる可能性が
あるからです。吊し上げされた後の自信の商売に支障を来さないという
保証はどこにもありません。
チャットツール
Twitter、LINE、Slack、Discord、mastodonなどショートメッセージ用
チャットツールはたくさんある。
俺個人的に推したいのは「Slack」
なぜSlackを使えと言っているのかは、技術系ショートメッセージチャット
のデファクトになっていること。
API公開だけじゃなく自動応答チャットもあるし、界隈にあるノウハウが
非常に多いい。当然alexaやGoogleHomeとの連携連動もできるので
一人作業のときalexaはGHが相方となって作業をさせることも可能だからだ。
Skackは嫌。LINEがいい、いや独自に作るでもいいと思う。
自分の使いやすいチャットツールを使えばいいと思う。
必要なのはリアルタイムでチャットができ、自動応答を使える環境があり、
クライアントがコモディティであることだと俺は考えている。
社内での環境
セキュリティの高さは企業規模に比例していきます。
大企業ほど、個人情報や金品のやり取りを行う職種であれば携帯電話を
居室内に持ち込むことも禁止されている場合があります。
その場でサクサク、ガリガリとコーディングできればいいのですが
手間がかかる、１度つくったものをまた作りたくない等の不満は
あるのではないでしょうか。
就業先の社内に外部ネットに接続できる環境があることが前提に
なりますが汎用的なコードは外に置いてしまって、そこから引っ張って
きたほうが「楽」ですよね。
条件１．就業先から外部ネットに接続できる
条件２．Proxyがある場合、ProxyのIPやURLを確認できること
条件３．条件１の上で外部サイトからファイル等々をダウンロードできること
用意するものとして以下。
・Github（Personal）
・DockerHub
・Virtualbox
・Vagrant
・Ansible
・Terraform
・Nodejs/npm
・クラウド環境（AWS/GCP）
・クラウド環境のクライアントCLI
・OSイメージはDebian、
Ubuntu、CentOSのいずれか
もし職場で自席の作業PCでダウンロードが出来ない場合
・技術系ブログを開設
・ソースコードはベタ打ち
もし職場の自席PCから外部ネットに接続できない場合
・A4のファイルを作っておく
この場合、技術ネタブログを一旦作っておいてそれを
両面印刷しておけばいい。
社内に紙の持込みを禁止しているという企業は俺個人は
いままで聞いたことが無い。念のため事前確認したほうが
良いかもしれないがダメと言われたら諦めてそんな会社は
辞めた方がいいだろうｗ
最初のベターな環境だったらGithubに全ておいておいて
fork->Cloneすれば数分で自席PCですべてを用意できる。
Dockerhubもあればインフラ系を一気に用意できる。
最終更新：2018年04月02日 02:01
