20日目 シリコンバレー戦略 編「How to become good enough a programmer to work at a top-notch Silicon Valley company? What kind of things do you need to know as a minimum? Any other advice on getting there」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 20日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。20日目の今日は、シリコンバレー 戦略 編です。

何はともあれ Google に聞いてみた

シリコンバレーで働くにはどうしたらいいか、Google で検索すると次の記事がみつかった。

https://www.quora.com/How-do-you-become-good-enough-a-programmer-to-work-at-a-top-notch-Silicon-Valley-company-What-kind-of-things-do-you-need-to-know-as-a-minimum-Any-other-advice-on-getting-there

「一流シリコンバレーの会社でプログラマーとして働けるくらい、いいプログラマーになるにはどうしたらいいのか。最低限どんなことを知っていればいいのか。それに関するそのほかのアドバイス。」

最適。ということでさしあたって翻訳。

まとめ

大きく分けて三つのスキルが必要

  1. 課題を技術的にどう解決するかを道筋を立てる Conceptualization
  2. コードを書いて実装する Implementation
  3. 最小限のリソースで素早く動くようにする Optimization

どのようにして

  1. 仕事を通じて獲得する
  2. 期限内に、漠然とした課題を解決する実装をし、
  3. さらに改善する

結局のところ

  1. 特定の技術の知識を問うているわけではなく、
  2. コンピュータサイエンス全体の理解を元に、
  3. 新しい問題を解決するために学習し、
  4. 自分の能力を高めることができるのか
  5. そしてどうやって問題にアプローチするのか。

ということ。

How to become good enough a programmer to work at a top-notch Silicon Valley company? What kind of things do you need to know as a minimum? Any other advice on getting there

There are two questions embedded here:

これには、本質的に二つの問いが内在している。

  1. How do I become a good enough programmer to be hirable anywhere
  2. What does it take to be hired at a top-notch Silicon Valley company
  1. どうすれば、どこでも雇われるほどの良いプログラマーになれるのか
  2. シリコンバレーの一流企業に採用されるためには何をすればいいか

And there is an assumption that being a top-notch programmer is a sufficient pre-requisite to be hired …

この前提として、一流のプログラマーになることができれば、雇われるのに必要な前提条件を満たすことができる、ということがある。

Let’s tackle question (1): Becoming a great programmer.

まずは一つ目の問いから取り組んでみよう。偉大なプログラマーになる。

Programming has three distinct elements. There is conceptualization of an idea, there is implementation of an idea and there is optimization of the implementation.

プログラミングには、三つの独立した要素がある。まず idea を概念化すること。そして idea の実装。最後に実装の最適化。この三つだ。

Conceptualization is the art of being able to translate some fuzzy goal and turn it into something that can be describe in terms of discrete technology blocks. Some people call this architecture, some people call this design, some people call it coding, and what you call it is less relevant than being able to go from “I wish I could do X in the real world” and imagining a way of doing it using technology.

概念化とは、漠然とした目的を解釈して、個別の技術的な課題に切り分ける技術だ。これをアーキテクチャーと呼ぶ人もいるし、デザインと呼ぶ人もいるし、コーディングと呼ぶ人もいる。どちらにせよ「X ができればいいなあ」という希望から始めて、これをテクノロジーを使って実現させる方法を模索することが、概念化だ。

For example, someone at Uber conceptualized the system that made it possible for folks to request a limo anywhere by leveraging mobile fones and cloud infrastructures.

例えば Uber のメンバーは人々がリムジンをどこへでも携帯電話とクラウド上のインフラを使って呼び出すことを可能にした。Uber はこのシステムを概念化したといえる。

Implementation is the art of taking a conceptualized idea and turning it into bits and bytes that run on code. This is a profoundly useful skill and highly portable. What’s important to realize is that there is the specifics of programming languages – how to write code in C++ and the meta-issues of programming – how should I structure my code for efficiency portability and scale of feature development and performance. This requires a deep understanding of computer science fundamentals and real technology and experience with large software systems and large teams and small teams and being able to make the right levels of tradeoffs.

実装は、概念化された idea を、コードとして動く bit や byte 、つまり文字列に変換する技術だ。これは深淵で価値ある技術であり、非常に可搬性が高い。認識しておくべく重要なこととして、各言語には特徴があるのだ、ということがある。C++ でコードを書く方法をわかった上で、さらにメタレベルのプログラミング言語について理解が必要だ。どのようにコードを構造化して、可搬性が高く、そしてスケールさせることが可能な状態をつくりだし、機能開発とパフォーマンスの改善をしていくのか。そのためにはコンピュータサイエンスの根源に関して、かなり深い理解が必要だし、実際の技術に関しても深く理解している必要があるし、大規模開発と小規模開発の両方の深い経験が必要だ。また最適な手法を決められるようになる必要もある。

The key aspect of implementation is the ability to make a compromise between date and quality and design and come up with a brilliant solution instead of a shitty compromise. Most engineers given enough time can come up with a brilliant solution, but when you constrain them they come up with shitty compromises.

実装における重要な側面は、妥協点を見つける能力だ。締め切りと品質とデザインの間で、輝く解決策を見つける。くだらない妥協策ではなく。十分な時間を与えられればエンジニアは誰だって最高の解決策を見つけることができる。しかし制限を与えると、くだらない妥協しか思いつくことしかできない。その中で最高の解決策となる妥協点を見つけなくてはいけない。

Optimization of the implementation is a different skill set, and it’s about understanding why something takes up as much time and resources and being able to preserve correctness while reducing time or resources or both.

実装の最適化は、これもまた今までの技術とは異なった技術で、あるプロセスになぜ時間がかかり、そしてリソースを消費するのかを理解し、時間もしくはリソース、もしくはその両方を減らしながら正常な動作をさせる技術だ。

When a top-notch silicon valley company is looking to hire someone they are looking for someone who has skills in all of these areas.

一流のシリコンバレーの企業は、これら全ての領域のスキルを持った人物を探している。

They are looking for someone who can translate fuzzy ideas into technology bits and pieces that can be implemented. They are looking for someone who can translate the implementations bit into things that ship on time and are desirable in the market. They are looking for someone who can make things go faster.

彼らが探しているのは、漠然としたアイデアをコードで実装できる人物だ。そしてその実装を時間内におこない、市場で価値があるものにできる人物だ。探しているのは、物事をさらに早く進めてくれる人物だ。

If that’s the skill set, how do you go about acquiring that skill set?

さてこういった技術が必要だとした場合、どうやってこれらを身につければいいのだろう?

First of all, the very short answer is to start working on those problems and demonstrating how you can solve each one of them.

まずは、簡潔に言えば、こういった問題に取り組むことを始めることだ。そしてこれらの問題をどう自分が解決するかを示すことだ。

If you have a job, and want a better one, take on projects that are fuzzy and figure out how to turn them into real things that can be implemented, demonstrate how you can implement things better, with higher quality and on time. Take on optimization projects and improve performance and maintain quality.

職業プログラマーで、さらに向上したいと考えているのであれば、早速プロジェクトに取り組んで、漠然とした問題を理解して実装し、さらにそれをどのように改善するか、しかも高いクオリティを持った上で時間内に終わらせるか。それを実務を通して示そう。さらにプロジェクトを最適化し、パフォーマンスを改善し、クオリティを保つ必要もある。

If you’re in school, then find problems you find interesting and try and solve them. Deliver your coursework on time with high quality. Deliver your projects in the same way. Look for ways to make code go faster that is meaningful. Engage with the broader technology community on the internet. Do it with respect and politeness.

もしまだ学生なのであれば、自分が関心のある問題を見つけて、それを解決しよう。課題を締め切り内に、しかも質の高いものを提出しよう。自分のプロジェクトでも同様に進めよう。コードが迅速に動くようにする方法を探すのも価値がある。インターネット上の幅広い技術コミニュティに関わろう。尊敬と礼節をもって。

If you don’t know how to code, and you’re trying to start a new career, then go to school. And if you can’t then you can still start, but it will be harder.

コードを書く方法を知らず、新しいキャリアとしてエンジニアを始めたいのであれば、学校に行こう。もしそれができないのであれば、それでも学習を始めよう。ただしそれは学校に行くよりは難しくはある。

At the end of the day, any company that is great is going to ask you questions that are going to probe those areas, and learn what you learned and understand how you thought about the problems.

結局のところ、企業が問うているのは、彼らのもっている課題を解けるのかということだ。何を学んできてかを確認し、課題についてどのような考え方をするのかを理解したいのだ。

But a really great company isn’t really interested in what you learned, and what your actual skills are, what they are really interested in is how you learned and how you grew and how you approached problems.

ただ、彼らは、あなたが何を学んできたかには興味がない。それから実際の今のスキルがどうかでもない。興味があるのは、どのようにして学習をするのか、そして自分を成長させるのか。そして課題にどうアプローチするのか、ということなのだ。

Great companies understand that they need to hire people who can adapt, can learn and understand the principles of programming as I outlined them.

彼らが探しているのは、状況に適応し、プログラミングの原則を学習し理解できる人間なのだ。これは今まで私が書き出してきた通りだ。

Yes there is a minimum bar of skill, but any school should get you there.

最低限必要な技術のレベルというのはあるが、そこまで学校は引き上げてくれることはない。

And sometimes you can’t get the job because you need specific skills for that job because they can’t afford the ramp up time, and getting those skills is about you finding projects that map to those skills.

仕事に必要なスキルをもっていなくて、企業がそのスキルを勉強させてあげる時間がない場合もある。それが理由で採用されないこともあるだろう。そういう場合には、スキルを身につければ、そのスキルが必要なプロジェクトにはつくことができる。

And if a company seems overly pre-occupied with your specific skills, then there is a danger that the company isn’t approaching hiring in the right way and it may not be the greatest place to work anymore.

もし企業があなたの持っている特定の技術に以上に関心を示しているとしたら、その企業は適切な方法で人選をしていないという危険性があるし、そうだとすれば働く場所としてはよくない場合もある。

まとめ

大きく分けて三つのスキルが必要

  1. 課題を技術的にどう解決するかを道筋を立てる Conceptualization
  2. コードを書いて実装する Implementation
  3. 最小限のリソースで素早く動くようにする Optimization

どのようにして

  1. 仕事を通じて獲得する
  2. 期限内に、漠然とした課題を解決する実装をし、
  3. さらに改善する

結局のところ

  1. 特定の技術の知識を問うているわけではなく、
  2. コンピュータサイエンス全体の理解を元に、
  3. 新しい問題を解決するために学習し、
  4. 自分の能力を高めることができるのか
  5. そしてどうやって問題にアプローチするのか。

ということ。

19日目 目指せシリコンバレー 編「世界を目指す」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 19日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。19日目の今日は、目指せシリコンバレー 編です。

世界を取りに行きたい

日本の一番になるよりも世界にいく方がイージーだし、しかもそっちのほうが面白そうなので、来年は日本を出てエンジニアをやりたいと思います。

そのために英語での面談のための資料も読んでいますし、英語リスニングも毎日やっています。

具体的には、各社に英語で応募のメールを送って、面接にパスすればいいとのことなので、レジュメを作って応募しないと!という感じです。

まだ漠然としているので、この辺りが必要じゃないのか、というポイントを列挙して今日は終わりにします。

  • 応募先の会社のリストアップ
  • 申し込みの履歴書的なものの英文での作成
  • 英語での面接対策
  • 行ってから生活に不便しない英語力を身につける(オンライン英会話)
  • エンジニアとしてのスキルのアップ(ただこれはどこまでも無限にあるので必須ではないかも)
  • 海外エンジニアのコミュニティへの所属
  • 海外で働いているエンジニアにコンタクト

このあたりかなあと思ってます。とにかく、応募しないと始まらないので、まずは応募なのかなあと。英語力やエンジニア力は、無限にやることはあるので、それが完成するのを待っていたら人生終わってしまいます。とはいえ、仕事でいくのだから、最低限の証明をする必要はあるかなと。ただ、やっていくなかで最低限がどれくらいなのかは見えてくるはずなので、あまり気にしても仕方がない。

リーンスタートアップという考え方がありますが、これを僕は結構気に入っているので、シリコンバレー編もこの戦略にのっとって進めて行きたいと思います。つまり、最低限何を達成すればいいのか、ということを明確にして、トライしていく。トライしていく中で、問題があれば修正する。と言う方法です。

明日からは、この戦略と行動について書いていきます。

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 19日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。19日目の今日は、目指せシリコンバレー 編です。

18日目 Chrome 開発者ツール 編「開発者ツールを征するものが、開発を征する」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 18日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。18日目の今日は、仕事としての Chrome 開発者ツール 編です。

開発者ツールを征するものが、開発を征する

どこまで自分の中で正確にコードを書いたとしても、最後はブラウザがどう解釈するのかで挙動が全て決まる。それがフロントエンドの世界の特徴だと思います。どんなに優秀なエンジニアでも IE 自体の挙動を変えることはできず、彼に従うしかありません。そのため開発者ツールを使いこなして、ブラザ内で起きていることの現状を正確に把握することこそが、開発の基盤になるということを痛感しました。

大きく分けて DOM Element (HTML, CSSの担当する領域) の状態と JavaScript の状態に分けられる

http://better-than-i-was-yesterday.com/google-chrome-devtool/

Chrome 開発者ツールでは、主に DOM Element の状態と JavaScript の状態の、二つの領域が重要だと感じています。(もちろんパフォーマンスやネットワークのタブなども重要なのですが、まずはこの二つの領域で正常な挙動が達成されなければ、それらのタブを確認するまでもありません。そいうう意味において。)

Elements タブで HTML と CSS を。Console と Source タブで JavaScript について確認します。

また Elements タブ内の EventListers は JavaScript の領域とつながっています。同様に Console のコマンドや、Source の EventLister Breakpoints などは Element と繋がっています。

ので、基本的には Elements タブと Source タブの二枚を行き来しながら、console タブは esc キーを押して出てくる下部のタブでデバッグする、という形を自分はとっています。

JavaScript のデバッグについて

Source タブを使った JavaScript のデバッグは React 開発を業務にしてから初めて行いました。

今までのように自分で書いたソースのデバッグであれば、正直書いたソースを見直す方が早かったのですが、他人が書いた API が入り組んだソースの場合、やはりこの Source タブを使ったデバッグが有効だと感じています。というのも、どの値がどのタイミングで変わるのかわからないものがたくさんあるので、それはやはりデバッグしながら詰めていくしかないのかなと。刻々と変化する変数を、クリアーに見ていけるのは Source タブならではだなと。

今後

開発者ツールの使い方をまとめています。動画コンテンツも増やそうと思っています。レッツユーチューバー。

http://better-than-i-was-yesterday.com/google-chrome-devtool/

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 18日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。18日目の今日は、仕事としての Chrome 開発者ツール 編です。

17日目 仕事としての React 編「今フロントエンドで仕事を得るなら React が近道と感じた」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 17日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。17日目の今日は、仕事としての React 編です。

今フロントエンドで仕事を得るなら React が近道と感じた

React, Vue, WebGL 等々、様々なフロントエンド技術の領域がありますが、今フロントエンドで仕事を得るなら React が一番近道だと感じました。その理由は簡単にいえば案件が多いということです。

https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176

上記グラフは npm のダウンロード数です。npm ダウンロード数と実際に市場で使われている技術には一定の相関があるはずですから、三つの技術の比較の中で顕著に物量が多い React は、やはり仕事も多いのではないかと考えられます。2017年に仕事を探した際の実感も、この予想に一致していました。Vue や WebGL を指定した仕事よりも、React を指定した仕事の方が7倍くらい多かったです。

ただ、Vue や WebGL を使う案件が、ぼくのリーチできる範囲の外にある可能性もあります。ただそうだとしても、その状況は一部の人以外にとっては同じことだと思いますので、総合的にいって React のほうが案件が多いといえます。

自分は直近仕事になる技実を重要視している

どの技術を使用するか、もしくは学習するかの選定は、エンジニアにとって重要な意思決定な訳ですが、私はその指標として「直近で仕事になるのか」ということを一番に重要視しています。

なぜならエンジニアリングは私にとっては生業であり、生業の第一の目的は、要求される課題を迅速にこなすことで、対価を得る、ことですから、仕事にならないことはその範囲外です。(もちろん趣味としてのコーディングという要素が自分にないわけではないのですが、それよりも生業としてのエンジニアリングの割合が圧倒的に高いです)

また、仕事として使うのが一番技術を身につける近道だと痛感していますので、仕事として使う機会のない技術よりも、すぐに使う技術の方を優先することで、スキルが上がり、生業としての効率を大幅にあげてくれます。

生業としての効率が上がれば、空いた時間でさらに新しい技術にチャレンジする余暇ができます。

その技術で自分に仕事がこない物に関しては、自分にとってはオーバースペックな技術

また、すぐ仕事にならない技術に関しては「自分にとってオーバースペック、もしくは身の程知らずな取り組み」である可能性が高いと思っています。例えば今自分が AWS にかなりの時間を投資したとしても、インフラを構築する仕事は来ないと思いますし、できないと思います。反対に Node.js でサーバーを立てたり、REST API をつくる技術は、自分の仕事に直近含まれてくる可能性が高いの有効ですし、実際今よくやっています。こういったレベル感の技術が今自分が習得すべきものだと考えています。

React は自分にとってちょうどいいレベル

こういったことを考えると、React は本当にちょうどいいレベル感だったなと思います。まず根本的に今まで自分がやってきたフロントエンドという領域であり、HTML, CSS を書くという今まで自分がやってきた技術がそのまま有用するからです。そのうえで React の概念さえ抑えてしまえば、あとは調べながら実装できるレベル感。即仕事にすることができました。その結果、あとは業務で書いていけば自然と現代のフロントエンド開発にはキャッチアップできる目処が経ちました。

また React を軸に、サーバーサイド、非同期通信、テストツール、Docker 等のインフラ周りに触れる機会を、以前より圧倒的に増やすことができたので、技術的に学習する価値のある対象が、次のステップに進んだと言う実感があります。これらは React を仕事でやるまえには先ほど言及した意味でのオーバースペックだった技術です。やはり直近仕事になるところから抑えていくという戦略は有効だとおもいます。

次の展開

今使用しているものの、システム全体を一人で立ち上げられない技術に次のようなものがあります。これらを自力で全て実装できるようになると、次のレベルにいけるとおもうので、ここをおさえていきます。

  • DOM テストの自動化ツール
  • TypeScript による型、
  • Docker による開発環境

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 17日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。17日目の今日は、仕事としての React 編です。

16日目 編「役に立った記事編」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 16日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。16日目の今日は、役に立った記事 編です。

Pocket からのフロントエンド系推薦記事を日々読んでいる

Pocket というブックマーク及びレコメンド系のサービスを使用して、フロントエンド系の推薦記事を日々読んでいます。

一概にどのサイトがいいということはいえそうになかったので、今年読んだ記事のうち、お気に入りに登録していた記事のリストを示します。

Getting started with create-react-app, Redux, React Router & Redux Thunk

Ten Things A Serious JavaScript Developer Should Learn

A Beginner’s Guide to Progressive Web Apps & the Frontend Web

Presentational and Container Components

React Binding Patterns: 5 Approaches for Handling this

How to Use CSS Modules with Create React App

How to Price Yourself as a Freelance Developer

Simple React Patterns

azat-co/cheatsheets

TLTR; Redux

React, Front End 開発者としての心得の二つを中心に読んでいたことがわかります。Pocket はかなりの精度で関心ある記事を推薦してくれるので非常に役に立ちます。

来年はもっとバックエンド、それから AWS 等のクラウド上でのインフラ作成の記事を読んで、フルスタックできるようになっていきます。

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 16日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。16日目の今日は、役に立った記事 編です。

15日目 買ってよかった飲食物 編「ダントツで水溶性食物繊維」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 15日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。15日目の今日は、買ってよかった食物 編です。

 ダントツで水溶性食物繊維

難消化性デキストリン 水溶性食物繊維 (微顆粒品) 【付属スプーン付】遺伝子組み換え材料不使用
NICHIGA(ニチガ)
固定リンク: http://amzn.asia/fRAwjQI

食物繊維が健康にいいというのはなんとなく皆さんご存知だと思うのですが、その中でも重要で取りにくいのは「水溶性の食物繊維」だということらしいんですね。

ほうれん草とかごぼうとかの、いわゆる繊維っぽいところが、不溶性食物繊維です。これももちろん重要なのですが、これはサラダとかを食べればたくさん摂取できる。

問題は水溶性食物繊維なんです。これは海藻やキノコに多く含まれているらしい。これを日常的に取るのは大変だ。そこで水溶性食物繊維です。

もちろん食事で摂るのが一番です。ですが、これで取れるならいいのではないかと思い、試してみました。

結論から言えば、水にも溶けるし、味はしないし、なんかお腹の調子がよくなった気がします。

お腹の調子を整える善玉菌の栄養に、水溶性食物繊維がなっているらしいんですね。絶対効いている。

ウーケ ふんわりごはん 小分けごはん 国産米100% (110g×2食)×24個

ウーケ
固定リンク: http://amzn.asia/3qe3TAG

これのポイントは 110g という非常に少なめの小包装です。一般的なご飯は200gなので、かなり多いんですね。自分が無理なく食べれる量はこれくらいでした。なのでいい感じです。

これくらいの小盛はスーパーやコンビニではほとんど見かけないので、アマゾンで買ってます。

ファミリーマートの燻製された鶏肉

タンパク質を摂ることが痩せるいちばんの近道であることはわかるのですが、手軽に取得できません。サラダチキンもいいのですが、あれ、外で食べようとすると水が出てきてなかなか食べにくい。なので、燻製された鳥がいいと思います!

ただ、食塩の量や添加物とかは多少気になります。それでも、カップラーメン等を食べるよりはいいと思いますので、しばらく定期的に食べてみようと思います。

なんとなく健康的に生活する食事がみえてきた

健康食品や手軽に日常的に食べれる食品などを色々試して、なんとなく運用できそうな食事がみえてきたのが 2017 年でした。今後もこまごま気を使っていきたいと思います!

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 15日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。15日目の今日は、買ってよかった食物 編です。

14日目 英語学習 編「インセンティブこそが語学学習の肝心所」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 14日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。14日目の今日は、英語学習 編です。

おすすめ教材

一億人の英文法 ――すべての日本人に贈る「話すため」の英文法(東進ブックス)

大西 泰斗
固定リンク: http://amzn.asia/4tVTq2r

まずお勧めなのは「一億人の英文法」です。この教材のポイントは、a とか the とか on といった一見些細な表現の重要な意味をかなりしつこく説明していることです。ほかにも when  とか as とか while とか、どれも似たような意味で取ってしまいそうな表現も詳しいです。つまり、辞書を引いているだけでは今一歩掴めない英語の感覚について解説が充実しています。

これは翻訳する際にも非常に重要です。結局のところ、何を言っているのかよくわからない翻訳というのは、こういった辞書を引いただけでは見逃しにくい、しかし明らかに意味を持つ表現を、しっかり翻訳しないから起きているのだと私は思います。原文を読むと明らかに書いてあるのに、抜けてしまっているのです。

と細かいことばかりいっていると、この本がそういう重箱の隅をつつくようなマニア向けの書籍だと思われてしまうと思うので弁解します。基本的にはこの本は初学者向けの文法書です。高校くらいまでの英語の知識がある人にお勧めです。

英文解釈教室 改訂版

伊藤 和夫
固定リンク: http://amzn.asia/dE5VIVt

この本が必要なのは、倒置などの、日常では使われる機会が少ないが、しっかりした文章では出て来る表現を理解したい時です。

だいたい英語は読めるようになったが、構造的に難しくて何を言っているのかわからない文章というのに出会うことがあると思います。こういう場合に、雰囲気で翻訳してしまうと、間違える可能性があります。基本的には、構造をしっかり理解できるべきです。そんな時に役に立つ一冊です。

内容はかなり難しく、しかも受験参考書なので、そこまで実践的ではありません。しかし、より正確に読む技術を探している人には役に立ちます。

今年の夏はこの本をかなりゴリゴリ取り組んでいました。でもまだ終わっていないです。かなり量があります。途中までしかやっていませんが、それでもかなりわかる範囲が増えました。また行き詰まったら再開したいと思います。少なくともプログラミングのドキュメントではこのような難しい表現は出てこないので、今のところさしあたった必要がないので保留中です。

お勧めアプリ

英語ニュース

https://itunes.apple.com/jp/app/%E3%81%96%E3%81%A3%E3%81%8F%E3%82%8A%E8%8B%B1%E8%AA%9E%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9-studynow-%E3%83%AA%E3%82%B9%E3%83%8B%E3%83%B3%E3%82%B0-%E8%A7%A3%E8%AA%AC%E4%BB%98/id934785989?mt=8

iPhone アプリです。ニュース記事を三十秒ほど読み上げます。日本語も付いています。正直 5分を超える長いニュースだと、聞いても全く理解できません。またネイティブ向けのニュースは語彙が難しい。そういうレベルの自分にちょうどいいアプリです。

EnglishCentral

https://itunes.apple.com/jp/app/learn-english-with-videos/id927987414?l=en&mt=8

このアプリはスティーブ・ジョブスさんやオバマさんの演説や、スヌーピーやディズニーのワンシーンなど、様々なコンテンツを使って英語学習ができるサービスです。コンテンツがいいのでお勧めです。

各種プログラミング教材

あとはやはり英語で提供されているプログラミング教材を今年の秋ぐらいから本気を出してやり始めました。Node, React, Native App あたりです。わかれば仕事に直接つながる、しかも日本語の教材はほぼない領域なので、なんとしても聞き取りたいという強い意志が、勉強にプラスになります。

結局語学学習はインセンティブがないとないと続かないですよね。エンジニアの場合、英語で情報を吸収できることが、そのまま収入につながるので、やる気が持続しやすいなと思いました。

来年はシリコンバレーに向けて英語をより強化したい

シリコンバレーに遅くとも2019年にいきたいので、来年はより英語をがんばるぞい!

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 14日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。14日目の今日は、英語学習 編です。

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 14日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。14日目の今日は、英語学習 編です。

13日目 一押しの飲食店編 編「一軒目酒場」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 13日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。13日目の今日は、一押しの飲食店 編です。

一軒目酒場が最強

2017年、さまざまな飲食店にいきましたが、圧倒的お勧めできる一店は「一軒目酒場」です。

https://www.yoronotaki.co.jp/store/ikkenme/

一軒目酒場は、西池袋に本社を構える、養老の滝グループが展開する居酒屋チェーン店。なんと池袋には、池袋南口店、池袋北口店、池袋東口店、池袋サンシャイン60通り店と、四店舗もございます。

なんといってもその特徴は安さ。

https://www.yoronotaki.co.jp/menu/book140/15/html5.html#page=3

レモンサワー190円、がつポン酢250円、アンチョビポテトサラダ200円です。圧倒的です。

しかも美味しい。

お勧めメニュー

  • 男梅サワー 190円
  • ガツポン酢 250円
  • 牛すじ煮込み 320円
  • セロリ漬け 280円
  • アンチョビポテトサラダ 200円

汚い店を回るブームもあったが結局一軒目酒場がいい

一軒目酒場にたどり着く前は、いわゆる個人営業の少し汚い渋い店、を探索していたのですが、こういう店がとても安いかというと特にそういうこともないですし、すごい美味しいかというとそれは店によるので、毎回チャレンジです。

そして、チャレンジする割には、最高得点は一軒目酒場を超えてこないのでは、ということに薄々気づいたのが2017年の初夏でした。

そう、どんなに風流で良さげな街の居酒屋よりも、一軒目酒場のほうが美味しいし、安いんです。

この事実を、昨今のせんべろブームに投じたい。

一軒目酒場こそが最強なんだと。

私の街に一軒目酒場はあるのか

ございます。東京になんと44店舗展開しておりますので、必ずあなたの駅の近くにも一軒目場がございます。

こちらの一軒目酒場oole を使ってお調べください。

https://www.yoronotaki.co.jp/search/index.html?keyword=%E6%9D%B1%E4%BA%AC&state=&brand=%E4%B8%80%E8%BB%92%E3%82%81%E9%85%92%E5%A0%B4&enkai%5B%5D=&_search_x=code

たださすがに飽きてはきた

今年一軒目酒場に10回以上いっているので、さすがに飽きてきました。メニューは全部食べた。

次はどうしたらいいのか。2018年の悩みです。

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 13日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。13日目の今日は、一押しの飲食店 編です。

12日目 ネイティブアプリ 編「Swift, Kotlin, React-Native どれをやるか」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 12日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。12日目の今日は、ネイティブアプリ 編です。

Swift, Kotlin, React-Native どれをやるか

今ネイティブアプリに参入しようとした場合、上記の 3 つの選択肢があると思うのですが、以下のような利点がそれぞれ私にはあります。

  • Swift 日本では iOS の需要が高く、また Swift は英語ドキュメントが読めないと実装できないので、自分にとって金銭的なインセンティブが高い。
  • Kotlin 新しい言語なので参入の余地があるし、JAVA の知識もつく。世界的な需要としては Android  の方が多い。
  • React-native 注目され始めたばかり技術であるので参入の余地があり、かつまだ日本語のドキュメントがないので自分の価値を発揮しやすい。また React の知識がプラスになる。

ネガティブポイントは次の点です。

  • Swift 汎用性は低い。基本的に iOS の開発の仕事しかない。
  • Kotlin すでに JAVA をやっているエンジニアが多いので、そこと戦うことになる。結果として英語が読める利点が下がる。
  • React-Native まだ仕事の数が多いとはいえない。日本ではかなり先進的な企業でしか使われていない。結局はネイティブの知識が必要で、React-Native 単体で業務レベルのアプリケーションを作るのは難しい。

これらの要因を鑑みて、Swift と React-native に取り組むことにしました。

  • 業務で使うことがいちばんの成長につながるので、直近仕事になりやすそうな Swift / Xcode が有利。Kotlin は JAVA 系のエンジニアがいるので仕事を取りにくい。
  • React-Native は現状仕事はなさそうだが、2年以内に来ると思われるので、アドバンテージを取りたい。またまだ日本語資料がないので、英語ができることが有利。

参考文献

iOS開発はこれがわかりやすいです。

https://www.appcoda.com/learnswift/get-started.html

React-Native は公式ドキュメントを翻訳しながら進めています

https://nakanisi-yusuke.gitbooks.io/react-native-document-translate-japanese/content/top.html

ウェブはプログレッシブアプリが前提になっていくと思われる

今ユーザーの体験の中心は Native にうつっているので、ウェブプリケーションを作る機会は減っていくのかもしれない。しかしプラットフォームとしてのウェブが中心であり続けるのは間違いないと自分は思います。Native はどこまでいっても各企業のものなので、標準化されることがないと思うからです。テクノロジーの中心は今後もウェブだと思います。ウェブが技術の核となりながら、ネイティブの体験を提供していく、というプログレッシブアプリの波が今後支配していくとなるとすると、やはりネイティブアプリに噛んでいく必要があるなと。がんばるぞい。

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 12日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。12日目の今日は、ネイティブアプリ 編です。

11日目 対訳原理主義者 編「対訳原理主義者は汎言語主義の夢を見るか」 2017年圧倒的成長振り返り一人アドベントカレンダー

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 11日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。11日目の今日は、対訳原理主義者 編です。

対訳原理主義者とは何か

対訳原理主義者とは、翻訳の成果を「原文」と「対象言語の訳文」の二つを併記する形式=対訳の文化を、原理主義的に進めていく者のこと。

具体的には私が進めている翻訳を実際にご覧いただきたい。

https://nakanisi-yusuke.gitbooks.io/redux-document-ja/content/docs/introduction/CoreConcepts.html (Redux 公式ドキュメントの対訳)

翻訳された結果である日本語だけではなく、原文の英語のセンテンスも併記しています。これが対訳形式です。

対訳形式の利点

基本的には母国語で読んだ方が、読める速度は上がりますが、しかし精度という意味では原文を読んだ方が高いといえます。その両者の利点をかね備えるのが、対訳形式です。

例えば、母国語が日本語で、原文が英語の場合、第三者が翻訳した日本語訳文を基本的に読み進めることで速度を確保しつつ、訳文が十分に意味を表出できていない場合には、原文を読むことで精度を上げる、という読み方が対訳であれば可能です。

対訳形式の場合、読者は翻訳されたセンテンスと同時に、原文をも確認することが容易にできるため、翻訳では十分に理解できない場合や、誤訳であることが予想される場合に、原文を確認することができます。

もし対訳ではない場合、原文を探す手間がかかります。(単純に原語切り替えタブをクリックすればいいだけの場合もありますが、それでも対訳よりも視認性が下がります) また、今読んでいる場所が何ページにあるのか、対応している箇所を探すのも一苦労です。

こういった問題を対訳形式は解消し、速度と精度のどちらをも、翻訳、原文をより向上させることができます。

過去の実績

こちらの記事のリンクで私の過去の対訳の成果について確認できます。

他にも GitBook 上で進めているものもあります。

対訳原理主義者としての今後の活動

対訳原理主義者として、対訳文化を推し進めるための一番効果的な方法は、何よりも私が対訳コンテンツを提供することだと思っています。

対訳可能なプラットフォームやサービスの作成、という間接的な方法も考えられますが、対訳が広がらない一番の要因は、そもそも翻訳を積極的におこなうエンジニアがいない、ということだと私は考えています。そもそも、対訳か訳文のみか、という問題の前に、翻訳コンテンツが非常に少ないというより根本的な問題があります。この根本的な問題をクリアしつつ、対訳を広めるためには、自分自身が対訳コンテンツを出していくことが一番効果があると考えています。

何を対象とすべきか

後述しますが、対訳、ひいては翻訳されたコンテンツが好まれないのは、そもそも翻訳されたコンテンツの質が低く、遅いからではないか、と考えています。翻訳されたコンテンツを読むよりも、日本人が書いたテキストの方がわかりやすければ、翻訳コンテンツは歓迎されません。また翻訳されるのが遅ければ、日本語の解説書籍も出版され始めますので、公式ドキュメントを読む必要性が下がります。

そうなれば、わざわざ無名の人間が翻訳した公式ドキュメントを読む価値はほぼありません。そして対訳原理主義を広める隙もありません。

ですから、対訳原理主義を推し進めるためには、ニーズがあり、かつまだ日本語の書籍が出ていないものを対象にする必要があると考えています。

例えば、JavaScript そのものや CSS に関してはすでに日本語の書籍が大量にありますので、この領域を対象にすることは、対訳原理主義の普及にはあまり効果がないと考えています。

効果があるのは、React Native, Swift, Kotlin といった、仕事としてニーズがある技術でありながら、まだ日本語の資料がない、もしくは少ない領域です。

React Native を主題とした日本語の商業書籍はまだありません。ですが技術として今後需要が増えていくことが期待されます。ですので、ここは対訳原理主義を広めるにあたって最適なエリアではないかと思っています。

Swift や Kotlin に関しては、その言語の仕様について書かれた本はすでに出ています。しかし、iOS や Android 開発のためのという点では、十分なコンテンツがないので、まだ隙間があると思っています。ただし、少なくとも出ているという点では、React Native よりも難しい市場です。それでも仕事としてすでに市場があるので、その点はプラスです。

React Native, Swift を重点対象として活動していきます。Kotlin は JAVA を過去にやっていた人たちに質の点で勝てないと思いますので譲ります。

対訳原理主義を私が推し進めるインセンティブは何か

なぜここまで対訳原理主義を私が推し進めるのか、疑問に思われる方もいらっしゃると思うのでご回答させていただきます。

そもそも論としては、翻訳が私の趣味だ、ということがあります。趣味で翻訳をやっているのです。そのため、別に誰も読まなくても私は粛々と翻訳を続けていきます。

だとしたら、対訳ではなく翻訳でいいではないか、と思われると思いますが、対訳こそが翻訳の面白さを一番引き出す形式だと思っています。訳文だけが乗っているだけでは、本当の翻訳の面白さを伝えきることができないのです。

だいたい翻訳された本を買う場合も、原語の書籍を書います。つまり一つのコンテンツについて日本語と言語の二冊の本を買っています。そしてそれを並べて読みます。これが一番楽しい読み方だと私は思います。

しかし、これはそもそもかさばります。二冊買わなくてはいけないので。また交互に見るのが非常に面倒です。であれば、最初から対訳になっていればいいのです。

とにかく対訳は私の趣味嗜好であるので推し進めている、というのが第一の原理です。

しいていえば対訳が公共に利する部分もある

対訳は私の趣味ですが、強いて言えば日本社会全体に貢献できる部分も多少はあると思います。

日本人の多言語化を推し進める可能性

例えば、英語を読める日本人を増やせるのではないかと思います。そもそも多く日本人が英語を読むことができないのは、読む機会がないからです。わざわざ読む機会のない、母国語以外の勉強をするのはハードルが高い行為なので、たいていの人はしません。機会がないどころか、母国語以外のコンテンツを買うのも一苦労です。Amazon の充実でこれは変わってきていますが、10年前はかなり難しく、根性が必要でした。

対訳で二つの言語が使われていれば、自然ともう一つの言語を読む機会を提供できます。読む機会さえあれば、自然と読めるようになります。対訳コンテンツは日本人の多言語化に寄与します。

多言語化が進めば、翻訳する人口が増える

多言語扱える人間が増えれば、結果として対訳コンテンツを提供できる人間が増えます。そうすれば、より一層対訳原理主義が広まることとなります。このサイクルが加速します。

想定される反論への反論

英語があるだけで、嫌な気持ちになる

ぼくの友達でパクチーが嫌いな人間がおり、またこれは一定数いると思いますが、彼らは自分の料理にパクチーが入っているのはもちろんのこと、他人の料理にパクチーが入っているだけでも嫌がります。他人の料理にパクチーが入っているのは自由主義の原則に従い諦めてもらうとして、自分の料理にパクチーが入っていたら嫌ですよね。よくわかります。

ただカオマンガイに入ってしまったパクチーよりも、対訳で紛れ込んだ英文を取り除くことは簡単です。例えば対訳形式、英語だけ、日本語だけ、という切り替えを可能にするインターフェイスを実装することは比較的簡単です。これは対訳が広がれば自ずと運用されるようになります。ですので、そこまで耐えていただければと思います。あと少しです。

原文を読んだ方が早い

もちろんその通りですが、それはある程度の語学力とエンジニア力があって初めて成立するものです。私は日本語で JavaScript を学習できたことを感謝しています。最初から英語だけで学習することは難しかったと思います。原文を読んだ方が早い人が翻訳にまわってもらえる社会を作る。これが私の目下の目標です。

翻訳している時間を、コードを書く時間にあてたほうが、お金になる

その通りだと思います。結局のところ、翻訳できるほど理解しているエンジニアは、翻訳をするインセンティブがありません。その結果、質の高い翻訳がなかなか世に出てきません。これは根源的な問題です。

金銭的なインセンティブは、翻訳を通して得られることはないと思います。金銭的なインセンティブはおそらくいちばん大きなインセンティブです。

金銭的なインセンティブがないとすればどうすればいいのか。

結局は翻訳自体に面白みを見いだせる人を増やすしかないのかなと思っています。面白いことはみんなやります。基本的にはこれしかありません。

ということで、翻訳の面白さ、対訳の面白さを感じている人のコミュニティを作る、といったらおこがましいですが、自然と集まれればいいのかなとは思っています。ただコミュニティを作るには、やはり私自身が強力に対訳を推し進めなくてはいけないと思うので、まずは対訳コンテンツを圧倒的物量で提供していく。これをおこないます。

対訳主義者の今後の野望

私が今のところ翻訳できるレベルで扱えるのは英語だけなので、扱える言語を増やしていきたいと思います。同時に英語も強化していきたい。

そのためには、その言葉が使われている国に移動した方が、学習の効率が上がると思うので、半年毎に言語の異なる国を移動して、フリーランスのエンジニアとして仕事をしていきたいと思っています。

がんばるぞ!

この記事は ” 2017年圧倒的成長振り返り一人アドベントカレンダー ” の 11日目です。

https://adventar.org/calendars/2747

アドベントカレンダーに乗り遅れ、参加できそうなものがなかったので行われる、孤独な一人アドベントカレンダー。11日目の今日は、対訳原理主義者 編です。