GDPRについてソフトウェアエンジニアは何を知るべきか?
もう1つの重要なテーマは、プライバシバイデザインとプライバシバイデフォルトです。これは、今後、すべてのアーキテクチャへ実際に統合されるべきです。この規則以前は、プライバシバイデザインとプライバシバイデフォルトは、設計の自動的要素でしたが、人々は何かが起きるまで、セキュリティやプライバシにお金を払いたくありませんでした。GDPRは、今、これに対処する強力な動機付けになります。2,000万ユーロまでの価値を動機付けます。プライバシバイデフォルトはいろいろなことを意味しますが、本来、個人識別データとそのプライバシを適切に管理して、保護することを目的とします。これが一般的に要求するのは、例えば、特に個人識別情報の読み取りアクセスを含む、誰がいつ何をしたかという明白な監査証跡です。さらに、そのデータがいつ保存され、様々なレイヤを移動したかに注意を払い、システムからデータが漏洩するのを避けるために、適
システム思考とプロダクトマネジメント
システム思考とプロダクトマネジメント ※プロダクトオーナー祭り2021 Spring - PO祭り2021Springでの登壇資料です https://postudy.connpass.com/event/202404/
要件定義～システム設計ができる人材になれる記事 - Qiita
はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの？」 「要件定義ってなに？」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。 そのため、本記事では実装（プログラミング）を開始する前に必要となる、 『企画～設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装（プログラミング）に使用する時間
決済サービスを閉じるときのやることリスト | メルカリエンジニアリング
Merpay Advent Calendar 2020の20日目は、メルペイProduct EngineeringチームのVP of Engineeringを担当しているnozaqがお送りします。 2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。 取り組んだこと 決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご
物流倉庫の実績集計を自動化して現場の負担を軽減したはなし - ZOZO TECH BLOG
こんにちは、基幹システム部BASEチームの横山です。 突然ですが、ちょうど1年程前に行われたZOZOバイト革命は覚えていますでしょうか？物流倉庫「ZOZOBASE」で一緒に働いてくれる仲間の2000人募集や、基本時給のUP等で少しだけ話題になりましたね。 今回は、そんなZOZOBASEの人材を管理する上で一助となる作業実績の集計自動化について紹介します。 はじめに ZOZOTOWNは独自の物流倉庫を保有しており、ブランド様からの商品入荷や保管、お客様への発送まで独自のシステムを用いて行っています。 一口に入荷から発送までと書きましたが、その中には多種多様な作業があり、現場で働く多くの方々に支えられております。このような物流倉庫の戦略を考える上で実績管理や人材管理はとても重要になります。 そんな実績の集計ですが、少し前までは人手で行われていました。それを自動化する際、どのような要件で設計・開
10万円オンライン申請は「失敗」だったのか？自治体を混乱させた本当の要因
コロナ禍の経済対策として政府が国民に一律10万円を配る「特別定額給付金」のオンライン申請で自治体の業務が混乱している――。2020年5月から6月にかけ、新聞やテレビは連日、この話題を取り上げた。
システムの「作り逃げ」を許すな、運用保守を担う技術者の時間が奪われる
日経クロステック登録会員になると… ・新着が分かるメールマガジンが届く ・キーワード登録、連載フォローが便利 さらに、有料会員に申し込むとすべての記事が読み放題に！ 春割キャンペーン実施中！ ＞＞詳しくは
Linux におけるファイル I/O の基礎
すべてがファイルというモデルの Linux (Unix) において、ファイル I/O (以降単に I/O と書く) を知っておいて損はない。 この記事では、基本的なファイルと関連する I/O について、対応する Linux システムコールも併せて説明する。 次回はこれらを実際に Linux 上で確認する予定。 ファイルUnix におけるファイルとは、普通「通常ファイル」のことを指し、バイトがリニアに並んだデータ (byte stream) のことである。 ファイル内のバイトは読み書きが可能で、指定されたバイトから開始する。この開始バイトはファイル内の「位置」と考えることができ、ファイルポジションまたはファイルオフセットという。 通常ファイルとは別に、スペシャルファイルというファイルとして表現されたカーネルオブジェクトがある。Linux では、スペシャルファイルとしてデバイスノード・名前付き
/dev/randomではなく/dev/urandomを使うべき理由?
「Myths about /dev/urandom」が定説を覆す解説を行っている。Linuxを使う場合には/dev/urandomよりも/dev/randomを使う方が安全だといわれていたが、ブロックするというその特性や実際の内部実装などから考えれば、/dev/urandomが適切な選択肢であり、強い理由があって/dev/randomを使っているのでなければ/dev/urandomが十分なランダムデータの入手源であるという。 説明はLinuxカーネルを焦点にしたもので、マニュアルにも記載されている定石「/dev/randomは、疑似乱数生成器を利用する/dev/urandomよりもランダム性が高い」というのは、必ずしもそういうことではないと説明している。説明は概念的なところから実際の処理の流れ、暗号処理が使用している疑似乱数生成器などに触れ、最終的に/dev/randomを必要とする強い理
Suicaのシステムがいかにすごいか仕組みを徹底解説 - 炎と硝煙にむせる開発現場から
Suicaの凄さ サービスを落とさないための「自立分散高速処理技術！」 ものすごい処理量をこなす緻密な速度改善 お金を扱うからこそ間違わない仕組み 当時は最先端の非接触ICカードを採用 非接触ICカードの歴史 年寄りも当たり前に使えるサービス だからSuicaは６０００万枚も普及した まとめ Suicaの凄さ ものすごい処理量（1日4000万件） 全然サービスが落ちない 年寄りも使っている Suicaがない社会なんて今や想像できないですよね？東京でSuica持ってない人はいないくらい普及していますし、レストランやコンビニでSuicaを使って買える場所も普通になってきました。普通に考えて、1日4000万件も処理して0.1秒以内に処理を完了させないといけないシステムなんて無茶苦茶難しくないですか？しかも、Suicaがリリースされたのは2001年です！ちょこっと調べてみたすごいブレークスルーの数
コードを美しく保つためのたった一つの方法 - ボクココ
ども、@kimihom です。 とあるイベントでエンジニアの方々と話していて話題になった “クリーンなコード” について書いていくとする。 結論から言うと、コードを書かない のが最も美しく保つための条件だと考える。 サービス設計レベルでの"美しさ" を極めよう いくら優秀なエンジニアがサービスを作ったところで、優秀でないプロダクトマネージャーの元で開発をしてはいいコードを保つことはできない。優秀でないプロダクトマネージャーは、機能の多さで他社と差別化をしたり部下の仕事を作ろうとする。この機能が他社サービスにはあるから、うちにも取り入れよう。そんな自社サービスの思想を全く考えない機能をエンジニアに要求するのだ。 その時点で、どんな優秀なエンジニアでも作ったシステムは確実に複雑になる。例えて言うなら、小説家が１冊の本の中にうまく章立てをしてまとめていたのに、全く別の話題をその本に書けと言われて
load averageを見てシステムの負荷を確認する - Qiita
load averageとは ロードアベレージはシステム全体の負荷状況を表す指標。 「1CPUにおける単位時間あたりの実行待ちとディスクI/O待ちのプロセスの数」で表される。 システムのスループットを上げたい場合はロードアベレージを下げることを目標にする。 詳細な説明 Linuxカーネルはプロセス１つごとにプロセスディスクリプタを持っていて、そのstateメンバにプロセスの状態を入れて管理している。 プロセスの状態は以下のように区別される。 TASK_RUNNING: 実行可能な状態。CPUが空いていれば実行できる。 TASK_UNINTERRUPTABLE: 割り込み不能な待ち状態。ディスクI/O待ちなど、短時間で復帰するもの。 TASK_INTERRUPTABLE: 割り込み可能な待ち状態。ユーザの入力待ちなど、復帰時間が予測できないもの。 TASK_STOPPED: 実行中断になった
分かれたシステムをていねいにモノリスに集約する/Integrate decentralized systems to a monolith carefully
https://starttoday-tech.connpass.com/event/96477/ オウチーノではもともとサービスごとに異なる言語やFWを用いてシステムが分かれており、担当者もそれぞれ別々でした。そのため各サービスに精通した担当者が少なく、担当者は日々の運用で手一杯という状況下で、リプレイスもうまく進んではいませんでした。 そこでリプレイスよりも、分かれているシステムをひとつのモノリシックアプリケーションに集約することで、チームとしてよりワークすることをまずは目指しました。 一方で数多くのサービス機能を集約することは、そのモノリシックアプリケーションが急激に肥大化することも意味します。そこでモノリスにすることでの弊害をなるべく抑えつつ集約していく事例についてご紹介します。
システム技術者が「ちょっと変えるだけでしょ？」という、ユーザーからの注文に辟易する理由。
どうも、 「単純な要件でも、システムの作りによって大きく難易度が変わる」 「システムは決して規格品ではなく、作る人によって全く出来が異なる」 ということが直感的に理解しにくいところが、色んな問題の根本原因の一つなんじゃないかなあ、という気が最近しています。 しんざきは、システム開発関連の仕事をしています。元々の専門分野はDB屋なんですが、まあ他にも色々やります。 で、当然のことながらユーザーと色々やりとりをして、仕様を固めて設計して開発して、みたいなことも何度もやっているのですが、その際何度も何度も聞いた言葉の一つに、 「ちょっと変えるだけでしょ？」 という言葉があるんです。 恐らく、システム開発に携わったことのある人であれば、何度となく聞いた言葉ではないでしょうか。 この「ちょっと変えるだけでしょ？」という言葉は一種の呪いの言葉、パワーワード・キルのようなものでして、ユーザー側と開発側の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shiodaifuku.io
system-design-primer/README-ja.md at master · donnemartin/system-design-primer