おいすブログ

random things

iPhoneの英英辞典がめちゃ便利

Spotlight検索(ホーム画面でswipe downして起動)で英単語を入力すると、suggestionにOxford Dictionaryが出てくると思うんですが、

f:id:oi5u:20180613181240p:plain

f:id:oi5u:20180613181241p:plain

これ、例文、派生語はもちろん語源まで載ってるし、 オフラインでも使えて早いので、かなり使える子です。 (ということにさっき気づきました。。)

ブラウザなどでテキストを長押し選択したときのコンテキストメニューからも、 この同じ辞書を呼び出すことが出来ますよね。 いつのまにか便利になったもんですなあ。

オンラインのときはSpotlightからそのままweb検索すれば Googleの辞書が表示されるので、

f:id:oi5u:20180613182058j:plain

より詳しい内容はここで見ることが出来るし、 音声を再生したい場合はここで再生できるし、 コロケーションを調べたい場合は検索結果を適当に眺めればOKだし、 スマホ最強ですね。

昔20$ぐらいで買ったCOBUILDの英英辞書アプリを起動する意味が ほぼなくなりました。。

COBUILD Advanced American

COBUILD Advanced American

  • 物書堂
  • Reference
  • $18.99

表丹沢 縦走の魅力

f:id:oi5u:20180611002418j:plain

時々山に登るんですが、 こないだは丹沢に行ってきました。

登山の目的

登山の目的には色々あると思うんですが、 自分は効率の良いトレーニングと気分転換を兼ねて登ってます。

荷物を持って歩くだけですが、超長時間の有酸素運動なので、 1回の登山で少なくとも3000kcalは消費してます。 時速8kmのジョギングを30分したところで240kcal、 もうちょっと強度を上げても400kcalぐらいでしょうから、 単純計算で、ジョギング7〜12回分の効果です。

でも山は危険

でももちろん山には危険がいっぱいなので、 調子が悪かったら無理せずペースを落としますし、 トレーニングの時はよく踏まれた登山道しか使いません。

山はワンチャンで遭難したり死んだりする可能性があるので、 自分の限界をしっかり把握し、事前準備と安全に留意することが重要ですね。 初心者のうちは、高尾山とか御岳山とかの初心者コースとかから始めるべきです。

登山の良いところ

私のような怠惰な人間だと、例えばジョギングを毎日の日課と決めても 「今日はやめとくか」となるポイントが毎日発生してしまうので、どうしても続きにくいのですが、 登山の特徴として、一度登り始めると下山まで基本的に逃げ場がなく、 そのポイントが基本的に発生しないので、とにかく最後までがんばれます。 他の人が登ってる姿を見ることによっても、励みになりますね。

しかも、景色の移り変わりや気持ち良い空気もボーナスでついてきます。 写真を撮ったり野花を愛でたりしても良いです。

意外とゲーム性がある

登山道にはコースタイムが大体決まっているので、 自分がどれくらいのペースで歩いたかとか、 同じコースを再度歩くのであればどれくらいタイムが縮まったかなどを励みにできます。 出発前にあれこれルートを考えるのも意外と楽しいし、 行動中も、浮き石があるガレ場とかザレ場でどう足を置いて登っていくか・下りていくかを 瞬間的かつ連続的に考えながら体を動かしていくのは、意外とゲーム性がある気が。

丹沢表尾根の魅力

丹沢はこれまでで一番多く登っているんですが、 中でも表尾根ルートが一番のお気に入りです。

おじいちゃんおばあちゃんが沢山登るコースではあるんですが、 距離も高度差もかなりあって、中級者以上向きの健脚コースです。

何が良いかと言うと、道中の変化がバラエティに富んでいて、 都心からのアクセスもそんなに悪くなく日帰りOKだし、 ピークハントの醍醐味が凝縮されたコースなんじゃないかと思います。

基本情報やルートはこちらを参照です。

秦野市観光協会−表丹沢登山ガイド:表尾根縦走コース

スタート地点であるヤビツ峠へは、秦野駅からバスで向かいます。 平日は朝1本しかないんですが、だいたい行列が出来てて積みきれずに臨時便が出ます。 バスはうねうねした山道を通っていくんですが、 ガードレールの外が切り立った崖になっていて、いつも怖いです…。

ヤビツ峠バス停から登山口までは平和な車道です。 この後いきなり始まる急登のための軽い準備運動ですね。 ヤビツ峠はバイク勢や自転車勢の人にも有名っぽいですね。

f:id:oi5u:20180611002603j:plain

これがヤビツ峠の登山口で、しばらくはきつい道が続きます。 それを乗り越えると、二ノ塔、三ノ塔とチェックポイント兼休憩地点が続き、 そのうち開けた場所に出て絶景が見れます。

f:id:oi5u:20180611004344j:plain

うっすら富士山もゲットできました。イケメンですね。

f:id:oi5u:20180611004505j:plain

道中、こんな木道があったり

f:id:oi5u:20180611002148j:plain

こんなハシゴがあったり

f:id:oi5u:20180611003820j:plain

こんなクサリがあったり

f:id:oi5u:20180611004047j:plain

こんな草ボーボーの区間(通称藪漕ぎ)があったりして、 ちょっとしたアスレチック感覚が楽しめます。 (安全には注意!)

上りのゴール地点である塔ノ岳での風景は、ぜひご自身の目で!

下りは、大倉尾根を通るのが一般的です。 通称バカ尾根と呼ばれていて、ひたすら長くてわりと単調...。

とはいえ、迷うことのない一本道でチェックポイントも多く、 安全で比較的歩きやすい道です。 疲れた体で頭をからっぽにしてひたすら下るのも乙です。

大倉バス停は登山者のターミナル的な場所で、バスの本数も多め。 トイレや靴を洗う場所があるので便利です。

その他

丹沢は山深くて、いろんなルートや楽しみ方が考えられますね。 鍋割山に行って鍋焼きうどん食べるのも美味しいし、 もっとストイックに行くならさらに足を伸ばして丹沢山蛭ヶ岳目指すとか。 蛭ヶ岳まではまだ行ったことがないので、近いうちチャレンジしたい!

クレジットカードの番号を暗記する

f:id:oi5u:20180607115312j:plain

オンラインショッピングとか、 サブスクリプション系のサービスを契約したりとかって、 みなさんどれくらいの頻度でしてますかね。

私は仕事柄、結構な頻度でしているので、 その度にクレジットカードの番号を入力させられます。 残念ながら、paypalその他の決済方法が使えることは少なく、 履歴を一箇所にまとめたいというのもあって、 だいたいクレジットカードです。

なので、クレジットカードの番号を暗記することを10年ぐらい前から始めたのですが、 これによってオンライン決済でのストレスが格段に減りました。

いちいち財布からカードを取り出して確認する必要がないので、 セキュアですし、職場から仕事中にちょこっと買い物するときとかも便利です😈

覚える要素としては

  • 16桁の番号
  • 有効期限(YYYY/MM)
  • 裏面の3桁の番号

と結構ボリュームがあるのですが、 暗記が苦手な私でも、適当に語呂合わせを作って 何も見ないで入力して分からなくなったら確認してってのを繰り返してると、 10回ぐらいで覚えられました。

途中で1回メインで使うカードを変えてて、 番号から何からすべて変わってしまって覚え直しになったのですが、 なんとかなっています。。

同じカードを使っていれば変わる部分は有効期限だけなので、 10年ぐらい余裕で役に立ちます。 クレカ使う機会が多いのであればやって損はないと思います🙂

エンジニアの転職について

f:id:oi5u:20180605174121j:plain

現場は深刻なエンジニア不足

2018年現在、ソフトウェアエンジニアの転職は完全に売り手市場だと思います。

というのも、数ヶ月前にいた会社では 同僚のエンジニアが辞めまくっていて慢性的な人手不足で、 エンジニアとして採用活動にも時々関わっていたので、 買い手側の立場としてもかなり苦労した経験があります。

大量の転職エージェント、フリーランス案件紹介会社の存在

その会社員時代、自分のところにもLinkedInやWantedly経由で 転職エージェントからのメッセージやフレンドリクエストが 頻繁に届いていました。

ヘッドハンティングのお知らせ」「魅力的な経歴が目に止まり」などと甘い言葉をかけてくるんですが、 これは別に自分がエンジニアとして何か特別だったからという訳ではなく、 単純に世の中の現場にエンジニアの数が足りておらず、 それに反して転職エージェントや紹介会社の数がめちゃくちゃ多いからです。

特にlinkedInにはびこるエージェントの多くは、 IT系の案件を担当していてもエンジニアリングの知識はほぼ無く、 手当たり次第にメッセージを送ってくるので、 スキルセット的に全然的はずれな会社に紹介しようとしてきます。 (フロントエンドやりたいって書いてるのに、サーバサイドのポジションを紹介してきたりとか)

もちろん、きっちりした仕事をされてる方もいるとは思いますが、 あまり専門知識や初期投資を必要としないビジネスなので、 これほどまでに人材会社が増えているのだと思います。

参考: 日本は狂ってる 派遣会社の会長=経済戦略会議の委員 | 黄金の金玉を知らないか?

転職エージェントがしてくれること

こんな感じでしょうか。

  • 応募先を人力検索してリストで送ってくれる
  • 志望動機などの作文の手伝いをしてくれる
  • 話し相手、面接の練習相手になってくれる
  • マージンを抜いてくれる

私も過去2度の転職をエージェント経由でやったことがあるんですが、 エンジニアの事情や適正は、正直、同じエンジニアにしか分からない部分が大きいので、 結局自分の目と耳と足で調べて探して考えるべきという結論に至りました。

もし現役エンジニアの転職エージェントがいて、 自分と専門分野や指向性が近いようだったら相談してみたいと思いますが、 そんなことはまず無いので…。

相手方のエンジニアや一緒に働くことになる方々とじっくり話をするのが当然の近道で、 よっぽど入りたい企業でもなければ、 エージェントと二人して小手先の準備を頑張ってもしょうがないかなと思います。 エンジニアに人気があって"イケてる"な企業って、 そういうことを重視しない傾向にあると思うので、なおさらですね。

私も今後もし会社員に戻るとしても、 受け身になって紹介メールを待つのではなく、 こちらから気になる企業に直接応募して、 相手の会社の方とじっくり話をすることに 時間をたくさん使いたいと思っています。

フリーランスの案件紹介会社

自分が関連ワードでよく検索してるからってものありますが、 最近Web広告でよく見かけるようになって、 急激に増えてきたなあっていう印象があります。

私自身は、昔に登録だけして実際に利用したことはないのですが、 やはりこれも転職エージェントと同じようなものだと思います。

紹介会社を介して契約を行うケースが多いと思うので、 クライアントさんとのお金や契約周りの手続きを代わりにやってくれるらしいですが、 彼らに支払う手数料がそれに見合った金額なのかどうかというのは きっちり吟味する必要がありますよね。

上の記事の情報では少なくとも20%とか30%とかっていう話なので、正直フェアではないですね。 自分が登録したところでは額面で日給2〜3万円みたいな相場だったので、 まあ相当抜かれてると思って良いかと思います。

また、わざわざ紹介してもらわなくても、エンジニアが不足している昨今なので、 気になる企業に自分から声をかけていけばすぐ案件が見つかると思いますし、 間に人を入れないほうがやり取りもスムーズでスピード感出ます。 自分の時は、週5日客先常駐みたいな案件が結構あって、 それってフリーランスで働く意味なくない...?って感じでした。

企業側にいた経験からも、担当者が受ける印象として、 「会社に紹介されたので来ました」っていう人より 自社に興味を持って自分から応募してきてくれた人のほうが志望度は強いはずですし、 自発的・能動的に動いてくれそうに思えて、あまり悪いことは無いと思います。

おわりに

テクノロジーの力で、あらゆることの中間マージンや取引コストは 昔に比べてもっと減らせるはずだし、減らすべきだと思うので、 テクノロジーに一番近いエンジニアからまずそれを変える動きが生まれたら良いなあと思います。

こういう、ブロックチェーンを使った働き方改革のプロジェクトみたいのもあったりしますしね。 Colony: A platform for open organizations

フリーランスになりました

f:id:oi5u:20180605161749j:plain

しばらくブログの更新をサボってしまっていたのですが、 3月に会社員エンジニアを辞め、 4月からいわゆるフリーランスのエンジニアになりました!

正直、会社員時代も比較的自由にやらせてもらってはいたのですが... 通勤時間や無駄な会社行事への強制参加が無くなり、 一緒に働く相手を選ぶことができるようになったので、 ざっくり言うと、とにかくストレスが減って使える時間が増えましたね。

会社を辞めてから2ヶ月ほど経ち、色々なことが落ち着いてきました。 家事や英語の勉強に使える時間が増えて、 自己投資や身の回りのことをしっかり出来ている安心感から、 仕事への集中力や効率も心なしか上がった気がします。

ただ、人と会う機会が激減したので、 これから社会性を失わずに健全に生きていけるのかどうかが今後の課題です。。 オフ会(勉強会という呼び方が嫌なのでこう呼ぶ)にももっと参加しようかなと思いつつ、 こういった情報発信にもある程度やっていきたい今日この頃です。

特に開業にあたっては、MF会計の使い方、青色申告のための会計処理、社会保険制度などなど、 色々と調べて学ぶことが多く、このあたり、また追って少しずつ情報発信していきたいです。

アイドルは代名詞を避ける

f:id:oi5u:20180113014630j:plain

アイドルには全然詳しくないんですが、AKB48とか欅坂46の人たちがテレビに出てしゃべってるのを見ると、会話の中で不自然なほどに自分たちのグループ名を呼ぶ印象があって。

どういうことかというと、例えば極端な話ですが、

AKB48の○○です。私たち、昨日海で撮影したんですよ。□□ちゃんは泳ぐのが苦手なんですが...」

っていう説明をするとして、

AKB48の○○です。昨日、AKB48のメンバーで海に行って撮影したんですよ。□□ちゃんはAKB48のメンバーの中でも泳ぐのが苦手で...」

ぐらいの勢いで、話の中にグループ名を無理やり盛り込んでくるんです。複数人で順番に自己紹介するときも必ず、

AKB48、チームXの○○です」

AKB48、チームXの□□です」

AKB48、チームXの△△です」

といった具合に、所属名を省略しない。

秋元康氏なんて業界のど真ん中に何十年もいると思うので、プロデュース業に関しては手練手管の限りを尽くした緻密な計算があるはずで、これ、間違いなくそういう風に教育されてるはず。

テレビをつけっぱなしにしている人は多そうなので、音であれば画面を見ていない人にも聞かせられるため、とにかく耳に残ることが重要だと思われる。選挙カーが候補者の名前をひたすら連呼するように、興味がない人でも、とにかく名前が耳に残るように、何度でも名前を呼ぶ。私、AKB48に全然興味はないのに、なぜか何人かは名前を覚えてしまっているし。

それはまあそれとして良いんだけど、なんとかこの技術を庶民の社会生活に応用できないかと考えた。

一般人のケース

目的

  • 職場などで引き立てたい同僚や部下や上司がいる
  • 自分たちの組織をアピールしたい

場面

  • 目上の人物との会話
  • 大勢の前でのプレゼンテーション
  • ドキュメント、プレゼン資料

などで、代名詞を避け、その引き立てたい固有名詞を極端に不自然にならない程度に盛り込む。固有名詞をより印象づけて、相手の潜在意識に働きかける🤤

👍「この資料は同じ□□プロジェクトのメンバーの○○が作りました。○○によると、ここの計画は...です。□□プロジェクトとしては、次の計画は...」

👎「この資料は同じプロジェクトのメンバーが作りました。ここの計画は...です。我々としては、次の計画は...」

まあ

この程度のことは口が上手い人や営業の人なんかは無意識にやってそうだし、そういう系の本に普通に書いてそうですね。

初対面の人や仲良くなりたい人と話すときに、相手の名前を呼んでから話しはじめるのが良かったりするのに似ている。相手が初対面の場合、相手の名前を覚えやすくもなる。これをテーマにひたすら掘り下げるとまた新書1冊出せそうです。

日本の(技術書の)ジレンマ

f:id:oi5u:20180110223150j:plain

技術書というのが 「ソフトウェア/インフラエンジニアが読むフレームワークや言語についての本」 だと仮定すると、

  1. 高度な内容になればなるほど、読者とニーズが減るので、入門者向けの内容になりがち

  2. 入門者向けの内容であれば、フレームワークや言語の公式サイトにあるGetting Startedのドキュメント(英語)で必要十分

    • その内容は、トップレベルのエンジニア集団が自分たちの技術の普及を賭けて練り上げたもの(のはず)なので、クオリティはだいたい高い

    • 逆に言うと、それが貧弱だったりわかりにくかったりする技術は信頼性に欠くので、あまり学ばないほうが良さそう、本気度からくる将来性が低そう

  3. 英語ドキュメントに抵抗が少ないエンジニアは最初から公式サイトの1次情報を見て学習し、足りない情報は英語のブログや動画から勝手に補完していく

1~3から、英語が苦手なエンジニアが入門時に読む感じの本が多く出版される。

日本はマーケットが大きくて本から簡単に情報が仕入れられるので、 入門者が日本語の情報に依存し、日本語の2次情報や3次情報を中心にした情報交換サイクルが生まれる。 結果、英語圏のコミュニティとの間でズレがどんどん拡がり、ガラパゴス化が発生。

また、

  • 日本発の技術がスタンダードになっている例は少ない
  • オープンソースプロジェクトのメインのcontributerだったり英語で議論に参加していたりするケースは少ない

という点から、「著者がそのフレームワークや言語を開発する側ではない」という仮定を置くと、本の内容は、

  • 元々英語で書かれている公式ドキュメントの翻訳
  • 自身が開発経験から学んだノウハウ
  • お手製サンプルコード

などになりがち。

そうすると、

  • 英語から日本語へ変換する労力と時間
  • 誤訳リスク
  • (レビューがあるとしても)入門的な内容なのに開発元から遠い人物の主観が混ざる

っていう副産物が生まれ、ここに、本というフォーマットそのものが持つ

  • バージョンアップや業界の変化に追従できずにすぐ内容が古くなる
  • 間違いがあったときに迅速な修正が難しい
  • 手に入れるのに金がかかる
  • それに関して質問したり意見を書いたり引用したりがWebに比べて難しい

などの欠点も倍率ドン。

なので、業界の技術レベルの底上げに貢献するための技術書なのに、 ニーズを勘案して内容を決めていくと、 長期的に見て全体があまり良い感じにならない、 というのがジレンマかなと思います。

名著はたくさんあるのでもちろん例外はあると思うけど、この図式に当てはまらなさそうなのは、

などですかね。

入門ドキュメントぐらい気合で読む覚悟と根性が無いと日本の開発者に明るい未来はないと思うので、 正直しんどいけどみんなでがんばっていこうねって思います。