よく忘れるのでメモする

• 起動

  • 1mysql.server start

• rootユーザーでログインする

  • 1mysql -u root -p

以降はログイン後の話

• データベース一覧

  • 1show databases;

• データベースの中のテーブルを確認する

  • 1show tables from {database_name};

• 使うデータベースを指定する

  • 1use {database_name}

• 終了

  • 1exit

随時更新していく。上に行くほど最近読んだ本。

一言で言うと「思い出にも複利の効果があるよ、経験は早めにしようね」という内容の本。

自分はお金はそこそこたまっているし、資産運用もしているけど、なんとなく増やしている感じがずっとあった。そういう自分にとってはいい本だった。

これまでの人生で色々なことに挑戦してきたし、それに必要ならいくらでもお金を払ってきたので、この本で言う良い生き方が出来ている自信はある。でも本を読んでまだまだ若いうちにもっと色々なことに挑戦してみたいなと思った。

海外エンジニアの働き方から学べることがたくさん書いてある本。個人で実践できる内容のものもあれば、組織や文化の助けがあって実践できるようなものもある。

本の内容は基本的に同意。読んでよかった。

11/28読了

面接という取り組みを通して、色々なシステムの設計を検討する本。要件を整理して全体像からシステムを設計し、そのあとに冗長化や複雑な仕様に対応できるような設計に変更していく。どういうインターフェースにするのか、どういう実装の方法があるのか、それらのメリデメは何かという雰囲気を掴むことができる。

本を通して15個のシステムの設計を考える。後半のYouTubeの設計やGoogleドライブの設計はかなり難易度高かった。読んでいて楽しい本。

11/15読了

TDDの実践方法を解説した“Test-Driven Development By Example"の日本語版。原著は2002年に書かれたものであり、それから20年経っている。

第一部ではTDDを使って国際通貨を扱うモデルを設計していく。ハンズオンを文章にしたような内容。本のために誇張している部分もありそうだが、細かいステップを踏んでいくやり方に少し面食らった。少し退屈に感じる場面もあるが、最終的に出来上がるものが素晴らしくて読んでいて感動した。

第二部ではxUnitを自前で開発していく。当然TDDを使って開発していく。

第三部ではTDDを行う上で使える周辺知識が述べられている。XP的な話が多い。デザインパターンのところが読んでいて面白かった。

付録の訳者による解説も面白かった。原著の出版からの15年に起きたTDDに関する世の中の反応や誤解について述べられている。これを読んでから本編を読む方が良い気がした。

どこかのタイミングでTDDを実践してみたい。

10/21読了

大事な能力だよね。意識するようにしてる。

10/4読了

知識のインデックスを作る目的でさらっと読んだ。

Vue勉強第二弾。

Vueを使った実際の開発のイメージが大分湧きました。各章独立していて読みやすい。

9/26読了

お仕事でVueの勉強が必要になり購入。

本の内容/構成はとても良いが、記載内容が古い(Vue2)ことに注意

この本からVueについて色々調べているけど、Vue2からVue3の過程で互換性のない変更をしたためユーザーが離れている雰囲気を感じている。仕事抜きに考えたとき、今から勉強して得になる技術なのだろうかと少し悩みながら勉強した。

とりあえずこの本でVueの概念や思想、Options APIの書き方は理解

9/25読了

プレイヤーのミスを見抜き、それを攻撃するための本

少なくともバレルを打つ抵抗が減ってきた感覚がある。

8/29 読了

9月にASPTに参加する。ポーカー強くなりたいから読んだ。

2-5の戦略が結構印象的。自分は1-2レベルだなと実感。これらの戦略を取り入れたポーカーをしていきたい。

8/21読了

ここ最近設計に関する本を読んでいる。この本も気になっていたので購入。

ソフトウェアに関する設計の話題をまとめた本だが、この本の構成が面白かった。最初にクリーンアーキテクチャを説明し、その背景を解明する形式でパッケージ原則やSOLIDなどを説明している。とにかく本質を伝えることに注力しているし、サラッと難しいことが書いてあったりする。ところどころ入ってくる絵が可愛いし定期的に読みたい。

8/12 読了

7/16読了

高品質なコードを書くための考え方が書いてある本。高品質なコードとは、信頼性が高く、保守が容易でバグが少ないこと。一章の理論編で抽象化、コードでの契約、エラーの扱い方などといった大きな考え方が書いてあり、この本のメインとも言える。中盤は命名や、DIなど、よくあるテクニックが紹介されている。 全部がどこかで見聞きしているものなので、知識を整理したり、人に進めるのによさそう。

7/2 読了

フロントエンドのテストのツールについて一通り紹介されている。ハンズオンの資料のような本なので、少し具体的すぎるような記述が多い。手を動かしてみる系

7/2読了

1974年に書かれたエッセイ。人月の神話や、銀の弾丸などないなど、色々な元ネタが詰まっている。ソフトウェアの難しさは本質的なものと、偶有的なものにわけられ、結局本質的なものはどれだけ進歩しても難しいままである。そのことは目を背けることはできないし、悲観的になる必要もない。そして、この本質は50年近く経っても色褪せていないし、技術の進化によって偶有的なものが減ってきていることでより顕著になっている。

途中あまりにも時代が古すぎて読んでいてつらい部分もあったが、全体的に共感する部分が多いし、書かれた時期をふまえると本質に満ちた内容が多い。

自分もタールの沼に足を踏み込んでしまった人間なので、もがきながら楽しもうと思った。

7/2 読了

エンジニアの感覚とビジネスの感覚の差を埋めてくれる本。 ビジネスサイドの人が読むとエンジニアの言っていることがより分かるようになるし、 エンジニアが読むと、「自分たちの常識をビジネスサイドの人たちは知らない」ということを知ることができる。

チームメンバにすすめて共通認識を作る系の本

6/20読了

こういうメタ知識大好き。

1975年に書かれた本。学びとは何かを徹底的に考えている。古い本だが、色褪せない系。

この本における学びとは、自分や他者の一貫性（世界）を維持しつつ、開放的に高め合うことを指している。いわゆる教育学的な側面を持っている本なので、機械的に教育する取り組みと、その取組がもたらす閉じた世界（上記の学びの定義から離れる状態）のジレンマなどを紹介している。

教育者や、ジュニアなメンバーに何かを教える人は読んで見ると面白いと思った。

6/4読了

副業先でリーダー的ポジションを任されている。最近それ関連の本を読んでいる。

この本ではチームを自己組織化チームにすることを目的としている。自己組織化チームとは、リーダーに依存せず意思決定ができる状態を指す。

チームのフェーズ（状態）は3つある。「サバイバルフェーズ」「学習フェーズ」そして、「自己組織化フェーズ」。それぞれでリーダーの振る舞いを変えることを求めている。

サバイバルフェーズはこの本では「学びが無い状態」のことを指す。眼の前の仕事に忙殺されている状態。このとき、リーダーは指揮官として動くことが求められる。目的はサバイバルフェーズから脱却し、学習フェーズに移行することだ。

学習フェーズはゆとり時間がある。そしてそのゆとり時間で新たな技術を学習したり、技術的負債を取り除いたり、チームメンバーに教えたりすることができる状態。このときリーダーは良きコーチとして振る舞う必要がある。

学習フェーズを経て、チームは自己組織化モードになる。このときのリーダーの振る舞いはファシリテーターとなる。決して指揮官になってはいけない。

このようなチームの分け方と、それぞれの振る舞いがあることを学べてよかった。残りはそれぞれの詳細で、後半は様々なリーダーのエッセイ集になっている。Matzもいた。

読んでて面白い本だった。

5/31読了

運用・拡張が厳しくなったソフトウェアをどう改善すべきか、幅広いトピックを紹介してくれる本。ツールがJava寄りなので、実務で活用するには別途ツールを調べる必要がありそうだったが、網羅的にトピックが書かれており満足だった。 5/4読了

読んで感じたこととして、理想が強くてすぐに実態と合わなくなりそうだなという印象。考え方や、何に課題を感じているのかという部分だけ意識して、それをなるべく増やさないような（DDDに限らない）実装をしていくぐらいのスタンスで良い気がした。

4/27読了

このあたりで知識を再整理したいと思い読んだ本。

画像、フォント、色の章が自分にとって学びが大きかった。なぜ2,3倍の画像を用意するのか、font-familyとはなにか、色とは何かがわかるようになったのは大きい。

対象者はWebデザイナーの本で、仕事の進め方みたいな話も含まれていたりする。

決済の歴史が包括的に書かれている。銀行が話に絡んでくるため、銀行の歴史とも言える。テクノロジーの台頭によって、決済の仕組みが大きく変わろうとしている。お金には犯罪がつきまとう。多種多様な人達が様々な思惑でいろいろなことをしてきたし、これからもそれらは続くことが予想される。決済に関する歴史や、登場人物など、全体感を知ることができてよかった。

ただこの本を読むためにはある程度の教養が必要そう。

以下の意味、読み取り方が分かる本。丁度いいレベル。

• 損益計算書

• 貸借対照表

• キャッシュフロー計算書

アクセシビリティについて知りたくて読んだ本。

色の見え方や言葉の使い方など、具体例が多く紹介されている。特に色弱の見え方がここまで違うものだとは思わなくて驚いた。

アクセシビリティは心遣いというか気遣いでもあるので、普段の実装で意識していきたいなと思った。

利益や数字指標を上げるための方法として、全体の、長期的な利益を最大化する「グローバルマキシマム」と、局所的な、短期的な利益を最大化する「ローカルマキシマム」がある。

ビジネスで生き残るためにはローカルマキシマムに頼らなければならない場面もある。しかし、脳死でローカルマキシマムに飛びついている人たちが一定数いるのも事実である。それを回避するための方法として、ラディカル・プロダクト・シンキングが挙げられている。

具体的な方法は本に書いてあるが、ビジョンを具体的に言語化し、それを日々の行動に移すのが大枠。 企業文化の話や、倫理の話もある。SDGsみを感じてしまった。

何かアウトプットを出すものというよりかは心構えの話なので、この考え方をもとに日々を過ごすだけでも何かが変わりそうだなと思った。具体的な事例が多くて面白かった。

面白かったキーワード「ビジョン負債」「スーパーチキン」「デジタル汚染」

2010年です。高校生の頃に購入した雑誌です。12年かけて解きました。 もちろん12年ずっと取り組んでいたわけではないです。数年放置しているのもザラでした。

最近パズルが自分の中でブームなので、家にあるペンシルパズルを消化しようと思い、解きかけだったパズル雑誌にトドメを刺しました。

ずっと放置していた理由は25*25ナンプレです。 こいつが曲者で、過去に5回挑戦して途中でハタンしていました。そりゃ心折れる。

2022/5/28の土曜日に、6度目の挑戦を行い、やっと解くことができました。6度目の挑戦は3時間ぐらいかかったかな。

大型ナンプレ、パズルとしての面白さより、ただの複雑な作業ゲーって感じで正直あまり好きではないんですよね。今度から解かなくてもいいかな。。。

あと167番のカプセルナンプレが問題として破綻していました_(:3」∠)_ 何度解いてもハタンしてしまうため回答をみたところ、ルールに合わない数字の配置があるのを発見しました。まぁこういうこともあるでしょう。10年以上前の雑誌なので文句言うつもりはありませんが、3度ぐらい解き直ししたのでちょっとげんなり。

会社の施策でアカウントが払い出されたのがきっかけで、有料IDEのRubyMineを最近使っています。もともとはVSCodeを使っていました。

ライブラリにコードジャンプできるところが非常に気に入っているので、しばらくは使うと思います。

エディタの乗り換えについてですが、もともとエディタを使いこなすタイプの人ではなかったので、そこまで抵抗はなかったです。

以下設定周りでやったこととかのメモです

コマンドから起動させたい

VSCodeの場合、開きたいリポジトリをカレントディレクトリにした状態で

1code .

1mine .

(追記)新しいPCにしました。Toolbox経由でRubyMineをインストールし、これを参考に設定を変更するのが一番楽です。

.idea/を.gitignoreを変更せずに無視したい

RubyMineを利用すると .idea/ が作成されます。うっかりするとgit pushしてしまうのでこれを阻止したい。

全社でRubyMineを利用しているという状況ならば.gitignoreに追記しても良さそうですが、現状一部の人が利用しているという状態です。なので.git/info/excludeに追記することで個人的にignoreしたいやつを設定しています。

1echo .idea/ >> .git/info/exclude

対象のコードのGitHub上でのリンクを取得したい

拡張機能を使います。

保存時にファイルを整形したい

1. ⌘+,で設定を開く

2. 「Tools」→「Actions on Save」

3. Reformat codeにチェック

メモ帳のように正方形の紙が束ねられています。

それぞれの紙には白と黒の模様が印刷されており、上手に折ることで片面が4×4の黒、裏面が4×4の白になるように折ることが目的です。

これをうまく折ることで

こうします。

折り紙という普段やらないことをメインにしたパズルなので、とても新鮮で解いてて楽しいです。

全100問