André Staltz - Unidirectional User Interface Architectures
This post is a non-exhaustive quick overview of the so-called “unidirectional data flow” architectures. Not meant to be taken as a beginner tutorial, but rather as an overview of their differences and peculiarities. At the end, I’ll introduce a new architecture which deviates significantly from the others. This post assumes client-side Web UI frameworks only. TERMINOLOGY It would be confusing to t
Uberがリアルタイムマーケットプラットフォームをスケールしている方法 | FAworksブログ
Uberは、たった4年で38倍という目覚ましい成長を遂げたという。今回が恐らく初めてだと思うが、UberのチーフシステムアーキテクトであるMatt Ranney氏が、その面白くて詳細にわたる発表、「Scaling Uber’s Real-time Market Platform（Uberのリアルタイムマーケットプラットフォームをスケーリングする）」の中で、Uberのソフトウェアの仕組みについて詳しく説明している。 もしあなたが「急騰料金（サージ・プライシング）」に興味があるなら、それはこの発表の中に出てこない。知ることができるのは、Uberのディスパッチシステム、同社の地理空間インデックスの実装方法、システムのスケール方法、高可用性の実現方法、不具合の対処法についてだ。例えば、ドライバーの電話をリカバリ用の外部分散ストレージシステムとして使うという、データセンターの不具合に対処する驚きの方
Elixir/Phoenixで並行処理を使って大量のメッセージに対応するBOTサーバーを構築する方法を調査してみました。 - Qiita
Elixir/Phoenixで並行処理を使って大量のメッセージに対応するBOTサーバーを構築する方法を調査してみました。ElixirbotPhoenix Facebook Messenger PlatformやLINE BOTが話題になっていますが、下記の記事でも言及されているように、BOTサーバーとして大量メッセージに対応するには「並行処理」がキモになってきます。 大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ そしてElixirといえばやっぱり「並行処理」なわけです。ということで「BOTサーバーを効率よく開発するにはElixir/Phoenixってとても良い選択なのでは？」という仮定のもと、色々と検証してみました。 並行処理のコード Elixirでプロセスを起動・管理する方法はいくつも用意されていますが、BOTサーバーの要件的に「状態」を管理する必要はありませんし、
【乗るしかない】AWS LambdaとLINE BOT APIでRSSを通知する【このビッグウェーry】 | DevelopersIO
こんにちは、せーのです。今日は何かと話題のチャットBOTを使ってこのDevelopers.ioのお知らせBOTを作ってみたいと思います。新しもの好きなので。 チャットBOTの時代はくるのか？ さてここのところLINEより「LINE BOT API」が発表され、更にFacebookからもチャットツールである「Messenger」に対してプログラムで制御するためのプラットフォーム「Bots for Messenger」が発表されました。これにより巷では「チャットBOTの時代が来る」「ゴールドラッシュならぬ"ボットラッシュ"だ」なんて言われております。 ChatOps 開発者の間では数年前から開発に普段エンジニア同士の情報伝達のために使うチャットツール(Slack, Chatwork等)に一定のコマンドを打ち込むことによってコンパイル、ビルド、コミットやPush、CI等を行う「ChatOps」と
Reduxでコンポーネントを再利用する - Qiita
Reduxはとりあえず使えるようになった後の情報が少ないように感じています。よく出回っているサンプルコードは「Real World 〜」のような名前がついていたとしても、あくまで雰囲気を味わうために用意されたものに毛が生えた程度で、現実に起こる問題に対する回答や指針を示しているわけではありません。業務で使うことを検討するのであれば、プロダクトの成長と共にどうやってスケールしていくかイメージできないと導入に踏み切れないですよね。本稿ではサンプルコードより大きな規模で開発していくために、Reduxにおけるコンポーネントの再利用について紹介します。 実現したいこと コンポーネントの再利用によってどのようなことを実現したいのかイメージしてもらうため、馴染みのあるアプリケーションの機能を具体例として挙げてみます。 Gmailで名前にマウスオーバーしたときに出るプロフィール情報 プロフィール画像の表示
僕がAWSでLINE botを作るなら - Qiita
検討すべき事項 下記の記事がとても参考になります。 大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ これを踏まえて、AWSでどのようにサービスを構築するか考えてみました。 LINEからの通知をキューに突っ込む LINE -> API Gateway -> AWS Lambda -> SNS -> SQS すべてがマネージドサービスなので、安定かつ、スケーラブルにLINEからの通知を受け付けられるはずです。 下記の記事が参考になります。 AWS Lambda + API GatewayでLINE BOT APIを叩いてみた キューを処理する SQS -> Elastic Beanstalk Worker + NAT Gateway LINE側でアクセス元IPのホワイトリスト登録が必要なので、NAT Gatewayを噛ませます。（要試作） NAT Gatewayは月5000
大量メッセージが来ても安心なLINE BOTサーバのアーキテクチャ - Qiita
Help us understand the problem. What is going on with this article? 3月24日に発表になったLINEのBOT API Trial Accountが、いよいよ4月7日から実際に試せるようになりました。既に多くのBOTが開発者の手によって作られ始めたようですね。QiitaにもいくつかBOTの作り方が投稿されていますので、"LINE BOT"というキーワードで探してみてください。 実際の作り方の基本は他の投稿に任せるとして、BOT API自体は非常にシンプルな作りなので、試すこと自体はすぐにできると思います。しかし、シンプルな反面、仮に近い将来「Trial」が取れて、友だち50人制限が撤廃された時、それでも正しく安定的に動作するBOTとするには、アーキテクチャ上の工夫が必要になります。個人的に、既にLINE BusinessCo
ChromiumからElectronを眺める - Qiita
はじめに Electronいいわー ChromiumとかNode.jsの知見もあるといいらしい *1 でもChromiumとかようわからんぜ この際勉強しちまえばいいじゃん！ 本エントリはElectronを構成する要素の一つ、Chromiumのアーキテクチャについて初心者が入門してみたものです。 Chromiumドキュメントを読む Chromiumの仕組みを優しく解説した本やエントリはざっと探した限りはありません。 そういうのが必要な人がふれる領域の話ではないのでしょう。 必然的に英語で書かれたドキュメントを読むことになります。 Chromiumプロジェクトはリンクの樹海のようになっていて迷いそうです。 Developer向けドキュメントは以下のリンクを辿って行くとみつかります。 For Developers > Design Documents - Engineering design
Rails のアーキテクチャ設計を考える - Qiita
はじめに ここ一年くらいずっと Rails の何がダメでどうすれば良くなるのかを考えていました。 Rails を使ってそれなりの規模のアプリケーションを作ったことがある人なら、メンテナンスのしづらさを感じたことがあるのではないでしょうか。 メンテナンスの問題は Rails 以外の開発でも発生することですが、実のところメンテナンスしやすいアプリケーションはどうすれば作れるのでしょうか？ この難問に対して私も答えを持っていませんが、考え続けています。 少なくとも、 Rails Way や Rails Tutorial をベースにしたアプリケーション開発は、業務で用いるには簡単すぎるように思います。 「レールに乗る」という言葉がありますが、私は考え方を変えました。 Rails は規模の大きいフレームワークですが、土台に過ぎません。 Rails Way の設計方針は小規模な開発では有効ですが、規模
ソシオメディア | デザインエントロピーの抑制
この記事は、2015年7月に開催した UX戦略フォーラム 2015 Summer における私の同タイトルの講演をもとにしています。またこの内容は ÉKRITS への寄稿記事「エントロピーとデザイン」の続編ともなっています。 デザイン・エントロピー デザインのプロセスにおいては、よくこんなことが起こります。サービスの企画段階ではとてもよいコンセプトだったのに、設計や製造の工程を経るうちに、技術的制約、コスト的制約、時間的制約、互換性や保守的な要求への対応、その他の様々な要因により、デザインが妥協案や折衷案にまみれていく。サービスの価値を決定づけている根幹がスポイルされて、気がつけば平凡でつまらないものができあがっている… このように、せっかくのアイデアが次第に骨抜きになってしまうのは、デザイナーにとってとても残念なことですが、これはある意味仕方のないことなのです。なぜなら、このような現象は宇
セルフマネジメント・テクノロジー「Za」とは
〔最終更新日：2016年10月27日〕 Zaは「全従業員がプロフェッショナルな黒字社員」という強い企業を実現するためのセルフマネジメント・テクノロジーです。 組織内に「市場」の原理を導入し、従業員一人ひとりの損益を可視化し、自営業者のような自助的マインド、つまり個々人の「自営力」を喚起します。 そもそもZaが生まれたきっかけは、社員が次々に辞めてしまうというマネジメント上の危機でした。そのとき私は経営者として絶望的な気分で、「何が悪かったのか」「どうすればよかったのか」と自分を責めながら、マネジメントの本をたくさん読み漁っていました。そのとき、ふと思い出したのです。私は「人から管理されたくもなければ、人を管理したくもない」と思って自営業者になったのでした。 そして気付きました。私に必要なのは「経営者として組織をうまくマネジメントできるようになること」ではなく、「管理しなくても会社が回る仕組
10分で実装するFlux
10分で実装するFlux 自己紹介 azu @azu_re Web scratch, JSer.info Flux /flˈʌks/ Fluxとは Facebookが提唱したSmalltalk MVCの焼き直し CQRS(Command Query Responsibility Segregation)と類似 データが一方通行へ流れるようにするアーキテクチャ ウェブUIについてそれを適応する 今日の目的 小さなFluxの実装を作りながらFluxついて学ぶ Fluxの特徴: Unidirectional data flow 本当にデータが一方通行に流れるのかを確認する Fluxでよく見る図 登場人物 何か色々いる Action Creators, Dispatcher, Store, React Views... Dispatcher = EventEmitterと今回は考える もっと実装的
サーバレスアーキテクチャとは？ - プログラマでありたい
サーバレスアーキテクチャの整理です。少し前は、2-Tier Architecture（クラウドネイティブなアーキテクチャ）と3-Tier Architecture（従来のアーキテクチャ）という対比で論じられることが多かったです。しかし、API Gatewayの登場により、3-Tierな構造でもクラウドネイティブなアーキテクチャにしやすくなりました。ということで、サーバレスアーキテクチャ（ServerLess Architecture）と呼ばれることが多いです。 サーバレスアーキテクチャのパターン それでは、従来型のアーキテクチャ（旧3-Tier）と2-Tierパターン、API Gatewayを利用したサーバレスアーキテクチャをそれぞれ見てみましょう。 従来型のパターン（ アプリケーションサーバ・パターン） まずは従来型のアーキテクチャです。間にELBを挟んでAutoScaleにすることは多
よくわかる、なぜ「五輪とリエージュのロゴは似てない」と考えるデザイナーが多いのか？（深津貴之） - 個人 - Yahoo!ニュース
大きなトラブルとなった五輪のロゴ類似問題。素人目にはそっくりになロゴに対し、審査員をはじめ多くのデザイナー達が「まったく違う」と反論していたのが印象的でした。しかし、不透明かつ説明不足の審査委員会もあいまって、残念ながらこれらの発言は身内を守るものと解釈されてしまいました。また画像の盗用問題により、本来なら行われるべきだった、冷静な議論などは完全に失われてしまいました。 なぜデザイナーと世間において、これほど大きな認識の違いが生まれたのでしょうか？本稿では、デザイナーと世間の間にある「類似性のギャップ」に関しできる限りわかりやすく説明します。最大公約数的な意見としては、このような感じではないかと思います。 全体の構成としては、まず類似性は鑑賞者の文化背景に依存することを説明します。その上で、前提知識として、デザインの本質や、文字を用いたデザインの類似性についての基礎知識を解説します。その後
技術選択とアーキテクトの役割
特定のプロジェクトがあり、要件定義をし概要設計をする。 それがアーキテクトの仕事だと思われがちですが、大きな視点を持ち様々な課題を自らリードして解決していく立場としても絶好のポジションです。 このセッションでは、Mobage オープンプラットフォームの立ち上げから、 グローバルプラットフォーム展開、さらには mixi 社との共同プラットフォーム構築、 JavaScript SDK と認証技術の組み合わせによる新しい HTML5 プラットフォーム構築をアーキテクトという立場でリードし続けた立場から、技術選択のみならず実現したい事に対する俯瞰的な捉え方を、これまでの実例と共に紹介し、アーキテクトという役割について、お話します。Read less
大学のレポート提出で一工夫したらコピペが皆無になったという話
レポートを「特許同様に先願制とする。つまり意図せずとも類似内容だった場合後に提出された方を減点する」と呪文を唱えたら、コピペが皆無となった上に〆切よりだいぶ早く集まった — Masahiko Inami (@drinami) 2009, 12月 22 当方が学生時代もレポートの類や試験の筆記問題などは(持ち込みがOKな場合も多々あるので)、OBなどが持つ過去問を頼りにそのまま写したり、ほぼトレースする所業が多数行われていた。中には歴代の先輩たちが使いまわしする、伝説のレポートなんてのもあり、高値で取引されたってのも記憶にある。何度となくコピーされたせいで、文字が随分かすれていたり、ね。まぁ、問題を出す教授側も新しい問題の設定が面倒くさいのか、毎年同じものしか出さないのも一因なんだけど。 今ではインターネットが普及しているので大学生界隈では情報の共有ももっとスマートになってるんだろうけど、同
学生に考えさせる授業
矛盾の止揚の教育（福耳さん） 学生に、Ａという仮説を教える。そして然る後に、Ａと矛盾する仮説Ｂを提示する。そして教えるこちらからはＡＢ間の矛盾は解決しない。学生自身に矛盾について悩ませる。 その結果、そうとうちゃんと考えてこそ、ＡＢそれぞれをふまえて、両者を止揚した仮説Ｃに学生自身の手でたどりつく。それをしてこそ、本当に自分の頭で考えて、自分の頭の中にその成果が残り、洞察力という力の存在を認識できる。 そういう講義をせんとあかん、と思ったのは、いまの学生、「決まった正解を教わるのが大学の講義」と勘違いしているからである。あーこどもっぽくっていや。そんなの、チャート式でも読んどいてくれ。 僕なんぞは、考え方ではなくって、他人が勝手に決めた正解を学んで、なにが面白いのかなんて思いますがねえ。 なかなかうまくいかないというか、結局のところ、学生が演技力を駆使するだけの結果となりそう。 というのは
大野左紀子さんをコピペレポート問題から解放する（かもしれない）授業案
レポートコピペ問題の問題（大野左紀子さん） しかしいろいろ参照したとしても、最終的には「自分で考えて意見をまとめる」という基本的なことが教育できない、その重要性すら叩き込めないとしたら、単に教育者や教育システムの問題だけなのだろうか？という疑問は湧く。それは、「自分で考えて意見をまとめる」ことが本当に大切なことだとは、世間では思われていないということの現れではないか。 自分で考えることが大切なのではなく、そこはショートカットして自分で考えたかのように振る舞えることが（処世術として）大切、というふうになっているのではないか。それどころか、もしそれが他人の意見だとしても、少なくとも自分よりは頭が良さそうな人の意見に右に倣えで、何が悪いのかと。世の中そんなものではないかと。自分の意見なんかいったいどこで求められるんだ‥‥。 いやいや、堂々と「学生に『考えさせる』なんてくだらない」といっている（下
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/19
Payforward
