風邪引いた(二週間ぶり)

こんばんは。寒気ともろもろで死んでおります。

今週から仕事始めとなった方も多くおられるかと思いますが、みなさまいかがお過ごしでしょうか。

 

1/7-9までの3日間、私は湯布院〜博多〜別府と二泊三日の旅行に行っていました。

都会でリモートワークしている私にとって、雄大な自然に触れる機会はそう多く無いので、非常にリフレッシュすることができました。

 

しかし、3日目の夕方、空港に向かっている途中で身に覚えがある喉の違和感が発生しました。

暖房のせいかな、などと考えながら帰路に着きましたが、家に着いて翌朝である今日、無事に風邪の症状が出てまいりました。

何を隠そう、先々週も風邪を引いておりました。

 

仕事終わりも近づき少し仕事が落ち着いていたからよかったものの、しかし今回は年始。それも有給2日空けてとのことで、仕事がかなり溜まっている予感。

会社に言えば休むことはできるでしょうか、メールを確認したところなかなかの件数問い合わせが入っていました。これを今週中に済ませるのはなかなか厳しい気がしています。

 

まあリモートワークで顔を出すわけでも無いので、明日はマスクをして、完全防寒状態で、はちみつ湯とポカリでも飲みながらエッサホイサ、えっちらおっちらタスクを消化したいと思います。

 

年末年始はお寺巡りに勤しみ、各地の社にお参りしたというのに、なんだか悪い予感がする、そんな2024年の幕開けとなりました。

では、私は少しだけお仕事の検証を済ませて、さっさと床に就こうと思います。

 

おやすみなさい。

「アドバイス」が持つ魅力に依存していないだろうか。

1. そのアドバイスは、必要か?

アドバイスが持つ魅力

アドバイスをすることは気持ちがいい。

 

アドバイスというのは、自分が相手の考えを訂正する行為である。

これは能力の差に関わらずに行うことができる。
相手が先生で、自分が生徒であったとして、先生が生徒である私にアドバイスを行うことはもちろん、反対に、生徒である私が先生に対してアドバイスをすることだって可能だ。

ここで、自分が相手の考えを訂正する、つまり、一時的にその考えについて自分の方が優秀な考えを持っていると錯覚することがある。

しかし、私は、基本的にこの世の全ての物にはそれが考えられた・決定された「理由」があると思う。
アドバイスをする前にはその「理由」が感情的なモノなのか、理性的なモノなのかを考慮する必要があると私は考える。

 

「理由」を考える

イマイチ分かりづらいかもしれない。例を示す。

私はエンジニアなので、プログラムのソースコードレビューをすることがある。
例えば、相手が提出してきたソースコードを見たとき、自分であればより簡潔に、より速く処理を終わらせることができるようなソースコードを思いついたとする。
きっと、私は相手より良いコードを思いついたので、アドバイスをしたくなるだろう。

ここで、すぐに「この実装は複雑で、処理も煩雑なので、ここをこのように効率化すると良いですよ。」とアドバイスすることは簡単だ。

 

しかし、自分がコードレビューを依頼した側であった場合に私はどう思うだろうか。

きっと、「こういう理由があってこの実装にしたんだけどな。」と少しは考えることだろう。

 

この「理由」が大切なのだ。

 

「参考にしたサイトで書いていた処理をコピペするだけで実装が可能だったため、時短のためにコピペをした」のであれば、アドバイスは素直に受けるべきだろう(当然、相手のアドバイスが真に要件に従っているか議論をする必要はある)。

→この場合、アドバイスを受けた側は、素直にコードを修正して再度レビュー依頼を行えば良い。

 

「他の環境で利用されているコードを参考に書いたため、コードの一貫性を保つために現在の書き方を採用した」のであれば、今後のコードの保守性も考えると、実際には複雑な処理を書いていたとしても、可読性の面では、統一した方がいいこともあるだろう。

→この場合、「いや、私はこういう理由でこの書き方を採用したんですけど、どう思いますか。」というやりとりが発生するだろう。このとき、アドバイスのされ方や、人によっては少しイラっとして返答をすることもあるかもしれない。

 

つまり、アドバイスの仕方によっては、相手を「イラつかせてしまう可能性」があるのだ。

そしてそれは、「それを決めた・考えた理由」に起因すると私は考えている。

 

そのため、アドバイスをする前には理由を知るというステップを、必ず踏むべきだと思う。

 

先ほどの、アドバイスの例を再度示そう。

「この実装は複雑で、処理も煩雑なので、ここをこのように効率化すると良いですよ。」

 

これに、ワンクッション、そう考えた理由を聞くステップを追加するとどうなるだろうか。

「この実装は一見複雑で、処理も煩雑に見えますが、このように実装をしている理由はありますか?もし、参考にしたサイトやコードがあれば教えてください。」

 

どうだろうか。

返答に応じて、アドバイスをする、しないを決めることができるようになった。

実装の際に考えた理由を相手に聞くことにより、自分のアドバイスが、相手にとって本当に必要だったかが分かるようになったとは感じないだろうか。

 

これにより、「アドバイスをしたい自分」や、「アドバイスをされたことによるイライラ」を、いきなり発生させることなく、相手とのコミュニケーションのファーストステップから感情を排すことができた。

 

長くなったが、こういうことを私は、常日頃意識するように努めている。

 

2. Xにおける、昨今のアドバイスの性質について

昨今、政治批判をするツイート(ポスト)をよく見かける(これは、私が多少政治に対して興味があり、そういったツイートの詳細やリプ欄を確認することがあるために、"おすすめツイート"として流れてくることも影響しているかもしれないが)

 

2024/01/04に、日本が台湾など、諸外国からの能登半島地震の支援申し出を断ったことが公表された。

 

そのことに対して、「日本は台湾の支援を断った」として、「なぜ断るんだ、今は猫の手でも借りたい状況じゃないのか」「台湾との関係性が悪くするぞ」など、色々なアドバイス(批判)が殺到した。

その後、台湾から、『「台湾を断った」との言い方は、台日間の調整の事実とは合致せず、公平性を欠いている』という声明が出された。

japan.focustaiwan.tw

実際、岸田総理からも『受け入れ態勢の構築のために要する作業や、現地の状況などを鑑みて、現時点では人的・物的支援については、一律で受け入れていないという状況にある』ことは説明されている。

 

これはあくまで一例だが、「理由を知る」というワンクッションを挟まずに、他人に意見することは簡単だが、それによって誰かに余計な手間をかけさせたり、混乱を招くこともあることが良く分かる事例だ。

 

このようなことは、本当によく散見される。

しかし、SNSでは「理由」を知ったことによりアドバイスが不要だと分かり、静観するような人は、基本表に出てこない。静観する人はツイートをする必要がないからだ。

 

これこそが、SNS陰謀論者が多く、まともな人が少ないと感じる大きな要因の一つだと考えている。

陰謀論者の意見ばかり目にすると、どうしてもその考えに流されてしまう人が出てくる。そうして、反ワクチンや反コロナ、行きすぎた環境活動家などがドンドン生まれてしまうのだろう。

非常に残念なSNSの性質だと私は思う。

3. まとめ

ここまで、アドバイスの魅力と理由を知ることの大切さについて書いてきました。

長々と、最後まで読んでくれた方に感謝の意を表します。

このようなこと、言わずとも分かっているという人が大半だとは思いますが、昨今のSNSを見ていると不安に駆られてしまい、勢いに任せてこのような記事を書いてしまいました。

 

この記事によって、少しでも、誰かにアドバイスをしたいと思っても、その前に「物事の理由」を知るワンステップを挟むことで、本当にそのアドバイスが必要なのかを少し立ち止まって考えることができることができる人が増えてくれたら嬉しいな、と一縷の望みをかけて、筆を置かせていただきます。

 

あ、新年の挨拶を失念しておりました。

明けましておめでとうございます。本年も、よろしくお願いいたします。

『ハーモニー/伊藤計劃』読後感想

はじめに

お久しぶりです、Soraです。 読書感想文です。

本の紹介

では、早速本の紹介に移りたいと思います。

今回私が紹介する本は、伊藤計劃さんの、「ハーモニー」です。

www.hayakawa-online.co.jp

アフィリエイトではありません。

感想

最初に感想話しちゃいます。

久々に本読みました。神保町に行って本を買い、3冊の本読みましたが、その中でもこのハーモニーが正直ぶっちぎりで面白かったです。

面白すぎて、ー映像化されているのでー映画もレンタルして見てしまいました。

なんというか、全てが将来的にあり得そうなんですよね。

あらすじ

ではどんな世界で、どんなことが起きるのか、簡単にあらすじを説明させていただきます。

21世紀後半、つまり今から数十年後に当たりますね。 <大災禍>というアメリカでの暴動を発展とした核戦争が起きて、感染病が蔓延したことなどが原因で、すごい数の人が死んだんです。

この大災禍の後、やっぱ健康・平和じゃなきゃダメだよねって感じになりまして、世界的に健康と平和への意識が高まったんです。 それにより、医療が非常に発達して、ついに全ての病気が消え去った-それこそ事故と老衰以外で死ぬことがなくなった-そういう、高度な福祉更生社会が舞台になります。

誰もが健康で平和に生活を送れる。まさにユートピアですね。

人々は一定の年齢になると、WatchMeっていう健康状態を監視するようなナノマシンを体内に入れるんですね。 WatchMeによって、少しでも健康状態を害そうものなら視界に警告が出たり、病気を早期発見しようものならWatchMeが医療分子を作りだし、自動でそれを治したり…。

ある意味、WatchMeによって、ずっと監視をされているような、そういう社会なんです。 でも、この世界ではそれが当たり前って考え方になっているんですね。

健康状態を害すようなものは全てダメ。 タバコやアルコールは当然、カフェインすら制限されています。「暴力」があるからという理由で、過去のほとんどの映画などの作品も閲覧不能と言う潔癖ぶりです。

みんなが同じような体つきなんですよ。ここはぜひ映像化されているので映画で見てほしい。 何人も人が出てくるのに、全然覚えられないんですよ。何の特徴もないから。 重要なファクターを担うようなキャラですら、映画を見終わった時には姿を思い出せないんです。

ま〜〜〜〜大抵上手くいかないですよね(笑) こういう技術が高度に発達しすぎた世界は。

事件発生

あるとき、死なないことが是とされた世界で大量の人間が、同時に、様々な手法で自殺を遂げます。

この様子がまた、自殺者の目線で描かれているんですけど、錯乱した様子とか一切なく、なんというか、死ぬことが当然であるかのようにごくごく自然に行われるんですね。 この表現が非常に上手い。

なんで自殺するのか、これにはまた理由があるんですけど、これは是非本編を読んで確認してほしいです。

この事件を追うことになるのが、そんな社会に嫌気が差し、幼少期に餓死を失敗しようとした主人公なんです。

これがまた、共に餓死をすることを提案し、そして死ぬことに成功した少女の後を追い続けている。そんな人なんですよ。 ある意味崇拝的な気持ちまで見え隠れするんですね。 こういうのが好きな人、結構多いんじゃないかなと思います。私がそうです(笑)

特に好きな場所を引用

次に、私が読んでいて考えさせられた、そんな文章について引用してご紹介します。

システムがそれなりに成熟していれば、意識的な決断は必要ない。これだけ相互扶助のシステムがあって、これだけ生活を指示してくれるソフトウェアがあって、いろいろなものを外注しているわたしたちに、どんな意志が必要だっていうの。問題はむしろ、意志を求められることの苦痛、健康やコミュニティのために自信を律するという意志の必要性だけが残ってしまったことの苦痛なんだよ

みなさん、どうですか。ChatGPTとか普段使っている方、AIに何かの選択を任せている方は、刺さるところがあったのではないでしょうか。

現在社内でCopilotの導入進めていたりしますが、アレらが提案してくるツールに任せてコードを書いているとき、自分の存在意義について少し考えたりはしませんか。

私は、これには「意志」が関係しているのかな、と読んでいて思いました。 もっともっとお伝えしたいシーンはたくさんあるのですが、時間と、あとどこをとってもネタバレになってしまいそうなので、紹介はこの辺でやめておきます。

まとめ

全体的に優しい世界のはずなのに、なぜか少し不気味な世界観。

ストーリーとしても分かりやすく、また読んでいるこちらが「自分の意識」について、不安を覚えさせるような表現。 伊藤計劃さんが、構成した非常にロジカルで、かつ繊細で、人の心・考え方を揺さぶるような力強さも持った作品となっています。 ハーモニーには、映画版もありますが、とにかくまずは小説で読んでほしいです。

私からの紹介は以上です、ありがとうございました!

今更ジェネレーティブAIについて勉強してみた

はじめに

タイトルの通りです。ずっと批判的な目線で見てきたジェネレーティブAI(いわゆる画像生成AIやテキスト生成AIと呼ばれるサービス)について、何も知らないまま批判するのもどうかと思ったので、Udemyを使って勉強してみました。

結論から書くと、上手いこと使えば商用に活かせるようなものも作れるでしょうが、生成したものを完成形として商用とするには少しレベルが低く、生成されたものを修正する知識や技術は身につけなければならないと思います。様々な工程において、時短テクとして使用されることはあるでしょうね。

そもそもAIとは

AIとは、かなり広義の意味合いを持つものです。

AI(人工知能)は、「コンピュータによって、生物の知能や、もしくはその延長線上にあるものを再現する技術」を指します。

現在は汎用人工知能と、特化型人工知能の2つに分類わけされています。

汎用人工知能

汎用人工知能は、アニメや漫画などで登場するような、人の知能並みの汎用性を持ったAIを指します。

鉄腕アトムや、プラメモのアイラのような感じですかね。 現在は、実用化に至っていない。とされています。

特化型人工知能

対して、特化型人工知能は、現在実用化されているような、将棋専門のAI、画像認識に特化したAI、自然言語処理に特化したAIを指します。

要は、特定の分野のみに特化した人工知能、ということですね。 中でも、自然言語処理の分野はChatGPTの登場によって、近年特に注目されていますよね。

このように、AIと一口に言っても、かなり広義の意味を持つ言葉なのです。分野も関係ありませんし、機械学習アルゴリズムも、教師の有無も、何なら機械学習でさえないかもしれません。AIという分野の中に、機械学習があり、その中に、教師あり学習教師なし学習強化学習と言った分野が存在し、その更に中にディープラーニングと呼ばれる技術が存在する、といった形の構造になっています。

では、タイトルにもなっているジェネレーティブAIとはどういった分野の、どういった方法で学習をしたものなのでしょうか。

ジェネレーティブAI

ジェネレーティブAIとは、データを生成することができるAI全てを指します。画像や文章、音楽、コードなど、全てジェネレーティブAIにカテゴライズされます。

今回は詳しいところまで触れませんが、大抵のジェネレーティブAIは、Transformという仕組みがベースとなっているとされています。

補足ですが、ChatGPTは

ChatGPTの仕組み超解説:ChatGPTの裏側大解剖|ChatGPT研究所

を、Stable Diffusionは

StableDiffusion : テキストから画像を生成する機械学習モデル | by Kazuki Kyakuno | axinc | Medium

を見るとある程度詳しく構造について知ることができると思います。LLMやCLIPについて私は知らなかったので、とても勉強になりました。

これまで、ジェネレーティブAIを使って何かを生成する際には、プログラミングのコードを用いて、ニューラルネットワークを構築するなり使用するなりして、コードを用いて、AIの操作を行っていました。これには、機械学習や数学の知識が必要でした。

それが近年では、ChatGPTのように、自然言語(英語や日本語)を用いることによって誰でもプログラミングの知識を必要とすることなく、ジェネレーティブAIを使えるようになったのです。これにより、絵や音楽、コーディングといった、専門技術の民主化が起きたわけですね。

実際に使ってみる

一般に、画像生成を扱うための手順は以下のようになっているようです。

画像生成手順

  1. Chat GPTに欲しい画像を説明した文章を作成してもらう
  2. DeepLなどで英語に変換する
  3. 画像生成AIに投げる 4.できた画像から欲しい情報が抜けていた場合、プロンプトにその情報を付加
  4. 3-4 を繰り返す

実際に私もやってみました。

まず、作りたい画像を決めます。

今回は、たまたま聴いていたさつきがてんこもりさんの、廃人シュプレヒコールのサムネイルの初音ミクのような画像を作りたいとします。

www.nicovideo.jp

次に、ChatGPTにイメージした画像を簡単に説明した文章を投げ、それをプロンプト(命令文)化するように依頼します。

次に、DeepLに投げて英語にしてStableDiffusionに投げようと思った……のですが、いつの間にかStableDiffusionの無料版は公開終了していたようです。

代替品として、Bing Image Creatorを用います。この子はプロンプトが日本語でもいけるので、翻訳はせずにそのまま投げます。

少し待って、出力された画像がこちらです。

暗い部屋でパソコンに向かう初音ミクのようなもの
まあ大体イメージ通りですね。言いたいことは色々とありますが、試行回数1回目ならこんなものでしょう。

感想

やってみて思いましたけど、これをお絵描きというにはあまりにやっている作業に「描き」が少なすぎます。というか描いてませんしね。

文字をキーボードで「打って」、自然言語処理AIに画像生成AIへの命令文として使用できるようなプロンプトを「生成させて」、画像生成AIへ生成したプロンプトを「入力して」「出力させている」わけですから。

自分が無から有を生み出しているわけないのに、これをお絵描きや絵師などと名乗れる人は逆に肝が据わっているというか…言ってて悲しくならないんでしょうかね。

ただ、ChatGPTの日本語生成能力は正直驚きました。今回使用したのはGPT3.5なので、もう少し不安定な日本語を生成するかと思っていたのですが、Twitterに溢れている日本語の文章の方が、よっぽど読みづらいし、変だと思います。

今回生成された画像もGPTが出力したプロンプトに書かれている条件をかなり抑えている気がします。もっと細かく条件を指定し、何回も試行を行えば欲しい画像を得ることもできるかもしれませんね。

総評

流石にお絵描きと言うにはおこがましいと思いますけど笑

人に何かを作ることを依頼する時、頭の中にあるイメージを言葉で伝えるのは難しいし、かといってイラストを描くにはそれなりの技術や知識が必要とされる気がしているので、簡単なイメージ図を生成して、完成版は本職の人にお願いするのが綺麗な活用方法なのかな。と思います。 0→1をつくる中の、0→0.5くらいにはなるんじゃないですかね。

結局、完成したものを評価するのは人間なので、技術や知識は必要になります。 AIさえあれば勉強はいらないと人間が勉強をやめてしまえば、AIも学習する対象が成長しないので進化は止まります。

結局勉強はし続けなければならないし、作業が0になることはないし、イラストレーターや動画クリエイター、プログラマーといった、大分類の職業がなくなることはしばらくは起こらないでしょうね。

限定的な立場の人間がジェネレーティブAIに取って代わられることはあるかもしれないので、自分がこれから先、どういった立場で社会に貢献していくのか。そのことを一度考えることが、多くの人に必要になるかもしれませんね。

『推し、燃ゆ』読後感想

はじめに

どうも。Soraです。

 

お久しぶりですね。ゴールデンウィークはいかがお過ごしでしょうか?

私は特にやることもなく、怠惰に日々を過ごしておりました。

何かやるか、と重い腰を上げ、買ったはいいものの積んでいた『推し、燃ゆ』を今し方読み終えました。

 

いつ聞いたのかも覚えてないですが、話題になった時でしょうか。推しが炎上した女の子を扱った作品、という前情報だけを覚えて読みましたが、思ったよりヘビーな作品なんですね。読みながら驚いていました。

 

読み終わった直後で若干気持ちが重たいですが、その気持ちを消化するためにも、自分にこの本を落とし込むためにも、感想を書いていきたいと思います。

 

あらすじ

本作の主人公は(明記されていませんが)、恐らく発達障害(適応障害かも?)の女の子です。

普通の生活を送るための最低限はこなせるものの、覚えることが苦手で、何をするにもメモをしないといけない。でも、そのメモを見ることを忘れてしまうような子。

そんな女の子が、人生を捧げるくらいの推しに出会います。

人生の熱の大半を捧げた推しが炎上したことで、少しずつ、少しずつ、しかし確かに、日常が歪んでいってしまう。そんなお話です。

 

これは本編とは関係ないのですが、この本は可愛らしいピンクのジャケットを捲ると、主人公の推しのイメージカラーである青が一面に広がっています。

また、スピン(本についているしおりの紐)の色も青色です。

 

これは電子版では気付きにくい、デザインの工夫ですね。めっちゃ良いと思います。

 

感想

この本を読んで私の人生を思い返すと、遠い昔、推しがいたことを思い出しました。

Pixivでイラストを探しまわり、Twitterで推しの魅力について長文を語り、グッズは買えるだけ買う。典型的なオタクですね。

 

そんな私も歳をとり、誰にとっても当たり障りのないエンタメを好きになり、流行りのものに触れ、自分の意見を殺し、何にでも折り合いをつけて、常に誰かの目を気にしながら生きるようになりました。

もうあの頃の気持ちは何にも残っていないですし、何があんなに私を惹きつけていたのか。推しの魅力はなんだったのか。それすら曖昧になっています。

 

作中で主人公のあかりは

「推しは命に関わるからね」

なんて言っていました。

 

彼女の心情は、今の私には共感もできず、想像もできませんが、彼女の人生そのものには羨ましさを感じます。

これまでの私の人生は、彼女のように作品に落とし込まれることはなく、誰かの記憶にも大して残らず、たくさんの人の心を動かすようなものでもないですから。

 

他人の目を気にしないほどに熱中できるものに、いつかは出逢いたいものですね。

【随時更新】スッキリわかるJava入門 第3版 学習記事【Java】

概要

スッキリわかるJava入門 第3版で学習したことについて、ノート代わりにまとめていく記事になります。

私の読書ペースとやる気次第で更新されます。

目次

1章

Javaのコードファイル名について

私は書籍に記載されているdokojavaではなく、実際に自分で環境構築を行なってプログラムを模写していく形をとりました。

環境構築を終え、サンプルプログラムを実行しようとすると、以下のエラーが起きました。

The public type Class must be defined in its own file

なぜだろう?と思い読み進めてみると、Javaではソースファイル名とpublicクラス名が同一である必要があるらしく、ソースファイル名をcode0_1,publicクラス名をmainとしていたいきなりつまづきました。

驚きのルールですが、関数ごとにファイルを分ける癖がつきそうなので良いのかもしれないですね。

コードブロック構造について

C/C++などの言語では、「{」「}」で区切られた範囲のことをコードブロック、なんて呼びますが、Javaでは、コードブロックが必ず2重構造になるようです。

各ブロックはクラスブロック、メソッドブロックと呼ばれ、メソッドブロックにコードを記述していくことになります。

Javaにおけるブロック構造

また、メソッドブロックで使うであろう変数には、いくつかの予約語が存在します。この予約語を変数名に当てることはできないので、注意が必要になります。

予約語一覧はこちら

Java | Javaの予約語

2章

リテラル

実際に変数に格納するなど、プログラムに記述される数値や文字のことを、リテラルと呼びます。 この時、リテラルは記法次第で様々なデータ型へと変化します。

特に、 「long」「float」型は他言語と記法がかなり違うので、気をつけないといけません。

主なリテラルの種類 記入方法
整数(int) 123
整数(long) 123L
浮動小数(double) 1.23
浮動小数(float) 1.23F
文字(char) '1.23'
文字(string) "1.23"

末尾につける「l」や「f」などの文字は、大文字でも小文字でもどちらでも大丈夫です。

一部を抜粋しただけなので、詳しく知りたい人はこちらをご確認ください。

Java : リテラルの表記方法いろいろ - プログラミングTIPS!

軽く検索した中で一番わかりやすかったです。

ちなみに、long型にint型を、double型にfloat型を格納することはできましたが、int型にlong型を、float型にdouble型を格納することはできませんでした

Type mismatch: cannot convert from double to float Java

これは、Javaが数値型に取り扱う数値範囲を元にして大小関係をつけており、小さな型から大きな型の変数へ代入する場合のみ変数の型に変換されて代入される、という仕様を持っているからだそうです。

数値型 扱える範囲の大きさ
浮動小数点型 double
浮動小数点型 float
整数型 long
整数型 int
整数型 short
整数型 byte

とはいえ、もちろん正しく格納するのが一番なので、基本的には公式で推奨されている形に従って書くのが良いでしょう。

文字列型の比較

文字列型(String)の比較は通常の比較方法ではなく、equals()を用いて行う。

以下はプログラム例。

// 文字列の比較方法
String msg1 = "Hello";
String msg2 = new String(msg1);

System.out.println(msg1 == msg2); 
System.out.println(msg1.equals(msg2)); 

/* 実行結果
false
true
*/

msg1とmsg2は同一の文字列が格納されているにも関わらず、演算子「==」で比較した際には実行結果としてfalseが返ってきています。

これは、javaにおいて、演算子「==」が同一の参照先であるかを比較するために起こるようです。

つまり、以下のように、二つのString変数が同一の参照先を示している場合には、trueが返ってきます。

// 文字列の比較方法
String msg1 = "Hello";
String msg2 = msg1;

System.out.println(msg1 == msg2); 

/* 実行結果
true
*/

しかし、先ほどのように、内容は同一でもnew演算子によって新たにメモリ上に参照先が作成された場合には、異なる参照先を示すためにfalseが返ってきてしまいます。

そこで、文字列の比較ではオブジェクトが示す内容が同一かを確かめるためにequals()が必要になるわけです。

詳しい説明はこちら

String (Java Platform SE 8)

を参照してください。

4章

3章は特に目新しい学びはなかったので省略。

配列の書き方

配列の宣言には型の宣言時に"[]"をつけるそうです。

// int型配列変数の宣言
 int[] hoge;
// int型の要素を作成
 hoge = new int [5]

// 宣言と要素の作成を同時に行う場合
int[] hogehoge = new int [10]

他言語でよく使われる以下の形でも配列の宣言が出来ますが、上記の形でも間違いではないことに注意です。

 int hoge[];
 hoge = new int [5]

 int hogehoge[] = new int [10]

5章

メソッド

Javaオブジェクト指向言語ですから、関数の他にメソッドという概念が存在します。

関数同様、引数を与えることができ、戻り値を返すことができます。

使い方も機能も似通っているので、オブジェクトの中にある関数=メソッドという理解でも困ることはないのかなと思いました。

具体的な細かな違いについては、以下のQiita記事が参考になりました。

関数とメソッドの違いとそれぞれを考えてみる(Javaで) - Qiita

値渡しと参照渡し

Javaでは、引数の渡し方に値渡しと参照渡しの2つの手法が存在します。

厳密にはJavaには値渡ししか存在しないようですが、著書で理解を簡単にするために参照渡しと呼んでいるので私もそれに倣っています。詳しくは[こちら]もう参照渡しとは言わせない - Qiita

メソッドに引数を与えると、基本的には値渡しとなるので、以下のような挙動を示します。

    public static int add(int x,int y){
        x++;
        int ans = x + y;
        return ans;
    }

    public static void main(String[] args){
        int a = 1;
        int b = 2;
        int ans = add(a,b);
        System.out.println(a + "+" + b + "=" + ans);
    }
    /*実行結果
    1+2=4
    */

しかし、配列など、一部変数を引数に用いた場合は参照渡しの挙動を示します。

    public static void incArray(int[] array){ 
        for(int i = 0;i < array.length; i++){
            array[i]++;
        }
    }

    public static void main(String[] args){
        int[] array = {1,2,3};
        incArray(array);
        for(int i : array){
            System.out.println(i);
        }
    }
    /*実行結果
    2
    3
    4
    */

これには、Javaの変数に「基本型」と「参照型」の2種類が存在することが起因しています。

参照型には配列、クラス(Stringなど)が該当し、基本型はそれ以外を指します。

簡単に言うと、引数で基本型は値渡し、参照型は参照渡しとなる。ということです。

詳しくはこちら

Javaの「参照型変数」を理解する:Eclipseではじめるプログラミング(9)(1/2 ページ) - @IT

【Laravel】Laravel Mix使用時に 関数がis not definedとなる場合の対処法

結論

jsファイルでの関数定義を以下のように修正する

function hoge() {

から

window.hoge = function(){
// 非同期関数の場合は以下の通り
// window.hoge = async funtion(){

何で1発で関数だと理解されないのか

おまけです。私が調べた結果をまとめたものになるので、間違えてる部分があるかと思いますが、その場合はコメント頂けると幸いです。

コードが動けば良い方は閉じてokです

Laravel Mixで使用されているwebpackはES6(ES2015)が採用されているそうです。

ES6以降、名前空間(namespace)という概念が追加され、複数のファイルについて、それぞれが名前空間を持つ方式と変更されました。

つまり、各jsファイル内関数はローカル関数として扱われるため、外部から実行できないようになっています。

ES6からモジュールとしてスクリプトファイルを読み込むことができるようになり、それぞれが独立し、必要なものだけをやり取りできるようになったためです。

本来、モジュールの公開や読み込みにはexportimportが用いられますが、LaravelではLaravel Mixを用いた場合、スクリプトの読み込みに以下のような記述を行います。

<script src="{{ mix('js/app.js') }}"></script>

これは、jQueryやReactなど、デザインシステムを実装しているだけであれば問題なく動作します。

しかしクライアントサイドで実行される、クライアントJavaScriptオブジェクトは、ブラウザから見ればローカル関数を呼び出して実行が行われることから 関数 is not defined ~となってしまうわけです。

そこで、windowオブジェクトのプロパティに関数を代入することで、グローバル変数として認識をさせることで対処する、というわけです。

以上、Laravel Mix使用時に 関数がis not definedとなる場合の対処法となぜ解決できるのかについての解説でした。

参考

Laravel Mix使用時にJavascriptの関数が未定義(not found)になるときの対処法

Windowオブジェクト | JavaScript プログラミング解説