先日出先で桃色の花が目に入って
桜？いやいやいやいやまだ季節が早い？梅？桃？なんていいながら近寄ってみたところ「河津桜」と表記がありました。
一足早く1月から2月にかけて咲く桜とのこと。
先週はやはり出先で虹を見ました。
足元まではっきりしている虹をみるなんて何年ぶりだろう。
ちょっと明るい気分にもなれたし
ブログのネタにもなっていただこうって思ったのですが
これだけで引き延ばすのはむつかしいですね。
カテゴリー別アーカイブ: コラム
プログラミング小噺三題
スタティックメソッドはどうですか
ちょっと、仕事プログラムで1つのファイルが肥大化傾向があって、「Java クラス 分割」というキーワードでググってみた。
そもそもJavaってのはクラスを分割して書けないという融通の利かない言語で、割と常識的なこととか初心者向けのことを書いてるページが並ぶ。
『何をクラス分割の指針とすべきか』（https://iwamototakashi.hatenadiary.jp/entry/20090530/p1）に書いてあるLCOM (Lack of Cohesion in Methods) ってのが面白い。
元ネタはITmedia。
で、常々失敗したOOPプログラムに接していると、いかに変数を減らすか、いかにインスタンスを減らすかばかり考えているわけですよ、最近は。
で、先程のページの
『ちなみにインスタンス変数のないクラスは、ほぼ不要であると個人的には思っています。そのようなクラスは、
スタティックメソッドの集まりになるのでしょうが：Static methods are procedural! In OO language stick to OO. And as far as Math.abs(-5) goes, I think Java got it wrong.
I really want to write -5.abs(). Ruby got that one right. Static Methods are Death to Testabilityという Miško Hevery 氏の意見(http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/)に私は賛成です。』
なんてことを読んじゃうと、喧嘩売ってんのかと思う。いやまぁ、勝手に読んでるのは私ですが。10年も前の記事なんで、今でも同じ考えとは限らないなと思う。
例に上がってるMath.abs(-5)の書き方は重要ですよ。これ、どっからでも呼べますから。
色々考えて最近はDBのテーブルアクセスは全部スタティックメソッドにしてる。SampleTbl.Record rec = SampleTbl.getById(String id)って感じ。
OOP的な意味では全てファクトリですよ。ファクトリしかないのだから全部スタティックメソッド。
レコードは普通にクラスなんで好きにすればいいけど、本質的にはget/setしかない。
で、SampleTbl.getByIdはコード上どこからでも好きに呼べるのが重要。誰がDBアクセスインスタンスを持ってるかとか気にしない。
そういうのは基本戦略としてメソッド内に封じ込める。
まぁ、スタティックメソッドの集まりに価値のある応用もあるってこと。
あと、Math.abs(-5)を先に作って、-5.abs()は最終的にMath.abs(-5)を呼ぶというような実装もよくやる。逆ではない。
私も関数型言語に触れるまではスタティックメソッドを活用しようとはあまり思わなかった。この10年でだいぶコードの書き方が変わった。
モンティ・ホール問題
三つの選択肢のどれかが当り。出題者はどれが当りか知っている。
回答者が選択した一つ以外の残り二つから出題者がはずれを選んで開ける。
さて、回答者は選択を維持するか変えるかどっちが有利か。これがモンティ・ホール問題。
モンティ・ホール問題が納得いかなくて、なるべく愚直にプログラムを書いてみようかと思い、
具体的にどう書こうかと考えてる間に納得してしまった。でもPythonで一応愚直に書いてみた。
「モンティ・ホール問題 プログラム」でググると似たような愚直なプログラムを書いた人は結構いるので掲載はしない。
Ubuntu 18.04のカスタマイズ
最近Ubuntuを使いにくいなぁと思っていた。問題はGUIで上にバッテリーステータスや日付表示されるパネルのフォントサイズを変更できなかったからだ。
UbuntuがUnityをやめてGNOME 3に移行したことで、どうやって設定変更したら良いのかわからなくなったのだ。VAIO Pro 11は割と画面解像度が高いので、
そのままでは非常に小さい文字しか表示されない。FirefoxやTerminalは個別にフォントサイズを大きくできるのでいいのだが、パネルに表示される日付やらバッテリー残量やらアプリのメニューやらは小さいまま。Unityの頃はディスプレイ画面のdpiを指定することで全体の文字サイズを調整できたのだがそういった機能はなくなったようだ。Kotlinのお試しのためVAIOを活用しようかなと思い、ちょっとググる。
GNOME 3のExtensionでUser Themesを有効にする。~/.themesに独自テーマのディレクトリを用意し、~/.themes/<テーマ名>/gnome-shell/gnome-shell.cssを作る。
# gnome-shell.css
stage {
font-size: 18pt;
}Tweaksの[外観 – テーマ – GNOME Shell]で上記<テーマ名>を選ぶ。
これでようやくGNOME 3のパネルの文字が読めるようになる。ともかく老眼には厳しい話だ。
GNOME 3のウィンドウマネージャはMutterというそうだ。dconf-editorでorg.gnome.mutterに幾つか設定がある。
edge-tilingをオフにすると、Ubuntu 18.04でかなりイライラさせられる「ウィンドウを移動させたいだけなのに、
上に持っていくと最大サイズにされてしまう」という問題が解消する。あぁ、嬉しい。
Ubuntuを起動したまま放置すると例えば30分でブランクスクリーンになるように設定している。
マウスを動かしたりするとブランクスクリーンを解除するのだが、Unityの頃にはなかった変な画面になっている。
真ん中にドカンと時計が表示されるロック画面とは違う謎画面。この画面の解除にはキーボード入力を要求する。いや、正確ではないな。
マウスで解除する方法はあるにはあるが、タッチスクリーンにおけるスワイプアップ相当の動きをマウスで行う必要がある。
これ決めた人は明らかに変。どう考えてもおかしい。キーボードくらい押せばいいとか思うでしょ。マシンを落とす（パワーオフにする）にはメニューから電源オフをするのが正しい手順で、
キーボードがなくてもちゃんと行える。逆に、キーボードに電源ボタンがない限り、キーボードだけでマシンを落とす方法はUIには用意されていない。
ノートパソコンはキーボードの近くに電源ボタンがあるからマシだが、デスクトップ機の電源を落とすのに電源ボタンを押すなんてことは普通しない。
という状況にも拘わらずキーボードを要求する、GNOMEは。とにかくストレス。
GNOME Shell Extensionsに「Disable Screen Shield」というツールがあると知る。
その邪魔な画面はScreen Shieldというらしい。これを無効にしてくれる。あぁ、嬉しい。そもそもScreen Shield自体がオプトインにすべき機能だろうに、
更にはオプトアウトすら用意していない。「GNOME Screen Shield」でググると世界中で迷惑がられてます。
IT化が進むロンドン、変わったものと変わらないもの
海外展示会情報第2回目は、展示会の内容から少し離れてロンドンの情報をお伝えしようと思います。筆者自体、約10年ぶりのロンドンでしたが、色々な変化した点を感じられました。
まずヒースロー空港で驚いたのはかなり自動化が進んでいることです。日本の空港を出発する際もパスポートのスキャンなど一部は自動化されていましたが、スタンプを押すところは職員の方がやっていました。しかしヒースロー空港に着くと、入国審査はすべて自動化ゲートで、税関も申告するものが無ければ素通りです。（ただし自動化ゲートを利用できるのは日本や韓国、オーストラリアなど一部の国のパスポートのみです）
また預け荷物が出てくるのも早く、入国審査が5分ほどで終わったにも関わらず、受け取り場所に行ったら、すでに荷物が流れていました。このスピードはおそらく羽田や成田空港よりも早いのではと思います。
パスポートにスタンプが押されないのはちょっと寂しい気もしますが、スピーディーで英会話の必要もありません。
レストランも自動化が進んでおり、キャッシュレスなのは当然ながら、注文をスマートフォンアプリで行うお店もありました。アプリ上で「店舗を選択」、「テーブル番号を入力」、「料理を注文」、「カードで決済」すれば後は料理が来るのを待つだけ、ほとんどウェイターと接することはありません。英語を話すのは料理が運ばれて来た時の「Thank you」くらいです。
ITテクノロジーによって、どんどん海外へ行くハードルは下がってきているようです。
ただ、レンガの壁と赤い屋根の家並みや、2階建てバス、まあまあの味のイギリス料理など、変わっていない点もたくさんありました（笑）
デスクトップ製品の複数ライセンスがいろいろ変わります（2020年1月24日以降）
複数ライセンスにはライセンスファイルが必要です
これまでのアンテナハウス社製デスクトップ製品は、インストール時に「シリアル」番号の入力が必要でした。シングルライセンス、複数ライセンス（以前はサイトライセンスと呼んでいました）とも同様でした。
2020年1月24日発売の新しい「瞬簡PDF」シリーズから、複数ライセンスでご利用のお客様はライセンスファイルが必要になります。対象製品は下記の通りです。
- 『瞬簡PDF 統合版 12』
- 『瞬簡PDF 書けまっせ 8』
- 『瞬簡PDF 変換 11』
- 『瞬簡PDF 作成 9』
- 『瞬簡PDF 編集 9』
弊社の担当窓口からお送りする納品物には、ライセンスファイルとライセンスファイルの登録の方法が書かれたファイルが含まれています。
バージョンアップ時の注意点
2020年1月24日発売の新しい「瞬簡PDF」シリーズにバージョンアップされる複数ライセンスのお客様には、お客様専用のライセンスファイルをお送りいたします。ライセンスファイルの導入方法につきましては、CD-ROMまたはダウンロードファイルに含まれている「ライセンス登録ガイド」をご覧ください。
その他にもいろいろ変わります！
2020年1月24日発売の新しい「瞬簡PDF」シリーズから、保守サービスの仕様を変更させていただきました。詳細は下記のリンク先をご覧ください。
複数ライセンスの詳細は下記をご覧ください。
遂に民法改正施行！ 請負や準委任契約の見直し済みましたか？
従来のひな形契約に直接かかわる請負及び準委任に関する改正民法への対応について検討が必要です。主な論点としては、以下の通りです。詳細及び対応した他の事項については、各社の顧問弁護士に確認いただくか、専門家にご相談ください。
補足：本ブログ内容は、株式会社ｅ－ＳＯＬ（https://e-sol.tokyo/）の許可を以って転載したものです。
１ 有償契約における規律の一本化
改正前民法においては、売買契約と請負契約でそれぞれ瑕疵担保責任の規定を置いていたが、 改正後民法においては、基本的に売買の 契約不適合責任の規定を準用する（ 改正後民法 第 559条） ことで売買と同様の規律が及ぶものとし、請負契約において売買と重複する規定等を削除して規定を整理している。
２「瑕疵担保責任」から「契約不適合責任」へ
改正前民法では、仕事の目的物に「瑕疵」があった場合に請負人が所定の責任を負うとされているが、 改正後民法では、目的物が種類 、品質 又は数量 に関して「契約の内容に適合しない」場合に責任を負う 、と表現が変更されている。
３ 契約不適合責任に基づく救済手段
（１）「修補」から「履行の追完」へ
改正前民法における瑕疵担保責任に基づく注文者による救済手段は瑕疵修補請求、損害賠償請求、解除 の 3つであったが、今回の改正でこのうち瑕疵修補請求にかかる改正前民法第 634条が削除され、請負についても売買契約の契約不適合責任に関する規定がする規定が準用準用されることになる結果、注文者は瑕疵修補請求に相当するものとして「履行の追完」請求ができることとなった（改正後民法第法第559条に基づく第条に基づく第562条の準用）。
（２）報酬減額請求権の追加
改正民法においては、契約不適合責任に基づく救済手段として、履行の追完請求、損害賠償請求、解除に加え、報酬減額請求が追加された（ 改正後民法 559条に基づく第563条の準用。 ）。
（３）債務不履行一般の損害賠償請求及び解除の規定の適用
改正前民法においては、瑕疵担保責任に基づく損害賠償及び解除が独自の条文として置かれていたが、改正後民法においては、当該条文が削除され、債務不履行一般の損害賠償※３及び解除※４の条文が適用されるようになった（改正後民法 第 559条、第 564条）。 これは、準用元である売買契約の契約不適合責任について、引き渡された目的物が契約の内容に適合しないことを債務不履行と位置付けたことによるものである。
（４）契約不適合責任の期間制限
改正前民法 の瑕疵担保責任では、仕事の目的物に瑕疵があったときは、注文者は目的物の引渡し（引渡しを要しないときは仕事の終了時）から 1年以内に瑕疵の修補、契約の解除又は損害賠償請求をしなければならないとされている。
詳しくは下記をご覧ください。
https://e-sol.tokyo/blog_articles/20200121.html
『PDF CookBook 第4巻』が完成。アマゾンから1月9日発売予定です。
『PDF CookBook』シリーズ初版は完結しました。
2018年から刊行してきました『PDF CookBook』シリーズの第4巻ができあがり、アマゾンPODでの発売準備が整いました。現在、予約受付中で2020年1月9より発売となります。いま、予約注文すると1月10日に届くようです。
※画像をクリックするとアマゾンの本書を紹介するページを開きます。
概要
『PDF CookBook』シリーズは、電子の紙PDFを企業向けのシステムで編集・加工する方法を紹介するシリーズ本です。いわば、PDFをメイン素材とする料理本です。第4巻では、第1章 注釈の情報取得・作成・編集・削除、第2章 FDF 文書のインポートとエクスポート、第3章 PDFの添付ファイル、第4章 画像のPDF化、第5章 PDFファイルの情報設定と取得、第6章 PDFの開き方、第7章 文書の保存、第8章 座標系オプションをテーマとして、全体で51項目のトピックを紹介しています。
目次
はじめに
第1章 注釈
1.1 注釈の作成・編集
1.1.1 ラバースタンプ注釈の作成
1.1.2 カスタムスタンプ注釈作成 (画像・PDF設定)
1.1.3 カスタムスタンプ注釈作成（日付のスタンプ)
1.1.4 リンク注釈の追加
1.1.5 テキスト注釈の作成
1.1.6 テキスト注釈のアイコンを設定する
1.1.7 ファイル添付注釈の作成
1.1.8 ハイライト注釈の作成
1.1.9 ハイライト注釈：テキスト検索
1.1.10 注釈を塗りつぶすための内部色の取得と設定
1.2 注釈の情報取得
1.2.1 注釈の個数・全ての注釈に共通した項目の情報を取得
1.2.2 マークアップ注釈の情報を取得
1.2.3 注釈タイプの判別をして特有の情報を取得する
1.3 注釈の削除
1.3.1 注釈の削除
第2章 注釈のインポートとエクスポート
2.1 FDFファイルを用いた注釈データ処理
2.1.1 注釈情報をFDFファイルにエクスポート
2.1.2 FDFファイルの注釈情報をインポート
2.2 PDFファイルを用いた注釈データ処理
2.2.1 PDFファイルからの注釈データインポート
第3章 PDFの添付ファイル
3.1 添付ファイルの情報取得・添付・書き出し・削除
3.1.1 添付ファイル情報の取得
3.1.2 ファイルの添付
3.1.3 添付ファイルの書き出し
3.1.4 添付ファイルの削除
第4章 画像のPDF化
4.1 画像からPDFのページを作成する
4.1.1 ページの作成
4.1.2 画像パラメータの指定
4.1.3 ページの大きさを選択
4.1.4 ページの大きさを指定する
4.1.5 画像の配置矩形を設定する
4.1.6 余白の指定
4.2 画像へのマスク処理
4.2.1 カラーキーマスクを施した画像のPDF化
4.2.2 明示マスクを施した画像のPDF化
4.2.3 ソフトマスクを施した画像のPDF化
4.2.4 ステンシルマスクで描画した画像のPDF化
4.3 既存PDFへPDF化した画像を挿入する
4.3.1 既存PDFへ画像から作成したページを挿入する
第5章 PDFの開き方
5.1 PDFの開き方の各種設定
5.1.1 PDFを開いた時の動作
5.1.2 ページモード・ページレイアウトの指定
5.1.3 UIオプションの設定
5.1.4 ウィンドウオプションの設定
5.1.5 タイトルバーへの文書タイトル表示の有無を選択する
5.1.6 開き方設定の削除
第6章 文書の保存
6.1 文書の保存形態の種類
6.1.1 リニアライズ保存
6.1.2 増分更新による保存
第7章 PDFファイルの情報設定と取得
7.1 PDFファイルの情報取得・設定
7.1.1 文書情報の取得
7.1.2 文書情報の設定
7.2 カスタムプロパティ
7.2.1 独自の項目名を持つカスタムプロパティの設定
7.2.2 カスタムプロパティの削除
7.3 PDFファイルの判定
7.3.1 署名付きPDFかどうかを取得
7.3.2 PDF/Aかどうかを取得
7.3.3 PDF/Xかどうかを取得
7.3.4 ページモード、ページレイアウト情報の有無を判定する
7.3.5 Web 表示用に最適化されているか否かを判定する
第8章 座標系オプション
8.1 座標系オプションの変更
8.1.1 原点の位置と座標の単位の変更
8.1.2 座標系の種類の変更
索引
書誌情報（プリントオンデマンド）
出版社: アンテナハウスCAS電子出版
発売日：2019年1月9日
著者：アンテナハウス株式会社
発行形式：（冊子本）プリントオンデマンド版
サイズ：B5判 横組み
ページ数：142ページ（表紙を除く）
価格（税込）：1,760円（本体：1,600円）
ISBN：978-4-900552-71-5
販売店：アマゾン
シリーズ既刊本紹介ページへのリンク
『PDF CookBook』シリーズ初版は、第1巻～第4巻までで完結となります。
・『PDF CookBook』
・『PDF CookBook 第2巻』
・『PDF CookBook 第3巻』
ユーザーサポート
ユーザーサポート担当です。
先日、久しぶりに地元のマラソン大会に参加してきました。
タイムは散々でしたが、穏やかな秋の日差しの下、たくさんの声援に元気づけられ気持ちのよいゴールを切ることができました。
大会は参加人数が千人にも満たない小さなものでしたが、地域の人たちがたくさんボランティアで参加されていて、また沿道ではお年寄りからお孫さんまで家族総出と思えるような人たちからもランナーに応援をいただき、心温まるものがありました。
勝手な思い込みかも知れませんが、この日ばかりは地域全体が「ランナー・ファースト」で、目一杯のおもてなしをいただいたような気がしました。
マラソンで思い浮かぶのは、来年の東京オリンピックのマラソン・競歩の会場変更を巡るここ最近の騒動です。
本番まで１年を切った段階で東京から札幌に会場が変更されたのも驚きですが、その理由が「アスリート・ファースト」にあると聞いて更に驚いてしまいました。
今回のオリンピックは、猛暑の時期の開催や米国のテレビ放映に合わせた競技スケジュールなど、当初から「アスリート・ファースト」ならぬ「マネー・ファースト」の都合しか感じられず、選手へのリスペクトはどこかに置き忘れられているといったら言い過ぎでしょうか？
もとより、へぼいランナーが小さな大会で感じる喜びと、トップアスリートがオリンピックで得られる栄誉では比較にならないでしょう。
しかし、オリンピックと前述のささやかなマラソン大会とは、規模の差こそあれ、競技の場を提供して選手を集め、選手も観客も共に競技を楽しもうとするところでは共通点があると思います。
その上で、前述の大会にあってオリンピックにないものがあるとすれば、それはやはり選手を迎え入れる側の、利益優先でなく選手優先で考え応援しようとする心のありどころのように思えてなりません。
やや強引ではありますが、私たちも製品をお客様に提供して対価を得る営利企業として、競技大会の主催者に似た立場にあるのではないかと考えます。
利益優先の考えではなく、お客様のニーズを汲み上げ役に立つ製品を開発してお客様に喜んでいただくことが結果的に利益にもつながるのではないかと思います。
今後も「カスタマー・ファースト」で丁寧なサポートを心がけて行きますので、よろしくお願いいたします。
生活習慣病対策に、インターバル速歩を実践しよう
ここに紹介しているのは、『ウォーキングの科学 10歳若返る、本当に効果的な歩き方』（能勢 博著、ブルーバックス、2019年10月発行）に書かれていることです。高齢化社会に向けてたいへん参考になりそうなので、紹介します。
まず、「インターバル速歩とは、本人がややきついと感じる早歩きと、ゆっくり歩きを3分間ずつ交互に繰り返すというウォーキング方法である。それを1日5セット、週4回以上繰り返すと、5か月間で体力が20%向上する」という。（まえがき）
具体的にインターバル速歩は次のように実践します。
・軽い運動のできる服装で底が柔らかく踵にクッション性のある靴を選ぶ。
・視線は25m先に向けて、背筋を伸ばした姿勢で歩く。
・できるだけ大股であるく。腕を振ると良い。
・スピードは「ややきつい」と感じる程度。5分間あるけば息が弾み、動悸がする程度。
・速歩の時間は3分を基準とする。
これを週4回以上繰り返す。週合計で速歩きの時間が60分になるようにする。5か月繰り返せば効果がでる。（pp.97-98）
30歳を過ぎると男女を問わず体力が少しずつ低下する。これは、加齢による筋力の低下が原因である。（pp.27-28）
最近は、体力の低下が高血圧、糖尿病、肥満といった生活習慣病の原因になると考えられるようになった。生活習慣病にとどまらず、認知症やがんに至るまで、中高年特有の疾患の根本原因は、加齢性筋減少症に伴う体力の低下である可能性が高い（p.28)。
体力の低下を防ぐために、1日1万歩歩くというような方法が勧められているが、松本市の「松本市熟年体育大学」事業に著者が協力した中で、その効果の検証を行ったところ、体力の向上はほとんど見られなかった。これはおそらく、普通に歩くだけでは運動の強度が弱すぎるためだろう。（pp.51-52）
現在の通常の筋力トレーニングは、アスリートや若者向けに考えられているものが多く、中高年は採用しにくい。また、マシンを使ったトレーニングは効果があるが、時間の制約やコストが大きすぎてゆとりのない人には採用しにくい。（pp.59-62）
著者たちが考え出した「インターバル速歩」は実践しやすいのが特徴である。例えば、きつい速足を30分間やってほしいというとみな逃げてしまい、継続できない。（p.211）
それに対してインターバル速歩は定着率が高い。つまり、継続してやれるのである。（pp.113-116）
インターバル速歩を実践した結果として、最高酸素消費量などの指標でみる体力が上がる。体力が上がると生活習慣病の指数が下がる。生活習慣病は体力強化で予防できるだろう。（p.74）
本書には、実験による効果検証のデータがたくさん出てきており、科学的な検証を行っているところが非常に良いと考えられます。詳しく知りたい人は、ぜひ、本書をお読みください。
11月14日（木）Markdownセミナー開催日が迫りました。
今週の木曜日に新宿・大久保にてMarkdownのセミナーを計画しています。
セミナーのご案内はこちらより：
「Markdown + CSS/TeXで冊子本を作ってみた 」
まだ席に余裕がありますので、関心をお持ちの方はぜひご参加ください。
本セミナーでアンテナハウスからは『簡単！ Markdown＋CSSによる冊子本作り―理論と実践』という冊子を制作した体験を主として説明致します。
Markdownの文法については、冊子ではグルーバーの元祖Markdownを基本にしていましたが、その後、他の文法も調べたところ、現時点ではCommonMarkの方が標準として適切と判断するにいたりましたので、セミナーではCommonMarkの文法を基本にご説明いたします。
CommonMarkと元祖Markdownの違い
CommonMarkは、グルーバーのMarkdownの考え方に基づいて、これをより厳格に規定しようという提案です。
2019年9月現在、CommonMark Version 0.29が公開されています。仕様書はジョン・マクファーレン氏（カリフォルニア大学バークレー校哲学教授。汎用マークアップ変換ツールPandocの開発者でもあります。）によるものです。CommonMarkは、元祖Markdownの規定が曖昧な箇所を明確化し、規定に不備がある箇所を補っています。元祖Markdownの考え方を尊重しながらも、元祖Markdownの規定では不合理と考えられる箇所については、説明を付けた上で元祖Markdownとは異なる規定を導入している箇所があります。
MarkdownはASCII句読点文字と空白や空行の組み合わせを使ってマークアップしたテキストをタグで表現した構造化文書に変換します。その際の解釈の一元性を保つ必要があります。例えば、ASCII句読点文字がマークアップ用なのか地のテキストの一部なのか、二つの用途のどちらを優先して解釈するか、などを細かく決めなければなりません。このため、CommonMarkの規則はかなり複雑になっています。CommonMarkでは元祖Markdownのマークアップ機能を基本としながらも、マークアップの付け方や解釈を大幅に強化しています。マークアップに使用するASCII句読点文字は同じでありながら、その使用方法と解釈が大幅に変更になっているものがあります。
CommonMarkの仕様にある文法は非常に微に入り細を穿っています。そのためエンドユーザがCommonMarkの規則を覚えて使うのは困難であり、仕様書はエンドユーザ向けというよりもMarkdown処理系の開発者向けといえます。エンドユーザはリアルタイム・プレビューアを使ってマークアップを解釈した結果を、HTML表示で確認しながらマークアップしていくのが良いでしょう。
追加されたマークアップ機能
CommonMarkは、元祖Markdownの機能をいくつか拡張しています。元祖Markdownのマークアップ機能に対して、CommonMarkで追加された機能は、①コードフェンス、②番号付き箇条書きの区切り記号を元祖Markdownの ‘.’ のみに加えて ‘)’ を使用可能に、③ショートカット型の参照リンクの追加、④強制改行文字の追加です。
| 構造 | HTML要素 | マークアップ文字 | 例 |
|---|---|---|---|
| コードフェンス | pre code | ```または~~~で囲まれた範囲 |
```
|
| 番号付き箇条書きの区切り文字 | ol li | 数字＋’)’＋空白で番号付き箇条書き | 1) 番号箇条項目 |
| 参照リンク（ショートカット型） | a href=”” | [リンクテキスト] 別の箇所に [リンクテキスト]: /uri |
[foo] 別の箇所に [foo]: /uri “title” |
| 強制改行 | br | 強制改行したい行末に ‘\’ | この行末に強制改行\ |
第二回技術書同人誌博覧会に出店します。
毎日お疲れ様です。
本日は電子出版サービスグループが担当します。
アンテナハウスが「アンテナハウスCAS電子出版」でプリントオンデマンド出版している技術書は、10冊以上あります。製品マニュアルを含めると倍くらいでしょうか。
「技術書」に関する少部数（同人誌）即売会が定期的に開催されるようになって、はや数年。
かの「技術書典」が初めて開催されてから、もう7回目を迎え、開催するごとに規模を増しているのを見て、実は技術者開発者って、自分の知識や技術を外に出したい、新知識や新技術を取り込みたい、意見交換したいんだなと思いました。
わたしですか？
わたしはPCでテレビが見られてネットサーフィンできればオールオッケー！ストレスなく使えていればよい、根っからのコンシューマ（一般消費者）です。
それはさておき、技術書に絞った同人誌即売会に新しい会が生まれ、12月14日、第2回目が開催されることになりました。
第二回技術書同人誌博覧会
技術書典（抽選）とは違い、早い者勝ちなので、我がアンテナハウスは申し込み開始日に電光石火の勢いで応募しました！
今月の半ばから入場チケットの申し込みが出来るようになるそうなので、そろそろサイトページができるころかもしれません。
売り子の社長が面白いことを言っていました。
技術書典は最近、時間を区切り、概ね午前中（～13時まで）は有料チケット購入者だけが入れるようにし、午後の時間帯は無料開場するという方針を取っています。
（技術書同人誌博覧会も同じ様式ですが、無料チケットになります。）
さて、売り上げ結果はというと、チケットを購入した人が会場を回っている時間帯のほうが大きく、逆に午後の無料開放時間帯、来場者数は多いですが、驚くほど売り上げが少なかったということでした。
売り子から見る「客」の質は、チケットを購入した来場者のほうが圧倒的に高かったことがわかります。よく考えればわかることですが、面白いですよね。。
今回の会も、同じ現象が起きそうです。
第二回技術書同人誌博覧会、12月14日（土）、プラザマーム（アンテナハウスブース：3階-た04）で開催です。
お見逃しなく！そしてご来場・ご来店をお待ちしております！
技術書同人誌博覧会公式サイト：https://gishohaku.dev/
一般参加のご案内：https://blog.gishohaku.dev/entry/gishohaku2-attend
＠技術書同人誌博覧会 運営事務局