「バグのないプログラムを書け」はできるんじゃない?


プログラムのわからないえらい人「バグのないプログラムを書くことはできないのか?難しいかもしれないが、十分に気を付けていれば防げるのではないか?」にどう返したらいいのかわからない

http://anond.hatelabo.jp/20170214114736

バグは人のミスなんだから、理屈的には正しいような気がする

だけど未だかつて人類はこれを達成できていないという観測的事実がある、何故そうなるのかを説明することは可能だろうか

ふと思ったんだけど、この増田さんが言われた「バグのないプログラムを書け」はできるんじゃない?

ゼロにはできないけど、限りなくバグの少ないシステムは作れると思うよ。理論的にはね。

でもね、問題がある。

「バグが限りなく少ないプログラムを書く」ためには膨大なコストと時間がかかる。

システム構築ってのは必ず予算と工期が決まっている。

だから100万円でシステムをつくるのに、1000万円かけて「バグが限りなく少ないプログラム」は作れないし、1ヵ月の工期に1年もかけていられない。

100万円のシステムを1ヵ月で作るのに1000万円かけて1年もの時間を費やしていいのなら「バグが限りなく少ないプログラム」は作れるんじゃないかな。

その「プログラムのわからないエロい人」に言ってみたらいいよ。「予算と工期を最低でも10倍用意したらできるかもよ」と。加えて「それでもやるか?」と。

それでもゼロにはならないから、世の中のシステム障害ってのものが後を絶たないのだけどね。

WordPressカスタム投稿プラグイン「Toolset Types」がプラグインディレクトリから消えている


カスタム投稿用プラグイン「Toolset Types」がWordpressのプラグインディレクトリ(プラグインリポジトリ)から消えているようです(2016年11月7日現在)。どうやら技術的な問題と規約上の問題があるらしく、技術的な問題は解決したものの規約上の問題が依然残っているとのことです。開発元もWordpressリポジトリへの復帰を望むべく、鋭意努力はしているが、べつの方法での配布も検討しているとのことです。「Toolset Types」をご利用の方は公式ページ(英語)をチェックされることをお勧めいたします。

Toolset Types 公式:
https://wp-types.com/blog/

Google Chromeでは javascript の window.close() で自分自身を消すことができない?効かない?


表題の件、javascriptのwindow.close()について、いろいろとテストをしてみた。

結論から言うと、Google Chromeでは javascript の window.close() で自分自身を消すことができないです。効かないです、ハイ。

忙しい人や、とりあえず結果だけ知りたい人は別に以下読まなくてもいいんじゃね?以下は「できない」ことを検証しただけだから。

さてさて、
以下のような簡単なコードを書いてみてテストしてみる。

sample1.htm

<html lang="ja">
<head>
<meta charset="UTF-8">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
</head>
<body>
<script>
$(function(){
    $(document).on("click","#close_window",function(){
        //自分自身を閉じる
        window.close();
    });
});
</script>
<button id="close_window">Close Window</button>
</body>
</html>

↑のHTMLファイルを作りChromeブラウザの「お気に入り」から(URLアドレス欄にパスを張り付けてもおなじ)「sample1.htm」を表示させてボタン「Close Window」を押すと、

Scripts may close only the windows that were opened by it.

というエラーが出て画面を閉じることができない。
一方で、「sample1.htm」のファイルを「ファイルの右クリック→プログラムから開く→Google Chrome」とすると
あら不思議、さっきまでウンともスンとも言わなかったのに見事にタブが消えるじゃありませんか。

もうちょっとツッコんでテストしてみる。

以下の2つのファイルを作ってみる。

sample2.htm

<html lang="ja">
<head>
<meta charset="UTF-8">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
</head>
<body>
<script>
$(function(){
    var childWindow;
    $(document).on("click","#open_child_window",function(){
        //別窓でsample3.htmを開く
        childWindow = window.open("./sample3.htm","window_close_2","_blank");
    });
    $(document).on("click","#close_child_window",function(){
        //別窓で開いたsample3.htmを閉じる
        childWindow.close();
    });
});
</script>
<button id="open_child_window">Open Child Window</button>
<button id="close_child_window">Close Child Window</button>
</body>
</html>

sample3.htm

<html lang="ja">
<head>
<meta charset="UTF-8">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
</head>
<body>
<script>
$(function(){
    $(document).on("click","#im_close",function(){
        //自分自身を閉じる
        window.close();
    });
    $(document).on("click","#close_parent",function(){
        //自分自身開いた親を閉じる
        window.opener.close();
    });
});
</script>
<button id="im_close">Im Close</button>
<button id="close_parent">Close Parent Window</button>
</body>
</html>

例ごとく、Chromeの「お気に入り」から「sample2.htm」を開く。
ボタン「Open Child Window」を押すと普通に別窓で「sample3.htm」が開く。
別窓「sample3.htm」のボタン「Im Close」を押すと、別窓「sample3.htm」が普通に消えてくれる。
これは問題ないようだ。

もう一つのボタン「Close Parent Window」を押すと、これは効かない。
案の定、「Scripts may close only the windows that were opened by it.」だ。
さて、前の実験と同じく、「sample2.htm」を「ファイルの右クリック→プログラムから開く→Google Chrome」とすると
あら不思議、「Close Parent Window」も動作して「sample2.htm」が表示されているタブもスコッと消える。

最後にもう一つテスト。
以下の二つのファイルをつくる。

sample4.htm

<html lang="ja">
<head>
<meta charset="UTF-8">
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
</head>
<body>
<script>
$(function(){
    $(document).on("click","#move_next",function(){
        //sample4.htmに画面移動する
        location.href="sample5.htm";
    });
});
</script>
<button id="move_next">Move Next</button>
</body>
</html>

sample5.htm

<html lang="ja">
<head>
<meta charset="UTF-8">
</head>
<body>
<script>
$(function(){
    //即座に自分自身を閉じる
    window.close();
});
</script>
<span>ほげほげ!!</span>
</body>
</html>

これも同じように「お気に入り」からと「右クリック→プログラムから開く」で試してみると、
「お気に入り」のほうは「sample5.htm」が表示されたまま止まり、
「Scripts may close only the windows that were opened by it.」となるが、
「右クリック」のほうは「sample5.htm」が表示された瞬間に消える。

結論としては・・・・

  • Google Chromeでは親タブ、親ウィンドウをJavascriptから(window.close()で)閉じることはできない。
  • ただし、window.openで開いた子ウィンドであれば自分自身からでも親からでも閉じることができる。
  • もちろん子ウィンドウから親ウィンドウは消すことはできない。

WEBサイトやWEBサービスを作るうえで、
「ファイルの右クリック→プログラムから開く→Google Chrome」なんてやるわけないから、
実質のところGoogle Chromeでは親画面(=初期表示ウィンドウや初期表示タブ)はスクリプトから消すことはできないようだ。
まぁ考えてみればセキュリティ的にもUI的にもいきなり画面が消えるなんてことはNGだからっちゅうことかしらね。
ってことで、この記事を書くきっかけとなった「URL直打ちされてタブ画面として開かれてしまった画面を別ウィンドウに移動させる」という課題は頓挫いたしましたとさ、チャンチャン。

ちなみにIEでは自分自身をWindow.close()で消すことができます。ただ、「消していいですか?」的なダイアログがでるので、どっちみにユーザのクリック動作が必要になるけど。自動的にスコっとウィンドウやタブを落とすのはできないのね。

PHPの開発環境にVisual Studio Codeがいい感じ


PHPの開発環境でよさげなエディタがないものかずっと調査していたのですが、
どうやらMicrosoftが作ったフリーのコーディングエディタである「Visual Studio Code」なるものがよさそう。
無料だし。なんせ無料だし。

Micorosoft Visual Studio Code
https://www.visualstudio.com/ja-jp/products/code-vs.aspx

んで、早速触ってみましたよ。

ちなみに、我が家の開発PCは基本的に外に持ち出すことを前提としておりまして、軽量コンパクトなノートPCが開発環境になっております。つまり非力なのです。だからEcripsなんて動かすだけでもCPUとメモリから煙が出そうな重厚なものは不可なのです。

ということで、我が家で一番非力なマシンであるASUS E200HAにVisual Studio Codeをインストールしてみました。

結論として・・・・

結構いけるじゃないの!!
ちょっとモッサリしてるケド。

さすがマイクロソフトのVisual Studioの名を冠しているだけあって、超IDEライク!!
テキストエディタな感じが一切しない!!
だから開発してる気分がモリモリですよ!!
ちょっとモッサリしてるケド。

デフォルトのデザインがいい感じじゃないの!!
ちょっとモッサリしてるケド。

コードの自動補完(スニペット:Snippets)とかIDEライクに効いてくれて、しかもjson形式で設定できるから、メンドクサイUIでちまちま設定する必要もないし!!
ちょっとモッサリしてるケド。

コードハイライトもデフォルトで効いててくれて、とくに設定をイジル必要もなくデフォルトで使えちゃうレベルです。
ちょっとモッサリしてるケド。

Gitなんかもデフォルトで使えちゃうんですよぉぉ!!
Gitなんて使ってないけどね。
あと、ちょっとモッサリしてるケド。

ちなみに、ちょっと古いけど、この↓サイトなどで

Visual Studio Codeの謎ペインの仕様はユーザ離れを起こす原因となり得そうな件
http://www.bunkei-programmer.net/entry/2015/11/25/190000

「純粋なタブの概念ではなく、横にしか分割できないペインが恐ろしく使いにくい」

とおっしゃられていたので、どうにかしてタブウィンドウで開けないものか触っていたらなんとも簡単にできたよ。

左ファイルツリーのファイルをダブルクリックすればタブウィンドウで開くじゃないの。

ってことでVisual Studio Code で複数ファイルをタブウィンドウで開きたい場合はダブルクリックすればいいよ。問題解決。

しばらくVisual Studio Code使ってPHP開発してみようかとおもってますよ。

【寄稿】システム開発の見積が高い4つの理由(ワケ)


Giochiamo!!ジョキアーモ!!からの寄稿記事です。

≪元サイトで読む≫

【ワケ1】儲ける必要のある「会社組織」が見積もっているから

システム開発という話から逸れますが、そもそも会社組織というものは絶対に儲ける必要があります。トントンじゃ絶対にダメなんです。なぜなら、そもそもマイナスからスタートしているからです。

会社組織というものは存在しているだけで経費がかかります。事務所賃貸費用、間接人件費、税金などなど。これは、仕事をしていなくとも必要であり、組織が生きていく上で絶対に必要となる生命維持(「法人は人格を有する」とはよく言ったものです)の費用です。したがって仕事を受ける以上、それなりに儲けを乗せないといけません。逆を言えば、会社組織というものは儲けが少ない仕事は受けてはいけないのです(儲けが少ない仕事ばかりしていると生命維持に支障がでてきます)。

したがって、当然ながら見積額にはその会社がその仕事で活動するうえで最低限以上の利益(経費といってもいい)が乗ります。つまり、会社組織が大きければ大きいほどこの利益が大きくなってきます。大きなシステム会社に見積もりを要求するとビックリするような金額が出てくるのはこのためです。

以前、勤めていた会社では「最低でも経費は6掛け」で計算していました。つまり原価100万円(原価=直接経費)の仕事は167万円以上の金額で提示していました。これがある程度の会社組織ならば当たり前のようにされています。一般の方々から見たら6掛けされた見積額と原価額を聞くと「ボッタくってるなぁ」と感じるかもしれませんが、これでも儲かっているわけではないんです。いろいろな経費を引くと、これでもトントンなんです。これには僕もビックリしました。このように会社組織の生命維持に必要な経費というものはとても大きいものなんです。

【ワケ2】システム会社が得意な技術が決まっているから

システム会社には得意な技術が必ずあります。建設会社を例にわかりやすく例えると、マンションなどのコンクリート構造物が得意とか、橋梁などの鋼構造物が得意とか、身近でいえば木造の家を作るのが得意だとか、そういう得意分野みたいなものがあるのです。具体的には、Windows系.NETが得意とか、業務システムをJavaで構築するのが得意とか、PHPでWEBサービスを作るのが得意とか、SAPやSalesforceなどの特定アプリケーションの導入やカスタマイズが得意とか。そのシステム会社によほど経営的な判断(新しい分野にチャレンジしよう、など)があった場合以外は、通常、その会社得意な技術やアプリケーションを使ってシステムを構築することを前提として提案や見積額が提示されます。

一方で、システム開発というのは不思議なもので、技術ごとに人件費単価が異なっているのです。つまり、.NETで工数1人月で作る場合と、Javaで工数1人月で作る場合と、PHPで工数1人月で作る場合でかかってくる人件費は異なっているのです。さらに不思議なことに、この人件費単価はかなり差があり、へたをすると費用が1~3倍になることがあります。

そこで、とある会社に「あれがしたい、これがしたい」と要望を持ち込むと、その会社が得意な技術と作り方でソロバンをはじきます。そうすると必然的に価格が異なってくるのです。つまり他社と1~3倍ほど差がある見積額が出てくるわけなんです。

具体例を出すと、Javaでシステムを構築する技術者の一般的な人月単価(技術者1人に1か月間作業をさせるのに必要な価格)は平均で60万円と言われています。一方でPHP技術者は平均月額単価は30万円です。しかもPHPはそもそも簡単学習、短工期を最大のメリットとしている言語ですので、Javaよりも高速で(短い工期で)構築することができます。おのずと見積額にも明確な差がでてくるわけです。(※ただし双方にメリット・デメリットがあるので一概に価格では決められないことはお断りしておきます)

【ワケ3】正しく要件を定義していないから

システムを作る上で最も重要な作業の一つに「要件定義」といわれる作業があります。この作業を簡単に説明すると「お客様の要件や要望を聞いて、お客様が何をしてほしいのか決める」作業となります。これは「お客様の御用聞き」をする作業ではありません。「お客様に本当に必要なこと」を正しくかつ詳細に探り当てる作業なのです。さらにいうと「お客様にはいらないこと」をちゃんと明確にする作業でもあるのです。そして要件定義をするうえで一番重要なことは、要件定義の段階では決して「お客様に必要なモノ(機能や形姿)」を具体的に定義してはいけないのです。

基本的にお客様はご自身のことをよくわかっておられません。ご自身にとって「本当に必要なモノ」を見えていないことが非常に多いのです。お客様は、ただ、漠然と「ほしい」と思ったから来ただけなのです。したがって作り手である我々が「そもそもなぜ、ソレがほしいと思ったのか?」「ソレを持つことによって何を成したいのか?」を紐解きながら「ただ、ほしい」という気持ちを解きほぐし、「お客様に本当に必要なこと」「お客様には要らないこと」を明確にして、お客様と共有していきます。これが要件定義という作業です。具体的なモノの話は、要件定義が明確になった後に具体的に設計されます(これを基本設計といいます)。

シンプルに考えてみてください。本当に成すべきことがわかっていないのに、本当に役に立つシステムができると思いますか?本当に成すべきことが分かっていないのに、システムを正しく使うことができると思いますか?本当に成すべきことがわかっていれば、不必要を極限までそぎ落とし、必要最低限の機能で最大の効果を上げるシステムを作ることが可能となります。つまり、要件定義が正しくできていれば「必要なシステムを安く作る」ことも十分に可能なのです。逆を言えば、要件定義が不完全もしくは間違って行われていた場合「必要以上かつ不必要で余計なものを作ってしまう(=高価になる)」危険があるわけです。

私のところに他社で出された見積を片手に「このシステム作るのにこんなに費用かかるの?」と相談に来られる方が多くいます。すこし時間を頂戴して、その方の要件をゆっくり紐解いていくと、実際にはその金額の半額以下で十分に構築可能なことがたくさんあります。つまり、お客様の要件を慎重に抽出してから、違ったやり方、異なる技術、その方の妥協点などをよくよく探っていくと1/5の価格で出来てしまうことも当たり前のようにあるのです(ただし、価格を下げるということは何かしらの代償が伴います。それを必ず説明してご納得いただかない限り、その仕事はお受けできないことがあることはお断りしておきます)。

この要件定義を正確に行うことが、正確な見積もりを出す根拠となります。強いて言えば、本来であれば要件定義ができていなければ見積はだせないのです。すでにお気づきと思いますが、要件定義は発注前に行われなければなりません。つまり、専門の技術者が要件定義をするのではなく、営業担当者が要件定義を行うことが多いのです(一般的な会社組織では技術者を動かすのは発注がなされた後になります)。要件定義を行うにはそれ相応の知識と経験が必要となります。一般的な技術者であっても要件定義を正確に行うことは難しいのです。要件定義を行う営業担当者にその知識と経験があるか・・・それが大きな問題となります(ここを重視して優秀な営業担当者を配置する会社組織ももちろんあります)。したがって、「だされた見積もりが高い」と相談に来られた場合、私はその方が話を持ち掛けたシステム会社の要件定義があまり正確に成されていないのではないか?と常に疑い、まず要件を慎重に分析することから始めるのです。その結果が前述の事例に結びつきます。

【ワケ4】その仕事を「やりたくない」から

最後は、単純な理由なのですが、あなたの持ち込んだ要望について、そのシステム会社が「できるけど、やりたくない」場合があります。【ワケ1】でもすこし触れましたが、会社組織には「やってよい仕事(=やるべき仕事)」と「やってはいけない仕事」があります。やりたくない理由はとても簡単で単純に利益に結びつかないのです。これは会社ごとにかなり明確に決まっています(これが明確でない会社は前述のとおり存続が危ういです)。しかし、お客様に対して「それは儲からないのでやりません」とはさすがに言えません。言えば失礼どころか信用を失いかねません。したがって、かなり利益を乗せた金額(=本来ならやらないが、このくらいくれるなら受けてもいい金額)を提示して「申し訳ありません、うちではこのくらい頂かないとできません」と頭を下げるのです(これなら営業職も頭を下げやすいのです)。

以上が、システム会社の見積が高い4つの理由(ワケ)です。
いかがでしたでしょうか?
あなたの手元にある「システム会社が作成した見積書」が高い理由をお分かりいただけましたでしょうか?

【これは絶対に買い】エイスースのモバイルノート 11.6型ディスプレイ ASUS VivoBook E200HA を3か月ほど使ったのでその感想とレビュー


ASUS VivoBook E200HAのベンチマークについて

(のちほど別記事で記載予定)

ASUS VivoBook E200HA ゴールド

ASUS VivoBook E200HAの使用感について

自分がASUS VivoBook E200HAで常時起動しているのは以下のアプリだ。

  • Mozilla Thunderbird
  • MS-Office Excel 2016
  • DropBox
  • LINE PC版
  • Google Chrome
  • 秀丸
  • WinSCP
  • Teraterm

たまに開発用で以下のMySQLサーバを立てて作業することがある。

  • MySQL Server
  • MySQL Workbench

前述のアプリを使いながら感じたのは、正直なところ、CPUパワーとメモリ量が圧倒的に足りない。
どのアプリが食っているか詳細にはしらべていないが、前述の常時起動アプリを全稼働させて、Chromeのタブを数個開くとマウスがカクつきだす。
そもそもアプリ起動にももたつく(ただWindowsの起動は鬼のようにはやい、さすがWindows10だ)。
Excel作業などもストレスになるとは言わないまでも、重いのが実感できる。内容タップリのブックをExcel作業しようとすれば、さらに動かないだろう。

たまに開発作業でMySQL Serverを立てることがあるのだけれど、これが顕著にパフォーマンスを下げる。MySQLで仕事しながらThunderbirdでのメール確認はものすごいストレスになる。動かなくなることはないが、数秒のタイムラグが発生する。

まだ試してはいないがEcrips、Android StudioやVisual Studioなどの開発環境を快適に動かすのはまず無理だと思ったほうがいい。できなくはないがかなりの高ストレスになるだろう。はじめからこれらのIDEでの作業を想定しているならもっとパワーのある違う機体にすべきだ。

ただし、これらは元からわかっていたことだ。
このASUS VivoBook E200HAはすこしましなタブレット機レベルのパフォーマンスしかないのだから。

それを補って余りあるのが本体の軽さとバッテリーの持ちだ。
丸一日充電せずに出先でフル作業できるのだから大したもんだ。
それが本体の軽さにも拍車をかける。なにしろ電源を持ち歩かなくてよいのだからさらにカバンの重さを軽くさせる。

一方、購入当初から懸念事項であった本体ストレージ容量だが、これも足りないことは足りないのだが、3か月ハードに使っていて容量が足りないと感じたことは全くない。
そもそもCPUパワーとメモリに余裕がないので、そこまでいろいろなアプリやデータを持ち歩くことができない。
今の私のマシンでは、いろいろなアプリをインストールしてもメインストレージは3~4GBの空きがあるし、さらに、4000円~5000円程度で購入できる128BGのSDXCカードを1枚さしているので、映画の10~20本ぐらい余裕で入る(そもそも快適に映画を見れるPCではないが、夜のお供などに)。

「ブラウジングとメールチェックだけしか使えない」と言われた低価格ネットブックにしてはちゃんと仕事になっている。
3万円強の出資に見合ったリターンが得られていると自信をもって言える。

ASUS VivoBook E200HA ダークブルー

ASUS VivoBook E200HAの機体外観や機体デザインについて

私はゴールドを購入した。ゴールドはかなりMacBook Airを意識したつくりになっている。が、質感がかなりチープだ。
外観についてはあまり期待もしていなかったし、使えればよいと思っていたし、そもそもMacBookAirそんなに好きじゃないし、でそこまで気にならない。でもどうせならブルーを買えばよかったなと思っている。ゴールドはチープさはかなり目立つ。まぁPCなんてきれいに飾り立てるものでもないし、私は文房具感覚で使い捨てにするつもりでこのPCを購入したので、機体外観や機体デザインについてはまったくマイナスにはならない。

ASUS VivoBook E200HA ホワイト

以上のことから、機体のパフォーマンスを考慮したうえで、ある程度使い方を限定できるならば、非常におすすめできるノートPCだ。ただ、万人におすすめできるPCではないことはご注意いただきたい。

VMWare Playerで「*****.vmxは有効な仮想マシン構成ファイルではありません」と出た場合の対処法


VMWare Playerで突然

「仮想マシンを開けませんでした:******.vmx

*****.vmxは有効な仮想マシン構成ファイルではありません」

というエラーメッセージが出てゲストOS(仮想ディスク)が起動できなくなった。

この場合の対処法について。

結論から言うと、ゲストOS(仮想ディスク)を同じ構成で新規作成してvmxファイルだけ元のvmxファイルと置き換えてやれば治る

仮想ディスクの新規作成では「あとからOSをインストールする」を選択。

仮想ディスク名は壊れた元の仮想ディスク名と一致させること。

元の仮想ディスク名は実態ファイル名が大抵仮想ディスク名となっているので、そのままつければよい。

もちろん、ネットワークの設定やらメモリ割り当て、プロセッサ割り当てなどは新規作成した仮想ディスクのものに置き換わってしまうので、運用していた元仮想ディスクに合わせて変更してやる必要がある。

ロリとエルフと魔法少女と自衛隊の「GATE(ゲート) 自衛隊 彼の地にて、斯く戦えり」が面白い


「GATE(ゲート) 自衛隊 彼の地にて、斯く戦えり」を一気見した。結論から言うととても面白かった。ストーリーは美少女系萌えファンタジーと戦国自衛隊を足して2で割った感じ。前者は「推して知る」ような萌えをこれでもかと詰め込んできて、もうお腹いっぱいだよママン的なものだけど、後者が非常によくできていた。原作者が陸自出身(おそらくメディックだと思われる)なのと、陸自が全面協力しているためか、細かいところがかなりリアルにできている。兵器類や用語などがかなり忠実に描かれていて、ミリ系ファンだったり自衛隊ファンであれば非常にグッとくる場面が盛りだくさんだ。それだけでも見る価値は十分ある。加えて映画「地獄の黙示禄」のパロディ場面があったり、たぶん原作者もアニメ監督もミリ系好きなんだろうなぁと非常に好感が持てた。

ただ・・・・ちょっと気になるのは・・・自衛隊が先制攻撃でバンバン人を殺してるのよね・・・・いちおう自衛隊は建前とはいえ軍隊ではなく専守防衛の組織のはずなんだけど・・・例えば、他国の内ゲバに陸自が介入して、片方を一方的に蹂躙するのはいかがなものかと。。。いくら異世界という設定だとしても政治的優位に立つという理由で大っぴらに先制攻撃していいものなのかね。ってか陸自が監修しちゃってるんだけど、これ防衛省的にOKだったのかね?っと小一時間。

ボソッ・・・youtubeで全話見れちゃうんだよね・・・

Windows版 MySQL5.7 64bitのインストーラは無いが32bit版インストーラに64bit版も含まれている。


Windows版のMySQL5.7 64bit専用インストーラはないのだけど、MySQL5.7 32bitインストーラに64bit版も含まれているっぽい。

MySQL5.7 32bit版インストーラダウンロードサイト
http://dev.mysql.com/downloads/mysql/

※オラクルのユーザ登録(無料)をしてからログインが必須

MySQL 5.7 32bit版インストーラをたたいて「custom」を選ぶとインストールするものを選べるので、そこから64bit版を選べばおk。

あといままでだとZIP版(ZIP Archive)で適当にINIファイル設定するだけで動いたんだけど、なぜか失敗。。。ちゃんと調べれば動かせるんだろうけど、メンドクサイからインストーラで入れちゃった。

蛇足だけど、MySQL Workbench 6.3.6 をインストールする際には以下の2つが必要になるのであらかじめ入れておこう。

MySQL Workbench 6.3.6 ダウンロードサイト
http://dev.mysql.com/downloads/workbench/

※こちらも要ログイン(無料)

PHPerはワープアまっしぐら。PHPerの単価が月60万~とかありえない。


そもそもPHPerの単価が月60万~とかありえない。

「フリーランスエンジニアが知るべき、PHP案件のトレンド、特徴、単価相場とは」
https://freelance.potepan.com/blogs/1685.html
より引用

~前略~

フリーのエンジニアが受け取る報酬の相場は一般的にプログラマで「40~60万」、システムエンジニアで「60~80万」と言われています。もちろんスキルや時間によりますが、一般的にはPHPですと相場は月60〜高い方で90万ほどです。

~後略~

この記事についてモノ申したい。

PHPが短期開発に向いているのは正しいが、それはPHPが規模の小さいシステム開発に向いているという理由がある。1人ないし2人という小規模でチャチャっと作ってしまうようなシステム開発でPHPは非常に大きな力を発揮する。そういう小規模なシステムだけに予算自体も少ない。大きなシステムほど成功すれば大きな利益が得られるが、システム規模が小さくなれば利益も少なくなり、自ずとシステム開発予算も小さくなる。

PHP案件は予算200万以下という案件が圧倒的に多い(比べてJava案件は億規模がゴロゴロある)。これに原価60%だと計算すると120万になる。これがエンジニアに支払われる金額となる。予算200万の規模だと工数は延べ2~3人月ぐらいが良いところだろう。工数がかかりすぎだと思うだろうか?これに要件定義や設計期間、運用テストなども含まれていると仮定すると、妥当な数値だ。単純に120万を3で割っても一人当たり40万だ。上流工程で月40万とかはありえないので、マネジメントをする上流SEだけ月60万と計算すると、コーダーに支払われるのは一人当たり30万となる。この計算、発注者と受注者の間にウワマエを刎ねるハイエナ会社(管理費、口座貸費用などの名目でウワマエを刎ねる)が一切いないことを前提に話している(つまり商流が1段)。ハイエナがいればそれだけ技術者に流れる金も少なくなる。

次にPHPは比較的に習得が容易だ(PHPフレームワークなども含め)。つまりPHPerはたくさんいる。技術者がたくさんいれば相場は自ずと下がる。さらに高度な技術者は単価の低いPHP案件など受けない(Java案件などの単価の高い案件にいく)から、PHP案件しか受けられない技術レベルの低い(=単価を安くせざろうえない)技術者しかいない。結果、案件争奪戦はダンピング合戦となり、PHPer=低単価が決定される。結果、高いレベルの技術者は余計にPHPからはなれていく。ここ7~8年ぐらいこの負の連鎖が続いた。これがPHPerのエンジニアリングサービス(技術者派遣)の実情だ。ぶっちゃけて、Javaなら月60万から、PHPなら月30万から、と買い手と売り手の双方で価格相場が形成されている。PHPerがこれを超えて単価を勝ち取るにはPHPコーディング以外の付加価値が必要となる。

ではそもそもPHPで予算規模の大きなシステムはあるのか?あるにはある。しかし全体からすればごくごくわずかで、しかも首都圏に限られる。もちろんそこには高レベルの技術者が集まってくる(Javaでバリバリ稼いでいるけど、PHPが好き、などの場違いな高段者)。あなたはそこで彼らと肩を並べる自信はあるだろうか?

ではなぜPHP案件で予算規模の大きなシステム開発案件がないのか?それは大手システム開発会社が関わっているからだ。大きな予算がついているということは失敗が許されない。つまりリスクをちゃんとヘッジしてくれる大手システム会社にまず話が持ち込まれる。そういう大手はよっぽどのことがない限りPHPなど絶対に使わない。かならずJavaが提案される。

さらに、エンジニアリングサービスにも地域格差というものがある。関西(主に大阪)は首都圏(主に東京)に比べて単価が80~70%と思っていい。東京での単価60万が大阪なら48万に、東京での単価40万は大阪だと32万になる。「SEなら東京にいけ」というのはこういうところからも来ている(そもそも案件数が首都圏は関西の2倍以上あるというのが主な理由ではある)。

つまり、金を稼ぎたいなら、PHPではなくJavaをやれ、というのが結論だ。というか常識と言っても過言ではない。

冒頭サイトで

PHPの場合はなにしろ開発需要が大きく、求人案件数も多いため、フリーランスの皆さんも多くの案件から自分に合ったものを選ぶことができます。

とあるが、この文章の後ろには「単価(給料)を選ばなければ」という一文が隠れていることを声を大にして言いたい。PHPの仕事は腐るほどあるのだ。だが誰が見てもワープアまっしぐら。あるていど会社組織の体を成している組織(社員を抱えていて食わせていかなければならない組織)では、その単価の安さから受けることができない(受けたら赤字確定だから)。したがってPHP案件は常時人不足。そこが辛うじて現在の単価を維持しているカラクリだ。

このままだと、PHPがあまりにも悲しいのでPHPの優れている点もあげていく。
(技術的に、ではなく、ビジネスとして、という観点から)

PHPはJavaに比べて圧倒的に「安く」作れる。PHPはあらゆるコストがJavaに比べてとても低いのだ。つまり同規模のシステムであれば、Javaに比べPHPのほうが1/10の金額で作れる。これは予算が限られている顧客にとって最大のメリットとなる。したがって、我々のような極小規模のインディペンデント会社が、技術者を売るのではなく、システム開発の全体像から提案して受託開発の受注を狙う場合は、PHPで提案することにより顧客に刺さる可能性が飛躍的に高まる。さらにインフラ周りや改修などの運用コストも低く抑えられるので提案力が出てくる。つまり、起業するとかフリーランスでシステム開発受託を狙う場合、大手と差別化をはかるという意味でPHPは大きな武器となる。逆に、前述に戻るが、末端技術者としてPHP案件に従事するというのであれば、経済的にジリ貧以外のなにものでもない。ワープアまっしぐらだ。「それでもPHPが好き」というのであれば別だが・・・