  |
はてなキーワード: VBとは
http://s.news.mynavi.jp/news/2017/03/30/133/
この記事で、おやおやCOBOLが入ってないぞ？と私も思ったし、他の人も思ってたようだ。
なんでだろう。
個人的には、この21世紀にコボラーとかヤバい、という認識で今まで生きてきたのは事実だが、はて、COBOLで嫌な思いをしたことがあるかというと、幸いにもそんな経験はない。
むしろ、
・関わった人たちが、ちゃんとした金融機関(某大手地銀)とかちゃんとした元請け(N社)だったので、ムチャな開発にもならなかったし、お金もちゃんともらえた
・それまではJAVA専門だったが、COBOLの仕組みとかは勉強になった
・一緒に仕事したおじさんがすごい優秀で経験豊富な技術者で、いろいろ教えてもらえた
と、悪い思い出がない。
やっぱ、悪い言語があるわけじゃなく、向いてないのに無理に採用するのが良くないんだよね。
件のアンケート結果は、そういう傾向(向いてないのに採用)が、COBOLからVBにシフトしてきたということかな。
話題のムラマリさんですが、記事によって書かれている理由がコロコロかわっているんですよね。
↓
↓
温暖な地域の方が、子どもの病気が治りやすいと知ったことが主な理由です
複合的な理由だったのかもしれないし、
行動した後から本人の記憶の中で理由の変遷があったのかもしれないですが、
おもしろかったのでまとめました。
他意はないです。
【出典】
Ryuichi Nishida
女性起業家、シンガポールに向かう | TechCrunch Japan
http://jp.techcrunch.com/2012/06/06/jp20120606a-female-entrepreneur-goes-to-singapore/
佐藤留美
https://newspicks.com/news/651502/body
https://dena.com/jp/article/2016/09/09/003194/
http://anond.hatelabo.jp/20161211110105
私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。
UMLなどの作図にツールを使用することはあっても、最終納品物としてはExcelに画像として張り付けて提出していた。
もちろんExcel方眼紙については批判もあるのは理解しているが、開発者、運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。
そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。
設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。
開発者、運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwikiの知識がほとんどない。
彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwikiを用語集として活用していたそうだ。
wikiには顧客業務の専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。
そういった運用をしているうちに彼はwiki自体を設計書とできないか考え、調査したところ実際にwikiを設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。
私も今調べてみたところwikiで設計書を書くという運用をしている会社もあるようだが、メリット・デメリットがwikiの知識があまりない私には判断しかねている。
ぱっと思いつくデメリットとしては、第一に、やはりマークアップを記述するコストが非常に大きいように思える。
記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコストが必要となるように思える。
第二に、保守以降、一つのシステムに複数の改修案件や故障対応が並行するようなことはままあることだが、ソースはSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である。
メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。
第二に、改訂履歴や差分が標準で用意されていることもメリットであろう。
第三に、検索が容易であることがあげられる。この点はExcelと比較して十分大きなメリットだと思っている。
私がぱっと思いつく限りではこんなもんである。
はてな諸兄の中にwikiで設計書を書いたことがある方がいれば、メリット・デメリット、その他運用において気をつけるべきことなどあればご助言願いたい。
なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。
そのため自社の標準の設計書テンプレートを使用する予定だった。もちろんExcelである。
また、設計書作成に使用するツールでExcel、Word以外の素晴らしいツールがあれば教えていただきたい。
どうかよろしくお頼み申し上げ候。
IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。
PHPのプロジェクトはPHPの認定試験に受かってる奴しか使わないとか、MySQLの資格もってないとテーブル設計もやらせないしSQLも書かせないみたいな。
認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。
Javaの入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観だから、自分は実力あるとナチュラルに信じこんでるし。
VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールをJavaに持ち込んで「全メソッドでcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界。
ダメな技術者が、年をとってるってだけで評価されて上にたってダメな技術者を育成するって負のループに入り込んでるから、一定の客観的な基準で評価する仕組みをもちこんで負のループを断ち切るべき。
プログラム書くようになってあるプロジェクトで実践でも投入されるようになってから数年。当時の上司にプログラマって名乗っていいんじゃない？とか言われてプログラマという自認もできた。
もともとはSE的な立場として仕様書を書いたりしてた。ゲーム業界だからSEとはいわずに企画とかプランナーとか呼ばれる職種。書類仕事がメインで、自分でツール作るかスクリプター的な役目でないかぎりコードみたいなものを書いたりはしなかった。コード書くの楽しい。VBなんかに戻れないし、もう書く事もできないだろうな。
だからってわけでもないけれど、できる企画とダメな企画ってのがわかるのよね。プログラマ側からみての意見になるから、ディレクターからみて、とかデザイナーから見て、とかはまたちょっと違うのだと思うのだけど。
自分、ちょっとコードの読み書きできるのでわかってます、な体で仕様書書いてくるのだけど、全然穴だらけ。要件が不明なままフローだけ書いてくる。実際にやりたいことは何なの？そこを説明して実装はプログラマに任せようよ、と。
ゲーム作るのにはバージョン管理システムを導入するのが常。subversionとかgitとかあるでしょ。すごく便利なんだけど基本的にテキスト形式のファイルを管理するためのものなので、エクセルみたいなバイナリ突っ込まれると差分じゃなくて全部のバージョンが入るから容量を圧迫するの。
画像データはまだいいよ。githubがpsdの差分さえ教えてくれるからね。
文字情報メインなのに差分を見る事もできない。検索もできない。
ただ、データ管理としてのエクセルは優秀なのよ。ちょっとしたツールもつくれちゃうし。仕様書をエクセル方眼で書いてくるやつはカスだ。
俺も若い頃はよく使ってたけどMarkdownを知ってからは断然こっちの方が書きやすい。そしてなにより読みやすい。検索もできるし成型もできる。強調表示や画像も貼れる。文法も簡単だし覚えやすい。
Markdownは文字列情報だ。文章だ。文章は一次元的に表現される。つまり書く側が完全に整理した思考でないと書ききれない。読む側に理解させるにはどういった順番で説明をすればいいか考えてからでないと表現できない。おのずと書類の内容、精度が上がる。ただの文章だからこそだ。
エクセルはタブやらなんやらで並列なまま多次元情報としたまま表現できる。思考が整理されてなくても表現できてしまうし、表現した気になる。書いてる側の思考がまとまってないまま表現できてしまうあたりはエクセルの自由度の高さでもあるのだけど、通して読む事ができない形式でもあるので、読む側のことを考えていないクソみたいな仕様書も提出されてきてしまうのが難点。
企画「XXファイルのYYタブに書いてありますよ。ちゃんと読んでるんですか？」
殺意が沸くわ。
Photoshopなり何なりで書いた絵図をGyazoにでもあげてリンクだけMDに貼れよ。エクセルでシェイプ駆使して作るより早いだろ。
パワポの方がマシですわ。あれはページにスペースの制限があるから１ページ内にまとめよう、伝えようっていう意思と能力がないとまとめられないから。
要件を伝えるのもいいけどバランス調整するための調整項目だしなよ。調整できるようにするし、こっちも使う変数を見出すきっかけになるから助かるんだよね。
3Dアーティストのあげてくるデータも仕様書書くでしょ？あれの要件とかもまとめられないでしょ。ノードとか意味わかる？揺れもの数とか制限あるのわかる？
なんでもいいからゲームエンジン触れよ。Unityとか簡単じゃん。プログラム書かなくてもいいじゃん。
俺があれだけMarkdown簡単だから覚えろって言ってもエクセルで上げてくるし、古い知識のままアップデートされない人って存在が迷惑ですわ。
プランナーで説明が下手って終わってるよね。俺も下手だわ。よく怒られてた。ごめんなさい。これは別にプランナーに限った話ではないけれど、プランナーて人に伝えてなんぼなので職能としてこれがないのは致命的だよなぁ。
書いてすっきりしたので寝る。星くれ星くれ
VB+Oracleのクラサバのプロジェクトのところに派遣された。
↓これみたいに、SQLを実行する前後を BeginTransaction〜commit/rollback で挟んでいるのだけど、
transaction = connection.BeginTransaction(・・・)
command.CommandText = "INSERT INTO ・・・"
command.ExecuteNonQuery()
transaction.Commit()
↓のように、commandとtransactionを関連付けないと、トランザクション関係なく実行されちゃうよな。
transaction = connection.BeginTransaction(・・・)
command.Transaction = transaction
command.CommandText = "INSERT INTO ・・・"
command.ExecuteNonQuery()
transaction.Commit()
プロジェクトでトランザクションを使っているところを全部確認したけど、一箇所もcommandとtransactionを関連付けてるところがなかったわ。
まあ何年もまえからやってるプロジェクトで問題になってないんだから、俺が指摘して問題にすることもないかな。
あと、Oracleに接続するユーザーとパスワードが.iniに保存されていて、それもいいのかよって感じだったわ。
アプリ自体にはログイン機能とか権限によってデータのアクセス制限があるのに、アプリ経由しないで直接Oracleに接続したら全部の情報見放題になるわ。
開発現場は、派遣のPCはネットに接続させないとか生データは見せないとか情報漏洩に神経を使ってるに、実際に運用されるであろう現場ではゆるゆるっていう。
元々は化学科の大学を卒業して、ゴム部品製造をしている会社で図面を書いていた。
ある時、設計から管理に移動して、CADのアドインを自前で作るようになり、プログラミングっておもしろいじゃん！と思い
転職を考えるようになったが、そんなアクティブに転職をすすめるようなことはしなかった。
結婚し、子供が生まれ、家を買い、まぁこのまま製造業していくんだろうなと思っていた矢先、会社の経営が傾き希望退職者の募集が始まった。
会社からは残ってほしいと言われたが、千載一遇のチャンスだと思い、割増退職金と無償の就職支援会社斡旋をもって会社を辞めた。
これが２０１３年の５月（３２歳）。
就職支援を得ていくつかのIT企業を紹介され、業界未経験であるにも関わらず前職とほぼ同じ給料で雇ってくれた会社が今の会社で
入社したのが２０１３年の７月。
この会社は、大手SIerの２次請を主な生業としており、細々と自社パッケージを取り扱う感じの従業員１００名前後の会社。
まず驚いたのは、求人票に「残業手当あり」と書いてあったので当然残業代全額支給だと思っていたが
内定書には「裁量労働制適用」とありみなし残業代が毎月１０時間分つくだけだということ。
「これがIT業界というやつなのですね！」と、前職の製造業では考えられない条件を簡単に受け入れられたのは今でも不思議。
入社してからおおよそ１年半、携わったのは１人から３人程度の小プロジェクトのみで、官公庁向けシステムの改造がほとんど。
しかも、言語はすべてVB系（6.0、.NEt、VBA）、データベースはアクセスとスーパーマイナーなみたこともないもののみ。
それでも、知らないことを初めてやるのは新鮮で楽しかったし、勉強にもなったが、最近なんか違う、このままじゃだめかも、って不安になってきた。
このまま、VBで小さいシステムの改造だけやってて、将来大丈夫？
最近SIerの未来は暗いっていう記事たくさんみるけど、今の会社はクラウドとかの今風の技術はまったくやらないし、大丈夫かなって感じてきた。
つい最近、掲示板に「SVNってすごくいいツールがあるから、みんなVSSから乗り換えてみない？」って書いてあって、とても不安になった。
二番に、ちゃんとソースレビューとかしてもらって、もっと色々学びたいって思ってること。
「自分で勉強しろ！！」って思うかもしれないが、社内にソースの内容について語れる人がほとんどいないし、既存ソースはとても古臭く
オブジェクト指向すらあやしいものばっかりで、とりあえず動けばいいやって感じが読んでて伝わってくるし、プロジェクトでも実際にそう言われてる。
残業代でないって普通だと思ってたけど、出るとこも普通にあるんですね。
昨年末、別プロジェクトで納期３カ月おくれてるとこにヘルプで行った人達は、平日は毎日泊まり込みで休日出勤も当然して
総労働時間は私の倍はいってるはずなのに、たぶん給料は私と同じくらいしかもらえない。
自分のことじゃないけど、これはやってられないなと思った。
てなことで会社を変えたいなって思ってるんですが、私の経歴で他に雇ってくれる会社ありますかね？
もうシステム開発とかVBとかじゃなくて、パイソンとかルビーとかでWebとかやりたいなぁ。
無理かなぁ。
今でもイントラネットって言葉を使うか知らんけど、企業内の閉じたネットワークの中で使う業務アプリね。
ブラウザはIE7以上でOSはXP以上対応で、ブラウザ×OSの全組み合わせでテストするとか狂った状況になってるわ。
画面もVBの感覚で作っていて、CSSでピクセル単位でパーツの位置とかサイズを指定して、罫線が一ドットでも隙間が空いてたらNGとかやってるし。
Webアプリの利点とか言われてる「ブラウザさえあれば動くからクライアントの管理のコストが低減できる」とかも、その業務アプリを動かす端末は何ページもあるマニュアルに従って環境設定しないと動作は保証しないってことになってるから結局パソコンの分かる人間が設定をやらないといけなくて、setup.exeをコピーしてきてクリックするより楽になってるとは思えないわ。
スマホの世界だと、ネットのアクセスはそれぞれ専用アプリで行うことが多くなってインターネットの世界が分断されるって危惧してる人もいるけど、業務アプリなんて分断っていうか最初から閉じてるからもうクラサバで、アプリでサーバーにサクセスすりゃいいじゃんって思うわ。
わたしの勘違いだったら申し訳ないけど、C#で次のようにコードを書いたら、ぬるぽ例外が発生しましたよ。
public class DoSample : System.Management.Automation.PSCmdlet
{
...
public DoSample() {
...
if ((this.MyInvocation == null) || (string.IsNullOrEmpty(this.MyInvocation.ScriptName))) {
return;
}
...
}
}