「ミドルウェア」を含む日記 RSS

はてなキーワード: ミドルウェアとは

2017-12-31

きれいなコードを書くのはやめた

きれいなコードを書け。コミットは細かく、メッセージをちゃんと書け。

そうずっと教えられてきたし努力してきた。

でも、もうきれいなコードを書くのはやめることにした。


業界2位のミドルウェアが、、1990年代タイムスリップたかのような継承拒否した継承構造で書かれていた。

世界的なOSSで3桁や4桁のスターがついているリポジトリコードは、コピペの嵐。巨大なマージコミットやFワード入りのコミットメッセージ

有名なスタートアップCTOコードは、メタプログラミング黒魔術の塊だった。

リードプログラマの同僚が、素早い機能追加で顧客から高く評価されている。

でも、それはコピペまみれで、巨大のコミットの汚いコードからできる。

自分バグのないきれいなコードを書くように心がけている。

同僚にくらべて、実装は遅い。そのことを叱責ばかりされる。


優秀なプログラマは、自分は quick and dirty なコードをかくくせに、 他人にはきれいなコード要求する。

ダブルスタンダードだ。

他人きれいなコード要求するのは、他人コードを読む時間を短くするためなのだろう。


優秀なプログラマになるために、私もきれいなコードをかくのはやめにすることにした。

2017-12-21

バグばっかりだったあのゲームの思い出

きららファンタジアというスマホゲーで何か大きな問題が起こって大騒ぎになっているというのは Twitter自分タイムラインにちらほらと出てきていたので「そうなんだー」程度の認識だったのだけれど、その炎上のまとめと考察(https://smhn.info/201712-kirara-fantasia-cheat)を読む機会があってなるほどこれは大変な問題ですね、と思った。

それで僕は、サービスインからサービス終了までをほぼ全て見守ってきたあのゲームの事を久しぶりに思い出したので懐かしい思い出としてここに書き記しておこうと思う。

そのゲーム、仮にスキマとしよう。そのスキマはスマホゲーによくある隙間の時間を埋められるようなデザインをされたゲームで、大まかにいうと冒険者を組織してダンジョンへと冒険に出かけさせ、持ち帰った財宝を使って冒険者を強化して、また冒険に出かけさせるというサイクルのゲームなのだが、冒険中はユーザ特にすることがなくただ待っているだけという、冒険者を送り出して帰ってきたのを確認するだけの作業をその隙間の時間にやってね、というゲームだった。なお、スキマは単発のゲームというよりは、はるか昔のパソコンで動いていたゲームを始祖とする名のあるタイトル(仮にウィリーとしよう)を冠したゲームで、ルネサンスと名付けられたウィリーブランド再生プロジェクトのうちの一つであった。僕はそのウィリーが好きだったのでとりあえず遊んでみようとダウンロードしたのであった。

サービスイン直後に一ヶ月メンテ

まず、スキマのサービスイン直後だが、オンラインゲーの例に漏れサービスイン直後に色々な問題を起こしてメンテにつぐメンテでまともに遊べる状態ではなかった。だいたい4,5日はメンテをしたり、たまにサービスしていたり、という感じだったのではないかと思う。そのサービスインから4,5日経ったあたりで、「このままでは安定したサービスが続けられないので長期メンテナンスに入る」といった感じのアナウンスと共に、メンテナンスに入った。このメンテナンスは一ヶ月とちょっとの間続いた。僕はサービスイン初日にはプレイできず長期メンテナンスに入る前に少し遊んだ程度だったのだが、遊んでみた所では「これは酷い」としか言いようがなかった。

まず動作もっさりとしている。何かのボタンを押すたびに CONNECTING… というダイアログが出て2秒位は待たされる。場合によってはボタンを3,4回押さないと目的の事ができないのに押すたびに CONNECTING… なのである。次にタップに反応しない。ボタンを押すと書いたが押したつもりが押されていない事がしばしばある。この場合は CONNECTING… が出ないのでわかるのかと思いきや、1秒位経ってから CONNECTING… と出てあぁ、押していたのか、とわかったりするようなもっさり具合である(もちろん押していなかった時もあるので1秒後までは押せたか押せなかったを判別できなかったりする)。

また、バグと言っていいであろう謎の動作が多い。ダンジョンに送り出したパーティダンジョン内部での行動がダンジョンログとして閲覧できるようになっており、そのダンジョンログは直前の3回までのログが観られるようになっているのだが、そのダンジョンログの表示される内容が複数が同じものになっていて実質的には3回のログはみられないであるとか、CONNECTING… が出るタイミングで他の部分をタップしてしまうと高確率アプリが落ちるであるとか、特定の順番で装備している武器を変更すると攻撃力が最低値に固定されるであるとか、リリース記念かなにかで貰えるキャラがなぜか毎日もらえて同じキャラが増えていくであるとか、まぁ色々な問題があって面食らったものである

そんな感じでサービスインを迎えたスキマなのであるが、こんなに酷い状態なのではユーザはどんな事を言っているのだろうとコミュニティを探した所、2chスレッドが立っていた。案の定スキマのバグ報告スレと化しており、「あぁ、このゲームは本当に全然駄目なんだな」とほっとしたのを覚えている。僕はその頃からその2chスレッドを眺めるようになった。また、こんな状態ではサービスが続けられないのはわかるけれど、一ヶ月程度のメンテナンスでなんとかなるものでもないだろうとも思ったので、せっかくなのでサービス終了まで看取ると面白いのではないかとも考えた。

サービス再開後も問題改善せず

一ヶ月と少し経った頃、スキマのサービスが再開された。まぁ残念ながら僕の予想は外れておらず、お世辞にもちゃんと遊べるとは言えない状態であった。とはいえ、本来は一回しか貰えないはずのキャラ複数回貰えるであるかいった所に代表されるゲームとして守られるべきルールのようなものについてのバグの多くは直っており、残っている問題の多くはクライアントアプリ側の問題サーバ側の負荷対策ができていない問題とみられ、クライアントアプリ側の問題特定操作をしなければ落ちはしないしサーバ側の問題もっさりだけれど待てば処理はしてくれるので一応遊べないことはない状態だとは言えた。それでも、クライアントアプリ側でのUI不思議動作(押してるつもりでも押せていない、連打するとクラッシュ)に誘発されたと考えられる進行不能バグ代表とする理不尽問題は沢山残っており、ユーザとしては不満が渦巻いていた。

そんなスキマではあるのだが、サービス再開の後はウィリーでは有名な人の名前を冠したイベントを行ったり、定期的に期間限定ダンジョンオープンしたりといった運営を行っていた。もちろんバグはじんわりと直ってはいくのだが、特に劇的な直り方はせず、「俺サービス開始直後からログインできなくなっててまだログインできないんだけど」みたいな事を報告するユーザ(?)も2chでは散見されるという状態で、2chスレッドは「スキマのバグを踏まないようにプレイするにはどうすれば良いのか」という情報を交換するための機能果たしていた。

開発会社の変更

一ヶ月メンテからサービス再開から3,4ヶ月経った頃、運営会社から開発会社の変更が発表された。曰く、外部の開発会社制作を依頼して制作したのだが、不都合が多すぎてどうしようもないので開発を自社に引き取るということであった。その後一ヶ月程して「不都合収束クライアント」と銘打ったクライアントが配布される。この不都合収束クライアントで確かにいくつかのバグ修正されはしたのだが、もっさりとした動作が変わるわけではなく(プロトコルサーバ側も修正されていないようであったので当然ではある)、操作によってはクライアント強制終了していたのが強制終了はしなくなった、程度の修正であり、これを解決するには根本的な改革必要であるとみてとれた。

サービス開始1周年

そんなスキマではあったが、何故かサービスは終了せず、サービス1周年の時を迎えた。この時、スキマの開発体制についての発表もあった。現在のスキマのクライアントプログラムは改修を重ねていくが、それと平行して開発ミドルウェアを変更してフルスクラッチクライアントを作り直している、という発表であった。2chスレッドではフルスクラッチクライアントを書き直すということで、バグの根治は当然として、目的の事を行うのに3〜4タップ必要であったりするというUI周りまで手がつけられるのではないか、という事を期待する声が上がったりもした。

また、この1周年挨拶の3ヶ月後には新クライアントの開発状況は70%と発表された。

この頃からであろうか、僕が遊んでいる環境のみなのか、又は他の人ではあまり現れない問題であったのか、とにかく僕が遊んでいる環境では冒険からの帰還を行おうとすると変に時間がかかるようになった。この問題は何らかの原因で帰還操作完了するまでの時間が少しづつ伸びていくという問題であった。この問題は後で僕には大きな問題として認識されるようになる。

この頃からは新クライアントを開発しているためなのか、旧クライアント修正はあまり行われなくなり、定期的なイベントが行われるのみであった。思えばこの頃はスキマの遊び方(このようにするとバグを踏むのでこれはしない、であるかいった遊ぶための作法)がわかっている人間しかスキマを遊んでおらず、運営側積極的には宣伝もしていないため新しいユーザも増えなかったため、比較的安定した運営が行われていたのではないかと思われる。

また、恐らくこの頃であると思われるが、2chスレッドで「スキマは冒険者が冒険をしてきたログを眺めることでそのダンジョン攻略法を考えたりするゲームなんだけど、あまりにもバグが多すぎるから2chというログを読む事でスキマというゲーム攻略しているよね」といった書き込みが行われるなど、スキマをダンジョン攻略ゲーとして捉えるのではなく、バグ攻略ゲーとして捉えるというユーザが現れていた。

期待はずれの新クライアント

さて、一周年の時に発表された新クライアント開発は、その後3ヶ月程で70%まで出来ていると発表されたが、結局その新クライアントがお目見えしたのは2周年を目前に控えた頃であった。新クライアントのお披露目はAndroidβテストという形で行われた。言い忘れていたがスキマはiOSしかサービスされておらず、それまでAndroid版は存在しなかった。僕はAndroidiOSも持っていたため、βテストに応募し、当選したので遊んでみたのである

まず、フルスクラッチ制作されると言われていたのでUI周りも変わるのであろうと思っていたのは完全に裏切られた。見た目はほとんど何も変わらず、もちろんUIタップ回数まで全く同じであった。しか使用されているフォントが違うために文字が見切れていたりといった問題が発生しており、お世辞にも前のクライアントとくらべて良くなったとは言えなかった。また、恐らくはサーバクライアント間のプロトコルも何も変わっていないのか、プロトコルサーバ側に起因する問題は依然として残っていた(武器や防具を鍛錬すると+の数値が上がるという仕様があるのだが、連続して鍛錬を行うと必ず1以上は上がるはずの鍛錬値が上がらなかったり下がったりするといった問題は残っていた)。また、動作iOS版と比べるともっさりとした感じが強く、何のために作り直したのかわからないという感想であった。2chスレッドの中ではこの新クライアントは単に今までの旧クライアントAndroid移植したものであり、本物の新クライアントはまだ開発中なのだと言って聞かない人が長いこと存在した程である

その後、βテストでお披露目された新クライアントは3ヶ月後にAndroidリリースされ、その後さらに3ヶ月後にiOSでも新クライアントリリースされた。

クライアントで新たに現れる問題の山

鳴り物入りで導入された新クライアントであるが、先程も書いたように、旧クライアントと比べると確かに解決された部分もあるが、サーバ側が関わる問題は全く同じ問題を抱えており、新クライアント特有問題が多く発見され、実質的には旧クライアントの方がバグが少ないという状態であった。

僕はβテスト以降は特にAndroid版で遊ぼうとはしていなかったため、新クライアントが先行リリースされたAndroid版を遊んでいた人達を眺めていたのだが、Android版で起こっていると2chで報告されている問題がそのままiOS版でも起こるとなると大変だと思って眺めている位には、Android版は阿鼻叫喚の様を呈していた。iOS版での新クライアントリリースは3ヶ月遅れたが、この間Android版は何度もなんどもアップデートを繰り返し、その度に少しづバグ修正されていくのをみて戦々恐々としていた。

iOS版の新クライアントリリースされた直後、僕はスキマを遊ぶことができなくなった。これはゲームを起動した後すぐに「通信エラー」が表示されてタイトル画面に戻されるという問題で、これを回避する方法全然からなかったためだ。「あぁ、ログインボーナス貰えてたのがなくなっちゃうなぁ」と思ったのを覚えている。

しかし、この問題については2ch(正確にはTwitter経由であるのでTwitterの誰か)に「お知らせ」をタップしてからだと通信エラーが起こらない、というオカルトじみた書き込みがあり、それを信じてやってみると確かに通信エラーが起こらないということが確認できた。これで僕もスキマをプレイすることができるようになったのである。この時は本当に2chというログを読んでスキマというゲーム攻略している感じがしたものだった。

この時、僕は何故通信エラーが起こるのか、何故「お知らせ」をタップすると通信エラーが起こらないのか、といった事を確認したくなってiOS版の通信を眺めてみることにした。本来であればこのような行為を行うのは自分主義に反するため、それまでは行わなかったのであるが、突然ゲームプレイできなくなるというのは大変衝撃であったので、つい出来心で、という感じで眺めてみたのである

クライアントサーバ間の通信HTTP、つまり平文で行われており簡単通信内容をみることができた。タイトル画面から通信エラーが出るまでの通信内容はだいたい以下のような感じであった。

1. クライアントからユーザ情報送信

2. サーバからセッションキーが送られてくる

3. クライアントから並列で何らかの情報を取得するためのGETリクエスト送信

4. 並列で送られたリクエストへの返信をサーバが返すが、その全てに更新された(別の)セッションキーが入っている

5. ログイン完了してゲーム画面が表示される

6. クライアントで何らかの操作を行おうとしてサーバリクエスト送信

7. 6.のリクエストへの返事が4**でエラー

まり、3. のリクエストが並列で行われ、サーバ更新したセッションキーが 4. でクライアントに届けられるのであるが、恐らくは届いたセッションキー前後してしまうことで壊れてしまったと考えられる。

これが、何故「お知らせ」をタップすると解消するのかであるが、実は「お知らせ」を取得するためのURLhttp://…../login2 というURLへのGETリクエストであり、かつセッションキー必要としておらず、このURLからリクエストの返事にはセッションキーが含まれるという特殊URLであったのだ。つまり本来であれば 5. の状態の時には壊れたセッションキーを保持していたはずが、そこで「お知らせ」をタップすることで新しい(正しい)セッションキーを手にすることができるようになり、その後の通信はちゃんと行えるようになったのである(その後の通信では並列にリクエストを投げるパスは僕の観測した範囲では存在しないように見えた)。

この事に気づいたTwitterの人はどうやって気づいたのかはわからないが、よく見つけてくれたものである。ともかく、僕はこの情報に助けられ、スキマを再開することができた。

長くなったので https://anond.hatelabo.jp/20171221020636 へ続く

2017-11-05

Webフレームワーク選定の悩み

Webアプリを作るとき何を基準にしてプログラム言語Webフレームワークミドルウェアを選定していますか?

RailsCoC:convention over configuration)以外の手法活用して、開発を高速化するにはどうすれば良いでしょうか?

 

希望条件

  1. 素早いプロトタイピングscaffold機能など
  2. テストコスト削減:関数型プログラミングモジュール手法
  3. 性能:コンパイル型の言語

…こういう条件を備えていれば良いかな?

 

フロントエンド

  1. JSGUI作成Vue.js等のSPAフレームワーク

 

バックエンド

  1. データ永続化ストレージCRUD機能を用意できれば何でも良い?

 

試作

  1. Railsプロトタイプを作りデザインスプリント実践

 

本番

  1. 形が決まったらGolangGCPで作り直して本番投入

プロトタイプを作り直す手間を省きたい。プロトタイプと本番を同じツールで作りたい。)

 

サーバーAWSバックエンドElixir/Phoenixフロントエンド:Elmという組合せはあまり盛り上がっていないようなので、Rails代替手段は何が良いのか?気になります

2017-10-12

プログラミング界隈で言語フレームワークミドルウェアの移り変わりについていかなきゃいけないつらさなんて話はよくあるが

デザインとかその他表現そもそも表現に限らずなんだって流行り廃りはあるから

そこで生き残ってる人は結局アップデートしてんだよな

2017-09-11

https://anond.hatelabo.jp/20170910205249

まじな話をすると、N予備校プログラミング入門コースやるのがオススメ

https://www.nnn.ed.nico

一日8時間勉強時間があるなら、だいたい一ヶ月で終わる内容。

月額1000円だけどしっかり勉強すれば一ヶ月の無料間中に終わると思う。

もともとN高等学校のノンプログラマーの生徒をWebエンジニアとして就職させるために作られたカリキュラム講師曰く去年はこれで二人エンジニア就職を決めたらしい。

内容も相当親切に説明していて、プログラミングで何か作るだけじゃなくて、就職必要な環境構築やセキュリティまでみっちりやる。

http://qiita.com/sifue/items/7e7c7867b64ce9742aee#%E3%82%B3%E3%83%B3%E3%82%BB%E3%83%97%E3%83%88%E3%82%92%E3%82%82%E3%81%A8%E3%81%AB%E6%A7%8B%E6%88%90%E3%81%95%E3%82%8C%E3%81%9F%E3%82%B3%E3%83%BC%E3%82%B9%E3%81%A8%E5%86%85%E5%AE%B9

講師が書いてる入門コースで習うことがまとめ。テキスト教材もあるけど授業も1項目を2時間で説明している。授業は週2の生放送とそのアーカイブがある。

↓みたいなことが学べる

----

Webプログラミング入門コース

Web ブラウザとは (Chrome, デベロッパーコンソール, alert)

はじめてのHTML (VSCode, HTML, Emmet)

さまざまなHTMLタグ (h, p, a, img, ul, tableタグ)

HTMLで作る自己紹介ページ (HTMLタグ組み合わせ, コンテンツ埋め込み)

はじめてのJavaScript (JS, ES6, エラー)

JavaScriptでの計算 (値, 算術演算子, 変数, 代入)

JavaScript論理を扱う (論理値, 論理積, 論理和, 否定, 比較演算子, if)

JavaScriptループ (ループ, for)

JavaScriptコレクション (コレクション, 配列, 添字, undefined)

JavaScript関数 (関数, 関数宣言, 引数, 戻り値, 関数呼び出し, 再帰)

JavaScriptオブジェクト (オブジェクト, モデリング, プロパティ, 要件定義)

はじめてのCSS (CSS, セレクタ, background-color, border)

CSSを使ったプログラミング (transform, id, class)

Webページの企画とデザイン (企画, 要件定義, モックアップ, 16進数カラーコード)

診断機能の開発 (const, let, JSDoc, インタフェース, 正規表現, テストコード)

診断機能組込み (div, 無名関数, アロー関数, ガード句, truthy, falsy)

ツイート機能の開発 (リバースエンジニアリング, URI, URL, URIエンコード)

Linux開発環境構築コース

LinuxというOS (VirtualBox, Vagrant, Ubuntuインストール, OS, CUIの大切さ)

コンピューター構成要素 (ノイマンコンピューター, プロセス, lshw, man, ps, dfの使い方)

ファイル操作 (pwd, ls, cd, mkdir, rm, cp, mv, find, ホストマシンとの共有ディレクトリ)

標準出力 (標準入力標準出力標準エラー出力パイプgrep)

vi (vimtutor)

シェルプログラミング (シバン, echo, read, 変数, if)

通信ネットワーク (パケット, tcpdump, IPアドレス, TCP, ルーター, ping)

サーバークライアント (tmux, nc, telnet)

HTTP通信 (http, https, DNS, hostsファイル, ポートフォワーディング)

通信をするボットの開発 (cron, ログ収集)

GitHubウェブサイトの公開 (GitHub, リポジトリ, fork, commit, 情報モラル)

イシュー管理とWikiによるドキュメント作成 (Issues, Wiki)

GitとGitHub連携 (git, ssh, clone, pull)

GitHubへのpush (init, add, status, インデックス, commit, push, tag)

Gitのブランチ (branch, checkout, merge, gh-pages)

ソーシャルコーディング (コンフリクト、プルリクエスト)

Webアプリ基礎コース

Node.js (Node.js, nodebrew, Linux, REPL, コマンドライン引数, プルリク課題)

集計処理を行うプログラム (集計, 人口動態CSV, Stream, for-of, 連想配列Map, map関数)

アルゴリズムの改善 (アルゴリズム, フィボナッチ数列, 再帰, time, プロファイル, nodegrind, O記法, メモ化)

ライブラリ (ライブラリ, パッケージマネージャー, npm)

Slackボット開発 (slack, mention, bot)

HubotとSlackアダプタ (hubot, yo)

モジュール化された処理 CRUD, オブジェクトライフサイクル, filter)

ボットインタフェースとの連携 (モジュールのつなぎ込み, trim, join)

同期I/Oと非同期I/O (同期I/O, 非同期I/O, ブロッキング)

例外処理 (try, catch, finally, throw)

HTTPサーバー (Web, TCPとUDP, Webサーバーの仕組み, Node.jsイベントループ, リスナー)

ログ (ログ, ログレベル)

HTTPのメソッド (メソッド, GET, POST, PUT, DELETE, CRUDとの対応)

HTMLフォーム (フォームの仕組み, form, input)

テンプレートエンジン (テンプレートエンジン, jade)

HerokuWebサービスを公開 (Webサービスの公開, heroku, dyno, toolbelt, login, create, logs)

認証利用者を制限する (認証, Basic認証, Authorizationヘッダ, ステータスコード)

Cookie を使った秘密匿名掲示板 (Cookie, Set-Cookie, expire)

UI、URI、モジュール設計 (モジュール設計, フォームメソッド制限, リダイレクト, 302)

フォームによる投稿機能の実装 (モジュール性, textarea, 303)

認証された投稿の一覧表示機能 (パスワードの平文管理の問題, 404, テンプレートのeach-in)

データベースへの保存機能の実装 (データベース, PostgreSQL, 主キー)

トラッキングCookieの実装 (トラッキング Cookie, IDの偽装, Cookie の削除)

削除機能の実装 (データベースを利用した削除処理, 認可, サーバーサイドでの認可)

管理者機能の実装 (Web サービス管理責任, 管理者機能の重要性)

デザインの改善 (Bootstrap, レスポンシブデザイン, セキュリティの問題があるサイトを公開しない)

脆弱性 (脆弱性, 脆弱性で生まれる損失, 個人情報保護法, OS コマンド・インジェクション)

XSS脆弱性対策 (XSS, 適切なエスケープ処理, リグレッション)

パスワード脆弱性対策(ハッシュ関数, メッセージダイジェスト, 不正アクセス禁止法, パスワードジェネレーター, 辞書攻撃)

セッション固定化攻撃脆弱性対策 (セッション, セッション固定化攻撃, ハッシュ値による正当性チェック)

より強固なセッション管理 (推測しづらいセッション識別子, 秘密鍵)

CSRF脆弱性対策 (CSRF, ワンタイムトークン)

安全なHerokuへの公開 (脆弱性に対する考え方, HTTPの廃止)

Webアプリ応用コース

Webフレームワーク (Express.js, フレームワーク導入, 簡単なAPI, セキュリティアップデート, Cookie パーサー, ミドルウェア, 外部認証, ロガー)

ExpressのAPI (app, Properties, Request, Response, Router)

GitHubを使った外部認証 (Passport, OAuth)

スティングフレームワーク (Mocha, レッド, グリーン, リファクタリング)

継続的インテグレーション (CircleCI)

クライアントフレームワーク (Webpack, Chrome 以外のブラウザでもES6)

DOM操作フレームワーク (jQuery, jQueryアニメーション, this)

AJAX (jQuery.ajax, クロスドメイン, 同一生成元ポリシー, x-requested-by, CORS)

WebSocket (WebSocket, WebSocketの状態遷移, Socket.io)

RDBとSQL (DDL, DCL, CREATE, DROP, INSERT, DELETE, UPDATE, WHERE)

データモデリング (リレーショナルモデル, 正規化)

テーブルの結合 (外部結合, 内部結合, 片側外部結合, JOIN ON)

インデックス (インデックス, 複合インデックス, Bツリー)

集計とソート (SUM, COUNT, ORDER BY, GROUP BY)

「予定調整くん」の設計 (要件定義、用語集、データモデル、URL設計モジュール設計、MVC)

認証とRouterモジュールの実装 (Mocha, supertest, passport-stub, モックテスト)

予定とユーザーの保存 (セキュリティ要件, UUID, 複合主キー)

予定とユーザーの一覧の表示 (非同期処理, Promise, then)

出欠とコメントの表示 (入れ子の連想配列, Promise.all, 子どもからデータを消す)

出欠とコメント更新 (Promiseチェイン, リファクタリング)

予定の編集と削除 (要件の衝突, 関数再利用)

デザインの改善 (this, グローバルオブジェクト)

セキュリティ対策と公開 (X-Frame-Options, Heroku環境変数)

2017-06-27

anond:20170627155813

スクリプト言語楽しいと思う人はアプリ寄りのことをしたいんだろうから

大学にいる間はまぁ我慢しておくんだな。

大学じゃアプリ開発なんて教えてくれないし、教えることができない。

情報系の学部で C を教えない方がおかしいだろう。

君たち大学生は将来コンパイラを書くかもしれないしOSミドルウェアの開発を

期待されてるんだよ。アプリ屋になることなど期待されてない。

2017-05-20

大企業に隠れているすごいエンジニア

paizaを始めとしたSIerDisで大企業(日系)にはロクなエンジニアがいないと思われてるっぽいけどいるとこにはいるんですよ。

知ってる人を紹介。

意識の高い大学生新入社員はこのあたりを目指すとみんなから尊敬されるぞ!



外部に出してる情報は少ないね

がんばって配属してもらおう。

2017-05-06

しかプログラミング一つにしても業界によって必要スキルは異なるわけだし、

Web系ならScala,JS,Ruby,ミドルウェアならC++,Java,システムならJava,分析ならPython,Ruby…)

会社必要になる知識漏れなく教えるなんてことは無理だと思う。

2017-05-05

http://anond.hatelabo.jp/20170504083902

エンジニアリング勘違いしてる人がときどきいるけど、エンジニアリングってのは工場を作ることであって、ライン工になることではない。

ソフトウェアエンジニアリングにおいてファクトリーはフレームワーク(あるいはミドルウェア)である

大企業においてフレームワーク(ミドルウェア)を作る仕事は専用の部署があり、名だたるOSSコミッタなど一流のプログラマーが在籍している。

2017-04-24

攻殻機動隊日本産業を後押ししてる

自分の周りの機械系やミドルウェア系の若い技術者の中には攻殻機動隊を見て今の道を目指したと言っている人が多い。

そういう意味で言えば攻殻機動隊日本産業を後押ししていると言える。

もう少し一般化して言うと、SF作品の持つ役割は思った以上に大きいのかもしれない。

小説でもアニメでもゲームでも面白いSF作品が生まれることを切に願う。

個人的には最近ではサイコパスが超面白かった。

2017-04-06

wordpress高速化が楽しくなってきた。

VPSミドルウェアwebサーバを変えたり、Mysqlチューニングやらなんやらで高速化してるんだけど

gtmetrix.comでハイスコアが出るとうれしい!ゲーム好きな人気持ちがなんとなくわかった。

でも、wordpressに書く記事がない。

高速化の経緯を記事にすればいいのかもしれないけどそっちにはあまり興味がない。

チューニングカーの同好会みたいなwordpress高速化同好会いかな?

2017-03-15

毎朝ぎりぎり出社の運用エンジニアです

今日会社障害対応

最近やっているプロジェクトはつまらない。

今やっている仕事の50%は運用プロジェクト関係

運用なので実装や開発ということもなく、何かシステム修正があればテスト、というような感じ。

障害も頻発するわけではないがそれでもつらい。

先輩はいい人で色々教えてくれるので、勉強になるからその点はうれしいのだけれど、

やっぱり運用プロジェクトというせいかモチベーションが上がらない。

最近は毎朝起きるのも遅い。

乗る電車もいつもぎりぎり間に合う電車

以前は出勤時間の3〜4時間前に起床して、好きなプログラミングをしたり

本を読んだり、ランニングをしたり自由に過ごしていた。

会社にはみんなよりも1時間早く来ていた。

きっとその頃は仕事が楽しかったのだろう。

会社に入ったばかりでやることはどれも新鮮。

少し難しい仕事も任されるようになってきてモチベーションもあったと思う。

仕事楽しいだけでなく充実感があった。

それが今では不思議と朝起きたくないのだ。

起きるのがつらいというか億劫

別に疲れが溜まっているわけではない。

目覚めは悪いどころかいつも目はぱっちりしている。

でも起きれない。ぎりぎりまで布団の中。

そして時間ぎりぎりになると焦燥感を感じつつのっそり布団から起き上がる。

まり憂鬱なのだ会社に行くのが。

この状況を打破するにはたぶん運用プロジェクトをやめるしかないのだろう。

今ではどうせ朝早く起きれないなら深夜までずっと起きていようか、なんて考えている。

会社をやめていく同僚にも言われたが、運用やってるとだれてくるらしい、私生活が。

そういって同僚はフリーランス転職した。

今では職場でも私生活でもいきいきしている。うらやましい限りだ。

自分フリーランスにはなろうとは思わないけども、少なくとも今のプロジェクト半年が限度かなーとは思ってる。

同じ環境にずっと居ても成長できるか不安だし。

それに自分市場価値はどんどん上げたいと思っているし、会社だけでなく会社の外でも評価される人間になりたい。

そういう意味でも今の運用プロジェクトに長く関わるのは、正しい選択ではないように思う。

運用プロジェクトの残念なところは、仕事の大半が顧客対応コミュニケーションコストでつぶれること。

特にお硬いお客さんだと本番作業をする度に、申請書類を書いて作業日の何日か前に提出しなければならないだとか。

障害対応であれば書類に発生日時や発生事象、発生原因、顧客影響、業務影響、対応策、横展開対応、再発防止策、etc..

なんてことをつらつら書かなければいけなかったり。

なにより障害が発生したらものによっては休日にも出勤しなければならないこと。

まぁ自分はその経験はまだ一度もないけども。ただ障害が起きて帰りが遅くなった時は本当に疲れる。

体力には自身があるけども精神的にはわりときます。人によるのかな?

つらつらと運用プロジェクトについてネガティブな事を書いたけども、悪いことばかりではない。

運用プロジェクトでは顧客対応必須だ。なので顧客との話し合いは上手くなる。

あと、運用エンジニアには広範な知識が求められる。

例えばフレームワーク脆弱性が発表されれば、どの程度影響があるのか、どのような対策を取れば十分か、そもそもどんな対策がとれるのか、とか。

ハードウェアミドルウェア障害が起きればそれに対する知識を駆使して対応を行う必要があるし、

ドメインが変わった、IPアドレスが変わった、となればシステム運用保守作業で影響がないか調査する必要がある。

なのでそのような対応を考える機会があるので勉強にはなる。

他にも必要知識として、プログラミング言語SQLはそこそこかけて、DBクライアントLinux操作、その他ミドルウェア知識必要になる。

なので現時点では自分スキルはそこそこ伸びてはいるのかなーとは感じている。

そんなこんなで運用プロジェクトは色々大変だよってことです。

理想運用プロジェクトで吸収できるものは吸収していって、早めに別プロジェクトに移っていきたいですね。

めんどくさいことが多いけどもつまらなすぎて潰れないようにとりあえずがんばります

明日仕事ですね。みなさん一緒にがんばりましょう。

2017-02-26

自動化って

暗黙知をなくす作業でもあるなぁと思った。

Ansibleとかはサーバー構築手順書をなくすことができるし、mavengemなどのパッケージ管理ツールセットアップ手順の暗黙知をなくすことができる(なんのライブラリ入れるーとか)

人にあれこれ聞くより、コード見て大体わかるような感じになっているとすごく助かるんだよなぁ。

もしかしてそういう感じで仕事を続けていけば、英語圏とかでも仕事できるようになるのかなぁ。

vagrant up ← コレだけで開発環境揃う環境、素敵に開発に入りやす

わしが1年1人でやっているやつ、ミドルウェア系には秘伝ミソが少し出来ているから、dockerで全部揃うようにしてみるかなぁ。Solr使っている部分とかしょうがないような気もしつつ、ローカルにあったほうが良いんだろうなぁ。あんま頻繁に開発しないし、そこは自分でやればいいか・・・。まあ多分solrコンテナを立てれば良いんだろう。

2016-10-07

http://anond.hatelabo.jp/20161006152658

元増田程の良い生活は出来てないけど、それなりに良い給料を貰って良い生活が出来ている同じ世代の独り語り。

収入民間給与実態統計とかで上位10%に入るくらい。

自分勉強出来なくて底辺高校出身高卒だけど、同じくラッキーだったりが続いて転職の結果、

年収ランキングに入る一部上場IT企業に中途で入り、今の生活に至る。

インターネット誕生して発展していく時代に生まれたから、ゲームオタクパソコンオタクであることが武器になって、

好きなことを仕事にできる業界に進んだことが大きいとは思う。

(プログラム弄ってたり、適当ミドルウェアを入れて環境を構築したりが遊びになる)

ただ、そうなれたことの一端に

>でもそれも、そんなカードも、両親が必死になって繋いで手渡してくれた大切なカードだった。

これが大きいんだと思う。

親が好きに生きさせてくれたことで今があるんだなぁと言うこと。

思い返せば、小さい頃から勉強ができなくてテレビゲームばっかりやってたけど、親がそれを怒ることは無かった。

怒られることが無いから、勉強別にしなくて良いものと思っていた。授業中は「なんでこんなことしてるんだろ。学校先生ってのはうるさい人だ」位に思っていたと思う。

勿論勉強しなくちゃいけない時期にテレビゲームばっかりやってたから、wikipedia底辺高校と書かれるような高校に入って

名も無き零細ITしか就職できなかったけど、それも自分の行動の結果だから人のせいにしたり後悔するようなことは無かった。

どちらかと言うと大学に行けなかったことで、人より4年早く就職できたことのほうが大きかったと思う。

当時の現場が良かったのもあるけど、単調なコーディングテスト手順書ばかりではなく、いろんなことをやらせてもらえた。

2000年問題の前はまだ中小規模の会社でも元請け結構あって、今みたいに頭数揃えて人海戦術ばかりな業界じゃなかったしね。

エンタープライズIT業界労働集約産業になっていく中、インターネットが発展したくさんの技術が生まれたことで、

オタク知識武器になる時代が続いている。

結果として、少なくとも現時点では学歴が無くても良い生活が送れている。

何か幸せかってのは生きてみなくちゃ分からいね

いい大学に入って良い学歴を持つことは武器にはなるけど、別に成功約束されているわけでは無いので、

生きていく力や生きる目的を探すことも大事時代になってきてるのかなと言うこと。

2016-06-20

だめだ。

仕事中だが、我慢できない。

このくそ素人どもが。何年ITにいるんだよ。

ミドルウェアディレクトリパーミッションときにはまるとか、マジありえない会話が聞こえてきて戦慄している。

2016-05-29

富士通退職した話」に言及とついでに自分の話でも。

自分も前に富士通に居て既に退職してます。後で詳しく書くけど、ソフトウェア開発職に居たです。

富士通を退職した話

彼のへの感想

富士通はクソでっかい会社なんだし、サイト見ればメインフレームやってるのだって判るんだから、開発職を希望したらメインフレーム関連の開発やる可能性あるのは当然予見出来るだろうし、それを想像してなかったのなら情弱とかブコメで言われてしまうよね。あと何も記述が無いか想像だけど、「それほど有能ではない」と判断された可能性もある。と言っても学生が思う「開発者として有能かどうか」ってのと会社でのそれってのは別物で、要するに学生自身自分が実績もあって優秀だと思っても、会社的にはそうでないのよね。そうなると(後述の富士通入社して10年が経った人の話にもあるのだけど)新人能力客観的判断材料って大学資格応用情報レベル以上)程度なのよね。資格に関しても基本情報なんてMARCHクラス以上の人間なら受けたら取れて当然だから、「有能かどうか」の判断材料にならない。就活の際に本気でIT業界に入りたいかどうかの判断材料にはなる程度。自分の同世代富士通本体に入ってソフトウェア開発関連に配属された人のプロフィールを見たけど、確か偏差値的には少なくとも神戸大学とか千葉大学あたりの修士しか居なかった覚えがある。あと確か2~3人がソフ開持ってた気がする。だから、この増田がどの程度だったのかなと。

ただ、20人月案件が具体的に何かは判らないのだけど、自分の在籍していた当時でも炎上巨大案件というのはあって、(自分が知ってるのは確かデジタルテレビがどうのこうのとか言ってた)、そういうのに入社して間もなく入ってしまうと自身勉強等が出来なかったり潰されたり最悪死んだりするんで、そういう意味でも逃げるのは正解の一つ。(自分炎上案件に放り込まれ新人が寮で死んでたとか話を聞いたことある

上司対応はまあこれだけ見ればクソだわな。

富士通を退職して思うこと

はあ、としか。この人がこう判断した際の判断材料にするであろう自己体験を具体的に書いてないので、意識高い系がフカしてるようにしか見えない。あと、たった3年しか居なくてあの巨大企業経営とか体制とか理解出来るんかね?と思わないでもない。自分とは部署が違うだろうから当然かもしれないけど、自分体験とは違うなーって感じ。自分は、外から見たら馬鹿みたいな事やってるように見えるかもしれないけど、経緯や目的巨大企業特有問題があってそうなってるんだなって思う事が多々あった。

富士通に入社して10年が経った - blog

近い時期に入社したと思われる。具体的な話が自分経験と一致してる。特に富士通ソフトウェア開発と言えばミドルウェアの開発が主だというのは、富士通内部じゃないとなかなか(特に学生なんかじゃ)判らないかなと。

それでこれらの話を見てどんな人が富士通(というか大企業)に向くのかなと考えたんだけど、「やりたいこと」そこまで明確じゃないけどコンピュータは嫌いじゃないって感じで、地頭がまあまあ良くて勉強に関しても要領よくやれる(要するにそこそこの大学に行って卒業した人)、それでそこそこ安定した職・収入目当てな人かなと。ってコレ書いててふわふわしてる人みたいであまり良い印象の人物像じゃないな。マッチングミスはどうしても起きると思うし、学生の頃に思う「やりたい事」って往々にして変わったり間違いだったりするし、そもそも学生の頃に明確な「やりたい事」がある人の方が少数派でしょ。だからこういうそこそこ優秀だけどふわふわしてる人の方が良いんじゃないかなとか。逆に、ちゃんと「やりたい事」が明確にあるけどまあ安定はしたいって人はどうしたらいいのかって言うと、自分みたく大企業の子会社を狙うと良いんじゃないかなと。子会社ならその会社がやってる事が理解やすいし、入った後の配属の希望も大きく違ったものにはなりにくいし。まあ子会社子会社で色々アルかもしれないけど。

で、自分入社から退社までの話。

入社10年ぐらい前。入ったのは富士通の子会社で主にミドルウェアの開発をやっている所でした。入社して1~2年したら子会社の統廃合とのことで富士通本体連携してる部署自分がそうだった)は富士通本体になりますとのことで富士通本体の方に移ったという経緯ですね。別に待遇とか元々本体と同じだったから変わらず、事務関連が小回りきかなくなったぐらい。入社してから退職までは5年ぐらいでした。辞めた理由実家事業を継ぐ事にしたため。

入社して数ヶ月の時にある温泉地にある某所でその手の開発をやってる子会社沢山と

富士通本体ソフト開発配属の人達研修をやったのだけど、その際に富士通本体人達と知り合った。(この際に全員のプロフィール冊子が配られた)そのときは流石子会社に入る人達本体とじゃレベルが違うな~と思いましたね。(ちなみに自分MARCHより下の院卒。)

自分が配属されたのは某製品部署API部分チーム。その製品C言語Java言語からも使えるように出入り口を用意する部分。中でやってる事は指定されたIPポートプロトコルに沿ってデータ投げるだけなんだけどね。ちなみに配属希望の際は「そこそこの忙しさの所がイイ」と言っていました。「バリバリに働きたい」と言ってた同期は多忙ヤバい所に配属されてました。他にもチームがいくつかあったけど、それらのうちの一つは例の「山奥の工場」でしたね。自分が配属された当時はC言語APIリニューアルするって開発してたのだけど、設計担当Javaしかやったことない人で色々とC言語流儀に反してて後々のメンテが大変でした。まあそれでもリニューアル前よりは遙かに良くて、以前はユーザに見せてる関数名が ○○search1 ○○search2 ○○search3 とかでしたね(ちなみに機能はそれサーチか?思うのもあった)。もっと酷かったのが初期製品Javaの公開メソッドで、マニュアルには「このメソッド引数○○を□□を指定した場合戻り値Objectを△△にキャストしてください。××を指定場合は…」という「これ製品にして売ってたんだ…」と思うレベル。もちろんコレがダメだったってのは開発側も認識していて当時は既にリニューアル済みだったけど。リニューアル済みでも少し微妙だったけどね。

これは、ミドルウェアの開発をやってる人達って基本的C言語が主でJavaとかをやってる人がほぼ居なかったからだと思う。上司もそういうのは良くないってのは認識してた。対象OSWindowsLinuxSolarisだったけど、そんなにたいした事やってなかったからほぼ同じコードだったような。ソケットの一部だけ違ってたっけかな。

それでそのバージョンの開発が終わったあたりで、.NET Frameworkが出始めてきたので次バージョンでは.NET FrameworkAPIを作る事になりまして、自分が少し勉強していたのでそれの設計から担当する事に。当時は.NET Framework 1.1で今思えば少し時期が早かったと思う。2.0Genericが出てからやった方が良かったと思うんだけど、そういうの政治的判断だし結果論だしなー。それまでにRubyとかオブジェクト指向言語に触れてその辺の勉強もしていたので、.NET用のAPIに関しては設計実装結構良い感じに出来たと思う。ああ、そういえばRuby用のAPI効率化の開発ツールとかの名目仕事中に勝手に作ってたなあ。他にもC言語APIも内部実装がクソすぎ!とキレてユーザ公開関数インターフェースだけ同じで中身をフルスクラッチした事も。もちろん絶対LDしてるんで完全に趣味なんだけどな。これでAPIC言語Java.NETになった訳だけど、現場案件で使われたのってほぼ全てJavaだったと思う。(開発中のサーバテストアプリC言語だけど)。要するに自分が数年関わったコードが世の中ではほぼ使われてない訳でして、取りそろえとして必要だったとはいえ世の中の役に立ってないってのは嬉しくは無かったですね。まあ、大企業仕事なんてそういうもんです。.NETに関してはそのバージョンが出る頃はその製品があまり売れてなかったんだか使われたって話は聞かなかったですね。ほほほ。大企業に勤めるのならこういう覚悟必要かもね。

で、.NETAPIが出来たあたりに開発ネタがなくなって保守気味になってきたので、人員整理作業整理との事でインストーラと切りたいけど一度やったからには切れない補助製品担当が増える事に。インストーラWindowsがInstallShieldというクソみたいな言語上で作られたものLinuxSolarisシェルスクリプトのもので、InsallShieldの方のコードはあまりにクソなのでリファクタリングさせてもらった。この辺の開発は少なかったのだけど新OS対応(Vistaとか)とか保守作業が大変だった覚えある。

んで、これらの作業が終わったあたりでこの製品でやることが無くなってきたのと同時に、この製品派生製品の話が出てきてて、それは1機能1exeで提供されてて、それらを纏めるバッチ処理機能部分を担当することに。バッチ処理の内容・順番を記述するのにXMLを使う事になったのでXMLのパーサが必要なのだけど、色々調べたら富士通内部でパーサ作ってたのでそれをもらって使う事に。そのパーサはC++からじゃないと使えなかったのだけど、趣味C++勉強してたので何とかなった。あと、結構OSの知識(プロセスとか)が必要WindowsLinuxSolarisで動くコードを書く必要があってまあまあ大変でした(と言ってもifdefで切り分けるだけなんだけど)。けど、これらの開発は自分が一から設計してコードを書いていたので楽しかったですね。それでこれが完成するかしないかあたりで、このバッチ処理機能が他の開発中の製品バッチ処理に使えないかとか話が出てきたあたりで自分退職する事に。(退職の話は1年ぐらい前に話し合って決定済み)引き継ぎをして退職ということになりました。最後は溜まった有給を使う予定でまだ在籍中だけど部屋を引き払って実家に帰ってたのだけど、打ち合わせに来て欲しいって言われてしま実家から何日か通ったのは良い想い出。というかまさか実家から朝8時に間に合うとは思って無かった。

振り返ってみて残業時間は月40~60時間が多かったかな。100時間超えた時は上司に怒られた。あと退職前の1年ぐらいはうちの事業本部(だったかな?)単位残業禁止になってホント残業0時間になった時期があった。他の部署の人の話で、どう考えても狂ってる上司の話とかを聞いてると上司とかの運は良かったと思う。あと、やっぱり仕事でみっちりプログラミングが出来たのは運が良かったと思う。富士通ソフト開発で C C++ C# Java シェルスクリプト InstallShieldとか(そんなに深くはないけど)色々やれた人間はそうそう居ないんじゃないかな。同期とかの仕事は年上の人の派遣の人に指示出したり取り仕切ったりする仕事とか、保守サポートみたいな開発じゃない仕事の話も良く聞いていたので、ソフト開発のキモ体験出来たのは良かったです(こなみ)。

2016-04-16

富士通20年勤務している側から見たお話

富士通退職した話」を読んで、20年近く努めている側から感想と疑問について書いてみたいと思います

山奥の工場

私も、情報科学大学時代専攻した後、新人で山奥というかむしろ雲の上にある天空工場に勤務してメインフレーム関連の仕事をしていました。

その工場に配属される新人は(希望すれば)寮に入るわけですが、高専卒は工場敷地内にある山頂の寮で二人部屋、学士卒は山の5合目にあるアパートの一人部屋、修士ドクターは街中にあるマンションという感じでした。

街中の下界から工場がある天上界への通勤バスで移動することになるのですが、わたしは、バスディーゼルエンジン排気ガスが苦手なので、頼み込んで工場敷地内にある寮にしてほしいと願い出て、山頂の寮に特別に入れてもらいました。そもそもが2人で一部屋なのですが、学歴関係か私は一人で2人部屋を使わせてもらっていたため、ものすごく広々と部屋が使えました。

わりと頼み込めば、人事や勤労も柔軟に対応してくれる会社という印象です。

メインフレームというレガシー業務

20年前でさえ、メインフレームは古いというイメージがありました。

ただ、私は古臭い部署に配属されたことは不幸とは思いませんでした。電話からスーパーコンピュータまで幅広く扱っている世界でも稀な会社に入ったからには、いろんなことを経験してみたい。

そのためには、そろそろ絶滅してしまいそうなメインフレームを今経験せずにいつ経験出来るのか?くらいな感じでむしろラッキーくらいに考えていました。

最新の流行を追いかけるのもそれはそれで面白いが、そういったものは出来合いのライブラリを組み合わせて流行を少し遅れて追っていく2位集団であるし、やりたければ個人で家でも出来るじゃないか程度の感覚です。

自分意見が割と通る環境

ただ、せっかくメインフレーム部署に来たのですが、私の担当ワークステーションで動作するUNIXPCでの開発が主体でした。

そもそもが、メインフレームを扱っていた部署ですから、先輩の人達はあまりUNIXPCに詳しくなかったので、大学UNIXPC経験した新人が入ってきたことは非常に重宝されました。

その部署では開発言語は、社内の独自言語(Cよりもさら機械語に近い言語マウスグラフィカルに操作してコーディングする言語)を使っていました。もともとはメインフレーム用の言語なのですが、UNIXワークステーションPC用にも

その言語コンパイラはあり、あわやその言語UNIXの開発する羽目になりそうだったのですが、私は猛烈に反対して自分意見を通しました。当時はJavaRubyなどの言語は無くCが全盛でしたが、

その部署の開発メンバーはCをほとんど知らなかったのです。そこで、社内のカイゼン活動として、C言語勉強会を開くことを提案し私が講師になってC言語メンバー習得してもらい、

PCUNIXでの開発は独自言語ではなくC言語を利用することを認めさせました。

元の増田の方は、自分エクセルVBAソースが見れない立場のようだと言っていましたが、ソースをみようとしたらシートにロックがかかっていたのを見て諦めてしまったのではないでしょうか?

元のEXCELを使った業務が非効率であるならば、業務改善活動として提案すれば、それを拒む上司というのはちょっと考えにくいです。

忙しい部署にも、改善活動ノルマが課せられるのですが、先輩はそういったことに関わっている時間が中々取れないので新人がそういった仕事をやると宣言しても拒むのはまずありえません。

案外苦労するゼネコン

下請けプログラマーからみると富士通のような会社中間搾取していて高給をとっているのに、仕事は丸投げという印象があるでしょうが、実際やってみると案外大変です。

私は、富士通本社SE的な立場グループ会社に出向して、そこから顧客先に派遣される4次受け5次受けのプログラマ両方を経験しましたが、はっきりと下請けの方が精神的に楽と感じました。

商売や、自分でやっているわけではない人に依頼した仕事について、責任をとるのは非常に苦しいものがあります。そもそもプログラミングはとても楽しいというのもありますが。

異動の希望はまず通る

私見ている範囲では違う部署に異動したいという希望100%通りました。異動を希望しているのにその部が解散するまでその部署にいる羽目になった人など見たことがないです。

もちろん、「プロジェクトが佳境で君に今抜けてしまわれては困る」というケースはあるのですが、IT業界プロジェクトの開発周期は年々短くなる一方ですから、割と早い段階で異動の希望は通る感じです。

もとの増田の方は巨大プロジェクトだったので大量の人がいるわけですが、こういった部署は異動の希望は通りやすいです。

なぜなら、新規プロジェクトで最も忙しいときは大量の人員を動員しているわけですが、バージョン2、バージョン3あるいはメンテナンスフェーズに入ればそんなに大量の人員必要がないので、会社としてもその部署人員を異動させたいわけです。

けれど、プロジェクトで中核の技術を担っているようなメンバーマイホーム天上界に立ててしまったメンバー、新しい仕事対応しにくい高齢メンバーは異動させにくいので、

EXCELをいじっているだけのような新人は異動の希望が通りやすいのです。

もとの増田も、もう少し我慢していれば希望が通った可能性は極めて高いですが、プロジェクトが佳境でまだ新人で入ったばかりといった状態では、もう少しその部署で頑張れと言われるだろうと思います

ただし、異動先の都合もありますので、ここから出たいはほぼ100%通りますが、あそこに行きたいは必ずしも通りません。

今更「京」スーパーコンピュータをやりたいといっても、人気部署ですし、プロジェクトの最盛期は過ぎているのでその希望が通る可能性は低いでしょう。

嫌な上司はすぐにいなくなる

色々な部署がある大きな会社では、管理職クラスは頻繁に異動が起こりますから、嫌いな上司はわりと直ぐにいなくなります。小さい会社だとそもそも部署が開発部と人事部営業部しかないというかんじなので、上司がやめるか自分が辞めるまで、嫌な上司と付き合う羽目になりがちです。

入社時の部署希望のコツ

新人研修期間が終わった後、人事の面談のチャンスがあるのですが、そこにはコツがあります

「おおざっぱにはっきりと希望を言うこと」です。

いちばん最悪なのが、大学での研究を話し、それを活かせる部署に行きたいと話すことです。

人事の人は技術には詳しくないですから研究内容が最先端であればあるほど、人事の人には通じないです。

キャッシュコヒーレンシが。。とか話すと、「よくわからないけどこの人は基本ソフトウェアに向いているのかな?だったら、自社でOSを開発しているメインフレーム回そう」という感じになってしまます

それよりは、人事の人が、会社組織のどの部署に配属すればいいかわかりやすいように、おおざっぱに希望をいうことです。

例えば、

上記のことを強い口調ではっきりというのが良いと思います

そのうえで、できれば○○製品をやりたいだとか、こういった業種のSEをやりたい等の希望だすと、どの部署に配属すればいいか相手にも伝わり希望が通りやすくなります

私の同期で入社して新人研修で山奥に配属されたバブル時代末裔のようなおねーちゃんとか、数人は、割とはっきり希望をいって、下界に戻っていきました。

2016-04-13

運用に向いている人が羨ましい

明らかに向き不向きがハッキリしていて、尚且つ向いている人が少ない開発に比べたら、運用の方が間口が広い(=向いている人が比較的多い)と一般には言われている。

しかし、自分は全く向いていなかった。


この業界に入ってから数年前まで開発一筋で来て、それからつい最近まで運用チームに加わっていたのだが、とにかく他の人に比べて明らかに動けなかった。

そもそも自分は「パッと見で動いてんだったら放っときゃいいじゃん」という人間なので、毎日毎日ルーチンワークで目配せがずっと続くとか、その時点でゲンナリだった。

それから監視対象の各機器(ストレージセキュリティアプライアンススイッチ等)や各種ミドルウェアメーカーごとに仕様が違いすぎて、またその仕様も込み入っていることが面倒で、それぞれのオペレーションを覚えるのも苦痛だった。

てかそんなモノに、一体どう興味を持てというんだ?

当然、どれもこれも大まかに把握している程度に留まってしまい、そういう中途半端理解だと、トラブった時に大変になると。

やたら読みにくいマニュアル片手に原因を探り、それでも分からないのでメーカーに問い合わせてログ提出→回答を元にオペレーション→やっぱり動かないみたいなケースが何度あったことか。

もちろん、そんな人間重要機器は任せられないので、自分などいてもいなくてもいいポジションに終始することになった。

正直、昼間の8時間は死んだ人間として過ごしていたに等しい。

あい経験はもう懲り懲りだ。


そんな自分経験から運用業務代表されるような、ああい灯台守みたいな業務をテキパキこなせる人は心底凄いと思う。

個人的には運用なんてもう金輪際やりたくないけど、一つだけ、開発と違って基本何も起きなければ残業無しという点はとても魅力的なのだ

一方、開発の「ややこしい物事を、コードドキュメントという形で、可能な限りシンプルかつ分かりやすい内容にまとめていく」感覚が何者にも代え難いのは間違いないが、夜遅いのだけは本当に何とかして欲しい。

昔、一人屋台で小さく短い開発案件ばかりやっていた時は比較時間自由が効いたけど、今はもうそんな仕事ないし。


そうなると、これからは身体が続く限り開発に従事し、本当にキツくなったら・・・一応経験ありの構築業務鞍替えするのかな。

2016-03-18

http://anond.hatelabo.jp/20160318203612

セカンドライフ時代ヘッドマウントディスプレイは、2メートル先に小さなディスプレイがあるだけだった。

今のOculusRiftを発端とする、広視野角型のヘッドマウントディスプレイは、解像度犠牲にする代わりに

左右100度程度の視野角で視界全体を覆ってくれる。

しかも、頭の動きに合わせて画面が変化するので、まるでその空間に居るような錯覚を感じるんだ。


リアルタイム描写でも、例えば、アンリアルエンジンというミドルウェアで作られたCG

少なくとも、セカンドライフ時代CGとはくらべものにならないくらい、本物らしい絵が作れるんだよ。

2016-03-10

得手不得手

イベントパーティに行った時、何に興味を示すかは人それぞれだろう。

「どんな人が来ているかな」「どんな食べ物が出るかな」などなど。


自分場合、そういう場所だと、演出ライトフォーカスしてしまう。

ライトの点滅を眺めながら、それがどんなパターンで動いているか見極めようとし、分かったら「ああ、なるほど」と勝手に喜んだり。

まり、世の中のあらゆる物事について、ルール法則性と言われるようなパターンを見出す形で理解しようとするのだ。

世界パターン化というアプローチによって抽象的に捉えようとすると言い換えれば聞こえはいいが、自分で作った思い込みに囚われやす性格とも言える。


そんな自分にとって、プログラミングなんて簡単な仕事の部類に入る。

コンピュータ人間と違って全く融通が効かないし、指示命令であるプログラムコンピュータ行間を読まないことを前提に書かないと動かないし、何よりコンピュータの側が操作する人間気持ちを汲んでくれることは絶対にない。

こう書くと極めて面倒なシロモノに思うかもしれないが、実はコンピュータに通じる共通パターンみたいなものがあって、それさえ分かってしまえば、あとはポイントを押さえ大いに効率よくやることが可能なのだ

からこそ、自分にとってプログラミングは好相性とも言える。

はいえ流石に家に帰ってまでプログラムを組みたいほどではないが、それでも仕事にしたのは人生の選択として自分をほめてやりたい。

もちろんシステム開発に占めるプログラミング割合は低い方なのだが、客が本当に欲しいものと、実装が楽になる方法の両方を常に勘案するという手法仕事を進めているので、今のところ大事故はやらかしていない。

また、「マニュアルを読んでその通りにする」のもこれまた得意。

そこに来てプログラミングの土台となるミドルウェアは「とりあえずこうすれば動くよ、そんな難しくないからやってみ?」みたいなスタートアップのための情報が必ずあるので、これまた「動かなくてギブアップ」という経験は皆無。


一方で、同じITであっても、アプライアンスストレージ管理がメインとなる、運用仕事は全く苦手だったり。

メーカー・機種ごとに色々違っていて標準的手法があまりないところに、それぞれ細かいところまで見ていかないといけないこともあって、自分お得意のパターン化があまり通用しないので、その時点で攻略する情熱や興味をを失ってしまうというか。


しか機械相手ならまだいい。

一番苦手なのは人間相手」だ。

要するにコミュニケーションが苦手なのだ

人間パターン化がほとんど通用しない相手の最たるもので、そんなパターン化とか考える暇があるなら、もっと目の前にいる相手のことをきちんと観察しろよって話である

しかし脳がパターン思考最適化してしまったせいか、相手ありきの現物合わせが全くできないのだ。

「どういう言い方や持って行き方だと、最もスムーズ意思を伝えられるか」は「相手が何を思ってその言動になっているか」という想像力問題になるが、その想像力自分には少しも備わっていない。

なのでマニュアルなんて読んでも時間無駄だし、多分そういう分野はマニュアルというよりレッスンor稽古or練習がモノを言う世界なので、マニュアルのものナンセンスという可能性が高い。

じゃあ練習すればって?誰を練習相手に?という取っ掛かりで詰んでいたり。

そもそも「パターン化できない」時点で「うわめんどくせー」と感じてしまう時点で、これ以上のコミュ力の成長は望めないだろう。

でも、もしこういうことが上手くできたら人生更に楽しいだろうなーとも思うので、なんとも悔しい。

お陰で、自分はこのままだとリーダー営業職をこなせる可能性はゼロだし、多分それは機会損失でもある。まあ無理にやって周囲に迷惑かけるよりはマシだけど。


これは余談だが、それもあってか、フィクション世界で目にする「人好き系リーダー」は、自分が最も好みのキャラだったりする。無い物ねだりの変形だろう。

ここ数年だと、ラブライブ!高坂穂乃果マイブームかな。

アニメ第一期ラスト3話の大ポカも含めて、愛すべきキャラだと思っている。

2016-01-25

http://anond.hatelabo.jp/20160123172824

私は以前、製薬会社実験データデータベースや様々な表示システムを作ったりマイクロアレイ解析などしてた。

その手の仕事をしている人は、社内に主にたった5人しか居なかった。

ネットワーク管理化学物質合成などする人は他にいた。実験する人はもちろん大勢いた。

知らないが、日本だと最大手でもこの手の仕事をしているのは合計数十人位ではないかと思う。

一方、世界大手企業だと数百人居たりする。

伝聞や想像だた、金融は多分世界比でもっと少ないだろう。

自動車企業だとそんなに悪くないかもしれない。

人工知能もっと居そうだけど新しい技術開発をできるのは日本で数十人も居ないのかもしれない。

例えば、リアルタイム3D画像認識技術が開発された頃日本にそれを十分理解できる人もあまりいなかった。

日本応用数学の分野は非常に規模が小さい。

科学研究を調べるとわかるが何にしても非常に人数が少ない。

相当重要テーマでも世界で数十人しか研究者が居ないのはよくあること。

例えば、量子コンピューターに関して調べてみると想像つくだろう。

一方、量子コンピューターを学ぶのはそれほど難しくない。本屋に本が何冊も売っている。

量子コンピューター研究者ネタが無いのかわからないが最近重力と関連付けたり無理やり感がある。

前世紀末に新卒就職したソフト企業最初20人以上のチームで開発したが、今では滅多にないだろう。

転職後は大規模なシステムにも使われているミドルウェアのコアを開発したが数人のチームだった。

まり技術を求められる仕事は非常に人が少ない。

今後私が主にやる仕事基本的に一人や数人ですることになる。

会社管理をしてもらうために存在するようなもの給料がどうとかは全く興味がない。

何をするにしても、地球上における到達状況を把握し、全生産活動理解すべしと思う。

例えば、ソフトウェアにはどのような種類があるか、そしてどの程度の規模で開発されているか大手企業はどうか、

十年後はどのようになっているだろうかと言うことをなるべく把握すべきだと思う。

ソフトに限らず、現在地球人エネルギー源などや多くの科学技術に関してそうすべきだと思う。

科学技術に限らず、社会自体理解もすべきで、特に兵器テロ犯罪などの背景など理解しておくべきだろう。

そこまで来ると、世界的な諜報機関なども普通存在だなと思えるようになって十分想像できるようになる。

そして、人類を超えた存在視野に入るようになってくる・・・

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