エンジニアのひよこ_level10

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

【shell】エラーをファイルに書き出す【221日目】

日記 シェルスクリプト

こんな時に使う

ターミナルでエラーを吐く時

echp ringo;
#!/bin/bash
cmd = 'echp ringo'
eval $cmd

あ、コマンド間違ってますね。

こうする

echp ringo 2> err.log;
#!/bin/bash
cmd = 'echp ringo 2> err.log'
eval $cmd

何してるの？

2>で、標準エラー出力を出力する

2> err.logで、標準エラー出力を、err.logに書き出してます。

シェルスクリプトでエラーを出力させる時も、eval経由すればいいので簡単に出来ます。

リアルアバター入門 のメモ【220日目】

日記 VR系

この勉強会行ってきました

supporterzcolab.com

Twitterのつぶやきまとめ

Googleフォームで、アンケート結果をスプレッドシートに出力する【219日目】

日記

Googleフォームって？

簡単にアンケートが作れるやつです。

Googleフォームの作成

  1. Googleドライブで右クリック
  2. その他
  3. Googleフォーム

(もしGoogleフォームが見つからない方は、一番下のアプリを追加でGoogleフォームを追加しよう)

結果をスプレッドシートに出力

  1. 作成したGoogleフォームを開く
  2. 中央の上の方に、『質問』『回答』があるので、『回答』を選ぶ
  3. 画面右上に、緑色のスプレッドシートの四角いマークがあるのでクリック
  4. 新しいスプレッドシートを作成するか、既存のスプレッドシートを選ぶ

おしまい。

【html】inputのhidden属性が、毎回同じ値を出す？【218日目】

日記 HTML

こんなコードがあったそうです。

<form>
    <input type="hidden" name="fruits" value="apple">
    <button type="submit" value="送信">

    <input type="hidden" name="fruits" value="orange">
    <button type="submit" value="送信">

    <input type="hidden" name="fruits" value="grape">
    <button type="submit" value="送信">
</form>

これで、どのボタンを押してもfruits=grapeしか帰ってこない！なぜだ！！！

inputのhiddenは必ず送る

今、formタグには、hiddenが3つ、submitが3つあります。

この時、ボタンは押したものだけのデータが送られますが、
hiddenは3つとも送ります。

すると、上から順に

fruits=apple
fruits=orange
fruits=grape

を代入していきます。

すると、最後に入れたfruitsの代入だけが残り、
fruits=grapeのデータだけが送られます。

どうすればいいか

いくつか方法がありますが、今回のようなボタンを選ぶ形式で、かつhiddenを使うのであれば、

<form>
    <input type="hidden" name="fruits" value="apple">
    <button type="submit" value="送信">
</form>
<form>
    <input type="hidden" name="fruits" value="orange">
    <button type="submit" value="送信">
</form>
<form>
    <input type="hidden" name="fruits" value="grape">
    <button type="submit" value="送信">
</form>

これで、押したところのhiddenだけが送れます。

話す側を気持ちよくさせる『聞く力』【217日目】

日記

プレゼンをする側に立ってみましょう

突然ですが、あなたは大きめの部屋で、50人程の方にプレゼンテーションをします！

さて、会場の人のリアクションはまばらです。

そんな時、あなたはどんな人に向かって話をしますか？

そこには、笑顔で首を縦に振る人が！

50人程の中に、2,3人程笑顔で首を縦に振る人がいますね。

なるほどなるほどと、納得をしている様子。

これはしっかり話を聞いていただけてそう！

あ、次のスライドに移動したら、首をかしげている。

言われてみればこれは説明足りていなかったかも。ちょっと補足しよう。

反応があるのは嬉しいですよね。

ということで、こんな経験は過去ありませんでしたか？

50人ではないにしろ、プレゼンをしている時に、
聞いてくれている、理解してくれたというのがわかるのはありがたいものです。

首をひねるだけでも、ちょっと説明しっかりした方がいいのかな？と目安になりますし。

まあ、単純な話、反応があるのは嬉しいことです。
ずーーーっと顔が変わらない人に話してると不安になったこととかないですか？

なんでも反応すれば良いわけではない

ただ、何を言ってもずっと納得いかないと首をかしげられると、それはそれで不安になります。

ずっと納得行かない！という反応しかしてなかったら、話すのやめようかなって思うかもしれません。

ただ、首をかしげている理由を質問して相手が理解してくれた反応もらえたら、
より一層嬉しい気持ちになりますね！

結局、なるほどわかった！という反応嬉しい

結局は、『言ってくれたことわかったよ！』というのが相手に伝わるのが一番です。

ただ、『理解してないけど理解したフリ』は有効な時もありますが、納得いかない人もいるでしょう。

だから、『理解したとき』に、何もリアクションしないのではなく、『リアクションをしましょう』。

たったそれだけでいいです。
それで救われる相手もいるので、明日から納得したと思ったら笑顔になるのを始めてみませんか？

トラブルの対処タイミング。津波が来てからじゃ遅い【216日目】

日記 マネジメント系メモ

リスクマネジメント

海の近くの家に住む。すると、津波に流されるリスクがあります。

このリスクを許容するにしても、
津波に流されたいわけではないです。

つまり、津波が起きそうな時は、避難をしないといけないわけですね。

津波が起こってから避難するのか

では、津波が起こった！

よし、避難だ！

避難が間に合わなかったあああああ

・・・ってなっちゃ意味ないですよね。
間に合わないのは、対処が遅かったからです。

では、いつ避難するのか

地震が起こったら避難する

津波というリスクを回避するためには、 津波が起こってからでは遅い。

津波が起こるのはいつか。 地震が起こった時だ。

つまり、地震が起こってから避難をするべきだ。

というやつですね。

リスク管理は、原因を確認する

津波というリスクに対応するには、そのリスクが起こる原因が何かを確かめる必要があります。 そして、地震という原因を見つけたら、地震が起きた時に対処をしましょう。

問題は早めに対応した方がいいのは間違いないので、 問題発見を早くするためにも、リスクの原因の分析をしていきましょう！

『仕様書に書いてないから』という設計の問題を軽減しよう【215日目】

日記 マネジメント系メモ

『だって仕様書に書いてなかったんで』

プロジェクトにおいて、こんなケースありませんか。

これから作るプログラムの仕様書を渡したら、
部下が動かないプログラムを提出してくる。

『だって仕様書に書いてなかったんで』

仕様書に書いている通りに作っただけでは動かなかった。
だが、どう見てもこのプログラムでは目的のものが作れない・・・

詳細設計に問題があったのか？

一見、詳細設計に不足があったことが問題に見えます。

ですが、詳細設計で『100%完璧な仕様書』が作れるか。

作れるなら、きっとその人が作った方が早いし、きっとロボットに作らせる未来も簡単だと思います。

『100%完璧な仕様書』が作れないなら、どうするべきか。
私達は、『仕様書が正しく書けていない』というリスク管理をするべきなのです。

対策は何か

『仕様書が正しくかけない』というリスクに対して、2パターンのアプローチがあると思います。

『起こる前に対応する』
『起こった後の対処を用意する』

起こる前：『１人で設計しない』

『起こる前に対応する』のは非常に難しいです。
『100%に限りなく近い仕様書』を作る必要があるからです。

これに対する対応の１つが、『１人で設計しない』こと。

  1. 設計をレビューしてもらう
  2. プロジェクトに関わる人に共有して、意見をもらう

見落とし、見逃しを避ける。

設計を分担した際は、お互いの設計をレビューするのもいいです。
分担する以上、お互いに概要を知っているのでレビューもスムーズに行えると思います。

起こった後：『目的』を共有する

『仕様書に書いただけのプログラムでは動かない仕様書』
それでも動くプログラムが出来上がることがあります。

それは、プログラマーが自分で考えて、いい感じに作る時です。

『熟練者じゃないと出来ないだろう』
という一面はあるかもしれませんが、１つ工夫すると、
プログラマーがいい感じに作る可能性が増えます。

それは、『このプログラムは何のために作るか』を知っている時です。

各パーツを何のために作るかを共有する、目的を共有することが大切です。

『ネジを作る』のではなく『ネジのように固定するものを作る』

『ネジ』を作ってみましょう。  
この設計書通りに作ってください。

これでは、設計書通りにしか作ることが出来ません。

この机を作るために、この板を固定するものを作りましょう。
そのために『ネジ』を作ってみましょう。  
この設計書通りに作ってください。

すると、プログラマーが作ってみようとしたら、あれ？これじゃ固定出来なくないか？
と気がつくかもしれません。

じゃあどうすれば固定出来る？と考えて、プログラマーは『いい感じに作る』かもしれません。

私達は『ネジ』を作ることが目的ではなく、
その先の『机』を作ることが目的ではありませんか。

仕様書も『机を作る』ために作るためにあって、『ネジを作る』のはあくまで手段です。

リスク軽減は難しい

今回の主題は、目的を持った仕様書を作ろうというお話でした。

目的書くことも手間かもしれませんが、結果的にかなり詳細に書くよりも、
より部下に伝わって、工数削減に繋がる可能性もあると思うので、
目的を書くことを忘れないようにしたいと思いました。

【HTML】inputタグの丸いボタン、radioボタンの書き方【214日目】

日記 HTML

こんなやつ、見たことないですか？


あ、これ押せるので試してみてください。
 

radioボタンって言います

これはラジオボタンと呼ばれているもので、

『必ず１つだけ選ぶ』選択肢で使います。 

 

 片方を押したら、もう片方が消えるとかですね。

 

どうやって書くの？

<input name="fruits" type="radio" value="apple" />りんご

<input name="fruits" type="radio" value="orange" />みかん

 

こんな感じです。

 

nameの意味

『name』と書かれているのは、それぞれが『セットである』ことを示すものです！

今回だと、りんごとみかんがセットですね。

 

セットだと何がいいか。

ボタンをクリックした時に、セットの中の１つしか選べないというやつです。

 

これは、りんごとみかんがセット、1から4がセットなので、クリックしたときにセットのなかから一個しか選べないやつです。

 

 valueの意味

これは、クリックしたものがなにかを示すものです。

決定ボタンを押した後に、サーバーにどのデータを送るか決めるものです。

 

もしnameがなかったら？

こんなふうに全部押せちゃいます。

 

ということで、適切にnameをセットしましょうね！