サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
gfx.hatenablog.com
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
DX: Developer Experience (開発体験)とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」(=義務)以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
追記: この件に関してエンジニアHubにもTypeScriptの記事を書きました: TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に - エンジニアHub|Webエンジニアのキャリアを考える! TypeScriptに対する失望は2パターンあって、その理由は理解できるのですが、いずれにせよそこでTypeScriptを捨てる判断をするのはもったいないと思っています。この2つの失望を感じたとしてもなお、TypeScriptには導入する価値があると思っています。 パターン1: 実はJavaScriptに対する失望である そこらのブログやTwitterで観測していると、理由の7割くらいこれです。これは、TypeScriptが独立した言語ではなくJavaScriptへのトランスパイラ(言語変換ツール)であり、独立したランタイムを
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に(=多くのケースではエディタで)typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
Kibelaは次のようにいくつかmarkdownを拡張しています。 PlantUML記法に対応しました - Kibela Blog 記事の外部共有とLaTeX記法による数式表示に対応しました - Kibela Blog そして、今後もそういう拡張は増えていくと思われます。 PlantUML KibelaのPlantUML記法はこういうやつです。 ```plantuml Bob -> Alice : hello Alice -> Bob : Go Away ``` GitLabも同じ構文でPlantUMLをサポートしていますね。 PlantUML & GitLab - GitLab Documentation crowiも最近PlantUML記法をサポートしはじめましたね。構文はKibelaとおなじです。 Support PlantUML by sotarok · Pull Request
2019年9月9日からFastlyに入社しています。勤務地は東京です。今後ともよろしくお願いいたします。 前職の Bit Journey, Inc. では3年ほどKibelaのサーバーサイドやフロントエンドアプリの開発に関わりました。Bit Journey在職中に子供がうまれ、現在も夫婦で分担しながら子育てをしていますが、この子育て初期という大変な時期*1にBit Journeyで気持ちよく働けたのはたいへんな僥倖でした。ここで改めて感謝いたします。 さて、Fastlyは方向性を変えて、ウェブアプリではなくVarnishやH2Oなどのミドルウェアの開発に関わります。 Kibelaは自分が数年のあいだ心血を注ぐにふさわしいサービスでしたし、実際のところ大いに開発を楽しみました。しかし、しばらく今後のキャリアの方向性を考えた結果、かねてから経験してみたいと思っていた低レイヤーなソフトウェア開発
こないだの@onkさんのスライドがとても良かったんですよ。 短期間で新技術を学ぶ技術 from Takafumi ONAKA 短時間といいつつ守破離の「離」までいくのに3年かかるといってて、高速道路なんてものはないんだなということがわかりますね。 とはいえ自分自身に照らし合わせてみてもそのとおりだなと思いました。ぼくもAndroidで対外的にアウトプットできるようになるまで3年くらいかかってますし。まあ、ぼくは新技術を学ぶのはわりと苦手なほうではあるんですが。 で、スライドにはないけど新しい技術を学ぶ際には大きな壁がいくつかあるなとあると思ってます。それを 意識して 乗り越えるための指標としてもこのスライドはよさそうだなと。 ついでなのでちょっと ぼくの感じる 三大壁をまとめてみました。まあ、壁を壁と感じない人もいると思いますけどね! Lv.1 着手の壁 症状: 何の役に立つのかわからない
Android Javaでは昔からAOSPのcoding style guidelineに則ったスタイルがとられることが多いようです。そのなかで、private fieldに "m" (member) や "s" (static member) などのプレフィクスをつけよ、というものがあります。 AOSP Java Code Style for Contributors | Android Open Source Project これはいわゆるハンガリアン記法の変種で、こういうやつですね。 class Recipe { private String mTitle; private List<String> mSteps; // ... } これについての態度はプロジェクトごとに様々ですが、たとえばクックパッド社のJavaのスタイルガイドでは明確に否定しています。 styleguide/
Rails Developers Meetup 2018 (#railsdm) で話した資料です。Railsの話はほとんどなくて、全文検索の仕組みとスコアリングについてのまとめが主です。 Q&Aシステムでの質問もここで回答します。 Q. データの同期はどうされていますか? 同期はActiveRecordのcallbackでActiveJobに更新jobを投げる形で非同期で行っています。また、データ構造などの更新がある場合にindex再構築するときのためのblue-green deployment用のバッチがあります。 Q. 何かgemを使われていますか?使われているなら、どんな選定理由ですか? いまはelasticsearch-railsを使っていますが、このエントリの後半にあるような理由で捨てようと思っています。移行先はまだ決めていません。 Q. 辞書を作ったりしていますか? Amazo
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は
github.com Railsのcontrollerで違和感があるのって actionのinputに params というインスタンスメソッド経由でアクセスすること しかも params はviewからアクセスできる! actionのoutputが controller のインスタンス変数への代入であること しかもそのインスタンス変数はviewからアクセスできる! というところだと思うんですよ。 なぜなら我々は「メソッドの引数でinputを受け取りメソッドの戻り値をoutputとすべし」ということを是としてコードを書いてるわけじゃないですか。リーダブルコードを読むまでもなく、変数のスコープは狭ければ狭いほどメンテナンスしやすいリーダブルなコードだというベストプラクティスを正しいものとしてコードを書いているわけじゃないですか。 そういうベストプラクティスに真っ向から反しているのが現在のRa
追記(2019/04/11): sonots氏がGitHubの方と相談しつつ設計した運用方法が公開されました。 全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG このガイドラインは今後のデファクトスタンダードになると思うのでtl;drを引用します。 個人で会社用と私用の2つの無料GitHubアカウントを持つことはGitHubの規約「非」準拠だった 会社用GitHubアカウントを廃止し私用GitHubアカウントを利用する規定に変更した セキュリティを担保するためGitHubのSSO機能を利用した GitHubの規約的には、おそらく「会社として会社用アカウントを pro版にする」「個人が身バレを防ぐために個人アカウントをpro版にして会社用アカウントを別途作る」などの運用も可能だとは思います。しかし、GitHubというサービス自体マル
追記: StreamやOptionalはpreview-2で実装されたようです。 gfx.hatenablog.com Android N previewが公開されましたね!このバージョンではJava8のサポートがあると発表されています。また、標準クラスライブラリがOpenJDKベースの実装になったことで、Java8との互換性が高まるのではないかという前評判もありました。 First Preview of Android N: Developer APIs & Tools | Android Developers Blog 本エントリでは、この「Android NでJava8」について解説します。 三行まとめ Android N runtimeはOpenJDK7ベースで、Java8クラスライブラリは一部のみ移植されている Android N SDKに同梱されているJackコンパイラはlam
GitHub ActionsからGitHub wikiを更新したいことがたまにあります。たとえば、何かのメトリクスを見やすく整形したものなど、repositoryのデータを何らかの形で加工したドキュメントを作りたいときです。コード生成したmarkdownドキュメントをコミットしてもいいですが、それよりはシンプルで運用が楽です。 今回は、GitHub repoで管理する原稿の文字数(など)を継続的に見れるページを作ると便利かなと思って作りました。自分一人だったらローカルで適当なツールを叩けばいいですが、同repoを見れる編集者にも共有したいとなると独立したページがあるほうが便利ですからね。 リポジトリはこんな感じです。 github.com 基本的には、 actions/checkout を使って "${{ github.repository }}.wiki" をcloneして編集してpus
半年くらいまえにBit Journeyに転職してKibelaを作ってました。AndroidエンジニアからRails + Reactエンジニアへの転向ということになります。 Kibelaはこちら。ようやく本日リリースできました。といっても開発面でいうとこれからが正念場ではあります。 Kibela - 個人の発信を組織の力にする情報共有ツール “個人の発信を組織の力にする情報共有ツール” と銘打っているとおり、これは 個人が組織内で自由に情報を発信すると組織が活性化する という仮説に基づいて設計されている、会社などの組織向けのサービスです。もちろんそれだけでなく、仕様書の整理につかったり議事録をとりあえず突っ込んでおくみたいなのもありです。 さてKibelaでできることはBlogとWikiを書くことです。これはつまり 個人が発信する情報 とそれ以外を分けるということです。このあたりの思想やベス
Android用ORMライブラリを書き始めました。 github.com 開発の動機 AndroidのORM事情は2014年の天下一「AndroidのORM」武道会 - Qiita あたりをどうぞ。ただ2015年11月現在だとDBFlow 2.xが爆速になっており、GreenDAOに匹敵するレベルになっていそうです。ほかのライブラリもいろいろアップデートしているので、天下一Android ORM武闘会の2015年版が望まれます。 さて本題ですが、私がAndroidのORMに求めるものは下記のようなものです。 高速 Realm並は無理でも、爆速ORMとして知られるGreenDAO程度の速度はほしい upgrade / downgradeできるmigration機構 なるべく自動的によしなにやってくれるのがよい たとえば開発中にカラムを追加したときは自動的にmigrationしてほしい マイグ
npm dependenciesを更新してGitHub Compare Viewのリンク付きでPRするツールを定期実行する - Islands in the byte stream このci-npm-updateはTypeScript 2.0 (beta) で書いたので、TypeScript+NodeJSツールを開発するときのプロジェクト構成の一例としてざっと解説しておきます。 最近はRailsなどのウェブアプリのJSもnpmで管理するようになったため、そういう条件でNodeJSツールを開発することも増えてくることでしょう。 Table of Contents Table of Contents エディタ tsconfig.json TSLint Task Runner Visual Studio Code Tasks shrinkwrap 所感 See Also エディタ Visual
『Androidを支える技術 I』 ~ 60fpsを達成するモダンなGUIシステム ~ 『Androidを支える技術 II』 ~ 真のマルチタスクに挑んだモバイルOSの心臓部 ~ これらを著者の有野さん よりご恵贈いただきました。ありがとうございます。 始めて知る内容も多かったのですが、既に知っていることでも著者の意見が反映されているのを読むと、いくつものモバイルOSを見てきたハッカーからみるとこう見えるのか!という新鮮な面白さがありました。 IとIIのテーマは独立しているので、どちらから読んでもいいと思います。 以下個人的に面白かった章をピックアップします。 I の見どころ §1: ActivityThread.java にあるAndroidアプリのエントリポイント public static void main(String[] args) の役割 ActivityTheadはデバッグ
セマンティックバージョニングは守るとして、だいたいこんなポリシーでやってます。 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
id:kazuho さんと「gitのbranchを消すべきか否か」という話をしていて、ぼくの「ローカルにせよリモートにせよbranchが増えすぎると目的のブランチを見つけられない」という意見に対して次のエントリを教えてもらったのでした。 git branch の結果を時間順にソート - kazuhoのメモ置き場 一理あるかもしれないと思ってこれをgitに組み込むためにgitのソースコードを眺めていたら、実はもうできるということを知りました。それがこれ: # 新しいのが下 git branch --sort=authordate # 新しいのが上 git branch --sort=-authordate このソートに使えるフィールドは、 git branch --help を引くと "The keys supported are the same as those in git for-e
追記(2019/04/16): 2017年半ばにここで触れているプロジェクトはTSに移行しました。今となってはTS+Reactの組み合わせは全く問題がなく、むしろ非常に相性のよい組み合わせであるとすらいえます。 TypeScript化の調査 2016年9月現在(React v15.3.1, TypeScript 2.0-rc)の話です。 いま開発しているウェブアプリのフロントエンドをTypeScript化しようと思ってちょっと調べてみたんですが、今やるのはいくらTypeScript推進派でもちょっと厳しいなと。 TypeScriptでimportできるライブラリは、TypeScriptのコード(.ts)またはdts: TypeScript definition files (.d.ts) のみ Reactは素のJS + 一部FlowType なのでdtsの公式提供は期待できない Defin
三行まとめ 保育所*1の電子化データは提供元によってファイル形式もデータの構造も異なるためプログラムで加工しにくい 東京都の場合、認可保育所一覧はそれぞれの区が管理しており探すのが大変 保育所のデータはプログラムで加工しやすい統一されたフォーマットで提供してほしい 保育所データの現状 保育所を検索するAndroidアプリでも作ってみるかなと思って保育所のデータを探しているのですが、いまのところプログラムで簡単に加工できるデータを見つけられていません。 たとえば、東京都の場合、代表的な保育所の種類としては「認可」「認証」「認可外」などがあります。 認可保育所の一覧は23区などの自治体が提供しているため、それぞれの区のサイトを探す必要があります。 たとえば港区と目黒区をみるとこんな感じです: 港区: http://www.city.minato.tokyo.jp/kodomo/kodomo/k
Android Software Development Kit License Agreementにこういう項目があります。 3.4 You may not use the SDK for any purpose not expressly permitted by the License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of
課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 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 (コマンドが失敗するとシェルスクリプトが即座に終了する)を効
コード生成でGsonをMoshiより高速化する - Islands in the byte stream の続きです。 GitHub - gfx/StaticGson: Static Gson binding library with annotation processing 三行まとめ StaticGsonはannotation processingでコード生成してGsonを高速化する拡張で、結果はLoganSquareより少し遅い程度 欠点はメソッド数+バイナリサイズのオーバーヘッド 利点はGsonと互換性の高さ。モデルにアノテーションをつけてGson初期化でオプションを一つ与えるだけ 解説 リフレクションで処理していたところをコード生成にして高速化する手法は思ったより効果ありそうだな、ということでjcenterにリリースしました。以下のように依存指定すると使えます。 depende
三行まとめ Cライブラリzopfliをwasmにビルドして npmjs.com にリリースしてみた wasmはポータブルなバイナリで、ネイティブコードと比較して半分程度の性能を期待できる emscriptenは N-API と比べると出来ることが少なすぎるのが課題 背景 WebAssembly *1 の評価のために、Cで書かれたzlib互換の圧縮ライブラリ google/zopfli をemscriptenでwasmにビルドしてリリースしてみました。 評価だけでなくリリースまでしたのは、zopfliのnodejs native addonである node-zopfli をしばしばインストールできないことがあるという問題があってそれを解決したかったからです。nodejsのnative addonはnode-gypというビルドツールを使うことが多いようですが、これはPython 2.x などn
GraphQLって用語が分かりにくいんですよね…ということで社内用に作った用語集を公開しておきます。 GraphQL http://graphql.org/ グラフキューエル query language リクエストのフォーマットがGraphQLということ レスポンスはJSON(でもMessagePackでもなんでも) GraphiQL https://github.com/graphql/graphiql グラフィクル GraphQL用のAPIコンソールというかAPIエクスプローラとかそういう類のもの 補完のサポートを受けながらqueryを書けるので "GraphQL IDE" とも呼ばれる 実体はReactベースのウェブアプリ(フロントエンドアプリ) graphiql-rails はこのフロントエンドアプリをRails Mountable Engineとして扱うためのgem GitHu
追記(2023/11/29): 2023/11/1からまたZaimでアメリカン・エキスプレスとの連携ができなくなりました: (11/2 掲載)アメリカン・エキスプレスの連携不具合について:よくある質問|家計簿アプリ Zaim。マネーフォワードではできているようです。困惑の極み…。とりあえずZaimのプレミアムプランは解約しました。 最近、我が家の家計のための家計簿アプリを、5年ほど使ったマネーフォワードMEからZaimに乗り換えました。今のところ、機能的には満足しており、かつこれまでできていなかった我が家の家計スタイルに合った家計簿の運用がようやくできるようになったので、大変満足しています。 もともとあった課題として、マネーフォワードMEは我が家の家計スタイルを実装していないというものがありました。我が家の家計スタイルは、別に特殊なものではなく、次のゼクシィの記事の「【2】お互いに、毎月定
次子のために5ヶ月の育休をとった記録です*1。 家族構成は、外資系*2勤務フルタイムワーカーの私、同じく外資系勤務フルタイムワーカーの妻、長子のmfx氏(2017年9月生まれ)、そして次子のrfx氏(2022年6月生まれ)という四人家族です。 私が育児休業をとったのはrfx氏の育児のためです。妻がはrfxの誕生の1ヶ月前から産休に入り、11月いっぱいまで育休をとりました。私は妻と入れ替わるように11月下旬から翌年の4月下旬まで育休をとったため、約5ヶ月間育児休業を取得することになりました。つまり、rfx氏が保育園に入園して慣らし保育が終わるまでの期間を、私たち夫婦で分担して育休をとり、育児に集中することにしたのです。 長子のmfx氏が生まれたときは、私は育休を取得しませんでした。当時は人数が一桁台のスタートアップ企業に勤めていましたが、育休は取ろうと思えば取れたはずです。しかしなんとなく「
次のページ
このページを最初にブックマークしてみませんか?
『Islands in the byte stream』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く