タグ

いまさらながらとprogrammingに関するvanbraamのブックマーク (14)

  • ジョエル・テスト

    こんにちは。 タオソフトウエアの杉山です。 今回は炊飯について取り上げます! 電気からガスへ 慣れると戻れない できるだけ大きな家電を買わずにすますため、 島へ移住の話【家電品 – 使わなくなった電子レンジ– 】 で触れた通り、もともと電子レンジで炊飯していました。これが水や米が変わっても使えそうな炊飯釜などを調べている中で、炊飯にガスを使うようになりました。 子どもの頃の実家のご飯も電気釜で、人生のほとんどは電気で炊飯されたご飯をべてきました。ガスで炊飯するのは小学生の授業での経験ぐらいしかなかったですが、普段の生活で電気からガスへ変えてみたら意外と早く時間短縮になるので驚いています。 ガス代は少し上がりますが急上昇するようなことは無く、電気代が下がったので安上がりになりました。大島はプロパンガスのため、都市ガスだともっと安くなるかなと感じています。 昔のガス釜の炊飯器は壊れず美味しい

  • どうしてプログラマに・・・プログラムが書けないのか?

    Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が「Fizz

  • 実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ

    わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他

    実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ
    vanbraam
    vanbraam 2020/03/22
    via b:id:entry:4683024661571180578; 自分がはてブ使い始める前の記事だった様なので,今更ながらブクマ
  • 「staticおじさん」はなぜ自信満々なのか

    「staticおじさん」という言葉をご存じでしょうか。「static」というのは、Javaのstaticメソッドのことです。Javaでメソッドを呼び出すときにはクラスからインスタンスを生成してインスタンスのメソッドを呼び出すのが普通です。一方、staticメソッドはインスタンスを生成しなくてもクラスから直接呼び出せます。このため、オブジェクト指向プログラミングを理解していない古いタイプのプログラマは、Javaでもstaticメソッドを多用します。これを揶揄して「staticおじさん」と呼ぶのです。 staticおじさんについては、わかりやすく解説したブログエントリが有名です(参考リンク)。実際のシステム開発の現場でstaticおじさんに苦しめられている様子をまとめたページもあります(参考リンク)。 なお、Javaのstaticメソッドを多用する人に限らず、古い感覚にとらわれて周囲に迷惑をま

    「staticおじさん」はなぜ自信満々なのか
    vanbraam
    vanbraam 2020/03/22
    "staticおじさん"という呼称が生まれる発端となったのはこれ b:id:entry:20987590 (2010年の記事). 読めばわかるが「インスタンスを作る奴は頭悪い」と主張する様な酷い記事で,とても擁護できる代物ではない
  • xUTP Magazine - xUnitester Hotlinks: 第一回 和田卓人さん(下)

    xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。 栄えある第一回のインタビューは、日の TDD 伝道師、和田卓人さんにお願いしました。 こちらは後編となります。前編はこちら 和田卓人(わだたくと) タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP(eXtreme Programming)を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い(完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念)」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めよう

    vanbraam
    vanbraam 2018/03/22
    "Kent Beck がやっていたのは、抽象的な話で、「テストの向き」という概念は基本的に無かった","Steve Freeman と Nat Pryce は、モックオブジェクトを使うことで(略)要求や対象の世界を自分たちが理解していく上での設計ツールに"
  • 開発会社におけるエンジニアスキル向上施策の過去と今|TechRacho by BPS株式会社

    morimorihoge@Webチーム部長です。ご無沙汰しています。ゴ魔乙はギルド戦が実装されてから拘束時間が多くなり、そろそろ見切りを付けようかとも思い始めた今日この頃です。とりあえずポケモンGOは始めました。 しばらくTechRachoに投稿できていなかったわけですが、別に遊んでいたわけではなく、むしろ開発会社としての業の方で一杯一杯でなかなか記事を書く気合を充填できていませんでした。 今回は、最近社内で(というか主に僕のいるWebチームで)取り組んでいる社内エンジニアのスキルアップへの取り組みについて、これまでの経過と近況を書こうと思います。長いです。 ※今年に入ってから弊社は事業拡大を目指して採用活動を強化しており、現在進行形でメンバの増強を行っています。新しい人が入ってくる中で古くからの人もいるという当たり前のことではありますが、過去にこういう取り組みをしていたんだよという記録

    開発会社におけるエンジニアスキル向上施策の過去と今|TechRacho by BPS株式会社
    vanbraam
    vanbraam 2018/03/11
    スキルマップのペーパー試験,自分だと正解できなさそう.細かい事は覚えてなくてWeb検索頼りなので<覚えてる方が作業が速いのはわかってるんで,言い訳だけど
  • コメントの9割は無駄!~アンチプラクティスから学ぶ洗練されたコメントの書き方~ #code #コード|CodeIQ MAGAZINE

    コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 (CodeIQ中の人) コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする

    コメントの9割は無駄!~アンチプラクティスから学ぶ洗練されたコメントの書き方~ #code #コード|CodeIQ MAGAZINE
    vanbraam
    vanbraam 2018/03/01
    9割無駄かどうかは知らないが,自分のコメントの書き方はこの記事に近い;しかし5年前はこんなにコメント肯定派多かったのか>ブコメ.今だとどうなるんだろう?
  • Android案件を見積もる場合に考えておくことリスト - Qiita

    アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様(必要機能リスト)がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル(全端末遅延1秒以内必須、とか)を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ

    Android案件を見積もる場合に考えておくことリスト - Qiita
    vanbraam
    vanbraam 2018/02/10
    via b:id:entry:357508495;"「簡単かを決めるのは開発者であり、企画者や営業ではない」と言い切ってしまおう"<完全同意
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
    vanbraam
    vanbraam 2018/01/29
    表層だけを撫で回すか本質を追うか.コピペグラマーやExcel FAQは表層を撫でているだけなので少しでもパターンが変わると対処できない.本質を追うのは一見遠回りだが応用が利くので後々まで使える力がついて実は効率的
  • むかしむかし、あるところにチェック例外という機能があったそうな | システムアーキテクトのごった煮

    ってことで、例外のお話です。 どうも僕の知っている限りでは、チェック例外という言語機能をもっているのはJavaだけみたいです。 僕個人としては、すばらしい機能なんですが。 Javaで最初にチェック例外を学んだ時、「そうそう、これこれ、これが欲しかったのよ!」 って思ったあの頃の想いは今も色あせていません。 「ずっと好きだったんだぜ~♪」って斉藤和義の曲を口ずさむくらいに、今もチェック例外を愛しています。 しかし、このチェック例外、他の言語からdisられまくって、最近の言語には取り込まれないという悲しいお話になっています。 過去に様々な議論があった中で、結論としてチェック例外は役に立たないってことになったらしいです。 経緯は知らんがね、そんなん。僕には役立ってるんだから。 ってことで、僕の立場から見た、チェック例外についての考察と扱いを書きます。 反論したい方、自重をお願いします。 だって、

    むかしむかし、あるところにチェック例外という機能があったそうな | システムアーキテクトのごった煮
    vanbraam
    vanbraam 2017/09/24
    例外=大域脱出の手段,検査例外=例外も戻り値の一種なので静的に型を把握,という認識.利点はある&コストも(IDEを使えば)大きいと思わないので,忌避される理由に納得感が余りない;Goの様に大域脱出を否定する方が理解できる
  • https://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf

  • 60%の人間はプログラミングの素質がない

    Coding Horror: Please Don't Learn to Code Please Understand Learning to Code Coding Horrorで有名なJeff Atwordが、ある州知事が今年の目標としてプログラミングを習得することを挙げていることに対し、そもそも税金を払う我々市民は、政治家にはプログラミング習得以上に重要な、政治家にしかできない問題の解決を望む、よってプログラミングを学ぶのをやめてくれという記事を書いた。これに対して、反論が多数上がっているが、Jeffも読んでいるある論文をあげて、この議論の参加するためには、必ずこの論文を知っておくべきであると書いた人がいる。この論文は有名で、非常に興味深いので、全プログラマーが読むべきである。 ふたこぶラクダという名前で知られている有名な論文がある。この論文では、60%の人間にプログラミングの素質が

  • cron の意外な落とし穴! - もろず blog

    システムを運用していく上で cron を使う場面はよくありますよね 処理をスケジュール実行したい時にとても便利です そんな cron ですが、最近仕事で作業しているときに ntpdate でシステム時刻を変更した後に cron で設定した時刻になってもジョブが実行されないという問題が見つかりました 全てのジョブが実行されていないわけではなく一部のジョブは実行されているようでした また、時刻を変更した後に crond を再起動すれば全てのジョブが正常に実行されるようになりました 幸い、実運用ではなくてシステムテスト中に見つかった問題なのでまだよかったんですが、運用している環境で同じ問題が起きたら相当マズイですよね そもそも ntp の時刻同期でシステム時刻が修正された場合にも同じ問題が起きそうじゃないですか? ググっても同じような事象は見つからず、社内のメンバーにも聞いてみても cron

    cron の意外な落とし穴! - もろず blog
    vanbraam
    vanbraam 2015/03/18
    時刻をベースに動作する系の時刻を変更したら何らかの影響が出るのは当然予期すべきか;ただ停止→時刻変更→起動の手順でも,停止〜起動間にcron実行時刻が過ぎてしまうと問題ありそう
  • Revenge of the Types: 型の復讐 - Qiita

    稿は Python に型アノテーションを追加するという提案が行われたときに起こった Python コミュニティの議論の後、2014年8月24日 (日) に Armin Ronacher (@mitsuhiko) 氏によって書かれた記事の翻訳です。 Revenge of the Types Revenge of the Types by Armin Ronacher : Python (REDDIT) Revenge of the Types | Hacker News Python 3.5 で導入を検討している型アノテーションについて興味がある方は以下を参考にしてください。 mypy で静的型付け Python プログラミング 私自身、型システムや他言語に明るくないため、一部未訳の部分があったり、勘違いや誤訳もあると思います。そういった誤りを見つけたら編集リクエストを送ってもらえると助か

    Revenge of the Types: 型の復讐 - Qiita
    vanbraam
    vanbraam 2015/01/14
    なるほど.明示的な型が悪いのではなく,Pythonの型の意味論に(主に実装の都合に由来する)破綻が一部存在するので,明示的な型を導入するのは適切ではないという主張か
  • 1