koogawa blog

iOS、Android、foursquareに関する話題

はてなブログ 独自ドメインを解除したときのメモ

前提

独自ドメイン koogawa.com を"さくらインターネット"で取得済み

やりたかったこと

独自ドメイン blog.koogawa.com をやめて、 koogawa.hateblo.jp に戻したかった。

例)

旧:http://blog.koogawa.com/entry/2020/10/03/230000

新:https://koogawa.hateblo.jp/entry/2019/02/01/113000

  • ドメインにアクセスが来たら新ドメインにリダイレクト(301)したい
  • URLが変わってしまうため、ブックマークもリセットされてしまう。これも統合したい

やったこと

ゾーン設定

独自ドメインを設定するときに追加した CNAMEレコードを削除。

↑つまり、これと逆のことをやる!

さくらのコントロールパネルからサブドメイン追加

ドメイン/SSL からサブドメイン blog.koogawa.com を追加して SSL(Let's Encrypt)対応。

f:id:koogawa:20201021091751p:plain

.htaccess 設定

blog.koogawa.com にアクセスが来たら koogawa.hateblo.jp にリダイレクトかける。

RewriteEngine On
RewriteCond %{http_host} ^blog.koogawa.com
RewriteRule ^(.*) https://koogawa.hateblo.jp/$1 [R=301,L]

はてなブックマーク統合

この方法で統合できた。

反映されるまでに長い時間がかかることがある、とのこと(実際まったく反映されなかった)。すぐに統合したい場合は「情報を更新する」を、記事ごとに実行する必要がある。

できなかったこと

はてなスターの引き継ぎはできなかった・・!すべてリセットされてしまった

個人ブログとQiitaとZennの使い分け

数年前にこんな記事を書いたのですが、最近 Zenn という新サービスが話題になっているので、改めてそれぞれの特徴を比較した上で、使い分けを整理していきます。

それぞれの特徴

個人ブログ

  • 技術以外の記事でも、なんでも自由にかける
  • デザインのカスタマイズが自由
  • ドメインも好きなものに設定できる
  • ブログサービスによっては公式アカウントがピックアップしてくれることも(はてなブログ、note 等)
  • 有名ブロガーでない限り、まったく読まれないこともある

Qiita

  • 「プログラミングに関する知識を記録・共有するためのサービス」であり*1、ポエムを書くと怒られたりする
  • LGTM機能がある
  • ストック機能もある
  • 記事に対するコメントができる
  • ユーザー、タグをフォローし、フィードに流すことが可能
  • 自分が獲得した総LGTM数が Contributions としてプロフィール画面に表示される
  • 自分が書いた記事を修正するとき、ストックしてくれたユーザに通知を送ることができる
  • Organizations 機能があり、ユーザーは複数の組織に属することが可能
  • SEOが強い💪
  • 新着記事が各タグのフィードに流れるので、誰が書いた記事でも、ある程度は読んでもらえる
  • 1日/週間/月間 単位で、人気の記事がトレンドページに表示される
  • LGTMが増えるとTwitter公式アカウントがピックアップしてくれる
  • LGTMが多い記事は週刊メールマガジンにピックアップされる(効果大)

Zenn

  • 「知見を共有するプログラマーに対価を」をコンセプトとした情報共有コミュニティ
  • 著者への 金銭的なサポート機能 がある
  • 本を書いて、無料/有料で公開できる
  • 記事を書く際、Tech(プログラミングに関する技術記事なのか)or Idea(考え方やポエム)を明確に選べる
  • いいね機能がある
  • バッジ機能がある(一日で最も人気のあった技術記事に対して付与される、等)
  • 記事にdiscussion欄があり、ユーザーは自由に投稿できる
  • Qiita のように、自分が獲得した総いいね数はどこにも表示されない
  • GitHubリポジトリとの連携機能がある
  • SEOはQiitaより弱い印象
  • 新着記事が各タグのフィードに流れるので、誰が書いた記事でも、ある程度は読んでもらえる
  • Tech, Idea, Book ごとのトレンド画面、タグごとの話題記事などがある
  • Twitterの公式アカウントが記事をピックアップしてくれることもある

それぞれの特徴を表にまとめてみます。

個人ブログ Qiita Zenn
共有できるもの なんでも自由に書ける プログラミングに関する知識 - プログラミングに関する技術記事
- 本(無料/有料)
- キャリア、チーム、仕事論、ポエムなど
いいね機能 サービスによる LGTM、ストック いいね
コメント機能 サービスによる あり あり
フォロー機能 サービスによる あり なし
グループ機能 サービスによる Organizations なし
ゲーミフィケーション サービスによる ない? バッジ機能
マネタイズ サービスによる ない 金銭的なサポート機能、本の売上
記事ピックアップ サービスによる - トレンド画面
- Twitter公式アカウント
- メールマガジン
- トレンド画面
- Twitter公式アカウント
SEO サービスと、著者の影響力による 強い

使い分け

それぞれの特徴を踏まえ、使い分けを考えてみます。

ブログ

  • 雑な技術メモ
  • 本の感想
  • アプリやイベントの宣伝
  • 技術と関係ないポエム
  • 勉強会レポート
  • 雑多なメモ
  • 入社・退職エントリ
  • 誰かの役に立つ、というより、自分の考えを整理するためのもの

Qiita

  • プログラミングに関わる内容
  • ググってたどりついて欲しい内容
  • 今後もメンテナンスしていく予定があり、その都度、読者に変更内容を通知したい記事
  • 誰かの役に立つことが目的であり、対価は求めない

Zenn

  • 誰かの役に立ち、かつ、対価も得たい
  • 渾身の記事である
  • 本を書きたい、販売したい

そんなわけで、この記事は「個人ブログ」に書いてみました。

「オンライン勉強会あるある」とその改善策

これは何

この記事では私が色々なオンライン勉強会を主催・参加してきて

  • この時間はもっと短縮できるなー
  • このやりとりは本来不要だよな

と感じた所謂「オンライン勉強会あるある」と、その改善策についてまとめていきたいとおもいます。

※主に Zoom を使った勉強会を想定しています


画面共有しようとしたら権限がないと言われて進行が中断する

自分の発表順が回ってきて、いざスライドを画面共有しようとしたら次のようなエラーが出て発表をスタートできないパターンです。

f:id:koogawa:20200613220926p:plain

これはホストが参加者の画面共有を許可していないためです。

回避策:ホストが参加者の画面共有を許可する設定にする

ホストが「画面の共有」ボタン右の^をクリックし、「高度な共有オプション…」を選択します。

f:id:koogawa:20200613221937p:plain

共有できるのは誰ですか?を「全参加者」にします。

f:id:koogawa:20200613235152p:plain

これで参加者も画面共有できるようになります。

画面共有しようとしたら色々アクセス権限を求められて時間かかる

自分の発表順が回ってきて、いざ画面共有しようとしたら次のアラートが出て、「あっ、、ちょっとお待ち下さいね」となってしまうパターンです。けっこう焦るので、このあとの発表にも影響が出かねません。

f:id:koogawa:20200613222445p:plain

回避策1:勉強会開始までに接続確認させてもらう

接続確認の時間を設けている勉強会もありますが、ない場合は自分からお願いしましょう。

回避策2:事前に画面共有の練習をしておく!

Zoomさえインストールしておけば、事前に画面共有をシミュレーションしておくことができます。勉強会開始までにアクセス権限は許可しておきましょう。

画面共有したいスクリーンが見つからない

自分の発表順が回ってきて、いざ画面共有しようとしたら共有したいスクリーンが見つからなくて焦るパターンです。

f:id:koogawa:20200613223541p:plain

とくにデュアルディスプレイ/トリプルディスプレイにしている場合は選択肢が複雑になるため、あたふたしてしまう方が多いようです。また、プレゼンテーションアプリをフルスクリーンにした際に「発表者用画面(経過時間や次のスクリーンが表示される)」がオーディエンスに見えてしまうケースも何度か見ました。

回避策1:事前に画面共有の練習をしておく!

やはり事前に一度練習しておくことが重要です。とくにデュアルディスプレイ/トリプルディスプレイにしている場合は、どのディスプレイがオーディエンス側に配信されるのかチェックしておきましょう。

回避策2:発表中はシングルディスプレイにする

面倒でなければ、発表中は外部ディスプレイを切断し、シングルディスプレイにしてしまうことで上記のリスクが減らせます(自分はけっこうやる)。

発表を終えた人が画面共有したままにしがち

自分の発表順が回ってきて、いざ画面共有しようとしたら前の発表者が画面共有したままになっていて画面共有できないパターンです。「◯◯さん、画面共有を切ってもらっても良いでしょうか・・!」とお願いすれば解決するのですが、ちょこっとだけ気不味さがあるので、なんとか仕組みで解決したいものです。

回避策:複数の参加者が同時に画面共有できるようにする

ホストが「画面の共有」ボタン右の^をクリックし、「複数の参加者が同時に共有可能」にチェックを入れます。

f:id:koogawa:20200613233359p:plain

これで複数の参加者が同時に画面共有できるようになります。

注意点としては、画面共有している人は、共有している自分のパソコンの画面しか見えないという点です。つまり、自分の発表が終わっても画面共有をオフにしない限りは、次の発表者の画面を見ることができません。自分の発表が終わったら画面共有を完了するようにしましょう。

※画面共有の実験は ( @shu223 ) さんに手伝っていただきました🙏 ありがとうございました!

iOSアプリ開発者がmacOSアプリ開発したときにやったこと

本日「真実の鏡」というmacOSアプリをリリースしました🎉

真実の鏡

真実の鏡

  • Kosuke Ogawa
  • Utilities
  • Free

私たちが普段、鏡や自撮りカメラなどでよく見ている自分の姿。実は左右が逆になっていることはご存知だと思います。このアプリは、実際に周りから見えている「本当の顔」を映し出すアプリです。よかったら使ってみてください。

✁ 宣伝ここまで ✁

↑でもつぶやいたんですが、macOS アプリに関する技術書はホントに少ない!!

というわけで

この記事では、今までにiOSアプリしか開発したことしか無い開発者が、初めてmacOS開発をする上で実践したこと、気付いたことなどをメモしたいと思います。

目次


shu223 さんの本を読んだ。

まず発見したのは shu223 さんの本!

shu223.hatenablog.com

iOSエンジニアの視点から「これ、macOSではどうやるの?」という事項を集めてまとめてみました。

まさに自分にピッタリの本でした!この本から

  • UIKit⇔AppKit の関係(例:UIImageViewではなくNSImageView)
  • Xcodeでの新規プロジェクト作成方法
  • アプリのビルド方法

などを学びました。

ここまで1時間弱。

足りない部分はネットでググる

今回やりたかったことは次の3つ。

  • Macのカメラ映像を表示するビューを2つ配置
  • 片方は左右反転した映像
  • もう片方は左右反転していない状態(つまり真実の顔)の映像
  • 目立たない場所にバナーも出したい

良い感じにググってヒットした記事を参考にさせて頂き、なんとか実装できました。

ここまで4〜5時間。

macOSに対応した広告SDKがない

このあたりで気付いたんですが、どうやら macOS に対応した広告SDKは殆ど無いようです!!

macos - How to put ads in apps for Mac App Store? - Stack Overflow

もし、macOS にも対応した広告サービスをご存じの方がいましたらぜひ教えてください🙏

ググり方にはコツがある

macOS アプリ開発の情報をググろうとして macOS 知りたい情報 で検索すると、技術記事ではなくMacの使い方に関する記事が多くヒットしてしまいます。この場合は Cocoa 知りたい情報 で検索すると、期待した情報にたどり着けることが多いです。

アプリ申請に関する情報も少ない

macOS アプリ申請に関する情報もなかなか見つかりませんでした。自分の場合は iOSアプリの申請を何度もしてきたので、 雰囲気でなんとか乗り越えた感があります💪(Certificate の作り方は基本的にiOSと一緒)

意外だったのは、macOSアプリの場合もスクリーンショットのサイズが決まっていること。

次のいずれか(アスペクト比 16:10)。 
1280 x 800 ピクセル 
1440 x 900 ピクセル 
2560 x 1600 ピクセル 
2880 x 1800 ピクセル 

https://help.apple.com/app-store-connect/#/devd274dd925

macOS アプリの画面サイズはアプリによってバラバラなので、スクリーンショットは良い感じに上記サイズに加工してあげる必要があります。

リジェクトされた!!

勝手もわからないし、一発で審査が通ることはないだろうなーと思ってましたが、申請出してから1日後、やっぱりリジェクトされました。

リジェクト理由は次の2つ。

2. 3 Performance: Accurate Metadata (macOS)
4. Design: Preamble (macOS)

Guideline 2.3.8 - Performance

We noticed that your app name to be displayed on the App Store does not sufficiently match the name of the app displayed when installed on macOS.

iTunes Connect Name: 真実の鏡
App Name when Installed: mirror
App Name when Launched: 真実の鏡
App Name in About/Hide/Quit Menu: mirror

iTunes Connectに登録された名前と、実際にアプリを起動したときに表示される名前が一致してないよ!ってことですね。 Appleのレビュアーさんが丁寧に Next Steps を提示してくれたので、その通りに修正。

2つ目のリジェクト理由はこちら。

Design Preamble

The user interface of your app is not consistent with the macOS Human Interface Guidelines.
Specifically, we found that when the user closes the main application window there is no menu item to re-open it.

ユーザーが✗ボタンでWindowを閉じると、再度Windowを開く術がないよ!ということですね。

ご存知の通り、Macの場合は✗ボタンで Window を閉じてもアプリ自体は生きているんですよね。ここで再び Window を開けるようにしておかないとリジェクトされてしまうようです。

macos - Design Preamble Mac OS X Mas - Stack Overflow

対処法をググると、上記の記事がヒットしたので、次のコードを追加し、

func applicationShouldTerminateAfterLastWindowClosed(_ sender: NSApplication) -> Bool {
    return true
}

✗ボタンをクリックしたらアプリ自体を終了するように修正しました。

無事リリース!

そんなこんなで、6/9 に無事、人生初の macOS アプリをリリースすることができました。

f:id:koogawa:20200609070008p:plain
時間がなかったので自分の写真を使いました
よかったら使ってくださいね!

オンライン勉強会の課題

先日、Swift Zoomin' というオンライン勉強会をZoom上で開催しました。

swift-tweets.connpass.com

おかげさまで大きなトラブルもなく、イベントは無事終了しました。

一方でいくつか課題も見えてきたので以下メモしておきます。

発表者が孤独問題

発表者の皆さんが共通しておっしゃっていたのが「発表中、不安になる」ということでした。

オフラインの勉強会と違ってオーディエンスの反応がないので、本当に聴こえているのか不安になる、顔が見えないので興味を持ってもらえているのかわからない、などの課題があるようです。

オーディエンスもマイクをオンにして、「うんうん」「なるほど!」などの相槌を打つようにすれば不安が減るかもしれません。しかし、相槌が発表者と被って話が聞こえなくなる問題もあるので難しいところですね。この辺りはソフトウェアがそのうち解決してくれると良いですね(発表者の声は自動的に◯倍にしてくれる等)

オーディエンスの顔が見えない問題は、オーディエンスも積極的にビデオをオンにするようにして(もしくはバーチャルアバターを使う)、ちょっと大袈裟なぐらいにリアクションを取ると良いかもしれません。

音声が聴こえていない方には音声で案内ができない

「音声が聴こえていない方いますか?」みたいな質問をついつい音声でやってしまいました(聴こえるわけがない😅)。

いや、普通に考えたらわかることなんですが、当日はテンパってこんなことをやってしまいがちです。。!

次回からは落ち着いてチャットでご案内するようにします🙏

オーディエンスが自分でミュート解除できるようにしても良さそう

最初はオーディエンス自身がミュートを解除できない設定にしていたのですが、質疑応答タイムでディスカッションが始まる場面があったので、途中から喋りたい人が自身でミュートを解除できる設定に切り替えました。

発言が終ると皆さんきちんとミュートに戻してくれるので、ミュート設定はオーディエンスに任せても良さそうです。

100人中参加してくれたのは63人

今回はZoomのプランの関係で参加者枠を100名に絞りました。100名の枠に対し、160名の応募があったので60名の方には残念ながら補欠にまわっていただきました。しかし、実際に参加いただいたのは100名中63名ほどでした。(補欠の皆さまごめんなさい🙏)

オフラインの勉強会でも欠席率を見越して参加者枠を設定する、といったことをよくやると思うのですが、オンライン勉強会だと予想が外れたときに「詰めて座ってもらう」「立ち見してもらう」ことができません。

これはもう申し込んでくれた方を信じるか、Zoomのウェビナー機能等を使って参加枠を増やすしかないのかもしれません。

***

課題ばかり書いてしまいましたが、次のようなありがたいお言葉も頂いたので、第1回目のイベントとしては成功だったんじゃないでしょうか!参加いただいた皆さま、本当にありがとうございました😄

Qiita に downvote(よくないね)機能は必要か?

Qiita に downvote(よくないね)機能は必要か?

先に結論を言ってしまうと、私は不要だと思います。

きっかけ

あえてURLは貼りませんが、この内容を初学者が真似してしまったらまずいだろうなぁ、という記事を見かけてしまったからです。

仮に downvote 機能があったらどうなるか

今回、自分が見つけたような記事には容赦なく downvote がつけられ、投稿者は深く傷つき、もしかすると記事を消してしまうかもしれません。結果的に間違った情報はネット上から消えるのですが、果たしてそれで良いのでしょうか。。。🤔

一緒に記事を育てていく

Qiita にはコメント欄と編集リクエスト機能があります。せっかくならそれらの機能を使って、どこが良くないかをコメントで教えてあげたほうが結果的に記事の質も上がっていくと思うのです。投稿者自身も誤りに気付ける。

これがもし downvote という形だと、どうしてもネガテイブな方向にしか進まないと思うんですよね。自分の書いた記事が「よくないね」と人前で言われて、「よし、良い記事にしていくぞ!」と考える人はあまりいないと思うのです。だから、私は downvote 機能は不要だと考えます。

***

今日書きたいことはそれくらいです。