カテゴリー: テクノロジー

Webスクレイピングをはじめてみました(1)

 

こんにちは、長年Webデザインに携わってきましたがプログラミングがなかなか覚えられないLQヒロシです。

今回は一念発起して、流行りのPythonWebスクレイピングをしながらプログラミングを勉強していこうという試みです。

なぜWebスクレイピングなのか?

 

PHPのちょっとした修正や、jQueryを使ったクリックやリサイズの簡単なイベントぐらいはできるけど、そこから先になかなか進めない・・。デザイナーなんだしJavaScriptUI周りのエフェクトとかを実装できるようになりたいと思ってはいるのですが、UI周りってイベント同士が絡んだりすると途端に難しくなってなかなか続かないのが目下の課題だったりします。

簡単なアウトプットを段階的にこなしていって、ファンクションのまとめ方だったり、データのやり取りなどプログラミングの勘所を掴んでいけるのが理想的ですよね。

Webスクレイピングであれば、WebサービスのAPI活用・クローリングでのデータの収集、データベースへの保存や取り出し、データの加工の作成という一連の流れが小規模なカタチで勉強できるので、体系的にポイントを抑えた勉強ができそうです。データを加工するのに正規表現も使うことになりそうだし。

 

プログラミング言語はpythonを使用し、ツイッターと連携して画像を収集しギャラリーサイト作成を最終的な目標としたいと思います。

 

第一回目は、スクレイピングとPythonについてご紹介できればと思います。

そもそもWebスクレイピングとは?

 

厳密にはクローリングとスクレイピングに分けることができます。

・クローリング
WebサイトのハイパーリンクをたどってWebページを探す作業

・スクレイピング
Webページから必要な情報を抜き出し、整形し直す作業

例えば、電子書籍の販売サイトから書籍情報を抜き出して価格を比較、最安値の情報のみをまとめるなど、要するに複数のWebサイトから任意の情報だけを抜き出し、雑多なデータを整理して有益な情報にすることでしょうか。

Pythonって何?おいしいの?

 

GoogleFacebookで採用されていて、機械学習やIoTの事例も多い現在最も旬な言語とも言われていますので、おいしいです。他のプログラミング言語同様、WindowsMacOSLinuxなどのプラットフォームで動作でき、環境構築・Webシステムの開発~データ解析までひとつの言語で実現できることから世界中で広く使われています。

Pythonの特徴

 

文法が読みやすい

 

プログラムは一度書かれた後も他の人に読まれるもの。pythonでは「シンプルで読みやすいコードが書けること」という設計思想があり、コード上の装飾が極力少なくなるような記述方法になっています。少し文例を見てみましょう

実行結果:hogeです

 

このように文の終わりに閉じタグが必要なく、制御構文では影響する範囲を括弧で囲む代わりにインデントで定義。変数は代入するだけで宣言されたことになるのでとてもすっきりとして読みやすいコードになります。

Pythonってなんだか難しそうなイメージがありましたが、PHPなどと比べても別段特殊な書き方をしているわけでもなく、文法が見やすいので非常に馴染みやすく感じました。教育の現場でも採用されていたりするそうで、プログラミング初心者にも学びやすい言語だと思います。

 

・導入が簡単!

 

MacならHomebrewでインストールするだけですぐに使えました。コンパイルする必要もないので、ぶっちゃけ笑ってしまうぐらい早いですwww

(以前PHPを導入した際は、php.iniファイルの設定を調整したり、事前にDBを用意したりと面倒だった思い出があります。)

 

・豊富なライブラリ

 

Pythonには正規表現、数学関数、通信プロコトルなどの標準ライブラリが非常に豊富でインストールするだけで利用が可能です。さらにサードパーティ製のライブラリも豊富に提供されています。最近ではディープラーニング用のTensorFlowなどが有名ですね。データ解析のライブラリも強力で、スクレイピングしたデータをインフォグラフィックとして表現できたりもします。

 

それではPythonの導入方法を見てみましょう

 

Pythonは2系と3系があり、現在は3系が主流になりつつあります。2系と3系の間には互換性がありません。Macではデフォルトでインストールされていますが2系だったりするので、Homebrewで3系をインストールします。

 

 

バージョンを確認してみましょう

 

Homebrewでインストールしたものが参照されているか確認します。

と表示されれば準備は完了です。

 

では、対話方式でプログラム実行できる「インタラクティブシェル」でPythonを動かしてみます。やり方はターミナル上で「python3」と入力するだけですw

立ち上がったら上記のようなメッセージが表示され、コマンド受付状態になります。では、構文を入力してみましょう。

はい、これだけですw簡単ですw

 

終了する時は

または

これでbashに戻ることができます。

 

第一回目は以上になります。説明や導入を中心に駆け足でご紹介してきました。
まだまだ勉強中の身のため、上手く伝えられず分かりにくい部分が多々あると思いますが、次回からは実際にPythonを利用して少しでも魅力をお伝えできればと思います!


NginxをHTTP/2対応する際のポイント

NginxをHTTP/2に対応するにはALPNに対応する必要があり、下記ソフトウェアバージョンの条件を満たす必要があります。

  • Nginx 1.9.5以上であること
    ※但し、その後のバージョンでHTTP/2に関する不具合の修正がある為、ご注意ください。
  • OpenSSL 1.0.2以上であること

導入されているソフトウェアバージョンについては、下記コマンドにて確認可能です。

$ nginx -V

下記のようにバージョン条件が満たされた出力がされていれば問題ありません。

nginx version: nginx/1.10.3 (Ubuntu)
built with OpenSSL 1.0.2g 1 Mar 2016
TLS SNI support enabled

過去にHTTP/2対応したと思っていてもOpenSSLのバージョンが低く、正しくHTTP/2に対応できていないということがあるのでご注意ください。

正しく対応できているかの確認はchromeのDeveloper toolにてProtocol列を表示し、確認してください。

問題がない場合には[h2]と出力されています。

 


パスワードを使わなくてもWeb認証できる?「WebAuthn」

WebAuthnが、Web認証の新たなスタンダードになるかもしれません。

FIDO Alliance and W3C Achieve Major Standards Milestone in Global Effort Towards Simpler, Stronger Authentication on the Web
https://www.w3.org/2018/04/pressrelease-webauthn-fido2.html.ja

本日発表された新しいFIDO2仕様と、それをサポートする主要ブラウザの取り組みは、全てのプラットフォームやデバイス間でFIDO認証が不偏のものとして存在する第一歩を踏み出したことを示しています。データの侵害とパスワードなどの資格情報の盗難は増加し続けていましたが、これからサービスプロバイダは、脆弱なパスワードやワンタイムパスコードに頼ることなく、全てのウェブサイトやアプリケーションで フィッシング耐性を持つFIDO認証を実装する時が来たのです。

 
発表によると、生体認証(指紋や顔、虹彩等)や、USB、BluetoothまたはNFCを介した外部認証ツールを利用し、パスワードやワンタイムパスコードを使用せずにWeb認証が可能となるそうです。
現在、W3Cにおける「勧告候補」となり、すでに主要ブラウザであるChromeやFirefox、Microsoft Edgeがサポートを発表しています。
 
生体認証と聞いてスマートフォンのロック解除を思い浮かべる方が多いのではないでしょうか。
寝起き顔で認証されずに悲しみにくれた経験をした方もいるかもしれません。
Webアプリケーションもそれらと同じように手軽にログインできるようになれば、パスワードそのものの管理の不便さ、煩わしさを嘆く必要はなくなります。
 
W3Cでは実装サンプルが公開されています。
https://www.w3.org/TR/webauthn/#sample-registration
 
Firefox Nightlyにおいては、about:configにsecurity.webauth.webauthnという項目がすでに存在していることが分かります。

firefox nightliyのabout:config

もうほぼ実現するとみていい状況だと思われます。

検索してみるとDemoサイトも出てくるのですが、試してみるとデバイスの接続を求められるアラートが表示されるところから進めませんでした。
FIDO・CTAPに対応した認証用アプリや機器が必要なのだと思われます。
また機会をみて試してみたいと思います。
 
ところで、Appleは4月現在のところだんまりです。
珍しいことでもないので近いうちに何らかの発表があるかもしれません。


抽選プログラムを開発しました

こんにちは。開発担当のマットです。
 
Sploutでは、ライトニングトーク大会を定期的にやっております。
メンバー全員が順番に5分間のトークをして、とても楽しい時間です。
 
ライトニングトーク大会をするには、発表順を決める必要があります。
今までは順番を決めるのにあみだくじを使ったりしていましたが、折角システム開発会社なので、順番を決めてくれる抽選プログラムを作ってみようと思いました。
 
一番簡単な方法はブラウザでJavaScriptを実行させるだけです。
Google Chromeを開き、右クリックして、「検証」>「コンソール」を押して、以下のスクリプトを貼り付けてEnterキーを押すと一瞬で順番を決めることができます。

超簡単ですが、面白くはないです。

Unityで面白いものを作ろう!

最近、Unityを学習しています。Unityは3Dゲームエンジンです(wikipedia) 。
これを使えば、何か面白い抽選プログラムを作れるではないかと!
 
考えついたのは「競馬」。

まずはプロジェクト開始。

とりあえず「Kuji」と名付けました。

プロジェクトに地面(Terrain)を入れる。

新規なUnityプロジェクトだと、カメラと照明しかないので、馬が走る地面をシーンの中に挿入する必要があります。
挿入して草のテキスチャーで塗りました。

次は馬の作成。

形を作る前に馬を象徴するゲームオブジェクトを作成します。

次はそのゲームオブジェクトの中に、複数のキューブで馬の形をなんとなく作り上げます。

色付けしましょう!

Unityでオブジェクトを色塗るには、Materialを作成すべきです。
Materialは「素材」という意味で、「色」だけではなく、「光沢」に関する色々な設定ができます。
とりあえず、2つのMaterialを作成し、馬の該当箇所に設定をしました。
片方はツヤ無しの馬毛。
他方はちょっとツヤ有りの鞍。

馬を走らせましょう!

Unityのアニメーション・システムで馬を走らせる動きを作るのは簡単です。

競馬場がないと・・・

簡単に壁と決勝線を地面の上に作りました。
馬もコピペして、サイズを調整。

馬にラベルを付ける。

誰がどの馬かわかりませんので、馬の上に名前ラベルを追加しました。

馬に個性を付ける。

次はスクリプトを作成して、馬のゲームオブジェクトに付属させました。
このスクリプトで、馬に付属しているMaterialの色やラベルの表記を設定できます。
これによって、馬をカスタマイズできるようになりました。

馬を並べましょう!

上記と同様に、馬のコピペだけでできました。
それぞれの馬の名前と色を設定します。
*この画像は数字を使っていますが、実際の抽選の時は参加するメンバーの名前を入れました。

最後の最後に「レース」のスクリプトを作成!

最後にとても簡単なレースのスクリプトを作成しました。
「Spaceキー」を押すと馬達が走り出します。
UnityのUpdateファンクションで、毎フレーム、それぞれの馬をちょっとずつ前に進める。しかし、毎フレーム進める距離はある範囲以内のランダム値です。それで、それぞれの馬の進み具合に差が発生します。

なお、決勝線にたどり着くと、走り止んで、その馬のラベルに書いてある名前が一覧に表示される。これで発表順を決めることができます!

まとめ

まだ学習中ですが、Unityで簡単にできることに驚きました。
上記の抽選プログラムの総合開発時間は2時間だけでしたのに、アニメーションを対応した3Dプログラムを一から作ることができました。
とても、有力なツールです!

これからも、色々面白いプログラムを開発してみたいと思います!


Flutterが銀の弾丸だったらいいな

 

最近弊社では、 #HASH というWebサービスが、ローンチされたのかされてないのか微妙な状態でなし崩し的にベータ版みたいな感じで公開されております。

 

「ハッシュタグでのゆるいつながり」をテーマにしたサービスで、ハッシュタグの作成や管理も簡単にできるようになっていますのでよろしければ使ってみて下さい。

 

で、まだベータ版みたいな状態ではあるんですがやっぱりこういうのはアプリも欲しいよね!ということでアプリ化の検討を始めました。そして検討する中でiOSとAndroid両方で動かすことが出来るいわゆるクロスプラットフォームな開発ツールの導入を検討してはどうか、という話になり、最近活発に開発が進んでいて(一部で)話題になっているFlutterというSDKを検討してみることになりました。

Flutterとは

 

Flutterは上述のとおり、iOSとAndroid両方で動作するアプリを開発することが出来るクロスプラットフォーム開発用のSDKです。Googleがオープンソースで開発していて非常に活発に開発が行われています。

 

 

こういうクロスプラットフォーム開発SDKにはいくつかのパターンがあるのですが、Flutterは

  • 独自のUIコンポーネントを使って描画を行い
  • 独自のAPIセットが提供されているためプラットフォーム間でコードが共有出来る

というものです。

 

ちなみに有名どころのクロスプラットフォームSDKであるXamarinは、

  • ネイティブのUIコンポーネントを利用してUIを構築し
  • 各プラットフォームAPIに対応する薄いラッパーAPI、もしくは独自のAPIセットが提供、のどちらかを選択できる

といった感じになっています。

 

検証したこと

 

今回はあくまで業務で使えるのか、そしてネイティブ実装で作るより明確なメリットがあるのか、ということが検証の主眼ですので、あまり技術的なことを細かくは書きません。(もちろんすべて実際にコードを書いて検証は行っています)

結局知りたいことって、

  • どこまでコード・UI設計が共通化出来るのか
  • 各プラットフォーム固有の機能がどこまでサポートされているのか
  • 各プラットフォームネイティブの環境でそれぞれのアプリを作ったときと比較してどの程度工期が短縮されるのか

っていうことなんですよね。

 

ではまず、

<どこまでUI設計が共通化出来るのか>

ということですが、UIについてはほぼ共通化が可能です。ただし今のところビジュアル設計ツールはなくコードでUIを記述していく形になります。
ただ、一度ビルドしてテスト端末などでデバッグ実行している状態でコードを変更すると、再ビルドすることなく実行した状態のままコードが反映されるというHot Reloadという機能があるため、意外と面倒には感じないのではないかと思います。

ただし、例えば広告を掲載したい、とかいうことになると現状admobしか対応していない、とか、アニメGIFなどネイティブ実装ではオープンソースのライブラリを使って簡単に表示できたりするのですが、そういったライブラリがまだあまり種類がなく、自力での開発が必要となる場面が多くなるような気がします。

 

<どこまでコードが共通化出来るのか>

コードについては、Flutterの標準ライブラリが対応している範囲であれば同一コードで記述できますが、対応していないものについてはChannelという仕組みを使って、ネイティブコードを呼び出す形で実装することになり、この場合swiftやkotlinなどでネイティブ実装する必要が出てきます。

 

ここは結構キモだと個人的に思うところですので、前提知識なくコードを見てもよくわからないかもしれませんが、ここだけは実装コードサンプルを載せてみます。

下記でやっていることは「ネイティブ実装を呼び出して文字列を取得する」という単純なもので、雰囲気だけ伝われば幸いです。

 

 

まずDart側でこのようなメソッドを準備します。ネイティブ側実装を呼び出す際にawaitでブロッキングしますのでこういうメソッド(非同期呼び出し)が必要になります。

Future<Null> _getCallbackDataString() async {
  String dataString;
  try {
    dataString = await platform.invokeMethod('iDataIO_getCallbackData');
  } on PlatformException catch (e) {
    dataString = e.message;
  }

  setState(() {
    _callbackDataString = dataString;
  });
}

この中の

platform.invokeMethod(‘iDataIO_getCallbackData’);

これがmethod channel というネイティブ側実装を呼び出すコードです。

 

 

そしてiOSの場合は、Flutterの動作ベースとなるAppDelegateのapplicationメソッド内に下記のようなコードを記述します。

let dataIOChannel = FlutterMethodChannel.init(name: "net.bugfix.io/dataio",
                                               binaryMessenger: controller)

dataIOChannel.setMethodCallHandler({
    (call: FlutterMethodCall, result: @escaping FlutterResult) -> Void in
    switch (call.method) {
      case "iDataIO_getCallbackData":
        result(dataString)
      default:
        result(FlutterMethodNotImplemented);
    }
});

この中の dataIOChannel が上記Dart側のplatform.invokeMethodで呼ばれるオブジェクトとなります。

そして渡されてきたメソッド名によってコードが実行され、resultで実行結果が返却されます。

 

Androidのコードは省略しますが、MainActivityの初期化コードの何処かに同じようなコードを記述することになります。

 

 

確かに工夫すれば結構なんでもやれちゃいそうではあるんですが、今回はここが一番のネックと感じました。
だってこれは完全にネイティブ実装、これなら全部ネイティブで書いたほうがストレスないと思うんですよね(個人的な見解)。。。

 

<プラットフォーム固有の機能がどこまでサポートされるか>

これも基本的にはコード共有と同じなんですが、例えばiOSの共有メニューに自分のアプリを選択肢として表示させてアクション出来るようにしたい、などについてはその部分はまるっとxCode使ってswiftで記述・plistを編集する必要があります。これも完全にネイティブ実装です。

 

<工期について>

これはもうネイティブ実装がどの程度必要になってくるか次第ですが、もしネイティブ実装の必要がほぼない、ということであれば、iOS、Androidそれぞれネイティブ実装したときが2だとすると、1.6程度かなといったところです。(がっつり作ったわけではありませんのであくまで私の感覚的なものです)

 

ただちょっと触ってみた感覚では、結局かなりネイティブコードを書くことになってしまうのではないか、という印象を持ちましたので、きちんとしたものを作ろうと思うほどにネイティブ実装より時間がかかってしまうように感じました。

 

例えば、オリジナルのソフトウェアキーボードを実装する、とか、上述した他のアプリとデータ共有する(iOSだと共有メニュー, AndroidだとIntent共有)など。
また、プッシュ通知自体はサーバサイドにFirebaseを利用すれば割合簡単に実装可能ですが、これも例えばiOSのプッシュ通知の際の細かな挙動をネイティブと同じように実装するのは、ネイティブ実装呼び出しを利用してもなかなか難しい感じです。

 

結論

 

今回、Flutterで実装することは見送る方向で検討しています。
やはりネイティブ実装が必要となる可能性が高く、それなら最初からネイティブ実装したほうが効率が良いのではないか、ネイティブ実装なら簡単に出来ることが予想外に時間がかかってしまう、という可能性がありそうだな、と感じたことです。

 

あと弊社、一応iOSもAndroidも両方対応可能なエンジニアが私含めていますので生産性という点でもデメリットを上回るメリットがないように感じました。

 

ただFlutterはまだベータ版で活発に開発が行われているようですので、今回私がネガティブに感じた部分がどんどん改善されていく可能性があります。

 

Flutterにかぎらずこういうものは時折チェックして乗り遅れないようにしていきたいですね。

 

開発現場からは以上となります。