Toy と帽子と ADP BE

主にプログラミングに関わる話をゆるくエモくやっていきます

ThinkPad X220 に xubuntu をインストールした時の記録

前置き

ThinkPad X220 を入手したので、早速プリインストールの Windows から xubuntu に入れ替えました。せっかくなので手順や注意すべきことなどを記録に残しておきます。

10 年以上前に X21 に ubuntu を入れた時は PXE ブートでやったんですが、今回はおとなしく USB メモリをインストールメディアにしてやることにしました。

準備する(べきだった)こと

  • USB メモリ 2 つ

リカバリーメディアのためにひとつと、インストール用のためにひとつ必要です。

まあ個人的には Windows に戻すことは九分九厘ないのでひとつでもよかったんですけど、まあこういうのを端折って何かあったときに困ることはまれによくあるというのと、極度の貧乏性なので作れるものは作っておこうということで。

容量は、X220 のリカバリーメディア用は 8GB が必要で、インストールメディア用は iso のサイズが 16.04 LTS で 1.2GB くらいなのでそれが入るサイズが必要です。とはいっても、わざわざ探さない限り 8GB くらいからしか売ってないですかね。

余談

昔なら使ってない USB メモリがそのへんに転がってたりしたものですが、このご時世ですから普段使う機会は全くといっていいほどなくなってしまって、ものが手元になく慌てて買いに行くはめになってしまいました。USB メモリ一つをポチって一日待つのもアホらしいですしね。

とはいいつつ、わざわざ街の電器屋さんに買いに行くのもだるいよなと思っていたのですが、カメラ屋でもメディアを扱っていることに気づきました。ちょっと盲点でした。というわけで、インストールメディアに使うためなら品質とか問わないので近所のカメラ屋さんに買いに行って事なきをえたのでした。

リカバリーメディアの作成

http://x220.e-sup.biz/thinkpad_x220_ssd/step1/x220.e-sup.biz

このブログを参考にさせていただきました。

(2019-12-19 追記) 参考にさせていただいたブログはリンク切れになっていました。残念。(2019-12-19 追記ここまで)

作成用のアプリケーションをするだけの簡単な作業です。いろいろググったところ、USB メモリはクリーンな状態にしておかないといけないようなのでそこだけ注意です。

インストールメディアの作成

私の普段使いの PC は xubuntu なので、そこで xubuntu のインストールメディアを作るのはとても簡単でした。

  1. Download Xubuntu « Xubuntu からインストールしたいバージョンの iso をダウンロード
  2. USB メモリをマウント
  3. ターミナルで usb-creator-gtk を実行
    1. 特に変なことをしていなければ標準で入っているはずで、apt の実行とかは不要です
  4. 起動したアプリケーションにダウンロードした iso と、マウントしたメディアが認識されているのを確認してブータブルUSBの作成をクリック

余談

ググると何種類かのアプリケーションを使用する記事が大量にヒットしますけど、標準で含まれているコマンド一つでできちゃうんですね。自分も今までは Unetbootin でやってました。

インストール

BIOS の boot の設定で USB メモリが優先されるように変更したのち、インストールメディアを差し込んで起動。インストーラーが起動するので、あとはそれに従ってインストールするだけです。

途中で「グラフィックス、Wi-Fi機器、Flash、MP3やその他のメディアに必要なサードパーティーソフトウェアをインストールする」という項目があるのでそれはちゃんとチェックしていたほうがいいかもしれないです。(チェックなしでのインストールを試してないので、その時どうなるかはわからないのですが)

余談

それにしても、インストールするたびにインストーラーがわかりやすく楽にできるようになっていていいですね。よく解説記事などで「わからないならデフォルトのままでOK」みたいに書かれている項目が以前はいくつかあったと思うのですが、そういうのはもうありません。わかるひとは後で自分でよろしくやればいいわけですから、とてもいいことなんじゃないかと思います。

インストール完了

思ったよりずっと早く終わりました。Wi-Fi や、トラックポイント、ウルトラナビなどもちゃんと認識されています。素晴らしい。今のところ唯一の問題は、ウルトラナビの感度がウルトラよすぎてウルトラいらいらするので、あとで無効にせねばなーということくらいですかね。

いやー、昔に比べて xubuntu のインストールは本当に楽になったなと感じます。あと、いつの間にやら日本語入力のデフォルトが Mozc になっているようで驚きました。

将棋ウォーズの棋譜 url から csa ファイルを作るワンライナー

(Lazy) One liner that create csa file from shogi w ...

とりあえずソフトで解析するための棋譜ファイルを作りたかっただけなので雑なワンライナーで済ませました。

ワンライナーで済ませずにちょっと気合を入れたら対局者名や消費時間なども入れられますが、そこまでする動機もないので・・・。

楽しく仕事をするということ

この記事は コミュニケーション Advent Calendar 24 日目の記事です。

最近思ったこと

仕事をする上で、何かのきっかけで一時的に雰囲気が良くなることが時々あります。たとえばレトロスペクティブのあととか、とてもチームの雰囲気が良くなることがあるんですよね、経験上。あ、いいなあこれ、みんな笑顔でいい雰囲気で仕事できてるなぁ、って。ただし、次の日にはだいたい元に戻っている。別に元より悪くなるわけではないのですけど。

結局、それはかりそめの笑顔だと思うのですよ。みんなの意識が本当に揃ったわけではなくて、あくまでも形式的な表面上のコミュニケーション。みんなで話し合って決めたからそうしようっていうだけで、本質的なところが何も解決していないから定着しないのではないかと。

もちろんやらないよりはやったほうがいいと思いますよ。私はいい雰囲気を作るのが苦手だからなおさら普段から意識していないといけない。(残念ながらまったくうまくできてませんけど)

今考えていること

じゃあ本質的なところを解決するにはどうしたらいいのかって話になるわけですが、それは結局、意識(知識・スキルも含めて)の共有ではないかとは思っています。それをどうやって実現するかの答えは私の中ではまだ全く見つかっていないので困っているのですが。そもそも実現不可能なんじゃないかとすら思っていたりして。仕事に対する意識も、持っている知識も経験もスキルも違う人たちが、同じものを共有するなんて。

いい悪いの問題ではなくて、見えているものが明らかに違うから伝えきれないよなぁと思うことがあって。見たいと思っているものがそもそも違うからどうしようもないよなぁと思うことがあって。でも、自分が見ているこの風景をぜひ見せてあげたいと願ってやまない自分がいる。

求め過ぎなのかもしれません。自分にも他人にも。みんな違うことを認識した上で、それでもできる手段を取ることに注力したほうが効率がいいのかもしれません。でもそれでは納得できないんだよなぁ。困ったことに。

「 関ジャバ 関西Javaエンジニアの会(関ジャバ) '17 10月度」に行ってきました

kanjava.connpass.com

に行ってきました。

というわけで、直接的な感想ではないんですけど、皆さんのセッションから得たこととか考えさせられたこととかを一旦まとめました。

DDD について

最近 DDD とかそれにまつわる技術とかを学んだり実践したりする上で思うのは、よくあるなんとかアーキテクチャーとか(MV なんとかなども含めて)一つの指針としてはとても有用だと思いますけど、なんとかアーキテクチャーありきで開発するのは違うよなーということです。 そういう型にはめて型ありきでやろうとすると、この層なんのためにあるのかよくわからないとか、特定の層がやたら膨れ上がったりとか、どうしても歪ができてしまうような気がして。

ドメイン」は現場によって違う。言語やフレームワークも違う。作業者の質や量も違う。結局、そのときどきに合わせて悩んで苦しんで生み出していくしかないのではないかというのが今の時点での私の結論ですかね。

どうせ成果物を何ヶ月後か何年後かにあらためて見返したら、「当時の俺ってアレやったな」としか思わないんですから。いつまで経っても。

まあ一言で言うと「銀の弾丸はない」っていうお決まりのフレーズになっちゃうんですけどね。

ああ、もちろん、大きな枠組みではなく細かい技術やノウハウの積み上げは必要だし重要です。たとえば 増田さんの本 はそういうものが詰まっているんだなと今さらながら気づきました。

言語について

私は Java 大好きっ子で、一方今回のセッションは Scala が多めだったわけですが、それはそれでいろいろ学びになります。 で、少し前から意識はしていたんですけど、やっぱり Java 以外の言語も勉強しないといけないと改めて思いました。

それは、いろんな言語を学んで選択肢を広げるということももちろんあるのですが、メインである Java をもっと深く知るためにこそ、Java だけでなく他の言語や言語を支える技術をもっと勉強したほうがよいという意味で。

オブジェクト指向について

私のオブジェクト指向に対する認識は、いろいろさまよった結果

オブジェクト指向の概念の発明者は誰ですか?(改訂版) - Smalltalkのtは小文字です“オブジェクト指向”の本質 - Smalltalkのtは小文字です

この辺でとどまっています。また、数年前には社内勉強会の講師としてオブジェクト指向について話そうとして大爆死した経験もあったりします。そんなわけで、自分でもよくわかってないし人にも説明できないし、そもそも人によって言うことはまちまちだし、なんかもう最近は「みんなの心の中に、それぞれのオブジェクト指向があるんだよ」ってことでいいじゃないかみたいな感覚でいました。(getter/setter がカプセル化とかいうのはもちろんだめですけどね)

しかし、少なくとも Java という文脈の上ではそれはもう「型」ってことでいいんじゃない?と増田さんのセッションを聞いていて自信(?)が持てました。(雑な表現、雑な理解ですけども)

まあとりあえず、存在はだけ知っていたけど英語なので敬遠していた WhatIs 論文くらいはいまさらながら読もうと思いました。今の自分なら時間は掛かれど、それなりに読めるはず・・・。

MVNO の端末が故障した時すること

私の場合、MVNO楽天モバイルで端末は ASUS の Zenfone5 です。 前回のエントリの通り、こいつが突然ぶっ壊れましたので修理に出しました。 修理に出す前にいろいろ調べたところでは、サポートが悪いだの時間がかかっただのという記事が目立ったので不安だったのですが、実際はかなりすんなり事が運んだので他の方の参考になればと思い記録を残すことにしました。

他の MVNO や端末メーカーだと若干事情が違うかもしれませんけど、参考にはなるかと思います。

端末のメーカーに連絡

MNO とは違い、MVNO には壊れた端末を持ち込んでも仕方ありませんので、自分でメーカーに連絡します。ASUS の場合はサポートサイトとして サポート 公式 | ASUS 日本 があります。

どうやって連絡するか

下の方に、メール、電話、チャットそれぞれのお問い合わせのリンクがありますが、たぶんメールが一番効率がいいです。

  • 時間を気にしなくていい
  • 電話やチャットだと、話が噛み合わずに無駄な時間を取られることもある(らしい)

というのが主な理由です。メールのレスポンスは十分早い(夜投げても次の営業日にはちゃんと返ってくる)ので、問題ありませんでした。私は最後までメールだけでやり取りしていました。

何を連絡するか

ASUS - メールでのお問い合わせ

問い合わせフォームに適切な情報を入力して、問い合わせ内容として端末の故障状況を記載し、修理したい旨をつたえます。

すると、修理受付方法を記載したメールが返送されてくるので、それの内容に従えば OK です。具体的には

  • 故障した端末
  • 修理依頼確認書
    • メールにPDFのダウンロード用 URL がありますので、ダウンロードして印刷して必要事項を書き込みます
  • 購入証明書(レシート、店舗印付き保証書、領収書等)
    • 店舗で購入したわけではないので、上記の書類はないのですが、私の場合は申込受付完了メールをプリントアウトして送りました

を、指定された住所に発送することになると思います。なお、発送は着払いで OK とのことでした。

見積もり完了

端末が向こうに届き次第修理の見積もりを行ってくれて、それが完了した時点で見積の内容で修理するか取り止めるかを確認されます。それに対して返答すればほぼやりとりは完了です。私の場合家に一度電話があったようなのですが、不在だったので対応できず、直後にメールが送られていましたのでそのメールに対して返答をしました。そもそも、連絡先としてメールアドレスだけ伝えておけば最初からメールで連絡してくると思われるので、次の機会があればそうしようかと思っています。

修理完了

見積もりを了承した旨を伝えると、実際に修理が行われて返却されます。 見積もりの了承に対する返答はメールできますが、それ以降はメーカーからは連絡が来ないので、修理及び配送状況はサポートサイトで自分で確認する必要があります。 https://www.asus.com/jp/support/Repair-Status-Inquiry/?country=Japan 製品のシリアルナンバーだけで検索可能です。

なお、修理代金は代引きで運送業者に払うことになります。

期間

壊れてから修理されて返ってくるまで約10日間くらいでした。個人的には十分速いと思います。 向こうの見積もりを了承してから手元に戻ってくるまでだと、なんと約3日間でした。

参考

修理の手続きをする上で、こちらの記事が非常に参考になりました。ありがとうございました。

【保障期間内でも、修理してもらうのは大変】ZenFone5の修理を依頼する方法はこちら(3/20追記と修正) - 格安スマホ SIMで節約生活^^

【保障期間内でも、修理してもらうのは大変】ZenFone5の修理を依頼する方法はこちら 完結編 - 格安スマホ SIMで節約生活^^

スマホのない生活 3日目

突然の別れ

スマホが突然お亡くなりになりまして、今日で三日経ちました。

で?

何か困ることがあるのかというと特に困りません。

私がスマホですることといえば、基本ネット見るか、ゲームするかだけなので。電話は年に数回しかする機会ないし。チャットアプリは、たまに仕事の連絡にで必要になることはあっても、それ以外では奥さんとしかやり取りしないから特に差し迫った問題でもない。カメラも特別なイベントでもない限り使わないですねそういえば。

ただし

知らぬ間に自分が書いた記事のコメント欄が(また)炎上しているのにすぐ気づけなかったりするのでちょっと困りました。

本当に、地味に、辛いこと

私は普段スマホをおしりのポケットに入れているんですが、持ち歩いていない今でもつい手がそこに伸びるわけですよ。で、そのたびに

(あ、スマホなかった)

と、なったあと

(ていうか、ケツでかっ)

って思わざるを得ないのが地味に嫌です・・・。

実は今年、9kg 痩せたしウェストも 5cm 減ったんですけど、おしりはなかなか痩せないんですよね・・・。

サービスと階層の話

【大阪】9/16 現場で役立つシステム設計の原則 読書会【第5回 in 豊中】 - connpass に行ってきました。その中で、私にめちゃくちゃ刺さったことについて書き残しておこうと思います。

なお、『現場で役立つシステム設計の原則』では、第5章の話に相当します。それプラス、読書会で出た話や、私個人の感想が含まれます。

要約

  • サービスは単機能で作る
  • 複数のサービスをひとつのまとまりとして扱いたいときは、単機能のサービスを複数まとめた新しいサービスを作る
  • 階層は必要になった時に作ればいい
    • 階層ありきで設計すると、無駄なクラスをつくるハメになる

感想

ずっと悩んでいたわけですよ。どの階層に何を置けばいいのか、どのように階層を作ればいいのか、ということに。

古くはいわゆる MVC やその亜種に悩まされてきましたし、やれ DDD だやれ Clean Architecture だと言っている今でも、サービスって何さ?ユースケースって何さ?モデルって何さ?ってよくわからなくて試行錯誤して階層を分けたり分けなかったりしているのです。しかし、どうしてもどこかにただデータを横流ししているだけのようなクラスを含む階層ができたり、逆に色んな要素がつめ込まれてしまうクラスができたりしまいます。どうしてもどこかに歪が出てしまう。

でも、無理に階層を分けないで、小さい単位で組み立てていって、ある程度まとまった固まりに対して必要となった時に初めて階層を用意するとしたら? それは確かに、より自然であるように思えます。

最初から○○層!って気合を入れる必要なんてなかったのです。階層ありきで作るから、○○層って何書けばいいの?とか、書いては見たけれど本当に必要なのかどうかわからないようなクラスができてしまっていたのです。

そんなわけで、これからは必要なものを必要な分だけ書いていこう、と思ったのでした。

余談

PHP の有力なフレームワークである Laravel ですら「モデル」に対しては完全に振りきっていて

多くの別々の人達にとって、その意味合いは様々なため、"models"という言葉の定義は曖昧であることに私達は気づきました。ある開発者たちはすべてのビジネスロジックを総称してアプリケーションの「モデル」と呼び、一方で別の人達はリレーショナルデータベースに関連するクラスを「モデル」として参照しています。 ディレクトリ構造 5.5 Laravel

とかいいだす始末です。(まあ実際そのとおりなんですが)

余談その二

『現場で役立つシステム設計の原則』の第3章を初めて読んだ時、なぜか今回の話に出てくる(古き悪しき)MVC を想起*1してしまって「えええええ?」となってしまったのでした。もう一度読むと全然そんなことは言っていないことがわかったのですが・・・。あの感覚はなんだったのだろうか?

*1:フラッシュバックと表現したほうが適切かも