「それ、何か言っているようで何も言っていないですよね」って思う
何かの解説、会話、ドキュメントでたまに「それ、何か言っているようで何も言っていないですよね」と指摘することがある。
- 情報量が増えていない
- 抽象化しすぎて本題からズレている
自分がよく見るのは上の2パターンがある。
1. 情報量が増えていない
具体的にはトートロジーになっている。関係ないことをそれっぽく言っている(文章や会話の隙間をただ埋めているだけ)。
2. 抽象化しすぎて本題からズレている
具体的には対象範囲や主語が大きくなりすぎて、本来のトピックについて具体的な話がない。
1はどうでもいいとして、2が需要がある場合もわかる。 でも、2については全体の中で「一度振り返ってみるとこういう目的なのですよ。そのうえでもとのトピックに戻ると、具体的には〜」みたいな話としてちょっと立ち止まって見る程度の話だと思うんですよね。トピックに戻ってからも延々と抽象的な話をするのは、そもそも元のトピックいらないじゃんっていうね。まぁそういうネタならいいんですけど。
- 作者: 木下是雄
- 出版社/メーカー: 中央公論新社
- 発売日: 2016/10/14
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: 結城浩
- 出版社/メーカー: 筑摩書房
- 発売日: 2014/10/10
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
- 作者: 結城浩
- 出版社/メーカー: 筑摩書房
- 発売日: 2014/12/12
- メディア: 文庫
- この商品を含むブログ (15件) を見る
"エンジニアが使うべき便利な windows アプリ一覧" がほしい
誰かが書き始めると、他の人も書いてくれることを祈ってこのエントリを書いている。できるだけ、組織全体で使うツール(チャットツールとか)は選ばないようにした。
エンジニアが使うべき便利な windows アプリ一覧、みたいなのってどっかにまとめないの?
— 徳永広夢 (@tokuhirom) October 2, 2018
- RapidEE
- cmder
- 7-zip
- clibor
- Chrome, Firefox
- Mate Translate
- WinMerge
- Git
- Everything
- Process Explorer などsysinternals系
- Crystal Disk Info
- ここで触れていないけど、実質必須になりそうなもの
RapidEE
Windowsの“環境変数”をGUIで編集できるソフト。各環境変数とその値をツリー形式でわかりやすく表示できるのが特長で、変数や値はツリーの右クリックメニューから追加・削除することが可能。また、値にパスを指定する場合はダイアログを使ってフォルダを選択できるので、編集作業の多くをマウス操作だけで完結でき、編集ミスを起こしにくい。また、無効なパスを赤文字で強調表示する機能を備えているので、入力ミスを一目で見つけることができて便利。過去に指定したパスがソフトのアンインストールなどで無効になった場合にも強調表示されるので、ときどき本ソフトで環境変数を調べれば、無効な値がないか確認できる。そのほか、設定した環境変数をREGファイルとしてバックアップしておくことも可能だ。
cmder
コンソールエミュレータ。最初からフォントがそこそこ設定されているし、便利。
7-zip
解凍、圧縮アプリケーション。いろんな形式に対応しているのと、パスワードなどもかけられる。エクスプローラ上でのコンテキストメニューとも統合できるので便利。
clibor
クリップボード履歴管理。数回前にコピーしたテキストをいつでもペーストできるようになる。便利。自分は、Ctrlを2回連続で叩くとペースト対象を選ぶポップアップがでるようにしている。
Chrome, Firefox
Webブラウザ。普段遣いするのはどちらでもいいと思う。WebGUIアプリケーションを開発するなら、結局両方入れることになると思う。
Mate Translate
翻訳アプリケーション。Chrome, Firefox拡張もあるし、デスクトップアプリケーション、モバイルアプリもある。 Firefox拡張として入れている場合には、英単語を選択すると、日本語翻訳がポップアップされる感じ。
WinMerge
ファイル同士やディレクトリ同士を比較して、ファイルのどの行が違うかが見えるようになる。差分がある行をどちらかにコピーすることもできる。他のDIFFツールやマージツールでもいいんですけど、WinMergeが一番楽な気がする。
そしてこれジオシティーズなので、大丈夫なのかが不安です。
Git
ファイルのバージョン管理ツール。チームで利用するツールなんですけど、Gitは一人でも使えるので、ぜひ入れておいたほうがいい。
Everything
「Everything」高速なファイル検索ソフト - 窓の杜
爆速ファイル名、パス名検索。インクリメンタルサーチに対応しているし便利。
Process Explorer などsysinternals系
sysinternalsはいろんなツールがありますが、とりあえずProcess Explorerは入れておきたい。タスクマネージャーでは出来ないことができます。(Windows10くらいからリソースマネージャーが高機能になってきているからどんどん不要な場面が増えてきて入るものの) 他には、caps lockをctrlにするツールとかもsysinternalsの1つにあります。
Crystal Disk Info
HDDとかSSDの状態のレポーティングツール。できればハードウェア障害は早めに予見したい。
ここで触れていないけど、実質必須になりそうなもの
- テキストエディタ、IDE => 好きなものにしたらいいとおもう。
- チャットツール => 組織に合わせましょう。
- ファイル共有 => 組織に合わせましょう。
- 各種テストツール => もうあげたらキリがない。(これは別立てがいい気がする)
Windows Sysinternals徹底解説 改訂新版 マイクロソフト関連書
- 作者: Mark Russinovich,Aaron Margosis
- 出版社/メーカー: 日経BP社
- 発売日: 2017/09/05
- メディア: Kindle版
- この商品を含むブログを見る
Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール Web制作者のための教科書シリーズ
- 作者: 塩谷啓,紫竹佑騎,原一成,平木聡著
- 出版社/メーカー: インプレス
- 発売日: 2014/11/27
- メディア: Kindle版
- この商品を含むブログを見る
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (7件) を見る
「開発現場で役立たせるための設計原則とパターン」をオススメできない理由
「開発現場で役立たせるための設計原則とパターン」は設計をリードするには悪手である
このエントリーは 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く に対する返答です。 件のエントリーおよびスライドを拝見したときの私の感想は「昔の自分だったらこのようにレクチャーしたであろうけど、いまの私ならこうしない。そして、このようにレクチャーするのは時に問題がある」というものでした。
私は発表を見ていたわけではなかったので、スライドだけを拝見したときにはエントリーとしてまとめるのはどうかと思ったのですが、発表者が丁寧な解説付きの記事をあげてくれていたので、私の考えをまとめるための情報を揃ったと判断した次第です。 そして発表者様のエントリーを読んでも私の感想は変わりませんでした。
まず、件のスライドにおける設計原則の解説自体には問題はなく、サンプルコード付きで解説していることは素晴らしいです。
問題は、設計原則の適用対象が生存期間が短いものになっていることです。これは、ここ20年ではもはや定説とされている「要件はよく変わる」「機能はよく変わる」という問題をそのまま受け継いでいます。つまり、この設計は要件変更に非常に弱い作りです。 ただ、要件変更に弱くてもコストがペイする(ROIが企業としては問題ない)場合もあると思います。私はそのような場面についてはあまり興味はありません。 私が興味があるのは、「変更につよい」とうたう設計とはなにか?という話です。
一応、記事中でも次のような説明があります
「問題によって適切な構造は変わる」
ただ、この文言が出てくるのはずいぶんと後半です。2/3はこれに反したような内容をつらつらと書いています。 仮にこの文言が最も主張したい内容だったとして、つまりそれはどのように実践するのか?についてはまるで解決方法が提示されていません。 これでは「この発表では考慮していませんが、考慮すべき大切なことがあります。(どうやるかは提示しない)」という発表になっています。なんの発表だったんだ。。。
発表の中にでてきた、コメントがどうこうとか、通知がどうこうとかってあきらかに機能の話で、その機能を構造化しても結局変更されるので弱いんですよ。もちろん設計は必要なんですけど、もっと重要な設計が先にあるということです。
まずは普遍的なモノゴトを対象に吟味して設計し、機能の設計はもっと力を抜いて設計したほうが良いです。
よく変更されるような振る舞いについては簡単に書き換えられるようになっているほうが楽だし、そのときに「この機能はこんなに重要だ!」という思い込みによる具象化と抽象化をするのは、いわゆる早すぎる最適化と同じ問題を抱えています。
私のバイアスの話
私はアジャイル開発やメッセージベースオブジェクト指向が好きです。ここの共通テーマは「決定を遅延しながら機能するネットワークを常に作り続ける」ことだと思っています。 そして共通する課題意識が構造というのは人間が計画駆動で生活したいというためのフォースが働いているものであり、私はそれをもっと使いこなす必要があると考えています。(言い過ぎかもしれないけど、構造を決定する必要はほぼないと私は考えている節がある) 少なくともIT業界でアジャイル開発の根本的な概念は広まっていて、要件はよく変わるし、見通せるものではないのだから、常に変化に対応しようとする話があります。 よって、私はこの考え方に反しているとさきの記事を見て思ったのです。(記事の中で「常に考えよう」という姿勢はあるんですけど、対象があまりにも狭いという話です。)
おまけ
では、私は実践できているのか?というと、幾分かは出来ていると考えています。まだ道半ばです。 その道半ばですが、何を考えてソフトウェア開発をしているのか?どのように要件を考えたり、設計をしているのか?というチャレンジの話を今度発表しようと考えています。 公募制なので通るかわかりませんが。公募が通らなかった場合は別の機会に発表しようと思いますので、聞きたい人はお気軽にコメントなりTwitterなり教えてください。
関連書籍
- 作者: クリストファーアレグザンダー,Christopher Alexander,中埜博
- 出版社/メーカー: 鹿島出版会
- 発売日: 2013/09/11
- メディア: 大型本
- この商品を含むブログ (2件) を見る
- 作者: アミーナ・カーン,松浦俊輔
- 出版社/メーカー: 作品社
- 発売日: 2018/05/10
- メディア: 単行本
- この商品を含むブログ (1件) を見る
ScalaMatsuri 2018トレーニングデイの感想。またはチュートリアルがひどかった件
ScalaMatsuri2018というScala言語のカンファレンスに参加してきました。といっても3日間のうちの1日目(というか0日目みたいな位置づけ)のトレーニングデイというものだけですが。 最近Scalaを使っているし、Scalaユーザーにいくつか聞けたらなぁーとかちょっと勉強したいなーって感じで。
運営の方はおそらく大変だったと思いますがいろいろ対応してくださって助かりました。 ただ、自分が参加したチュートリアルセッションはひどかったです。自分もハンズオンで教えることがあり、失敗を幾度かしてフィードバックをもらっては改善してきました。ので、今回は私がフィードバックをする番だと思いましたので、このエントリにさせていただきます。
- トラックとかモチベーションについて
- Scala入門ハンズオンのタイムライン
- Implicit入門
- CTO座談会
- まとめ
Java/Groovyでうるう秒を扱う方法
Java言語でうるう秒を扱う方法を調べたのでまとめておきます。Twitterで質問したらたくさんのリプライ、エアリプがありそれらをもとに調べることで達成できました。ありがとうございました。
概要
- Java標準APIのOracle実装ではうるう秒を扱えない。Calendar, Dateなどの旧型のAPI、ZonedDateTimeなどのDate and Time APIどちらも。
- ThreeTen-Extra というライブラリを使うとうるう秒を扱える。
うるう秒を扱えるということに対して期待していること
4年に1度だけ2/29があるうるう年のように、2年から5年に1度くらいの間隔で世界中の時計が1秒だけ増えることがあります。これをうるう秒と言っています。最近だと日本時間で2017/1/1 08:59:59 のつぎが 2017/1/1 08:59:60 となりました。普段はない60秒があり、1分間が61秒になりました。 これはいつ挿入されるかは規則はいまのところありません。(どれくらい前に告知されるのかは決まっていないのかな?)
で、システムにおいてうるう秒においても 08:59:60 のように時刻を正確に記録できるのかが気になりました。
というのも例えば、UNIXTIMEはうるう秒を丸めるという仕様になっています。
具体的には次のような形になります。
- 東京の時刻
- UNIXTIME
- 2012-07-01T08:59:59+09:00[Asia/Tokyo]
- 1341100799
- 2012-07-01T08:59:60+09:00[Asia/Tokyo] <= うるう秒挿入
- 1341100799 <= 1秒前と同じ
- 2012-07-01T09:00:00+09:00[Asia/Tokyo]
- 1341100800
ということで、UNIXTIMEを使うとうるう秒時点の扱いを気をつけなければいけません。(保存にしろ、描画にしろ)
ので、流れとして
- 「2012-07-01T08:59:60+09:00[Asia/Tokyo]」という時刻を表現できるようにするにはどうしたらいいのだろうか?という視点で調べました。
- このシステムはうるう秒が来ても正確に動作するシステムであるといえるようにしたい。
- となると、うるう秒を発生させるテストを書かなければいけない。
- (例えば)Javaでうるう秒を任意に起こすことはできるのか?
という形です。
そこで、「2012-07-01T08:59:59+09:00[Asia/Tokyo]」のオブジェクトを生成し、1秒すすめたときに「2012-07-01T08:59:60+09:00[Asia/Tokyo]」が生成できるのか?ということを調べました。
Java標準のAPIだとどうなるのか
Java標準の時間を扱うクラスというとJava7まではjava.util.Calendar、java.util.Dateを使い、Java8からはDate and Time APIである java.time.ZonedDateTime などを使います。
JavaDocにはOS依存だよーとか、Java実装依存だよーとか書かれていたので、次のような環境で試しました。
ですがいずれの場合でも、「2012-07-01T08:59:59+09:00[Asia/Tokyo]」のオブジェクトを生成し、1秒すすめたときには 60秒にならず09:00:00になってしまいました。
Calendarの場合
def c = Calendar.getInstance(TimeZone.getTimeZone("Asia/Tokyo")) // 59秒を生成 c.set(1900 + 112, 6, 1, 8, 59, 59) // うるう秒にすすめる c.add(Calendar.SECOND, 1) // fail assert c.getTime().toString() == "Sun Jul 01 08:59:60 JST 2012" // うるう秒で生成 def d = new Date(112, 6, 1, 8, 59, 60) // fail assert d.toString() == "Sun Jul 01 08:59:60 JST 2012"
ZonedDateTimeの場合
// 59秒を生成 def zdt59 = ZonedDateTime.parse("2012-07-01T08:59:59+09:00[Asia/Tokyo]") // うるう秒にすすめる // fail assert zdt59.plusSeconds(1).toString() == "2012-07-01T08:59:60+09:00[Asia/Tokyo]"
ちなみにZonedDateTimeのparseメソッドはそもそも60秒をパースできませんし、Instantのparseメソッドは60秒をパースしても0秒に丸めてしまいます。
ThreeTen-Extraを使うとどうなるのか
ThreeTen-Extraというライブラリを使うとこれが実は出来ます!(なんだってー!なんのためのJSR310だっt
- Stephen Colebourneが「Joda-Time」をつくる
- JSR-310としてJoda-Timeのように便利にしようとDate and Time APIが取り込まれる
- Stephen ColebourneがJSR-310の拡張ライブラリ「ThreeTen-Extra」をつくる
もう、Stephen Colebourneに足向けて寝られないですね。
UtcInstantというクラスを使うとうるう秒を保持した計算ができるようになっています。なのでタイムゾーンなしの文字である「2012-06-30T23:59:59.000Z」を渡して1秒足してみて60秒になれば成功です。
import java.time.Duration import org.threeten.extra.scale.UtcInstant def ui = UtcInstant.parse("2012-06-30T23:59:59.000Z") def ui2 = ui.plus(Duration.ofSeconds(1) // success assert ui2.toString() == "2012-06-30T23:59:60Z"
ということでうるう秒を鑑みて時刻を考えるなら、UtcInstantとして常に計算し、日付、タイムゾーンは別で管理しておくという戦略をとればよさそうです。
ちなみにUtcInstantでは日付はMJD(修正ユリウス日)が使われています。のでだいたい5桁くらいで収まる範囲です。
ただしこれがバグっぽいAPIがある
UtcInstantにはisLeapSecond()というメソッドがあるのですが、これがうるう秒ちょうどになった瞬間はまだうるう秒じゃないという判定をしてしまっているように見えます。
- 08:59:59.999
- 08:59:60.000 <= うるう秒 <= ここでisLeapSecondがfalseになってしまう。
- 08:59:60.001 <= うるう秒 <= ここはtrueを返してくれる
- ...
- 09:00:00.000
まだThreeTen-Extraの仕様を読み切ってないのですが、仕様が僕のおもっているとおりならこれはtrueを返すべきところなので、まずかったらIssueをあげようかなーと。
そのほかの話
ここまでで、Javaでうるう秒を扱うという方法がわかったわけですが、システム全体で考えるといろいろと面倒です。 まず、Windowsはうるう秒をサポートしていません。
次に、Linuxではうるう秒については60秒になった瞬間に59秒をやり直します。(60秒から0秒のあいだまでもう一度59秒になります)
そして、NTPサーバがどのように返答するか次第でOSの挙動は変わります。
ちなみに、GoogleなんかではLeap Smearingといって、うるう秒の1秒を(うるう秒前後の)20時間かけてちょっとずつ時計の進みを遅くすることで60秒という1秒間を分散させています。こうすることで、NTPサーバに問い合わせても60秒という時間が指定されません。つまり、ある20時間だけほんの少しずつだけ時計が遅く進んでいるのです。
クラウドを使っている場合にはインフラのNTPまでを統一するのは難しいので、要件に応じてどこを何に統一するのか考える必要があります。
最後に
情報収集につきあってくださった id:megascus さん、エアリプしてくれた khasunuma さんありがとうございました。めっちゃ勉強になりました。 そしてコードを簡単に共有できるWandbox最高でした。Groovyの最新版うごかしてくれてありがとう。(もう少し言えば、@Grabが動くようになっているともっともっと嬉しいんだなー。)
参考
13 章 : Date and Time API · Java Study
- ここが正しかった。やはりJCP会員つよし。というか、このサイトかなりすごい。khasunumaさんすごい。
Java本格入門 ~モダンスタイルによる基礎からオブジェクト指向・実用ライブラリまで
- 作者: 谷本心,阪本雄一郎,岡田拓也,秋葉誠,村田賢一郎,アクロクエストテクノロジー株式会社
- 出版社/メーカー: 技術評論社
- 発売日: 2017/04/18
- メディア: 大型本
- この商品を含むブログを見る
- 作者: Joshua Bloch
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 2018/01/06
- メディア: ペーパーバック
- この商品を含むブログ (2件) を見る
Scrumのカンファレンスに参加してきた #RSGT2018
ソフトウェアコードのはじめかた
- プロジェクト名や名前空間の雑さはIDEなどの強力さを考慮して決めること
- プロジェクトをつくるときは次の手順でやること
- てきとうにスキャッフォルドでつくる。gradle initとか。
- gitignoreを追加する gitignore.io - Create Useful .gitignore Files For Your Project
- git init
- git add
- git commit で↑までにやったコマンドやWebサービスでの指定方法などをコメントにのこす
- 要件を確認してアーキテクチャと単語の整理
- noteという名前空間をつくり、そこにメモ書き用テストファイルをつくる。
- 要件をテストコードにはりつける
- 要件の一部をテストコードに翻訳する。簡単なケースだけでいい。 : RED
- プロダクトコードを仮実装する。 : GREEN
- 他の入出力のケースをテストに追加する。三角測量。 : RED
- プロダクトコードを修正する。 : GREEN
- テストコードをリファクタリングする。 : GREEN
- 何をクラスとして切り出すかは、何をつくりたいのかを定義している段階できまるので、コードをかきながら決めないほうがいい。
- テストコードはできるだけ長く書きはじめていく。テストコードは動的構造を記述する部分であり、プロトコル定義ツールとして使う。
- 小さいテストコードはあくまでデバッグのサポート、型システムのサポート程度に考えて記述する。
- 静的構造はプロダクトコード側で記述できる内容なので、プロダクトコードのリファクタリングや大枠の設計でおこなうようにする。
- テストコードとプロダクトコードの設計がかたまったら、noteにあるテストコードを適切な名前空間にきりだしてあげる。