CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
本書について 本書は、Node.jsでのアプリケーション開発を始めようとする皆さんに、 ”高度な”JavaScriptについて知るべきあらゆることを解説します。 よくある”Hello World”チュートリアルの、はるか上をいくものです。 ステータス 貴方が読んでいるのは、本書のいわゆる最終版となります。 つまり本書は、間違いが見つかった場合や、 Node.jsの新バージョンにおえる変更点を反映する時のみ、改訂されます。 最終更新日は2012年2月12日です。 本書内のコードのサンプルは、Node.jsのバージョン0.6.10でテストしています。 ターゲット読者 本書は、Ruby、Python、PHP、Javaのような、少なくともひとつのオブジェクト指向言語を理解しており、 JavaScriptについてはあまり経験がなく、Node.jsについては全く経験がないという、 著者と同じようなバッ
西野亮廣の商売について解説します
連日西野亮廣の話題が世間を賑わわせているのでそろそろ彼の戦略、商法について解説しようと思う。 私は西野亮廣研究家の一人で彼のサロンに入っている。 立場を明言しておくと、サロンには入っているがメンバーとは特に交流もなく、クラウドファンディングで支援することもなく 彼のビジネスロジックが書いてあるサロン用ブログを読むだけにとどまっている。まだ0プペである。（追記・ついにプペった） どちらかというとNプペしてキャッキャしてる人たちとは西野に対する温度差がかなりあるのでとても交流できそうにないと思っている側である。 ただ、個人事業主としては彼の戦略は大いに参考になる部分があるのでそれをシェアする。 ということで、どうやってここまで彼が支持者を獲得していったかというところを解説していきたい。 まず最初に挙げられるのがチケットの手売りというところ。 https://www.jprime.jp/arti
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
【翻訳】あなたが求めていたリアクティブプログラミング入門 - ninjinkun's diary
original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する｜ハイクラス転職・求人情報サイト AMBI（アンビ）
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する Androidアプリの開発において悩ましいアーキテクチャの選定。本記事では選定する意味を改めて整理し、 MVP・Clean Architecture・MVVM・Fluxといった最新の実例を紹介します。 はじめまして。Androidエンジニアの藤原聖（ふじわら・さとる／@satorufujiwara）です。 現在は株式会社サイバーエージェントで、エンジニアリングマネージャーを兼任しています。2017年で35歳になり、定年を迎えました（プログラマの定年については「体型を支える技術」などを参照）。 Androidアプリ開発には2010年から携わっていますが、今現在の関心事は何といっても公式開発言語に採用されたKotlin。そしてもう一つが、Androidの
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。｜じゅ ごん｜note
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。 [Ateam Lifestyle x cyma Advent Calendar 2018]の5日目は、株式会社エイチームライフスタイルの@gonjyu121が担当します。 はじめに最近のWEBサービス運営チームというと、事業運営や企画営業のチームと、エンジニアチームが一緒になって働く事が多いですよね。 そんな時、多くのエンジニアが、 「品質保持やリファクタリング、改善系のissue（タスク）の優先度がなかなか上がらず、着手できない・・・・・・」 といった悩みを抱えがちです。これなんですが、非エンジニアの皆さんからすると、 「エンジニアがすごいのは分かるんだけど、何をやってるか、なんでこんな時間がかかるのか、正直分からないんだよなー」 と思っていたりします。こんな話、
作成：2015/08/10 更新：2017/04/16 Web制作 > 開発環境 ページを移動せずにテンプレートや仕様書を確認したい。今回はPCの横に貼ったり印刷したり、ワンクリックで見れるように、1ページで完結している資料をまとめました。Web制作をする上で便利なチートシートや資料・仕様書まとめです。 エンジニア速報は Twitter の@commteで配信しています。 もくじ WordPress版 受託用マニュアル １．ヒアリングシート ２．WP版ホームページ制作の流れ ３．WordPress管理マニュアル ４．WP版品質チェックシート ５．Wordpress タグ タスクランナー ６．gulp ７．Bower JavaScript 代替言語／JST ８．TypeScript ９．CoffeeScript １０．Jade コーディング用 １１．Chrome 開発ツール １２．html5
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年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレー
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
設計原則はよい設計をするための指針です。 では、よい設計とはなんでしょうか？ もっとも重要なソフトウェア品質は発展性 ソフトウェアの発展性がビジネス価値を生む 発展性をうみだす７つの設計原則 モジュール化 モジュール化の２つのアプローチ 型によるモジュール化 手続き的なモジュール化 関心の分離 関心の4象限 入出力と計算・判断の分離 業務の関心と実装の詳細の分離 もっとも複雑な関心事（ビジネスロジック）の分離を徹底する カプセル化と抽象化 カプセル化 ビジネスロジックのカプセル化 抽象化 データ抽象 ビジネスロジックとデータ抽象 高凝集と疎結合 凝集度 結合度 隠された結合性の問題 定義の一点性 見た目が同じコード 7つの設計原則の学び方 コードの実装例 ドメインオブジェクト設計のガイドライン 実践ガイドとして使える本 設計の考え方を理解するための本 もっとも重要なソフトウェア品質は発展性
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
はじめに 最近、Webの記事を見てるとReactだVue.jsばかりが上がっていてJSPやERBの話をしてる人は誰もいません。jQueryの記事ももちろん見ない。 つまり、Webだけ見る限りではほとんどの人がSPAを使ってるように見えます。 私はWeb界隈には居るもののどちらかというとバックエンド寄り、もっというとそもそもWebとか関係ない領域を見る事が多いので、ちょっとキャッチアップを兼ねていくつかの個人プロダクトにVue.jsを採用してみました。 jQueryくらいで頭が止まってたので。サーバサイドもマイクロサービスでAPI化が進んでるのでフロントもそれに合った技術を選ばないとですしね。 というわけで、今回はその中で得た知見というか、従来型のサーバサイドでのWeb開発をしていた人の視点でVue.jsをキャッチアップする流れで書いていきたいと思います。 まあ最終的な結論は正直「これすごく
2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
本項は「C# Tokyo オンライン「世界一わかりやすいClean Architecture」他」による発表の登壇原稿となります。過去に発表した.NET版の記事はこちらにアーカイブしています。 本稿のサンプルコード・PPTはこちらで公開しています。 「CC BY-SA 4.0」で公開していますので、気に入っていただけたら営利目的含め、ライセンスの範囲で自由に利用していただいて問題ありません。 github.com また動画を以下で配信しています。よろしければご覧ください。 世界一わかりやすいClean Architecture はじめに まず初めに、クリーンアーキテクチャの誤解されがちな二つのことについてお話させていただきます。 その上で、クリーンアーキテクチャの本質とは何か？押さえておくべき、本当に重要だと考えている三つの事について、お話しします。 注意事項 さて本題に入る前に、少し注意
お久しぶりです。@at_grandpa です。 今回、Model View Controller について再考する機会があったので、自分なりに整理してみました。 勘違い MVCの勘違いに関しては、以下のSlideShareが有名かと思います。 やはりお前らのMVCは間違っている @mugeso これにはドキッとしたことを覚えています。 このスライドで「間違っている！」と指摘されている形式を、そういうものだと理解していたからです。 上記で指摘されている勘違い形式を、自分なりにわかりやすく噛み砕き、図にしてみました。 Userからの入力をControllerが受け取る Controllerはデータ置き場であるModelからデータを取得する 取得したデータをControllerが加工する 加工したデータをViewに転送する Viewは、受け取ったデータを視覚表現しディスプレイに表示する 自分の中
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
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アプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
ISSUEへ移動しました 診断機能の結果も元に単価表の精度をアップデートしています。購読してお待ちいただければと思います。 2022年度最新版はこちら こちらの単価表を元に単価診断機能を作りました 様々なご要望を受け、新たに単価診断機能を作成しました！質問形式で現時点での単価目安を診断することができます。改良に改良を重ねていくのでぜひ一度受けてもらえると嬉しいです！ はじめに 私は「ISSUE」という副業プラットフォームを運営しているのですが、プラットフォームを構築する際にエンジニアの方々約200人とお話しました。そのヒアリング内容からエンジニア業務委託単価表を作成してみました。単価はこれから副業やフリーランスとして活動しようという方々がよく悩むところだと思います。私もそうでした。またすでに業務委託をしている方もどのタイミングで単価を上げる交渉をすればいいかとても悩むものだと思います。そん
セクションナイン の 吉田真吾（@yoshidashingo）です。 昨今のサーバーレスアーキテクチャの実装パターンについて5つの分野でユースケースをまとめました。 実装方法はAWSがベースですが、クラウド各社のFaaSに大きな機能差はないので(そもそもシンプルなコンセプトなので)、FaaS単体よりも、連携可能な周辺サービスまで含めて自分のアプリケーションのユースケースに合っているかどうかが大事になってきます。また、そもそもいくつかの実装はPaaSのオプション機能として組み込まれている場合もあります。よって、この先連携先の機能強化などによってもっと多くのパターンが発見されることになると考えています。 【1】Webアプリケーション シングルページアプリケーション ex. Serverless Single Page Apps Web API REST API GraphQL 非同期Webジョ
パリで発表されていたReact向けプロダクトがあまりにも未来に生きていて興奮したので、紹介させてください。 目次 目次 この記事のゴール 想定読者 はじめに 今回ベースとするソースコード React Nativeは何をするツールか Reactは何をするツールか React DOMとReact Nativeの違い Reactアプリケーションを描画するものたち React DOMの役割 React Nativeの役割 1. ネイティブ処理系の上でJavaScript処理系を動かす 2. Reactを動かす 3. Reactから渡された差分をネイティブViewに適用する React Native DOMはどこがReact Nativeなのか React Native DOMのやばいところ6連発 ReactからはReact Nativeに見えてるのがやばい Objective-C実装をJavaSc
はじめに 本稿は、日経クロステックにて筆者が昨年連載していた3回分の記事一部変更して1つにまとめたものです。 https://xtech.nikkei.com/atcl/nxt/column/18/01394/ 有料記事として配信されておりますが、無料でも閲覧できるようにということで日経クロステック様に許可を得てQiitaにも掲載しています。 第1回：技術的負債はなぜ生じるか。 第2回：ソフトウエア開発を「制御」する意外な処方箋 第3回：技術的負債への取り組みはなぜ「２つのDX」につながるのか。 第1回：技術的負債はなぜ生じるか。 年間12兆円ものマイナスの影響をもたらす技術的負債（あるいはレガシーシステム）はどのように生まれるのでしょうか。それを防ぐ方法はあるのでしょうか。第1回は、技術的負債をとりまく歴史をたどりながら、ソフトウェアエンジニアではない人にも理解できるようにその正体に迫り
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解説展示で、様
UXデザイナー深津貴之が語る身も蓋もない組織論!? 「ユーザー目線のない会社からは逃げるしかない」「それでもそこでがんばりたいなら……」 | HRナビ by リクルート
PCやスマートフォンを開けば、そこには不愉快なUIが至るところにあふれている。さして文章が長くもないのにページが4分割されているニュース記事（腹立たしいことに4ページ目はたった1行だったりする）、サッカーのハイライト動画でシュートの行方をカメラが追い始めた瞬間に始まる動画広告、場面転換をするたびにCMが挟み込まれ、もはやCMを見ているのかゲームをしているのかわからなくなるアドベンチャーゲームアプリなど……。 さらに不幸なことは、ウェブメディアの編集部や動画配信者、ゲーム制作会社の制作現場にいる人たちにとっても、これは決して愉快な状況ではないということだ。罵詈雑言混じりの苦情が書かれたユーザー評価欄やSNSを見ながら彼らは言うだろう。「誰が好き好んでこんなUIを作るものか」と。 関わる誰から見てもおかしなUIは、それでもなぜ量産され世の中のストレスを増幅させ続けているのだろうか？ その負のス
5年間は生き続ける考え方が凝縮された良書「AWSで実現するモダンアプリケーション入門」 | DevelopersIO
「最近、モダンモダンすげぇ聞くけどモダンってなに？」 「人の数だけモダンはあるんだよ…」 近年、パブリッククラウドを主軸としたアプリケーション開発文脈の中で「モダンアプリケーション」という言葉をよく聞くようになりました。自分もMAD（Modern Application Development）事業部の部長を去年やっていたりして、モダンという言葉には人一倍敏感だったりします。 そんなおり、そのモダンアプリケーションについて真正面から解説する本を、著者の落水さんから献本いただいたので、僭越ながら書評という形でご紹介させていただきます。 モダンがなにかようやくわかるの…!? ( ﾟдﾟ) ｶﾞﾀｯ / ヾ ＿_L| /￣￣￣/＿ ＼/ / 丸わかりやで。 書籍の概要「AWSで実現するモダンアプリケーション入門」 AWSで実現するモダンアプリケーション入門 〜サーバーレス、コンテナ、マイ
2度のインシデントが示す安全なシステムへの理解不足勤勉な国民性を持ち、システムの運用を行わせれば確実に仕事をこなすことで世界的にも知られている日本において、Mt. Gox事件に続く、2回目の取引所における大きなインシデントが発生した。筆者は、以前より、日経IT Proの連載「ブロックチェーンは本当に世界を変えるのか」（大幅加筆をして書籍『ブロックチェーン技術の未解決問題』として出版）において、ブロックチェーンを用いたシステムにおけるセキュリティ確保の難しさを解説し、スタンフォード大学で行われたブロックチェーンのセキュリティに関するトップの会議であるBlockchain Protocol Analysis and Security Engineering 2017 (BPASE 2017)、IEEE Security & Pricvacy on the Blockhcain(IEEE S&B
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだので、まとめてみます。コメントやツッコミなどのフィードバックがあればうれしいです。 続編としてクリーンアーキテクチャ本を読むためのポイントという記事を書きました。併せてご覧ください。 なぜ良著？著者のロバート・Ｃ・マーチン（著書読んだことあるかも？）は、50年前から現代に至るまで、様々なアーキテクチャを見て、第一線級として開発し続けてきた経験を元に、どのアーキテクチャでもクリーンにしようとするなら、基本部分は変わらないと言ってて、それらが美味くまとまった本だからです。 いってみればコンピュータ工学について抑えるべきポイントを解説した本であり、The Clean Architectureそのものについてはほとんど割かれていません。それくらい、基本として知るべき事が書かれた本なのです。 最近のアーキテクチャを追いか
私は色んなプログラミング言語を触るのが病的*1に好きで、どの言語をどういう場面で使うのが良いのか凄く興味があります。 そこで、今の私の知識範囲でのそれぞれのプログラミング言語の使いどころを（自分用の整理もかねて）書いてみます。 C/C++ - C＝OSやミドルウェア、C++＝効率化のための再実装 安直に「メモリとスピードが第一優先のとき」と思いたいところですが、同等程度のスピードでもっといい言語はいっぱいあります。計算集約的ならJuliaとか、オブジェクト指向で組むようなソフトならD言語とか。なのでまずC言語は、Swigみたいのを使って他の言語の拡張ライブラリを書いたり、システムコールを使ってOSやミドルウェアを書くときじゃないかと思います。C++はテンプレートを駆使したりして効率を維持しながら抽象度の高いコーディングをするような場面がしっくり来ると思います。既に他の言語で実装したソフトウ
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
AWS料金早見表
サーバレスアーキテクチャ構成にしたときに 実際のところ、どれくらいの料金になるのか気になったので算出してみようと思います。 (あくまでシミュレーションしたものでAWS側で値段や計算方法が変わったりするため、責任は負いかねますので導入する際は自己責任でお願いします。) AWSのどこにどれくらいの料金がかかっているのか知ることは大事だと思ったのですが、トータルだとなかなかまとまってなかったのでまとめてみました。 間違ってたらご指摘いただけると助かります。 サーバレスアーキテクチャって何？って方はこちら参照してください 世界に先駆けてAWSサーバレスアーキテクチャでユーザ認証とAPI認可の実装をしてみた AWSサーバレスアーキテクチャでCloudFrontからWAFをかけてAPI Gatewayを呼ぶ Lambda+RDSはアンチパターン 全部教えます！ サーバレスアプリのアンチパターン とチュ
ソフトウェア設計について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では、「これはどうな
webエンジニアの「業務委託単価表」が公開 - Digital Shift Times（デジタル シフト タイムズ） その変革に勇気と希望を
Resource株式会社は、3,000の実績データをもとにwebエンジニアの業務委託単価表を公開したと発表した。 現在の単価が適正単価なのか、次の単価レンジに行くにはどうすれば良いか、開発発注プラットフォーム「ISSUE」の実績を使い調査したとのことだ。 2022年11月ではISSUE上に1,800人以上のユーザーデータと2,000以上の単価診断結果があるという。またISSUEではクラウドソーシング形式で企業とマッチングすることにより、報酬を獲得することができる。その際の契約時給単価を今回の相場作成の参考にしているとのことだ。 ・1,000〜2,000円 インターン・アルバイトレベル。プログラミングを始めたての学生や勉強中の人が対象になる。実務経験としては0〜1年ほどの人が当てはまる。プログラミングの概念を学んでいる段階なので、外部APIなどの公式ドキュメントを理解するのが難しい場合もある
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
Node.js チュートリアル | Node ビギナーズブック
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
終わるSIerの底辺を見てきた - ミッションたぶんPossible
1ページで完結、Web制作者が助かるチートシート・資料・PDFまとめ
変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
7つの設計原則とオブジェクト指向プログラミング - ソフトウェア設計を考える
DHHはどのようにRailsのコントローラを書くのか | POSTD
コードが読めるソフトウェア開発者 - As a Futurist...
レガシーおじさん、SPAを始めてみた。そして限界を知る
2018年なぜ私達はコンテナ/Dockerを使うのか | iret.media
世界一わかりやすいClean Architecture - nuits.jp blog
「MVCの勘違い」について、もう一度考えてみる - 圧倒亭グランパのブログ
複雑なJavaScriptアプリケーションを考えながら作る話
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
エンジニア200人に聞いて、業務委託単価表を作りました - Qiita
サーバーレスアーキテクチャのパターン別ユースケース - yoshidashingo
Web最新技術がてんこ盛りのreact-native-domから目が離せない - ナカザンドットネット
「技術的負債」への処方箋と「２つのDX」 - Qiita
Satoshiが注意深く設定した世界の境界線
Clean Architectureは全てのプログラマにお奨めしたい良著｜erukiti
プログラミング言語の使いわけ - アドファイブ日記（ミラー版）
Microservices における認証と認可の設計パターン