「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - QiitaRegister as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
IPA ISEC セキュア・プログラミング講座：C/C++言語編 第6章 フェイルセーフ：体系だてたエラーハンドリング
このようにして、プログラムの中は多くのエラーハンドリングのコードで占められてゆく。 エラーの想定 ソフトウェアを構築する際には、起こりうるエラーをひととおり想定し、それらに対処するコードを書く必要がある。 エラーの想定は、要件定義から詳細設計に至る工程のどれにおいても行う必要がある。システムの機能性、構造、仕様を決めてゆく過程で、そこで起こりうるエラーも段階的に明らかになってくるからである。 その際、エラーへの対処方法を立案するのであるが、対処方法は概ね次の9つのパターンに分類できる（詳しくは後述）。 「スキップ」 「デフォルト値」 「別ロジック」 「入力の再要求」 「同じ処理の再試行」 「自己プログラムの再起動、OSの再起動」 「上位モジュールへの失敗の通知」 「他マシンへの役割の引継ぎ」 「プログラムの停止、マシンのシャットダウン」 エラーハンドリングの内容 エラーハンドリングには、一
人気のないインフラエンジニアってどんな仕事？ - orangeitems’s diary
インフラエンジニアの私 私自身はIT業界に20年以上前に入った時に、多分プログラマーやシステムエンジニアのキャリアパスに乗ることもできたはずなのですが、今はバリバリのインフラエンジニアになってしまっています。 「私、インフラエンジニアになります！」と言ったおぼえは無かったのですが、どうしてインフラエンジニアに収まってしまったのでしょうか。 そもそも、開発者と呼ばれるプログラマーやシステムエンジニアとの差分はどこにあるのかも考えてみたいと思います。 というのも、この記事が話題になっているからです。 b.hatena.ne.jp なぜ、人気がないのでしょうか。 私は、人気がないという指摘に関しては、否定することはできません。ITインフラ専門の企業ならともかく、ソフトウェア開発をメインで行う企業においては、進んでなりたがる人は少数派、変な言葉ですが「変わり者」の部類かと思います。 でも、誰かがや
プログラム設計の本質｜プログラム設計のコツや実践的な流れ
プログラムを作っていて何か困ったことが起きたとしたら、プログラムの設計が原因であることが多いものです。 例えば、プログラムを作っていてだんだん頭が混乱してきて訳が分からなくなったり、一つのプログラムの行数がものすごく長くなり困ってしまった経験がある方は多いでしょう。 また、他の人が作ったプログラムを読んでも、内容がすっと頭に入って来ない、同じような処理が至る所にあるけれど違いが分からない、そもそも何をやっているのかわからない、ということも日常茶飯事ではないでしょうか。 プログラムの設計は、そのようなことを起こさないために必要なのです。プログラムを作り始める「前」にしっかりと設計を行い、プログラムへ「意味」を与えることが、色々な失敗をしないために必要なのです。 この記事ではそんな「プログラムの設計」について、プログラムの設計の初心者向けに、特定のプログラミング言語や方法論に依存しない、一生通
サービスに求められるものを、6段階に分類する｜深津 貴之 (fladdict)
「サービスの体験をよくする」というのが、漠然としてどうすればいいかわからないとき、まずユーザー体験を6段階に分類するのをオススメします。 この図をベースに、 ・あなたのプロダクトの現状 ・やろうとする施策やアップデートが、それぞれどのレイヤーに属するかを見て、基本は低レイヤー（機能より）のものから、充足させてゆきます。 下記は、家を例にしたのユーザー体験です。 Lv 0. 存在しない家がない。寒い。そして何も解決してない。 Lv 1. 機能がある屋根と壁と床がある。とりあえず雨風がしのげる。色々と我慢すれば、まぁ生きていける。 Lv 2. 安全と安心地震で壊れない。水漏れしない、火災報知器がついた、ドアに鍵がかかるようになった。最低限の信頼性が担保できる状態です。 Lv 3. 使いやすい、わかりやすいまっとうに使えるか。家のなかで迷わない。生活導線が機能するか。キッチンや冷暖房などがスムー
AWSのログ管理ベストプラクティス
9. 収集 処理 分析 保存 データ収集と 保存 データ処理イベント処理 データ分析 データ 答え 分析前の前処理等、 いわゆるETL （抽出、変換、挿 入 ）的な処理 各サーバや、サー ビスからのログを 収集する ログに対して各種 分析をかける 収集したログを サーバやデータス トアに保存する 10. Amazon S3 Amazon Kinesis (Streams, Firehose) Amazon DynamoDB Amazon RDS (Aurora) AWS Lambda KCL Apps Amazon EMR Amazon Redshift Amazon Machine Learning 収集 処理 分析 保存 データ収集と 保存 データ処理イベント処理 データ分析 データ 答え Amazon Athena
バッチ処理の採用と設計を考えてみよう | メルカリエンジニアリング
こんにちは。メルペイで、決済・振込申請のバックエンドソフトウェアエンジニアをしている id:koemu です。 今日は、バッチ処理を行う理由について、考察を深めて設計に活かしていく話をしたいと思います。 はじめに バッチ処理とは、ある決まったタイミングで1つのプログラムが複数のデータを 一括処理 することを指します。この反対の言葉として、オンライン処理があります。オンライン処理とは、お客様の操作を初めとしたイベントをもとに 逐次処理 されるものです。OLTP(Online Transaction Processing)とも言います。 本エントリでは、バッチ処理を採用するにあたり、どういったユースケースが適切なのかを整理して、今後のソフトウェアの設計の指針にできることを目指しています。今回は、「バッチ処理を採用するとき」と「バッチ処理の設計」の2つについて取り上げます。 バッチ処理を採用する
システム設計時の脱Excelの手助けとなるツール - 聞こえないJavaエンジニアが適当に書き連ねていく
これは何 業務で設計する際に、Excelを使わずにドキュメントを作成したいときに使いたいものまとめ。 Excelだと辛いこと Excelで図を書こうとすると、図形の大きさや矢印の向き、吹き出しの位置の調整に結構時間を取られてしまう。 また、修正したときに差分確認がExcelだと出来ないのでどこを変えたのかがわかりにくい。 改善するにあたって重視するポイント 新たなツールを購入する必要が無い。 フリーのツールで実現できる。 導入が比較的容易である。 環境構築するのが難しくない。 テキストベースで資料を作成出来る。 テキストベースであるため、差分確認が容易である。 構文が難しくない ある程度パターンを把握すれば、直感的に書くことが出来る。 図の配置はツールにほぼ一任が出来る。 図によっては、ちょっと位置を変えたくなることがあるが、その時はオプションでちょっとだけどうにか出来る。 画像ファイルへ
変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita
この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ
Suicaのシステムがいかにすごいか仕組みを徹底解説 - 炎と硝煙にむせる開発現場から
Suicaの凄さ サービスを落とさないための「自立分散高速処理技術！」 ものすごい処理量をこなす緻密な速度改善 お金を扱うからこそ間違わない仕組み 当時は最先端の非接触ICカードを採用 非接触ICカードの歴史 年寄りも当たり前に使えるサービス だからSuicaは６０００万枚も普及した まとめ Suicaの凄さ ものすごい処理量（1日4000万件） 全然サービスが落ちない 年寄りも使っている Suicaがない社会なんて今や想像できないですよね？東京でSuica持ってない人はいないくらい普及していますし、レストランやコンビニでSuicaを使って買える場所も普通になってきました。普通に考えて、1日4000万件も処理して0.1秒以内に処理を完了させないといけないシステムなんて無茶苦茶難しくないですか？しかも、Suicaがリリースされたのは2001年です！ちょこっと調べてみたすごいブレークスルーの数
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
ユーザーが許可したくなるPush通知を考える｜sadakoa｜note
初めましての方もこんにちは、さだこえ (@sadako_a_ ) と申します。 DeNAに新卒で入社後、現在は株式会社FOLIOのデジタルプロダクトデザイナーとして、オンライン証券のUIデザインに従事しながら、スタートアップのデザイン支援を副業で行っています。 今記事では、主にアプリの機能として欠かせないPush通知に焦点を当て、記事を執筆します。 Push通知とはご存知の通りPush通知とは、アプリやwebサービスで何か変更や更新があった場合にお知らせをする機能です。一般的にこの業界で言われるPush通知は、Apple Push Notificationを指していることが多いと思われます。 その理由の1つとして、AndroidはPush通知に関してユーザーの許可を取る必要が無いからです。（ダウンロードする際にオプトインされるため、許可率は100%になる。） iOSやWeb Browser
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
Swift の HTTP ライブラリで苦しまないための自作 API クライアント設計 - Qiita
iOS 開発で必須とも言える API クライアントの設計手法を、初心者にもわかりやすく紹介します。 はじめに あなたは、どのように API クライアントを設計していますか。 まずはライブラリを選ぶでしょうか。 それとも、クラス図を書くのでしょうか。 なるほど、なるほど、ふーむ。 この記事では、もっと別のより良い設計方法を紹介します。 紹介する設計方法は、ほとんど設計知識のない状況から始めることができます。しかも、最終的にはあなたのプロジェクトにぴったりの設計を手に入れられる方法です。 対象読者 さて、この記事では、対象読者を次のように設定しています: どのような API 設計にしたらいいかわからない人 どのような API のライブラリを使うべきかわからない人 また、最終的には以下のレベルの目標を達成できることでしょう: あなたのプロジェクトの API 層設計者になれるレベル 目次 はじめに
プロの条件と開発プロセス ― ＠IT情報マネジメント
ソフトウェア開発に「開発プロセス」は必要なんでしょうか？ これはよく私が「開発プロセス」の標準化のお手伝いやトレーニングをする際に、最初にされる質問です。もし、この質問をされたら、これを読まれている皆さんはどう答えるでしょうか？ おそらく、いろいろなご意見、回答があると思います。「こうすればできる開発手順の標準化」第1回では、「もの作りのプロフェッショナル」という視点からこの問いが持つ意味について考えてみたいと思います。 （1）プロフェッショナルとは？ 筆者が20年くらい前に新人で会社に入り、ソフトウェア開発部門に配属されたとき、こう尋ねられました。 「ソフトウェア開発で、プロフェッショナルとアマチュアの違いは何か？」 恥ずかしい話、そのときは「給料をもらっているか否か」くらいしか私の頭には浮かびませんでした。しかし、そのとき教えられたのは、「仕事の成果（物）の品質を保証できるか否か」とい
システム開発 手順書 - Qiita
開発時に、いつもぶれるので、纏めておく。 各ドキュメントは、開発に必要か、どの程度の粒度で作るかを事前に確認すること。 要件定義 要件ヒアリング 要件の聞き込み調査、議事録質疑応答などで、Ｉｓｓｕｅリストを作成 業務フロー作成 とりあえず業務フローをつくって、情報整理。要件ヒアリングとも整合性を合わせる。 ユースケース作成 要件ヒアリングと、業務フローを元に、ユースケースの作成 画面遷移図 画面遷移のみを考慮。この時点で技術的な考慮は行わない。 画面モックアップ この時点のモックアップは作りすぎないこと。（でないとコストオーバー） 主要画面や技術的に確認する部分に特化させること。 作成したものは基本的に、以降の開発に生かすように作成 プロジェクトのトッププログラマに委任、後の開発時に技術的な部分を任せることも視野に入れる。 基本設計 基本設計になると、同時進行で作成する成果物が多いので、柔
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Django REST Framework における API 実装プラクティス | PyCon JP 2018
HTML5アプリにおけるパフォーマンスの基礎知識
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp
