React Reduxファーストインプレッション - Islands in the byte stream
今更感ありますがReact Reduxを導入したの所感をメモしておきます。 github.com ざっとみてこれなら自分でも再実装できそうだなという印象 いままではreact-micro-container でfluxしてた cf. 小さいReactアプリケーションのためのライブラリ書いた - Qiita 新規Railsアプリに小さく導入するReact // Speaker Deck React Reduxにすると、個々のreact componentをfluxフレームワークに依存しない形で設計できる これに対して react-micro-container はcontainerに制御されることを意識した設計になる（＝containerとcomponentで設計が異なる） React ReduxなしでReactを初めてRect Reduxを導入するのは簡単だし、あとから別のflux実装にす
『Androidを支える技術』(I, II) の内容に興奮した - Islands in the byte stream
『Androidを支える技術 I』 ~ 60fpsを達成するモダンなGUIシステム ~ 『Androidを支える技術 II』 ~ 真のマルチタスクに挑んだモバイルOSの心臓部 ~ これらを著者の有野さん よりご恵贈いただきました。ありがとうございます。 始めて知る内容も多かったのですが、既に知っていることでも著者の意見が反映されているのを読むと、いくつものモバイルOSを見てきたハッカーからみるとこう見えるのか！という新鮮な面白さがありました。 IとIIのテーマは独立しているので、どちらから読んでもいいと思います。 以下個人的に面白かった章をピックアップします。 I の見どころ §1: ActivityThread.java にあるAndroidアプリのエントリポイント public static void main(String[] args) の役割 ActivityTheadはデバッグ
MathJaxによる描画を細かく制御する - Islands in the byte stream
MathJax というのはLaTeXなどで書いた数式を美しく描画するための処理系です。 なおこのエントリは MathJax v2.7.0 を対象にしています。 www.mathjax.org まず前提として、ほとんどのケースではMathJaxをconfigパラメータを与えてロードするだけで自動的にtypeset *1 が行われます。 この自動typesetは、HTML中のすべての要素に対してただ一度だけ行われるので、content editableでウェブエディタを実装しているケースやリアルタイムプレビューとの相性が非常に悪いのです。つまりcontent editable中のLaTeX記法は置き換えるべきではないのに置き換えてしまうし、プレビューが更新されてもtypesetされないのでこちらはLaTeX記法が処理されません。 そこで細かくMathJaxを制御する必要があるのですが、これがな
CommonMarkの現状 2017年4月版 - Islands in the byte stream
CommonMarkというのはMarkdownの標準化を目指して2014年に立ち上がったプロジェクトです。 当時のニュース: Standard Markdown Becomes Common Markdown then CommonMark (日本語版) 公式サイト: http://commonmark.org/ あれから3年、とうとうGitHubがCommonMarkを採用したというアナウンスがありました。つまり、長らくMarkdownデファクトと考えられてきたGFM: GitHub Flavored Markdownは、いまやCommonMarkのスーパーセットなのです。 A formal spec for GitHub Flavored Markdown | GitHub Engineering (2017/03/14) To ensure that the rendered Mar
JavaScript SSRのためのレンダリングサーバがほしい - Islands in the byte stream
いまReactのSSRのためにHypernova を使っていて、これはこれでちゃんと動くんですがいくつか不満があります。 Unix Domain Socketをサポートしていない アプリケーションサーバ（express）の設定をほとんど変えられない worker数とか bodyの圧縮にzstdを使うとか さらに、JSでレンダリングしたいコンテンツは他にもあって、たとえば MathJax Markdown CommonMarkだとC実装とJS実装があるのでめちゃくちゃ頑張らなくても同じようなものを作ることはできるが… なのでさしあたってこの三種類のコンテンツをレンダリングするためのNodeJSサーバがあるといいなと。 ここまでくるとNodeJSでアプリケーションサーバを書いたほうがいい気もしますが、まあそこは既存の資産があるのでステートレスなレンダリングだけでもまずはNodeJSでやれればな
<meta name="robots" content="noindex"/> でも検索エンジンにインデックスされるケースがある - Islands in the byte stream
noindex tagがあるにも関わらずインデックスされているケースを見かけたので調べてみたところ、googlebotに関してはどうやらそういう仕様があるようです。 noindex tag は常にインデックスの削除を行うのだと思っていたのでちょっと驚きました。 メタタグを使用して検索インデックス登録をブロックする - Search Console ヘルプ 重要: noindex メタタグを有効にするには、robots.txt ファイルでページをブロックしないでください。ページが robots.txt ファイルでブロックされると、クローラは noindex タグを認識しません。そのため、たとえば他のページからリンクされていると、ページは検索結果に引き続き表示される可能性があります。 Block search indexing with meta tags - Search Console H
Ormaに関する雑談＆質問用にgitterのchat roomをつくりました - Islands in the byte stream
en: https://gitter.im/Android-Orma/Lobby ja: https://gitter.im/Android-Orma/Ja 背景 GitLab、Slackライクなサービス「Gitter」を買収。有償プラン廃止で何人でも無料で利用可能に。オープンソース化も約束 － Publickey でひさびさにgitterを知って、悪くないんじゃないかと思って設置してみました。 OSSコミュニティの母体としてSlackをつかうことが増えてるようですが、gitterだとpublic channelであれば招待されなくても入れるし、コミュニティとしてはそのほうがいいですよね。 正直チャットサービスとしてのクオリティはSlackのほうが高いです。gitterはリアクションとかできないし、モバイルアプリもGitHubのパスワードをアプリ内ブラウザで入力しないといけないので使えない
カンファレンススタッフ用アプリがあるとよさそう - Islands in the byte stream
DroidKaigi 2017お疲れさまでした。スタッフとしては3回目、スピーカーとしては初めての参加でした。 スタッフとしては、受付の誘導、司会、副司会、会場の片付けなどをしました。特に司会はわりと臨機応変に行動しなければならず、部屋ごとにけっこうバラバラだったのではないかなあと思います。 カンファレンスが始まってからも次々と様々な仕様変更がきて、「意識を高くもって気をつける」だけだとカバーしきれないところがあります。そういう点をカバーできるようにカンファレンススタッフ用アプリがあるといいなーと思って記憶が鮮明なうちにメモしておきます。もちろん関係者でのKTPは別途しますが、それは公開されないと思うので。 実際に起きたこと スタッフのシフト表の変更 頻繁におきてた印象、というのもいくつか不整合がみつかるので シフト表にいれるスタッフは40人くらいいるので、不整合なく保つのは至難の業 セッ
DroidKaigi 2017で「ORMの選び方」という発表をしました - Islands in the byte stream
Ormaの開発の際に他のORMはどういう設計思想なのかを調べたときの知見をもとに、DroidKaigi 2017用に仕上げた発表です。 これ契機にORMについて一家言ある人が増えるといいなと思いながら発表しました。 SQLiteDatabase (SQLiteOpenHelper) を直接つかうかどうかでいうと圧倒的にORMをつかったほうが早く品質のよいアプリを開発できると思っていて、それはやはりORMのマッピング、クエリビルダ、アソシエーション、pub-sub、マイグレーションといった機能が便利だからなんですよね。ただ便利といういだけのみならず、型安全だったり自動化してくれたりと信頼性を高める工夫を書くORMがしているわけで、それを使わないのはもったいないです。 その上で、まあ私としてはOrmaが私の感じる問題を解決してくれる唯一のORMなのでOrmaを使いますが、機能や将来性などを考え
Bit Journeyに転職してKibelaをリリースしました - Islands in the byte stream
半年くらいまえにBit Journeyに転職してKibelaを作ってました。AndroidエンジニアからRails + Reactエンジニアへの転向ということになります。 Kibelaはこちら。ようやく本日リリースできました。といっても開発面でいうとこれからが正念場ではあります。 Kibela - 個人の発信を組織の力にする情報共有ツール “個人の発信を組織の力にする情報共有ツール” と銘打っているとおり、これは 個人が組織内で自由に情報を発信すると組織が活性化する という仮説に基づいて設計されている、会社などの組織向けのサービスです。もちろんそれだけでなく、仕様書の整理につかったり議事録をとりあえず突っ込んでおくみたいなのもありです。 さてKibelaでできることはBlogとWikiを書くことです。これはつまり 個人が発信する情報 とそれ以外を分けるということです。このあたりの思想やベス
Herokuのreview appsでRailsのLetter Opener WebをつかうHack - Islands in the byte stream
github.com これのREADMEにもありますが、Letter Opener (-Webも含む）をHerokuで使うにはちょっと注意が必要です。つまり、 Letter Openerはデータを #{Rails.root}/tmp/letter_opener に保存する Herokuはdyno (node) 間でデータのやりとりは出来ない設計 ActionMailerの deliver_later! はActiveJobで実行するので、web dynoではなくworker dyno のファイルシステムにLetter Openerのデータを保存する という状況なので、 #deliver_now! で送信したものはLetter Openerで見えますが、 #deliver_later! で送信したものは見えない、ということになります。 じゃあHeroku review appのときだけ #d
Orma v4.2.0 の Relation#upsert() の設計 - Islands in the byte stream
https://github.com/gfx/Android-Orma Orma v4.2.0 で Relation#upsert() を実装しました。これは、モデルのインスタンスを渡すとその状態に応じて INSERT または UPDATE を実行するというメソッドです。 モデル同士の関連もよしなにしてくれるので、とりあえず #upsert() で突っ込むといい感じに保存されるという便利メソッドです。 ただひとつ注意点があって、primary key の自動採番モード（デフォルトの挙動）のときに #upsert() 後にそのモデルを参照する場合は、#upsert() の戻り値を使わなければいけません。というのも、Ormaは どんなモデルでもimmutableであるという仮定 を置いており、自動採番したprimary keyをモデルのフィールドに代入したりはしないからです。 つまり、次のよう
新技術を学ぶ技術と三つの壁とDroidKaigi 2017 - Islands in the byte stream
こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね！ Lv.1 着手の壁 症状: 何の役に立つのかわからない
ObjectBox vs Orma - Islands in the byte stream
greenDAOの開発元であるgreenbotが新しいNoSQL ORMのβ版をアナウンスしたようです。 greenrobot.org いわく、マルチスレッドで使いやすく、バイトコード操作のようなマジカルな方法はとらず、マイグレーションを自動で行えてしかも爆速だと。これらの特徴はOrmaも標榜しているので、気になりますね。 ORMにとってのパフォーマンスは一番重要というわけではないものの、それなりには速くないと困るのは確か。というわけで、まずは軽くベンチマークをとってみました。コードベースはOrmaのリポジトリ内のベンチマークコードに追加した形です。 結論からいうと、読み込みはわりと速いです。 書き込みはOrmaとほぼおなじ水準 何度か繰り返すとOrmaより速いこともあります なおOrmaは手書きの素朴なコードよりも高速に見えますが、手書きのコードでの最適化をサボっているためです Real
Rails + React + SSRのもとでレスポンシブにするにあたって現状とっている方法 - Islands in the byte stream
SSRと絡めようとすると難しくて、いろいろ試行錯誤しました。いまはこういう方向でやろうとしていて、そこそこメンテナンス可能に書けそうだなという手応えがあります。 三行で CSSのメディアクエリのみを使い、Railsでテンプレートエンジンを使うにせよReactでSSRするにせよReactでCSRするにせよ同じ方法を使う PCのみ表示させる場合は .showPcOnly クラスを、スマホでのみ表示させる場合は.showSmartphoneOnlyクラスをつけたdivで囲む たまに .showPcOnly などとは別に width: 100% などを指定しないといけないが、それは別途クラスを定義して与える ヘルパーSCSSクラス こんな感じのヘルパーを用意しておく。 $smartphoneBreakpoint: 767px; @mixin smartphone { @media screen a
Ruby extのためのVisual Studio Codeのclang extension用設定を書き出す - Islands in the byte stream
Visual Studio Codeの C/C++ Clang extensionのためのいくらかの設定をすると、Ruby extensionを開発するときに補完が効くようになり、開発が楽になります。 C/C++ Clang - Visual Studio Marketplace ところでRuby extensionのCFLAGSなどの設定はわりと難しくて、実際のMakefileを読み込んでmakeを実行するのがてっとりばやいです。 というわけで、extconfを起動してMakefileをつくり、そこから必要なマクロを抜き出して .vscode/settings.json に書きだすためのタスクをつくってみました。 # additional Rake task for "ext/foo" namespace :vscode do desc "Setup Visual Studio Code
Android SDK 25.2.3から付属のsdkmanager(1)でパッケージのインストールをする - Islands in the byte stream
Android SDK 25.2.3にsdkmanagerとういコマンドが新しくく追加されていたようです。 sdkmanager これは、CLIでAndroid SDK packageを管理するためのツールのようです。Gradle Android pluginと同様にlicensesファイルに対応しているので、CIなどで扱いやすいですし、なによりandroidコマンドにはなかったパッケージのアップデートがサポートされています。このため、androidコマンドよりは扱いやすく工夫の余地が増えてると考えてよさそうです。 使い方はこんな感じです: # homebrewだとまだパスが通らないので絶対パスで参照する # インストール済みパッケージと利用可能なパッケージを出力する $ANDROID_HOME/tools/bin/sdkmanager --list # platform-toolsと旧名
Ormaの2016年振り返りと2017年の展望 - Islands in the byte stream
https://github.com/gfx/Android-Orma 2015年末に開発をはじめたOrmaも、この一年でだいぶバージョンが進んで、年明け時点で v0.20.0だったところが、年末時点でv4.0.2でした。v0.20.0...v4.0.2で21,768 additions and 6,328 deletionsということで、結構書いたなあという感じです。そのおかげでv1.0.0の頃とくらべると格段に安定していますし、機能も増えてます。 採用事例や紹介エントリも増えてきました。 ActiveAndroidからOrmaへ移行した理由 | eureka tech blog ちはやふるにはまったので百人一首を暗記するアプリ作った - もやもやエンジニア Android開発のマイベストプラクティス - Qiita 今から新規でAndroidアプリを書き始めるなら。 - wakwak3
ライブラリのバージョニングのしかた - Islands in the byte stream
セマンティックバージョニングは守るとして、だいたいこんなポリシーでやってます。 0.0.1 - proof of concept / minimum viable product 0.1.0 - とりあえずリリースしてプロダクションに組み込んでみる 1.0.0 - プロダクションに組み込んだ 2.0.0 - セマンティックバージョニングに従うので、メジャーバージョンアップは機能ではなく単にAPI互換性を失うという印 あとは、alpha, beta, rcなどを接尾詞としてつけることもあります。 *-alpha - 開発中 *-beta - 安定してきた *-rc - release candidate. プロダクションに組み込んでもOK
Suffix ArrayをRustで実装した - Islands in the byte stream
suffix arrayを一番簡単なアルゴリズムで実装する - アルゴリズム学習(その6) - $shibayu36->blog; を読んで、ちょうど自分も何らかの形で全文検索を一部実装してみようと思っていたのでRustで真似してみました。 Rustを選んだ理由は、以下の理由からです。 実際に全文検索を実装するのに耐えうるパフォーマンスであること パッケージマネージャなどのエコシステムが完備されていること Rustについてはそれほど詳しくはないのですが、GCや例外がないとのこと。であればパフォーマンスチューニングがC言語並にやりやすい可能性がありますし、一度真面目に勉強してみたいと思っていました。Goと異なり、ジェネリクスがあるのも魅力的です。 というわけでコードこんな感じになりました: pub fn make_suffix_array(s: &str) -> Vec<i64> { use
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
