Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

MacBook Pro (M1)でのメモです。インストールできるかどうか状況確認メモです。 自分がよく使うものを中心に。なるべくARMネイティブになるように。もしプライマリーで提供されているインストール手段（.dmg利用など）でARM対応が済んでいればそれを紹介しますが、もしそれで対応していない場合にはMacPortsやソースビルドなどの結果も合わせて紹介します。 PowerPC->x86->x86_64とユニバーサルバイナリを挟んで対応してきたMacPortsはこういう過渡期に強いです。 なお、ここで紹介するバージョンは最新版から古い可能性がありますが、「M1サポートが追加された前後のバージョン」を明記するのを目標にしていますので、これより新しければ問題ないと見てもらえればと思います。 編集リクエストウェルカムです。 現在の状況 IDE/エディタ Eclipseはあまりきちんと試していま

PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra

PySpa統合思念体です。これからJavaScriptを覚えるなら、「この書き方はもう覚えなくていい」（よりよい代替がある）というものを集めてみました。 ES6以降の難しさは、旧来の書き方にプラスが増えただけではなく、大量の「旧来の書き方は間違いを誘発しやすいから非推奨」というものを作り出した点にあります。5年前、10年前の本やウェブがあまり役に立たちません。なお、書き方が複数あるものは、好き嫌いは当然あると思いますが、あえて過激に1つに絞っているところもあります。なお、これはこれから新規に学ぶ人が、過去のドキュメントやコードを見た時に古い情報を選別するためのまとめです。残念ながら、今時の書き方のみで構成された書籍などが存在しないからです。 たぶん明示的に書いていても読み飛ばす人はいると思いますが、すでに書いている人向けではありません。これから書くコードをこのスタイルにしていくのは別にいい

発音記号はalc.co.jpの英辞郎 on Webから引用。他にも思い出したら追記するかも？ Label [léibl] 日本語ではラベルと書かれることが多いけど、それで発音しても通じない。レーベルの方が近い。 Route [rúːt] 日本語ではルートと書かれるし、発音記号見てもどう見てもルートなんだけど、ラウトとアメリカでは呼ぶ。イギリスだとルートのままという噂も聞くけど、ルートだとrootと同じになっちゃうので、独自発展した業界発音なのかもしれない。派生語のRouterもルーターじゃなくてラウター。こんなツイートも。 そういえば昨日Routingは米語ではラウティングと読み、ルーティング発音の米語でえっちい意味のスラングがあると聞きました。ルーティングプロトコルは任せてくれとかいうとエロテクマスターみたいな意味になると聞きました。 本当かどうかはわかりません。 — さぎにゃん しゅわ

この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav

GoCon 2015 Winterでは、社内での取り組みとしてExcelのパースの時間のロスを避けるために、簡易データ構造を使ってMessagePack + LZ4で圧縮して高速化したことを紹介しました。それでも十分速くはなったのですが、LTで発表のあったシリアライズ系のライブラリのベンチマーク比較でFlatbuffersが最速だったので、ちょっと試してみました。 ↑のグラフは、こちらのベンチマークの結果をExcelでグラフにしてみたものです。Gobがダントツ遅かったのでそちらは振りきっています(Gobに合わせると他のものの比較がしにくくなるので範囲を狭めた)。GoConで発表した通り、今MessagePackを使っているのはデータのキャッシュです。作成に多少がかかっても、後の読み出しが速い方がトータルとしてはうれしい領域なので、Unmarshalが最速のFlatbuffersに俄然興味を

埋め込み(embedded)に要注意というお話です。あるいは、GolangもC++のようなゼロオーバーヘッドを目指していると考えれば腑に落ちるよね、的な。 Goはオブジェクト指向言語っぽく使うことができます。次のような機能を提供しています。 interfaceを使ったコーディング 埋め込み(embedded)を使った実装継承 インタフェースは次のような感じです。 // ポニーは歩ける type Pony interface { Walk() } // アースポニーも歩けるので、Ponyインタフェースに渡せる type EarthPony struct { } func (ep *EarthPony) Walk() { fmt.Println("歩くよ") } インタフェースはメソッド宣言しかかけません。実装は書けません。でも、定義されたメソッドを持てば、それはすべて「これの仲間だ」という感

URLをいじくるプログラムをいじっていて、仕様がよくわからなくて悩んだのでまとめます。 2/23: 追試部分を追記 2018/7/14: JavaScriptのURLSearchParamsと、GoのPathEscapeについて追記 ことの経緯 HTTPとはなんぞやとか、GETとPOSTがどうの、それぞれでパラメータがどういう経緯でウェブアプリケーション(とかCGI)に渡って来るのかぐらいは知っていました。で、ウェブでXHRでGETリクエストを送る場合にはJavaScriptのencodeURIComponent()で各パラメータをエンコードして、&でくっつけて、URLの末尾に?で付与すればいいんだよね？と思っていました。こんな感じに。 var finalUrl = [url, "?", encodeURIComponent("key"), "=", encodeURIComponent(