「設計」を含む日記 RSS

はてなキーワード: 設計とは

2016-07-25

ポケモンGOはほんとに(株)ポケ仕事してんのか

今日になってやっとポケモンGOやってみたんですよ、ポケモンGO

ポケモンブランド使わせてるぐらいだから

よっぽど遊びやすGPSゲーになってて「すげぇ……」ってなるのを期待してたのよ。

でもね、期待した俺がバカだったね。

こんなもん、ただのマイナーチェンジIngressですよ。

Ingressポケモン売り渡しただけですよ。

なんかねー、もうとにかく不親切。

Ingressでは「でもそこがクール」で済んだ不親切ぶりだけど、

そこにポケモンの皮かぶせてそのまま打ち出してどうすんの。

もっと口出せよ、(株)ポケ。Nianticに丸投げなんじゃねーのこれ。

思いつくままにポケモンGOのひどいとこを列挙すると、

 

(1)XMに比例してポケモンを出す仕様がクソ

これさ、Ingressの時にはまぁ人口密集地ほどXMあるってのは納得できたのよ。

世界観合致してたから。風水でいう龍穴みたいなもんでしょ?

でもそれをポケモンの出現頻度に重ねるなんておかしくない?

しろ郊外ほどポケモン出るのが正しいあり方なんじゃない?

そりゃさ、むやみに人気のないとこにユーザー誘導しない配慮なのはわかりますよ。

でもXM濃度を何段階かに分けて整理して、

濃いとこは人家まわりにいそうな種類のポケモン

薄いとこは緑地や里山にいそうなちょっとワイルドな種類のポケモン

まったくないとこは危ないかポケモンさない、とかの設定にして、

都市部でも田舎でもプレイ時間あたりのエンカウント率は揃えるように出来なかったのかよ。

イングレスでいうファーム的なとこが近くにないと何もおもしろくない、みたいなのは

ポケモンでやっちゃダメだろ。やる気あんの?

 

(2)「近くにいるポケモン」を狙って動けないのがキツい

これもポケモン密度に関わることだけど、

ちょっと郊外に行って低密度なとこでポケモンを探してると、

近くにいるポケモンを9匹表示してくれても、

それを目掛けて歩きまわるのがほとんど不可能なのよ。

画面を注視して草の飛んでるとこを目指して歩くとか危ないでしょ。

こんな仕様のままじゃ「歩きスマホ助長する設計にはなってない」なんて擁護できんわ。

だいたいがうろうろするよりは直線的に歩いたほうが

タマゴの孵化のためには有利な設計になってるんだから

いっそ位置情報とは別処理で、

歩いた距離に応じてもエンカウントするようにしてくれればいいんだよ。

密集地でたくさん捕れるのはそれはそれで嬉しいから良しとしても、

過疎地でも費やした時間に応じてプレイ体験が出来るようにしとかないと、

わけもわからず歩かされて何も起こらないクソゲーみたいなことに現状なっとるぞ。

ちゃんと色んなとこでテストプレイしたの?

 

(3)車でプレイする奴対策が取られてないのがクソ

すでにもうニュースになってるけどさ、

ポケストップやらを効率よく回るために車で出かけるバカが出るのはわかりきったことだろ。

街中のデカ公園の中でやってる分には車プレイヤーなんて気にならないけどさ、

夜に小一時間近所を回っただけでも何台かポケスト巡回車を見かけたぞ。

場所覚えて巡回してるなら危なくないかもしれんけど、

ポケモンGOじゃなくたってLINEだのなんだの見ながら運転するクソがいるんだからさ、

いちど車でやる習慣ついちまったら他所に行ってマップ見ながらやるに決まっている。

違反事故助長してるイメージがどれだけマイナスになるか考えてなかったの?

せめて画面ONのまま車で移動してるのを検出したら24時間ゲーム出来ないとか、

キツめのペナルティを初めから実装しとかないとダメだろ。

これを実装すると同乗中に起動できないことになるけど、

それで不満が起こるのとながら運転で事故違反が起こるのとどっちが損かちゃんと考えとけよ。

歩いてやるもんだ、ということをもっともっと前面に打ち出せ。

百万単位ユーザー抱えたコンテンツなんだぞ。

まかり間違うと死人が出るようなリスクは念入りに潰しとかないと。

 

とにかく「Ingressポケモンの皮かぶせたらすごいおもしろいよね」までで

思考が止まってる感じがして、良く言えばお人好しですねと言えなくもないけど、

正直ちゃんとテストプレイを重ねてリスクを潰して磨いていった感じが全然しない。

深入りすると危険だけど、浅いとこで遊ぶ分には毒もなく間口が広いのがポケモンの売りだったろ。

Ingress並みの初見殺しアプリのままリリースしてどうすんだよ。

はいえこからいろんな仕組みを足していってポケモンらしさを出していくんだろうけど、

なんかもうほんと頑張ってください。

40何個だか偽アプリが出まわって「ひどいねー」とか同情してたけど、

いまんとこ本物でさえパチもん臭はんぱないです。

(株)ポケ頑張れ。超口出せ。

ポケモンGOの実力はこんなもんじゃないはずだ!

2016-07-22

人体に携帯灰皿をつけない理由

街中喫煙者用の喫煙所だらけになればいいのに



まさか増田さんの書いた喫煙所記事が、ここまで盛り上がらないとは思わなかった。なんで携帯灰皿を持ち歩かないの?というブクマコメントが多かったので、その理由を書いておく。





ということで、喫煙者用に喫煙所や固定灰皿があると便利という話になる。また、灰皿は非常に軽いため、持ち運んでの盗難がしやすい。喫煙所盗難対策用に地球ロックをしてある灰皿が置いてある。



分煙による地域振興というのは各地であって、その一環として喫煙所を設置してあるお店やコンビニの増加がある。喫煙所がある場所地図があったりする。

最寄の喫煙所を探す / 地図検索のスグソコ



ともあれ、ブクマコメントを見ていると、とにかく喫煙者タバコが嫌いという人が多いんだなーと思った。

タグ「喫煙脳の恐怖」を検索 - はてなブックマーク

はてブ(タグ)さんが喫煙者嫌いな人をピックアップ

良いエンジニアの条件ってさ・・・

以下の記事を読んでの考察

https://nanapi.com/ja/122917



上記内の記事でもそうだし、

散々いろんな優秀な方々が言ってることだから

良いエンジニアになるのに一番大事なことって


技術が単純に好きなこと」


なのだろう。。。多分。



そこでふと思ったんだけど

この技術が「好き」という想いには

レベル存在しているのではなかろうか。


自分はまだ駆け出しのPGだが、

以下は自分想像した

アプリケーションエンジニアの「好き」レベルである




Level1】:

ネット本屋で新しい技術を目にすると、ざっと確認してしまう習慣がある。

ありがちな言動:「ふむふむ(ほむほむ)」



Level2】:

Level1に加え、自宅でWebサーバを公開したり、アプリ作成している。

またこのレベルからデザインUI/UXDBセキュリティインフラ技術など、興味関心が多分野へ渡りコミットし始める。

ありがちな言動:「今日アクセスが10増えたぞい。ぐふっ」



Level3】:

Level2に加え、休日はしっかりと時間を確保し、技術習得や、OSSへのコミットを楽しんでいる。

ありがちな言動:「今日×コミット×コンプ♪」



Level4】:

Level3に加え、技術面白すぎて、いろんなアイデアが一日中頭の中に浮かび、

気づいたら毎日手を動かして何らかの実装をしている。

ありがちな言動:「フォオオオオオオオオー」



Level5】:

Level4に加え、FWライブラリソース読破し、茶々を入れることに喜びを覚える。

また実際にコミットも行えるLevelに到達。

ありがちな言動:「これはアカン。。」



Level6】:

Level5に加え、言語設計にまで手を伸ばし始める。

現在第2のMatzになるため、世間から隠れたところで日々ハッピーエンジニアリングに勤しむ。

ありがちな言動:「俺が最高の言語、作っちゃる!!!





↑これあってる?

2016-07-20

人生に、○学を

哲学を知らなければ、

目に見えるものしか見えないじゃないか

哲学を知らなければ、

どうやって存在想像するのだ(アニメか?)」


科学を知らなければ、

目に見えるものしか見えないじゃないか

科学を知らなければ、

どうやって物質想像するのだ(アニメか?)」


工学を知らなければ、

目に見えるものしか作れないじゃないか

工学を知らなければ、

どうやってシステム設計するのだ(アニメか?)」

2016-07-18

http://anond.hatelabo.jp/20160718223650

IT技術学歴は、座学と手先の器用さほど離れてないよ

地頭があるやつは、やる気あればプログラミング設計も身につけられる

IT業界認定試験もっと重要視すべき

IPAのやってるやつだけじゃなくて、ベンダーのやってる言語とかDBとかああいうのも。

PHPプロジェクトPHP認定試験に受かってる奴しか使わないとか、MySQL資格もってないとテーブル設計やらせないしSQLも書かせないみたいな。

認定試験なんて実力とは関係ないって言う人いるけど、SIerではびこってる「経験年数=技術力」って基準より数段マシになると思うわ。

Java入門書も読んだこと無いレベルの人が、コードを書くどころかレビュワーをやっていて、しかも「経験年数=技術力」って世界観から自分は実力あるとナチュラルに信じこんでるし。

VBから来たベテランが「エラーハンドラを全サブルーチンで書くべし」みたいなルールJavaに持ち込んで「全メソッドcatch(Exception e)するべきだろ」とか自信たっぷりに言ってる世界

ダメ技術者が、年をとってるってだけで評価されて上にたってダメ技術者を育成するって負のループに入り込んでるから一定客観的基準評価する仕組みをもちこんで負のループを断ち切るべき。

システム開発法規制すべきだ

全部仕事だった。この3日の間に遅れているスケジュール回復させようと毎日16時間労働だった。

IT屋、SI屋に勤めて10年近くがすぎた。慣れてしまってはいけないのだが、もうあきらめてしまった。職場から見えるビル建築現場は日、月と休みだった。毎日日没後には誰も働いていない。私の仕事とは、会議のない日没後が本番だ。

20万人月案件のひくまでもない。この惨状が常に続いているのは、どこでも発生しているのは、法規制がまったくされていないからだ。不動産屋なら受付に免状がかけられているように、納涼も知識もない人間大勢アサインされている。20万人月というのは、相応の能力を持った人間がよってたかってやっと達成できる作業量なのだが、単純に20万人月あつめれば完成するように思われていないだろうか。オラクル、エムセスレッドハット、シスコ、ほかいろいろ。企業の発行している認定失格ではなくて、法が定めた資格がないのが問題なのだ。座っているから死なないと思われていないだろうか。

一刻も早いシステム開発設計法整備を望んで止まない。

2016-07-17

Excelに苦戦中

いわゆるExcel方眼紙システム設計書を書いているのだが、これがどうにも上手くいかない。

問題は色々あるが、大きく分けて「必要情報が見えにくい」「変化に追従するのが大変」に集約される。


まず「必要情報が見えにくい」について。

そのメソッド記述するのに必要な、他の設計書や仕様書を見つけにくい。

例えば、他の設計書(1ファイルで1クラス)に書かれているメソッド名や引数が合っていなくても、すぐに発見しづらい。

また、入出力情報が書かれたインターフェース仕様書を探しにくいなどなど。

そもそもどうユースケースを読んで、設計必要クラス抽出するかもよくわからないし。


次に「変化に追従するのが大変」について。

上述の状態設計書を書いた結果、製造するプログラマから「こんなんじゃ実装できない」と突っ返されて修正するパターンが多い。

また設計を進めた結果、仕様変更必要事態が度々発生する。

更に要件定義レベルでの見落としによる手直しも、結構な頻度で起きる。

いずれもExcelファイル1個に留まらない、影響範囲の大きい修正になるケースが殆ど

そんなことが相次いで発生した結果、修正対象抽出修正確認作業作業量が膨大化し、全く対応できない。


というわけで、もはや限界ギリギリだったり。

「1個ずつ解決していけばいずれ必ず終わる」を合言葉に、気合努力根性でやってきたけど、なんでこうも先が見えないのか意味がわからない。

どうしたら対応できるのか・・・

論文レビュー

20本ほど読まねばなのだが、最初の4本のクオリティがアレすぎてもう萎えている。

「〜と考える」が延々と続いたのちに「よって○○システム設計した」ってお前なぁ!

(指導教官もよく知ってるので「お前なぁ!」っていいたいけど、single blindだからおおっぴらには言えない)

2016-07-15

http://anond.hatelabo.jp/20160714211518

WEB企業研究開発してるけど、概ね同意

対話システムの分野では、タスク型と非タスク型に分けられる。

タスク型というのは、「テレビ付けて」「テーブルからりんご取って」

とか、指令を出すタイプロボカップとかはこっち。

それ以外の非タスク型は、いわゆるコミュニケーションロボットチャットボットで用いられるような、コミュニケーション自体目的としているもの

前者は、限定されたシチュエーションであれば結構良く出来てきてる。

多少のことばの揺れがあっても、ちゃんと認識してくれる。

ちゃんと使いどころさえ考えれば、ユーザーの期待を超えてサービスとして成功する可能性も高いだろう

だが非タスク型、テメーの出番はまだ先だ。

自然言語処理の現状の研究成果じゃ、それっぽい答えを返すのが関の山だ。

タスク型は、リラックスストレス低減、萌えなどの効果が期待されてるが、現状それっぽいことを返して、使用者勝手意図を推測してもらう使い方しかできない。

りんななんかも、ユーザーJKだと思って想像を膨らませて勝手に話してるだけ。だからこそ、コミュニケーション系でうまくいくには、

キャラクターの背景を綿密に設計

シチュエーション限定

③変な回答しても許して貰える対策

などが必要になってくる。

はっきり言って、これは人工知能の分野ではなく、ギャルゲーアニメドラマなどの経験があったほうがユーザーにいい体験を与えられるものが作れる。そんな段階。

からコミュニケーションできる何かを作りたいんなら、ゲーム開発者でも雇ったほうがいいよ。

http://anond.hatelabo.jp/20160715103235

崩御を前提としないと無理やりに譲位させた後に傀儡政権誕生したりする可能性があるからだろ。ちゃんと設計されてる。角度とか

2016-07-10

dcvb.sytes.netというspamサイト

私はネットウォッチャーとして様々なサイトを漁っている一介の増田である面白いサイトを見つけるためにGoogle alertを利用しているのだが、少し前からGoogle alertを狙うと思われるspamサイトに苦しめられているので紹介したい。

一例を示そう。xyzドメインで、「LIGO 重力波」で検索する。

google:site:.xyz LIGO 重力波

検索結果は以下のURLで示すように、dcrwns.it.xzuvdspcp.xyz というドメインが表示される。

画面キャプチャ: http://www.fastpic.jp/images.php?file=3101744883.png

しかし、このサイトアクセスすると、以下のように http://dcvb.sytes.net/dcrwns.it.xzuvdspcp.xyz魚拓)にリダイレクトされるのだ。

画面キャプチャ: http://www.fastpic.jp/images.php?file=0078597575.png

このサイト、主要なコンテンツYahoo!知恵袋から引用で、「続きを読むクリックすると、以下の質問リンクしている。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10158380025]

まり、この dcvb.sytes.net というサイトは、Yahoo! 知恵袋をパクったspamサイトなのだが、なぜかこのサイト上のページには以下のように検索避けがしてある(タグ文字は全角で表記した)。

<meta name="robots" content="noindex,nofollow" >

すなわち、この dcvb.sytes.net 自体検索ではたどり着くことはできず、必ずリダイレクトによりたどり着くように設計されているのだ。

そして、Googleで表示された dcrwns.it.xzuvdspcp.xyz というサイトだが、単にアクセスするとリダイレクトするだけなので、Googleロボットキーワード収集されるはずがない。

ここから増田の推測だが、リダイレクト用のサイトは、次のように、Google botか否かで表示を変えているのではないか

なんとかしてGoogle botと同じ内容を見てみたいと思い、Googleキャッシュ確認しようにも、キャッシュは表示されない。noarchive設定がされているのだろう。細かいところまでよく考えられている。

リダイレクトに用いられているドメインだが、以下のように非常に多数だ。

これだけで18ドメインある。お名前.comだと一つ99円で大安売りしているので、漏れているものをいれても 2000円位だろう。それだけ費用と手間を掛けても、それを上回る広告収入が入るのだろう。

どうもお手上げだ。誰か助けてくれ。

自民反自民支持率を割り出して、その割合に応じて自民と民進で議席を配分すりゃいいだけだろ。

なんで全員が投票する必要あるん?

日本人女性の平均のおっぱいサイズを調べるために全員のおっぱいを測る必要ないじゃん。

1000人も調べて、平均とればよくね?

そもそも、二院制とか意味あるの?

解散がない参議院議員のほうが国民感情に流された議論になりにくい、専門的な議論を尽くせる、みたいな理由だった気がするけど、参議院議員こそ芸能人とかスポーツ選手とか当選してるから説得力なくね?

現行制度だと、必ず投票に行く組織票ノイズデカいから、せっせ投票率を上げる必要があるんだろうけど、そもそも制度設計に無理があるだろ。

紙に名前書いて人が数えるとか、いま21世紀だぞ?

50個もボタンがあるクソ仕様テレビリモコンをこういう時に活用すりゃいいだろ。

2016-07-08

【追記あり】スマホ設計思想はどう考えても誤っている

数週間前にボーナスで買ったスマホを割ってしまって、どこに怒りをぶつけたらいいのかわからん状態から、ダラダラ愚痴を書くぞ。

日頃ポケットに入れて持ち歩くものなのに、表面は落としたら割れガラスになっているってのはどう考えてもおかしいぞ。

設計した人は落としたらどうなるか、って発想がないのか。余りにも危険予知が出来てなさすぎるぞ。

PSPVITAも大部分は液晶だけど、あれは基本的カバンに入れて持ち運ぶものから問題ない。昔のストレートタイプガラケー基本的ガラスの面が少ないので、落としても割れることはあまりにない。

でもスマホは1面全てガラスからしかも頻繁に持ち歩くものなのに。一応言っておくけど、液晶保護フィルムはいかに衝撃を吸収することを謳っているものガラスフィルムみたいに固いものであっても、気休めにしかならんぞ。ソースは俺と友人と上司の3人だ。コンクリートに落とすくらいなら何とかなるかもしれんけど、砂利とか石とか机の脚とか、力が一点に集中するものに向かって落ちると、あっさり割れる。

京セラのトルクみたいに、フレームが盛り上がってて液晶部分がくぼんでる端末なら、落としても割れ心配は少ないかもしれん。まあそんな設計になってる端末はそうそうないけど。

それどころか最近の端末は、淵の部分を曲面ガラスにして、画面がフレームより上になるというさらなるイヤガラセを仕込んでるからな。このタイプは落とすと液晶部分にダメージが行く可能性は、フラットな端末よりさらに上だ。こんなわけのわからん設計にすんなよ。

デザインのため、と言われればほんの少しは納得するが、デザインのために脆くするのかいかがなものか。割れていない状態iPhoneは非常に美しいが、割れiPhoneが放つ悲壮感があまりにももの悲しい。割れた後、恐ろしく不格好になって嘲笑対象になることをデザインした人は考えなかったのか。

しかもあっさり割れる癖に自分難易度が高いうえに、修理費も高いときたもんだ。だから割れても、そのままな人が多いんだろ。

ともかく、スマホメーカー各社は落としても液晶割れない設計にして頂きたい。

=============================================================================

追記:7/11 1:04

スマホの画面を割った怒りで勢いで書いた愚痴でしたが、想像以上にコメントして頂けたので、補足をしておきます。皆様、色々な意見ありがとうございました。

まず割ったスマホiPhoneではありません。「Black Berry Priv」という端末です。かなり良い値段がするSIMフリー端末なのですが、スライドキーボードが気に入り、奮発して買ったものです。

そして、ちゃんとカバーもしていましたし、フィルムも貼っていました。だからこそ、「何で割れるんだああああっ!!!」と八つ当たりに近い怒り方をしていたわけです。とはいえ、本文中にも書いたとおり、友人や同僚2人もフィルムを付けているのに画面を割っているのを見ているので、本当に気休めにしかならないと今回の件で思ったわけです。ただ、落として割らなかったことの方が多いので、基本的に付けるべきであるとは思います

今回、スマホを割った原因は胸ポケットに入れたスマホが落ちたからです。詳しくは公式サイトなどで「Black Berry Priv」の写真を見てもらえればわかりますが、この端末はふちが曲面になっており、画面がかなり盛り上がった構造をしています。だからカバーをつけてたって、画面の方が位置が高く、落としてしまったときに画面からぶつかり割れちゃったってことです。

トルクを使えばいいというコメントをたくさん頂きましたが、手元に初代(SKT01)と2代目(G01)がすでにあります。実を言うとスマホの画面を割ったのは2回目で(こっちもAndroid。このときはケースを付けていなかった)、以降は反省して、スマホにはケースをつけ、そしてトルクと2台持ちしています。日ごろポケットに入れて使うのはトルクで、それ以外はハイスペック端末という風に住み分けていたんですが、今回は何気なくBlackBerryの方を胸ポケットに入れてしまったばっかりに……。

ちなみに初代トルク画面の周りに金属の枠が埋め込まれているなど、分かりやすく頑丈さを感じる端末ですが、現状では1万円台で買えるスマホスペックがほぼ変わらないので、今使うのは非常にキツイです。タッチパネルの反応も鈍いですし。G01はミドルスペック並みの性能はありますが、初代機と比較すると、ふちが余り高くなくて金属も埋め込まれていないし、なによりSIMピョン問題があり、堅牢性には割りと疑問があるので、あまりお勧めはしません(今のところ、自分の端末では発生していませんが……)。3代目のG02はスペックも外観もG01とあまり変化がないので食指が伸びておらず、まだ購入していません。

あと、GalaxyActiveやTouchPadについては使ったことがないので詳しくは知りません(中古でも余り見かけないので)。

色々と書きましたが、スマホは本当に大事に扱ったほうが良いです。間違っても胸ポケットに入れてはダメ

http://anond.hatelabo.jp/20160708210033

自分エンプラ系とweb系両方経験してるから指摘はまあその通りだなと思う

ある分野の「設計」「レビュー」が別の業界の「設計」「レビュー」が指すものとは

まるで違っているというのはそのとおりだ。

で、思う。

じゃあエンプラ系の技術者の利点って何よ、と。

web系は分かりやすものを短時間で創る、ちょっと間違ったところで怒られない、大事なのはページビューからとにかくタイムリーにさくさく作ることが大事

一方でエンプラ系はちょっとの間違いにすごくナーバスだ、ちょっとの表示間違いで超怒られる、だから間違わないようにテストとかレビューとかきっちり

金も時間も書けないくせにきっちり

作る楽しさまるでないのに厳しくきっちり

鬱になるレベルモラハラできっちり

金にはなるのかもしれんよ、多重請負のトップにいればさ。

けど末端の自分にはただ病むだけの仕事だった。

で、思うのよ。エンプラ系の技術者って何が楽しくってやってんの?

安定?給与

http://anond.hatelabo.jp/20160707235347

お疲れさまです。

設計書の指摘事項および質問事項です。



まず全体的に、インデントおかしいのと「}」が不足しています

プログラム仕様書はいえ「}」や「;」は書く必要がないため、もう少し日本語として通じる文章にしてください。



人間 俺の友達

使われていない変数ですが、問題ありませんか?

下記の

関係 彼女と俺の友達

初期化必要なのでしょうか?



俺 = 彼女いない歴 = 年齢;

俺は、人間型の変数なので、真理値を代入できないのでは?

真理値を人間型にキャストする共通関数があるのでしょうか?



もし(彼女フリー; 彼女彼氏出来るまで; 俺頑張る++){

「もし」ではなく、繰り返しを意味する「諦めない」でしょうか?

また「彼女フリー;」setupメソッドで「なんかモテそう」を代入していますが、フリーで上書きして問題ありませんか? その場合「なんかモテそう」の代入処理は必要なのでしょうか?

変数彼女フォーカス不明のため、このクラス内だけでは考慮できません。

次に「俺頑張る++」は、人間型の変数俺の頑張るプロパティインクリメントするという意味でしょうか?



もしもだ(彼女と俺の友達恋人){

上記のループが回っているときに、このメソッドではない別のメソッドで、変数彼女と俺の友達の値が変更されるため、上記のループの中に条件式があるのでしょうか?

もし、そのためであれば、非同期処理を本当に使う必要があるのか、もう一度設計見直してください。

そのためでないのなら、ループが始まるまえに、条件式を記載してください。




return 今夜も童貞;

voidなので、値を返すことはできません。

updateメソッドの型を指定するべきだと思われます

また、条件式の結果によっては、値を返さないケースがあります

その場合は初期値を返すのか、エラーを投げるのか明記してください。



以上、指摘事項を受けて、修正箇所があれば修正を行い、レビュー結果ドキュメント修正箇所を明記してください。

また、質問箇所については、レビュー結果ドキュメントに回答もセットで記載してください。

文章でわかりにくいところがありましたら、遠慮なく私のところまで聞きにきてください。

明日は午前中は自席にいます、午後から電話会議が散発的にあるため定時後でしたら対応可能です。



確認よろしくお願いします。

2016-07-07

[] 国鉄6200形蒸気機関車

6200形は、1897年明治30年)および1900年明治33年)に、イギリスニールソンネルソン)社

(Neilson & Co., Hyde Park Locomotive Works) で製造され、官設鉄道が輸入したテンダー式蒸気機関車である

他社製の同形機をあわせて1909年明治42年)までに135両が輸入された、明治時代後期を代表する旅客列車用テンダー機関車

一つである。他社製造機も含め、原設計を行なった会社の名を取って「ネルソン」と愛称された。

https://ja.wikipedia.org/wiki/%E5%9B%BD%E9%89%846200%E5%BD%A2%E8%92%B8%E6%B0%97%E6%A9%9F%E9%96%A2%E8%BB%8A

http://anond.hatelabo.jp/20160707183550

設計したんだよ。

それで開発始めるでしょ。

さぁどんどん作ってよ。

イイ感じに出来てきたね。



はい、ここで別の派閥設計担当設計内容を変更してくるわけ。

それで開発始めるでしょ。

さぁどんどん作ってよ。

イイ感じに出来てきたね。



※以後このループ

http://anond.hatelabo.jp/20160707182245

結局なんで「デスマーチ」なの?

設計が揉めてるだけなら開発は案件降りてこないから暇なはずでしょ

「誰が主導権持ってるか」なんてふわっとした解説どや顔でしてんじゃねーよボケ

http://novtan.hatenablog.com/entry/2016/07/06/134448

読んでもらえるかどうかわからないが,一応IDコールしてみる。> id:NOV1975

この記事

  • どうやって育てるか
  • 育てるコストをどうするか
  • 育たない人をどうするか

という点において,「ウォーターフォールアジャイルはどう違うのか」という問題が混然一体となって語られてて,ちょっとわかりにくい気がした。

そこで,この3つの論点について,自分なりの理解アジャイルウォーターフォールの違い(あるいは違わないこと)を書いてみる。

どうやって育てるか

まず,OJTとOffJT(研修勉強会等)の組み合わせで育てる,というレベルの話では,ウォーターフォールアジャイルもあまり違いはない。

また,スキルの広げ方についても,ウォーターフォールアジャイルであまり違いはないと思う。NOV1975氏は,

プログラミングって世界はわりと想像できるんですよね。もうちょっと大きいアーキテクチャの話とか、業務要件の落としこみの部分とかをどういうプロセスで身につけて成長していくんだろうか。

と書いているが,アジャイルでも,最初既存のものの改修から始めてもらって,新機能の追加(ここで要件落としこみが入る),新プロダクトの設計(ここでアーキテクチャの話が入る),みたいに,徐々に範囲を広げていく感じだと思う。

ただアジャイルのチームでは,最初の「既存のものの改修」の段階から運用の稼働を減らすことを意識し,テストデプロイ自動化をしてもらうことになるはず。運用意識する,という点では,運用系の機能追加(例:監視機能の強化)もやってもらうことになる。これをどこに入れるかは悩ましいけど,比較的初期段階で経験することが多いのでは。

手法レベルでは,アジャイルで特徴的なのはOJT手法としてwonodas氏の言うところのレビューやペア・プログラミングを重視している点ではないかと思う。このへんはwwolf氏のあげた「アプレティスシップ・パターン」にもあるのではないかと思うが,職人弟子関係で,日頃の行動の中である種「背中を見せる」感じで(教えるというより)学ばせる感じになると思う。

育てるコストをどうするか

これは(NOV1975自身が書いている通り)ウォーターフォールアジャイルも変わらないと思う。顧客提示する価格の中に教育も含まれることになる。

ここで重要なのはアジャイル場合教育顧客にとっても価値が大きい点だと思う。なぜならアジャイルのチームは,システムを開発するだけでなく,運用も行うのが基本。運用の中で継続的に改造や機能追加を行うことで,顧客にとってのシステム価値を高めていくのがアジャイルの真の意義。そういう活動を続けるために,教育投資することは顧客にとっても価値があるはず。

話はそれるが,ここで少し面白いなと思ったのは,「属人性j」の話。アジャイルのチームでは「属人性」を避ける文化があると思う。だがそれはチーム内の話であって,外から見ると同じチームに開発と運用を依頼することは,チームとしては「替え」がききにくくなる気がする。そのあたりを現状どう解決しているのかはちょっと興味がある。

育たない人をどうするか

これはもう,向いてない人はチームから出て行ってもらうのがお互いのため,というのがアジャイルのやり方だと思う。というかそもそもそういう人をできるだけ入れない。なぜならチームの文化が壊れるから

正直,そういう人でもウォーターフォールだと活きる道がある,というNOV1975氏の考えには納得できないが,なんとか活かしたいという心情は理解できる。なので少し考えてみたけど,人手の作業最後まで残りそうな QA (Quality Assurance) やマニュアル作成あたりに行ってもらうしかないのではないだろうか。個人的には,向いてない人が向いてない業界にいるのは本人のためにもならないとは思うけれど。

2016-07-06

コンピュータ言語言語ごとの特徴を俺が教えてやる(異論は認める

コンピュータ言語って世の中に山ほどあるけれど、それぞれの言語ごとに特徴がある(特徴のない言語は廃れていく)。

まり言語に詳しくない人相手に、俺の考えるそれぞれの言語の特徴を書いてみようと思う。

なお、取り上げるのはある程度広く使われている言語に限りたいと思う。

TL;DR

言語 概要
C言語 高速動作するバイナリ生成を目的としたコンパイル言語。だいたいどんな環境でも使えるがバグやす
C++ マニアック言語、高速、習得大変
Java サーバで高速かつ安定に動作するコンパイル言語、大規模でよく使われる
C# 主にWindowsクライアント用のバイナリ生成に使われるコンパイル言語
Perl 広く使われていたが今は若干時代遅れのスプリクト言語。汚い
Python Perlにかわって主流になりつつあるスクリプト言語。綺麗
PHP Web開発にフォーカスされたスクリプト言語一世を風靡した。
Ruby とても綺麗なスクリプト言語
JavaScript ブラウザで実行出来る唯一の言語言語自体はいまいちだが、ブラウザ事情需要あり
Go サーバサイドで安全かつ高速動作するバイナリ生成を目的としたコンパイル言語

詳細

C言語

メモリに直接アクセスして書き換えるといったコンピュータ機械語に近い言語構文を持つため、高速な処理が可能言語

コンパイラ歴史も古く環境も整っており、組み込み系などを含むほぼ全ての環境で利用可能な万能言語

一方で、メモリの確保や解放といった基本的なことも自前で処理する必要があるため、コーディング効率が良くなく、多種多様バグを生みやすい側面も持つ。

ある程度以上のエンジニアであれば常識として知っておきたい言語だが、初めて覚える言語としてはあまり適当ではない。

C++

C言語オブジェクト指向を導入した言語C++言語とはあまり呼ばれず、しーぷらすぷらす、もしくは略してしーぷらぷら、しーたすたす、などと呼ばれる。

C言語の速度を維持したままオブジェクト指向テンプレートなどの効率的記述可能にしようとした意気は真っ当だったのだが、

当時最先端だった色々な技術思想を叩き込んだおかげで、あり得ないほど複雑化した言語としても有名。

C++理解しています」という人はほぼ初級者で、本当に理解していくほど「C++には自信がありません」となっていく。

速度を追求する分野では良く使われている。完全に理解するのは難しいとしても、テンプレートくらいまでは理解しておくと仕事上なんとかなる…かもしれない。

Java

サーバサイドで安全コードを実行する目的でよく使われる言語。長い歴史を持っており、比較的高速に動作する。

当時は画期的だった「バーチャルマシン」や「ガベージコレクション」という機構を備え、CやC++でよく問題になるメモリ解放忘れというバグを生まず、

サーバサイドなどで何千時間動作するソフトウェアに適した言語として受け入れられた。

必然的エンタープライズ用途で利用されることが多く、各種ツールなども豊富人海戦術がしやす言語という側面も出てきた。

一方でブラウザHello Worldを出すだけでも大変な労力を必要とするので、スタートアップなどではあまり使われない。

ガラケーアプリや(ちょっと違うが)Androidなど、クライアントサイドでも使われることがある。

プログラミング言語最初Javaを覚えるという人は結構多いが、仕事としてJavaを使うのは大抵SI系の業務になり、なかなか辛い労働を強いられる可能性が高い。

C#

クライアントサイドで安全コードを実行する目的でよく使われる言語。こちらも比較的高速に動作する。

元々はWindowsクライアント用の言語であり、Javaとは違ってクライアント向きのAPIが多数ある。

マイクロソフトが開発した言語ということもあり、マイクロソフトの優れた開発環境が利用出来るので開発効率は非常に高い。

Unityなどでも利用可能であるが、基本的にはクライアントの実行形式ファイルを生成する目的が大きく、サーバサイドではあまり使われない。

自作ゲーム開発をしたいのであればうってつけの言語。初めて覚える言語としても十分に良いだろうが、C#を使う仕事は近年無くなりつつある。

Perl

ほぼ全てのLinuxディストリビューションに含まれており、ツールや様々な用途で使われていた。

上に紹介したC、C++JavaC#のようなコンパイル言語とは違い、(少し語弊はあるが)1行ずつ実行してエラーがあれば止まるスクリプト言語である

ちょっと開発してすぐに実行ということが出来るのと、コマンドラインでワンラインコードを読み込ませてちょっとした処理が出来るなど応用範囲の広い言語である

20年近く前にWebCGIが普及した時には、ほぼどのようなサーバ環境でも実行可能だったこともあり、Perlを使うことが極めて多かった。

しかし、主に読みづらい言語仕様のせいで、近年新規ではほとんど使われなくなった。既存コードもどんどん別の言語に置き換えられていることが多い。

日本大手Web企業の一部が使っているので、そこに就職するために覚えるのもアリっちゃアリだけど、今からPerlをわざわざ覚えるのは強くオススメしない。

Python

後発のスプリクト言語。こちらもほぼ全てのLinuxディストリビューションに含まれており、それゆえに広く使われている。

インデントまで言語仕様規定することで、誰が書いても読みやすコードになるように考えられている言語である

Perlの代わりに使われることが増えていて、周辺ツールなども充実しており、小規模から大規模までカバーする勢いがある。

ただ、Python2とPython3のバージョン間での非互換性があまり綺麗に設計されていなかったため、そこで混乱を招いていたこともあった。

最近だとマシンラーニング系のライブラリPythonが使われていたり、海外ではPerlに代わる言語として受け入れられつつある。

最初に覚える言語としては良い選択肢だろう。

PHP

Web開発に特化したスクリプト言語CGIの代わりに使われ始め、一世を風靡した。

以前CGIWebに何かを表示するには比較的大変な労力を割かなければいけなかったのが、PHPを使うと誰でも即座にWeb開発が出来たので爆発的に普及した。

またphp.net豊富ドキュメントスニペットのおかげもあり、開発初期の効率が大変に良い言語である

残念なことに、言語API設計がいけていない点が多く、一部の人から蛇蝎の如く嫌われている。

今でも根強い人気があり、海外でも小規模プロジェクト最初の開発にPHPを選ぶのは比較的よくある選択肢であるようだ。

Webアプリを開発をしたいという明確な目的を持つ人が、最初に学ぶ言語としてPHPを選ぶのは理にかなっていると思う。

なおこの言語を本気でディスってる人は大体視野の狭いエンジニアであることが多いので、地雷エンジニアを見分けるのにも役立つ。

Ruby

綺麗なスクリプト言語日本発で世界的に普及している数少ないIT技術の一つ。

言語仕様が美しく、それゆえにファンが多い。Ruby on RailsというWebフレームワークの登場で、Webアプリでの採用例も一気に増えている。

基本的には他のスクリプト言語と同じくサーバサイドでのプログラミングに用いられることがほとんどである

スクリプト言語で何かを作成するのであれば、Rubyを選んでおけばそう失敗することはない万能言語

サーバサイドで何かすることに興味を持っているならば、最初に覚える言語としてはとてもオススメ出来る。

一方で、なぜかRuby採用するWeb側のフレームワーク(具体的にはprototype.jsCoffeeScriptはいつもクソなので、そちらは深入りしないのが吉。

JavaScript

ブラウザで動くスプリクト言語ブラウザ戦争が勃発していた18年前、奇跡のようなめぐり合わせでベンダー間の合意が取れ実装された言語

言語としてはプロトタイプベースオブジェクト指向という少しめずらしい形式を取っているが、実際にはあまりその特徴は利用されていない。

言語仕様イマイチで、大変バグを生みやす言語であり、また関数スタックが深くなる特性もあり、あまり積極的に使うべき言語ではないが

ブラウザで動く言語現在これしかないので、大きなシェアを持っている。

一部の物好きがサーバサイドでこの言語を使おうと(主にnode.jsで)四苦八苦している(とはいえ、1つの言語Webサーバが完結するのは大きなメリットだ)。

ブラウザで動く唯一の言語のくせにとにかく書くのが面倒ということもあり、多数のAltJSと呼ばれるJavaScriptに変換される別言語を生み出されている。

まあJavaScript本体人が手で書く言語ではない…というのがECMAScript5までの印象だったが、新しい規格が順次導入されており、今後に期待。

Web業界で生きていくならば、好むと好まざるとにかかわらず覚えなければいけない言語である

最初に覚える言語としては、ブラウザ上でゲームなども作れるし、node.jsサーバサイドもできるしで、意外とオススメだったりする。

GO

C、C++Javaと同じでコンパイル言語サーバサイドで高速かつ安定なバイナリを出力することを目的とされ設計されたGoogle発の言語

その目的においてはかなり高性能を誇るので、特に速度を要求されるサーバサイドでのプロジェクトでは導入が進んでいる。

それ以外の目的ではあまりこの言語採用するメリットはないが、ニッチ用途ピンポイントで抑えており、これから広く利用されることも期待される。

コミュニティも活発であり、初めて言語を覚える人が参入すれば喜ばれるだろう。言語としても美しい言語なので、サーバ系のプログラムに興味があればオススメである

まとめ

繰り返しだけれど、それぞれの言語ごとに特徴があり、特徴のない言語は廃れていく。

ここに挙げた言語は何らかの特徴があり、何らかの用途必要なので生き残っている。

その背景を知った上で、ここにある言語は全部ある程度読み書きが出来るようになると素晴らしいと思う。

http://anond.hatelabo.jp/20160705224433

しつこくてすみません。(謝る気ないw)


なんか聞いてるとデータモデルをちゃんと押さえられていない気がします。

根底」にあるモデル(大抵の場合DBにいるやつ)を抑えていれば、それ以外のデータ構造はそれらの変換からできているので、世をしのぶ「仮の姿」ですよね。

根底」にあるやつがどんな風に変装して「仮の姿」になっているのかを調べて頭に入れて、ついでにメモっておけばOKですね。


インターフェース齟齬がでるのは、何が「根底」にある『変わらないやつ』で、何が世をしのぶ「仮の姿」(『いかようにも変わる』)なのか、

『変わらないやつ』からいかようにも変わるやつ』にどんな風に変身(変換)しているのかを整理できていないことが原因のような気がします。。

仮の姿から「別の仮の姿」へ変換するときも、『変わらないやつ』とそいつらがどんな風に変身した関係なのかを抑えてないと、変な設計になるのではないでしょうか?


要するに「仮の姿」と「別の仮の姿」だけで考えてはダメ!だと。

常に「根底」にある『変わらないやつ』を意識しろ!っていうことですね。


上から目線すみません。。


追記:

他人設計した「根底」にある『変わらないやつ』が残念なものだった場合は、なんとも言えないです。。

2016-07-05

仕様書仕様書っていうけど

設計仕事ですからね?

しかも何がどこにある程度の事しか書かれてないっていう

設計ができない、ならわかるけど仕様書が書けないって言わないでしょ

頭の悪い僕はどうやって生きていけばよいのか

僕は頭が悪いのにエンジニアをやってる。

仕事ができないから、残業カバーする毎日ですね。

・要領が悪い

メンタルが弱い

頭が悪い

これが僕の三重苦。

打ち合わせでみんなの会話についていけない。

いつまでも仕様書が書き上げられず、なんども推敲してしまう。

アクションを起こすのが怖くて先延ばしにしがち。

何度もなおそうと励んできたけど、

結局忙しくなってうやむやになってしまう。

こういう生き方は、もうやめたいのだけれど。

追記:

学部卒の10選手

まり褒められた設計の仕方はしてないですね。

自分の中でルール確立されてないのがよくないのでしょう。

図やマトリクスを書いて抜け漏れなくやってるつもりなのですが、

なぜか自分機能けが、他機能との整合性が取れなくなることが多いです。

コメントありがとうございます

もう少し落ち着いてやっていきます

なんではてなってインテリのくせに恋愛ネタ多いの?

恋愛って言うのは性器に基づいた性欲の抽象化であって肉体労働の変形種なのにな。

ギリギリホワイトカラーと認めるとしてもドカタの設計者みたいなもんだぞ?

からインテリフェミニストが多いのは当たり前なのにな。

はてなはなにがしたいんだよ

教えて偉い人