Re: 技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - @kyanny's blog
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience - Speaker Deck 「品質と速度はトレードオフの関係ではなく、比例する」みたいな話を見聞きするたびにモヤッとするのが、 本当に短期的な話、三十分以内に変更してデプロイしたい、みたいな「短期的」な話であれば「テスト書いてる時間はない」は間違いではない、一分将棋みたいなギリギリのプロジェクトに従事している人のことを考えろ（？） 「ちゃんと設計せずに作った（そうせざるを得ない外圧があった）→ちゃんと設計する余裕があれば負債を溜め込まずに済んだ」みたいに聞こえるが、十分な時間があったら負債が出ない高品質の設計ができたとでも思っているのか？ ↑に書いた「三十分か一時間か」みたいなギリギリの状況ならいざ知らず、日・週単位でスケジュールが組まれてるソフトウェア開発プロジェクト
RuboCop リネーム騒動の所感 - @kyanny's blog
Is it time to change the name? · Issue #8091 · rubocop-hq/rubocop · GitHub Rubyists, we must do better | timriley-info The RuboCop Name Drama Redux | Meta Redux 件の騒動を知る前に「Black Lives Matter の流れに乗って名前変えたらいいんじゃねーの」とは思った 難癖をつけられて揉める前に済ませておくほうが楽そう、とか FactoryBot のことを当然思い出しながら 個人的に RuboCop は好きではなく愛着もないので、というのもある リネームしたら？という提案自体は、まぁ妥当な範囲内だと思う master ブランチやめます話もあることだし https://twitter.com/mislav/status/1270
NewsPicks は往年のはてなブックマークに似ている - @kyanny's blog
@kyanny 金額はまぁいいんだけど（ちょっと高いと思うけど！サブスクリプション系サービス税抜き 1000 円弱が相場と思うので）「社会的にも立派な肩書の成功したおじさんたちがよそ行きの格好して社交するはてブ」的なコミュニティに自分がハマってしまいそうなのが怖いんだよなー— Kensuke Nagae (@kyanny) May 12, 2016 @kyanny なにせ自分がもうすでにそういうおっさん世代だからね...「社会的に立派な肩書がなく特に成功もしていない平凡なおじさん」からみて（ある種）憧れの対象になりうるエリートおっさんのファン・取り巻きに、いかにも自分みたいなタイプはなりそうで、あまり想像したくない— Kensuke Nagae (@kyanny) May 12, 2016 @kyanny 「社会的に立派な学歴・職歴もなく特にモテてもいない平凡なネトヲタ」がはてブでサブカル
書評: リーダブルコード - @kyanny's blog
オライリー・ジャパン高様より献本いただきました。ありがとうございます。 「The Art of Readable Code」については過去にブログで二度触れたことがありますが*1、日本語訳の出版に際し改めて紹介すると、これはコーディングに上達したい人のための本です。良いコードとは読みやすいコードである、と明確な定義をまず述べて、具体的にどのようなコードが読みやすいのか、読みづらいコードのどこをどう改善すれば読みやすくなるのかを掘り下げていきます。 この本が素晴らしいのは、徹底して具体的かつ実践的なテクニックを取り扱っていることです。ともすれば抽象的で主観的な内容になりがちなコードの読みやすさという話題を扱っていながら、豊富なサンプルコードと的確な改善例を示すことで、誰もが日々のコーディングに取り入れて毎日のコードをより良くしていけるように配慮されています。 本書で紹介されている考え方やテク
Postgres.app を使え - @kyanny's blog
Homebrew でインストールした PostgreSQL に接続できない・起動できないトラブルが何度も何度も起こり、そのたびに直し方を調べてもこれという方法がなぜかすぐに見つからなくていつもいつも時間を無駄にするので、諦めて Postgres.app を使うことにする。 次にインストール・アップグレードなどの作業をするとき目を通すべきドキュメント psql とかへのパスの通し方は、 Using Command Line Tools with Postgres.app pg gem のインストールに失敗するときは、 Configuring Ruby for Postgres.app rails console などで盛大にエラーが出るときは、 gem uninstall pg で全部削除してから bundle install し直す
Book: Web API: The Good Parts - @kyanny's blog
内容はよくまとまっていた。確かにそこは悩むよね、という点がいくつもカバーされていて、かつ既存の API をリサーチしたまとめを元にベターな選択肢が述べられていて納得感がある。 API の設計や実装に慣れている人でも、迷ったときのリファレンスとして利用できると思う。薄い本なので全体的に言及が浅い印象があるけど、随所でより深い議論へのポインタがあるのもよい（海外ブログの URL とか） セキュリティの話題を扱う第6章だけ異彩を放っている感じがした。一読する価値はあるけど、バージョニングの話とかレスポンスデータ構造の話とかと比べるとだいぶ毛色が違っていて、この章の一部だけ妙に収まりが悪く感じた。 校正が杜撰だった。あまりにひどくて読みながら誤変換とかミスっぽい部分をメモしたら21箇所もあった。それ以外にも日本語の文章としてなんか変、みたいなのもあった。今まで読んだ本のなかで最低レベルのミスの多さ
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
rbenv のメカニズム - @kyanny's blog
rbenv 環境下で実行された Ruby プログラムの中から他の Ruby プログラムを起動するときに、 rbenv 環境をリセットしたい―要するに別のバージョンの Ruby で外部プログラムを実行したい―という事情があったので rbenv のメカニズムについて調べた。 rbenv 環境下で ruby コマンドを実行するとき、実際にコンパイルされた ruby バイナリが直接実行されているわけではない。 rbenv 環境をお膳立てした上で ruby バイナリを exec するラッパーのシェルスクリプトが実行される。こういうものを binstub と呼ぶ。 binstub である ruby という名前のシェルスクリプトの中身をみてみると、最終的に rbenv exec というサブコマンドを呼び出している。 rbenv のサブコマンドはリポジトリでいうと libexec ディレクトリ以下にある。
github に登録する公開鍵ファイルを id_rsa.pub じゃない名前で使いたい→ ~/.ssh/config で解決 - @kyanny's blog
github_id_rsa.pub とかを別につくって git コマンドにはそっちのペアを鍵ファイルとして使って欲しいんだけどうまくいかない。 $ export GIT_SSH="ssh -i ~/.ssh/github_id_rsa" $ git clone git@github.com:XXXX/XXXX # Permission deniedGitのリポジトリにsshでアクセスする | Hiroaki's blog をみて warpper つくってみたけどやっぱりだめ。こちらは ssh コマンドがヘンになるみたい。 $ echo '#!/bin/sh shift exec ssh -i ~/.ssh/github_id_rsa $*' > ~/bin/git-ssh $ export GIT_SSH=$HOME/bin/git-ssh $ git clone git@github.c
「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブログに投稿した記事を IFTTT で Day One に投稿する - @kyanny's blog