「デザパタ」を含む日記 RSS

はてなキーワード: デザパタとは

2023-10-30

anond:20231030191847

まずC#でどのようなソフトウェアが作られているかを調べてみて、その中に興味を持てる分野があればそれを作るために何が必要か調べてみるといい

教科書読むだけでワクワクして勉強進められるなら、何読んだって良い

実際に動いているソフトウェアソースコード読みたいならgithubを探索してみるといい

構文とかライブラリの使い方はやりたいことによって変わるし、デザパタや〇〇原則みたいなのは個人製作ではどうでもいい

これさえ理解すれば何でも作れるようになれます、みたいな知の高速道路はまだまだ未整備

いろんなことに挑戦して経験を積むしか現状無い

2021-10-04

ある書籍要約系サイトの想い出

ソフトウェア開発における名著とされる読みものがある。かつて、そういった著作エッセンスをひたすら抜き出して黙々とまとめていくはてなダイアリー存在した。2010 年代のことであるGoFデザパタ本とか UNIX 哲学とかピープルウェアとかそういうの。ジュンク堂本棚でいえば「SE 読みもの」というやつだ。業界に入って間もなかった当時の自分は、技術的な相談ができる大人が周囲にいなかった。いま思えば、残業中のオフィスで長いコンパイルを待つあいだ、ぼんやりとこのはてダを読み、目の前のやるせないソースや、所属するチームが置かれた状況について思いを巡らせながら、ガス抜き感覚でこのはてダを読む時間が好きだった。どの項目も歯切れの良い紋切り型文体で読みやすく、読んでいるうちに不安のかたまりがスルスルと解かれていき、気持ちラクになるような気がしたのだった。

その後、わたしアラサーになるころには、そこで紹介されていた大部分の原著書店で購入し物理的に所持するに至っている。あのはてダがなければ、本屋でも仕事関連の棚で足を止める人間にはなっていなかったのではないかと思う。その後、当時のはてダの内容を抜粋したもの秀和システム書籍化され出版される運びになった。ファンだったわたしは発売をとても楽しみにしていた。が、本屋に並んだ書籍を手にとってみると、あのはてダにあった宝物のような輝きはすっかり失われていた。なぜかはわからないけれど、説得力が損なわれている気がしたのだった。書籍化の都合、はてダに貼られていた Amazon へのリンクが取り払われ、原著との接続性がいくぶん薄らいでしまったせいかもしれない。またこ書籍化に伴って、はてダも閉鎖されてしまった。もっと新刊の売上にも関わるだろうし、あの「要約」は原著に対する網羅度がかなり高いもので、権利面ではかなりグレーなものだったように思うから、閉鎖されるのは当然の成り行きだったと言える。が、自分の成長期にあたる年代にあのはてダがあったことは本当にキャリアの上で助けになったと感じているし、原著を所持していてもなおあのはてダを参照したいという思いがあるくらい、とても優れたものだった。他人の「きれいなノート」を借りて勉強していたような感覚というか、そんなような。「新人に読ませたい n 冊の本」というタイトルのクソ記事がもはや春先の業界風物詩になっているが、そんな記事とは段違いにもっと直接的に本が持つ価値を訴えてくるコンテンツだったのだった、少なくともわたしにとっては。

図解界隈というのが流行っていると聞いて、そんなはてダがあったことを思い出した。結局のところ「SE 読みもの」も自己啓発本に他ならないし、個人的DDD

なんて宗教だとすら思う。それにしても「要約」がきっかけで世界が広がるとことは実際あるかもしれないよ、ということが伝えたかった。

2021-02-14

からオブジェクト指向オブジェクト指向プログラミングは全くの別物だろって言ってるだろうが

言ってないけど。

Cから派生したCやJavaなどでやってるのはオブジェクト指向プログラミング

メッセージングメソッド呼び出しで近似して、

クラスというものを作って、「カプセル化」、「継承」、「ポリモーフィズム」を三本の矢にして

いかデザパタマウント取るかを競い合う競技のことだ。

これを提唱しているのはオブジェクト指向プログラミング日本語解説しているWikipediaなので間違いない。

現在日本人に対してオブジェクト指向とは何かと問えばこれのことなので、これさえ押さえておけば会話に問題はない。

なまじっか真のオブジェクト指向精通していると、英語版wikipediaオブジェクト指向を学び、smalltalkなんかかじった日には、現代日本におけるオブジェクト指向いかに偽物かわかるだろうが、奇異にみられるのはあなた自身であることを付け加えておく。

2020-12-25

anond:20201225022330

システムエンジニアだと年収1000万円超えはいるのに。

昔はSE=設計士、PG=大工みたいなイメージ脳裏にあって書いたのかもしれんけど、今はそういう垣根はあまり無いきがする。

エクセルしか使えないSIer技術力のある外注に頼るか、ローコードツール(キントーンとか)使わないと仕事にならないし。そもそもSIerはすごく嫌われるw

あと、PG設計できないてのも古い固定観念

今は設計思想も大抵デザパタに収まるし、フレームワークによっては複合キー認めないのも多いから、ウォーターフォールの上流下流じゃなくてセールスエンジニア要件定義からPGが直接仕様策定するなんてよくある話だよ(アジャイル)。

2020-10-23

anond:20201023144203

デザパタ勉強する程度なら、どんな言語でもよくね?

大昔のアルゴリズム本とか、実在しない疑似言語とかでコードが書いてあったけど。

2019-04-30

anond:20190430140732

そのデザパタ意味メリットデメリット自分なりに理解した上で

使う、使わないを判断できるのであればとても有用だと思う。

特に使わない判断ができるかどうか。

ファイル書き込み中に他システムが読み込んだり書き換えたりする心配が無いケースとか、

実質同じ処理だからといって同一の関数にすると他の誰かがバグ修正して特定フローの時だけ処理を変えたつもりが全フローにおいて処理が変わっちゃうとか

そういうのを見極めるの重要

設計デザイン)とは何かって話

設計というもの必要不要かというのは大変興味深い、と言えばウソだけど。

例の記事で言うところの「クリーンアーキテクチャ」が何なのかわからなかったので調べてみた。

要するにデザパタ一種らしい。(解説が難しくて3秒で深く追及するのをやめた)

デザパタ不要かどうかを議論しているようだ。

俺は老害プログラマだが世の中のデザパタほとんどはクソだと思ってるがそんなことよりも重要なのは

「そのデザパタ、今必要ですか?」

という問いだと思う。

そのデザパタ解決たかった問題と同じものを今の自分が抱えているのか?

単に新しく覚えたスキルを使ってみたくなる病にかかってないか

案外、今直面している問題に使えるデザパタって多くない。

返って複雑になるものばっかり。


そうだ。デザパタ不要とか生易しいものではない。害悪だ。

デザパタは滅びるべし。

2017-12-06

編集者が書く、編集じゃない仕事でも役立った7つの編集スキル

https://adventar.org/calendars/2660

とかやってて乗り遅れた。乗り遅れたので増田に書く。

最初に少し自己紹介をする。新卒出版社、そのあとベンチャー2社を渡り歩いて、いまはわりと大きい会社Web仕事をしている団塊ジュニア出版社時代は概ね雑誌編集で、連載やったり特集やったり。ムック書籍も同時進行でやっていくスタイル。このアドベントカレンダーに参加してるやつらはだいたい友達(そうでない人もいる)。とくに仲が悪いのは……って、そういうことを増田からって書くのはよくない。

以下に書く内容はタイトルの通り、編集を辞めて違う仕事をしても、あー意外と編集者やってたときスキル役立つよなーって話。最初に目次的なものを書くとこうなる。

なんか真面目くさいな。最悪だ。最悪だと思っても書けちゃうのがプロ鼓舞)。

構造化と抽象化

別に言葉は「仕組み化」とか「見える化」「体系化」でもいいんだけど、乱雑にいりみだれてる言葉事象を、いい感じに整理して、まとめなおす作業一式。まとめた結果は図とか短い文章になってコミュニケーション素材として用いる。会議資料になったり、営業ツールになったり、報告書になったりする。

出版社じゃない場所仕事してみると、この「まとめなおす」機能が壊れていることがわりと少なくない。だいたい仕事はなんでもたいへんで、状況はかんたん明快!なんてこともあんまりない。だからといって、いい感じに整理しておきましよ!みたいなこともほとんどない。見てるだけで整理して章立てしたくなる。ラフを書くノリでホワイトボードにポンチ絵書いて、適当キャプションを口で言うだけで「わかりやすい」という反応が得られる。便利。

で、部下や同僚が同じことできないと不便だから教えてみると、抽象化能力とか、抽象化したモノとモノの関連を整理する能力に欠けているとわかる。デザパタみたいにして教えてあげると、すいすいできるようになったりする。まあ地頭はわりと効くけど、どっちかっていうと訓練。取材インタビューのまとめとかした編集者は鬼訓練されてる感じ。あとクソ原稿を直すのも似た作業ですね。量が質を作るジャンル

議論

だいたいどんな会社でも、会議などの社内コミュニケーションで残念なことをいうやつはいる。モチベーション下げる能力がすごい高い人、たぶんユビキタス存在するんだ。これはアレだ、どんないい記事で、売れて、読者の評価高くても、DISってくる人はいるアレ。元編集者的にはそっくり。そういえば売れたこともDISられたこともない編集者さんはがんばろう。

若いうちはなかなか難しかったり、傷ついたりするかもだけど、想定能力と、度胸、切り返し能力あたりが見についてくる。予測力っぽい感じ。これがめっちゃ効く。だいたい知的労働をする会社は、対人コミュニケーションが主たる仕事、かつストレッサになりがちなんで、そこの予測力や度胸、切り返し能力があると、とりあえずバカ扱いはされない。

あいまい定義を、ほどよく確認したり、論理矛盾をいらいらさせないように指摘したりってのは、取材インタビュー、あるいは査読した結果をフィードバックする感じとよく似ている。人格攻撃しないで、コンテンツのもの目線を向けながら品質を上げる行動みたいな。結果議論が進む。これ便利。

なお人格が壊れている編集者は、ここがだいてい壊れてる感じする。そういう人ほど優秀ってのもまたある。人格壊れたまんま、かつて優秀だった、みたいな人もいて、これはしんどい。若くしてこじらせちゃうのと同じくらいしんどい。ぼくにもしんどみがありますメンタルヘルス

マーケティングの基礎

メーカーっぽい会社場合プロダクトアウトが強すぎてマーケ不在ってことはわりとよくある。わりといけてる雑誌屋場合、ここがしっかりしてて、自分仕事がどう部数(=売上)に効くかを体で覚えてて、これがよい。例えば定期購読者増やしたいとか、ECでまったくおんなじ構造の話があるので理解がはやい。

プロの物書きやプロ編集者は「うけてなんぼ」の世界だということをよく知ってるゆえ、勝手に学んじゃうってことだと想像する。いまのWebマーケはいろいろ計測できるけど、impだCVRだCPAだってのは、知ってる概念がなんか別のアメリカ人言葉で言い換えられただけで「うけてなんぼ」を知ってて、自分でやってたって人は、たいてい難しくない。

広告仕事もしてた人だとなおわかりよいかも。Web媒体というか、読者さん課金がない媒体経験だけだと厳しいかもしれない。炎上だけやってる人のうち、インターネットを利用してインターネット価値を下げてるってわかってやってる人ははやくほろんでほしいな。でてくる広告マイナスクリックする技術まだか。

表現が伝わるとき想像力

なんかふつう会社の人をみていると、書くことで精神エネルギーを使い切って、読む人のことまで神経届いてないっぽい人が少なくない(全員だとはいってない)。いや出版社にもそういう残念な人いるけど、割合がだいぶ違う。あと、読む人をわりと簡単にダマさえると信じてる人も多い。ちゃんとした編集者のみなさんはよくご存じの通り、そんなわけない。

プロ編集者は目の前の文章が読者にどう読まれるかの想像力を発揮してる時間が長い。めっちゃ長い。結果訓練されまくって、文章を書く前に脳内読者の文句が想起されたりするまでゲシュタルトが鍛えられる。これがめっちゃ便利。結果として「まとめたもの」の生産性が高い。これに、最初に書いた抽象化能力構造能力が組み合わさると「優秀」って思われやすい。いや訓練の結果なだけなんですけど…。

逆にいうと、そこらへんを売りにしていくとうまくいきやすいってことかも。決められた手順の繰り返しより、乱打戦とかゲリラ戦に向くみたいな売り込み。いやせっかく編集やめるんだったらもう少し落ち着いて仕事したいってのはわかるんだけどもまあ(時代)。

コミュ力交渉

だいぶだるくなってきたので、ここから先は端折ってく。コミュ力とか交渉力はふつうにみんな使うし、編集者ノリのままでわりとOK会社業界によっては謙譲の度合いとか忖度の度合いとか変わってくるけど、まあ大事なところは本音ってのは間違いない。服装や出社時刻は違う。外資はいたことないのでよくわからん。なんだっけ、まあ誠実ならOK。不誠実なやつはすぐに編集者やめてくれ。

雑誌書籍にあった内容で学んだことそのまんま

世の中の人は恐ろしいほど、本も雑誌も読まない。Webも見ない。読み続けることに慣れてない。一方編集職の人は、大食いチャンピオンレベル文字摂取する。結果として知識量は多くて、かつ元ネタとして活用するように脳内におさまってるんで、そのまんま役に立つ。くそ便利。意識まらないようにしつつ大量に読む技術、まじで編集者を支える技術だと思う。なお筆者はいまでも奥付から読むみたいなクセが抜けない。習慣怖い。

お金計算

まあこれは編集じゃなくても仕事してりゃわかるか。てか編集スキルじゃなくね?

おしまい。こういう尻すぼみなスタイルよくないと思いつつも、読み直すとかあんまりしなくなってる元編集者なので初稿ってことで。どうせ編集アドベントカレンダーなんだから、もうちょっといけてる感じにだれか編集してくれたらうれしいかも。元原稿がこれじゃ、だれもやりたくないかw 送り仮名とかたぶんそろってないし。まあ項目5つくらいにして、順番入れかえたいよねふつう

***

編集を離れてもう5年ほどになる。やってたころは「編集はぼくに向いている仕事」って思っていたけど、まあそれ以外でも別に極端に向いてないってことはないなって感じ。たぶん知的活動コミュニケーションがない仕事ってほとんどないってことなんじゃないかなー。

ということで、まだ編集で消耗しているみなさんは、年末進行まっただなかな人も少なくないと思いますが、なによりご健康留意してほしいなと思いつつ、これからもよい仕事をぜひおねがいします。今はいち読者として、いろいろな記事や読み物を楽しみにしていますノシ

2017-05-31

http://anond.hatelabo.jp/20170531174912

この間、調べながら6時間かけて20行程度のコード書いて1000円をゲットした43才無職のオレが通りますよ。

デザパタ、知らなくても、たぶん、Excelマクロだけでも稼ぐ奴や稼ぐんだと思うぜ...。

32歳

プログラミング趣味レベルデザパタとかよくわからない

文才なし

本も大して読んでない

英語も喋れない

常識ない(地名とかさっぱりわからない)

はてブ見てるとみんなすごいなって思う

このまま何のスキル教養もないまま人生終わるんだろうか

2017-05-22

エンジニアプログラマ)として成長するには

プログラマとして超一流になるにはどれくらいの規模の企業が最適かという問題

超一流の定義として、

に加えて

を想定している。

プログラマエンジニア(例えば化学機械系)は設備にも試行錯誤するのにもお金必要だし、

必然的資金力のある順で成長環境が整っているというイメージ

でもプログラマだけに関しては資金力や規模=成長環境というわけではないんじゃないか

自前でサーバーを用意・運用できるだけの資金力があればいいわけだし、100人規模の会社でも事足りる。

データ分析なんかも情報系の学士ならいつでも学びなおせるだろう。

から問題資金力じゃない。

おそらく問題環境だろう。

優秀な奴もただ多ければ多いほどいいというわけでもなく、連絡が取れる人という意味でだ。

10万人規模の会社でも、仕事の中で会う人は多くて50人とかだろう。

さらにそういう超大規模会社セキュリティアウトプット自由度であったり業務多様性であったりが制限される。

これらを加味した結果、SIer候補から外れるので、

候補順として

1.ソフトウェア開発大手大手ってどこ?)

2.電機メーカー技術開発

3.Web大手

4.自動車メーカー技術開発(一部)

といったところか。前半と後半のスキルの重視度合いで2と3が交代しそう

2015-11-06

90年代オブジェクト指向ってオカルトじみてたな

gofデザパタみたいにコーディングのイデオム程度ならいいけど、オブジェクト指向分析とかオブジェクト指向設計とか、あそこまでいくと完全にオカルト

でもいまだにああいうのを、科学的とか工学的だとおもってるオッサンいるし。

2014-04-22

http://anond.hatelabo.jp/20140410183410

すごい今更だけど、1に対してだけ少し。

基本的に、まだ発展途上にあるものほど、理論面が強調されがちなんだと思う。

今の関数型言語は、まだデザインパターンが、色々発案されだしているけど、確立しきっていなかった頃のJavaオブジェクト指向時代、みたいな感じ。

Javaで言うデザパタは、関数型言語では大体、モナドとしてまとめられるわけだけれど、そのモナドを色々発明するために、圏論をしっておくに越したことはない、みたいな感じなんじゃないかと。

もっとも、そろそろすでに出てきているデザパタモナドを利用するだけの、純粋学習者も増え始めている頃合だから、気になりだしては来るタイミングなんだろうけど。

2014-04-03

社会的技術負債をなくすには

社会的技術負債をなくすには

動的言語は使わない。

動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)

動的DBは使わない。リレーションのない動的DBは使わない(mongoDBNoSQL系)

動的オープンを紹介してくるメデイアのステマ気づき騙されない

動的オープン無料育成研修セミナーには行かない

Silerが勧めてくる技術独立できない技術からやらない 関わらない

職務経歴書黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない

マニアックオープンソースは拾ってこない 広めない

Jser Phper Rubistにならない 奢らない

PHP Java JavaScript Ruby RoR Html5仕事は請け負わない

技術負債をなくすには

C# Objctive-cだけ使う

VisualStudio Xcodeだけ使う

VisualStudio Xcode機能をフル活用する

WindowsServerを使う

一定シェアを獲得したDBを使う

デザパタを覚える

コミュニケーションOffice 365 redMine,イラレGit Svnを使う

動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな

セキュリティに問題のある動的言語はどこにいってもトラブルになる

原発システムRuby,RoR,PHP,JavaScriptを使いたいと思うか?Silerはなら提案してくるだろう儲かるから

使えば必ず原発はハックされる

C# ASP.net2007年から海外では大流行だった 一方日本メディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた

C#(静的言語)は14年前のソースが今でも使うことができる。VisualStudioにはソース自動バージョンアップ機能があり書き換えてくれる。 コード負債にならない コンパイルバグがわかる DLLバージョンをチェックしてくれる ブレイクポイント リモートデバッグ

動的言語オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ機能追加のたびに修正することになる リファクタが使えない 負債言語

>14年前のソースが今でも使うことができる

この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか?関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性仕様変更がたくさん埋まっているソースだ 修正には手間と時間予算がかかる

C#なら一瞬で最新の.netフレームワークバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単

PHPを捨てたほういい理由

http://apps.wiki.fc2.com/wiki/PHP%E3%82%92%E6%8D%A8%E3%81%A6%E3%81%9F%E3%81%BB%E3%81%86%E3%81%84%E3%81%84%E7%90%86%E7%94%B1

今はRoRステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更バグ脆弱性は出続け、そのたびに全ソース検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要中間業者は儲かるのでメディア無料育成を通して広めてくる 煽っておいて自己責任の国 日本

静的言語サーバーサイドで何がいいかというと 自分は C# Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方

もうお分かりいただけただろうか?動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語いつまでも高い稼働の保守作業が必要だ。機能追加、言語仕様変更脆弱性修正するのにお金時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。

これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語マスターたからといって独立はできない。なぜなら、5人以上のプログラマーが働いてやっと出来上がるものほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。まさにIT版のねずみ講  上のしか儲からないようになっている。 それに加えて酷いピンハネ。100万で売って7割以上搾取 一人送れば70万円入る世界だ。Silerにとって開発現場炎上すればするだけよい。言語脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人適当教育して3年開発の下駄はかせて送り、現場炎上させて新たに人を送り込んで利益を得ている。

メモ

#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報流出すること結構あるようだ @WikiPHP

#2 2013年 Javaフレームワーク Strutsサポートが終了した こういうフレームワークをメデイアで煽っておいて最後自己責任される。オープン言語はやってはいけない

#3 これはどの業界にも言える事だが、気合い、根性気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーション社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。(○ーイズ、○ルマー、○ニー、旧日本軍ジオン軍タバコ室や残業特定社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる

#5 仕事の最終目的コミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。Office 365RedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ

#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る

#9思えばSiler業界自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率生産性保守作業は社会進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的スキルしか身に付かなかった。それしかやらせてもらえなかった。

しょーもない言語社会の発展を止め、技術者を路頭に迷せた。有益言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたのではないか?

C#ロボット組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。

特にロボットはMocrosoft Robotics StudioというVisualStudioロボット版の開発環境2006年から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界JavaLampが主)

続き

http://apps.wiki.fc2.com/

2014-03-14

社会的技術負債をなくすには

技術負債をなくすには

C# Objctive-cだけ使う

VisualStudio Xcodeだけ使う

VisualStudio Xcode機能をフル活用する

WindowsServerを使う

一定シェアを獲得したDBを使う

デザパタを覚える

コミュニケーションredMine,イラレGit Svnを使う

社会的技術負債をなくすには

動的言語は使わない。

動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)

動的DBは使わない。リレーションのない動的DBは使わない(mongoDBNoSQL系)

動的オープンを紹介してくるメデイアのステマ気づき騙されない

動的オープン無料育成研修セミナーには行かない

Silerが勧めてくる技術独立できない技術からやらない 関わらない

職務経歴書黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない

マニアックオープンソースは拾ってこない 広めない

Jser Phper Rubistにならない 奢らない

PHP Java JavaScript Ruby RoR Html5仕事は請け負わない

動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな

セキュリティに問題のある動的言語はどこにいってもトラブルになる

原発システムRuby,PHP,JavaScriptを使いたいと思うか?Silerはなら提案してくるだろう儲かるから

使えば必ず原発はハックされる

C# ASP.net2007年から海外では大流行だった 一方日本メディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた

C#(静的言語)は14年前のソースが今でも使うことができる。VisualStudioにはソース自動バージョンアップ機能があり書き換えてくれる。 コード負債にならない コンパイルバグがわかる DLLバージョンをチェックしてくれる ブレイクポイント リモートデバッグ

動的言語オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ機能追加のたびに修正することになる リファクタが使えない 負債言語

>14年前のソースが今でも使うことができる

この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか?関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性仕様変更がたくさん埋まっているソースだ 修正には手間と時間予算がかかる

C#なら一瞬で最新の.netフレームワークバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単

&blanklink(PHPを捨てたほういい理由){http://www.slideshare.net/neuecc/c-22979400?v=qf2&b=&from_search=42}

今はRoRステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更バグ脆弱性は出続け、そのたびに全ソース検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要中間業者は儲かるのでメディア無料育成を通して広めてくる 煽っておいて自己責任の国 日本

静的言語サーバーサイドで何がいいかというと 自分は C# Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方

もうお分かりいただけただろうか?動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語いつまでも高い稼働の保守作業が必要だ。機能追加、言語仕様変更脆弱性修正するのにお金時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。

これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語マスターたからといって独立はできない。なぜなら、5人以上のプログラマーが働いてやっと出来上がるものほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。それに加えて酷いピンハネ。100万で売って7割以上搾取 一人送れば70万円入る世界だ。まさにIT版のねずみ講  上のしか儲からないようになっている。Silerにとって開発現場炎上すればするだけよい。言語脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人適当教育して3年開発の下駄はかせて送り、現場炎上させて新たに人を送り込んで利益を得ている。

メモ

#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報流出すること結構あるようだ @WikiPHP

#2 2013年 Javaフレームワーク Strutsサポートが終了した こういうフレームワークをメデイアで煽っておいて最後自己責任される。オープン言語はやってはいけない

#3 これはどの業界にも言える事だが、気合い、根性気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーション社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。(○ーイズ、○ルマー、○ニー、旧日本軍タバコ室や残業特定社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる

#5 仕事の最終目的コミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。 RedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ

#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る

#7思えばSiler業界自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率生産性保守作業をしている間に社会進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的スキルしか身に付かなかったしそれしかやらせてもらえなかった。

しょーもない言語技術者に学ばせて社会の発展を止め、技術者を路頭に迷よわすよりも、有益言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたはずだ

C#ロボット組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。

特にロボットはMocrosoft Robotics StudioというVisualStudioロボット版の開発環境2006年から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界JavaLampが主)

Amazon倉庫ロボット自動システム

http://gigazine.net/news/20121231-kiva-system/

それを開発している会社採用情報 採用言語C++ C# Java

http://www.kivasystems.com/careers-at-kiva/

PHP RoR JS Rubyなんてどこにも書いていない 数年もすれば仕様が変りバグ脆弱性を出す危ない言語だとわかっているのだろう こんな危ない言語は使ってはいけない

Mocrosoft Robotics Studio

http://www.saturn.dti.ne.jp/npaka/robotics/index.html

https://www.microsoft.com/en-us/download/details.aspx?id=29081

続きはWEB

http://goo.gl/2nwGh

2014-02-07

http://anond.hatelabo.jp/20140207144207

なぜそこに行き着いたのか、という経験のほうがよっぽど大事じゃね?

それがあってこその汎用性なんだし。

しろ、その経験無くして、なぜ汎用的なのか分かってるとは到底思えない。

名前云々より、そっちの方が怖いんだけど。

そうね。

まあ原典デザパタ自体は、ガッツリコード載ってるし、現実にありそうな問題を解決する体裁をとってて、いい本だと思うんだよ。

http://anond.hatelabo.jp/20140207135655

それにデザパタなんて普通にプログラミングやってたら使ってるもんだろ。特別勉強するもんでもねーよ。

抽象化って基本わかりづらいから、みんなで俺々抽象化やってると収拾つかなくなるじゃん。(多分そのせいでLisp流行らない)

似たような事やりたい時は、似たような構成にして、共通の名前付けましょうってのは、重要だと思うよ?

コード書けない奴がデザインパターン語るなんて笑止というのは同意するけど。

2011-03-29

典型的PHPerの13の悪癖

PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。

何も知らないかPHPを愛せるんだよ、PHPerは。だからまず、HTMLCSSJavaScriptSQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。

15年間ほどPHPインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故はない。ウェブ仕事をしていれば、PHPJavaで共通する知識も多い。PHPerはJavaを覚えてPHPさよならしろ。そして恥ずかしい悪癖を直すべきだ。

2011-01-15

http://anond.hatelabo.jp/20110115205136

ありがとうございます

パタヘネは(ヘネパタも)読んだことないですね…。

プログラム自体を好きになって、好きを原動力に色々やれるのが一番理想的なんですけどねえ。

原理原則系の本は、SICPを途中まで読んだとか、コードコンプリートとか、アーキテクチャ系だとCODEとかの啓蒙書に近いのを読んだくらいですかね…。

あとオブジェクト指向の本は結構読みましたね。デザパタを暗記するとかは無理ですが、原理的なところはだいぶ理解してると思います。

言語仕様とかと違って、ある程度抽象的なので理解しやすいですね。使う頻度が高いというのもありますが)

他にも細かい勉強は色々齧ってますが(プログラミング言語を作る、という本で再帰下降パーサの辺りまでやったりとか)、いかんせん根本的に興味がないのですぐ忘れますね…。

文字列処理云々も、K&Rとか読んだときに一通り勉強してるはずですが、すぐ忘れます

上っ面だけでなく原理重要というのはある意味その通りだと思いますが、自分にとっては上っ面の細かい仕様とかが一番苦痛なのが辛いところです

結局実務では上っ面が必要ですからね。できればpython辺りで全て済ませたいですが、すぐ処理効率だのなんだのといった面倒な話になりますね。

生きるの辛いです。

いや、えーと、この話に関しては、ガチプログラマの方々がどういう価値観で人を判断するのかとかが良くわかってとても為になってます

ほんと、分散環境で大規模データ処理だの、高速ネットワーク通信だの、ガチプログラマが大活躍のこのご時勢、当分続きそうだと思ってます

時代の流れ、ニーズの変化に応じて柔軟に対応できるのが本当に優秀な人なんだろうと思いますが、自分はなかなか難しいですね…。

多分、「魔法」を連呼してた増田の方が自分より向いてると思います。

2010-03-28

新人プログラマのみなさんへ

そろそろ四月ということで、職業としての「プログラマ」になる方も、はてな界隈では多いでしょうか。なにはともあれおめでとうございます。マの世界へようこそ。私も4月になるので、心機一転頑張りたいなと思い、働いて学んできたことや言われてきたことなどをつらつらと書き出します。

仕事のこと::簡単な目標

仕事ルールはたくさんあります。その中で座右の銘ではありませんが、指針となるような一つ目標があるといいでしょう。私が念頭に置いているのは「三年後に気持ちよく転職できるようにする」ということです。結構移り気が激しいタイプなんですよね。でも人には嫌われたくないという。「気持ちよく」というのがポイントで、会社を「気持ちよく」辞めて転職するのは今までに辞めていった先輩をみていてもなかなか大変そうです。「気持ちよく」辞めるための仕事術を「上司」「同期」「後輩」「自分」という点であげてみました。大切なのは「気持ちよく転職できるようにする」ために周りの人を気遣いそれを示すことで「あいつはよく頑張ってくれた」「次も頑張ってもらいたい」「また一緒に仕事をしたいな」と思ってもらい惜しまれつつ転職できるようにすることです。

仕事のこと::上司・同期

進捗報告 タスク/終了予定日/発生している障害 を上司等に送りましょう

あなたの上司仕事全体の進捗の管理メンバーの割り振りを考えます。そのために各人に割り振った仕事の進み具合や仕事量に無理がないかを把握する必要があります。あなたはそれを考えて、自分が行っているタスクの状態をきちんと上司に報告しましょう。現状に無理があるようなら、その状態と代替策を上司に相談しましょう。

何か質問する時や意見をする時は自分なりに答えをもって質問しましょう

大抵の人は忙しいのと、別の問題で頭を使っているため、きっとあなたが頭を悩ませて質問したいと思っている、その特定の問題について、あなたほど深く考えていないでしょう。そんな時にただ質問も投げられても、相手も一から考えてしまうので、お互いに負荷が高くなってしまいます。それで相手のことを考えて、技術的な質問や方針などの相談の際には質問の後に「こうしてみようと思う」「この点が問題なのでこうすれば解決するはず」など、それなりに自分の答えをもって、質問や意見をすべきです。そうすれば相手もそれをベース自分意見経験を考えながら伝えることが出来るため、あなたの質問に答えることがそれほど重荷ではなくなります。

笑顔で働く

楽しく笑顔で働きましょう。笑う門には福来るではないですが、多くの人は笑顔に惹き付けられるものです。また上司も基本、自分の舵取りでメンバーが楽しく仕事出来ていると思いたいものです。それに応えましょう。

仕事のこと::同期・後輩

「引き継いだ人のために」会社ルールに沿ったプロダクト作りをする

会社には多くの場合コーディングルールドキュメント規則があります。「こうしたほうが早いのになあ」とか「こんなのクールじゃない」とか考えることもあるでしょうが、ルールに従いましょう。3年後に後輩に「ここはクールじゃなかったらこうした」と説明するのは大変ですし、きっと3年もたてば、その「クール」も変わっているはずです。もしどう考えても効率が悪いようなら会社ルール自体の改善を訴えましょう。

「引き継いだ人のために」ドキュメントをのこしておく

上と矛盾するようですが、急ぎ仕事(こればかりやる会社もある)をやる場合は、ドキュメント不要ということもあります。そんな場合でも最低限の仕様等のドキュメントの記録を残しておきましょう。引き継ぐ後輩に口頭で伝えるのは手間というより、忘れている部分も増え、伝言ゲーム状態になります。これは、人日を割当られていないのにやるわけですから、ちょっと大変ですが、意識しておきましょう。

「引き継いだ人のために」仕事の進め方を記録しておく

自分がどう考えて、どう上司とやり取りをしていたかを簡単な記録でいいので毎日つけましょう。将来の後輩が見た時にきっとそれが、励ましや何かのヒントになるはずです。

仕事のこと::自分

失敗を恐れない

自分についてはこのひとつだけ。失敗をしないのは仕事をしない人だけです。三年後にはどうせ転職するのですから、失敗をおそれずルールを守りながらも常に新しい何かを探して創りだしていきましょう。そうすれば転職の際に自分はこういう挑戦をしてきたという自信が出来ますし、以前の会社で思い切れば未練なく辞めることが出来ます。

失敗は怖いですが、それを少し減らす方法として「失敗を想定する」プログラマ的に言えば「例外処理」を考えておくというのがあります。人はわからないものは怖いですが、失敗した、間違いを犯した場合はこうすればいい、最悪こうなるということがわかっていれば、その恐怖は減るものです。そしてその「例外処理」を書きおわったなら、明日のことを考えて、思い悩むのは辞めて、その日、その日の仕事を頑張りましょう。

勉強のこと

仕事の進め方について書いてみましたが、冒頭でも述べたように、プログラマは一サラリーマンである以上に一職人です。プログラムについての勉強を常にしましょう。勉強会社をやめても人を裏切りません。プログラム言語についてはもちろんですが、それだけではありません。仕事をしているとついつい忘れがちになりますが、基本的なデータ構造アルゴリズムデータベースの仕組みやネットワークの仕組み等の計算機科学を知っておくことが大切です。またプログラムの組み方については、デザパタエンタープライズアーキテクスチャパターンなどを知っておくと仕事をすすめやすいでしょう。

私のおすすめは「勉強会駆動勉強」です。何か勉強したいな、身につけたいなあと思うことがあったら、それをテーマに近くのコミュニティ勉強会の発表申し込みをします。人に教えようとすると自分のものにしなければいけませんから必死に勉強します。するとその知識が身に付くのはもちろんこと、その分野について詳しい人と周りに思ってもらえるかもしれず、また第一人者からアドバイスを受けることもできます。なかなかの一石三鳥です。

勉強のことについて、最初と逆になりますが私たちは一職人ですが一サラリーマンです。ハッカーといえど、社会人としての基本的な知識である英語数学経済学をおさえておきましょう。経済学感覚とは違う部分で社会が動いていることがわかり、おもしろいです。私のおすすめは「スティグリッツ入門経済学」ですね。また習慣として毎日のニュース日経)や週ペースの経済雑誌東洋経済等)を読んで、基本的な現代経済をおさえておきましょう。自分仕事社会の目から客観的におさえることが出来ます。

生活のこと

最後に。仕事のことや勉強のことをたくさん書いてきました。しかし、仕事最適化しても人生はおもしろくありません。運動を適度にし、自分趣味を見つけて興味を持ち(私はアニメラノベ読み)、いろいろなことを学んで、楽しみながら人生を過ごしましょう。

2010-01-29

http://anond.hatelabo.jp/20100129110646

デザパタ的な仮想コードプログラム設計部分の99%くらいは説明出来ちゃう

いや、それは。

【どんな言語だろうが、「挨拶」はある。】と言うようなものでさ。

中国語でする「挨拶」はなに?】を解決しないだろう。

まぁ、プログラミング能力は、言語能力よりも設計能力の方が重要だという主張なら、一理あるが。

2009-08-07

http://anond.hatelabo.jp/20090807172637

これマジ?

俺、未経験(もちろん非情報系専攻)で業界に入ってプログラミングやることになって1年くらい経つ。

その間の学習の軌跡はだいたいこんなもん。

  • とりあえずK&Rを読まされてCをなんとなく学習。すぐにC++コード書くことになる。C++柴田ボウヨウかなんかの本を読む。
  • メモリ空間イメージがつかめなくて苦しむ。参照と実体の区別がつかなくてオブジェクトをうまく扱えない。
  • メモリ空間イメージを理解した。ここまでくると大体感覚がわかってくる。OOPとかすんなり理解できるようになる(もちろんギークレベルでは決して無い)。
  • デザパタ系の本をあらためて読むと意味がよくわかるようになっている。継承とかよくないよね。できるだけ集約を使って権限と責任を委譲した方がいいよね、みたいな感じ。
  • Template Methodとか正直名前を覚えてられないんだけど、今ググったら普通に使ってる手法だった。ていうか普通に考えてそういう設計になるよね、みたいな。(いまここ)


実際にはコード書く以外の仕事してる期間も結構ある(半分くらい)。設計考えたりとかアルゴリズム考えたりとか。

でも俺、ギークとかなんとかみたいな変態プログラマの人たちには全く追いつける気がしないし、わかんないことだらけで俺センスねーなーと思うことしきり。本当に。

「珠玉のプログラミング」っていう本があるけど、あれみたいにビットレベルコンピュータ原理を最大限活用してパフォーマンスの高いコードを書く、みたいな考え方がさっぱり身につかない。

でもこのエントリ見ると、俺もちょっとは自身もっていいんじゃね?って気がしたわけだ。

でもやっぱりそんなことは無いのかな。

ちなみにデザパタ関連およびOOP関連では『デザインパターンとともに学ぶオブジェクト指向こころ』っていう本がマジオススメ感動的にわかりやすい。

 
ログイン ユーザー登録
ようこそ ゲスト さん