情報ではなく経験をアウトプットすること - 余白
調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
謙遜しないと決めている話 - 余白
僕は誰かに褒められたとき、謙遜しないようにしている。 褒められたら「ありがとうございます」「嬉しいです」「照れます」と、はっきり言葉で喜びを示す。 これを心がけはじめた最初のころは意識的だったけど、最近では意識しなくても自然にそう振る舞えるようになった。 これまで何人かに、「それいいですね」と言われることがあって、そういえばこの自分ルールについてちゃんと言葉にしたことがなかったなと思ってこの記事を書いている。 褒めたいと思ったあなたを否定しない 「謙遜しない」というルールの根幹は、「褒めたいと思ったあなたを否定しない」ということ。 褒めてもらったことが、自分が本当に認められたいことではないときもある。あるいは、何気なくやったことで自分ではそれほど価値を感じていないことのときもある。 それでも、相手が自分を褒めたいと思ったそのことはその人にとって疑いようのない事実である。「そう思った」という
README.mdに動的コンテンツを埋め込む、あるいはImage via Functionというアプローチ - 余白
突然ですが、 README.md に動的なコンテンツを埋め込みたいと思ったことはないですか？僕はあります。 具体的には、リポジトリのコントリビューターをREADME.mdに埋め込みたいという願望がありました。 つまりこういうことです。 しかし毎回CIなどでREADME.mdを編集するのはセットアップが面倒です。 <contributors-list> みたいなCustom Elementsが使えたらきれいな世界だなあと思ったのですが、肝心のscriptタグが動かないのでそれは無理です。 ということで、頼れるのは 画像 ということになりました。 Image via Function README.mdに埋め込めて、なおかつ動的なコンテンツを扱えるのは画像のURL展開だけなので、つまりコントリビューターリストを画像化するHTTPエンドポイントを用意し、そのURLをREADME.mdに埋め込めば
無責任な"not for me"発言は迷惑なのでやめてほしい - lacolaco
愚痴。 最近特定の技術やライブラリ、ツールなどに対して、「自分には合わなかった」のような発言をする人をよく見かける。 ちょっと前だと「○○はクソ」のような直接的なdisが目立っていた気がするので、少しは丸くなったつもりなのかもしれないが、 Angularというひとつの技術のユーザーコミュニティを主催する僕としては余計に迷惑だ。 もっと慎重になれ medium.com AirbnbがReact Nativeを使うのをやめた記事、これは本当に偉い。 技術選定を行い、結果的にマッチしなかった、というレポートには、最低限次の項目が必要だと考えている。 開発の目的 選定理由 マッチしなかった理由 このどれが欠けてもいけない。単に言葉遣いが柔らかいだけでdisと変わりないどころか、下手するとFUDにすらなり得る。 FUD - Wikipedia FUD（英: Fear, Uncertainty and
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
危機感の話 - 余白
常に危機感がある。これは自分が博士号も修士号も持っておらず、第三者から観測可能な価値を持っていないどころか、コンピューターサイエンスの教育を受けたことがないくせにソフトウェアエンジニアとして専門職に就いて生計を立てているのが根底にあるかもしれない。 プログラマーとしてインターネット上で活動しはじめたころからずっとアカデミーに対して劣等感がある。 自分がやっていることなんて高度な教育を受けた人間がちょっと参入してくればあっという間に淘汰されるだろうし、常に風前の灯火っていう感じがしてる。 正直なところ1年後に自分に仕事があるかどうかまったく自信がない。半年後すら曖昧だ。3年後なんてまったく想像もできない。 何をしても足りてない気がするから、毎日生き急いでいるような気がする。 本当は価値がないかもしれないけども、少なくとも価値があると錯覚してもらうために、常に可能な限り優れた成果を出してそれを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
