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

本日,応用情報技術者試験(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の楽しさを色々知れて良かったです.

DDD本の1章~5章までで気になったところまとめ

DDD本の1章から5章までで気になったところの個人的まとめです.

www.shoeisha.co.jp

2章

ユビキタス言語

とにかく用語などを使うのではなく,そのチームでの定義を設けその言語を使えということ. 一つのチームに一つのユビキタス言語を使用することが理想であると書かれていた

4章

レイヤードアーキテクチャ(LAYERED ARCHITECTURE)

  1. ユーザインタフェース層,プレゼンテーション層
  2. アプリケーション層
  3. ドメイン
  4. インフラストラクチャ層

以上の4つのレイヤーからなるアーキテクチャである.1.が一番上のレイヤーで4.が一番下のレイヤーである.

ユーザインタフェース層は表示周りの処理,アプリケーション層は上と下をつなぐインターフェース的な役割,ドメイン層はロジック周りの処理,インフラストラクチャ層はデータの永続化などドメイン層を支える処理を行う.

このアーキテクチャの特徴は,複雑なコードをレイヤーで分割し,それによって各レイヤーごとの責務に集中するだけでよくなる点である. 各レイヤーが下のレイヤーにのみ依存し,上のレイヤーとは疎結合な関係を保つことを容易に実行できる.

5章

エンティティと値オブジェクト

エンティティは,各エンティティに識別番号などを持たせオブジェクトごとの同一性を判断する. 例として,座席が挙げられていた. 座席はどれも同じものであるが,座席番号がついており座席ごとで区別することができる.

それに対して値オブジェクトは,同一性を判断しないオブジェクトである. この値オブジェクトの中にはエンティティなども含まれており,その場合は値オブジェクトの中のエンティティで同一性を判断することになる.

サービス

エンティティや値オブジェクトを触るインターフェースとして提供されているのが,サービスである. サービスを設けることにより,ロジック部分とエンティティや値オブジェクト部分を明確に分離できる. サービスは単にエンティティや値オブジェクトをつなぐだけなので,ステートレスである必要がある.

モジュール

ドメインロジックなどを他のコードと切り離すときなど利用する場面が多いらしい

感想

まだ序章