Movatterモバイル変換


[0]ホーム

URL:


はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

はてなブックマーク

タグ

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

タグの絞り込みを解除

アーキテクチャに関するlegobokuのブックマーク (5)

  • legoboku
    legoboku2013/01/06非公開
    詳細はCESで発表か。日本発で大化けするデバイスになる?
    • 事前設計とTDD - 2012-12-16 - やっとむでぽん

      実はモデリングが大好きです。元々はオブジェクト指向プログラミングを勉強しているところからUMLに(自然に)興味が向き、そこからオブジェクト指向設計とかオブジェクト指向分析とかそういう脇道にそれ(脇道とか言ったら怒られる!)、仕様も設計もこれからはオブジェクト指向だ!というありがちな若気の至りもありました。デザインパターンにも転んだし、責務!ロール!コラボレーション!ってのもやったし、重厚長大なフレームワークとかもなかなか楽しいですよねえ。ねえ? 今でも概念モデルとか大好物で、上の話を聞きながらうっかりとこんなオブジェクトモデリングをしてしまったりします。 そんなわけで、プログラミングする対象の仕様を理解しながら頭の中でモデリングして設計を進めてしまうのはやむを得ません。多かれ少なかれ、なにかしらの設計が浮かんできてしまいます。 でもTDDはテストを書きながら設計をします。先行して設計してし

      事前設計とTDD - 2012-12-16 - やっとむでぽん
      legoboku
      legoboku2012/12/21非公開
      「少なくともアーキテクチャ像が必要だ。そうしたアーキテクチャはTDDで積み上げた結果出来上がるものではなく、ユースケースやクライアントとの対話から創出されるものだ。」
      • 組み込みもけっこう末路なのかもしれない

        業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道 業務系に限らず、組み込み系もけっこう先行きは明るくないと思う。 メーカーの下請けでやってるようなところだと ・メーカーの予算削減で人員は減るが仕事量は変わらない ・むしろシステムの高機能化でアーキテクチャは複雑になる ・しかし一つの製品の納期はどんどん短くなる ・メーカー側もコスト面から製品に対して人員を割かなくなるので、メーカー側の社員が手が回らず下請けに丸投げしだす ・請け側の会社も仕事が少しでもあるところにスキルをあまり考えずに要員を投入する はい、デスマ。 発注側も受け側も余裕が無くなっていて、それでも請けるほうは仕事無いから請けるしか無くて、だいたい当初の想定通りのフェーズや要因で炎上する。で、年中残業やら休日出勤やらで疲弊するエンジニア。 請ける側にも多分に問題はあって、マネジメントできない人がマネジメントをし、設計

        組み込みもけっこう末路なのかもしれない
        legoboku
        legoboku2012/10/16非公開
        “スキルのある人、職人芸を持ってるような人は中長期的にメーカー側から指名でお抱えしてもらえることは割と多いようだけど、それ以外の大多数は中、中の下くらいのスキルなので辛い割には先の見えない状況”
        • CPUのアーキテクチャをトイレに例えると | Hinemosu

          おもろい。たとえ方がうまいなぁ。 消え気味なのでコピペ。 155 :・良く分かるパイプライン :04/04/26 17:20 ID:B6tZVOSS 「おしっこをして手をあらってでてくる」。 トイレが一室しかないと混雑時は長蛇の列ができます。 1.おしっこをする 2.手を洗う。 二段のパイプにすると、手を洗ってる間に別の人が用を足せるようになります。 トイレ一室で二人が気持ちよくなれて、効率が倍になります。 もうすこし深くしてみましょう。 1.ジッパーを下げる 2.ちんちんとりだす 3.放尿する 4.しずくを切ってちんちんしまう。 5.ジッパーをあげる 6.手を洗う 7.紙を使って手をふく 7ステージに分解すると、なんと 7人が同時に処理できます。 これがパイプラインです。 156 :・良く分かるスーパスケーラ :04/04/26 17:21 ID:B6tZVOSS トイレの利用はおしっこ

          CPUのアーキテクチャをトイレに例えると | Hinemosu
          • ソフトウェア・エンジニアから見た原発事故

            私はこれまでこのブログで、今回の原発事故が「想定外の津波によって起こされた天災」ではなく、「来想定すべき天災に対する対処を先送りして来たことによる人災」であったこと、そして、形だけの津波対策や地震対策をしたところで、「規制機関が電力業界と癒着して利権構造を作っている」という根的・構造的な問題を抱えている限りは、同じような事故が必ずまた起こることを指摘してきた。 こんな私の指摘に対しては、「原子力の専門家でもない、シアトルに住むソフトウェア・エンジニアの戯言(たわごと)に過ぎない」と言う指摘もしばしばいただいたが、エンジニアに不可欠な「システマティックにものを見る能力」のある人であれば、原子力の専門家でなくとも、これぐらいのことは言える。 別の言い方をすれば、事故に関して公開されている限られた情報だけで、その根の原因がどこにあったのか、そして、このまま原発を再稼働することがどのくらい危

            legoboku
            legoboku2012/07/08非公開
            福島原発での事故の原因をソフトウェアの比喩で解説。アーキテクチャの問題を解決せずに再稼働しても同じ問題が起きる。
            • 残りのブックマークを読み込んでいます1

            お知らせ

            公式Twitter

            • @HatenaBookmark

              リリース、障害情報などのサービスのお知らせ

            • @hatebu

              最新の人気エントリーの配信

            処理を実行中です

            キーボードショートカット一覧

            j次のブックマーク

            k前のブックマーク

            lあとで読む

            eコメント一覧を開く

            oページを開く

            はてなブックマーク

            公式Twitter

            はてなのサービス

            • App Storeからダウンロード
            • Google Playで手に入れよう
            Copyright © 2005-2025Hatena. All Rights Reserved.
            設定を変更しましたx

            [8]ページ先頭

            ©2009-2025 Movatter.jp