Rubyのcaseを〇〇(言語名)のswitch文だと思っている人たちにぼくから一言ガツンと申し上げたい
「Rubyのcase」を一瞥し「あー要は〇〇(言語名)のswitchね」などと早合点し、その後もその真の価値を知ることなく一生を終えるプログラマが近年跡を絶たない。加えて、「今更条件分岐？RubyはOOPなんだからポリモフィズムじゃね？」とか「HashにProc突っ込んでcallするのがオレ流。」とかうそぶく人たちもまた増加の一途を辿っている。 そんな世の中にあって、ぼくは一言、できればガツンと一言申し上げたい。生まれも育ちもRubyなぼくから、是非ともそんな人たちに「Rubyのcase」について一言申し上げておきたい。 ─ 問題１ ─ 名前name、レベルlevel、ポイントpointの各属性を持った複数のCharacterオブジェクトcharlie, liz, benがある。 class Character < Struct.new(:name, :level, :point) def
[Chrome] DevToolsのWorkspaceでローカルプロジェクトをライブエディット&デバッグする - Qiita
※ 執筆時点ではCanaryで利用できます ChromeのDevToolsに「Workspace」という機能が追加されました Workspaceを使うとDevToolsをエディタとして使うことができます ローカルフォルダの追加 DevToolsを開いて歯車アイコンからSettingsを開くと項目に"Workspace"があるので選択 Add folderでフォルダを選択 リソースへのアクセス許可を求められるので許可を選択 Sourcesパネルに選択したフォルダが追加される リソースの編集の自動反映を有効にする ブラウザのリロードなしに編集・保存したファイルが反映されるようになる(htmlはむり？ 右クリックメニューから"Map to network resource"を選択 ダイアログでDevToolsの再起動を求められるので許可(Chromeの再起動ではない) 右側のエディタ部分でCSS
![[Chrome] DevToolsのWorkspaceでローカルプロジェクトをライブエディット&デバッグする - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/10db9711a05b6fb5a0ba4ff61e62a568c0e29e71/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCQ2hyb21lJTVEJTIwRGV2VG9vbHMlRTMlODElQUVXb3Jrc3BhY2UlRTMlODElQTclRTMlODMlQUQlRTMlODMlQkMlRTMlODIlQUIlRTMlODMlQUIlRTMlODMlOTclRTMlODMlQUQlRTMlODIlQjglRTMlODIlQTclRTMlODIlQUYlRTMlODMlODglRTMlODIlOTIlRTMlODMlQTklRTMlODIlQTQlRTMlODMlOTYlRTMlODIlQTglRTMlODMlODclRTMlODIlQTMlRTMlODMlODMlRTMlODMlODglMjYlRTMlODMlODclRTMlODMlOTAlRTMlODMlODMlRTMlODIlQjAlRTMlODElOTklRTMlODIlOEImdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZ0eHQtY2xpcD1lbGxpcHNpcyZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWU0NTM2MTllNDhiYWUwOGQxMTAwMWJkYTQ4YWViYWJj%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwbmFrYWptZyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YjNlYjExOWUxMTNlZTVjYzVjNTgwYTA4NWVlMTgzZTA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D5ebb1d3a463327af6fa0f41fab0dbb9c)
git bisect で問題箇所を特定する - Qiita
以前は問題なく動いていたはずの機能が、最新版では動かなくなっている・・・。こんなときは、「どのコミットが問題を混入させてしまったのだろうか？」を知りたくなるでしょう。 これを手助けするのが git bisect コマンドです。git bisect コマンドは、二分探索によって問題箇所を特定します。 事前準備 最初に大事なことがひとつあります。それは、「問題がない（good）状態と問題がある（bad）状態を、確実に判定できるようにする」 ことです。 当然のことではありますが、ここがあやふやだと、二分探索をしても問題箇所をうまく特定できません。 可能なら、「テストスクリプトを1つ実行するだけで判定」できるようにしたほうが良いです。このとき、テストスクリプトは、git リポジトリからチェックアウトした作業ツリーに対して実行できるようにします（例えばソースからのビルド処理もテストスクリプトに含めま
これはウェブページです｡
たいしたページではありません｡ あるのは言葉だけ｡ それをあなたは読んでいます｡ オシャレなデザインや､レスポンシブなレイアウト､魔法のようなスクリプトに私たちは魅了されてしまいました｡ でも､ウェブで一番強力な道具は､今も昔も言葉です｡ 私が書いた言葉を､あなたが読んでいる｡これこそ魔法です｡ 私はブリティッシュコロンビア州の小さな都市にいますが､あなたは別のどこかにいることでしょう｡私は2013年6月20日の早朝にこれを書きましたが､あなたは違う日時にこれを読んでいることでしょう｡私はノートパソコンでこれを書きましたが､あなたは携帯電話でこれを読んでいるかもしれないし､タブレット端末やデスクトップ端末で読んでいるかもしれません｡ 私とあなたがこうして繋がることができたのは､私が書いた言葉をあなたが読んでいるからです｡ウェブとはそういうものです｡場所や端末､タイムゾーンが違っても､このシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Linux】ngrepの導入 | cozzbox