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が最近リリースされ、重要な変...

YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
コードレビューにstashを使ってます。 こいつはgitのブランチ間の差分に対してコメントをつけることができるツールです。 ただ、ネットを介したコミュニケーションって何故か気が大きくなってしまったり、感情が見えづらかったりで誤解を生みがちです。 特にコードレビューって間違いを指摘するとかあんまり楽しい会話をするわけでもないので、言葉には気を使わないといけません。 今日は自分が気をつけている言葉や行いを上げてみます。 否定しない def get_name(name) @user.find(name: name) end ☓:getは軽量なアクセッサとして使うのが常識なのでやめて下さい。 ◯:findしてることが分かるメソッド名が良いです いちいち否定する必要はないです。素直にどうして欲しいか書きましょう。 否定しない2 「けど〜」 def search(name) @user.find(na
一般的にプログラミングというのは総合開発環境(IDE)を使って開発するものです。JavaだったらEclipseとかNetBeans、C#だったらVisual Studio、AndroidだったらEclipseかAndroid Studioと、だいたい決まっています。 でも僕はどれも使いません。 何を使っているかというと、IDEじゃなくテキストエディタのみ。コンパイルはコマンドプロンプト上でコマンドを打つという原始的な方法をとっています(実際はバッチファイルを作ってそれを走らせる)。この話をするとたいてい不思議がられますね。何でそんな無駄なことするんだ、みたいな。 [ad#top-1] IDEを使うとプログラミングを覚えない まず第一の欠点はこれ。当然ながらIDEはプログラミングの補助をしてくれるので、自動で必要なコードを生成してくれる頭のいい奴です。でも、これって便利な一方で、プログラミン
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩
サイバーエージェント メディアディベロップメント事業本部 A.J.A.社内勉強会第一回 (2016.6.23) の資料です。 幽霊型 (phantom) という型レベルプログラミングの手法について、Scala を用いて紹介しています。
偉大なプログラマーから学ぶ!プログラミングの考え方を学べる良書9冊とは! プログラミングの考え方を学べる良書まとめ。プログラミングをするには、ネットワークやアルゴリズムといった知識が重要です。偉大なプログラマーが自分の経験や知識を書物として残しています。優秀なプログラマーを目指す人は必見でしょう。 テックアカデミーマガジンは受講者数No.1のプログラミングスクール「テックアカデミー」が運営。初心者向けにプロが解説した記事を公開中。現役エンジニアの方はこちらをご覧ください。 ※ アンケートモニター提供元:GMOリサーチ株式会社 調査期間:2021年8月12日~8月16日 調査対象:2020年8月以降にプログラミングスクールを受講した18~80歳の男女1,000名 調査手法:インターネット調査 本稿は、CodingDojoのブログ記事を、CodingDojo Blogより了解を得て日本語翻
Microsoftはサンフランシスコで開催中のカンファレンス「DevNation」で、プログラミング環境の相互運用性を向上させる共通プロトコルをオープンソースで公開すると発表した。興味深いのは、この取り組みがCodenvyおよびRed Hatとの共同で進められていることだ。 このプロトコル「Language Server Protocol」(LSP)は、プログラミング言語をさまざまなコードエディタや統合開発環境(IDE)に統合するための共通の手段を提供する。LSPはさまざまなツールで多様なプログラミング言語を編集できるようにするもので、開発者の柔軟性と生産性を拡大することを目指している。 Codenvyの最高経営責任者(CEO)兼「Eclpipse Che」のプロジェクト責任者であるTyler Jewell氏は、「これまで、ほとんどのプログラミング言語は、1つのツールだけで最適化されていた
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス(以下WFと記述)」だが、実際のところ皆さんそれぞれ
Introduction to Linux namespaces - Part 2: IPC | Yet another enthusiast blog! こういうブログ記事があって、元記事はC言語なんだけど、これと同じことをmrubyでもやってみたサンプル。なお元記事は clone(2) だけど今回はforkしてから unshare(2) している。clone未実装なんで。。 reader, writer = IO.pipe puts " - Hello ?" p = Process.fork do Namespace.unshare(Namespace::CLONE_NEWUTS | Namespace::CLONE_NEWIPC) writer.close reader.read # blocking system "hostname 'In-Namespace'" puts " -
Total unique users: 9723 Note: The counts don’t sum to the total because some users contribute to multiple organizations (thanks!) and we’ve tried to avoid double-counting. Note: The counts from the Microsoft org are specific to the few .NET Core-related repos that exist there, such as visualfsharp. Note: These numbers include Microsoft employees, which are (at most) 10% of the count. Samsung join
「OpenStackのようなインフラソフトウェアは死んだ」、MirantisとRackspaceのマーケティング担当がブログで激論 「気がつくのに時間が掛かったかかったけれど、いまは確信している。インフラソフトウェアは死んだ」。OpenStackの専業SIerとして知られるMirantisの共同創業者でチーフマーケティングオフィサーのBoris Renski氏は、6月15日付のブログ「Infrastructure Software is Dead」をこのような書き出しで始めました。 このMirantisのブログは、Rackspaceからの反応を引き起こしています。OpenStack関係者のなかで存在感の大きな2社がいま、OpenStackのビジネスについてどう考えているのかが浮き彫りになっているので、2社のやりとりを簡単に紹介しましょう。 Mirantis:インフラソフトウェアは死んだ!
ポジション的なもの 個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く