はてなブックマーク

また飛行機内の暇つぶしエッセイ。 昔ベックマンがチャンネル9でHaskellやF#では、シンタックスを数学に近づけたい、なぜならそっちの方が数学的に考える時にノイズが少ないからだ、 みたいな事を言っていた気がする。 その事を思い出した、という話。 最近Folangでgoで書いたトランスパイラをセルフホストのために再実装している。 同じような実装をgoとfolangで書く事になるので、両者の特徴というか出来上がるコードの違いがなかなか興味深い。 基本的にはfolangの実装はF#で実装した場合とほとんど同じ感じとは思うので、以下はF#とgolangの話と思って読んでもらっておおむね良い。 セルフホストのためには再実装が必要なのだが、同じものを二回、しかも比較的最近実装したものをもう一回実装するのはかったるい。 だからとっとと終わらせたいし、デバッグとかもしたくないので、なるべくなら同じ実装に

飛行機の中の暇つぶしとしてスマホで文章を書いてみる。 今、プログラマとして自分が一番やるべきこと、やりたい事はなんだろう？と考えてみると、 今仕事でやっている、GPU用の独自言語を作る、というのは、かなり有力なものに思う。 一番やりたい事、やるべき事を考えた時に、それが今やってる事と一致しているのは、なかなか良い事だなぁ。 今回の仕事は、作っているものに関しては、なかなか満足のいくものだ。 自分が自分の考えで、あったら良いと思うものを作っている。 成功の栄誉も失敗の惨めさも、全て私のものと思える。 失敗した時にそれを自分のものと思える、当事者意識のある事をやるのは、健全な事にも思うし、 自分らの年齢、キャリアのステージでは当然そうあるべき事にも思う。 プログラマにとって、仕事の内容が自分のものか会社やプロジェクトのものか、というのは、ケースバイケースで結構状況により差があると思う。 今回の

最近、SNS向きでは無い話題、というのが随分増えたと思う。 自分はプログラミングの専門家と言って良いと思うのだけれど、 プログラムに関する間違った情報などは定期的にSNSで流れて来る。 そしてそうした事にいちいち反論するのはいかにも無駄な事に感じられてやる気がしない。 以前kzysもインターネットで誰かが間違っていることを気にしない - blog.8-p.infoと言っていたが、 同じような話だろう。 こうした事をSNSで反論していくのが無駄だ、という事に同意があるとして、 ではどうすべきか？と言えば、一専門家としては正しい事を発信するのが良い、と思う。 そうした事はSNS以外の場でやるのがいいんじゃないか。SNSでやると反論しているのと同じになってしまうので。 それをSNSでやるのと、例えばblogでやるのは同じではないか？という気もするが、これは違うと思う。 SNSでは、発言のコンテキ

あおぞらAndroid教室でツアーとかGetting Startedとかリファレンスを読んでいけるようにする為に、 技術文書の読み方、というのを考えてみたい。 はじめに考えてる事 自分はあまり技術文書を何らかの手法に従って読んでいる訳で無く、またそうすべきともあまり思っていない。 好きに読んだらいいと思うし、自分の方法が何か特別優れていて人に伝えるべきだという気もしない。 一方で、大学とかに行ってないプログラム素人に技術文書を読ませると、 速度にも内容の消化具合にも大きく問題があり、そこには読み方の問題があるように見える。 だからプログラムを教える事の一貫として、技術文書の読み方を教える必要はあるようにも見える。 現実問題として明らかに遅さに問題があるので、なんとか出来るならしたい。 ライブラリやフレームワークや言語を学ぶのに技術文書を読む機会は多く、それら特有の特徴もいろいろあるので、

あおぞらAndroid教室でプログラム素人にプログラムを教えていると、 プログラムの解説を読むのがすごく遅い、という事に気づく。 自分にとってプログラムの本を読むのは娯楽なので、 あんまり早く読もうとはしていないし、 その結果として自分はプログラムの本を読むのがそんなに早くも無いと思っている。 だが、その自分と比較しても何倍も遅い。 なので自分（や普通のプログラマ）がプログラムの本を読む速度が早い理由を考えてみたくなった。 構造の予想と内容の予想 例えば今、【書籍】CppConcurrencyInActionを読んでいる。 けれど、読んでいる内容は文字の半分以下なんじゃないか。 普通のプログラマは、プログラムの本を全部は読んでないよな。 章のタイトルを見て、節のタイトルなどを見て、そこで何が書いてあるのかとかを予想して、 適当にパラパラ見つつサンプルコードとかはちょっと時間を掛けて見て、

以前podcastなどでも言ったが、最近友人知人を集めてAndroidアプリ開発を教えている。 最初は普段ダベってる友人が、今の仕事低賃金なのでAndroidのアプリ開発を覚えてプログラマになりたい、とか言ってきた。 年齢的には自分と近い年齢なのでそれなりに探す必要はあるだろうが、 まぁ探せばありそうだし、どのみちプログラムには興味あったのでやってみたい、との事。 普段カフェやファミレスでダベってるのをプログラム教えるのに変えるのは別にいいよ、と思ったので、やってみた。 で、共通の友人に「最近あいつにアプリ開発教えててさ〜」と言ったら「何それ、俺も習いたいんだけど？」とか言い出して、 別に二人でも三人でもあんま変わらんしいいぜ、と言って、これだとどこか市の施設とかでやる方がいいか、と探したら無料で使えてホワイトボードもある所があったので、 そこで教え始めた。 で、そんな話を親族にしてて、小

「karino2のあおぞらAndroid開発教室」のトップページです。 以下の再生リストのコンテンツと連動しています。 このコースは、基本的には以下の二つが交互に進む感じになっています。 Androidの勉強 kotlinというプログラム言語の勉強 Androidの方には「Android側」と記述してあります。区別が曖昧なものもありますが、目安にどうぞ。 AndroidStudioを触ってみる Android側 最初の一歩、TextViewとButtonを使ってみよう！ Android側 EditText、チェックボックスなどを使ってみる この辺まで終わったら、プログラム言語の方の勉強を少しする方が良い。 プログラムをkotlinで学ぶ、前篇 ここから少しプログラム言語の勉強をする。 算数で挫折した人向けのJavaScript入門を6.3までやる 「算数で挫折した人向けの、JavaScri

空港で暇なので何か文章でも書こうという事で。 podcastなどでも度々話をしているが、ここ1年くらい掛けてお仕事で作っていた独自言語が割と使えるようになった。 リリースまでにはまだやる事がそれなりに残っているが、2年弱くらいで作ったとは言えそうだ。 これはコレクションからUnitTestのライブラリからパーサーから全て手作りで、結構大掛かりであり、実装の面でも色々な工夫が入っているし、 そもそもに実現しているものも、自分が作らなければ類似のものは無いくらいには新規性のあるものだ（独自言語なので当たり前だが）。 こういう、結構大きくて、自分が作らなければ世の中に無いものが、たった一人で生み出せる、というのは、結構凄いことだよなぁ。 一方で、2年くらい仕事でずっと一人で何かを作り続ければ、相当なものが作れる人は、世の中にはそれなりにたくさんいるんんじゃないか。 自分と同世代のプログラマの友人

宿に長期滞在している都合で、いろいろな仕事の人と話をする機会がある。 そうして思うのは、自分は割と意義のあると思える仕事をしているなぁ、という事。 これはプログラマという仕事の良い所なんじゃないか。 今やっている仕事は一発当てよう系の仕事で、当てられそうだという意味では無い。 当たらなければまぁみじめな失敗に終わると言えるし、 その結果はあまり意義のあるものでも無い。 だがやってみないと分からないと思えるような事はやれていて、 何度やっても箸にも棒にもかからないという感じでは無い。 これは標準的なプログラムの仕事の範疇と言って良いと思う。 特別凄い事でも無いが、特別恵まれてない事でも無い。 まぁ普通の範囲で多少恵まれている方かな、くらいか？ 待遇や労働環境を考えると、普通くらいかもしれない。 だが、40代で何かアウトプットに意義を感じる仕事をするというのは、結構恵まれてるよなぁ。 自分のや

fsharp-lessonで抽象データ型を定義する段になり、 抽象データ型の解説をリンクしようとした所、 どうも良い解説が無い。 仕方ないので自分で解説を書く事にする。 この記事では抽象データ型、Abstract Data TypeをADTとも略します。 この記事は初心者向けの話なのでベテランは読む必要はありません。 データ型を考える 抽象データ型（Abstract Data Type）とは、 データ型の拡張と考えるのが良い。 抽象データ型を考えるには、まず抽象じゃないデータ型を見てみるのが良い。 という事で単なるデータ型を考えよう。 データ型というのは、ようするにintとかfloatとかの事です。 データ型というのは、それを使って変数を定義したりして、プログラムを書くのに使います。 int x = 0; int SomFunc(int b) { ... } float y = 0; fl

karino2の暇つぶしプログラム教室のF#編のページです。 理論上がりの人が機械学習屋になってPythonでとりあえずコードは書けるようになった、くらいの人で、 そろそろプログラムって奴を本格的にやってみるか、と思った人を対象に、karino2が暇つぶし程度にプログラムを教える、という事をやるサイトです。 機械学習屋になりたい人向けではなくて、すでになっている人に対してのプログラムの教室です。機械学習は扱いません。 姉妹サイト: karino2の暇つぶしプログラム教室 C言語編(通称c-lesson) モチベーションや背景など モチベーションとか背景とか 進め方 適当に課題をやってもらいつつgitterで質問に答えたり添削したりして、 たまに補足したり説明した方がいいと思う事は本を紹介したり説明をしたり動画を作ったりします。 とりあえず始める人はgitterで自己紹介くらい簡単にしてくれ

TeFWikiとは、ローカルのプレーンテキストのテキストファイルに、マークダウンとWikiLinkを使ったWikiです。名前の由来はTExt File WIKIから。 特徴 単一フォルダ内のプレーンテキストのみ、メタデータ無し markdown + 大かっこによるWikiLink　(ex. [[何かのリンク]]) モダンなCSSによるレンダリング (bulma.css) スマホとPCのアプリ PC版webサーバー要らずの単独のアプリ（ElectronでMacとWindowsで動作確認済み） Android版はネイティブアプリ 共有手段は特に用意しないので、クラウドストレージのフォルダsyncのアプリを別途使う（自分はAutoSync for Google Driveを使っている） スクリーンショット PC版 Android版 ダウンロード 今の所、PC版（Mac, Windows）とAnd

自分はF# での開発は、基本的にfsx上でM-Enterしながら開発している。 ちょっと動作を確認、とかじゃなくて、プロジェクトの最初から最後の直前までずっとfsx上からしか実行しない。 ビルドも動作確認目的でしかしない。めんどくさいので最後までProgram.fs書かない事もある。 普通emacsとかでスクリプト言語開発するとみんなこういうスタイルだろうからあまり言及する必要無いか？と思ったが、 jmukとkzysがF# 触ってみてるのを見て、一応簡単に自分がどう開発しているか、と、ちょっとしたワークアラウンド的な事も解説してみようかと思って書いてみる。 fsharp scriptとfsの関係とかもちょっと入門者にはわかりにくいし（自分も良く分かってない）。 前提条件: F# の開発環境 今のところMac Bookで書いてます。 .NET Core SDK VS Code VS Code

F# はOOPも出来るぜ、ってみんな言うし、WPFとかFormsとかASP.NETとかやる人にとってはそこらへんが全部ちゃんと書けるのがすごい重要なのも良く分かるのだが、 F# for Fun and Profitでも最初はOOPするなと言っているし、 実際自分も一ヶ月くらいF# で結構なコードを書いたが、一回もclassは定義していない。 .NETのライブラリを呼ぶのでnewしたりメソッドを呼んだりはするのだけれど。 という事で言うほどOOPしなくね？と思うのだった。 特にコマンドラインでの雑用をメインとする自分みたいな人はほとんどクラスを定義する事は無いんじゃないか。プログラムの規模が小さいという意味では無くて、intrusiveなライブラリを使わない、という意味で。 で、代わりに使うのは何か？と言えばmoduleだと思う。 moduleとは何か？ moduleは何かと言うと、C++と

F#にはレコード型がある。レコード型はCの構造体みたいなものだが、 みたいなものという時にはいつも違いが重要になるもので、レコード型もその例に漏れない。 なお、F#に限らずMLにそもそもある概念だった気がするからML派生言語には全部ある気もするが、あんま詳しくないのでF#の話をする。 レコード型は基本はimmutableで変更は出来ない。代わりに部分更新したオブジェクトを新しく作れる。 この辺は最近のJSにも入っているので良くある概念と思う。 さらにハッシュ値とかequalityとか使いそうなものは勝手に生成される。そういうもの。 kotlinのdataクラスとかも似ているが、向こうはvarも指定出来るところはちょっと違う。 ただ基本的な考え方は同じものだ。実際dataクラスも全部valにする事が多くて、実質同じ使い方をする。 という事でここではkotlinのdataクラスも含めてレコード

PCとスマホでメモを共有したくていろいろ渡り歩いたが、どれも気に食わないので自分で作る事にした。 GooglePlay: てきすとでっき 個人的には究極のメモアプリが出来たんじゃないかと思っている。 以下背景として考えている思想的な事などを。 追記: PC版も作った github: electron-textdeck 追記: ローカルのファイルを指定してsyncする方が良さそう GoogleDriveのファイルを直接指定すると、以前は割と長いことそのurlが使えたのだけれど、2021-09-03現在、数日単位で無効になるように変更されたっぽい。 SO: Persisted SAF URI from Google Drive changes after a few days, content is unreachable という事でローカルのファイルを指定して、Google DriveとはA

以前MacとWindowsの両方で使う雑用コマンドライン言語にF#はどうだろう？などと書いたように、F#を使ってみているが、なかなか良くて気に入った。 VS Codeでの開発環境が良い まずVS Code+Ionideが良く出来ている。 インテリセンスは早いし書いてる途中のエラーもガンガン見つけてくれる。 文法的な間違いもツールチップでだいたい解決していけて、 使いながら学習していける感じがある。 以前試したgolangのLSより断然良く出来ている（最近のgolangは良くなってるかもしれないが）。 .NET Coreのインストールも特に手間取らずあっさり出来るし、 環境設定もハマらない。良い。 MacでもWindowsでも特に問題なく使える。 こういうのはMSは良い仕事をするね。Javaよりずっとわかりやすい。 環境が割と成熟していてセットアップとかのストレスが無いのが良い。 言語周辺の

みんな割と未来の予言はよくするが、あんまりその結果を振り返らんよなぁ。 現在のディープラーニングのブームをどう捉えるか、というか、 プログラマのキャリアという点でどう接していくか、を考えるにあたり、 過去のブームを考えてみるのは良いんじゃないか、という気がした。 最近並列GCや並行GCの章を読んでいて、 一昔前の大きなブームとしてはParallel computingがあったなぁ、と思い出した。 ということでこの事について、専門にしてなかった部外者プログラマの目にどう映ったかを記しておきたい。 なお、「XXXだと言われていた」はあんまりソースとかを確認したりはしてません。 なんとなく自分はそう聞いていた気がしたしそう思ってた、程度のものです。 かつて思っていたことと当時の状況 Parallel computingはだいたい10年くらい前の時点ではその後の大きなトレンドとして明らかに存在して

はじめに このkotlin lessonではhttpにはfuelを使ってもらっている。 だからコルーチンというかawaitResponseResultとかを使ってもらっている。 で、コルーチンの解説なんて死ぬほどあるだろうから適当にググって適当に書いてください、と言った所、皆なんか全然分かってない感じのコードを書いてくる。 何故だ？解説とかあるだろ？と思って自分でもググってみると、「確かにこれじゃ入門者は使えないな…」というのばかり。 という事で、あまり分かってない人がとりあえず使うのに必要となる事だけを解説してみます。 hello worldとかでは無くて、そういうのを動かした後に読む文書です。 この文書を書こうと思ったきっかけ こんなコードが来ました（多少解説の為に変更しています）。 詳細はいいとして、putContentInnnerはsuspend関数で中にawaitResponse

プログラムの入門としての抽象化の話をします。ベテラン向けじゃないんで、ベテランの人は読んでも新しい事は無いと思います。 データ分析界隈だと、数学や物理などで抽象的な事というのには良く出会ってきた経験を持つので、抽象的な物は得意な方だ、という人は多いと思うし、実際そうだと思う。 ただ、プログラムの抽象化は違う部分もあるので、一度プログラムの抽象化という物を初心者の気持ちになって学んでみる機会は必要とも思う。 ここではそんな話をしてみる。 カプセル化 プログラムの抽象化と言えばカプセル化なのだが、いまいち良い解説が無いので自分で書く事にする。 一般的な事は知らないけれど、プログラムにおいては、抽象化の定義は「情報を落とす」事となっている。 全ての情報を持っている所から、特定の情報だけにする事でアクセスする「口」を定める訳だ。 だからだいたいの抽象化は物を「削る」のだけど、一つだけ例外がある そ

前から書こうと思っていた、ALPを支える技術の感想です。二ヶ月くらい遅れですが(^^; まず本題の前にこのシリーズの感想から。 なかなか面白かった。 主義主張には同意しかねる部分は多いけれど（特にTizenやWindows Mobileが駄目だったからただリリースしても駄目だった、という結論）、結局どちらが正しいかを知る方法は無いので、多様な意見という事なのでしょう。 このシリーズで面白いな、と思ったのは、第三期では内部の人が意外と意義とか面白さを持ってやっていたように見える所。 これは結構意外でした。 もっと「俺は全然駄目だと思ってたけど仕方なかったんだ」みたいな内容になるのかと思っていたので、中は中でいろいろあったんだろうなぁ、と。 外から見ると一期も二期も三期もなくずっとぐずぐずやってて何も出ない、という印象だったのだけど、結構違いはあるんですね。 実際たけしさんは5年くらいやってた

以前Tensorflowの本を探してた事を覚えてた編集さんが、「最近Tensorflowの本を出したので良かったら読んで見てください」と言って献本してもらった本。 今の自分がTensorflowについて学べる本がこの世に存在するとは思えないのだけれど、この本の評判は機械学習の本としてそこそこ良さそうで、ちょっと気になっては居た。 今年前半は小難しい本を読んでばかり居たのでここらで息抜きに軽く普通の本も読みたいと思ってた所なので、読んで見る事にする。 なお、私はたぶんそもそもに対象読者じゃない気がするので、このブログのポストを読む時はそのへんは差し引いてください。 開幕の前提にいまいち同意出来ない この本は、プログラマのツールボックスに新しく機械学習を追加しよう、という前提で書かれている。 でもこの前提がもはや成立しないんじゃないか。 これは機械学習を、まるでサービス開発の一手法として必要に

karino2の暇つぶしプログラム教室のC言語編のページです。 C言語の入門書くらいは読んだがそこから先が良くわからん、という人向けに、 暇つぶし程度に教える、という事をやるサイトです。 あらすじ twitterでプログラム教えてもいいって言ったら教えてほしいという人がいたので教える事にする。 少し話を聞いたところ、 まずはC言語でちゃんとプログラム書く事を教えてほしい C言語の本などは読んでいて、ArduinoやRasbherryPiなどの経験はちょっとある 大学院生だがCS系の専攻では無い という感じらしい。 進め方 適当に課題をやってもらいつつgitterで質問に答えたり添削したりして、 たまに補足したり説明した方がいいと思う事は本を紹介したり説明をしたり動画を作ったりします。 とりあえず始める人はgitterで自己紹介くらい簡単にしてくれると嬉しいです。 課題は https://g