タグ

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

  • 関連タグはありません

タグの絞り込みを解除

developmentとprogrammingとProgrammingに関するat_yasuのブックマーク (75)

  • ソフトウェアの肥大化について - bkブログ

    ソフトウェアの肥大化について 肥大化したソフトウェアというとリソースいでメンテナンスがしづらい厄介ものというイメージがあります。しかし、広く使われているソフトウェアは多かれ少なかれ肥大化しているように思えます。ソフトウェアの肥大化はよくないことなのでしょうか。 結論からいえば、必ずしも悪いことではありません。この話題は Joel Spolsky 氏がストラテジー・レターIV:ブロートウェアと80/20の神話で書いています。私が付け加えられることはあまりありませんが、最近、知人との間で話題になったので、少し書いてみたいと思います。 数年前、 Alan Kay 氏の Squaek についての講演を聞きにいったとき、途中でコードのサイズが話題になり、Squeak のコードはこんなに小さい(具体的な数字は忘れました)といって、何千万行もある Windows NT を引き合いに出して、Squaek

  • TechCrunch | Startup and Technology News

    Limited space! Get on waitlist to be the first to know when tickets go live!

    TechCrunch | Startup and Technology News
  • 私がソフトウェア技術者でもありつづける理由 : 404 Blog Not Found

    2010年09月25日22:45 カテゴリLoveCode 私がソフトウェア技術者でもありつづける理由 一言でいえば、「自分に報い続けたいから」ということになる。 私がソフトウェア技術者をやめた理由 - Rails で行こう!私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 以下に照らし合わせれば、その複雑な感情とやらそのものがお嫌いなのだろう。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 で、何をもって美醜を決めているかといえば、コルモゴロフ複雑性と、そこからの距離をお使いのようだ。 うるう年を計算

    私がソフトウェア技術者でもありつづける理由 : 404 Blog Not Found
  • Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている

    先日、経済産業省向けの仕事をしている知り合いと事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月30万円というケースもあるという。 こんな話を聞くと当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日で一人月30万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ

    at_yasu
    at_yasu 2010/09/23
    「シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。」
  • Date Variable Formatting — ExpressionEngine 7 Documentation

    at_yasu
    at_yasu 2010/06/30
    date formmat
  • Fine Software Writings

    最近のもの 目標でなく恐怖を明確にすべき理由 (Tim Ferriss) 我々が築き、掘っている未来 (Elon Musk) 表計算ソフト誕生の話 (Dan Bricklin) Linuxの背後にある精神 (Linus Torvalds) 先延ばし魔の頭の中はどうなっているか (Tim Urban) 好きになる仕事はどうしたら見つかるのか (Scott Dinsmore) 人間に新たな感覚を作り出すことは可能か? (David Eagleman) 人工知能が人間より高い知性を持つようになったとき何が起きるか? (Nick Bostrom) 厄介な問題を解決したい? ではトーストの作り方を説明してください (Tom Wujec) 子供の夢を奪う学校というシステム (Seth Godin) 彼らがいなくなってしまう前に (Jimmy Nelson) 頭良さそうにTED風プレゼンをする方法 (W

  • いいアジャイルと悪いアジャイル

    スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見

  • 日本のソフトウェア産業は「製造業」 - My Life After MIT Sloan

    これは、MIT SloanのCusumano先生がでも授業でもよく言ってる話。 面白いから忘れないうちに書き記しておく。 Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。 日の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日通でもある。 そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。 Europe: Software as a science -ヨーロッパにとってソフトウェアは「科学」 Japan: Software as production -日のソフトウェアは「製造業」 India: Software as a service -インドのソフトウェア産業は「(プロフェッショナル)サービス」 U.S.: Soft

  • Accessories - Apple Developer

  • COBOLこそスピード経営に必要

    家電通販最大手のジャパネットたかた。同社における開発言語のメインはCOBOLだ。通信販売で取り扱う商品は日々追加され、客先でのセッティングといった付帯サービスも多様化している。情報システムを統括する星井龍也専務執行役員は、「こうした状況変化に迅速に対応するためには、COBOLの高い生産性が必要だ」と語る。(聞き手は井上英明=日経コンピュータ、写真は林田大輔) メインの開発言語にCOBOLを据えていると聞く。 2008年1月、基幹システムをメインフレームからUNIXサーバーにオープン化するプロジェクトを開始する際に、「当社はメインの開発言語をCOBOLとする」と宣言しました。26人いる情報システム部員の全員が、COBOLを読み書きできるようにしています。それまでは、COBOLを読み書きできる部員は3人だけでした。 当社のシステムにおいて基幹となるのは、販売管理システムです。お客様からの注文や

    COBOLこそスピード経営に必要
    at_yasu
    at_yasu 2010/03/24
    基幹がCOBOLだからCOBOLにすると速くなるという話かしら。これ移行時が大変だな。
  • プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集

    印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。彼らの考え方については、面接時に少しやり取りを行えばそれなりに見当が付くだろう。しかし、実際のプログラミング経験を推し量るのは至難の業だ。一部の企業では、さまざまなテストを実施することでこれを行おうとするものの、筆者の経験から言えば、こういったテストは近代的な開発環境では必要性が薄い知識(IDEのオートコンプリート機能や、F1キーの押下で表示されるヘルプ、インターネットといったものがあるため、ライブラリの知識は以前ほど重要ではなくなっている)の丸暗記能力を試すだけに終わることも多い。そこで記事では、開発者を評価するうえ

    プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集
  • https://srad.jp/story/09/05/04/0350234/

    at_yasu
    at_yasu 2009/05/04
    もうやらなくていい昔のcoding technickの話
  • OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん

    OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr

    OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん
    at_yasu
    at_yasu 2008/12/04
    OMakeの事。使ってみないと分からないなあ…
  • http://ja.doukaku.org/

  • プログラミング言語 C の新機能

    プログラミング言語 C は 1990 年に ISO で規格化された言語です。その後、何度かの誤りの訂正や wchar_t 型の追加といった追補がなされた後、さらに使いやすくするための新しい機能が検討されてきました。そして、1999 年、ついに新しいプログラミング言語 C の仕様「ISO/IEC 9899:1999 - Programming Language C」(略称 C99) が 1999/12/01 付けで規格として出版されました。ここでは、その新機能を説明します。