Kuehar's Blog

どっちでもいいじゃん、そう思っていました for文とWhile文を使うシチュエーションについて深く考えたことがなかったのです。 正直できることにほとんど差がないし すると、 コーディングを支える技術――成り立ちから学ぶプログラミング作法 を読んでいるときにどちらも一緒ならばfor文の方が読みやすいよ！と書いていたので確かに！と思ったのでメモ。 そう述べているメインの理由として例を見ながら考えてみます。 C言語でwhile文が要素が以下のように散らばるのに対して、 i = 0 while ( i < N ) { printf ( "%d\n" , i ) ; i ++ ; } for文では以下のような文法のため、一塊の処理として読んだ時に1度で理解しやすくなる、というものでした。 for ( i = 0 ; i < N ; i ++ ) { printf ( "%d\n" , i ) ; } チームで開発する以上、何度も読み返すような例は良くない。 何より自分ですらどういった意図を持ってそのコードを書いたかなんて忘れてしまうのだから簡潔にかけている方がいいですよね。 確かにその通りだと思ったので今後はよっぽどの理由がない限りチーム開発では繰り返し処理をfor文で書くことにしようと思いました。というお話。

@Stateってなんぞや と言う話。 ただのメモなので基本の当たり前のことについて書いておく。 まあ更新可能な変数を宣言したい時につけとけばそう言うものとして扱ってくれるんだろうなぁ、程度のイメージだった。 ただ、知らなかったのはこの値を更新するたびに body を更新、画面を 再描画 するということ。 Swift初期のこととかよく知らなかったけど、この仕組み自体 Swift5.1 で追加されたものらしい。 そもそも論としてstructが基本的に更新不能と言うことを考えれば何かしらの回避可能な仕組みがあって当たり前だろう、ということになりそうなものだけど新しい事を学ぶ時ってインプットが多くなりすぎて詰め込む方に意識がいってしまいすごく今更なメモになった。 ちなみにひとまず動かしてみた例がこれ。 トグルボタンを用意して状態出力するもの。 ソースは ここ 。

初心者向け 開発者定義のViewModifier 初心者向け の記事。 SwiftUIではViewでUIの要素を指定し、ViewModifierで要素のレイアウトを整えていく。 その書き方はそれぞれの要素に対して // // ContentView.swift // Modifier // // Created by kuehar on 2021/07/01. // import SwiftUI struct ContentView : View { var body : some View { Text ( "Hello, world!" ) . padding ( ) } } struct ContentView_Previews : PreviewProvider { static var previews : some View { ContentView ( ) } } プロジェクトを作ったときはこういう形式でコードが生成されるが、このコードの中の .padding() が実際のViewModifer。 Previewで見てみると最初はこんな感じだが、 例えば .padding(bottom) に変えてみると、 少しだけ Hello, World! が上に動いている。非常に分かりづらいが。 こういった形で各要素を修飾することによって要素の内容を変えていく。 開発者定義のViewModifier 同時に、開発者側で定義する再利用可能なViewModifierを作成できる。 開発者でどのビューにも適用できる再利用可能なViewModifierを作成したい場合に用いるもので、いくつかのViewModifierを組み合わせて新しいViewModifierを作成することができる、というもの。 例えば Apple公式のViewModifier のドキュメントでは以下のようなViewModifierを定義し、使用しています。 // // ContentView.swift // Modifier // // Created b

Webスクレイピングとか 試していたらこれが突然出た。 macOS用公式インストーラーのPython 3.6でCERTIFICATE_VERIFY_FAILEDとなる問題 という記事に解決策が書いてあったが、 python.orgで配布されているmacOS用の公式インストーラーでインストールしたPython 3.6を使い、 urllib.request.urlopen() で https:// のWebページを取得しようとすると、以下のエラーが発生します。 で、このタイトルのエラーに当たっていたよう。 私の場合はPython3.8.5を使っていたので $ /Applications/Python\ 3.8/Install\ Certificates.command というコマンドをターミナルで叩くことで事なきをえた。 読んでないのが悪いとはいえこれはハマる人が多いんじゃなかろうか。

たまたま目にしたので Create Phone Number たまたま目にしたので CodeWars なるサイトがあるとのことで試しに登録してみた。 サイトで問題を解いてコーディングスキル上げてね！みたいなサイトです。 Create Phone Number そこで２問目(3問目だったかも)で出てきた Create Phone Number についてPythonで解いていました。 この問題はリストで10桁の数字が与えられるので、それらの値を電話番号のフォーマット、下のような形式で変換して返してほしいという問題です。 create_phone_number ( [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 0 ] ) # => returns "(123) 456-7890" 僕は愚直にfor文の中で分岐を何度も挟むことで作る、という方法を取りました。 def create_phone_number ( n ) : phone_number = '(' for i , num in enumerate ( n ) : if i < 3 : phone_number += str ( num ) if i == 2 : phone_number += ') ' elif i <= 13 : phone_number += str ( num ) if i == 5 : phone_number += '-' return phone_number でもよく見たらこれって書く量も多いし、なんかあんまりいけてないなぁと思っていたところ他の方の回答を見たところ、こんな解答を見つけました。 def create_phone_number ( n ) : return "({}{}{}) {}{}{}-{}{}{}{}" .

楽をするのは良いことだ 環境 構築 Firebase Nuxt.js 楽をするのは良いことだ ということで、個人的に好きで使っているNuxt.jsをFirebaseにデプロイし、その後Githubにプッシュするたびに自動的にデプロイされるように設定するまでをこの記事では解説しておきます。 Firebase使ってみた こちらの記事を参考にさせていただきました。 環境 OSX Catalina npm version6.14.6 node.js v12.18.4 構築 Firebase まず Firebase にログインします。 Googleアカウントが必要となるので持っていない方は取得してください。 こちらのページにアクセスしたら使ってみるをクリックし、以下の個人のプロジェクトを管理するページに移ってください。 そしてプロジェクトを追加をクリックし、任意のプロジェクト名を設定し、プロジェクトを作成してください。 これでプロジェクトを作成できました！ ひとまずターミナルを開き、以下のコマンドを使ってFirebase CLIをインストールしておきましょう。 $ npm install -g firebase-tools そしてついでにログインをしておきましょう。 $ firebase login 次はNuxtプロジェクトを作成し、Firebaseとつないでデプロイしてみましょう。 Nuxt.js mkdir firebase cd firebase vue init nuxt-community/starter-template sample こちらでfirebaseディレクトリ内にNuxtのテンプレートが作成されました。 そして次にfirebaseとつなぐ必要があるので以下のコマンドをターミナルで実行してください。 また、ここではHostingを選択してください。 $ firebase init MacBook-Pro sample % firebase init ######## #### ######## ######## ######## ### ###### ######## ## ## ##

社内システムとAPI 社内でとある雑談をしている際に、社内システムを構築する際にAPIを設計、開発するとより簡単、かつ疎結合なシステムを作る時に便利になってくるのではないか、という前提を元にAPIについて勉強しなおしました。 どうせ勉強するならアウトプットして外に出すことで間違っていた際にご指摘を受けることも出来ますし、自身の勉強の証にもなるだろうということでサクサクっと書いていきます。 参考図書 Webを支える技術 Web API: The Good Parts 学習の順番 Webを支える技術 Web API: The Good Parts の順で勉強しました。 正確には Webを支える技術 は読んだことがあったので、基本的な歴史や仕様について学び直すために読んだ、と言ったほうが正しいかもしれません。 そもそもHTTPとかを理解できていないとAPIについて何を言っているのか分からない、というのはあると思うのでWebの仕組みを理解する基礎固めのためにも読むべきだと思います。 あと単純に面白いです。 Web API: The Good Parts はWeb APIをこれから設計、開発しようという人を対象とした本なので、APIについてのざっくりとした説明はあるものの、主軸はあくまでこういうAPI設計したら気持ち悪くね？こっちの方がよくね？とか、特定のユーザーにAPI叩かれすぎたら困るよね？じゃあこうしよう！などの開発者向けの内容がメインです。 こちらも面白かったです。 オライリーの本ですが、著者が日本の方ということもあり、分かりにくい表現も少なく、スラスラ読める、という印象なので困っている方に特におすすめです。 そもそもAPIって何よ？ 一般的な定義 Application programming interface の略です。 よく言われるAPI、というのは大体の場合Web APIのことを指します。 なお、APIを使うことをITエンジニア界隈では「APIを叩く」、と言います。 これはAPIを使うことを英語で「hit api」というためで、それが和訳されて使われ続けて今に至るとか。 なお、Web APIとは、 Web API: The Good Parts にある通り、 Web APIとは「HTTPプロトコルを