タグ

システムに関するhrksb5029のブックマーク (15)

  • 現代的システム開発概論 2024

    2024年度リクルート エンジニアコース新人研修の講義資料です

    現代的システム開発概論 2024
  • ヘッドレスCMS + S3 静的ウェブページで記事投稿システムをサクッと実装してみた(microCMS + Amazon S3) | DevelopersIO

    はじめに みんなが大好きな Amazon S3 の「静的ウェブサイトホスティング」。 サーバー不要でお手軽にウェブページを公開できる便利な機能ですが、HTMLを触らずにちょっとしたお知らせなどを更新できるようにしたい、というケースも多いと思います。 今回はそんな用途にぴったりの「ヘッドレスCMS」を利用して、S3 でホスティングしている静的ウェブページに管理画面から記事を投稿できるシステムを、1 時間ほどの作業でサクッと実装してみました! ※記事では「とりあえず動くシステム」をできるだけ簡単に、最短で体験することを目指しているため、セキュリティフロントエンドの実装技術については掘り下げていません。 ヘッドレスCMSとは? CMS(Content Management System)とはユーザー管理、記事の投稿、データベースなどがセットになったコンテンツ管理システム全体を指します。 最も

    ヘッドレスCMS + S3 静的ウェブページで記事投稿システムをサクッと実装してみた(microCMS + Amazon S3) | DevelopersIO
  • shiodaifuku.io

    Webエンジニアのブログです。

    shiodaifuku.io
  • 認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏

    自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか?」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

    認証と認可と課金とコアドメインを分離したシステムは勝てるという話 - まっちゅーのチラ裏
  • ログ設計指針

    概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応

    ログ設計指針
  • Account Suspended

    Account Suspended This Account has been suspended. Contact your hosting provider for more information.

    Account Suspended
  • 自分の理解を理解する→何をどのように分かっているかを可視化するISM構造学習法の考え方

    知識はスタンドアローンでは存立できない。 そして理解するとは結びつけること、知識のネットワークをつくり育てることに他ならない。 今回は、こうした理解の捉え方を、最も直裁に実装化したISM構造学習法を紹介しよう。 自分が今現在、何と何をどのように結びつけて理解しているかを繰り返し可視化し、これを増補改訂していく中で学習を進めていこうというアプローチである。 (時間がない人のための概略) 1 学びたいことから複数(20〜30個)の項目を拾い出す 2 「この項目はこの項目とつながってる」と今の時点で分かるもの同士を結ぶ 3 連結関係をdot言語で記述しGraphvizで階層構造(ネットワーク)図にする 4 学習が進む度に、結びつきを追加/修正し構造図を改訂していく (関連記事) ・直観を超えた何かが組み上がることを目指して→考える道具としてのdot言語 / Graphviz 読書猿Classic

    自分の理解を理解する→何をどのように分かっているかを可視化するISM構造学習法の考え方
  • 見積りの根拠出してくれっていったら、金くれって言われたよ

    システム屋の常識ってものが分からないのですが・・。 社内の業務をいくつかIT化することになった。ACCESSとかでも頑張ればできそうな感じだったんだけれど、システム屋にやらす方向で進めることになった。 何社かシステム屋呼んで、こっちのやりたいことをいって、概算金額出させてた。この時出てきた金額が350万~2200万。こんな簡単なシステムなのになんでこんなに金がかかるのか・・。なんでこんな差があるのか・・。(この時点でシステム屋業界に対しての不信感が社内に生まれることになった。)結局、一番低い金額で出してきたところが、営業の印象もなかなかよく、そこに決めることになった。 その後、細かい金額出させるために何度か呼んで、必要なことを事細かく伝えて詳細見積りとスケジュール表を出せっていった。それで出てきたのが、A3の紙1枚で4項目ぐらいのざっくり見積りと、設計期間・製造期間・動作確認期間っていう期

    見積りの根拠出してくれっていったら、金くれって言われたよ
  • システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道

    どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

    システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
  • 社内サーバインフラ勉強会(DB)

    2. 今回の目的 1. 「データを保存する」ということが、実際にど ういうことなのかを知る。 2. 中の動作を踏まえることで、効率のよいアプ リを書けるようになる。 3. 問題が起きたときに、その原因を突き止めら れるようになる。 一般論をメインとし、MySQL等の細かい 個別ノウハウは取り上げません。 3. おしながき 1. 「データを保存する」とはどういうことか 2. MySQLがディスクに書くまで 3. 仮想メモリとページキャッシュ 4. とっても複雑なストレージの動作 5. MySQLのインデックスとメモリの関係

    社内サーバインフラ勉強会(DB)
  • おすすめzsh設定 - 2011-09-05 - ククログ

    他の人がzshを使っているのを見ていると、「もっと便利に使えるのに」と、もやっとしたり、「え、その便利な機能ってなに?」と、発見があったりします。だれかに「この設定をすると便利ですよ」と話しやすくするために、今のzshのおすすめ設定をここに記しておきます。 もし、Emacsも使っている場合はおすすめEmacs設定もどうぞ。 ディレクトリ構成 長年漬け込んできたzshの設定がそこそこの量になっているので、以下のようなディレクトリ構成にして分類しています。主に、zsh標準機能の設定と追加パッケージの設定を分けるためにこうしています。 ~ ├── .zshrc # シェルを起動する毎に読み込まれる。 │ # ~/.zsh.d/zshrcを読み込んで │ # 標準機能の追加設定を行う。 ├── .zshenv # ログイン時に一度だけ読み込まれる。 │ # ~/.zsh.d/zshenvを読み込ん

    おすすめzsh設定 - 2011-09-05 - ククログ
  • エラーハンドリングモデル考察

    エラーハンドリングモデルに関する考察。 エラーハンドリング勉強会 ( http://partake.in/events/9874b92a-4cf0-4a20-a3fe-951239da5612 )にて発表。Read less

    エラーハンドリングモデル考察
  • コンサルタントがよく使うRFPの書き方:12項目で網羅的に作成

    情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。 新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト(月単価150万円以上)であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。 そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用い

    コンサルタントがよく使うRFPの書き方:12項目で網羅的に作成
  • 第1回 重なった30の不手際

    東日大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座(以下、口座a)に、振り込みが殺到した。 午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。 みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた(表-1)。 みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口(ぐち)」かである。 これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座

    第1回 重なった30の不手際
  • 新)4つの労働者階級 - Chikirinの日記

    階級といえば“資家 vs. 労働者”や、“経営者 vs. 雇われ人”という構造が定番ですが、最近は働く人の中に、新たな4つのグループが生まれてきていると感じます。 下図には淡い水色から濃い水色まで 4種類の人がいます。 一番上の (1) は、「システムを作る人」です。 ビジネスシステムを作る人の他、国のシステムを作る人もいます。 システムとは IT のことではなく、「物事の仕組み」という意味です。 「こういうビジネスをやろう!」とか「こういう制度を作ろう」と構想する人ってことですね。その人数はごく限られています。 次に少し濃い水色の (2) の人たち。 (1) の人はビジネスの構想が固まった後、(2)の人に、構想の実現に必要な各機能分野について「具体的な仕組みを作ってくれるよう」依頼(発注)します。 仕組みとして代表的なのは IT システムですが、それ以外にも、物流システム、マーケティン

    新)4つの労働者階級 - Chikirinの日記
    hrksb5029
    hrksb5029 2010/09/14
    激しく同意します。そして(1)(2)(3)の人たちは(4)の業務もある程度理解している必要があります。そのある程度はどの程度が妥当なのか難しいと思います。十分に把握していないと実用性のないシステムができてしまいます。
  • 1