関西Node学園 梅田キャンパス 1時限目に参加して来た

nodejs.connpass.com

参加して来たので,まとめます.

春からはじめる新しいNode.js - Node.js v10 @shisama_

平野さん、ウェブリオ

  • EcmaScript
    • 二ヶ月に一回ミーティング
    • TC39
  • node
    • node.js release にリリースしたやつが載っている
    • node4 v8 engine 4
    • node 6 今月末にLTSではなくなる
    • node 8 現在のLTS async / await をサポート
      • 一年後の四月にLTSではなくなる
    • node 9 現在のcurrent
    • 次のnode 10 4/24リリース
      • v8 6.6に
      • v8 6.7 chrome 67に乗っている
      • npm7に期待
      • EcmaScript
        • 多くの機能が追加される
        • dynamic import
        • promiseにfinallyが追加
        • node greenでどの機能が使えるかが書いている
        • 実験的な機能はフラグによって使用することができる
          • harmony
          • 実験的な機能が使える

感想

どのバージョンがどんな感じかを詳しく説明して,バージョンの上げる目安なんかもわかって勉強になりました.

TypeScript + Express(仮) @kamiyam

かみやんさん フリーランス

  • TypeScript
    • マイクロソフトさん
    • nodeの代わりにts-nodeを入れる
    • 型定義置き場はtypes/...
    • switch caseのところを文字列で比較するのではなく、enumで定義したtypeを利用する
  • TypeScript + Express

感想

実演もあったりしてどうやってTypeScriptを導入していくかをじっくりやっていて,すごく勉強になりました.ts-nodeは知らなかったです😇

Babel7.xで変わること @mochiya98

ふなおかさん HAL大阪

  • babel
    • npm i @babel/とかで書かないといけない
    • どこの情報を見たら良いか
      • planning for 7.0
      • nearing the 7.0
      • Upgrade to Babel7 移行メインの内容
      • babel-upgradeで移行が楽

感想

babelをあまり意識したことがなかったので,勉強します・・・

JavaScriptユニットテスト入門 きりん@sota1235

きりんさん メルカリ

テストに行くまでの道

  • テストの必要性
    • 品質担保
      • 意図した通りに動作するか
    • 責務ごとにテストを書く
    • 汚いコードはテストが書きづらい
  • 現実との戦い
    • フロントエンドのテストが書けるようになったのは数年前
    • UIとロジックの切り離し
    • テストのコスパ
      • ロジックが変化しやすいものはテストを書き換えることが多くなる
      • 計算ロジックはテストして良さそう
      • UIのテストは無駄になることが多い
      • ビジネスロジックは変わることが少ない
  • モジュールを切り出す
    • ユーザインタラクションとロジックを分離する

感想

スライドで出てきた,せやなボタンがネタ感があって非常に面白かったです.そしてそれを元にちゃんとロジックとUIを切り離し分離したコードまで書いてありすごく考えられたスライドで感動しました.こういうプレゼンをしたいなと思いました.😆

無理せずflowtypeを導入していく

まいけるさん

  • flowtype
    • jsで書いて,ビルドするときにアノテーションを取っ払う
    • flow-remove-typeでアノテーションを取れる
    • flow.org/en/docs/types
    • React使うときに便利
    • language serverを使おう
    • typeを定義するのが大変だったらObjectでおっけー
    • サードパーティーライブラリの型はanyになってしまう
  • flowのupgrade
    • ためるとやばい
    • flowはchangelogを見る
    • それで分からなければtestコードを見る

感想

flow周りのupgradeのつらい現状が非常に伝わって来ました.Utility Typesを知らなかったので,学んでいこうと思いました.

まとめ

精進します.🙇‍♂️

応用情報技術者試験を受けてきたので反省した

本日,応用情報技術者試験(AP)が全国で行われてました. 僕も参加し,試験を受けました.

試験の手応え

正直,ビミョい感じがしてて個人的に受かっていると信じながらこれからも生きていく所存です. Twitterでは,強気に攻めてます.

勉強時間など

当初の計画

  • 毎日,100問ずつ解く
  • 試験開始日までに全ての問題を二週分解ける計算
  • 優勝🎉

という流れだった

現実

  • 20時間ぐらい午前に
  • 驚くことに午後は2時間程度😇
  • 午前も少ないと思いつつ,午後はあまりやる気がなくてざっと見て終わりって感じ😢

受けてみた後,思ったことをつらつら

思ったことは,午前と午後を分けない方がいいんじゃないかということです. 午前の問題を断片的に解いていると,結構自分は今何をしているんだろう?応用情報かな?となってしまったりしました.

だから個人的には「今日は平成○○年の過去問を解くぞ!」というスタンスで午前午後の問題をセットで解いて雰囲気をつかむことが理想だと思いました.

↓イメージとしてはこんな感じ

https://i.pinimg.com/originals/27/39/62/27396251edcb2103378dac90f9a77fc8.png

でも雰囲気ってのは大事だと思っていて,非常にやっている感が出てくると思います(多分). そして午前の問題を適当に解いている時と違って,全体で何点かという評価が出てくれます. ここで高得点を取れたらいい気分になれます(多分).

すごくいいですね.😝

この午前午後セットの過去問を週に三回ぐらい解いていけば,二ヶ月で16回ぐらい解けます. これが十分かはわかりませんが,次受ける時があればこんな感じで勉強しようと思います(戒め)

まとめ

応用情報技術者試験をちゃんと勉強して,次は頑張りたい

プロを目指す人のためのRuby入門を読みました

gihyo.jp

読みましたので,雑感なんかをつらつらと.時間としては9時間ほどで読めました.(3日)

凄く楽しく読めました😊

全体を通して

その章ごとにお題が決められており,そのお題に関する例題がありました. この例題というものがテストなども交えて,結構なボリューム感を持って存在しています. 技術書を少しは読んでいるのですが,しっかりした例題があると読んで得た知識をすぐに活かせるのでより身につくなぁと思いました.

面白かった点

rubyこんなこともできるのかすげぇってコードを読みながら思ったら,コードの下の文章にこういった書き方をするのはやめましょうと書いてあり,「書くなよ!絶対書くなよ」感が印象に残りました.

面白いなと思いました.

気になった点

  • ->(){}lambdaという二つの書き方でlambdaが定義できるとのことなのですが,本では -> の方で書いています.qiitaの記事を読んでいるとlambdaという表記で書いている人もいました.(情報が古いかもしれない?🤔)

ココらへんは好みもしくは担当する案件の規約とかに依存しそうなので,わからないなぁと思いました.(個人的にlambda派)

たくさん書き方がある良い言語だと思いました.

まとめ

Ruby初心者でこの本を手に取り読みましたが,漏らすこと無く読み切ることができて良い本だと思いました. 例題をやる上で変更箇所がわかりやすく塗りつぶされているので,適度な速度を保ちつつコードを書くことができました. 入門書として非常に役に立たちました.🙇

DDD本を読み終えた(ざっくり)

DDD本をとりあえず読んだので,気になった部分をまとめます.

www.shoeisha.co.jp

↓5章までは以下にまとめてます.

http://blog.hatena.ne.jp/MitubaEX/mitubaex.hatenablog.com/edit?entry=17391345971618128236 mitubaex.hatenablog.com


6章

集約

エンティティと値オブジェクトをまとめたもの. 集約にはルートエンティティがあり,このルートのみを外部のオブジェクトは参照できる.

本で挙げられてた例では,自動車がルートエンティティでその下に車輪,タイヤ,位置が保持されている. これにより,自動車の下にある車輪は外部のオブジェクトから参照されることが無く,集約内部での不変条件を満たせる. この不変条件というのは,自動車だと前のタイヤは二つで後ろのタイヤは二つといった絶対変わらない条件のことを指す. 後ろのタイヤを勝手に誰かに変えられると困るかもしれない.

ファクトリ

オブジェクトを作成,再構成する役割を持つオブジェクト. 複雑な処理をカプセル化できたりする. 基本的な役割は,集約を作成して集約のルートを渡す.

ファクトリは,エンティティを再構成する時,識別子を新たに作ってはいけない. だからファクトリメソッドの引数には識別子を入れる. オブジェクトの再構成をする場合は,DBなどですでに値が書き換わっているかなど確認することが多いらしい.

リポジトリ

クライアント,DB間のインタフェース的存在. データストアの実際の操作をカプセル化する.

リポジトリは,クライアントから切り離されているので容易に実装を変更できる. また最後のDBへのコミットはリポジトリが行うのではなく,クライアント側の責務である. リポジトリは変更の操作を行うだけで,トランザクション処理には関与しない.


14章

境界づけられたコンテキスト

複数のモデルを抱える巨大なプロジェクトがあった時,モデルごとにきちんと境界をしき外部のモデルに左右されない一貫性を保つ. このコンテキストごとに名前を設け,そのコンテキストと他のコンテキストの関係をコンテキストマップにまとめる.

腐敗防止層

二つのモデルが結合されて,モデルの一貫性が取れなくなった場合には腐敗防止層を設ける. この腐敗防止層は,二つのモデルの双方向の変換を行う.


15章

汎用サブドメイン

ドメインの中の優先度の低い処理群. OSSのライブラリなど実現に必要な手段のことだと思った.

ドメインビジョン声明文

コアドメインがやることを1ページのドキュメントとして記述する. このドメインビジョン声明文は開発が進むにつれて変化し,そのたびに改訂版を出す.

凝集されたメカニズム

ドメインに関係のない処理群. 汎用サブドメインとの違いはコードが無いので,いまいちわからなかった・・・

他にも色々ありましたが,また実践ドメイン駆動設計を読んでから読み直したいです


感想

長い.

それでも読んでて面白いと思う箇所が多く,実践を読んでまた理解を深めていけたらなと思いました. 精進します.

YouTubeの音楽を垂れ流すだけのアプリを作った話

部活の制作合宿でYouTube垂れ流しアプリnoisicを作成しました.

↓実際に発表したスライド

概要

noisic

検索ワードを入れたら,その検索ワードに引っかかった動画を再生し続けるアプリです.

  • 使用技術: electron

作った目的

  • 普段,ブラウザでYouTubeを見て調べ物もする
  • タブが無限に生成される
  • chromeを落とす
  • 音楽が止まる😭

こういうことが頻繁に起こるので,解消したいと思って開発しました.

App for YouTubeというものがあるらしい

  • 軽く使った感じ次の動画へのautoplayがない?
  • 金払うとホットキーが割り当てられるらしい

大変そう

やっていき

詰まったところ

  • Reactを採用するかしないか案件 -> 結局採用しなかった
  • YouTubeの投稿者による再生の制限された動画の扱い
  • UI

感想

できてよかった

firebaseにcreate-react-appしたアプリをデプロイする

備忘録です.

install

sudo npm update -g firebase-tools
sudo npm install -g create-react-app  

create app

create-react-app [dir_name]
cd [dir_name]

dir_nameは好きな名前で大丈夫です.

firebase setting

firebase login

firebase init
=> Hostingを選ぶ.前もってfirebaseでプロジェクトを作成して,そのプロジェクト名を指定する.

firebase.jsonを以下のように変更します

- {}
+{
+  "hosting": {
+    "public": "build"
+  }
+}

build & deploy

npm run build
firebase deploy

これでdeployできた思います.

Umeda.goという勉強会に参加しました.

umedago.connpass.com

Goだけで作るフロントエンド入門 @nobonoboさん

gopherjs + vecty 最高という話

↓チャットアプリ

vecty sample

golang初心者が3dモデル出すために色々苦労した話 @akinobufujiiさん

aimingで主にクライアントエンジニアをしている

背景

golangが流行っている レンダリング周りの勉強がしたい

C++歴7年

やっていき

golang + OpenGLで3Dモデルを出してみる

go-gl/glとかいろいろ触れるライブラリが揃っている

コードは300行ぐらい

重要ポイント

5日間ぐらいでgolangで3Dモデルは描画できるぞ!

スタートアップ立ち上げの主力言語にgoを採用してみた話 @ponpoko1968さん

フリーランスのお方

人を採用したい時,rubyだと人がたくさん来るかもしれないから適度に人が少なそうなgolangを採用.

API構築にはgoaを採用.goaでswaggerの設定ファイルを吐ける. 凄い

ReactNativeでGoを使う @hatajoeさん

isomorphic go

  • サーバもクライアントも同じ言語でやっていこうという思想
  • 今回はmobileをgoでやってみたお話

gomobileでandroidからgolangを扱えるようにしてあげて,その後Nativeでbridgeする

サーバとクライアントで同一の構造体を持つことができて,varidationが楽

感想

gopherjsが非常に面白いなぁと思ったり,いろいろ楽しそうという印象でした.

ちょっとgolangをかじっただけの,goamateurなのでgolangの楽しさを色々知れて良かったです.