あじちゃんのブログ。備忘録。

〜SEもOLなんですかね?

ブログを始めてから1年が経ちました。

11月の末に書いた文章なのでいま(2019/01/31)はちょっと思ってることが違ったりするけどまあ概ね同じ。


まず、このブログを始めた経緯は「転職」をするため。
Twitterかなにかでちゃんと情報発信していることを明示できるものがあるといいよと言った話を聞いたのがきっかけだったと思う。最初はどんな風に何を書けばいいのか全く分からずにダラダラと書いていたけれど、書き続けるうちにどういう風に書いたら初見の人が読みやすく理解しやすいかを意識して書けるようになった。些細なことでも継続が大切だなと思う。

さて、私は社会人4年目で2018年11月に4社目に転職しました。
ブログを始めて約1年できっちり転職できたのは本当に良かった。
今度の会社は、人に社名を言って伝わる会社なので少し嬉しいし、技術力のある人ばかりなのですごく刺激になるなぁと感じている。

今回は、すべての転職の経緯を書き出しつつ自分の考え方の変化を書いていこうかなと思っています。

1社目 800人規模のSIer

新卒で入社後、業務アプリケーションの開発をする部署に配属になる。
技術力のある人ばかりの部署で、ITが全く分からない私は常に頭の上にクエスチョンマークが回っている状態。
先輩や上司は「分からなかったら聞け」と言ってくれるものの、同時に「2回以上同じことを聞くな」という文化。
より良い聞き方も、もらった答えを咀嚼する力もまだ持っていなかった私にはこの文化がとてもとても辛く、相談できる相手もいなかったのでだんだんとメンタルを壊していった。
また、Oracleの資格も取らねばならず毎月のように試験を受けては落ちを繰り返した。しばらく待ってほしいという意見も通じず(お前の勉強不足が悪い論)自己肯定感がどんどん削がれていく。
上司は圧が強いタイプの人で、他の社員に怒鳴ったりする場面もとても多かった。私自身は怒鳴られることはなかったものの、育った環境から怒鳴り声が非常に苦手だったため、毎度背中越しの叱責を聞き流しつつ全身震えながらモニターと向き合っていた。
そんなこんなで1年。眠れない日が続いたり、起きられない日が続いたりし、とうとう玄関から出られなくなって数日後会社を辞めることを決意した。
スーパー忙しいはずの上長(女性)が寿司をご馳走してくれつつ引き止めをしてくれたが、休職したり部署を変えたりしてもいずれ顔をあわせることに耐えられないと判断し退職の意が変わらないことを伝えた。

2社目 地域最大の文房具小売店

1社目を辞めてから1年後、どうにか働けるだけの気力を取り戻したので元々好きだった文房具関連の小売店でアシスタント社員という名目で半年の契約をした。IT関連の仕事にしなかったのは1年間ボロクソに言われ続けていたこともあり完全に自信を失っていたから。
ちなみにこの会社では経理事務を請け負った。
経理事務は、毎日上がってくる前日のレシートの束と申請された売り上げを一つ一つ電卓で計算し、複数のエクセルに手入力し、外部からの電話を取って道を教えたり商品を探したりしつつ、手書きの会員入会証をシステムに打ち込んだりしていると1日が終わる。
エクセル入力の部分とかが億劫過ぎたのでバッチを走らせてやっていたら1日かかる仕事が半日せず終わるようになって暇をもてあますようになり、仕事がなくなり毎日シュレッダーをかけるばかりになった。暇そうにしているのでお局様にも目をつけられて嫌な感じの態度を取られるようになったので欠勤しがちになり半年で辞めた。あやうくバックれるところだった。
ここでの経験から、系を戻すだけの仕事は得意だが好きでないなと気づいてITに戻る決意が固まった。

3社目 社長と私だけの人売りベンチャー

自社での開発ができるという話で遠隔で面接を受け、東京に引っ越してから契約書を書いた。契約書の内容が思ってたのと違っていた。給料も低い。やばい低い。でも札幌でもらってたのと同じくらいだったので文句は言えず働き始めた。
武蔵小杉の某SIerにSESで派遣されて1年くらい働いた。そのあとは現弊社で半年くらい働いた。基本はフロントエンドで社内のいろんなPJから雑多な業務を振られていた。自分の力+αちょっとでこなせる仕事が多かったので気持ちは楽だった(最初こそ炎上プロジェクトだったがそのうち落ち着いた)。
サーバーとかネットワークの知識とが少なかったので、2つくらいサーバーリプレイス案件に入った。なんか出張とかあって楽しかったし、ネットワークの基礎くらいはわかるようになった。いいこと。そんなこんなで少しずつできることわかることの幅が広がってきて仕事が単調に感じるようになってきた。自分でPHPを勉強し始めていて人にも教えてもらいつつどうにか基礎を習得できたかなという時期だったので、間に入っている営業さんに「PHP案件のある会社に移りたい」とお願いした。このSIerを抜ける時に結構な嫌味らしきことを言われたがどーでもよかったので覚えていない。なんか別れ際の女々しい男かよって感じだった。このころ、無職時代のツケが回ってきていて「金がない〜金をくれ〜」という感じになっていた。税金を滞納して赤い封筒がしょっちゅう届いていた。電気も止まったりした。ついでに、いつ現場を切られるかという不安で胃を痛めたりもしていた。このままでは1社目の二の舞になると思ったので、転職活動を本格化させることにした。ブログはこの辺りで始めた。
あっという間に年月が流れていったので、「ふーん。わたし働けるんじゃん」と思えるようになったのは結構大きな変化だったと思う。今でも思っているが私は結構な社会不適合者だ。
ブログと同時にツイッターも本格的に見始めた。それまでは化学関連の人ばかりフォローしていたが、アカウントを一新してIT界隈の人ばかりフォローした。みんな技術のことをツイートしているし働き方や金銭面の話まで議論したりしていた。最近はちょっと息苦しいのでそれ界隈の発言を控えている。ちょうどツイッター転職がじんわりと流行り始めていた。ひよこ大佐という人がツイッターでかなり良い条件の転職を果たしたということだった。私もそれに乗っかってハッシュタグをつけた転職希望ツイートを作成したところ、数日のうちに10件以上のお声がけをいただけた。何社か軽い面談と会社見学をさせてもらったがほとんどの会社はなんとなく自分が続けられる気がしなくてお断りしてしまった。
エージェントからも声をかけてもらって3社だけエントリーをしたが、短い期間での転職をしているのが悪手となりお断りされた。せっかく興味が湧くような事業だったので残念だったが、まあ仕方ないかなとも思った。人を雇うのもお金がかかって大変だろう。
多分同い年の人が経営者のベンチャー企業も良さそうで、会社見学をしたらそのまま内定を頂いた。ただ、金銭面で苦しいままになってしまう条件だったのでお断りした。入社してからよほど悪くなければ上がると言われてももはや信じられない。何も信じない。
私は元来お人好しで騙されやすく不利益を被ってきた。次の転職でこそはそんなことになるまいと誓った。

4社目 エンタメ系の会社

3社目で最後に派遣されていた会社に縁あって契約社員でねじ込んでもらった。技術力も足りないのに入れたのは多分やっている業務をわかっている人が少ないから。なので、早いところ他の人がやってることをポンと投げられてもできるようにならないと2018年の3月で契約が終わってしまうだろう。ちなみに、口頭では「1年くらい働いて技術力が上がったら正社員にしますよ」ということだったが、入社の手続きの紙には2018年3月までの契約期間が書かれていた。年度末の切り替えがあるからそういう書き方になっているんだろうと思うが、文句を言うのは面倒で嫌だなと思ったので諦めた。気にしないことにした。でもいまそれが気になって割とストレスが溜まっていると思う。
まあ、仕事がなくなって働く先が見つからなかったら貯金もないし死ぬか生きるか考えてからその先を考えるつもりでいる。私の選択肢はいつだって死か生かから始まる。
私のネガティブはいい。今やっている仕事について書く。
まずはじめに取り組んだのが管理ツール。管理ツールっていうのは表で動いている諸々のサービスを運用している人たちが、より楽に仕事をできるようにするためのシステム。例えば、SQLを直叩きしなきゃならなかった人がGUI上でボタンを押すだけで済むようになるとかそういう感じ。
これはLaravelで組まれていて、初めてのPHPのお仕事だった。3ヶ月ほどでたくさんあった改修や新機能追加が落ち着いた。デザイナーさんとちゃんと仕事をするのは初めてだったけど結構面白かった。私もデザイナーの真似事をしていたけれどやっぱりプロはちょっと違うんだなーと思ったし、デザイナーチーム独特のワークフローやレビュー法もあるようでもっと詳しく聞いておけばよかったと思った。人見知り良くない。今年の忘年会で顔をあわせる機会があったら聞いてみようと思う。
その次にやっているのがTypeScriptで動くAPIの実装とそのリファレンス作成。リファレンスはRAMLで書いている。
RAMLはこれを始めてから初めて知った言語?で、SPAの何かなのかなーという感じ。全然理解していない。なんとなく書き方がわかってきた程度の理解。公式ドキュメントは全部英語で、日本語翻訳もほぼされていない。[RAML][検索]で出てくる情報が全てだった。これには結構苦戦して、本当に見よう見まねで書くばかりだった。どこかの休みを使ってあのドキュメントを全部翻訳してやろうという気概はある。自分の不理解が一番辛い。
APIの実装はTypeScriptで、これも初めての言語。いや、JavaScriptは今までもずっと書いてきたけれどそれをオブジェクト指向で書けるというのはなかなか嬉しいなと思った。

web components のすすめ

勉強会に行った時のメモです


web components の近況

  • IEは基本ダメ2020.01でもうWin7のサポートが切れるので考えなくてよいでしょう
  • EdgeもDevelopingになりました
  • どうしてもIEで使いたい場合はポリフィル入れればよいよ(ケアは必要
  • モダンなものだとpolyfillsなしでOK

基本

  • 新たにESModulesが追加された
  • HTML Templates,HTML Importsは使わない
  • 逐一callBackが呼ばれているだけなのだけどね
  • attachShadow mode:open
    • styleの要素なんかが外に出ない隠蔽しちゃう
    • shadowDOMを持つ要素は子要素を持たなくなる
    • 入れると消えた子要素がslotの要素として割り当てられる
      • 要素名で部分を指定が可能

使い所

  • プロジェクトを超える共通コンポーネント
  • コンポーネントライブラリを使う
    • iron-autogrow-textarea とか pinch-zoom とか
    • webcompoonents.org, googlechromelabs
  • マイクロフロントエンド
    • マイクロサービスをフロントエンドに持ち込む
      • e.g. Reactを隠蔽する(webComponentsだけど中身はReactで動いてるとか)
      • ページの関心毎と技術的関心毎を分離できる
  • SSL
    • Shadow DOMとslotを利用した Hydrate不要のSSRがつくれる
    • 標準仕様なので使えるところで使いましょう

現実的な開発

  • バニラでかく(疲弊しちゃう〜)
  • lit-htmlを使う
    • lit-htmlアプリをwebComponentsにする
  • lit-elementを使う
  • Angular/Vueを使う

    • FWの機能によってFWからwebComponentsを作る
  • バニラで書く→疲弊する→なぜ?

    • ゼロ依存なので軽くて見通しがいい
    • DOM APIを使うことになるので複雑なテンプレートには不向き
    • 属性値は文字列になるのでプリミティブなタグを作る目的の方が相性が良い
  • lit-html

    • polymer
    • テンプレートだけをlit-htmlで書く
      • 更新があるときは勝手に差分更新してくれるので便利
      • webComponentsとして定義する以上はある程度のプリミティブさは求められるよ
  • lit-element
    • litElementをextendsすることで色々良いね
    • typescriptnative!!!
    • lit-htmlのベネフィットを持ち込める
    • property({type:x})で柔軟な属性値を扱える(関数とかも
    • RxJSとの相性が良い
    • ライブラリ
      • fit-htmlとかもある
    • 全てが関数,全てが型付き!!!
    • HTMLと親和性が高い

余談

  • htm
    • tagのテンプレートで書くライブラリ
    • htm自体はテンプレートを解釈しない
    • JSXに似たシンタックス
      • ただし,型検索できない…
    • preach, vhtml と組み合わせて使う

*文法は似ているがフォーカスが異なるのでプロジェクトに合わせて考える FPが好きならlit-htmlもおすすめ

Composerでdev-masterを指定しているpackageの正確なバージョンの確認方法

結論

composerのパッケージのバージョンを調べるときは composer show -i packagename する.
packagenameつけなかったりcomposer.lock見ても dev-master で使っているパッケージの正確な名前はわからないので気をつけよう.

経緯

例えばこんな感じの composer.json があったとして,

{
    "name": “test”,
    "description": “this is test server",
    "keywords": ["framework", "laravel"],
    "license": "",
    "type": "project",
    "require": {
        "intervention/image": "dev-master,
    },
}

この部分 "intervention/image": "dev-master”, の, dev-master について.

dev-master とは,このpackageのmasterブランチのことで、このバージョンを指定するとmasterの最新コミットが適用される.
つまり,最新機能が入っているけど不安定なものがインストールされてしまう.
この状態は障害を生みやすいので,動いている状態で一旦固めてしまうのが良い.

というわけで,このパッケージ intervention/image の正式バージョン名を調べる.

バージョンを調べる

ダメだった方法

  • composer.lock を見る
  • composer show -i から目的パッケージを探して見る

よかった方法

  • composer show -i packagename して目的パッケージの詳細情報を見る

ダメだった方法は2つは, - composer.lock を見る

{
    "name": "intervention/image",
    "version": "dev-master",
    "source": {
        "type": "git",
        "url": "https://github.com/Intervention/image.git",
        "reference": "e82d274f786e3d4b866a59b173f42e716f0783eb"
    },
    ...略...
},
  • composer show -i から目的パッケージを探して見る
$ composer show -i
…略…
intervention/image                    dev-master e82d274 Image handling and manipulation library with support for Laravel integration

という感じで,composer.jsonに書ける形式のバージョンはわかりませんでした.

よかった方法は, composer show -i intervention/image する方法.

$ composer show -i intervention/image
name     : intervention/image
descrip. : Image handling and manipulation library with support for Laravel integration
keywords : gd, image, imagick, laravel, thumbnail, watermark
versions : * dev-master, 2.4.x-dev
type     : library
…略…

versionsのところに, * dev-master2.4.x-dev が書かれている.
これの 2.4.x-dev がいまインストールされているバージョンとわかる.

固定バージョンを適用する

バージョンがわかったらcomposer.jsonを以下のように書き換える.

{
    "name": “test”,
    "description": “this is test server",
    "keywords": ["framework", "laravel"],
    "license": "",
    "type": "project",
    "require": {
        "intervention/image": "2.4.x-dev,
    },
}

あとは $ composer update すればOK!

2018.07に考えたキャリアプランメモがあったので忘れないように書いておく

直近(〜2018.10)

業務

  • PHP,JS のスキルを伸ばす → 基礎の復習と実装の正確性

個人

  • PHPで作成したwebアプリケーションのβ版リリース(〜7月16日まで)
  • 画像処理講座の修了(7月中)

1年後(2018.11〜2019.6 = 26歳)

業務

  • React.js, TypeScriptを業務で使用できるレベルまで引き上げる

個人

  • AWSの機能いくつかを理解できるようになる
  • 勉強会等での登壇
  • プレゼン(軽いLT)などを抵抗なくできる

3年後(2019.7〜2021.6 = 29歳)

業務

  • その時業務で使っている、フロントエンド技術の習得(緊急の対応時に呼んでもらえるくらい)
  • リーダーとして小さめのチームのマネジメントができること
  • バックエンド系の習得(webエンジニアとして、インフラ以外を一通り回せる)
  • テクニカルディレクターへの足がけになるようなことができるといいな……

個人

  • やりたいことを人にプレゼンできること
  • 自分の専門技術を他の人に教育できること
  • 今後の方針を決めること

5年後(2021.7〜2023.6 = 31歳)

業務

  • チームマネジメントができること(中心に立ち、方向性を示していく役割が概ねできること)
  • 会社では産休とか育休中の予定...

個人

  • 自宅でできる仕事を取りながら職場復帰時に技術の遅れが出ないようにしたい

npm で TS2304 (Cannot find name '***') というエラーが出る時の原因と対処

エラー

  • npm -i したらこんなエラーが.
node_modules/@types/superagent/index.d.ts:29:29 - error TS2304: Cannot find name 'Blob'.

29 type MultipartValueSingle = Blob | Buffer | fs.ReadStream | string | boolean | number;
                               ~~~~

node_modules/@types/superagent/index.d.ts:116:14 - error TS2304: Cannot find name 'XMLHttpRequest'.

116         xhr: XMLHttpRequest;
                 ~~~~~~~~~~~~~~

原因

  • それぞれを呼ぶライブラリが足りなかったせい

解決

  • オプション --lib dom を付けてインストールし直すことで,不足している標準ライブラリを一緒にインストールしてくれる
$ npm i --lib dom
npm notice created a lockfile as package-lock.json. You should commit this file.
+ dom@0.0.3
added 1 package and audited 10248 packages in 4.722s
found 0 vulnerabilities

参考

@types/superagent error TS2304: Cannot find name 'XMLHttpRequest'. #12044

dropColumnするつもりでdropしたらテーブルを消そうとしてびっくりした

原因

dropColumn するべきところで drop をしていた.

リファレンス

テーブルリネーム/削除

存在するテーブルを削除する場合は、dropかdropIfExistsメソッドを使います。

コードとエラー

// 正しいコード
Schema::connection($this->connection)->table('tableName', function (Blueprint $table) {
    $table->dropColumn('createdAt');
    $table->dropColumn('updatedAt');
});

// 間違ってるコード
Schema::connection($this->connection)->table('tableName', function (Blueprint $table) {
    $table->drop('createdAt');
    $table->drop('updatedAt');
});
  • エラーの内容
  [Illuminate\Database\QueryException]                                         
  SQLSTATE[42S02]: Base table or view not found: 1051 Unknown table 'databaseName.tableName' doesn't exist
  (SQL: drop table `products`)          

唐突の drop table 😱
エラーにならなかったら恐ろしいことになってしまう.
ここで一番怖いと思ったことが, $table->drop('ココ') で指定しているのがテーブル名でなくカラムなのに $table で指されているテーブルを消そうとしていたこと. 「タイポでした〜😂」じゃすまないっすよ... ちなみに,phpは関数の引数の数が合ってなくても動くので、$table->drop(‘カラム名’) と書いても死なずに $table->drop() と同等の動作をするためこのようなことになったと推測...

今回のエラーの追い方

  1. とりあえず実行して,エラーログを確認( storage/logs/laravel-yyyy-MM-dd.log
  2. エラーが起きているファイルと場所がわかったら,気になる箇所にdumpを入れて実行する
  3. dumpが出なかった手前でエラーが起きているので処理を1つずつ実行して見ていく
  4. 🤔💬 わたしは大体カラム名ミスってるとかメソッド名が違うとかtypoしてるとかが多いので同じようなことをしている他のファイルと見比べたりしながら原因を見つけました.

laravel のマイグレーション機能の`string()`で作成したカラムの長さ

string('hoge') がデフォルトでvarchar幾つになるのか?

laravel のマイグレーション機能で作成したカラムの長さは,
例: $table->string('hoge');varchar(191) となる.