エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

熱中症対策まとめ

きっかけ

梅雨明け後、梅雨明け前と同じ感覚で外に出たら、見事に軽度な熱中症になってしまった。。。。
今夏は、梅雨明け前後の差が激しい様子。
自分への戒めの意味を含めて、まとめる。

熱中症とは?

wikipedia抜粋

熱中症(ねっちゅうしょう、hyperthermia、俗に heat stroke, sun stroke ということが多い)とは、暑熱環境下においての身体適応の障害によっておこる状態の総称である。
本質的には、脱水による体温上昇と、体温上昇に伴う臓器血流低下と多臓器不全で[2]、表面的な症状として主なものは、めまい、失神、頭痛、吐き気、強い眠気、気分が悪くなる、体温の異常な上昇、異常な発汗(または汗が出なくなる)などがある。

熱中症 - Wikipedia

熱中症の種類

熱失神

  • 原因
    発汗による脱水と皮膚血管の拡張によって血圧が低下して、脳血流が減少した時に発生する。
  • 症状
    • めまい
    • 一時的な失神
    • 顔面蒼白
  • 対策
    涼しい場所に移動して体温を下げ、水分補給する。

熱けいれん

  • 原因
    大量の汗をかいたのに、水分だけを補給して、塩分やミネラルが不足した場合に発生する。
  • 症状
    • 筋肉痛
    • 手足がつる
    • 筋肉がけいれんする
  • 対策
    塩分補給。
    (黒飴なめなめ♪が永続ループする。。。)
    塩飴が個人的にはオススメ。

熱疲労

  • 原因
    多量の発汗に水分・塩分補給が追いつかず、脱水症状になったときに発生する。
  • 症状

    • 全身倦怠感
    • 悪心・嘔吐
    • 頭痛
    • 集中力や判断力の低下
    • 皮膚は冷たいが、汗をかく
  • 対策
    熱失神と同じく、涼しい場所に移動して体温を下げ、水分補給する。

熱射病

  • 原因
    体温上昇で中枢機能に異常が発生して、体温調節機能が失われることにより生じる。
    かなり危険な状態!
  • 症状
    • 体温が高い
    • 意識障害
    • 呼びかけや刺激への反応がにぶい
    • 言動が不自然
    • ふらつく
    • 汗をかかない
    • 皮膚は乾燥
  • 対策
    集中治療のできる病院へ早く搬送する。
    早く体温を下げて意識を回復させることが重要。

熱中症を引き起こす要因

環境

  • 日差しが強い
  • 気温が高い
  • 湿度が高い
  • 風が弱い
  • 閉めきった室内
  • 前日との気温差

からだ

  • 下痢ぎみ → 脱水しやすい
  • 低栄養状態 → 塩分不足が発生しやすい。野菜をちゃんと食べないとラメなんだからね!
  • 二日酔いや寝不足
  • 高齢者や乳幼児

行動

  • 激しい運動
  • 長時間の屋外作業
  • 水分補給できない環境

予防

  • 涼しい服装
  • 適度な休憩
  • 水分・塩分補給

+αの注意

室内にいる時でも、扇風機を動かすなどして、風の流れを作ること。
水分補給にお茶はやめる。なぜなら、カフェインの利尿作用で、脱水症状になる危険がますから。
水分補給の名目で、コンビニでコーヒー買うのは、間違え。
(もしかすると、コーヒー以外を売りだせば、売れるんじゃねぇ。。?)
(一番簡単なのは、麦茶な気がする)
バランスの取れた栄養補給をする。
好き嫌いすると、熱中症になりやすいので、子どもにはなるべく野菜も食べさせる。

オススメの食

  • 麦茶
  • 夏野菜
  • 梅干し
  • レモン

まとめてみての感想

子どもの野菜嫌いは、熱中症を理由に無理やり直せそうな気がする。
あと、カフェイン系はダメなんだと今更思った。
コンビニで買う場合は、オフィスで飲む場合とかにしたほうが良いかもですね。
夏場の麦茶にお金の臭いがプンプンするのは、気のせいか。

参考サイト

熱中症からカラダを守ろう|大塚製薬

環境省熱中症予防情報サイト 熱中症の予防方法と対処方法

脱水症・熱中症・熱射病を予防するには | カラダの豆事典 | サワイ健康推進課

熱中症を予防する食事のとり方とおいしいレシピ | 熱中症ゼロへ - 日本気象協会推進

ポケモンGoで思うITエンジニアの戯れ言

『Pokémon GO』公式サイト

感じたこと

やったことがないけど、端から見て感じたことを書いていく。
関わってないため、誤解があるかも知れない。
関わってない人の意見として見てもらえればと。

もの凄い話題性

日本でリリースされてから、ニュースにならない日を見ない。
これは、異常だと思う。
常に何かしらの話題があり、それにアクセスする人が多いのだと感じる。

やっている人が多い

電車の中でもやっている人が多い。
満員電車でもやっている人が居て、こっそり画面を覗かせてもらっている。(内緒だぜ!)
画面は、そこまで現実を追求してないと感じる。
結構シンプルな作りだと感じる。

よるのコンビニ

コンビニに行く際に、結構徘徊している人を見る。
ちょっと危険な気がするな。
特に女性と子どもは。

現実世界と電脳世界の超融合

ポケモンGoは、インターネットを現実世界に近づけた成功例として語られそうな気がします。
初代デジモンであったような世界観が実現しようとしていることに歓喜を覚えている。
現実世界とリンクさせることで、達成感が強くなったから、熱中する人が増えたのだと分析。
これは、数年前から言われていたことで、モバイル端末の発展があったからこその当然の結果のように感じる。

そこら辺の予想は、下記の本を読んで理解した。

suzaku-tec.hatenadiary.jp

集客力が凄そう

ポケモンというビッグタイトルが、場所とリンクするようになったので、集客力がもの凄いのではないだろうかと感じる。
なにかのイベント事に関与していたら、集客力が上がりそう。
直近だとコミケだな。
ビッグサイトに、ホウオウ襲来!とかあったら、もの凄い人来そう。

副次産業

外出が増えた事により、いろいろ産業が活発化しそうですね。
特に夏場にリリースしたのがデカイ。
夏場は外にでることが多いので、人気に拍車をかけている気がする。
そして、子どもは夏休みですしね!

バイルバッテリー

どこかのニュースで見たが、ポケモンGoのおかげでモバイルバッテリーが世界的に売れているそうだ。
そりゃ、ずっと持ち歩いているわけにはいかないから、売れますよね。
こういった先読みの力(写輪眼!)が、企業には必要なのかもしれない。
個人的には、太陽光パネル付きで充電できるバッテリーとか欲しいかなと思った。
あと、歩いたときの振動で自家発電するのとか。

もっと色んな所に影響が。。。

スマフォのケースも、ポケモンGoで捕獲しやすいような奴が出ていたりしている。
あと、外出増えるので、帽子や靴なんかは売れそう。
特に帽子は、サトシのキャップを売りだせば、爆発的に売れそう。
もう発売してんのかな?
あとは、自販機においしいみず・サイコソーダ・ミックスオレ売れば売れんじゃね?って勝手に予想。

危険もある

スマホ見ながら歩く人が増えた。
どっちに動くかわからないから、避けて進もうとして肩があたったことが何回かある。
女性ならいいけど、オッサンとぶつかった日には、気分最悪である。
あと、深夜徘徊は、当然危険。
進入禁止系の箇所も危ない。
そこら辺は、注意しないといけない。

ポケモン以外でも可能性が

ポケモンGoが成功を収めたので、真似するところが増えそう。
ドラクエとかデジモン妖怪ウォッチなんかはやれますね。

感想

新たな産業を切り開いたので、もの凄いと思う。
しかも、ポケモン全部出してないので、まだまだ発展途上かと思うと、恐ろしい。。。

IoTが、ゲーム産業に効果的であることが証明できたのではなかろうか?
あと、端末がメーカー固有でないことが、すごくいいと思いました。

アジャイルで思うこと

きっかけ

下記記事を見て、かなり面白かった。
挑発的なタイトルだったが、言っていることは自分が思っていることに近かったので、思ったことと考えを書いて見るに至る。

simplearchitect.hatenablog.com

記事が公開されて書くまでに時間がかかったのは、溜めた情報を処理しきれていなかったから。。。
試行錯誤しているが、情報処理能力を高めるのは、難しい。

私的考え・感想

サム・グッケンハイマーの一言

「ウォータフォールは一切メリットがないので止めておきなさい」

この言葉は、素直に受け入れる言葉だと思う。
日本でプロジェクトに入ると、角が立つから言えないのが大多数を占める気がする。
自分もそうだ。
同じ思いのエンジニアは、結構いるのではないかと、記事を見て思う。

腐った価値観

アジャイルが流行らない要素に、風土が大きく関係している気がする。
空気を読むことに価値観を置いている日本人のせいかも知れない。

学校では、同じ制服を来て、授業でザワついたら『全員が静かになるまで授業しません』という所業が行われるから。
で、それが社会にでると、権力者の言うことは絶対になる。
日本の陰謀論を考えてしまう。
陰謀論好きも日本人の風土ではないかと思ってしまう。

もう何も信じられない!!

ウォーターフォールの弱点

デスマーチの多発

設計という名の机上の空論が進むから、いざ開発になって問題が出てくる。
しかも、デスマーチになっても、権力者に被害がさほどない。
だって、仕事は終わっているんだもの。
何も言えずに作業者は作業するしかない。

問題を指摘しても、議論のすり替えで、いつの間にか説得させられる。
何を言っているか分からねぇと思うが、そういうことが結構ある。
ポルナレフの気分を味わって満足するしかない!
そういう状況に追いやられてしまうのだ。
権力者の方が口が上手いから。
後になって言い返す方法を思いつくのだけれど、すでに時遅しなんだよね。。。

フィードバックがない

設計でいろいろ考えはするけど、実践知を考えないから、開発になって問題になる。
なので、新しいことに手を出せず、有耶無耶で破綻に至る。
※直近で同じことがあったから、余計にそう思う。

机上の空論という考えがあるのにもかかわらず、そういうことをやってしまう。
どこかで進化が止まっているとしか思えない。

しかも、問題を指摘すると感情論になるから、たちが悪い。

どうするか?

で、結局どうするかは、自分で実践していくしかない。
だって、やらせてくれないだもの。
そして、メリット理解してくれないんだもの。
誰かがアジャイルで勝者になるしかない。

自分は私生活に取り入れてやっていくしかないと思っている。
金も企画力もないので、適用シーンを考えて使っていくしかないかなと思っている。
あとは、なるべくアジャイルチックな文化を定着させるために、裏工作をするしかないかなと感じている。

あとは、権力者が泣きついてくるのを待つか。
その際は、小姑並みの精神攻撃を食らわせてやりたい!!!

アジャイルの勝者がでない

日本では無理な気がしなくもない。
もっと別な進化が必要な気がしている。

好き勝手書いたけど、ウォーターフォールから脱却できないのは、そこにメリットあるからだと思う。
たぶん、お金がらみだろうけど。
もっと別なアプローチが必要なのかもしれないと思う今日この頃。

その他参考

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

【書評】リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

きっかけ

そもそも読んだのは、2014年の終わり。
ものすごい売れているので、パラパラめくったら、かなり共感できることが書かれていたので、買った。
すでに買っているのに、読了してないがために2冊買ってしまった思い出の品。
それをきっかけに、クラウドで買った本を管理するようになった。

感想・内容

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

コードの大原則

コードは理解しやすくしなければならない!

なぜなら、読みやすいコードは、他人が最短で理解できるコードの事だから。
他人が理解しやすいようにコーディングすることが、凡人と達人の分かれ目。

コードは短いほうがいいが、他人が理解するまで時間を短くするコードを書くことが優先。
(Javaだと三項演算子がそう。確かに使うとコードが短くなるけど、使い時を間違えると意味が分からなくなる。)

理解しやすい設計が、優れた設計。
(難しいロジックを難しいまま設計するのは、よい設計者とは言えない。)
(エンジニアの腕の見せ所は、分かり難い事をいかに分かりやすく設計するか。その一点に尽きる。)
(難しいものを難しく設計してドヤ顔するのは、恥をしらない愚か者。)

命名

名前に情報を詰め込む

明確な名前を付けることは、多くの情報を詰め込めること。
いい名前は目的や実態を表す。
名前は、短いコメントととらえるべき。

名前の長さ

スコープの範囲で決める。
スコープが狭ければ、処理が見えるため、変数名は短くていい。
(for分のインデックスに "i" を使っていいのは、スコープが狭い時だけって意味だね)

長い名前が問題ではない。意味不明な名前が問題なのだ!
(意味不明な名前とは、ようするにマジックナンバーを使ったりするやつ。)
(日本は、なぜコード値のようなものを命名したがるのだろうか?もの凄く疑問)
(大手SIは、よくすることに思える。)

誤解

誤解されにくい命名を心がける。
命名する際は、誤解を生む要因がないか、積極的に探すクセをつける。
(誤解を生むような命名にするとバグの温床になる。昼ドラで誤解を生むような会話をすると、泥沼に落ちるのと一緒)

コードの美しさ

コードの美しさは、読みやすさ。
シンプルさこそを絶対の基準にする。
美しい = いい設計ではないので、注意。

美しさの原則

  • 統一されたレイアウト
  • 似ているところは似せる
  • 関係するコードをブロック化

コードの段落表記

  • 考えをグループ化できる
  • 他との考えの違いを区別しやすくする
  • 視覚的な踏み石
    (枕詞って言った方が日本人にはしっくりくるかな?)
    (例を出すと、熱湯風呂に入るのをためらっている奴が、「押すなよ」って言ってたら、押してあげることだ)

一貫性あるスタイル > 正しいスタイル
正しさよりも一貫性が重要。
見た目をそろえることが、バグの早期発見につながる。

コメント

コメントすべきこと

書き手の意図を読み手に伝える。
コメントが名前の説明になる場合、それは名前がおかしいので、考え直す。

コメントは、修正を促したり、なぜそうなったのか背景を載せるように心がける。

一般的なコメント例

TODO:あとでやるタスクを書く
FIXME:既知のバグや不具合
HACK:許容しにくい解決策
XXX:危険、問題あり

定数のコメント

なぜその値なのかを考える必要がなくすコメントにする。

コメントを書く基準

読み手が、プロジェクトを熟知していない人と考える。
つまり、コメントに書かなければいけないこととは、質問されそうなことに対する答えだ。

コメントを書く作業フロー

  1. 頭にあるコメントをすべて書き出す
  2. 不要な個所を探す
  3. 改善、添削

コメントすべきではないこと

コードからすぐに抽出できること。
コードを補うコメント→コメントを書くのではなく、コードを修正すべき。

コメントに書くべきこと(推奨すべきこと)

  • なぜこの作りになっているか
  • コードの結果レベル(TODO, FIXMEなど)
  • 定数の背景

読み手が欲しているもの

  • 疑問に思うことを先回りして書いておく
  • ファイル・クラスの全体像
  • 一般的ではない動作

コメントの簡素化

コメント領域は少なくすべき。
多いコメント→それだけコードに問題がある。

歯切れのいい文書、短いけど的確な文章が、読みやすさにつながる。
特に、あいまいな代名詞は除去する。
「それ」「これ」は、読み手が何を指しているのか紐解く必要があり、手間と誤解を招く。
使ってもいいが、何を指しているのか明確にしてあげる。

ロジック

if文

条件は、否定形よりも肯定系を使う。
否定形は、分かり難さにつながる。
条件の優劣も見やすさにつながるので、注意。

三甲演算子

基本的には使うべきではないが、よりコードが簡潔になる場合は使うべき。
(これをどう使うかで、コーディング能力がわかる。)

ネスト

  • 深い=精神的苦痛を当たる
  • 浅い=理解しやすい

ネストを浅くするには、処理を途中で終わらせるようにロジックを組む必要がある。

難しいロジック

最善手ではない可能性が高い。
逆転の発想が必要になる。
巨大で難解なロジックはなるべく分割する。

変数

一度だけ初期化するもの。
変数の変更が多くなるということは、処理を追う必要があり、面倒。

テスト

テストコード

テストコードが読みやすい=テスト以外も読みやすい。

テストコードが読みにくいと起こること

  • 本物のコードの修正を恐れる
  • 新しいコードを書いてもテストケース書かない

テストの原則

大切ではない詳細 → 隠す 大切な詳細 → 目立たせる

(つまり、本質ではないことは、処理を隠蔽してやる必要がある。)

テストデータ

なるべく単純化させる。
複雑なテストデータは、隠すか単純化しないと、テスト恐怖症を引き起こす。

テストやりすぎ問題

90%のテストは楽だが、残りの10%は難しいもの。
実際に100%のカバレッジを達成しても、バグがゼロになることはない。
コストとバグの消化が割りに合わなくなるので、許容店を考える。

最後に

コードの質を高める

簡単なのは、外部の視点を得ること。
外部には、6ヶ月後の自分も含まれる。
(ぼっちにやさしい!)
(自分は、触らなくなって3日立つと忘れるので、うまく利用する)

エンジニアで大切なこと

実践すること

気づく機会は、手を動かしたもののみに与えられる。
気づきがなければ、成長はできない。

他人に頼る

外部の視点は、自分に気づけないことに対する気づきを与えてくれる。
なので、指摘してくれる人は大切にすべき。

(GitHubにコードを晒す連中は、コレが主要な目的だと思う。)

感想

いろいろ考えが変わった一冊。
自分ではなく、読む人にたいしてコーディングするという考えが、一番印象にのこった&ためになった。
意外にも、それが出来てない奴が、日本には多い。
言われたことをそのまま実装するだけでは、ダメだということを痛感できた一冊。
新人教育で読ませるだけでも価値があると思うんだが、ウチの会社は理解せんだろうな。。。

これを読書会を社内で開くことを検討中。
やって結果が出たら、ブログに書きたい。

2016年上半期で気に入った文房具

文房具は勉強に重要

2016年に入って、いろいろ試しにノート買ったり、文房具を買うことが多かった気がする。
そのなかで気に入ったものとその理由を書いて、今後に生かす。
※発売自体は結構前のもある。

マツコの知らない世界」に出ていた文房具の人にちょっと触発された。

気に入ったもの

コクヨノートキャンパス ドット入り罫線

コクヨ キャンパスノート ドット入り罫線 5冊パック B5 B罫 30枚 ノ-3CBTX5

コクヨ キャンパスノート ドット入り罫線 5冊パック B5 B罫 30枚 ノ-3CBTX5

思ったこと

ただ、ドットが入っただけなんだけど、あるとないとでは、雲梯の差が出る。
ちょっと前までは、ドットがないノートを使っていたけど、これを使うようになってノートが凄くきれいになった。
文頭がそろえやすいのが、非常にいい。
単純なことだが、パッと見でわかりやすくて見やすくなる。
自分は、本を読んで得た知識をノートに書くようにしている。
その作業をした際に、後で見やすいのは、とても助かる。

ただでさえ字が汚いので、配置を意識せずにそろえることができるのが、ものすごい楽だった。
方眼ノートでいいのでは?と思ったけど、方眼ノートだと、お絵かき主体になるのよね。。。
方眼ノートは方眼ノートで、別利用シーンがあるので、別に使っている。
それは、後続で紹介。

なにか文章をまとめたいときや、見返すことが前提の場合は、使ってみるといいかもしれない。
自分は結構しっくり来た。

パイロット フリクションボールノック0.5mm

思ったこと

自分は、青が好きなので、青をよく使う。
だって、黒だと味気ないし、赤だと目が痛い。
ノートをとることにも楽しみを見出したいので、青を使う。

3色にしないのは、ペンの色を変えるのが面倒なのと、どうしても太くなるので、手が痛くなるから。
筆圧が結構強い&力強く握るほうなので、太いと結構力を入れてしまう。
かといって細すぎると持ちにくいので、0.5mmが自分には一番合っていた。

また、芯の詰め替えも簡単にできるので、非常に使い勝手が良かった。
ただし、詰め替えで置いてあるのは黒が多い。
同士が少なくて残念だわ。。。

ロジカル・シンクノート

思ったこと

これの用途は、アイディアの書き留め&説明
図を主体に書くことが多いシーンで使う。
文字が多い場合でも、補足線で矢印入れることが多い場合に使うことが多いかな?
よく使うのが、なにかの勉強会に行ったときに、図と文字、補助線使って考えをメモするときに使う。

最後に

文房具は、学習と因果関係が思ったより強いと感じるようになった。
ケチらずにいろいろ試していきたい。

文具ソムリエール「菅 未里」って人が可愛らしいと思って見ていた。
既婚者だと知ったときは、衝撃が大きかった。
それでも応援したい人ではある。
心の闇とか、興味を引くワードを持っている。遊戯王好きにはたまらないね!

調べたら、ブログ書いているのだな。
これからは、要チェックしておこう。

STATIONERY RESTAURANT | 毎日が楽しくなる文房具いかがですか?

【書評】アジャイル開発とスクラム

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

きっかけ

アジャイルサムライを呼んだが、後続の本で知識を深めたいと思っていたので、読了。
本当は、実際にやってみてフィードバックを得ながら開発するのがいいのだろうけど、プロジェクトの主流はウォーターフォールが一般的で難しい。
あと、私生活に適用しようと思っても、いきなり適用が難しいのがある。
本質をより良く理解したかった。

近くに、メンターになれる人がいれば良かったけど、内向的性格が災いして、なかなかできない。
なんか、アジャイルをテーマにしたカンファレンスがあれば、行きたいと思う。

内容・感想

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

アジャイル開発とは何か、スクラムとは何か

ウォーターフォール

開発工程に従って順次開発する方式。
工程間をドキュメント使って意思疎通する。
下記問題点がある。

  • 動くものが最後まで見えない
  • 文章での意思疎通による誤解発生のしやすさ
  • 完成時に古くなる可能性

アジャイル

開発工程を短い期間で繰り返す。
ユーザの意見を取り入れて開発を行う。

アジャイル開発

手順・プロセスによる開発ではない。
価値観や考え方を元にした開発。
そのため、やり方には複数ある。
決まったやり方を指すのではなく、考え方を指す。

(おそらく多くの人は、決まったやり方を求めている気がする。)
(そのために、誤解が生まれている気がしてならない。)

なぜ、アジャイル開発なのか

従来のシステム開発

  1. 市場調査
  2. ビジネスモデル確立
  3. システム発注
  4. ソフトウェア開発
  5. 納品
  6. リリース

ビジネスのゴールと、ソフトウェア開発のゴールが分断されている。
ビジネスのゴール:システムで利益を得る(リリース以降)
ソフトウェアのゴール:仕様通りに作る(納品まで。リリースも含む場合がある。)

ゴールが違うから別々の利益を求める。

最初の内に多くの機能を求める。

リリースする頃には、いらない機能になってお金がかさむ。

章まとめ

アジャイルが出現した背景
ビジネス変化の高速化

アジャイルの目的
ゴールを共有して、無駄を省く事。
柔軟な対応と費用対効果の向上に主眼を置く。

スクラムとは何か

アジャイルの一種。
経験を元にしたスプリント*1を実行する。
スプリントで得た経験を、次のスプリントに活かす。

スクラムの3つの役割

  • プロダクトオーナー
    何を作るか決める人
  • 開発チーム
    開発する人々
  • スクラムマスター
    マネジメントする人。働きやすい環境構築を行う人。

スクラムの成果物

  • インクリメント
    スプリントの成果物。リリースする媒体。
  • プロダクトバックログ
    機能リスト
  • スプリントバックログ
    今回のスプリントで実装する機能リスト

スクラム5つのイベント

  • スプリント
  • スプリント計画
  • デイリースクラム
  • スプリントレビュー
  • レトロスペクティブ

スプリント

繰り返す反復の作業。

スプリント計画

スプリント開始時のミーティング(キックオフ)
プロダクトバックログからスプリントバックログを抜き出す。
対応内容を決めて、タスクに落としこむ。

(アジャイルは計画が内容に思われがちだが、実際は、やることを決めて計画は立てる。
アジャイルサムライでも知っていたので、それほど驚きはしないが、知らない人は驚愕するらしい。
※個人の推測

ここでWBSに落とすのだろうか?)

デイリースクラム

朝会・夕会の実施。
活動状況を共有する。
開発チームで対応できないこと→スクラムマスターに依頼する。
共有して見えた状況→プロダクトオーナーに報告

(ウォーターフォールでもやると思う。
ただ、役割を決めてないと宙ぶらりんになるが。
やることは、スクラムの肝な気がする)

スプリントレビュー

スプリントが終わった後のデモ

レトロスペクティブ

スプリントレビューでの振り返り

アジャイル開発の活動

アジャイルの実践には、プラクティスと呼ばれるいくつかの活動が必要になる。

ユーザストーリー

ユーザの言葉で書かれた機能説明 → これが要求仕様書になる。
アナログ重視して、カードに書かれたことをきっかけとして話す。
会話ベース。
仕様書に落としこむと、ドキュメント肥大化と分析麻痺が起こるから。

(方式が異様に多いのは、何度か経験がある。
ドキュメントが多いと圧倒されるし、仕事をした気になるから注意が必要だと思う。
ドキュメントが多い=優れたシステムではないハズ!)

プランニング・ポーカー

チーム全体で開発規模を見積もる。
各々の見積もりを比較して決める。
※人は、見積もるより比較が楽なため。

ポーカーのように日数合わせをして進めるので、この名称だと思われる。

朝会(デイリースクラム

やることを見える化して、チームで共有する。
長くなる議論は、一旦区切る必要がある。

振り返り

チーム活動を通して、今後の改善を話し合う。
PDCAのCAに相当。
気づきを共有して次に活かすのが目的。

(よく考えるとPDCAのCAって、一緒にやることが多い気がする。)

タスクかんばん

現在していることを全てカード化して可視化する。
誰でも見ればプロジェクト状況が分かるようになる。
そうすることでボトルネックを見つけやすくして、スループットをあげる手法。
あと、分散開発がしやすくなる。

(たぶん、これはトヨタの流れだよね。。。)

バーンダウンチャート

スプリントの残作業を認識して、現在の進捗を知るのが目的。
進捗に対してどのような行動をとる/取らせるかが重要。
一番の目的は、行動喚起すること。

ペアプログラミング

ペアでプログラミングさせる。
そうすることで、リアルタイムレビューと知識の共有が行われる。
会話しながら開発するので、集中力が必要になる。

テスト駆動開発

テストの定義→失敗→再設計を繰り返して設計を成長させる。

リファクタリング

外部からのうときを変えずに、内部構造を変える再設計活動。

継続的インテグレーション

動くソフトウェアを常時展開させる

アジャイルを支えるもの

アナログと会話

動くものによって品質を作って密度の濃い場を作る。
開発速度と効率が上がる。

(今までは品質を高めながら作るのが主流だったけど、これからは作りながら品質を高めていくことが主流になる。
そうしないと、速度でないことは、明白なハズ!)

オブジェクト指向

変更・テストの容易性をあげる技術として必須。

(今は、関数型が目立つが、オブジェクト指向と反目はしないと思っている。適用する場所が違うだけ。
アジャイルを突き詰めていくと、マイクロサービスになる気がする。)

スピード時代に独自のアジャイル手法。ワンチームマインドで挑むリクルート

新しい開発標準「SWAT」

メディアの変化

紙 → Web
旧来の勝ちパターンが遅すぎる。
やってみないとわからないが多数を占めるので、実際にやってみることを優先しなければいけない。
競合他社がいるなかで遅いことは、負けに繋がる。
(ブルーオーシャン戦略の基本ですな)

SWAT

Speedy Willing Alliance Teamの略。
一致団結して、意志をもって開発スピードを追求する。
(言われたことを早くやるではないのが、ポイント)

スクラムと実践知リーダー

スクラムオーナーとプロダクトオーナーに求められるものは、実践知のリーダーシップ。

アリストテレスのフロネシスと実践知

知 → 3つの形態がある。(ドラゴンボールのセルかな??)

  • エピスメーテー
    科学・哲学が該当。
    普遍的で、文脈に依存せず、再現可能で言語表現できるもの
  • テクネー
    技術・スキル。文脈依存で実践のノウハウ
  • フロネシス
    実践からの知恵。目に見える事象と背後にある関係から適切な判断をして実行する。

(フロネシスを理解してない奴が多いこと。
だから、「Why ~」って言うのに騙される。
やり方を学んでも、それができる場面と背景を理解してないとダメってことだな。
魚の目利きのやり方を覚えても、いい魚が絶対手に入るわけではない。
売っている人との利害関係や関係の構築を考えることも必要なのだ。
それを体系的に伝えることが困難なので、修行という考え方があるのだと、儂は思う。)

実践知に必要なリーダーシップ

  • 良い目的を作る → 良い判断のため
  • 場をタイムリーにする → 知の流通を良くする
  • 現実の直視 → 現実を見て、本質を見抜く
  • 直感の本質を概念化 → 本質を見つけたら、それを伝える能力
  • 概念の実行 → 見つけた法則を実行に移す行動力。政治力も伴う。
  • 知の組織化 → 知の伝授・継承・分散

(リーダーシップを発揮するとは、未知の事象を解析して分析、実践して検証を含めること?
何もしない奴は、確かにリーダーシップがあるとは言えんな。
あと、考えを持たない奴も、リーダーとしてどうだろうかと思う。)

感想

アジャイルサムライを読んでいたからか、違和感なく読めた。
リーダーシップの考え方は、概ね同意。
行動を起こして、率先するのがリーダーシップだと思うね。

やっぱり一番難しいのが、問題の共有と解決だろうか。
人の考えは、統一することができないから、アジャイルが失敗しやすい由縁だと感じる。
それをどうやって解消するかが、アジャイル開発の課題な気がする。

アジャイルの基礎はアジャイルサムライで固められた。
汎用概念や、他の取り組み方、実践方法について迷ったら、読むといいかもしれない。
たぶん、アジャイルサムライを読み直すと、見えなかった本質の説明が分かりそうな気がする。
多読がいいとされるのは、理解のきっかけが、いろんなところにあるからかもしれないと思いました(小並感)

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

*1:反復プロセス

eclipse4.6 新機能まとめ

Eclipse 4.6

f:id:suzaku0914:20160717043831j:plain

IDEのトレンドを知っているのは、開発者として当然だと思い調査。

ネーミング

いつもなら、天体系の名前のはずだが、今回は、元素名。
なんでだろー(テツトモ風)

マジで気になる。
eclipseって名前自体も天体系の用語だと思うのに。
ネタ切れかな?
テラナイトでも天体の名前が使われているから、個人的には結構覚えやすかったのに。。。

天体の名前は、中二病全開だからだろうか?
プロダクトにおいて、イメージは大切だからな。

そして、スプラッシュ画面の画像は、いつもながらカッコいい。。。

変更内容

バグフィックスは除く。
結構いっぱいある。

  • JavaScript ES6 対応他
  • メモリ消費量の低減
  • Git ステージング・ビュー
  • 部分一致でのコンテンツ・アシスト
  • エディターで行折り返し
  • 最大化などの操作性向上
  • JSON エディター
  • 起動高速化、UI 性能改善、アップデート高速化
  • Eclipse 実行環境は Java 8 が必須に
  • WTPTomcat 9 対応
  • Java 保管アクションにダイヤモンド演算子への変換追加
  • "if" のコンテンツ・アシストで == null と != null 候補を表示
  • Ctrl+、Ctrl- でエディターのフォント拡大縮小
  • ワークスペース選択ダイアログに最近使ったワークスペースの一覧を表示して選択・削除
  • ファイルの関連付け設定で「関連付けられていないファイルのオープン」の挙動を設定
  • null アノテーションの型を複数指定可能
  • ダイアログのダークテーマ対応
  • 名前変更ポップアップにオプションを開くためのリンクを表示
  • ファイル検索でバイナリーファイルを対象にするオプションを追加
  • クイック・アクセスで Ctrl+3 で表示切り替え
  • アノテーション新規作成時に Target アノテーションなどのメタアノテーションの追加オプション追加
  • リファクタリング:パラメータを新規フィールドに割り当て
  • Java > コード・スタイル > フォーマッター > 編集 > 小括弧 に関する設定追加
  • 履歴からのアプリケーション終了→再起動
  • 編集中エディタの自動セーブ
  • 最近使ったワークスーペースを直接選んで起動

...etc

気になった機能と確認結果

eclipse.iniの変更

使用するGCの設定が、G1GCになっている。
G1GCは、以前記事に取り上げたことがあるので、そちらを参照してもらえればと。

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

簡単に言うと、大きなメモリを効率よく管理するためのGC
あまり大きなメモリを使ってないなら、設定を変えてみるといいかも。
Java9からは、デフォルトになるため、そこらへんは意識しておきたい。

仕組みは、以下の記事がわかりやすかった。

3.1.4 G1GCのメモリー構造とGCの流れについて

JSON エディター

地味にアウトラインが便利。
たまに、設定ファイルとしてJSON使ったりすることがあるので、アウトラインで構造が見やすくなった。

エディターで行折り返し

自分は、常に行折り返しさせないのが使いやすいが、そっちが使いにくい人もいるのだな。
ハード的な要因だろうか?
行折り返しが必要なほど、横いっぱいになるようなコーディングはしないように心がけているので、あまり気にしたことがなかった。

Alt + Shift + Y で切り替える。(デフォルト設定では)

ダークテーマ

闇ですね。
正しき闇の力を使えてこそeclipseって、勝手に思っている。

残念なことに、一部スクロールバーがダークテーマにならない問題が残っている模様。。。
次期バージョンで解決するようです。

この部分は、InteliJ IDEAが一番しっくりくるな。

Ctrl+、Ctrl- でエディターのフォント拡大縮小

これは、ライブコーディングする人にとっては便利ですね。
毎回フォント設定変えるのは、時間かかるうえに、なんか慌てちゃってパニくるときがある。(精神が弱い俺固有の問題かもしれんが。。。)

編集中エディタの自動セーブ

必要なのだろうか?って思ってしまった。
癖でCtrl+Sで勝手に保存してしまうので、個人的にはいらない。
たまにExcelを保存し忘れてクラッシュしてなくなりましたって人を見るけど、「それはリスク背負って作業した結果でしょ?」って思う僕は、傲慢すぎるのだろうか?
デフォルトでは、当然のように無効化されているので、保存癖をつけるのが普通だと思う。

履歴からのアプリケーション終了→再起動

これは、嬉しい。
たまにeclipseがクラッシュして、強制終了することがある。
その際に、Tomcat起動したまんまとかいうと、厄介なことになる。
過去記事にも書いたが、それが結構あって、対処方法を調べて残したほどだ。

suzaku-tec.hatenadiary.jp

多分、ハードが貧弱なせいでしょうね。。。。

最近使ったワークスーペースを直接選んで起動

あんまり起動時にワークスペース選ぶことがないので、実感はわかないのが正直なところ。

クイック・アクセス

なるべくショートカットを使うようになってから使うようになった。
フィルタリング機能が提供された。
これによって、大きな分類を覚えておけば、ある程度アクセスしやすくなる。
覚えてないときとかは、大分類で探すことができるようになるわけですな。

リンク

参考にした記事

Eclipse 4.6 Neon 新機能 TOP10!と Spring Boot STS - Qiita

Eclipse4.6 "Neon"の新機能一覧 - R42日記

感想

takahashikzn さんのブログがすごく詳しかった。
これくらいのことができるエンジニアになりたいものだと思いました。

全体的に、コーディング補助の能力が向上した印象を受ける。
コードの解析技術がもっと進んでくれればいいなと思う。
特にNull解析は!

遊び心ある機能があると面白いかもな~と心の中で思う。