everyrfc.org 2024 著作権. 不許複製 プライバシーポリシー
ユーザーエンゲージメント部の諸橋 id:moro です。 わたしはずっと、ユーザー登録やログイン周りという、サービス的には基盤的なところ、技術スタック的にはアプリケーション寄りのところに取り組んできました。関連する話を何度かこの開発者ブログにも書いています。 ユーザー基盤を作り直しながらRailsでのサービス層に向き合う 巨大なWEBアプリケーションに巨大な変更を取り入れるためにやったこと この記事で触れている「電話番号による登録」について、チームメンバーが別の側面を紹介してくれています。 今日はそのあたりの開発を通じて考えた、Railsアプリケーションでのフォームオブジェクトやサービス層といったものが何であるか、という問いに対する、現在の自分のスタンスを紹介します。 サービス層、サービスオブジェクト、フォームオブジェクト もともと Railsは Web 画面から DB 構造までをあえて密
先日書いた AWS の勉強方法をまとめた記事(AWSを学ぶ上でやってよかった勉強法5選 - log4ketancho)で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、 今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで…… や 「2)簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。 というような利用料金が気になってしまう、、というコメントを幾つかいただきました。 この気持ちとても分かります!業務で使う分にはサーバー何台立てようが気になりませんが(は言い過ぎですがw)、個人でサービスを運営する場合はそうはい
CDN_Study という勉強にいってきた。 https://http2study.connpass.com/event/81469/ そこで、Akamaiの方が、「個人の意見だけど、アプリケーション側がもっと基礎設計でステートレスでキャッシュフレンドリーな設計になってないといけないよね」という旨の発言をしていて、最近そのことにアプリケーションエンジニアとして同じようなことを考えていたので、書き出してみる。 SPAとかSSRとかフロントの不毛な話は出さないようにしてるが、主にサーバレス環境を意識している。 前提 世の中のアプリケーション内のモジュールは、Statefull or Stateless に分類でき、それをツリー状に表現できれば差分検知できる、という React の仮想 DOM 的な世界観が自分にある 以下の話は、基本的には Fastly のサロゲートペアーとそのためのミドルウェ
こんにちは。ハウスマートの高松(@t2kmt)です。 皆さんは開発要件をまとめるのにどんなフォーマットを使っていますか? 開発要件をいい感じにまとめるのって大変ですよね。 ドキュメント整備せずに開発に着手し始めてしまうと手戻り抜け漏れが出てしまいますが、一方で要件定義書をガチガチなフォーマットにするとドキュメントの作成自体の工数が増えてしまいます。 スタートアップはスピードが命。ドキュメントを書きまくって開発が進まないなんて言語道断です。 開発要件の整理はプロジェクトの成否に多大なインパクトを与えますが、ほとんどの現場では企画を考える人にフォーマットが委ねられていることが多いと思います。 今回は皆さんが快適に開発要件をまとめられるように、ハウスマートで利用している mini spec というフォーマットをご紹介します。 mini spec とは mini spec とは開発の要件をまとめる
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書(仕様書)」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな(≒納品物になりえる)設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォータ
システム刷新に失敗する理由のひとつが、ユーザ企業が業者の設計スキルを吟味せずに一括請負契約を結んでしまう点にある。彼らに委託すると、実際には下請業者が設計していたりする。多くの業者が多かれ少なかれゼネコン化しているため、設計スキルが空洞化しているためだ。下請業者に的確な設計が出来ないとは限らないが、起用される設計者のスキルレベルを発注者がコントロールできないという意味で、リスクが大き過ぎる。 そもそも「システム刷新に失敗した」とはどういうことか。ユーザ企業自身が想定するコスト感やスピード感でシステムを改善・発展させられなくなっているのであれば、失敗したと判断していい。少しばかり改修しようとしても、無駄に複雑な設計を掌握している開発業者の意向に振り回される。そんな業務システムの命運は業者に握られていて、これはもう経営権の一部を奪われているのと変わらない。そんな事例は少なくない。 なぜそういう
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法 作者: 増田亨出版社/メーカー: 技術評論社発売日: 2017/07/05メディア: 単行本(ソフトカバー)この商品を含むブログ (1件) を見る 目次流しは以前書きましたが、読み終わってるので改めて。 一緒に開発する人には読んでおいてほしい。可能なら手元に置きながら開発してほしい本です。手頃なサイズ、重量、厚さ、価格ですし。鈍器本系に比べれば持ち運びやすい。実際レビューやペアプロの際、「あの本に書いてるんだけど・・・」という感じで何度か参照しています。 読書会をしてみて 4つのイベントに参加しました。うち2つは輪読形式の読書会で、最初から最後まで読み上げです。有用なのと同時に危険でもある、というのが読書会での感想です。 平易な文章で理解しやすいように思えるのですが、表面だけで理解した気になっていると間違いな
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 言われたものはだいたい作れるし、どんなプログラミング言語が来ても大抵書けそうかなってなったエンジニアがそこで成長が止まってしまう人を見かけることがあります。 技術が好きで、作ることが好きで、なのに環境に求められず成長が止まってしまっているんだろうと思います。 ここで成長が止まってしまう環境とは、 新しい技術の情報を仕入れて語り合うエンジニアが居ない 業務用件に高い技術が求められない 改善サイクルが遅い 開発プロセスなどをまとめる人がいない などです。 簡単に言うと、今はうまく仕事があるけれど、停滞している仕事場ですね。 下手にビジネス的
プロダクトマネジメントにおいて「製品仕様を合議制(多数決)で決めてはいけない」というルールがあるが、それは何故なのか。そして、だとしたらどのように人の意見を取り入れるのが良いのか、を考えてみた。 なぜ製品仕様を合議制で決めてはいけないのか。合議に参加している人たちは、その問題の責任者ほど制約条件や問題の背景を深く理解をしていないから。合議制や多数決で物事を決めると、必ずその結果に満足している人たちの方が満足していない人たちよりも多くなる。これは素晴らしい手法だ。 しかし、製品開発の目的は社内の人を満足させることではない。正しい製品をつくることだ。製品にとっての正しさとは、「その製品を顧客(市場)が求めていること」であり、これを満たすためには様々な調査や知識が必要だ。 製品仕様のように、問題の複雑さが一定を超えると、知識を持っている人と持っていない人の意見に違いが出始める。世の中(「社内」と
2018年1月16日 Webサイト制作, 便利ツール 普段使っているChromeをより便利にしてくれる拡張機能。私も様々なものを入れていますが、その中でもWeb制作時に使える便利拡張をいくつか紹介します。Firefoxに対応しているものもありますよ! ↑私が10年以上利用している会計ソフト! Web Developer Chrome拡張|Firefox Add-on|GitHub|公式サイト Webに携わる人は入れておいて損はない拡張のひとつ!長年利用させていただいてます。1クリックでCSSやJavaScriptを無効化したり、画像の非表示、様々なデバイスサイズでの表示、クラスやID名の表示、定規やカラーピッカーまで揃っています!カラーピッカーはCSSで定義されたものだけでなく、画像からも抽出できるのがすごい。日本語版もあるので試してみてくださいね。 CSS Peeper Chrome拡張
もしも開発者としての安定した将来を手に入れたいのであれば、新世代のUXエンジニア(User Experience Developer)になりましょう。 なぜUXデザイナーだけが存在するのでしょうか? 彼らだけがユーザー体験への影響を独占しているわけではありません。開発者を例に挙げてみましょう。サービスのパフォーマンスやセキュリティ、およびその他の多くの開発上の決定が、ユーザー体験に影響を与えています。 優れたユーザー体験に貢献しているのは、デザイナーだけではありません。 あなたが開発者であるのなら、今こそあなたのユーザー体験への貢献を喧伝するときです。UXエンジニアになる時代がやってきました。その理由とは、ユーザー体験はビジネスにとって必要不可欠で経営者はそのことを知っているからです。 UXエンジニアになる理由 伝統的なマーケティングの時代は終わりました。人々は広告を見ないし、広告ブロッカ
こんにちは。Akerunエンジニアの @ishturk です。 Akerun Advent Calendarの記事です。 今日は設計書の話です。 設計書をどんなツールで書くかは、僕らソフトウェアエンジニアの尽きない悩み(楽しみ)ですね。 最近はまったツールが最高に良かったので紹介させてください。 僕のツールに求める要件は以下です。 編集がカジュアルにできる UMLが書ける。あとから編集できる(画像での貼付けは編集できないのでNG) バージョンの管理ができる 好きになれる(重要) 変遷と pros/cons MS Word pros 良くも悪くもスタンダードなツールですね。 だれでも編集できるのが強みです。 Visioと組み合わせれば、UMLも後から編集可能です cons Visioは標準にするには少々値が張ります。 バイナリ形式なのでバージョン管理はしづらいです。 ページが増えたり画像を貼
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
12月1日にレッドブルスタジオ東京にて、Dropbox Japan主催のUnleash the World’s Creative Energyと題されたイベントがあったので行ってきました。 クリエイティブな仕事のコラボレーションをサポートするツールとなりつつある最近のDropbox。Design managerのKurt VanerさんがDropbox Paperの制作現場の様子と素晴らしいデザインの傾向というタイトルで話してくれたのでメモを残しておこうと思う。 先程言った通り、Dropboxはただのファイル共有サービスではなくなっている。(友達紹介だけで14GBくらいの容量を稼いでいたころが懐かしい…。)そもそもファイルの共有サービスというより、クラウドストレージ的な側面が最初は強かったサービスだが、今ではPaperやShowcaseというサービスなどがローンチされ、彼らが次のフェーズに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く