Rust の練習も兼ねて、AtCoder の問題を使ってちょこちょこトレーニングをしてみてる
多重ループを作った時に、深いループから抜け出す方法として調べたらこれがでてきた
ネストとラベル - Rust By Example 日本語版
ターゲットになるループにラベルをつけて、breakの時に指定するらしい
これは読みやすい!
Rust の練習も兼ねて、AtCoder の問題を使ってちょこちょこトレーニングをしてみてる
多重ループを作った時に、深いループから抜け出す方法として調べたらこれがでてきた
ネストとラベル - Rust By Example 日本語版
ターゲットになるループにラベルをつけて、breakの時に指定するらしい
これは読みやすい!
関数の返り値に 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 の話です
プログラムのソースコードは言語ごとの文法に則って記述されます
言語の文法は文(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 では一応三項演算子はかける
こうゆう他の言語との比較は面白いですね!
久しぶりにブログを再開しようと思う
今年は積極的にアウトプットすることを目標にしていきたいと思ってる
週1とかで続けたい...
今日はセンター試験(今は共通テストと名称が変わったとのこと)の2日目らしい
受験生のみんな
おつかれさまです
まだ他にも試験が続いたりすると思うけど、一旦今日はゆっくりお風呂につかってリフレッシュしてください
受験生のお子さんを持つ知り合いもいて、今回はちょっと試験が身近に感じる
うまくいった人、そうじゃなかった人いろいろあると思う
自分の過去を振り返ると、どんな結果が出ようが、あとからの物事の捉え方/解釈の仕方で本当にその後の人生はどうにでもなるということを感じています
(センター試験に関しては自分はうまくいかなかったw)
自分もまだまだ人生の途中で偉そうなことは言えないし、今後どうなるかわからない
しかし、起きちゃったことはしょうがないんですよね
それよりもここからどうするかが大事という気持ちのコントロールが大事で、今後大なり小なり想定外のことは起こる
想定外と書くとなんかネガティブな印象を受けると思うが、想定外にはポジティブなものやネガティブなものもあって、
それを受け入れた上で取れる選択肢を洗い出し、自分にとってよさそうなものを選択していくといいと思う
少なくとも、自分はそこでいろいろな人に出会い、知識を得たりして生活できている
今後もそんな風に生きていくことになると思う
個人的にはそうゆう時、ちょっとでも自分がなりたい人がいそうな環境やなりたい人がとりそうな行動を想像して選ぶといい結果が得られるように感じる
今はなりたい人がいない場合、自分の周りを見渡してその時点で「うらやましいな〜」と思う人を観察したり、アプローチしてみるといいと思う
本を読むとかもいいですね
他の人の人生や考え方に少し関心を持つというのがいい気がします
実はイメージと違ったとかも含めて、そこから知ることはたくさんあるはず
それも想定外
最後に引用で締めたいと思います
You play with the cards you’re dealt …whatever that means.
「配られたカードで勝負するしかないのさ...それがどうゆう意味であれ」
漫画『Peanuts』よりスヌーピーのセリフ
そんなこんなで今年も1年よろしくおねがいします!!
クチコミってどんな人が書くんだろー、書く人の気持ちが知りたい
と思い、この何ヶ月か書いてみたところ
特に店舗を持つ人はやってみるといいなと思ったのでまとめておく
自分が目につくところは、自分のお店に来た方でも気になる人がいる。
その店の店長が期待してること(こだわり)を想像する。
なぜそう思ったのかまとめる(メニューやポップ、会話など)
ギャップがあれば、それを書く
情報の非対称性を意識する。
やさしく〜みたいな言葉で集客して、専門用語ドカッドカンはダメ
周りのお客さんに対して店員さんがどのような言葉を使っているか見てみる
Googleローカルガイドはレベルが上がって楽しい
その上顧客目線をつける練習になるのでぜひやってみて欲しい
今回の投稿は、第58回ヨルクルでプチセミナーの講師を行った際、話す内容を事前にまとめた原稿です
ヨルクルというのは「南大阪発egaoプロジェクト」という介護福祉に関わる方々のコミュニティで、定期的に開催されているセミナーイベントです。
当日発表したスライドはこちら
制作コストも低下してきたため
Web/チラシ/動画...などを制作に依頼した方も多いのではないでしょうか!?
その中でも、成果物を見て「思ってたんと違うな...」という経験をした人も多いのでは?
それって実は制作が始まった時点から、すでに決まってた未来かもしれません...
本日のセミナーの結論を1つの画像で示すと以下のようなイメージです
「二人三脚」です
それでは始めていきましょう
おそらく勘のいい人はこれだけですべてを理解していただけるような気がしますが笑
それだけだと抽象的すぎるので、1つずつ紐解いていきます
制作をするにあたって必要なものはなんでしょうか?
少し広告媒体と離れますが、ここでは犬小屋を作るという前提で考えてみましょう
大きくまとめると必要なものは以下の3つになると思います
Web/チラシ/動画制作を行うときも基本的には同じです が異なる点もあります
異なる点は
* 素材の大部分は発注者が持っている(持っていることを知らないケースも)こと
ではないでしょうか?
道具は制作が持っています
計画はその素材/道具を考慮して制作と発注者が作成するものです
コー●ンにあなたの会社の熱意は売っていませんよね
以下の3つのステップに気をつければ、十分な素材が提供できると思います
この3つの中身を説明していきます
2つのポイントがあります * 想いの共有 * ゴールの共有
制作の目的というくくりですが、少し抽象度を上げてまずは制作以前の会社やサービス、プロジェクトについて、
どのような想いで作ったのか伝えないといけません。
なぜ会社/サービス/プロジェクトを作りたいと思ったのか
誰に届けたいと思ったのか
どんな人の課題を解決するのか
感情を揺さぶるのか
コンテンツを知った/使った結果どうなるのか がこの項目にあたります。
その成果物によって何かしら達成したいゴールがあるはず
なぜその成果物を望むのかを知りたい
どんなことをして欲しいの?
感動してほしい
ゴールを共有していないとどうなるのか?
どくさいスイッチの話 のび太がジャイアンにいじめられる のびた: ジャイアンさえいなければ、こんな目に合わずにすむ ドラえもん: じゃあ消しちゃう? => どくさいスイッチ ジャイアンを消す ジャイアンはこの世から跡形もなく消えるが、スネ夫がのび太をいじめる スネ夫消す...... 最終的にみんな消えてしまう
のび太はいじめられたくなかった=> これが本当のゴール 体を鍛える/殴られても痛くなくする/ジャイアンを優しくしてしまう...手段は色々
一緒にゴールを考える(考えてもらう)というプロセスを制作なぞることが重要です
イメージに近いものを列挙
ステップ1で共有した情報を元に参考サイトや競合サイトを見つける
掘り下げ
列挙してもらったモノのどの部分が目に止まったのか、伝える
* 素材の色味
* 動き
* テキスト...
テキスト/画像の配置を決めていく 想いの部分で共有してもらった情報を元に、優先順位をもってテキスト/画像の配置を決めていく
頻度を上げる、実際にラフを共有された時など、なるべく早くチェックする ツールを上手く活用しましょう
制作チームは生のリアクションを求めています そのため、違和感を感じた場合は早めにそれを言語化(言語化できなくてもネガ/ポジを伝える)し、伝えることが重要です
二人三脚も頻繁に声かけを行い、お互いにゴールを視認しながら進んでいきます。
制作の場合も以下のステップを踏むことで限りなく「思ってたのと違う」というケースは減ります。
を意識して、結果の出る成果物を作成していきましょう!!
似たようなissueを発見したのでメモ
作者によるシンプルな回答
各レスポンスにjwt含めばいいよね
毎回tokenの期限が更新されるし、なるほどそうだよなと思いつつ ユーザーがアクションしなくなってから、1.dayなり有効期限が経過した時に無効化されればいい
カスタマブルなコンポーネント作成を行うためにコードリーディング
今日気になった部分は
vue-material/MdButton.vue at dev · vuematerial/vue-material · GitHub
md-buttonにclassを渡してテンプレにclassが渡る部分
ここでmd-primaryなどを渡すことで、ボタンのカラーを変更したりできる
vueの標準仕様で
カスタムコンポーネント上で class 属性を使用するとき、これらのクラスはコンポーネントの root 要素 に追加
とのことです
なるほど!!
こちらの記事そのままだったんですが、少しわかりにくかったので...
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がインストールできれば、エラー表示はなくなる...
これでいいのだろうか
ではでは〜
微妙にハマってしまったのでメモ
Node.JSのMongoDBのクライアントでは有名どころでMongooseがあると思うのですが、
個人的な理由でMongoDB Node.JS Driverを使ってます
(一応本家が出してるしな〜的な軽い理由です)
これまで使ってて特に何も感じなかったのですが、
データはMongoDBの中に確実に入ってるのに、ドライバ経由でデータを取ろうとすると取れないという現象に遭遇しました
僕が引っかかったのはこちらの問題でした
これまではid以外のPKのフィールドでデータを取得し、
取得したデータからhoge._idで取得していたから気づかなかった...
すでにクエリから取得したデータは自動でIDがObjectIDに変換してくれてたっぽい
(パッと見文字列だけどよくよく見ると""が付いてなかった)
その値を他のコレクションに渡してデータを投げてたからこれまで支障がなかったという...
今回はIDからデータを取ろうと思って、id: "hexstringhogehoge"のように
idにstringを渡せば取れると思ったけど失敗した形
じゃあどうすればよかったかっていうと
const ObjectID = require('mongodb').ObjectID ObjectID.createFromHexString('hexstringhogehogehoge')
みたいに文字列をObjectIDに変換してからクエリとして使おう
ではでは〜