公開が目前に迫った劇場版『シドニアの騎士』マスコミ向け以外で初の先行試写会がTOMにて開催！ | Tokyo Otaku Mode Blog
2015年2月21日。いよいよこの日がやって来た。 Tokyo Otaku Mode主催の劇場版『シドニアの騎士』先行試写会。 参加者による懇親会も兼ねたこのビッグイベントのスタートを2時間半後に控えた午後1時30分、私は会場となるTOMオフィス9Ｆの入口ドアをくぐった。ふだんはTOMイベントウォッチャーとして脇で取材し、レポート原稿を書くことを主な業務としているが、今回は司会進行の大役も仰せつかっている。TOMのイベントスタッフとともに、事前準備に臨む段取りになっていたのだ。 会場設営、映像ならびに音響チェック、会の進行確認、その他もろもろの準備が完了。あとは参加者の到着を待つだけとなった。 今回のイベントの参加予定人数は、抽選を突破した一般参加のエンジニア・デザイナーの皆さん、特別ゲスト・関係者、TOMスタッフを合わせて総勢50人。受付開始の15時30分を過ぎるとともに徐々に会場の席が
就職しました - たごもりすメモ
結局3月からそのまま働くことにしました。 先日のエントリを書いて以来、本当に多くの方から声をかけていただきました。ありがとうございました。本来なら個別にご報告するべきところですが、ちょっと数が多くて厳しいので、このエントリをもって報告にかえさせていただきます。 またいろいろと話を伺う中で考えたことなどもあるので、そちらについては別途エントリを書くつもりです。 様々な話を聞いた上で、1月末の時点では自分でもわかっていなかったことがわかりました。最終的に重視したのは以下の点です。 技術ベンチャーであること ベンチャー企業として大きな成功を狙っていること、またそれが有望に見えること 優秀なプログラマが同僚に多いこと 退職エントリに書いた観点のほかに、この3点が今回の自分にとって重要だということは後から見えてきたことでした。 ということで Treasure Data に入社しました。Softwar
『Amazon Web Services パターン別構築・運用ガイド』を書きました - プログラマでありたい
たまに呟いていましたが、AWSを題材に『Amazon Web Services パターン別構築・運用ガイド』という本を書きました。今回は、所属している会社であるNRIネットコム株式会社の同僚たちと書いています。 Amazon Web Services パターン別構築・運用ガイド 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬出版社/メーカー: SBクリエイティブ発売日: 2015/03/25メディア: 大型本この商品を含むブログ (1件) を見る 本を書いた理由 前回執筆した『Rubyによるクローラー開発技法』が好評だったこともあり、SBクリエイティブさんからAWS本を出さないかという打診を受けました。AWSは長年親しんできたこともあり、また仕事でもAWSに関する事業を進めている関係で、願ったり叶ったりでした。 一方で、やはり本を出すというのは大変です。私個人の問
2014年 Webアプリケーションフレームワークトレンド（PHP / Java / Ruby / Python / Perl） - Qiita
2014年 Webアプリケーションフレームワークトレンド（PHP / Java / Ruby / Python / Perl）JavaRubyPythonPerlPHP はじめに 一昨日、FIFA15 でサイドバックが前線に放ったフィードが直接入って80m強の超ロングシュートとなって困惑しました。 さて、話は変わりますが、2014年12月時点の TIOBE Programming Community Index によると、昨年と比較して最もランクアップしているプログラミング言語は、Visual Basic なんですね。 そんなプログラミング言語上位20位ですが、Webアプリケーションを構築するにあたって、どの言語を採用するかというのと同じく悩ましいのがどのフレームワークを採用するかということ。 フレームワークの選定基準はアプリケーションの要件はもちろんのこと、環境や開発者、その他にも様々な
論理削除がデータを汚している - jfluteの日記
ベクトルの違うデータ まあ、それは事実。 ただ、履歴をそのまま残したいということも事実。 いちいち削除履歴テーブルなんて作ってられないのも事実。 ※ここでの論理削除は、復活する論理削除じゃなく、物理削除の代わりとして履歴のための論理削除を指します。(復活する論理削除って、そもそも削除とは言えないって気も...) 本来、論理削除されたデータって... そのテーブルの定義するデータとはベクトルの違うデータ である考えます。 でも、わざわざ削除されたデータを保持するテーブルを作ると、それはそれで面倒なのでそのまま同じテーブルに持ったままにする。その方が扱いが簡単なことが多いから。削除フラグを true にするだけで済むから。 個人的には、業務上重要なテーブルに関しては、しっかりと「削除履歴テーブル」を用意して、本体のテーブルには常に有効なデータだけがある状態の方が、データメンテもプログラムも遥か
スタートアップ共同創業者の見つけ方、付き合い方、別れ方
多くの投資家やアクセラレーターが投資判断をする際に、「スタートアップのチームを見る」という発言をするように、最初期のチームメンバー（共同創業者）はスタートアップの成功を左右します。ではどのような共同創業者を選べばよいのか、というのが今回のスライドです。 ただチームに別れはつきものです。別れ方については、チーム作った時に別れ方を決めておくことが重要なので、それを併記しておかないとあまり実用的ではないのかなと思ったほか、であれば真ん中の付き合い方も必要、ということで、少し長くなりましたが、見つけ方と付き合い方と別れ方の3つを併記させていただきました。（付き合い方の部分は流して書いてはいますが、もっとドロドロしてるというご指摘もあるかと思います…）Read less
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Composer
Amazon Web Services パターン別構築・運用ガイド
https://jp.techcrunch.com/2015/03/02/jp20150302compathy/
