テストがうまくいかないプロジェクトに捧ぐ、正しいテストの考え方 - Qiita
この記事の対象者 プロジェクトでテストを書いている。(書いたことある) テストが重要らしい事は知っているが、テストの恩恵をそこまで実感できていない。 結局手動テストに依存したバグフィックスをしている。 はじめに 私はテストの設計手法、実装に関する知識は多く持っていましたが、知らなかったことはテストの考え方でした。 テストが重要らしいことを知っている人は多いと思います。 しかし、実際に恩恵を実感できていない人もいると思います。 事実、 テストが重要だと発信している人 と、 テストが重要らしいことを知っている人がいます。 後者の人は、とりあえずテストを書く事ができます。しかし、テストに時間を割く割りに、最終的には手動テストでバグを発見することに依存している事も多いかなと感じます。 世間ではテスト書くのが当たり前、テストは重要！という風潮であるのに、何故テストが重要であると実感できないのでしょう
FXや株の自動取引ツールの作り方 - Ａ級リーグ指し手１号
私はFXやら株やらの投資に多少手を染めているのですが、一時期その自動取引をするツールを自作したことがあります。先日やはり自動取引に興味のある方とその話をしていたのですが、自動取引のやり方というのはどうもあまり知られていないようです。Web製作サイドでは割と一般的な技術を使っているだけ（だと思う）で、そんな大したことをやってるわけではないのですが、その業界以外ではたしかにあまり知られていない技術かもしれないので、参考にされる方もいるかもしれないと思い、ご紹介しておきます。 世の中にはFXや株の自動取引ツールというものがいくつか出回っています。FXだとMetaTraderというのが有名です。ただ、どのツールも大体、為替なり株価なりの時系列情報だけを用いた単純なテクニカル分析を対象としており、いろんな情報源を利用してある程度複雑なロジックを実現することは（私の知る限り）できないはずです。そのよう
Naming -名前付け- - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Naming -名前付け- プログラミングで最も重要な技術の一つが、名前付けです。 且つ、センスが問われるものなので、上達は難しいものでもあります。 この記事では、様々な文献から抽出した名前付けに関する情報を雑多にまとめました。 -名前重要- ソフトウェアの設計のアプローチとして、『まず名前から入る』というのは、あまり語られていない秘訣としてもっと広く知られても良いように思います。 まつもとゆきひろ 『プログラマが知るべき９７のこと』 コミュニケーションの基礎 名前は、コミュニケーションの基礎となるものです。 私にもあなたにも名前が無け
クラウドベースのアルゴリズムトレーディングサービス"Quantopian"を試してみる - Qiita
この記事について Pythonでファイナンス関係の情報を探していたところ見つけた"Quantopian"が面白そうだったので試してみます。 Quantopian Quantopianとは クラウドベースのアルゴリズムトレーディングプラットフォームです。ユーザはブラウザで専用のIDE(開発環境)を使ってPythonライクなコードでトレーディングアルゴリズムを作成し、バックテストを行うことができます。Interactive Brokers証券に口座がある場合は、接続してリアルトレードを行うこともできるようです。 何がトレードできる？ 2002年以降の米国株/ETFのデータを分足ベースで保持しているようです。 はじめよう アカウント登録 サイトにアクセスします。真っ赤です。右上のSign Upからメールアドレスで登録します。 ログイン直後 上部にメニューが並んでいます。 Capital -> L
「リアクティブプログラミングが読み難い」というのは本当なのか? - Qiita
追記(2017/05/2) redux-sagaでの非同期バージョンの紹介とリンクを追記。 追記(2017/2/23修正) 元記事の追記3にて言及を頂いたように、以下の「見易い版」コードは元コードが実現していた機能が抜けおちているという誤りがあります。遅くなりましたが、お詫びの上修正させていただきます。 修正内容は以下の「refreshボタン押下ですべての候補を消去」の項目に追記しました。 上記追記の趣旨として、リアクティブプログラミングはそれほど判り難いのだ、というご指摘になっていますが、返す言葉もございません。 はじめに 先日「リアクティブプログラミングとは何だったか」という記事を目にしまして、内容はたいへん興味深かったのですが、以下の記述がありました。 『宣言的』といえそうなのはわかりますし、パラダイムとして従来のコードとは一線を画すものであることは確かですが、どう贔屓目にみてもひた
「var禁止」禁止
2016/02/20 Hokuriku Comm CampのLTで発表した際のプレゼンテーションスライドです。
ソースコードに技術者のレベルが現れる：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
新規に書かれたソースコードを見ると、それを書いた技術者のレベルがある程度分かります。特に、レベルが低いエンジニアが書いたコードほど、よく分かります。レベルが低いというのは、全くの初心者という意味ではありません。社会人となってソフトウェア開発に従事して数年を経過して、本人はプログラミングできると思って書いているレベルであっても、書かれたコードを見ると、レベルが低いということです。 レベルが低い大きな理由の1つは、自分が書いたコードをスキルが高い人にレビューしてもらうという習慣を本人が持たないし、組織も持たないからです。もう1つの大きな理由は、使用しているシステムや開発言語に関した、きちんとした学習をしていないということも挙げられます。※ ※ たとえば、Java言語で開発していても『Effective Java』を読んだことさえないとか。 「初心者だからと言って汚いコードを書くことが許される訳
Yahoo! JAPAN Tech Blogの「分散プログラミングモデルおよびデザインパターンの考察」の記事は何が間違っているのでしょうか？
間違っているというより、全体的に用語の使い方があいまいで意味がよくわからない箇所が多いと思いました。ですから具体的にどこが間違っているという指摘はしづらいのですが、明らかにおかしなことが書かれている箇所があります。 厳密には、クラウド環境を構成するサーバーは、マルチプロセッサーやマルチコアは内部的にもMIMDですし、最近のプロセッサやGPUなどの拡張ボードでも何かしらのSIMDに対応しています。そのため、厳密な分類では、現状のクラウド環境はMIMDおよびSIMDのハイブリッドなアーキテクチャですが、今回の記事の流れから、SIMD動向については割愛してMIMDを中心に話を進めています。 ↓前半はクラウドを構成するサーバーのハードウェアのアーキテクチャの話です。 厳密には、クラウド環境を構成するサーバーは、マルチプロセッサーやマルチコアは内部的にもMIMDですし、最近のプロセッサやGPUなどの
2016年、C言語はどう書くべきか (後編) | POSTD
(前編はこちら： 2016年、C言語はどう書くべきか (前編) ) (編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) システム依存の型 まだ「32 bitのプラットフォームでは32 bitのlong型、64 bitのプラットフォームでは64 bitのlong型がいい」という不満があるようですね。 プラットフォームに依存する2つの異なるサイズを使うため、 故意に コードを難しくすることを考えたくなければ、システム依存の型のために long を使おうとは思わないでしょう。 この状況では、プラットフォームのためにポインタ値を保持する整数型、 intptr_t を使うべきです。 モダン32-bitプラットフォームでは、 intptr_t は int32_t です。 モダン64-bitプラットフォームでは、 intptr_t は int64_t です。 int
5 年続く 「はてなブックマーク」 アプリを継続開発する技術
Androidのセキュア開発について考えてみた(明日、敗訴しないためのセキュアコーディング.ver2)
分散プログラミングモデルおよびデザインパターン - kuenishi's blog
同名の某記事について。僕がタイトルから想像する期待を、なんだか意外な方向に裏切ってくれた記事であった。批判するだけではよくないので、同じタイトルで僕ならどういう話になるか…という話をしよう。絵のない長文だ覚悟して読め(ΦωΦ)ﾌﾌﾌ…。 分散プログラミングモデル プログラミングモデルとはなんであろうか。 …CもJavaもMPIも登場していない1972年の論文を持ってこられてそれがオリジナルだみたいなこと言われてもえー…って感じで、Flynnの1972年の論文は並列計算やHPCの方面へ非常に大きな影響を与えていると思う。ただしそれはCPU内の話であって、時代が進むと共にたとえば牧野先生の日記「並列計算機のプログラミングモデル」で書かれているような議論につながるといえば繋がるには繋がるが、このレベルで計算を並列化する議論にしか応用できない。せいぜい、プログラミングモデルとひとくちにいっても様々
『組織にテストを書く文化を根付かせる戦略と戦術』を聞いて #jopf - miyohide's blog
はじめに 先日開催された『開発を活性化するためのポイントとテストに関する勉強会』にて、『組織にテストを書く文化を根付かせる戦略と戦術』のお話を聞いてきたので、そこでの内容と自分が所属している組織への適用について記してみます。 各種資料 発表資料 組織にテストを書く文化を根付かせる戦略と戦術 from Takuto Wada Togetter togetter.com 感想 衝撃的だったのは、「テストを書く文化の醸成には2年ぐらいかかる」という言葉。 t_wada「文化の醸成は年単位の事業になる。だいたい2年ぐらいかかる。」 #jopf— みよひで。オシャレ男子になりたい (@miyohide) 2016, 2月 16 一日二日でできるとは思っていないんですが、まさか年単位とは。 そのため、勢いで乗りきれるほど甘くはなく、戦略と戦術でもってテストを書く文化を醸成しましょうという話に続きます。
続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシが食えるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、
Python: concurrent.futures を使った並行・並列処理 - CUBE SUGAR CONTAINER
Python の concurrent.futures はバージョン 3.2 で追加された並行・並列処理用のパッケージ。 似たようなパッケージにはこれまでにも threading や multiprocessing があったんだけど、これはそれよりも高レベルの API になっている。 デフォルトでスレッド・プロセスプールが使えたり、マルチスレッドとマルチプロセスがほとんどコードを変えずに使い分けられるメリットがある。 下準備 使う Python のバージョンが 3.2 未満のときは PyPI にあるバックポート版のパッケージをインストールする必要がある。 $ pip install futures ただし、今回使う環境は Python 3.5 なので関係ない。 $ python --version Python 3.5.1 $ sw_vers ProductName: Mac OS X P
Railsの基本理念 : Railsの生みの親が掲げる8つの原則 | POSTD
(訳注: 2016/3/2、頂いたフィードバックをもとに記事を修正いたしました。) Ruby on Railsは最近、急激に注目を集めていますが、その原因はほとんど、この言語が斬新なテクノロジーとしてもてはやされたことと、タイミングにあります。技術的な優位性は時間の経過とともに失われますから、タイミングがよかっただけでは、一過性のブームに終わり、このムーブメントの隆盛は長続きしません。従って、「Railsがいかにして、適切な技術としての位置を維持し続けるるだけでなく、影響力とコミュニティを拡大し続けてきたのか」をより多くの人に説明していく必要があります。そして、その維持・拡大を可能にした/していく要因は、物議を醸すことさえあるRailsの基本原則にあると考えています。 この基本原則はここ10年ほどの間に進化を続けてきましたが、最も強固な柱となっているルールはやはり、公開当初から制定されてい
分散プログラミングモデルおよびデザインパターンの考察
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 写真：アフロ データ＆サイエンスソリューション統括本部、データインフラ本部、今野です。 早速ですが、今月開催の「Developers Summit 2016 （以下、デブサミ2016）」で当方が登壇する運びとなりました。気がつけば、前回の記事「分散システム処理モデルに関する動向について」から随分と日がたってしまいましたので、今回は、より広範囲な内容を整理してみたいと思います。 デブサミ2016の当方の講演テーマは「温故知新」です。今回は、このテーマにもつながる話題として、クラウド環境の代表的な分散プログラミングモデルやデザインパターンについて、一般的な考察をしてみたいと思います。 古典的なプログラミングモデルによる分類 まず最初に
GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟
Githubで海外のエンジニアさんをフォローしているのですが、あるエンジニアさんがtilというリポジトリをstarしていました。 github.com 「なんか新しいツールか何かかな？」と思ったのですが、覗いてみたらdescriptionに"Today I learned"の文字が。 どうもtilというリポジトリを作成してそこに"今日覚えたこと"を書いていくのがプチ流行している様子。 ・ 色んなTILが 今までだと同じような感じでベストプラクティス等をまとめた"◯◯-awesome"が流行ってましたが、 自分が何を学んでいっているのか自分も他人にも知ってもらうためにこういうリポジトリを作って書いていくのも面白そうですね。 関連したWebサービスとかが作成されたらそれはそれでまた面白いのかも。
TensorFlowを遊び倒す！ 〜目次〜 - Platinum Data Blog by BrainPad
※TensorFlowとは2015年11月9日にオープンソース化されたGoogleの機械学習ライブラリです。 本ブログでは、実際のTensorFlowの使い方を連載方式でご紹介しています。 皆様こんにちは。 テクノロジー＆ソフトウェア開発本部の佐藤貴海です。 本日から「TensorFlowを遊び倒す！」と銘打って、Googleが2015年11月9日に公開した“機械知能(?)ライブラリ”のTensorFlowを入門編＆応用編にわけて、使い方をご紹介していこうと思います。 www.youtube.com http://www.tensorflow.org/ TensorFlowを何と呼ぶかは微妙なところです。機械学習ライブラリと言っているところもありますが、Getting Startedで「Hello, TensorFlow!」とやっているので、もう少し大きい概念のライブラリのようです。 とり
gccを用いたCの共有ライブラリの作り方 - シリコンの谷のゾンビ
ゆとりなもので，ついこないだまで動的リンクと静的リンクの違いがわかっていなかった．動的リンクというのが理解できた頃，そっかユーティリティライブラリは自分で共有ライブラリ作ってしまえばいいんだ，というごく当たり前のことが理解できた． UNIXをさわりはじめていた初期の頃，mecab.soのシンボリックが〜〜という用なハマりがあったのだけれど，あれは要するに実行時に共有ファイルへのパスを指定してあげればよかっただけのこと． わかると当たり前だけれど，わからないと「何がわからないのかわからない」状態に落ち込むなぁ，と改めて思いました． （幸いなことに，僕の周りには「ゆとり乙ｗｗ」と指導してくれる方々がいるので認識できるようになるのですが，少なくとも大学（院）時代はそうでなかったわけで，ゆとりスパイラルの恐ろしさを体感した気がしています．） というわけで自分用共有ライブラリの作り方をきちんと理解で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT業界・エンジニアの転職ならTech Stars Agent
