かろてんはこう思いました

フロントエンドエンジニアになりたいバックエンドエンジニアの雑記。

angular2でngFormを用いて双方向データバインディングを実現

angular2で双方向データバインディング

angularJSとangular2では、双方向データバインディングの方法が異なります。 今日はangular2を使って双方向データバインディングを実現していきましょう。

手順

  1. 準備
  2. FormsModuleを読み込む
  3. componentのテンプレートに[(ngModel)]を記述

準備

angular tutorialからgit cloneしてきます。

もろもろのmoduleのinstallを行い、ローカルサーバをスタートさせます。

git clone https://github.com/angular/quickstart.git
cd quickstart
npm install
npm start

FormsModuleを読み込む

app.module.tsにて、以下矢印部分2つを追記します。

// app.module.ts
import { FormsModule } from '@angular/forms’; // ←

@NgModule ({
  imports: [FormsModule] // ←
})

componentのテンプレートに[(ngModel)]を記述

// app.component.ts
import { Component } from '@angular/core';

@Component({
  selector: 'my-app',
  template: `
  <input [(ngModel)]="name">
  <h1>{{name}}</h1>
  `,
})

export class AppComponent  {
  name = 'Angular';
}

結果

f:id:karoten512:20170709120655g:plain

べンチャー企業で働く時は飢えることを覚悟しておいた方が良い

IT系ベンチャー企業と聞いてどんなイメージをお持ちでしょうか

 

特にIT系のベンチャー企業と言うと、短期間の間にゴリゴリ業績を伸ばし、儲かってそうなイメージがあります。

 

 

そういう会社ももちろんあります。

 

ただ、私がいた会社はそうではありませんでした。

 

以前いた会社は、法人化して間もないベンチャー企業でした。

よくある話なんですが、ベンチャー企業は設立間もないとお金がないので、

正社員を雇うほどの金銭的体力がありません。

 

そこで、正社員ではなく外注(個人事業主)として契約することがよくあります。

そのベンチャー企業はほぼ全員が外注として働いておりました。

 

フリーランスと言えば聞こえはいいでしょうが(最近何故か流行っている)、

貰った報酬から所得税・住民税・国民健康・国民年金等を自分で払払わなければなりませんでした。

すると残るのはアルバイトをしていたほうがマシかな、と思えるような金額です。

 

また報酬の額も、感覚的にはおかしなほど安いものでした。

社長が物欲のない人だったので(なんで会社を起こしたのだろうか)、これだけあれば最低限生きていける位の報酬を私たちはいただいておりました。

 

しかし皆が皆、社長のように玄米しか食べないとかいう質素な生活ができるわけではありません。なんなんですかね。社長の前世は僧侶か何がだったんだと思います。

 

そんな感じで、あの頃は常にギリギリの生活を強いられていました。

 

極限までランニングコストを下げるため、大家さんに直接交渉して、家賃をゴリゴリ下げてもらいました。

 

夏の暑い間はお湯は必要ないので、ガスの契約をしませんでした。

水シャワー、あれは心臓に悪いですね。やめたほうが良いと思います。

 

カーテンを買う余裕もありませんでした。もちろん冷蔵庫も買えません。

洗濯機は近所のコインランドリーですませていました。

あたりまえですが、テレビなんてありません。

平成も30年になろうかというこの世の中、三種の神器のうち一つも持ち合わせていない自分がいました。

 

部屋にあるのは机と椅子とベッドだけ…。

 

以前友人を家に招き入れたとき、こんなことを言われたことがあります。

「(私の名前)さぁ………早く脱獄できるといいね……」

 

そう、私の部屋は囚人の部屋のようでした。

 

つづく

 

フロントエンドエンジニアとは何か、バックエンドエンジニアとは何か

なんとなく使っていたフロントエンドとバックエンドと言う言葉を今一度整理してみました。

超ざっくりなので初心者向けです。

 

フロントエンドエンジニアについて

作るもの

フロントエンドエンジニアは、主に「ユーザの目に見える部分」を作ることが多いです。

 

例えばアマゾンのページにアクセスした時のことを考えてみましょう。

アマゾンのトップページには様々なリンクやボタンがあります。

そしてそれらのリンクやボタンを押すことができます。

 

このような、ユーザの目にみえて、

そして直接操作ができるような部品を作るのがフロントエンドエンジニアの仕事です。

 

必要なスキル

ただ部品を作るのが仕事ではありません。

部品を作る(コーディングする)スキルはもちろん、

ユーザにとって使いやすいデザインを考えるスキルも必要です。

 

扱う言語

扱う言語としては、主にHTML, CSS, JavaScriptなどです。

 

JavaScriptはその昔、

ページの部品(DOM)を動かしてちょっとだけ装飾を加えたりするくらいの小さな開発にて

で使われることが多かったようです。

 

しかし近年、開発工数を大幅に減らすことができ、

しかもよりユーザにとって使いやすい画面を提供することができる

JavaScriptフレームワークがどんどん出てきています。

 

よく使われるものとしては、

Googleが開発提供しているAngularJS、

Facebookが開発提供しているReact.js、

他にもBackbone.js、Vue.jsなどがあります。

 

これらのフレームワークの登場により、

ユーザにとても使いやすいページが簡単に実装できるようになりました。

そのため、以前に比べフロントエンドエンジニアの案件は増えているといえるでしょう。

 

 

バックエンドエンジニアについて

 

作るもの

バックエンドで開発する部分は、基本的にユーザからは見えない部分です。

 

先程の例で言えば、

アマゾンのトップページから商品を検索する際商品名を入力してエンターキーを押すと、

エンターキーを押すと商品名がサーバーに送られます。

 

すると、サーバー上にある大量のデータベースの中から、

商品名を含む商品が検索されブラウザへ帰ってきます。

こうしてブラウザに検索結果が表示されます。

 

このように、ユーザが送ってきた情報をもとに、

データベースを操作(追加・削除・検索・加工)するような、

目に見えない部分を開発しているのがバックエンドです。

 

扱う言語

よく使われているのが、JavaPHPなどです。

また少し前からかなり増えてきているのがRubyです。

 

特にRubyは、開発工数を大幅に減らし、

楽しく開発できるRuby on Railsというフレームワークが登場してからよく使われるようになりました。

ちなみにRubyを開発したのは日本人(Matz)です。

 

必要なスキル 

大量のデータを取り扱うことになるので、

データを加工したり、検索したり、追加したりするのをいかに早く扱うか、

というパフォーマンス部分はとても重要になってきます。

 

パフォーマンスを改善するにはアルゴリズムについての知識は必須です。

 

また、予約システムや購入システムなど、

いろいろな要素が絡み合う複雑なロジックを扱うこともあります。

それらの複雑な物事を整理する力などが必要となってきます。

 

フロントエンドエンジニアとバックエンドエンジニアは手を取り合おう

フロントエンジニア・バックエンドエンジニアはともになくてはならない存在です。

 

フロントエンドエンジニアがいなければ、

ユーザが触ることができる画面を作ることができません。

 

バックエンドエンジニアがいなかったら、

アプリケーションの機能そのものを作ることはできません。

 

フロントエンドエンジニアとバックエンドエンジニアが協力的に開発を進めることにより、

ユーザにとって使い勝手も良い高機能なアプリケーションを作ることが可能になるのです。

 

僕はバックエンドエンジニア(PHPer)だったのですが、

最近AngualrJSを使ってから、

画面をグリグリ動かせるJavaScriptがかなり好きになってきました。

 

ただなかなか癖がある(PHPもくせあるだろ!と言われそうですが)ので、

なかなか慣れるまで時間がかかりそうです。

 

頑張って勉強しよう。

とかろてんは思ったよ。

フリーランスエンジニアを雇う、企業側のメリット

最近フリーランスエンジニアと言う言葉をあちこちで目にするようになった。

 

一時期私もフリーランスエンジニアとして働いていた。

自由だった。出勤時間も自由だったし、作業場所も自由だった。

そんなメリットがあったのでフリーランスエンジニアになった。

しかし縛られないがゆえのデメリットもあった。

 

このように、多くの記事では、

フリーランスエンジニアとして働く「雇用側(正式には雇用ではない)」のメリット・デメリットについて触れている。

しかし、フリーランスエンジニアを雇う「企業側」のメリット・デメリットについて述べている記事は少ない。

 

そこで、企業側のメリットについてまとめてみたいと思う。

(デメリットはまた別の記事で)

 

・安く雇える

これは、「フリーランスエンジニアの単価は一般的なサラリーマンの収入に比べると高い」という事実に矛盾すると思う人もいるだろう。

ここで、サラリーマンの収入について「貰う側」「払う側」で考えてみたい。

 

貰う側からしたら

 サラリーマンの手取り = 給与 - 税金

 

払う側からしたら

 給与 = サラリーマンの手取り+ 税金 * 2

 

※サラリーマンは会社に税金の半分を負担してもらっている。

逆からみると、会社はサラリーマンの給与から天引きされる税金の2倍を払っている。

 

その他諸々含め、企業が25万の給与を支払う場合、会社が実際に負担している金額は40万程度だと言われている。

 

それに対し、フリーランスエンジニアは外注なので、税金を負担しなくてもよい。

それだけサラリーマンよりも高い「報酬」を払うことが可能だ。

 

ただし、必ず安く雇えるとも限らない。

単価の高いフリーランスエンジニアを雇った場合などは、やはり会社員にかけるお金よりも高い金額を払う必要が出てくる。

 

しかしそれでもなお、フリーランスエンジニアを雇うメリットがある。

それが以下の点だ。

 

・固定費を抑えられる

会社にとって、毎月出ていくお金(固定費)が少ないことはとても良いことだ。

 

社員を雇うと、毎月給与を払わなくてはならない。

その時会社が儲かっていなくても、かならず給与は発生する。

 

しかし、フリーランスエンジニアはプロジェクト単位での契約であることがほとんどだ。

つまり、プロジェクトが終わったら任期が切れる。すると、繁忙期以外は固定費を抑えることができる。

これは会社にとって大きなメリットだ。

 

 

このように企業側には、

・安く雇える

・固定費を抑えられる

というメリットがある。これは雇われる側の人には意外と知られていない。

 

昨今フリーランスエンジニアの需要がそれなりに高まっているのは、

あたりまえだが「個人のメリット」と「企業のメリット」の双方が存在するからだ。

 

美味しい話はその逆側の視点から見つめることも大事である。

 

そう思ったよ。

アウトプットの重要性を、今一度考えてみる

ずっと前から、アウトプットの重要性をといている人がとても多い。

  

インプットだけではダメだ。アウトプットをしたほうがよい。

結構耳タコだ。

 

でもなぜ、アウトプットをしたほうが良いのか。

 

私は、「頭の中の無定形なものが、定形なものになってくる」からだと思っている。

 

 

●人間の思考には、定形と無定形がある

 

基本的に人間の思考は雲のようなもので、生成したり消滅したり大忙しだ。

あれが食べたい、これが欲しい、眠い、次の会議の資料を作成しなくちゃ、これからどうなってしまうのだろう、など様々。

よく「思考がモヤモヤする」とか言ったりする。それと似ている。

 

しかも頭の中だけで話が終わらないのだから、たちが悪い。

外界の刺激はどんどん入ってくる。思考は次々姿形を変える。無定形だ。

 

その中でも、比較的定形なものはある。

よく見知っている物事だ。

頭のなかで「バナナ」を思い浮かべてみる。割りと正確に描ける気がする。

 

よく知っている物事は、定形で、

よく分からない物事は、つかみ用がなく無定形。そんな感じ。

 

 

●無定形なものをまず言葉にする

 

では、よくわからない物事を、わかるようにするにはどうしたら良いか。

 

言葉にしてしまえばよい。

 

そうすると、情報が不足しているので、たいてい古文書のように穴空き状態になる。

もやもやしたものを無理やり形ある言葉にしようとしているから当たり前だ。

 

その時大事なのは、古文書のどこに穴が開いているのか、ということだ。

これがわかってくればしめたものだ。

その何かを補いながら、再び言葉にすればよい。

 

古文書が出来上がってくる頃には、

無定形だったものが定形として、頭のなかにどんと鎮座しているはずだ。

 

 

自分がなぜアウトプットをしているのか、

最近わからなくなってきたので、こんなことを考えてみた。

 

書き終わってみると、自分の考えも古文書のようになっていて穴だらけだ。

きっとこの古文書の穴を埋めるほど、思考がクリアになっていく気がする。

 

穴空きの古文書を手に取りながらそう思った。

 

 

技術系ブログというものをはじめてみようかと思う

僕はこの春から、小さな会社の社内SEをしている。

 

もともとIT系の会社でなく、システム部門の立ち上げ役として新卒で入社。

その会社のIT系のノウハウは皆無。

上司はいない。

質問できる人もいない。

 

どうやって技術的なことにキャッチアップしていったら良いのか考えた末、

「何かしら発信していたらまさかり飛んでくるだろう」

の精神で技術ブログをやってみることにした。

 

気が向いたらぼちぼち投稿していくつもり。