本書について 本書は、Node.jsでのアプリケーション開発を始めようとする皆さんに、 ”高度な”JavaScriptについて知るべきあらゆることを解説します。 よくある”Hello World”チュートリアルの、はるか上をいくものです。 ステータス 貴方が読んでいるのは、本書のいわゆる最終版となります。 つまり本書は、間違いが見つかった場合や、 Node.jsの新バージョンにおえる変更点を反映する時のみ、改訂されます。 最終更新日は2012年2月12日です。 本書内のコードのサンプルは、Node.jsのバージョン0.6.10でテストしています。 ターゲット読者 本書は、Ruby、Python、PHP、Javaのような、少なくともひとつのオブジェクト指向言語を理解しており、 JavaScriptについてはあまり経験がなく、Node.jsについては全く経験がないという、 著者と同じようなバッ
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
Backbone.JSからAngular2まで、全9大JavaScriptフレームワークを書き比べた! - paiza times
(English article is here.) こんにちは、吉岡([twitter:@yoshiokatsuneo])です。 ウェブ開発に欠かせないJavaScriptフレームワークですが、日々発展しておりReact.js, Ractive.js, Aurelia.js, AngularJS2.0など次々と新しいフレームワークが出てきています。 一体どれを使えばいいのか？何が違うのか？何から調べていいのか迷うことがあります。 そこで、現時点で事実上全てとなる、９大主要フレームワークについて、実際に使ってみて比較を行います。 Backbone.js Ember.js Knockout.js AngularJS(1.x) React.js Ractive.js vue.js Aurelia.js AngularJS2.0(アルファ版) これらのフレームワークでは、以下のような機能が実現さ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレー
今日はさくらVPSに載せているWordPressのパフォーマンスをチューニングして高速化に成功したので安心して眠れるという話をします。 2.5ページ/秒だったのが70ページ/秒と30倍高速化。 以前はDaily数千PVで重くなっていたサイトがDaily3.6万PVを余裕で捌けるようになりました。 #ちなみにproxy cacheという手法はwordpressでなくても動的コンテンツ全般に有効です。 ▼サーバ気にしなくて良くなったので今週末新宿御苑に花見に行けました☆。枝ぶりがいいさくらが多くてほんといいところだと思うの。 WordPressチューニング高速化結果http://hara19.jp/のサーバ環境と測定結果は以下のとおり。 WordPress稼働環境さくらVPS 1GB/CentOS5.5/PHP5.3/MySQL5.5/WordPress3.1。 WEBサーバはチューニングにあ
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
「日本は、韓国に嫌われている」 こう言うと多くの日本人は、 「そんなことはない。昔は反日だったけど“今は”違う！」 とか、 「反日は“一部”の人間だけ。ほとんどはどちらでもない！」 という『願望による部分否定』をすることがある。 はたして本当に“今は”違うのだろうか？ 本当に“一部”という表現に見合うほど少数派なのだろうか？ そしてそれらは「何を根拠に」言っているのだろうか。 私はその希望的な推察の根拠を聞いたことがない。 また、 「日韓友好を阻害してるのは靖国と竹島の問題だ！」 「韓国人が嫌ってるのは日本人じゃなくて日本政府だ！」 といった『責任の一極転嫁による気休め』もよく聞く。 だが、もし竹島や靖国がなかったら韓国は反日を止めるだろうか？ 答えは間違いなくＮＯである。 「韓国は、官民一体の反日主義国家である」 こう言うと普通の日本人はつい良心的に、 「もしかして日本人が知らないだけ
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
初めてのプログラミング体験まとめ（Ruby on Rails編）：小鳥ピヨピヨ(a cheeping little bird)
startmac 生まれてはじめて、プログラミングなるものしてみんとて。 いやー、Webディレクターをしていると、ちょっとでいいから自分でプログラミングができるといいなと思いはじめるんですよねー。 でもあまりにも敷居が高くて、なかなか手を出せず、そしてどんどん月日は流れていくばかり。 で、このたびStart Macに当選してMacBookをもらったとき、これを機に、 「今度こそ、絶対に、何が何でもプログラミングを学ぼう」 と思ったんですよね。ほら、MacってベースがUNIXだから、なんとなくプログラミングとかもやりやすそうな気もするし。 なので、今回はちょっと気合を入れて、先生を見つけて、時間をとって、とうとうやってしまいました。 プログラミング童貞を捧げる相手は、「Ruby on Rails」。とても簡単にプログラミングができると話題のフレームワークです。 Rubyというプログラミング言
NetflixのgithubリポジトリはWeb技術の百貨店だった - DiaryException
検索しているとなにかとNetflixのgithubリポジトリがヒットするので、全部（2015/07/18現在分）調査してみた。 github APIで https://github.com/Netflix のリストを全部取得して、名前・概要・URL・最終更新日時 (なんの更新だ?) を抽出。 AWS用のプロダクトが多かったのでまずそれらと、その他という分類にした。その他はほとんどがJavaライブラリ・システムだが、一部WebアプリケーションやPythonライブラリがある。 日本語での説明はReadmeやWikiを見て書いているが、理解が正しくないかもしれない。 AWS用 aws-autoscaling Tools and Documentation about using Auto Scaling URL: https://github.com/Netflix/aws-autoscalin
pipとpipenvとpoetryの技術的・歴史的背景とその展望 - Stimulator
- はじめに - Pythonのパッケージ管理ツールは、長らく乱世にあると言える。 特にpip、pipenv、poetryというツールの登場シーン前後では、多くの変革がもたらされた。 本記事は、Pythonパッケージ管理ツールであるpip、pipenv、poetryの3つに着目し、それぞれのツールに対してフラットな背景、技術的な説明を示しながら、所属企業内にてpoetry移行大臣として1年活動した上での経験、移行の意図について綴り、今後のPythonパッケージ管理の展望について妄想するものである。 注意：本記事はPythonパッケージ管理のベストプラクティスを主張する記事ではありません。背景を理解し自らの開発環境や状態に応じて適切に技術選定できるソフトウェアエンジニアこそ良いソフトウェアエンジニアであると筆者は考えています。 重要なポイントのみ把握したい場合は、各章の最後のまとめを読んで頂
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
MEAN(MongoDB, Express, AngularJS, Node.js)スタックが優れている理由 - Mozilla Open Web Day in Tokyoを終えて - albatrosary's blog
MEANとは、LAMP(Linux, Apache, MySQL, PHP)に変わる技術としてじわじわと注目されはじめているアーキテクチャです。このアーキテクチャMEAN(MongoDB, Express, AngularJS, Node.js)は、シンプルでかつ強力なアーキテクチャで、現在のJavaを利用したアプリケーション開発とは一線を画すところです。HTML5開発にとってJavaの役割が殆どなくなるというのも注目すべき点だと考えます。MEANで一般的に言われる注目すべき事項は次のところです： JavaScriptフルスタックである データモデルとしてクライアントからデータベースに至までJSON そして、この記事を書こうと思ったきっかけですが、2014/10/5(日) Mozilla Open Web Day in Tokyo | Mozilla Japan でのMEAN解説展示で、様
VSCodeの拡張機能、なに使ってますか？ はてなエンジニア世論調査 #2 - Hatena Developer Blog
こんにちは、Webアプリケーションエンジニアのid:hogashiです。 半年ほど前に公開した「開発環境のフォントなに使ってますか？」に続く、はてなエンジニア世論調査の第2回「VSCodeの拡張機能、なに使ってますか？」です。 ソースコードエディタであるVisual Studio Code（以下、VSCode）は多くのエンジニアに利用されています。VSCodeにはソースコードのシンタックスハイライトやデバッグなど、さまざまな拡張機能をインストールして使うことができますが、公開されている拡張機能は膨大にあります。 その中から、はてなのエンジニアはどんな拡張機能をインストールして、日頃の開発に使っているのでしょうか？ 前回と同様にアンケート調査してみました。 アンケート方法 アンケート結果から見える人気の機能拡張 6割の拡張機能は1人だけが使用 人によってかなり異なるインストール数 興味深いコ
ニコニコ動画(く)リリース失敗に寄せて
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。 Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 - QiitaドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。 ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。 ニコニコ生放送におけるdock
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
Scrapy + Scrapy Cloudで快適Pythonクロール+スクレイピングライフを送る - Gunosyデータ分析ブログ
はじめに こんにちは、データ分析部の久保 (@beatinaniwa) です。 今日は義務教育で教えても良いんじゃないかとよく思うWebクロールとスクレイピングの話です。 私自身、日頃は社内に蓄積されるニュース記事データや行動ログをSQLやPythonを使って取得・分析することが多いですが、Web上にある外部データを使って分析に役立てたいというシーンはままあります。 単独のページをガリガリスクレイピングしたいときなどは、下の1年半ぐらい前の会社アドベントカレンダーに書いたような方法でやっていけば良いんですが、いくつもの階層にわかれたニュースポータルサイトやグルメポータルサイトを効率よくクロール+スクレイピングするためには、それに適したツールを使うのがすごく便利です。 qiita.com そこでPython用スクレイピングフレームワークScrapyの登場です。 Scrapy | A Fast
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
私は色んなプログラミング言語を触るのが病的*1に好きで、どの言語をどういう場面で使うのが良いのか凄く興味があります。 そこで、今の私の知識範囲でのそれぞれのプログラミング言語の使いどころを（自分用の整理もかねて）書いてみます。 C/C++ - C＝OSやミドルウェア、C++＝効率化のための再実装 安直に「メモリとスピードが第一優先のとき」と思いたいところですが、同等程度のスピードでもっといい言語はいっぱいあります。計算集約的ならJuliaとか、オブジェクト指向で組むようなソフトならD言語とか。なのでまずC言語は、Swigみたいのを使って他の言語の拡張ライブラリを書いたり、システムコールを使ってOSやミドルウェアを書くときじゃないかと思います。C++はテンプレートを駆使したりして効率を維持しながら抽象度の高いコーディングをするような場面がしっくり来ると思います。既に他の言語で実装したソフトウ
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
OOコード養成ギブス - rants
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
みんなのウェディングの高井です。 クラスベースのオブジェクト指向プログラミング言語を利用している人であれば、クラスとは、ありふれていて普段から利用するものです。にもかかわらず、良いクラスをつくるというのは、なかなかに難しいことです。 先日、みんなのウェディングでアルバイトをしてくれている学生さんのコードレビューをしていたときにも、それを強く感じました。 実践的プラグマティックには「ソフトウェアの規模や文脈にあわせて、適切に抽象化していただきたい」という以上のことを言っても仕方がないところなのですが、それだけでは経験の浅いプログラマーにとって、まったく分からないという話になってしまいます。 というわけで、今回はクラス設計の原則についてのお話しです。 Bertrand Meyerのクラス設計の原則 Bertrand Meyerは『オブジェクト指向入門 第2版』の中で、クラス設計について章をひと
Contents Command Line Interface Guidelines An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day. Authors Aanand Prasad Engineer at Squarespace, co-creator of Docker Compose. @aanandprasad Ben Firshman Co-creator Replicate, co-creator of Docker Compose. @bfirsh Carl Tashian Offroad Engineer at Smallstep, first e
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した 最近、コミットはされないがローカルのディレクトリに置かれている.envのようなファイルから生のパスワードやAPI Tokenを削除しました。 これは、ローカルでマルウェアを実行した場合に、ローカルに置かれている生のパスワードやAPI Tokenを盗まれる可能性があるためです。 最近は、npm install時のpostinstallでのデータを盗むようなマルウェアを仕込んだりするソフトウェアサプライチェーン攻撃が多様化しています。 Compromised PyTorch-nightly dependency chain between December 25th and December 30th, 2022. | PyTorch What’s Really Goin
ソフトウェア設計について、YAGNIやSOLIDなど多くの原則・法則があることが知られていますが、その解釈にはぶれが存在することが多いです。そこで、特に有名なものあるいは有用と感じることが多いものをいくつかピックアップして、その解釈やトレードオフについてまとめてみました。 注意としては、SOLIDが入ってることからわかる通り、主にOOPに関する文脈になります。また、各原則の定義については概ね知っている前提で書いているのであまり初学者向けの記事ではないかもしれませんのでご承知おきください。 YAGNI（You ain't gonna need it.） YAGNIは、予測による実装が実際に役立つことは少ないという経験則から生まれた原則です。 一般にオーバーエンジニアリングが利益をもたらすケースは限定的で、どちらかというとプロジェクトに害を与えることが多いとされています。YAGNIは日々状況の
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
モダンなJava開発ガイド (2018年版)
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2018年現在でもJava開発をしていると、Antすら使っていないEclipseプロジェクトにそこそこの頻度で出くわします。Eclipseの自動コンパイルが通ればOKであり、ビルドはExcel手順書をもとに手動で行われ、依存関係ライブラリはもちろんlibフォルダに各種jarファイルが放り込んであります。Eclipse上以外ではどう動かせば分かる人がいないため、コマンドラインからビルドなどを行うことは叶わず、CI化なんて夢のまた夢です。 そんなJava開発から脱却したい人向けのJava開発のモダン化ガイドです。 基本的にJava 8以降で
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? @rana_kualuさんの2018年の最先端バックエンドエンジニアになろうという翻訳記事がとても興味深かったのですが、記事内で提示されているロードマップに関して微妙に違和感を感じる部分もありましたので、 記事に記載されているスキルは現場でどの程度必要なのか 記事に記載されていないが現場において重要なスキルは何か といった辺りを、自分なりの意見を交えてちょっと書き出してみました。 自分をエンジニアとして最先端だとは全く思っていないのですが、最近のバックエンドのトレンドに一応多少なりともきちんとキャッチアップしてるかなとは思うので、若い方
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-p
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
こんにちは。ソウゾウの Software Engineer (CTO) の @suguru です。連載：「メルカリShops」プレオープンまでの開発の裏側の1日目を担当させていただきます。 7月末にメルカリShopsという新しいサービスが公開されました。メルカリShops は、2021年1月にメルカリのグループ会社として設立したソウゾウが新たに立ち上げたサービスです。 この記事では、メルカリShops を作るにあたり、どういった技術、アーキテクチャを選定したのか、その背景と意思決定をまとめて共有したいと思います。 monorepo まず最初にプロジェクトをスタートしたときに、サービスのリポジトリを作るのですが、迷わず monorepo による構成を選択しました。monorepo は、システムを構成する複数のコンポーネントの独立性を保ちつつ、全ての構成を1つのリポジトリで管理する手法です。今
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』（1999 年）で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これには
Ruby中級入門
Ruby中級入門 1. Ruby中級入門 @shokai 2013年8月5日(火) @masuilab 2. 私 •@shokai (しょうかい) •趣味：料理、glitch 3. ある程度大きなアプリケーションを作 っていると、部品に分割したくなると 思います。アプリ内ライブラリやgem の作り方を説明します。Rubyの機能を 活用した使い勝手の良いライブラリの デザインについて考えます。 4. • アプリ内ライブラリの作り方・gemの作り方 • サンプルコードとテスト • ライブラリのデザイン • API • DSL • 泥臭い小手先の技 • 例外・エラーの通知 • ドキュメント コンテンツ 5. ライブラリを作る 例：LeapMotionを自作アプリに組み込むための アプリ内ライブラリを作る 6. • LeapMotionはport 6437にWebSocket 接続するとJSONで
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS! ：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js チュートリアル | Node ビギナーズブック
gitにおけるコミットログ/メッセージ例文集100
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
さくらVPSのWordPressをチューニングして30倍高速化した方法 - 原宿・表参道.jp
韓国は『なぜ』反日か？
複雑なJavaScriptアプリケーションを考えながら作る話
技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
Gitのコミットメッセージの書き方 | POSTD
書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
Clean Architectureは全てのプログラマにお奨めしたい良著｜erukiti
プログラミング言語の使いわけ - アドファイブ日記（ミラー版）
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
クラス設計の原則 — みんなのウェディングエンジニアリングブログ
Command Line Interface Guidelines
1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した
ソフトウェア設計についての原則や法則についてまとめてみた
2018年の最先端バックエンドエンジニアに必要なスキルについて考えてみました。 - Qiita
オブジェクト指向の法則集 - Qiita
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
メルカリShops の技術スタックと、その選定理由 | メルカリエンジニアリング
プログラマーのための原則（2 万字） - Qiita
エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD