Kuehar's Blog

非効率はやめよう ということでよくあるコードとして紹介されていた内容をそのままメモ。 使えるようにしておく。 public class concat { // ループごとにStringBuilderオブジェクトを生成し、2回のappend処理を行う。非効率になる可能性高し。 static String concatTest1 ( String [ ] array ) { String result = "" ; for ( String s : array ) { result += s ; // +=演算で文字列結合 } return result ; } // 効率よし。ただしイミュータブルなStringを使わないことでバグが出やすくなるためそこの安全性を取るか効率を取るかはご自由に。 static String concatTest2 ( String [ ] array ) { StringBuilder result = new StringBuilder ( ) ; for ( String s : array ) { result . append ( s ) ; // +=演算で文字列結合 } return result . toString ( ) ; } }

Javaの ? true a:b;←これ何よと思ったので Javaの ? true a:b;←これ何よと思ったので 発端はLeetCode。 Javaで書くか〜と思い、書いた後に Solution で使われていたこれ。 public ListNode addTwoNumbers ( ListNode l1 , ListNode l2 ) { ListNode dummyHead = new ListNode ( 0 ) ; ListNode p = l1 , q = l2 , curr = dummyHead ; int carry = 0 ; while ( p != null || q != null ) { int x = ( p != null ) ? p . val : 0 ; //　ここ int y = ( q != null ) ? q . val : 0 ; int sum = carry + x + y ; carry = sum / 10 ; curr . next = new ListNode ( sum % 10 ) ; curr = curr . next ; if ( p != null ) p = p . next ; if ( q != null ) q = q . next ; } if ( carry > 0 ) { curr . next = new ListNode ( carry ) ; } return dummyHead . next ; } ということで調べた。 三項演算子だった。 ? true a : b ; 評価式がtrueの場合、 : の左側(この場合は a )が返る、ということで、値を返すだけならば書きやすくなる。

StringBuilderとStringBufferの違いを言えるか 違い 備考 StringBuilderとStringBufferの違いを言えるか という話。 どっちでもいいんじゃん？というのが大多数の正直な意見かもしれないがどうせ使うならいい方を使いたい。 ということで調査、アンドメモ。 違い StringBuilderはJava5で導入された。 それ以前から使われていたのがStringBuffer。 二つの違いは排他制御があるかどうか。 Java8の StringBuilder ドキュメントでは、 文字の可変シーケンスです。このクラスは、StringBufferと互換性があるAPIを提供しますが、同期化は保証されません。このクラスは、文字列バッファが単一のスレッド(一般的なケース)により使用されていた場合のStringBufferの簡単な代替として使用されるよう設計されています。このクラスは、ほとんどの実装で高速に実行されるので、可能な場合は、StringBufferよりも優先して使用することをお薦めします。 と書いてある。 StringBufferを使用すればメソッドが呼ばれる度にStringbufferオブジェクトがロックされます。 つまり排他制御が行われるわけですが、それと同時に速度も犠牲にしている。 もっというとほとんどのケースの場合、スレッドセーフである必要がないためStringBuilderの方が速いし基本はこっちを使っておけば良い、という話。 ちなみに逆にStringBufferの方が明確に良いケースってあるんですかね。 パッと思いつかないのでどこかで考えてそれでパターン分けしていれば困ることは無くなりそう。 備考 StringBuilderの構造はこんな感じ。

文字列を処理しようという時に・・・ 文字列を後ろから抽出したい時は 文字列を処理しようという時に・・・ IndexOutOfBoundsException と StringIndexOutOfBoundsException 、これらの例外に出くわすことが多いので。 メモ程度の内容。 まあ存在しないインデックスを指定するときがほとんど。 例えば以下のコードのように。 class Main { public static void main ( String [ ] args ) { String s = "abc" ; // 以下の例はいずれもStringIndexOutOfBoundsExceptionが発生する s . charAt ( - 1 ) ; s . charAt ( 3 ) ; // 抜き出し位置が存在しないので例外が投げられる s . substring ( 1 , 3 ) ; // そもそもsubstring(開始位置,終了位置)なので対応していない s . substring ( 2 , 1 ) ; } } 文字列を後ろから抽出したい時は String型 . substring ( String型 . length - 切り出したい文字列の長さ ) ; というやり方でやっといてね！とのこと。

JavaでStringを生成する時はnew生成をやめようね！！という話。 なぜ書くのか 調査でどういう結論に至ったのか JavaでStringを生成する時はnew生成をやめようね！！という話。 String s = new String ( "0123456789" ) ; という書き方の話。 なぜ書くのか String a1 = "Hoge" ; String型を宣言するときにこういう書き方をしていたが、最初のnewする書き方と何が違うのか気になったので調べてみると違うものとして扱われてたのでメモ。 調査でどういう結論に至ったのか String s = new String ( "0123456789" ) ; という書き方は通常のオブジェクト同様にヒープ領域にインスタンスを作成する。 対して、 String a1 = "Hoge" ; String a2 = "Hoge" ; この書き方は定数として定数プールに保存される。 あえてnew Stringを使う明確な理由がない限り、Stringを変数に設定する場合は、 String str = "Hoge" ; というようにリテラルを直接指定し、 new String は使わないのがセオリーとなる。 そうすればStringオブジェクトを必要最低限で済ませることができ、メモリにもまたパフォーマンス的にもよい結果となる、らしい。 ちなみに文字列を作成した場合、JVMはまず最初に定数プールを見に行き、もし定数プールに同様の文字列が存在する場合には同じ参照を与える。 String型が不変の理由もここら辺にありそう。 それはまた別の記事で調べたいときに書きます。 今回は以上。

始める前に 範囲 知らなかったこととかのメモ。 テーマ：I Have Allergies 知らなかった語彙 使えそうな例文 テーマ：At the Gym 知らなかった語彙 使えそうな例文 テーマ：Weight Loss 知らなかった語彙 使えそうな例文 テーマ：Scheduling a Doctor’s Appointment 知らなかった語彙 使えそうな例文 テーマ：Health Check-Up I: Medical History 知らなかった語彙・使いたいけど使えていない語彙 使えそうな例文 Health Check-Up II: The Physical Exam 知らなかった語彙・使いたいけど使えていない語彙 使えそうな例文 始める前に 一日更新は時間がかかり過ぎてしまう（他のこともやりたい）ので、メモをまとめておいて、今回みたいに週末にまとめて出すか、それともメモレベルでいいので毎日出すのか、というのはとりあえず試してみてということで。 ひとまずこれからは週末に出します。 範囲 Health & Lifestyle Staying Healthy 04~10 知らなかったこととかのメモ。 テーマ：I Have Allergies 知らなかった語彙・使いたいけど使えていない語彙 pollen 訳：花粉 itchy 訳：痒い swell up 訳：腫れる water 訳：涙を出す、分泌液を出す。 hay fever 訳：花粉症 shellfish 訳：貝、甲殻類 sting(過去形はstung) 訳：針で刺す、刺すような痛みを与える hives 訳：蕁麻疹 例： My daughter broke out into **hives** after eating peanuts. antihistamine 訳：抗ヒスタミン剤 eye drops 訳：目薬 使えそうな例文 What are you allergic to? 訳：何にアレルギーがありますか？ be allegic to~ でアレルギーがある、という聞きかたを他の例文でもしていたのでアレルギーを聞くときに使えそう。 I

知らなかったこととかのメモ。 テーマ：Healthy Eating 知らなかった語彙 真似したい表現 知っていたけど普段使えていない表現 知らなかったこととかのメモ。 テーマ：Healthy Eating 今回からフィットネス/健康について。 やりたいテーマだったのでモチベーションは高め。 知らなかった語彙 nutrient 訳：栄養になる物、栄養分 単体では知らなかった気がする。 nutritious とかなら知ってたけど。 We get so many **nutrients** from nuts. 意：私たちは、ナッツからとても多くの栄養分を得ます。 rich in 訳：豊富な healthily 訳：健康的な healthの副詞。 healthyは形容詞。 例文では I should probably eat more healthily. と使っていたのでそのまま覚えても良さげ。 嗜める場合は主語を変えるだけでいいし。 rich in ~ 訳：(栄養分が)豊富な~ Chicken breast is rich in protein. 意：鶏の胸肉はタンパク質が豊富だ。 真似したい表現 I eat out almost every day now 訳：ほとんど毎日外食してる これ自体は大したことない表現だけど、ほとんど毎日〇〇してるは使い所が多そう。 I hit the gym almost every day now とかだったら最近の生活スタイルでも使える。 知っていたけど普段使えていない表現 why don’t you ~ めちゃくちゃ簡単な表現なのに全然使えていない。 この機会に使うようにしたいなぁ… 今回はこんな感じ。 毎日英会話自体は続けているが他のことをやっていて記事は書けていないのが少し残念。 やった内容に関しては復習がてら書いていく予定。

いや、それgrepコマンドで良くない？？？ 単一ファイルの変換 カレントディレクトリのファイル全てを対象にする場合 いや、それgrepコマンドで良くない？？？ と言われること間違いなしの内容。 ただ僕自身、誰かにこれやってね！！と言われるとパッと思い浮かばなかったので自戒のためにコピペで動くように書いておく。 zsh で動作確認をしています。 今のmacOSってプリインストールされてるのzshなの知らなかった・・・ フォルダ構成はこんな感じ。 grep_test | |-----grep.txt |-----grep2.txt あ、 github にファイルを作ってコミット履歴も残していますので、気になる方はそちらも確認どうぞ。 grep.txtには this is grep test file. grep2.txtには is this grep command test????? という文字列が書かれており、共通の文字列として this , grep , test が存在しています。 単一ファイルの変換 まずは単一のファイルの中身を変えてみます。 grepコマンドで 単一 の実行しようとすると $ grep -l '置換対象の文字列' 置換対象のファイル | xargs sed -i.bak -e 's/置換対象の文字列/置換後の文字列/g' となる。 今回は grep.txt の this を that に変えてみる。 その場合、 $ grep -l 'this' grep.txt | xargs sed -i.bak -e 's/this/that/g' となり、 grep_test 内で上記のコマンドを叩くと、 that is grep test file. と変換される。 カレントディレクトリのファイル全てを対象にする場合 カレントディレクトリ内の全てのファイルを対象にして行う場合はこちら。 $ grep -l '置換対象の文字列' ./* | xargs sed -i.bak -e 's/置換対象の文字列/置換後の文字列/g' 今回は全てのファイルに存在するte

知らなかったこととかのメモ。 テーマ：Conveying Your Ideas 知らなかった語彙 知っていたけど普段使えていない表現 知らなかったこととかのメモ。 テーマ：Conveying Your Ideas 自分の考えを伝えるときのテーマ 知らなかった語彙 sound plan a good solid plan that is financially secure or based on valid reasoning 聞こえのいい、って感じの意味合いで sound なのかな。知らなかったし自分で使うこともなさそうだけど誰かが使った時に分かるのは大事なのでメモっておく。 知っていたけど普段使えていない表現 Furthermore/Moreover/In addition/On top of that… 意：加えて Let me offer an example. 意：一例を挙げてみましょう。 for example とか for instace とかと同じ。 Thus/Therefore… 意：したがって What I mean is… 意：私が言いたいのは There is no doubt that… 意：…は間違いありません。 It’s obvious/clear that… 意：…は明らか Regarding/concerning… 意: …に関して When it comes to… 意：になると 知ってるけど使えてないよなぁと思った表現を抜粋。 There is no doubt~ とか使いたい、超使いたい。 今回はこんな感じ。

知らなかったこととかのメモ。 テーマ：Brainstorming Sessions 知らなかった語彙 知っていたけど普段使えていない表現 間違えて覚えてた問題 知らなかったこととかのメモ。 テーマ：Brainstorming Sessions ブレインストーミングするときのテーマ。 知らなかった語彙 Let’s just bounce ideas off each other. 意：お互いにアイデアを出し合いましょう。 bounce ideas off って初めて聞いたけど意見を出し合うみたいな意味らしい。 Wouldn’t it be smarter to…? 意：もっとスマートに…と思いませんか？ テキストではもっといい感じの意見ないのか？って感じで使ってた。 知っていたけど普段使えていない表現 That’s not a bad idea. 意：悪くないアイデアだね ツンデレ。それだけ。 I’m not too keen on that. 意：あまり気にしていません。 keen って受験英語で見た覚えがあるけどこんな意味だったっけ・・・？？ 意味はDeepLで出したものだからこんな感じだけど文脈的にはそれはないわ〜という感じの意味で使っていたので注意。 間違えて覚えてた問題 get along with come up with 何故か come up with を仲良くなるという文脈で覚えていたので調べなおしていた。うろ覚えで使うの良くない。 ちなみに仲良くなるなら Become friends with でも可。 ただ、こちらは知らない人と仲良くなる、と言う意味合いで使うらしい。 ソース： 仲良くなるって英語でなんて言うの？ 今回はこんな感じ。

知らなかったこととかのメモ。 テーマ：Dealing with Problems 知らなかった語彙 知っていたけど普段使えていない表現 考えたい宿題 知らなかったこととかのメモ。 テーマ：Dealing with Problems 問題に対処するときのテーマ 知らなかった語彙 On the upside… 意：良い面では 使ったことない。というか仮に見たことがあっても覚えてない。 They are facing a sales coverage problem. They/We are facing 問題の内容 problem. でかなり使いやすそうな定型表現。 知っていたけど普段使えていない表現 engage in 意：参加する take part in とか join でも代用できる。 そういえばベンチャー界隈の人たちがよく使うjoinしました！みたいなのってどこから始まったんだろう。 We need to do something about this. 意：これを何とかしないといけない。 からの What are our options? で意見を聞くのが良さそう。 そこに対する受け答えで、 The best option would be… 意：もっともいい選択肢は・・・ Another option/an alternative would be… 意：違う選択肢は・・・ の二つをセットで覚えて中身は事柄に応じて考える！みたいな感じかなぁ。 考えたい宿題 Do you often get a chance to discuss the problems that your company is facing? How do you usually decide on the solutions? という質問があってその後に What do you think is the best way to reach a decision in a group discussion? Why do you think so? という質問があった。 一つ目は簡単なのだけど、二つ目は少し手間取ってしまって簡潔に表現ができなかったので反省。