ソフトウェアに関する英語でよくあるミス | quipped
ソフトウェアエンジニアの仕事はいいソフトウェアを書くことなので、別に英語のミスなんか二次的な問題なのだが、Twitterやメーリングリストで、日本人（と思われる）ソフトウェアエンジニアがよくするミスについて、メモしておこうと思う。何かの役に立ったら幸いだ。反響があれば、あとからここに足していくかもしれない。 software/middleware/hardwareは常に単数:softwares/middlewares/hardwaresとはまず言わない。どうしても数えたい時は"a piece/pieces of software"とするのが妥当。 codeも基本的に数えられない:"I wrote codes"とか"I can't deploy codes"とかいう表現を散見するが、これも間違い。ただcodeに関しては、暗号という意味もあり、こちらは数えられます。"Secret codes"
staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい
死の行進から生還せよ！ 皆のデスマーチ対処法：わたしの愛するエンジニアライフ：エンジニアライフ
本音が語れるエンジニア参加型メディア「＠IT自分戦略研究所 エンジニアライフ」。日々、ITエンジニアの「生の声」を公開している。 ここでは、編集部の独断と偏愛によって選んだコラムをテーマ別に紹介していく。今回のテーマは「デスマーチ」。デスマーチの体験談やそこから得た教訓、デスマーチを避ける方法などを紹介する。 無茶ぶりにも程がある「デスマーチ対処法」 まずは、デスマーチの体験談から、デスマーチを生き延びる教訓を学ぼう。 『ソフトウェア開発者あがりの品質保証人の奮闘記録』の虚人氏は、世にも不思議な「デスマーチ対処方法」を教えてくれた。 「バグだらけのプログラムを、なんとか出荷できる状態にする方法を教える」。プロジェクトマネージャはこう切り出した。マネージャの方針は、下記のとおりである。 その1 「休まず働け」 その2 「頭は使うな、身体を動かせ、気合を入れろ！」 その3 「バグは絶対に作るな
Java変態文法最速マスター - プログラマーの脳みそ
Java基礎文法最速マスター - いろいろ解析日記をリスペクト。 Javaの変態文法・技法一覧です。Javaの基礎をある程度知っている人はこれを読めばJavaの変態をマスターしてJavaを書くことができるようになっています。簡易リファレンスとしても利用できると思いますので、これは足りないと思うものがあれば教えてください。 1.基礎 エンクロージング型内部classの作成 外部classのインスタンスに紐付くインスタンスを生成します。外部クラスのインスタンス - 内部クラスのインスタンス間に、クラス - インスタンスのような関係を持たせることができます。 public class Outer { public class Inner { } } というようなクラスを作った場合、 Outer o = new Outer(); Inner i = o.new Inner(); となります。new
Webアプリ脆弱性オタがふつーのSEの彼女に脆弱性世界を軽く紹介(ry
まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、 「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、 その上で全く知らない脆弱性の世界とはなんなのか、ちょっとだけ好奇心持ってる」 ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために 説明するべき10パターンを選んでみたいのだけれど。 （要は「脱オタクファッションガイド」の正反対版だな。彼女に脆弱性を布教するのではなく 相互のコミュニケーションの入口として） あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。 できれば、秋葉原とか筑波とかから突っ込みがはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。 あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。 プログラム言語オタがCOBOLは
オブジェクト指向っぽい話が分かるかもしれないJavaScript講座 その1 | Takazudo Clipping*
自分はスーパーJavaScripterでこんなすげーのが5行で書けちゃう。やばいだろ！とかいうのでは全然無いですが、オブジェクト指向っぽい話が最近分かってきたつもりで、それでやっときゃ問題無いってことを思い始めているので、なんかそんな話を書いていきます。 こんな短く書くテクニックがあるぜ！ var hoge = hage ? huga : hoga; とか書けちゃうんだぜ！とかより、長くていいから分かりやすく拡張しやすいようにするにはどうするのかとか、そういう話ができればなーと思います。内容的には全くもって新しくも何とも無いですが。jQuery使ってやる前提です。 まんじゅう製造スクリプト 今日はまんじゅうを5個作ります。なんと、まんじゅうは、クリックすると隠れます。 まんじゅうサンプル var Manju = function(){ this.elem; this.hidden = fa
きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス
Firebugで作るGreasemonkeyスクリプト〜入門と実践(From Kanasan.JS) | Blog.37to.net
最終更新日 Wed, 29 Apr 2009 01:29:41 +0900 最後のコメント Sun, 25 Jan 2015 19:08:17 +0900 最後のトラックバック Wed, 11 Mar 2009 15:49:00 +0900 ブックマーク 遅くなりましたが、先日に開催された、Kanasan.JS Greasemonkey チュートリアル読書会のレポートです。 せっかくなので、読書会の内容を元にGreasemonkeyスクリプト作成の「入門」「実践」「Tips」の3本立てでまとめてみたいと思います。 今回の開催はKanasan.JSの主催をkanasanから引き継いで、初めての開催ということもあり、とても緊張しました。 途中までは無難に進んでいたのですが、後半は段取り不足が出てきた感じでした。参加者の方々にはご迷惑をお掛けしました。 Greasemonkey チュートリアル読
プログラム未経験の僕が初めて作ったiPhoneアプリが2月16日に発売されます！というわけで使用した参考資料等のまとめ。 - らっこのじゆうちょう
Cocoaの本を読み始めてから２ヶ月、iPhone SDKをいじり始めてから1ヶ月半。 ついに僕が作ったiPhone / iPod touchアプリ「SingingCat」が2009年2月16日からAppStoreで発売されます。（日本での価格は115円。） (追記 2/16 4:30) 発売されました！ → 今後、僕のように未経験から何か作る方の参考になればと、以下にアプリ制作につかった資料をあげておきます。 読んだ本 たのしいCocoaプログラミング[Leopard対応版] 自作アプリをApp Storeで世界に向けて販売できる!! iPhone SDKプログラミング大全 (MacPeople Books) 参考させていただいたサイト・お世話になったサイト あまりまとまっていないですが、 僕のはてブのiPhone＆プログラミング タグ に全てあります。 また、Twitterのiphon
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
各種チートシートまとめ - goinger的日記
なんとなく便利そうなのを探してまとめてみた。 リンク切れおそろしい プログラミング関連 C, CPP, C# Cheat Sheets C, CPP, C#のチートシートがたくさんある 249 Prototype Dissected prototype.js チートシート 347 Haskell Cheatsheet Haskell 130 command line ruby cheat sheet ruby commandline チートシート 680 ruby-on-rails-cheat-sheet/ Railsのチートシート 701 google関連 google guide 検索オプションの説明とか 1358 Google Guide Quick Reference Google検索ガイド 9657 google help: cheat sheet google本家から提供 40
HSB 値と輝度の求め方
PhotoShop の HSB（Hue、Saturation、Brightness）カラーモデルは、基本的にはWindows API のカラー選択ダイアログで提供されている HSV（Hue、Saturation、Value）カラーモデルと同じです。 ただ細かいことですが、PhotoShop の HSB 値は、RGB 値と 1 対 1 で対応していません。RGB には、24bit すなわち 16,777,216 通りの値があり得ますが、HSB には、彩度 360 度、彩度と明度 0～100 % のそれぞれ101通りで、 360 × 101 × 101 = 3,672,360 通りしかありません。ということは、RGB から HSB を求める計算は不可逆ということになります。 Windows のカラー選択ダイアログでは HSV も 24bit で表現しているので、可逆だろうと思います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Project Cartoon: Japanese
顧客が本当に必要だったもの《アイマス版》 - やねうらおブログ(移転しました)
2NT -無料ブログ 無料ホームページ 等-