はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 動機 「スマホ用Webサイトが既にあるんだけど、それを上手く使ってアプリ化出来ない？」という話は、まだ一定数存在します。 その時に、「結局個別にKotlin/Swiftで実装するのが一番良いですよ」と反論したいアプリエンジニアも一定数いると思います。 私もその一人なので、理論武装のためにまとめました。 ただ、ほとんどの技術要素については実運用の経験が少ないため、間違いが含まれている可能性があります。 その際は、コメントや編集リクエストで教えて頂けると助かります 方針一覧 Web (PWAを利用し、アプリっぽく見せる) ガワネイティブ (

動機・前提 今更ながら、とある案件でガワネイティブの要望が出てきそうだったので、事前調査としていくつか調べました。 "ガワネイティブ"という表記が一般的なのかは不明ですがこの記事では、 Webとスマホネイティブの間にある技術（ガワネイティブやハイブリッド、クロスプラットフォームなど） で記載したように「アプリ内WebViewで、サーバがレンダリングしたHTMLを表示する」とします。 サンプルとして作ったもの WebView内に表示するHTML https://github.com/noboru-i/sample-html/blob/master/webview.html iOS側のサンプル（playground形式） https://github.com/noboru-i/sample-hybrid-ios WKWebViewを利用しています。 Android側のサンプル https://

前提 既存のGoogle App Engine Python + Angular 1.x + CoffeeScriptのサービスを、Google App Engine Python + Nuxt.jsに置き換えようとしています。 最終的には、Nuxt.jsでbuildした結果を、Google App Engineのstatic_filesとして配信する予定です。 SPAモードを利用し、SSRは利用しません。（GAEでNodeを動かすのが大変そうなので） 今回APIアクセスには、 @nuxtjs/axios を利用しようと思います。標準っぽかったので。 環境・やりたいこと まず、ローカルで開発時は、本番稼働しているサーバに接続しようと思います。 （今後、ローカルでサーバを実行して、そちらに向けることも想定しています。） また、GAEではデプロイごとに https://20180610t220

CircleCIでプライベートなファイルを暗号化してレポジトリ管理する - Qiita を参考に、GitHubに暗号化したファイルを置いておいて、CircleCIでのビルドに利用していました。 今回、あるAndroidアプリをCircleCI 1.0から2.0に変更するにあたって詰まったのでメモ。 最初に結論 1.1より古いバージョンで暗号化したファイルを復号化するときは、 -md md5 をつける必要があるっぽい。 （ホントは、最新バージョンで暗号化しなおした方がいいはずですが。。） 何をしようとしたか CircleCI 2.0にするにあたって、Language Guide: Android - CircleCIを参考に、CircleCI側が用意しているDockerを利用しました。 そして、今までと同じように、暗号化しておいた google-services.json をCircleCI

CircleCI 2.0でAndroid関連の静的解析結果をPullRequestで指摘する - Qiita で、CircleCI側が用意したdockerイメージにRubyの実行環境が入っていなかったため、回りくどいことをしていました。 （workflowsを利用して、コードをattachしつつ、別のdockerイメージを動かす） その記事をベトナムの子会社に共有して数時間後、 https://github.com/circleci/circleci-images/pull/75/files というPRを教えてもらいました。 CircleCIの提供しているdockerイメージに、Rubyの実行環境が入ったようです。 これを使うことで、Rubyのコンテナは必要なくなりそうです。 ということで、やってみました。 変更点例 一部消しすぎてたので、追加修正。 https://github.com/

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Dangerとは Dangerとは、ざっくり言うと、PRのレビューをするときに、"You Forgot To...(...するのを忘れてませんか？）"と指摘するのを自動化するツールらしいです。 似たようなツールとして、以前から packsaddle/ruby-saddler を使っていたのは、 Androidのコードを自動で解析し、GitHubのpull requestにコメントする - Qiita にも書いていました。 Android開発のコードレビューbotを乗り換えた話 - クックパッド開発者ブログ を読むと、クックパッドさんもDokumiから乗り換えたということで、使ってみました。（ミーハー） （ミーハーついでに、fastlaneとか作ってる Felix Krauseさんが絡んでる？というのも、やってみた要因の一つ） 上記のブログにもDokumi時代の問題点が書かれていましたが、私

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はMonstar Lab, Inc. Advent Calendar 2016 3日目の記事です。 前日は @noboru_i の Androidアプリにログ系ライブラリを導入してみた話 - Qiita でした。 って、2日連続で書いてみました。 昨日のは、時間がなかったので社内Wikiの焼き直しにしちゃって、微妙だったので。 ただ、書いてみると、どこかで見たようなリモートワーク論の焼き直しになっちゃった気がします... 誰かの参考になれば幸いです。 経緯 2012年4月にMonstar Labに入社。 2015年2月頃に生まれ

動機 最近、Electronのアプリを作り始めました。 出来上がった機能をすぐに公開したいので、CircleCIでmac用のappファイルを作成し、GitHubのReleaseに上げる事にしました。 ただ、masterの変更の度にバージョン番号を上げるのも面倒だし、Releaseのタグが大量にあるのも微妙な気がしました。 （なにより、毎回tagを手動で作るのもめんどい） そこで、Releaseは毎回"更新"し、package.jsonのversionが変わっている場合のみReleaseを"追加"することにしました。 普通は逆というか、普通のフローとは違いますね。。 例： Releaseにv0.0.1が存在するとき、versionが0.0.1のままmasterが更新 以前のタグ・Releaseを破棄、最新のmasterでv0.0.1を再作成。 Releaseにv0.0.1が存在するとき、ve

基本的には、 https://circleci.com/docs/ios-code-signing/ の通りです。 設定が完了したものは https://github.com/noboru-i/kyouen-ios にあります。 （ほとんどは https://github.com/noboru-i/kyouen-ios/pull/29 のPRで行いました） 事前準備 CircleCiでiOSのビルドをするためには、Pricing and Plan Information - CircleCIにあるように、最低でも$39/月の課金が必要です。 また、GitHubとの連携設定や、fastlaneの利用のためのGemfileなどが必要です。 .p12ファイルをアップロード 今回はTestFlightで配信するため、"iOS Distribution"の証明書を発行しておき、CircleCIにアッ

"require-dev": { "fzaninotto/faker": "~1.4", "mockery/mockery": "0.9.*", "phpunit/phpunit": "~4.0", "phpspec/phpspec": "~2.1", "squizlabs/php_codesniffer": "*", "phpmd/phpmd" : "*" }, # !/usr/bin/env bash set -eu echo "********************" echo "* install gems *" echo "********************" gem install --no-document checkstyle_filter-git saddler saddler-reporter-github pmd_translate_checkstyle_fo

目的 Swiftも2.0になり、使う機会が増えてきました。 複数人で書くことも増えてくると、コードフォーマットの統一を図りたくなってきます。 realm/SwiftLintを利用したら、github/swift-style-guideベースのチェックが出来そうです。 ローカルでやる場合は、Xcodeに設定しておけば保存などのタイミングでチェックしてくれるのですが、担当者によっては無視してしまう可能性があります。 また、SwiftLintも日々チェック項目が追加されているので、開発者のローカルのSwiftLintが古く、チェックしきれてない可能性もあります。 Androidのコードを自動で解析し、GitHubのpull requestにコメントするみたいにしておけば、CircleCI→GitHubのコメントをしてくれ、Slackと連携しておけば違反が可視化しやすそうです。 実現すること Ci

この記事はCircleCI Advent Calendar 2015 - Qiitaの14日目の記事です。 13日目はnofrmmさんですが、まだ記事が無いようです。 余談 本当は、CircleCIでのiOSビルドの有料化に伴って、個人アプリのビルドをTravisCIに移したという話をしようと思いましたが、今でもCircleCIでビルド出来てる（金は払ってない）っぽいので、一旦移行はやめました。 なので、社内で実際に構築した別のことをまとめました。 背景 iOSアプリを受託で作る場合、いろいろ面倒ですよね。主に証明書周りが。 弊社でよくあるパターンとしては、 iTunes connectなどはお客さんしか入れない。 証明書はもらえる。 UDIDが増えたら、お客さんに連絡→provisioningを発行してもらう。 ipaファイルを納品する。 という感じです。 そのため、証明書やprovis

実現したいこと フォーマットがぐちゃぐちゃのコードや、close漏れしてるコード、使ってないリソースが大量にあるようなプロジェクトをこの世から駆逐したい。 CheckstyleとかFindBugsをコミットする前に毎回確認し、それを修正していけば駆逐出来そうですが、 つい忘れてしまったり、時間がないからと後回しにしてしまいがちです。にんげんだもの。 また、コードレビューで、スペースの位置とかインデントとか細かいことを指摘したくない。 そんなの、人間の仕事じゃないので、コンピュータにやらせたい。 ということで、下図のようにGitHubのpull requestにレビューの形で書けば、実装者は対応せざるを得ないし、 対応後のコードを人間がレビューすることで、人間は本質的なレビューに専念できます。（きっと 自動レビューの内容としては下記の通り。 Checkstyle FindBugs PMD C