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.comのアカウントは仕事用と私用で分ける方がいいの？ - Islands in the byte stream
追記(2019/04/11): sonots氏がGitHubの方と相談しつつ設計した運用方法が公開されました。 全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG このガイドラインは今後のデファクトスタンダードになると思うのでtl;drを引用します。 個人で会社用と私用の2つの無料GitHubアカウントを持つことはGitHubの規約「非」準拠だった 会社用GitHubアカウントを廃止し私用GitHubアカウントを利用する規定に変更した セキュリティを担保するためGitHubのSSO機能を利用した GitHubの規約的には、おそらく「会社として会社用アカウントを pro版にする」「個人が身バレを防ぐために個人アカウントをpro版にして会社用アカウントを別途作る」などの運用も可能だとは思います。しかし、GitHubというサービス自体マル
DX: Developer Experience （開発体験）は重要だ - Islands in the byte stream
DX: Developer Experience （開発体験）とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」（＝義務）以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
HTC U11 は安心して人におすすめできるシムフリーAndroid端末だ！ - Islands in the byte stream
www.htc.com 発売日に買って2週間ほど使ってますが、非常に快適です。 ここ1年で Android Z4 ⇢ Huawei P9 Lite ⇢ HTC U11 と変えてきましたが、一番ストレスフリーかもしれないです。シムフリーだし*1、変なビルトインアプリはあまり入ってないし*2、指紋認証がついてるし*3、Felica もついているし*4、USB debugも有効にできます*5。今のところ気になるのは、ボトムナビゲーションのホームボタンが指紋認証デバイスとかぶせているせいで独自実装なのがちょっと慣れないと使いにくいのと、ボトムナビゲーションにあるはずのIME切り替えボタンが存在しないのが不便だということくらいです。 Felicaと指紋認証のついているシムフリーのハイエンドAndroid端末というのがなくて困っていたわけですが、HTC U11は今のところ申し分のない出来です。よかった
High Sierraには「アプリのリンクを踏んでもChromeの空白ページが開くだけ」というバグがあるっぽい - Islands in the byte stream
一時的な回避策ですが、このバグが発現する状態になったら「Chromeを再起動する」で回復するようです。このエントリを書いている時点でのmacOSの最新版は 10.13.2 (High Sierra) なので、以降のバージョンでは直ってるかもしれません。 ぼく自身はまだSierraのままなので伝聞です*1。ただTwitterのタイムラインで頻繁にこれ系の悩みを見かけて、そのたびに返信しているのでもっと知られるべきだなと思い、キーボードを叩くことにしました。 追記: Chromeのアップデートがきているときに起きやすいようですが、アップデートが来ていなくても起きるようです。 なんか、アップデートが降って来てる状態だと発生するぽいです— SHIBATA Hiroshi (@hsbt) December 19, 2017 これみんななってたのか。アップデートなくても起きるなあ。 / “High S
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は
Rubyの型定義ファイルを中央repoにしないほうがいい理由 - Islands in the byte stream
あるいは私がDefinitelyTyped (DT) が失敗だと思っている理由、です。 DefinitelyTypedは明確に失敗だと思っているので、あれを避けるのはそんなに難しくないかなと。まず (1) anyを認めて「型がなくてもいいや」という気持ちでいく (2) 中央repoは作らずそれぞれのgemに対して型定義パッチをおくりつける でなんとかなるっしょ。— FUJI Goro (@__gfx__) September 19, 2017 あたりが話の発端です。 DTについては以前いまいちイケてない理由を書いたことがあります。 TypeScriptのDefinitelyTypedは「ダメでもともと、うまく使えればラッキー」くらいの距離感がよい - Islands in the byte stream この時の話を一言でまとめると「ライブラリの作者ではない第三者がメンテしていることが多く
なぜTypeScript推しなのか - Islands in the byte stream
KibelaのフロントエンドをES2015からTypeScriptに絶賛移行中です。 www.typescriptlang.org で、なぜ flow じゃないくてTSなのかって話です。 flow vs typescriptである理由は、どちらもJSのスーパーセットをうたう静的型付きのaltJSだからです。この時代にあえてaltJSを導入する理由としては静的型があるというのが必須で、かつ学習コストを考えるとJSのスーパーセットであるのが望ましいでしょう。 言語仕様 言語仕様の点から言うと、決定的な差はないと思っています。 メリットもだいたい同じで 生産性: エディタの補完をJSよりも賢くできるので、より少ない脳のワーキングメモリでコードを書ける 堅牢性: コンパイル時に（＝多くのケースではエディタで）typoなどの間違いを検出できるのでバグを減らせる 学習コスト: JSをベースにしており、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
