Jekyll基本操作メモ

マークダウンで静的サイトが作成可能なツールJekyllの基本操作をメモ。
GitHubにホスティングすると、GitHub Pagesにてお手軽に公開可能です。

＜環境＞
【Ubuntu 16.04.2 LTS】
【jekyll 3.0.1】
　
　　
以下、GitHubに、適当なポジトリを作成した後に実行しています。
　
　
Jekyllインストール

sudo apt install jekyll

適当な名前でディレクトリを作成する。（MyJekyllとか。）
そこに index.mdを作成し、以下のように編集。

---
---
Hello Jekyll!

以下を実行すると、公開するhtmlファイルが作成される。 （「_site」というディレクトリに存在する。）

jekyll build

以下のコマンドで、ビルトインWebサーバ稼働。

jekyll serve

mdファイルを編集→build
という手順で作成する。

完成したら、git push。
その後、リポジトリの Settingsにて、GitHub PagesのSourceを、「None」→「master branch」等に変更し、Save。
URLはリロード後、「Your site is ready to be published at xxx」という形式で示してくれている。 　
　

ブログの雛形作成

以下のコマンドでブログの雛形を作成できる。

jekyll new (ブログ名)

記事が１つ自動生成されている。
記事の追加する場合、「_posts」ディレクトリに、ファイルを追加。

---

＜参考サイト＞
Jekyllいつやるの？ジキやルの？今でしょ！

Cent OS：デスクトップ環境

【環境：CentOS Linux release 7.3.1611(Core)】

以下のコマンドでインストール。

 yum -y groups install "GNOME Desktop"

切り替え

startx 

フィボナッチ工数見積に衝撃を受け、実践してみた感想

フィボナッチ工数見積という手法があるらしい。 jabba.cloud

凄まじい衝撃を受けたんで、早速試してみた。
まだ開発に入ってないので、今回、適用してみたのは見積フェーズのみ。
それだけでも、十分に有用だという実感があった。

超ざっくり説明すると、以下の段取りで進める。

• 作業を細かい単位に切り出してチケット化する
• 各チケットに、２、３、５、８、１３、２１のどれかのポイントを付ける。重いタスク程、高ポイント。
  （ポイントに単位は無い。ただの数字）

詳細はリンク先を参照して下さい。
ちゃんと適用する場合は、開発フェーズにも突っ込みます。そして今回初めて使うんで、過去の累積などは無い。
今回はポイントに３４も追加して実践しました。
　
以下、やってみた感想。
実践し、自分なりに感じたメリットなどを書いています。
また、上記のリンク先の記事を先に読んでおいた方が、以下で何を言っているのか分かりやすいかと思います。 　

重いタスクの見積がやりやすい

以下、要約して抜粋した内容。

ポイントを１、２、３、..８、９、１０と連続した数字ではなくフィボナッチ数列にしているのには理由がある。
　
実務においてタスクの重さは指数関数的に伸びていく。重量なタスクにはモノによって大きな差が出る。 また、重くなるにしたがって差を大きくすることでその差をより意識するように仕向ける。
　
軽いタスクの場合、２や３の差は小さく多少の誤差が出ても大きな影響は無い。見積もりの重要性は重いタスクほどにある。
　
重いタスクを「９かな？それとも１０かな？」とじっくり考えても９と１０の差は１でしかでなく、９と１０の差を意識するのが難しくなる。
　
ここをフィボナッチにすることで、１３と２１の差はとても大きく、「あれが２１だったらこれは１３にすべきだろ」と、より明確に区別することが可能になる。

これは本当に目から鱗。
特に、未知の部分が多い機能の実装については、見積が非常に難しい。
これは…5人日？6人日？？といくら考えても、答えなんて出てこない。
が、少し手を動かしてみて
「おおお！これは難しい！２１ポイントで。いや、まだ××という問題もあるぞ…。それなら、その次の３４ポイントだな。」
といった感じで、次の数字が明確化されているので、重いタスクに数字を付ける行為がやりやすい。
２１ポイントじゃ低すぎるな。じゃ、２５ポイント？２６ポイント…？と、変に悩まなくて済む。 　
　

タスクの重さを測る事に注力できる

人日（人月）で考えないので、余計な考えを挟まなくて済む。
具体的には、
「これは３人日で。いや…３日で出来るかな…？」とか、
「自分でやったら２日で終わるけど、Aさんがやったら４日かな…」とか、
「これは１日で終わってほしいけど、新人のB君にタスクを振る事を考えたら、３日…いやいや取り過ぎか。２日かな。」
とか、そんな感じの内容。
人日で考えると、どうしても作業担当者の開発力にも視点が行きがちになる。
その点、単位の無いポイントで考えると、単純にタスクの重さを測る事だけに注力できる。 　
　

提案から実践までのハードルが低い

業務改善や新しい手法の導入は、受け入れられにくい事も多い。
慣れ親しんだ業務のやり方を変えたり、新しいツールの使い方を覚えたり、そのツールにおける概念を覚えたりするのに、抵抗感を感じる人が少なからず居るからだ。
そういう人達を説得するために、デモを見せたり、資料を作ったり、ツールを使うための環境を整えたり、様々な検証をしたり・・・といった作業は、かなり骨が折れる。
『好奇心＞労力』という図式が成り立っているうちはいいが、そのうち通常業務が忙しくなるか、「お前、仕事しないで何やってんの？」という冷ややかな視線と言葉で徐々にテンションが下がってくるかで、
『好奇心＜労力』となってしまった瞬間に、提案活動は停滞もしくは終焉に向かう。
　
その点、フィボナッチ工数見積は、提案のハードルがめちゃめちゃ低い。
準備なんてほとんど要らないし、必要なツールも無い。効果や背景も、上記のブログ１記事を見てもらうだけで十分。
　
また、見積について、確固たる手法を確立させている人は、それほど多くないと思う。
それこそ、見積もりなんて星占いレベルという意見もあるぐらいだ。毎回毎回、確たる拠り所や足がかりは無く、これなら絶対に行ける！という確証など無いまま、内心恐る恐る出しているというのが実情だと思う。
つまり、見積については、多くの人が拠り所を求めている。何かいい方法はないものか…　と常に頭を抱えている。
組織において、提案を受け入れやすい土台が既に整っている可能性は高い。
　
加えて、「この言語は最高だ！」「このフレームワークは最も洗練されている！」といったポリシーを持っている人は居ても、見積手法についてポリシーを持っている人など皆無に等しい。
その点でも、スムーズに受け入れてもらいやすい材料になっている。
　
　
　
　
以上が、感想。
　
実践した結果、ポイントとボリュームを見ると、概ね正解に近そうな数字が出た。
　
でも最終的には人日（人月）で資料を作らないといけなかったので、試しにちょっとだけポイントあたりの労力を測ってみた。
具体的には５ポイントのタスクを消化し、何人日が妥当だろうか。と検証してみた。
すると、今回のプロジェクトでは、５ポイントが大体１人日くらいかな？という事が分かり、その係数を全体のポイントに掛け、見積の数字とした。
結果、割と正解に近い数字が出たと思う。人日で見積もったとしても、大体これぐらいになったかな。という感触はあった。
　
仮に数字が大きく間違ったとしても、それは掛ける係数が間違っていただけで、手法としては間違っていないんじゃないかと思う。
正直、人日で見積もるよりも遥かに頭を悩ませる材料が少ないので、見積に苦労しているエンジニアは、是非一度試してみてはどうでしょう？
　
他にも実践する人が出てきて、成功例や失敗例、そして運用の知見がもっとネット上に蓄積されて行かないかな、と願い、微力ながらもそれに協力できないかと今回のエントリにしてみた。

GitHubだけでスライドが作れるサービス「GitPitch」の使い方

GitHubだけでスライドが作れるサービス「GitPitch」の使い方を、スライドにしてみた。

https://gitpitch.com/kakisoft/HowToUseGitPitch

GitPitchを使ってどんな事ができるのか、直感的に分かるようにしてみました。
　
基本的な使い方から、設定ファイルを使用した全体的なレイアウトの方法などをスライドにしています。

ASP.NET：1pxdeepを使用したBootstrapテーマ変更

「1pxdeep」という、Bootstrapテーマカラーを自由にカスタマイズできるサービスを利用し、ASP.NETに適用する手順です。

―１―
1pxdeepにて、「Seed color」ボタンでカラーを選択し、「Schema now」で内容を確認。
「DownLoad」ボタンをクリックし、アーカイブファイルを保存し、解凍する。
　

―２―
「scheme.less」を以下のように編集。
(保存時のSeed colorの値に変更する)
　

―３―
「1pxdeep.less」に以下の内容を追加。

@import "scheme.less"; // color scheme
@import "bootstrap.less"; // bootstrap
@import "1pxdeep.less"; // 1pxdeep theme

　

―４―
Bootstrap本家サイトの、「Download source」をクリックして、ソースを保存。その後、解凍。 　

―５―
Bootstrapソースの「less」フォルダに、編集した「scheme.less」と「1pxdeep.less」を保存。 　

―６―
Lessコンパイラをインストールしていない場合、以下のコマンドでインストール。

npm install -g less

npmが無い場合、Node.jsをインストール。 　

―７―
lessフォルダに移動し、ターミナルより以下を実行。

lessc 1pxdeep.less bootstrap.css

―８―
作成された「bootstrap.css」ファイルを、Contentフォルダに格納する。 　

―９―
完了。

VMware：Ubuntuインストール直後にやった事のメモ

＜環境＞
【VMware Playser 6.0.7】
【ホストOS：Windows7】
【ゲストOS：Ubuntu 14.04 LTS】

ホストとゲスト間のクリップボードの共有

ゲストOSとホストOSとで、クリップボードを共有する設定。（最近のバージョンでは、インストールした時点で共有されているようですが。）

メニューより以下を実行。

Player→管理→VMware Toolのインストール

【"VMware Tools"にアクセスできません】というエラーが発生したら、一度「Player→取外し可能デバイス→CD/DVD」にて認識されている全デバイスを外した後に、実行する。

デバイスを認識出来たら、/media にアクセス。
/media/<USERNAME>/VMware Tools/VMware Tools-9.6.5-2700074.tar.gz
をコピーし、適当な場所に展開。

展開コマンド

tar xf VMware Tools-9.6.5-2700074.tar.gz

展開したフォルダに移動後、以下を実行。

sudo ./vmware-install.pl

途中、何度かダイアログが出るが、全部[ENTER]でOK。 その後、再起動。

sudo reboot

固定IP設定

/etc/network/interfaces を編集。
以下、設定例。

auto eth0
iface eth0 inet static
address 192.168.233.2
netmask 255.255.255.0
gateway 192.168.233.1
dns-nameservers 192.168.1.1

gatewayt、dns-nameserversなどは、環境次第では記述しなくてもいい。
仮想マシンの設定の「ネットワークアダプタ」を、「ブリッジ」に設定。
　
　
　

ネットワーク設定の注意点

VirtualBoxがインストールされている場合、そのアダプタをVMwareが認識しないようにしておく。

仮想マシンの設定→ネットワークアダプタ→アダプタの設定→VirtualBox Host-Only Network
チェックをOFF

Ubuntu：ASP.NET MVC 基本操作

【環境：Ubuntu 16.04.2 LTS】

以下のコマンドで、ASP.NET MVCの雛形を作成できます。

sudo dotnet new mvc

ビルトインサーバの起動と実行は以下のコマンドで。

sudo dotnet run

実行時、Assets file 'project.assets.json' not found.というエラーが発生した場合、以下のコマンドを実行。

sudo dotnet restore