新規ユーザーを作成した後、sudoの権限を与えるコマンド。
(基本的にrootで作業したくないため)
一行だが
gpasswd -a username sudo
※usernameは任意のユーザーID
2016年9月28日水曜日
2016年9月27日火曜日
ubuntuでファイヤーウォールを導入してポートを制限する
Vultrでクラウドサーバーを本格的に使い始めたのでファイヤーウォールを導入して一応セキュリティ対策。
- ファイヤーウォールを導入
- sudo apt-get install ufw
- Port設定(SSHとTCPのみ許可する)
- sudo ufw allow 22
- sudo ufw allow 8888
- 有効化
- sudo uff enable
- 確認
- sudo ufw status
ubuntuで自分のサーバーの空いているportを調べる
こちらをそのまんま実行。
- nmapというportスキャンのアプリケーションをインストール
- sudo apt-get install nmap
- 自分のサーバーの空いているportを調べる。
- sudo nmap -sTU localhost
2016年9月26日月曜日
node.js開発環境を構築したfor Mac(Macは結果的に関係なかった)
自分で使いやすい環境は何かなと、試行錯誤してきた結果、やっと何となく落ち着くやり方が見えてきたので、記録しておく。
- サーバーを立てることにした。Vultrにした。東京リージョンがある。なんとなくAWSとかは敷居が高い気がした。慣れたubuntuを速攻インストールできる。後発なので管理コンソールが洗練されている気がする。最低月5ドルなので、お小遣いも減らない。ここから登録してもらえるとさらにお小遣いが減らないので嬉しい。
- ubuntu16.04で環境整備
- adduserでユーザー追加(useraddをいままで使ってた。こっちのほうが便利)
- apt-getでnode.jsをインストール
- 同じくnpmをインストール
- npmでexpressをインストール
- 同じくexpress-generatorをインストール
- 同じくpug(旧jade)をインストール
- Visual Studio Codeをエディタとして使う。プラグインを導入。
- ftp-simpleプラグインを導入して直接サーバーのファイルを編集することにした。
- あとはHTML、Jade関連のプラグインをインストール。
これで最低限のことができる。Gitとかはおいおい。とりあえずRCSでいいかな。
これまでやったこと。
- node.jsのチュートリアルでWebサーバーをつくってjavascriptを基本を学習。
- 役に立ったサイト。(下記以外もいろいろお世話になりました。)
- サンプルHTML(CSSフレームワークbootstrapの学習)ファイルを作成
- 役に立ったサイト
- もう一歩進んでテンプレートエンジンJadeの学習<今ここ
これからやりたいこと
- expressをつかってチュートリアルアプリの再作成。
- socket.ioを使ったチャットプログラムの作成。
IT開発プロジェクトの見積
今回は、見積について少し書いてみたいと思う。
プロジェクトの初期段階での見積もりの不確実性と、サイクリックな再見積もり(アジャイル系アプローチ等)の提案についてはいろいろな人が別に述べていると思うので割愛する。
プロジェクトの初期段階での見積もりの不確実性については、いくつかの要素があるのではと考えたので整理したい。なぜプロジェクトの初期段階で見積もりが不正確なのか?
もちろん前提として、プロジェクトの戦略目標は定まっているものとする。(定まっていないなら必ずプロジェクトは崩壊する)
※このへんのところは名著 失敗の本質―日本軍の組織論的研究
中公文庫
ISBN-10: 4122018331
を読んでほしい。
見積もりの不確実性の根本は、「決まっていないこと、わからないこと」の多さにあると思う。よってサイクリックな再見積もりによって不確実性をだんだんと減らしていく。
しかし最初の段階でも「決まっていること、わかること」は当然ある。そして「決まっていること、わかること」は、「決まっていないこと、わからないこと」より相対的に多いと考える。
8:2の法則から考えると8割ぐらいの要求は決まっていて、またプロジェクトコストに対する8:2の法則から考えると8割の決まっていることは、最終コストの2割で実現できるのでは?と考える。
じゃあ残りの2割の要求は?と考えるとそれは、レアケースに対する要求ではないか?
とするとプロジェクトの初期段階ではその決まっていることに焦点をあて見積もると、精度の高い見積もりが得られるのでは?と考える。そして初期段階で決まっていることことが、そのプロジェクトのコア機能であり、その時点で「決まっていなこと、わからないこと」は捨て置いて、計画してプロジェクトをスタートさせれば良いのでは?残りのレアな機能については、コア機能の完成後、おっつけ組み込むアプローチがあるのではないか?
最初にこれがアジャイル的進め方かなあと思ったが、ちょっと違うかもしれない。もう少し深堀して考える必要があると思う。
※「決まっていること、わかっていること」の数だけでいうと、8割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな?書き直すのが面倒なので補足しておく。
プロジェクトの初期段階での見積もりの不確実性と、サイクリックな再見積もり(アジャイル系アプローチ等)の提案についてはいろいろな人が別に述べていると思うので割愛する。
プロジェクトの初期段階での見積もりの不確実性については、いくつかの要素があるのではと考えたので整理したい。なぜプロジェクトの初期段階で見積もりが不正確なのか?
もちろん前提として、プロジェクトの戦略目標は定まっているものとする。(定まっていないなら必ずプロジェクトは崩壊する)
※このへんのところは名著 失敗の本質―日本軍の組織論的研究
中公文庫
ISBN-10: 4122018331
を読んでほしい。
見積もりの不確実性の根本は、「決まっていないこと、わからないこと」の多さにあると思う。よってサイクリックな再見積もりによって不確実性をだんだんと減らしていく。
しかし最初の段階でも「決まっていること、わかること」は当然ある。そして「決まっていること、わかること」は、「決まっていないこと、わからないこと」より相対的に多いと考える。
8:2の法則から考えると8割ぐらいの要求は決まっていて、またプロジェクトコストに対する8:2の法則から考えると8割の決まっていることは、最終コストの2割で実現できるのでは?と考える。
じゃあ残りの2割の要求は?と考えるとそれは、レアケースに対する要求ではないか?
とするとプロジェクトの初期段階ではその決まっていることに焦点をあて見積もると、精度の高い見積もりが得られるのでは?と考える。そして初期段階で決まっていることことが、そのプロジェクトのコア機能であり、その時点で「決まっていなこと、わからないこと」は捨て置いて、計画してプロジェクトをスタートさせれば良いのでは?残りのレアな機能については、コア機能の完成後、おっつけ組み込むアプローチがあるのではないか?
最初にこれがアジャイル的進め方かなあと思ったが、ちょっと違うかもしれない。もう少し深堀して考える必要があると思う。
※「決まっていること、わかっていること」の数だけでいうと、8割よりずっと少ないかもしれない。無意識のうちにビジネスに対する重要性を掛け算しているのかな?書き直すのが面倒なので補足しておく。
2016年9月20日火曜日
IT開発プロジェクトと建築土木
もうIT関連の仕事に携わって20年ぐらいになるが、関係したプロジェクトは成功も失敗もある。自分自身がPMとして失敗してしまったプロジェクトもあるし、さまざまな担当して担当タスクを失敗してしまったこともあるし、自分は失敗しなかったがプロジェクトとしては、失敗だったこともある。
ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能(品質)が+30%の幅の中に収まることと考えている。(甘い見方かもしれないが)
ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。
ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。
ちなみに自分の中では、当初のシステムの目標に対し、期間、予算、機能(品質)が+30%の幅の中に収まることと考えている。(甘い見方かもしれないが)
ITプロジェクトを推進するにあたって、例えば「ビルを立てる」といった建築土木のプロジェクトの進め方との関連を意識したりしてきた。
ITプロジェクトと建築土木の考え方の間には類似点があると考えていた。
- ものすごくざっくりというと作業工程が計画〜設計〜実装(建築土木ではなんと表現するのだろう)と工程の進み方が似ていると考えていた。※アジャイル開発においても基本これは変わらないと考えている。進め方の粒度の違いだけ。
- 何十〜何千という見知らぬ人間が集まって目標を完遂する。各工程でスペシャリストが集まり、ものを作り上げていく。釘を打つ人と壁紙を貼る人の間のコミュニケーションはどのようにとっていくのだろうとか。
- 予算、工期、品質の目標がある。
建築に失敗したビルというのは聞かないが、(実はあるのか??)、失敗したITプロジェクトはごろごろある。なぜなんだろうと考えた結果、計画局面の決定ぐあいが違うのでは?と思い至った。大きなビルならモックアップをつくって検証すると聞いたことがある。また設計図など共通認識を持つための情報ツールがもう枯れた技術となっていて実装時に迷うことがないのでは?(記法なども統一されているだろうし、A社の設計図は、全然別のB社が完全に読み取れるはず)
とするとITプロジェクトにおいても
- 計画、設計局面において、できるだけ決定できることは細かく決定しておくこと。
- 決定したことの共通理解を関係者がもつこと。また理解のための共通言語(設計図に相当するもの)もつこと。
- 上記とも関係するが、共通理解のためのイメージ合わせのためプロトタイプを利用すること(モックアップに相当。プロトタイプの再利用など考えず使い捨てにしたほうが良いと思う)
実装より計画を!(アジャイル宣言に反している気がしますが。。)
に重点をおくと現状が改善されるように思った。通常のウォーターフォール開発では計画〜要件定義までに予算の2割も使えば多いほうだが、(計画には1割も使っていないのでは?)これを少なくとも3割程度までUPすると後半の手戻りも少なくより成功に近づくのではと考えた。
2016年9月16日金曜日
IoTについて勉強した
IoT(Internet on Thing)とは何か?を勉強した。
文字通り、あらゆるものがインターネットに接続されること(冷蔵庫とか家電)と最初は理解していた。で接続して情報を収集して何になるの?と考えていた。
IoTとは、以下のように定義されるらしい。
文字通り、あらゆるものがインターネットに接続されること(冷蔵庫とか家電)と最初は理解していた。で接続して情報を収集して何になるの?と考えていた。
IoTとは、以下のように定義されるらしい。
- モノからセンサーによっていろいろな情報をインターネット経由で収集する。
- 収集したデータを蓄積する。
- 蓄積されたデータを分析する。
- 分析に従って、必要に応じてモノにフィードバックする。(センサーついているモノに直接フィードバックすることもあれば、分析結果を社会や企業、の今後に生かすことも指すらしい)
センサーから収集し、蓄積したデータは膨大なものになるので、その分析には人工知能も関連してくる。(人知では分析しきれないほどのデータ量になりがちのため)
とすると応用領域は、例えば電力のスマートメーターによって電力の使用量の傾向の蓄積であるとか、自動車からの交通量の状況蓄積と対策とか、自動車事故を起こしやすい状況の分析とか。また医療分野についてもいろいろな応用が考えられる。介護分野についても同様。(しかし金融の投資動向とか分析されると一般人は、大手金融機関の思いのままになるんだろうなあ)
とするとその情報の管理が大変重要になる。各々のデータが個人情報と結びついた時、その個人の生活が赤裸々になってしまう可能性がある。(もうAmazonやGoogle、Appleにはかなりの個人情報を握られてしまっているが)
2016年9月現在、政府から情報銀行なる構想が提言されたが、個人の購買行動や医療情報などは国に握られたくはないとの思いがある。年金の管理のずさんさ、住基カードの有様をみるととても役所に自分の情報を預けたくはないと考える。(マイナンバーを利用したいのだろうけど、ビッグブラザーの影がチラチラ見えて来る)
登録:
投稿 (Atom)