タグ

perlと考え方に関するwkbyshnbtkのブックマーク (6)

  • プラグマをストップさせよ! | taro-nishinoの日記 | スラド

    CPANを常日頃観察している方は、やたらとプラグマもどきが多いことにお気づきだと思います。これらは目的が多少違っていても、多くはベストプラクティスのためだと言ってもいいでしょう。 いいプログラマの素質にはいろいろな要素があります。当然頭が切れる、理解が速い、構想力に秀でている等いろいろあるでしょう。私が思うには、最低限必要なことがあります。つまり己を知っていることなんです。自分の弱点、短所、悪癖等を自覚していることです。その弱さを知っていれば、当然それをカバーするものはないかと探して、strict、warningsのコアプラグマはほぼ誰でも必須であることに気がつくはずです。自分が駄目だからそれらに頼らざるを得ないのです。後、使うべきプラグマは個人差があるでしょう。日人なら日語リテラルを書く機会が多いから、どうせ書くならUTF-8でやるのが面倒が無いのでutf8プラグマでしょう(これも極

    wkbyshnbtk
    wkbyshnbtk 2009/12/18
    「use strict」を書かないことが気持ち悪い。知っている人にすれば悪しき慣習だろうけど、初心者の目を考えれば書いてあったり書いてなかったりする方が、混乱の元になる気がする。
  • FUDを広げるのは誰の特にもならないと思うんだ。 - D-6 [相変わらず根無し]

    FUDを広げるのは誰の特にもならないと思うんだ。 以下、まぁ書き散らかしです。あんまり推敲してません。すまそ。ちなみに、下記記事に対するブクマはDISも多いけど、素直な反応もちらほらあるようで興味深い。 僕にとってのJavaは2001年に終わってますが・・・。同じ事何回も書かなくちゃいけない言語なんて死んだも同然ですよ。ライブラリもちらばってて何がどこにあるのかわかんないし。 って、書くのは簡単です。多分元記事をテンプレ化してほぼ同じ事をどの言語に対しても僕は書けます。 ただ、エンジニアという職種の人がそんなことしてるのはどうかなぁ、と。エンジニアの使命を問題を解くことです。何でつまづいたかとか、なにがむずかしかったとか、何ができなかったとかそういう事をちゃんと書いて欲しいなと思う。CPANのアップロードとかも状況に対しての認識もなく、「回数」という一面だけで判断をばっさりしてていいのでし

  • メソッドチェーンの話の続き - Charsbar::Note

    ぐだぐだ言う前に認定試験でも受けるつもりでMojoのコードを制限時間二時間くらいで通読してみれば自然と言いたいことがわかるようになるんじゃないかと思いつつ。 前回のサンプルの my $loader = Loader->new; my $book = $loader->load( 'Book' )->buildこのコード。 どのように書いてほしいかというと、 my $loader = Loader->new; $loader->load( 'Book' ); my $book = $loader->buildと書いてほしいです。 こう書けば、loadが何をしているのかが、コードから推測できます。buildが$loaderから呼ばれたことがコードを読んでわかります。 http://d.hatena.ne.jp/perlcodesample/20090219/1233929050 文脈にもよるけ

    メソッドチェーンの話の続き - Charsbar::Note
    wkbyshnbtk
    wkbyshnbtk 2009/02/07
    「みんな忙しいんだから、なるべく時間をかけずに読みたいんですよ。」
  • バグ見つけた→それってどんなテスト?もしくは、なんでMVCなんて使うの? - D-6 [相変わらず根無し]

    バグ見つけた→それってどんなテスト?もしくは、なんでMVCなんて使うの? 最近ソフトウェアエンジニアリングに置ける開発手法に関して考えている。 ぶっちゃけ言ってしまうと「やっぱりTDDっぽいのがいいな」というところに落ち着きつつあるのだが、厳密にTDDをしたほうがよい、と思ってるわけではない。TDDとかExtremeプログラミング、Agileプログラミングにしても理想はいいんだけど、原理主義っぽい使い方は現実にそぐわないと思ってるからだ。 前置きはこれくらいにしておいて・・・重要だと思うのは以下の点: 開発サイクルに自動テストツールを組み込むエンジニアによるバグ/不具合発見時には「動かない」は許可しない。必ず再現コードを提出してもらうテストを自動テストツールを組み込む(=次回リリース前にはかならずテストを実行できる状態にする)テストが通るまで修正を続けるという開発サイクルを取るべきだ、とい

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • tokuhirom blog

    Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at

  • 1