オブジェクト指向のハードコアは2019年5月25日にゼロベースサロンで行われたイベントです。「オブジェクト指向」というキーワードについて、プログラミング、デザイン、哲学などの分野を横断しつつ知的な議論ができました。 https://www.zerobase.jp/salon/2019/05/25/hardcore...
![オブジェクト指向のハードコア](https://cdn-ak-scissors.b.st-hatena.com/image/square/0c60ea8deca5ba37805c59ca81e36bdf93840a12/height=288;version=1;width=512/https%3A%2F%2Fi.ytimg.com%2Fvi%2FWrJ7em1S6WA%2Fhqdefault.jpg%3Fsqp%3D-oaymwEWCMQBEG5IWvKriqkDCQgBFQAAiEIYAQ%3D%3D%26rs%3DAOn4CLCnbcabf5BVb4gfhpzNdQfceQpfdw%26days_since_epoch%3D19863)
LatestGo slices package written Go for loop updated Java FileReader updated Python decorators updated Java filter map updated Java enum type written Java Function written F# print functions written Tkinter Python programming ebook. AuthorMy name is Jan Bodnar and I am a passionate programmer with many years of programming experience. I have been writing programming articles since 2007. So far, I h
Hello, world! Refactoring.Guru makes it easy for you to discover everything you need to know about refactoring, design patterns, SOLID principles, and other smart programming topics. This site shows you the big picture, how all these subjects intersect, work together, and are still relevant. I don’t pretend to be the inventor of these concepts—most of them were invented by others during the past 2
違うと断定していいかどうかは、なんつーか「歴史的事情」てのもありそうだし、(ワタシがここで言おうとしている)文脈依存なのね。 Python 翻訳の Transifex 用語集でこう定義されていてずっと違和感あってしょうがなかったんで、改めて考察してみた。 まず「日本語におけるテクニカルターム」としての実引数、仮引数の違いは、「方向」の違いである。つーか、「らしい」。なんせアタシは「コンピュータ的な正規の教育」は、大学時代の Fortran のためのものだけだったし、これを教わった記憶は確かにあるものの、もう20年近く前ですもの、忘れていたさ。簡単だよ、これだけのこと: 仮引数は「受け取り手目線」(渡せよ、をらぁ) 実引数は「呼び出し側目線」(受け取れや、ごるぁ) で、WikiPedia での説明では英語との対応をこう説明している: 仮引数: parameter、formal paramet
みんな割と未来の予言はよくするが、あんまりその結果を振り返らんよなぁ。 現在のディープラーニングのブームをどう捉えるか、というか、 プログラマのキャリアという点でどう接していくか、を考えるにあたり、 過去のブームを考えてみるのは良いんじゃないか、という気がした。 最近並列GCや並行GCの章を読んでいて、 一昔前の大きなブームとしてはParallel computingがあったなぁ、と思い出した。 ということでこの事について、専門にしてなかった部外者プログラマの目にどう映ったかを記しておきたい。 なお、「XXXだと言われていた」はあんまりソースとかを確認したりはしてません。 なんとなく自分はそう聞いていた気がしたしそう思ってた、程度のものです。 かつて思っていたことと当時の状況 Parallel computingはだいたい10年くらい前の時点ではその後の大きなトレンドとして明らかに存在して
When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. A good architecture is important, otherwise it becomes slower and more expensive to add new capabilities in the future. Like many in the software world, I’ve long been wary of the term “architecture” as it often suggests a
きしださんの以下のツイート オブジェクト指向はこの20年だれも再定義せずみんな自分の思うオブジェクト指向を暗黙に仮定して適当に話してるだけなので、技術的な共通認識のもとの議論はほとんどできないんですよ。という話を「オブジェクト指向をきちんと使いたいあなたへ」の記事に書いたのだけど、そろそろ公開するか— きしだൠ(K8S(Kishidades)) (@kis) July 29, 2019 を読んで、そういえば、私が思うオブジェクト指向の定義、についてツイッター以外ではあまり語ったことがなかったなと思い返し、ちょっと記事にしてみることにしました。まず、結論からいうと、私はオブジェクト指向プログラミングとは サブタイピングを活用したプログラミング手法の総称 と考えています。ここで、クラス継承とかインタフェース継承とかダックタイピングとかではなく、単にサブタイピングであるのがポイントです。なお、型
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
※ 2019年7月27日に追記しました。 この記事の最後に、失敗談の補足を書いた記事へのリンクを追加しました。 システムの一部機能を改修するテーマが現在進行中です。テーマは他の箇所に影響がないくらいに分離できるものです。この大きさが丁度いい。チャンスとばかりにリファクタリングすることにしました。 アプリケーションはそれなりにレイヤー化されています。controllerとserviceとrepositoryがある。よくある3層構造です。何を見直して再設計するのか?それはドメインオブジェクトモデルの構築です。 現状のアプリケーションはビジネスロジックをモデリングしたものとは言えない状態です。自分がやったのだけれど。しかしだからでもあります。なぜこうなったかを振り返り、どのようにできたかを考えます。失敗から学べることもあるはずです。 参照側の層は薄く?本当に? 開発対象のシステムはある情報の検索
基本はオフセットベースで実装することになるが、カーソルベースの方が性能的には有利なので、カーソルベースページネーションにできないかは常に検討する。
Dismiss Join GitHub today GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together. Sign up What's this about After working on different projects, I've noticed that every one of them had some common problems, regardless of domain, architecture, code convention and so on. Those problems weren't challenging, just a tedious ro
プログラムの入門としての抽象化の話をします。ベテラン向けじゃないんで、ベテランの人は読んでも新しい事は無いと思います。 データ分析界隈だと、数学や物理などで抽象的な事というのには良く出会ってきた経験を持つので、抽象的な物は得意な方だ、という人は多いと思うし、実際そうだと思う。 ただ、プログラムの抽象化は違う部分もあるので、一度プログラムの抽象化という物を初心者の気持ちになって学んでみる機会は必要とも思う。 ここではそんな話をしてみる。 カプセル化 プログラムの抽象化と言えばカプセル化なのだが、いまいち良い解説が無いので自分で書く事にする。 一般的な事は知らないけれど、プログラムにおいては、抽象化の定義は「情報を落とす」事となっている。 全ての情報を持っている所から、特定の情報だけにする事でアクセスする「口」を定める訳だ。 だからだいたいの抽象化は物を「削る」のだけど、一つだけ例外がある そ
はじめに この記事は、僕が配属当初に先輩からよく言われた「ソースコードはしゃべるように書け」について、それが具体的に何を意味するのかを、配属から6年経った今改めて考えてみる記事です。 その先輩はすでに辞め新しいステップへ進まれてしまったためにその真意を直接聞き直して確認することはできないのですが、今の僕なりの解釈、ということで書いてみます。 とは言え、「ソースコードはしゃべるように書け」は「ソースコードの読みやすさ」という意味では役に立つ考え方ですが、それがどんな場面でも正しいかというとそうではないと思っています。おそらく、自然言語に近づけた書き方よりも、より機械の仕組みに近づけた書き方をした方がはるかに効率がよかったり、安全な言語や場面もあると思います。 また、仕様自体が複雑だったり、既存のソースがすでに汚いなどの理由で、この記事に書いたようなことがすんなり実行できる環境というもの自体が
プログラムからJSONを出力する場合、Object内のkeyの順番が固定されている保証はない。二つのJSONを比較したい場合、出力のたびにkeyの順番が違うとdiffを使ってもうまく比較できない。 jqのオプションで--sort-keysオプションを使用すると、各オブジェクトのkeyを並び替えて出力してくれるため、JSONをjqで整形したうえでdiffするといい。 --sort-keys / -S: Output the fields of each object with the keys in sorted order. $ diff <(./JSON出力プログラム | jq . --sort-keys) <(./JSON出力プログラム | jq . --sort-keys)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く