システム設計を効率的に学べる「system-design-primer」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに エンジニアのみなさま、日々の学習本当にお疲れ様です！ また本記事まで足を運んでいただき本当に感謝です。 最後まで読んでもらえると幸いです。 システム設計はエンジニアにとって重要なスキルですが、いざ学習しようとすると幅広い知識と実践的なスキルが求められるため、独学ではハードルが高く感じられることも多いです。今回は、システム設計を学ぶためのオープンソースプロジェクト 「system-design-primer」 を紹介します。system-design-primerを活用することで、システム設計の基礎から応用まで体系的に学べるとの
顧客企業の求人情報から受託システム開発契約の単価を決める話（フリーランス・零細企業向け） - terurouメモ
準委任契約でシステム開発を受託する際の契約単価、どう決めてますか？ 相場といわれる額とか、過去の自分の実績額とか、もしくは自分の生活必要な年収からの逆算とか、勘や経験や度胸に近いもので決めてる人が大半なんじゃなかろうかと思います。ただ、それだけだと単価交渉する際に弱いんで、一例としてそれっぽい算出式を書いてみます。 フリーランスや零細企業が、いわゆる事業会社と直接契約するようなケースと考えてもらえばいいです。 算出式 (顧客企業の給与年額 × (1 + 休暇/残業係数 + 福利厚生係数 + 利益/リスク係数) + 受託側の一人当たりの年間経費) これで年額が出るので、月額単価の場合は 12 で割って、時間単価の場合は 1920 (160h×12）で割ってください。顧客企業側の1日の基準労働時間が8hではなく、7.5hとか6hだったりする場合もあるので、その場合の時間単価の計算は適時修正して
レビューしやすいコミット履歴でバグ削減 - Money Forward Developers Blog
こんにちは。 アグリゲーション開発担当の中川です。 今回は、みんなが大好きな構成管理ツール「Git」について話したいと思います。 私は Git を使い始めてから、バグの発生数が激減しました。 Git を使ったとある手法によってレビューが充実し、バグの少ないコードを書くようになったと考えています。 では、今回はその手法について紹介したいと思います。 ※ 本稿は Git 以外の第三世代構成管理ツール（Hg、Bzr など）にも適用するかと思いますが、Git の用語とコマンドを使って紹介していくため Git の基本知識が必要となります。ご了承ください。 レビューしやすいコミット履歴と、開発の流れで自然にできるコミット履歴の乖離 以下のようなコミット履歴があるとします。 1. wip: 仕様変更○○を行い始めた 2. wip: 仕様変更○○の続き 3. wip: ちょっと設計を変更、それと過去のバグ
組み込みデバイスの開発にこそ必要な「おもてなし設計」
最近、UIEvolutionのビジネスが、単なる「テクノロジーのライセンス・ビジネス」から、「プロトタイプの構築」や「おもてなし設計」ビジネスにシフトしている。一昔前は、「UIEngineのJavaに対する優位性を説明して欲しい」などの技術的な問い合わせばかりが多かったが、最近は「○○向けのデバイスを作っているんだけど、おもてなしの設計の段階から手伝ってくれないか」という話が増えているのだ。「おもてなし設計」の重要性が業界でようやく理解されて来た兆候だと解釈している。 そこで今日は、そんな傾向をさらに押し進めるために、スマートフォン・タブレット・家電などの組み込みデバイスの開発における「おもてなし設計」の重要性の話。 ここのところ「Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ」「なぜ横並びで展示されるAndroidタブレットを作
ミクロで今更な話をパラパラと - 山奥通信 増刊号
最近のまとめ(・ω・) 基本その1 PresentationやPersistenceといったレベルでのフレームワークは、それ自身が直接アプリケーション固有の課題を解決するわけではないのは言うまでも無いですが。 個々のフレームワークの汎用性と生産性のバランスが、個別の案件にたいして最適とは限らないという点については、まだまだ軽視されているんじゃないかと思ったりして(´・ω・`) 一般論を言えば、あるフレームワークの汎用性と、そのフレームワークを使用するコンテキストを特化したときの生産性は相反するわけで。 よって、個別のアプリケーション開発においては、アーキテクトはアプリケーションに最適なアーキテクチャを選択し、既存のフレームワークで足りない部分は補うものを自作したりするわけですが。 このアーキテクチャの選択・設計如何によっては、生産性は上がりも下がりもするし、品質にも影響するわけで。 まあ、
FF(16進数の掛け算)を覚えよう - やねうらおブログ(移転しました)
最近、あるプログラマと話していて気づいたのだけど、彼は16進数の2桁と1桁との掛け算(FDh×5とか)が出来ない。やり方自体を知らないのだ。彼はWindowsの電卓を立ち上げて計算していた。 そのときは「プログラマでなくともこんなこと知ってて当然だろ！」と思ったのだけど、その後、10人ぐらいのプログラマに出来るかどうか聞いてみたが誰も出来ない。 結局、「普通は出来ない」のだと私は理解した。しかし16進数の掛け算はそんなに難しくない。私が子供のころには、まわりにＦＦ(1×1＝1に始まって、F×F＝E1まで)を丸暗記している人がいっぱいいた。情報教育の一環として中学か高校で教えても計算の仕方ぐらい教えればいいのになぁと思っている。 前置きが長くなったが、以下にやり方などを書いておく。 ■ 16進数に馴染もう 16進数では、A = 10 , B = 11 , C = 12 , D = 13 ,
ITエンジニアの「やってはいけない」---目次：ITpro
設計・実装から運用，メソドロジまで，最新アンチパターンを徹底解説 先輩から教わったことのなかに多くの「やってはいけないこと」（アンチパターン）があるだろう。だが，その理由を問われると，うまく説明できないことがあるのではないだろうか。突き詰めて考えると，状況によっては「やっても構わない」こともあるし，技術の進化に伴い「やれるようになってきた」こともある。そこで設計，実装，テスト，運用，メソドロジの各分野について，取材を通じて浮かび上がった最新アンチパターンを徹底解説する。テーマごとに「どれくらいやってはいけないか」のレベルも表した。レベル３～レベル１の３段階あり，レベルの数字が大きいほど，やってはいけない度合いも大きい。 関連サイト： ■設計編 ■メソドロジ編 ■実装編 ■テスト編 ■運用編 ■サーバー運用編 ■データベース編 ■セキュリティ編 ■記録メディア編 ■方式設計編 ■内部統制編
Googleは日本企業を幸せにできるか？
米Googleが企業顧客（広告主）に対して発している主張は，とても明快だと感じている。「Googleの優れたソフトウエア（広告サービス）を，ユーザー企業は直接利用しましょう。無駄な中間業者を排除して，あなたもわれわれも幸せになりましょう」。これがGoogleの主張だと思っている。果たしてGoogleは，日本企業を幸せにできるだろうか？ 実は，Googleと似た主張を，サーバー用ソフトウエアの分野で行っている企業が存在する。米Microsoftである。筆者は，Microsoftの基本的な方針が，「ユーザー企業の情報システム部門がシステム・インテグレータの手を借りずに利用できるサーバー用ソフトウエアをリリースすることで，システム・インテグレータという中間業者を排除する」ことにあると思っている。「ソフトウエアの力」によって広告代理店を排除しようとしているGoogleと，システム・インテグレータを
思いの詰まったCIOたちの言葉
「ベンダーもユーザーも品質を軽視しすぎていた」、「改革には“背伸び”した目標が必要」、「論理と合理性ばかりではダメだ」---。 これらは、大手企業のCIO（最高情報責任者）たちが自社の情報システムや組織、ベンダーなどに対する思いを語った言葉である。いずれも、特番サイト「CIO情報交差点」の人気コラム『今週のCIO』で、日経情報ストラテジー編集部の記者が第一線のCIOの方々にインタビューしたものだ。 このサイトの前身であるITpro「Enterprise：IT経営」で「今週のCIO」の連載が始まってからちょうど1年。これを機に、過去に掲載された約50人のCIOの発言の中から、システム化の方向性やあるべき姿、マネジメントやコミュニケーションのあり方、ベンダーにぜひ言いたいことなど、印象的な言葉の数々を振り返ってみた。 システム化の方向性やあるべき姿について まず、過去の取り組みを振り返りながら
ソフトウェア開発者のための推薦図書
Code Complete 2 [ Code Complete第2版―完全なプログラミングを目指して (上・下) ] スティーブ・マコネルのCode Completeはソフトウェア開発者のための｢楽しい料理｣本だ。この本を読むということは、自分の仕事を楽しんでいるということであり、自分のすることに真剣であるということであり、もっと向上したいと思っているということなのだ。Code Completeの中で、スティーブは平均的なプログラマが読む 技術書は年に1冊に満たないと指摘している。この本を読んでいるという時点で、あなたはおそらく周りにいる開発者たちの90%と違う行動を取っていることになる。それもいい方向にだ。 私はこの本がすごく好きで、ここから自分のWebサイトの名前(Coding Horror)を取ったくらいだ。この本ではやるべきでない悪い例には"coding horror"アイコンで印
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
