Java 18で入ったJVM関連の(やや細かめな)改善(JJUGナイトセミナー「Java 18 リリース記念イベント」発表資料)
前回書いた 短期間でプログラミングを習得してWebサービスをつくるための知識と方法まとめ が好評だったので、今回は、JavaScriptに絞って習得するための方法をまとめてみたいと思います。 ちなみに、一番最初に、JSに触れた時は、Hello, Worldを表示させたり、 aタグでリンクをはったりぐらいしか出来ませんでした。 ですが、現在はjQueryで社内システムの 画面をつくる(Ajaxとかを使って)事を任せてもらっています。 なぜ、JavaScript(JS)がいいのか?なぜ勉強するのか? まずは、なぜJSをお薦めするのかを説明します。 ①ネイティブアプリがつくれちゃう。 ネイティブアプリとは、iPhoneアプリとか、Androidアプリのことです。 これまでは、iPhoneなら、Objective-Cという言語を、 AndroidならJava(JSとは別物)という言語
Tags: partnerbyd_studiosolution_partner_managementpartner_enablement_centersap_solutions_ondemand_studiosolution_partner This document is aimed at anyone interested in extending the core functionalities of the SAP Cloud solutions namely SAP Cloud for Customers, SAP Business ByDesign and SAP Cloud for Travel by using the SAP Cloud Applications Studio. You would like to know, what the SAP Cloud Appl
静的テスト/動的テスト ( ※↓ ) 1.静的テスト、2.動的テスト モデルベーステスト / モデルベースではないテスト ( ※↓ ) モデルベーステスト モデルベースではないテスト 2.1. アドホックテスト、2.2.探索型テスト ホワイトボックス・テスト / ブラックボックス・テスト / グレーボックス・テスト ( ※↓ ) ホワイトボックス・テスト ( ※↓ ) 1.制御パステスト、2.データフロー・パステスト ブラックボックス・テスト ( ※↓ ) 入力値および出力値の項目を決定する方法 1.同値分割、2.境界値分析 テストケース(テストを行う入力値と出力値の項目とその組み合わせ)を決定する方法 ディシジョンテーブルを使った方法 1.単純なディシジョンテーブルの使用、 2. 原因結果グラフ、3. 実験計画法、4. 原因流れ図(グレーボックステストの一種) 状態遷移テスト ファズ・テ
.scratch(初期Scratch) .sb(~Scratch 1.4) .sb2(Scratch 2.0) .sb3(Scratch 3.0) .sprite(~Scratch 1.4) .sprite2(Scratch 2.0) .sprite3(Scratch 3.0) Scratch(スクラッチ)は、アメリカにある非営利団体Scratch財団がマサチューセッツ工科大学(Massachusetts Institute of Technology、MIT)のMITメディアラボ(MIT Media Lab)内にあるライフロング・キンダーガーテン・グループ(Lifelong Kindergarten Group)と共同開発する、8歳から16歳のユーザーをメインターゲットとする無料教育ビジュアルプログラミング言語及びその開発環境、コミュニティサイトである。ウィキペディアと同様、収録されてい
あのWebサービスもJVMを利用している 「Javaは大規模なエンタープライズシステムにしか使われない」 それが常識だと思っていませんか? たしかに、これまでJava Virtual Machine(JVM)は、他の言語を実行すると遅く、Javaのプログラムを実行する環境にすぎないものでした。ところが、Java 7から実装されたInvokeDynamicにより、JVM上で、RubyやPHPなどさまざまなコンピュータ言語で記述されたプログラムをより高速に実行できるようになりました。 これにより、今までエンタープライズでJava言語で記述されたプログラムを実行するだけの環境であったJVMが、汎用的な実行環境になったと言えます。また、これまでJavaの実行環境として使用されていたノウハウが、他の言語で記述されたプログラムを実行する際にも利用できます。 最近では、TwitterがJVMをアプリケー
DBの世界に起こる変革 を見てびっくりするほどがっかりした。DBMSの世界はこれから変革が起こるどころが、もうすでに変革ががんがんに起こっていて、One Size Does Not Fit Allの時代だと言われて久しい。Oracle RDBMSだけの世界とかを見ていると、その変化が見えなくなってしまうことが多いだろう。しかしちょっとRDBMSを離れたら、現在はDBMS戦国時代であり、Oracle社もその有力なプレイヤーの一人である。 とりあえず現状を知りたいと思ったら、以下が非常に参考になる。 NoSQLの現状 50以上のソフトウェアがひしめく市場、これを戦国時代と言わずしてなんだろうか。MongoDBあり、Hadoopあり、KVSあり、NewSQLあり・・・これが21世紀のDBMSの現状だ。 ちなみに先のサイトで話にあった「ジャーナルを書かないRDBMS」というのはつまりLog Str
最近そもそもバッチ処理というものを知らない人達を見ることが多くなりました。某プロジェクトで「いや、ストプロってよくわからないんですよ。最近書いたことないし。」という話をずーっと聞いていたのですが、本人はバッチ処理という意味で話していたことが後から判明した、ということがありました。 ああ、この人はSQLでのバッチ処理しか知らないのですね、とちょっと衝撃ではありました。とうとうそーゆー時代になったかと。 まず、誤解のないようにいうとバッチ処理、という言葉自体はIT固有のものではないです。生産管理や物流や、そういった業務では普通に「バッチ」という言葉をIT以外で使います。ただし意味はある程度同じで、「一定の塊を一度に処理をする」ということです。物流システムの業務要件なんかを詰めているとバッチっていうと、どっちのこと?なんて普通に聞かれたりします。その意味ではバッチの対義語がリアルタイムというのは
自動改札機の運賃計算プログラムはいかにデバッグされているのか? 10の40乗という運賃パターンのテスト方法を開発者が解説(前編) ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか? 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡
最近、トランザクションの再勉強を始めていて、先日クラウド温泉でも発表させてもらった手前、ちょうどいいので一回まとめておく。はじめに断っておくと自分は別にDBやTXの専門家ではない。なので以下の内容の正確性については保証しない。内容については自分で勉強してくださいね。 1.「なんでまたTXなのか」 まずもって何故にTXなのか?というお話から始めます。もう枯れてんじゃないか?今頃RDBMSでもないだろう。それはそうですが、以下の流れは無視できません。 ・RDBMSの特許切れ NIIの佐藤先生の指摘にもあるように、1980-90年代のRDBMS関連の特許が切れ始めます。これにより商用一辺倒で、OSSではどうしても勝てなかったRDBMSでの技術革新や、その技術を応用した別のもの(RDBMSとは限りません)が登場してくる可能性が高いです。各ベンダーもそれを見越して、一斉にRDBMS関連への「逆張り」
等など、懸念点が一杯で、問題解くこと自体に入れないわけです。 だがしかし、実際に、自分が自転車に乗るとして、そこらへん適当に考えてよ、というと、それは難しいです。。。。ということになり、それでも無理やり作らせると、これまた非常にセンスがない前提を作って考えてくるのです。多分、興味の向きが「人間」ではなく「仕組み」にあるから、なんですね。 どうして今自分はこういう動作をしたんだろう?ではなくこれはどういう風に動いてるんだろう?と。 で、元の話に戻ると。 「要件にマッチしてるかどうか」を判断しながら動作を規定するは、結構「理系人間」には難しいのです。 なぜなら、『動作を規定する=「要件」に照らし合わせながら「前提条件」を自分で定義していく』作業なので。 そして、良く言われるのは、エンジニアは機能をいかにウツクシク実現できるか、に目がいきがちでそれがどういう文脈で使われるかまで考えられない。思い
JB:この件について一般化するのは嫌なので、私がTDD/BDD使うときとその理由を説明させてください。 私が初めてTDDに出会ったのはミス(欠陥といってもバグといってもいいでしょう)を防ぐ方法を求めていたからです。プログラム上の多くのミスのおかげで私は完璧さの感覚を失ってしまいました。どんなことを成し遂げても仕事が完璧に近づいたと感じたことはありませんでした。そして、書いたコードをテストすれば、ばかげた小さなミスを見つけ修正できるのではないかと考えました。テストをしてミスを見つけたかったのは、愚かにみられるのを防ぐためというより、仕事に対する完璧さの感覚を失わないようにするためです。実際テストは役に立ちました。数年経って、TDDはコーディングのミスを防ぐのに役に立つだけでなく、デザインの失敗を防ぐのにも役に立つことに気づきました。そしてBDDを学び、どのような機能を実装するかについての失敗
コードと構成管理の取扱いについて。ソフトウェア開発プロジェクトで自分がプログラミングすることは基本的に無いのだけれども、プロジェクトマネージャとしてはかなりコードに触れるほうだと思っている。最近コードにまつわる興味深いブログ記事をいくつか見たので、これに対して自分の考えを少しまとめてみる。 コードレビューについて ここで紹介されている、構成管理システム(VCS)でのレビューコントロールがとてもエレガントだと思う。 レビューのために bug tracker や task management system を使うのはあまり良いとは思いません。 レビューでは非常に細かい点が議論されることがあり、これが仕事のタスクの一チケットに相当するとはとても思えないからです。 例えば、この変数名は短すぎて良くわからない、といったことのために bug tracker をブラウザで開き、チケットを切る、やってら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く