フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
cloudpackエバンジェリストの吉田真吾(@yoshidashingo)です。 昨日、DevLOVE現場甲子園2014東日本大会に参加して現場目線でのAWSセキュリティあるある的な話をして来ました。 その際にAWSのセキュリティ全般について知りたい場合に何を読めばいいか質問されたので、こちらで紹介しておきたいと思います。 AWSセキュリティセンター 1. AWSセキュリティ概要 ストレージデバイスの廃棄**の章では、ストレージデバイスが製品寿命に達した場合に、DoD 5220.22-M または NIST 800-88 に記載されている技術を用いてサニタイズを行ってから廃棄されるということが書かれています。 2. AWSセキュリティのベストプラクティス AWSの共有責任モデルを知る (1) Infrastructure servicesにおける共有責任モデル (2) Container
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース(OSS)を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
ソリューションアーキテクトの今井(@imai_factory)です。 今日はAWS Summit Tokyo 2014で東京リージョンのリリースが発表されたAmazon Kinesisと、これを便利に使うためのツールやライブラリのエコシステムを紹介したいと思います。これらは数も多いので何度かにわけてご紹介していきたいと思います。 初回となる今回はAmazon Kinesis自体についてのおさらいと、2014年8月時点でリリース済みのツール群のさわりを紹介します。ツールそれぞれのディープな話題については次回以降にご期待ください。 リアルタイムなデータ処理とAmazon Kinesis このブログを読んでいる方のなかにはデータの可視化や集計について考えてみたり、実際に開発・運用している方が多いのではないかと思います。実装方法にはいろいろあると思いますが、AWS上で行うのであればAmazon S
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす http://japan.internet.com/busnews/20111013/8.html で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。 (2011/10/19 08:14)ありがたい誤訳の指摘をいただいたので3カ所修正。 Stevey の Google プラットフォームぶっちゃけ話 僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは(しかもその印象は日々強まるのだけれど)、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやも
マイクロサービス(microservices)という言葉をご存知でしょうか? 今、エンタープライズ界隈のソフトウェアエンジニアの間でマイクロサービスという言葉がにわかに盛り上がりつつあります。 マイクロサービスはJames Lewis氏によって提案された言葉です。詳細については、彼がMartin Fowler氏と共著で書いた「Microservices」という記事を参照してほしいのですが、ようするにひとつのアプリケーションを、Railsのような一枚岩のアーキテクチャではなく、複数の軽量なサービスを連携させたアーキテクチャでつくろうというアプローチです。 上述の記事 では、マイクロサービスの特徴が九つほど上げられています。 サービスによるコンポーネント化:ライブラリではなく別プロセスで動作するサービスによってアプリケーションのコンポーネント化を実現している。 ビジネスケイパビリティに基づく組
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか? A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
DigitalOcean で運用している古いブログ用のサーバーに Tiarra を同居させていたが、WordPress から Middleman + S3 に移行したことで、 Tiarra のためにインスタンスを起動しているという勿体無い状況になった。 そこで、Raspberry Pi で Tiarra を動かすことにした。ついでに環境構築に Ansible を使った。 以下、構築した時のメモを残しておく。 環境 Raspberry Pi: Type B OS: Raspbian (Version: June 2014) 開発方法、Playbook の確認 Vagrant, Sahara で確認しながら Playbook を書いた。 Raspberry Pi に流しながら確認するのは非効率だなと思ったので、 Vagrantbox.es に公開されている Debian Wheezy 7.2
本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー(連載はVol.68〜)を購入して頂きたい。 本日発表したス
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
Webエンジニアのキャリアにはどんな道があるのか、先頭を走ってるいろいろなエンジニアに話を伺うインタビュー連載。第1回はグリーCTOの藤本さんです。 [撮影:平野正樹] CTOの役割 ──私舘野も最近CTO[1]になって、長年CTOをされている藤本さんが、CTOに対してどんな考えをお持ちなのかを聞かせていただければと思い、本日はお伺いしました。突然ですが、ぶっちゃけCTOってエンジニアなのでしょうか? 藤本:純粋な意味ではエンジニアではないですね。もちろん技術の知識は必要で、エンジニアリングも業務で兼ねたりしますけど、それだけじゃないですよね。 ──大きな技術ビジョンを描いて、それに対して貢献したりとかでしょうか? 藤本:そうですね。会社がある程度大きくなると、そこに経営視点で貢献したり、技術と事業を結び付けたりなど、全体の舵取りをする必要があります。そういう意味ではいちエンジニアでは
7 Patterns to Refactor Fat ActiveRecord Models という記事があり、読もう読もうと思いつつ1年くらい経ってしまった。 ようやく読んだので理解した内容を書いておく。 コード例は元記事のもの。 Rails で thin controller, fat model を心がけていると、model がマジで激太りしてヤバくなる。 実際に自分が仕事で書いている rails アプリも激太りしててヤバい。 この blog の筆者が作っている CodeClimate で C 判定をもらう程度には肥満体型になっている。 Mixinに抜き出さない! Model が太ってきた時に考えるのは ActiveSupport::Concern を使って感心事を抜き出して、Mixin にすることだと思う。 実際に手元のアプリでも models/concerns/ なんていうディレ
AngularJSアプリケーション開発ガイド を読みながら勉強したときのメモ。 HelloWorld AngularJS を入手する 公式サイトから angular.min.js をダウンロードする。 HTML を書く <html ng-app> <head> <script src="angular.min.js"></script> <script src="helloWorld.js"></script> </head> <body> <h1 ng-controller="HelloWorldController">{{message}}</h1> </body> </html> angular.min.js を読み込む。 ng-app ディレクティブを付けたタグの中が、 AngularJS のテンプレートとして処理される。 ng-controller ディレクティブを付けたタグの中
KAIZEN platform Inc. Senior Technology Advisor 伊藤直也氏(@naoya_ito) 2002年に新卒入社したニフティでブログサービス『ココログ』の開発担当となり、一躍有名になる。その後、はてなで『はてなブックマーク』など各種サービスを立ち上げ、2010年にグリーへ入社。2012年に同社を退職して以降は、フリーランスとしてベンチャーの技術顧問などを請け負う。自身のブログ『naoyaのはてなダイアリー』が人気 「Webアプリの実装で差別化は無理」という考えが変わった 現在、KAIZEN platform Inc.をはじめ複数社の技術顧問を務めている伊藤直也氏。「普段から、アウトプットの目的なく技術の勉強をすることはほとんどない」という性分から、今年上半期は「顧問としてベストプラクティスを提供するために知っておくべき領域」にフォーカスして情報収集を
子供が生まれたり、職場では人事改革が行われたり、@oranieさんがスマートフォンアプリエンジニアになったりと、生活が激変しつつある今日この頃みなさまいかがお過ごしでしょうか。 はい、乙カレー様です。くわのです。 職場ではずっとchef-server 1本で来ていたわけなのですが、ちょっと前からchef solo+Berkshelfを使い始めたりしている私達がいます。 きっとみなさんchef-serverとか強がりやがってやっと素直になりやがったなと思っていることでしょう。 (Chef-serverも使い方で便利ですよ) ドキュメント読んだらいいのかと思ったりもするんだけどBerkshelfのドキュメントがあんま綺麗じゃなくて困るというw ちゅーことで、ざっくり使い方を整理しました。あ、Berkshelfのバージョンは3です。 Berkshelf BerkshelfはCookbookの依存
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く