CoreOSのTectonicコンテナプラットフォームがMicrosoft Azureをフルサポート

本日(米国時間8月17日)CoreOSは、KubernetesベースのTectonicコンテナ管理プラットフォームの、Microsoft Azure対応を発表した 。これまでは、ベアメタルサーバとAWS上へのコンテナデプロイメントだけが完全にサポートされていた。3月に登場したAzureへのベータサポートに続く今回の新規リリースで、Tectonicはサポート対象の3つのプラットフォームにまたがるマルチクラウドデプロイメントへの統合サポートを提供することになった。

「Microsoft Azureに向けてのTectonicsの安定版メジャーリリースは、マルチクラウドに対応し、インフラと運用をより効率的かつスケラーブルなものにするというお約束に向けた、非常に重要なステップです」と語るのはCoreOSのTectonicプロダクトマネージャーRob Szumskiだ。「Azure向けTectonicは、Kubernetesインフラストラクチャを初めから正しく構築し、展開サイクルをスピードアップすることで、時間とコストを節約します。ハイブリッドクラウドのデプロイメントが可能なことで、インフラストラクチャ責任者たちは、ユーザーをクラウドコンピューティングやクラウドサービスにロックインしないプラットフォームの自由度と柔軟性を手に入れることができます」。

Tectonicのその他のアップデートとしては、Google謹製コンテナオーケストレーションサービスの最新リリースであるKubernetes 1.7への完全サポートも含まれる。最新リリースへのアップグレードはワンクリックで完了し、アップデート中にダウンタイムが発生しないことが約束されている。これはKubernetesの初期版と比べると大きな利点だ。当時はどのようなプラットフォームを選んでもアップグレードは一苦労だった。

また新機能としてインバウンドトラフィックをより詳細に制御できるようにするネットワークポリシーのサポート(アルファ版)が入り、コンテナの展開中に問題が発生した場合のアラートを、あらかじめ設定しておくこともできるようになった。

[ 原文へ ]
(翻訳:Sako)

GMが実際に走行中の車両内で車載アプリのテストを行なう環境を提供

GMは、車載用インフォテインメントシステムで使用するソフトウェアを開発者が簡単に開発できるようにするために、多くのことを行ってきた。1月には、車両からの様々なデータへのアクセスを可能とし、デトロイトに置かれた特定の開発者用ハードウェアを使わずとも、デスクトップでシミュレータを使ってソフトウェアを開発することを可能にした。

そして今回GMは、開発者が実際の車両のリアルな状況の下で、作成した車載ソフトウェアをテストすることを可能にするアプリケーションGM Dev Clientの提供を始める。その機能の中には車が走行中にノートPCを介して、調整を行ったり変更を行なう更新をリアルタイムに行なう機能も含まれている(もちろん操作は運転手ではなく、同乗者によって行われる)。

これは、開発者たちが自動車メーカーのネイティブソフトウェアプラットフォームをターゲットにして開発する手段の大きな変化だ。これまでは、例えばiOSやAndroidのように、開発に対する広範囲の最適化が行われたことはなかった。安全が最優先であることを保証するための制約はまだあるものの、このことによって、車内で使用するためのアプリを構築する際の問題が大幅に削減される。

開発者が車内でテストできるようにするには、まず最初にNGI SDK(今年初めにGMがリリースした、デスクトップ上で仮想インフォテイメント環境を用いた開発を可能にするソフトウェアキット)をダウンロードしてインストールしなければならない。仮想環境上でアプリが出来上がったら、それをGMに提出し内部レビューを受ける。その結果承認されたなら、開発者のAppShopを通してDev Clientを利用できるようにする。開発者はホワイトリスト登録を受けるために、車に固有の車両識別番号を提供する。

この時点で、開発者を積極的にサポートし、車両用のアプリケーション開発プロセスを改善することは、賢い動きだ。GMはわずか6ヶ月でこのプロセスを隅々に渡り大幅に改良した。そしてこの動きは来たる自動運転車ブームに向けて、車内アプリで先行したいと考える開発者たちから歓迎され、その採用を促進することだろう。

[ 原文へ ]
(翻訳:Sako)

Cloudflareがデベロッパープラットホームとその開発努力を支える1億ドルのファンドを創設

Cloudflareが今日(米国時間6/27)、Cloudflare Appsと呼ばれるアプリケーション開発プラットホームを立ち上げ、またデベロッパーたちのアイデアの実現を助けるためのファンド(当初1億ドル)Cloudflare Developer Fundを発表した。

開発プラットホームは、そこでCloudflareのエコシステムを利用するアプリケーションの構築ができ、それらをCloudflare Appsストアに置いたり、またコーディング不要でWebページにマップやフォームなどの機能を容易に配置できる。

CEOで協同ファウンダーのMatthew Princeは、同社上に開発プラットホームがあることの意味をこう説明する: “今のCloudflareは600万を超える顧客のインターネットプロパティの前に座っている〔CDNや他のリバースプロキシサービスで〕。弊社は世界最大のネットワークを稼働させており、データセンターは世界中に115箇所ある。そのネットワークを毎日大量のトラフィックが通っているが、それらが通るときには、それをいろんな方法で変える/加工する方法と機会がデベロッパーにある”。

今回のデベロッパープラットホームは、Cloudflareが昨年12月にEagerという小さな企業を買収したことが契機だ。今日の発表はその買収の成果だ、とPrinceは説明する。

ひとつの例として、ライブのWebページにGoogleのマップを(コードを書かずに)挿入するやり方がある。Eagerの技術を使うとそれは、Cloudflare AppsストアでGoogle Mapツールをクリックするだけだ。そのあとドロップダウンリストからセレクトして、目的の場所へドロップダウンする。ささいなこと、と思えるかもしれないが、なにしろプロのプログラマーがいなくても、誰でも、地図をWebページに加えることができるのだ。その工程は、とても簡単で早い。

1億ドルのファンドの件は、Princeによると、Cloudflareのアイデアではなくて、投資家たちの提案だ。“彼らはとても熱心だった。NEA、Venrock、それにPelion Venture Partnersらは、人びとがCloudflareのプラットホームの構築と拡張に挑戦すれば、そのスケールとパワーを自分でも納得するだろう、そしてそれが、もうひとつのすごい企業を作る機会であることに気づく、と主張するのだ”、と彼は語る。彼らは、Cloudflareをベースとするアプリケーションを、Cloudflareの新たな分身のように感じている。

NEAのマネージングゼネラルパートナーでCloudflareの取締役でもあるScott Sandellも、同じ意見だ。“このDeveloper Fundでデベロッパーは、Cloudflareのネットワーク上で何千ものエンタープライズや何百万ものユーザーにアクセスできるだけでなく、デベロッパーがビジョンを実現できるための資本も提供されるのだ”、と彼は言う。

Cloudflareは2011年にアプリケーションストアを立ち上げ、約30のアプリケーションをサポートしたが、その後、企業の成長戦略の方が忙しくなって、立ち消えになった。Eagerの技術が使える今は、APIを提供する最初の試みよりもずっとデベロッパーフレンドリーだ。プロトタイプもきわめて迅速に作れる、とPrinceは語る。

Cloudflareは2010年9月のTechCrunch Disruptでデビューし、その後1億8000万ドルあまりを調達している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Hackathon NY 2017:CodeCorrectはコード中の一般的な間違いの解決方法を発見してくれる

今日(米国時間5月14日)のTechCrunch Disrupt Hackathonで、あるハッカーが、おそらくその部屋にいたすべての開発者にとって便利なプロジェクトを考え出した。開発者がコードを書いている際に、そのエラーを修正することを助けるCodeCorrectがプレゼンテーションされた。

このプロジェクトの作者は、個人参加のハッカーであるPat Needhamだ。彼は、開発者が出会う一般的なエラーに対する解決法を素早く効率的に見つけるために、StackOverflow APIへのプラグインを行った。フルスタック開発者であるNeedhamは、高校時代からコーディングしているが、まだ学習途上であり、彼自身の問題の1つを解決したいと思っていた。

ハックは、ウェブのコード中にJavaScriptのコード断片を挿入することで、未補足例外(uncaught exception)をローカルなnode.jsウェブサーバーにリルートするというものだ。そこから、挿入されていたコードはStackOverflowのAPIに対して、エラーメッセージを検索し、ユーザの質問に対して最高ランクの付けられたソリューションを返すよう要求する。回答はStackOverflowから抽出され、もし自動的に命令に変換できる場合は元のコードに変更が反映される。

目標は、開発者たち、特にジュニア開発者たちが、コード内のエラーのトラブルシューティングに費やす時間とエネルギーを削減することだ。

「これはシニア開発者なら答を知っているようなエラーに直面した、開発者やジュニア開発者たちが熱望しているものです」とNeedhamはステージの裏で私に語った。「これは、メンターがいない、あるいは最も効果的に検索するための適切な方法を知らない人たちのためのものです」。

しかし実際には、これは全ての開発者たちに役立つ可能性があるだろう。

[ 原文へ ]
(翻訳:Sako)

GoogleがRaspberry Pi用のAIツール/ライブラリの提供を充実、TensorFlowも

pi3_angled_web

Googleは今年、人気の高いマイコンボードRaspberry Piを使っているメイカーたちのプロジェクトをパワーアップするために、開発ツールの充実を進める。それらは、顔認識、情動認識、音声のテキスト変換、自然言語処理、感情分析、予測分析などのソフトウェアツールだ。

今Googleは、Piメイカーへのアンケート調査で、彼らが欲しいと思っているツールを探っている。そのアンケートは、Raspberry Pi FoundationのWebサイトで見られる。

“Googleの関心は、メイカーたちのためのスマートツールを作ることであり、そのためには、みなさんの要望をお聞きする必要がある”、とアンケートは述べている。

アンケートの回答者は、まず関心分野を選ぶ: ホームオートメーション、ドローン、IoT、ロボット、3Dプリント、ウェアラブル、そして機械学習。Googleの対象が相当広いことが、これらからも分かる。

Piの協同ファウンダー、Eben Uptonはこう語る: “大きな機会がありそうなのは、ディープラーニングとAIだ。Googleはこの分野でとても強い、とくにDeepMindを買収してからはね。現実世界のさまざまな仕事をするRaspberry Piを、それらのサービスに結びつけると、もちろんいろんなメリットがあるだろう。ユーザーが何を志向しているのか、アンケート調査の結果を早く見たいね”。

イギリスの非営利団体であるPi Foundationは、この安価なマイコンキットで大成功し、昨年9月には1000万台を突破した。4年半前に最初にリリースしたときには、全部で数千台も売れれば十分、と彼は予測していた。

今ではPiメイカーたちのための開発ツールも豊富にあり、たとえば顔認識のプロジェクトなら、OpenCVのコンピュータービジョンライブラリを使える。

しかしGoogleが提供するのは、いろんなAIツールのセットであり、ユーザーもいろんなタイプのプロジェクトに容易に取り組める。たとえば機械学習のためのオープンソースのライブラリTensorFlowも、元々はGoogleで作られたツールだ。

Googleは前からPiに関心を持ち、2013年には100万ドル相当ぶんのこのマイコンをイギリスの15000名の学童にプレゼントした。多くの若者がプログラミングできるようになることは、Pi Foundationの中核的ミッションであると同時に、Googleにとっても重要なことだからだ。

またGoogleは以前、PiをベーシックなWebサーバーにするためのオープンソースツールを開発した。そしてGoogleのIoTプラットホームAndroid Thingsは、最新最強のPi、Pi 3をサポートしている。

AndroidのPi用公式バージョンはまだないけど、AndroidをPiの上で動かす方法はいろいろある(やや制約はあるが)。Googleが本物の実装に取り組んでいるらしい兆候もある。

それについてUptonはこう言う: “公式のAndroidに関するニュースはないけど、うちの社内のソフトウェアプラットホームとしてはPIXELとRaspbianに前から一貫して力を入れている”。

Googleのスポークスパーソンは、Piの開発ツールについてまだとくに詳しい情報はないけど、“今後とも、さらに多く、オープンソースの機械学習ツールをPiのコミュニティと共有していけることは、すばらしい。今年はもっといろいろあると思うから、ずっと見ていてほしい”、と語った。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

同一のコードベースからiOSアプリとAndroidアプリを並行開発できるUXツールキットFuseが$12Mを調達

fuse_laptop

エンドユーザーにとっては、アプリケーションのユーザー体験(user experience, UX)こそが、まさにそのプロダクトそのものだ。だからデベロッパーは、良質なユーザー体験ツールキットに大きな投資をする。Fuseは、そんなツール集のひとつだ。同社の目的は、複雑なアプリケーションの開発時間を半減すること。今日(米国時間1/24)同社は、NorthzoneAlliance Ventureからの1200万ドルの資金調達を発表し、今後はそのツールキットをもっと広いオーディエンスに周知していこうとしている。

The ability to show the app design on multiple platforms and screen sizes is a boon for developers

複数のプラットホームや画面サイズに対応できるデザイン能力は、デベロッパーにとってありがたい。

同社がとくに力を入れているのは、アプリケーションのユーザー体験のインタフェイスを作るデザイナーと、アプリケーションの中にそういうユーザー体験を実装するデベロッパーとのあいだのコラボレーションを、良くしていくことだ。Fuseの主張では、同社の製品を使えば両者間のシナジー効果が大きいので、ネイティブアプリケーションの制作とその後の進化が迅速かつ容易になる。

Fuseの協同ファウンダーでCEOのAnders Lassenはこう語る: “アプリケーションの市場競争で勝つためには、UXが優れていることがすべてだ。しかし最近ではますます、ユーザー体験の優れたアプリケーションをより短時間で作りたい、という声が大きくなっている。うちのプラットホームに対する初期の反応は、私たちに大いに自信を持たせてくれるものだった。そして、こうやって投資家が注目してくれたことは、なお一層すばらしい”。

Fuseを利用すると、同一のコードベースからiOSアプリとAndroidアプリをリアルタイムで同時に開発できる。つまりこのプラットホームでは、開発中のアプリに対するUIのアップデートや、コンテンツやデータの反映がリアルタイムでできるから、相当早く、アプリのテスト工程へ移行できる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

多様なコンテキスト情報でデバッグを支援するBacktraceが$5Mを調達

Back view of modern programmer sitting and writing code in dark room

CEOで協同ファウンダーのAbel Mathewによると、デバッグ・サービスBacktrace I/Oを立ち上げたのは、協同ファウンダーたちがアドテック企業AppNexusの技術者だったとき実際に直面した問題を解決するためだった。

Mathewによると、Backtraceのねらいは“デバッグという工程を解決すること”。それは、多くの企業が、“古い時代遅れのソリューションのつぎはぎ細工”や手作りのツールで対応している工程だ。

“多くの場合、開発に要する時間の50%以上がデバッグに費やされるのも、そのせいだ”、と彼は語る。“業界全体としては、デバッグのコストはとてつもなく大きい。デベロッパーが正しいソリューションを採用していないときには、そのコストはさらに高騰する”。

同社はこのほどシリーズAで500万ドルの資金を調達し、その調達総額は610万ドルになった。ラウンドをリードしたのはAmplify Partners、これに、Work­-Benchとこれまでの投資家Rally VenturesとTribeca Venture Partnersが参加した。AmplifyのSunil Dhaliwalが、Backtraceの取締役会に加わる。

“技術者が冷戦時代に発明されたデバッグ技術を使ってるかぎりは、ソフトウェアが世界を食べるという事態にはなりえない”、今回の投資のプレスリリースでDhaliwalがそう述べている。“今のソフトウェア開発は、継続的デリバリやWebスケールのデプロイメント、そしてエンタープライズクラスの信頼性が、その特徴と性格を指すキーワードだが、Backtraceはそのような時代にふさわしい必要不可欠なデバッグ能力を自動化することによって、より良いソフトウェアを作る”。

Backtraceには、検索可能なエラー報告、すべてのクラッシュのデータベース、デバッグアシスタント、自動化アラート、などなど独自の機能がある。Backtraceの違いを示す例としてMathewが挙げるのは、アプリケーションがクラッシュすると従来的にはスタックトレースに頼ることが多いが、Backtraceはそれに加えてさまざまなコンテキスト情報(そのときの変数の値など)も提供するから、クラッシュしたときの全体的な状況がよく分かる。“デベロッパーは十分な量のデータを効率的に調べることができる”、と彼は主張する。

顧客には、Mathewが前にいた会社AppNexusのほかに、MediaMath, Circonus, Fastlyなどがいる。彼によるとBacktraceはこれまで、エンタープライズソフトウェアやインターネットのインフラストラクチャなど、要求の厳しいソフトウェアに注力してきた。その多くが、大企業の顧客だ。しかしBacktraceそのものは、どんな規模のソフトウェア開発でも、そしてどんなデベロッパーでも、十分に利用できる、という。

“小さなスタートアップでも、インディーのビデオゲームデベロッパーでも、Backtraceはそのニーズに応えることができる。ソフトウェアがあるところには、必ずエラーとバグがある。Backtraceは規模の大小を問わず、エラーの管理と分析という問題解決のお手伝いをする”、と彼は述べている。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

JIRAに死を

death-to-smoochy

Atlassianのバグトラッカー/機能プランナーJIRAは、今や至るところで使われているし、ぼくも長年、ソフトウェアビジネスの重要な目的に奉仕する製品、と考えていた。重要な目的とは、プロジェクトチームが共通の敵を見つけて共同で立ち向かうことだ。でも、そうではなかった。JIRAの設計は基本的に、良質なソフトウェア開発とは正反対のもので、単純なバグトラッキングぐらいにしか使えない。では、もっと良いやり方とは、なんだろう。

ライターでないときのぼくはソフトウェアエンジニアで、ソフトウェアコンサルタント企業のHappyFunCorpに籍を置いていろんなクライアントの仕事をしている。だからJIRAのいろんな違った使い方を、見る機会がある。一部の企業はそれをBugzilla++として使っているが、それで十分だ。でも最近ますます多いと思われる使い方が、要求の定義だ; プロジェクトを多数のJIRAチケットに分解すれば、それらを使って、評価もコミュニケーションも進捗管理も変更管理も、何でもできる、という考え方だ。

でも、この考え方には深刻な欠点がある。JIRAのチケットは、絶対的で不可避な想定とそれらの結果を表現している。それが記述している機能やビヘイビアは、離散的でない。それは絶対的な二択、すなわち完全か、無か、だ。しかもそれは、個別に評価できる、とされる。つまり個々に、それだけを孤立的に扱える、と想定される。そしてその、他のチケットとの結びつきは、JIRAの子どもっぽい概念、“リンクされた”チケットという言葉で表現される。

これは、ソフトウェアの最良の作り方ではない。ソフトウェアは、反復的(iterative)である。サブシステムAを作る、次にサブシステムBを作る、そしてABをインタフェイスする…という単純な過程ではなく、デベロッパー間には最初にA-AB-Bの全体を見通した情報の流れ〔プログラム中の情報の流れ、フロー〕が共有されていて、それから(あるいはその前に)最初の方のデータでその流れをテストし、その過程を通じて何かを発見し、何かを学ぶ。そして次は、そこで現れた想定外や、システムのどこかにあった地雷原に対策することが多い。ときにはその作業に数週間を費やし、その後本流に戻って、情報の流れを拡大する、…以上の過程を、A、AB、Bの三者が完成するまで反復する。

しかしJIRAでは、進捗はまだ残っているチケットと、クリアしたチケットの数で計られる。そう明示されているわけではないけど、必然的にそうなる。“To Do”(未着手)や“In Progress”(作業中)のチケットが並ぶでっかいカラムは、誰も見たくない。みんな、できるだけ早くそれらをそこから外して“QA”(品質管理中)や“Shelved”(保留中)へ移したい。だからJIRAのチケット方式では、デベロッパーが一度に一つのチケットだけを扱いがちになり、それは多くの場合に非効率であるだけでなく、開発の後段における重大な、その時点ではもはや手遅れの、エラーを招きがちだ。

さらにまずいのは、デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ…それが技術的最適ではない場合でもだ(そういう場合の方がむしろ多い)。もちろん、完全に最初に戻って、プロジェクトのメンタルモデルの全面的な再構築を求めることはできる。だが、そんな重い社会的および資本的負担を、すでに進行中のプロジェクトに関して誰が引き受けるのか? ときには非技術系の管理職が片手間で拙速に作ることもある、暗黙にチケットを前提しているアーキテクチャを、黙って受け入れる方が楽である。

しかし最悪なのは、プロジェクトを複数のチケットに分解するこのやり方では、システム全体を展望する場がどこにもないことだ。最良のソフトウェアは、細部の緻密な実装に集中できると同時に、システム全体の大きな目的や狙いをつねに心にとめているデベロッパーから生まれる。JIRAでは後者が、異様なほど、そして不必要に、困難になる。

ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。

そしてぼくが提案するもっと良い方法は、びっくりするほど単純だ。複雑なシステムを定義/表現できて、そこに曖昧性や不確定性、互いに絡みあった関係性、成功のための反復レベル、そして大きさと細部が不特定に幅広いスペクトル、などなどを記述できる強力なシステムが、すでにある。それは、“散文(prose)”と呼ばれる。

何らかの理由で今日の企業の多くが、明快でシンプルな長い散文(2パラグラフ以上)を書くことを、疫病のように恐れて避ける。でも、上手に書けた8ページのドキュメントなら、複雑なシステムのニュアンスを、互いにリンクし合ったJIRAのチケットの扱いにくい小艦隊よりもずっと見事に、定義できる。

しかも今なら、シンプルなテキストドキュメントを、文や箇条書き、パラグラフ、節、章などに分解して、それらの要素の評価や進捗を記録する自動化システムを、容易に作れる。チケットと違って、各要素の大きさは制限されない。散文をJIRAのチケット集合に自動的に変換することも、必要ならできるだろうが、その場合もプロジェクトを主導する仕様は、単一の、一貫性のある散文ドキュメントだ。

機能のプランニングには、コミュニケーションが必要だ。JIRAは、複雑なシステムの要求をコミュニケーションする方法としては基本的に劣悪である。言葉の並びは、それが良く書けていれば、つねにベターである。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

デザインとプロトタイピングツールのMarvelがシリーズAで400万ポンドを調達

marvel-web

POP買収の熱も冷めやらぬ、デザイン・プロトタイピングプラットフォームのMarvelが、シリーズAの資金調達で400万ポンドを調達したことを明らかにした。ラウンドを主導したのはBGF Venturesで、これに以前からの支援者たちであるIndex Ventures、Connect Ventures、Inreach Ventures、Andy McLoughlin、そしてRichard Fearnが加わった。

Marvelは、ウェブとモバイルアプリのアイデアをプロトタイプ(またはワイヤーフレーミング)するためのシンプルなアプリとしてスタートし、今では誰もがデザインとプロトタイプを行うことが可能になることを目指す、オールインワンデザインプラットフォームへと成長した。組織の中心にデザインを据える企業たちを支援するために、個々のデザイナーやチームによって利用されている。

これを実現するために、Marvelはワイヤーフレームからユーザーテストまで、コラボレーション機能を提供しながら、Webやアプリのデザインワークフロー全体をサポートしている。

同社とその製品が成長した方法も興味深い。それが買収の巧妙な戦略によって少しずつ達成されてきたように見えることだ。ウェブやアプリデザインのエコシステムは、製品ではないにしても、沢山の機能に溢れていて、その多くが大きな企業へと成長することはない。

Marvelはいくつかの機能や製品の買収から始めた — POPの資産を獲得する前には、Plexiというデザインツールを買収した — 市場で先頭を走るために、それらを自社の製品に組み込んだのだ。

今日のシリーズAの目的はMarvelを会社として強化することだ。スタートアップのプラットフォームには現在、100万人以上の登録ユーザが居て、毎月約3万5000人の新規ユーザがサインアップしていると聞いている。最大の市場は米国と英国である。現在はセールスに投資しているが、最近までは現在までは多くを組織と顧客のサポートに向けて投資していた。新たな資本はまた、Marvelの新たな市場への進出や新製品の開発を可能にする。

BGF VenturesのパートナーであるRory Stirlingは、次のように述べている。「私たちはMurat、Brendan、そしてJonathanが、この数年にわたってこの事業を構築するところを見てきました。Marvelの旅に参加することは並ぶことのない誇りです。私たちは、彼らの製品へのこだわりとユーザーに対する親近感が大好きです。技術が創造的なプロセスをシンプルにするために使われるとき、驚くべきことが起こります。Marvelは、個人やチームが世界規模で優れた製品を作り出す方法を変える能力を持っていると信じています。これはまさにBGF Venturesが支援したい野心の一種です。私たちは、すでにチームが掴んでいる印象的で忠実なユーザー基盤を持つビジネスを、拡大する手助けをすることを楽しみにしています」。

[ 原文へ ]
(翻訳:Sako)

テンプレートを廃しブロック方式で自由度を高めた、一般人のためのWebデザインツールTilda

img_9478

メイカーに代表されるような、いろんなプロジェクトに次から次と手を出すタイプの起業家は、Webサイトも次から次とたくさん作らなければならない。そのための便利なツールとして、Bootstrap(これはやめた方がよい)やSquarespace、WordPressのクールなプラグイン、などなどがかねてからある。ここでご紹介するTildaも、そのひとつだ。

Tildaは使いやすくて応答性の良いページビルダーで、ふつうのランディングページだけなら月額15ドルで利用できる。FunkyPunkyというデザインスタジオをやっているロシアのWebデザイナーNikita Obukhovが、自分たちで使うためにTildaを作り、最近それを一般公開した。画像やテキストのレイアウトはドラッグ&ドロップ方式だから、何かを貼り付けるのは数秒で終わる。

その差別化要因のひとつが、Zero Blockと呼ばれる“Webエディター内のWebエディター”的なツールで、文字やフォントの管理(タイポグラフィー)、図形を描く、アニメーションを作る、などの作業ができる。いわばこれは、Tildaの秘密兵器だ。

Obukhovはこう説明する: “ユーザーは、予(あらかじ)めデザインされているブロックを組み合わせてWebサイトを作る。テンプレートはない。その方が柔軟性があり、ユーザーの自由度も大きい。ブロックは、わが社のプロたちの作品だから、ルックスがよろしい”。

試してみたら、こんなプロジェクトを15分で作れた。既存の写真とテキストを、ちょっと使っただけだ。終わったらすぐにそれをアップできるし、公開できる。ドメインを割り当てるのも簡単だ。とにかく、使用体験はとても快適だ。

Tildaはまだ自己資本のみで、今リピーターの顧客が約4000名いる。

あなたはまだ、Bootstrapから完全に抜け出せないかもしれないし、Tildaの月額15ドルは高いと感じるかもしれない。でも、ぼく自身の証言としては、とても使いやすいから捨てられないツールだね。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Kinetiseは素人開発者による企業内モバイルアプリ開発を加速する

kinetise_screenshot01

アプリ構築プラットフォームであり、Disruptハッカソンのお気に入りツールであるKinetise は、企業におけるiOSとAndroid向けネイティブモバイルアプリケーションアプリ作成プロセスを一般に開放することを目指している。ドラッグアンドドロップインターフェースを使用して、このシステムは、基本的にビジュアルに、ネイティブアプリケーションを構築し配備することができる。こうすれば、非開発者がモバイルアプリケーションを作成および配備することができるのだ。

同社は当初、スタートアップのアプリ開発のための販売に焦点を当てていたが、すぐに大きな企業組織の内部で、データ収集のためのちょっとしたアプリを作るために同社のプラットフォームを使用している「シチズンデベロッパー(素人開発者)たち」がいることを発見した。その結果同社は最近、暗号化接続、強力なデータベースツール、および改善されたGPS位置管理などのエンタープライズ向け機能を多数追加した。これが意味することは、会社の中の素人ユーザーがプラットフォームを使って、配送の追跡や、現場での保険金請求の受付や、単純に時間追跡アプリを作ることができるということだ。

これまでの経験から、私はこうしたアプローチのプラットフォームには懐疑的だった。数年前私がこうした種類のツールに出会った時には、その主な利用法は開発者が1つの論理的ビジネスルールからモバイルアプリを複数のOS(iOS、Android、Blackberryなど)に対して生成し、複数のアプリケーションを同時に公開するといったものだった。

筋金入りの開発者自身ではない私は、その時点でさまざまな開発者からのさまざまな意見を聞いてみた。私が話した、より伝統的な開発者の多くは、そのアイデアを気に入って、相当な時間の節約が可能であることを期待した。対して私が話したモバイル開発者たちは悲観的で、そうしたツールはネイティブ言語による真のモバイルソリューションに比べて、脆く不自由なものだと考えていた。

しかしKinetiseのシステムは、私がこれまでに見たものよりも頑丈であり、正直に言えば私の興味を最も惹きつけたのは、チームが発見したいくつかの成果だった。

KinetizeのCEOであるPiotr Pawlakとの簡単なSkype通話の中で、彼は彼とそのチームが1回の配備を行う前に気付いた、キーとなる洞察について、説明をしてくれた。
「私たちは、ネイティブアプリを作るための簡単な方法として、私たちのプロダクトを開始しました。私たちは、スタートアップや実験者たちには、かなり人気があったのですが、私たちは本当に面白いことを発見したのです:企業が1回限りのアプリを作るために私たちのプロダクトを使用していたことです」と彼は言った。「私たちが少し調査してみたところ、企業はガートナーが呼ぶところの「シチズンデベロッパー」モデルに従っているように思われました:彼らはウェブページを作る代わりに内部アプリを作っているのです」。

そこにKinetiseの強みの1つがある。それは企業内アプリむけの高速開発プログラムである。確かに、プラットフォームはまだアプリストアでの一般公開用のアプリを構築するための方法も提供しているが、企業向けも主要なターゲットであり強みである。

 私はこの利点がよくわかる。なぜなら、ネットワーク接続性がないときにでも「オフライン」で機能することができるモバイルツールを必要とする、リモートでモバイルな企業ユーザーたちが確かに多数存在しているからだ。これらのシナリオでは、ネイティブモバイルアプリは優れたソリューションであり、モバイルサイトを上回る利点を持っている。

「Kinetiseはテンプレートベースのアプリクリエイターの1つではありません」とPawlakは言う。「私たちは、レストランや美容パーラー向けなどのアプリを構築しているわけではありませんが、私たちは真のカスタムアプリをコーディングレスで提供します。私たちの顧客は子供たちがレゴブロックを組み立てるように、アプリを組み立てます。そして組み立て終わったものはAndroidとiOSで動作するアプリになるのです。他にこのようなものはありません」。

顧客からの反応は、彼らのアプローチが正当な開発ツールとして十分に頑丈であるとの自信を深めることに役立ち、モバイルアプリの開発の現状を変革することへ向かわせる。

kinetise_screenshot02

現在、ワルシャワを拠点にするこのスタートアップは、30000人の登録ユーザーと3つの企業顧客を持ち、アプリストアには100以上のアプリを、MVP(Minimum Viable Product)/プロトタイプ/内部アプリを700以上持っている。

[ 原文へ ]
(翻訳:Sako)

バックエンドとフロントエンドとが仲良くなって十分納期に間に合うためのツールBrightWork、立ち上げ前から300名が待ち行列

img_9388

フロントエンドの連中とバックエンドの連中は、意思疎通ができない。バックエンドの連中が“Node.js”と言うと、フロントエンドの連中は“ノード何?”と聞き返し、やがて喧嘩になり、水かけ論になり、最後は大混乱になる。シカゴ生まれでTechStarsで育ったBrightWorkに、そんなときのためのソリューションがある。

TwilioのエンジニアだったJosh Carterと、NikeのデベロッパーだったPhil Taylorが創った同社は、これまで20万ドルを調達して、バックエンドのデプロイを単純化しようとしている。

Carterは説明する: “Philもぼくも、同じ問題で悪戦苦闘していた。DisneyやTaco BellやPabst Blue Ribbonなんかのアプリケーションを作っていたんだけど、どんな場合でも、バックエンドとマイクロサービスの構築で納期の大半を食ってしまうんだ。Phisも同じ問題を抱えていて、彼はクライアントのためのソリューションやインフラストラクチャをもっとアジャイルに作れるための、ベストの方法を探していた。二人で共感を共有できたから、Brightworkのようなものを創ろう、ということになった。”

Brightworkはいわば、昔のCpanelのような、一連のスクリプトの集まりだ。ここにはこんなAPIやサービスがほしい、と思ったら、ボタンを押すだけでコードが完成する。そしてそのコード片の回りに、それを管理するためのインタフェイスをくっつければ、フロントエンドが完成する。なんとなく、気の抜けたビールのようなやり方だが、でも、使える。

同社の立ち上げ前から300名のユーザーが立ち上げを待っていた。

“しかし最初は一部の人たちにだけ使ってもらって、彼らから重要なフィードバックをもらった。でももちろん、成長するためにはオーディエンスを広げなければいけないことも、わかっていた”、とCarterは語る。

バックエンドはフロントエンドほどセクシーではないが、中身のクリームと外側のチョコレーtの両方が揃わないと、おいしいケーキはできない。両者の合体を支援するBrightworkは、だからすばらしいだろう。もう、お互いに喧嘩する必要はないね。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))