set -eのもとで特定のコマンドの終了ステータスを変数に入れるシェルスクリプトのスニペット - Islands in the byte stream
課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 set -e # グローバルな状態を変える操作を行う git merge --no-ff --no-commit $main_branch || true # 結果をチェックしてexit codeを変数に入れる git diff --cached --exit-code --quiet ; code=$? # グローバルな状態をもとに戻す git merge --abort # 上位プロセスに結果を渡す exit $code スクリプト全体には set -e （コマンドが失敗するとシェルスクリプトが即座に終了する）を効
Findy Engineer Labに Individual Contributor の話を寄稿しました - Islands in the byte stream
engineer-lab.findy-code.io 詳細は記事を読んでいただきたいのですが、おかげさまで「ICという役割を初めて知った」「自分もIC的な働き方をしたいのだと分かった」という感想が複数みられたので、この記事を書いた甲斐はあったなあと思います。 一方でやや誤解というか説明が不十分だったかなと思うのが、「ICを役割としておいている企業では、ICはプレイヤーのデフォルトの役割である」ということです。Fastlyではそうですし、たぶんICを置いている他の企業でもそうです。ICはスタープレイヤーだけに許された特別な働き方では決してありません。私はIC的に働いてきて今後もICで行きたいと思いますが、ICと管理職（ピープルマネージャ）を行き来するという選択をとってもいいですし、むしろICとピープルマネージャを行き来するほうがICとしての成長に繋がりますよという主張もあります。 ともあれ私
GitHub ActionsからGitHub wikiを更新する - Islands in the byte stream
GitHub ActionsからGitHub wikiを更新したいことがたまにあります。たとえば、何かのメトリクスを見やすく整形したものなど、repositoryのデータを何らかの形で加工したドキュメントを作りたいときです。コード生成したmarkdownドキュメントをコミットしてもいいですが、それよりはシンプルで運用が楽です。 今回は、GitHub repoで管理する原稿の文字数（など）を継続的に見れるページを作ると便利かなと思って作りました。自分一人だったらローカルで適当なツールを叩けばいいですが、同repoを見れる編集者にも共有したいとなると独立したページがあるほうが便利ですからね。 リポジトリはこんな感じです。 github.com 基本的には、 actions/checkout を使って "${{ github.repository }}.wiki" をcloneして編集してpus
JSConf JP 2019で "How to Boost Your Code with WebAssembly" という話をしました - Islands in the byte stream
abstract: https://jsconf.jp/2019/talk/fuji-goro Wasmを触り始めるにはまだ少しはやくて、おそらく2020年にはリリースされるであろうSIMDなどがほしいところです。とはいえ、JSの最適化コンパイラ（スライドではV8のTurboFanにだけ触れていますがほかのJSエンジンでも基本的には同じ傾向なはず）に頼らず安定したパフォーマンスを出せるというのは大きなメリットなので、その方面だと現在の状況でも考慮に値する可能性はあります。 ところでスライドでも触れてますが、eBayのバーコードスキャナ事例は大変興味深いです。 WebAssembly at eBay: A Real-World Use Case ここのエントリでも次のように書かれていて This is sort of expected, as JavaScript can indeed be
ES modulesのexport defaultは使わないほうがよい - Islands in the byte stream
ES modulesにexport defaultってのがあるんですが、default exportのexport対象に名前が必須でないため、IDEによるコード補完と相性が悪いです。 他のところはどうしてるのかなと思って調べてみると、GoogleのTypeScript Style Guide では禁止されてました(v1.0.0, 2019/07 現在）。 https://github.com/google/gts/blob/v1.0.0/tslint.json#L40 ("no-default-export": true) TypeScript compiler coding guidelineには特に言及はないみたいですね。 https://github.com/Microsoft/TypeScript/wiki/Coding-guidelines そもそもexport defaultは
なぜTypeScriptに失望してしまうのか - Islands in the byte stream
追記: この件に関してエンジニアHubにもTypeScriptの記事を書きました: TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に - エンジニアHub｜Webエンジニアのキャリアを考える！ TypeScriptに対する失望は2パターンあって、その理由は理解できるのですが、いずれにせよそこでTypeScriptを捨てる判断をするのはもったいないと思っています。この2つの失望を感じたとしてもなお、TypeScriptには導入する価値があると思っています。 パターン1: 実はJavaScriptに対する失望である そこらのブログやTwitterで観測していると、理由の7割くらいこれです。これは、TypeScriptが独立した言語ではなくJavaScriptへのトランスパイラ（言語変換ツール）であり、独立したランタイムを
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
Androidライブラリのためのmaskaradeというorgを作った - Islands in the byte stream
The Maskarade project · GitHub 最近イマイチAndroidの活動ができてないんですが、Androidライブラリのメンテを諦めたわけではなくて、たとえばOrmaとかはまだやりたいことがいくつかあるのでやるつもりはあります。一方で、ちゃんと新しいメンテナがいたほうがいいなーというプロジェクトもあって、とりあえず私のメンテする気のあるなしに関わらずユーザーがいそうなAndroidライブラリを全部まとめて maskarade（マスカレード）というorganizationに移すことにしました。 何故これが必要なのかというと、新しくオーナーシップをもったメンテナを受け入れられる体制にするためにorgが必要だからです。GitHubは個人アカウントにあるリポジトリのオーナーシップをコラボレータに渡すことはできないんですよね。なので、オーナーシップを誰かに渡したいときは (1)
npmjs.com で著名ソフトウェアによく似た名前のマルウェアが大量に発見された - Islands in the byte stream
Malicious packages in npm. Here’s what to do | Ivan Akulov’s blog People found malicious packages in npm that work like real ones, are named similarly real ones, but collect and send your process environment to a third-party server when you install them 訳: 悪意のあるパッケージがnpmで発見された。それらは、実際のパッケージによく似た名前で同じように動くが、パッケージのインストール時にプロセスの環境変数を外部のサーバに送信する。 発見されたパッケージの一覧は元エントリをどうぞ。このようなマルウェアである偽パッケージの一例をあげると、 ba
『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はデバッグ
DroidKaigi 2017で「ORMの選び方」という発表をしました - Islands in the byte stream
Ormaの開発の際に他のORMはどういう設計思想なのかを調べたときの知見をもとに、DroidKaigi 2017用に仕上げた発表です。 これ契機にORMについて一家言ある人が増えるといいなと思いながら発表しました。 SQLiteDatabase (SQLiteOpenHelper) を直接つかうかどうかでいうと圧倒的にORMをつかったほうが早く品質のよいアプリを開発できると思っていて、それはやはりORMのマッピング、クエリビルダ、アソシエーション、pub-sub、マイグレーションといった機能が便利だからなんですよね。ただ便利といういだけのみならず、型安全だったり自動化してくれたりと信頼性を高める工夫を書くORMがしているわけで、それを使わないのはもったいないです。 その上で、まあ私としてはOrmaが私の感じる問題を解決してくれる唯一のORMなのでOrmaを使いますが、機能や将来性などを考え
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をモデルのフィールドに代入したりはしないからです。 つまり、次のよう
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
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
Orma v4.0.0 - RxJava2 & SQLBrite-like query observables - Islands in the byte stream
GitHub - gfx/Android-Orma: A type-safe ORM for Android as a wrapper of SQLiteDatabase v3.0.0からまだ一ヶ月くらいしかたってませんが、Ormaがv4.0.0となりました。 目玉機能は RxJava 2.x 対応で、これが後方互換性を維持したまま行うのが難しかったため、メジャーバージョンを上げることにしました。 RxJava 2.x 対応 機能的にはRxJava 1.x対応と同じ水準なはずです。 ただこれを機に、 Observable を返すものは AsObservable をサフィックスに、 Single は AsSingle に、 Completable は AsCompletableに…と、メソッド名を見ればRx observableのどの亜種を返すのかを分かるようにしました。 Query Obs
AndroidのCIはlintOptions.textReportを有効にしておくと捗る - Islands in the byte stream
ThreeTenABPの差分(v1.0.3...v1.0.4)を見ていて気づいたんですが、Android Lintの結果をテキスト形式で標準出力に出すことができるんですね。マニュアル にも書いてありますが、今日初めて知りました。 lintOptions { textReport true textOutput 'stdout' } これをするとコマンドラインのビルドでlintのwarningやerrorが表示されるので、たとえばCIがlint errorで落ちたときに手元でlintを走らせることなく原因がわかります。 日頃有効にしておくとwarningでも対処しようというプレッシャーになるので、やって損はなさそうです。
Orma v3.0.0-rc2 と内部設計の見直し - Islands in the byte stream
Orma v3.0.0-rc2をリリースしました。CHANGESはこちら： Android-Orma/CHANGELOG.md at master · gfx/Android-Orma · GitHub 三行まとめ あるモデルが複数の同じ型のモデルをdirect associationで持てるようになりました 内部的に非常に大きな変更を行ったので新しいバージョンを検証してみてください v3.0.0はもうしばらく寝かせてから来週あたりにリリース予定です 解説 このバージョンは、3.0.0-rc1と比較してただ1つのバグフィクスを含みます。しかし、この修正のために内部の設計の見直しが必要だったため、変更量が非常に大きいものになっています。 そもそもdirect associationとはなにか、このリリースで解決したかったことはなにかを説明します。 Direct Associations Or
Orma v3.0.0-rc1 for Android Studio v2.2 / Android Gradle Plugin v2.2 - Islands in the byte stream
Orma v2.x は Android Gradle Plugin v2.2 と同時に使えないという問題がありまして、このたびこれを修正した v3.0.0-rc1 を出しました。RCとはいうものの、中身はdeprecated methodsを消したくらいであまり変えていないので、安定性は v2.6.0 と大差ないはずです。 github.com CHANGES Orma v3.x は逆に Android Gradle Plugin v2.2 より古いものとは同時に使えないのでご注意ください。 また、Orma v3.0.0-rc1 は RxJava v1.2.0 の、晴れて @Beta となった Completable を使っています。したがって、RxJavaのアップグレードも必要です。 v3.0.0 正規版は #189 を修正したら出すつもりでいます。これがわりと内部的に大規模な変更が必要
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
potatotips #56 で 「OSS開発のリテラシー / Android編」という発表をしました - Islands in the byte stream
IntelliJ IDEAで特定行のGitHub PRを開く"Find Pull Request" pluginがまじイノベーティブ - Islands in the byte stream
