kumamotone’s blog

iOS/Android アプリエンジニアです https://twitter.com/kumamo_tone

AtCoder Beginner Contest 159 (ABC159) A,B,C 解説

atcoder.jp

自分は出なかったのだが、全体的に数学っぽい問題だったっぽい。実際(実際って何?)、AからCまでfor文ひとつ書かずに解くことができる。

自分はコンピュータサイエンス修士取ったくせに数学苦手意識がすごく強いので、Twitterの感想見てて自分が参加してたらつらそうだったな〜と思った。

ついでに見たPDF版の解説が分かりにくかったのだが(すいません、個人の感想です)解説動画の内容がわかりやすいと思ったので、補足しつつ書き残しておく。

PDF: https://img.atcoder.jp/abc159/editorial.pdf

www.youtube.com

A - The Number of Even Pairs

問題概要

偶数が書いてあるN個のボールと奇数が書いてあるM 個のボールがある。ここから2つ選んで、書かれた数の和が偶数になるパターンの数を求めよ。

答え

偶数が書いてあるボールのグループ、奇数が書いてあるボールのグループから、それぞれ1個ずつ取る場合は絶対に奇数になる。

逆に、同じグループから選ぶ場合は絶対に偶数になる。

なぜなら、偶数、奇数の性質上、

  • 奇数+奇数=偶数 // いいね‥

  • 偶数+偶数=偶数 // いいね‥

  • 奇数+偶数=奇数 // ダメです

となるので。

そのため答えは

N個のボールから2個選ぶ= {} _NC_2 =  \dfrac {N(N-1)}{2} パターン

M個のボールから2個選ぶ= {} _MC_2 =  \dfrac {M(M-1)}{2} パターン

を足したものになる。

ちなみに  {} _nC_r ってなんだっけとなったときは、ググる

 {} _nC_r =  \dfrac {n!}{(n-r)!r!}

ということがわかり、今回 r=2 なので

=  \dfrac {n!}{(n-2)!2!}

=  \dfrac {n(n-1)(n-2)(n-3)...}{2(n-2)(n-3)...}

=  \dfrac {n(n-1)}{2}

となる。

int main() {    
    int N, M;
    cin >> N >> M;
    int ans = N*(N-1)/2 + M*(M-1)/2 ;
    
    cout << ans << endl;
    return 0;
}

書きながら N*(N-1)/2 の結果って常に整数になるの?って一瞬思うが、これも偶数と奇数の性質上、

  • Nが奇数だったらN-1は偶数
  • Nが偶数だったらN-1は奇数
  • 奇数×偶数は常に偶数

のため、絶対 N(N-1) は偶数となり、2で割っても大丈夫。

B - String Palindrome

atcoder.jp

問題概要

akasaka のような、回文な上に、中心の文字の左右の文字列も回文になっている文字列かどうか判定せよ。

答え

問題文が厳密な書き方をしているので一見”"強い""回文って何?って思うが、上記の概要みたいなことを言ってるというのに気付ければ、そのまま実装すれば良いとなる。

まず回文かどうかは、以下の関数で求められる。

bool isPalindrome(string s) {
  string t = s;
  reverse(t.begin(), t.end()); // t をひっくり返したやつが
  return s == t; // 同じだったら同じ
}

文字列をひっくり返す方法は最近の大体の言語で関数化されてるはずなのでC++以外の場合はそういうのを使うとよさそう。

あとは、全体を回文かどうか判定したあとに、真ん中の文字から左の文字が回文になっているかどうかだけ判定すれば実は右側の文字は判定しなくて良くて、以下のようになる。

int main() {
    string s;
    cin >> s;
    bool ans = true;
    if (!isPalindrome(s)) {
        ans = false;
    }
    string leftSub = s.substr(0, s.size()/2);
    if (!isPalindrome(leftSub)) {
        ans = false;
    }
    
    cout << (ans ? "Yes" : "No") << endl;
    return 0;
}

C - Maximum Volume

問題概要

縦、横、高さの長さの合計が L の直方体としてありうる体積の最大値を出力せよ。

答え

直感的に(は?)、縦、横、高さが同じの場合に体積が一番でかそうだと気づいた場合、縦、横、高さがLの1/3のときの体積を求めればいいじゃんとなる。

なので、シンプルに

(L/3)3

を計算すれば良い。

int main() {
    double l;
    cin >> l;
    double ans = pow(l/3,3);
    cout << fixed << setprecision(12) << ans << endl;
    return 0;
}

なんだその直感は

これだけで問題は解けるが、マジでそれで大丈夫か?となる。

これは相加相乗平均不等式というやつで証明できるっぽいが、もっと直感的に(?)確かめる方法がある。

まず、縦、横、長さが同じときの体積を a×a×a …(1)とする。

その状態から、ほんのちょっと ε だけ長さを変えたときの体積は、 a(a + ε)(a - ε) …(2) になる。

このとき、 (1) と (2) を比較すると、

a×a×a と a(a + ε)(a - ε)

a×a と (a+ε)(a-ε)

a2 と a2 - ε2 // 左のほうが絶対デカいね

となり、ε>0 (ほんのちょっとって言ってるのに0だったらズルじゃん?)から、 (2) は (1) より ε2 ぶん小さいので (1) のほうが確実にデカい、となる。

なので 、縦、横、長さが同じときの体積が一番デカい。よかったですね。

感想

ここまででもむずいなあとなり筆をおいてしまったのだけどCまで8,201人中7,134人解けてるので、たぶん標準的な参加者的にはそうでもないんだろうな…と思うとぐんにょりしてしまった

HerokuにMySQL+NginxのRailsアプリを移管した

さくらのVPSで運用してたRailsのアプリだが、ほとんど放置状態になっているのにも関わらず月1000円ぐらい払い続けているのがもったいないのでherokuのフリープランに移管した。

つまずきつつ解決したことなどを健忘録的に書き残しておく。

Ruby や gem のバージョンアップ

Macの場合入れるだけで大体つまずく

stackoverflow.com

qiita.com

次からはDocker使ったほうがええんじゃないかと思った。シンプルにググったらなんとかなるものが多いからがんばれ

一回 Gemfile.lock を消して bundle install して一気に依存解決するという技があった

precompile

デプロイはGithubリポジトリ指定するだけで簡単にできたがCSSがあたっていない。

precompileに設定が必要で、まず下記のgemをproductionに指定する。

gem 'rails_12factor'

あとは bundle exec rake assets:precompile もしておく。

DBのインポート

DBはプラグインという形で提供されている。

PostgreSQLで問題ない場合はPostgresを使うのが無難っぽいが、MySQLを使いたかった。

devcenter.heroku.com

heroku addons:create cleardb:ignite というコマンドでインポートできると公式に紹介があるが、--fork コマンドはMySQLサーバーがpublicにアクセスできるところにある場合に使えるみたいで、無効なURLを渡しても静かに失敗する。

JawsDBはフリーの制限が結構厳しくて、DBのサイズによってはINSERT時に勝手にRejectされたりするっぽい。

stackoverflow.com

で結局いかの記事を参考にClearDBにmysqlコマンド使って書き込むってやつをやった。

fuzzyblog.io

JawsDBを例に書いてあるがClearDBでも同様にできる。ホスト名とかパスワードとかどこ?!ってなるがheroku config で出てきたmysql:の連結URLをバラせばいける。

heroku config -a [app-name]

最後にDATABASE_URLを指定するのだが、そのときはmysql:をmysql2:に変更する。

heroku config:set DATABASE_URL='mysql2://~~~' -a [app-name]

独自ドメインの設定

設定のDNS Targetからアドレスを持ってきて

f:id:kumamotone:20200104154121p:plain

CNAMEに設定すればOK

f:id:kumamotone:20200104154101p:plain

以下日記

Mac上でRailsアプリだが、Herokuにはかなりあっさりデプロイすることができた。一方さくらのVPSはというと、VPS自体に罪はないのだけどなんかいつからかnginxのソケットがなんとかで落ちてて、productionのlogはlogrotateしてなかったので20GBとかになってた ほかにも罠は色々ある気がするけど日常的にサーバー管理してないのでもう1〜2年置くとさっぱり思い出せんし再度デプロイするのにサクッとできる自信は全然ない。マネージする範囲は絞ったほうがいいな〜と再実感しました。おわり

potatotips #67 に参加しました (iOSブログまとめ枠) #potatotips

potatotips #67iOS ブログまとめ枠で参加させていただきました。

f:id:kumamotone:20191217205228j:plain

会場はメルペイさん。

カンファレンスアプリをSwiftUIで作った / Masamichi Ueta さん

speakerdeck.com

Flutter製の2018年製カンファレンスアプリをSwiftUIでリライトした。MVVM、Dark Mode、Localization、Sign in with Appleなどの要素を盛り込んでいる。

Listの同じRowにNavigationLink2個おいたとき、各々別の画面に遷移してほしいんだがそうならなかった。ScrollViewにForEachでVStackを並べることで回避した。

PageViewでpopするとXcode11.2.1のビルドでクラッシュしていたが、Xcode11.3ではクラッシュしなくなっていた。

コードはOSSとして公開している。

github.com

ブログにも書いてある。

tech.mercari.com

GeometryReaderでSwiftUIのViewをキャプチャする / Takeshi Sato さん

speakerdeck.com

Viewのキャプチャ(スクリーンショット)を取りたい。

f:id:kumamotone:20191217195814p:plain

UIViewだとこうやるよね。でもSwiftUIのViewにはBoundsもCALayerもない。どうするか?

Bounds は GeometryReader で取ることにした。 CALayer は UIView に変換して取ることにした。

geometry.frame(in: .global)geometry.frame(in: .local) で座標を取る。(それぞれUIViewのframeとboundsに相当しそう)

UIView への変換は UIHostingController に渡してやって、UIWindow に add して visible にした状態なら view プロパティから取れる。

        let window = UIWindow(frame: CGRect(origin: canvasRect.origin,
                                            size: canvasRect.size))
        let hosting = UIHostingController(rootView: body)
        hosting.view.frame = window.frame
        window.addSubview(hosting.view)
        window.makeKeyAndVisible()
        return hosting.view.renderedImage

サンプルコード。

github.com

Integrating Function Builder / AkihisaSengoku さん

speakerdeck.com

Function Builderとはなにか、作り方と使い方など。

UICollectionView
CompositionalLayoutできれいなGrid Layoutをつくる / Yuichi Kobayashi さん

speakerdeck.com

Swiftサウンドプログラミングをはじめる〜メトロノーム編〜 / teruto_yamasaki さん

3通りの方法でメトロノームを実装してみた。サウンド再生スレッドの優先度は高く保つ。

Playground初心者から脱却するための3つのTips / 417_72ki さん

speakerdeck.com

Playground の中で左のペインを出して New Playground Page すると Playground の中で複数の検証ができるので実は playground 作りまくらなくて良い。

sources/ の中にSwiftファイルを追加できて、処理も共通化できる(注:internal じゃなくて public にする必要がある)

SwiftUI 導入で LLVM のドキュメント読む羽目になった話 / Akkey さん

qiita.com

Xcode Preview が動かないときがあった。どうやら static framework に関係していて、 Linker flags に -fprofile-instr-generate を追加すると動くようになるようだった。なんでなのかを LLVM のドキュメント読んで調べている(情報募集中)。

画面をUITableViewで作るリスクとその対応 / zwtin さん

UITableVIew はパフォーマンスが良いって言うけど有限のリストの場合UIScrollViewにぶちこんだほうがかえってスクロール時にかくつかずに体験がよくなることがある(それはそう)

そのほか

まんぷくむすびはうまい

大胆にリスクを楽しむ

この記事は SHIROBAKO Advent Calendar 2019 の 16日目です。(日付越えてしまいました‥すみません)

SHIROBAKOは、アニメ制作会社の現場を描いたアニメです。2014年10月から2015年3月まで全24話が放送されました。エンジニアやデザイナーの現場にも通じる状況が描かれていたこともあって、放映から4年以上経ったいまでも人気があるアニメです。来年2月29日に初の劇場版も公開されます。個人的には遅ればせながら去年の12月に初履修しました。

個人的にピックアップしたいのは22話のシーン。

「だって去年の今頃なんて、自分がアニメ制作に関われるなんて夢にも思ってなかったんすから」 「りーちゃんは怖くないんだね...」 「何言ってんすか絵麻先輩 怖いのは脚本家になれないことです!」

人間のリスクに対する感覚は基本的によくできていて、大勢の目に触れるとき、それ自体は別に危ないことではないはずなのに、「怖い=危ない」と本能が訴えかけてきます。

その感覚自体は大事にしてあげたら良いと思うのですが、怖さに流されてしまうのはときとして長期的なゴールを遠ざけてしまう(この場合は「脚本家になること」)のではないかと思います。

個人的に今年を振り返ってみると、批評にさらされるのを恐れて公開するのを後回しにしたり、話しかけるべき人に嫌われることを恐れて話しかけるのを後回しにしたり、わくわくより怖さが勝って身動きが取れなくなってしまった記憶がいくつもあります。

このような短期的な怖さをはねのけることは簡単なことではなく、このようなときに必要になってくるのが「脚本家になりたい」のような強い情熱だと思います。このような強いものがあるからこそワクワクが勝つ。自分もりーちゃんのように、怖さが気にならないほどに夢中になって、大胆にチャンスを掴みにいくという姿勢でやっていきたいです。

2016年4月に新卒で入社したヤフー株式会社を退職しました。

半年の丁寧なOJT形式の研修のあと、主にiOSAndroidアプリの開発を担当させていただきました。期間としては3年と8ヶ月になりますが、かなりいろんな経験ができて、成長できたと思います。Yahoo! JAPAN アプリをはじめ、多くの人に使ってもらえるプロダクトの機能開発に携わったり、新規プロダクトの開発に携わったり、社内ハッカソンで数人チームでプロダクトを作ったり、大小様々な規模の開発に携わることができました。副業は申請を出せばOKになっていて、副業で請けていたアプリ開発では、個人で1年強で200〜300万ほど稼ぐこともできました。(この頃に関してはそれなりにハードワークだったのできつかったですが…)。

また、社内での定期勉強会の主催や、大きなミートアップの主催をやらせてもらえたり、業務でカンファレンスに参加、登壇などさせてもらったりなどするうちに、自然と社内外の繋がりも増えてきて、社外からのお誘いや、経験の機会につながることもありました。学生のときにJavaC#などでGUIを書いていたのが経験として活きたのはありますが、入社したころはアプリ開発は完全に未経験だったことを考えると、かなりの変化だと思います。

この個人事業主でも稼げるし社外からもオファーがもらえるという経験はかなり精神的に良くて、大学院のときは「これで卒業できなかったら結構きついだろうし、中退したらどうやって生きていけばいいんだ…」という感じだったのに対して、今は「最悪やめてもなんとかなるかも」という感じで積極的にリスクが取れるようになり、精神的に楽になりました。(学び続けないとすぐ役に立てなくなりそうというプレッシャーもあるので、完全に楽という感覚もないですが…)

全体的にいわゆるホワイト気質で、フリーアドレスやリモートワークも推奨されているので働きやすく、毎週の1on1などで振り返りの機会が得られるし、社食など福利厚生も充実していて、こういった点などもかなり良かったと思います。

じゃあなんでやめるのかというと、ひとつは現状関わっているプロダクトの方向性とやりたいことの方向性が合わず、社内異動も叶わなかったこと、また、これはよくある話だとは思うのですが、(自分の場合)新卒の給与テーブルからちまちま昇給するのを待つより、一度転職する方が大きく収入を増やせてしまうということなどが大きな要因でした。その他の細かいネガティブな面などに関しては、こういったところに一方的に書くのはフェアじゃないと思いますし、退職時のインタビューなどで概ね正直にフィードバックさせていただいたので、内部でできるだけ受けとめてもらえることを願っています。あっでもこれだけは言いたい。週休3日制ってどうなったんですか?

人事発令が出てからは、退職を惜しんでくださる方がいたり、退職するにも関わらず、たくさんの人に前向きなメッセージをいただき、とてもありがたかったです。この会社でソフトウェアエンジニアとしてのスタートを切れて本当に良かったと思います。これからも引き続き頑張っていきます。

potatotips #65 に参加しました (Androidブログまとめ) #potatotips

potatotips #65 に参加させていただきました。

f:id:kumamotone:20191001200750p:plain

自分が所属しているヤフーで開催しました。

Android ブログまとめ枠の人がいなかったので軽く書いてみます。

5分でわかる Kotlin Contracts

speakerdeck.com

手前味噌ですが Kotlin Contracts を5分でわかるようにまとめてみました。

嬉しかった感想を拾います。

GitHub Actionsを用いたDeployGateアプリ配布の自動化

speakerdeck.com

デザイン確認用のアプリの配布が面倒だったので、Pull Request をダストデザイン確認用アプリが自動配布される仕組みを作った。

CIサービス、BitriseとかでもできるけどGitHub Actionsを検証を兼ねて利用してみた。

使い方や、つまずいたところなどを解説。

Secretが新しく生えている。

便利そう

TargetSdkVersion29で BottomNavigationが点滅する件

speakerdeck.com

TargetSdkVersion29(Android 10)で、BottomNavigation がちらつくバグがあった。

再現するリポジトリを用意しました。

github.com

パッチを上げたがすでにissueが上がっていた。モンキーパッチを当ててなんとかすることもできるが、基本対応されるのを待ったほうが良いかも

そのほか

のみもの

たべもの

おつかれさまでした。

iOSDC 2019 に参加しました #iosdc

iOSDC 2019 に参加者として参加しました。

愛社精神のある服装で参加したりブースのお手伝いをしたりしました。

pixivの社員さんにリジェクト除御守もらいました。凝りすぎててやばい。

ブースでCyberAgentさんから大吟醸いただきました。こんな載せてもらったり景品もらえたりで光栄ですがもっとスコア出せると思ってたのでちょっと悔しいぜ

今回結構いい写真取れたと思うのでみて↑

とくにお気に入りの発表

今回見れていない発表も多いので、たまたま見れた範囲の話になります。また、厳選3本になります。

speakerdeck.com

iOSアプリ設計パターン入門の著者でもあるtakasekさんのLT。著書でも説明されていたSOLID原則について、わかりやすい比喩をもとに説明されていました。

よくプログラミングの勉強をしていて「これって人生と同じだよな」みたいなことよく思うので共感できました。

speakerdeck.com

個人的にモバイル決済に興味があるので、モバイル決済アプリをとりまく社会的背景、法律の話、Apple PayやJPQRの話などが、かなりわかりやすくコンパクトにまとまっていて大変良かったです。

個人的にこういったカンファレンスでは、自分の知識の幅を広げたいという側面もあるため、自分の中のそういったニーズにこたえてくれる発表でした。

また、プレゼンテーションのスピードや、話し方がとても聞きやすく、話に集中できました。

speakerdeck.com

SDKを使わずにiOSの機能を使ってデジタル化粧をどのように実現するかという内容でした。

ハイパスフィルターや階調反転、オーバーレイなどおそらくこういった画像処理では基本的なテクニックを、実装を見ながらわかりやすく説明されていました。

PhotoShopチュートリアルを参考にフィルターを実装するというのが、なるほど色々応用がきいて(よくある話なのかもしれませんが)かしこい方法だなー!と思いました。

OSSという、わかりやすく、人に役立つフォーマットでちゃんとアウトプットを出しているという点も素晴らしいと思います。

そのほか

まとめありがてぇ

ぼやき

良いところもある一方で、もやもやした気持ちになるところもありました。

たとえば、今年はなんとか反省を生かして自分は取ることができたのですが、懇親会のチケットが取りづらい、チケットの存在に気づけなくて悲しい思いをしている人を見て悲しい、という経験は、一昨年、去年に続いて今年もありました。このフィードバックは過去にもアンケートなどを通じて行っているのですが、今年は(JOKERチケットの存在はあるとはいえ)さらにわかりづらくなっているように感じました。

おそらく個人的にこういったカンファレンスによく参加するようになって、過剰に色々なことが気になってしまうようになってしまっているだけのような気はします。他にももやもやした部分に関しては色々あるのですが、オープンな場に書いて炎上するようなことは自分も望まないので、アンケートがオープンしたらできるだけ静かにフィードバックさせていただければと思っています。

ただ、こういったネガティブな感想は、SNSなどでオープンに発言してしまった結果、「なんで運営に直接フィードバックしないんですか?」みたいなツッコミを食らっているところも、個人的によく散見します(あとはフード関連にコメント飯食いに来てるわけじゃないんだからwみたいな)(特定の個人や発言を指したものではありません)。

誹謗中傷はもちろん駄目なのですが、こういった問題意識に対して「運営が頑張ってくれてるんだから文句言うなよ!」的な同調圧力のようなものも(勝手に)感じていて、若干の生きづらさを感じています。より意見しやすい、風通しの良い風潮になることを望んでいます。

おわりに

f:id:kumamotone:20190908095913j:plain

なんやかんや書いてしまいましたが、新しい知見を得たり、色々な方と交流することもでき、大変ありがたいカンファレンスでした。 色々な人の努力や気持ちで成り立っていると思います。みなさまおつかれさまでした。ありがとうございました。