Posts for: #Medium

何もしてないのに1日が過ぎた

#drink  #life  #medium  #java 

仲の良い焼き鳥屋さんで軽く飲んできた。2時に寝て7時に起きた。午前中はだらだらしてた。午後から会社の事務手続きをやりながら、実家の法事の段取りをやりながら、ブログの記事などを読んでいた。

jj

茉莉花 (ジャスミン焼酎) をジャスミン茶で割った飲みものを jj と呼ぶらしい。焼き鳥屋さんのマスター曰く、お客さんが 串カツ田中で販売 しているのをみて、焼き鳥屋さんでも扱ってよと言うから置いてみたと話していた。あまりこれまで飲んだことのない不思議な飲みものになっていた。基本はジャスミン茶なんだけど、アルコール入っているなという雰囲気がするカルイ飲みものに感じた。お茶ベースだからどんな食べものにもあいそう。すごくおいしいものではない分、軽く飲みたいときにちょうどいいかもしれない。

法事の出席者管理

来週は35日の だんご転がし がある。2月の上旬には49日もある。過去の葬儀もあわせて親戚や関係者の、出席を管理するためのスプレッドシートを作った。出席確認を母に任せていたらなかなか進まなくてお正月から2週間あってもまだ確認を取り切れていない。人間を調整するのがもっとも面倒で時間がかかる。その後に初盆、1回忌、3回忌と続く。連絡先の電話番号も私の方で管理して、私が電話していった方がよいのかなぁ。

Java は死んだ

この記事の著者はいまも java が通用すると思っているとしたらそれは誤解があるという。その誤解を5つあげるといった記事。

誤解1: Javaには、大規模で活発な開発者コミュニティーがある。

これは誤解ではなく事実だと書いてある (´・ω・｀) 著者の意見としては、他言語の進化が速く java は冗長で古い型システムで時代遅れみたいなことを主張している。私の意見だと java の進化もいまは速くていうほど時代遅れというほどではない。過去の資産がいまの java に追いつけていないといったのもある。十分に他言語に機能的に追いついているし開発サイクルも速い。

誤解2: Javaは幅広い用途に使われる。Javaは単なるWeb開発言語ではなく、モバイルアプリやゲーム、エンタープライズレベルのソフトウェアの開発にも利用されている。

これも著者の視点が適切ではない。モバイルでは kotlin が席巻していて、web の開発言語としても java をあげるのは大企業やエンタープライズ開発のみではないかと説いている。たしかに kotlin は java ではないが、jvm 言語ではあるので jvm は未だに必要とされているという事実がある。もう1つ、java はエンタープライズレベルのでミドルウェアで確固とした地位を気付いている。例えば、cassandra, hadoop, kafka など、これらを web 開発で使っている限り、それは web 開発でも使われていると言えるだろう。

誤解3: Javaは基礎となる言語である。多くの新しいプログラミング言語は、Javaの原理と概念に基づいて構築されており、何らかの形でJavaと互換性を持つように設計されている。

こんなこと誰も言っていないと思うけど、著者がそもそも誤解しているのではないか。一方でクリーンアーキテクチャに代表されるような、java のエコシステムで開発されたアーキテクチャなどは java と相性がよい。java と他言語との最大の違いはクラスがないとプログラミングできないという点であり、これはメリット・デメリットをもたらすが、oop においては di 技術を進化させてクリーンアーキテクチャのような概念の下支えをしている。

誤解4: Javaは大手企業の強力なサポートがある。Javaを保守・サポートしているオラクル社は、Javaという言語に強いこだわりを持っており、その開発・改良に投資を続けている。また、GoogleやAmazonなど、多くの大手企業が自社の製品やサービスにJavaを採用している。

oracle という企業とそのプロダクトが市場でのシェアを失っているという視点で懸念を表明している。たしかに oracle はそうかもしれないが、google や amazon だって java を活用しているので oracle がダメになっても web 系の大企業がサポートしていくのではないかと私は推測する。

誤解5: Javaは学校や大学で広く教えられている。

この点だけは著者の意見に違和感はない。一昔前は java が大学でよく教えられていたと思うが、今後は python や go といった、他の言語が最初に学ぶプログラミング言語として人気を博していくのではないかと私も思う。

ざっと読んでみて java 開発をやったことのない経験が浅い開発者が書いた記事だなと思えた。

url エンコーディングと uri の仕様

#java  #spring boot  #medium 

1時に寝ようとして、寝てたか起きてたかわからない時間を過ごして7時に起きた。

WebClient と query string のエンコーディング

以前にも WebClient の基本 について少し書いた。data={"x": 1, "y": 2} のような json 文字列を query string でリクエストしようとしたときに少しはまったので書いておく。java 標準ライブラリの URLEncoder を使ってエンコードするとスペースが + になる。これは html の仕様として正しいが、uri の仕様としては不正になる。そのため + を %20 に置き換える必要がある。

private String encode(String data) throws UnsupportedEncodingException {
    // NOTE: the URI doesn't allow '+' character
    return URLEncoder.encode(data, StandardCharsets.UTF_8).replace("+", "%20");
}

このロジックで {"x": 1, "y": 2} を url エンコードすると次の文字列になる。

%7B%22x%22%3A%201%2C%20%22y%22%3A%202%7D

あらかじめ url エンコーディングした文字列を渡すと、今度は WebClient が % を %25 にさらにエンコーディングしてしまう。Spring WebClient Requests with Parameters 6.Encoding Mode によると、次の4つのエンコーディングモードをカスタマイズできる。デフォルトは TEMPLATE_AND_VALUES らしい。

  • TEMPLATE_AND_VALUES: Pre-encode the URI template and strictly encode URI variables when expanded
  • VALUES_ONLY: Do not encode the URI template, but strictly encode URI variables after expanding them into the template
  • URI_COMPONENTS: Encode URI component value after expending URI variables
  • NONE: No encoding will be applied

もとの url エンコード済みの文字列が次のようなものになってしまう。

%257B%2522x%2522%253A%25...

既存の実装をあまり変えたくもなくてやや力技で実装した。局所的な変更だからまぁいっか。

webClient.get().uri(uriBuilder -> {
  var uriObj = uriBuilder.path(getControllerBasePath() + path).queryParams(query).build(pathParams);
  if (encodedData != null) {
      var uri = uriObj.toString();
      var connector = uri.contains("?") ? "&" : "?";
      uriObj = URI.create(String.format("%s%sdata=%s", uri, connector, encodedData));
  }
  return uriObj;
}).retrieve()

よいエラーメッセージ、わるいエラーメッセージ

タイトルに惹かれてちょっと期待外れ。art というと日本人は芸術と高度なものを期待しがちだけど、the art of だと技術の体系といった意味合いもあるのでちょとしたノウハウを解説する技術ブログのようなものでも誤っていない。

ユーザー体験をよくするためのエラーメッセージのコツとして次の3つを提案している。

  • 何が起きたのか、なぜ起きたのかを説明する
  • 次のステップを提案する
  • 適切なトーンで書く

この3つの具体例としてどのようなものかを説明している。私にとってはそう目新しいものではないが、エラーメッセージにトーンという概念はなかったので最近の流行りなのかなと思った。

蓋然性という言葉がよくわからなかった

#verbal aptitude  #medium 

0時に寝て7時に起きた。朝からタスクの詳細をヒアリングして web api と画面を作るだけの簡単な作業。しばらく (1-2週間ぐらい？) は暇な日々が続きそう。

蓋然性 (probability) と可能性 (possibility) の違い

わかりやすかった。

夏目漱石が授業で言った例では、「教壇で喋る講師が逆立ちする可能性はあるが、蓋然性はない。」というものがあります。

「判例の用いる確率の用語」～元公務員講師のコラム～

なんとなく稼ぐ

次の4つの手法による収入を passive income (受動的な収入) と定義している。

  1. ソフトウェアとデジタル資産を売る
  2. ブログを始める
  3. 自分の youtube チャンネルを始める
  4. フリーランスオンライン

それぞれみていくと、ソフトウェアを売るというのはアプリストアに代表されるようなマーケットプレイスで販売すること。デジタル資産とは電子書籍など。ブログは medium のようなサブスクリプションを使う。youtube はコンテンツを作って広告収入を得るかな。オンラインでフリーランスとして副収入を稼ぐという方法。どれもよく知られた当たり前の手法だけど、簡潔にまとまっていてわかりやすかった。

スキルの定量化とお仕事探し

#founding  #career  #medium  #management 

0時に寝て7時に起きた。直近は日曜日はだらだらしてたんだけど、すんなり起きれた。

お仕事探し

offers さんのカジュアル面談 の雰囲気から企業に直接応募するプラットフォームの方が、私の経歴や実績の詳細を確認しやすいので面談に進みやすいのではないかとみている。そこで findy と lapras のプロフィールを作成してみた。これまで oss 活動やブログなどでアウトプットしていた資産がたくさんあるのでレベルはしょぼいにも関わらず、これらのプラットフォーム上ではそこそこよい数値がアルゴリズム的には算出される。プラットフォーム側としては転職やエンゲージメントを高めたいという意図があるから、ゴーストアカウントのようなものも含めて算出すると普通の人は高めの数字が算出されるのではないかと推測する。

findy さんのスキル偏差値によると、想定年収予測は1060-1160万円らしい。この数値は起業する前のサラリーマン時代の年収に近いのでそんなにずれてはいない。lapras さんの公開プロフィール によると、技術力が4.01で約170万人中668位だというのは上位 0.04% に属することになってしまう。んな、あほなという思いはある。とはいえ、自己申告の経歴をいくらでも盛れる職務経歴書よりも、客観的なアルゴリズムで評価できる指標の方が絶対値が適切かは置いておいても、相対評価において他の候補者と比較できるのを好む採用担当者もいるだろう。匿名の一般的な職務経歴書を用いる remogu さんの選考 は書類選考でばんばん落ちまくる。それに比べたら、アルゴリズムで相対的によい数値が出ているプラットフォームの方が面談に進みやすいのではないかという話し。本当にそうかどうかの仮説はこれから検証する。

google の従業員が働いていないという発言の真意

昨日たまたま medium のダイジェストでみかけた記事を読んだらおもしろかったので、なるべく余裕のある日は medium の記事を1つ読むようにしてみようかと思う。言うても deepl を使って斜め読みして大意を掴む程度なので日本語の記事を読むのとそんなに時間が取られるわけではないと思う。今日は次の記事を読んだ。

プログラミングにおける生産性とはどういうものかを説明しつつ、google の ceo がいう生産性が十分ではないという発言の真意は、従業員が業務時間にさぼっているとか怠慢だとかいう意味ではなく、google のビジネス全体がこれまで達成してきたのと同じ業務時間では期待した成果を達成できなくなってきているのではないかと考察している。

At some point, productivity measurement becomes Schrödinger’s cat.

また著者の引用？では生産性の計測とはシュレディンガーの猫のようなものだという話題もおもしろい。どんな会社もある時点での生産性の測定はシュレディンガーの猫のようなものになる。セグメントを分割し過ぎると返ってストレスとなり、余計な混乱を招き、計測そのものが生産性を低下させる。生産性の測定はマクロレベルでやるのが理に適っていて、工場時代のマネジメントをもつ amazon は大量の人員削減をしつつも成し遂げた。google のようなワークカルチャーをもつ会社ならその気になればスマートにできるだろう。一方で google という会社はすでにリベラルな極みにある企業文化をもっているため、生産性を測るような試みは組織全体に大きな感情的ダメージを与えるだろう。その結果として amazon と同じような道を歩むのではないかと。

シュレディンガーの猫がどういう意味かもわからなくてそれも読んでた。

キャリアは知識と経験の差分でわかる

#life  #medium  #programming  #information exchange 

23時に寝て2時に起きてその後どうしていたかあまり覚えていないが気付いたら8時だった。

ストレッチ

今日の開脚幅は開始前160cmで、ストレッチ後163cmだった。今週も全然ストレッチできなかったのになぜか数値はよくなっていた。ストレッチを受けていて調子の悪さも感じなかったので気候が過ごしやすくなってきて体調がよくなった結果として普段の生活における活動量や新陳代謝などにも影響を与えているのかもしれない。トレーナーさんからは涼しくなったのだから運動をしてくださいと言われた。ほんとその通り。

知識と経験

たまたま目を通した medium のおすすめ記事に出ていて、タイトルにひかれて斜め読みしたらおもしろかったので後で deepl を使って精読した。最近は英語の記事を deepl で訳して読んでいる。まず deepl で全訳した後に文脈から訳文の意味をとれなかったり、明らかにおかしいところだけを手直しする。著作権的に機械翻訳を公開はできないため、その翻訳内容は課題管理システムのイシューで管理している。この記事だと手直し数回ぐらいで大意を読める。普段、英語の記事を日本語アカウントで紹介することはないんだけど、これは素晴らしい内容だったのでそのまま共有することにした。軽く所感も書いてあるが、課題管理システムのイシューにはさらに詳細な分析やコメントも残している。

多くの若いチームでは課題管理の重要性を理解していない。その無理解の原因の1つとして、ものごとを検討したり判断したりした時点では正しかったことが未来のある時点で誤りになってしまう可能性を想像できないからだと私は考えている。記憶と忘却の仕組みから前日のことですら半分以上忘れてしまうので数ヶ月前の詳細など、ほとんどの人は覚えていない。にも関わらず、日々の小さい判断の積み重ねや意思決定の履歴を記録として残さないのはなぜだろうか？それはその詳細があとで重要になるかどうか、多くのケースでその発生時点ではわからないからだ。例えば、システムのアーキテクチャに関して言えば Architectural Decision Records (ADRs) というドキュメントが提唱されている。アーキテクチャのような大きなものでさえ、明示的に残さないと経緯がわからなくなるのに、もっと小さい粒度である日々の開発や運用の誤りを、一般の (普通の) 開発者がその発生時点から数ヶ月や数年経ってふりかえって見直すことができるだろうか？いやできないというのが、多くのチームやメンバーをみてきた私の所感だ。多くのメンバーは過去のある時点の見逃しや判断ミスをなかったことにしようとする。それは無意識にしろ意識的にしろ起きやすい。客観的に詳細を確認できればなかったことになってしまうのは仕方のないことでもある。

私は課題管理システムのコメントに、こういう状況からこう判断したとか、誰それと相談してこういう事情でそうしたとか、自身の感覚からとくに意味もなく決めたとか、常々なぜに相当する内容を残している。そして、あるとき過去の経緯を見返して、そのときの判断は適切だったか、過去のある時点で気付けたはずのことを見逃してなかったか、見逃していたとすればどうすればその時に気付きを得られたか、というふりかえりを日常的なチケット整理の一環として実践している。件の medium の記事にはなぜそれが重要なのかの概念を書いてあるように私には受け取れた。課題管理 + 情報共有の需要な概念の1つだと認識して寝かせておこうと思う。