かきスタンプ

福岡で物流系のエンジニアやってます

bootstrap:アイコンの上にバッジを表示する

こういう感じの。
f:id:kakisoft:20170718025617p:plain

ー html側 ー

<div class="container">
  <button class="btn btn-default btn-lg btn-link" style="text-decoration: none;font-size:45px;">
    <span class="glyphicon glyphicon-envelope"></span>
    <span class="badge badge-notify">5</span>
  </button>
</div>

CSS側 ー

.btn-default >.badge-notify{
   background:red;
   position:relative;
   top: 7px;
   left: -62px;
}

サイズを小さくしたい場合は、buttonでなく、aを使ったほうがよさそう。

AWS:rootユーザに切り替え

AWSは、通常 ec2-userでログインします。
rootユーザでログインを試みると、「Please login as the user “ec2-user” rather than the user “root”.」というメッセージが表示されますが、一度、ec2-userでログインした後、ユーザを切り替える事で、rootユーザでの実行が可能です。

  1. ec2-userにてログイン
  2. sudo passwd を実行し、パスワードを設定
  3. su - を実行。先ほど入力したパスワードを入力

Ubuntu 16:デバイスマネージャー起動方法

<環境>
Ubuntu 16.04.2 LTS】
 
Windowsで言う、デバイスマネージャーに相当するツール。
デフォルトのデスクトップ環境(Unity)の使用を前提としています。 

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

sudo apt-get install hardinfo

起動

hardinfo

 
起動画面はこんな感じ。 f:id:kakisoft:20170711134415p:plain  
 
簡易版にsysinfoというツールもありました。

sudo apt install sysinfo
sysinfo

起動画面はこんな感じ。 f:id:kakisoft:20170711142410p:plain

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 (ブログ名)

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


<参考サイト>
Jekyllいつやるの?ジキやルの?今でしょ!

Cent OS:デスクトップ環境

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

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

 yum -y groups install "GNOME Desktop"

切り替え

startx 

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

フィボナッチ工数見積という手法があるらしい。 tango-ruby.hatenablog.com

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

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

  • 作業を細かい単位に切り出してチケット化する
  • 各チケットに、2、3、5、8、13、21のどれかのポイントを付ける。重いタスク程、高ポイント。
    (ポイントに単位は無い。ただの数字)

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

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

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

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

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

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

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

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

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

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

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

https://gitpitch.com/kakisoft/HowToUseGitPitch

f:id:kakisoft:20170706210414p:plain

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