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

いつブロ

いつまで続くか分からないブログ(仮)主に趣味やプログラミングに関するメモを書いています。

☆初登壇☆JAWS-UG大阪 第18回勉強会 サーバーレス #jawsug

AWS サーバーレス 勉強会

f:id:koichi0814:20170226230514j:plain

jawsugosaka.doorkeeper.jp

AWS歴半年でサーバーレスに関する内容で登壇して来ました。
最近話題のサーバーレスという事で参加者が増えすぎたので3会場繋いでやりました。
初めての登壇なのに大丈夫かな?
3会場同時なんかどうやるの?
とか思いましたが実はあんまり気にしていませんでした。
なんせ自分の担当があるので、それ以外のことは運営スタッフにおまかせ状態でした^^
 
第1会場 38人
第2会場 47人
第3会場 35人
計:120人
 
行きましたねー。100人超え。
私の担当は一番多い第2会場のAWSJでした。
しかもトップバッター。
 
f:id:koichi0814:20170226232614j:plain
 
とりあえずスクリーンの横に立って、やってる感出してみる。
 
f:id:koichi0814:20170226233037j:plain
 
ライブコーディング風に15分で簡単なサーバーレスなアプリ(呼び方あってるのかな?)を構築している動画を再生している所!
ライブコーディングだと緊張して打ち間違いや手順を間違えたり、パニックになったりするので、15分でサーバーレスなアプリを構築できるように何度も練習して動画にしたものを15分に編集しました(笑)
 
はじめてのAWSサーバーレスということで、業務で実際に使っている内容を簡単なサンプルで再現する事にしました。
作ったサンプルはフォームに生年月日を入力して送信すると年齢を返すというもので、こんな手順で作りました。

  1. S3 のバケットと CloudFront を作成
    CloudFront 経由でしか S3 に直接アクセスできないようにします
  2. Lambda に設定するロールを作成
    S3 にファイルを作成するのでフルアクセス権限を持ったロールを作成します
  3. Lambda を作成
    パラメータの生年月日から年齢を計算して、結果を S3 に JSON ファイルとして格納します
    ファイルを作成したあとは、結果の画面を表示するために Location を指定して転送します
  4. API Gateway を作成
    Lambda は JSON を受け取る前提になっているので、フォームで入力された生年月日をJSONマッピングして Lambda を呼び出します
    Location をヘッダーにマッピングして 302 として返すようにします
    API Gatewayを直接呼び出されないようにキーも設定しておきます
  5. API Gateway 呼び出す CloudFront を作成
    API Gateway の URL を CloudFront の呼び出し先として設定します
  6. S3にソースをアップロード
    フォームの Action に API の CloudFront の Domain Name を設定します
  7. 完成
    1.で作った CloudFront の Domain Name をブラウザに入力して動作確認を行います

手順を間違えずにスムーズにサーバーレスを構築するのって、しっかりと頭に入ってないと難しかったです。
でもたった15分でサーバーレスができちゃうんですよね〜。
 
動画なので間違えたりしないのですが、
「ここを〜」とか「ここで〜」とか自分のMacに話しかけちゃってダメな感じでした。。。
しかも他の2会場に繋いでいるのでMacから離れると音声が届かないので、ほとんど下を向いてしまっていたことに途中で気が付きました(笑)
 
f:id:koichi0814:20170227000724j:plain
f:id:koichi0814:20170227004810j:plain
 
ほっと一息、質問コーナー。
 
Q1.
苦労した所はどこですか?
 
A1.
コンテンツの作成は専門の会社にお願いしていたのですが、一部に PHP が使われていたり、ヘッダーやフッターに SSI が使われていたので困りました。
S3 に置くので PHP は使えないし、SSI も動きません。PHP は止めてもらって、というか無視して、SSI についてはローカル環境に Xampp をインストールしてそこにソースを置いて wget で SSI が展開された html を取ってきて S3 にアップロードするという事をやっていました。
共通部分に修正が入るたびに全ソース修正するのが段々大変になってきたので、共通部分は JSON に持たしてページを開いたときに JavaScriptJSON からタグを生成するように変更しました。
 
Q2.
S3に置くようにしてサイトのリニューアル前と後ではパフォーマンスは良くなりましたか?
 
A2.
はい。かなりサクサク動くようになりました。
 
 
 

さいごに

スライドというか動画は300MBもあるのでどうやって公開しようか考え中です。。
言うの忘れていましたが、弊社ではクラウドエンジニアを絶賛募集中です!!

Osaka HoloLens Meetup vol.1 に参加してテンション上がった

勉強会 HoloLens Surface Studio

1. はじめに(有名人に会いに行く)

f:id:koichi0814:20170205064704j:plain
Osaka HoloLens Meetup vol.1
HoloLens日本リリース記念ハンズオン&meetup 参加レポートです。
 
HoloLens持ってないし全く興味もないまま参加してきました。
参加の動機は、日本マイクロソフト株式会社 エバンジェリスト・業務執行役員である西脇 資哲さんに一度お会いしたかったからです。
あの「エバンジェリスト養成講座」の西脇さんですね。
 
もちろん勉強会の参加者の中には知り合いは居ませんでした!
(途中で気が付いたんですがお一人居ました)
そんな状態だったので、受付もぼっちで・・・と思って向かっていると、
まさかのちょまどさんが受付に居らして、コミュ障MAXに緊張してしまいました。。。
しかも横には西脇さんも居られて、、、
「あ、どうも〜」みたいな感じで、、、
Twitterのアイコンは自分の写真にしていたので認識されていたのかも知れません。(勝手な想像です。)
初っ端から超有名人に迎えられて(?)どうしていいものか戸惑ってしまいました(笑)
 
会場に入るとハンズオンからの参加者が既にお寿司を食べながらご歓談の様子だったので案の定輪に入れずでしたが、座席が空き放題で最前列の良い場所が確保出来てそれはそれで良かったです。
発表される方は絶対に前の方に集まるはずなので、それを見越しての最前列確保です。
西脇さんもすごく近くに座って居られましたが、最後の最後まで喋れず(笑)
何とか勇気を振り絞ってご挨拶出来たのは最後の集合写真のときでした!
目的は果たせました!
 
それにしてもちょまどさんはこの日のためにわざわざ大阪まで来られたそうで凄いですよね!
若い内からこんな行動力を発揮するなんて。ここはぜひ見習いたいですね。
私の会社にもこんな人欲しいです(笑)
絵も上手で漫画も描けてプログラミングも出来て英語も話せる、こんな人居ないですよ。普通。
これからのクリエイターをリードするマイクロソフト社員としては秀逸で必須なんじゃないでしょうか。
IT業界全体としても。
 
今回の勉強会参加でたくさんエネルギーを貰いました!
ほんと参加して良かったです!
 
という感じでした。
ふ〜。HoloLensの事何にも書いてない。
書きます書きます。
 

2. HoloLensの概要と、Windows Holographicに向けて

f:id:koichi0814:20170205065204j:plain
もちろん、中村さんの事は知らずに参加しました(笑)
HoloLensの話はこちらにまとまっています。
Natural Software
 
32bitのWindows10が内蔵されているということで、3次元の中でExcelを立ち上げたり、メーラーを立ち上げたり空間の中で作業が出来るそうです。

HoloLensを付けたら寝ながらでも仕事出来るようになるのかな。
 
スライドどこにあるのでしょう・・・
 

3. HoloLensと私

f:id:koichi0814:20170205070919j:plain
HoloLensを付けたままの発表スタイルを確立?!
左手めっちゃ重そうですけど(笑)
 
f:id:koichi0814:20170205071204j:plain
なかなかカッコ良く締められていました。
 

4. Hololensの動作原理概要

f:id:koichi0814:20170205071311j:plain
個人的な見解ではありますが、動作原理の解説がめちゃくちゃ面白かったです!!!
中身を知り尽くしているから説得力がある!
 
f:id:koichi0814:20170205071513j:plain
こういうの面白いです。物理とか入ってくると。
まとめ資料欲しいです。
 

5. マイクロソフトの最新テクノロジー

f:id:koichi0814:20170205071918j:plain
これを聞きに来たのです。
最初から惹き込まれるトーク。
 
f:id:koichi0814:20170205071950j:plain
ゼロ・グラビティというやつらしく、指1本で動かせるとか。
(でも戻すときは両手です(笑))
 
f:id:koichi0814:20170205072007j:plain
このダイヤルが超便利なんです。
ちょっとしたオブジェみたいでカッコいいですね。

言葉で表すのは難しいのでこちらの動画を見てもらった方が良いかもです。
 
西脇さんによるSurface Studioの紹介

 
個人的参加のちょまどさんによるライブドローイング
 

6. まとめ

HoloLensもSurface Studioも凄かったです!
今回全く知らずに参加しましたが、HoloLensって単なるVRだと思っていましたがそうじゃなかったです。
そもそもHoloLensのMRというものを理解する必要がありました。
www.buildinsider.net
Surface Studioのダイヤルはめちゃくちゃ便利なんじゃないでしょうか?
ダイヤルなんて昔からあるのにアナログがデジタルと融合したときの感動は凄いものがありましたよ。

Electronのconsole.logでハマる

Electron

1. はじめに

このエントリーはElectron Advent Calendar 2016 - Qiitaの3日目です。
 
分かっている人からすれば極々当たり前の事なんでしょうが、
私はめちゃくちゃハマったのでここに記録しておきたいと思います。
 
何にハマったかというと、console.logを使ったログ出力です。
console.logを使うとIDEのコンソールウィンドウにログが出力されるのだろうなと思っていて、 実際にやってみると確かに表示されたのでデバッグで簡単にログを出したいときはそうやっていました。 ところが、コンソールウィンドウに表示されないときがありました。
 

2. 開発環境

macOS Sierra
WebStorm 2016.3.1
 Application Parameter --enable-logging
 ECMA Script 6
Node.js 6.5.0
Electron 1.4.8
 
ソースは以下のような構成でした。
test_pj
- node_modules
- browserwindow.js - index.html
- index.js
- package.json
- style.css
- webview.js
 
プロジェクトの作り方も一応説明しておきます。
nodebrewを使ってNode.jsをインストールして、Node.jsのパッケージマネージャをpackage.jsonを作ります。

nodebrew install-binary v6.5.0
nodebrew use v6.5.0

cd ~/Documents/
mkdir test_pj
cd test_pj
npm init -y

package.jsonはこんな感じで作られます。

{
  "name": "test_pj",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

次はElectronをインストールします。
--save-devとするとpackage.jsonに追記してくれます。

npm i electron-prebuilt --save-dev  

続いてpackage.jsonを修正します。
7行目に「"start": "electron index.js",」を追加します。

{
  "name": "test_pj",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "start": "electron index.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "electron-prebuilt": "^1.4.8"
  }
}

こんな感じでプロジェクトを作っていきました。
 
続いてindex.jsを作成します。
package.jsonのmainに書いたこのjsがメインプロセスといいます。
メインプロセスから作成するBrowserWindow(10行目)がレンダラプロセスです。ちょっとややこしいかも知れません。

"use strict";

const {app} = require("electron");
const {BrowserWindow} = require("electron");

let mainWindow;

app.on("ready", function() {
    // こっちがレンダラプロセス
    mainWindow = new BrowserWindow({width: 1000, height: 800, "node-integration": false});
    mainWindow.loadURL("file://" + __dirname + "/index.html");
    // mainWindow.openDevTools();
    mainWindow.on("closed", function() {
        mainWindow = null;
    });
});

// デバッグログ
console.log("index.js");

上の11行目でindex.htmlを指定しているので、index.htmlを作ります。
 
index.htmlでは15行目にwebviewタグを使っていて、srcに指定したgoogle.comを画面いっぱいに表示します。
16行目のscriptタグでbrowsewindow.jsも読み込みます。

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <title>test_pj</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
<div id="menu-bar">
    <input type="text" id="url" value="http://electron.atom.io/">
    <button onclick="load();">Load</button>
    <button onclick="opendev();">Open Dev Tool</button>
</div>
test
<webview id="webview" preload="webview.js" src="http://google.com" style="position:absolute;width:100%;height:100%;"></webview>
<script type="text/javascript" src="browsewindow.js"></script>
</body>
</html>

webview.jsはデバッグログを出力するだけです。

"use strict";

console.log("webview.js");

browsewindow.jsは画面のボタンに対する処理を書きます。

"use strict";

console.log("browserwindow.js");

function load(){
    let url = document.getElementById("url").value;
    let webview = document.getElementById("webview");
    webview.setAttribute("src",url);
}
function opendev(){
    let webview = document.getElementById("webview");
    webview.openDevTools();
}

WebStorm上ではこんな感じになります。ちょっと見にくいですが。。
f:id:koichi0814:20161127130108p:plain
 

3. 実行結果

実行するとこのようなウィンドウが表示されます。
f:id:koichi0814:20161127130414p:plain
 
このときのデバッグログの表示を確認してみましょう。
f:id:koichi0814:20161127132442p:plain
index.jsとbrowserwindow.jsの文字が表示されている事が分かります。
メインプロセスとレンダラプロセスではログの出力が異なるようです。
そしてレンダラプロセス内のwebviewタグで指定したwebview.jsのログが表示されていません。
ここでかなりハマりました。
メインプロセスとレンダラプロセスが頭の中でごっちゃになってしまって、 メインプロセスではconsole.logが出力されて、レンダラプロセスでは出力されないものだと思い込んでしまいました。
メインプロセス(index.js)側では最初console.logを出力しておらず、 console.logが表示された方がメインプロセスだと勘違いしていたから余計に分からなくなってしまいました。
 
ではwebview.jsのログを探してみましょう。
ウィンドウにフォーカスを当てて、option + command + I (アイ)を押すとデベロッパーツールが表示されます。
ここで出力されているログはなんと「browserwindow.js」でした。 f:id:koichi0814:20161127132043p:plain
 
webview.jsのログは一体どこへ?
ウィンドウ(index.html)の「Open Dev Tool」ボタンを押してみましょう。
このボタンはindex.htmlのwebviewに対してデベロッパーツールを表示するようにjsを書いています。
f:id:koichi0814:20161127133801p:plain
ありました!
こんな所に表示されるので、Electronのメニューバーやショートカットキーでデベロッパーツールを表示させてログを確認していると、 思わぬ落とし穴に嵌りそうです。
 

4. まとめ

f:id:koichi0814:20161128002717p:plain
こんな感じでしょうか。
レンダラプロセスでのconsole.logも全部WebStormに出てくれたら良かったんですがね。
 

5. 未解決の問題

ついでに現時点でよく分かっていない問題があるので、誰か教えてくれるかも知れないという期待を込めて書いておきます。
それはデバッグ実行時にブレークポイントで止まってくれるのがメインプロセスのみという問題です。
WebStormだからなのか、WebStormでもちゃんと設定すれば止まってくれるのか分かっていないのです。
ブレークポイントで止まってくれていればconsole.logなんて出さなくても良い筈なんです。。。
念のため設定情報を貼っておきますね。
f:id:koichi0814:20161128004256p:plain
ちなみに、JavaScript file:のところに指定してもしなくてもブレークポイントで止まるのはメインプロセスだけでした。

#わいた温泉郷 という所に行って来ました

f:id:koichi0814:20160918223956j:plain
 
この写真は はげの湯温泉 旅館 山翠 の窓から撮影したものです。
当日は大雨の警報が出ていたのにもかかわらずこの地域のみ晴れるという幸運に恵まれました。
 
目の前に広がる景色の中、モクモクと出ている蒸気の所が「わいた地熱発電所」です。
住民の方々が作られた発電所だそうで、日本で16年ぶりの地熱発電所になるとのこと。
地熱発電について調べてみると日本は火山大国なのに意外と地熱発電所は少ないようです。
 
この写真は早朝に撮ったんですが、霧がすごく出ていてまるで天空の地熱発電所を見ているような気になりました。
天空の城で有名な竹田城跡の倍の標高750mもありますからね。
 

はげの湯温泉 旅館 山翠

f:id:koichi0814:20160918233324j:plain
どうしても頭の方の「はげ」しか思い浮かばないんですが(笑)
ロビーにはお土産が置いてあって「はげソーダ」というソーダが売っていました。
「実際にはハゲません」というコメントも付いていて、これは全力でネタにしてくれと言わんばかりに(笑)
写真撮り忘れたのが残念〜。
 
こちらの温泉は美肌効果があるそうで、確かにツルツルしている感じです。
帰って来て2日経ちますが、二の腕なんかはまだツルツルしている感じがします。
 
f:id:koichi0814:20160918232357j:plain
f:id:koichi0814:20160918232403j:plain
旅館では新鮮な刺し身が出てきて、これがまたぷりっぷりで美味しかったんですよ!
私はお酒が飲めないので、もうずっと食べていました。おかわりしたいぐらいに!
隣からは「あれ?もう刺し身がない」という声が聞こえてきましたが、それぐらい箸が止まりませんでした(笑)
 
自分のお土産にはこちらの2つを買いました。
「牛乳かすたーどぱい」も「シェフのわたぼうし」も妻が美味しいと言っていたので超オススメです。私が美味しいと言うと大体妻の口に合わない事が多いのですが、今回は意外と意見が一致しました(笑)
私は「シェフのわたぼうし」がお気に入りです。
作っている所が同じ会社なので両方美味しいのも頷けますね。
f:id:koichi0814:20160918234432j:plain
 

地熱を利用してパクチーの栽培

f:id:koichi0814:20160919000049j:plain
植えたばかりのパクチー。この台が他にも何個もあって、収穫体験もさせてもらいました。
手で引っこ抜くだけで簡単に収穫出来ました。
 
f:id:koichi0814:20160919000605j:plain
向こうの方に生い茂っているのが収穫用のパクチーです。
左右に分かれている所を収穫したんですが、結構な量です。はい。
 
このあと収穫したパクチーを麻婆豆腐に和えたりして戴きました。
初めて食べたんですが、天ぷらにしても美味しいかもって思いました。
天ぷらで思い出したけど、この山で山菜とか採れないのかな?と思ってみたり。
 

小国両神社

f:id:koichi0814:20160919001743j:plain
途中立ち寄った神社です。周りが山だからか何か神々しいものを感じます。

f:id:koichi0814:20160919002409j:plain
この絵馬の大きさ。これが絵馬なんですって。
他にも博物館に置いて有りそうなものもあって、面白い体験が出来ました。
ここでも写真少なめだったのが心残り〜。
 

まとめ

わいた温泉郷がある熊本県阿蘇郡小国町は崖のような階段の上にある神社や、山の奥の方にある祠などカメラが好きな人には特に面白いと思える題材が沢山あります。
温泉宿も他にもあるので、今度は違う宿に泊まりつつまだ行っていない所への散策もでき、非日常を味わうにはもってこいの場所だと思いました。
今度行ったらもっと写真撮りたいと思います。
ちなみにわいた温泉郷での撮影は約700枚でした。
まだまだ撮り足りない〜。

千なのか千尋なのか - 名前はきっと大事です

名前の漢字をたまに間違えられる事があります。
「功」が正しいんですけど、たまに「巧」になっている事があります。
(入社したてなので最近ありましたね(笑)でも怒っていませんよ(笑))
 
それより残念なのは、以前の職場でよくあった現場に入ると付与されるメールアドレス間違い。
koichiが正しいのですが、日本語読みっぽくkouichiとなっている時ははもう本当に残念です。
細かい事ですが、私からすると間違いなんです。
 
でも間違いだと思っているのはこちらだけで、他の人はそう思っていないかも知れません。
世の中のコウイチさん全員がこの u が入るの嫌いとも限らないし、逆に u が入っていないと嫌だという人も居るかも知れません。
 
どっちでも良いやんって思うかも知れませんが、
極端にいうと本人にしてみればアイデンティティを否定されたように思うかも知れません。
漢字もフォントによっては大分変わって見えます。
その人が普段使っているフォントはその字が当たり前だけど、
他の人からは普通じゃなかったり。
 
上手く表現出来ないけど、
そういう間違いには歩み寄りが大事だと思います。
相手が言っている事を理解する姿勢とか、何かそういうの。
上手く表現出来ないけど。

祝!SIerを卒業して1ヶ月経ちました

現在


ついにSIerから飛び出しました。
今はとある事業会社でプログラマーをやっています。
(社内SEと書かないのは何かSIerっぽくて嫌なんです。)
 

過去


社会人になって10数年SI業界にどっぷりと浸かっていまして、
ここ数年クラウドやIoTやら新しい技術というか仕組みが出て来ていたのに、
本業で使う事は全くありませんでした。
 
今思えば最初にプログラマーとして就職した会社は自分の会社でシステムを開発して売って行く感じだったのですが、会社に体力が無かったので新しい事をやろうとして失敗していた記憶があります。SIはSIなんですが、ただの下請けではなかった所は良かったと思います。
 
その後入った会社は完全なSIerでした。
1社は受託開発で、もう1社は客先常駐派遣でした。
受託開発はまだ面白かったです。自分の思い通りに仕事が出来ていた分、楽しい部分も辛い部分も味わえた気がします。
客先常駐派遣の方は、仕事をするのにも面接が必要という事にビックリしました。本当にビックリしてしまって自分の会社ってどこなんだろうという気持ちで3年程過ごしました。
3年も?と思うかも知れませんが、月に1回の帰社日があるだけなので、
どんな社員が居るのか、
どんな仕事をしているのか、
どんなスキルを持った人が居るのか、
全く分かりませんでした。
 
1社目のSIerは受託開発だったので自分で色々やる事が多かったのですが、
客先常駐派遣の方は単なる技術者で、やる事は決まっているのでそれ以外の事は基本的に他の人がやっていて、どんどん考える事が無くなって行きました。
人月単価というのにも驚きました。
1ヶ月の契約時間が160〜180時間などと決まっていて、それを下回れば会社に入るお金が減って、上回れば増える。下回っても自分に支払われる給料が減る事はありませんが、残業して上回れば残業代として加算されるという感じでした。
 
新しい技術や仕組み(自動化など)で効率を上げて作業時間が減っても会社に入るお金が減ると赤字社員となるのです。
短時間で成果を上げるとお客様には喜ばれますが、やり過ぎると赤字になるわけです。
会社としても収益が減るので、作業時間は下回らないようにして欲しいと何度も言われました。
ダラダラしないと会社からの評価が下がるんです。
こんなのおかしくないですか?
こんなビジネスモデルがおかしいと思います。
新しい事にもチャレンジ出来ないし、ある程度ダラダラしないとダメだなんて。
 

ターニングポイント


こういう事が随分続いていた時に、これじゃあダメだと思ってやりだしたのが社外の勉強会への参加でした。
そのときの心境はこちらに書きました。

k-koba.hatenablog.com

2014年がターニングポイントとなったのは確実ですね。
華やかなイメージがあったWeb業界の人達は、凄く主体的に行動を起こせる人が多い事や、同じSIerの中でも新しい取り組みを実際の業務に入れていたり、実は常駐先の人がMicrosoft MVPで同い年で勉強会主催者だったり、学生なのに(というのは語弊がありますが)学生でもどんどん新しい事を学んでいたり、OSSのコミッターだったり、それはそれは凄い人がたくさん居ました。
 
いつかそういう人達と一緒に新しい事をやりたいと思うようになりました。
でもまずは自分の会社でそういう雰囲気作りをしようと思って社内勉強会も何度か開催しました。付き合って下さった方々には感謝しています。
残念ながら、そもそも客先常駐で月に1回しか集まらない環境では社内で何かをするという事自体途方も無い労力を必要とするので長続きはしませんでした。
 
そんな中勉強会でたまたま知り合った人が、これから自分がやりたい事を既にやり始めていて、今まで自分がやって来た事が活かせそうで、遡ること高校の頃の経験も活かせそうな会社だったので思い切って人生をピボットしました。
 
たまたま35歳でプログラマー定年説の年齢ですが、派遣プログラマーやSEの35歳と事業会社のプログラマーの35歳とでは全く違うと感じています。
事業会社なのでずっとプログラムを書き続ける事もないと思いますが、事業自体が面白いのでプログラミング以外の仕事も面白そうです。
 

現在~未来


今はAWSやkintoneを使って社内の効率化を図っています。
言語は専らPythonです。楽です。
AWSを使った事ないままAWSの勉強会に参加した事があって、AWSやってる人って普段からEC2とかS3とかlambdaとか横文字言葉を言っているのを意味も分からず聞いていたのですが、最近漸く分かりました(笑)
ただのサーバーとストレージと実行環境かよって。それぐらいSIerAWSに疎い人が多いんじゃないかな?自分だけかもですが。
 
極言暴論じゃないけど、いわゆる社内SEと呼ばれる人達(もしくはそれに変わる新しい中の人達)がAWSを始めとするクラウドやIoTを使い出したら、今のSIerは本当に無用になるんじゃないかな?
社内の事に詳しい人がどんどん攻めのITをやって行くスピードに社外のSIerが追いつける筈もないと思います。
社外に出すのが面倒なので自分たちでやってしまうというのが今の感覚です。
 
今後はモバイルアプリやIoTにどんどん力を入れて行くのでとても楽しみです。
 
ついでに今の会社の事を少し書いておくと、今までの会社には無かった事の一つが毎朝の朝励です。
毎日交代で司会と3分間スピーチがあり、スピーチに対しての意見の発表など、全員が積極的に意見を述べていて朝から頭の準備運動が出来ていてシャキッとします。
こういうの結構好きです。
それに毎週月曜日には社長の講話があるので、会社がどういう方向に向かっていっているのか再確認出来ますし、やる気を起こさせて貰えるのでこれが凄く良いです。
朝礼がダメだという人も居ると思いますが、それは朝礼の内容がダメなんだと思います。
私も以前の会社の常駐先で社員がスピーチをしている朝礼を色々見て来ましたが、総じて声が小さくて何を言っているのか分かりませんでした。こういうのはさっさと止めた方が良いんじゃない?といつも思っていました。
 
今の会社には面白い朝励があります。
入る前にも色々聞いていましたが、入ってから社員全員の熱さを肌で感じています。
私も負けないようにテンション上げて行きたいと思います。
 
廊下ですれ違うときに、うつむいて歩く事もなくなりました(笑)
SIerで客先常駐の皆さん、うつむいて歩いていませんか?(笑)
朝の「おはようございます。」も半径1mぐらいしか聞こえない声じゃないですか?
もっと活き活きと働く方が自分にも家族にも会社にも良いと思いますよ。  

おまけ


入社祝いとして課長からこんな本をプレゼントしてもらいました。
読みたいと思いながらも読んでなかった本なのでちょうど良かったです。
表紙だけで嫌煙していたのが勿体無かったです。
最初の「日本語版まえがき」を読めば後はスラスラ読めます。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 
 
こういうのを書いているとこのテーマにピッタリだったかもですね。
この回は行きたかったのですが、社員旅行のため行けなくなったのが残念です。
でも人生初の社員旅行なのでそっちはそっちで楽しみです。 devlove-kansai.doorkeeper.jp  
 
それと、ちょうどクラウドに強い会社の合同採用イベントがあるそうなので、
情報交換のために参加しようと思います。
※転職するつもりはありません(笑) kansai-recruit.connpass.com

RailsチュートリアルがCloud9に対応していて、めちゃくちゃ簡単になっていた

Rails

f:id:koichi0814:20160604211736p:plain 画像:http://rubyonrails.org/
 
Railsと言えばまずは↓↓↓ここですよね?
railstutorial.jp  
2年前にはじめてRubyをやったとき、Railsを覚えるならここが良いという事を聞きました。
これを一通りやれば大体分かるとはいえ、それはそれはとても長く面倒くさい道のりでした。
 
何が面倒って全部ターミナルでやらないといけなかった事です。
Railsをインストールすると色んなフォルダが出来て、初心者にはどこに何のファイルがあるかとか覚えるのが大変だし、いちいちコマンドでその場所に移動したりしてファイルを開いて・・・
しかもVimで(もしくはviで)・・・
正直なところ、当時は2014年にもなってメモ帳かよ!って思っていました。
Vimをメモ帳というのは言い過ぎました。単に私のスキル不足です。)
 
普段からIDEに慣れ切ってしまっている者としては、ああいうのが本当に面倒で何より疲れてしまうんです。。
このチュートリアルも5章ぐらいまでやりましたが面倒で飽きてしまいました。
 
で、今回久々に最初からやり直そうと思ったら、
Cloud9というクラウドIDEを使ってやるようになっていて、
環境面の敷居がグーーーーーンと下がっていました。
RubyやGitも最初から入っているので開発に必要なツール類のインストールが不要で、どこにファイルがあるかも簡単に分かるし、入力補完も効くし、無料だし。
GitHubやBitBucketとの連携も簡単と至れり尽くせりでした。
ブラウザ上で全て完結するので、Windowsしか持っていない人でも気軽にRubyを初められると思います。
WindowsでもRubyを動かせるけどちょっと環境が特殊だし、困ったときに詳しい人が近くに居なかったりする事が多いのでそういう面でもこのクラウドIDEは有用だと思いました。
 
そういう訳で今回はチュートリアル完走出来そうです。
 
これもっと早く誰かに教えて欲しかったです。
きっとそういう人多いと思うので書いてみました。
 
各種ハンズオンもクラウドIDEとか使うと環境で躓いてしまうという事が減るんじゃないかと思いました。