タグ

ブックマーク / blog.jnito.com (5)

  • 雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try

    (この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました) 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする&機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな

    雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
    tpircs
    tpircs 2023/02/17
    テストファーストってプログラミング手法/設計手法の一つと思っており、テストファーストでやったとしても品質を高めるためのテストは別にやったほうがいいと思ってる。
  • Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try

    はじめに 先日、Rubyプログラマが職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は当にひどかった 今年は誰かな〜? → えっ、僕!? 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る(一人で解決しようとしない) リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策(設定の変更等)は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない&時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た

    Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try
    tpircs
    tpircs 2019/07/29
    ゲームのボイスチャットに危険性を感じるのはいいけど、そこにスプラの画像を持ってくるのは不適切ではなかろうか。
  • プログラマの僕が東京ではなく田舎に住む理由 #ruraladvent - give IT a try

    はじめに このエントリは「地方在住ITエンジニア・アドベントカレンダー 2015」の1日目の記事です。 地方在住ITエンジニア(元・地方在住も可) Advent Calendar 2015 - Adventar このアドベントカレンダーは「地方と仕事」をテーマに、有志のITエンジニアが自分の思うところを書き綴っていくアドベントカレンダーです。 トップバッターとして、僕も「プログラマの僕が東京ではなく田舎に住む理由」というタイトルで何か書いてみようと思います。 あなた誰?どこに住んでて何してるの? 僕は伊藤淳一と言います。 今は兵庫県西脇市っていうところに住んでます。 西脇市はこんなところにあります。 都会 or 田舎で答えるならズバリ「田舎」でしょう。 とはいえ、「超」が付くほどの田舎ではないので、日常生活には全く不自由しません。 今はソニックガーデンという会社でRubyプログラマをやって

    プログラマの僕が東京ではなく田舎に住む理由 #ruraladvent - give IT a try
    tpircs
    tpircs 2015/12/01
    リモートでそれなりの収入を得ることの出来るのに必要とされるスキルって相当高いと思っている。一般化はまだまだまだまだ先な印象。
  • ソフトウェア開発プロセス残酷物語 - give IT a try

    昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや人が直接手を動かすことはありませ

    tpircs
    tpircs 2012/08/27
    各プロジェクトに1人は開発プロセスを考えられる人材が必要、ってことかな。1人だと辛いから2人以上欲しいところだけど。新人教育の頃からそういうスタンスでやれば何人かは育ったりするのかなぁ・・・。
  • FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try

    はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに!? ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第1

    FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
    tpircs
    tpircs 2011/10/08
    自分含めて新人・若手5人選んでボーリングスコア計算のプログラムを書かせてみたら普通に書けた。マシな状況かもしれない。
  • 1