「UML」を含む日記 RSS

はてなキーワード: UMLとは

2019-04-17

若者応援おじさんの思い出

https://twitter.com/MAEZIMAS/status/1113114798672113665

若者説教する老害は二流。

一流の老害は「君たちこそが真のニュータイプだ」とか言って、若者自分既得権益確保のための鉄砲玉にする。

…いやマジ本当に、若い人気をつけてね。若者説教おじさんは、せいぜいまだ極限の不愉快ですむけど、若者応援おじさんに乗せられると最悪人生詰むので…

というツイート流行っているので、私が遭遇した若者応援おじさんについて書こうと思う。

当時の私は親との折り合いがつかず、学力もそこそこあったし、勉強もしていたのにも関わらず大学に進学せずにフリーターをしていた。実家を出たかったし、大学にも進学したかたから金の工面が当面の目標だった。そんなとき出会ったのが若者応援おじさんのAさんである。Aさんはバブルの頃に就活をしていて、まだインターネットやパーソナル・コンピュータというのが流行る前から電子工作プログラミングをやっていた人だった。実際、経歴を聞いてみると10回以上転職を繰り返しているものの、有名企業(今にして思えば、カビ臭いSIerだが)で部長をしていたことがあって、年収が1700万ぐらい稼いでいたこともある人だった。

最初出会ったとき自分が如何にすごいかということを熱心に語っていた。80年台後半ぐらいのコンピュータ開発の大型プロジェクトに関わっていたとか、セキュリティ専門家とか、今までに触ったことのあるプログラミング言語が300個を超えるとか。でも、当時の技術的なトレンド(MongoDBRuby on Rails、AngularJSとか)についての知識が限りなく少なく、「フレームワークなんてその場で覚えればいい」みたいなタイプだった。中学生の頃にラジオ工作したとか、はんだごてで電子回路設計したとか、そういう話は熱心にするのに、Bram Moolenaarの名前を知らなかったりした。要は、最近プログラマがどういう関心やインセンティブプログラミングやってるかを知らずに、過去の栄光を語ってるようなタイプだったと思う。

まぁ、それでも、その人のコネで中規模程度のSIer入社して、そこそこいい感じの待遇だったように思う。当時の私の技術力は『わかりやすJava入門』『たのしRuby』を一通り終わらせて簡単言語仕様を把握したぐらいでろくにコードも書いたことのないような人間だったから、定時で帰れて手取り二十万もらえるのは甘い汁を吸えたとは思うんだ。

でも入社を決めた一番の理由が、そのAさんが私の関心に理解があると思っていたからだ。というのも、当時の私は「人工知能人工生命に興味があります。三年後に大学入学するまでにプログラミングスキルを磨きつつ生活費学費を稼ぎたい」ということを明言した上で、それを叶えてくれる会社を探していた。技術力はないものの、「自頭がいいか入社してからプログラミングを覚えればすぐに戦力になるよ」と複数人間から言われていて、それぞれ就職先を紹介してもらえるような状況になっていた。今から思えば、そんなコードを書けない人間を自頭なんて胡散臭いもので褒めるような人間は信用してはいけないと思うし、口車に乗せられたと思うのだけど。そこは自分にも甘いところがあったように思う。あ、あと、補足しておくと、当時はDeep Learningなんていうのは全く人口膾炙してなかった時期で、スチュアート・カウフマン金子邦彦に憧れてたような、周回遅れの複雑系に魅せられた若者が私だった。

駄文を書き連ねてしまったが、要は

①親との折り合いが悪く、大学に進学したいが、金が足りない

実家を出るために生活費を稼ぐ必要があったが、飲食バイトとかではスキルが身につかない状態で、価値の高い若い時間無駄にしてしま

③そんなところに現れたのが過去の栄光を話す若者応援おじさんのA

自分殆どコードを書いたことのない業務経験で、21世紀になっても複雑系の話に興味をそそられるような斜に構えたスノッブ

という状況設定理解してくれればいい。

では、入社後の話をしよう。私が配属されたプロジェクトは80万行程度のJavaコードで動いてるBtoB向けの製品保守開発してるプロジェクトだった。やってることはGoogleAmazonMicrosoftみたいな大手ならやってるようなサービスの完全下位互換みたいなソフトウェアを、情弱だけど社員数は多いみたいな企業に売りつけるような仕事だ。国産とか、セキュリティとか、そういうよくわからない言葉を並べ立てて、海外UIも洗練されていて、優秀なエンジニア管理してるものセキュリティ的に怪しいと不安煽り立てて売りつけるようなやつだ。そんなクソみたいな製品でも年間5億円ぐらいの売上になるのだからIT系って糞だなって思う。ネット上では優秀な人間ばかりがアウトプットしてるし、NDAの名の下に詐欺まがいのソフトウェア(今回の例なら無料UIも洗練されていて、使いやすサービス)が明るみにならないのだから、こんな国はさっさとスクラップ・アンド・ビルドすればいいのにって思うよ。IT化されてないのが時代錯誤で〜みたいな記事ネット上でもバズるけど、実際には10年前のスパゲッティコードを惰性と不安につけ込んで売りつけるようなSIerがたくさんある。そんで、そんな意味不明ソフトウェアを導入すれば、どこに何があるのか分からないUI操作に大切な業務時間を奪われて、日本全体の生産性が落ちてしまう。ユーザー時間生産性を奪い、開発者にとっても技術負債しかならないようなソフトウェアを売りつけてる悪性腫瘍みたいなSIerはさっさと滅んでしまえばいいと思うよ。

まぁ、私が配属されたプロジェクトはそんな感じだ。まるで意義を感じないが金にはなってるプロジェクトに配属された。そのプロジェクトの根幹部分は一人のエンジニア設計開発しており、そのエンジニアは既に退職して、どこに何が書いてあるのかわかってない人間が後任として保守を行っている。盲腸みたいに全く有難みのない機能を増やすことでより高く売りつけるようなプロジェクトだった。

そのプロジェクトの中にいる人について話そう。プロジェクトマネージャー仕事漬けで毎月350時間ぐらい働いている60連勤とか当たり前で、常に酔っ払ったような、眠そうな目をしてる人だった。にも関わらず、同じプロジェクト人間仕事がなさすぎて業務時間中に関係ない談笑をしたりしていた。プログラマテスター文書作成をするスタッフが40人ぐらいいるところで、閑散期(機能追加のサーバーリリース前以外)は暇そうにしてる人が多かった。プロジェクトマネージャーを除いて。要は、PM一生懸命働いているが、その一生懸命さは惰性で行われており、無能なのに業務時間が長いPMがいて、その人が全部仕事をやってしまう。他人に頼めない性格らしくて、存在意義が分からない業務他人に頼んでは「なぜこんなこともできないんだ?」って怒鳴るのが生きがいみたいな人だった。頑張ってることがアイデンティティになってて、その頑張りに意味があるのか、必要なのかという吟味ができず、タスク他人に振ることもできず、情報もそのPM一人だけが握っているから、周りの人も「私が仕事を請け負いましょうか」ということもできない。それで新入社員をイビるような存在意義のわからない仕事を振って、できなかったら人格否定をするような感じの。

私が受けた仕事ととしては、週に1回ベンダーのところに会議をしに行くんだけど、そのときの社内の資料を全部紙でプリントアウトして持っていくというのがあった。文書作成スタッフ製品仕様Wordでまとめて、600ページぐらいのpdfにしたものが1500万円ぐらいで売れるらしく、その増えた言語仕様プリントアウトしてベンダーのところまで持っていく。追加された仕様以外にも、今週やったテスト内容をExcelで纏めたものプリントアウトしたりしていた。紙の量で言うと、一回の会議で2500枚ぐらいで、それをキャリーケースに詰めて客先であるベンダーまで持っていくらしい。聞いた話では、その2500枚の会議資料殆どまれずに捨てられるのに、そのPMベンダーにその慣習を廃止しようとは提案しない。ベンダーとの週一の会議の他にも、進捗報告を主とする社内会議があって、PM以外の人はあのプリントアウトする悪習は廃止すべきという話が上がっているのにPMが首を縦に振らないから一向に改善されない。まぁ、そのプリントアウトするのをやるのが私の仕事だったわけですよ。毎週4時間ぐらい掛けてWordExcel文書サイズとか調整してさ。元の文書サイズや余白が狂ってるのに、客先に失礼だと言われて、手直しして、プリントアウされたコロコロコミック何冊分だよ? みたいな紙の束をホチキスで止めていくんだけど、ホチキスの止め方が汚いとやり直し。

じゃあ、なぜPMは頑なに意味のない業務をし続けて、それによって新入社員を使い潰そうとするのかと言えば、弊社の業績が悪くて倒産しそうだったときにそのベンダーが手を貸してくれたからそのときの恩義があるとかなんとか言っていた。だから、靴を舐めるようなことをするし、他人生産性を奪うようなクソ製品を世の中に出して何も感じないらしい。読みもしない産業廃棄物を作り出して、それを無碍にされて喜んでいるような業務が、今の日本の何割を占めているのだろう? そのPMの口癖は「俺はプログラミングは全くわからないが、こんなプリントアウト段取りもできないようなやつはプログラミングなんてできないと思うよ」だった。FizzBuzzどころか変数関数すら知らないような人間にこんなことを言われるのは屈辱だったし、これが高卒経験就職することなのだろうと思った。

他にも、私が受け持った仕事に、製品が動くかどうかを確認するテスターという仕事があった。RSpecSelenium自動化しようと言っても、そんな技術を持ってる人がいなかったから、一々自分でその製品を触って仕様通りになっているか確認しないといけなかった。画面遷移が600ページのpdfになっているから、それを見ながら正しい画面遷移ができているか確認する業務だったが、正直人間のやる仕事ではないと思う。画面遷移だから前のページから次のページに移行したときに前にどのページだったなんてスクショを撮ったぐらいじゃわからないのに、「このテストExcelにした内容じゃ、本当にテストしたのかわからないだろう?」と言われた。言われたとおりにExcelファイルスクショをひたすら貼り付けていたというのに。しかも、その他にも特定ファイルアップロードするときにどの条件だとアップロードができないか判別するテストをどうやって行うのか考えろというのがあった。今までにテスターをやっていた人に聞いても指針なんてないと言われ、「賢い人はそういうのを考えつくものだ。俺はパソコンに詳しくないが」とPMに言われ、嫌気が差した。

まぁ、ここまで書けば、如何にブラックと言うか、理不尽で不合理な職場かというのはわかったと思うけど、いい面もあったんだ。前にも書いたように、未経験高卒手取り20万貰えたのは嬉しかったし、研修のない会社だったから、最初の二ヶ月ぐらいは一人で勝手勉強しててと言われたから、実働換算で時給3000~4000円ぐらい貰える計算だったのかな。一番瞬間時給が高かった日はメールの返答に20分ぐらい使ったときだったから、日給1万、実働換算の時給が30000円ぐらいになった。それぐらい放任されていた。

最初社長が「君にはソースコードUMLを書いてもらおう」とか言って、クラス図を書く練習をしていたんだけど、現場の人は「今更UMLなんて必要ない」「ソースコードを読めばわかる」と言って、全く必要とされていなかった。だから業務とは関係ないTCP/IPRubyGit勉強をしていた。家のことで勉強に対してモチベーションが落ちていた私は、金を貰えるという環境では目の前の勉強に集中できるようになって、元の勉強するための生活リズムっていうのか、そういうのを取り戻せた。それは当時の私にとっては有難かったと思う。

ここまでをまとめると

無料で使えるサービス下位互換といえるような、他人生産性と金無駄にするような製品を開発してるプロジェクトに配属された

PMけが忙しく働いて、周りの人の割り振りができていない。

PM多忙なのはしなくていい仕事を引き受けているだけ。

社会悪のようなソフトウェアを売りつけて金を稼いでいるプロジェクトだった。

仕様書やテスト内容のプリントアウトという必要ない業務をしたり、指示内容と叱責内容が矛盾する理不尽を受けなければならなかった。

しかし、勉強してるだけで月20万貰える環境は有難く、当時の私にとっては願ったり叶ったりだった。

では、次に私がその会社入社から辞めるまでの経緯について書こう。最初のうちは、自分勉強時間を取れていたし、振られる仕事理不尽で意義を感じられないものであるものの、すぐに終わることが多かったか問題ないと感じた。それが徐々に仕事が増えていき、勉強時間が取れなくなっていった。

ここで若者応援おじさんAの登場である。Aさんは私と会ったときは有名企業に勤めていて、そこを辞めて私を紹介してくれた中小企業で働き始め、その数カ月後に私を紹介してくれた。元々、その会社社長とは懇意にしていたから、一緒に働こうという話が何十年も前からあって、今回ちょうどタイミングが合ったから、その友人の会社の重役として就職したらしい。私が就職したのはその数カ月後だった。

Aさんは「何か問題があったら、部下や上司という立場を気にせずに忌憚なく言ってほしい」「俺は人を見る目はある方だ。君は一本芯の通ったところがあるから、周りに流されずに新しいことをできるだろう」「君には将来性がある」「俺は新しい会社でも権力を持ってるからへんなことを言ったり、したりしてる人がいたら遠慮なく言ってほしい」とかそういうのを入社する前に言っていて、まぁ、色々とおかしいところ、FAKE野郎みたいな発言が多かったけど、そこだけは信じてたんだよね。本当に騙すんだったら、そんなすぐに辞められるようなリスクを上げるような発言はしないだろうってさ。ちなみにFAKE野郎って感じたのは、一方的自分の話だけをして、私が質問すると煙に巻いたり、私のことを買ってるという割には私の話をすぐに中断させて自分の話をし続けるとか。その人はFラン出身だったから、ちょっとインテリなことを言うと「君は変わってるね」って言ったり、きょとんとした顔で10秒ぐらい固まった後、すぐに自分の自慢話を再開したりと、決して自分の知らないことや分からないことを認めようとしなかった点だ。他にも、「私と働きたいと言ってくれていた会社はあったけど、そこは技術的に成長できそうだけど給料は月7万程度でバイト身分から、迷ってるんですよね。バイトから自由時間は多く取れるんですけど」みたいな発言をしたら、鳩が豆鉄砲を食ったような顔をして、私が感じていた不安を取り合ってはくれなかった。Aさんは「俺は社内で影響力を持っているから、君を正社員にすることもできる」みたいな話を延々としてたのに、いざ蓋を開けてみると、「君の面接での受け答えが駄目だから契約社員として雇用することになった」「あれから上層部に渋られてしまって、請負契約にすることになった」と話が二転三転していった。だったら、他にも選択肢があったのに、他のところに就職したのにと思ったが、自分能力や経歴で負い目を感じていたから強く言うことはできなかった。高卒就活するというのはそういうことだ。他にも選択肢があるのにも関わらず、どうせ労働に関する知識がないと足元を見られて、条件を徐々に下げられ、他に選択肢をなくした後で、悪い条件で働かざるを得ない状況になっていた。結局、勤務時間タイムカード管理されてるのにフリーランスとして請負契約を結ぶという偽装請負契約させられ、もっと技術力を磨ける選択肢は潰されてしまっていた。

私は会社問題点を丁寧に分析してpdfにまとめてAさんに送ったんだ。それが間違いだった。如何に会社がそのベンダーに良くしてもらったか、大変なのをわかった上で俺たちが会社を立て直してきたかということばかりを話していた。百歩譲ってそこはいいとしても、ベンダーとは関係なく職場環境を良くするための話までいい加減に聞かされてうんざりしていた。

「Aという問題があります。その背景にはBがあります。そのためにはCという解決策があります

という話をしたときに、「Bぐらいみんな当たり前にしている。君だけ特別扱いすることはできない」みたいな返し方をされて、問題が発生してる事自体はないものとされていった。結局、職場にはびこる不合理で理不尽業務ルール改善することはなく、私への人格攻撃で終わってしまった。

毎日どうでもいい作業で疲れ切って勉強時間が取れなくなってしまった私は、最初出会った頃のAさんの言葉を信じて、「私が本当にしたいことは、仕様書やテスト時のスクショプリントアウトしたり、よくわからないテスターをやったりすることではない。このままでは、プログラマとしてのキャリアを積むための勉強時間を作ることもできないし、業務内でコードを書くこともないか業務時間を短くしてほしい」と言った。少なくとも、最初Aさんと会ったときは、「君には人工知能このエントリーをはてなブックマークに追加ツイートシェア

2019-04-05

リセールスやコンサルやってるけど頼むからエンジニア気取りは来ないでくれというか消えてくれという話

最近は、35歳定年説は嘘だ!って声に反して、危機感覚えたweb系だとか問わずに、シコシコSEPGやってる奴らがコンサルとかプリセールスの方によく流れてくるけど、ハッキリ言ってマジで迷惑から来ないでくれないかな。

つーかマジでハッキリ言うわ、迷惑から業界から消えてくれ、もしくは一生下流でシコシコやっててくれ、仕事なくなるまでフリーランス(笑)とやらでやってて、年食って40くらいになって仕事なくなったら、生活保護でも受けて隠遁でもしててくれ。

俺も技術者上がりだから気持ちはわかるけれどもね、まず君らエンジニアって、思考回路からして致命的に世間ズレ起こしてんのよ。

君らITエンジニアは、「コミュニケーション能力」というのを、邪教の如く嫌って、単語唱えられただけでお経や聖書の一説食らった悪魔妖怪の様にもがき苦しんで発狂するけどね、

例えば、よく開発の現場とかでは、論理思考と称した手垢のついたUMLチャートみたいな、いちいち明確な意味筋道立てて言わないと気が済まないしそういう風に相手は聞けないと悪いっていうあの感じあるでしょ。

お前あんなの、ユー子とかIT業界外でやったら、というか、一般人相手にやったら、ハッキリ言ってヤクザ警察の取り調べとかみたいな、言葉尻掴んで脅迫してるか、喧嘩を売ってるようにしか聞こえないからな、ヒョロガリキョロ充のもの恰好してるようなのが行ったら、何してくるかわからない感満載のサイコ不審者みたいにしか見えないからな、言っとくけど、気に入らないこと一言でも言ったら出刃包丁で〇されそう見たいな怖さを相手に与えてるように見えちゃうわけ。

大体これを客先でかまし出禁食らうとかいう、会社教育を疑うようなこと、必ずやらかすわけよ、大学からしてパソコン以外の知識だけ磨いてきました、みたいな技術上がりって

もっとひでえのは、何をトチ狂ったのか「可哀そうなIT音痴のキミ達に、この道のプロである私がナーチャリングしてあげる」みたいな態度やるやつ、Web系上がりに特に多いけど、

こんなもん、客先どころか、普段私生活からこういう態度取ってて、よくぶん殴られたり暴力振るわれなかったなって思うよ、まぁ、パソコン以外友達がいない、昔ならそもそも職につけてるかどうかも怪しい様な〇達〇害みたいなのでも食えちゃうITって業種がすべては罪なんだろうけどね

あとな、場の空気読めよ。客だって内心無理ってわかっててそっからどう落としどころ探っていくかのようなのがコンサル技術営業の商談というか、世の中のマトモだろうが怪しい仕事だろうが、ビジネスの流れの基本なんだが、その場でハッキリと無理だのできないだの技術がわかってないだの、挙句の果てに「技術力を図るためにわざとやってるんでしょ?」とか見たいな、誰もが思ってても口に出しては決していけないようなこと、平気でズバズバ暴言放言連発するからな。

あのね、開発の現場とかオペの現場とかならそういうの普通だったんだろうけどね、他業種のお客様の前どころか、商談の席でそれやったら最悪訴訟モンになんだぞ?わかる?

私生活でそんな態度取っててよく今まで五体満足で生きてこられたよな、都会のゲーセンとかでやったらマジで不良に頭カチ割られるんじゃないのって思うわ、ホント

つーか、ここ4~5年こんな奴らしかこの業種に来なくなったんだけど、俺がいたころも相当ひどかったけど、今こんなレベルしか上がってこないってどんだけ人材不足なんだよIT業界

ウザさとか迷惑さのレベルが、合コンで張り切ってイニシアチブ握ろうと喚く、プレデターエイリアンみたいな顔したブスとか、痛々しいくらいウケてないのに動物園の檻の中で奇行をしてエサ貰ってるチンパンジーみたいなウェイウェイ真似してるキョロ充と相席になった時くらいの迷惑度な訳、商売あがったりなんだよ、そういうのが来られると。

結論コミュニケーション能力がない奴が、技術一本で最上流の工程がメインの仕事をやりたいだなんて、寝言は土日祝日休み休みいってください、というか来ないでください、ぶっちゃけ消えてください。

じゃあどこ行けっていうんだって生活保護でも貰って大好きなパソコンと向かい合ってたまに勉強会にでも出てたら?別に仕事としてお金もらうだけがITエンジニアってわけじゃねえんじゃねえの?

その代わり、仕事でやっててごはん食べてるプロ大人たちの間に入りたいなんて、バカなことほざくなよな、どこの業者から金もらってやってるのか知らんが、ITブログだってキャリアアップと称して、煽り立てんじゃねえぞ、プリセールとかコンサルってのは、作〇所でも精神病院でも幼稚園でもないからな。

2019-04-03

anond:20190403152304

文章を書くとき主観的になりきる(感情移入する)必要があるが、プログラム客観的メタな考え方でつくる必要がある

コンピュータシステム立場になって考えている。UMLユースケース図は証左。たぶん、増田コンピュータ感情移入できないから、そのように思うのだろう。クルマを愛車と呼ぶのか、単なる移動手段の一機械しか思えないか。どちらが良い悪いは無いけど。

プログラム意味や内容がわかっていないことについて書けない

⇨かつてはやり直しコストが高かったのでウォーターフォールモデルが主流だったが、現在WYSIWYGのごとく、コードを書いて、動かしてみて、検討しなおしてコードを書く、といった繰り返しで調整して作っていくこともそんなに変ではない。

作りたい成果物が決まっているのは、文章も何らかの意図を持って書くのだから一緒。

私の結論プログラム言語は、英語にも増した世界共通言語(よく変わるけど…何処かの進学塾のセンセが書いていたけど、数式のほうがさら普遍性が高い)

2019-02-19

"美しいコード"はよく見るけど、"美しい設計"について書いたものって目にしたことがない。

クリーンコードリーダブルコードなど、"美しいコード"を書くための本は知ってるけど、

例えば要件定義UML図があってその解説をするような、"美しい設計"について書いた本/記事ってよく考えると知らない。

GoFとかのデザインパターン設計だけど、「どう活用するか?」がメインで、

MVCDDD設計ではあるけどあくま手法

ある定義の中に埋め込まれた一部としてその姿を解説付きで見たことがない。

整理されたコードを書くことは設計かつ実装だけど、それが全てだったら上流/下流って世間工程が分かれてる意味って?

「こんな一見勘違いしそうなややこしい要件を、こんな風に設計しました!」っていう例をたくさん見てみたい。

優しく博識な増田さんや、どうぞ教えてくださいな。

2019-01-27

anond:20190127224821

SV

I laughed.

me.laugh()

疑問の余地がなく正しいと思う。

SVO

I have a pen.

me.has(new Pen())

「所有している」はメソッドでは表現できないと思う。

meオブジェクトメンバーpenがいる、とUMLかなんかで表現するしかなさそう。

SVC

It's a pen.

it.isA(Pen)

It is a Pen継承関係表現する?

He looks happy.

him.looks(Feeling.HAPPY)

him.looks()をコールしたらFeeling.HAPPYが返ってくる方が正確?

でも人によって感じ方違うしな・・・

SVOO

I gave my brother a chocolate

me.gives(me.brother, new Chocolate())

難しい。合ってると思う。

SVOC

I made my brother my wife

me.makes(me.brother, new Wife(me))

難しい。

that

which (非制限用法)

読めない(´・ω・`)

2018-11-19

増田プログラマー養成講座 その22 データベース設計 概念物理

前回は、DB設計の(1)要件定義を学びました。

今回は、DB設計の(2)概念設計、(3)論理設計、(4)物理設計を見てみましょう。

 

DB設計の流れ

  1. 要件定義
  2. 概念設計
  3. 論理設計
  4. 物理設計

 

DB設計の教材

データベース解説本やWeb記事を調べてみた。

  1. 本「スッキリわかるSQL入門」 第12章 テーブル設計 https://book.impress.co.jp/books/1111101167
  2. Web記事「できるエンジニアになるためのちょい上DB術」 https://www.edifist.co.jp/lecture/dbdesign/

 

スッキリわかるSQL入門」のDB設計説明コンパクトにまとまっていて、分かりやすいと思いました。(是非一度読んでみてください。)

 

 

 

概念設計論理設計物理設計概要

スッキリわかるSQL入門」第12章の説明(p.374)を参考にしてみよう。(詳しくは本を読んでみてください。)

 

概念設計

管理すべき情報はどのようなものなのかを整理します。

データベースシステムに関することは考えず、要件に登場する情報だけをザックリと把握します。

たとえば、家計簿データベースであれば、扱うべき情報として「利用者情報」や「入出金情報」などがあることを明確にします。

また、情報間で関連がある場合、どのような関係があるかも併せて整理します。

 

論理設計

概念設計で明らかになった各情報について、RDBを使う前提で構造を整理し詳しく具体化していきます

論理設計では「どのようなテーブルを作り、それぞれのテーブルにどのような列を作るか」まで明らかにすれば十分です。

型や制約など、付随的な部分については考えません。

 

物理設計

特定DBMS製品(たとえばMySQL)を使う前提に立ち、論理設計で明らかになった各テーブルについて、その内容を詳しく具体化していきます

すべてのテーブルのすべての列について、型、インデックス、制約、デフォルト値など、テーブル作成必要なすべての要素を確定させます

この物理設計に基づいて、CREATE TABLE文などを含む一連のDDL文を作成し、最終的にデータベース内にテーブル作成することができます

 

本書の「図12-4 データベース構築のおおまかな流れ」も参考にして欲しい。

入力 お客様要件(全国の倉庫商品があって、その在庫管理したいんだけど~)

 

 

●処理 DB設計作業

 ・概念設計:(商品)(在庫)(倉庫) …ER図を作成

 ・論理設計:[商品][在庫][倉庫]    …正規化

 ・物理設計:[SHOHIN][ZAIKO][SOUKO]  …使うDB仕様に合わせてテーブル定義表を作成

 

 

●出力 DDL

 ・CREATE TABLE

 ・CREATE VIEW

 ・CREATE INDEX

 

 

 

(2) 概念設計

 

ER図とは?

ER図とは、「Entity-relationship Diagram」(実体関連図)の省略形だ。

 

ER図の用語

コンピューター用語英語ばっかりだから日本語にして欲しいよねw

 

ER図の書き方
  1. エンティティ―」は四角い箱で書く。
  2. 箱の中にエンティティ―の詳細な中身=「アトリビュート」を書く。
  3. 箱と箱を「リレーション」の線でつなぐ。
  4. 線の両端に「カーディナリティー」「オプショナリティー」の記号を書く。

 

ER図で使う記号は、「IE記法」や「IDEF1X記法」など、いろいろな規格がある。

情報処理技術者試験のデータベーススペシャリストの問題では、「UML」という図の記法も使われる。

 

 

 

(3) 論理設計

 

正規化とは?

正規化 Normalization」とは、データの形を「正規形」(Normal form)に変えること。

ざっくり言うと、テーブル(表)を分割して、データの重複や不整合を解消する作業だ。

 

テーブルの形を変えていくステップには、第1~第5まで5段階ある。

  1. 第1正規
  2. 第2正規
  3. 第3正規
  4. 第4正規
  5. 第5正規

それぞれの変形方法について理解しておこう。

実務では第3正規形まで正規化できればとりあえずOK

 

第3.5正規形(ボイス-コッド正規形)

第3正規形をより厳密にした「ボイス-コッド正規形」という形もある。

第3と第4の間なので「第3.5正規形」とも呼ばれている。

(ボイス-コッド形もカウントに入れたら、第1~第5、+第3.5で計6段階になる。)

 

非正規

正規化を進めると、SQLJOIN」の利用が増えてくる。JOINを多用する処理は遅い=DBの性能低下につながる。

第3正規形まで分割しても、実際に使ってみて遅い場合は、第2正規形や第1正規形に戻して使うこともある。これを「非正規化」とか「正規化を崩す」などという。

 

RDBでは処理速度が遅くなる場合、代わりに「NoSQL」を使う場合もある。

 

 

 

(4) 物理設計

 

時間がない場合、先にGUIDB管理ツールでデータベース作成してしまい、その後でテーブル定義表を作成することもある。

 

DB設計に慣れてきたら上記の各段階はすっ飛ばして、いきなりデータベースを作れるようになるだろう。

 

ここまで、SQLの使い方やデータベース設計について学びました。

次回は、その他のSQLに関連する話も見てみよう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181026145516 増田プログラマー養成講座 その12 データベース参考書

anond:20181028152656 増田プログラマー養成講座 その13 SQL文法

anond:20181031014212 増田プログラマー養成講座 その14 Webアプリの試作品作成

anond:20181101225335 増田プログラマー養成講座 その15 Webアプリの完成見本

anond:20181101230220 増田プログラマー養成講座 その16 Webアプリの完成見本(続き)

anond:20181104161900 増田プログラマー養成講座 その17 Webアプリの骨組み

anond:20181104233013 増田プログラマー養成講座 その18 SQLデータの追加と取得

anond:20181110120715 増田プログラマー養成講座 その19 SQLデータ更新

anond:20181110182445 増田プログラマー養成講座 その20 SQLデータの削除

anond:20181111205255 増田プログラマー養成講座 その21 データベース設計 (1)要件定義

anond:20181119224031 増田プログラマー養成講座 その22 データベース設計 概念物理 ←★今ここ★

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-23

増田プログラマー養成講座 その10 OOP参考書

前回はオブジェクト指向プログラミングOOP)の使いどころを学ぶために、MVCフレームワークを使ってみました。(ほんの触りだけ)

今回はOOP理解を助けるための参考書を探してみましょう。

 

OOP参考書

OOPに関する有名な本はたくさんありますAmazonレビュー評価が高い本は、定番の本が多いです。

だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初意味チンプンカンプンだと思います

最初意味が分からなくても)なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます

 

オブジェクト指向でなぜつくるのか 第2版

この本は、OOP概要、基礎知識コンパクトにまとめられています

今の自分知識の過不足をチェックできます

この本を1つの目安にして、今後の学習指針を立ててみて下さい。

 

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

https://www.shuwasystem.co.jp/products/7980html/4614.html

この本は、OOPも含むプログラム設計ノウハウ原則をまとめて紹介しています

カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます

今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います

(第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。)

 

オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

https://gihyo.jp/book/2016/978-4-7741-8361-9

この本は、上記2冊の内容を具体的な事例で説明しているような本です。

OOP解説本をいろいろ読んでみると、

などといった用語に出くわすと思います

これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います

サンプルコードRuby説明されていますが、何らかのOOP言語を使ったことがあれば、Ruby文法を知らなくても、だいたい意味は分かると思います

 

プログラミング入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味理解できないと思われます

しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな!」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います

 

プログラミングって難しいイメージがありますけど、習うより慣れろの精神で、とりあえず適当に触ってみるのがいいと思います

 

その他

PHPを使って、OOP基本的な仕組みを説明をしたので、PHP入門書を挙げるなら、とりあえずこの1冊。

自分にとっては分かりやす説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。

 

Java入門書文法の基礎を学んだら、次に読んでみたい本。

デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います

(なんでこういう書き方をしてるんだろ?とか、定番の書き方=パターンがいくつかあるので。)

 

グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります

リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分メンテナンスするときに苦労が減ります

 

今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります

自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります

図書館本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。

 

本のコストパフォーマンス

リファレンス文法辞書など)は、読む頻度が多ければ、買って損はしない=元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。

プログラミング専門学校かに行ったら、学費が何十万円もしますね?それを思えば本なら安いものです。)

 

プログラミング学習曲線

プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね?

プログラムサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います

でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます

学習曲線で言えば、滑らかな右肩上がり(/)ではなく、ある時グイッと変わる階段状(_l ̄)の変化に近いと思います

なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。

理解を早める補助として、上記のような参考書活用されてみて下さい。

 

まとめ

今回までで、手続言語構造プログラミングオブジェクト指向プログラミング)の基本を知りました。

次回は、問合型言語SQL)を学び、データベースを使いましょう。

 


anond:20181015215004 未経験からプログラマーなんだが全然からない

anond:20181016015826 増田プログラマー養成講座 その1 パソコンの用意

anond:20181016164341 増田プログラマー養成講座 その2 プログラムデータ+処理、プログラム言語の種類

anond:20181016180059 増田プログラマー養成講座 その3 構造プログラミングの基本(順次、反復、分岐

anond:20181016193144 増田プログラマー養成講座 その4 子ども向け教材「Scratch」で構造プログラミング練習

anond:20181017161003 増田プログラマー養成講座 その5 オブジェクトとは何か?

anond:20181017191404 増田プログラマー養成講座 その6 OOPの種類、PHPの準備

anond:20181019181549 増田プログラマー養成講座 その7 OOPの仕組み(前半)

anond:20181020230044 増田プログラマー養成講座 その8 OOPの仕組み(後半)

anond:20181022232327 増田プログラマー養成講座 その9 MVCフレームワークを使ってみよう

anond:20181023184616 増田プログラマー養成講座 その10 OOP参考書 ←★今ここ★

anond:20181024214133 増田プログラマー養成講座 その11 データベースを使ってみよう

anond:20181024214737 増田プログラマー養成講座 コンテンツ一覧

2018-10-15

おまえら最近UMLとか書いてるかい

昔はよく書いていたのだけど、最近めっきりかかなくなった。

時代の流れは早いよな。

2018-08-23

仕様書を書くためのシステム

って作れないんだろうか

UML作成ツール

うーんもっと分かりやす

 

最近プログラミング作るゲームみたいなの流行ってるけど

言葉記述するから仕様書を書くシステム」っぽくなってる

アレみたいな感じで書きたい

2018-06-28

時代とともに変わるソフトウェア開発の基礎

コンピュータソフトウェアを開発、運用するエンジニアが持つべ知識スキルの基本セットとは何か?

例えばインテルCPUアセンブラが書けます!と言った場合就活で有利になる場面がどれだけ想像できるか。

UMLクラス図書ます!とか、暗号化理論バッチリだぜ!とか、相対性理論なら任せとけ!とかの場合

おうおうおう、だったら弊社のホームページをカッコよくしてくれよみたいな案件無難にこなせるのかというと

甚だ疑問では無いだろうか。

一昔前はソフトウェアハードウェアのおまけだったわけで、ハードウェアこそがエンジニアが抑えるべき基礎だった。

時代は変わり、ソフトウェアでできることはものすごく多くなった。スマホアプリを作るのに組み込み知識がなくても困らない。

からこそ、現代ソフトウェアのみのエンジニアは旧来のコンピュータ関連エンジニアと道を分かたれている事を自覚しなければならない。

自分キャリア自分デザインする必要があるということ。

古いエンジニアの教えに沿えば、自分も古いエンジニアになる。

今の時代の最適解を見つけるのは困難かもしれない。

だけど組み込み系やマイコン制御をしないのであればアセンブラC言語よりも優先して学習することはいくらでもある。

C#C++よりもPHPが優先される場面もある。

html,css,javascript をある程度自在に扱えるようになるのも長期間の訓練による積み重ねが必要になる。

コンピュータサイエンスネタが無いな……これはプログラミングに役立つネタももちろんあって、構造プログラミングオブジェクト指向プログラミングなんかもそうだけど、表層的に関数分けました、クラス分けましたとかしてもうまくいかない。ネストが浅けりゃいいってわけじゃない。プログラミング以外のネタもある。サラリーマン巡回問題とか。

2018-06-05

anond:20180605110042

UMLとか図形がメインだと図の方がよさげなのはわかった

anond:20180605110042

いたことねえな。普通設計書だろ。

UMLとかERを図というのは分かるがそれでもドキュメントタイトルとしては設計書した見たことないし書いたことない。

2018-03-16

ちょっと羨ましい

プログラマやってるけど、昔話を聞くに、本当に隔世の感があると思わされる。

だって昔のプログラマ仕事って、入念に机上デバッグされたフローチャートを、ただひたすらCOBOLFortranアセンブラ翻訳して、コーディングシートに書くだけの仕事だったんでしょ?

フローチャートで書ける程度のロジックなんて全然難しくないので、シートを書き終わった時点で事実上プログラムは完成したに等しいと。

あとはパンチしてもらって、テストは大抵一回動かすだけで全部問題なく通って一丁上がりと。

そうなると、これはもう気合と体力の問題って話になる。

そりゃ月残業300とか働くのも決して不可能じゃないし、それだってハイになった勢いでガシガシ書けるだろう。

そうやってカネがっぽり稼いで、日々のモヤモヤは酒タバコ麻雀パチンコ風俗スッキリさせて、そんでまた思いっきり働く。それが男だろ!ってノリだよな。

仕事懇意になってるパンチャーのお姉ちゃんと裏で仲良くなって、そのまま付き合って…なんてのも普通にアリだろう。

昭和は明るい時代だったんだなあと、少し羨ましくなる。


今はもう、あらゆることが複雑になりすぎて、設計だってUMLER図で対処できるかすら怪しくなっている。

言語だってJavaだけじゃなく、SQLやら、HTMLCSSJavaScriptと心得てないと仕事にならない。

そして何より、動かして試して、都度直していかないと分からないことだらけになっている。

プログラマの脳にかかる負荷は昔と比べ物にならない。当然あまりに長時間労働事実上不可能

俺は残業100まで行った所で帯状疱疹が出て、シャワーで腰をさすりながらココらへんが限界と思い知らされた。それが10年前。

勿論今はもっと無理が利かない状況。


でも、残業300可能時代を、色んな会社で現役として駆け抜け出世した幹部オヤジ達に、今のプログラマが抱えているアレやコレやらは、多分理解できない。

それくらい、時代が変わりすぎたのだろう。見えている世界が違いすぎる。

から今の若い奴らを根性無しとして完全に見下しているし、本音では「なんだよ急に辞めやがって使えねーなー」とか「アイツ死にやがった、ざまあwww」と思ってる、人でなしの老害ばっかり。

勿論FortranC/C++Javaみたくスキルを身につけてきた人は例外だけど、本当に例外中の例外でめったにいない。

それで「昔のままのノリじゃ、今の開発は絶対に稼げない」ということに思い至らない。

こんなブラック業界、やっぱり一度潰れたほうがいいんだろうと思わされる。

2018-02-11

年収240万のWEBプログラマ底辺会社や人に対して抱いてる不満

会社について

パソコンスペックが貧弱

事あるごとにだんまりするパソコンを使い続けている人って本当にすごい。

自分場合によってはログイン画面で既に半ギレなのに。

キーボードマウスが貧弱

USB接続セキュリティ的にどうのこうのって言うけど、多少手間が掛かっても好きなの使わせてよ。買ってくれとはいわないから。

ディスプレイが貧弱

自分は最低でも3つは欲しい。こういう仕事してればウィンドウだらけになるじゃん。

・机が狭い

机が広いってだけで効率と気分が良くなる気がする。というかディスプレイが置けない。

通路が狭い

後ろを誰かが通るとき、逐一すみませんって通路を開けなくちゃいけないのつらい。

・イスがしょぼい

腰がつらい。

ライセンスを買ってくれない

アクティベートしないまま使わせるのは百歩譲るとしても、ヤフオクとか怪しいところからマイクロソフトアドビライセンス仕入れて使わせるのってどうなんだ。

そういう思考回路人間は、バレないからとか、まわりもやってるとかい免罪符を盾に、法律倫理も破っていいとか考えていそう。特に労働基準法的なやつ。

・開発環境が整っていない

gitってなに・・・?ってところからはじめたくない。

JetBrainsIDEを使うのに骨折って交渉するところからはじめたくない。

・なにをするにも申請必要

めんどい。上掲した項目を実現するのに、対費用効果がどうのこうの・・・って。誰が得するんだよ。

労働者労働環境に対して金払いが悪い

ベンダー資格とか高いけどさ、業務関係するのなら、資格手当が出ないのなら、せめて合格したとき受験料払ってよ。

一般的感覚会社負担費用個人負担にさせるような会社は嫌い。好きになれない。

・気分良く仕事をしてもらうという働きかけが一切ない

高い意識を持って働いてほしいだとか、会社を好きになってほしいとか、そういうこと全く思っていないのだろうか。

あるいはそれが労働者として当然のことで、自然にそうなるとでも思っているのだろうか。

少なくとも自分は苛立ってると普段より頭の回りがそれなりに悪くなる。

残業だってそう、連日遅くまで残って仕事して、それで効率よく質の良いものを作れるとは到底思えない。

プロ意識をもって仕事しろとか言っちゃう

240万にも満たない年収で雇ってるんだから、ちゃんとその程度のゴミを雇ってるって自覚持ってほしい。

お金を貰ってるんだからとか、社会人なんだからとか、そんなん言われただけでやる気になるわけねーだろ。むしろやる気なくなる。

この年収自分が幾らか熱意を持って仕事したり勉強するのは、あくま自分個人的な興味や矜恃の問題から

というか発注する客側もそう。然るべき時間費用があってこその質なのだから、短い時間と割安な費用で納品されるのはゴミだと自覚してほしい。

短い時間と割安な費用でも、企業として質の高い製品を納品するのが当然だと思っているのだろうか。まあゴミが納品されるんですけどね。

残業は全額はでないのが当然とかい唾棄すべき風潮

そういう会社は等しく今すぐ潰れろ

・隣の人と距離が近すぎる

ほどほどが良い。Slackみたいなコミュニケーションツールがあって、気軽に話せるけど、物理的には近すぎないのがいい。

・書いたり貼り出したりする場所が少ない

壁を自由に使えると手軽で良いな。

UMLを知らない、使わない

複雑なものをある側面から、誤解なく簡素に表せる、素晴らしい言語なのになぜ使わないのか。

draw.ioみたいな便利なのがあるのに、Excel方眼紙アクティティ図に似て非なる謎の図を書き続けるのはなぜなのか。

テスト時間をかけるという風潮がない

画面を動かしてみて、できました、このテストおわりです、それで済ませて質が高くなるわけないだろ。

そもそもjenkinsとかcircle ciとか誰も知らないseleniumとか聞いたこともない。

ウォーターフローにとらわれてる

前もって仕様が確定することなんてどうせないじゃん。いつまでたっても客側にいいように言われて、しっちゃかめっちゃかされるんでしょ。

なら保守されないExcel方眼紙を量産したって仕方がないじゃん。せめてじゃあその辺は最低限にして動くものを作ろうよ。

からってアジャイルにしようとは絶対にならないだろうけど。。。そういう参加を客側と交渉すること自体ありえないって思ってそうだし。

でもさあ、とりあえず動くものを早い段階から見てもらうくらい良いじゃん。どうせこそこそやると後になって見たいって言われて叩かれるんだから

人について

・話が長い、でも資料もないし書き出さな

話の論点がズレて、何を話したかったのか、何を聞きたかったのかわからなくなる。そして後から言った言わないになる。

あらかじめ資料を用意しとくなり、どこか広いところに書きながら話そうよ。で、できれば書いた人がデータとしてどこかに投げてほしい。そして消しておいてほしい。

言葉意味を大切にしない

訳のわからない造語を使い出したり、意味を分かってないのにその言葉不用意に使うの止めてほしい。

きっとそういう人って、まずその言葉意味理解しようという意志が致命的に欠けているから、会話していて不毛感が凄い。

・長く書くことをしない

短い文章齟齬なく十全な文章を書けることは確かに素晴らしいことだけど、だいたいそんなことは出来ない。

から多少冗長であるように思えても、細かすぎるように思えても、長く書いてほしい。

つーか、毎度毎度短い謎の書き残しがあって、それの話を聞きに行くのつらいんだよ。わかってくれ。絶対わかってくれないけど。

読んで意味のわからないことって、読んだつもりにだけなってしまって、後で指摘されると読む側が一方的に悪いことにされたりするのつらい。

・居眠りする

正直自分の気づかないところなら好きなだけ寝ていてもいいけど、まあ気づくし。

眠い頭でこういう仕事なんて効率よくできるわけないのに。つまり目障り。

自分過去を話したがる

興味ないから。前の会社とか、そこでなにしてたとか。知りたきゃこっちから聞くよ。

自分が興味あるのは自分が抱えてる仕事を如何にしてうまいことするかなんだよ。話すなら年長者としてそれを話してくれ。

2017-11-08

anond:20171107110105

> ここ5,6年の悩みで最近はっきりわかってきたんだけど、俺いつのころからかどうやって勉強していいのかわからなくなった。

> 一番大きいのは結婚して子供できて自由時間が減ったことなんだろうけど、でもそれ以前から勉強ぜんぜんできなくなったの。

お前は俺かってくらいまったく同じ状況。なので最近ずっと「俺ってもっと優秀な人間じゃなかったか」って思って自己分析してるんだけど、ここ数年で一気にスキルセットが変わったのが大きな原因かなと思ってる。デザインパターンアスペクト指向UMLプロジェクト管理手法、積み上げてきたものはたくさんあるけど、今はまったく使えない。若者より知識ものすごくあるけど、意味がなくなった知識ばかりなので実質的比較をするとほぼ対等。アジャイルクラウド機械学習・・・新しく出てきて若い世代が中心的に学んできた技術存在を考えると、おっさんたちはむしろ若者よりマイナスになってしまったわけ。知識の量は若者より多いのに関わらず。

なので、勉強をするときも「若者よりスタート地点がだいぶ低い」という観点勉強しないとダメだと言う結論に至った。その方法とは、簡単コンテンツを、大量の時間をかけて大量に吸収する、ということ。

後、子供はもう致命的な。特に休日今までは合計で16時間くらいは勉強に使えていたのが0時間になる。一ヶ月だと64時間くらい消えてるのね。勉強できないってより勉強してない。となると、前述の「大量の時間をかけて」が無理ゲーなので、すでに詰んではいる。

> もう俺は嫁さんと一緒にあと20年近くかけて子供2人育てなあかんからITが好きか嫌いか仕事選べる立場じゃねーーーの!

「すでに詰んではいる」と書いたとおりなのだが、これもまったくの真実。「技術ができない人」が「大金を得なければならない」。しかもそれは自分のためではなく、家族という他人のため。その行為は悪ではなく、善。

驚くべきことに結婚して子供ができると「能力の低下」と「収入の増加」を同時に満足させなければならない。そのためにできた制度が、おそらく年功序列であり、管理職なのであろう。そして今はその制度が壊滅しつつある。それでもこの矛盾と戦わなければならないので、結局は能力がなくても若者からお金を奪っていく方法を考えて、どんな手段を使ってもそれを実践していかなければ家族(言い換えると次の世代)を守れない、ということになるだろう。

管理職になる他にも、自分の持ってるレガシー技術を後輩に強制して、自分レガシー知識有効となる土俵議論を持っていくという手もある。いずれにしてもろくでもない。

2017-06-17

Web系に入社して3年目 人生相談

うちの会社Web系なんだから当然っちゃ当然なんだけど、案件の8割くらいはCMS案件なのよね。

それもWordPress脆弱性出しすぎとかで保守しにくいってことでもうちょいマイナーCMSが中心。

プログラマーとして入社してから今まで、デザイナーが渡してきたHTMLファイルCMSテンプレートとして構築する、

っていう作業社会人生活の半分以上を占めていて、業務としてはPHP簡単プログラミングすらあんまり経験ない気がする。

CMSテンプレートもif文とかループとかあるからこれもプログラミングといえばプログラミングなんだけど、

Web系っていうともっとPythonとかNode.jsとかVueみたいなキャピキャピした技術に触れるもんだと思ってたよ。

給料は安いけど割りかし残業も少なくて何かとヌル会社から今のところやめるつもりは特にないんだけど、

ディレクターとの調整とかExcel方眼紙仕様書(多分一般的SEが作るのよりはかなり簡潔なもの、勿論UMLとかはない)書いたり見積もりしたり操作マニュアル書いたりっていう経験はあっても

下流工程を生きるプログラマーとして例えば5年後10年後、技術的なキャリアとして「HTMLファイルをよくわからんCMSテンプレートとして当て込むだけのことを長年やってきたおじさん」

誕生したとして、果たして生きていけるのか心配になってきた。

僕は生きていけるのでしょうか。転職した方がいいんでしょうか。教えてください。

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2017-01-29

Excel方眼紙はクソ!Markdownが至高!」みたいな無能

一般的仕様書とか図形、UML使いまくりなんだけどそれはどうしろと?

Excel方眼紙叩いてるのって社会経験のないクソ大学生ばっかなんだろうな

Excel方眼紙より表現力の豊かな媒体は今のところ絶対存在しない

2016-11-18

メンバー設計書をwikiで書きましょうって提案された

私はソフトウェア製造業で十年近く働いているが設計書と言えばExcelまたはWordだった。

UMLなどの作図にツール使用することはあっても、最終納品物としてはExcel画像として張り付けて提出していた。

もちろんExcel方眼紙については批判もあるのは理解しているが、開発者運用者、顧客など関係者すべてが手間なく簡単に読めることを条件とすると、やはりExcelに落ち着いてしまう。

 

そんな私に表題のようなことを提案されたわけだが、最初何を言っているのかわからなかった。

設計書と言えばExcelという私には設計書をwikiで書くという発想がみじんもなかったからだ。

開発者運用者、顧客のだれでも手間なく容易に読めるという条件はwikiでもかなえられることに気付いたが、私にはwiki知識ほとんどない。

 

彼に詳しく聞いてみると、前に参画していたプロジェクトでは社内サーバに建てたwiki用語集として活用していたそうだ。

wikiには顧客業務専門用語などを記載して、製造工程以降に参画してくるメンバーとの情報共有のツールとして使用していたらしい。

そういった運用をしているうちに彼はwiki自体設計書とできないか考え、調査したところ実際にwiki設計書として使用している会社もあるようだということで、今回提案に踏み切ったらしい。

 

私も今調べてみたところwiki設計書を書くという運用をしている会社もあるようだが、メリットデメリットwiki知識があまりない私には判断しかねている。

ぱっと思いつくデメリットとしては、第一に、やはりマークアップ記述するコストが非常に大きいように思える。

記述する手間だけでなく、記述するスキルを手に入れるためのコストも考えると無視できないコスト必要となるように思える。

第二に、保守以降、一つのシステム複数改修案件や故障対応が並行するようなことはままあることだが、ソースSVNなどで管理できるがwikiはできないため、設計書とソース間で不整合が発生することは大きな問題である

 

メリットとしては、リンク機能で各設計書間を容易に行き来できることが第一に挙げられる。

第二に、改訂履歴差分が標準で用意されていることもメリットであろう。

第三に、検索が容易であることがあげられる。この点はExcel比較して十分大きなメリットだと思っている。

 

私がぱっと思いつく限りではこんなもんである

はてな諸兄の中にwiki設計書を書いたことがある方がいれば、メリットデメリット、その他運用において気をつけるべきことなどあればご助言願いたい。

 

なお、今回の案件は数万LOCの小規模な、VBからWEBアプリへの置き換え案件であり、顧客から設計書の決まった書式などは指定されていない。

そのため自社の標準の設計テンプレート使用する予定だった。もちろんExcelである

 

また、設計作成使用するツールExcelWord以外の素晴らしいツールがあれば教えていただきたい。

どうかよろしくお頼み申し上げ候。

2016-11-04

IT界隈の動物たち

GitHubの謎生物が気になり、せっかくなのでIT界隈の動物(?)を用いた名前ロゴの由来など調べてみた。

※追記あり:Gopherファンに襲われそうなので。ごめんねGopher

GitHub

種類:octocat(ネコタコ

名前:monalisa

Q.どうしてタコなのに8本足じゃないの?

A.なにも考えずに描いたからね!

もともとデザイナーはoctopussと呼んでいたが、いくら訂正してもGitHub社員がoctocatと呼ぶため、octocatで落ち着いた。

octocatはあの生物種の名称であり、monalisaという名前社員の娘が学校課題で名付けたもの

Python

種類:ニシキヘビ

名前: -

イギリスコメディ番組空飛ぶモンティ・パイソン』より。

またPythonという英単語はニシキヘビを意味するため、マスコットとしてヘビが用いられる。

オライリーの本とかすごい表紙だよね。

PHP

種類:ゾウ

名前:ElePHPant

PHP」という字面が、横から象を見たような感じなので。

PostgreSQL

種類:ゾウ

名前:slonik

動物ロゴにしたいなら、象なんてどうだい?アガサ・クリスティ小説にもある『象は忘れない』だ」

   ― PostgreSQL発足時のメーリスより

Evernote

種類:ゾウ

名前: -

象は記憶力が非常に優れた動物のため。PostgreSQLと同じで、象の優れた能力あやかっている。

GNU

種類:ヌー

名前: -

GNU is Not Unix.

Mozilla Firefox

種類:キツネ

名前: -

もともとPhoenixという名前だったが、商標権侵害していたので、公募Firebirdという名前に決定。

しかし今度はDBに同じ名前があったので、Firefoxレッサーパンダの別名)に改名

みなさん命名は慎重に。

Docker

種類:クジラ

名前Moby Dock

白鯨Moby-Dick)』より。クジラ採用した理由デザイン見れば納得。

個人的に一番センスのある名前デザインだと感じる。

Linux

種類:ペンギン

名前Tux

名前タキシードTuxedo)を着ているように見えるから

ロゴコンテストで決定されたが、他の作品を見ればなぜ選ばれたのかよくわかる。デザインって大事

https://www.cs.earlham.edu/~jeremiah/linux-pix/linux-logo.html

Twitter

種類:鳥

名前:ラリー・バード

名前NBAのラリー・バード選手より。社員ファンだったらしい

ちなみに初期のTwitterデザインGitHubデザイナーが手掛けたもの。すごいっすね。

Seaser

種類:シーサー

名前: -

開発者出身地沖縄だったので。

MySQL

種類:イルカ

名前:Sakila

データ大海原を進む、という意味をこめてイルカ採用

Apache Tomcat

種類:ネコ

名前: -

オライリーの本に載ることを考慮して動物マスコットにしようと考え、「自立した強かさ」を持つという意味Tomcat(雄猫の愛称)を採用

しかし、猫はオライリーUML本で使われてしまい、念願のTomcat本にはユキヒョウが使われたという…。

が、最近Tomcat本には猫が使われた。めでたし。

Apple

種類:Dogcow(イヌ+ウシ)

名前:Clarus

昔々、Mac OSで用紙の向きや色を表示するために使用されていたらしい。

知らんわ。

Plan 9 from Bell Labs

種類:ウサギ

名前:Glenda

OS名前であるPlan 9~」はエド・ウッドの『Plan 9 from Outer Space』に由来。

ウサギ名前であるGlendaはエド・ウッドの『グレンとグレンダ』に由来。

どんだけエド・ウッド好きなんだよ。

Go

種類:ホリネズミ

名前Go Gopher

彼の歴史Goプロジェクトよりずっと前、1999年に遡る。

ニュージャージーのWFMUラジオで、Renee Frenchによって宣伝用のTシャツに描かれたのが、彼の初登場。

その後、Bell labsのメールシステムアバターとして起用もされた。

(ちなみにReneeはBell labsのGlendaを描いた人。Glendaもアバターの一員だった)

そうして2009年Goプロジェクトが発足し、ロゴ検討していたメンバーにReneeが無償で描いてあげたのが「Go gopherである

みんなGo Gopherと呼ぶので、特に固有の名前は無いらしい。

由来は下記サイトにありました。

https://blog.golang.org/gopher



調べてみた感想:週末にエド・ウッド作品見てみようかな、と思いました。

2016-09-03

なぜITはこんなにも不完全なんだ

もう50年も60年も経つじゃないか

なぜ未だにトランジスタについて学ぶ必要があるんだ

なぜ未だにCPUの内部構造について知っているのが当たり前という風潮なんだ

なぜ未だにC++が書けるプログラマが本物のプログラマ呼ばわりされているんだ

なぜ未だにコーダーという単純労働者必要とされているんだ

なぜ未だにホームページ屋さんという職種が成り立つん

なぜ未だにCiscoの設定書くだけの資格がもてはやされるんだ

なぜ未だにアルゴリズムを書く能力絶対必要だとされるんだ

なぜ未だにプログラムを書いているのではなくAPIを叩いているだけだという罵倒が成り立つん

なぜ未だにマルチスレッドプログラミングなんて手で書いているんだ

なぜ未だにUMLマウスポチポチ書かなきゃいけないんだ

なぜ未だにライブラリが増え続けるんだ

なぜ未だにコンピューターサイエンスなんて学問必要とされるんdな

もうプログラムを書きたくない

方法論を考えたくない

そんなのを作りたいものを作るだけの人間が考えるのは間違ってる

簡単に良いものが誰にでも出来ることが理想に決まっているだろう

人間なんて働かないほうが良いに決まっている

なぜこんなにも不完全なんだ

なんでまだこんなにも人間の手を煩わせるんだ

こんなのは現代手工業

SOHOが成立するのは時代が進んでいるんじゃないぞ

フレックスタイム産業革命以前への退化だぞ

早く産業革命が来てくれ

人間に何も考えさせないでくれ

もう休ませてくれ

助けてくれ

2015-07-25

UMLとかシーケンスとか状態遷移とか

凄く優秀な営業がいて、以下のどれかを必ず顧客に納得させられるとするわね。

クラス図やシーケンス図等のプログラム設計図を......

1.納品する  お金貰う

2.納品しない お金貰う

3.納品する  お金貰わない

4.納品しない お金貰わない

どれが良いか。

アチシは3が良い。

お金貰っちゃうと、行き過ぎた品質を求められちゃうの。

(誰が適切な品質だと判断出来るの?だから最初から100%目指すのよね!)

2と4はきらい。

2はだいっきらい。4よりきらい。

お金理由に、怠けを暗黙的に認めちゃうじゃない。

怠けたらね、それは将来アチシ達に利子付きで帰ってくるのよ......

オラァ!トイチ言うたろォ!!?オドレェ!!!

(利子って何かというとね、大体は物忘れってやつだと思うわ)

2014-07-22

オブジェクト指向を学ぶ意味とは

今月に入ってからJava(ゆくゆくはAndroid勉強してる素人なんだけど

http://qiita.com/kenokabe/items/13ea8d2da6adce1b3b9a

http://d.hatena.ne.jp/nowokay/20140718

こういうの読むと、別に理解出来てるわけじゃないものの、じゃ今OOPやる意味ってなんなんだろと思う。

地固めというか、それでも基礎力つけるためにひと通りはやったほうがいいのかな。

デザインパターンUML書きながら、動作と意味を追いながらとりあえず書経してるけど、

周りに相談できる人もいないので、ここで訊いてみた。

初めてはてなダイアリー書いてみたら、記法からなくてアメブロみたくなったので死にたい

2014-02-04

ゾーン』に入る方法

ゾーン』とは、極度に集中した精神の状態のことです。『フロー状態』とも言います

極度に集中した状態では、時間の流れが遅くなり、作業は、なめらかに転がるように、よどみなく進んでいきます

私はプログラマーですが、『ゾーン』に入ってバリバリ書きまくれるときもあれば、躓いてばかりでちっともコーディングが進まない時もあります

今日は私が実践している『ゾーン』に入るための方法を説明します。

あらかじめ断っておきますが、私がこの方法で『ゾーン』に入れるのは、10回に3回です。

気温の変化、体調の変化、途中で割り込みがないか、前日よく眠れたか合コンで意中の相手に無視されたか、などなど、

ありとあらゆる影響が『ゾーン』に入ることを妨げます

それでも知りたい、という方は続きをお読みください。

事前準備

人の脳のうち、自覚して使われていない部分を「無意識」の領域と呼びます

無意識」には、「意識」下にあるリソースとは比べ物にならないほどの莫大なリソースがあります

ゾーン』に入ると、そこにあるリソース有効活用できます

ふだん「無意識」下には、”生活するためのプログラム”、”危機を回避するためのプログラム”などが常駐プログラムとして走っています

無意識」の空きリソースを確保するために、それらを一旦終了する必要があります

作業の途中で、お腹が空くことに備える。

まず、作業の前に食事をとってください。食事は胃もたれする脂っこいものや、体内で性質を変えるもの――カフェインアルコール、などを避けてください。

そして、作業の途中でお腹が空いた時のために、おやつを用意しておきます

おやつは”自動的に”食べられるものが良いです。

食べかすが溢れるクッキーなどは避けてください。手が汚れる羊羹などもいけません。できれば手づかみで食べれる、まんじゅうなどがよいでしょう。

包装されているものは、あらかじめ皮をむいておきましょう。

トイレにいっておく

生活するためのプログラム”に、”必要タイミングトイレに立つ”というものがあります

作業開始の前に用を足しておきましょう。

また食生活を習慣化すると、発動のif条件が時間のチェックだけで十分になるので、ある程度このプログラム要求するリソースを減らすことができます

割り込みを減らす

とちゅうで誰かから電話がかかってきたり、メールが来たり、アラームが鳴ったり、上司から呼び出されたりすると、『ゾーンから強制的離脱させられます

携帯電池を抜いたり、割り込まないように上司を説得しておく、などの対策を取りましょう。

誰かが訪ねて来ないようにするために、できれば作業はブースや自室で行うのが好ましいです。

予定を減らす

あなたの脳の実行ループには、"予定されていた行動のために準備する"というタイマーセットアップされています

これも実はリソースを食っています

たとえば夜に意中の女の子初デート約束があるようなとき、その日の日中に『ゾーン』に入ることはできません。

女の子とのデートを諦める、などすれば確実なのですが、そうもいかない方々も多いでしょう。

私は彼女と話をつけて、デート彼女の方から誘ってもらうようにしています

(脱線しますが、一番危険なのは、”予定された致命的な割り込み”です。上司からちょっと話があるから明日の午前、俺のところに来てくれる?」などと言われた時、プログラマーたるあなた今日は、人生から消え去ります。作業は上の空で、全く手につかないでしょう。)

つまづきを減らす

プログラミングの途中で、API仕様を調べたり、バグレポート分析したり、他部門に問い合わせたりすると、そこで『ゾーンからはじき出されてしまます

APIに習熟するために十分に練習をしておきましょう。

問い合わせが必要なら、それも済ませておきましょう。

分析はあらかじめ済ませておき、プログラミングを残すのみ、としておきましょう。

なお、これは人とプロジェクトによるかと思いますが、クラス設計まで事前にしておく必要はありません。

深い『ゾーン』に入った時は、正しいUMLが頭のなかに勝手に浮かんできます

以上が事前準備です。すべての項目を念入りにチェックしてください。

一つでもおろそかにしていると、そこがあなたの集中の限界になります

実際の作業に入る

準備は出来ましたか?それでははじめましょう。

トランス系の音楽聴く

作業開始時に音楽を聴きます

私は音楽に詳しくありませんが、知り合いのすすめでトランス系の音楽聴くようにしています

google:psytrance youtube

これをヘッドホンで聴きますiTunesホットキーを設定して、簡単に音量を落とせるようにしてください。

ゾーン』使いの中には、作業前に深い瞑想を行って、一気に突入する、という人もいますが、

私は音楽を聞きながら、徐々に入ることをおすすめします。

一気に入ると、うまく入れるときには良いのですが、入れなかった場合、次回に『ゾーン』に入るとき、”すごく面倒くさく”なってしまうのです。

(これはおそらく、精神へのダメージを防ぐための防御プログラムの働き、のようなものだと思いますが、詳しくはわかりません。)

自分に言い聞かす

作業に集中できてきたら、次の文句を頭のなかで唱えましょう。

「集中するのを面倒臭がっている自分がいる。一方で、深い集中に入っていく自分がいる」

だんだん集中が高まっていく自分気づきましょう。

思考を言葉にするのをやめ、イメージにする

人は普段、自分がやろうとしていることを”言葉”にして、明示的に考えます

これは「意識」下のプロセスです。

無意識」の領域で思考を行うために、”言葉”にするのをやめます

具体的には、作業しながら、次のイメージを頭に思い描きます

       鉄 
 ___________
 |     |
鉄| (磁石)  |鉄
 |     |
 ----------
    鉄

鉄に囲まれた部屋に、丸い磁石のたまが浮かんでいる、という状態です。

これは登大遊氏が考案したテクニックです。(彼はこのイメージを伴った方法を「論理的思考放棄」とよんでいました)

磁石は集中がブレると、鉄に引き寄せられてぶれてしまますが、

集中が高まると、中心で微動だにしなくなっていきます

このようなイメージを頭のなかに維持し、磁石を真ん中に維持するようにしながら、プログラミングの作業を続けてください。

この方法に慣れるまでには時間がかかりますが、うまくできるようになると、『ゾーン』への突入確率が劇的に上がります

飽きてきたら、やめる

作業に躓いたり、なんとなく飽きてきた、やる気がなくなってきたら、即座に作業をやめましょう。

無意識」下でなんらかの常駐プログラムが働いて、思考をだんだん”濁らせて”いるのです。

ゾーン』に入っているあなたは、このプロセスの進行が手に取るように分かります

ここで無理に戻そうとすると、「無意識」下の思考のコントロールを失い、次回に『ゾーン』に入りにくくなってしまます

潔く諦め、集中をほどいて、作業を終わりにしましょう。

以上です。。

2013-11-20

http://marupeke296.com/OOD_No2_CS1_HalloWorld.html

コンポジションを表す線が、UMLと逆じゃないっすか?これ。

ClassA ◆─── ClassB

は、

class ClassA {
	ClassB _classB;
	public ClassA() {
		_classB = new ClassB
	}
}

class ClassB {}

ですよね?

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん