タグ

プログラミングに関するkawa-_-kawaのブックマーク (24)

  • レイヤードアーキテクチャ - kawasima

    POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた

    レイヤードアーキテクチャ - kawasima
    kawa-_-kawa
    kawa-_-kawa 2020/09/18
    レイヤードアーキテクチャの本質は、下位レイヤーは「機能」を持っており、上位レイヤーからみることによってのみ「意味」を得られるということ。抽象化を本質と捉えると混乱するだけだと思う。
  • NoCodeと負の遺産 - 西尾泰和のScrapbox

    Excel VBAマクロは負の遺産になったわけだけど、いわゆるNoCodeやRPAの類が負の遺産にならないにはどういう条件が必要なのかなぁ おそらくロジックがローカルファイル+奥まったところにあってなかなか見えないからVBAは負の遺産化したのだと思うのだけど、サーバで管理すればそれが回避できるか?

    NoCodeと負の遺産 - 西尾泰和のScrapbox
    kawa-_-kawa
    kawa-_-kawa 2020/07/22
    こういう議論いいね。全部うなづくことばかりだ。
  • ペアリング対コードレビュー: 開発者文化の比較

    前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって

  • Visual Studioを、VSCodeのコード補完や文法チェックを実現するLanguage Server Protocol対応にする拡張機能が登場 - Publickey

    Visual StudioをLanguage Server Protocol対応にする拡張機能が発表された。Visual Studioがネイティブに対応していないプログラミング言語でも、構文ハイライトやコード補完などが利用可能になる。 マイクロソフトがオープンソースで開発しているエディタ「Visual Studio Code」(以下VSCode)には、さまざまなプログラミング言語に対応してリアルタイムに構文のハイライトや文法チェック、コード補完などを行う機能が備わっています。 これはVSCodeのエディタとは切り離され、別プロセスで動いているLanguage Serverが処理を行い、それをエディタに伝えることで実現しています。そしてエディタとLanguage ServerはJSONベースの「Language Server Protocol」で通信を行っています。 マイクロソフトはこのLa

    Visual Studioを、VSCodeのコード補完や文法チェックを実現するLanguage Server Protocol対応にする拡張機能が登場 - Publickey
    kawa-_-kawa
    kawa-_-kawa 2017/11/28
    すごいな!そう来たか!!
  • SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ

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

    SEとPG、どっちが頭がいい?(2):下流から見たIT業界:エンジニアライフ
    kawa-_-kawa
    kawa-_-kawa 2017/08/23
    “いくら見かけのドキュメントを整備しても、それは顧客の要求だけが精緻に文書化されたというに過ぎず、それによってソフトウェアの品質をコントロールしているわけではありません。”
  • 「スキル伝授にはペアプロが最速」というのは何故か - 圧倒亭グランパのブログ

    この問いに対して、自分なりの答えを言語化できたのでまとめます。 目次 目次 疑問 実践する機会 自分なりの答え 「コードを書く瞬間の思考」にアドバイスを貰える 他の方法で代替できない ペアプロの欠点 まとめ 疑問 きっかけは、下記の方々のやり取りをTwitterで見かけたからです。 「それをできる人とペアプロする」以上に短期間で新しい技術を身につける方法を知らない。— Jxck (@Jxck_) 2017年2月3日 ペアプロが最速だろうなあ https://t.co/SdbZZ2EypI— Takuto Wada (@t_wada) 2017年2月3日 サッと調べると「最速なのは同意」という意見が大半でした。自分もこれには同意するのですが、「なぜペアプロが最速なのか?」という疑問を持ったのです。 ペアプロ、最速だと思うんだけど、なぜ最速なのかがハッキリわからない。「わからないことがすぐに聞

    「スキル伝授にはペアプロが最速」というのは何故か - 圧倒亭グランパのブログ
  • Lispのアイデア | POSTD

    Lispと聞くと、冷蔵庫のような大きいサイズのコンピュータや、大文字のアルファベット文字列や括弧の並びといったような過去の時代のことが頭に浮かびます。そう、非常に多くの括弧。何故、オブジェクト指向プログラミングの作成者たちは、そんなにもLispの アイデア に魅了されるのでしょうか。そしてまた、アイデアとされるプログラミング言語というものは、どうやったら説明できるでしょうか。こうしたことを教えてくれなかったコンピュータ科学の教育を責めるべきでしょうか。 Lispは、John McCarthyが書いた Recursive Functions of Symbolic Expressions and Their Interpretation by Machines, Part I という論文によって、初めて世界に登場しました。その中で、McCarthyはプログラミングに新しい多くのアイデアを導入

    Lispのアイデア | POSTD
  • apollo11号のソースコードを読みつつ - aerith7’s blog

    これはなに? はじめに AGCあれこれ Temporary I HOPEHOPEHOPE ASTRONAUT NOW LOOK WHERE YOU ENDED UP ふと気になりました いい時代ですね 1201&1202エラー なにそれ? カ、カルマンフィルターだー!!! カルマンフィルターの開発経緯 その他面白コメントアウト集 TRASHY LITTLE SUBROUTINES(つまんないサブルーチン) NUMERO MYSTERIOSO(神秘の数字) OFF TO SEE THE WIZARD COME AGAIN SOON HONI SOIT QUI MAL Y PENSE(悪意を抱く者に災いあれ)、NOLI ME TANGERE(私に触れるな) PINBALL_GAME_BUTTONS_AND_LIGHTS.agc おわりに 反省 参考文献 これはなに? この記事はeeic Adv

    apollo11号のソースコードを読みつつ - aerith7’s blog
  • Scalaの学習コストを下げるための心得 - kmizuの日記

    追記:Twitterで、「それって、言語マニアにしかできない技のような気が」という指摘を受けました。自分としては一般的に適用可能な話だと思っていますが、あるいは自分の感性が著しくずれているのかもしれません。その辺承知の上でお読みください。 Scalaは習得が難しい言語だ、とよく言われます。また、実際問題として、Scalaの言語仕様の全体はそれなりに複雑でもあります。しかし、それはたとえばJavaでも言語仕様の全体像を把握するのは難しい話であり、Scalaに限った話ではありません。にも関わらず、Scalaの習得が難しいとよく言われるのはプログラミング言語の学習モデルが誤っているからではないかと最近思うようになりました。そこで、Scala(や他の言語も含めて)のコストを下げるために必要な心得についてちょっと書いてみます。 Scalaはオブジェクト指向言語である これは、Scalaは関数型プログ

    Scalaの学習コストを下げるための心得 - kmizuの日記
  • 30年かけてたどり着いた、私のとっておきのプログラミングスタイル

    私なりの「時間の使い方」のベースは、ソフトウェア・エンジニアとして、いくつものプロジェクトに関わってきた結果辿り着いた、「必ず締め切りは守る」仕事の仕方にある。

    30年かけてたどり着いた、私のとっておきのプログラミングスタイル
  • フリーエンジニアのIT案件ならレバテックフリーランス

    Scalaは、オブジェクト指向と関数型の特徴を兼備するプログラミング言語です。簡潔で柔軟性の高いコーディングが行えるため、高く評価されています。採用例としては、国内ならニコニコ動画やChatwork、海外ならTwitterやLinkedIn、Foursquareといった大規模なサービスが挙げられます。 Scala関連の記事は徐々に増加していますが、人気が高いJavaなどのプログラミング言語と比較するとまだまだ情報は少ないです。そこで記事では、これからScalaを学習する方の参考になる記事やサイト、スライドをまとめて紹介します。「Scalaに興味があるけど、情報が少なくて勉強しにくい」という方は、ぜひ参考にしてください。 また、Scalaエンジニア仕事内容、年収、将来性などに興味をお持ちの方は、以下の記事もご覧ください。 関連記事 : Scalaエンジニア年収|人気や将来性、入門時に学

    フリーエンジニアのIT案件ならレバテックフリーランス
  • Blue. No! Yellow! : プログラミング言語の進歩史と生産性にまつわる問答 | POSTD

    世界初のプログラム内蔵方式コンピュータに搭載された、最初のプログラムを書くのに使われた言語は何だったでしょうか? もちろん、バイナリの機械語です。 なぜですか? えー、当然ながら、シンボリックアセンブラがなかったからです。最初期のプログラムは、バイナリで書かなければなりませんでした。 バイナリの機械語と比較して、アセンブリ言語でプログラムを書くと、どのくらい簡単ですか? ずっと 簡単です。 数字を言ってください。何倍ぐらい簡単ですか? えー、まあ、アセンブラは、あなたの代わりに面倒な事務処理を全てしてくれますからね。つまり、全ての物理アドレスの計算です。全ての物理的な命令を構築するわけです。あなたが範囲外にアドレス指定するなど、物理的に不可能なことをしないよう確認します。そして、簡単にロードできるバイナリの出力を生成します。 それによって、軽減されたワークロードは、 膨大 です。 どのくら

    Blue. No! Yellow! : プログラミング言語の進歩史と生産性にまつわる問答 | POSTD
  • 海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方3つ - ジンジャー研究室

    プログラミングに関する格言みたいなのは昔から結構あって、例えばYAGNIみたいに日でも十分浸透してるのは多いんだけど、やっぱり新しい概念はどんどん生まれていくので追いかけていると面白い。 というわけで、最近知った中でもっと日でも言及されても良いと思ったやつを3つ紹介。 Simple Made Easy Rich Hickey(Clojure言語の作者)による講演(2011年)のタイトル。全文はここで読める。英語しんどくてPOSTDに投げたんだけど音沙汰がない。まだ全部見てないから和訳欲しい。 内容としては、みんな安易に「簡単」なものを選びがちだけど「シンプル」なものの方が価値あるぜ、というもの。曰く、「シンプル」は絶対的・客観的な指標だけど「簡単」は相対的・主観的なもの。例えば英語の話者にとってドイツ語は難しいが、それは自分にとって「遠い」存在であるだけで悪いものじゃない。 「慣れてい

    海外エンジニアが話題にしていて「なるほど」と思ったプログラミングに関する考え方3つ - ジンジャー研究室
  • 【連載企画!】1ヶ月でプログラミングを習得する方法とは

    【連載企画!】1ヶ月でプログラミングを習得する方法とは キャリアに特化したQ&AサービスJobQとのコラボで、1ヶ月間集中してプログラミングを習得するための方法を紹介しています。少し長い休みでプログラミングを勉強したいと考えている人はぜひ参考にしてみてください。 テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元:GMOリサーチ株式会社 調査期間:2021年8月12日~8月16日  調査対象:2020年8月以降にプログラミングスクールを受講した18~80歳の男女1,000名  調査手法:インターネット調査 記事は、キャリアに特化したQ&Aサービス「JobQ」との連載企画になります。毎週月曜日に転職起業など、様々なテーマに沿って紹介し

    【連載企画!】1ヶ月でプログラミングを習得する方法とは
    kawa-_-kawa
    kawa-_-kawa 2016/05/24
    “技術の性質上学んだ知識は割とすぐに使えなくなります。 知識を蓄積させるというより、知識の獲得速度をあげるって感じです。”
  • オブジェクト指向関連書籍リスト - give IT a try

    自分はどれくらいオブジェクト指向について勉強してきたんだろう?というのを整理する意味で、これまでに読んできたオブジェクト指向関連のをまとめてみます。 エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION) 作者: マーチン・ファウラー,長瀬嘉秀,株式会社テクノロジックアート出版社/メーカー: 翔泳社発売日: 2005/04/21メディア: 大型購入: 10人 クリック: 635回この商品を含むブログ (143件) を見る企業向けシステムをオブジェクト指向で設計するときに有用なです。ドメインロジックの3パターンは必ず押さえておきたいですね。 実践UML 第3版 オブジェクト指向分析設計と反復型開発入門 作者: クレーグ・ラーマン,依田智夫,今野睦,依田光江出版社/メーカー: ピアソンエデュケーション発売日: 2007/11/12

    オブジェクト指向関連書籍リスト - give IT a try
  • DDDで設計するならCQRSの利用を検討すべき - Qiita

    タイトルに書かれていることで全てなのですが、DDDとCQRSの併用について強調している日語の情報が少ないので、軽くまとめておきます。 CQRS+DDD CQRS(コマンドクエリ責務分離)とは、サーバの機能を「コマンド」(副作用あり)と「クエリ」(副作用なし)で完全に分けちゃおう、という考え方です。そもそも「コマンド」と「クエリ」ではあらゆる要件が異なります。 一貫性: 「コマンド」は整合性のある処理が必要、「クエリ」はあまり気にする必要なし ストレージ: 「コマンド」側は正規化してデータを保存したい、「クエリ」側は非正規な方が効率的 スケーラビリティ: 「コマンド」は全体の負荷の中で占める割合が少ない、「クエリ」は負荷が大きい なので分けちゃうわけですが、 コマンド側 複雑なビジネスロジックが絡むので、ドメイン駆動が活躍 クエリ側 複雑なビジネスロジックがないので、ドメイン層はスキップ

    DDDで設計するならCQRSの利用を検討すべき - Qiita
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

    dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
  • サークルで初心者向けにプログラミングの話とかをする際にちょっと考えてみたいことについて発表した - ぱすたけ日記

    はじめに ちょっと前の話なのですが、僕の所属している京大マイコンクラブの新入生向け説明会で講座*1をやらせてもらったので、その内容について書いていきます。 スライドを公開するだけでも良かったのですが、スライドだけだと伝わりづらいこともあるかと思ったのでブログで補足しようという作戦です。 スライドはこちら モチベーション 講座やってくれと言われてから何について話すか考えてて、昨年はわくわくシンセサイザー入門というタイトルでWeb Audio APIについて話したけど、この時期に来る新入生はコードを書いたこともない人が多かったので、具体的なAPIなどを紹介するのではなくて何かしら精神っぽいエモさあるトークをしようという方針を立てた。 ちょうどそろそろスライドを作るかというタイミングでたまたま部室居たら、サークルの若者たちが競技プログラミングを始める新入生に向けたC++のスライドのレビュー会をし

    サークルで初心者向けにプログラミングの話とかをする際にちょっと考えてみたいことについて発表した - ぱすたけ日記
  • .NET開発者がよく使うサイト、本当に使えるサイト【2016年度版】

    .NET開発者がよく使うサイト、当に使えるサイト【2016年度版】:特集:.NET開発者のためのオンラインリソースガイド(1/2 ページ) Web上には.NET関連サイトが数え切れないほどたくさんある。その中でも.NET開発初心者がまずは押さえておきたいWebサイトを厳選してまとめた。 稿は、これから.NETでプログラミングを始めようとしている方や、新しく.NETでの開発に携わることになった方に贈るオンラインリソースガイドの2016年度版である。インターネット上に数ある.NET関連サイト/プログラミング関連サイトの中で、.NET開発者がまずは押さえておくべきWebサイトについてまとめている。 稿がまとめているサイト&ジャンル分けについて .NET開発者がよく利用するサイトの代表は、やはり.NET Framework & Visual Studioを提供するマイクロソフトのサイトだろう

    .NET開発者がよく使うサイト、本当に使えるサイト【2016年度版】
  • Greg Young流CQRS - Mark Nijhof - Digital Romanticism

    この記事はMark Nijhof氏のブログ記事「CQRS à la Greg Young」を氏の許可を得て翻訳したものです。(原文公開日:2009/11/11) この記事は以前のブログである"blog.fohjin.com"にて公開していたものです。 以前、2日間の講習を受けた時に、ビールを飲みながらGreg Young氏とドメイン駆動設計について語るという幸運に恵まれたことがあります。その時の話題は専ら、コマンドクエリ責務分離(CQRS:Command and Query Responsibility Segregation)パターンに関するものでした。Gregは、Eric Evans氏が著作において説明したドメイン駆動設計を受け継ぎ、主に技術的な実装を進化させています。コマンドクエリ分離(CQS)は元々Bertrand Meyer氏によって考案されたもので、オブジェクトのレベルで適用さ

    Greg Young流CQRS - Mark Nijhof - Digital Romanticism