エンジニアのひよこ_level10

毎日更新してた人。たまに記事書きます。

抽象メソッドに対するコメントを、具体的にしすぎない【178日目】

抽象メソッドって?

abstract class ClassHuman
{
    abstract protected sayGreeting();
}

この abstract protected sayGreeting();の部分。

これは、実装が描かれていないので、

class ClassJapanese extends ClassHuman
{
    protected sayGreeting()
    {
        echo 'こんにちは!';
    }
}

のように、継承先で実装を行う。

コメントを具体的にしない?

abstract class ClassHuman
{
    // こんにちはと文字を出力する
    abstract protected sayGreeting();
}

これだと困るのがわかると思います。
継承先は、 echo 'こんにちは';とか、DBに'こんにちは'とか、実装がすっごく狭まります。

そもそもsayGreetingは本当に『こんにちは』と言わせたかったの?

挨拶をさせたかったのでは?

させたかったことは『挨拶をさせる』です。

abstract class ClassHuman
{
    // 挨拶を出力させる
    abstract protected sayGreeting();
}
class ClassJapanese extends ClassHuman
{
    protected sayGreeting()
    {
        echo 'こんにちは!';
    }
}
class ClassAmerican extends ClassHuman
{
    protected sayGreeting()
    {
        echo 'Hello!';
    }
}

これなら、違和感ないと思います。

何をさせたいのかを抽象的に考える

『こんにちは』と言わせたい
挨拶をさせたい

それぞれ、意味の範囲も違います。
前者は具体的過ぎますし、このクラスを継承させる時に、全部のクラスに本当に『こんにちは』を言わせたいのかをよく考える必要があります。

必要十分なコメントを書くことが重要であると言われたことがあります。

なかなかその領域になれていませんが、
コメントで詳しく言い過ぎ、定義広げすぎとならないように、
今後も注意してコメントを書きたいです。

じゃないと、上の例みたいに、コメントが関数を十分に表現できず、
コメントによってプログラムが制約されてしまうので、
気をつけていきましょう。

特化型AIじゃシンギュラリティ起こせないとかいう話【177日目】

注意

AIについて全く詳しくない人が、過去に複数の人から聞いた話を継ぎ接ぎにして、まとめてメモしたものです。

 

真に受けすぎないでください(´・ω・`)

 

シンギュラリティ(技術的特異点

人類の進化曲線が、無限大になるポイントを指す言葉。

http://www.nikkeibp.co.jp/atcl/column/16/ai/080300003/?ST=mobile&P=1

 

進化が時間に比例するように段階的に成長するのではなく、

垂直に成長線が伸びる。

 

人間のそのままの成長には限界あるけど、テクノロジーにおいて急激な成長が起こるやつ。

 

人間の脳と同じ仕組みが機械に出来て、機械の相互学習などによって、凄まじい速度で成長するとかいう話。

 

……たまに、人が機械に置き換えられるとかで話題に上がりますね。

 

特化型AIじゃだめな理由

んで、特化型AIじゃシンギュラリティ起こせないよーって話。

 

1.ネジを手作業で作る

2.設計図に応じて、ネジとかタイヤとか様々な作業を指示する

3.何を作るか。どう作るか考える

 

1.2.とかは自動化できたけど、

車作ってー!って言って機械が全部できるかというとそうじゃない……

 

で、3辺りが特化型AIに置き換わろうとしてるけど、それってまだAIを動かすための私達人間の存在が必要だよね。

 

 汎用型AIって。

経験のもと、作業を何も考えず行えるのは小脳とかの話で、そこらへんは特化型AIの領域だけど、

 

汎用型AIは、人間の大脳とか、人間が考える仕組みをそのまま再現していくのを作ろうとしてる。

 

そこで互いに相互学習していくと成長速度が無限大に広がってーってのがシンギュラリティで、

 

まだ特化型だと、学習して自動化した作業をやれ!って命令する必要があるから、今までの機械による自動化とそんな変わらないよねっていう。

 

 企業がAIを使う理由って?

まだ、産業におけるAI利用は結局、自然言語を解釈して、自動的に作業してもらう。

 

ボタンを押して機会を動かすのとそんな変わらない領域なのかな。

 

だから、研究組織と、会社や国とでAI分野への力の入れ方が分かれてないかなー大丈夫かなー?って最近思いましたまる!

『余裕マネジメント』で『始めにくい施策』をやれる環境づくり【176日目】

この記事読んでみました

next.rikunabi.com

『対話をする』ことは『コストに対して成果が見えにくい』

以前の記事で、『納得感』を上げることは難しいと考えました。

それは『対話』をすることは、『コストに対して成果が見えにくい』から実行しにくい。
例えば、

MTGで相手の考えを理解しようとする時間より、施策の話をもっと進めたほうが早く施策に取り掛かれるのでは】

許容する心が必要

ただ『デメリット』『コスト』の部分を洗い出して、この成果が出せそうなら、そのコストを『許容しよう』って考えて踏み出せば、実行できるのかなと。

【10分の認識のすり合わせによって、今後起こるかもしれない手戻りを減らすことが出来るかもしれません。その手戻りも、2時間かかるかもしれません】

ただ、不確定なものをやるのは心理的にも難しいかも知れないです。

常に『余裕』『自由に使える時間』を作ろう

数値化できない成果は存在する。だから比較は単純にできないので、 『まあ、それくらいのコストなら払ってみよう!』って言える資産・環境、『余裕』は常に持つべきなんだなと。

でないと、数値化できない施策はすべて実行できなくなるのかなって思いました。

ブログは『余裕がを作った』からやれた施策

実は、ブログをやる時期には、『必ず21時には家に帰る』ということをしていました。
勉強会や仕事や友人との飲み会でも、必ず21時には家に着くように調整していました。

でも、おかげで毎日21時からご飯を食べる他にもやれる『自由時間』が作れました。

『自由時間』という余裕があったので、そこに『自己投資しよう』。

【アウトプットの習慣をつけるために、毎日10分くらいは投資してもいいや】

と思えたのも、ブログが始められた要因だと思います。

きっちり時間を決めてスケジュールを組むのも大切ですが、
うまく『余裕のマネジメント』も必要なのではないかと思いました。

仕様変更で要らなくなったコードはどうすべき?【175日目】

こんなコード

if ($use < 0) {
    func(pow($use, 2));
} else {
    func($use);
}

$useがマイナスなら、2乗を使うってコード。

仕様変更起こりました。

Aさん『$useが負になることはなくなったよ!』

え、まじか。このコードどうしよう。

残す利点

もし、仕様変更が起こったら、即対応出来る。

残さない利点

コード見やすい
無駄なコード減る

どっちがいい?

まあ、残さない方がいいですよね(´・ω・`)

また仕様変わって再開発することになったら?
git管理してたら、そこから戻すのもあり。
覚えてたらね!!!

あるいは、結構変わる可能性が高そうなら、コメントで残すという選択肢があるのか・・・?

って思ったけど、まあ普通は残さないですよね(´・ω・`)

ってことで、無駄なコードは残さないようにしましょう。
残すべき!って意見がありましたら、是非教えてください!

jQueryで、自分の真上、真下の要素を取得する【174日目】

親、子はわかる

<div class="parent">
    <div class="child"></div>
</div>

これが親子なのはわかる

<div class="a"></div>
<div class="b"></div>

同じ階層の上下にある、これの関係はどうしたら・・・

prev

$('.b').prev(); 

これで $('.a')が取得出来る

ちなみに、自分より上の要素全部を取る場合は

$('.b').prevAll(); 

next

$('.a').next(); 

これでさっきの逆、自分の下の要素を取ることが出来る。

納得感vs生産性vsコストって難しい【173日目】

以前私が悩んだこと

開発をするときにこんな悩みを持ちました

『この開発やる必要ある?』

そう思った時に、まあ仕事に集中出来なかったり、
積極的に仕事に関わろうとする意欲が、いつもより下がったことがあります。

これを読んでる人も同じことを思ったことあるのではないでしょうか。

起案者との会話で解消

そこで私は、起案者と一対一で話す時間をいただいて、
その開発をなぜやるのか、その開発に対する熱量を直接感じて、
これは全力で支えたいと感じました。

その時の開発は、私は多少しんどくても、集中力は下がりにくかったです。
やりきったときは結構感動がありました。

この出来事から考えること

これ、決して私だけが起こるような問題ではないとは思います。

つまり、私が逆に『この開発する必要ある?』と思われる時があると思います。

では、それに対してどれだけ対処する必要があるのか。

解決方法

1.仕事の意図や意義を説いて、納得感をもって開発してもらう
(ただし、コストがかかる。リターンが見づらい)

2.意義を説かないでも、各々で納得感を持つ事ができるメンバーで固める
(調達出来るのか、そもそも実現可能なのか)

3.特になにもしない
(納得感ない人はいるかもしれない、ただしふるいにかけることもできる)

そもそも納得感は必要なのか

こう考えると、納得感を得てもらうには、コストを掛ける必要がある。

ただ、納得感ははたして必要なのか。

納得感によって、開発効率が上がるのであれば、それは必要な投資と考えることが出来る。
最初の話であれば、開発効率が上がっていた『のかもしれない』。

だって、それは数値化出来るか?コストも成果も見にくい投資、私は結構難しいと思う。

だからどうするかと言えば、各々で納得感を得るための手段を手に入れてもらうか、
納得感を各々で得ることが出来るメンバーを固めるのが現実的なのかなと考えてしまった。

つまり、上の2,3が理想になるのかもしれないです。

納得感を持ててない時に、私達はどう生き残ればいいのか

今回、生産性だけを中心に話しましたけど、『納得感』が産む物って他にもあるとは思います。
ただ、それに対して私達が何もせずに投資してもらうって難しいのかもしれないと思いました。

そもそも、助けてやらなければ納得感を得られないような、口を開けて待つしか出来ない人に用はないと考えることが可能かもしれない。

そう考えると、『納得感を得られないなら、納得感を得るために動くこと』ってそれだけでも価値があると思うので、積極的に『納得感』を勝ち取りに行きたいなと思います。

逆に納得感を持ててない人にはどうすればいいか・・・答えは出なかった

ただ、私が他の人に『納得感を持ってもらう』にはどうしたらいいかは、思いつきませんでした。

なにせ、もしかしたら既に納得感を持ってもらうためにいろいろしてもらっていた可能性もあります。
そう考えると、『飲みニケーション』とかって分かりづらいけど凄く素敵な施策なのかもしれない。

もし、『納得感』は必要なものであるとか、こうすれば納得感を持ってもらいやすい等、いい方法があれば、ぜひ教えていただきたいです。

私も与えられるだけの側は終わってしまったので、これからもっと学びたいと思いましたまる。

【LT】新卒エンジニアが150日ブログ書き続けたLTのスライド【172日目】

www.slideshare.net

都内某所でLTしました

willow710kut.hatenablog.com

ということで、以前都内某所でLTした時のスライドです。

情報量少ない

絵が多めなので、情報量少ないです。

以下、スライドで書けなかった内容

勉強の習慣

  1. 毎日学んだことをアウトプットする
  2. 記事にする前に調べる
  3. 勉強の習慣になっている

人に話しかけられる

  1. 『社内の人』にも見られて、頑張ってるな、と声かけてもらえたりする
  2. 『社外の人』にも見られて、ランチ行く?という話になったりする
  3. コミュニケーション苦手でも、話しかけられる側なら楽!

自信がつく

  1. 過去の記事を見たら、自分の成長の跡がある
  2. 継続を数値化することが出来る
  3. 他の人とは違うことが出来ている!これは個性!と考えれて、自信になる

もっと交友関係広げたい!

ということで、積極的にLTしようと考えています!

また、ランチとか、勉強会とか、交流会はぜひぜひ参加したい人なので、
twitterfacebook等、気軽にお声がけください!

https://twitter.com/16210372twitter.com

www.facebook.com

DockerでJavaの環境構築についてメモ【171日目】

前に書いたDockerでJavaの環境構築について。

 

alias用意して、bash起動する方式だったけど、

そもそもコンパイルをbuild時点で終わらせておきたい。

 

Dockerの思想的には、イメージの時点で動くものが用意されているべきなので、

コンパイルを済ませておいた方が良さげ。

 

で、どう実装するか迷い中。

 

コンパイルの手順をDockerfileに用意するのは、プログラムに応じてDockerfile書き換えることになるのでナンセンス。

 

ということで、Makefile

Makefileコンパイル手順を書いて、コピーする。

Dockerfileには、Makefileを動かす記述だけする。

 

これで、Dockerfileはそのままに、Makefileだけユーザーに書かせれば良い。

 

Makefileも生成ファイル名を固定してやれば、ビルド後にランするコマンドも固定出来そう。

 

もう少し環境考えてみよう。

それっぽくなったらgithubにあげよう。