macをWindowsっぽく快適に使う小技集 for Windowsユーザ
前職で1年ほどmac book使ってましたが、それまではほぼWindows、そして仕事とか自宅鯖とかなんとなくお試し程度にLinuxも使ってたのらぬこ(@noranuk0)です。
そんな僕が、先日 mac mini を買いました。
公式販売価格は88000円(税抜き)なので、約35%引きと割りとお得な買い物だった気がしております。
起動して S.M.A.R.T情報を眺めると通電時間は約800時間、それなりには使われていたと思いますがSSD劣化などの心配は全くなさそうです。
ちなみに、モニター、キーボード*1、マウス*2は自宅で余っていたものを使いまわしております。
さて、ここ1週間は自宅ではほぼほぼmac使いになっているわけなのですが、操作がやっぱりwindowsとはかなり違っているわけでして、やっぱりどうにも使いづらいところが多々出てくるわけで。
仕事ではWindowsマシーンを使っている都合上、特にキーボード、マウスの操作性はできるだけWindowsと同じにしたいと思うわけで。
そんなわけで、色々調べつつ、設定変更やカスタマイズ系アプリを入れるなど行い、結果、Windowsと大体おなじような操作性を手に入れることができました。
今回はそのあたりを紹介したいと思います。
前提条件
僕のmac mini環境はこんな感じです。
- mac OS sierra
- キーボード Windows用 日本語キーボード(無線)
- マウス Windows用 2ボタン+ホイールマウス(無線) OSのバージョン、入力デバイスの種類によっては、今回の記事に書かれていることがうまく実現できないかもしれません。
僕もmacには詳しくないので、もしうまく動かないような場合には、すみませんがお力に離れないと思います。
ちなみに、僕が使ってるキーボード&マウスはこちらです。
LOGICOOL ワイヤレスデスクトップ キーボード&マウスセット ワイヤレスコンボ Unifying対応超小型レシーバー採用 MK520
- 出版社/メーカー: ロジクール
- 発売日: 2010/09/10
- メディア: Personal Computers
- 購入: 3人 クリック: 7回
- この商品を含むブログ (3件) を見る
早速カスタマイズをする
ここからは、「僕がうまくやったやり方」を説明していきます。
マウスホイールのスクロール方向をWindowsと同じ感じに
購入したてのmacは、マウスホイールでのスクロール方向がWindowsと逆向きです。
Windowsと同じ向きにするには設定が必要です。
- 画面上のメニューバーの左端のりんごアイコンから「システム環境設定」を選びます。
- マウス という項目を探して選択します。
- スクロールの方向:ナチュラルのチェックを外します。
- マウスの移動速度(軌跡の速さ)、スクロール速度なども変更できるので、ついでにお好みで変更しても良いかと思います。
日本語入力の切り替えを [半角全角] キーで行う
これ、割と一筋縄では行きません。
入力ソースの切り替えに使用するショートカットキーは、はシステム環境設定のキーボードから変更ができるのですが、日本語Windowsキーボードをmacにつなぐと、半角全角キーが「`」に割り当てられてしまい、このキー単体をショートカットキーとして設定することはできないようになっています。
標準機能だけでなんとかするのはおそらく不可能で、これを実現するにはアプリの力が必要です。
今回は、「Karabiner-Elements」という、キーコードをかなり自由にカスタマイズできるアプリを使います。
ちなみに、僕はmac標準の日本語入力システムの「ことえり」は好きになれない*3ので、「google日本語入力」を使っています。このあとの説明も google日本語入力の場合の説明になっています。色々察して適宜読み替えるなりgoogle日本語入力も合わせて導入するなりしてください。
ちょっと話がそれましたが、本題の実現方法を大まかに言うと以下のようになります
- 「Karabiner-Elements」を使って「全角半角」キーを「F15」とか割りとどうでもいいキーのキーコードに割り当てる。
- システム環境設定で「入力ソースの切り替え」のショートカットキーに「F15」を割り当てる。
ということで、早速やっていきます。
まずはアプリをダウンロード&インストールします。
- Karabiner-Elements アクセスします。
- ページを開いて1画面ほど下にスクロールすると「Project Status」という見出しの下に You can download … みたいな英語が書かれています。
- そこに、dmg ファイルへのリンクが貼られていると思うので、それをダウンロード&インストールします。 なお、インストール後にPCの再起動が必要になります。
ダウンロード&インストールが完了したら、LaunchPadなどからアプリを起動します。
アプリを起動したら、Virtual Keyboard というタブを開き、Keyboard Typeから JIS を選択します。
次に、Simple Modifications タブを開き、 grave_accent_and_tilde(`) *4を f15 に割り当てます。ほか、お好みでキーコードを変更したいキーを自由に追加しても構いません。
僕は、「無変換」を「英数」に、「変換」「カタカナひらがな」を「かな」キーに割り当てる設定も追加しています。
ここまでの作業で、「全角半角」キーを押すと、f15が押されたと macOSさんは認識してくれるようになりました。
今度は、f15キーが押されたら、日本語み↔英語の入力切替を行う設定を行います。
「システム環境設定」を開き、「キーボード」の設定画面を開きます。
「入力ソース」タブを選び入力ソース一覧から「ひらがな(google)」「英数(google)」以外を削除します*5
「ショートカット」タブを選び、「入力ソース」カテゴリーの「入力ソースの次のソースを選択」のショートカットに F15を割り当てます。
とりあえずこれで、「全角半角」キーで日本語↔英語入力の切り替えが実現できました。
なお、かな→カナ変換とか、そういうのは知らんです。Windowsでも使っていなかったので実現できるのかとかすでにあるのかとかは不明でございます。
キーボード文字エリアの右上にある「¥」で「/(バックスラッシュ)」を入力する
UniCodeとかそういうの知らんですわ。「\」を「¥」として表示してるのはなんかもう暗黙の了解っていうかなんていうか。
google日本語入力使っている方はLaunchPadの中に「config dialog」っていう「ひらがなの「あ」」のアイコンあるので、そこから設定できます。
「ことえり」な方は「システム環境設定」の「キーボード」の中辺りから設定できたと思います。
もう少しネタはあるのですが、そろそろ力尽きてきたので、今回はこのへんで、ということで。
お読みいただいてありがとうございました。
mac 関連のその他の記事
androidアプリのCI環境(自動ビルドとテスト版自動配信)を全部無料で整える 其の弐
どうものらぬこです。
今回の話は、開発中androidアプリのソースをgitリポジトリにpushした瞬間、自動テスト(書いていれば)、自動ビルドが走り、成果物(apk)を自動でテスト配信するというお話の第二弾です。
前回記事では、bitriseというモバイル・アプリ向けのCIサービスを利用して、自動ビルド&自動テストするところまでを紹介しました。
今回は、fabricというサービスの一つであるcrashlyticsに含まれるbeta版アプリの配信機能を利用して、開発中アプリを随時テスト端末へ自動配信する方法を紹介します。
fabricは、アプリの収益化、利用者の増加にまつわる様々な問題を分析、解決するようなWeb上のプラットフォームです。
アプリユーザ数、アクティブユーザ率などの集計、クラッシュレポートの収集、そして今回利用するテスト版の配信機能などを備えています。
もともとTwitter社が運営していたのですが、今年の1月にgoogleに売却されたようです。
ただ、アナリティクス的な機能や、クラッシュレポートの収集機能であれば、firebaseというプラットフォームもありますし、機能的にかぶるところも多いです。
fabricのサービスが今後どうなるのかは、正直なところちょっと未知数かもしれません。
とはいえ、手軽にテスト版アプリの自動配信が行えるプラットフォームとしては、現時点ではとても使いやすいと感じているので、当面はこちらを利用していきたいと考えています。
アカウント登録
利用するにはアカウント登録が必要です。
というわけで、まずはfabricのアカウントを取得します。
アカウントの取得は、Fabric - App Development Platform for teams の右上にある、[GET FABRIC]ボタンから行うことができます。
登録は、画面右上の [GET FABRIC] と書かれたボタンから行います。
fabricのダッシュボードにアプリを追加する
アカウント登録が完了したら、fabricのダッシュボードに自動配信を行いたいアプリを登録します。
ダッシュボードへの登録は、対象アプリにfabricのSDKを組み込み、それをいったん起動することで自動的に行われます。
SDKの組み込みは build.gradleやandroidmanifest.xmlへのコード埋め込みのみなので比較的簡単に行えます。
しかし、APIkeyの取得が、現状android studio の pluginから行うしか方法がなさそうです。したがって、SDKの組み込みを行うにはandroid studio へのプラグイン導入が必須な感じとなっております。
Web上に導入手順が細かく書かれているfirebaseと比べるとやっぱりちょっと適当な印象を持ってしまします。いずれはなんとかしていただきたいものです。。
まあ、ここで言っても仕方がないので、ここはめげずに android studio にfabric pluginを導入します。
プラグインの導入は、[File] - [Settings…] メニューを選択して表示されるSettingsダイアログ内の plugins から行うことができます。
インストール完了後、android studio を再起動すると、ツールボタンンに fabricプラグイン起動ボタンが追加されています。
プラグインを起動すると、ログイン画面が表示されるので、先ほど登録したログイン情報を入力してログインします。
fabricで使えるすべての機能が一覧表示されるので、その中から crashlytics を選択します。
crashlyticsは本来は、クラッシュログの収集用のツールですが、テスト版(開発中)のアプリをテスト端末に自動配信する機能も持っています。 今回はそれを了する形になります。
crashlyticsを選択すると、埋め込み用のコードが表示されるので、そのままapplyボタンを押せば、オープン中のプロジェクトにコードが追加されます。
テスト端末などでアプリをデバッグ起動すれば、自動的に fabricのダッシュボードにアプリが追加されます。
fabricにwebからログインすると、確かにダッシュボードにアプリが登録されています。
自動配信を設定する
まずはテスターの方をfabricのプロジェクトメンバーに登録します。
テスター=本人のみというボッチ系開発者の方も、まずは自分をメンバーとして登録する必要があります。
ダッシュボードのサイドメニューから Beta を選択し、Add Testers というボタンを押します。
メールアドレスを聞かれるので、メアドを入力します。
すぐに下記のようなメールが来るので、
テスト対象のアンドロイド端末でメールを開き、本文内の [Let me in] ボタンを押します。
配信管理用アプリのダウンロード&インストールが始まるので、指示に従い配信用アプリをインストールしてください。
Beta というアプリがインストールされるはずです。
以後は、fabricに登録したテストアプリを更新するたびにこのアプリに通知が飛ぶようになっています。
テスターを何人か抱えたチーム開発を行うような場合だけではなく、個人開発中、数台のテスト端末に開発中アプリをまとめて配信したいような場合にも活用できるかと思います。
また、過去のバージョンも保存されているため、一旦旧バージョンに戻して確認するといったことも簡単に行うことができるようになっています。
fabricのアプリを更新する
android版の場合、gradeleコマンドを利用すればfabric経由で簡単に更新版を配信することができます。
- デバッグ版の場合
$ ./gradlew assembleDebug crashlyticsUploadDistributionDebug
- リリース版の場合
$ ./gradlew assembleRelease crashlyticsUploadDistributionRelease
これを自動ビルドを行ってくれるCI環境に組み込めば、developブランチへのpushでdebug版のテスト配信、masterブランチへのpushでrelease版のテスト配信を行うといったことが可能になります。
前回紹介した bitriseの記事でも、そのような設定を行っています。
以上、2回に分けて、androidアプリのCI環境の話と、テスト版自動配信の話をさせていただきました。
お読みいただいてありがとうございました。
androidアプリのCI環境(自動ビルドとテスト版自動配信)を全部無料で整える 其の壱
どうも、のらぬこです。
今回の話は、個人開発しているandroidアプリのソース管理(gitホスティングサービス)、自動ビルド、自動テスト配信環境を全部無料で整えたというお話の第一弾(前半)になっております。
この記事では、これらのことをどのように実現したかという観点で、ソース管理の話から自動ビルド環境を構築したところまでの話をします。
利用したサービスは以下の3つです。
- BitBucket
- Bitrise
- fabric(crashlytics beta配信)
- リリース済アプリのクラッシュ情報を自動で収集、報告してくれる等のサービスが提供されています。
- 今回は、その中の一つ、テスト版をチームメンバーに自動配信するようなサービスを利用します。
なお、今回の話は、Bitbucketアカウント登録から、Bitriseを利用した自動ビルド環境構築までの話になります。
さて、僕はandroidの個人開発を始めた当初から、gitホスティングサービスとしてマイクロソフトが提供しているVisual Studio Team Serviceを利用していました。
ちなみに、Visual Studio Team Serviceはソース管理(gitとMS製のバージョン管理システムに対応)と自動ビルド&デプロイ、Issue管理をひとまとめにしたようなWeb上のサービスになります。
5人以上のチームで使用する場合には有償になりますが、メンバーがそれ未満の場合にはサービス利用は基本無料となり、例えば、プライベートgitリポジトリなども数や容量の制限なく自由にいくつでも作成することができる(逆に、パブリックなリポジトリは作成できない)等、ちょっとほかには見られないような特徴も持っています。
また、.net系のアプリやwebサービスはもちろん、nodejsなwebアプリ、mavenやgradle管理のJVM系言語、androidやxcodeにも対応したCI環境も用意されており、さらにazureへの自動デプロイもできたりして*1、お金はかけたくないけどいろいろ使ってみたい等、用途によってはとても良いサービスだと思います。
Visual Studio Team Serviceについては、以前紹介記事も書いているので、ご興味ありましたら合わせてごらんください。 noranuk0.hatenablog.com
僕ももともとはgitリポジトリのホスティングサービスとしてしか活用していなかったのですが、開発中Androidアプリの自動ビルドもそのうちやりたいなーとは思っていました。
が、Visual Studio Team Serviceで用意されていたAndroidの自動ビルド環境は割と残念な出来栄えで、自動ビルドには成功しませんでした。
どの辺が残念かというと、環境がかなり古く、例えば用意されているsdkバージョンに未だにandroid-19が使われていました。
しかもおそらくアクセス権限関係?でSDKのアップデートもできない状態で、どうにも使用するには堪えないような代物だったんです。
半ばあきらめていたのですが、gitリポジトリにはBitbucketを使い、リポジトリへのpushをトリガーとした自動ビルドにはbitriseを、ビルド済apkの自動配信にはfabricを使えば、僕のやりたいことは全部無料で実現できそうだと分かり、早速試してみました。
結果、自動ビルド&自動配信まで無事に行うことができるようになりました。
前置きが長くなってしまいましたが、これから手順等の紹介をします。
gitリポジトリの移行
まずは、BitBucketのアカウントを作ります。
BitBucketもVSTSと同様に少人数チームであればプライベートリポジトリも割と無制限に作れるようです。
Bitbucketのアカウント作成と他のリポジトリからのソースのインポートについては特に説明の必要ないかと思います。
どうしても何かを見ながらやりたい方はこの辺(↓)でよさげなページを探してください。
bitbucket アカウント作成 - Google 検索
gitはtortoiseGitかSourceTree経由で使っててコマンドとかよく解んないっていう僕みたいな人は、Bitbucketには他のgitホスティングサービスのリポジトリを丸ごとインポートできるUIを持っているので、そいつを使えば移行も簡単です。
ただしその場合、移行後にローカルリポジトリのoriginの向き先を変えるなり、BitBucketからcloneし直すなりしないと後でちょっと残念な気持ちになるかもしれません。
Bitriseで自動ビルド環境を準備する
Bitriseは、iOS, android, unityプロジェクトのCI環境を提供しているモバイルアプリに特化したCIサービスです。
CIによる自動ビルドも、月に200ビルドまでは無料で利用することができるため、個人利用であれば無料枠内で十分に活用できると思います。もちろん、ちゃんとテストを書いていれば、時間制限はあると思いますが、androidエミュレータを利用した自動テストも当然可能です。
ソースコードは、対応するgitホスティングサービスと連携し、そこから取得ことになります。
対応しているgitホスティングサービスは、GitHub, BitBucket, GitLabの3つです。。
実は、この記事を書いていて気が付いたのですが、任意のgitリポジトリを指定することもできたようです*2。
ビルド手順は、workflowと呼ばれるWeb上のツールで設定します。
なお、基本的なテンプレートは最初から用意されており、ソース取得元のgitリポジトリを指定すれば、中身をみてAndroid、iOS、Unityの設定を自動生成してくれるため、特にカスタマイズが必要なければそのまますぐに使えます。
ただし、ビルド結果やビルド済みファイルのダウンロードURLが記入されたメールの配信などは、デフォルトでは行ってくれません。
ビルド結果とダウンロードURLが書かれたメール通知やSlack通知、今回僕が行ったようなfabricを利用したテスト版配信等をやりたい場合は、多少の設定追加、変更などのカスタマイズが必要です。
なお、カスタマイズする場合も、難しいことをする必要は全然ありません。
例えば、特定のURLからファイルをダウンロードしたり、ビルド結果をslackに通知するためのひな型は最初から用意されており、使いたいコンポネントを選択し、URLやAPIキーなどの情報を入力するだけで使えるようになっています。
アプリの署名については、少し注意が必要です。
androidアプリの場合、apkを署名するための鍵が必要になります。
デバッグ用の鍵はbitrise側で用意されているため、特に意識せずともデバッグ用に署名されたapkをビルドしてくれます。しかし、どうも毎回必ず同じ鍵が使用されるわけではないようで、更新版のインストールに失敗してしまうことがありました。
したがって、デバッグビルド用の鍵も自分で用意したほうが良いかもしれません。
独自の(自分で用意した)鍵を使いたい場合も、bitriseが鍵の保存場所を提供してくれているため、別途サーバを用意して鍵をWebからダウンロードできるようにしておく必要も、gitリポジトリに鍵をコミットしておく必要もありません。
僕の場合、ローカル開発環境で使用している鍵と同じものを使いたかったので、bitriseが用意してくれたアップロード場所に、普段開発PCで使用している鍵を登録しています。 qiita.com
無論、リリース向けの鍵についても、同様にbitriseのサーバにアップロードして、リリース版ビルド時にその鍵を参照するように設定しておけば、独自の鍵管理の仕組みを考える必要がなくなります。
ところで、自動ビルドの実行タイミングについてですが、初期設定では全てのブランチへのpush、プルリクをトリガーとして、すべて同じ手順でビルドが実行されるようになっています。
例えば、developへのpush時はdebug版、masterへのpushでリリース版のapkをビルドするような場合には、ワークフローを複数作成し、エディター画面の「trigger pattern」と書かれたリンクから、トリガーの種類と使用するワークフローを関連付けする必要があります。
トリガーには、特定ブランチへのpush時、特定ブランチへのプルリク時、特定パターンのタグがpushされた時を指定することができるようになっています。
これらの設定内容は最終的にはymlに落ちますが、ymlでしか書けないような設定は(おそらく)ありません。
全てGUIツールで設定が可能になっています。
自分が使っているymlの設定はこんな感じです。 developへのpushでデバッグ版、masterへのpushでリリース版がビルドされ、ビルド成功時にはfabric betaへの自動配信までやってくれます。
--- format_version: 1.3.1 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git trigger_map: - push_branch: master workflow: master - push_branch: develop workflow: develop workflows: master: steps: - activate-ssh-key@3.1.1: run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' - git-clone: {} - script@1.1.3: title: Do anything with Script step - install-missing-android-tools@1.0.1: {} - gradle-runner: inputs: - gradle_task: "$GRADLE_TASK_PREFIX$POSTFIX_RELEASE $CRASHLYTICS_UPLOAD_DISTRIBUTION_PREFIX$POSTFIX_RELEASE" - deploy-to-bitrise-io@1.2.9: inputs: - notify_user_groups: none - notify_email_list: "$EMAIL_NOTIFICATION" envs: - KEY: '' opts: is_expand: true develop: steps: - activate-ssh-key@3.1.1: is_always_run: true run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}' - git-clone: is_always_run: true - file-downloader@0.9.1: is_always_run: true inputs: - source: "$BITRISEIO_MYSYNCER_DEBUG_YMEWHJSL_URL" - destination: app/signingConfigs/debug.keystore - script@1.1.3: title: Do anything with Script step is_always_run: true - install-missing-android-tools@1.0.1: is_always_run: true - gradle-runner: is_always_run: true inputs: - gradle_task: "$GRADLE_TASK_PREFIX$POSTFIX_DEBUG $CRASHLYTICS_UPLOAD_DISTRIBUTION_PREFIX$POSTFIX_DEBUG" - deploy-to-bitrise-io@1.2.9: inputs: - notify_email_list: "$EMAIL_NOTIFICATION" app: envs: - opts: is_expand: false GRADLE_BUILD_FILE_PATH: build.gradle - opts: is_expand: false GRADLE_TASK_PREFIX: assemble - opts: is_expand: false GRADLEW_PATH: "./gradlew" - opts: is_expand: true CRASHLYTICS_UPLOAD_DISTRIBUTION_PREFIX: crashlyticsUploadDistribution - opts: is_expand: true POSTFIX_DEBUG: Debug - opts: is_expand: true POSTFIX_RELEASE: RELEASE - opts: is_expand: true EMAIL_NOTIFICATION: ********@gmail.com
fabricbeta配信の話まで書こうと思っていたのですが、そろそろ眠くなってきたので続きはまた今度、ということで。
ちょっと中途半端で終わっていますが、お読みいただいてありがとうございました。
PVがあろうがなかろうが、続編も近日中に公開予定です。
この便利さは想像以上! ドラム式洗濯機のイイところ ~注意点と一緒に語ってみる~
僕がドラム式洗濯機を選んだ訳
掃除、洗濯、料理、食後の後片付等々、数ある家事の中で最も苦行なのは「洗濯」だと思っています。
洗濯機に洗濯物を入れてスイッチを入れた時点で、「1時間後、洗濯が終わった洗濯物を干さなければならない」という行動的制制約が課せられます。
特に、外出が禁止される(洗濯が終わるタイミングで在宅していなければならない)というのが個人的には一番の心理的負担です。
洗濯物を干した後も、「夕方or翌朝には干した洗濯物を取り込む」という行動予定を頭の片隅に残しておく必要があります。
洗濯物の取り込みを忘たまま仕事などに出かけてしまった時に偶然にも昼から雨ったりすると、雨でびしょぬれになった洗濯物のことを思い出し、非常に残念な気持ちになります。
そんな悩みを軽減してくれるかもしれないドラム式洗濯機、前々から欲しいと思っていたのですが、20万円程度の費用がかかり、それがネックと感じていて、なかなか手を出せずにいました。
それでも、いい加減購入欲が限界値を超えてきまして、今年のお正月、お正月特価セールに期待してヨドバシAkibaに足を運んでみました。
やはり予想通りというかなんというか、家電売り場の各種家電も結構な値引き価格で売られておりました。
もちろんドラム式洗濯機もです。
しかも、ドラム式洗濯機に至っては、お正月特価で通常価格よりも3万~5万ほどのお値引き価格で販売されています。
「迷っている理由が値段なら買え、買う理由が値段ならやめろ」っていう格言、とても名言だと思います。
ドラム式洗濯機があれば・・・
- 時間の無駄が削減できそう
- その他のことが何となくいろいろ捗りそう
- 時間的制約から生まれるストレスがキレイに解消される
- 今使っている縦型の洗濯機もまとめ洗いするにはちょっと小さい
小一時間ほどウロウロしつつ悩んだのですが、買い替える決断を致しました。
選ぶ時の注意点
その場で、ドラム式洗濯機の選び方のコツを、所有&活用中の友人に聞いてみたところ「設置サイズ」「搬入サイズ」「メンテナンス(フィルター掃除)のやりやすさ」かなー、というご神託をいただきました。
ドラム式洗濯機は、現在「日立」「パナ」「東芝」「シャープ」の4社から販売されています。
基本的には、この中から選んでいくわけです。
搬入サイズについては、僕は戸建て住まいなので、廊下を通過できるサイズであれば基本的には無問題です。
次に設置場所のサイズですが、排水溝が奥の壁から65センチの位置にあるのがネックでしたが、最悪高さをかさ上げすればどうにかなると思ってたので、こちらもあまり気にしていませんでした。
ただ、ランドリースペースの既存の収納家具の都合上、幅が60cm以上のものを選んでしまうと収納家具の買い直しをしないとどうにもならない感じだったので、幅60cm以下というのが割と重要ポイントでした。
メンテナンス性については、どのメーカーも、洗濯機の下のほうに排水用ゴミ取り装置のの糸くずカゴ、上のほうに乾燥機排気ダクト用の吸排気フィルタがあるような構造です。こちらに関してもどれも似たり寄ったりでした。
ところで、ドラム式洗濯機の大きさは、狭いスペースにも収まるコンパクトなもの(幅60cm×奥行60cmほど)と、ファミリー向けの標準サイズ(幅60~75cm×奥行65cm~75cmほど)の2タイプが存在します。
コンパクトサイズのドラム式洗濯機はパナソニックやシャープから出ていて、特にシャープのものは高さもかなり低めに抑えられています。
ちなみに、スペック上の容量は、コンパクトサイズの場合は洗濯容量6kg前後、標準サイズの物では洗濯容量10kg前後、どちらのサイズも乾燥容量はだいたいその半分ほどです。
機能については、カタログ上はどのメーカーも大差なく(プラズマクラスターやecoナビ等の付加機能の差異はありますが)、結局、値段とメーカーの好みと見た目で選ぶことにしました。
洗濯機の大きさ(容量)については最後まで迷ってました。
独り住まいなのでコンパクトサイズのものも一応検討しましたが、コンパクトといっても、奥行きが15cmほど小さいだけだし、何より乾燥容量が3kgほどしかありません。
価格は多少抑えられますが、乾燥容量の3kgというのは現在使っている縦型の洗濯機よりも小さくなってしまうため、最終的に候補から外しました。
購入したのは、最近いろいろ(悪い意味で)話題の絶えない東芝さんの最新型モデルです。
実物はこんな感じです。
操作パネルがなんか未来チックなのがかっこよくて割と気に入っております。
僕が購入したときは、17万3000円+10%ポイント還元ほどでしたが、価格コムなどで探すと、現在の最安価格はもう少し安くなっているようです。
ドラム式洗濯機を買ってよかったこと
洗濯物を放り込んでスイッチを押せばあとは乾燥まで全部やってくれるというのは思っていた以上に心理的に楽です。
別に洗濯マニアではないので、仕上がりがどうだとか、しわがどうだとか、そういうのはよくわかりませんが、とりあえずきれいにはなっています。また、今のところ生乾きだったこともありません。
毛布も洗えるとのことだったので、試しにセミダブルサイズの毛布を洗ってみましたが、洗ってもフカフカのまま、もちろんちゃんと綺麗になりました。
なお、乾燥時には湿気を含んだ温風が大量に排出されるため、洗濯中の換気は割と必須な感じです。
また、運転音もエアコンの室外機よりは大きいため、深夜帯の運転は、地域、環境によっては配慮が必要かもしれません。
ドラム式洗濯機の注意点
乾燥機用のダクトのエアフィルター、排水用の糸くずかご(排水用の水にまざってる糸くずなどのごみを回収するための部品)ですが、とにかく毎回結構な量の綿埃や糸くずがたまります。
まずは乾燥機部分の吸排気口フィルターですが、洗濯後に取り外して汚れを確認してみると、毎回毎回厚さ数ミリほどの綿埃がべったりと付着しています。
乾燥が始まってから半分くらい(1時間ほど)時間が経ったタイミングで、一時停止&フィルタ掃除すれば、若干効率が上がるんじゃないかって思うほどには溜まっています*1。
掃除は簡単で、古い歯ブラシなどでフィルターを軽くこすってあげれば、綿埃の塊がごそっと取れるので、はがれた綿埃の塊を捨てるだけです。
難しいことは何もありません。
乾燥用のダクトが埃で詰まってしまうと、乾燥効率は当然のことながら劇落ちのようです。十分な時間乾燥しても、洗い物が生乾きだったり、最悪、ドラム式洗濯機の故障にもつながってしまうんだとか。検索するとそういった事例もたくさん出てきます。
毎回のフィルタ掃除は超重要な感じですね。
次に排水用の糸くずかごなのですが、こちらも毎回結構な糸くずがたまります。やはり毎回掃除したほうがよさそうです。
ところで、この糸くずカゴなのですが、縦型洗濯機の洗濯槽内側についているような糸くず回収袋に比べると目が粗いです。
細かい糸くずなどは水流でそのまま排水溝に流れてしまうんじゃないかっていうくらいには粗いです。
排水溝が詰まった場合、なんだかとてもめんどくさいことになりそうなので、対策をいくつかとっています。
まず1つ目の対策は、糸くずかごの中に取り付けるゴミ取りフィルターを使う、ことです。
洗濯機内蔵の糸くずカゴよりも目が細かいため、小さな糸くずもしっかりキャッチできるようになるはずです。
ドラム式洗濯機用 ゴミ取りブルーフィルター15枚入り×4セット
- メディア: ホーム&キッチン
2つ目は、洗濯機の排水パイプと排水溝の間に挟むタイプの糸くずフィルターボックスです。洗濯機の糸くずフィルターで取れなかったごみをここで再回収するために使っています。
糸くずフィルターボックスにも量は少ないですが糸くずや髪の毛などのゴミがたまります。2、3回の洗濯で一つまみというくらいです。
細かいゴミなら水流にのってそのまま流れてしまいそうではありますが、まあ、一応気休め程度といったところでしょうか。
上のリンクで紹介した商品は東芝製ですが、排水溝の口径に合わせて作られているため、おそらく他のメーカーの洗濯機でも使えると思います。なお、日立やパナからも類似品が出ているようです。
洗濯漕も見えないところが結構汚れます。
見える部分、つまり、洗濯漕の内側の金属部分はピカピカだと思います。
ですが、ドアのパッキンを軽くめくって裏側を見てみると、とてもおぞましいことになっているかもしれません。
この部分は乾燥時に熱風がもろに吹き込んでくる場所のため(たぶん)、一度水を吸った綿埃がパリパリに乾燥してしまい、掃除するのも一苦労です。
半年~1年に1回程度で構わないので、専用の洗濯漕クリーナーで洗浄運転をすることを個人的にはおすすめいたします。
僕も、使用開始から暫くの間は、たまにめくってみて、取れるゴミだけはつまんで捨てていましたが、使用開始から1年後、専用クリーナーを試しに使ってみました。
洗濯漕内のすべての汚れが本当にきれいに落ちました。
そして、排水用の糸くずフィルターにはものすごい量の糸くずだの綿埃だのがたまっておりました。
洗濯漕クリーナーは結構値の張る商品ですが、年に1回程度は必要経費だと思って利用した方がよさそうです。
まとめ
ドラム式洗濯機、縦型洗濯機と比べると値段も高いし、メンテナンスに若干気を使う必要が出てくることも確かですが、天気の心配と自分のタイムスケジュールを拘束する要因を1つ取り払ってくれるという意味で、費用に見合ったメリットがあると思います。
今後、洗濯のために費やす時間を軽減するための投資と考えれば、確かに多少お高いですが、購入する価値は十分にあると思います。
この記事が、ドラム式洗濯機ほしいなーと思っている方、すでにお使いの方のご参考になれば幸いです。
次は家事の中でも2番目に嫌いな食後の後片付けを楽にしてくれるかもしれない機械を導入したいなぁ。と思う今日この頃です。お金があれば。ですが。。。。
追記)食洗機も買いました!
お読みいただいてありがとうございました。
*1:そんな面倒くさいことやらないけど
【神級対応】イオシスさんで買った中古タブレットがプチ初期不良、でもその後の対応には好感が持てた
こんにちは。のらぬこです。
先日、中古PC、中古モバイル端末などを取り扱っているイオシスというお店で、Xperia Z4 tabletを買いました。
購入したのはいわゆる海外モデル、LTE+WiFiに対応ているものです。
イオシスさんの中古商品はAランクからCランクまでのグレードがあります。
- Aランク:
- ほぼ新品
- Bランク:
- 経年劣化による使用感はあるけど目立つ傷や破損などは無い商品
- Cランク:
- 経年劣化以上の目立つ傷、ひび割れ破損、付属品欠品などがある商品
参考)商品ランクとは? | 中古スマホ・タブレット格安販売の【イオシス】
僕は使用感とかはあまり気にしないのですが、目立たなくても液晶面に傷があったら嫌だったので、新品個人輸入と値段あまり変わりませんでしたが(それでももろもろ手数料とか考えると1万円近く安い)、Aランクのものを購入しました。
注文後3日程度で届いたと思います。
梱包については「もうちょっと緩衝材多めに入れてもいいんじゃないかな」と個人的には思ったりもしたのですが、商品は、外箱、付属品、本体ともにとても奇麗でした。
取り敢えず、起動&初回セットアップを済ませ、しばらく触ってみたのですが、とあることに気づいてしまいました。
画面通知領域の右上に表示されている「NFC」のアイコンが点滅してる?
どうも、NFCモジュールを起動しようとして失敗して再起動、を繰り返しているように見えます。
試しに、NFC対応BTヘッドホンとか手持ちの携帯電話をNFCでつなごうとしてもうまくいきません。
こういうことがないようにAランク選んだんだけどな(´・ω・`)
取り敢えず、端末再リセットなどあれこれ試しても直る気配がありません。
NFCってぶっちゃけ使わない。でも、電池持ちとかには影響出てそうだなー。
海外モデルって、日本ソニーは修理受付してくれないんだよなー。
ダメだったらまあしょうがないかと思いつつ、一応イオシスさんに対応可能か質問してみました。
以下、送ったメール全文です。
株式会社イオシス 通信販売課 ご担当者様 ○○と申します 先日、そちらのショップから [中古Aランク] Sony Xperia Z4 Tablet SGP771 LTE [White 32GB 海外版 SIMフリー] を購入いたしました。 注文番号は ほげほげほにゃらら です。 御送付頂きましたタブレット端末を、早速つかってみたのですが、 端末機能のうち、NFCが正常に動作しない現象が発生しております。 現象としては、 ・画面右上のNFCアイコンが点滅を繰り返す。 ・設定>その他の設定>NFCのオプションが正常に動作していない (NFC機能の有効化、無効化を切り替えるオプションです) ・設定>タブレット情報>機器診断>テストタブ で表示される NFCのテストを実行するとテストに失敗した旨が表示されます。 ・NFC対応の他の機器とつないでみましたが接続に失敗します。 端末のリセットなど確認してみたのですが、現象は変わらないようです。 ネットなどで、類似の不具合に遭遇されている方がいないかも確認してみましたが、 情報はないようで、初期不良の可能性を考えております。 商品に貼られていた保護フィルムを剥がしてしまったのですが、 初期不良のご確認、ご対応いただくことは可能でしょうか? 箱、その他付属品は購入時のまま保管されており、タブレット本体にも傷、汚れなどはつけておりません。 ご回答いただければ幸いです。 どうぞよろしくお願いいたします。
改めて読み返してみると、なんか面倒臭そうな奴だなー、とか思われた気がします。
中古品に対して、「初期」不良という言い方もなんか変な気もしたのですが、イオシスさんも「中古品の初期不良は~」みたいな書き方をされていたので、そこは気にしないことにしました。
昼にメールを送ったら、夕方前には返信が来まして、お詫びの文面と一緒に「同一商品の在庫確認します。在庫あれば交換、在庫なければ返金対応」という趣旨の返信がありました。
その後18時半ごろに、在庫確認できたから交換対応しますよ、とメールが来ました。
遅くまでご苦労様ですm(__)m
翌日、届いた商品を返送して、その3日後くらいに交換品の発送完了のメールが届きました。
その翌日には交換品を受け取ることができ、交換していただいた商品は全機能問題なく使えております。
初期(?)不良を引き当ててしまってちょっとひと手間掛かることになってしまったのは若干残念ではありますが、ショップさんの対応は丁寧で非常に好感が持てました。
後、配送に、佐川ではなくヤマトを使っていたのもポイント高いです*1。
また何かあったら利用したいと思ったショップさんのお話でした。
今回の話は以上となります。
お読みいただいてありがとうございました。
Sony Xperia Z4 Tablet (SIMフリー LTE, 32GB, White)[並行輸入]
- メディア: Personal Computers
- この商品を含むブログを見る
*1:佐川は荷物の扱いが酷いからっていう以外にも、ヤマトの場合、配送先を後からコンビニに変更できるので地味に便利なのです
jetty + jndi(with c3p0)な環境から lightsleepを使って超簡単にDBに繋ぐ - デバッグができるようになるまで
どうも、のらぬこです。
この記事では、タイトルに記載の環境が eclipseデバッグ環境でも mvn jetty:run での環境でも正しく動作するところまでを記載します。
さて、最近、個人的に立ち上げてみたいWebサービスができまして、現在こっそり実装中です。
ただ、いかんせコード書き始めてまだ3日程度なので、使うフレームワークは今後変わるかもしれないし、そもそも途中で飽きるかもしれません。
が、今のところ、言語はJava、ApplicationServer には jetty、RDBは postgreSQL、Webフレームワークにはasta4dというフレームワークを選択しています。
O/R mapperとしてDomaを使おうかとも思ったのですが、最近見かけたlightsleepというO/R mapperを検証がてら使ってみることにしました。
下準備
開発環境
まずは開発環境として以下の環境を準備します。
- Eclipse 4.5.2
- すでにneon.2 まで出ていますが、そちらでも問題ないと思います。
- run-jetty-run 1.3.5(Nightly)
- Eclipse 内の market place からもダウンロードできますが、現在公開されているバージョンはjetty 9.0.0M3 までしか対応していません。
- eclipseからデバッグ実行したとき、環境によっては(?)不具合が発生する可能性があるため、GitHub - xzer/run-jetty-run: Official successor of https://code.google.com/p/run-jetty-run/ を参考に、最新のnightly buildを使います。
- market placeからダウンロードできる1.3.4を使用た場合、デバッガから起動した際に、使用するJettyのバージョンに関わらず、IndexOutOfRangeExceptionが大量発生する謎バグに遭遇することがあります。
- なお、Eclipse market place を見ると、「Eclipse Jetty 3.9.0」 なるものもありますが、こちらのプラグインはjetty 起動時にc3p0を lib/ext としてjettyに食わせる手段がなさそうなので使えません。
とりあえずひな型WebAppの作成
これから開発を始めるという方は、まずはひな型Webプロジェクトを作成してください。
asta4dを利用する場合の手順は、GitHub - astamuse/asta4d: View first web application framework に手順が掛かれています。超簡単。
pomの設定を追加
下記のような形で書きます。とりあえず、今回追加が必要となる部分のみ抜き出しています。
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <dependencies> <!-- https://mvnrepository.com/artifact/org.postgresql/postgresql --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>9.4.1212.jre7</version> </dependency> <!-- https://mvnrepository.com/artifact/com.mchange/c3p0 --> <dependency> <groupId>com.mchange</groupId> <artifactId>c3p0</artifactId> <version>0.9.5.2</version> </dependency> <dependency> <groupId>lightsleep</groupId> <artifactId>lightsleep</artifactId> <version>1.5.1</version> <scope>system</scope> <systemPath>${project.basedir}/lib/lightsleep-1.5.1.jar</systemPath> </dependency> </dependencies> </project>
なお、lightsleepは mvnrepository に登録されてなさそうなので、こちらを参考に、jarをダウンロードして pom.xml に systempath として追加しています。
jndiの設定を書く
jetty側
プロジェクトディレクトリに jetty ディレクトリを作成し、その中に jetty-local.xml という名前で jndiの設定(jetty側)を記載します。 jndi名、jdbc接続文字列等は各自適切に変更してください。
<!-- jetty/jetty-local.xml --> <Configure id="noranuk0DB" class="org.eclipse.jetty.server.Server"> <New id="noranuk0MasterDB" class="org.eclipse.jetty.plus.jndi.Resource"> <Arg></Arg> <!-- score --> <Arg>jdbc/noranuk0DB</Arg> <!-- name --> <Arg> <!-- value --> <New class="com.mchange.v2.c3p0.ComboPooledDataSource"> <Set name="driverClass">org.postgresql.Driver</Set> <Set name="jdbcUrl">jdbc:postgresql://localhost:5432/kagure</Set> <Set name="user">admin</Set> <Set name="password">admin</Set> </New> </Arg> </New> </Configure>
webapp側
src/main/webapp/WEB-INF/web.xml の web-app要素内に以下を追記します。res-ref-name は jetty-local.xml で指定した名前と同じものを設定してください。
<resource-ref> <res-ref-name>jdbc/noranuk0DB</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
lightsleepの設定
src/main/resources/lightsleep.property を新規作成し、以下のような感じで設定します。Databaseの欄は環境に合わせて適宜変更してください。
# for PostgreSQL Logger = Std$Out$Info Database = PostgreSQL ConnectionSupplier = Jndi dataSource = jdbc/noranuk0DB
各環境ごとの設定例などは、Lightsleep/Manual_ja.md at master · MasatoKokubo/Lightsleep · GitHub を参照してください。
run-jetty-runの設定
- $HOME/.m2/repository/ 以下から下記3つの jarを探してきて、プロジェクトディレクトリ内の適当な場所(jetty/lib/ext 等)にコピーします。
- c3p0-0.9.5.2.jar
- mchange-commons-java-0.2.1.jar
- postgresql-9.4.1212.jre7.jar
- JDBCドライバは、接続先DBによって適切なものに読み替えてください
- Eclipse から [Run] - [Debug configurations…] を選択します。
- 左サイドペインから [Jetty WEbApp]を選択します。
- Jettyタブを開きます。
- Jetty classpath タブを開きます
- リストを一番下までスクロールさせると[Custom Jetty Classpath]という項目があるのでそれを選択します。
- 最初にコピーした3つの jar を追加します。
ここまでの作業をしたうえで、デバッグを開始すれば、おそらく正常に実行されるはずです。
DBアクセスのテスト
URLがたたかれた時に動作するコードに、こんな感じのコード埋め込んであげると確認できるかと思います。
Transaction.execute(connection -> { Optional<Item> contactOpt = new Sql<>(Item.class) .where("id={}", 1) .select(connection); // 取得したレコード出力するなりなんなり });
mvn jetty:run 向け pom.xml の設定
そろそろ書くのに疲れてきたので、jetty-maven-pluginの設定部分のみ貼っておきます。
こっち側は、jetty + jndi(with c3p0) が正しく動作するように設定を記載するだけです。
dependencies に c3p0 と jdbc drive を追加してあげないと、jettyが起動時にjndiの設定を行う際、c3p0などが認識できずエラーになってしまうので、ちゃんと書かないとだめです。
<project> <build> <plugins> <plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <version>9.4.0.v20161208</version> <configuration> <webApp> <contextPath>/</contextPath> </webApp> <httpConnector> <port>8080</port> </httpConnector> <daemon>true</daemon> <jettyXml>${project.basedir}/jetty/jetty-local.xml</jettyXml> </configuration> <executions> <execution> <id>start-jetty</id> <phase>pre-integration-test</phase> <goals> <goal>start</goal> </goals> <configuration> <scanIntervalSeconds>0</scanIntervalSeconds> </configuration> </execution> <execution> <id>stop-jetty</id> <phase>post-integration-test</phase> <goals> <goal>stop</goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-io</artifactId> <version>9.4.0.v20161208</version> </dependency> <!-- https://mvnrepository.com/artifact/org.postgresql/postgresql --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>9.4.1212.jre7</version> </dependency> <!-- https://mvnrepository.com/artifact/com.mchange/c3p0 --> <dependency> <groupId>com.mchange</groupId> <artifactId>c3p0</artifactId> <version>0.9.5.2</version> </dependency> </dependencies> </plugin> <!-- --> </plugins> </build> </project>
今回の話は以上となります。
lightsleep の使用感など、何かネタが出てくればそちらも記事にしたいと思います。
お読みいただいてありがとうございました。
gulp-s3-gzipで、s3上の格納先のパスを指定する方法
こんばんは、のらぬこです。
webサーバからクライアントにコンテンツ圧縮してを送ることができる仕様があります。
今更感半端ないですが、リクエストヘッダに書く accept-encoding : gzip とか、レスポンスヘッダにcontent-encoding : gzip と書いて圧縮したコンテンツを返すとかの話です。
少しでも転送量を減らしたいとき、少しでもページ読み込み速度を上げたい時などに使われるものだと思います。
ところで、s3に格納されたファイルについては、webブラウザが圧縮コンテンツ送ってもいいって要求してきても(つまり、accept-encoding : gzip と書かれていたとしても)、s3はわざわざ圧縮したコンテンツを返してくれません。
その辺は自前でやってくれってことですね。
取り敢えずやってみるだけであれば、以下の記事などが参考になると思います。
こちらの記事を書いた方も言われていますが、毎回毎回こんなことやってたら精神的に死んじゃうので、自動化したいですよね。
例えば、gulp を使う場合、gulp-s3-gzip というモジュールを使うと、ファイルを自動でgzip圧縮したうえで、自動でs3にアップロードできます。
しかも、content-encoding のヘッダ指定などもやってくれるので、deployはコマンド一発で完了です。
npmjs内のドキュメントを読むと、ちょっと困ったことにアップロード先のパス指定のやり方が記載されていません。
やり方は簡単で、npm install して引っ張ってきたソース見るとすぐわかります。
var gulp = require("gulp"); var s3 = require("gulp-s3-gzip"); var gzip = require("gulp-gzip"); var options = { gzippedOnly: true, uploadPath : "/hoge/fuga/" }; gulp.src('./dist/**') .pipe(gzip()) .pipe(s3(aws, options)); });
こんな感じで、options に uploadPath : "/hoge/fuga/" を追加すればおっけーです。
なお、gulp-s3-gzipの詳しい説明や、ソースコード全体を閲覧したい場合には、上でも紹介した gulp-s3-gzip のページを参照してください。
ということで、今回のお話は以上となります。
どなたかのお役に立てれば幸いです。