編集履歴

質問編集履歴

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2022/01/11 13:52

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -47,122 +47,10 @@
 と二段に分かれること
-```
-俗に言うなんでも屋の人間がよく若手のキャリアプランについて聞かれるので、
-納得するための30minと自分が毎年やっていることを話す
-https://zenn.dev/gama/articles/2893c2ac322152
-ハッカソンで「強強エンジニア」が言っていた有用な情報
-2.プログラミング力を高めるには？
-「結局は地道に書き続けるしかない。
-最初はコードの一部を書き換えたりして学ぶ。
-その次は自分で考えたものを作る。
-もしくは他の人のコードを真似して作る。
-そうすることでプログラミング力は高くなると思います。」
-プログラミングは結局、自分でキャッチアップしないといけないので、
-やる子がやる世界
-4.技術力が追いつかない件について
-とある審査員の方が僕に投げかけた質問です。
-「君は何でプログラミングを始めたの？？」
-僕「そりゃぁ、自分のアイデアを形にできて、今作りたいものがあるからです。」
-Tさんはこの返答が意外だったのか、驚いた表情で、「それめっちゃエンジニア向いてるよ！！」
-僕「いや、でもそれに対する技術力が伴わなくって、、、」
-Tさん「伴わなくて当たり前なの！！今実装したい機能を勉強してやったとしても、あれを追加したい、やっぱ最新の技術に変更しようとなって、結局は技術力なんて一生追いつくことはないんだよ。」
-僕は「技術力がないこと」を理由に開発をしない口実を作っていただけなのかもしれません。
-これを聞いてからは吹っ切れて、個人開発を進めています
-（まぁキャッチアップしながらなので、苦戦を強いられてはいますが笑）
-最後に
-ハッカソンは本当に勉強になります。
-ビビらず、「自分なんか」なんて思わず、参加しましょう！！
-困ったらメンター陣に相談すれば何とかなります。
-開発経験をハッカソンで積んで強強エンジニアを目指しましょう！！
-アドバスター
-http://ad1227-game.herokuapp.com/
-向いてるかどうか別として（ココ大事）
-『育てる,　教える』＜＜＜『仕事できる奴らとイイものマネタイズできるものを作る,学ぶ』
-方が興味がある
-前提となるコンテキスト
-React、TypeScriptをメインでやってきたのでここではその環境を前提にします
-スタートアップ～中規模くらいの組織で新規サービスをつくる場面を想定しています
-◆Worse is Betterという考え方
-http://chasen.org/~daiti-m/text/worse-is-better-ja.html
-https://note.com/ruiu/n/n9948f0cc3ed3
-自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。
-少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必要になると思います。もちろんつくるアプリケーションの複雑度にもよりますが、フロントエンドでCAを必要とするほど複雑なアプリケーションはそう多くはないと思います。
-CAによって外部に依存しない純粋なビジネスロジックを表現したコードを手に入れることができますが、そのトレードオフとしてコード量や複雑性が増加することは無視できません。CAを諦めて、サーバーサイドのOpenAPIの型に直接依存するようにして薄く作るとコード量が少なく理解しやすいコードベースを構築できます。そうすることでCAのメリットとなるビジネスロジックの純粋性はトレードオフとして失われますが、代わりに得られたコードのシンプルさによる理解のしやすさや変更容易性を重視するというのが（自分の理解する限りでの）Worse is Better的な考え方です。
-◆コードの品質の価値を過小評価しない
-書籍Clean Architectureはあの同心円の図が独り歩きしてますが、設計以前の考え方に結構なページ数が割かれていてしかもとても参考になります。
-序盤に出てくる刺さったフレーズを2つ雑に要約してみます。
-１．汚いコードを書く方がクリーンなコードを書くより常に遅い
-　　・スタートアップだから、開発初期だからコードが汚くていいということはない
-２．ソフトウェアの構造は振る舞いと同等の価値を持つ（構造≒変更が容易であること）
-　　・完璧に動作するけど変更ができないより、バグだらけだけど変更が容易な方が良い
-特に2番目は個人的には目からウロコで、ソフトウェアのユーザーに提供する動作・振る舞いと同じくらいアーキテクチャとコード品質が適切に保たれていることが大事という視点はなかったです。同書では構造というエンジニアにしか見えない価値を守るのはエンジニアの責任であり、そのためにはPdMやセールスといったステークホルダーと「闘争」して構造を守る必要があるとまで書かれています。そして1番目にもあるようにコードの品質を高くすることが結局は開発速度を速くするのであればそこに注力するのが正しいと言えそうです。この1番目については書籍Clean Architectureにあるような設計テクニックをつぎ込んできれいで正しい「良い」アーキテクチャを目指したくなりますが、トレードオフを見てWorse is Better的な設計・コードを採用すべきだと思います。
-コンサルタントとうまく付き合う方法（案）
-https://qiita.com/kaizen_nagoya/items/499b0a16ac89c0fe3fb0
-コンサルタントといっても、経営コンサルタントのように、数字ですぐに採否を決められるようなコンサルタントもあれば、技術コンサルタントのように１０年後にしか成果がでず、１０年に１回ぐらいしか呼ばれないような仕事の仕方もあります。
-自分および自分の師匠の流派は、お客様第一で、一度呼ばれたら、次に呼ばれるのは１０年後くらいだろうという想定のもと、一回でできるかぎり解決してしまおうという仕事の仕方です。
-ある塊の仕事を、１年間に平たく伸ばして、年収を確保しようという営業的な配慮はここではしていません。
-お客様の方で、あいつが食っていけなくなって、１０年後にまた頼む時に頼めないと困ると思い、仕事を横流ししてくださるようなお客様を想定しています。
-いかに、言い出せないことを、言いだしてもらうかに半分時間を費やしてもかまわないというのが経験則です。
-経営者があなたではなく、コンサルの言うなりだったら、その会社を辞める良い機会かもしれません。
-優秀なコンサルほど、たくさんの経験があっても、
-自分の話を先にするのではなく、お客様の実情を知ろうとします。
 ```
 #　https://leetcode.com/problems/valid-parentheses/
 class Solution:
@@ -182,4 +70,6 @@
         }
 instance = Solution()
-print(instance.isValid(input()))
+print(instance.isValid(input()))
+```

aaaaaaaaaaaaaaaaaaaaa

2022/01/11 13:52

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -159,4 +159,27 @@
 自分の話を先にするのではなく、お客様の実情を知ろうとします。
-```
+```
+#　https://leetcode.com/problems/valid-parentheses/
+class Solution:
+    print('Hello')
+    def isValid(self, s: str) -> bool: #関数アノテーション   戻り値に期待する型は、引数の閉じカッコの後に、矢印->を付けて示す。
+#[] {} () 　　左がきたら　対応する右を判定
+#　括弧のネストのレベルを数える変数を１つ用意し、文字列の最初から１文字ずつ呼んで行って
+#開き括弧があればレベル＋１　閉じ括弧-1  →　{[ と２連続で来たときはどうする？？　２になったらアウト　値がマイナスになったらアウト
+#「レベルがどの範囲になったときか？を考える」
+#どこかでレベルがマイナスの値になればエラー    #括弧の入れ子を検出
+#https://ja.stackoverflow.com/questions/32938/python%E3%81%A7%E6%8B%AC%E5%BC%A7%E3%81%AE%E5%85%A5%E3%82%8C%E5%AD%90%E3%82%92%E6%A4%9C%E5%87%BA
+        if(  ){
+            return true
+        } else {
+            return false
+        }
+instance = Solution()
+print(instance.isValid(input()))

aaaaaaaaaaaaaaaaaaaaa

2022/01/11 04:57

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,119 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+俗に言うなんでも屋の人間がよく若手のキャリアプランについて聞かれるので、
+納得するための30minと自分が毎年やっていることを話す
+https://zenn.dev/gama/articles/2893c2ac322152
+ハッカソンで「強強エンジニア」が言っていた有用な情報
+2.プログラミング力を高めるには？
+「結局は地道に書き続けるしかない。
+最初はコードの一部を書き換えたりして学ぶ。
+その次は自分で考えたものを作る。
+もしくは他の人のコードを真似して作る。
+そうすることでプログラミング力は高くなると思います。」
+プログラミングは結局、自分でキャッチアップしないといけないので、
+やる子がやる世界
+4.技術力が追いつかない件について
+とある審査員の方が僕に投げかけた質問です。
+「君は何でプログラミングを始めたの？？」
+僕「そりゃぁ、自分のアイデアを形にできて、今作りたいものがあるからです。」
+Tさんはこの返答が意外だったのか、驚いた表情で、「それめっちゃエンジニア向いてるよ！！」
+僕「いや、でもそれに対する技術力が伴わなくって、、、」
+Tさん「伴わなくて当たり前なの！！今実装したい機能を勉強してやったとしても、あれを追加したい、やっぱ最新の技術に変更しようとなって、結局は技術力なんて一生追いつくことはないんだよ。」
+僕は「技術力がないこと」を理由に開発をしない口実を作っていただけなのかもしれません。
+これを聞いてからは吹っ切れて、個人開発を進めています
+（まぁキャッチアップしながらなので、苦戦を強いられてはいますが笑）
+最後に
+ハッカソンは本当に勉強になります。
+ビビらず、「自分なんか」なんて思わず、参加しましょう！！
+困ったらメンター陣に相談すれば何とかなります。
+開発経験をハッカソンで積んで強強エンジニアを目指しましょう！！
+アドバスター
+http://ad1227-game.herokuapp.com/
+向いてるかどうか別として（ココ大事）
+『育てる,　教える』＜＜＜『仕事できる奴らとイイものマネタイズできるものを作る,学ぶ』
+方が興味がある
+前提となるコンテキスト
+React、TypeScriptをメインでやってきたのでここではその環境を前提にします
+スタートアップ～中規模くらいの組織で新規サービスをつくる場面を想定しています
+◆Worse is Betterという考え方
+http://chasen.org/~daiti-m/text/worse-is-better-ja.html
+https://note.com/ruiu/n/n9948f0cc3ed3
+自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。
+少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必要になると思います。もちろんつくるアプリケーションの複雑度にもよりますが、フロントエンドでCAを必要とするほど複雑なアプリケーションはそう多くはないと思います。
+CAによって外部に依存しない純粋なビジネスロジックを表現したコードを手に入れることができますが、そのトレードオフとしてコード量や複雑性が増加することは無視できません。CAを諦めて、サーバーサイドのOpenAPIの型に直接依存するようにして薄く作るとコード量が少なく理解しやすいコードベースを構築できます。そうすることでCAのメリットとなるビジネスロジックの純粋性はトレードオフとして失われますが、代わりに得られたコードのシンプルさによる理解のしやすさや変更容易性を重視するというのが（自分の理解する限りでの）Worse is Better的な考え方です。
+◆コードの品質の価値を過小評価しない
+書籍Clean Architectureはあの同心円の図が独り歩きしてますが、設計以前の考え方に結構なページ数が割かれていてしかもとても参考になります。
+序盤に出てくる刺さったフレーズを2つ雑に要約してみます。
+１．汚いコードを書く方がクリーンなコードを書くより常に遅い
+　　・スタートアップだから、開発初期だからコードが汚くていいということはない
+２．ソフトウェアの構造は振る舞いと同等の価値を持つ（構造≒変更が容易であること）
+　　・完璧に動作するけど変更ができないより、バグだらけだけど変更が容易な方が良い
+特に2番目は個人的には目からウロコで、ソフトウェアのユーザーに提供する動作・振る舞いと同じくらいアーキテクチャとコード品質が適切に保たれていることが大事という視点はなかったです。同書では構造というエンジニアにしか見えない価値を守るのはエンジニアの責任であり、そのためにはPdMやセールスといったステークホルダーと「闘争」して構造を守る必要があるとまで書かれています。そして1番目にもあるようにコードの品質を高くすることが結局は開発速度を速くするのであればそこに注力するのが正しいと言えそうです。この1番目については書籍Clean Architectureにあるような設計テクニックをつぎ込んできれいで正しい「良い」アーキテクチャを目指したくなりますが、トレードオフを見てWorse is Better的な設計・コードを採用すべきだと思います。
+コンサルタントとうまく付き合う方法（案）
+https://qiita.com/kaizen_nagoya/items/499b0a16ac89c0fe3fb0
+コンサルタントといっても、経営コンサルタントのように、数字ですぐに採否を決められるようなコンサルタントもあれば、技術コンサルタントのように１０年後にしか成果がでず、１０年に１回ぐらいしか呼ばれないような仕事の仕方もあります。
+自分および自分の師匠の流派は、お客様第一で、一度呼ばれたら、次に呼ばれるのは１０年後くらいだろうという想定のもと、一回でできるかぎり解決してしまおうという仕事の仕方です。
+ある塊の仕事を、１年間に平たく伸ばして、年収を確保しようという営業的な配慮はここではしていません。
+お客様の方で、あいつが食っていけなくなって、１０年後にまた頼む時に頼めないと困ると思い、仕事を横流ししてくださるようなお客様を想定しています。
+いかに、言い出せないことを、言いだしてもらうかに半分時間を費やしてもかまわないというのが経験則です。
+経営者があなたではなく、コンサルの言うなりだったら、その会社を辞める良い機会かもしれません。
+優秀なコンサルほど、たくさんの経験があっても、
+自分の話を先にするのではなく、お客様の実情を知ろうとします。
+```

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2022/01/11 01:11

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,133 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-```
-（感想）
-私が採用側または、大手なら課す。
-現職で採択するなら、
-チームで使っている技術スタックの問題を選択形式で出題したい。（即戦力がほしい）
-#◆チェックリスト & PRPoint
-「実装ができる」だけは自己中な状態
-→影響範囲が広くなり保守が大変(未然に防ぐ実装)
-#◆コーディング面接・試験
-1.1～2次面接など、選考の序盤~中盤の段階(４５分)
->コンピュータサイエンスに関連した知識を問われる技術面接もある（codingなし）
-事前課題を解き、面接官にその実装について解説をする面接（事前のコーディングに3,4時間かかるものもあり）
-##流れ
-1. 問題の確認
-↓
-2. 解法を考える
-↓
-3. 実際にコーディング
-↓
-4. 解説(工夫点)
-↓
-5. ディスカッション
-- 問題の一部が変わったらどのようにコードを変えるか
-- 計算量
-- 更に改善できるコードがあるかどうか
-- エッジケースに対応できているか
-- コードを書く際に気をつけたこと(コーディング規約など)
-##評価ポイント
-企業により評価方法はさまざまですが、以下の項目については共通していると思ってよいでしょう。
-1. アルゴリズムとデータ構造に関する基礎知識を持っているか
-そもそも基礎知識がなければ解けない問題が出題されるので
-2. 全てのテストケースを制限時間内に通す実装力を持っているか
-→ 入出力例には出ていないエッジケースや例外ケースに気づけるか
-→ 計算量を意識して効率がよく実行時間の制約を満たす実装ができるか
-3. 変数名や関数名を適切に命名するなど、他人が読みやすいコードを書けるか
-一度のコーディング試験で書く必要のあるコードの量はそう多くありません。関数自体を作らなかったり、変数もxやｙなど単純なものを使う場合が多いです。
-また、コーディング試験の形式によっては以下のようなポイントも評価されます。
-・コードを書き慣れているか
-オフラインで実施する場合や、コーディング中の画面をその場で映す形式の場合、コードがスラスラと書けるかを見られる場合もあります。
-・ディスカッションの中で、自分が書いたコードを分かりやすく説明できるか
-コミュニケーション能力やカルチャーフィットについては中盤以降の面接で見られるため、あくまでそれ以前の足切り的な位置づけであるコーディング試験では重要視しない企業が多いと思われます。
-##おすすめ使用言語
-よほど使い慣れている言語が無い限りは、pythonがおすすめ。
-> 圧倒的に楽。
-業務でjavaを使ってますが、効率重視であえてpythonを選択
-#◆対策◆
-コーディング試験はatcoderのビギナーコンテストくらいのレベル
-LeetCodeは、海外で有名なコーディング試験対策サイト(高評価のeasy問題を解きまくる。)
-https://leetcode.com/
-※goodの比率が50%以上の問題を良問
-※力づくではなく、
-しっかりとアルゴリズムを理解しながら解くことをオススメします。bruteforceは、誰でもできてしまうので
-Codilityで苦手な問題の種類を解く。
-楽天などが採用しているらしいコーディング試験サイト
-Atcoderやproject eulerなど利用してもいいかもしれません。
-#要はセンター試験のようなもの
- アルゴリズムをごりごり活用するような会社だと、勉強する価値は大いにある。
-ただし、ある程度の企業規模になれば
-> ※ただし受けた人曰く
-　　新しく勉強したアルゴリズムを業務で使ったことは一度もないです。とのこと。
-コーディングテストが実施される企業
-僕が受けた（コーディングテストの選考があった）企業
-↑難
-SmartNews（競技プログラミング慣れしていないと難しい)
-Recruit
-BizReach
-Rakuten
-Wantedly
-↓易
-その他コーディングテストが実施されることを知っている企業
-Google
-Line
-Yahoo
-プログラミングテストでの選考も可能な企業
-teamLab
-一応僕が知っている範囲だとこんな感じです。（他に知っている方がいたら教えてください）
-体感として、ある程度有名なWeb系の企業だと、コーディングテストが必要な割合は3、4割な気がします。
-✖Paizaのスキルチェック
-就活サービスとしては良いと思いますが、コーディング試験対策には向いていません。 なぜかというと、模範解答が無いため、復習ができないためです。
-```

aaaaaaaaaaaaaaaaaaaaa

2022/01/06 07:03

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -145,4 +145,32 @@
 　　新しく勉強したアルゴリズムを業務で使ったことは一度もないです。とのこと。
+コーディングテストが実施される企業
+僕が受けた（コーディングテストの選考があった）企業
+↑難
+SmartNews（競技プログラミング慣れしていないと難しい)
+Recruit
+BizReach
+Rakuten
+Wantedly
+↓易
+その他コーディングテストが実施されることを知っている企業
+Google
+Line
+Yahoo
+プログラミングテストでの選考も可能な企業
+teamLab
+一応僕が知っている範囲だとこんな感じです。（他に知っている方がいたら教えてください）
+体感として、ある程度有名なWeb系の企業だと、コーディングテストが必要な割合は3、4割な気がします。
+✖Paizaのスキルチェック
+就活サービスとしては良いと思いますが、コーディング試験対策には向いていません。 なぜかというと、模範解答が無いため、復習ができないためです。
 ```

aaaaaaaaaaaaaaaaaaaaa

2022/01/06 01:35

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,105 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+（感想）
+私が採用側または、大手なら課す。
+現職で採択するなら、
+チームで使っている技術スタックの問題を選択形式で出題したい。（即戦力がほしい）
+#◆チェックリスト & PRPoint
+「実装ができる」だけは自己中な状態
+→影響範囲が広くなり保守が大変(未然に防ぐ実装)
+#◆コーディング面接・試験
+1.1～2次面接など、選考の序盤~中盤の段階(４５分)
+>コンピュータサイエンスに関連した知識を問われる技術面接もある（codingなし）
+事前課題を解き、面接官にその実装について解説をする面接（事前のコーディングに3,4時間かかるものもあり）
+##流れ
+1. 問題の確認
+↓
+2. 解法を考える
+↓
+3. 実際にコーディング
+↓
+4. 解説(工夫点)
+↓
+5. ディスカッション
+- 問題の一部が変わったらどのようにコードを変えるか
+- 計算量
+- 更に改善できるコードがあるかどうか
+- エッジケースに対応できているか
+- コードを書く際に気をつけたこと(コーディング規約など)
+##評価ポイント
+企業により評価方法はさまざまですが、以下の項目については共通していると思ってよいでしょう。
+1. アルゴリズムとデータ構造に関する基礎知識を持っているか
+そもそも基礎知識がなければ解けない問題が出題されるので
+2. 全てのテストケースを制限時間内に通す実装力を持っているか
+→ 入出力例には出ていないエッジケースや例外ケースに気づけるか
+→ 計算量を意識して効率がよく実行時間の制約を満たす実装ができるか
+3. 変数名や関数名を適切に命名するなど、他人が読みやすいコードを書けるか
+一度のコーディング試験で書く必要のあるコードの量はそう多くありません。関数自体を作らなかったり、変数もxやｙなど単純なものを使う場合が多いです。
+また、コーディング試験の形式によっては以下のようなポイントも評価されます。
+・コードを書き慣れているか
+オフラインで実施する場合や、コーディング中の画面をその場で映す形式の場合、コードがスラスラと書けるかを見られる場合もあります。
+・ディスカッションの中で、自分が書いたコードを分かりやすく説明できるか
+コミュニケーション能力やカルチャーフィットについては中盤以降の面接で見られるため、あくまでそれ以前の足切り的な位置づけであるコーディング試験では重要視しない企業が多いと思われます。
+##おすすめ使用言語
+よほど使い慣れている言語が無い限りは、pythonがおすすめ。
+> 圧倒的に楽。
+業務でjavaを使ってますが、効率重視であえてpythonを選択
+#◆対策◆
+コーディング試験はatcoderのビギナーコンテストくらいのレベル
+LeetCodeは、海外で有名なコーディング試験対策サイト(高評価のeasy問題を解きまくる。)
+https://leetcode.com/
+※goodの比率が50%以上の問題を良問
+※力づくではなく、
+しっかりとアルゴリズムを理解しながら解くことをオススメします。bruteforceは、誰でもできてしまうので
+Codilityで苦手な問題の種類を解く。
+楽天などが採用しているらしいコーディング試験サイト
+Atcoderやproject eulerなど利用してもいいかもしれません。
+#要はセンター試験のようなもの
+ アルゴリズムをごりごり活用するような会社だと、勉強する価値は大いにある。
+ただし、ある程度の企業規模になれば
+> ※ただし受けた人曰く
+　　新しく勉強したアルゴリズムを業務で使ったことは一度もないです。とのこと。
+```

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2022/01/06 01:32

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,254 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-```
-前提：ポジティブシンキングなんてムダだ！(メタ分析)
-→→心理対比さえ実践すればいい（1回につき15〜20分が目安）
-▼ステップ１：願望（Wish）　もっとも重要なもの１つに絞る
-"仕事やプライベートに関して、自分が抱く希望や不安を詳細にいくつか書き出す（または思い描く）。健康になる！
-見た目が良くなる！
-モテる！
-医療費が減る！
-自慢できる！
-ブログのネタになる！"
-このとき重要なのは、「達成は難しいけど、がんばれば何とかなりそうだ：な〜」ぐらいの難易度設定にしておく：「１年で億万長者」とか「ベストセラー作家に」なんて願望を抱くと、ポジティブシンキングの罠にハマっちゃいますんでご注意ください。また、達成したい願望がいくつもある場合は、自分にとって最も重要なものだけ
-▼ステップ２：成果（Outcome）
-"上で考えた願望や不安に関する「ベストの成果」を思い描きます。しばし頭のなかでメリットをイメージしてみて、一番ポジティブな気分になったものを選べばOK。このとき、選んだメリットについてどんな気分になっているかまでを細かく具体的にイメージすればするほど効果が高まるっぽい。　例：願望：毎日エクササイズをする
-成果：健康で最高の気分になる
-不安：借金を返す
-成果：完済！"
-▼ステップ３：障害（Obstacle）
-"いまの自分の目標を達成するために、どんなトラブルが起きるかを詳細にいくつか書き出す（または思い描く）。具体的な考え方としては、
-どんな考え方が目標の達成をさまたげているのか？
-どんな行動が目標の達成をさまたげているのか？
-どんな癖や習慣が目標の達成をさまたげているのか？
-どんな思い込みが目標の達成をさまたげているのか？
-どんな感情が目標の達成をさまたげているのか？
-みたいな感じ。というと、「金がない」や「親が反対してる」など、環境や外的な問題をあげる人も多そうですが、これはNGであります。そもそも、「願望（Wish）」のステップで「がんばれば何とかなりそうな〜」ってレベルの目標を選んでいるので、主な障害は自分の問題でしかありえないはずなんですね。"
-▼ステップ４：計画（Plan）
-上で考えた障害を克服する方法を考え、具体的な対策→「もしXが起きたらYをやる」
-自分の願望や障害を可能なかぎり詳細にイメージしたうえで、図のような短い文章に落としこむのがポイント
-非常にシンプルですが、これだけで目標の達成率が２倍も変わってくる
-なぜ『心理対比』はそこまで効くのか？
-1.目標を達成したイメージを細かく思い描く
-2.脳がダイレクトにイメージを受け取る
-3.「あれ？目標を達成できるんじゃね？」と脳が思い込む
-※脳はイメージと現実の区別が苦手なので、具体的な創造については現実で達成できそうだと勝手に思う傾向がある
-※副作用
-1. ポジティブな想像に脳が満足する
-2. 脳が「もういいや」と思い出す
-3. やる気が失せる
-基本的に脳は短期的な感情や目先の欲望に反応する働きのほうが強い
-そこで、目標達成のプロセスで起こり得るトラブルを想定してあげると、
-1. 脳が短期的なトラブルを認識
-2. 「これらのトラブルを乗り越えればごほうびが手に入るんだな…」と脳が納得する
-3. やる気が出る！
-短期的な「トラブル」を設定することで、脳に目標へ向かうためのロードマップができあがるわけ
-```
-パケ構成
-demo
--controller
--repository
-    |
-    -entity----MemberData
-     Mapper
-     repository
--service
-Apllication
-@Mapper
-public interface MemberMapper {
-    @Select("SELECT * from members")
-    List<MemberData> findAll();
-    @Select("SELECT * FROM members where id = #{id}")
-    MemberData findById(@Param("id") Integer id);
-    @Insert("INSERT INTO members (name, age) VALUES (#{name}, #{age})")
-    void create(@Param("name") String name, @Param("age") Integer age);
-    @Update("UPDATE  members " +
-            "SET id=#{id}," +
-            "name =#{name}," +
-            "age =#{age} " +
-            "WHERE id =#{id}")
-    void update(@Param("id") Integer id, @Param("name") String name, @Param("age") Integer age);
-    @Delete("DELETE FROM members where id = #{id}")
-    void deleteById(@Param("id") Integer id);
-}
-/**
- * RESTful な URL
- * https://qiita.com/mserizawa/items/b833e407d89abd21ee72#restful-%E3%81%AA-url-%E3%81%AB%E3%81%97%E3%82%88%E3%81%86
- * 総コミット数：23  作成ブランチ：7
- * 合計行数（+追加行数 -削除行数）：799 (+727, -72)
- */
-@RestController
-@RequiredArgsConstructor
-@RequestMapping("/members")
-public class MemberController {
-    private final MemberService memberService;
-    @GetMapping
-    public List<MemberData> findAll() {
-        return memberService.findAll();
-    }
-    @GetMapping("/{id}")
-    public MemberData findById(@PathVariable int id){
-        return  memberService.findById(id);
-    }
-    @PostMapping
-    @ResponseBody
-    public void create(@RequestBody List<MemberData> memberData){
-        memberService.create(memberData);
-    }
-    @PutMapping("/{id}")
-    @ResponseBody
-    //Bug: id が存在しないと updateできない → id重複なしなら新規登録したい
-    public void update(@PathVariable int id, @RequestBody MemberData memberData){
-        memberService.update(id, memberData);
-    }
-    @DeleteMapping("/{id}")
-    //Bug：id で delete すると id が欠番になる
-    public void deleteById(@PathVariable int id){
-        memberService.deleteById(id);
-    }
-    //実装手順: branch作成, PullRequest作成, 空コミット, 実装orリファクタ, マージ
-    //実装感想： 1.O/Rマッパー(Mybatis, Prizma, etc…)は　DB操作には必須
-    //         3.【課題】フロント → エンドの疎通の理解が必要(Json形式のリクエスト作成方法, URL組立てBackEndに送信する方法)
-    //         4.【苦労予想】テスト設計,　異常系制御, 言語ごとのテストフレームワーク, エビデンス取得作業
-}
-```
-@Repository
-@RequiredArgsConstructor
-public class MemberRepository{
-    private final MemberMapper mapper;
-    public List<MemberData> findAll(){
-        return mapper.findAll();
-    }
-    public MemberData findById(int id){
-        return mapper.findById(id);
-    }
-    public void create(String name, int age){
-        mapper.create(name, age);
-    }
-    public void update(int id, String name, int age){
-        mapper.update(id,name, age);
-    }
-    public void deleteById(int id){
-        mapper.deleteById(id);
-    }
-}
-@Service
-@RequiredArgsConstructor
-public class MemberService {
-    private final MemberRepository memberRepository;
-    public List<MemberData> findAll(){
-        return memberRepository.findAll();
-    }
-    public MemberData findById(int id){
-        return memberRepository.findById(id);
-    }
-    public void create(List<MemberData> memberData){
-        for(MemberData data: memberData){
-            memberRepository.create(data.getName(), data.getAge());
-        }
-        System.out.println("登録完了");
-    }
-    public void update(int id, MemberData memberData){
-        memberRepository.update(id, memberData.getName(), memberData.getAge());
-        System.out.println("更新完了");
-    }
-    public void deleteById(int id){
-        memberRepository.deleteById(id);
-        System.out.println("削除完了");
-    }
-}
-```
-```

aaaaaaaaaaaaaaaaaaaaa

2021/12/23 07:04

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -208,25 +208,90 @@
 ```
+@Repository
+@RequiredArgsConstructor
+public class MemberRepository{
+    private final MemberMapper mapper;
+    public List<MemberData> findAll(){
+        return mapper.findAll();
+    }
+    public MemberData findById(int id){
+        return mapper.findById(id);
+    }
+    public void create(String name, int age){
+        mapper.create(name, age);
+    }
+    public void update(int id, String name, int age){
+        mapper.update(id,name, age);
+    }
+    public void deleteById(int id){
+        mapper.deleteById(id);
+    }
+}
+@Service
+@RequiredArgsConstructor
+public class MemberService {
+    private final MemberRepository memberRepository;
+    public List<MemberData> findAll(){
+        return memberRepository.findAll();
+    }
+    public MemberData findById(int id){
+        return memberRepository.findById(id);
+    }
+    public void create(List<MemberData> memberData){
+        for(MemberData data: memberData){
+            memberRepository.create(data.getName(), data.getAge());
+        }
+        System.out.println("登録完了");
+    }
+    public void update(int id, MemberData memberData){
+        memberRepository.update(id, memberData.getName(), memberData.getAge());
+        System.out.println("更新完了");
+    }
+    public void deleteById(int id){
+        memberRepository.deleteById(id);
+        System.out.println("削除完了");
+    }
+}
+```
 ```

aaaaaaaaaaaaaaaaaaaaa

2021/12/23 04:24

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,189 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+前提：ポジティブシンキングなんてムダだ！(メタ分析)
+→→心理対比さえ実践すればいい（1回につき15〜20分が目安）
+▼ステップ１：願望（Wish）　もっとも重要なもの１つに絞る
+"仕事やプライベートに関して、自分が抱く希望や不安を詳細にいくつか書き出す（または思い描く）。健康になる！
+見た目が良くなる！
+モテる！
+医療費が減る！
+自慢できる！
+ブログのネタになる！"
+このとき重要なのは、「達成は難しいけど、がんばれば何とかなりそうだ：な〜」ぐらいの難易度設定にしておく：「１年で億万長者」とか「ベストセラー作家に」なんて願望を抱くと、ポジティブシンキングの罠にハマっちゃいますんでご注意ください。また、達成したい願望がいくつもある場合は、自分にとって最も重要なものだけ
+▼ステップ２：成果（Outcome）
+"上で考えた願望や不安に関する「ベストの成果」を思い描きます。しばし頭のなかでメリットをイメージしてみて、一番ポジティブな気分になったものを選べばOK。このとき、選んだメリットについてどんな気分になっているかまでを細かく具体的にイメージすればするほど効果が高まるっぽい。　例：願望：毎日エクササイズをする
+成果：健康で最高の気分になる
+不安：借金を返す
+成果：完済！"
+▼ステップ３：障害（Obstacle）
+"いまの自分の目標を達成するために、どんなトラブルが起きるかを詳細にいくつか書き出す（または思い描く）。具体的な考え方としては、
+どんな考え方が目標の達成をさまたげているのか？
+どんな行動が目標の達成をさまたげているのか？
+どんな癖や習慣が目標の達成をさまたげているのか？
+どんな思い込みが目標の達成をさまたげているのか？
+どんな感情が目標の達成をさまたげているのか？
+みたいな感じ。というと、「金がない」や「親が反対してる」など、環境や外的な問題をあげる人も多そうですが、これはNGであります。そもそも、「願望（Wish）」のステップで「がんばれば何とかなりそうな〜」ってレベルの目標を選んでいるので、主な障害は自分の問題でしかありえないはずなんですね。"
+▼ステップ４：計画（Plan）
+上で考えた障害を克服する方法を考え、具体的な対策→「もしXが起きたらYをやる」
+自分の願望や障害を可能なかぎり詳細にイメージしたうえで、図のような短い文章に落としこむのがポイント
+非常にシンプルですが、これだけで目標の達成率が２倍も変わってくる
+なぜ『心理対比』はそこまで効くのか？
+1.目標を達成したイメージを細かく思い描く
+2.脳がダイレクトにイメージを受け取る
+3.「あれ？目標を達成できるんじゃね？」と脳が思い込む
+※脳はイメージと現実の区別が苦手なので、具体的な創造については現実で達成できそうだと勝手に思う傾向がある
+※副作用
+1. ポジティブな想像に脳が満足する
+2. 脳が「もういいや」と思い出す
+3. やる気が失せる
+基本的に脳は短期的な感情や目先の欲望に反応する働きのほうが強い
+そこで、目標達成のプロセスで起こり得るトラブルを想定してあげると、
+1. 脳が短期的なトラブルを認識
+2. 「これらのトラブルを乗り越えればごほうびが手に入るんだな…」と脳が納得する
+3. やる気が出る！
+短期的な「トラブル」を設定することで、脳に目標へ向かうためのロードマップができあがるわけ
+```
+パケ構成
+demo
+-controller
+-repository
+    |
+    -entity----MemberData
+     Mapper
+     repository
+-service
+Apllication
+@Mapper
+public interface MemberMapper {
+    @Select("SELECT * from members")
+    List<MemberData> findAll();
+    @Select("SELECT * FROM members where id = #{id}")
+    MemberData findById(@Param("id") Integer id);
+    @Insert("INSERT INTO members (name, age) VALUES (#{name}, #{age})")
+    void create(@Param("name") String name, @Param("age") Integer age);
+    @Update("UPDATE  members " +
+            "SET id=#{id}," +
+            "name =#{name}," +
+            "age =#{age} " +
+            "WHERE id =#{id}")
+    void update(@Param("id") Integer id, @Param("name") String name, @Param("age") Integer age);
+    @Delete("DELETE FROM members where id = #{id}")
+    void deleteById(@Param("id") Integer id);
+}
+/**
+ * RESTful な URL
+ * https://qiita.com/mserizawa/items/b833e407d89abd21ee72#restful-%E3%81%AA-url-%E3%81%AB%E3%81%97%E3%82%88%E3%81%86
+ * 総コミット数：23  作成ブランチ：7
+ * 合計行数（+追加行数 -削除行数）：799 (+727, -72)
+ */
+@RestController
+@RequiredArgsConstructor
+@RequestMapping("/members")
+public class MemberController {
+    private final MemberService memberService;
+    @GetMapping
+    public List<MemberData> findAll() {
+        return memberService.findAll();
+    }
+    @GetMapping("/{id}")
+    public MemberData findById(@PathVariable int id){
+        return  memberService.findById(id);
+    }
+    @PostMapping
+    @ResponseBody
+    public void create(@RequestBody List<MemberData> memberData){
+        memberService.create(memberData);
+    }
+    @PutMapping("/{id}")
+    @ResponseBody
+    //Bug: id が存在しないと updateできない → id重複なしなら新規登録したい
+    public void update(@PathVariable int id, @RequestBody MemberData memberData){
+        memberService.update(id, memberData);
+    }
+    @DeleteMapping("/{id}")
+    //Bug：id で delete すると id が欠番になる
+    public void deleteById(@PathVariable int id){
+        memberService.deleteById(id);
+    }
+    //実装手順: branch作成, PullRequest作成, 空コミット, 実装orリファクタ, マージ
+    //実装感想： 1.O/Rマッパー(Mybatis, Prizma, etc…)は　DB操作には必須
+    //         3.【課題】フロント → エンドの疎通の理解が必要(Json形式のリクエスト作成方法, URL組立てBackEndに送信する方法)
+    //         4.【苦労予想】テスト設計,　異常系制御, 言語ごとのテストフレームワーク, エビデンス取得作業
+}
+```
+```

ミスがありました

2021/12/23 04:22

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,95 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-```
-https://craftsman-software.com/posts/56
-分報じゃないけど、好きなときに好きなこと（仕事上でもプライベートでもの課題や感情）を書いていい場所
-書く義務もなければ読む義務もないので気軽にどぞ
-◆フロントエンドのすべて
-https://roadmap.sh/frontend
-https://zenn.dev/kkeeth/scraps/dd30ae9d48f092
-↑解説記事
-× 「こんなにやらなきゃいけないことあるんだ」
-○ 「ふーん、こんな広い世界なんだ」
-開発の心得
-テストがしにくい場合は、おそらく実装のクラス設計や関数の分け方がわるいです
-本来webサーバーは『構築するもの』
-以下はDLするだけでWebサーバを構築する必要がない
-XAMPP：Apache
-SpringBoot：Tomcat、Jetty、UnderTow
-```
-「XAMPP」の名称由来
-・「X」←クロスプラットフォーム対応(Windows、Linux、Mac)
-・「A」←Apache
-・「M」←MySQL/MariaDB
-・「P」←PHP
-・「P」←Perl
-```
-#CakePHP Laravel 違い  メリットデメリット
->前提：どちらもPHPのフレームワーク
-CakePHP：規約が基本で爆速の開発スピードが魅力だが、基本的にはシンプルに開発を進める
-Laravel    ：便利でとても賢いフレームワーク、比較的に最新の技術や流行に対して対応力が高い
-##CakePHP メリット　デメリット
-メリット
-＞初心者でも理解しやすい
-キャッシュ機能で表示の高速化が可能
-生成されたSQLのデバッグ機能やバリデーション機能付き
-活発なコミュニティがある(意見がもらいやすい)
-複数人で行う開発に向いている
-高速に一定のセキュリティが担保されたプロジェクトを、
-経験のない方でも比較的手軽に開発できるのが最大のメリット
-デメリット
->規約が厳しい=柔軟性に欠ける
-規約が厳しいということは、誰がプログラミングしても規約通りにコーディングされるため、一貫性が出てコードの可読性も向上します。
-要望が増えてくると、CakePHPだと対応に時間がかかってしまうことも。
-##Laravel メリット　デメリット
-メリット
->頻繁に行われるバージョンアップ（新機能追加されやすい）
-人気度の高さ故のコミュニティ
-比較的簡単に習得可能
-開発スピードもはやい
-デメリット
->複数人での開発をするには注意が必要
-CakePHPと比べると処理速度が遅め(気にしなくてOK)
-Laravelの柔軟性の高さ故の問題。
-人によっては同じ処理でも全然コーディングの仕方が変わることもあるため、大きめなプロジェクトの場合やコーディングに携わる人が複数人に渡る場合は、コーディング規約やルールを先に決めておくのがおきましょう。
-#現在のPHPフレームワークでは,圧倒的にLaravelが人気
-新規開発→Laravel
-少し前に開発→CakePHP
-```

aaaaaaaaaaaaaaaaaaaaa

2021/12/22 06:38

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,95 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+https://craftsman-software.com/posts/56
+分報じゃないけど、好きなときに好きなこと（仕事上でもプライベートでもの課題や感情）を書いていい場所
+書く義務もなければ読む義務もないので気軽にどぞ
+◆フロントエンドのすべて
+https://roadmap.sh/frontend
+https://zenn.dev/kkeeth/scraps/dd30ae9d48f092
+↑解説記事
+× 「こんなにやらなきゃいけないことあるんだ」
+○ 「ふーん、こんな広い世界なんだ」
+開発の心得
+テストがしにくい場合は、おそらく実装のクラス設計や関数の分け方がわるいです
+本来webサーバーは『構築するもの』
+以下はDLするだけでWebサーバを構築する必要がない
+XAMPP：Apache
+SpringBoot：Tomcat、Jetty、UnderTow
+```
+「XAMPP」の名称由来
+・「X」←クロスプラットフォーム対応(Windows、Linux、Mac)
+・「A」←Apache
+・「M」←MySQL/MariaDB
+・「P」←PHP
+・「P」←Perl
+```
+#CakePHP Laravel 違い  メリットデメリット
+>前提：どちらもPHPのフレームワーク
+CakePHP：規約が基本で爆速の開発スピードが魅力だが、基本的にはシンプルに開発を進める
+Laravel    ：便利でとても賢いフレームワーク、比較的に最新の技術や流行に対して対応力が高い
+##CakePHP メリット　デメリット
+メリット
+＞初心者でも理解しやすい
+キャッシュ機能で表示の高速化が可能
+生成されたSQLのデバッグ機能やバリデーション機能付き
+活発なコミュニティがある(意見がもらいやすい)
+複数人で行う開発に向いている
+高速に一定のセキュリティが担保されたプロジェクトを、
+経験のない方でも比較的手軽に開発できるのが最大のメリット
+デメリット
+>規約が厳しい=柔軟性に欠ける
+規約が厳しいということは、誰がプログラミングしても規約通りにコーディングされるため、一貫性が出てコードの可読性も向上します。
+要望が増えてくると、CakePHPだと対応に時間がかかってしまうことも。
+##Laravel メリット　デメリット
+メリット
+>頻繁に行われるバージョンアップ（新機能追加されやすい）
+人気度の高さ故のコミュニティ
+比較的簡単に習得可能
+開発スピードもはやい
+デメリット
+>複数人での開発をするには注意が必要
+CakePHPと比べると処理速度が遅め(気にしなくてOK)
+Laravelの柔軟性の高さ故の問題。
+人によっては同じ処理でも全然コーディングの仕方が変わることもあるため、大きめなプロジェクトの場合やコーディングに携わる人が複数人に渡る場合は、コーディング規約やルールを先に決めておくのがおきましょう。
+#現在のPHPフレームワークでは,圧倒的にLaravelが人気
+新規開発→Laravel
+少し前に開発→CakePHP
+```

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2021/12/22 04:26

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,16 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-```
-dependencies {
-	implementation 'org.springframework.boot:spring-boot-starter-web'
-	implementation group: 'org.mybatis.spring.boot', name: 'mybatis-spring-boot-starter', version: '2.1.4'
-	testImplementation 'org.springframework.boot:spring-boot-starter-test'
-	implementation 'org.springframework.boot:spring-boot-starter-actuator'
-	compileOnly 'org.projectlombok:lombok'
-	annotationProcessor 'org.projectlombok:lombok'
-	runtimeOnly 'mysql:mysql-connector-java'
-}
-```

aaaaaaaaaaaaaaaaaaaaa

2021/12/21 06:39

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,16 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+dependencies {
+	implementation 'org.springframework.boot:spring-boot-starter-web'
+	implementation group: 'org.mybatis.spring.boot', name: 'mybatis-spring-boot-starter', version: '2.1.4'
+	testImplementation 'org.springframework.boot:spring-boot-starter-test'
+	implementation 'org.springframework.boot:spring-boot-starter-actuator'
+	compileOnly 'org.projectlombok:lombok'
+	annotationProcessor 'org.projectlombok:lombok'
+	runtimeOnly 'mysql:mysql-connector-java'
+}
+```

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2021/12/21 04:52

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,106 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-```
-【備忘録】InteliJ便利ショートカット(Windows)
-個人的によく使用するものを抜粋????
-覚えてないものほど上に記載
->参考 Windows & Mac ver
-https://qiita.com/yoppe/items/f7cbeb825c071691d3f2
-Git機能もこちらから
-https://qiita.com/yoppe/items/fd03607d4d4f191d32dd
-■ ファイル横断テキスト検索(Find in Path)
-ショートカットキー(Windows)：Ctrl + Shift + F
-■ なんでも検索(Search Everywhere)
-ショートカットキー：Shift 2回連打
-■ 現在開いてるファイルのプロジェクト/パッケージへジャンプ(Select In)
-ショートカットキー(Windows)：Alt + F1
-■ 選択行を上下に移動(Move Line Up/Move Line Down)
-ショートカットキー(Windows)：Alt + Shift + ↑／↓
-■ マルチカーソル(Add Selection for Next Occurrence)
-ショートカットキー(Windows)：（特定文字列を選択してから）Alt + J
-※置換すると不要なとこまで変更してしまう
-■ プロジェクトツールウィンドウの表示/非表示(Structure)
-ショートカットキー(Windows)：Alt + 1
-■ 現在の行を複製(Duplicate Line or Selection)
-ショートカットキー(Windows)：Ctrl + D
-#不要なimport文削除 :
-ショートカットキー(Windows)：Ctrl + Alt + O
-# コピー履歴から貼り付け(Paste from History)
-※Windowsのみ
-ショートカットキー(Windows)：Windowsアイコン + V
-■ 宣言へジャンプ(Go to Declaration or Usages)
-ショートカットキー(Windows)：Ctrl + B
-                            or   Ctrl + クリック
-便利そう
-■ 継承関係をクラス図で表示(Show UML Popup)
-ショートカットキー(Windows)：Ctrl + Alt + U
-```
-```
-パスパラメータ、クエリパラメータ、リクエストボディ　違いとは？
-##パスパラメータ（Pathparameter）,クエリパラメータ(queryparameter)
-URIで送るものがパスパラメータとクエリパラメータです。
-```
-https://example.com/pathparameter/{pathparameter}?queryparameter1=hogehoge&queryparameter2=fugafuga
-```
-例を見て貰えばわかるのですが、
-URIでドメインの後、？の前に来るものがパスパラメータです。
-そして、?の後に来るのがクエリパラメータです。
-##リクエストボディ(requestBody)
-URIではなく、JSONで送るものです。
-```
-{
-  hoge_name: fugafuga,
-  description: hogefugahoge,
-}
-```
-```

aaaaaaaaaaaaaaaaaaaaa

2021/12/18 04:15

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -115,4 +115,35 @@
 便利そう
 ■ 継承関係をクラス図で表示(Show UML Popup)
 ショートカットキー(Windows)：Ctrl + Alt + U
+```
+```
+パスパラメータ、クエリパラメータ、リクエストボディ　違いとは？
+##パスパラメータ（Pathparameter）,クエリパラメータ(queryparameter)
+URIで送るものがパスパラメータとクエリパラメータです。
+```
+https://example.com/pathparameter/{pathparameter}?queryparameter1=hogehoge&queryparameter2=fugafuga
+```
+例を見て貰えばわかるのですが、
+URIでドメインの後、？の前に来るものがパスパラメータです。
+そして、?の後に来るのがクエリパラメータです。
+##リクエストボディ(requestBody)
+URIではなく、JSONで送るものです。
+```
+{
+  hoge_name: fugafuga,
+  description: hogefugahoge,
+}
+```
 ```

aaaaaaaaaaaaaaaaaaaaa

2021/12/17 04:45

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,75 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+【備忘録】InteliJ便利ショートカット(Windows)
+個人的によく使用するものを抜粋????
+覚えてないものほど上に記載
+>参考 Windows & Mac ver
+https://qiita.com/yoppe/items/f7cbeb825c071691d3f2
+Git機能もこちらから
+https://qiita.com/yoppe/items/fd03607d4d4f191d32dd
+■ ファイル横断テキスト検索(Find in Path)
+ショートカットキー(Windows)：Ctrl + Shift + F
+■ なんでも検索(Search Everywhere)
+ショートカットキー：Shift 2回連打
+■ 現在開いてるファイルのプロジェクト/パッケージへジャンプ(Select In)
+ショートカットキー(Windows)：Alt + F1
+■ 選択行を上下に移動(Move Line Up/Move Line Down)
+ショートカットキー(Windows)：Alt + Shift + ↑／↓
+■ マルチカーソル(Add Selection for Next Occurrence)
+ショートカットキー(Windows)：（特定文字列を選択してから）Alt + J
+※置換すると不要なとこまで変更してしまう
+■ プロジェクトツールウィンドウの表示/非表示(Structure)
+ショートカットキー(Windows)：Alt + 1
+■ 現在の行を複製(Duplicate Line or Selection)
+ショートカットキー(Windows)：Ctrl + D
+#不要なimport文削除 :
+ショートカットキー(Windows)：Ctrl + Alt + O
+# コピー履歴から貼り付け(Paste from History)
+※Windowsのみ
+ショートカットキー(Windows)：Windowsアイコン + V
+■ 宣言へジャンプ(Go to Declaration or Usages)
+ショートカットキー(Windows)：Ctrl + B
+                            or   Ctrl + クリック
+便利そう
+■ 継承関係をクラス図で表示(Show UML Popup)
+ショートカットキー(Windows)：Ctrl + Alt + U
+```

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2021/12/17 01:56

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,67 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-```
-調子がよかった理由
-１．明確な道を提示 & 相談　＆共感（その後も何するか明確だった）
-２．作業が思ったよりも難しくない（ここなら返信作業が大変だと思った）
-３．作業量が軽く（できたが多い）
-→対策
-1. 具体的な道筋（目標と努力両方に意識を切り替えながらモチベを保つ）　　※今までは目標だけが先行していた
-２．普段やっている作業が『それほど大変じゃない』というのを脳に刷り込む必要がある（脳トレーニング）
-３．仕事とプライベートonoffをつける(以前はonのまま
-※これらを一度に身につけないように
-　するといいと思う。
-■目標の達成率が２倍に高まる『WOOP』 (本は効かなかった)
-https://yuchrszk.blogspot.com/2014/11/woop-3.html
-■ぐずぐず克服シート（エクセル使用） 日常用 / 仕事用
-https://yuchrszk.blogspot.com/2014/08/blog-post_5.html
-いやな気分よ、さようなら　検討
-日常                     仕事
-スペース：
-朝配信：
-出勤(朝散歩)：
-帰宅：
-即シャワー：
-椅子上で
-文字打ち：
-ココナラ連絡：
-(細分化)
-担当者C
-N
-Nめ
-動画班
-動画編集カット（外注希望）：
-11時就寝
-麻雀
-ゲーム？配信　not　配信
-タイピング
-■１秒でやる気を出す心理テクニック→『背筋を伸ばして全身に力を入れつつ腕組みしながら拳を握る』
-https://yuchrszk.blogspot.com/2014/06/blog-post_6497.html
-20〜30秒キープ：闘争本能を刺激するポーズでアドレナリンの分泌が原因
-背筋を伸ばす：（トロント大学）意思力が高まったうえに、痛みにも強くなった（パートナーと別れたときや、仕事の失敗といったような精神的な苦痛も減らせる）
-腕を組む 　　:（2007年の論文）難問題にも粘り強く取組む&成績も非常にUP(モチベ０,気分が落ちてる時も効果あり)
-拳を握る　　：（2011年の研究）痛みに耐える力がUP＆スナック＜＜健康食品に意識が向くように
-全身に力を入れる：（2011年の研究）全身の筋肉に力を込めると、甘いモノの誘惑を避け、苦い薬でも飲むようになり、嫌なことでも率先して実行するように。長期的なメリットが非常に大きいテク」
-便利ショートカット：
-［Alt］＋［Tab］キーを押すと、開いているウィンドウのイメージが表示されます。 ［Alt］キーを押したまま、［Tab］キーを繰り返し押すと、順に選択できます
-```
-```

aaaaaaaaaaaaaaaaaaaaa

2021/12/16 14:50

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -48,4 +48,63 @@
+```
+調子がよかった理由
+１．明確な道を提示 & 相談　＆共感（その後も何するか明確だった）
+２．作業が思ったよりも難しくない（ここなら返信作業が大変だと思った）
+３．作業量が軽く（できたが多い）
+→対策
+1. 具体的な道筋（目標と努力両方に意識を切り替えながらモチベを保つ）　　※今までは目標だけが先行していた
+２．普段やっている作業が『それほど大変じゃない』というのを脳に刷り込む必要がある（脳トレーニング）
+３．仕事とプライベートonoffをつける(以前はonのまま
+※これらを一度に身につけないように
+　するといいと思う。
+■目標の達成率が２倍に高まる『WOOP』 (本は効かなかった)
+https://yuchrszk.blogspot.com/2014/11/woop-3.html
+■ぐずぐず克服シート（エクセル使用） 日常用 / 仕事用
+https://yuchrszk.blogspot.com/2014/08/blog-post_5.html
+いやな気分よ、さようなら　検討
+日常                     仕事
+スペース：
+朝配信：
+出勤(朝散歩)：
+帰宅：
+即シャワー：
+椅子上で
+文字打ち：
+ココナラ連絡：
+(細分化)
+担当者C
+N
+Nめ
+動画班
+動画編集カット（外注希望）：
+11時就寝
+麻雀
+ゲーム？配信　not　配信
+タイピング
+■１秒でやる気を出す心理テクニック→『背筋を伸ばして全身に力を入れつつ腕組みしながら拳を握る』
+https://yuchrszk.blogspot.com/2014/06/blog-post_6497.html
+20〜30秒キープ：闘争本能を刺激するポーズでアドレナリンの分泌が原因
+背筋を伸ばす：（トロント大学）意思力が高まったうえに、痛みにも強くなった（パートナーと別れたときや、仕事の失敗といったような精神的な苦痛も減らせる）
+腕を組む 　　:（2007年の論文）難問題にも粘り強く取組む&成績も非常にUP(モチベ０,気分が落ちてる時も効果あり)
+拳を握る　　：（2011年の研究）痛みに耐える力がUP＆スナック＜＜健康食品に意識が向くように
+全身に力を入れる：（2011年の研究）全身の筋肉に力を込めると、甘いモノの誘惑を避け、苦い薬でも飲むようになり、嫌なことでも率先して実行するように。長期的なメリットが非常に大きいテク」
+便利ショートカット：
+［Alt］＋［Tab］キーを押すと、開いているウィンドウのイメージが表示されます。 ［Alt］キーを押したまま、［Tab］キーを繰り返し押すと、順に選択できます
+```
 ```

ｄｄｄｄｄｄｄｄｄｄｄｄｄｄ

2021/12/16 01:22

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -48,86 +48,4 @@
-```
-【保存版】 ノート
-ミスに早期に気づき、対応を迅速に行えるかが、SNS上で批判の集中砲火を受けるか回避できるかに
-論調を適切に把握し、早期に対応を行うことができれば、SNS炎上から称賛に繋がり可能性
-・炎上に対して事実の確認を早期に行うこと
-・「何が批判の原因となっているのか」「批判されている内容は事実か」「誤解だとすれば、本当はどうだったのか」
-・ユーザーが何に対して批判を行っているのか理解できなければ、謝罪対応も適切には行えません。逆に「本質がわかっていない」という更なる批判につながる可能性もあります。
-・事実の確認と論調の把握ができ、判断材料が揃った段階で、謝罪の方法や今後の対応を検討する
-・どのように信頼を回復していくのか、
-・二度と同じ過ちを侵さないためにどのような対策を講じることができるのか
-３大NG
-まず1つめは「個人的な反論をしないこと」です。組織として取るべき炎上対策にブレが生じやすくなると同時に、感情に任せた反論となれば、火に油を注ぐことになります。注意したいのは、匿名の書き込みですら特定される恐れがあること。実際に、炎上している会社を擁護する反論を社員が匿名で掲示板に書き込んだところ、投稿の発信元が露呈して大炎上につながったケースもあります。
-2つめは「苦しい言い訳をしないこと」。以前、従業員がハンバーガーのバンズの上に寝転がっている写真をTwitterに投稿して炎上しました。その際、企業の公式サイトで「発注ミスで廃棄処分だった」と釈明しましたが、これに対してネット上では、「そんな大量な廃棄が出るわけがない」、「その場しのぎの言い訳だ」などとして、炎上が長引いてしまいました。たとえそれが事実であったとしても、まずは謝意を全面に出すことが求められます。
-3つめは、「鎮静後に気を抜かないこと」。コンビニ大手チェーンにおいて、店舗内のアイス冷凍庫に入った写真がネット上に公開され、炎上したことがあります。本社が公式に謝罪し、テレビ報道もされて一旦は沈静化しましたが、そのわずか1か月後に、別のアルバイトスタッフによる不適切なつぶやきから新たなネットリスクが発生。そのスタッフのFacebookから、学校や交友関係が明るみになり、未成年で飲酒・喫煙していることまで判明し、再炎上しました。炎上を招いた企業に対して、ネットユーザーは一定期間厳しく監視する傾向にあるため、鎮静後も気を抜いてはいけません。
-なお、事態が鎮静化した後もインターネット上に炎上の記録が残り、批判的な書き込みが目に付く状態が続くこともあります。その際、「外部の専門会社に委託して検索順位を下げること」は、炎上対策としておすすめできません。恣意的に押し下げたことが表面化すると、さらなる炎上を招くからです。ホームページや公式SNSアカウントなどで地道な投稿とプロモーションを続けてネット上のコンテンツを増やし、自然と炎上に関するページの検索順位が下がる「逆SEO対策」こそ、正しい炎上対策の一環といえます。
-① 重要な情報のやり取りをしない
-守秘義務や秘密保持契約など規則に基づき漏えいさせてはいけない事柄をSNSに投稿してはいけません。
-もし情報が漏えいした場合、担当者の解雇だけでなく、損害賠償に発展する可能性もあります。
-SNSでやりとりする情報は、基本的には「すべて公になってしまう」と考えましょう。
-② 事実かどうか不確かなものは発信しない
-ウラが取れない情報を発信しないのはもちろん、
-他者の利害にかかわっている場合はより一層注意が必要です。
-事実は思った以上に不確かなものであると認識しておきましょう。
-③ 他人のプライバシーや個人情報を発信しない
-この場合の個人情報とは、人物を照合できる可能性がある情報すべてを意味します。「だれかをどこかで見た」という情報も他人のプライバシーに触れる情報になるので避けるべきです。
-また、重要な情報を送る相手の確認も決して怠れません。たとえばDM（ダイレクトメール）など普段公開されないやりとりでの送信先のミスや、相手がなりすましアカウントである危険性も考えられるためです。
-④ センシティブな世間の関心事に むやみに干渉しない
-SNSをにぎわせる話題には触れないほうが懸命と言えます。
-投稿の内容が会社のマイナスになる可能性はないか重ねて吟味しましょう。
-企業の炎上が起きた時の 3つの心構え
-焦りからひとたび判断を間違えると、一般ユーザーからますます怒りや不満を買ってしまう場合さえあるのです。
-① なによりもまずは、落ち着く
-炎上のショックで取り乱してはいけません。慌てて行った運用の判断が「その場しのぎの取りつくろい」とユーザーから判断されてしまうと、あとで正しい対処や情報がわかったとしても、そのときには事態がより複雑化している場合があります。
-他の心構えにもつながりますが、まずは冷静になることが大切です。
-② 「すぐ削除」が必ずしも良いとはいえない
-万一アカウントで炎上が起きた場合、「問題の投稿を急いで削除しないと！」と思いがちです。
-たしかに早めの対応は重要ですが、ほかの対応なしに投稿削除だけを先んじて行うと、
-SNSユーザーは「隠ぺい・ごまかし」と捉えることがあります。
-そうなると、炎上が加速する恐れがあります。
-③ 謝罪も、全体の指針が決まってから
-炎上時はすべての対応に一貫性が求められます。
-というのも、対応や発言が二転三転してしまうと、
-「誠実でない・信憑性がない」とユーザーの猜疑心を掻き立ててしまうためです。
-担当者は不用意な謝罪を控え、炎上を事実をすばやく関係部署間で周知し、
-全体で対応を考えましょう。
-理想的な炎上対応フローの例
-ソーシャルメディアの活動を停止する
-炎上したアカウントは必要最低限な情報発信にとどめ、解決の目途が立つまで一旦停止させましょう。この場合の「停止」とはアカウントやコンテンツの「削除」ではなく、むやみな投稿をストップして様子を見ることをいいます。
-弁明や謝罪、今後の対応策や発表は方針が決まってから
-一貫した対応がユーザーの信頼につながります。
-弁明や謝罪といった今後の対応策は担当者が冷静に判断し、対応しましょう。
+```

aaaaaaaaaaaaaaaaaaaaa

2021/12/10 10:14

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,90 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+```
+【保存版】 ノート
+ミスに早期に気づき、対応を迅速に行えるかが、SNS上で批判の集中砲火を受けるか回避できるかに
+論調を適切に把握し、早期に対応を行うことができれば、SNS炎上から称賛に繋がり可能性
+・炎上に対して事実の確認を早期に行うこと
+・「何が批判の原因となっているのか」「批判されている内容は事実か」「誤解だとすれば、本当はどうだったのか」
+・ユーザーが何に対して批判を行っているのか理解できなければ、謝罪対応も適切には行えません。逆に「本質がわかっていない」という更なる批判につながる可能性もあります。
+・事実の確認と論調の把握ができ、判断材料が揃った段階で、謝罪の方法や今後の対応を検討する
+・どのように信頼を回復していくのか、
+・二度と同じ過ちを侵さないためにどのような対策を講じることができるのか
+３大NG
+まず1つめは「個人的な反論をしないこと」です。組織として取るべき炎上対策にブレが生じやすくなると同時に、感情に任せた反論となれば、火に油を注ぐことになります。注意したいのは、匿名の書き込みですら特定される恐れがあること。実際に、炎上している会社を擁護する反論を社員が匿名で掲示板に書き込んだところ、投稿の発信元が露呈して大炎上につながったケースもあります。
+2つめは「苦しい言い訳をしないこと」。以前、従業員がハンバーガーのバンズの上に寝転がっている写真をTwitterに投稿して炎上しました。その際、企業の公式サイトで「発注ミスで廃棄処分だった」と釈明しましたが、これに対してネット上では、「そんな大量な廃棄が出るわけがない」、「その場しのぎの言い訳だ」などとして、炎上が長引いてしまいました。たとえそれが事実であったとしても、まずは謝意を全面に出すことが求められます。
+3つめは、「鎮静後に気を抜かないこと」。コンビニ大手チェーンにおいて、店舗内のアイス冷凍庫に入った写真がネット上に公開され、炎上したことがあります。本社が公式に謝罪し、テレビ報道もされて一旦は沈静化しましたが、そのわずか1か月後に、別のアルバイトスタッフによる不適切なつぶやきから新たなネットリスクが発生。そのスタッフのFacebookから、学校や交友関係が明るみになり、未成年で飲酒・喫煙していることまで判明し、再炎上しました。炎上を招いた企業に対して、ネットユーザーは一定期間厳しく監視する傾向にあるため、鎮静後も気を抜いてはいけません。
+なお、事態が鎮静化した後もインターネット上に炎上の記録が残り、批判的な書き込みが目に付く状態が続くこともあります。その際、「外部の専門会社に委託して検索順位を下げること」は、炎上対策としておすすめできません。恣意的に押し下げたことが表面化すると、さらなる炎上を招くからです。ホームページや公式SNSアカウントなどで地道な投稿とプロモーションを続けてネット上のコンテンツを増やし、自然と炎上に関するページの検索順位が下がる「逆SEO対策」こそ、正しい炎上対策の一環といえます。
+① 重要な情報のやり取りをしない
+守秘義務や秘密保持契約など規則に基づき漏えいさせてはいけない事柄をSNSに投稿してはいけません。
+もし情報が漏えいした場合、担当者の解雇だけでなく、損害賠償に発展する可能性もあります。
+SNSでやりとりする情報は、基本的には「すべて公になってしまう」と考えましょう。
+② 事実かどうか不確かなものは発信しない
+ウラが取れない情報を発信しないのはもちろん、
+他者の利害にかかわっている場合はより一層注意が必要です。
+事実は思った以上に不確かなものであると認識しておきましょう。
+③ 他人のプライバシーや個人情報を発信しない
+この場合の個人情報とは、人物を照合できる可能性がある情報すべてを意味します。「だれかをどこかで見た」という情報も他人のプライバシーに触れる情報になるので避けるべきです。
+また、重要な情報を送る相手の確認も決して怠れません。たとえばDM（ダイレクトメール）など普段公開されないやりとりでの送信先のミスや、相手がなりすましアカウントである危険性も考えられるためです。
+④ センシティブな世間の関心事に むやみに干渉しない
+SNSをにぎわせる話題には触れないほうが懸命と言えます。
+投稿の内容が会社のマイナスになる可能性はないか重ねて吟味しましょう。
+企業の炎上が起きた時の 3つの心構え
+焦りからひとたび判断を間違えると、一般ユーザーからますます怒りや不満を買ってしまう場合さえあるのです。
+① なによりもまずは、落ち着く
+炎上のショックで取り乱してはいけません。慌てて行った運用の判断が「その場しのぎの取りつくろい」とユーザーから判断されてしまうと、あとで正しい対処や情報がわかったとしても、そのときには事態がより複雑化している場合があります。
+他の心構えにもつながりますが、まずは冷静になることが大切です。
+② 「すぐ削除」が必ずしも良いとはいえない
+万一アカウントで炎上が起きた場合、「問題の投稿を急いで削除しないと！」と思いがちです。
+たしかに早めの対応は重要ですが、ほかの対応なしに投稿削除だけを先んじて行うと、
+SNSユーザーは「隠ぺい・ごまかし」と捉えることがあります。
+そうなると、炎上が加速する恐れがあります。
+③ 謝罪も、全体の指針が決まってから
+炎上時はすべての対応に一貫性が求められます。
+というのも、対応や発言が二転三転してしまうと、
+「誠実でない・信憑性がない」とユーザーの猜疑心を掻き立ててしまうためです。
+担当者は不用意な謝罪を控え、炎上を事実をすばやく関係部署間で周知し、
+全体で対応を考えましょう。
+理想的な炎上対応フローの例
+ソーシャルメディアの活動を停止する
+炎上したアカウントは必要最低限な情報発信にとどめ、解決の目途が立つまで一旦停止させましょう。この場合の「停止」とはアカウントやコンテンツの「削除」ではなく、むやみな投稿をストップして様子を見ることをいいます。
+弁明や謝罪、今後の対応策や発表は方針が決まってから
+一貫した対応がユーザーの信頼につながります。
+弁明や謝罪といった今後の対応策は担当者が冷静に判断し、対応しましょう。

追記

2021/12/10 00:29

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,135 +44,4 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
-前提：Next.jsは、JavaScriptライブラリであるReact開発におけるフレームワーク
-作業手順(プロジェクトの作成手順）
-1.npx　コマンドが使えること
-2.フォルダ作成（vscordでファイルを開く)
-3.npx create-next-app --example with-typescript {プロジェクト名}
-4.起動確認　プロジェクト名の階層に移動して「npm run dev」
-5サイトの作成完了
-6.Next.jsでSSR、SSGの方法
-基本的にpagesディレクトリ配下に作成したページに以下の関数を追加するだけです。
-SSGしたい場合
-APIなどから取得したデータを元にページを動的に作成する場合・・・getStaticPaths + getStaticProps
-動的なページ作成は不要な場合・・・getStaticPropsのみ
-SSRしたい場合・・・getServerSideProps
-以下はSSGのAPIなどから取得したデータを元にページを動的に作成する場合のサンプルコードです。(残りは公式ドキュメントを参考にしてください。)
-```/pages/piyo/[id].tsx
-import React from 'react';
-import { GetStaticPaths, GetStaticProps } from 'next';
-// 型定義：一覧
-type Piyo = {
-  id: string;
-};
-// 型定義：詳細
-type PiyoDetail = {
-  id: string;
-  name: string;
-  value: string;
-};
-// 3. あとはgetStaticPathsとgetStaticPropsで作成されたpropsを使用して画面描画する処理を記述してあげればOK
-const piyoPage: React.FC<PiyoDetail> = ({ id, name, value }) => (
-  <div>
-    {`idは${id}、nameは${name}、valueは${value}です。`}
-  </div>
-);
-// 1. まずはここで動的に作成するページデータを取得
-export const getStaticPaths: GetStaticPaths = async () => {
-  // API叩いて一覧データを取得と仮定
-  const response: Piyo[] = await fetch('https://.../piyos');
-  // paramsの中のid:はファイル名の[id]の部分と合わせること
-  const paths = response.map((piyo: Piyo) => (
-    { params: { id: piyo.id } }
-  ));
-  // これでgetStaticPropsでparamsが使用可能に
-  // fallback=falseは存在しないページは404
-  return { paths, fallback: false };
-};
-// 2. ここでpiyoPageでpropsとして使用するデータを取得・作成します
-export const getStaticProps: GetStaticProps = async ({ params }) => {
-  // API叩いて詳細データを取得と仮定
-  const piyoDetail: PiyoDetail = await fetch(`https://.../piyos/${params.id}`);
-  // これでpiyoPageでpropsとして使用可能に
-  return { props: { piyoDetail } };
-};
-export default piyoPage;
-```
-これでawait fetch('https://.../piyos')で1〜3のidが取得できた場合、
-ビルド後に
-http://localhost:3000/piyo/1
-http://localhost:3000/piyo/2
-http://localhost:3000/piyo/3
-といった感じでアクセスできるようになります。
-7.vercelにデプロイ
-https://tomosta.jp/article/nextjs-basic/#ib-toc-anchor-25
-8.Chakra UIで遊んでみよう（✖ダークモード）
-https://zenn.dev/knjname/articles/20210105tryoutchakraui
-Next.jsにChakura導入
-https://fwywd.com/tech/next-chakra-ui
-##switch 式　最近の Java がすごい！
-switch 式は Java 14 より正式に追加されたようです。
-以下のように switch 式により値を返すことができるようになりました。
-```
-int numLetters = switch (day) {
-    case MONDAY, FRIDAY, SUNDAY -> 6;
-    case TUESDAY                -> 7;
-    case THURSDAY, SATURDAY     -> 8;
-    case WEDNESDAY              -> 9;
-};
-```
-また、以前の switch 文では以下のように case のブロックごとに break を書く必要がありましたが、アロー構文 -> により break を省略することができるようになりました。
-```
-switch (day) {
-    case MONDAY:
-    case TUESDAY:
-        int temp = ...
-        break;
-    case WEDNESDAY:
-    case THURSDAY:
-        int temp2 = ...
-        break;
-    default:
-        int temp3 = ...
-}
-```

aaaaaaaaaaaaaaaaaaaaa

2021/12/08 09:01

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -143,4 +143,36 @@
 https://zenn.dev/knjname/articles/20210105tryoutchakraui
 Next.jsにChakura導入
-https://fwywd.com/tech/next-chakra-ui
+https://fwywd.com/tech/next-chakra-ui
+##switch 式　最近の Java がすごい！
+switch 式は Java 14 より正式に追加されたようです。
+以下のように switch 式により値を返すことができるようになりました。
+```
+int numLetters = switch (day) {
+    case MONDAY, FRIDAY, SUNDAY -> 6;
+    case TUESDAY                -> 7;
+    case THURSDAY, SATURDAY     -> 8;
+    case WEDNESDAY              -> 9;
+};
+```
+また、以前の switch 文では以下のように case のブロックごとに break を書く必要がありましたが、アロー構文 -> により break を省略することができるようになりました。
+```
+switch (day) {
+    case MONDAY:
+    case TUESDAY:
+        int temp = ...
+        break;
+    case WEDNESDAY:
+    case THURSDAY:
+        int temp2 = ...
+        break;
+    default:
+        int temp3 = ...
+}
+```

aaaaaaaaaaaaaaaaaaaaa

2021/12/08 02:19

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

@@ -44,4 +44,103 @@
 理想は
 1234
 5678
-と二段に分かれること
+と二段に分かれること
+前提：Next.jsは、JavaScriptライブラリであるReact開発におけるフレームワーク
+作業手順(プロジェクトの作成手順）
+1.npx　コマンドが使えること
+2.フォルダ作成（vscordでファイルを開く)
+3.npx create-next-app --example with-typescript {プロジェクト名}
+4.起動確認　プロジェクト名の階層に移動して「npm run dev」
+5サイトの作成完了
+6.Next.jsでSSR、SSGの方法
+基本的にpagesディレクトリ配下に作成したページに以下の関数を追加するだけです。
+SSGしたい場合
+APIなどから取得したデータを元にページを動的に作成する場合・・・getStaticPaths + getStaticProps
+動的なページ作成は不要な場合・・・getStaticPropsのみ
+SSRしたい場合・・・getServerSideProps
+以下はSSGのAPIなどから取得したデータを元にページを動的に作成する場合のサンプルコードです。(残りは公式ドキュメントを参考にしてください。)
+```/pages/piyo/[id].tsx
+import React from 'react';
+import { GetStaticPaths, GetStaticProps } from 'next';
+// 型定義：一覧
+type Piyo = {
+  id: string;
+};
+// 型定義：詳細
+type PiyoDetail = {
+  id: string;
+  name: string;
+  value: string;
+};
+// 3. あとはgetStaticPathsとgetStaticPropsで作成されたpropsを使用して画面描画する処理を記述してあげればOK
+const piyoPage: React.FC<PiyoDetail> = ({ id, name, value }) => (
+  <div>
+    {`idは${id}、nameは${name}、valueは${value}です。`}
+  </div>
+);
+// 1. まずはここで動的に作成するページデータを取得
+export const getStaticPaths: GetStaticPaths = async () => {
+  // API叩いて一覧データを取得と仮定
+  const response: Piyo[] = await fetch('https://.../piyos');
+  // paramsの中のid:はファイル名の[id]の部分と合わせること
+  const paths = response.map((piyo: Piyo) => (
+    { params: { id: piyo.id } }
+  ));
+  // これでgetStaticPropsでparamsが使用可能に
+  // fallback=falseは存在しないページは404
+  return { paths, fallback: false };
+};
+// 2. ここでpiyoPageでpropsとして使用するデータを取得・作成します
+export const getStaticProps: GetStaticProps = async ({ params }) => {
+  // API叩いて詳細データを取得と仮定
+  const piyoDetail: PiyoDetail = await fetch(`https://.../piyos/${params.id}`);
+  // これでpiyoPageでpropsとして使用可能に
+  return { props: { piyoDetail } };
+};
+export default piyoPage;
+```
+これでawait fetch('https://.../piyos')で1〜3のidが取得できた場合、
+ビルド後に
+http://localhost:3000/piyo/1
+http://localhost:3000/piyo/2
+http://localhost:3000/piyo/3
+といった感じでアクセスできるようになります。
+7.vercelにデプロイ
+https://tomosta.jp/article/nextjs-basic/#ib-toc-anchor-25
+8.Chakra UIで遊んでみよう（✖ダークモード）
+https://zenn.dev/knjname/articles/20210105tryoutchakraui
+Next.jsにChakura導入
+https://fwywd.com/tech/next-chakra-ui

実現したいことを追加。

2021/12/08 01:57

投稿

tapipi

スコア13

title CHANGED Viewed

File without changes

body CHANGED Viewed

File without changes