タグ

2017年12月17日のブックマーク (9件)

  • コンポーネント指向フロントエンド開発におけるデザイナーの参画について - Qiita

    この記事はドワンゴ AdventCalendar 2017の17日目の記事です。 dwangoアドベントカレンダー17日目を担当させていただきます @ln-north です。デザイナーとして2016年度新卒として入社し、もうすぐ2年になります。 エンジニアさんで埋められるカレンダーの中、ひっそりとデザイナーも参加させていただきます、どうぞお手柔らかに…。 はじめに ここ何年かのWebフロントエンド界隈の動きは非常に大きくそして速く、デザイナーから見ても様々なパラダイムシフトが起こっています。scsswebpackからHTML5やCSS3まで…当に大変ですよね。 特に最近はReactVueなど、 コンポーネント指向 のWebシステム開発が発展を遂げています。Web Componentsなども含め、流れを見てるとおそらくWebはこのコンポーネント指向に向かい、しばらく進んでいくのだろうと

    コンポーネント指向フロントエンド開発におけるデザイナーの参画について - Qiita
  • 「いつも笑顔で明るい女が好き」。「都合のいい人外」を求めるポジティブ信仰男 - 妖怪男ウォッチ

    女子が言う「包容力がある男の人が好き♡」は「自分の悩みや感情を全部受けとめてくれて、自分を全肯定してくれて、弱さやネガティブさを見せない」地母神タイプの人外を求めていることがある、と書きました。 婚活女子がよく言う条件「一緒にいて楽しい人・価値観が合う人がいい」がゆるふわすぎて危ない - 妖怪男ウォッチ で、これと似た男性バージョンが「いつも笑顔の人がいい」「いつもポジティブな人がいい」「いつも穏やかな人がいい」「いつも癒される女性がいい」です!!! うんうん笑顔は最高だよねーときめくよねー癒やしだよねーなどと軽く流してしまいがちですが、じっくり話を聞いてみると「それって女性に人外になれって言ってる???心を殺して欲しいマン?欲しいマン?」と詰め寄りたくなる案件、けっこうあります。 インタビューをもとに共通項をどかんと解体してみましょう! 事例1:「愚痴は君らしくない。いつも笑顔でいてほし

    「いつも笑顔で明るい女が好き」。「都合のいい人外」を求めるポジティブ信仰男 - 妖怪男ウォッチ
  • freeeのChatbotが問い合わせの4割近くを解決できるようになるまで - freee Developers Hub

    はじめまして、freee FastestCustomerSupportチームに所属しています、浅越(あさこし)です。社内ではこっしー/kossyと呼ばれています。特技は身長です。 この記事は freee Developers Advent Calendar の16日目です。 突然ですが、会計freeeではプロダクト内で自動応答システム、いわゆるChatbotなサポートを提供しており、ユーザーの皆様からのお問合せに24時間回答ができるようにしています。 2017年1月に公開してから約1年になり、チャットサポートにお問い合わせいただく数と比較して4割近くの対応が完結できている計算になっています。 freeeのカスタマーサポートチームはユーザー皆様の対応以外にもいろんな分野の業務を担えるように日々取り組んでおり、その一環でこちらの導入や運用も担当をしてきました。今日はその経緯やこれまで感じたとこ

    freeeのChatbotが問い合わせの4割近くを解決できるようになるまで - freee Developers Hub
  • TechCrunch | Startup and Technology News

    It’s all part of an effort to say that, this time, when the shareholders vote to approve his monster $56 billion compensation package, they were fully informed.

    TechCrunch | Startup and Technology News
  • PM(Product Manager)って何やってるのか具体的な案件を見ながら説明してみる - freee Developers Hub

    この記事は freee Developers Advent Calendar の17日目です。 自己紹介 freee 株式会社で、PM(Product Manager)をやっているfuji_tipです。 freeeに入ってから4年で、マーケティング/事業開発 —> データ分析 —> 事業戦略 —> PM という変遷で、社内ジョブホッパーです。フルスタック社員と自称しています。 趣味は飲酒です。 PMってなにやってるの 社内外から、PMって何やってるかわからない、どういう能力があればPMになれるのかわからないなどの声をもらうことが多いので、具体的な案件のリリースまでのプロセスを振り返りながら、PM仕事について理解いただければと思います。 ある機能を作る!とか既存の機能改善をする!となったときの大体の流れを簡単に下記の通り説明します。 課題選定・ゴール設定 それが当に課題なのか?課題だとし

    PM(Product Manager)って何やってるのか具体的な案件を見ながら説明してみる - freee Developers Hub
  • SpringのDIとAOPの簡潔な説明 - Qiita

    前提 記事は「Spring3 入門」(通称:緑)を参考にしました Spring:Java言語のフレームワーク Springの肝はDIとAOP 【DI】(Dependency Injection) 〜概要〜 日語訳すると「依存性の注入」です。 SpringのDIコンテナの利点は大きく2つあります。それは、 クラスからnew演算子を消せる インスタンス化を1回で済ませられる(Singleton) です。 〜実装〜 実現する方法は2通りあります。 アノテーションを使う Bean定義ファイルを使う です。 アノテーションベースの方のみ説明書きます。 インスタンス変数(注入先の変数)の前に@Autowiredをつけると、@Componentアノテーションのついたクラスの中から該当するものを探し、newしてインスタンスを突っ込んでくれます! ▼(実装例) (パッケージ名やimport文は省略)

    SpringのDIとAOPの簡潔な説明 - Qiita
  • メルカリチャンネルにおけるFirebaseの利用例 | メルカリエンジニアリング

    Mercari Advent Calendar 2017 の16日目は@sota1235がお届けします。 この記事では私のチームが開発しているメルカリチャンネルでFirebase Realtime Databaseを使うにあたり行っている工夫をご紹介します。 同じ文脈の話を今年のPHPカンファレンスでも発表したのですが、この記事ではその時お話できなかったもう少し細かい工夫を4つ紹介したいと思います。 Realtime Databaseへのリクエストを間引く Realtime Databaseは非常に高トラフィックな通信を捌くことができます。 とはいっても無尽蔵にデータ更新処理をしたり読取処理をできるわけでは当然ありません。 メルカリチャンネルでは以下のように多くの用途にRealtime Databaseを利用しています これらを全て素直にRealtime Databaseに書き込むとすぐに

    メルカリチャンネルにおけるFirebaseの利用例 | メルカリエンジニアリング
  • 初心者がGASで同窓会の参加受付から名簿更新までを自動化した話 - ytmatsuge's log

    この記事は CAMPHOR- Advent Calendar の16日目の記事です。 ytmatsuge です。 普段は六木の会社で新規事業のビジネスサイドを担当しております。 日は、非エンジニアの私が、同窓会委員の負担を減らすべく、出欠確認・名簿更新の自動化に携わった話をまとめてみます。 自動確認メールの送信 自動更新名簿の作成方法 上記のような技術的な話はもちろんですが、「母世代でも利用しやすいサービス企画・設計」「最小限のコストで問題解決する方法」など、業務上の目的で実際に利用されるサービスをつくるにあたっていくつかハードルがあったので、少しでも参考にしていただければと思います。 改善前の状況 改善前の状況では、同窓会事務局と卒業生がメールでやり取りをし、 その情報をエクセルに転記しリストを作成していました。図にすると次のような流れになります。 これを見た若者は いや、 LINE

    初心者がGASで同窓会の参加受付から名簿更新までを自動化した話 - ytmatsuge's log
  • Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita

    記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション

    Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita