タグ

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

  • 関連タグはありません

タグの絞り込みを解除

Javaとprogrammingとdesignに関するraimon49のブックマーク (61)

  • 17. Gauche Schemeの基本デザインの選択理由、オブジェクトデータベース、浮動小数点数の落とし穴

    プログラミング言語を作る時には、途中で変えることが極めて難しいデザイン選択を最初に行わないといけないことがあります。今回は川合史朗さんがGaucheを設計した時に行ったデザイン選択の判断について話を伺いました。また、浮動小数点数のトリッキーさについても話をしています。出演者: 川合史朗 (@anohana)、Rui Ueyama (@rui314) https://turingcomplete.fm/17 ハッシュタグは#tcfmです。 TCFMはサポーターの投げ銭によって収益を上げています。このコンテンツに課金してもいいよという方はぜひクリエイター支援サイトPatreonから登録してご協力ください。 イントロ (0:00) セキュキャン参加者募集中 (0:41) 俳優のオーディションとその心構え (2:43) 川合史朗さんが出演している映画がサンフランシスコで上映されます (5:16)

    17. Gauche Schemeの基本デザインの選択理由、オブジェクトデータベース、浮動小数点数の落とし穴
    raimon49
    raimon49 2018/10/24
    Futureは未来というよりは先物の概念。将来こうしますという取引の約束。
  • GitHub - fbeline/Design-Patterns-JS: All the 23 (GoF) design patterns implemented in Javascript

    Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case. Abstract factory: provide an interface for creating families of related or dependent objects without specifying their concrete classes. Builder: separate the construction of a complex o

    GitHub - fbeline/Design-Patterns-JS: All the 23 (GoF) design patterns implemented in Javascript
    raimon49
    raimon49 2018/10/23
    JavaScriptでGoFデザインパターン。ES6での実装例もある。
  • オブジェクト指向の呪いと、その避け方 - mizchi's blog

    このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

    オブジェクト指向の呪いと、その避け方 - mizchi's blog
  • 私と型システムとポエム

    最近巷では俄に型システムについての言及が増え、型システムポエマーが増えてる気がするので自分もその時流に乗りたい。 完全にポエムだけどなんかあったら随時指摘ください。直します。 TL;DR 言いたいことはまとめると次 型システムは程度問題なのでちょうどいいところを探すべき 型は万能でも強さが正義でもない(だから未だに研究されてる) よく知りもしないくせに計算機科学を侮辱するのはやめろ 予防線 あくまでポエムですので中身はないです 私は型理論専攻で学位はとったものの研究者ではないのであまり信用しすぎないように 型システムの過去 型システムは大まかに次のような利点があるとされてきた(個人的主観) 「異常」なプログラムを検出する仕組み 静的解析による分かりやすいエラーメッセージ 型そのもののドキュメント性 IDEでのcompletionに貢献 最適化に貢献 (数学に正しく裏打ちされたsemanti

  • Java SE 9の紹介: モジュール・システムを中心に

    Java SE 9を、新たに導入されたモジュール・システム(Jigsaw)を中心として紹介します。JJUG CCC 2017 Fallの発表資料です。 補足: p. 7 正しくは「JMX」→「JMS (Java Message Service)」。JMXはJava SE内の、モニタリング用の仕組みです。 p. 43 これに加えて、SPIの実装を提供するモジュールも、モジュールレイヤーに含まれます。具体的にはConfiguration.resolveAndBindの動きです。 p. 47「Oracle JDKでは、外部モジュールの非公開メンバへのリフレクションが可能」は、OpenJDKでも同じ動作です。「HotSpot系の」とすべきところでした。 このスライドはCC Attribution Licenseの元に、利用・改変・再配布をライセンスします。

    Java SE 9の紹介: モジュール・システムを中心に
    raimon49
    raimon49 2017/11/19
    module-info.java回り。openなモジュール全体 or opens命令されたパッケージでなければリフレクションでアクセスできない。
  • 読みやすいコード(僕にとって) - Mitsuyuki.Shiiba

    最近気づいたことがある。それは、僕はみんなみたいに複雑なことが理解できない、ってこと。 話をしてても「ごめんなさい。いまのわかんなかった。もう一回教えて欲しい。」とかよくあるし。ドキュメントも、ちょっと複雑なことが書いてあると、全然頭に入ってこない。 色んなルールがドキュメントに書いてあって、それをちゃんと守りながら開発してる人たちとか見てると、みんなすごいなぁって思うのであった。 なんだろうなぁ。こう・・・色んな想像が始まってしまって、考えが落ち着かないんよね。 そんな僕なのだけど、ここ数年はありがたいことに色んなコードを読む機会がある。読みやすいコードもあれば、パズルみたいに複雑なものもあって。そんな中で、たぶん、僕にとって読みやすいコード、というのは普通の人にとってはとても読みやすいコードなのかなぁって思って。書いてみる。 JavaでWebのアプリを開発してる。基盤とかフレームワーク

    読みやすいコード(僕にとって) - Mitsuyuki.Shiiba
  • Rubyはどのように生まれ、世界へ羽ばたいていったのか?まつもとゆきひろさん講演会の全貌をレポート – NET BIZ DIV. TECH BLOG

    どうですか? Rubyって新参者のイメージがあると思うんですけど、実はJavaと同じぐらい古いんですよ。 ちなみに、World Wide Webの原型になるものが作られたのは1990年だったそうです。Rubyを作りはじめた当時の1993年の時点では、World Wide Web自体は存在はしていたのですが、世間一般にはほとんど認知されていませんでした。つまり、冒頭でも申し上げたとおり、Rubyはweb用に開発されたわけではなかったのです。 当時すでに先輩としてPerlという言語があったのですが、その代わりになるような言語を作りたかった。でも単にまったく同じものを作ってもしょうがない。その頃の私はオブジェクト指向に傾倒していたので、こう考えました。 「オブジェクト指向に基づいて言語をデザインすることで、既存のものよりも良い言語が作れるんじゃないか」 ―― それがRubyの始まりです。 国際色

    Rubyはどのように生まれ、世界へ羽ばたいていったのか?まつもとゆきひろさん講演会の全貌をレポート – NET BIZ DIV. TECH BLOG
    raimon49
    raimon49 2017/10/02
    自分のアイディアと信念を曲げない、名誉・功績・評価は独占せず貢献した人に譲る。
  • How to start Kotlin APP DOJO

    今から始めるKotlinによるAndroidアプリ開発 2017/08/29 APP DOJO August 2017 @ Google Japan

    How to start Kotlin APP DOJO
    raimon49
    raimon49 2017/08/30
    Data classやNullableの話
  • JavaプログラマのためのKotlin入門 - Qiita

    KotlinAndroid の公式言語になることが Goole I/O 2017 で発表されました。 Java プログラマが Kotlin を始めることがこれから多くなると思うので、 Kotlin をスムーズに始められるように次の 3 点についてまとめます。 Javaとほぼ同じところ 新しい考え方が必要でつまづきがちなところ Kotlinならではの便利なこと すべてを一つの投稿にすると長くなるので連載形式とし、投稿では最初の「Javaと同じところ」について説明します。 Kotlinって何? 題の前に、 Kotlin について簡単に説明します。 まずは↓の Android のコードを見て下さい。これは Android Studio が生成するテンプレートの Kotlin 版です。 Android アプリ開発者であれば、初見でも概ね何をしているのかわかると思います。 class Ma

    JavaプログラマのためのKotlin入門 - Qiita
    raimon49
    raimon49 2017/05/19
    クラスを継承可能にさせようとしたらopen classって書くことになるの凄く設計センスいい。
  • Scalaに関する誤解と事実を語る - kmizuの日記

    TL;DR 世間のScalaに関するイメージは、昔のままであることが多い 昔のままどころか、最初から間違ったイメージを持たれていることも多い 実際には、既に解決されている問題は多々あるし、改善に向かっていることも多い プロジェクト管理の問題を言語に押し付けているケースもある はじめに 自分が最初にScalaに触れたのが2005年(Scala 1からカウントした場合)、あるいは2007年(Scala 2以降からカウントした場合)と、Scalaとの付き合いも結構長くなってきましたが、その間に Typesafe社(現Lightbend社)の設立 実質標準ビルドツールとしてのsbtの確立 ライブラリのバイナリ後方互換性に関するポリシーの策定 公式ScalaイベントScala Daysのはじまり Play 2 Frameworkの登場 Scala Center発足 その他色々 がありました。この間、

    Scalaに関する誤解と事実を語る - kmizuの日記
    raimon49
    raimon49 2017/05/07
    implicit conversionやバイナリ互換性の話。
  • ドメイン駆動設計について DroidKaigi 2017 で登壇しました。

    長らく Y.A.Mの雑記帳というブログでAndroid技術情報を発信しています。最近はなかなか投稿できなくなってしまいましたが、それも仕事としてAndroidに関われているためです。Androidを触り始めたころはまだ学生だったので時間があったんでしょうね。 はじめて Android に関するエントリを投稿したのは 2009 年 5 月 24 日です。当時はJavaFXを触っていたので、NetbeansでAndroidをやろうとしていたようです。 当時のAndroidのバージョンは1.5、Fragment もなく、Support Library もなく、マルチタッチすらなく、ストアは Google Play ではなく Android Market という名前でした。 ここから2、3年くらいは、仕事Android アプリを開発している人はもっぱらメーカーのプリインアプリを作っている方たち

    ドメイン駆動設計について DroidKaigi 2017 で登壇しました。
    raimon49
    raimon49 2017/04/03
    利口なUIやUIが使役するユーティリティメソッドからドメインモデルを隔離するとはどういうことか、という話。
  • Big Sky :: golang と Generics と私

    以下の記事は Java について触れていますが、Java を dis っている訳でもありませんし、冗長に見える例を意図的に使っています。 最近 Twittergolang に Generics が無い事についてずいぶんと盛り上がったのですが、僕の意見をこのブログにも書いておこうと思います。 golang に多相が無いのはアレだとか開発者の怠慢だみたいな話はだいたい他の言語を覚えた人から出る感想で、静的型付言語である golang を見ると確かにそう見えるかもしれない。ただ golangJava や他の言語と違って Duck Type を採用している。 — Vim芸人 (@mattn_jp) March 7, 2017 スクリプト言語の多くに多相が求められないのと同じ様に golang を深く触る人達から多相が欲しいという意見がそれほど出ないのは golang の型が Duck

    Big Sky :: golang と Generics と私
  • なぜGo言語 (golang) はよい言語なのか・Goでプログラムを書くべき理由 | yunabe.jp

    結論としてはGo言語には以下のようないくつかの長所があり、現実路線で非常にバランスがとれた言語だと思います。 これらの長所のために失われたメリットも当然いくつもありますが、一定程度以上の規模のプロジェクトで利用する言語の選択肢としては現存するプログラミング言語の中では一番か二番目によいのではないかと思います。 コンパイルが速い (vs. C++) GCとメモリ安全性 (vs. C++) 妥当で現実的なレベルの型安全性 (vs. Python/Ruby) 実行時パフォーマンスが良さ (vs. Python/Ruby) 現実問題、ある程度の規模と期間のプロジェクトになると型検証があるとリファクタリングなどがだいぶ楽になるのでありがたい。 型があるので自然と実行時パフォーマンスも良い 標準ライブラリが整備されている (vs. C++) むしろ標準ライブラリにjsonのparserすら存在しないC

    raimon49
    raimon49 2017/01/17
    後半に批判への反論あり。
  • Rebuild: 171: Psychologically Safe Podcast (naoya)

    Naoya Ito さんをゲストに迎えて、デザインパターン、Python, Pandas, データサイエンス、マネージメントなどについて話しました。 Show Notes 増田 (はてな匿名ダイアリー) Rebuild: 169: Your Blog Can Be Generated By Neural Networks (omo) リーダブルコード Java言語で学ぶデザインパターン入門 マルチスレッド編 gensim Pandas Data Frame | R Tutorial Project Jupyter Is the Data Science market getting flooded? Network Programming with Perl Anaconda Perltidy Python for Data Analysis - O'Reilly Media Python

    Rebuild: 171: Psychologically Safe Podcast (naoya)
  • null安全を誤解している人達へのメッセージ - Qiita

    null安全を誤解している人達へのメッセージ 先日koherが投稿した記事が多く読まれたようです。記事の内容は僕とkoherが普段話してきた内容が多く登場しているため、僕が人々に伝えたい内容とも強く合致しています。しかし残念な事にインターネットの反応を見ていると、誤解しているケースが思ったより多くありました。 そこで、ネットで見られた意見に対して返答を書きました。 特定の実在する意見は指さずに、僕が感じ取った文脈を編集したものを対象にします。それによって、「そんな事言われてないじゃないか」と思うものがあれば、僕としてもそのほうが嬉しいのでそれで問題ないです。 「たしかにそうだ」と思ってnull安全に今一度興味をもってもらえれば嬉しいです。 なお、記事中のコードは特に言及が無ければswiftです。 意見: null安全があっても、ちゃんとやるのを忘れているかもしれないのでは 忘れません。ちゃ

    null安全を誤解している人達へのメッセージ - Qiita
    raimon49
    raimon49 2016/11/19
    JSONのくだりが現代的で頭に入り易い。丁寧だ。
  • フリーエンジニアのIT案件ならレバテックフリーランス

    2016年11月3日(祝)、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 <この記事の要約> 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい

    フリーエンジニアのIT案件ならレバテックフリーランス
  • Rebuild: 158: Kill All The Threads (ko1, Matz)

    Koichi Sasada さん、まつもとゆきひろさんをゲストに迎えて、Guild, Ruby 3 などについて話しました。(9/10 RubyKaigi 2016 にて収録) Show Notes RubyKaigi 2016 A proposal of new concurrency model for Ruby 3 Koichi Sasada: A proposal of new concurrency model for Ruby 3 (RubyKaigi2016) Global interpreter lock Ruby creator floats new concurrency model ギルド verse | RubyGems.org Rust: Ownership and Lifetimes Erlang -- Processes Racket: Places Soft

    Rebuild: 158: Kill All The Threads (ko1, Matz)
    raimon49
    raimon49 2016/09/16
    ギルドと所属 受け渡しできるオブジェクトを不変なものに限定して安全に並列処理させるアイディア
  • Butter Knife、今までありがとう。 Data Binding、これからよろしく。 - Qiita

    Butter Knife、今までありがとう あるアプリのmaster branchに,Butter Knifeへの依存をなくすPull Requestをmergeした. いままでButter Knifeが担っていた仕事はすべてData Bindingが受け持つことになる.Data Bindingは公式はbeta releaseと言っているものの,限りなく1.0に近いRCなんじゃないかという感じがしたため実戦に投入している. 実行時に全力でReflectionするButter Knifeと違い,Data BindingはAnnotation Processingで事前に色々やってくれる方式というのも嬉しい(c.f. Butter KnifeもAnnotation Processingする方式に切り替えるっぽい? => Split the compiler and runtime into s

    Butter Knife、今までありがとう。 Data Binding、これからよろしく。 - Qiita
    raimon49
    raimon49 2016/04/14
    非Reflectionらしい
  • Objective-C 供養 - Qiita

    Help us understand the problem. What is going on with this article? 世間はクリスマスモードだと言うのに、辛気臭いタイトルですみません。「勝手に殺すな」とか「お前は何様だ」などとなんだか怒られそうです。「喪失感で胸がいっぱい」だとか「 Objective-C はまだまだ使える言語です!」だとか、そういう感傷もありませんし、主張もしません。「いい言語だと思うし好きだけど、結局 Mac OS X や iOS のアプリケーション開発以外に活用(しようとトライしたけど)できないまま Swift が発表されたなー」と思っていて、なぜ活用しにくかったのかを整理してみようと考えました。ですので、「 Objective-C 栄光の歴史」を語ることはありません。体験してないし。知らないし。 それから、ここでは言語としての Objective-

    Objective-C 供養 - Qiita
  • re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - ぐるぐる~

    元ネタ: 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記 OOPの文脈で見ると、元の記事が言っていることもわからなくはないのですが、対象が広すぎていろいろと不正確になってしまっているので、ちょっとまとめてみます。 元の記事が対象にしているのは、Maybe / Optional / Nullableの3つです。 対応する型を持つ言語を見てみると、下記のようになります。 Maybe(Haskell) Optional(Swift/Java) Nullable(C#) これらは、「値がないこと」を表すもの、という見方では同じですが、それぞれ異なる価値観の元に作られています。 Maybe/OptionalとNullable これらはすべて型パラメータを取ります*1。 しかし、この中でNullableだけは型パラメータに

    re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - ぐるぐる~
    raimon49
    raimon49 2015/11/30
    C#は値型へのnull許容、Javaは戻り値での明示