Because We Love Happy Coding

フリーライターがPHPとかJavaとか勉強してます

「増分バックアップ」「差分バックアップ」の違いは英語の方が覚えやすい

先に結論

  • 「増分バックアップ」「差分バックアップ」という日本語は、仕組みの実情を正しく伝えていなくて覚えづらい。訳語が悪い
  • incremental backupは「漸増バックアップ」の方が良い
  • defferential backup は「基準差バックアップ」にしてはどうか。

「増分」と「差分」の区別がつかない

バックアップにはいくつか種類がある。たとえば情報技術者試験などでも問題になるのが、「増分」とか「差分」の違いだ。

これらの違いについては、まぁ詳しいサイトがいっぱいあるのでそちらを読んでいただきたい。

中身はともかく、私はいつも、名前がどっちがどっちだかいつもわからなくなる。「増分」と「差分」。わかりづらい。

調べていたら、「増分」の英語として「incremental」が出て来て膝を打った。それなら、わかる。incrementalは「少しずつ足していく」という意味だからだ。バックアップに「少しずつ足していく」。これなら実情に合っている。

日本語の「増分」という単語には「増える」要素はあるけれど、「少しずつ足していく」というイメージがない。だから分からなくなるのだ。

incremental backupの訳語としては「漸増バックアップ」の方が良いのではないか。

もしかして、私が覚えられないのは、訳語が悪いのではなかろうか!

「日本語のイメージが勝手に付加される」差分=前回からの差

というわけで「差分」の訳語を調べてみたら、こちらはやはり「defferential backup」だった。文字通り「difference 差」ということだから、これは「差分」と言ってもいいだろう。

ただ「差分バックアップ」と言った時に「前回からの差」だと無意識に思ってしまうのは私だけだろうか。差分バックアップは常に「完全バックアップからの差」をとるバックアップなのだ。

そういう意味で、defferential backup は「基準差バックアップ」にしてはどうか。その方が実情を伝えている。

翻訳は「イメージを伝える」作業である。

外国語が苦手な人は逐語訳をしがちだが、翻訳はイメージを伝える作業である。「英単語=日本語単語」という対応が正確であることはあまりない。

例えば「首」という単語を英語にするとしたら何だろうか。neckという語が最初に浮かぶのは自然なことだけれど、実情をよく考えてみると 首=neckではないことがわかる。

「大将の首をとれ」は「head」だ。neckだけとるような戦場はありえない。日本語の「首」のイメージを正しく伝えるには、headとneckを使い分けなければならない。

バックアップも同じで、incremental backup、differential backupのイメージを正しく伝える訳語があれば、大勢の人が効率よく学習できる。

そしてこれは英語に限らず、日本語だって、イメージを正しく伝えることが大事なのだ。

Slack の Botを使いこなしたい

これまでslackに興味はあったものの、友達がいなくて泣いていた。友人が作ったプログラミング部でslackが採用されたので、主導者にいくつか教えてもらい、やっと概略が飲み込めたのでslackの記事もあれこれ読んでみた。

標準SlackBotを使いこなしたい。

標準のSlackBotを面白く使っているアイデアはないかなー、と思って探してみた。

mayonez.jp

↑ここはいろいろまとまっている。

mame-tora.com

↑「おはよ」「おみくじ」あたりまではまぁ思いつく。「おやつ」もあるか。

SlackBotをつくりたくなってくる

Hubotを使ってBotを作るとさらにカスタマイズ度アップ。ただし24時間動く環境が必要。

よく提案されているのはHerokuを使ってホスティングする方法だけど、最近は価格改定で無料アカウントに制限ができちゃったらしい。

さくらのVPSを契約するのも、まぁいいんだけど。

いくつか気になっているのは、GoogleAppsScriptから作る方法があるみたい。これならたぶん無料で、しかも24時間動く。

GitHub - masuidrive/miyamoto: Google Apps Scriptで書かれたSlack用勤怠管理Botの「みやもとさん」

↑ひとり勤怠管理とかやってみっか……。

tech.innovator.jp.net

↑これもGoogleAppsScriptから。

kuma-no-kara-age.hatenablog.com

↑このブログ前にも見たことがある。何度も遭遇するので、たぶん人気記事なんだな。数えるほどしか記事ないみたいだけど。

これはBotKitを使った、とある。

dotnsf.blog.jp

↑ここはけっこう詳しい。

Node.jsが動く環境かぁ。SynologyのNASでやれないかなー。

tech.camph.net

↑これもGoogleAppsScript活用。これならなんかできそうな気がしてきた……!

Java初学者がひっかかっていたところまとめ

1ヶ月ほど初学者に教えた際、ひっかかっていたところをまとめた。何かの参考に。

Eclipseエディタのエラー表記が消えない

セーブしていない

基本。Eclipseのエラー表記は、保存されるタイミングで更新されるので、記述を直しても保存しないとマークが出たままになる。

何かのキャッシュが残ってしまっている

Eclipseでたまにある。ファイルを閉じて開くとエラーが消える。

「変数〜は一度も使われていません」

Eclipseの愛情を感じるエラーというかアラート。初心者向けのソースでは使わない変数でもお作法っぽい理由で変数作っていたりするので、けっこうこれが出てくる。

未完成ソースコード

未完成のソースコードで「エラーやアラートが消えません」と言ってくる事例。そりゃ未完成だからね。書き進めると消える種類のもの。

「〜を変数に解決できません」

以下のケースが多い。

変数の宣言をしていない

基本。

宣言とスコープの問題

これが割と多い。 「宣言した変数はブロック内で有効」ということがまだ飲み込めずエラーになっている。 あるいは逆に上位のブロックで宣言したために、破棄されるべきデータが破棄されず残ってしまい、想定外の挙動をする。

書き間違い

メソッド名に()を付け忘れるなどで変数名と見なされてしまい「〜を変数に解決できません」になる。

「型名を解決できません」

自分で作成したクラスの場合は打ち間違い。

(自分で作成していない)クラス名が与えられている場合は、import忘れが多い。

文字化け

いくつかのパターンがある

文字コード指定がおかしい

文字コードの誤字

「uft8」とかその類型。

req側の指定とres側の指定両方が必要

サーブレットの場合、RequestとResponse両方に文字コード指定が必要。

オブジェクトを直接System.out.printしようとしている

データを保持するEntityオブジェクトをそのまま表示しようとして文字化けする。

JDBC

duplicate PRIMARY KEY

jdbcSQLのINSERT文を実行する際に、「既に存在する主キー」を追加しようとすること。IDの重複など。
例文の通りにINSERT文を打ち込んで、2回(以上)実行しようとするとこれが出る。

引数間違いによるSQLException

サーバー名などの打ち間違いが多い。「locahost」などサラッと書いてあると意外と見つけづらい。

INパラメータ指定

PreparedStatementのINパラメータを指定する際に順番を間違えている。

suitable driver not found

DriverManager.getConnection(url,user,password)で「suitable driver not found」と出る。

getConnection()の第一引数のurlを打ち間違えている

jdbc:」と書くべきところを「jbdc:」と打ち間違えたりすると、「driver not found」になる。

環境設定ミス。クラスパスが何かの原因で通っていない。

これはしんどい。なかなか気づかない。

JSPサーブレット

「formのname属性」「key」「変数名」の混乱

往々にしてベテランは後で見て追いやすいように(サンプルコードも)同じkey名を使い回す傾向がある。慣れた人は文脈を見れば「これが変数名」「これが属性名」などすぐわかるのだけれど、初学者にはどれがどれに対応しているのかわかりづらい。

サンプルコードでユーザーなどの「名前」をデータとして持つ場合が最悪でこんな感じになる。

  • HTML/JSPファイル: formタグのname属性に氏名を入力させ"name"のキーを持たせる
  • httpリクエスト: 格納されているkeyが"name"で値が"山田"
  • サーブレット: request.getParameter(“name”)で取り出した値を入れる変数名がname

name の name が nameである、みたいなことになり、ここを丁寧に説明しないとしんどい。

404エラー

JavaリソースとHTML/JSPのパスの違い。 Javaリソースはアノテーション(またはweb.xml)でパスを指定するため、プロジェクト名の直下がほとんど。HTMLやJSPなどはディレクトリ階層を正しく指定する必要がある。

getParameterとgetAttributeの違い

formから受け取る時は getParameter() 。
setAttribute() したものを受け取るときは getAttribute() 。
getAttribute() のキャスト忘れ/キャストミスもある。

EL式/Beansの形式

${sessionScope.beans.member} のようにドット記法でつなぐのを忘れて、 ${sessionScope.beans} または ${sessionScope.member} のように書いてしまうことが多い。

データベースアクセス専用のPHP設計

f:id:mogami74:20161208124847j:plain

自分のあれこれをデータベースに入れようと思っている。購入物とか、レストランの評価とかあれこれね。いっぱいいっぱい、作りたいデータベースがあるの。

とりあえずレストランについてはPHPで途中まで書いてみてそれなりには動いているんだけれど、ここから改修するのが面倒になってきた。この先、データテーブルが増えるたびに同じような作業をするのはめんどくさい。

というわけで、データベースアクセス専用のPHPを作ったらどうか、と考えた。しかしながら、いま一つ、どういう設計にしたらいいのか、いい考えが浮かばない。

Google先生に伺って、参考になりそうなサイトを見つけた。

blog.tojiru.net

blog.tojiru.net

まさにこれだ。用語がいくつか登場しているので、チェックしておいて後で調べることにする。

とりあえず、ユースケース的なまとまりごとにHogeDAOというクラスを作って、そこにDB操作を集約させることにした。各テーブルを体現するクラスも作成する。

たとえば、RestaurantsDAOクラスはRestaurantsTableクラスとVisitTableクラスを使いながらDBにアクセスする。(本当はStationTableとかMealTableもある)

こんなのもある。

d.hatena.ne.jp

  • Singleton

Singleton パターン - Wikipedia

Singleton パターン(シングルトン・パターン)とは、オブジェクト指向のコンピュータプログラムにおける、デザインパターンの1つである。(中略)Singleton パターンを用いると、そのクラスのインスタンスが1つしか生成されないことを保証することができる。

ふむー。成ル程。

Javaの勉強5

f:id:mogami74:20160225132733j:plain

ラッパークラス

基本データ型を参照型オブジェクトにしたもの。要するに、何でもオブジェクトにしちゃえば、メソッドも付けられて便利だよね、というオブジェクト至上主義ですよね(暴論)。

Autoboxingは、プリミティブ型をラッパークラスに変換する自動処理。

Generics

型を一般化したもの。これも「オブジェクトなら何でも処理しちゃうぜー」というオブジェクト至上主義ってことでいいよね。

こうなると、文字通り「何でもオブジェクト」だよなー。オブジェクト指向は偉大な発明だな。

Javaの勉強4

f:id:mogami74:20160306115355j:plain

クラスパス

-classpath.;c:¥classes セミコロンの意味は、パスの区切りということらしい。この場合、ドットとclassesと2つのパスを指定しているってこと。

例外

一般的例外と業務的例外。一般的例外は、Java上で用意されているもの。業務的例外は、主にユーザー定義例外。

チェック例外と非チェック例外。チェック例外は、外部システムとの境界のような、例外処理が必須になる部分。非チェック例外はシステム内部できちんと潰しておけば例外処理しなくてもいい部分。

Javaの検査例外は、呼び出し側の責任でない異常系 - Qiita

Javaの検査例外は、呼び出し側の責任でない異常系 - Qiita

throws は三単現のs。クラス名に付ける宣言。例外処理を呼び出し元に丸投げする宣言。
throw は命令文。例外をスローする、というヤツ。

実際の授業で「三単現」と「命令文」の話をしたら、同僚の先生に「今のできっとみんな覚えましたね」と誉められたな。

授業では例外処理のイメージを理解してもらうのが難しかったんだけど、「ソフトが強制終了してWindows が謝る」とか「異常終了の内容を送信しますか?ダイアログ」なんかを例外処理の例として挙げたらわかりやすかったかもしれない。

Collection API

Javaの近年のバージョンで追加された、集合を扱うAPIArrayListとか要素追加できて便利ね。

Javaの勉強3

f:id:mogami74:20170611084200j:plain

UML

コンポジション

以下の記事がわかりやすかった。

集約もコンポジションも「全体 - 部分」の関係。 集約は、モデリングする際には無視する(?)。関連と意味合いには変わらないので関連で表現できる。 コンポジションは、1つの部分インスタンスに対して最大1つの全体インスタンスで構成される。 最大1つなので、全体インスタンスの多重度は「0..1」もしくは「1」のどちらかになるはず。 部分インスタンスの譲渡や破棄などの責務を所有している全体インスタンスが担うことができる。 全体インスタンスと部分インスタンスのライフサイクルが完全一致しなくてもよくなった。 --via UMLの集約とコンポジションの違いについて - 目指せ!三流エンジニア

あと、こちらも役に立ちそう。

誤解しがちなモデリングの技:第1回:コンポジションにまつわるアレコレ | 豆蔵ソフト工学ラボ

誘導可能性

可視性と同じような意味で考えればいいのかな?

関連はデフォルトでは双方向性を持ちます。これは、関連から生成される2つのオブジェクトは両方相手を知っており、お互いにメッセージを交換し合うことを意味します。しかし、明らかに片方のオブジェクトからしかメッセージを送る必要がない場合に双方向性を持つとするならば、実装局面においてはプログラムコードに冗長性をもたらすことになります。また、モデルの意味上においても分かりづらさをもたらしてしまいます。このようなときには、関連の端に矢印を書くことで、関連の方向性を明確にします。図13では、明細から商品に向けて矢印を書くことで、明細は商品を知っているが、商品は明細を知らないという意味をモデルに付加しています。こうすることで、商品クラスが明細クラスから独立していることを強調することができます。このように関連の方向性をつけることを誘導可能性と呼びます。 --via 【改訂版】初歩のUML:第6回 「関連」の理解をさらに深める - ITmedia エンタープライズ