Dependency Injectionでやりたいことはモジュールimport - きしだのHatena
Dependency Injection(DI)、最近のフレームワークには欠かせない気がする機能になってますね。 そしてDIの説明をみると「依存性の注入」みたいなことが書いてあって、ようわからんになりがちです。 実態としては高機能なimportなので、あまり難しいことを考えなくていいような気がします。 たとえば、こんな感じのMyServiceクラスがあってDIコンテナに管理させるとします。 @Component class MyService { void method() { } } そして、MyServiceを使うMyControllerがあるとします。 @Component class MyController { @Inject MyService service; void hello() { service.method(); } } これって、実際のところMyServiceの
オブジェクト指向 の検索結果 - きしだのHatena
オブジェクト指向言語の話をするときに便利なように、Javaを中心にプログラミング言語をまとめてみました。 Javaに影響与えるか、Javaから影響を受けるか、という感じですね。 Simula オブジェクト指向はここから始まったと言われています。 クラス、オブジェクト、継承、仮想関数(多態)といった、オブジェクト指向の基本要素が備わっていました。 ただし、「オブジェクト指向」という言葉は生まれていません。 Smalltalk Simulaから発想を得て「オブジェクト指向」という… …ろいろ分類した本で、オブジェクト指向言語とはどういう位置づけになるのかという話をするときに確認してもらいたいんだけど、いま中古で4万円。 「アルゴリズムデザイン」も一時絶版状態で、12万とかで売られてるのを見た。 いまは在庫復活して17,000+税になっているけど、買ったときは15,000+税だったな。Amazo
x=x+1がわからないのは逐次実行がわかっていないからで、記号を変えても解決にならない - きしだのHatena
x = x + 1がわからないという話が流行ってました。 で、「=ではなく:=を使えば」とか「イミュータブルにすれば」とかいう話が出たりしてますが、問題をあとまわしにしてるように見えます。 結局のところ、逐次実行がわかっていないことが表面化している場合がほとんどではないかと。 https://speakerdeck.com/kishida/lets-code-a-process?slide=8 プログラム以外の文章は、基本的にひとつの状態を示していて状態が遷移するということがありません。 推理小説なども、最終的な状態が徐々に開示されるだけともいえます。途中から読むと犯人が変わるということはないですね。もちろんそのように途中から読むと犯人が変わるような叙述トリックは可能ですが、通常はそうではないからトリックになるわけで。 つまり、x = x + 1という式は、x + 1という演算を行ってから
Javaを中心に偏見ベースでプログラミング言語の関係をまとめた - きしだのHatena
オブジェクト指向言語の話をするときに便利なように、Javaを中心にプログラミング言語をまとめてみました。 Javaに影響与えるか、Javaから影響を受けるか、という感じですね。 Simula オブジェクト指向はここから始まったと言われています。 クラス、オブジェクト、継承、仮想関数(多態)といった、オブジェクト指向の基本要素が備わっていました。 ただし、「オブジェクト指向」という言葉は生まれていません。 Smalltalk Simulaから発想を得て「オブジェクト指向」という言葉を生んだのはアラン・ケイでした。 しかし、モデルとしてはSimulaとは異なりメッセージングを主体としたものでした。また、アラン・ケイの「オブジェクト指向」はプログラミングのパラダイムだけではなく、人がコンピュータをどのように扱うかというメタファであり、ダイナブックというハードウェアやそのユーザーインタフェースを含
APIといえばWeb APIになった現在、ローカルAPIは専らライブラリと呼ばれる説 - きしだのHatena
APIというとWeb APIのことを指すようになってしばらくたちますが、こういう場合WebじゃないほうのAPIを指すレトロニムができるはずなんですよね。 例えばこのエントリのタイトルではローカルAPIという言葉を使ったけど、埋め込みAPI、組み込みAPIという言い方も可能な気はして、そしてどれもしっくり来ない。シェアドライブラリを考えると埋め込みAPI / 組み込みAPIというのは不適切でローカルAPIが適切な気がするけど、違和感が大きい。 元々でいうと、アプリケーションプログラマがなんらかミドルウェアなどを使うための入り口というのはAPIで、SQLもAPIのひとつだったりした。 C.J.DateとCodd博士の「The relational and network approaches: Comparison of the application programming interfac
オブジェクト指向は差分プログラミングとデータ分類をまとめて扱おうとしたのが弱点 - きしだのHatena
オブジェクト指向の最大の特徴は、モジュールと型を一体に扱ったことです。 メイヤーの本では次のような「オブジェクト指向の基準」があげられています。 クラスが唯一のモジュールでなければならない すべての型はクラスに基づいていなければならない つまり、クラスはモジュールであり型であるということです。 ここで、モジュールにとって必要な、クラスで実現できる機能は、モジュール間で異なる部分だけをそのモジュールで実装するという差分プログラミングです。 型に求められるのは、データの分類です。 ということは、オブジェクト指向は差分プログラミングとデータの分類を同時に扱おうとしていたということになります。 けれども、データの分類と差分プログラミングを同時に行うのは大変です。 「できらぁ！データの分類と同時に差分プログラミングして、いいソフトウェアができるっていったんだよ！！」 というのがオブジェクト指向だった
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena
某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
10年間のプログラミングの変化といえばクラウド、型推論、リアクティブ - きしだのHatena
この10年間のプログラミングの変化、というのが流れてきたのだけど、個人的にはクラウド、型推論付き静的型、リアクティブかなぁという風に思ってます。 クラウド(とスマホ) 2008年にGoogle App Engineが出たり、最初のHadoopサミットが行われたり、ちょうど10年前に始まったとも言えるクラウドは、すでに流行ではなく常識になっています。 いまや、クラウドを考えずにシステムを組むということはないんじゃないでしょうか。 スマホもこの10年で広まり、端末にUI、データはクラウドということも当たり前になっています。 40%の視聴率をもった紅白で視聴者が同時投票するようなことも、AWSを使って危なげなく行えるようになっていますが、10年前にこのようなサービスをたった4時間だけ行うということはなかなか考えにくいもので、実現できるのも限られたベンダーだけだったと思います。けれどもいまではそれ
小学校低学年へのプログラミング教育には効果がないと考えたほうがいい - きしだのHatena
子どもへのプログラミング教育は早ければ早いほどいいというものではない。 最近子どもへのプログラミング教育が話題になることが多いけど、恐らく小学３年生までの子どもへの効果はほとんどなく、小学４年生でもほとんどの子どもには難しいと思う。 人間の知能の発達には段階があって、必要な段階に達していないうちにそれが必要な教育を行っても効果は望めない。 まず、なんでこのエントリを書いたかというと、プログラミングには適した発達段階があるということを知らないと、その発達段階に達する前にプログラミング教育を行って、もちろんプログラミングは出来なくて、その子には適性がないという判断をしてしまうとうことが起きてしまうんじゃないかと思ったからだ。 まだ適した段階まで来てないだけなのにプログラミング教育をして失敗して「この子にはプログラミングができなかった/興味をもたなかった」という実績を作ってしまうことによって、将
かわいいリレーショナルデータベース作った - きしだのHatena
リレーショナルデータベースの勉強用に、最低限の機能をもったリレーショナルデータベースを作ってみました。 今回実装した最低限の機能というのは、射影(select)・選択(where)・結合(join)です。 テーブル作成 テーブル作成は次のようになります。 Table shohin = Table.create("shohin", new String[]{"shohin_id", "shohin_name", "kubun_id", "price"}); shohin.insert(1, "りんご", 1, 300) .insert(2, "みかん", 1, 130) .insert(3, "キャベツ", 2, 200) .insert(4, "わかめ", null, 250) .insert(5, "しいたけ", 3, 180); System.out.println(shohin);
プログラムの生産性を高めるためになにを勉強するか - きしだのHatena
用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ
コミュニティに入るか入らないかでエンジニアとしての幸福度がかわる - きしだのHatena
以前、「勉強会に参加しないと不幸になる話」というのをアップしました。 勉強会に参加しないと不幸になる話 - きしだのはてな このときは、勉強会x勉強会という枠だったので、「勉強会」と表現していますが、実際にはコミュニティに参加しないと不幸になる話でした。 あと、ここでの幸せ・不幸せというのは、エンジニアとして、という話で、エンジニアリング能力があがるとか、エンジニアリングの活動がやりやすいとか、エンジニアリングの活動が評価されるとか、エンジニアリングの話題を共有できる仲間が増えるとか、そういう観点です。 エンジニアとしての幸せ以外にも、人生にはさまざまな観点の幸せがある、ということは最初に補足しておきます。 会社が教育機能をもっていない エンジニアとしての幸せに大切なのは、エンジニアリング能力を上げていくことです。 ただ、2013年の産業経済省IT人材白書の概要に IT企業に対して、201
ネットワークに自信のない人は東大講義の情報工学概論Ａを見よう - 2012-01-28 - きしだのはてな
東大にUTオープンコースウェアというのがあって、いろいろな講義資料が公開されています。 http://ocw.u-tokyo.ac.jp/ その中には動画授業があるものもあって、そのほぼすべてがおもしろいです。ただ興味がもてるかどうかという違いだけ。 その中で、情報工学概論Ａというのがあって、授業内容としてはネットワークの概論になってます。まだ全部見てないけど、ネットワーク全般の話からTCP/IPの話、セキュリティまでの講義が公開されてるみたい。 こういう一貫した話がちゃんと語られてる講義というのはなかなか公開されてない、公開されてたとしてもネットワーク設定程度だったりするので、これは貴重だと思います。 http://ocw.u-tokyo.ac.jp/lecture?id=11314&r=609526321 ネットワークの勉強をしたことがない人は、テレビのかわりにこの講義を流しておくとい
2010-11-25 - きしだのはてな - 技術力をあげたいプログラマが読んでおかないと話にならない本10冊
ここにあげた本じゃなくてもいいので、同じ分野でなにか読むとか、本に書いてあるほど詳しくなくてもそれなりに知識をもっておくべき本。 アルゴリズムクイックリファレンス 作者: George T. Heineman,Gary Pollice,Stanley Selkow,黒川利明,黒川洋出版社/メーカー: オライリージャパン発売日: 2010/04/26メディア: 単行本（ソフトカバー）購入: 11人 クリック: 656回この商品を含むブログ (72件) を見る まずはアルゴリズム。クイックって書いてあるけどぜんぜんクイックじゃないｗ。各言語で書かれた入門書を読んでもいいと思う。 実際のプログラムにアルゴリズムの知識を活かすということを知りたいならプログラミングコンテストチャレンジブックがおすすめ。 プログラミングの基礎 ((Computer Science Library)) 作者: 浅井健一
アルゴリズムの勉強のしかた - きしだのHatena
この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基本的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういう本で勉強すればいいか、ぼくの知ってる本からまとめてみました。
読みやすいコードのための暗黙の了解がつまってる「リーダブルコード」 - きしだのHatena
そういえばidがkdmsnrの児玉サヌールという人から「本を訳したよ！」と献本いただいたのだけど、届いた本を見てみると訳者は角 征典という人だったのでとまどっていたところ。 出版したときにいただいてたので、もう半年近くになるけど、時間がかかったのは、ちまちまと一日1ページとか2ページとか読んでたから。普通に読めば、たぶん土日で読めます。 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者:Dustin Boswell,Trevor FoucherオライリージャパンAmazon 関係ないけど、一時期、角さん、角田さん、角谷さん、という一文字ずつ成長する東のほうの人と一気に知り合いになって「かっくん」と言われてるのがどの人かわからないことがあった。懐かしい話。 それはそれとして、ぼくは「きれいなコードをかきましょう」系の話
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
