yuw27b’s blog

技術メモと雑記

Content Security Policyの今後(2016年10月現在)

先月の勉強会での発表の内容と少し重なりますが、CSPの各レベルの仕様とブラウザ対応状況などのまとめです。

Content Security Policyとは

CSP (Content Security Policy) - Web セキュリティ | MDN

ざっくりですが、WebサイトからXSSの危険を取り除くための仕様です。
現在は、サーバ側でHTTPヘッダーにCSPを追加することで利用できます。

きちんと指定すればWebサイトの安全性が高まるということで、私もJavaScriptがいろいろしているサイトには導入してみているのですが、まだまだ仕様が変わっていきそうな雰囲気ですね・・・。


Content Security Policy Level1

W3Cの公式ページ

Content Security Policy 1.0
※最終バージョンの内容はここにある↓
https://www.w3.org/TR/2012/CR-CSP-20121115/

ブラウザ対応状況

Can I use... Support tables for HTML5, CSS3, etc

  • 長い間「勧告候補」だったが、Level2に引き継がれてこちらは今後の更新はないようです。
  • IE10以降とモダンブラウザが対応。※ただしIEは「X-Content-Security-Policy」
主な機能
  • 「default-src」「script-src」「style-src」等のディレクティブに、コンテンツの読み込みを許可するドメインを指定できる
  • inlineでの実行を許可するかどうかを指定できる
  • script-src(JavaScript)に関しては、evalの実行を許可するかどうかを指定できる
  • レポートの機能


Content Security Policy Level2

W3Cの公式ページ

Content Security Policy Level 2
2016年10月現在勧告候補

ブラウザ対応状況

Can I use... Support tables for HTML5, CSS3, etc


Content Security Policy Level3

W3Cの公式ページ

Content Security Policy Level 3

  • Working draftの段階なので、ブラウザ実装等はこれからと思われる。
  • fetchやService Workersなどの、新しい(?)仕様への対応
  • strict-dynamic他、いくつかのディレクティブの追加

いろいろと追加されているようですが、草案段階なのでまだ変わるかもしれないですね。


本当に安全なのか問題

Googleのエンジニアによる論文

発表のスライドでも触れましたが、CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy という論文が発表されています。
これによれば、現在のCSPではXSSの危険を完全に取り除けているケースはほとんどないそうです。
特にホワイトリスト経由の攻撃が可能である場合が多い、と指摘されているのですが、
そうなると外部ドメインからJavaScriptを読み込む場合は、CSP(Level 1)ではXSSを防げないことになります。

論文中ではそこで、CSP Level2および3で実装予定のnonceとstrict-dynamicが有効だ、と述べられています。
が、CSPの実装を待てず(?)に、XSS-Protectionヘッダという新しい仕様の提案も出ているようです。
こちらが詳しいです:
XSSを防ぐ新しいXSS-Protectionヘッダ - あすのかぜ

使う側としては、仕様の混在はできれば避けてほしいところですが、今後どうなるのでしょうか。


nonceによるホワイトリスト

※CSP Level 2における「nonce」についてです。XSS-Protectionのnonceはまた別の仕様です。

例えば、https://example.comから、JavaScriptファイルを読み込みたい、とします。
Level 1では以下のようにCSPを記述していました。

Content-Security-Policy: default-src 'self';
script-src 'self' https://example.com

Level 2では、上記に加えてnonceを利用した記述ができるようになります。

Content-Security-Policy: default-src 'self';
script-src 'self' 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'

HTML側でexample.comJavaScriptファイルを読み込むときには、

<script src="https://example.com/lib.js" nonce="Nc3n83cnSAd3wc3Sasdfn939hc3"></script>

のようにすれば読み込むことができます。

どちらもホワイトリストの指定ですが、nonceを使用するほうが安全性が高い、と前述の論文でも述べられています。
また、JavaScriptだけでなく、例えばCSSを外部から読み込む場合も、同様にして使用できます。



hashによるホワイトリスト

こちらはなかなか豪快(?)な仕様です。
インラインスクリプトのコードを暗号化したものをあらかじめCSPに記述しておくと、そのコードは実行可能、というものです。
なので、CSPのほうには暗号を記述します:

Content-Security-Policy: script-src 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZ..............'

例として考え付くのは、Google Analyticsのコードを暗号化したものを指定しておき、
HTML側ではいつもの(?)var _gaq = 〜のようなAnalyticsのコードを貼り付ける、という場合でしょうか。

※CSPではデフォルトでinline-scriptを許可しておらず、また許可してしまうと安全性は下がるので、不許可が好ましいのですが、
そうするとGoogle Analyticsのコードをわざわざ個別のファイルにしてのように読み込む必要がありました。
このhashを使えば外部ファイルにする必要はなくなります。


strict-dynamicとは

JavaScriptを対象とした仕様です。
こちらはLevel 3からの仕様なので、今後変わるかもしれませんが、2016年10月現在の仕様書によれば以下のようなものです。
仕様書の例そのままですが、

Content-Security-Policy: script-src 'nonce-abcdefg' 'strict-dynamic'

のようにCSPを記述し、HTMLでは以下のようにJavaScriptを読み込むとします。(nonceが一致しているので読み込まれます!)

<script src="https://cdn.example.com/script.js" nonce="abcdefg" ></script>

さらに、
https://cdn.example.com/script.js」内に以下のようなコードがあるとします。

document.write('<scr' + 'ipt src="/sadness.js"></scr' + 'ipt>');

このとき、「'strict-dynamic'」があると、この「sadness.js」は読み込まれません。
(逆に考えると、CSP Level2までは読み込めてしまうということですよね・・・だから安全でない、と言われるのでしょうか。)

ただし、

var s = document.createElement('script');
s.src = 'https://othercdn.not-example.net/dependency.js';
document.head.appendChild('s');

のような記述の場合は読み込めるそうです。



おわりに

仕様書やら論文やら、それなりにまじめに読んだつもりですが、そこまで英語に自信があるわけでもなく、おかしな解釈をしている点があるかもしれません。
何かお気付きの点があればコメントいただければ幸いです。

NDS第49回勉強会に行ってきたよ

少々日が経ってしまいましたが、NDS(長岡IT開発者勉強会)第49回勉強会に行ってきました。
今回のテーマは「セキュリティ」ということでしたが、貴重なお話がたくさん聞けました。
めずらしく(?)メモを取りながら聞いていたので、感想など書き残しておこうと思います。
そしてそんなところに紛れて発表もしてきたので、スライドも貼っておきます。

情報セキュリティ研修応用編ダイジェスト (30min) hiro_ishibashiさん

サイバー攻撃の歴史から!意外と通史で見ることはなかったので、新鮮な視点。
標的型攻撃
FireEye
ITストーキング
gmailはexeが送れないらしい。exe.zipも検知されるらしい。
ファイル共有サービスを使う
従業員より役員の方が標的型メールを開封しやすい
標的型攻撃は、社内で1人でも開封したら意味がない。10人が1人になっても同じこと。
→訓練は開封させない訓練ではなく、開封後の対策を訓練すべき。
ルールと運用の不整合。セキュリティといえども経営レベルの問題。
TCP/IPは善意を前提とした仕様
CSIRTと消防署、インシデントカード
未来には119番みたいな番号ができたりする・・・?
メール・FAX禁止の金融機関。まあ金融機関は仕方ない気もする。

Webサイト改ざんの事例紹介について (15min) nomeshi さん

事例というので汎用的(?)事例かと思ったら、知人の例だった。具体的でありがたい!
FFFTPで接続すると知らないファイルが・・・というのは、実は大昔に身に覚えがある。大事には至らなかったけど。)
Web diary professionalの脆弱性とのこと。まあ、WordPressにもあったし・・・。
Webサイトの放置はなんであれ危険ですよね。
ルワンダgoogle。あるのかgoogle・・・。
偽のショッピングサイトに飛ばされるようなので、クレジットカードの番号を盗んだりするんだろうか。
google search consoleっぽいファイルもウイルスらしい。sitemap.xmlも。

Content Security PolicyとWebサービスのセキュリティ対策 (15min)

自分の発表です。
スライドはこちらに

結局パスワードってどうしたらいいの? (30min) occhie3さん

情報モラルの布教大事!素晴らしいお仕事だと思う。
今の学校ではそういう講習があるのか。
情報セキュリティワークショップ
パスワードリスト攻撃ってやっぱりなくならないのね。不正ログインもすごく多い。
うちのサービスも簡単なパスワードは撥ねるべきなのか・・・。うーん、無理そうw
同一ホストからの連続ログイン試行を拒否、これも実装すべきか。
sha-1はもうダメ。sha-2とsalt化でDBに入れるべき。ハッシュ化を1000回くらい繰り返すのも有効。

セキュリティ (30min) MasatoMatsuokaさん

INTERPOLにサイバー警察ができたとのこと。ニューロマンサー)の時代が来るのか(違)。
情報セキュリティ>サイバーセキュリティ(情報のほうは紙とかも入るからくくりが大きい)
アリアンツの格付け(?)によると、サイバーの脅威は経営リスクの第3位。
いまは変電設備もデジタルなので、攻撃できるとのこと→サイバーでフィジカルを壊すことができる。
銀行口座のお金を移された例もある。
ネットで繋がってないところも→例えば工場の内部に入る従業員や保守業者のパソコンから侵入する。
工場に(保守に)行く人がアクセスするようなページにマルウエアを仕込む。JARファイルとかドライバとか。
一般的なハッカーより、発電所なら発電所に詳しい人の方が早くハッキングできてしまう。
システムが動かなくなるとしてもパッチを当てろ!
2016年の予想:APTはメモリ等に移行(ファイルではない)、ランサム継続、モバイル、IoT
Android Pay, Apple Pay、株取引などが狙われる。iPhone7気をつけろ、とのこと。少額で広範囲から詐取する見込みとのこと。
・個人としては、とにかく踏み台にされないように。ウイルスソフト絶対。パスワードは複雑に。
とにかく自分のアカウントを守れば世界は平和に。他人に迷惑をかけない!
ご自身はMacカスペルスキーファイアウォールLittle Snitch)を使っていらっしゃるそう。

emailを安全に使うための心がけ (15min) civicさん

メール開くだけなら大丈夫そう。確かに。添付ファイルを開くのがダメなんですよね。
メールのFromはあてにならない。つまりオレオレ詐欺
メール内のリンクは使わない。
メールソフトやOSの警告は無視しない。基本だけど大事ですね。
メールの添付ファイルはOSはガードしていない。例えばzipだとセキュリティソフトも処理できないケースがある。
添付ファイルそのものが危険。
Adobe,microsoft,Javaは最新に。MacJava危険。
一般人の場合は、添付ファイルを開く前にウイルスチェックすればほぼ大丈夫。
IPAのバージョンチェッカー
zipやexcelのパスワードを別メールで送るのは全く意味がない。日本だけ。
.exeを暗号化して.zipにするとgmailでも送れるらしい。
MMSにもウイルス乗せられる。

C#関連で何か (15min) alightさん

MSのMVPの方。
Azure Active Directory B2Cについて
パスワードの変更対応サービス自作するの、確かに面倒だった。し、自前のユーザー管理システムはセキュリティに不安が残るのも事実。
なので、認証の外部サービスいいなあ。
(うちのサービスクラウドにできない、というか月額みたいな契約ができないから無理、というつらみ。。。)
Azureのコンソール画面けっこうかっこいい。
APIとして使えるの良さそう。
契約できそうなプロジェクトがあったらぜひ試してみたい。

SG受験のすすめ (LT 5min) ゑぬぽいさん

管理部門の人向けの試験、というの良さそう。「マネジメント」が入っているのはそういうことなのか。
全国的にリテラシーが上がるといいですね。
合格率すごい高い。のは最初の試験だったから?
今のところIT関連の資格とは無縁で来てしまっているので、何か勉強するのも良いかも、と思ったり。



以上、ちょっと自分用メモの側面が大きいですが、大変有意義な会でした。
ぜひまた長岡まで足を伸ばしたいと思います。
ありがとうございました!

stylelintを使い始めたので設定例など (2016年9月更新)

※2016年9月13日更新:stylelintのアップデートに伴い、ルールの記述方法が古くなっていたものがありましたので、訂正しました。

stylelintって?

名前のとおりCSSのlintツールです。
設定したルールから外れた書き方をすると警告してくれます。

CSSを書くにあたって、インデントにタブを使うのかスペースを使うのか、スペースなら何文字分にするのか、「{」の前にスペースを空けるかどうか、といった「書き方」を統一する目的で使います。バリデーション(CSSの標準仕様に準拠しているかどうかの判定)は行いません。

公式サイト:http://stylelint.io/
日本語情報だとこちらが分かりやすかったです:CSSのLintをstylelintにする - Qiita


stylelintの特徴

  • ルールのカスタマイズができる
  • ルールセットの使い分けも簡単

CSSのlintツール自体は他にもありますが、stylelintが気に入った理由は、ルールのカスタマイズが簡単、ルールセットを簡単に切り替えられる、という2点です。
私は、デザインカンプをもらってHTML+CSSをコーディングする、という作業を定期的にするのですが、クライアントさんによってCSSのコーディングルールに違いがあるため、「このクライアントさんは小数点の前にゼロを入れちゃダメだったな」とか「こっちのクライアントさんはmargin-topは禁止だったな」とか、毎回資料を確認して見直しをしていました。
stylelintであれば、クライアントごとにルールのプリセットを作成しておき、警告の出た部分を修正するだけです。設定できるルールもたくさんあるので、これまでのところ、チェックしたい項目はすべてカバーできています。


インストールする

stylelintはnode.jsとnpmを使用するので、node.jsをインストール(インストールおよびバージョン管理方法は様々あるので、検索してみてください)してから、ターミナルで

npm install stylelint

と打つとインストールされます・・・と、公式サイトにありますが、私の環境では、

npm install -g stylelint

としてグローバルにインストールしないと、パスが通りませんでした。

次に設定ファイルですが、「.stylelintrc」という名前のファイルを用意します。ルールについては、公式サイトまたは、冒頭にあげた日本語情報が分かりやすいと思います。
全ルールを網羅したサンプルもstylelintのGitHubリポジトリにあります。


.stylelintrcの例

私が基本セットとして使っているルール一覧です。
多少ゆるめのルールになっていたり、個人的な癖もありますが、それなりに一般的な「書き方」になっているかな、と思います。
(打ち消してあるプロパティは、stylelintのアップデートに伴って使用できなくなった古い表記方法です。)

string-quotessingleシングルクオートを使う
color-hex-caseupper16進数の色コードは大文字
color-hex-lengthshort色コードを省略できるときは省略する
color-no-invalid-hextrue色コードがおかしい場合に警告
number-leading-zeronever数字の前にゼロをつけない
number-no-trailing-zerostrue数字の後ろに(不要な)ゼロはつけない(「10.0px」はダメ)
number-zero-length-no-unit
length-zero-no-unit
true「0」の場合は単位なし(「margin: 0px;」はダメ)
value-list-comma-newline-afternever-multi-lineカンマの後で改行しない
value-list-comma-space-afteralwaysカンマの後は必ずスペースを入れる(「Arial, Helvetica」)
declaration-colon-space-afteralwaysコロンの後に必ずスペースを入れる(「margin:0;」はダメ)
declaration-no-importanttrue「!important」は使わない
declaration-block-no-single-linetrue1行で全部書かない(「a {color: #000; }」はダメ)
declaration-block-single-line-max-declarations01行で全部書かない(「a {color: #000; }」はダメ)
block-no-emptytrue空のブロックを許可しない
block-opening-brace-newline-afteralways「{」のあとは必ず改行
block-closing-brace-newline-beforealways「}」の前に必ず改行
block-opening-brace-space-beforealways「{」の前に必ずスペース
selector-combinator-space-afteralways「div +p」はダメ(「+」や「>」のあとに必ずスペース)
selector-combinator-space-beforealways「div+ p」もダメ(「+」や「>」の前にも必ずスペース)
selector-list-comma-space-afteralways「div, p」のとき、カンマの後に必ずスペース
rule-no-duplicate-propertiestrueプロパティの重複を警告(「display」が2個あるとか)
declaration-block-no-duplicate-propertiestrueプロパティの重複を警告(「display」が2個あるとか)
rule-trailing-semicolonalwaysルールの後に必ずセミコロン
declaration-block-trailing-semicolonalwaysルールの後に必ずセミコロン
indentationtabインデントはタブ

※設定ファイル(.stylelintrc)はこれ
設定ファイルを見てもらうと分かるのですが、上に挙げた項目のほかに、「property-whitelist」というルールにCSSの仕様上定義されている全プロパティを突っ込んでます。プロパティ名のスペルを間違えたときに警告してほしいからなのですが、もっとスマートな方法がありそうな気もしています・・・
それともやっぱりこればvalidatorの範疇かな。


使ってみる

ターミナルで、

stylelint xxx.css

とすると、ルールから外れた記述が見つかった場合に、

30:3     Expected single space after "," (selector-list-comma-space-after)
128:14 Expected "#f0bd25" to be "#F0BD25" (color-hex-case)
129:2   Unexpected duplicate property "background" (rule-no-duplicate-properties)

・・・というように出力されます。左端が行数/文字数なので、その部分を直していきます。

実行時に読み込まれるルールセットは、実行時のディレクトリにある.stylelintrcの内容が読み込まれます。.stylelintrcが見つからなければ、さらに上の階層にさかのぼって探しに行きます。


エディタのプラグインを利用してリアルタイムにチェック

このような実行方法でもいいのですが、エディタのプラグインを使えば、書いている最中にどんどん警告してくれるので便利です。
公式サイトにプラグインの一覧がありますが、現在AtomSublime Text、Visual Studio用のプラグインがあるようです。



GitHubのリポジトリを見ると、現在(2016年2月)も開発がどんどん進んでいるようです。新しいルールが追加されたりもしているようなので、何かあればまた追記したいと思います。

カレンダーUIを実装する依存なしのJavaScriptライブラリ

カレンダーUIを実装するJavaScriptライブラリの紹介です。
Webアプリ上の入力フォームに、日付を選択する項目を実装したときのこと。

input type="date" を使いたいのだけど・・・

HTMLのinputタグに、「type="date"」を指定すると、一部のブラウザではカレンダーUIを表示してくれますが、主要ブラウザすべてにサポートされるのはまだまだ先のようで、案件で使うのは難しそうでした(2016年1月現在)。
参考:Can I use... Support tables for HTML5, CSS3, etc
※この仕様自体が、WHATWGのLiving Standardsであり、HTML5の仕様として勧告されているわけではないので、ブラウザのサポートはなかなか進まないのかもしれません。

jQueryjQuery UIに依存したくない

カレンダー方式で日付を入力するUIとなると、まずjQuery UIのDatepickerが思い浮かびました。デザインも色々なパターンがあり、jQuery製ということで各種のブラウザ対応や安定性も保証できて良いのですが、最近はjQueryを使わないWebアプリの案件もあり、カレンダーのためだけにjQueryjQuery UIを読み込む、というのはあまり良い方法には思えませんでした。

「Kalendae」

それで、ピュアJavaScriptで動作するライブラリを探したところ、「Kalendae」というものに行き当たりました。
GitHubにコードとドキュメントがあります:GitHub - ChiperSoft/Kalendae: A javascript date picker that just works.

GitHubのスター数は1,700を超えており(2016年1月現在)、開発も止まっていないようなので、良さそう!ということで、使ってみることにしました。

特徴としては、

  • 依存ライブラリなし(※)
  • 単一の日付選択と、期間選択の両方が可能。他にもオプションはいろいろある。
  • click、changeなどのイベント取得や、リセットなど、必要になりそうなAPIはきちんと揃っている印象
  • 見た目はCSSでカスタマイズ可能
  • モダンブラウザとIE8に対応

※ドキュメントにも「依存はないよ」というようなニュアンスのことが書いてあるのですが、実際にはmoment.jsを使っています。ですがKalendaeにはstand alone版があり、こちらはkalendae.jsのコードにmoment.jsを含めて配布しているものなので、読み込むファイルはこれ1つで済みます。
(どちらもMITライセンスなので、ソースコードに丸ごと含めてしまっても問題ないわけですね。)
つまり、

  • 基本的には・・・stand alone版のkalendae.js
  • すでにmoment.jsを読み込んでいるよ、という場合は・・・moment.jsを含まないkalendae.js

を使えば良い、と思います。

ファイルサイズ

  • kalendae.js 34KB
  • kalendae.min.js 17KB
  • kalendae.standalone.js 132KB
  • kalendae.standalone.min.js 51KB

上記の他に、

  • kalendae.css 7KB
  • ボタン用のpng画像が1KB×2ファイル

(バージョン0.5.5で確認)

実装例

kalendae.cssとkalendae.standalone.min.jsを読み込んで、ボタン用の画像はCSSと同じ階層に置いておきます。
そこで以下のように書くと、

<input type="text" class="auto-kal">

こうなります
f:id:yuw27b:20160108230952p:plain

オプション指定例:

<input type="text" class="auto-kal" data-kal="format: 'YYYY/MM/DD', months: 2, mode: 'range', direction: 'future'">

f:id:yuw27b:20160108231824p:plain
(フォーマットを年/月/日、2ヶ月分表示、期間選択、未来の日付のみ選択可能)



jQueryなプロジェクトでカレンダーが必要なときは、しばらくはこのKalendarにお世話になろうと思います!

新潟へIターンしてWEBエンジニアをしている話

この記事は、地方在住ITエンジニア(元・地方在住も可) Advent Calendar 2015 - Adventarの19日目の記事です。

私が住んでいるのは新潟県新潟市で、政令指定都市ですので、カレンダーの「地方」の趣旨からするとちょっとぎりぎりですが、

ということで、多目にに見てもらえたら幸いです。

アラサーWEBエンジニア。
最近は、JavaScript4割、CSS3割、Ruby2割、PHP1割くらいの感じで書いてます。

東京から新潟へ

3年前まで東京でECサイトの制作をやっていましたが、結婚を機に新潟へ引っ越すことになりました。
引っ越すこと自体に不満はなかったのですが、「仕事どうしよう・・・?」というのは頭に浮かんでいました。

当時の会社から、リモートで続けるか、みたいな話もあったのですが、

  • 業務内容がちょっと希望の方向とずれてきていたこと
  • 家族以外に友人・知人のいない土地でいきなり在宅勤務では、完全に引きこもりになりそうなこと

から、きっぱり退職させてもらうことにしました。(今思えば少しもったいなかった気もしますが・・・)

新潟の求人

当時勤務していた会社は、採用したいときにはFind Job!を利用していたので、自分もここで新潟県の求人を検索してみましたが・・・
検索条件の「勤務地」のところに新潟県はないんですね。北陸と東北がありますが、その中に新潟県の求人は0件です。当時、約半年にわたってときどきチェックしてましたが、いつ見ても0件でした。
引っ越してから分かりましたが、こっちの求人は何と言ってもハローワークなのでした。

WEBエンジニアで探した求人の印象は、

  • 新潟県の平均給与額は東京都の7割くらいなので、IT関連でも同じくらいの感覚。
  • ただし、最先端の技術を求める求人が少ないので、高給なエンジニア職は見つけにくそう。
  • 車がないと通えないところに会社があるのは普通のこと
  • 自動車免許必須のところが多い(会社には電車で通えたとしても、客先には車で行く)
  • WEB制作専門で規模の大きな会社は少ない(10人以下が多かったと思う)
  • もう少し規模の大きなところだと、WEB以外の事もやっていてWEB部門もあるよ、っていう会社

東京に比べると数が圧倒的に少ないので、希望に合う求人が出るまで待てるかどうかが重要かもしれません。

今の働きかた

パートタイムのエンジニア(WEB専門の会社ではない)+フリーランス に落ち着きました。
ハローワークのIT関係の相談員さんに「パートでもいいんですけど」って言ったら、「そんな人は初めてです」って言われた記憶があります(笑)。ですが「事務職のカテゴリのほうにも、プログラミングが活かせる仕事がありますよ」っていうアドバイスは的中しました。そういえば、当時ハローワーク自体が車がないとかなり行きにくい場所にありました。

フリーランスのほうは、東京のWEB制作会社さんや、新潟のセミナー・勉強会で知り合った方から発注いただけている状態です。

現状には満足&感謝してますが、将来的には東京の会社に雇用してもらって新潟でリモートワーク、が理想かなあ・・・などと考えたりもしています。
これは新潟が、とかではなくて、私がそこまでフリーランス向きではない気がするからです。

東京に比べて困ること

だいたい他の方々が書いていたことと同じですが、

  • 技術書を売っている本屋さんが少ない
  • 勉強会などが少ない(でも、あることはありますよ!)
  • もし転職するとなると選択肢が少ない

といったあたりです。
また、私はある程度東京でエンジニア経験ができていて、情報収集の仕方とか、自分の目指したい方向とか、多少なりとも分かっているから地方でやれている部分もあると思います。新米エンジニアだったらどうだろう・・・、というか、新潟で生まれ育っていたらエンジニアにすらなっていなかったのでは?という気がします。


新潟FAQ

※他のかたのブログでおもしろかったので、僭越ながら東京でよく聞かれる質問集を(3年しか住んでないけど)。

  • お米とお酒でしょ?

まあそうです。お米は本当においしいです!それ以外にもたいていの野菜と果物、肉、魚、卵と県内産のものが手に入ります。

  • 雪がすごいんでしょ?

新潟市内はそうでもないです。屋根の雪を降ろすなんてことはあり得ません。積もっても備えがあるので、そこまで困ることは(今のところ)ないです。

  • 生活費は安い?

家賃や駐車場などは安いです。食費も、野菜、魚などをよくもらうので安いと思います。ですが、上にも書きましたがその分給与水準が低いので、余計にお金が貯まったりということはないです。

  • 車がないと生活できないの?

新潟市内だと、車なしでも生活はできると思います。が、車がないと行かれないレストランとかお店とかたくさんあるので、そのあたりの選択肢はだいぶ減ります。
あと、冬はスタッドレスタイヤ必須です。

  • 新潟弁てあるの?

あります。しかも地域によってけっこう違うようです。
私の場合、おばあちゃんと会話するのがけっこう大変で、最初の頃は半分くらいしか理解できませんでした。
逆に若い人は共通語に近い話し方をしている印象です。

  • 東京に戻ってこないの?

今のところ戻るつもりはないです。
仕事も、どうにもならなくなったらIT関連じゃなくても仕方ないかなあ、くらいに思っています。
もちろんエンジニアを続けられたら理想的ですけどね!



明日は@takushinoharaさんです。よろしくお願いします!