Python for Finance Tutorial: Algorithmic Trading
This Python for Finance tutorial introduces you to algorithmic trading, and much more. Technology has become an asset in finance: financial institutions are now evolving to technology companies rather than only staying occupied with just the financial aspect: besides the fact that technology brings about innovation the speeds and can help to gain a competitive advantage, the rate and frequency of
On the Unhappiness of Software Developers
The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Ps
モブプロをやってみた。良さ。使いどころ。 #devkan - Mitsuyuki.Shiiba
devlove-kansai.doorkeeper.jp モブプログラミングやってきました！面白かったー。疲れたー。面白かったー。 モブプログラミングって？ チーム全員(プロダクトオーナー含む)が集まって、1人だけがコードを書いて、それがスクリーンに映しだされてて、その他の人みんなでやいやい言いながらものを作っていく。というスタイル。ルールは「ドライバー(コードを書いてる人)は、ナビゲーター(周りでやいやい言ってる人)に言われた通りにコードを書く。ドライバーが自分で考えてコードを書くのはダメ。」という感じ。 やってみた 7人ぐらいのチームで、プロダクトオーナーからのお題に対してTDDで実装をやってみた。2部制でやったのだけど、第1部はKotlin + IntelliJ IDEAでローマ数字の計算を。Kotlin全く知らないし、IntelliJも全然慣れてない。第2部はJavaで自動販売機を
UI研究者 増井俊之が語るエンジニアに伝えたいこと | 三年予測 ｜dodaエンジニア IT
UI研究者 増井俊之 1959年生まれ。54歳。慶應義塾大学環境情報学部教授。東京大学大学院修士課程卒業後、富士通、シャープ、ソニーコンピュータサイエンス研究所、産業技術総合研究所を経て、2006年から2008年まで米AppleでiPhoneの日本語入力方式の開発に従事。2008年より慶應義塾大学。 慶應義塾大学SFC（湘南藤沢キャンパス）にある増井俊之の研究室は、混沌とした楽しさが感じられる場だった。まず、ドアの開閉の方法からして違う。「NFC対応のスマートフォンをかざして回す」操作で解錠する仕組みが作り込まれている。ドア解錠の機構から伸びるケーブルの先には、ガジェット作りでは定番のマイコンボード「Arduino」がある。ユーザインタフェース研究者である増井の研究成果をドア解錠の機構に組み込んでいるのだ。 研究室の入り口には、研究室メンバーが「ニコニコ学会」で大賞を獲得したときの副賞のだ
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
「Googleスプレッドシート」、AIでグラフ作成が簡単に--自然言語を理解
スプレッドシートに詳しい人なら、「=AVERAGE(Sheet1!C2:C933)」のようなコマンドもごく簡単に書けるだろう。そうでない人にとって、表計算アプリ「Googleスプレッドシート」に人工知能（AI）が組み込まれるということは、「What are the average sales for Sunday?（日曜日の平均売上高は？）」と聞くだけで済むようになる、ということだ。 Googleが米国時間6月1日に発表したAIに関するアップデートは、平易な言い回しによるコマンドを理解できるようにしようとする取り組みにおいて、Googleスプレッドシートが出した最高の成果だ。さらに例を挙げれば、「What is the distribution of products sold?（販売された製品の分布は？）」「Histogram of 2017 customer ratings（2017年
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Engage Visitors & Customers | PushCrew (now VWO Engage)
