パンうめぇ

園児ニアの日記帳

【TOEIC】1年半かけて475→700まで上げました

久しぶりの更新です．気付いたら社会人2年目になってしまいました，kanekouです．

大学院の頃，自分の英語力の無さに危機感を覚え，TOEICの勉強を始めました．約1年半で200点ちょい点数を上げ，社会人1年目で700点に到達することができました．最後の受験から少し時間が経ってしまったのですが，ここで振り返りたいなと思い，この記事を書いてます．

実際の点数の変位はこちらです．

TOIEC 点数推移

2021年5月頃から勉強を始め，2021年7月から基本的に月一ペースで試験を受けていました．じわじわと点数を伸ばし，700点まで辿り着きました．院生のうちに何とか600点まで辿り着き(2022/1/30)，そこから9ヶ月ぐらいで700点にたどり着いた感じです(2022/10/23)．その後はまた600点台を右往左往してたのですが，技術周りの勉強に時間をかけることにしたため，2023/3/5を最後に中断という形となっています．

なぜTOEICを受講しようと思ったか

エンジニア希望にも関わらず英語と数学への苦手意識があり，コンプレックスに感じていたためです．一定点数以上を取らなきゃいけない，というような外的要因はなかったので，当初は2年ぐらいかけてゆる〜く勉強していこうと思ってました．

筆者の英語力はこんな感じでした．

  • 受験生時代: センター試験90点ぐらい(200点満点中)
  • 大学生時代: TOEIC300点台
  • 院1年初期: 400後半(院進テストでTOEIC IPテスト受験)

リーディング，リスニング共にダメダメですが，特に文法への苦手意識がすごかったです．

学習指針

継続することを最優先としました．その中で，以下の指針を掲げました．

  1. モチベに頼らない
  2. 「やらないと気持ち悪い」に落とし込むことを目標とする
  3. 最低ラインを決める

1.については，自身が飽き性なので，やる気に頼ると間違いなく続かないことが目に見えていたためです．また，そもそもやる気のある日があれば，やる気のない日もあり，これはコントロール不可だと考えています．継続するためには，モチベに頼らない設計を行う必要があると考えました． とはいえやる気はあるに越したことはないと思うので，英語の発音がかっこいい曲だったり，英語系YouTuberの動画を見たりして，できるだけモチベを上げるようにはしていました．

2.は1.の対応策として考えました．歯磨きのように，やらないと寝る前に「なんか気持ち悪いな，，，」と思う状態を作り出すことで，モチベを上げるよりも継続力を高められると思いました(歯磨きにやる気は必要ないと思う🪥)．

3.は2.を実現するために実践した具体的な方法です．最低30分学べばその日はOK!とすることで，達成ハードルを下げます．そうすると容易に成功体験を得られるため，習慣化につながると考えました． 習慣化の天敵は「完璧主義」だと考えています．100%を求めると，それが崩れた時にやる気を失うリスクがあるので，30%ぐらいの低い目標を設定することとしました．

1日の学習内容

学生時代は多い時で2h程,朝に勉強していました． 社会人になってからは平均1.5h勉強していました．社会人は時間を取るのが厳しくなったので，出社の日は電車の時間も活用し，行き帰り計1hの間も英語の時間に当てました(帰宅して残り30min学習する感じ)．個人的には，家より電車の時間の方が集中できました．電車時間はabceedというアプリを使って学習してたのですが，スマホ片手間で学習できるのでかなりおすすめです(TOEIC900点の後輩もabceedをやり込んでいました)．

www.abceed.com

社会人の1.5hの内訳ですが，700点いったあたり(2023/10/23)から中断するまで(2023/03/05)は以下の学習を30minずつ行なっていました．

  • 単語
  • 文法(1日交互)
  • 長文読解(1日交互)
  • リスニング(公式問題集を解いたのち，シャドーイング)

文法と長文読解は交互に行なっていました．

色々やり方を変えて取り組んではいたのですが，以上のプログラムが一番無理なく続いたかな〜と思います．本当に仕事で疲れている時はシャドーイングのみ行うか，何もせずアニメ見て寝てました( ˘ω˘ )

単語と文法はabceed 主体で勉強しました．サクサク進むので空いた時間に片手間でできます．単語はabcced内でわからない単語があると直ぐに単語帳に登録できるため便利です．

長文読解は，中断する辺り(2023/03/05)はabceedで学習していたのですが，700点に到達した時(2023/10/23)は公式問題集を解きまくっていました．

学んでて楽しかったこと

2022/9/11あたりからリスニングの点数が急に伸びたのが嬉しかったです．公式問題集を解いたからなのか，シャドーイングが効いたからなのかはわかりませんが，リスニングってある時に劇的に伸びるんですよね．．．あと，国際学会の研究発表で何を言っているのか聞き取れたり，好きな海外バンドのMCで言っていることがわかってきたりして，テンションが上がりました🤘

TOEICの点数推移を見るのも楽しいです．TOEICは専用サイトで今までの点数が見れるので，数字で成長を感じてました．

苦しかったこと

  • 文法の壁
  • 長文読解のスピード

です．文法を疎かにしても500点台は行くのですが，安定して600点台を取るには本番7割ぐらい取れないと厳しかったです．おそらく長文読解のスピードと正確性にも文法知識が繋がってくると思います(感覚で解けるのはネイティブだけだと思う)．基礎固めとして文法を徹底的に勉強するのが重要だと実感しました．

長文読解は未だ課題で，伸び悩んでいるところです．本番で最後の10問を残して終えることが多く，まだまだ改善の余地があるなーと思います．解けなかった問題が多い回は点数も低く，スピードと正確性は比例していると感じました．

おすすめ教材

公式問題集がコスパ最強だと思います．

700点に到達した時，part7は公式問題集を解きまくっていた記憶があります(リスニングも基本公式問題集)．アプリで出される問題よりも問題難易度は低いのですが，本番と傾向がかなり似通っている印象です．

公式問題集はコスパ最高なのですが，家でどっしり構えないと勉強できないのが難点です．語学学習で最重要なのは継続だと思います．続ける上では，隙間時間にさっと勉強できる環境づくりを作り，学習ハードルを下げることが重要と考えます．そこで文法や単語の勉強は，スマホの学習アプリを利用するのをおすすめします．個人的には，以下の理由でabceedをお勧めします．

  • AIが自身に合った問題をレコメンドしてくれる
  • アプリ内で様々な教材を購入して利用できるので，かさばらない
  • PC, スマホ, タブレット間での連携←めちゃくちゃ良い

TOEICやっててよかったこと

英語サイトやエラーメッセージの目grep力の向上

英語を瞬間的に理解する力が上がったと思います．調べ物をする上で，さっと英語を読んで気になったものを翻訳アプリに掛け詳細を読む，という動きができるようになり，良い情報に早く辿り着けるようになったかなと感じてます．また，英語サイトを避けて調べるということも減り(無くなってはいない)，公式リファレンスやGithub issue等の信頼性の高い情報源から情報を取得できるようになってきたと思います．

関数名，変数名の命名意識

関数名や変数名を命名する際に，文法と単語そのものの意味をちゃんと考えるようになりました．

文法の知識は命名時にかなり役立つ印象です．

習慣化のメソッドを得た

何かを続ける上で意識すべきことを学び，血肉にできたと思います．

英語だけでなく，様々な学びに応用できそうです．(ブログ書くのも習慣化したいが．．．)

自己肯定感が高まった

年単位の習慣化の成功体験を得たので，自己肯定感が高まりました．何かしら取り組んだことがうまくいかない場合でも，容易にめげなくなったと思います．

全体所感

英語に関するコンプレックス自体は払拭できたのかなと思います．(とりあえず読み聞きは，平均よりもできるようになったのかなと思います)

外敵要因がないものに対し，計画を立て年単位で継続するという経験があまりなかったので，結果を出せたのは大きな自信になりました．実際，自身の力不足を感じて落ち込んでいる時など，TOEICの経験を思い出すと元気をもらえます．

この1年半の間，色んな出来事がありましたが（国際学会登壇，就職，騒音問題からの引っ越し，不眠等)，「頑張り過ぎない」ことを意識したおかげで，なんだかんだ続けられたのかなと思います．

最終目標の800点には到達していないですし，英語を喋れるようにもなりたいので，またいつか学習を再開しようとは思います．しかし今は，それよりも早く一人前のエンジニアになりたいので，当分は技術の勉強をしていきます．あとアルゴリズムの勉強も再開したいです．数字に強いエンジニアになりたい．

scrapbox.io

2021年読んだ(読んでいる)技術書紹介

本記事は琉大アドベントカレンダー 17日目の記事となります．

16日目のたゆさんのお酒美味しそうでしたね． 普段ハイボールしか飲まないので挑戦してみたい...

さて今回は，2021年読んだ(読んでいる)本について，技術書中心に紹介します．

Webを支える技術

Webアプリ全体としての基礎知識を得ることができる本です．

RESTful APIや，ステートレスといったよく聞く言葉を理解せずなんとなくWebアプリを作ってたので，きちんと理解したいと思い読み始めました．

Webの歴史からAPI設計のコツなど幅広いトピックを扱っており，浅く広くWebの全体像を見渡せると思います．

もしWeb系で働くのなら，目を通すことをお勧めします．

https://images-na.ssl-images-amazon.com/images/I/51OSBZvAxGL._SX351_BO1,204,203,200_.jpg

www.amazon.co.jp

オブジェクト指向でなぜつくるのか

「継承とかポリモーフィズムとかあるけど，結局なんでオブジェクト指向なん？ 」と言う疑問に対し丁寧に解説してくれる本です．よくオブジェクト指向プログラミング(OOP)は現実のモノに例えられますが，作者はそれに否定的で開幕から面白いです．

大学の授業でOOPについては学びますが，当時ちゃんと説明できるか？と言われると全く自信がない状態でした．この本がわかりやすかった点は，OOP以前のプログラミング言語と比較しているところです．OOPが登場する前の構造化プログラミング利点と問題点を解説し，どのようにオブジェクト指向が生まれたのかについて述べています．この一連の流れで「なぜOOPなのか」がスッと入ってきました．またメモリの仕組み等，内部的な動きについても述べられており楽しめます．

そういえばつい前に継承が議論になってた気がしますが，個人的には可読性を下げるので微妙だと思います．

後半は関数型言語について解説されており，超分かりやすいです．読む前は「ウッ，関数型...」とアレルギー反応を引き起こしてましたが，初めて全体像を理解できました． PythonやRubyでも関数型を意識するとコードが綺麗になるので，学ぶ利点は大きいのではないかと思います．ガッツリ時間とって勉強したいです．

https://images-na.ssl-images-amazon.com/images/I/51s3936d+kL._SX364_BO1,204,203,200_.jpg

オブジェクト指向でなぜつくるのか 第2版 | 平澤 章 |本 | 通販 | Amazon

JavaScriptPrimer

JavaScriptについて，全く知らない初心者向けに超丁寧に解説してくれます．書籍版もありますが，インターネッツで無料公開されています．

https://jsprimer.net

JavaScriptは進化が激しく，少し前のサイトだと全く役に立たないことがよくありますが，本サイトはECMAScript 2015以降をベースに定期更新されているので安心して学べると思います．

暗黙の型変換の項は，JSの恐ろしさを特に感じました．かなりあやふやな言語だと知り，型の重要性とTypeScriptが支持されている理由がなんとなくですが分かった気がします．

非同期処理はやはり難しいですが，最初Async Functionとawaitを使わずPromiseで書くことから始めるので，中で何が起こっているのでイメージしやすかったです．

カオスでどこから手をつけていいのかわからないJSを学ぶ上で，最初にお勧めします．

https://images-na.ssl-images-amazon.com/images/I/51P+rWQKYdL._SX387_BO1,204,203,200_.jpg

www.amazon.co.jp

りあクト！TypeScript で始めるつらくない React 開発 第 3.1 版【Ⅰ. 言語・環境編】

React学びたいな〜と思ったときにおすすめされた本です．言語・環境編ではReactに深くは踏み込まず，React周辺の言語知識，例えば型や関数型言語，JSのエコシステムについての知見を得ることができます．

普段動的型付け言語で開発しているので，ジェネリクスや型ガードといった型を用いたテクニックについて学ぶことができたのは一番の収穫でした．これらの知識はReact, TypeScriptだけでなく，他言語にも応用が効くと考えています．

またJSの歴史，エコシステムも興味深い内容でした．JSは進化が早いので古い情報が溢れており，歴史的背景を学ぶことでググり方を知ることに繋がると思います．

上司と新人エンジニアの会話型形式で進んでいくのですが，主人公である新人エンジニアの質問が恐ろしく鋭いです．しばらく触っていると疑問に感じるだろう事を質問してくれるので，理解が深まります．

まだⅡ以降は読めていないので，React少し触ったのち，本格的な実践内容に踏み込もうと考えています．

https://booth.pximg.net/c/620x620/a6bb6149-3c80-4a32-af82-d43ef5505047/i/2368045/2ab8cb19-fd7a-4c3c-8bc8-f8b201393bfc_base_resized.jpg

booth.pm

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂3版

AWSを用いてインフラについて実践的に学ぶことができます． 始めはAWS入門書として読み始めましたが，AWSの勉強というよりは，あくまでインフラ習得の実行環境として利用する感じでした．どちらかというとネットワークについて手を動かしながら学べる価値が大きいです．

インフラ周りは基本情報や授業で知識だけ入れてましたが，いまいち理解できてるか怪しかったので，実践的かつ体型的に学べたことに満足しています．ネットワーク構築を低コストで体験できるのはクラウドの良さですね．従来は物理サーバー等を準備するのにコストがかかると思うので，コスパ🙆‍♂️です．

サクサク進んだので，ネットワークの全体像やAWSのイメージを掴みたい人におすすめです．本のまま進めても上手くいかないこともありますが，ちゃんと調べれば解決しますし，そこで理解が深まると思います．

注意点として，演習が終わった後はちゃんとインスタンスやNATの設定周りを削除しないと学生には痛い額を請求されます．筆者は翌月数千円取られました．

https://images-na.ssl-images-amazon.com/images/I/71fV1UCcOwL.jpg

www.amazon.co.jp

ピープルウェア(Doing)

まだ半分(第II部)までしか読んでいませんが，紹介します．技術書というより，マネジメントの名著です．エンジニアリングマネージャー向けですが，エンジニアだけでなくIT会社で働く全員が読んだ方がいいんじゃないかと思います．

まだ学生ですが，エンジニアとして感じていることが明文化されており，かなり共感できます． 初版が30年前，というのが信じられないほど今に通用する内容だと思います． ソフトウェア開発も結局は人の問題に行き着くことを強く感じさせられます．

読んだ中で印象に残ったこととして

  • ソフトウェア開発の失敗の多くは，技術的というより，社会学的なもの．

  • プロジェクトメンバーを結束させる能力ある人は，普通に仕事をする人の二人分の価値がある。

  • 手を動かしてない時間，仕事以外の時間の重要性．超人的な力が必要な仕事ほど，チームメンバーの交流が必要不可欠となる．メンバー全員で夕飯を共にすることは絶対に必要．

  • 早くヤレとせかされれば、雑な仕事をするだけで、質の高い仕事はしない。

  • 生活を犠牲に残業をさせるとワーカホリックに落ちいる．仕事より大切なもの(家族や若さ)を犠牲にしていると気づいた時，その人はいなくなる．そこまでして優秀な人を辞めさせて，本当の意味の生産性とはなにか．

  • オフィス投資の重要性．オフィス環境の良し悪しがプログラマーの生産性に大きく影響する．エンジニアが集中しやすい環境の作り方．開放型オフィスの問題点など．

などが挙げられます．オフィス環境については，自宅最強だと思いました．エンジニアが出社したがらない理由がわかる．

→ 追記(2021/12/19): 第Ⅳ部では，チームメンバーを物理的に引き離すことの弊害が述べられています．雑談が減ることで起こる結束力の低下は，大きな弊害だと思います．そこら辺リモートでどう担保するかは難しい問題ですね．

現時点で感動しているので，社会人が読んだらヤバそう．

https://images-na.ssl-images-amazon.com/images/I/51CFepapBZL._SX337_BO1,204,203,200_.jpg

www.amazon.co.jp

理科系の作文技術

技術書ではないですが，論文を書くことになる(書いている)皆さんにお勧めの本です．理科系のレポート，論文の書き方を記した本となります．

理科系の文章は文学とは異なり，わかりやすさが最優先されます．すっきりと筋の通った文章を書くための文章構造や，記述順番について述べられています．

個人的には，

  • 日本語は曖昧なので，できるだけ言い切ることで説得力を持たせる．
  • 修飾語を生やしすぎるとわかりずらくなるので，一文は簡潔に書くことを意識する．
  • 受動態はわかりずらいので，できるだけ避ける．

がすぐ使えて，実用性が高いと思いました．

またスキルの話ではないですが，以下の言葉は心強く感じました．

自分自身が直接にことに当たりものに当たって得た情報――なまの情報――，またそれについての自分自身の考えに重点をおくべきである．これらは，たとえ不備であり未熟・浅薄であったとしても，オリジナリティーという無比の強味をもっている

主張そのものに価値があるので，人前に出してみるスタンスを大事にしよう...

https://images-na.ssl-images-amazon.com/images/I/31818M220JL._SX298_BO1,204,203,200_.jpg

www.amazon.co.jp

まとめ

JSはカオスで面白いな〜と感じました．特にエコシステム．タイムライン見てるとJSの技術でよく盛り上がってるので，話に追いつけるようなりたい所存です． また，普段動的型付け言語を書いてて考えなかったことを多く学べました．やはり型は面白いと感じるので，TypeScriptと相性のいいReactを重点的に学び，開発を通して血肉にしたいです．

今年は一ヶ月に一冊読むという目標を掲げていました(技術以外の知識本含め)．月によって達成できないこともありましたが，計12冊読了しており，年単位ではギリギリ達成できてよかったです． 登校時に20分読書が結構よかった．

全体として初学者向けの書を漁っていましたが，しばらく続けようと思います． 個人的に興味がある関数型言語や，仕事でも使いそうなGolang，JS，リファクタリングやテストについて読む予定です． おすすめあれば教えてください!

明日はIsseiさんです．お楽しみに！

scrapbox.io

読書メモの取り方

今年は読書を心がけています．インターンで実力不足を実感し，知識を得るに読書が効率良いんじゃないかと思ったからです．読む本は技術書だけでなく，その時気になったトピック(心理，自己啓発，お金)もあります．

読書をする上で，効率よく知識を得たいと考えています．そのためにメモの取り方を意識しています．メモをとり，自分なりにまとめて後で振り替えられるようなやり方を模索中です．この記事では，いい感じにメモを残せる読書ツールはないかと模索した現時点での見解をまとめます．主に技術書向けですが，それ以外の「読み物」についても述べています．

試した(している)のは以下4つです．

  • mindmap
  • scrapbox
  • Zenn Scraps
  • audiobook.jp

結論

  • 基本scrapboxでメモを取ってアウトプットする
  • コード関連の作業logがとりたくなったらZenn Scrapsを使う
  • 隙間時間にオーディオブックを聴く，メモは細かく付けようとしない
  • メモは凝りすぎない．割とテキトーでいい．

mindmap

まず試してみたのがmindmap です．章ごとに分けてメモを取りました．その際関連するワードから派生する情報を生やしていきます．

メモはツイッターで呟きながらメモして，終わったらブログに残すという感じです．

kanekou.hatenablog.com

アウトプットして反応をもらうことがモチベとしてあることに気づいたので，外に出すことを意識するようになりました．

こちらのサイトを参考にしました

studyhacker.net

利点

  • 視認性が高く，関係が一目瞭然
  • 振り返った時わかりやすい
  • 新しい関係が見つかりやすい

欠点

  • 読みながら書くのが割と大変
  • 技術書以外だと辛い．PCが手元にない時とか．

良い点としてはパッとみた時のわかりやすさが挙げられます．関係性がビジュアライズされているので振り返りやすいです．また新たな関係を見つけやすく，結びつける(線を引く)楽しさもあると思います．

悪いところとして，読みながらメモを取るのが大変でした．読書中にメモしたい単語を見つけ，関連する枝を探してつなげるのが割と疲れますし，ペースが乱れます．また「綺麗にメモを残したい」という心理状態に陥ってしまい，見やすさに注力した結果，気負いすぎて読むのが苦痛になってしまいました．

またPCが手元にない場合，メモを取るのが紙またはアプリUIだと難しいことも挙げられます．

読んでる時はマーカーだけ引いて，章を読み終わりにメモを取ればもう少し気楽でよかったかもしれないですが，それでも手間かなあと感じます．

scrapbox

mindmapをやめて次に試してみたのがscrapboxです．scrapboxはファイル階層の概念がないのが特徴で，ドキュメントがフラットに並んでおり，タグとリンクを通して情報を結びつけます．これがかなり画期的だと思います．なぜなら雑にメモを取っておいて，後から関連する物事をまとめるのが容易だからです．めんどくさがりにぴったりです．

ここで読書ログを管理してます．

scrapbox.io

利点

  • メモの容易性
  • 関連する物事を合成できる
  • カスタマイズ性
  • 自動保存

欠点

  • 選択操作でのスクロールが微妙
  • コード貼ると少し重い
  • マークダウンに変換したい時

良いところとして，メモを取るのが容易です．階層という概念がないので，気楽にメモを取ることができます．データを整理しながらメモを取るのではなく，殴り書きで書いておき，その後に整理するのがおすすめです．

また整理する上でおすすめなのがリンク化です．メモする単語を[]で囲いリンク化しておくことで，他のドキュメントで同単語が現れた際に結合することができます．これにより，関連する情報を集約できます．scrapboxのすごいところは，この作業が低コストで行えるところです．雑に殴り書きして，後から整理する楽しさがあります．DBを正規化してるみたいで面白いです．

またUserScriptを用いて様々な機能を追加することができます．jsで書けるので，エンジニア的にも面白みのある機能だと思います．私はインデントの深さによってitemizeの種類を変え，見やすくしています．

自動保存も便利で，保存忘れで吹っ飛んだあああああってことがないです．一文字ずつ保存されているので，戻るボタンで前ページ行っても大丈夫です．

欠点として，選択操作でのスクロールの動きが微妙だと感じました．巨大メモをクリップボードにcopyする際，選択操作で上下スクロールが滑らかにいかないのが若干ストレスです．一方，コードはコードブロックにcopyボタンがあるので容易にコピーできます． 加えて，そこそこ巨大なコードを貼ると動きが重く感じます．以上の理由でコードをベタベタ残すのには向いてないと感じました．

マークダウンで扱いたい時に不便かもしれません．scrapboxは独自記法です．思想の違いにより，わざわざmarkdownにする必要はないと考えます．扱いやすく，考えられた記法だと思います．しかしマークダウンに変換して扱いたい場合が多々あり，export機能が欲しいところです．

scrapbox.io

メモの流れ

  1. private projectのlog置き場に雑メモ，あるいはコピペ
  2. 芝刈り
  3. 考えや感想をまとめて，public projectに書く

ということを今やってます．試行錯誤してるので，本ごとにばらつきがあります．

コピペをそのままpublicにするのは著作権的にアレなので，いつでも見直せる場としてprivate空間にいいなと思ったものを雑メモし見直せるようにしています．その後芝刈りを行い，情報整理します．

最後に考えや感想をまとめたものをpublicに置くことでアウトプットを行い，モチベを上げています．

Zenn Scraps

zenn.dev

スクラップは、スレッド形式で知見やメモをまとめていく機能です。最初にテーマを決めてスクラップを作成したら、あとは自分の好きな単位で、好きなときに情報を足していきます。

技術書で作業logを取る際に利用しています．scrapboxのコードの扱いが微妙だったので，logを残すのにいいツールがないか探していた時に見つけました．もともとgithub issuesに作業logを残す習慣があり， issuesライクだったので使いやすいかも?と思ったのがきっかけです．少ししか試していないので何かあれば追記します．

今スクラップしてるのはこちらです．

zenn.dev

利点

  • 気楽にlogを残せる
  • リアルタイム性
  • コードが扱いやすい
  • 後から見た時に流れが把握しやすい
  • 達成感を得られる
  • マークダウン
  • 問題単位で公開設定できる

欠点

  • 個人的には今のところなし
  • 強いていうなら限定公開ができない．

github issuesに慣れていると，使いやすいです．使い方としては，専門書を読んでいるときに発生したイレギュラーに対して 作業logを残していく感じです．

利点は今のとこgithub issuesと変わらないです．マークダウン形式でコードが扱いやすく，つぶやき形式で気軽にlogが残せます．またスレッド形式なので後から見た時に流れが掴みやすいです．誰が見てもわかるような記述を意識する必要がありますが，それほどコストもかからず重荷とは感じません．

また見直した後に得られる「やっている感」がモチベに繋がります． イレギュラーな問題が解決したら，closeして記事にすればいいですね．

欠点はまだ見つけてないのですが，強いていうなら限定公開ができないです．公開設定はpublicかarchiveの2つのみです．私は今のところ困っていませんが，組織内で知見を貯めたい場合には向かなさそうですね*1． とはいえ，問題単位で公開設定ができるのは利点だと思います．

んーでもgithub issuesでよくね？

現時点で差別化できるところは

  1. プロジェクトがなくても，メモが取れる
  2. 問題単位での公開設定

と考えてます．プロジェクト単位ではなく，問題単位で気楽に扱うことのできるのが強みだと思います．

参考

zenn.dev

zenn.dev

audiobook.jp

オーディオブックとは，本を音声で読み聞かせてくれるサービスです．より効率よく知識を得たいと思い，最近始めました．こちらです．

audiobook.jp

まだ一冊しか読んでいないのでアレですが，見解を述べます．

まず技術書向きではありません．図や表といった専門的な本ではなく，抽象的な事柄を述べている本が向いてます．ビジネス書や自己啓発，コミュニケーション書などです．

利点

  • 作業しながら効率よく知識が得られる

欠点

  • 拾い読みができない
  • 向いている本，そうでない本がある
  • メモとりずらい？

利点として，隙間時間に効率よく知識を得ることができます．移動中または作業中に聞けるので，学校からの帰り道や家事といった，耳が空いている時に利用しています．速度も上げれるので効率を上げることもできます．意外と耳は空いているもので，気づいたら読み終わっていました．

欠点として，要点を拾い読みすることが難しいです．一般的な読書は流し読みして必要部分だけ注力することが可能ですが，オーディオブックは最初から最後まで聞く必要があります．それでも隙間時間に聞けるため，効率はいいと思います．

向いている本，そうでない本があることは上で述べた通りです．読む前に判断する必要があります．

メモは取りづらいかも?と感じました．私は細かくメモを取るのが好きで，kindleや実物の本ではブックマークかマーカーを付けまくり，読了後にメモを取っています．アプリにブックマークボタンがあるのですが，作業中に聞くので，「ここだ！」という時にボタンを押しずらいです(ポケットから取り出すのめんどくさい)．これに関しては，ブクマの間隔が細かすぎるのかもしれません．1トラック1ブクマの方が気楽で続くのかも．

メモはテキトーでいい

メモを取るのに凝り始めると次第に苦痛となり，やめてしまうことがわかりました．「学べるところ全部取り込もう」と気負いすぎると続かなくなります．

楽しむことが大事だと感じました．テキトーさを保ちつつ，達成感を感じながらメモを取るのがコツだと思います．その点scrapboxがバランス良く，おすすめです．

これからも試行錯誤していきます． 他におすすめの読書法やメモの取り方があれば教えてください．よろしくお願いします🙇🏻

*1:ローカルで開発サーバーを立てて公開する方法があるっぽい Zennの記事を限定公開する方法

Catalina→Big Surへの移行時にmacをクリーンインストールする

どうも．先日原付でコケて右鎖骨を負傷したkanekouです．

新学期というわけで，いい加減OSをCatalinaからBig Surに上げようと思い立ち，クリーンインストールを行いました．備忘録として残します．

なぜクリーンインストールするのか

macを健康に保つにためは定期的なクリーンインストールがおすすめです．特にOSアップデート時にそのままアップデートすると何らかの不具合が生じ，動作が不安定になる可能性が高いです．よってクリーンインストールしてから乗り換えた方が得策だと思います．また長らくmacを使っているとシステムファイルに正体不明のゴミが溜まります．私のMacだとクリーンインストール前のゴミの量はこのくらいありました．

f:id:kanekou:20210422205030p:plain
クリーンインストール前．謎のOtherが圧迫している．

クリーンインストール後はここまで減らすことができました．空き容量もかなり増えました．

f:id:kanekou:20210422204410p:plain

ヘルスケアの一環として，定期的にクリーンインストールを行いましょう!!

準備

バックアップちゃんと取ります． 戦略として，シンボリックリンクを使用することで設定ファイルをクラウド(Dropbox)に保存しローカルと同期させます． その他データはTimeMachineに保存し，リストア時にドラッグアンドドロップで戻します．

  1. TimeMachineでファイルバックアップ．

  2. Brewfileのdumpをとる．brew bundle dumpを実行し，dumpファイルを作成(brewfile)．使わなさそうなpackageはコメントアウトし，Dropboxへ保存．

    後に気づいたが，後述のmackupの設定ファイルにbrewfileを追加することでまとめてクラウド管理できそう．

  3. mackupを使い，設定ファイルをDropboxへ移動させる．mackupは設定ファイルを指定場所に移動させ，元の場所にシンボリックリンクを作成してくれる．これによりクラウド上で設定ファイルを管理できる．

  4. 念の為，前もってBig Surをインストールする．

Clean Install

やってき

リカバリーモードでOSを起動し，ユーティリティからデータを削除します．こちらのサイトを参考に，Catalina → Big Surでも問題なく行うことができました．どうやらCatalinaからMacintoshHD とMacintoshHD dataでボリュームが別れたらしいです．両者ともデータを削除し，Macintosh HDの方にOSを再インストールします．大体30分ぐらいだった気がします．アニメ見てたらいい感じです．

リストア

戻します．やる順序間違えたなと思うものもあり，次いい感じなるよう並び直してます．こちらの記事を参考にしました．

最低限やること

  1. パスワードマネージャーをインストール．各ツールのインストールでパスワードを求められるので，早めにインストールする．実際には遅い段階で入れてしまったため，めんどくさいことに． ちなみに1password6というパスワード管理マネージャーおすすめ． ただし最新版の1password7は月額性サブスクリプションに加入しないと利用できないらしいので注意．
  2. Dropboxをインストールしログイン．
  3. brewをインストール．その後brewfileがある場所で% brew bundleを実行し，管理パッケージを一括インストール．
  4. % mackup restoreでDropbox上の設定ファイルをリストア．
  5. Keyの割り当てを行う．これは2の段階で行った方がいいかもしれない．お好みの段階で．以下自身の設定．
    • トラックパッドの設定を変更．tap to clickをオンにする．
    • カンマと句読点の設定を変更．，と．を有効にする．
    • 3本指のドラッグを有効にする
    • 辞書を3本指タップで起動するようにする．Look up & data detectorsをTap wich three fingersにする
    • 左右⌘キーでひらがな，ローマ字を切り替えられるようにする．karabiner-elementsを用いる．
    • US keyboardなのでCapslock KeyをControl Keyに割り当てる．こちらもkarabiner-elementsを用いる．デフォルト設定でも変更可能だが，karabiner-elementsと相性が悪い．
  6. Mail設定．ログインし，HTMLメールをプレーンメールに変更する．セキュリティ上プレーンテキストが好まれるため．
  7. TimeMachineからファイルの復元．必要に合わせてドラッグアンドドロップ．

最低限こんな感じかなと思います．後は個人的な復元作業です．

個人的作業

研究環境の復元

conda環境のjupyter notebook上で実験を行っていたので，Python環境から復元する．

まずpyenvをanyenvを用いてインストール． anyenvは*env系をまとめて管理してくれるので，余分にpathを通す手間を省ける．

% anyenv install --init
% anyenv install pyenv
% exec $SHELL -l

次に以下のpackageのインストールを行う．

  • python
  • conda
  • jupyter notebook
  • その他packages
# インストール可能なpythonとanacondaのverを調べる
% pyenv install -l 
% pyenv install <python version>
% pyenv global <python version>
% pyenv install <anaconda version>
% pyenv global <anaconda version>
# jupyter notebookは色んな場面で使うので，globalにイントール
% conda install jupyter
# 研究用のconda環境を構築
% conda create -n master-research 
% conda init zsh
% exec $SHELL -l
% conda activate master-research
# install other packages 
## もし`conda serach <package name>`でヒットした場合，condaでインストールする
% pip install SNAKES
% pip install pyqubo
% conda install -c plotly plotly

各種ソフトウェアのインストール

基本的にインストール→ログイン作業を繰り返すこととなる．必要に合わせて入れてけばいいと思う． 一番めんどくさい作業なので，前述したパスワードマネージャーがあると捗る．

  • Docker for mac
  • slack
  • mattermost
  • line
  • discord
  • zoom
  • iTerm
  • BetterTouchTool
  • tweetdeck
  • Tex
  • kindle
  • Quiver
  • Vivaldi
  • omnigraph
  • HHKBドライバー
  • alfred
    • app store だとversionが古いため，公式サイトからダウンロードする．その後，検索設定と辞書設定を変更する．辞書設定ではd [word]で単語の意味を，s [word]でスペルサジェストを表示するよう変更する．またCmd + Spaceで起動するよう設定する．
  • vscode
    • mackupのおかげで勝手にsetting jsonが同期される．extensionsは同期されてなかったので，次からこのように.vscode/extensions.jsonを作成し，mackupに追加することで同期させる．

所感

だらだらやってたら丸一日ぐらいかかってしまった... ですがmackupとパスワードマネージャーを用いることで，低コストに復元することができたと思います．

反省点としてbrewfileをmackupで管理してなかったこと，vscodeのextension情報をexportしていなかったことが挙げられます． 設定ファイルはとにかくmackupに追加し，更に容易に環境再現できるよう努めたいと思います． また研究環境構築に関しては，コンテナorスクリプトで自動化できそうな気がします．

どうせなので，秘伝のタレと化した.zshrcと.vimrcを抜本的に見直したいです．もう何が入ってるかよくわからないので．

最後に

mackup最高〜

もっと自動化できるよ！って方いましたら教えてください．

快適なMacライフを👋

参考サイト

JavaScript Primerを完走しました

jsprimer.net

2021年はフロントエンドを重点的に勉強しようと思い，基礎からJSを学ぶため本サイトを利用しました．

読む前のフロントエンドの知見

  • モノリスRailsのerbでフロントエンドを作成していた
  • JQueryで補佐的にフロントエンドを整える程度
  • Nuxt.jsは雰囲気で触っていた
  • ECMAScriptナニソレ

読んでどうだったか

  • JSの基本文法について学んだ．一見同じような処理でも細かい挙動が違うオブジェクトや，現在非推奨の書き方も多くある．進化が早い言語なので，常に最新の書き方を追う必要があると思った．
  • reduceメソッドが難しい．何回も調べてしまう．使いこなせたらかっこいいと思う．
  • JSの取り巻く環境について大まかに把握できた．よくわからないまま雰囲気で書いていたので，背景を知れたのは良かった．
    • JavaScriptとECMAScriptの違いについて学んだ．ECMAScriptはどの実行環境でも共通な動作が定義されている．一方ブラウザとNode.jsでは実行環境が異なるため，それぞれの環境で必要機能が定義されている．共通動作と環境ごとに固有機能を含んだものがJavaScriptであるということを学んだ．
    • ECMAScriptの進化，互換性について学んだ．ES2015前とでは大きく仕様が異なるので書き方に注意する．
    • babel, TypeScript等のトランスパイラーの知見を得た．JSの互換性や型の問題について，トランスパイラーを用いて対処していることを知った．
    • モジュールハンドラーの知見を得た．実行環境の違いによるモジュールの依存関係を解決することを学んだ．
  • 型変換についての知見を得た．暗黙の型変換でバグを生みやすい事を学んだ．型について緩く，危険度の高い言語だと感じた．なぜTypeScriptが重宝されているのか何となくわかった．
  • 非同期処理についての知見を得た．かなり難しい項目だった．完全に理解できたわけではないので，書きながら血肉にしていきたい．

これから

最低限のJSの知見は得たと思うので，Reactの勉強に取り組みたいと思います．バイトとアプリ制作でNext.jsを使う予定だからです．

予定としては，Reactチュートリアル→Nextチュートリアルで基本的な流れを掴み，実際のアプリ開発に入ろうと考えています．時間があればりあクト！ TypeScriptで始めるつらくないReact開発 第3.1版【Ⅰ. 言語・環境編】 にも取り組みたいと思います．

学習メモ

Scrapbox手を動かす系にいいかも．

scrapbox.io

コード

github.com

技育祭3日目参加レポート 2021

3/13に開かれた技育祭2021に参加した．3日目の参加レポートとなる．

talent.supporterz.jp

ただプログラマでありたい～夢中になれるプログラミングの楽しみ方～

GMOインターネット株式会社 デベロッパーエバンジェリスト 成瀬さん(@nrslib)の講演．

プログラミングを純粋に楽しもう，という内容で，共感することが多かった．

特に共感したのは，「きれいにした時」にプログラミングが楽しいということだ．私は，新しいコードを書くよりリファクタリングする方が楽しいと感じる．最近だと研究のコードを1週間かけてリファクタリングしたのだが，研究史上一番楽しかった．

呼吸するようにリファクタリングしろ

「コードを書く=リファクタリングするぐらいの意識を持つべし」と学んだ．「忙しいからリファクタリングできない」と言い訳しそうだが，「リファクタリングする時間も含めてのコーディングスピードなんだな」と思った． エンジニアリングの教科書である「NEWGAME」6巻にて，なるっちが高速実装でバグだらけの実装をしてしまう回をふと思い出した． 品質を意識して呼吸するようにリファクタリングを心がけようと思う．

www.amazon.co.jp

「コードはラブレターである」という考えも面白かった．確かに「どう受け取ってくれるかな」「うまく伝わるかな」ドキドキする点で一緒かもしれない(送ったことない)．相手のことを思いやった読みやすいコードを意識しようと思う．今のところ高確率で振られそう．

「コードに遊びを作る」考えは実践できるようになりたい．「どこまで将来のことを見通してソフトコーディングできるか」の話だと考える．経験が必要だと思うので，とりあえず書きまくるしかない．またOSS等で天才のコードを見て学ぼうと思う．

「新しい言語，パラダイムに触れた時が楽しい」という話も面白かった．「パラダイムが異なるプログラミングを学ぶことで技術力が上がるのでは？」と考えていたので，共感できる内容だった．オブジェクト指向のRubyをこれまで多く触ってきたので，特性の違うGolangを触ることで言語知識を深めようと考えている．

手段が目的化しているエンジニアはつよいと感じる．パズル感覚でプログラミングそのものを楽しんで，かつビジネスにも活かせたら最高だろうなと思った．

モダンフロントエンドの技術の追いかけ方 ~ OSS の魅力を添えて~

株式会社ゆめみ 取締役 桑原さん(@kuwahara_jsri)のフロントエンド技術に関する講演．フロントエンドスタック多すぎ問題に対して，どのように学んでいけばいいか話をいただいた．フロントエンドの知識はあまり持ち合わせていないが，Next.jsを触る予定なので興味があった．

なるほどと思ったのは，学習リストを作り好きなものから取り組むということだ．フロントの技術スタック全部を網羅するのは厳しいと思うので，取り組むならモチベ駆動の貪欲法が良さそうだと思う． 疑問に思った時に深堀りする事で効率よく吸収できそう． ただECMAScriptのは最低限やった方が幸せになれると思ったので，現在進行形でJavaScript Primerの勉強を進めている．

また学んだ次の日に10分でも復習すると記憶の定着率が段違いらしい．TOIEC勉強でも使えそう．

技術のリサーチ方について，「一次情報からアプローチしろ」というのは大学一年生から言われているが，よくQiitaに逃げてしまっていたのでギクッとした． 院に上がり，様々なインターンやバイトを経験してきちんと意識するようになったと思う．エンジニア力 ≒ ググり力 ≒ 英語力だと思うので，リーティング力とDeepL力を更に伸ばしていきたい．

なぜ学ぶ上でOSSを勧めるのか

これについて以下の3つが挙げられていた．

  • Get feedback from engineers around the word.
  • Read code from engineers around the world.
  • Can lead to self-branding.

やはり一番下が最も魅力的に感じる笑．生存戦略の観点で，とても強いカードだと思う．あとシンプルにかっこいいと思うし，憧れるエンジニア像でもある．

一番上と二番目は，学びの観点で強力だと感じた．世界中の人たちからフィードバックをもらえるのは，考えてみるとすごい体験でもある．実装を追いかけてることから始めよう...と思った．

OSSに心理的障壁を感じてしまっているが，やればリターンが大きいと感じた．あとは勇気だけだと思う．いきなりコードをコミットするのではなくて，誤文字を訂正する簡単なところからステップアップしていきたい．

ひろゆきだけど何か質問ある？

元2ちゃんねる管理人 ひろゆきさん(@hirox246)の質問コーナー．技育祭で一番楽しみにしていた．Youtubeと変わらずキレキレの論破を連発しており，とても面白かった．

↑ その通りすぎます．すみません(技術祭はタイポです．すみません)．

  • 「やりたいことができそうな環境」と，「エンジニアとして成長できそうな環境」どちらを選びますか？

と質問もしてみた．それぞれの軸によると思うが，考えを聞いてみたかったので． 私自身は前者に傾いている．

以下回答

  • 入るまでに，「できそうだ」，とか「やれそうだ」とか大体思い違いがあるので，それを信じてもしょうがない
  • 綺麗事を確認できるといいが，真に受けてもしょうがない

Q. ではどのように調べればいいか

  • 働いている知り合いだとか，ネットに書いているので見てみるのがいいと思う
  • 転職率は割と重要

と回答をいただいた． 相手の言っていることを鵜呑みにせず，リアルな声を自分で調べる事が重要だと受け取った． またネットで調べることはしていたが，離職率は見ていなかったので参考になった． ありがとうございます．

所感

成瀬さんの人柄がとてもよかった．ツイッターとzoomコメント越しだが話しやすく，リラックスして聞くことができた．Youtubeも見てみようと思う．

桑原さんのフロントエンドの話は，フロントエンドにとどまらず技術全体に活かせる話だったので，常に頭の片隅においておきたい．

ひろゆきさんのコーナーはzoomが重くなるほど質問がきていたが，バンバン回答しており知識量と論理的思考能力の高さが凄まじかった．言いにくそうなこともスパッと回答するのでYoutube同様見ていてとても面白かった．

技育祭2日目参加レポート 2021

3/12に開かれた技育祭2021に参加した．2日目の参加レポートとなる．

talent.supporterz.jp

無駄なものをつくって稼ぐ方法

無駄づくり発明家コンテンツクリエイター 藤原さんの講演．

「とりあえず作ってみる」という精神が重要だと学んだ．不器用らしいが，コンプレックスを容認し，まず作ってみる姿勢を見習いたいと思った．

アウトプットの重要性を述べており，自己表現する上での必要性が伝わった．

  • 人に見せることで整理される
  • 人に見せることで自分が広がる
  • 消費されず自分のものとして積み上げる

人に見せることで新しいアクションが生まれる．何か作っても人に見せないとあまり意味がないと思うので，人に伝えるのは重要だと思う．

また「作品を通して言語化が難しい自身の内面を知ってもらえる」という考えに納得した．ソフトウェアエンジニアなら普段からソースコードをアウトプットすることで，自身のスキルや考えが伝わりやすくなると思う．社会的に認められているクリエイターの言葉には説得力があった．

「無駄」について

  • 社会的必要性はあまり重視せず，作品を通して自己表現を重視する
  • 世の中は最適化されていくが，無駄なものを省き過ぎるのは良くない．その余白を作っていく．

という考え方が面白いと感じた．無駄なものから生み出されるクリエイティブな可能性はあると思う．

Goライブコーディング2021

株式会社fluct CTOの鈴木さんのGoライブコーディングを眺める会をした．迷路問題に取り組んでおり，VOYAGE GROUP CTO 小賀さんに解説をいただきながら拝見した．

あまりGoに詳しくないが，責任の分離が上手いと思った．マップの中にいるのかを判定する関数やゲッター，セッター等を関数として適切に分離しながら高速にコードを記述しており，凄みを感じた．

またテスト駆動で記述しており，高速なリファクタリングにつなげていた．テストを書くと結果的に記述スピードが早くなることが学び取れた．

鈴木さんのコード↓

https://play.golang.org/p/0P3S44hyVHK

超就活術〜つよつよエンジニアになる為の５つの絶対原則〜

株式会社ゆめみ 代表取締役 片岡さんの講演．

就活を含めた今後エンジニアとして活躍する上での5つマインドセットについて話をいただいた．

個人的に心に残った話は以下4つ．

  • メタスキル
  • リーンラーリング
  • 反面師匠
  • 意思決定における悩み

メタスキル

メタスキルの重要性を再認識した．目標設定の話で，最大と最小の目標を決める考えが興味深かった．

MIN目標は馬鹿らしいぐらいがいい

これに対して「週3日ランニングするという目標設定をした時に，靴を結ぶという最小目標を設定する」という例えがとても分かりやすく，教えを説いたオリジナル替え歌で強く記憶に残ることとなった．

リーンラーニング

必要なことを必要な時に必要な分だけ学ぶこと．具体的には，翌月必要になる分だけのスキルを今月学ぶことを言うらしい．確かに効率良さそう．現状学びたいこと，学ばなければいけないことがたくさんあり，どれをやろうか悩んでいるので，とりあえず直近使いそうな技術から学んでいこうと思った．

反面師匠

一番興味深い話だった．

　苦手な人ほど，学ぶことがある

苦手な人の「苦手な部分」は否定してきた自分であり，見方を変えると自分にない長所を持っている可能性が高い． 面白い考えだと思う．相手のいいところを見つける認知方法は実践していたが，主に感情コントロールの手段として使っていた．この考えを用いることで，苦手な人からも有用な情報を得られるので効率がいいと思った．

意思決定における悩み

内定承諾等，重要な意思決定では悩むことは多いが，どのように決定すればいいか考えを教わった．こちらもメタスキルを生かし，事前に決め方を決めることが重要だと述べていた． 就活では「〜で選んだ方がいい」と言う話をよく聞くので，そういった軸の話かと思いきや，さらにメタな話だったので驚いた．

確かに最後に必要なのは納得感だと思うので，事前に「決め方を決める」ことで後悔を最小限に収められると思う．「考え方や価値観は人それぞれ違う」ことを前提に置いた時，メタスキルの重要性を改めた感じた．

[1部] 今求められる21世紀型エンジニアに必要なこと [2部] 大好評につき今年も開催！若手6人のぶっちゃけトーク

前半は株式会社サイバーエージェント 長瀬さんの講演，後半は若手6人のぶっちゃけトークという内容だった．

前半

表題の通り21世紀で必要なエンジニアについてのお話をいただいた．端的にいうと技術が進歩し，実装コストが低くなるので，自らアイデアを提案するオーナーシップ型エンジニアが求められるという内容だった．「エンジニアは実装だけでなく，プロダクトマネージメントもする必要性がある」という認識だ．

CloudやSaaS等でさらに技術スタックが一般化するということで，スペシャリストではなく，ジェネラリストが求められるようになりそう．どちらかというとジェネラリストになりたい．

後半

若手6人のぶっちゃけトークという内容だった．

メガベンチャー志望の方々は「環境」を軸に選ぶ人が多いと感じた．様々な事業に取り組んでいる会社なので，「事業領域に興味がある」というよりは「人」や，「成長できる環境」で選んだ方が幸せになりそう．私は「事業領域」を最も大事としてるので，今の考えだと向いてないかもしれない．このことを学べたのはよかった．

また30代にもらえそうな給料が想像していた額よりかなり高く，とてもびっくりした(なんだかんだお金は大事)．

所感

片岡さんのメタスキルの話が強く心に残った．認知を変えると行動が変わることを再認識したし，メタスキルをさらに上げていこうと思う．