タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

ProgrammingとDevelopmentとdevelopmentに関するftnkのブックマーク (47)

  • なぜお前らは「好きだからコードを書く」はできるのに「好きだからメンテナンスする」ができないのか? - mputの日記。 (2007-09-24)

  • ke-tai.org 携帯プログラミング情報

    2013/6/1に第四回札幌MySQL勉強会開催を行います Tweet 2013/5/20 月曜日 matsui Posted in お知らせ | No Comments » イベントの告知です。 2013年6月1日に、第四回札幌MySQL勉強会が開催されます。 日時: 2013/06/01 14:00 ~ 18:00 場所: 株式会社インフィニットループ (札幌市中央区北1条東1丁目6-5 札幌イーストスクエア 6F) イベントの詳細についてはこちらの公式サイトからご覧下さい。 → 札幌MySQL勉強会公式サイト 今回も第三回と同じく、セミナー形式ではなく個人個人が好きに勉強をしようという会です。 最後に成果発表の時間を設けますので、差し支えなければ簡単な発表をして頂ければと思います。 今回は「MySQL5.6を体験してみよう!」をテーマに、MySQL5.6のサーバを用意する予定です。

  • IBM Java:コード品質を追求:ソフトウェア設計者にとってのコード品質 - Japan

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Java:コード品質を追求:ソフトウェア設計者にとってのコード品質 - Japan
  • バグを見つけるためのテストをしよう

    「一生懸命テストしたのに、どうしてもバグがなくならない。」これは、すべてのソフトウェア開発者に共通する悩みであろう。 バグのあるソフトウェアでも、リリース前には、膨大なテスト項目をクリアしてきたはずだ。だが、そのほとんどは、仕様書や設計書から書き写しただけの、機能が正しく動くことを確認するものばかりになってはいないか。 テストしても見逃されるバグは、ソフトウェアを使い込んだり、ちょっと変わった操作をしたり、ある特殊な状況でのみ発生するものが多い。このようなバグは、意図的にバグを見つけようとしない限り、見つからないものである。 ソフトウェアテストも、創造性を問われる仕事である。ソフトウェアテストに関する広汎な知識と、豊かな想像力で、バグを見つけられるようなテストを創り出していかなくてはならない。それができなければ、ソフトウェアの品質も向上しない。 確認のためのテストと、バグを見つけるためのテ

  • 秋元@サイボウズラボ・プログラマー・ブログ: regist という英語は無い

    さて、サイボウズラボの立ち上げプレスリリースが出たこの瞬間、とりあえずこのブログを見に来る人も多いと思われる。そんなチャンスに、このブログを読んだ人、特に日のソフトウェア技術者に一番訴えたいことってなんだろう? と考えた。 それは、日プログラマーだけが使う謎の動詞 registについてである。そんな単語は存在しないから、ちゃんと "register" を使おう。 Google.com で regist.cgi を検索 Google.com で regist.php を検索 出てくるのは日語のサイトばっかりである。拡張子を".jsp" や ".asp" にしても同様だが、とにかくこの「存在しない単語を使ったファイル名」のなんと多いことか。 register = 「登録する」 は、名詞でもあり動詞でもある単語だ。"-er" がついた単語は「○○する人」の意味のことが多いため、"er"

    秋元@サイボウズラボ・プログラマー・ブログ: regist という英語は無い
  • Six Apart - Tech Talk Blog: Six Apart のチーム開発 〜 コミット・ログをメールで

    2006年09月07日 Six Apart のチーム開発 ~ コミット・ログをメールで こんにちは。TypePad Engineer の重田です。 今回のTech Talk Blogはチーム開発について触れてみたいと思います。 はじめに 唐突ですがにチーム開発についていくつか列挙します。 ソフトウェア開発において最も重要な資源はソースコードです チームでの開発において最も重要なのはコミュニケーションです シックス・アパートではソースコード管理にsubversionを利用しています シックス・アパートではコミュニケーション・ツールに、メール・メッセンジャー・チャット・ビデオ会議など使用しています ということで今日はコミット・ログについて触れます。 シックス・アパートでの私 シックス・アパートではリポジトリにコミットされたログがメールで送られてきます。一日に100通近いメールが届きます。Mov

  • 使いながら覚えるGDB

    はじめに プログラムのデバッグと言えばひたすらprintfを挿入しまくっていたある日、 デバッガなる便利な代物があるということを知った。なんでもプログラムを一行 ずつ実行できて、変数の値をその場で確認できるらしい。これは是非使ってみねばと 思い、UNIX環境で使えるGDBというデバッガを試してみた。が、何がなんだかさっぱり 分からない。Webを検索するとマニュアルの日語訳が見つかった。これで勉強すれば 使えるようになるかも、と読み始めるも、いきなりm4がどうのこうのだの、意味不明 の文章が続く…。 これは私がGDBを使い始めた時の話だが、似たような経験を持っている人が他にもいる と思う。 GDBのマニュアルは初心者にはすこし敷居が高い。 GDBに限らずマニュアルというものは初学者が参考書として用いるのには 適していない。というのも、マニュアルの類は情報量が多い分、重要な部分を 見つけ出す

  • CodeIDE

    CodeIDE
  • monotone: distributed version control

    monotone is a free distributed version control system. it provides a simple, single-file transactional version store, with fully disconnected operation and an efficient peer-to-peer synchronization protocol. it understands history-sensitive merging, lightweight branches, integrated code review and 3rd party testing. it uses cryptographic version naming and client-side RSA certificates. it has good

    ftnk
    ftnk 2007/09/11
    monotone is a free distributed version control system.
  • http://www.seshop.com/event/dev/2007/data/

  • HackingWithGnu - enbug.org

    はっきんぐ・うぃず・ぐにゅー GNU を使って開発しようっていう不定期な連載です。 いつ書かれるかも分からないし、いつ終わるかも、いつ改訂されるかも不明です。 もちろん、ここは全然公式なページじゃありません。 嘘は出来る限り書かないように努力しますが、絶対信頼してはいけません。 これらは、かなり昔に私自身が執筆していた記事を掘り返した物です。 古くなって、現状に当てはまらない部分を更新していますが、十分ではないかもしれません。 第一回 GNU C の書き方 (1) 第二回 GNU C の書き方 (2) 第三回 GNU C の書き方 (3) 第四回 GNU Make の初歩 第五回 GNU Automake の概要 第六回 GNU Autoconf (1) 第七回 GNU Autoconf (2) 第十二回までありますよ...

  • 開発ツールとしての Emacs

    の元原稿に少しだけ手を加えたものです。 雑誌掲載のものとは若干の差異があります。(詳細未確認) 2001年5月〜2006年11月の掲載記事を PDF で収録した MOOK が2007年5月に出るということなので これを機会に整理しました。 じつはね 「安く出したいので著作権料は現物支給で勘弁願いたい」 というメールが来たのだった。 原稿を書いた全員が二次使用の無報酬に同意したのかはわからないが、 「ま、たいした分量でもないのでいいか」と思ったしだい。 (原稿料の下落につながるからそんな勝手なことすんな!と いった話があるのであれば教えてくださいね) (注) IE6 (IE7未確認) ではなく Firefox や Safari で見ると私の 意図通りに表示されているようです。 他のブラウザは未確認です。 前書き 著者の Emacs 歴は1989年の Nemacs(Emacs18.55 をベ

  • ソフトウェア開発者のための推薦図書

    Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための「楽しい料理だ。このを読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。このを読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこのがすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。このではやるべきでない悪い例には"coding horror"アイコンで印

  • http://www.sabamiso.net/yoggy/hiki/?2007%2F04%2F09+%A5%EA%A5%D0%A1%BC%A5%B9%A5%A8%A5%F3%A5%B8%A5%CB%A5%A2%A5%EA%A5%F3%A5%B0%A4%DE%A4%C4%A4%EA%A4%CE%A5%E1%A5%E2

  • Wataru's memo(2007-04-11)

    ● [Linux][Writing] 世界一単純な実行ファイルフォーマット binfmt_flat Computer Architecture Series 第二作のために、日々素材作りを進めているのですが、この作業の間に "binfmt_flat" というオタッキーなモジュールが誕生しました。今日は、このモジュールを使った "Hello golf" をご紹介しましょう(注: 昨年一世を風靡した ELF golf ではありませんので、あしからず)。 初学者の理解を阻む複雑な ELF 皆さんご存じの通り、PC-UNIX 上における標準のオブジェクトファイルフォーマットは ELF (Executable and Linking Format) ですが、このフォーマットは高機能を追求しているため、内部はかなり複雑な作りになっています。 実は、当初 Computer Architecture Se

  • プログラマの権利宣言

    Jeff Atwood / 青木靖 訳 2006年8月24日 企業は開発者に給与として60-100kドル支払いながら、ひどい作業環境と汚い使い古しのハードウェアによって彼らを損なっている。信じられない話だ。そんなのはビジネス的に理屈に合わない。ところがそういうのをどこでも目にする。ソフトウェア開発者が成功するために不可欠なものを与えていな い企業がいかに多いかは驚くばかりだ。 そこでプログラマの権利宣言を採択し、成功に不可欠な基的なことを否定する企業からプログラマの権利を守ることを提案する。 すべてのプログラマは2つのモニタを持つ権利を有する 下落する液晶ディスプレイの価格と、遍く存在するデュアル出力ビデオカードのことを考えるなら、開発者を1つのディスプレイに制限するのはばかげた話だ。ディスプレイを2つにすることによって得られる生産性の利益については、今では十分に説明されている。開発者の

  • プログラミングの6大10項目リスト

    Jeff Atwood / 青木靖 訳 2007年3月22日 以下に私の選ぶプログラミングの6大10項目リストを挙げておく。取り上げた順序には特に意味はない。このエントリを簡潔なものにしておきたいので、それぞれの項目は短い要約を引用するに留める。興味を引くものがあれば、ぜひリンクをたどってオリジナルの作者の考えについてもっと詳しく読むことをお勧めする。 [ 訳注: 要約だけで意味が取りにくいものに簡単な説明をつけた。] ジェラルド・ワインバーグの「エゴレスプログラミングの十戒」 自分が誤りを犯すということを理解し、受け入れること 。 自分と自分のコードは別物である。 どんなに「空手」を学ぼうと、いつでもあなたよりもっと詳しい人間がいる。 相談せずにコードの書き直 しをしない。 自分より無知な人に対しても尊敬と敬意と忍耐を持って接すること。 世界で唯一変わらないのは変わるということだけ。 唯

  • Twitter API 仕様書 日本語訳

  • プログラミングの光景:第1回 デバッグについて|gihyo.jp

    プログラミングに関する雑多なあれこれ 今号から、「⁠プログラミングの光景」と題して連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。連載ではプログラミングに関する雑多な事柄について書く予定です。 第1回は、プログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。 デバッグの時間 ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも(そうであってほしいと考えているよりも)デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。 デバ

    プログラミングの光景:第1回 デバッグについて|gihyo.jp
  • アジャイルのレイヤ 〜 アジャイルを整理し直して理解する - kuranukiの日記

    アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。 最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、

    アジャイルのレイヤ 〜 アジャイルを整理し直して理解する - kuranukiの日記