メモメモ

中央区の地価地図 1995-2023 — 国土数値情報で同じ19地点の28年を可視化

2026-07-24T10:36:31.000+09:00

国土数値情報の地価公示データを使って、東京都中央区の地価が1995年から2023年までどう動いたかを地図上で見られるサイトを作りました。

https://chuo-ward-landprice.onchange.workers.dev/

スライダーを1995年から2023年へ動かすと、円の大きさ（＝地価）と色（＝1995年比）が変わっていきます。日本橋・銀座・八丁堀・勝どきなど、中央区の19地点を並べてあります。

同じ中央区で、地価は23倍ちがう

まず目につくのは、区内の格差です。2023年の断面で見ると、いちばん高い銀座四丁目交差点（三越・和光のあたり）が2,860万円/m²。いちばん安い日本橋人形町の裏通りが127万円/m²。同じ区の、電車で数分の距離で、22.5倍の開きがあります。

「銀座は高い」という話は誰でも知っていますが、数字で並べると、その差が中央区という一つの区の中に収まっていることに改めて驚きます。

1995年を超えたのは、19地点のうち3地点だけ

このサイトでは各地点を「1995年＝100」の指数にして、色で表しています。100を超えれば暖色、下回れば寒色です。

28年たった2023年時点で、1995年の水準を超えているのは次の3地点だけでした。

銀座四丁目交差点 … 201（1995年の約2倍）
松屋銀座 … 169
東京駅八重洲南 … 145

いずれも、基幹の駅や大通りの交差点に面した街区です。残りの16地点は、いまも1995年の水準に届いていません。地名としてのブランド（銀座・日本橋）で回復したわけではなく、「どの通りに面しているか」で戻り方が大きく違う、という印象を受けます。

実際、同じ銀座でも一本裏に入った銀座二丁目は63にとどまります。これは日本橋側の裏通りとそれほど変わりません。

再開発の中心でも、6割弱

個人的にいちばん意外だったのが、日本橋室町です。三井本館やCOREDO室町がある、日本橋再開発の象徴のような場所ですが、指数は57（535万円/m² → 303万円/m²）。COREDO室町の開業（2010年）を挟んでも、1995年の6割弱にとどまっています。

再開発が街の賑わいを変えたのは間違いないと思いますが、少なくとも地価公示という一つの指標で、隣の街区までは十分に波及していない、という見え方になります。地価は再開発の効果が反映されるまで時間差もあるので、これだけで結論を出せる話ではありませんが、事実として「戻っていない」ことは記録に残っています。

全地点の「底」が、2004〜2005年に集中していた

スライダーを動かしていて気づいたのは、多くの地点が同じタイミングで底を打っていることです。19地点のうち15地点が、2004年か2005年に最安値をつけていました。バブル崩壊後の下落が、この時期にそろって止まっている。個別の街の事情というより、もっと大きな流れがあったことがうかがえます。

「地点が増えると比較にならない」という落とし穴

作る過程で一度つまずいた話を書いておきます。

地価公示は毎年少しずつ調査地点が増えます。中央区も、古い年ほど地点が少なく、新しい年ほど多い。最初はデータにある全64地点をそのまま地図に出していたのですが、これだと再生したときに「点が増えていく」のか「地価が動いた」のか区別がつきません。増えた点は、単に新しく調査対象になっただけなのに、画面上は何かが起きたように見えてしまう。

そこで、1995年から2023年まで欠測なく調査され続けた19地点だけに絞りました。全期間で地点数が変わらないので、純粋に同じ地点の推移だけを比べられます。地点数は減りましたが、比較として成立するほうを取りました。

データの扱いで気をつけたこと

地価公示の地点は「その街区の標準的な地価」であって、特定の建物の資産価値ではありません。施設名のラベル（「COREDO室町」など）は場所の目印として付けたもので、その建物の敷地価格ではない、という点は注記に入れています。
年と年のあいだはスライダーで滑らかに動きますが、これは表示上の補間で、実際の調査は年1回です。
出典は「国土数値情報（地価公示）（国土交通省）を加工して作成」。二次利用のルールに沿って明記しています。

技術メモ

地図は MapLibre GL JS と地理院タイル（淡色地図を暗く加工）。
地価公示データ（国土数値情報 L01）は zip の中に GeoJSON が同梱されていて、座標変換なしで使えます。1983〜2023年の各年価格が1レコードに全部入っているので、時系列を作るのが楽でした。
データはビルド時に静的な GeoJSON へ落としてあり、実行時に外部APIを叩きません。中央区19地点・28年分で、gzip後およそ4KBです。
地点ラベルは日本語なので、MapLibre の symbol レイヤー（フォントの外部配信が必要）を避け、HTMLの要素として重ねています。近すぎるラベルは、地価が高いほうを優先して間引いています。
ホスティングは Cloudflare Workers。

丸の内への通勤流動を可視化した前のプロジェクトが「どこから人が来るか（空間）」だったのに対し、今回は「28年で何が起きたか（時間）」を見るものになりました。

東急線全98駅の乗降客数トレンドマップ — 国土数値情報で2011〜2024年度を可視化

2026-07-23T01:37:05.748+09:00

国土数値情報のデータを使って、東急線全98駅の乗降客数の推移（2011〜2024年度）を地図上で可視化するサイトを作りました。

https://tokyu-trendmap.pages.dev/

各駅を乗降客数に応じた円で描き、下部のタイムスライダーを動かすと年度が切り替わって円が伸縮します。再生ボタンを押せば2011年度から2024年度までが自動で流れます。

コロナ禍の落ち込みと、その後

再生してみると、2020年度で円が一斉に縮み、その後じわじわと戻っていく様子が見えます。駅ごとの変化率を中央値でとると、こうなります。

期間	変化率（中央値）
2019 → 2020年度	−27.4%
2020 → 2024年度	+27.7%
2019 → 2024年度	−7.8%

コロナ禍で約3割減り、そこから3割近く戻したものの、コロナ前と比べるとまだ8%ほど少ない、という状況です。2019年度の水準まで戻っている駅は96駅中12駅にとどまります。

2024年度の乗降客数を見ると、渋谷が177万人/日と突出していて、以下横浜（51万）、中目黒（38万）、目黒（38万）、武蔵小杉（20万）と続きます。

「回復度」を色分けするのをやめた話

最初は「コロナ前（2019年度）比で増えた駅は青、減った駅は赤」という配色にしていました。作った側としては見せたい絵があったからです。

ただ、これは特定の年を基準に据えて解釈を押し付ける見せ方だと考え直し、やめました。年度はスライダーで自由に選べるので、どこを基準にするかは見る人が決めればいい。いまは円の色を一律にして、大きさだけで多寡を表しています。

円の色は濃いグレーにしました。青系だと、こどもの国線や東急新横浜線の路線色と近く、特にP型・D型色覚では駅が路線に埋もれてしまうためです。「路線は色付き、駅は無彩色」と役割を分けています。

データの扱いで気をつけたこと

欠損値は補間も推計もせず「データなし」として表示しています。世田谷線の2011年度など、そもそも値がない年度があります。

それと、出典データ側に集計範囲の変更に由来する不連続が残っています。たとえば渋谷は2011→2012年度で+70%と跳ねますが、これは2011年度まで田園都市線と東横線が別レコードで計上されていたものが、2012年度以降ひとつに統合されたためです。中目黒・目黒・横浜などは2023年度前後で大きく増えますが、相互直通運転分の計上範囲が変わったとみられます。

実態の変化ではないので補正したくなるところですが、どう補正しても恣意的になるため、そのまま出して注記で伝えることにしました。サイト内の「このサイトについて」にも書いてあります。

技術メモ

地図は MapLibre GL JS + 地理院タイル（淡色地図）
乗降客数は国土数値情報の「駅別乗降客数データ（S12-25）」、路線の形は「鉄道データ（N02-25）」から東急線ぶんを抽出
背景の地理院タイルは彩度を落として沈めています。ラスタタイルなので高速道路だけを消すことができず、「消す」のではなく「沈めて」東急線を前に出す方針にしました
路線の色は東急公式のラインカラー（公式サイトの路線ロゴSVGから取得）
データはビルド時に静的JSONへ落としてあり、実行時に外部APIを叩きません。日本語の駅名ラベルもブラウザのローカルフォントで描画しているので、フォントサーバーへの依存もなしです
ホスティングは Cloudflare Pages

出典: 国土数値情報（駅別乗降客数データ・鉄道データ）（国土交通省）を加工して作成。国土数値情報は非商用利用に限定されています。

毎朝84万人が千代田区へ — 2010・2015・2020年の国勢調査で通勤者数を市区町村別に可視化

2026-05-15T18:10:30.111+09:00

国勢調査のデータを使って、関東各地から千代田区への通勤者数をインタラクティブな地図で可視化するサイトを作りました。

https://marunouchi-commut.onchange.workers.dev

調査年	千代田区への通勤者数	前回比
2010年	約76万人	—
2015年	約79万人	+3万人
2020年	約84万人	+5万人

きっかけ

大手町、丸の内、有楽町——千代田区のこの一帯に、関東のどこからどれだけの人が毎朝集まってくるのか、ふと気になったことがきっかけです。

国勢調査には「従業地・通学地による人口集計」という項目があり、どの市区町村からどこへ通勤しているかが5年ごとに全国規模で記録されています。総務省統計局が e-Stat（政府統計の総合窓口）でオープンデータとして公開しており、誰でも無償で利用できます。このデータを使えば、千代田区への通勤流動を市区町村単位で地図上に描けると思い、作り始めました。

見えてきたこと

2020年時点で、千代田区への通勤者数は関東だけで約84万人です。横浜市や川崎市、さいたま市といった大都市からの流入が多いのは予想どおりでしたが、地図をひとつひとつ確認していくと、人口の少ない市からも想像以上に多くの人が毎朝この街を目指していることに気づきます。

2010年・2015年・2020年の3時点を切り替えて比較できるようにしたところ、全体の通勤者数は76万人→79万人→84万人と一貫して増加していることがわかりました。都心再開発の波がデータにも表れています。

2020年データの読み方

ひとつ注記しておきたいのが、最新の2020年データについてです。

国勢調査は5年ごとに10月1日時点の状況を記録します。2020年10月といえば、新型コロナウイルス感染症による最初の緊急事態宣言が解除されたあとにあたります。テレワークが急速に普及し、通勤の概念そのものが揺らいだ時期です。

「10月1日時点で千代田区に通勤している」という定義に照らすと、この年のデータは平常時とは異なる条件下で収集されている可能性があります。2015年から2020年にかけての増減を見るときは、コロナ禍という特殊な文脈を念頭に置いてほしいと思います。

使い方

地図上の市区町村をタップすると、通勤者数・全体シェア・順位・直前調査年との増減が表示されます。スマートフォンで自分の街を探してみてください。

https://marunouchi-commut.onchange.workers.dev

生成AI用語集 - MoE・Thinking・Reasoningなど主要概念まとめ

2026-02-01T14:30:45.112+09:00

生成AIの技術やサービスを理解するために、頻出する用語を自分の学習用にまとめました。

モデルアーキテクチャ関連

MoE（Mixture of Experts）

読み方: ミクスチャー・オブ・エキスパート

意味: 複数の「専門家（Expert）」と呼ばれるサブネットワークを持ち、入力に応じて最適な専門家のみを選択的に活性化させるニューラルネットワークアーキテクチャ。

メリット:

全パラメータを常に使用しないため、計算効率が高い
モデルの総パラメータ数を増やしつつ、推論コストを抑制可能

採用例: Mixtral（Mistral AI）、GPT-4（推定）、Grok

出典: Shazeer et al. (2017) "Outrageously Large Neural Networks"

Transformer

読み方: トランスフォーマー

意味: 2017年にGoogleが発表した、Self-Attention機構を中核とするニューラルネットワークアーキテクチャ。現在のLLMの基盤技術。

特徴:

並列処理が可能で学習が高速
長い文脈の依存関係を捉えられる

出典: Vaswani et al. (2017) "Attention Is All You Need"

パラメータ数

意味: モデルが学習する重みの総数。一般的にパラメータ数が多いほど表現力が高いが、計算コストも増大する。

目安:

7B（70億）: 軽量モデル、ローカル実行可能
70B（700億）: 高性能モデル
1T以上（1兆以上）: 最大規模モデル（GPT-4など）

推論・思考関連

Reasoning（リーズニング）

読み方: リーズニング

意味: AIが論理的な推論を行う能力。数学の問題解決、論理パズル、因果関係の理解などを含む。

関連技術: Chain-of-Thought、Tree-of-Thought

Chain-of-Thought（CoT）

読み方: チェイン・オブ・ソート

意味: 複雑な問題を解く際に、中間的な推論ステップを明示的に生成させるプロンプト手法。「段階的に考えてください」と指示することで精度が向上する。

出典: Wei et al. (2022) "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models"

Thinking / Extended Thinking

読み方: シンキング / エクステンデッド・シンキング

意味: モデルが回答を生成する前に、内部で思考プロセスを実行する機能。Claude 3.5やo1などで採用。

特徴:

複雑な問題で精度が向上
思考過程が可視化される場合もある
応答時間が長くなるトレードオフあり

System 1 / System 2

意味: 認知心理学に由来する概念。AIにも適用される。

System 1: 高速・直感的な処理（通常のLLM応答）
System 2: 低速・熟慮的な処理（Thinking機能、CoTなど）

出典: Daniel Kahneman "Thinking, Fast and Slow" (2011)

学習・ファインチューニング関連

RLHF（Reinforcement Learning from Human Feedback）

読み方: アールエルエイチエフ

意味: 人間のフィードバックを報酬として強化学習を行う手法。モデルの出力を人間の好みに合わせて調整する。

プロセス:

人間が複数の回答をランキング
報酬モデルを学習
報酬モデルを使ってLLMをファインチューニング

出典: Ouyang et al. (2022) "Training language models to follow instructions with human feedback"

Constitutional AI

読み方: コンスティチューショナルAI

意味: Anthropicが開発した手法。AIに「憲法」（原則のセット）を与え、自己批判と修正を通じて安全性を向上させる。

出典: Bai et al. (2022) "Constitutional AI: Harmlessness from AI Feedback"

LoRA（Low-Rank Adaptation）

読み方: ローラ

意味: 大規模モデルの全パラメータを更新せず、低ランクの行列を追加してファインチューニングする手法。計算コストを大幅に削減。

出典: Hu et al. (2021) "LoRA: Low-Rank Adaptation of Large Language Models"

応用・インターフェース関連

RAG（Retrieval-Augmented Generation）

読み方: ラグ

意味: 外部知識ベースから関連情報を検索し、それを元にテキストを生成する手法。モデルの知識を動的に拡張できる。

メリット:

最新情報を反映可能
ハルシネーション（幻覚）を軽減
出典を明示できる

出典: Lewis et al. (2020) "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"

Agent / AIエージェント

意味: LLMを核として、ツール使用・計画立案・実行を自律的に行うシステム。

構成要素:

LLM（推論エンジン）
ツール（API、検索、コード実行など）
メモリ（会話履歴、長期記憶）
計画機能

MCP（Model Context Protocol）

読み方: エムシーピー

意味: Anthropicが提唱するオープンプロトコル。AIアプリケーションと外部データソース・ツールを標準化された方法で接続する。

出典: Model Context Protocol公式

評価・品質関連

Hallucination（ハルシネーション）

読み方: ハルシネーション（幻覚）

意味: AIが事実と異なる情報をもっともらしく生成してしまう現象。

対策: RAG、ファクトチェック、温度パラメータの調整

Benchmark（ベンチマーク）

意味: モデルの性能を測定するための標準化されたテスト。

主要ベンチマーク:

MMLU: 多分野の知識を測定
HumanEval: コード生成能力
GSM8K: 数学的推論
HellaSwag: 常識推論

まとめ

生成AI分野は急速に発展しており、新しい用語が次々と登場しています。この記事は随時更新予定です。

参考リンク:

arXiv - AI論文のプレプリントサーバー
Hugging Face - モデル・データセットのハブ
Anthropic Research
OpenAI Research

都道府県別の時給相場が一目でわかる無料ツール — 47都道府県×4業種の市場相場を最低賃金と比較

2026-02-01T12:35:00.001+09:00

このツールでできること — 提案時給の市場競争力を即座に判定

人材派遣業の営業担当者向けに、提案時給が市場相場と比べて競争力を持つかを47都道府県・4業種別に判定できる無料ツールを作成しました。クライアントへの時給提案時の根拠資料としてご活用いただけます。

▶ 時給競争力シミュレーターを開く

主な機能 — 47都道府県×4業種に対応

47都道府県対応: 各都道府県の最低賃金と市場相場を表示
4業種対応: 宿泊業・飲食サービス業 / 卸売業・小売業 / 生活関連サービス業・娯楽業 / サービス業(派遣等)
リアルタイム判定: 時給を入力すると即座に全都道府県の競争力を判定
4段階評価: 安全・注意・危険・違反の4ランクで一目で判定
ダークモード対応

4段階評価の判定基準

提案時給を入力すると、各都道府県・業種ごとに以下の4段階で競争力を判定します。

評価	判定基準	意味
🟢 安全	相場 +10% 以上	市場競争力あり
🟡 注意	相場並み	標準的水準
🟠 危険	相場未満	採用難の可能性
🔴 違反	最低賃金未満	法令違反のため提案不可

データソース — 厚労省「賃金構造基本統計調査」をベース

本ツールは、厚生労働省「賃金構造基本統計調査」(e-Stat)の都道府県別・業種別データをベースに、各都道府県の最低賃金上昇率で補正した2024年推定時給を表示しています。

出典: e-Stat 賃金構造基本統計調査(厚生労働省)
対象: 短時間労働者 / 1時間当たり所定内給与額 / 都道府県別
最低賃金データ: 厚生労働省地域別最低賃金(2024年改定)

データの算出方法と注意点

本ツールの市場相場は、以下の計算式で算出した推定値です。

2024年推定時給 = 2019年実績 × (2024年最低賃金 ÷ 2019年最低賃金)

⚠ ご利用上の注意: 2020年以降、短時間労働者の産業×都道府県クロス集計データがe-Statで公開されていないため、2019年の実データを最低賃金上昇率で補正した推定値を使用しています。実際の募集条件とは異なる場合がありますので、参考値としてご活用ください。

使い方 — 業界選択と時給入力の2ステップ

業界を選択
提案したい時給を入力
各都道府県のカードで競争力を確認

クライアントへの時給提案時の根拠資料として、ぜひご活用ください。

Mac初期設定履歴

2025-07-17T08:16:00.000+09:00

-- 設定 --

・３本指ドラッグ

https://support.apple.com/ja-jp/102341

・メニューバーにバッテリーの状況を表示

https://support.apple.com/ja-jp/guide/mac-help/mchlp1115/mac

-- インストール --

■手動

brew

■brew

git

■brew casks

appcleaner

firefox

rectangle

zoom

brave-browser

google-chrome

slack

docker

microsoft-edge

visual-studio-code

figma

opera

vlc

brave

1password

■App Store

VirusBarrier Scanner

LINE

Kindle

■直接

・Epson Software

・VMWare Fusion

このブログについて

2024-07-09T06:38:00.002+09:00

■このブログの目的

・自分にとって価値のある情報を蓄積する

・アウトプットすることで知識の深掘りや技術の理解を深める

■このブログで記載する内容

・自分にとって有用な情報

・自分が10年後見ても価値のある(あるいは価値があったと思える)情報

・知人に見られても問題ない内容

■このブログで記載しない内容

・プライベートに関する内容は記載しない

・政治的な内容は記載しない

・Blogger.com コンテンツポリシーに反する内容は記載しない

読書：プロジェクトのトラブル解決大全

2024-07-06T05:38:00.008+09:00

プロジェクトのトラブル解決大全　小さな問題から大炎上まで使える「プロの火消し術86」

■目次
序章　プロジェクトのトラブル解決にもセオリーがある
第１章　最初の準備―９割の人がスタートでつまずく
第２章　状況把握―効率的な現場検証と聴取の方法
第３章　原因特定とリカバリプランの策定―真因特定、優先順位、体制見直しの手順
第４章　リスタートを切る―人心掌握、ルール変えのポイント
第５章　リカバリ遂行―炎上中のプロジェクト管理は「３つだけ」
第６章　メンバーモチベーション管理―モチベーションは「上げる」のではなく「戻す」
第７章　リーダーシップとメンタリティ―炎上を通じて新たな信頼を築けるリーダーとは
第８章　クロージング―次につなげる「振り返り」から盛大な「打ち上げ」まで

■著者
木部智之氏
デロイトトーマツコンサルティング合同会社ディレクター/元日本IBMエグゼクティブ・プロジェクト・マネジャー。

■■メモ■■
■序章　プロジェクトのトラブル解決にもセオリーがある
・そもそもトラブルプロジェクトに対応のセオリーがあることに驚き。ただし読んでみると確かに思い当たるフシだらけで、納得できるものや新たな気づきを本書で得られる
・小さな火種を放置しない

■第１章　最初の準備―９割の人がスタートでつまずく
・「腹をくくる」いきなり精神論だが、これは本当に大事。当事者意識がないと挫けて逃げに走る
・最初に確認すべきは「プロジェクト計画書」「体制図」「課題管理表」「進捗報告資料」
・原因と対策の仮説を立てる
・「懐刀」を手にいれる
　・これも人に関するところでなかなか難しい。。。

ヤフーファイナンスの数値を理解する - 詳細情報 - 参考指標 - EPS/BPS

2018-07-17T23:53:00.002+09:00

前回に引き続き、指標数字の意味を確認していきます。
※用語はファイナンス用語集/初めてでもわかりやすい用語集を参照しています

今回も「詳細情報」タブの「参考指標」を見てみます。
データは2018/7/17 のヤフー株(株価361円)を利用しています。

EPS(1株利益)

当期純利益÷期中平均株式数=EPSなのですが、ヤフーの場合2019年３月期の予想当期利益を発表していないので、2018年3月期で計算すると、
2018年３月期当期利益 131,153,000,000円 ÷ 発行済株式数5,696,905,200株 = 23.02円となりますね
こちらにも決算数値が載っていますが、過去3期で発行済株式数は変わらないのですが営業利益は下がっているので、EPSは下がってきていますね。

BPS(1株あたり純資産)

株主資本 ÷ 発行済株式数 = BPS ですが、
自己資本1,013,878,218,444円 ÷ 発行済株式数5,696,905,200株 = 177.97円となりますね
こちらにも決算数値が載っていますが、過去3期で発行済株式数は変わらないのですが営業利益は下がっているので、EPSは下がってきていますね。
こちらの決算数値では、過去3期で発行済株式数は変わらないが自己資本は増えているため、BPSは上昇傾向にあります。自己資本増加の中身を見て見ると、ジャパンネット銀行を子会社したことで１兆円ほど増えています。お金が増えたというよりも、銀行資産がまるごと移ってきただけなので、使えるお金が増えた、というわけでもなさそうですね。

ヤフーファイナンスの数値を理解する - 詳細情報 - 参考指標

2018-06-25T21:56:00.000+09:00

前回に引き続き、指標数字の意味を確認していきます。
※用語はファイナンス用語集/初めてでもわかりやすい用語集を参照しています

今回は「詳細情報」タブの「参考指標」を見てみます。
データは2018/6/7 のヤフー株(株価393円)を利用しています。

時価総額

株価に発行済株式数を掛けたもの。
単位：百万円（十万円のけたを四捨五入して表示）

発行済株式数

各証券取引所が発表している公表資料による。ただし、転換社債または優先株の普通株式への転換、新株引受権の行使にともなう株式数の増加や、自社株買いによる株式消却が規定の数量未満である場合などは、毎月末ごろに前月中の変化分がまとめて発表されるため、毎日の更新ではなく最大2か月遅れとなる場合がある。
また、株主割当やライツイシューなどの増資（既存株主が時価よりも安い金額を払い込むことにより、株を得ることができる増資）があった場合には、理論的には株価が減少するため、払い込みが行なわれるまでの間、時価総額が変動しないように発行済株式数を増加させている。そのため、実際の発行済株式数とは異なる場合がある。
単位：株

配当利回り(会社予想)

一株当りの年間予想配当(予想1株配当)を株価で割って算出。
単位：％（小数点以下第2位まで表示）
算式：年間配当金 ÷ 株価 × 100

1株配当(会社予想)

企業が発表した一株当りの年間予想配当。原則、前営業日までに発表された配当予想値を反映。
期中に株式分割等が予定されている企業については、現在の株数に換算した値を表示。
※分割発生時の表示例：

7月に予想配当を5,000円と発表していた銘柄が、1：100の株式分割を発表(効力発生日 10月1日、株価変更日 9月26日)した場合、株価変更日の9月26日より50円と表示

PER(会社予想)：株価収益率

株価を1株当りの予想純利益(予想EPS)で割って算出。
単位：倍。小数点以下第2位まで表示
算式：株価 ÷ 予想EPS

PBR(実績)：株価純資産倍率

株価を1株当りの純資産(BPS)で割って算出。
単位：倍。小数点以下第2位まで表示
算式：株価 ÷ BPS

EPS(会社予想)：1株利益

1株当たりの予想純利益。企業が発表した予想当期純利益を期中平均株式数で割って算出。原則、前営業日までに発表された予想値を反映。
中間決算や変則決算の場合、数値は年率換算していない。
※分割発生時の表示例

会社予想を元に算出したEPSが3,000円の銘柄で、1：100の株式分割(効発生日 10月1日、株価変更日 9月26日)が発生する場合、株価変更日の9月26日より30円と表示。

単位：円（小数点以下第2位まで表示）
算式：今期予想当期純利益÷期中平均株式数

BPS(実績)：1株株主資本・1株当たり純資産

四半期毎の短信発表実績値を元に一株当りの純資産を算出。
発表以降分割が行われている場合は、現在株数ベースに換算した数値を表示
原則として、前営業日までの発表値を反映。
単位：円（小数点以下第2位まで表示）
算式：株主資本 ÷ 発行済株式数

最低購入金額

その銘柄を取引するために最低限必要な購入金額。
単位：円
算式は：株価×単元株数

単元株数

取引の基準となる株数
「---」は単元株制度がないことを示す。
単位：株

年初来高値

その年（1〜3月までは前年とその年）で最も高かった約定値段。

年初来安値

その年（1〜3月までは前年とその年）で最も低かった約定値段。

それではもうちょっと具体的に見ていきましょう。

時価総額

約2.2兆円ぐらいで、東証全市場の中で、６０番ぐらいの規模のようです

発行済株式数

約56億株ぐらいですね。東証全市場で5番目ぐらいなので、かなりたくさん発行しているようですね

配当利回り(会社予想)

年間配当8.86円 ÷ 株価393円 x 100 = 2.25%ですね。
2%を越えると高配当株と言われるようですが、数ヶ月前の株価が500円だったことを考えると、株価が下がって高配当になった印象があります。

1株配当(会社予想)

1株あたり8.86円なので、100株の単元株もっていれば１年で886円(税引前)もらえることになります

PER/PBR/EPS/BPS

次回詳しく見ていこうと思います

最低購入金額

株価 393円 × 単元株数100株 = 39,300円からヤフー株が買えます

年初来高値

2018/01/25に549円をつけたのが、今年の最高値のようです

年初来安値

2018/06/05に380円をつけたのが、今年の最安値のようです

ヤフーファイナンスの数値を理解する - 詳細情報

2018-06-05T22:01:00.000+09:00

各企業の株価や情報を知るのにヤフーファイナンスをよく利用するのですが、見るのは株価とチャートぐらいです。
情報を正確に把握するために、改めて一つ一つの指標数字の意味を確認していこうと思います。
※用語はファイナンス用語集/初めてでもわかりやすい用語集を参照しています

まずは「詳細情報」タブから。

前日終値

前営業日の最後に成立した約定(売買が成立した)値段

始値

場(前場：午前9時から11時30分/後場：取引所によって時間帯は若干異なり、例えば東京証券取引所の場合は、12時半から15時)が開いてから最初の約定値段、つまりその日に初めて成立した約定値段
前日の終値に近い値段とは限らない
とくに前日の取引終了後にニュース報道などがあった場合、大きく動くことがある

高値

寄付き(前場と後場それぞれで最初に成立した取引)から現在時刻までで最も高かった約定値段

安値

寄付きから現在時刻までに最も安かった約定値段

出来高

その日取引された合計株数。売買高とも

売買代金

その日取引された合計金額
単位：千円

値幅制限

前日終値にあわせて決まる、株価が動く範囲
単位：円

Hadoop and HBase vs RDBMS メモ

2009-11-29T22:23:00.004+09:00

Hadoop and HBase vs RDBMSの超適当翻訳メモ

Hadoop/HBase vs. RDBMS

December CTO Forum

Jonathan Gray
Streamy.com

-1-

プロフィール

・Streamy.comの共同創業者
・経歴（経験）：コンピュータエンジニアリング、分散／耐障害性アプリケーション、リレーショナルデータベース、Linux
・2008年6月にStreamy.comのバックエンドをPostgreSQL からHadoop/Hbaseに移行に成功

-2-

なぜHadoop/Hbaseなのか

・データがペタバイトまで大きくなった
・従来のデータベースは拡張するのにお金がかかるし、本質的に分散化が難しい
・一般的なハードウェアは安くてパワフル
- 1000ドル（？）で4core/4GB/1TB
- 300GB 15k RPM SAS が500ドルぐらい
・ランダムアクセスとバッチ処理が必要
- Hadoop はbatch/streamingのみサポート

-3-

Hadoop/Hbaseの歴史

・ Googleは拡張性の問題を解決した
- “The Google File System” 2003年10月発表
　- Hadoop DFS
- “MapReduce：大規模クラスター構成での簡略化されたデータ処理” 2004年12月発表
- Hadoop Map Reduce
- “Bigtable：構造化されたデータのための分散ストレージファイルシステム” 2006年11月発表
- HBase

-4-

Hadoop の紹介

・2つのメインコンポーネント
- Hadoop DFS
　　- 一般的なハードウェア上で動作する、スケーラブルで障害耐性の高い、高性能分散ファイルシステム
- Hadoop Map Reduce
- 分散コンピューティングのためのソフトウェアフレームワーク
・採用実績
　- 多くの組織で製品として使われている
　- Yahooはプライマリースポンサーとして何万ものHadoopのアクティブノードを動かしている

-5-

HDFS: Hadoop Distributed File System

・数千のノードにペタバイトのデータを複製
- データは64MBのブロックごとに分割され、それぞれのブロックが3回複製される
・マスター／スレーブアーキテクチャ
- マスター NameNode はブロックの位置情報を含む
- スレーブ DataNode はローカルのファイルシステムのブロックを管理する
・一般的なハードウェアで組み立て
- 15k RPM diskもRAIDも不要

-6-

HDFS の例

・１テラバイトのテキストファイルを10ノードのクラスター上に展開
- Java APIか、コマンドラインが使える
./hadoop dfs ?copyFromLocal ./srcFile /destFile
- ファイルは64MBのブロックに分割(合計16,384ブロック)
- それぞれのブロックは3つのノードに送られる(合計49,152ブロック、3テラバイト)
- 異なったクラスター／地理的な位置にレプリケーションが保障される

-7-

MapReduce

・ペタバイトのデータを確実にローカルファイルのように扱うための分散プログラミングモデル
- JavaとＣが最初から使える
- HadoopStreamingを使ってどんな言語も使える
・関数型プログラミングのmap/reduce関数に触発された
　入力 -> Map() -> コピー/ソート -> Reduce() -> 出力

-8-

MapReduce の例

・ WordCount の例をHDFS上の1テラバイトのファイルで動かす
- 各ブロックファイルでMapタスク起動
- それぞれのタスクの中で、Map関数がそれぞれの行で呼ばれる：Map(LineNubmer,LineString)
- LineStringの中のれぞれの文字→Output(Word,1)
- Mapの出力はソートされ、グループ化され、reducerにコピーされる
- Reduce(Word,List)がそれぞれの文字で呼ばれる
- Output(Word,Length(List))
- 最終的に、それぞれの文字の合計数が出力される

-9-

Hadoop…

　 - Hadoopは、大規模なデータを”バッチ”で保存したり、ストリーミングするように設計されている
- Hadoopは、リアルタイムでクエリーを流すのには向いていない
- Hadoopは、ランダムアクセスをサポートしない
これがHbaseがある理由。

-10-

Hbaseとは？

・分散、
・列指向、
・多次元、
・高可用性、
・高性能
・ストレージシステム
プロジェクトゴール：
数十億の列行×数百万の列×数百のバージョン
の数ペタバイトデータが数千の一般的なサーバに載る

-11-

HBase でできないor不得意なこと

・SQL データベース
- joinがない、クエリーエンジンがない、型がない、ＳＱＬがない
- トランザクション、副次索引はできるけど、未熟
・ＲＤＢＭＳの当座の代用品
・ＲＤＢＭに対しての非スキーマ構造
- 非正規化データ
- 分散してコマ切れのテーブル

社内のＤＢＡなら“ＮＯ”って言うでしょう

-12-

HBase のアーキテクチャ

・テーブルはいくつもの領域(regions)からできている
・領域は”startKey”と”endKey”によって特定される
- 空のテーブル：
(Table,NULL,NULL)
- ２つの　領域のテーブル：
(Table,NULL,”Streamy”)と(Table,”Streamy”,NULL)
・それぞれの領域はＨＤＦＳ上の各ファイルやブロックとして違ったノードにあるかもしれない。
それぞれの領域はHadoopによって複製される

-13-

HBase アーキテクチャ（つづき）
・２つのタイプのHbaseのノード
・特別テーブル ? ROOT ? と META。スキーマ情報と領域の位置を保存
・マスターサーバーは領域サーバーの監視に責任を持ち、領域のロードバランシングにも責任を持つ

-14-

HBase のテーブル

・テーブルは行によってソートされる
・テーブルスキーマは”column families”によってのみ定義される
- それぞれのファミリーはいくつもの列から成る
- それぞれの列はいくつものバージョンから成る
- 列はinsertされた時のみ存在し、NULLの入力は自由（できる？）
- ファミリーの中の列はソートされ、また、お互いにソートされる
- テーブル名を除くすべてはbyte[]
(Table,Row,Family:Column,Timestamp)→値

-15-

HBase テーブルのデータ構造

SortedMap(
RowKey, List(
SortedMap(
Column, List(
Value, Timestamp
)
)
)
)
SortedMap(RowKey, List(SortedMap(Column, List(Value, Timestamp))))

-16-

Web クロールの例

・webクロールデータの保存
- “crawl”テーブルと “content” ファミリー
- 列の中にＵＲＬの行
- content:data 加工していないクロールしたデータを保存
- content:language HTTPのLanguage ヘッダーを保存
- content:type HTTPのContent-Typeヘッダーを保存
- もしハイパーリンクや画像などのために未加工データを処理するのであれば、”links”ファミリーと”images”ファミリーを加える
　 - links: それぞれのハイパーリンクのための列
- images: それぞれの画像のための列

-17-

RDBMSでのWebクロールの例

・一般的なＤＢだとどうなるのか？
- “crawl”テーブルの中に”url”,”data”,”language”,”type”列
- “links”テーブルの中に”url”と”link”列
- “images”テーブルの中に”url”と”image”列
・どのぐらいの規模？
- 1000万ドキュメント w/avg 10リンクと10イメージ
- 合計2億1000万行に対して合計1000万
- links/imagesテーブルでインデクスが膨れ上がる

-18-

HBaseへの接続

・ネイティブ Java クライアント/API
- get(byte[] row, byte[] column, long ts, int versions)
・非ネイティブ Java クライアン
- Thrift server (※)(Ruby, C++, etc)
- REST server
- Native C/C++ client scheduled for 0.20 release
・MapReduce用TableInput/TableOutputFormat
- HBase が MapReduce の元データ
・Hbase Shell
- データ取得、追加、スキャン、管理用Jruby シェル

(※「Threift server」:Thrift is a software framework for scalable cross-language services

-19-

HBase 拡張

・Hive, Pig, Cascading
- 次期Hbase統合のHadoop用のMapReduceツール
・Pigi
- Hbase ORM はindex、join、検索、ページング、順序付けを含む
・subRecord
- ストレージと統合されたインフラを提供。セキュリティ、ロギング、評価指標、Hbaseのモニタリング
・ Hbase-Writer
- Heritrix はHbaseテーブルを直接クロールする

-20-

HBaseの歴史

・2006年11月
- GoogleがBigTableの論文を発表
・2007年2月
- 最初のHbaseのプロトタイプがHadoop contribとして作成される
・2007年10月
- 最初の利用可能なHbase
・2008年1月
- Hadoop がトップレベルプロジェクトになり、Hbaseがサブプロジェクトになる
・2008年10月
- Hbase 0.18.1 リリース

-21-

現在のプロジェクトステータス

・最新リリース：HBase 0.18.1 on Hadoop 0.18.2
- 8番目のHBaseリリース
- スケーラブルで安定なバージョンリリース
・もうすぐリリース：HBase 0.19.0 on Hadoop 0.19.0
- マスター障害時に小さなデータの消失もない機能をHDFSに加える（最大100この編集ミスに対して3万の履歴)
- メモリ利用の効率化とリソースモニタリングについての大規模な改修
・その次のリリース: HBase 0.20.0 on Hadoop 0.20.0 (March 2009)
- 新しいHDFSファイルフォーマット「TFile」
- SPOF(Single Point of Failer)をなくす：ZooKeeper がマルチマスターを実現
-大量のランダムアクセスに対する改善
- インメモリー、キャッシュ容量の拡張

-22-

HBase の使われているところ

・Streamy
・Powerset
- Birthplace of HBase
- Home of Michael Stack, project lead
・Mahalo
・The Shopping Engine @ Tokenizer.org
・Advanced Threats Research @ Trend Micro
・Wikia
・Multilingual Archive @ WorldLing
・Also being used in some capacity at:
- Yahoo, Last.fm, Videosurf, and Rapleaf

-23-

Hadoop/HBase > PostgreSQL,MySQL,SQLServer2008,Oracle

質問ある？

-24-

比較１

・ショッピングカートを保存するシステム
- 顧客、製品、注文

-25-

シンプルなSQLスキーマ

CREATE TABLE customers (
customerid UUID PRIMARY KEY,
name TEXT, email TEXT)

CREATE TABLE products (
productid UUID PRIMARY KEY,
name TEXT, price DOUBLE)

CREATE TABLE orders (
orderid UUID PRIMARY KEY,
customerid UUID INDEXED REFERENCES(customers.customerid),
date TIMESTAMP, total DOUBLE)

CREATE TABLE orderproducts (
orderid UUID INDEXED REFERENCES(orders.orderid),
productid UUID REFERENCES(products.productid))

-26-

シンプルなHbaseのスキーマ

CREATE TABLE customers (content, orders)
CREATE TABLE products (content)
CREATE TABLE orders (content, products)

-27-

SQL、HBaseへのクエリ

・顧客用：name,emal,orders取得
・製品用：name,price取得
・注文用：customer,stamp,total取得
・注文用：productのリスト取得

-28-

SQLが得意なこと
・join
- 1つのクエリですべての注文した製品と製品情報を取得
・副次索引
- e-mailからのcustomerid取得
・参照整合性
- 注文を策することで’orderproducts’も削除される
- IDをupdateする際の伝搬
・リアルタイム解析
- GROUP BYやORDER BY は簡易統計解析ができる

-29-

Hbaseが得意なこと

・データスケール
- 100万顧客と100万製品
- 製品情報は大きなテキストデータシートかPDFファイルを含む
- 顧客が製品ページを見た毎回のトラッキング
・Read/Writeスケール
- テーブルはreads/writesノードに完全に分散される
- 書き込みは高速におこなわれ、インデックスのアップデート不要
・レプリケーション
- 自動的に行われる
・バッチ解析
- 大量の複雑なクエリーが連続して効果的にMapReduceの分散ジョブになり、並列して実行される

-30-

結論

・小さなインスタンスのシンプルなシステムであれば、リレーショナルデータベースは構造やデータアクセスのための方法を提供する
- トランザクションやクエリーエンジンンのほとんどの働きはアウトソースできる
- Hbaseはアプリケーションレイヤーに複雑さをもたらす
・拡張の必要があれば、HBaseの特性と柔軟性は、RDBMSでのスケーリングでの悩みを取り除いてくれるでしょう

-31-

比較２

・比較の鍵となる要因
- ハードウェア要件
- 拡張性
- 信頼性
- 使いやすさ
- 費用

-32-

ハードウェア要件
・RDBMSは入出力バウンド
　 - 通常は高速で高価なディスクの大きな配列を必要とする -小さな本番環境は単一ノードで15-30の15k RPMドライブで、16コア、
16?64ギガバイトのRAMが必要かもしれない - 同様の仕様では、バックアップサーバが必要
・Hbaseは一般的なハードウェア用に設計されている
- 最大のパフォーマンス要因はノードの数
- 小さな本番環境では、10-20ノードでそれぞれで2500GB 7.2kRPMのでドライブで、4コアで4GB
- RAIDの１つのマースターノード、デュアルPSU(電源ユニット)、その他、最近ではSPOF

-33-

拡張性

・RDBMSのスケールは以下のもので実現される
- Memcachedによるキャッシング
- パーティショニングは多くの場合アプリケーションか外部ツールに委ねられる
- レプリケーション機能は組み込まれているか、または、有名なRDBMSではアドオンとして提供される
- スケールのメカニズムであるにもかかわらず、アーキテクチャ上効果的なマルチマスターサポートを許容しない
・Hbase はbox外でスケールする
- ランダムアクセスはMemcachedに似た気候によって高速化される(0.20からビルトイン)
- 低速から高速まで同時並行して一定のパフォーマンスを保つ
- 書き込みは分散んされ、インデックスは存在しない
- RegionServerの追加によってスケールがプラグインされる

-34-

信頼性

・RDBMS
- スレーブレプリケーション
- ワーム／ホットバックアップ
- 単一ノードの故障はたびたび致命的となる
・Hbase
- レプリケーションは組み込まれている
- バックアップはできるけど不要。

-35-

使いやすさ

・RDBMS
- 洗練された数100万のSQLとリレーショナルデータモデリング
- 正規化されたスキーマはわかりやすく、予測通りのパフォーマンスを発揮する
- しかし、スキーマはたびたび制限され、変更しにくく、拡張しにくい
・HBaseとMapReduce
- 重要な学修曲線
- 初期の苦労を緩和するため、優れたコミュニティといくつもの使い勝手を良くするツールが増えてきている
- スキーマは緩く定義されているので、データ構造は変更しやすく、パフォーマンスも一定

-36-

その他の要因

・ＯＳ／アーキテクチャ
- RDBMSはターゲットのアーキテクチャによって大きく変わる
- HbaseはLinux用に設計されて、SolarisやWindowsで成功している例もある
・費用
- HbaseはFOSS(Free and Open Source Softuare)
- たくさんの成熟したFOSSのRDBMSはあるが、企業で多く使われているものは高価
・広範な使用
- RDBMSは実証済みである
- HadoopとHbaseはまだ開発中で、まだ本番での広い利用には至っていない

-37-

結論

・2番目と1番目は同じ（？）
・RDBMSは強力な機能を提供しますが、拡張する費用はとても高いです
・Hbaseは必要最小限の機能しかありませんが、少ない費用で拡張できます

-38-

Ubuntu 8.04 LTSでhadoop環境構築

2009-11-29T22:04:00.007+09:00

■javaインストール


$ sudo apt-get install sun-java6-*

■javaのバージョン確認


$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

■sun java使う設定


$ sudo update-alternatives --config java

■phpインストール(hadoop streamingでphpを動かす場合)


$ sudo apt-get install php5 php5-cli

■ユーザー追加


$ sudo adduser hadoop

■ssh_configが変だったので修正（なぜ?）


$ sudo vi /etc/ssh/ssh_config
PermitRootLoginをコメントアウト

■hadoopユーザ設定(パスなしユーザ設定)


$su - hadoop
$ssh-keygen -t rsa -P ""
$cat .ssh/id_rsa.pub >> .ssh/authorized_keys

■パスなしログイン確認


$ ssh localhost

■hadoopダウンロード、展開


$ wget http://www.meisei-u.ac.jp/mirror/apache/dist/hadoop/core/hadoop-0.20.1/hadoop-0.20.1.tar.gz
$ tar xvzf hadoop-0.20.1.tar.gz
$ ln -s hadoop-0.20.1 hadoop
$ vi hadoop/conf/hadoop-env.sh
export JAVA_HOME=/usr/lib/jvm/java-6-sun
$ cd hadoop

■hadoopテスト(シングルモード)


$ mkdir input
$ cp conf/*.xml input
$ bin/hadoop jar hadoop-*-examples.jar grep input output 'dfs[a-z.]+'
$ cat output/*

■hadoopテスト(疑似分散モード)


$ cd hadoop

☆以下のファイル編集


<configuration>
<property>
 <name>fs.default.name</name>
 <value>hdfs://localhost:9000</value>
</property>
</configuration>

conf/hdfs-site.xml:


<configuration>
<property>
 <name>dfs.replication</name>
 <value>1</value>
</property>
</configuration>

conf/mapred-site.xml:


<configuration>
<property>
 <name>mapred.job.tracker</name>
 <value>localhost:9001</value>
</property>
</configuration>

■フォーマット


$ bin/hadoop namenode -format

■起動


$ bin/start-all.sh

■動作確認


NameNode  :http://localhost:50070/
JobTracker:http://localhost:50030/

■起動確認


$ jps
3815 DataNode
3964 JobTracker
4059 TaskTracker
3894 SecondaryNameNode
3736 NameNode
12858 Jps

■テストデータ作成
・サンプルデータ


$ cat /home/hadoop/sample/sample.txt
a b c d e f g
a b c d e f
a b c d e
a b c d
a b c
a b
a

・phpでmap処理：標準入力の文字列を空白で分割して、タブ区切りの行として出力


#!/usr/bin/php
while ( !feof(STDIN) ) {
    $line = trim(fgets(STDIN));
    foreach ( preg_split('/\s+/', $line) as $word ) {
        if ( $word !== '' ) {
            echo "${word}\t1\n";
        }
    }
}
?>

・phpでreduce処理：標準入力の文字列を数え上げる


$ cat /home/hadoop/sample/reduce.php
#!/usr/bin/php
$value ) {
 echo "${key}\t${value}\n";
}
?>

■テスト
・テストデータ登録


$ cd hadoop
$ bin/hadoop fs -put /home/hadoop/sample/sample.txt input

・実行


$ bin/hadoop jar contrib/streaming/hadoop-0.20.1-streaming.jar \
-input input/sample.txt \
-output output_sample \
-mapper 'php /home/hadoop/sample/map.php' \
-reducer 'php /home/hadoop/sample/reduce.php'

・結果表示：単語ごとに出現回数表示


$ bin/hadoop fs -cat output_sample/*
a       7
b       6
c       5
d       4
e       3
f       2
g       1

■ストップ


$ bin/stop-all.sh

クラウドの種類

2009-08-10T21:59:00.002+09:00

パブリッククラウド
サード・パーティー (ベンダー) によって提供されるクラウド・サービス。パブリッククラウドは企業のファイアウォールの外側にあり、クラウド・プロバイダーによって完全にホストおよび管理される。
・メリット
リソースのアウトソース、オンデマンド利用
・デメリット
事業者のインターフェースにあわせる必要性、ガバナンスが効かない

プライベートクラウド
企業内部に提供されるクラウド・サービス。これらのクラウドは企業のファイアウォールの内側にあり、企業によって管理される。
・メリット
リソースの一元化、オンデマンド利用、パブリッククラウドに比べて細かな制御
・デメリット
リソース管理は自社内、運用コストが大きい

ハイブリットクラウド
パブリッククラウドとプライベートクラウドを組み合わせたクラウド。ハイブリッドクラウドは企業が作成し、その管理責任は企業とパブリック・クラウド・プロバイダーとの間で分担される。ハイブリッドクラウドはパブリック・スペースとプライベート・スペース両方のサービスを利用する。
・メリット
パブリッククラウドとプライベートクラウドを適材適所に適用
・デメリット
パブリッククラウドとプライベートクラウドを組み合わせることでの実装、管理の難しさ

バーチャルプライベートクラウド
パブリッククラウド内にプライベートな専用領域を作り出すクラウド。パブリッククラウド内に仮想的な占有領域を作成し、ユーザー企業内の情報システムをVPNで接続する。
・メリット
プライベートを構築できない中小企業でもプライベートクラウドのメリットを享受できる
・デメリット
実験段階で商用事例がない、VPNの提供など事業者の協力が必要

クラウド・コンピューティングの提供形態

2009-08-10T21:57:00.004+09:00

アプリケーション・サービス(SaaS)
ソフトウェア（主にアプリケーションソフトウェア）をネットワーク経由のサービスとして提供・販売。
（例：Gmail 、Yahoo! メールなど）
プラットフォーム・サービス(PaaS)
ソフトウェアを構築および稼動させるための土台となるプラットフォームを、インターネット経由のサービスとして提供。
（例：Amazon Webサービス、Google App Engineなど）
インフラストラクチャー・サービス(IaaS)
コンピュータシステムを構築および稼動させるための基盤（仮想マシンやネットワークなどのインフラ）そのものを、インターネット経由のサービスとして提供。
（例：Amazon EC2、Amazon S3など）

JUnit A Cook's Tour 「4. Conclusion」まとめ的な何か（自分めも）

2009-08-03T00:50:00.001+09:00

・パターン使うとフレームワーク開発とか人に説明するのにベンリだよ！
・パターンが密集してると使いやすいけど、変更しにくいよ！
・でもよくできたフレームワークはパターン密集してるからそっちの方がいいかもね！
・他人に使わせる前に自分で使ったらいいと思うよ！
・フレームワークはシンプルなのが使いやすくていいよね！
・どうしても機能追加したくなったら拡張パッケージにしたらいいと思うよ！
・コード書くよりいっぱいコード読んでね！
・リファクタリング大事だよ！

JUnit A Cook's Tour 4. Conclusion翻訳メモ

2009-08-03T00:28:00.009+09:00

JUnit A Cook's Tour の「4. Conclusion」を雰囲気でほにゃくしてみる。
☆はよくわかんないところ。
ほんやくこんにゃくホシイ。

----

4. Conclusion
4.結論

To conclude, let’s make some general observations:
結論として、全体を見てみましょう

Patterns
パターン

We found discussing the design in terms of patterns to be invaluable, both as we were developing the framework and as we try to explain it to others.
設計をパターンの単位で議論することは、フレームワークの開発とフレームワークを他者に説明する上で有益であることが分かりました。

You are now in a perfect position to judge whether describing a framework with patterns is effective.
あなたは、現在、あるフレームワークが効果的なパターンで記述されているか判断できる最適な立場にあります。

If you liked the discussion above, try the same style of presentation for your own system.
もし上記のような議論が好きなら、自分のシステムのために同じスタイルのプレゼンテーションを試してみてください。

Pattern density
パターンの密度

There is a high pattern "density" around TestCase, which is the key abstraction of JUnit.
TestCaseのまわりには高いパターンの「密度」があります。そして、それはJUnitの鍵となる抽象概念です。

Designs with high pattern density are easier to use but harder to change.
高密度なパターンによる設計は、使いやすいのですが、変更が困難です。

☆We have found that such a high pattern density around key abstractions is common for mature frameworks.
成熟したフレームワークではそういった鍵となる抽象概念による高密度なパターンは一般的であることがわかりました。

☆The opposite should be true of immature frameworks - they should have low pattern density.
反対に、未熟なフレームワークではパターンの密度が低いはずです。

☆Once you discover what problem you are really solving, then you can begin to "compress" the solution, leading to a denser and denser field of patterns where they provide leverage.
いったんあなたが本当に解決したい問題を発見したら、あなたは解決策を圧縮して、パターンが提供する、より高密度な領域に導いてくれます。

Eat your own dog food
あなた自身のドッグフードを食べてください(他人に提供するものはまず自分で試してみましょう)

As soon as we had the base unit testing functionality implemented, we applied it ourselves.
我々は基本単位のテストが機能するところまで実装したらすぐに、我々自身でそれを適用しました。

☆ A TestTest verifies that the framework reports the correct results for errors, successes, and failures.
TestTest(Testインターフェースのためのテスト？)は、フレームワークがエラーや成功、失敗などの適切な結果をレポートすること検証しています。

We found this invaluable as we continued to evolve the design of the framework.
我々がフレームワークのデザインを発展させ続けたので、こういった内容は非常に貴重であるとわかりました。

We found that the most challenging application of JUnit was testing its own behavior.
JUnitで最も挑戦的なアプリケーションは、JUnitがJUnit自体のふるまいをテストしていることであることを見いだしました。

Intersection, not union
交差、結合ではなくて。

There is a temptation in framework development to include every feature you can.
フレームワーク開発では、できるだけいろんな機能を取り込みたいという誘惑があります。

After all, you want to make the framework as valuable as possible.
結局、あなたはフレームワークをできるだけ価値のあるものにしたいのです。

However, there is a counteracting force- developers have to decide to use your framework.
しかし、開発者があなたのフレームワークを使うことを決心させなければならない反作用（ジレンマ？）があります。

The fewer features the framework has, the easier it is to learn, the more likely a developer will use it.
機能が少ないフレームワークは、学習が容易で、開発者に使われやすいでしょう。

JUnit is written in this style.
JUnitは、このスタイルで書かれています。

It implements only those features absolutely essential to running tests- running suites of tests, isolating the execution of tests from each other, and running tests automatically.
JUnitはテストを走らせるために厳選された機能だけを実装しています。それは、テスト１式を走らせること、お互いに独立したテストの実行、自動的にテストを走らせることなどです。

Sure, we couldn’t resist adding some features but we were careful to put them into their own extensions package (test.extensions).
もちろん、私たちは若干の特徴を加えることを抑えることができませんでした。しかし、それは拡張パッケージ(test.extensions)の中に、注意深く取り込みました。

A notable member of this package is a TestDecorator allowing execution of additional code before and after a test.
この拡張パッケージで特筆すべきクラスはTestDecoratorで、TestDecoratorはテストの前後に追加コードを実行できるようにしています。

Framework writers read their code
フレームワークの記述者は、自分のコードを読みます

We spent far more time reading the JUnit code than we spent writing it, and nearly as much time removing duplicate functionality as we spent adding new functionality.
我々がJUnitのコードを読んでいる時間は、JUnitのコードを書いた時間よりも遥かに多くの時間を費やしています。
そして、新しい機能を追加している時間とほとんど同じくらいの時間を重複機能の除去に費やしています。

We experimented aggressively with the design, adding new classes and moving responsibility around in as many different ways as we could imagine.
我々は新しいクラスを加えたり、想像できるあらゆる方法で責務を移動したりして、積極的に設計を試しました。

☆We were rewarded (and are still being rewarded) for our monomania by a continuous flow of insights into JUnit, testing, object design, framework development, and opportunities for further articles.
JUnitへの洞察、テスト、オブジェクトデザイン、フレームワーク開発、そしてさらなるものへのチャンスといった、我々の執拗で継続的継続的なフローによって、我々は恩恵を受けています。（そしてこれからも）

The latest version of JUnit can be downloaded from http://www.junit.org.
JUnitの最新版は、http://www.junit.org.からダウンロードできます。

vmwareでubuntu linuxの設定めも

2009-07-22T22:34:00.012+09:00

windows ホストのvmwareでubuntu linuxをインストールしたました。
ほとんどの設定についてはコチラのサイトがとても詳しいです。
で、java の設定はコチラで。

その他設定メモ

sshは２がデフォルトらしいので、ttsshは使えない(PuTTY ごった煮版を利用)
sshの設定はrootログインだけ拒否して、認証はとりあえずパスワード認証で。
SDカードに入れたのでShrinkは40分ぐらいかかった
ターミナル上はディレクトリ名は日本語よりもやっぱり英語にしといた方が楽
windowsで作ったソースは文字化けするのでiconvで変換とかが必要そう
ファイル転送はとりあえずwinscpで。（sambaはめんどくさそうなので後でやる)

メモメモ

中央区の地価地図 1995-2023 — 国土数値情報で同じ19地点の28年を可視化

同じ中央区で、地価は23倍ちがう

1995年を超えたのは、19地点のうち3地点だけ

再開発の中心でも、6割弱

全地点の「底」が、2004〜2005年に集中していた

「地点が増えると比較にならない」という落とし穴

データの扱いで気をつけたこと

技術メモ

東急線 全98駅の乗降客数トレンドマップ — 国土数値情報で2011〜2024年度を可視化

コロナ禍の落ち込みと、その後

「回復度」を色分けするのをやめた話

データの扱いで気をつけたこと

技術メモ

毎朝84万人が千代田区へ — 2010・2015・2020年の国勢調査で通勤者数を市区町村別に可視化

きっかけ

見えてきたこと

2020年データの読み方

使い方

生成AI用語集 - MoE・Thinking・Reasoningなど主要概念まとめ

モデルアーキテクチャ関連

MoE（Mixture of Experts）

Transformer

パラメータ数

推論・思考関連

Reasoning（リーズニング）

Chain-of-Thought（CoT）

Thinking / Extended Thinking

System 1 / System 2

学習・ファインチューニング関連

RLHF（Reinforcement Learning from Human Feedback）

Constitutional AI

LoRA（Low-Rank Adaptation）

応用・インターフェース関連

RAG（Retrieval-Augmented Generation）

Agent / AIエージェント

MCP（Model Context Protocol）

評価・品質関連

Hallucination（ハルシネーション）

Benchmark（ベンチマーク）

まとめ

都道府県別の時給相場が一目でわかる無料ツール — 47都道府県×4業種の市場相場を最低賃金と比較

このツールでできること — 提案時給の市場競争力を即座に判定

主な機能 — 47都道府県×4業種に対応

4段階評価の判定基準

データソース — 厚労省「賃金構造基本統計調査」をベース

データの算出方法と注意点

使い方 — 業界選択と時給入力の2ステップ

Mac初期設定履歴

このブログについて

読書：プロジェクトのトラブル解決大全

ヤフーファイナンスの数値を理解する - 詳細情報 - 参考指標 - EPS/BPS

ヤフーファイナンスの数値を理解する - 詳細情報 - 参考指標

ヤフーファイナンスの数値を理解する - 詳細情報

Hadoop and HBase vs RDBMS メモ

Ubuntu 8.04 LTSでhadoop環境構築

クラウドの種類

クラウド・コンピューティングの提供形態

JUnit A Cook's Tour 「4. Conclusion」まとめ的な何か（自分めも）

JUnit A Cook's Tour 4. Conclusion翻訳メモ

vmwareでubuntu linuxの設定めも

東急線全98駅の乗降客数トレンドマップ — 国土数値情報で2011〜2024年度を可視化