生存報告
久しぶりに記事を書く。 生存報告を兼ねてます。
最近は、研究の方が結構忙しい...。 先週行った実験がそこそこの結果が出て、国際会議向けに論文を書くことにしたけど、提出までの期限があと2週間弱。 国際会議の中ではレベルが高い訳では無いらしいけど、言うて国際会議だし査読はちゃんとあるし気合い入れなきゃいけない。
結果は出ているけど、「もしかしたらもっと良くなるかも?」という願いから、 色々なデータやそれらを組み合わせたりして実験しながら執筆したり、関連論文読み漁ったり。
何が大変って、説得力のある論文を書くことと、それを英語で書くこと(文章力皆無 & 英語苦手) とは言っても、研究室の先生が英語得意だから、どれだけその先生に上手く頼れるかが勝負かも。研究もチームプレーですね(?)
勿論、他の事も手を止める気はないので、全て平行してやろうとしているけど、タイムマネジメントが難しい...。 ここ1週間は効率重視で早寝早起きを心掛けていたけど、今日はオールになりそう。 でも、ここで妥協したら後悔するだろうし、踏ん張ろう💪
研究していた
ここ3日間くらい、少し研究重めにやりつつ、会社の課題やったり、アルバイトやったりでした。
そのおかげあって、研究も大分進んだので、近い内にまとめて先生にぶつけてきたいと思います。 もう少し追加実験するかもだけど、形になってきたし論文出せそう。
やっぱり、自然言語処理もすごい面白い分野ですね。 研究してて純粋に楽しいのもあるけど、今後もっと伸びていく分野でもあるし、 他の技術と組み合わせることで色んな可能性が開けてワクワクします。
Twitter APIと自然言語処理で、話題の技術情報とか取得してきてくれるBotとか作ったらどうだろうとか考えてたり...。
あとは、研究するのにCGP Traslation APIとか使ってたけど、 まだ無料トライアル分のクレジット残ってるし、せっかくなので他のも触ってみたい。
色々やることあるけど、全体的に前よりはイイ感じで手が回り始めたので、もっとギア上げていきたい。
ずっと研究と開発してた休日
題目通り、ずっと研究と開発のループしてた休日でした。
集中してたら、いつの間にか休みが終わっていた感じ。 集中できたのはいいけど、これはこれで悲しい(笑)
最近、課題やったり開発したりして大分フロントエンドに慣れてきたけど、 ライブラリ周りの知識が少な過ぎると感じているので、この辺りの調査もしたいなと思っているのと、 やっぱり理解を深める良い方法は実際に実装することだと思うので、個人開発もしていきたい。
react-native-modal
今日は、React Nativeのモーダル関連の話。
先日、react-native-modal
というライブラリでモーダルを実装したんですが、
「iPhoneでは大丈夫なのに、 Androidでカクついてしまう」という状況が起きてしまいました。
その他の背景を簡単に状況を整理すると、
- モーダルを出したい
- モーダルを出すアニメーションは特に要らない
- バックグラウンドで、いくつか非同期処理が動いている
- Androidでカクつく
という感じ。(なぜAndroidだけなんや...)
react-native-modalとは
そもそも、react-native-modal
とは何なのか。
GitHubはこれですね。
ReactNative標準のModalをラップして、主にそののアニメーション周りを簡単に扱えるようにしたものらしい。
アニメーションの指定はreact-native-animatable
で定義されたものに加えて、自分で定義したアニメーションも指定することができます。
結局、どう解決に持っていったのか
結論を言うと、標準のModalでanimationType="none"
を指定してアニメーションを切りました。
アニメーションを扱う必要が無いのであれば、標準のものを使っても何も支障は無いと判断しました。
他の案としては、
- react-native-modalの
useNativeDriver
をONにする方法 - 一瞬で出現する/消えるアニメーションを自分で定義して、それを使う
辺りが挙げられましたが、結局アニメーションしないなら要らないだろうと思いました。 (本当はreact-native-modalを使いつつ、アニメーションOFF設定ができれば良かったんですけど、その術は見当たらなかったです。)
雑用したり、課題したり
最近やっていることの一つに、内定先のJavaScript関係の課題をしているのですが、これが結構難しい。
特に、メリット/デメリット等の考え方が問われる問題が難しくて、 調べたり考えたりするのにも結構時間掛かるし、文章をまとめるのにも時間が掛かる。
課題毎に想定時間みたいなものが書かれているんですが、その何倍も時間が掛かっている...。1ヶ月とか優に超しているので辛いお気持ち。 (先輩は以前これを2日で終わらせたらしいので、その凄さを身をもって体感しています。だいぶバケモノ。)
でも、頑張って考えて、自分なりの考えを持てた瞬間が結構気持ち良くて、少しずつだけど成長している実感はあるのでそれが救い。 明日も頑張っていこう。
Reactとimmutable.js
生活習慣が後ろにズレまくってて辛い...。
今日は、以下の記事を読んでイイなと思ったので、共有したいと思います。 WantedlyのReact(+Redux)とimmutable.jsを組み合わせることで、こんなメリットがあるよという話です。
詳しくはリンク先のページを見てもらうとして、簡単にまとめると以下の2つのメリットがあるみたいですね。
- パフォーマンスの向上
- シンプルな記述
パフォーマンスの向上
この旨の記述は、公式の方でも言及されています。 ただ、読んでみた所「immutable.jsを使って状態管理をすれば、状態オブジェクトの"参照"を確認するだけで変更を検知できるようになるから、パフォーマンスが向上しますよ。」 みたいなこといってますね。
確かにそうだけど、まぁこれはReduxを導入していれば誰でもやっていることですね。
シンプルな記述
これは個人的にかなり魅力的です。
ReduxではReducerで現在の状態+差分情報を受け取って、新しい状態を返しますが、その時Object.assign
やスプレッド演算子を使って何やかんやするんですよね。
これで書くと、特にネストが深くなると記述がゴチャゴチャしてくるんですよね。
でも、immutable.jsのRecord
を継承させて状態オブジェクトを作れば、その辺りが簡潔に書けるようになると思います。
他にも、モデルをRecord
を継承させたクラスにすることで、色々と便利になりそうです。(昨日も同じようなこと書いた)
また新しくプロジェクトを立ち上げる時は、状態部分とモデル部分にimmutable.jsを導入してみたいと思います。
関数型とオブジェクト指向
もう最近割と辛みを感じていたんですけど、だいぶ回復しました。
今日は、最近携わらせていただいているプロジェクトを進めたりしていましたが、 ここでは少し前に考えていた「関数型とオブジェクト指向」について少し書いてみようと思い立ちました。
概要
関数型も、オブジェクト指向もプログラミングパラダイムのことです。 (プログラミングを書く時の"考え方"のことですね。他には手続き型とかあります。)
多分、エンジニアなら"オブジェクト指向"は誰でも聞いた事があるのではないかと思います。 Javaとかがその代表格ですね。
"関数型"は少し前まで自分も全然知らなかったので、結構知らない人も多いのではと思います。 有名なのはHaskellとかですかね。
上に挙げた2つのパラダイムは並列関係にあるので、よく「どちらを使うべきか」みたいな議論が起きたりしています。 どちらかを選択して、もう片方を切り捨てる考え方ですね、自分も少し前までこの考え方してました。
でも、実際にはこの2つのパラダイムは共存は可能らしいんですよね。 すると、次は「どう共存させるのか」という問題になります。
2つのパラダイムをどう使い分ける?
※あくまで、現時点で自分が考えていることなので、鵜呑みは厳禁でお願いしますね
結論から言うと、ベースとして関数型を採用して、論理的にデータをまとめたい時にVariable Objectsパターンを採用したクラスを使うと、 それぞれの良さをいい感じに引き出せるんじゃないかなと思っています。
Variable Objectsパターンについて、詳しくは以下を見てもらうとして、 個人的な感覚としては、状態が不変かつメソッドに副作用のないオブジェクトみたいな認識です。 そして、これが関数型の考え方とすごくマッチしている気がするんですよね!!
因みに、JavaScriptのプリミティブ型には、このパターンが採用されていると思います。(多分)
関数型をベースに使っていると、「データとデータ」や「データと振る舞い」の間の結合が緩くなりがちなので、 そういった時にVariable Objectsパターンを採用したクラスを導入することで、関数型とオブジェクト指向、両方の恩恵を得ることができると思います。