  |
はてなキーワード: バックエンドとは
副題：Androidで動くBASIC!でプログラミング教育を行うメリットとデメリット
０１．はじめに
この文章は、Androidで動くBASIC!でプログラミング教育を行うメリットとデメリットに
０２．BASICとは
BASICはプログラム初心者向け言語として1960年代に発表された古い言語です。
極めて簡単な文法とインタープリターによる即時実行や1970～80年代のパソコン
に無償で搭載されていたことから沢山の人に利用されていました。
しかし、簡単ゆえの機能の少なさと即時実行方式のための性能の低さやその後の
優れたプログラム言語発表によりBASICの利用は著しく低下しています。
０３．BASIC!とは
BASIC!はアンドロイドのタブレットやスマートフォン上で動くアプリです。
Google playからインストール可能で無料で利用できます。
https://play.google.com/store/apps/details?id=com.rfo.basic&hl=ja
BASICの文法を踏襲していますが、Android向けに大幅に命令が拡張されており、
GPS等の各種センサーの情報取得やSQLiteのデータベース機能、WEBVIEWを利用
したHTML、CSS、JS表示・実行など約500程度の命令群で構成されています。
無料、広告なしのアプリをインストールするだけでこれらの機能が利用可能で
過去の栄光というかBASIC自体は広く利用された時期が過去に存在しパソコン
BASIC!は基本はBASICの拡張であり文法や変数の取り扱いにおおきな違いは
ありません。
その当時、少しであってもBASICを触った人は多いのでメンターとしての
BASIC!は手続き型と呼ばれる非オブジェクト指向の言語であり最新の言語
とは異なっています。
BASIC!のネイティブな命令群だけだと他の言語へのスムーズな移行は難しい
かもしれません。
しかし、BASIC!にはHTML5アプリのようにBASIC!自体のwebViewでHTML,JS,CSS
HTML,JS,CSSは現在Webの標準であり、進化を続けています。
特にjavascriptはオブジェクト指向の言語に進化し採用される領域もフロント
BASIC!自体のwebViewは他のAndroidアプリ同様、chromiumベースでAndroid
システムのWebviewの更新により常に最新化されています。
HTMLモードではjQuery,Angular,ReactなどのJSライブラリも利用できます。
最初はBASIC!ネイティブなプログラム→HTMLモードでJSを利用したプログラム
但しAndroid5.0あたりからAndroidシステムのWebviewが導入されているので
安いタブレットであれば1万円程度で新品が買えます。中古のスマホであれば
更に安価です。
またプログラムを作るのでキーボードもあった方がいいと思いますが
もちろんソフトウェアキーボード（フリック入力など）でもプログラムは
作れます。
パソコンよりもはるかに安価でプログラミング教育が実現可能です。
iPhoneの登場以来現在の子供たちはタッチパネルAndroidデバイスに
慣れています。
また教える大人側も日頃パソコンよりスマホを触る人は多いと思います。
f.可搬性が高い
ここで述べる可搬性とは別のデバイスで同じプログラムを動かす場合の
容易さの事です。
BASIC!はインタープリタなのでソースファイルのみを別のデバイスに
仮にHTMLモードの場合は併せてHTML,JS,CSSをコピーするだけです。
別のデバイスにはBASIC!さえインストールされていれば動きます。
BASIC!独自のプラグインや拡張モジュールなどは特にありません。
a.性能上の問題
BASIC!の実体はJavaで出来ています。すなわちJavaよりは性能は悪い
ことになります。
実際、大量の繰り返しや大量の文字列を扱うプログラムは性能が出ないので
Androidのスマホやタブレット自体もパソコンの演算能力には劣ります。
但し、プログラミング教育には大きな障害にならないと思います。
BASIC!はプログラムを作るアプリである以上当然文法エラーを実行時に
表示する仕組みになっています。
ただ一部エラーチェックが甘い部分もあり本来エラーとすべきところを
そのまま実行する場合もあり想定外の結果となる可能性もあります。
次にエディタは単なるテキストエディタと同等の機能しかなく最近の
エディタにあるようなシンタクスハイライトや入力補完といった機能は
ありません。
ただ比較的シンプルなプログラムを作る教育では大きな影響は無いと
考えています。
c.一部機能に制約がある
前述の通りHTMLモードではJSが動かせます。ただし制約があります。
非同期通信などを行おうする場合、JSが実行時エラーになる可能性が
あります。
またデータベース機能であるSQLiteへの操作についても文字型項目しか
利用できない制約があります。
JSがローカルモードのみなのは教育の事を考えると少し残念ですが
d.参考となる文献がほぼない
該当する書籍がないのが実情です。
■BASIC! ～ 分かりやすい教本で一から学べるコンピュータ言語 - Android★SQUARE
http://blog.livedoor.jp/an_square/archives/51887786.html
BASIC!の文法自体は極めて簡単なのでどうにかなると思います。
０６．結論
技術集団のイメージあるけど、サービスがまじでイケてないって会社って結構あるよね。
バックエンドのエンジニアが優秀でレスポンスがめちゃくちゃ速くたって、デザインが全てを台無しにするような。
インフラエンジニアが超高負荷に耐えうる環境を構築したところで、ユーザーからすれば知るところではない。
すなわち使いやすさだ。
楽天ってエンジニアは優秀な人がたくさん集まっているイメージがある。
リクルートもいろんなサービス持ってるし、エンジニアはガチで優秀だ。
１クリックで済ませるべきところを７クリックくらい要求される導線、すさまじいユーザー経験だわ。
もうなんかCSSは微塵も使っていないかのような初代HTMLデザイン系。
日本でソーシャルゲームがヒットして、およそ10年経とうとしている。プラットフォームはフィーチャーフォンからスマホへと移行したものの、相変わらず膨大な売り上げを生み出し続けている。この間、数多のタイトルが作成され、そして消えていった。これはソシャゲ開発のお話である。
ソーシャルゲームの開発は、他の業種同様企画から始まる。他社IPものであれば大手IPを扱う会社と連携をとり会社主導で企画は進み、自社オリジナルタイトルであれば社内で抜擢されたプロデューサーとなる人物が中心となって企画を書き上げる。会社の規模にもよるが、小規模企業で月商1億、大手なら月商10億を目指すことが目標だ。
その後、適任のデザイナー、プログラマー、企画を含め5,6人があつまりプロトタイプ制作が始まる。ゲームのシステムが組み込まれ、キービジュアルやゲームの雰囲気を決めていく。最終的には会社からゴーサインをもらうことが目的となる。
プロトが通れば、次に、アルファ（一部動かないものの、一通り遊べる）・ベータ（ほぼ全機能が実装）という順にマイルストーンが敷かれ、順に進めていく。多くのスタッフがこのアプリは月10億以上を売り上げ、ランキングで、モンストやFGOといったアプリと並ぶことを意識して仕事をする。
最初の問題はここで発生する。ソシャゲ企業はWebが前身なのだ。つまり、判断する人間が判断できないことが多い。唐突に素人意見を繰り出したり、かのスティーブジョブスを真似てちゃぶ台返しを何度も行う。本人は真剣に、これが経営者のあるべき姿だと信じている。
このような妨害をかわしつつ、のらりくらりとベータへ進んでいくが、その辺りで作業者は厳しい現実と向き合うことになる。これは、微妙なんじゃないかと気づくのだ。その頃、手が空いてきたプロデューサーとマーケターは呑気に広告計画を立てている。そして、いよいよローンチだ。多くの広告費が投入され、特設サイトや事前予約、プロモーションビデオが公開され、華々しい登場を飾る。多くのアプリはこのタイミングが一番ユーザ数が多く、売り上げも高い。逆にいえば、ここで数字が残せなかったアプリは早々に注意信号が点灯し、マーケターは顔を青くし、プロデューサはポーカーフェイスとなる。ここでのユーザ数と売り上げは新しいタイトルに対する期待感と広告費によって得られたもので、今後は開発したアプリの出来が問われていくことになる。使い勝手が悪い、バグが多い、サーバが止まる、ゲームがつまらない、思っていたものと違うなどといった理由で新しいユーザは次々と離脱していく。
そこで、いわゆる継続率という指標、インストールした日から1日後、2日後、そして7日後、30日後に何パーセントのユーザが残っているのかというデータを改善するため、マーケットや行動を調査し、どこにボトルネックがあるのかを調べ改善をするという動きが始まる。また、ユーザを飽きさせず定期的に課金してもらうため、運用が始まる。大抵新しく書き起こされた魅力的なキャラクターが、ローンチ時よりも魅力的な効果を纏って登場する。もちろんそれは、ガチャという形式で提供され、最上位のキャラクターは数万程度の課金が必要になるような確率で封入される。
さて、ローンチから3ヶ月が過ぎた。ここ最近のゲームは3ヶ月分程度の運用分を初期予算に組み込んでいるため、ここから実際に運用を続けるべきかどうかが真剣に判断されることとなる。ところで、この業界での売り上げの方程式は、「DAU（日間アクティブユーザー数）xARPU（ユーザあたりの平均売り上げ額）」だ。問題のARPUだが、ゲームの人気度やガチャの確率によるものの、大抵のゲームは月を平均すれば10円〜50円程度となる。もちろん好調でガチャのキャンペーンが当たっている場合、瞬間的に100円以上にもなる。これは、ユーザ数が少なくなれば作業に対する売り上げのうまみが減ることを示唆している。
ここで、運用の経費を概算してみよう。小さなゲームでも、10人〜20人程度は運用に携わっている。（大型タイトルだともっとだ）平均年棒500万円の給与として、月額41万円。ここで人件費の概算は+16%程度なので、一人47.5万円とする。20人で、約1000万円。さらにサーバ代。ちょっとしたユーザ数でも数十台、数百台規模のAppサーバ、バックエンドのDBサーバ、リアルタイム通信サーバ、アセット用のデータストアや転送料金など、100万〜1000万程度を見ておこう。このサーバ代はなかなか癖があり、Appサーバは比較的増減がしやすいものの、お金のかかるDBサーバは負荷を見越してシャーディングをがっつりかましたのにユーザが少ないと、簡単にスケールダウンできず、泣く泣く無駄に費用を払うことになる。もちろん、甘く見ていてメンテ祭りというのもよくあるが、基本的には事前に過剰な負荷分散が行われているパターンが多い。なにせ、月に10億も稼ぐんだから。 忘れてはいけないのは外注費。イラスト代、3Dモデル代、などなど。5人月 400万円としよう。
さて、サーバ台を500万として1900万が最低の運営費用だ。盛り下がってきたゲームのARPUは10円程度になるとして、元を取るためのユーザ数は約63,000人である。もちろんキャンペーンなどで一時的に売り上げが増えるので、もう少し少なくても良いかもしれない。いずれにせよ、今人気のあるタイトルもそうでないタイトルも、徐々にユーザが減ることで売り上げは減り、投入した資金から得られるリターンが減り、人件費とサーバ代だけが重くのしかかる。
この時、開発の現場はというと、案外淡々と仕事が進められている。慌てふためくのは上位陣のみで、末端作業者は細かな作業改善をしたり、次の異動先に思いを馳せたり、技術向上に努めたりする。また、会社に愛想をつかして退職するのも大抵このタイミングだろう。
その後徐々に、開発の人員が減らされていき、改善のサイクルが長くなり、キャンペーンの頻度も下がる。作業者のやる気はこの辺りで地に落ち、惰性での仕事が続く。当然ユーザからのメッセージには平謝りの状況が続く。何度か、大きめのリリースや広告を放つこともあるが、一度沈み始めた船はなかなか浮上することはない。そして、ある程度の利益を食い潰した（もしくは赤字に耐えられなくなる）ところで、いよいよ赤信号が現示される。
「サービスを終了せよ」
この時、開発チームに余力など残っていない。決められた期日までにきちんとたたみ終わることが目標である。開発者はこのプロジェクトを終わらせることができホッとすると同時に、できればなんらかの形で残したいと思うかもしれない。しかし、それは叶わないことが目に見えているのだ。昨今のアプリはローカル側、つまりスマホにあるゲーム部分は結果を受け取る・ゲームをプレイする、素材を指定するといった入出力の機能しかなく、主なシステムロジック、つまり実際にガチャを引いたり、素材を手に入れたり、結果を処理したりするのはサーバ側に実装されている。このため、ローカル側に全てを実装するのはサーバ側の機能をフルスクラッチをするのと変わらず、とてもこんなことをする暇はない。また、昨今クラウドの様々なプロダクトを組み合わせて実装しているものも多く、素直にソースコードを書き直せば実装できるといった類いのものでもない。
そうして、ユーザ、開発者それぞれが複雑な気持ちを抱いたままソーシャルゲームは消失する。
稀にあまりあるほどの利益を稼ぎ出したアプリであれば、ストーリーやイラストのアーカイブが配信される幸運な例もある。これは開発者や経営側のプライドと感謝と人件費の消化であり、非常にラッキーなケースだ。
開発者でさえゲームを起動することはおよそ叶わない。なぜなら、複雑なサーバ構成を再現せねばならないからだ。せいぜいデバッグ機能でバトルやUIをちょこっと動かすぐらいしか出来ない。
これがソシャゲのあらましである。いま流行りのあのゲームもこのゲームも、いずれは幕が降りるのである。ソーシャルゲームは時代とともに人の心の中へと消えていくのだ。
門外漢からするとこんな風に聞こえてる。（所々適当に書いてるし書いてる内容は嘘デタラメ）
「gulpでbowerしてsassをgruntでビルドすれば、cssがストリーミング形式でデタッチされるから便利だよ。それにgulpはCoffeScriptとかtypescriptみたいな流行りのサードパーティも従来のJSみたいに変換してくれるしウォータフォールじゃなくてアジャイル的なプロジェクトでも使いやすい。スクラッチから書かなくてもいい感じにアジャストしてくれるよ。あと、OSSとしてgit上に上がってるんだけど、DLなんかもAWSと連携させてWebGLとTensorflowやらchainerやらと組み合わせればブラウザでDQNとかA3CとかDCGANも動かせるスクリプトがリリースされてた、バックエンドではDNNを走らせてフロントで表示する分をNode.jsでカスタマイズしたりタスクランナーでプロセスをマネージメントできるからもはやjsでtensorflowを含めたpythonのラッパーみたいな感じで使えて便利。最近ではbluemixがBitcoinのマインングをサポートしていてブラウザ上でウォレットからマイニングのセットアップまでできるんだって、ブロックチェーンの仕組みを拡張して社内のタスクマネージャーとかNAS上のデータを分散してサーバーに保存できるみたいなこともあるんだって。」
http://anond.hatelabo.jp/20170506031453
↑の元増田です。
といわけで、今度のイベも「うわーマジだりー」という感じだったり。
ブコメに新三川艦隊任務の話があったけど、あれは他の枝で書いた通りこの前クリアした。
まあでもかなりしんどかった。今でも思い出すたび不快になる。敵戦艦の攻撃が一発でも当たれば即撤退ないしボスS勝利が消えるとか、闇深すぎ。
上：DeNAのWELQ問題、最大の原因とされている責任者「村田マリ」とは何者なのか？ - GIGAZINE
殺しにかかってるっていうけどこの人十分稼いだでしょ。周りの目を気にするならあんな仕事しないだろうし、むしろ引退できてせいせいしてたり？
光輝「いらすとやもまだまだよのう」
そのままどこにでも持っていけそう。すげーなこれ。
私怨含みっぽい。
失くすには惜しい出来だ…
こういうインチキ臭い業界で成り上がるには、大学生の頃からその大学生ブランドを最大限に活かしてメディア企業に媚びて取り入るところから戦いは始まってるんだな。言いたくないけど電通東大生女子にしてもあれだし
呂布だー！
これに関わってた奴は全員が100%モラルハザードだという事を理解してる。ってか理解できないやつはさすがにトップクラスのITベンチャーで勤められない。 つまり、村田の上司も部下も全員故意犯。彼らに倫理観は無い。
最高かよ
最高だった
こういう「私たちイケてる」感で集まった人がやってたことが、結局は「検索結果にゴミをばらまくこと」だった、というのはコミュニティとして考える必要があると思う
これ、企画からフロント、バックエンドまで全部レベル高くて凄いな。漫画プラットフォーム作ってるところ、まるごと買ったほうがいいんじゃなかろうか
freeeの件で「Google出身のメンバーが高度な技術を引っさげて日本のバックエンドを革命すべく起業したっていうなんとなくかっこいいストーリーがほとんど唯一の売りだったのに」というブコメがあるが、そもそも役員のプロフィールを見ると、彼らは単に営業担当であったことがわかる。
https://corp.freee.co.jp/company/
Google在籍経験のあるメンバーの担当職務は、「中小企業向けのマーケティング」、「新規顧客開発」、「ビジネス開発」などで「エンジニアリング」と書いてあるものは一人もいない。
当然ながら彼らに技術があるわけではなく、CTOは非Google。彼らはGoogleをやめて創業するにもかかわらずエンジニアリングからは一人も引っ張ってこれなかった訳だ。
そのへんを無視して「元Googleだから」といってちやほやするのはもうやめた方がいい。あの会社ですごいのはエンジニアリングであって営業じゃない。
wordpress最盛期。あの案件もこの案件もWordPressを使って、プラグインましましjqueryましまし脂マシマシな納品が星の数ほど生まれていく。「プラグインが最新バージョンに対応しないので、本体のバージョンアップができません」といってセキュリティホールだらけのwordpressが放置される。アホかと、バカかと。
フロントエンドはhtml,css,javascriptでつくるものだよ。expressをみて「javascriptでバックエンド書くの？気持ち悪い」っていってただろ。それと同じだ。いつまでphpでフロントエンド書くつもりだよ。phpで動的生成し続けるから、いつまでもwp headでwordpressのサイトってバレてアタック受けるんだよ。とりあえずurlの末尾にwp-adminってつけて確認されるんだよ。
分離しろ、分離。wordpressの管理画面が悪いとはいわない。あいつはいいやつだ。けど、wordpressでフロント書く必要はない。wordpressもrest apiだしただろ。更新はwordpressでやって、その情報をapiで取得してきたらいいんだ、それでいい。
wordpressでテーマをつくるのがキャッチだった頃からもう6年はたった。6年前といえば、Windows 7使ってた頃だよ。ヒカリエまだできてない。そんな頃のやり方つかって「これがスタンダードです」とかいってクライアントをだまくらかして楽しいか。さっさと2017年に追いつけよ。
当方、フリーの IT 技術者。ある Web ベースのシステムを開発しているのだが、プロジェクトのマネージャー、リーダーをはじめとするメンバーの無知と無理解のおかげで作業が進まずに困っています。
ブラウザーのキャッシュの仕組みを少しでも知っている人なら、非 IT 系の方でも読めるように書きました。ぜひ助言をお願いします。
私は発注元(A 社)に客先常駐している。私が契約しているのは A 社のグループ会社である B 社だ。
A 社内のチームメンバーは以下のとおり。
さて、今開発しているシステム(以下システム P)はもともとスタンドアローンで運用する形態だったが、最近クラウドバージョンの提供も始まり、現在はスタンドアローンバージョンとクラウドバージョンの並行開発となっている。X さん、Y さん、Z さんは主にクラウドサーバーの管理や、私や W さんが作った部分のテストを担当している。
クラウドバージョンの初めてのアップデートを控えた 6 月に問題が発覚した。コードをアップデートすると、ブラウザーのキャッシュが効いていて表示がおかしくなるというのだ。
プログラマー以外の 4 人は実は Web システムの案件は初めてで、ブラウザーのキャッシュの仕組みすら理解していない。X さんから相談を受け、「Web アプリケーションからブラウザーのキャッシュをクリアーすることはできない。代わりに、HTML から読み込まれる外部リソースの後ろに『?v=3.14』のようなダミーのクエリー文字列をつければよい。アップデートのたびに数字を変える。これは一般的に採用されている手法で、これ以外の解決策はない」ということを伝えた。具体的にコードエディター上で修正イメージを見せて、すべてに対応するのに 1 日あればできる、とも。
これで「そうですか、ではお願いします」となれば、テストを含めて 2、3 日で終わった話なのだが、ここから長い混乱が始まる。
X さんから、「変更箇所をなるべく少なくしたいので、前回リリース分と今回リリース分で変更のあったファイルのリストを出してほしい」と言われる。変更のないリソースにはクエリー文字列をつけたくないらしい。
内心呆れつつ、Git (ソースコード管理システム)でファイルの変更履歴を調べ、一覧表を提出した。X さんに「それぞれのページでソースコードを確認し、この一覧表に載っているファイルにはクエリー文字列がついていることをひとつひとつ確認するのですよね。却って手間が掛かりますよ。それよりも、すべてのファイルを対象にしたほうが作るほうもテストするほうも楽です」と伝えた。
6 月も残り 1 週間を切ったある日、Z さんから、「実際に問題になっているのはどのファイルのどの部分か、スタイルシートのどのクラス・ID 指定が効いていないのか、V さんが知りたがっている。原因解明に必要なので調べるように」と指示が出る。
私は「ブラウザーのキャッシュが効いているためで、キャッシュを消すか無効にすれば直る。今までも修正のたびにテストではキャッシュを消してもらっていたでしょう」と説明するが、調べろ調べろと繰り返すばかり。「そんなことを調べて何になるんですか。キャッシュの問題ですよ?」と言うと、Z さんは手をわなわな震わせて、「お客さまが知りたいと言っているのに、『そんなことを調べて何になるんですか』とはどういうことですか!」と声を荒らげる。しまいには「お客さまのご要望にお応えして私たちはお金をもらっている。お客さまからの依頼なら応えるのが当たり前」と言い出す。技術的に意味がないことをいくら説明するも理解されない。
非プログラマー 4 氏の知識の底上げをしないといつまで経っても平行線だと思い、Redmine (課題管理システム)にブラウザーのキャッシュの仕組みを解説する文書を投稿した。ほぼ同じものを以下に掲載する。非技術者にも分かりやすく書いたつもりだ。あまり細かいことを説明しても混乱させるだけだと思い、リクエストヘッダーの Cache-Control や Expires などは説明を省いた。
キャッシュとは
キャッシュ(cache) とは、一度読み込んだデータを内部に保存しておく機構のことです。2 回目以降の読み込み時はキャッシュを読み込むことで、処理時間の短縮を図ります。
ウェブブラウザーにおけるキャッシュは一般に、HTML ファイルおよび HTML から読み込まれる外部リソース(スタイルシートファイル、JavaScript ファイル、画像ファイルなど)に対して適用されます。
キャッシュが作られるタイミング
ブラウザーがあるファイルを読み込もうとする時、キャッシュがなければ実ファイルを読み込んだ上でそのファイルの内容をキャッシュします。
キャッシュが破棄されるタイミング
キャッシュがいつ破棄されるのかは完全にブラウザー依存です。異なるファイルのキャッシュが同じ期間だけ存在するかどうかも分かりません。
キャッシュはユーザーがブラウザーの操作で明示的に削除(クリアー)することはできますが、 サーバー側からクライアント(ブラウザー)のキャッシュをクリアーすることはできません。
ウェブアプリケーションのキャッシュ対策
ウェブアプリケーションをアップデートした際、クライアントのキャッシュを無効にするために、以下の手法がよく使われます。
＜ link rel="stylesheet" type="text/css" href="style.css" ＞ ＜ script type='text/javascript' src='script.js' ＞＜ /script ＞ ＜ img src="picture.jpg" alt="" width="640" height="480" ＞このような外部リソース読み込みについて、ファイル名の後ろにクエリー文字列を追加します。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.4.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.4.0" alt="" width="640" height="480" ＞スクリプトでない静的ファイルにクエリー文字列を付加しても、読み込まれるファイルは同じです。つまり、
style.cssとstyle.css?v=2.4.0は同じ style.css というファイルを指します。ブラウザーが style.css をキャッシュしている状態で、この行を読み込んだとします。
＜ link rel="stylesheet" type="text/css" href="style.css?v=2.4.0" ＞ブラウザーは「
style.css?v=2.4.0というファイルはキャッシュにない」と判断し、style.css?v=2.4.0 というファイルを読み込みます。結果として、ディスク上の style.css が読み込まれてスタイルシートが更新されます。この HTML をまた読み込んだ時は、「
style.css?v=2.4.0というファイルはキャッシュ済み」と判断し、ディスク上のファイルではなくキャッシュを利用します。ウェブアプリケーションをバージョン 2.5.0 にアップデートする時には、「
?v=2.4.0」の部分を「?v=2.5.0」に書き換えてリリースします。＜ link rel="stylesheet" type="text/css" href="style.css?v=2.5.0" ＞ ＜ script type="text/javascript" src="script.js?v=2.5.0" ＞＜ /script ＞ ＜ img src="picture.jpg?v=2.5.0" alt="" width="640" height="480" ＞同様の仕組みで、2.4.0 時代のキャッシュがあっても 2.5.0 用に書き換えられたファイルが読み込まれ、キャッシュの問題は起こりません。
この手法は、キャッシュ問題を解決する手段としては一般的に用いられているものです。俗に「キャッシュバスター (cachebuster)」とも呼ばれます。
数日経った日の午後。Y さんが A4 判数ページにもなる「調査報告書」を作成した。問題になっているスタイルシートについて前回リリース分と今回リリース予定分の差分を取り、それぞれの行について「新規」「変更」「削除」の印をつけ、「とりあえず、このクラス指定が効いていないだけなので、HTML 中にインラインスタイル(＜ div style="..." ＞)で指定すればよい」と結論づけていた。
報告書には「状況から見て、変更・削除されたスタイル指定は影響が出るらしい。新規に追加した部分については影響がないようだ」とも。私が書いた説明を読んでいないのか、理解できなかったのか。
この報告書を元に、X さんから「この行とこの行にインラインスタイルを指定してください。これで暫定対応とします」と指示が出た。
私は「この修正は何ら根本的な対策になっていないことは理解していますか。『現状で問題になっている箇所』は、この環境でたまたまそうなっているだけの話で、ほかのお客さまの環境では別の画面が崩れるかもしれないのです。それを承知の上で、これを暫定対応としてよいのですね」と X さんに確認。X さんは「はい」とだけ答えたので、黙って作業を完了した。Git のコミットメッセージに「この方法は何の効果もないこと、それでも作業をしてよいのかを X さんに確認の上、作業」と書いてコミットした。
しばらくすると X さんから「うまく表示されています。OK です」と報告があった。
夕方、私が帰ろうとすると、X さんが Y さんに「画面がおかしい」と言っている。横から覗くと、先ほど「暫定対応」とやらを入れた画面で、表示は正常だがボタンを押しても何の反応もない。私は静かに「JavaScript のキャッシュですね」。
聞けば、Y さんは「キャッシュはスタイルシートにだけ効く」と思い込んでいたらしい。やはり先の説明を読んでいないようだ。そして、Y さんの環境ではボタンは有効だったとも。
私は「Y さんの環境では(JavaScript の)古いキャッシュは効いていなかった。X さんのところではキャッシュが効いていた。これが、私が言っている『環境依存』の意味です。昼の暫定対応ではダメなんです。半月前から私が言っているように、すべての外部リソース読み込みにキャッシュバスターをつけないと解決にならないんです」と伝える。
Y さんは観念した様子で、「キャッシュバスターって、一部分にだけ適用することもできますか」と聞く。この人、理解してないなと思いつつ、「はい、できますよ」と返すと、「では、問題の発生している範囲を調査して、問題が起こっているファイルにだけキャッシュバスターを……」。やはり何も分かっていない。
私は繰り返し、ブラウザーのキャッシュは環境依存なのですべての外部リソース読み込みにキャッシュバスターを付加しないと無意味だと説明した上で、こう付け加えた。
「指示されたことだけを黙ってやっていれば、そりゃあそっちのほうがラクですよ。でも、喧嘩をしてでも、場の雰囲気を悪くしてでも自分の意見を主張するのは、技術者としてのちっぽけな良心からです。お願いですから、専門家の言うことを聞いてください。私の意見が信用ならないのでしたら、ほかの技術者に意見を聞いてください」
この数日後、本件の対応を先送りにすることが決まったと X さんから報告があった。
聞けば、リリースを急いでいるのは特定の顧客の要望によるものらしい。その顧客はスタンドアローンバージョンを利用しているので、アップデートの現地作業の際にブラウザーのキャッシュを消してくればいいとのこと。
リリースに間に合わない間に合わないとあれだけ騒いでいたのに。プロジェクト管理がまるでできていない。
そして今日の夕方、この件についてレビューを開きたいとプロジェクトマネージャーの V さんから言われる。レビューって、何をやればいいんだろう。何をすれば気が済むんだろう。Redmine に書いた説明を読んで理解してもらえれば、やるべきことはひとつしかないと分かろうものなのに。
X さんから質問を受ける。「例の件、ほかの方法はないんでしょうか。『こういう方法もあるけれど、工数が掛かるので採用しません』というのがもしあれば話が進めやすいかと」。残念ながらありません、せいぜいファイル名そのものを変更するくらいですが、本質的には同じことですし管理の手間が増大します、と伝えた。
ついでに、X さんに「あの説明を読んで、よく分からない部分があったら教えてください」と尋ねると、実は忙しくて斜め読みしかしていないと白状された。その状態で対応策を一生懸命協議していたのですな。
レビューの席でまた一悶着ありそうだ。どうやったら彼らを納得させられるのだろうか。信用できない技術者に説明してもらったって、信じないんだったら意味がないのにねえ。
文字数制限に引っかかってしまい、末尾が切れてしまっていました。続きはこちらに書きました。
おっすオラ社畜！
年齢：今年30歳
経歴：
－既存のシステムを解析して新しいフレームワークに載せ替える作業とか。
－営業が売りつけたソフトウェアを実際に客先に導入する作業とか。
資格：
年収： 400万
俺がいるのはマイナーな海外製のソフトウェアαを客先に導入しにいく仕事。
作業自体はマニュアルにそって設定ファイルを仕込んだりするだけですぐ終わる。
ネットワークの知識とか、特殊な専門知識は必要なし。(マニュアルに載ってないない裏設定とかはあるけど)
あとは製品αのセミナー講師とかもやらされてたけど喋りが下手すぎて外された。
最近はαと連携する他社製品β、εとかの勉強もやれって感じかな。
給料が良い。 －前職は賞与なし手取り18万とかのクソザコITだったから雲泥の差。
上司がいい人。－いい人なんだけど他の人がね…。
オフィスがそこそこキレイ －スチールスケールのオフィスチェア使わせてくれる
20人くらいしかいない部署なのに親会社の派閥も巻き込んで混沌を
生み出している。おかげで飲み会のやりとりも気を使う。
(愚痴も速攻で共有されるので迂闊なことを言えない)
「お前知ってるだろｗ歌えよギャハハ」みたいなのもあった)
－扱ってる製品αは頑張って生き残りの道を探してるけど競合他社やOSSに押されてる。
正社員の人たちは別部署で他の製品担当すればいいかもしれないけど契約社員の俺は切られそう。
法改正に伴って契約・派遣の無期雇用に対応したから頑張れば無期雇用にはなれるかもしれない。正社員は一回落とされてるから無理かな。
実は知り合いが立ち上げた会社に誘いを受けている。
そっちは開発の仕事で会社立ち上げる際に商流すっぱ抜いたらしく結構うまく回してるみたい。
もちろん、給料とか実際に何やるかはちゃんと聞くが行ってみたいと思っている…。
・転職先について待遇と業務内容以外にも聞いたほうがいいことってなんかある？
意外と反応あってあったけぇあったけぇ。
普段は「増田で全レスとか追記なんてだせーよな！」と思っている派なんだけどついリアクション返してしまった。
トラバブコメありがとう。自分では思いつかない考え方とか意見とか出てきて本当にありがたい。
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など（特定されそうだからぼかすけど。）
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
（そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。）
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。（ITインフラ部署の無い会社はさすがに無いはずだ）
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
（ここで簡単のために旧弊社を（旧）A社、買収した側の競合他社を（旧）B社と呼ぶことにする。）
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ？」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。（つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい）
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）
そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。
勉強が不得意な職業プログラマですが、WindowsアプリをSPAに作り替えることになりそう。
プロジェクトメンバーに積極的に技術を習得するような人はいないので、簡単なフレームワークを探しています。
↑に近いようなフレームワークありませんか？
突如として増田の前に現れるプロトタイプ増田11（旧11人の増田）。
アルファブロガーが残したとされる禁忌のネタを使い5000ブクマを動員してyahooニュースにも掲載される。
荒れ狂うYahoo砲とはてブ砲の前に次々とサービス停止に追い込まれるはてなサーバ。
akamaiのバックエンドごと葬り去るその威力の前に、政府は非常事態宣言を発令。
はてな運営は東京DCを捨て、dockerを使い、北海道は石狩にあるデータセンターでサービス復旧を試みるも、
自分を偽って送り続ける退屈な日常と決別して、この非常事態に対する挑戦を開始した。
次回、「決戦！クラウドに降る雪」
君のpingはアプリケーションサーバに届いているか。
という感じの合体ロボものになりませんか。 ＞さくらインターネット様
○朝食：なし
○調子
はややー。
今日と昨日と遅くまで残業して疲れたからか、普段より一際、酔いが回っているので、変なこと書くかも。
昨日言われた通り、調査っていうか、っていうか、向こうの人が望む方式でやるために、もう一度調べ直しをしてた。
向こうの人曰く「このやり方でできる」そうなんだけど、やっぱりどう考えても、できないようにしか思えない。
その、それなりにプログラマやってきてるけど、Webの仕事はこの現場が初めてで、いやまあ一年ぐらいこのプロジェクトにはいるものの、今までは画面とかサーバーサイドで単体で動くバックエンドの仕組みとかを作ってたから、ちょっとこういう部分わからないから
はーい、と頷いて、頑張って調べたんだけど、
やっぱりどうも、そんなやり方はできないようにしか思えない……
うーむ、ちょっと、真面目に勉強したいな、本とか買ってまずは一般論を学ぶべきな気がしてきた。
っていうかあれか、クソ雑魚ナメクジらしく質問サイトで質問すればいいのかなあ。
うーーーーーーーーん、なんか難しいなあ、
いやでも、なんか、仕組みを考える限り、できないようにしか思えないけどなあ。
でも、ネット調べるとやってる人もいるんだよなあ。
でも、なんでできるんだあ？ なんか理屈がよくわからんぞいやだなあ。
だってさ、GETだからURLの中に戻り値が入って取り出せるんでしょ？（うーーーーん、この理解もだいぶあやしいぞ、なんかうまくこの仕組みを理解できてない気がする） POSTだったら、戻り値はレスポンス（あれ？ リクエスト？ いっつも、レスポンスとリクエストがどっちかわからなくなる）のボディに入ってくるから、それただの戻り値で、JSONPでもなんでもなくない？
POSTのJSONPなんてできなくない？
でも、できるっていうんだもんなー。
よくわかんねーなー。
僕の頭が悪いんだろうなあ。
そもそも、なんで、向こうの人がPOSTに固執してるのかも、全く全然わからないんだよなあ。
セキリティってなに？ パスワードとか、機密事項ならわかるけど、ただの検索だしなあ。
（しかも、検索結果は嫌がおうにも、DBとテキストファイルにログ出力されるから、誰が何を検索したかは、URL覗けるぐらいの人なら、POSTでもわかると思うんだけどなあ）
あーーーーー、ビールおいしい。
●XboxOne
○HaloWars2
マルチプレイのオープンベータが始まったので、とりあえずダウンロードだけした。
ストーリーが楽しみで、対人戦はあまり興味がなかったんだけど、ネットのインタビュー記事によると、
5分とかそれぐらいで楽しめる、短めのモードがあるらしいので、少し興味がある。
●3DS
プレイ。
ちゃんと、全員揃えて、悪ポケを並べて満悦です！
・カントー
コラッタ（両）、ラッタ（両）、アローラコラッタ（普）、アローララッタ（普）
ニャース（両）、ペルシアン（両）、アローラニャース（普）、アローラペルシアン（普）
イーブイ（両）
ベトベター（ド）、ベトベトン（ド）、アローラベトベター（普）、アローラベトベトン（普）
・ジョウト
ブラッキー（ド）
ヤミカラス（両）
ニューラ（両）
ヨーギラス（両）、サナギラス（両）、バンギラス（両）、メガバンギラス（普）
・ホウエン
・シンオウ
ドンカラス（普）
ミカルゲ（普）
マニューラ（普）
ダークライ（未）
・イッシュ
・カロス
ケロマツ（両）、ゲコガシラ（両）、ゲッコウガ（両）、サトシゲッコウガ（普）
イベルタル（両）
・アローラ
アクジキング（未）
（例外：タイプ：ヌル（普）、無シルヴァディ（普）、悪シルヴァディ（未））
カントーは、ベトベター（リージョンじゃない方）、ベトベトン（リージョンじゃない方）の普通絵が未実装。ドット絵はあるから仮置き中。
ジョウトは、ブラッキーの普通絵が未実装。ドット絵はあるから仮置き中。
ホウエンは、ポチエナ、グラエナ、キバニア、サメハダー、の普通絵が未実装。ドット絵はあるから仮置き中。
シンオウは、ダークライが両方未実装。仕方ないから、バッジとれ〜るセンターのバイトを仮置き中。
カロスは、いましめフーパの普通絵が未実装、ドット絵はあるから仮置き中。ときはなフーパは両方未実装。仕方ないから、バッジとれ〜るセンターのバイトを仮置き中。
こんな感じなので、仮置きしてる、ドット絵も普通絵もない、悪ポケは、
うーむ、全悪ポケが揃うのがとっても楽しみです！
っていうか、もう、バッジケースがいっぱいいっぱいなので、ドット絵を外させてほしいから、早く普通絵でコンプしてほしいなあ。
○ポケとる
20個揃えることで、レックウザが真の力を解放して、ようやく、ポケとるのチュートリアルが終わる、とかネットのコミュニティでは言われているので、楽しみ。
とはいえ、コインを使えば、普通に真の力は解放できるので、コインが使えないランキングイベントとか、メインステージの道中とかで使うぐらいなのかなあ、まだよくわかんないや。
ログボのみ。
を読んだ。刺激的な内容だが、もやもやしてたのが言語化された感じで「はっ」とした。
と、同時に現状コピペプログラマが生まれるのは仕方ないことだとも思ってしまった。
1つは、根底の意識。もう一つは日本という環境が原因だと思っている。
私は縁あって外国人が多い会社で働いている。そこでWebエンジニアをしている。
一緒に働いている外国人エンジニアが、まぁ優秀なのだ。最近大学を出たばかりの人もいるが、優秀になるレールを歩んでいる。
一緒に働いてると日本人(俺)ってヤベーな。と思うことが多々ある。プログラムに関する意識が出発点から違うのだ。
彼らは以下の共通認識があるように思える。
3. 英語ができるのは当たり前
海外ではソフトウェアエンジニアは、医者に次ぐ人気職であるそうだ。今は帰国したが、一緒に働いてたインド人エンジニアは、大学受験をした際、医者とエンジニアで迷った。と言っていた。
彼ほどではないが、同世代の中でも優秀な若者が、明確なエンジニア希望をもって専門の過程を経てエンジニアとなる。
Linuxやネットワークなどの底レイヤーから、自分の興味ある分野(バックエンドやフロント、アプリ開発)まで、ある程度できる人がインターンを経て入社する。
私の経歴はというと、かなりお粗末なものだ。お世辞にも良いと言えない大学の文系卒で、大きいプロジェクト動かすマネジメントカッケーって思ってSIerを就職口の一つとして選んで入った。大学卒業時にはJavaとJavaScriptの区別がつかなかった。
そんな私でも独学と、勘と、経験によりある程度のことはできるようになったとは思っている(思いたい)のだが、優秀な彼らを見ると、コンピュータサイエンスを学ばずしてエンジニアを名乗ってる自分が恥ずかしくなる時が周期的に訪れる。
つまり、0ではないと思うが、文系卒、更には未経験が就職でプログラマを選ぶという選択肢は日本に比べると圧倒的に少ない。
そのため、外れプログラマは少なく、腐ったリンゴが少ない彼らは腐る確立が低いのだと思う。
私自身もその口だったし、今も抜け出したとは言えない。
しかし、彼らは違うように思える。その根底にあるのは、コンピュータサイエンスを学んできたが故、プログラムは難しいという意識と、造詣の深さだと思う。
もちろん、彼らとてExampleなく出発することはできないが、コピペで済ますことは極力しない。
ちゃんと手を動かして、表面だけでなく、どうやって動いてるかを理解しようとしている。1つの機能実装する時は、3つほどルートを探したり、必要なパラメータ、オプション以外もちゃんと調べてコーディングしている。
そのため、簡単にできます。とはあまり言わない。例えば、form一つ作る時も背景を理解して実装を行う。様々なセキュリティリスクを考慮して、フレームワークを選択している。
自分なんて、必要な部分しか見なかったし、そもそも調べる意識がなかった。ある時、私は仕事が早くなったと息巻いてたが、今思うとなんてことはない。単にググるのが上手くなっただけだったのだ。
3. 英語ができるのは当たり前
少し変わった環境で、いろんな国籍の人が働いている。スペイン、イタリア、聞いたことのない国の人もいる。しかしながら、彼らは一貫として英語がしゃべれるし、書ける。「え、公用語でしょ？」と言わんばかりだ。
だからなのか情報のキャッチアップが早い。わからないところはissueを漁るし、質問する。まず当たるのは公式だ。英語を英語のまま取り入れる。
総意の認識であると思うが、プログラムの１次ソースは英語だ。私たちの目に触れる多くは優秀な日本人エンジニアが翻訳した情報である。そもそも張っているアンテナが違う。
あと、上手くは言語化できないのだが、そもそも降りてくる情報自体が綺麗に整ったもの、絞られたものが多いのだ。そのため、泥水をすすることが少ないと思う。だからなのか、過程をすっ飛ばして答えを求めるサイトが多いような気がする。
では、この意識の違いはどこから来るかというと、日本という環境が大きいのかもしれない。
まず日本は、他国に比べて内需で食っていけるような環境である。
企業の発展にはエンジニアは必要不可欠。そのため専門知識を学んでなくとも、大量募集 - 大量採用が行われたのだと思う。
その後、海外の優秀なエンジニアが入ってテコ入れするかと言うとそうではない、日本語という既得権で守られているからだ。
なので私たちは気づきにくい。世界のトレンドとか、プログラムの書き方とか、考え方とか。そのためコピペエンジニアは自分をコピペエンジニアと知らないまま成長し、なまじ仕事ができて自信を覚え、次のコピペエンジニアを育てる仕組みが出来上がっていると推測する。
ここ数年でエンジニアを主体とする会社が増え、そのような意識が変わってきていると思うが、浸透するにはまだまだかかるはずだ。
根本的な解決となると、日本のあり方、教育を変えていく必要が出てくる。一例あげると、新卒一括で学部関係なくなんでもなれることはそもそも間違いなのだ。(自分はその経緯でエンジニアにならせてもらったことは棚にあげる)
http://anond.hatelabo.jp/20161222124531
やってみたぜ。
諸々引かれて手取りは16万円
家は、郊外に敷地1000平米、住居部分は250平米の5LDKでプール付き
車で通勤30分で、毎日10時に出て19時には帰ってくる感じ。
帰って子供の面倒とか家事をやって、22時から26時くらいまでプログラム書いたり
アラフォーで、フロントからバックエンド、iOSアプリ、Androidアプリまで一通りやってる感じ
マネージメントはやらないって言ってるからこれ以上給料は上がらないかなぁ。
# 以下24日に追記
確かに貯金はしてないね。リアルに月末に貯金額0になる生活だわ。
ただ、医療費用はほとんど無料、学費は日本で言う小中高は無料、幼稚園は二人で5千円位
車とかまとまった金が必要な時は、toptalって言うまぁクラウドワークスみたいなサービス使って
副業で金を調達してるわ。その時は人月6千ドルで請ける上に、毎月末に請求、支払サイト10日みたいな感じだから
一ヶ月半以内に６0万円くらいは調達できる。実質一日2,3時間しか働かないけどまぁコード書くのは速いから
今まで文句言われたこと無い。
ただガンガン働いてガンガン稼ぐスタイルは嫌いだから、余りやらないけどね。
そろそろ４０で失業したら人生詰むけど、英語と現地語と日本語喋れて、プログラミングも大体最近の流行追ってるし、
githubにはスターが1000くらい付いたライブラリ公開してるし、まぁこれで食いっぱぐれる事は無いっしょ。
家の掃除は、オープンな感じで家具をぐちゃぐちゃ置いていないから楽だなぁ。
庭の落ち葉は超大変だった。
まぁシリコンバレーとか憧れるけど、プログラマーならこういう人生もありまっせ！
１２、３年前まで東京で働いてたけど、最近は大分改善されたことを祈るわ。まじであの始発の電車みて
一歩踏み出せば楽になれるかなぁってぼんやり思ってた時期は辛かった。
あとまぁ美人は多いね。うちの会社はオタクばっかりだから縁はないけどな。
プログラマーは多分外国で美女と知り合うとかそういう期待は諦めたほうが良い
