読者です 読者をやめる 読者になる 読者になる

砂日記ばーじょん2.0

IT関連の仕事中に浮かんできたポエムとか読んだ本の感想とか書いていきます。

【デブサミ2017聴講記】【17-E-1】自動化はどこに向かうのか~まだ開発・運用の自動化で消耗しているの?~

デブサミの参加記録(1/8)

公開資料

Togetter

感想

さくらインターネット前佛さんによる自動化の話

サーバやクラウドいったキーワードは全くの専門外ですが、自動化テーマに興味があったのと、
多少タイトルに釣られました。
内容は以下の3つをいろいろな切り口で語ってくださいました。

  • 自動化が目的になると地獄行き
  • 「ツール」は私たちの問題を解決しない
  • 問題解決の道標「必要は発明の母」

つい昨日、現場でSlackを使ってみようということでアカウントをもらい、
「おおー流行りのSlackをついに自分も体験だ~」とか喜んでいたので結構耳が痛い話となりました(笑)

手段の目的化あるある

アジャイル開発やDevOpsの流行が拡大する中で、自動化を推奨する声が増えていますが、
ちょっと待てよという。
そのツールを使うことで課題は解決できるか
組織はみんなハッピーになれるか。
ツールに運用を捻じ曲げられて逆に働きにくくならないか。
ツールを入れるという手段が目的になってしまうのはありがちだよなぁと思いました。

体制や環境で課題はそれぞれ異なる

あるチームで良かったから他のチームでも自動化するのは良いとは限らない。
自動化云々の前にまず課題を洗い出し、解決手段を探ることから始めるのが大事。
そのうえで必要とされるものを入れていくべしというのが非常に納得できる話でした。
また、個人レベルならとりあえず使ってみようは僕はよくやりますが、
そのノリをチームに持ち込むのは危険だなと気付きました。

声の大きな人に屈しないこと

結構組織の声の大きい人(役員とか、技術トップとか)の声に屈しないようにするのが
難しいところだなーとも思ってます。
「いや、それをするとうちのチームのここが回らなくなる待ってほしい」
みたいな話ができるかどうか・・・。
大きな声に流されて不要な仕組みを導入してしまうケースもあるあるですが、
自分の中で効果的な対処法を見つけるのは大変そうです。
偉いひとは、偉いもん(笑)

運用とか、自動化に限った話でない

省力化、時間短縮、人的ミス防止といった観点とか登壇者様の背景から
運用寄りの話をイメージしていましたが、
スライド見返してみるとテーマは運用だけでなく開発にも当てはまるし、
自動化だけでなく組織運営に関わるすべてのツールに当てはまるよなぁということで、
開発エンジニアの自分にとっても非常に役に立つ内容でした。

けものフレンズ駆動開発はじめました

原典(たぶん)

けものフレンズ駆動開発とは

けものフレンズに登場するフレンズたちの精神に則り実現する、楽しく生産性の高い開発のことです。
重要なのはだいたい次のようなことです。

  • 相手を褒める
  • 相手を認める
  • すごいと思った時に「すごーい!」と言う

褒めるという行為は難しい

設計書のウォークスルーやプルリクエストなどを含むコードレビュー作業において、褒めるということができている人はあまりいないと思います。

「設計書の記述が冗長でなく読みやすい」
「変数名がわかりやすい」
「あとでリファクタリングしやすいようにテストコードが書かれている」
などなど

レベルの高いエンジニアほど、当たり前で褒めるほどのことでないことが多く、自然と口から出るのは指摘ばかりになってしまうと思います。

しかし、けものフレンズを視聴したあなたは気付いたはず。

相手を認め、称えることはそんなに難しいことじゃあないと。

「きみは〇〇ができるフレンズなんだね!すごーい!」が使える場所を探す

褒めよう褒めようと、強く意識する必要はありません。
流行り文句を出せそうな場所が無いかなって探します。
そうすると、何気ないちょっとしたところが、
普段当たり前でスルーしていたところが、良いように見えてきます。
そうしたらコメントしてあげるのです。
「きみは読みやすい設計書が書けるフレンズなんだね!すごーい!」
「変数名がわかりやすーい!」
「テストコードがちゃんと書けてるからリファクタリングかんたんだね!わーい!」

そんな軽いノリで話せる空気じゃない、という現場の場合

もちろん相手との関係性とか、立場上、けものフレンズ語録が使えない人も多いと思います。
無理にけものフレンズ語録でコメントする必要はありません。
頭の中だけでつぶやき、実際の言葉は丁寧な感じにすればいいだけです。

(きみは読みやすい設計書が書けるフレンズなんだね!すごーい!)
「読みやすい設計書を作っていただけて助かります」

(変数名がわかりやすーい!)
「変数名から役割のイメージができて良いと思います」

(テストコードがちゃんと書けてるからリファクタリングかんたんだね!わーい!)
「しっかりテストコードを書いていただけたおかげで後でリファクタリングしやすいです」

脳内でならけものになり放題です。どんどんしゃべっていきましょう。

褒めるのが上手になると、指摘の仕方も上手になる

褒め方が分かってくると、冷たくなりがちだった指摘も柔らかり、相手が受け入れやすくなります。 「行数が長いので、本質的でない箇所はプライベート関数に外だししてください」

「行数が長いと感じましたので、本質的でない箇所をプライベート関数に外だししてみるとスッキリすると思います」

「このコードちょっと長いねー!プライベート関数に外だしすると読みやすくなるんじゃないかなー!」
・・・多少例に無理がありますでしょうか。私もまだまだこれからです。

実際にやってみて

まだ始めたばかりですが、相手の良いところも良くないところも以前よりよく見えるようになってきた気がします。 同時に、伝え方により気を遣い、スムーズな意思疎通ができるようにもなってきています。
これから社内で広まっていくといいなと、密かに拡大を目論んでいるところです。

SQLアンチパターン読了 外部キーの取り扱いは難しい

SQLアンチパターンを読んだ

読了後、ビンゴをやった。

ビンゴの結果

f:id:snufkin127:20170127023651p:plain
縦一列に綺麗なビンゴが並びました。

4章キーレスエントリ(外部キー嫌い)について

丸ついたもの全部の体験や感想を話すと長いので、ひとつだけ。

僕はSIer企業に就職し、9年間色んな現場でシステム構築に関わったが、
外部キーをきちんと扱うシステムに出会ったことが一度もない。 どこのシステムでも参照整合性はプログラムで担保していた。

理由は本書にも書かれている通り、

外部キー制約を省略すれば、データベース設計がシンプルになり、
柔軟性が高まり、実行速度が速くなると思っている読者もいるかもしれません。

 

多くの開発者が外部キーを避けるのは、
複数のテーブルの関連し合う列を更新する際に、
外部キー制約が邪魔になると感じるからです。

このあたりに尽きる。
他にも、テスト環境でのプログラムの動作確認時やテストのときに、レコードをちょっと削除したり更新したいなーと思っても、
参照制約で関連しているために、テスト箇所とは直接関係のないテーブルを更新しなければならなかったりするのがしんどかったりする。

外部キーを正しく扱えるプログラマーは残念ながら多くなく、
コードで参照整合性を保証する手段が多く選ばれるのだと思う。

小規模のシステムならいけるかもしれないが、
システム規模が大きくなると複雑度も増大するので、
制約に振り回されず外部キーを使いこなすというのはなかなか難しい。
ずっと課題とは思っているものの、中々解決できないことの一つです。

はてなブログデビューの手始めにMarkdownの練習をする

ご挨拶

この度はてなブログでの執筆をしていくこととなりました。
よろしくお願い致します。

Qiitaと併用していこうと思ってまして、
はてなの方には主にポエムとか雑感を、 Qiitaにはプログラムとか書いていこうと思っています。
ちゃんと続くかわかりませんが、あまり気負わずやっていきたいと思います。

手始めに、最初の投稿がてら、Markdownの練習をしていきたいと思います。 はてなブログでもQiitaでも、さらに職場ではConfluenceや Bitbucketを使っているのですが、
いずれもMarkdown記法で書くことができるようになっています。
それぞれで若干使える文法に差があるものの、
ある程度統一的な文法で書くことができるので、
覚えたいと思ってます。
何番煎じだよって内容ですが、気にしない。
内容の充実度、記事としての読みやすさでは以下の方が参考になると思います。

Markdown記法ではてなブログを書くための手引き - No Hack No Life

参考にさせていただきました

2017/01/26 01:43

そもそもMarkdownとはなんぞや・・・。

Markdown

「書きやすくて読みやすいプレーンテキストとして記述した文書を、妥当なXHTML(もしくはHTML)文書へと変換できるフォーマット」 有名なMarkdown方言としてMarkdown Extra(英語版)[1]やGitHub Flavored Markdown[2]、Marukuなどがある。

だそうです。

Markdownの大元は考案者であるJohn Gruberのサイトにあり、

http://daringfireball.net/projects/markdown/

にてダウンロードできるそうです。

各種サービスが実装しているMarkdownは上記を取捨選択と拡張をしているようです。 こちらをひとつずつはてなブログとQiitaで試していこうと思います。
Qiita版はこちら

見出しを出す

# をつけると見出しになる

見出し1

見出し2

見出し3

見出し4

見出し5
見出し6
# 見出し7(これは出ない。6まで設定可能)

リンクをつける

[表示文字](URL)でリンクになる

Yahoo Japan

段落や改行をつける

Qiitaとは異なる挙動をし、(ちょっと分かりにくい)
単純に 改行しても 半角スペースで区切られ改行にはならない

行末に半角スペースを
ふたつ入れると改行になる (brタグ) (Qiitaはならない)

間に改行を加えると

段落になる(pタグで囲われる)

引用文

> をつけると引用文になる

はてなブログだと
こんな感じ
Qiitaと結構見た目に差がある
個人的にはこっちの方が好き
コードブロックと同じような見た目?

強調

*文字列*もしくは_文字列_
**2段階**
***3段階***
~~打消し線~~

一段階
二段階 ABC123
三段階目は英数字がイタリックになるっぽい。ABC123
若干Qiitaと異なる?(Qiitaは全部イタリックになる)
打消し線

コード挿入

`インラインコード`  
``pre記法``
```コード記法```

インラインコード

<strong>pre記法。タグがそのまま書ける</strong>

public class Test {
    private String message = "初めのバッククォートの後ろにPG言語名を書くと、シンタックスハイライトを入れてくれる";
}

基本はコード記法(バッククォート3つ)で良さげでしょうか

リスト

「*」「+」「-」を使用するとリストになる

  • テスト
    • テスト
      • テスト
        • test

記号の前のスペースの数でインデントできる。Qiitaはスペースでなくタブを使用するため、書き方が少し異なる。

1. 「数字ドット」
    1. を入れると
        1. 数字のリストになる
  1. 「数字ドット」
  2. を入れると
  3. 数字のリストになる
    1. インデントも可能だが、数字でなくなる(Qiitaと異なる)

テーブル記法

| 左寄せ | 右寄せ | 中央寄せ |
|:------|-------:|:-------:|
| 1-1   |     1-2|   1-3   |
| 2-1   |     2-2|   2-3   |
左寄せ 右寄せ 中央寄せ
1-1 1-2 1-3
2-1 2-2 2-3

水平線

---や***で水平線になる


ひとまずまとめ

他にもいろいろあるのですが、
とりあえずよく使いそうなのをピックアップして
試してみました。

はてなブログは改行や段落のつけ方に慣れるのに少し時間がかかりそうです。