プログラミング初心者は変数名やメソッド名を略さない方がいいよ、という話 - give IT a try
今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定
【問題提起】篠原嘉一氏に情報教育の講演を依頼する前に考えていただきたいこと ～ITエンジニアから見た、情報教育のあり方について～ - give IT a try
要約（僕の主張） 篠原嘉一氏の講演内容には、IT関連の知識がない人にはわかりづらいウソや間違い、極論が多く含まれているため、適切な情報教育だとは言いがたい。よって改善を強く希望する。 学校側は「生徒をネットのトラブルから守りたい」という思いが優先されるため、ITエンジニアよりも「情報の正しさ」がないがしろにされてしまうのかもしれない。だが、ITエンジニアとして、そして保護者として、学校は子どもたちに正しい情報を伝える努力をしてほしい。 我々ITエンジニアも情報教育を学校に丸投げするのではなく、正しい知識を伝えるために、主体的に情報教育に協力していく必要がある。 はじめに Image: http://www.mrf-ip.com/blog/0067/ 先日、息子が通っている中学校で開催された情報教育講演会に参加してきました。 これは中学校の全生徒と、任意参加の保護者で、情報教育（主にSNSや
入社試験や新人研修にピッタリ？（旧）国民の祝日.csvを変換するRubyプログラムを解説しました - give IT a try
お知らせ（と執筆のきっかけ） Qiitaに「【短命に終わった】国民の祝日.csvをパースして変換するRubyプログラムとコード解説動画」という記事を書きました。 「国民の祝日.csv」って何？という方はこちらをご覧ください。 このCSVファイル、プログラマにとっては非常に扱いづらい形式のため、あちこちから「ひどい」「最悪」と非難を受けていたかわいそうなCSVファイルです。 「休日が一覧できるCSV作ったよー」があんなにアホなのは、コードを書かない人が意思決定をするからと推測され、プログラム教育の必要性自体は感じるのだが、子供の方ではなく意思決定する年配の人の方が先に学ばないと、今後30年くらいの期間、ネ申Excel的な問題が続くと思われる。 pic.twitter.com/C6bfzuH95I— 未識@🐠🏭技術書典2 お-03 (@mishiki) 2017年2月22日 僕は直接仕事で
オブジェクト指向関連書籍リスト - give IT a try
自分はどれくらいオブジェクト指向について勉強してきたんだろう？というのを整理する意味で、これまでに読んできたオブジェクト指向関連の本をまとめてみます。 エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION) 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート出版社/メーカー: 翔泳社発売日: 2005/04/21メディア: 大型本購入: 10人 クリック: 635回この商品を含むブログ (143件) を見る企業向けシステムをオブジェクト指向で設計するときに有用な本です。ドメインロジックの3パターンは必ず押さえておきたいですね。 実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 作者: クレーグ・ラーマン,依田智夫,今野睦,依田光江出版社/メーカー: ピアソンエデュケーション発売日: 2007/11/12
O/Rマッピングツールに対する誤解をときたい -実装編 Part4- - give IT a try
Part3を読む ドメインモデルクラス それではここからドメインモデルを構成する注文クラス、注文明細クラス、書籍クラス、和書クラス、洋書クラスを説明していきます。 注文クラス(BookOrder.cs) using System; using System.Collections.Generic; using System.Text; namespace Junichi.Ito.NHibernateBookStore { // 1件の注文を表す [Serializable] public class BookOrder { private int id; private string customerName; private DateTime orderDate; private IList<BookOrderItem> items; // 注文ID public virtual int
ミュージシャンという呼称、プログラマという呼称 - give IT a try
プロのミュージシャン、音楽家、といっても色々なジャンルで色々な人がいる。 クラシック音楽のプロミュージシャン。 ロックバンド、パンクバンドのミュージシャン。 DJやダンス音楽のミュージシャン。 たぶん、クラシック音楽のミュージシャンはほとんどの人が音大を出ているはず。 だから専門の楽器だけじゃなくて、ピアノも一通り弾けるはずだし、楽譜が読めないわけはないし、音楽理論もばっちり理解している。 でもロックバンドのミュージシャンで音大出てる人はかなり少ないはず。 専門の楽器はできるけど、それと同時にピアノが弾ける、楽譜が読める、音楽理論を理解している、とは限らない。 楽器の演奏テクニックにしても千差万別で、超絶技巧ミュージシャンもいれば、アマチュアの方がうまいかも、って思うレベルのプロミュージシャンもいる。 DJやダンス音楽を作るミュージシャンの中には楽器すら弾けない人もいたりする。 ターンテー
Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(前編) - give IT a try
2011.12.31 追記 後編を書きました。こちらもあわせてどうぞ。 Excel列名変換問題で第２回社内プログラミングコンテストを開催してみた(後編) - give IT a try はじめに 先日、FizzBuzz問題を使って社内プログラミングコンテストを開きました。 このブログでも書いた通り、なかなか興味深い結果になりましたが、一方で反省点もいくつか見つかりました。 特に問題が解けなかった人が出てしまったのは痛い誤算だったので、今回はできるだけ最後まで解けるような配慮をしてみました。 ただし、問題自体はFizzBuzz問題よりもずっと難しくしてあります。 今回もちょっと長いエントリになっていますが、よろしければ最後までお付き合いくださいませ。 前回の反省点 詳しくはこちらのエントリに書きましたが、簡単にまとめると 言語の得意・不得意が結果に大きく影響した 抜き打ちで実施したことがその
FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
「動的型付言語は使い物にならない」か？ - give IT a try
はじめに Ruby対Scala, 動的型付言語は使い物にならないという興味深いWeb記事を読みました。 はじめに断っておきますが、おいらは別にRubyが嫌いなわけではないですし、「動的型付言語は使い物にならない」と思っているわけではありません。 そもそもRubyや動的型付言語での大規模開発経験がないので、良し悪しを正当に評価できません。 ましてやScalaなんて文法すらまともに知らないので、Scalaバンザイ！なんて言えるわけもありません。 ただ、おいら自身も「Rubyとかで開発したらこんな問題が起きるかも〜」と想像していたことが、結構そのまま書かれていたのが印象的でした。 これまで中規模〜大規模なシステムはJavaやC#で開発してきたので、IDEやコンパイラの支援はたっぷり受けてきました。 Ruby on Railsで開発してみたい！という憧れはありますが、IDEの入力補完やリファクタリ
おかしなおかしな目標管理 - give IT a try
組織のゴール うまく書けるかどうか分からないけど、前々からちょっと気になっていた話です。 うちの会社では半期ごとにゴールを設定します。 ゴールは通常、組織全体で定量化(数値化)できるものが設定されます。 ゴールを達成したかどうかで、特別ボーナスの額が変わることがあります。 この会社に入った時は前の会社のあいまいな(つまり基準がよく分からない)評価制度があまり好きではなかったので、「明確に評価できるのはいいね！」と感じていたのですが、最近その弊害をよく感じます。 一言でいうと、目的と手段が入れ替わってしまう時があるんです。 では具体例を・・・いや、ちょっとその前にコンテキストを説明します。 今から始まる話のコンテキスト おいらは社内SEである。 顧客はすべて社内の人間である。 開発も社内で行っている。外注はしていない。 社内開発なので当然、開発に関わる金銭のやりとりは発生しない。 期日につい
数値で測るコード品質 - give IT a try
プロフィールのところにも書いてあるのですが、おいらの目標は「美しく無駄のないシステムアーキテクチャを設計、構築すること」です。 なぜならシステムの保守性や拡張性って、アーキテクチャやコードの品質によって雲泥の差が出ることを、幾度となく痛感してきているからです。 しかし、どんなアーキテクチャやソースコードがキレイなのか、拡張性や保守性が高いのか、っていうのはなかなか客観的に判断しにくいのもたしか。 「俺のコードはあんたのより分かりやすい」 「そうですか？？」 「絶対そうやろ！？なんでわからんのや？？？」 みたいな議論が始まったらたぶん平行線になっちゃいますよね。 そこでツールを使って、コードの品質を定量的に測ってみることにしました。 今回使ったツール 今回使ったツールはこちらです。 SourceMonitor V3.5 http://sourceforge.net/projects/dupl
C#のコード品質を上げるフリーツール8本 - give IT a try
はじめに 読みにくいコードや複雑なコードをメンテナンスするのってイヤですよね。 コードの品質を上げる方法の一つにコードレビューがありますが、すべてのソースコードを人力でチェックしていくのは大変ですし、レビュアーのスキルや好みにも大きく依存してしまいます。 そういう場合はツールを使って自動化するのが有効です。 ツールを使えばあっという間に完了しますし、実施者のスキルや好みに左右されることもありません。 しかし、あまりお金がかかるツールだと、ちょっと気軽に導入しにくいです。 そこで今回はC#のコード品質向上に有効なフリーツールを紹介します。 実際のプロジェクトで使用したことがあるものばかりなので、どれも「使えるツール」だと思いますよ。 ところで、ツールを紹介する前にTipsと注意点を簡単に挙げておきましょう。 ツールを利用する際のTips 自分の書いたコードのみを対象とし、ツールが作成したコー
O/Rマッピングツールに対する誤解をときたい - give IT a try
2010.12.23 追記 本エントリの続編となる「実装編」のブログを書きました。 こちらも合わせて読んでみてください。 O/Rマッピングツールに対する誤解をときたい -実装編 Part1- - give IT a try 本文にコメントすると泥沼に巻き込まれそうなので、ここに書いておきます。。。 http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html なんかこのコラムのコメントを読んでいると、「O/Rマッピングツール(ORM)はSQLを書きたくない開発者のためのツールだ」と思われているような感じを受けます。 おいらはこれまでORMを使った開発プロジェクトに3回参加しました。 確かに最初のプロジェクトでは「SQLを書かなくてもいいんだよ」とリーダーから説明されたような記憶があります。 しかしその発想は大きな誤解です。 ORMを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
