雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
【JS完全に理解した】JavaScript PrimerとプログラミングTypeScriptとレガシーフロントエンド安全改善ガイドを読んでみた - give IT a try
はじめに 僕は仕事でRuby on Railsを使ってWebアプリケーションを開発しているので、JavaScriptはそれなりに使えます。 ですが、サーバーサイドで使っているRubyに比べると、JavaScriptの習熟度はそれほど高くありません。 とくに、文法が一気にブラッシュアップされたES2015（ES6）以降の知識は「なんとなく把握はしているが、あくまでなんとなく」といった感じです。 また、最近よく名前を聞くようになったTypeScriptも「名前は知っているが使ったことはない」というのが現状です。 というわけで、「そろそろちゃんと勉強しておかないと」という思いから、以下の本を購入してみました。 JavaScript Primer 迷わないための入門書 (アスキードワンゴ) 作者:azu,Suguru Inatomi発売日: 2020/06/10メディア: Kindle版プログラミ
【問題提起】篠原嘉一氏に情報教育の講演を依頼する前に考えていただきたいこと ～ITエンジニアから見た、情報教育のあり方について～ - give IT a try
要約（僕の主張） 篠原嘉一氏の講演内容には、IT関連の知識がない人にはわかりづらいウソや間違い、極論が多く含まれているため、適切な情報教育だとは言いがたい。よって改善を強く希望する。 学校側は「生徒をネットのトラブルから守りたい」という思いが優先されるため、ITエンジニアよりも「情報の正しさ」がないがしろにされてしまうのかもしれない。だが、ITエンジニアとして、そして保護者として、学校は子どもたちに正しい情報を伝える努力をしてほしい。 我々ITエンジニアも情報教育を学校に丸投げするのではなく、正しい知識を伝えるために、主体的に情報教育に協力していく必要がある。 はじめに Image: http://www.mrf-ip.com/blog/0067/ 先日、息子が通っている中学校で開催された情報教育講演会に参加してきました。 これは中学校の全生徒と、任意参加の保護者で、情報教育（主にSNSや
ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア - give IT a try
はじめに 「プロを目指す人のためのRuby入門」を出版して以来、本で学んだ内容をブログに載せてくれている方をよく見かけます。 それ自体は著者として大変嬉しいのですが、たまに「ん？これはちょっと・・・」と思うようなブログ記事を見かけるときがあります。 具体的にいうと、本の内容を丸写ししているだけのブログ記事です。 このエントリでは本の丸写しがなぜいけないのか、かわりにどういうブログを書けばいいのか、ということについて書いていきます。 本の内容を丸写ししているブログの例 本の内容を丸写しをしているブログというのは文字通り「丸写し」しているブログです。 具体的なイメージを共有するために「こんな感じ」という例を載せておきます（特定の誰かのブログを意図しているわけではありません）。 タイトル「第2章 2.2.3 文の区切り」 「プロを目指す人のためのRuby入門」を読んでいるので、勉強した内容をメモ
【洋書Q＆A】どうやって洋書を読んでるの？どれくらい時間がかかるの？という質問に答えてみた - give IT a try
はじめに 昨日、「こんな洋書を読んだよー」っていうブログを書いたら、Twitterでこんな質問をもらいました。 どのように洋書を読んでいますか？ 読み切るのにどれくらいかかりましたか？ 洋書を読むと和書より頭に残らないことが多いので、ぜひ参考にしたいです。— urimaro (@urimaro) 2017年9月11日 どれだけ役に立つかわかりませんが、140文字で返信するには短すぎるのでこのブログに返信を書いてみます。 備考：「洋書」の定義 ここでいう「洋書」とは、「英語で書かれたプログラマ向けの技術書」のことを指します。 たしかに洋書の内容は頭に残りにくい 質問主のurimaroさんは「洋書を読むと和書より頭に残らないことが多い」とおっしゃっていますが、その感覚は僕もわかります。 英語はそこそこ得意とはいえ、母国語と同じレベルで英語を読めるほど僕の英語スキルは高くないです。 わかりにくい
WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた - give IT a try
はじめに Twitterを見てたら、気になる雑誌の特集を見つけました。 WEB+DB PRESS Vol.99の「Rubyで学ぶ！良いコードって何だろう？」という特集記事です。 WEB+DB PRESS Vol.99 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編出版社/メーカー: 技術評論社発売日: 2017/06/24メディア: 大型本この商品を含むブログを見るRuby大好き！きれいなコード大好き！！な僕にとっては、この特集は読まずにはいられません！ 早速買って読んでみました。 お～、なるほど、たしかにいいことが書いてある！ うんうん、そうそう・・・あれ？この
新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try
はじめに：「僕にもそんな頃があった」 先日、西脇.rb＆神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者（＝僕）が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか？」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも
デザイナさん直伝のCSSテクニックが満載！「RubyistのためのCSS勉強会」を開催しました - give IT a try
はじめに さる2016年1月9日、西脇.rb＆神戸.rbの合同勉強会として「RubyistのためのCSS勉強会」を開催しました。 主催者の僕自身が「参加して良かった！」と思えるぐらい有益な情報がたくさん詰まった勉強会になったので、今回のエントリではこの勉強会の内容を紹介します。 もくじ ちょっと長いので、先に目次を載せておきます。 はじめに もくじ 講師は合同会社フィヨルドの町田さん！ この勉強会で講義してもらったテーマ 座学編 Railsの app/assets/stylesheets 内のディレクトリ構成例 最近注目を集めているAtomic Designについて 3種類のリセット系CSSの特徴について 変更に強いマークアップのルールについて プログラマとデザイナの協業について ハンズオン編 進め方の具体例 1問目：グローバルナビゲーションの作成 2問目：アラート画面の作成 3問目：記事
テストコードは「書けるようになる」ものじゃなく「書きたい」と思うもの（ポエム） - give IT a try
「Railsチュートリアルを見ながらテストコードを写経しても、自分でテストコードが書ける気がしない」という新人さんのつぶやきに思わず反応した僕の、斜め上から目線の感想を書きなぐっておきます。 テストコードは「書けるようになる・ならない」の問題じゃなくて、「テストコードって便利！テストコードって大事！！」って思えるかどうかじゃないかな～と思ってる。 僕みたいなおっちゃんが働き始めた頃は「テスト = 手で動かして目で確認してスクリーンショットを撮ってエクセルに貼り付ける」という肉体労働だった。 コードを変更したら、もう一回「手で動かして目で確認してスクリーンショットを撮ってエクセルに貼り付ける」を繰り返さなきゃいけなかった。 ところが、テストコードを書けば「自動化できる！何回でも繰り返せる！すぐ終わる！自動テストすげー！！」ってなって、「こりゃテストコード書けた方が100倍いいわ」っていうモチ
2011-02-18 - ITは芸術だ レガシープログラマかどうかを判断する10項目
※2011.3.30追記 11個目の判断項目を追加しました。 また、「昔はね...」の補足説明を各項目に追加しました。 レガシープログラマ = モダンな言語のおいしい機能をうまく使いこなせていないプログラマ おいらは時々社内システムのコードレビューなんかをやっているのですが、「なんかちょっと前時代的だな〜」とか「ちょっと修正したらC言語でもコンパイルできそうだな〜」って思うことがよくあります。 おいらがレビューする言語は主にC#です。C#やJavaのような比較的モダンな言語のおいしい機能をうまく使いこなせていないプログラマを、ここでは「レガシープログラマ」と呼ぶことにします*1。 そこで、おいらがこれまでに見てきたコードの中から「これはレガシープログラマっぽい」と思った典型的な症例を10個11個挙げてみます。 レガシープログラマの判断項目 使われるローカル変数をすべてメソッドの最初に宣言す
プログラマ歴12年の僕が選んだ「10年経っても役立つ技術書17選」 - give IT a try
はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「この本で学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。（紛らわしくてご
サンプルストーリーで理解するDNSの設定方法と周辺知識(改) - give IT a try
2013.4.20 追記 CNAMEの間違った使い方を書いていたので、「3. DNSレコードでCNAMEやAレコードを設定する」の項を一部修正しました。 というか、実際に痛い目に遭いました・・・(T T)。 詳しくは本文にて。 2014.10.10 追記 結局Herokuでは「Aレコード + ネイキッドドメイン」の設定を使うことはできなくなりました。 ネイキッドドメインを使う場合は、かわりに「CNAME flattening」という仕組みを使います。 詳しくは以下の記事で説明しているので、参考にしてみてください。 妻のパン屋のwebサイトをいろいろ更新した話 ～Rails 4アップデートとかサイトの高速化とか～ - give IT a try はじめに みなさん、DNS、ネームサーバー(NS)、Aレコード、CNAME、と言われて、「ああ、アレね」ってすぐに頭の中にイメージが浮かびますか？
「現場を変える？会社を変わる？」できることと、できないこと - give IT a try
はじめに 先日のDevLOVE関西でもちょこっと絡ませてもらった@jyukutyoさんのブログがなかなか面白いと感じました。 「現場を変える・会社を変わる・SIから抜ける」何を選ぶのか - Fight the Future 書いてあることはほぼ同意です。 それに補足する形で僕の経験や考えをいくつか紹介してみます。 「信念がコンフリクトしている人」を変えるのはムリ まず、僕の経験上、一人の人間が現場を変えることは非常に難しいです。 一番困難、というか絶対ムリだと思ったのは「信念がコンフリクトしている人」を変えることです。 特にそれが上司だったり、部長クラスの人だと、転職する方が有力な選択肢になると思います。 例えば、アジャイルな開発スタイルを現場に導入したいと思っていても、「アジャイル開発なんて理想論だ。そんなお遊びで仕事が回るのは景気のいい会社だけだ。普通の会社は事前に仕様書を書いて開発を
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
プログラマのためのKindle導入ガイド - give IT a try
別のエントリでも書きましたが、欲しい洋書をいつでもさくっと手に入れたかったのと、本棚にあまり本を増やしたくなかったので、Kindle DXを手に入れました。 今回は電子書籍に興味を持っている日本人プログラマ向けに、僕がKindleをしばらく使ってみた感想を書いてみたいと思います。 左がKindle、右がiPad。開いている本はどちらも同じ 良いところ 手のひらの上の本棚 iPhoneを手に入れたときの感想は「手のひらの上のパソコン」でしたが、Kindleの場合は「手のひらの上の本棚」という感じです。 本棚まで歩いて本を取ってこなくても、ソファに座りながらすいすいと別の本に切り替えられます。 外にだって持ち運べます。本棚を。 これは今までになかった感覚です。 iPadより読みやすい 前からe-inkディスプレイの質感は知っていましたが、やはりiPad等のバックライト付き液晶画面に比べると読み
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
