第4回 コードの分割―その1 見通しの良いコードは適切な分割から | gihyo.jp
本連載が書籍化されました。 『良いコードを書く技術 ─ 読みやすく保守しやすいプログラミング作法』 縣俊貴 著／A5判・240ページ 価格2394円（本体2280円） ISBN 978-4-7741-4596-9 今回のテーマはコードの分割 5,000行を超えるメソッド……。そんなプログラムのメンテナンスを頼まれて、途方に暮れたことはありませんか[1]？ 逆にメソッドは細かく分割されているんだけど、細か過ぎて流れがさっぱりわからないコードを見たことはありませんか？ 本連載のテーマは「良いコード」です。良いコードは可読性が高く、メンテナンス性にも優れています。そのためには、適切な単位でのコード分割が必要になります。今回は、そんなコード分割のポイントについて解説します。 なぜコードを分割するのか コードを分割すると何がうれしいのでしょうか。たとえば次のようなメリットがあります。 可読性の向上
第23回 Windows Live フォト ギャラリー ── はてなフォトライフ プラグインの作成 Part II | gihyo.jp
前回に続いてPhoto Gallery Publishing Plug-in Platformについてです。サンプルとしてLiveフォト ギャラリーなどで使える はてなフォトライフへ写真をアップロードするプラグインを作ります。今回は実際にプラグインのコードの記述しアップロードができるところまで作成します。 プラグインの処理 コードを書く前に、プラグインが行う処理を確認しておきましょう。Liveアプリケーション上でひとつ以上の動画像を選択した状態で、アップロードメニュー[1]からアップロード先を選択すると、対象のプラグインの処理が実行されます。アップロード先の選択からアップロード完了までに、Liveアプリケーションとプラグインとの間では複数回のやり取りをしています。あるアップロードに対して行われるこの一連のやり取りを、本記事中ではセッションと記載しています。 1. 設定ウィンドウの表示 プラ
SoulHack #8 「厳密さ」「客観性」以外にもうひとつ支点を持とう | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第18回 ［他責］から［自責］の議論へ | gihyo.jp
こんにちは。グラフィックファシリテーターのやまざきゆにこです。ここ最近、私のグラフィックの中にも、「不況」「先が見えない」「業績悪化」「人員削減」といった言葉から描く絵が本当に増えました。 そこで今回は（前回の予告では引き続き［リーダーシップ］を発揮する人の絵の世界の楽しみ方＝“ポジティブな” 議論の引っ張り方を紹介するつもりでしたが予定変更！）、じつは世の中の会議の大多数を占めているかもしれない“ネガティブな”空気と発言が飛び交う議論の現場で、それを絵にしたときに起きる変化を紹介します。 ここでちょっとこんな会議室を想像してみてください。「社会のせい」「会社のせい」「上司のせい」。［リーダーシップ］とは真逆の立場から、他人のせい、他の出来事のせいにした［他責な発言］が、議論の合間合間に聞こえてくる会議室です。 「そうはいっても、こんな景気じゃどうしようも
第7回 保護期間延長論争の陰にある現実 | gihyo.jp
はじめに～除夜の鐘とともに消えゆくもの もうすぐ迎える年の暮れ。除夜の鐘を聞きながら、まさに終わらんとする“ゆく年”のことをあれこれと思い出して毎年しんみりとされている方もいらっしゃることでしょう。 そして、除夜の鐘とともに終わるものがもう一つ。 ……そう、「著作権の保護期間」です。 著作権法には、著作権がいつまで続くのか、ということを定めた規定があり、著作物の種類によって何パターンかの規定が設けられているのですが、いずれも、以下のような規定になっています。 基準日が属する年の「翌年」から起算して、「Ｘ年を経過するまでの間」（著作権が）存続する。 そして、基準日が属する年の翌年の年末に１年経過、さらにその翌年の年末に２年経過…と続いていくことになり、Ｘ年が経過した年の年末に、著作権の保護期間が満了する、ということになるのです。 通常の著作物の場合、「著作者の死後50年を経過する
第2回 なぜ、人は欠陥を見逃すのか？ | gihyo.jp
「テストを実施すると必ずバグを見つけることができますか？」と聞かれると、筆者の回答は“No”です。テストによるバグを検出は、実施した結果が期待値と異なる事象のときに発見されます。テストにおいての期待値とは、テスト対象が動作した「正しい結果」です。 テストケースを見ると期待値の設計はされていますが、ほとんどの場合は期待値以外の結果が記述されることはありません。テストの実施においてテストケースに記述されている期待値以外の結果は、テスト担当者の判断に委ねられます。この期待値がバグを発見する重要な鍵を握っています。 あるプロジェクトの情景 ある製品のテストを担当したTさんとテストマネージャのM氏の会話を聞いてみましょう。 M氏：「先週のテストの実施結果を報告してくれ。」 Tさん：「テストの計画通りにテストケースを実施しましたが、不具合の検出率が低いようです。」 M氏：「それは、テスト対象の品質
第16回 アイデアを実践してブラッシュアップ | gihyo.jp
アイデアとプロトタイピング アイデア流行りの今日この頃です。 ビジネスでも研究でも、アイデアの出し方をどうするか、というのが大きなテーマになっているようです。 筆者の場合、これまでの人生をふりかえってみると、アイデアはいつでもあふれるように出てくるほうなので、アイデアの出し方なんてのには、最近とんと興味がなくなってしまいました。 たとえばソフトウェアのアイデアなんてのは、ほとんど尽きることなく出てくるわけです。いちいちなんかのかたちに入れて展開するようなまどろっこしいことをする必要もないくらいで、もういくらでもだらだらと出てくる。 このところ、自分でもプログラムを作るようになったのですが、だいたい毎日使うものの大半は自作という状況になりつつあります。このあいだ、『PilePaperFile』プロジェクトでのソフトウェア一覧をご紹介させていただいたのですが、その後もテキストエディタ/ビュー
第17回 質感をどう扱うか | gihyo.jp
アイコンなんてまどろっこしい 最近とみにアイコンをダブルクリックしてウィンドウに開く、という手続きがめんどうくさくてたまらないのです。アイコンを探した上に、わざわざダブルクリックするだなんて。考えるだにぞっとしない話です。めんどうじゃありませんか？ 考えてみると、GUIを使い始めた最初から、アイコンを選んでダブルクリックなんてことは、ばからしくてやってられんぞと思ったのです。CUIを礼賛しているわけではなくて、中途半端すぎるGUIの事情に、ついていけないものを感じていました。 なんだよアイコンって、って考えます。なぜアイコンをクリックしてウィンドウを開くなんて作業が必要なんでしょう。 アプリケーション中心の時代なら、アイコンがスイッチの代替になっていたことはわからないではないのです。OSは数種類、アプリケーションは数十種類程度。そのくらいの中程度の規模のオブジェクトを区別するのにはアイコン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
