Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
GraphQL’s query language is very easy to understand. For most people, it clicks immediately and doesn’t require much explanation. Thanks to GraphQL’s type system and tools like GraphiQL — a query builder/editor for GraphQL — learning GraphQL isn’t hard at all, and its advantages over traditional RESTful APIs become obvious quite quickly. Given GraphQL’s clear advantages, almost every developer I’v
みなさん、メンテナンスしやすいプログラムにするための設計に苦労してませんか? 次々と現れるフレームワークやデザインパターンに振り回されてませんか!? プログラムの設計については、パターン周りを中心に長い間多くの人を悩ませているように見えます。例えば MVC などは 1980 年代からあるものなのに、未だに定期的に議論に上がったり改善されたパターンなどが提案されたり、それを元にしたフレームワークが現れたりします。 僕もそういった設計に悩んだ(でる)一人なのですが、最近は新しいパターンも大事とは思いつつも単純に依存関係をきちんとコントロールする事が大事なんじゃないかと思うようになってきました。 そこで、この記事では依存関係をテーマに見通しが良く変更に強いプログラムにするために重要だと思う事を書いていきます。 この記事は大きく前半と後半に分かれています。前半は依存関係そのものの話や疎結合について
In this article, I’d like to clarify the differences in DTO vs Value Object vs POCO where DTO stands for Data Transfer Object, and POCO is Plain Old CLR Object, also known as POJO in Java environment. First of all, I want to make a note regarding Value Object. There’s a similar concept in C#, namely Value Type. It’s just an implementation detail of how objects are being stored in memory and I’m no
a place for me to talk about programming and .NET ... because my friends and family aren't interested All programs need to react to events. When X happens, do Y. Even the most trivial “Hello, World” application prints its output in response to the “program was started” event. And as our programs gain features, the number of events they need to respond to (such as button clicks, or incoming network
Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa
.NET開発者中心 厳選ブログ記事 MVVMパターンの常識 ― 「M」「V」「VM」の役割とは? ―― 「the sea of fertility」より ―― 尾上 雅則 2011/05/18 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET/.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 MVVM(Model-View-ViewModel)パターンに関する知見があちこちに散らばっているように見えるので、そろそろまとめてみることにしました。この記事は、MVVMの基本的な考え方・実装方法などを把握されて
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET/.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
システム開発や保守、運用の現場においてドキュメントは必須のものです。 しかし、ドキュメントの作成・維持には多くのパワーがかかるため、ドキュ メントが存在しない、資料が古いままになっているなどといった現状を多く 耳にします。 本勉強会ではこれらのドキュメントでよく利用される「図」にフォーカスし、 みるみるうちに図を作成できる「blockdiag」をご紹介します。 「blockdiag」はシンプルなテキスト記述からブロック図、ネットワーク図などの 画像ファイルを出力可能なオープンソースの画像生成ツールです。書き やすさ、メンテナンスしやすさを中心にデザインされており、図を作るのに 配置や並べ替えに苦労する必要はありません。 blockdiagのサンプルはこちら このような特徴を持つ「blockdiag」と、シンプルな記述でドキュメントを作成 するツール「Sphinx」を組み合わせることによって
最近の趣味は「Haskellはいいぞ」と呟くかTwitter Search: Haskellを巡回して を押して回ることです 毎日巡回しているとHaskellに入門しようとするも細かいところに引っかかって前に進めないでいる人をちらほら見かけます。今回はそんな見回りの知見を活かしてHaskell初心者が躓きやすいポイントをまとめてみたいと思います。 1. 入門書は何がいいの? それはもうすごいH本一択でしょう!…と言いたいところですが時々不満の声を聞くこともあります。確かにすごいH本こと『すごいHaskellたのしく学ぼう!』は世界一わかりやすいHaskell入門書であることは間違いないと思いますが、逆に内容が平易すぎるため記述が冗長だと感じたり読み終わっても何か自分で作れるようになった気がしなかったりするかもしれません。なので僕は「プログラミングも初心者でHaskellから入門してみたい」
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 (契約プログラミングについて) Effective Java読書会9日目 - 例外 (Javaにおける例外の扱いについて) 契約による設計から見た例外 (この記事の方がより詳しいけど難しいイメージ) チェック例外と非チェック例外の違い チェック例外→「回復
今回は、プロデルで作ったプログラムを他の人が利用できるようにする方法をご紹介します。 自分が作ったプログラムを、他の人に使ってもらおう 自分が便利だ、と思って作ったプログラムは、きっと他の人にも役立つものであるはずです。プロデルで便利なソフトが出来上がったら、インターネットに公開しましょう。 プロデルで作ったプログラムを動かすには、作ったプログラムとプロデル本体が必要ですが、他の人のPCにプロデルがインストールされているとは限りません。プロデルがないPCでも、作ったプログラムが動くようにするには「実行可能ファイル」というファイル形式を作って、それを配布すれば動きます。 なお、プロデルは商用利用も可能です。開発したアプリは、AS-ISの条件のもとライセンスフリーで利用・公開できます。
The Firefox developer tools use CodeMirror as the source editor in many places (including the new WebIDE). CodeMirror provides auto-indentation when starting a new line and can convert tab presses into indents. Both of these features are frustrating however if the editor is set to insert the wrong indentation. That’s why many text editors will detect the indentation used in a file when it’s loaded
「プリンシプル オブ プログラミング」という本を執筆しました。少し先ですが、2016/03 下旬 発売予定となっています。 書籍紹介・目次 どのような本? 構成は? どうして必要? どうやって説明? 読んでほしい人は? 書いた人は? 最後に どのような本? ソフトウェア業界で高名な、よいコードを書くための「プリンシプル」を紹介します。 プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」のことです。これらは、歴史の審査を受けて生き残った、よいプログラミングのためのエッセンス(「普遍的」「定説的」「本質的」な知識)です。 構成は? プリンシプルを、7つのカテゴリに分けて説明しています。 第1章 前提 〜 プログラミングの変わらぬ真実 〜 第2章 原則 〜 プログラミングのガイドライン 〜 第3章 思想 〜 プログラミングのイデオロギー 〜
Emojicode is an open-source, full-blown programming language consisting of emojis.Install Emojicode 1.0 beta 2 Visit the docsOr Stay in touch with Emojicode Conceptually BrightAs a multi-paradigm language Emojicode features object-orientation, optionals, generics, closures, and protocols. Lightning FastEmojicode compiles to native machine code using lots of optimizations that make your code fast.
Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。 Androidは、Google社が開発したスマートフォンやタブレットなど携帯端末向けのプラットフォームです。 カーネル・ミドルウェア・ユーザーインターフェイス・ウェブブラウザ・電話帳などのアプリケーションやソフトウェアをひとつにまとめて構成。 カーネル・ライブラリ・ランタイムはほとんどがC言語/C++、アプリケーションなどはJavaSEのサブセットとAndroid環境で書かれています。
オブジェクトの内部の値がイミュータブルであれば、今後もその値は変更されないことが保証されているので、新しい状態を持った新しいオブジェクトの内部の値のうち、変更のない部分(つまり値のうちのほとんど)は古いオブジェクトの値をそのまま参照すればよく、コピーする必要がないということを @takkkun が言っていて(正確には、イミュータブルなリストに新しい値を追加した新しいリストを作るときには、中身をコピーする必要ない。変更されないことが保証されてるから、という話だった)目から鱗が落ちたのでここに記して置こうとおもった。 で終わろうと思ったんだけど、もう少しちゃんと書く。 ミュータブルな世界では同一性の問題がある。 たとえば playerA と playerB の HP がたまたまおなじ 10 であったとしても playerA と playerB の HP 変数が同じ数値オブジェクトを参照していた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く