「カバレッジ」を含む日記 RSS

はてなキーワード: カバレッジとは

2018-04-26

データサイエンティストが働いて嫌だったなと思う人たち

コンサルにてアナリストをやった後、データサイエンティストを名乗りながら仕事をしています。そんな中で嫌だったなと思った人たちとプロジェクト

1.医療統計の周りの人

最近アウトカムでの評価の流れにはなってきたが、まだまだモデル評価をする事は少ない。

でも何故か相変わらずロジステックとCox回帰をやれればおっけーであり、モデルの精度が当たらなくてもオッズ比と説明変数

有意差だけでていれば上手く行く分野。 本当に心が痛む上、まだまだ「医者でなければ人であらず」が通ってしまい、モデル説明よりもお医者様のお言葉が1stにきてしまう。また分析プロジェクト

設計らしい設計があまり出来ないのもつらいところ(モデルの精度が出ていないのにそのオッズ比・有意差に何の意味があるんだと思う)。後日本の製薬企業から「何とか工夫で有意差がでないのか!!」

という謎おしかりを受ける・・・いやそんなん無理ですやんと切実に思う。やる気でこの世界数字は変わりません。

後は何だかんだ製薬企業日本の古いしきたりが多いので面倒。

2.Google Analyticsアナリスト関連

割と良いBIみたいなんが良くも悪くもあるためアナリストの人たちがやった気になっているやつ。Web関係アナリストは、アナリストを名乗って欲しくない人の方が多いイメージ(勿論しっかりWebアナリストやっている方々は知っている)。広告内容を分類し、CV予測、そしてマルチチャネル予算からCV最適化案件をしていたらWebアナリストから「私の作るLPは最適です。なので予算4000万です」という謎の最適の主張を受けたのはいい思い出(何故かデザイナー様がWebアナリストもやっていた)。広告内容のuser2vecでのレコメンド実装チャレンジして評価して、協調フィルタリングよりも精度はよさげだな喜んでいたら、どっかのよくわからないレコメンドツールというのが汎用性もあるし、既存ツールに1万ぐらい払えば追加できるとそして何故か「最適化」されているという言葉役員が騙されて決済がおりていたのを聞いたとき殺意が沸いた。どうせ既存マーケティングオートメーションレコメンドエンジンなんて協調フィルタリング・ロジぐらいだろうと思っている。本気で分析やっている人がそうそ最適化なんて言葉を使わないと思うんだ・・・まぁここの反省Web業界といってもみんなコーディングがりがりではなくてGUIでいいならそれでが割と多いという事を学んだ (注意)。

3.データベース関連

どっかの人のにもあったが、「あっ、データ分析分かるんだよね?」という事でVB6Accessの改修をやらされそうになったときは全力で拒否った。

後は何故かPHP+MySQLあん(ry

VB6見た後でPythonコードを見ると心が癒された。

4.やる気を説いて来る人達

やる気で数字が変わったら誰も苦労なんてしないんだよ・・・。半教師有り等で精度向上見込めるといってもいくらなんでもこのデータでは

運用目標には到達しないとしか思えないんだ。

5.ホワイトボックステスト要求されたとき

モデルホワイトボックステストってどうやってやるんだ?精度を検証データでやっていれば良いじゃないかと思っていた。ただそこの金融系でITプロジェクトは、基本的に「ホワイトボックステスト」やらが必須らしく・・・おいおい・・。とりあえずカテゴリー目的変数がそれぞれの値を取ることを客先で見せてかつレポートで「こうこうこうゆうときカテゴリー変数が変わりますよ」という彼らがいう境界線確認を全てやることになった。カバレッジ100%も言われたが、流石に無さ過ぎるので諦めてもらった。

6.KGIとKPIしっかり切り分けてBI作成していたら集計屋かといって来られる時

どこかの人にもあったが、私はビジネスが動けばよいと思っているので難しい分析をしなくても上手く行く時は、集計で上手く切り分けて、要因分析をやる(裏で決定木とかで境界値とかは見ていたりする)。ただ何故かそれで集計ばかりしかしていないと怒られる。別に研究者ではないし、難しい分析をしてクライアントへの説明時間を取られたり、展開が難しくなるぐらいならば皆と合意した上で、KPIとKGIを切り分けてダッシュボード作成をしっかり出来る方が実はビジネス上上手く行くだ。むしろ自分への戒めでいつも難しい分析が本当に必要なのかと思ってるぐらいである。

注意 因みに私の別部署インフラ基盤周りのWordpress関係炎上していた。そこそこの大規模でWordpress使うって大変らしいのに・・・

勿論これの逆、評価した上で、分析ビジネスにしっかりと生かしていける人は大好きです。

2018-04-24

母集団

https://anond.hatelabo.jp/20180424082940

母集団」について 増田で盛り上がることがあろうとは!

とうれしくなってしまったので、解説しておく。

事例に出てきた選挙の話で考えてみると、新聞社大手マスコミが行っている電話での世論調査は下記のように整理できる。

RDD調査の例

A.日本有権者全体=母集団目標母集団

B.RDDで補足できる電話番号全体=枠母集団

C.実際に調査対象となった電話番号全体=対象

D.答えてくれた電話番号=回答数。

ここでサンプリング理論関係してくるのは、Cを適切な数集めたらBが推定できるよね、って話。

人口が何千万人もいるのに2000人対象調査するだけでいいのはどうして?っていうのはBとCの関係

AとBの差(カバレッジ誤差)は統計学では埋められない。

じゃ、ネット世論調査はどうか?っていうと、

ネット会社パネルに依頼するよ、派

A.日本有権者全体=母集団目標母集団

B.ネット調査会社パネル=枠母集団

C.調査依頼を送った数=対象

D.答えてくれた数=回答数

バナーとかで回答者募集するよ、派

A.日本有権者全体=母集団目標母集団

B.バナー掲載されている当該サイトアクセスする可能性がある人=枠母集団

C.バナー掲載されている時間に当該サイトアクセスした人=対象

D.答えてくれた数=回答数

カバレッジ誤差

で、世論調査がどうのこうのっていっているのは、

上記の枠母集団目標母集団関係

AとBがどう考えても同質じゃないから、あたらないよね、ってこと。

目標母集団と枠母集団の違い、具体例を挙げて説明しているのって あまり ないけど、下記の文科省学校関係調査説明なんかはイメージやすいと思う。

http://www.mext.go.jp/b_menu/toukei/chousa01/kyouin/sonota/1400767.htm

じゃぁ電話番号だったらいいのかよ、っていう指摘は出ると思うが、ごもっとも。

下記、NHK小野寺さんの文章をご一読を。

https://www.nhk.or.jp/bunken/research/yoron/pdf/20170130_3.pdf

2018-02-25

コードレビュー不要論

こんだけ守れてるなら他の指摘事項なんて、開発者ごとの微細なスタイル押し付けいであって、品質据え置きで開発スピード下げるだけだろ。

2018-01-09

そもそも無料ダウンロードコストゼロでもないしね

ダウンロードしたらそれだけHDDの容量を使うわけでそこにお金がかかるし、

ブラウザで読むにしたって"ギガが減る"状態の人もいる。

漫画村ってのは行ったことがないので知らないけど、以前調べたところでは

ダウンロード実用的なレベルで行うにはロダプレミアムアカウント必要で、

そこには月1,2千円程度の、正規の読み放題サービス程度のお金もかかった(作品カバレッジが違ったけど)。

明らかに、多少のコストなら払ってもいいという人が多いということなので、

今後、正規著作権者はそこをくまなく攫う方法を真面目に考える必要が出てくるだろうね。

https://anond.hatelabo.jp/20180109001953

2017-12-01

anond:20171201134753

人の心がない奴に当たったら高度な人工知能だと思ってルールを厳格に適用するのがいいと思う。厳格かつ抽象的かつカバレッジの広い規則を作って運用するってのもキチガイじゃない人には難しいのかもしれないけど。

ごめん、そのルールってのがイマイチからなかったんだけど、

厳格かつ抽象的、カバレッジの広いって

具体的に例えて言うとどんな感じになる?

anond:20171201130711

多分そうなんだろう。で、俺自身はともかくとして、サイコパスとかソシオパスとかアスペとか、そういう人の心がない奴に当たったら高度な人工知能だと思ってルールを厳格に適用するのがいいと思う。厳格かつ抽象的かつカバレッジの広い規則を作って運用するってのもキチガイじゃない人には難しいのかもしれないけど。

2016-12-12

はいくらでも無理な要求をしてよい

客にコスト構造なんてわかるはずがないか

普通のことだと思うのだけれど、おそらく日本の皆さまが歪んでいるのは「売り手は客の要求を断る権利がある」の部分で。無理してきいちゃう。だから「作り手のことを考えて要求を抑えるべし」とか噴飯物の「常識」が幅を利かせるのだが、それこそ無理な話だということを認識しろ。同じような無理な要求として「安いものは悪いと認識スべし」というものもある。

だがしかし、私は言いたい。素人部外者に、コスト構造など正確に把握できる訳がない。現代社会はお前の頭と違ってとかく複雑なのだよ。

あんなにお金のかかっているように見えるテレビ番組googleマイクロソフトオフィスみたいなwebサービスchromelinuxのようなソフトウェアやすごいグラフィック音声つきのソシャゲなどが、無料提供されているのだ。お前のしょぼいソレがその値段とか、へそが茶を沸かすわ とお客様は思っている。同じ業界のものでさえ、他社のコストについて「どうしてその値段でやっていけるのか?」と首を傾げることもある。

そもそもなぜ安いかを隠していることも多い。だからってミミズを原料に使っている的な客にとって不都合な真実ばかりではない。そのようなコストメリットを出すことこそが、業界で優位にやっていける企業秘密であり強みであり、言うなればすべての企業が持っているべき秘密で、つまりあらゆる物の値段の詳細な原価は隠されているのだ。ましてや他業界素人部外者などにわかるわけがない。

例えば、コストを抑える技術として「原料を安くて悪いもの仕入れる」の他に「海外人件費の安い国から仕入れる」とか「原料の安い国から仕入れる」とか「特殊輸送方法仕入れる(冷凍技術ができたので船で輸送できるようになったとか)」とか「スーパー職人(あるいは秘密ロボット)が1日に普通の千倍作るので給料10倍にしても余裕」とか、いくらでも未知の技術革新は想定しうる。その他にも、フリーミアム的な無料低価格戦略、早期にシェアを取りたいか期間限定で、でもソレを言わず低価格販売されるものもある(そして回収期を逃し他事業利益を突っ込んで補填されたり、シェアが取れて薄利多売で利益回収できたりするもの=客は丸儲けパターンも多い)。それを顧客判断しろなんて言うのは、無理だ。

同様に「高いならいいものか?」という問題もある。ただのボッタクリ値上げじゃないという判断が、どうしてできるのか?有名料亭でさえ産地偽装するこんな世の中で。お前が「お客様のために最高級の原料を」と思ったソレが、そもそも業者ぼったくりの結果の値段じゃないと、どうして断言できるのか? 冷凍だとこの味は出ない? 冷凍技術革新的発明がなかったとどうして言える? いやそんな悪意あるぼったくりじゃなくても、無駄に包装に手間がかかってるとか、有名タレントCM出演料がとか、プロしか気づかない僅かな風味の差とか、自動テストカバレッジ100%とか、客が実は「そんな価値、そこまでのこだわりは必要ない」と思ってる部分のコストが高いだけの場合もある。

他の要求も同じだ。

例えば「24時間窓口開けろ」とか「もっとキレイしろ」とか、それが「無理な要求」「労働者の首を絞める」につながるのか?いや、つなげる経営者もいるだろうが、それは「お前の職場ブラックから」なのであって、早々にやめるか経営者をすげ替えるべきだろう。それはお前の雇用者問題経営戦略問題であって、客の要求が「取り除くべき直接の原因」ではない。

24時間対応しろ」が無理な場合、正しい回答は「それでは利益が出ないのでできません」や「それならこの値段になります」とかだ。もちろんライバル社がやりだして客が取られることもあるだろう。それに文句をいうのは売り手・作り手としての矜持にかけるんじゃないかね。それがライバル社のブラック労働の結果なら、労基に相談だ(こういう敵対的提訴が増えるといいですね)

だいたい客に行儀良さを求めても、行儀の悪い客は出てくる。そうなると損するのは行儀の良い客だけ。そもそも、素人部外者のお前の判断する「コスト度外視のひどい要求」が、実は店側にとっては「採算の取れるかんたんな要求」かもしれないだろ?もしかすると利益の増える方向の要求かもしれない。客は売り手のすべてを知っているわけじゃないのだ。

客は無理を言えばいい。売り手は、それが無理なら、単に断ればよいだけ。戦うべきは客の要求ブラック労働につなげる職場であって、無理を言う客の存在ではない。

2016-11-19

チーム開発が分からん

チームで開発って分からんね。

とあるWebサービス会社プログラマとしてに勤めて約1年。社会人3年目(といっても途中でブランク半年

個人的感想だが正直プロダクトのコードはひどい。

コピペコードもいっぱい。というか、現在進行形。「コピペしてちょっと直せばできるよね」なんてのをよく聞く。

手続き的でどうしてもロジックの重複もひどい。ifとswitchの嵐。

テストエクセル仕様書カバレッジ観点?何それみたいな空気

・動いてるところには触らない。

一方俺個人

DRY大好き。コピペなんてありえないでしょう(最近ちょっと緩まった)

オブジェクト指向大好き。if文?switch?多態で減らせない?

テスト?(何らかの意味で)網羅率意識は当然でしょJK

リファクタガンガンしてコード量を減らすべき。

とかまぁ独学が多いせいか原理原則みたいのに凝り固まってしまってると思う。

正直言って自分はチームとあってないと思う。コーディングスタイルだったり、開発速度だったり。それは申し訳ない。

プログラミングスタイルは嫌いだけど人としてとても好きな先輩は「合わせるのって大事だよね」っていう。

それは分かる。全体としての一貫性プログラムでとても重要なことだと思う。

その人は仕事も早いし、チーム最古参仕様歴史的経緯もよく把握してる。

でもさ、そんなプログラミング繰り返しても薄っぺらコードが積み重なるだけじゃん。

コード減らそうよ。コピペなんて恥ずかしくないのかと問いたい。

仕事遅くなってもちゃんと網羅率を意識したテスト仕様書書こうよ。

それができないのはコードのテスタビリティが低いからでしょ?

と思って、俺は毛色の違うコードを混ぜちゃう。それがプログラムとして正しいと思うし、ほかのスタイルで書けない。

迷惑なんだろうなと思うし未熟だと思う。

でも俺はプログラマとしてあんコード耐えられないし、やってはいけないと思う。

本来はチームに提案して、全体として方針を決めてそれに合わせるべきなんだろう。

俺が良いと思うからその方法で書く!なんてのは単なる我満だと思う。

彼はプログラマとしてダメだと思う。でもビジネスマンやチームでの開発者として正しいと思う。

なんだか納得できない。かと言って俺自身については今の仕事のやり方で良いと思わない。

からない

2016-06-20

http://anond.hatelabo.jp/20160619234906

カバレッジ定義が違うんでしょうね。

通過行のカバレッジ100%(≒分岐網羅)だとして、それでOKとしているとすれば、「テストを甘く見ている」と言うのはごもっともかと思います

2015-08-22

SEことば

SEの私の言葉意味

追記歓迎

言葉意味
議事録気が変わる前の意見
非機能要件実装するかは気分次第
確認しておきます今日は帰ります
オブジェクト指向オ○ニー
偉い人の意見パルプンテ
ちょっとした仕様変更ザキ
客先担当者の急な交代ザラキ
要件定義から見直しザラキーマ
確定した仕様幻想
WBSSはサグラダファミリア
キーマン鬱病になりにくいことがわかってる人
ベストプラクティスモジュール化されてません
増員導入教育で作業が止まる
それは新しい方法ですね問題がおきたらお前が対応しろ
操作手順書唯一多少参考になる設計ドキュメント
備考最も重要考慮事項
XXはリスク問題が起きる(起きてる)けど俺は知りません
試験エビデンス誰も見ないけど一番手間のかかるもの
ペアコーディング今日だるいから流すわ
すべての入力パターンを網羅したテスト1ケース0.1秒で実行しても宇宙が終わるほうが早い
フレームワークバグ仕様です
カバレッジ100%不具合だらけですがコンパイルエラーはありません
トレードオフこの仕事やるのと休日出勤どっちがいい?
動きます完成度10%
一部のエラー処理がまだ完成度20%
誰かの独自フレームワークお前はしぬ
会社独自フレームワークみんなしぬ

2015-04-12

将棋の件を受けて

開発者のかっこ悪さやルール範囲内(今回は修正不可ルールいまいちだったっぽいけど、それを決めたのは対戦相手じゃない)で戦ったプロ棋士への敬意のなさはおいておいて。

IBMスルガ銀行訴訟マイクロソフトの月次パッチに対する反応の時も少し思ったけど、はてなTwitter界隈の流れを見る感じプログラムシステム完璧さへの信仰、それをエンジニアに当然の如く要求する思いが渦巻いているようで純粋に怖い。

将棋なんか局面10の220乗あり得る(らしい)ので、将棋を適切に行う機能に対するカバレッジ100%検証実施せよと言われたらそれをするしかないわけだが当たり前だが出来るわけがない。

工数システム投資は絞られるのに責任けが増大している気がどうしてもする。初版から潜在不良なしのパーフェクトを求められる環境だとすると我々はどうすれば/どのような心持でいればいいんだ?組み込みなんかそれに近いわけだし教えてほしい。

2014-11-29

http://anond.hatelabo.jp/20141129112709

新米マネージャ管理する小規模プロジェクトにおいて発生する諸問題とその対策について

マネージャを多少悪者気味に書いていますが、マネジメントの大変さはわかっているつもりです。

自分が開発すればこのくらいでできる」問題

上司「この間言ってたプロジェクト見積もりできた?」

マネージャ「たぶん2週間ぐらいでできますよ!wordpressなら学生のころバイトとかでもよくインストールしてたから楽勝です!」

デザイナ「完全オリジナルwordpressデザイン2週間か、なんとかなるかな?」

プログラマPHP経験なんだけど大丈夫かなあ…」

.... 略 ....

上司「あれから2週間だけど、こんなにバグ多すぎじゃリリース無理じゃない?」

マネージャ「違うんですよ!デザイナー全然テンプレートの使い方覚えてくれないし、あのプログラマPHPからないとか言って仕事中にPHPの本とか読んでるから遅れたんです!たぶん自分だけだったらこんなに時間かなりませんよ。」

デザイナ(「XHTMLになってない!」とか余計な所に口突っ込んできやがって!)

プログラマ(PHPなんて簡単だよとか言ってJavaプロジェクトからコンバートさせたのテメーだろうが!)

原因

対策


テストは開発工数に含まれないよね?」問題

マネージャ「このスケジュールなんだけど、テスト期間長過ぎじゃない?」

プログラマ「え、でも機能もこれだけあります10日程度は妥当かと」

マネージャ「いやいや、画面たったこれだけじゃない、通しのテストなんてみんなでやれば1日ぐらいで終わるでしょ?」

プログラマバグがあったらどうするんですか?」

マネージャ「俺がレビューしてるんだからそんなでかいバグ出るわけねえだろ。ナメてんのか」

.... 略 ....

プログラマテストバグこれだけ見つけました」

マネージャ「へー、それじゃこれ今日のうちに修正してね」

プログラマセキュリティ周りのバグもあるので、修正には3日程かかると思いますが」

マネージャ「ふざけんな!テスト今日で終わるスケジュールだろ!」

原因

対策


バージョン管理効率悪くなるからダメ問題

プログラマ「前のプロジェクトgitを使って便利だったので、今回のプロジェクトでも使いたいのですが…」

マネージャバージョン管理とか使ってるの?あんなの効率悪くなるからやめたほうが良いよ」

デザイナ「私もそういうの面倒だからあんまり使いたくないな」

マネージャ「前に俺がやってたプロジェクトではフォルダで日付ごとに管理してた。同じ風にすれば大丈夫だろ」

プログラマ「でもロールバックが…」

マネージャ「古いフォルダからファイルコピーすればいいだけだろ。馬鹿か」

.... 略 ....

マネージャ「なんで古いソース持ってきても動かないんだよ!」

デザイナ(間違ってファイル上書きしたのは黙っておこう)

プログラマローカルgitリポジトリあるのは黙っておこう)

原因

対策


フレームワークバグがあったらどうするんだ!」問題

マネージャ「何このCodeIgniterっていうの?」

プログラマ「あ、それ最近流行ってるPHPフレームワークで、URLルーティングが…」

マネージャ「はぁ!?フレームワークとか使わないと開発できないわけ?これだから最近ゆとりダメなんだよ。」

プログラマ「でも、便利ですよ?」

マネージャ「俺のプロジェクトではそういう怪しいやつは使わないからバグがあったらお前責任取れるの?」

.... 略 ....

マネージャ「どう、俺の書いたURLルーティングライブラリすごく便利じゃない?」

プログラマ大文字を使うとうまく動かないのですが」

マネージャ「あー、それは仕様からしょうがないよ。mod_rewrite使えば問題無いでしょ?」

プログラマ他人が再発明した車輪バグ修正するのって本当に不毛だな…)

原因

対策

2014-03-03

http://anond.hatelabo.jp/20140303174315

横だけど、オバマケアって失点なのか?

確かにhealthcare.govのトラブルは大きく取り上げられたが、あれってオバマケアのほんの一部だぞ? あのサイト使わなきゃ保険に入れないわけじゃないし。

うちはピーク時$1000/月越えてた保険料カバレッジ増えたうえに$700/月以下になったので、オバマケア様々なんだが。

2013-12-27

カバレッジ厨は消えろ

テストコードカバレッジ100%とか何バカなこと言ってんの?

お前がカバレッジ100%だと思ってるそのテスト全然スカスカですから

カバレッジ厨がTDDBDDだ、UnitTestRSpecだと騒いだところでバグは一向に無くなりませんから!!!!!

2013-11-10

http://anond.hatelabo.jp/20131109185658

組み込み系の仕事をしている二年目です。

毎日仕事ができなくて凹んでます元増田の2年目が羨ましいです。

研究室では解析アプリケーションを作るのにC,C++,Fortranをいじってました

また趣味サーバの立ち上げやWeb系のJavascriptPHP,Pythonなどもいじっていました。

なんである程度どっちもわかります

で、そんな自分組み込み系の仕事に入ったわけなのですが、

まったく違う。組み込みWebアプリケーション文化が違ったわけです。

ここからはあくまで私の体験ですが…

まず、組み込み系はハード接続図)を読めないと話になりませんでした。

CPUFLASHSRAMFPGACPLDアナログ回路、バッファ、それらをつなぐバス、電源、接点、コネクタスロット、A/D、D/Aなどなど、

これらがどうつながってるか意識しなくてはいけません。SoCとか行っても接続図読めないと意味ありません。

この段階でプリント板の単体検証もしてもらいます

広い話、プリント設計組み込み系の仕事なんですよね。

次に、FPGACPLD設計があります言語VerilogVHDLです。XilinxAltera、Actel等のデバイスに書き込みます

PLDって言うのは言語で書けるハードです。似ているようでCPUと違うので設計にはスキル必要です。

この段階でシミュレーション(modelsim等)をしてもらいます

ここも立派な組み込み系の仕事です。

次にCPUです。言語はC,アセンブラC++です。でもほとんどがCです。デバイスルネサスSHとかです。自分はここで見習いをしてます

CPUに直接入ってくる信号(接点・バス等)もありますが、前述のFPGACPLDから入ってくる信号のほうが多いです。

で、アプリケーションWeb系と何が違うかといえば、ものすごい短期間にいろんなことが起こります

リアルタイム処理っていうのでしょうか。割り込みとか聞いたことありませんか。

要はOSがないので自分でなんでも考えなきゃいけないわけです。

CPU検証はMISRA-Cや専用のカバレッジテストツールで行います

一般的組み込み系の仕事と言われるとここを指すと思います


実際にはユーザーインタフェース設計組み込みに入ります

接点の調整とかLCDパネルとかメンテナンスのツールだとかがないと装置に指令を出せません。

これらにもCPUが入っているわけなので別にコードを書く必要があります組み込み系の仕事です。

さらPLCってのもあります

これは言語でかけるリレー回路です。リレーってのはスイッチです。

スイッチ操作することで接続されている機械操作(電源の入り切りとか)します。

これもCPU,PLD等とは全く違う方式(ラダー)で書きます。十分組み込み仕事です。

最後に組み合わせ評価・試験です。

ユニット試験では通っても、組み合わせ試験で動かないというのは100%あると思います

試験仕事じゃないと思われるでしょうが自分はここも立派な組み込み系の仕事だと思ってます

この段階で確認がとれた後、装置に渡せるようになります

などなど一言組み込み系の仕事といってもいろいろあるわけです。

上の中の2つ3つを仕事に使えるレベルまで持って行くには10年、20年はかかると言われました。

ここで表題の件なのですが、元増田の人は経験8年なので、例えばFPGAを8年やってきてCを書けと言われても大変だと思います

特にその後にWeb系の仕事(これも一言で表すにはいろいろジャンルがあると思いますが)をされてきたとのことなので

いろいろとあったのだと思います。逆にずーとやっていた分野のことを任せるといいかもしれません。

まずどんなことをやってきたのか聞いてみたほうがいいと思います

2013-10-23

http://anond.hatelabo.jp/20131023215018

無い。C言語(++含む)の開発能力で開発競争をしていては、開発が間に合わない。

どう考えてもサービス記述用の言語必要になる。

その言語を介して、おそらくLLVMを通してネイティブへのダイレクトコンパイルになると思われるからOSの壁はわりと超えやすい。

その関係上、OSに要求される機能RTOS程度の機能になるだろうが、RTOSその物は余程の性能でない限りLinuxでもユーザーランドドライバで解決可能。

それに、よく要求されれる機能Linuxパッチ当てても可能。

 

結果論として、OSその物の高機能化勝負にはならない。勝負になるのはOSエミュレーターというか開発環境

より開発しやす環境を整えたほうが勝つ。正確には、自動車が要求する水準までのサービスの開発とテスト高速化して支える技術カバレッジとかね。

OSその物は限られた天才が作るだろうが、その天才の質は日米共に大差は付かない。もしくは買ってきても構わない。

問題は、その下に必要な大量の普通プログラマーと、そのプログラマーが作ったもの天才が書いたものと遜色ない品質まで持ち上げるシステム

 

要するに、日本刀ではなく、火炎放射器マシンガンのように普通兵隊をどこまで強化できるか?という競争になる。

ただしまぁそれは、今の自動車メーカーが考えているようなものではないから、そこの開発装置競争Googleにボロ負けするだろ。

 

SDKを作ろうとしているメーカーは沢山あるが、作れるメーカー殆ど無い。

2013-09-23

さすらい

とあるプロジェクトフロントエンジニアとして手伝っていて、2500行程度のそびえ立つクソなJavaScriptの改修を頼まれていた。

git blame しただけで最低でも10人このJSファイルコードを追加していることがわかった。最初コミット2010年2月ごろだから最初からいるエンジニアの人に話を聞いてみたらこのJS20人近い人がいじっているらしい。

別に関わっている人数とかはどうでもいいんだけど、変数名が謎すぎたり、関数名前と中身の挙動が合っていなかったり、まぁひどいコードで、それを半月ぐらいかけて、個人的な安心感を高めるためにも最初はheadless testとかcapybaraでテストをもりもり書いて、カバレッジを高めて(期間的に100%にはできなかったけど、C0で70%ぐらい)からリファクタリングしていたら最終的にCoofeeScriptに変換して700行ぐらい(JS1000行ぐらいかな)になる予定(追加開発があればまだ増えるかも)。消えた部分は使われていない関数とか無駄な処理とかコメントだったかな。

だいたいなんでこんなことになったかっていうと、経営者がアホな要求ばっかり今までドキュメントを用意していなかったりするからそびえ立つクソコードが生まれたという感じ。CoofeeScriptにしたのもある程度書式を固定したかたから。

同時にGithubPRベースの開発も導入した。俺が入った時には他に3人のフロントエンジニアがいてその人達コードを見ながらもやってた。その人たちはあんまりプログラマとしての能力が高くなかったのでPRベースJSの基礎なんかを教えながらやってた。プロジェクトに入ってからは俺はずっとテスト環境を整備していて、今いるプロジェクトメンバーはまだテストをかける状態じゃないから、PR送られてきたらそのブランチに対してテストを追加したコミットをぶん投げるという感じで進めていた。

もちろん、PRからJenkins連携してテストを走らせるようにしたらフロントエンドチーム、3人ともかなり安心感をもって開発をすることができましたとさ。俺はこのプロジェクトとは今月末でさよならから、俺の仕事ドキュメント書いたりレビューをする文化根付かせて終わりって感じかなー。

あと、JSテストとかViewテストの仕方3年前にくらべるとだいぶ情報が増えてきたし、フロントエンジニア〜な人達テストに身を委ねてみるといいと思った。

あー楽しかった。この世のクソ(ただし金は生んでる)コードをまたひとつ潰せた。

2013-08-06

あなたドコモ経営陣だったとします (※追記あり)

事業環境は厳しいです。ドル箱だったiモードの栄華も今は昔、「ただの土管になりたくない」という強い意志も、いまや具体的戦略のないただの願望になってしまいました。通信インフラコモディティ化していて他キャリアとの差別化はできなくなったどころか、LTEカバレッジでは最も出遅れている始末。他キャリアへの流出が止まらなくなり、キャンペーン甲斐なく何度も純減を繰り返しています。もはや減収減益の構造が定着しつつあるといっていいでしょう。

そこでiPhone導入が取り沙汰されるわけです。

確かに、まだiPhone人気が十分に高い日本では、短期的にはiPhone販売がMNP流出防止&純減ストップの切り札になることはわかっています。それでもiPhone販売に踏み切れない一番の理由は、これまで株主総会でも日経記事でも繰り返し観測気球を出してきたとおり、Appleが課す高い販売シェアノルマ---一説には50%---がドコモ負担になると予測されるからです。

でも、「販売ノルマ率を切り下げてくれればウチも採用しまから、そこは何とかお願いしますよ」というドコモからの数年越しのメッセージに、Appleは反応しませんでした。確かに中国インドアフリカといった途上国の巨大市場に比べれば、ドコモたかだか6000万契約極東のいちメガキャリアしかありません。最後発のドコモに対して契約条件を緩和したら、当然ソフトバンクau最恵国待遇を要求するでしょう。Appleからすれば、各社に販売ノルマを緩和したらトータルではツーペイになってしまうし、利益率を緩和したら、まだiPhoneが高い競争力を持っている地域市場を自らスポイルすることになってしまますAppleドコモ妥協してやる意味は今のところないのです。

からドコモにはもう後がなくなってしまいました。とにかくiPhoneの販売ノルマクリアできる体制を整え、iPhone販売契約に踏み切るのが喫緊課題です。そのためはどうすればいいか? iPhone豊富選択肢のなかのワンオブゼムにしてはだめですよね。実際に数を捌かなければ、Appleが課すペナルティで今度は営業利益率がガタ落ちしまから。となれば、今は1シーズンに10機種も出しているAndroidスマートフォンの投入ラインナップをせいぜい3〜4機種程度に絞り、それらとは別格の位置づけでiPhoneを売りまくらなければいけなくなりますソフトバンクKDDIは実際そうしています)。「業績回復のためにやれるべきことは全部やっている」と株主に説明するためのステップとして、これはもう必須の条件でしょう。

さて、では実際にラインナップのどこを整理して、誰にiPhoneを売ってゆくのか。ドコモ既存ユーザーのうち、特に重視すべき移行見込層は、1)フィーチャーフォンユーザーと、2)Androidに乗り替えたものの、その機能操作性に不満があるユーザー…ということになるでしょう。1)はかつてブランドだった「ドコモのN」や「ドコモのP」などを長年ご愛顧戴いてきた層。2)は、Android機種のなかでも差別化に失敗しているコモディティ的端末、すなわち、N・P・F・SHのユーザー。これらのユーザーを「わかりやすいですよ」「使いやすいですよ」とiPhoneに誘導してゆくためには、これらのセカンドラインメーカーが作るスマートフォンは、むしろ選択肢から消えていてくれたほうがいいですよね。

こうして事前にキャリア内の浮遊層を作っておき、適切なタイミングiPhone移行キャンペーンを投下すれば、そこは衰えたりとはい国内最大の契約者数を誇るキャリアドコモですから、その数字的なインパクトはかなり大きいはずです。


から今回話題になった「ツートップ戦略」は、巷間言われているように、スター機種のXperiaGalaxyを重点的に売り込むための、攻めの施策というだけではありません。それは、来たるべきiPhone時代を見据え、長年ドコモ蜜月関係にあったメーカーたちと縁切りすることを意図した、非情身辺整理の作業でもあります。今般報道されているNECカシオパナソニックモバイルスマートフォン撤退は、ドコモの販売奨励戦略の「失敗」ではなく、はじめからの狙い通りの「成功」だったというわけです。



【追記】山本一郎さんのコメントへの御礼

ネット世界では投資家ゲーム開発者ラノベ作家企業探偵ベルロックメディアシニアマネージャーなどの華麗な経歴で知られる山本一郎さんという人に拙文へのリンク貼っていただけたようで、恐縮至極、汗顔の至りです。

【悲報】ドコモ関連で「いかにも」な与太記事が増田に掲載され局地的に話題に(山本 一郎) - 個人 - Yahoo!ニュース

空手形や取らぬ狸皮の動機でNECを真っ二つにするとはちょっと思いづらいんですよね。


はい、もし上の文章からそんな経緯を想像する人がいたら、企業経営には向いていないでしょうね。山本一郎さんがドコモ経営陣だったとしても、当然、Appleと今期以降のiPhone販売契約について話の筋道をつけてからの「ツートップ戦略」で年末大水計に打って出るのではないでしょうか? 見込みベースで話を進めて裏目に出たら、ツートップ転じてオンリーツー状態になってしまますのでね。もしここまでの話がすべて机上の空論なら、それはすなわち、「ドコモは次の機種サイクルから事実上ソニーサムスンだけでスマートフォン市場を闘い続けることを選んだ」という話になるわけです。

しかし、本邦のモバイル業界フラッグキャリア格ともいえるドコモが、たった2メーカー×1〜2機種の最新スマートフォンラインナップで次の秋冬商戦に挑むなんてことがあるでしょうか? この会社は今年に入ってからの一連の動きのなかで、どんなコストを払い、何を仕込んでいるのでしょうか? 山本さんが並べているリンクの数々も、ツートップ戦略が「単体では」純増の切り札として奏効しなかったことを示していますが、それは本当は「切り札」ではなく、さらなる戦略転換のためのひとつの手段だったのではないでしょうか? 予定では2013年中に市場投入され、サムスンとの密な提携関係ならびにモバイルOS第三極戦略の礎となるはずだったTizen派筆頭の永田氏をいきなり傍流に追いやってしまったことには、果たしてどんな意味があるのでしょうか? 

さまざまな状況証拠から考えて、今のドコモがその機種戦略プラットフォーム戦略の中に、何か大きなパズルピースがはまるための「スペース」を作っていることを全否定できる人はそういないのではないでしょうか。そして、その巨大な空白に当てはまる商品は、現状では1つしかありません。

もう、おわかりですね

2011-02-10

http://anond.hatelabo.jp/20110209221517

Cの場合は使わないからだろ。関数内に関数

というか、Cの場合関数粒度を気にすることが多いからね。

再帰関数 > ループでかけ

たいな感じで、関数コールを嫌う文化からなぁ突き詰めると。

そういう事をしようと思わない。別な書き方をするとかじゃなかろうか?

 

いちおう、C++ならクラス内にクラスは書けるから似たような事はできる。

 

C/C++文化的に速度とメモリ重要視する言語からあんまりね、そう言うのは主流じゃないと思う。

class A{

private:

 int A:

public:

 void set_A(int &a){

  A=a;

 }

}

たいなことも・・・あまり、おすすめできないし・・・。論理的には美しいんだけど・・・いろいろ弊害もあると考えるのがC/C++

ましていわんや、関数内。

※一番痛いのは、設定関数が1箇所なので、動作変更がすぐできる>>大規模システムではコードカバレッジがあるので、

根元の関数の挙動を大きく変えられたら、上位のクラスの莫大なテストやり直しだから、1箇所変更で全箇所変わるのはデメリットw。上位で修正が基本。

というか、やっちゃだめwww。

たとえば、intをdoubleにとかなら、それもう別物だから、上位も変更でしょ。普通・・・。とか。

 

あと#define関数デバッガーでおえないので、なるべくC++コンパイラ通してinlineで書いてぇぇぇぇとか。色々。むしろ#defineで複雑なことしないで

2010-07-09

ビジネスロジックをストアードプロシージャで実装してはいけない

ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジッククライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。

ストアードプロシージャと単体テストは食い合わせが悪い

RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語デバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語記述した場合よりもはるかに時間がかかる。

また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。

さらに、カバレッジツールは大抵の場合使えないだろう。

ストアードプロシージャは、たいていの場合、静的解析が行えない

ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。

ストアードプロシージャは、バージョン管理されたコードとの整合性に問題がある

仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイル管理し、それをバージョン管理システムに含めたとしても(というか、最低そうすべきなんだが)、あるリビジョンコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。

ではトリガーはどうなのだ

リガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。

さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。

では一体いつストアードプログラムを使うのか

一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合

もう一つは、複数クライアント言語で同一データベースを使用することが決定済みな場合

2008-02-19

http://anond.hatelabo.jp/20080219092305

上司の資質が激しく問われているな。

今日モジュールXのテストデータを作ってください。11時までにテスト項目としかるべき結果のリストアップカバレッジをチェック後、Y主任からレビューを受けてください。主任には私から話をしておきます。午後からテストデータを作成してください。明日朝市からモジュールテストに入ります。

こんな感じ?

2007-11-14

それは仕様・・・が違ってました

いま結合試験だ。

仕様書が間違ってたり曖昧だったりする。

時間がないから力技でテストをした。

上のPMに報告せねばならない。

どうやったら説得力のある報告ができるか?

いまさら無理だろ。

密度、カバレッジ等を持ち出しても仕様が違うのは論外。

少しはプロセス改善の目を持ってほしい。

管理する側はプロセスより結果を見るほうが楽だろうけどさ。

(※大手SI屋の中の人より)

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