PR
Keyword Search
▼キーワード検索
Solis
２０代までは好き勝手に生きてきたのですが、３０代になって家族とともにおとなしく生きてきました。３０代後半でもう一度羽ばたこうと思っても、失速。また落ちてしまいました。もう一度空を羽ばたきます。 コンピューター関連の仕事をしております。
Calendar
Comments
http://buycialisky.com/@ Re:TinyURLのようなRedirectionの仕組み(06/30)
viagra cialis predamdiferencias entre e…
2026.05
2026.04
2026.03
2026.02
2026.01
2026.04
2026.03
2026.02
2026.01
2025.12
2025.11
2025.10
2025.09
2025.08
2025.11
2025.10
2025.09
2025.08
遍路と農業とＦＸの…
おばか社長さん
田舎で！情報起業 … 田舎っぽ こと 関根雅泰さん
パンラヤー（妻）は… samo1965さん
にわとりのあたま にわとりのあたまさん
アサワ（妻）はフィ… マハルナさん
さ.ゆ.り.… さゆり1995さん
田舎で！情報起業 … 田舎っぽ こと 関根雅泰さん
パンラヤー（妻）は… samo1965さん
にわとりのあたま にわとりのあたまさん
アサワ（妻）はフィ… マハルナさん
さ.ゆ.り.… さゆり1995さん
2006.05.31
カテゴリ： カテゴリ未分類
５月までの仕事の進捗をここに記しておきます。
備忘録の意味もあるので詳しい説明は省く、そこはご容赦願いたい。
１．事務所
あいちベンチャーハウスの入居は、よかったと思う。
自宅と違って、落ち着いて仕事ができる。
難点を言えば家から１時間かかるので、深夜に家を出て集中したいなと思うときに行けない。
部屋の隣が共同会議室なので、少しうるさいこと。耳をそば立てて戦略的な話でも聞ければと思ったが、体育会系の決起集会のようなもので参考にはならなかった。それ以来、会議が始まるとネットチャンネルを見たり、音楽を流したりしている。
事務所代４万円＋駐車場代１万円＝計５万円は、収入に乏しい私には辛いが全体のコストからすればたいしたことはない。生活費が毎月３０万円＋仕事の諸経費１０万円の計４０万円が、消えていく。
何も収入がなければ、再来年の３月に全部消えてしまう。来年の３月までに目処が立たなければ、厳しい状態に追い込まれるか。
５月中にスケジュールの同期ソフトウェアをとりあえず完成する公約だった。
これは先週の予想つかない問題があったせいもあるし、開発が進んでいない。４月から今月まで書いたコードは７００行ほど。べたにすると、１０行／日。実際に仕事に取り組んでいるときで、２０行／日。Rubyは効率が良いけれど、これではいかん。最終的には１００行／日にしないといけない。
効率の悪い理由としては、以下が考えられる
・自分の能力の問題
歳を取って遅くなった？プログラミングの仕事の経験不足？
古いアルゴリズム辞典のようなものは頭に入っているつもりだけれど、経験のないものについては頭の回転が鈍いか
文法的にいけるはずだと思っていても、実際には文法エラーが多い。エラー表示のあるものもないものも両方。IDEに頼らず、結局print文でエラーを見つけているところが多い。
・集中力の欠如。
行き詰ってしまうと、自分で解決しなければいけない。
なんか壁にぶつかってしまうと、ダーツを投げたり（ダーツ盤を買いました）、テレビゲームをしたり、Ｈなアダルトビデオなどを気分転換にみる。しかし気分転換ですまなくなり、本気でゲームをしたり、ビデオをみてムラムラしてしまうのでいかん。周りにゲームなどを置かないようにした方がいいかな。
答えを見つかる瞬間というのは、ゲームなどをしていながら、一瞬それが目に入らず別のことを考え始めるときに起きることがある。それを待っているんだけれど。目はテレビを見つめているんだけれど、まったく別事を考えているというような。
こんなに集中してできるところはないので、すごくありがたい。
他にプログラマーがいれば、つまんないことでも尋ねてみてすぐに答えが返ってくることもあるし、しゃべっている間に自分で答えを見つけてしまうこともある。
まじめにこつこつをやるということが苦手で、ぱっと思いついたらタタタタとやるほうである。プログラミングでも得意・不得意はあるし、事業でも得意・不得意はある。
この変だろうな。
３．開発内容
それから、(a)古いデータから新しいデータをつくり、(b)それぞれのスケジュールを更新しなくてはならない。
bは、データの新規作成、更新、削除をする。更新と削除は、元のデータを探さなくてはならないが、なんとかなりそうな気がする。日付がキーになるので、その日付でデータを開きデータを入力して更新ボタンを押す、あるいは削除ボタンを押せばいいのだから、なんとかなるだろう。
aについて、じっくり考えている。
２つのスケジュールを比較して、元が同じデータであるかどうかを見極めるのが難しい。
スケジュールデータに番号がついていれば同じデータとして見当がつくが、まったく別のシステムのため比較対象を探すのが難しい。件名が変わったのか、日付が変わったのが、時刻が変わったのが、それともまったく別のデータとして作成されたのか、データをみて判断しなくてはならない。
問題はスケジュールデータはデータの更新日時がないケースが多いので、２つのスケジュールのうちどちらが新しいかわからないし正しいかわからない。更新日時がない場合は一方を「正しい」と仮定するしかないだろうな。Google Calendarは作成日時と更新日時がわかるので、将来的にはそれを基準にした方がいいかなと思うが利用者の利便性によるのでなんともいえない。
次のようなアルゴリズムを考えている。
２つのスケジュールをＡとＢとする
(1) ＡとＢを比べて、まず同じデータと思われるのを結びつける
結びつける方法は、件名、日付、時刻のうち変化が少ないものを元は同じデータであったとする。
それを一つ一つ、結び付けてみる。
(2) Ａを基準に考える。
ＡとＢが結び付けられているならば、Ａを採用する
Ａが存在しないＢならば、Ｂを新しく採用する。
もう一つのアイディアは、スケジュールの件名にIDを振ってしまうこと。
そうすれば何が変わっても同一かどうか判断できる。しかし、これは利用者がつけるわけにもいかないし、プログラムが勝手にＩＤを振ってそれが見えてしまうので、見栄えが悪くなってしまうかもしれない。
備忘録の意味もあるので詳しい説明は省く、そこはご容赦願いたい。
１．事務所
あいちベンチャーハウスの入居は、よかったと思う。
自宅と違って、落ち着いて仕事ができる。
難点を言えば家から１時間かかるので、深夜に家を出て集中したいなと思うときに行けない。
部屋の隣が共同会議室なので、少しうるさいこと。耳をそば立てて戦略的な話でも聞ければと思ったが、体育会系の決起集会のようなもので参考にはならなかった。それ以来、会議が始まるとネットチャンネルを見たり、音楽を流したりしている。
事務所代４万円＋駐車場代１万円＝計５万円は、収入に乏しい私には辛いが全体のコストからすればたいしたことはない。生活費が毎月３０万円＋仕事の諸経費１０万円の計４０万円が、消えていく。
何も収入がなければ、再来年の３月に全部消えてしまう。来年の３月までに目処が立たなければ、厳しい状態に追い込まれるか。
５月中にスケジュールの同期ソフトウェアをとりあえず完成する公約だった。
これは先週の予想つかない問題があったせいもあるし、開発が進んでいない。４月から今月まで書いたコードは７００行ほど。べたにすると、１０行／日。実際に仕事に取り組んでいるときで、２０行／日。Rubyは効率が良いけれど、これではいかん。最終的には１００行／日にしないといけない。
効率の悪い理由としては、以下が考えられる
・自分の能力の問題
歳を取って遅くなった？プログラミングの仕事の経験不足？
古いアルゴリズム辞典のようなものは頭に入っているつもりだけれど、経験のないものについては頭の回転が鈍いか
文法的にいけるはずだと思っていても、実際には文法エラーが多い。エラー表示のあるものもないものも両方。IDEに頼らず、結局print文でエラーを見つけているところが多い。
・集中力の欠如。
行き詰ってしまうと、自分で解決しなければいけない。
なんか壁にぶつかってしまうと、ダーツを投げたり（ダーツ盤を買いました）、テレビゲームをしたり、Ｈなアダルトビデオなどを気分転換にみる。しかし気分転換ですまなくなり、本気でゲームをしたり、ビデオをみてムラムラしてしまうのでいかん。周りにゲームなどを置かないようにした方がいいかな。
答えを見つかる瞬間というのは、ゲームなどをしていながら、一瞬それが目に入らず別のことを考え始めるときに起きることがある。それを待っているんだけれど。目はテレビを見つめているんだけれど、まったく別事を考えているというような。
こんなに集中してできるところはないので、すごくありがたい。
他にプログラマーがいれば、つまんないことでも尋ねてみてすぐに答えが返ってくることもあるし、しゃべっている間に自分で答えを見つけてしまうこともある。
まじめにこつこつをやるということが苦手で、ぱっと思いついたらタタタタとやるほうである。プログラミングでも得意・不得意はあるし、事業でも得意・不得意はある。
この変だろうな。
３．開発内容
それから、(a)古いデータから新しいデータをつくり、(b)それぞれのスケジュールを更新しなくてはならない。
bは、データの新規作成、更新、削除をする。更新と削除は、元のデータを探さなくてはならないが、なんとかなりそうな気がする。日付がキーになるので、その日付でデータを開きデータを入力して更新ボタンを押す、あるいは削除ボタンを押せばいいのだから、なんとかなるだろう。
aについて、じっくり考えている。
２つのスケジュールを比較して、元が同じデータであるかどうかを見極めるのが難しい。
スケジュールデータに番号がついていれば同じデータとして見当がつくが、まったく別のシステムのため比較対象を探すのが難しい。件名が変わったのか、日付が変わったのが、時刻が変わったのが、それともまったく別のデータとして作成されたのか、データをみて判断しなくてはならない。
問題はスケジュールデータはデータの更新日時がないケースが多いので、２つのスケジュールのうちどちらが新しいかわからないし正しいかわからない。更新日時がない場合は一方を「正しい」と仮定するしかないだろうな。Google Calendarは作成日時と更新日時がわかるので、将来的にはそれを基準にした方がいいかなと思うが利用者の利便性によるのでなんともいえない。
次のようなアルゴリズムを考えている。
２つのスケジュールをＡとＢとする
(1) ＡとＢを比べて、まず同じデータと思われるのを結びつける
結びつける方法は、件名、日付、時刻のうち変化が少ないものを元は同じデータであったとする。
それを一つ一つ、結び付けてみる。
(2) Ａを基準に考える。
ＡとＢが結び付けられているならば、Ａを採用する
Ａが存在しないＢならば、Ｂを新しく採用する。
もう一つのアイディアは、スケジュールの件名にIDを振ってしまうこと。
そうすれば何が変わっても同一かどうか判断できる。しかし、これは利用者がつけるわけにもいかないし、プログラムが勝手にＩＤを振ってそれが見えてしまうので、見栄えが悪くなってしまうかもしれない。
お気に入りの記事を「いいね！」で応援しよう
【毎日開催】
15記事にいいね！で1ポイント
© Rakuten Group, Inc.
