夏休み最終日もインターンシップ最終日ではない
今日で夏休みは終わり。
けどインターンシップは終わらない。金曜日までですね。
というわけで金曜日まで学校はお休み。
なんでこんなことになってしまったのか。
元々お盆の前後に2週間ずつインターンシップの期間が決められていた。
このお盆前の方で行くもんだと思ってたらそうはならなかったというだけの話ではある。
ただこの日程に決まった背景にはこの会社が多くの学生を実習生として受け入れてくれたという事情もある。
確か本科生3人・専攻科生2人を受け入れてくれたんだったかな。
本科生は1週間で足りるから、本科生をお盆前の2週間に1週間ずつ2人と1人で受け入れてもらったのだろう。
そして専攻科生はしゃあないので夏休みからはみ出るけど、お盆の後の2週間に2人受け入れてもらおうと。
おそらく本科生が2人ならこうもならんかったと思うのだが、希望する学生をできるだけ受け入れてもらったということだろう。
専攻科生ならしゃあないで済まされるのかという話だが、どうも担当教員が学生課に問い合わせたらそう帰ってきたそう。
専攻科生の出欠管理はまぁいい加減なのでそれでもいいやってことらしい。
けど本科生は絶対にはみ出てはいけないといわれたそうで、まぁ苦肉の策だったのだろう。
幸いなことにはみ出た2日間のうち木曜日は研究の日なので、欠けてもあまり影響はない。
なので実質的には金曜日の1日のみ欠席するだけと言える。なのではみ出るという事の割には大したことはないと。
こうして夏休みが2日延びたようなことになってしまったが、
実際は逆で夏休みはインターンシップ開始前に終わってしまったようなもんである。
インターンシップ終わって学校に行ったら研究発表の準備をせなあかん。
というわけで夏休みなのに全く休まる気がしない、夏休みの後半だったなと。
まぁ前半は旅行いったりそれなりに休日を活用した気はするんですけど、お盆明けからは全く休み無しですからね。
いやさすがに土日は休みですけど。そうして夏休みが去っていく。
Author : hidemaro
Date : 2011/08/31(Wed) 21:59
記録 | Comment | trackback (0)
VBでコントロールを自作する
PC間で通信を行うソフトウエアを作って欲しいとインターンシップ2週目の課題が出された。
これは特に内容は決めてないから好きに決めて欲しいと言われた。
そこでつくることになったのがオセロである。
まぁ無難なネタではあるが。
例によってVisual Basic 6で開発する。
まぁ他の開発環境でもいいのかなとおもって開発機を見てたらVB6とVC++6しかなかった。
当時のVisual C++といえばどこがVisualやねんと言われたものである。
こんなもんで開発してたら終わらんわ。というか使い方知らん。
それならVB6の方がよっぽどましである。
というわけでどうやったら通信できるかなと調べてみた。
例によってWinsockのコントロールがあるらしい。
これをペタッと貼って使えばいい。
それにしてもコントロールを貼らないと使えないってのはどうなのよ。
まぁVBだからそれでもいいのかもしれんが。
ここで実習生2人で役割分担して開発することにして、
僕が通信に関わる部分、もう1人がインターフェースに関わる部分をやることとした。
この2つの部分をつなぐためにはどうしようかと思った。
そこでとった方法がカスタムコントロールを作るという方法。
ここにWinsockのコントロールを貼って、それでイベントやサブルーチンを定義する。
そしてインターフェース側から使ってもらうと。
わざわざコントロールという形にしたのはWinsockもTimerもコントロールの形だったから。
イベントの定義の仕方だが、
Public Event StartGame(ByVal First as Boolean)
とサブルーチンを定義するように定義するわけだが、使い方は少し違う。
RaiseEvent StartGame(True)
RaiseEventが必要。
使う方は Othello1_StartGame とかいうサブルーチンの内容を書くようにすれば使える。
まぁこのあたりはVB.NETでも似たようなもんです。
そしてC#でもこの要素は取り入れられている。
ただ僕はこれまでEventを自分で定義して使ったことなかったかな。
まぁけどEventってのは便利なもんだと思うので、こういう仕掛けがあるVBはいいのかなと。
ともかくあと3日ですが、ちゃんと動くものを仕上げたいですね。
Author : hidemaro
Date : 2011/08/30(Tue) 22:15
Windows・Microsoft | Comment | trackback (0)
また折りたたみ自転車を買う
自転車がパンクして、チューブを変えれば走るにせよ、ギアとかどうも調子が悪かった。
まぁそんなこともあって新しい自転車を買うことにした。
一応いままでの自転車も置いてあって、予備として後にチューブは変える予定。
というわけでホームセンターへ。
まぁいろいろ自転車置いてあるのだが、安くはないなと思いながら見てた。
3段変速の自転車がメインなのかな。変速はあるとないでは大違いですしね。
変速あったほうがいいよなとおもってたらおもしろい自転車が。
今まで使ってた自転車に似た、折りたたみで6段変速の自転車があった。
前後に荷台がついているのでこれまでの自転車よりも取扱はよさそう。
まぁ色がピンク色で妙に派手なのが気になるが、性能は申し分ないし値段も割安感があった。
というわけでこれを買うてもらった。
自宅までこの自転車で走って行ってたが、やはり走りはいいですね。
これまでの自転車がだいぶギアやられてたのがよくわかる。ずいぶん軽く走る。
タイヤの径が小さくならざる得ない折りたたみ自転車だけど、変速機がついているから漕ぐのは大変でもない。
これは以前と変わらんが。
ところで今の自転車いつ買ったんだったけなとBlogを調べてみた。
2009年10月のようですね。ちょうど2年前ぐらい。
これまで中学校入学以来、通学のため毎日自転車乗ってるけど、まぁ2年～3年ぐらいしか持ちませんね。
もうちょっと持って欲しいよなと思うのだけどね。なかなかね。
修理にかかるお金や自転車の購入費とか駐輪場代とか考えるとあまり自転車を使うというのは安くないのかなと思い始めてきた。
楽なことには違いないし、通学以外にも使うから通学に使わなければ全くいらんというものではないけど。
どうもそんな気がしてならない。
Author : hidemaro
Date : 2011/08/29(Mon) 22:19
買い物・消費 | Comment | trackback (0)
列車の追い抜き大会
最近Simutransで年代設定ありで遊んでいる。
1930年代だとバスでろくに人を運べないから市内交通の中心は路面電車になるわけで、
それで路面電車を走らせていたらこれを郊外に伸ばしたら隣町に人を運べるなど考えてインターアーバンのできあがり。
ただ時代が進むにつれてお客さんも増えてきて大変なので普通鉄道の電車が出てきたあたりから路上走行区間を減らして、
停まってばっかりではうっとうしいので急行を走らせたりした。
それで急行を走らせると各停との間が詰まってくるので追い越しが必要になってくる。
というわけで追い越しのための設備を作ることにした。
まわりの土地に余裕がある急行通過駅の外側に線路を追加してここにホームを設置する。
そしてその駅より手前の信号をいくつか取り除いてある程度信号のない区間を設ける。
そして駅を出たところに信号を置く。これで通過列車が停車列車を追い越ししてくれる。
複線で列車同士の追い越しを設定する方法 (Simutrans日本語化･解説Wiki)
まぁともかくこうすれば急行と各停が接近したら追い越してくれる。
Simutransにはダイヤというものがないから追い越しが起こる条件はわりにいい加減にしか設定できない。
実際の鉄道ではダイヤを定めて走らせているから、ここで追い越さないと詰まるから追い越してとか考えてやるのが普通だと思う。
あとSimutransでは実現できないけど、実際には上位の列車と下位の列車の乗り継ぎを考えて設定されていることも多い。
近鉄大阪線だと昼間は国分、ラッシュアワーは五位堂で急行・区間快速・快速急行と準急・各停の追い越しが行われる。
ここで追い越される準急から追い越す区間快速に乗り換えるとか、逆に区間快速から準急に乗り換えるとかできる。
昨日八尾に行くのに使ったのだけど便利ですね。
よく考えられてるのは分かるのだが、通過待ちでやたらと待たされることもある。
先日こんなことがあった。
急行に乗ってたら特急待ちというから待ってたら特急がやってきた。
なかなか出発しないなとおもったら切り離しをやってたらしい。切り離して電車が出て行った。
これだけでもずいぶん待たされたと思うのだが、なぜか急行より先に切り離した残りの特急車が車庫に走っていった。
おい、とおもったら、しばらくしてその線路を別の特急がびゅーんと通過。
こうして特急2本に追い抜かされて出発。なんと10分待ちである。ここまで待たされたらたまらんな。
まぁいかにも大阪線らしい話で。特急切り離し待ちも特急2本待ちも探せばたくさんあるはず。どっちもってのはめずらしいと思うけど。
特急2本待ちとかいやがらせにしか見えんが、近鉄大阪線の事情を考えれば分からんことはない話である。
近鉄大阪線は毎時4～5本もの特急が走っている。急行は毎時3本、ラッシュアワーでも4本ぐらいだから特急の方が多いぐらい。
急行が終点まで特急に抜かされずに走るなんてなかなか厳しいものがある。だから1回は抜かされると考えよう
すると2回特急に抜かされないといけない急行が出てきそうなのはだいたい予想は付く。
特急が特急を抜かせる駅とかまぁ限られるから、その範囲でいろいろ考えてはいるのだろう。
そんなことを考えていないSimutransでは、
接近してるのに追い抜きをせずに進んで追いつかれたり、一方で3本抜きされたりまぁむちゃくちゃですわ。
それに比べればよっぽどよくできてるのかなとは思いますけどね。
Author : hidemaro
Date : 2011/08/28(Sun) 23:28
交通 | Comment | trackback (0)
府立高専にお出かけ [kosenconf-026osaka]
今日は高専カンファレンス in 大阪に参加するために寝屋川市にある府立高専に行っていた。
府立高専とは言うけど、実はこの4月から正式名称を 大阪府立大学工業高等専門学校 に改めて、
設置者は公立大学法人大阪府立大学になった。都立産技高専とにたようなパターンである。
まぁしかし略称は多分府立高専でよさそうだ。公式Webサイトにも「府立高専が新しく生まれ変わりました」とあるし。
ところで府立高専があるのは寝屋川市だが、電車で行くと京阪電車の寝屋川市駅が近い。
というわけで大阪都心や守口市・門真市・枚方市あたりからはアクセスがよい。
八幡市・伏見区あたりからもよさそうだがいかんせん府立高専、大阪府民以外は入学できないのでここらから学生を持って来れない。
北摂からだと大阪モノレールが通じているので、門真までモノレールで来て京阪でいける。
もしくは大阪都心を介して来てもたいしたことではないか。
まぁこのあたりまでは通学しやすいかなとも思うのだけど、東大阪市・八尾市・柏原市からは近そうに見えて通学しづらい。
というのも中河内と北河内を直接つなぐ鉄道はこの前出来たおおさか東線しかない。まぁ通学には使えんわな。
だからバイクなどで通うのを別とすれば、大阪都心を介して通う必要があり、ターミナル間の移動もめんどくさい。
中河内からだと奈良高専が近いので、ここに通っている学生も多いだろう。
で、なにが言いたかったのかというと、近鉄沿線からのアクセスがよくないと。
まぁ鶴橋-京橋経由が一番無難なルートではあるけど、わざわざ大阪都心に向かうのは残念な気がした。
そこでいろいろ調べていたら寝屋川に向かって走っていくバスがあることがわかった。
それが近鉄バスの萱島線で近鉄八尾駅～若江岩田～荒本駅～住道駅～萱島駅と走る。
住道駅止めが多いんだけど、萱島行きも1時間に1本ぐらいあるしまぁ使える。
萱島駅というとクスノキの木が生えた駅だが、寝屋川市駅の1つ大阪側にあたる。
京阪電車で移動してもいいし、ちょうどコミュニティバスが走っていたのでこれで寝屋川市役所まで行けば府立高専はすぐ近く。
ただバスの本数が少ないのと八尾から1時間ちょっとかかるとか定時性が悪いとか言う事情があるので復路は大阪都心を経て帰ってきた。
バスでショートカットしたつもりだけど、やっぱり都心通った方が早かった。当たり前だ。
さて、今日の最初のブロックはつくってみたコンテスト、つくってみたものについて発表するというもの。
もともとそういう発表は多かろうと思うのだけど、コンテストというからには集計して表彰するという。
これはすばらしいと思う作品もあった。
この発想はなかったなぁって、そんなのもね。
なかなかおもしろい試みかなと思った。
ただ時間が短かったので一体なにを作ってたんだという疑問はあったりしてそこは難しいかなと。
一般発表もLTもみどころは多かったのですがまぁともかく。
なかなか勉強になったなと。アクセス悪いけど行ってよかったとおもった。
インターンシップのすき間に挟まれててどうにも行く気がおきんかったのだが、
まぁ息抜きにはいいかなと思ってね。まぁそれは正解だったかなと思った。
Author : hidemaro
Date : 2011/08/27(Sat) 23:29
記録 | Comment | trackback (0)
バグを探す方法を考える作業
今日は検証の前準備として評価シートの作成をしていた。
お互いの仕様書を交換して機能がちゃんと動作するかチェックするに当たって確認する項目を列挙したわけですね。
まぁちゃんと動作するかというので基本的な動作はそれぞれ制作中に確認している。
それも確認するけど、必ずしもそういうことばかりではない。
変な操作をしても正しく動作するかというのが主な対象となる気がする。
まぁ変な操作といってもいろいろある。
ゼロ除算とかオーバーフローのようにプログラム内部でエラーが発生するような操作もあるし、
想定されている操作手順と違う順序で操作されたりしたときどうなるかということもある。
手順通りに操作しない方が悪いと言うかもしれないけど、必ずしも手順通りに操作がおこなわれると期待していいわけでもない。
手順通りじゃないならそれなりに無視するとか措置をとらなければならない。
というわけでエラーを起こしてみたり、使わないボタンを押してみたりそういうことが多い。
あと正しく操作してもちゃんと動作しているかなかなか確かめにくいのがリセットというもの。
内部状態をリセットしたというけどほんまにそうなのか、なかなかわかりにくい。
それをあの手この手で初期状態に戻ったか確認する方法を考えていた。
式を入力して=を押すと結果が出てくるところで、式を入力してリセットしてから=を押すと結果が出ないかとか、
まぁいろいろ考えてみたわけだが、はてどうだろうか。
ともかく評価シートをいろいろ考えて作って、お互いに評価し合うための環境を確認して、操作の具合を確かめていた。
自分がつくった電卓と操作がかなり違うので戸惑うばかり。
ともかく本格的な検証は月曜日ですが、ポチポチ、あらオーバーフローする式を打ち込んでしまった。
なのにエラーが出ないぞ、と早速バグを発見してしまったとさ。
まぁまた月曜日チェックしますけどね。
Author : hidemaro
Date : 2011/08/26(Fri) 22:48
記録 | Comment | trackback (0)
VBのエラー処理の今昔
今日は朝からひどい目にあった。
雨が降ってるのでかっぱを着て出かけたのですが、走行中に自転車がパンクして全く走らなくなった。
しゃあないのでそのまま走って駅を目指したらなんとか所定の電車に間に合った。余裕を持って出発していてよかった。
果たしてパンクだったのかようわからん話ではあるのですが、帰ってきて修理したけど修理できたか怪しい。
もうそろそろ買い換え時か。
さて今日もVB、また不気味なことに遭遇した。
VB6ではイベントハンドラのサブルーチンの名前って勝手に決まるんですね。
Button1というコントロールを作れば、Button1_Clickがクリック時に呼び出されるサブルーチンだとなるそうで。
そんないい加減なと思うんだけど確かにそうらしい。
VB.NETではさすがにそんなことはなくて、ちゃんとサブルーチンをイベントに関連づけするような記述が必要になる。
デザイナーの操作でイベントのサブルーチンを作るのかと思ったらなくて調べたらそうで驚いた。
さて、昨日エラー処理が不気味だと言ったが、どんな風にやるのか。
Private Sub Calculation() On Error GoTo ErrorHandler Dim Result_ Select Case ExpressionOperator Case Plus Result_ = LeftVal + RightVal Case Minus Result_ = LeftVal - RightVal Case Multiple Result_ = LeftVal * RightVal Case Divide Result_ = LeftVal / RightVal End Select Result = Result_ NumBox = ResultToStr(Result) Exit Sub ErrorHandler: State = ErrorMode Select Case Err.Number Case 11 NumBox = "ゼロ除算" Case 6 NumBox = "計算結果オーバーフロー" Case Else NumBox = "計算時エラー(" + CStr(Err.Number) + ")" End Select End Sub
さて、最初にOn Error GoTo とある。
エラーが起きたらGoToしろと言ってるわけだ。なんとGoToである。
ともかくエラーが起きたら ErrorHandlerに飛べと書いてあるので、ErrorHandler:以下を見てみる。
エラーの種類の判別はErr.Numberで得られるエラー番号で判別する。
Err.Descriptionでエラーの説明が得られるなどするようで。
GoToでラベルに飛ぶという仕組みなので、エラーが起きなかった時はラベルの手前で関数を脱出する必要がある。
ErrorHandler:の前のExit Subはそういう意味です。忘れるとエラー起きてないのにエラー処理することになってしまう。
だからGoToはやめておけと、と思わんこともないのだが、これ以外いい方法もないのでしゃあない。
おそらくこの点がVB.NETになって画期的に改善されたところではないかなと思う。
VB.NETでは Try～Catch～FinaryというC#に似た表記が使われるようになった。
なので、
Private Sub Calculation() Try Dim Result_ Select Case ExpressionOperator Case Plus Result_ = LeftVal + RightVal Case Minus Result_ = LeftVal - RightVal Case Multiple Result_ = LeftVal * RightVal Case Divide Result_ = LeftVal / RightVal End Select Result = Result_ NumBox.Text = ResultToStr(Result) Catch e As System.DivideByZeroException NumBox.Text = "ゼロ除算" Catch e As System.OverflowException NumBox.Text = "計算結果オーバーフロー" Catch e As System.Exception NumBox.Text = "計算時エラー(" + e.Message + ")" End Try End Sub
のような形で書けたんじゃないかなと。これならわかりやすいですね。
いかに例外が画期的なエラー処理かよくわかりますね。
まぁいかにVB.NETで変わったかということやわな。
ともかく今日でプログラムはほぼ完成。
明日はお互いにプログラムの検証を行うことになりそう。
Author : hidemaro
Date : 2011/08/25(Thu) 22:01
Windows・Microsoft | Comment | trackback (0)
不思議なVB6でプログラミング
さて今日はVisual Basicでプログラミングの日。
ずいぶん機能が複雑だったこともあって1日では済まなかった。
まぁ1日で済んでしまっても困るのだが。
Visual Basicというと触れたことがあるかないかで言うとあるという答えになるが、
このVisual BasicというのはVisual Basic .NETのことで、かなりC#の要素を取り入れている。
なのでC#を触れている人からすればわりに易しい。まぁBasic自体そうも難しいもんではないしね。
逆にVB.NETを触れたことがある人ならC#はわりに易しいかもしれない。
ただ今回の開発環境はVisual Basic 6.0、ともかくなかなか信じがたいプログラミング言語だった。
とりあえずボタンに動作を割り付けてみることにした。デザインでボタンをクリックしてイベントハンドラに動作を書き込む。
Private Sub Foo_Click() If NumBox = "0" Then NumBox = CStr(1) ElseIf NumBox = "-0" Then NumBox = CStr(-1) Else NumBox = NumBox + CStr(1) End If End Sub
まぁ動作の意味はともかく、条件分岐である。
Basicでは If (条件式) Then (真のときの処理) Else (偽のときの処理) という書き方をする。
ただ、実際には処理が1行で済むことも少ないので、処理に代えて行数とかラベルとかを書くこともしばしば。
けどVisual Basicではブロックで書くことが普通なのでその点ではCやらとそう差があるわけではない。
If (条件式) Then まで1行で書いて、次の行から真の時の処理のブロックが始まる。
ElseIf (条件式) Then とか Else とか書いたらブロックが終わって、新しいブロックが始まる。
そして忘れてはいけないのが最後のEnd If、これが抜けるとうまくいかない。EndではなくてEnd Ifなので注意。
あと、NumBoxはテキストボックスですが、C#だと NumBox.Text=1.ToString(); とか書くところを、 NumBox=CStr(1) と書いている。
CStrは文字列への変換関数のようなものらしい。NumBoxに直接文字列を代入すれば表示される文字列に入るようで。
NumBox.Caption=CStr(1) と書いてもいいんだけど。まぁVBではよく使われるようだしそう紛らわしくもないしいいかなと。
VBでグローバル変数はプログラムの何よりも最初で宣言すればいいらしい。
Dim ExpressionState As Integer
VBでは変数の宣言はDimで書く。BasicでDimといえば配列の宣言に使われるのが相場だが、配列の宣言にも使う。
Dim OperatorsName() As String
()を付ければ配列になる。()内に数字を書けば静的に確保されるが、これは後でSplitで得られた配列を入れるのでこれでいい。
ここでAs Integerと書いてるけど、これでInteger型でということを示している。
ちなみにVBのIntegerはVB.NETでは System.Int32、まぁC#で言うところのintと一緒だけど、VB6ではCで言うところのshortに相当する。
なので-32768～23767しか扱えない。なのでLongを使うことが推奨されている。とこれを書いてから知った。まぁそんな値は使わんからこのままでいいが。
ちなみにVB.NETでLongはSystem.Int64に相当するのでわけがわからない。Longを使うべしはVB6に対する言葉だ。
これでプログラムを書いていたのだが、なぜかフリーズしてしまうことがあった。
なんでだろとおもって調べていたら変数名を間違えてたようで。
というのもVBでは変数を宣言出来るけどオリジナルのBasic同様にスカラー変数は宣言せずに使うことが出来る。
宣言することが推奨されているけどチェックはしてくれない。チェックして欲しければ最初にこう書いておけばいい。
Option Explicit
ちなみにVB.NETではこれは標準で有効らしい。
ただ実行するまでエラーが出てこないのが難点ではある。VB6ではデバッグ時はインタプリタとして動作しているようで。
サブルーチンを定義しようと思って、こんな風に書いてみた。
Private Sub PutOperator() If ExpressionState >= 3 Then ExpressionState = 2 ElseIf ExpressionState = 1 Then ExpressionState = 2 End If End Sub Private Sub Btn3() PutOperator End Sub
まぁSubで始めてEnd Subで終わると言うのはVBらしい話ではある。
それで呼び出す時ですが、PutOperator()と書いたらおかしいと言われる。
どうもPutOperatorと()を付けなければよかったのだがこのときには理由が分からなかった。
まぁともかくこう書いておけばうまく動いた。
返り値を出したい時はSubではなくてFunctionを使う。
Private Function InputToStr(ByVal Numeric As Double) As String If Abs(Numeric) >= 100 InputToStr = Format(Numeric, "0.0e-0") Else InputToStr = CStr(Numeric) End If End Function
返り値をAsで書くのは相変わらず。引数はByValを付けなければ参照渡しになってしまうので、ByValを付けておく方が無難な気がする。
返り値は関数名に代入するというのはVerilogのFunctionみたいだな。まぁアリと言えばありだが。
返り値があるかないかでSubとFunctionを区別するというのはめんどくさいように見えて合理的かなとも思った。
Cでは返り値がないことをvoid型の返り値があると書いているけどどうにもいいわけがましい気がするし。
と、SubとFunctionで宣言が違うことには一定の理解を示したが……後に信じられないことを発見してしまった。
エラーを示すためにダイアログを出すことにしてこういうコードを書いた。
MsgBox("Error")
まぁこれはうまくいったのだが、ダイアログの種類を変えようとこう書いた。
MsgBox("Error",vbCritical,"電卓-エラー")
と思ったら = がないとか怒られる。なんでやねんと。
調べたら返り値を取る場合と取らない場合で使い方が違うらしい。
返り値を取る場合は()で囲まずに、
MsgBox "Error",vbCritical,"電卓-エラー"
と書くのが正しいらしい。実はさっきPutOperator()ではエラーが出てPutOperatorだとうまくいった理由もこれ。
MsgBox("Error") がうまくいったのは ("Error")を先に解釈したからのよう。
VB.NETでは返り値がなくても()を付けてもかまわんようで。それが当然だと思ってたのだが。
ちなみに括弧を省略する以外に、Callを前に付けて、
Call MsgBox("Error",vbCritical,"電卓-エラー")
と書いてもうまく動く。
ともかく1日VB6を扱っていてなぜこうなるということばかりだった。
まぁ他にも気になるところはあったのだけど、エラー処理とか。まぁあれも不気味でしたね。
資料がVB6で作ってあるのでVB6で実習してもらうと最初に言われたけど、まぁ難儀やわ。
もう1人の実習生は、Cで記述できるマイコンのプログラムに分担させる部分を増やしてVBでの記述を簡素化しようと試みていた。
それはどうよとも思ったけど、確かにCの感覚でVBに触れると痛い目を見るなとも思った。
Author : hidemaro
Date : 2011/08/24(Wed) 22:36
Windows・Microsoft | Comment | trackback (0)
仕様書書き書き
今日はインターンシップ2日目。
その前に昨日の話を少し。
昨日、朝に作業場に連れてこられた時に入口で靴を履き替えるようになっていた。
じゃあ履き替えるスリッパとかあるのかなとおもったらないと言うから靴下で入っていった。
後に説明があったときに、スリッパは持参するように連絡したはずだがというものの、そんな連絡は受けていない。
インターンシップ担当の教員が連絡し忘れたのかも知れない。ずいぶんいい加減なメールだったからその可能性は大いにある。
ともかく、しゃあないので昨日のところは土足のまま仕事をして、今日からはスリッパを持参せよと指示を受けた。
それで家でスリッパを探したのだが、見あたらない。父に聞けば捨てたというから困った。
しゃあないのでビーチサンダルを持参してこれをスリッパと思って履いて、昼休みにスーパーでスリッパを買った。
というわけで今日は荷物がパンパンだった。
今日やったことは電卓の仕様書の作成ですね。
有する機能を整理して書いていくという作業ですね。
今回の電卓は操作をスイッチ基盤で行うと言うこともあってかなり複雑ではある。
というわけで操作の方法を整理するのが結構大変だった。
実装するのもめんどくさそうだなぁと思いながら書いてた。
そもそもの問題がスイッチの数が少ないことで、少ないスイッチでスムーズに入力するためにはということを悩んでいたわけだ。
課題として渡された要求仕様には、画面レイアウトは提案して欲しいとか、表示できる桁数は提案して欲しいなど書いてあった。
というわけで画面レイアウトを仕様書に書いたり、倍精度浮動小数点型の有効桁数を調べたりしてた。
それにしてもWindows標準の電卓ってむちゃくちゃ精度高いですね。
簡単そうに見えてよく作り込まれている。さすがにそこまでやれないや。
ただ、丸め誤差への対応はもしかしたら行わんといかんかもしれんね。そのあたりはまた考えるけど。
ともかく今日のところは仕様書作りとフォームの作成に明け暮れた。
明日からは電卓のプログラムを書いていくけどなかなか複雑なのでゆっくりやっていけばいいかなと。
Visual Basic 6とかいう厄介な言語を使うので、まぁなかなか難儀しそうではありますが。
Author : hidemaro
Date : 2011/08/23(Tue) 21:58
記録 | Comment | trackback (0)
ソフトウェアの設計をする人
今日はインターンシップ1日目、というわけで4:30に起床。
早すぎるだろと思ったかも知れない。確かに早すぎる。
というのもインターンシップ先の事業所の始業が8時なんですよね。
今日は余裕を持って行こうと思い、1本早い電車で30分前には着くようにして、出発前の支度時間も長めに取った。
その結果こうなったわけだけど、明日からは5時起きで十分ですね。
というわけでまだまだ電車は空いていた。最寄り駅を出た時にはラッシュアワーは始まる前だった。
明日は15分ほど遅いので少し事情は違いそうだが。
ともかくインターンシップ先の最寄り駅に到着。
インターンシップ先はそう大きな会社ではない。従業員数100人ぐらいのようだ。
事業所はその最寄り駅を出てすぐのところにある。
5階建ての小さなビルだが、2階から5階まで全てこの会社が使っているよう。
ともかく受付へ、とエレベータの5階のボタンを押しても動かない。
わけがわからないので従業員らしきにインターンシップで来たのだがと告げると、作業場に連れて行かれた。
そして待機しろとのこと。その後もう1人のインターンシップの学生も来て、8時から説明があった。
ところでこの会社はハードウェアの試作とソフトウェアの設計をやっている会社のようで、
今回実習させてもらうのはソフトウェア開発の部門ですね。
というわけで仕事場を見せてもらったのですが、かなり低レベルのソフトウェアを作っているようで。
携帯電話のソフトウェア作ってるんだというから説明を聞けば、充放電とかいうことをやっているから驚いた。
そういうところもソフトウェアなのねと驚いたもの。
他にも体重計のソフトウェアとハードウェアを設計したという話もあった。
県内に工場を置くとあるメーカーから発注されたものだそうで。
PC用のソフトウェアとかもやってはいるんだけどとは言ってたけど、実際にやってるのはそんな感じだそうで。
そして実習課題が発表されたが、Visual Basicで電卓を作るというものだった。
それだけだと1週間のプログラムと差がないから、スイッチとロータリースイッチのついた基盤も渡されて、
これで操作する電卓を作ることとなった。
その電卓を作るに当たっては仕様書を作って、プログラムを書いて、デバッグして、交代して検証してという一連の流れをするようだが、
今日のところは渡された基盤のプログラミングと動作の確認をしていた。
とりあえずハードウェアはAPIが用意されているのでこれを呼び出せば細かい事は考えなくてもプログラミングはできるようだ。
なんか他の研修でも使っているようで、そのためにいろいろ用意されているようね。
ともかく説明を読みながらUARTでボタンの状態を送信したり出来るようにした。
そしてこれをVBで受信する方法を確認して、電卓での利用方法を考えて今日のところは終わった。
元々1週間用のプログラムにつけたしたようなスタイルなので流れがイマイチ掴めないというのが実際のところ。
まぁともかくただ作るだけならそんなに時間がかからないというのも実際のところかなと思う。
ただ、作るだけで終わらないというのが開発の実情のようである。
周辺の機能との兼ね合いなどの検証の方がよっぽど時間がかかると述べていた方もおられた。
まぁそこらへんをどないしてやってるのという知恵を学ぼうというのが1つありそうですね。
ともかく明日も朝は早いのでさっさと寝ましょう。
Author : hidemaro
Date : 2011/08/22(Mon) 21:42
記録 | Comment | trackback (0)