27
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

無職の開発未経験者が、KotlinでAndroidアプリを独学でリリースするまでを振り返ってみた

Last updated at Posted at 2022-12-09

こんにちは。halkoです。
私は現在、Androidエンジニアとしての就職を目指して、日々個人開発をしています。

つい先日、単語帳を自作できるAndroidアプリをリリースしました。

Google Playへ
簡単なアプリですし、コードの質、デザイン、改善点を挙げたらキリがない粗末な作品ではありますが、なんとか使えます!

プログラミングというものに初めて触れたのは約1年前。
人や環境に恵まれて、ありがたいことに
スクールや教材などにはお金をかけずに、リリースまでこぎつけることができました。
開発未経験の状態から、自作アプリをリリースするまでの流れを振り返ってみたいと思います。

自分のためでもありますが、未経験からアプリリリースを目指している方の参考にもなれば幸いです。

※(注)リリースしたアプリはインストール数も少なく、収入やキャリアを築けたわけではないので、成長途中のビギナーの話としてお読みいただければと思います…!

なぜ、Androidアプリのリリースを目指すようになったのか

開発そのものに触れたきっかけ

私は、現在無職なのですが、以前は看護学校に通っており、在学中にとあるきっかげでiOSエンジニアの方と知り合いました。
アプリの開発なんてワクワクする仕事だなあ、と思い、仕事内容を聞いてみたところ、その方が開発作業をしているPCの画面を見せてくださいました。
ひたすらアルファベットが並んだ画面をみて、「映画のハッカーみたい!」と非常に安直な発想で感動し、
かっこいいなあーーー、私もやってみたい!という衝動にかられます。
(今思い返すと、あれはxcodeの画面でしたね)

Androidユーザーの私は、Androidで同じように開発している人たちは何を使っているかな、と調べてみました。
どうやらAndroid Studioというソフトをパソコンに入れればいい良さそう…、と知り、さっそくインストール。
ですが、学校の課題や実習の準備なので忙しくなり、私のpcの中のAndroid Studioは、その後しばらく放置されたままとなりました。 

持病の悪化、退学

少し話がそれますが、私は高校の頃からうつ病を患っており、治療と並行して、看護学校に通っていました。
小康状態を保ったまま、日々を送っていたつもりでしたが、一年生最後の冬ごろ、症状が悪化してしまい、進級できずに退学することとなってしまいました。

この短期間での退学はネガティブに聞こえてしまうと思うのですが、私にとっては学びの多い一年でした。
看護の業界は、精神的なタフさを求められること、勉強量と看護の質が必ずしも比例しないこと、人によって正しい見解が大きく変動すること…。
こういった課題を、自分は技量不足で乗り越えられませんでしたが、
この業界で日々生き抜いている看護関係の方々への尊敬は、本当に、本当に、大きいものとなりました。

そして、私にあった業界、

  • 勉強した時間とスキルが比較的比例する
  • 伝統や形式より、効率を大事にする
  • 新しい文化や基準の導入に積極的
  • IT系の技術を使える人が多数派

こういった場所で働きたいな、と気づくことができました。

開発を始める

退学後、主治医に「とにかく休みなさい。好きなことしなさい。」という夢のようなお墨付きをもらいます。
これは、眠っていたAndroid Studioをたたきおこすっきゃない!と、毎日自分の部屋で開発するようになりました。

続けるにつれ、何もわからない状態から、少しずつできることが増えていきました。
開発を通して小さな自信を身に着けていく度、「この社会でも生きてけるかもな」と、心が癒されていきました。
多くの人の支えや心理療法、そして何より開発のおかげで、少しづつ元気と自信を取り戻し始めた私は、プログラミングで何かを成し遂げてみたい、と思うようになりました。

そして、目標を「Androidアプリをストアでリリースする」と設定することにし、療養しながら開発を続けました。

どうやって開発を独学で勉強したのか

個人的な話にそれてしまいましたが、ここからは、もうちょっと役に立つ経験談です。
前述の通り、私は一切お金をかけずに、主にインターネットにある情報で開発を勉強しました。
開発の勉強に投資をするような金銭的余裕がなかったのと、好きな時間に好きなように勉強したい!と考えたのが、主な理由です。

洗練された技術では到底ありませんが、「簡単なアプリなら自分で作ってリリースできる状態」までは、行き着くことができました。
では、具体的にどのような流れでそうなれたのか、記そうと思います。

初心者はとにかくFreeCodeCampをやっとけば大丈夫

私は、FreeCodeCampというYouTubeチャンネルの講座で、開発の基礎を学びました。
というか、この動画一本だけです。
Android Development for Beginners - Full Course
11時間の動画で、Android Studio,javaのインストール手順を含めた基礎のすべてが詰まっています。

私は、一日3時間から4時間、

  • 動画を10分ほど再生して、自分のパソコンで動画の内容を再現する

を繰り返しました。
一日に進む動画の分数は、20分あったら多いほうでした。
今思えばとても簡単なことをやっているのですが、知識を0から1に進めるのは本当に難しいもので、4時間やったらもうへとへとでした(笑)

この動画は、メイサム様(twitter)という、個人でも開発学習動画のチャンネルを持っておられる大変素晴らしい方が、とても分かりやすい英語で解説してくださっています。
高校3年生レベルの英語が分かる方であれば、難なくついていくことができます。
パソコンの画面をすべてミラーリングしているので、英語が多少わからなくても、やっていることはすべてわかるようになっています。

彼の素晴らしいところは、私のような猿レベルの知識しか持っていない者にもわかるよう、難しい表現は一切使わず、言葉選びにも内容にも非常に配慮されているところです。
メイサム様にすべてを教わったので、彼には本当に頭が上がりません。

と、ここまでこの動画を持ち上げていながら、私、8時間ほどまで進んだところで離脱しております。
8時間進んだ時点で、できることがだいぶ増えたきもちになり、
「自分で試行錯誤して何かを作りたい!」
という欲求に駆られてしまったんです。

Kotlinで電卓を作ってみる

先述の知人に、最初に作るものは電卓がおすすめだよ、と言われていたので、自分で電卓を作ってみることにしました。
freeCodeCampの動画で学んだのは、javaを使った開発方法でしたが、Androidの開発に向いていていてよりモダンなKotlinという言語があることを知り、Kotlinで書くことにしました。
電卓を作るレベルの開発でしたら、javaもKotlinもそんなに大差はないので、

  • ネットで検索して調べる
  • Kotlinでの電卓のつくり方をyoutubeで探して真似する
  • Android Studioで出てくるシンタックスエラー(コードが間違っていると、赤い波線で指摘してくれる)をなくす

の三本柱で開発しました。

kina.gif

出来上がったのはこんな感じのものです。ご覧ください。詰めが甘々(笑)
82÷5=26だそうです。これを使って会計計算なんかしたらと考えると恐ろしいですね!

この電卓を作ってみたことで得た非常に大きな気づきは、大体どの家にもあるあの電卓が、いかに優秀かということです。
電卓を作ろう、と決めてから、私は人生で初めて、

  • そもそも電卓って結果の出方やボタンを押したときの操作ってどうなっているんだっけ?

と、電卓の構造・機能について深く考えました。
いざ作ってみるとなると、電卓ってよく考えられた機械なんだなあ…。
説明書無しで、誰でも使うことができる電卓が、いかに偉大かに気づくことができました。

もうとにかくKinaを作りたくてしょうがなくなってしまった

今思い返すと、電卓ちゃんと完成してないじゃん!!という感じなのですが、
電卓がある程度形になったことで、とにかく自分の想像するアプリを自分で作ってみたくなりました。
私が作りたかったのは、暗記を手伝ってくれるツールです。

これは、看護学生時代からずーーっとほしかったアプリなんです。
学生時代、とにかく暗記しなければいけないことが多かったのですが、学校の資料は全部紙。
いつでもどこでもちょびちょび暗記したいのに、勉強するとなると、紙の資料を引っ張り出して、マーカーを引いて赤シートで隠して…と、非常に面倒でした。
一度勉強内容をアプリの中でまとめたら、常に見返せて暗記の練習もできる、そんなアプリがあればいいのに…
今となっては看護学生ではないので必要なくなってしまったのですが、それでも、悲願のアプリを作りたい!というパッションで、Kinaの作成を始めました。

Kinaの制作過程でデザインを学ぶ

私は、コードをカタカタ書くのと同じくらい、アプリの構成・デザインを考えるのも大好きです。
デザインは原案は、Figmaという無料ツールで作りました。
聞いた所によると、プロの方々や会社での開発というのは、デザインが決まってから、それを再現するようにアプリを開発するものらしいです。
ですが、デザイン能力も開発能力も半人前だった上、そのような制作工程のスタンダードも知らなかったものですから、
xmlのレイアウトファイルを作りながら、デザインを考える・大幅に変更する、というようなだいぶ適当なこともたくさんやりました。

開発当初のデザインと現在の比較

Before After

アプリのアイコンの比較

左が旧デザインのキャラクターなのですが、ミ〇オンに似ている、と訴えられたらどうしよう!と気づいたり、あんまかわいくねえなこいつ…と思ったりして変更を重ねた結果、右の子になりました。

グラフィックデザインの奥深さに気づく

私は、

  • 著作権関係で訴えられたら怖い
  • とにかく何でも自分で作りたい

という発想から、アプリで使うアイコン等はすべて自分で作りました。
反省点のうちの一つでもありますが、著作権に関しては、ちゃんと調べてルールを守れば大丈夫なので、自分で全部作る必要なんてなかったです。
効率やスピードのためにも、一部は既存のものを上手に使うべきでした。

作ったロゴの一部です

初期に作ったものなので、なんだかそっけないデザインですね
まだリリースはしていませんが、今後はアイコンを一新しようと思っています

すこしましになったかな!

画面上での統一感や、万人が同じものとして意味を認識できるかなど、課題は多く残っています…。
やはり、その分野にはその分野のプロがいますので、分業というのも大事ですね。

ただ、アイコンデザインは、保存形式の勉強にもなりました。

  • ファイルの名前の最後につく、svgやpngって何?
  • 一番容量の軽いデータの保存方法ってどれ?

また、開発上使いやすいアイコンとは何か、なども初めて意識するようになりました。

  • ある部分の色だけプログラミング上で変更したいときは、どんな風にデザインを構成しておけばいいんだろう?
  • 比率の変更に強いデザインって何だろう?

すべての学びを通して、グラフィックデザインの楽しさに初めて気が付きました。
一番楽しかったのは、Kinaのロゴのデザインですかね。

ペンで書いてラフにデザインしたものを、比率や角度をしっかりと計算して、正しく美しく構成しなおす作業は、この上なく爽快感があります~
すべて、四角形と丸で作れるというのも、本当に面白いですよね!

詰まったところがあったら、それは他の誰かも絶対に体験している

変なバグが起きたり、思い描いた動きをしてくれなかったり、開発中困ることがたくさんありました。
でもそのほとんどは、根気よくネットで調べると解決しました。
開発で困るたいていのことは、他の誰かも体験済みなのだと学びました。
それだけでなく、他人同士が失敗や疑問をネット上で共有・解決するという、素敵なプログラミングの文化が存在することも知りました。

困ったら調べて、どなたかの解決策を真似させていただき、また詰まったら調べる…これの繰り返しで、Kinaを作ることができました。

リリースまでこぎつけることができた要因(干渉不可なもの)

リリースまでを振り返ると、楽しくて続けられたという印象がとても強いです。
初心者の私には、下手の横好きという言葉がぴったりな気がします。
今後楽しく開発を続けるためにも、

  • なぜ、こんなにも開発が楽しかった(楽しい)のか

を分析してみたいと思います。
まず、自分ではどうすることもできない、環境、運、特性といった要因から書いてみます。

①開発すること自体が目的だった(お金儲けや就職ではなかった)

前述の通り、開発を始めたきっかけは「お医者さんから好きなことをやれと言われたから」です。
また、お恥ずかしいことに、プロダクトをより多くのユーザーに使ってもらいたい、マネタイズしたい、といった想像ができるほどの具体的なビジョンがありませんでした。
でも、こういった野心のなさが功を奏したのかもしれません。
私は、パソコンに向かって開発をしているだけで、以下のような目的が果たせていると感じていました。

  • 開発においてできることを増やす
  • プログラミングを継続する
  • プログラミングをして楽しい時間を過ごして、ただぼーっと引きこもるだけではない1日にする

これらは、比較的達成しやすい目的なので、私は常に満足感を感じた状態で開発できていました。

たとえ、作った電卓の割り算が間違った値を出したとか、一日使って直したバグが実はそもそもいらない機能のバグだったとか、そいういうことがあっても、すでに開発してるだけで十分満たされているので、とくにへこたれる理由にはなりませんでした。
今でももちろんできないことばかりの私ですが、できることが少ない内は、成果ではなく作業自体を目的にするのも、一つの手かもしれません。

②周囲のサポートがあった

大変恥ずかしい話ですが、今現在も、両親をはじめとする周囲の方の全面的援助のもと生活しています。
上記のような、のんびりとした姿勢で開発に臨めたのは、

  • 家事さえすれば、毎日100%の時間を開発だけにそそぐことができた
  • 金銭的に困窮する心配があまりなかった

というのが大きな理由だと思います。
これに関しては、「引きこもらないでいてくれるだけいいや」、という非常に寛容な考えで、援助してくれている家族のおかげです。
長い目で自活できるようになってくれれば、今自立を焦らせる必要はないだろう、と見守ってくれ、一日中パソコンをいじっている私を信頼してもらえるのは、自分の努力でもなくただただ運なので、自分は本当にラッキーだと日々実感しています。
これらの環境なしで、独学を継続できていたとは、1ミリも思いません…。

③作りたいものがあった

具体的に作りたいもののアイディアがわいていたので、次に何をやればいいかわからない…、という感覚には特になりませんでした。
いつだって、やりたいことでいっぱいでした!
できることが少し増えると、あれもできるかも、と妄想して、新しいことをやってみていました。
ただ、(あとで詳しく書きますが)本当に必要なのか考えず、どこまでも手を伸ばしてしまったのは反省点でもあります(笑)

リリースまでこぎつけることができた要因(自分で工夫したもの)

①理解できる前に作ってみちゃった

開発はよくわからないことだらけで、難しいことばかりでした。
初めのうちは、何が高度で何が基本的な知識なのかもわからなかったですし、少し調べては、哲学のように抽象的な(に、思える)解説と睨めっこしていました。
疑問を理解しようとするだけで、一日が終わってしまうような状態が楽しくなかった私は、
実際に手を動かすほうが、開発を学ぶスタイルとして性に合っていたようです。
なんかむずくてよくわかんないけど、とにかくつくってみよ!の精神で開発を進めました。

一つ例を挙げると、私は最近まで、”+=”の意味がよく分かっていませんでした。
ご存知の通り、aの値を、a自身の値に特定の値を加算した値に変えたいとき、この”+=”を使うのですが、私は何度解説を聞いても、いったい何のことだか全くわからず、
「+1は+1って書けばいいじゃん、なんで+=なの?わけわからん!」
とずっと思っていました。

この”+=”が理解できたのは、動画を見て勉強している時ではなく、実際に自分がアプリを作る際、「自身の値に+1をした値をゲットしたい」という状況になってからでした。
想像もつかないことを理解しようとするのは至難の業です。

実際手を動かしてみて、ある知識が必要になったタイミングで、その知識を理解しようすれば、実例と一緒に学ぶことができ、理解も圧倒的に早いと思います。
習うより慣れろ、の精神は、0から開発を学ぶ上で役に立ちました。

一方で、わずかですが知識がついた今は、情報のインプットの比率を増やさなければとも感じています。

②時間で達成感を感じれるようにした

開発を始めたばかりの頃は、とにかく何にも進みませんでした。
本当にカタツムリスピードでしか進捗がないので、「これを毎日続けてなんになるんだろう…」と心が折れそうになることも。
日々の開発作業の評価基準を、機能の追加といった目に見える成果においていると、とてもモチベーションが保てませんでした。
そこで、私は、Notionというサービスを使って、一日何時間開発したのか、記録に残すようにしました。

バイトのタイムカードを自分で打つというようなイメージです。
一週間や一か月単位で、どのくらい開発に時間をかけたのか、見返すようにしています。

そうすることで、たとえ能力はなにも上がっていない気がしても、

  • まあこの位の時間をかけたのだから頑張ってるよな!という満足感

を得ることができました。

成果ではなく時間にフォーカスするメリットは、もう一つあります。
私は、できることが増え、能力が上がると、一日に作業できる時間も増えていきました。
何もわかっていない初心者の頃は、3時間もたてばへとへとですが、能力が上がると、きづいたらこんなに時間たってる!!時間が足りない~というぐ具合に変化してきたのです。

つまり、実際開発項目が進んでいるかどうかは関係なく、一日の作業時間が増えていくことは、自分の開発能力が上がっていることの表れであり、
それを自ら確認できることは、一人でプログラミングを学ぶ上でとても大事な指標となったわけです。

③タッチイベントの処理など、目に見えやすい開発ジャンルから学んでいった

Viewを動的に動かすアニメーションや、タッチの種類を判別してViewを変化させるなど、やっていて達成感を感じやすい、私の好きなジャンルから開発していきました。

DBの処理などに手を出したのは、少し開発に慣れてきてからでした。

とにかく開発が楽しくあるように、テンションの上がるものから触れていくよう意識しました。
最初のうちは、何をやっても勉強になる気がしたので、とにかく、続けられるように、自分が楽しいように開発することを最優先にしていれば、リリースできるかも!したいな!!という気持ちも維持できると思いました。

もしすべて一からやり直せるならば、改善する点

リリースができた理由を長々と書いてきましたが、
こうしていれば、もっとスムーズにリリース出来ただろうな…と思う点も、たくさんあります。
以下、一部ですがあげてみます。

①Kinaの原案はもっとシンプルにすべきだった

私は、やりたいことがない…という悩みとは無縁だったのですが、むしろ逆に、こういう機能が欲しい、こんな風に作りたい、というアイディアが多すぎました。

既に開発者として成熟している方であれば、これが何か問題になることはないと思うのですが、初心者がアイディアを持ちすぎてしまうときは、注意が必要でした。

私は、やりたいことがどれだけあっても、それをどういった開発プロセスで実現するのか、まったくイメージがついていませんでした。
アイディアが豊富なのは、アイディアが全くない状態と、

  • 開発するうえでの解像度が低い

という点において、共通している気がするのです。

複雑なアイディアを低い解像度を持ったまま開発すると、自分が一体どんな進捗状態にあるのか、何を達成したのか、よくわかっていないことになります。

実際私は、「そもそも何をやっているのかもうよくわからない!」という状況に追い込まれたことが、何度もありました。
そして、そこまで煮詰まってはじめて、「何をやるべきなのか整理しよう」という行動に出ていました。

しかし、最初からやりたいことをシンプルにしておけば、

  • 自分は今何を目的に開発しているのか

を失うことはなかったはずです。

具体的には、作りこみたい機能をリストアップし、優先順位をつけ、リリースできる最低限の完成度を目指して開発すればよかった…と、後悔しています。

②ある開発項目を達成するために、身に着けるべき知識を、整理して開発に臨むべきだった

Aができるようになるには、Bの知識が必要。
Bを理解するには、Cを勉強しなければならない。

理解が足りない状態で開発をしていると、触れなければいけない開発知識が、芋づる方式に増えていくことが多かったです。
わからない単語を調べたら、解説にある単語の一つが分からず、延々と辞書を引き続ける…といったところでしょうか。

このサイクルからは、自ら意識して抜け出す努力が必要だったのですが、それがなかなかできませんでした。
わからないことを一つ一つ理解して改善していく、という方法では、開発はいつまでたっても進まない!(それどころか、どんどんコードがとっ散らかっていきます(笑))

  • まず、完成させたい状態をしっかりと決める。
  • 今の自分の知識で、完成状態に一番近いものを作り上げる。
  • それ以上進むことができなくなったら、今の自分の知識では完成できなかった項目のみ、調べて完成を試みる。
    • ※この時、調べて理解が進むため、自分の知識で書いたコードの改善点に気づきますが、そこを改善することなく、開発項目の完成を最優先とする!!

というのが、今の私が思いつく、より良い開発手順です…。

より深い知識に基づいた開発手順に変更することは、開発の途中で行うべきではありませんでした。
なぜなら、開発の途中でロジックの構造を変更しようとすると、とんでもない量のコードを書き直さなくてはならなくなるのです。

しかも、それをやっている間に、「あれ、今のよりいい方法があるのか…」と気づき、さらなる変更を重ね、最終的には、最初に自分で書いたロジックはどこへやら…なんてことも。

このループにはまって困るのは、とにかく開発が進まなくなってしまうことです!
もちろん、より良いコードをかけたほうがいいですが、開発項目の完成を優先させなければ、とにかく次へ進めなくなってしまいました。

自分のできる形でやってみて、足りないところを最小限だけ、調べて補う。
このスタンスをもっと大事にしていたら、より、楽に、リリースに近づけたのになあ!と反省です。

③ライブラリに頼る癖をつければよかった

少し開発ができるようになってくると、
「自分が作りたいものは、自分で全部作りたい!」という気持ちになってきてしまいました。

確かに、どうにか頑張れば、多少の頃は自分で作れるかもしれません。
でも同時に、多くの人が同じような機能を求めている、ということを忘れてはなりませんでした。

詳しく調べたら、誰かがライブラリで共有しているような機能(特にカスタムView Class)を、自作するのに、多くの時間を割いてしまいました。

もちろん、自分で作ったことで勉強にはなったのですが、バグがない状態で機能するようにと、たくさんの労力と時間を使いました。
そして、最終的にはバグは解消しきれず、大量のコードを廃棄しました…。
それをすべてカットしていれば、

「アプリを使えるものとして完成させ、他人につかってもらえる状態にする」
というリリースにおける最大の目的から、大きくぶれずに済んだはずなのです。

リリースにおける最大の障害は、リリースのイメージがつかなくなってしまうこと。
私は、ライブラリを使わずに、せっせことカスタムViewClassを自作していた間、
私は本当にリリースにたどり着くことができるんだろうか…」という感覚に、何度も陥ってしまいました。

それを避けるための努力を、もっと意識して行えばよかったな、と反省しています。

最後に

長くなってしまいましたが、私のリリースまでの軌跡をここまで読んでくださってありがとうございます。
読んだ方へメッセージを記したいと思います。

Androidアプリをゼロから独学でリリースしたいと考えている方へ

時間をかければ、どなたでもできると思います!
開発には、

  • 知的欲求を満たす
  • 創造性を発揮できる、
  • スポーツや対人関係とは違って、かけた労力に確実に比例して、できることが増える

といった素敵な要素がいっぱいあると感じました。

その魅力に興味がわいたら、ぜひチャレンジしてみてはいかがでしょうか。

全体像が見えてくるまで、暗闇を探るような期間が続くこともありましたが、そこを乗り越えると本当に楽しいです。ぜひ焦らず、気長にやってみていただければと思います。

私がこれからチャレンジしていきたいこと

リリースという一つの節目を乗り越えた、私の個人的な抱負を記録させていただこうと思います。
Kinaはまだまだ、私の夢見た暗記ツールにたどり着いてはいません。

アプリをより多くの人に使ってもらえるよう、順次アップデートを重ね、機能改善し、学び続けたいです。

  • APIを立てて、端末間のデータ同期を実現する
    • バックエンド開発にも興味があるので、APIを作る経験をしてみたいというのもあります
  • よりみやすい、綺麗なコードに
    • ライブラリをはじめとするOSSを読んで、作りや書き方を勉強し、KiNaに反映させていきたいと思います
  • iOS版をリリースする
    • Androidユーザーの知人は少なく、せっかくのリアルなフィードバックのチャンスを逃してしまっているので

以上がKiNaを通しての個人開発に関してですが、

自分のキャリアとしては「Android developerとして就職する」ことを目指していきたいです。

貯金は減っていく一方で、親の視線もいつまで暖かいかわかったもんじゃないですしね…

なんて理由だけではないです!!(笑)

最近は、正解が見つかりにくい疑問に直面することが多くなってきました。
熟練の開発者の方々に教わりながら、実際に利用者の存在するサービスの開発に参加したいという気持ちが、日に日に増しています。
日々リサーチしつつ、このブログも誰かの目に留まるきっかけになったら、という思いでおります。

募集

最後まで読んでいただきありがとうございました。

もし

  • ここから次のムーブについて、アドバイスしてくださる方
  • インターン先などを紹介してくださる方
  • 健康マージャン好きな方
  • Androidエンジニアの方

などいらっしゃいましたら、ぜひTwitterでご連絡いただければ嬉しいです。
twitter

※修正
無事就活が成功し、現在は某アプリ受注委託会社で勤務しております。

27
16
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
27
16

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?