はてなブックマーク

事実と思われる情報を時系列で並べる。足りないものがあるかもしれない。 6/2 に噂を Ben Sandofsky が tweet 。 There’s a rumor React Native was abandoned in the main Facebook app. Anyone heard similar/different? — Ben Sandofsky (@sandofsky) 2018年6月1日 このひとは Halide という iOS で提供されているカメラアプリの開発者。これは純粋に噂が真実かどうか確かめたいという発言のように見える。 https://itunes.apple.com/jp/app/halide-raw%E6%92%AE%E5%BD%B1%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B%E6%89%8B%E5%8B%95%E3%82

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? react-native-dom とは experimental と書いてあるが普通に動く。デモを見ると React Native で提供されている仮想 DOM は大体動くといった感じ。 2018 年の React Europe で発表された資料。 https://rndom-slides.vincentriemer.app/ https://www.youtube.com/watch?v=aOWIJ4Mgb2k これの何がすごいかというとブリッジの仕組みにのっとって構築されているところだ。 Native First と言っている。 ブ

activation code とは ここでは次の特徴を持つデータのことをいう。 特定のサービスでのみ有効 文字列 1 度しか使えない OS やプロプライエタリーなソフトウェア、プリペイド式の仮想通貨などで使われているようなアレ。 どういうフォーマットがいい ? 文字種 打ち間違いがないように 1 と I 、 0 と O など似ている文字がないほうがよいが、 1 桁にできるだけ情報量を持たせたい。ということでいろいろ見てみたところ Base32 が良さそう。 Base32 では ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 の 32 文字を使ってエンコーディングする。 40bit 単位でエンコーディングするのではみ出した分は = でパディングされるが、 ID として使うときにはパディングをとってしまえばいい。 長さ 入力の手間を省くため短いほうがよいが、後述する衝突確率

Xcode に staging/production ビルド用の設定を追加する staging/production 用のビルド設定を追加したい、ということがあるはず。 ここでは production ビルドをユーザーが実際に使うもの、 staging ビルドを production ビルドと同一だけど限られた範囲で使うもの、という前提で書いていく。 元ネタはこちら。 https://github.com/facebook/react-native/issues/11813 production ビルド用設定を追加する 簡単な production 用ビルドから。 Scheme の追加 Scheme 選択欄から Manage Schemes... を選ぶ。 Xcode メニューの Product -> Scheme -> Manage Schemes... からでもアクセスできる。 対象の

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

React Native Japan で @besutome 、 @YutamaKotaro と技術書典 3 で技術書を書いたのでその作業内容を記録しようと思う。 出した本はこちら。 PDF 形式で配布している。 おおまかに次の流れで作業した。 原稿を書く + 校正作業 レビュー Re:VIEW 形式への変換 装丁 + 微調整 次で各手順について書いていく。 textlint と Re:VIEW Template は素人が使っても確実に威力を発揮するので強く使用を推奨。 原稿を書く + 校正作業 原稿は markdown で書いて git で管理した。今回は複数人で書いたので github に repo を作ってそこで共有。 原稿を書く際は先に textlint と日本語用のルールをセットアップして、日本語として不自然にならないかチェックしながらやった。非常に有用なので使用をおすすめ。 h

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

「いつも「時間がない」あなたに」を読んで、開発に役立てられることたくさんあるなーと思ったのでまとめる。 "SCARCITY: Why Having Too Little Means So Much" という本の日本語訳。原題からわかるとおり、「欠乏」についての科学的な実験結果と洞察がまとめられている行動経済学の本。時間への欠乏について「も」言及されているが、どちらかというと貧困など社会的な欠乏への対処を大目標においた、現在のまとめ的な立ち位置の本。「おれたちのたたかいはこれからだ」で締められている。 ただまあ非常に読みづらい。神話的というか、口伝的というか、寓話や例が多く登場するが明快なまとめがなく、主張したいことがわかりづらい。時間がない人は最後に訳者が主張を 3 ページでまとめてるのでそこをまず読んで、目次をたよりに具体例を探していくのがよいかも。 というわけで、書かれていることから実

React.js × React Native meetup 申込時にもらっていた質問をパネルディスカッションで答えようとしたものの時間がなくてお蔵入りになってしまったがそれはもったいないので答えていくコーナー。 パネルディスカッションでしゃべった内容とも重複しているところがある。 ↓も参考に。 以降 React Native を RN と略する。 データフロー Web では React/Redux がデファクトスタンダードだが RN ではどうか ? flux データフローを使わずに済む規模であれば導入コストもばかにならないので React のみで書くのがよい。 MobX で書いている方を知っているが、小規模なのでわかりやすさ重視で書きたいとのこと。 それ以外は Redux しか聞いたことがない。 ↓MobX と Redux の比較について React Conf 2017 でセッションがあ

どこでも動いてほしいツールは golang で書いて Github の release page からバイナリー落とせれば最強じゃんと思ったのでその設定を書き留める。 前提は次。 Github に golang で書いたツールの public repo がある 目指すところは次。 特定形式の git tag を push したときだけバイナリー生成してダウンロードできるようにする 参考にしたのは次。 http://qiita.com/toruuetani/items/b41805ef8568b4ae0519 このときから Github の UI や CircleCI の機能が変わっている 実際に動いてるプロジェクトは次。 https://github.com/januswel/dotor https://github.com/januswel/yangpao Github 設定 Circl

2016 年になって React Native 開発が現実的な選択肢となってきたので、 advent calendar の締めとしてメリット・デメリットの整理と、はじめるための諸情報をまとめる。 メリット React Native の利点だと言われる次のことを詳細に。 実行速度が速い 開発速度が速い OSS 開発要員の確保が容易 実行速度が速い よく聞かれたり、ハナシが噛み合わないときに確認したらそうだった、ということとして「 WebView 上で動くから遅いんでしょ ? 」ということがある。たぶん Cordova あたりを思いだして言っているのかなと思いつつも、既存の JavaScript によるモバイル開発の感覚はまったく役に立たないという返答をしている。 どのくらいサクサク動くのかという例として既存のアプリをみてもらうのがはやいので、次のアプリをインストールしてスクロールしまくってほ

チーム開発をやっていると特定の処理を呼び出す際にインターフェイスを明示することがとても重要になってきます。言い換えると使い方がきちんと示されていることが最低ラインということです。ドキュメントは実際の処理と乖離しますし、各人がソースコードの処理を追わなければならないというのはチームでやっている意味がありません。 ところが JavaScript にはそういった仕組みが存在しません。どういった処理をするのかを表すための関数名は指定できますが、 JavaScript では関数を任意の名前の変数に代入できるので実はあまり役に立ちません。 といった状況にあった JavaScript ですが、昨今のツールの登場によって事情が変わってきました。 JavaScript でもインターフェイスを明示しながら開発するにはどうすればいいかを要素技術と一緒に書いていきます。

React Native 開発でも mocha を使う理由 React Native ではテスティングフレームワークとして Jest が推奨されていますが、 Jest は Jasmine 系の API を受け継いでいることもあり、 mocha に比べると習熟が難しいことが難点です。 API を覚えるまでは expect に続けてどういった条件を書けるんだっけ、とリファレンスをあさる必要が出てきます。 こういったことを覚えずにすむ mocha は非常にコストパフォーマンスのよい技術です。単純に assert で満たすべき条件を羅列してやるだけでテストが書けます。テスト駆動開発で有名な @t_wada 和田卓人さんは No API is the best API とおっしゃっています。 ちなみに react-native init 時の Jest インストールは設定で抑制できます。 React

CureApp では DDD と JavaScript を使って小さなチームで柔軟にマルチプラットフォーム対応を実現しています。ここではそのために実施している方法や必要となる知識を共有します。 ちなみに実際に対応しているプラットフォームは次になります。 Web desktop iOS Android DDD という考え方 DDD とは Domain Driven Design の略で、 Eric Evans がソフトウェア開発を実践する中で得た知識・方法論をまとめて提唱したものです。日本語訳された本が出版されています。 以下これを DDD 本と呼びます。 ドメイン ひとことでいうと「解決したい問題」のことです。ある疾患を治療したいという問題や、もっと簡単に飲料缶を自動販売したいといった問題、つまり自動販売機をどう実現するかなどがあたります。 モデリング 「解決すべき問題から見た物事の捉え方

React Native とは ? 一発目なので簡単な紹介から。 React.js と同様、仮想 DOM で UI を記述できるモバイルアプリ作成用の JavaScript フレームワーク。特徴としては次のようなものがある。 EcmaScript 2015 宣言的 コンポーネント指向 CSS ライクなスタイル指定 flow による型チェックサポート 公式で取り上げられている使用例は次にまとめられている。 思想は次のページで説明されている。これは去年の記事。 重要だと思う点をとりあげる。 keep development velocity: 開発速度を落とさない One of the most painful things about our transition to mobile, though, is how much it's slowed down our development

Node 学園祭 2016 印象に残ったセッションのまとめ。 計画・実施されたみなさま、とても楽しかったです。ありがとうございました !! 動画も公開されたようです。 Demystifying JavaScript Engines http://slides.com/a0viedo/demystifying-js-engines#/ https://github.com/a0viedo/demystifying-js-engines http://togetter.com/li/1047918 JavaScript エンジンについてのセッション。 2006 年ごろの牧歌的なインタープリターのハナシからはじまって、 JIT のかけ方、各実装ごとの最適化のかけかた、 Garbage Collection の実装まとめまで。 最後の話題である GC について↓あたり読めばいいかも。 http:/

Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up

実を言うと次の方法だと brew update && brew upgrade すると動かなくなる場合があっていろいろ面倒だったんだけど最近は vm で docker で container だよねということで以下略。 ひとりでしか使わないからバックエンドは sqlite でもいいんだけど、 MariaDB を使うことにする。 docker machine 作成 できるだけ用途別にわけたほうが楽だと思うので Redmine 用の docker machine をつくる。 docker-machine create --driver virtualbox redmine eval "$(docker-machine env redmine)" コンテナー群 以下、各コンテナーを順に作っていくけど手っ取り早く動く環境がほしいという場合は一番最後からみていくといい。 MariaDB コンテナー

新 Firebase のどの機能を React Native で使えるのか調べてみた。 現在使える機能 基本的に次のページで Web で使える機能は React Native でも使えるよう。 Realtime Database 以外は未検証。 Cloud Messaging Authentication Realtime Database Storage Hosting その他の機能は bridge 経由になる。 Analytics はすでに bridge がある。 それ以外はいまのところ自前で bridge を書く必要がある。 セットアップ方法 Firebase プロジェクト作成 次のボタンを押して新しいプロジェクトを作成する。 config の情報を次の位置から取得する。 次の apiKey, authDoamin, databaseURL, storageBucket の値をひかえ

元記事: http://tadeuzagallo.com/blog/react-native-bridge/ 翻訳については https://github.com/januswel/react-native-bridge-ja で管理している。 また、元記事では文字で説明されている部分も含めて実行時の簡単なフローを描いてみた。ここで bundle というのは React Native packager によって bundle されたファイルのこと。 というわけで、以下翻訳。 この投稿では React Native の基礎を知っている方を対象に、ネイティブと JavaScript の通信時における内部の動作へ焦点をあてます。 メインスレッド 何よりも先に、 React Native では 3 つの主要なスレッド1があることを覚えておいてください。 シャドウキュー コンポーネント再配置時に使用

React Native で development, staging, production など環境を切り替えるJavaScriptAndroidMobileiOSreactnative 基本的に React Native は development か production かしか切り替えができない。 __DEV__ React Native では development かどうかを判別する仕組みとして __DEV__ というグローバルな変数が定義されている。次のページに書いてあるように、 packager に bundle してもらう際、 dev という query prameter に true か 1 を指定したときに __DEV__ = true としてくれる。 これを見て設定を切り替えればいい。 ちなみに Android で cd android && ./gradlew

C++ のユニットテストを簡単にあつかえるようにしてみた。 要素としては次。 Google Test https://code.google.com/p/googletest/ 現在一番扱いやすい C++ ユニットテスト用フレームワークだと思う。 CMake との親和性が高いのもよい。 CMake http://www.cmake.org/ ユニットテストのコンパイルを楽にするために。 実行と結果の要約表示は付属の CTest を使うといい感じになる。 ここでは CMake まわりの設定について説明していく。 Google Test の使い方については各自で調べてください。 サンプル CMake の都合上ディレクトリー構造がキモになってくるのでわかりやすさのためにサンプル作ってみた。 トップで次のコマンドを打つとテストまで完了する。 project root/ cmake/ # CMake

Bitrise でもテストできるので一見 CircleCI はいらないように見えるんだけど、 Bitrise は push / pull request でしか trigger できないので細かい制御、例えばリリース用の tag を付加したときだけ動かしたい場合にやっぱりいる。 Bitrise.io スマホアプリ向け CI サービス。スマホアプリに特化しているだけあってかなり楽に iOS / Android のビルド設定ができる。具体的には次がうれしい。 Provisioning Profile や keystore などをアップロードできるのでセキュリティ的に安心 ↑を github repo に commit しなくてよい Bitrise を信用する必要はある メモリーが足りなかったりビルド時間が長すぎて打ち切られたりがない 少なくともいまのところこれで落ちたことはない UI でぽちぽ

一部嘘が書いてあったので修正。コメントで教えてくれた @Linda_pp さん、 @thinca さんありがとう。 この記事は vim advent calendar の 8 日目の記事。 vimconf 2015 でのどっちしゃべるか迷ってしゃべらなかったほうのテーマを書く。 rlhelp.vim は年末にいじるよ…。 ここで書くのは複数環境で動く .vimrc や .gvimrc の書き方であって、それらを複数環境で同期させる方法ではない。これについてはそのうち書くかも。 どうやって環境を切り分けるかというのはわりと出てくるんだけど、どういうときに切り分けたほうがいいか、うまい切り分け方というのはあまりない情報なので自分の設定から引っ張りだしてみる。 https://raw.githubusercontent.com/januswel/dotfiles/master/.vimrc ht

C++ の lint ツールとして cpplint がよさそう。 キレイなコードを書くためにこれを強制したいんだけど、 editor の設定やなんかだと使ってるものによって方法が違うので逆にめんどくさくなってしまう。 じゃあ必ず通るパスはどこだということで git commit は絶対やるわけだからそこで cpplint をかけてしまおうという流れ。 cpplint に通らないと commit できなくする。 こういうときは pre-commit hooks を使うらしい。 というわけで設定を作ってみた。 cpplint を使うリポジトリーの直下に tools ディレクトリーを作ってその下に cpplint.py を置く。 で、次のファイルを .git/hooks/ の下におくと git commit 時に勝手に cpplint が走ってくれる。 #!/bin/sh # # An exam

watcher が実体化した際に使用するメモリーは自分で管理する必要がある。 ある watcher に対応するイベントを発生させなくても、強制的に動作させることもできる。 状態遷移 watcher は次のうち、どれかの状態になる。 initialized イベントループに登録される前の状態 initialized になるにはイベントが発火した際に動作するコールバック関数の設定が必須 active / running / active イベント発火を待っている最中の状態 ドキュメントに書かれている方法を除いて、読み書き・移動・解放できない pending active で監視対象のイベントが発火された後の状態 stopped になるか、コールバック関数が実行される直前までは pending ev_io とか繰り返し使用できる watcher は pending からまた active に移行

autotools に比べてとても使いやすい。 CMakeLists.txt ビルド対象のディレクトリーに CMakeLists.txt を配置することで cmake コマンドが対象だと認識してくれるようになる。 最低限必要な設定は次になる。 cmake_minimum_required CMakeLists.txt に記載されている内容を実行するにあたって必要な CMake のバージョンを明示する add_executable 実行ファイル名と、そのビルドに必要な c / cpp ファイルの指定 ヘッダーファイルはここに指定しなくても、更新すると勝手に認識してリビルド対象にしてくれる target_link_libraries リンクするライブラリーの指定 gcc に -lfoo と指定していた場合、 foo とだけ書く ビルド対象の分割 複数のビルド対象がある場合、ひとつの CMake

自前でこったことをするわけでなければ log4js-node と node-config で。 https://github.com/nomiddlename/log4js-node https://github.com/lorenwest/node-config fluentd にログを送りつけたい場合は fluent-logger-node を使う。 log4js を使ってログをはきつつ、環境ごとの設定を node-config できりわける。 node-config は <environment>.json という名前で環境ごとに設定を書けるみたい。開発用と本番用でログまわりの設定を変えてみる。 基本的に以下の 3 つのログをとることにするよ。 アプリのシステムログ アクセスログ エラーログ 開発用ではすべてのレベルのログをコンソールにたれながす。 { "log4js": { "le