Pick up the 9th-gen iPad with two years of AppleCare+ for only $298
「Rubyにみるグローバルソフトウェア開発」というタイトルでの講演だった。 http://aiit.doorkeeper.jp/events/8871 まつもとゆきひろのコピーは作れるのか? コミュニティの運営とかは言語化できそうだけど、情熱をコピーすることはできない。心に灯をともすにはどうすればいいのだろう。それを10年間続けるにはどうすればいいのだろう。 OSSを作ることはそれほど難しいことではない。多分、気の利いたプログラマなら誰でも作ることはできる。 githubのようなサービスが開発を支援してくれるし、コミュニティ作りのコストを圧倒的に下げた。twtitterやFacebookやブログなどで開発を告知することも出来る。 にも関わらず、Rubyのように世界中で使われるプロダクトを作った人はまつもとさん以外にほとんど現れていない。OSSを作った人はいっぱいいるが、まつもとさんのような
そう。タイトル通りだ。筆者、江添亮はドワンゴに雇用された。一体、どのような経緯でドワンゴに入社するに至ったのか。また、どんな仕事をしているのか。それを説明するには、時系列を追って書いたほうがいいだろう。 2013年8月21日 ふとみると、以下のようなサブジェクトのメールが届いていた。 【ご相談】ドワンゴ主催の C++11, 14 に関する勉強会にスピーカーとしてご参加頂けないでしょうか C++11? C++14? なんと、日本にC++14などという単語を知っている企業があったのか。しかし・・・ドワンゴ? SPAMだろうか。いや、こんなにピンポイントなSPAMがあるわけがない。 それにしても解せないメールだ。ドワンゴといえば、もちろん、あの有名なニコニコ動画の企業だ。ニコニコ動画と言えばWebサイトだ。ニコニコ動画やその関連サービスの開発にC++を使っているのだろうか。いやまて、たしか子会社
普段、Chefを使って運用しているので、なかなか参考になる話だったというか、共感できる部分が多かったです。 「グリーにおけるChef導入事例」 荒井 良太 氏 @ryot_a_rai グリー Chefとは サーバの構築や設定更新を自動化するツール サーバのあるべき姿をRubyで記述しておくと、セットアップしてくれる 冪等性 Chef社のOSS 導入背景 運用担当者が秘伝の手順書でサーバのセットアップを手動でやっていた。 非効率 オペレーションミスの危険 Chefにより自動化し、安定運用をはかる リードタイム Chefにより自動化し、サーバのデリバリーを素早く行う Before Chef Debianパッケージ サーバの役割ごとのメタパッケージ 設定ファイルはスクリプトで生成 設定値 パッケージ内 サーバ管理システムに問い合わせ サーバ管理システム 社内のサーバ情報を管理しているシステム サ
失礼ながら、モリス節炸裂しまくりで面白かった。話上手だなぁ。 「社内システムの構造と設計、実装のはなし」 田籠 聡 氏 @tagomoris LINE(株) 開発支援室 LINE 「LINEというサービス、みなさんご存じない方もいらっしゃるとは思いますが(ry」 DevOps, by Ops, for Ops 今日言いたいことは、、、 社内システムほど他システムとの連携を考えよう 社内システムではJSON APIを使おう 必要なものを作ろう これから1つずつ説明します。 Webサービス今昔 Web2.0: マッシュアップ全盛期 OAuth流行、支配的に WebAPIの制限 GoogleMapsのJS APIの制限等 Open Web API トラフィック、レスポンスタイムが課題 ニコ動も最初はコンテンツストレージにyoutube使ってた 太平洋横断してTTLが コストは誰が払う? 互換性
By: @sage_solar – CC BY 2.0 私は会社で働き続けるにあたって、なるべく疲れないように働くことを大事にしています。 仕事で疲れがたまってしまうと、私生活にも影響が出てしまうばかりか、翌日以降の仕事にも支障が出てしまうためです。 私は過去に仕事の無理でうつ病になりかけたことと、身体を壊して入院した経験があるため、おそらく疲れに関してはかなり真面目に向き合っている方だと思います。 心身に異常をきたすことにより、長時間労働によって得た「時間」や「お金」などを回復期間に失いました。非常に虚しかったです。 (中略) 残業で得た「お金」「時間」「信頼」などは、心身の不調一発で消し飛びます。私は心の病と入院でそれを思い知りました。 via 長時間労働のリスクについて考える-持続可能な働き方をしていますか? そんな私が日々疲れないように働くために行っていることについて今回紹介したい
期待通り、面白い話だったのでメモを残しておく。 「サーバプロビジョニングのこれまでとこれから」 宮下 剛輔 氏 mizzy @gosukenator paperboy&co. テクニカルマネージャ サーバプロビジョニングとは プロビジョニングは3つのレイヤがある。 orchestration application service orchestration configuration system configuration bootstrapping cloud or vm image launch os install あまり厳密に捉えすぎる必要はない。とのこと。 Bootstraping 今日は割愛 Configuration ミドルウェアのインストールとか設定とか いわゆる構成管理ツール CFEngine, Puppet, Chef, Ansibleなど 会場は、Chef利用者多
本日、はてラボに新しいサービス「承認プラットフォーム 大承認」をリリースしました。 http://daishonin.hatelabo.jp/ 承認プラットフォーム大承認とは 承認プラットフォーム大承認は、インターネットで人に褒められた「承認」をまとめるウェブサービスです。 インターネットでは、情報を発信すると注目こそされるものの、その分批判的な意見も集まるので、情報を発信するクリエイターにとっては厳しい世界でした。 承認プラットフォーム大承認は、クリエイターのためのオアシスです。承認されたという思い出をまとめて、後からまとめて見返すことができます。 承認プラットフォーム大承認でできること インターネットで人に褒められた「承認」を投稿できます。 友達が承認されていたら、友達のページに投稿することができます。 めでたい承認には、寿ボタンでお祝いすることができます。 承認プラットフォーム大承認
by D. Sharon Pruitt 自分の持っている知性やクリエイティビティを天性のものであり、自分の力ではどうにもならないものと考えている人も多いのですが、それこそが人の限界を決める思い込みであり、「成長する思考態度」を持つと人は自分の知性や能力を伸ばしていくことができる、ということが、スタンフォード大学の教授である心理学者のCarol Dweck博士の行った20年にわたる研究で明らかになっています。 Fixed vs. Growth: The Two Basic Mindsets That Shape Our Lives | Brain Pickings http://www.brainpickings.org/index.php/2014/01/29/carol-dweck-mindset/ この、自分の成長を自分自身で邪魔してしまう「固定された思考態度」と、「成長する思考態度」
今では日常生活に不可欠なものとなったインターネットだが、その歴史はまだ浅く、幸いなことにわれわれはその誕生や発展に寄与してきた人々の“生の声”を聞くことができる。その1人がコンピューター科学者のレナード・クラインロック(Leonard Kleinrock)氏だ。インターネットの重要な仕組みの1つである「パケット通信」について数学的理論付けを行い、“インターネットの父”の1人とされる。 そのクラインロック氏が昨年(2013年)10月末、アイルランドのダブリンで、インターネットの誕生を振り返り、今後を展望する講演を行った。誕生から45年、同氏は自分たちの産物の成長と発展をどう見ているのだろうか。 100年以上前からあった「世界的ネットワーク」のビジョン 多くの人が知るとおり、インターネットの原型は1960年代に米国防総省のARPA(高等研究計画局)が構築したコンピューターネットワーク「ARPA
はじめに みなさんは単にネットワークという言葉を聞くと、どのようなイメージを持たれるでしょうか。単純にパケットが通過するだけのケーブル的なイメージでしょうか。それとも、ロードバランスやパケットフィルタリングを行う箱のようなイメージでしょうか。 これまでのネットワーク機器はRFC(RequestFor Comment)などの標準で定義されたプロトコルに沿って動作し、ネットワーク機器を利用するユーザはメーカーが用意した記述ルールに従い設定を行うのが一般的でした。このような状況からネットワークは受け身でしか利用できないイメージが定着していると思いますが、次世代ネットワーク制御技術「OpenFlow[1]」の登場により状況が変化しつつあります。 ネットワークをプログラムするOpenFlow OpenFlowを用いればネットワークの動きをプログラムにより制御することができます。ネットワークの動きを
Software-Defined Storage、これからのストレージ技術が実現する世界とはどのようなものか? サーバ仮想化が普及し、ネットワークの分野でSoftware-Defined Networkingが盛り上がる中、次の焦点はストレージ分野におけるSoftware-Defined Storageの登場だといわれています。 しかしSoftware-Defined NetworkingがOpenFlowのような標準技術を中心としたおかげで、それがどのような技術であり、どのような機能を備えているのかについて、おおまかなコンセンサスが存在したのに対し、ストレージ分野ではストレージの仮想化についてもSoftware-Defined Storageについても、どのような技術がそれに相当し、何を実現するものなのか、いまだ業界におけるコンセンサスが十分に得られているようには見えません。 VMwar
This post is long overdue; this isn’t a declaration of intent (any intent was long ago made real), just my reflection about my own path. I left the Python world a long time ago but I never took a chance to say goodbye. While I had moved on from Python years ago, I felt a certain attachment to it well past then, not quite admitting to myself that I wasn’t coming back. When my proposal for PyCon 201
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
2010年4月に入社した任天堂を1月末をもって退職しました。 今までの振り返りとこれからについて、自分の中での整理もかねて、流行の退職ブログぽく書きます。色々書いてたらくそ長くなりました。 4年前の決断 ちょっと昔に遡りますが、4年前、僕は人生の中でも大きな決断を強いられていました。「任天堂に入社するか?渋谷にある会社に入社するか?」です。色々な人にも相談をしましたが、7対3くらいで任天堂が勝っていたような気がします。そして、最終的には任天堂に決めました。決め手となった理由は、「自分の好きなことを仕事にしよう」と考えたからです。社会人になってから知り合った人は意外と知らなかったりするのですが、僕はテレビに出てマリカー64で優勝しちゃったり、FF13を2日間徹夜でやっちゃったりするくらいのゲーマーです。大学受験のときも息抜きにゲーセンに通い、アメリカ留学してたときも現地でPSPとDSを買って
2014年02月12日16:19 「反省してまーす」の国母が有能コーチだった件 カテゴリスポーツオリンピック omonet Comment(0)Trackback(0) 1: 風吹けば名無し 2014/02/12(水) 15:17:51.50 ID:rM7A0OKT 4年前 ↓ 現在(銀平野 銅平岡のコーチ) 40: 風吹けば名無し 2014/02/12(水) 15:28:09.30 ID:Fog5B4QT >>1 真ん中のおっさん、手袋が破れて見えた、顔の描かれた指みたいだな 4: 風吹けば名無し 2014/02/12(水) 15:19:54.57 ID:0djB4Hf6 そらオリンピック出るくらいやし 5: 風吹けば名無し 2014/02/12(水) 15:19:58.19 ID:8yY+MOw7 これは苦労を重ねた顔ですわ 9: 風吹けば名無し 2014/02/12(水) 1
システム構築には、大きく分けて4つのリスクがある。すべてのフェイズを通じて存在するそれらのリスクを正しく認識しなければ、システム開発は失敗に終わるだけだ。それらリスクへの対処法を紹介する。 システム構築は、成功率が30%といわれるほどリスクの高い投資である。そのリスクに無頓着で、業者に任せっきりにするのは、保険に入らずに車を運転するのと同じくらい危険だ。システム構築における主なリスクは、「認識的リスク」「人的リスク」「技術的リスク」「組織的リスク」である。 それぞれのリスクは、単独ではなく複合的に襲ってくることが多いので、常にリスクに対してアンテナを高くし、コスト・納期・品質に与える影響度と発生確率によって優先順位を付け、各リスクに応じて早めに対策を打つ必要がある。それには、間接的な情報だけに頼らず、3現(現場、現物、現実)主義を尊重することだ。例えば、現物を見て品質に対するリスクを知るこ
システム構築の上流工程強化(非機能要求グレード)紹介ページ 本ページの情報は、2023年8月時点のものです。本事業は終了しているため、お問い合わせには対応できません。 国民生活や社会経済活動における基盤となった情報システムは、「大規模化・複雑化」、「利用の広がり」の点からますます高度化しています。このような高度化に伴い、情報システムの安定的なサービスが求められるようになっており、複雑なシステムを構成する多様なコンポーネントがきちんと連携してそのようなサービスを提供する「システム基盤」の実現が重要になっています。そのためには、提供したいサービスに対応する要求を適切に定義する必要があります。 機能/非機能要求の相違点と課題 システム構築における要求には機能要求と非機能要求があります。このうち、非機能要求については、以下のような要件定義上の課題があります。 非機能要求グレードとは 「非機能要求グ
発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に「ギャップ」が生じます。具体的には、次の(1)~(3)のようなギャップが生じます。 要件定義すべき内容が抜けており、開発者に説明していない。 発注者が開発者に説明したが、何らかの理由で漏れた。 開発者が何らかの理由により誤認・拡大解釈し、実現範囲に取り込んでしまった。 機能要件に着目し、上流工程で実現したい情報システム像を伝え、発注者と開発者との不充分な合意形成が原因で発生する下流工程の手戻りを防止するための次のようなコツを集めたものです。 実現したい情報システム像について発注者と開発者が合意形成するために、伝える側が漏れなく正確に情報を提供するためのコツ 発注者と開発者との不充分な合意形成が原因で下流工程で発生する手戻りを防止するための先人の開発者のコツ 機能要件の合意形成ガイドは、「概要編」 と次の6つの技術領域のコツをまと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く