Sending raw XML using savon(Ruby gem) without WSDL file
Let's say you are a software developer using Ruby. If you want to work with the SOAP API, it's best to use savon. Basically, savon assumes that you have a WSDL file. However, unfortunately, sometimes you can't get the WSDL file from the API provider. You won't be able to find a way to write to send the raw XML. In such a case, the following sample code may help you. The first argument can be any option. Try it!
転籍して3ヶ月経った
先日のエントリで書いたように、5月1日に転籍をした。 kousy.hatenablog.com グループ内転籍なので試用期間はないが、3ヶ月経って今の環境に慣れてきたので感想を書いておく。
フルリモートでの転籍
転籍前はリモートワークの制度はなかった。 2月から徐々にリモートワークに移行していた。 3月は丁度、前の会社で最後のプロジェクトの終盤だったので、リリースに向けての修正などのタスクが多かった。 幸いプロジェクトの立ち上がりの時期のようなコミュニケーションコストが高くなる時期ではなかったので、移行しやすかった。 そして、5月にリモートのまま転籍した。 転籍後に部ごとのミッションを各部のメンバーで話し合って制定した。 Google Meetで繋いで数十人で行うワークショップは初めてだった。 意外と成り立つということに驚いた。 Jam Boardのカードに付箋でアイデア出しをするような感じで書き出してまとめていった。 日頃の振り返りもJam Boardでやるとオフラインでやっているとのあまり変わらないのでオススメ。 以下は週次の振り返りのボードの実際の画像。
転籍して最初のPJは全てリモートで進行し、完了した
転籍直後は前の会社で働いたことのあるメンバーでのプロジェクトが始まった。 立ち上げからリリース、リリース後の振り返りまで全てがリモートで行われた。 プロダクトオーナーとは一度もリアルで顔を合わせることなく、無事にPJが終わった。 プロダクトオーナー、スクラムマスター、開発者（エンジニア2、デザイナー1）でスクラム風のチームだった。 全員がフルリモートでもスプリントを重ねるごとに関係性の構築が出来た。 チームとしての問題点を洗い出して改善していけた。 七夕の日にリリースして無事終えた。
転籍後、専門領域ごとに部署が決まっていることのメリット
部署ごとに異なる技術領域の専門性を高められているのが、メリットだと思っている。 転籍前は、ほとんどの人がサーバーサイドエンジニアという開発組織にいた。 Ruby, Ruby on Railsについては深く学べるが、それ以外の技術については限定的にしか知ることが出来ない状態だった。 今はSRE、アプリエンジニア、サーバーサイドエンジニアなどそれぞれが1つの部署として別れている。 部署ごとに専門的な知見を貯めていっている気がする。
転籍後、開発者が増えたことによるメリット
組織のエンジニアの数が20人くらい増えた。 それぞれの人から学ぶことがある。 新規のプロジェクトの立ち上げが頻繁に起きているので、GitHubにリポジトリが作られてから、ライブラリ整備、アプリケーションの骨組み作りなどが爆速で行われている。 勿論しっかり設計も考えられている。 こういうのを間近で見られるのとても学びになる。 たまにコードレビューで関わることも出来るので、本を読んでも学べないような実際に使ってみてどうだったという判断や、技術に関する思想を学べる。
エンジニアリングだけでなく、デザインについても多くを学べる。 プロダクトを作り始める時にしっかりとコンセプト、ユーザー体験について考えて意見を出しているプロジェクトはブレずに良いものを作っていける気がする。
まとめ
会社が変わってリモートのままでも、相変わらず成長し続けている。 学んでばかりではなく、社会に価値提供出来ている実感も少しある。 新しいプロジェクトはこれまでとは全く違う開発体制、全く異なるプロダクトで戸惑うことも多いが無事に終えたらまた記事を書く。
HHKBを買った
アメリカ西部のカウボーイたちは、馬が死ぬと馬はそこに残していくが、どんなに砂漠を歩こうとも、鞍は自分で担いで往く。馬は消耗品であり、鞍は自分の体に馴染んだインタフェースだからだ。いまやパソコンは消耗品であり、キーボードは大切な、生涯使えるインタフェースであることを忘れてはいけない。［東京大学 和田英一 名誉教授の談話］
経緯
2年くらい前馬と鞍の例え話に胸を打たれて以来欲しかったが、外付けのデバイスをなるべく使わずに道具はシンプルにしたい、というこだわりを持っていたので敬遠していた。 しかし、素晴らしいものを使って得られる体験というのは代え難いのかなぁ、と思って買ってみることにした。 最後はしゅうまいさんからのひと押しでしたw
買っちゃいましょう！最初はLiteから…と思って中途半端な物を買ってしまい後悔したので最初からProfessionalにするのがオススメです！
— syumai (@__syumai) July 26, 2020
行った設定
とりあえず最低限のみ。
良いところ
- 打鍵音
- キーボード自体の質感
- 合理的なキー配列に強制的に慣れることができそうなところ
悪いところ
- キーボード自体に高さがあるので、パームレストがないと手首の筋肉が疲れる感じがする
- Fnキーを押しながらでのカーソル操作はやはり慣れない
- 日本語と英語の変換にcommand + spaceを使っているが、やりづらい（MacbookではCaps Lockに割り当てていた。。）
まだまだ不慣れで使いづらいところもあるが、数ヶ月して慣れたタイミングで再びレビューを書いてみようと思う。 外付けキーボードなのでPCを置く台を使って、外付けのマウスを使うのもありだが、とりあえずは変数を1つに固定するという意味で尊師スタイルにして使うことで効果を測定していこうと思う。 尊師スタイルでMacbook本体のマジックトラックパッドを使っていると、パームレスト置けない問題は改善したほうが良さそう。
開発環境のrails serverにAndroid端末でアクセスする方法
何番煎じだよ感ありますが、自分用メモ。
必要な物
Chromeのアドレスバーに以下をコピペする。
chrome://inspect/#devices
クリックする
ポート番号を入れる
あとはAndoid端末側の設定をする
ビルド番号のところを複数回タップすると、開発者モードになる。裏技感。
既に開発者モードなので、このような表示。
あとはPCとケーブルで接続して、USBデバッグを許可して、見たいページをAndroid端末で見るだけ。 たまにUSBデバッグモードにならないときは、Android端末を再起動する。 Android Studioのエミュレーターでも大体のことは確認できるが、実機使いたいって場合はこれでいいのでは。
気が向いたら、エミュレータでLINE使いたいときに既に持ってるLINEアカウントでログインすると、トーク履歴消えるよ！って話書きます。
株式会社みんなのウェディングを退職しました
5月からは同くふうグループの事業会社である株式会社Da Vinci Studioで引き続きエンジニアとして働きます。 転職と見せかけて、グループ内転籍というオチです。 da-vinci-studio.com なので、手続き上一旦退職するだけで、オフィスの場所も変わりませんし、一緒に働く人もあまり変わりません。 席の場所すら変わりません（最近はWFHなので、オフィス内の席という概念もない、、）。
以上、退職エントリってやつを書いてみたかっただけでしたw
