ABC124感想

2週連続で参加しました。

atcoder.jp

A感想

同じ場合と違う場合で場合分けすればよさそう。3分でAC。

B感想

螺旋本の最初に乗っている例題とだいたい同じもの。5分でAC。

C感想

010101…か101010…の2パターンしかないのでどっちかを計算すればよい。 もう片方は文字列の長さから引けば算出できる。 12分でAC。

D感想

問題文を読み違えていて、気づいたのが30分後くらいだったのでそのままギブアップ。とはいえ読み直しても無理でしたね……。

Dは問題文もそれなりに複雑な気がするので焦らずじっくり問題文を理解すべきと思いました。

全般感想

20分でCまでACできたのは満足。Dはこれからですね。

D解きなおし

解説のPDFを読んで方針を確認して実装しました。方針がわかれば実装は素直にできる気がします。

Submission #4969555 - AtCoder Beginner Contest 124

D問題は、以下の3つを考えるのが大事だと思いました。

おまけ

最近勢いがすごいんですけど何があったんでしょうか?

ABC123感想

AtCoderのテストを久しぶりに解きました。

atcoder.jp

どれくらい久しぶりかというと、この記事を書いたときぶりで、今年に入って初です。

alek3.hatenablog.com

結果

A~Cの3完でした。Cにてこずりすぎたかなと思いつつも、自分にとっての最低ラインである3完は死守したのでよしとします。

A感想

最近のAの中だと割と難しい気がします。3分でAC。

B感想

料理の注文時間の1の位に着目すればよいが、それを完全に理解するのにやや時間がかかりました。 10分でAC。

C感想

ボトルネックとなる一番輸送能力の低い交通機関にのみ着目すればよいということはパッと見で分かりました。

しかし、割り切れる割り切れないの場合分けを忘れていて、3WAを出してしましました。

10分で最初の提出、そこからACまで25分かかりました。

D感想

本番中は、実装方針を考えましたが、アルゴリズム書けなさそうとみてギブアップ。

解説のPDFを見て、方針②なら簡単に実装できそうと思い、改めて解きなおしてみました。

Submission #4880342 - AtCoder Beginner Contest 123

秒数はギリギリでしたが、一発AC。

解法①や②はアルゴリズムをほとんど使っていませんね。それでもDが解けるかもしれないと判明したのは収穫でした。

今後に向けて

6月末*1までに、

  • Rate800↑
  • ABC4完

を目標に頑張りたいと思います。

アルゴリズムはこちらで勉強していきます。

蟻本で挫折したのでもう少し簡単そうなものにしました。

ちなみにIDは「alkwest」です。なんでこんな名前にしたかというと、alekからちょっと変化を加えたかったからです。正直かなり名前変えたいですが、チャンスが1回しかないそうなのでまだいいかという気持ちです。

*1:時期に意味はないけどあんまりダラダラやっててもしょうがないということで

レビュー『ブロックチェーンアプリケーション開発の教科書』

サラッと読んだところでレビューします。

目次

  1. ブロックチェーンとは?
  2. ブロックチェーン技術の理解
  3. ブロックチェーンアプリケーションの理解
  4. ブロックチェーンプロダクトの比較
  5. ビジネスへの応用
  6. アプリケーション開発の基礎知識
  7. Solidityによるアプリケーション開発
  8. アプリケーション開発のフレームワーク
  9. アプリケーション設計の注意点
  10. 技術的課題と解決策
  11. ブロックチェーン技術の未来

どんな本か

  • 説明は幅広い
  • コードの記載量は多くない

「WEBアプリケーション開発の教科書」という本が巷では出回っていないのは、現代のWEBアプリケーションは高度に細分化されているため、最低限の知識でさえ網羅しようとすると何千ページにもなってしまうからでしょう。

しかしながら、ブロックチェーンについては、少なくともブロックチェーンそのものの開発をするわけでないのなら、まだギリギリこのようなコンセプトの本も成立するのではと思います。

コードは時間が経てば古くなってしまって使いづらくなってしまいそうですが、概念については変わらないので、そこについては有用であり続けると思います。

レベル感については、1冊目とするには少し厳しい気がしていて、読み物的な入門書を1冊挟んでから取り掛かるのがいいかもしれません。

扱われていないもの

実際のコードについては、7章と8章でしか扱われていません。また、Solidity*1と書かれている通り、Ethereumのことが記載されていて、他の基盤については具体的なコードの記載はありません。

また、ブロックチェーンの活用方法も、仮想通貨などのパブリックブロックチェーンに関するそれが中心で、パーミッションブロックチェーンについてはあまり記載されていないように見えます*2

おまけ

完全に個人の感想ですが、ユースケースについてはもっと「おおっ」と唸るような例がもうちょっとほしいなと思いました。

また、ブロックチェーンでがっつりコーディングにページを割いた書籍は出づらいと思いますので、諦めて自分で書いて学んだり、書いている人に話を聞いたりするしかないと思います。

*1:Ethereumで用いるスマートコントラクト開発言語

*2:厳密にはブロックチェーンでない基盤もあるのでそれはそうという感じもある

読了『まんがでわかるLinux シス管系女子②』

積んでいたのをようやく崩しました。

本書は「まんがでわかるLinux シス管系女子」シリーズの第二巻で、第一巻を引き継ぎ、より複雑なシェルスクリプトを書く方法や、コマンドを叩いたりするのに必要なコマンドが紹介されています。

古びない知識

記載内容の初出は2013年~2015年です。扱う内容はLinuxコマンドであったりシェルスクリプトであったりするので、現在でもそのまま使えるでしょう。

ユースケースベースの利点

1巻からそのスタイルは変わっていないのですが、「こんなことできたらいいな」というユースケースからスタートしています。

なので、私のような初学者でも、実際の業務で試してみようという気分になってきます。*1

トピック

以下の二つのトピックは重点的に取り上げられています。

正規表現はそれ単体でも使われますが、取り上げられているfindやsedと一緒に使われているケースが紹介されています。

標準入出力は、例えば引数入力の代替手段としての標準入力が紹介されていますした。

他にも、while文、case、continue / breakなど、プログラミング言語であれば始めのほうに出てくる話が2巻の後半で集中するのは興味深いです。

体系的書籍への道筋

作中では10行前後のスクリプトが書かれていますが、それ以上の複雑な内容になってくると、マンガでカバーするのは難しくなっていくように思います。

なので、この後はもう少し体系的な書籍へ進むのが上達に有効なのかなと。

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界

一応持ってますけど例によって積読です。

気になるところ

本筋とはあまり関係ないのですが、いまのみんとちゃんのようにゴリゴリにスクリプトを組んでいくと、「秘伝のタレ」化しないか少し心配なのですが、世の中のシス管現場はどうなっているですかね?

目次

最後に目次を挙げます。

  • 第1話 定期的に行う作業を自動実行したい
    • crontab
  • 第2話 鍵認証で安全にログインしたい
    • 公開鍵認証
  • 第3話 定時処理で自動的にscpしたい
  • 第4話 複数のサーバーのファイルを効率よく収集したい
  • 第5話 条件に当てはまるログの行数を集計したい
    • wcと算術展開
  • 第6話 複数のテキストファイルを一括編集したい
  • 第7話 表記が一定でない語句をまとめて置換したい
  • 第8話 正規表現のパターン指定をもっと簡潔にしたい
    • 大文字小文字の違いの無視と文字の範囲指定
  • 第9話 正規表現のパターン指定をさらに簡潔にしたい
    • 範囲外の文字の指定と行頭・行末の指定
  • 第10話 古い日付のファイルを探して消したい
    • find
  • 第11話 もっと複雑な条件でファイルを探したい
    • findの複雑な検索条件
  • 第12話 ディスクが満杯になる前にファイルを削除したい
    • dfと数値の大小での条件分岐
  • 第13話 前のコマンドが成功したら次も実行したい
    • ANDリスト
  • 第14話 前のコマンドが失敗したら次を実行したい
    • ORリスト
  • 第15話 親ディレクトリーにいちいち戻る操作を省略したい
    • サブシェル
  • 第16話 3パターン以上の場合分けをしたい
    • case
  • 第17話 社員番号の最初の方の文字で処理を振り分けたい
    • caseのパターン指定
  • 第18話 同じ処理を1時間繰り返し実行したい
    • whileループとsleep
  • 第19話 コマンドの出力をパイプラインで受け取りたい
  • 標準入力とread
  • 第20話 スペース混じりのファイル名もループ処理したい
    • whileループとread
  • 第21話 キーボードからの入力を待ち受けたい
    • readからの入力待ち
  • 第22話 キーボードからの入力を確認の後でやり直したい
    • continueとbreak
  • 第23話 コマンドのすべての出力をファイルに保存したい
  • 第23.5話 ユーザー作成用コマンドの違いを把握したい
    • useraddとadduserとuserdelとdeluser

おまけ

『まんがでわかるLinuxシス管系女子①』まとめたった - 等身大から1割増し

まんがでわかるLinux シス管系女子3 がめっちゃイイ - 等身大から1割増し

*1:例えば、自分の場合だとスクリプトの標準入力についてちゃんと見直してみようと思いました。

きっと読むほどうまい『失敗から学ぶ RDBの正しい歩き方』

『失敗から学ぶ RDBの正しい歩き方』を読みました。

失敗から学ぶ RDBの正しい歩き方:書籍案内|技術評論社

要約

  • RDBを扱う上で気にすべきことが幅広く書いてあります。
  • 挙げられたトピックは頭に叩き込んでおくべき。

取り扱われないもの

タイトルで「RDBの歩き方」とあるようにNoSQLのようなデータベースはチラッと登場するのみです。

また、本文中ではMySQLPostgreSQLの例がほとんどであり、RDBMSの比較については、あまり扱われません。ただ、種類の違いを意識することの重要性は説明されています。

さらに、この書籍は20のアンチパターンの列挙で構成されていますが、それぞれに対して「アンチパターンを生まないためには?」というアンサーを記載しています。しかし、『SQLアンチパターン』のような直接的な「解決策」を明示していないように思えました。

例えば第5章「フラグの闇」では、削除フラグというアンチパターンが紹介されています。そこでの記載がこちら。

このように、テーブルに状態をもたせてしまった場合、その対処方法に銀の弾丸はありませんのでご注意ください。

もう一つ挙げます。

しかしテーブルに状態を持たせると、何らかの理由でそれをリファクタリングする必要が出た場合に困難を極めます。

なかなか冷や汗出ますね。この章に限らず、RDBに関して誤った設計をしてしまうと、取り戻すのが非常に大変ということが読み取れました。

カバーする範囲の広さ

この本の最大の特長は、カバーする範囲の広さにあると思います。例えば、開発と運用両方をカバーしています。

  • 開発(テーブル設計):第1章~第2章、第4章~第9章、第15章、第20章
  • 開発(テーブル設計以外):第3章、第13章~第14章、第16章~第17章
  • 運用:第10章~第12章、第18章~第19章*1

テーブル設計以外とは、具体的に言うとクエリとロックとキャッシュです。*2

わずか300ページ弱の書籍ですが、RDBを扱う上で頻出、かつ影響度が大きいポイントはほぼ網羅されているのでは、と思いました。

読む、試す、また読むのサイクル

この本を読んで、自分には刺さるところが多くありました。第5章「フラグの闇」、第8章「JSONの甘い罠」、第11章「見られないエラーログ」などです。

内容の細かいところまで暗記するのは難しいにしても、少なくともデータベース設計や運用を考える際に、本書で取り上げられたテーマはパッと浮かぶべきだと思いました。

また、この本を読んで得られた気付きに基づき、今関わっているシステムを改善しようと思います。そのうえで、また本書に戻ってくるとさらなる学びがあるに違いありません。

まとめ

RDBを使っているなら読んでおくといいと思います。

また、本文中でいくつかSlideshareのリンクが貼られているので、電子書籍を買ったほうがいいかもしれません。

私は紙の書籍を買ってしまったので、URLを頑張って手動で打ち込みます……。

*1:12章までが連載部分でそれ以降が描き下ろしなのでこのように分割されているっぽい。ひとまとめにしたほうが読みやすかった気もしますが

*2:INDEXはテーブル設計の方に入れてあります

『暗号技術入門』よりメッセージ認証コード、デジタル署名について

結城浩『暗号技術入門第3版 秘密の国のアリス』の一部をまとめました。

メッセージ認証コード・デジタル署名は、どちらもメッセージが書き換えられていないことを示す正真性(完全性)を確保するためや、メッセージが正しい送信者からのものであることを示す認証を実現するために用いられます。

一方、無関係な第三者に漏洩しないという、機密性を確保することはできません。

メッセージ認証コードとは

Message Authentication Code で、MACともいわれます。

コードというと第一印象は何かしらの文字列ですが、そうではなく

鍵に依存した一方向ハッシュ関数

です。メッセージをそのハッシュ関数にかけると、MAC値が得られます。

実際の使い方は以下になります。

  1. 送信者アリスと、受信者ボブは、同じ鍵を持っているとします。

  2. アリスは鍵を使い、メッセージのMAC値を計算します。

  3. アリスはメッセージとMAC値をボブに送信します。

  4. ボブはメッセージと自分が持つ鍵からMAC値を計算し、両者が一致すれば認証成功です。

デジタル署名とは

単語のイメージからは、自分の名前をサインしたものをデジタル上で表現するものと思われます。

実際は、自らの秘密鍵で暗号化したメッセージ*1そのものです。メッセージ全体が暗号化されることがあります。逆に、メッセージ自体は暗号化しない場合のデジタル署名をクリア署名といいます。

簡単に、デジタル署名の使用手順を記載します。

  1. 送信者アリスは、一方向ハッシュ関数*2でメッセージのハッシュ値を計算します。

  2. アリスは、自分の秘密鍵ハッシュ値を暗号化します。これが署名になります。

  3. アリスは、メッセージを署名を受信者ボブに送信します。

  4. ボブは、受信した署名をアリスの公開鍵で復号し、ハッシュ値を得ます。

  5. ボブは、受信したメッセージからハッシュ値を計算し、前の手順から得たハッシュ値と比較します。両者が一致すれば認証成功です。

メッセージ認証コードと、デジタル署名は役割や使い方が近いことが分かります。

メッセージ認証コードと、デジタル署名の使い分け

メッセージ認証コードは、第三者による証明と、否認防止ができません*3。一方、デジタル署名は誰でも検証できますし、否認防止ができます。

ならば、デジタル署名はメッセージ認証コードの上位互換なのでしょうか。

おそらくそれは違っていて、理由は対称暗号が公開鍵暗号より優れているポイントと同じです。

すなわちパフォーマンスが違います。

とはいえここからは個人の感想ですが、デジタル署名はハッシュ値に対して暗号化をかけているわけだし、パフォーマンスもそこまで問題にならなさそうな気がします。

*1:もしくはハッシュ化したメッセージを暗号化したもの

*2:鍵に依存しないのでメッセージ認証コードで使っているものとは別物

*3:どちらも、送信者と受信者が同じ鍵を持つので、どっちかそれを使ったかが証明できないため

HackerRankというサービスに登録した

とある縁でHackerRankというサイトに登録したので説明しようと思います。

どんなサイトか?

www.hackerrank.com

Practice coding, prepare for interviews, and get hired.

とあるようにプログラミングの練習問題、コーディング試験対策、求人応募ができます。しかし、求人応募はアメリカと一部のヨーロッパに限られます。

サイトはすべて英語です。

練習問題

登録すると、ダッシュボードにテーマ別の練習問題が表示されます。一番左の「Problrem Solving」が一番豊富にそろっている印象。 f:id:alek3:20190303152118p:plain

解き始めると、ダッシュボードで進捗が表示されます。たくさん解くとレベルアップする感じでしょうかね。 f:id:alek3:20190303152008p:plain

問題の特色

ブラウザ上にコードを貼って、解答を提出するのですが、標準入出力については、すでにコードが記載されています。

なので、回答者である我々は、問題を解くロジックのみを考えればよいことになります。

まとめ

プログラミングの問題を解答できるサイトは、AtCoderやPaizaなど、様々なものがあると思いますが、以下のニーズに対してはHackerRankが適していると思います。

最後については補足が必要ですが、WEB上でコーディングテストを受ける際に、このサイトが使われいているそうです。

参考

他のレビュー投稿です。

HackerRankのアルゴリズム厳選20問でコーディング面接をハックする - 港区で苦しむデータサイエンティストのメモ帳

HackerRankでプログラミングを勉強する - Qiita

HackerRankで問題を解いてみよう! - Takahiro Octopress Blog

*1:ただし、サイトを見た感じC、C++JavaPythonRubyJavaScriptしかないような感じがする