タグ

2016年7月1日のブックマーク (7件)

  • ナウいJavaScriptアニメーション実装法

    【ヒカ☆ラボ】JavaScriptの情報交換LT会~React/Redux,Node.js,アニメーション,Processing等々~

    ナウいJavaScriptアニメーション実装法
  • スタートアップのための、ピボットの法則 | 500 Startups Japan

    今回は500 StartupsのEIRであるSelcuk Atli氏によるブログをご紹介します。彼は以前BoostableとSocialWireというアドテクスタートアップを創業した経験を持っています。イスタンブールで育ち、フルブライト奨学金で渡米後、起業家としてYCombinatorを卒業しています。 2011年に私たちはシリコンバレーのトップクラスと言われている投資家から、200万ドルを調達しました。私たちはSocialWire(のちにManifestと社名変更)というスタートアップをやっていて、EC事業者向けにユーザーごとに商品を最適化できるサービスを提供していました。ユーザーがFacebookでアカウント登録した際に、簡単にその個人にあった商品などをパーソナライズできるよう支援するというものです。しかし、すぐに大企業が数年間もかけて最適化しているECサイトに、私たちのプロダクトを導

    スタートアップのための、ピボットの法則 | 500 Startups Japan
  • 中の人に聞いたGitHub flowの本当の使い方 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 今日GitHubの中の人のLTを聞く機会があって当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが当のGitHub-flowは違う。 当のflowは PR作成 ⇩ 修正 ⇩

    中の人に聞いたGitHub flowの本当の使い方 - Qiita
  • 生産性と創造性は両立しない:研究結果 | ライフハッカー・ジャパン

    ビジネスで成功するには、良いアイデアだけではなく、実行力が求められます。ただ、その両方を成し遂げたいのであれば、両者が相反するものであるという厳しい現実から目を背けるべきではありません。これは、テキサス大学オースティン校の心理学教授、Art Markman氏による『Harvard Business Review』誌への最近の投稿で、非常に示唆に富んでいます。ほとんどの人は、クリエイティブでありながら仕事を上手に片付けられるように努力しますが、Markman教授が指摘するのは、あまり認めたくない真実です。つまり、生産性を高めようとすることは、多くの場合、イノベーションの邪魔になり、その逆もまた真実であるということです。 生産性と創造性の間には、根的な対立があります(中略)。生産性の高い人というのは、やり遂げるべきタスクを秩序正しい方法でこなしていきます。目標に向かって、しっかりと、進捗を確

    生産性と創造性は両立しない:研究結果 | ライフハッカー・ジャパン
  • 【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO

    はじめに こんにちは植木和樹@上越妙高オフィスです。日は私がここ10年くらい意識している運用手順書を書くときのポイントについてまとめてみました。 対象読者 開発・構築したシステムを別の人に引き継ぐ予定のある人 他の人が作ったシステムを引き継ぐ担当の人 半年後の自分でも分かる手順書の書き方に困っている人 (この記事を読むのにかかる時間の目安:5分) 1. ドキュメントの冒頭に書くこと まず個々の詳細手順の前に、ドキュメント自体について記載してもらいたいことです。 1.1. ドキュメントに書かれていることを3行で書く ドキュメントの最初には、このドキュメントに何が書かれているのかを100文字くらいで書いておくと良いでしょう。 システムが増えれば増えるほど手順書も増えていくものです。見つけたドキュメントに自分の期待するものが書かれているのか、冒頭数行でわかるようになっているとうれしいです。 1

    【社内資料公開】運用手順書を作る時のポイントについて書いてみた | DevelopersIO
  • 開発や業務におけるチャットを使った情報共有の民度、潜伏あるいは揮発してしまう情報のリスクについて

    テキストチャット中心の開発コミュニケーションと課題感 ご飯ブログを書いてばかりで、老害活動できていないからたまには真っ当なブログ。 最近、テキストチャットを使ったコミュニケーションが円滑になるためには?という課題についてよく考えるのでチャットユーザの民度を上げるための覚え書きをまとめます。 Slackなどを使ったチャットコミニュケーションの民度、運用の成熟に思いを馳せてる。 — あほむ (@ahomu) June 28, 2016 オフィスワーカーにとってのチャット オフィスワーカーであっても、メールと同じで記録が残りメールよりも即時性が高い、チャットによるコミュニケーションは少なくありません。物理的に移動する手間を省き、送信側の任意のタイミングでメッセージを送れることなどが魅力です。 口頭コミュニケーションは即時性が高い代わりに揮発性も高く、その場に居合わせないと得られない情報です。口頭

    開発や業務におけるチャットを使った情報共有の民度、潜伏あるいは揮発してしまう情報のリスクについて
  • 私がMVCフレームワークをもはや使わない理由

    数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM

    私がMVCフレームワークをもはや使わない理由