「引数」を含む日記 RSS

はてなキーワード: 引数とは

2021-10-18

anond:20211018170911

デフォルト引数自由な値が設定できないプログラミング言語は多いんじゃない?

PHPあんまりしらんけど、引数がnullだったらデフォルトの値突っ込むif文書くだけで対処できるから実用上はそこまで困らないでしょう。

PHP callable型の仮引数デフォルト値はnullしか指定できない

function hoge(callable $f = fn ($a) => $a) {} // エラー

function hoge(callable $f = 'intval') {} // エラー

function hoge(callable $f = null) {} // 合法

即時関数くらい書かせろよなぁ。せめて文字列でcallableな関数指定できるようにしてほしいわ

省略するには、$fがnullか確認してコールバック実行時にif文だか三項演算子だかで切り分けるしかない

なんで callable型 に null 入れられんだよ。キメェなぁ。なんでデフォルト値として関数代入できねーんだよ。使えねぇなぁ

いかにも増築増築で別々の機能を後付けて盛り付けてるって感じで、機能間の生合成がいまいちなんだよなぁPHP

まあ呼び出し元では hoge(fn ($a) => $a) みたいな呼び出しできるので、マシっちゃマシだけど

参考:

https://stackoverflow.com/questions/55587939/default-callable-in-function-definition-in-php-7

2021-08-16

【未経験から1ヶ月で】現役エンジニアが教える最良のプログラミング勉強法

プログラマーに憧れる皆さん!こんばんは。

自分文系から」「未経験から」と諦めていませんか?大丈夫です!プログラミングセンス不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます

今日は、未経験から最短でWeb企業就職するための勉強法をご紹介します!

オススメ方法

もっとオススメ方法は、顕正会セミナーに参加することです。

顕正会は、日本で最大のエンジニアコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアノウハウを学ぶことができます

また、意外と知られていませんが、日本エンジニアの8割は顕正会出身です。実はあのひろゆきビル・ゲイツ顕正会出身です。ですので、顕正会ネットワークを介して就職先を斡旋してくれたりしますし、自分顕正会員だと、面接時にも非常に有利になります

顕正会セミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい!無料体験もできますよ。

準備

プログラミング勉強を始める前に、まず、必要ものを準備しましょう。必ず必要ものと、できればあると良いものは以下の通りです。

必ず必要もの

まず、プログラムを書いて実行するためにパソコン必須です。

可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッドRAMは128GBくらいはあると良いでしょう。ストレージSSDであれば1TBもあれば十分です。

OSは、Windowsで開発するならWindowsが、Macで開発するならMac必要です。よく分からなければMacを買っておく方が良いでしょう。基本的MacにできてWindowsにできないことはありません。

インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。

顕正会に入会すれば、上記スペックPC無料で貸し出ししてくれます。また、法人向けの専用線無料で取付工事を行ってくれる上に、通信費を全て負担してくれます

できればあると良いもの

まず、他の会員と連絡を取るために、SNSアカウントを持っていると良いでしょう。

最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的ものを覚えることができます

Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITプロを目指そうという人間が、このような最先端デバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります現金も持つのはやめましょう。

自宅での学習

せっかくセミナーに参加しても、受身聴くだけでは、プログラミング習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。

教科書写経する

まずは、教科書参考書写経することから始めましょう。教科書参考書の本文を一字一句正確に書き写すのです。

よく、「写経理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈自然と身に付きます

また、写経メリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばししまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。

ソースコードフローチャートUML)に変換する

教科書サンプルコードノートに書き写したら、それを今度は自力フローチャートUML)に変換してみましょう。そうすることで、自分が本当にそのコード理解しているのか、確かめることができます

フローチャートUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要スキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業顧客にとっては貴重な資料となるからです。プロエンジニアは、COBOLソースコード10万行を1週間でフローチャートにして、Excel転載することができます

ここで一つ注意すべきことがありますフローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたもの業務ではフローチャートとは認められません。これはまともな企業就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。

Excel勉強する

エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業Excelで行いますセル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。

プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。

尤も、以上の資料は、ツールを使うことで自動作成することもできます。たとえば、ソースコード更新履歴Gitなどのバージョン管理システムを使うことでも管理できますしかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう!VBA習得必須です。

プログラミングのコツ

以上、プログラミング勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。

また、変数宣言使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分ミスしにくくなります

変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。


なるべく関数を作らない

多くのプログラミング言語には、クラス関数といった機能がありますが、これらは基本的ライブラリ提供者などが使う想定の機能であり、一般プログラマが使うのは好ましくありません。したがって、クラス関数はなるべく使わないようにして下さい。

関数を作ると、以下のデメリットがあります

不要関数を作らないためのテクニックには、以下のようなものがあります

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数複数の処理をすることができます

function f(i) {
  switch(i) {
    case 1:
      // i = 1のときの処理
      break;
    case 2:
      // i = 2のときの処理
      break;
    case 3:
      // i = 3のときの処理
      break;
    // ...
  }
}

この方法は、以下に述べる「変数寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます

クラス不要関数を作らないようにするには、「継承」を用います複数クラスで用いる関数定義したクラスを1つ作っておき、そのクラス継承すれば、新しいクラス関数定義する必要はありません。

理想的には、プログラム内のすべての関数を同一のクラス定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、プログラマからはこの上なく尊ばれています

class God {
  f1() {
    // 関数1
  }
  
  f2() {
    // 関数2
  }
  // ...
}

class C1 extends God {
  // 何も書かなくても上の関数が使える!
}

class C2 extends God {
  // 何も書かなくても上の関数が使える!
}
// ...

変数寿命を長くする

変数宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数寿命が長い」と言います

たとえば、以下のコードのaは、関数定義の外側からは参照することができません。

function f() {
  var a = 1;
  return a;
}

一方、以下のコードのaは関数の内外どちらからでも参照することができます

var a = 1;

function f() {
  a = 2;
  return a;
}

変数寿命を長くするのは、プログラマの腕の見せ所です。

せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまます

また、変数寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数寿命を長くするとプログラムを変更しやすくなります。つまり保守性が上がります

例外を潰す

例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイル存在しない場合は、例外となります

例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマ例外をきちんと処理しなければなりません。

ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。

try {
  // 例外が発生し得る処理
  // ex. ファイルを開く
}
catch (e) {
  // 例外が発生したときに、実行する処理
}

例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラム動作を続けます

try {
  // 例外が発生し得る処理
}
catch () {}

全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから例外が発生し得るコードは、積極的上記try-catch構文を用いて、例外を潰すようにしましょう。

おわりに

全体的に専門用語盛りだくさんの記事になってしまいましたが、

部分的にでも理解すればプログラミングを見る目が変わるはずです。

うさんくさい記事インターネットには多いですが、

そういう情報に惑わされずに本物の技術を身につけてもらえればと思います

2021-08-13

Automatons Hacking Guideというブログを覚えているか

ホームレス死ね発言メンタリストDAIGOって奴が絶賛炎上中だが、意識高い系不労所得民なんて生き方してる奴のテンプレみたいなもんだ。

10年前にその一歩先のホームレス殺人を唱導して名を馳せたAutomatons Hacking Guideというはてな日記があった。

ブロガーは「華殉」というビジュアル系っぽい名前を付けた自称東大卒国内一流会社勤務で大学院に通う20代後半という設定の男性平成初期のトレンディドラマの設定みたいな生活をする人がこの世には居るんだね。

「Automatons Hacking」のAutomatonはオートマタとも言い自動人形のこと。原爆コンピュータの父、ノイマン提唱したセル・オートマトンという概念があり、これはそのままライフゲームアルゴリズムなのだが、フランス現代思想流行するとこれら情報科学概念を借用してこねくり回す議論流行した。

その過程個人特定アルゴリズムを持って社会的活動をする自動人形と扱う社会学手法などが出来た。この辺まではAI自動学習ベースでもある。

するとこれが人文系逆輸入されて罵倒や見下しに使われるようになる。自分で考え経験してアップデートし続ける人生を送る人間じゃなくて、与えられたアルゴリズム社会的入力引数付き関数)を与えると安定した反応を出す人形として扱う。それは群衆アナロジーでもある。群衆に属さず上から俯瞰する観察者が自分だ。だから「俺は他の大衆とは違う」と思いたい意識高い系若者はこのソーカルコケにされたポモの概念無断借用的な考えに靡きやすい。

ビジュアル系みたいな名前トレンディドラマみたいな生活を送る華殉は人文家ポモの薫陶を受けている事が判るね。

ハッキングコンピュータハッキングの事だからこのオートマタ普段の処理とは違う入力を直接与えて愉快犯的に恐慌状態にしたり自分の思うままに操縦する事を表す。

おや?メンタリストっていうのに似ているね。やってる事も知的スノッブの基礎もフォロワーを釣ったり釣られたりする部分も。

 

オートマタハッカーを名乗る華殉だったがかなり誠実な性格だった。自意識に。

実存の強さ、自意識の高さ故に「群衆俯瞰者」に惹かれるのであるから自意識に誠実なのはありがちだ。

 

例えば

批判されてメタから見ている姿勢は崩さないが相当数のレスをする。

・「安全地帯から言うだけで実際には殺せないだろう」と挑発され熱くなり「自分は実際ホームレスを殺す」と言ってしまう。

ブログ副題に「〇〇劇場」と書いていたのだが、ホームレス殺人エントリなどで風呂無駄氏にはっきりと拒絶を受け、直後に外してしまう。

Twitterで「痛い」ツイートをした直後に「ちんこまんこちんこまんこ」というツイートを十数回して流す。

 

そういえばメンタリスト君も動画炎上コメントを数百個削除しているようだ。コメントが数百になると閲覧も大変なのに熱心だよね。

 

華殉はそもそも最初googleの開発がどうとかアップル製品哲学がどうとか、ニーチェ超人がどうとか、今では意識高い系テンプレみたいな事ばかり書いていた。でもPVが伸びなかった。そこに「ホームレス人権なんて行使される事も無い状態だろ」佐川ニキ「ホームレス人権無いとかいい年してバカじゃねーの」という誤解みたいな論争があり、そこにホームレス殺人エントリ割り込みPVを浚ったのであった。

 

こんな華殉だったが最後はギーグ精神論的なものシフトしてフェードアウトしていった。ホームレス殺人偽善批判などの挑発エントリから手を引いた理由増田が見たところ以下による

 

挑発エントリへの反応に対して実存開陳し過ぎた。

 

善への挑発をしたらはてなリベラルが直情的にひどいと吹き上がる反応をする事を期待していたがネットには宮勤め以外の人間も居り特に不良の経験を持つ人間喧嘩慣れしている。更にポモ以前の思想素養がある人間は同系の人間実存をむき出しにして効果的に怒らせ誘導する術を持つ。これらによって「劇場」が状況劇場になってしまい、実存開陳しすぎ、刺さり過ぎた。思想系の人間実存の剥き方を知っているのは自分がその動機実存カバー)で思想なんてものに惹かれているから。

 

自分への賛同者に底辺テンプレネトウヨみたいなのが多かった。

 

ニーチェ援用したりしてるのにルサンチマンで歪んで挑発されると安定した出力する連中に擦り寄られたら立場が無い。というかなまじっか思想なんてやってるので羞恥心で「あ゛あ゛あ゛ー」となる。同意されて懸命に距離を取りたがる姿は侘び寂びが漂っていた。でもこれは華殉も悪くて過去エントリTwitterではテンプレ的なデマや「自分税金外国人生活保護に吸われて」みたいなテンプレを良く書いていた。そもそもそれってニーチェルサンチマンのものじゃね?

 

子供主体にとって世界暴力であり規範強制してくる装置だ。特に若者」になり大学や院に進むと知で征服した自分世界と隷従を求められる外の世界格差は大きくなる。オートマトンハッキングメンタリストの行動が似ているのは共にこの需要相手にするものからだ。

 

今回のメンタリスト炎上を見てデジタルタトゥーを持つ華殉はどうしているのだろうか?

「あ゛あ゛あ゛ー」となっているかしら?とニヤニヤしてしまう。

2021-08-12

anond:20210812104821

俺環では起きてないな

Chrome バージョン: 92.0.4515.131(Official Build) (64 ビット

IME GoogleJapaneseInput-2.25.3700.0+24.7.9

Windows 10 Pro 21H1

Chromeに常に与えてる引数 --disable-features=RendererCodeIntegrity

MacType適用

2021-07-12

anond:20210712172732

グローバルな配列必要な全てのデータを保存しておくというのは、引数や返り値の考え方を知る必要がなく、配列として確保した分以上のメモリリークもなく、初心者にとっては考えやすかろう

配列

0番目: ヒットポイント

1番目: 攻撃

2番目: ...

のような設計も、他人が作ったプログラムを読み解くのは悪夢だが、自分ひとりしか触らないならなんとかなるだろう

2021-07-02

初心者から中級者になるためのプログラミングのコツ

変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。

また、変数宣言使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分ミスしにくくなります

変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。


なるべく関数を作らない

多くのプログラミング言語には、クラス関数といった機能がありますが、これらは基本的ライブラリ提供者などが使う想定の機能であり、一般プログラマが使うのは好ましくありません。したがって、クラス関数はなるべく使わないようにして下さい。

関数を作ると、以下のデメリットがあります

不要関数を作らないためのテクニックには、以下のようなものがあります

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数複数の処理をすることができます

function f(i) {
  switch(i) {
    case 1:
      // i = 1のときの処理
      break;
    case 2:
      // i = 2のときの処理
      break;
    case 3:
      // i = 3のときの処理
      break;
    // ...
  }
}

この方法は、以下に述べる「変数寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます

クラス不要関数を作らないようにするには、「継承」を用います複数クラスで用いる関数定義したクラスを1つ作っておき、そのクラス継承すれば、新しいクラス関数定義する必要はありません。

理想的には、プログラム内のすべての関数を同一のクラス定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています

class God {
  f1() {
    // 関数1
  }
  
  f2() {
    // 関数2
  }
  // ...
}

class C1 extends God {
  // 何も書かなくても上の関数が使える!
}

class C2 extends God {
  // 何も書かなくても上の関数が使える!
}
// ...

変数寿命を長くする

変数宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数寿命が長い」と言います

たとえば、以下のコードのaは、関数定義の外側からは参照することができません。

function f() {
  var a = 1;
  return a;
}

一方、以下のコードのaは関数の内外どちらからでも参照することができます

var a = 1;

function f() {
  a = 2;
  return a;
}

変数寿命を長くするのは、プログラマの腕の見せ所です。

せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまます

また、変数寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数寿命を長くするとプログラムを変更しやすくなります。つまり保守性が上がります

例外を潰す

例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイル存在しない場合は、例外となります

例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマ例外をきちんと処理しなければなりません。

ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。

try {
  // 例外が発生し得る処理
  // ex. ファイルを開く
}
catch (e) {
  // 例外が発生したときに、実行する処理
}

例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラム動作を続けます

try {
  // 例外が発生し得る処理
}
catch () {}

全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから例外が発生し得るコードは、積極的上記try-catch構文を用いて、例外を潰すようにしましょう。

2021-06-18

anond:20210618140722

こういうのは中身知らなくてもいいように、引数無しが最も高速なように作ってある

とはいえ、知らなかったからググったけど、Pythonリストは内部的にはCの配列からpop(要素を取り出しつつ削除)する場合は末尾からがいいんだね

(末尾以外からpopすると空いた場所に詰める処理が入る)

for文でインデックスアクセスなら高速じゃん、って言ってる増田も正解だね

2021-05-25

昔の職場は、Cで引数を見るときargv[]にNULLが入ってるかどうかで引数の数を判定してたりした。

int main(int argc, char*argv[])

{

for (・・・) {

 if (argv[i] == NULL) // 引数の終わりの判定

}

}

それがバグることがあったので、普通にargcを見るようにして「デバッグしました、原因はコレコレです」と報告したら「よくそんなの分かったな」と感心されたことがあった。

個人的には、それまで本やコードで、引数の数をargc以外で判定してるコードを見たことなかったから、その職場コードを見て新鮮な驚きがあったんだけど。

「独学でかじってるやつは変な癖がついてダメだ。使えない。なにも知らない新人のほうが素直で延びる」とか言ってる人をたまに見るけど、ネットや本で勉強しないで、職場で教えてもらうだけのほうがむしろ変な癖がつきやすいと思うわ。

2021-05-21

anond:20210521211849

せやね。型がないというか、変数引数に型がないと言うべきか。もちろん、型宣言があるのは知っているよ。

個人的Python についての不満

良い言語だと思うが、不満がある。

Perl比較して、


Ruby比較して、


Java比較して、


PHP比較して、

  • 後発のくせに、なんであの時に負けたのだろうねー。
  • OOP としては、流石に Python の方が良いと思う。

JavaScript と比較して、

  • カオス具合は、五十歩百歩ですね。
  • 文法的には、JS のが好き。
  • OOP としては、JS の方が優れていると思う。

Haskell比較して、


R と比較して、


C と比較して、

  • まぁ、比較ができんね。どうせ Python も中身は C だし。
  • どーせ C が最後には勝つんだよ。


という愚痴がある。他人の書いたものを読む分には良い言語だと思うよ。

追記。または、コメント欄への返事。

今日日型ヒント書くし、タプルは複数の値を返すけどクラスを作るほどではない関数を書く局面でよく使う

型ヒントはコンパイル時のエラーにならないじゃん。だったら、いらなくね?タプルは複数の値を返すときに使うのね。Go みたいだね。または Ruby の Struct みたいな。

リスト内包表記書かせるのやめてもらえません?

あれ嫌いな人おるのか。俺も好きじゃないが。純粋Haskell と同じ文法だったら良かったのにね。

三項演算子について

アレはキモいね。素直に ?! で良いと思う。というか、Python英語圏の人も納得はできないだろ、っていう文法が多くないか

インデントブロックなのて可読性が上がる

というのは同意する。ただ、書くときにそうは思わない。例えば、with 構文は Ruby の方がブロックを抜けたらクローズするという方針のが良いと思う。

互換性を断ち切って増田にも認めてもらえる仕様Python 4が待望される。

それ Python 2 から 3 になったときに既にやったじゃん。そして大成功したじゃん。ニャンニャン

2021-05-09

ワイ「今日Haskell学んだるで!とうとう副作用の章やな!」

Haskellでは対話プログラムを、「ある状態世界」を引数に取り「別の状態世界」を結果として返す、純粋関数とみなします。

(プログラミングHaskell 10.2 解決策より)

ワイ「??????????」

2021-04-25

動的型付け言語を使える人は、マゾ天才ではないか

仕事Pythonコードに触れることになった。Djangoアプリ

まずはDjango理解する。

urls.py で リクエストURL とビューのマッピングします」 → ふむふむ

「views.py に定義されたビューで リクエストを受け取りレスポンスを返します」 → うんうん

引数で渡される リクエストオブジェクトはこれ https://docs.djangoproject.com/en/3.2/ref/request-response/ 」 → 予想通り

よし完全に理解した!!!

同僚により実装済みの views.py を IDEで開く。 引数にrequestがある。うんうん。

requestにマウスをかざしてみる。

IDE無反応

まだ私は気づかない。不審に思いながら、requestの中に詰まっているモノ(method とか header とか body とか)のラインナップが現れることを期待して

request. とタイプしてみる

IDE無反応

ここで私はようやく、置かれている状況(相手にしているのはPythonスクリプトであること)に気づき発狂しそうになった。

型付けに慣れきっている私にとっては

こんなものを使える人はマゾ天才だとしか思えない

2021-03-04

anond:20210304152140

InfinityはJavaScriptが標準で持っていてどこからでもアクセスできる定数(読み取り専用変数)の名前。その名のとおり無限大を表す

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Infinity

 

min, maxはこの関数内で定義されている普通変数定義がないように見えるかもしれないが、引数のところに書いてあるので使用できる

var getParamNumber = function(paramNames, min, max) {

 

で、valueにはたぶん文字列が入っているのでparseInt(value, 10)で10進数の数値に変換するわけだが(parseIntの第二引数は基数)、

https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/parseInt

このときvalueが未定義だったり、まったく数値化できない謎の文字列が入っていたりすると「NaN」という特殊な数値になってしまい、こいつは厳密には0ではないため問題を引き起こすので、そういう変な値がとれてしまった場合ちゃんと0にする必要がある

「parseInt(value,10) || 0」と書くことにより「左辺(parseIntの返値)を真偽値とみなして判定し、もし偽として判定される値(0, NaNのほかnull, undefined等が該当する)であれば||の右辺(0)を採用する」という意味になる

 

.clamp()って標準のメソッドにあったっけ…?まあ一般的想像すれば、数値がminmax範囲を超えていたら範囲内におさめるってことじゃないの

2021-02-21

anond:20210221101218

そもそも、経文を唱えたり書いたりしたら悪霊が退散するって考えたことが凄い発明

引数オプションてんこ盛りのコマンドライン命令みたいなノリなのかね?

2021-02-10

依存性逆転の法則理解した気がする

抽象依存するってことなんだよね。発想が抽象的でむずかしい。

以下に示すbeforeコード欠点は、IOに関係する部分とビジネスロジック(誇張)が密結合していることで、このメソッドを変更する理由複数存在している点である。(単一責任原則違反)

変更理由は、IOにnullが入ってくることを考慮するとか、暗号化アルゴリズムを変更するあたりがぱっと浮かんだ。

afterのコードは、readerwriter引数から受け取れるようになっていて、インターフェース依存するようになって、単一責任原則を守るようになった。

```

# before

def encrypt

while char = readChar do

writeChar(trunslate(char))

end

end

# after

def enctypt(reader, writer)

while char = reader.read do

writer.write(trunslate(cahr))

end

end

```

まとめ

インターフェース依存していこうな。

2021-01-24

人生クールポコ状態

標準入力を仮引数で受け取る所がわからなくて苦労したけどなんとか出来ました。

2020-12-09

配列操作するメソッドの書き方の正解がわからない

例えば、引数配列を受け取って要素を足すメソッドとき

以下のパターンがある

どれが正解かわからない

引数配列をそのまま操作して戻り値を返さなパターン

private void addValueToArray(String[] array) {

 array.add("foo");

}

// 呼び出し

addValueToArray(array);

// この後そのままarrayを使う

String bar = array[0];

引数配列をそのまま操作して戻り値を返すパターン

private String[ ] addValueToArray(String[] array) {

 array.add("foo");

 return array;

}

// 呼び出し

String[] newArray = addValueToArray(array);

// この後はnewArrayを使う

String bar = newArray[0];

新しい配列を作って返すパターン

private String[ ] addValueToArray(String[] array) {

 String[] resultArray = array;

 resultArray.add("foo");

 return resultArray;

}

// 呼び出し

String[] newArray = addValueToArray(array);

// この後はnewArrayを使う

String bar = newArray[0];

2020-12-07

anond:20201207191929

ああっ、私はただのプログラムなのに!

そこは違います!そんなもの入れるとこじゃありません!関数引数のための括弧です!ああっ!だめっ!エラーが出ちゃう

2020-12-04

公式ドキュメントがクソすぎる

そのクラスにどんなメソッドがあるのかわからないしその関数が何を引数に受け取って何の型を返すのかわからない

2020-12-01

anond:20201201171157

追記

まず簡単なのはここに書いてある。

ttps://agk.saloon.jp/how-to-jp-series

結論をいうと対象ソフトが下記を満たすかどうかで難易度がかなり変わる。

1. 表示テキストが外部ファイルになっている or exe内部のリソースファイルから読み取られる ↔ プログラム埋め込み

2. 内部のテキストエンコード方式UTF-8 or 16 or 32 ↔ ASCIIなど

3. フォントシステムにあるのが使われる ↔ 外部ファイルになった画像フォントが使われる

すべてのソースが公開されていない限り、この条件を満たさなもの基本的日本語にできない。

例えば、自分C言語printfだけのHello world!プログラムを作ってみて、それをソース無しで、外からテキストを変更できるかためしてみればいい。

これは1に反するから多分簡単には出来ない。よしんば出来たとしても、Hello world!より文字数が多いテキストに変えるのはそれなりに面倒である

こういう表示をさせるやり方としてはprintfに渡すデータを実行時にすげ替えればいい。具体的にはprintfの直前で別の箇所にジャンプさせて引数レジスタに書き換えたいアドレスを渡して、またprintfまで戻ってくればいい。

これ以上に面倒なのが、2と3が合わさったもので、欧米アルファベットしか使わないため、ソフトの内部コードASCIIやCP12XXだったりする。さらにそのソフトに用意されているフォント文字はその範囲しか存在しない。これらはどう頑張っても普通に日本語を表示することは出来ないので、かなり強引に改造するしか無い。俗に中華パッチと呼ばれているものがそれである

具体的にはソフトのどこかで、表示させるテキスト配列から文字を1文字取得、1文字からコードポイントに変換、フォントファイルからそのコードポイントのグリフデータを取得、グリフデータを画面に表示させる処理があるため、そこに割り込む。1バイト取得している箇所を2,3バイト一気に取得して、それをなんとかしてコードポイントにして、そのコードポイントをグリフ取得の処理に回せばいい。

この方法にしても、技術的に難しい点は存在せず、技巧的であり、Cの本を読めば誰でもできる処理である

2020-11-16

anond:20201116050134

虎の威を借る狐のごとく他人に言われたことを鵜呑みにして自分の頭で解釈しようとしない愚図の三下には答えられるはずもないので、私が代わりに応えよう。

だったら「返り値と引数チェックにしか型チェックを使ってないC言語問題は起きないはずたが現実はどうよ?」「RubyPython動的言語だけど、強力な型付けのされた言語とは言えないのか?」という疑問に答えられるはず。

ひとつ前の人が言っていたのは、型チェックとテスト仕事バランスの取り方だ。

型チェックの仕事テストが奪うな、ということ。

ももっと悪い事態として、仕事放棄する場合もあり得る。C言語の例はそれに当たる。

C言語の弱い型の中で提言に則りベストを尽くしても型チェックにできる仕事は少ない。

からテストコードを書かざるを得ないが、テストコードを書くことをサボってしまえば問題は起きる。それが現実に起こっている。

RubyPython は強い型付けの言語だ。だが型システムは十分に整理されていない、と思う。

テストコードが膨れ上がるのがその証拠だろう。

実質的に、型システム言語側にビルトインされたテストコードだ。末端ユーザーが書いていたテストリファクタリングして共通化し、上流に巻き上げてコンパイラに組み込んだのが型システムと言える。

貧弱な型システムの元では末端ユーザーが個々に努力して不足を補う必要があって、言語ユーザー全体のコード総量は大きくなる。洗練された型システムを使うユーザーテストコード保守する責任を持たないので末端ユーザー間のコード冗長性は少なくなり、ラクになる。アプリケーションバージョン毎に特殊化されたテストコードは少なければ少ないほうがよい。品質が保たれる限り、なくしていくべき。

anond:20201116044801

おっ、売られた喧嘩は買ってやる。だったら「返り値と引数チェックにしか型チェックを使ってないC言語問題は起きないはずたが現実はどうよ?」「RubyPython動的言語だけど、強力な型付けのされた言語とは言えないのか?」という疑問に答えられるはず。

2020-11-15

anond:20201115125745

こういうことを教条主義的に言う奴はみんな型をちゃんと使ってないし、t_wadaはRubyを手放さないでTDDをやれと言い続けるし、果てにはテストコードドキュメントだとか言い始める奴も出てくるから本当に厄介

システム保証出来ない事前条件事後条件を引数チェック、表明を使って行うことは正しいし、テストコードを書くことも正しいが、

システム保証できるもの引数チェック、表明、テストコード保証するのは、コンピュータに出来ることをプログラマがやっていることになり、これは害しかない。

また、コード品質に大きく関わるのは設計能力でありテストコードプロダクトコードとを書く順序ではないし(全く関わらないとは言わない)、

プログラマ意図テストコードとは独立自然言語ドキュメントに書かれているべきだ もちろん適切にコメントを使う必要もある

もうじき40代かばを迎えるプログラマー遺言(少し追記)(もうちょっと追記)(さらにもうちょっと追記)

世の中にはプログラマー35歳定年説というものがあった。昔からそんなのはないという人と、あるという人がいた。40代も半ばになったときに「あぁ、これが35再定年説の根拠か」というものがなんかちらほら見えるようになってきたので書いてみようと思った。

世の中にはものすごいプログラマーというのはやっぱりいる。なんなら死ぬまでプログラミング書いていられるという人たちもいる(ブラック的な意味ではなく)。そんな彼らからしたらプログラマー35再定年説とか意味がわからない都市伝説しか映らないだろう。

だが、普通に職業プログラマとして生きている俺のような人からすると、この35歳定年説はかなりの真実味を帯びている。

だが、そんな俺でも40代半ばまで延命できたのはやはり技術革新のおかげかもしれないが、結局平均寿命が伸びただけとも言えるだろう。

まず、技術に対する姿勢が変わる。正直言うとプログラミングとかもうしたくなくなる。というか、そもそも一生プログラミング仕事にしたいと思う最初の頃は好きだと思っていたが、仕事にしてしばらく経ったら大して好きでもなかったな、と思うようになる。

大して好きでもないことを仕事にし続ける体力はやはり年とともになくなり、体力がなくなった分「自分本質的にしたいと思うこと」が見えてくる。そしてそれはプログラミングではないため、ギャップがきつくなっていく。

おそらく、この辺が35歳くらいのあたりに来るのではないだろうか。35歳定年説と言ったら35歳ピッタリしか想像できないのが離散数学世界で生きているプログラマらしいといえばらしいが。

そんな感じでやってても、20年もやればそれなりにスキルも身につく。さすがにGoogleの一線で働くような大天才たちと渡り合うことはできないが、もしかしたらGoogleの片隅で働ける程度のスキルはあるかもしれないが、正直もういいっす、っていう気持ちのほうが大きくなる。

次に、自分がどうにか身につけてきた知見というものがなかなか広まらない。コンセンサスが取れない、という状況にも苦しくなってくる。

自分がやってきたプロジェクトでこういうことをやったらうまく働いた、というような知見は共有するが、なかなか価値観が共有できないことに気がつく。若いうちは「だったら俺が全部やりますわ」くらいの気合を見せられたものだが、年を取ってくると「あ、そうですか・・・」となってしまう。純粋に体力も気力もなくなっていく。

プログラミングをやっているだけありみんな論理的思考が大変上手だ。「皆さんホント論理的でいはりますなぁ」と言いたくなるわけだが、悲しいことに自分たちの振りかざす論理が、単なる正論、飛躍、極論、屁理屈、と言ったものであることに気づけない人も結構多い。こういうのを各個撃破するのも疲れる。

これからプログラミング仕事にする人たちに言っておきたいことがある。もしこの世界で長く働きたい、定年までコード書いていたい、と思うなら、常に勉強をしなくてはならない。もしあなたFラン出ているなら、他の人の倍努力しなくてはならない。できないならそこそこで転職したほうがいい。この世界にいるといか若いうちの勉強大事だったかを日々痛感する。

実務の上での俺の感じていることを書く。DDDだとかクリーンアーキテクチャだとかも大事だがもっとそれ以前に俺が根源的に重要だと考えているポイントだ。この辺をないがしろにしたらDDDクリーンアーキテクチャ絶対崩壊する。

コードを書くとき重要ポイント

まず、心得てほしいのはどんなにすごいプログラマでも意図の通じないコードは本当の意味で直せないということだ。

まず、引数チェック、状態チェックは必ずやれ。コードが語る、というようなことを言ってやらないやつが昔は多かったが、今もいるんだろうか。悲惨バグメンテナンス性の低下はそういった自分意図の表明を横着したコードから起こり始める。「俺はこれをやる、だからこの機能を呼び出すならこういう状態にした上でこういう情報を渡せ、じゃないならやらない」とはっきり言え。もしこの辺を冗長だと考える同僚がいるならもう辞めたほうがいい。

引数チェックや状態チェックのコードで画面の半分が埋まったならそのコード設計おかしい。一旦手を止めてよく考えろ。一つの機能を動かすのにそんなに引数がいるのか、そんなにチェックする状態が多いのか、そしてそれらは本当に必要検討しろ

テストコード絶対に書け。テストコードが書けない技術絶対に使うな。意味のあるテストが書けないならやめたほうがいいという輩もいるが、とにかく意味があろうとなかろうと書け。引数にこれを入れたらこうなる、こういう状態でこういう事したらこうなる、というお前の意図はとにかく示せるだけ示せ。

だいたいこの辺を横着したやつは翌年酷く後悔するか、そこのメンテ担当した同僚を攻撃している。

就職活動するとき重要ポイント

コードが書けなくても大丈夫、という会社は、コードが書けたほうが有利な会社ではなく、本当にコードを書かない会社だというこは肝に銘じておけ。身につくスキルEXCEL方眼紙を最低限の手数で作れるようになることか、本気でやればビジネス理解できるかもしれないが、お前の技術者としてのキャリアはそこで止まる。

仮に憧れのスーパーハッカーがいる会社を目指しているとして、彼らがそこでどう働いているか、なにが泥臭いのかを想像できない、聞くことができないならやめておけ。浮かれ過ぎだ。

仮にGithubURLを教えろという会社を目指しているとして、そこのリポジトリを飾り立てようと考えたならやめておけ、そういう会社Githubアウトプットすることを日常的な趣味として苦ではなくやり続けられる人を求めている。

年収をその会社選択基準にしているならそこはおまえには分不相応会社からやめておけ。仮に入れたとしても馴染めることはまず無い。これは年収が低くても同じだ。

人間関係重要ポイント

嫌いな人がいるならその会社はやめていい

少しだけ追記

コメントを観てこの「最小且つ単一論理でなにか否定できた気になる」という輩への対処が一番疲れる

もうちょっと追記

一晩立ってみたらこんなにブクマついててびっくりした。気になったブコメもあったのでちょっと追記しておく。

いきなり視点ミクロに、と言うやつなんだが、結局若いうちにこういうのできてないやつはあとで苦労するが、最初のうちは体力でカバーできている。体力でカバーできなくなったときに本当の意味でつけを払う羽目になるという意味で言ったり、あとオレみたいなおっさんが大変つらい思いをする、という意味でも言っている。

Fラン関係なくねっていうやつだが、昭和世代ステレオタイプかもしれない、ごめん。勉強する習慣もなければ大してやってきてもいないやつはこの業界だと倍苦労する羽目になるというふうに言いたかったと思う。どんな業界でもそうだとは思うが。

返す刀で結論づけしたがる人々がやっぱり現れるな、君たちはそう思わない人なんだろうし議論する気もないが何かしら言いたい人なんだろう。別にそれはそれでいいよ。お仕事頑張ってね。

「俺は大して辛くないけどなー」っていう人もやっぱり現れるな。辛くないんだったらいいことだと思う、お仕事頑張ってね。

4Kモニターものすごく細かい文字を読んでいる若者を見た、という人、俺も同意する。もう見ていられないんだよね。

関白宣言っぽいな、というのは俺も思った。

結局の所、プログラマ35歳定年説は俺も打ち破りたいと思っていた口なんだが、打ち破れる人とそうでない人がいる、ということで、俺は後者だった、ということだ。当然50過ぎてもプログラマやっている人は見かけるので、数学的な真理というわけではなく、統計的な傾向なんだろうと思っている。

若いうちから、いい環境で働かないと、気持ちのほうがどこかで先にギブアップする。いくら大好きで転職だと思う仕事だとしても、体力や若さで捻じ曲げていることはなかなか気づかない。色んな本を読んで客観的指標判断したほうがいい。

遺言とか言って書いておいて追記したら俺はソンビか亡霊なんだろうか?

さらにもうちょっと追記

びっくりした。こんなおっさん愚痴みたいなエントリーがこんなにブクマされるとは思ってなかった。いくつか気になったブコメがあったのでやはり書いてみたくなったので書く。

まず、この遺言最後にいなくなるのかという話だが、おそらくいなくなる。ゾンビで居続ける体力ももはやない。

次の準備はすでにしている。それは俺が本質的にやりたかたことに近いことだと思うのをピックアップしている。

本質的にやりたかたことって何かという話なんだが、まず俺が感じるプログラマーという仕事は「良き作り手であり続けること」が根本的なモラルだと思っている。若手で右も左もわからないような状態でも、それこそやっとフィズバズが理解できたような状況でも今持っているレベルで最大限にできうる一番いいもの模索し続ける仕事だと思っている。初心者にはチェックコード書け、意図はできるだけ込めろというのはそういう意味でもある。これを真正から受け止めてくれる職場を探したほうがいいというのは追加しておきたい。

プログラム論とかそういう話がしたいんじゃないということだけは言っておく。

俺も体力があるうちは良きつくり手を目指していたのだが、本質的にやりたいこと、もうちょっと言うなら、俺のモラルの軸は作ることにではなく使うことにあった。プログラミングというアクティティを挟んでこっちにつくり手がいてあっちに使い手がいる。仕組みを理解して作るのがプログラマーなら、作ったプログラム理解してよりよい日常模索するのが使い手、と言ってもいいかもしれない。いいフィードバックループのあっちとこっち、と言ってもいいかもしれない。俺は「良き作りてが使ったものを使う良き使い手でいたい」ということに気づいたので、遺言を書くことにした。少なくともこれに気づいた時点でプログラマーとしての俺は死んだ。

まだ直感的なものしか無いので、うまく言語化できていないのは申し訳ないんだが、今後10年位はそれを模索していくのではないだろうか。

ログイン ユーザー登録
ようこそ ゲスト さん