settingsに特定のキーで設定する。Xcodegenはキーさえわかれば、ほとんどの設定は指定することができる。
application_name: settings: SWIFT_OBJC_BRIDGING_HEADER: "path/BridgingHeader.h" ``
settingsに特定のキーで設定する。Xcodegenはキーさえわかれば、ほとんどの設定は指定することができる。
application_name: settings: SWIFT_OBJC_BRIDGING_HEADER: "path/BridgingHeader.h" ``
2020年1月20日現在の話です。
OpenAPI(Swagger)で書かれた定義ファイルからswiftのクライアントコードを生成する場合に、openapi-generatorを使おうと考えると思います。しかし、下記のようなコマンドで生成されるコードはコンパイルはできるもののそのままでは動いてもレスポンスを返すことは決してないコードが生成されます。この回避方法を2つ紹介します。
openapi-generator generate -i openapi.yaml -o src/ -g swift5
生成されるコードにlibraryを指定することによって、デフォルトに指定されている。URLSessionを使った壊れた実装のコードを回避します。libraryで指定できるのは現状だと alamofire だけのようです。
openapi-generator generate -i openapi.yaml -o src/ -g swift5 --library alamofire
openapi-generatorを使うのを諦めてswagger-codegenでコードを生成することで回避する方法です。openapi-generatorで生成されるコードと大体同じものが生成されます。
深夜のノリで書いているのであまり真に受けないで欲しい。
私が思っていた違和感が、スクラムガイド2020年版がでて変更によって言語化できると思ったので書きました。
と思う。スクラムガイドにはサーバントリーダーや真のリーダーと書かれているけれども日本的なリーダーではない。つまり、役職的な上位のものがスクラムマスターになるわけではない。偉いわけでもないし、インクリメントの出来に責任も取らない。自己改善していけるスクラムチーム作りに責任を持つ。
スクラムチームが目指していくべきことは、自分たちを改善していけるようにすることである。スクラムマスターはより良いスクラムをするためにリードする人である。スクラムマスターはより良いスクラムをするために支援し導く人である。それをするために、複数チームに跨っていたり、逆に1チームに複数いてもいいと思う。会社としての役職はリーダーである必要はない。スクラムの概念に会社の役職としてのリーダーはない。
スクラムマスターが開発者の開発速度を測ったり改善するためのツールを開発したり探してきたりすることがあると思う。この仕事はスクラムマスターがする仕事ではないと思う。スクラムチームが目指していくべきことは、自分たちを改善していけるようにすることなので、開発者が開発者のことを改善するためのツールを開発したり探してくることは、開発者がやるべきことである。
同様に、プロダクトオーナーがプロダクトをより良くするためのことは、プロダクトオーナーなり開発者がやればいいことなのでスクラムマスターがやる必要はない。
自分たちを改善を行う何かをインクリメントとして含めるべきである。そうすれば、開発者を行う理由ができる。プロダクトは、コードだけの部分をさす言葉ではない。付随するサービスもさす言葉である。開発者は、利用可能なインクリメントのあらゆる側面を作成することを確約する。「あらゆる側面」を狭めるべきではない。
経験的にスクラムマスターがやれば早いできるかもしれないが、やる必要はない。
個人的には最終的には自分自身をクビにすることだと思う。要らなくていいなら要らない役割だと考えている。開発者とプロダクトオーナーがより良いスクラムを自分たちで改善していけるなら、スクラムマスターは必要ない。
別のチームに行ってたまに様子を見にいくくらいになればいい。別のチームないなら元の役割に戻るなり、社内ニートするなりしていいと思う。
というか社内ニートを目指すべき
「そういう価値観もあるよね」という生暖かい気持ちで読んで欲しい
リリースされたコードの価値はそのコードが達成すべき目標に対する指標で測る。例えば、売上やユーザー数、PVです。本来の目的にそった指標で測ることによって目的に最短で達成できると考えるからです。
新しい機能は指標をどれだけ上昇されると予測されているかで評価されるべきです。この記事ではこの指標を予想評価値と呼ぶことにします。各機能は予想評価値と作成時間を考慮して、優先順位を決めます。
完全に出来上がっていてデプロイボタンを押せばリリースされるコードの価値は、リリースされていないので無価値とも言えるし、ほとんど予想評価値とも言えます。間をとって、予想評価値の半分の価値だとします。リリース日が決まっているとかあると思うが、デプロイすれば予想評価値が二倍になるので、リリース日にデプロイボタンを押す必要のない作り方をした方が素早く価値を高めれます。
予想評価値が付けれる程度の状態。まだ、作成時間も予想していない状態。
コードとしては価値がある物は一切ないのでほとんど無価値だと言えます。
アイディアがなければ良いプロダクトもないのでアイディアにはには別の価値を与えた方が良いです。
1つの機能を作るためには、複数のサブ機能を作り組み合わせることで作っていくと思います。サブ機能ごとに仕様を考えて作っていきます。仕様に沿ったものを作ってはマージしていきます。仕様からマージするまでの段階を経るごとに2倍以上の価値を持つと考えています。例えば、レビューされているコードはレビューされていないコードの2倍以上の価値があし、マージされいるコードはレビューされているコードの二倍以上の価値があります。
アイディアからリリースするまでに大切なこととしては、早く作りリリースすることです。段階を分割することによって各段階の時間を計測して最適化することができます。各段階の価値は後半になっていくにつれ増大します。新しく機能を作り始めるよりも、作りかけのものをリリースする方が価値が高いということです。後半の作業は価値が高いため自動化の価値が高いです。例えば自動デプロイや自動テストをすることで、自動的にコードの価値の増加させることができます。
サブ機能についても同じです。新しいコードを書くよりもレビューすることの方が価値が高く、レビューを簡単にするための努力は価値があるということになります。早くレビューを通すために分割や説明文を書くことは価値があります。フォーマッタやlinter、自動テストによる動作の保証はすることはレビューの妨げの排除は価値があります。
iOSと Androidをまとめて開発したいという要望があり、その夢と現実の歴史。ゲームは知りません。
iPhoneとAndroidが2007年に発表され、今後の携帯電話のスタンダードになっていくことが予見された。当時の開発言語はObjective-CとJavaであり、ほぼ同じロジックを二つの言語で書く必要があった。現在はSwiftとKotlinに取って代わられつつあるが2つの言語で書く必要があるのは変わらない。面倒くさいよね。
Rubyでかけるやつ。iOS 13.2. Android 8.1が最新なので察してあげてください。
Flashをベース。AcrionScript3+MXMLで開発ができる。Flash職人がアプリ開発に使っていたという印象があります。一時期の郵便局年賀状アプリや初期の艦これAndroid版はAirで動いていたらしい。HARMAN に移行され、HARMANに連絡しないとアップデートが受けられないという実質的な死を迎えました。Apache Flexとその派生のApache Royaleもありましたが、Apache財団に移管済に移管済みだそうです
JSでかけるやつ。最古参でまだ定期的にアップデートされている。最近は聞かない。
よく知らない。Object Pascal言語(Delphi)で書くらしい。アップデートはあるようだけど、使っている話はあまり聞いたことがない Delphi: 概要 - エンバカデロ・テクノロジーズ
珍しくOSS。WebView 動く。5年前からアップデートがない。 Ratchet
Phone GapはAdobeが次世代Flashになると見込んで開発元を買収した。 WebViewでUI作って、ネイティブの機能をブリッジして使えるようにしたもの。当初Web系の人たちの使いやすさもあって流行ったが、iPhoneとAndroidのギャップにやられる。Phone GapはApache Cordovaとして寄贈され、Phone Gapとしての終焉を迎えました。 CordovaからはMonacaに派生があります。 IonicはCordvaをベースに独自のプラットフォームを構成し、今はCordva相当を自作して置き換えた。
Swiftでクロスプラットフォームの開発を行えるようにしたもの。 チェンジログが3年前のベータ版リリースだったり、動きが全く掴めない。少なくとも流行ってはなさそう。
Xamarinはマイクロソフトが開発した。 C#で開発できる。マイクロソフトは激推ししているのでしばらくは死にそうにない。接触確認アプリで使われている。ちゃんと動く印象。C#に使い慣れている人が多ければ採用される可能性はある印象。 .NET MAUIが登場し移行が推奨されています。iOS 16とAndroid 13でサポートが終了した。 Windows Phoneなんてものもありました。
Xamarin ドキュメント - Xamarin | Microsoft Learn
React NativeはFacebookが開発した。 JSCかhermesを通してNative UIでレンダリングしてる。Reactはが得意ならあり得る。WebでいいならアプリとしてリリースせずにWebにしとけばいいじゃね?
React Native · Learn once, write anywhere
FlutterはGoogleが開発している。 Dartで開発する。どうしてもGoogleのアプリっぽくなる。ここ最近(2020年8月)は割と使われているらしいということを聞く。
Flutter - Build apps for any screen
.NET Multi-Platform App UI の略。 Microsoftが開発している。Xamarinの移行先。 C#で開発する。
UIはそれぞれの言語で書いて、ドメインモデルなどの共通のロジック部分は一つの言語で各タイプ。
JavaからもObjective-Cからも無理なく呼び出せる。実際使っているという話は聞いたことがない。どこかにはいそう。
Kotlinで書けるのでAndroidはもちろん動く。iOSの方はなんかいろいろやって、frameworkに固めてインポートできるようにしているらしい。
C言語と同じく、JavaからもObjective-Cからも呼び出せれば何でもいいので、かなりの数の言語が理論上はできるということになっている。実際のアプリでやっているのはごく少数だとは思う。
5年以上栄えているクロスプラットフォームは今のところなく、繁栄と衰退を繰り返している。完全に死んでいるのは少ない。最近流行っている物はわからないが、正直長く続けるとわかってるならネイティブで開発することをお勧めする。スタートアップで高速でリリースしなければいけないときや、どうしてもアプリエンジニアを採用できない時、Xamarin,React Native,Flutterが今までの夢の歴史を終わらせれると思った時などに採用すべきだろう。
モチベーション向上につながる 目標の存在はモチベーションを上昇させ、パフォーマンスを上げます。 1960年代にEdwin Lockeが提唱した、Goal-settig theory of motivationにおいて、目標設定は業務へのモチベーションを高く保ち、パフォーマンスを向上させるために必要不可欠とされています。Goal Setting Theory of Motivation
事実、金銭的なインセンティブがない状態にも関わらず、目標の設定を行ったグループの方が、そうでないグループに比べて、12〜15%パフォーマンスが高い事が研究によって明らかにされています。The Impact of Goal-setting on Worker Performance - Empirical Evidence from a Real-effort Production Experiment
本人が納得している目標については、曖昧な目標よりは明確な目標のほうが、また難易度の低い目標よりは難易度の高い目標のほうが、フィードバックが遅いより早い方が結果としての業績は高い、ということが確認されている。本人が納得していない目標は逆に業績の低下を招く可能性もある。 チームでも同じように、明確で高い難易度と高速なフィードバックに納得していれば、結果として高い業績を上げることができると思われる。
人事評価として、目標設定を行う場合は大抵の場合はジレンマが発生する。目標を達成しなければ給料が下がるが、低い目標を立てては意味がない。メンバーは給料を優先するため低い目標を立てようとして、高い目標への本人の納得を得ることが難しくなる。何とかするのがマネージャーの手腕かもしれないが、少なくとも今まで全ての人に納得できる目標を立てさせたマネージャーにあっていないので9割のマネージャーが本人が納得していないか、緩い目標を立てていると思われる。
可能であれば人事評価を本質的な能力の有無によって決めて目標設定と切り離し、目標設定をメンバーのモチベーションの向上にフォーカスするべきです。
長期的な未来を予測することは難しいということを前提にアジャイルをしている。アジャイルは計画をしないわけでも目標も定めないわけでもない。1年先の目標を立てたとして、52週間も先に結果がわかることになる。1週間スプリントなら52回も先で1ヶ月スプリントでも12回も先の話である。その頃には目標で立てていたことは、十分にできているか、目指すべき目標になっているはずだ。1年は明らかに長すぎる。アジャイル宣言でも、「計画に従うことよりも変化への対応」と言っている。陳腐化しているか間違っている目標を1年間も掲げるよりも変化への対応を行って柔軟に切り替えていくべきである。柔軟に切り替えていくことができない環境の場合は一年もの先を見通せないので、年間目標を立てたとしても曖昧な目標を立てることになる。曖昧な目標は、目標設定としては意味がないわけではないが効果的ではない。
最適な長さは、スプリントと同じ程度だと思われる。良い目標であれば次のスプリントでも続ければ良い。そのときそのときに集中すべき目標は何なのかを考え続けましょう。目標は明確で高い難易度と高速なフィードバックが可能で、他の注力すべきでない目標から後ろ髪を引かれないようにすべきだろう。
メモ書き
世界観として、観察者と観察対象がある。ObserableからObserverに対して複数回状態を送信する。UILabelとかUITableViewはObserberとなり、Obserableの値を観察を行って変更があった場合にそれに合わせて表示を変更を行う。ObserableはDBの値やサーバーで取ってくる値、UITextFieldやUIButtonなどがある。
obserableは基本的にHotなobservableでないと複数から観察できない。 * Subject * multicast, publish/replay/replayAll, share
少し古いが、このスライドがわかりやすかった。shareが便利
今日こそ理解するHot / Cold @社内RxSwift勉強会
内部的に使われているもの。ObserverでありObservableでもある。FilterとかMapで返ってくる
46pあたりから説明がありわかりやすかった。 RxSwift コードリーディングの勘所@社内RxSwift勉強会
まだよくわからない
入力される最後の通知からtimeinterval の時間の後にcount分だけ通知を一気に流す。 検索をするコストがそこそこある場合に、入力されるたびではなくUISearchBarからの最後の入力から0.5秒後に検索を行いたい時に用いるのが良い。 debounceはcountを1にしたもの
連続して大量に繰り返される処理を一定間隔で間引くものです。 よく使われるのはscrollイベントです。スクロールイベントをすべてハンドリングすると処理回数が多くなり、場合によってはスクロールがもっさりしてしまいますよね。それを防ぎます。
Eventに変換と元に戻す
【RxSwift】materialize, dematealizeを使ってみた
複数のObservableをまとめて、一つのObservableとして扱うもの
通知の内容が前回と変更があった場合に通知を次に流す
複数のストリームを混ぜ合わせられる
【RxSwift】concatとmergeの違いをサンプルを元に整理してみる – su- tech blog
RxSwiftのObertvableな物についている
最もシンプルなObservableType。ObservableType に実装されているところ以外はほとんど能力はない
subscribeを完了させた後にconnect()を行って、接続を完了させる。