  |
はてなキーワード: PaaSとは
まずIaaS基盤ではない、PaaS実装のためについでで実装されてるだけ
PaaS基盤展開にARMを使うのでそのためにIaaS機能も開放されているにすぎない。
・PaaSメインで使いたい
→ Azure Pack (似たような事はできるけど今後の機能拡張があまり期待できない)
・IaaSメインで使いたい
→ Azure Stack (まちがい)
少なくともWindows Server 2016で実装される各種機能使いたいならAzure Stackは現状無理なので諦めましょう。
Azure のPaaS系機能を使いたいと思うならAzure Stack一択、現状実装されてなくても今後の拡張で実装される可能性は高い。
そもそも的な話すると今後発表されるというCPS的HWじゃないと正式リリース版はサポートされないという事なので、新規HW購入必須です。
この記事を読んだ。
http://anond.hatelabo.jp/20160619185731
元COBOLエンジニア、現Rubyエンジニアとして増田の記事がどうしても許せなかったので反応してみる。
この記事もこんなタイトルだけど、これもやっぱり主語が大きいと思う。
汎用系の現場でもRubyの現場でも優秀な人はたくさんいたし。
今では信じられないほどの経験を当時（といっても2年前）はしていた。
改めて今、RubyというかRailsを始めてよかったなーと思う。
いやー、これが一番ひどかったな。
まず静的デバッグ（机上デバッグ）といってコンペアファイル、ソースコード、コンパイルログをそれぞれ紙出しして提出用（クライアント）、リーダー、上司用の3部印刷する。
全てマーカーを塗った後に赤入れする為にそれぞれ分けるんだ。
そしてインデントもレビュー指摘項目なんだけど、紙出しされたもののインデントが正しいかチェックするんだよ。
定規で計るんだよ。半角スペースが5ミリだったっけな。
それで5ミリずれてたら指摘するんだよ。目がつかれたよね。
っていうか品質に対する意識は今のほうがよっぽど高いし効率的だよ。
これもびっくりだよね。
専属の社員がいた。SIerなんて人を突っ込んだもの勝ちだから、上手いこと言って検証要員とかいって突っ込んだんだろうね。
ダンプがだいたい1時間くらいかけて出てくるから、それを裁断してホッチキス留めしてマーカー。
ネットは使えない。現場に入る時も持ち物チェックとかあるしな。
常に貸し出し台帳は予約で埋まっていたな。やっと借りれたのは現場離れる1週間前だったなんてこともあった。
まだまだあるんだけど、これだけでもひどい現場だったなーって思う。
そもそも設計→開発→レビュー→手戻り→設計→開発...のループだったから前に進めてないし。
Gemとか外部のコードを信じきるとか、もちろん質の低いRubyエンジニアというか現場はあると思う。
この先もっともっとブラックボックスなフレームワークを使うようになるかもしれないし、環境も何もかも全部おまかせでPaaSが主流になるかもしれない。
普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。
ソフトウェアを自社開発していて、顧客自身がWebアプリケーションを作れるようなマルチテナントサービスを提供しています。
とある機能設計でCTOが「コレ出来るよね？」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、
別の部署の部下がちゃんと理由((CTOには言葉の意味すらわかってなかったらしい))を説明して何度も断ってたのに、
無関係なうちの部長が呼び出されて「出来るよね？」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。
彼自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当の開発者たち。
社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署に所属しているわけでもなく、
最近の方向性や技術動向に関しては全然理解していないにも関わらず。
普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。
自分が板挟みになりそうなら部下を責める。あなたの意図はどこ？
思考停止と思えるほどに「今までもこうやって来たんだし」がバンバン口から出てくる。
それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。
そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。
たった４人の小さい部署だから毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、
彼以外の３人がミドルウェアやフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社の規則に関する話が出てくるようになって、
最終的に「忙しいから」というよくわからない理由で勉強会が消えた。
３人共「楽しかったのになぁ」って口を揃えたんだけどね。
部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。
僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д｀)ﾊｧ…」とか言ってたくせにCTOの前ではハハハと笑っている。
以前指摘したけど、彼は新製品に関するプロダクトマネジメントやステークホルダーの立場ではなく、あくまで開発者らしい。
じゃあ誰が責任者でステークホルダーなんだよと思ったけど、そんなものは既存製品にもいなかった。
おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。
基本的に技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。
バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。
でもそれでCTOっぽく技術をリードしていると思っているらしい。
その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。
社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。
来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。
目の前の利益にはすぐ食いつく。
「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズが必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。
サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。
うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。
そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者や運用者、更には顧客への次の担当者を苦しめる。
現行製品の仕様を切り替えた時にカスタマイズで問題が起こったおかげで製品の仕様にカスタマイズを考慮したあれやこれやを要求されてがんじがらめ。
ちなみに、コレよりひどい自称元SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから、
突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。
もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守・運用は彼の仕事じゃないしね。
CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分の理解の範囲内に収めるべく発言しまくるし、
新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの？」で畳み掛けてくる。
もちろんそれを聞いた部長は「そうですよね。それも必要ですよね！」って援護してきて考えてきた設計がことごとく旧製品になっていく。
どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。
そんなもん誰が使うんだろうねぇ。
「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。
最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。
そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、
それすら新しい案件で潰されていくことだろう。
当初は「お客さんにはあくまで実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、
今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。
まともなデバッグシステムやエディタを使わずに果たしてユーザはPHPコードを書いて開発をするだろうか？もちろん、否。
お客さんから依頼を受けたら営業担当者が四苦八苦しながら開発代行を行い納品する。
それでも難しい場合、パートナー企業に依頼をして開発をしてもらい、納品する。
そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの？」と迷うレベルだし、
想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから、
どれが正しい仕様なのかすら不明瞭になっている。
Javaってオブジェクト指向のプログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの？って状態。
クラスがただの関数置き場になっててメンバー変数をいじるもんだから、副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。
それを避けるにはどうするか？もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。
とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。
もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。
あちこちにDBコネクションとか埋め込んであって都度データ取得するから小さなコードでも動作するにはDBコネクションが必要なんだ。
僕は新卒メンバーには「会社内の書き方は（どの会社でもそうだけど、ここは特に）独自のやり方だから、コレが正しいと思わないように。
今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身で勉強するんだよ。」と言っておいた。
Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。
自分の部署の立場を守る発言は多いけど、１年後２年後３年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。
未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。
製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、
役員会でCTOが勝手に「仕様検討にかかった時間が負債になった」と報告したらしい。
「なにより、こんなことで諦める俺が憎い！」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。
誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端。
運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端。
そういった点は大変に申し訳ない。
でも、今のまま居たって僕に未来はない。
こんなところでこんなグチグチ言ってちゃダメなんだ。
だから、ゴメン！
Pixearch(ピクサーチ)
node.jsとMongoDBの勉強がてらpixivの画像のタグ検索のサービスを作りました。
はてブのタグ検索のようにpixivに投稿された最近の画像をpixiv内でのブックマーク数でフィルタをかけて検索できるのが特徴です。
検索したり、タグをたどって、ダラダラと良い絵を眺めるのを目的としています。
普段はブログを書いたりしてないので、今回学んだことのメモがてらの投稿です。
MongoDBを試そうと思ったのがサービスを作り始めた発端です。
Web部分はmongoDBと相性が良さそうなnode.jsを採用。
MVCのフレームワークで何か適当なものはないかとググってSails.jsが良さそうだったので今回採用しました。
今回はせっかくnode.jsを採用したので、噂のnode.jsのPaaSのnodejitsuを試しに使っています。
500MB分の容量のMongoDBを最初から使えるのも大きかったです。
とりあえず最小のプランにしてるのでどのくらい捌けるのか気になるところ。
Web開発用のモジュールを自分で用意するのがめんどいなー、という人向けな印象。
このくらいの規模のものだったらサクッと作れました。
ただある程度の規模のちゃんとしたサービスを作るのには色々足りてないので、自分でカスタマイズしたりできる人じゃないと使うのは辛そうです。
後、ドキュメントも公式のものだけだと説明されてない機能が結構あったりします。
デフォルトだとDBはMySQLに対応していて、MongoDBを使うにはsails-mongoを入れる必要がありました。
開発中に困ったことは、nodejitsuで動かそうとしてsails-mongoでエラーが出て、調べてみたらauthenticationに対応していないというバグがあったことでした。
手元で直したのでpull requestを送ろうかと思ったら既に他の人が送っていて、3日前ぐらいに取り込まれているので今は大丈夫なはず。
https://github.com/balderdashy/sails-mongo/pull/36
現在進行形で色々Issueが上がって修正がされているのでそのうちこなれてくるのに期待。
細かいところで設計や考慮がちゃんとされてるなーと感じたところも多かったので、node.jsで開発してる人は一回試してみると勉強になりそうです。
最初にコレクションの操作に戸惑ったのですが、結局JSの連想配列なので思ったより早く馴染みました。
$setとか$gteとか特殊な意味を持つキーがいくつかあるので、その辺を把握できてから色々と捗りました。
MySQLに比べて特に更新系で複雑なクエリが発行できるので、ORMで使うと十全に機能を発揮できないのではないかな、と思ったり。
ご存知スキーマレスなので、何も考えずにデータを突っ込んでるとIntegerで保存したい値がStringになっててソートのときに困ったりするので要注意。
指定した容量を超えたら自動で消してくれるCapped Collectionがあると知ったので、今回みたいな容量が限られてる場合に便利かなと試してみたのですが、このオプションを有効にしたコレクションだとデータのアップデートや削除ができなくなりました。
おそらく、追加しかしないログのようなデータの保存に使うもののようです。
まだ微妙な部分も多かったですが、デプロイとかコマンド一発でできて、設定管理がpackage.jsonでできたりして面白かったです。
今回は、特に問題が起きたときに環境にsshで入ったりできないので、表示されてるログだけで問題を調査するのに苦労しました。
MongoLabとMongoHQというMongoDBの外部ホスティングサービスが上述したように使えるのですが、無料の容量を超えて使うにはそこそこお金が掛かるのでモリモリ容量を使うものを考えている場合は注意がいります。（もちろん値段に見合ったプロダクトを提供してくれると思いますが）
ということで、せっかく作ったので是非試してみてください。
