プログラムが書けない人に「仕様変更」について説明するには | tech - 氾濫原
「仕様変更」という言葉はプログラム書く人じゃないと、そのイメージが掴めないと思う。イメージが掴めない人に対してそれを説明するとしたら何がいいだろう？ と思った。 とりあえず、料理に例えたらいいのではないかと思ったので、それに例えて考えてみる。 仕様とはレシピのことであり、最終的には具体的に「食べることができる美味しい料理」すなわち「うまく動くプログラム」を作ることを目的としている。 仕様というのは、最初は「イタリア料理」「日本料理」「中華料理」程度しか示されない。当然この時点では方針程度しか考えることができない。食材を買うこともできない。せいぜい使う調味料を揃えるぐらいしかできない。 もう少し進むと、料理名まで具体化される。スパゲティを作りましょうとか、ピザを作りましょうとかだ。とりあえずここまできたら小麦粉を買おうとかまではできるかもしれない。でも実際に作りはじめることはできない。 さら
「よりよいコードを求めて命名について頭をひねる会」のログ
http://www.zusaar.com/event/438105 アプリケーションを作る英語 の著者の西野さんを交えて、クラス名とかメソッド名とか変数名とか命名で困っている課題を1つ以上持ち寄りみんなで一緒に検討する勉強会をしました。 「アプリケーションを作る英語」 電子書籍 http://tatsu-zine.com/books/english4app 紙 http://www.amazon.co.jp/gp/product/4844332848/ はじめに：西野さんからちょっとお話 The Art of Readable Code から第2章と第3章 第2章：名前に情報を詰め込むようにする どういう情報をつめこむか。 明確な言葉を選ぶ get は不明確らしい getPage(url) -> FetchPage(url) や DownloadPage(url) 特色のある（color
学んでから作るのではなく、作ってから学ぶ - ぼくはまちちゃん！
こんにちはこんにちは！！ 先日、ちょっとしたイベントで、学生の方にこんな質問をされました。 「自分は早くプログラマになりたい、作りたいアプリもある。 だけど来年にならないとプログラミングの授業が始まらないから、作れない」 と。 なるほど。 その時、ぼくが答えたのは、 「今日、家に帰ったらプログラミングしてください」 だったんだけど、言葉が足りなかったかもしない。 だからここに、もうちょっと詳しく書いてみますね。 アプリを作る、プログラマになる、一番手っ取り早い方法を。 1. 目標を立てる 作りたいものを思い描くということ。 いきなりすごいものを作るのは大変だから、最初の目標は少し抑えてちょっとしたものがいいね。 できれば、自分にとって便利なものや、少しワクワクするものがいい。 例えば、スマホで動くキッチンタイマーとかでもいい。 （これはワクワクしないかもしれないけど） 2. すぐに作り始め
プログラマの実力は経験だけであがらないことがレベル格差につながる - きしだのはてな
プログラマというのは、道具に慣れることが、実力があがることにならないのですよね。だから、勉強せず業務経験だけだとレベルが低いままということになってしまう。 Javaを10年さわり続けて、Strutsを5年さわり続けても、それだけでは、与えられた画面を手際よく作成できるようになるだけで、たとえばStrutsすらよりよく使えるようになるわけではなかったりする。 Javaにしても、「volatileってなんですか？」という問いに、まあ知らないのはしかたないとしても、解説を見ながらですら答えられない可能性がある。 プログラムの反復生産は、プログラミング能力の向上にあまりつながらない。設定や記述に慣れるだけだ。そして、この「慣れ」というのには「難しいからそもそも実装を回避する」というようなものも含まれる。実力の向上は、作業ができるレベルで止まってしまう。 プログラマとしての実力をあげるための勉強が自
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
新人SEがSIerに絶望した時に読みたいスライド4選 - ギークに憧れて
新社会人の皆さん､いかがお過ごしでしょうか｡ 最近､SIerに就職した知人が｢会社辞めたい｣というのをちらほら聞く｡聞いてみれば､彼等は仕事で挫折しているわけではない｡むしろ､技術に優れ熱意を持っている事が多い｡ではなぜ辞めたいのかと聞けば､一日中画面のスクリーンキャプチャ撮らされたりCOBOL読まされたりしていて､｢ああ､そっか…そうだよね…｡｣となる｡ そんな時は､SI業界の熱い人達のスライドを見て何かを感じよう！という事で4つ選んでみた｡弊社関係者が多いのは僕のネットウォッチの都合上お許しください｡moon and strategy moon and strategy from toshihiro ichitani 永和の@papandaさんのスライド｡｢自分の生き方を他人任せにしない｣受託プログラマの進路〜アジャイルセールスと手塚モデル〜 受託プログラマの進路 〜アジャイルセールス
名状し難いコードを書く(コメント編) | Webシステム開発／教育ソリューションのタイムインターメディア
あらすじ 長年プログラムを書いていても、良いコメントを書く技術ってぇのはなかなか身に付かないもので、 良かれと思って書いたコメントでも後々読み返すと書いた当人ですら首を傾げる始末。 長屋に住む八五郎もそんなSEの一人。 ある日、出社すると親方エンジニアがカンカンに怒っている。 どうやら先週末の退社前にレビューしてもらおうと push したコードについてらしい。 特に不味いところはなかったはずだが、はて、何が悪かったのだろうかと親方のデスクのモニターを覗き込むと── さっぱり役に立たない <summary> 八五郎は普段から Visual Studio で C# のコードを書いている。 こいつにはXML Documentation Commentsというのがあり、 一定の書式に従って型やメンバーにコメントを書いておけば、 インテリセンスで有意義なメッセージが表示されたりAPI リファレンスの
ウンコード・マニア
「なんだこの糞コードは!(怒)」「書いた奴出てこい!(怒)」 こんな声を聞いたり、叫んだりしたことはありませんか？ ウンコードについて学ぶことによってウンコードを撲滅しましょう！ とりあえず、趣のあるウンコード鑑賞から始めて下さい お知らせ 2013-06-27 profile image をTwitter API1.1に対応しました。Thanks for Profile Image API For Twitter 2013-06-16 Twitter API1.1に対応しました。 2012-12-05 職人ランキングを追加しました。 2012-11-21 レコメンド機能を追加しました。 Twitterアカウント @unkode_mania で更新情報をつぶやいてます 障害情報 2012-08-14 障害情報: 19:20 - 21:59 くらいの間、internal server err
ペアプロ・TDDの『お題』をまとめてみた #tddbc #coderetreat #pp_con - Diary of absj31
TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人
iPhoneアプリで食べていく――「ぐんまのやぼう」ができるまで
全国を群馬県にしてしまう人気ゲーム「ぐんまのやぼう」を開発したのは、アプリ開発だけで生計を立てている28歳の自称「ネオニート」。これまで100本以上のアプリを作ってきたが、「できれば働きたくない」「ひっそりしたい」と話す。 「東京都は群馬県になりました」「日本の都道府県はすべて群馬県になりました、つまり日本は群馬県です」 日本中を群馬県にしてしまうスマートフォン向けゲーム「ぐんまのやぼう」がヒットしている。5月初めの公開から2カ月で60万ダウンロードを突破。関連グッズが発売されたり、開発者が群馬県の観光特使に任命されるなど、アプリの枠を超えた盛り上がりを見せている。 開発したのは、群馬県出身のプログラマー・RucKyGAMES（ラッキーゲームス）さん。スマートフォン向けアプリからの収入だけで生計を立てている、自称「ネオニート」の28歳男性だ。RucKyGAMESは彼とデザイナーから成る2人
美しいプログラムを書く(業務用Webアプリケーション保守編) | Webシステム開発／教育ソリューションのタイムインターメディア
あらすじ あなたはとある業務用 Web アプリケーションの開発・保守を任されています。 このアプリケーションは ASP.NET を用いて作成されており、 クライアントサイドは一部 jQuery を利用してナウなヤングにバカウケの UI を実装しています。 さて、今回は 商品情報の変更履歴を一覧表示する。一覧から2つのバージョンを選んで差分を表示できるようにする。 という機能を実装することになりました。 これ自体はちゃちゃっと実装し、以下のようなHTMLが生成されるようにしました: ... <table> <tr> <th>A</th> <th>B</th> <th>変更日時</th> <th>変更者</th> </tr> <tr> <td><input type="radio" name="new_version" value="9"/></td> <td></td> <td>2012-0
定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)
いやー、この問題は本当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの？老害なの？」 とか言わないで欲しい。この問題、本当に難しいんだよ！ ■ １度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり
橋本商会 » プログラムの写経
プログラミング初心者が写経する時に気をつけると良い事を4つ説明します。 画像はイメージです プログラムを勉強する時に、写経しろ（すでに完成しているプログラムを本から書き写せ）とか言われるが、ちょっと意識するとだいぶ違うと思う 1. 外から書け 例えば、1からnまでの数字を全部表示するプログラムがあるとする。 def run(max) 1.upto(max).each do |i| puts i end end run(10) これを写経する時、上から下に1行目から順に書くのではなくて、まず def run(max) end いちばん外側を書いて def run(max) 1.upto(max).each do |i| end end 中を書いて def run(max) 1.upto(max).each do |i| puts i end end こうなる。 上から書かないのが重要。プログ
自分がエンジニアとして働くために学んできたことをまとめてみる - smellman's Broken Diary
id:sinsoku さんが今までソフトウェア開発について勉強してきたことのふりかえりというエントリで学習してきたことをふりかえっていて、僕も転職を機会にまとめてみようかと思います。ただし、僕はエンジニアという大まかな括りで書いてみます。 とりあえず、期間はアルバイト時代からケイビーエムジェイ入社までの期間です。 アルバイト一社目 Linkedinには社名を書いていますが、社名は伏せておきます。よくわからないけど。 主な業務内容はVisual Basic 6でのGIS開発でした。当時はまだGoogle Mapsとか無かった時代で、G-XMLの動向についてが注目されていたような時代です。 アルバイトだったので研修などはありません。いきなり数万行(数十万行かな？)のVisual Basicのソースコードを渡されて改修するというものでした。 最初の一ヶ月程度はVisual Basic自体に慣れる
ITエンジニア向け質問・回答コミュニティ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
ITエンジニア向けQ＆Aサイト「QA＠IT」をローンチしました！：Rails Hub情報局：エンジニアライフ
こんにちは、＠IT編集部の西村賢です。本日、2012年5月29日にITエンジニア向けの質問・回答コミュニティサイト、「QA＠IT」をローンチしました！ あるようでなかった、日本語による本格的な技術系のQ＆Aサイトです（プレスリリース）。 今さらQ＆Aなの？ 今さらQ＆Aサイトなの？ と思う人もいるかもしれませんが、QA@ITは以下のような特徴があり、先行する多くのQ＆Aサイトとは異なります。 ITに特化している Wikipediaのように他の利用者の質問や回答を編集できる 質問や回答に対してプラス、マイナスの両方の評価ができる より多くの利用者が評価した回答が上位に表示される コミュニティに認められたユーザーは、徐々に権限が増える 回答と、回答以外のやり取り（質問への質問など）が区別できる 以下、順に説明いたしますが、その前にヒトコト。 分かる人には一瞬で分かると思いますが、QA@ITはS
僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組
昨日、@irofさんと飲みながら自分を思い返すと「ちゃんとソフトウェア開発を勉強しはじめてから3年間たった」つまり「@bleisさんを知ってからこの5月でまる3年間たった」 それまでの僕はデザインパターンもオブジェクト指向がなんたるかも、バージョン管理もなにも知らなかった。 毎日言われたことをこなす仕事をして、変えたいけど誰も教えてくれないし、学び方すら教えてくれなかった。 それなりに努力してたけど、よくはわかっていなかった。 そんな状態から抜け出したのが3年前。このブログの先頭でも書いた。当時僕は21歳かな。（ちなみに就職したのは19歳のとき） →【このブログをはじめるきっかけ - うさぎ組】 この3年間でやったことをふりかえってみようと思いました。 ちょっとわかりにくいだろうけど、2009年5月からの12ヶ月周期で書いてみます。 こうやって振り返るのはあくまで僕のためであって、何かを誇
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
: _
システム・エンジニアの基礎知識