そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか？ - きしだのはてな
「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。 第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。 コマンドラインでは慣れ親しめない サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。 「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？ 現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。 そして、まだプログラムの面白さを知りません。 コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。 それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。 javac
川o・-・）＜2nd life
Perl での print debug の方法の紹介がブーム(?)だったので、自分がよく行ってる Ruby での debug 方法7つについて書いてみます。 p ご存じの人も多い Kernel#p メソッド。これを使うとオブジェクトの内容を見やすい形で出力してくれます。 >> p ({:foobar => :baz}) {:foobar=>:baz}Object#inspect を使うと、p で出力するときと同じ文字列を String として取得できます。 >> puts ({:foobar => :baz}).inspect {:foobar=>:baz}初心者の頃この p での出力を使う方法がわからなくて困った記憶が…。 pp pp というライブラリを使うと、p より、より見やすい形式で出力してくれます。たとえば >> a = Array.new(10) { {:foobar => :
Safari拡張の作り方 - os0x.blog
Safari拡張をいくつか作って大体感覚は掴めたので、ざっくりと拡張の作成手順を解説してみます。 なお、Windows版で作業していますが、Macでもほとんど同じだと思います。 Safari拡張とは 最初に、Safari拡張とはなにか、について。Safari拡張はHTML/CSS/JavaScriptをベースに、ブラウザ側が用意したAPIを使ってブラウザを便利にするモジュールです。通常、JavaScriptだけではクロスドメインの問題など、実現できることに制限がありますが、その点を拡張用に用意されたAPIで補います。そのため、APIが用意されていない部分については対応できないという制限があります。しかし、開発のし易さ、ウェブとの親和性の高さからアイディア次第で便利で強力なツールとなるのがSafari拡張・Chrome拡張です。 なお、現状のAPIは暫定的なもので、ここで紹介するのもあくまで
GNU Screen のちょっと便利な使い方 - プログラミングは素晴らしい
今日はかなり珍しく技術的な話題を提供します。 要約 [困ったこと] １つの Screen で複数のサーバにたくさん telnet するとどの仮想端末で何をしていたか忘れる！ 選択が面倒！ [この記事を読むとできること] Screen のウィンドウタイトルにユーザ名、ホスト名、作業中のディレクトリを表示 どのサーバにどのウィンドウでログインしているかを確認しながらウィンドウ選択 知っている方もかなり多いのかもしれませんが、bash には PROMPT_COMMAND という環境変数があります。PROMPT_COMMAND を使うことで、PROMPT が表示される時に自動的に実行するコマンドを指定できます。 これにたとえば私の場合ですと、次のように設定しています。 PROMPT_COMMAND='echo -ne "\033]0;$(whoami)@$(hostname):$(pwd)\007
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Railsでデバッグをする７つの方法 - Hello, world! - s21g
