並び順

ブックマーク数

期間指定

  • から
  • まで

281 - 320 件 / 458件

新着順 人気順

UnitTestの検索結果281 - 320 件 / 458件

  • 【速報】JUnit5 はこうなる!?【プロトタイプ】 | DevelopersIO

    渡辺です。 DevelopersIOでの100本目のエントリーがJUnitネタとなりました。 自分がJUnit実践入門を執筆したのは2011年から2012年にかけてです(出版が2012年11月)。 それからJava8がリリースされていますが、JUnit4自体は大きな進化はしていませんでした。 昨日、JUnit Lambda Prototypeが公開されました。 まだプロトタイプということで、今後の変更は大きいかと思いますが、いよいよ次世代のJUnitの足音が聞こえてきた感じがします。 今回は、このドキュメントからJUnit Lambdaの概要と方針について速報をお送りしたいと思います。 なお、現在JUnitチームでは、このプロトタイプに対するフィードバックを募集しています。 ここはこうじゃないとかはてブコメントする前にTwitterやGitHubでフィードバックを! JUnit Lambd

      【速報】JUnit5 はこうなる!?【プロトタイプ】 | DevelopersIO
    • テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ

      テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ キーマンズネットは、IT担当者を対象にしたアンケート結果として「テスト自動化ツールの導入状況」を公開しました。 それによると、導入済みは全体の8.5%(「既に導入済みである(追加リプレイスなし)」7.5%と「既に導入済みである(追加リプレイスあり)」の1.0%の合計)で、導入を検討しているが4.8%。今後も導入しないするグループは86.7%(「必要性を感じているが導入を検討していない」の38.6%と、「必要性を感じない」の48.1%の合計)」になりました。 グラフを見ると従業員規模1001名以上では導入済みが約15%である一方、100名以下では1.8%であり、従業員規模によって大きな違いがあることが分かります。 対象言語はJavaがトップ、目的は品質の向上、工数削減など すでにテスト

        テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じないと。キ-マンズネット調べ
      • Jasmine: Javascript Testing Framework

        describe("Jasmine", function() { it("makes testing JavaScript awesome!", function() { expect(yourCode).toBeLotsBetter(); }); }); Documentation User Guide Release Notes API Documentation Contributor Guide Download For pure JavaScript projects: VersionSizeDateSHA1

        • Redirecting

          Redirecting to docs/en/latest...

          • Yaneu Labs --- コンピュータ将棋プログラムをLISPで書く

            *[hatefu:labs.yaneu.com/20090905/] コンピュータ将棋プログラムをLISPで書く 「コンピュータ将棋プログラムをLISPで書く」と言うとコンピュータ将棋開発関係者にすら完全にネタかと思われているのが実状ではあるが、私はこれを機にその誤解を解いておきたい。 ここでは、私がC#で書いたLISPエンジンのソースを公開し、これが実際にコンピュータ将棋プログラムの開発において非常に有効であることを示す。 * YaneLisp version 1.10 今回の記事はあまりに長文なので最後まで読む前に眠くなる人のために、まず始めに私が実装したLISPのバイナリとソースを配布しておく。ライセンスはNYSLとする。 勢いに任せて実装したので、かなり雑な作りだが、必要ならばC#側で関数を追加するなりすればいいと思う。このLISPの製作に要した時間は丸2日ぐらい。 # YaneL

            • 「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found

              2008年03月27日03:00 カテゴリArtLightweight Languages 「同じコード」の同じって何さ - TAPのススメ 問題は、この「同じコード」の定義。 「誰が書いても同じコード」は大事なことなのか - ひがやすを blog でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。同じ「書き方」をしなければならないのか? 結果が「同じ」ならいいのか? もし後者だとしたら、実は 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 すら必

                「同じコード」の同じって何さ - TAPのススメ : 404 Blog Not Found
              • Objective-C Programming Guide for Open Source Software

                2014/02/01 @ GREE

                  Objective-C Programming Guide for Open Source Software
                • テスト駆動開発(TDD)はもう終わっているのか? Part 2 | POSTD

                  前編はこちらです 4:テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が

                    テスト駆動開発(TDD)はもう終わっているのか? Part 2 | POSTD
                  • Java EE6で単体テストや結合テストを自動化する方法について - 達人プログラマーを目指して

                    今週水曜日に、オラクル青山センターで行われたGlassfish Japanユーザーグループの勉強会でJava EE6のお話をさせていただきました。勉強会のスライドとビデオは以下のリンク先にあります。 Glassfish勉強会(JavaEE6について) View more presentations from Ryo Asai http://www.ustream.tv/recorded/16552906 今回は基本的に私がこのブログで書いてきたJava EE6関連の情報について紹介させていただきました。欲張って少し内容を詰め込み過ぎたところがあったかもしれませんが、Java EE6を使った単体試験や結合試験の自動化については、説明をスキップしてしまい、ちょっとわかりにくくなってしまいました。ここで、あらためてJava EE6上のアプリケーションのテスト自動化について簡単に補足させていただき

                      Java EE6で単体テストや結合テストを自動化する方法について - 達人プログラマーを目指して
                    • 使えるRSpec入門・その3「ゼロからわかるモック(mock)を使ったテストの書き方」 - Qiita

                      はじめに みなさんこんにちは! この記事は「必要最小限の努力で最大限実戦で使える知識を提供するRSpec入門記事」、略して「使えるRSpec入門」の第3回です。 今回はRSpecのモックを使ったテストについて説明します。 これまでモックを全く使ったことがない人でもわかるように丁寧に説明していくつもりです。 また、これまでの回と同様、個人的に使用頻度が低いと思っている内容についてはバッサリ説明を省きます。 ただし、第1回や第2回に比べるとテストコードが少し複雑になって、仕組みや動きを想像するのがちょっと難しいかもしれません。 ぱっと頭に入ってこない場合はじっくり本文を読んだり、実際に自分で写経しながらコードを動かしたりするなどして、少し時間をかけながら理解するようにしてください。 今回は以下のような内容を説明します。 モックの基本的な使い方 モックを使った検証 モックでわざとエラーを発生させ

                        使えるRSpec入門・その3「ゼロからわかるモック(mock)を使ったテストの書き方」 - Qiita
                      • "Excelenium"(エクセレニウム)で,快適な自動回帰テストを  (Seleniumのテストスクリプトとテスト仕様書を自動生成) - 主に言語とシステム開発に関して

                        テスト仕様を書くだけで,仕様書自身がテストを自動でやってくれる。 それがExcelenium(エクセレニウム)。 Excelenium = Excel + Selenium 左側で,操作のステップを日本語で書くと, 右側で,テスト仕様書風のフォーマットの文章をリアルタイムで自動生成してくれる。 ※画像中で「確認」と書いてあるのは,チェックポイントの部分。これは自動的にオレンジ色のセルになる。 書く必要があるのは,青い線より左側だけ。 そして, 「この仕様書の全テストを実行」 というボタンを押すと・・・ Seleniumのテストケースが自動生成され, ブラウザが立ち上がり, テスト仕様書に書いてあった全テストが実行される。 (※ついでに,シート上の全テストケースに自動で番号が振られる。) Webアプリケーションの結合テスト / 回帰テストが大幅に楽になる。 従来のような「テスト仕様書」と称し

                          "Excelenium"(エクセレニウム)で,快適な自動回帰テストを  (Seleniumのテストスクリプトとテスト仕様書を自動生成) - 主に言語とシステム開発に関して
                        • net/httpで作るGo APIサーバー #1

                          GoにはWebサービスを作るためのフレームワークがそれなりの数存在している。 Awesome Go - Web Frameworks ただ、そこまでデファクトというものがあるわけではなく、他の言語と比べると少々乱立気味なのではないかな、という感想を持っている。この記事ではnet/httpを主軸に据え、取替可能な部品となるライブラリを利用してAPIサーバーを作成する方法を紹介する。 長くなりそうなので記事を分けて紹介する予定だけど、今日はアプリケーショングローバルな値をどのように保持するのが良いのかについて書く。 アプリケーショングローバルな値 APIサーバーにはそのアプリケーションにおいてグローバルな値を保持しておきたいケースが多い。例えばAPIサーバーの設定情報だったり、外部APIにアクセスするクライアントだったり、DBへのコネクションだったり、loggerだったり。そういったものを初期

                          • 特集:PHPUnit3で始めるユニットテスト|gihyo.jp

                            運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

                              特集:PHPUnit3で始めるユニットテスト|gihyo.jp
                            • SeleniumでJavaScriptを使う方法いろいろ(変数・関数などの利用) | colori

                              Selenium(Selenium Core, Selenium IDE, Selenium RC など)でテストケースを書く場合、かゆいところに手を届かせたい時に是非とも利用したいのがJavaScriptです。 しかし、まだまだその情報が気軽に手に入らないのが残念なところ。 「ないなら書いてしまえ!」ということでSeleniumでJavaScriptを利用したい場合に使える方法をまとめてみることにしました。 逆引き辞典にしたいのかリファレンスにしたいのかわけがわからんカテゴライズになっていますが、少しづつ増やしていくので気長にお待ちください。 使用バージョンはSelenium 1.0です。 目次 JavaScript基本編 Selenium空間とページ空間の違いによるJavaScriptの使い分け JavaScriptによるDOM指定でエレメント(要素)を特定する 各種コマンドの入力欄に

                              • 入門Chef Solo落ち穂拾い

                                Provisioning Frameworks Casual Talks vol.1 (https://gist.github.com/studio3104/5417631) での発表スライドです

                                  入門Chef Solo落ち穂拾い
                                • XcodeでBotを設定する - Toyship.org

                                  Xcode5の新しい機能として、 Botという継続的インテグレーションツールが導入されました。 アプリ開発時に、ソースコードを書く以外の部分を担当してくれる、たよりになるツールです。 自動的にビルド・テスト・リリースまでしてくれるので、ちょっと楽に開発を進められるようになるかもしれません。 継続的インテグレーションツール(CIツール)としてはJenkinsが広く使われていますが、BotにはJenkinsとほぼ同様の機能があり、さらにiOS/Macアプリに特化した機能が追加されています。 今Jenkinsを使っている人も一回試してみてはいかがでしょうか。 なお、詳しい公式資料はこちらです。 Xcode Continuous Integration Guide Botの主な機能 Botには、主にこんな機能があります。 自動ビルド インテグレーション詳細情報の表示 BigScreenによるコクピ

                                    XcodeでBotを設定する - Toyship.org
                                  • XP Epsiode

                                    Chose Vacation RentalsTips for renting your Vacation Rentals Whether you are a tenant or a landlord, here are some practical tips to help you prepare your vacation. Booking a vacation rental The reservation of your holiday rental is made directly with the landlord. It is recommended to confirm your reservation by sending a rental contract and a deposit or deposit. The balance of the stay will be p

                                    • Bashアプリケーションをテストする | POSTD

                                      以前、bashスクリプトをテストする仕事に取り組んだことがあります。最初、Pythonユニットテストを使うことにしましたが、プロジェクトに外部技術を持ち込むのは気が進みませんでした。そこで、仕方なく、悪名高い bash で書かれたテスト用フレームワークを使いました。 既存ソリューションの概要 手に入るソリューションを探してGoogle検索しましたが、選択肢はほんの少ししかありませんでした。そのうちいくつかについて、詳しく見ていきましょう。 重要になるのは、どんな基準でしょうか? 依存関係: bass のテスト用フレームワークを選ぶときに、 python 、 lua などのシステムパッケージも一緒に引きずり込むのは嫌ですね。 インストールの難しさ:継続的な開発の実装とTravis CIでの継続的な統合も仕事の1つだったので、私にとってインストールにかかる時間と手間数が妥当だということは、重要

                                        Bashアプリケーションをテストする | POSTD
                                      • ブラックボックステストとホワイトボックステスト | DevelopersIO

                                        テスト分類のひとつにブラックボックステストとホワイトボックステストがあります。 ブラックボックステストとは、テスト対象の内部を意識せずに外部仕様のみからテストケースを構築していく手法です。ユニットテストであれば、テスト対象となるメソッドの実装(コード)を意識せず、メソッドのAPI仕様からテストケースを作成することになります。 一方、ホワイトボックステストでは、テスト対象の内部を意識し、どのような構造であるかを踏まえたテストケースを構築します。ユニットテストであれば、テスト対象となるメソッドの実装(コード)を意識し、分岐や繰り返しなどを考慮しつつテストケースを作成することになります。 さて、ユニットテストはブラックテストでしょうか? それともブラックボックステストでしょうか? 「JUnit実践入門」では次のように記述しました。 本書で扱うユニットテストは、テスト対象の内部ロジックを考慮して行

                                          ブラックボックステストとホワイトボックステスト | DevelopersIO
                                        • はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(後編)。CROSS 2014

                                          Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日都内で開催されました。「現場に聞く!テスト/CI/DevOps、実際のところどうなの」というセッションでは、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇しています。 セッションの前半では、テストの重要性やテストをどのくらい書くべきなのか、といった議論が行われましたが、後半ではどうすれば組織としてCIやテストに取り組めるのか。そして組織内での情報共有などについての意見が交わされました。 (本記事は「はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(前編)。CROSS 2014」

                                            はてなやクックパッドの開発現場で、CIやテストはどう行われているのか?(後編)。CROSS 2014
                                          • Shibu's Diary: コードを書くときに心がけていること

                                            渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 コードを書き続けるためにやってること(by Voluntas) なんか流行っているので乗ってみます。 趣味コード 趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に

                                            • Androidでレガシーコードを書き続けないためのたった1つの方法 - ブログなんだよもん

                                              答え:テストできるように作る 周りでAndroid開発してる話を聞くのですが、どうもテストがしづらかったり、修正が大変だったりする模様。ここを直してあそこがバグるみたいな。 本屋で参考になりそうな本を探すも、入門系かリファレンス系が殆どで、「どういう設計にするべきか?」とか「Android Test」とかAndroid向けフレームワークの話がさっぱり無い。そんな状況なので、入門書片手にアプリを書き始めた人は、ViewとLogicを始め、色々なものが適切に分けられてないコードを作り、テストの無いレガシーコードが量産されていくのかな、と。 そういう分けで最初の結論になります。 ちょうど、ちょっとしたAndroidアプリを書いてみようと思ってたので、ここら辺を参考に実際のアプリに先立っていくつかのフレームワークを組み合わせたAndroid-Development-Suiteを作成。 いわゆるサン

                                                Androidでレガシーコードを書き続けないためのたった1つの方法 - ブログなんだよもん
                                              • テストの自動化を考える前に

                                                5. 前職で実際にあった出来事 マネージャ 今回はテストファーストでやります ぐるぐる はい! マネージャ なので、実装に入る前に テスト仕様書を完成させます ぐるぐる はい? マネージャ テスト仕様書は実装開始までに Fix され、以降の変更は認めません ぐるぐる はいぃぃぃぃ?

                                                  テストの自動化を考える前に
                                                • ActiveRecordを試すときに便利なやつ - r7kamura - Medium

                                                  手元で ActiveRecord を試したいときに、いちいちデータベースを用意したり、再現性のあるコード片に整えたりするのは、結構な手間に感じてしまうかもしれません。この記事では、そういったケースで利用できる知識を幾つかまとめておこうと思います。 以下は今回題材に使うコード例で、これを上から順に説明していきます。 ActiveRecord で .count の挙動を試す例bundler/inlinebundler/inline は Bundler 1.10 から追加された機能です。これを利用すると、Gemfile を独立したファイルとして用意することなく、スクリプトの中にその定義を埋め込めるようになります。 続くスクリプトがどのバージョンの Gem で動かせるのかということを明示でき、必要であればライブラリを実行時に自動的にインストールし、依存関係を調べて $LOAD_PATH を調整し、

                                                  • 「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog

                                                    rspec-2.11 がリリースされましたね。いくつかの変更点の中に、今後は should ではなく expect を推奨し、デフォルトでは expect のみが有効化されるようになる、というものがありました。 http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax 個人的にこの変更は説得力に欠けるなーと思っていて、 expect 推しにする理由が should は Kernel にはえるので Kernel を include しない BasicObject のインスタンスに対して should を呼ぶとおかしくなる 標準ライブラリ delegate は Kernel のメソッドの一部だけを include するので rspec と delegate のどちらが先にロードされるかによって should の挙動

                                                      「RSpec は英語として読みやすいから良い」というお題目はなんだったのか - @kyanny's blog
                                                    • RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明

                                                      🖥 VULTRおすすめ 「VULTR」はVPSサーバのサービスです。日本にリージョンがあり、最安は512MBで2.5ドル/月($0.004/時間)で借りることができます。4GBメモリでも月20ドルです。 最近はVULTRのヘビーユーザーになので、「ここ」から会員登録してもらえるとサービス開発が捗ります!

                                                        RSpecでテストを作るのに役立つ「モック/スタブ」のシンプルな説明
                                                      • waf チュートリアル - 純粋関数型雑記帳

                                                        waf - The flexible build system http://code.google.com/p/waf/ wafというものを最近知り一目惚れしてしまったので、紹介記事を書きます。ユーザーが増えると嬉しいな。 wafとは何か?特徴・利点・使うべき理由 wafはPythonベースのビルドシステムです。同様のことを行うツールとして、Autotools、Scons、CMake、Antなどがあります。Sconsからの派生で、比較的新しいソフトウェアです。 分かりやすい Pythonで書かれており、スクリプトもPythonで記述します。シェルスクリプトと謎のマクロが入り混じるAutotoolsや、独自言語のCMakeなどに比べて扱い易いです。Pythonを知っていれば非常にすんなりと使いこなすことが出来ます。Pythonを知らなくても、他の独自言語を覚えるよりは実りがあるかと思います

                                                          waf チュートリアル - 純粋関数型雑記帳
                                                        • Jenkinsでビルド・パイプラインを作る

                                                          Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 #12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの1つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、本番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。(

                                                            Jenkinsでビルド・パイプラインを作る
                                                          • Dropboxは全部Pythonで信頼性の高いソフトウェアを作った(後編)~PyCon APAC 2013

                                                            Pythonユーザーが集まり、情報交換し、交流するためのカンファレンス「PyCon APAC 2013」が9月13日、14日に都内で開催されました。PyCon APACはこれまでシンガポールで開催されており、今回初めて日本で開催されました。 (本記事は「Dropboxは全部Pythonで信頼性の高いソフトウェアを作った(前編)~PyCon APAC 2013」の続きです) Pythonは遅いのか? でもたぶん、あなたのアプリはCPUによって制約されているわけではないでしょう。ごく限られた分野、例えばゲームとか科学計算ではないのならば、多くの制約はハードディスクやネットワーク、もしくはメモリから来ているのではないでしょうか。 それにもしも本当にCPUによって制約されているのであれば、そういうアプリはだいたいCやC++で書かれているとは思うけれど、Pythonにも選択肢はあって、それはCyth

                                                              Dropboxは全部Pythonで信頼性の高いソフトウェアを作った(後編)~PyCon APAC 2013
                                                            • RustでAPIを開発してみたら結構辛かった話

                                                              はじめに 皆様こんにちは、株式会社プラハのAwataです。 今日は、以前書いたリーダーの振り返り記事で軽く触れていた、RustでのAPI開発についての記事を書いていこうと思います。 結論RustでWebは辛い!という話なんですが、約5か月くらいRustでWeb開発をしたので、今後の参考になるようなことを書いていこうと思います。 ぜひ最後までお付き合いください。 TL;DR RustでWeb開発はまだ早いかもしれない。 RustでDDDはやりやすい。ただしDIがやりにくい場合があるので、そこは要注意。 Rustはモジュールの仕組みが協力なので、モジュラモノリスはやりやすい。 サンプルリポジトリはこちら Rustはやっぱり難しいけど人気の理由も少し分かった気がする そもそもなぜRustでやってみようとなったのか 前例が少ない中、どうしてRustで開発しようと思ったのか気になる方も多いと思います

                                                                RustでAPIを開発してみたら結構辛かった話
                                                              • PHPUnitでできる単体テスト

                                                                はじめに 単体テストとは、システムの構成要素であるクラスやメソッド単位での動作を確認する作業のことを言います。 Webシステムは基本的に不特定多数に公開するものであり、公開前にはきちんとテストを行っておくことが重要です。 PHPにはテストツールとしてPHPUnitという単体テストのツールがあり、PHPUnitを利用するとクラス内のメソッドに対してテスト用のクラスを自動で生成し、効率よくテストすることができます。 PHPUnitを利用して単体テストする場合のプロセスは テスト対象となるクラス、PHPプログラムの作成 1.で作成したクラスからPHPUnit内のクラスを用いてテスト用のクラスを作成 2.で作成したテスト用のクラスに目的に応じてテストメソッドの実体を記述 テスト実行、結果の確認 となります。 本記事では、本連載第4回『GPS携帯を使った口コミサイト構築』の逆ジオコーディング処理をテ

                                                                  PHPUnitでできる単体テスト
                                                                • ウノウラボ by Zynga Japan: 30分でわかる PHP Extensionの作り方を学べる記事をかいたよー \(^o^)/

                                                                  こんにちは。12月に入社した@chobi_eです。 私が所属しているチームではお菓子系男子が30%を超えているという素敵チームで 毎週チーム内の漢の子がお菓子を焼いてくるという状況でハッピハッピハッピーです。 今日は私が学んできたPHP Extension作成についてのノウハウの一部を 公開しようと思います。 PHPExtension作成についての資料はklabさんやyoyaさん rskyさんの記事が参考になりますが私のようにPHPは書けてもCが書けない人には具体的にhello world以降何をすればいいのかがサッパリよく分かりません。 そこで先人達が作ってくれた偉大なライブラリをPHPで扱えるようにする為にC/MigemoのPHPバインディングを作ってみましょう C/Migemoをインストールしてみる 読者の方の中にはC/Migemoをご存知でない方もいらっしゃるかと思いますので簡単に

                                                                  • Test your IPv6.

                                                                    JavaScript Required This site requires JavaScript, as well as the ability to pull in cross-site scripts, in order to perform the testing. If this message does not go away, it means that JavaScript has been disabled, either by a plugin or extension in your browser, or by explicit browser setting. Do you use NoScript? If you use this Firefox add-on, you'll need to "Temporarily allow all this page".

                                                                      Test your IPv6.
                                                                    • MeCab: Yet Another Part-of-Speech and Morphological Analyzer

                                                                      MeCab に至るまでの形態素解析器開発の歴史等はこちらをご覧ください メーリングリスト 一般ユーザ向けメーリングリスト 開発者向けメーリングリスト 新着情報 2012-01-27 MeCab 0.993 MeCab::Tagger::formatNode()が正しく動いていなかった問題の修正 スタックの消費を抑えるため、ほとんどのローカル変数(配列)をヒープ上に退避 2012-01-14 MeCab 0.992 ソースコード中のTypoの修正 2012-01-14 MeCab 0.991 空文字列もしくは空白文字列を解析した時に解析エラーとなる問題を修正 ユーザ辞書の作成に失敗する場合がある問題を修正 2011-12-24 MeCab 0.99 MeCab::Model, MeCab::Lattice クラスを追加 マルチスレッド環境でのユーザビリティの向上。複数スレッドが同一

                                                                      • 書いたコードが一発で動作するとなぜ不安なのか : akiyan.com

                                                                        書いたコードが一発で動作するとなぜ不安なのか 2013-04-21 プログラミングにおいて少なくないコードを一気に書き上げたとき、そのコードが一発で動作 or テストケースに通るとなんともいえない不安を覚えるのは、プログラマーなら誰でもあるあるネタだと思う。「本当にこれ、一発で動作しちゃっていいの? 俺、そこまでミスしないプログラマーだっけ?」なんて自分を疑ったりする。 このあいだもそんなことがあったんだけど、ふと気になった。不安になる理由は、自信のなさからくるものだけだろうか? ちなみに、書いたコードが正しく動作しないとき、コードを修正すると不安になることはない。一体、なぜ? 一発で動作したブラウザの画面を見ながら、考えてみて、閃いた。「コードの修正は、書いたコードを見直す機会にもなっているから」じゃないだろうか。コードの見直しは「リファクタリング」といっていもいい。 一発で動作してしま

                                                                          書いたコードが一発で動作するとなぜ不安なのか : akiyan.com
                                                                        • 開発を効率的に進めるられるまでの道程

                                                                          DroidKaigi Android学ぶを君へ。生き抜くためのナレッジ共有 Note : https://github.com/operando/DroidKaigi

                                                                            開発を効率的に進めるられるまでの道程
                                                                          • 小さく始める JavaScript のテスト - Qiita

                                                                            書かないと怒られるし、書きたいとは思っているが、書くまでの敷居がやたらと高くなってしまった気がしている人へ。 最小のテスト 本質的にテストを書くのにフレームワークはいらない。 assertion だけあればいい。 isomorphic にしたいなら、 node の assert モジュールすら使わず console.assert だけで書ける。 // assert function assert(actual, expected) { console.log('.'); console.assert(actual === expected, '\nact: ' + actual + '\nexp: ' + expected); } function TestSum() { assert(1+2, 3); } // exec TestSum(); あとは普通にこのスクリプトを node/io

                                                                              小さく始める JavaScript のテスト - Qiita
                                                                            • PHPの改善 !== PHPのバージョンアップ | PR TIMES 開発者ブログ

                                                                              <? include("abc.php"); include("def.php"); include("conf.php"); include("db.php"); include("some.php"); include("what.php"); Define("NUM", 100); class super_calc extends great_calc { /* * * * コンストラクタ * * * * */ public function super_calc($initial_num){ $this->db = DB::getDb(DSN); $this->initial_num = $initial_num; } /* * * * チェック * * * * */ public add_ok($add_num){ $res = $this->addable($add_num);

                                                                                PHPの改善 !== PHPのバージョンアップ | PR TIMES 開発者ブログ
                                                                              • Jest

                                                                                Jest is a delightful JavaScript Testing Framework with a focus on simplicity.

                                                                                  Jest
                                                                                • (修正版) NumPy/pandas使いのためのテスト自動化入門 / PyConJP2020

                                                                                  PyCon JP 2020での発表スライドです。 --------------------------- (2020/08/30) 誤字を修正しました。 場所: p15 誤: assert_array_close() 正: assert_allclose() --------------------------- (2020/08/31) 誤字を修正しました。pandas.util.testingは動作しますが、pandas1.0以降ではdeprecatedになっており代替としてpandas.testingを使うことが推奨されています。 場所: p17 誤: pandas.util.testing 正: pandas.testing なお、p18のサンプルコードは元々pandas.testingで説明していたため変更はありません。 --------------------------- ト

                                                                                    (修正版) NumPy/pandas使いのためのテスト自動化入門 / PyConJP2020