パラメータを決める 次に関数に渡すパラメータを決めます。 関数の名前で表現されている処理を実現するには、どれだけのパラメータがあればよいか？　と考えてみましょう。 今回の例でいえば「お客さんの年齢」と「日付」があれば、すべてのチケット価格が計算できます。 ということで、age と date の2つのパラメータを渡すことにします。 function calculateTicketPrice (age, date) { } パラメータの名前も、なにを表しているかわかるようにしてくださいね。 くれぐれも「hensu」とか適当な名前をつけたり、同じ変数にぜんぜん違う値を繰り返し代入したりすることのないようにしましょう。 テストを書く 次にユニットテストを書きましょう。 テストは常に更新される仕様書です。 業務ロジックをテストに説明させておけば、関数の仕様をコメントにいちいち書く必要などありません。

エモい。この不明瞭な形容詞が定着するなんて思わなかった。 エモさとは何なのか？ Wikipediaには「感情が動かされた状態」、「感情が高まって強く訴えかける心の動きなどを意味する日本語の形容詞」と書いてあるけれど、いまいちよくわからない。 一方で、私の文章は、「エモい」と評価をもらうことが多い。謎めいた形容詞で言い表される文章とは一体どういうことなのか？ こんなことを書きながらも、自分自身、「あ、これはエモい」と思う作品に出合うことは多い。切なくて、妙に共感して、胸がざわつくあの感じ。単に甘美な言葉を羅列しただけでは、こんなに胸は動かされない。 私は、ひとつ仮説を持っている。 決して同じ体験をしたわけではないけれど、映像が頭に浮かび、追体験したような気分になる。この時、人は文章にエモさを感じるのではないか？ それは「固有名詞」×日常性で作れる。 『ボクたちはみんな大人になれなかった』は、

鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ

はじめに VueをつかってWebアプリケーションを実装するとき、Componentをどう切るかって誰でも一度は悩みますよね(悩みますよね？)。とりあえず思いつくままに切ってみたり、繰り返し使いそうなもので切ってみたり、CSSのスコープで切ってみたり…。いろいろな切り口があると思います。 この「いろいろな切り口」でコンポーネントを切ることができる点が、コンポーネント設計を難しくしている所以だと考えています。 そこで今回は、どのような切り口・観点でコンポーネントを切ればよいのか、そのときに気をつけるべきことは何か、といったComponentの設計方法についてまとめてみます。 すべての実用ケースを想定できているわけではないと思いますが、大小いくつかのWebアプリを開発する際に利用してみて今のところいい感じに運用できている方法です(というか自然と収束して出来上がった考え方という感じです)。 はじめ

Mobile Push Notifications Direct, highly visible, mobile-first

こんにちは。レストランボードでiOS開発を担当しているいちきです！ 突然ですが、皆さんのプロジェクトではデザインファイルをどう管理されていますか？ 今回はデザイナー、エンジニア協働で取り組んだデザインのファイル管理改善についてお話したいと思います。 はじめに 僕が配属された当時のレストランボードのデザイン共有フローです。 デザインファイルは会社の共有ドライブで管理している 案件ごとにフォルダーを作り、デザインをしたらそこに追加していく 新案件がある度に前のデザインから必要な要素を取ってきてデザインする エンジニアとの共有は画像データに書き出して渡す(エンジニアはデザインファイルの場所を把握していない) デザイナーはプロジェクトに1名(現在は2名) 必要なデザインがあればデザイナーにお願いをしてデザインの画像を受け取っていました。 見えてきた課題 デザインを確認したい時にはデザイナーへ依頼を

土日祝日などの勤務時間外にがんばって出した成果を「やっていき」「圧倒的当事者意識」などと手放しに称賛しない方が良いと思っている。 「いやー土日にがんばるなんてスゴイっすね〜〜〜」と褒められて気分良くなったりするんだけど往々にしてそもそも実現不可能なスケジュールの帳尻合わせに加担してしまっていたりする。そういうのは個人の頑張りで巻き返すのではなくいっそ破綻させた方が全体の教訓になるので好ましい。 こういう振る舞いを迂闊に繰り返すとだんだん周囲の期待値も変わってきて「休日で巻き返せる/巻き返してくれるからいっか」「今週末は働いてくれなかったのか…」となってくる。*1 ボランティア精神に近い個人の貢献は当たり前ではないことを共有し続けないといけない。 誤解しないようにしたいのが問題なのは「やり方」であって「出した成果」それ自体は尊いということ。「休日に対応したからゴミ」みたいなことは、ない。平日

ブログ運営で大切なことは、公開した記事がきちんと読まれることです。ウェブアナリストの小川卓さんによるブログ分析の入門。第2回は、良い記事を見極める「読了率」と「スクロール率」についてです。 cover photo by Jastrow (2008) - Musa reading a scroll., Public Domain, Link前回の記事では、過去の記事を評価する方法を紹介しました。 過去の記事を「地層」にしよう！ ブログの「初月率」を取得して改善に活かすには【小川卓のGoogleアナリティクスではてなブログ分析入門 第1回】 - 週刊はてなブログ 今回は、公開後間もないものも含めて記事自体を評価する方法を紹介します。良い記事と悪い記事を見極めるには、何を見る必要があるのでしょうか？ わかりやすい指標としては、ページビュー数やはてなブックマーク数などがあるでしょう。そういった数字

地味に便利なものから慣れるとなくてはならないものまで、GitHubを見やすく・使いやすくしてくれる拡張機能を紹介します。 ここではすべてChromeの拡張機能として紹介していますが、中にはその他のブラウザでも利用可能（主にFirefoxのアドオン）なものもあるので、それらは併せて紹介している各拡張機能のGitHubページなどから辿ってください。 以下で紹介している拡張機能の一部は、プライベートリポジトリでも利用できるようにするなどの理由でアクセストークンを設定する必要があります。 入力する旨が表示されたり各拡張機能の紹介ページに設定方法として記載もされていますが、ほとんどの場合は「Developer settings」から移動した先で「repo」を選択して作成し、出力されたコードを設定欄に記述します。 GitHub File Icon screen shot by GitHub File