はてなで新しくWebサービスを作るときのインフラの作り方 - Hatena Developer Blog
この記事ははてなデベロッパーアドベントカレンダーを始めます - Hatena Developer Blogの17日目の記事です．昨日は id:yashigani_w の Promiseを学ぶためにSwiftでPromiseを実装してみた話 - yashigani?.days でした． こんにちは、はてなの id:wtatsuru です。はてなのインフラ全般をみています。 はてなでは、しばしば新サービスを構築する機会があります。正式サービスもあれば、はてラボ のような実験的サービス、内部の Microserviceの一部になっているものなど多種多様なものがあります。新規サービスのインフラを構築する際は、最小構成でありつつ後のスケールやメンテナンスを考えた仕組みを作っていくことになります。この記事では、2015年12月現在のはてなでの標準的な構成を紹介していきます。 新サービスの最小構成 こち
ナウいツールやサービスなどのまとめ - Qiita
国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 をもとにナウい感じのサービスなどをまとめた。分類がおかしいかもしれないのん コード管理 ソースコードは Git で管理しているところが増えている Git GitHub GitHub Enterprise: Enterprise 向け Gitlab Gitlab Cloud Gitlab CE: オープンソース Gitlab EE: Enterprise 向け BitBucket Stash: Enterprise 向け codebreak; RhodeCode Gitorious GitPrep GitBucket GitHubクローンまとめ 無料でGitHubのような機能を実現するための候補 | Act as Professional - hiroki.jp 料金 private repositor
これが大規模SIerな弊社のデファクトスタンダードな開発スタイルだ！！ - そこに仁義はあるのか(仮)
受託開発やっている、いまの開発スタイルを書く。 この前のブログはわりとフォーカスをしぼったはなしだったので、今回は簡単に全体のはなし。（書く順番が逆っぽい） 今回のプロジェクトではアーキテクトとして、この↓開発スタイルの構築と運用をしていて学び多い。 バージョン管理はGit プロジェクト用サーバーにGitBucketをたててソースコードを管理している。 オフショアと仕事をするなど、開発拠点がわかれることが多い。 ソースコードに対してロックをとったりしちゃうと、他の人が開発すすめられなくなるし、拠点別れて並行開発する大規模案件だからこそ、Gitを使う必要がある。 各開発者がブランチをきって開発をして、プルリクでレビュー依頼、からのマージをすることで、レビューが済んでいるソースしかmasterブランチに取り込まれない、というのもイイ。 弊社の”エンジニア”はみんな当たり前のようにGitを使って
2015年のWebサイトの作り方 at 67ws
The document summarizes quotes from three individuals about web design and development. Tim Berners-Lee notes that the primary principle of the web is universality, meaning it should be accessible from any device. Jason Fried argues that designing in Photoshop wastes time, as the design then needs to be rebuilt in HTML/CSS. Instead, one should design directly in HTML/CSS to allow for faster iterat
Gof デザインパターンの勉強メモ記事とブックマークまとめ
はじめに# 今年の目標は, デザインパターンの攻略! ということで, この一年でまとめた情報や書いた記事のブックマークページです. 過去記事は, Ruby と Java が入り混じっていたり, 気まぐれでどんどん更新していったので, とてもまとまりがないとおもう. 強引に一つのページにまとめてみた感じ… (*‘д`*) 一年の振り返り# Rubyist になる# 去年の 12 月から Rubyist になった. Rubyist になった日 | Futurismo そして, オブジェクト指向開発に触れることになった. 楽しかったので, 何も考えずにデザインパターンを使ってみたりした. しかし, これはのちに後悔することになった. 保守性よりもスピードを重視するべきだったのに, デザインパターンをつかって, 仕事が遅れてしまったという悲しい思い出. POSA を学ぶ# coursera で P
【総計５万はてブ！】QiitaのAdvent Calendarのはてブ数をNode.jsで集計してRactive.jsで表示する
【総計５万はてブ！】QiitaのAdvent Calendarのはてブ数をNode.jsで集計してRactive.jsで表示するNode.jsRactiveJS 総はてブ数: 50,681 総記事数: 3,818/5,350 テーマ数214 【完走✕】1位 Git はてブ数合計: 2018, 記事数: 22 【完走○】2位 Vim はてブ数合計: 1887, 記事数: 25 【完走✕】3位 クローラー／スクレイピング はてブ数合計: 1759, 記事数: 24 【完走✕】4位 Yahoo! JAPAN Tech はてブ数合計: 1700, 記事数: 22 【完走○】5位 Pepabo はてブ数合計: 1622, 記事数: 25 【完走○】6位 Webアプリエンジニア養成読本 はてブ数合計: 1413, 記事数: 25 【完走✕】7位 VirtualDOM はてブ数合計: 1370, 記事数
本日12月1日より、プログラマ有志による2014年の技術系Advent Calendarが各所ではじまる | gihyo.jp
本日12月1日より、プログラマ有志による2014年の技術系Advent Calendarが各所ではじまる 本日12月1日より、プログラマ有志による2014年の各技術系Advent Calendar（アドベントカレンダー）が一日目を担当する人のblogではじまっている。技術系Advent Calendarの数の増加傾向は今年も続いており、Qiitaを利用したものがとても多くなっている。 一般的なAdvent Calendarは、12月25日のクリスマスを楽しみに待つために、12月1日から24日までのカレンダーの日付それぞれの部分が扉になっており、1日ずつその日の日付の部分を開くと天使や動物の絵などが見えるという仕組みになっている（もちろん、様々なバリエーションがある）。 これに発想をえて、技術系Advent Calendarでは基本的に、12月1日から25日までの25日間、特定のプログラ
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Pinterestをスケールさせる中で学んだこと - ワザノバ | wazanova
https://www.youtube.com/watch?v=jQNCuD_hxdQ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 PinterestのMarty Weinerによる goto; conference 2014の講演。 「webサイトどうやってつくるの？」という創業期から、現在に至るまで、段階的にテクノロジースタックがどう進化したか。 現在のPinterestのシステムアーキテクチャの全貌。 個別のテクノロジーの選択理由。 などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード（初日の10:20のコマです。）できるので、そちらを見ていただいてもわかりやすいかと。 「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。
#JJUG＆#JGGUG 共催ナイトセミナー「2時間で分かる！次世代ビルドツールの本命Gradleの全貌」に行ってきました - Challenge Engineer Life !
タイトルがめちゃくちゃ長くなってしまった(^^; 今日のJJUGナイトセミナーはイベント告知後、すぐにキャンセル待ち状態となっていたので登録を諦めていたのですが…今日のお昼にみたら空きができてた！ので申し込んで行ってきました。 http://jjug.doorkeeper.jp/events/10618 Mavenはもう古い、時代はGradleだ！的な話はチラホラ聞いたことがありましたが、私は普段Mavenしか利用しておらず、実際にGradleを触ったことはないので、今日参加して色々と話が聞けて良かったです。 Gradleの本家サイト http://www.gradle.org/ Gradle 日本語ドキュメント http://gradle.monochromeroad.com/docs/index.html 発表の中でも紹介がありましたが、GradleはSpringやHibernateの
Android and iOS Development with Java EE 7
by Reza Rahman, Java EE/GlassFish Evangelist at Oracle on Jul 29, 2013 Mobile application development powered by platforms like Andriod and iOS is here to stay. In this heavily code driven session, we will show you how you can effectively utilize Java EE as the back-end ... Show more Mobile application development powered by platforms like Andriod and iOS is here to stay. In this heavily code dri
JavaOne報告会2014アーキテクチャトレンド
2014/10/18に開催されたJavaOne報告会での「アーキテクチャトレンド」での発表資料です。 （誤字があったので再アップしました）Read less
「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual - 元RX-7乗りの適当な日々
4/7に、LINEさんのオフィスで開催された「JVM Operation Casual Talks」。 一部で、Cassandra Casualだったのではないかという疑惑もありましたが、なかなかためになる話が多くて、あとできっと資料を見たくなる日が来そうなので、ちょっとまとめておこうと思う。 こちらもあわせて読みたい JVM Operation Casual Talks #jvmcasual - Togetter Understanding Memory Management of JavaVM in 15 minutes (@stanakaさん) https://speakerdeck.com/stanaka/understanding-memory-management-of-javavm-in-15-minutes @stanakaさん、どこでJVM使ってるのかと思ったら、今日は
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
俺の価値創造契約
〜新しい契約形態での受託開発サービス立ち上げ 1,396日間の記録〜 2010年11月に「価値創造契約」を発表してから4年。数案件を実施し、さまざまな経験をしてきました。その貴重なエピソードを発表します。 @XP祭り2014
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
従来型のSIビジネスはなぜ立ち行かなくなるのか～斎藤昌義×倉貫義人『受託開発のこれからを考える』レポート - エンジニアtype | 転職＠type
2014.09.15 働き方 SIビジネスが直面している問題、ビジネスモデルの未来を危惧する声が聞かれるようになって久しいが、実際のところ、問題の本質をどう理解し、どのように解決への筋道を立てていけば良いのだろうか。 弊誌ではこのほど、くしくもほぼ同時期にこの問題と正面から向き合った本を上梓した斎藤昌義（『システムインテグレーション崩壊』）、倉貫義人（『「納品」をなくせばうまくいく』）の両氏を招き、『受託開発のこれからを考える』と題したイベントを開催した。その模様を2回にわたってレポートする。今回は、イベント前半で両氏が行った、従来型SIビジネスに対する問題提起のパートを詳報しよう。 ネットコマース株式会社 代表取締役 斎藤昌義氏 1982年、日本IBM入社、営業として一部上場の電気電子関連企業を担当。営業企画部門に在籍の後、同社を退職。1995年、ネットコマース設立。産学連携事業やベンチ
IT業界の『多重下請け構造』は社会悪になりつつある - paiza times
Photo by Jonathan Kos-Read 今回のpaiza開発日誌は片山がお送りします。 SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか？ その点について今回は少し整理してみようと思います。 ■「多重下請け構造」とは何か 説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。 良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Conferences and events
コードレビューの話
