はてなブックマーク

解説 Crystalはコンパイル時に自動的に src/prelude.cr を読み込む。 このファイルの中で標準ライブラリを読み込んでいるため、CrystalではRubyのようにスラスラとコードがかけるようになっている。 一方、このファイル内で大量の標準ライブラリを読みこんでいるせいで、Crystalのバイナリは実際には使ってない機能もバイナリに含めてしまっている。 正確に言えば、コンパイラが使わないと分かっているコードは含まれないのだが、シグナルやスレッド等、使うかわからないコードはバイナリに含まれてしまう。 例にあるように、ビルドオプションに --prelude="empty" を加えると src/prelude.cr を読み込む代わりに src/empty.cr を読み込むようになる。このファイルではごくわずかなライブラリのみを読み込んでいるため、生成されるバイナリサイズが小さくなる

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

メモです。表題の通り。 利用される値 license_key ディベロッパーコンソール > アプリ > サービスとAPI の「バイナリに追加する Base64 エンコードの RSA 公開鍵です。スペースはすべて削除してください。」の下にある文字列 purchase_data 購入時のIntentから INAPP_PURCHASE_DATA で取り出せる値 signature 購入時のIntentから INAPP_DATA_SIGNATURE で取り出せる値 検証コード def verify(data, sign) verifier.verify(OpenSSL::Digest::SHA1.new, Base64.decode64(sign), data) end def verifier @_verifier ||= OpenSSL::PKey::RSA.new(Base64.decode

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

using System; class Program { struct ValWrap { public int value; } class RefWrap { public int value; } static void swapAndEdit(ValWrap left, ValWrap right) { var tmp = left; left = right; right = tmp; tmp.value *= 100; } static void swapAndEdit(RefWrap left, RefWrap right) { var tmp = left; left = right; right = tmp; tmp.value *= 100; } static void swapAndEdit(ref ValWrap left, ref ValWrap right)

まとめ HTMLでタグを書く時に、<br />のようにスラッシュ/を入れる書き方がありますが、<br>と書くほうが良いでしょう。<img>とか<input>とか<meta>とかも全部いっしょです。 詳細 なんで後ろに / をつけるの？ 昔 XHTML というものを流行らせようとしたときの名残です。 XHTMLはXMLとして正しくないといけないので <br>単独ではダメで<br />か<br></br>と書かなくてはいけません。 （ちなみにXML的には<br/>でよいのですが、当時のブラウザはそれを正しいタグとして認識できなかったため、<br />と書く必要がありました） XHTML ? 昔 W3C という団体が「これからのWebは機械からも利用できるようにすべきだ。だからXMLとして読める形式にしよう」と言い出しました。ところが XHTMLのMIME-TYPEだとWebページとして表示され

この記事は Javascriptを使うのをやめろ：Railsの時代遅れ云々についての結論 等の 「JSダメだろ」「いやダメなのはお前だろ」論争に対する私の考えになります。 結論 JavaScriptを使う前に、それによって提供されるUXに対してもっと検討してほしい。 メシマズって ここでメシマズを例に挙げたのはJSの使い方が 「普通のケーキじゃ物足りないと思ってアクセントに刺身を入れてみたの。どう？」 「うん、おいしい……よ？ （生臭くて食べられたもんじゃない、どうしよう）」 という流れに似ていると感じたためです。 この記事では「このような行為」もしくは「このような行為をする人物」をメシマズと呼ぶことにします。 メシマズなサイト ケーキに刺身は極論ですが、例えばこのQiitaを例にします。 このサイトでは過去の記事を見たい場合、下までスクロールして「もっと見る」のボタンを押す。 こうすると

はじめに AppleがSwiftという言語を発表した。 新しい言語をつくるのであれば既存の言語から良いアイディアは取り入れ悪いアイディアは取り入れないのが良い。 TwitterのTLを見ていると「Swiftは○○に似ている」という発言があったので、 どこら辺が似ているのかを自分の中で振り返ってみた。 （最初は「Swiftは○○のパクり」というタイトルにしたかったのだが、文全体を挑発的に書けなかったのでやめた） 間違っていることもあるはずなので、コメントは大歓迎である。 全部紹介するのは無理なので、とりあえず A Swift Tour から引用したい。 基本文法 基本文法はC言語系だ。現在の手続き型言語はC++やJava等これが主流である。 （主流でない文法はFORTRAN、BASIC、Pascalなどなど。関数型だとまた全く違う） Simple Values letやvarのように、型から

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代

内容はあくまで私の主観です。いつも通りコメントは大歓迎ですが、長文であれば別途投稿してもらえたほうが有益だと思います。 自分のスタンス 自動テストは素晴らしい。どんどん利用していくべき。 テスト駆動開発の主張に同意できない。 TDDの何がしっくりこないか TDDの主張がしっくりこない TDDの肝は「テストを先に書くことで思考をクリアにし、実装を早くする」「Red-Green-Refactoringの繰り返し（以下、TDDのサイクル）というガイドを用意することで開発者を安心させる」だと思っている。 まず一つめが納得いかない。世の中のプログラマは本当にテストが無いと行き当たりばったりで全く保守できないような実装をしてしまうのだろうか。少なくとも私はテストの有無に依らずそれなりの設計をする自信がある。 最初にテストがあれば「テストしやすいコードを強制させる」ことができるのはまあ正しいだろう。しか

タイトルに反して、どうやらWikipediaによると型チェックはソフトウェアテストではないらしい。 プログラムを実行し、正しく動作するかどうか確認する作業 （略） 欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できない。 型チェックは一部ではあるものの、プログラムを実行するまでもなく正しく動くことを確認でき、欠陥が存在しないことの証明ができてしまうからだ。 しかし型チェックはテストコード同様、「プログラムの動作部分ではないが、プログラマのミスを避けるために追加で書かれるコード。本質的には無くてよい」ものであることに違いはない。 型チェックもソフトウェアテストってことにしておこうよ 従来のソフトウェアテストを「帰納的テスト」、型チェックのようなものを「演繹的テスト」と呼びたい。 型チェック自体をテストとすれば多くのソフトウェア開発でTDDを行っていることになる。これは単な

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

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

各本の情報はJSONで表現されます。/books にGETリクエストした場合はレスポンスとして本の一覧がJSONとして返されます。 本の追加や削除を行う場合は、本情報をJSON形式でPOSTリクエストのボディとして送ります。application/x-www-form-urlencoded形式で送ることは避けるべきです。 更新に失敗した場合、失敗した理由をJSON形式で返します。 ステータスコードは、取得時・更新成功時には200 OKを、更新失敗時には4XX番代を使うのがよいでしょう。 情報はJSON形式と書きましたが、XMLなどでも構いません。 しかし、正常系・異常系ともにアプリケーション内で統一された形式を利用してください。 リソース指向 本の情報は/booksにあるとして、拡張子を変えることで、様々なフォーマットでデータを利用できるようにします。 例えば本の一覧をJSON形式で欲しけ

説明 なぜ私がJava8のラムダ式の型をわざわざ調べることになったのか説明する。 C#ではラムダ式の型としてFuncとActionが用意されている。 一方Javaではさまざまな型が用意されており、それらの定義がまた様々なパッケージに分散している。このため必要な型を探すのが難しい。 例えば「intとintを受け取りintを返すような関数」を引数に取る関数reduceを定義したくなったとする。 この時C#では、Func<int, int, int>を型として利用すればよいと容易に判断がつくが、JavaでIntBinaryOperatorを使えばよいと判断するのはJava8に慣れたプログラマでないと難しい。 そんな理由で、わざわざJava8のラムダ式の型を調べたり、それらの命名規則を探ってみたりしたのである。 おまけ 例示のため、JavaとC#でreduce関数を利用したプログラムを記述した。

背景 Java 8 が公開され、Javaでもラムダ式が使えるようになった。 言語的制約により、Javaはプリミティブ型を含むものは別のインタフェースを用意せざるを得なかった。 その結果、必要なクラス名が簡単にはわからなくなってしまったので、とりあえず列挙してみた。 規則性はあるようだが、命名規則の優先度がいまいちよく分からない 対象 対象は Runnableクラス, java.util.function名前空間のものである。 一覧表 ラムダ式の型 Javaのクラス + メソッド名