エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

Windows10にOracleをインストールしようとしたらありがちな罠にハマった

Oracle18cのWindows用のZipを落としてきて、解答して、
setup.exe
を管理者権限で実行するんだけど、一瞬だけウインドウが表示されたあと、すぐに消えてしまう現象が発生。

ググると同じお悩みの人は多い。
質問サイトを読んでいると…

"Remove all the spaces in the name of directory"
community.oracle.com

ビンゴ！ "Program Files" の下でやろうとしてたのが原因でした。
ありがち。
https://community.oracle.com/thread/4175173

f:id:taichiw:20200209125846p:plain
※ダウンロードも時間かかったけど、セットアップがまた長い…

古いプログラムからも学ぶことがある…と思う。

機会がありまして、宮大工・西岡常一さんの聞き書き、「木のいのち木のこころ」を読んでいます。

木のいのち木のこころ 天・地・人 （新潮文庫） [ 西岡常一 ]

木のいのち木のこころ 天・地・人 （新潮文庫） [ 西岡常一 ]

宮大工として過去の建造物の解体修理をしていると、過去の職人の仕事が見えてくるそうです。
建築から1300年以上経ってもなお現存する、法隆寺の建築仕事の素晴らしさ。
一方、そこから時代が下った、室町や江戸時代に建てられた寺社を見ると、便利な道具が発明されたことや、華美な装飾やコストカット、早い完成が求められたことなどを背景に質が悪化している、ということが見えるそうです。


そんな文章を読んでいるうち、まったくもって1300年という歴史はありませんが、「古いプログラム」に思いを馳せてみるのもいいかなぁと思いました。
…ということで、「『10年くらい前のソースを読んでうわって思った』5年くらい前の私」の話です。


当時私が担当していたアプリケーションの一部に、「Java1.4以前に書かれたんだなぁ」というソースコードが残っていました。
現在のビルド環境、動作環境は最新のJDKが使われていますが、ソースの書き方が「ジェネリクスがなかった時代」の書き方なんですね。

特に当時衝撃だったのが、
・クラスやメソッド名に意味がない。abb101, abb102, みたいなメソッド名が並んでる
・メソッドでコレクションを引数として受け取る場合は、配列。ListやMapを引数に取らない
の二点でした。

当時は、「何この古臭い書き方…」「理解できない」「ク○コード」くらいにしか思っていませんでした。しかし、改めて思い返してみると、今でも通用する設計上重要なエッセンスが含まれてるんです。


クラス名やメソッド名が読めない、意味不明なものである、ということは、別でこれらの一覧を定義した仕様書があった*1ということです。
仕様書があろうがなかろうが、読める名前にしたほうがいいのは間違いありません。
しかし、きちんと初めにメソッドを定義してからコーディングに入るという考え方自体は、TDDなどにも見られるように今も重要な考え方だと思います。


一方、引数を配列で取る、というのは当時のJavaの言語仕様の範囲内でなるべく問題を起こさないためのテクニックだったようです。キャリアの長い先輩エンジニアから以前、教えていただきました。
Java5でジェネリクスが導入される以前のJavaでは、ListやMapなどのコレクションの要素の「型（クラス）」を明示的に宣言する方法がありませんでした。
そのため、コレクションへの要素の追加時と要素の取り出し時で異なるクラスを使ってもコンパイルエラーにはならず、実行時に例外が投げられたり、予測しない挙動をする、という危険がありました。
これを防ぐため、メソッド間でコレクションを引き渡す場合、型の定義が可能な配列にあえて変換して引き渡すことで実行時エラーを回避する、というテクニックがあったそうです。

今の時代に置き換えますと、さすがにJavaのメソッド呼び出しでこういう事は起きないと思うのですが、Web APIの呼び出しで見られるような話ですね。
最近（…とは言え数年前か）は、RESTでは型が定義しづらいからgRPCなどのRPCを使って、プログラム内で型定義をする　という話もあるようです。


プログラム言語やフレームワークはどんどん進歩していますが、保守性が高い、読みやすいコードの要素というのは昔から変わっていないと思います。
ときには「ふっっっるい」ソースコードを読んで、当時の人の考えに思いを馳せてみるのもおもしろいかもしれません。

*1:どこかには現存しているのかもしれませんが、私は在処を知りません

自組織内でアドベントカレンダーやってみました

Team マネジメント

今の自部署が7月にできて半年弱。
当時、新しいプロダクトに不慣れだった各メンバーも、随分と慣れてきました。

…ということで、ちょうど12月だし、お互いここ半年で学んだことを共有しあってみようぜ！　ということでアドベントカレンダーを部署内でやってみました。
f:id:taichiw:20191202202834p:plain
誰も乗ってくれなかったらどうしよう…　と思ったのですが、埋まりきってはいないものの、とりあえずライターがそこそこ集まってくれて、ホッと胸をなでおろしているところです。
（さすがにいきなり始めると本当に誰も来てくれない恐れがあったので、事前に角度高そうなメンバーに興味あるかどうかは聞いてました…が、それ以外の人達も集まってきてくれて嬉しい限り！）

直近、今週の金曜日が埋まってないので誰か引きずり込まないとなー！

Rakuten Technology Conference 2019 に行ってきました RTC2019 #rtechconf

tech.rakuten.co.jp

「明日すぐに仕事では役に立たないけど、いつか一個くらい役に立つかも」的な単語を覚えてこれたので、満足でした。行ってよかったです。

GitOps, Jenkins X & the Future of CI/CD

  • Jenkins X
    • 今日、会場に付く前に唯一予習していった単語
    • Kubernetesなどのクラウドネイティブアプリケーションに特化したCI/CDツール
    • 単にデプロイだけでなく、クラスタを組むところからやってくれるみたい
  • ML(Machine Learning)を用いたテスト最適化
    • どのテストを流すべきかをMLを使って分析・決定
    • テスト量が1/3になったとか、結果変更したのに流し漏れたテストは0.1%しかなかったとか、AWSの費用が1/2になったとか。

Fast and Curious

フロント弱いんで聞いてきました！

Fight back against Endless Phishing and Fake site

終わりなきフィッシングサイトとの戦い。
ページの構造に目をつけて、機械学習でフィッシングサイトを見つける話とか、
楽天の店舗向けもユーザーも、社員も、フィッシングサイトで狙われているとか、
おはなしとして面白かった。

Computer Vision - The Now & The Future

今のAIはここまでできる　って話が面白かった。

運営の皆さんはお疲れさまでした！

※公式Twitterがツイートしてんるんだけど、ハッシュタグをつけていないのは一体…？
※公式サイトにスピーカー紹介はあるんだけどセッション紹介がないのは一体…？

【昔話】無力さを感じた九州旅行

今の会社に新卒で入社したのが2008年。
その後、新人研修などを終えて、縁あって、オンライン旅行サービスの開発をする部署に配属されたのが、今日からちょうど11年前の2008年8月1日でした。

当時の自分の感覚では、
・インターネットで、宿や交通手段の予約をすることは市民権を得てきている
ことに加え、
・自分のように、「居酒屋の予約すら電話でするのが嫌な人間」にとってはネットで宿が取れるなんて最高！
　→このサービスは確実に旅行者を増やしている
　→人が動く！地方に金が落ちる！　すごい、これこそまさに「日本を元気に、地方を元気に」だ！　俺の会社はすごいことをやってるぞ！

…と感じていました。

そんな中、翌年の2009年、日本に「シルバーウィーク」という連休が爆誕しました。
このシルバーウィークを使って、当時の私は、「九州全県を7泊8日で周る弾丸ツアー」を敢行しました。
f:id:taichiw:20190801235321p:plain
この旅行中も、携帯電話から適宜よろしいタイミングで宿を予約したり、あるいは観光地情報を調べたりして、「あー　便利な世の中だなー　俺もその便利さの一端を担ってるんだなー」なんて思ってたんです。

そんな中、最終日に訪れた指宿市で、私は衝撃を受けました。

指宿…　といえば、日本の中でもなかなか有名な温泉地。
そして、「指宿駅」はその市の中心地！　…と思って電車を降りてみたら…

f:id:taichiw:20090926121453j:plain

ザ・シャッター街。
この当時25歳だったのですが、恥ずかしながら、このとき自分の人生の中で初めて「シャッター街」を見たのです。*1

このときの自分に訪れたショックは結構凄まじく、
「何が地方を元気にだ。これが地方の現実だ。自分は何もできていない。じゃあ、一体何ができるんだろう…」
と感じたことを今でも思っています。


あれから10年近くが経ちました。
上の体験をや思いを、日々意識しながら仕事している…　と言ったら大嘘になります。

ですが、ふとしたきっかけで思い出し、自身が仕事を通じてやりたいことの一つとして、思い返すことがあります。

今日はそんな日でした。

*1:厳密にはそれ以前にもどこかで見ていたのかもしれないけど、認識していなかった

36歳時点で「マネージャー」というものに対して思うこと

マネジメント 日頃思ってること

今日の記事は日記というか後で自分が読み返すための、雑記要素強めです。チラシの裏。

はじめに、背景

  • 今年の6月で36歳になりました。歳男です。
  • 今年の4月に、弊社内で「マネージャー」と呼ばれている役職になりました。それ以前は「リーダー」または「アシスタントマネージャー」と呼ばれる職責を約5年間、3チームに渡ってやらせてもらいました。
  • つまり、35歳にエンジニアからマネージャーに転身したことになります。35歳定年説ってフィクションだと思ってたんですが、ある意味ガチでそのレールの上をいっております。

マネージャーになって見えたこと

f:id:taichiw:20190629110047p:plain*1
あくまで私の観測範囲内、弊社・弊部署内で数ヶ月の間に感じたことです。

  • 突き詰めていくと、メンバーの成長を作り出すことこそが、マネージャのもっとも優先順位の高い仕事（のような気がする）
    • もちろんその先には組織としての成長とか、そもそも成長自体が組織が目指している遠い「月」に行こうとするための手段であったりとかはするんだけど…
    • この辺になると手段と目的ってループしてる気がする。実現したい世界があるから働いてるんだけど、一方で「働く」って言うコト自体がそもそも「生きる」とか「自己実現」とかと等価に近かったりするので*2…。

気づいた自分の中での変化

  • 以前、リーダーをやらせてもらっていたときは、自分よりスキルの高い人や経験の高いメンバーに対して、「申し訳なさ」「やりにくさ」「自分がリーダーですみません」みたいなのが正直あった。
  • 今回、マネージャになって、同様に自分より「上」のエンジニアと相対したときに、以前ほど気まずさのようなものを感じなくなっていた。

自己分析してみると、この変化は、「マネージャという『ポジション』を受け入れた」のかなぁと思います。
SLAMDUNKのリョータがゲーム中に先輩たちに指示を出すように、点を取ること以上にゲームメイクすることを第一の自分の役割と捉えた。自分がそれをしなければチームとして点が取れることもない、と。
※実際にはプレーヤーではなく、監督である安西先生のほうが近い場面は多いのでしょうが。

同じように、チーム内で圧倒的に開発を進めるエンジニアである以上に、自分はそんなエンジニアの皆さんの育成を誰よりも考えている、チームの目指す方向について誰よりも考えている、
…という点について、もしかしたら、そう思えるだけの自信も、少しついてきたのかもしれません。

気づいた自分の中での変化2

  • ついほんの一年前ですよ。「ここに技術書とマネジメントの本があったら、技術書が読みたい」と言った自分がいましたが
  • いまはマネジメントの本を読みます。

一体、当時は何があって今は何があったんでしょう、私。
単に、直近の目の前の課題が違うだけかもしれません。

エンジニアリングを勉強しなくていいという話ではない

来年の今頃は「技術書読みたい」って言ってるかもしれません。
進路や自分のキャリアに惑う　というよりは、　ある程度のリーダー力　×　ある程度のエンジニア力　が自分の強みだと思っていますので*3、場面場面に応じて、両方を適宜伸ばしていく必要はあるのだと思います。

*1:原泰久　『キングダム』

*2:人によるので、万人がそう、とは思っていない

*3:この言い方だと、大概の人がそうな気もしますが