モバイルアイランドとは何ですか

みなさんこんにちは。 私の名前はMax Degterevです（ここにはアカウントがありませんので、私のtwitterは@suprMaxとサイトmaxdegterev.nameです ）。 私たちは最近、モバイルサイトの新しいクールなバージョンを立ち上げました。 今から彼についてお話します。

主な根拠

新しいモバイルサイトで作業している間、古いサイトの開発経験がありました。 これらの手紙を書いている時点では、まだhttp://ostrovok.ru/mで入手できるはずですが 、どのくらいの期間機能するかはわかりません。 古いサイトは非常に簡単に機能しました。 彼は一般的なOTAプロジェクトに住んでおり、それに応じて、同じバックエンド（Django）、標準メディアジェネレーター、シンプルなHTMLテンプレート（サーバー側）、アンダースコアのいくつかのJavaSciptテンプレート、SCSS、および通常のJavaSciptを使用します。 私たちは皆これを100回経験しました、それはすべて非常に退屈です。



新しいサイトを開発する前に、次のタスクを行いました。

• サイトを新しいデザインにし、同時にこの新しいデザインがどのように機能するか、そして今後モバイルアプリケーションに使用する価値があるかどうかを確認します。
• このサイトは、iPhoneおよびAndroid 2.x、4.x、デフォルトのブラウザーで正常に機能するはずです。
• 古い機能にはない新しい機能をいくつか追加します。 たとえば、ホテル名でフィルタリングし、ホテルをお気に入りに追加します。 もちろん、大規模なサイトを完全にコピーするべきではありません。
• 楽しく面白くしてください。

歴史的に、サイトは常にモバイルアプリケーションの設計で開発されており、この設計はその上に展開されています。 そのような実験のようです。 そして、ここでのデザインはまったく新しいフラットでした（iOS 7スタイル、ファッショナブル！）。 したがって、色、そして実際に外観が島の他の部分とわずかに異なることに驚かないでください。



前回のように、OTAに依存したくありませんでした。 さらに、私はこのサイトで一人で作業しましたが、Djangoを教えることはまったく面白くありませんが、OTA開発者の1人を常に気を散らすことは決して面白くありません。 だから私は海賊のように考えることにしました。 Ostrovokには、モバイルサイトに必要なほとんどの機能をカバーするモバイルAPIが既にあります。 デスクトップサイトからAPIのこの部分を追加すると、かなり良い解決策が得られます。 これが私が選んだアプローチです。



私はNodeJSを基礎として取りました。 私はいつもやってみたかった。 フレームワークはExpressJSで、Sinatraに非常によく似ています（こんにちはRuby！）。 ユーザーセッションを実施する必要があるため、Redisは不可欠です。 通常よりも少ないJavaScriptを印刷するにはCoffeeScriptを使用しました。 テンプレートの場合はJadeを、CSSの場合はStylusを使用しました。 ファッションサイトが必要で、携帯電話では速度を大幅に向上させることができるため、singlepageはすべてを行うことにしました。 最初はSpineJSを使用することを考えましたが、彼のコミュニティはそれほど大きくないので、Backbone、Lo-Dash、Zeptoなどの古典的な束です。









アセットのアセンブリを少し工夫する必要がありました。 レールのように、すべてを自動的にクールにしたい。 アセットラックは非常に優れたソリューションであることが判明し、JS、CSS、さらにはJadeテンプレートを組み立てる作業を完全に引き受けました。 もちろん、彼はテンプレートをプリコンパイルする方法を知っており、指定された名前空間に入れます（app.templatesを選択しました）。 彼はまた、CoffeeScriptと要件システムをプリコンパイルするという頭痛の種を取り、2つのオプションを提供します。Snockets（Sprockets）と、RequireJSを使用した従来のNodeJSバージョン（Browserify）です。 ただし、NodeJSは新しいものなので、問題がありました。

• サーバーの起動時に統計がコンパイルされます。 ファイル内の何かが変更されました-サーバーを再起動してください。 生産上問題はありませんが、開発中は特に便利ではありません。 nodemonをインストールすることで解決しました。 さらに、Cakefileで簡単な命令を記述し、サーバーを起動するだけで十分です（例： `cake dev`）。 そして問題ありません。
  
  
• Staticsはコンパイルされますが、ディスクに収まりません。 Asset-Rackはホスティング（Amazon S3など）にファイルをアップロードできますが、たとえばnginxを介して自分でファイルを提供したい場合は、創造的でなければなりません。
  
  

  compressAsset = (filename, contents)-> console.log("[#{(new Date()).toUTCString()}] #{logPrefix} Compressing asset #{filename}.gz") zlib.gzip(contents, (e, buffer) -> fs.writeFile(filename + '.gz', buffer)) generateAssets = -> for asset in assets.assets filename = __dirname + '/public' + asset.url.replace('.', "-#{asset.md5}.") if not fs.existsSync(filename) console.log("[#{(new Date()).toUTCString()}] #{logPrefix} Saving asset #{filename}") fs.writeFileSync(filename, asset.contents, encoding: 'utf-8') compressAsset(filename, asset.contents) assets.on('complete', -> generateAssets() unless config.is_dev
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

小計：

• バックエンドとフロントエンドは1つの言語で書かれています。 1つのコードスタイルで、同じファイルを接続することもできます。 たとえば、データ検証およびヘルパーテンプレート。 さて、追加のボーナスとして-フロントエンドベンダーはバックエンドコードを読んで、何が起こっているかを理解できます。
• テンプレートといえば。 Jadeは、クライアントとサーバーの両方で使用できます。 私の場合、1つのlayout.jadeをすべてのページに接続します。 ただし、必要に応じて、バックエンドでページを生成することにより、絶対に任意のページを提供できます。 もちろん正しいデータ構造をスキップしましたが、利便性は明らかです。
• スタイラスは単に神です。 Jadeテンプレートをスタイラスファイルに完全にコピーし、そこから不要なものをすべて削除して、スタイルを記述できます。 これがWebの設計方法です。
• バックエンド、フロントエンド、どこでも簡単でわかりやすいJSON構成。

ファッショナブルで若々しく、楽しくなるようにタスクを決めました。

仕組み

プロジェクト自体の編成方法について少し説明します。 写真は千の言葉に値する：





BackboneとCoffeeScriptの開発の詳細には触れません。 これについて何千もの記事が書かれています。 モジュールの構造について簡単に説明します。一般的には、私がやったように、夢中にならないようにします。



明らかに、Backboneにはコレクション、モデル、ビューがあります。 別のフォルダに入れます。 モジュールも必要でした。 これらは、私がどのページにいても、常に必要なものです。 これらはアプリケーションの開始時にロードされ、たとえば、ビューが別のページに移動したときにすぐに破棄されたときにアンロードされなくなります。 一部のモデル/コレクション（たとえば、[終了]ボタンをクリックしたときの予約のリスト）と同様。 私のモジュールは、モーダルウィンドウ、サイドバー、電話の物理的な位置に関する情報などです。



最終的に、これは私のメインapp.coffeeファイルの外観です：

  #= require ../../data/app.config.js #= require ../helpers.js #= require app.utils.js #= require_tree modules #= require router.coffee #= require_tree models #= require_tree collections #= require_tree views app = _.extend(@app, Backbone.Events) # ... # Layout modules app.size = new app.modules.Size() # Data modules app.geo = new app.modules.Geo() app.user = new app.modules.User() app.analytics = new app.modules.Analytics() # Modals and extra views app.overlay = new app.modules.Overlay() app.modal = new app.modules.Modal() # Router relies heavily on stuff above app.router = new app.Router() # ... Backbone.history.start(pushState: true, hashChange: false)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、バックエンドでも使用されるhelpers.jsです。 require_treeを介してフォルダーを接続すると、個々のファイルの接続について考えることはできませんが、読み込み順序はそれを保証しないため、他のクラス（たとえば、view）から継承する必要がある場合は追加のrequireを行う必要があります。 そのようなタスクはありませんでしたが、Backbone.history.startを呼び出すまでに、システムのすべてのモジュールとコンポーネントは既にメモリにあったため、ルーターはその仕事、コールビューなどを実行できました。



スタイラスについて少し説明します。 SASSに非常に似ていますが、多くの追加機能があります。 明らかに、識別ベースです。 これにより、クラス名の共通部分に煩わされることがなくなります。 しかし、私たちは皆長い間これを見てきました、それは退屈です。 CSSルールの値を変数として使用できるのはどうですか？

  .my-awesome-block width: 100px height: 100px margin: (@width / 2) auto line-height: @height
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

悪くない。 ベンダープレフィックスのサポートはどうですか？ 私たちはひどい競争の世界に住んでいます。 幸い、次のようになります。

  .my-awesome-block box-sizing: border-box transition: all .2s ease
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スタイラス自体は、自分が持っているミックスインを調べ、同じ名前のプロパティを見つけると、置換を実行します。 したがって、境界線の半径（ちなみにtrue）のように、ベンダープレフィックスを入力する必要がなくなった場合、1つのミックスインを削除するだけで、残りのファイルを開くことさえできません。 よくわかりませんが、これで将来約100倍の節約ができるように思えます。 さて、私のapp.stylがどのように見えるかの小さな例：

  @import 'config' @import 'includes/reset.css' @import 'includes/fonts.css' @import 'includes/mixins' @import 'plugins/iswipe' @import 'plugins/zepto.sidebarify' @import 'plugins/zepto.calendar.css' @import 'plugins/zepto.input.numselect.css' @import 'plugins/zepto.listselect.css' @import 'plugins/zepto.textarea_autogrow' @import 'partials/partial_date' @import 'partials/partial_spinner' // ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

混合インポートも問題ではないことがわかりました。 現時点での唯一の欠点は、mixinを呼び出すために引数が必要なことです。 これがなければ、この呼び出しは機能しませんでしたが、既に修正されていました。 私はこのように書いています：

  html, body // lol! noselect plz body, select, input, button, textarea color: #4b5c66 font: normal 14px Helvetica, Arial, sans-serif line-height: 1.4em //...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スタイリングでは、常にクラスのみを使用してシスの邪悪な特異性を打ち負かし、クラスが交差しないことを146％保証するために、SMACSSアプローチを使用しました。 まあ、またはそうではないが、非常に似ています。 ページの構造に関連し、トランジション中に変更されないものはすべて、接頭辞l（レイアウト）で行いました。 また、p（ページ）、b（ブロック）ページ内のブロックなどもあります。 要素が要素にネストされている場合、そのクラスは親の名前の一部を継承します。 継承されない場合がありますが、ルートクラスは常に継承されます。 スタイルの例を次に示します。

  .p-awesomepage .pa-header // styles .pah-soopermenulink color: hotpink .pa-content // styles .pa-loading // styles .pa-title // styles
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このマークアップの場合：

  .p-awesomepage header.pa-header wow, header! .pa-content .pa-title my awesome title .pa-loading .pa-title loading is being loaded
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプローチとスタイラスのルールのネストを組み合わせる場合（主なことはシフトしないことです。そうしないと、出口でソーセージが出ます）、交差点はありません。



ジェイドについては何も言うことはありません。 これは非常にテンプレートエンジンです。 スリムを使用した人は同じです。 サポートにはインクルードとパーシャルが含まれます。 一般的なhelpers.jsファイルを介してヘルパーを投げました。 独自に登録することもできますが。 たとえば、すでに持っている：マークダウン。

展開について少し

開発の開発方法に関するすべてがすぐに理解できる場合は、ここで少し考えなければならない展開を展開する方法を示します。 レールについては、capistranoのような9999999ソリューションがすでに発明されていますが、これまでのところ、ノードで機能するものを見つけることができませんでした。

私は、次のことを行う「cake deploy」というケーキの指示を最大限に活用するために、テストVPSを決定しました。

  task 'update', '[VPS]: Update current state with new from repo', -> console.log('[Cake]: Pulling updates from repo') exec('git pull', (error, stdout, stderr) -> unless error console.log('[Cake]: Installing npm packages') exec('npm install', (error, stdout, stderr) -> unless error console.log('[Cake]: Restarting forever') # exec('forever restartall') exec('killall forever') exec('killall nodejs') console.log('[Cake]: Cleaning up old assets') exec('find ./public/assets -regextype posix-egrep -regex ".*\.(js|css|gz|gzip)$" -delete') exec('cake forever') sendMail() else console.warn("[Cake]: Installation failed with error: #{error}") ) else console.warn("[Cake]: Update failed with error: #{error}") ) task 'deploy', '[DEV]: Deploy current repo state to dev VPS', -> console.log('[Cake]: Connecting to VPS mobota@mobota-dev.ostrovok.ru && running update') exec('ssh mobota@mobota-dev.ostrovok.ru \'cd /var/www/mobota && cake update\'', (error, stdout, stderr) -> if error console.warn("[Cake]: Deploy failed with error: #{error}") else console.log('[Cake]: Deployed!') )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実稼働環境にロールアウトするために、Denis Orlihinはdebianパッケージをセットアップしました。 teamcityの頭蓋骨は機能し、アセンブリの前にテストを実行します。 とてもかっこいい。 詳細はお伝えしませんが、おそらく彼が何らかの形で伝えるでしょう。



テストといえば。 ハハフロントエンドであり、原則として非常に怠laなので、私は通常テストを書きません。 しかし、サードパーティのAPIに依存する必要があるため、ここでは統合テストが本当に必要でした。 mocha + chaiJSのテストを作成しました。 非常にシンプルで便利、そして最も重要なのは優れたレポーターです：



（私は公園に座っているので、インターネットは超高速ではなく、テストは落ちました）

これはすべて非常に興味深いですが、モバイル開発についてはどこにありますか。

そして確かに、それは最も重要なことのための時間でしょう。 本格的なブラウザと比較して、モバイルデバイス用に開発する際に気づいた違いは何ですか。 一度に複数のプラットフォームで作業する必要があり、各プラットフォームには独自の問題があることを考えると、それほど単純ではないことがわかります。 昨年から状況はそれほど変わっていないと言える。 主な問題は、2番目のバージョンのAndroid携帯電話と4代前半です。 iOSでは、奇跡もありますが、すべてがはるかに簡単です。



まず、問題に関する詳細。 一部は非常に明白ですが、繰り返します。 いくつかは私にとって初めてのことでした。つまり、他の誰かに役立つ可能性があります。

• ブレーキをクリックします。 300msのクリック遅延については誰もが知っています。 サイト上の通常のリンクのクリックは、クリック後約300ミリ秒で処理されます。 これは、これが実際にはクリックであり、他のジェスチャーではないことを理解するために必要です。 おまけとして、タッチスタートイベントリスナーをリンクに追加しようとすると、いわゆる ページのコンテンツが既に変更されている場合でも、正確に300ミリ秒後に同じ領域でゴーストクリックします。 また、Android 2ではまったく別のページで発生します。 この問題にはいくつかの解決策があります。 Googleのように、これらのゴーストクリックをキャッチするための独創的なスキームを考案できます。 または、原則としてリンクを拒否してイベントをクリックするだけです。 私の場合、2番目のオプションを選択しました。 Zeptoには、このためだけのカスタムタップイベントがありますが、壊れています。 ソリューションを作成しました。おそらくGitHubに投稿します。
  
  
• 網膜上のぼやけた写真。 現在、pixel-ratio> 1.5のデバイスが増えています。つまり、仮想ピクセルごとにいくつかの物理ピクセルがあります。 そのようなデバイスで画像がぼやけないようにするには、画像を数倍大きくアップロードして拡大縮小すれば十分です。 遅延のアプローチは、常に大きな画像とスケール（背景サイズのFTW）をアップロードすることです。
  
  
• 遷移/変換を伴うハードウェアアクセラレーションアニメーション。 ここではすべてが明らかであるように見えるので、あらゆる場所でtranslateまたはtranslate3dを使用してください。 実際、そうではありません。 まず、GPUを使用してすべてのプロパティを高速化するわけではありませんが、ごくわずかです。 位置、透明度など 第二に、Android 2には、アニメーション化されたブロックの周期的なちらつき、「クリスマスツリー」の出現、および一般的なブレーキの形でのtranslate3dに関する重大な問題があります。 さて、GPUレイヤー上にあるブロックを再レンダリングする必要がある場合、iOSには問題があります。 たとえば、私のサイトにはサイドバーがあり、ドラッグすることができます。また、クリックするだけでアニメーション化されます。 クールなことに、場所はほとんどありませんが、アニメーションでは他のどこにも見たことがありません。 しかし、問題は、コンテンツをGPUに転送すると、一部のページに移動すると、ちらつきが始まり、ブラウザがそれを描画してGPUに再度ドロップするまで、画面から0.5秒間消えます。 左/上を使用することに戻らなければなりませんでした。 さらに、翻訳を使用してどこかに引き出されたブロックにネイティブ選択要素を表示すると、Android 2では完全に機能しなくなります。 留意してください（ドロップダウンリストは、ブロックが元々画面に表示されていた場所ではなく、元の場所に表示されます）。
  
  
• 固定位置。 私も試しません。 オーバーフロー：スクロールを使用すると、状況は改善されるようであるため、fixedなレイアウトの固定要素の問題を解決する必要があります。 前回探したとき、iOSでオープンキーボードを使用して再描画してもうまくいきませんでした。
  
  
• Android 2はJSON.parse（null）で素晴らしい動作をします。 解析する前に文字列を検証してください。 そして彼は、テキストシャドウでテキストを完全にレンダリングする方法を知りません。 ハイフネーションが機能しない場合があり、一部の文字が飛び去る場合があります。 私はいつもやる：
  
  

    .android2 * text-shadow: none !important;
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  多くの時間と神経を節約します。
  
  
• ウィンドウの動作にはいくつかの違いがあります。 まず、スケールを非常に簡単に変更できます。これは、大規模なブラウザーではほとんど行われません。 規模を拡大することをお勧めします。人生が楽になります。 次のようになります。
  
  

    meta(name="viewport", content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no")
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  また、 モバイルのhtml5boilerplateメソッドpreventZoom（）を確認する必要もあります。 それは大いに役立ちます。 とにかく、そこからたくさんのクールなものをとることができます。
  
  
  
  画面の高さ/幅の決定に問題がある可能性があります。 Android / iOSの回答には一貫性がありません。 特に、Androidは一般に、実際の2倍の幅と高さがあると言えます。 可能な限りCSSを使用することをお勧めしますが、本当にしたい場合は、次のようにできます。
  
  

    class Size _min_width: 320 _min_height: 416 _iOS_toolbar_height: 44 _android_delay: 300 constructor: -> @width = null @height = null if $.os.ios app.dom.win.on('orientationchange load', @orientationChange) else app.dom.win.on('orientationchange resize load', => window.setTimeout(@orientationChange, @_android_delay) ) @orientationChange() orientationChange: => prevWidth = @width prevHeight = @height if $.os.ios and not window.orientation @width = window.screen.availWidth @height = window.screen.availHeight - @_iOS_toolbar_height else @width = app.dom.win.width() @height = app.dom.win.height() @width = Math.max(@_min_width, @width) @height = Math.max(@_min_height, @height) if @width isnt prevWidth or @height isnt prevHeight app.trigger('size:resize', width: @width height: @height )
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  コンテンツ/ウィンドウの高さの決定、多くの冒険を期待して、この点でモバイルブラウザは非常にクールであり、フルスクリーンで何かをすることは普通であり、オーバーレイ/モーダルでは簡単ではありません。
  
  
• 特に長時間何も要求されていない場合、ネットワーク要求は非常に遅くなります。 クエリの並列化も良い考えではないかもしれません。そのうちの1つは簡単に失敗する可能性があり、結局のところ、これは高速ではありません。 私は、素晴らしい答えでいくつかのリクエストをしようとします。 （最大は500kb-1mb最大ですが、モバイル通信のままです）。 うまくいくようです。 DOMを使用した操作-同じ話。 デバイスが非常に物静かなので、すべてが非常に遅くなります。 特にAndroidでは、彼らの問題が何なのかわかりません。 新しい4でさえ同じiPhone 4Sを失います。 一般に、通常のルールがここで機能します-リクエストとグループの書き込み/読み取りが少なくなります。
  
  
• Android 4の以前のバージョンはHistory APIをサポートしていません。 つまり、Backboneでは、通常の状態更新の代わりにハッシュを使用する必要があります。 新しいバージョンはすでにすべてをサポートしているはずであり、Android 2は常にサポートしているので、気にしませんでした。
  
  
• ページを下にスクロールしてコンテンツを変更すると、Androidはスクロール位置を元の位置に戻しません。 新しいコンテンツの高さに応じて、目に見える問題がある場合があります。
  
  
• 画面のどこかに飛んでいるposition：absoluteのブロックがある場合は、高さがそれほど大きくないことを確認してください。 そうでない場合、ページに「穴」が表示され、あたかもそれがある程度の高さを占めているかのように見えます。 iOSの実際。
  
  
• iOSで全画面表示を行う場合は、ルート要素の1つの高さを実際の画面の高さに設定する必要があります。 そうしないと、どんなに一生懸命試みても、ステータスバーはどこにも行きません。 高さ：100％も正常に機能しません。
  
  
• 親ブロックにオーバーフロー：スクロール、位置の子：絶対がある場合、Androidでのレンダリング時に問題が発生する可能性があります。 オーバーフローを無効にすることによってのみ解決されます：スクロール。
  
  

一般に、開発アプローチは、非常に弱いマシン上の大規模サイトでの作業に似ています。 バッテリーとプロセッサ/メモリのリソースが非常に限られていることを忘れてはならず、実際のデバイスのパフォーマンスを常に確認してください。 もちろん、これはテストに使用できたデバイスに基づいた私の個人的な経験です。 私はいくつかの点で間違っているかもしれません。



デスクトップのブラウザとは異なり、モバイルの開発ボーナス：

• デバイスはブレーキをかけていますが、まだ最新のものであり、多くがサポートされています。 これは、キーフレーム/トランジションおよび最新のJavaScriptなどによるアニメーションを意味します。
  
  
• プラットフォームは3つだけです。 iOSは単独で非常にうまく機能します。デバッグには、Safariの開発者ツールを使用することをお勧めします。 さらに悪いことに、Androidでブラウザログをadbコンソールに出力するものはほとんどありませんが、それでも2つのプラットフォームと同様のブラウザエンジンしかありません。 多くのベンダープレフィックスについて忘れることができます。
  
  
• 新しいおもちゃで遊ぶのはいつも面白いです。 また、モバイルサイトはネイティブアプリとしてラップするか、少なくともホームスクリーンに追加できます。 素晴らしい。
  
  

おわりに

私たちは開発者になるために素晴らしい時間を過ごしています。 アイデアが頭に浮かび、それを簡単に実装できます。 残りの人々は、彼らにとって実現できないアイデアで生きています。 したがって、コードを記述してNodeJSを使用してください。迅速、便利、非同期、そして若者です。 そして、文字を入力するのではなく、アイデアを思いつくのにもっと時間がかかります。



GitHubのサイトから何かを投稿すると思います。自分でそれを見て使用することができます。 皆さん、頑張ってください。