React Native | SEO-LPO.net

ヤフー主催の学生ハッカソン「HACK U 2021」の最優秀作品2点発表、傾向の変化も解説

2021年8月、ヤフー主催学生ハッカソン「Hack U 2021」が2回に分けて開催された。いずれもオンライン開催で、合計54チームがエントリーしたが、チームのメンバー同士も集まることが禁止された完全オンラインの状況での参加となった。ヤフーは10月5日、その最優秀作品2点を紹介するとともに、2020年と2021年の参加者の傾向を分析し、ブログ記事「学生たちがハッカソンで使う技術トレンドは半年で変わったか？」で発表した。

ヤフーは、Hack Uを「夏の風物詩のようなものにしたい」と考えつつ毎年開催を続けているとのことだが、今回は両日とも1日で申し込みが埋まってしまうほどの人気だったという。小学生以上の学生なら誰でも参加でき、サポート役としてヤフーのエンジニアが付くという親切なイベントになっている。審査基準は、新規性（オリジナリティー）、技術性（技術の高度さ）、発展性（将来性や波及効果が期待できるか）、再現性（実現可能なアイデアか）の4つ。ブログでは、最優秀賞を獲得した2つの作品が紹介された。

「スローターム」（チーム名：この素晴らしいコードに祝福を！）

開発時に発生するプログラミングのエラーをワンタップで共有してくれるVisual Studio Codeのプラグインと、共有先のSNS両方を作り上げた作品。コード制作中にエラーをハイライトするだけで、GitHubでの質問文が簡単に作れる。さらに、その質問にうまく答えてくれそうな人を自動的に選んでつなげてくれる。コロナ禍で人に質問がしにくくなった問題を改善してくれる。

3pt Manager（チーム名：OAO）

バスケットボールの3ポイントシュートをiPhoneで練習できるアプリ。シュートするごとにiPhoneがボールの軌跡を取得し、角度のデータを蓄積する。毎日の練習結果がグラフ化されるので、効率的に練習ができるというものだ。

参加者が使用しているプログラミング言語と開発環境の傾向

同ブログでは、2020年と2021年のHACK Uで、参加者が使用しているプログラミング言語と開発環境に違いがあるかを分析している。使用言語は、どちらもJavaScriptとPythonがトップと変わらないが、2021年はRubyが上位に入ってきた。2020年はRubyを使うチームは1割に満たなかったのに対して、20201年はPythonに次いで3位に上がってる。その理由は、大学の年次に関係があると、筆者であるヤフーCTO室Developer Relations Hack Uプロデューサー中村友一氏は書いている。参加学生は大学3年生が中心だが、去年2年生だった学生は、授業などで手軽に始められるRubyを使う機会が多くなったからだとの分析が面白い。

ヤフー主催の学生ハッカソン「HACK U 2021」の最優秀作品2点発表、傾向の変化も解説

View Slideshow

Previous Next Exit

開発環境については、Flutter、React Native、Xamarinなど多くのOSに対応できるクロスプラットフォームフレームワークを利用するチームが増えたのこと。iOS、Android、ウェブのすべてに対応するソフトウェアの開発を目指すということは、チームが継続開発やサービスの公開を考えているためだと中村氏は分析した。

また同氏は、Dockerの浸透を挙げている。今回、Dockerを使いサービスのデプロイまで考えて作ってきたチームが大幅に増えたという。Dockerが学生にも浸透し始めていることがうかがえ、今後ハッカソンにおいても環境構築におけるメインストリームになるかもしれないと指摘している。

この2年間はオンライン開催のため、参加者同士の交流が制限されたが、「今後ハイブリッド開催になった時にどのように変化するかが楽しみです」と中村氏は話している。

マイクロソフトが「React Native for Windows」を公開

米国時間5月6日、Microsoft（マイクロソフト）は、React NativeのデベロッパーがWindowsをターゲットにするための新しいオープンソースプロジェクトを発表した。「React Native for Windows」と自然に名付けられたそのプロジェクトは、MITライセンスの下でReact Nativeを「性能を重視して」実装することを目指す。

Facebook発のクロスプラットフォーム開発フレームワークであるReact Nativeを使ってWindowsをターゲットにするのはこれが初めてではない。デベロッパーがJavaScriptでコードを書き、AndroidとiOSで動かすことのできるこのフレームワークには、Windowsおよび macOSをターゲットにするためのプラグインと拡張機能がすでにある。

React Native for Windowsでは、MicrosoftがReact Nativeを再実装し、多くのコンポーネントをC++で書き直すことによって最大の性能を引き出そうとするものだ。デベロッパーは、PC、タブレット、Xbox、複合現実端末などさまざまなWindows 10デバイスをターゲットにできる。プロジェクトをMicrosoftがバックアップしていることで、デベロッパーはより高性能で柔軟性の高いアプリをユーザーに提供できるようになる。

プロジェクトはGitHubですでに公開中で、デベロッパーはテストが可能。完成度の高いバージョンが近いうちに提供される予定だ。

[原文へ]

（翻訳：Nob Takahashi / facebook ）

ネイティブアプリ開発者は絶滅危惧種なのか？

最近ちょっとおもしろいことに気づいた。5年ほど前なら、新たな仕事で頼りになるiOSの経験豊かな熟練開発者は、少なくとも金の卵を生むユニコーン企業と同じくらいには簡単に見つけることができた。それが2年前になると、そんな人を見つけ出すのはかなり難しくなった。そして今年は？もしかすると、ランダムなノイズのようなものかもしれないが、今年はそのあたりにいることはいるようだ。あれこれ考えてみると、それも単なる偶然ではないように思えてくる。

App Annieの「State of Mobile 2019」は、「モバイルの成熟」について遠回しに触れている。それは、特定の市場で年間のダウンロード数が横ばいになるような状態のことだ。その報告によれば、米国はその状態に達しているという。米国市場でのアプリのダウンロード数は、2016年から2018年にかけて、5%の微増に留まっている。ただし、アプリから得られる収益は、同じ期間にアプリストア上で70％も増加している。これは注目すべき点だ。

その一方で、iOSのApp Storeのアプリ数は、過去2年間でほぼ横ばいとなっている。これには、Apple（アップル）の承認基準が厳しくなったことの影響もある。それを含めても、収益の増加は注目に値する。

さらにその一方で、非ネイティブでクロスプラットフォームのアプリ開発フレームワークに対する人気が高まっているという事実もある。「マイクロソフトのiOSおよびAndroidアプリの中身をスキャンしてみた。その中で、Word、Excel、Xbox、その他もろもろ38本ものアプリが、最近のアップデートでReact Nativeを利用するようになったことを発見した」と、AppFiguresは報告している。そして「昨年の1年で、React Nativeの利用はほぼ倍増した」という。

聞くところによると、多くのクライアントが、単純なものも、そうでないものも、React Nativeを使ったクロスプラットフォームのアプリ開発にますます興味を持つようになっているという。私は、この動きが必ずしも望ましいものではないと考えている。それについては、数カ月前のExtraCrunchに、こうした判断とそのメリット、デメリットについて書いた通りだ。それでも、Cordova／Ionicに比べれば、まだ少しはまともな選択だろう。そちらについては、ここ数年、何度もひどい経験をさせられてきた。そして、ゆっくりながら確実にPWAが勃興しつつある。

アプリのブームは終わったのだろうか？今日の熟練したネイティブアプリ開発者は、明日にはCOBOLプログラマーのような時代遅れになってしまうのだろうか？もちろん、それほど速い変化ではないだろう。ネイティブの開発ツールや技術も、最近大幅に進化してきた。例えば「SwiftのほうがObjective-Cよりだんぜんいい」と感じていないような人には会ったことがない。

Kotlinはさらに新しいが、Androidアプリ開発にとってはiOSにとってのSwiftと似たような立場にある。そして、いわゆる「ロングテール」の新規アプリ開発が成長し続けているのも確かだ。大規模な消費者や企業向けを対象にするのではなく、かなり的を絞ったビジネス分野向けに開発され、アップデートされるアプリのことだ。

とはいえ、特定分野のアプリ開発だけで生計を立てようとすることには、まだ少し不安もある。特にデベロッパーとしてのキャリアが浅いうちはなおさらだろう。それは、その市場が消えてしまうかもしれなからではない。スマホでしか利用できない、ずば抜けた新技術（例えばARなど）を除外してしまうことになるかもしれないからだ。これまでのような、絶え間のない成長と増え続ける需要は、米国のように成熟した市場では、近い将来には失われているだろう。まだいくらかの成長はあるだろうが、その分は、非ネイティブ開発の増加によって吸収されてしまう。

つまり、App Storeが登場して以来初めて、ネイティブアプリ開発者に対する需要が減少し始めるような未来を、少なくとも想像することが可能となっている。もちろん、それだけが確実な未来というわけではない。それが社会通念になっているというのでもない。5月のGoogle I/Oに群がるAndroidデベロッパーや、6月にWWDCに押し寄せるiOSデベロッパーにも聞いてみるべきだろう。それでも念のため、バックアップ戦略を立てておく価値はあるのではないだろうか。

画像クレジット：Pixabay LicenseによるPixabay

［原文へ］

（翻訳：Fumihiko Shibata）

Android Studioはいつまでこの体たらくを続けるのか？

年に2回程度、私はちょっとしたAndroid開発をすることが必要なプロジェクトに関わっている。そこで、年に2回程度Googleのいわゆる統合開発環境であるAndroid Studioを、祈るような気持ちで立ち上げる。…そして年に2回、それがいまだにエレガントで直感的なRube Goldberg機械（複雑怪奇な仕掛けでちょっとしたことを行うだけの機械）であることに気がついて、苦い失望に顔をしかめるのだ。

私が特定のOSに肩入れしているわけではないことは急いで付け加えておきたい、というより私はどちらかといえばGoogle贔屓なのだ。これまでの私のスマートフォンは全てAndroidだった。最初にHTC Magicを買った2009年以来、私は職業としても趣味としてもAndroidアプリを書き続けて来た。その後もAndroidが続き、Galaxy S2、Nexus 4、Moto X、そしてピカピカのPixelを手にしている。

しかし私は、iOSやtvOSのアプリも書いている。そしてAppleのソフトウェアに対する覇権的態度は嫌っているものの、AppleのIDEであるXcodeを立ち上げると、少しほっとした気持ちになるのだ。それは高速で滑らかに動く。そして、それがあまり上手く動作しないときでも、足手まといになることは滅多にない 、だがAndroid Studioの場合、足手まといになることが基本機能なのだ。

例えば、私はそのビジュアルツールを利用して、スクリーン上に要素を本当に上手くレイアウトできた試しがない。もちろんそれが理論的に可能であることは知っている。しかし試す度に強度のフラストレーションに襲われて、結局XMLでレイアウトを直接書くことになるのだ。これが私1人だけの問題ではないことは確かだ。逆にXcodeでは、自由奔放に楽しく、ドラッグアンドドロップをするだけだ。

最初の状態ではAndroid Studioは自動的にJavaクラスをロードしていない。これを行うためには、不可解な迷路の中に埋め込まれたメニューに辿り着かなければならない。最初の状態では、Android Studioは、おそらく私が必要とする無数のサポートライブラリをどのようにロードすべきかを教えてくれないし、Androidエミュレーター（いまだに耐え難いほど遅い）をどのように実行すれば良いかも教えてくれない。この両者への秘密の扉は、信じようが信じまいが、”Tools”メニューの中の”Android”サブメニューの中に埋め込まれている。このことについて、少し考えてみよう。何故GoogleのフラッグシップAndroid開発ツールに、”Tools/Android”メニューがあるのだろうか？全部がAndroidツールではないのか？これらの重要な要素がメニューである必要があるのか？

…問題の1つは、もちろん、Android Studioがゼロから作られたものではないということだ。それは今やもう年老いたJava IDEであるIntelliJ IDEAプラットフォームに基づいている…まあそれでお分かりだろう。15歳という年齢を感じさせるソフトウェアだし、それはAndroid開発のために作られたというよりも、対応させたということが明らかなものなのだ（”Tools/Android”を思い出してみよう）。そして、もちろんそれはJavaで書かれていて、マルチプラットフォームで動作する…しかし動作は遅い。

Androidのエコシステム自身が、さまざまなライブラリとSDKの、目まいがするような過剰なバージョンへと断片化し、扱いにくくかつ複雑であることは事実だ。例えば、ビルドツールのGradleが開発者泣かせということは有名な話だ（とはいえビルドそのものは難しい。Appleのビルドツールも開発者の手をがっちりと掴んでいてはくれない）。しかし、良く設計されたIDEは、少なくともこの苦痛を緩和できる。Android Studioがマルチプラットフォームでなければならないのに対して、Xcodeは1つのOSだけで走れば良いというのは真実だ。しかし、他でもないGoogleは、マルチプラットフォーム上でネイティブコードをサポートできるリソースを持っている筈だ。

巨大怪物のGoogleが、10億台以上で使われているそのモバイルプラットフォーム向けのフラッグシップ開発環境を、これほどまでに遅く、ツギハギだらけで醜いもののままにしていることは本当に驚異的だ。負の効果は測り知れない。iOSの開発をより早くより効率的にしているものの理由の1つが、良いツールが提供されていることだ。両方のエコシステムに慣れた開発者たちは、AndroidよりもiOSの方を好む。なぜならそちらの方が遥かに使いやすいからだ。そのため私たちはスマートフォンソフトウェアとしてiOSを優先することになり、Androidは二の次になってしまうのだ。AndroidアプリはiOSプリよりも大きくなりがちなことで有名だ、それなのにIDEがそれに対処できないということは信じがたい。

まあ身勝手な話だが、仮にGoogleのIDEが優れていた場合には、Appleに対して改善を迫るとは思う。Xcodeは完璧からは程遠い。クラッシュもすれば、ハングアップもする。しかしそうした欠陥があるとしても、比較するまでもなく、iOSの開発はAndroidの開発よりも遥かに苦痛が少ないものだ。（まあ、それもデプロイしようとするまでの話だが。そこから先はAndroidには苦労がない。Appleの「改善はされたもののしばしば不可解な」、ビルド、署名、アップロード、提出、そしてベータ版ビルドですら承認を待たされるプロセスは、iOS開発者に深い恨みと怒りを引き起こすものだと知っている）。

しかし最近、半ば疑いながらの期待ではあるが、真のライバルが初めて現れてきたようだ。このことは、最近Microsoftによって買収されたXamarinのおかげで、.NETプログラマーたちにとっては既に知られていたことだ。Xamarinを使えば.NETを用いてAndroidとiOSに対してネイティブアプリを作成することが可能になる。しかし最近ではFacebookのRact Nativeが、（あまり沢山の）ネイティブコードを書くことなしに、クロスプラットフォームネイティブコードを書くための現実的なソリューションとなりつつある。すなわちAndroid StudioもXcodeも利用する必要がないのだ。

私はAppleとGoogleの開発環境が消え去ってしまうと言っているわけではない。しかしAppleとGoogleのデファクトで塞がれた道を、誰かが少なくとも押し退けようと努力しているのを見ることができることは良いことだ。彼らは、特に後者は、競争の欠如によって自己満足的に成長してきた。彼らがReactに、どのように対応（react）するかを見守ろう。

[ 原文へ ]
（翻訳：Sako）

「Cola」は開発者が地図やフライト確認などのアプリを自由に付け足せるメッセージアプリ

チャットにアプリを埋め込めるメッセージングアプリのColaは誰でも新しいアプリケーションを組み込めるようにするための開発者キットを公開した。

本日更新されたバージョンには、メッセージングアプリの中で動作する12個の「バブル」と呼ばれる実質的なアプリケーションが含まれている。ユーザーは中で使われる個別のツールのアカウントを作ることなく、天候やフライト情報、GIF、その他の情報を共有することができる。同社が優先するのは他人と基本的なタスクを行う際の壁の高さを下げることである。メッセージアプリを離れることなく2人が共有ToDoリストをチェックする場合を考えてみると良いだろう。

Cola自身が提供する新しいバブルに加えて、開発者はバブル開発キットを用いてメッセンジャーのために新しい機能を作成することが可能だ。AppleのApp Storeと同様に、Colaはユーザーを保護するための承認プロセスを用意している。

10人のチームが、2014年以来Colaを開発していて、ユーザーは今年の3月からアプリケーションを使うことができるようになっている。昨年末に、Naval Ravikantは130万ドルのシードラウンドを主導した。この時はRavikantのAngelListシンジケートも参加しているが、その中にはAOLの創設者スティーブ・ケースも含まれている。

メッセージングクライアントのプラットフォーム化を決意した企業はColaが最初ではない。Heymarketはビルトインされたアプリのようなテンプレートを使用して中小企業が顧客と連携するためのメッセージングプラットフォームを開発しているし、AtlassianのHipChatは、Slackに類似したチームのためのメッセージング機能を提供していて、Dropbox、Github、Trello、BlueJeansそしてUberまでもが統合されている。

市場の空白を探す努力の結果、Colaは消費者をターゲットにしている。そのサービスはユニークではあるものの、それはまだ基本的にFacebookのメッセンジャー、AppleのiMessage、GroupMe、WeChatなどと競合するものだ。

Colaの制限の1つは、コンテンツを発見し送るためにはアプリの中から行わなければならないということだ。例えばGIF画像を送信したいときに、Giphyでそれを開くことはできない。Colaのユーザーがそれを送信するためにはGiphyバブルを使う必要がある。また、統合のメリットを最大限に活用するためには、送信者と受信者の両方がColaをダウンロードしておく必要がある。

アプリのUIは非常に基本的なものだ。とはいえ加えられたシンプルさは欠点を上回っている。私たちが馴染んでいるマテリアルデザインではないが、きちんと動作しわかりにくいものでもない。

エンジニアリングの観点から言えば、各バブルは独自のサンドボックス内で実行されるので、失敗したメッセージがアプリケーション全体を巻き込んでダウンさせてしまうことを心配する必要はない。Colaはそのサービスがスムースに運用されることを狙って、Facebookによって主導されているオープンソース技術のReact Nativeを活用している。開発者はネイティブ「バブル」アプリケーションをJavascriptを使って開発する。

Colaのバブル（泡）は便利だが、クリティカルマスに達するユーザーを引き込むには、何らかのキラーフィーチャーが必要だろう。開発を外部へ公開することによって、利用者が単に欲しいと思うだけではなく本当に必要とする機能をColaが提供できる可能性は高まるだろう。

[ 原文へ ]
（翻訳：Sako）