islands5 blog

日々起こったことを共有したり、思ったこと、勉強したことを書いていくブログ。普段はRailsやAWSを活用したWeb系の開発をやってます。

Rust を始めてみている(ループから抜ける break について)

Rust の練習も兼ねて、AtCoder の問題を使ってちょこちょこトレーニングをしてみてる

多重ループを作った時に、深いループから抜け出す方法として調べたらこれがでてきた
ネストとラベル - Rust By Example 日本語版 ターゲットになるループにラベルをつけて、breakの時に指定するらしい
これは読みやすい!

Rust を始めてみている(Box<dyn Hoge> について)

関数の返り値に Box と返す箇所があり、「はて??」となった箇所があったので少し調べた

ドキュメントによると

Rustのコンパイラはあらゆる関数のリターン型に必要なスペースを知っておく必要があります。... そのトレイトの異なる実装はそれぞれ別の量のメモリを必要とするからです。

dynを利用してトレイトを返す - Rust By Example 日本語版

なるほど、参照だったらどんなサイズが入るか決まるので、必要なスペースがコンパイラもわかるよってことみたいです
本の例だと、BufReadトレイトを File.open, std::io::stdin が実装してるので利用していたということでした

Box と dyn は組み合わせて使うものなのかな〜と思って調べたら、深淵にハマりそうだったのでまた後日...

Box はヒープメモリ確保に関連
dyn は... まだようわからん
戻り値がどのような特徴を持つ型になるかどうかで変わる様子(impl Trait というものもあるそう)

少しずつ深堀っていければいいと思う

参考リンク
dynを利用してトレイトを返す - Rust By Example 日本語版 Box, スタックとヒープ - Rust By Example 日本語版 Rustのdyn Traitとimpl Traitの違いについて 安定化間近!Rustのimpl Traitを今こそ理解する - 簡潔なQ

Rust を始めてみている(if 式について)

最近は少しずつ Rust の本を写経していってます
なにかしらのアウトプットを軽くでもしていければな〜と思ってちょっとメモ
if の話です

プログラムのソースコードは言語ごとの文法に則って記述されます
言語の文法は文(Statement)と式(Expression)というもので構成されています めっちゃ簡単に言うと文は値を返さない、式は値を返すという特徴があります。

普段僕がよく使ってる Ruby も if は式で、そうゆう点では Rust は if を Ruby っぽく使えそうです

例えばある特定の値を条件によって変化させたい場合

if 文を扱う言語(C や Go など)の場合
(cond は何かしらの条件です)

int value = 0;

if(cond) {
  value = 5;
}else{
  value = 10;
}

一旦宣言して上書きするような感じ 一方 if 式(Rust や Ruby)の場合

let value = if cond {
                     5
                   } else {
                     10
                   };

こんな感じで1行で書けます

let value = if cond == 0 { 5 } else { 10 }

こんな感じで1行でもかけちゃうからか、Rustでは三項演算子がないみたいです
Ruby では一応三項演算子はかける
こうゆう他の言語との比較は面白いですね!

参考リンク

式と文、評価と実行、そして副作用 ―― プログラムはいかにして動くのか【前編】

演算子式 (Ruby 3.3 リファレンスマニュアル)

想定外が起きたときの選択について

久しぶりにブログを再開しようと思う
今年は積極的にアウトプットすることを目標にしていきたいと思ってる
週1とかで続けたい...

今日はセンター試験(今は共通テストと名称が変わったとのこと)の2日目らしい

受験生のみんな
おつかれさまです
まだ他にも試験が続いたりすると思うけど、一旦今日はゆっくりお風呂につかってリフレッシュしてください

受験生のお子さんを持つ知り合いもいて、今回はちょっと試験が身近に感じる

うまくいった人、そうじゃなかった人いろいろあると思う
自分の過去を振り返ると、どんな結果が出ようが、あとからの物事の捉え方/解釈の仕方で本当にその後の人生はどうにでもなるということを感じています
(センター試験に関しては自分はうまくいかなかったw)

自分もまだまだ人生の途中で偉そうなことは言えないし、今後どうなるかわからない
しかし、起きちゃったことはしょうがないんですよね

それよりもここからどうするかが大事という気持ちのコントロールが大事で、今後大なり小なり想定外のことは起こる

想定外と書くとなんかネガティブな印象を受けると思うが、想定外にはポジティブなものやネガティブなものもあって、
それを受け入れた上で取れる選択肢を洗い出し、自分にとってよさそうなものを選択していくといいと思う
少なくとも、自分はそこでいろいろな人に出会い、知識を得たりして生活できている
今後もそんな風に生きていくことになると思う

個人的にはそうゆう時、ちょっとでも自分がなりたい人がいそうな環境やなりたい人がとりそうな行動を想像して選ぶといい結果が得られるように感じる
今はなりたい人がいない場合、自分の周りを見渡してその時点で「うらやましいな〜」と思う人を観察したり、アプローチしてみるといいと思う
本を読むとかもいいですね
他の人の人生や考え方に少し関心を持つというのがいい気がします

実はイメージと違ったとかも含めて、そこから知ることはたくさんあるはず
それも想定外

最後に引用で締めたいと思います

You play with the cards you’re dealt …whatever that means.
「配られたカードで勝負するしかないのさ...それがどうゆう意味であれ」

漫画『Peanuts』よりスヌーピーのセリフ

そんなこんなで今年も1年よろしくおねがいします!!

お客様目線を養う方法

クチコミってどんな人が書くんだろー、書く人の気持ちが知りたい
と思い、この何ヶ月か書いてみたところ

特に店舗を持つ人はやってみるといいなと思ったのでまとめておく

初めて利用したサービスで思ったことをまとめる

自分が目につくところは、自分のお店に来た方でも気になる人がいる。
その店の店長が期待してること(こだわり)を想像する。
なぜそう思ったのかまとめる(メニューやポップ、会話など)
ギャップがあれば、それを書く

専門的なサービス(例えば家電量販店)なら...

情報の非対称性を意識する。
やさしく〜みたいな言葉で集客して、専門用語ドカッドカンはダメ
周りのお客さんに対して店員さんがどのような言葉を使っているか見てみる

まとめ

Googleローカルガイドはレベルが上がって楽しい
その上顧客目線をつける練習になるのでぜひやってみて欲しい

思ってたのと違う...を減らす、制作に依頼する技術〜第58回ヨルクルプチセミナー

今回の投稿は、第58回ヨルクルでプチセミナーの講師を行った際、話す内容を事前にまとめた原稿です
ヨルクルというのは「南大阪発egaoプロジェクト」という介護福祉に関わる方々のコミュニティで、定期的に開催されているセミナーイベントです。

当日発表したスライドはこちら

以下原稿

制作コストも低下してきたため
Web/チラシ/動画...などを制作に依頼した方も多いのではないでしょうか!?
その中でも、成果物を見て「思ってたんと違うな...」という経験をした人も多いのでは?
それって実は制作が始まった時点から、すでに決まってた未来かもしれません...

本日のセミナーの結論を1つの画像で示すと以下のようなイメージです
f:id:fiveislands:20190505173423p:plain
「二人三脚」です
それでは始めていきましょう

おそらく勘のいい人はこれだけですべてを理解していただけるような気がしますが笑
それだけだと抽象的すぎるので、1つずつ紐解いていきます

そもそも制作に必要なものとは

制作をするにあたって必要なものはなんでしょうか?
少し広告媒体と離れますが、ここでは犬小屋を作るという前提で考えてみましょう

  • トンカチ
  • ペンキ
  • 設計図
  • (お金) ...

大きくまとめると必要なものは以下の3つになると思います

  • 道具
  • 素材
  • 計画

Web/チラシ/動画制作を行うときも基本的には同じです が異なる点もあります

異なる点は * 素材の大部分は発注者が持っている(持っていることを知らないケースも)こと ではないでしょうか?
道具は制作が持っています
計画はその素材/道具を考慮して制作と発注者が作成するものです

コー●ンにあなたの会社の熱意は売っていませんよね

素材を提供する

以下の3つのステップに気をつければ、十分な素材が提供できると思います

  1. 制作の目的を明確に
  2. 完成のイメージをすりあわせ
  3. コミュニケーション

この3つの中身を説明していきます

制作の目的を明確に

2つのポイントがあります * 想いの共有 * ゴールの共有

想いの共有

制作の目的というくくりですが、少し抽象度を上げてまずは制作以前の会社やサービス、プロジェクトについて、
どのような想いで作ったのか伝えないといけません。

なぜ会社/サービス/プロジェクトを作りたいと思ったのか
誰に届けたいと思ったのか
どんな人の課題を解決するのか
感情を揺さぶるのか

コンテンツを知った/使った結果どうなるのか がこの項目にあたります。

ゴールの共有

その成果物によって何かしら達成したいゴールがあるはず
なぜその成果物を望むのかを知りたい どんなことをして欲しいの?

  • 会社を知ってほしい
  • 問い合わせしてほしい
  • キャンペーンを知ってほしい&来て欲しい
  • 感動してほしい

  • ゴールを共有していないとどうなるのか?

どくさいスイッチの話 のび太がジャイアンにいじめられる のびた: ジャイアンさえいなければ、こんな目に合わずにすむ ドラえもん: じゃあ消しちゃう? => どくさいスイッチ ジャイアンを消す ジャイアンはこの世から跡形もなく消えるが、スネ夫がのび太をいじめる スネ夫消す...... 最終的にみんな消えてしまう

のび太はいじめられたくなかった=> これが本当のゴール 体を鍛える/殴られても痛くなくする/ジャイアンを優しくしてしまう...手段は色々

一緒にゴールを考える(考えてもらう)というプロセスを制作なぞることが重要です

完成イメージのすり合わせ

イメージに近いものを列挙
ステップ1で共有した情報を元に参考サイトや競合サイトを見つける

掘り下げ
列挙してもらったモノのどの部分が目に止まったのか、伝える
* 素材の色味 * 動き * テキスト...

テキスト/画像の配置を決めていく 想いの部分で共有してもらった情報を元に、優先順位をもってテキスト/画像の配置を決めていく

コミュニケーション

頻度を上げる、実際にラフを共有された時など、なるべく早くチェックする ツールを上手く活用しましょう

  • メールよりはチャット
  • 会議とオンライン会議を併用

制作チームは生のリアクションを求めています そのため、違和感を感じた場合は早めにそれを言語化(言語化できなくてもネガ/ポジを伝える)し、伝えることが重要です

まとめ

二人三脚も頻繁に声かけを行い、お互いにゴールを視認しながら進んでいきます。
制作の場合も以下のステップを踏むことで限りなく「思ってたのと違う」というケースは減ります。

  1. 制作の目的を明確に
  2. 完成のイメージをすりあわせ
  3. コミュニケーション

を意識して、結果の出る成果物を作成していきましょう!!

RailsAPIモードで認証にknockを利用してる場合、最初に認証してから一定期間経つとjwtが切れてしまう件について

似たようなissueを発見したのでメモ

作者によるシンプルな回答  

各レスポンスにjwt含めばいいよね  

github.com  

毎回tokenの期限が更新されるし、なるほどそうだよなと思いつつ   ユーザーがアクションしなくなってから、1.dayなり有効期限が経過した時に無効化されればいい

vue-materialのコードを読んでみる〜button編〜v1

カスタマブルなコンポーネント作成を行うためにコードリーディング

今日気になった部分は
vue-material/MdButton.vue at dev · vuematerial/vue-material · GitHub

md-buttonにclassを渡してテンプレにclassが渡る部分
ここでmd-primaryなどを渡すことで、ボタンのカラーを変更したりできる

クラスとスタイルのバインディング — Vue.js

vueの標準仕様で

カスタムコンポーネント上で class 属性を使用するとき、これらのクラスはコンポーネントの root 要素 に追加

とのことです
なるほど!!

brew周りをいじった時にError: qt@5.5: unknown version :mountain_lionに遭遇した時の対処

こちらの記事そのままだったんですが、少しわかりにくかったので...

brew update
cd $( brew --prefix )/Homebrew/Library/Taps/homebrew/homebrew-core

# below is the last commit containing qt@5.5 with homebrew
git checkout 9ba3d6ef8891e5c15dbdc9333f857b13711d4e97 Formula/qt@5.5.rb

<- この段階でgrepなどを使ってmoutain_lionをサーチ
するとqt@5.5.rbみたいなファイルがヒットするので
depends_on :macos => :moutain_lion
をコメント

# here is where the error occurs
brew install qt@5.5

これでqt@5.5がインストールできれば、エラー表示はなくなる...
これでいいのだろうか

ではでは〜

MongoDB Node.JS driverを使って躓いたメモ

微妙にハマってしまったのでメモ

Node.JSのMongoDBのクライアントでは有名どころでMongooseがあると思うのですが、 個人的な理由でMongoDB Node.JS Driverを使ってます
(一応本家が出してるしな〜的な軽い理由です)

これまで使ってて特に何も感じなかったのですが、
データはMongoDBの中に確実に入ってるのに、ドライバ経由でデータを取ろうとすると取れないという現象に遭遇しました

_id系を検索クエリに入れるときは、ObjectID.createFromHexStringで変換してから

mongodb.github.io

僕が引っかかったのはこちらの問題でした

これまではid以外のPKのフィールドでデータを取得し、
取得したデータからhoge._idで取得していたから気づかなかった...
すでにクエリから取得したデータは自動でIDがObjectIDに変換してくれてたっぽい
(パッと見文字列だけどよくよく見ると""が付いてなかった)

その値を他のコレクションに渡してデータを投げてたからこれまで支障がなかったという...

今回はIDからデータを取ろうと思って、id: "hexstringhogehoge"のように
idにstringを渡せば取れると思ったけど失敗した形

じゃあどうすればよかったかっていうと

const ObjectID = require('mongodb').ObjectID

ObjectID.createFromHexString('hexstringhogehogehoge')

みたいに文字列をObjectIDに変換してからクエリとして使おう

ではでは〜