タグ

2010年4月6日のブックマーク (13件)

  • まとめよう、あつまろう - Togetter

    コミュニケーションが生まれるツイートまとめツール

    まとめよう、あつまろう - Togetter
    ocs
    ocs 2010/04/06
  • ドミニオンプレイイベント5th 10.10.03

    今回も、決勝戦と一部フリープレイ卓で「Prosperity」(日語版名:「繁栄」)を使用いたします!ぜひ、発売前のエキスパンションをお楽しみください。 初心者向けのルール説明も実施いたします。 日時 2010年10月3日(SUN) 11:00~21:00(前回と開始時刻が変更になりました。なお、トーナメント参加者は13:40までにご来場ください) 会場 なかのZERO 西館 学習室1 参加費 400円(ドミオン~4セットをお持ちいただいた方は200円になります) 募集人数 事前予約枠として60人を受付けます。それとは別に当日枠を若干用意しております。 ただし、会場のキャパシティの都合で、入場をお断りする場合もありますのでご注意ください。 その他 会場の状況については、twitter上で情報を流す予定です。@fujiken_UTGを一時的にフォローしていただくか、ハッシュタグ#domini

  • 株式会社ファンケル様 | 事例紹介 | NECソフト

    ocs
    ocs 2010/04/06
  • 日本のIT業界の問題点 - 技術情報Wiki

    業界イメージの悪化問題 † イメージはそんなに悪くない 2008.2.29 学生が就職を希望する業界としてIT業界は全24業種の中で8位。 「今後の日を支えていく」業種を尋ねる質問では5位と上位にランクされるものの、「人気が高くて就職が難しい」では10位、「働いている人の満足度が高い」でも10位、「優秀な学生が就職する」でも11位と中位。情報系の学生ではいずれの質問に対しても平均よりも上位に来ているが、文系と情報系以外の理系の学生の答えがもう1つだった。 IT企業新卒採用苦戦の理由は仕事のイメージ悪い 2008.1.29 復活果たしたITサービス業界がこの5年で失ったもの 2007.7.20 1.業界への若者の好感度 2.業界の成長性 かつてのような右肩上がりの成長シナリオを描けるソリューションプロバイダは少ない。既に金融業界向けでは,顧客の旺盛な引き合いに応えられず,一部の仕事をやむな

    ocs
    ocs 2010/04/06
  • コメントを書くべきか書かざるべきか

    原文(投稿日:2010/03/03)へのリンク 開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。 Seattle Area Alt.Net グループのメンバらが、コードにコメントを書く必要性やプラクティスについて議論した。Kelly Leahy氏は、一目瞭然のわずかなコメントが散りばめられているようなコードが好みだ。コメントは「コードを変更したときに取り残されてしまうことが多く」、「不正確なノイズをシステムに取り込んでしまうだけ」だと考えているためだ。 (コメントを書くということは)多くの人にとって個人的なことですが、私はコメントをかなりスリムにするよう気を配っています。というのも、コードを変更したときに、コメントが取

    コメントを書くべきか書かざるべきか
    ocs
    ocs 2010/04/06
  • 大企業は社内調整が忙しくて、顧客に構っている暇はない:それでも開発は続くよ - CNET Japan

    大企業の社員ともなると、暇が無くて大変なのである。 社内調整がとてつもなく忙しくて、顧客なんかに会っている時間はないのである。 もちろん、新しい事業などと関わっている暇はない。 「稼ぐ」などとは無縁である。そんな下賤なことは販社、代理店でやればよい。 仕事とは手続き・調整であり、決定権ですらどこにあるか分からない中で、その都度その都度手順を踏んでいかなければならない。 様々なテンプレートから書式を選ぶところから仕事は始まる。 発注者になる@システム部門は窓際である これはもう、大変である。一言では説明しきれない。 SIベンダへの発注を例にとってみよう。 窓際であるシステム部門の課長、部長にとっての予算執行は一大行事である。 どう見ても一人で2週間で出来る仕事を、数人で何ヶ月、の仕事に引き延ばす。 システム開発なり、大規模改修における発注担当者の動きは1000万を超えようものなら、手続き・調

    ocs
    ocs 2010/04/06
  • String非推奨の勧め - minghaiの日記

    Javaプログラムにおいて,クラスを作ることを厭う人たちが多い. そのような人たちの多くはデータを桁数依存にて構造が存在する文字列にして扱うことを好む. しかしJavaにおいてStringを解析することは多くの例外の原因となり,ひいてはシステム障害の原因となることが多い. またStringの演算は重く,Stringはメモリ消費量が多い. この文章では,Java利用システムにおいてStringの濫用を戒め,適切な型の利用と適切なクラス設計を行うことを勧める.*1 Stringの問題 多発する例外 Stringを利用することにより発生する例外には次のものがある. NullPointerException StringIndexOutOfBoundsException IndexOutOfBoundsException IllegalArgumentException UnsupportedEn

    String非推奨の勧め - minghaiの日記
  • プログラマーとSEのフリーランスのススメ♪

    管理人がシステム開発の仕事を始めて1年目でフリー(個人事業主)になった経験から、プログラマーやSEがフリーランスになる方法や体験談を書いてます☆

  • 古き悪しき詳細設計書 - SiroKuro Page

    詳しすぎる詳細設計書 - SiroKuro Page の続きです。前の記事ではブクマありがとうございました。 はてな界隈の拒否反応を見る限り、詳しすぎる詳細設計書に良い印象を持ってる人は少なそうです。もっとも、私は良い面も持っていると思っていまして、 プログラマの技術的知識や業務的知識の量に左右されることなく、一定の品質を保つことができる なんてメリットがあります。属人性の排除ですね。 あたりまえですね。実は設計者が書いたプログラムを詳細設計書と呼んでいるんですから。しかもテストどころか処理系にわせてすらいないプログラムです。悪く言えば机上の空論です。良く言えば……絵に描いた? プログラマの技能に左右されないかわりに設計書の品質に左右されるので、一定の品質が「悪い方に一定」だったりすることもあって、色々と下流工程の憤が溜まりそうです。既に溜まっていますね、ごめんなさい。 題:古き悪

    古き悪しき詳細設計書 - SiroKuro Page
  • 詳しすぎる詳細設計書 - SiroKuro Page

    「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力: 「性別と身長のペア」のリスト 出力: 男性の平均身長」と「女性の平均身長」の差 処理概要: 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を1つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を1増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を1増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい

    詳しすぎる詳細設計書 - SiroKuro Page
  • 【図解!!コレが方眼紙Excelだ!】 島国大和のド畜生

    2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04

    ocs
    ocs 2010/04/06
  • アジャイルって受託開発との相性が最悪な気がする - GoTheDistance

    全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え - Publickey 「ウオーターフォールとは」のラベル貼りの議論になるとめんどくさいから、とりあえず「初期段階ですべての意志決定をしようとするシステム開発の進め方」という定義で話を進めたいと思います。 滝 「要件定義」→「設計」→「実装」→「テスト」という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ

    アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
  • 誤ったマージタイミング - wwolf.web.fc2.com

    ocs
    ocs 2010/04/06