読者です 読者をやめる 読者になる 読者になる

引きこもりでも月10万円

なるべく家から出ないで月10万円稼ぐ方法を模索する日々です。

マヒトデザインで名刺を100枚550円(送料込み)で印刷した

f:id:ayb:20170526135319p:plain

先日、ココナラを使ってデザインしてもらった名刺を印刷してみました。

allyourbase.hatenablog.com

印刷は、何度か名刺の印刷でお世話になっている「マヒトデザイン」さんで行いました。

受付当日出荷!格安名刺印刷のマヒトデザイン

印刷代390円、送料160円の合計550円で100枚の名刺を印刷できて安いです。

マヒトデザインはPDFなどの形式で入稿すればそのまま名刺にしてくれるんですが、形式に制限があって手元の画像をPDFに書き出しただけではダメでした。

画像を使って名刺を作る場合は、「デザイン注文」というメニューを使います。デザイン注文を使えば、手元の画像ファイルを使って自由度の高いデザインをすることができます。

今回は、既に名刺印刷用の画像ファイルができていたので、それを埋め込むだけでした。

f:id:ayb:20170526135803p:plain

カラー自由デザイン→自由編集を選択します。

f:id:ayb:20170526135808p:plain

この画面で完成している名刺の画像を貼り付ければOKです。

完成した名刺は今のところ配る予定がないのですが、オフ会とかに行く機会があれば配りたいと思っています。引きこもりがちなので、そういう機会はかなりレアですが…。

GitHubに1日30コミットしたら草の色が変わった

f:id:ayb:20170526132521j:plain

GitHubの草生やし活動を継続しております。昨日、Play Storeにアプリを一つ後悔したのですが(宣伝)。

play.google.com

アプリのリリース作業のために30コミットほどして、GitHubにpushしたら草の色が変わってしまいました。

Before:

f:id:ayb:20170522203459p:plain

After:

f:id:ayb:20170526132542p:plain

全体的に草の色が淡くなっているのがわかるかと思います。

GitHubに多数のコミットをpushすると草の色が変わる、という現象の存在は知っていたのですが、実際に自分の草の色が変わるとがっかりしますね…。

気持ちを切り替えて、引き続きGitHubに草を生やす活動を頑張っていきたいと思います。もっとたくさんのアプリをリリースしていきたいです。よろしくお願いします。

allyourbase.hatenablog.com

「ちょっと今から仕事やめてくる」を読んだ感想(ネタバレ注意)

f:id:ayb:20170525135915j:plain

北川恵海の「ちょっと今から仕事やめてくる」を読みました。今月から映画も公開されるようですね。割とこう、心に刺さる作品でした。

以下、ネタバレがある可能性があるのでご注意ください。

続きを読む

GitをコマンドラインからSourceTreeに乗り換えた

f:id:ayb:20170525085749j:plain

Gitはずっとコマンドラインから使っていたんですが、ついにSourceTreeに乗り換える決意をしました。いざ使ってみると、とても便利です。今までコマンドラインからGitの操作をしていたのがバカみたいな気がしてきました。

www.sourcetreeapp.com

Gitの操作をコマンドラインからSourceTreeに乗り換えたのは、「Gitがおもしろいほどわかる基本の使い方33」という本を読んだことが理由です。この本は、Gitの使い方でなくてSourceTreeの使い方を解説した本であると言ってもいい本です。

この中に書いてあったことで感動したのが、

  • ステージに追加したファイルを作業ツリーに戻すのがクリック1回のみで済む
  • 変更箇所の取り消しも一瞬でできる
  • ハンク単位の追加と削除が簡単にできる

という3点です。コマンドラインから上記の操作をするのは大変、というかわたくしは調べながらでないとできません。こういう複雑な操作が簡単にできる、というのはSourceTreeを使う利点であると感じました。

また、MacのターミナルからGitを使っていて地味にストレスになっていたのが、「コミットメッセージを日本語で入力しているとターミナルが落ちる」という問題です(わたくしだけでしょうか?)。SourceTreeからコミットメッセージを入力すると、この問題が解決されるのが嬉しいです。

まだSourceTreeの操作には習熟しておりませんが、既に手放せなくなっております。SourceTreeを使うとGit Flowが運用しやすくなるみたいなので、その辺りも試して行きたいですね。

USB Type-Cの変換ケーブルを百均(セリア)で買いました

f:id:ayb:20170525080725p:plain

100円ショップのセリアにUSB Type-Cの変換ケーブルが売っていたので買ってきました。近所のセリアで売っていたUSB Type-Cの変換ケーブルは3種類です。

上の画像左から、

  • USB Type-Cオス-USB-Type-Cオス
  • MicroUSB Bメス-USB-Type-Cオス
  • USB Aオス-USB-Type-Cオス

となっています。仕様は以下のとおりです。

①USB Type-Cオス-USB-Type-Cオス

  • 充電、転送用ケーブル
  • USB 2.0
  • ケーブル長50cm
  • 最大5V、3A対応

②MicroUSB Bメス-USB-Type-Cオス

  • 充電、転送用ケーブル
  • USB 2.0
  • ケーブル長10cm
  • 最大5V、2A対応

③USB Aオス-USB-Type-Cオス

  • 充電、転送用ケーブル
  • USB 2.0
  • ケーブル長50cm
  • 最大電圧、電流不明

100円でデータの転送に対応したケーブルが手に入るのはとても良いですね。品質面に不安はありますが、とりあえず使うのにはよさそうです。

「iOS開発におけるパターンによるオートマティズム」を読んだ

f:id:ayb:20170524105547j:plain

iOS開発におけるパターンによるオートマティズム」を読みました。少し古い本ですが、とても参考になる良書でした。

iOS開発におけるパターンによるオートマティズム

iOS開発におけるパターンによるオートマティズム

この本は、iOSアプリのチュートリアルが終わって、本格的なアプリ開発を始めようという方のための本です。少し古い本なので、サンプルコードはObjective-Cで書いてあります。

この時点で読む気を無くした方もいると思います。わたくしも始めはそうでした。しかしながら、いざ本書を読み始めてみると、本書で提言されている「再利用可能なコードを書くための考え方」はSwiftの時代にも通用すると感じました。

本書は、本格的なアプリを作成するための、堅固な土台を提供することになる。ユーザにとって十分な機能を実装し、また将来のバージョンのOSでもきちんと動作するアプリを作り上げるための土台だ。これを身につけてもらうのが、本書の目的だ。(p.11)

とあるように、基礎を固める段階にあるプログラマにとってはとても有益であると感じました。

その例が本書で取り上げられている「MVCによるクラス設計」です。本書では、MVCアーキテクチャに基づいてクラスの設計を行なっています。この辺りの考え方は、アプリ開発入門からその次の段階に移行するために必要となってくる知識であると思います。

クラスの設計は、MVC(モデル・ビュー・コントローラ)アーキテクチャに準拠して行う。これが、Cocoa Touchフレームワークを利用するときの大原則だ。この原則から外れると、遅かれ早かれ、アプリ開発は頓挫することになるだろう。(p.44)

本書では、モデル、ビュー、コントローラのそれぞれについて実装の「パターン」*1が、再利用可能なプログラムとして提示されます。iOS開発力を底上げするために、この辺りのパターンが参考になるのではないでしょうか。

長くなってきたので、この辺で失礼します。

iOS開発におけるパターンによるオートマティズム

iOS開発におけるパターンによるオートマティズム

*1:いわゆるデザインパターンではない

【Swift】デリゲート(delegate)パターンのわかりやすいサンプルプログラムを書いてみました

f:id:ayb:20170524105747j:plain

iPhoneアプリの開発でわかりにくいデリゲート(delegate)パターン。その使い方をとてもわかりやすく解説しているサンプルがあったので、実際にコードを書いてみました。Playgroundで動かしています。

「絶対に挫折しないiPhoneアプリ開発超入門」に掲載されているサンプルです。詳しくは、本書を参照してください。

まずはこんな感じでクラスを定義します。弁護人(Laywer)クラスと被告人(Defender)クラスがあります。弁護士は被告人の代理人(Delegate)になります。

class Lawyer {
    func defend() {
        print("異議あり!")
    }
}

class Defender {
    var delegate:Lawyer?
}

太郎君は弁護人を雇い、弁護士に弁護(defend)を依頼します。

let taro = Defender()
taro.delegate = Lawyer()
taro.delegate?.defend()

この書き方の問題点は、弁護人(Lawyer)が本当に defend() メソッドを持っているかわからない、すなわち、雇った弁護人が本物の弁護士なのかわからない、という点です。

そこで、弁護士資格(Lawyer License)プロトコルを作ります。

protocol LawyerLicense {
    func defend()
}

被告人は、代理人としてLawyerLicenseを実装したクラス、すなわち弁護士資格を持った弁護人のみを弁護人として雇うことにします。

class Defender {
    var delegate:LawyerLicense?
}

弁護人は、弁護士資格を持っていることを示すために、LawyerLicenseプロトコルを批准します。デリゲートは必ずプロトコルを批准します。

class Lawyer:LawyerLicense {
    func defend() {
        print("異議あり!")
    }
}

これで、太郎君は弁護士資格を持った弁護人に弁護してもらえることが保証されます。

サンプルプログラムの全文はこちらです。

protocol LawyerLicense {
    func defend()
}

class Lawyer:LawyerLicense {
    func defend() {
        print("異議あり!")
    }
}

class Defender {
    var delegate:LawyerLicense?
}

let taro = Defender()
taro.delegate = Lawyer()
taro.delegate?.defend()

【Android】BroadcastReceiverで電源オンを検知する

f:id:ayb:20170524105925j:plain

AndroidのBroadcastReceiverで、電源オンを検知するための実装方法をメモしておきます。

まずはAndroidManifestのパーミッションRECEIVE_BOOT_COMPLETED を追加します。

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

次に、AndroidManifestのインテントフィルタに BOOT_COMPLETED を追加します。

<receiver android:name=".SampleBroadcastReceiver">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

BroadcastReceiver を継承したクラスの中で Intent#getAction() を使ってイベントを拾います。

public class SampleBroadcastReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {

        String action = intent.getAction();

        if(action == null){
            return;
        }

        switch (action){
            case Intent.ACTION_BOOT_COMPLETED:
                //do something here
                break;
        }
    }
}

たぶんこれで動くはず。

サンプルコードをGitHubに置いておくので、役に立ったらフォローやスターをもらえると嬉しいです。

github.com

「新装版リファクタリング 既存のコードを安全に改善する」を読みました

f:id:ayb:20170523142546j:plain

新装版リファクタリング 既存のコードを安全に改善する」を読みました。オブジェクト指向とテストの重要性に関する理解が深まる本。リファクタリングの具体的な手順をマニュアルに落とし込んでいるのも参考になって良いですね。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

リファクタリングとは

本書より抜粋。

  • 外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること(名詞)
  • 外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること(動詞)

振る舞いを保ったまま、コードを改良することをリファクタリングという。振る舞いが変わらないということが大切です。それを保証するためにテストを行う。

リファクタリングを読んだ感想

ソフトウェア開発でリファクタリングを行うときには、2つの活動に作業を区分すべきです。すなわち、機能追加とリファクタリングを区別するのです。機能追加を行うときには、既存のコードを変更してはいけません。(p.54)

機能の追加を行なっているときはリファクタリングを行わない、リファクタリングを行なっているときは機能追加を行わない。今、どちらの作業を行なっているのかを意識することが大切であると言っています。

リファクタリングしようと構えるのではなく、何かを行うための手段としてリファクタリングが行われます。そしてリファクタリングによって、次の作業が導かれるのです。(p.57)

リファクタリングはそれ自体が目的ではなく、何らかの目的があって行うものです。じゃあ、その目的とは何なのか。

リファクタリングに着手する第1の理由は、これから修正しようとしているコードを理解するためです。(p.58)

コードに対する理解を深めるためにリファクタリングを行う。意図が不明確なコードがあれば、その意図が明確になるようコードを修正する。容易に理解できるコードに置き換える。これがリファクタリングの第1の目標であると言っています。

リファクタリングを行うもう1つの理由は、容易に機能追加できない設計があるからです(p.58)

そのままでは機能を追加することが難しいコードを修正して、機能の追加が容易なコードに修正する。機能追加を容易にするためにコードを修正することが、もう一つのリファクタリングの目標になります。

リファクタリングを1回してしまえば、機能の追加はずっと手早く簡単にできるようになります。(p.58)

リファクタリングを行うことにより、機能の追加が容易になること。これがリファクタリングを行う動機付けの一つになります。

リファクタリングはゲームのようなものです。システムの現在の振る舞いを保ったままで、どのようにしてシステムをより品質の良い、コストの低い、価値あるものにできるかということなのです。(p.62)

振る舞いを変化させずに、コードの価値を高めてくれるのがリファクタリングです。ゲームのように楽しみましょう!Enjoy!

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

「github.io」ドメインのサイトを作る方法

f:id:ayb:20170523142803j:plain

GitHubには「GitHub Pages」という仕組みがあって、「アカウント名+github.io」というドメインに静的なウェブサイトを無料でホスティングすることができます。

レンタルサーバーを借りる必要も、FTPソフトを使う必要もなく、お手軽にウェブサイトを作れて便利です。github.ioドメインになるので、エンジニアやデザイナーのポートフォリオサイトに使うと良いのではないかと思います。

わたくし(okuzawats)であれば、下記のURLにウェブサイトを作ることができます。

https://okuzawats.github.io/

github.ioドメインのウェブサイトを作る手順は以下の通りです。

  1. GitHub上に「アカウント名+.github.io」という名前のリポジトリを作成する(例:okuzawats.github.io)
  2. リポジトリをローカルにクローンする
  3. リポジトリに静的なウェブサイトのソースを置いて、GitHubにpushする

これだけでgithub.ioドメインのウェブサイトを構築することができます。しかもSSLです。

f:id:ayb:20170523132837p:plain

「静的サイトジェネレータ」と呼ばれるツールを使えば、GitHubページ上にブログを作ることもできます。OctoPressやHugoといったものが有名ですね。

GitHubにはこの他にも、プロジェクトのウェブサイトを作る機能もあるようです。わたくしは使ったことがないのでここではこれ以上触れません。