Twitter api ver1.1、痛いところ、痛くないところ
Twitter apiのガイドラインが改定になるそうです。 Twitter API v1.1でのAPI利用ルールの変更について こちらの日本語ブログは当たり障りのないところしか書いてないので、関係者は英語の方を読むことを強くおすすめします。 Changes coming in Version 1.1 of the Twitter API どうしてもこういう制約が増えるものは、ネガティブが極大化するので、ちょっと冷静に見てきましょう。 ■すべてのapiのエンドポイントに認証が必要、さらにレートリミットの変更 現在、検索apiなどはOAuthの認証が不要で、IPアドレス毎に一時間あたりのアクセス数が定められていますが、これが廃止になり、2013年3月までに全てOAuth認証を通した方法に変更を求めています。 さらに、１時間毎にapiにアクセス可能な数が、apiの内容によって変わります。今までは
ネットサービス系企業における、積み上げ型タスク管理の危険性
ネットサービスもそこそこの規模になると、後回しになっている、あっちゃこっちゃに細かい問題が積み上がってきます。 継続改善というサイクルの中で、改善していくわけですが、じゃぁこれをどのように処理していくか？という考え方の話。 一番最悪なのは、とにかく目についたものを全部直そうと言う考え方。 もはや維持フェーズに入っている事業担当の方なら、是非、どんどん直してくださいって話なんですが、多くのケースではそうではなく、未来に向かって、前に進むべきタスクが存在しているハズです。 事業の優先順位と連動せず、現場の開発者の判断で、気になったところを直していくと、必ず時間がかかります。見積もりには、判断ミスをするとか、考える時間やソースコードを検索するような時間が往々にして入ってませんからね。かつ、修正範囲が大きくなって、新しいバグの温床になることも少なくありません。 必ずスケジュールを切って、優先順位を
jQuery PluginのDate Pickerで、日付が1月なのに、2月になっちゃったりする不具合について。
コリスさんの以下の記事に引用されていたdate pickerのjQuery pluginがありまして、 リッチインターネットアプリケーションの実装時に検討したい30のUI | コリス こんな感じのものなんですけど、 DatePicker - jQuery plugin 現在時刻が2月の段階で、1月の値を渡すと、何故か2月の日付に初期化されてしまうという現象がありまして、いろいろ調べていたら、どうもバグらしいところがありました。 datepicker.jsに渡された日付の初期化文字列を日付データに変更するparseDateメソッドの戻り値のところ。 return new Date( y||now.getFullYear(), m||now.getMonth(), d||now.getDate(), h||now.getHours(), min||now.getMinutes(), 0 );
すごいコードが保守性悪いっておかしくないですか？
まず大前提として、その仕事が有能であろうがそうでなかろうが、属人性の高い仕事ってのは廃されるべきですよね。まぁ有能ならスルーしてても利益になればラッキーですが、逆に損失に繋がるなら嫌ですよね。 つまり属人性が高いことは基本的にリスクであって、その結果もたらされるメリットがあればラッキーというレベルなので、結局、成果に応じてケースバイケースなので、ルールとしては廃したいところですよね。 研究職なら良いんですが、それ以外の人だと、せいぜい20%ルールとか、お給料を出すカイゼン活動ぐらいで力を発揮して欲しいところですよね。 それに、人がいなくなっても企業には責任は残りますから、あなた死んだらどうなるんですか？明日失踪したらどうなるんですか？というリスクを管理しなきゃいけませんから、リスクは前向きに楽しむものですが、やっぱり儲かる形にするところまでは、本人がんばれって話ですよね。（つまり企業内なら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
