パーフェクトJava EEの感想 - AOEの日記
Java EE 7 に対応した解説本として出版されたパーフェクト Java EE を 著者のお一人である上妻 (id:n_agetsuma) さんから頂きました。ありがとうございます！ 簡単ではありますが、本についての感想をまとめました。 gihyo.jp 実は本を頂いたのはもう半年前の夏のことだったのですが、色々と忙しい状況が続き、感想文の公開がこんなに遅くなってしまいました。ごめんなさい！ 本の特色 この本の特色は、Java EE の Web Profile に内容を絞ったという思い切った点にあります。説明する対象を絞ることで、これまでの和書の Java EE 解説本よりも、各仕様の解説が深くなっており、多様な機能、意外と知られていない新機能などがしっかり網羅されています。ただ、そのために jBatch が対象から抜けちゃったのはちょっと残念だったかなと思っています。 また、著作メンバ
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
Geekなぺーじ : いいから殺せ。後はこっちでなんとかするから
IT業界って怖いですね～（棒読み） 何でそうなった？ そもそもの発端は、私が現在執筆中のLinuxネットワークプログラミング書に書いているコラムのための質問でした。 Wiresharkやtcpdumpを利用したパケットキャプチャによる通信プログラムのデバッグを解説する際にプロミスキャスモードとは何かという話を書いていたのですが、その最後にちょっとしたコラムを書くためのブレストとしてTwitterで質問をしました。 で、結局出来上がった原稿は以下のような感じです。 Twitterでコラムの内容を見たいと発言されている方がいらしたので、出版前ですが晒してしまいます。 コラム：ぁゃιぃ UNIX用語 (☆ 「あやしい」の部分は、xa xya イオタ xi です。) プロミスキャスモードを「無差別モード」と訳す場合が多いのですが、この「Promiscuos」という単語は性的な意味を含む英単語なので
いまさら聞けないLinuxとメモリの基礎＆vmstatの詳しい使い方 - Qiita
さくらインターネット Advent Calendar最終日は、硬派にLinuxのメモリに関する基礎知識についてみてみたいと思います。 最近はサーバーを意識せずプログラミングできるようになり、メモリの空き容量について意識することも少なくなりましたが、いざ低レイヤーに触れなければいけないシチュエーションになった際に、OSを目の前に呆然とする人が多いようです。 基本的にLinux のパフォーマンスについて、メモリをたくさんつめばいいとか、スワップさせないほうが良い とか、このあたりは良く知られたことだと思います。 ただ、なんとなく ps コマンドや free コマンド などの結果を見るだけでなく、もう少しメモリのことについて掘り下げてみてみたいと思います。 メモリとキャッシュ Linux におけるメモリの状態を大きく分けると「使用中のメモリ」「キャッシュ」「空きメモリ」「スワップ」の 4 つに分
「ソフトウェアの時代」について - 急がば回れ、選ぶなら近道
まぁなんか適当に思うことを。 ■ハードの限界の露呈 ムーアの法則の限界はITのあり方を根本から変えると思う。この四半世紀、ITの現場レベルでは「困ったらハード増強」が一つの基本政策であったことは間違いない。ハードウェアの進歩は結果として、IT全体のパフォーマンスを上げ、結果として社会における有用性を増した。その一方でハードウェアの高進はソフトウェアの進化を止めていた側面は確かにある。 ソフトウェアのレイヤー、とくにミドルレイヤー〜アプリケーションのレイヤーでは、通信にしろ、分散処理にしろ、DBにしろ、OSにしろ、「業界全体としてトコトンできるレベルまでやったのか？」という意味では、実際はやっていないと思う。もちろん、各セグメントではそれなりに追求はしたけど、ドカドカ、金突っ込んで全部ひっくり返すというまでには至っていない。これはIT全体に言えることだけど、ソフトウェアにコストをかけるよりも
エンジニアが自由研究に時間をかけるべき理由
ここ数年でWebエンジニアを取り巻く環境は劇的に変わったと思う。 具体的に言うと、知的好奇心とやりがいを求めて仕事を選ぶことが当然になったように感じる。 Webエンジニアを取り巻く変化 5年半前、私が新卒で就職した時はまだ、エンジニアでも長時間労働はあたりまえで、エンジニアはビジネスサイドが考えた要件に従ってサービスを実装する人だ、という認識が強かったように思う。 一緒に大学院を卒業した優秀な友人たちはみんなメーカーか大手SIerに就職し、それこそWeb企業を就職の選択肢に入れている人はめずらしかった。 その後、リーンスタートアップやアジャイルの導入によって、エンジニアがサービスを考えて、実装・リリースし、データを取り、そのデータを元にまたサービスを改善していくことが当然となり、エンジニアという仕事はよりクリエイティブなものとなった。 また、オープンソースのプロダクトは当然のように色々なサ
「知らないこと」を恐れないマインドセットが技術導入を加速する - メソッド屋のブログ
先日、米マイクロソフトの Redmond キャンパスで行われたマイクロサービスのハックフェストに２週間ほどサポーターとして参加してきた。 そこで気づいた日本との技術導入の差の秘密について気づきをブログに書き留めておこうと思う。 ハックフェストというのは、お客様のガチの環境もしくはそれに近い環境/テーマで行うハッカソンだ。 例えば DevOps の文脈であれば、自動化したら効率化されそうな部分に関して、マイクロソフトの製品チーム、エバンジェリストがサポートしながら、お客様自身が我々と一緒にハックをして、実際にお客様の環境を自動化してしまうようなイベントだ。 Hello Worldやチュートリアルレベルではないので、お客様の環境が本当に自動化されてリードタイムが短縮されたり、我々にとっても、現場の難しい問題を知り、それに対してソリューションを作ることができるので、スキルアップまでできるので私は
2016年現在のJavaについて - arclamp
Sun MicrosystemsがOracleに買収されたのが2009年ですから、あれから7年が経ちました。 2013年、Javaは大人になったはずだった 僕は2013年に「イマドキのJavaとORACLEについて - arclamp」という記事をアップし、次のように書きました。 そんなわけで「ORACLEはJavaにコミットしているのか？」という質問が無意味なぐらい、ORACLEはJava技術だけではなく、Javaユーザーの方を向いているのです。 もちろん、ORACLEは（SUNに比べて）イノベーションが足りないとかスピード感がないとか批判もできるのですが、これだけエンタープライズのユーザーが増えた中では、Javaの後方互換性を保ちつつ、着実に進化していく、つまりは引き続き安心してJavaを使うことができるというのは大きな価値でしょう。 そう、Javaは本当の意味でオトナになったのかもし
プログラミングでよく使う英単語のまとめ【随時更新】
チェックマークをつける意味で check を使う場合は例外。 check 自体を避けたい場合は putCheckmark とする。 change 何をどう変更しているのかわからない。 check と同様に具体的な名前にできないか考えてみるとよい。 例外として isChanged のフラグを変更するための Change メソッドに使う場合がある。 xxxManager / xxxController こういう名前をつけるとクラスが肥大しやすい。 単一責任の原則にのっとってクラスを設計するべし。 UNIX 哲学にも「Small is beautiful.」という考え方がある。 xxxType, xxxData, xxxItem, xxxInfo 冗長になりやすい。 Type, Data, Item, Info を取っても意味が通じないか検討してみる。 使わないほうがよい言葉 compare 比
分析SQLのコーディングスタイル - クックパッド開発者ブログ
SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
乱数にコクを出す方法について
深津 貴之 / THE GUILD / note @fladdict アニメーションの監修で、「 Random();の代わりに、(Random()+Random()+Rrandom()+Random()+Random())/5.0f; を使うと、動きにコクが出る」と言ったら、ピュアオーディオ扱いされるのですが・・・これは根拠のあるアルゴです。 2016-11-03 11:29:43 深津 貴之 / THE GUILD / note @fladdict 乱数のコクをチューニングする話をすると、なぜピュアオーディオ扱いされるのか？ みんな乱数の波動を、もっと体で感じようよ。全然ヴァイブレーションが違うよ。 2016-11-03 11:36:47
乱数チューニングによる動きのコク
乱数チューニングによる動きのコク 1. 一様乱数 いわゆるMath関数による乱数。 雑味や臭みが強く、そのままでは使い物にならない。 2. 雑味を取り除いた乱数 下処理として臭みや雑味を取り除いた状態。一様乱数特有の発作的なガタツキがないのがわかるだろうか？ 過去2フレームに、距離33%以内の重複数が出ないようになっている。 シャッフルやスロットのアニメ処理など、2連続で同じ数字が重なるとバグって見える表現に有効。 3. コクのある乱数 乱数の旨味が濃縮された状態。中心極限定理により、自然な風合いに濃縮されている。 加算式による天然の正規分布は、ボックスミューラー法の養殖された乱数と違い、加算回数で生産者ごとの味わいが出せる。 パーティィクルや自然シミュレーションと相性が良い。 4. 芳醇なまろ味を出した乱数 口に含んだ後に、豊かな香りが広がる乱数。移動平均により連続性を出すことで、揺らぎ
技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
IBM、自社のJavaVMをオープンソース化すると発表。COBOLやPL/IのランタイムをJavaVMにも。Java 9と同時に正式版リリースを予定。JavaOne 2016
IBM、自社のJavaVMをオープンソース化すると発表。COBOLやPL/IのランタイムをJavaVMにも。Java 9と同時に正式版リリースを予定。JavaOne 2016 IBMは、これまで自社で開発してきたJavaVMをオープンソース化すると、サンフランシスコで開催されていたJavaOne 2016で発表しました。 JavaOne 2016の3日目の基調講演に登壇した同社Distinguished Engineer兼Java CTOのJohn Duimovich氏は、冒頭で聴衆に「With Community」（コミュニティとともに）と呼びかけたあと「Make Java Great Again」（Javaを再び素晴らしいものにしよう）と書かれたキャップをかぶって見せました。 これはIBMが、コミュニティと一緒にJavaを進化させていくのだという心意気を示したメッセージのように受け止め
ひどいソフトウェア作りたくなくて考えること - hitode909の日記
ソフトウェア作ってるとどうしようもないひどい状況になったり、知らないプロダクトを読んだらひどい状況になってたりすることがあって、どんなときにそういうことになるのか、必ずそうなるのか、そうなることを予見できないか、完成したソフトウェアを見てひどいかどうか判定できるか、とか気になってる。 作ってる途中に気付けないものか 作る前に気づけることはあるかひどいのは分かってるけどやるしかないときにだけひどいものができるのか時間はあるけどやる気がないとそうなるのかプライベートでなんかあるとそうなるのか書いてから時間が経つと大体のものはそうなるのかコードは正しくて読者が使われてるパターンに理解がないだけなのかパターンの使い方が変だと読めなくなるのか当時と環境、社会情勢や実行環境、データ量、などが変わってひどくなるのかいい技術が発明される前なのでしかたないのかいい技術が発明されたときにキャッチアップすべきか
皇紀を採用した安田生命保険の先見の明：データイズム：オルタナティブ・ブログ
実は私、安田生命保険相互会社（今の明治生命保険）に勤めていたことがあります。枝野官房長官が皇紀何年かご存じなかったというニュースがあって思い出して検索していたら、懐かしいことがWikipediaに書かれていました。 皇紀と安田生命保険 安田生命保険（今の明治安田生命保険）は、1970年代に個人情報管理のシステムを構築することになった。その際システムの担当者は、20数年後に生じるであろう2000年問題をすでに予測していたのか、あるいはシステム上で都合がいいからなのか、「年」の処理に西暦や元号ではなく皇紀を使用した[6]。そのことにより、安田生命保険は2000年問題を（皇紀の下2桁が00になるのは2040年なので）40年先送りしたとされる。 これだけでは分かりませんね。1940年をゼロとする皇紀を採用してどうして2000年問題を40年先送りできるのか？生保の扱う生まれ年なんて1940年（昭和1
神武天皇即位紀元#皇紀と安田生命保険 - Wikipedia
神武天皇即位紀元（じんむてんのうそくいきげん）は、初代天皇である神武天皇が即位したとされる年を元年とする日本の紀年法である。『日本書紀』の記述に基づき、元年を西暦（キリスト紀元）前660年としている。 通常は略して皇紀（こうき）という[1]。その他、紀元、神武紀元、皇暦（こうれき）、神武暦（じんむれき）、日紀（にっき）[2]等の名称がある。 昭和13年（1938年）に発行された五十銭紙幣 神武天皇即位紀元で「紀元二千五百九十八年」と記載されている 日本では明治5年（1872年）に神武天皇即位紀元を制定するまでは、紀年法として元号や干支を使用（あるいはそれらを併用）していた。明治維新後、政府は西洋に倣って、暦法を改め太陽暦を採用するとともに、紀年法として紀元を使用することにした。 明治5年（1872年）、政府は太陰太陽暦から太陽暦への改暦を布告し、その6日後に神武天皇即位を紀元とすることを布
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
appgiga.jp
Amazon Echo and the SAP HANA Cloud Platform
良きモノの提供に向けた協働 - 開発とテストが一体となったソフトウェア開発 -
