答えのない問題に挑む心構え - 超ウィザード級ハッカーのたのしみ
「答えのない問題」と呼ばれる種類の問題があります。この種類の問題に取り組む仕事は、過重労働のイメージが強い。その理由が問題の構造にあることに気づいたので記録しておく。 まず答えのない問題について説明します。答えのない問題とは、明確な解決策や結論が存在しなかったり、主観性の違いにより一意の答えが存在しない問題のことです。明らかな答えはなくて、人によって言うことが変わるような問題です。例えば広告のクリエイティブだったり、ビジネス上の戦略立案や意思決定に関する問題、投資判断の問題は、答えがない問題です。どんな広告を出したらいいかに唯一の正解はないし、企業の戦略も唯一の正解があるわけではありませんね。 『左利きのエレン』で描かれている広告会社のクリエイティブの人たちとか、コンサルタントの人たちの SNS とか眺めていると、彼らの仕事はハードワークの印象が強い。やりがいが強く夢中になれる仕事だから、
あなたの感想が聞きたい - 超ウィザード級ハッカーのたのしみ
それってあなたの感想ですよね？ このフレーズは、ひろゆきの言葉として有名です。このフレーズだけ聞くと、感想だからだめだというようにも聞こえますが、感想を述べること大切だと私は考えています。 もちろん、ひろゆきが感想を持つべきではないと言っているわけではありません。彼の言いたかったことは、意見と事実の混同を避け、それぞれをきちんと識別しましょうということでした。意見と事実の区別は議論における基本的なスキルで、事実の裏付けがない意見は説得力を欠きます。 しかし、自分の意見を持つことは重要です。意見を持つことは、ポジションを持つとも言います。上司に対して「どうしましょう？」という相談を持ちかけたとき、「君はどうしたいの？」と聞き返されることは皆さんも経験があるのではないでしょうか。それは、自分の意見を表明してほしいというリクエストです。 その一方で、意見を持つことは、しんどいと感じることもあるで
ChatGPT と主体性 - 超ウィザード級ハッカーのたのしみ
ChatGPTが私の人間に対する価値観を変えている。人より賢いAIが実際に存在するとわかると、どのように人間があるべきか悩む。ChatGPTを使えば、大量のテキストをほとんど手間なく作成できるため、私がわざわざ文章を書く価値はないと思うが、逆にChatGPTに刺激されて、ものを書きたくなるのが不思議だ。 さて、ChatGPTは、主体性がないがとても優秀なアシスタントのようなものだ。言われたことには、必ずすぐに何か返答する。こちらの作業指示が悪くて間違う場合もあるが、フィードバックを与えて修正を促せる。逆に聞いていないことは答えないので、ChatGPTのアウトプットがこちらの想像を超えることはない。 ChatGPTは、私を含めて大半の人より賢いので、人に頼むよりChatGPTと会話している方が有意義だとよく思う。ChatGPTには主体性がなく、報連相ができないため、分からなかったことを「分か
いつも間違っている人への対処法 - 超ウィザード級ハッカーのたのしみ
間違いを減らす方法を考えていて、ある程度以上はどうしようもないという役に立たない結論を得たのだったのだが、過激だったのか、意図せずアクセスが増えてしまった。単に苦労していますだけの内容を多く読まれても困るなと、一回取り下げて書き足しました。 間違いの減らし方を こちら に書きました。 仕事をしていると、必ず間違いを提出してくる人に出会ったことはないでしょうか？私は何度も悲しい思いをしており、そういう人にはもう仕事は頼めないと、非情ですが早々に判断するようにしています。 少なくともソフトウェア開発の世界では、正確さに大きな価値が置かれています。この業界だけでなく、一般的に、間違いは欠陥か事故であり、基本的に許されないものです。仕事は、紙の試験ではないため、百点満点が当たり前です。タクシーに乗ったら、事故せずに必ずつくことを期待する。手術で手が滑ることや、車を運転して信号を見間違えることは許さ
ChatGPT とわたし - 超ウィザード級ハッカーのたのしみ
ChatGPT の登場には脳天を雷で撃たれたかのような衝撃が走りました。世間の多くの人が ChatGPT に驚いて興奮しているのは知っていますが、私も同じように感動を覚えています。技術的にや社会的に見て ChatGPT の何がすごいのかは、私が述べるまでもないですが、私にとって ChatGPT がどうすごいのかは、言語化したほうがいいと思ったので書きます。 AI が仕事を奪うとか、シンギュラリティだとか、言っている人もポジショントークで言っているだけで、本気で信じているとは思ってませんでした。例えば投資を集めるために、ストーリーとして面白いから語られていただけで、実際信じてないんだろうと冷ややかに見ていました。 しかし、ChatGPT を見せられると、冷ややかというか冷静ではいられません。産業的なインパクトは分かりましたが、それ以上に価値観が揺らぎます。私が大切だと信じて努力してきたものの
順問題と逆問題 - 超ウィザード級ハッカーのたのしみ
「順問題」と「逆問題」という新しいことばを知りました。英語でいうと direct problem, inverse problem です。例えば、入出力系を考えたときに、入力から出力を求めるのが順問題で、出力から入力を推定したり、入力に対して求められる出力を実現する系を考えたりするのを逆問題と呼ぶそうです。算数の問題だけでなくて、広く「問題解決 problem-solving」といわれる一般的な問題にあてはめると、こうやったらどうなるかを求めるのが順問題、こうなるためにはどうするかを求めるのが逆問題です。 例えば下のようなのが例としてあげられるでしょうか。 順問題 - 演算、構造計算、実験、検査、推論 逆問題 - 設計、プログラミング、計画、証明、詰将棋 厳密に区別できるものではないです。順問題で、こうやったらどうなるかを求めるには、実際にやってみるというのが一つの良いやりかたですが、どう
論理的思考とはパターン認識である - 超ウィザード級ハッカーのたのしみ
語っていることの辻褄があっているとか、矛盾がないとか、整合性が取れている状態を論理的と言います。意思決定や問題を解きたいときなど、正しさに重きが置かれる場面では、論理的であることを求められます。論理的整合性が取れていないものは誤っている可能性が高く、根拠が弱かったり話の辻褄があっていない意見は、正しいことを求めるところではだいたい無視されるでしょう。ただし偉い人が言ったら別ですけど。 議論が論理的か非論理的かは、話を聞く人が判断しますが、われわれはどうやって話の筋が通っているかどうかを判断しているんでしょうか。現実にはもっと大雑把にやっていますけど、理想的な場面を仮定して、数学の証明のように推論規則を守っているかをひとつずつ確認しているとしましょう。ひとつの文が論理的に妥当化どうかって、わたしたちはどうやって判断していますかね。見たら分かるとしか答えようがないと思うんですよね。 例えば「A
結合の種類と結合度 - 超ウィザード級ハッカーのたのしみ
先日に発見したモジュールの結合の定義を自身でも気に入ったので、よく知られている結合の種類をこの定義に当てはめてみようと思います。 Coupling (computer programming) - Wikipedia モジュールの結合にはいくつかの種類がありまして、以下のものが知られています。 内部結合 content coupling 共通結合 common coupling 外部結合 external coupling 制御結合 control coupling スタンプ結合 stamp coupling (data-structured coupling) データ結合 data coupling 名前が変だし、それぞれの関係性も分かりづらいので、この分類はあまり好きではないのですが、他のもっと良い分類をしらないので、とりあえずこれを使います。 モジュール の モジュール に対する結合
疎結合の正体見たり - 超ウィザード級ハッカーのたのしみ
モジュールが疎結合になっているとか密結合になっているとか、業界にいますとよく聞きます。モジュール間の結合度の定義を発見したのでメモしておきます。 モジュール の モジュール に対する結合度 は以下の式で定義できます。 ここで、 は が に対して持つ仮定の集合、 は仮定 が成立しなくなる確率です。 要するに、これは情報エントロピーを用いて結合度を定義しようとしていまして、 は0以上の値を取り、結合度の値が大きいほどモジュール間の結合が密となります。 そもそも、モジュール間の結合度というものが定義されていなかったので、その定義を発見したことに意味があります。 さらに、この定義が便利なのは有名な設計原則を説明できてしまうことです。以下のようなものを聞いたことがあると思います。 デルメル原則 リスコフの置換原則 ハリウッド原則 驚き最小の原則 これらはだいたい同じことを言っています。依存する側が持
シェルスクリプトのキモいところ - 超ウィザード級ハッカーのたのしみ
シェルスクリプトのインタプリタを作ろうかと、シェルスクリプトの仕様を調べています。気持ちの悪い仕様をいくつか見つけました。仕様書*1を見ながら、dash で試しました。 丸括弧と波括弧のふるまいが違う。 丸括弧はサブシェル、波括弧はコマンドのグルーピングをするための似たような文法ですが、ふるまいが異なるので戸惑います。 $ (echo hello) hello 丸括弧はコマンドの前後にスペースも要らず、丸括弧内のコマンドが実行されます。 $ {echo hello} {echo: not found $ { echo hello } Syntax error: end of file unexpected (expecting "}") $ { echo hello; } hello しかし、波括弧はコマンドの前にスペースか改行をを入れて、コマンドの後ろにはセミコロンか改行を入れる必要があ
Bloom Filter を作ってみた - 超ウィザード級ハッカーのたのしみ
Bloom Filter を実装してみた。簡単な実装なので、速度や空間効率は悪いです。 Bloom Filter というのは、確率的データ構造の一つで、ある要素が集合に含まれるかどうかを試験するものです。空間効率が非常に良いのが利点で、偽陽性、つまり集合に含まれない要素もあるとしてしまう場合があるという欠点があります。偽陰性はありません。 以下が実装例です。 import hashlib import math class BloomFilter: def __init__(self, num_item, false_positive): assert 0 <= false_positive <= 1 # Optimal number of bit array size and hash function # https://en.wikipedia.org/wiki/Bloom_filt
異常時にちゃんと止まるシェルスクリプト - 超ウィザード級ハッカーのたのしみ
自動化は大切ですが、自動化するときは異常時にちゃんと止まるようにしなければなりません。トヨタ自動車でいうところのニンベンのついた「自働化」である。なぜ自働化が必要かというと、エラー時に止まってくれない機械は稼働中に人が張り付いて見守っていなければならないからです。また、エラーが起こったのちに機械が動き続けるならば、異常なアウトプットが出力され続けることになり、異常なアウトプットを処理しなければならないというムダが発生します。自動化のためのスクリプトを書くときは、エラー時には止まるように作らなければなりません。 しかしながら、シェルスクリプトは恐ろしいことにエラーが起きても既定ではそのまま処理を続けていきます。異常時にちゃんと止まる自働化スクリプトとするためには以下をスクリプトの先頭に書くと良いでしょう。 set -eu -o pipefail trap 'echo "ERROR: line
クラスの依存関係グラフ - 超ウィザード級ハッカーのたのしみ
Java のクラスの依存関係を調べてみた。 規模が大きいアプリケーションの方が統計が取りやすいので、Apache Hadoop の 3.0.0-alpha バージョンを対象に調べる。テストとアノテーションを除いた、Hadoop 由良のパッケージに含まれるクラスに依存関係のグラフについて調査する。 クラス間の依存関係を調べるのに、JDK8 に含まれる jdeps というコマンドを使った。jdeps に -verbose オプションをつけると 各 jar 内のクラスが依存しているクラスが出力される。-dotoutput オプションで DOT ファイルに結果を保存することができる。下のようなファイルが出力される。 digraph "hadoop-mapreduce-client-common-3.0.0-alpha1.jar" { // Path: ./mapreduce/hadoop-mapr
Bash で Power Assert 風のものを作った - 超ウィザード級ハッカーのたのしみ
GitHub - fjkz/power-assert-bash: Power Assert for Bash Bash で Power Assert 風のものを作りました。*1 なぜか Bash には assert がありません。なので、 Bash でテストを書くときは、 set -e として、 [ "$actual" == "$expect" ] とか書きます。しかし、これだと失敗したときに、情報がないので困ります。set -x としてもいいのですが、これ欲しくない表示も出て、ウザイのです。また結果も見づらい。Bats もテストのどこでエラーとなったかは教えてくれるが、変数の中身とかは教えてくれません。 そこで、 Power Assert 風のものを作ってみました。 Power Assert とは、Spockに含まれる assert の結果を美しく表示してくれる機能です。 . power
CAP定理について - 超ウィザード級ハッカーのたのしみ
CAP定理という分散ストレージシステムの設計において非常に重要な定理がある。まだ、以下の元の論文を読んでいないので、正確な理解かどうかは保証できないが、理解している範囲で考えることを記す。 https://www.comp.nus.edu.sg/~gilbert/pubs/BrewersConjecture-SigAct.pdf CAP定理によると、分散システムでは以下の３つを同時に満たすことはできない： Consistency 一貫性、 Availability 可用性、 Partition tolerance 分断耐性。 それぞれ、 all nodes see the same data at the same time, every request receives a response about whether it succeeded or failed, the system
コード型ログ(5) Bashで自分のディレクトリを知る - 超ウィザード級ハッカーのたのしみ
シェルスクリプトで自分のディレクトリを知りたいことがあります。 . ./functions.sh 例えば、上のように他のシェルスクリプトを読み込みたいときに相対パスを使うのはよくないときがあります。なぜならば、./の場所はシェルスクリプトを実行するカレントディレクトリであって、シェルスクリプトのファイルがある場所ではないからです。シェルスクリプトは、どのディレクトリから実行しても動くようにしたいものです。 シェルスクリプトのファイルが存在するディレクトリを知るには以下のようにします。 MYNAME="${BASH_SOURCE:-$0}" MYDIR=$(cd -P -- $(dirname -- "${MYNAME}"); pwd) ${MYNAME}には今のファイルの相対パスが入っています。 ${BASH_SOURCE:-$0}となっているのは、$0にはBash以外では今のファイルの名
ncatで遊んでみる - 超ウィザード級ハッカーのたのしみ
ncatという超便利コマンドを恥ずかしながらいままで知らなかった。HTTPプロトコルを学ぶには最適なおもちゃだ。 www.example.com の 80番ポートに、 / を GET するという HTTP リクエストを投げてみる。 fjk@x240:~$ ncat www.example.com 80 << END GET / HTTP/1.1 Host: www.example.com END すると、以下のような HTTP レスポンスが返ってくる。200番のステータスコードが帰ってきているので、リクエストはうまいこといったようだ。いろいろヘッダーフィールドについているが、こう見ると HTTP プロトコルはテキストを送って返すだけという非常に単純なプロトコルなことが分かる。 HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: max-a
コード型ログ(3) privateなメソッドのテスト - 超ウィザード級ハッカーのたのしみ
前回： コード型ログ(2) staticな変数の排他にはsynchronized(*.class) { } を使う - 超ウィザード級ハッカーのたのしみ privateなメソッドは、ユニットテストがしにくい。 対処法は２つで、 テストしないか、 Reflectionで頑張るか、 スコープをpackage pririveteに広げるか、 である。 呼び出しものの入出力からテストができるのであれば、無理してテストをする必要はない。 しかし、わざわざ別のメソッドに分けたということは、入力と出力の対応が明確な単位になっているはずなので、テストしたい。 Reflectionで頑張る場合は、例えば class Add { private static int add(int a, int b) { return a + b; } } を呼ぶには、 static int invokeAdd(int a,
コード型ログ(1) スレッドを止めるにはinterruptを使う - 超ウィザード級ハッカーのたのしみ
他の人が書いていたら読めるけれども、知らなければ書けない定型的なソースコードの型を集めているので気が向いたら書いていく。ダジャレが好きなので、コード型ログと呼ぶ。今回は１回目。 無限ループを持つスレッドはinterrupt()で止められるようにする。 package org.example.katalog; public class InterruptSample { public static void main(String[] args) { Thread t = new Thread() { @Override public void run() { // interruptされるまで、"Hello world"を出力し続ける。 // なお、isInterrupted()は呼ぶとフラグがクリアされてfalseになる。 while (!isInterrupted()) { Syste
可読性に関するソフトウェアメトリクスを考えた - 超ウィザード級ハッカーのたのしみ
新しいソフトウェアメトリクスを思いつきました。 ソフトウェアメトリクスとは、ソフトウェアの特性を推定するための定量値のことです。バグの数とかレビューの時間とか開発の過程で得られる値もありますし、テストの数だとかカバレージといったテストを評価する値もあります。ソースコード自体から測定されるものとしては、LOC (Line Of Code)やCyclomatic Complexityがよく知られています。それぞれ、ソースコードの規模・複雑さを示すものです。*1 近年では、ソフトウェアの特性としてソースコードの可読性が重要視されるようになっています。ソースコードは書く時間よりも読まれる時間の方が長い。読むための労力が少ないソースコードは、生産性を向上させ、バグも少なくなります。 可読性を高めるためには、適切な名付けやコメント、明快な処理のフローが必要です。名付けやコメントについては、数値化するこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
