  |
はてなキーワード: UMLとは
プログラマやってるけど、昔話を聞くに、本当に隔世の感があると思わされる。
だって昔のプログラマの仕事って、入念に机上デバッグされたフローチャートを、ただひたすらCOBOLかFortranかアセンブラに翻訳して、コーディングシートに書くだけの仕事だったんでしょ？
フローチャートで書ける程度のロジックなんて全然難しくないので、シートを書き終わった時点で事実上プログラムは完成したに等しいと。
あとはパンチしてもらって、テストは大抵一回動かすだけで全部問題なく通って一丁上がりと。
そりゃ月残業300とか働くのも決して不可能じゃないし、それだってハイになった勢いでガシガシ書けるだろう。
そうやってカネがっぽり稼いで、日々のモヤモヤは酒タバコ麻雀パチンコ風俗でスッキリさせて、そんでまた思いっきり働く。それが男だろ！ってノリだよな。
仕事で懇意になってるパンチャーのお姉ちゃんと裏で仲良くなって、そのまま付き合って…なんてのも普通にアリだろう。
今はもう、あらゆることが複雑になりすぎて、設計だってUMLとER図で対処できるかすら怪しくなっている。
言語だってJavaだけじゃなく、SQLやら、HTMLにCSSにJavaScriptと心得てないと仕事にならない。
そして何より、動かして試して、都度直していかないと分からないことだらけになっている。
プログラマの脳にかかる負荷は昔と比べ物にならない。当然あまりに長時間の労働は事実上不可能。
俺は残業100まで行った所で帯状疱疹が出て、シャワーで腰をさすりながらココらへんが限界と思い知らされた。それが10年前。
勿論今はもっと無理が利かない状況。
でも、残業300可能な時代を、色んな会社で現役として駆け抜け出世した幹部オヤジ達に、今のプログラマが抱えているアレやコレやらは、多分理解できない。
それくらい、時代が変わりすぎたのだろう。見えている世界が違いすぎる。
だから今の若い奴らを根性無しとして完全に見下しているし、本音では「なんだよ急に辞めやがって使えねーなー」とか「アイツ死にやがった、ざまあwww」と思ってる、人でなしの老害ばっかり。
勿論Fortran→C/C++→Javaみたくスキルを身につけてきた人は例外だけど、本当に例外中の例外でめったにいない。
それで「昔のままのノリじゃ、今の開発は絶対に稼げない」ということに思い至らない。
事あるごとにだんまりするパソコンを使い続けている人って本当にすごい。
USB接続はセキュリティ的にどうのこうのって言うけど、多少手間が掛かっても好きなの使わせてよ。買ってくれとはいわないから。
自分は最低でも３つは欲しい。こういう仕事してればウィンドウだらけになるじゃん。
机が広いってだけで効率と気分が良くなる気がする。というかディスプレイが置けない。
後ろを誰かが通るとき、逐一すみませんって通路を開けなくちゃいけないのつらい。
腰がつらい。
アクティベートしないまま使わせるのは百歩譲るとしても、ヤフオクとか怪しいところからマイクロソフトやアドビのライセンス仕入れて使わせるのってどうなんだ。
そういう思考回路の人間は、バレないからとか、まわりもやってるとかいう免罪符を盾に、法律や倫理も破っていいとか考えていそう。特に労働基準法的なやつ。
JetBrainsのIDEを使うのに骨折って交渉するところからはじめたくない。
めんどい。上掲した項目を実現するのに、対費用効果がどうのこうの・・・って。誰が得するんだよ。
ベンダーの資格とか高いけどさ、業務に関係するのなら、資格手当が出ないのなら、せめて合格したときは受験料払ってよ。
一般的な感覚で会社負担の費用を個人負担にさせるような会社は嫌い。好きになれない。
高い意識を持って働いてほしいだとか、会社を好きになってほしいとか、そういうこと全く思っていないのだろうか。
あるいはそれが労働者として当然のことで、自然にそうなるとでも思っているのだろうか。
少なくとも自分は苛立ってると普段より頭の回りがそれなりに悪くなる。
残業だってそう、連日遅くまで残って仕事して、それで効率よく質の良いものを作れるとは到底思えない。
240万にも満たない年収で雇ってるんだから、ちゃんとその程度のゴミを雇ってるって自覚持ってほしい。
お金を貰ってるんだからとか、社会人なんだからとか、そんなん言われただけでやる気になるわけねーだろ。むしろやる気なくなる。
この年収の自分が幾らか熱意を持って仕事したり勉強するのは、あくまで自分の個人的な興味や矜恃の問題だから。
というか発注する客側もそう。然るべき時間と費用があってこその質なのだから、短い時間と割安な費用で納品されるのはゴミだと自覚してほしい。
短い時間と割安な費用でも、企業として質の高い製品を納品するのが当然だと思っているのだろうか。まあゴミが納品されるんですけどね。
そういう会社は等しく今すぐ潰れろ
ほどほどが良い。Slackみたいなコミュニケーションツールがあって、気軽に話せるけど、物理的には近すぎないのがいい。
壁を自由に使えると手軽で良いな。
複雑なものをある側面から、誤解なく簡素に表せる、素晴らしい言語なのになぜ使わないのか。
draw.ioみたいな便利なのがあるのに、Excel方眼紙でアクティビティ図に似て非なる謎の図を書き続けるのはなぜなのか。
画面を動かしてみて、できました、このテストおわりです、それで済ませて質が高くなるわけないだろ。
そもそもjenkinsとかcircle ciとか誰も知らない。seleniumとか聞いたこともない。
前もって仕様が確定することなんてどうせないじゃん。いつまでたっても客側にいいように言われて、しっちゃかめっちゃかされるんでしょ。
なら保守されないExcel方眼紙を量産したって仕方がないじゃん。せめてじゃあその辺は最低限にして動くものを作ろうよ。
だからってアジャイルにしようとは絶対にならないだろうけど。。。そういう参加を客側と交渉すること自体ありえないって思ってそうだし。
でもさあ、とりあえず動くものを早い段階から見てもらうくらい良いじゃん。どうせこそこそやると後になって見たいって言われて叩かれるんだから。
話の論点がズレて、何を話したかったのか、何を聞きたかったのかわからなくなる。そして後から言った言わないになる。
あらかじめ資料を用意しとくなり、どこか広いところに書きながら話そうよ。で、できれば書いた人がデータとしてどこかに投げてほしい。そして消しておいてほしい。
訳のわからない造語を使い出したり、意味を分かってないのにその言葉を不用意に使うの止めてほしい。
きっとそういう人って、まずその言葉の意味を理解しようという意志が致命的に欠けているから、会話していて不毛感が凄い。
短い文章で齟齬なく十全な文章を書けることは確かに素晴らしいことだけど、だいたいそんなことは出来ない。
だから多少冗長であるように思えても、細かすぎるように思えても、長く書いてほしい。
つーか、毎度毎度短い謎の書き残しがあって、それの話を聞きに行くのつらいんだよ。わかってくれ。絶対わかってくれないけど。
読んで意味のわからないことって、読んだつもりにだけなってしまって、後で指摘されると読む側が一方的に悪いことにされたりするのつらい。
正直自分の気づかないところなら好きなだけ寝ていてもいいけど、まあ気づくし。
眠い頭でこういう仕事なんて効率よくできるわけないのに。つまり目障り。
興味ないから。前の会社とか、そこでなにしてたとか。知りたきゃこっちから聞くよ。
＞ ここ５，６年の悩みで最近はっきりわかってきたんだけど、俺いつのころからかどうやって勉強していいのかわからなくなった。
＞ 一番大きいのは結婚して子供できて自由な時間が減ったことなんだろうけど、でもそれ以前から勉強ぜんぜんできなくなったの。
お前は俺かってくらいまったく同じ状況。なので最近ずっと「俺ってもっと優秀な人間じゃなかったか」って思って自己分析してるんだけど、ここ数年で一気にスキルセットが変わったのが大きな原因かなと思ってる。デザインパターン、アスペクト指向、UML、プロジェクト管理手法、積み上げてきたものはたくさんあるけど、今はまったく使えない。若者より知識はものすごくあるけど、意味がなくなった知識ばかりなので実質的な比較をするとほぼ対等。アジャイル、クラウド、機械学習・・・新しく出てきて若い世代が中心的に学んできた技術の存在を考えると、おっさんたちはむしろ若者よりマイナスになってしまったわけ。知識の量は若者より多いのに関わらず。
なので、勉強をするときも「若者よりスタート地点がだいぶ低い」という観点で勉強しないとダメだと言う結論に至った。その方法とは、簡単なコンテンツを、大量の時間をかけて大量に吸収する、ということ。
後、子供はもう致命的な。特に休日今までは合計で16時間くらいは勉強に使えていたのが0時間になる。一ヶ月だと64時間くらい消えてるのね。勉強できないってより勉強してない。となると、前述の「大量の時間をかけて」が無理ゲーなので、すでに詰んではいる。
＞ もう俺は嫁さんと一緒にあと２０年近くかけて子供２人育てなあかんからITが好きか嫌いかで仕事選べる立場じゃねーーーの！
「すでに詰んではいる」と書いたとおりなのだが、これもまったくの真実。「技術ができない人」が「大金を得なければならない」。しかもそれは自分のためではなく、家族という他人のため。その行為は悪ではなく、善。
驚くべきことに結婚して子供ができると「能力の低下」と「収入の増加」を同時に満足させなければならない。そのためにできた制度が、おそらく年功序列であり、管理職なのであろう。そして今はその制度が壊滅しつつある。それでもこの矛盾と戦わなければならないので、結局は能力がなくても若者からお金を奪っていく方法を考えて、どんな手段を使ってもそれを実践していかなければ家族（言い換えると次の世代）を守れない、ということになるだろう。
管理職になる他にも、自分の持ってるレガシーな技術を後輩に強制して、自分のレガシーな知識が有効となる土俵に議論を持っていくという手もある。いずれにしてもろくでもない。
うちの会社、Web系なんだから当然っちゃ当然なんだけど、案件の8割くらいはCMS案件なのよね。
それもWordPressは脆弱性出しすぎとかで保守しにくいってことでもうちょいマイナーなCMSが中心。
プログラマーとして入社してから今まで、デザイナーが渡してきたHTMLファイルをCMSのテンプレートとして構築する、
っていう作業が社会人生活の半分以上を占めていて、業務としてはPHPの簡単なプログラミングすらあんまり経験ない気がする。
CMSのテンプレートもif文とかループとかあるからこれもプログラミングといえばプログラミングなんだけど、
Web系っていうともっとPythonとかNode.jsとかVueみたいなキャピキャピした技術に触れるもんだと思ってたよ。
給料は安いけど割りかし残業も少なくて何かとヌルい会社だから今のところやめるつもりは特にないんだけど、
ディレクターとの調整とかExcel方眼紙で仕様書(多分一般的なSEが作るのよりはかなり簡潔なもの、勿論UMLとかはない)書いたり見積もりしたり操作マニュアル書いたりっていう経験はあっても
下流工程を生きるプログラマーとして例えば5年後10年後、技術的なキャリアとして「HTMLファイルをよくわからんCMSのテンプレートとして当て込むだけのことを長年やってきたおじさん」
が誕生したとして、果たして生きていけるのか心配になってきた。
僕は生きていけるのでしょうか。転職した方がいいんでしょうか。教えてください。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
私はソフトウェア製造業で十年近く働いているが設計書と言えば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以外の素晴らしいツールがあれば教えていただきたい。
どうかよろしくお頼み申し上げ候。
GitHubの謎生物が気になり、せっかくなのでIT界隈の動物(?)を用いた名前やロゴの由来など調べてみた。
※追記あり：Gopherファンに襲われそうなので。ごめんねGopher君
Q.どうしてタコなのに8本足じゃないの？
A.なにも考えずに描いたからね！
もともとデザイナーはoctopussと呼んでいたが、いくら訂正してもGitHubの社員がoctocatと呼ぶため、octocatで落ち着いた。
octocatはあの生物種の名称であり、monalisaという名前は社員の娘が学校の課題で名付けたもの。
種類：ニシキヘビ
名前： -
イギリスのコメディ番組『空飛ぶモンティ・パイソン』より。
またPythonという英単語はニシキヘビを意味するため、マスコットとしてヘビが用いられる。
オライリーの本とかすごい表紙だよね。
種類：ゾウ
種類：ゾウ
名前：slonik
「動物のロゴにしたいなら、象なんてどうだい？アガサ・クリスティの小説にもある『象は忘れない』だ」
― PostgreSQL発足時のメーリスより
種類：ゾウ
名前： -
象は記憶力が非常に優れた動物のため。PostgreSQLと同じで、象の優れた能力にあやかっている。
種類：ヌー
名前： -
種類：キツネ
名前： -
もともとPhoenixという名前だったが、商標権を侵害していたので、公募でFirebirdという名前に決定。
しかし今度はDBに同じ名前があったので、Firefox（レッサーパンダの別名）に改名。
みなさん命名は慎重に。
種類：クジラ
『白鯨（Moby-Dick）』より。クジラを採用した理由はデザイン見れば納得。
種類：ペンギン
名前はタキシード（Tuxedo）を着ているように見えるから。
ロゴコンテストで決定されたが、他の作品を見ればなぜ選ばれたのかよくわかる。デザインって大事。
https://www.cs.earlham.edu/~jeremiah/linux-pix/linux-logo.html
種類：鳥
名前：ラリー・バード
名前はNBAのラリー・バード選手より。社員がファンだったらしい
ちなみに初期のTwitterのデザインはGitHubのデザイナーが手掛けたもの。すごいっすね。
種類：シーサー
名前： -
種類：イルカ
名前：Sakila
種類：ネコ
名前： -
オライリーの本に載ることを考慮して動物をマスコットにしようと考え、「自立した強かさ」を持つという意味でTomcat（雄猫の愛称）を採用。
しかし、猫はオライリーのUML本で使われてしまい、念願のTomcat本にはユキヒョウが使われたという…。
種類：Dogcow（イヌ＋ウシ）
名前：Clarus
昔々、Mac OSで用紙の向きや色を表示するために使用されていたらしい。
知らんわ。
種類：ウサギ
名前：Glenda
OSの名前である「Plan 9～」はエド・ウッドの『Plan 9 from Outer Space』に由来。
ウサギの名前であるGlendaはエド・ウッドの『グレンとグレンダ』に由来。
どんだけエド・ウッド好きなんだよ。
ニュージャージーのWFMUラジオで、Renee Frenchによって宣伝用のTシャツに描かれたのが、彼の初登場。
その後、Bell labsのメールシステムでアバターとして起用もされた。
(ちなみにReneeはBell labsのGlendaを描いた人。Glendaもアバターの一員だった)
そうして2009年、Goプロジェクトが発足し、ロゴを検討していたメンバーにReneeが無償で描いてあげたのが「Go gopher」である。
みんなGo Gopherと呼ぶので、特に固有の名前は無いらしい。
由来は下記サイトにありました。
https://blog.golang.org/gopher
もう50年も60年も経つじゃないか
なぜ未だにCPUの内部構造について知っているのが当たり前という風潮なんだ
なぜ未だにC++が書けるプログラマが本物のプログラマ呼ばわりされているんだ
なぜ未だにCiscoの設定書くだけの資格がもてはやされるんだ
なぜ未だにプログラムを書いているのではなくAPIを叩いているだけだという罵倒が成り立つんだ
なぜ未だにマルチスレッドプログラミングなんて手で書いているんだ
なぜ未だにライブラリが増え続けるんだ
なぜ未だにコンピューターサイエンスなんて学問が必要とされるんdな
もうプログラムを書きたくない
方法論を考えたくない
そんなのを作りたいものを作るだけの人間が考えるのは間違ってる
簡単に良いものが誰にでも出来ることが理想に決まっているだろう
人間なんて働かないほうが良いに決まっている
なぜこんなにも不完全なんだ
なんでまだこんなにも人間の手を煩わせるんだ
早く産業革命が来てくれ
人間に何も考えさせないでくれ
もう休ませてくれ
助けてくれ
今月に入ってからJava（ゆくゆくはAndroid）勉強してる素人なんだけど
http://qiita.com/kenokabe/items/13ea8d2da6adce1b3b9a
http://d.hatena.ne.jp/nowokay/20140718
こういうの読むと、別に理解出来てるわけじゃないものの、じゃ今OOPやる意味ってなんなんだろと思う。
地固めというか、それでも基礎力つけるためにひと通りはやったほうがいいのかな。
デザインパターンはUML書きながら、動作と意味を追いながらとりあえず書経してるけど、
周りに相談できる人もいないので、ここで訊いてみた。
『ゾーン』とは、極度に集中した精神の状態のことです。『フロー状態』とも言います。
極度に集中した状態では、時間の流れが遅くなり、作業は、なめらかに転がるように、よどみなく進んでいきます。
私はプログラマーですが、『ゾーン』に入ってバリバリ書きまくれるときもあれば、躓いてばかりでちっともコーディングが進まない時もあります。
今日は私が実践している『ゾーン』に入るための方法を説明します。
あらかじめ断っておきますが、私がこの方法で『ゾーン』に入れるのは、10回に３回です。
気温の変化、体調の変化、途中で割り込みがないか、前日よく眠れたか、合コンで意中の相手に無視されたか、などなど、
それでも知りたい、という方は続きをお読みください。
人の脳のうち、自覚して使われていない部分を「無意識」の領域と呼びます。
「無意識」には、「意識」下にあるリソースとは比べ物にならないほどの莫大なリソースがあります。
ふだん「無意識」下には、”生活するためのプログラム”、”危機を回避するためのプログラム”などが常駐プログラムとして走っています。
「無意識」の空きリソースを確保するために、それらを一旦終了する必要があります。
まず、作業の前に食事をとってください。食事は胃もたれする脂っこいものや、体内で性質を変えるもの――カフェイン・アルコール、などを避けてください。
そして、作業の途中でお腹が空いた時のために、おやつを用意しておきます。
食べかすが溢れるクッキーなどは避けてください。手が汚れる羊羹などもいけません。できれば手づかみで食べれる、まんじゅうなどがよいでしょう。
包装されているものは、あらかじめ皮をむいておきましょう。
”生活するためのプログラム”に、”必要なタイミングでトイレに立つ”というものがあります。
作業開始の前に用を足しておきましょう。
また食生活を習慣化すると、発動のif条件が時間のチェックだけで十分になるので、ある程度このプログラムの要求するリソースを減らすことができます。
とちゅうで誰かから電話がかかってきたり、メールが来たり、アラームが鳴ったり、上司から呼び出されたりすると、『ゾーン』から強制的に離脱させられます。
携帯の電池を抜いたり、割り込まないように上司を説得しておく、などの対策を取りましょう。
誰かが訪ねて来ないようにするために、できれば作業はブースや自室で行うのが好ましいです。
あなたの脳の実行ループには、"予定されていた行動のために準備する"というタイマーがセットアップされています。
たとえば夜に意中の女の子と初デートの約束があるようなとき、その日の日中に『ゾーン』に入ることはできません。
女の子とのデートを諦める、などすれば確実なのですが、そうもいかない方々も多いでしょう。
私は彼女と話をつけて、デートは彼女の方から誘ってもらうようにしています。
(脱線しますが、一番危険なのは、”予定された致命的な割り込み”です。上司から「ちょっと話があるから、明日の午前、俺のところに来てくれる？」などと言われた時、プログラマーたるあなたの今日は、人生から消え去ります。作業は上の空で、全く手につかないでしょう。)
プログラミングの途中で、APIの仕様を調べたり、バグレポートを分析したり、他部門に問い合わせたりすると、そこで『ゾーン』からはじき出されてしまいます。
APIに習熟するために十分に練習をしておきましょう。
問い合わせが必要なら、それも済ませておきましょう。
分析はあらかじめ済ませておき、プログラミングを残すのみ、としておきましょう。
なお、これは人とプロジェクトによるかと思いますが、クラス設計まで事前にしておく必要はありません。
深い『ゾーン』に入った時は、正しいUMLが頭のなかに勝手に浮かんできます。
以上が事前準備です。すべての項目を念入りにチェックしてください。
一つでもおろそかにしていると、そこがあなたの集中の限界になります。
準備は出来ましたか？それでははじめましょう。
私は音楽に詳しくありませんが、知り合いのすすめでトランス系の音楽を聴くようにしています。
これをヘッドホンで聴きます。iTunesにホットキーを設定して、簡単に音量を落とせるようにしてください。
『ゾーン』使いの中には、作業前に深い瞑想を行って、一気に突入する、という人もいますが、
一気に入ると、うまく入れるときには良いのですが、入れなかった場合、次回に『ゾーン』に入るとき、”すごく面倒くさく”なってしまうのです。
(これはおそらく、精神へのダメージを防ぐための防御プログラムの働き、のようなものだと思いますが、詳しくはわかりません。)
作業に集中できてきたら、次の文句を頭のなかで唱えましょう。
「集中するのを面倒臭がっている自分がいる。一方で、深い集中に入っていく自分がいる」
人は普段、自分がやろうとしていることを”言葉”にして、明示的に考えます。
「無意識」の領域で思考を行うために、”言葉”にするのをやめます。
鉄 ___________ | | 鉄| (磁石) |鉄 | | ---------- 鉄
鉄に囲まれた部屋に、丸い磁石のたまが浮かんでいる、という状態です。
これは登大遊氏が考案したテクニックです。(彼はこのイメージを伴った方法を「論理的思考の放棄」とよんでいました)
磁石は集中がブレると、鉄に引き寄せられてぶれてしまいますが、
このようなイメージを頭のなかに維持し、磁石を真ん中に維持するようにしながら、プログラミングの作業を続けてください。
この方法に慣れるまでには時間がかかりますが、うまくできるようになると、『ゾーン』への突入確率が劇的に上がります。
作業に躓いたり、なんとなく飽きてきた、やる気がなくなってきたら、即座に作業をやめましょう。
「無意識」下でなんらかの常駐プログラムが働いて、思考をだんだん”濁らせて”いるのです。
『ゾーン』に入っているあなたは、このプロセスの進行が手に取るように分かります。
ここで無理に戻そうとすると、「無意識」下の思考のコントロールを失い、次回に『ゾーン』に入りにくくなってしまいます。
潔く諦め、集中をほどいて、作業を終わりにしましょう。
以上です。。
インターフェースとかそんなものをちゃんと設計を考えれば必要ない。複雑にするだけ。
（リファクタリングの必要を説明したところ…）バグでもないのに動いているシステムのソースを書き換える？ふざけるな
（Javaのジェネリクスを見て）なんだこれは、ちょっとわからないから説明して……ふむふむ、わかりにくいから配列にしろ
DBの正規化（DBの使っていないテーブルの洗い出しという意味で使用）
JavaScript?あんな簡易言語なんて使えるのか？
（昨今のStruts脆弱性のニュースを聞き）よし！攻撃をされていないかチェックだ！ここのページ（なんかのニュース）を参考にして調査報告をしてくれ（Strutsは使っておりません）
（昔ながらの静的でApacheのみで動く会社のサイトについて）なんか簡単でいいからさ。資料問い合わせフォームみたいなのを作ってさ、メールが営業に飛ぶようにしてさ、そして問い合わせした会社のデータをためておいて統計みたいなのをだしたいんだけど。
ほんと簡単なものでいいからさ。デザインとかは気にしないからさ。簡単なエクセルみたいなので出せるくらいでいいからさ。一週間くらいでできるかな？
ますだでリリース報告すると、いいことあるかもよと聞いて、やってきました。
あまけんβ- アマゾン商品の検索をいい感じに使えるサービスを開発中。
「あまけん」はアマゾン商品の検索をいい感じにできるサービスを目標に開発しました。
「あまけん」ではアマゾン商品の検索後、レビュー数などによる並び替えや、星の数でのフィルタリング、画像や簡易表示など表示モードの切り替えが可能です。
また検索後の並び替えなどでは、非常に高速に動作するため、商品の比較などに向いていると思います。
ますだ報告デフォルト(?)の、開発の流れや開発環境を簡単に。
検索後、お好みの星の数でフィルタリングした上で、レビュー数や売上ランキング順で並び替えて商品を比較するのがお勧めです。特にレビュー数は本家サイトにない指標なので、おすすめです。
表示モードは情報量と一覧性のバランスのいい”簡易”モードがお勧めです。お好みに合わせて、情報量の多い”詳細”モードや一覧性が高い”画像モードの使い分けも可能です。
アマゾン内で検索する前や後に併用して、あまけんの高速性を活かして、商品比較用にといった活用もおすすめです。
お気に入り登録機能など、様子を見ながら機能追加や改修などのアップデートを行っていきたいと思います。
http://d.hatena.ne.jp/nowokay/20130322#1363969460
以下の記述のまとめ：
お前の言っているソフトウェア工学は今のソフトウェア工学じゃねえよ．
端的に言うとそんだけ．
で，本題．
まず，書いてる内容が古すぎて救いがたい．iPS細胞の研究がノーベル賞取った現状で，「実験材料に受精卵を使う万能細胞の研究なんて許されませんよ！」と主張されても，その何だ，困る，とかそういうの．
1999年、なにがあったかというと、XPエクストリーム・プログラミング入門という本が発行されたのです。リンク先は2版ですが、日本語版でも初版は2000年12月になっています。
で，何？2000年以降ソフトウェア工学が何も進んでないと主張したいの？
って最初に書いてあんのに，そこから崩れて何も出てきてないって主張はどっから出てきたの？自分が知らないことが分かってるのにドヤ顔で提言とか大丈夫か？
しかし、結局統一設計手法は完成せず、UMLだけが残りました。実際に使われているのはその一部です。CORBAも普及せず、WebプロトコルにあわせてSOAPが出てきたものの、結局単純なRESTが定着しました。XMLはいまは毛嫌いされています。大成功したはずのオブジェクト指向も、Webアプリではうまく適用できませんでした。
だから何だ．提案されても使いにくかったり，状況自体が変化したら無用になるに決まってる．まさか「ソフトウェア工学分野で提案された手法はどれだけ開発環境が変わっても生き延びていなければならない」とかいう寝言じみた主張でもしたいのか？言語に流行廃りがあるように，手法にも流行廃りはあるに決まってるだろ．
あとSOAPとXMLに関しては，その衰退過程自体がよくある話すぎて話にならん．一番最初に厳格な重量級の様式が定められて，それをベースに運用レベルを考慮した軽量級の様式が定義されて駆動するってのはよくある話．言い換えると，学術から出てきた理論的に正しい手法が，産業界で必要なところだけつまみ食いされる形で運用されるとか，サンプルは死ぬほどそこらじゅうに転がってねえか？
ああ，CORBAはまあ，うん，そのなんだ．アレはフォローできない．
実際のところ，UMLが残っただけで十分じゃねえの？最初に提案された時の理念さえブレてなければ，つまみ食いしたモノがはやってても提案者的には本望だろ．
今はCMMIだ．CMMは2000年にCMMIに統合されてる．今更XPの本出してくるところといい，真面目に2000年より前で知識止まってんだな．
はぁ？動的型付言語が普及したらなんでソフトウェア工学と離れんのよ？静的型付言語で使えて，動的型付で使えなくなる研究分野なんぞ，完全にソースコードに寄り添った研究だけじゃねえか．
「この手法はC言語を対象としている」って書いてある研究は他の全ての言語には一切適用できないと主張してんのと一緒だ．はじめてのCあたりからやり直せ．
ここで、やはりCMMの失敗がソフトウェア工学にとっての痛手だったように見えます。
もちろん、プロセスを規定することが難しいということは当時からも言われていました。それであるから、CMMはプロセスそのものを規定するのではなく、プロセスの規定方法を規定するというメタプロセスになっていたのです。
そして、すべての組織で同じプロセスを採用することはできないということから、５段階のレベルを設けました。また、プロセスは変化し続けなければいけないということから、CMM成熟度レベル５では「最適化している」という成熟度になっていました。
これはなかなかいいかもしれないということで、期待は大きかったと思います。
でも、とにかく運用が大変だとか、CMM成熟度レベル5でも品質がいいわけじゃないとか、そういう話がきこえてくるようになりました。
まず失敗を定義しろ．で，失敗したってんなら，CMMIで未だに新たな認定がなされてる（http://cmmiinstitute.com/assets/presentations/2012SepCMMI.pdf）理由を説明しろ．
で，運用が大変？当たり前だ．品質確保すんのに運用が楽とかあり得んだろ．従業員に好きにやらせてもアウトプットが高品質ならそもそもCMMIなんぞ必要無い．順序が逆だ．「CMM成熟度レベル5でも品質がいいわけじゃない」ってのも当然だ．アレは組織の成熟度を評価する指標であって，中で働く人間の能力を評価してるわけじゃない．というか流動すんのに評価なんぞできねえけど．
そもそも，CMMIレベル5ってのはおおむね高品質なものが出てくるだけで，人間が関わっている以上ある程度のばらつきは存在する．つーかさー，CMMIレベル5なら必ず高品質のモノが出てくるとか思ってんの？まさかまだ銀の弾丸の存在を信じてんの？「ISO9001に準拠してればリコールなんて発生しない！」と思い込むくらい残念すぎねえか，その思考回路．
ああ，「CMMI」じゃなくて本気で「CMM」の話をしてるんなら申し訳ない．もう無いんだから，CMMの話を最近全く聞かないのは当然で，勘違いしても仕方ない．悪いもしくは古いのはアンタの頭だ．
もともとソフトウェア工学に対しては「がっこーで現場しらない人が研究してる手法なんて使えない」のような声があったのですが、XPやアジャイルによって「現場から生まれた手法のほうが使えるよねー」というのが決定的になりました。
前半は正しい．ソフトウェア工学の最初期からずっとその手の意見はあって，未だに言われてる．が，後半は話にならん．
真面目に聞くんだけど，アジャイルソフトウェア開発宣言に名前が入ってる17人のうち，何人知ってる？何人が開発寄りで，何人が研究寄りか分かる？まさかKent Beck1人を見て「アジャイルは現場から！」とか寝言垂れて無いよな？そもそもKent Beckはコンピュータサイエンスで博士号持ってるし，開発寄りと主張していいのかどうかすら微妙なんだけど．
あとアジャイルも突発的に出てきたわけじゃなくて，プロトタイピングとかあの辺（とそれ以前）からの流れがあると思うんだけどなあ．
ソフトウェア工学が何を失敗しているかというと、その学問自体の認知度が低すぎることです。
ソフトウェア工学がどのような問題を扱う学問かが知られていない。どのような問題を扱う学問か知られていないので、その問題に直面している人がソフトウェア工学の成果を積極的には利用できない。
問題に直面してる人がソフトウェア工学の成果を積極的に利用できないうんぬんについては，最近の国際会議でもその辺を扱った研究が出てきてたりする．ICSE2012のDistingished paperのうちの1本がそんなん．Eclipseの検索ツール使わずに，テキストエディタにコピペしてCtrl+F使ってる人の話とか出てきてた覚えが．
ただ，ソフトウェア工学の認知度なんぞどうでもいいと思うんだけどなあ，別に．そっから出てきたモノが使われさえしてりゃあ．ソフトウェア工学研究の成果が，それと分からずに使われてるんならそれ以上に望むべきモノは無いだろうに．「これがソフトウェア工学様の研究成果でござーい」と大上段に振りかぶって，「ありがたや」の言葉と共に使われることを望んでる研究者なんぞいねえだろ．
就職活動で「半年でプログラムは覚えれるし専門は必要ない」のようなことを言われるという話があります。たしかにアルゴリズムなど実装技術の研究をしていた人をSIの開発現場で生かすのは難しいと思います。でも、ソフトウェア工学の専門知識は、半年で覚えれるものではないし、SIでの開発現場に必要になるはずです。
うん，そうですね．だがそれを学術側を知ろうともしてない人間が言うな．
ソフトウェア開発がある限り、ソフトウェア工学は必要なので、XP・アジャイルを織り込んで再構築して、認知度を高めていってほしいなーと思います。再構築とかは他力本願になってしまうけど。
ソフトウェア工学を再構築しよう，という動きとしては http://semat.org/ あたりがあるのでそっち参照．
あとさー，そもそも論として，ソフトウェア工学の研究内容を「現場」と「学術」に2分することが不可能だって分かってる？工学ってそういうもんだろ？その2分は「工学」と「理学」というレベルでは可能なのであって，既に工学にカテゴライズされてるソフトウェア工学を分けるのは不可能だ．それくらいは語の定義レベルの話なんで，分かっててくれ，頼む．
まあ暇ならトップ会議であるところのICSEのプログラム（https://files.ifi.uzh.ch/icseweb/fileadmin/downloads/ICSE2012_conference_program.pdf）でも眺めてみて，ソフトウェア工学の定義について悩んでみるのもいいかと思います．
実際のところトピックは割と流動的．最近はOSS周りが流行．gitのおかげで開発者の行動とか取りやすくなってる関係もあって．
つまりさー，なんでか知らんけど，この人の頭ん中では「ソフトウェア工学は静的型付言語を利用したウォーターフォール型開発でしか使えない」てことになってんだよな．
あと，なんか無理矢理にでもソフトウェア工学をdisりたくてしょうがないってことは分かった．
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの？
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸？
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
Eclipseがemacsやvimより優れている点を挙げてみよう。
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・上位版にWSADが存在する。
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
などを即座に実現できる。
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。
こんなのシステム開発と言えるのか。
おお、反応をいただけるとは、どうもありがとうございます。
確かに保守的な内容と思われるかもしれないのですが、ここに書いたのは学部３年までの内容ですので、プログラミングをやったことのない生徒もいることを考えると、基礎からやっていったらこういう内容になるのではないか、と思います。
４年以降になると、さらにUMLや、3DCGなど、応用的な分野の実習も入ってきます。
他大学のシラバスも見てみたつもりだったのですが、このような内容の実習を行っている大学は他にもあるのかもしれませんね。筑波大学の授業や、CLUは面白そうだと思いました。
今はほとんどシラバスの内容をネットで見られるので、受験生が授業の内容を調べながら大学を選ぶことができるのですが、一つ一つ調べていくのは大変だと思います。
各大学の売りをみんなで宣伝しあったら、受験生の助けになるんじゃないかな、と思いました。
あと、scheme やっていないの？
残念ながらやってないみたいです。関数型言語については、一応MLを使った演習があるのですが、それほどサポートが手厚いとは言えなそうです。
トラックバックってこういう方法でいいのかな。
はてなに慣れてなくて。
いわれっぱなしも悲しいので、言い訳。
結婚したら幸せな家庭を作るべく、おいしい料理も作ったし、綺麗を維持する努力もしてたし、勉強もしたし、仕事だって個人で月100万稼ぐ月もあったりとがんばっていたよ。
実際、旦那さんの友達に紹介されると、綺麗だの理想だのとほめられて、旦那さんは鼻たかだかだった。
だけど、
って、長文を書いたのだけど、身ばれがこわいので消しました。うん。ネットこわい。
まぁ、いろいろあって、すべてにやる気を無くしだしてました。
好きになる人いるかなぁ。
とりあえず、お肌のお手入れして、すべすべになりました。
マニキュアはやっぱり不評なのね。
資格は今年中にUMLと応用情報と簿記2級を取るつもりなんだけど…
ちょっとロスタイムが多すぎた。せめて1個は取ろう。
朝8時起きは遅いんだけど、旦那さんが深夜2時とか3時とかに帰ってくるから、
目覚めちゃって、ちゃんと夜眠れないんだ。
服は少しずつ買ってます。
髪の毛は黒髪ストレートにすることに決定しました。
ここ1年弱でfortranとかのクソコードを書いた経験以外一切無くてブランクも数年あった状態から、C/C++を使ってオブジェクト指向でそれなりに書けるようになった俺だけど。
一番苦労したのはメモリ空間のイメージを掴むまでだったね。C++で言うと、newしたオブジェクトがメモリ空間上にどう存在してどう振る舞うのか、っていうイメージが湧かなくて最初大変だった。
UMLのシーケンス図で表現される振る舞いを、頭の中に作った仮想的なメモリ空間上でシミュレートする感じか。この辺さえ理解できたらあとは細かいテクニックの話だけな気がする。
http://anond.hatelabo.jp/20081105135432
8月にアサインされたプロジェクトで知り合い、10月から付き合い始めた。
これまで5人くらいと付き合ったことがあるけれど、一般的な女の子と比較して
といった点が目立つ。
見た目は松たか子を少し丸くしたようなかわいらしさがあるのだけれど、要するに中身は男だ。
初めは戸惑いもあったが、案外こういう女の子とつきあうのは楽で楽しいと分かってきた。
いろいろデザインパターン・開発手法・パラダイムなどを試そうとするなど好奇心が強い。
UMLの資格も持っているというのにデータベース系の資格も取ろうと勉強していて向上心の強さがある。
仕様をうまくモデリングできない自分に「おかしいな、普段はこんなはずじゃないのに///」と恥ずかしがる。
問題はどうやって知り合うかだけれど、コーディング(開発)という戦闘モードの時に誘うのではなく、オフタイムが狙い目としか。
初めの一歩が難しいだけで、後は一般的な女の子よりも付き合いは簡単かも。
だって普段男同士でしている会話と同じでいいんだから。
いま、ふとバックアップの「com」って名前のフォルダを見て、javaでwebアプリケーションとか開発してた頃を思い出し胸がキュンってなった。
あの頃comフォルダを開いて一日の業務が始まり、comフォルダを閉じて帰宅の路についた。
comフォルダをみんなで毎日つつき、開発し、comフォルダを納品して報酬をもらっていた。
あの頃はcomフォルダが全てで、comフォルダに一喜一憂し、Eclipsさえあれば一生食うにこまらないやと思っていたな。
誰も読まないUML図。ダンボール一箱分の仕様書。バグ報告すると仕様としてマニュアルに記載される、メーカー様謹製フレームワーク。
あそこにはもう戻ることはないけれど、面白かったな。
みんな元気ですか？SEは欝になってませんか？チームリーダーは残業２００時間こえてませんか？プロジェクトマネージャは３５越えて独身じゃないですか？
最下層のPGはネトゲ嵌って廃人同然で、デスク周りはフィギュアばっかじゃないですか？
また、どっかで飲みましょう。それまで、、生きろ！
