スポンサーサイト

一定期間更新がないため広告を表示しています


  • 2010.11.01 Monday
  • -
  • -
  • -
  • -
  • by スポンサードリンク

エヴァンゲリオン 最後のシ者

 今日やっとのことでうってきました。

エヴァンゲリオン最後のシ者!

20:00頃からうってきたのですが、初あたりは"覚醒モード"でスタートです。

3連して、そのあと1箱飲み込まれたあとに、"暴走モード"突入で2連です。

前の台から思っていたことだけど、
2R確変は続かない・・・・

とはいっても、5000くらいでかかったので結果的には勝ちました。

幸先よいスタートでよかったです。


ただ、ホールに出たばかりで、
本当にまわらなかった・・・我慢が勝負かな・・・・


小心者

仕事でなかなかキツイことを言えない性格です。

最近、メンバーの仕事の邪魔?(結果的に)をしている人がいる。

ただ、話の内容は仕事の内容なのだ。

問題なのは、目的もなく話にくるということ。

その方は、別の会社の人なんだけど、結構空気が読めないようで、
ちょくちょく、実のない話をしにきている。 

その人としては、実があるのかもしれない。
ただ、今の状況で、このようなことが続くと流石に迷惑に思えてくることがある。

そういったときに、ハッキリ言える人になりたい。
(直接話をしにきた場合は、言ってます。)


何か言い方を考えているんだどけ、
結局、何を話したいかを考えると、何も話せなくなる。

この部分が今後の課題。


「相手のことをあまり深く知らなくても、注意を行うこと」


手にしたものと失ったもの

先週の日曜日に、パソコンと携帯電話それにスーツと靴を買いました。
総額、20万円くらいかな・・・

大きな買い物と思われがちですが、
もともと、パチンコで負けたお金が、パチンコで戻ってきただけなので、
特に得したというお話ではない。


それよりも失ったもの。。。


これは大きい。。。


さすがに、今回は真剣に考えていたこともあったので、
簡単には取り戻せそうにもありません。


大きい。
文字にしてしまうと、本当に大きい。


取り戻せることができるなら。取り戻したい。


新入社員さんへ

もう気付いたら4月ですね。
電車の中は、いつもよりフレッシュな空気が漂っているような感じがします。

4月から新たな生活が始まった新社会人さんへ!!!


今の気持ちを忘れずに!!!
辛いときや、嫌なことがあったときは入社したときのことを思い出すといいぞ!!!

「初心わするべからず」

よく言ったものですが、たまに初心に戻るのはいいことです。


特にIT業界へ新しい一歩を踏み出した皆様。

体調にはくれぐれも注意しましょう。(笑)
そして、もっと良いIT業界へしていこう!!!



優先度のつけ方

今週は、自社の用事で2日間ほど客先にお休みを頂いたのですが、久しぶりに出社してビックリ!!



大量にタスクが溜まっていました。(笑)



その数なんと、○○個弱・・・・



チェックボックスをつけた形でタスクを列挙し、優先度をつけて片付けることにしました。

□タスク1・・・
□タスク2・・・
 ・
 ・
 ・
□タスク9・・・

※ここで気をつけていることは、なんでも書くことです。
仕事のことでも、プライベートなことでも、思いついたことでもです。

だいたい、朝出社して行うのがこの作業。
その日にやらなければならないことを、まずは列挙することから始まります。

この後に優先度をつけていくわけだけど。
自分の中での勝手なルールをご紹介。

【自分流】
ヾ限が決まっているものは、まず記入していきます。

△匹譴らい時間のかかるものか工数を記入していきます。

キーマンを記入していきます。

で、完了。
って、"優先度"つけてないやん!!!


はい。その通りです。


優先度はつけません。
その代わり、仕事をするときに以下のように行います。

仝畫庵罎牢日の決まっているもの!!!
 これは、近々の予定のものでも、ある程度猶予があるものでも、まずは期限が決まっているものを全力で片付けます。
理由…午前中は非常に頭の回転が速い(自分以外も)ので、人とする作業でも早く片付くことが多いし、期限が決まっているものを後回しにしてしまうと、引っ掛かりが残って他の作業へ悪影響を与えると考えているからです。

⊂しでも空いた時間は、別のタスクを並行しながらやる。
理由…よく並行して仕事をすることを不得意とする人がいると思いますが、同時に実行できる仕事が増えることで、かなり効率とモチベーションを維持することができます。もちろん、一度に考えられることは一つまでです。でも、実際仕事をしているときに感じたことがあると思うのですが、集中できなくなってきたときって、何か別のことを考えながら、作業をしていることってよくあると思います。

例えば仕事をしながら、頭の中で音楽が流れていたり・・・CMのフレーズがリピートしていたり・・・

これを逆に利用します。先ほど書いたタスクのリストを常に目に入る位置へ置いておいて、暇があれば見るようにします。そうすることで、別の作業をしながらでも頭の意識がそちら向きます。問題なんかだと、別の仕事をしているときにでも、突然「あっ」という発想が出てきます。「あっ」ときたら、即座にメモをしておきます。これを繰り替えしていることで、その作業を行うときに、スムーズに進めることの環境が頭の中にできているのです。

8畍紊蓮見切りをつけながら作業を行う。
 私の場合、午後になったら見切りをつけながら作業を行います。午前中にできなかった作業を行いながら、ノートをチラホラ。これは、あの人にお願いしてみよう。とか・・・この作業はここまでにしようとか・・・その日に完結してしまう仕事もあれば、何かお願いしていることが解決しないと進まないこと。そういったことを考慮しながら、自分の中で整理をしていき、最終的に自分の考えた見切りがあっているかどうかを確認後、今日はここまで整理した。⇒タスク完了!とします。
これで、結構無くなる仕事があり、かつココロもスッキリして結構な相乗効果が得られます。

ぅ廛蹈哀薀爐篝澤彭の作業
 こういった作業はどうしても、あらかじめ予測した時間またはそれ以上の時間がかかるものです。これはどうしようもない事実なので、できるだけ前倒しが出来るように、着手当初は残業をしてでも前倒しをします(もちろん予定や体調は十分の考慮)。前倒しの効果は絶大です。気分的にも余裕ができるため、ゆっくりと考えることができ、思わぬ発想が浮かんだりもするものです。昨今のシステム開発は非常にタイトなため、前倒しなんてめっそうもない。と思っている人もいると思います。そういう状況になってしまったら、そのとき考えるものです。今まさにそういう状況という人は、いっそ自分の作業を他の人にふってしまいましょう。そんなことできないよ!という人。それはあなたができる人間だから仕事が他の人にまわせないけど、まわってくるのです。それ以外の人・・・その案件は諦めるしかないかもしれません。見切りも必要です。


BizBrowser 性能改善

今日はBizBrowserの性能改善にPonitをメモ書きします。

FlexViewオブジェクトの中身を操作するときは、毎行GetRowするのではく、MoveNextでアクセスする。
(Bizの宝箱から抜粋)
≪引用≫
for文内にGetRowの記述があると、都度FlexRowオブジェクトと全列に対応するFlexCell
アクセッサオブジェクトが生成されますので、1回の処理につき、行数×(列数+1) の
オブジェクトが生成されます。


■修正前
/* 重複チェックを行う処理 */

var row2 = FlexView1.GetRow( 0 );      /* (1) */
String s;
while( !row2.end ) {
    s = row2.FlexText1.value;
    for( var i = 0; i < FlexView1.RowCount; i++ ) {
        var row = FlexText1.GetRow( i );   /* (2) */
        if ( s == row.FlexText1.value ){   /* (3) */
            /*エラー処理*/
        }
    }
    row2.moveNext();
}

■修正後
/* 重複チェックを行う処理 */
var row2 = FlexView1.GetRow( 0 );

var s;
while( row2.position < FlexView1.RowCount - 1 ) {
    s = row2.FlexText1.value;
    var row = FlexView1.GetRow( row2.position + 1 );
    while( !row.end ) {
        if ( s == row.FlexText1.value ) {
            /*エラー処理*/
        }
        row.MoveNext();
    }
    row2.MoveNext();
}
(1) で1行目(先頭行)を取得しています。
(2) で i は0ですから再び(1)と同じ行を取得します。
(3) は(1)と(2)つまり同じ行の同じ列を比較しているので最初はエラーとなります。


▲ブジェクトを参照する場合は、
絶対パスで指定するのではなく、相対パスで指定する。

≪例≫
Form Hoge {
   Form HogeHoge {
      TextBox Text1 {
           Function OnLostFocus( e ) {
                /* Text2の内容を編集 */
                /* ■絶対パスで指定 */
                Hoge.HogeHoge.Text2.Value = "Hello";

                /* ■相対パスで指定 */
                ^.Text2.Value = "Hello";
           }
      }
      TextBox Text2 {}
   }
}
このように相対パスで指定することで、オブジェクトに対するアクセス速度が向上します。

Getする基点オブジェクト
どういった理由はわかりませんが、Getする基点オブジェクト(ここでは適当に命名しています)の階層を深くすることで、処理速度が向上します。
≪例≫
Form Hoge {
   Form HogeHoge {
      TextBox Text1 {}
      TextBox Text2 {}
      Form HogeHogeHoge {}
   }
}

このようなフォームクラスがあったときに、モーダルダイアログを表示する場合、Hoge.Get("test.crs");とするより、HogeHogeHoge.Get("test.crs");とするほうが、処理速度が向上します。
(環境に依存するかもしれませんが、今のところ向上しています)

ぅブジェクトツリー(勝手に命名しています)の構造をできるだけ簡素化する。
例えば、オブジェクトに独自のプロパティのようなものを定義したいとします。
≪例(必須チェックフラグを追加)≫
TextBox Text1 {
   Number HissuCheck = $FALSE;
   Function OnFocusOperation(e) {
       if ( this.HissuCheck ) {
           if ( this.Value == "" ) {
               //.MessageBox("入力してください");
           }
       }
   }
}

上記のように、テキストボックスに独自のプロパティのような扱いができる変数として定義することはよくあると思います。この場合のように一つだけ(HissuCheck)プロパティもどきを作成する場合はよいのですが、量が増えてくると処理速度が低下します。
≪例≫
TextBox Text1 {
   Number HissuCheck = $FALSE;
   Number AutoTrim = $FALSE;
   Number AutoZeroPadding = $FALSE;
   String Roll = "1";
   Function OnFocusOperation(e) {
       if ( this.HissuCheck ) {
           if ( this.Value == "" ) {
               //.MessageBox("入力してください");
           }
       }
   }
}

このようにオブジェクトに持たせるプロパティもどきを増やしていくと、オブジェクトのDelete処理やGet処理が遅くなるようです。どういった理由かはわかりませんが、オブジェクトツリーを複雑にすればするほど、この現象が発生します。
このような場合を想定して、以下のようにあらかじめ一つの変数で管理すると解決できます。

TextBox Text1 {
   Array Properties;
   this. Properties ["HissuCheck"] = $FALSE;
   this. Properties ["AutoTrim"] = $FALSE;
   this. Properties ["AutoZeroPadding"] = $FALSE;
   this. Properties ["Roll"] = "1";
   Function OnFocusOperation(e) {
       if ( this.Properties ["HissuCheck"] ) {
           if ( this.Value == "" ) {
               //.MessageBox("入力してください");
           }
       }
   }
}



工事進行基準

 一昨年くらいから、聞くようになった。この単語。 

来月から、原則システム開発プロジェクトへも適用が開始されるということから、 
会社の上司に本格的にお勉強しなさい命令がありました(笑) 

ってことで、出勤予定だった今日1日をつかって勉強中。 

とは言っても、基本的な知識はネットでちょくちょく調べていたので、 
その塵ばった知識を集約⇒自分の行動として定着させるのが今日の目的です。 

違う勉強もしたいんだけど、とりあえずは工事進行基準! 


せっかく少し纏まってきたので解説を! 
知っている人もいると思うけど、従来のシステム開発プロジェクトでは 
財務諸表なんかの会計処理を行う場合、工事完成基準という方法で売上計上をしていました。 
どういうことかって簡単に説明すると、 
システム開発が完了して、お客さんに納品した時点で売上として計上していたってこと。 
これって、実際の開発を行っているベンダーさんでは有用なのよ。 
だって、実績があがった時点で売上の計上を行うわけだから、何もかもが明確になってる。 
でも、株主さんなんかへは不親切な計上方法だったんだよね。 
(長期案件なんかでは、最後になるまで状況が公開されないのと同じだからね。) 

この工事完成基準を、2009年4月から工事進行基準での売上計上をしましょうってのが、 
今回の改正内容です。 

こっちも簡単に説明しておくと。 
工事進行基準ってのは、四半期ごとに進捗具合に応じて売上を計上するってことです。 
四半期ごとに計上することで、株主さんなんかには早い段階で状況を公開することから、 
いち早く状況を知ることができるっていうメリットがあるわけ。 

でもシステム開発をしている人達には、ちょっとしたインパクトが当然あるんだよね。 
だって、今までって結構、なーなーでやってる部分が少しはあったわけですよ。 
原価管理とか、進捗管理とか、売上管理とかね。 
そういった部分を、ある一定のタイミングでできるだけ正確に把握しなくてはいけないわけ。 
だって、システム開発が完了してない時点で未来がわからない状態で、 
売上を計上して、外部に公開しないといけないからね。 

この作業をしっかりやっていないと、会社の信用に繋がって 
仕事の受注が難しくなったり、株主離れなんかが起きて、結局自分の会社に跳ね返ってくるもんね。 
これは怖い!わけですよ。 

まっ、記事を読んでいて(まだ途中)抜け道もないわけではないようだけど。 
ただ、これだけコンプライアンすが叫ばれている世の中ですからね。 
そう簡単にはいかないだろうし、ましては民主党の小沢さんみたく、説明責任ができないようだと、会社の存続にかかわるからね。 


まっ、そんなこんなでいろいろと勉強してるんだけど。 
結構難しいよね。知ることよりも、次に生かすことって!


Google Gears その

 GoogleGearsの簡単なアプリケーション作成方法

1.まず、以下のサイトよりGoogleGearsをダウンロードし、インストールを行います。

  ■ダウンロードサイト

2.次にGoogleGears用の初期化ファイル(gear_init.js)をダウンロードします。

    ■ダウンロードサイト

※ダウンロード後に、スクリプトを読み込める位置へ配置し、
指定したファイルから読み込んでおけばOKです。
<script type="text/javascript" src="js/gears_init.js"></script>

3.以下のコードをスクリプトタグに埋め込みます。

if(window.google || google.gears ) {
  try{
var localServer = 
google.gears.factory.create('beta.localserver', '1.0');
  }catch(e){
alert( 'GoogleGearsのアクセスが許可されませんでした' );
  }
}

※上記コードにて、GoogleGearsの利用を許可するかどうかの確認メッセージが表示されます。

ここで、createメソッドの第1引数がポイントになります。
'beta.localserver'
今回は、ローカルサーバーオブジェクトを取得していますが、
GoogleGearのオブジェクトを取得する場合は、すべて上記のファクトリークラスの
createメソッドを利用して取得することになります。
(例)
ローカルサーバーオブジェクト:'beta.localserver'
データベースオブジェクト:'beta.database'
ワーカープールオブジェクト:'beta.workerpool'
HttpRequestオブジェクト:'beta.httprequest'
Timerオブジェクト:'beta.timer'

4.今回はManagedResourceStoreを利用するので、以下のコードを追加します。
if(window.google || google.gears ) {
  try{
      var localServer = google.gears.factory.create('beta.localserver', '1.0');
      var managedStore = localServer.createManagedStore('store');
  }catch(e){
      alert( "ユーザーによって、Gearの利用は許可されませんでした。" );
  }
}

※createManagedStoreメソッドに渡す引数は、ストレージ名称です。
今回は"store"としていますが、任意の名前を指定することが可能です。

5.そして、キャッシュされたファイルとサーバーのファイルとの差異をチェックするために、
  マニフェストファイルを作成しておきます。

{
// マニフェストファイル形式のバージョン(必須)
"betaManifestVersion": 1,

// ファイルのバージョン(必須)
"version": "20090303.01",

// キャッシュ対象のファイルを指定
"entries" : [
{ "url": "js/gears_init.js" },
{ "url": "js/message.js" },
{ "url": "index.html" }
]
}

※マニフェストファイルはJSON形式で記述します。

6.そして以下のように、マニフェストファイルをチェックする形式の処理を追加します。
if(window.google || google.gears ) {
  try {
      // GoogleGears用のローカルサーバオブジェクトを取得
      var localServer = google.gears.factory.create('beta.localserver', '1.0');
      if (localServer != null ) {
          // マネージドストア オブジェクトを生成
          var managedStore = localServer.createManagedStore('store');
  if ( managedStore != null ) {
              // ここで上記で作成したマニフェストファイルを指定する
              managedStore.manifestUrl = "mani/manifest.json";

             // 現在のキャッシュが保持しているバージョンを確認
             var currentVersion = managedStore.currentVersion;

             // キャッシュの更新
             managedStore.checkForUpdate();

             // タイマーイベントにて更新
             var timerId = window.setInterval(function() {

                 // 現在のリソースストアのバージョン
                 var newVersion = managedStore.currentVersion;

                 // キャッシュの更新が終了
                 if ( newVersion != currentVersion ||
                      managedStore.updateStatus == 0 ||
                      managedStore.updateStatus == 3 ) {
                      // ここでupdateStatusは以下の値を持つ
      //    0:更新タスクは正常終了
        //    1:マニフェストファイルのチェック中
        //    2:最新のマニフェストファイルにより、ダウンロード中
        //    3:更新タスクが異常終了
                      alert(("最新バージョン:[" + newVersion + "]");
                      alert(("キャッシュバージョン:[" + currentVersion + "]");
    
                      // 更新タスクの状態チェックを終了
                      window.clearInterval(timerId);
                      if ( managedStore.updateStatus == 0 ) {
                          // 更新が成功した際の処理
                          alert(("キャッシュの更新に成功しました");
                      }
               }
            }, 500);
         }
      }
  } catch(e) {
      alert(("ユーザーによって、Gearの利用は許可されませんでした。");
      alert(e);
  }
}else{
alert(("Google Gearsはインストールされていません。");
}

※この処理を、index.html(最初にアクセスするページ)のonloadイベント等に指定しておくことで、オフライン⇔オンラインの同期を最初に行うことができます。


尚、今回利用したクラスのAPIを参考程度まで・・・
■Factoryクラス
指定したオブジェクトを生成
 :create( className, version )
インストールされているGearsの、ビルドに関する情報を取得する
 :getBuildInfo()

■LocalServer
リソースストアを開くためのメソッド。存在しない場合はnullを返却する
 :createManagedStore( name, [requiredCookie] )

■ManagedResourceStore
指定されたマニフェストファイルのバージョンを見て、バックグラウンドでキャッシュの更新を行う。
 :checkForUpdate()

《 補 足 》
GoogleGearはDojoでも利用可能なようです。


GoogleGearsを試してみた

Googleが提供しているオフラインアプリケーションを実現するための
GoogleGearsを試してみました。

とは言っても、サンプルアプリケーションを動かした程度なのですが・・・

主な機能は以下の3点
.蹇璽ルサーバー
▲如璽織戞璽后SQLLight)を利用
ワーカープール

個々の機能は、Factoryクラスを経由して、
オブジェクトの生成から、操作までを可能とします。

簡単にキャッシュを管理する仕組みから、
ユーザが細かいレベルでキャッシュの管理をできるようです。

DataBaseアクセス自体も、ローカル単体で動かすことができることから、
パフォーマンス面でもだいぶ早いようです。

SQL自体は普通のRDBを利用する感じでJavaScriptから利用する事も可能。
トランザクションの仕組みを利用できることから、簡易なアプリケーションで利用する上では、申し分ないと考えられます。
(そもそも、オンラインになった状態でデータはサーバーに送信される仕組みで通常は構築するわけだから、簡単なデータ管理ができれば問題ないと思います)

また、重たい処理もワーカープールを利用することで、
バッククラウンドで処理を行うことで解消できるようです。
ただし、ワークプール内ではJavaScriptのAPIに制限があり、
独自のHttpRequestクラスやTimerクラスを利用して実装を行う必要があるようです。

■GoogleGearsダウンロードサイト

■GoogleGearsを利用した参考サイト
Remember The Milk


在宅勤務

 今月からシフト勤務が始まり、
今日は自宅でコソコソと勉強をしています。

テーマは、「クラウドコンピューティング」だったのだけれども、
今現時点では、在宅勤務について考えていたりします。
(この派生ブリがなとも(笑))

サーバーの仮想化技術から、
Saas⇒クラウドコンピューティング⇒ZumoDriveやDropboxのAmazonS3関連
⇒再び、仮想化技術⇒グリーンITへ・・・

そこで読んでいた記事の中に在宅勤務についてすこし触れられていた。
昨今、リーマンショック後の不景気が始まる前から、ニートの問題がすくなからず
とりあげられていたと思うんだけど、こういった人たちに働いてもらう目的もこめて
在宅勤務を上手く利用できればいいと思った。

自宅にいても仕事がある。
これって、ニートと呼ばれる人以外でも出産をして子供の世話が大変な両親や、
現役をさった高齢者の方まで、様々な人を雇用することが可能な話ではないでしょうか?
(そんなに上手く事は運びませんが)

でも、現在のインフラ技術があれば、
こういった労働形態も実現可能なのではないか?

そもそも、働いていない人は
人生の"目的"そのものが、そっちに向いていないからだと思う。
別に否定も肯定もしませんが、そういった人たちも生活するには最低限のお金が必要なのは、
自分自身も絶対わかっているはず。


そういった人達と一緒に仕事ではなく、自宅でできる趣味みたいな位置付けで、
生活ができれば、それはそれで企業にとってもメリットがあると思う。
ただし、社会に対する責任(CSR)があるから、最低限のルールは決めておこないと大変なことになるだろうけど、社会に出て数年が立つけれど、これだけはゆずれないところだと思う。

でも、その責任すら感じさせない環境が構築できれば、
理想的なのかもしれないし、もっと働く人が増えてくるかもしれない。

また、在宅勤務は人が移動しない分、グリーンITへも繋がると思う。
大阪では、マイカー通勤をやめよう!みたいない日があるけれど、
通勤自宅が削減されれば、その分エコじゃない?

まっ、想像するのは簡単な分だけ、実現するのは難しいと思うんだけどね。
でも、在宅勤務も捨てたもんじゃないと思うけどな。

もっと、これからITの世界は進化していくわけだし、
将来は、こういった環境で働ける人達が増えていくことを期待しています。


関連会社
株式会社ツクル
誠意と創意で技術を社会に活かすIT企業
          
          
時計
calendar
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
Amazon
selected entries
categories
archives
recent comment
recommend
links
profile
search this site.
sponsored links
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM
2008JUGEMキャラコングランプリ
キャラクターデザイン:磯崎洋助/「おしゃれひつじ」