ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ

「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」の著者、市谷聡啓さんが2019年6月に出版した「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を拝読しました。 本書をおすすめしたい人 プロダクト開発において、アジャイル開発での進めかたを知りたい人 アジャイル開発チームのプロダクトオーナー(ビジネスサイド、企画者） プロダクト開発チームが所属している会社の経営者 アジャイル開発を新たに学びたい人 アジャイル開発をひととおり知っているが、あらためて学びたい人 「正しいものを正しくつくる」という中心理念 本書のAmazonレビューを見ていたところ、星1つのレビューを見つけました。 エンジニアの傲慢さが詰まった本 「正しい」という言葉を使うエンジニア、同じエンジニアとして非常に恥ずかしい思いです。 「正しいも

Clean Architecture　達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか

回答 (3件中の1件目) Rubyの実行速度に興味があって、15年くらいMRIの開発をしています。興味があるので長い記事になっちゃったことをお詫びします。 遅いと言ったとき、多分「実行速度」の話をしているんだと思いますが、それ以外にも結構いろんな「はやさ」があります。思いつくところで少しご紹介します。 (1) プログラムを作るはやさ Ruby は生産性が高い言語と言われることが多いので、プログラムを作る早さは早い、という評価が一般的です。 Cで書くと2日かかる。実行時間は0.1秒 Rubyで書くと1日かかる。実行時間は10秒（Cの100倍） と、すこし極端な仮定を置いてみると...

回答 (5件中の1件目) この質問にかなり先行して2015年、Quora（本家）で投げかけられた質問として、 Why do some functional programmers criticize design patterns in OOP languages as a sign of language deficiency, while Monad is also a design pattern? なぜ、関数型プログラマらは、オブジェクト指向(OOP)言語のデザインパターンを、言語の欠陥の象徴だと批判するのでしょうか？モナドもデザインパターンじゃないんですか？ があります。...

Webサービスやアプリなど開発や運用に関わっている方であれば、こんなことを耳にしたことがあるのでは無いでしょうか？ 5人でテストを行えば、ユーザビリティ上の問題のうち85%を発見できるこれらは業界的にはある意味で常識ですが、色々話を聞いてみると、この常識の「出処」あるいは「根拠」ってあんまり知られていないようなのです。 もちろん、ちょっと知識のある人であれば、ユーザビリティ業界の第一人者であるヤコブ・ニールセン博士が提唱したというところまでは知識として知っているでしょう。しかしながら、その元ネタとなった論文を実際に読んだ人、あるいは85%という数字の根拠やその条件について理解されている方はどの程度居るのでしょうか。 ということで本記事では「ユーザテストは5人で85%」の元ネタである下記の論文について、解説、と言うとちょっと大げさかもですが、概要を紹介してみたいと思います。願わくば、この記事

地方出身、関東の有名私大卒で、地方（出身地ではない）国立大の教員（工学部）経験者です。 地方国立大には、地元出身者と、とにかく国立大学を目指して、偏差値のランクで入ってくる学生がいて、私がいた大学では前者の方が全体的に伸びしろが大きいイメージでした。 学力的な意味もあるし、都会の私立大学を中心に何を教えているのか分からない横文字の学部が増える中で、地方の大学は基礎的なカリキュラムを丁寧に教えているので、まじめに授業を受けている学生はその意味でも基礎力が付いている印象でした。個人的には、学生に対する評価は高いです。地元出身の学生には、旧帝大や有名私立に匹敵する学生も少なくなかったです。 では何が違ったか。 それは、ここで出てきた「情報を調べてマウンティングする能力」に近いものかも知れません。 東京は、何かのレベルが高いというだけでなく「その価値観を、メディアを通してあたかも普遍的なもののよう

最近、はてなブログで退職エントリをよく見ます。 6年勤めたNTTを退職しました 日本経済新聞社を退職しました 富士通SEを1.5年務めて辞めた結果、得られた3つの手札 １つ目はNTT研究所を辞めてGoogleに転職した方の記事。 ２つ目は日経新聞を辞めてGoogleに転職した方の記事。 ３つ目は富士通を辞めてスタートアップに転職した方の記事です。 現時点で日系大企業を辞めてGAFAに転職する人が増えているかはわかりませんが、日系企業の非効率さに嫌気がさした優秀な若手がGAFAを始めとする外資系企業に転職する流れは加速していくように思います。 インターネットは簡単に国境を超え、グローバルIT企業は世界中から優秀な頭脳をかき集めています。 待遇も一流、環境も一流。周りにいる人間も超一流ばかりの環境に、優秀な若手が惹きつけられるのは無理もありません。 冒頭で紹介した退職エントリからも伝わってくる

直面する問題を解決したらkaminariができた。Ruby / Railsコミッター松田明のOSS開発の実像 世界中のRubyプログラマに使用されるOSSであるkaminari。これを手がけたRuby / Railsコミッター松田明さんに、開発背景を聞きました。 「これがあったら便利なはずだ」という予測。 あるいは、「これが問題だから、解決する」という現状認識。 新たな技術が生み出される源流にあるものとは、一体なんでしょうか。 Ruby on Rails（以下、Rails）を用いたWebアプリケーション開発において、圧倒的な存在感を放つページネータであるkaminariを開発した松田明（まつだ・あきら／ @a_matsuda ）さんの場合は、“絶対に”後者であると語ります。 Rails、そしてRubyのコミッターでもある松田さんは、まさにRubyを用いた開発の最中、先行するソフトウェアに感

やりたいこと データを変形・加工するスクリプトをURL上にホストをして、 ポータブルで永続的でブラウザで完結するWebアプリを作れるようにします！ Rubyはデータ加工に最適！ Rubyは豊富なメソッドが標準で用意されていて、特にArray, Enumerator, Stringなどよくデータを加工したいときに使えるメソッドがとても豊富です。 メソッドチェーンでつなげていけるところが、人の思考にあっていて、どんどんデータを変えていけるところがRubyの良さだと思います。 そのためデフォルトの言語はRubyです。JavaScriptもオプションで選べるようになってます。 そこで、　データ加工に便利なRubyで書いた小さいWebアプリをURL上にホストします！ URLにすべてのコードを載せてしまえば究極的にポータブルなWebアプリになるのではないかという発想です。Itty.bittyにインスパ

Qに1度開催しているマネージャー合宿を続けて1年が経ちますが、今回の合宿で組織の価値観を話し合っていた時に、我々の中ではマネジメントにおける「当事者意識を持て」という言葉の明確な死、終わりを感じました。 と言っても、当事者意識という言葉自体を否定しているわけでありません。今でも当事者意識を持つことは重要だと思ってはいます。 あくまで、現在のクラウドワークスのマネジメントにおいては「当事者意識を持て」という言葉は死んだと感じた次第です。その経緯と理由を以下にまとめておきます。 （また、弊社株主を始めとして当事者意識という言葉でマネジメントしている会社があると認識していますので、他社についてとやかく言うつもりもありませんし、他社は他社でそのようなマネジメントで成果を出しているのだと思います。現在の日本社会を背景としてゼロから組織を作っているクラウドワークスでの話が原則です。） ■１．不確実性の

(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) Pythonは高い人気を誇り、DevOps、データサイエンス、Web開発、セキュリティの分野で使われています。 しかし、速度に関しては高い評価が全くありません。 JavaとC、C++、C#、Pythonの速度を比べるには、どうしたらいいのでしょう？　答えは、実行するアプリケーションのタイプに大きく左右されます。完璧なベンチマークはありませんが、[手始めに比べる手段](https://algs4.cs.princeton.edu/faq/)としてはThe Computer Language Benchmarks Gameが適しています。 私は10年ほどthe Computer Language Benchmarks Gameを参照していますが、Java、C#、Go、JavaScript、C++などの他言

筆者は普段btraxのサンフランシスコオフィスで働くUXデザイナーだ。これまでに日本を訪れたことはまだ1度しかないのだが、今年の6月、日本に出張するチャンスが巡ってきた。 Suicaへのチャージからフードトラックでお弁当を買うことに至るまで、日本ではあらゆる購買体験の設計がとても優れていることを感じた。 また、普段生活しているサンフランシスコでの自然で気にすることのないようなやりとりが、いかに自分が「当然物事はこうなるだろう」と期待するメンタルモデルにいかに引っ張られていたかもわかった。 日本での体験はサンフランシスコでよりもはるかにスムーズ日本の人は明らかにサンフランシスコの人とは異なる独自のメンタルモデルを持っている。 滞在中に時々不便な思いをすることはあったが、地下鉄に乗ったりレストランで食事をしたりすることはサンフランシスコでの同じ体験よりもはるかにスムーズで気持ちのよいものだった

Ruby1.8.5、1.8.6、1.8.7のリリースマネージャを務め、現在は株式会社マネーフォワードでフルタイムのRubyコミッター職として働く卜部昌平（うらべ・しょうへい／@shyouhei）さんは、deoptimizationと呼ばれるアプローチを用いてRubyの高速化に取り組んでいます。 本稿ではその足跡から、いかなる思想のもとでデザインや実装を行っているかを、卜部さん本人が解説します。 Deoptimizationの着想に至るまで デザインとは、やらないことを決めること 「最適化が間違っていたら、戻す」をどう実装するか？ インストラクションを消し、跡地をnopで埋める 「メソッド呼び出しが省略可能であること」を判定するために 省略可能な呼び出され方を増やす 大き過ぎる問題ではなく、実現できる規模の問題に取り組む Deoptimizationの着想に至るまで 言語を高速化するときに、

「先進的なソフト開発手法の導入で、日本と世界の差が広がっている」。CI（継続的インテグレーション）ツールのオープンソースソフトウエア（OSS）「Jenkins」の開発者であり、米CloudBeesのCTO（最高技術責任者）を務める川口耕介氏が警鐘を鳴らす。2018年9月23日に開催する「Jenkinsユーザ・カンファレンス 2018 東京」に先立って、日経 xTECHのインタビューに答えた。 Jenkinsはバージョン管理ツールへのプログラムの保存といった出来事を検知して、自動的にツールの起動などの作業を実行する。日本では、ソフトウエアのビルドやテストを自動化する定番ツールとなっている。ところが、多くの企業で活用が現場の作業改善にとどまる。その先に進まない日本企業の姿に川口氏は物足りなさを感じている。同氏はこの状況を打破すべく、CloudBeesの日本への関わりを増やす意向だ。 ここでいう

Web ナチュラリスト フィードを眺めていたら Alex Russell 氏の新作が投稿されていた。 The "Developer Experience" Bait-and-Switch | Infrequently Noted 本来の趣旨については原文を読んでもらえばいいし、下記はこれを読んだ上で普段の考えを踏まえて脳裏をよぎったポエムである。 我々は複雑性で仕事をしている 仕事をしている、もしくはそれでお金を稼いでいる。誰もが。 私は 2012 年頃から Web の、特に Web フロントエンドの複雑性に加担している自覚がある。 Web の専門性が高まることはその技術領域に深淵な価値があることを示唆し、それに携わることの価値を相対的に向上させることができる。 私の活動そのものは些細なものだが、かくして 2018 年現在の Web はかくも複雑になることに成功し、エンジニアリングの名の下

イベント概要 先日、アジャイルの本質について語るイベントが日本橋で開催された イベントのテーマは「本質を理解しないままのアジャイル開発に挑む危うさ」 アジャイル3怪獣 と呼び声の高い (?!) お三方がアジャイル開発の本質を激辛トークで深掘り 会の後半では、参加者を交えたディスカッション（フィッシュボール形式）も行われた イベント詳細はこちら：https://connpass.com/event/96750/ 登壇者 やっとむさん「アジャイルってなにが美味しいの？」 きょんさん「目的論からのアジャイル～手段を目的化すること～」 ryuzeeさん「アジャイル開発でコールド負けしないための5つのポイント」 感想を一言で言うと タイトル通り、内容が本質すぎて辛かった 終始「ぐぬぬ…」となる胸熱展開のオンパレードでした 「アジャイルってなにが美味しいの？」 by やっとむさん 登壇資料 そもそもア

RESTful APIを設計した際のステータスコードの指針です。 メソッド別 GET 成功した場合 200 OK：最も一般的 304 Not Modified：条件付きGETでキャッシュを使わせたい場合 POST 成功した場合 201 Created 作成したリソースのURIを示すLocationヘッダを付けておく 議論 200 OKだとまずいのか？ 200 OKを応答する実装も多くあり、まずいというわけでもない 200 OKはPOST結果がキャッシュ可能、201 CreatedはPOST結果がキャッシュ不可能として分けてもいいが、そこまでする必要があるか？（POSTのキャッシュは一般的ではない） 204 No Contentだとまずいのか？ クライアントがPOST結果を事前に全て知っているわけではないのでNo Contentは不親切では？ 失敗した場合 409 Conflict：作成しよ