就職しました
我々の業界では退職エントリを書いて欲しいものリストを晒すと三角コーンが届くそうなので、就職しましたって話をします。
昨年夏に第一子を出産し、そろそろ社会復帰したいなと年末から就活を始め、先日から株式会社キュア・アップにてエンジニアとして社会復帰しました。
「アプリで病気を治療する」という二度見、三度見するような事業にクソ真面目に取り組んでいる（褒めてる）スタートアップ企業です。
会社のモットーは「家庭と仕事を大切に」で、私の勤務形態はリモートワークのパートのおばちゃんと大変フレキシブルなものです。
パートのおばちゃんなので社保も何もありませんが、
- 出社しない
- 通勤もない
- 定時もない
- 時間ではなく実績ベース
- 家で子供の面倒を見ながら無理なく稼働
という、 保育園にも預けられないゼロ歳児を抱えたカーチャンにも優しい働き方です。
サラッと書いてるけど、ここまで柔軟に対応してくれるの本当にすごいことだと思うので、全力でアッピールします。
保育園にも預けられないゼロ歳児を抱えたカーチャンにも優しい働き方です。
大事なことなのでもう一度言いますね。
保育園にも預けられないゼロ歳児を抱えたカーチャンにも優しい働き方です。
すごい！
今後は自社製品のフロントエンド開発に携わっていきます。
さようなら、Flashまがいの頑張りコンテンツ制作。
そういうのはWebGLとかバリバリ使いこなす人たちに託しますので、こちらは任せてください。
現場からは以上です。
モダンなフロントエンド開発を勉強しようと思った
妊娠、出産、育児のため一年近く無職主婦やってたけど、ようやく現場復帰の目処が立ったので、本腰入れてモダンなフロントエンド開発を勉強することにしました。
約一年ぼんやりしていた間にどうなったのかと身構えていましたが、正直、あんまり変わっていないようで。
ES2015（ES6っていうと怒られるやつ）は化石となり、CommonJSは死に絶え、Babelは光の彼方に消え去った世界を想像していたのに、皆さんばっちり現役。
JSフレームワークは相変わらずAngularとReactが人気で、CSSプリプロセッサはSass（SCSS）の一人勝ち、GulpやWebpackもまだまだ使われている模様。
Facebookからyarnというツールが出たようだけど、これがないと死ぬわけでもなさそうなので、しばし様子見。
ツールやノウハウは増えて闇が深まったものの、全体的に進歩してない印象で、思いの外やることがない・・・(´・ω・`)
ということで、NeoVimをインストールすることにしました。
モダンなエディタを使いたいからね！
インストール方法はNeoVimのWikiにあるように、homebrewでinstallするだけ。
brew install neovim/neovim/neovim
あとは黒い画面でそっとnvimと呼んであげます。
簡単だね！
NeoVimはVimとは違って起動時に~/.vimrcを読みにいきません。
今までのVimと設定を共有したいなら、
ln -s ~/.vim ~/.config/nvim ln -s ~/.vimrc ~/.config/nvim/init.vim
とシンボリックリンクを貼りなさいよってhomebrewが言ってました。
とりあえずここまで。
モダンなエディタをモダンに使いこなしたいと思います、まる。
余談
NeoVimが~/.vimrcではなく~/.config/nvim/init.vimを読みに行くのは、XDG Base Directory Specificationという仕様に沿っているからだそう。
XDG（略）なんて聞いたこともなかったのでググってみると、
「XDG Base Directory Specification」はデスクトップ環境における標準的なフォルダー構造を規定した仕様です。
とのこと。 たしかにホームディレクトリにドットファイルが散らばってるのはお行儀良くないし、こういう管理の仕方もいいかも。
npm run-script で実行するスクリプトに引数を渡す
npm2からrun-scriptに引数を渡せると聞いていましたが、
npm run-script hoge --arg1=fuga
とか打ってみてもまるで効いてる様子がなかったので、毎回勝手にpackage.jsonの中身を書き換えて、コミット前に戻すという荒技をかましていました。
しかし先日、うっかり書き換えたpackage.jsonをコミットしてしまい、周りの優しい人たちからやんわりとご指摘を受けました。
「引数は、すぺーすはいふんはいふんすぺーすはいふんはいふんで指定できるよ」
( ﾟдﾟ) ｴｴｪ……
口頭で教えてもらってポカーンとなりましたが、こういうことだそうです。
npm run-script hoge -- --arg1=fuga
なるほど。
ドキュメントよく読めって話ですね。
いままで勝手に書き換えててすいませんでした。
Reactで「閉じろ」と怒られる
たとえば、商品名の一覧を表示したいとき。
list(items){ return ( items.map( item => <li>{ item.name }</li> ) ) } render() { const { items } = this.props; return( <ul> { this.list(items); } </ul> ); }
こんなの、よく書きますね。
これは怒られません。正しい。
上記に加えて、this.props.optionsに値があれば、オプションを表示したいとき。
options(opt){ return ( <dd>{ opt.option01 }</dd> <dd>{ opt.option02 }</dd> <dd>{ opt.option03 }</dd> ) } list(items){ return ( items.map( item => <li>{ item.name }</li> ) ) } render() { const { items, options } = this.props; return ( <ul> { this.list(items) } </ul> <dl> { options && this.options(options) } </dl> ); }
なんて書くと、Adjacent JSX elements must be wrapped in an enclosing tagと怒られます。
Module build failed: SyntaxError: /PATH/TO/YOUR/SCRIPT/FILE.js: Adjacent JSX elements must be wrapped in an enclosing tag
| return (
| <dd>{ opt.option01 }</dd>
> | <dd>{ opt.option02 }</dd>
| ^
| <dd>{ opt.option03 }</dd>
このエラーメッセージを単に「隣り合う要素は単一のタグでラップされなければならない」と解釈してしまい、(・3・)あるぇ〜？どれも<dd>で括ってあるのになぁ〜？などと考えてしまったのですが、そうではなく、「隣接要素たちは単一のタグでラップされていなければならない」ということでした。
隣接要素というのはみんな大好きCSSでも登場する、隣接要素です。
どっちかっていうと兄弟要素な気もしますが。
セレクタでいうとE + *とかE ~ *にあたります。わからん人はMDNでも見てください。
なので、上記エラーを解消するには、
options(opt){ return ( <dl> <dd>{ opt.option01 }</dd> <dd>{ opt.option02 }</dd> <dd>{ opt.option03 }</dd> </dl> ) }
と、<dd>たちを括ってあげれば良いのでした。
なお、さまざまな事情からどうしてもタグで括るという対応ができない場合は、配列にして返してあげると通ります。
listで返しているitems.map( item => <li>{ item.name }</li> )も、結局のところ個々の要素の配列なので、隣接要素という扱いではないのかなと思っています。たぶん。
よく調べてないけど。
Flashが終わった日
Adobe Flash Professionalが、Adobe Animate CCに名称を変更するそうですね。
Flasherを自称できるほどの仕事をこなしたわけではありませんが、私はとにかくFlashが大好きでした。
今でこそJavascriptなんて書いていますが、そもそもフロントエンドに携わるようになったのもFlashがきっかけでした。
仕事は減ってしまったけど、やっぱりFlashが好きで好きでしょうがないんです。
だから（というのも変ですが）この発表を聞いたときは素直に「あぁ、終わったんだなぁ」と感じました。
需要がないとか、見捨てられたという意味で終わったのではありません。
従来のWebにおいてFlashコンテンツが担ってきた役目を果たして、世代交代するんだな、と。
一昔前はアニメーションやインタラクティブコンテンツといえばFlashしかなかったけど、今はそんなことないですからね。
ここ数年でスマートフォンやタブレットなど、Flashを再生できない環境が急増しました。
一方で、HTML5だ！CSS3だ！WebAudioだ！WebGLだ！WebWorkerだ！となんやかんやで新しい技術が次々と登場しました。
Flashでしかできなかったことを、それだけで実現できると鳴り物入りでやってきた子たちです。
彼らの成果のほどはさておき、WebはたしかにFlashに頼らない方向へと流れていきました。
そしてFlash Professionalもまた、多彩な環境への書き出しをサポートするなど、Webではない新しい道を築き始めていました。
両者はゆっくりと、確実に、別々の道を歩んでいました。
だからこそ今回の名称変更は、Webの発展と魅力的なコンテンツの提供に大きく貢献した、Flashという技術の一つの節目のように思います。
Flashはオワコンだという人もいます。
Flash Professionalという名前まで奪われてしまったことで、Flashは死んだという人もいます。
たしかにWebにおけるFlashの役割は終わっていますし、Flash Professionalという名前も消えてなくなります。
そういう意味ではどちらも正しいでしょう。
とはいえ、Webの世界を離れてみれば、まだまだ多くの開発者に愛され、育てられている技術でもあります。
今日を糧に明日にはまた少し成長する技術です。
これが果たして終わっている、死んでいるといえるでしょうか。
Flashの不遇を嘆く人もいます。
こんなに素晴らしいプロダクトが名前まで奪われるなんて、と残念がる人もいます。
私も大好きなので、その気持ちはよくかります。
しかし、先述の通り、WebにおいてFlashは役目を終えたと考えれば、そう悲しむこともない気がします。
むしろそれ以上に悲しいことは、鳴り物入りでやってきた新しい技術たちの未熟さです。
もちろん、今は未熟であっても、いずれは便利で強力なものになるでしょう。
そうやって将来に期待することも結構ですが、私たちの目の前にはそれを使うしかないという現実があるのです。
仕様も決まらず、標準化も進まず、ブラウザごとに独自実装が施されたプレフィクスだらけのAPI、統一されない挙動、端末固有の不具合。
Flashを使わないからといってパフォーマンスに優れるわけでもない。
手間と苦労と検証時間は増えましたが、その結果得られるものは何なのでしょうか。
Flashの不遇なんかより、未熟な技術を押し付けられる開発者の不遇を嘆きたいですよ、私は。
と、まぁ随分と贔屓目でしたが、Flashは終わってるけど死んでないと思うよっていう話でした。
ところでなんでFlashクラスタの人は定期的にFlash死亡説流してはお通夜モードになるんですかね。
マゾなんですかね。
おしまい。
ES6だとクラス直下の変数定義ができない（気がする）
ECMAScriptの流れを汲むActionScriptでは
class Hoge { const HOGE_CONST:String = 'hoge_const'; var hoge:String = 'hoge'; }
こういう書き方ができました。
それならES6でclass構文に対応したよ！とかいってるJavascriptさんだってできるよねって思ったらシンタックスエラー。
仕様書見てもClassBodyに書けるClassElementには[static] MethodDefinitionとしか書いてないので、変数定義はダメそうです。
ECMAScript Language Specification ECMA-262 6th Edition – DRAFT
じゃあどうやって書くかというと、こんな感じのようです。
class Hoge { get HOGE_CONST() { return 'hoge_const'; } constructor() { this.hoge = 'string'; } }
getter,setterを使ったり、初期値を持った変数であればコンストラクタの中で定義するようです。
そういえばActionScriptやHaxeでもそんなことできたなー。
言われればなんてことないんですが、やっぱりちょっと癖がある気がしました。まる。
