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日目の今日は、対訳原理主義者 編です。

 

 

 

10日目 機械学習 編「10年後、機械学習しかエンジニアの仕事が残らなくなっても、仕事を取りたい」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

10年後、ウェブの仕事はないかも…でも

10年前にあった、普通のウェブサイトを作る仕事は、今かなり減っていて、しかも単価も下がっていると思います。賛否両論あると思いますが、昔と同じ基準では仕事できないのは確かだと思います。

今は SPA や Native アプリの仕事が多く単価が高いので、そこを狙っている自分ですが、こういった仕事も 10年後はないだろうなと思います。現在そこそこのウェブサイトを無料で簡単にできるようになっているのと同じで、そこそこウェブアプリは誰でもできるようになっているような気がします。それがテクノロジーなので。

そして今話題になっているように、そもそも人間の仕事は AI が無くしていく気もします。そうなったらもうやることはないのですが、AI の実装はせずとも、それを使った何かの仕事はまだあるんじゃないか、という可能性にかけて、機械学習もやってみてます。

https://www.coursera.org/learn/machine-learning/home/welcome

元スタンフォード大のコンピューターサイエンスの教授で、 Coursera の共同創立者、現 Baidu のチーフサイエンティストの Andrew Ng さんが教えてくれる、しかも無料の機械学習コースです。

行列や微分積分がふんだんに出てくるのですが、理系の学部生1年生レベルの数学力でなんとかなるらしいので、なんとか week 3 まではついていけています。しかし week 11 まであります。なかなか進まない。でもやらないよりはいいので、少しずつ進めていっています。

やはり数学がかなり面白いです。そんなことができるのかと。もちろん仕事のレベルで数学が使えるようになることはないとは思うのですが、それでも基礎的な概念を知っているのと知らないのでは圧倒的差があるので、怖気付かずにどんどん数学をやっていってます。

未来はどうなるかわからない。しかしなるべく新しいことをやりたい。

未来仕事がなくなるかどうかは誰にもわかりませんし、そもそも仕事をしなくてもいい時代が来るということかもしれません。そうなったときには、結局面白いことをやる、ということしかなくなります。そして、面白いことって新しいことだと思うんですよね。未知の領域。なので、仕事がなくなるとか、なくならないとかは別にしても、自分の未知の領域である高度な領域と機械学習等の新しいサイエンスに取り組んでいきたいと思います。圧倒的成長の時代は機械学習へ…

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

https://adventar.org/calendars/2747

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

9日目 ダイエット 編「鳥もも肉とコメを食べていたら、自動的に痩せる」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

鳥もも肉とコメを食べていたら、自動的に痩せる

特に体重を減らす気は無かったのですが、健康になりたいと思い、食事を見直すついでにダイエットをしてみました。

これは7月くらいから初めて10月くらいまでは続きました。この間、鶏胸肉を1日200g、コメを200g、あとはブロッコリーやほうれん草等を主に食べたのですが、これでもだいたい1日1200キロカロリーくらいしか取れないので、自動的に痩せていきました。なんなら食べきれないくらいです。その結果、61キロから57キロまで緩やかに減っていたのですが、10月中盤に風邪を引き、そこでもどっちゃいました!

リバウンド、ということはないと思います。筋トレもしていたし、食事は十分にとっていたので。腕立てやスクワットの回数は減っていないどころか、増えました。

ただ、結局は継続が大事ですね。そして継続のためには健康が大事。風邪を引いたりするとやり直しという気がします。のですので、次は風邪対策というか、体力のキープということも視野にいれながらダイエットしたいと思います。

圧倒的成長は圧倒的身体から。健康第一!

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

https://adventar.org/calendars/2747

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

8日目 買ってよかったガジェット 編「 けっきょく MacBook Pro が最強」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

圧倒的に MacBook Pro 次にマウスとキーボード、最後に Bose のサイレントヘッドホン

なんといっても中古で買った MacBookPro 2015 です。沖さんの元をしばらく離れ出稼ぎでゲットしたまとまったお金を使って買いました。もともと2011年の MacBook Pro を使っており、Photoshop や Illustrator がとにかく厳しい状態でした。開発マシンを支給されるので仕事に支障はないものの、家で趣味の開発に困難が。特に、ネイティブアプリの開発が絶望的で、Xcode の iOS シミュレターを動かすのがほぼ不可能でした。さらになんと WebGL 関係も動かないので Three.js とかやりたいと思ってもできませんでした。対応してませんと警告がでる。なんでやねん!

2015年のものなので最速ではないにせよ、npm start もすぐ走るし、iOS のシミュレータもさくさく動きます。また当然ですがありとあらゆる開発の待ち時間が短くなったので、能率アップ。

ちなみに、もともと日本語キーボードだったのですが、英語キーボードにしました。これによってシングルクオテーションの位置も近くなり、最近の JavaScript の潮流であるシングルクオテーション使用も簡単に。最高です。

今後もお金をためて、まずはメインの開発ツールであるパソコンを買い換えていきたい!

Apple 正規品のマウスとキーボードが結局無難

マジックトラックパッドを2に、キーボードも一つ新しいバージョンであるマジックキーボードに変えました。

https://www.apple.com/jp/shop/product/MJ2R2J/A/magic-trackpad-2

https://www.apple.com/shop/product/MLA22LL/A/magic-keyboard-us-english?fnode=56

特にMagic Trackpad 2 は、弱い力でも反応するので素晴らしいです。疲れない。また細かいところですが、電源のオンオフをトグルスイッチでできるので、切り忘れがない。

キーボードはそこまでタッチ感に違いはないかなという感じです。

どちらも小さくなっており、おそらく軽くもなっています。高級感もアップ。

まだ壊れてないからいいかーと思っている人も検討の価値ありです。

それから次の持ち運びできる代も欠かせません。

サンワダイレクト ノートパソコンスタンド iPadスタンド エルゴノミクス ドイツのiFデザイン賞受賞 100-CR004
固定リンク: http://amzn.asia/bsnl8Tc

ノートパソコンをその高さのまま使っていると、いつか首折れると思います。高さをあげて首を少しでも正面に向けるようにしています。持ち運びできてそこまで重くなく、そこそこ高さも上がります。もっと高さを稼げるものがあれば教えて欲しいです。

Bose QuietComfort 35 wireless headphones II ワイヤレスノイズキャンセリングヘッドホン

固定リンク: http://amzn.asia/exNCncM

作業中にヘッドホンをしているのですが、音楽は一切流していません。無音を作るためだけに、ノイズキャンセリングヘッドホンをしています。

ビックカメラの店員さんが、ノイズキャンセリングの性能に関しては各社甲乙つけがたいが、やはり Bose に今でも分があるのではないか、とおっしゃっていたので、これを購入。ノイズキャンセリングインイヤーイヤホンの方がもしかしたら静音性は高いかもしれないし、首も疲れないのかもしれませんが、耳に入れる方式があまり好きじゃないのでヘッドホンを選択しました。

完全に無音にはならないのですが、かなり低減してくれるのは間違いありません。また通勤電車の中で英語の勉強をするのにも最適です。

結局開発ツール周りがコスパ高い

結局、1日6時間以上は触る開発周りのツールがコスパが高いなと思いました。Kindle ペーパーホワイトとかも買ったのですが、けっきょく Mac か iPhone で見ています。とにかく開発を早くして、圧倒的成長をし、賃金を増やす。これがベストですね!今後も成長に必要な開発ツールにはお金を惜しまず、圧倒的成長をし続けたいと思います。

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

https://adventar.org/calendars/2747

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

7日目 役に立ったチュートリアル 編「公式サイトで React, Redux を、Udemy で Node.js を身につけた 」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

公式サイトで React, Redux を、Udemy で Node.js を身につけた

今年身につけた技術で特に大きいものは、React, Redux 周りのシングルページアプリケーションを作るための技術と Node.js まわりのバックエンドの知識です。React Redux は公式チュートリアル(翻訳記事)を、Node.js 等バックエンド周りは Udemy(https://www.udemy.com/) で学習しました。

Continue reading “7日目 役に立ったチュートリアル 編「公式サイトで React, Redux を、Udemy で Node.js を身につけた 」 2017年圧倒的成長振り返り一人アドベントカレンダー”

6日目 役に立った書籍 編「まとまった学習に本は強い」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

まとまった学習に本は強い

刻一刻とバージョンアップしていくウェブ開発の周辺環境においては、情報が執筆時に固定されてしまう紙もしくは電子書籍は、不利な部分があります。しかしそれでも、まとまった学習が必要な場合に、つまり初学者にとってはやはり書籍は強いなと思います。フロントエンドの開発をまとめて学習する、サーバーサイドプログラミングを始める、こういうときに書籍が役立ちます。ある程度基礎をつけた後は、公式のドキュメントや各種記事をおっていけばいいということになります。

改訂新版JavaScript本格入門 ~モダンスタイルによる基礎から現場での応用まで

山田 祥寛
固定リンク: http://amzn.asia/hwCkllD

まだ自分が英語の記事を読む実力がなかったときに、一番読んでいたのはこの本です。原理的な部分がわかるので、理解が深まります。やっとどの項目を読んでも、だいたい知っているな、というところまできました。

最新バージョンは、ES2015 に対応し、promise,  async, map といった新しいメソッドの解説が追加されました。

オライリー関係の JavaScript の本よりも簡単だと思うので、とりあえず書けるけど、新しい記法がわからない、非同期処理とか言われてもよくわからない、というレベル感の方にオススメです。

Clean Coder プロフェッショナルプログラマへの道

Robert C. Martin
固定リンク: http://amzn.asia/2uhJs1I

リーダブルコード、情熱プログラマーといった、特定の言語に限らないエンジニアとしてのソフトスキルについての本です。

この手の本として一番近いのは情熱プログラマーだと思うのですが、私の個人的な趣味として、こちらのロバートさんの人柄に惹かれます。

過去に書いた自分の記事からの引用ですが、以下のような点が役に経ちました。コードの柔軟性に関する議論です。

  1. 常に細かいコードへの変更を加えることで、「柔軟性」を与えることができる。
  2. そして変更を加えるためには、コードを理解している、もしくはしなくてはいけないから、それも結果的に、コードを確実に動かすことにつながる。
  3. 例えば、JSならグローバルに配置されているファンクションやヴァリアブルを、クラスに書き換える。もしくは、純粋関数で書き直してみる。
  4. 他にも、別の機能が追加された時にも、そのコンポーネントが機能するのか、試してみる。もしうまくいかないとすれば、柔軟性が低いコードになっているので、変更する。
  5. 一般的には、洗練された、もしくはベストプラクティスに基づいたコードを書く、という方針がよく取られるのではないかと思う。しかし、そうではなくて、常にコードを動かせるような柔軟性のあるコードを書く、もしくはそのために実際にコードを変更する、という発想は、私にとっては新たな視点であり、また実務的なアドバイスであった。動くコードをかききって終わり、ではなく、それを常に動かしていく。

雑記 Clean Coder 等

このコードを変化させることによって柔軟性を担保するという考え方は、単にコードにとどまらず、自分のスキルアップ、キャリアについても適応できるのではないかと思っています。つまり、何か単一の領域、例えばフロントだとかバックエンドだとか IoT だとか、にこだわることなく、むしろエンジニアリングという視点で柔軟に、領域を横断して、同じことを実行してみることが有効なのではないかなと思います。

例えば、SPA は基本的に React のようなフロントで動くコードを元に構築されていますが、これはもちろんサーバーサイドでレンダリングさせることもできますし、同じようなことをネイティブでやることもできます。結局のところ、データを展開してユーザーに見える形にする、という意味では、フロントもサーバーサイドもネイティブも同じです。

ここでどれが最適解なのか、ということを考えずに (もちろん最適解をみつけるのがエンジニアの仕事ではあるのはもちろんですが、仕事とは関係なしに) 柔軟に様々な場所で同じアプリケーションを動かしてみる、というのが成長につながるのではないかなと思います。

形を変えられる、ということ自体がある種の技術的な修行になります。

Node.js超入門

掌田津耶乃
固定リンク: http://amzn.asia/8xCxI9t

この本は、フロントエンドから仕事を初めて、バックエンドも勉強したいという人に(つまり自分です)オススメの本です。

そもそもなんでバックエンドが必要なのか、ということからかなり詳しく説明してくれています。その上、プログラミングをしたことがある人であれば知っているようなことに関してはそこまでページが割かれていないので、自分のような実力感の人に丁度良いと思います。(反対に完全にプログラミングをやったことのない方は、もっと初学者向けのコンテンツの方が望ましいかもしれない)

また、この本は2017年後半にでいていますので、市場の Node.js のどの本よりも情報が新しいというのもポイントです。バージョンの違いによって生じるエラーは、初学者はなかなか一人でクリアーできないものです。新しければ新しいほどいいです。

JavaScript関数型プログラミング 複雑性を抑える発想と実践法を学ぶ impress top gearシリーズ

LuisAtencio
固定リンク: http://amzn.asia/7YmhS4L

プログラミングを勉強するときにたどる道筋は次のようなものだと思います。

  1. 変数に値を代入してみる。
  2. 条件分岐を if などを使って行う。
  3. 関数を使って、処理を抽象化する。
  4. オブジェクト指向プログラミングで、関数と変数をカプセル化する。
  5. 各種フレームワーク、ライブラリを活用する。

つまりプログラミングのパラダイムを、順番におっていくことになるわけですが、その次に今出て生きているのが関数型プログラミングです。もちろんパラダイムといっても、ある手法が完全になくなって新しい手法が支配する、というようなことにはプログラミングの世界ではなっていないので、関数型プログラミングも既存の手法と並存していくことになると思います。

具体的には、例えばオブジェクト指向プログラミングとの並存という意味では、値を格納する装置としてのオブジェクトは今後も有効だとされています。さらにメソッドに関しても、例えばライブラリが提供する関数のように、あるオブジェクトに紐づく形でメソッドが提供されるというのも有効だろうと。

問題なのは、インスタンスが持つ自分自身の値を変更してしまうメソッドです。JavaScript でいえば、this で自分自身のプロパティを参照するメソッドです。これはメソッドに副作用をもたらすので、問題です。

純粋な関数型だけでプログラミングすることはできないので、副作用を起こす部分と、おこさない部分を明確に切り分けることが重要だと提唱しています。副作用が起きることがわかっている部分を、別に切り離して、そこだけチェックすると。

OOP がオワコンだ、なんて言い出す人がいますが、常にパラダイムは並行して運用されるのであって、何かが出てきたら何かがなくなるなんていうことはないですよね。(相対性理論が出てきたって、依然として古典力学は、投げたボールがどこに落ちるかを予測するために使われています。)

JavaScript Interview Questions You’ll Most Likely Be Asked (Job Interview Questions Book 25) (English Edition)

Vibrant Publishers
固定リンク: http://amzn.asia/9NEa0Ys

ジョブインタビュー、つまり就職活動時の面接で問われる質問の回答例文集です。

せっかく現代社会に生まれたので、2年以内にシリコンバレーで仕事をしようと思って、買いました。

JS 内でページを遷移させるにはどうしますか?またその履歴をどう処理しますか?とか、JavaScript の特徴は?JAVA との違いは?といった、なかなか役に立つ質問が多く、簡潔に英語で答えられるようになるためには有効な一冊です。ただ、2017年に出たにしては、情報が古い部分もあります。ちょっとこれはやり方として古すぎるのでは…という部分は適宜調べてバージョンアップしましょう。

巷の噂では、きっちり実務経験があって、モダンな開発をキャッチアップして、英語ができれば、シリコンバーで働くのも割とできるらしい、とのことなので、チャレンジしていきたいとおもいます。

まずはこの一冊から 意味がわかる線形代数 (BERET SCIENCE)

石井俊全
固定リンク: http://amzn.asia/2kCAIWO

最近機械学習もちまちま勉強しているのですが、その際にどうしても数学の知識が必要になります。だいたい理工系の大学一年生がやるような内容のようですが、私は史学が専門なので、線形代数といわれても、小説家の大岡昇平が趣味でやっていたな、という知識しかなく、なんら計算処理できず、困っておりました。

そこでこの一冊です。結構わかりやすいです。ただ扱っている内容が内容なので、誰でもすごいわかる、ということはないかなと思います。根性入れて読めば、まあわかる、というレベル感の本です。

これなら分かる最適化数学―基礎原理から計算手法まで

金谷 健一
固定リンク: http://amzn.asia/gdu24e7

機械学習においては、線形代数の知識の他にも、いわゆる微分積分の知識が必要になってきます。なぜなら機械学習というのは平たく言えば、ある統計データを近似するに最適な関数を特定する = 最適化 をコンピューターの力技で実現する手法だからです。結局でてくる概念はほとんど数学処理なので、このあたりの知識がないと、いまいちピンとこない。ということでこの一冊です。

他にもオススメの本があった気がするのですが、思い出せないのでまた今度!

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

https://adventar.org/calendars/2747

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

 

雑記 Clean Coder 等

Clean Coder

おもしろい本だった。一章だけ読んだが、フリーランスのエンジニアとして必要な行動規範が書かれており参考になる。

  1. 責任をとる⇨コードを確実に動かす
  2. そのためには、不明瞭なところを一切なくす
  3. そのためには、常にコードに細かい変更を加えること、が一つの策。
  4. もう一つは、テストを書くこと。全てに。テスト駆動開発 Test Drive Development TDD。
  5. 常に細かいコードへの変更を加えることで、「柔軟性」を与えることができる。そして変更を加えるためには、コードを理解している、もしくはしなくてはいけないから、それも結果的に、コードを確実に動かすことにつながる。
  6. 例えば、JSならグローバルに配置されているファンクションやヴァリアブルを、クラスに書き換える。もしくは、純粋関数で書き直してみる。他にも、別の機能が追加された時にも、そのコンポーネントが機能するのか、試してみる。もしうまくいかないとすれば、柔軟性が低いコードになっているので、変更する。

特にコードを書く段階では、「柔軟性」というキーワードが参考になると思った。一般的には、洗練された、もしくはベストプラクティスに基づいたコードを書く、という方針がよく取られるのではないかと思う。しかし、そうではなくて、常にコードを動かせるような柔軟性のあるコードを書く、もしくはそのために実際にコードを変更する、という発想は、私にとっては新たな視点であり、また実務的なアドバイスであった。動くコードをかききって終わり、ではなく、それを常に動かしていく。⇨個人的な具体的な課題:キーボードのアプリをReactに置き換える。

話題は冒頭の「プロフェッショナルとして責任をとる」という部分に戻るが、このテーマを具体的に自分のスキルについて鑑みた場合、Gitのより深い理解と、npmスクリプトやGulpといったタスクランナーによる処理への深い理解が、今すぐに必要だと感じた。

Gitはエンジニアの成果物に直接的に関わるシステムだし、自分の作業だけではなく、プロジェクト全体に影響を与える。コードを書く仕事の最終アプトップトは常にGitを経由してなされる。それゆえ、完全な理解が必要だ。昨日もGitの復習をしていた。継続してマスターしていく。

タスクランナーについては、webpack、npm スクリプト、Gulp 等々あるが(webpack、npmスクリプトはタスクランナーではないけれど、事実上Gulp等に変わってJSのトランスコンパイルやモジュールの管理、Sass等のプリプロセスを担当する役割を担っているという意味において。) これらを通して、最終的な成果物がつくりだされる以上、Git同様に重要だ。

Gitもタスクランナーも、実務で使う範囲ではそこまで難しくなく、ほぼ同じ作業の繰りかえしであるため問題なく使えるが、プロフェッショナルとしての責任を持てる理解が今の自分にあるかというと、ない。急務である。

(Deep Work) => Flow – A proven Path to Satisfaction

さらに話は変わって昨日読んだ、おもしろい記事。

https://www.robinwieruch.de/lessons-learned-deep-work-flow/

5日目 IoT 編「IoT をやるとウェブの根幹の知識がついていい」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

  1. raspberry pi 3 に nodebrew を入れて node のバージョンを管理する。node-redも入れる。 2017年5月1日
  2. Node-REDの基本的なノード:MQTT,JSON,Websocket,TCP等 2017年4月29日
  3. 最初のフローを作る。Node-REDレクチャー2 2017年4月23日
  4. Node-RED イントロダクション 2017年4月23日

5/5 養老の滝ハッカソン

https://media.dmm-make.com/item/4181/

これに向けてラズベリーパイを買い、node をインストールして、Node-RED を仕込んで、Grove を秋葉原で買って…というのを 1ft-seabass さんご指導のもと、色々準備していったのですが、いつも通り HTML, CSS, JS を書くフロントをやったので、全くセンサー触らず。IoT デビューできず。

IoT をやるにあたって、ルーターの仕組みや、根本的なネットワークの知識、通信プロトコルの知識がつきました。ウェブだけでどうしても完結するサービスをメインにやっているので、その外側の知識があやふやだったのですが、IoT を通して知見が広がりました。

やっぱり実世界の値、気温や速度や位置情報を、簡単に取れて、それがウェブに反映するというのは面白いですね。

その後、結局 Grove センサーは放置しっぱなしで申し訳ないのですが、また時間を見つけてやっていきたいと思っています!とはいえ、仕事でやらないとなかなかまとまった時間ができないのが難しいところ。IoT とウェブを組み合わせる小規模な仕事、とか見つければなと思います。

明日はリアクト編です!

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

https://adventar.org/calendars/2747

 

4日目 WebStorm 編「WebStorm は全部盛りなので楽」 2017年圧倒的成長振り返り一人アドベントカレンダー

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

https://adventar.org/calendars/2747

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

通算 10 記事、WebStorm について書きました。

  1. webstorm 差分チェック(diff)のショートカット 2017年12月1日
  2. webstorm standard js成形 2017年10月16日
  3. Webstorm reformat codeの設定 2017年6月7日
  4. WebStorm の設定を複数の端末で共有する 2017年4月8日
  5. WebStorm Bitbucket 2017年3月26日
  6. Webstorm EAP 版が Vue.js をサポートしたので使ってみました 2017年3月16日
  7. WebStormでコードをチェックする 2017年1月19日
  8. WebStormのエディターの色を変える 2017年1月19日
  9. WebStormのKeymapを他のパソコンに移行させる 2017年1月13日
  10. WebStormのショートカットキー 2016年11月19日

元々は Atom を使っていたのですが、沖さんが JetBrains 製品を使われていたので、私も便乗して WebStorm にしました。自分の周りの強いウェブ開発者は、WebStorm (もしくはその上位バージョンにあたる IntelliJ IDEA) か VSCode を使っています。

VSCode はやはり軽いです。また無料なので、今からウェブ開発を始める人には VSCode をおススメさせていただいています。非力なパソコンでもサクサク動きます。

WebStorm は全部盛りで、プラグインの追加や設定をせずとも、最初から必要なものが揃っています。また Version Control を WebStorm ないでできるのが便利です。

Version Control

差分をいつもエディターないで簡単に見れて、今見ているファイルをエディターで開く、なんてことが簡単にできるのが連携しているポイントだと思います。SourceTree のほうが高機能な部分もありますが、(例えばファイル全体ではなくて、特定の行だけをコミットに取り出すなど) いつものエディターでコミットできて、差分をチェックできて、連携しているからこそ実現できる一発で差分が生じている行に移動ができる、というのはかなり快適です。

npm script の実行

package.json に書かれた npm スクリプトを実行するための機能があります。これをつかえば、毎回 npm start とか npm run build とか打たなくていいので楽です。

あと地味にいいのは、例えば package.json が開発ディレクトリの直下にない場合、プロジェクトを開くたびに、毎回 cd fornt とかって移動してから npm コマンドを叩くことになるわけですが、WebStorm ならそれも必要ないです。package.json のある場所を指定してあげれば、この機能でそのままアクセス可能です。

また、プロジェクトを開いた時に絶対実行するスクリプトを登録しておけば、自動的に実行してくれます。地味に楽です。

他にも次の記事が参考になります。

ウェブ制作にはWebStormがお勧め! 使いこなせば操作が爆速になる機能のまとめ

http://ceblog.mediba.jp/post/143350750932/webstorm%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E5%BF%AB%E9%81%A9web%E9%96%8B%E7%99%BA%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1

常に使っている機能

  • cmd + shift + O → ファイル検索
  • cmd + 数字でタブを切り替える。1 プロジェクト、4 run、9 バージョンコントロール
  • esc → エディターウィンドウに戻る
  • alt + F12 ターミナルを開く
  • cmd + b → JS の変数、関数、CSS のクラスの宣言元に移動する。宣言の場所でもう一度ショートカットキーを実行することで、使用している変数・関数へジャンプする。
  • cmd + K → コミット
  • cmd + shift + K → プッシュ
  • cmd + T → アップデートプロジェクト
  • cmd + i (に自分で設定)→Select in Project View(今見ているファイルを左側のプロジェクトタブで開く)

知っているはショートカットを忘れてしまっていつも使えていない機能

  • Option+F7 → 変数・関数の使用箇所を一覧表示
  • Command+Option+O → 変数名・関数名・クラス名を検索
  • command+shift+F → 全文検索
  • Command+Shift+Delete → 最後に編集した行に移動
  • Command+Shift+V → 文字列をコピーした履歴からペーストする
  • alt + 上下 → 単語単位で選択範囲を広げる
  • Shift+F6 → リネーム

今後使いたい機能

REST Client

今は Google 拡張の Restlet Client を使っていて、これもいいのですが、WebStorm 内にあるのであればこれを使っていきたいなと。

Debug を WebStorm から

https://www.jetbrains.com/help/webstorm/debugging-javascript-in-chrome.html

Chrome でいつもはデバッグしていたのですが、なんと WebStorm 内でデバッグ可能。現在レンダリングされている HTML も見れる。もちろん Node で立てたサーバー内でも実行可能。使えたら便利そうです。

比較系

WebStorm/PhpStormが備える差分抽出(Diff)機能まとめ

  • ローカル履歴と現在のファイルを比較する。
  • ブランチごとの比較。

  • Deployment(Automatic Upload)
  • Directoies ディレクトリの役割を決める。ルートパスなど。
  • JavaScript Libraies 外部のJavaScriptライブラリを読み込んでコード補完を行えるようにする機能。

今後もガンガンウェブストームの機能を覚えて、自動化できることは自動化していきたいと思います。

VSCode 使っている人をみていて軽そうで羨ましいというのはありますが、むしろ最速のパソコンを買えばいい。毎年最速のパソコンが買えるように稼ぎたいと思います。

一人アドベントカレンダーはまだまだ続きます。