過去より未来に近い今

30オーバーでも始めるには今より遅いことはない。育児と技術両方諦めないようにアウトプット。

HTMLの理解がイマイチだったので、FreeCodeCampを始めてみた

HTMLの理解がふわっとした状態だったので、FreeCodeCampを始めてみた。 FreeCodeCampについてはこちらがまとまっている。

www.recipi.jp

FreeCodeCamp

www.freecodecamp.org

今ではHTMLであればいろんなサイトで学習が可能で、最近だとProgate、少し前だとドットインストールあたりが有名だったのではないかと思う。

英語が苦手なのになぜFreeCodeCampを選んだのかというと

  • 英語の読む力をレベルアップしたい。

むしろ英語が苦手だからこその選択。 最近はちゃんと公式ドキュメントを読むようになったのだが、英語の読解力が足りず、結構辛い。HTML自体はある程度は理解しているので英語でやってもできそう、という算段。

  • カリキュラムが豊富。

多いのがいいというわけではないが、試しに始めてみた感触として学習しやすい設定になっている。

  • その場でコーディング、プレビューされ、自分のコードの課題レビューもその場で実施され、フィードバックを受けられる。

やはりコーディングは書かないと身につかない。別のエディタでやってもいいのだが、それをやると画面切り替えや配置やで余計な時間を取られることがあったため、画面ですべて完結してくれるのは学習にかかるコスト(手間)として軽微で自分には合っていた。

HTMLとCSSをやってみつつ、英語の勉強もしていこうと思う。

メモ。

  • attribute:属性。

Vue.jsをAWS Cloud9で開発する時の開発サーバのinvalid hedder errorの解消方法

最近Vue.jsをAWS Cloud9上で利用する機会があったが、その際にpreviewlocalhostがhedderエラーとなったので、その解決方法。

npm run serve

をしたら、以下のエラーが表示され、previewが表示されない。

invalid hedder error

以下の内容でvue.config.jsを作成し、プロジェクトディレクトリの配下(具体的にはpackage.jsonなどと同じ階層)に配置すればOK。

module.exports = {
  devServer: {
    disableHostCheck: true
  },
}

ES6だと以下のような書きぶり。

export const devServer = {
  disableHostCheck: true
};

これでAWS Cloud9でも開発サーバがきちんと立ち上がり、確認できる。

辿り着きたい場所がはっきりしていなくても走り続けるんだよ

この記事はSHIROBAKOアドベントカレンダーの17日目です。

adventar.org

万策尽きたー!!

今私自身がチームビルディングを仕事で模索しており、そんな折SHIROBAKOアドベントカレンダーに初参加したことで今一度SHIROBAKOを見返していたところ、第2話のあるぴん談義でインスピレーションデッキを思い起こしたのでそのことでも書こうと思ったところ、他の方がわかり易い内容でまとめてくれていました。拝見して「そうなんだよね、そうそう!」と満足なまま読み終えたのですが、気づけばネタがないではないか!

思わず「万策尽きたー!」となりましたが、SHIROBAKOの密度はそんなものではない! ということでネタ変更で辿り着きたい場所に向かって行動し始める話とでもそれがわからないこともあるということについて、SHIROBAKOから私が感じたことを書いてみたいと思います。

自分の今いる場所が違うんじゃないか?

SHIROBAKO第9話「何を伝えたかったんだと思う?」にこんな場面がります。

高待遇、業界でも評判のいいCG会社で不満そうな顔で働くみーちゃん。そんなみーちゃんの不満の原因は目の前にある仕事がタイヤばかりであること。CG作成の技術は上がっているのですが、自分の作りたかったものはタイヤじゃない、と悩みながら、今の会社で別のチャンスがあるのか周りの人と会話してみるも3年先まで車の仕事が決まっている。他の人に不満はないのか訪ねても、福利厚生や待遇の良さで仕事の内容ではなく、会社としての良さの評価を返される。 みーちゃんはまだまだもやもやします。会社の人ではない人に話そうとずかちゃんらに連絡。

そして次の場面です。

「CGの会社に入って夢に近づいたと思ったけど、最近逆に夢から遠ざかっている気がするんですよね。」

「このままこの会社にいたら3年後もホイール作っている自分しか想像できなくて・・・。」

f:id:gohh56:20181217011641j:plain

同じような経験をしている人はいるのではないでしょうか?

私自身SIerでまだ働いていますが、自分がやりたかったことってこれだっけ?と思うことやこのままでいいのか?と思うことがあります。(実際現在はそのための動きをしているのですが、支えるものがあるので、いきなり先もなく退職届を出す勇気はないですが。)

上流工程と言われるプロジェクト計画や要件定義、業務整理の支援、プロジェクト管理と言う名の金勘定、Excelを多用する日々・・・。年数を重ねる毎に開発そのものから離れていくと、自分がやりたかったエンジニアってもっとこう技術を活かしてシンプルに価値を出すような仕事ではなかったか?と思い返すことがあります。 (ただ、実はこういった場面でもエンジニアリング、という観点では活かせる部分があり、まさにそれでチームビルディングや業務Hackという点で右往左往している状態。)

みーちゃんの「夢に近づいたはずが夢から遠ざかっているような」感覚、よくわかります。

また同じ会社で同じようなことを考えている人がいるかと話をしても、福利厚生や働きやすさ(=一定度ぬるさ、も含む)で今の会社に居続ける選択肢を持っている人が多数いるという環境。

これもたまに誤解されますが、その環境が絶対悪であったり、その環境に満足している人が意識が低い、というわけではありません。 単に自分がその環境にいるべきではない、もしくは自分は別の環境にいたいと思っている、ということではあるのですが、何分環境が良いだけにそこを離れるリスクなんかも考えてしまって、できれば今の環境でなんとかならんもんかな?なんて・・・悶々とします。

ある程度続けないとわからない vs 自分のやりたいことと違うなら早めに決断する、問題

社会人になるときによくよく出ていたキーフレーズとして

  • 3年は続けろ

みたいなものがあったと思います。今35歳、社会人としては11年ですが、今になって思えばそんなことはない、と言えます。 このフレーズにはすぐ決断できるほど知らないだろう、であったり、続けてみるとその仕事の面白さに気づくことがある、ということもあります。それはそれで確かにあるのですが、もし自分のやりたいことがはっきりしていて、それと違ってしまっている=やりたいことから離れている、という感覚があるなら決断は早めの方がいいです。これは自分の感覚でも、様々な人の話を聞いても思います。

10話「あと一杯だけね」で、りーちゃんが一見おかしな、でもそのとおりという例えを言います。

「野球やりたいのにサッカー部入ったもんですもんね。」

f:id:gohh56:20181217014024j:plain

時に極端な例はわかりやすかったりします。

ただ、注意しとく必要があるのは「野球やりたいのに」です。 やりたいことがはっきりしている、それが例え一時の感情でも、自分の意志がはっきりしていること、というのが大事です。 自分が扶養されているときなどはある程度面倒を見てもらえますが、そうでなくなった時自分の人生の責任は誰も取ってくれません。自分で決めて自分で責任をとっていくしかありません。そうなった時に自分の意志、感情を大事にすることはとても大切です。なんせ責任を撮るわけですから、自分で決めたしな、ぐらいは思えないといけません。

もしこのような意志や感情がなく、よくわからないけどみんなやめるから、みたいなもので決めてしまうと自分の意志がないので、あまり良い結果にはなりません(たぶん)。このように「野球やりたいのに」がなく、「サッカー部やめよっかなー」ならとりあえず「サッカー部でサッカーやっとけ」というのがよくて、サッカーやり続けているとサッカーやグラウンドのことやなんやかんやに多少なり詳しくなったり、考えが深くなったりして、サッカーの面白さに気づくか、自分のやりたいことが別にあると気づく可能性が出てきます。

たぶんこの差があっての、継続 vs 軌道修正、の話になるのだと思います。

目標=やりたいことがわかっているならそのために行動するでいいじゃないか

みーちゃんが社長に思いを伝えた際に社長が語ります。

「目標があるんならそのためにどうしたらいいか一度しっかり考えてみたら?」 「何をやるにせよ、この先の自分が具体的に思い描けないなら始まらないだろ?」

f:id:gohh56:20181217015859j:plain

社長もこれまでいろいろと経験して考えてきて、の言葉ですよね。

確かに自分にやりたいことがはっきりしているなら、他のことは「やらないリスト」にして、どうしたらいいかをブレイクダウンしていく必要があります。キャリアだけでなくても、一つの仕事をとっても、成果物はなにか?、目的はなにか?がわかっていないと求められていたものと違ったことをやってしまったりします。

ただ、一方で「この先の自分が具体的に思い描けない」状態でも無慈悲に時間は過ぎていきます。目標を具体化することは大事なのですが、でもそれができていない状態でも人生やキャリアが「始まらない」ことはなく、「始まってしまっている」のだと思います。

また、描いた目標が間違っていたら、やってきたことも間違いなのか?と考えてしまい、目標を決めきれない、ということもあります。

もし目標が間違っていたら?何が正しい選択なのか?

なんとなく私も「これが正解」と思える選択肢を選びたいし、「間違えたくない」と思ってしまいます。

ただ、よくよく考えるとみんなが同じ正解なんてないんですよね。だから、それぞれ違う意見があっていいし、間違えたら軌道修正してもいい。

我々の世代は寿命が100歳ぐらいになると言われています。そうなると一部選択肢は除きますが、軌道修正やキャリアチェンジのチャンスはあって、それを経験と言えるような生き方の選択も可能だと思います。むしろ単純労働や同じスキルの人が求められていた時代ではないので、このキャリアやスキルや経験のベクトルが散らばっていて、この幅が広いほど、希少価値が高い人材になりえるのではないか、とも言えます。

辿り着きたい場所があるなら、そこにむかって走れ、でも辿り着きたい場所がはっきりしていなくても、走り続けるしかない

おいちゃんは自分のやりたいこと=目標が見えず、「考えないとな」としながら、目の前の仕事を必死にこなしていきます。

f:id:gohh56:20181217021030j:plain

この状態にある時、それがその人の中でどのように決定され、それが本当にやりたいことであるかわからなくても、目標=やりたいことができた、それに向かって行動している、という人はキラキラして見えます。逆に自分をその人と比較して、「自分は何がやりたいのだろう?」「やりたいことがない自分ってどうしようもないな」と考えてしまったりします。

「ホンダさんはたどり着きたい場所を見つけたんだね。」

f:id:gohh56:20181217021053j:plain

この状態、ものすごくわかります。私も何度もハマり、今もモヤモヤしています。「辿り着きたい場所」=目標、やりたいことってモヤモヤしてはっきりしない(できない?)ことが結構あるんですよね。

そんな中、実はこの状態に対しての気づきをおいちゃん自身で話している、という場面があります。

「詰まっていたその絵コンテが進みだしたのはどこにたどり着きたいかがはっきりしたからでそのためになにをやればいいのかが見えたんだって。」

f:id:gohh56:20181217021333j:plain

突然の話題変更。おいちゃんはこういう問題などに対して、メタファで語る例を出すのが上手だよな、と思います。(これって自分が見聞きしたことを自分の中で腹落ちさせて理解しようとしているからなんですよね。こういうことがしっかりできるのって強いな、と思います。)

ここでは一見、「辿り着きたい場所が見えた」=「やるべきことがわかった」ということで目標がはっきりしたら次に進めたよ、ということを語っていると思うのですが、私はそれとは別のことも伝えているのではないか?と感じました。 それは「詰まっていたその絵コンテが進みだしたのは」の部分です。「悩んで苦しんだが詰まってしまった。それでもなんとかしたいともがいていたら」→「辿り着きたい場所が見えた」。 木下監督も舞茸さんと話す前に目標=やりたかったことがわからなくなって、その結果ストーリーがこれでいいのか、がわからなくなっているという場面があります。

つまり、「辿り着きたい場所」=目標、やりたいこと、がモヤモヤしていたり、わからなくなっていたりしても、それでもあがき続けていると何かのきっかけで気づける、ってことなんじゃないかな?と思いました。

辿り着きたい場所がそれがたとえ結果的にまた変わったとしてもそれでもはっきりしているならそのためにするべきことをやる。

辿り着きたい場所がはっきりしない、もしくは決めきれない場合でもあがき続けることをやめない。走り続けるという選択肢がある。

自分のキャリアで悩みまくっていますが、だからといって何もしない、というのは違うよな、いろいろやってみようと思っていたことが、SHIROBAKOによって自分の中で再整理できました。

まとめ

なんだかとりとめもないポエムチックな話になってしまいました。

でも、こんなカタチでもSHIROBAKOについて書いたことで、改めてSHIROBAKOは日々のもやもやなどを「こういうことだったのか」と気づかせてくれ、励ましてくれる一生涯繰り返し観たいアニメであることを再確認できたので良しとさせていただきます。

※最後の最後に舞茸しめじさんのメンタリングすごい・・・。

相談したい・・・。

「一番やりたかったことはなんですか?」

f:id:gohh56:20181217023855j:plain

エンジニアとして食っていく方法@TECHPLAY Academy 参加レポ

エンジニアとして今後食っていきたいと思っているのと、登壇者に及川さんがいらっしゃったので、参加。

似たような内容は他でも聞くことはあったが、今回の参加ではその内容が自分の中で腹落ちしてくることが多く、アウトプット駆動を加速させようと決意した(賞味期限3日※後述)

TL;DR

エンジニアの人材不足やその中でどんな人材が求められ、価値ある人材になるためにはNot only coding, but also xxxである。

  • どんなエンジニアが求められるか?=コード書いているだけでなく、開発のあらゆるフェーズでオーナーシップを発揮できる。

  • エンジニアとしての成長サイクル。学習→知識→技能へ昇華させていく。

  • 自分の置かれた環境を変えるより、自分が変わる、自分のいる環境を変える方が早い。嘆いていないで行動すべし。

  • 技術だけでなく組み合わせで希少人材になる。

  • ITと何かの組み合わせは面白いことが起きる。ビジネスに技術を組み合わせた視点で見ると面白い。

参加目的、何をしたくて参加したか?

  • 35歳、SIer所属エンジニアの生存戦略を考える参考にしたい。

  • エンジニアと言っても、様々な役割ができてきた中で生存していく選択肢としてどう考えるのかの参考にしたい=キャリアパスに悩む状態を次に進めたい。

刺さったキーワード

※言っていたとおりに聞き取れていなかったらすいません・・・。

エンジニアと言われると今の自分は微妙な立場ではあるが、エンジニアでなくてももう少し広い面で技術者であり続けたい。 by 及川卓也さん

めちゃくちゃかっこいいと思った。ほんとそう思う。

決意には賞味期限がある。それは3日ぐらい。 by 許 直人さん

賞味期限実感あった。でもこうやって強い人が明言すると期限を強く意識するようになる。

会社を清算することを経験した時に所属していたエンジニアは他社へ移ったが、自分は残った。当時の社長からエンジニアとしてはまだまだだが、エンジニアだけでなく、マーケティングもできるから残した。それ以来スキルを面で捉えている。 by 許 直人さん

以前及川さんの別のところの話で人材の希少性をベクトルで捉える話を思い出した。実例伴って、かつエンジニアとしての技術力の自分の立ち位置を意識するようになっていたので、更に刺さった。希少人材になり、価値を出したい。

呼吸法と同じ。吐いてから吸う。アウトプットから始まりなので、アウトプットから考える。 by 及川卓也さん

すいません、インプット駆動に逃げてました・・・。アウトプット駆動する。--> とりあえずAdvent Calendarに参加することにした。今年中にどこかで登壇もしたい。

レポ

活躍するエンジニアの条件 及川 卓也さん

日本のプログラミング教育の話から米国のプログラミング教育とプログラミングが貧困を抜け出す手段として広く受け入れられ、事実米国でのソフトウェアエンジニアの価値=年収の高い実情を順を追って説明されていた。

ソフトウェアエンジニアが年収が高いのは価値を生み出しているからであり、価値を生み出すエンジニアとはSIerにある開発者と設計者を分ける、上流、下流などと分けて、要件も自分たちで決めないようなものではなく、ビジネスにコミットしていく=開発のあらゆるフェーズでオーナーシップを発揮し、プロダクト・サービスを考えられる技術好きなエンジニアである。

そして求人で見るような「経験年数◯年」というのは経験≠過ごした時間、ではなく経験=技能としてのレベルを意味しているので、年数足りないからとビビるのではなく、技能を磨け、ということであった。

IT技術者の不足はよく聞く話で、また求人倍率がIT関係は非常に高いということも知っていたが、それは単にITやってきた人、IT得意な人という意味の数字ではないだろうな、とはモヤモヤっと考えていた。今回話を聞いて、この数字に表現されている人材というのがどういうことを求められているのか、そしてそれはなぜなのか?についてわかりやすく、頭が整理された。

日本のエンジニアの給与や待遇はSIerの人月商売の影響で未だまだそれほど高いものではないが、今後はその求められる価値が高まることに合わせて給与や待遇も上がっていくように思う。(徐々にそのような傾向が出てきているらしい。) 技能を磨き続けることについては個人的には面白いし、勉強会やインターネットなどこんなに恵まれた職業はないのではないか?と思っている。ただ、好きでやっていることでも高い価値を生み出せるのであれば、それを評価してもらえる社会であってほしいと思う。

美容師からエンジニアへの転身 許 直人さん

ご自身の置かれた状況からいかにして技能を積み上げ、市場価値の高いエンジニアになってきたか、という話。

正直自分とは大きく異なるのでいろんな意味で「すげー・・・」という感想だったが、その中でも以下のポイントは自分の行動にできそう。

  • 定期的に自分のスキルセットを棚卸しして転職エージェントにどのぐらいの価値評価されるかを確認する。

  • 仕事の一部を技術への投資へ回す(食っていくための仕事だけをやるのではなくて、できるかできないかわからないことをやって、常に価値を高めていく)。競争にさらされている意識を持ち続ける。

  • 自分に何ができるか考え、自分から取りに行く。

自分の仕事の中に食っていくための仕事以外を盛り込んじゃおう、というのは最近意識的にしているが、やや後ろめたさのようなものを感じていたが、このように強い人が言ってくれると「だよね!」という気持ちになる。また単に仕事中にプライベートなことをやっているというわけではなく、そういう仕事の仕方をしていくということ自体がその組織に貢献することにもなる、と聞いていて思った。

パネルディスカッション

いろいろ出たが一部自分にとって気付きとなったポイント。

  • SIerでぬるま湯と感じていたときも社内ではなく、外に目を向けていたことで危機感を持ち続けた。それがモチベーションになった。

今私もこの状態。食っていく仕事は余裕を持ってこなせるが、市場価値で見た時の自分が怖い。この危機感を持つために社外との接点は持ち続けるべき。たぶんそれはSIerに限らず、web系でも言えると思っている。

  • 自分を追い込むことで行動せざるを得ない状況をつくることも一つの手である。ただ、年齢が高くなると家族が増えたりでチャレンジするリスクが高くなるのは間違いない。

保育園の点数大事・・・。と思ってしまう今日この頃。

  • 意志が強くない、大きなリスクを取れない場合ではとにかくアウトプットから始めることが大事。学習だけでは技能に昇華しないので、とにかくアウトプットが先で、必要なインプットを入れていくというサイクルを作る。

  • アウトプットの種類は登壇、LTなどいろいろある。勉強会も盛んなので参加すればいいが、受け身で参加するのではなく、常に質問するつもりで話を聞け。

勉強会に参加して満足してしまっていた部分はあるので猛省。今回参加目的を再確認して質問させてもらったが、質問力弱かったな。

  • 困ったら公式ドキュメント読め。英語の方が最新なので英語頑張れ。またトライアンドエラーでやっていってみるのもあり。

  • 面としてのスキルセットを持ったエンジニア(技術者)の方が希少化しやすい。エンジニアでもプロダクトマネージャーやスクラムマスターなどいろいろあると思うが、チームの人とちゃんと話せるレベルの技術は最低限備えた上で、あとは自分が好きになれたものをやっていけばよい。

キャリアを考える上での技術力の最低ラインが認識できた。もちろんそこでいいと思わないし、技術を知ることは好きだし、どんどん様変わりするので、成長し続けていく必要があるが、指針が得られた。

  • 職業エンジニア=仕事でしかコーディングしない、プライベートでコーディングなどしていると変人扱いしてくるエンジニア、はどこかに行って、技術好きなエンジニアばかりになるといい。

いつになるかわからないが、求められる価値が高まれば自然とそうなりそう。そしてその時自分はエンジニア、技術者としていたい、と思った。

すくすく!子育てエンジニアMeetp#3に参加してきた

現在3歳&0歳の子供がいる身として気になっていた勉強会へ参加してきた。

子育てエンジニアというネーミングでもある通り、父母の方々が多く、他の勉強会にはないほっこりした雰囲気の勉強会だった。

すくすく!子育てエンジニアMeetupとは?

イベント概要から抜粋。

・家庭や育児においてもっとエンジニアリングで何か出来るのではないか?と思ったことはありませんか?

・困っていることがあるのだけど、実はこれは何か解決出来るツールを作っている人がいるのではないか?

・今後、こういった困り事が出るから今のうちにツールを作っておいたほうがいいと伝えたい。

そういった家庭や育児におけるtipsを皆で共有しようという場です。 そこで得たナレッジを家庭で共有し、さらによくしていこうという集まりです。

家庭や育児をエンジニアリングでサポート、そのノウハウを共有しよう、という集まりということだった。

家庭や育児など身近な部分をエンジニアリングで良くしていこう、というのは課題解決の敷居としてアプローチしやすい&自分事なので、当事者としての課題設定がしやすい、という面がある一方、実はこういう家庭内でのエンジニア的なアプローチは共有される場面が少ないように感じていたので、このような集まりを企画していただいたのは非常にありがたい。

#3の開催概要

場所:マネーフォワード社新オフィス(田町)

21階ということもあり、夜景が綺麗に見えた。新しいオフィスとのことで全体的にきれいでおしゃれだった。

エンジニアの勉強会としては珍しく、子供向けのお土産あり、黒烏龍茶などの健康配慮された飲料の提供(アルコールはなし)ということで、奥様マネジメント的には好感度が高い運営となっていた。

勉強会で得たこと

身近な課題、悩みを考え方含め整理して、解決するアプローチを複数の事例で伺えた。自分でもちょっとした「こうなっていればいいな」と思うことがエンジニアリングで解決する課題設定になるのだと気づけたのはアウトプットを増やしたい思いと家庭内でもやることをやる必要があるということを両立できるチャンスだな、と思った。

以下、それぞれの発表ごとでの気付きなど。

発表枠(1):tknzk さん

  • VUIを使った育児ログの記録についての話

我が家にもVUI端末があるのだが、イマイチ利用しきれていない。IFTTTとそれだけだと不足する部分はスクリプトを書いて補うというTipsは参考になった。IFTTTなど使えるものは使ってなるべく楽することも時間がない子育てエンジニアには必要なTipsだな、と感じた。

発表枠(2):おおやまみちのくさん

  • Scrapboxを家庭に導入された話

私自体はScrapboxは利用したことがあったが、現在はNotionへ移行している。そのため、ある程度使い心地は知っているつもりだったが、リンク機能や地図などのデモを拝見して、確かに子供とのお出かけ計画などには非常に便利かもしれない、と感じた。

ただ我が家の場合、奥様マネジメント的に利用してもらう敷居が高そう。

発表枠(3):Yuu Ito さん

  • 夫婦でお買い物アプリを作った話

ご夫婦共にエンジニアで、買い物リストの共有が既存サービスでイマイチはまらなかったからアプリを開発されたそうだ。他の人に利用してもらうと環境によってはそれほど効果が出なかったが、ご夫婦にはハマって効果が出たということだった。家庭内のやり取りやその家族の悩みどころというのは世界で1つ、とまではいかないが、ある程度ニッチな悩みになるのかもしれない、と感じた。その時それをエンジニアリングで解決する、という方法はありで、またそのニッチな悩みは世の中にある程度同じ境遇の人がいるような気がした。

アプリを公開されるかもしれないとのことだったが、自分の悩みやその解決方法も他の誰かの役に立つのかもしれないと考えさせられた。

発表枠(4):chocopie116さん

  • 音声を拾うことで奥様の大変度合いを感じる仕組みを作られた話&家庭内マネジメントについての話

TDDを元にした奥様サイクルや家庭内の負のスパイラルの話などエンジニアリング以前に把握しておくべき考え方の話があり、頷く内容だった。よくエンジニアは作ることばかり考えるのではなく、作らずに済むことも考える必要があるという話があるが、抱っこを変わる、アイスのお土産で喜ばすなどはまさにこれに当たる内容で、なんでも何か作ればいいと思ってはいけないな、と感じた。

その上で音声を拾い、それをモニタリング、しきい値を超えるとアラートが上がる仕組みを入れ、赤ちゃんの泣き状況を把握する仕組みを構築され、奥様の大変な状況を共有するということを実施されているというのは家庭内でのエンジニアリングの事例としては自分では思いつかない内容だった。

発表枠(5):shikicheeさん

  • 妊娠されて不安な奥様に対して準備したことの話

家事の外注、家庭内カフェ化=作業効率を上げる環境の構築、Trelloを使った献立管理、保活の実体験として利用した資料や検討の仕方のお話。

我が家の場合Trelloを奥さんに使ってもらうのは敷居が高いなどなかなか展開できそうにないが、webサービスとして保育関係の情報が結構出ている(東京だけかもしれないが・・・)というのは参考になった。

次回に向けて

全体的に子供の紹介が出るとみんなでニコニコしたり、登壇内容も既存サービスを家庭で適用した事例紹介や、家庭内Tipsや自身で開発したものを育児などに活かした話など幅が広く、登壇しやすい雰囲気であった。

次回はチャンスが有れば登壇にチャレンジしてみたい。

Google Apps Scriptをローカルでコーディングするためにclaspを導入した

Google Apps Script(以下GAS)は便利なので、業務効率化のために利用することが多いが、標準のオンライン開発環境だとコーディング補助や静的解析が弱いので、ローカルでコーディングできないものか?と思っていた。

調べてみると少し前から「clasp」というCLIツールがgoogleより提供されており、これを利用するとローカル環境での開発が可能となることから入れてみた。

環境

参考資料

qiita.com

qiita.com

qiita.com

claspとは?

googleから提供されているCLIツール。これを使うとGASのプロジェクトを作成したり、G Suiteからソースをpullしたり、pushしたり、バージョン作成やバージョン確認が可能となる。

claspを使って何が嬉しいのか?

  • GASは便利だが、web上の開発ツールだとちょっとしたところが足りない。それがローカル環境だと自分の慣れた環境で開発できる。

  • GASはほぼJavaScriptなので、JavaScript的補完が効き、開発効率UP。

  • gitなどでソースのバージョン管理できる。

  • GASはWindows officeでいうところのVisual Basicなので、なんとなく開発と言い切れない部分がローカル環境の開発ツール使って(黒い画面で)操作しているとかっこよく、開発しているっぽさが増す。

claspを入れてみよう

  1. node.jsとnpmのインストール

  2. npmを使ってclaspを導入

$ npm i @google/clasp -g
  1. GAS APIをONにする

このあたりは参考リンクを参照。

  1. clasp loginする

ログインするとwebでいつものグーグルの認証画面が出るので認証を通す。するとwindowsの場合、ユーザーのhomeディレクトリ直下に

.clasprc.json

というjsonファイルが作成される。

$ clasp logout

とするとログアウトするのだが、この時login時に作成された

.clasprc.json

が削除されている。

つまりこのファイルが認証情報になっている様子。

ちなみに自分の環境では上記のlogoutコマンドを叩かない限り、PCそのもののシャットダウンなどをしてもjsonファイルは残り続けており、かつclasp loginせずにいきなりclaspコマンドが利用できた。

claspを使った自分流のローカル開発環境の実現

  • ざっくりした開発の流れ

    1. cloneまたはcreateでプロジェクトを作る

    2. gitリポジトリ作成

    3. VSCodeで開発

    4. Gitステージング→コミット

    5. clasp push

    6. G Suite上でデバッグ

      • この時エラーが出るなど修正があれば、3-5を繰り返す
    7. 正常に動けばclasp version 'hogehoge'でバージョン作成

claspで疑問に思ったこととその確認した結果

  • GASプロジェクトを切り替えるにはどうしたらいいのだろうか?

    参考にした資料でもgoogleのclasp説明資料でもイマイチよくわからなかったので、いろいろ試してみた。

    その結果、最初にcreateまたはcloneをすると

    .clasp.json

    というファイルがカレントディレクトリに作成されるのだが、この中にスクリプトIDが記載されていて、その設定ファイルを処理時に参照してGASと紐づけて処理していることが判明した。

    つまり、プロジェクトの切り替えは特別なコマンドで操作する、などではなく、単純にカレントディレクトリを移動するだけでよかった。

    具体的には以下のようなディレクトリ構成があったとする。

    gas

    ├ gasprojectA

    │ └ .clasp.json

    │ └ hoge.js

    └ gasprojectB

      └ .clasp.json

      └ hogeB.js

    作業時にgasprojectAとgasprojectBを交互に操作したい場合があったとしたら、コマンドプロンプトでカレントディレクトリを都度移動して、claspコマンドを打てば、そのカレントディレクトリにあるjsonファイルに記載されたスクリプトIDに紐づくGASプロジェクトに対して、カレントディレクトリ内のファイルをやり取りしてくれる、ということ。

  • ローカル環境でどのようなディレクトリ管理がよいか?

    参考にしたリンクにはGASのjsファイルに「/」を入れるとclasp pullした時にディレクトリ階層にしてくれるとあるのだが、この「/」があることがもやもやしてしまい、結果自分はローカル環境でそれぞれプロジェクトごとにディレクトリを作成して、そのディレクトリ内にcloneすることにした。

例としては上記のプロジェクト切り替えの通り。

これでwebのGAS上でも「/」がなく、かつGASプロジェクトごとにディレクトリが分割しているので、gitリポジトリもそれぞれ個別で作成可能となった。

claspでもやはりまだイマイチな点

  • pushしないとイマイチデバッグができない

    GASにもよると思うが、スプレッドシートとセットなどG Suiteのサービスとセットになっている場合が多いため、ローカルでの動作確認には限界がある。

  • ネットワーク環境にもよると思われるが、処理に時間がかかる

    もしかしたら都度json見に行っているから?自分のネットワーク環境もあるので、これはイマイチ原因はわからないが、webでコーディングしてそのまま動かす、というclasp利用なしと比べるとこの点はどうしても劣る。

なんだかんだでclaspいいよ

イマイチな部分はあるが、やはりローカル環境での開発とgitでのバージョン管理ができるのはよい。

最近はGASのコンソール画面もあり、webでできることも一覧で確認する方法も充実してきているので、web上でのサービスとclaspと組み合わせると結構幸せなGASライフを送れる。

G Suiteを利用して、GASでなにかしている人にはclaspオススメ。

Djangoのmigrateでハマった

Djangoのmigrateでハマったので、その内容と解決方法をメモ。

背景

Djnagoのオンラインコースが一通り完了したので、参考にしつつ、自分で別のアプリケーションを作成することにした。 models.pyで定義後、一度makemigrationsとmigrateを実行し、adminサイトで確認したところ、想定していたデータベース構成と異なる部分があったので、models.pyを修正し、再度migrationをしようとしたところエラーが発生した。

発生事象①

makemigrationsしたところ以下のエラーが発生。

f:id:gohh56:20181003004742p:plain

作成したmodelの中でデフォルト設定がないが追加しようとしている項目があるがどうするの?ということらしい。

解決方法①

select an option:

と聞かれたので、ここでは1を選択。実際にデフォルト設定値を入力するよう促されるので、e.g.にある内容を参考に入力。

私の場合はtimezone.nowで解消した。

発生事象②

次にmigrateをしようとしたところ、今度は以下のエラーが発生。

f:id:gohh56:20181003005534p:plain

どうやらmakemigrationsのデフォルト設定が良くなかった様子。

解決方法②

ググったところ、以下の記事に遭遇。

まだデータ登録はしていなかったので、データベースを作り直してもよいと思い、migrations以下のファイルを削除、再度makemigrationsとmigrateを実行したところ正常に処理が完了できた。

qiita.com

エラー自体は解消したのだが、削除したファイルが一体何の意味を持つものなのかはっきりしなかったので、調べた。するとDjango公式ドキュメントに以下の記述を発見。

マイグレーションというのは、データベーススキーマに対するバージョン管理システムのようなものです。makemigrations はモデルの変更点を1つのマイグレーションファイルにパッケージングし(コミットのようなものです)、migrate はその変更点をデータベースに適用する、というわけです。

migrationsディレクトリ内のファイルはこのマイグレーションファイルに該当していたようで、この情報を一度削除することでリセットされたということらしい。

ちなみにより調べるともう少し丁寧なデータベースリセット方法があった。次はこのやり方を参考にして再度対応しよう。

https://trybeetle.com/en/detail/4/