Hatena::ブログ(Diary)

日々、とんは語る。

この日記のはてなブックマーク数 はてなスターカウンター Peace この日記をあなたのはてなアンテナに追加する。 rss
お問い合わせ先 mailto

2016-04-22 雨の日。

Emacsによって極限まで鍛えられた小指でMacBookを使うとこうなる。

| 06:47 |

MacBookのキーボード

2014年の年明けに購入して以来、約2年間利用し続けている僕のMacBookですが、最近キーボード「A」文字が消えてしまいました。

「A」以外はまったく問題ないことから、左小指の力が関係していることはあきらかでしょう。

左小指と言えば思い当たる節がひとつあります。それはEmacsです。

現在は、EmacsだけではなくAtomも利用してますが、Emacsを使い続けた僕の小指は、どうやら常人の小指の力を越え、「ザ・ハンド」のような能力が身についてしまったようです。

みなさん、小指を痛めるときがあるかもしれませんが、それの痛みを乗り越えた先には、いつか「ザ・ハンド」がその身に宿りますので、その日がくるま自分の小指を信じて、鍛え続けましょう。

2016-04-10 曇りの日。

日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。

16:53 |

ボストンで脱出ゲームしたときの写真

先週書いた10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。という記事がまずまずの反響を得たのですが、僕の予想とは異なり、「こんなに多くのツールフレームワーク必要とする現状はおかしい」といった、状況批判意見が多く集まりました。

はてブのコメントのスクリーンショット

Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており、この半年間ほどは「実際にどの組み合わせがベストか」という議論が行われていました。そして、そういった議論もようやく落ち着きを見せ、おおよそ僕が書いたような組み合わせに帰結しつつあります

そのため、まさかフロントは変化が激し過ぎる」とか「保守が大変そう」などといったような、1年くらい前に言われていた意見が、いまだに多くを占めるとは、まったく予想していなかったというのが正直な意見です。ひと昔まえであれば、「面白そう」とか、「もっと便利なツールがあるよ」といったポジティブ意見が中心だった気がします。

確かに、これまでの開発環境と大きく異なるため、「まだまだ対応するのは難しい」という意見は良く分かりますしかし、「対応」と「キャッチアップ」は別であり、普通にキャッチアップをしていれば、この流れは不可逆であり「今後、元に戻ることはない」と確信していなのは、むしろヤバいと感じることでしょう。

しかし、はてブTwitterFacebookコメントを見る限りでは、素人ではなく、現在Web仕事をしている人ですら、「流れが早くてついて行けない」「もう少し様子を見ておいた方が良さそう」といった日和見意見を述べており、「日本エンジニア大丈夫なのかな?」と僕は不安を覚えてしまいました。

なぜ、変化への対応がここまで遅いのか。

「なぜ、変化への対応がここまで遅いのか」という理由を考えてみて、「プログラミングが好きではない職業エンジニアが増えている」などが思い浮んだのですが、根本となる最大の理由は「英語しかドキュメントがない」ためだという結論に至りました。

この組み合わせが異常、というのはやってみると実際そんなことない。React と Redux 以外はただのツールなので、どれも半日あれば使いこなせるようになる

naoya のコメント / はてなブックマーク

id:naoya さんもこのように言っていますが、僕もReactとReduxは慣れるのに時間がかかるものの、それ以外は、単なるメソッドや、ツールしかないで、習得するまでたいして時間がかかるものではないと思います。なので、難しいという意見の大半は、おそらくまだ試していないのではないかと思います

では、実際に試すと、どの程度の期間で習得できるものなのか、ちょうど良い例があるので紹介しましょう。

英語ができれば、プログラミング初心者でも4ヶ月で React + Redux + Electron でアプリが作れる。

Urai君の写真

Urai Masato君いう若者がいます。彼はTOEIC940点の文系大学生プログラマによるブログというブログを書いており、タイトルからも分かる通り、文系大学学生で「英語はできるけど、プログラミングはまったくの素人」という学生でした。

そんな彼は、僕の友人が経営する語学学校サウスピークに去年の夏頃に留学し、TOEIC940点という素晴しいスコアマークしました。そして、日本帰国してから就職まで時間があるのでプログラミング勉強をしようと思ったとき、僕の友人に相談したのをきっかけに僕と出会いました。

僕は近年「プログラマ英語必須というけれど、プログラミングを覚えてから英語勉強するよりも、英語を覚えてからプログラミング勉強をした方が圧倒的に学習効率が良いのではないか」と考えていました。そんなとき、彼と出会った僕は、僕の考えを検証できる良い機会だと思ったので、彼に対して、次のような提案しました。

彼はこの提案に対して「ぜひ、やってみたい」と答えたので、去年の11月から英語プログラミングを学ぶと、どれくらいの早さで学習できるのか?」という実験がスタートしました。

その結果は、

という記事にまとめられていますが、主にJavaScriptを中心に学習した結果、

といった風に、本当にプログラミングをまったく書いたことのない状態から、4ヶ月でElectronを使ってはてなブログに記事を投稿できるデスクトップアプリケーションを自作するまで成長しました。

僕が言うのもなんですが、これは異常に早いと言っても良いのではないでしょうか?僕は正直、危機感を覚えたくらいです。

彼に英語記事課題を与えてみて分かったことは、

ということです。記事を読む早さは、本当にびびるくらい早く、例えば、ブラウザレンダリングの仕組みを学んでもらおうと思ってConstructing the Object Modelという記事を与えると、半日もかからず読んで理解するという感じです。そんなわけで、予想を大きく上まわるスピード学習課題を消化されたため、新しい課題を探すのがとても大変でした。

他にも、UNIX/Linuxコマンド英語学習すると、pwd は「Print Working Directory」の略なので、そのまま英語意味からコマンド名を覚えることができるなど、様々なメリットがありました。

再現性がないため、純粋比較は難しいのですが、僕がこれまで教えた経験から判断によると、やはり「英語を先に学んでからプログラミング勉強した方が、圧倒的にプログラミング学習効率が高い」という結論に至りました。

この経験自分の中で新しい確信と素晴しい価値観を生み出しました。そこで、Urai君のような若者もっと育たいと思いサウスピークに相談してみたところ快諾を得たので、今年度からまったく新しくエンジニア育成プロジェクトをやってみることにしました。

英語Webエンジニアリングを学ぶ、サウスピーク「光速Webエンジニアプラン

世の中にはITブートキャンプと呼ばれる短期間でITスキルを学ぶサービスや、IT留学プランなる英語プログラミングを同時に学ぶサービスがあります

しかし、今回企画した「光速Webエンジニアプラン」は、それらとは違い、まずはスラスラと英文が読めるまで本気で英語勉強してもらい、その後でプログラミング勉強を開始します。これは、先に述べた通り、プログラミング学習には、英語を読めることが、圧倒的なアドバンテージを生むためです。

『英語ができない人』と『光速Webエンジニアプラン』の学習曲線イメージ図

このアドバンテージイメージ図にしてみると上記のようになります。Aの場合半年間の学習アドバンテージがありますが、英語をスラスラ読めるBでは、情報量に圧倒的な差があるため、個人差はありますが、Aの3倍のスピードで成長したとします。

そうすると、半年遅れにも関わらず、Bはプログラミング学習を開始して3ヶ月後にAを抜き去ってしまます。そして、新しい技術が増え続けるIT業界では、英語による情報格差が縮まることはなく、逆に開く一方であるため、2年後、3年後には、とても比較ができないほどの差が生まれることになります

このプラン詳細は、1年で最先端Webエンジニアになれる、サウスピーク光速Webエンジニアプラン【先着10名、5月末まで】をご確認ください。

1年で最先端Webエンジニアになれる、サウスピーク光速Webエンジニアプラン【先着10名、5月末まで】

最後に、4月9日技術評論社から、僕も寄稿した仕事ですぐ役立つ Vim&Emacsエキスパート活用術という本が発売されましたので、興味のある方はぜひどうぞ。

藤澤藤澤 2016/04/10 20:57 同感です。
ただ使わない使ってる見たことがないという人はレベルにいないことを理解してないまたは認めたくないのかなと、最近は思うことにしてます。
みんながみんなそうじゃないので安心してください(੭ु´・ω・`)੭ु⁾⁾
さすがに940点の子のレベルには到底なれませんが笑なりたいですけどね

tomoyatomoya 2016/04/10 21:13 それなりの批判覚悟で書いた記事だったのですが、はてブやTwitterでは僕が思ったよりも肯定的な意見が多いようなので、日本の未来もまだまだ明いのでは? と少し思えるようになりました。

YMDYMD 2016/04/11 10:22 僕の職場では日和見な人が多い理由としては英語がわからないにプラスして
受託開発
だからってのが大きいですね。

人月どれだけ積めばいいかわからない、とか、そもそもお客さんにこの技術使っていいか
確認しなきゃだめ とか ・・・

増田治雄増田治雄 2016/04/11 19:33 Seasideを使われた事は有りますか?
Drag & Dropで画面を構築でき、Smalltalkだけで処理を記述できます。
もし使われた事がないんでしたら、あなたも技術について行けてない方と変わらないと思いますが。

Shogo WadaShogo Wada 2016/04/13 20:33 確かに、流れが早くてついていけない、という心持ちはあまり好ましくないかもしれませんね。業界全体がJavaScriptに向かっているのは確かなので、今後もフロントエンドをやりたいなら、JavaScriptは学ばなければならないのかもしれません。Rubyという選択肢もありますが。

ですが、海外でも未だにその開発環境は好ましくないという意見が多いですよ。特に批判が多いのは、この記事でも言われている通り、依存しなければならないライブラリーが多いことです。NPMだと、普通のプロジェクトでも千以上のライブラリーに依存しなければならないことが多いですからね。
依存が増えると、リスクも増えます。長期的に維持しなければならないプロジェクトの場合は、長期的に依存の管理もしなければならないので、さらにリスクが増えます。そして、ビジネスの中で生まれるプロジェクトは、ほとんどが長期的な管理が必要なものです。
特にleft-padの事件があったときには、多くの開発者がこのことについて語っていました。依存の多さに肯定的な開発者は、あまり見たことがありません。こんな皮肉も流行りました->https://twitter.com/yogthos/status/713090123894796288

無条件で慣れ親しんだ技術に固執するのはダメですが、無条件で新しい技術に固執するのもダメですよね。

結局、他に使えるものもないから使うんですけどね😊ただでさえ進化が早いプログラミング業界の中でも、今一番進化が早い分野なので、今後が楽しみです。

YumaInauraYumaInaura 2016/04/14 23:35 ive thought know how to use, how to readl English is very important factor for programers.
But other people dont think same.

If Japanese document and English document both exist, Japanese programers select to read Japanese naturaly.
I wonder.

I hope all programers write and communicate in English only!

2016-04-03 暑い日。

10年のツケを支払ったフロント界隈におけるJavaScript開発環境(2016年4月現在)。

15:36 |

2015年CSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います

最初結論を書いておくと、

『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』

という組み合わせが、いま僕の採用しているJavaScript環境です。

主要ライブラリは React

去年、一気に普及したReactは、今年に入っても絶好調です。他のライブラリや、Angular 2など、色々と騒がれていましたが、去年1年間で個人的に当面はReactに完全決着したと思っています。数年前は、jQueryが使えないとフロント仕事は難しいと言われていましたが、これからはReactが使えないとフロント仕事は難しいと言われることになるでしょう。

Reactはブラウザで動作するアプリケーション以外にも、React Nativeによるモバイルアプリ開発も行えますので、今後ますます成長していきそうです。

アプリケーションフレームワークは Redux

Reactで本格的にアプリケーションを開発する場合フレームワーク必要です。Reactの普及にともなって、Fluxや、Fluxxorなど様々なフレームワークが乱立しましたが、現在首位に立っているのは、Reduxだと感じています

僕も最初Fluxで開発していたのですが、その後、Reduxが登場し、評判が良いので全面書き換えを行ったのですが、その便利さがとても良く分かりました。Fluxではdispatch, store, actionなどの処理を結構地道に実装していく必要があったのですが、Reduxの場合Fluxのときと比べて50%くらいのコード量で同じ機能実装できました。

まだ、完全決着とはいかないかもしれませんが、これから開発される方は、とりあえず Redux で始めてみるのが良いと思います

ルーティングは react-router

React + Redux アプリルーティング必要場合は、Redux と同じコミュニティで開発されている react-routerを選択しておけば、まず間違いないでしょう。最近v2リリースされたので、これから利用しはじめる場合は、そちらを利用しましょう。

UIフレームワークは material-ui

UIは好み応じて選択すれば良いと思いますが、オススメ個人的に React を本格的に利用するようになったきっかけとなるのが material-ui です。GoogleMaterial Designを React コンポーネントによって再現したフレームワークで、フロントアプリ開発が爆速になります

見た目とかそういうのではなく、とにかくHTMLCSSを一切書かずに、用意されたコンポーネントばんばん配置していくだけで、アプリケーションができていくため、UI設計に完全にフォーカスできるのが最大の利点だと思っています

HTTP Request は axios

axiosを利用する前は、superagentを利用していたのですが、Promise ベースの方が楽なので乗り換えました。superagentのときと比べて、XHRまわりで悩まされなくなりました。

記述は ES2015(ES6)

JSは書きにくい、という意見からCoffeeScriptTypeScriptなどのAltJS採用するプロジェクトも多くなりましたが、去年ES2015がリリースされたお陰で、本家原点回帰する流れができたような気がします。

後述するBabelなどビルド環境が整ったお陰で、積極的にES2015の構文が利用できるようになった事も大きいのですが、実際にES2015を書いてみると、とても書き心地が良く、これが普及要因だと思っています

個人的には、これからJavaScriptを覚えたいという人は、最初からES2015で覚える方が良いでしょう。

ビルド環境は Babel + webpack

ビルド環境についても、色々な動きがありました。トランスパイラは、BabelがReactをサポートしたことなどもあり、完全に一本化した感がありますが、ビルド処理は、Grunt、Gulp、Browserify、webpackなどのツールを、どの組み合わせで選択すれば良いのか、本当によく分かりませんでした。

ただ、最近海外を中心に webpackに一本化する動きが広がってきており、僕もこの流れに乗っています。開発サーバーもwebpack-dev-serverを利用すれば、簡単に用意できるところも実にナイスです。

文法・構文チェックは ESLint + Airbnb JavaScript Style Guide

ES2015やReactを利用して開発するということは、大袈裟に言えば、必要となる構文知識が単純なJavaScriptの3倍になると言えます大袈裟)。せっかく新しい構文、新しいライブラリを利用して開発するのであれば、新しい構文に早く慣れたいものです。そこで役に立つのが、ESLint + Airbnb JavaScript Style Guideの組み合わせです。

ESLintは、厳しめの構文チェッカで、設定が多いことでも有名でしたが、最近プラグイン形式第三者作成した設定を簡単にインポートすることができるようになり、とても使いやすくなりました。

中でも、Airbnb JavaScript Style Guideは、ES2015とReactの構文を、かなり前のめりでサポートするように設定されているため、警告に従って修正していれば、古いスタイル記述強制的にどんんどん新しくなっていき、速攻で新しい構文を学習できるため、とても助けられました。

Atomを利用している場合は、linter + linter-eslintプラグインを入れておくと良いでしょう。

テストは…

テストはまだどれが良いのか決まっていません。なんとなく、jsdom + chai + mocha を利用してみたりしていますが、Rubyテストについては揺れていますので、一本化は難しいのかもしれません。

まとめ

去年1年はフロント回りの激しい流れに、多くの方が翻弄されたのではないかと思いますが、個人的には落ち着いてきたように見えてきました。

学習コストは一気に跳ね上がりましたが、逆に言えば、Web進化が激しい中、10年前からほぼ変っていなかったフロント回りの技術が、いよいよ時代に追い付かなければならなくなり、去年みたいな大変革が起きたと思えば、とても自然な流れと言えます

流石に今後は、去年のような激しい変化は起きないと思いますので、フロント回りを静観しておられたかたは、ぜひ今年で一気に追い付くと良いでしょう。

追記

これから時代を支えるエンジニアを育成する1年で最先端Webエンジニアになれる、サウスピーク光速Webエンジニアプラン【先着10名、5月末まで】という事業をやってみることにしました。興味のある方はぜひこちらもご欄ください。

1年で最先端Webエンジニアになれる、サウスピーク光速Webエンジニアプラン【先着10名、5月末まで】

JSJS 2016/04/27 15:30 フロント>サーバサイドも多少>5年後以降には将来はアプリ制作も考えたいと思っている者です。
絶対的な答えはないので、沢山の方の意見が聞きたく質問しています。

HTML5>CSS3>jQueryとやってきたのですが、その後どう学んでいくか迷っています。

その後どうするかがわかりません。
候補は下記ですが、

・リアクト
・メテオ
・タイプスクリプト
・jQueryはオワコンのようなので、JSその物でフロントを一年ほどやり、その後サーバサードをやる事になった時に、エクスプレスかメテオをやる。
・jQueryはオワコンのようなので、JSその物でフロントを一年ほどやり、その後サーバサードをやる事になった時に、英語の読み書きをやってメテオをやる。

リアクトはサーバサイドは出来ないようなので、いきなりメテオが出来れば一番合理的なのかなと思っていますが、重くて小中規模のサイトには向かないのと、
本を買って学べば何とかなると思っていましたが、日本語の本もほとんどないという事なので数年は手が出せない物なのかなと思っています。

リアクトをお勧めておられるので、サーバサイドのみ出来ないようですが、JSの基礎をやった後にすぐにリアクトを始め、
その後サーバサードをやる事になった時に、エクスプレスかメテオをやるのが一番でしょうか?
小中規模のサイト制作を請けるフリーランスか小規模企業での仕事を考えています。

それでは、今後も勉強になる記事を楽しみにしています。
頑張ってください。

2016-01-18 日本は雪らしい日。

出版までの道のり 2016 出版社から選ばれる時代から選ぶ時代へ。

08:59 |

技術書の本棚

本を出版すると、人からよく「どうやって出版したんですか?」と聞かれました。もちろん、自分自身出版するまで、どうすれば出版までこぎつけることができるのか、未知の道のりでしたので、質問する気持ちは良くわかります。

同様の質問として「どうやって会社を立ち上げられたのですか?」という質問もありますが、これも似たようなものです。どちらも回答としては同じで、結局のところ本を出したいのなら「まずは書く」、会社を立ち上げたいのであれば「まずは登記する」。つまりは行動ありきであることが、実際にやってみれば良くわかります。

ただ、出版場合だと、書いたとしても「出版社を見つける」という重要かつ難しい課題が残されていました。しかし、最近この課題重要ではなくなってきました。それは電子出版という選択肢が登場したからにほかなりません。

電子出版の現状。

もちろん、電子出版と紙の出版にはまだまだ大きな違いがあります。電子と紙を比べた場合デメリットは以下のようなものがあります。

ただし、電子は紙に比べて、一切の費用負担を掛けず、また出版社を選ばずに市場価値を問えるという、紙にはない魅力があります。

これを踏まえた上で、私が考える2016年から出版への道のりを述べていきたいと思います。

出版への道のり

大筋の手順としては、次の通りです。

  1. テーマを決める
  2. 目次を作る
  3. 書く
  4. 画像素材を揃える
  5. 校正する
  6. 電子版を作成する
  7. 校正する
  8. Amazon電子出版する
  9. 宣伝する
  10. 売上データをまとめる
  11. 出版社コンタクトをとる
  12. 出版社を決める

方針としては『書きたいものを書く』という気持ちを最優先事項として、方法を考えます。その上で導かれる僕の中でのベスト方法が上記になります。

この方法の良いところは、電子である一定部数の売上を確保しておくことで、紙で出版した場合の売上規模を予測しておきます。そのため、出版社にとっても無名の著者であっても、リスクをとれるようにしておくことが肝要です。

出版社人間サラリーマン

考えてみれば当たり前ですが、出版社編集者会社所属するサラリーマンです。そのため、上司からハンコを貰わなければ、話はひとつも前には進みません。

そして、ハンコを貰うために最も有効判断材料は、決裁権を持つ人からの『それ、売れるの?』という疑問に対するアンサーであることは、言うまでもありません。

つまり、先に最大の障害を取り除いておくことで、議論を円滑に進めることができるようになります。

出版社から選ばれる時代から自分出版社を選ぶ時代へ。

WEB業界を支える技術書フェア

さて、電子書籍の登場によって、これまでは、出版社から選んで貰わなければ難しかった出版フローに上記の選択肢が加わった結果、私の中で確たる気持ちが芽生えました。

それは、出版社から選んで貰うのではなく、出版社を選ぶ時代がきたのだということです。

出版コンテンツビジネスですが、コンテンツビジネス打率はとても低く、3割バッターで優秀なプロデューサーという説が一般的です。

そんな厳しい現実の中で、すでに市場から評価を獲得しているコンテンツというものは、金の宝箱と言えるでしょう。

みんなが開けたい金の宝箱があれば、あとは誰に鍵を渡すかを決めるだけです。つまり、どの出版社作品を預けるか、よくよく吟味して決めることができるようになるのです。

出版社を選ぶ基準

出版社を選ぶ基準は、人それぞれだと思いますが、参考までに個人的基準とその理由を述べておきたいと思います。

  1. 担当編集情熱
  2. 好きな出版社

担当編集情熱は、とても重要だと感じています。本を作るという作業は、かなり気の遠くなる作業です。そのため、もし編集さんのやる気がなければ、最悪、作業頓挫し、作品が世に出ない可能性も大いにあります。

他にも、良い編集さんに当たれば、著者のレベルがまだその域に達していなかったとしても、プロ校正スキルにより、立派な作品へと昇華して貰うことが可能です。

WEB+DB PRESS Plusシリーズ

僕は、技術評論社池田さんのお世話になることが多いのですが、個人として、とても成長させて頂けたと強く実感しています。

もし好きな出版社があれば、ぜひそこと交渉しましょう。もちろん、自分の本がその出版社ブランドイメージから外れていれば、可能性はありませんが、ちゃんと出版社もつブランドマッチしていれば、好きな出版社の方が話は早いはずです。

また、好きな出版社から本を出すことは、自らの喜びにも大きな満足感を与えてくれます。出版社会社ですので、予算の状況に応じて、発売のタイミングはまちまちですが、待てるのであれば、やはり好きなことろから出すのが1番良いと思います。

出版社とのコンタクト方法

特に好きな出版社がない場合は、基本的に全部の出版社コンタクトを取り、タイミングや条件を比較して検討すると良いと思います。

これは、紛れもない営業活動ですので、その際には、名刺数字のあるプレゼン資料をもって行きましょう。

コンタクトの取り方も通常の営業と同じです。メール電話などてアポを取り、直接会って資料を見せる。もちろん、メール電話の際にも、目的数字を完結に伝えておきましょう。

まとめ

近年は、個人の時代だと言われていますが、出版電子出版の登場によって大きく変化してきています。

もちろん、まだまだ過渡期であり、出版業界の今後の状況についてはよくわかりませんが、本がなくなることはありませんし、情報があふれてきている現代からこそ本の価値が見直されてきます。

価値の高いコンテンツを公開することは、個人のブランドにも大きくプラス寄与しますので、もし時間と興味がある人は、ぜひ試してみると良いでしょう。

<< 2016/06 >>
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30