早くなんとかしないと…

社会人としてもシステムエンジニアとしても駄目になってしまう…

javaで正規表現

とあるコードが数字→英数字になる仕様変更に取り組んだときの、気づきと備忘録、その1。


チェック処理で正規表現を用いることになった。
java正規表現

SBクリエイティブ:体系的に学ぶ 安全なWebアプリケーションの作り方』を確認したところ、javaならmatchesメソッドが使える、とのこと。

matchesメソッド https://docs.oracle.com/javase/jp/6/api/java/lang/String.html#matches(java.lang.String)


"java 文字列 正規表現 チェック"でググって見つけた、以下の記事を参考にしながら、実装。
正規表現を使う - Javaちょこっとリファレンス
Javaで入力チェックを正規表現で行う - dirablueの日記
Javaで正規表現によるチェックについて - Java~PG CENTER(プログラムセンター)~


実装したものの、諸々の都合で、私はレビューにまわることに。
…で、上がってきた実装。

if(targetCode.matches("^[0-9a-zA-Z]{3}+$"))
{
	// 正規表現を満たしている場合の処理
} else {
	// 正規表現を満たしていない場合の処理
}

"+"なくてもいいのでは?と指摘したものの、修正されず。
のちの試験で問題も出てないので、まあいいか、と流す。

Eclipseのブレークポイントに条件を追加する

Eclipseデバッグを利用して、想定通りの判定処理になっているかどうか試験をしていた時のことです。
繰り返し処理中に何回も同じ値が出てくるため、次の該当値が出てくるまで何回もF8を押すのがダルくて、ラクできる方法を探そうと思い立ちました。
たまたま右クリックした時に出てきていた単語を絡めて、「Eclipse インスペクション」で検索したところ、下記のスライドを見つけました。

Eclipseデバッガを活用するための31のtips

P.69の「Q22.ある条件を満たす時、初めて止まるようにブレークポイントを貼るにはどうすればよいですか?」がまさに自分のやりたいことでした。

Eclipseを日本語化している場合は、下記の操作になります。

1. ブレークポイントを右クリック
2. 「ブレークポイント・プロパティー」を選択
3. 「条件付き」チェックボックスを選択
※「'true'の時に中断」ラジオボタンが選択されていることを確認
4. テキストエリアに条件を入力

targetStr.equals("ヒット")

5. 「OK」を選択

この例だと、targetStrが"ヒット"の場合だけ、ブレークポイントで処理が止まるようになります。

目視確認はザルになりがちだし、ミスってまた最初からも嫌だし…この設定のおかげで、試験の時短になりました。

フィンランドの国語教育すごいなあ

bookmeter.com

■なぜ読んだのか

新人SE向けの記事を読み漁っている中で、たどり着いた記事で紹介されていた、フィンランドの議論のルールに興味を持ったから。

 

たどり着いた記事

Adways Engineers' Blog : 新人後輩SEに業務に入る前に読んで欲しい記事 15選

 

紹介されていた記事

d.hatena.ne.jp

また、上下関係で下である自分の意見に聞く耳を持ってもらえず、ストレスともどかしさを感じており、なにか解決の糸口が掴めるのでは?と思ったから。

f:id:PET_HAL:20170610141147j:plain

▲自身のノートにはこのような嘆きが最近増えている

 

■読了にかかった期間・時間

1時間。届いた日に読了。

 

■備忘録

読了後、読んでよかったと思った。

練習してできるようになりたいことが、たくさん書かれていた。

実践してみたいことを書き出しておく。

 

□発想力のカルタ

それは何?

それで何をするの?

それはどんなもの?

中央のテーマは単語が実践しやすそう。

 

□表現力のカルタ

いつ?

どこで?

だれが?

何を?

なぜ?

どうやって?

それからどうなった?

こちらは中央は短文。創作などで使えそう。

 

□論理力

どうして?攻撃

池上彰氏の『伝える力』を思い出しました。日本銀行を社会の教科書を引用して説明すると、小さい子どもには伝わらず、素朴な疑問をぶつけられる、というお話。ここで「そういうものなんだよ」と言っちゃあ、おしまいだ…。

自分が疑問を持つことも大事だし、どうして?攻撃に筋の通った、納得のできる答えを返せるようになることも大事。

# 猫が好きなのはかわいいから→犬だってかわいいのにどうして猫?

 

意見+理由

意見

なぜなら(理由1)

それに(理由2)

また(理由3)

3つの理由がただの言い換えにならないように気をつけること。

理由を3つ述べて意見で殴れ。

 

□批判的思考力

いいところと悪いところを10個ずつ挙げる

悪いところだけを挙げるメソッドだったが、生徒が悪いところだけを挙げるのはいやだと言うのでいいところも挙げるようになったそうだ。見習いたい。

 

□コミュニケーション力

議論のルール。…は、すでにまとめてある記事も紹介したので、私が気になった点のみ、備忘録を残しておく。

 

1. 他人の発言をさえぎらない。

他人の発言中に勝手にしゃべりださない。例え発言中の人の意見がふざけていようが、途中でしゃべりだした人がルール違反。自分の発言の価値(と表現して伝わるのだろうか)を下げないためにも、大事なことかも。

 

6. 話を聞くときはほかのことをしない。

P.69のイラストでいうと、寝ている生徒がこのルールを違反しているということだろう。

 

8. 議論が台無しになるようなことを言わない。

【本書より引用】(前提に立ち返ると、他の人の気づかなかった論点を示したように見えるので、優越感に浸れるのです。)

突き刺さる一文。「そもそも」を禁止しようと思った。

 

10. 議論が終わったら、議論の内容の話はしない。

蒸し返して喧嘩になることがあり、ルール化されたそうだ。


本書を読んでいると、先生が生徒の提案でルールを改良しているようで、そういう受容性のある雰囲気も素晴らしいなあと思った。

『リーダブルコード』を読んで、備忘録

www.oreilly.co.jp

■なぜ読んだのか

試験要員化していた私に、コーディングの機会が巡ってくることになったから。

# 読みかけの本に飽きてきたから、という理由もある

 

■読了にかかった期間・時間

累計3時間くらい。

5/23-6/4の13日間のうち、7日着手。

 

■備忘録

本書における「リーダブルコード」「より良いコード」の定義は、「第三者が理解するまでにかかる時間が短いコード」であることを、まずはおさえておきたい。
そして、「第三者」には、未来の自分も含まれている。

 

とりあえず、これなら今の自分でも心がけ次第でできそうだと思ったことを抜き出しておく。

・【P.14】ループで使う変数に説明的な名前をつける
  (例:i,j,k→ci,mi,ui)

・【P.20】変数に単位を含める
  (例:start→start_ms)

・【P.21】変数に属性を含める
  (例:html→html_utf8)

・【P.31】限界値の変数の接頭にmin_,max_をつける

・【P.32】以上以下の範囲を表す変数の接頭にfirst_,last_をつける

・【P.33】以上未満の範囲を表す変数の接頭にbegin_,end_をつける

・【P.77】名前付き引数っぽいコメントをつける
  (例:checkRange(/* first_index = */ 1, /* last_index = */ 10))

・【P.84】条件式の左側には調査対象、右側には比較対象
  (例:if(first_index >= 1))

・【P.91】関数から早く返す
# 関数の複数returnを許容しないのはアホくさいらしい。
# …が、ここは賛否が分かれそうな気がした

・【P.124】変数の変更箇所を少なくする
  (現在値の判断が難しくなるのを避けるため)

・【P.127】標準のライブラリを利用する
  (時間の節約になり、書くコードも少なくなる)
# 確かにこれは忘れがちだなと思った

・【P.229】1回のコミットにつき変更内容はひとつ
  (例:1回目のコミット→コメント整形、2回目のコミット→今回の改修)
# コメント整形と今回の改修両方ぶち込んだらdiffとりにくいよな~と思って
# コメント整形しなかったことがあったんだけど
# こうすれば良かったんだ!と気づかせてもらった

 

過去のコメントがコードをただ日本語化しただけになってて、本書で書かれていた意味のないコメントだなって凹んだけど、これから気をつけたらいいよね!

なんちゃらMap

なんちゃらMap系のコードをいじるのでメモ。

 

■追加する場合

HashMap:バラバラ

TreeMap:キーでソート

LinkedHashMap:追加された順

HashMap、TreeMap、LinkedHashMapの違いとLRU | infoScoop開発者ブログより

(ググったワード:"treemap linkedhashmap")

 

■ループ

LinkedHashMap<String, String> map = new LinkedHashMap<String, String>();

for(Map.Entry<String,String> entry : map.entrySet()){
          // entry.getKey()
          // entry.getValue()
}

[java][基本] HashMap、HashSet、ArrayListのループ処理サンプル | keiのTECブログより

(ググったワード:"linkedhashmap ループ")

 

以下、6/27追記。

keyをIntegerからStringに変更したら、今までparseIntで同じkey扱いだった"01"と"1"が別keyとなっていた。

なんでかな…と調べたところ、重複したkeyで新たにputすると、valueは新しいものに置換される、とのこと。

Mapに重複したキー値を追加した場合 - 裏ブログより

(ググったワード:"treemap キー 重複")

APIの仕様にも書いてありました。

Map (Java Platform SE 6)

つまり、今までは新しいvalueで置換していたということか。
従来の処理と異なるので、確認事案でした。

エンジニア・プログラマーの指導教育に関する私の過去話

日課となりつつあるはてなブックマーク - 人気エントリー - テクノロジーのチェックで、今週はエンジニア・プログラマーの指導教育に関する記事が目に留まりました。

エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた5つのこと - Qiita

小学生の時からプログラムを組んでいた人が大学から優秀な教員の元で始めた人に抜かれたという話 原因はどこにあるのか - Togetterまとめ

 

自身の過去話を書いておこうと思います。

 

 

■指導される側として

いちばん傷ついたのは私が給料泥棒だというニュアンスの発言をされたことでした。

私の所属には、専門学校卒で昇級し、大卒の私と同等級の先輩社員がいました。

その先輩社員と比べられ、給料泥棒と言われたのです。

この発言に私は何も言い返せませんでした。事実には変わりないので。

他にもいろいろと厳しいことを上司に言われ続けてきましたが、私はその悔しさがバネになったところも大きかったのだと思います。

ただ反対に、その生意気さで涙を流したことがありました。

客先派遣となった私は、同じように派遣の年上社員と共に仕事をすることになりました。

# 派遣先A社、年上派遣社員はB社所属、私はC社所属。

年下の私はたびたび相談していたのですが、「ここは既存の機能を使って実現したい」「いや、ここはそうじゃなくてこういうロジックにするべき」とお互いが折れない事態になり、「教え甲斐がない」「好きにしろ」と吐き捨てられました。フロアの社員全員に聞こえるような大きな声で。

年齢差があるとはいえ、派遣社員という同じ立場である以上、私がこの社員に、しかもフロアの社員全員に聞こえるように怒られるのはおかしい。

その日は言われた内容になのか悔しさなのかショックなのかよく分からないものの、何度も涙がこみ上げてきて、頻繁にトイレに行っては泣いていました。

そんな時、上司から別件で電話があり、その際、この出来事を伝えました。

# その後、年上派遣社員と共に仕事をすることはありませんでした。

 

指導される側は、

・指導に対して感謝の言葉を述べる

・素直に受け入れる

ことが大事かなあと。

私の後者の例で上司部下の関係の場合、今後指導を受けられない可能性も出てきます。

3月末に公開した社会人最初の3年がもうすぐ終わるので振り返ってみるでも書いたのですが、嫌われるよりも好かれておいた方が、教えていただく機会に恵まれるはず。

 

 

■指導する側として

上記での上司からの電話は、後輩社員が退職するという連絡でした。

この後輩社員を含め、過去に2人指導を任されたのですが、結論から言うと上手く指導できませんでした。厳しすぎると言われました。

指導する側になると、質問される度に自分の仕事の手を止めないといけなくなります。そして質問に答えるために自分の時間を削る。

説明する時も内容の取捨選択が難しい。余計なことまで話すとキャパオーバーしちゃうだろうし、メモも追いつかないだろうし。スマートに説明できるだろうか…「わかった?」「…わかりました」(ああわかってないな…)

指示を出すのもそう。1から10まで出しちゃうと自分で考えなくなっちゃう可能性がある。でも、ある程度出しておかないとこちらの想定通りにしてくれない…どうすれば…

えっこれ前も同じミスしてたよね?なんで同じミスするの?ああ言ってしまった。典型的ダメな例として挙げられていることだって知っているのに、本当に言ってしまった。だから「今度は大丈夫だよね?」って聞いちゃう。「はい!」ああまた同じミス…

 

指導する側は経験不足なので、今後また指導する立場になることがあれば、悩んでいた頃に買った本を一気に読んで、改めてブログ記事にまとめたいと思っています。

ただ経験してこうすべきだったかなと思ったのは、

・自分の基準ではなく、相手の基準で考えること

・結果に問題がなければ、方法や過程、細かい部分には口を出さないこと

・事実であっても、相手のやる気を削ぐようなことは言わないこと

でしょうか…

 

 

あと、指導される側も指導する側もどちらも、

・相手のことを理解しようと努めること(7つの習慣のひとつ「まず理解に徹し、そして理解される」)

・信頼関係を築いていくこと

・相手のせいにしないこと

は大事かなあと。

 

 

指導される側を石、指導する側を磨く人に例えると、良い石なら磨く人が誰であれキレイに磨けるだろうし、磨く人の腕が良ければどんな石だってキレイに磨けるだろうし、そんな石、磨く人に出会えた人は幸運でしょう。

ただ出会えるとは限らないので、石は石なりに、磨く人は磨く人なりに、いろいろと試してお互いに切磋琢磨していくことになると思います。

 

 

最後に、なんかいいじゃんこれ!と私が思ったマネジメントの記事を紹介します。

blog.kentarok.org

Excelのデータに重複がないか確認する

Excelのデータに重複がないか確認する方法を調べて試した時の備忘録。

Excelでコード採番したものの、コードが飛んでいる箇所があり、目視での確認は難しい。
前日作業して一晩おいて翌朝セルフチェックしようと思っていたのに、がっつり睡眠時間を削ってしまい、朝から頭はまわらない。
じゃあもうExcel(システム)にしてもらった方が確実だよね、なにか方法はないかな。
…ということで「エクセル 重複 チェック」でググって下記のWebページを発見。

www.becoolusers.com

重複チェックするセルを範囲選択

ホーム > スタイル > 条件付き書式 > セルの強調表示ルール > 重複する値
OK

あとは色フィルターでコードが重複していないか確認すればOK。
採番コードに重複が見つかったので、コードを採番し直しました。
早く気づけてよかった…。