タグ

programmingに関するitachisoftのブックマーク (52)

  • 詳細設計書が滅亡しない理由 - kagamihogeの日記

    IT 業界というか SIer の枠組みの中で働いている人であれば、一度は詳細設計書ないし詳細仕様書というドキュメントを見たか書いたことがあるだろう。 Excel 方眼紙の悪夢 詳細設計書の話の前にちょっと触れておきたいのが「Excel 方眼紙」 これまでのプロジェクト経験とネットの情報を見る限り、詳細設計書はほぼ 100% コレで書かれている。Excel 方眼紙がどのようなものかは こんな感じ である。典型的な使われ方は 【図解!!コレが方眼紙Excelだ!】:島国大和のド畜生 がわかりやすい。 「Excel 方眼紙」でググるとわかのだが、コイツは猛烈に嫌われている。一発作り捨てならば、図や表を交えたドキュメントをそこそこ作りやすいという利点はある。プレゼンや紙印刷を考えないならば、個人差はあれど PowerPoint 並の使い勝手を覚える人はいる。 がしかし、Excel 方眼紙はそのメリ

    詳細設計書が滅亡しない理由 - kagamihogeの日記
  • プログラミング言語人気TOP10の簡易解説

    0-1. 前書き この世にはたくさんのプログラミング言語が存在します。Wikiepdiaのプログラミング言語一覧を見ると、実に200個以上というわけの分からない数の言語が並んでいたりします。 【参考URL】プログラミング言語一覧 - Wikipedia http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%... 200の中にはほとんど使われてない言語も混じってるので、実際に仕事でざくざく使われている言語は20とか30とかそういうオーダーなのですが、それでも1人の人間が把握するにはちょっと多過ぎる数です。 記事では、そうした有り余るプログラミング言語の海の中で「どれを勉強したらいいの?」とか「どれを採用するのが適切?」という悩みをお持ちの方が「よし、この言語に決めた!」と自信を持って決断できるように背中を押すことを目的として書か

  • DOMから始めるJavaScriptモダン・スクリプティング---目次:ITpro

    近年,Ajaxの台頭をきっかけに,JavaScriptを使ったブラウザのリッチ・クライアント化が進んできました。現在では,ページの表示を変化させるだけであれば,ほとんどのことはJavaScriptのみで対処することが可能です。それを実現するのがDOMなのです。 第1回 DOMから始めるモダン・スクリプティングの世界へようこそ 第2回 ブラウザからHTMLはどう見えているかを理解しよう ~ドキュメントツリー~ 第3回 DOMスクリプティングのことはじめ(1) ~要素(タグ)を狙い撃ち~ 第4回 DOMスクリプティングのことはじめ(2) ~これはどんな要素?~ 第5回 DOMを使ってHTMLを自由自在に書き換える 第6回 イベントハンドラから脱却しよう 第7回 スクリプトを完全に分離しよう ~コンテンツ,プレゼンテーション,ビヘイビア~ 第8回 スクリプトのパッケージ化 ~使い回しできるスクリ

    DOMから始めるJavaScriptモダン・スクリプティング---目次:ITpro
  • プログラマなら人月なんかさっさと超えろ - 矢野勉のはてな日記

    Java, プログラミングノリノリで書いてみる。 人月というのは「人月の神話」以来、現場の技術者にとっては「お金の計算にしか使えない単位」なのですが、発注者側に分かりやすいということでいまでも大はやりしています。というか受注者側もまじめにこの単位で計算しています。 そしてJavaの世界というのは、私のようにJavaが大好きだからやってる、という人間はすごく少数派で、「そろそろJavaでもやっとくか」「Strutsの使い方覚えたからもういいか」「できればJavaなんかいじりたくないなー。俺も早くプログラマに『これやっといて』って言えるようになりたい」という人のほうが多いのが実情なんですね。その点Rubyの世界は、今は「好きだからやってる」人が圧倒的でしょう。プログラム能力の高いJavaプログラマを探すのは、プログラム能力の高いRubyプログラマを探すよりずっと大変だろうと思う。 Javaの世

  • 覚書き/Selenium - PukiWiki

    SeleniumRC † RCはリモートコントロール。 Firefox以外のブラウザもサポートするので、IEもいけるはず。⇒いけた! 開発言語からの使用と、コマンドラインからの使用と、2つの使い方がある。(こまんどラインは下のほうで少し紹介) ↑ 開発言語(Java)からの使用 † とりあえず、説明は Eclipse を前提で。 Javaプロジェクトを作成して、libフォルダを作成する。 以下のファイルをlibフォルダにコピーして、ビルドパスに追加する。 selenium-server.jar selenium-java-client-driver.jar Seleniumのホームページには、SeleneseTestCase を継承して単体試験コードを書くサンプルがあったのだけど、Exceptionがthrowされてしまった。どうやら、別(コマンドライン)で Selenium Serve

  • Seleniumメモ - オエリブラ観測所

    Selenium RCを使ってIEとChromeが動かなかったのことにいらついたので調べる。 一般的にはselenium-server.jarのあるフォルダに移動してから 下記コマンドをコマンドプロンプトに打ち込めばOK。 java -jar selenium-server.jar -htmlSuite <起動ブラウザ指定> <テスト対象となるサイトのURL> <テストスイートの絶対パス> <結果保存用ファイルの絶対パス> IEを起動する方法 起動ブラウザ設定に *iexplore または *iexploreproxy を指定すれば良い。 差がわかってない。 起きてるエラーはたぶんこれと同じ Selenium RC with IE7 *iexploreproxyの罠 さっそく嫌な記事を発見した 覚書き|Selenium 少し調べたところ、どうやら 1.0.3 では、iexploreprox

    Seleniumメモ - オエリブラ観測所
  • 全Eclipse Java プログラマーに捧げる Eclispe 徹底活用術完全版〜Eclipseに空気を読ませて楽する術〜 - Yamashiro0217の日記

    この記事は、http://d.hatena.ne.jp/higayasuo/20090612/1244772658 の「Ctrl+1とCtrl+Spaceうんぬん」の話にインスパイアされて書いた。Eclipse可愛いよ。Eclipse。 記事長いから、さくっと読み飛ばして、アニメーションgifがあるところから読んでも十分訳にたつと思う。 あと、新人さんとかに写経させるのもいいかも。というか、半分ぐらいうちの新人に勉強のためと思って書いたから。で、実際に写経させて役にたった。 Java は Eclipse などの IDE も含めて言語というか、環境というか…だと僕は思ってる。Commons, Maven なども含めたい(まぁ、そのあたりは、CPANも含めてperlだろ。とか、これは否定する人だらけだろうけど、Railsrubyということを言う人もいるよね)。 少なくとも僕は、Eclipse

    全Eclipse Java プログラマーに捧げる Eclispe 徹底活用術完全版〜Eclipseに空気を読ませて楽する術〜 - Yamashiro0217の日記
  • ユメのチカラ: プログラマの基礎体力

    そもそも、プログラマの基礎体力ってなんだろう。学校でアルゴリズムの基礎を習うとか、プログラミング言語を習うとか、あるいはコンピュータの基礎を習うとかそういうことなのだろうか。 断片的な情報を獲得するのなら確かにインターネットや書籍でどうにかなる。しかし、職業プログラマとして一目置かれる存在になるための基礎体力ってなんだろう。 高校や大学などでプログラマの基礎体力は身につくのだろうか。 プログラムと言っても、ゲームのプログラムから、顧客の要求に従ったアプリケーションプログラム、組み込み機器の制御プログラム、あるいはOSやら、コンパイラやら、RDBMSやらの基盤ソフトウェアなど様々ある。 わたしの場合、子供の頃、初めてコンピュータに触る機会があって、その時のなにやら得体の知れない興奮みたいなものが結局のところコンピュータ関連の職業につくことになったのだが、知識0から鍛えるべきプログラマの基礎体

  • ユメのチカラ: プログラマの仕事はプログラムを読むことである

    ソフトウェア開発コストのほとんどは保守のコストだと言われている。各種統計がそれを示しているわけだけど、自分の実感とも合う。 古典的なウォータフォールモデルでは保守というのが意識されないか、あっても一番下流なので、その重要性に対する認識が非常に薄い。 保守という言葉は若干大げさな響きを持つが、プログラムの不具合の修正や、ちょっとした機能変更、機能追加などなど、運用していけば、つまりそのソフトウェアが利用されていれば必ず必要なものである。保守されていないソフトウェアは早晩利用されなくなるか、既に利用されていないかである。 Unixの哲学を持ち出すまでもなく、優れたプログラマはプログラムを書くのではなく、再利用する。いかにしてプログラムを書く機会を減らすか虎視眈々としている。可能な限り再利用して、どうしても書かざるを得ない場合はリサイクルをしちゃったりする。(プログラマにとってのReduce/R

  • はてなブログ | 無料ブログを作成しよう

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    はてなブログ | 無料ブログを作成しよう
  • Googleブックスで読めるソフトウェア開発に関する本たち - 俺がぐったり部だ!

    Googleブックスの騒ぎを知って約1年。気づくと今そこには「読んでみたかった!」というが数多く載せられていることを知りました。 さて、そこでゲーム開発にも応用できる知識を中心に私がチョイスしたのが以下のたちです。もちろんGoogleブックスではこれら以外にもまだまだ多くのを閲覧することができます。これらを読めば、には当に知識と情報がまとめられているということ、著者たちの努力を発見できると思います。 ゲームデザイン 「おもしろい」のゲームデザイン: 楽しいゲームを作る理論 シリアスゲーム デジタルゲーム学習: シリアスゲーム導入・実践ガイド ユーザビリティエンジニアリング原論: ユーザーのためのインタフェースデザイン 人はなぜ形のないものを買うのか: 仮想世界のビジネスモデル ゲーム理論の基と考え方がよ〜くわかる ノベルゲームのシナリオ作成奥義 ライトノベル創作教室 すごい人

    Googleブックスで読めるソフトウェア開発に関する本たち - 俺がぐったり部だ!
  • プログラマが知るべきじゃない97のこと

    take3000 @take3000 「プログラマが知るべきじゃない97のこと」っていうのを誰か書かないかな RT @syuta: 404 Blog Not Found:紹介 - プログラマが知るべき97のこと - ほしいほしい http://bit.ly/grEkak 2010-12-13 13:19:45

    プログラマが知るべきじゃない97のこと
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

    プログラミングと設計は来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
  • 10年間泥のように働いて花が咲きました - ひがやすを技術ブログ

    蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会

    10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

    昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
  • SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ

    10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

    SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
  • SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ

    刺戟的な題名で続けます。 前回は日独特のSE/PGの分業体制がどのようにして発生したのか、ということを説明しました。それは日にソフトウェア開発が産業として根付いたときに、PGが単純作業労働者と位置付けられてしまったため、上級技術者を区別する言葉が必要とされた、それがSE(システムエンジニア)だというものでした。 ●C言語@UNIXでは COBOLの開発ではSE作業とPG作業がきちんと分けられていると思われがちですが、これも前回述べたとおり実際には形式だけのものになっていました。これはタイムシェアリング端末の普及によってプログラミング作業が格段に効率化されたからでした。プログラミングに残っていた煩雑な手作業の部分が省力化されたのです。 この事情はBasicやC言語でも同じことです。1980年代後半、わたしは最初の会社を辞め、パソコンの開発をするようになりました。現場では、技術者はそれぞれ

    SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
  • 入門 自然言語処理を禁書にすべき10の理由 | TRIVIAL TECHNOLOGIES on CLOUD

    みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー 「入門 自然言語処理」はヤバい書籍なので禁書にすべきだ。 タイトルは釣りじゃない。その理由を10個挙げる。 自然言語処理のかなり基的なことからそこそこ高度なことについて解説されてあり,自然言語処理について理解が深まり過ぎる ボリュームがあるのに書き方が平易でついつい読みふけってしまう 演習問題があり,自分の理解度を確かめられたりするのもケシカラン 原著は欧米語のための言語処理について書かれた書籍なのに,日語の形態素解析などについても解説してあって我慢できない 必要ライブラリのインストールなど環境構築に時間が取られそうでヤバい 書籍の応用でBotとか人工無能とか作ったらどうかな−,と

  • 「コードの読まれ方が分かった」、工数見積もり精度向上に寄与

    「コードの読まれ方が分かった」、工数見積もり精度向上に寄与:奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月~11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守/派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな

    「コードの読まれ方が分かった」、工数見積もり精度向上に寄与