読者です 読者をやめる 読者になる 読者になる

おうさまのみみはロバのみみ

ネット上での木の洞

Amazon Web Services実践入門

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

今回は実際に写経というか手を動かしながらやったわけではなくて 網羅的にどういう機能がありそれらを触りながら覚える前に一通り目を通して理解するのが目的だったため 実際にインスタンスを立ててゴニョゴニョしたりはしていない。

元々目次を読んだ段階で期待はしていたが大まかなAWSの機能などを知ることが出来たので目的としては達成できた気がする。 ただ予想を超えるような驚きはなかった。 せいぜいが「AWSというサービスはまさしく金の弾丸で殴るサービスを地で行くのだな」と感じたことくらいだろうか。

その代わりAWSという巨人に乗っかれるのでその分のお布施だと考えれば安くないがべらぼうに高いわけでもないのかなという印象だ。

中身に関してはAWSに詳しくないもののおおよそ漠然とどういうことができるのか?が把握できるようなものに仕上がっていると思う。 実際のブラウザ上でどこを操作するのか?やaws-cliを使用する際のコマンド入力の内容やそこで表示された項目の説明など必要十分な情報と密度が兼ね備えている。

というわけで実践はしていないけど入門用としては十分な内容になっていることと思う。 ぼくの使いみちとしては個人開発でサーバーサイドをRailsで行おうと考えていて、そのインフラ部分をAWSで構成しようと思っている。 そのときに必要な機能を使いたいときに辞書のようにペラペラ捲って確認する書籍として手元においておこうかなという感じだろうか。

AWSを業務で一部のみしか使っていない、AWSは知っているが使ったことがない人向けの書籍だと思われる。 業務でバリバリに使っている場合はもっと詳細に書かれた書籍かAWSに詳しいかたのブログを読んだほうがいいんじゃないかと思う。

ng-kyoto meetup #5 に初参加してきた

公式サイト

ng-kyoto

リンクは#3となっているが気にしてはいけない、今回は#5だいいね? connpassはこちら

感想

初参加で知り合いがほぼいない中、この手のイベントが久々だったということもあって最初こそ緊張したけどもそこは良い意味で緩い雰囲気に当てられたのか割りとリラックスして聞けました。 惜しむらくはぼくはサーバーサイドエンジニアでフロントエンドに疎いところがあって一部話している内容についていくのがキツかったり単語や名称自体知らないみたいなことがあったことでしょうか。 その辺もうちょっと知識があれば質問とかも出来たのかもしれないと思うとちょっと残念でしたね。

参加した目的

1番の理由は @takapyyy さんの「フロントエンドフレームワークの選び方」がちょうど個人開発で作成する予定のフロントエンドのフレームワーク選定の参考になりそうだなーというのが動機の一番大きな目的ですかね。 (なおconnpass登録時のタイトルは「Angularを触ろうと思うまで (仮)」だった) この辺のAngularが何向きなのか?とかReactの強みとは?とかVue.JSはなにが優れているのか?みたいなのが触りくらいしか理解できてなかったので聞いてみたかったということですね。 JavaScriptにおける大規模ってどれくらいからなの?みたいな。

実際に発表聞いた感想とか

フロントエンドフレームワークの選び方が一番気になっていた話しだったのでかなり集中して聞いていた。 当たり前の話しだけど「プロダクトにあったフレームワークを選べ」ということ。 チャレンジするのも勇気!だけど時には「いつもの」を選ぶのも勇気!というのが非常にしみた。

個人的な感じた内容や他の発表者のかたの内容から推測すると Angular > React > Vueの順に大規模→小規模な感じだと理解していて、規模感や学習コストなんかを懸案した上で採用するのがベターな選択肢だなという当たり前の結論に達した。

個人開発するものに関してはそこまで大規模にはならないし(する予定はない)SPAにする予定もないのでVue.JSが無難なのかな?という仮決定を出せたので参加してよかったと改めて思った。 ReactはReact-nativeを触った感じだと非常にわかりやすいし、現在のデファクトといってしまって問題ない感じなので最後まで悩んでいる。 それもあってまだ仮決定としている感じだ。 (ただ多分Vue.JSでほぼ決まりかなと思ってる、Reactである必要性が今のところない)

追記: 「TODOアプリは面白くないからオススメしない」とあるけどもこれには以下の理由から完全な同意が出来ないとぼくは考えている。 興味のある分野のアプリを作るが示された選択肢の中でもっとも最善手だとはぼくも思うが興味がある≒学習に最適だとはぼくは考えていなくて 例えばTODOアプリでは一通りの機能を触れるけども特定の興味をもった分野でのアプリの場合、利用する機能や実装が特定のものに偏ることがある。 これが悪いとは一概にいえないのだが初期段階などではぼくは広くいろいろな機能を触っておくべきだと考えているのでそういう意味でもTODOアプリを作成するのは意味があると思っている。 とはいえTODOアプリを作るのがつまらないと感じているのに敢えてやるほどのメリットはないとも思う。 個人的な進め方としてはTODOアプリなど一通りの機能を触るものを作ってから興味のある分野のアプリを作るというのがボク自身の進め方になる。 TODOアプリじゃなくてチュートリアルやればだいたいこの手の内容は解決するんだけどもちょっと気になったので追記しておいた。

他にもいろんな方の発表があって久しぶりにどっぷり技術の話しに浸かれたなあと思いました。 やっぱりこういう勉強会というか技術発表の場に来るのは刺激を受けることが出来るのでいいですね。

他にも実務で使うAngular-CLIの話しやAngularでGUI Animationの話しが個人的に興味深かったですね。 突発LTだった難しいよね、コードレビューも面白かった。 でっかいPR来たらどうすんの?(きみたちどうしてるの?)というLTerからの質問に会場内で解決策が出なかったのは残念だった、非常に知りたい内容だった。

ちなみに今ぼくがいる会社はPRで開発をしていて以下の条件を通過したものをマージすることにしている。

  • コードレビュー済みのPRのみマージ(緊急時などは除く)
  • 必ずレビューは全員のOKをもらう
  • マージ後検証用の環境にデプロイし目視チェックを必ずプロダクト参加メンバー全員に課している

これはプロジェクトの規模がそこまで大きくないからこの手法で成り立っているけどもOSSのような大きなプロジェクトなどでは通用しないだろうと思う。 みんなデカい修正内容のPRが来たらどうしてるのか教えて欲しい。

あと「宗教戦争になりがちな話題はコーディング規約に先に書いたものが勝ち、それに関する議論は別のIssueでやれ!」という意見が個人的にツボった。 いいアイディアじゃねえか!

懇親会の話とか

懇親会はめっちゃでかいピザが届いて「おいおいこれ食いきれるのか?絶対残すやつじゃね???」と思ったが綺麗になくなったので良かった。 カラムーチョうまかった、安定感だいじ。 お酒以外にもソフトドリンクがあったので下戸なぼくには非常に助かった。

懇親会ではフロントエンドの話しがでたかと思えばヨーヨーの話しがでたりWeb Assemblyから始まった話しが最終的に最近のミニ四駆はすごい!みたいな話しに繋がったりで楽しかったですね。 ちなみに光るヨーヨーの動画みて「これ伊藤直也さんみたい!」といった犯人はぼくです、さーせん。 いやでも光るヨーヨーに30kはさすがに出せない!><;

ともあれぼくに近しい、でもぼくよりも若いエンジニアのパワフルさに圧倒されつつも「サーバーサイドエンジニアだからとかフロントエンドエンジニアだからとかもう言ってるやつは死滅していくだけだな、ぼくも頑張らなければ!!!」みたいな焦りと高揚する気持ちとがないまぜになっているので頑張って個人開発進めようと思います。 とりあえず来月以降は今登録してる勉強会とかセミナー以外は参加せずにガッツリ開発に専念しようと思う。

さいごに

だいたいこんな感じかな。 お名前だけはやたらとよく拝見していたこざけさんにも挨拶出来たし、いろんなエンジニアのかたと話せたり、個人開発の選択肢がおおよそ決まったりと得るものが多い日でした。 次はVue.JSからの刺客として登壇できるといいなーとか思ってるのでそのときはよろしくおなしゃす!!!

良いチームと悪いチーム、その差。

最近よく「良いチームとは?どうあれば良いチームなのか?」という疑問をずっと抱えていたのだけども結論が出ずに堂々巡りをしておりちょっと困っていた。 ところが今朝はてブみていたら id:hase0831 さんが明確な答えを示していてくれて「そうか、これが足りなかったのか!」という気づきを得た。

hase0831.hatenablog.jp

技術力が決して高いと言えない開発チームで働いたときに「このチームは技術的課題はあるけども良いチームだな」と感じることと「このチームは技術的課題云々以前の問題がありすぎるチームだな」と感じることがあった。 両者にはある程度共通する(というか内容の根本自体はほぼ同じ)課題や問題があって「じゃあなにが良いチームと悪いチームを分ける分水嶺になっているのだろう?」と考えていた。

技術的レベルにおいては双方ともに同じようなレベルだったのだが明確にチームとしての明暗が分かれているように感じた。 TeamGeekなども読んだけども結局のところ、この疑問の解決や決定的な分析は図れなかったのだけどもここで挙げられている3つの点におけるアプローチが違うということに気づいた。

悪いチーム

恐らくわかりやすいだろうと思うので悪いチームからのアプローチを紹介する。 これらの状態に陥っている場合はチームが機能していない可能性が高いと思うので早急に改善すべき状態だといえるだろう。

Why?まで落とさず作業を進める

よく言われる内容だが「何故それをすべきなのか?」が説明されないまま仕事をすると多くの場合以下の問題が発生する

  • 指示したものと違う提出物があがる
  • 見た目は指示したもののように見えるが実体が異なる
  • 指示されたものにはなっているが将来的な課題に関する対応策が検討されない
  • 指示されたことしか行わない

これらの話しがでるとよく「指示の裏にある意図を作業者が汲み取って欲しい」ということを言われる。 この意見は一見正しいのだけども「指示の裏にある意図を指示者が伝える」のも同じくらい重要だと考えている。 これらはどちらかだけでは成り立たなくて悪いチームはどちらかに押し付ける形で仕事をしていることが多いように感じた。

これらはある意味でコミュニケーションにおける問題だと考える。 そのための解決策は「飲みニケーション」などではなく、「正しく伝える努力」と「正しく理解する努力」を双方が理解することだと思う。 悪いチームはだいたいこれらの努力の方向性が一方通行であることがほとんどであるように思う。

作業者からすれば「指示された通りにしたのにリジェクトされた」と不満が溜まるし「そもそもなにがしたいのか?」というWhy?が共有されていないのだから どうなっていて欲しいのか?将来的にどう発展させるのか?という将来像が見えずただ言われたことをそのまま行うという最悪の状態になる、悪循環のループが完成する。

この状態が何故最悪かというと「何故こんな状態になっているのか?」という問題が発覚したときの分析時に「指示された通りにやりました、私の責任ではありません」という責任の放棄となすりつけあいが発生してしまうからだ。 そしてその悪循環に疲弊したメンバーから辞めていくことになる。

こうなるともうチームとしては崩壊している状態といえる。 マネジメント権限を持つ人間はこれらの問題が発生する前に対処する必要がある。 正直このような状態からチームを立て直すのはかなり厳しい状態であると思う。

これらの問題をマネジメント権限を持つ人間が検知するには 「指示されている内容がわからない」「なにがどうなっていればいいんですか?」 というような意見が作業者から出たら限りなく赤に近い黄色信号になっているのでなにがどう足りていないのかを検討すべきである。

全員の持つ情報粒度にバラつきがある

全員が同じ情報を全て知っている必要というのはないと思うが「誰が知っているのか?」「どこに情報があるのか?」が共有されていないとチームメンバー間に温度差が出来てしまう。 この温度差というのはやっかいで検知するのが難しい。 ただこの温度差というのは不平不満の温床になるので出来る限り無くす、それが難しければ温度差を軽減する必要がある。

件のブログでも危ういところまでいったとのことなので情報を管理する人は特にデリケートに扱う必要があるのだと思う。

大まかにでも「ここからここまでは全員が知ることのできる情報」「ここからここまでは管理者のみが知り得る情報」というようなカテゴライズをするくらいしか解決策が思いつかない。 しかしそうすると「この情報はどっちなのか?」という例が必ず浮上してくるし、その対処に悩む内にうやむやになってしまうパターンがほとんどなのではないかと思う。

TED Talkだったと思うが今まで機密情報だったオープンにして誰でも閲覧可能にしたところ業務効率が飛躍的に向上した、情報に機密性を持たせることによるメリットよりもデメリットのほうが大きいという話しを以前なにかで読んだ(もしくは見た)がチーム単位であればそれでもいいかもしれないが会社規模となるとなかなか難しいのではないかと思う。 ただそういう方針を話しあったり常にブラッシュアップしていけば温度差というのは非常に小さい影響で収まるのではないかとは思う。

またこれらの温度差をキャッチアップする方法として1on1などの手法はあるが結局のところこれらは「どうせ言っても無駄だろう?」という諦めをメンバーが感じてしまった段階で意味がなくなってしまう。 信頼関係が構築できていないところに手法だけ持ってきても意味がないのだ、まずは崩れてしまった信頼関係を構築するところから初めなくてはいけない。

「違う」「間違ってる」しか伝えない

これは最初のWhy?にもかかる部分があると思うのだけど悪いチームというのは最初のWhyが出来ていないせいで期待したものと違うものがあがった際に「これは違います」としか伝えないことがほとんどだと言っていい。 明らかな不具合、例えばブログのエントリを投稿したのに表示されていないとかならそれでもいいと思う(というか普通に考えて大問題だしそれで伝わらないのは別の意味でやばいと思う)

ところが多くの場合は「ここのAという部分が期待した動きになっていない」「このBという表示が本来B'になっていて欲しいのになっていない」というケースが多い。 悪いチームはこの説明を後出しでいうことが多い。 当然、作業者側からすれば「最初に説明しろよ!」と不満が溜まる。 結果チームとしての空気は悪くなるし指示者に対する不信感も募るため「言われたことしか行わない作業者」が出来上がってしまう。

言われたことしかしない部下や社員がいると嘆く前にまず指示者は分析をすべきだと思う。 だいたいの場合は嘆いているだけで作業者側からすれば明確な理由に対する対策が行われていないことが殆どであるように思う。

良いチーム

Why?まで落とさず作業を進める

良いチームは多くの場合伝え方が上手いことが多い。 「Aの機能を追加してほしい、以前似たような実装をBプロジェクトのCに実装してある」などとしてどういう状態が理想なのかを具体性を持って説明する。 これを受けた作業者は当然Cの機能を元に考えるため車輪の再発明を行わなくて済むし、具体的なイメージとしてC機能があるため指示者とのズレも最小限となる。 また「C機能をそのまま使えない理由はなにであるか?」とか「今後この機能はD機能に移行していくことが予想されるので移行が簡単に行えるように実装しよう」と考えることが出来る。

これはWhy?がきちんと支持者と作業者間で共有されているからだろうと思う。

全員の持つ情報粒度にバラつきがある

良いチームの場合「これは全員が知ってる(知っていない)」が明確であることが多いように思う。 そして「このことなら社内のナレッジツールでみたことあるよ!」とか「それは○○さんに聞けばわかるよ!」とかってパターンが多い。 この例でいうなら○○さんが管理者しか知りえないことを知っているという認識がおおよそ全体に認知されていることが大事という話し。

駄目なチームは「誰に聞けばいいのかわからない」が共有されてしまっていることが多いが良いチームは全く逆で「誰に聞けばいいか」が明確なため 「こういうことを聞くのは誰かわからない」というときに「○○さんなら知ってるんじゃないか?」という質問しやすい空気につながっているのだと思う。

「違う」「間違ってる」しか伝えない

良いチームは「ここは出来ればこうしてほしかったですね。」とか「こうやれば次回からはもっと早く実装できますよ!」などOKなときでもどうしてほしいかをきちんと伝えることが多い。 ここが悪いチームとの決定的な差かなと個人的には思っている。 こういう小さな信頼の積み重ねや1つ1つの事柄に対する信頼感がチームを育てるのだと思う。

まとめ

気づけばそこそこ書いているが結局のところ悪いチームの駄目なところっていうのは共通してるけど 良いチームの良いところっていうのはそのときどきやメンバーで変わってるという印象以上のものがないんだよね。 ということで凡人たるぼくらが出来ることは潰せるデメリットは早めに潰すという対処療法しかないのだよ。

前職の同僚によく言われたことだが「一気に変えることは出来ない(難しい)ので少しずつ変えていきましょう」ということですね。 これが出来るからこそ良いチームなんだと。

職務経歴書OSS化改善案

luccafort.hatenablog.com

id:okoysm さん経由で知った #職務経歴書OSS化 で書いたデメリットの中で一番個人的に大きかった理由の1つである「個人情報がフルオープン」の改善案を思いついたので忘れない内に書き出しておく。

改善案

元々はGithub上でなんとかしたいと思っていたのだけどもどうやってもGithubだと難しいなということを感じていたのだけども よくよく考えたらQiitaの限定公開を使えばMarkDown形式でかけるしログとしてもいいのではないだろうか?と思った次第。

問題点

ただ難点というか当然ながら問題もあって

  • 限定公開している場合PR送れないっぽいのでフィードバックが受けられない
  • Gitで管理していない

が出来ないというなんか改善してんだか改悪してんだかわかんないなって状況になってしまった。

まとめ

とはいえ「GithubのPublicで公開するのはちょっと…でもそのためにPrivate契約するのも(´ε`;)ウーン…」という人はQiitaで公開するのは1つの選択肢かなと思う。 Dropboxとかでも公開するのと変わらないんだけどもブラウザだけで完結するっていうのがメリットの1つかなとはちょっと思ったりしてる。 というわけで暫くの間Qiitaの限定公開に職務経歴書をあげておこうと思う。

あとついでなので履歴書もMarkDown形式で書き出してみようかなと思ってる。 結局これらの資料ってどういうことしたのか?とかどこの学校出身なのかとかってデータがわかればいいだけだし形式に拘る必要性ないよね!ということで3連休の間にしれっと書き上げておく。

SQLアンチパターン

id:Soudai がなにかの資料で「とりあえずSQLアンチパターン読んでないやつは読んどけ!マジで!!!」って書いてたのが読み始めのきっかけ。 実践ハイパフォーマンスMySQLみたいな迷ったときに辞書のようにして使う書籍なのかと思って買ってはいたんだけども読んでいなかったことを後悔した。

この書籍は非常に示唆に富んでいる。 「DBなにそれ?(ハナホジ」という人にはこういうことをしてはならぬ!というまさに本著の冒頭で書かれている転ばぬ先の杖、べからず集として機能します。 逆に実務でバリバリにRDB使ってるよ!という初級から中級にかけてのサーバーサイドエンジニアにはかつての自分の失策を見つめ返す良い機会を与えることでしょう。

唯一疑問というか、それは違うんじゃね?となったのがファントムファイルの章なのだけどもそれをつぶやいたところまさかの方から反応あってびっくらこいた。

ファントムファイルの対象バイトサイズなんかを考えると今現在の状態とはかけ離れた時期に原著が書かれていたのかなと推測する。 あるいは著者がファントムファイル教の信者なのかもしれない、今聞いてみたらあれは誤りだったよ!とかいいそうな気はする。

というわけで本著をすでに買っていてぼくと同じように読んでないひとは今すぐ本棚から引っ張りだしてきて読むんだ! きっと得るものがあるぞい!

最近よく考えていること

さいしょ

今の会社がアレすぎるので転職とか諸々の選択肢を改めて考えている。 その中で今までは考えなかった選択肢をよく考えている。 フリーランスと起業だ。

これはぼくが起業したい!とかフリーランスになりたい!みたいなポジティブな動機から考えていることではない。 ただぼくが考えている「こうあって欲しい」と望む条件を満たそうとすると自分で会社起こすか、フリーランスのように働き方を選べないと難しそうだという現実に直面しただけの話だ。

何故今までこれらのことをぼくが考えていないか?

この理由は簡単でぼくは経営者向きの発想や性格でないからだ。

経営者として↓の3つがぼくには大きく欠落していると考えている。 恐らくぼくという人間とそれなりに深く関わりのある人は同様の感想を持つんじゃないかと思う。

作ってみたいと思うサービスなどはあるもののじゃあそれをマネタイズするにはどうするのか? 作ったサービスを広く知って使ってもらうためにはどういう広告戦略を立てないといけないのか? サービスをスケールさせ、人手が足りなくなったときにどうやって雇った人材のマネジメントするのか?

主にこれらの点が知識不足や能力不足、またそもそもこれらの能力を向上させる意欲などなどが欠落していると考えているからだ。 その他にもお金がないとかそこまでのモチベーションがないとか色々あるが全部は多分書き出せない。 それぞれは大きな問題ではないのかもしれないけども数が多すぎると思ってる。

ともあれ、これらの説明を道筋立てて説明できないひとをぼくは信用できない。 自分ですら信用できないひとを誰が信用してくれるというのだろうか?ということだ。

じゃあ何故そう考えるようになったのか?

これは関西に帰ってきたこと、転職活動を直近で行ったこと、年齢的なことなどなどの条件が恐らく複合的に交わったからこそなのかなと思っている。 ぼくはもう若いとは言えない年齢だ。 少なくとも「エンジニアで中途採用を行う、どちらも未経験者だ」と言われたときにぼくの年齢と大卒、あるいは高卒のような方と比較された場合に 多少のアドバンテージごときでは若手のほうを採用するだろうと思う。

そういったことを考えていると「1つの会社や技術などにロックインされてしまう今の状態はよくないのでは?」と考えるようになった。

この辺はSoft Skillsの不動産やれ!っていう話しに近いものがあるのかもしれない。 本業とは別に副業を持っているという選択肢があることで精神的安定を得られることなどが影響しているのかなと。 副収入があれば多少貧窮しても生きていける、そう思えばとり得る選択肢の幅というのは非常に広がるのではないか?と考えているが実際にどうなのかは未だ不明だ。

まとめ

ともかく、今まではセルフコントロールが出来る自信がないことや金銭面などの不安からフリーランスになることを最初から検討していなかった。 起業に関しても、自分だけの問題では済まないことなどから諦めていたところがあった。

がしかし、これらの選択肢が取り得る選択なのだという安心感があれば転職の道や今後の働き方などにも非常に高い自由度を与えられる気がしている。

なんだか取り留めがないけどもそういうわけでフリーランスや起業した人に話しを聞きに行こうと思ってるので そのときは随分うるさいやつが来たなと思ってくれて構わないので答えれる範囲で答えてくれると嬉しいです。

あと起業やフリーランスで困ったことや解決方法としてどうしたか?などあれば教えてほしいです。 以上、おしまい!

似たようなことを考えている人がいる

割りと↓と似たような考えをしているなと前から思っていたので一度話しを聞いてみたいと思ってる。

pha.hateblo.jp

あこがれのはてなランチをてにいれた!

タイトル以上の内容がありません、ただの自慢です!( ・´ー・`)ドヤァ

本日のはてなランチはカレー。美味かった!

どうやら金曜日はカレーの日らしいのでカレー好きな人は金曜日にはてなランチできるように調整すると良いです。 なお東京オフィスと京都オフィスでそれぞれ傾向が違うらしい。 京都オフィスは健康志向っぽい趣らしい。

とりあえず今の会社の現状話したり、今後どうしていきたいのか?みたいな相談に id:Soudai に乗ってもらった。 大変感謝している。 あとだいくしーさん (id:daiksy) にようやくご挨拶できた、多分初めてお会いした。 いつもしょうもないことしか言ってなくてすみません…。

あ、あと 偽名さん (id:amagitakayosi) を紹介してもらって雑談したりゆううきさん (id:y_uuki) を紹介してもらったりした。 いつもブログなどで購読させてもらったり、KyotoJS #12 をキャンセルしてしまい迷惑をかけてしまったことを謝ったりした。 (IDコールしておきながら違う人だったらどうしよう…という不安がちょっぴりあるけど多分あってるはず)

id:Soudai に誰か会いたい人いる?って聞かれたので多分はてな社員の中で一番ブログ読んでるしばゆーさん (id:shiba_yu36) をあげさせてもらったのだけども「誘うの忘れてたwww」って言われたので まあしゃあないかーそーだいもしばゆーさんも忙しそうだもんなと思いつつ若干残念な思いだったので次はてなランチするときもリクエストさせてもらおうと思ってる。

以上! とりあえずはてなの空気感に触れられて良かった。 奇しくもSwitch発売日だったからかみんな集まってワイワイやってるのが楽しげで業務モードの真剣さとのギャップが激しくていい会社とメンバーだなーと思ったとさ!

わりとガチではてなで社会人インターンしたくなりました…。 とはいえスキルセットがミスマッチなんだよねぼくの場合(PHPerなので)、PerlやってないしScalaもやってないからなあ。 今からPerlを1から覚える、覚えさせるなら若い人優先するだろうし、ぼくも同じ立場ならそうするからな! 勉強会とかカンファレンス、なんかの雑誌で連載開始するレベルのスキルセットを身につければワンチャン…(゚A゚;)ゴクリ

本題とは関係ないんだけども京都地下鉄のイメージキャラクター太秦萌のポスターが社内にあったんだけどどうやって手に入れたのかがめちゃくちゃ気になる。 写真とっておけば良かった!そして入手経路を聞き出すべきだった!!!(激しく後悔)