ドットインストール代表のライフハックブログ

プロジェクトの軸をぶれさせないために、「目的」と「ゴール」、そして「戦略」と「評価」の4つの大きな枠で考えるフレームワークがあります。「目的」と「ゴール」は固めてしまい、いくつかの大きな戦略を立て、その戦略に沿った戦術を展開し、それぞれの効果を測定して戦術の練り直し、修正をかけていく、というやり方です。場合によっては半年おきに戦略を微修正させることもあるでしょう。 「Objective （目的）」「Goal （ゴール）」「Strategy （戦略）」「Measurement （評価）」で「OGSM」とか呼ばれるものです。アクションプランなどの評価手法と、考え方としてはよく似たものと思っています。 欧米のジョンソン・エンド・ジョンソンやP&Gといった外資系企業で取り組まれているフレームワークだそうです。僕は7年ぐらい前に大阪の会社にいたときにこれを知りました。 僕もいまは、上のシートのように

ミスリードを誘うタイトルでお送りしております。 トラブル対応は全く無駄だと思う。もちろん「トラブルが起きてるんだからトラブル対応しなきゃに決まってるだろ」といった話ではない。 いきなり話が変わるが、私の奥さんは看護師で、結婚当初私が風邪を引くと優しくしてくれるのかな？と思ってたけど、毎回どえらく怒られていた。曰く 風邪は基本的に予防できる病気 なのに風邪を引くのは怠慢な証拠 風邪を引くと会社休まないとだし、お金も時間も浪費するので本当に意味がない いや、全くごもっともでぐうの音も出ない正論としかいいようがない。 さて翻って、みなさん自身がおもりするシステムの健康をちゃんと見てるだろうか？ 上記の言葉をシステムトラブルに置き換えてみよう。 トラブルは基本的には予防し得る なのにトラブルを起こしてしまうのは怠慢な証拠 トラブルを起こしたら対応にかかるエンジニア工数や顧客対応の工数はドブに捨てて

Go deeper into fascinating topics with original video series from TED

今回のワンポイント Webシステムにファイルアップロードやダウンロード処理を取り入れているケースは多い。また、世の中にも、いくつかのサンプルソースや参考文献が出回っており、開発も行いやすいといえる。しかし、利用する場合には、アプリケーションサーバ全体の性能劣化やタイムアウトといったいくつかの問題を考慮することが重要だ。実際に発生したトラブル事例を交え、その問題点や注意事項について解説する。 ファイルアップロード／ダウンロード処理に潜むわなとは？ ファイルアップロードやダウンロードといっても、小さなファイルを扱っている場合は問題になる可能性は低い。しかし巨大なファイルを扱う場合や、通信回線の品質が悪く、ファイルアップロードやダウンロードにかかる時間が長い場合には、注意が必要である。 このような場合、以下の問題が発生する可能性がある。 サーバリソースの問題 無応答問題 タイムアウト問題 以降で

運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

今回から2回に分けて、位置情報をDatastoreに格納する方法をいくつか紹介します[1]⁠。 数値型で保存する 緯度経度の情報をデータベースへ格納するときに、もっとも簡単な方法が数値型として保存する方法です。緯度経度がとりうる値の範囲は、以下の通りですので、システムに必要な小数点以下の数字を考慮して型を決めましょう。 はてなフォトライフでは、写真に緯度経度のメタ情報を設定することができますが、高精度な緯度経度情報は必要ないので、型を以下のように指定しています。 latitude decimal(7,4) longitude decimal(7,4) decimal(7,4)という指定は、10進数で7桁のデータで、小数点以下は4桁まで格納するというものです。 あるオブジェクトの緯度経度を保存し、表示するだけならこれだけで十分ですが、位置情報を中心に扱うサービスになると、格納したデータを緯度

こんにちは、アシアルの中川です。 Google Mapsに表示する情報をMySQLのgeometry型で扱う方法を試してみました。 Google Mapsのある地点にマーカーを表示したりすることがある場合、 緯度・経度の情報で地点に表示させることができますが、 データベースにこの情報を保存する場合、lat(float), lng(float)とそれぞれカラムに保存する方法もあるのですが、この方法では各データの位置の関係が非常に扱いにくくなります。 Google Mapsで表示されている範囲内のデータのみ取得したい場合や、 ある地点から近い順に取得する場合などに面倒なことになります。 そこで、MySQL4.1以降で用意されている空間情報を扱う機能の「geometry」型を使用します。 「MySQL 4.1 リファレンスマニュアル :: 10 MySQL における空間情報の機能(日本語)」 「

BY Guy Kawasaki -in Japanese スティーブ・ジョブズから学べる教訓を解説する人は数あれど、同じ屋根の下で直に彼と働いた経験者はほとんどいない。取りこぼしたり忘れたりしないよう、僕がスティーブ・ジョブズから学んだ教訓のTOP12をまとめておこう。 1. Experts are clueless エキスパートはなんにもわかっちゃいない エキスパート（記者、アナリスト、コンサルタント、銀行家、グル）は自分じゃ何も「実行」できないから人に「助言」する。君の製品のどこが悪いと口では言えるが自分じゃ何ひとついいもの作れない。どうしたら売れるか口では言えるが自分じゃ何ひとつ売れない。どうしたら素晴らしいチームにできるか口では言えるが自分じゃ秘書ひとり管理するのがやっとだ。 だいたい1980年代半ばあのエキスパート連中は「Macintoshのニ大欠点はデイジーホィールプリンター専

未来予測関連の記事やレポートから「○○年に、○○になる」といった情報のみを 厳選し、西暦年や分野ごとに整理した未来予測のデータベースです。 各未来予測データには「類型」（予測、推計、計画、政策目標、決定 など）「出典」「資料名」「発表時期」が付記されています。 なおトップページの「TOTAL FUTURE」は未来年表に収録されている未来予測デー タ数の累計です。毎月20日に更新しています。 2024.06.20　未来年表データベースを更新 2024.05.20　未来年表データベースを更新 2024.04.20　未来年表データベースを更新 2024.03.20　未来年表データベースを更新　2024年データを書庫へ移動 2024.02.20　未来年表データベースを更新 未来年表 ： 更新情報

ご注意下さい 最近、「ワールドビジネスサテライト」の制作会社を名乗り、番組に取り上げるよう計らうので一定の費用を払え、という売り込みをする会社がある、との情報が寄せられました。「ワールドビジネスサテライト」を始めとする報道番組は、あくまで報道番組の視点から番組が独自に取材対象の選定にあたっており、当社や番組制作会社が取材対象者から金銭を受け取って番組を制作することはありません。 不審な働きかけがあった場合には、テレビ東京までお問合わせください。

ときどき、たまたま自分がそのとき考えていたことについてそれを補強するような材料が偶然たくさん集まってくる、なんてことがあります。そんな出来事があったので、ちょっとブログを書いてみようかなと。 以前に HBFav を作ったときこんなことを書きました。 Mark Zuckerberg は、いずれみんな、ニュースは友人知人経由で知ることになるだろうと言っていました。自分もそうなるだろうと思います。 4年ぐらいが経ちましたが、その思いは以前よりも増して確信めいたものになってきています。 ところで先日、Twitter の iOS アプリに「ニュース」という機能が追加されました。人によっては出てないそうなのでまだテスト中か、もしくは既に削除されているのかもしれないですが。 この機能についての自分の感想は以下のようなものでした。 もうすこし補足します*1。 Facebook や Twitter のような