ソフト屋とハード屋、どっちが得だと思う？ ー これからの社会を生きるエンジニアへ | mixture-art@Q
ちょっと仕事っぽい真面目な話でも。 （やべぇな、また長文になってしまった）・組み込み製品（家電とか工業製品）のファームウェアを書いてるひと ・スマホとかのアプリを書いているひと ・Web上で動くアプリケーションとか書いているひと ・組み込み製品のメカ外装もしくはロボティクスを設計しているひと ・組み込み製品の電気回路やその上で使われてる電気部品を設計しているひと という感じに限定させてもらう。 当然もっといろんな領域のハード屋、ソフト屋がいるがその人たちは今回の話ではお休みで(_ _) まずこれら技術領域の比較において極めて根本的な差を押さえておこう。 それは ルールを決めたのは誰だ？ ということだ。 ハード屋のお仕事というのは基本的には全て自然界の物理法則の上に成り立っている。 物質の組成、電気の性質、磁気の性質、重量、材質、力学、etc. 全て自然科学の研究の産物をいかにアレ
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita
Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
コンピュータ・情報科学系で読んでおきたい本 - Books
コンピュータ・アーキテクチャ ◎コンピュータの構成と設計―ハードウエアとソフトウエアのインタフェース（上）（下） / (基本)(名著) ○コンピュータ・アーキテクチャ―設計・実現・評価の定量的アプローチ / (易)(コンパクト)(CPUの歴史あり)(読んでおきたい) ○マイクロプロセッサ・アーキテクチャ入門 / (難)(名著) ○CPUの創りかた / (萌え本)(読んでおきたい)(入門) コンピュータの構成と設計~ハードウエアとソフトウエアのインタフェース 第3版 (上) 作者: デイビッド・A.パターソン,ジョン・L.ヘネシー,David A. Patterson,John L. Hennessy,成田光彰出版社/メーカー: 日経BP社発売日: 2006/03/16メディア: 単行本購入: 14人 クリック: 356回この商品を含むブログ (89件) を見るコンピュータの構成と設計~ハー
#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
複雑なJavaScriptアプリケーションを考えながら作る話
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アプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
DRY原則 - Strategic Choice
The DRY PrincipleDon't Repeat Yourself. どういうこと？重複したコードを書かないこと。その考えに基づいて設計すること。 適用範囲はコードだけではない。変化に強く柔軟なシステムを構築するために重要な考え方である。たとえば？「達人プログラマー」では二重化の発生する 4 つのパターンを解説している。やむをえない二重化 開発者に選択の余地が与えられない、環境が二重化を要求するような場合を指す。言語や環境などの二重化がある。不慮の二重化 設計の誤りによる二重化。手抜きによる二重化 二重化されることをわかっていながら、納期が直前だったりという事情でついやってしまう二重化。定数を直接コードに埋め込んでしまう 繰り返し使われるコードをインラインで書いてしまう 開発者間の二重化 プロジェクトの開発チーム同士で発生している二重化。あちらでもこちらでも同じ処理をしているのに
スタートアップ向け監視設計入門::Innova EngineerBlog
Image from Datadog はじめに こんにちは。エンジニアのみかみです。DevOpsを推進するための、ビルドツール、CI、監視系の設計や管理ツールの作成を担当しています。インフラエンジニアっぽいですが、実際はチーム内の困ったを拾うキャッチャーで、よろず相談屋をやっています。 さて、今回は監視についてのお話です。 最近、安価で柔軟に使えるクラウドサービスが提供され、新規サービスの開発が容易になりました。 しかし、サービスをリリースしたものの、ある程度サービスが認知されてくると突然システムが故障したり、予期せぬ不具合が突然発生し困ったことはないでしょうか？ サービスの稼働率を100％保証することは技術的に難しく、サーバー稼働率99.9％を保証しているサービスが多いですが、この数字でも年に9時間は停止する計算になります。100%の動作保証が難しいのならば、何時停止したとしても、すぐに
DB論理設計のノウハウ - Qiita
DB設計の概要を簡単におさらいした後、論理設計について主にまとめていきます。 DB設計の全体手順のおさらい DB設計は、大きく論理設計と物理設計に分けられます。 概念スキーマを定義します。 エンティティの抽出 エンティティの定義 正規化 ER図の作成 物理設計 論理設計の結果を受けて、データを格納するための物理的な領域や格納方法を決めます。 テーブル定義 インデックス定義 ハードウェアのサイジング ストレージの冗長構成決定 ファイルの物理配置決定 テーブルの構成要素のおさらい 行と列 行(レコード)：横のデータの組 列(カラム)：縦のデータの組 キー キーとは、DBのテーブルから特定のデータを引き出すための鍵です。 主キー：その値を指定すれば、必ず一行のレコードを特定できるような列の組み合わせのこと。一意にレコードを識別するためにある 外部キー：2つのデーブル間の列同士で設定するもの。参照
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
